if (repo.st == BROKEN) do_release(&repo.src);

commit日常茶飯事upstream devsとbug世話人distro devsの憂鬱（？） :)
[T3h antinomy(?) of upstream and distro devs. :)]

05/21 06:09:48 loki_val
    Why is it whenever an upstream starts talking about doing unversioned
    releases right from git, I get the urge to crush some nuts and
    eat them?
05/21 06:10:06 loki_val
    YOU'RE UPSTREAM. RELEASES'R'YOU!
05/21 06:15:31 hiyuh
    hmm
05/21 06:16:31 hiyuh
    loki_val is a sucessor of jakub?
05/21 06:16:35 *
    hiyuh hides
05/21 06:17:11 loki_val
    hmmm...
05/21 06:17:14 *
    loki_val smacks hiyuh
05/21 06:17:17 hiyuh
    lol
05/21 06:17:23 loki_val
    sorry, don't have the class
05/21 06:18:11 eroyf
    nor the mentallity
05/21 06:18:17 darksiide
    Ingmar: new jeeves?
05/21 06:19:01 loki_val
    hilighted you
05/21 06:19:58 eroyf
    i saw it and ignored it
05/21 06:21:07 bonsaikitten
    loki_val: try fedora
05/21 06:21:35 loki_val
    bonsaikitten: sry, only works with distros that won't compile.
05/21 06:21:37 bonsaikitten
    loki_val: after seeing that mess you'll understand that releases
    are fubar by default and unversioned won't break stuff
05/21 06:22:10 bonsaikitten
    loki_val: the fedora installer, it treats serious errors (like kernel
    not installable) as unimportant warning that the user won't even see
05/21 06:22:14 bonsaikitten
    wtf ...
05/21 06:22:50 loki_val
    Unversioned doesn't break stuff. But one thing's for certain; if
    nothing's versioned, it won't ever be release-worthy.
05/21 06:23:17 loki_val
    It's just a point in time when the software doesn't suck as much as
    it usually does.
05/21 06:32:07 AStorm
    loki_val: you're so wrong
05/21 06:32:31 AStorm
    release is the point in time when CDs are made and every development
    is frozen
05/21 06:32:40 AStorm
    so only so-called "stable changes" are made
05/21 06:32:41 bonsaikitten
    erm
05/21 06:32:46 bonsaikitten
    AStorm: dude ... what??
05/21 06:33:03 loki_val
    AStorm: I dare you to run git kernel.
05/21 06:33:11 loki_val
    Please.
05/21 06:33:13 AStorm
    loki_val: I do, so what?
05/21 06:33:20 Ken69267
    I ran a git kernel for about 5 months straight no probs
05/21 06:33:30 AStorm
    it's 97% of time stable. Or more.
05/21 06:33:43 AStorm
    they are versioned
05/21 06:33:45 bonsaikitten
    which one?
05/21 06:33:49 bonsaikitten
    97 or more?
05/21 06:33:51 AStorm
    they are more finely grained versions
05/21 06:34:06 AStorm
    bonsaikitten: 97% was a pessimistic estimate for Linux tree.
05/21 06:34:25 loki_val
    Dude, what you call finely grained version, we call "not production
    ready".
05/21 06:34:36 AStorm
    you're wrong too
05/21 06:34:45 AStorm
    who does the testing deeming it "production ready"?
05/21 06:34:57 AStorm
    Do your homework, instead of relying on someone to do it for you.
05/21 06:34:58 loki_val
    You need at least a bit of QA on a version before you put it into
    production.
05/21 06:35:04 AStorm
    ...
05/21 06:35:08 pchrist|univ
    loki_val: show us your "uname -r" :P
05/21 06:35:09 loki_val
    I don't have the time for that.
05/21 06:35:20 AStorm
    loki_val: excuses, they're always good.
05/21 06:35:30 AStorm
    :-)
05/21 06:35:40 loki_val
    pchrist|univ: 2.6.23.12-hrt5
05/21 06:35:50 AStorm
    devel tree
05/21 06:35:58 AStorm
    :-)
05/21 06:36:01 loki_val
    Nahh, patches for my own comfort.
05/21 06:36:10 pchrist|univ
    you AStorm ?
05/21 06:36:10 AStorm
    hrtimer tree?
05/21 06:36:14 pchrist|univ
    :P
05/21 06:36:17 loki_val
    My clock would do strange things without it.
05/21 06:36:25 AStorm
    2.6.25-rc8-electric1
05/21 06:36:39 loki_val
    That's like SOO old.
05/21 06:36:48 AStorm
    need to update it some day
05/21 06:36:50 AStorm
    too lazy
05/21 06:36:55 AStorm
    it's stable
05/21 06:37:47 AStorm
    what I don't get is people publishing kitchen-sink patchsets :>
05/21 06:37:48 hiyuh
    hmm, upstream's live one is ok to use? then why releases are b0rken
    one? t3h devs will break their code in repo to release?
05/21 06:38:01 AStorm
    hiyuh: not exactly
05/21 06:38:15 AStorm
    it's just releases aren't any more stable than main git tree
05/21 06:38:22 loki_val
    HAHAHAHAHAHA!
05/21 06:38:33 *
    loki_val giggles
05/21 06:38:37 AStorm
    Linux has no real cooling period
05/21 06:38:43 AStorm
    (I mean the kernel)
05/21 06:38:51 AStorm
    unlike Firefox for example
05/21 06:39:04 *
    hiyuh breaks his code to make t3h release.
05/21 06:39:15 AStorm
    mwhahaha

(AStorm and loki_val continue to argue about it)

個人的にはupstream repoから直接パクってきたモノだろうとreleaseしたtar玉だろうと、
少しぶっ壊れている方が可愛気があって好きだったりするが、その辺りのサジ加減が問題かも。
releaseすべきか、せざるべきか、それが問題だ。 :P
[Personally, I kinda prefer to play recent sources (no matter it was live one
or tarball) w/ itty-bitty bugz. But I can't say it's for all users.
It's DA question of degree. "release or not, it's DA problem." :p]

pROM = genROM(&fsckin_IO_rel);

#vhdlにて。
[At #vhdl.]

05/09 20:38:20 _vanpelt
    hi, i have to convert an 7bit input signal to another output
    signal. the converting table is very large. is it better to query
    an array or to write a very long "when" statement?
05/09 20:48:26 hiyuh
    input synchronously, covert it synchronously, output
    synchronously... this is common way to function w/ faster0rz clock
    but input-to-output latency is large.
05/09 20:48:36 hiyuh
    asynchronously convert directly input to output is shortest
    input-to-output latency, but it won't function w/ faster0rz clock.
05/09 20:48:51 hiyuh
    so it's up to you.
05/09 20:49:06 _vanpelt
    the whole architecture is asynchronous
05/09 20:50:37 hiyuh
    if you intended to make it to be asynchronously w/o paticular reason,
    then I'd have to say it's bad design.
05/09 20:51:23 _vanpelt
    hiyuh: i have to implement it after a given design :) no possibility
    to make it synchron
05/09 20:54:36 hiyuh
    wtf :p
05/09 21:10:14 _vanpelt
    hiyuh: its from my university :)
05/09 21:11:33 _vanpelt
    hiyuh: but theoretically it makes no difference whether to query
    an array or a waste when list am i right? because the number of
    comparations is equal?
05/09 21:14:41 hiyuh
    nah, it depends what signal will be inputed, how signal will
    be converted, what signal will be outputed, and what device and
    synthesizer are you using. :p
05/09 21:15:37 _vanpelt
    hiyuh: i don't need any synthesizers or devices. it is for simulation
    only
05/09 21:16:26 _vanpelt
    hiyuh: or to ask the other way, what is more elegant?
05/09 21:20:59 hiyuh
    IMHO, how signal will be converted is really complex and looks like
    randomly, pre-generated constant array to output by input signal
    indexing is what I'd code.
05/09 21:21:42 hiyuh
    the array will be generated by TSV and/or SSV (maybe I'll generate
    it by using some program or its spec) w/ awk(1p) and/or sed(1p) script
05/09 21:23:15 hiyuh
    how signal will be converted is simple or semantical, just code
    function. then use it like, "output <= MyAwesomeFunction(input);"
05/09 21:23:16 _vanpelt
    how do you mean input signal indexing?
05/09 21:24:18 hiyuh
    output <= MyAwesomeConstantArray(input1 & input2 & input3
    & ... & inputN); <--- this looks like indexing.
05/09 21:25:01 _vanpelt
    hiyuh: ok. but there is no function that is able to actualy
    calculate the value according to input. the numbers in the array
    are to independent
05/09 21:26:09 _vanpelt
    so i could implement binary search or something but i think that
    this would go a step to far, doesn't it?
05/09 21:27:39 _vanpelt
    the problem is that there is no function that could calculate the
    position of the result from the input value
05/09 21:28:37 hiyuh
    eh?
05/09 21:28:49 hiyuh
    so I'd have to say no idea.
05/09 21:28:50 hiyuh
    I haven't seen desired I/O logical relation what you're talking about.
05/09 21:29:19 hiyuh
    I'm moronic coder, no code (or spec) is no help.
05/09 21:31:16 _vanpelt
    hiyuh: ok sorry for being so imprecise. the input vales range from
    1500 to 300. but not every value is needed. for example only 1500,
    1463,1428,...
05/09 21:31:35 hiyuh
    ok, then?
05/09 21:31:59 _vanpelt
    but the output values are constantly increasing 40,41,...
05/09 21:32:48 _vanpelt
    so what i have to do is asigning 1500 -> 40, 1463 -> 41,...
05/09 21:34:39 hiyuh
    heh, so you have that entire of fsckin' I/O relation already?
05/09 21:35:23 _vanpelt
    yes i have a table on paper for this huge list
05/09 21:38:42 hiyuh
    ok, then generate constant ROM declaration from that fsckin' list
    into package vhdl by hand or script or something.
05/09 21:38:43 hiyuh
    then use it like "output <= MyAwesomeConstantROM(input);" w/
    "use work.MyAwesomeConstantROM.all;"
05/09 21:40:14 _vanpelt
    wouldn't that produce overhead because then i would have to generate
    an array of 1500 elements and use only 300 of them
05/09 21:41:44 _vanpelt
    because i could asign the input values the position of the output
    values in the array, search in the array for the right input value
    and return the position
05/09 21:44:42 _vanpelt
    i really appreciate your patience :)
05/09 21:44:59 hiyuh
    nah, create "input_value output_value" TSV or SSV, sort(1p) it by
    input_value, use script or program to generate constant ROM by using
    dummy stub value (which won't output).
05/09 21:46:30 _vanpelt
    hiyuh: ok i will do it that way. thanks a lot for your help!
05/09 21:46:57 hiyuh
    np, good luck. :p
05/09 21:47:11 _vanpelt
    hiyuh: really great. thanks

05/09 23:57:44 _vanpelt
    hiyuh: i got another, this time hopefully simplier question. i just
    read a vhdl performance manual. is it really true to prefer integers
    over slv's?
05/10 00:02:51 hiyuh
    _vanpelt: performance for what?
05/10 00:02:53 hiyuh
    shorter simulation runtime? shorter synthesizing time? function w/
    faster clock? lower power or current?
05/10 00:03:52 hiyuh
    and wth is vhdl performance manual??? :p
05/10 00:04:07 _vanpelt
    hiyuh: if i have nothing like that specified, which optimization
    should i use? as it is mainly simulated for simulation?
05/10 00:04:51 _vanpelt
    hiyuh: the paper is called "VHDL Style Guidelines for Performance" :)
05/10 00:07:27 hiyuh
    BWK and RP said like that, IIRC. "first of all, to optimize your code,
    don't optimize it."
05/10 00:08:09 _vanpelt
    hiyuh: :) ok
05/10 00:09:27 _vanpelt
    hiyuh: but could i say that using slv's i am closer to the hardware
    and so it is better when synthesizing it or running it on an FPGA
05/10 00:13:09 hiyuh
    for synthesizer, good one can optimize your code w/ runtime options
    than your hand-optimize.
05/10 00:13:17 hiyuh
    but bad one produces ton of craps. :p
05/10 00:15:15 hiyuh
    FYI. for simulation, good one can optimize your code JIT than your
    hand-optimize.
05/10 00:15:19 hiyuh
    but bad one takes so looooooooong time. :p
05/10 00:14:54 _vanpelt
    hiyuh: ok. thanks again. i wont annoy you again today :)

他の言語でも俺様コードジェネレータをでっち上げるのは良くある事だし、最近は王道のスタイルで
書かれたコードをマトモなツールで使えばキチガイの様に手で最適化する必要は殆ど無い。
勿論、VHDLのRTLデザインはハードウェアに突っ込まれるので、I/Oの位置やタイミング制約で
悪足掻きする事はかなりあるけど、それは元のブツが王道のスタイルで書かれている方が弄りやすい。
[Codin' code generator is nice lazy way, that's not only for VHDL. T3h royal road style code w/ suckless tools won't require any of hand-uber-optimization, recently.
Yup, RTL level VHDL is intended to be into the device, so it has many I/O location and its timing restriction. But before poking it for these ton of restriction, original one as royal road design is the best one to start.]

シミュレータは、マトモなモノはそれなりに優秀で、JITな感じで動いているのは見ているだけで
大体分かる。
なので後は、「delta delayが少ないスタイルで書かれているか、否か？」でシミュレーションに
必要な時間が決まるんじゃないかと妄想している。
で、某G社の人が提唱しているスタイルが最強ではないかと思うのだがどうか？ :)
[Recently, simulator becomes suckless a little. I guess it run w/ JIT optimization in my exp.
So, the last curse is "how many delta delaying　is required to simulate it?", IMHO.
Then, t3h G guy sez awesome royal road style, so I was really surprised. :)]

calDPI(NV) != calDPI(NOUVEAU|RANDR12_ON)

nouveauのlive git ebuildが動いたので調子にコいてemergeしまくっていたら、
Xorgが起動しなくなるほどぶっ壊れた。 :P
で、#nouveauで泣きをイれてみる。
[nouveau just worked, so I remerge it sometimes. It b0rk0rz my X. :P
So I asked devs at #nouveau.]

05/08 00:25:58 hiyuh
    hmm, updating nouveau on my pb. it breaks my X. :p
05/08 00:38:29 marcheu
    hiyuh: bisect, and then blame someone :)
05/08 00:41:17 hiyuh
    zomg :)
05/08 00:44:30 hiyuh
    I can't startx w/ nouveau by using the overlay atm. it seems to b0rk
    at loading (or initializing) nouveau_drv.so.
05/08 00:47:50 pq
    so look in Xorg's log
05/08 00:49:27 hiyuh
    pq: any easy way to bisect by using the overlay's
    xf86-video-nouveau? setting EGIT_blah?
05/08 00:49:54 pq
    hmm... I don't that would be an easier option
05/08 00:50:41 pq
    git-clone the nouveau DDX repo, build it, and make a symlink from
    where the ebuild installed the driver to the hand-built drv.so
05/08 00:51:33 pq
    for instance, I have
    /usr/lib/xorg/modules/drivers/nouveau_drv.so.devel ->
    /home/pq/nouveau/xf86-video-nouveau/src/.libs/nouveau_drv.so
05/08 00:52:01 hiyuh
    ah ok.
05/08 00:52:09 pq
    then I just do the link nouveau_drv.so -> nouveau_drv.so.devel when
    I want to switch to the hand-built version

05/08 01:57:11 hiyuh
    pq, marcheu: http://dev.gentoo.gr.jp/~hiyuh/misc/nouveau-bisect.log
05/08 01:57:52 marcheu
    hiyuh: you're saying it's 52e58c7e799697989fcfbf95050ce10a4c3d1f8f ?
05/08 02:04:32 hiyuh
    marcheu: I guess so.
05/08 02:05:34 pq
    hiyuh, when the bisection completes, git says something like "the
    first bad commit is..."
05/08 02:06:06 pq
    I'm not sure how to read the bisect log
05/08 02:07:06 hiyuh
    http://dev.gentoo.gr.jp/~hiyuh/misc/b0rk-Xorg.0.log
05/08 02:07:55 hiyuh
    all bad rev does vomit like this.
05/08 02:09:36 pq
    hm, script execution segfaults
05/08 02:09:44 pq
    hiyuh, btw. please enable randr12
05/08 02:09:47 marcheu
    hiyuh: I blame malc0  :)
05/08 02:10:13 hiyuh
    lol
05/08 02:12:54 hiyuh
    pq: randr12 works kinda bit. but it shows me larger and bolder fonts
    on gtk app.
05/08 02:12:59 hiyuh
    for testing is ok, but "do enable it always" is not good for me atm.
05/08 02:13:09 marcheu
    hiyuh: what are the issues with it ?
05/08 02:13:26 marcheu
    hiyuh: can't you force another dpi ? AFAIK what randr12 does is
    correct
05/08 02:13:30 marcheu
    or use smaller fonts..
05/08 02:15:35 hiyuh
    well, I'm not good at tuning xorg.conf. I just replaced "nv" to
    "nouveau". http://dev.gentoo.gr.jp/~hiyuh/misc/xorg.conf
05/08 02:16:00 marcheu
    I think "nv" has incorrect dpi computation...
05/08 02:16:07 hiyuh
    zomg :)
05/08 02:16:25 marcheu
    the right thing to do is configure your font size in whatever app
    you use
05/08 02:16:35 marcheu
    or force dpi but that's pretty dirty
05/08 02:16:57 pq
    you can also calculate what the true dpi is and see which one
    is closer
05/08 02:17:09 marcheu
    I think I've been looking at pb12 logs before (yours ?) and they
    reported proper size with randr12 but not default
05/08 02:22:19 hiyuh
    heh
05/08 02:24:47 marcheu
    they didn't ?
05/08 02:25:02 marcheu
    the detected size should be displayed in the logs
05/08 02:27:03 hiyuh
    marcheu: hmm? are you saying "show me the Xorg log w/ randr12
    enabled"?
05/08 02:27:28 marcheu
    I'm saying you should check the reported size is correct
05/08 02:27:41 marcheu
    which would mean the dpi is in turn correct
05/08 02:27:46 marcheu
    I don't want the logs, I'm pretty sure it is
05/08 02:30:06 hiyuh
    well, how can I check whether it was correct or not?
05/08 02:30:09 hiyuh
    running Xorg w/ randr12 enabled then what?
05/08 02:30:39 marcheu
    the screen size is in the logs
05/08 02:36:03 hiyuh
    nv sets (75, 75). w/ randr12 off, nouveau sets (75, 75). w/ randr12
    on, nouveau sets (108, 144)
05/08 02:38:16 marcheu
    sure, because nouveau with randr12 takes the screen size into account,
    which is the correct thing to do
05/08 02:38:21 marcheu
    look in the logs for the screen size
05/08 02:38:27 marcheu
    you'll see that it's the right one
05/08 02:38:32 marcheu
    but I'm repeating myself somehow
05/08 02:40:23 hiyuh
    so, (108, 144) is correct DPI?
05/08 02:40:44 marcheu
    so.
05/08 02:41:09 marcheu
    to compute the DPI, you divide the size in pixels by the size
    in inches
05/08 02:41:16 marcheu
    the size in pixels is the same
05/08 02:41:34 marcheu
    now feel free to do the computation yourself
05/08 02:41:59 marcheu
    and really I'm leaving before this stuff drives me crazy
05/08 02:42:04 pmdata
    !INCREASE your dpi! PLIZ YOUR EYES
05/08 02:42:54 marcheu
    and really, we're not going to fuck up dpi calculation because it
    makes font too big or too small. it's up to the apps to be configured
05/08 02:42:57 marcheu
    bbl
05/08 02:43:15 pq
    btw. the size in inches is horizontal or vertical, not diagonal
    marketing inches :-)

つーことで、git repoの方はmalc0様々がそのうち直してくれるだろうと勝手に期待して待つことにする。
randr12 onなnouveauはnvとDPIがモロ違うっぽいのでフォントはアプリ側で調整する方法で行くかな。
[So I'm waiting official fix for this b0rkage by malc0 or someone who read t3h log.
ATM, w/ randr12 on, nouveau sets different DPI from nv's (is incorrect?).
T3h way to stick nouveau w/ randr12 on, I'll set appropriated font size as the app side setting.]