K.Maebashi's BBS

★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★ ★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★ ☆★☆ ★☆★　ライブチャット検索チャットレディ情報　無料ポータルサイト ☆★☆ ★☆★ ライブチャットひろば 　http://livechat-hiroba.com/ ☆★☆ ★☆★　ライブチャット人気サイトも、無料お試しサイトも、 ☆★☆　新規オープンも一目でわかる！ ★☆★　2005年の ライブチャットひろばでは、数あるライブチャットサイトを ☆★☆　独自の視点でて紹介しています！ ★☆★　サイト探しに苦労なさってるライブチャットファンの皆様に、 ☆★☆　少しでもお役に立てればと管理人が厳選したサイトをご紹介いたします。 ★☆★ また、出会い系サイトのご紹介や、相互リンクも随時募集しております。 ☆★☆　お気軽に御覧下さい。 ★☆★　もちろん無料で情報をゲットしてください。 ☆★☆　 ★☆★ ☆★☆ http://livechat-hiroba.com/ http://livechat-hiroba.com/

おお、ビンゴでしたか。 該当スレッドをいろんな形式で表示してみたり、 「PHP & MySQL」のコンテンツでデータ構造を調べたりして、 パズルを解くように推理して楽しんでました。 生データに手を入れて整合性を壊してしまうという落とし穴には私もよくハマります。 冗長なデータ構造(ここではmessage.top)をあえて導入している場合は特に注意が必要ですよね。 (ぱ)さんの掲示板は実用重視でシンプルに洗練されてますね。 お役に立てて何よりです。

>レスの練習です 練習の投稿ならテスト用掲示板 http://kmaebashi.com/bbs/list.php?boardid=testbbs の方でお願いします。 また、この掲示板では、HTMLソースの中に「REMOTEHOST_ID」という形で 投稿元のIPアドレスをハッシュした値を埋め込んでいるので、 同一人物が複数回投稿すると、ハンドル名を変えても、それが同一人物による 投稿であることが誰の目にもバレてしまうのでよろしく。

このところ客先に詰めていて帰りが遅かったため、対処が遅れましてすみません。 まさにそれが原因だったようです。修正しました。ご指摘ありがとうございます。 >以前、スレッドのトップに位置するメッセージの親IDが >NULLであるべきところが0になっていたのを修正した際、 こういう修正を行ったこと自体、きれいさっぱり忘れていたので、 「この掲示板は最初からスレッド表示をサポートしていたし、 　初期の投稿はそれこそ何度もスレッド表示で見たはずなんだけどなあ」 と悩んでいました。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=303 この対応のことですね。このときもご指摘いただきありがとうございました。

>というわけで早速テストです。 >変換指定子に「#」があるのを知りませんでした。_no > >#include <stdio.h> > >int main(void) { > int hoge = 4095; > printf("%#010x\n", hoge); > > return 0; >} > >ただ、「0x」の大文字小文字変換もそのうしろの >変換指定子「x」依存なのがちょっと嫌かも。 >もっとも普段からリテラルで0X00000FFFなどと書かないから >見慣れないというだけでしょうが・・・ レスの練習です

以前、スレッドのトップに位置するメッセージの親IDが NULLであるべきところが0になっていたのを修正した際、 本当にメッセージ[0]の子であった メッセージ[1]の親IDまでNULLにしてしまっていませんか？ 一度D/Bをご確認ください。

あのー、これは何でしょう… と見ているうち、「みつ」さんの意図はわかりませんが、ひとつこの掲示板の バグを見つけました。「みつ」さんの投稿から、 「この投稿を含むスレッドを表示」しても、ひとつの投稿しか表示されないようです。 今はまったく余裕がない状況なので、後ほど対処します。

>http://6029.teacup.com/scjv/bbs >ここなんかだと、完全に本人の投稿だとみなされて叱責されてますね。 いや、ぶっちゃけ本人の投稿ではないと決まったわけでもないと思いますがね。 ご本人がこれほど明確に否定している以上、あまり迂闊なことは言えませんが、 以下、事実だけを記します。 6/12 16:24 問題の書き込みがあった。「国際協力、掲示板」でGoogleして 　　　　　たどり着いた模様。 6/17 02:25 私から山本氏にメールを送る。当然そこにはうちの掲示板のURLを書いた。 6/17 06:38 例の書き込みと同じIPアドレスからふたたびアクセス。 また、http://www.ets-org.jp/contact.htmlを見ると、山本敏晴氏の メールアドレスは toshi＠zar.att.ne.jp であり、ドメインがspammerのそれと 一致しています。 もちろん、「spammerはたまたま山本敏晴氏と同じatt.ne.jpを使用していて、 たまたま5日ぶりに書き込みのその後が気になって掲示板を確認しに来た」という 可能性が否定できるものではありません。 しかし…

>仕様について簡単に説明します。 > >・発言内容は全て<pre>で囲まれます。ソースリストを載せるのに便利にするためです。 >　適当な位置で改行を入れてください。 >・でもやっぱり改行を入れ忘れる人もいるので、プレビュー表示をつけました。 >　確認してから「送信」をクリックしてください。 >・タグは全無効です。<font color="red">ほらね</font> >・クリッカブルURLの機能があります。 >　http://kmaebashi.com >　タグは無効なので<a>タグは書けません。 >・現状では削除機能がないので削除用パスワードは単なるお飾りです。 >・スレッド表示時、スレッドトップの「▼」をクリックすると、そのスレッドの >　発言を一覧表示します。 >・一画面あたりの表示数は以下の通りです。 >　- 日付順表示…30 >　- 日付順インデックス…50 >　- スレッド表示…20スレッド >

http://6029.teacup.com/scjv/bbs ここなんかだと、完全に本人の投稿だとみなされて叱責されてますね。 # 「善意」で名前を騙られちゃたまりません。 暇に任せて調べたら、以前にも同じようなことが行なわれてたようです。 http://www.google.co.jp/search?hl=ja&c2coff=1&rls=GGLD%2CGGLD%3A2004-51%2CGGLD%3Aja&q=%22%E5%B1%B1%E6%9C%AC%E6%95%8F%E6%99%B4%22+%22%E5%BE%85%E6%9C%9B%E3%81%AE%E7%AC%AC%E4%BA%8C%E5%BC%BE%22&lr= まぁ本人が「待望の第二弾、満を持して登場！」なんて書かないか(^^;)

返事が遅くなりましてすみません。 >本人以外が勝手にやってるなら消した方がいいし、 >たとえ本人がやってる場合も、掲示版spamの一種なので >消した方がいいんじゃないですかね。 > >問い合わせをした方がいいかどうかは迷うところですが。 問い合わせをするのであれば、少なくとも先方がこの書き込みを 確認するまでは削除できないと考えます。 この書き込みは、住所や電話番号なども含まれていますが、 もともと公開情報ですから急いで消さなければいけないものではないでしょう。 というわけで、(しばし迷いましたが)問い合わせメールを出しました。 回答によっては削除いたします。

>なので、まさかご本人がやっているはずはないと思うんですが… >問い合わせメールでも出してみますかね。 本人以外が勝手にやってるなら消した方がいいし、 たとえ本人がやってる場合も、掲示版spamの一種なので 消した方がいいんじゃないですかね。 問い合わせをした方がいいかどうかは迷うところですが。

さて。どうしたものでしょうか。 リンク先を見ると、「山本敏晴」という人は、何冊も本を出してたり、 講演会や写真展などの活動をされている方のようです。 そういう、社会的な立場もある人が、 　「無差別宣伝掲示板書き込み」 という迷惑行為を、実名出してやるとは、ちと私には信じがたいところがあります。 # 少なくとも私にとって、[640]の投稿は、よくあるアダルトサイトなどの広告書き込み # よりも数段不快です。 なので、まさかご本人がやっているはずはないと思うんですが… 問い合わせメールでも出してみますかね。

新刊の紹介です。 カンボジアの写真絵本を出版しました。 題名 「あなたのたいせつなものはなんですか？ 　・・・カンボジアより」 小学館刊 山本敏晴写真・文 定価１５００円プラス税 「あなたのたいせつなものは、なんですか？」 カンボジアの子供達にこの質問をし、 それを絵に描いてもらってきました。 また絵に描いてもらった後に、 必ずその子の家に行き、 その子の住んでいる家の写真、 家族の写真、 その村の風景写真などを撮影させてもらいました。 こうした取材を行っている理由は、 様々な国の様々な文化を紹介し、 世界の多様性を皆様にご覧頂きたいと思っているからです。 絵を描いてもらうだけではなく、 暮らしている様子を取材しているのは、 「これこれこういう社会背景に住んでいる人が、 　こういうものを大切だと思っている・・」 というその流れを理解して頂きたく思うからです。 今回、カンボジアの子供達が描いた「たいせつなもの」は、 多岐にわたっています。 明るい絵、暗い絵、よくわからないもの・・・。 そうした彼らの考え方とその生活している背景をご覧頂き、 様々な国に、様々な考え方の人達がいることを、 まずは見て頂ければ嬉しく思います。 そして、どんなに変わった考え方をしている人達にも、 必ず一緒に暮らしている家族がいて、 大切な友達がいることを知って頂ければ幸いです。 NPO法人　宇宙船地球号 Earth the Spaceship : ETS 事務局長　山本敏晴 108-0014 東京都港区芝5-20-7-504 電話　 03-5443-8969 ファックス 　03-6400-5949 http://www.ets-org.jp

>伊藤と申します。 はじめまして。 >yacc,lex以外にbison,flexというのがあり、 >そっちのほうが新しいと聞いた記憶ありなのですが、 >例の企画では、なぜyacc,lexなんでしょうか？？ bison とflexは、GNUプロジェクトが開発したyacc/lexの互換品ですね。 ですから、「bison/flexではなくyacc/lexを使った」というわけではなく、 基本的にはどちらも同じものです。 実際、crowbarのUNIX版はLinuxに付属していたyacc/lexでmakeしていますが、 Windows版はbison/flexを使用しています(配布しているMakefileを使う場合)。 bison/flexは、(GNUのやることなので当然のように)yacc/lexの上位互換に なっていて、いろいろ機能追加がなされています。しかし、今回の要件では 特に不要なので、それなら低機能なほうに合わせたほうが使える人も増えるのでは、 と考えて、UNIX版はyacc/lexでmakeしているわけです。

伊藤と申します。 yacc,lex以外にbison,flexというのがあり、 そっちのほうが新しいと聞いた記憶ありなのですが、 例の企画では、なぜyacc,lexなんでしょうか？？ 素朴な疑問です(^^

>すみません、そのように実行しても'外部シンボル_mainが未解決'というエラーが出ます。 このエラーメッセージは、その名前の関数なりグローバル変数なりの定義が 見つからないときに出ます。つまりmain関数がないということです。 main関数を書いてない(mainを書いた.cファイルをリンクしていない)か、 mainと書いたつもりでスペルを間違えたとかでしょう。

竹内です。 >はい。まったく問題ありませんので、ご自由にお使いください。 >わかりにくいところ等ありましたら、また掲示板の方にでも書き込んでください。 ありがとうございます。また書き込みさせて頂きます。 >何かと大変な状況かと思いますが、ご活躍を期待しております。 上記リンクにヨルダン日記等も書いておりますので、 お暇な時にでも見てみて下さい。

すみません、そのように実行しても'外部シンボル_mainが未解決'というエラーが出ます。

>エラー_外部シンボル'get_word'が未解決 リンクしていないからでしょう。 BorlandのCコンパイラを使っているのなら、たとえば bcc32 hoge.c とやればhoge.exeという実行形式ができますが、単語の出現頻度のプログラムは、 main.c, get_word.c, initialize.c, add_word.c, dump_word.c, finailze.cを リンクしてひとつの実行形式になります。個別に bcc32 main.c などとやっていれば当然上記のエラーが出ます。 bcc32 -owordmanage main.c get_word.c initialize.c add_word.c dump_word.c finalize.c のように書けば「wordmanage.exe」というひとつの実行形式ができるはずです。

管理人様、スペースお借りします。 C言語ポインタ完全制覇を熟読中ですが、単語の出現頻度を表示するプログラムに関してOSはXP、コンパイラはboland5.5を使っているのですが、本の記載されてる通り実行したところ、エラー_外部シンボル'get_word'が未解決(以下initialize,add_word,dump_word,finalizeも同様のエラーが出ます)というエラーができ実行できません。全く原因が分からないんですがどうかアドバイスをお願いします。

>始めまして。竹内敏彦と申します。 はじめまして。 >私は現在、国際協力機構のシニア海外ボランティアとして >中東の国ヨルダンのアル・フセイン大学(http://www.new.ahu.edu.jo/) >のコンピュータ・エンジニアリング＆IT学部にて学生の面倒を見ています。 遠いところから興味を持っていただきありがとうございます。 それにしてもヨルダンとは。うちのページも(日本語しかないくせに)ずいぶん グローバルになったものだと喜びつつも驚いております。 >とりあえず、HPからダウンロードさせて頂いたドキュメント、ソースコード等を、 >学生の学習参考資料として使わせて頂こうと思っています。 はい。まったく問題ありませんので、ご自由にお使いください。 わかりにくいところ等ありましたら、また掲示板の方にでも書き込んでください。 何かと大変な状況かと思いますが、ご活躍を期待しております。

始めまして。竹内敏彦と申します。 専門的な会話に突然割り込む様で申し訳ないのですが、 メールよりも掲示板へ、という記述がありましたので、 こちらへ投稿させて頂きました。 私は現在、国際協力機構のシニア海外ボランティアとして 中東の国ヨルダンのアル・フセイン大学(http://www.new.ahu.edu.jo/) のコンピュータ・エンジニアリング＆IT学部にて学生の面倒を見ています。 (まだ着任１ヶ月目で、言葉の問題等もあり、実際に教えるところまでは行っていません。) 学生の中に、プログラミング言語が作ってみたいという者がおり、 私自身に知識が無いので、学生に示す具定例があった方が良いと思い WEBで検索していたところ、前橋さんのページにたどり着きました。 crowbarのソースやドキュメントを参考にして、 私自身の勉強も兼ねて学生に紹介したいと思っています。 「プログラミング言語を作る」のページには、断り無く勝手に使って良い との記述がありましたが、念の為、一言お断わりしてからと思った次第です。 とりあえず、HPからダウンロードさせて頂いたドキュメント、ソースコード等を、 学生の学習参考資料として使わせて頂こうと思っています。 アラビア語しか話せない学生が多いので、私の翻訳・説明で どこまで解ってくれるか判りませんが、内容の理解が出来れば それを土台にして、新しい言語を作成出来たら良いな、とも考えております。 (理解するまで行けるかどうかも現時点では不安なのですが．．．。) 唐突にお邪魔して申し訳ありませんでした。では、失礼致します。

>条件の判断を言語の文法として導入せず、アプリケーション側で >判断してもらう場合、上に伝搬させたい例外の throw を忘れやす >そうな気もします。Java に慣れている人だと、finally 節の中 >では普通 throw を行わないので、特に危ないかも。 確かにそうですね。私自身「Java謎+落とし穴～」にそんなことを書いてました。 >欲しい機能のが OR 条件だけなら、catch の後に例外を羅列でき >るような文法にするんですかねえ… ひとまずORがあれば、そのcatch節の中で処理の振り分けはできそうなので (できるように作ればですが)、よさそうな手に思えます。 try { 　… } catch (HogeException, PiyoException: ex) { 　… } とかですかねえ…

> (1)例外の種類の区別を、言語レベルで提供するか、ライブラリ > 　レベルで提供するか、規約レベルの話にするか。 ゼロ除算や、浮動小数点関係のエラーのような例外は、言語処理系 の側で投げて欲しいので、完全にライブラリレベルだけってわけに はいきませんよね。 利用者側で例外の種類を拡張できないようにするのも不便そうだし、 結局、折衷策にせざるをえないような気がします。 > (2)例外の種類別catchを、言語レベルで提供するか、アプリケー > 　ションで判断してもらうか。 > > Javaのように、catchを例外の種類ごとに書く方法だと、OR条件 > (この例外とこの例外の時にはこうする)のようなものが書きにく > くて、なんとかならんもんかと常々思っているのですが… 条件の判断を言語の文法として導入せず、アプリケーション側で 判断してもらう場合、上に伝搬させたい例外の throw を忘れやす そうな気もします。Java に慣れている人だと、finally 節の中 では普通 throw を行わないので、特に危ないかも。 欲しい機能のが OR 条件だけなら、catch の後に例外を羅列でき るような文法にするんですかねえ…

[446] >JDK1.0ベースで記述されているためです。Javaは1.1になったときイベントの扱いが >一新され、古い流儀のプログラムでは、上記の警告が出るようになりました。 [447] >確認ですが、警告が出るだけで、コンパイルは通ってクラスファイルもできていて、 >しかるべきHTMLファイルをつければ動くわけですよね? >うちのWebページをネット上で見たときしか動かない、というわけではなく。 はい。警告が出るだけで、それ以外はすべてOKです。 大変な作業になるのかと思い、提供されるかもしれない修正版と比較しようと思っていましたが、Eclipse 3.1 の力(ちから)を借りて、問題となる部分を書き換えました。 お騒がせしました。 反省: 先ず自分でやれぇー。( 他の初心者は困っていないのだろうか。大きなお世話 ) 反省: 件名の扱いを JavaHouse で知りました。

書き忘れました。 確認ですが、警告が出るだけで、コンパイルは通ってクラスファイルもできていて、 しかるべきHTMLファイルをつければ動くわけですよね? うちのWebページをネット上で見たときしか動かない、というわけではなく。

>"注: Puzzle16Applet.java は推奨されない API を使用またはオーバーライドしています。" これが出るのは、「パズル16」はなにしろ7年も前に書いたものなので、 JDK1.0ベースで記述されているためです。Javaは1.1になったときイベントの扱いが 一新され、古い流儀のプログラムでは、上記の警告が出るようになりました。 >"警告"の出ないソースを提供していただけないでしょうか。 さすがに今更あのプログラムを直す気にはなれませんし、JDK1.0のプログラムと しては「正しい」わけですから、すみませんがこちらで修正版を提供する つもりはありません。ご了承ください。

>Java や C++ の例外の場合、例外の受け手は直接指定せず、受け手が >存在しない場合はトップレベルまで伝搬するわけですが、こういう風に >書くと、それとはだいぶ意味的に違うものになりそうです。 う。確かに私の書いたのだと、トップレベルまで伝搬しませんし、 例外の種類に関わらずcatch節に流れ込みますね。 例外の種類に関わらずcatchに流れ込むことについては、 「自分が知らない例外だったらcatch節で投げ直してよ」という方法で いけそうな気がしますが(ていうかクラス階層という概念がないcrowbarでは、 別途例外階層を定義する手段を提供しない限りそうなってしまいそうですが)、 catch節で例外を投げなおしたときには、上位がさらにtryで囲まれていれば そっちのtryのcatch節に流れ込むように思います(というかそう作らなければ 面白くない)。ただ、catch節で例外を投げなおすためには、上位のtry用の クロージャを持っていなければいけないので、何かと面倒そうではあります。 >また、例外の伝搬を >実装するために、クロージャのリストも管理することになるんじゃ >ないかな… こういうことですかね。 >でも Lisp みたいなマクロがないと、文法的に結構面倒くさそうなので、 >言語レベルで定義しちゃった方が、むしろ好ましいかもしれませんね。 ということで言語レベルで定義しようとせこせこ弄り回しているわけですが、 上に書いたように、crowbarにはクラス階層の概念がないので、どうやって catchしたものか考えているところです。 Common Lispの例外処理は、ちょっとぐぐって以下のページを見つけたのですが、 http://www.geocities.jp/m_hiroi/xyzzy_lisp/abclisp16.html やっぱり階層構造を(おそらくライブラリレベルで)実現していますね。 上に書いたような「なんでもcatchに流れ込むから、あとはアプリケーションで 投げ直してくれ」という戦略をとるにせよ、なんらかの方法で識別がつかないと そもそもアプリケーションでも区別がつきませんから、どうしようかと 考えているところです。 (1)例外の種類の区別を、言語レベルで提供するか、ライブラリレベルで提供するか、 　規約レベルの話にするか。 (2)例外の種類別catchを、言語レベルで提供するか、アプリケーションで 　判断してもらうか。 Javaのように、catchを例外の種類ごとに書く方法だと、OR条件(この例外と この例外の時にはこうする)のようなものが書きにくくて、なんとかならんもんかと 常々思っているのですが…

プログラマなページ -> 超手抜きJavaパズル -> パズル16 のソースを javac Puzzle16Applet.java した処、次のようなメッセージが出ました。 "注: Puzzle16Applet.java は推奨されない API を使用またはオーバーライドしています。" 更に、javac のメッセージを手がかりに詳細を見ると"警告"が三つありました。 "警告"の出ないソースを提供していただけないでしょうか。 ブラウザ上では作動しています。 以上