予定
TODO
ふーん、
DX-7(ミク)、EOS
B200(リン)/
B500(レン)の次は
VL1(ルカ)ときたか。
とすると
WX11を咥(以下略
当時ROMpler化まっしぐらだったPCM音源ベースのシンセに対する
最後の抵抗だったなよな＞＞VA音源、
VL/VPシリーズって結局商売なったんだろうかあれ。
おいらはもう当時は「彼氏がピコピコ音鳴らしてた、別れたい」ちゅーかんじで
電子→電気への回帰でHAMMOND XB-2 + VOCE electric pianoがホスイと思ってた頃。
ちょうどAcid Jazz全盛期だったし、Free Soulのコンピ盤あたりを震源に'60〜70サウンドが流行りだした時期だし。
その空気を的確に読んでたのが正にROMplerであるE-mu VINTAGE KEYSだったような希ガス。
まぁアレだ、思い返せばレゾナンスすらないKORG M1みたいなのがバカ売れちゃった時点で
一般人に本当の意味でのシンセは不要だったんだと思う。
プリセット音しか使わないならROMplerが商売として一番おいしい訳だ。
ってもその辺はYAMAHA自身があのFM音源で「音作り＝難解」ちゅー印象を
ユーザーの脳に刻んじまったからなので自業自得だとは思うけど。
要するに何がいいたいかというとアナログとのハイブリッドLA音源マンセーということです(ぉ
でも当時RolandもLA音源を正常進化させること無くウンコ化させよったからなぁ…
D-70とかありえんかった…PWM(Pulse Width Modulation)とRM(Ring Modulator)捨てて
DLM(Differencial Loop Modulation)とか頭ウジわいてんのかと。
おかげで木管系やキレイ系なベルの音を出すのに死ぬほど苦労した。
あれ76鍵じゃなきゃ即売り飛ばしてたな…U-20の76鍵モデルと思うようにして我慢したけど。
DLMって要はPCM音素片を高速でloopさせる時に発生する折り返しノイズでしかないので
マジキチな音しか作れません、まぁノイズ好きには(^q^)おいしい機能なんだけど。
エッビマヨマヨメタルマシーンミュージック。
(追記)
元YAMAHA系音楽教室バイトの分際ですっかり忘れとったけど
あの会社はシンセで商売してるのじゃなくて、そこからの技術を惜しみなく注ぎ込んだ
エレクトーンなんかで稼いでるんだよな、最も売れたVA音源機はおそらく
EL-900あたりなんだろね。
なんせ最初のアナログシンセである
GX-1はエレクトーンの形だし
同様に最初のFM音源搭載機だった
GS1もデジピの形だしね。
シンセなんて遊びでやっててもおかしくない。
縁談チャラにするための自爆テロにウィニーでフリーソフト収集が今後流行りそうだ。
OLYMPUS-PEN D3げっと、わりと安く手に入ってホクホク。
今年の雛祭りはお内裏様がD3でお雛様がEEDのF Zuiko 32mm F1.7飾りでいくか。
風邪がさらに悪化、年始よりお休みになってしもた。
うへへcurrent-userにpatchなげとるのに誰も見てねぇのな。
もうやだ。
某所でchristos_time_t mergeするよーゆうとるけど
libc no bumpとか書いてあるのはまだこれチャンスあるって事っすかね。
あぁまだ__RENAMEつかってcompat提供したってことね。
major bumpは後でってことかー。
ということでsrc/lib/libc/shlib_versionに列挙してあるmajor bump時にすべきこと
の一覧にこっそり_ctype_ tableネタを追加しておいた。
まだMacOS X上でのcrossbuildコケるか、やっぱ買わねーと駄目そうだ。
この不況で7月以降仕事があるかすらアヤシイのにそんな大金もなー。
まぁそんときゃお世話になるかもしれない年越し派遣村だが
社民って前回選挙で議席減った後自分とこの職員切りまくってなかったっけ？
current-usersのlibc major bumpネタ、やっとpkgsrc方面への影響をみんな認識しだした風味?
さすがOpenBSDみたいに始終libcがcrunkして賽の河原状態でports作り直してる
ヒャッハーな乱世とは違って、長年__RENAME()でトラブルを避けてきたネットキ慈愛の拳。
結局3rd Partyな共有ライブラリがインタフェースにtime_tを使っちまう可能性もありなので
今回の64bit time_t化でpkgsrcなんかの再コンパイルは必須になっちゃうのは仕方ないやね。
libcだけ__RENAME()とかsymbol versioningすりゃいいってもんじゃないのが
public typeのtypedefを変更する場合の恐ろしいとこですな。
そいやLC_*を実装してnon-developerが嬉しい点をひとつ思い出した。
perlが余計な文句垂れない、だ。
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset)
LANG = "ja_JP.ISO-2022-JP"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
しかしまだLC_COLLATE実装されてないからまだ解決されてねーしｗ
まだまだPERL_BADLANG=0かー、くっくやしいビクンビクン。
結局バグ持ちか否かは
#include <stdio.h>
#include <stdlib.h>
#define CONFTEST "conftest.fparseln"
#define COMMENT '#'
int
main(void)
{
static const char delim[3] = { '\0', '\0', COMMENT };
FILE *fp;
char *ptr;
fp = fopen(CONFTEST, "w+");
if (fp != NULL) {
unlink(CONFTEST);
ungetc(COMMENT, fp);
ptr = fparseln(fp, NULL, NULL, delim,
FPARSELN_UNESCALL);
fclose(fp);
if (ptr == NULL)
exit(0);
}
exit(1);
}
んなコードを実行すりゃいいのだが、src/tools/compat/configure.acに
どう書きゃいんだべさ、GNU autotoolワカンネ。
こんな感じでいいのだろけ。
AC_CHECK_FUNCS(fparseln, [
AC_MSG_CHECKING(if fparseln seems to work)
AC_RUN_IFELSE(
[AC_LANG_SOURCE([[
#define _NETBSD_SOURCE
#include <stdio.h>
#include <stdlib.h>
#define CONFTEST "conftest.fparseln"
#define COMMENT '#'
int
main(void)
{
static const char delim[3] = { '\0', '\0', COMMENT };
FILE *fp;
char *ptr;
fp = fopen(CONFTEST, "w+");
if (fp != NULL) {
unlink(CONFTEST);
ungetc(COMMENT, fp);
ptr = fparseln(fp, NULL, NULL, delim,
FPARSELN_UNESCALL);
fclose(fp);
if (ptr == NULL)
exit(0);
}
exit(1);
}
]])],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
AC_DEFINE(BROKEN_FPARSELN, 1,
[Define if your `fparseln' function is broken.])],
[AC_MSG_WARN([cross compiling: not checking farseln])],
)
])
そかしsrc/tools/compat/configureはautoconf-2.52なのだがpkgsrcは既に2.63だ。
2.52を拾ってこないと駄目なのかしら。
結局localにautoconf-2.52入れた。
相変わらず風邪っぴき、体温が38度超えとるわー。
今回のlocale-db問題の口火となった、長年放置プレイの
lib/10877を
突然commitしてくれよった人から、何を今更( ゜д゜)ポカーンな質問メールきとる。
な…… もしや…tech-userlevel……購読してない……だと…？
*1
いやbugathonとか参加してsend-prを積極的にcloseすんのは偉いと思うけど
PRと一緒に送られてくるFIXが常に正しいとは限らんのですよ。
言葉は悪いけど、無能な働き者by ゼークトにはならん様に注意しようぜ。
まぁ誰かがこのFIXに対してイローンハンローンobjection投げときゃよかったんだろうけど
あまりに古いサブマリンPR過ぎて俺も存在を知らなかったという。
Citrusのドキュメントを作文するだけの簡単なお仕事です。
とりあえずFreeBSDとLinux、NetBSD-4.0で動作確認した
patch。
まだいろんなメールの返事書いてないのでそれが終わったらcommitすんべ。
と思ったらcurrent-userで騒ぎになってるのでpatchだけ晒してみた。
風邪が治らない。
fparseln(3)のバグ踏んだ件の修正と、MacOS Xでcross buildする場合に
FreeBSD由来のRuneの呪いが発動する報告がcurrent-userにあったのでそっちも修正。
cross環境もつくっときゃ直ぐ気づいたんだろが。
残るはLC_COLLATE → multibyte regex(3) → localedef(1)か、なんという男坂。
昔yamtさんが書いたcollationの実装ってどんなんだっけか読んでみるか。
あとTR14652の完全実装をすべきか、LC_ADDRESSとかLC_PAPERってどれくらい使われてるんだ…
そもそもこのデータを利用するAPIがドキュメントにないのがアレ過ぎる…
joerg氏がなんか per thread-locale vs multi-locale ちゅう比較をして
前者はらめぇとかtech-userlevelに投げてきたのだが
そもそもThread Aware Locale Modelって
なのでどっちがいいという話じゃなくて、両方実装するのだよな。
ポイントずれとれ。
ctype.hのマクロとか重々承知してますわ。
つかせっかくftpに置いてるんだから実装みてちょ。
あとでまとめてメール書く。
FreeBSDの/usr/include/ctype.hのたぶん
rev1.27でNetBSDの定義とconflictするのが復活しとる。
よって今朝のcommitだけじゃcross-tools作れんわ。
ctype.hでis*/to*をinlineやmacroにして性能稼ごうとかもう止めようよ…
これ直すのかったるいなー。
MacOS Xだとどうんなんだろ、やっぱ買わないと駄目か。
ちなみに私を
*BSDに引っ張り込んだツレの正体は狂信的マカで
Pipin@買えば幸せになるとかこれからはCopelandの時代とか
YellowBox for Windowsで救われる、などと意味不明な供述を繰り返しており
まったく欲しいと思ったことがこれまでなかったんだが。
一番簡単な方法はMacOS XやFreeBSDがrunetype.hをpublicにしとるので
こっちのprivateなrunetype.hをrunetype_local.hとかにリネームしちまうかだな。
netbsd-4でfparseln(3)のバグ踏んじまう件も駄目だわｗｗｗ
そもそもnon-portableだから既にlibnbcompat.aがこれ持ってるんだな。
でもlibcにすでにfparseln(3)が存在する場合そっちを優先して
libnbcompat.aの中のfparseln.loは空っぽになってるわけだ。
つまりこれconfigureによるチェックでlibc側のfparseln(3)がバグ持ちか否かを
チェックせんとあかんちゅーことだ…これは萎える…
agc氏がokゆうとるのでcommitしてまった、ついでにnviも。
ああっ、もうダメッ！
ぁあ…commitするっ、commitしますうっ！！
いやぁぁっ！あたし、こんなにいっぱいcommitしてるゥゥッ！
しかしcommit logふいた、これやっぱ枝切るべきだったろ。
mklocale(1)作り直しになるので多分src/UPDATINGも追加しないとならんはずだけど
とりあえず放置(ぉ
wizd(8)やっぱすげー、つうかいつもありがとう、ナンマンダブ。
ちなみに今回commitしたpatchだとlocale-dbはインスコされます。
ですのでmultibyte regex問題とかdate(1)の出力がひどい件については
あきらめましょう(ぉ
風邪なおらんね、おかげで駅伝の往路からサザエさん症候群発症しそうだわ。
WAPBLが刺さらんようになったのでs/softdep/log/に戻してみた。
とりあえずbuild.shくらいじゃ刺さらないくらいには安定してるっぽい。
うーん、tech-userlevelなんかキター。
reed氏にLC_{MONETARY,NUMERIC,TIME,MESSAGES}実装して何がうれしいかとか
citrus_db使う事で開発者「以外」がなんかメリットあるかを
説明できる自信が全くないぞ。
なんせ実装した俺自身がひとっつも嬉しくないからな(ぉい
基本的にはバイナリ互換で将来的にgdgdになるのを回避できるのと
localeのキャッシュメカニズム突っ込んだのでちったー早くなるかってのと
(計測してないからびみょーですが)、このキャッシュを導入したことで
multi-localeの実装が楽になって、libstdc++ウマーってくらいしかないのよな。
つまりはあくまで開発者ネタでしかないとゆー。
chrtbl(1)についてはありゃSysV由来のゾンビなので放置でおｋ。
本来はmklocale(1)だって4.4BSD由来(つかFreeBSD？)のゾンビなので
ばっちいからポイしないとアレなんですが、localedef(1)でstateful encoding support
を考えるとかなり頭の痛い話になるので、とりあえずmklocale(1)に実装しちまえ
というグータラな発想でやってるからな。
とりあえず身も蓋もない返事書いて投げた。
デレツンなメールきた。
要約すると「おめでとう、でもまだそっちが正しいとは思ってないんだからね！」
あーぁ、別にあのまま表面上plain-text dbでもよかったんだよな。
んで結局/var/cache/locale/*/LC_*ちゅーMDデータ生成した挙句
二度とlibcはMIなplain-text dbは読まねぇｗとかいう
返し技もあるんだけど…まぁ/varの容量がアレですな。
しかしなんでそんなにFreeBSDの実装にこだわるんだろか。
こうなったらFreeBSDも
*1(滅多な事言わない
つか「でももうlex/yaccで書いてたlocaledef(1)、止めます」って
lex/yacc使うより手書きparserじゃないと逆に手間かかりすぎると思うんだけど。
なんせcharmap/localedefはcomment char/escape charを自由に変更可能だから。
それに
ISO/IEC TR14652のinclude directiveとか実装しようとすると氏ねるからなぁ、yyparse()じゃなぁ。
前段にcpp(1)噛ますのと訳違うし…。
NetBSDならfparseln(3)使ったほうが逆に簡単に書けるってば *2。
ということを繰り返しsodaさんと私で説明してるはずなんだがな。
Citrusにはドキュメント皆無なことに文句言われたけど、まぁそれはゴメン。
wiz氏にもmkcsmapper/mkesdbのman書けやゴルァいわれてたな…
まるでそびえ立つようなtemplateもどきマクロとヘッダの嵐だから
慣れないと読みづらいかもね、それこそ今回のコードはOpenBSDに
永遠にmergeされない自信がある。
さっさとsrc/external/bsd/citrusにでもごっそり移動して整備すべきなんだな。
しかしそれやるにはもっとCitrusとlibcの分離を進めないと厳しいのよな。
結局それはmulti-localeでやる予定だったのでしばらくはむりぽ。
Solaris並みのアレな分離をすればなんとか、なぁ…
ちゅかsrc/external/bsd/citrus/docだけ掘るかの。
こうしてTODOで埋もれていくんだなー。
i'm sinking in the quicksand of my thought and i ain't got the power anymore
そもそもあっちで実装してるlocaledef(1)がplain-text db formatを出力するなら
今回おれが魔改造したmklocale(1)にpipe(8)すりゃいいだけなんだけよな、よく考えると。
止める必要もなかろうとでも返事書くかー。
というか書きかけでいいから実装見せて欲しいよな、こっちも書きはじめたばっかの
プークスクスなのを以前tech-userlevelに投げたりしてるのに、ショボーン。
lib/40317 ぶ、よりによってnetbsd-4のfparseln(3)にあるバグ踏んだ。
つかmklocale(1)はtoolchainなのでfparseln(3)のよなportableではない
関数使う場合は自前でlinkしないと駄目ですな。
build.sh便利だけど結構大変ですお、移植性ヘル。
例のメールへの返事もかかなあかんので明日だな、でんでんでんぐり返って(以下略