00:01.40 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
00:05.46 |
Ralith |
heh |
00:37.26 |
*** join/#brlcad mafm
(n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) |
01:43.28 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
02:36.00 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
04:04.33 |
starseeker |
is fried, but the cedar
closet is (essentially) done |
04:05.22 |
starseeker |
and the gentoo box goes through (yet another)
tramatic update, successfully. |
04:05.36 |
starseeker |
There seem to be a lot of backwards
incompatible changes lately |
04:05.46 |
starseeker |
probably for the best, but eeek |
04:45.59 |
*** join/#brlcad puddingpimp
(n=dave@118.93.87.238) |
07:40.32 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
07:46.03 |
Ralith |
starseeker: this is why I stopped using
gentoo. |
07:46.31 |
Ralith |
"okay, routine system upâOH GOD WHERE'S MY
X" |
09:27.22 |
Maloeran |
Pretty much. With Gentoo, it's best to upgrade
only what you strictly need... and hope for the best |
11:06.17 |
d-lo |
mernin! |
11:06.51 |
archivist |
with gentoo upgrade to a sane distro
asap |
11:11.28 |
``Erik |
*yawn* |
11:12.22 |
``Erik |
is glad he uses fbsd, updates
are neither traumatic nor unsafe O.O |
11:13.40 |
``Erik |
there was this one time, in band camp, when I
did a massive upgrade on an ancient system and it was a bastard
stopgap patch (still is), so several ports failed, but portmanager
gives you pre-upgrade pkg's, so it was trivial to undo the mucked
up parts of the upgrade... definitely a corner case situation,
though :D |
11:14.21 |
``Erik |
(I mean, seriously, who in their right mind
would still be running 5.2.1? it was so... screwed up that they
changed their numbering system just for that one release) |
11:15.43 |
archivist |
my old debian screwed up on an update, about 5
years ago, its still up though |
11:16.58 |
``Erik |
:D stable or testing? |
11:17.24 |
``Erik |
I had some interesting experiences with
unstable, and stable was just too out of date, I used testing for a
lot of my debian boxes back in the day |
11:18.10 |
archivist |
cant remember but uname responds with
2.4.27-2-686-smp #1 SMP Mon May 16 16:55:31 JST 2005 i686
GNU/Linux |
11:18.39 |
``Erik |
should be an /etc/debian file |
11:18.43 |
``Erik |
iirc |
11:19.00 |
``Erik |
or look at your apt config file :) |
11:19.21 |
archivist |
3.1 |
11:19.56 |
``Erik |
according to this chart, it's
"sarge" |
11:20.21 |
``Erik |
6 june 2005, support ended april
2008 |
11:22.22 |
archivist |
these old boxes run and run |
11:23.05 |
archivist |
it is on its last month or so |
11:29.16 |
archivist |
this job has ended and I have to move the
servers home |
12:01.29 |
Yoshi47 |
45812:11 mged |
12:17.28 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
12:27.59 |
``Erik |
put a bullet in its head, yoshi, it probably
put itself in an infinite loop (or went into the "it'll finish.. in
a few thousand years" mode) |
12:44.43 |
brlcad |
blames the
ISP |
12:51.29 |
``Erik |
eh? |
12:51.47 |
``Erik |
(looks like everyone using bz got
peered) |
12:53.32 |
_clock_ |
who has worked on PDP-1? |
13:21.17 |
CIA-33 |
BRL-CAD: 03bob1961 * r36183
10/brlcad/trunk/src/tclscripts/archer/AttrGroupsDisplayUtility.tcl:
Added methods for reading/writing attribute groups and mappings.
Added a method to export to png. |
13:42.30 |
brlcad |
``Erik: bz rebooted unexpectedly |
13:45.28 |
brlcad |
_clock_: pdp wasn't interesting until pdp-8,
and even then pdp-11 was where it was at |
13:48.02 |
Yoshi47 |
``Erik, do i have too? can't i wait till my pc
turns off or restarts? lol |
13:51.35 |
brlcad |
:) |
13:51.40 |
``Erik |
pdp7 had some niftiness iirc |
13:51.43 |
Maloeran |
45812 minutes? Isn't that like... a
month? |
13:51.59 |
``Erik |
(wasn't the pdp8 just a souped up 7? or was
that the big abi break?) |
13:52.03 |
Yoshi47 |
yep |
13:52.20 |
``Erik |
lisp on a pdp1 was awesome, simh ftw |
13:52.29 |
Maloeran |
A month. You are being optimistic, I see...
:) |
13:53.06 |
Yoshi47 |
nope just don't have time to work on it
anyways |
13:53.18 |
Yoshi47 |
so just like to see it will finish or
not |
13:53.53 |
``Erik |
if it doesn't finish in a day or two, it
probably won't finish in your lifetime :( |
13:53.56 |
Maloeran |
I guess it's only using 100% of one CPU core,
so it isn't that bad |
13:54.02 |
Yoshi47 |
yep |
13:54.34 |
Yoshi47 |
ok well when i need my other core or the power
goes out or some idiot comes by and does something then iguess that
will be the end |
13:54.59 |
brlcad |
it's an O(n^3) algorithm .. and that's a
pretty big 'n' it's crunching on |
13:55.00 |
Maloeran |
wonders if there are ways to
randomly query the EIP of a running program, to have a clue what
it's doing |
13:55.20 |
brlcad |
so it will probably finish .. just unclear if
it's days/weeks/months/years |
13:55.53 |
``Erik |
millenia |
13:55.58 |
brlcad |
(and single-cpu, so it's not exactly burning
the midnight oil) |
13:57.11 |
``Erik |
let's see, we're in the cenozoic era, what
comes next? :D |
14:26.13 |
brlcad |
the "flying spaghetti monster hath forsaken
us" era |
14:34.43 |
``Erik |
well |
14:34.51 |
``Erik |
that's the biblical name, the age of
truth |
14:34.55 |
``Erik |
:) |
14:49.09 |
``Erik |
hey, uh, starseeker? |
14:49.49 |
``Erik |
y'know that old mkVIII or whatever you were
putzing with? was survice involved in that? |
14:54.48 |
*** join/#brlcad mafm
(n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) |
15:31.28 |
CIA-33 |
BRL-CAD: 03bob1961 * r36184
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Tweak the attr
method. |
15:41.20 |
*** join/#brlcad starseeker
(n=starseek@BZ.BZFLAG.BZ) |
15:41.45 |
starseeker |
mutter... dead terminal... |
15:43.57 |
CIA-33 |
BRL-CAD: 03starseeker * r36185
10/brlcad/branches/dmtogl-branch/: Create branch to have a place to
experiment with togl |
15:57.53 |
``Erik |
heh |
15:58.06 |
``Erik |
starseeker, was survice involved in anything
related to the mk8? |
16:00.19 |
starseeker |
``Erik: I don't believe so |
16:00.23 |
``Erik |
huh |
16:00.31 |
starseeker |
the mk iv yess |
16:00.36 |
``Erik |
ahhh |
16:01.01 |
``Erik |
one of the old ww1 tanks is on their homepage
ticker, in what looks like a point datacloud |
16:01.04 |
``Erik |
was curious seeing that |
16:01.13 |
``Erik |
(also saw an old rayfarce screenie
there) |
16:01.36 |
starseeker |
oh, the gold one - yes that's a Mark
IV |
16:01.44 |
starseeker |
point cloud |
16:06.10 |
``Erik |
ah, 'k |
16:06.28 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.224.134) |
16:06.31 |
starseeker |
or actually, that's probaby the mesh created
from the point cloud... |
16:06.41 |
``Erik |
yeh, all their stuff tries to build
meshe |
16:06.43 |
``Erik |
meshes |
16:06.51 |
``Erik |
simple local hulling I think |
16:07.11 |
``Erik |
fun toys over in the warehouse,
though |
16:07.28 |
``Erik |
<-- got a tour just after their mini-range
went live |
16:10.48 |
``Erik |
oh fucking son of a fucking bitch |
16:11.01 |
``Erik |
forgot about osX's case
idioticity with the fs |
16:44.45 |
CIA-33 |
BRL-CAD: 03starseeker * r36186
10/brlcad/branches/dmtogl-branch/ (55 files in 6 dirs): First code
working toward togl integration into BRL-CAD build. |
17:01.40 |
*** join/#brlcad samrose
(n=samrose@c-71-238-70-85.hsd1.mi.comcast.net) |
17:18.41 |
*** join/#brlcad parigaudi
(n=quassel@217.91.127.94) |
17:27.02 |
brlcad |
hello parigaudi |
17:28.24 |
*** join/#brlcad Ralith
(n=ralith@d142-058-086-207.wireless.sfu.ca) |
17:29.03 |
brlcad |
you all shouldn't talk about Ralith like that
when he's not here |
17:29.07 |
brlcad |
oh hi Ralith |
17:53.54 |
brlcad |
~16*140 |
17:53.55 |
ibot |
2240 |
18:43.29 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
18:47.44 |
``Erik |
cally speaking |
18:52.28 |
Ralith |
I hear you guys bin talkin bout me behind my
back >:| |
19:01.34 |
``Erik |
well |
19:01.49 |
``Erik |
if you weren't spending all your time off in
the distance buried in a sheep... |
19:14.25 |
CIA-33 |
BRL-CAD: 03starseeker * r36187
10/brlcad/branches/dmtogl-branch/src/other/togl/Makefile.in: Let's
see if this makes togl build out of dir... |
19:23.47 |
starseeker |
ah, good |
19:34.33 |
starseeker |
brlcad: OK, just to organize my thinking - the
goal is for there to be no direct access to ged struct components
in the ged code, correct? |
19:41.42 |
starseeker |
and in this vein, the struct bu_vls
ged_result_str currently in struct ged should be replaced with
something that supports an API of the form GED_APPEND_RESULT(struct
bu_vls) and GED_NEXT_RESULT(struct ged_results)? (probably a
bu_list, but that should be hidden as an implementation
detail?) |
19:41.47 |
*** join/#brlcad PrezKennedy
(i=Matthew@208.43.126.194) |
20:13.15 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E086.dip.t-dialin.net) |
20:19.16 |
*** join/#brlcad mafm
(n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) |
21:03.19 |
brlcad |
starseeker: yes, unequivocally |
21:03.50 |
brlcad |
"struct ged" is a black box, only accessed
through api routines/macros |
21:04.27 |
brlcad |
GED_NEXT_RESULT doesn't make much
sense |
21:04.34 |
brlcad |
you can just keep appending results |
21:05.12 |
brlcad |
or is that for accessing results? |
21:06.50 |
brlcad |
would avoid introducing new structures as that
defeats much of the goal of making the API as simple as
possible |
21:08.23 |
brlcad |
typedef'd enums are probably okay if there are
lists of types/codes, but not containers outside of something
simple like a bu_list, or an iterator accessor pattern where you
provide a callback that is called per item ala
db_walk_tree() |
21:57.00 |
``Erik |
struct GED_HERE_BE_DRAGONS |
21:59.09 |
``Erik |
(once you truely understand it, I will
apogogize to your gf.) |
22:07.19 |
*** join/#brlcad puddingpimp
(n=dave@gateway.quickcircuit.co.nz) |
22:28.20 |
starseeker |
brlcad: yeah, APPEND to add results and NEXT
to iterate over the list/array of results |
22:31.08 |
starseeker |
but those were just made up on the spur of the
moment |
22:31.59 |
starseeker |
doesn't want to dive into
rewiring libged and then find out he did it the wrong
way... |
22:36.08 |
starseeker |
is liking bu_lists of bu_vls
full pathnames for results, but I must confess a pro/con analysis
of that vs. iterator/accessor is probably in
order... |
22:36.37 |
starseeker |
also, where do you envision enums being
helpful? (I'm not implying they're not - I'm sure they are - but
I'm not following) |
23:33.55 |
Maloeran |
Gez. So which one of you designed that thing?
http://news.bbc.co.uk/2/hi/technology/8302903.stm |
23:33.59 |
Maloeran |
:) |