blike

blikeがこの頃すごいスピードで更新されているので読んでみました。なんだかjavaとかCがスクリプト言語っぽくなって、ちょっと面白そう。

CFBですが、C言語の標準の書き方で
#include <stdio.h>
int main(void)
{
#include "main.cfb"
return 0;
}
ってやればほぼ同じことができそうですね。

そうか、CFBみたいなJFBを作れば、Javaでも同じことができるのか！
uchanさんにいわれるまで気がつかなかった！
あとで作ろう。

な、なんと！
最初からそうすればよかった・・・

>blikeとは一体何なのか？

C言語やJavaをお勉強するための、K流の支援キットです。教材です。

>サンプルプログラムと、そのビルド方法を知りたいです。

たとえばCFB版（C言語を入門向きにしたもの）ならここで説明しています。
http://osask.net/w/?blike/CFB/p0002

win機での挙動がわからないので想像ですが、linux用にblike.hを移植しようと思いました。
http://kemeconoajito.blog88.fc2.com/blog-entry-118.html

inkeyで得られる数値の仕様とか、colorでの色番号の仕様とか、いろいろ具体的な所の挙動が（当方、windouws機をもってないので）よく分からないので、だれか対応表みたいなのおねがいします…（ちらっ

確かにそうですね。どうしてそんな間抜けなことをしてしまったのか、自分でも不思議です。
今は忙しいのですが、近いうちに直します。

グラフィック対応版のblikeを開発中です。
これができたら第一世代のOSASKアプリを移植して遊びたいです。

blikeを「はりぼてOS」に移植してみました。
「はりぼてOS」でもkcubeが回っています。
結構楽しいです。

linux の gnome 上で gtk+2.0 でドライバー部分を書いてみました。
（グラフィック部分のみ）
http://blog-imgs-42.fc2.com/k/e/m/kemeconoajito/drvgtk03.png



blike.c は書き換えずに、drvwin32.c 以下のみを書き換えて、それで本当に動作するのか？
…を試すために書いたのですが、大方、動作するようです。

ドライバーを書いた際に、いくつか気づいた点、疑問点がありました。



ピクセル合成のモード？　が、何を表してるのか分からないので、具体的な式による説明があるとありがたいです。
（ウインドウズにベッタリな処理なので、ブラックボックスで具体的な計算式がわからないので、移植にこまる）

たとえば「この合成モードでは (ピクセルA * ピクセルB) による乗算を行うことを期待している」みたいな具体的な説明をだれか補足してくれるとありがたいです。
各フラグの。



あと、bld_waitNF() に望んでる動作は、２ミリ秒スリープさせるってことでしょうか？
#define TIMER_INTERVAL 10
Sleep(TIMER_INTERVAL / 4);
この125Hz（２ミリ秒）を公式と考えなさいということですか？



当方windowsの実行環境が遠いので、実際のウインドウズ上で動作を試してなかったので誤解してたのですが、
printf の結果は、コンソールではなく、新しくウインドウ作って、そこに表示するみたいですが、

ならば、新規にウインドウを作る処理は、大多数のアプリケーションならば blmainの実行中に必ずあると考えて、
open window は必ず行うということにしてしまえばどうでしょうか？
（エコーのない cp コマンドを作る場合等は不要でしょうが、そういう例は稀だと思います。
　大多数のアプリケーションでは、なんらかの文字や画像が情報として画面出力されるものだと思います。）

つまり、open window する関数を、ユーザーに任せずに、自動にしてしまえばどうでしょうか？　（デフォルトサイズで）

あと、ユーザーがウインドウのサイズ変更をしたい場合には、open ではなく resize という名前を使った方が意味がわかりやすいと思うのですが。 resize window 的な名前の関数で。



あと、気になったのは、window の幅と高さを引数で受けとるとき、引数名が x y なのが奇妙に感じました。
最初混乱しました。（「デスクトップ上での初期表示座標か？？」とか誤解して最初混乱しました）
幅と高さは w , h に変えた方がドライバー作る人に誤解が無くていいと思います。



あと、将来的にウインドウを複数作る場合に、おそらくウインドウ毎にスレッドを用意するのでしょうけど、その場合 bl_work を大域変数として、たった一個しか bl_work が無い状況は、複数ウインドウを開く場合に面倒なことになると思います。

将来的に、「複数ウインドウを開くことは考えてない」ということで、bl_work が（ポインタではなく実数での）大域変数なのですか？

たとえば bl_work をポインタとして用意してあれば、将来的に配列として扱うようにも簡単に変更できると思うのですが、現状の実数の状態だと、bl_work を配列化する際に、結構な置換が必要になるのでは…　と不安を感じました。

blike.c が bl_work に依存してるので、ドライバ側では bl_work をポインタとして書き換えることができないので困りました。

複数ウインドウを作る場合は bl_work の扱いはどうなる予定なのでしょうか？
それとも、将来にわたって複数ウインドウはサポートしないということなのでしょうか？

眺めてみました。

なぜbl_workを、直接アクセス可能な状態のまま、周囲を作り込んでしまってるんですか？
bl_workは、根本的に複数スレッドからアクセスされると想定するべきでは？　と思うのですが。

すなわち、
bl_work へアクセスするためのインターフェースを用意し、
bl_work の排他制御を徹底する（基本的に直接書き込みは禁じ手とする）。　これをすべてのbl_workに対するアクセスで徹底すれば、lockもunlockも不要ではありませんか？

これを、なぜやらないんですか？　効率ですか？
（そもそも、key[]に関しては、なぜ配列なのですか？　配列でlock unlockなのですか？　リングバッファーにすればいいだけのことじゃないですか。）


bl_workに対して、”書き込み読み込みの、許可フラグ”を用いずに、bl_workに「どのスレッドも、勝手なタイミングで自由に」アクセスできてしまう設計は、
そもそも複数スレッドの元で使われる共有変数の実装としては、あまりにも自由過ぎます。危なっかしいです。



正直な話、
bl_workへの、読み込み書き込みの排他制御が保証されてないが為に、
ドライバー側としても、じつに組みづらい設計だと感じます。(bl_workへ書き込むタイミングを計るという点で、じつに余計な神経を使わされます。)

他のスレッドの動作を能動的に止めたり動かしたりする、そんなことを一々手動で行わなければ安全に読み書きできない現状の bl_work は、
やはり設計として、根本的に稚拙だと思います。



素朴な疑問なのですが、
なぜbl_workを、こんなシングルスレッドみたいなやりかたでアクセスする設計にしてるんですか？

gtk+2というライブラリーというものを用いて、某windows用ライブラリーのドライバー部分を、
ubuntu10.10上でも動作するように移植を試みてみました。

”””　動作テストをお願いしたいのですが、お願いできますでしょうか？　”””

当方の環境（cpu:core2, memory:2G, graphic:intel G45オンボード）環境では動作確認したのですが、
他の環境では動くかどうか不安です。



手順：
git と libgtk2.0-dev のインストール
sudo apt-get install git libgtk2.0-dev

ソースファイルのダウンロード
git clone git://git.pf.sourceforge.jp/gitroot/k/ke/kemeco/c_blike_01e_linux.git

コンパイル
cd ./c_blike_01e_linux/samples
./build.sh



コンパイルが成功すれば、./c_blike_01e_linux/samples ディレクトリーに、２０個程度のサンプルプログラムができあがってるので、
実行できるか、動くかどうか？　など、試してほしいです。

もしも動いた場合、もしくは、動かなかった場合、また、なにかバグがあった場合など、なにか報告してくれるとありがたいです。
（24bitグラフィックを前提に、ピクセルが LSB 側から RGBRGBRGB...... と扱われることを前提に決め打ちしてしまってるので、
　もしかしたら、そのあたりでグラフィック表示にバグが出るかも…と思ったので。）

ソフトのライセンスは、ドライバー部分（./c_blike_01e_linux/lib_src/gtk以下）は、LGPL とします（gtk+2がLGPLなので）。 それ以外はたぶんKL-01だと思います。

いろいろありがとうございます。今は忙しいのであまりお返事できません。後日書きます。
とりあえず、もうすぐバージョン01fが出ます。でも今回はドライバとのインタフェースは改良できていません。すみません。
フォント周りは、僕も全面的に直したいです。キーも不満いっぱいです。もうちょっといろいろ作って全体が見えてきたら、中身を書き直したいです。

c_blike_01f
blike.h だか blike0.hだか忘れましたが #define rgb bl_rgb がスペルミスで rbgになってました。

ご無沙汰、になってしまいました。

ちょっとRubyのオブジェクト指向にはまってて、抜けだせませんでした。

blike、凄い事になってますね。
個人的にはefg01のバイナリ互換という発想に驚愕してたんですが、こんなに手軽にGUIも出来ちゃうのは魅力的だと思います。
blikeを使って何か作りたくなってきたので、何か出来たら公開します。

とか言ってまた途中で投げ出すかもしれません。
その時はごめんなさい。

test008a.cのバーの動きをキーリピート非依存にしました。http://codepad.org/kfYsZLj9

キーを離した場合にbl_inkey(BL_GETKEY)で4095が返ってくるのですが、
その4095が、何のキーを離した結果の4095かを判断する方法がわかりません。

たとえば A を押し続けてる状態で B を押し、
A, B の順で離した場合は 4095, 4095 となり、
B, A の順で離した場合も 4095, 4095 となり、見分けがつきません。

また、
A のみを離した場合は 4095 で
B のみを離した場合も 4095 なので、どちらか一方を離した場合も、そのボタンの見分けがつきません。

つまり、
A を押したまま B を連打した場合と、
A, B を交互に連打した場合と、
A, B を押したまま C を連打した場合とで現れる 4095 に関して、
どのボタンに対応した 4095 かを判断する方法がわからないので、
たとえば「右に歩き続けながらジャンプボタンを押した場合」に、ジャンプボタンの結果の4095なのか、右キーを離した結果の4095なのかを見分ける方法がわかりません。

なにか良い方法はないでしょうか。

こんばんは、自作OS入門書を読んでいるものです。
ここにくるのはお初なのでよろしくおねがいします。


早速質問なのですが本に書いてあった「CD-ROMからの起動(harib27f)」なのですが、二番目に書いてある「CDRECORDフロントエンド」のサイトに行きましたがダウンロードできない状態になっていました。

なのでKさんおすすめの他のソフトのサイトがあったら教えてください、お願いします。

osaskのk氏のblike上の「画面に点を打つ」という機能を使って、３Dポリゴンを表示するライブラリーを書いてみました。

スクリーンショット
ttp://blog-imgs-42-origin.fc2.com/k/e/m/kemeconoajito/bl3d20110707.jpg

ソースコードはgitで管理してるので、直接クローンしてダウンロードすれば簡単だと思います。また、zipでも上げときました。
http://sourceforge.jp/users/kemeco/pf/c_blike_01f_linux/



あと、ウインドウズ用にコンパイルしたバイナリ－と、
ソースコードと、コンパイル用のバッチファイルのセットです。
http://sourceforge.jp/downloads/users/0/330/bl3d_cube.zip/

当方、ウインドウズは、ウインドウズ２０００しか持ってないので、このバイナリ－が最新のウィンドウズ上で動くかはわかりませんが、
このディレクトリーをk氏オリジナルの c_blike_01f の./sampleディレクトリーに置いて、build.bat を実行すれば、
コンパイルならできるかもしれません。
（注意：当方の mingw のインストールディレクトリーは c:\minguなので、gccおよびarのパスがそこに決め打ちしてあります。
　mingwを c:\program files\mingw などにインストールしてる方は、build.bat内のパスを書き換えないとコンパイルできないかもしれません）



bl3d_cube.exe は、例の猫をテクスチャーマッピングしたサイコロを表示します。
操作方法は jk hl um で、たしかキューブのxyz回転ができたような記憶です。（忘れた）


bl3d_cube2.exe は、重力の方向がX,Y,Zで変化する中で、例の猫のキューブが複数動く光景を観察するデモです。

操作方法：
視点の平行移動（shiftを押しながらだと回転操作）
j,k: 視点のY軸上での移動
h,l: 同X軸
u,m: 同Z軸

視点モードの変更
1: 通常の視点。
2: 追跡視点。１個目のキューブをカメラが追跡します。
（なるべく画面の中心に映すするように、カメラ角度が自動的に操作される）

キューブ数の増減
i, d: キューブ数を増やしたり、減らしたりします。（最大３００個まで）

当方のcore2ペンティアム,2.4GHz環境では、
500個表示した状態でも、あまり処理落ちせずに60フレームで表示できてます。（ただし描画ピクセル数が増えると厳しいです）

１キューブは12ポリゴンで構成されるので、
12 * 500 * 60フレーム = 秒間約36万ポリゴン。
実際にはピクセル描画されないポリゴンも結構あるのですが、
頂点ジオメトリだけで考えれば、36万程度は全然余裕みたいです。
（テクスチャー＆光源計算＆グラデーション）

ただ、blikeはVRAM描画のボトルネックが小さくはないので、
各ポリゴンの表示サイズが大きくなった際にVRAMへのピクセル描画量が増えると、
最悪、数ポリゴン程度でも60フレームが不可能になってしまいます。



希望：
blikeのVRAM描画を、超高速で行う関数を、
setPix()などとは別に用意してくれるとありがたいです。

もしくはVRAMの配列を直接扱うことを、許可してくれるとありがたいです。
つまりヘッダーで変数名を公開するなどによって、公式に使用を許可してくれるとありがたいです。

あと、blikeで公式に sin cos sqrt log や asin acos atan2 などを用意してくれると、安心して使えていいと思います。
（
　　　　たとえば bl_sin(a) {return sin(a)} みたいなのでもいいので、公式に許可してくれれば安心して使えるのですが、
　　　　現状はsin()などは公式に使用を許可されてない状態なので不安です。
　　　　（
　　　　　　　　kcubeでsin()が使用されてるから、「公式に、使ってもいい事になってる…のかも…しれない？？」という認識です。現状
　　　　　　　　bl_sin()などを用意して、公式に使用を許可してくれれば、いろいろ安心なのですが…
　　　　）
）

>>ウィンドウのイメージデータへの直接アクセスを許すかどうかは悩み中です。ドライバが作りにくくなったらどうしようとか心配しているわけですが、これはもう少し悩ませてください。
ウインドウのイメージデータと言っても、直接ドライバー側のウインドウが持つフレームバッファーに直接書くことは要求してません。
もしそれをblMain()から許可してしまえば、カラー形式は様々なので、途端にblMain()ソースの移植性が失われてしまいます。
（24bit,0xBBGGRR形式を前提に直接あつかえば、そのblMain()コードは32bit,0x00RRGGBB環境では当然正常に表示されませんし、移植性に問題が生じてしまう）
そうではなく、commonの扱うレベルのフレームバッファーへの直接アクセスを言ってます。
ここは32bit,0x00RRGGBB形式で固定なので、直接アクセスを許してもblMain()の移植性に問題は生じないと思います。
bld_内の、まさにウインドウの直接のバッファーを、直接読み書きすることを許可するような仕様変更に関しては、もちろん反対です。そんなことしたらblikeの意味（blMain()の移植性）が失われますし。






<bl_play_pcm()などを使えるようにしたい>

blikeでサウンドをサポートしようと思い、
どうやれば移植性のある実装になるかを思案してみました。

条件として考えたのは
１：ドライバー側の開発負担を最も小さくできる方法。（つまり、commonではどうしても実現できない機能のみの、最小限の実装）
２：ソフトウェアで可能な部分は、極力ソフトウェアによるエミュレートで行う。（機種依存せずに実現可能な機能は、すべてcommon側で行う）
３：ウィンドウズ環境に有利な設計をする。（波形は、ウインドウズで一般的なwav形式（リトルエンディアン、符号あり16bit,44100Hz）の使用を前提とする）
です。

これにより、結論としては
ドライバー側が担当する機能：
　　　　wav形式の断片（16bit,44100Hz,モノラルの波形パケット）を、指定された側のスピーカーで再生する。

common側が担当する機能：
　　　　wavファイルのロード。
　　　　複数チャンネルの波形を合成して、一つの波形パケットを生成し、それをドライバーに渡す。
　　　　各チャンネルの再生の管理。
　　　　　　　　（波形全体の再生が完了するまで、blMain()とは別スレッドで、波形パケット生成＆ドライバー側へのパケット転送を独自に続ける）

という形になりました。
つまり、
ドライバー側はシンプルなパケット再生機能のみ。（渡されたパケットを、指定されたスピーカーで、ただ鳴らすだけ。）（ミキサーのような高レベルなことは一切行わない）
common側はミキサー全般と、波形再生の再生状況の管理全般を担当します。

ドライバー側は当然スレッドで独立して動かさねばなりません。ドライバー側では、ソースコードレベルでの移植性を考慮する必要が無いので、スレッド化できます。
問題は、common側です。
common側はソースコードの移植性（ソースコードの変更無しにコンパイル可能）を満たすためには、スレッドが使用できません。
なぜなら、blikeではスレッドがサポートされてないからです。



というわけで、commonでスレッド生成が可能になるように、bld_でスレッド関連の関数をサポートすべきだと思います。
それは必要最小限で十分で、

struct BLD_THREAD {...};

typedef void* (*bld_thread_func)(void*);
struct BLD_THREAD* bld_create_thread(bld_thread_func f, void* data);

void bld_join_thread(struct BLD_THREAD* a);

void bld_close_thread(struct BLD_THREAD* a);

の３つで十分だと思います。
これをbld_で提供すれば、common側でスレッドを使っても、移植性のあるコードになると思います。



もしもcommon側でスレッドを使わずにミキサーを作った場合、
音を再生してる間はblMain()の他の処理が全て停止する、という、悲惨な状況になると思います。
音を再生してる間、ゲームの動きが全て止まるなんてショボすぎます。これは現代のレベルでは許されないレベルのショボさだと思います。（まるでBASIC時代のゲーム）

commonでのスレッド使用を諦め、かつ、音を再生してもblMain()が停止しないようにするためには、
ドライバー側に、プレイヤー、ミキサー、波形再生管理、これら全て行うソースを書いてしまえば可能ですが、これだと、新規のドライバー移植作業がとてもシンドイことになります。
（
　　　　もっとも、これら全てをドライバーで書くならば、common, driverに分割する設計よりも、ずっと効率的に処理できるのも事実だし、
　　　　また、commonによるソフトウェアエミュレートによるミキサーではなく、ハードやALSAなどに依存したミキサー機能を直接使えるので、
　　　　より高速・高効率になるメリットもありますが。
）



blikeは、同じソースコードがどこでもコンパイルできて、まったく同じように動くのが売りだと思うので、
ソフトウェアエミュレートで可能なことは、極力common側で行うのが正しいスタイルだと思います。
ミキサーと波形再生管理のような、ソフトウェアエミュレートで可能な部分はcommonに書くべきだし、
ドライバー側に多チャンネルの合成や、波形再生管理のような、高レベルのコンポーネントを要求すべきでは無いと思います。

なので、ドライバーの仕様に、スレッドを扱う関数のサポートを、追加すべきだと思います。

もしもスレッドが扱えないOS上に、blikeのドライバーを移植する場合は、スレッド関連が使用不能なことを表すマクロなりをblike.hに設定しておいて、
単純にスレッド関連の関数は空としてドライバーを書けば良いと思います。
ドライバーのスレッド関連関数が空関数になることに伴い、commonに書かれてる関数のうち、スレッドに依存した関数も空関数として無効化するようにすれば、
blMain()のアプリ中でも、commonのスレッド依存関数を使用した部分は空関数で無効化されるので、おそらく有効機能のみでblMain()は無事に動くはずだと思います。



ドライバー側でスレッドを提供しても、スレッドの提供をcommonまでにしておけば（blMain()には提供しなければ）、
とりあえずblMain()レベル（アプリケーションレベル）では、移植に問題は生じないはずだと思います。
単純に、チープな環境では、blMain()がチープな環境なりに、一応、動くはずです。（それはたとえば音が鳴らない等の差として）

ただ、個人的には、スレッドの使用をblMain()にも提供すべきだと思います。
（スレッドを使えない環境では動かないblMain()アプリが書かれうるけど、それはそれで、「スレッドが使えないOSでは、動かないアプリも時々あるな…」程度で諦めてもらえば良いと思います。）


…個人的には、あまりに極端にチープな環境は、切り捨てるべきだと思います。
たとえば、スレッドが使えない、音が鳴らない、マウスが無い、ネットが無い、モニターが無い、等々、あまりにもチープな環境はサブターゲット（おまけ）と考えて設計すべきだと思います。
これをメインターゲットと考えて設計してしまってるから、サウンドが無い、ネットが無い、マウスが無い、そしてスレッドが無いなんて状況になってるんだと思います。

そこそこ新しくて、いまどきの普通のパソコンなら有って当然な機能は、遠慮せずにサポートしても、現実的なケースとして考えるにおいて、移植に重大な問題が生じるようなケースは稀だと思います。
大体、古いパソコンの想定は、１０年前のペンティアム３機程度の機能を想定しておいて、それよりも古いパソコンやOSへの移植性は、ついで程度に考えておけば十分だと思います。



４８６レベルの古い低機能なパソコンを、おまけターゲットではなく、メインターゲットみたいに考えてしまうと、たぶん、身動き取れなくなると思います。
で、blikeの設計の妙な制約って、まさにそこだと思います。
２０年前のパソコンが、亡霊みたいに後ろ髪を引っ張ってるような状況に思えます。おまけターゲットならぬ、おばけターゲットというか。

おまけターゲットも、せいぜいペンティアム３時代までで十分だと思います。個人的に。
これから先、多コア化に伴い、スレッドのサポートは必須になると思います。
スレッドが使えない環境は、今後、間違いなく廃れていくと確信してます。過去方向の普遍性ではなく、未来方向への普遍性を求めるべきだと思います。

わかりました。
blike で実現される機能は、あくまで現状のはりぼてOSが基準なので、
はりぼてOS上で動かない機能が、オリジナル版blikeに追加される可能性は０ということですね。

はりぼてOSで動かない機能が、オリジナル版blikeでサポートされることへの要望・期待をしないように、今後は気をつけます。
すみませんでした。



ところで、
先頭アドレスのアライメントを指定して確保できるmalloc(),free()を書いたのですが、blikeに追加してくれませんか？

使用してる関数は bld_malloc(), bld_free(), bl_printf() のみなので、common に属するソースだと思います。
（bl_malloc(), bl_free()が動かないので）

http://sourceforge.jp/users/kemeco/pf/c_blike_01f_linux/git/?a=blob&h=b779dbace15770497dbfa9cdf302e5de778198e6&hb=91108e45b0d1d2fc2d0951d2b44823a5c23e1f08&f=lib_src/common/bl_malloc_aligned.c

http://sourceforge.jp/users/kemeco/pf/c_blike_01f_linux/git/?a=blob&h=5fa6be5bb408c48c7f2360a4906ad7e7cfc332c5&hb=91108e45b0d1d2fc2d0951d2b44823a5c23e1f08&f=blike0.h

先頭アドレスを 456byte 境界に配置したい場合は、
　　　　void* p = bl_malloc_aligned(123, 456);
とすれば、先頭アドレスが 456 で割り切れるアドレスに配置されます。

解放する場合は
　　　　bl_malloc_free(p);
とすれば、確保したメモリーが全て解放されます。



余談：
blike の開発ツリーのソースコードを、 git で管理・公開してみてはどうでしょうか？

現状の変更状態がはっきりするし、
（過疎ってますが）ここのコミュニティーの人たちなどがblike開発版をダウンロードして使うことで、
デバッグ作業や修正パッチ作成を行って貰える形にもなるでしょうし。

http://sourceforge.jp/users/kemeco/pf/bl_clock/git/?a=blob&h=d14fed82e6d12cf385685c225207163c84779b6f&hb=d4f4e8dd2d7e5f64341cf9ae764dd36157599b12&f=bl_clock.c

c_blike_01f で時計
http://sakurasite.homeip.net/imgboard/img-box/img20120208220719.png

linuxでのビルド方法:
1.ライブラリーを落としてインストール
git clone git://git.pf.sourceforge.jp/gitroot/k/ke/kemeco/c_blike_01f_linux.git
cd c_blike_01f_linux
aclocal
autoheader
autoconf
./configure --prefix=/usr
make
sudo make install
ldconfig

2.普通にc_blikeをpkg-configでリンクしてビルド（sin,cosを使ってるので libm もリンクしてます）
gcc -o bl_clock bl_clock.c `pkg-config c_blike --libs --cflags` -lm

3.実行
./bl_clock

同じく c_blike_01f にて、任意の三角形グラデーション塗りつぶしを行う関数です。
(filltrigr.c)
http://sourceforge.jp/users/kemeco/pf/bl_filltrigr/git/?a=tree

ベースは filltri.c なので、基本的に仕様は同じです。
１ファイル完結にしてあるので、/common に置いても、あまり汚れないと思います。

ソースコードのgitリポジトリー
git clone git://git.pf.sourceforge.jp/gitroot/k/ke/kemeco/bl_filltrigr.git

c_blike_01f_linux は、アプリ起動時の引数を取得できなかったので、ツール類を書く際に不便だったので、
アプリ起動時に引数を取得できるように、グローバル変数を追加してみました。
（int bl_argc と char** bl_argv）

git clone git://git.pf.sourceforge.jp/gitroot/k/ke/kemeco/c_blike_01f_linux.git



これによって
main(int argc, char** argv)に相当する情報を、
グローバル変数 int bl_argc; char** bl_argv; として参照できるようになりました。

sample/test_argc.c に、簡単な使い方の例を書いてあります。



備考：
c_blike_01f_linuxのビルド・インストール方法

aclocal
autoheader
autoconf
./configure --prefix=/usr
make

sudo make install
sudo ldconfig



で、以降、aiueo.cなどのソースコードを
gcc -o aiueo aiueo.c `pkg-config c_blike --libs --cflags`
でビルドできます。

sample/test*.c のサンプル群のビルドも、上記の記述法で手動でやってもいいですが、
面倒なのでバッチファイルを用意してあります。
./build.sh

あぼ～ん

書き忘れ



ライブラリーのビルド・インストール方法が変わりました（重要）:

./autogen.sh --prefix=/usr
make
sudo make install
sudo ldconfig

です。
これには、autoconf, automake, libtool が必要となります。
（これらツールは、普通のgnu/linuxディストリビューションならば必ず用意されてると思います。予めインストールしておいてください）

Haskell で blike 関数を利用するためのラッパー

https://github.com/takeutch-kemeco/blike/wiki/Haskell-%28GHC%29-%E3%81%8B%E3%82%89-blike-%E3%82%92%E4%BD%BF%E3%81%86

test000a.c ～ test008a.cを試しにHaskellで書き換えてみました。動きます。

趣味な仕様によるスクリプト言語を作ってます。
全体的には昔のBASIC程度の表現力すらありませんが（for等のループ命令が無い。ループはifとgotoで行う等）、一方で変数が全て暗黙に複素数として扱われたり、式にラムダ関数を含められたり、歪な仕様の趣味言語です。

これの組み込み関数のバックエンドに blike をそのまま用いてみました。

https://github.com/takeutch-kemeco/memcalc

sample/bl_func/以下に、test000a.mc ～ test008a.mc として、blikeのサンプルコードに対応したものがあります。

>>53
使うのは良いのですが、メンテナンスが地味にめんどくさくなってきました・・・

blikeライブラリーのバックエンドに使ってるgtk+3等のライブラリーの諸々の仕様変更に追随してblikeライブラリーのコードを微修正する、俗に言うメンテナンス作業が地味に面倒になってきました・・・
（幸い、最近はgtk+3の仕様変更は落ち着いてきたので静かですが）

ドライバーにマウスとペンタブのサポートを追加しました。
これでペイント作れます。

https://github.com/takeutch-kemeco/blike#%E3%82%AA%E3%83%AA%E3%82%B8%E3%83%8A%E3%83%AB%E3%81%A8%E3%81%AF%E7%95%B0%E3%81%AA%E3%82%8B-c_blike_01f_linux-%E5%9B%BA%E6%9C%89%E3%81%AE%E6%A9%9F%E8%83%BD

また、ウインドウ内では、ウインドウマネージャーによるデフォルトのマウスカーソルは消えるようにしてあるので、必要ならば自分でマウスカーソルを描くことも可能です。