From machino ＠ yendot.org Thu Sep 2 14:04:18 2004 From: machino ＠ yendot.org (Satoshi MACHINO) Date: Thu, 2 Sep 2004 14:04:18 +0900 Subject: [Musashi-devel 72] Re: MUSASHI-1.0.4 In-Reply-To: <200408310208.AA01868@hayabusa.adm.osaka-sandai.ac.jp> References: <200408310208.AA01868@hayabusa.adm.osaka-sandai.ac.jp> Message-ID: <20040902140418.5a7da8fa.machino@yendot.org> まちの です。 On Tue, 31 Aug 2004 11:08:31 +0900 Yukinobu Hamuro wrote: > ご無沙汰しております。 こちらこそ、最近は何も動けておりません。 本業の方もLinux/UNIXとはかなりかけ離れた世界であたふたしております。 > ご教授いただきたいことがあります。 > そろそろMUSASHI-CORE-1.0.4をリリースしようと思っているのですが、 > ２つの問題が出てきています。 私で対応できそうな話ではない気がしますが(笑 > １．コマンドラインの引数処理にgetopt_longを用い、"--xxx"といった引数にも対応するように変更しました。 > しかしながら、Solarisではそのような関数は標準ライブラリに登録されておらず困っております。 > またネットで見るとFreeBSDにも実装されていないようです。 > 何かよい方法はないでしょうか？ Solarisとかはgetoptしかないんでしたっけ、たしか... 今previewのSolaris10になれば実装されるんですよね > Solarisユーザの方 答えになっていませんが、 getoptをベースに拡張した関数を実装するかSolarisではgetoptしか使わない(使えない)ようにする のがまともな方法でしょうね。 ググるといろいろ見付かりますが、実装まで踏み込んだモノはないですね... debianのdancerこと上川さん作のdshがsparcへの移植で上記の実装を 取り込んでいるようです。 http://mikilab.doshisha.ac.jp/dia/research/person/dancer/dancer-20020619.html#dshsolaris sourceの確認はしていませんが... dshに関しては http://www.netfort.gr.jp/~dancer/software/dsh.html を御覧ください。 何かの参考になるかも知れません。 > マルチプラットフォームへの対応は、1.0.3の時もそうでしたが、非常に骨の折れる仕事で、参っております。。。 GNUのツールを前提に進めるならば良いのですが、 Solaris, HP-UX, AIX, Cygwinとかまで言い出すと 標準関数ですら互換性は怪しくなりますね。 どこまでマルチプラットホームに対応するのかは 判断に難しい問題だと思います。 > ２．こちらの開発環境をRHL9.0に変えたことにより、configure.inを変更しなければなりませんでした(autotoolのバージョンUPによるレガシーな文法の変更)。 > しかしながら、少なくともCygwinでは素直にはコンパイルできなくなりました。ただし./configureの前にautoreconfを実行すれば、いくつかのWarningは出るものの、 > コンパイルはOKのようです。 > 現在のバージョンを添付します。 > Vineではどうでしょうか？ 済みません。 CVSのレポジトリはこまめにupdateしておりましたが makeまでは確認していませんでした。 一度、確認してみます。 後日、報告させてもらいます。 -- まちの machino ＠ vinelinux.org machino ＠ yendot.org GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32 From machino ＠ yendot.org Sat Sep 4 14:41:44 2004 From: machino ＠ yendot.org (Satoshi MACHINO) Date: Sat, 4 Sep 2004 14:41:44 +0900 Subject: [Musashi-devel 73] Re: MUSASHI-1.0.4 In-Reply-To: <20040902140418.5a7da8fa.machino@yendot.org> References: <200408310208.AA01868@hayabusa.adm.osaka-sandai.ac.jp> <20040902140418.5a7da8fa.machino@yendot.org> Message-ID: <20040904144144.2d8d7436.machino@yendot.org> まちの です。 On Thu, 2 Sep 2004 14:04:18 +0900 Satoshi MACHINO wrote: > > ２．こちらの開発環境をRHL9.0に変えたことにより、configure.inを変更しなければなりませんでした(autotoolのバージョンUPによるレガシーな文法の変更)。 > > しかしながら、少なくともCygwinでは素直にはコンパイルできなくなりました。ただし./configureの前にautoreconfを実行すれば、いくつかのWarningは出るものの、 > > コンパイルはOKのようです。 > > 現在のバージョンを添付します。 > > Vineではどうでしょうか？ > > 済みません。 > CVSのレポジトリはこまめにupdateしておりましたが > makeまでは確認していませんでした。 > 一度、確認してみます。 > 後日、報告させてもらいます。 添付されていた(MLでsource.tar.gz添付には驚いた)モノでは VineSeed/Vine3.0では問題なくbuild出来ている様です。 configureとmakeのlogを付けておきます。 一度、パッケージの方も更新しましょうか? 適当なpreの時点で指示があれば用意しますが... 特に要望がなければVine3.0用になりますが。 -- まちの machino ＠ vinelinux.org machino ＠ yendot.org GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: musashi-1.0.4-pre2-configure.log.bz2 型: application/x-bzip2 サイズ: 1342 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/musashi-devel/attachments/20040904/57f08828/attachment.bin -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: musashi-1.0.4-pre2-make.log.bz2 型: application/x-bzip2 サイズ: 4490 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/musashi-devel/attachments/20040904/57f08828/attachment-0001.bin From hamuro ＠ adm.osaka-sandai.ac.jp Sat Sep 4 15:14:44 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Sat, 04 Sep 2004 15:14:44 +0900 Subject: [Musashi-devel 74] Re: MUSASHI-1.0.4 In-Reply-To: <20040902140418.5a7da8fa.machino@yendot.org> References: <20040902140418.5a7da8fa.machino@yendot.org> Message-ID: <200409040614.AA01910@hayabusa.adm.osaka-sandai.ac.jp> まちのさん、羽室です。 >Solarisとかはgetoptしかないんでしたっけ、たしか... はい、getopt_long関数はインプリメントされていないようです。 >答えになっていませんが、 >getoptをベースに拡張した関数を実装するかSolarisではgetoptしか使わない(使えない)ようにする >のがまともな方法でしょうね。 >ググるといろいろ見付かりますが、実装まで踏み込んだモノはないですね... >debianのdancerこと上川さん作のdshがsparcへの移植で上記の実装を >取り込んでいるようです。 > http://mikilab.doshisha.ac.jp/dia/research/person/dancer/dancer-20020619.html#dshsolaris なるほど。 いずれにせよ時間がかかりそうですね。 >sourceの確認はしていませんが... >dshに関しては > http://www.netfort.gr.jp/~dancer/software/dsh.html >を御覧ください。 >何かの参考になるかも知れません。 情報ありがとうございます。 >GNUのツールを前提に進めるならば良いのですが、 >Solaris, HP-UX, AIX, Cygwinとかまで言い出すと >標準関数ですら互換性は怪しくなりますね。 >どこまでマルチプラットホームに対応するのかは >判断に難しい問題だと思います。 はい。1.0.3のときは頑張りすぎたように思います。 とりあえず開発者としては「RedHat9.0でのみ検証済」としてリリースしようと思います。 マルチプラットフォーム対応は、どなたか他の方に手伝っていただけるようになることを願いながら。。。 まったく手が足りていない中では仕方ないかと考えております（一人ではとても無理だと今更ながら気づかされました）。。。 ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From hamuro ＠ adm.osaka-sandai.ac.jp Sat Sep 4 15:22:58 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Sat, 04 Sep 2004 15:22:58 +0900 Subject: [Musashi-devel 75] Re: MUSASHI-1.0.4 In-Reply-To: <20040904144144.2d8d7436.machino@yendot.org> References: <20040904144144.2d8d7436.machino@yendot.org> Message-ID: <200409040622.AA01911@hayabusa.adm.osaka-sandai.ac.jp> まちのさん、羽室です。 >添付されていた(MLでsource.tar.gz添付には驚いた)モノでは 通常、そのようなことはしないのですね。 >VineSeed/Vine3.0では問題なくbuild出来ている様です。 >configureとmakeのlogを付けておきます。 ご検証ありがとうございます。 >一度、パッケージの方も更新しましょうか? >適当なpreの時点で指示があれば用意しますが... >特に要望がなければVine3.0用になりますが。 来週の前半に1.0.4-pre2の公式(？)リリースをしようと思います。 その際はよろしくお願いします。 ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From machino ＠ yendot.org Sat Sep 4 15:44:15 2004 From: machino ＠ yendot.org (Satoshi MACHINO) Date: Sat, 4 Sep 2004 15:44:15 +0900 Subject: [Musashi-devel 76] Re: MUSASHI-1.0.4 In-Reply-To: <200409040622.AA01911@hayabusa.adm.osaka-sandai.ac.jp> References: <20040904144144.2d8d7436.machino@yendot.org> <200409040622.AA01911@hayabusa.adm.osaka-sandai.ac.jp> Message-ID: <20040904154415.36d461ff.machino@yendot.org> まちの です。 On Sat, 04 Sep 2004 15:22:58 +0900 Yukinobu Hamuro wrote: > >添付されていた(MLでsource.tar.gz添付には驚いた)モノでは > 通常、そのようなことはしないのですね。 ここもそうですがML運用上の制限で添付ファイルを含めた容量の 制限があります。 (このMLも管理者以外だと40KB以下に制限されているようです) ですので、URL等のリンク先だけ示すか 必要な人にDMする場合が多いのではないかと思います。 # あくまでMLのポリシー次第なのでMUSTであるという事ではありません # 非公開なMLではなんでもありで運用する場合もあります。 > 来週の前半に1.0.4-pre2の公式(？)リリースをしようと思います。 > その際はよろしくお願いします。 リリース準備が出来た時点で連絡(DMでも)戴ければ sf.jpにリリースからあまりタイムラグなくパッケージの 用意を出来るようにしてみます。 羽室先生のところにRH9の開発環境に関して よろしければ、教えてください。 # RH9はfedora Projectのsecurity fix.まで含めたモノですか? # それともRedhatの分まででしょうか? 間に合えばVMware上に同じ環境を用意したいと思います。 -- まちの machino ＠ vinelinux.org machino ＠ yendot.org GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32 From hamuro ＠ adm.osaka-sandai.ac.jp Sat Sep 4 17:08:58 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Sat, 04 Sep 2004 17:08:58 +0900 Subject: [Musashi-devel 77] Re: MUSASHI-1.0.4 In-Reply-To: <20040904154415.36d461ff.machino@yendot.org> References: <20040904154415.36d461ff.machino@yendot.org> Message-ID: <200409040808.AA01913@hayabusa.adm.osaka-sandai.ac.jp> まちのさん、羽室です。 >ここもそうですがML運用上の制限で添付ファイルを含めた容量の >制限があります。 >(このMLも管理者以外だと40KB以下に制限されているようです) >ですので、URL等のリンク先だけ示すか >必要な人にDMする場合が多いのではないかと思います。 ># あくまでMLのポリシー次第なのでMUSTであるという事ではありません ># 非公開なMLではなんでもありで運用する場合もあります。 なるほど。 次回からはsfの方にUPするようにします。 >リリース準備が出来た時点で連絡(DMでも)戴ければ >sf.jpにリリースからあまりタイムラグなくパッケージの >用意を出来るようにしてみます。 ありがとうございます。 >羽室先生のところにRH9の開発環境に関して >よろしければ、教えてください。 ># RH9はfedora Projectのsecurity fix.まで含めたモノですか? ># それともRedhatの分まででしょうか? すみません。 そのあたりのこと全く分からずに使っております。 どのようにすれば分かるのでしょうか？ とりあえずdmesgのトップ行のメッセージを以下に示します。 Linux version 2.4.20-8 (bhcompile ＠ porky.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003 >間に合えばVMware上に同じ環境を用意したいと思います。 ありがとうございます。 いろいろと情報ありがとうございます。 いつもながら本当に助かります。 ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From hamuro ＠ adm.osaka-sandai.ac.jp Mon Sep 6 18:20:51 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Mon, 06 Sep 2004 18:20:51 +0900 Subject: [Musashi-devel 78] =?iso-2022-jp?b?UmU6IEdyYXBoTUwgGyRCPSQbKEI=?= =?iso-2022-jp?b?GyRCQDUbKEI=?= In-Reply-To: <200408270457.i7R4vgX05744@Sp-Moto01.ar.sanken.osaka-u.ac.jp> References: <200408270457.i7R4vgX05744@Sp-Moto01.ar.sanken.osaka-u.ac.jp> Message-ID: <200409060920.AA01922@hayabusa.adm.osaka-sandai.ac.jp> 光永君、羽室です。 返信が遅れまして申し訳ありません。 別件で全く時間が取れませんでした。 送っていただいたソースを確認しました。 ワークファイル、標準入出力、メッセージ出力、いずれの問題もOKでした。 ただ、依然添付しましたデータにてエラー(end by signal)が出るようです。 いずれもEdgeにラベルがないものです。 ご確認願います。 Yuki Mitsunaga さんは書きました: >光永です > >GraphML若干修正しましたので送ります > >修正点は > >optypeでlabelを選択できるように変更 >Graph要素ないにGraphLabel要素を記述できるように変更 >GraphLabelの定義を記述 > >以上の3点です > >不足してる点などみつかりましたらご指摘よろしくおねがいします > >Takashi Washio wrote: > >> 光永君 >> >> >修正版のGraphMLのXMLSchemaを添付しておきます >> >基本はPMMLの定義を採用して不必要そうなものを削っています >> >各要素、属性の説明などは下のURLを参照下さい >> >DataDictionaryについては左からDataDictionaryを選んで参照下さい >> > >> >http://www.dmg.org/v2-1/Header.html >> > >> >現状ではGraphLabelについては追加していない状態です >> > >> >PMMLにModelStatsという統計情報などを記述する要素がありました >> >GraphMLにもとりあえずStatisticsという要素をいれていますが、これは必要でしょうか？ >> >現在のところ要素Statisticsの定義についての記述はされていません >> > >> >_______________________________________________ >> >Musashi-devel mailing list >> >Musashi-devel ＠ lists.sourceforge.jp >> >http://lists.sourceforge.jp/mailman/listinfo/musashi-devel >> >> すみません。私は混乱してるのですが、上記のGraphMLの定義ファイルは、 >> 下のメールに関するものでしょうか。時間的には上記の方が下のメールより >> 早いのですが。下はもう対応が済んでいるということでしょうか？ >> >> 鷲尾 >> >> >おそらく羽室先生がおっしゃっているのは現状のGraphMLのXMLSchemaに >> >DataDictionaryやHeaderの定義の記述がないと言うことだと思います。 >> >上の要素についてはPMMLではいろんなモデルについて共通で用いられているタグです >> >ので >> >GraphPMMLのXMLSchemaを書く際には省略してたのですが >> >GraphMLは別のものであるということを考えるとそちらの記述も追加しておいたほう >> >がよいですね。 >> >こちらは修正が済み次第またMLに投げたいと思います。 >> >> >> _______________________________________________ >> Musashi-devel mailing list >> Musashi-devel ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/musashi-devel >______________________________________________________________________ > >_______________________________________________ >Musashi-devel mailing list >Musashi-devel ＠ lists.sourceforge.jp >http://lists.sourceforge.jp/mailman/listinfo/musashi-devel ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: xt2gml02.xml 型: application/octet-stream サイズ: 1915 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/musashi-devel/attachments/20040906/ffa861ac/attachment.obj -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: xt2gml03.xml 型: application/octet-stream サイズ: 1351 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/musashi-devel/attachments/20040906/ffa861ac/attachment-0001.obj From hamuro ＠ adm.osaka-sandai.ac.jp Mon Sep 6 21:30:54 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Mon, 06 Sep 2004 21:30:54 +0900 Subject: [Musashi-devel 79] =?iso-2022-jp?b?GyRCPEFMZBsoQg==?= Message-ID: <200409061230.AA01925@hayabusa.adm.osaka-sandai.ac.jp> まちのさん、羽室です。 こんにちは。 パッケージのリリースについて教えていただきたいことがあります。 これまで、パッケージの正式リリースの前にpreXXというパッケージをUPしていました。 その目的は主に、各種プラットフォームにおけるコンパイルチェックおよび動作チェックでした。 このような方法は一般的なのでしょうか？ というのも、CVSがあるので、それをインストールしてもらってチェックすれば事足りるかと考えました。 （だんだんと、「ずぼら」になりつつあります。。。） 今の考えでは、 CVSのアナウンス→動作確認→修正→CVSに反映 →このサイクルを繰り返し、落ち着けばtar.gzの正式リリース といった感じを考えています。 rpmのパッケージングはその後でも良いかと思っておりますがどうでしょうか？ ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From machino ＠ yendot.org Tue Sep 7 00:32:49 2004 From: machino ＠ yendot.org (Satoshi MACHINO) Date: Tue, 7 Sep 2004 00:32:49 +0900 Subject: [Musashi-devel 80] =?iso-2022-jp?b?UmU6IBskQjxBTGQbKEI=?= In-Reply-To: <200409061230.AA01925@hayabusa.adm.osaka-sandai.ac.jp> References: <200409061230.AA01925@hayabusa.adm.osaka-sandai.ac.jp> Message-ID: <20040907003249.200f4e32.machino@yendot.org> まちの です。 こちらは見落としていました。 On Mon, 06 Sep 2004 21:30:54 +0900 Yukinobu Hamuro wrote: > これまで、パッケージの正式リリースの前にpreXXというパッケージをUPしていました。 > その目的は主に、各種プラットフォームにおけるコンパイルチェックおよび動作チェックでした。 > このような方法は一般的なのでしょうか？ preXXとするか、alpha-->betaとするか (stable version).99のように(例えばXやlinux kernel)するかは いろいろありますが、なんらかの形でリリース前にテスト版を 出すのは一般的です。 > というのも、CVSがあるので、それをインストールしてもらってチェックすれば事足りるかと考えました。 もちろんこれでも結果は同じなのですが、 どちらかというとcvsからcheckoutする人は 開発の環境に慣れた人で、当然checkout後に 自分でautotoolsを使ったりする事が自力で出来る人。 cvsやsubversionなどで不特定のメンバーで共同開発する環境に 慣れていない人には、それはそれでつまずく原因にもなります。 tarballで提供されていれば、少なくともconfigure;make;make installで かたが付く事が多いですから... なので言ってしまえば開発の方針次第ではないかと思います。 cvsだけの方が開発者の手間はかかりませんし、 コミッターが多ければそれで十分かも知れません。 ただし若干(一部にはかなり?)ハードルが上がります。 tarballを用意する方式は 手間がかかる半面、テストユーザには使いやすいメリットがあります。 MUSASHIの場合はどうでしょうかねぇ? コミッターは多くなさそうですが、 実作業が羽室先生だけに負荷がかかっているようですし。 > 今の考えでは、 > CVSのアナウンス→動作確認→修正→CVSに反映 > →このサイクルを繰り返し、落ち着けばtar.gzの正式リリース > といった感じを考えています。 妥協案として、テストの初期段階では cvsから直接checkoutしてもらい、 リリースが本当に近付いた時点でβ版をtarballで1,2回だして リリースに持っていくという事もできるのではないでしょうか? たぶんこうすると多くの人はβがでるまでチェックしないという事も 起こり得ますが... source的にはもう十分βレベルなのかも知れませんけども。 # 私は個人的にどちらでも構いません > rpmのパッケージングはその後でも良いかと思っておりますがどうでしょうか？ 私の作業はこの方が助かりますが、 なんらかのパッケージがないとテストできないとかいう方は -devel MLにはいないと考えて良いでしょうか? # -user MLならそうも言えないでしょうから... sourceからbuildする方法やバイナリの構成が大きく変わらない場合は rpmパッケージにしちゃった方が更新や削除が楽なので 普通は自製パッケージにしちゃう方が多いのですが。 テストとはいえ公開用だと、それなりにパッケージのチェックも要りますので 回数は少ない方が作る方は助かります。 前回の時はRPMのパッケージの数を増やす事に主眼を置いて いろいろなディストリビューション用を用意しましたが 今回は以前から言っているように提供するパッケージは 少し絞ろうと思っています。 -- まちの machino ＠ vinelinux.org machino ＠ yendot.org GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32 From hamuro ＠ adm.osaka-sandai.ac.jp Tue Sep 7 11:11:04 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Tue, 07 Sep 2004 11:11:04 +0900 Subject: [Musashi-devel 81] =?iso-2022-jp?b?UmU6IBskQjxBTGQbKEI=?= In-Reply-To: <20040907003249.200f4e32.machino@yendot.org> References: <20040907003249.200f4e32.machino@yendot.org> Message-ID: <200409070211.AA01931@hayabusa.adm.osaka-sandai.ac.jp> まちのさん、 >> これまで、パッケージの正式リリースの前にpreXXというパッケージをUPしていました。 >> その目的は主に、各種プラットフォームにおけるコンパイルチェックおよび動作チェックでした。 >> このような方法は一般的なのでしょうか？ > >preXXとするか、alpha-->betaとするか >(stable version).99のように(例えばXやlinux kernel)するかは >いろいろありますが、なんらかの形でリリース前にテスト版を >出すのは一般的です。 なるほど。 >> というのも、CVSがあるので、それをインストールしてもらってチェックすれば事足りるかと考えました。 > >もちろんこれでも結果は同じなのですが、 >どちらかというとcvsからcheckoutする人は >開発の環境に慣れた人で、当然checkout後に >自分でautotoolsを使ったりする事が自力で出来る人。 > >cvsやsubversionなどで不特定のメンバーで共同開発する環境に >慣れていない人には、それはそれでつまずく原因にもなります。 >tarballで提供されていれば、少なくともconfigure;make;make installで >かたが付く事が多いですから... > >なので言ってしまえば開発の方針次第ではないかと思います。 >cvsだけの方が開発者の手間はかかりませんし、 >コミッターが多ければそれで十分かも知れません。 >ただし若干(一部にはかなり?)ハードルが上がります。 > >tarballを用意する方式は >手間がかかる半面、テストユーザには使いやすいメリットがあります。 CVSの方にはconfigureも含めておりますので、通常のコンパイルと全く同様に対処できると考えています。 またsourceforgeでは、tarballへのリンクもありますのでcvsでcoする必要もありません。 >MUSASHIの場合はどうでしょうかねぇ? >コミッターは多くなさそうですが、 はい、特にdevelMLは10名以下ですね。 usersにも投げてみようと思います。 >実作業が羽室先生だけに負荷がかかっているようですし。 はい、そこがつらいところです。 しかし、まちのさんには色々とご指導いただき感謝しております。 >> 今の考えでは、 >> CVSのアナウンス→動作確認→修正→CVSに反映 >> →このサイクルを繰り返し、落ち着けばtar.gzの正式リリース >> といった感じを考えています。 > >妥協案として、テストの初期段階では >cvsから直接checkoutしてもらい、 >リリースが本当に近付いた時点でβ版をtarballで1,2回だして >リリースに持っていくという事もできるのではないでしょうか? そうですね。 前でも述べましたが、cvsでもtarballをダウンロードできるので それでどうでしょうか？ >> rpmのパッケージングはその後でも良いかと思っておりますがどうでしょうか？ > >私の作業はこの方が助かりますが、 >なんらかのパッケージがないとテストできないとかいう方は >-devel MLにはいないと考えて良いでしょうか? ># -user MLならそうも言えないでしょうから... 問題ないと思われます。 >sourceからbuildする方法やバイナリの構成が大きく変わらない場合は >rpmパッケージにしちゃった方が更新や削除が楽なので >普通は自製パッケージにしちゃう方が多いのですが。 >テストとはいえ公開用だと、それなりにパッケージのチェックも要りますので >回数は少ない方が作る方は助かります。 そうですね。 tarballが落ち着いたときに、パッケージのチェックという流れでいきましょう。 >前回の時はRPMのパッケージの数を増やす事に主眼を置いて >いろいろなディストリビューション用を用意しましたが >今回は以前から言っているように提供するパッケージは >少し絞ろうと思っています。 はい、了解いたしました。 ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From machino ＠ yendot.org Tue Sep 7 21:17:40 2004 From: machino ＠ yendot.org (Satoshi MACHINO) Date: Tue, 7 Sep 2004 21:17:40 +0900 Subject: [Musashi-devel 82] =?iso-2022-jp?b?UmU6IBskQjxBTGQbKEI=?= In-Reply-To: <200409070211.AA01931@hayabusa.adm.osaka-sandai.ac.jp> References: <20040907003249.200f4e32.machino@yendot.org> <200409070211.AA01931@hayabusa.adm.osaka-sandai.ac.jp> Message-ID: <20040907211740.46bd5c3f.machino@yendot.org> まちの です。 On Tue, 07 Sep 2004 11:11:04 +0900 Yukinobu Hamuro wrote: > CVSの方にはconfigureも含めておりますので、通常のコンパイルと全く同様に対処できると考えています。 > またsourceforgeでは、tarballへのリンクもありますのでcvsでcoする必要もありません。 そうですね。 であれば特に問題ないのではないかと思います。 > >実作業が羽室先生だけに負荷がかかっているようですし。 > はい、そこがつらいところです。 > しかし、まちのさんには色々とご指導いただき感謝しております。 口先だけしか出していないので 適当にバイアスかけて流してください(笑 > 前でも述べましたが、cvsでもtarballをダウンロードできるので > それでどうでしょうか？ それで良いのでは無いでしょうか。 > tarballが落ち着いたときに、パッケージのチェックという流れでいきましょう。 はい、そうしましょう。 -- まちの machino ＠ vinelinux.org machino ＠ yendot.org GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32 From fuja2 ＠ bj8.so-net.ne.jp Wed Sep 8 01:43:51 2004 From: fuja2 ＠ bj8.so-net.ne.jp (kazuo sonobe) Date: Wed, 8 Sep 2004 01:43:51 +0900 Subject: [Musashi-devel 83] =?iso-2022-jp?b?Z3JhcGhNTBskQk1RST08KCU9GyhC?= =?iso-2022-jp?b?GyRCJVUlSDRYTyIbKEI=?= Message-ID: <20040908014351.5d3019dd.fuja2@bj8.so-net.ne.jp> お久しぶりです。そのべ＠こまがわ　です。 ちょっと間が空いてしまい生存確認的なメールになってしまいました。 graphML用表示ソフト関連は、作業内容としては変わってないのですが、 ・Qt上で使えるグラフ構造描画クラスの整備 にも力点を置いて進めてるところです。実は前に教えていただいた graphVizの影響をかなり受けました。 graphVizにはグラフ描画用のクラスライブラリのようなもの（Ｃ実装） があって非常に良く出来ていますが、アプリケーションを作成するの に便利なQtやGtkと組み合わせては使えないだろうと考えてます。 （逆にgraphVizはXがあれば動くようなので、選択の問題とも言えますが）。 Qt上にクラスライブラリがまとまってれば、グラフ構造に関連し多少 複雑なアプリケーションを作りたい人にとって、役に立つと期待したい です。 あと、上の話が整理できたら、GUIアプリを作ってくれそうな人に声を かけてみようと思ってます（かけてみないとわかりませんが）。 musashiの魅力はすぐに感じてもらえると思いますが、GUIアプリに 対する面倒な印象をなんとかするほうが大変かもしれません。 graphMLについては、実はまだ何が表せて何が表せないのか（私の立場 からすると何が表示できなければいけないのか）がちゃんとはわかって ないのですが、もう少ししたら質問させてもらうことになると思います。 -- ／　kazuo sonobe ☆ ／　信号処理技術の解説ページ「蜂波の眼」作成中 ☆ 　　 From washio ＠ ar.sanken.osaka-u.ac.jp Wed Sep 8 14:27:14 2004 From: washio ＠ ar.sanken.osaka-u.ac.jp (Takashi Washio) Date: Wed, 08 Sep 2004 14:27:14 +0900 Subject: [Musashi-devel 84] =?iso-2022-jp?b?UmU6IGdyYXBoTUwgGyRCTVEbKEI=?= =?iso-2022-jp?b?GyRCST08KCU9JVUlSDRYTyIbKEI=?= In-Reply-To: <20040908014351.5d3019dd.fuja2@bj8.so-net.ne.jp> Message-ID: <5.1.1.8.2.20040908142541.06175ac0@Sp-Moto01.ar.sanken.osaka-u.ac.jp> 園部様 鷲尾です。以下、かねてよりgraphVizには興味を持っていますが、 やはり環境を考えるといろいろ問題点があるのですね。こちらからも 分からないことなど追々質問させていただくかもしれませんが、 宜しくお願いします。 鷲尾 >お久しぶりです。そのべ＠こまがわ　です。 >ちょっと間が空いてしまい生存確認的なメールになってしまいました。 > >graphML用表示ソフト関連は、作業内容としては変わってないのですが、 > >・Qt上で使えるグラフ構造描画クラスの整備 > >にも力点を置いて進めてるところです。実は前に教えていただいた >graphVizの影響をかなり受けました。 >graphVizにはグラフ描画用のクラスライブラリのようなもの（Ｃ実装） >があって非常に良く出来ていますが、アプリケーションを作成するの >に便利なQtやGtkと組み合わせては使えないだろうと考えてます。 >（逆にgraphVizはXがあれば動くようなので、選択の問題とも言えますが）。 >Qt上にクラスライブラリがまとまってれば、グラフ構造に関連し多少 >複雑なアプリケーションを作りたい人にとって、役に立つと期待したい >です。 > >あと、上の話が整理できたら、GUIアプリを作ってくれそうな人に声を >かけてみようと思ってます（かけてみないとわかりませんが）。 >musashiの魅力はすぐに感じてもらえると思いますが、GUIアプリに >対する面倒な印象をなんとかするほうが大変かもしれません。 > > >graphMLについては、実はまだ何が表せて何が表せないのか（私の立場 >からすると何が表示できなければいけないのか）がちゃんとはわかって >ないのですが、もう少ししたら質問させてもらうことになると思います。 > >-- > ／　kazuo sonobe >☆ ／　信号処理技術の解説ページ「蜂波の眼」作成中 >☆ 　　 >_______________________________________________ >Musashi-devel mailing list >Musashi-devel ＠ lists.sourceforge.jp >http://lists.sourceforge.jp/mailman/listinfo/musashi-devel From fuja2 ＠ bj8.so-net.ne.jp Thu Sep 9 12:24:10 2004 From: fuja2 ＠ bj8.so-net.ne.jp (kazuo sonobe) Date: Thu, 9 Sep 2004 12:24:10 +0900 Subject: [Musashi-devel 85] =?iso-2022-jp?b?Rnc6IFJlOiBncmFwaE1MIA==?= =?iso-2022-jp?b?GyRCTVFJPTwoJT0lVSVINFhPIhsoQg==?= Message-ID: <20040909122410.6b626d26.fuja2@bj8.so-net.ne.jp> 園部です。 もうしわけありません。MLに返信したつもりが鷲尾先生の 方に直接送ってしまったようです。 失礼いたしました。引用してMLの方に再送信いたします。 Begin forwarded message: Date: Thu, 9 Sep 2004 02:10:40 +0900 From: kazuo sonobe To: Takashi Washio Subject: Re: graphML 用表示ソフト関連 鷲尾先生 園部です。そうですね、どういうソフトを作るかにもよると思うのですが、 例えば私が作ってるmusashi_textではQtが用意してる部品（table,textedit, tabなど）を使っていて、これを自作するとなると相当大変になると思います。 あとQtやGtkはまだ発展途上なので、これからも便利な部品が出てくる可能性 がある、というのもあります。 graphVizの場合は様々な表示ができるという点で完成度が高いので、graphML 用表示ソフトの方も当面はgraphVizを目標にしてやっていきたいです。 こちらこそ、これからよろしくお願いいたします。 On Wed, 08 Sep 2004 14:27:14 +0900 Takashi Washio wrote: > 園部様 > > 鷲尾です。以下、かねてよりgraphVizには興味を持っていますが、 > やはり環境を考えるといろいろ問題点があるのですね。こちらからも > 分からないことなど追々質問させていただくかもしれませんが、 > 宜しくお願いします。 > > 鷲尾 -- ／　kazuo sonobe ☆ ／　信号処理技術の解説ページ「蜂波の眼」作成中 ☆ 　　 From hamuro ＠ adm.osaka-sandai.ac.jp Thu Sep 9 12:25:49 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Thu, 09 Sep 2004 12:25:49 +0900 Subject: [Musashi-devel 86] =?iso-2022-jp?b?UmU6IGdyYXBoTUwbJEJNUUk9GyhC?= =?iso-2022-jp?b?GyRCPCglPSVVJUg0WE8iGyhC?= In-Reply-To: <20040908014351.5d3019dd.fuja2@bj8.so-net.ne.jp> References: <20040908014351.5d3019dd.fuja2@bj8.so-net.ne.jp> Message-ID: <200409090325.AA01942@hayabusa.adm.osaka-sandai.ac.jp> 園部さん、羽室です。 >・Qt上で使えるグラフ構造描画クラスの整備 > >にも力点を置いて進めてるところです。実は前に教えていただいた >graphVizの影響をかなり受けました。 >graphVizにはグラフ描画用のクラスライブラリのようなもの（Ｃ実装） >があって非常に良く出来ていますが、アプリケーションを作成するの >に便利なQtやGtkと組み合わせては使えないだろうと考えてます。 >（逆にgraphVizはXがあれば動くようなので、選択の問題とも言えますが）。 >Qt上にクラスライブラリがまとまってれば、グラフ構造に関連し多少 >複雑なアプリケーションを作りたい人にとって、役に立つと期待したい >です。 GUIプログラミングに詳しくないので、graphVizとQtの組み合わせがなぜ無理なのかはよく分かりませんが、 描画ルーチン以外の関数(例えばエッジの重なりが最小になるようなノードの配置計算など）は利用できないでしょうか？ ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From fuja2 ＠ bj8.so-net.ne.jp Sun Sep 12 01:26:16 2004 From: fuja2 ＠ bj8.so-net.ne.jp (kazuo sonobe) Date: Sun, 12 Sep 2004 01:26:16 +0900 Subject: [Musashi-devel 87] =?iso-2022-jp?b?UmU6IGdyYXBoTUwbJEJNUUk9GyhC?= =?iso-2022-jp?b?GyRCPCglPSVVJUg0WE8iGyhC?= Message-ID: <20040912012616.30a952cd.fuja2@bj8.so-net.ne.jp> 羽室先生。園部です。 次のアドレスに間違って送ってたようなので再送します。 （木曜の晩にdevelに送ったつもりだったのですが、たった今、 気がつきました。ちょっと注意力が散漫になってたようです） musashi-devel-bounces ＠ lists.sourceforge.jp Begin forwarded message: Date: Thu, 9 Sep 2004 20:54:53 +0900 From: kazuo sonobe To: musashi-devel-bounces ＠ lists.sourceforge.jp Subject: Re: graphML用表示ソフト関連 羽室先生 園部です。反応が遅くなってしまいました。 On Thu, 09 Sep 2004 12:25:49 +0900 Yukinobu Hamuro wrote: > GUIプログラミングに詳しくないので、graphVizとQtの組み合わせがなぜ無理なのかは >よく分かりませんが、 >描画ルーチン以外の関数(例えばエッジの重なりが最小になるようなノードの配置計算 >など）は利用できないでしょうか？ ノードの配置計算に関しては、NEATO というプログラムの中で行ってるみたいです。 一応中身を見てみたのですが、大事そうな部分は数百行ぐらいだった と思います。最初はソースレベルで利用できないかと考えたのですが、ソースから アルゴリズムを読みとって実装しなおすのとどちらが良いか思案してるところです。 他にも有用な計算がないかは、ざっとでも見てみようと思ってます。 余談ですが・・・ あと graphViz で参考になったのは、いろいろなノードの形に対応するのに予め用意し てある画像を読み込んで使ってることでした。しかも背景（画像中の白色）は画面上で 透明として扱われるので複雑な形が画面上で重なっても大丈夫なようになってます。 同じことが Qt 上でも簡単にできるようなので、こういうやり方は常套手段なのかも しれません。 QtとgraphVizの組み合わせが絶対にダメかというと私にもわからないのですが、画面に 描画するライブラリは、仮想的なレイヤを何層も重ねてるので無理には一緒にできない ような気がします。例えばQtのプログラムにXの生の描画面を表示する方法はわかりま せんし、できたとしてもすごい矛盾（例えばクリックなどのイベントがどういう風に 扱われるか）が起きそうです。 ちょっと活動が低調気味だったのですが少し回転を上げていくので、またどうぞよろし くお願いいたします。 -- ／　kazuo sonobe ☆ ／　信号処理技術の解説ページ「蜂波の眼」作成中 ☆ 　　 From hamuro ＠ adm.osaka-sandai.ac.jp Wed Sep 15 12:30:23 2004 From: hamuro ＠ adm.osaka-sandai.ac.jp (Yukinobu Hamuro) Date: Wed, 15 Sep 2004 12:30:23 +0900 Subject: [Musashi-devel 88] =?iso-2022-jp?b?UmU6IGdyYXBoTUwbJEJNUUk9GyhC?= =?iso-2022-jp?b?GyRCPCglPSVVJUg0WE8iGyhC?= In-Reply-To: <20040912012616.30a952cd.fuja2@bj8.so-net.ne.jp> References: <20040912012616.30a952cd.fuja2@bj8.so-net.ne.jp> Message-ID: <200409150330.AA01981@hayabusa.adm.osaka-sandai.ac.jp> 園部さん、羽室です。 graphViz、かなり詳しいところまで調査されているのですね。 GUIプログラミングの難しさを垣間見たような気がします。 何かこちらでできることがありましたらお申し付け下さい。 完成を楽しみにしております。 kazuo sonobe さんは書きました: > >羽室先生。園部です。 > >次のアドレスに間違って送ってたようなので再送します。 >（木曜の晩にdevelに送ったつもりだったのですが、たった今、 >気がつきました。ちょっと注意力が散漫になってたようです） >musashi-devel-bounces ＠ lists.sourceforge.jp > > >Begin forwarded message: > >Date: Thu, 9 Sep 2004 20:54:53 +0900 >From: kazuo sonobe >To: musashi-devel-bounces ＠ lists.sourceforge.jp >Subject: Re: graphML用表示ソフト関連 > >羽室先生 > >園部です。反応が遅くなってしまいました。 > >On Thu, 09 Sep 2004 12:25:49 +0900 >Yukinobu Hamuro wrote: > >> GUIプログラミングに詳しくないので、graphVizとQtの組み合わせがなぜ無理なのかは >>よく分かりませんが、 >>描画ルーチン以外の関数(例えばエッジの重なりが最小になるようなノードの配置計算 >>など）は利用できないでしょうか？ > >ノードの配置計算に関しては、NEATO というプログラムの中で行ってるみたいです。 >一応中身を見てみたのですが、大事そうな部分は数百行ぐらいだった >と思います。最初はソースレベルで利用できないかと考えたのですが、ソースから >アルゴリズムを読みとって実装しなおすのとどちらが良いか思案してるところです。 >他にも有用な計算がないかは、ざっとでも見てみようと思ってます。 > >余談ですが・・・ >あと graphViz で参考になったのは、いろいろなノードの形に対応するのに予め用意し >てある画像を読み込んで使ってることでした。しかも背景（画像中の白色）は画面上で >透明として扱われるので複雑な形が画面上で重なっても大丈夫なようになってます。 >同じことが Qt 上でも簡単にできるようなので、こういうやり方は常套手段なのかも >しれません。 > >QtとgraphVizの組み合わせが絶対にダメかというと私にもわからないのですが、画面に >描画するライブラリは、仮想的なレイヤを何層も重ねてるので無理には一緒にできない >ような気がします。例えばQtのプログラムにXの生の描画面を表示する方法はわかりま >せんし、できたとしてもすごい矛盾（例えばクリックなどのイベントがどういう風に >扱われるか）が起きそうです。 > >ちょっと活動が低調気味だったのですが少し回転を上げていくので、またどうぞよろし >くお願いいたします。 >-- > ／　kazuo sonobe >☆ ／　信号処理技術の解説ページ「蜂波の眼」作成中 >☆ 　　 >_______________________________________________ >Musashi-devel mailing list >Musashi-devel ＠ lists.sourceforge.jp >http://lists.sourceforge.jp/mailman/listinfo/musashi-devel > ---- Yukinobu Hamuro hamuro ＠ adm.osaka-sandai.ac.jp From munetika ＠ os-inc.net Thu Sep 30 14:31:45 2004 From: munetika ＠ os-inc.net (Ryuichiro Munechika) Date: Thu, 30 Sep 2004 14:31:45 +0900 (JST) Subject: [Musashi-devel 89] =?iso-2022-jp?b?TVVTQVNISSAbJEI0WD90JE4bKEIg?= =?iso-2022-jp?b?UEhQIBskQiROPEJBdSRLNFgkOSRrNURPQCRLJEQkJCRGGyhC?= Message-ID: <1705.61.204.43.174.1096522305.squirrel@www.niji-net.com> 　宗近です 　羽室先生からのご提案で、一部で話をしていたMUSASHI関数のPHPの実装に 関する議論についてmusashi-develメーリングリストで行おうということに なりました。 　背景を説明しますと、Web系アプリケーションの代表的な開発言語である PHPにMUSASHIを関数として利用できる機能が実装されると、Web開発がやり やすくなるということ、またPLI(PHP command Line Interface)によりシェル に依存しない形でバッチを実装できるので、MUSASHIを利用したアプリケー ションが行いやすくなる点があります。 　先日qnoteの鶴田さんと、また昨日PHPポケットリファレンスの大垣さんと お話してアイデアを色々といただいているので広く意見を募りながらより よいものを開発していこうという思いがあります。 　musashi-develメーリングリストに登録していない方は登録をお願い いたします。 http://lists.sourceforge.jp/mailman/listinfo/musashi-devel 　よろしくお願い申し上げます。 -- オーエス・インク 代表 宗近龍一郎 munetika ＠ os-inc.net http://www.os-inc.net/ PHS : 070-5650-8819 Vodafone : 080-3114-9238