00:12.44 |
Twingy |
moderate drop in stocks today |
00:53.26 |
*** join/#brlcad ``Erik
(i=erik@c-69-250-155-85.hsd1.md.comcast.net) |
01:58.38 |
Twingy |
all state is a rip off |
01:58.42 |
Twingy |
they want $70/mo more than geico for the same
thing |
02:02.56 |
brlcad |
all hail the gecko |
02:03.20 |
brlcad |
(i.e. throw the lizard as far as
possible) |
02:03.38 |
Twingy |
you fix those bugs yet? :) |
02:17.56 |
brlcad |
what bugs? the librt thing? |
02:18.57 |
brlcad |
that's been in there since I first compiled on
freebsd amd64 iirc, looked entirely like a bug in gcc's optimizer
or the threading library |
02:19.10 |
Twingy |
hrm |
02:19.33 |
brlcad |
if you walk through it in gdb, the stack just
goes "poof" mid computation (if you can keep gdb from crashing
itself) |
02:19.47 |
brlcad |
i never got to try a different threading
library |
02:20.47 |
brlcad |
there was a thread on the freebsd bugs mailing
list about a threading bug related to amd64 and crashes inside
system libraries (which is where the stack was going poof, sprintf
and similar funcs) |
02:21.40 |
brlcad |
this was like 8-12 months ago when first got
access to such a configuration iirc |
02:23.24 |
brlcad |
gdb was almost useless, the only next step I
can think of outside of trying different threading library would be
to valgrind a simple raytrace and make sure the errors are cleaned
up (which has never been done) |
06:20.26 |
*** join/#brlcad PKMOBILE
(n=Apathy@c-68-33-243-45.hsd1.md.comcast.net) |
07:32.16 |
*** join/#brlcad DTRemenak
(n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) |
08:51.24 |
*** join/#brlcad sehh
(n=sehh@88.218.28.143) |
08:51.32 |
sehh |
hey people |
08:51.54 |
sehh |
is brlcad SMP-aware (multi-threaded,
etc)? |
09:10.42 |
*** part/#brlcad sehh
(n=sehh@88.218.28.143) |
09:10.50 |
brlcad |
meh |
09:10.53 |
brlcad |
'yes' |
10:43.48 |
*** join/#brlcad pier
(n=pier@151.56.213.160) |
15:06.26 |
*** join/#brlcad pier
(n=pier@151.56.213.160) |
19:25.19 |
*** join/#brlcad ``Erik
(i=erik@c-69-250-155-85.hsd1.md.comcast.net) |