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
05/21 06:15:31 hiyuh
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
05/21 06:17:14 *
loki_val smacks hiyuh
05/21 06:17:17 hiyuh
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
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
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
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
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
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
05/21 06:36:17 loki_val
My clock would do strange things without it.
05/21 06:36:25 AStorm
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
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

(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);

[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
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
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,
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
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 :)

[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.]

なので後は、「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. :)]



nouveauのlive git ebuildが動いたので調子にコいてemergeしまくっていたら、
Xorgが起動しなくなるほどぶっ壊れた。 :P
[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 ->
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
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
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
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
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
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
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
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
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.]