http://w.atwiki.jp/wiki9_susumu/ susumu @Wiki ja 2006-03-25T21:49:20+09:00 1143290960 https://w.atwiki.jp/wiki9_susumu/pages/36.html -[[トップページ/2006年03月25日/Eclipse Antコンパイルに失敗]] #blognavi 2006-03-25T21:49:20+09:00 1143290960 https://w.atwiki.jp/wiki9_susumu/pages/35.html #blognavi Eclipseでハマりました。無駄な1時間だった.. 以前はビルドできていたbuild.xmlが、compile taskで失敗するようになりました。思い当たる原因は、JDK1.4を一度アンインストールし、再度インストールしたこと。EclipseはJDK1.3で動かしているので影響無いだろう、と思っていたんですが。 Perhaps JAVA_HOME does not point to the JDK と言われたのでクラスパスの設定周りと格闘していたのですが、1時間使ってあきらめ、ググッたら即解決。fork="true"を追加するとうまくいきました。 [[井原のメモ>http://72.14.203.104/search?q=cache:_XkQXAhPU3MJ:memo.windy.ac/archives/000217.html+Perhaps+JAVA_HOME+does+not+point+to+the+JDK+Eclipse&hl=ja&gl=jp&ct=clnk&cd=1&lr=lang_ja&client=firefox-a]]から引用しますと、 ＜javac （うんたらかんたら） ＞ を ＜javac fork="true" （うんたらかんたら） ＞ のようにする。javacのとこにfork="true"を追加する。どうしてそうするとうまくいくのかはわかんない。 私もわかりません。Eclipseって、ときどき設定方法が分からずに、時間を奪うことがあるんですよね。 #right{ カテゴリ: &#x5b;[[プログラミング>トップページ/カテゴリ/プログラミング]]&#x5d; - &trackback() - 2006年03月25日 21:42:50 } #comment(nostyle,nsize8,size30) #blognavi[[リンク名>URL]] 2006-03-25T21:52:24+09:00 1143291144 https://w.atwiki.jp/wiki9_susumu/pages/34.html #blognavi NextTrainデータをXML化すると、サーバやPC、携帯間で時刻表のやりとりが簡単になるよな、とぼんやりと思っていたのですが、「Web2.0が導く知識産業社会」にもっとしっかりと書いてありました。 http://hotwired.goo.ne.jp/original/fujimoto/060314/index.html 時刻表データの形式をXMLとし、プロトコルもWebServiceベースに決めておけば、あとは各電鉄、バス会社がそれにしたがってオープンにするだけ。日曜プログラマがクライアントを書いて改善していけば十分ハッピーな世界になるはず。 各電鉄のダイヤグラムデータから時刻表は簡単に生成できますよね？　そのデータの信頼性をどのように保障するか、というところが問題として残りそうですが。 #right{ カテゴリ: &#x5b;[[NextTrain>トップページ/カテゴリ/NextTrain]]&#x5d; - &trackback() - 2006年03月23日 00:13:33 } #blognavi 2006-03-23T00:13:48+09:00 1143040428 https://w.atwiki.jp/wiki9_susumu/pages/33.html -[[トップページ/2006年03月23日/公共財としての時刻表]] -[[トップページ/2006年03月23日/公共財として時刻表]] #blognavi 2006-03-23T00:12:05+09:00 1143040325 https://w.atwiki.jp/wiki9_susumu/pages/31.html -[[トップページ/2006年03月21日/NextTrain形式のXML化]] #blognavi 2006-03-21T23:30:32+09:00 1142951432 https://w.atwiki.jp/wiki9_susumu/pages/30.html #blognavi NextTrainのデータ形式は便利なのですが、いくつか欠点があると思ってます。 - 「駅名」「行き先」などの情報を、プログラムが認識できない。 - 急行、特急など、頻出するアトリビュート集合を、共通規約として定義しておきたい。 - 「アトリビュート」の有効範囲が曖昧。現在のところ、ファイル内のある行で宣言したアトリビュートは、その行以降有効であり、もし同一のアルファベット（キー）に対して有効なアトリビュートが再定義された場合、それ以降再定義が有効になる、という実装が多いようです。 - アトリビュートの種類が52種類に制限されている。 - 文字コードが事実上Shift JISになっている。 -- Unicodeに対応しておけば、フランス語、ドイツ語、中国語などもいけそう。 このあたりを踏まえ、NextTrain形式をXML化すると嬉しいのではないかと考えています。最近仕事の関係でRDFについても読み漁っているのですが、RDFで表現しても面白いかも。 例えば、こんな感じでしょうか。 http://newsoc.homeip.net/vnt/tokyo2atami_ver2.xml バイト数は増えてしまいますが。 #right{ カテゴリ: &#x5b;[[NextTrain>トップページ/カテゴリ/NextTrain]]&#x5d; - &trackback() - 2006年03月21日 23:16:20 } #comment(nostyle,nsize8,size30) #blognavi 2006-03-21T23:44:31+09:00 1142952271 https://w.atwiki.jp/wiki9_susumu/pages/29.html -[[トップページ/2006年03月16日/MIDP2.0のキーコード処理]] #blognavi 2006-03-16T23:31:11+09:00 1142519471 https://w.atwiki.jp/wiki9_susumu/pages/28.html #blognavi [[vNextTrain]]の3G対応は、残念ながらまだ完了しておりません。 - (1)上下キーが効かない - (2)AM/PM自動表示などのメニューを選択できない といった不具合が報告されております。 (1)については、昔似た不具合を見たことがありました。 Canvas.keyReleased(int keyCode)に渡ってくるkeyCodeは、KEY_NUM1,KEY_NUM2といった数字キーやKEY_STAR(*)といった文字キーを示すキーコードです。ただし、上下キーやFキーなどの一部のキーコードとして評価するためには、int gameCode= getGameAction(keyCode)などとしてコードを変換してやる必要があります。この変換処理を忘れていると、機種によっては上下キーが効かなかったりするわけですが、そのときは偶然2G機(多分V602SH)では変換処理を忘れていてもOKで、3G機(多分901SH)では忘れていては駄目だったわけです。 今回のvNextTrainもこれが原因かと思っていたのですが、どうも違うようです。現在悩み中。 #right{ カテゴリ: &#x5b;[[NextTrain>トップページ/カテゴリ/NextTrain]]&#x5d; - &trackback() - 2006年03月16日 23:21:28 } #comment(nostyle,nsize8,size30) #blognavi 2006-03-16T23:34:54+09:00 1142519694 https://w.atwiki.jp/wiki9_susumu/pages/27.html -[[トップページ/2006年03月14日/JADの改行コード]] #blognavi 2006-03-15T00:12:45+09:00 1142349165 https://w.atwiki.jp/wiki9_susumu/pages/26.html #blognavi 3G対応不具合の原因は予想通りJADファイルに関係していましたが、私の予想とはぜんぜん違うものでした。例えばJADファイルの改行コードを疑ったりして、調査に時間をかけてしまっておりました。 その調査の途中、JADとMANIFESTの改行コードがLFでないと、V702NKでインストールに失敗する、ということを知りました。他の機種ではCR+LFでも良いらしいのですが、V702NKでは制限されるそうです。V702NKだけ見捨てるわけにもいきませんので、JADとMANIFESTをの改行コードをLFに統一することにしました。 [[vNextTrain]]のために用意したJADとMANIFESTは、もともとLFになっています。MANIFESTはそのままJARに取り込まれるのでOK。JADファイルは開発環境がJarサイズをJADファイルに追記するときに、なぜか改行コードがCR+LFになってしまいます。私はEclipse+JSCL 1.2.2 Pluginを使ってVアプリを開発しています。この環境でVアプリプロジェクトを作成すると、同時にantのビルドファイルbuild.xmlが作成されます。このbuild.xmlが起動するupdatejad(Jarサイズを追記するタスク)uがLFをCR+LFに変更してしまっていました。これは、updatejadの実装が原因というより、JREのデフォルト改行コードの問題だと思われます。 そこで、Jarサイズの追記と同時にCR+LFになってしまったJADを、自動的にLFに戻すことを試みました。updatejadタスク後の、archiveタスクにfixcrlfを追記して、以下のようにします。 <target name="archive"> <jar destfile="${bin}/${jarname}.jar" manifest="./MANIFEST.MF"> <fileset dir="${preverified}" /> <fileset dir="${res}" /> <fileset dir="${nexttrain_core}/resource/" includes="**/*.png" /> </jar> <copy file="./ 2006-03-15T00:17:25+09:00 1142349445