00:26.20 |
*** join/#brlcad CIA-5
(~CIA@flapjack.navi.cx) |
00:31.20 |
*** join/#brlcad CIA-3
(~CIA@flapjack.navi.cx) |
04:45.58 |
Twingy |
An anonymous reader submits "As noted at
heise.de Saarland University is showing a prototype of a 3D
Raytracing Card at CeBIT2005. The FPGA is clocked at 90 MHz and is
3-5 times faster in raytracing then a Pentium4 CPU with 30 times
more MHz. Besides game engines using raytracing there was a scene
of a Boeing with 350 million polygons rendered in
realtime." |
04:46.43 |
brlcad |
bah, not even a billion polys :) |
04:47.50 |
Twingy |
heh |
04:48.22 |
Twingy |
certainly faster than what I can do |
04:48.31 |
Twingy |
of course |
04:48.38 |
Twingy |
they have like 6 guys working on this full
time |
04:48.48 |
brlcad |
well, of course.. more time and it's
hardware |
04:48.49 |
Twingy |
and we have like 1 guy working on this 70% of
the time |
04:49.09 |
Twingy |
sigh |
04:49.33 |
brlcad |
they're also trying to make money -- big
motivator ;) |
04:49.39 |
Twingy |
yah |
04:49.42 |
Twingy |
hey |
04:49.43 |
Twingy |
I am too |
04:49.48 |
brlcad |
heh |
04:50.01 |
brlcad |
"Twingy, Inc" |
04:50.05 |
Twingy |
heh |
04:50.12 |
Twingy |
I like it |
04:50.47 |
brlcad |
"'Scuse me Sir.. who do I make this check out
to?" .. "Why, Twingy Incorporated, of course!" |
04:50.55 |
Twingy |
teehee |
04:51.14 |
Twingy |
I'm calling my basement Fort Shumaker from now
on |
04:51.22 |
Twingy |
since I can work at home |
04:51.39 |
brlcad |
then Twingy takes the check and runs off
cackling maniacally into the distance |
04:51.58 |
Twingy |
it's fo mah womenz |
04:52.02 |
Twingy |
aww yea |
04:52.06 |
brlcad |
haha |
04:52.25 |
Twingy |
I think I wanna try subversion with
adrt |
04:52.33 |
Twingy |
I'm not pleased with cvs anymore |
04:52.40 |
brlcad |
you ever were? |
04:52.46 |
Twingy |
good point |
04:53.39 |
Twingy |
hurmph |
04:53.44 |
brlcad |
the biggest/only things cvs has going for it
is that it's free, it's mature, pretty stable, and well
understood |
04:53.52 |
Twingy |
not by me :D |
04:54.23 |
Twingy |
you see lifegems.com ? |
04:54.36 |
brlcad |
svn maintains the "understanding" by keeping
cvs's interface and is of course also free |
04:55.02 |
brlcad |
as soon as they can prove thier
maturity/stability, they'll likely be the next cms "golden
standard" |
04:55.07 |
Twingy |
svn is also geared for like major
changes |
04:55.17 |
Twingy |
like moving directories, renaming shit,
deleting stuff |
04:55.28 |
Twingy |
cms? |
04:55.35 |
brlcad |
content management system |
04:55.45 |
Twingy |
ah, ASA |
04:55.49 |
Twingy |
another silly acronym |
04:56.00 |
brlcad |
pretty common one :P |
04:56.07 |
Twingy |
meh |
04:56.55 |
brlcad |
sure svn fixes most all of cvs' short comings,
but that means jack if they can't prove they're stable |
04:57.11 |
brlcad |
only takes one obscure bug to destroy a
repository |
04:57.23 |
brlcad |
fortunately, they are starting to
mature |
04:57.46 |
brlcad |
hear fewer and fewer repository corruption
reports on the list |
04:58.22 |
brlcad |
since 1.0 at least last year |
04:59.21 |
brlcad |
when sourceforge finishes their svn support --
that'll be huge for the svn folks |
04:59.45 |
brlcad |
and sure to work out any remaining stability
bugs .. 100,000 projects is bound to find any left |
05:00.22 |
Twingy |
jup |
05:02.03 |
brlcad |
plan to convert brl-cad over to it after
sf.net finishes implementing it and they get a few months of
production testing under their belt |
05:02.34 |
Twingy |
ah |
05:02.37 |
Twingy |
neat |
05:03.35 |
brlcad |
no real need beforehand, though .. cvs does
work solid if you know how to use it and what not to do |
05:05.50 |
Twingy |
yah, but there's always the things that it
doesn't really support |
05:05.55 |
Twingy |
like major project changes |
05:06.06 |
Twingy |
so it's just a bunch of cumbersome scripting
and typing |
05:06.43 |
brlcad |
that's all a matter of how to use it and what
not to do imo |
05:06.52 |
brlcad |
you _can_ do just about anything sourcecode
related |
05:07.02 |
brlcad |
you just might not like how you have to do it
or what it implies |
05:07.12 |
brlcad |
svn cleans that mess up |
05:07.58 |
brlcad |
cvs does make you be less chaotic with your
"major changes" and requires more thought upfront -- I do
appreciate that regardless |
06:16.31 |
EricWilhelm |
svk looks pretty cool too |
06:19.38 |
brlcad |
http://www.linuxonpower.com/ |
06:19.50 |
brlcad |
could be fun to enter that |
06:20.28 |
EricWilhelm |
btw, I thought of how you could do a "live
install" with compiled code |
06:21.23 |
EricWilhelm |
basically, you would install wrappers instead
of binaries. |
06:21.43 |
EricWilhelm |
probably python scripts (or I guess they could
be wrapper binaries...) |
06:22.06 |
EricWilhelm |
the wrappers would compare the last checksum
from the source and decide if a recompile is needed |
06:22.36 |
EricWilhelm |
Hope to have more on that once I understand
scons a little better. |
06:22.48 |
brlcad |
that sounds like what libtool does
pre-install |
06:23.21 |
brlcad |
you create "libtool libraries" .. which are
effectively scripts. same holds for binaries |
06:23.47 |
brlcad |
they end up being shell scripts that recompile
if needed, set up the library paths etc |
06:24.13 |
EricWilhelm |
ack! must apt-get install
libtool-doc |
06:24.50 |
brlcad |
when coupled with automake, which will handle
dependency tracking, the scripts are auto-updated for a local
checkout update |
06:25.57 |
brlcad |
the problems are more practical though..
various versions and interdependencies in automake and libtool make
them difficult to get functioning properly without being strict on
exactly what versions are allowed |
06:26.37 |
EricWilhelm |
does this work for binary programs (e.g.
mged?) |
06:26.53 |
brlcad |
yes, brl-cad uses libtool |
06:27.11 |
brlcad |
if you compile a cvs checkout, src/mged/mged
is actually a shell script |
06:27.24 |
brlcad |
src/mged/.libs/mged should be the actual
binary |
06:28.26 |
brlcad |
libtool works with automake to generate
makefiles that do that magic for you automatically |
06:28.49 |
brlcad |
the harder part is the dependency
tracking |
06:29.16 |
brlcad |
i have it working for other projects, but for
some reason it's getting auto-disabled in brl-cad -- most likely
just due to the dependency complexity |
06:30.38 |
EricWilhelm |
well, yet another idea that's already been
done |
06:30.48 |
EricWilhelm |
there goes that software patent :-) |
06:30.54 |
brlcad |
heh |
06:31.04 |
brlcad |
you could easily respin that into a better
idea |
06:31.31 |
brlcad |
libtool is nice in theory but not so great in
execution/implementation |
06:31.38 |
EricWilhelm |
although, I don't see any build actions in
src/mged/mged |
06:32.03 |
EricWilhelm |
the implementation is where scons is probably
a little more flexible |
06:32.21 |
EricWilhelm |
shell scripts are so last century |
06:32.37 |
brlcad |
scons gets past many issues (and provides a
few new ones of it's own) |
06:33.13 |
brlcad |
they're the lowest common denominator on old
systems |
06:33.38 |
brlcad |
i might not have awk, but I have sh dammit
;) |
06:34.10 |
EricWilhelm |
sh -c 'perl' |
06:35.37 |
brlcad |
there are many "good" alternatives if you're
willing to drop a large portion of very very old systems |
06:35.56 |
EricWilhelm |
I'm reading the libtool docs now. It doesn't
sound like it's really doing the live-install thing. |
06:37.06 |
brlcad |
not exactly what you'd said.. but it is in
that direction I gather -- at least in conjunction with automake
and the build system dependency tracking |
06:37.15 |
narnia |
shell scripts are not "so last century". shell
scripts are extremely useful everyday. |
06:38.00 |
EricWilhelm |
what I have in mind is a system that enables
you to checkout the latest cvs, work a little magic and then run
mged by typing 'mged' from any cwd |
06:38.37 |
EricWilhelm |
then, work a little magic again and be right
back to where you were before (such as running the latest stable
version) |
06:39.48 |
brlcad |
hmm.. so some sort of mix between portage and
the alternatives system |
06:39.54 |
EricWilhelm |
are you after the tier1? |
06:40.06 |
EricWilhelm |
?alternatives? |
06:40.15 |
brlcad |
tier 1, yes.. i'm not inclined to port someone
else's code :) |
06:40.53 |
brlcad |
redhat created an "alternatives" system to
deal with the task of package/version selection |
06:41.22 |
brlcad |
say you install various mta's like sendmail
and postfix |
06:41.49 |
brlcad |
you can select between the two or versions of
either one by running a command |
06:42.12 |
brlcad |
symlinks and config files get updated and
you're suddenly running the new/old/different
'alternative' |
06:42.46 |
brlcad |
redhat doesn't use it for everything in the
system yet -- just some core configuration items last I
noticed |
06:42.50 |
brlcad |
but the basic idea is there |
06:43.53 |
brlcad |
course for them, it's made a little easier as
they also define where and how their packages install so it's
somewhat easier to make non-conflicting packages that can be
swapped on the fly |
06:50.02 |
EricWilhelm |
brlcad, yes something like the alternatives,
but that only covers the stable vs cvs/svn choice |
06:50.22 |
EricWilhelm |
btw, debian appears to be using alternatives
as of sarge |
06:51.56 |
EricWilhelm |
as far as similarities to portage, I guess
that's what you meant when you mentioned the sandbox |
06:52.40 |
EricWilhelm |
so, yes it would be like a sandbox, except the
point is to be able to run the sandboxed code from outside of the
sandbox (e.g. not chrooted) |
06:53.38 |
narnia |
i normally use /usr/local for what you are
describing. |
06:54.06 |
EricWilhelm |
so does the rest of the world |
06:54.34 |
EricWilhelm |
but using it usually involves running make
&& make test && make install before you can
actually run the code |
06:54.44 |
EricWilhelm |
I'm talking about something like
this: |
06:54.55 |
EricWilhelm |
svn co http://brlcad.sourceforge.net/svn |
06:55.06 |
EricWilhelm |
cd svn |
06:55.10 |
EricWilhelm |
make live-install |
06:55.21 |
EricWilhelm |
cd /home/me/stuff/models/ |
06:55.29 |
EricWilhelm |
mged a_model.g |
06:55.53 |
EricWilhelm |
now, say I close mged and mess with the code a
little. |
06:56.04 |
EricWilhelm |
save it, and then... (drum roll) |
06:56.09 |
EricWilhelm |
mged a_model.g |
06:56.45 |
narnia |
and magically mged was recompiled? |
06:56.49 |
EricWilhelm |
right |
06:56.59 |
narnia |
okay |
06:57.07 |
EricWilhelm |
it works for Perl, Python, etc, why not C and
C++ ? |
06:57.36 |
brlcad |
hmm.. i edit code all the time that I don't
necessariliy want to compile or install/run/use yet ;) |
06:57.53 |
EricWilhelm |
I'm working on the details of making it a
smooth workflow with Perl, so we'll see where it goes from
there. |
06:58.08 |
EricWilhelm |
brlcad, that's when you branch it (maybe svk
is good for that) |
06:58.21 |
narnia |
perl, python are not compiled like c and c++.
they are interpreted languages. |
06:58.39 |
EricWilhelm |
or just run 'alternatives brlcad stable'
(whatever) |
06:58.51 |
brlcad |
not branched work.. just stuff I'm not done
with |
06:58.54 |
EricWilhelm |
narnia, my question was hypothetical |
06:59.16 |
brlcad |
start editing.. stop go eat lunch.. come back
and do a lil modeling.. back to editing, etc |
06:59.41 |
EricWilhelm |
ok, but the code is a different version than
the code that you want to be running right? |
06:59.45 |
brlcad |
at least that's not a branch in any
traditional sense |
06:59.55 |
brlcad |
right |
06:59.55 |
narnia |
like brlcad said while working on source i do
not want some program that thinks it is smarter than me. i decide
when to compile. |
07:00.14 |
EricWilhelm |
with svk (as I understand it) you can have a
local branch which gets merged back to the trunk before the global
checkin |
07:00.46 |
EricWilhelm |
how often do you run the program that you're
working on without compiling? |
07:01.17 |
EricWilhelm |
if you're coding on mged and you want to run
mged, wouldn't you compile it about 99% of the time before running
it? |
07:01.33 |
brlcad |
depends on what's being worked on |
07:02.15 |
EricWilhelm |
of course. Everything depends on
something. |
07:02.28 |
brlcad |
normally if I'm just coding, yes.. I'll
edit/compile/edit/compile .. but if I'm doing other tasks like
modeling or image conversions too -- i've suddenly "stopped
coding" |
07:02.35 |
narnia |
like brlcad said. if i am debugging a program
i may alter the source code but not necessarily want to compile it
right that minute. |
07:02.36 |
EricWilhelm |
I wouldn't build such a thing without a kill
switch. |
07:03.06 |
brlcad |
i could switch back to the installed version
too -- but then I often want somewhere just in between |
07:03.14 |
EricWilhelm |
branch |
07:03.19 |
brlcad |
branches are a pita to deal with in
cvs |
07:03.26 |
EricWilhelm |
don't use cvs |
07:03.28 |
brlcad |
svn makes that a lil bit easier |
07:03.41 |
brlcad |
but it's still a rather large process
leap |
07:03.53 |
EricWilhelm |
you mean cvs->svn ? |
07:03.56 |
brlcad |
for something that's conceptually just taking
a break |
07:04.16 |
brlcad |
subversion is a cvs replacement |
07:04.41 |
EricWilhelm |
no, the 'process leap' what is "a rather large
process leap" |
07:04.42 |
EricWilhelm |
? |
07:05.05 |
EricWilhelm |
branching rather than stopping? |
07:05.18 |
brlcad |
no, branching is still the large process leap
-- from a pure coding perspective I'm not branching |
07:05.40 |
brlcad |
I'm only branching to work around the fact
that I don't want my runtime to change |
07:05.59 |
EricWilhelm |
ok, yeah you're just running code from a
different era than the code that you're editing |
07:06.02 |
brlcad |
that's trading one minor inconvenience with
another |
07:06.41 |
EricWilhelm |
which inconvenience is bigger? make install
or 'checkpoint ...' |
07:07.23 |
EricWilhelm |
I mean, it sounds like you would use a
live-install system if you could freeze it at '2 minutes ago' or
something. |
07:07.35 |
brlcad |
now something like what apple's gotten worked
out where I can be running some app and on the fly swap in new
libraries into the binary without recompiling -- that's pretty damn
cool |
07:07.50 |
EricWilhelm |
that's reflectionn |
07:07.54 |
EricWilhelm |
s/nn/n |
07:08.28 |
brlcad |
that's dynamic loadable libraries and an
interruptible run-time with dynamic lookup |
07:09.30 |
brlcad |
actually i'd say checkpointing would be more
inconvenient because that ends up being tracked by my revision
control system |
07:10.19 |
EricWilhelm |
ahh! the 'tunes project' |
07:10.20 |
brlcad |
ends up polluting the revision control history
with editing behavior instead of logical code changes |
07:11.02 |
EricWilhelm |
but if you could use svk to make local
checkpoints, you could commit to the cvs/svn whenever it made
sense |
07:11.35 |
brlcad |
the objective c runtime is very similar to
java's reflection api, though there are a few core
differences |
07:11.35 |
EricWilhelm |
reflective: http://tunes.org/ |
07:13.51 |
brlcad |
introspection maybe |
07:13.57 |
brlcad |
dynamic discovery another |
07:14.37 |
EricWilhelm |
but the ultimate reflection is exactly
analogous to a mirror |
07:14.50 |
EricWilhelm |
you move (change code) and the mirror shows
you the change |
07:15.35 |
brlcad |
I generally cannot see what's inside things
when looking at a mirror reflection of something |
07:15.37 |
EricWilhelm |
there's also a project doing something with a
super-cool X-windows replacement in that site somewhere |
07:15.57 |
EricWilhelm |
(in case you ever wanted to have two mouse
cursors) |
07:15.58 |
brlcad |
the reflection pattern generally is more than
self-interface visibility |
07:16.35 |
brlcad |
it's self-implementation visibility |
07:16.48 |
EricWilhelm |
so your mirror needs some endoscopes and
such? |
07:17.19 |
brlcad |
like if I could have some special fantastical
mirror that could see into my sould as well as my front |
07:18.00 |
brlcad |
a reflection is generally only one-view .. i
can't see what's behind me without multiple reflections |
07:18.23 |
brlcad |
it's all pedantic differences, but part of why
I never liked that particular buzz word |
07:18.52 |
EricWilhelm |
I wasn't aware it was a buzz word (though I
guess if they use it in relation to Java, it *must* be.) |
07:24.02 |
brlcad |
not so much "buzz" probably except in the java
context |
07:24.34 |
brlcad |
http://en.wikipedia.org/wiki/Reflection_%28computer_science%29 |
07:58.00 |
EricWilhelm |
still can't find that darned dual-cursor (and
many more featureful) X server replacement. I cranked konqueror's
history up to a bzillion about a month ago for exactly this reason,
but it seems to be no use. |
09:46.16 |
*** part/#brlcad TheBOFH
(dodell@the-bofh.org) |
10:11.05 |
*** join/#brlcad Pimpinella
(~frank@p50820C8C.dip0.t-ipconnect.de) |
14:16.45 |
*** join/#brlcad brlcad_
(~brlcad@bz.bzflag.bz) |
14:46.18 |
*** join/#brlcad narnia
(~terrylr@johann.blauedonau.com) |
16:57.38 |
*** mode/#brlcad [+o brlcad]
by ChanServ |
17:07.39 |
*** join/#brlcad dan_falck
(~danfalck@wbar1.sea1-4-5-017-067.sea1.dsl-verizon.net) [NETSPLIT
VICTIM] |
18:23.31 |
*** join/#brlcad CIA-8
(~CIA@flapjack.navi.cx) |
18:24.02 |
*** join/#brlcad dan_falck
(~danfalck@wbar1.sea1-4-5-017-067.sea1.dsl-verizon.net) [NETSPLIT
VICTIM] |
18:24.02 |
*** join/#brlcad narnia
(~terrylr@johann.blauedonau.com) [NETSPLIT VICTIM] |
18:31.00 |
*** join/#brlcad dan_falck
(~danfalck@wbar1.sea1-4-5-017-067.sea1.dsl-verizon.net) [NETSPLIT
VICTIM] |
18:31.00 |
*** join/#brlcad narnia
(~terrylr@johann.blauedonau.com) [NETSPLIT VICTIM] |
18:40.49 |
*** join/#brlcad dan_falck
(~danfalck@wbar1.sea1-4-5-017-067.sea1.dsl-verizon.net) [NETSPLIT
VICTIM] |
18:40.49 |
*** join/#brlcad narnia
(~terrylr@johann.blauedonau.com) [NETSPLIT VICTIM] |
19:37.44 |
*** join/#brlcad narnia
(~terrylr@johann.blauedonau.com) |
19:38.08 |
*** join/#brlcad dan_falck
(~danfalck@wbar1.sea1-4-5-017-067.sea1.dsl-verizon.net) |
21:42.54 |
brlcad |
heh |
21:44.38 |
CIA-8 |
BRL-CAD: 03brlcad *
10brlcad/src/other/libtcl/Makefile.am: libtcl needs libdl for
symbols from tclLoadDl.o |
22:33.30 |
narnia |
brlcad, fyi, part21 is going extremely slow.
much slower than i originally thought it would. |