2001-08-18
λ. Re: Access すっごく難しいです。
へえ。Accessってまだあったんだ。最近データベースの話はOracleとかPostgreSQLとかMySQLとかしか聞かないから、すっかり市場から駆逐されてしまったんだと思ってた。ところで、RDBMSの考え方って、ちょっと好きになれないんだよなぁ。
2002-08-18
λ. ブロークンアロー
を見た。
λ. コンパイル猿
cygwinでgtk2関係のライブラリのビルドに挑戦。Ruby-GNOME2の実験環境を作るのが目的の一つ。
それにしてもcygwinはやっぱ遅い。クロスコンパイル環境つくろっかなー
λ. glib-2.0.6
gimp共同掲示板でのsけいしさんの情報を元にlibtoolを置き換える。以下の他のライブラリのコンパイルでも同様にする。
それから、以下のように言われてしまうので、「-luser32 -lwsock32 -lkernel32」が付かないよう細工してコンパイルした。-luser32と-lkernel32については自信ないけど、-lwsock32だけは確実に不用なので報告しておこう(#91696)。
*** Warning: This library needs some functionality provided by -luser32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lwsock32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lkernel32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it.
こうして作ったglib用に、Ruby/GLibをコンパイルしようとしてtypoに気が付いた。後でこっそり直しとこ。
λ. atk-1..3
何故かimpgenが/usr/libを見に行くので、DLLを/usr/binからコピーして安易に対処。
λ. freetype-2.1.0
普通にビルドしたらDLLにならなかった。まあ、とりあえず作っているだけで、今回はgimpまでビルドするつもりではないので、気にしないことに。(gimpにはpangoft2が必要なんで)
λ. pango-1.0,4
どうせなので、pangowin32, pangox. pangoxft, pangoft2 全部作った。pangoのモジュールにはサフィックスが付くので、共存について特に考える必要はないはず。
fribidiとXftについて考えるのが面倒だったので、mini-fribidiとmini-xftを使う。
pango/pango-utils.cにミスを発見したので修正。この修正をしないとG_WIN32_DLLMAIN_FOR_DLL_NAMEのところでエラーになる。ひょっとして、CygwinでPangoをビルドしてるのって僕が初めて? (#91785)
--- pango/pango-utils.c.orig 2002-02-10 14:53:40.000000000 +0900 +++ pango/pango-utils.c 2002-08-18 10:57:36.000000000 +0900 @@ -38,7 +38,7 @@ # define getc_unlocked(f) getc(f) #endif /* !HAVE_FLOCKFILE */ -#ifdef G_OS_WIN32 +#ifdef G_PLATFORM_WIN32 #include <sys/types.h>
pangowin32で、glibの時と同様のエラーでスタティックライブラリにされてしまう。こっちは実際に使われているライブラリなので、とりあえず「-Wl,-lgdi32」に置き換えて、リンカに直接渡すようにしたらうまく行ったようだ。 libtool良くわからん。
pangoxとpangoxftも、何故かスタティックライブラリにされてしまう。
が、とりあえず、pangowin32(とpangoft2)はうまく作れてるのだから、これを使ってGDK_WINDOWING_WIN32なgtk+をビルドすることに進もうかな。
λ. gtk+-2.0.6
最終的にはwin32用とx11用を両方作りたい。
/usr/lib/gtk-2.0/include/gdkconfig.h が衝突するのでここだけディレクトリを変更して、.pcファイルもそれに合わせて変更する必要があるかも。と思ったが、そもそも /usr/lib/gtk-2.0/2.0.6/modules以下のモジュールって共有できるんだろうか? とりあえず、今日はwin32版さえ出来れば良いので気にしない事にする。
gdk-pixbufのpixopsで、アセンブラで書かれた関係のシンボルがundefinedだと言われてしまう。オブジェクトファイルを見てみると、「_」が先頭についていないシンボルが代わりに定義されていた。.Sファイルを見ると「#ifndef __MINGW32__」で定義するシンボルを変えているようなので、試しに「#if !defined(__MINGW32__) && !defined(__CYGWIN__)」を使うように書き換えたら、うまく行ったようだ。#91597
以下のように言われる。 giochannel.hでG_OS_WIN32の時しかG_WIN32_MSG_HANDLEが定義されないのが原因。仕方ないので、G_PLATFORM_WIN32のときもG_WIN32_MSG_HANDLEだけ定義するように変更してみる。(追記: この修正は誤りなので注意)
../../../gtk+-2.0.6/gdk/win32/gdkevents-win32.c: In function `_gdk_events_init':
../../../gtk+-2.0.6/gdk/win32/gdkevents-win32.c:320: `G_WIN32_MSG_HANDLE' undeclared (first use in this function)
gdkwindow-win32.cで_MAX_PATHが宣言されてないと言われてしまう(#91681)。 仕方ないので、gdkwindow-win32.cの先頭辺りに、以下のように書いて対処。
#if defined(MAX_PATH) && !defined(_MAX_PATH) #define _MAX_PATH MAX_PATH #endif
リンク時に「.libs/libgdk-win32-2.0.lax/libgdk-win32.al/gdk-win32res.lo: file not recognized: File format not recognized」といわれてしまった。このファイルの中身を見ると、オブジェクトファイルではなく、以下のようなテキストだった。
# gdk-win32res.lo # Generated by lt-compile-resource, compatible with libtool pic_object=.libs/gdk-win32res.o non_pic_object=none
試しにgdk/win32/rcでmakeすると、以下のように言われてしまった。
windresがVPATHに対応してない?
gtk.icoをこのディレクトリにコピーしたら、ビルドできた。
../../../../gtk+-2.0.6/build/win32/lt-compile-resource gdk.rc gdk-win32res.lo Using zero as build number windres: can't open icon file `gtk.ico': No such file or directory
次に引っかかったのはgtk/gtkfilesel.c。 unistd.hとwinsock.hのgethostnameの宣言が衝突する。 Cygwinの場合はwinsock.hをincludeしないことにする。 #91654
--- gtk+-2.0.6/gtk/gtkfilesel.c.orig 2002-06-16 13:02:28.000000000 +0900 +++ gtk+-2.0.6/gtk/gtkfilesel.c 2002-08-19 12:58:08.000000000 +0900 @@ -51,7 +51,7 @@ #include <windows.h> #undef STRICT #endif /* G_OS_WIN32 || G_WITH_CYGWIN */ -#ifdef HAVE_WINSOCK_H +#if defined(HAVE_WINSOCK_H) && !defined(G_WITH_CYGWIN) #include <winsock.h> /* For gethostname */ #endif
ところで、同じファイルのtranslate_win32_path()には以下のような説明があるけど、
「//x/somepath/file.jpg」という形式のパスは古くて
もう使われていないんじゃなかったっけ?
後でcygwin_conv_to_posix_path()辺りを使うように書き換えよう。(#91843)
/* * Take the path currently in the file selection * entry field and translate as necessary from * a WIN32 style to CYGWIN32 style path. For * instance translate: * x:\somepath\file.jpg * to: * //x/somepath/file.jpg * * Replace the path in the selection text field. * Return a boolean value concerning whether a * translation had to be made. */
とりあえず、gtkfilesel.cは他にも後で手を入れる必要がありそう。
2008-08-18
λ. 自然変換の垂直合成と水平合成
こないだまで圏論勉強会で読んでいた「The Haskell Programmer's Guide to the IO Monad — Don't Panic」を ocaml-nagoya でも読んでいたようだ。 それで、活動記録/20080501 - ocaml-nagoya に自然変換の合成に関して「どこがverticalなのかよくわかりませんでした」と書いてあるのを見かけたので、ちょっと補足。
どこがverticalかというと、このテキストには出てこないけど、自然変換にはもう一つ「水平」合成があるからで、図式の描き方の慣例から「垂直合成(vertical composition)」「水平合成(horizontal composition)」と呼ばれている。
まず、以下の図のように縦に積まれた自然変換 τ と σ を合成するのが垂直合成 τ・σ : F → H で、(τ・σ)X := τX ∘ σX で定義される。
![\UseAllTwocells\xymatrix@+20pt{ C \ruppertwocell^F{\sigma} \ar[r]|{G} \rlowertwocell_H{\tau} & D }](tex/4707f7b36ea4543701f599af365b0924.png "\UseAllTwocells\xymatrix@+20pt{ C \ruppertwocell^F{\sigma} \ar[r]|{G} \rlowertwocell_H{\tau} & D }")
次に、以下の図のように横に並べられた自然変換 τ と σ を合成するのが水平合成 τ ∘ σ : F'F → G'G で、τG・F'σ = G'σ・τF で定義される。
定義の図:
![\xymatrix{F'F \ar[r]^{F'\sigma} \ar[d]_{\tau F} & F'G \ar[d]^{\tau G} \\ G'F \ar[r]_{G'\sigma} & G'G }](tex/cbc8df47312af219b508a5d3b8323c07.png "\xymatrix{F'F \ar[r]^{F'\sigma} \ar[d]_{\tau F} & F'G \ar[d]^{\tau G} \\ G'F \ar[r]_{G'\sigma} & G'G }")
ここまで書いてから気づいたけど、圏論勉強会のときも同じような図を描いてた。このときの図では、水平合成の方に黒丸「・」を使ってしまっているので、その部分はちょっと違うけど。
何故違ってしまっているかというと、合成が二つもあると射の合成と同じ記法(「τ∘σ」や「τσ」)をどちらに使うかはちょっと悩ましいんだよね。 通常は水平合成に射の合成と同じ記号を使っていて、これは2-圏とか色々な観点からは都合が良いのだけど、一方でHaskellから自然変換≒多相関数という対応で理解する場合には、垂直合成に対して関数合成の記号を使いたくもあって、このときは後者の考えで図を描いたんだろう(多分)。
