| 00:03.26 |
*** join/#brlcad BigAToo
(n=BigAToo@cpe-24-209-94-205.woh.res.rr.com) |
| 00:27.39 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 01:02.38 |
CIA-31 |
BRL-CAD:
03brlcad * r33485 10/brlcad/trunk/src/libfb/if_ogl.c: this is more
a blind stab, but try to remove X11/keysym.h too. it's part of Xlib
and presumably not needed (glenn added both headers a long time
ago) |
| 01:34.13 |
*** join/#brlcad parodyoflanguage
(n=klh@mmds-216-19-34-118.twm.az.commspeed.net) |
| 01:38.36 |
*** join/#brlcad BigAToo
(n=BigAToo@cpe-24-209-94-205.woh.res.rr.com) |
| 03:43.04 |
*** join/#brlcad BigAToo
(n=BigAToo@cpe-24-209-94-205.woh.res.rr.com) |
| 04:12.18 |
*** join/#brlcad BigAToo
(n=BigAToo@75.52.175.178) |
| 04:33.56 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 04:34.31 |
Dr_Phreakenstein |
. |
| 04:36.38 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 04:43.50 |
Dr_Phreakenstein |
does anyone
know the current progress of the step interpreter? or perhaps how
people can help with that? |
| 04:47.28 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-bbbcf736a7d873b7) |
| 04:48.36 |
ashishrai |
Hi All
!!!! |
| 04:49.44 |
ashishrai |
I am a
multi-touch enthusiast and I would like to develop a multitouch
interface with brl-cad, a cad system with multi-touch will be very
cool - what do you say !! |
| 04:51.17 |
Ralith |
ashishrai:
That would be pretty neat. I look forward to seeing your
work. |
| 04:53.07 |
ashishrai |
Thanks Ralith
:) |
| 04:54.19 |
ashishrai |
i was
researching about a good opensource cad software and i feel that
brl-cad would be the best |
| 04:54.41 |
Ralith |
It's pretty
much the only noteworth entry in the field, as far as I
know. |
| 04:55.09 |
ashishrai |
i have good
working experience with multi-touch ( developed both some hardware
and software ) but i am totally newbie to brl-cad |
| 04:55.18 |
ashishrai |
can you
please help to how and where to get started with
brl-cad |
| 04:55.22 |
Ralith |
the code is
pretty well put together |
| 04:55.40 |
Ralith |
well, what do
you want your UI to do? |
| 04:57.14 |
ashishrai |
right now i
am thinking of having a UI similar to google skectchup ie you can
draw lines , polygons, solids etc with your hand/pen on the
software |
| 04:58.01 |
ashishrai |
i would try
to extend it so that many person can work on the same table - ie
openning two or more parts , of say , the same design |
| 04:58.21 |
Ralith |
You should be
aware that, at the moment, there's no reliable way to render
regions in realtime. |
| 04:58.37 |
Ralith |
and as such
shaded views like you describe can't yet be done. |
| 04:58.41 |
Ralith |
this is
coming. |
| 04:58.51 |
ashishrai |
ok
!! |
| 04:59.35 |
Ralith |
if you're ok
with that, I *think* libwdb is the place you want to start; that's
what provides an inteface for reading/writing brl-cad
databases. |
| 04:59.55 |
ashishrai |
but still the
designing part instead of from mouse and keyboard can be done a
surface/table much intitutively |
| 04:59.58 |
ashishrai |
yeah sure
:) |
| 05:00.33 |
ashishrai |
we have very
good documents on how to use brl-cad , do we have such
documentation for the code too |
| 05:01.45 |
ashishrai |
i am sorry if
these are very vague questions , i will come back again after
having a good look at the code-base :) |
| 05:02.34 |
ashishrai |
i will
concentrate on libwdb - thanks very much for help :) |
| 05:04.10 |
Ralith |
I'm not sure
how well documented the code is in general, but I know a lot of
effort has gone into it lately |
| 05:04.18 |
Ralith |
it's
certainly worth looking at. |
| 05:04.24 |
Ralith |
if only to
judge its quality. |
| 05:04.32 |
brlcad |
Dr_Phreakenstein: how would you like to
help with it? |
| 05:04.48 |
brlcad |
(and yes, I
know the status of it -- it's one of my current tasks) |
| 05:06.15 |
brlcad |
ashishrai:
that sounds pretty interesting -- are you interested in hooking
multitouch into the existing modeling interface (mged) or working
on a new interface or something else? |
| 05:07.00 |
brlcad |
libwdb is
only for creating geometry -- not so hot for editing in general
since you can't read geometry that has been written out |
| 05:07.08 |
brlcad |
for full
read/write, you use librt |
| 05:07.35 |
brlcad |
libwdb is an
interface on top of librt |
| 05:08.16 |
brlcad |
the code is
pretty well documented, but it is a massive code base (more than a
million lines) so there are plenty of places that are
over-commented and under-commented |
| 05:09.13 |
Ralith |
librt seems
more monolithic the more I hear about it :/ |
| 05:09.21 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 05:09.36 |
ashishrai |
how about say
from the gesture recognition code i have known that till now the
user has drawn a line from this point to that and then i would like
to invoke the command from brl-cad to display that |
| 05:09.45 |
ashishrai |
i would like
to first start with this basic one |
| 05:10.14 |
brlcad |
Ralith: librt
isn't a million lines .. :) |
| 05:10.16 |
Dr_Phreakenstein |
also
interested in multi-touch, but i cannot help/use in the near
future |
| 05:10.37 |
yukonbob |
hello,
cadheads |
| 05:11.00 |
Dr_Phreakenstein |
hello,
yukonbob |
| 05:11.07 |
ashishrai |
then when the
user will complete the polygon it will be displayed as a polygon
which then again can be stretched in a direction to create a
solid |
| 05:11.08 |
brlcad |
librt is
basically the file format (.g), basic in-memory geometry
representation, and ray-tracing |
| 05:11.12 |
yukonbob |
evening,
doctor |
| 05:11.14 |
brlcad |
no more, no
less |
| 05:11.29 |
Dr_Phreakenstein |
i am still
learning to code, so nut much help there |
| 05:11.40 |
brlcad |
168k lines at
a glance in librt |
| 05:11.54 |
Dr_Phreakenstein |
however, i am
can help test/debug |
| 05:12.13 |
Dr_Phreakenstein |
i am still
studying the ISO standard now |
| 05:12.23 |
ashishrai |
any sort of
help will be highly appreciable :) |
| 05:12.30 |
brlcad |
ashishrai:
the issue with a brl-cad interface is that we don't do much at all
with 2D entities -- most of the interactions are in 3D space
creating 3D objects directly |
| 05:12.32 |
ashishrai |
i am
completely newbie :) |
| 05:13.05 |
Dr_Phreakenstein |
my overall
plan is to develop an opensource system to do rapid prototyping,
with scale-to-manufacturability |
| 05:13.28 |
brlcad |
it would be
really interesting to have a gesture for the various primitives,
editing operations, and view manipulations .. |
| 05:13.49 |
ashishrai |
cant we draw
things like lines planes etc in 3d too |
| 05:13.49 |
Dr_Phreakenstein |
yes |
| 05:13.56 |
ashishrai |
yes true
:) |
| 05:14.05 |
Dr_Phreakenstein |
yes to
brlcad |
| 05:14.38 |
brlcad |
ashishrai:
you can, but we focus on solid modeling -- with is intrinsically
3D, objects that occupy a volume |
| 05:15.07 |
brlcad |
so instead of
"draw me these four lines, make a square, extrude it to make a
box", we go directly to "make be a box with these
dimensions" |
| 05:15.20 |
brlcad |
s/be/me/ |
| 05:15.48 |
brlcad |
Dr_Phreakenstein: understandable that
you'd be learning the code -- can you do more than test/debug,
though? :) |
| 05:15.53 |
ashishrai |
<PROTECTED> |
| 05:16.07 |
brlcad |
we're not
exactly ready for testing/debugging just quite yet (maybe in a few
weeks) |
| 05:16.33 |
Dr_Phreakenstein |
well, it will
take me longer than that to learn C |
| 05:16.42 |
Dr_Phreakenstein |
i was just
now working on python |
| 05:16.50 |
ashishrai |
editing of a
design on multi-touch surface will also be very great - eg a team
working on it |
| 05:16.53 |
brlcad |
ashishrai:
that's my point -- our basic primitives are not 2D entities,
they're 3D ones -- so the gestures would have a domain to work
within |
| 05:17.31 |
jonored |
Dr_Phreakenstein: You're aware of the
RepRap open-source rapid prototyping machine and all that, right?
Sounds related, and you're not in their channel here :) |
| 05:17.54 |
brlcad |
ashishrai:
here is a basic overview of our fundamental entity
types |
| 05:17.57 |
brlcad |
http://brlcad.org/tmp/primitives/Primitives3_grouped.png |
| 05:19.16 |
Ralith |
Dr_Phreakenstein: open source rapid
prototyping, hm? Ever heard of reprap? |
| 05:19.24 |
ashishrai |
but how ,
from the user point of view , can i directly describe such a
primitive on a multitouch surface |
| 05:19.26 |
Dr_Phreakenstein |
nope |
| 05:19.34 |
Dr_Phreakenstein |
just looked
up |
| 05:19.38 |
Ralith |
Dr_Phreakenstein: you'll love
it. |
| 05:19.44 |
brlcad |
ashishrai:
that would be the trick/work/task :) |
| 05:19.48 |
Ralith |
open source
sub-$1k FDM machine. |
| 05:19.58 |
Dr_Phreakenstein |
pretty neat,
and a great starting point |
| 05:20.19 |
Dr_Phreakenstein |
i am thinking
larger than that, and with a high degree of automation |
| 05:20.21 |
ashishrai |
one way can
be - there can be a menu to be selected and then the user can edit
it and view it in a intuitive way |
| 05:20.46 |
Ralith |
Dr_Phreakenstein: automation in what
way? |
| 05:21.10 |
brlcad |
ashishrai:
complex gestures for complex shapes, for example .. a "d" gesture
might make a cylinder or an "o" might make a sphere |
| 05:21.54 |
brlcad |
or yeah, they
select a gui option .. "create torus" .. then the gesture would be
specific to the parameters for the torus |
| 05:22.15 |
jonored |
But it's a
lot of basic development done, and if you can be compatible you've
got a lot of people who would be interested. But the rapid
prototyping talk probably would fit better over in #reprap
:) |
| 05:22.41 |
yukonbob |
ashishrai:
have you heard of Jeff Han? |
| 05:22.42 |
brlcad |
basic 3D view
manipulation using gestures is something that would be
interesting/useful to have by itself without even considering
editing options |
| 05:22.49 |
Dr_Phreakenstein |
still working
on overall plan, however, the original idea was for people to be
able to submit something, and i build and assemble it for
them... |
| 05:23.02 |
Ralith |
hey jonored!
I was about to mention you. |
| 05:23.13 |
ashishrai |
hmmmm , so
where should i start looking in the code where say i can invoke a
command with required argumnts |
| 05:23.14 |
ashishrai |
yukonbob:
yeah sure |
| 05:23.18 |
ashishrai |
he is the
bond |
| 05:23.30 |
yukonbob |
?"the
bond" |
| 05:23.39 |
Ralith |
Dr_Phreakenstein: I wouldn't call that
open source rapid prototyping. |
| 05:23.41 |
ashishrai |
i think he is
collaborating with Autocad to develop such a thing |
| 05:23.50 |
brlcad |
ashishrai: a
good starting point would be the view gestures that were worked on
for blender: http://wiki.blender.org/index.php/Manual/Gestures |
| 05:23.54 |
Dr_Phreakenstein |
it started
with circuit boards, where you would send art, i would cut a
circuit, and a shipping label would be in a printer |
| 05:24.02 |
Ralith |
Dr_Phreakenstein: I'd call that Yet
Another Commercial RP service :P |
| 05:24.13 |
Dr_Phreakenstein |
no, the
overall scheme is larger than that |
| 05:24.20 |
brlcad |
implementing
something like that for mged or archer would be pretty
straightforward |
| 05:24.28 |
Dr_Phreakenstein |
up to that
point, you are correct |
| 05:24.53 |
Dr_Phreakenstein |
my idea would
be based on all open source software |
| 05:25.10 |
Dr_Phreakenstein |
i could do
the work for you, |
| 05:25.43 |
Dr_Phreakenstein |
or set up the
facilities for you to have some or all of your own
capabilities |
| 05:26.02 |
Dr_Phreakenstein |
it would have
to scale up or down |
| 05:26.14 |
ashishrai |
very good and
it will be a good starting point - after that i will know/think of
some editing capabilities too :) |
| 05:27.13 |
brlcad |
ashishrai:
the places to look for mged and archer are in src/mged and
src/archer respectively .. they are two rather different modeling
interfaces (both are C+Tcl hybrid code bases) one in production
use, the other a new prototype interface |
| 05:27.38 |
brlcad |
mged on the C
side would probably be the easiest to get started with unless you
know Tcl |
| 05:27.40 |
Dr_Phreakenstein |
also, part of
that is developing /good/ cnc controllers using step-nc, with emc2,
on realtime linux |
| 05:28.31 |
ashishrai |
great !!
thanks brlcad :) |
| 05:28.54 |
yukonbob |
brlcad: how
is archer these days? |
| 05:29.28 |
brlcad |
yukonbob:
coming along well actually .. bob has been testing most of his big
libged refactoring efforts by putting the changes into archer
first |
| 05:29.53 |
brlcad |
so now archer
can do almost everything mged can do via the command
line |
| 05:30.30 |
yukonbob |
brlcad: that
sounds like an excellent way to do development on it...
:) |
| 05:30.34 |
yukonbob |
?screenshots? |
| 05:30.37 |
brlcad |
so archer is
fully hooked into libged, and now he's working on integrating
libged back into mged (which will help archer as well) |
| 05:31.07 |
brlcad |
yukonbob:
mm.. don't have any fresh ones on me at the moment |
| 05:31.35 |
brlcad |
there is the
old one int /tmp/ if you've never seen it at all |
| 05:31.38 |
Dr_Phreakenstein |
i look
forward to any improvements to archer |
| 05:32.39 |
brlcad |
http://brlcad.org/tmp/Archer_0.5prototype.png
(from like three years ago) |
| 05:33.15 |
Ralith |
not
bad. |
| 05:33.55 |
brlcad |
if archer can
get all of mged's command line functionality, and a few portions of
the gui-only functionality that it's missing, it'd be viable to
supplant mged after an alpha/beta testing period |
| 05:34.25 |
brlcad |
that'd be a
ways down the road, though, as mged's gui functionality is pretty
substantial compared to archer |
| 05:34.58 |
Dr_Phreakenstein |
yes, but
archer is pretty |
| 05:35.02 |
Dr_Phreakenstein |
:) |
| 05:35.04 |
Ralith |
^ |
| 05:35.28 |
brlcad |
and the same
could have been said about mged's command-line functionality
compared to archer, but here we are 6-months later or so and
they're nearly unified |
| 05:35.53 |
Dr_Phreakenstein |
i am
impressed |
| 05:36.05 |
Dr_Phreakenstein |
that is some
pretty substantial work |
| 05:36.52 |
Dr_Phreakenstein |
there will
never be a replacement for a good command line |
| 05:37.02 |
yukonbob |
"supplant" --
how so? |
| 05:37.05 |
yukonbob |
get rid of
mged? |
| 05:37.46 |
brlcad |
as in replace
it eventually if/when it encompassed most of the same
functionality |
| 05:37.57 |
yukonbob |
frowns |
| 05:38.05 |
brlcad |
why? |
| 05:38.13 |
brlcad |
it's not like
mged goes away |
| 05:38.16 |
yukonbob |
i _like_ mged
;) |
| 05:38.36 |
brlcad |
it'd be more
like the two would merge .. they *are* effectively merging by the
nature of refactoring mged into a libged |
| 05:38.45 |
Dr_Phreakenstein |
there is a
certain difficulty in maintaining parallel implementations of a
given functionality |
| 05:38.48 |
brlcad |
making them
both use the same editing library |
| 05:39.02 |
yukonbob |
if it's all
still there in some way, that's fine... a window in archer, and a
way to hide archer's button panels |
| 05:39.52 |
yukonbob |
enjoys writing his code in Tcl anyway, and [source]ing
it... |
| 05:39.55 |
brlcad |
yeah, it
wouldn't be hard to add an option to make archer spit out three
windows instead of one to make it closer to mged |
| 05:40.15 |
brlcad |
mged actually
already has the logic in it to make it a single-window app instead
of the multi-window default it does now |
| 05:40.20 |
yukonbob |
procedural
constructive solid geometry |
| 05:40.34 |
brlcad |
it was just
never fully stabilized as that same mod added tear-off menus and
other glitz |
| 05:40.55 |
brlcad |
and the
tear-off's didn't behave quite right iirc (for the ones that are
dynamic) |
| 05:41.19 |
brlcad |
yukonbob: you
do know that archer is more Tcl than mged is? :) |
| 05:41.27 |
yukonbob |
archer has
always been good-looking, and it's nice to hear it's progressing...
and coding against the libs can only be good for all involved, so
"here's to archer" |
| 05:41.51 |
yukonbob |
re: archer
and Tcl -- no... I think I'm starting to like it more |
| 05:41.53 |
yukonbob |
:) |
| 05:41.59 |
yukonbob |
LOL |
| 05:42.02 |
brlcad |
it's actually
pure tcl |
| 05:42.20 |
yukonbob |
that's
_really_ nice to hear. |
| 05:42.53 |
yukonbob |
still needs to get his system stable, and then I'll do more
than just "talking" about rendering and using the editors
:P |
| 05:42.54 |
brlcad |
well, that
and it has a package load that hooks into C for the state
management and geometry processing (via libged and
librt) |
| 05:43.08 |
brlcad |
instead of an
embedded tcl interpreter, it is just a tcl script that kicks
off |
| 05:43.27 |
Ralith |
brlcad:
archer is tcl? really? I didn't know TCL could look decent
:P |
| 05:43.29 |
Ralith |
tk that
is. |
| 05:43.36 |
brlcad |
Ralith: yeah,
no kidding :) |
| 05:43.52 |
yukonbob |
! |
| 05:43.53 |
brlcad |
there are a
lot of tricks and tweaks off of the defaults to make it look sane
like that |
| 05:44.09 |
yukonbob |
shame -- Tk
has been undergoing a facelift for years now |
| 05:44.18 |
yukonbob |
tile,
ttk |
| 05:44.20 |
brlcad |
it does get a
bad rap |
| 05:44.46 |
yukonbob |
people look
at screenies from the 80's and say "that doesn't look
modern" |
| 05:45.06 |
brlcad |
and mostly
just because a handful of the widget defaults were braindead dumb
.. some guy's pet peave on the way he wanted it |
| 05:45.16 |
brlcad |
tile/ttk are
pretty cool.. |
| 05:45.48 |
yukonbob |
goes to grab food... |
| 05:46.00 |
brlcad |
little harder
to use and the widgets aren't as fleshed out, but it's a vast
improvement |
| 05:46.18 |
Dr_Phreakenstein |
tcl/tk can
look quite good, same as qt3, and is quite stable and
robust |
| 05:47.32 |
*** join/#brlcad DanielFalck
(n=dan@pool-71-111-77-16.ptldor.dsl-w.verizon.net) |
| 06:07.04 |
Dr_Phreakenstein |
find -type
f|cat|wc -l |
| 06:07.11 |
Dr_Phreakenstein |
36591 |
| 06:07.28 |
Dr_Phreakenstein |
total lines
in brlcad svn |
| 06:07.45 |
louipc |
clear |
| 06:07.50 |
louipc |
oops |
| 06:08.02 |
Dr_Phreakenstein |
clear |
| 06:08.17 |
louipc |
only 36k
lines? |
| 06:08.23 |
Ralith |
that doesn't
sound right |
| 06:08.24 |
louipc |
<PROTECTED> |
| 06:08.29 |
louipc |
;) |
| 06:08.32 |
Ralith |
more
likely. |
| 06:09.13 |
Dr_Phreakenstein |
hmmm |
| 06:09.16 |
Dr_Phreakenstein |
oops |
| 06:09.30 |
Dr_Phreakenstein |
files |
| 06:09.53 |
louipc |
you want
`find -type f -exec cat {} \; | wc -l` I guess |
| 06:10.30 |
Dr_Phreakenstein |
11860839 |
| 06:10.41 |
Dr_Phreakenstein |
cat `find
-type f`|wc -l |
| 06:11.00 |
Dr_Phreakenstein |
sorry,
tired |
| 06:11.37 |
Dr_Phreakenstein |
11,860,839
(commas added for emphasis) |
| 06:12.11 |
louipc |
wow my
computer is so slow |
| 06:12.43 |
Dr_Phreakenstein |
executing
that command? |
| 06:12.50 |
louipc |
can't be 11M
though... |
| 06:12.51 |
Dr_Phreakenstein |
took 3.512
real seconds |
| 06:12.52 |
louipc |
that's
crazy! |
| 06:13.03 |
louipc |
yes I run a
pIII |
| 06:13.06 |
Dr_Phreakenstein |
no, that is
not just source |
| 06:13.16 |
Dr_Phreakenstein |
that is
everything |
| 06:13.33 |
Dr_Phreakenstein |
which means
that if there is a cr/lf in a png, it is counted |
| 06:13.55 |
louipc |
yea |
| 06:14.13 |
Ralith |
louipc: why
can't it be 11M? |
| 06:14.34 |
Ralith |
Dr_Phreakenstein: try -iname '*.c??' -or
-iname '*.h??' |
| 06:14.54 |
louipc |
Dr_Phreakenstein: is that on the svn
checkout or on an extracted tarball? |
| 06:14.59 |
Dr_Phreakenstein |
cat `find
-type f`|grep .h|wc -l |
| 06:15.05 |
Dr_Phreakenstein |
1967863 |
| 06:15.23 |
louipc |
Ralith: seems
like 10 times what I thought it was around |
| 06:15.27 |
Dr_Phreakenstein |
.c
yields |
| 06:15.35 |
Dr_Phreakenstein |
2998240 |
| 06:15.49 |
Ralith |
Dr_Phreakenstein: ...why didn't you just
do what I suggested :P |
| 06:15.50 |
louipc |
oh
wow |
| 06:16.06 |
Dr_Phreakenstein |
already
executed mine |
| 06:16.07 |
Ralith |
louipc:
brl-cad is big. |
| 06:16.23 |
louipc |
i
know |
| 06:16.47 |
Dr_Phreakenstein |
also, that
includes css files |
| 06:17.30 |
louipc |
Dr_Phreakenstein: is that on the svn
checkout? |
| 06:17.33 |
louipc |
11M? |
| 06:17.44 |
Dr_Phreakenstein |
but mine
includes other erronious things |
| 06:17.45 |
Dr_Phreakenstein |
yes |
| 06:17.53 |
louipc |
because you'd
get all the .svn stuff then |
| 06:18.11 |
Dr_Phreakenstein |
according to
the over simplified, unfiltered command above |
| 06:18.19 |
Dr_Phreakenstein |
true, so not
perfect |
| 06:18.28 |
Dr_Phreakenstein |
still
impressive |
| 06:18.49 |
louipc |
the number
will be a lot smaller without .svn |
| 06:19.35 |
Dr_Phreakenstein |
perhaps |
| 06:19.46 |
Ralith |
still
>1M |
| 06:20.23 |
louipc |
no. of files
minus .svn = 11131 |
| 06:20.38 |
Dr_Phreakenstein |
yes, but
those are small files |
| 06:20.47 |
Dr_Phreakenstein |
cat `find
-type f`|grep -v .svn|wc -l |
| 06:20.53 |
Dr_Phreakenstein |
11838213 |
| 06:21.07 |
Dr_Phreakenstein |
compare
to |
| 06:21.09 |
Dr_Phreakenstein |
11860839 |
| 06:21.22 |
louipc |
hmm
interesting |
| 06:22.14 |
louipc |
I think you
have to put the grep inside the ` ` though |
| 06:22.28 |
louipc |
try that
:P |
| 06:23.35 |
Ralith |
heh |
| 06:23.48 |
Ralith |
louipc: I was
referring to LoC |
| 06:24.18 |
louipc |
the history
is probably bigger than the actual codebase |
| 06:24.56 |
Dr_Phreakenstein |
good
catch |
| 06:25.09 |
Dr_Phreakenstein |
cat `find
-type f|grep -v .svn`|wc -l |
| 06:25.16 |
Dr_Phreakenstein |
5615906 |
| 06:25.49 |
Dr_Phreakenstein |
cd
/usr/src/linux-2.6.28-gentoo |
| 06:25.53 |
Dr_Phreakenstein |
make
distclean |
| 06:26.02 |
Dr_Phreakenstein |
time cat
`find -type f`|wc -l |
| 06:26.07 |
louipc |
so you
finally got the 'real' number hehe |
| 06:26.09 |
Dr_Phreakenstein |
10122684 |
| 06:26.13 |
Dr_Phreakenstein |
yeah |
| 06:26.27 |
Dr_Phreakenstein |
that is much
more believable |
| 06:26.42 |
Dr_Phreakenstein |
5.6
million |
| 06:26.55 |
Dr_Phreakenstein |
that's a lot
o characters |
| 06:27.41 |
Dr_Phreakenstein |
over half the
size of the linux kernel |
| 06:27.48 |
louipc |
you should
subtract the blank lines hehe |
| 06:28.14 |
Dr_Phreakenstein |
ok, this is
fun, but i don't have all night |
| 06:28.32 |
Dr_Phreakenstein |
if i was
going to do that, i ought to be more productive than
counting |
| 07:22.10 |
*** join/#brlcad clock_
(n=clock@77-58-239-209.dclient.hispeed.ch) |
| 08:27.00 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 08:45.03 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 10:01.22 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-38-82-253-107-236.adsl.proxad.net) |
| 10:46.29 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 10:58.09 |
*** join/#brlcad b0ef`
(n=b0ef@95.34.57.61.customer.cdi.no) |
| 11:35.58 |
d-lo |
Mornin
all! |
| 11:36.54 |
starseeker |
snnnnooorrreeeee |
| 11:37.32 |
starseeker |
d-lo: Wow
you're an early riser :-P |
| 11:37.57 |
starseeker |
shakes head and faces up to the reality of having to drive
before 7am... |
| 11:41.09 |
d-lo |
up at 0415 to
be @ work by 0615 ;) |
| 11:42.05 |
d-lo |
throws a bucket of ice water on starseeker. 'Mornin
Sunshine!' |
| 11:43.10 |
starseeker |
is nocturnal by inclination :-P |
| 11:43.58 |
d-lo |
has choosen to sync 'sleeping habits' with his wife... works
out much better in the end ;) |
| 11:44.30 |
starseeker |
understandable :-) |
| 11:45.02 |
d-lo |
based on irc
activity, quite a few 'cadheads' are either nocturnal or on the
other side of the globe :) |
| 11:45.24 |
Ralith |
nocturnal
here |
| 11:47.13 |
d-lo |
Ralith:
Washington state? |
| 11:54.23 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 11:57.56 |
starseeker |
yukonbob:
Here's a reasonably recent image: http://bzflag.bz/~starseeker/archer.png |
| 11:58.42 |
starseeker |
knows he shouldn't use tire so much, but in this case bob
wrote a plugin for tires which is visible on the
right. |
| 11:59.34 |
d-lo |
Wow. Thats a
*Nice* tire! Only the combination of a sexy Cad system and
brilliant programmers could have come up with that! |
| 11:59.43 |
d-lo |
:D |
| 12:15.39 |
CIA-31 |
BRL-CAD:
03davidloman * r33486 10/rt^3/trunk/ (8 files in 3 dirs): Added
Getters n Setters to the NetMsgs |
| 12:16.49 |
archivist |
starseeker,
how long did it take to create |
| 12:20.58 |
brlcad |
starseeker:
nice |
| 12:21.58 |
brlcad |
Dr_Phreakenstein: try running
sh/enumerate.sh .. that will give a more accurate file/line
count |
| 12:23.49 |
brlcad |
(which will
report even non-blank lines too) |
| 12:25.36 |
CIA-31 |
BRL-CAD:
03davidloman * r33487 10/rt^3/trunk/ (17 files in 4 dirs): Re-org
NetMsg and subclasses into dedicated dir |
| 12:40.32 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-38-82-253-107-236.adsl.proxad.net) |
| 12:54.02 |
CIA-31 |
BRL-CAD:
03brlcad * r33488 10/brlcad/trunk/sh/enumerate.sh: update the
enumeration to more accurately count documentation line counts
(wasn't counting the docbook xml files, was counting cmakelist
build files and svn files) and 3rd party sources (wasn't counting
the c++ sources). |
| 12:56.18 |
*** join/#brlcad BigAToo
(n=BigAToo@adsl-75-52-175-178.dsl.dytnoh.sbcglobal.net) |
| 13:35.02 |
*** join/#brlcad docelic_
(n=docelic@78.134.192.144) |
| 13:48.57 |
*** join/#brlcad madant
(n=madant@117.196.143.185) |
| 14:03.17 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-38-82-253-107-236.adsl.proxad.net) |
| 14:33.56 |
yukonbob |
starseeker:
re: archer - nice! thx |
| 14:34.06 |
CIA-31 |
BRL-CAD:
03bob1961 * r33489 10/brlcad/trunk/src/ (15 files in 2 dirs): More
mods related to MGED using libged. |
| 14:53.19 |
CIA-31 |
BRL-CAD:
03davidloman * r33490 10/rt^3/trunk/ (2 files in 2 dirs): Added
NetMsg subclass: GeometryManifestMsg |
| 14:54.48 |
d-lo |
make oddness
:/ its not seeing files that are there and seeing other files that
aren't there...... ghost in the shell :/ |
| 14:59.06 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 15:36.31 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-38-82-253-107-236.adsl.proxad.net) |
| 16:01.54 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D722.dip.t-dialin.net) |
| 16:58.48 |
*** join/#brlcad BigAToo
(n=BigAToo@75.52.175.178) |
| 17:08.11 |
CIA-31 |
BRL-CAD:
03bob1961 * r33491 10/brlcad/trunk/src/mged/mged.c: Added
ged_output_handler. Output from rt, rtcheck, rtedge, etc. is
restored. |
| 17:15.58 |
*** join/#brlcad csanyipal
(n=csanyipa@91.102.231.33) |
| 17:16.15 |
csanyipal |
Hello! |
| 17:18.32 |
csanyipal |
I'm making a
tutorial for my pupils. I want to ask you about Ellipsoid Generic
(ellg) that can be find in the "Introduction to the MGED" tutorial
at page 261. |
| 17:19.06 |
d-lo |
Ask
away! |
| 17:19.28 |
csanyipal |
I can't
figure out what is the Chord length, l? |
| 17:19.54 |
csanyipal |
I can't find
it here: http://en.wikipedia.org/wiki/Ellipsoid |
| 17:24.10 |
d-lo |
don't quote
me on this, but if you look at the drawing on p261, I believe the
Chord length is the distance between B and C.... |
| 17:26.07 |
d-lo |
i *think* an
ellg is merely an ell with v->c being equal to v->b and l =
b->c. |
| 17:27.04 |
d-lo |
similar is
the ell1. Instead of controlling l (as in the ellg), one controls
r (which is v->b AND v->c) |
| 17:27.22 |
d-lo |
again, don't
quote me :) |
| 17:28.03 |
csanyipal |
d-lo: ok,
I'll think about what did you say! :) |
| 17:28.06 |
d-lo |
wait for
brlcad and/or starseeker and/or anyone else with a firmer grasp on
BRL-CAD's ellipsoid implementation |
| 17:28.22 |
csanyipal |
d-lo:
ok |
| 17:34.38 |
CIA-31 |
BRL-CAD:
03davidloman * r33492 10/rt^3/trunk/ (14 files in 6 dirs): Finished
implementing GeometryManifestMsg. Cleaned up a segfault in
netMsgSerialTest |
| 17:42.50 |
csanyipal |
I try to
create an ellg and I think I figure out what is the Chord length:
it is the Major Axis of the Ellipse.. |
| 17:45.16 |
csanyipal |
I'm sure
about this. :) |
| 17:45.18 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 17:45.28 |
d-lo |
alrighty
then. Good on ya! |
| 17:45.45 |
csanyipal |
d-lo: Thanks
anyway! :) |
| 17:49.33 |
*** join/#brlcad saltan
(n=lievensa@d51530284.access.telenet.be) |
| 17:50.03 |
*** part/#brlcad saltan
(n=lievensa@d51530284.access.telenet.be) |
| 18:03.29 |
*** join/#brlcad jonored_
(n=jonored@pool-71-162-75-2.bstnma.east.verizon.net) |
| 18:10.43 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 18:10.55 |
d-lo |
hai ``Erik_
! |
| 18:12.21 |
d-lo |
kicks CIA-31 |
| 18:12.21 |
CIA-31 |
ow |
| 18:12.25 |
CIA-31 |
BRL-CAD:
03davidloman * r33493 10/rt^3/trunk/ (7 files in 6 dirs):
Consolidated ibme/gs/ge related binary generation into src/iBME.
Moved all test source files into src/test/ |
| 18:12.31 |
CIA-31 |
BRL-CAD:
03davidloman * r33494
10/rt^3/trunk/src/tests/streamSerialTests.cxx: Added
streamSerialTests.cxx into src/test/ |
| 18:37.35 |
*** join/#brlcad BigAToo
(n=BigAToo@rrcs-24-123-229-117.central.biz.rr.com) |
| 19:29.03 |
d-lo |
kicks CIA-31 |
| 19:29.04 |
CIA-31 |
BRL-CAD:
03davidloman * r33495 10/rt^3/trunk/src/GeometryService/
(GeometryService.cxx gsph0.cxx netMsg/NetMsg.cxx): Work towards
having a bare bones (aka running) geometry service. Starting from a
simple tcp echo server for initial phase. |
| 19:29.14 |
CIA-31 |
ow |
| 19:29.29 |
d-lo |
must be cold.
CIA is a bit slow :P |
| 19:43.01 |
*** join/#brlcad bjorklinux
(n=bjork@ip72-204-40-138.fv.ks.cox.net) |
| 19:43.12 |
bjorklinux |
i figured
this would be the best place to ask... what's cigi? |
| 19:43.27 |
bjorklinux |
as in
http://cigi.sourceforge.net |
| 19:43.31 |
bjorklinux |
anything to
do with brlcad? |
| 19:44.49 |
d-lo |
... Common
Image Generator Interface? Centre for International Governance
Innovation? Chicago Interface Group, Inc? |
| 19:46.23 |
bjorklinux |
the image
generator bit. |
| 19:47.00 |
d-lo |
Not that I am
aware of. I am pretty sure that CIGI has everything to do with
realtime simulation. |
| 19:48.12 |
bjorklinux |
hmm. |
| 19:48.40 |
d-lo |
how did you
connect CIGI to BRLCAD? |
| 19:49.02 |
bjorklinux |
it had lots
of graphics :) |
| 19:49.11 |
bjorklinux |
also 'image
generator' |
| 19:49.22 |
bjorklinux |
i thought i'd
start here for clues |
| 20:27.19 |
CIA-31 |
BRL-CAD:
03davidloman * r33496 10/rt^3/trunk/src/iBME/Makefile.am:
integrated gsph0 into the build system. |
| 20:38.07 |
csanyipal |
so
long! |
| 20:48.14 |
brlcad |
d-lo: that
sounds right regarding ellg and ell1 .. just different knobs so you
can specify them more intuitively depending on what
measurements/constraints you have |
| 20:48.43 |
brlcad |
they really
should all three be collapsed into one primitive with variable
typein interfaces, but they're just old history |
| 20:52.18 |
brlcad |
bjorklinux:
we have nothing to do with cigi |
| 21:22.59 |
*** join/#brlcad madant
(n=madant@117.196.128.37) |
| 21:25.14 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 21:38.33 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:10.06 |
*** join/#brlcad saltan
(n=lievensa@d51530284.access.telenet.be) |
| 22:10.40 |
*** part/#brlcad saltan
(n=lievensa@d51530284.access.telenet.be) |
| 22:25.31 |
*** join/#brlcad BigAToo
(n=BigAToo@cpe-24-209-94-205.woh.res.rr.com) |
| 22:40.15 |
bjorklinux |
thanks
brlcad. |
| 22:49.27 |
brlcad |
bjorklinux:
sure .. if you want to do something with us/them -- go for it
;) |
| 23:59.08 |
``Erik |
huh, elise
0-60 4.9, skidpad .97 M3 0-60 4.8, skidpad .98... you're just half
a hair behind me, boy :D *duck* |
| 00:08.05 |
CIA-65 |
BRL-CAD:
03brlcad * r33524 10/brlcad/trunk/TODO: getting incrTcl
subconfigure to work would be kind of a waste of time given how
much it's radically changed for the pending 4.0 release that has a
drastically changed build system. |
| 01:45.50 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:32.12 |
yukonbob |
hey
cadheads |
| 02:35.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-205.sbndin.btas.verizon.net) |
| 02:38.20 |
bjork_ |
such a word
exists? |
| 02:43.48 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178014879.dsl.bell.ca) |
| 02:54.13 |
brlcad |
apparently
;) |
| 03:48.44 |
brlcad |
struggles to find a way to make incrTcl work with system
tcl/tk |
| 04:10.54 |
Ralith |
suggests bribery |
| 04:15.15 |
brlcad |
has a plot developing |
| 04:36.48 |
Twingy |
PEANUT BUTTAH
JELLY TIME!@! |
| 05:00.55 |
brlcad |
peanut buttah
jelly with a baseball bat! |
| 05:02.20 |
poolio |
Heh, I have a
friend who dressed up in a banana suit and went around singing that
for halloween :) |
| 05:02.44 |
brlcad |
hehe |
| 05:15.30 |
Twingy |
polishes up gcam for release tomorrow |
| 05:18.28 |
DanielFalck |
hey Twingy,
what's new in gcam? |
| 05:18.53 |
Twingy |
DanielFalck:
hi |
| 05:19.37 |
DanielFalck |
Twingy: does
it run under Mac OS X? |
| 05:20.24 |
Twingy |
no more
cut/paste/move prev move next, replaced with drag and drop in
treeview, object picking in 3D window, material origin selection,
improved pocketing code, several bug fixes, flip direction, and
adding helical tool paths in sketches atm |
| 05:20.39 |
Twingy |
DanielFalck:
yea, if you have gtk + gtkglext + opengl |
| 05:20.59 |
DanielFalck |
ok, I might
be able to get them installed here |
| 05:21.18 |
Twingy |
after I get
ubuntu .deb package done I need to talk to emc guys to get it onto
live CD |
| 05:21.24 |
Twingy |
after that I
need to update the manual |
| 05:22.20 |
DanielFalck |
I have
gtkglext1 in fink, cool |
| 05:22.39 |
Twingy |
after that I
am extending the Y axis on my mill an extra 4 inches, machining out
a new bedway and rails |
| 05:23.00 |
Twingy |
I need to be
able to cut 9" diameter for a vacuum chamber I'm working
on |
| 05:23.27 |
DanielFalck |
9" diameter
what? |
| 05:23.34 |
Twingy |
circle |
| 05:24.44 |
DanielFalck |
in
aluminum? |
| 05:25.04 |
Twingy |
acrylic, the
bed way is T-6061 aluminum, the rails are T-306
stainless |
| 05:25.45 |
Twingy |
then I am
junking the 1/4 HP AC motor for a 3-phase brushless |
| 05:25.54 |
Twingy |
much smaller
and more efficient |
| 05:26.05 |
Twingy |
and I can
wire speed controller into the xylotex for digital
control |
| 05:27.43 |
Twingy |
I've had
about 20 orders come to the house in the last month |
| 05:29.33 |
DanielFalck |
you make
vacuum chambers commercially? |
| 05:30.40 |
Twingy |
no no, this
is for a flywheel project I'm doing |
| 05:30.48 |
DanielFalck |
oh,
ok... |
| 05:32.50 |
Twingy |
hopefully
another 9 months doesn't go by before the next release |
| 05:33.49 |
DanielFalck |
do you have
dxf import in gcam? |
| 05:34.31 |
Twingy |
that's next
ver |
| 05:34.45 |
Twingy |
I've got all
the contouring algorithms done when I did the RS274X
code |
| 05:34.53 |
Twingy |
so it should
be fairly painless |
| 05:35.23 |
Twingy |
I just don't
want to get bogged down in writing too much software in one
stint |
| 05:35.39 |
DanielFalck |
do you do
offset contour pocketing? |
| 05:35.39 |
Twingy |
gcam is
second to my projects |
| 05:35.58 |
Twingy |
the contour
pocketing is in the same boat, the algorithms are there I just
haven't tied them into the sketches yet |
| 05:36.33 |
Twingy |
there's a ton
of low hanging fruit in gcam right now, just limited amount of time
to do stuff |
| 05:36.37 |
DanielFalck |
I've been
told that the algorithms for pocketing are pretty hard |
| 05:36.57 |
DanielFalck |
I might be
wrong... |
| 05:38.47 |
Twingy |
well zig zag
is trivial, it's just horizontal lines with a finish
pass |
| 05:39.06 |
Twingy |
there are
papers on the contouring, but honestly it's not as complicated as
people make it out to be |
| 05:39.08 |
DanielFalck |
how about
offset contour with islans? |
| 05:39.16 |
DanielFalck |
islands- |
| 05:39.28 |
Twingy |
exactly, so I
have an algorithm that does line/line line/arc arc/arc
intersections |
| 05:39.29 |
DanielFalck |
that's the
one everyone seems to avoid |
| 05:39.44 |
Twingy |
and I can set
a negative offset and perform the intersections |
| 05:40.02 |
Twingy |
once the
offset gets to a point where 0 area exists then it's
done |
| 05:40.37 |
Twingy |
so it's
basically just a for loop calling this function over and over
decreasing the offset by the radius of the end mill |
| 05:40.58 |
Twingy |
and the
islands just form as a result of the intersections |
| 05:41.30 |
Twingy |
all that
intersection code was kind of a headache to write, but it has so
much application |
| 05:41.47 |
DanielFalck |
I hope you
get that one going. Nobody else seems to be working on it in the OS
world |
| 05:42.19 |
Twingy |
I put in a
formal application to GNU community for GNU approval |
| 05:42.32 |
Twingy |
I think it
has enough critical mass to be looked at seriously |
| 05:43.06 |
Twingy |
and I think
once the contour pocketing and STL/DXF is done it's going to put a
number of those less $100 software packages out of
business |
| 05:43.09 |
DanielFalck |
what does the
GNU approval do for the project? |
| 05:43.22 |
Twingy |
it means that
if you log into the gnu ftp site you'll see gcam there |
| 05:43.27 |
DanielFalck |
ok |
| 05:43.34 |
DanielFalck |
just like
gcc |
| 05:43.37 |
Twingy |
right |
| 05:43.43 |
Twingy |
it'll
probably be real close to gcc :) |
| 05:44.20 |
Twingy |
they advocate
using guile for the development environment but we'll see about
that :) |
| 05:44.22 |
DanielFalck |
yes |
| 05:45.01 |
Twingy |
I just keep
chipping away at it |
| 05:45.24 |
Twingy |
I worked on
large software project before this called Nurbana, but I am now
convinced I lost interest because I didn't use it in my
projects |
| 05:45.34 |
Twingy |
I am using
GCAM on a weekly, some times daily basis |
| 05:45.40 |
Twingy |
it's the
perfect synergy |
| 05:48.27 |
DanielFalck |
fink didn't
have gtk+2.10 , so I'm downloading something from the Gtk+ site for
os X now |
| 05:48.30 |
DanielFalck |
2.14 |
| 05:50.07 |
Twingy |
ah |
| 05:50.16 |
Twingy |
what did it
have? |
| 05:50.22 |
DanielFalck |
2.6.10 |
| 05:50.31 |
Twingy |
oh wow, that
is ancient |
| 05:50.37 |
Twingy |
that is like
5 years old |
| 05:50.45 |
DanielFalck |
yeah, fink is
really old in the tooth |
| 05:51.06 |
Twingy |
that came out
long before dapper drake |
| 05:51.14 |
DanielFalck |
it's been
several years since I've used a mac at home and Linux is much nicer
for source code |
| 05:51.27 |
Twingy |
I jut got a
black berry with blue tooth modem tethering |
| 05:51.28 |
DanielFalck |
I'm using
Ubuntu 8.04 on this box |
| 05:51.32 |
Twingy |
I set it up
on my mac in like 30 seconds |
| 05:51.44 |
Twingy |
I can surf
the net at about 1Mb now anywhere |
| 05:52.08 |
Twingy |
works from
ubuntu as well |
| 05:52.14 |
Twingy |
I love
it |
| 05:52.52 |
Twingy |
I got a
little USB thing http://www.cirago.com/images/bluetooth/Cirago_BTA3210_2.jpg |
| 05:53.00 |
Twingy |
I can plug it
into desktop computers and they can surf the net too |
| 05:53.54 |
Ralith |
Twingy: oo,
you're the gcam guy? |
| 05:54.02 |
Twingy |
Ralith:
yes! |
| 05:54.17 |
Ralith |
how hard do
you think it would be to add fused deposition modelling
support? |
| 05:54.34 |
Twingy |
you just need
a command to turn the head on and off right? |
| 05:54.50 |
Twingy |
and it's an
additive process instead of subtractive |
| 05:54.51 |
Ralith |
as far as
tool control? yeah |
| 05:55.03 |
Twingy |
right? |
| 05:55.06 |
Ralith |
yes |
| 05:55.10 |
Twingy |
should be
trivial |
| 05:55.12 |
Ralith |
that's the
bit I'd expect to cause probl-- |
| 05:55.14 |
Ralith |
awesome! |
| 05:55.33 |
Twingy |
in terms of
rendering the final object I just invert the bit on the
voxels |
| 05:55.38 |
Twingy |
so they
appear instead of dissapear |
| 05:55.52 |
Ralith |
what sort of
files can gcam take? |
| 05:56.06 |
Twingy |
Ralith: only
gerber files for circuit boards, next version will have DXF/STL
stuff |
| 05:56.15 |
Twingy |
version after
that I plan on support 4D and 5D mills |
| 05:56.31 |
Ralith |
er, you have
(and have had for a long time) screenshots w/ 3D stuff |
| 05:56.53 |
Twingy |
there will be
a few minor releases in bewtween the next two major
releases |
| 05:57.07 |
Twingy |
to improve
performance and 3D rendering I think |
| 05:57.15 |
Ralith |
so 3D is not
actually currently supported? |
| 05:57.19 |
Twingy |
it
is |
| 05:57.27 |
Ralith |
how, if all
you can take is gerber? |
| 05:57.27 |
Twingy |
wire frame
and voxel view |
| 05:57.42 |
Twingy |
the rendering
is done based on the tool paths and a hunk of material in
gcam |
| 05:57.50 |
Twingy |
it mills away
material |
| 05:57.55 |
Twingy |
you click
render and you see the final part |
| 05:58.00 |
Ralith |
er, doesn't
gcam generate the toolpaths? |
| 05:58.02 |
Twingy |
yes |
| 05:58.10 |
Twingy |
but you can
preview what your part will look like |
| 05:58.14 |
Ralith |
what does it
generate the toolpaths from? |
| 05:58.24 |
Twingy |
it's coarse,
but it's a good way of checking before you cut it out |
| 05:58.33 |
Twingy |
the tool
paths come from my libgcode |
| 05:58.39 |
Twingy |
it's
thousands of lines of code |
| 05:58.45 |
Ralith |
where does it
get the information with which to generate the
toolpaths |
| 05:58.49 |
Ralith |
it's not
telepathic |
| 05:59.07 |
Twingy |
the GUI, you
create sketches, bolt holes, drill holes, etc |
| 05:59.17 |
Twingy |
you see it in
wire frame |
| 05:59.26 |
Ralith |
so it can't
import models at all? |
| 05:59.35 |
Twingy |
only gerber
right now |
| 05:59.41 |
Ralith |
gerber
doesn't do models |
| 05:59.41 |
Twingy |
next version
will be dxf/stl |
| 05:59.42 |
Ralith |
it does
PCBs |
| 05:59.45 |
Twingy |
correct |
| 05:59.51 |
Ralith |
so it can't
import models. |
| 05:59.57 |
Ralith |
damn. |
| 06:00.16 |
Twingy |
it's already
in bugzilla as a feature request |
| 06:00.27 |
Ralith |
no plans for
including BRL-CAD databases in the list of supported formats in the
near future? |
| 06:00.42 |
Twingy |
supporting
brl-cad would be quirky |
| 06:00.54 |
Twingy |
you would be
better off exporting dxf/stl from brl-cad |
| 06:01.13 |
Twingy |
assuming
brl-cad dxf/stl is working now |
| 06:02.39 |
Twingy |
just to give
you an arbitrary date, let's say beginning of summer for dxf/stl
support |
| 06:05.33 |
Ralith |
exporting STL
is lossy |
| 06:05.45 |
Ralith |
you can't
represent anything smooth |
| 06:08.09 |
Twingy |
right, but
keep in mind gcode natively only supports lines and
arcs |
| 06:08.57 |
Twingy |
some of the
objects in brl-cad could be turned into piece wise arcs, but for
the most part it will have to be tesselated anyway to get into arcs
or lines |
| 06:09.04 |
Ralith |
stl doesn't
support arcs. |
| 06:09.14 |
Twingy |
exactly |
| 06:09.20 |
Twingy |
so if brl-cad
has a nurbs surface |
| 06:09.33 |
Ralith |
it can be
much more closely approximated with arcs than with
lines. |
| 06:09.46 |
Twingy |
the spline
will have to undergo decomposition into bezier curves, then into
bernstein polynomials, then into arcs |
| 06:09.52 |
Ralith |
or, at worst,
approximated with similar accuracy with much less data. |
| 06:10.36 |
Twingy |
it would be a
great deal of code to recognize the 20 or 30 primitives in brl-cad
and figure out how to decompose those into arcs
properly |
| 06:10.56 |
Twingy |
especially
with boolean operations |
| 06:11.19 |
Twingy |
brl-cad ray
traces the CSG to get the final result |
| 06:11.29 |
Ralith |
and you could
take advantage of that raytracing. |
| 06:11.38 |
Twingy |
and ray
tracing is tesselating |
| 06:11.40 |
Ralith |
you don't
have to reinvent the wheel. |
| 06:11.53 |
Twingy |
how is ray
tracing different from tesselating? |
| 06:12.06 |
Ralith |
uh, it's a
different thing |
| 06:12.13 |
Twingy |
think about
it... |
| 06:12.14 |
Ralith |
how is
solving a formula different from taking a square root? |
| 06:12.26 |
Twingy |
so with ray
tracing you have a grid of rays |
| 06:12.35 |
Twingy |
and the
result is a collection of intersection points |
| 06:12.44 |
Twingy |
the
intersection points form a point cloud or mesh |
| 06:12.48 |
Ralith |
there's
significantly more to it than that :P |
| 06:12.54 |
Ralith |
not only
that, who said anything about a grid? |
| 06:12.54 |
Twingy |
the mesh is a
tesselated representation of the implicit geometry |
| 06:13.14 |
Ralith |
BRL-CAD gives
you a lot more than a point when you get a rayhit. |
| 06:13.19 |
Twingy |
Ralith:
because you are not beam tracing, a ray is infinitely
thin |
| 06:13.32 |
Ralith |
more than
enough to accurately place circular arcs, in fact. |
| 06:14.01 |
Twingy |
I disagree,
because you can end up resulting in moire and aliasing
artificacts |
| 06:14.31 |
Twingy |
you have to
choose the density of your grid of rays |
| 06:14.40 |
Twingy |
if it is not
high enough you lose detail |
| 06:15.36 |
Twingy |
now, you
could "interpolate" the results returned from the ray
intersections, but you are still not exactly representing the
implicit geometry |
| 06:15.46 |
Twingy |
because ray
tracing is a form tessellating |
| 06:16.32 |
Twingy |
as the grid
density approaches infinity the point cloud approaches and implicit
representation |
| 06:18.24 |
Twingy |
I think you
can clearly see this as an Inductive Proof |
| 06:19.29 |
Twingy |
DanielFalck:
did gtk compile? |
| 06:32.29 |
DanielFalck |
I got it to
build, but I misconfigured it - I have gtk libs for the old fink
build along with the new one |
| 06:32.48 |
DanielFalck |
I'm not even
sure how to clean it up and get things linked right |
| 06:33.15 |
DanielFalck |
I just went
through this with the latest version of tcl/tk and got things
sorted out |
| 06:33.23 |
DanielFalck |
but it takes
me a while |
| 06:34.10 |
DanielFalck |
Twingy: visit
#cam if you feel like it. there are some of us working on/playing
with other os cam systems |
| 06:34.22 |
Twingy |
k |
| 06:34.42 |
DanielFalck |
Dan Heeks has
some interesting stuff as does crotchet |
| 07:02.46 |
Twingy |
looks like he
is making progress |
| 07:02.54 |
Twingy |
how long has
he been at it? |
| 07:03.03 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178014879.dsl.bell.ca) |
| 07:14.28 |
DanielFalck |
I'm not
sure |
| 07:14.45 |
DanielFalck |
he programs
cam for a living |
| 07:23.35 |
Twingy |
so if I put
him out of business that would be bad for him |
| 07:24.13 |
Twingy |
isn't he kind
of hurting himself by giving stuff away for free if he is trying to
make money off of it to survive? |
| 07:24.38 |
DanielFalck |
I'm not sure
of the motivation. You'll have to ask hime |
| 07:24.40 |
DanielFalck |
him |
| 07:30.18 |
DanielFalck |
I'm just glad
he's willing to share |
| 07:31.53 |
Twingy |
you can't
beat free :) |
| 07:32.27 |
DanielFalck |
the other guy
I mentioned, crotchet, is a machinist who has learned to program
c++ |
| 07:33.16 |
DanielFalck |
he's ported
over the old apt360 fortran code (in C, not C++) and has a nice app
called aptsketch, that I actually use for making gcode |
| 07:33.42 |
DanielFalck |
it uses gtkmm
and opengl |
| 07:34.21 |
DanielFalck |
I'm just a
rookie,learning python |
| 07:44.24 |
Twingy |
k, I'm off to
bed |
| 07:44.55 |
DanielFalck |
it was good
chatting with you |
| 08:12.09 |
*** join/#brlcad b0ef`
(n=b0ef@95.34.57.61.customer.cdi.no) |
| 08:15.47 |
*** join/#brlcad madant
(n=madant@117.196.136.108) |
| 09:31.50 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 09:53.06 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 12:18.41 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FD14.dip.t-dialin.net) |
| 13:02.58 |
*** join/#brlcad madant
(n=madant@117.196.138.212) |
| 13:24.34 |
*** join/#brlcad madant1
(n=madant@117.196.138.212) |
| 13:54.01 |
*** join/#brlcad docelic_
(n=docelic@78.134.199.40) |
| 14:00.09 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:52.28 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 15:35.42 |
*** join/#brlcad b0ef`
(n=b0ef@95.34.57.61.customer.cdi.no) |
| 15:52.35 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FD14.dip.t-dialin.net) |
| 15:58.27 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 16:03.06 |
*** join/#brlcad madant
(n=madant@117.196.145.227) |
| 16:31.06 |
*** join/#brlcad madant
(n=madant@117.196.145.227) |
| 17:09.49 |
*** join/#brlcad madant1
(n=madant@117.196.145.227) |
| 17:21.03 |
starseeker |
DanielFalck:
Is there a link for aptsketch anywhere? |
| 17:43.34 |
*** join/#brlcad madant
(n=madant@117.196.145.227) |
| 18:02.08 |
*** join/#brlcad DanielFalck
(n=dan@pool-71-111-65-232.ptldor.dsl-w.verizon.net) |
| 18:02.40 |
DanielFalck |
http://sourceforge.net/projects/aptos/ |
| 18:04.04 |
DanielFalck |
another
interesting project: |
| 18:04.05 |
DanielFalck |
http://heekscnc.blogspot.com/ |
| 18:19.28 |
CIA-65 |
BRL-CAD:
03brlcad * r33525 10/brlcad/trunk/src/other/incrTcl/compat/ (43
files in 2 dirs): |
| 18:19.28 |
CIA-65 |
BRL-CAD: add
the tcl/tk headers for 8.4 since if we're compiling against a
system 8.4, we |
| 18:19.28 |
CIA-65 |
BRL-CAD:
still need access to tclInt.h and friends (which are not publicly
installed |
| 18:19.28 |
CIA-65 |
BRL-CAD:
headers). put them in a version-specific 'compat' directory that we
can later |
| 18:19.28 |
CIA-65 |
BRL-CAD:
refer to via cppflags. |
| 18:19.52 |
CIA-65 |
BRL-CAD:
03brlcad * r33526 10/brlcad/trunk/src/other/incrTcl/Makefile.am:
include compat in the dist |
| 18:27.02 |
CIA-65 |
BRL-CAD:
03brlcad * r33527 10/brlcad/trunk/ (3 files in 3 dirs): |
| 18:27.02 |
CIA-65 |
BRL-CAD: if
we're compiling against a system 8.4, use the newly added 'compat'
headers in |
| 18:27.02 |
CIA-65 |
BRL-CAD:
src/other/incrTcl/compat/8.4 so that we get the proper
internal/private tcl/tk |
| 18:27.02 |
CIA-65 |
BRL-CAD:
headers. this makes the entire compilation succeed using system
tcl/tk with our |
| 18:27.04 |
CIA-65 |
BRL-CAD:
bundled incrTcl, toggled off of the TCL_8_4_HEADERS conditional.
also makes it |
| 18:27.06 |
CIA-65 |
BRL-CAD: so
we can remove that tcl+itcl sanity check section that forced our
tcl/tk if |
| 18:27.08 |
CIA-65 |
BRL-CAD: not
8.5. |
| 18:39.34 |
CIA-65 |
BRL-CAD:
03brlcad * r33528 10/brlcad/trunk/configure.ac: remove some dead
logic, update the comment about -fast (it's because of aliasing),
and remove the silly HAVE_BRLCAD conditional. |
| 18:53.19 |
CIA-65 |
BRL-CAD:
03brlcad * r33529 10/brlcad/trunk/TODO: too vague a task and it's
an on-going one |
| 19:11.36 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-205.sbndin.btas.verizon.net) |
| 20:46.16 |
*** join/#brlcad mafm
(n=mafm@138.Red-83-54-182.dynamicIP.rima-tde.net) |
| 20:49.05 |
mafm |
hi |
| 21:38.23 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-205.sbndin.btas.verizon.net) |
| 22:53.18 |
brlcad |
howdy
mafm |
| 22:53.24 |
brlcad |
(woo hoo, tv
is now up on the wall) |
| 22:56.17 |
mafm |
burn it down!
it only tells you lies :P |
| 22:58.57 |
Ralith |
hehe |
| 23:17.44 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178014879.dsl.bell.ca) |
| 23:18.38 |
IriX64 |
http://www3.sympatico.ca/mario.dulisse2/project-cassandra.png
<--- cassandra coming along :) |
| 23:28.38 |
brlcad |
mafm: hehe,
so true |
| 23:54.38 |
*** join/#brlcad mafm_
(n=mafm@138.Red-83-54-182.dynamicIP.rima-tde.net) |
| 00:06.16 |
mafm |
night |
| 01:25.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-150.sbndin.btas.verizon.net) |
| 01:32.40 |
CIA-31 |
BRL-CAD:
03brlcad * r33541 10/brlcad/trunk/TODO: few ideas that have been on
mind for a while. vrml importer, brl-cad taxonomy document, and
incremental raytrace-based display manager interface. |
| 01:51.45 |
CIA-31 |
BRL-CAD:
03starseeker * r33542
10/brlcad/trunk/doc/html/manuals/mged/mged2.html: Fix problem with
eto specification as reported in bug #2120094 |
| 02:20.23 |
*** join/#brlcad Axman6_
(n=Axman6@210-9-142-162.netspeed.com.au) |
| 02:28.55 |
*** join/#brlcad Axman6__
(n=Axman6@210-9-136-102.netspeed.com.au) |
| 02:33.08 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 02:51.37 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-2025e922198ffa7c) |
| 03:08.34 |
*** part/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-2025e922198ffa7c) |
| 03:11.30 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-2025e922198ffa7c) |
| 03:18.20 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:27.28 |
starseeker |
grumbles... cating mpg files together results in something
that doesn't work on rockbox, and rockbox doesn't (yet) support
movie playlists out of box |
| 03:28.12 |
starseeker |
decides to go for broke and build latest svn with patch, and
crosses fingers he doesn't brick anything... |
| 03:37.13 |
Dr_Phreakenstein |
cating most
types of mpeg files produces something that does not work on most
things. |
| 03:37.36 |
Dr_Phreakenstein |
main
exception is if it is a streamrip |
| 03:37.54 |
Dr_Phreakenstein |
even then,
you must rebuild the index |
| 03:38.15 |
Dr_Phreakenstein |
mencoder of
the mplayer package may be your friend on this |
| 03:38.41 |
Dr_Phreakenstein |
otherwise,
try kino |
| 03:39.10 |
Dr_Phreakenstein |
http://www.kinodv.org/ |
| 03:39.31 |
Dr_Phreakenstein |
(returns to
topic) |
| 03:39.35 |
Ralith |
starseeker:
you could just concat them with mencoder |
| 03:39.50 |
Dr_Phreakenstein |
correct |
| 03:41.38 |
Dr_Phreakenstein |
should look
something like |
| 03:42.08 |
Dr_Phreakenstein |
#mencoder
file1.mpg file2.mpg -o outfile.mpg -oac copy -ovc copy |
| 03:43.14 |
Dr_Phreakenstein |
anyone ever
research STEP, or read the STEP application handbook? |
| 03:43.33 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564870.dsl.bell.ca) |
| 04:14.29 |
brlcad |
starseeker:
while it might work for some combinations of mpg's, I can't imagine
that cat'ing together two random mpg files would work on most
players |
| 04:14.43 |
brlcad |
invalid
timestamps and sync blocks |
| 04:14.53 |
brlcad |
different
encoding settings |
| 04:15.26 |
brlcad |
Dr_Phreakenstein: we've done a lot more
than research it |
| 04:15.47 |
brlcad |
developing a
step importer is one of our top priorities |
| 04:16.37 |
brlcad |
have not read
the step application handbook, though, I must admit |
| 04:17.07 |
brlcad |
downloads |
| 04:21.21 |
Dr_Phreakenstein |
nice |
| 04:22.13 |
Dr_Phreakenstein |
the one i am
refering to was found at |
| 04:22.15 |
Dr_Phreakenstein |
http://www.tc184-sc4.org/SC4_Open/SC4_Standards_Developers_Info/Files/STEP_application_handbook_63006.pdf |
| 04:22.16 |
brlcad |
we have most
of the rest of the spec, though, ap's 203, 214, 22, 23, 24, and
11 |
| 04:22.25 |
brlcad |
nods, already have it |
| 04:22.38 |
Dr_Phreakenstein |
figured that
was it |
| 04:22.52 |
Dr_Phreakenstein |
i just got it
myself |
| 04:23.00 |
Dr_Phreakenstein |
looks like a
nice little read |
| 04:23.17 |
Dr_Phreakenstein |
you mentioned
an importer... |
| 04:23.28 |
Dr_Phreakenstein |
what about
export? |
| 04:23.38 |
brlcad |
eventually,
ideally yes |
| 04:23.52 |
brlcad |
first
priority is on an importer though |
| 04:24.07 |
Dr_Phreakenstein |
i do not
know, but i should think that one would facilitate the other, to an
extent |
| 04:24.17 |
brlcad |
it's actually
a funded priority, importer should be completed sometime this
year |
| 04:24.29 |
brlcad |
to a limited
extent |
| 04:24.35 |
brlcad |
it's a lot
easier to make an exporter |
| 04:25.06 |
brlcad |
more grunt
code in an exporter and basic architecting to let the user specify
what format they want exported |
| 04:26.34 |
brlcad |
example, say
you have a model of just an implicit sphere and a box that overlap
with a CSG operation to subtract one from the other |
| 04:27.02 |
brlcad |
using 203 and
214, we 'could' (and ideally by default will) export exactly that,
preserving our data exactly |
| 04:27.22 |
brlcad |
yet that's
not something most CAD systems will grok |
| 04:29.16 |
brlcad |
other options
might be to output spline-surface brep with csg operations,
evaluated spline-surface brep, evaluated polygonal brep,
volumetric, among others |
| 04:29.58 |
Dr_Phreakenstein |
i
see |
| 04:30.48 |
Dr_Phreakenstein |
well, brlcad
is my cad of choice, except maybe qcad for simple 2d, until i get
better with brlcad |
| 04:31.14 |
Dr_Phreakenstein |
primarily
interested in not losing any data to go to a
postprocessor |
| 04:32.00 |
Dr_Phreakenstein |
should not
need much to load that into a CAM system and send to machine as
STEP-NC |
| 04:32.07 |
brlcad |
Dr_Phreakenstein: so you're interesting in
working on the step exporter? :) |
| 04:32.30 |
brlcad |
thinks you should 'go for it' ;) |
| 04:34.28 |
Ralith |
STEP-NC? |
| 04:34.32 |
brlcad |
be glad to
help out any way I can if you do get started on it |
| 04:34.55 |
brlcad |
looking to
use the NIST toolkit at least for importing -- not sure how helpful
it would be for export |
| 04:37.36 |
Dr_Phreakenstein |
well, i may
not be quite up for it |
| 04:37.46 |
Dr_Phreakenstein |
still
learning brlcad myself |
| 04:38.12 |
Dr_Phreakenstein |
not saying
no, i just do not want to commit to something
unrealistic |
| 04:39.08 |
brlcad |
understandable |
| 04:39.19 |
brlcad |
can you
code? |
| 04:40.54 |
Dr_Phreakenstein |
learning
python |
| 04:40.55 |
brlcad |
the "learning
brl-cad" part is a never-ending process (i've been 'learning' it
for 10 years and don't know it all) |
| 04:41.22 |
brlcad |
just depends
where you draw the line and what to chew off when |
| 04:41.27 |
Dr_Phreakenstein |
at over 5
million lines, i should think not |
| 04:41.29 |
Dr_Phreakenstein |
true |
| 04:41.38 |
brlcad |
it's actually
only about 1 million lines |
| 04:41.56 |
brlcad |
just barely
over 1 |
| 04:46.51 |
brlcad |
(don't count
the sources in src/other/ and regress/ -- they're 3rd party bundled
dependencies and long regression scripts) |
| 04:47.12 |
brlcad |
can run
sh/enumeration.sh to get more details if you have a source
checkout |
| 04:47.26 |
Dr_Phreakenstein |
i ran it, and
it failed |
| 04:47.41 |
brlcad |
oh? |
| 04:47.51 |
Dr_Phreakenstein |
i used find,
grep, and wc |
| 04:48.50 |
IriX64 |
http://rafb.net/p/grYR4Y43.html
<--- this at install time, i was hoping it was fixed since
last i reported it |
| 04:49.51 |
Dr_Phreakenstein |
cat `find
-type f|grep -v .svn`|wc -l |
| 04:49.56 |
Dr_Phreakenstein |
that's what i
used |
| 04:50.33 |
brlcad |
IriX64: we
talked about that just *yesterday* |
| 04:51.16 |
brlcad |
so stop
pasting it unless you figure something new out |
| 04:51.31 |
Dr_Phreakenstein |
on svn
33542 |
| 04:51.39 |
brlcad |
Dr_Phreakenstein: which is why you're
about 4 million lines off ;) |
| 04:51.53 |
Dr_Phreakenstein |
i would
suppose so |
| 04:52.02 |
Dr_Phreakenstein |
5644578 |
| 04:52.13 |
Dr_Phreakenstein |
that is the
dumb counting method |
| 04:52.13 |
brlcad |
can you paste
the output of enumeration.sh ? |
| 04:52.18 |
Dr_Phreakenstein |
... |
| 04:53.07 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.08 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.10 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.11 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.13 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.14 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.16 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.17 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.19 |
Dr_Phreakenstein |
... |
| 04:53.26 |
Dr_Phreakenstein |
2374 BRL-CAD
Files |
| 04:53.26 |
brlcad |
well that
much looks okay |
| 04:53.28 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.29 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.30 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:53.32 |
Dr_Phreakenstein |
expr: syntax
error |
| 04:53.33 |
Dr_Phreakenstein |
expr: syntax
error |
| 04:53.37 |
Dr_Phreakenstein |
expr: syntax
error |
| 04:53.38 |
Dr_Phreakenstein |
dc: stack
empty |
| 04:53.41 |
Dr_Phreakenstein |
dc: stack
empty |
| 04:53.42 |
Dr_Phreakenstein |
dc: stack
empty |
| 04:53.44 |
Dr_Phreakenstein |
dc: stack
empty |
| 04:53.50 |
Dr_Phreakenstein |
dc: stack
empty |
| 04:53.54 |
Dr_Phreakenstein |
dc: stack
empty |
| 04:53.56 |
Dr_Phreakenstein |
----------------------------------------- |
| 04:53.58 |
Dr_Phreakenstein |
--
LINE COUNT TOTALS -- |
| 04:54.02 |
Dr_Phreakenstein |
----------------------------------------- |
| 04:54.04 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.06 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.08 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.10 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.12 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.14 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.16 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.18 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.21 |
brlcad |
so cascade
counting failure |
| 04:54.22 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.26 |
Dr_Phreakenstein |
<PROTECTED> |
| 04:54.28 |
Dr_Phreakenstein |
1564461 3rd
Party Code (not counted above) |
| 04:54.30 |
Dr_Phreakenstein |
(edited for
some redundancy) |
| 04:54.54 |
Dr_Phreakenstein |
note, I am
using amd64 arch |
| 04:54.58 |
brlcad |
btw, pastebin
would probably be better for most things over just a handful of
lines (for future ref) ;) |
| 04:55.04 |
brlcad |
that wouldn't
matter |
| 04:55.12 |
brlcad |
it's just a
shell script |
| 04:55.25 |
Dr_Phreakenstein |
well, dc
often fails |
| 04:55.32 |
Dr_Phreakenstein |
have not
investigated why |
| 04:55.58 |
brlcad |
dc is because
the expr's fail |
| 04:56.40 |
brlcad |
expr's fail
because a previous count failed |
| 04:57.40 |
brlcad |
aha, that's
right around where it starts using awk |
| 04:57.44 |
brlcad |
do you have
awk? |
| 04:58.15 |
brlcad |
and is this a
linux amd64 or some other OS? |
| 04:58.46 |
Dr_Phreakenstein |
yes,
gentoo |
| 04:59.06 |
Dr_Phreakenstein |
oh,
yes |
| 04:59.14 |
Dr_Phreakenstein |
can't get by
w/out it |
| 04:59.48 |
Dr_Phreakenstein |
GNU Awk
3.1.6 |
| 05:02.39 |
Dr_Phreakenstein |
<brlcad> thanks for tip on pastebin;
i've never used it |
| 05:02.52 |
brlcad |
sure |
| 05:03.02 |
brlcad |
there are a
bunch of them |
| 05:03.46 |
brlcad |
e.g., one at
http://paste.bzflag.bz/ and
.. |
| 05:03.50 |
brlcad |
~pastebin |
| 05:03.50 |
ibot |
[~pastebin] A
"pastebin" is a web-based service where you can paste anything over
3 lines without flooding the channel. Here are links to a few :
http://www.pastebin.com ,
http://pastebin.ca , http://channels.debian.net/paste
, http://paste.lisp.org ,
http://www.rafb.net/paste |
| 05:03.56 |
brlcad |
few
others |
| 05:04.17 |
Dr_Phreakenstein |
thanks |
| 05:04.18 |
brlcad |
the .com is
probably the worst |
| 05:04.40 |
Dr_Phreakenstein |
in terms of
over use? |
| 05:05.16 |
brlcad |
overuse (lag,
spam), often unreachable on various networks due to
blocks/abuse |
| 05:07.43 |
Dr_Phreakenstein |
nice |
| 05:07.55 |
Dr_Phreakenstein |
will use in
future |
| 05:11.13 |
CIA-31 |
BRL-CAD:
03brlcad * r33543 10/brlcad/trunk/sh/enumerate.sh: try a few minor
portability tweaks for the 'sum' function |
| 05:11.25 |
brlcad |
give that a
try |
| 05:14.05 |
CIA-31 |
BRL-CAD:
03brlcad * r33544 10/brlcad/trunk/NEWS: Robert Penny reported and
fixed a minor documentation bug in the mged tutorial where the 'in'
command had wrong values listed (two transposed params) |
| 05:17.30 |
Dr_Phreakenstein |
http://pastebin.ca/1307831 |
| 05:18.21 |
Dr_Phreakenstein |
expires 1
hr |
| 05:23.03 |
brlcad |
no matter, a
"no change" would have worked too in that particular instance
;) |
| 05:23.25 |
brlcad |
guessing it's
the sum function, just not sure where/why yet |
| 05:23.37 |
brlcad |
adding in
some debug |
| 05:28.45 |
Dr_Phreakenstein |
will
investigate |
| 05:37.37 |
Dr_Phreakenstein |
<brlcad>please see http://pastebin.ca/1307843 |
| 05:37.48 |
Dr_Phreakenstein |
turns out you
have to run it from that dir |
| 05:38.03 |
Dr_Phreakenstein |
please
compare counts to yours to make sure they are good |
| 05:40.37 |
Dr_Phreakenstein |
i was running
as sh/enumerate.sh from brlcad directory |
| 05:41.37 |
brlcad |
that's how I
usually run it actually |
| 05:41.42 |
brlcad |
but that does
help |
| 05:41.43 |
CIA-31 |
BRL-CAD:
03brlcad * r33545 10/brlcad/trunk/sh/enumerate.sh: add some basic
debugging to help isolate a problem with the tabulations on linux
from Dr_Phreakenstein, can run via: DEBUG=1
sh/enumerate.sh |
| 05:47.40 |
Dr_Phreakenstein |
ok, this does
not make sense... |
| 05:47.54 |
Dr_Phreakenstein |
i ran it from
brlcad root... |
| 05:48.48 |
Dr_Phreakenstein |
with debug,
it got same count and no errors (well, + 8 lines, but that is
expected from change. other count was off many
thousands) |
| 05:49.53 |
brlcad |
what are your
debug lines? |
| 05:52.38 |
Dr_Phreakenstein |
http://pastebin.ca/1307850 |
| 05:55.29 |
brlcad |
huh, that is
very odd |
| 05:55.43 |
brlcad |
i mean, it
looks like what I'd expect |
| 05:56.20 |
brlcad |
everything
looks fine other than it being a clean checkout count so generated
files aren't counted |
| 06:00.00 |
brlcad |
what's odd is
that it suddenly works now.. (does it work without
DEBUG=1?) |
| 06:00.07 |
Dr_Phreakenstein |
checking |
| 06:02.11 |
Dr_Phreakenstein |
sure 'nuff,
looks good |
| 06:02.17 |
brlcad |
huh! |
| 06:06.11 |
brlcad |
then out of
ideas beyond a shell bug or some wierd typo somewhere (which I
don't see) |
| 06:07.26 |
Dr_Phreakenstein |
neither do
i |
| 06:07.39 |
brlcad |
and I must
fold it up for tonight though, too .. early meeting later
today |
| 06:07.45 |
brlcad |
at least it
runs now |
| 06:08.14 |
Dr_Phreakenstein |
I am no sh
wizard, but i vote to leave debug in there, since magic seems to
work, now |
| 06:08.26 |
Dr_Phreakenstein |
have fun at
meeting |
| 06:11.05 |
brlcad |
yeah, will
need some more work |
| 06:11.16 |
brlcad |
maybe more
pervasive debug statements |
| 06:11.21 |
brlcad |
anyways,
cheers! |
| 09:46.41 |
*** join/#brlcad clock_
(n=clock@77-58-234-87.dclient.hispeed.ch) |
| 10:06.33 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 10:16.53 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-59-82-252-168-15.adsl.proxad.net) |
| 11:22.13 |
*** join/#brlcad mafm
(n=mafm@30.Red-88-23-76.staticIP.rima-tde.net) |
| 11:32.29 |
mafm |
hi |
| 11:43.51 |
*** join/#brlcad micges
(n=michu@29.6.28.78.cable.dyn.petrus.com.pl) |
| 11:57.26 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:23.28 |
*** part/#brlcad micges
(n=michu@29.6.28.78.cable.dyn.petrus.com.pl) |
| 12:31.33 |
*** join/#brlcad CIA-31
(n=CIA@208.69.182.149) |
| 12:51.28 |
brlcad |
howdy
howdy |
| 12:52.12 |
brlcad |
mafm: tv is
doing just fine, great actually |
| 12:53.46 |
archivist |
becoming a
couch potato |
| 12:54.57 |
mafm |
but probably
is telling you lies anyway :D |
| 12:58.02 |
brlcad |
the lies are
on par with the ones I hear in real life |
| 12:58.37 |
brlcad |
mostly
background noise while I code unless I'm watching a movie (which is
what I do most of the time with it) |
| 13:00.44 |
brlcad |
wow, nice ..
http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt |
| 13:08.34 |
alex_joni |
that should
boost things |
| 13:11.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 13:22.17 |
mafm |
in the last
years I forgot about tv, I lived in houses without it and not
missing it much, it's strange |
| 13:23.35 |
mafm |
hmm, LGPL as
in linking non-open programs? |
| 13:24.41 |
mafm |
so it's now
mostly like GTK |
| 13:30.44 |
starseeker |
's jaw drops |
| 13:30.53 |
starseeker |
Uh.... |
| 13:31.11 |
starseeker |
Didn't that
just blow Trolltech's business model away? |
| 13:31.20 |
starseeker |
or Nokia's
now I guess? |
| 13:32.53 |
starseeker |
gleefully contemplates an unholy mating of QT and
Ogre3d |
| 13:33.57 |
starseeker |
glares at rockbox's player - for some reason mpg's combined
with mencoder don't give back audio |
| 13:34.13 |
starseeker |
Dr_Phreakenstein: thanks, that should have
worked |
| 13:34.51 |
starseeker |
almost bricked ipod trying to build and install custom
version - apparently it's VERY sensitive to which compiler
version... |
| 13:35.22 |
*** join/#brlcad CIA-44
(n=CIA@208.69.182.149) |
| 13:35.28 |
starseeker |
alright,
nevermind |
| 13:35.38 |
starseeker |
prepares to launch back into the fray |
| 13:53.35 |
*** join/#brlcad docelic
(n=docelic@78.134.201.183) |
| 14:32.45 |
*** join/#brlcad worldmonkey
(n=klh@mmds-216-19-34-118.twm.az.commspeed.net) |
| 15:45.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C7D3.dip.t-dialin.net) |
| 16:24.52 |
CIA-44 |
BRL-CAD:
03bob1961 * r33546 10/brlcad/trunk/src/shapes/picket_fence.c:
Initialization not needed on these character arrays (i.e. they're
inititialized below before being used). Besides, windows doesn't
like it. |
| 16:28.18 |
CIA-44 |
BRL-CAD:
03brlcad * r33547 10/brlcad/trunk/src/shapes/picket_fence.c: msvc
probably didn't like that they were empty initializers. give them a
value and it should be happy. |
| 16:42.37 |
*** join/#brlcad madant
(n=madant@117.196.139.156) |
| 16:43.20 |
CIA-44 |
BRL-CAD:
03bob1961 * r33548 10/brlcad/trunk/src/libged/ (inside.c typein.c):
Add code to prevent interrupts during database writes. |
| 17:03.19 |
CIA-44 |
BRL-CAD:
03bob1961 * r33549 10/brlcad/trunk/src/mged/ (Makefile.am arbs.c
cmd.c cmd.h inside.c setup.c typein.c): Mods to use libged's ged_in
and ged_inside functions. |
| 17:15.48 |
*** join/#brlcad mafm_
(n=mafm@30.Red-88-23-76.staticIP.rima-tde.net) |
| 17:20.35 |
*** join/#brlcad madant
(n=madant@117.196.134.104) |
| 17:21.54 |
CIA-44 |
BRL-CAD:
03brlcad * r33550 10/brlcad/trunk/BUGS: mged on mac crashes if you
link against the system tcl/tk libs |
| 17:24.33 |
CIA-44 |
BRL-CAD:
03brlcad * r33551 10/brlcad/trunk/BUGS: the fast4-g line skipping
bug was fixed a while back |
| 17:27.13 |
CIA-44 |
BRL-CAD:
03brlcad * r33552 10/brlcad/trunk/BUGS: |
| 17:27.15 |
CIA-44 |
BRL-CAD: pipe
primitive no longer calls dynamic allocation during run-time thanks
to |
| 17:27.17 |
CIA-44 |
BRL-CAD:
john. remove the lingering default doesn't work (because it seems
to work just |
| 17:27.19 |
CIA-44 |
BRL-CAD: fine
and that code has changed a fair bit). also, rtwizard seems to be
working |
| 17:27.21 |
CIA-44 |
BRL-CAD: just
fine now too. |
| 17:30.18 |
CIA-44 |
BRL-CAD:
03bob1961 * r33553 10/brlcad/trunk/misc/win32-msvc8/ (4 files in 4
dirs): Updates to get things compiling on Windows. |
| 17:35.57 |
CIA-44 |
BRL-CAD:
03brlcad * r33554 10/brlcad/trunk/ (BUGS
src/tclscripts/mged/text.tcl): |
| 17:35.59 |
CIA-44 |
BRL-CAD: mged
should read just fine from stdin now with the handful of trickeries
going |
| 17:36.01 |
CIA-44 |
BRL-CAD: on.
this also fixes one remaining bug when reading in from stdin via
gets -- |
| 17:36.03 |
CIA-44 |
BRL-CAD: was
getting an error of: can't rename to "execute_cmd_save": command
already |
| 17:36.05 |
CIA-44 |
BRL-CAD:
exists |
| 17:39.26 |
brlcad |
howdy madant
! |
| 17:40.23 |
madant |
hi sean
:) |
| 17:40.32 |
madant |
happy new
year |
| 17:40.36 |
brlcad |
likewise |
| 17:40.40 |
brlcad |
how's the
break? |
| 17:40.55 |
madant |
awesome till
now.. |
| 17:41.07 |
brlcad |
classes
starting back up? |
| 17:41.18 |
madant |
not
yet |
| 17:41.39 |
madant |
went for some
climbing towards the end of the year |
| 17:42.09 |
madant |
sports
climbing mostly .. was fun.. i think i have wasted enough time
loitering around enjoying though :D |
| 17:42.14 |
brlcad |
so then
what's the "till now"? |
| 17:42.24 |
brlcad |
nods |
| 17:42.50 |
madant |
i might be
going to an Institute for a couple of months to get exposure into
some sustainable technologies |
| 17:43.25 |
madant |
and I have an
Interview from a B-school coming up towards the end of
March.. |
| 17:43.54 |
madant |
Imagine 200
people getting selected out of 2,80,000 :D |
| 17:44.41 |
madant |
and in the
middle of all this I haven't been able to do a single productive
thing since september :D |
| 17:44.50 |
madant |
how is the
winter in US ? |
| 17:45.27 |
brlcad |
brick |
| 17:45.31 |
brlcad |
er, brisk
:) |
| 17:46.40 |
brlcad |
productive,
but so much going on that it's tricky to stay focused on any one
task for very long |
| 17:47.02 |
madant |
:D I live
pretty close to the equator .. so almost no winter
here.. |
| 17:47.31 |
brlcad |
nods |
| 17:47.32 |
madant |
in the end to
create anything of value one has to stay focused on one task for
long |
| 17:48.09 |
madant |
geometry
service coming up good ? |
| 17:48.15 |
brlcad |
used to have
that back in the day, but seasons are nice for mixing things up
every now and then (e.g., easier to code in the winter when there's
really not much more you could do outside) |
| 17:48.25 |
brlcad |
yeah, steady
pace there |
| 17:48.46 |
brlcad |
libged's
getting tied back into mged now, which should flesh out any
remaining issues |
| 17:49.18 |
brlcad |
the service
daemon is just about ready to go on-line for simple read/write
testing probably in a week or so |
| 17:49.30 |
madant |
what about
mafm's ide work |
| 17:50.21 |
brlcad |
not much has
changed there |
| 17:50.30 |
brlcad |
it's about
where he left it |
| 17:50.54 |
brlcad |
that's one of
a hundred projects I'd love to be working on |
| 17:51.14 |
madant |
hmm.. I am
really hopeful of spending at least 15 hours per week on
libpc |
| 17:51.24 |
mafm |
ide? |
| 17:51.35 |
brlcad |
the new
gui |
| 17:51.36 |
madant |
oops i meant
gui :D |
| 17:52.11 |
brlcad |
you going to
apply to gsoc again if we participate again? |
| 17:52.32 |
mafm |
me? |
| 17:52.36 |
madant |
don't know
about my student status |
| 17:52.52 |
mafm |
I don't think
that I'll be eligible anymore |
| 17:52.55 |
brlcad |
an informal
announcement just went out a couple days ago saying it's on again
for this year |
| 17:53.02 |
brlcad |
mafm:
oh? |
| 17:53.12 |
brlcad |
that partly
sucks :) |
| 17:53.21 |
madant |
yeah i saw
the group post.. lh trying to publicise :D |
| 17:53.24 |
brlcad |
i mean great
that you're done and all, if that's why :) |
| 17:53.55 |
brlcad |
course, you
could always continue as a mentor too ;) |
| 17:54.06 |
madant |
I would love
to take part again.. but i think i would love to work on it before
.. morally feels odd if i only work during SoC :P |
| 17:54.11 |
mafm |
I'm finishing
the project and I have to defend it, but I don't know if that will
count |
| 17:54.39 |
madant |
http://en.wikipedia.org/wiki/Indian_Institutes_of_Management
is the B-school i was talking about :) |
| 17:54.41 |
brlcad |
mafm: will
you still be a full-time student by the time the program
begins? |
| 17:54.47 |
mafm |
if not I
could be mentor I guess, but I don't have much experience as
mentor |
| 17:55.17 |
mafm |
begins by the
end of may? I don't think so, but not sure |
| 17:55.24 |
madant |
would we be
getting more slots this year ? i mean more students compared to
last ? |
| 17:55.59 |
brlcad |
madant: so
why wouldn't yout have student status? those are business
schools |
| 17:56.24 |
madant |
yeah i will
have student status if I clear the interview :) |
| 17:56.53 |
madant |
basically .28
million people wrote in.. they have shortlisted 800 :D |
| 17:57.11 |
brlcad |
and no,
wouldn't likely accept more slots -- that pretty much put us at
effective mentoring capacity |
| 17:57.12 |
madant |
now i have to
clear the interview to be in the 170 or so :D |
| 17:57.58 |
madant |
can imagine..
without good mentoring especially in such a huge code base things
can go pretty crazy |
| 17:57.59 |
brlcad |
totally
depends on the students, but if you guys had been more 'green', it
could have been pretty bad with four, or could have easily taken 8
.. but 4 people working full time is a lot of progress to review
and integrate regardless |
| 17:58.33 |
brlcad |
probably will
reduce the slot count for bzflag |
| 17:58.35 |
mafm |
more
green? |
| 17:58.48 |
mafm |
immature? |
| 17:58.56 |
madant |
i think he
means active :D |
| 17:59.11 |
brlcad |
with the
weaker students there last year, six slots was too many (and we had
2X the number of mentors as here) |
| 17:59.18 |
brlcad |
green ==
inexperienced |
| 17:59.52 |
madant |
i think
mentoring must be tougher than coding . |
| 18:00.17 |
madant |
I have always
found checking someone else's code difficult compared to
writing |
| 18:03.02 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 18:03.02 |
madant |
let me see
how much progress I can make in the next couple of months,
otherwise it would be pointless to eat up a gsoc slot @ brl-cad
which some other student could use for doing some good
work. |
| 18:03.04 |
brlcad |
depends on
the code and who wrote it ;) |
| 18:03.16 |
madant |
@brlcad
true |
| 18:03.43 |
madant |
u must have
read the beautiful code book we got last year as students
? |
| 18:04.05 |
brlcad |
some of it
was quite nice actually |
| 18:04.40 |
brlcad |
you guys (all
4) were pretty above par in terms of readability and
communication |
| 18:05.03 |
madant |
I totally
loved the section on geometry where the author discusses various
ways of checking for collinearity |
| 18:05.08 |
madant |
of three
points |
| 18:05.11 |
brlcad |
I think that
libpc is coming together quite nicely actually |
| 18:05.34 |
brlcad |
section on
geometry? |
| 18:05.37 |
brlcad |
some
book? |
| 18:06.16 |
madant |
not a
section.. a chapter. |
| 18:07.19 |
madant |
1 sec i will
give the link |
| 18:07.47 |
brlcad |
an entire
chapter that says two slopes are equal? |
| 18:08.16 |
brlcad |
or adding two
distances will give the third? |
| 18:08.22 |
mafm |
haven't found time to read the Beautiful Code book
yet |
| 18:08.23 |
madant |
:D not really
he considers the comparing slopes and addition idea |
| 18:08.24 |
mafm |
:( |
| 18:08.43 |
madant |
but then in
the case of slopes there is the issue of infinite slope for a
vertical line |
| 18:08.59 |
mafm |
so what's the
plan for gsoc this year? |
| 18:09.13 |
madant |
and for the
distances there is the case of square roots being involved and
floating point considerations |
| 18:09.50 |
mafm |
another 4
students? I might consider applying if I had the possibility, but
it's not an strict requirement for my collaboration with
brl-cad |
| 18:09.53 |
brlcad |
madant: sure,
but those don't mean the approach itself is flawed, they're just
boundary cases that have to be dealt with on the
implementation |
| 18:10.15 |
brlcad |
mafm: up to 4
(if we get accepted) |
| 18:10.17 |
madant |
exactly.. the
author was just putting forward his concept of beautiful
code |
| 18:10.22 |
mafm |
I don't know
if I'd be prepared for being a mentor, but when I'm done with the
project (3 months or so) I should have more time available and less
traveling to do |
| 18:10.23 |
madant |
in the end
the most elegant solution :) was finding the area of the triangle
formed by the three points which is a simple
determinant |
| 18:10.28 |
brlcad |
highly expect
org selections will be reduced this year |
| 18:10.45 |
brlcad |
mafm: you
could specifically mentor someone working on the gui ;) |
| 18:10.52 |
brlcad |
picking up
where you left off |
| 18:10.57 |
madant |
brlcad: why ?
last year google had trouble coordinating ? |
| 18:10.59 |
mafm |
for
continuing with the gui and so on (I don't know if you're finished
with the refactoring, haven't seen anything on -devel ML about
that) |
| 18:11.23 |
mafm |
well, but the
applicant might be more experience than me, that's embarrasing
:D |
| 18:11.25 |
brlcad |
madant: nope,
reduced economy is making spending hard for most
companies |
| 18:11.29 |
mafm |
experienced* |
| 18:11.43 |
brlcad |
the fact that
they're even going to hold a gsoc is a pretty big deal |
| 18:12.21 |
brlcad |
mafm: I
haven't even gotten started on the refactoring aspect .. and the
announcement today has opened up another possibility that was a
non-starter previously |
| 18:12.23 |
madant |
brlcad: maybe
that's why the heads up. I mean i was kind of surprised why LH felt
like spreading the news |
| 18:13.19 |
brlcad |
for some
perspective, even the Microsoft gorilla is expected to lay off
about 17k people worldwide in order to safe money |
| 18:13.22 |
brlcad |
er,
save |
| 18:13.23 |
mafm |
you mean the
announcement of gsoc? but that's what a few days ago, wasn't
it? |
| 18:13.34 |
madant |
It didn't
even strike me that they might consider not conducting it
:D |
| 18:13.50 |
brlcad |
yeah |
| 18:14.07 |
mafm |
so another
student would do the refactoring... of what? GUI or other internal
parts? |
| 18:14.29 |
brlcad |
some
companies are in pretty big trouble .. fortunately google has been
doing pretty well (the stock market reinforces that position
too) |
| 18:14.43 |
brlcad |
mafm:
whatever they propose |
| 18:15.04 |
brlcad |
picking up
where you left off and making more progress is all that matters..
work is work |
| 18:15.09 |
brlcad |
regardless of
it being on the front-end or back-end |
| 18:15.17 |
mafm |
I
see |
| 18:15.55 |
mafm |
well, as I
said I might continue my work somewhat soon |
| 18:16.31 |
brlcad |
I'd still
like to see the prototype get closer to visually resembling some of
the back look n' feel of the IOE, there's plenty of engine work to
be done, build system integration/cleanup, command integration,
... |
| 18:19.20 |
madant |
brlcad: this
is the page and the book
http://books.google.com/books?id=gJrmszNHQV4C&pg=RA7-PA519&lpg=RA7-PA519 |
| 18:19.38 |
mafm |
yep, it's a
lot of work really |
| 18:21.35 |
madant |
and the
article was by Brian Hayes - Writing Programs for "The
Book" |
| 18:22.37 |
madant |
mafm: do read
Beautiful code , some parts are good :) and Best of luck for
defending your thesis |
| 18:23.44 |
brlcad |
so he
recommends the area approach, simple enough |
| 18:24.01 |
brlcad |
ah, so this
is the book google sent you guys? |
| 18:24.06 |
madant |
yep |
| 18:24.11 |
CIA-44 |
BRL-CAD:
03bob1961 * r33555 10/brlcad/trunk/NEWS: Updates to reflect change
in MGED's "inside" command. |
| 18:24.56 |
CIA-44 |
BRL-CAD:
03bob1961 * r33556 10/brlcad/trunk/src/libtclcad/ged_obj.c: Minor
mod. |
| 18:24.58 |
mafm |
yes, I
might... but I have to do much more reading :| |
| 18:25.17 |
mafm |
and the book
is quite a brick |
| 18:25.25 |
mafm |
last year's
was more manageable |
| 18:25.54 |
madant |
:D i think
this one was more enjoyable.. |
| 18:27.43 |
mafm |
I have about
40 books to read, half of them somewhat urgently :| |
| 18:28.46 |
mafm |
hmm, nope,
more like 10 actually -- and fortunately |
| 18:29.02 |
CIA-44 |
BRL-CAD:
03brlcad * r33557 10/brlcad/trunk/BUGS: make extrude no longer
crashes, bot values display with local units |
| 18:29.56 |
madant |
my very
incomplete Reading List http://dawtho.googlepages.com/ReadingList |
| 18:34.27 |
madant |
brlcad:
regarding libpc, I will go back to the list of TODOs I had at the
end of gsoc and start finishing them one by one. |
| 18:35.37 |
brlcad |
madant:
sounds like a plan ;) |
| 18:35.39 |
mafm |
madant: R,
the language? |
| 18:36.05 |
madant |
there is a
boundary problem which sort of ate my head for quite sometime. I
have temporarily sorted it out by storing the value of the variable
before iteration |
| 18:36.41 |
madant |
basically, if
the variable value is on the boundary the iteration somehow does
not go through the entire sample space. |
| 18:36.56 |
madant |
mafm:
yeah |
| 18:37.16 |
madant |
mafm: The R
book is not that impressive though.. very sloppily written i
think |
| 18:37.41 |
mafm |
I have to
deal with it in my project |
| 18:38.08 |
madant |
kewl, you are
working in statistics ? |
| 18:38.48 |
mafm |
nope |
| 18:38.57 |
mafm |
well,
somewhat |
| 18:39.14 |
mafm |
not-supervised learning |
| 18:40.29 |
madant |
so u use R
for analysing the results ? |
| 18:40.59 |
mafm |
I have to
translate from R and Fortran to Java |
| 18:41.03 |
madant |
mafm: is
machine learning fun? |
| 18:41.19 |
madant |
:O why Java
? |
| 18:41.23 |
madant |
is javaphobic |
| 18:41.24 |
mafm |
to classify
automatically objects in different clusters |
| 18:41.31 |
mafm |
requirements
of the ESA |
| 18:42.48 |
mafm |
R is a bit
chaotic for big projects I think (I'm not fan of weakly-typed
languages in general), but anyway it was not my
decision |
| 18:43.08 |
mafm |
but it's very
handy for some tasks |
| 18:43.25 |
madant |
R is pretty
neat. I mean you can pretty much do anything with it if numbers are
involved |
| 18:43.38 |
BigAToo |
Do any of you
know where I can get a ver 7.12.2 that is compiled for x86 32bit to
try? |
| 18:44.42 |
madant |
mafm: I am
interested in Morphometric applications |
| 18:45.16 |
madant |
I would have
loved to try some economic ( econometric ) modeling but my economic
skills suck i think |
| 18:46.13 |
mafm |
BigAToo:
nope, sorry |
| 18:46.52 |
mafm |
R has
automatic plotting and so on, is kind of a command-line spreadsheet
:D |
| 18:47.31 |
``Erik |
kinda like
gnuplot? O.o |
| 18:47.45 |
mafm |
never used
it |
| 18:48.13 |
mafm |
but you can
create matrices and vectors of many types and ways and operate with
functions over the data |
| 18:48.20 |
BigAToo |
I have loved
7.10.4 that I have been using but would like to see the new stuff.
Thanks |
| 18:56.00 |
mafm |
BigAToo: for
some reason there's only amd64, for linuz |
| 18:58.11 |
BigAToo |
Yep, I am
going to try it on my XP VM and then try and compile
it. |
| 19:05.47 |
*** join/#brlcad b0ef
(n=b0ef@95.34.57.61.customer.cdi.no) |
| 19:06.52 |
*** join/#brlcad madant
(n=madant@117.196.128.50) |
| 19:19.20 |
brlcad |
BigAToo: an
updated 32-bit binary should be uploaded soon |
| 19:20.08 |
brlcad |
from 7.10 to
7.12 is mostly minor updates -- you can see the list of changes
since 7.10.4 in the NEWS file:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/NEWS |
| 19:20.23 |
brlcad |
~factinfo
cadnews |
| 19:20.23 |
ibot |
brlcad:
there's no such factoid as cadnews |
| 19:20.33 |
brlcad |
~cadnews is
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/NEWS |
| 19:20.34 |
ibot |
brlcad:
okay |
| 19:20.48 |
brlcad |
~cadtodo is
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/TODO |
| 19:20.49 |
ibot |
brlcad:
okay |
| 19:20.53 |
brlcad |
~cadbugs is
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/BUGS |
| 19:20.54 |
ibot |
okay,
brlcad |
| 20:08.32 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 20:54.55 |
madant |
loved "Man on Wire" |
| 20:56.31 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C7D3.dip.t-dialin.net) |
| 21:10.07 |
*** join/#brlcad CIA-19
(n=CIA@208.69.182.149) |
| 21:30.16 |
CIA-19 |
BRL-CAD:
03bob1961 * r33558 10/brlcad/trunk/src/ (libged/3ptarb.c mged/cmd.c
mged/cmd.h mged/setup.c): Added "more args" behavior to libged's
ged_3ptarb and modified MGED to use it. |
| 21:39.11 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564870.dsl.bell.ca) |
| 21:41.03 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:12.24 |
*** join/#brlcad docelic
(n=docelic@78.134.201.183) |
| 22:43.45 |
*** join/#brlcad smurfette
(n=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) |
| 00:32.13 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:50.38 |
starseeker |
grins as freecad bombs trying to load the IGES openmoko
model |
| 00:50.50 |
starseeker |
that one
seems to be a toughie |
| 02:41.00 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 02:41.02 |
Dr_Phreakenstein |
wow. those
openmoko files are fairly sizable |
| 03:21.54 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-196-139.we.res.rr.com) |
| 03:43.48 |
yukonbob |
hello,
cadheads |
| 03:58.23 |
docelic |
aoy
yb |
| 04:29.11 |
brlcad |
howdy |
| 04:30.44 |
DanielFalck |
hi
brlcad |
| 04:44.36 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 04:48.36 |
brlcad |
howdy
DanielFalck |
| 04:48.55 |
brlcad |
glad to see
the problem was found/fixed |
| 04:49.00 |
brlcad |
john
rocks |
| 04:52.32 |
DanielFalck |
I didn't
update the whole build last night - just dxf-g |
| 04:52.40 |
DanielFalck |
it worked for
rendering |
| 04:54.18 |
DanielFalck |
has there
been any motion on the g-stl tesselation bug having to do with
revolved entities? I suppose I should read through the source to
check. |
| 05:07.43 |
brlcad |
shouldn't
have needed to update everything |
| 05:07.57 |
CIA-4 |
BRL-CAD:
03brlcad * r33564 10/brlcad/trunk/NEWS: |
| 05:07.57 |
CIA-4 |
BRL-CAD: bob
changed the mged 'inside' command so that it'll no longer use the
geometry |
| 05:07.57 |
CIA-4 |
BRL-CAD:
being edited as the outside solid. this removes functionality but
helps make |
| 05:07.57 |
CIA-4 |
BRL-CAD: mged
stateless in the process (and was part of libged refactoring).
reworded to |
| 05:07.57 |
CIA-4 |
BRL-CAD: fit
to a one-liner. |
| 05:13.30 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 05:14.29 |
CIA-4 |
BRL-CAD:
03brlcad * r33565 10/brlcad/trunk/NEWS: |
| 05:14.29 |
CIA-4 |
BRL-CAD: john
fixed a neat lil bug in dxf-g where it was creating double-edge
sketch |
| 05:14.29 |
CIA-4 |
BRL-CAD:
objects when converting each wire edge. this fixes sf bug 2457527
(rendering |
| 05:14.29 |
CIA-4 |
BRL-CAD: bug
in revolved solid) by Dan Falck (ddfalck2002) where those same
sketches |
| 05:14.29 |
CIA-4 |
BRL-CAD:
failed to render as a solid of revolution. |
| 05:17.40 |
brlcad |
DanielFalck:
that's not so much a bug as tess support just hasn't been
implemented for revolves yet because they're so new |
| 05:18.03 |
DanielFalck |
yes, sorry
you are right |
| 05:18.08 |
DanielFalck |
wrong
term |
| 05:18.11 |
brlcad |
rather, there
was a bug where it crashes.. that was fixed, I believe .. but it
still won't tessellate until someone writes that code
;) |
| 05:18.38 |
DanielFalck |
would it help
move things along if I put in a request on sourceforge? |
| 05:19.31 |
brlcad |
couldn't
hurt |
| 05:19.43 |
DanielFalck |
ok, will do
it. thanks |
| 05:19.43 |
brlcad |
but would
probably be more effective to just keep asking pacman87 about
it |
| 05:19.48 |
brlcad |
~seen
packman87 |
| 05:19.49 |
ibot |
brlcad: i
haven't seen 'packman87' |
| 05:19.53 |
brlcad |
~seen
pacman87 |
| 05:19.53 |
ibot |
pacman87
<n=Timothy@pool-71-170-39-105.dllstx.fios.verizon.net> was
last seen on IRC in channel #bzflag, 14d 5h 17m 40s ago, saying:
'also, if you're planning on adding that info to the windows
readme, the link there is broken, too'. |
| 05:20.19 |
brlcad |
hm, looks
like winter vacation isn't over yet |
| 05:22.33 |
DanielFalck |
oh, whoops I
already reported it in December. |
| 05:22.43 |
DanielFalck |
Priority
6 |
| 05:22.47 |
brlcad |
ah, my
bad |
| 05:23.13 |
DanielFalck |
I've been
testing a lot of stuff lately. so many projects.... |
| 05:23.53 |
DanielFalck |
emc,
aptsketch, freecad, varkon, heekscad/cnc etc... |
| 05:24.35 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 05:25.37 |
CIA-4 |
BRL-CAD:
03brlcad * r33566
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c:
ws |
| 05:29.46 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 05:32.14 |
DanielFalck |
brlcad:
thanks |
| 05:53.26 |
brlcad |
DanielFalck:
hrm, well thank you for your patience too... so much to do, so
little time |
| 05:54.04 |
brlcad |
a lot of the
attention of late has been going into either simple maintenance or
into the long-term priority efforts |
| 06:09.00 |
louipc |
DanielFalck:
what would you say is the best for cad/cam on linux? |
| 06:15.44 |
CIA-4 |
BRL-CAD:
03brlcad * r33567 10/brlcad/trunk/ (doc/deprecation.txt
include/raytrace.h src/librt/db_io.c): db_free_external was
deprecated before 7.0, source recommends calling bu_free_external
instead. |
| 07:38.01 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:01.18 |
*** join/#brlcad madant
(n=madant@117.196.144.246) |
| 09:52.24 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-239-8.dclient.hispeed.ch) |
| 10:31.11 |
*** join/#brlcad mafm
(n=mafm@30.Red-88-23-76.staticIP.rima-tde.net) |
| 11:38.59 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
| 11:44.17 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-91-240.dclient.hispeed.ch) |
| 12:10.18 |
d-lo |
mornin
all |
| 13:00.36 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:16.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-131.sbndin.btas.verizon.net) |
| 14:25.41 |
brlcad |
morning
d-lo |
| 14:26.28 |
d-lo |
howdy
howdy. |
| 14:26.56 |
d-lo |
how did you
weekend go? |
| 14:27.05 |
d-lo |
s/you/your |
| 14:27.49 |
brlcad |
good and
bad |
| 14:28.11 |
d-lo |
well thats
good and sorry to hear that. |
| 14:29.33 |
d-lo |
did you get
to play in the snow at all? |
| 14:33.50 |
brlcad |
nope, but had
a nice party, did some shopping, did some work on the house, got
some code done |
| 14:40.44 |
d-lo |
house warming
party or 'just because' party ? |
| 14:48.47 |
brlcad |
playoff
party |
| 14:50.57 |
brlcad |
installing a
new electrical outlet behind the TV was probably the most
interesting 'challenge'.. that lil job took hours (mostly fishing
finding ways to fish the power up through the wall |
| 14:51.35 |
brlcad |
but it's in
place now, no mistakes, no sparks, a thing of beauty |
| 14:52.01 |
d-lo |
yeah, running
'old work' wires through a house is really rough unless you have
one of those 'ulstrasonic interference finder' devices and a 200'
phish reel :/ |
| 14:53.00 |
brlcad |
I had a phish
reel and a stud/power finder |
| 14:54.14 |
d-lo |
I had a
friend down in white marsh that showed me a 'ultrasonic' device...
shows everything behinds the wall...kinda like a fish finder. it
was waaaaaay cool. trumped my B&D stud/power finder hands down
:( |
| 14:54.18 |
brlcad |
the reel
helped a little bit, but I still had to drill 2.5" hole halfway to
try and feed |
| 14:54.40 |
brlcad |
ah one of
those, yeah |
| 14:54.57 |
d-lo |
heh, just rip
down all the drywall, install conduit, wire and redrywall
:) |
| 14:55.02 |
brlcad |
I almost
splurged for one of those lighted cameras that display to an
lcd |
| 14:55.29 |
d-lo |
oooh, those
pseudo-spy camera things? neat! |
| 14:56.17 |
brlcad |
this is the
wall with the big tv, so the drywall is staying up there for quite
a while :) |
| 14:57.07 |
d-lo |
good deal.
|
| 14:57.31 |
d-lo |
Are you
planning on running cat throughout the house? I can't remember if
you are a wireless hater or not... |
| 14:58.20 |
brlcad |
one of these:
http://tiny.cc/M0301 |
| 14:58.47 |
brlcad |
i'm not a
hater, but I do like a wired line running to my main
server |
| 14:58.48 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-109.sbndin.btas.verizon.net) |
| 14:59.26 |
d-lo |
What Do
Customers Ultimately Buy After Viewing This Item? 88% buy 'SWAT
team costume with realistic FireArms' |
| 14:59.29 |
brlcad |
which is
upstairs, so I do have to run some cat6 quite a ways |
| 14:59.57 |
brlcad |
heh, yours
says that? |
| 15:00.04 |
brlcad |
mine says 78%
buy that item |
| 15:00.14 |
d-lo |
is looking for a way to centralize all the cat6 in the vent
shaft... might take some work :/ |
| 15:00.23 |
d-lo |
no, I just
thought it would be cool if it did say that :) |
| 15:01.00 |
brlcad |
ah,
heh |
| 15:09.57 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 15:20.22 |
``Erik |
"now with
free fbi dossier" heh |
| 15:20.41 |
d-lo |
``Erik: how
ya feeling? |
| 15:20.49 |
``Erik |
tired and
old |
| 15:21.22 |
``Erik |
I mostly
didn't want to shovel the road out to where they bothered
plowing |
| 15:21.35 |
d-lo |
well, there
is some 'good' that can come from an extra day at home: more wow
time ;) |
| 15:21.38 |
``Erik |
private
community roads suck when snow's around |
| 15:21.47 |
``Erik |
nah, been
cleaning and throwing cold weather gear in my car |
| 15:21.55 |
``Erik |
and paying
bills |
| 15:22.08 |
d-lo |
I know. They
plowed my roads at 3 am..... bastards... |
| 15:22.52 |
``Erik |
I can see
where they plowed.. way out there... but I'd have to shovel more
road than driveway to get there |
| 15:22.53 |
``Erik |
:/ |
| 15:23.27 |
``Erik |
and I can't
find my gloves and hat, so I don't wanna be outside :D |
| 15:24.11 |
d-lo |
just thought of a new 'roomba'..... gas fired
SnowThrowerOomba! |
| 15:25.41 |
``Erik |
heh |
| 15:25.46 |
``Erik |
dave, are you
playing on fenix? |
| 15:26.01 |
d-lo |
nah... barely
playing on Epsi. |
| 15:26.09 |
``Erik |
there's a
claymore in fenix fate |
| 15:26.19 |
d-lo |
got sucked
back int a Civ4 addiction. |
| 15:26.24 |
d-lo |
orly? |
| 15:26.33 |
d-lo |
did they copy
my profile? |
| 15:26.49 |
``Erik |
http://fenix.astroempires.com/profile.aspx?player=11127 |
| 15:27.01 |
``Erik |
no, but same
name and guild |
| 15:27.16 |
d-lo |
heh, I think
there is an Anime with the name Claymore |
| 15:27.31 |
d-lo |
just bombard
him with 'POSER!!!!!' private messages for me, k? |
| 15:27.43 |
``Erik |
ah, heh :D
saw the name and the familiar "OMG he's got a" title :D |
| 15:27.50 |
``Erik |
hrm, I'm not
in fate, so I d'no if I wanna stir things up like that |
| 15:28.23 |
``Erik |
<--
sometimes knows when to shut his mouth... on rare occasion...
:D |
| 15:28.29 |
d-lo |
lol |
| 15:28.48 |
d-lo |
well its nice
to know that I have a 'cool' internet handle :D |
| 15:29.00 |
``Erik |
oh, brlcad, I
stuck richard as contact and cliff as alt for in-house
distribution, the s2 guys should be handling most of it for
us |
| 15:29.04 |
d-lo |
should charge royalties......hrm..... |
| 15:29.17 |
``Erik |
I think there
may be prior art |
| 15:30.39 |
``Erik |
(though
"fire" was patented a few years ago... mebbe you could pull it
off!) |
| 15:31.22 |
d-lo |
its my ticked
to being a millionare! No wait.... |
| 15:32.21 |
``Erik |
closes down gnucash |
| 15:32.34 |
``Erik |
w00t, I'm a
hundredaire! |
| 15:33.46 |
d-lo |
we need to
start a l33t hundredaire club. |
| 16:13.06 |
*** join/#brlcad docelic_
(n=docelic@78.134.199.34) |
| 16:24.05 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-53-82-65-37-12.adsl.proxad.net) |
| 16:33.02 |
Dr_Phreakenstein |
brlcad:
thanks a lot. now i have to buy one, too. recently got my first
milwaukee corded drill, and now i know why people kill eachother
over those things. |
| 16:34.29 |
bjork_ |
i use a
ridgid. |
| 16:34.36 |
bjork_ |
the damned
batteries are fried ... |
| 16:34.41 |
Dr_Phreakenstein |
nice |
| 16:34.53 |
bjork_ |
but the 18V
li-ion ... very powerful |
| 16:34.57 |
bjork_ |
and
relatively light weight. |
| 16:35.09 |
Dr_Phreakenstein |
milwaukee
uses genuine panasonic batteries, as does bosch |
| 16:35.23 |
Dr_Phreakenstein |
those are the
only 2 choices, in my book |
| 16:35.28 |
bjork_ |
i can drill
holes with 5/16th screws into 1/4 inch thick steel sheets with
it. |
| 16:35.33 |
Dr_Phreakenstein |
even so,
corded is the way for me |
| 16:35.49 |
Dr_Phreakenstein |
yes, but how
many? |
| 16:35.59 |
bjork_ |
1 per hole,
usually. |
| 16:36.07 |
bjork_ |
that's when i
don't have a drill bit handy. |
| 16:36.11 |
Dr_Phreakenstein |
per
battery? |
| 16:36.15 |
bjork_ |
oh
no. |
| 16:36.23 |
bjork_ |
the battery
lasts several holes. |
| 16:36.44 |
bjork_ |
i think
something in the circuitry is gone bye-bye and so i have to have
those replaced. |
| 16:37.06 |
Dr_Phreakenstein |
i have a lot
of extension cords, so i just skip the battery
altogether. |
| 16:37.28 |
bjork_ |
i hardly ever
use chorded drills unless i'm drilling into an I-beam or
something. |
| 16:37.41 |
Dr_Phreakenstein |
which I
do |
| 16:37.49 |
bjork_ |
oh
alright. |
| 16:37.53 |
bjork_ |
what for? the
heck of it? |
| 16:38.14 |
Dr_Phreakenstein |
no, building
my machine shop |
| 16:38.47 |
bjork_ |
cooooooool! |
| 16:39.36 |
Dr_Phreakenstein |
i even insist
on keyed chucks. keyless does not grip well enough on a 1/2" TiN
drill bit through 1" mild steel |
| 16:39.51 |
bjork_ |
so you
already have the machines for the shop? |
| 16:40.32 |
Dr_Phreakenstein |
going to
auction thursday |
| 16:40.37 |
bjork_ |
really
nice. |
| 16:40.40 |
Dr_Phreakenstein |
toes
crossed |
| 16:40.46 |
bjork_ |
but what do
you need one for? |
| 16:40.48 |
louipc |
1/2 drill is
a bit big for keyless isn't it? |
| 16:41.14 |
``Erik |
likes his makita |
| 16:41.30 |
Dr_Phreakenstein |
yes, they do
not hold stil. even cheap keyed chucks do not suffice |
| 16:41.49 |
louipc |
oh you're
talking about hand drills? |
| 16:41.51 |
Dr_Phreakenstein |
makita is my
3rd choice |
| 16:41.56 |
Dr_Phreakenstein |
yes |
| 16:42.10 |
louipc |
I guess it
still applies |
| 16:42.21 |
bjork_ |
it's ridgid,
hilti for #2, and bosch #3 |
| 16:42.30 |
bjork_ |
hilti's are
not too cheap though. |
| 16:43.06 |
Dr_Phreakenstein |
now, i like
the ridgid model 535 pipe machine, and i have one of their plumbing
snakes nice |
| 16:43.50 |
bjork_ |
what do you
need a machine shop for, Dr_Phreakenstein? |
| 16:44.20 |
Dr_Phreakenstein |
making
money |
| 16:45.26 |
bjork_ |
are you a
machinist? |
| 16:45.30 |
Dr_Phreakenstein |
I am taking
classes now to become a machinist, but since i was in the army, i
decided that i have worked for my last employer |
| 16:45.31 |
louipc |
my machine
shop made chips but no money :( |
| 16:45.41 |
Dr_Phreakenstein |
bummer |
| 16:46.04 |
bjork_ |
custom parts
and what not ? |
| 16:46.35 |
louipc |
you need CNC
to make money nowadays |
| 16:47.01 |
``Erik |
meh, I can't
spend too much money on tools, I'm using craftsman instead of
snapon for hand tools :D |
| 16:47.03 |
archivist |
for certain 1
offs non cnc is faster |
| 16:47.30 |
bjork_ |
``Erik,
craftsman replaces your tools for free so it's still a good
choice. |
| 16:47.55 |
louipc |
money isn't
really made on one-offs though |
| 16:48.09 |
louipc |
so you still
need CNC to make money ;) |
| 16:48.15 |
bjork_ |
but if you're
doing batch work, you'll be competing with the chinese. |
| 16:48.16 |
archivist |
canbe, I do 1
off gears, but on cnc |
| 16:49.02 |
louipc |
yeah and the
chinese have shiny new tools |
| 16:49.08 |
``Erik |
scratches his head and tries to figure out why there's some
christian prayer going on during the inaguration |
| 16:49.47 |
Dr_Phreakenstein |
yeah, one of
the machines for sale (actually they have 17) is cnc |
| 16:50.36 |
archivist |
I need 5 axix
to cut my setup time down |
| 16:50.44 |
Dr_Phreakenstein |
Dr_Phreakenstein scratches his head and
tries to figure out why Erik is watching the
inaguration |
| 16:50.55 |
Dr_Phreakenstein |
well, i gotta
start somewhere |
| 16:50.59 |
louipc |
get a lathe
with bar feed, part catcher, then you can pump out
parts. |
| 16:51.21 |
Dr_Phreakenstein |
:) |
| 16:51.23 |
``Erik |
the un-bush,
and the first black president of the us *shrug* at least I'm
watching the bbc feed instead of fox :D |
| 16:51.43 |
archivist |
in BBC land not watching :) |
| 16:51.56 |
Dr_Phreakenstein |
good for you,
both |
| 16:52.17 |
louipc |
I'll check
that out on the tele |
| 16:52.24 |
louipc |
how long is
it supposed to go on for? |
| 16:52.46 |
``Erik |
'bbc america'
is regional and lame, though :( when I was in memphis, they showed
tons of comedy like abfab, monty python, black adder, etc... here
it's all stupid semi-reality show crap about dirty houses and
shit |
| 16:53.03 |
archivist |
I want bar
fed cnc sliding head lathe, I my scrounge a freebee and add cnc to
it |
| 16:53.05 |
bjork_ |
he's NOT
black! |
| 16:53.08 |
bjork_ |
geezus
bleeding christ! |
| 16:53.51 |
Dr_Phreakenstein |
well, i hate
to leave this, but gotta go to class and make chips! |
| 16:53.55 |
louipc |
well he's
close enough for people to make a frenzy out of it |
| 16:54.06 |
bjork_ |
he's the
first mixed president, that's for sure. |
| 16:54.18 |
bjork_ |
he's neither
black nor white. |
| 16:54.32 |
``Erik |
most of the
US considers him black, though *shrug* imagine it goes back to that
"one drop" mentality :/ |
| 16:55.11 |
bjork_ |
stupidity on
display for the whole world to see. |
| 16:55.39 |
bjork_ |
i thought
they called slick willie the first black president too at one
point. |
| 16:57.18 |
``Erik |
I thought
that was due to childhood background, not ethnicity |
| 16:58.01 |
bjork_ |
i have no
idea. |
| 16:58.18 |
bjork_ |
so if obama's
dad had been latino, he'd be the first latino
president? |
| 16:58.25 |
bjork_ |
instead of
the first mullato? |
| 16:59.37 |
``Erik |
if you wanna
go down that slippery slope, we're all africans |
| 17:00.16 |
brlcad |
``Erik: I saw
the note, looked good (and they were better to be
listed) |
| 17:00.33 |
bjork_ |
hahaha |
| 17:00.39 |
``Erik |
but general
perception of the populace is that he is black, *shrug* so it's a
fairly important paradigm change :) |
| 17:01.21 |
``Erik |
aight,
brlcad, I got a call from the bc just before the meeting, so I had
no clue what I was walking in to and what I could/should commit us
to |
| 17:01.29 |
bjork_ |
i still think
it's unfair. the world is simply not strictly binary. |
| 17:02.07 |
``Erik |
ok, mebbe
it's better to look at what he is not than what he is... he's not
an old white guy |
| 17:02.55 |
``Erik |
hopefully
it's a sign that bigotry and prejudice and racism are dying
out |
| 17:05.04 |
bjork_ |
hahaha |
| 17:05.28 |
bjork_ |
as long as
humans remain, it'll be a primary element of social
behavior. |
| 17:05.43 |
bjork_ |
overtly it no
longer is that bad. |
| 17:05.50 |
bjork_ |
but people'll
find ways and means. |
| 17:06.23 |
bjork_ |
s.a. suffered
from the arpatheid regime for so long. black s.a-cans gained
power... |
| 17:06.45 |
bjork_ |
and what do
they do to the zimbabwe refugees, who are just like them? they
murder them and beat them up. |
| 17:06.47 |
``Erik |
oh, there'll
be some way we break outselves out into smaller tribes, but mebbe
it'll shift to merit instead of heredity |
| 17:06.55 |
bjork_ |
yeah. |
| 17:43.39 |
*** join/#brlcad b0ef
(n=b0ef@95.34.57.61.customer.cdi.no) |
| 17:49.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-109.sbndin.btas.verizon.net) |
| 18:24.39 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:36.20 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 20:10.30 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 20:10.47 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 20:10.47 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 20:12.50 |
brlcad |
hah, go
me |
| 20:13.38 |
brlcad |
nice simple
call for temporarily suspending a signal yet still delivering a
raised signal if one is received while suspended once it's
resumed |
| 20:22.36 |
``Erik |
eh? |
| 20:29.28 |
brlcad |
dilute
engrish in the excitement of it working |
| 20:42.01 |
CIA-4 |
BRL-CAD:
03brlcad * r33568 10/brlcad/trunk/ (6 files in 4 dirs): |
| 20:42.01 |
CIA-4 |
BRL-CAD: Add
new routines to libbu for temporarily suspending signal handling
via a new |
| 20:42.01 |
CIA-4 |
BRL-CAD:
bu_suspend_signal() and bu_restore_signal() interface. the previous
handler is |
| 20:42.01 |
CIA-4 |
BRL-CAD:
stashed and later restored. if that signal is received while
suspended, the |
| 20:42.01 |
CIA-4 |
BRL-CAD:
handler is called once restored. this can be useful for protecting
critical |
| 20:42.04 |
CIA-4 |
BRL-CAD:
sections. |
| 20:44.23 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 21:16.45 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 21:17.20 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-241-173.dclient.hispeed.ch) |
| 21:45.30 |
CIA-4 |
BRL-CAD:
03brlcad * r33569 10/brlcad/trunk/ (include/bu.h
src/libbu/signal.c): prevent suspending the same signal multiple
times (and clobbering the original handler). |
| 22:07.12 |
CIA-4 |
BRL-CAD:
03brlcad * r33570 10/brlcad/trunk/src/libbu/signal.c: hm, the logic
with just one counter means the restore will not raise pending
signals unless there are no other suspended signals. make them
per-signal. |
| 22:15.25 |
CIA-4 |
BRL-CAD:
03brlcad * r33571 10/brlcad/trunk/src/librt/db_io.c: protect all
database writes from being interrupted by a signal, use the new bu
routines for suspending a signal handler. |
| 22:20.56 |
CIA-4 |
BRL-CAD:
03brlcad * r33572 10/brlcad/trunk/src/libged/ (inside.c
typein.c): |
| 22:20.56 |
CIA-4 |
BRL-CAD:
should no longer need the signal handler protections this high up
in the API |
| 22:20.57 |
CIA-4 |
BRL-CAD:
since there are protections at the lower-level db_write().
db_diradd() might |
| 22:20.57 |
CIA-4 |
BRL-CAD: also
need bu_suspend_signal() proections but since it's all in-memory,
it |
| 22:20.57 |
CIA-4 |
BRL-CAD:
souldn't matter if it gets a signal that interrupts. |
| 23:39.15 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 00:00.17 |
``Erik |
yes, we know
what rt looks like O.o it's in SVN |
| 00:00.28 |
IriX64 |
sure is
:) |
| 00:01.16 |
IriX64 |
thank God he
said "clipboard" and not 9mm :) |
| 00:03.07 |
``Erik |
only punkass
"gansta" wannabes carry 9's anymore, a .40 or 10mm is where it's
at, yo |
| 00:03.10 |
``Erik |
:D |
| 00:04.33 |
IriX64 |
http://rafb.net/p/T7SLwE60.html
<--- this is where i learn from mostly ;) |
| 00:05.28 |
IriX64 |
after all the
code *is the documentation |
| 00:07.18 |
``Erik |
bu.h would be
a good commented index of all that crap (and we know what src/libbu
looks like) |
| 00:07.53 |
IriX64 |
thanks, i
look at a lot of stuff, like the style you guys have |
| 00:08.00 |
IriX64 |
its
consistent |
| 00:08.53 |
IriX64 |
if i try a
diff to my brlcad2 svn thing, do the old diffs stay? |
| 00:11.18 |
IriX64 |
remebering of
course "my system is strange" :) |
| 00:15.40 |
IriX64 |
remeber when
i started with 7.6.2? i still can say i've never had so much fun
:) |
| 00:17.44 |
IriX64 |
he, all
because i wanted to test automake on a makefile.am :) |
| 00:17.49 |
IriX64 |
heh
even |
| 00:25.18 |
CIA-5 |
BRL-CAD:
03brlcad * r33577 10/brlcad/trunk/ (TODO include/bu.h): |
| 00:25.18 |
CIA-5 |
BRL-CAD: bitv
shifting is now 'optimized' as in no longer calculated at run-time.
since |
| 00:25.18 |
CIA-5 |
BRL-CAD:
bitv_t doesn't change at compile time and works equally well for
large bit |
| 00:25.18 |
CIA-5 |
BRL-CAD:
vectors (actually a little faster if 'long' is a signficantly
faster integer |
| 00:25.18 |
CIA-5 |
BRL-CAD: type
than 'long long' even on a 64-bit platform). that makes us ready
to |
| 00:25.21 |
CIA-5 |
BRL-CAD:
release if testing goes well. still need a mega-mged test script to
make sure |
| 00:25.23 |
CIA-5 |
BRL-CAD:
libged integration is good. |
| 00:27.26 |
CIA-5 |
BRL-CAD:
03brlcad * r33578 10/brlcad/trunk/TODO: given the libged
integration, we do need to write mged test script to exhaustively
exercise all commands before doing a release. |
| 00:29.56 |
``Erik |
"svn diff
> version.patch" and then manually review it |
| 00:31.54 |
IriX64 |
thanks
man |
| 00:33.53 |
CIA-5 |
BRL-CAD:
03brlcad * r33579 10/brlcad/trunk/BUGS: |
| 00:33.53 |
CIA-5 |
BRL-CAD:
victor provided a reproducible case where xpush blows steaming
chunks and fails |
| 00:33.53 |
CIA-5 |
BRL-CAD:
miserably to do its job leaving the db in a destroyed state. looks
like it is |
| 00:33.53 |
CIA-5 |
BRL-CAD:
stopping halfway through the task but gives no indication that
anything goes |
| 00:33.54 |
CIA-5 |
BRL-CAD:
wrong. |
| 00:35.14 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 00:38.02 |
``Erik |
neato |
| 00:40.32 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 00:46.33 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 00:58.53 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 00:58.53 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.0 is now posted (20081108) |
| 01:06.40 |
*** join/#brlcad bjork_
(n=bjork@ip72-204-40-138.fv.ks.cox.net) |
| 01:10.33 |
IriX64 |
http://www3.sympatico.com/mario.dulisse2/frame.png
:) |
| 01:20.18 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 01:23.43 |
``Erik |
grats on the
masters, twingy |
| 01:24.34 |
``Erik |
neato, more
tkhtml breakage |
| 01:26.28 |
Twingy |
I didn't get
a masters |
| 01:30.38 |
``Erik |
oh, I heard
you did |
| 01:30.53 |
``Erik |
guess the
grapevine twisted the message :) you were going for a masters at
gatech, right? |
| 01:32.12 |
Twingy |
yes, I
stopped that over a year ago |
| 01:32.20 |
``Erik |
heh |
| 01:32.22 |
Twingy |
I'm pursuing
a masters in computer engineering now |
| 01:32.42 |
``Erik |
ah,
cool |
| 01:36.39 |
mafm |
night |
| 01:47.31 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 02:08.02 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-109.sbndin.btas.verizon.net) |
| 02:57.03 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 03:53.41 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
| 04:05.43 |
yukonbob |
hello,
cadheads |
| 05:12.52 |
Dr_Phreakenstein |
hello,
yukonbob |
| 05:13.19 |
Dr_Phreakenstein |
(sorry, got
some serious lag here ;) ) |
| 05:17.09 |
brlcad |
howdy
yukonbob |
| 05:44.58 |
yukonbob |
hey
Dr_Phreakenstein |
| 05:45.04 |
yukonbob |
brlcad: long
time, no chat :) |
| 05:48.26 |
brlcad |
indeed! |
| 06:02.45 |
yukonbob |
what's
happening, my Internet friend? |
| 06:03.13 |
yukonbob |
(is
capatalizing Internet considered Bad Form these days? I think it's
passe') |
| 06:03.15 |
yukonbob |
*internet |
| 06:04.22 |
brlcad |
nah |
| 06:04.40 |
brlcad |
going pretty
good |
| 06:04.50 |
brlcad |
lot of irons
in the fire, but made some progress today |
| 06:05.33 |
yukonbob |
nice... |
| 06:05.49 |
yukonbob |
interesting
news to talk about? |
| 06:06.05 |
yukonbob |
is getting into cmake (after owning the book for almost a
year) |
| 06:06.17 |
yukonbob |
is also getting into cross compiling
(mingw) |
| 06:06.27 |
yukonbob |
...and more
hardcore Tcl... |
| 06:06.34 |
brlcad |
cool |
| 06:07.07 |
yukonbob |
...and
looking forward to getting the lastest ITcl/ITk (branded "ng")
running so he can get over this no-brl-cad drought... |
| 06:07.15 |
brlcad |
biggest news
is probably that libged is coming to completion, getting integrated
with mged now, and will soon hopefully provoke the merging of mged
and archer |
| 06:07.20 |
yukonbob |
I don't know
when the last time I had it installed was :P |
| 06:07.34 |
yukonbob |
ah, I miss
mged |
| 06:08.41 |
yukonbob |
once I
finally get it installed, I want to a) start modelling again
(speedos) b) delve into programming against librt |
| 06:09.05 |
yukonbob |
I'll be
picking your brain... |
| 06:09.54 |
yukonbob |
actually has some only-secondarily related-to-brl-cad
questions for you, but I'll collect some info and formulate good
questions before I start wasting time... |
| 06:10.31 |
brlcad |
looks forward to it |
| 06:10.37 |
yukonbob |
:) |
| 06:11.10 |
yukonbob |
you have any
news re: itcl/itk ng? I've heard that they pass all the test
suites, but I haven't tried building for quite a few
weeks... |
| 06:11.18 |
yukonbob |
what's the
tree use? |
| 06:11.21 |
brlcad |
librt is easy
.. since you're so interested in tcl, you might be more keen on
mged/archer enhancements |
| 06:11.42 |
brlcad |
I tried it
about 6-8 weeks ago |
| 06:11.46 |
brlcad |
and it failed
miserably |
| 06:11.47 |
yukonbob |
success? |
| 06:11.48 |
yukonbob |
ha |
| 06:11.50 |
yukonbob |
*ah |
| 06:11.51 |
yukonbob |
:P |
| 06:11.56 |
yukonbob |
fsck |
| 06:12.18 |
yukonbob |
itcl/itk are
still aboslutely required though, correct? |
| 06:12.19 |
brlcad |
it's changed
a fair bit since then, worth another try |
| 06:12.24 |
brlcad |
absolutely,
yes |
| 06:12.42 |
brlcad |
there's more
than 100k lines of itcl/itk code |
| 06:12.44 |
yukonbob |
ya -- test
scores have gone up, which is promising ... I monitor the wiki page
occasionally .... |
| 06:12.55 |
brlcad |
monitors the trackers |
| 06:13.01 |
yukonbob |
itcl is
certainly a blessing and a curse... |
| 06:13.09 |
yukonbob |
?trackers |
| 06:13.16 |
brlcad |
the sf
trackers |
| 06:13.19 |
yukonbob |
ah |
| 06:13.31 |
brlcad |
all bug
reports, feature requests, support requests, patches |
| 06:13.39 |
yukonbob |
ya |
| 06:13.51 |
brlcad |
easier to see
when someone is actually busy |
| 06:14.01 |
brlcad |
as opposed to
just being all talk |
| 06:14.06 |
brlcad |
on the
lists |
| 06:14.07 |
yukonbob |
true,
true. |
| 06:15.04 |
yukonbob |
goes to see latest news/details on itcl/itk, setup test
env... |
| 06:20.21 |
PrezKennedyIII |
i wish i
could go on just a couple hours of sleep like brlcad can
:( |
| 06:20.32 |
PrezKennedyIII |
waves good night |
| 06:20.39 |
brlcad |
it's easier
the more you do it |
| 06:20.55 |
brlcad |
plenty of
time to sleep when you're dead |
| 06:20.59 |
PrezKennedyIII |
ive tried...
it doesn't work for me |
| 06:21.04 |
PrezKennedyIII |
i need about
6-8 hours |
| 06:21.09 |
brlcad |
one/two time
tries don't do jack |
| 06:21.12 |
brlcad |
has to be
habitual |
| 06:21.32 |
PrezKennedyIII |
ive tried for
years and i finally gave up |
| 06:21.50 |
PrezKennedyIII |
i need at
least 6, or the day absolutely sucks |
| 06:22.09 |
brlcad |
4 is about
the minimum sustainable for most |
| 06:22.38 |
PrezKennedyIII |
besides,
youll be dead sooner if you dont get enough sleep :p |
| 06:22.42 |
PrezKennedyIII |
catch 22
;) |
| 06:22.47 |
brlcad |
nah, old
wives tale |
| 06:23.09 |
brlcad |
there've been
plenty of studies that have shown it's sustainable |
| 06:23.15 |
louipc |
depends on
what you do to your body I suppose |
| 06:23.27 |
brlcad |
it's just not
something you can jump into though |
| 06:24.05 |
brlcad |
it's like
cold weather or distance running or listening to loud
music |
| 06:24.13 |
brlcad |
your body
adjusts over time |
| 06:24.51 |
PrezKennedyIII |
and then you
can never hear the same, your knees get damaged, and you catch
pneumonia |
| 06:24.54 |
PrezKennedyIII |
:D |
| 06:24.55 |
louipc |
I did 4hrs a
night for about 2yrs... but I'd sleep everywhere... on the bus,
waiting in line, at lunch break, ... |
| 06:25.12 |
PrezKennedyIII |
gnight
all |
| 06:25.18 |
louipc |
gnite |
| 06:25.46 |
PrezKennedyIII |
oh yeah,
brlcad... my dad is trying that whole 4 hour thing and i dont think
its workin for him either |
| 06:25.55 |
PrezKennedyIII |
he falls
asleep playing games |
| 06:25.58 |
brlcad |
particularly liked the discovery episode that put a northern
indian/eskimo against someone from new england, testing their cold
weather extremes |
| 06:26.14 |
louipc |
hah |
| 06:26.24 |
brlcad |
hooked them
both up to instruments in a closed room and dropped the temperature
fast to measure their responses |
| 06:26.38 |
brlcad |
(in their
skivies only) |
| 06:26.57 |
brlcad |
pretty
interesting to see the response graphs over time |
| 06:28.13 |
brlcad |
both could
withstand some pretty substantial extreme colds before getting near
internal organ danger temps, but the eskimo was noticably
unaffected nor uncomfortable until it was near that
extreme |
| 06:29.06 |
louipc |
so he can
keep on trucking potentially to safety eh? |
| 06:29.11 |
brlcad |
the other
dude was mostly just 'miserable' and whiny much longer |
| 06:30.01 |
yukonbob |
starts itcl build attempt. |
| 06:30.03 |
brlcad |
the indian
could withstand a colder temp, but it wasn't nearly as drastic as
their first measure of asking them to say when they "felt
cold" |
| 06:30.05 |
yukonbob |
runs into first failure... |
| 06:31.02 |
brlcad |
you have to
have a recent tcl/tk too |
| 06:31.08 |
yukonbob |
8.5.6 |
| 06:31.23 |
yukonbob |
_has_ been working, quietly, in his lab here
;) |
| 06:42.49 |
yukonbob |
is stalled at this hour... |
| 06:43.08 |
yukonbob |
brlcad: if
it's agreeable to you, I've got some general questions that I'll
pose in the future... |
| 06:43.29 |
yukonbob |
more
shared-lib/libtool/auto*-fu |
| 06:44.00 |
yukonbob |
prepares to hit hay --- is not on 4h sleep sched yet
;) |
| 06:53.21 |
brlcad |
heh |
| 07:02.56 |
brlcad |
wanders off to his car for a cruise |
| 08:41.20 |
brlcad |
wanders into the darkness |
| 08:48.00 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-38-82-253-71-35.adsl.proxad.net) |
| 08:59.30 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:11.25 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 09:11.25 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 09:11.25 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 11:58.02 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:14.26 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 12:34.07 |
CIA-4 |
BRL-CAD:
03d_rossberg * r33580
10/brlcad/trunk/include/config_win.h: |
| 12:34.07 |
CIA-4 |
BRL-CAD: some
declarations for signal handling |
| 12:34.07 |
CIA-4 |
BRL-CAD:
Notice: Signals are poorly supported by MS Windows. This o.s. has
its own methods to do the job. Using signals means to target a Unix
o.s.. |
| 12:36.14 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 12:38.38 |
CIA-4 |
BRL-CAD:
03d_rossberg * r33581
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added one more
function to export |
| 13:45.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-228.sbndin.btas.verizon.net) |
| 14:20.50 |
*** join/#brlcad mafm
(n=mafm@30.Red-88-23-76.staticIP.rima-tde.net) |
| 14:20.58 |
mafm |
hi |
| 14:23.58 |
brlcad |
howdy |
| 14:34.15 |
*** join/#brlcad mafm_
(n=mafm@30.Red-88-23-76.staticIP.rima-tde.net) |
| 15:08.35 |
yukonbob |
brlcad:
speaking of 4h sleeping schedules, are you a coffee (or tea, jolt,
etc) drinker? |
| 15:15.24 |
``Erik |
coffee made
with bawls, pheer |
| 15:15.41 |
*** join/#brlcad mafm_
(n=mafm@30.Red-88-23-76.staticIP.rima-tde.net) |
| 15:57.15 |
*** join/#brlcad mafm
(n=quassel@30.Red-88-23-76.staticIP.rima-tde.net) |
| 16:03.16 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FB66.dip.t-dialin.net) |
| 16:13.57 |
*** join/#brlcad docelic_
(n=docelic@78.134.197.125) |
| 16:14.25 |
brlcad |
yukonbob: I
go through phases, but yeah sure |
| 16:15.08 |
brlcad |
usually a
couple weeks on, few weeks off, so I never get used to it (and then
it also usually does its job very well if I need it) |
| 16:22.45 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:26.04 |
*** join/#brlcad samrose
(n=samrose@99.181.171.110) |
| 17:46.06 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 17:56.45 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 18:20.00 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 18:29.03 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 18:50.15 |
*** join/#brlcad mafm
(n=quassel@30.Red-88-23-76.staticIP.rima-tde.net) |
| 19:06.48 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 19:39.16 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-239-43.dclient.hispeed.ch) |
| 19:51.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-228.sbndin.btas.verizon.net) |
| 20:21.52 |
CIA-4 |
BRL-CAD:
03erikgreenwald * r33582 10/brlcad/trunk/src/adrt/ (4 files in 2
dirs): move utilization of vmath.h |
| 20:28.06 |
*** join/#brlcad Bman
(n=erik@ftp.brlcad.org) |
| 20:45.00 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 20:50.51 |
*** join/#brlcad madant
(n=madant@117.196.136.169) |
| 20:54.36 |
CIA-4 |
BRL-CAD:
03brlcad * r33583 10/brlcad/trunk/ (4 files in 3 dirs): (log
message trimmed) |
| 20:54.36 |
CIA-4 |
BRL-CAD:
daniel makes a good point about signals on windows. instead of
making the code |
| 20:54.36 |
CIA-4 |
BRL-CAD:
specific to signals, make the api attempt to suspend interruptions
(with various |
| 20:54.36 |
CIA-4 |
BRL-CAD:
signals being one form of an interrupt). on mac and windows, this
might also |
| 20:54.36 |
CIA-4 |
BRL-CAD:
include buffering various gui events (like the close button) that
may have |
| 20:54.38 |
CIA-4 |
BRL-CAD:
independent callbacks. hide the two new bu_*_signal() routines as
an |
| 20:54.40 |
CIA-4 |
BRL-CAD:
implementation detail for now since it's not readily needed
anywhere else and |
| 20:56.41 |
CIA-4 |
BRL-CAD:
03brlcad * r33584 10/brlcad/trunk/src/libbu/signal.c: rename
prep |
| 21:00.22 |
CIA-4 |
BRL-CAD:
03brlcad * r33585 10/brlcad/trunk/ (6 files in 3 dirs): rename
signal.c to interrupt.c |
| 21:03.38 |
CIA-4 |
BRL-CAD:
03brlcad * r33586 10/brlcad/trunk/src/mged/ (chgview.c cmd.c
facedef.c rtif.c track.c utility1.c): s/interupts/interrupts/g
typo |
| 21:10.12 |
CIA-4 |
BRL-CAD:
03brlcad * r33587 10/brlcad/trunk/TODO: |
| 21:10.12 |
CIA-4 |
BRL-CAD:
should refactor mged's signal handling so that any long-running
command can be |
| 21:10.12 |
CIA-4 |
BRL-CAD:
interrupted safely. as it is, with the sig2/sig3 interrupt handler
using |
| 21:10.12 |
CIA-4 |
BRL-CAD:
longjmp's, just about any librt call might leave the dbip in a bad
state. |
| 21:13.53 |
CIA-4 |
BRL-CAD:
03erikgreenwald * r33588 10/brlcad/trunk/src/adrt/libutil/
(Makefile.am camera.c camera.h umath.c umath.h): eliminate umath
and camera |
| 21:14.15 |
CIA-4 |
BRL-CAD:
03erikgreenwald * r33589 10/brlcad/trunk/src/adrt/ (25 files in 5
dirs): use vmath where possible |
| 21:56.03 |
CIA-4 |
BRL-CAD:
03erikgreenwald * r33590 10/brlcad/trunk/ (7 files in 5 dirs): move
mersenne twister random number generator from ADRT's libutil to
libbn |
| 21:58.01 |
CIA-4 |
BRL-CAD:
03erikgreenwald * r33591 10/brlcad/trunk/ (9 files in 8 dirs):
eliminate src/adrt/libutil and src/adrt/libcommon |
| 22:06.18 |
CIA-4 |
BRL-CAD:
03erikgreenwald * r33592 10/brlcad/trunk/configure.ac:
src/adrt/libcommon is GONE, man |
| 22:13.40 |
kanzure |
I have a set
of points that represent a path that I'd like to model. These
points would be, say, used to guide a drill bit. Is there a way for
me to do this easily via BRLCAD? |
| 22:14.00 |
kanzure |
Previously I
was attempting to plot tubing using those coords, but there were
one too many things going wrong that I haven't been able to track
down. |
| 22:14.54 |
*** join/#brlcad b0ef
(n=b0ef@62.16.142.244) |
| 22:23.32 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 22:41.02 |
*** join/#brlcad mafm
(n=quassel@30.Red-88-23-76.staticIP.rima-tde.net) |
| 22:46.41 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:34.27 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-121.sbndin.btas.verizon.net) |
| 23:34.53 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 23:37.06 |
kanzure |
Hey
elite01. |
| 23:37.38 |
elite01 |
yo kanzure
:D |
| 23:37.41 |
elite01 |
waves |
| 23:37.52 |
kanzure |
waves back. |
| 23:54.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-121.sbndin.btas.verizon.net) |
| 23:57.37 |
*** join/#brlcad mafm
(n=quassel@30.Red-88-23-76.staticIP.rima-tde.net) |
| 00:42.57 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 02:12.54 |
*** join/#brlcad madant1
(n=madant@117.196.138.125) |
| 02:20.13 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-196-139.we.res.rr.com) |
| 02:37.29 |
*** join/#brlcad mafm
(n=quassel@30.Red-88-23-76.staticIP.rima-tde.net) |
| 02:41.27 |
brlcad |
kanzure: by
previously attempting to plot tubing, you mean in
brl-cad? |
| 02:41.42 |
brlcad |
I'd think
that'd be a good case for the pipe primitive |
| 02:42.14 |
brlcad |
the set of
points being a partial set of params to a given pipe |
| 02:50.02 |
kanzure |
That last
message made no sense, what ? :) |
| 02:50.06 |
kanzure |
but yes, I
did mean plot tubing in brlcad |
| 02:51.18 |
brlcad |
how did you
previously attempt |
| 02:51.33 |
brlcad |
what did you
try to do? |
| 02:51.39 |
kanzure |
<PROTECTED> |
| 02:52.06 |
kanzure |
You were
helping me out when I was figuring that out, actually. I was using
the command to point-and-click to place the next piece of
tubing |
| 02:52.27 |
brlcad |
i mean what
primitive(s) were you using? |
| 02:53.00 |
kanzure |
pipe |
| 02:53.01 |
brlcad |
you say
'tubing' but we don't have a tubing primtive, so wondering if it
was a pipe or series of cylinders or spheres, or something
else |
| 02:53.04 |
brlcad |
ah
ok |
| 02:53.07 |
kanzure |
sorry, pipe
:) |
| 02:54.29 |
brlcad |
okay, so
there's a couple things you can do |
| 02:55.13 |
brlcad |
either a)
give the pipe tutorial another go (volume III, principles of
effective modeling, on the website under docs) |
| 02:55.34 |
brlcad |
or b) try the
'pipe' command outside of mged |
| 02:55.45 |
kanzure |
in the
shell? |
| 02:56.08 |
brlcad |
or c) just
manually create a series of cylinders (rcc's would probably be
best) that use your points as start/end points |
| 02:56.29 |
brlcad |
on the
command prompt outside of mged, not mged's command
prompt |
| 02:56.49 |
brlcad |
the unix/dos
command line |
| 02:57.17 |
kanzure |
if I do the
cylinder rcc's, that would mean that each cross section would
"jolt" sort of, right? |
| 02:57.39 |
kanzure |
I'm using
this for some fluid flow simulations, by the way, so I think I'd
just have to increase the granularity or resolution of the list of
numbers for the cylinders |
| 02:58.32 |
brlcad |
there would
be a "crack" in the tubing run if you used just rcc's and it wasn't
just a straight tube |
| 02:58.47 |
brlcad |
but you could
add joints that would make a seamless bend |
| 02:58.57 |
brlcad |
e.g. just add
a sphere at that point with the same radius |
| 02:59.25 |
kanzure |
same radius
as what? I'm not calculating "bends" at the moment- I just have a
list of points from some parametric equations |
| 02:59.28 |
kanzure |
particularly
of a spiral. |
| 02:59.41 |
brlcad |
but then
that's sort of what the 'pipe' tool does too (with options to use
torii, spheres, mitre'd corners, etc) |
| 03:00.00 |
brlcad |
sphere having
the same radius as your cylinders |
| 03:00.06 |
brlcad |
whatever you
choose |
| 03:00.30 |
kanzure |
oh? Maybe
that's why I was having problems earlier. Each time I tried to plot
'pipe' with the parametric equations, it would tell me that it was
intersecting with itself and not plottable (or something- I can't
get you the specific error at the moment) |
| 03:00.44 |
kanzure |
the "oh?" was
to the mention of the options to the pipe command |
| 03:01.08 |
brlcad |
fyi, the pipe
_tool_ is not at all the same as the pipe primitive |
| 03:01.38 |
brlcad |
the tool
predated the primitive by about a decade and was the defacto way
for a long time (it still has nice interactive inputs) |
| 03:01.39 |
kanzure |
hrm. worth
investigating. The tutorial that I read in the PDF would have been
about the primitive, IIRC, right? |
| 03:01.55 |
brlcad |
the pipe
primitive is basically a subset of what the pipe tool can
do |
| 03:02.53 |
brlcad |
if the pipe
primitive was complaining about self-intersection, it was probably
bends that were too extreme (e.g. bending back on itself) or
invalid inputs |
| 03:03.06 |
kanzure |
floating
point inputs? |
| 03:03.13 |
kanzure |
erm, doubles,
basically. |
| 03:03.27 |
brlcad |
no, nothing
to do with floats/doubles |
| 03:03.56 |
brlcad |
i mean it's
asking for values and you think it means something else |
| 03:04.26 |
kanzure |
it was the
xyz "point" for the 'point' command in mged. |
| 03:04.48 |
kanzure |
so it was
something like "p 1.0 2.0 3.0" |
| 03:04.58 |
kanzure |
I can bring
up the specifics later. |
| 03:05.29 |
brlcad |
like asking
for diameter values and you feed radius values inadvertently or
setting the next pipe 'point' when you're on a bend and feeding the
wrong point |
| 03:05.54 |
kanzure |
like I said,
I'm just plotting the points from a parametric equation |
| 03:06.00 |
brlcad |
'p' is not
the 'point' command, it's just parameters .. which depend on the
currently activated edit operation |
| 03:06.01 |
kanzure |
so if I'm on
a bend, how do I account for that |
| 03:06.09 |
kanzure |
oh, sorry, it
might not have been 'p' |
| 03:06.30 |
brlcad |
you would
have used 'p' if you were selecting edit options |
| 03:06.51 |
brlcad |
it just
doesn't mean "point" :) |
| 03:07.35 |
brlcad |
the pipe
primitive doesn't just take a series of points and
spline-interpolate them |
| 03:07.43 |
kanzure |
aha, here we
go |
| 03:07.44 |
brlcad |
the tutorial
is really necessary for understanding its inputs |
| 03:07.52 |
kanzure |
http://heybryan.org/bioreactor/membraneless_filtration/spiral_generator.pl |
| 03:08.03 |
kanzure |
hope you can
read perl - if not, check near the bottom to see the mged
command. |
| 03:08.21 |
kanzure |
nope, sorry,
wrong one. I was just doing rpp's. |
| 03:08.48 |
brlcad |
yeah, I was
gonna say :) |
| 03:08.56 |
kanzure |
those are
some funny pipes huh? :) |
| 03:09.01 |
brlcad |
:) |
| 03:10.39 |
brlcad |
mm.. that's
one insanely slow download rate |
| 03:10.51 |
kanzure |
how slow am I
at? |
| 03:11.00 |
kanzure |
I'm paying
for an 8 MB/sec line. |
| 03:13.30 |
brlcad |
<PROTECTED> |
| 03:13.30 |
brlcad |
<PROTECTED> |
| 03:13.30 |
brlcad |
100 292k
100 292k 0 0 12815 0 0:00:23 0:00:23 --:--:--
17608 |
| 03:14.05 |
kanzure |
speed is in
kbps? |
| 03:14.19 |
brlcad |
12.5KB/sec |
| 03:14.30 |
brlcad |
a hair shy of
8MB/sec |
| 03:14.37 |
kanzure |
huh.
well. |
| 03:15.19 |
brlcad |
maybe others
are hitting up the pipe |
| 03:15.29 |
kanzure |
tails the apache log |
| 03:15.41 |
brlcad |
there, that's
a little better, about 40KB/sec now |
| 03:16.13 |
brlcad |
neat,
http://heybryan.org/bioreactor/membraneless_filtration/2008-12-16_spiral_generator_works.png |
| 03:16.46 |
kanzure |
turns out
that the cross-sections are facing the wrong way on some parts of
the spiral |
| 03:16.48 |
brlcad |
with that
many points, you certainly should be able to create a corresponding
pipe with the right inputs |
| 03:17.14 |
brlcad |
the only
issue I can see arising would be having a radius be larger than the
spacing between the "points" |
| 03:17.16 |
kanzure |
they are
rectangular cross-sections, so on one side of the spiral you might
see something like the 'window' facing inwards, as seen in the
other shots |
| 03:17.25 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 03:17.49 |
kanzure |
(instead of
facing the right way, which I guess would be defined as the tangent
at that point?) |
| 03:19.00 |
brlcad |
yeah, I saw
them |
| 03:19.42 |
brlcad |
would make a
great dominos demo |
| 03:20.40 |
madant1 |
loves spiral of dominos |
| 03:20.59 |
kanzure |
good analogy.
Google 3D Warehouse has a 3D spiral of dominoes .. hm, not
algorithmically generated though |
| 03:21.14 |
*** join/#brlcad kanzure3
(i=bryan@66.112.232.233) |
| 03:21.16 |
kanzure3 |
http://sketchup.google.com/3dwarehouse/details?mid=8c93df389a7d4a057a734abc5ba1db0f |
| 03:22.07 |
brlcad |
must enfeed |
| 03:22.13 |
brlcad |
tacos! |
| 03:22.17 |
brlcad |
bbl |
| 03:31.08 |
yukonbob |
hello,
cadheads |
| 05:05.22 |
kanzure |
brlcad: Hey,
so about that spiral_generator.pl file. The oed command didn't work
in there anyway, it was supposed to rotate the rpp, but it never
did work. Any hints? |
| 05:08.35 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 05:25.17 |
brlcad |
kanzure: hm.
well, you don't have a rotate command in there |
| 05:25.20 |
brlcad |
only a
translate |
| 05:25.58 |
brlcad |
and the
leading / on cross_section_region is unnecessary, but don't see a
problem off hand |
| 05:26.01 |
kanzure |
if I
s/translate/rotate/ will that work? |
| 05:27.11 |
brlcad |
s/translate/rotobj/, sure |
| 05:28.13 |
kanzure |
oops,
wait |
| 05:28.14 |
brlcad |
note that
rotations are the reason the left-hand side must lead down to a
primitive -- it uses the primitive as the rotation keypoint by
default |
| 05:28.18 |
kanzure |
the
'translate' shouldn't matter |
| 05:28.25 |
kanzure |
it should be
s/orot/rotobj/ |
| 05:28.50 |
kanzure |
right? |
| 05:29.14 |
brlcad |
orot and
rotobj are effectively the same |
| 05:29.20 |
kanzure |
doesn't do
its job then :( |
| 05:29.30 |
brlcad |
rotobj -i
will work incrementally, otherwise both are absolute
iirc |
| 05:30.39 |
brlcad |
it also works
with degrees and not radians |
| 05:31.36 |
brlcad |
seems to work
just fine here, is it not rotating at all or just not in the manner
you expect? |
| 05:31.46 |
kanzure |
not at
all |
| 05:32.08 |
kanzure |
lemme see if
I can't just use a random value for radians and see how that
looks |
| 05:36.25 |
brlcad |
can you paste
that semi-separated line with values so I can test it
here? |
| 05:37.00 |
kanzure3 |
<PROTECTED> |
| 05:37.07 |
brlcad |
object
rotations is one of the staple commands that is run in production
hundreds of times a week in-house, so I really suspect it's just
bad input |
| 05:37.48 |
kanzure |
That's with
$degrees=int(rand(10))*PI; |
| 05:38.19 |
kanzure |
though I
don't know why now that I think about it. |
| 05:38.57 |
CIA-4 |
BRL-CAD:
03brlcad * r33593 10/brlcad/trunk/TODO: need to deprecate one of
the object rotation commands |
| 05:43.51 |
brlcad |
hm, that
example works just fine here: http://paste.bzflag.bz/m50be6677 |
| 05:44.15 |
brlcad |
(just used
rpp and rpp2 instead of mflb2_524.s and caboff1_524.s) |
| 05:45.23 |
brlcad |
an unrelated
hint, if all you have is a primitive, you can just run "sed
primitive" to go into edit mode on a given primitive instead of
specifying the two paths |
| 05:45.49 |
brlcad |
it's when you
got to cross_section_region_524.c that you need oed since it's a
combination instead of a primitive |
| 05:47.38 |
kanzure3 |
originally I
was using g-stl -o keep.g.stl spiral.g
cross_section_region_{0..999}.r |
| 05:47.44 |
kanzure3 |
to generate
an stl file for an STL viewer that I use |
| 05:47.53 |
kanzure3 |
but it seems
it doesn't like my cross_section_region_$i objects any
more |
| 05:48.07 |
kanzure3 |
ah, it's .c
:) |
| 05:50.44 |
kanzure3 |
http://heybryan.org/bioreactor/membraneless_filtration/2009-01-22.png
<- so this is with the random values. That's one side of the
spiral. The holes should be aligned .. not the way that they
are. |
| 06:42.59 |
*** join/#brlcad cad02
(n=3c32aae7@bz.bzflag.bz) |
| 06:43.08 |
cad02 |
hi |
| 07:20.58 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 07:20.58 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.0 is now posted (20081108) |
| 08:30.01 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 08:30.01 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.0 is now posted (20081108) |
| 08:36.10 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:00.12 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 09:00.12 |
*** join/#brlcad kanzure3 (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad b0ef (n=b0ef@62.16.142.244) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad smurfette
(n=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 09:00.12 |
*** join/#brlcad kanzure (i=bbishop@66.112.232.117) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 09:00.12 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 09:00.12 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 09:00.13 |
*** mode/#brlcad [+o brlcad] by
irc.freenode.net |
| 09:00.14 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:01.42 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-59-82-252-154-167.adsl.proxad.net) |
| 09:02.52 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 09:07.02 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:08.01 |
*** join/#brlcad mafm
(n=quassel@30.Red-88-23-76.staticIP.rima-tde.net) |
| 13:17.31 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:22.59 |
brlcad |
kanzure:
there is some sort of randomness there |
| 13:23.09 |
brlcad |
but I see
what you mean |
| 13:23.22 |
brlcad |
orot is
working, though -- just means that the values aren't
right |
| 13:24.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-121.sbndin.btas.verizon.net) |
| 13:24.33 |
brlcad |
as I
mentioned, the two most common mistakes are providing radians
instead of degrees and assuming a global rotation
keypoint |
| 13:26.24 |
brlcad |
my guess
would be the latter in this case, it's using one of the vertices on
the arb8 as the rotation keypoint, which is very likely not what
you would expect -- you either need to compute the center-point on
the .c and run 'keypoint' first or set the global 0,0,0 origin as a
keypoint or try incremental rotations |
| 13:35.03 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-121.sbndin.btas.verizon.net) |
| 13:42.39 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:23.33 |
``Erik |
EVERYBODY
DANCE! |
| 14:23.52 |
d-lo |
Disco Disco
Good Good |
| 14:27.36 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F3EB.dip.t-dialin.net) |
| 14:33.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-121.sbndin.btas.verizon.net) |
| 14:40.37 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:49.28 |
*** join/#brlcad samrose
(n=samrose@99.147.180.206) |
| 15:30.35 |
*** join/#brlcad ``Erik
(n=erik@ftp.brlcad.org) |
| 15:31.47 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 15:38.11 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 15:47.37 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 16:09.05 |
*** kick/#brlcad [CIA-4!n=sean@bz.bzflag.bz] by brlcad
(brlcad) |
| 16:09.24 |
brlcad |
oops |
| 16:09.35 |
brlcad |
forgot the /me |
| 16:14.21 |
*** join/#brlcad docelic__
(n=docelic@78.134.204.208) |
| 16:17.08 |
``Erik |
bot abuse!
I'm calling petr! |
| 16:17.31 |
``Erik |
gas leaks in
the building are fun. wee. |
| 16:26.19 |
d-lo |
brlcad: do
you know who stole my chair? |
| 16:32.03 |
brlcad |
oops! |
| 16:32.08 |
brlcad |
d-lo: it's in
the server room |
| 16:32.26 |
d-lo |
ah, okay. As
long as its not on its way to Canada or Mexico ;) |
| 16:32.56 |
brlcad |
needed a
"high" chair for a late night server session, it was the
highest |
| 16:34.12 |
d-lo |
sighs. nice to have the ol chair back ;) |
| 16:45.46 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 17:23.13 |
kanzure |
http://heybryan.org/bioreactor/membraneless_filtration/2009-01-23.png
<- at least I know it works. |
| 17:39.04 |
brlcad |
hehe, kanzure
that's pretty cool |
| 17:40.58 |
kanzure |
so setting
zrot = tan(y/x) didn't do the trick (I've tested and zrot is indeed
the correct rototation) |
| 17:41.42 |
*** join/#brlcad CIA-65
(n=CIA@208.69.182.149) |
| 17:41.45 |
kanzure |
there's some
function that will do it correctly (clearly), so what I should do
is go through it manually and then figure out what my function plot
looks like |
| 17:44.00 |
brlcad |
yeah |
| 17:44.06 |
brlcad |
I suspect
it's just the keypoint |
| 17:44.26 |
brlcad |
the default
keypoint is going to be one of the corners of that
"window"/box |
| 17:44.38 |
kanzure |
btw, I set
keypoint to 0 0 0. |
| 17:44.40 |
brlcad |
which isn't
likely what you'd want to rotate about even for a z
rotation |
| 17:45.21 |
brlcad |
if they're
centered at the origin before you translate them, that would be
perfect |
| 17:45.48 |
brlcad |
center at the
origin, rotate as needed, translate into place |
| 17:46.32 |
brlcad |
otherwise
you'll need to call 'keypoint' and compute the center of the
box |
| 17:49.14 |
kanzure |
brlcad: nope,
even with keypoint 0 0 0; translate ; orot;. |
| 17:49.38 |
kanzure |
that's with
the zrot as the tangent at the point. That's probably wrong. Maybe
I should go ask #math. |
| 17:50.37 |
brlcad |
i said it has
to be centered on 0 0 0 |
| 17:50.47 |
brlcad |
if it's not
working, it's not centered there |
| 17:51.14 |
brlcad |
the script
you showed earlier, they certainly weren't being centered about the
origin |
| 17:51.18 |
kanzure |
I thought
keypoint centers it? |
| 17:51.33 |
brlcad |
no, keypoint
just sets the keypoint about which you rotate |
| 17:53.09 |
brlcad |
say your
object was a sphere, positioned at 100 0 0 .. if you rotate it 180
degrees with a keypoint of 0 0 0, it'll be at -100 0 0 |
| 17:53.50 |
kanzure |
so the
objects that I make are just rpp's with different sizes (xmin,
xmax, etc.) |
| 17:53.53 |
brlcad |
if you set
the keypoint to 100 0 0 and rotate it 180 degress, it'll still be
at 100 0 0 (but 'facing' the opposite direction) |
| 17:54.24 |
kanzure |
so I guess I
don't know how to set the center point? |
| 17:55.24 |
brlcad |
the
default/natural keypoint for a sphere happens to be center of the
sphere .. the default keypoint for an rpp is one of the corners
(the 'first' corner) |
| 17:56.48 |
brlcad |
so if it's a
box that is 10x10x2, modeled from 0 0 0 to 10 10 0, you'd want to
set the keypoint as 5 5 1 to have it rotate in place |
| 18:25.44 |
kanzure |
well that's
weird, setting zrot to zero produces the same result. I'm so
confused. |
| 19:31.31 |
PrezKennedy |
brlcad, have
you ever heard of shapeways? |
| 19:31.41 |
kanzure |
I have
:) |
| 19:31.53 |
kanzure |
ponoko,
shapeways, emachineshop, .. |
| 19:32.10 |
PrezKennedy |
which is the
best? |
| 19:32.24 |
kanzure |
http://heybryan.org/~bbishop/docs/comparison.html
comparison of thei nventories of fablab v. techshop v. emachineshop
(although I should add shapeways and ponoko) |
| 19:32.27 |
kanzure |
*the
inventories |
| 19:32.41 |
kanzure |
I have a
preference for ponoko, but only because the CEO has been friendly
to me :) |
| 19:34.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-121.sbndin.btas.verizon.net) |
| 19:36.28 |
kanzure |
brlcad: Ok,
so I'm using the pipe in the shell (outside of mged), and it seems
to work, except some "FAILED in Boolean evaluation"
messages. |
| 19:37.13 |
kanzure |
http://heybryan.org/bioreactor/membraneless_filtration/2009-01-23_pipe.png
- presumably, the parts where there is separation, are the places
where those FAILED messages are being thrown |
| 20:06.45 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 20:15.05 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 20:22.52 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
| 20:32.29 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-242.dclient.hispeed.ch) |
| 20:44.11 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 21:00.25 |
CIA-65 |
BRL-CAD:
03starseeker * r33599 10/brlcad/trunk/ (4 files in 3 dirs): Add
support for >, <, >=, <= to the -attr option in
search |
| 21:35.39 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564870.dsl.bell.ca) |
| 22:08.55 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 22:49.45 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:13.28 |
``Erik |
first the
lotus with the storm trooper driving, now this http://www.collegehumor.com/picture:1897399 |
| 23:13.34 |
``Erik |
the roads
just aren't safe anymore |
| 00:30.36 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:44.02 |
mafm |
night |
| 00:50.39 |
brlcad |
cya |
| 01:01.41 |
starseeker |
growls at in comand |
| 01:01.44 |
starseeker |
command |
| 01:03.33 |
brlcad |
sup? |
| 01:03.49 |
brlcad |
that would be
a fun command to totally rewrite to be more modular |
| 01:05.12 |
brlcad |
would be a
little tricky to refactor a few things, like making it a
pass-through to primitive-specific commands (e.g. "arb8 create
param1 param2 param3 ...", "sph make", etc) |
| 01:05.15 |
starseeker |
Oh, just
making the test commands for functionality checking |
| 01:05.33 |
starseeker |
is getting to figure out legal parameters for all the
primitives... |
| 01:06.06 |
starseeker |
is starting mged testing script for libged
work |
| 01:06.12 |
brlcad |
oh,
awesome! |
| 01:06.25 |
brlcad |
I was
thinking about that whilest in the wonderful training
today |
| 01:06.34 |
starseeker |
training? |
| 01:06.57 |
starseeker |
panics |
| 01:06.59 |
brlcad |
another
construx course that ed and I are in |
| 01:07.03 |
brlcad |
you're
fine |
| 01:07.03 |
starseeker |
oh,
ok |
| 01:07.05 |
starseeker |
phew |
| 01:07.15 |
brlcad |
today was 50%
overlap with estimation training |
| 01:07.25 |
brlcad |
next two days
are more to the meat |
| 01:07.33 |
starseeker |
got to play with financial stuff and car oil changes - got in
at 5pm :-( |
| 01:07.36 |
starseeker |
cool |
| 01:07.47 |
brlcad |
and at least
he covered and was familiar with how his practices relate to agile
methods |
| 01:08.05 |
starseeker |
well, that
helps a bit :-) |
| 01:08.16 |
starseeker |
still has fond memories of the previous
course |
| 01:08.37 |
brlcad |
yeah, he
seems a lot more knowledgable about the differences in different
types of projects, research-oriented,
production-oriented |
| 01:09.02 |
brlcad |
how they
relate, how various techniques fall apart |
| 01:09.13 |
starseeker |
awesome |
| 01:10.31 |
brlcad |
if anyone
wants to talk to the sourceforge staffers, they're hosting an "open
house" meeting on the 29th (Time: 2009-01-29 11:00AM Eastern
(08:00AM Pacific, 15:00 UTC)) |
| 01:10.53 |
starseeker |
irc? |
| 01:10.57 |
brlcad |
they'll open
to complaints, requests, comments |
| 01:11.02 |
brlcad |
yeah on
irc |
| 01:11.05 |
starseeker |
nifty |
| 01:11.10 |
brlcad |
irc.slashnet.org, #sourceforge |
| 01:11.34 |
brlcad |
it's not the
first time they've done it, they started irc meetings about a year
ago, have held a couple |
| 01:11.56 |
brlcad |
is particularly interested in the new trac
integration... |
| 01:12.35 |
brlcad |
I'm not sure
if it's a solution in search of a problem, but trac is a much
better tracking system than the sf.net trackers |
| 01:12.40 |
starseeker |
doesn't really have too much to complain about, aside from
the connection being dropped on big commits... |
| 01:12.46 |
starseeker |
nice |
| 01:12.47 |
brlcad |
for at least
some definitions of 'better' |
| 01:13.37 |
brlcad |
if you want
to kick the tires on it, lemme know and I'll turn it on |
| 01:14.14 |
brlcad |
there are
about a dozen other apps they've recently integrated too with the
new infrastructure, documented somewhere.. (just lemme
know) |
| 01:14.48 |
starseeker |
cool |
| 01:14.51 |
starseeker |
will look into it |
| 01:15.22 |
starseeker |
is about to be drivin nuts by the stray character capture in
the tcl command window |
| 01:16.26 |
brlcad |
you ran into
it? |
| 01:16.33 |
brlcad |
it's *really*
easy to fix |
| 01:16.41 |
brlcad |
IFF you find
the keybinding that causes it |
| 01:16.53 |
starseeker |
looks like
it's popping up when I do a paste into tcl, and then hit return too
fast |
| 01:16.54 |
brlcad |
I fixed
"most" of them over a year ago |
| 01:17.12 |
starseeker |
can't nail it
down yet |
| 01:17.36 |
starseeker |
glares at Tk for allowing it to happen in the first
place |
| 01:17.40 |
brlcad |
could be a
scroll event (including you clicking on the scroll bar) |
| 01:18.24 |
brlcad |
tk textareas
with a scrollbar are very very simple, app code controls pretty
much every binding |
| 01:18.53 |
brlcad |
at least the
way we use it -- there's probably a better widget now that does
much of it for free, but not back in the day |
| 01:18.59 |
starseeker |
nods |
| 01:19.18 |
starseeker |
note to self
- find better text widget... |
| 01:22.15 |
brlcad |
not worth
it |
| 01:22.49 |
brlcad |
it'd take a
lot of work to decouple it and if you did everything right, it'd be
nearly identical |
| 01:23.05 |
starseeker |
wouldn't it
be a benefit on the maintainance side of things though? |
| 01:23.08 |
brlcad |
better effort
spent merging archer with mged |
| 01:23.11 |
starseeker |
true |
| 01:23.19 |
brlcad |
I think its
text widget might be newer/better |
| 01:24.58 |
starseeker |
that reminds
me - how did you want to address the "list of drawn objects"
problem? It seems like a state issue, and libged is supposed to be
stateless, but some of the commands need to "trigger" an entry in
some list somewhere in MGED, at the very least |
| 01:27.41 |
starseeker |
not to
mention rt itself |
| 01:31.00 |
brlcad |
hmm.. hehe,
now what a thing of beauty .. http://brlcad.org/~sean/tmp/lotii.jpg |
| 01:31.30 |
starseeker |
heh |
| 01:31.45 |
starseeker |
where'd that
come from? |
| 01:31.55 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 01:31.57 |
brlcad |
libged
operates on a ged structure, which includes lists -- so the
commands themselves are stateless, but they are passed lists to
operate upon (and have to be written/modified to recognize the ged
lists) |
| 01:32.04 |
brlcad |
just found it
somewhere |
| 01:32.11 |
starseeker |
cool |
| 01:32.13 |
brlcad |
i think
that's all the colors :) |
| 01:32.20 |
starseeker |
thought for a second it was a raytraced image
:-P |
| 01:32.23 |
brlcad |
except two
exotics |
| 01:32.47 |
brlcad |
don't think
the mother-of-pearl one is there |
| 01:41.41 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-236.sbndin.btas.verizon.net) |
| 01:42.15 |
starseeker |
phew |
| 01:44.12 |
starseeker |
that's all
the primitives in claims to support in 7.12.6 |
| 01:54.37 |
starseeker |
brlcad: I'm
going to stick what I've got into svn for safe keeping, but it's
nowhere near ready so it's a temporary file name and not being
added to the test routines |
| 01:55.09 |
starseeker |
however,
using the "would I want to redo this if I lost it" metric i don't
want to lose it ;-) |
| 01:56.15 |
CIA-31 |
BRL-CAD:
03starseeker * r33608 10/brlcad/trunk/regress/mged_test.sh: Add
early stages of mged test script intended to exercise (eventually)
all mged commands. |
| 02:04.28 |
brlcad |
starseeker:
k, just don't forget EXTRA_DIST though in the meantime |
| 02:04.49 |
brlcad |
distcheck
will fail if files are missing |
| 02:17.13 |
CIA-31 |
BRL-CAD:
03starseeker * r33609 10/brlcad/trunk/regress/Makefile.am: put
mged_test.sh in EXTRA_DIST |
| 02:25.48 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128565480.dsl.bell.ca) |
| 03:12.30 |
yukonbob |
hello,
cadheads |
| 03:12.34 |
brlcad |
howdy |
| 03:24.21 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 03:41.08 |
starseeker |
brlcad: I
don't suppose there are any docs anywhere on the implementation of
sketch and what { bezier D 4 P { 4 7 9 8 0 } } is actually
describing? |
| 03:44.54 |
brlcad |
bezier curve,
degree 4, control points 4 5 9 8 and 0 |
| 03:45.39 |
starseeker |
hmm - so
points are defined independently of particular
segments? |
| 03:46.26 |
starseeker |
what about {
carc S 6 E 5 R -1 L 0 O 0 } |
| 03:48.13 |
brlcad |
yeah |
| 03:48.18 |
brlcad |
there should
be a vertex list |
| 03:48.26 |
starseeker |
weird |
| 03:48.37 |
brlcad |
lines, carcs,
bezeiers, reference indices of that array |
| 03:48.56 |
brlcad |
S 5 E 4 ..
starts at vertex 5 ends at 4 |
| 03:49.07 |
starseeker |
ok - R is
radius? |
| 03:49.09 |
brlcad |
R
-1 |
| 03:49.10 |
brlcad |
right |
| 03:49.43 |
starseeker |
is that for
storage/efficiency reasons? |
| 03:50.04 |
starseeker |
would have stored line, xy start, xy end |
| 03:50.27 |
brlcad |
yeah,
generally way more compact as points are usually referenced at
least twice |
| 03:50.59 |
brlcad |
and it makes
for a topological structure |
| 03:51.24 |
brlcad |
you know that
two line segments actually connect by the fact that they reference
the same point |
| 03:51.32 |
brlcad |
not just
because they are "close" within a tolerance |
| 03:51.41 |
starseeker |
OK, I can see
that |
| 03:51.57 |
starseeker |
REALLY needs to work on his primitives
documentation... |
| 03:53.02 |
brlcad |
it's pretty
common paradigm, most geometry formats do that for all primitives
(check out an stl or dxf file sometime to see more
examples) |
| 03:53.24 |
starseeker |
nods - I can see the logic, just makes for very unintuitive
"interactive" geometry entering |
| 03:53.45 |
brlcad |
yeah
:) |
| 03:53.57 |
brlcad |
have to
specify all your points in advance |
| 03:54.03 |
brlcad |
it shouldn't
be the interactive form |
| 03:54.47 |
starseeker |
hmm. |
| 03:55.04 |
starseeker |
was setting up the "in" command to do just that, but perhaps
that's a bad move |
| 03:55.07 |
brlcad |
make
interactive whatever is most intuitive for interactive |
| 03:55.17 |
brlcad |
you have a
lot more flexibility there |
| 03:55.37 |
brlcad |
none of the
other primitives match the tclget form |
| 03:55.52 |
brlcad |
at least not
1-1, none that come to mind |
| 03:56.10 |
starseeker |
's first thought is to specify line segments, arcs, etc. and
have the in command figure out the points and make them "available"
if the user wants to specify them |
| 03:57.06 |
starseeker |
hmm |
| 03:57.18 |
starseeker |
I could
really go to town with this if I'm not careful |
| 03:57.26 |
brlcad |
since you
have the "points" in ascii form at that point (no pun intended),
you should be able to dervie the vertex list |
| 03:57.34 |
starseeker |
sure |
| 03:57.42 |
brlcad |
or.. |
| 03:58.27 |
starseeker |
I was
thinking to be able to specify either "X,Y" line segments or
"2->4" style to save typing |
| 03:58.52 |
brlcad |
without much
thought into it, could be similar to the tclget form sans the VL,
but allowing 'in' to have segmented sections for each 'primitive'
type prefixed with an identifier |
| 03:58.52 |
starseeker |
I've got to
be careful not to make "in" too elaborate though |
| 03:59.19 |
brlcad |
then you
could specify 'v'ertices as a primitive of their own before
use |
| 03:59.34 |
starseeker |
right |
| 04:00.04 |
brlcad |
like if you
wanted to make a line: in sketch sketch v 4.5 2.3 v 8.4 7.4 s 0
1 |
| 04:00.07 |
starseeker |
at user
option either specify a vertix explicitly, or have them deduced
from more "intuitive information |
| 04:00.51 |
starseeker |
or, in sketch
sketch l 4.5 2.3 8.4 7.4 -> same thing |
| 04:01.02 |
brlcad |
I don't think
you'd be able to deduce index vs value reliably without a
hint |
| 04:01.20 |
starseeker |
l would be
the hint - "line segment" |
| 04:01.34 |
brlcad |
e.g. in
sketch sketch l 4 2 8 7 |
| 04:01.44 |
brlcad |
is that 4.0
2.0 8.0 7.0 or indices |
| 04:01.55 |
starseeker |
use l for xy
xy form, s for v1 v2 form |
| 04:02.20 |
brlcad |
hm |
| 04:02.28 |
brlcad |
double up all
the entity types |
| 04:02.32 |
brlcad |
interesting
thought |
| 04:02.36 |
starseeker |
right |
| 04:02.46 |
starseeker |
what's
"intuitive" will depend on the situation |
| 04:03.04 |
starseeker |
or the
user |
| 04:03.48 |
brlcad |
could be
something like "s"/"si", "c"/"ci", etc |
| 04:03.55 |
starseeker |
right |
| 04:04.17 |
brlcad |
more to type,
but less to remember |
| 04:04.32 |
starseeker |
and
consistent between types |
| 04:13.04 |
brlcad |
well, that's
one bit you can probably have fun with for sure |
| 04:13.11 |
starseeker |
:-) |
| 04:13.45 |
starseeker |
the sketch
editor actually makes a bit more sense now that I get how it's
thinking about verticies |
| 04:14.08 |
brlcad |
yeah, you
probably see how the interface basically just directly ties to the
data |
| 04:14.39 |
brlcad |
because it
was completely written in just a couple days |
| 04:14.48 |
starseeker |
nods |
| 04:15.19 |
starseeker |
soome sense
of scale in the drawing window would probably help |
| 04:15.49 |
brlcad |
probably |
| 04:16.00 |
brlcad |
though it
does auto-adjust based on the points that are created |
| 04:16.12 |
brlcad |
so they're
semi-sensibly normalized to a useful range |
| 04:16.32 |
starseeker |
sure, but you
can't SEE that up front ;-) |
| 04:17.41 |
brlcad |
right, but if
I saw the values and saw that the values kept changing on me,
that'd be a bigger problem (I'd expect a fixed controllable scale
like the 3D view) |
| 04:17.54 |
starseeker |
nods |
| 04:18.37 |
starseeker |
thinks it would also help to have two panes - one which shows
the sketch in its local coordinate system and another which lets
the user get at the 3D settings |
| 04:19.29 |
starseeker |
or,
alternately, have the MGED window's display of the sketch object
handle that part |
| 04:19.35 |
starseeker |
just like any
other primitive |
| 04:20.52 |
starseeker |
brlcad:
Thanks for the orientation - it really helped |
| 04:21.48 |
brlcad |
nods |
| 04:22.57 |
starseeker |
I really
should get out of here... |
| 04:22.59 |
yukonbob |
brlcad:
question: ".a" archives are always "static", correct? |
| 04:23.00 |
brlcad |
sketch really
belongs integrated, just with a distinction of 2D editing
operations and 3D editing operations (along with 4D) as separate
"interfaces" |
| 04:23.10 |
brlcad |
yukonbob: .a
are static archives, yes |
| 04:27.01 |
Ralith |
yukonbob,
iirc, .a is literally just an amaglamation of .o |
| 04:27.48 |
brlcad |
pretty much,
at least the symbols of the specified .o files plus a table of
contents |
| 04:27.54 |
brlcad |
not just a
concatenation of files |
| 04:28.21 |
brlcad |
plus/minus a
few discrepancies for various platforms over the
decades |
| 04:28.26 |
Ralith |
yeah, not
quite that literally. |
| 04:28.48 |
starseeker |
:q |
| 04:28.53 |
starseeker |
whoops,
that's not vim |
| 04:29.35 |
starseeker |
<grin>
and now I'm going to go operate a motor vehicle |
| 04:29.37 |
Ralith |
if I had the
power to trigger a netsplit, that would have been an awesome time
to do so. |
| 04:29.54 |
starseeker |
lol |
| 04:29.54 |
yukonbob |
wtf would
libtool be trying to dynamically link a .a? |
| 04:30.02 |
Ralith |
O.o |
| 04:30.13 |
yukonbob |
www.pastebin.ca/1319264 |
| 04:30.14 |
brlcad |
yukonbob:
because someone specified a .a as an ldadd |
| 04:31.12 |
yukonbob |
Ralith: re:
'amalgamation' -- ya -- .a == archive, which iiuc is actually
similar to tar, for example... it has a ToC, etc. and can hold
multiple files... |
| 04:31.59 |
yukonbob |
heh |
| 04:32.10 |
yukonbob |
sees this has been discussed above... |
| 04:35.39 |
brlcad |
yukonbob:
that pastebin is normal -- it's just a warning that a "libtool
archive" (.la) was created that referenced linking against a
library for which there was no dynamic library found |
| 04:36.20 |
brlcad |
so it's
saying that it'll have to differ linking until the .la is used
whereupon it'll use the .a it found (which is fine for
binaries) |
| 04:37.02 |
brlcad |
it didn't try
to dynamically link a .a, it said it couldn't but that was all it
found |
| 04:50.50 |
CIA-31 |
BRL-CAD:
03brlcad * r33610 10/brlcad/trunk/include/bu.h: gah, hard-coding to
5 is a problem on 64-bit platforms where long's can be 64-bit and
require a 6 shift. must have been asleep at the
keyboard. |
| 05:01.29 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128565480.dsl.bell.ca) |
| 05:21.53 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 05:21.53 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.0 is now posted (20081108) |
| 05:21.53 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 05:22.12 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 05:22.14 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128565480.dsl.bell.ca) |
| 05:24.36 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 05:27.10 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 05:28.32 |
*** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198)
[NETSPLIT VICTIM] |
| 05:32.10 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 05:32.12 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 05:32.19 |
*** join/#brlcad Axman6 (n=Axman6@61.69.24.207) [NETSPLIT
VICTIM] |
| 05:32.19 |
*** join/#brlcad bjork_
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 05:32.45 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 05:32.46 |
*** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198)
[NETSPLIT VICTIM] |
| 05:33.20 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 05:33.20 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 05:33.21 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 05:33.21 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 05:33.26 |
*** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198)
[NETSPLIT VICTIM] |
| 05:33.56 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 05:33.57 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 05:33.57 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 05:37.52 |
*** join/#brlcad MinuteElectron (n=MinuteEl@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 05:37.52 |
*** join/#brlcad kanzure (i=bbishop@66.112.232.117) [NETSPLIT
VICTIM] |
| 05:39.11 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 05:39.25 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 05:40.32 |
*** join/#brlcad CIA-32 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 05:41.13 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 05:42.42 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 05:45.46 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 06:07.53 |
*** join/#brlcad madant
(n=madant@117.196.147.233) |
| 07:01.48 |
yukonbob |
brlcad: ok --
thx for that commentary -- I've got more questions/cases coming --
I'm approaching this in a measured baby-step fashion as much as I
can... ;) |
| 07:55.37 |
starseek1r |
decides sleep is in order... |
| 07:56.27 |
starseeker |
humph |
| 08:06.40 |
brlcad |
heh |
| 08:46.25 |
*** join/#brlcad archivist_ub
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 08:55.55 |
*** join/#brlcad csanyipal
(n=csanyipa@91.102.231.33) |
| 08:56.28 |
csanyipal |
Howdy! |
| 10:18.34 |
*** join/#brlcad mafm
(n=quassel@119.Red-81-39-20.dynamicIP.rima-tde.net) |
| 11:43.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 12:03.40 |
d-lo |
mernin
all |
| 12:04.39 |
mafm |
mernin
d-lo! |
| 12:07.10 |
d-lo |
Finally
getting snow here. Time for some sled action... well after work
that is. |
| 12:13.43 |
mafm |
:) |
| 12:13.53 |
mafm |
we had a bit
of snow several times, but not very heavy |
| 12:14.01 |
mafm |
we never
do |
| 12:21.00 |
d-lo |
well, aren't
you somewhat close to the Med? |
| 12:31.09 |
mafm |
mmm |
| 12:31.15 |
mafm |
I'll
geolocate myself now: |
| 12:31.20 |
*** join/#brlcad madant
(n=madant@117.196.128.155) |
| 12:36.43 |
*** join/#brlcad mafm
(n=quassel@119.Red-81-39-20.dynamicIP.rima-tde.net) |
| 12:36.50 |
mafm |
ops
:) |
| 12:38.59 |
mafm |
http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=lugo&sll=38.707163,-9.135517&sspn=0.428661,0.76561 |
| 12:41.17 |
madant |
mafm u are at
Lugo ? |
| 12:41.27 |
mafm |
madant:
yep |
| 12:42.03 |
mafm |
why, do you
know somebody from there? |
| 12:42.43 |
madant |
nah.. only
Barcelona which is like the other coast right :) |
| 12:42.51 |
madant |
ever been to
Siurana ? |
| 12:42.56 |
mafm |
yep |
| 12:43.05 |
mafm |
1k km
away |
| 12:43.20 |
mafm |
nope, I don't
even know where Siurana is :) |
| 12:43.55 |
mafm |
about the
proximity to mediterranian sea: alps are closer, pirinees are
touching it, and there's a lot of snow there :) |
| 12:44.18 |
d-lo |
mafm: So I
see :) |
| 12:44.47 |
``Erik |
I don't think
I can get to the main road |
| 12:44.49 |
mafm |
but there are
no big mountains around, the tallest are about 2k
meters |
| 12:45.48 |
d-lo |
``Erik: I am
begining to see a pattern with you and brlcad: "Oh i have this
expensive, awesome sports car and there is a bit of snow on the
ground... guess I'll have to stay home today!" :P |
| 12:45.51 |
madant |
Siurana is
near barcelona . good for climbing |
| 12:45.53 |
madant |
http://www.master-hunters.com/fotos/siurana.jpg |
| 12:46.23 |
mafm |
:) |
| 12:46.32 |
mafm |
I've only
been a couple of times in Catalonia |
| 12:46.33 |
d-lo |
madant: Thats
a beautiful picture! |
| 12:46.35 |
``Erik |
they're
light, have insane amounts of torque and have tires that simply do
not grab in snow and rain |
| 12:46.52 |
``Erik |
my truck
woulda done it, my car cannot |
| 12:47.33 |
d-lo |
Took the Jeep
out and had some pseudo-offroading/snowsleding fun this morning :)
Its why I got to work about an hour later than norm :) |
| 12:47.35 |
``Erik |
and
amusingly, I think there's more snow on my driveway than I can
clear |
| 12:47.56 |
``Erik |
heh, I had an
'80 honda civic stationwagon that I did effin' insane shit in the
snow with |
| 12:48.03 |
d-lo |
how much you
have on the ground thus far ``Erik |
| 12:48.15 |
d-lo |
Honda's are
great for that. |
| 12:48.25 |
``Erik |
at one point,
I got stuck in mud and snow, ended up pushing it into a ditch and
slaloming down to the street below |
| 12:48.40 |
d-lo |
CRX + snow
covereed deserted mall parking lot = crazy fun :) |
| 12:48.48 |
d-lo |
lol
nice! |
| 12:48.56 |
``Erik |
um, well, ok,
I'm sure it does clear, but I can't see the road or sidewalk, it's
hard to make out the curb |
| 12:49.22 |
``Erik |
looks lik ea
couple inches |
| 12:49.26 |
``Erik |
~2-3 |
| 12:49.27 |
ibot |
-1 |
| 12:49.33 |
d-lo |
lol |
| 12:49.53 |
d-lo |
damn 'bots
always piping up when you don't wantem to. |
| 12:50.05 |
d-lo |
~What is the
meaning of life? |
| 12:50.07 |
ibot |
I think you
lost me on that one, d-lo |
| 12:50.19 |
``Erik |
I only see 3
cars tracks in the cul de sac here |
| 12:50.21 |
d-lo |
its 42 silly.
Sheesh. |
| 12:50.22 |
``Erik |
~what is
42? |
| 12:50.23 |
ibot |
42 is, like,
the answer to life the universe and everything, see also
http://en.wikipedia.org/wiki/the_answer_to_life,_the_universe,_and_everything |
| 12:50.29 |
``Erik |
NO ROUND
TRIP! FAIL@ |
| 12:50.50 |
``Erik |
is the BC
in? |
| 12:50.59 |
``Erik |
I'm getting
no answer on the phone |
| 12:51.09 |
d-lo |
Dunno. They
have that Software training thing going on. |
| 12:51.16 |
``Erik |
ohhhh,
hrm |
| 12:51.25 |
``Erik |
that'd be why
I got no answer yesterday |
| 12:51.37 |
d-lo |
if you want,
"I saw Erik here today" :) |
| 12:51.49 |
``Erik |
nah, I'm too
honest for all that |
| 12:51.49 |
d-lo |
I think its
me an d John A in the whole building. |
| 12:51.53 |
``Erik |
hrm |
| 12:52.11 |
``Erik |
do you have a
CoC? |
| 12:52.14 |
``Erik |
wow, that
sounded wrong |
| 12:52.41 |
d-lo |
we only have
abour 1" on the ground up by my house, but by the way the radio and
TV are reporting it, you'd think its The End. |
| 12:52.46 |
d-lo |
lol |
| 12:53.13 |
``Erik |
it's moving
east by northeast, so you might get soem more |
| 12:53.34 |
d-lo |
CoC = Cohorts
of Chaos. A Centaur based guild on the game of Shadowbane known
for their effective hit and run tactics. |
| 12:53.38 |
``Erik |
here's the
thing, I can't drive, but I want to work, I d'no if it'd be ok for
me to work from home, being open source, etc |
| 12:53.42 |
``Erik |
I meant chain
of command |
| 12:53.51 |
d-lo |
:D |
| 12:53.56 |
``Erik |
otherwise,
it'd be corrosion of conformity |
| 12:54.08 |
d-lo |
Just leave
messages. If I see someone, I will let em know. |
| 12:54.16 |
``Erik |
which became
a pretty decent band when they picked up pepper |
| 12:54.36 |
``Erik |
yeah buying
an outback is looking more and more attractive |
| 12:54.42 |
d-lo |
I saw them
when the opened for Metallica during the Poor ol Touring Me tour in
Orlando. |
| 12:54.51 |
``Erik |
uhm, around
'93 or '94? |
| 12:55.05 |
d-lo |
Outbank in
addition to the M3? |
| 12:55.09 |
d-lo |
'97 |
| 12:55.15 |
d-lo |
summer of
'97 |
| 12:55.26 |
``Erik |
my best bud
in high school was hired as a bouncer for metallica and CoC in
seattle around '94 or so |
| 12:55.51 |
``Erik |
yeah, m3 for
nice days, outback for not nice days, plus the larger
payload |
| 12:55.56 |
``Erik |
and selling
my truck to a neighbor |
| 12:56.31 |
d-lo |
yeah, you
told me about the truck. If you need help pushing it out into the
street, lemme know :) |
| 12:56.54 |
``Erik |
hehehe, well,
a neighbors friend wants to buy it to fix it up for his son, and
the neighbor is thinking about buying it himself |
| 12:56.56 |
d-lo |
So... normal
Outback or Baja Outback ;) |
| 12:57.17 |
``Erik |
uhm, they
have like half a dozen variants now, I was looking at the 'sports'
edition, because I'm, well, stupid |
| 12:58.51 |
*** join/#brlcad mafm2
(n=quassel@119.Red-81-39-20.dynamicIP.rima-tde.net) |
| 12:58.59 |
brlcad |
has absolutely no aversion to working (or going in to work),
else I wouldn't do this for fun and in most of my spare time
too |
| 12:59.03 |
d-lo |
Nah, not
stupid... just enjoys a nice toy or two. |
| 12:59.13 |
brlcad |
suckers just
pay me to do it too |
| 12:59.17 |
d-lo |
lol |
| 12:59.21 |
brlcad |
so I buy
toys |
| 12:59.43 |
``Erik |
morning, "the
boy" |
| 13:00.22 |
brlcad |
not nice to
call mafm2 that! |
| 13:00.41 |
d-lo |
brlcad: hows
the class? |
| 13:00.53 |
brlcad |
it's
alright |
| 13:02.22 |
brlcad |
mostly a big
rehash of things already known, particularly for open source
project management, agile practices, estimation
techniques |
| 13:02.37 |
brlcad |
today and
tomorrow are diff topics, so will see |
| 13:03.02 |
d-lo |
heh, well,
known to you mebbe, hence why *I* wanted to go :P |
| 13:04.48 |
d-lo |
brlcad: you
gonna be able to make it to post? |
| 13:04.50 |
brlcad |
wanting to
get into project management? |
| 13:05.16 |
brlcad |
d-lo: don't
see why not |
| 13:06.01 |
brlcad |
ballerina on
ice .. just have to take it really slow |
| 13:06.02 |
d-lo |
brlcad: Yes,
actually i do. And was just asking about the roads because the
one's I traveled were not that great and getting worse. |
| 13:06.53 |
mafm2 |
d-lo:
:P |
| 13:07.46 |
brlcad |
mm,
frightening :) |
| 13:08.07 |
d-lo |
well, its not
the roads, but the retarded hicks with big trucks that scare
me. |
| 13:08.20 |
brlcad |
not that,
wanting to :) |
| 13:09.18 |
d-lo |
heh, well I
have managed my way out of a few wet paper bags in my life so there
:P |
| 13:09.45 |
brlcad |
like many
things, the job is often best served by people that don't want it
-- the don't meddle/impose, don't get too involved, have more
humble people skills, protect their people better, etc |
| 13:10.27 |
brlcad |
particularly
for software management, unless you start up a production shop
where you're just coding widgets with no research
aspect |
| 13:11.13 |
d-lo |
hrm, well,
the opposite can be said also. Too humble/univolved and the
leadership aspect is nullified. |
| 13:11.29 |
brlcad |
sure, it's
not black and white |
| 13:11.30 |
d-lo |
Its more a
fine balance that makes a good manager. |
| 13:11.34 |
brlcad |
it's just the
bigger trend |
| 13:12.18 |
d-lo |
I'll agree
100% with the micromanagement. Let the workers work and the
leaders lead ;) |
| 13:12.46 |
brlcad |
it's not just
micromanagement |
| 13:12.58 |
brlcad |
it doesn't
take much at all to demotivate |
| 13:13.57 |
brlcad |
hell, I
honestly almost quit over an argument about shutting doors many
years ago |
| 13:14.30 |
d-lo |
Exactly,
which is where a univolved/humble manager will fail. If a manager
cannot set realistic, attainable waypoints/goals with tangible
benefits for the workers, morale drops quickly. |
| 13:14.56 |
brlcad |
authority or
rules without merit or reason is a non-starter in my
world |
| 13:14.56 |
d-lo |
brlcad: as in
you wanted your door shut but management said to keep it
open? |
| 13:15.41 |
brlcad |
no,
different, but that's for another day |
| 13:15.53 |
d-lo |
I think thats
a given, actually. Very few people nowadays are happy with 'just
obeying the rules without knowing the why behind them' |
| 13:16.35 |
d-lo |
okay. I
could just see some of the managers here starting BS like that,
lol |
| 13:16.40 |
brlcad |
people bend
to the rules *all* the time, put up with crap and find work-arounds
instead of fixing the imposition problem |
| 13:17.23 |
d-lo |
heh, never
said they didn't bend to them, just said they aren't happy blindly
following. They usually seek the 'Why' or just quit. |
| 13:17.53 |
d-lo |
But you are
right, many people don't try to fix the problem.... thats someone
else's job... right? |
| 13:17.56 |
d-lo |
:) |
| 13:18.24 |
brlcad |
the point
should be seen in the industry productivity quotia .. that gov't
employees on *average* are only 30% productive |
| 13:18.34 |
brlcad |
compared to
industry's roughly 70% average |
| 13:19.41 |
d-lo |
Thats okay
though, because Obama will fix that too. lol |
| 13:19.45 |
brlcad |
that implies
that on average at least, that gov't workers put up with and allow
(or require) more than twice as much overhead process in their
work |
| 13:20.21 |
d-lo |
well, thats
assuming that 'Laziness' is either not accounted for or part of
overhead :) |
| 13:20.42 |
brlcad |
process for
the sake of process "to be safe", process on top of process,
inefficiency at every corner, entrenched workers that do negative
work |
| 13:20.56 |
brlcad |
the class
actually touched on net negative programmers, I was really glad to
see that |
| 13:21.14 |
``Erik |
hides |
| 13:21.18 |
d-lo |
lol |
| 13:21.41 |
brlcad |
did not know
that the rate of negative programmers is actually around
30% |
| 13:21.45 |
``Erik |
I have an
abstract to write, and a fistful of crap I wanna work on,
sucks |
| 13:21.48 |
``Erik |
really?
huh |
| 13:22.04 |
``Erik |
uh, how did
the bz migration go? HRM? |
| 13:22.21 |
``Erik |
order of
criticality is bz, the suns, then code, right? |
| 13:22.22 |
``Erik |
:D |
| 13:22.39 |
brlcad |
the migration
has actually been underway |
| 13:22.39 |
d-lo |
rate.... as
in the amount of negative producicity they create or the amount of
neg programmers compared to the total amount of
programmers. |
| 13:22.43 |
d-lo |
> |
| 13:22.45 |
d-lo |
? |
| 13:23.12 |
``Erik |
software
developers have a HUGE difference between 'stars' and
'tards' |
| 13:23.16 |
brlcad |
d-lo: that on
a given team, the team would actually get *more* work done if that
programmer was not there |
| 13:23.19 |
brlcad |
in the long
run |
| 13:23.36 |
brlcad |
due to bugs
that go unnoticed that have to get fixed X months/years from
now |
| 13:23.45 |
brlcad |
due to
overhead communication to keep everyone informed |
| 13:23.57 |
brlcad |
due to
arguments and disconformity |
| 13:23.59 |
``Erik |
mythical man
month provided brilliant insight in the 70's |
| 13:24.16 |
``Erik |
but was
mostly ignored by the "powers that be" |
| 13:24.32 |
brlcad |
``Erik:
you'll like one stat .. i'll have to mention it later |
| 13:24.41 |
``Erik |
heh,
pm? |
| 13:24.51 |
brlcad |
no, i'm just
gonna be late |
| 13:24.56 |
brlcad |
ask me about
paradigms |
| 13:25.24 |
``Erik |
ok, *shrug*
when we're both in the office, I'll jabber about four
nickels |
| 13:25.53 |
``Erik |
a bit
confused why this can't be said here and now, but
*shrug* |
| 13:25.55 |
brlcad |
or here
later, I just gotta hit the road :) |
| 13:26.22 |
``Erik |
ah, aight,
you're riding what, michelin pilot pros? be damn careful, they
don't grab snow/ice owrth a fuck |
| 13:26.37 |
``Erik |
I have 'em on
the front, I refuse to drive cuz I don't feel like dying
today |
| 13:26.53 |
d-lo |
"Today is a
good day to die." |
| 13:27.05 |
brlcad |
more worried
about getting her prettiness all sullied with muck and
grime |
| 13:27.10 |
``Erik |
heh,
amusingly, I have a wad of that blood. |
| 13:27.13 |
``Erik |
but I
disagree. |
| 13:27.45 |
archivist |
cars are
meant to be used |
| 13:27.45 |
``Erik |
tell ya what,
witht he m's, I'm FAR more scared about the fucker behind me not
having the braking power |
| 13:28.26 |
``Erik |
I mean, good
street conditions, I can clomp down and stop in half the distance
of an average sedan... fuckers tailgate and don't pay attention,
it's damn dangerous |
| 13:28.45 |
*** join/#brlcad smurfette
(n=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) |
| 13:28.46 |
d-lo |
yeah, the
snow has always been the least of my worries... its all the idiots
out there. |
| 13:29.43 |
d-lo |
I'll be
watching the roads/storm progress. I'll jet if it gets too bad.
Although I don't think it will be a problem. |
| 13:29.43 |
``Erik |
the, uh,
silverado sportback that parks in the same lot, I hit the brakes
coming up on paradise, the dude was all sideways and shit from
hitting the brakes too hard :( he blew out into the turn lane, but
I was crapping my drawers |
| 13:29.54 |
d-lo |
has been playing ddo and kinda likes it. |
| 13:30.07 |
``Erik |
your jeep
should be able to track fairly well in this east coast
shit |
| 13:30.17 |
``Erik |
ddo? |
| 13:30.27 |
``Erik |
dance dance
OBLIVION? |
| 13:30.39 |
d-lo |
vomits. |
| 13:30.56 |
d-lo |
No, not that
retarded game. |
| 13:31.00 |
d-lo |
D&D
online. |
| 13:31.08 |
d-lo |
playing the
10 day free trial. |
| 13:31.10 |
``Erik |
did you see
the generic rip-off at the bowling alley? |
| 13:31.25 |
d-lo |
Nope, must
have missed it. |
| 13:31.35 |
d-lo |
Either that
or my brain blocked it out from my memory on purpose. |
| 13:31.48 |
``Erik |
they're
redoing shit, it's amusing, in the "arcade" section, there is a ddr
rip-off |
| 13:32.04 |
``Erik |
richard
claims it's going out due to green tube failure |
| 13:32.18 |
d-lo |
'green tube
failure' |
| 13:32.24 |
d-lo |
... is that
medical talk? |
| 13:32.31 |
``Erik |
crt
shit |
| 13:32.48 |
d-lo |
eww.... who
uses crts anymore? |
| 13:33.02 |
``Erik |
it's a
halfassed ddr rip with a little crt and a shitty stomp pad
thing |
| 13:33.50 |
d-lo |
heh, I
threatend my mother-in-law's life when she mentioned she might get
us that DDR pad for Xmas. |
| 13:34.12 |
d-lo |
We got copies
of NWN instead :) |
| 13:34.56 |
d-lo |
hates DDR in case you haven't noticed. |
| 13:36.14 |
d-lo |
hey, where
can you find the default size of the Socket buffer at the OS
level? |
| 13:38.55 |
``Erik |
um, usually
it's the same as the page buffer |
| 13:39.03 |
``Erik |
BUFSIZ in uh,
stdlib.h I think |
| 13:39.08 |
d-lo |
kk. |
| 13:39.34 |
d-lo |
justr trying
to size a socket buffer intelligently. |
| 13:39.49 |
``Erik |
most os's
have gone with 0-copy socket buffers, so it's a page |
| 13:41.02 |
``Erik |
um, the ether
spec says 1500, which comes out to like 1486 or something, but
frags are recouped immediately now |
| 13:41.07 |
``Erik |
*think* |
| 13:41.18 |
d-lo |
1500
bytes? |
| 13:41.25 |
``Erik |
*fail* 1k is
probably a good size |
| 13:41.26 |
``Erik |
yeah |
| 13:41.51 |
``Erik |
there's crap
fro "large packets"... heh, I d'no, I don't remember |
| 13:42.05 |
d-lo |
no worries...
just looking for a starting point. |
| 13:42.40 |
``Erik |
1k is safe,
4k is common |
| 13:43.13 |
``Erik |
BUFSIZ is
usually 4k |
| 13:43.39 |
``Erik |
if you get to
the point where it actually matters, you'll know. |
| 13:44.18 |
d-lo |
well, I will
be streaming several MB of data, so I am going to fill the buffer
every time.. |
| 13:45.50 |
``Erik |
don't sweat
it until it becomes a problem |
| 13:46.14 |
``Erik |
fragment
collectors and buffers are pretty damn solid these days |
| 13:46.26 |
d-lo |
kk |
| 13:46.33 |
d-lo |
so what you
upto today> |
| 13:46.34 |
d-lo |
? |
| 13:46.55 |
``Erik |
I need to
write an abstract for a conference |
| 13:47.02 |
``Erik |
and do some
adrt/isst work |
| 13:47.05 |
d-lo |
abstract....
what? |
| 13:47.27 |
``Erik |
uh, some v/l
conf up in jersey that BC is all twisted in a knot
about |
| 13:47.47 |
d-lo |
so an
abstract presentation? |
| 13:48.17 |
``Erik |
yeah, she
wants me to present in like may, but it needs and abstract by end
of jan |
| 13:48.41 |
d-lo |
wow... thats
a bit ahead of schedule! |
| 13:49.02 |
``Erik |
gov't is as
gov't does |
| 13:53.16 |
*** join/#brlcad Vivek
(n=Vivek@gnu-india/admin/VivekVC) |
| 13:53.49 |
Vivek |
Where can I
get the install instructions for brl-cad ? |
| 13:54.26 |
Vivek |
I have
downloaded the 64 bit version and unzipped and untared
it |
| 13:54.43 |
d-lo |
what
OS? |
| 13:57.15 |
Vivek |
Ubuntu |
| 13:57.59 |
d-lo |
did you get
the binaries or the source? |
| 13:59.19 |
Vivek |
d-lo:
http://downloads.sourceforge.net/brlcad/brlcad_7.12.2_x86_64.tar.gz?modtime=1209452298&big_mirror=0 |
| 13:59.53 |
Vivek |
d-lo: Source
from the above URL. |
| 14:00.42 |
``Erik |
what is the
fail? |
| 14:01.02 |
d-lo |
that looks
like a Binary distribution. try running mged from
rel-7.12.2/bin/ |
| 14:01.39 |
Vivek |
``Erik: I
need the howto to install it on ubuntu, a pointer to the revelant
document would be nice.\ |
| 14:02.04 |
Vivek |
d-lo: I use
ubuntu not rhel. |
| 14:02.23 |
d-lo |
Vivek: yes,
you said that. |
| 14:02.30 |
``Erik |
the code is
the doc :D I'm not looking at your URL, the source is the one true
way, fwiw |
| 14:02.54 |
Vivek |
``Erik:
ahaa |
| 14:03.12 |
Vivek |
I was looking
for a install or readme file :) |
| 14:03.25 |
``Erik |
we have both
an INSTALL and a README |
| 14:03.34 |
d-lo |
like I said,
You downloaded a Binary dist, so 'cd' over to
whereveryouuntarredit/rel-7.12.2/bin/ and try running
'mged' |
| 14:04.14 |
Vivek |
So can you
point me to the URL to download the latest souce :) |
| 14:04.34 |
``Erik |
being a 30
year old program, we install to /usr/brlcad/ by default, old school
unix style, yo |
| 14:05.00 |
Vivek |
``Erik:
ok... |
| 14:05.06 |
``Erik |
yes, the
sourceforge page has a link to the latest source, it's like 7.14.0
or something |
| 14:05.12 |
d-lo |
latest
tarball of source:
http://sourceforge.net/project/showfiles.php?group_id=105292&package_id=113368 |
| 14:05.36 |
d-lo |
or you can
get a SVN checkout if you want the latest (perhaps not greatest ;)
) |
| 14:06.53 |
Vivek |
``Erik and
d-lo: Thanks |
| 14:08.47 |
d-lo |
np |
| 14:09.48 |
Vivek |
oops I had
downloaded the binary earlier ;) |
| 14:51.59 |
*** join/#brlcad mafm2
(n=quassel@119.Red-81-39-20.dynamicIP.rima-tde.net) |
| 15:03.23 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 15:12.37 |
*** join/#brlcad madant
(n=madant@117.196.146.14) |
| 15:15.47 |
*** join/#brlcad mafm
(n=quassel@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 15:41.23 |
starseeker |
struggles back to something one might generously call awake
and heads in |
| 15:41.46 |
starseeker |
mmm, purty
snow |
| 15:41.51 |
starseeker |
this should
be entertaining |
| 15:45.01 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F0CC.dip.t-dialin.net) |
| 15:47.26 |
*** join/#brlcad madant1
(n=madant@117.196.140.123) |
| 16:09.58 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 17:06.42 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 17:29.15 |
*** join/#brlcad madant
(n=madant@117.196.140.123) |
| 17:31.14 |
*** join/#brlcad uwe123
(n=uwe@a33-94.adsl.paltel.net) |
| 17:48.52 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 18:25.10 |
CIA-32 |
BRL-CAD:
03bob1961 * r33611 10/brlcad/trunk/ (11 files in 4 dirs): Added the
following functions to libged: ged_grid2model_lu, ged_grid2view_lu,
ged_model2grid_lu, ged_model2view_lu, ged_view2grid_lu,
ged_view2model_lu and ged_view2model_vec. |
| 19:19.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-80.sbndin.btas.verizon.net) |
| 19:33.17 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-80.sbndin.btas.verizon.net) |
| 20:47.21 |
*** join/#brlcad AddZero
(n=user@c75-111-103-220.amrlcmta01.tx.dh.suddenlink.net) |
| 21:40.38 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F0CC.dip.t-dialin.net) |
| 21:56.37 |
brlcad |
mm.. today
was much better, that was fairly useful or at least
interesting |
| 21:57.46 |
brlcad |
d-lo: that's
one of those places where just using libpkg as the underlying
transport will save a lot of work |
| 21:58.17 |
brlcad |
it's a fairly
extensively tested codebase as it is that already parcels up and
delivers data across a pipe through a fairly simple
interface |
| 21:59.19 |
brlcad |
and it takes
care of all of the portability issues that you won't encounter (tcp
issues, drop outs, splits, kernel/system buffering, signals, etc)
just testing on a couple platforms |
| 22:02.12 |
brlcad |
also, fwiw,
our INSTALL file is in both the source and binary dists (in binary
it's in share/brlcad/VERSION/doc/INSTALL iirc, otherwise the http
svn URL helps) |
| 22:41.35 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 23:41.01 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 00:23.03 |
``Erik |
http://www.boingboing.net/2008/02/29/ted-2008-crow-vendin.html
skeers me |
| 01:02.28 |
mafm |
night |
| 01:08.11 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:45.45 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 02:17.40 |
``Erik |
<PROTECTED> |
| 02:18.58 |
Dr_Phreakenstein |
i still need
to see it |
| 02:19.23 |
Dr_Phreakenstein |
i was not one
of the 92.4 million that watched the game |
| 02:19.47 |
Dr_Phreakenstein |
anyone else
having trouble starting archer? |
| 02:20.01 |
``Erik |
http://www.collegehumor.com/video:1899103 |
| 02:20.24 |
brlcad |
Dr_Phreakenstein: works here |
| 02:20.46 |
Dr_Phreakenstein |
thanks,
both |
| 02:21.04 |
Dr_Phreakenstein |
probably my
bad installation |
| 02:21.47 |
brlcad |
that was one
of the best sb commercials |
| 02:22.03 |
Dr_Phreakenstein |
recompiling,
brb |
| 02:25.31 |
``Erik |
"chinlone: a
new sport that's like soccer, only interesting." hehehe |
| 02:38.17 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 02:47.30 |
Dr_Phreakenstein |
i don't
suppose that originated in, say, china |
| 02:55.20 |
``Erik |
burma,
apparently |
| 02:57.12 |
Dr_Phreakenstein |
eh, close
(sorta) |
| 03:06.13 |
Dr_Phreakenstein |
archer
gives: |
| 03:06.16 |
Dr_Phreakenstein |
unknown
option "-menu" |
| 03:06.39 |
Dr_Phreakenstein |
then tells me
that the error is unexpected, aborting |
| 03:07.34 |
``Erik |
hm, did you
build with --enable-all ? |
| 03:10.04 |
Dr_Phreakenstein |
make
clean;CFLAGS="-O2 -fomit-frame-pointer -msse3 -mmmx -m3dnow -pipe
-march=opteron -w" CXXFLAGS="${CFLAGS}" ./configure
--build=x86_64-pc-linux-gnu --enable-64bit-build --enable-optimized
--disable-debug --prefix=/usr/local --with-gnu-ld ;make -iks
--no-print-directory;make html-recursive; make install |
| 03:10.09 |
Dr_Phreakenstein |
no |
| 03:10.26 |
Dr_Phreakenstein |
are any of
those options problematic? |
| 03:10.30 |
``Erik |
it may be
that archer is using features added after your version of
tk |
| 03:11.21 |
Dr_Phreakenstein |
tk ver
8.5.6 |
| 03:11.42 |
Dr_Phreakenstein |
should i
retry with internal tk? |
| 03:11.44 |
``Erik |
um, possibly,
we have a tuned set of optimizations, --enable-optimized should be
used instead of that CFLAGS stuff (there might be conflicts), and
--build should theoretically be left to do its own |
| 03:12.21 |
Dr_Phreakenstein |
does
-optimized find my processor type (-march) |
| 03:12.25 |
``Erik |
--with-gnu-ld
would be assume, and I believe --enable-optimized insinuates
--disbale-debug |
| 03:12.45 |
``Erik |
it finds a
good enough match based on what the skeery weird shit we do is
:D |
| 03:12.59 |
Dr_Phreakenstein |
fair
enough |
| 03:13.10 |
``Erik |
the general
rule is "when it don't work right, just do "./configure
--enable-all --prefix=wherever" |
| 03:13.17 |
Dr_Phreakenstein |
can i use
parallel make (-j 17) |
| 03:13.20 |
``Erik |
yeah |
| 03:13.40 |
``Erik |
and we have a
'fast' build rule that helps if you have more than 8 or so
cores |
| 03:13.45 |
``Erik |
make -j23
fast |
| 03:14.24 |
Dr_Phreakenstein |
i only have
dual-proc, dual core, and i am using a new kde, so i need some
processor left ;) |
| 03:14.31 |
``Erik |
heh |
| 03:14.44 |
``Erik |
so the fast
rule won't benefit you :D |
| 03:14.48 |
``Erik |
nice make
-j3 |
| 03:14.49 |
``Erik |
:D |
| 03:14.51 |
brlcad |
8.5.6 should
be fine, but it's an easy enough recompile to make sure .. suspect
it's just something minor |
| 03:15.30 |
Dr_Phreakenstein |
probably,
seems to be someting with bwish, if i followed strace
correctly |
| 03:15.37 |
``Erik |
ya didn't
show up today, brlcad :) the tl was wondering where you were, and
ya missed korean |
| 03:15.46 |
Dr_Phreakenstein |
it made a 10
meg trace, so you can only read that in so much depth |
| 03:15.49 |
brlcad |
i sent him
e-mail |
| 03:16.20 |
brlcad |
repairs
yesterday went till 3am, didn't get going until late |
| 03:16.22 |
Dr_Phreakenstein |
email tubes
clogged, valve shut off |
| 03:16.36 |
``Erik |
eck
(repairs?) |
| 03:23.05 |
brlcad |
floor joists
on the main floor -- a series of repairs made during sale were done
very poorly |
| 03:23.20 |
brlcad |
now it's
outstanding, the guy that came to work on them was
phenomenal |
| 03:23.25 |
``Erik |
ah,
cool |
| 03:23.38 |
``Erik |
needs to try calling the guy to fix his front woodwork again
:/ |
| 03:24.35 |
``Erik |
(try calling
him again, fix it again) |
| 03:31.18 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 03:33.30 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 03:52.19 |
Dr_Phreakenstein |
Erik: hope he
is better than the Iraqi carpenters we found |
| 03:52.43 |
Dr_Phreakenstein |
they used
wood screws, and pounded them in with a hammer |
| 03:54.27 |
brlcad |
hah |
| 03:55.38 |
Dr_Phreakenstein |
if that was
the only problem, i could forgive them, but they were slow, flakey,
expensive, and the language barrier did not help |
| 03:56.01 |
Dr_Phreakenstein |
finished work
was sub-par at best |
| 03:56.42 |
Dr_Phreakenstein |
in their
defense, wood is not the material of choice over there, so they as
a whole had little experience, and less to work with |
| 03:57.23 |
Dr_Phreakenstein |
here, every
9-year old boy knows how to hammer nails, and use a tape measure,
at least a little bit |
| 03:57.42 |
Dr_Phreakenstein |
"helping" dad
with some honey-dos and a tree fort |
| 03:58.18 |
Dr_Phreakenstein |
perhaps
excepting urban apartment dwellers |
| 04:29.35 |
Dr_Phreakenstein |
oops.... make
distclean foo-barred my brlcad sources. probably something i
did |
| 05:11.21 |
Dr_Phreakenstein |
ok, ran into
error running make test |
| 05:11.40 |
Dr_Phreakenstein |
this may be
why i stoppped using internal tcl |
| 05:13.39 |
Dr_Phreakenstein |
question: |
| 05:14.10 |
Dr_Phreakenstein |
if i use
internal tcl/tk, where can i put brlcad specific
init.tcl? |
| 05:15.57 |
Dr_Phreakenstein |
or, more
specifically, how do i point brlcad components to a different
init.tcl file |
| 05:25.25 |
Dr_Phreakenstein |
fixed
it |
| 05:25.42 |
Dr_Phreakenstein |
gotta make
install *before* make test |
| 05:45.42 |
brlcad |
ah, yes ..
make test has lots of limitations |
| 05:46.17 |
brlcad |
has to be
installed, maybe requires an in-place build iirc too |
| 05:57.03 |
Dr_Phreakenstein |
back to same
-menu error after recommended options |
| 05:57.41 |
Dr_Phreakenstein |
something in
tcl |
| 05:58.22 |
Dr_Phreakenstein |
i am looking
at my environment to see how it is (likely) clobbering brlcad's
local tcl install |
| 05:58.31 |
Dr_Phreakenstein |
by tcl i mean
tcl/tk |
| 05:58.49 |
Dr_Phreakenstein |
, itk, and
friends |
| 06:01.39 |
brlcad |
where are you
installing to? the default path? |
| 06:02.00 |
brlcad |
ah,
/usr/local |
| 06:04.14 |
brlcad |
was going to
say that it's very unlikely that it'd be an environment issue,
unless you're mixing into a dir with existing tcl data |
| 06:04.45 |
brlcad |
still seems
unlikely to me (more likely just a simple, maybe recent, bug in
archer) |
| 06:05.34 |
brlcad |
easy enough
test if you really want to test it would be to install into
/usr/brlcad |
| 06:05.43 |
brlcad |
(i.e., the
configure default) |
| 06:08.37 |
Dr_Phreakenstein |
how do i tell
it to go to /usr/local/brlcad? have tried in past, with no success
(trying to keep /usr uncluttered, no luck) |
| 06:09.53 |
Dr_Phreakenstein |
wait- that
may have been the ebuild that i made (gentoo install file) that
could not do it |
| 06:10.01 |
Dr_Phreakenstein |
trying
now... |
| 06:11.25 |
Dr_Phreakenstein |
by chance,
does brlcad look at an environment variable named
TCL_LIBRARY |
| 06:11.41 |
Dr_Phreakenstein |
i have that,
set by something else, to 8.4 |
| 06:13.33 |
Dr_Phreakenstein |
also,
TCLHOME, TCLLIBPATH, ITCL_LIBRARY, ITK_LIBRARY |
| 06:15.49 |
Dr_Phreakenstein |
brlcad: are
you on the east coast? |
| 06:20.55 |
brlcad |
--prefix=/usr/local/brlcad |
| 06:21.07 |
Dr_Phreakenstein |
more
directly, do you ever sleep? you are tremendously helpful, about 22
hrs/day |
| 06:21.22 |
brlcad |
it will obey
the various tcl/tk _LIBRARY variables, but you shouldn't need to
set them |
| 06:21.50 |
brlcad |
thanks,
trying to get it up to 25 hours a day |
| 06:21.51 |
Dr_Phreakenstein |
iow, if they
are set wrong, i should clear them, no? |
| 06:22.01 |
brlcad |
oh
absolutely |
| 06:22.11 |
Dr_Phreakenstein |
look into
something called polyphasic sleep |
| 06:22.12 |
brlcad |
they will
override on pretty much every version of tcl |
| 06:23.03 |
Dr_Phreakenstein |
in a
nutshell, trains your body to achieve REM in less time |
| 06:23.03 |
Dr_Phreakenstein |
sleep 20
minutes, wake for 3 hrs 40 minutes |
| 06:23.15 |
Dr_Phreakenstein |
total of 3
hrs sleep per night |
| 06:23.24 |
brlcad |
i've actually
done that for short stints |
| 06:23.29 |
brlcad |
weekends
screw it up though |
| 06:23.32 |
Dr_Phreakenstein |
they call it
the uber-hacker schedule |
| 06:23.33 |
Dr_Phreakenstein |
yep |
| 06:23.59 |
brlcad |
as well as
long coding stints |
| 06:24.03 |
Dr_Phreakenstein |
also,
interactions with humans in "meatspace" can make it less
practical |
| 06:24.38 |
Dr_Phreakenstein |
as in, you
are awake all the time, but can only talk to people, go to store,
etc, certain times of the day |
| 06:24.56 |
Dr_Phreakenstein |
i am
considering it, how did it work for you? |
| 06:25.06 |
Dr_Phreakenstein |
besides above
mentioned |
| 06:25.07 |
brlcad |
yeah, that
already sucks to varying degrees with how I sleep/work
now |
| 06:25.13 |
Dr_Phreakenstein |
:) |
| 06:25.16 |
brlcad |
there are
upsides too though |
| 06:25.39 |
brlcad |
I moved into
the city party because of that same issue actually, more things
open much much later |
| 06:25.46 |
Dr_Phreakenstein |
did sig-other
think you were insane? |
| 06:25.48 |
Dr_Phreakenstein |
true |
| 06:26.20 |
Dr_Phreakenstein |
i live in
mid-smallish town (~40k ppl) |
| 06:26.39 |
Dr_Phreakenstein |
half of me
wants to live in a loft above telco, |
| 06:26.50 |
Dr_Phreakenstein |
other half
wants to be hermit in woods |
| 06:27.09 |
brlcad |
I find it
easier to just sleep 3-5 hours a day, a lot easier to sustain than
powernapping all the time |
| 06:27.37 |
brlcad |
particularly
with a work schedule where folks are calling and stopping by when
you'd be needing to nap |
| 06:28.09 |
Dr_Phreakenstein |
loft would be
downtown portland, OR, over fictitious telco( there are none dt
witha loft ovre them, and I could get u-DSL at 40 megs |
| 06:28.54 |
brlcad |
downtown
portland sounds hella fun |
| 06:29.03 |
Dr_Phreakenstein |
have you
been? |
| 06:29.06 |
brlcad |
nope |
| 06:29.17 |
Dr_Phreakenstein |
nothing like
it |
| 06:29.20 |
brlcad |
had a buddy
that lived there for a couple years |
| 06:29.35 |
Dr_Phreakenstein |
how did they
make him leave? |
| 06:29.53 |
Dr_Phreakenstein |
tow cable in
front, fire behind? |
| 06:30.09 |
brlcad |
heh |
| 06:30.25 |
brlcad |
job changed
iirc, found a great job out east |
| 06:30.34 |
Dr_Phreakenstein |
no job is
that good |
| 06:30.54 |
Dr_Phreakenstein |
rather starve
in stumptown, than succeed anywhere else |
| 06:31.20 |
Dr_Phreakenstein |
stumptown,
pdx, city of roses |
| 06:31.23 |
brlcad |
:) |
| 06:32.09 |
Dr_Phreakenstein |
downside is
crazy laws, and nearly communist ideas everywhere, creaping into
legislation |
| 06:32.27 |
Dr_Phreakenstein |
they want to
install box in cars, charge by mile |
| 06:33.05 |
brlcad |
they've
talked about doing that out here too |
| 06:33.12 |
Dr_Phreakenstein |
we actually
have an (by comparison) active communist party, and green
party |
| 06:33.24 |
Dr_Phreakenstein |
small
problem; |
| 06:33.27 |
Dr_Phreakenstein |
hackers |
| 06:34.11 |
Dr_Phreakenstein |
also, it
shoots self in foot by discouraging better fuel mileage the way gas
tax does |
| 06:34.59 |
Dr_Phreakenstein |
and... with
rising energy rates/demand, they want to actually *destroy* our
hydro power |
| 06:35.09 |
Dr_Phreakenstein |
literally
demolish dams |
| 06:35.19 |
Dr_Phreakenstein |
they forget
that will flood portland |
| 06:35.31 |
brlcad |
that's a
longer topic for another day :) |
| 06:35.39 |
Dr_Phreakenstein |
but it will
save 4000 fish |
| 06:35.53 |
brlcad |
is compelled to get a lil more code done before
naptime |
| 06:35.55 |
Dr_Phreakenstein |
sorry, fresh
fury still here |
| 06:36.21 |
brlcad |
can tell |
| 06:36.26 |
Dr_Phreakenstein |
still
compiling, will keep posted of progress |
| 06:36.29 |
Dr_Phreakenstein |
:) |
| 06:36.46 |
brlcad |
good luck on
the compiling -- here as usual and will respond eventually if you
have details |
| 06:36.59 |
Dr_Phreakenstein |
thanks |
| 06:37.29 |
Dr_Phreakenstein |
also, you are
welcome here anytime you would like to venture out west |
| 06:37.45 |
brlcad |
for testing,
you shouldn't have any env vars set that would override runtime
behavior including all the *_LIBRARY* vars |
| 06:37.57 |
Dr_Phreakenstein |
k |
| 06:40.26 |
brlcad |
be sure to
read the INSTALL file if you haven't yet (along with the README and
doc/README*) |
| 06:40.44 |
brlcad |
waves g'luck |
| 06:41.02 |
Dr_Phreakenstein |
thnx |
| 07:22.28 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 07:23.41 |
Dr_Phreakenstein |
profit! |
| 07:25.35 |
Dr_Phreakenstein |
awww...
segfault |
| 07:25.52 |
Dr_Phreakenstein |
but archer
did work long enough to do that |
| 07:25.54 |
Dr_Phreakenstein |
:) |
| 08:19.50 |
*** join/#brlcad brlquestions
(n=user@12.Red-83-44-240.dynamicIP.rima-tde.net) |
| 08:28.38 |
Dr_Phreakenstein |
thanks for
help brlcad and Erik |
| 08:29.53 |
Dr_Phreakenstein |
(entering
biphasic sleep mode, suspending operations) |
| 09:13.01 |
ruskie |
decides to not bother with separating utah... to much
pain... |
| 09:46.24 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-236-115.dclient.hispeed.ch) |
| 10:55.59 |
*** join/#brlcad appletizer
(i=user@82-32-123-8.cable.ubr04.hawk.blueyonder.co.uk) |
| 10:57.55 |
*** join/#brlcad Guest65051
(n=ssaq@ner-as25280.alshamil.net.ae) |
| 11:28.16 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-91-240.dclient.hispeed.ch) |
| 12:04.34 |
d-lo |
Morning all!
*Reads Backlog* |
| 12:04.57 |
d-lo |
heard the superbowl commercials were sub-par this year
:/ |
| 12:05.57 |
d-lo |
Heh, I'll
walk to work before I have to pay a black box. Sounds like a move
by the Cabbie Party. |
| 12:07.19 |
d-lo |
As a former
Nuclear Engineer, I can understand the frustration with fish
clogging up pumps, pipes and strainers. The answer, however, is
not to remove the power plant... its to sharpen the blades on the
pump impeller :) |
| 12:08.29 |
d-lo |
Anyone: Any
Fedora Core users here? Can they speak to the Pros and Cons of the
OS? |
| 12:13.23 |
appletizer |
fedora? |
| 12:13.28 |
appletizer |
it's good
:) |
| 12:13.34 |
appletizer |
centos is
better though |
| 12:13.39 |
appletizer |
fedora is
considered legacy |
| 12:14.09 |
archivist |
selinux bites
a few |
| 12:14.21 |
d-lo |
Well I was
checking out the FC10 VMware appliance last night.... gotta admit,
the KDE looks *a lot* like Vista... dunno how I feel about that
:/ |
| 12:14.45 |
d-lo |
appletizer:
Why, in your opinion, is centos > fedora? |
| 12:14.56 |
appletizer |
depends on
your goals |
| 12:15.11 |
appletizer |
for server
type goals, centos provides better stability |
| 12:15.22 |
d-lo |
Workstation
stuff. |
| 12:15.41 |
appletizer |
for
workstation, then people tend to use fedora |
| 12:16.04 |
appletizer |
fedora has
more bleeding edge packages |
| 12:16.13 |
archivist |
uses ubuntu due to EMC2 |
| 12:16.27 |
d-lo |
Trying to
make a smart decision as to which OS i am going to use... don't
feel like reinstalling/reconfiguring more than once. |
| 12:17.13 |
appletizer |
hehe honestly
it doesn't really matter |
| 12:17.54 |
d-lo |
It kinda
does, since each flavor has its own quirks, features and
pitfalls. |
| 12:18.05 |
appletizer |
yeah that's
what fuel unnecessary distro wars |
| 12:18.52 |
appletizer |
but there's
always a shift in distro popularity anyway |
| 12:18.58 |
appletizer |
it used to be
redhat once upon a time |
| 12:19.01 |
appletizer |
now it's
ubuntu |
| 12:19.23 |
d-lo |
heh, not
after popular :) If anything, I am anti-trendy. |
| 12:19.33 |
d-lo |
Its the
'Underdog complex' I suppose :) |
| 12:19.52 |
appletizer |
hehe underdog
could be useful |
| 12:20.02 |
appletizer |
in that
you're less exposed to malicious codings |
| 12:20.12 |
appletizer |
but the
downside of that is you get less userbase exposure |
| 12:20.30 |
d-lo |
True
enough. |
| 12:21.12 |
appletizer |
as long as
you're using one of the more popular distros, you're fine :)
anywhere between centos, fedora, rhel and ubuntu |
| 12:21.21 |
archivist |
I use ubuntu
only because the EMC2 devs use that for the RTAT realtime, makes
it easy for me to do cnc |
| 12:21.25 |
appletizer |
oh and
freebsd/openbsd of course :) |
| 12:21.29 |
archivist |
RTAI |
| 12:22.52 |
_sushi_ |
!calc
2+3 |
| 12:23.06 |
appletizer |
if you prefer
underdogs, nimblex or wolvix could be useful |
| 12:23.07 |
appletizer |
:P |
| 12:23.13 |
appletizer |
they're like
among the least populars |
| 12:23.14 |
appletizer |
haha |
| 12:24.00 |
d-lo |
heh, and that
gets back to my criteria of 'make a smart choice' :P |
| 12:25.10 |
d-lo |
spins some Prodigy. Good stuff. |
| 12:30.49 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:37.12 |
Defcon- |
d-lo, do you
remember the video of One Love |
| 12:37.26 |
Defcon- |
i'm still
wondering how long it took to render it back then :) |
| 12:37.33 |
Defcon- |
*than |
| 12:39.27 |
d-lo |
artist? |
| 12:40.59 |
Defcon- |
prodigy |
| 12:41.00 |
Defcon- |
:p |
| 12:41.15 |
d-lo |
don't think I
ever saw the video :/ |
| 12:41.28 |
Defcon- |
:) |
| 12:41.31 |
Defcon- |
it's on
youtube |
| 12:42.11 |
d-lo |
didn't have cable/mtv/vh1/highspeed internet till he was out
of highschool :/ |
| 12:42.27 |
d-lo |
I missed a
bunch of videos. |
| 12:43.00 |
Defcon- |
:) |
| 12:46.45 |
d-lo |
Defcon-: Heh,
I feel bad for not recognizing the song by title. Thats one of my
al time fav movies... as horrible as it was. lol |
| 12:52.11 |
Defcon- |
haha, it's ok
:) |
| 12:53.08 |
Defcon- |
everybody is
allowed to forgot the |
| 12:53.16 |
Defcon- |
everybody is
allowed to forgot the Prodigy once.. |
| 13:08.47 |
brlquestions |
hello again,
another question ... |
| 13:09.08 |
d-lo |
turns off the lights and hides. |
| 13:09.11 |
d-lo |
;) |
| 13:09.26 |
brlquestions |
is there some
way to sketch bezier passing closer to control points in BRL CAD
? |
| 13:11.32 |
brlquestions |
I converted
the whole sketch on a single closed bezier that renders well on
qcad after writing it by means of libdime |
| 13:12.01 |
brlquestions |
the problem
is that bezier primitive in BRLCAD's sketch API rounds my corners
too much ... |
| 13:12.21 |
brlquestions |
(sorry single
closed NURBS or whatever ...) |
| 13:25.47 |
d-lo |
brlquestions:
Gonna have to defer that to someone more knowledgeable than me :/
sorry! |
| 13:25.58 |
CIA-32 |
BRL-CAD:
03davidloman * r33651 10/rt^3/trunk/ (13 files in 5 dirs): Updated
NetMsg and subclasses to use DataStream. Updated
netMsgSerialTest. |
| 13:27.22 |
brlquestions |
OK, thanks
... suppose there's some representation problem dealing with
libdime specs, qcad NURBS splines and bezier primitive in
BRLCAD |
| 13:40.15 |
brlcad |
brlquestions:
you can always add more control points, but I suspect the issue eis
a translation problem |
| 13:42.51 |
brlcad |
either a
bezier getting imported as a sketch incorrectly via dxf-g
(remember, that is "brand new" code to bring in the 2D entities) or
an entity getting imported with params for the wrong type of curve
(like making a bspline as a bezier curve and vice
versa) |
| 13:43.56 |
*** join/#brlcad piksi (n=piksi@pi-xi.net) |
| 13:45.30 |
CIA-32 |
BRL-CAD:
03johnranderson * r33652 10/jbrlcad/trunk/ (14 files in 4 dirs):
Modifications to make jBrlcad compatible with other
projects |
| 13:48.44 |
brlcad |
our sketch
primitive really only supports bezier curves (though the logic for
also supporting nurbs curves is pretty much done too) |
| 13:50.50 |
brlcad |
so I guess
the question is what type of curve did you originally make with
libdime, what type of curve did you end up with in the sketch, and
how'd you go from dime to sketch |
| 14:03.01 |
``Erik |
*readreadread* if I had to use linux, I'd
probably go with ubuntu on the desktop and debian on the
server |
| 14:04.09 |
d-lo |
``Erik:
whyso? |
| 14:06.42 |
``Erik |
ubuntu has
decent package management and a fairly user interface focus, debian
historically has been extremely solid compared to other
leenewxes |
| 14:07.03 |
``Erik |
and both use
apt/dpkg instead of the rpm trainwreck :D |
| 14:07.42 |
``Erik |
hugs fbsd (and obsd on occasion) |
| 14:08.02 |
``Erik |
I need to
scrap together another machine to give solaris10 a
whirl |
| 14:08.07 |
d-lo |
Well, for me,
'RPM' has a place in my heart.... for neigh to 9 years, it stood
for Reactor Plant Manual... the bane of my existance
>8-( |
| 14:08.41 |
``Erik |
heh, 'redhat
package manager'.. 'really putrid muck', whatever :D |
| 14:09.22 |
``Erik |
it's far
easier to make an rpm than a dpkg, it's far easier to use a dpkg
than an rpm :D |
| 14:09.40 |
d-lo |
interesting.... |
| 14:09.47 |
``Erik |
im(ns)ho |
| 14:10.18 |
d-lo |
i figured I
would get a few nsho here, so its a good place to ask
;) |
| 14:10.29 |
d-lo |
brlcad: How
are those repairs going? |
| 14:13.03 |
brlquestions |
thank you
very much brlcad ... I have to learn a lot of three dee modeling
!!! thanks again for your help ! |
| 14:23.23 |
``Erik |
heh, for some
reason, my brain parsed /jbrlcad/trunk as "brlcad junk"
O.o |
| 14:23.40 |
d-lo |
jyou're just
not jused to speaking jjava speak ;) |
| 14:30.31 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:32.00 |
``Erik |
heh, 'jjava',
even brief periods of java development are so traumatic, you
develop uncontrollable stuttering? ;) |
| 14:32.48 |
d-lo |
jI don't
jknow what joo are jtalking about.... |
| 14:33.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-219.sbndin.btas.verizon.net) |
| 15:08.53 |
brlcad |
wanders about but won't be going to lunch |
| 15:08.54 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33653 10/brlcad/trunk/src/adrt/adrt.h: macro to
turn network opcodes into human readable names |
| 15:09.14 |
``Erik |
how very odd,
"svn commit file.h" failed, but "svn commit ./file.h"
succeeded |
| 15:09.25 |
brlcad |
serverage
funness |
| 15:09.33 |
brlcad |
probably
would have worked just a second time |
| 15:09.50 |
``Erik |
failed many
times in a row, tried removing and restoring the file, reapplying
the changes, same failure |
| 15:10.03 |
``Erik |
perhaps
smething about symlinks and nfs mounts confuzzled svn |
| 15:10.03 |
brlcad |
what was the
error? |
| 15:10.53 |
``Erik |
beh, lost the
backlog, was something about not being able to find
.svn/text-base/adrt.h.adrt.h.svn-base |
| 15:10.58 |
``Erik |
(which
existed) |
| 15:11.11 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 15:11.59 |
brlcad |
huh, that is
odd |
| 15:12.08 |
brlcad |
likes the nfs theory |
| 15:16.53 |
``Erik |
suddenly remembers why he had gtk installed on that machine.
*sigh* *compile* |
| 15:21.53 |
brlcad |
fwiw, not
going to lunch |
| 15:31.56 |
``Erik |
so I've heard
:D |
| 15:31.59 |
``Erik |
big
breakfast? |
| 15:32.18 |
brlcad |
no, just
busy |
| 15:32.46 |
``Erik |
aren't we
all? :D which'll happen first, release or migration? |
| 15:33.01 |
brlcad |
no,
definitely not all |
| 15:34.41 |
``Erik |
ah, gtk is
done compiling, autoreconf can now occur |
| 15:41.19 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33654 10/brlcad/trunk/src/adrt/libutil/: empty
dir |
| 15:49.24 |
CIA-32 |
BRL-CAD:
03bob1961 * r33655 10/brlcad/trunk/src/tclscripts/mged/ (font.tcl
openw.tcl): This fixes a bug that was breaking the font preferences
panel (i.e. it's init routine was not getting called if a .mgedrc
file was present). |
| 15:51.36 |
mafm |
hi |
| 15:51.44 |
d-lo |
hai mafm
! |
| 17:16.02 |
brlquestions |
Hello again
... what do you think about the possibility of using : |
| 17:16.06 |
brlquestions |
void |
| 17:16.06 |
brlquestions |
nurb_c_to_bezier(struct bu_list *clist,
struct edge_g_cnurb *crv) |
| 17:16.29 |
brlquestions |
in
nurb_bezier.c to change representation before sketch extrusion
... |
| 17:17.00 |
brlquestions |
where can I
find documentation about bu_list and edge_g_cnurb structures to use
it in my own code ... |
| 17:21.02 |
starseeker |
brlquestions:
best bet is probably the code itself |
| 17:21.16 |
starseeker |
not sure
there are any useful programmer docs for those routines |
| 17:22.02 |
brlquestions |
OK thanks
starseeker ... anyway you now where are those structs defined
? |
| 17:22.14 |
CIA-32 |
BRL-CAD:
03starseeker * r33656 10/brlcad/trunk/regress/mged_test.sh: Fix
couple minor issues in mged test script. |
| 17:23.11 |
starseeker |
check bu.h
and nmg.h in brlcad/include directory |
| 17:23.36 |
brlquestions |
ok thanks
again ! |
| 17:24.11 |
brlquestions |
that's it
include directory :) |
| 18:23.15 |
CIA-32 |
BRL-CAD:
03starseeker * r33657 10/brlcad/trunk/regress/mged_test.sh: Add
first tests of view commands |
| 18:29.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-219.sbndin.btas.verizon.net) |
| 18:33.02 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33658 10/brlcad/trunk/src/adrt/slave/slave.c:
fix up performance info (but leave disabled for now) |
| 18:38.07 |
CIA-32 |
BRL-CAD:
03starseeker * r33659 10/brlcad/trunk/regress/mged_test.sh: Add ae,
center and eye_pt tests |
| 18:38.43 |
CIA-32 |
BRL-CAD:
03davidloman * r33660 10/rt^3/trunk/ (7 files in 6 dirs): More
cleanup on DataStream, NetMsg & Subs, and
GeometryService |
| 18:50.37 |
CIA-32 |
BRL-CAD:
03davidloman * r33661 10/rt^3/trunk/src/tests/gsph0_Test.java:
Adding groundwork for a simple cross language test. |
| 19:31.25 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33662 10/brlcad/trunk/src/adrt/librender/cut.c:
use vmath.h |
| 19:32.04 |
brlcad |
mmm.. buzzing
with activity, nice |
| 19:33.11 |
brlcad |
that
conversion using the old brep routine might work, but the data
containers are wrong dimension (I think) |
| 19:33.32 |
brlcad |
I believe
that takes a nurbs surface and turns it into a set of bezier
patches |
| 19:34.14 |
brlcad |
which means
he's on the right track, and might be able to make that routine or
one similar work, but it'd be better to fix sketch nurbs curve
support |
| 19:34.50 |
d-lo |
buzzes. |
| 19:49.04 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33663
10/brlcad/trunk/src/adrt/librender/normal.c: use vmath |
| 19:49.07 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33664
10/brlcad/trunk/src/adrt/librender/phong.c: irrelevant structural
changes |
| 19:51.27 |
CIA-32 |
BRL-CAD:
03johnranderson * r33665
10/brlcad/trunk/src/librtserver/rtserver.c: Modified to use the
classes in jbrlcad |
| 19:52.30 |
brlcad |
you too? my
phone's been buzzing all day |
| 19:52.40 |
brlcad |
buzzes when a commit is made |
| 19:53.11 |
brlcad |
oh wow..
librtserver is no longer stand-alone |
| 19:53.11 |
brlcad |
hrm |
| 19:53.38 |
CIA-32 |
BRL-CAD:
03starseeker * r33666 10/brlcad/trunk/regress/mged_test.sh: Add a
few more view commands |
| 19:54.18 |
starseeker |
erm, wait a
minute - does that mean brlcad now depends on jbrlcad to
build?? |
| 19:58.25 |
``Erik |
only
librtserver |
| 19:58.38 |
``Erik |
which is a
JNI stub monstrosity |
| 19:59.24 |
starseeker |
right, but my
point is would a garden variety build hault on librtserver
now? |
| 20:00.12 |
``Erik |
uhm, I'd have
to look at the change, but I BELIEVE that the jni asks for classes
via strings, and he updated the classnames... so it should build
just fine, you just have to define the symbols to be able to
require it into a jvm |
| 20:01.57 |
``Erik |
yeah, he just
changed the values of some string constants to say
"org/brlcad/numerics" instead of
"mil/army/muvs/sim/math" |
| 20:01.59 |
brlcad |
starseeker:
yeah, no -- but you would have to have jbrlcad to *use*
librtserver |
| 20:02.15 |
starseeker |
ok |
| 20:02.17 |
``Erik |
(previously,
you needed MUVE-3 to use librtserver) |
| 20:03.23 |
brlcad |
it's a todo
item to update the src/java portions to be all org/brlcad if
they're not already |
| 20:03.39 |
brlcad |
dont' recall
if john did that already |
| 20:04.29 |
brlcad |
long-term,
it'll make sense to either merge in jbrlcad (if it's used a lot
more, or at least the pieces required by librtserver), or move
src/java over into jbrlcad |
| 20:04.49 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33667
10/brlcad/trunk/src/adrt/librender/component.c: minor formatting
and elimination of superfluous temporary variable |
| 20:05.12 |
brlcad |
shakes fist at not having a graphical console on
cad |
| 20:05.15 |
``Erik |
votes move to jbrlcad, so'z we can have a clbrlcad, pybrlcad,
etc :D |
| 20:05.28 |
brlcad |
heh |
| 20:05.50 |
brlcad |
have I ever
mentioned how much I hate language prefixes on project names?
:) |
| 20:05.54 |
starseeker |
clbrlcad -
for... mind bending designs :-) |
| 20:06.05 |
``Erik |
yeah, but
they do it |
| 20:06.23 |
brlcad |
geeks are
horrible at internalizing a name, using implementation to
name |
| 20:06.30 |
d-lo |
its l33t and
you know you like it. |
| 20:07.03 |
``Erik |
$ ls
~/src/macports/dports/python/py* | wc -l |
| 20:07.03 |
``Erik |
<PROTECTED> |
| 20:07.08 |
brlcad |
it's a long
winded bikeshed discussion on usability, branding, marketing, and
readability :) |
| 20:08.28 |
``Erik |
names suck :D
"wtf is a 'maven'? oh, you mean plwwwfm, I see" hehehe |
| 20:08.29 |
brlcad |
yeah, python
folks are some of the worst at it, php and java too |
| 20:08.52 |
``Erik |
'boost'? is
that an energy drink? :D |
| 20:09.18 |
brlcad |
maven's at
least a 'word' and can be pronounced fairly
unambiguously |
| 20:09.30 |
``Erik |
</smartass> time to ponder
code |
| 20:10.02 |
brlcad |
it only stops
mattering if your project gets so popular that the prefix is no
longer a prefix and it's a popularly recognized trademark on it's
own |
| 20:10.07 |
brlcad |
like
"jboss" |
| 20:10.59 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-219.sbndin.btas.verizon.net) |
| 20:11.03 |
brlcad |
stops ranting and returns to hammering on the
server |
| 20:11.57 |
d-lo |
It will
probably go quicker if you use jHammer, iHammer or
mcHammer. |
| 20:12.07 |
d-lo |
:D |
| 20:12.13 |
starseeker |
mcHammer is
overrated |
| 20:12.49 |
d-lo |
Especially
since 'You Can't Touch' it |
| 20:12.55 |
starseeker |
prefers the flexibility o cl-Hammer, the only hammer that can
hammer itself |
| 20:15.06 |
CIA-32 |
BRL-CAD:
03starseeker * r33668 10/brlcad/trunk/regress/mged_test.sh: Add
view version of sca to testing |
| 20:19.38 |
``Erik |
heh |
| 20:20.06 |
``Erik |
erHammer and
mlHammer can be fun |
| 20:20.39 |
``Erik |
(but clHammer
and scmHammer are the only ones that can deal with screws
elegantly) |
| 20:21.27 |
brlcad |
starseeker:
press isn't so much tied to the graphics as the graphics is tied to
press |
| 20:22.24 |
starseeker |
brlcad:
sorry, wasn't clear - trying to select an arb face to rotate
strictly from the command line doesn't seem to be workable even
with press |
| 20:22.27 |
brlcad |
press is a
very old command, so you could press buttons on the overlay menu
when you didn't have an input device |
| 20:22.54 |
brlcad |
if it's
doable from the gui, it should be doable on the command
line |
| 20:23.09 |
brlcad |
it's just
rather unexpected as to how it works |
| 20:23.40 |
starseeker |
after all the
pressing it pops up a GUI asking for a vertex to rotate around, and
press doesn't seem to hit the OK in the dialog |
| 20:23.44 |
brlcad |
like if you
wanted to select a face, it's something like: press "Edit Face
1234" |
| 20:24.08 |
brlcad |
sounds like
the wrong press string |
| 20:24.53 |
brlcad |
that pop-up
dialog would be something like CMD_MORE with typein where it
prompts if there is an incomplete action |
| 20:25.05 |
starseeker |
mutters under his breath about archane user interface
interaction techniques... |
| 20:25.29 |
brlcad |
it's a lot
more intuitive if you turn on faceplate mode |
| 20:25.37 |
starseeker |
brlcad:
ah |
| 20:25.46 |
brlcad |
the things
you can press and the strings you can specify are usually directly
spelled out there |
| 20:26.32 |
brlcad |
<PROTECTED> |
| 20:27.35 |
starseeker |
Is it worth
all that just for eqn in the context of arb rotation? |
| 20:28.27 |
starseeker |
I suppose
it's a more general issue for testing graphical mged functionality
in the end... |
| 20:28.41 |
brlcad |
it it worth
you understanding the details of how press works, probably
:) |
| 20:28.51 |
brlcad |
for eqn, of
course not |
| 20:29.01 |
starseeker |
growl... |
| 20:29.19 |
starseeker |
OK, I'll
figure it out once I'm done grabbing low hanging fruit for
testing |
| 20:29.46 |
brlcad |
that's a
common (simple) command that is very useful in many contexts
(particularly for users that want to script) |
| 20:29.56 |
starseeker |
wonders how to deal with testing the commands that flip up an
editor... |
| 20:30.15 |
brlcad |
'accept' and
'reject' for example are really just aliases for "press accept" and
"press reject" |
| 20:30.53 |
brlcad |
notes the sore lack of "apply" that would be good to have so
long as we have the modality |
| 20:31.19 |
brlcad |
starseeker:
set EDITOR to something scriptable |
| 20:31.25 |
starseeker |
wants reset to work in the editing context as well as press
reset, but supposes it conflicts with
something... |
| 20:31.26 |
brlcad |
like
'cat' |
| 20:31.29 |
starseeker |
heh |
| 20:31.38 |
brlcad |
"reset" is
also missing |
| 20:32.00 |
starseeker |
thought it was a libged bug at first when reset didn't
work... |
| 20:32.46 |
brlcad |
there are
other EDITOR tricks you can use -- just depends on the command
being tested |
| 20:34.34 |
starseeker |
wonders where the pink pen on his desk came
from... |
| 20:35.41 |
starseeker |
alright, time
for fizzy energy drink of some kind... |
| 20:37.01 |
brlcad |
mm. fizzy
blue bawls |
| 20:37.25 |
brlcad |
haven't had
that much caffeine in a long while |
| 20:55.05 |
CIA-32 |
BRL-CAD:
03davidloman * r33669 10/rt^3/trunk/src/ (3 files in 3 dirs): Minor
adjustments, bugfixes and tweaks. |
| 20:56.17 |
CIA-32 |
BRL-CAD:
03davidloman * r33670 10/rt^3/trunk/src/tests/ (. gsph0_Test.java
java/ java/gsph0_Test.java): Small directory organization change.
More work on the test for 'phase-0' GeometryServer. |
| 20:56.33 |
d-lo |
Whelp... cyas
all tomarrow. |
| 21:06.20 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D3BF.dip.t-dialin.net) |
| 21:07.43 |
brlcad |
dya
d-lo |
| 22:06.07 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33671 10/brlcad/trunk/src/adrt/slave/slave.c:
fix component view |
| 23:31.58 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-219.sbndin.btas.verizon.net) |
| 00:14.51 |
*** join/#brlcad BigAToo
(n=BigAToo@mail.fbcelkhart.org) |
| 00:48.20 |
mafm |
night |
| 03:38.39 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.196.139) |
| 04:32.14 |
brlcad |
sighs in relief as he settles down into his
chair |
| 04:35.13 |
yukonbob |
hello
cadheads |
| 06:58.02 |
brlcad |
waves and wanders |
| 07:00.15 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 07:18.17 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 07:49.34 |
brlcad |
howdy
Dr_Phreakenstein |
| 08:18.27 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-91-240.dclient.hispeed.ch) |
| 09:06.30 |
Dr_Phreakenstein |
hello
brlcad! |
| 10:04.34 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 11:47.52 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 11:47.52 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 12:02.40 |
d-lo |
yawns. |
| 12:02.54 |
d-lo |
Bitter cold
and snowy morning to all! |
| 12:03.22 |
archivist |
stop whining
about the snow :) |
| 12:03.59 |
d-lo |
Don't mind
the snow, its the nasty 30 mph wind that I don't like
:) |
| 12:04.04 |
alex_joni |
nice warm and
sunny here |
| 12:04.28 |
d-lo |
Really tested
the CCA on the Jeep's Battery this morning, lol. |
| 12:04.41 |
d-lo |
alex_joni:
Email me some 'warm and sunny' please! |
| 12:04.50 |
archivist |
press is over
dramatising the snow here in the UK |
| 12:05.50 |
d-lo |
archivist: I
take it that you too deal with, "ZOMG, 5cm of show... ITS THE END
OF THE WORLD!" ? |
| 12:06.21 |
archivist |
hehe
yea |
| 12:07.02 |
d-lo |
Last week, we
got a 'dusting'... seriously < 1mm snow... and they shutdown all
public and private schools for 2 hours.... |
| 12:07.06 |
archivist |
Ive offered
to go fetch a customer who was going to come today |
| 12:07.12 |
d-lo |
lol |
| 12:07.25 |
d-lo |
now *THATS*
customer service. |
| 12:07.44 |
Dr_Phreakenstein |
business must
be bad to need customers *that* much |
| 12:07.45 |
Dr_Phreakenstein |
;) |
| 12:07.46 |
archivist |
he was the
president of a car club, he is a wimp |
| 12:08.06 |
Dr_Phreakenstein |
now if he was
pres of 4wd club.. |
| 12:08.11 |
d-lo |
fancy shmancy
cars? |
| 12:08.14 |
Dr_Phreakenstein |
no problem
for him |
| 12:08.23 |
d-lo |
Dr_Phreakenstein: Exactly what I was
thinking. |
| 12:08.28 |
archivist |
hehe tha
would be funny, he does own a Freelander |
| 12:09.28 |
d-lo |
well, to be
fair, most (if not all) mainstream SUV's aren't designed to handle
any offroading any more :/ |
| 12:09.42 |
d-lo |
Landrover
probably has a better rep than most, but still. |
| 12:10.49 |
Dr_Phreakenstein |
true |
| 12:11.01 |
archivist |
takes some
snow to stop a Series 3 Landrover I had some fun years
ago |
| 12:11.42 |
Dr_Phreakenstein |
(Dr_Phreakenstein cannot remember seeing a
dirty SUV recently) |
| 12:11.55 |
archivist |
bent a wing
going flat out into a snow drift, we pulled it straight and carried
on |
| 12:12.43 |
Dr_Phreakenstein |
I remember
passing people in the snow, while driving my valiant with bald
tires, dead suspension |
| 12:12.59 |
Dr_Phreakenstein |
actual 4wd
and awd suvs |
| 12:13.04 |
d-lo |
for instance,
I come from a 'Jeep' family. My most recent Jeep is a '08
Patriot... a bit more 'smooth ride' than 'rough and tough', but
still a good car.... I took it on the small dirt/snow hills in my
housing development last week and had nearlyt all my neighbors
staring in awe. My thought is, "Its a Jeep silly, what did you
expect me to do with it?" |
| 12:13.19 |
Dr_Phreakenstein |
no
kidding |
| 12:13.20 |
*** join/#brlcad csanyipal
(n=csanyipa@25-144-85-95.dynamic.stcable.net) |
| 12:13.30 |
archivist |
yup go out
and enjoy |
| 12:13.52 |
csanyipal |
howdy |
| 12:13.56 |
Dr_Phreakenstein |
although, my
caravan has also proven off-road worthy |
| 12:13.57 |
csanyipal |
Howdy! |
| 12:14.00 |
Dr_Phreakenstein |
howdy! |
| 12:14.14 |
d-lo |
On a
different note, when ever I see a full size truck or nice SUV
'pimped out' with windows, rims and a stereo.... I get very
angry. |
| 12:14.30 |
Dr_Phreakenstein |
just gotta
watch out for that pesky ABS controller |
| 12:14.33 |
d-lo |
Howdy
csanyipal |
| 12:14.33 |
Dr_Phreakenstein |
yeah... |
| 12:14.41 |
Dr_Phreakenstein |
you cannot
put chains on those |
| 12:14.48 |
d-lo |
Caravan... as
in Dodge Caravan? |
| 12:14.52 |
Dr_Phreakenstein |
yup |
| 12:15.02 |
d-lo |
What year? I
love those vans :) |
| 12:15.07 |
Dr_Phreakenstein |
2000 |
| 12:15.14 |
Dr_Phreakenstein |
36.3
flex |
| 12:15.18 |
Dr_Phreakenstein |
3.3 |
| 12:15.30 |
d-lo |
Nice. We
have an '03 and I love how easy the maintenance is on the 3.3
:) |
| 12:15.41 |
Dr_Phreakenstein |
they are the
best |
| 12:15.56 |
Dr_Phreakenstein |
i will always
buy them, too easy to fix |
| 12:16.13 |
Dr_Phreakenstein |
as long as
you do not have to access rear cyl bank, as for plugs |
| 12:16.39 |
Dr_Phreakenstein |
i put some
100k mile bosch plugs on there, so no problem for a
while |
| 12:17.16 |
d-lo |
heh, well, I
draw the line maintenance like that. Too time intensive for me.
Easier to drop it off and wait a day while someone else deals with
that. |
| 12:17.36 |
Dr_Phreakenstein |
installed
class III hitch, HD shocks, prodigy electronic brake
controller |
| 12:17.49 |
d-lo |
Alternator,
belts, plugs, breaks.. (basically the easy stuff) is what I tend to
do myself. |
| 12:17.53 |
d-lo |
What do you
pull with it? |
| 12:18.04 |
Dr_Phreakenstein |
switch to
valvoline P/N vv935 oil |
| 12:18.23 |
Dr_Phreakenstein |
going to WA
to get some stuff from Grizzly |
| 12:18.39 |
d-lo |
Grizzly =
? |
| 12:18.40 |
Dr_Phreakenstein |
Milling
machine and sheet metal shear |
| 12:18.55 |
d-lo |
ah, Heavy
Metal :) |
| 12:19.07 |
Dr_Phreakenstein |
http://www.grizzly.com/products/9-x-32-Gear-Head-Mill-Drill-with-Stand/G0484 |
| 12:19.44 |
archivist |
expects EMC2 on it in a while |
| 12:20.04 |
d-lo |
Buy or
lease? |
| 12:20.17 |
Dr_Phreakenstein |
http://www.grizzly.com/products/52-16-Gauge-Foot-Shear/T20797 |
| 12:20.19 |
Dr_Phreakenstein |
buy |
| 12:20.30 |
d-lo |
nice, whats
the Price Tag on a bachine like that? |
| 12:20.35 |
Dr_Phreakenstein |
archivist
:) |
| 12:20.47 |
Dr_Phreakenstein |
shear,
1200 |
| 12:21.07 |
Dr_Phreakenstein |
mill
2000 |
| 12:21.09 |
d-lo |
nice 1/2 ton.
No problem! lol |
| 12:21.32 |
d-lo |
Use for
Business or hobby? |
| 12:21.37 |
Dr_Phreakenstein |
also some
small misc stuff, arbor press, tooling, etc |
| 12:21.44 |
Dr_Phreakenstein |
110 systems,
llc |
| 12:22.13 |
d-lo |
as in 110V
electricity? |
| 12:22.25 |
Dr_Phreakenstein |
actually, my
cousing has designed a cnc controller and software, so i will be
suing that |
| 12:22.39 |
Dr_Phreakenstein |
actually,
name was picked from when we did email |
| 12:22.43 |
Dr_Phreakenstein |
port
110 |
| 12:22.51 |
d-lo |
nice
:) |
| 12:22.58 |
Dr_Phreakenstein |
also 110
punchdown, as in low-volt wiring |
| 12:23.10 |
d-lo |
'cause I was
going to point out that the Mill Grill is 220V ;) |
| 12:23.22 |
Dr_Phreakenstein |
:) |
| 12:23.38 |
Dr_Phreakenstein |
yes, but that
is in lieu of 440 3 ph |
| 12:24.06 |
Dr_Phreakenstein |
the power
company will accept 3 easy payments of $5000 to hook it
up |
| 12:24.17 |
Dr_Phreakenstein |
220 is easier
to find |
| 12:24.29 |
Dr_Phreakenstein |
as in make my
wife wait to use the dryer |
| 12:24.54 |
d-lo |
is not a big fan of 440/450/480V.... took 500Vdc though the
heart when I was in the Navy.... I still get a bit shy when doing
ANY electrical work, lol. |
| 12:25.07 |
Dr_Phreakenstein |
fair
enough |
| 12:25.09 |
d-lo |
3 easy
payments eh? LOL. |
| 12:25.37 |
Dr_Phreakenstein |
oh, and that
only brings power to the bottom of the pole |
| 12:25.53 |
d-lo |
Start asking
around to see if anyone carries a 220V '6-strip' and see what kind
of looks you get :) |
| 12:25.53 |
Dr_Phreakenstein |
i still have
to dig trench, do panel, meter, etc in premise |
| 12:26.07 |
d-lo |
save cost...
don't install a meter :) |
| 12:26.18 |
Dr_Phreakenstein |
i like your
style |
| 12:26.39 |
Dr_Phreakenstein |
just get some
mueller alligator clips on the pole |
| 12:27.07 |
Dr_Phreakenstein |
(remember to
use fiberglass ladder for that job) |
| 12:27.40 |
d-lo |
Well, I *WAS*
going to suggest building a ghetto Current Transformer by looping
some insulated cable around the power lines :) You can claim that
they weren't using the Magnetic field anyways and that you are
'recycling' of sorts :) |
| 12:27.57 |
Dr_Phreakenstein |
hmmm.... |
| 12:28.02 |
Dr_Phreakenstein |
i have heard
of this |
| 12:28.38 |
Dr_Phreakenstein |
also, it
would give me a more reasonable voltage, albeit a little light on
the current |
| 12:29.11 |
d-lo |
I have done
it with 110V in the house... but it was more of a "Hrm, can I build
a Current Sensor with a wire and a Voltmeter" |
| 12:29.36 |
Dr_Phreakenstein |
the method
that i like is to get in as the prototype machine shop in a startup
company... free rent and electricity |
| 12:29.47 |
Dr_Phreakenstein |
i know 2
shops that do that |
| 12:30.15 |
d-lo |
Excellent
angle.... never thought about that. |
| 12:30.22 |
d-lo |
Nothing beats
free. |
| 12:30.29 |
Dr_Phreakenstein |
:) |
| 12:30.53 |
Dr_Phreakenstein |
found APC
UPSs at the local metal scrapper... |
| 12:31.02 |
Dr_Phreakenstein |
$12.50
apiece |
| 12:31.03 |
d-lo |
So, what kind
of products/services does your company provide? |
| 12:31.06 |
Dr_Phreakenstein |
1500
VA |
| 12:31.09 |
d-lo |
..still
functional? |
| 12:31.15 |
Dr_Phreakenstein |
what do you
need? |
| 12:31.22 |
Dr_Phreakenstein |
I have a
forklift for sale |
| 12:31.25 |
d-lo |
just
curious. |
| 12:31.25 |
Dr_Phreakenstein |
yes |
| 12:31.42 |
Dr_Phreakenstein |
got it at HP
machine shop auction |
| 12:31.43 |
d-lo |
lol, now the
wife would really hate me if I brought home a forklift.
lol |
| 12:31.59 |
Dr_Phreakenstein |
why do you
think I am selling mine |
| 12:32.00 |
Dr_Phreakenstein |
:) |
| 12:32.04 |
d-lo |
She grimaces
everytime I tell her I am swinging by Home Depot.... |
| 12:32.10 |
Dr_Phreakenstein |
lol |
| 12:32.17 |
Dr_Phreakenstein |
nice |
| 12:32.28 |
Dr_Phreakenstein |
we have an
industrial wholesaler here... |
| 12:32.49 |
d-lo |
I could
probably justify it by saying a forklist will facilitate moving the
furnature around easier.... (and make it MUCH more fun) |
| 12:32.53 |
d-lo |
hrm...... |
| 12:33.29 |
Dr_Phreakenstein |
I did not
know it would take so long, but my wife and kids waited an hour
while I bought nuts and bolts one day... in bulk it took them 35
minutes to ring me up |
| 12:33.42 |
Dr_Phreakenstein |
she may go
for a pallet jack |
| 12:33.50 |
d-lo |
bah, I am
saving for a Deck... can't swing a forklift right now
:( |
| 12:34.09 |
Dr_Phreakenstein |
then, when
that proves insufficient, you can justify the upgrade |
| 12:34.23 |
d-lo |
Personally, I
always thought one of those selfpropelled cherry pickers would be a
blast. |
| 12:34.24 |
Dr_Phreakenstein |
oh, but i can
sell it so cheap! |
| 12:34.27 |
d-lo |
lol |
| 12:34.33 |
Dr_Phreakenstein |
they
are |
| 12:34.41 |
Dr_Phreakenstein |
careful not
to tip |
| 12:34.50 |
d-lo |
shipping
would be a bitch though :) You're West Coast USA? |
| 12:34.58 |
Dr_Phreakenstein |
oregon,
yes |
| 12:35.19 |
Dr_Phreakenstein |
it is on my
dad's truck right now, I could swing by your location |
| 12:35.21 |
d-lo |
wonders if there is a Guiness Record for driving
cross-country in a forklift.... |
| 12:35.27 |
Dr_Phreakenstein |
:) |
| 12:35.46 |
Dr_Phreakenstein |
um, with it's
electric battery, not sure about that one |
| 12:36.12 |
d-lo |
Solar panels
and craftsman gennies baby... yeah! |
| 12:36.20 |
Dr_Phreakenstein |
hey, but you
could make a wicked UPS with a 24 v, 1120 AH battery |
| 12:37.03 |
Dr_Phreakenstein |
that sounds
efficient as can be |
| 12:37.34 |
d-lo |
UPS's are
only good to hold the line voltage and current whilst the 'ballsy
Diesel' back up gennie fires up on UV start :) |
| 12:38.02 |
d-lo |
I *almost*
have my wife sold on a multi-fuel back up gennie for the
house. |
| 12:38.03 |
Dr_Phreakenstein |
yes, but this
could hold line voltage for your neighborhood |
| 12:38.05 |
d-lo |
..almost. |
| 12:38.21 |
Dr_Phreakenstein |
hmmm |
| 12:38.29 |
d-lo |
I figure, 1
or 2 more sustaned power outtages will sway her. |
| 12:38.44 |
Dr_Phreakenstein |
tell her you
will bury it underground to make it quieter |
| 12:38.52 |
Dr_Phreakenstein |
that can be
arranged... |
| 12:38.52 |
d-lo |
lol |
| 12:38.54 |
Dr_Phreakenstein |
;) |
| 12:39.15 |
d-lo |
Oh, we are in
a new development, so the retarded 'low wage' workers knock out
power quite regularly. |
| 12:39.29 |
d-lo |
I laugh
heartly every time it happens. |
| 12:39.38 |
Dr_Phreakenstein |
nice |
| 12:40.27 |
d-lo |
its kind of
funny to look outside and see a 15 ton CAT front loader backed over
a transformer enclosure with 4 workers standing 50 ft away, just
staring. |
| 12:40.56 |
Dr_Phreakenstein |
...oops... |
| 12:41.26 |
d-lo |
Once i was
assured that no one got hurt, I just laughed and
laughed. |
| 12:41.49 |
Dr_Phreakenstein |
wonders if
that is as funny as seeing D-10 cat on it's side next to a HETT,
and an 88m doing pushups in the ditch |
| 12:42.11 |
d-lo |
lol |
| 12:42.58 |
Dr_Phreakenstein |
i sure
laughed (once I was out of earshot of her leadership, yes,
her) |
| 12:43.14 |
d-lo |
now thats
funny. |
| 12:43.52 |
Dr_Phreakenstein |
i even
returned to take a picture, but i could not get there until after
PT, and it was up by then |
| 12:44.06 |
d-lo |
I work with a
guy who was ex-Army, I forget his MOS, but his primary role was
HETT and HEMMIT(spelling?) mechanic.... oh man, the stories he
has... |
| 12:44.16 |
Dr_Phreakenstein |
2 88 wreckers
will lift anything in a hurry |
| 12:44.25 |
Dr_Phreakenstein |
HEMMT |
| 12:44.30 |
Dr_Phreakenstein |
i
bet |
| 12:44.36 |
d-lo |
righto,
thanks. |
| 12:44.46 |
Dr_Phreakenstein |
drove one
once |
| 12:45.03 |
d-lo |
I got used to
10 years of Navy acronyms and then switched up and joined the Army
as a civ.... whole new world lol. |
| 12:45.34 |
d-lo |
drove? I was
impressed enough with riding in one. |
| 12:45.56 |
Dr_Phreakenstein |
I was new to
army, and they needed people to drive vehicles onto a train car. so
they gave me a license for everything in the motorpool, minus
forklift |
| 12:46.17 |
Dr_Phreakenstein |
ironically, a
forklift was all that i had ever been trained on... |
| 12:46.40 |
Dr_Phreakenstein |
so, there was
this sea of armored vehicles... |
| 12:47.06 |
Dr_Phreakenstein |
I soon tired
of APCs and HMMWVs, so i tried other stuff |
| 12:47.15 |
d-lo |
my current
favorite military vehicle: |
| 12:47.21 |
d-lo |
http://patdollard.com/wp-content/uploads/land_mrap_img_maxxpro_cat-1_final_lg.jpg |
| 12:47.48 |
Dr_Phreakenstein |
Bradley...
88, HEMMT, LMTV, LMTV with tractor-trailer, and some other
stuff |
| 12:47.54 |
Dr_Phreakenstein |
nice |
| 12:48.25 |
Dr_Phreakenstein |
those are
nice to ride in, even nicer to drive |
| 12:48.36 |
Dr_Phreakenstein |
I am a big
International fan |
| 12:48.58 |
d-lo |
Of all the
Army vehicles, the IMG MAXXPRO is the only one I have a lot of
experience with... and me likes :) If I could get one for home, I
would. |
| 12:49.08 |
Dr_Phreakenstein |
actually, my
Yale forklift is sitting on a 1970 International Loadstar
1800 |
| 12:49.24 |
d-lo |
"Oh, so you
want to tailgate me? Let me just perform a brake
check." |
| 12:49.35 |
Dr_Phreakenstein |
the good ole
113 is kinda fun, if you have one in good shape |
| 12:49.56 |
d-lo |
bah, I need
to work now :/ |
| 12:50.01 |
Dr_Phreakenstein |
yeah, maxpro
stops alright |
| 12:50.09 |
Dr_Phreakenstein |
one more
thing |
| 12:50.42 |
Dr_Phreakenstein |
look into
installing sach's "nivomat" suspension in your van |
| 12:51.08 |
Dr_Phreakenstein |
you can get
it online for about 250 per shock (rear only) |
| 12:51.38 |
Dr_Phreakenstein |
wish i new
about it before getting those monroe shocks i got... not bad, but
self-levelling is the best |
| 12:51.50 |
d-lo |
nivomat
eh? |
| 12:51.52 |
Dr_Phreakenstein |
available
with factory tow package, too |
| 12:51.56 |
Dr_Phreakenstein |
yup |
| 12:51.56 |
d-lo |
I'll look it
up. |
| 12:52.11 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-91-240.dclient.hispeed.ch) |
| 12:52.26 |
Dr_Phreakenstein |
send me
phreak@110mail.com and i will send you p/n and links |
| 12:53.03 |
Dr_Phreakenstein |
i gotta
sleep. |
| 12:53.44 |
Dr_Phreakenstein |
gotta wake up
in 2 hrs for class, then install wiring for trailer and get up at 4
tomorrow for 6 hr drive to bellingham WA |
| 12:54.41 |
d-lo |
k, you sleep.
I'll ask the wife about the forklift :) |
| 12:54.43 |
d-lo |
lol |
| 12:55.41 |
Dr_Phreakenstein |
:) |
| 13:23.41 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 13:49.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-219.sbndin.btas.verizon.net) |
| 15:27.33 |
*** join/#brlcad Jose`
(i=43cd67c9@gateway/web/ajax/mibbit.com/x-238b78f97b453d81) |
| 15:27.40 |
Jose` |
WELL GOOD
MORNING EVERYBODY! |
| 15:27.53 |
Jose` |
I HAVE COME
TO SPREAD CHEERS! |
| 15:28.00 |
Jose` |
AND
PRESENTS! |
| 15:28.05 |
Jose` |
AND
CANDIES! |
| 15:28.26 |
Jose` |
BUTT FIRST
YOU MUST PAY THE FIDDLER!! |
| 15:28.34 |
Jose` |
THEN WE CAN
ALL HAVE BUTT SECKS |
| 15:28.47 |
Jose` |
YAY! |
| 15:28.52 |
Jose` |
<3 |
| 15:29.50 |
Jose` |
OOPS WRONG
CHANNEL SORRY ABOUT THAT :( |
| 15:29.51 |
*** mode/#brlcad [+b *!*@gateway/web] by
brlcad |
| 15:29.54 |
*** mode/#brlcad [+b *!*@gateway/web*] by
brlcad |
| 15:30.07 |
*** mode/#brlcad [-b *!*@gateway/web] by
brlcad |
| 15:35.49 |
``Erik |
heh |
| 15:36.33 |
``Erik |
should get himself one of these http://www.youtube.com/watch?v=ZDoy9S82ETA |
| 15:36.43 |
d-lo |
If it was the
wrong channel, why hasn't he left yet? |
| 15:37.19 |
d-lo |
``Erik: Wont
that *ensure* your ability to get to work on snow days? |
| 15:37.27 |
``Erik |
yes |
| 15:37.49 |
``Erik |
and any damn
other place I wanted to go |
| 15:37.50 |
``Erik |
:D |
| 15:37.57 |
d-lo |
lol |
| 15:38.09 |
``Erik |
"what? curb?
I didn't feel a curb, occifer" |
| 15:39.07 |
d-lo |
I wonder what
people would be thinking when they are coming out of Best Buy and
see that buggy parked on top of their car.... with you walking away
from it while enabling the car alarm... Chirp Chirp! |
| 15:39.32 |
``Erik |
heh, that'd
be awesome getting one of those up on 4 cars, one wheel on each
roof |
| 15:39.37 |
``Erik |
especially if
they were all suv's :D |
| 15:40.05 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E377.dip.t-dialin.net) |
| 15:40.11 |
d-lo |
lol |
| 15:40.36 |
*** join/#brlcad njan
(i=james@freenode/staff/njan) |
| 15:41.48 |
brlcad |
howdy
njan |
| 15:43.43 |
*** mode/#brlcad [-b *!*@gateway/web*] by
brlcad |
| 15:50.24 |
*** join/#brlcad Gary
(i=gary@freenode/staff/colchester-lug.gary) |
| 15:53.05 |
brlcad |
appreciated
but you guys are late ;) |
| 15:53.56 |
Gary |
ya,
sorry |
| 16:02.08 |
*** join/#brlcad samrose
(n=samrose@adsl-76-241-187-180.dsl.sfldmi.sbcglobal.net) |
| 16:23.15 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-219.sbndin.btas.verizon.net) |
| 16:32.17 |
*** part/#brlcad Gary
(i=gary@freenode/staff/colchester-lug.gary) |
| 16:47.04 |
CIA-32 |
BRL-CAD:
03starseeker * r33672
10/brlcad/trunk/regress/mged_test.sh: |
| 16:47.06 |
CIA-32 |
BRL-CAD: Add
in remainder of view manipulation commands on the Quick Reference
Card, put |
| 16:47.08 |
CIA-32 |
BRL-CAD:
cleanup rm command at end for temp files, clear results files when
running |
| 16:47.10 |
CIA-32 |
BRL-CAD:
again. The overlay command segfaults when the attempt is made to
run it from |
| 16:47.12 |
CIA-32 |
BRL-CAD: the
script (works interactively) so commented out for now. |
| 16:53.34 |
brlcad |
cool |
| 17:08.39 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 17:47.21 |
CIA-32 |
BRL-CAD:
03homovulgaris * r33673 10/brlcad/trunk/src/libpc/ (Makefile.am
pcMathGrammar.h pcMathLF.h): Adding Lazy Function header file for
the Math VM |
| 17:57.53 |
``Erik |
o'sake wa
sugoii ii desu. |
| 18:06.26 |
*** join/#brlcad samrose
(n=samrose@adsl-76-241-187-180.dsl.sfldmi.sbcglobal.net) |
| 18:26.11 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:44.12 |
CIA-32 |
BRL-CAD:
03homovulgaris * r33674 10/brlcad/trunk/src/libpc/ (pcMathGrammar.h
pcMathLF.h): Definition of lazy functions and beginning to
elaborate ExpressionGrammar |
| 18:53.34 |
CIA-32 |
BRL-CAD:
03starseeker * r33675 10/brlcad/trunk/regress/mged_test.sh: Add
remainder of displaying geometry commands from Quick Reference Card
(with the exception of the geometry browser, which will require
some thought). |
| 18:55.26 |
starseeker |
if nothing
else, this sucker is great practice with vim |
| 19:06.22 |
*** part/#brlcad njan
(i=james@freenode/staff/njan) |
| 19:21.09 |
CIA-32 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1207 10/wiki/NewSessionREQOK: /* Byte Format */ |
| 19:31.58 |
CIA-32 |
BRL-CAD:
03bob1961 * r33676 10/brlcad/trunk/src/mged/setup.c: |
| 19:32.00 |
CIA-32 |
BRL-CAD: For
now, the arb and bev commands are being called via
cmd_ged_plain_wrapper. |
| 19:32.02 |
CIA-32 |
BRL-CAD:
cmd_ged_edit_wrapper was being used previously and was trying to
draw the newly |
| 19:32.04 |
CIA-32 |
BRL-CAD:
created object, assuming that it was the last parameter. Will have
to come up |
| 19:32.06 |
CIA-32 |
BRL-CAD: with
something else later (i.e. no time at the moment). |
| 19:38.50 |
CIA-32 |
BRL-CAD:
03starseeker * r33677 10/brlcad/trunk/regress/mged_test.sh: Add
tests for kill commands on Quick Reference Card |
| 19:42.46 |
d-lo |
heh, looks
like that media wiki CIA addon works :) |
| 20:20.31 |
CIA-32 |
BRL-CAD:
03davidloman * r33678 10/rt^3/trunk/src/ (4 files in 3 dirs):
Continuing work for gsph0. gsph0 now communicating with gsph0_test
during Hostname exchange and new session request. |
| 20:23.38 |
CIA-32 |
BRL-CAD:
03davidloman * r33679 10/rt^3/trunk/src/tests/java/ (8 files):
Continuing work for gsph0_Test. gsph0_Test now communicating with
gsph0 during Hostname exchange and new session request. |
| 20:24.58 |
CIA-32 |
BRL-CAD:
03davidloman * r33680 10/rt^3/trunk/src/iBME/testing.g: Simple
example .g for file transfer testing. |
| 20:26.52 |
``Erik |
brlcad,
*ping* |
| 20:33.01 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r33681 10/brlcad/trunk/src/adrt/librender/cut.c:
darwin doesn't seem to like pointers to stack addresses in library
functions being dereferenced, so malloc() (and free) the cutter
geometry (fixes bus fault). |
| 20:55.12 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-228.dclient.hispeed.ch) |
| 22:14.57 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E377.dip.t-dialin.net) |
| 22:26.40 |
brlcad |
``Erik:
points to stack data should be just fine on darwin -- perhaps stack
corruption |
| 22:48.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 23:18.33 |
``Erik |
hrm, it's two
function calls that don't do jack iwth the stack, when I put it
through the debugger, it looks like a reasonable address (and
consistant) |
| 23:18.59 |
``Erik |
and it's a
bus fault, not a seg fault, which is odd in itself |
| 23:19.30 |
brlcad |
mm |
| 23:19.33 |
brlcad |
i still don't
buy it |
| 23:19.46 |
``Erik |
*shrug* that
change made the problem go away, mebbe I'll explore it a bit
later |
| 23:19.54 |
brlcad |
those are
simple floats in an array on the stack |
| 23:20.23 |
``Erik |
yeah, with a
few levels of indirection in the mix... it sees into the first
pointer ok, btu the second is inaccessable |
| 23:20.32 |
starseeker |
brlcad:
should I incorporate the existing mged regression testing into what
I'm doing or do you want to keep it as its own routine? |
| 23:20.39 |
brlcad |
there should
be no problem passing around pointers to that -- maybe somewhere it
gets cast to the wrong pointer type, like a bad double/triple
pointer cast |
| 23:20.43 |
``Erik |
I d'no, if I
decide to think about it, mebbe I'll revert it and step through
it |
| 23:20.55 |
brlcad |
that'd be
something that might turn out fine on some environments |
| 23:21.07 |
brlcad |
depending on
the alignment |
| 23:21.17 |
``Erik |
given that it
uses the same type everywhere along the path, and it's nicely
aligned, I 'dno about that |
| 23:21.36 |
brlcad |
starseeker:
what are you doing? |
| 23:21.38 |
``Erik |
unless
there're some funky compile option differences between the various
libs |
| 23:22.13 |
``Erik |
if I think
about it between now and tomorrow, I'll try stepping it to see
what's up *shrug* |
| 23:22.21 |
brlcad |
*shrug* |
| 23:22.28 |
brlcad |
looked like
it was during prep, so not a big issue |
| 23:22.34 |
``Erik |
yup |
| 23:22.35 |
starseeker |
brlcad: The
mged/libged regression testing - should I just suck the stuff you
did to test mged command functionality into one big mged test, or
did you want to retain your routine as a separate
entity? |
| 23:22.37 |
brlcad |
but just
don't think it's a darwin thing |
| 23:22.49 |
``Erik |
that's the
only place it exhibited itself |
| 23:23.03 |
brlcad |
starseeker:
AH, the "other" existing mged regression testing |
| 23:23.07 |
starseeker |
right |
| 23:23.31 |
brlcad |
nah, leave it
alone unless you have a compelling reason to join them |
| 23:23.43 |
starseeker |
ok. |
| 23:23.54 |
starseeker |
was just wanting to steal the mged.sh name
;-) |
| 23:23.56 |
brlcad |
the tests
don't need to be elegant, they're overhead code -- the less
maintenance the better |
| 23:24.34 |
brlcad |
whatever
suits your fancy then :) |
| 23:24.42 |
starseeker |
ok |
| 23:24.59 |
starseeker |
is thinking this will be ready to hook in in a few
days... |
| 23:25.13 |
starseeker |
assuming my
vim editing speed increases somewhat |
| 23:26.00 |
brlcad |
I'd be
inclined to make all those sections you have into individual files,
source them in and run a function or exec them directly |
| 23:26.35 |
brlcad |
just think
how fast you'd be by now if you had a powerful scriptable
environment at your fingertips with the same investment of effort
;) |
| 23:26.58 |
starseeker |
heh |
| 23:27.16 |
brlcad |
are the tests
looking grim or green? |
| 23:27.37 |
starseeker |
not too bad
so far - I haven't actually run a 7.12.6 benchmark in a
bit |
| 23:27.43 |
starseeker |
me relinks
and re-runs... |
| 23:28.07 |
brlcad |
gave bob time to tweak, releasing either tomorrow or
saturday |
| 23:28.31 |
brlcad |
going to
press really hard to keep to a release by the 7th |
| 23:28.32 |
starseeker |
he's squashed
a few bugs already - the make spewing errors was a
biggie |
| 23:31.00 |
starseeker |
nods |
| 23:36.51 |
starseeker |
auugh, why do
I get a bus error now |
| 23:42.28 |
yukonbob |
brlcad: plate
full of bugs? |
| 23:42.35 |
yukonbob |
s/bugs/tickets/ |
| 23:44.52 |
brlcad |
yukonbob:
yeah, there are too many tickets, none getting closed
out |
| 23:50.19 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 23:56.32 |
starseeker |
hmm, well
autoview, saveview, loadview, ps, and plot are now suddenly causing
bus errors |
| 00:03.59 |
starseeker |
hrm - looks
like a couple of the view input options are busted |
| 00:04.29 |
starseeker |
berates himself for using make instead of in to create test
primitives for other commands - default changes is messing up
comparisons |
| 00:04.41 |
starseeker |
guess I get
to go back and fix it |
| 00:05.29 |
starseeker |
don't get why
all of a sudden the saveview stuff is dead - it was working when I
initially tested it and that was against head... |
| 00:20.52 |
mafm |
night |
| 00:35.12 |
starseeker |
kill is being
somewhat less verbose as well |
| 00:37.56 |
starseeker |
erm. g_diff
bombs |
| 00:45.30 |
starseeker |
brlcad: Is
g_diff converting things to the same format as g2asc and doing the
diff on that? |
| 03:09.36 |
``Erik |
bombs on
what? |
| 03:09.55 |
``Erik |
I was just
dicking around in g_diff.. it does not do a g2asc, but it has
similar logic for human readable crap |
| 03:11.44 |
``Erik |
other than
that, the last 'real' modification was a little over a year ago by
daytona |
| 03:22.48 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-198-192.we.res.rr.com) |
| 03:34.12 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 03:55.55 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 03:59.07 |
starseeker |
``Erik: on
the messy .g files generated by running mged_test.sh first on
7.12.6 and then on head |
| 04:11.15 |
*** join/#brlcad MinuteEl1ctron
(n=MinuteEl@bz.bzflag.bz) |
| 04:14.58 |
*** join/#brlcad CIA-40
(n=CIA@208.69.182.149) |
| 04:28.48 |
``Erik |
g_diff's
natural behavior is to compare straight up in mem rep |
| 04:29.18 |
``Erik |
it acutally
compares the binary csg tree for combs iirc |
| 04:29.48 |
``Erik |
and then
produces text acceptable as mged input in 'mged/machine'
mode |
| 04:30.22 |
``Erik |
my hack was
to wait until after those were done, then do substring searching on
the output strings... horribly hackish, boggled I haven't been
yelled at for it :D |
| 04:32.29 |
``Erik |
hates when people with no appreciable ability in math make
absolute statements about the output of certain mathematical
statements |
| 04:35.02 |
``Erik |
23k base
health, more like 31k buffed, do the numbers, the 'big bad guy' can
do up to 13k damage a whack on me, but this fucker claims I'd be
one-shotted |
| 04:35.22 |
``Erik |
tries to figure out how 13k > 31k, thinks he could stay
standing 2 hits without a damn heal |
| 04:35.24 |
``Erik |
*grouse* |
| 04:37.33 |
``Erik |
</nerd> |
| 04:39.07 |
``Erik |
wouldn't mind seeing g2asc's core logic moved into librt, and
g_diff's output actually using those lib-ized
functions |
| 04:39.40 |
``Erik |
It hink g2asc
and asc2g need their per-primitive logic worked into the primitive
files |
| 04:39.57 |
``Erik |
the v5 i/o is
essentially complicated swizzling |
| 04:40.08 |
``Erik |
why not have
the ascii rep in there as well? |
| 04:52.41 |
brlcad |
starseeker:
no, it doesn't convert to asc and compare, it compares object to
object in order, attribute by attribute |
| 04:54.24 |
brlcad |
and yeah,
what ``Erik said |
| 05:02.41 |
``Erik |
brlcad: is
migration low priority now? |
| 05:11.06 |
brlcad |
nope, just
stalled by the other migration |
| 05:11.25 |
brlcad |
car filled
with 6 guys or so in a pimped out car just drove by the house,
stopped, backed up, were checking out the car |
| 05:11.32 |
brlcad |
geniunely
just interested in the car, but odd they new it was
mine |
| 05:11.41 |
brlcad |
yes, I will
be installing external video cameras at some point soon
:) |
| 05:13.34 |
``Erik |
on the
upside, a very noticable car is far less likely to be chop shop
meat |
| 05:16.31 |
``Erik |
<--
grumbles some at the suv that cut him of on post and he ended up
passing about 12 miles later, should paint his car fucktard orange
to not blend in or something :D *duck* |
| 05:17.56 |
``Erik |
oh, btw, saw
another hidden cop, dark green or dark blue dodge dakota pickup
(salt and bright flashing lights made it hard to
distinguish) |
| 05:19.02 |
``Erik |
tagged
someone on 22 just east of the jeep dealership |
| 05:42.48 |
brlcad |
would rather be a fucktard if that means smiling every
goddamn time I look at my car, get in the car, drive the car
.. |
| 05:43.14 |
brlcad |
blending is
dulling |
| 05:43.16 |
Dr_Phreakenstein |
:) |
| 06:17.12 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 06:35.43 |
starseeker |
brlcad: is
there a good way to direct MGED output to a file at the tcl
level? |
| 06:37.01 |
brlcad |
erhm |
| 06:37.14 |
starseeker |
is studying output_hook... |
| 06:37.22 |
brlcad |
it depends,
but yeah, you can generally redirect any output for any command
just like the shell |
| 06:37.35 |
brlcad |
many commands
have built-in support |
| 06:38.06 |
starseeker |
using ">"
and ">>"? |
| 06:38.09 |
brlcad |
it's a little
tricky with our commands for some of them since many of them "do
their own thing" on the C side |
| 06:38.15 |
brlcad |
nopes |
| 06:41.00 |
brlcad |
if it's a
command that just returns a value that is printed, you can capture
that to a file very simply |
| 06:41.25 |
brlcad |
set fd [open
whatever w] ; puts $fd [your command here] ; close $fd |
| 06:42.10 |
brlcad |
if your
command calls puts directly or manually writes to stdout/stderr,
then you'll have to reopen stdout/stderr |
| 06:44.08 |
starseeker |
hmm |
| 06:44.10 |
brlcad |
this is
pretty interesting by itself and is related, http://inferno.slug.org/cgi-bin/wiki?Redirecting_Stdout |
| 06:44.32 |
brlcad |
does the
stdout redirection |
| 06:45.24 |
starseeker |
hmm - what's
the license on that? |
| 06:47.34 |
brlcad |
don't know,
doesn't say (not that I'd be too worried for such a small public
snippet that isn't being promoted/used outside of regression
testing) |
| 06:47.38 |
yukonbob |
hi
nerds |
| 06:47.38 |
starseeker |
grr -
wildcards don't seem to work inside [] |
| 06:47.45 |
brlcad |
nope |
| 06:47.55 |
brlcad |
wildcards are
glob compat expansion |
| 06:47.57 |
yukonbob |
starseeker:
glob |
| 06:47.59 |
brlcad |
there is a
glob command |
| 06:48.36 |
starseeker |
glob expands
the file system |
| 06:48.47 |
starseeker |
wants it to list primitives |
| 06:48.51 |
brlcad |
starseeker:
another option is the exec command which does offer operator
redirection |
| 06:48.57 |
starseeker |
hmmm |
| 06:49.26 |
brlcad |
set ret [exec
script.tcl >& output] |
| 06:49.52 |
brlcad |
er, set ret
[exec tclsh script.tcl >& output] |
| 06:50.14 |
brlcad |
will kick off
a subprocess |
| 06:50.20 |
starseeker |
that might
work |
| 06:50.36 |
brlcad |
ret will of
course have the numeric exit status |
| 06:50.39 |
yukonbob |
one could
also build a completely new [brlputs] either at script or C
level... |
| 06:50.51 |
starseeker |
as you've
probably guessed, I'm exploring doing this regression thing from
the tcl side |
| 06:51.21 |
brlcad |
you have a
reasonable setup as it is |
| 06:52.08 |
starseeker |
it has at
least one major problem with extensive use of the make
command |
| 06:52.11 |
starseeker |
that was a
bad mistake |
| 06:52.24 |
starseeker |
also, a lot
of operations like tra should be tried on all the
primitives |
| 06:52.39 |
starseeker |
I've already
convinced tcl to do some rather intelligent things in that
department |
| 06:53.11 |
brlcad |
make just
exemplifies that problem I was telling you about, sensitivity of
the tests to changes |
| 06:53.15 |
starseeker |
of course, I
can kick off the individual scripts from sh, but I was thinking if
tcl was used all the way through we could also regression test on
Windows |
| 06:53.21 |
yukonbob |
starseeker:
are you using tcltest(n)? |
| 06:53.23 |
brlcad |
the tests are
going to be *highly* sensitive unless you make the comparisons
highly relaxed |
| 06:53.43 |
starseeker |
yukonbob:
never heard of it |
| 06:53.46 |
starseeker |
googles |
| 06:53.53 |
yukonbob |
man n tcltest
:) |
| 06:54.20 |
yukonbob |
(assuming
your tcl man pages are section n) |
| 06:54.26 |
brlcad |
yukonbob: a
great suggestion, maybe "round two" |
| 06:54.38 |
starseeker |
brlcad: Oh,
agreed - they'll be fragile. But that particular one (make)
incorporated a known problem into libged sensitive commands at a
time when we have to be especially concerned about their behavior -
just a brain dead move on my part |
| 06:54.56 |
brlcad |
starseeker:
nod |
| 06:55.07 |
brlcad |
so swap them
all out for in commands, and you're done :) |
| 06:55.24 |
brlcad |
except for
the make command, don't swap it out for in ;) |
| 06:55.59 |
starseeker |
sure - but
having to do that manually is a pain in the neck, and highlighted
how stupid I was to have so many manual instances of various
commands present in full verbosity anyway |
| 06:55.59 |
brlcad |
yukonbob:
have you used tcltest on a project before, example testsuite that
could be run somewhere? |
| 06:56.18 |
starseeker |
proc in_arb8
{cmdname {id_number ""} {extension ".s"}} {in [format %s_arb8%s%s
$cmdname $id_number $extension] arb8 10 -9 -8 10 -1 -8 10 -1 0 10
-9 0 3 -9 -8 3 -1 -8 3 -1 0 3 -9 0 } |
| 06:56.23 |
starseeker |
for
example |
| 06:57.23 |
starseeker |
as is, even
without integrating anything, I think we look like we're in fairly
good shape |
| 06:57.58 |
starseeker |
I don't have
full coverage yet, but have a lot of the critical ones |
| 06:58.44 |
brlcad |
good shape on
the testing side or on the results side |
| 06:58.50 |
starseeker |
results |
| 06:59.06 |
brlcad |
ah, great ..
so we can .. SHIP IT! |
| 06:59.13 |
starseeker |
most are due
to the make differences (or other arb changes) |
| 06:59.21 |
brlcad |
that would
make for a great dyslexic typo |
| 07:00.22 |
brlcad |
I'm actually
most concerned about outright crashes happening |
| 07:01.21 |
starseeker |
Well, aside
from autoview and saveview, loadview, ps, and plot antics I don't
think I hit anything that flat out crashed |
| 07:01.54 |
starseeker |
oh, and
overlay |
| 07:02.07 |
starseeker |
Bob knows
autoview is messed up |
| 07:02.16 |
starseeker |
the others
seem to be unhappy about being scripted |
| 07:05.07 |
starseeker |
anyway, sleep
- I'll forge on tomorrow |
| 07:05.26 |
starseeker |
getting a
better feel for how to do stuff in tcl, so that's probably
good |
| 07:06.30 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-239-200.dclient.hispeed.ch) |
| 07:06.40 |
starseeker |
brlcad,
yukonbob: thanks for the help |
| 07:06.47 |
starseeker |
appreciate it
:-) |
| 07:07.01 |
brlcad |
what's
autoview do wrong? |
| 07:07.11 |
starseeker |
it's not
doing much of anything |
| 07:07.15 |
brlcad |
hrm, quite a
few things use it |
| 07:07.49 |
brlcad |
okay, well
cya on the other side |
| 07:08.02 |
starseeker |
later
:-) |
| 07:15.59 |
yukonbob |
brlcad: I've
done -small- work with it... see Tcl itself for large test suite,
or sqlite |
| 07:16.25 |
yukonbob |
see also
dejagnu, which is tcl-based |
| 07:16.37 |
yukonbob |
^---- gcc
testsuite |
| 08:09.43 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
| 08:24.05 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-91-240.dclient.hispeed.ch) |
| 09:41.44 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 10:19.10 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:16.42 |
CIA-40 |
BRL-CAD:
03brlcad * r33682 10/brlcad/trunk/doc/deprecation.txt: apparently I
made it obsolete in 7.12.4 whilest consolidating and eliminating
globals |
| 13:01.10 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E645.dip.t-dialin.net) |
| 13:23.09 |
CIA-40 |
BRL-CAD:
03starseeker * r33683 10/brlcad/trunk/TODO: Add note in TODO about
tools to make life easier with springs/shocks/coils and
gears |
| 13:49.53 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 15:00.43 |
``Erik |
taps his foot and waits for release so he can begin
committing horrible atrocities |
| 15:01.43 |
``Erik |
(parse
however you like) |
| 15:02.15 |
``Erik |
I'm thinking
above shoving libtie into librt proper O.o |
| 15:05.30 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 15:18.53 |
CIA-40 |
BRL-CAD:
03starseeker * r33684 10/brlcad/trunk/regress/mged_test.sh: Replace
some of the makes with ins, comment out a few problematic
tests. |
| 15:22.18 |
brlcad |
``Erik: you
could make the release yourself, follow the HACKING guide
steps |
| 15:22.48 |
brlcad |
basically
just have to write some release notes, update the release number in
a couple places, sync to stable, and pass make
distcheck |
| 15:22.52 |
``Erik |
uhhhhh
*thinks of a way to dodge* waiting on starseekers mged test suite
results? :D |
| 15:23.24 |
``Erik |
has released auto* crap before, knows the routine, just
doesn't wanna do it :D dicking with code instead |
| 15:23.54 |
archivist |
watches him wriggle |
| 15:24.08 |
``Erik |
(that and the
machines I like have failed install/deinstall tests since the
tkhtml stuff, due to tea ... issues) |
| 15:24.10 |
``Erik |
:D |
| 15:24.26 |
``Erik |
yeah, well, I
think the wiggling just bought me the duty |
| 15:25.55 |
brlcad |
starseeker
seems willing |
| 15:38.04 |
``Erik |
yeah, he just
left my office, he's gonna head it up, *puts on pigtails and
freckles* an' ah halped! |
| 15:51.22 |
CIA-40 |
BRL-CAD:
03starseeker * r33685 10/brlcad/trunk/ (ChangeLog
include/conf/PATCH): Bump PATCH number, update
Changelog |
| 15:52.01 |
starseeker |
brlcad:
Given the updates coming to the TODO file, do you want me to do
anything with it now? |
| 15:52.08 |
brlcad |
nope |
| 15:52.11 |
starseeker |
k |
| 15:58.15 |
CIA-40 |
BRL-CAD:
03brlcad * r33686 10/brlcad/trunk/NEWS: (log message
trimmed) |
| 15:58.15 |
CIA-40 |
BRL-CAD:
spell out names for consistency unless they won't fit, items are
supposed to be |
| 15:58.15 |
CIA-40 |
BRL-CAD: in
stack-based chronological ordering with newest on top. so move up
eriks |
| 15:58.15 |
CIA-40 |
BRL-CAD:
(added a rough cut at an "evolutionary" capability to g_diff. This
attempts to |
| 15:58.15 |
CIA-40 |
BRL-CAD:
guess if a change to a region was a natural evolution or if the
region was |
| 15:58.18 |
CIA-40 |
BRL-CAD:
"reworked" in some significant fashion. Requested by lbutler.) and
expand (Base |
| 15:58.20 |
CIA-40 |
BRL-CAD: to
neck ratio in hyp should not be scaled with other parameters,
result is |
| 16:01.31 |
``Erik |
tries to remember AM_CONDITIONAL's
behavior |
| 16:03.49 |
CIA-40 |
BRL-CAD:
03brlcad * r33687 10/brlcad/trunk/NEWS: summary in preparation for
release 7.14.2; emphasize the importer and exporter changes noting
bot_dump, lens, dem-g, and the dxf-g 2d entity fix. |
| 16:06.23 |
brlcad |
AM_CONDITIONAL(VAR, [condition]) ==> if
condition evaluates to true, define/include VAR
sections |
| 16:06.56 |
``Erik |
yeah, but the
little details when you're in the guts is where I'm trynig to think
:D |
| 16:07.17 |
brlcad |
you mean the
condition? |
| 16:07.19 |
``Erik |
I think I
don't even need to do that, though, I think it was just a silly
oversight... testing |
| 16:07.36 |
brlcad |
rarely need
conditionals |
| 16:07.45 |
``Erik |
"if VAR", was
thinking I might need to undefined VAR in the .ac |
| 16:08.25 |
``Erik |
(--enable-all
on a machien without apache fop attempts to execute ":", trying to
make it smarter) |
| 16:08.26 |
brlcad |
usually
better to AC_SUBST so it can be toggled in the source |
| 16:08.33 |
brlcad |
ah
yes |
| 16:09.21 |
brlcad |
starseeker:
I'm done |
| 16:09.37 |
starseeker |
brlcad:
great, thanks! |
| 16:09.44 |
starseeker |
got builds
going on mac and linux now |
| 16:10.50 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33688 10/brlcad/trunk/configure.ac: do not build
PDF docs if apache FOP is not found. |
| 16:10.52 |
``Erik |
taps cia |
| 16:10.55 |
``Erik |
starseeker:
I'm done |
| 16:10.56 |
``Erik |
:D |
| 16:11.14 |
starseeker |
``Erik:
awesome, thanks! |
| 16:11.28 |
starseeker |
notes change to configure.ac and restarts
builds... |
| 16:12.35 |
``Erik |
since I've
probably broken things in horrible ways, I should flee to lunch...
:D |
| 16:12.46 |
starseeker |
heh |
| 16:13.25 |
starseeker |
might as well
- make distcheck will take a little while |
| 16:13.41 |
``Erik |
yeah, it
might even take until, oh, say, 1pm? |
| 16:13.50 |
starseeker |
heh |
| 16:14.44 |
brlcad |
starseeker,
you should be good to go to upload to sf.net as well -- see a
previous release for what goes into notes, changelog, and the
various file settings |
| 16:18.12 |
brlcad |
or ask,
whatever |
| 16:19.19 |
starseeker |
cool, I'll
take care of it |
| 16:19.25 |
starseeker |
has done it once before, IIRC |
| 16:20.47 |
CIA-40 |
BRL-CAD:
03davidloman * r33689 10/rt^3/trunk/src/tests/java/ (3 files):
Completion of gsph0_test. Now successfully handshakes, requests
geometry, receives geometry and logs off the gsph0. |
| 16:20.52 |
starseeker |
brlcad: You
get to do the website update (heh - we missed 7.14.0 on the
website. oops) |
| 16:23.24 |
CIA-40 |
BRL-CAD:
03davidloman * r33690 10/rt^3/trunk/ (8 files in 7 dirs):
Completion of gsph0. Now sucessfully handshakes, handles requests,
sends geometry and disconnects from gsph0_test. Boost::asio is
providing a segfault whenever a client disconnects, so that is the
next issue to tackle. |
| 16:27.22 |
starseeker |
brlcad: bty,
home come make extrude uses an empty sketch instead of some
default? |
| 16:27.28 |
starseeker |
er
s/home/how |
| 16:28.35 |
brlcad |
it's a lose
lose situation |
| 16:28.56 |
starseeker |
how
so? |
| 16:29.20 |
brlcad |
it used to
make a default and people complained that (of course) it was never
what they were modeling if they're actually creating something
new |
| 16:29.32 |
starseeker |
ah |
| 16:29.37 |
brlcad |
so to use
sketch, you always had to pop open the sketch editor |
| 16:29.46 |
brlcad |
and delete
everything |
| 16:29.51 |
brlcad |
every
time |
| 16:30.00 |
brlcad |
now it's an
empty pallete |
| 16:30.21 |
brlcad |
makes it
harder for quick testing, but for folks actually modeling, it's a
step less |
| 16:30.40 |
starseeker |
maybe we
should show a bounding box wireframe for the empty case or
something, so it doesn't look like a total falure |
| 16:30.54 |
starseeker |
OK, I can see
that |
| 16:31.31 |
starseeker |
we should be
able to draw the bb without the sketch |
| 16:31.55 |
brlcad |
what is the
bb of an empty sketch? :) |
| 16:32.18 |
starseeker |
no, the empty
extrude |
| 16:32.28 |
starseeker |
or rather, an
extrude with an empty sketcy |
| 16:32.32 |
starseeker |
sketch |
| 16:32.33 |
starseeker |
grr |
| 16:32.50 |
sketcy |
:D |
| 16:32.54 |
starseeker |
the extrude's
bounding box is not impacted by the contents o the sketch,
iirc |
| 16:33.03 |
sketcy |
d-lo |
| 16:33.04 |
starseeker |
:-P |
| 16:33.10 |
starseeker |
nice |
| 16:33.24 |
d-lo |
is an irssitard |
| 16:34.31 |
starseeker |
an empty
sketch will obviously have nothing to display, but an empty extrude
still defines a volume in which the extrusion will take
place |
| 16:34.49 |
brlcad |
it's an empty
volume |
| 16:35.08 |
brlcad |
it defines a
height |
| 16:35.11 |
brlcad |
so the "bb"
would be a line |
| 16:35.14 |
brlcad |
segment |
| 16:35.21 |
brlcad |
not very
intuitive/useful |
| 16:35.26 |
starseeker |
I thought
there were other vectors |
| 16:35.29 |
starseeker |
looks again |
| 16:35.33 |
brlcad |
those are
scaling parameters |
| 16:35.42 |
brlcad |
not absolute
values |
| 16:35.45 |
starseeker |
ah,
phooy |
| 16:35.50 |
brlcad |
multiply by
the scaling and you got zero |
| 16:36.07 |
starseeker |
thought the sketch was scaled to fit within absolute 3D
boundaries |
| 16:36.09 |
starseeker |
my
bad |
| 16:36.17 |
brlcad |
hm |
| 16:36.20 |
brlcad |
well
double-check it |
| 16:36.33 |
starseeker |
if it isn't
it should be ;-) |
| 16:37.44 |
brlcad |
the confusion
there might be the inconsistency, showing the wireframe bounding
box that renders nothing where normally that would be .. a
box |
| 16:37.51 |
brlcad |
and
conceivably could be a sketch that is just a box |
| 16:38.13 |
starseeker |
true - maybe
use dotted lines or some other non-traditional outline? |
| 16:38.27 |
starseeker |
could use it
for all bounding volumes, come to think of it |
| 16:39.04 |
brlcad |
it's
presently all neatly abstracted |
| 16:39.26 |
brlcad |
wireframe
render just asks the primitives for their segment list and draws
them |
| 16:39.52 |
brlcad |
if it's
drawing a combination, it draws subtractions with a dashed
line |
| 16:40.04 |
brlcad |
the primitive
doesn't have a way to say "this is just my bounding
box" |
| 16:40.32 |
starseeker |
hmm -
pity |
| 16:41.03 |
brlcad |
what you
could do, though, once BB creation is separated from prep() would
be to change wireframe render to display a BB (with whatever visual
annotation) using the bb routine if the segment list was
empty() |
| 16:41.16 |
brlcad |
could have
another mode that displayed all bounding boxes.. that'd be
cool |
| 16:46.25 |
starseeker |
uh - got a
failure - MISSING FROM DIST: ./src/mged/red.c |
| 16:46.31 |
starseeker |
what
the |
| 16:46.40 |
starseeker |
is that file
new? |
| 16:47.40 |
starseeker |
investigates |
| 16:51.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 17:01.38 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 17:14.05 |
starseeker |
blinks - the red.c error did NOT occur on
OSX |
| 17:15.34 |
CIA-40 |
BRL-CAD:
03starseeker * r33691 10/brlcad/trunk/src/mged/Makefile.am: Put
red.c in EXTRA_DIST to make distcheck happy. |
| 17:24.37 |
starseeker |
brlcad: I
recall you finding a "right" way to sync to stable that didn't
involve blowing it away - what was the trick? |
| 17:57.36 |
brlcad |
using the
right command |
| 17:57.54 |
brlcad |
and right
options |
| 17:58.40 |
brlcad |
I believe I
put an example in a commit log message |
| 18:00.31 |
starseeker |
ok. Is there
a way in tcl to direct stderr to stdout the way the 2>&1
trick does in sh? |
| 18:00.52 |
brlcad |
>& |
| 18:01.09 |
starseeker |
thanks |
| 18:01.29 |
brlcad |
"man n exec"
lists all the combinations |
| 18:15.55 |
starseeker |
wonders how the sh logic looking for the mged path can be
recreated... hmm... |
| 18:31.00 |
starseeker |
brlcad: If
you did comment on the svn options I'm not seeing it in the STABLE
merge commits |
| 18:38.16 |
starseeker |
ok, both make
distchecks passed - starting the STABLE merge (gulp) |
| 18:43.41 |
CIA-40 |
BRL-CAD:
03starseeker * r33692 10/brlcad/tags/rel-7-14-2/: Tag 7.14.2
Release |
| 18:44.42 |
starseeker |
that was some
strange password stuff it wanted |
| 19:18.24 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 19:39.19 |
brlcad |
starseeker:
that doesn't look right.. |
| 19:39.41 |
brlcad |
tag should be
off of STABLE *after* the merge is complete and
committed |
| 19:39.53 |
starseeker |
crud |
| 19:40.00 |
starseeker |
then HACKING
is wrong |
| 19:40.11 |
brlcad |
not a big
deal, but fyi for future |
| 19:40.16 |
starseeker |
k |
| 19:40.22 |
brlcad |
hacking
doesn't know about stable |
| 19:40.27 |
starseeker |
grr |
| 19:40.47 |
starseeker |
syncing up
STABLE is being a major pita again |
| 19:41.22 |
brlcad |
what is your
merge line? |
| 19:41.44 |
starseeker |
svn merge -r
33115:HEAD https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk |
| 19:41.52 |
starseeker |
I'm doing it
by subdirectories now with better luck |
| 19:42.04 |
brlcad |
did you find
the commit? |
| 19:42.14 |
brlcad |
I vaguely
recall that being the problem |
| 19:42.16 |
starseeker |
the one with
your comment? no |
| 19:42.54 |
brlcad |
it's starting
to come back to me.. |
| 19:48.02 |
starseeker |
I'm thinking
the header updates are partially clogging it |
| 19:48.12 |
starseeker |
it means a
change for virtually every file |
| 19:48.32 |
brlcad |
which implies
something is wrong with the merge line |
| 19:48.36 |
brlcad |
that should
be a clean merge |
| 19:49.57 |
starseeker |
my connection
keeps timing out |
| 19:54.50 |
brlcad |
starseeker:
try form 1 for svn merge |
| 19:54.56 |
brlcad |
instead of
three |
| 19:56.04 |
starseeker |
form
1? |
| 19:56.13 |
brlcad |
svn help
merge, the first one |
| 19:56.26 |
brlcad |
and be
specific on all three optional parts |
| 19:56.43 |
brlcad |
even if it's
the 'default' |
| 19:58.13 |
brlcad |
i vaguely
recall the screwup having something to do with not specifying the
from/to explicitly |
| 19:59.45 |
starseeker |
it doesn't
like
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/branches/STABLE@33115 |
| 19:59.54 |
starseeker |
syntax
error |
| 20:00.15 |
brlcad |
plus, the
last merge point was r33207 |
| 20:00.33 |
brlcad |
that's not a
valid revision on STABLE |
| 20:00.45 |
brlcad |
hm!(lightbulb) |
| 20:00.50 |
brlcad |
that could
cause it |
| 20:01.04 |
brlcad |
not valid so
it defaults to BASE .. which would be a conflict |
| 20:01.25 |
brlcad |
(guessing) |
| 20:01.46 |
starseeker |
it's a syntax
error though, not a revision # error |
| 20:02.50 |
starseeker |
oh,
duh |
| 20:03.55 |
starseeker |
removes stray -r |
| 20:04.09 |
starseeker |
OK, I'm gonna
grab lunch while that runs |
| 20:05.24 |
brlcad |
hopes that's a fresh working copy, else it'll still be
conflicted |
| 20:12.02 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 20:30.28 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-198.dclient.hispeed.ch) |
| 20:32.55 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 21:01.21 |
starseeker |
brlcad:
still getting the blasted timeout failures |
| 21:19.40 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 21:53.53 |
CIA-40 |
BRL-CAD:
03starseeker * r33693 10/brlcad/branches/STABLE/ (142 files in 10
dirs): Merge 7.14.2 into STABLE branch - part 1 |
| 21:55.59 |
CIA-40 |
BRL-CAD:
03starseeker * r33694 10/brlcad/branches/STABLE/ (75 files in 25
dirs): Merge 7.14.2 into STABLE branch - part 2 |
| 21:56.24 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 21:58.34 |
CIA-40 |
BRL-CAD:
03starseeker * r33695 10/brlcad/branches/STABLE/src/ (204 files in
29 dirs): Merge 7.14.2 into STABLE branch - part 3 |
| 22:03.08 |
CIA-40 |
BRL-CAD:
03starseeker * r33696 10/brlcad/branches/STABLE/src/ (374 files in
21 dirs): Merge 7.14.2 into STABLE branch - part 4 |
| 22:03.43 |
brlcad |
heh |
| 22:04.15 |
starseeker |
shakes fist at connection, but at least it
merged |
| 22:04.18 |
brlcad |
any better
luck on the merge? |
| 22:04.19 |
starseeker |
thanks brlcad
for that command |
| 22:04.22 |
starseeker |
yep |
| 22:04.27 |
brlcad |
cool |
| 22:04.37 |
brlcad |
in hindsight,
I suspect it maybe was just the revision being used |
| 22:04.45 |
brlcad |
either that
or lack of explicit . |
| 22:04.52 |
starseeker |
I think lack
of explicit |
| 22:05.04 |
starseeker |
will stick that in hacking for next time |
| 22:05.21 |
starseeker |
expected better of subversion, but oh well |
| 22:09.08 |
starseeker |
brlcad: I'm
updating HACKING to include stable |
| 22:10.59 |
louipc |
wow |
| 22:17.28 |
CIA-40 |
BRL-CAD:
03starseeker * r33697 10/brlcad/branches/STABLE/src/ (709 files in
57 dirs): Merge 7.14.2 into STABLE branch - part 5 |
| 22:18.29 |
starseeker |
brlcad: Any
idea how to enable "test.s*" matching of database objects in a .g
file instead of files on the filesystem from tcl? |
| 22:32.12 |
CIA-40 |
BRL-CAD:
03starseeker * r33698 10/brlcad/branches/STABLE/src/ (320 files in
15 dirs): Merge 7.14.2 into STABLE branch - part 6 |
| 22:32.29 |
CIA-40 |
BRL-CAD:
03starseeker * r33699 10/brlcad/branches/STABLE/src/ (512 files in
21 dirs): Merge 7.14.2 into STABLE branch - part 7 |
| 22:32.41 |
CIA-40 |
BRL-CAD:
03starseeker * r33700 10/brlcad/branches/STABLE/ (12 files): Merge
7.14.2 into STABLE branch - part 8 |
| 22:32.44 |
starseeker |
phew |
| 22:32.53 |
starseeker |
hopes that has got it |
| 22:37.03 |
starseeker |
brlcad: i've
gotta run - i can do the pulls on the tagged release and stable
later to follow up, as well as uploading the tarballs, or you can
take it from here |
| 22:37.08 |
starseeker |
whoever gets
to it first? |
| 22:42.05 |
CIA-40 |
BRL-CAD:
03starseeker * r33701 10/brlcad/trunk/HACKING: Correct HACKING to
take into account the updating of STABLE - tagging should actually
happen from stable branch, not from trunk itself. |
| 22:44.23 |
CIA-40 |
BRL-CAD:
03starseeker * r33703 10/brlcad/trunk/regress/mged/.mged.tcl.swp:
oops, don't want the swap file |
| 22:44.32 |
CIA-40 |
BRL-CAD:
03starseeker * r33702 10/brlcad/trunk/regress/mged/ (17 files): Put
in early versions of tcl based regression tests, using individual
files per-command and using looping logic and procs to make things
easier to manage. Early test code, feasibility study. |
| 22:44.50 |
*** join/#brlcad ruskie
(i=ruskie@sourcemage/mage/ruskie) |
| 23:19.01 |
``Erik |
weird |
| 23:55.38 |
starseeker |
``Erik:
what? |
| 00:04.36 |
brlcad |
starseeker:
just caught one of the first commits from today -- the
*_LIBRARY_PATH foo you're using won't work |
| 00:04.53 |
starseeker |
hmm.
OK |
| 00:04.56 |
brlcad |
those are
read by the linker before/while a binary is being
loaded |
| 00:05.18 |
starseeker |
was basing it off the sh scripts |
| 00:05.28 |
brlcad |
if you're
running the tclsh that got you to those set env()'s then you're not
on a platform/environment that needed them set in the first
place |
| 00:05.39 |
brlcad |
yep, they set
it *before* the binary is called |
| 00:05.57 |
starseeker |
I thought I
was too |
| 00:06.00 |
starseeker |
looks again |
| 00:06.15 |
brlcad |
I'm looking
at tcl code.. |
| 00:06.23 |
brlcad |
if it's
running tcl code, then it doesn't matter |
| 00:06.32 |
starseeker |
oh,
point |
| 00:06.33 |
brlcad |
because tclsh
is running |
| 00:06.36 |
starseeker |
k |
| 00:06.44 |
brlcad |
ld is done
with its job |
| 00:07.09 |
brlcad |
there is an
old hack you can use, though -- a script that doubles as both a
shell and tcl script -- old trick |
| 00:08.06 |
brlcad |
look at
src/tclscripts/ami.tcl to see an example -- it's a shell script
that can be invoked as either a shell script or a tcl
script |
| 00:08.27 |
CIA-40 |
BRL-CAD:
03starseeker * r33724 10/brlcad/trunk/regress/mged/mged.tcl: Remove
env logic - won't work inside tclsh |
| 00:08.28 |
brlcad |
actually
better example |
| 00:08.33 |
brlcad |
look at
src/archer/archer |
| 00:08.42 |
brlcad |
that even
sets env vars and reinvokes |
| 00:09.40 |
brlcad |
the "trick"
is because tcl and sh handle line-comments differently, with sh
ignoring comment continuations and tcl not ignoring
them |
| 00:10.54 |
starseeker |
blast - I was
hoping staying completely within tcl land would avoid the need for
shell scripting, and let us run these on Windows |
| 00:11.37 |
brlcad |
it would run
on windows |
| 00:11.56 |
brlcad |
they work as
tcl scripts -- and on windows you're not going to have an LD
error |
| 00:12.09 |
starseeker |
ah |
| 00:12.20 |
brlcad |
fed through
tclsh, it'll ignore the shell lines |
| 00:13.19 |
brlcad |
for the nix
platforms, they can either be fed through sh (which will read the
sh lines, set *_LIBRARY_PATH accordingly, and then reinvoke as tcl)
or push the LD wrapping back up into make (like
src/tclscripts/Makefile.am does for ami.tcl) |
| 00:13.46 |
starseeker |
Hmm. What's
the preferred way? |
| 00:14.15 |
brlcad |
probably to
push it up into the Makefile.am |
| 00:14.22 |
brlcad |
keeps the
scripts more simple like you have them |
| 00:14.28 |
brlcad |
rather, even
more so |
| 00:15.12 |
brlcad |
if it really
gets messier than the three lines it takes now, you could wrap the
whole thing in a script anyways |
| 00:15.42 |
starseeker |
nods |
| 00:15.54 |
starseeker |
I'll give the
Makefile.am way a quick go |
| 00:16.43 |
brlcad |
see if mged
works for you though .. don't have a clean build here, but if
that's a prevalent bug, that'd require an emergency fix and release
of 7.14.6 |
| 00:17.58 |
starseeker |
let me
check |
| 00:18.26 |
starseeker |
what command
is it accepting? |
| 00:18.33 |
brlcad |
anything and
everything |
| 00:18.36 |
brlcad |
sdlfakjhsdlkj |
| 00:18.53 |
starseeker |
yeah - I
don't know if it's doing anything with them but it is accepting
them |
| 00:19.20 |
brlcad |
nope, nothing
works afaict |
| 00:19.22 |
starseeker |
I take it it
should be flashing the error about no db being open? |
| 00:19.23 |
brlcad |
opendb
test.g |
| 00:19.33 |
brlcad |
every command
fails |
| 00:19.39 |
starseeker |
same
here |
| 00:19.40 |
brlcad |
rather ..
does nothing |
| 00:19.51 |
brlcad |
okay, that's
pretty critical |
| 00:20.04 |
starseeker |
hrm - libged
related? |
| 00:20.23 |
brlcad |
don't know
but highly possible |
| 00:20.30 |
starseeker |
oh
great |
| 00:20.44 |
starseeker |
starts digging in src/mged |
| 00:21.08 |
brlcad |
pulls the source uploads |
| 00:24.48 |
brlcad |
arf, have to
do a 7.14.4 as soon as that's fixed |
| 00:32.42 |
CIA-40 |
BRL-CAD:
03starseeker * r33725 10/brlcad/trunk/regress/mged/Makefile.am:
Move the path logic to Makefile.am where it will actually work
(thanks Sean) |
| 00:36.53 |
starseeker |
hmm -
ged_refresh_handler calls refresh... |
| 00:40.53 |
starseeker |
OK, it never
gets as far as calling f_quit when I type quit, so its messed up
before that... |
| 00:48.25 |
*** join/#brlcad oiteste
(n=chatzill@189.71.4.20) |
| 00:51.26 |
starseeker |
brlcad: Ick
- this is one of those right on the border between Tcl and
C |
| 00:51.36 |
starseeker |
it's getting
to refresh |
| 00:51.57 |
andrecastelo |
howdy
:D |
| 00:52.19 |
starseeker |
howdy
:-) |
| 01:22.08 |
starseeker |
brlcad:
right now, my best guess is that it has something to do with
gedp->ged_gdp->gd_rtCmdNotify being set to mged_rtCmdNotify
when a file is loaded, but not without a file loaded (since gedp
doesn't point to a structure) |
| 01:31.59 |
starseeker |
If I do the
naive thing and initialize a ged struct with a pointer to NULL, it
starts up in classic mode and doesn't correctly handle
anything. |
| 01:32.29 |
starseeker |
perhaps ged
has some sort of built in assumption about a database being open
before processing commands? |
| 01:34.01 |
starseeker |
in
src/mged/mged.c lines 657-680 is where mged_rtCmdNotify is being
assigned |
| 01:34.16 |
starseeker |
or not
assigned, as the case may be |
| 02:55.43 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 02:57.45 |
Mouette |
so,these
problems still haven't solution in solaris platform? |
| 03:06.43 |
Mouette |
7.14.2
sourcecode in sourceforge.net is disappear!!!! @@ |
| 03:11.21 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:54.04 |
starseeker |
Mouette: We
found a problem that needs fixing |
| 03:56.52 |
Mouette |
so you delete
that sourcecode? |
| 03:57.04 |
starseeker |
brlcad took
it down, I believe |
| 03:57.20 |
starseeker |
you can still
get the source code from svn, if you want it - but it's busted
right now |
| 03:57.54 |
Mouette |
no, i like
wait stable version |
| 04:00.02 |
brlcad |
Mouette: I
disabled it, though I believe the direct link is still valid if you
had it -- there's a problem with it so it was disabled |
| 04:02.35 |
brlcad |
starseeker:
I've not looked, but the problem almost guaranteed has something to
do with the ged command wrapper in mged |
| 04:02.53 |
starseeker |
I emailed
Bob |
| 04:03.09 |
starseeker |
needs to get some sleep tonight, but he may be able to spot
it right off tomoroww morning |
| 04:03.21 |
starseeker |
can't spell |
| 04:04.11 |
brlcad |
bets it's cmd.c:351 |
| 04:05.00 |
starseeker |
that could be
it |
| 04:05.31 |
starseeker |
wonders why he didn't notice that in the gdb back trace for
the case with a file loaded |
| 04:05.37 |
brlcad |
yep |
| 04:05.47 |
brlcad |
gedp is only
set during f_opendb |
| 04:05.51 |
brlcad |
that's not
right |
| 04:41.31 |
brlcad |
now the other
question is how classic mode works but graphical
doesn't |
| 05:46.15 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 06:25.09 |
brlcad |
closes up gdb for the night only fixing the one bug but not
very well |
| 06:26.45 |
CIA-40 |
BRL-CAD:
03brlcad * r33726 10/brlcad/trunk/src/mged/ (mged.c setup.c): gedp
needs to be non-null. it should exist for the life of the caller
making libged calls. move ged init into mged_setup but keep the
wdbp association else all goes to hell. |
| 06:29.10 |
brlcad |
that seemds
to do the trick here, but I'm sure there's more to it |
| 06:54.20 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:21.41 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:22.11 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 11:05.58 |
d-lo |
Morning
all! |
| 11:06.21 |
brlcad |
yawns |
| 11:07.45 |
d-lo |
just waking
or getting ready to crash? |
| 11:07.55 |
d-lo |
or do I
already know the answer :) |
| 11:08.37 |
d-lo |
just FYI:
/usr/bin/ld: skipping incompatible /usr/X11/lib/libX11.so when
searching for -lX11 |
| 11:08.50 |
d-lo |
so I think I
will talk with Brian today :/ |
| 11:09.06 |
brlcad |
what type is
it? |
| 11:09.31 |
d-lo |
What type is
what? The X11 lib? |
| 11:09.35 |
brlcad |
yep |
| 11:09.54 |
brlcad |
if it's
incompatible, you can often make it compatible |
| 11:10.00 |
d-lo |
I get that
linker error for both the .so and the .a |
| 11:10.04 |
brlcad |
sure |
| 11:10.24 |
brlcad |
it's the
'why' it's incompatible that matters |
| 11:10.34 |
d-lo |
I am going to
try a few more things. I just noticed the path is getting the libs
from /lib/ and not /lib64/ |
| 11:10.46 |
d-lo |
How can I
find out the 'why' ? |
| 11:11.04 |
brlcad |
don't guess,
just run "file" on it -- it'll tell you its type, then run file on
one of your .o files to see what type you're building |
| 11:12.06 |
d-lo |
run file on
one of the .o's generated during the brlcad build? |
| 11:12.19 |
brlcad |
you have
others? :) |
| 11:12.34 |
d-lo |
:) Just
verifying info when I am in uncharted waters :) |
| 11:12.49 |
d-lo |
apologizes for abnoxious q's :) |
| 11:13.45 |
brlcad |
is usually sarcastic, bitter, and brief in the unintended
early prelight hours |
| 11:14.46 |
d-lo |
well, the
build is hanging up in: brlcad/src/other/tk/unix/ and so i picked
the last .o generated: tkUnixXId.o: ELF 64-bit LSB relocatable, AMD
x86-64, version 1 (SYSV), not stripped |
| 11:15.02 |
d-lo |
....and that
tells me that I am building a 64-bit version? |
| 11:19.45 |
brlcad |
it tells you
a lot of things, one being that it's building 64-bit
version |
| 11:20.18 |
brlcad |
more
importantly, what is the .so's type |
| 11:21.06 |
brlcad |
also
important is whether it was incompatible, skipped, and it simply
used something else (that was compatible) or whether it skipped and
linked nothing/failed |
| 11:21.21 |
brlcad |
the message
by itself could be innocuous |
| 11:21.42 |
d-lo |
the .so files
are not generated yet. |
| 11:21.51 |
d-lo |
or are you
speaking of the .so of the X11 libs |
| 11:21.52 |
d-lo |
? |
| 11:21.53 |
brlcad |
o.O |
| 11:22.08 |
brlcad |
i'm speaking
of the .so that is supposedly .. incompatible |
| 11:23.04 |
brlcad |
the point is
you compare types to see why it's incompatible |
| 11:23.14 |
brlcad |
if it's a
simple 32/64, you can do something about that |
| 11:23.51 |
d-lo |
Yeah, its
saying its a 32bit lib. |
| 11:24.43 |
d-lo |
Hrm,
configure is showing both -L/usr/X11/lib and -L/usr/X11/lib64 for
linker flags |
| 11:25.39 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 11:26.28 |
brlcad |
hence my
other point |
| 11:26.43 |
brlcad |
rather
important is whether it was incompatible, skipped, and it simply
used something else (that was compatible) or whether it skipped and
linked nothing/failed |
| 11:27.25 |
d-lo |
Well I have
tried ./configure --with-x11=/usr/X11/lib64 (and a few other
variants) with no change :/ |
| 11:28.35 |
brlcad |
but have you
confirmed that you need to change it? |
| 11:28.46 |
d-lo |
Okay, more
info: |
| 11:28.58 |
brlcad |
given both
dirs are listed, the incompatible statement probably doesn't
matter |
| 11:29.11 |
d-lo |
When I simply
./configure, I get a LD error stating it cannot find
-lX11 |
| 11:29.39 |
d-lo |
When I
./configure --with-x11=/usr/X11 then I get the incompatable
error. |
| 11:29.59 |
d-lo |
So I know i
need to point the configure to the 64 bit flavor of X11, but I am
not succeeding. |
| 11:30.13 |
brlcad |
do you even
*have* a 64-bit flavor of X11 |
| 11:30.57 |
d-lo |
yep:
libX11.so: ELF 64-bit LSB shared object, AMD x86-64, version 1
(SYSV), stripped |
| 11:31.21 |
d-lo |
after you
tossed me the 'file' bone, I went and verified the files in the
/usr/X11/lib64 dir |
| 11:31.36 |
d-lo |
so its there,
but the pathing is somehow messed up :/ |
| 11:31.47 |
brlcad |
so then it's
just path foo missing |
| 11:32.13 |
brlcad |
try
--enable-64bit, if that doesn't work try setting flags directly
yourself |
| 11:32.28 |
d-lo |
i add that --
to the ./configure? |
| 11:32.29 |
brlcad |
./configure
LDFLAGS="..." CPPFLAGS="..." CFLAGS=".." |
| 11:32.33 |
brlcad |
yep |
| 11:32.52 |
brlcad |
iirc, that
may swap the search ordering |
| 11:32.58 |
brlcad |
but no
promises |
| 11:33.05 |
d-lo |
heh. |
| 11:33.09 |
brlcad |
it's just as
easy to force it manually |
| 11:33.18 |
d-lo |
make |
| 11:33.24 |
d-lo |
damn, wrong
window. |
| 11:34.33 |
d-lo |
nope same
thing... lemme try setting the LDFLAGS manually. |
| 11:34.38 |
d-lo |
Thanks for
your help btw. |
| 11:36.03 |
brlcad |
fyi, if you
have both, there's not much for brian to do -- you have everything
you need |
| 11:36.56 |
d-lo |
i figured.
email not sent yet. |
| 11:39.41 |
d-lo |
Hrm, well
thats annoying. I used ./configure LDFLAGS="blahhblah" and it just
appened all the previous flags to the end of what I supplied.... so
/usr/X11/lib is still there :/ |
| 11:40.09 |
brlcad |
ordering
matters |
| 11:40.24 |
brlcad |
doesn't
matter if there are extras if it finds the one you need
first |
| 11:40.56 |
d-lo |
is beginning to see what starseeker and others scream about
sometimes :) |
| 11:41.22 |
brlcad |
newbies |
| 11:41.35 |
d-lo |
Hey! I
resemble that remark. |
| 11:43.10 |
brlcad |
understanding
linkage and search paths in detail is usually something hammered in
hard in a first-year cs program |
| 11:43.19 |
d-lo |
are there
adverse effects to using make -j ? |
| 11:43.22 |
brlcad |
at least it
used to be |
| 11:43.33 |
brlcad |
d-lo: yes, it
compiles adversely faster |
| 11:43.44 |
brlcad |
on smp
hardware |
| 11:44.55 |
d-lo |
:P I knew
that, just wanted to know if it f-ed up the build in any
way. |
| 11:45.28 |
brlcad |
wouldn't be a
very useful option if it did |
| 11:46.20 |
d-lo |
true, but
there is enough nuainces to this whole 'make' thing that its a
perfectly valid question/concern :P |
| 11:46.47 |
brlcad |
only with
your current uncertain state of reasoning |
| 11:48.10 |
d-lo |
./configure
LDFLAGS="-L/usr/X11/lib64" nor ./configure
LDFLAGS="-L/usr/X11/lib64" --with-x11=/usr/X11 works... still same
errors :? |
| 11:48.13 |
brlcad |
there are
certainly potential effects, as with any option, but nothing that
matters right now that you'd run into |
| 11:49.05 |
brlcad |
look at the
actual test in the config.log and see why |
| 11:49.46 |
brlcad |
could be not
using it or something else overriding it or wrong order or missing
some other flag or ... |
| 11:50.29 |
d-lo |
okay, one
sec. |
| 11:51.06 |
brlcad |
could also
move the 32bit lib out of the way |
| 11:51.27 |
brlcad |
but wouldn't
do that until you know what all usses it |
| 11:51.46 |
brlcad |
wanders off for a bit, have fun |
| 11:52.06 |
d-lo |
lata! |
| 12:05.16 |
d-lo |
brlcad: I
know you are away, but are we still using Doxygen? We moving to
something else? |
| 12:12.07 |
louipc |
I took first
year CS 7yrs ago. We learned java. I made a tic tac toe game with
the swing toolkit woo. |
| 12:15.08 |
starseeker |
d-lo: We're
still set up to use Doxygen, but I don't know if anyone has played
with it lately |
| 12:15.30 |
starseeker |
we need to do
a lot of work on "doxygenifying" things, IIRC |
| 12:15.35 |
d-lo |
starseeker:
Whats the code documentation of choice now? (Or is
there?) |
| 12:19.41 |
d-lo |
starseeker:
Docbook is for.... the tutorials and such? |
| 12:21.35 |
louipc |
docbook is
for documenting libraries and such |
| 12:21.59 |
louipc |
errm
not |
| 12:22.06 |
louipc |
d-lo: you got
it :D |
| 12:22.29 |
louipc |
I just woke
up |
| 12:24.02 |
d-lo |
alrighty
then, thanks :) |
| 12:35.53 |
*** join/#brlcad brlquestions
(n=user@56.Red-79-152-174.dynamicIP.rima-tde.net) |
| 12:35.58 |
brlquestions |
Hi again
! |
| 12:36.19 |
louipc |
hi |
| 12:36.22 |
brlquestions |
hi
louipc |
| 12:36.33 |
brlquestions |
I have one
question ... |
| 12:36.50 |
brlquestions |
the g-stl
conversor is very slow ... is it normal ? |
| 12:37.15 |
louipc |
I don't
know |
| 12:37.45 |
d-lo |
g-stl uses
the facetiation/tessilation routines and, yes, can be *very
slow* |
| 12:37.55 |
brlquestions |
OK ... thank
you d-lo |
| 12:38.13 |
brlquestions |
I was
wondering if there was some pathological operation in my model
... |
| 12:38.25 |
d-lo |
there have
been times where I have fired off a tessilation just before I leave
work for the day, so it would be done by the time I get in the next
day. |
| 12:38.48 |
louipc |
is it slower
than raytracing? |
| 12:38.55 |
d-lo |
but these
models I speak of are 75-100MB files with tens of thousands of
primitives. |
| 12:39.23 |
d-lo |
louipc: all
depends on the complexity of the object(s) you are
facetizing. |
| 12:39.29 |
brlquestions |
No ... I'm
talking about 20 minutes for one bezier solid extrusion intersected
with a spherical shell |
| 12:39.36 |
louipc |
ok |
| 12:39.39 |
d-lo |
gennerally
though, raytracing is much much faster. |
| 12:40.43 |
d-lo |
brlcad: I
have only delt with an extrusion *once* in the past 3 years of
modeling and then it was for hobby purposes only. I never tried to
shove it through a tessilator. |
| 12:41.00 |
brlquestions |
OK ... thanks
! |
| 12:41.05 |
d-lo |
Oops, that
was ment for brlquestions not brlcad ;) |
| 12:41.10 |
d-lo |
brlq |
| 12:41.26 |
d-lo |
brlquestions:
If it finishes succesfully, I would like to know the time it
took! |
| 12:41.46 |
brlquestions |
about 20
minutes with a cylindrical shell ... |
| 12:42.00 |
louipc |
pix or it
didn't happen |
| 12:42.00 |
brlquestions |
the spherical
one is running now ! |
| 12:42.08 |
d-lo |
louipc:
lol |
| 12:42.37 |
d-lo |
brlquestions:
how was the quality of the resulting BoT? |
| 12:43.10 |
brlquestions |
I think it
was good ... but anyway I need a spherical shell intersection
prior |
| 12:43.15 |
brlquestions |
to laser
sintering it ... |
| 12:45.33 |
brlquestions |
my boss only
wants to perform expensive experiments (sinterizing) only on models
closer to final products. |
| 12:45.47 |
brlquestions |
No cylinders
... spheres !!! |
| 12:46.24 |
louipc |
sounds
neat |
| 12:48.23 |
brlquestions |
OK ... the
tesellation finished right now ! 24 minutes ! |
| 12:48.28 |
brlquestions |
good results
! |
| 12:53.09 |
d-lo |
ah, its nice
to see all 4 cores at 100% :) |
| 12:54.29 |
d-lo |
brlcad: I
think I found an issue with the Makefiles. in at least two Make
files, the LDFLAG of -L/usr/X11/lib64 is being changed to
-L/usr/lib64 ... dunno why quite yet |
| 12:55.38 |
brlquestions |
check your
mail d-lo ! |
| 12:55.48 |
brlquestions |
there's a
screen capture of the BoT .. |
| 12:58.53 |
d-lo |
lookin
good! |
| 13:34.12 |
CIA-40 |
BRL-CAD:
03davidloman * r33727 10/rt^3/trunk/ (7 files in 6 dirs): Forgot to
svn add the GeometryChunk.h file. Also includes a few minor fixes a
new Exception subclass. |
| 13:39.34 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 13:40.04 |
CIA-40 |
BRL-CAD:
03davidloman * r33728
10/rt^3/trunk/src/GeometryService/netMsg/GeometryChunkMsg.cxx: Also
forgot to include the source for GeometryChunkMsg. |
| 13:48.57 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 13:56.08 |
d-lo |
anyone:
Shouldn't 'make install' copy the includes/ dir over? I am looking
for bu.h and it just isn't there... libbu.so is, but not the
header.... |
| 13:57.50 |
louipc |
yeah it
should |
| 13:58.11 |
d-lo |
glares at this evil machine. |
| 13:58.33 |
d-lo |
More than
likely operator error, but for now I blame the machine. |
| 14:00.10 |
louipc |
:D |
| 14:03.51 |
d-lo |
a ha.
workeded that time. |
| 14:03.56 |
d-lo |
glares at this evil machine. |
| 14:08.42 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F782.dip.t-dialin.net) |
| 14:09.41 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 15:27.56 |
``Erik___ |
yes, it
should go ito $PREFIX/include/ |
| 15:31.03 |
brlcad |
$prefix/include/brlcad |
| 15:31.20 |
brlcad |
for the
brlcad headers and top-level include for the external dep
headers |
| 15:31.59 |
d-lo |
something
went foobar with the first time 'round. removed it and tried again
and it worked. |
| 15:32.54 |
d-lo |
Oddness is
that in 2 Makefiles in the tk dirs, the LDFLAG for the X11 was
changed from /usr/X11/lib64 to /usr/lib64 .... |
| 15:33.30 |
d-lo |
quick change
back and it was compiling just fine.. |
| 15:34.22 |
d-lo |
``Erik: How
ya feelin? |
| 15:35.33 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 15:44.19 |
``Erik |
underground |
| 15:46.16 |
starseeker |
``Erik:
hiding? |
| 15:46.31 |
d-lo |
Well I just
got the call from my oldest's school... apperantly he blew chunks
all over the playground..... Just when i thought we had this bug
beat.... |
| 15:46.44 |
starseeker |
arrgh |
| 15:46.56 |
_sushi_ |
blew chunks
all over the playground? |
| 15:47.15 |
d-lo |
vomit |
| 15:49.27 |
``Erik |
I assume the
whif is collecing thim? |
| 15:49.33 |
``Erik |
s/ t/
/ |
| 15:50.01 |
``Erik |
hope is
recoups soon :( |
| 15:50.08 |
``Erik |
s/is/he/ |
| 15:50.21 |
_sushi_ |
d-lo: what
bug? |
| 15:50.22 |
``Erik |
keyboard is
outsmarting me today |
| 15:50.27 |
d-lo |
Yuppers.
just got a little concerned with that call and you not being here
either.... might be a trend and I don't want to burn any more sick
leave :/ |
| 15:50.46 |
d-lo |
_sushi_:
Stomach flu probably. |
| 15:50.59 |
``Erik |
no, I drank
myself fucktarded last night and am recouping |
| 15:51.14 |
``Erik |
<-- epic
fail. |
| 15:51.27 |
starseeker |
what'd you do
that for??? |
| 15:51.33 |
d-lo |
ah, okay,
well then perhaps its not another epidemic :/ |
| 15:51.38 |
``Erik |
uh, same
reason folk climb everest |
| 15:51.56 |
``Erik |
one tequlia
two tequila three tequila floor :) |
| 15:52.06 |
starseeker |
shakes head |
| 15:52.13 |
d-lo |
Playing MMOs
while heavily intoxicated is a whole new level of
entertainment. |
| 15:52.18 |
``Erik |
oh
yeah |
| 15:52.32 |
``Erik |
punker
recounted last nights mmo episode to me |
| 15:52.36 |
starseeker |
you might
want to pick a somewhat less physically damaging pointless
challenge ;-) |
| 15:52.36 |
``Erik |
I was in rare
form :D |
| 15:53.10 |
d-lo |
there is
nothing worse than an 'angry drunk' Dwarf at the bar.... man they
can be A-holes. |
| 15:53.12 |
``Erik |
apparently, I
am very giving and loving when fucked up |
| 15:53.30 |
starseeker |
wow, you WERE
smashed ;-) |
| 15:53.40 |
``Erik |
"no, I don't
need loot, I'm happy with the experience... dude, you wanna go grab
a beer? come on down to baltirmoe, man" |
| 15:54.05 |
d-lo |
lol |
| 15:54.42 |
d-lo |
loots a *glowing* Pint of Guiness + 4 |
| 15:54.56 |
``Erik |
so yeah, I
felt the notion of driving this morning would have been ... bad
:) |
| 15:55.57 |
d-lo |
good
call. |
| 15:56.09 |
``Erik |
amusingly,
I've done some of my best coding either drunk off my arse, or right
after my wisdom teeth, one shattered so they gave me a codeine
cocktail, I was wobbling in my chair but knocked out a buttload of
code |
| 15:56.19 |
d-lo |
gives you a
chance to go farming and make up for the income loss that occurred
last night :) |
| 15:56.32 |
``Erik |
meh, I got
money out the butt on that game |
| 15:56.57 |
``Erik |
as usual, the
upgrade are strictly from places I'm not geared to go. |
| 15:57.10 |
d-lo |
didn't need to know what ``Erik did with his money while
drunk.... |
| 15:57.21 |
``Erik |
they went all
donation and gave me luvin' last night, and I went and liquored
myself up stupid to fuck shit up |
| 15:57.41 |
``Erik |
<-- pissed
at himself |
| 15:58.06 |
d-lo |
No Leeroy
then? More Erik Teresa that normal? :D |
| 15:58.24 |
``Erik |
heh, no, I
don't leroy, I go all pussyfood |
| 15:58.27 |
``Erik |
foot |
| 15:58.41 |
``Erik |
"wait, what?
did you guys pull? I LOVE YOU MANG" |
| 15:59.16 |
d-lo |
Personnally,
I think suicidal raids on zones with naked toons is
funny. |
| 15:59.26 |
``Erik |
"I don't need
loot, I'm just happy I'm here" |
| 15:59.34 |
d-lo |
Both to watch
and participate in. |
| 15:59.47 |
``Erik |
heh, that's
become a tradition, everyone groups up at the instance start and
the tank is standing there butt nekkid |
| 15:59.50 |
d-lo |
lol, just
Lovin Life eh? |
| 16:00.46 |
d-lo |
once I get my
lappy back to some resemblance of useful, I will install wine and
see if I can get some games runnin :) |
| 16:00.57 |
``Erik |
and I've
participated in full group nekkid runs through instances (the
notion being we die, we die a lot, we're trying to eliminate the
repair cost) |
| 16:01.14 |
``Erik |
just buy
yourself a mac, man :D |
| 16:01.23 |
``Erik |
e-humps steve jobs leg |
| 16:01.32 |
d-lo |
has a better idea: You buy me a Mac! |
| 16:01.41 |
d-lo |
lol |
| 16:01.43 |
d-lo |
down
boy |
| 16:02.23 |
``Erik |
if'n yall
want a long lunch, I'll come down to duclaws or festival or
something |
| 16:02.32 |
d-lo |
You don't
happen to know if OSX has been sucessfully installed/ran on non
Apple hardware... do ya? |
| 16:02.47 |
CIA-40 |
BRL-CAD:
03johnranderson * r33729
10/jbrlcad/trunk/src/org/brlcad/samples/GetRegionMap.java:
Eliminated use of java 6 specifics, because this is now used in
gomez (needs to be java 5 compatible) |
| 16:03.05 |
``Erik |
um, there was
a system that apple sued out of existance that did it |
| 16:03.21 |
d-lo |
well, i was
talking more 'hack' that legit. |
| 16:03.23 |
``Erik |
and um, there
was just an article on how to do it on smackslot a couple days
ago |
| 16:03.56 |
d-lo |
thinks running OSX on a Dell would be funny
:) |
| 16:04.00 |
``Erik |
franky, apple
puts out some damn nice hardware, I think it's worth the
premium |
| 16:04.12 |
d-lo |
agrees. |
| 16:04.26 |
d-lo |
but worth it
or not, new puter hardware is not in the budget. |
| 16:04.29 |
``Erik |
I'm a bit
pissed that I can't find teh white&clear keyboard
anymore |
| 16:05.01 |
d-lo |
lol....
Hackintosh OSX |
| 16:05.56 |
``Erik |
the new style
keyboard is awfully well built, but lacks |
| 16:06.27 |
``Erik |
<-- hugs
his macbook, but admits that it's not egonomeric |
| 16:07.05 |
d-lo |
in the words
of the unknown Apple FanBoi: "sure, its not ergonmic or cheap, but
its an Apple!" |
| 16:07.22 |
``Erik |
yeah, pretty
much |
| 16:07.25 |
d-lo |
can't remember where he heard that, but it made him
ill. |
| 16:07.34 |
d-lo |
i felt like
smacking that guy. |
| 16:07.43 |
``Erik |
at least it
still has nipples |
| 16:08.21 |
``Erik |
though when
they moved them from the middle fingers to the pointers, that
pissed me off |
| 16:08.35 |
``Erik |
they belong
on d and k, not f and j, damnit |
| 16:08.49 |
``Erik |
shakes cane |
| 16:09.00 |
d-lo |
lol |
| 16:09.13 |
d-lo |
so, where are
these lunch places in which you speak? |
| 16:09.29 |
``Erik |
duclaws is
kinda close to the harford mall |
| 16:09.34 |
``Erik |
festival is
down 24 |
| 16:09.52 |
``Erik |
they're
generally considered "too far away" for lunch |
| 16:10.39 |
``Erik |
2+ hour
dealies |
| 16:10.48 |
d-lo |
ah, well
never mind then :/ |
| 16:10.51 |
``Erik |
but I wont'
drive an hour to go to lunch :) |
| 16:11.31 |
``Erik |
yeah, I
assumed *shrug* |
| 16:12.26 |
``Erik |
duclaws is a
microbrewery, so not up your alley anways |
| 16:12.35 |
d-lo |
heh, I really
do think I am going to try this Hackentosh approach ;) |
| 16:12.36 |
``Erik |
festival has
a japanese place that isn't too bad |
| 16:13.15 |
``Erik |
totally, the
killer is gonna be the bios crap, macs used to use openfirmware and
are now like epi or something |
| 16:13.41 |
``Erik |
so you'll
need 10.5 and the right hw |
| 16:14.43 |
Dr_Phreakenstein |
... can be
done with qemu... is a lot of work, and requires just the right
hardware to avoid some /serious/ driver issues |
| 16:15.40 |
d-lo |
need to
aquire 10.5 for some testing ;) |
| 16:15.53 |
Dr_Phreakenstein |
I would say
not worth it in all but the most unique circumstances (must run x
software on y hardware, cannot afford correct solution) |
| 16:16.19 |
Dr_Phreakenstein |
convince
someone to give you shell access to their machine |
| 16:16.37 |
d-lo |
you lost
me... |
| 16:17.06 |
d-lo |
why would I
need shell access to someone else's machine? |
| 16:17.08 |
Dr_Phreakenstein |
find someont
with 10.5 and get them to let you have some time on their
HW |
| 16:17.39 |
d-lo |
for what
purpose? |
| 16:18.41 |
Dr_Phreakenstein |
[20090210
08:15:42] <d-lo> need to aquire 10.5 for some testing
;) |
| 16:18.58 |
d-lo |
heh, I mend
the disc(s) for installation testing. |
| 16:19.06 |
d-lo |
s/mend/meant/ |
| 16:20.22 |
Dr_Phreakenstein |
why the need
for installation testing? it will work on real HW, fail on most
everything else (BIOS checksum, or other scheme to lock you
out) |
| 16:20.56 |
d-lo |
I have a Dell
lappy, and I want to see if i can get OS10.5 running on it
:) |
| 16:21.31 |
``Erik |
just grab
fbsd :D or linux, y'know, if you're lame |
| 16:21.48 |
Dr_Phreakenstein |
clears
throat |
| 16:21.52 |
Dr_Phreakenstein |
loudly |
| 16:22.13 |
Dr_Phreakenstein |
then chants
"gentoo, gentoo!" |
| 16:22.16 |
``Erik |
sorry, done
too much kernel work, can't respect leenewx no mo' |
| 16:22.41 |
Dr_Phreakenstein |
that's you,
man |
| 16:22.52 |
``Erik |
yes, that is
me |
| 16:23.02 |
d-lo |
i was
wondering who that was... |
| 16:23.13 |
Dr_Phreakenstein |
I have
converted from winedo$e in 96, and never looked back |
| 16:23.49 |
``Erik |
I went to
linux in '95, fbsd in '97 or '98, after witnessing the horrors from
kernel hacking |
| 16:23.58 |
Dr_Phreakenstein |
tried bsd in
98 or so, not impressed, went back to slackware |
| 16:24.04 |
``Erik |
been a kernel
hacker of some form or another since '86 |
| 16:24.28 |
Dr_Phreakenstein |
well, back
then, fbsd was a much better kernel |
| 16:24.28 |
``Erik |
interrupt
vectors on c64's, yo |
| 16:24.33 |
Dr_Phreakenstein |
! |
| 16:24.43 |
Dr_Phreakenstein |
I had
one... |
| 16:24.59 |
d-lo |
You don't
know the power of the Vic-20 .... |
| 16:25.07 |
``Erik |
been
watching, linux has spastic upgrades, but often throws them away
and adopts what fbsd did 5 years before |
| 16:25.16 |
Dr_Phreakenstein |
sold it to
that chick that reverse engineered it and made one in
FPGAs |
| 16:25.29 |
Dr_Phreakenstein |
they were
popular in Germany, I am told |
| 16:25.57 |
``Erik |
in the last
decade, I've seen ONE significant linux accomplishment adopted into
fbsd. One. |
| 16:25.59 |
Dr_Phreakenstein |
no, i don't
know the power of vic-20 |
| 16:26.07 |
Dr_Phreakenstein |
ok |
| 16:26.29 |
``Erik |
the zero copy
network shit, which was re-organized like mad due to security
concerns :D |
| 16:26.50 |
``Erik |
though ingo's
scheduler got some attention |
| 16:26.51 |
Dr_Phreakenstein |
still not
switching, too much infrastructure in place, time learning, also i
like the performance i get |
| 16:26.57 |
d-lo |
way out int
he middle of the AZ desert.. I was l33t with my cassette drive...
my parents pheared me. |
| 16:27.18 |
Dr_Phreakenstein |
... until
global warming melted your tape |
| 16:27.21 |
``Erik |
hehehhe, I
was buying the 120 minute cassettes to hold more data
:D |
| 16:27.33 |
Dr_Phreakenstein |
... wait,
that was just an ordinary day in may |
| 16:27.37 |
d-lo |
I think I
ended up taking the whole machine out for target practice one
day... |
| 16:27.48 |
``Erik |
yes, they
failed sooner, and had a higher doa, but when they worked, it was
sweet |
| 16:28.19 |
Dr_Phreakenstein |
anyone ever
use a 2.88 mB 3.5" floppy? |
| 16:28.27 |
Dr_Phreakenstein |
WORM? |
| 16:28.40 |
d-lo |
yeah, the
'super-HD'floppies. |
| 16:28.54 |
Dr_Phreakenstein |
or ls-120
super disk |
| 16:28.58 |
d-lo |
never messed
with them much.... jumped straight to 'SuperDisk' ! |
| 16:28.58 |
Dr_Phreakenstein |
from
panasonic |
| 16:29.09 |
Dr_Phreakenstein |
nice |
| 16:29.27 |
d-lo |
I was on the
iOmega Zip Disk bandwagon for a while... |
| 16:30.02 |
Dr_Phreakenstein |
until wheels
fell off..."read error !@#$&$%T#$..." |
| 16:30.13 |
d-lo |
yeah, that
was a waste of money. |
| 16:30.43 |
Dr_Phreakenstein |
SD cards,
that's the way to go. or CF |
| 16:30.56 |
Dr_Phreakenstein |
a great
backup solution, they are |
| 16:31.23 |
Dr_Phreakenstein |
32 gig CF,
get 2 of them to B/U system on rotating basis |
| 16:32.05 |
d-lo |
heh, um, I
have 2 500GB drives, 1 160 and a handfull of 80's.... won't work
for me :/ |
| 16:32.22 |
Dr_Phreakenstein |
that's
all? |
| 16:32.42 |
Dr_Phreakenstein |
I have lot's
more, but everything else is on RAID |
| 16:33.35 |
Dr_Phreakenstein |
with (ahem)
gentoo, all of my packages are tarred and bzipped in a certain dir,
and that is not much data |
| 16:34.08 |
Dr_Phreakenstein |
add that to a
tar file of my etc dir and boot dir, and that is a good
backup |
| 16:34.29 |
Dr_Phreakenstein |
crap! gotta
go to class |
| 16:34.34 |
Dr_Phreakenstein |
have fun,
kids |
| 16:34.37 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:34.58 |
CIA-40 |
BRL-CAD:
03starseeker * r33730 10/brlcad/trunk/regress/mged/ (run_test
run_test.tcl): Take a stab at getting a run_test sh script/tcl
script hybrid |
| 16:35.47 |
d-lo |
and you can
back 1.5TB+ up on 2 32Gig CF cards with Gentoo? Thats Frickin
amazing!!!!!! :P |
| 16:40.06 |
d-lo |
well, without
furthing any HardDrive envy that is floating around here, the 1TB
(ish) i have is a pain in the butt to back up to CDs as it is, so
using CF cards would make me want to gouge my own eyes
out. |
| 16:40.10 |
d-lo |
;) |
| 16:44.04 |
CIA-40 |
BRL-CAD:
03starseeker * r33731 10/brlcad/trunk/regress/mged/run_test: Go for
a system tclsh if the local btclsh isn't found - for this it won't
matter. |
| 16:46.16 |
brlcad |
starseeker:
if you're not mid-stream, distcheck |
| 16:47.44 |
CIA-40 |
BRL-CAD:
03starseeker * r33732 10/brlcad/trunk/regress/mged/run_test: Allow
user to supply source directory as second option |
| 16:47.50 |
starseeker |
brlcad: Ok,
I'm sure I'm busted on that ;-) |
| 16:48.07 |
starseeker |
you're happy
with the mged fix for the no-db case? |
| 16:48.26 |
d-lo |
brlcad: In
looking through libpkg, i am thinking it is posible to use libpkg
with out passing a callback table to a pkg_conn .....that sound
about right? |
| 16:52.05 |
d-lo |
brlcad:
Message from Ed: Call him at x6300. |
| 16:54.05 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-66.dclient.hispeed.ch) |
| 17:09.32 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:20.37 |
starseeker |
prods CIA |
| 17:23.22 |
CIA-40 |
BRL-CAD:
03starseeker * r33733 10/brlcad/trunk/regress/mged/Makefile.am:
It's run_test now |
| 17:34.41 |
d-lo |
brlcad: I
will need to sitdown and talk libpkg with you... I am just not
seeing the light :/ |
| 17:38.12 |
starseeker |
brlcad: make
distcheck passed on the Mac |
| 18:30.16 |
starseeker |
and on
linux |
| 19:33.00 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-66.dclient.hispeed.ch) |
| 19:55.09 |
CIA-40 |
BRL-CAD:
03starseeker * r33734 10/brlcad/trunk/regress/mged/ (11 files): Add
the geometry displaying commands to
regress/mged/mged.tcl |
| 19:59.59 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1096600726.dsl.bell.ca) |
| 20:24.47 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 20:56.03 |
CIA-40 |
BRL-CAD:
03brlcad * r33735 10/brlcad/trunk/ (NEWS src/gtools/g_diff.c):
fixed g_diff crash reported by lee butler where g_diff crashed with
a badmagic error bu_bomb'ing out due to an uninitialized vls. looks
like it is possibly related to earlier changes. |
| 21:26.50 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1096600726.dsl.bell.ca) |
| 21:41.29 |
CIA-40 |
BRL-CAD:
03brlcad * r33736 10/brlcad/trunk/TODO: need to fix two more
critical bugs before release. File->Open in MGED crashes and the
'gets' command locks it up saying the variable is not defined (or
it crashes/freezes). |
| 21:42.35 |
CIA-40 |
BRL-CAD:
03brlcad * r33737 10/brlcad/trunk/TODO: see the gets example in its
manpage |
| 21:50.01 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F782.dip.t-dialin.net) |
| 22:21.17 |
CIA-40 |
BRL-CAD:
03starseeker * r33738 10/brlcad/trunk/regress/mged/ (5 files):
Start on editing commands. |
| 22:46.44 |
CIA-40 |
BRL-CAD:
03starseeker * r33739 10/brlcad/trunk/regress/mged/ (Makefile.am
oed.mged regression_resources.tcl): add oed testing |
| 23:02.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 23:04.11 |
CIA-40 |
BRL-CAD:
03starseeker * r33740 10/brlcad/trunk/regress/mged/ (Makefile.am
i.mged keypoint.mged rm.mged): add i, rm and keypoint
testing |
| 23:17.45 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 23:22.12 |
poolio |
Howdy
all |
| 23:22.15 |
poolio |
congrats on
the release :) |
| 23:37.25 |
louipc |
oh! I missed
that |
| 23:55.01 |
brlcad |
poolio: not
worthy of congrats, escaped with a handful of critical
bugs |
| 23:55.05 |
brlcad |
had to pull
it shortly after |
| 23:56.43 |
poolio |
ah sorry to
hear that, is it all worked out yet or is that the reason for the
flurry of commits? |
| 23:57.26 |
brlcad |
nope, just
normal flurry |
| 23:57.39 |
brlcad |
though lot of
flurry going into testing as there may be other isses |
| 23:57.58 |
brlcad |
half of the
known ones are worked out, couple to go |
| 23:58.31 |
poolio |
good luck!
I've had a few bugs recently that took a few weeks to work
out... |
| 23:58.53 |
brlcad |
yeah, these
shouldn't be too complicated |
| 23:59.02 |
brlcad |
it's only
been a couple days |
| 23:59.13 |
brlcad |
and three
were just discovered today |
| 23:59.25 |
brlcad |
one already
fixed |
| 23:59.33 |
brlcad |
two to
go |
| 23:59.57 |
poolio |
Were there
issues in trunk or were these introduced while tagging and
such? |
| 00:00.10 |
brlcad |
in trunk,
just undetected |
| 00:19.08 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 00:19.32 |
louipc |
oh? so the
currently hosted 7.14.2 is no good? |
| 00:37.37 |
brlcad |
depends what
you need it for |
| 00:37.42 |
brlcad |
mged has a
variety of problems |
| 00:38.06 |
louipc |
ah I think
you mentioned mged -c works ok though? |
| 00:38.21 |
brlcad |
yep |
| 00:38.28 |
louipc |
cool
;) |
| 00:56.43 |
Dr_Phreakenstein |
do you guys
want build testing on 33740? |
| 01:00.36 |
mafm |
night |
| 01:07.04 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:14.07 |
brlcad |
Dr_Phreakenstein: 33740 is
what? |
| 01:15.33 |
brlcad |
otherwise,
sure .. build testing on varied platforms is always good ..
especially if you can help fix problems and not just report them
;) |
| 01:31.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 01:51.24 |
Dr_Phreakenstein |
well, I do
what I can... |
| 01:52.59 |
Dr_Phreakenstein |
that is the
subversion revision |
| 01:54.19 |
Dr_Phreakenstein |
build and
test ok on gentoo, amd64, kernel 2.6.28, gcc 4.3.3 |
| 02:28.28 |
brlcad |
cool |
| 02:29.16 |
Dr_Phreakenstein |
benchmark is
good, too |
| 02:30.08 |
Dr_Phreakenstein |
tries to
figure out how to cram more processors into box. wants to ace
benchmark |
| 03:04.44 |
starseeker |
loves bugs that make his X11 session go
wonky |
| 03:05.55 |
Dr_Phreakenstein |
that is the
advantage of having another machine that I can use to ssh in and
restart X |
| 03:06.04 |
Dr_Phreakenstein |
too bad that
machine broke |
| 03:06.31 |
starseeker |
brlcad: I
lost input when running mged in gdb, but the error reported had to
do with string comparison immediately after I selected a .g file in
the dialog |
| 03:08.01 |
starseeker |
happens with
or without a db open |
| 03:09.41 |
Dr_Phreakenstein |
starseeker:
are you running recent X? |
| 03:09.44 |
Dr_Phreakenstein |
kde? |
| 03:20.29 |
Dr_Phreakenstein |
I have the
same problem, I believe it is either new X input evdev/keyboard,
and/or their interaction with kde. I did some upgrades of xorg,
gcc, glibc, binutils, and kde 4.2 about the same time. for some
reason, certain bugs in other programs cause this, but the same
bugs caused no such instability before. Also, I seem to have lost
keyboard for no apparent reason a few times, and regained it once.
iow, may not be an mged thing |
| 03:21.15 |
Dr_Phreakenstein |
where was the
string comparison happening? |
| 03:28.22 |
Dr_Phreakenstein |
starseeker: I
would like to help if I could, gotta restart (bad nvidia driver
...grr) |
| 03:46.27 |
starseeker |
Dr_Phreakenstein: No, no kde |
| 03:46.34 |
starseeker |
this is very
probably mged |
| 03:47.40 |
starseeker |
oh |
| 03:48.32 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 03:48.37 |
starseeker |
Dr_Phreakenstein: No, no kde |
| 03:48.46 |
starseeker |
it's almost
certainly an mged issue |
| 03:49.52 |
Dr_Phreakenstein |
perhaps so,
but like I said, I started having the same problems right around
upgrade time, I believe before kde upgrade, but after xorg,
glibc/gcc |
| 03:56.36 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 04:00.41 |
starseeker |
grrrrr |
| 04:08.47 |
starseeker |
man - how do
I debug something like this? |
| 04:09.38 |
Dr_Phreakenstein |
tell me how
you got there, and I will try to help in whatever way i
can |
| 04:09.57 |
brlcad |
Dr_Phreakenstein: you'll have a hard time
getting an "ace" benchmark ... :) |
| 04:10.14 |
starseeker |
open mged
7.14.2 or latest svn, File->Open and select a file |
| 04:10.16 |
Dr_Phreakenstein |
:) |
| 04:10.46 |
brlcad |
I think
current leader is somewhere on the order of 42 million VGRs
(projected) iirc |
| 04:10.59 |
starseeker |
wow |
| 04:11.15 |
brlcad |
or 12
million, there was a two and it was more than 10 :) |
| 04:11.38 |
brlcad |
and that was
about 2 years ago |
| 04:12.42 |
Dr_Phreakenstein |
well, i can
dream, no? |
| 04:12.54 |
brlcad |
it is
impressive that a deskside workstation SMP is about to eclipse the
previous SMP leader (512 CPU Origin 2000) |
| 04:13.22 |
brlcad |
probably in
two years |
| 04:14.13 |
Dr_Phreakenstein |
well, my
machine is 2 years old, and I have 2.4 gHz proc, could put 3 gHz
in |
| 04:14.29 |
Dr_Phreakenstein |
att, price
dictated 2.4 |
| 04:14.59 |
Dr_Phreakenstein |
starseeker: I
crash before I can load anything |
| 04:15.32 |
Dr_Phreakenstein |
however, I
can open it with a db (have not tried actually using said db...
standby) |
| 04:15.47 |
brlcad |
Dr_Phreakenstein: what's your vgr
count? |
| 04:20.04 |
brlcad |
starseeker:
best bet is either putting a break in the main event loop in mged
(in mged.c iirc) or resorting to old-skool print
statements |
| 04:20.26 |
brlcad |
if you run
mged in gdb via a remote session, you should be able to control it
without killing X |
| 04:21.48 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 04:27.23 |
Dr_Phreakenstein |
ok, I can
start with open db, then go to open another, get segfault.
investigating. did not lose X, although (unrelated) transparency is
missing. 3d window was flakey. gotta look at my end |
| 04:27.57 |
brlcad |
open db via
menu or via opendb command? |
| 04:31.38 |
Dr_Phreakenstein |
menu |
| 04:33.38 |
Dr_Phreakenstein |
vgr
13884 |
| 04:33.46 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 04:37.21 |
Dr_Phreakenstein |
considering
only 4 cores, not too bad |
| 04:37.31 |
Dr_Phreakenstein |
as opposed to
512 |
| 04:37.42 |
brlcad |
yep, not too
shabby |
| 04:39.15 |
Dr_Phreakenstein |
not braggin,
just proud, considering i am poor |
| 04:39.47 |
Dr_Phreakenstein |
that having
been said, i am happy to donate cpu time and shell access to
deserving persons |
| 04:40.55 |
brlcad |
13k vaxen is
pretty substantial ;) |
| 04:41.04 |
Dr_Phreakenstein |
true |
| 04:41.27 |
Dr_Phreakenstein |
offer still
stands |
| 04:41.59 |
brlcad |
i'm good for
now, but thanks :) |
| 04:42.31 |
Dr_Phreakenstein |
will advise
of beowolf completion |
| 04:42.33 |
Dr_Phreakenstein |
;) |
| 04:47.09 |
yukonbob |
evening,
cadheads |
| 04:47.51 |
Dr_Phreakenstein |
evening,
yukonbob |
| 04:53.13 |
*** join/#brlcad madant
(n=madant@117.196.138.246) |
| 04:58.46 |
Dr_Phreakenstein |
is restarting
X. again |
| 05:04.09 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 05:04.54 |
Dr_Phreakenstein |
looks like i
fixed opengl, trying mged again |
| 05:07.31 |
*** join/#brlcad PrezKennedyJR
(i=Matthew@whitecalf.net) |
| 05:09.19 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 05:18.43 |
Dr_Phreakenstein |
ok,
starseeker, |
| 05:19.07 |
Dr_Phreakenstein |
I may have
something more helpful |
| 05:20.23 |
Dr_Phreakenstein |
i now have
opengl working right, so when i get the above crash, my screen
blanks (like going from fullscreen gl) |
| 05:20.50 |
Dr_Phreakenstein |
i then return
to konsole, which reports segfault |
| 05:21.28 |
Dr_Phreakenstein |
which tells
me that crash is mged, |
| 05:22.12 |
Dr_Phreakenstein |
but locking X
is opengl, video driver, or other opengl apps fighting over
it |
| 05:22.32 |
Dr_Phreakenstein |
looking at
crash now to find it |
| 05:23.21 |
*** join/#brlcad madant (n=madant@117.196.138.246) [NETSPLIT
VICTIM] |
| 05:23.21 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 05:23.21 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 05:33.35 |
Dr_Phreakenstein |
d-lo,
hello |
| 05:35.20 |
Dr_Phreakenstein |
4 starseeker:
have you found the bug yet? |
| 05:35.28 |
louipc |
whoazers |
| 05:35.45 |
Dr_Phreakenstein |
hey, just
learning from <brlcad> |
| 05:36.08 |
Dr_Phreakenstein |
kinda grabs
ya |
| 05:37.52 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 05:38.40 |
Dr_Phreakenstein |
if not, it
seems to be line 249 of vls.c |
| 05:41.21 |
Dr_Phreakenstein |
wait, that is
where it complained, however, the bad pointer seems to be
bu_vls |
| 05:41.43 |
Dr_Phreakenstein |
said it was
"Zero_Magic_Number" |
| 05:42.23 |
Dr_Phreakenstein |
whatever that
means |
| 05:45.46 |
Dr_Phreakenstein |
if you send
me an email addr, or send mail to phreak@110mail.com, I will send
strace outputs |
| 05:53.46 |
starseeker |
Dr_Phreakenstein: just use pastebin:
http://pastebin.bzflag.bz/ |
| 05:54.34 |
starseeker |
a complaint
at the vls level is almost always due to problems with string
handling further up the chain |
| 05:56.22 |
brlcad |
Dr_Phreakenstein: Zero_Magic_Number means
it's a string that hasn't been initialized |
| 05:56.41 |
brlcad |
sounds
exactly like the other bug I fixed earlier today too |
| 05:56.54 |
brlcad |
something
missing a bu_vls_init() |
| 05:57.23 |
starseeker |
it seems to
be before f_opendb... hmmm... |
| 05:57.40 |
starseeker |
looks at db_Open in tcl land... |
| 05:59.10 |
brlcad |
if you have a
trace, you'll at least have the place where the vls is being
called |
| 05:59.15 |
brlcad |
it's usually
obvious from there |
| 05:59.24 |
starseeker |
wants the trace :-) |
| 05:59.28 |
starseeker |
I can't
generate one here |
| 05:59.41 |
brlcad |
starseeker:
if we do gsoc again, you interested in mentoring? |
| 05:59.47 |
starseeker |
brlcad:
sure |
| 05:59.53 |
brlcad |
k |
| 05:59.57 |
brlcad |
all still
tbd |
| 06:00.01 |
starseeker |
np |
| 06:00.51 |
brlcad |
last years
didn't get as much attention as it deserved so probably would only
accept a couple students at most IFF even accepted |
| 06:01.07 |
starseeker |
right |
| 06:01.08 |
brlcad |
you have a
link to your panoramas? |
| 06:01.31 |
starseeker |
I don't think
they're online - I can put one up on bz |
| 06:01.33 |
starseeker |
one
sec |
| 06:01.41 |
starseeker |
(cat, shut
up!) |
| 06:02.11 |
starseeker |
ah, it is
up |
| 06:02.31 |
brlcad |
you had a
couple iirc |
| 06:02.35 |
brlcad |
the interior
and the exterior |
| 06:02.54 |
starseeker |
interior was
a panorama |
| 06:03.00 |
starseeker |
exterior just
a side shot |
| 06:03.11 |
brlcad |
still
stitched using panotools, though, right? |
| 06:03.21 |
starseeker |
no, that was
a full shot |
| 06:03.39 |
brlcad |
ah,
okay |
| 06:03.40 |
starseeker |
I did some
flat scans with panotools, but the side shots aren't
practical |
| 06:04.29 |
starseeker |
well, this is
one but it's 25 megs: http://bzflag.bz/~starseeker/pano_1.jpg |
| 06:05.05 |
Dr_Phreakenstein |
working on
it... |
| 06:05.16 |
Dr_Phreakenstein |
too big to
select and put into paste bin |
| 06:05.25 |
Dr_Phreakenstein |
can i get an
email? |
| 06:05.45 |
brlcad |
too big for
paste bin? |
| 06:05.54 |
brlcad |
the limit on
that is like 25 MB |
| 06:06.50 |
brlcad |
stack trace
shouldn't be more than a few dozen lines |
| 06:08.52 |
Dr_Phreakenstein |
3971 lines
for one |
| 06:08.58 |
Dr_Phreakenstein |
otu of
3 |
| 06:09.04 |
Dr_Phreakenstein |
out |
| 06:10.28 |
starseeker |
brlcad:
here's one with managable size: http://bzflag.bz/~starseeker/tank_interior.jpg |
| 06:11.52 |
Ralith |
starseeker:
you call that manageable? |
| 06:11.59 |
Ralith |
:P |
| 06:13.19 |
Dr_Phreakenstein |
perhaps by
comparison... |
| 06:15.56 |
starseeker |
Ralith:
well, there's the 25 meg version... |
| 06:16.10 |
Ralith |
fine,
fine |
| 06:16.12 |
starseeker |
Dr_Phreakenstein: It looks like it was
trying to read your .mgedrc |
| 06:16.17 |
Ralith |
how's that
model doing, anyway? |
| 06:16.30 |
starseeker |
haven't had
time to work on it yet |
| 06:17.06 |
Ralith |
aw. |
| 06:17.33 |
Dr_Phreakenstein |
I have
.mgedrc |
| 06:18.45 |
starseeker |
brlcad: I'm
going to paste a subset of this to pastebin |
| 06:19.21 |
Dr_Phreakenstein |
want to see
.mgedrc, too? |
| 06:19.37 |
starseeker |
maybe - let's
see what brlcad makes of this |
| 06:19.41 |
Dr_Phreakenstein |
(only 507
lines) |
| 06:20.08 |
Dr_Phreakenstein |
hope that
info dump helps at all |
| 06:20.20 |
starseeker |
http://pastebin.bzflag.bz/m67aab374 |
| 06:20.42 |
brlcad |
starseeker:
and to clarify .. you used the panotools and not hugin,
yes? |
| 06:20.47 |
brlcad |
hugin being
http://hugin.sourceforge.net/ |
| 06:20.53 |
starseeker |
I used
hugin |
| 06:21.02 |
starseeker |
thought it was built on panotools? |
| 06:21.09 |
brlcad |
ah, okay --
glad I asked then |
| 06:21.16 |
starseeker |
is that
bad? |
| 06:21.37 |
brlcad |
it's based on
them and somewhat built on them, but a slightly different
approach |
| 06:21.41 |
brlcad |
no, not
bad |
| 06:21.46 |
brlcad |
even
better |
| 06:22.46 |
Dr_Phreakenstein |
emerges
hugin |
| 06:23.07 |
starseeker |
Dr_Phreakenstein: what's the last line in
your mgedrc file? |
| 06:25.36 |
starseeker |
hmm - that
trace contains the complete mgedrc file, then something goes bad on
a write |
| 06:26.00 |
starseeker |
what the
heck... |
| 06:26.17 |
starseeker |
MUST sleep - got meeting tomorrow |
| 06:26.27 |
starseeker |
will sleep on it - thanks Dr_Phreakenstein |
| 06:26.27 |
Dr_Phreakenstein |
the strace
command cut off everything after 4096 bytes |
| 06:26.45 |
Dr_Phreakenstein |
i can rerun
with larger cutoff, if desired |
| 06:27.21 |
Dr_Phreakenstein |
let me know
if i can be of any further assistance. during day, send me mail, as
i do not always read full backlog |
| 06:27.28 |
starseeker |
not sure if
that will help - can you get it to run inside gdb and then do
bt? |
| 06:27.46 |
starseeker |
k -
thanks! |
| 06:27.46 |
Dr_Phreakenstein |
bt? |
| 06:27.51 |
starseeker |
backtrace |
| 06:28.06 |
starseeker |
it's what I
would have done had I not lost all X11 input |
| 06:28.20 |
Dr_Phreakenstein |
will try, and
email to you... do not wait up, but i should have by
morning |
| 06:28.28 |
Dr_Phreakenstein |
sorry about
that |
| 06:28.31 |
starseeker |
np |
| 06:28.33 |
starseeker |
thank
you! |
| 06:28.39 |
starseeker |
zzzzz |
| 06:28.43 |
Dr_Phreakenstein |
later |
| 07:07.19 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-146.dclient.hispeed.ch) |
| 07:15.03 |
CIA-40 |
BRL-CAD:
03brlcad * r33741 10/brlcad/trunk/NEWS: bob did this for 7.14.2,
but it didn't make the notes. he filled out the nearly empty usage
message and added a specific help message if you don't have a
material file set up. |
| 07:20.46 |
CIA-40 |
BRL-CAD:
03brlcad * r33742 10/brlcad/trunk/NEWS: |
| 07:20.46 |
CIA-40 |
BRL-CAD: typo
in 7.14.2 notes that didn't get caught. original message was (added
a |
| 07:20.46 |
CIA-40 |
BRL-CAD:
rough cut at an evolutionary capability to g_diff. This attempts to
guess if a |
| 07:20.46 |
CIA-40 |
BRL-CAD:
change to a region was a natural evolution or if the region was
reworked in some |
| 07:20.46 |
CIA-40 |
BRL-CAD:
significant fashion. Requested by lbutler.) |
| 07:24.59 |
CIA-40 |
BRL-CAD:
03brlcad * r33743 10/brlcad/trunk/NEWS: |
| 07:25.00 |
CIA-40 |
BRL-CAD:
another 7.14.2 fix that wasn't documented (blasted e-mail backlog),
bob fixed |
| 07:25.00 |
CIA-40 |
BRL-CAD:
mged's font preferences panel/window that was preventing the menu
from |
| 07:25.00 |
CIA-40 |
BRL-CAD:
displaying if there was a .mgedrc file present. init wasn't getting
called |
| 07:25.00 |
CIA-40 |
BRL-CAD:
causing badness. |
| 07:40.32 |
CIA-40 |
BRL-CAD:
03brlcad * r33744 10/brlcad/trunk/NEWS: minor but user-visible,
john fixed a bug in the oed command documentation to note that the
path must be drawn in order to be edited. fixes sf bug 2533174
(problems with oed command) reported by lbutler on
2009-01-24. |
| 07:41.05 |
brlcad |
at least that
one was consciously left out |
| 07:41.16 |
brlcad |
just better
to put it in hindsight to be consistent |
| 07:54.12 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:07.55 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 08:25.47 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:34.03 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 08:45.09 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:51.33 |
*** part/#brlcad piksi (n=piksi@pi-xi.net) |
| 09:15.11 |
*** join/#brlcad mafm
(n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) |
| 09:51.06 |
*** join/#brlcad brlquestions
(n=user@167.Red-79-145-179.dynamicIP.rima-tde.net) |
| 09:51.25 |
brlquestions |
Hi everybody
! |
| 11:16.24 |
*** join/#brlcad mafm
(n=mafm@28.Red-81-34-125.dynamicIP.rima-tde.net) |
| 11:31.06 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.4.20) |
| 11:49.53 |
d-lo |
Morning
all! |
| 12:11.03 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 12:21.57 |
brlcad |
grumble |
| 12:22.14 |
d-lo |
grumble? Not
enough sleep? |
| 12:23.06 |
Axman6 |
not enough
love |
| 12:23.09 |
Axman6 |
hugs brlcad |
| 12:23.33 |
brlcad |
always too
much and it's just that unproductive sinkholecesspool part of the
day |
| 12:24.00 |
brlcad |
yawns and rubs and scratches |
| 12:25.13 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 12:45.57 |
d-lo |
brlcad: so is
it more server work today? |
| 12:51.13 |
brlcad |
actually, in
meeting till after lunch |
| 12:51.23 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 12:52.17 |
brlcad |
yesterday was
a great day, though, particularly the afternoon
progress |
| 12:52.45 |
d-lo |
I think I
overheard you say the Raid array was back up? |
| 13:03.09 |
*** join/#brlcad madant
(n=madant@117.196.134.51) |
| 13:43.06 |
d-lo |
brlcad: in
libpkg, does one have to utilize the callback table for the recv()
and 'pkg_type' for the send()? |
| 14:15.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 14:18.10 |
brlcad |
d-lo: I'll
have to take another look in depth later today but my recollection
is vaguely that it does need the callback table to switch on
events |
| 14:18.39 |
brlcad |
quite
possible that it doesn't though, that's really vague and biased by
use |
| 14:19.33 |
brlcad |
that said,
it's possible to mod libpkg as well so long as the underlying
transport and parceling isn't changed (it's massively
tested/robust) |
| 14:19.53 |
brlcad |
there is one
mod that the API does need that's been on the todo, to add callback
parameters |
| 14:20.14 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 14:20.15 |
d-lo |
brlcad: Been
in the code for a while now, and it looks like its needed. I am
finding difficult to wire it in to an OO setting :/ |
| 14:20.45 |
brlcad |
right now it
relies on a global or static data containers |
| 14:22.45 |
brlcad |
being OO
doesn't change anything, at least doesn't make for a limiting
constraint |
| 14:23.04 |
brlcad |
any OO design
is deconstructable to a fully procedural one |
| 14:23.26 |
brlcad |
not that we
want to, but just saying that shouldn't be the issue |
| 14:24.25 |
d-lo |
heh,
shouldn't" ...nice :P |
| 14:25.11 |
brlcad |
okay, I could
say that isn't the issue, but trying not to be too blunt
:) |
| 14:26.38 |
brlcad |
being "OO"
isn't a problem, being async maybe or being multithreaded maybe or
wanting multiplexing maybe or wanting non-global data containers
maybe, etc. |
| 14:27.27 |
brlcad |
it's a very
simple (yet *very* robust) parcel transport layer |
| 14:28.06 |
brlcad |
it's been
hooked into OO before though, too, related to the java OO wrapping
I sent you last year |
| 14:30.44 |
d-lo |
Hrm, I don't
remember that java wrapping stuff.... only jbrlcad. |
| 14:36.26 |
d-lo |
needs an easychair @ work.... |
| 14:38.52 |
brlcad |
yeah, it was
one of the very first code chunks when you started on the
project |
| 14:39.11 |
d-lo |
Hrm, can't
find that email. Where does it live elsewhere? |
| 14:39.31 |
brlcad |
i'd have to
dig around for it again |
| 14:40.11 |
d-lo |
No worries.
Gonna work up a test. I *think* libpkg should work without
callbacks. |
| 14:40.41 |
brlcad |
it's simple
enough because it leaves you with the raw socket |
| 14:41.02 |
brlcad |
so i'm sure
you could make something callbackless |
| 14:41.38 |
brlcad |
it's just
whether you can do that and still go through the bit of code in pkg
that has the various state recoveries and error
handling |
| 14:41.52 |
d-lo |
Well, I am
going to try to rework the network api since libpkg already has 2/3
similar header elements... no need for redundant
redundancy. |
| 14:42.14 |
brlcad |
simple is
better |
| 14:43.27 |
d-lo |
I am thinking
that pkg_process() won't be a problem. It calls pkg_dispatch()
which just so happens to preform a null check on the callback table
and returns gracefully. |
| 14:46.03 |
d-lo |
heh, damn.
pkg_dispatch() wipes the pkg_conn's buffer before returning...
there goes that idea lol. |
| 14:47.46 |
d-lo |
lack of
experience question: Fundimentally, is there any difference
between feeding a pkg_switch a C routine and a function of an
object instance? |
| 14:48.59 |
d-lo |
apologizes for his horrid speling. |
| 14:49.21 |
starseeker |
spelng 's
overrrrratd |
| 14:49.32 |
d-lo |
wurd! |
| 14:49.39 |
brlcad |
there are
some differences but most can be overcome |
| 14:49.47 |
brlcad |
a static
member is identical |
| 14:49.49 |
starseeker |
after reading
slashdot for years, it takes a lot of bad spelling before I'll
notice |
| 14:51.44 |
d-lo |
so: If I
have a pkg_conn as a member of an object, and I feed
object->pkg_conn a pkg_switch that maps a 'pkg_type' to a
function of this object... shouldn't that work? |
| 14:54.39 |
d-lo |
heh, that
could have been worded a bit better. :) |
| 15:00.56 |
brlcad |
it depends on
the access settings and function signature, but yeah, something
like that is possible (the syntax is funky) |
| 15:01.06 |
brlcad |
runs |
| 15:05.45 |
brlcad |
last note
before I really run off, really should make the function static so
that it's an opaque caller |
| 15:06.04 |
brlcad |
you can make
the object to be called on a data member used by the static
callback |
| 15:06.38 |
brlcad |
which gets
into the whole issue that the callback registration needs to also
support a client data pointer (simple mod) |
| 15:13.03 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:24.05 |
CIA-40 |
BRL-CAD:
03starseeker * r33745 10/brlcad/trunk/regress/mged/ (9 files): Add
arced, copymat, putmat, push, xpush, accept, reject, and
tra |
| 15:59.50 |
Dr_Phreakenstein |
greetings,
party people! |
| 16:01.52 |
Dr_Phreakenstein |
working
people? |
| 16:02.58 |
d-lo |
"work work
work work... HELLO BOYS!" - Mel Brooks |
| 16:04.58 |
Dr_Phreakenstein |
won't admit
to seing that movie. so many times |
| 16:09.21 |
Dr_Phreakenstein |
d-lo: not to
rehash, for backing up on CF, i meant only system and config files,
as in only things handled by package installer. full drive backup,
another story |
| 16:09.39 |
Dr_Phreakenstein |
still owe you
those part numbers, have not forgotten |
| 16:09.55 |
d-lo |
Dr_Phreakenstein: yeah, got your email.
Its understood now ;) |
| 16:10.04 |
Dr_Phreakenstein |
cool |
| 16:10.50 |
Dr_Phreakenstein |
yeah, gentoo
is amazing, but i cannot claim things like that. will leave such
claims for vista |
| 16:13.55 |
d-lo |
read an
article somewhere that MS is pushing windows 7 *really* hard to get
it out ASAP. Looks like they are in phear of MS Windows ME - round
2. lol Consumer reports are starting to slam Vista pretty hard :)
tee hee. |
| 16:14.35 |
Dr_Phreakenstein |
ahhh....
warms the heart to hear stuff like that... |
| 16:15.08 |
Dr_Phreakenstein |
4
<starseeker>: need anything before I split for
class? |
| 16:20.11 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:31.48 |
Dr_Phreakenstein |
off to fun
times! |
| 16:42.53 |
*** join/#brlcad prado_
(n=prado_@tri59-1-82-233-202-167.fbx.proxad.net) |
| 16:49.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 17:09.44 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D38F.dip.t-dialin.net) |
| 17:37.39 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:42.45 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:15.23 |
d-lo |
http://xkcd.com/528/ LOL |
| 19:57.12 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 20:38.01 |
Dr_Phreakenstein |
nice |
| 20:43.37 |
starseeker |
auugh - now
7.14.3 works on my mac |
| 20:44.10 |
starseeker |
sort of - it
opens the file without hanging but does not load
.mgedrc |
| 20:47.58 |
Dr_Phreakenstein |
on lunch
break now, will hop on tonight to try and help |
| 20:52.41 |
starseeker |
oh, lovely -
now it just crashes |
| 20:52.48 |
starseeker |
must not have installed lastest |
| 21:26.51 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D38F.dip.t-dialin.net) |
| 22:26.43 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 22:30.53 |
starseeker |
tracks instant mged start crash - workin gthrouh to
mged.c:2464 |
| 22:32.59 |
brlcad |
starseeker:
is it a bu_bomb? |
| 22:33.14 |
brlcad |
or
coredump/segfault? |
| 22:33.29 |
starseeker |
bu_bomb |
| 22:33.45 |
brlcad |
vls zero or
bad magic? |
| 22:34.05 |
starseeker |
Zero_magic_number |
| 22:34.30 |
starseeker |
trying to
figure out why - str contains an mgedrc reference at that
point |
| 22:35.30 |
brlcad |
if you break
on 2464 *before* calling Tcl_EvalFile, what is str |
| 22:36.37 |
starseeker |
<PROTECTED> |
| 22:36.37 |
starseeker |
<PROTECTED> |
| 22:36.37 |
starseeker |
<PROTECTED> |
| 22:36.37 |
starseeker |
<PROTECTED> |
| 22:36.37 |
starseeker |
<PROTECTED> |
| 22:36.52 |
starseeker |
looks like a
valid vls |
| 22:37.11 |
brlcad |
yep |
| 22:37.17 |
brlcad |
so that vls
is actually fine |
| 22:37.37 |
brlcad |
it's the
.mgedrc command processing |
| 22:39.06 |
starseeker |
fears following it down those roads |
| 22:39.06 |
starseeker |
but does
anyway... |
| 22:39.06 |
brlcad |
:) |
| 22:39.06 |
brlcad |
yeah, you
have to |
| 22:39.12 |
starseeker |
hi ho, hi ho,
it's off to tclIOUtil we go... |
| 22:41.24 |
starseeker |
ok, hello
Tcl_FSEvalFileEx... |
| 22:41.47 |
brlcad |
it's going to
end up being a Tcl_EvalEx |
| 22:41.57 |
brlcad |
running the
whole file as one command |
| 22:42.05 |
starseeker |
ah,
thanks |
| 22:45.19 |
brlcad |
b
tclBasic.c:4294 |
| 22:45.36 |
brlcad |
run with
that, should then break for every commmand in the
.mgedrc |
| 22:45.44 |
brlcad |
set that
after you get to the 2464 breakpoint |
| 22:45.59 |
starseeker |
Tcl_ParseCommand (interp=0x780b200,
start=0x74ee1ec "\n", '#' <repeats 22 times>, " Query Ray
Settings ", '#' <repeats 22 times>, "\n# Set the basename of
the fake solids generated by nirt\nqray basename query_ray\n\n#
Specifies the kind of output generated by nirt.\n# g"...,
numBytes=2902, nested=0, parsePtr=0x74f5024) at
/Users/cyapp/brlcad/src/other/tcl/unix/../generic/tclParse.c:271 |
| 22:46.05 |
starseeker |
271
if ((start == NULL) && (numBytes != 0)) { |
| 22:46.06 |
starseeker |
that's the
poison |
| 22:46.51 |
brlcad |
o.O |
| 22:47.14 |
starseeker |
last parse
command before death |
| 22:48.06 |
brlcad |
doesn't see anything there |
| 22:48.20 |
brlcad |
and that
doesn't make sense too.. that's not in my .mgedrc at
least |
| 22:48.48 |
starseeker |
can wipe/redo my .mgedrc - maybe the old one is killing
it |
| 22:48.49 |
starseeker |
one
sec |
| 22:49.00 |
brlcad |
keep
it |
| 22:49.03 |
brlcad |
just move
it |
| 22:49.06 |
starseeker |
k |
| 22:49.16 |
brlcad |
there's no
reason an old mgedrc should cause a crash |
| 22:49.58 |
brlcad |
if we mess up
and it does, we should fix the mess up; not give "delete your
.mgedrc" as a 'fix' :) |
| 22:50.13 |
starseeker |
aw
;-) |
| 22:51.02 |
brlcad |
ah, I see the
Query Ray Settings section in mgedrc.tcl -- mine is just apparently
older |
| 22:51.30 |
brlcad |
ah, I wonder
if that's it |
| 22:51.44 |
brlcad |
is "qray" a
valid command now that libged is hooked in |
| 22:51.53 |
starseeker |
hrm |
| 22:51.57 |
starseeker |
good
question |
| 22:53.13 |
brlcad |
or if one of
the args to qray changed when you were working on nirt |
| 22:53.29 |
brlcad |
as unlikely
as that seems .. should have come up much earlier if that was the
case |
| 22:53.46 |
starseeker |
still crashes
without an mgedrc |
| 22:54.35 |
brlcad |
nothing new
was added to .mgedrc output recently, so that shouldn't be
it |
| 22:54.47 |
starseeker |
crashing in a
different place without mgedrc |
| 22:54.49 |
starseeker |
hang
on... |
| 22:55.56 |
starseeker |
now it's
mged.c:709 |
| 22:56.21 |
starseeker |
hmm - valid
vls, contains "gui" |
| 22:58.50 |
brlcad |
:) |
| 22:58.55 |
brlcad |
that's kinda
useless :) |
| 22:59.04 |
brlcad |
gui is the
command that kicks off the entire gui |
| 22:59.16 |
starseeker |
I'm digging
deeper |
| 22:59.21 |
brlcad |
basically
means "something went wrong" ;) |
| 23:02.38 |
starseeker |
Breakpoint 2,
Tcl_ParseCommand (interp=0x780b200, start=0x81e3504 "press
left}\n", numBytes=10, nested=0, parsePtr=0x74f59b0) at
/Users/cyapp/brlcad/src/other/tcl/unix/../generic/tclParse.c:271 |
| 23:02.42 |
starseeker |
271
if ((start == NULL) && (numBytes != 0)) { |
| 23:02.45 |
starseeker |
(gdb) |
| 23:02.50 |
starseeker |
continuing
after that triggers it |
| 23:03.33 |
CIA-40 |
BRL-CAD:
03brlcad * r33746 10/brlcad/trunk/src/libged/keep.c: fix another
cosmetic issue lee found today, if you run keep on a file that
already exists, it wasn't printing the file name due to amissing
vararg |
| 23:04.56 |
starseeker |
hmm - looks
like ged_autoview in one of these logs... |
| 23:06.18 |
starseeker |
ah
HAH |
| 23:07.15 |
starseeker |
that's
it |
| 23:07.50 |
starseeker |
GED_CHECK_DATABASE_OPEN is calling
BU_CK_VLS, which is getting passed an empty vls |
| 23:08.05 |
starseeker |
the gedp
pointer isn't null, but its contents are |
| 23:08.29 |
starseeker |
or rather -
the vls structures in it are unitialized |
| 23:09.02 |
starseeker |
checks chgview |
| 23:13.19 |
brlcad |
aha,
right |
| 23:13.29 |
starseeker |
I think it's
that blasted gedp from main |
| 23:13.37 |
brlcad |
exactly why I
didn't think my hack fix was sufficient |
| 23:13.38 |
starseeker |
size_reset
doesn't take any params |
| 23:13.56 |
starseeker |
and bv_reset
doesn't take a ged struct |
| 23:14.01 |
starseeker |
it's gotta be
the main one |
| 23:14.53 |
brlcad |
hm, the logic
to GED_CHECK_DATABASE_OPEN is rather weak |
| 23:15.04 |
brlcad |
if it's not a
null gedp, it tries to bu_vls_trunc.. |
| 23:15.13 |
brlcad |
actually,
hrm |
| 23:15.18 |
starseeker |
it looks like
the GED_INIT function needs to accept NULL and still initialize the
vls stuff |
| 23:15.26 |
brlcad |
yep |
| 23:15.31 |
brlcad |
exactly what
I was thinking |
| 23:15.37 |
starseeker |
hunts for GED_INIT |
| 23:16.16 |
brlcad |
I left the
GED_INIT in ged_dbopen(), but it also/still has to be on
BU_GETSTRUCT |
| 23:16.22 |
brlcad |
has to be in
both places |
| 23:16.39 |
brlcad |
though now
there may be a memory leak if the gedp isn't wiped out |
| 23:17.39 |
starseeker |
heh - there's
a ged_init_qray |
| 23:17.46 |
brlcad |
I think that
may belong better in the wrapper instead of during init |
| 23:17.48 |
starseeker |
wonders if that's why the mgedrc was crapping
out |
| 23:17.58 |
brlcad |
probably |
| 23:18.13 |
starseeker |
BINGO |
| 23:18.19 |
brlcad |
I bet a lot
of commands would fail because of the non-null gedp and null
dbip |
| 23:18.24 |
starseeker |
ged_init is
just returning if gedp is NULL |
| 23:18.52 |
brlcad |
hrm? that
sounds right |
| 23:19.02 |
brlcad |
nothing to
init if you don't have a gedp |
| 23:19.14 |
starseeker |
maybe, but
that's why the vls structures are in an invalid state |
| 23:19.26 |
brlcad |
it's never
initialized |
| 23:19.28 |
starseeker |
"Zero_Magic" |
| 23:19.39 |
brlcad |
look for the
getstruct |
| 23:19.56 |
brlcad |
the one I
added yesterday, needs a GED_INIT() immediately after |
| 23:20.02 |
brlcad |
just with a
null wdbp |
| 23:21.04 |
starseeker |
in
setup.c? |
| 23:21.44 |
brlcad |
sounds about
right |
| 23:23.09 |
starseeker |
well, that's
progress - now it says "A database is not open! MGED unable to
initialize gui, reverting to classic mode." |
| 23:24.21 |
CIA-40 |
BRL-CAD:
03starseeker * r33747 10/brlcad/trunk/src/mged/setup.c: Initialize
gedp so we don't have invalid vls structures when checks are
run. |
| 23:24.34 |
starseeker |
er, sorry
Sean, should have credited you with the suggestion
there |
| 23:25.18 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 23:25.50 |
starseeker |
now that's
weird - it cant initialize, offers classic, and then pops up the
full GUI anyway |
| 23:28.36 |
starseeker |
erm - it says
No symbol "TCL_OK" in current context. |
| 23:28.46 |
starseeker |
well no
wonder status doesn't equal it |
| 23:28.59 |
starseeker |
brlcad:
where do we get TCL_OK from? |
| 23:37.34 |
starseeker |
oh, OK -
tcl.h, and it's 0 |
| 23:38.34 |
starseeker |
hmm - we're
getting 1 as a return from the 709 mged Tcl_Eval |
| 23:42.07 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 23:45.50 |
brlcad |
starseeker: I
don't need to be credited for any and every suggestion |
| 23:45.54 |
brlcad |
especially
for one-liners :) |
| 23:46.21 |
starseeker |
well, going
from crashing to non-crashing on the startup of the main gui is
nice |
| 23:46.33 |
starseeker |
now if I can
just figure out why its returning status 1... |
| 23:47.14 |
brlcad |
because of
the "A database is not open!" message |
| 23:47.20 |
brlcad |
from there,
the rest just cascades |
| 23:47.45 |
starseeker |
is that a
consequence of ged wanting a database then? |
| 23:54.45 |
starseeker |
looks for where the messages are called and feels a sinking
feeling |
| 23:58.42 |
starseeker |
I'm guessing
the fix is to have the various commands that can run without an
open database check for an open database only when the wdbp pointer
is non-NULL? |
| 00:10.18 |
starseeker |
message to self - per discussion with Sean, push GED checks
for database state in commands down to where the command actually
needs to know - "correct" way to avoid status picking up errors
from the ged commands run in startup |
| 00:20.24 |
*** join/#brlcad BigAToo
(n=BigAToo@mail.fbcelkhart.org) |
| 00:27.59 |
brlcad |
if we
separate out help from the main work command, then the checks could
conceivably remain at the top -- we'll end up with something like
rt_functab that the wrapper would use to invoke a
command |
| 00:28.13 |
brlcad |
for now,
though, I think the next step is to just do the
push-down |
| 00:33.43 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.4.20) |
| 00:34.37 |
brlcad |
howdy
andrecastelo ! |
| 00:34.40 |
brlcad |
ltns |
| 00:34.59 |
andrecastelo |
howdy brlcad
:D |
| 00:36.01 |
andrecastelo |
how's
everything??? |
| 00:36.09 |
brlcad |
busy as all
frack |
| 00:36.23 |
brlcad |
too many
irons in the fire I suppose |
| 00:36.32 |
brlcad |
otherwise,
going great |
| 00:36.54 |
brlcad |
has to run off for a bit, ttyl |
| 00:38.11 |
andrecastelo |
:D |
| 01:09.54 |
CIA-40 |
BRL-CAD:
03louipc * r33748 10/brlcad/trunk/misc/archlinux/PKGBUILD: Add
libxslt as makedepends, and tkhtml3 as optdepends in Arch
PKGBUILD. |
| 01:16.43 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 01:59.10 |
``Erik_ |
heh, I keep
seeing more and more about ted lately O.o |
| 02:43.28 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-198-192.we.res.rr.com) |
| 03:03.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 03:42.16 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1096600726.dsl.bell.ca) |
| 03:50.27 |
starseeker |
``Erik: the
old rich text editor? |
| 03:50.39 |
starseeker |
hasn't heard of it in years... |
| 03:51.30 |
starseeker |
hey, cool -
it does still exist: http://www.nllgg.nl/Ted/ |
| 03:51.46 |
Dr_Phreakenstein |
silly
antiques ;) |
| 03:51.54 |
starseeker |
indeed |
| 03:52.10 |
Dr_Phreakenstein |
actually, ted
was not a very clever name... |
| 03:52.35 |
Dr_Phreakenstein |
i have known
of several, unrelated text editors named ted |
| 03:52.59 |
louipc |
oh
sweet! |
| 03:53.07 |
louipc |
installs ted |
| 03:53.12 |
Dr_Phreakenstein |
i should
start a collection |
| 03:53.26 |
starseeker |
used it back in the 386 days... |
| 03:53.36 |
starseeker |
Abiword was
too much for it, iirc |
| 03:54.05 |
Dr_Phreakenstein |
Abiword! |
| 03:54.23 |
louipc |
Abiword is as
far as I want to go. |
| 03:54.50 |
Dr_Phreakenstein |
my current
favs are nano, the one built into mc, and kate |
| 03:55.07 |
starseeker |
grows ever fonder of vim |
| 03:55.31 |
Dr_Phreakenstein |
i do not mean
to start debate... |
| 03:55.45 |
louipc |
vim++ |
| 03:55.46 |
starseeker |
nah, nowadays
they're all pretty good |
| 03:55.48 |
Dr_Phreakenstein |
editors are
really a matter of habit and preference |
| 03:56.04 |
starseeker |
you just have
to spend a lot of time to take advantage of the powerful
ones |
| 03:56.10 |
louipc |
they should
tweak evim so it's usable via console |
| 03:56.13 |
starseeker |
still uses nedit for quick and dirty |
| 03:56.20 |
louipc |
then there
would be no reason for nano whatsoever |
| 03:56.56 |
Dr_Phreakenstein |
i remember my
1st experience w/ vi. got stuck in slackware 96 after i wiped my
dos partition. i had no idea what to do, never heard of a man page,
nothing |
| 03:57.14 |
Dr_Phreakenstein |
i was
hurting |
| 03:57.53 |
louipc |
I had a book
so it wasn't so bad |
| 03:58.02 |
Dr_Phreakenstein |
given that
trauma, i think that you can understand my reluctance to use vi and
all derivitaves, even if i can acknowledge their technical
greatness |
| 03:58.18 |
starseeker |
sure - a lot
of people associate it with emergency situations |
| 03:58.32 |
Dr_Phreakenstein |
yeah, i did
not know that they wrote books for those sorts of
things |
| 03:58.40 |
Dr_Phreakenstein |
ya might call
it baptism by fire |
| 03:58.49 |
louipc |
hehe |
| 03:58.53 |
Dr_Phreakenstein |
:) |
| 03:59.22 |
louipc |
well when I
first dived into linux I did hear that it was a bit challenging, so
I went out and got some docs |
| 03:59.22 |
Dr_Phreakenstein |
also, i was
using the worst possible hardware |
| 04:00.02 |
Dr_Phreakenstein |
i had never
heard of it... i complained that windows crashed and dos was
limiting (wanted better shell) |
| 04:00.27 |
Dr_Phreakenstein |
so my cousin
sent me a disk, and it really forced me to learn a lot |
| 04:00.31 |
Dr_Phreakenstein |
glad for it
now |
| 04:00.33 |
louipc |
nice |
| 04:00.51 |
Dr_Phreakenstein |
oh, no net
access, either |
| 04:01.02 |
Dr_Phreakenstein |
that might
have helped |
| 04:02.07 |
Dr_Phreakenstein |
i still
prefer nano due to it's ease of integration in very tiny systems
(very tiny still means qwerty kbd or remote shell of some
kind) |
| 04:02.20 |
louipc |
good luck
getting that to work way back then :P |
| 04:02.40 |
Dr_Phreakenstein |
getting what
to work? |
| 04:02.53 |
louipc |
internet? |
| 04:03.07 |
louipc |
dialup -
ppp |
| 04:03.07 |
Dr_Phreakenstein |
in 96? my
only restriction was parental |
| 04:03.29 |
Dr_Phreakenstein |
i had a ...
14,400 baud modem |
| 04:03.43 |
Dr_Phreakenstein |
that's *over*
14K! |
| 04:03.45 |
louipc |
sweet |
| 04:04.05 |
Dr_Phreakenstein |
i know, i
could not even whistle that fast! |
| 04:04.20 |
Dr_Phreakenstein |
ahem... |
| 04:04.38 |
Dr_Phreakenstein |
chai, the
russian way has a *lot* of caffeine in it |
| 04:05.00 |
louipc |
yeah I
actually didn't -get- vi, and I didn't like it |
| 04:05.08 |
louipc |
so I used
emacs for awhile :D |
| 04:05.58 |
Dr_Phreakenstein |
now there is
the kirby-vacuum, universal motor assembly of software |
| 04:06.33 |
Dr_Phreakenstein |
it has long
since ceased to be primarily an editor |
| 04:06.50 |
Dr_Phreakenstein |
now more like
a complete desktop environment |
| 04:07.01 |
Dr_Phreakenstein |
that i still
do not use |
| 04:07.10 |
louipc |
haha |
| 04:08.19 |
louipc |
you know nano
isn't completely user friendly |
| 04:08.45 |
louipc |
I had one
user ask "I'm stuck. What does ^X mean?" |
| 04:09.36 |
Dr_Phreakenstein |
well, what
can you do |
| 04:09.56 |
Dr_Phreakenstein |
pebkac |
| 04:10.11 |
Dr_Phreakenstein |
had they
figured out the cupholder yet? |
| 04:10.23 |
louipc |
well nowhere
does it say ^ = ctrl |
| 04:10.41 |
louipc |
:D |
| 04:10.52 |
Dr_Phreakenstein |
no, i guess i
know that from some stumbling i did back in the day... |
| 04:10.58 |
louipc |
they figured
out ssh! |
| 04:11.04 |
Dr_Phreakenstein |
but it seems
like a good guess |
| 04:11.07 |
Dr_Phreakenstein |
that or
alt |
| 04:11.15 |
louipc |
or
esc |
| 04:11.25 |
louipc |
or
shift-6 |
| 04:11.32 |
Dr_Phreakenstein |
ok, so that
leaves 3 combinations to try |
| 04:11.42 |
Dr_Phreakenstein |
all of which
is faster than asking |
| 04:14.00 |
Dr_Phreakenstein |
http://catb.org/~esr/faqs/smart-questions.html |
| 04:14.14 |
Dr_Phreakenstein |
make 'em read
that |
| 04:14.32 |
Dr_Phreakenstein |
and
everything else by him and dj bernstein |
| 04:14.53 |
Dr_Phreakenstein |
then, have
them read theregister.co.uk/odds/bofh |
| 04:15.20 |
Dr_Phreakenstein |
that will
first bring them down to size, then let them know what you are
capable of |
| 04:29.22 |
schwinn434 |
where can I
read about brlcad, and downloaded it, if possible |
| 04:29.39 |
Axman6 |
brlcad.org i
think |
| 04:30.36 |
schwinn434 |
thx
Axman6 |
| 04:31.27 |
schwinn434 |
is there a 3
dimensional cad program similar to AutoCad which is
opensource |
| 04:33.42 |
``Erik |
striped
irregular bucket, pheer... was the gospel back when I was a
sysadmin |
| 04:34.23 |
``Erik |
there're some
things esr has written that can safely be ignored, though...
:D |
| 04:35.19 |
Dr_Phreakenstein |
yes |
| 04:35.28 |
Dr_Phreakenstein |
very
safely |
| 04:36.00 |
Dr_Phreakenstein |
schwinn434:
qcad is 2d and OS... |
| 04:36.21 |
Dr_Phreakenstein |
it is
available as 3d, but i believe at a $price |
| 04:36.40 |
``Erik |
and screw
nano, http://www.geocities.com/kensanata/ed.html |
| 04:38.20 |
louipc |
``Erik++ |
| 04:41.17 |
Dr_Phreakenstein |
that was one
of the funniest things i have read this year! |
| 04:41.31 |
schwinn434 |
is qcad
opensource? |
| 04:41.54 |
Dr_Phreakenstein |
i believe
so |
| 04:42.02 |
schwinn434 |
thx
Dr_Phreakenstein |
| 04:43.29 |
louipc |
haha it's
crippleware |
| 04:43.49 |
louipc |
The demo
version terminates after 10 minutes. # It can be restarted and used
for 100 hours in total. |
| 04:43.55 |
louipc |
opensource
crippleware though |
| 04:43.59 |
Dr_Phreakenstein |
community is
released under GPL |
| 04:44.02 |
louipc |
odd |
| 04:44.07 |
Dr_Phreakenstein |
what? |
| 04:44.10 |
Dr_Phreakenstein |
weird |
| 04:44.12 |
louipc |
http://www.qcad.org/qcad_downloads.html |
| 04:44.28 |
Dr_Phreakenstein |
i compile it
and use it often |
| 04:44.46 |
Dr_Phreakenstein |
does not do
3d, which brings me here |
| 04:45.29 |
Dr_Phreakenstein |
if you
compile it, i have found no time restriction |
| 04:46.12 |
``Erik |
hrm, looks
like there're 3 products, only 'professional demo' has the time
restriction, community is the only gpl one |
| 04:46.21 |
Dr_Phreakenstein |
correct |
| 04:46.36 |
schwinn434 |
thx
guys |
| 04:47.01 |
Dr_Phreakenstein |
but really,
schwinn434, brlcad can import and export autocad files |
| 04:47.11 |
Dr_Phreakenstein |
you should
use that instead |
| 04:47.16 |
``Erik |
erm, a subset
of |
| 04:47.25 |
louipc |
I guess the
time restraints is a config option in their build |
| 04:47.27 |
Dr_Phreakenstein |
shhhh... |
| 04:47.33 |
louipc |
possibly |
| 04:47.40 |
``Erik |
like we
ignore all the extra drafting crap, we do the triangles for solid
geometry |
| 04:47.44 |
Dr_Phreakenstein |
that's not a
very good sales pitch, Erik |
| 04:48.24 |
louipc |
NASA used
BRL-CAD to send people to the moon. |
| 04:48.25 |
``Erik |
heh, no, I'm
not a sales person :D if it's just the solid stuff needed out of
the dxf, we're right there for it... but if that meta-info is
required, *shrug* we don't do that |
| 04:48.34 |
louipc |
fact |
| 04:48.44 |
Dr_Phreakenstein |
the correct
answer is "Yes, it is not only fully compatible, but better in
every way, and if you disagree, we will refund your purchase price
in full" |
| 04:49.09 |
schwinn434 |
didn't
realize brlcad was so powerful |
| 04:49.12 |
brlcad |
``Erik: it
does import the 2D geometric entities now too (as
sketches) |
| 04:49.18 |
``Erik |
oh,
neat |
| 04:49.21 |
brlcad |
g-dxf is the
shizzle |
| 04:49.31 |
brlcad |
er, dxf-g
:) |
| 04:49.31 |
``Erik |
does it
attempt to export the sketches, too |
| 04:49.33 |
``Erik |
? |
| 04:49.38 |
brlcad |
mm, doubt
it |
| 04:49.45 |
louipc |
hmm |
| 04:49.53 |
``Erik |
I looked
through the source not TOO long ago and didn't see sketch shtuff
:/ |
| 04:49.53 |
brlcad |
but
maybe |
| 04:49.54 |
Dr_Phreakenstein |
see, there ya
go |
| 04:49.58 |
louipc |
schwinn434: I
was joking :D |
| 04:50.10 |
louipc |
schwinn434: I
don't know that for a fact |
| 04:50.32 |
brlcad |
it still
doesn't import the non-geometric entities I believe and various
attributes that have only to do with annotation |
| 04:50.46 |
Dr_Phreakenstein |
begins
working on sales literature and #ower#oint |
| 04:50.55 |
brlcad |
like an
entity with a "stipple" attribute .. yeah, that's ignored and
probably will stay that way |
| 04:51.09 |
Dr_Phreakenstein |
que es
"stipple" |
| 04:51.18 |
brlcad |
- - - - -
- |
| 04:51.22 |
louipc |
hash
marks? |
| 04:51.36 |
``Erik |
I d'no,
things like that could just be saved as named object pairs in the
attribute tags |
| 04:51.43 |
brlcad |
means draw
the wireframe and/or edges or whatever it's associated with using
dashed lines instead of a solid line |
| 04:51.46 |
louipc |
oh hidden
lines/centre lines, etc |
| 04:51.54 |
``Erik |
wouldn't MEAN
anything, but slightly less data lost |
| 04:52.00 |
Dr_Phreakenstein |
ahhh...
drafting symbol stuff |
| 04:52.40 |
Dr_Phreakenstein |
that is
rendered irrelevant by the whole idea of CSG |
| 04:52.50 |
Dr_Phreakenstein |
it only makes
for pretty prints... |
| 04:53.25 |
brlcad |
it's
irrelevant in most solid modeling systems |
| 04:53.33 |
brlcad |
very much a
drafting feature |
| 04:53.37 |
louipc |
*hatching |
| 04:53.52 |
Dr_Phreakenstein |
which brings
me to my idea of a print making utility, or something, to turn
geometry nice draft |
| 04:54.07 |
louipc |
you need
those marks if you're going to take a draft into the shop for
sure |
| 04:54.10 |
``Erik |
kinda sorta
like rtedge does? |
| 04:54.10 |
Dr_Phreakenstein |
geometry into
nice draft |
| 04:54.14 |
Dr_Phreakenstein |
yes |
| 04:54.20 |
brlcad |
enjoys some awesome home-cooked surf n'
turf |
| 04:54.22 |
Dr_Phreakenstein |
rtedge... |
| 04:54.30 |
Dr_Phreakenstein |
sorta |
| 04:54.49 |
louipc |
sounds
good |
| 04:55.23 |
Dr_Phreakenstein |
would add
dimmensions, 4 views, notes, specs, and |
| 04:55.32 |
Dr_Phreakenstein |
GD&T |
| 04:55.35 |
louipc |
bill of
materials |
| 04:55.43 |
Dr_Phreakenstein |
perhaps |
| 04:55.51 |
louipc |
revisions |
| 04:55.54 |
Dr_Phreakenstein |
that is too
easy to do in favorite editor |
| 04:55.57 |
Dr_Phreakenstein |
yes |
| 04:56.05 |
Dr_Phreakenstein |
revisions is
a good one |
| 04:56.07 |
``Erik |
4view is
easy, dimensions could be glued on post-rendering, no? |
| 04:56.22 |
Dr_Phreakenstein |
i did it in
openoffice |
| 04:56.29 |
``Erik |
doesn't know what the behavior of sketch is in rtege
O.o |
| 04:56.36 |
louipc |
you need bill
of materials on the dwg, especially if it's an assembly |
| 04:56.49 |
Dr_Phreakenstein |
ok, i buy
that |
| 04:57.22 |
louipc |
and
dimensioning is a bit of an art. I couldn't trust a computer to
always make the right decisions |
| 04:57.44 |
``Erik |
for 'bill of
materials', what exactly is the pertinent information? |
| 04:57.53 |
Dr_Phreakenstein |
no, should be
manually editable, especially w/ tolerances |
| 04:57.59 |
louipc |
yea |
| 04:58.20 |
Dr_Phreakenstein |
that is
something that would deserve a fair bit of thought |
| 04:58.22 |
louipc |
``Erik: tells
you what the different parts are on the drawing |
| 04:58.46 |
``Erik |
yes, but just
a list of part numbers? or material and mass? or? :) |
| 04:59.05 |
Dr_Phreakenstein |
sources,
prices, quantity |
| 04:59.06 |
louipc |
if it's a
screw it will tell you what it's specs are, if it's a custom part
it will give the part/dwg number |
| 04:59.25 |
Dr_Phreakenstein |
perhaps mult.
part numbers |
| 04:59.35 |
Dr_Phreakenstein |
assy/sub-assy
numbers |
| 04:59.56 |
``Erik |
soo, encode
it into the geometries path, then a quick little scripts to massage
the output of mged -c commands for a usable output? :) |
| 05:00.09 |
Dr_Phreakenstein |
as in part
numbers for vendor and client |
| 05:00.20 |
Dr_Phreakenstein |
groups of
parts for assy |
| 05:00.41 |
Dr_Phreakenstein |
could
work |
| 05:00.51 |
Dr_Phreakenstein |
bye,
schwinn |
| 05:01.36 |
louipc |
the most
important part is always first ;) |
| 05:02.35 |
Dr_Phreakenstein |
... also,
notes about the construction, specs, or assembly of different
parts, and a misc notes field to cover everything else |
| 05:02.43 |
Dr_Phreakenstein |
here ya
go... |
| 05:02.54 |
Dr_Phreakenstein |
notes per
part, and per drawing |
| 05:03.06 |
Dr_Phreakenstein |
that is the
easiest way to make it more generic |
| 05:03.53 |
``Erik |
been 20 years
since I've done drafting, and it was just an intro course, so
nothing detailed :D I know the general format for electronics, but
that sounds a bit differnet |
| 05:04.27 |
Dr_Phreakenstein |
the new thing
is geometric dimensioning and tolerancing |
| 05:04.31 |
louipc |
you can
achieve the order by naming I guess |
| 05:04.54 |
Dr_Phreakenstein |
just a set of
symbols and a system for doing dimensions |
| 05:05.00 |
louipc |
001.Main_Housing, 002.Drive_Shaft,
003.Bearing |
| 05:05.04 |
``Erik |
or attribute
abuse |
| 05:05.11 |
Dr_Phreakenstein |
:) |
| 05:05.14 |
Dr_Phreakenstein |
true |
| 05:06.05 |
Dr_Phreakenstein |
i would not
mind if brlcad could do electronic stuff, too |
| 05:06.17 |
Dr_Phreakenstein |
sounds like a
lot of work |
| 05:06.36 |
``Erik |
talking to
geda would probably be a better first stab O.o |
| 05:07.16 |
Dr_Phreakenstein |
but it would
be handy to have it figure out size/shape of populated board, to
see if it would fit housing |
| 05:07.22 |
Dr_Phreakenstein |
i like
kicad |
| 05:07.59 |
Dr_Phreakenstein |
geda is
decent, i have less experience with |
| 05:08.40 |
Dr_Phreakenstein |
actually,
what i want, is a hammer that also saws, polishes, grinds, and
drives threaded fasteners |
| 05:08.41 |
Dr_Phreakenstein |
;) |
| 05:09.02 |
``Erik |
I think they
call those shops |
| 05:09.10 |
Dr_Phreakenstein |
if it had a
soldering attachment, so much the better |
| 05:09.14 |
Dr_Phreakenstein |
ok, you
win |
| 05:09.18 |
louipc |
oh sweet. 3d
view |
| 05:09.30 |
Dr_Phreakenstein |
from a
hammer? |
| 05:10.25 |
louipc |
kicad |
| 05:10.46 |
Dr_Phreakenstein |
what i meant
was that it would be cool to have an "everything cad" system, but i
understand why that would not always work |
| 05:10.57 |
Dr_Phreakenstein |
upgrades
kicad to latest |
| 05:19.00 |
Dr_Phreakenstein |
hmmm... i
will have to talk to those guys, see if they can export 3d data to
a file brlcad can read |
| 05:19.07 |
Dr_Phreakenstein |
that would be
nice! |
| 05:20.12 |
brlcad |
too much
manpower and lack of development focus to attempt to support too
many domains at once, there's more than enough work to just support
one or two domains |
| 05:21.02 |
Dr_Phreakenstein |
i understand
that, i meant make kicad export to .g |
| 05:21.04 |
brlcad |
solid
modeling is top-priority followed closely behind by either drafting
or mcad needs (or the features that overlap both
domains) |
| 05:21.22 |
brlcad |
that would be
pretty easy |
| 05:21.28 |
Dr_Phreakenstein |
exactly |
| 05:21.58 |
Dr_Phreakenstein |
hey, you guys
have any debugging for me today? |
| 05:22.23 |
Dr_Phreakenstein |
i am not much
of a programmer, but i can do that |
| 05:22.48 |
Dr_Phreakenstein |
"I can strace
like nobody's business!" |
| 05:23.26 |
brlcad |
I think the
main problems were sorted out earlier today |
| 05:23.31 |
Dr_Phreakenstein |
still
learning to work w/ you guys |
| 05:23.32 |
Dr_Phreakenstein |
k |
| 05:23.53 |
Dr_Phreakenstein |
sorry to say,
i should have pointed some stuff out i found in my
trace |
| 05:23.54 |
brlcad |
now just have
a lot of grunt-work moving and repairs to take care of |
| 05:24.42 |
Dr_Phreakenstein |
looks like i
could have saved some hours, not sure. i saw stuff last night that
you guys discussed this morning |
| 05:30.57 |
brlcad |
Dr_Phreakenstein: actually your lead last
night helped |
| 05:31.08 |
brlcad |
helped a lot,
thanks |
| 05:32.54 |
Dr_Phreakenstein |
glad to
contrib... |
| 05:33.22 |
Dr_Phreakenstein |
don't be
afraid to throw problems at me... |
| 05:33.43 |
Dr_Phreakenstein |
this way we
can both learn what i can do, and i can learn at all |
| 05:34.03 |
Dr_Phreakenstein |
eg this
morning was my first experience w/ gdb |
| 05:34.28 |
louipc |
do you do any
programming? |
| 05:34.47 |
brlcad |
if you have
an app with debugging symbols, gdb is actually pretty easy to
learn |
| 05:34.51 |
brlcad |
at least most
of the basics |
| 05:34.54 |
Dr_Phreakenstein |
not yet, but
i can fumble through bash and python |
| 05:35.08 |
Dr_Phreakenstein |
so i
saw |
| 05:35.13 |
louipc |
aww, same
here :/ |
| 05:35.18 |
Dr_Phreakenstein |
always
thought it would be way harder |
| 05:35.32 |
louipc |
so that's why
you don't use vi or emacs yet ;) |
| 05:35.37 |
Dr_Phreakenstein |
:) |
| 05:35.53 |
Dr_Phreakenstein |
perhaps |
| 05:36.28 |
Dr_Phreakenstein |
although, in
my defense, my main use of kde is that it gives me konsole, a nice
way to have more terminals |
| 05:36.44 |
Dr_Phreakenstein |
terminals
with a scrollbar |
| 05:37.13 |
Dr_Phreakenstein |
and unlimited
scrollback buffer |
| 05:37.20 |
Dr_Phreakenstein |
with
search |
| 05:37.46 |
louipc |
hmm yeah
sometimes I'd like more scrollback |
| 05:37.55 |
louipc |
but it's
usually because I wasn't paying attention |
| 05:38.30 |
Dr_Phreakenstein |
here is a tip
to help many things... |
| 05:39.07 |
Dr_Phreakenstein |
# hey, let's
get a decent terminal speed now. |
| 05:39.09 |
Dr_Phreakenstein |
if tty|grep
-v tty > /dev/null ; then |
| 05:39.10 |
Dr_Phreakenstein |
<PROTECTED> |
| 05:39.12 |
Dr_Phreakenstein |
<PROTECTED> |
| 05:39.13 |
Dr_Phreakenstein |
<PROTECTED> |
| 05:39.15 |
Dr_Phreakenstein |
fi |
| 05:39.19 |
Dr_Phreakenstein |
that is in my
~/.bashrc |
| 05:39.55 |
Dr_Phreakenstein |
believe it
ornot, that speeds up compiles |
| 05:40.11 |
louipc |
hmmm |
| 05:41.00 |
Dr_Phreakenstein |
but it will
often break plain console, thus else |
| 05:41.40 |
Dr_Phreakenstein |
try #time cat
hugefile.txt before and after |
| 05:42.21 |
Dr_Phreakenstein |
i do not
remember how i discovered that |
| 05:42.25 |
louipc |
can my PIII
handle 4000000? |
| 05:42.29 |
Dr_Phreakenstein |
yes |
| 05:42.33 |
louipc |
sweet |
| 05:42.45 |
Dr_Phreakenstein |
i looked in
linux kernel source, and that is mak |
| 05:42.46 |
Dr_Phreakenstein |
max |
| 05:42.54 |
louipc |
cool |
| 05:43.07 |
Dr_Phreakenstein |
used it on my
PIII toughbook |
| 05:43.11 |
louipc |
pro tip.
thx |
| 05:43.30 |
Dr_Phreakenstein |
np, you prob
will not find that online |
| 05:44.39 |
Dr_Phreakenstein |
also, i use
make with "-j 17 -iks --no-print-directory" |
| 05:45.05 |
Dr_Phreakenstein |
i means
ignore errors, k means keep going. those are dangerous, but others
add speed |
| 05:45.46 |
Dr_Phreakenstein |
every write
to stdout blocks, so it cannot compile any faster than
that... |
| 05:45.57 |
Dr_Phreakenstein |
so i tell it
not to send as much output |
| 05:46.20 |
louipc |
true |
| 05:47.12 |
Dr_Phreakenstein |
however, i do
break a lot of stuff, so take my uber-tweaking tips w/
NaCl |
| 05:47.14 |
louipc |
I guess I
really need to work on getting all the 3rd party libraries
installed separately from brl-cad |
| 05:47.24 |
Dr_Phreakenstein |
stty is well
tested on many boxes, though |
| 05:47.28 |
louipc |
if I don't
have to compile them it will dramatically help |
| 05:47.37 |
Dr_Phreakenstein |
true |
| 05:47.41 |
Dr_Phreakenstein |
what
distro? |
| 05:47.46 |
louipc |
arch |
| 05:48.05 |
Dr_Phreakenstein |
gentoo
derivitave, iirc |
| 05:48.11 |
Dr_Phreakenstein |
? |
| 05:48.20 |
louipc |
LFS
derivative if anything |
| 05:48.27 |
louipc |
inspired by
CRUX |
| 05:48.32 |
Dr_Phreakenstein |
ahhh |
| 05:48.56 |
Dr_Phreakenstein |
sorry, so
many, i get mixed |
| 05:49.00 |
louipc |
binary
packages, rolling release |
| 05:49.17 |
Dr_Phreakenstein |
cool |
| 05:49.44 |
Dr_Phreakenstein |
i will say,
gentoo has given me *much* compiling and resolution
experience |
| 05:49.55 |
Dr_Phreakenstein |
too
much? |
| 05:50.10 |
louipc |
now that I
don't have to compile everything I can actually do some hacking
:D |
| 05:50.20 |
louipc |
yeah I used
to use gentoo |
| 05:50.27 |
Dr_Phreakenstein |
slaps on
gentoo bumper sticker that reads "I'd rather be
compiling" |
| 05:51.01 |
Dr_Phreakenstein |
can't argue
there |
| 06:57.09 |
yukonbob |
Dr_Phreakenstein: how many CPU cores do
you have at your disposal? |
| 06:57.25 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-150.dclient.hispeed.ch) |
| 06:58.54 |
Dr_Phreakenstein |
4 |
| 06:59.20 |
yukonbob |
why do you
"-j 17" for your make, then? |
| 06:59.24 |
Dr_Phreakenstein |
2proc, dual
core, 2.4gHz |
| 06:59.32 |
yukonbob |
I'd think 5
is about the max you'd require... |
| 06:59.40 |
yukonbob |
4 on, 1 on
stand-by |
| 06:59.43 |
Dr_Phreakenstein |
j= core *4 +
1 |
| 07:00.00 |
Dr_Phreakenstein |
also have 8
gigs ram |
| 07:00.31 |
yukonbob |
but that
"parallelism" isn't really parallel if they're just being swapped
around the cores ;) |
| 07:00.42 |
yukonbob |
...and that's
not free, either. |
| 07:01.05 |
Dr_Phreakenstein |
i forget, but
i researched it at one point, and that is what i arrived
at |
| 07:01.25 |
Dr_Phreakenstein |
somehow, it
gave the best performance in test case |
| 07:02.01 |
Dr_Phreakenstein |
ahhh, that
may have been when i had a slower hd |
| 07:02.29 |
Dr_Phreakenstein |
even now, i
am mostly io-restricted |
| 07:02.46 |
yukonbob |
nods |
| 07:03.17 |
Dr_Phreakenstein |
i did not
believe it, either, thought it was insane, but it seems to
work |
| 07:03.29 |
Dr_Phreakenstein |
and on
gentoo, i do a little compiling ;) |
| 07:07.33 |
Dr_Phreakenstein |
also, -j 17
is no good w/out my stty optimizations |
| 07:16.09 |
Ralith |
I'd think
that -j 17 is no good without four quadcores, too. |
| 07:16.46 |
Ralith |
the rule I've
always hear is ncpu+1 |
| 07:16.51 |
Ralith |
heard* |
| 07:17.49 |
Dr_Phreakenstein |
fair enough,
especially for a sys that is better balanced than mine |
| 07:18.28 |
Dr_Phreakenstein |
depends on
cache and scheduler, too, but that is getting pretty deep, and for
specific cases |
| 07:18.55 |
Ralith |
I suppose
ultimately you're best off just trial-and-erroring your way up
until performance starts to drop again |
| 07:19.11 |
Dr_Phreakenstein |
yeah, that is
how i got where i am |
| 07:19.30 |
Dr_Phreakenstein |
problem is, i
only tested it for certain things |
| 07:20.00 |
Dr_Phreakenstein |
mainly just
to emerge a short list of programs |
| 07:20.34 |
Dr_Phreakenstein |
wonder how it
would be affected by ccache |
| 08:27.22 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:01.10 |
*** join/#brlcad d-l1
(n=dloman@c-76-98-150-188.hsd1.pa.comcast.net) |
| 09:01.56 |
*** part/#brlcad d-l1
(n=dloman@c-76-98-150-188.hsd1.pa.comcast.net) |
| 09:08.34 |
*** join/#brlcad brlquestions
(n=user@60.Red-79-152-3.dynamicIP.rima-tde.net) |
| 10:04.33 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 10:06.46 |
d-lo |
likes ubuntu :) |
| 10:22.37 |
Dr_Phreakenstein |
not a bad
choice |
| 10:22.44 |
Dr_Phreakenstein |
you are up
early |
| 10:47.27 |
*** join/#brlcad mafm
(n=mafm@28.Red-81-34-125.dynamicIP.rima-tde.net) |
| 11:19.45 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 11:46.13 |
d-lo |
not really.
Thats my normal 'up' time. |
| 11:46.51 |
d-lo |
Wake
@0400-0415. On the road to work by 0500. Arrive @ work
0600-0615. |
| 11:49.13 |
d-lo |
I was very
impressed by Ubuntu. I have basically done a 'out of box test' of
FC10 vs ubuntu. |
| 11:50.16 |
d-lo |
and Ubuntu
wins hands down. I had to install only 2 drivers not included with
the base install to make myt Dell 1505 lappy work at 100%...
although I haven't tested the graphics driver yet. |
| 12:01.21 |
Dr_Phreakenstein |
nice |
| 12:01.49 |
d-lo |
gonna put on
wine this evening and fire up Civ4 and a few others ;) |
| 12:01.58 |
Dr_Phreakenstein |
:) |
| 12:02.23 |
Dr_Phreakenstein |
i have tetris
and minehunt on my HP calculator... |
| 12:02.35 |
Dr_Phreakenstein |
that is about
as much gaming as i do |
| 12:03.06 |
Dr_Phreakenstein |
makes my
professor seem less verbose |
| 12:03.08 |
d-lo |
tetris
rules. |
| 12:03.25 |
d-lo |
what
class? |
| 12:08.53 |
Dr_Phreakenstein |
well, i only
have 3 instructors, as it is a small dept |
| 12:09.09 |
Dr_Phreakenstein |
that one
teaches CNC mill, and inspection II |
| 12:09.57 |
d-lo |
kewl. |
| 12:10.10 |
_sushi_ |
what is the
inspection about |
| 12:10.11 |
d-lo |
did you get
all that gear Hauled successfully? |
| 12:10.13 |
Dr_Phreakenstein |
they are all
really smart, but that guy can really get going |
| 12:10.19 |
Dr_Phreakenstein |
yup |
| 12:10.33 |
Dr_Phreakenstein |
somehow (lots
of prayer) i am still alive |
| 12:11.32 |
Dr_Phreakenstein |
not to preach
(i hate that), but that was really a faith-building
experience |
| 12:11.46 |
Dr_Phreakenstein |
too much wind
load for my caravan |
| 12:11.54 |
Dr_Phreakenstein |
terrible
trailer |
| 12:12.06 |
Dr_Phreakenstein |
ratchet
straps rubbing on tires |
| 12:12.20 |
Dr_Phreakenstein |
no good
strapdown points |
| 12:12.46 |
Dr_Phreakenstein |
and those
that there were had iffy welds that were bending under the
stress |
| 12:13.00 |
d-lo |
heh, sounds
like the stuff 'good stories' are made of eh? |
| 12:13.09 |
Dr_Phreakenstein |
engine
redlined or plain ran out of steam on hills |
| 12:13.14 |
Dr_Phreakenstein |
:)
indeed |
| 12:13.34 |
Dr_Phreakenstein |
oh, and i
drove 800 miles on 2 hrs of sleep |
| 12:13.49 |
Dr_Phreakenstein |
maxed out
debit card, so could not get gas... |
| 12:14.01 |
Dr_Phreakenstein |
mad it home
with about 1 pint, no joke |
| 12:14.26 |
Dr_Phreakenstein |
gauge said i
was getting 4-5 mpg on hills |
| 12:15.00 |
d-lo |
you must
*really* love that gear :D |
| 12:16.04 |
Dr_Phreakenstein |
uh-huh! |
| 12:16.13 |
Dr_Phreakenstein |
too bad it is
still in driveway |
| 12:16.20 |
Dr_Phreakenstein |
no room in
garage |
| 12:16.36 |
Dr_Phreakenstein |
oh, and i
came out about even vs shipping |
| 12:16.45 |
d-lo |
where is it
going to go? (Ultimately) |
| 12:16.49 |
Dr_Phreakenstein |
however, now
i have a hitch and wiring |
| 12:17.07 |
Dr_Phreakenstein |
well, i have
to move to a different house... this is funny |
| 12:17.27 |
d-lo |
hell, you
gotta move it all again? |
| 12:17.30 |
Dr_Phreakenstein |
i have a
wife+3 kids, right (ages 1, 2, 3)... |
| 12:17.51 |
Dr_Phreakenstein |
well, it is
still on trailer, and this time will be a shorter drive |
| 12:17.52 |
d-lo |
Woot! You
got me beat! (mine are 5,4,2.5) |
| 12:18.10 |
Dr_Phreakenstein |
yeah, 375 and
383 days apart |
| 12:18.18 |
d-lo |
niceness. |
| 12:18.38 |
d-lo |
379 stdev
4 |
| 12:18.49 |
Dr_Phreakenstein |
so, we are
planning on moving into my mother-in-law's garage, after
renovation |
| 12:18.56 |
Dr_Phreakenstein |
:) |
| 12:19.02 |
Dr_Phreakenstein |
cool
:) |
| 12:19.15 |
Dr_Phreakenstein |
that thing is
40*24' |
| 12:19.17 |
d-lo |
15 months
between my first 2 and 21 between the last two. works out to 15
days shy of exactly 36 months :) |
| 12:19.37 |
d-lo |
'Moving into
garage' as in the family? or the gear? |
| 12:19.48 |
Dr_Phreakenstein |
with a wall
across 24' width, 15' from back |
| 12:19.53 |
Dr_Phreakenstein |
everything |
| 12:20.03 |
Dr_Phreakenstein |
shop in
front, family in smaller space |
| 12:20.36 |
Dr_Phreakenstein |
will share
bath and kitchen with bigger house to avoid legal and bldg permit
hassle |
| 12:21.09 |
d-lo |
Now that I
have all 3 pairs of little feet storming up and down the steps in a
3 story townhome.... I am begining to covet a studio style layout
:/ |
| 12:21.26 |
Dr_Phreakenstein |
there is
that... |
| 12:21.37 |
d-lo |
good call on
the legal. |
| 12:21.52 |
Dr_Phreakenstein |
i am in
townhome, lack sufficient electricity and garage space |
| 12:22.38 |
d-lo |
I can't
remember... is this just a hobby, or a hobby turning into a
bidness? |
| 12:22.39 |
Dr_Phreakenstein |
as in
computer, 3 printers, workbench, aircompressor, lamps, room lights,
and some house outlets on 20amps |
| 12:23.03 |
Dr_Phreakenstein |
compressor
trips brks, and my UPS squawks, plus i lose light |
| 12:23.07 |
d-lo |
20 or
200? |
| 12:23.14 |
Dr_Phreakenstein |
hobby-to
bus |
| 12:23.26 |
Dr_Phreakenstein |
20
amps |
| 12:23.47 |
d-lo |
...your whole
townhome is served by a 20 amp feed?!? |
| 12:24.02 |
Dr_Phreakenstein |
never mind
hooking up my rack, with those computers |
| 12:24.11 |
Dr_Phreakenstein |
no, just all
the big stuff |
| 12:24.42 |
d-lo |
whats the
main house feed? 100A or 200A service? |
| 12:24.48 |
Dr_Phreakenstein |
it has 4 20
amp circuits for most everything (save stove, etc), but all lights
and outlets |
| 12:25.19 |
d-lo |
(are we
talking about your townhome or the MIL's garage?) |
| 12:26.06 |
_sushi_ |
Hey how
dangerous is the 120VAC> |
| 12:26.08 |
Dr_Phreakenstein |
current
place... not sure of total, no main brkr in panel |
| 12:26.13 |
_sushi_ |
If you touch
it are you gonna die? |
| 12:26.19 |
Dr_Phreakenstein |
only
deadly,y? |
| 12:26.23 |
_sushi_ |
Should be
less dangerous than the European 230 |
| 12:26.42 |
Dr_Phreakenstein |
only takes 10
mAh through heart |
| 12:26.46 |
d-lo |
120Vac can
kill you... 230 can kill you...440 can kill you dead.... but then
again, so can a 9V or AA battery :) |
| 12:27.00 |
Dr_Phreakenstein |
lowest known
lethality was 30vdc |
| 12:27.29 |
Dr_Phreakenstein |
for
exocution |
| 12:27.43 |
Dr_Phreakenstein |
that must
have been agonizing |
| 12:27.55 |
_sushi_ |
tickled to
death? |
| 12:28.12 |
d-lo |
0.001a person
killed themselves with a multimeter (powered by a 9V) |
| 12:28.15 |
Dr_Phreakenstein |
i have been
bitten by 15kv, but low current. it only sucked |
| 12:28.31 |
Dr_Phreakenstein |
that takes
some talent! |
| 12:28.50 |
Dr_Phreakenstein |
death by
fluke |
| 12:28.52 |
_sushi_ |
Must have
rammed the measuring points directly into his heart |
| 12:28.53 |
Dr_Phreakenstein |
pardon
pun |
| 12:29.17 |
Dr_Phreakenstein |
aided with
brine solution, to improve conductivity |
| 12:29.27 |
d-lo |
put it on
Ohms, and jabbed a lead in each index finger. 9V/resistance of
blood = enough amperage to pop his heart. |
| 12:29.39 |
d-lo |
ded |
| 12:29.43 |
Dr_Phreakenstein |
no, MIL
place, i will install my own dedicated power |
| 12:29.46 |
_sushi_ |
did the heart
make a popping sound? |
| 12:30.00 |
d-lo |
I imagine you
could do the same thing with a 1.5V batter if you
wanted. |
| 12:30.18 |
Dr_Phreakenstein |
sounds like
wasted talent |
| 12:30.19 |
d-lo |
_sushi_:
dunno, but I imagine not. |
| 12:30.28 |
d-lo |
Darwinism in
full effect |
| 12:31.37 |
Dr_Phreakenstein |
nice |
| 12:31.39 |
_sushi_ |
did he suffer
from darwinism? |
| 12:31.50 |
_sushi_ |
I made a 50V
power supply for my optical receiver |
| 12:31.53 |
_sushi_ |
Is it lethal
then? |
| 12:31.54 |
d-lo |
seemingly so
;) |
| 12:32.13 |
d-lo |
Voltage isn't
lethal, its the current that the voltage develops that
is. |
| 12:32.33 |
Dr_Phreakenstein |
<_sushi_>: what you must know is
that here in US, we do everything possible to protect such persons
from themselves |
| 12:32.49 |
d-lo |
...and we
shouldn't :/ |
| 12:33.25 |
Dr_Phreakenstein |
but every now
and again, you get someone really determined, which results in
those sorts of stories, more laws, and greater national
debt |
| 12:34.12 |
d-lo |
not that
you're bitter or anything :) |
| 12:34.49 |
Dr_Phreakenstein |
not to sound
cruel, but if you do not buckle up, and you crash, hey, we just
should not pay the bill. sorry, dude. the car had seatbelts, since
what, 1968, maybe sooner? |
| 12:34.49 |
_sushi_ |
Hmm you need
300-500mA DC to cause fibrilation |
| 12:35.03 |
_sushi_ |
My power
supply is designed for about 100uA current |
| 12:35.14 |
Dr_Phreakenstein |
get a
cap |
| 12:35.15 |
d-lo |
fib is
usually only incuded by AC current.... |
| 12:35.25 |
_sushi_ |
But since
it's mounted on a roof person touching it accidentally could be
shocked and fall from the roof |
| 12:35.33 |
_sushi_ |
I should
still put a warning sign there is 50V inside |
| 12:36.00 |
Dr_Phreakenstein |
or mount it
to car... excellent anti-theft |
| 12:36.02 |
d-lo |
0.1mA makes a
muscle twitch, 1.0mA causes physical pain, and 10mA causes
death. |
| 12:36.24 |
_sushi_ |
d-lo: where
do you have 10mA from? |
| 12:36.31 |
Dr_Phreakenstein |
figures 1 A
should do it |
| 12:36.35 |
d-lo |
eh? |
| 12:36.42 |
_sushi_ |
d-lo: source
URL? |
| 12:36.53 |
_sushi_ |
I don't
believe the story with the battery |
| 12:37.04 |
d-lo |
training. In
my past life, I was an electrician. |
| 12:37.04 |
_sushi_ |
I would
believe the one with 30V if properly contacted |
| 12:37.08 |
Dr_Phreakenstein |
i have
electronics pocket ref, and it says 10mA |
| 12:37.25 |
_sushi_ |
for
AC? |
| 12:37.31 |
_sushi_ |
And how much
for DC? My supply is DC |
| 12:38.05 |
Dr_Phreakenstein |
any 10
mA |
| 12:38.14 |
Dr_Phreakenstein |
DC-purple |
| 12:38.53 |
Dr_Phreakenstein |
your body is
pretty efficient as electricity is only signal, not motive
power |
| 12:39.06 |
alex_joni |
any
voltage/current pair is lethal with the right set of
electrodes |
| 12:39.10 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33749 10/rt^3/trunk/src/coreInterface/
(Combination.cpp Object.cpp): moved resource pointer memory
management into Object class |
| 12:39.24 |
alex_joni |
almost any
;) |
| 12:39.36 |
Dr_Phreakenstein |
yup |
| 12:39.42 |
d-lo |
Worst case
senario: A person is tired, cold, naked and wet... their body
resistance is about 300 ohms. If it takes 100mA to kill that
person (300ohms / .1 = 30) then a mere 30V applied to the person
will kil them |
| 12:40.28 |
Dr_Phreakenstein |
there ya
go |
| 12:40.59 |
d-lo |
i was
forgetful in my numbers (1mA moves a muscle, 10mA = pain and 100mA
causes death) but that is average... each person is
different. |
| 12:41.25 |
Dr_Phreakenstein |
remember,
that 10mA has to go through heart, and it is too hard to predict
path through a body, so much current may be wasted |
| 12:41.36 |
Dr_Phreakenstein |
"wasted" |
| 12:41.58 |
d-lo |
anyways,
blood is about the same resistance as water... nearly zero, so if
you take a 9V battery: 9V/.001ohms = 9000A.... yeah, that'll kill
ya. |
| 12:42.17 |
_sushi_ |
lol |
| 12:42.26 |
Dr_Phreakenstein |
-internal
resistance of cell... still lethal |
| 12:42.35 |
d-lo |
and .001 ohms
is very very generous |
| 12:43.09 |
Dr_Phreakenstein |
so don't play
with electrons, kids |
| 12:43.33 |
_sushi_ |
hmm when I
take 12V into sweaty hand and press hard then I can make
0.12mA |
| 12:43.34 |
Dr_Phreakenstein |
one day, i
walked past and outlet... |
| 12:43.37 |
d-lo |
heh, well, at
least don't stab yourself with live electrical leads. |
| 12:43.51 |
_sushi_ |
I don't think
my blood has 1mOhm |
| 12:44.07 |
Dr_Phreakenstein |
i was a bit
alarmed to see my favorite klein screwdriver sticking straight out
of the outlet |
| 12:44.07 |
d-lo |
_sushi_:
exactly... ever wonder why your car battery is only 12V but can
knock you on your ass? :) |
| 12:44.14 |
_sushi_ |
10
kOhm |
| 12:44.16 |
Dr_Phreakenstein |
thankfully,
from the ground |
| 12:44.33 |
d-lo |
oh dear...
kiddo get a hold of it? |
| 12:44.33 |
_sushi_ |
d-lo: never
heard about car battery knocking anyone |
| 12:45.06 |
Dr_Phreakenstein |
i guess...
trying to be like me and "fix" stuff |
| 12:45.10 |
d-lo |
_sushi_: well
grab both the + and - sides of your car battery sometime and you'll
find out. |
| 12:45.13 |
d-lo |
:) |
| 12:45.35 |
_sushi_ |
d-lo: 120uA
and I don't feel anything |
| 12:45.41 |
Dr_Phreakenstein |
better yet,
place wrench carefully across terminals... |
| 12:45.49 |
_sushi_ |
wrench !=
body |
| 12:46.05 |
Dr_Phreakenstein |
no, but lead
acid can arc weld |
| 12:46.08 |
_sushi_ |
they are made
from very different material |
| 12:46.16 |
d-lo |
Dr_Phreakenstein: Lol, yeah.. did that
during my first carstereo install... scared the life outta
me. |
| 12:46.30 |
_sushi_ |
d-lo: never
welded before? |
| 12:47.03 |
d-lo |
_sushi_:
120uA is .000120 amps... we are talking .001, .01 and .1 amps....
several magnitudes difference |
| 12:47.20 |
d-lo |
_sushi_: yes,
several times... but on purpose. |
| 12:47.38 |
*** join/#brlcad mafm_
(n=mafm@28.Red-81-34-125.dynamicIP.rima-tde.net) |
| 12:47.43 |
d-lo |
the wrench on
the terminals was an accident and not expected. |
| 12:48.05 |
d-lo |
thus,
scarey. |
| 12:48.42 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 12:49.27 |
d-lo |
besides, if
you have a 50Vdc power supply and the load on it is only drawing
120uA... that in no way means that the 50Vdc p/s can't be shorted
to ground and draw lethal current.... |
| 12:49.52 |
d-lo |
the general
rule of thumb is anything around or over 30Vdc should have a
warning sign of some sort... |
| 12:51.04 |
_sushi_ |
d-lo: what I
said if I connect my sqeaty hands across 12V and press down hard, I
get only 120uA |
| 12:51.37 |
_sushi_ |
That shows my
body resistance with sweaty hands and pressing down hard is 10
kOhm |
| 12:51.48 |
_sushi_ |
If you take
30V and 10kOhm, you get 0.3mA |
| 12:52.01 |
_sushi_ |
You need
300mA to be lethal, still 3 oderrs of magnitude are
missing. |
| 12:52.27 |
_sushi_ |
oh no,
100kOhm! |
| 12:52.34 |
d-lo |
...just
curious.. but where are you getting this 120uA measure
from? |
| 12:52.42 |
_sushi_ |
from an
ampmeter |
| 12:53.00 |
Dr_Phreakenstein |
hey, if we
stop hearing from you during these tests, what is the local number
to call ambulance in your area? |
| 12:53.16 |
d-lo |
lol |
| 12:53.25 |
Dr_Phreakenstein |
and where
should we send 'em? |
| 12:53.37 |
Dr_Phreakenstein |
:) |
| 12:54.30 |
d-lo |
multimeter or
ammeter of a 12V power supply? |
| 12:55.26 |
_sushi_ |
d-lo:
multimeter, at 40mA range |
| 12:55.38 |
_sushi_ |
Now I was
able to make 500uA, but I had to press so hard that it was
painful |
| 12:56.16 |
d-lo |
10K sounds
about right for normal situation hand to hand
resistance. |
| 12:56.22 |
Dr_Phreakenstein |
....which is
a good reminder of when to stop |
| 12:56.38 |
_sushi_ |
Dr_Phreakenstein: the pain was from
pressing, not from the current |
| 12:56.54 |
Dr_Phreakenstein |
i know that,
point still stands |
| 12:57.28 |
Dr_Phreakenstein |
i am not
afraid of electricity, but i have never intentionally shocked
myself, ammeter or otherwise |
| 12:57.49 |
_sushi_ |
I Once put
16V AC across my skull when I was a kid |
| 12:58.00 |
_sushi_ |
I could see
dim white flickering light in my peripheral vision |
| 12:58.02 |
brlcad |
heh, 'splains
a lot, don't it |
| 12:58.08 |
Dr_Phreakenstein |
i do not want
to be on record as encouraging this sor of thing |
| 12:58.13 |
Dr_Phreakenstein |
:) |
| 12:58.14 |
_sushi_ |
Across the
temples. From the model train supply. |
| 12:58.15 |
d-lo |
get both
hands 'sweaty', grab two metal pipes and then check your body
resistance. |
| 12:58.22 |
d-lo |
lol |
| 12:58.38 |
d-lo |
should get
about 1k-5k |
| 12:58.57 |
Dr_Phreakenstein |
again, there
is the idea of stopping while ahead |
| 12:59.03 |
_sushi_ |
Sounds like
you have to be a pretty good contortionist to actually kill
yourself with domestic voltage |
| 12:59.06 |
Dr_Phreakenstein |
or less
behind |
| 12:59.44 |
_sushi_ |
Then I got
scared that maybe I killed some cells in my brain with that current
and now I become retarded |
| 12:59.59 |
Dr_Phreakenstein |
has no
comment |
| 13:01.02 |
Dr_Phreakenstein |
thinks not to
remind these guys of ethanol... a great
brain-cell-icicide |
| 13:01.12 |
d-lo |
not really
_sushi_ : A person just gets done washing dishes. They see the
toaster is still plugged in and lean over to umplug it. One hand
on the metal sink(wet) the other hand grabs the plus. They
overreach a tad and a finger slips around and hits the hot prong as
its coming out of the wall... with both hands wet and one hand on a
good grounding point... zap. can easily be killed. |
| 13:01.28 |
d-lo |
plus =
plug |
| 13:01.49 |
_sushi_ |
d-lo: I think
US should get their plug design fixed |
| 13:02.11 |
d-lo |
has nothing
to do with plug design... electricity is still
electricity. |
| 13:02.24 |
_sushi_ |
It has - the
European plug doesn't allow you to touch hot parts |
| 13:02.34 |
Dr_Phreakenstein |
?!!! |
| 13:02.34 |
d-lo |
its very easy
to get shocked... especially when you don't know the dangers
involved. |
| 13:02.38 |
Dr_Phreakenstein |
which
one? |
| 13:02.53 |
_sushi_ |
British,
Czech,/// |
| 13:02.56 |
Dr_Phreakenstein |
the round pin
ones that always arc and fall out of socket? |
| 13:03.28 |
_sushi_ |
But seriously
the US plug is a major health hazard |
| 13:03.43 |
Dr_Phreakenstein |
british plug
design is good, but fails in implementation. |
| 13:03.55 |
Dr_Phreakenstein |
i used to
replace about 5-10 a day |
| 13:04.18 |
_sushi_ |
You can half
insert it and then touch the hot one with your finger |
| 13:04.33 |
Dr_Phreakenstein |
have fun with
that |
| 13:05.18 |
Dr_Phreakenstein |
oh, and those
switches in the outlets... brilliant idea, really |
| 13:05.35 |
Dr_Phreakenstein |
except that
they always weld together |
| 13:05.40 |
d-lo |
Dr_Phreakenstein: agreed. |
| 13:06.42 |
Dr_Phreakenstein |
<_sushi_>: hate to say, but outside
of Brittain, British electrical equipment has a poor reputation.
can anyone say Lucas? |
| 13:07.04 |
Dr_Phreakenstein |
7 fuses in
series to power a car stereo |
| 13:07.18 |
Dr_Phreakenstein |
no reason for
that |
| 13:07.28 |
d-lo |
the US plug
is by no means the safest... but there is a trade off there. the
number of electrical related deaths is pretty low. |
| 13:07.38 |
Dr_Phreakenstein |
indeed |
| 13:07.58 |
d-lo |
Dr_Phreakenstein: Well,if you want to make
absolutely damned sure that the stereo has overcurrent
protection... |
| 13:08.12 |
Dr_Phreakenstein |
what we are
saying is, though there is plenty of anger, actual incidence of
death is low |
| 13:08.16 |
Dr_Phreakenstein |
:) |
| 13:08.32 |
_sushi_ |
Look at the
US plug it has all-metal contacts and the area around the socket is
flat http://en.wikipedia.org/wiki/File:Domestic_AC_Type_B_USA.jpg |
| 13:08.33 |
Dr_Phreakenstein |
I should have
charged a lot more for that job |
| 13:09.03 |
_sushi_ |
If you insert
halfway you can still touch the hot prong. I have tested that
myself witha plug we have here. Checked with a multimeter that
there is a contact, and that I can touch with a finger. |
| 13:09.07 |
Dr_Phreakenstein |
yes, familiar
w/ those units |
| 13:09.07 |
d-lo |
heh, I am
well aware of what the US socket looks like :) |
| 13:09.35 |
d-lo |
_sushi_:
Yes... and? |
| 13:09.52 |
Dr_Phreakenstein |
that is why
we do not conduct such tests, we already have a good idea what will
happen... |
| 13:10.04 |
Dr_Phreakenstein |
how good is
that GFCI? |
| 13:10.11 |
_sushi_ |
The Euro plug
has an elevated area around the socket, preventing a finger access
when half-inserted: http://en.wikipedia.org/wiki/File:C_plug.jpg |
| 13:10.38 |
d-lo |
not that I
will admit anything Dr_Phreakenstein , but gfci is pretty good
protection :) |
| 13:11.03 |
Dr_Phreakenstein |
yes, but i
have a policy to not tempt fate |
| 13:11.30 |
d-lo |
_sushi_: yes,
there are US receptical coverplates that perform the exact same
function. |
| 13:11.32 |
Dr_Phreakenstein |
especially
since so many things are made in, shall we say, poorly regulated
corners of earth |
| 13:11.46 |
_sushi_ |
The British
plug has part of the hot prongs insulated, so you cannot get into
contact with lethal voltage: http://en.wikipedia.org/wiki/File:G_plug.png |
| 13:11.59 |
Dr_Phreakenstein |
not all of
them are so made |
| 13:12.08 |
d-lo |
Whats sooooo
wrong with the lowest bidder? They need to make a living
too! |
| 13:12.27 |
Dr_Phreakenstein |
and they
do |
| 13:12.50 |
Dr_Phreakenstein |
we just do
not touch live conductors, live to see another day |
| 13:13.25 |
d-lo |
_sushi_: and
the trade off is that the surface area in which current can conduct
is reduced... thus rasing current density and lowering the life of
the connection. Its a trade off. |
| 13:13.42 |
Dr_Phreakenstein |
that is y
kitchen appliance plugs are so short... it will unplug rather than
stay on while causing injury |
| 13:14.10 |
d-lo |
aka, the
G_plug is rated at 13A whereas the US standard is rated to 15A,
sometimes 20A |
| 13:14.40 |
_sushi_ |
But the G
plug has higher voltage therefore you can get even higher
power |
| 13:15.02 |
_sushi_ |
According to
my opinions The US plugs shouldn't be used with more than
48V |
| 13:15.40 |
_sushi_ |
they are low
voltage plug, then don't offer any protection against accidental
contact with live conductor |
| 13:15.44 |
d-lo |
true. but us
sockets are rated to 230V... although they only carry
110-130. |
| 13:15.48 |
_sushi_ |
Like banana
plugs. |
| 13:16.09 |
Dr_Phreakenstein |
or some other
euro plugs |
| 13:16.26 |
_sushi_ |
Some of the
Swiss have the same problem as the US ones |
| 13:16.35 |
d-lo |
_sushi_: Some
sockets have the female portion of the contactors recessed. Serves
the same function as the G_plug but also invokes the same
limitatiosn. |
| 13:16.37 |
_sushi_ |
Also
all-metal conductor and no elevated area |
| 13:17.19 |
_sushi_ |
d-lo: I
disagree that having a recessed socket invokes any electrical
limitation |
| 13:17.47 |
Dr_Phreakenstein |
in fairness,
US design is quite old, and people do not want to retrofit. but we
have one standard for our primary outlets, an advantage over
continental europe where poor adapters can lead to
hazards |
| 13:18.32 |
_sushi_ |
US is one
state, whereas Europe isn't |
| 13:18.41 |
_sushi_ |
Within each
state you also have one standard |
| 13:18.42 |
Dr_Phreakenstein |
um, 50
states |
| 13:18.47 |
d-lo |
_sushi_: not
the recessed socket, the insulated prongs of the G-plug. Some us
sockets have recessed electrical contacts (while the face of the
socket stays the same) thus, also, reducing the contact area.
thats the comparison I was making. |
| 13:18.50 |
_sushi_ |
Or one
country |
| 13:19.24 |
d-lo |
heh, one of
the few times anything has been standardized sucessfully
:/ |
| 13:19.51 |
Dr_Phreakenstein |
like the
metric sys... congress made it official |
| 13:19.54 |
Dr_Phreakenstein |
in
1896 |
| 13:20.00 |
Dr_Phreakenstein |
or 1898, i
forget |
| 13:20.05 |
_sushi_ |
lol |
| 13:20.14 |
d-lo |
long story
short, there are pros and cons to each design. neither is
superior. |
| 13:20.14 |
Dr_Phreakenstein |
you can see
where that went |
| 13:20.25 |
_sushi_ |
btw how much
is a pint? |
| 13:20.29 |
d-lo |
also likes metric. Dividing and multiplying by 10 is much
easier. |
| 13:20.31 |
Dr_Phreakenstein |
i have to buy
2 sets of tools to work on even one car |
| 13:21.11 |
Dr_Phreakenstein |
i am used to
metric from cycling, but even there, certain things are spec'd in
inches |
| 13:21.20 |
d-lo |
9/16th or
half... wtf? Neither? Damn it, its a 13mm.... |
| 13:21.29 |
Dr_Phreakenstein |
1 pair of
chain links is 1 inch when new |
| 13:21.34 |
Dr_Phreakenstein |
:) |
| 13:21.41 |
Dr_Phreakenstein |
story of my
life |
| 13:22.36 |
Dr_Phreakenstein |
certain
bearings may literally have inch OD, metric ID |
| 13:22.41 |
Dr_Phreakenstein |
?!!! |
| 13:22.47 |
d-lo |
heh, now
thats stupid. |
| 13:22.52 |
Dr_Phreakenstein |
who thought
of that! |
| 13:23.04 |
d-lo |
hopefully
someone who is now unemployed. |
| 13:23.12 |
_sushi_ |
10mm inner
diameter and 10inch outer? |
| 13:23.18 |
d-lo |
lol |
| 13:23.29 |
d-lo |
thats a
badass bearing! |
| 13:23.47 |
Dr_Phreakenstein |
more like 1.5
inch OD, 25mm ID, or so |
| 13:23.47 |
_sushi_ |
wouldn't
work |
| 13:23.55 |
Dr_Phreakenstein |
sure it
would |
| 13:24.00 |
_sushi_ |
but 1cm inner
and 1in out could work |
| 13:24.04 |
d-lo |
~9" diameter
ballbearings for a <10mm shaft...lol |
| 13:24.29 |
d-lo |
i dub it...
the 'Compensation Bearing" |
| 13:24.36 |
Dr_Phreakenstein |
:) |
| 13:24.55 |
Dr_Phreakenstein |
heh, just got
second part |
| 13:25.02 |
Dr_Phreakenstein |
need to
sleep |
| 13:25.08 |
d-lo |
"For when
your bearing *can* be huge when it doesn't need to..." |
| 13:25.17 |
d-lo |
nighty
night! |
| 13:25.28 |
Dr_Phreakenstein |
o, i still
gotta finish H/W |
| 13:25.40 |
d-lo |
well get to
is slacker! |
| 13:25.48 |
d-lo |
edit: well
get to it slacker! |
| 13:25.50 |
Dr_Phreakenstein |
looking at 24
oz rockstar, viso, and chai |
| 13:26.03 |
d-lo |
careful with
that energy drink stuff...... |
| 13:26.07 |
Dr_Phreakenstein |
all 2/3
gone |
| 13:26.14 |
Dr_Phreakenstein |
yeah, fries
nerves |
| 13:26.25 |
Dr_Phreakenstein |
takes calcium
from bones and teeth |
| 13:26.46 |
Dr_Phreakenstein |
leads to
diabetes and blood pressure problems |
| 13:26.52 |
d-lo |
I have to
back off the Mt Dew... I randomly make strange noises and/or scream
at brlcad. I think he's scared of me... |
| 13:26.53 |
Dr_Phreakenstein |
makes me want
to smoke |
| 13:26.59 |
brlcad |
heh |
| 13:27.15 |
Dr_Phreakenstein |
i was up to 2
liters a day of that stuff |
| 13:27.20 |
Dr_Phreakenstein |
for 3
yrs |
| 13:27.30 |
d-lo |
brlcad: did
you get your requisite 4 hrs down? |
| 13:27.49 |
brlcad |
yeah, and
then some after a hard workout last night.. sore |
| 13:27.53 |
Dr_Phreakenstein |
actually,
they started making 3L bottles, and i would have one a day for a
month or so |
| 13:28.17 |
d-lo |
I bet your
pancreas hates you... |
| 13:28.24 |
Dr_Phreakenstein |
btw, it does
not have effect that urban legend says |
| 13:28.34 |
Dr_Phreakenstein |
yeah,
probably |
| 13:29.11 |
d-lo |
well good. I
thought I was crazy living on 5-6 hrs aday... when I heard you say
" i only need 4! " I was sceptical... |
| 13:29.50 |
Dr_Phreakenstein |
i was telling
brlcad about polyphasic sleep... d-lo should try, too |
| 13:30.01 |
Dr_Phreakenstein |
only 3hrs per
day |
| 13:30.02 |
d-lo |
well, you
best get to that homework before you sugar crash. |
| 13:30.09 |
Dr_Phreakenstein |
too
late |
| 13:30.17 |
Dr_Phreakenstein |
i crashed and
rebounded |
| 13:30.45 |
d-lo |
when I was in
the Navy on the sub, we shifted to 18 hour days... thats an awesome
schedule. Up for 13-14, down for 4-5. |
| 13:30.54 |
d-lo |
*that* works
like a champ. |
| 13:31.27 |
Dr_Phreakenstein |
nice |
| 13:32.06 |
d-lo |
I tried it
when I wasn't underway though.... doesn't work so well when you can
see the sun. |
| 13:32.23 |
Dr_Phreakenstein |
how about in
hacker cave? |
| 13:32.32 |
d-lo |
brlcad: you
got a membership to a gym somehwere or do you do it all at
home? |
| 13:32.42 |
d-lo |
has no hacker cave. |
| 13:33.02 |
d-lo |
has children that find him anyways no matter where he
hides |
| 13:33.21 |
Dr_Phreakenstein |
i got a
sawzall and a shovel that'll fix that |
| 13:33.32 |
Dr_Phreakenstein |
yeah, me,
too |
| 13:33.36 |
Dr_Phreakenstein |
i love
'em |
| 13:34.06 |
brlcad |
doesn't believe in working out from home |
| 13:34.09 |
brlcad |
at least it's
not for me |
| 13:34.33 |
Dr_Phreakenstein |
says that
some people work, some people work out |
| 13:34.42 |
brlcad |
just not
sustainably effective -- too convenient and easy to get accustomed
to ignoring |
| 13:34.43 |
d-lo |
brlcad: Thats
cool. What's your reasoning? |
| 13:34.59 |
d-lo |
(if your dont
mind me asking) |
| 13:35.10 |
d-lo |
is having a *very* bad typing day :/ |
| 13:35.34 |
brlcad |
works for
some (very few), but I mostly find that it's just too
convenient |
| 13:35.37 |
Dr_Phreakenstein |
must be
contagious |
| 13:35.56 |
brlcad |
there are so
many other things in the house that can always take attention, and
be more entertaining even |
| 13:36.05 |
Dr_Phreakenstein |
hmmm |
| 13:36.30 |
brlcad |
whereas
physically going to the gym is a separate event in itself, a place
you go to get something done |
| 13:36.59 |
Dr_Phreakenstein |
only thing
that works for me is cycling (contrived destination), or, certain
"partner assisted" cardio events |
| 13:36.59 |
d-lo |
ah, so its a
mental conditioning thing... gotcha. |
| 13:37.13 |
d-lo |
hence, 3
kids. |
| 13:37.15 |
d-lo |
:P |
| 13:37.17 |
Dr_Phreakenstein |
:) |
| 13:37.20 |
brlcad |
plus just the
social aspect of working out with others working out can help
sustain that conditioning, get you past the ruts |
| 13:37.25 |
Dr_Phreakenstein |
and a
vascectomy |
| 13:37.46 |
Dr_Phreakenstein |
cool, glad
that works for you |
| 13:37.49 |
d-lo |
great, they
just issued a 50mph wind warning.... $5 says I lose power at work
:/ |
| 13:38.13 |
Dr_Phreakenstein |
i just lost
pwr here... alarm at 7-11 just shut off |
| 13:38.20 |
brlcad |
yeah, I heard
that last night .. that should be fun |
| 13:38.27 |
Dr_Phreakenstein |
even the
telco RT reset |
| 13:38.29 |
brlcad |
should have a
betting pool on which trees fall |
| 13:38.51 |
Dr_Phreakenstein |
mark 'em w/
different colors of spraypaint like BLM |
| 13:39.08 |
d-lo |
was having fun doing an obstical course all the way to work.
The Jeep Patriot handles much better than he
thought! |
| 13:39.27 |
Dr_Phreakenstein |
..."there's
only one!" |
| 13:39.47 |
Dr_Phreakenstein |
what state is
this in, MD? |
| 13:39.48 |
d-lo |
oh dear...
anything fall on the new ride brlcad ? |
| 13:40.03 |
d-lo |
Dr_Phreakenstein: Damned skippy! Yes,
Work in MD, live in PA. |
| 13:40.11 |
Dr_Phreakenstein |
fun |
| 13:40.27 |
d-lo |
1 hour
commute through Amish country :) |
| 13:40.46 |
Dr_Phreakenstein |
you east
coasters are why america uses so much gas |
| 13:40.49 |
Dr_Phreakenstein |
;) |
| 13:40.59 |
d-lo |
heh. |
| 13:41.02 |
d-lo |
tell em about
it. |
| 13:41.07 |
Dr_Phreakenstein |
things are
more spread out here, but we have shorter commutes, go
figure |
| 13:41.22 |
Dr_Phreakenstein |
except much
of CA |
| 13:41.22 |
d-lo |
but I wasn't
about to drop 2.5x the money for a house just to live in
MD. |
| 13:41.29 |
d-lo |
grew up in AZ. |
| 13:41.37 |
d-lo |
knows spread out. |
| 13:41.37 |
Dr_Phreakenstein |
not to say i
blame you at all |
| 13:42.00 |
Dr_Phreakenstein |
just stay
away from Maricopa Cty sherrif! |
| 13:42.16 |
d-lo |
What I bought
in PA for $130k was going for $280k(ish) in MD |
| 13:42.26 |
Dr_Phreakenstein |
pink
jumpsuits and all |
| 13:42.27 |
d-lo |
I still have
my pinik boxers lol. |
| 13:42.33 |
Dr_Phreakenstein |
:) |
| 13:42.50 |
Dr_Phreakenstein |
nice |
| 13:42.51 |
d-lo |
"Sherrif Joe
busted my ass" on the back... priceless. |
| 13:43.31 |
d-lo |
If I could
work a 100% telework contract with the Government... I'd so be
moving back to the west. |
| 13:43.41 |
Dr_Phreakenstein |
i could buy a
phone booth here for $125K... but it would be advertised as a
"cozy... handyman's dream..." |
| 13:43.45 |
d-lo |
has his eye on Northern Colorado/Wyoming. |
| 13:44.00 |
Dr_Phreakenstein |
not
bad |
| 13:44.10 |
d-lo |
Prices bad
out there then? |
| 13:44.25 |
Dr_Phreakenstein |
yes, thanks
to Californication |
| 13:44.48 |
Dr_Phreakenstein |
and no
lumber, thanks Green peace and spotted owl! |
| 13:45.25 |
Dr_Phreakenstein |
not that
spotted owl is any different than striped one, just does not get
away from chainsaws fast enough |
| 13:45.26 |
d-lo |
Them Cali's
are screwing up AZ too. They are causing the real-estate market to
crash and mess my family's investments! (fumes) |
| 13:45.37 |
Dr_Phreakenstein |
yup |
| 13:45.41 |
Dr_Phreakenstein |
that's
ok |
| 13:45.55 |
Dr_Phreakenstein |
they will be
bankrupt and fall into Pacific soon |
| 13:46.09 |
Dr_Phreakenstein |
already
halfway there... bankrupt |
| 13:46.47 |
d-lo |
I new a guy
who thought it would be funny if the 'Big One' hit cali and
everything east of the fault fell into the Atlantic. |
| 13:47.14 |
Dr_Phreakenstein |
hmmm... |
| 13:47.19 |
d-lo |
Murphey would
probably laugh his ass of at that one. |
| 13:47.39 |
Dr_Phreakenstein |
he may need
to re-examine the atlas before he gets his hopes up |
| 13:48.15 |
d-lo |
oh thank
god.... it finally compiled. Stupid Singleton.... |
| 13:48.39 |
Dr_Phreakenstein |
yeah, then
nobody to pay high prices for hollywood movies, actors must find
productive work now |
| 13:49.21 |
d-lo |
aint that the
truth. Perhaps all the Pro Sports players would get a real job
too... but thats just asking too much i suppose. |
| 13:49.53 |
d-lo |
I suppose
that Education will become more important that the NFL about the
same time hell freezes over. |
| 13:50.43 |
Dr_Phreakenstein |
if
then |
| 13:50.59 |
``Erik |
were saying
60 on the radio |
| 13:51.13 |
Dr_Phreakenstein |
how much to
build new arena? |
| 13:51.28 |
d-lo |
hopes this building gets damaged.. maybe we can get a new
one! |
| 13:51.34 |
``Erik |
HAH! |
| 13:51.37 |
Dr_Phreakenstein |
how many
schools, teachers, textbooks for that much money |
| 13:51.42 |
d-lo |
I know... I
laughed too. |
| 13:51.58 |
Dr_Phreakenstein |
with obama,
you will get at least one |
| 13:52.07 |
``Erik |
I'm upstairs
because the floor is gonna give, I"d rather fall than be fallen on
O.o |
| 13:52.31 |
d-lo |
not to
mention, for that amount of money... you just *might* get a few
more students to stop betting their career on Pro Ball and actually
prepare for life. |
| 13:52.41 |
Dr_Phreakenstein |
actually,
they will have so much money, they will build one, tear it down,
then make a new one from granite and gold |
| 13:52.51 |
Dr_Phreakenstein |
yeah |
| 13:52.52 |
d-lo |
ack, true.
theres a big heavy thing over my office too.... |
| 13:53.21 |
Dr_Phreakenstein |
hey, stop
calling Erik "the big heavy thing over my office" |
| 13:53.25 |
Dr_Phreakenstein |
sorry |
| 13:53.27 |
Dr_Phreakenstein |
that was
bad |
| 13:53.34 |
Dr_Phreakenstein |
did not mean
it |
| 13:53.36 |
``Erik |
heh, I'm one
over, he's talking about dave :D |
| 13:53.39 |
d-lo |
realizes that armed with this knowledge, Murphy and his laws
are putting d-lo at serious risk.... |
| 13:53.55 |
Dr_Phreakenstein |
:) |
| 13:53.58 |
``Erik |
pheer the
skeery dave on dave action that might happen O.O (or didja mean the
safe) |
| 13:54.19 |
Dr_Phreakenstein |
what's the
diff? |
| 13:54.33 |
d-lo |
retches and the mere beginnings of the mental picture 'Dave
on Dave Action' |
| 13:54.59 |
d-lo |
Hi, my name
is Dave and this is my Co-worker Dave and my other Co-worker
Dave. |
| 13:55.08 |
d-lo |
We work at a
freaky cloning factory. |
| 13:55.20 |
Dr_Phreakenstein |
anything like
that dude, what's his name... |
| 13:55.26 |
``Erik |
passes out mandatory flannel and those earflap
hats |
| 13:55.26 |
Dr_Phreakenstein |
rosie
o'donnel |
| 13:55.34 |
d-lo |
lawl. |
| 13:56.03 |
d-lo |
Mandatory
Flannel ...sounds like a punk rock band or the punch line to a
really bad joke... |
| 13:56.04 |
Dr_Phreakenstein |
ba-dum-che |
| 13:56.38 |
Dr_Phreakenstein |
sounds like
the hour when the rock stations plays only 90's
alternative |
| 13:56.39 |
``Erik |
wait, I think
dlo just called my wardrobe a really bad joke *sob* |
| 13:56.54 |
Dr_Phreakenstein |
... hey, and
mine |
| 13:57.01 |
d-lo |
Rosie is on
the list of "People to leave behind when we evacuate Earth during
Armageddon" |
| 13:57.19 |
Dr_Phreakenstein |
yeah, craft
not rated for that payload |
| 13:57.33 |
``Erik |
I thought she
was on the passenger list for the one we shoot into thte sun, isn't
that how simpsons portrayed it? |
| 13:57.38 |
d-lo |
``Erik: You
play the guitar, right? |
| 13:57.54 |
``Erik |
I beat on
strings and fake it |
| 13:58.02 |
d-lo |
Flannel
allowed then. |
| 13:58.11 |
Dr_Phreakenstein |
you know a
dude named Eric Johnson? |
| 13:58.28 |
d-lo |
Special Agent
Eric Johnson? |
| 13:58.31 |
Dr_Phreakenstein |
think
satriani, steve vai |
| 13:58.57 |
``Erik |
play a lot of
narvarna, alice in chains, soundgarden, ... and I lived in the
seattle area from '88 to '96, so I'll pretend I'm allowed to be a
throwback :D |
| 13:59.06 |
Dr_Phreakenstein |
nice! |
| 13:59.26 |
Dr_Phreakenstein |
AIC,
"would"... great bassline |
| 13:59.47 |
Dr_Phreakenstein |
simple, but
solid |
| 14:00.12 |
brlcad |
d-lo: there
aren't too many trees to worry about in the city, bigger concern
are ancient power poles in the alleys |
| 14:01.07 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:01.17 |
d-lo |
brlcad:
Ack... didn't even consider that... forgot that power isn't buried
everywhere.... |
| 14:01.29 |
d-lo |
brlcad: Still
have power? |
| 14:01.33 |
d-lo |
:D |
| 14:01.44 |
``Erik |
obviously he
doesn't |
| 14:01.45 |
``Erik |
:D |
| 14:02.09 |
d-lo |
has his router and modem on a dedicated UPS.
:P |
| 14:02.37 |
d-lo |
sometimes it
works... sometimes not. Depends on the ups in the Comcast cabinet
down the street. |
| 14:02.58 |
``Erik |
heh, yeah, my
cable modem, 'server' and wireless router are all on a fairly big
consumer grade ups |
| 14:03.39 |
d-lo |
``Erik: Hows
the cable modem feeling now adays? any better? |
| 14:04.26 |
Dr_Phreakenstein |
... in the
time it took to ask that, rates increased another $3 |
| 14:04.32 |
``Erik |
tracked it
down to a specific connection, might clean it and shoot some
silly-con or a little oil to fight off corrosion |
| 14:05.03 |
Dr_Phreakenstein |
deoxit |
| 14:05.06 |
d-lo |
Dr_Phreakenstein: aint that the
truth. |
| 14:05.08 |
``Erik |
need to clean
up my den so I can make the cable company come fix it, probably
needs the splitter replaced and upstream cable cut and
redone |
| 14:05.34 |
Dr_Phreakenstein |
don't
bother... cockcast? |
| 14:05.34 |
``Erik |
lacks a coax crimper |
| 14:05.44 |
Dr_Phreakenstein |
they will
make it worse, if and when they show |
| 14:06.06 |
d-lo |
i dunno,
their rates might be high, but I have had decent luck with the
techs that come out. |
| 14:06.16 |
Dr_Phreakenstein |
"tech" |
| 14:06.25 |
``Erik |
yeah, I tried
to call them out after an 8 hour service failure, soonest they
could schedule someone to look at it was 2 weeks away... ended up
working again "magically" so I never bothered |
| 14:06.53 |
Dr_Phreakenstein |
as in 6
grueling hours of how to say "I dunno, but it will cost more... and
save you money, somehow" |
| 14:07.13 |
``Erik |
amusingly, I
could probably drop off all my gear and cancel my service on the
way in to work, call, and have a tech out to install stuff when I
get home. but fixing something for someone already paying? 2
weeks. |
| 14:07.43 |
Dr_Phreakenstein |
cancel that
auto debit |
| 14:07.51 |
Dr_Phreakenstein |
they will be
more responsive |
| 14:07.53 |
Dr_Phreakenstein |
no
joke |
| 14:08.30 |
``Erik |
heh, never
bought into that, I don't like the notion of people taking money
from me without letting me audit and approve first |
| 14:09.11 |
d-lo |
well, i have
heard of *some* people who call in and cancel service knowing that
they probably won't get around to turning it off for a few
months... at which point they call back in and turn it on again.
gets a few free months out of it... |
| 14:09.50 |
Dr_Phreakenstein |
usually only
works for tv part |
| 14:10.10 |
Dr_Phreakenstein |
and then they
may never actually unhook phys connection |
| 14:10.30 |
Dr_Phreakenstein |
someone like
me, but legally distinct from me told a funny story |
| 14:10.41 |
``Erik |
they usually
don't, houses have pretty much all come pre-wired for cable for the
last 25 years |
| 14:10.51 |
Dr_Phreakenstein |
"he" used to
live in a 104 unit apt complex... |
| 14:11.18 |
Dr_Phreakenstein |
convinced all
neighbors to disconnect cable service |
| 14:11.27 |
Dr_Phreakenstein |
then
reconnected them |
| 14:11.43 |
Dr_Phreakenstein |
got them to
chip in for replacement locks for boxes... |
| 14:12.12 |
Dr_Phreakenstein |
also, bought
bolt cutters from Home Depot, used them for project, and returned
them when done |
| 14:12.23 |
Dr_Phreakenstein |
that guy is
great! |
| 14:12.52 |
Dr_Phreakenstein |
figured if
nobody started/stopped service, they would never come
out |
| 14:12.53 |
d-lo |
Well, there
is a fine line between being economical and being flat out cheap :D
Good story though. |
| 14:13.06 |
Dr_Phreakenstein |
:) |
| 14:13.29 |
Dr_Phreakenstein |
that may be
worse than cheap, but hey, those guys had it coming |
| 14:13.44 |
Dr_Phreakenstein |
sometimes ya
gotta enforce a little karma yourself |
| 14:14.31 |
Dr_Phreakenstein |
don't
remember his name... |
| 14:15.17 |
d-lo |
i'm sure
:) |
| 14:16.43 |
Dr_Phreakenstein |
:) |
| 14:18.25 |
d-lo |
brlcad: Do
you remember what the difference is between pkg_conn.pkc_inbuf and
pkg_conn.pkc_buf ? |
| 14:19.51 |
brlcad |
not off the
top of my head |
| 14:19.59 |
d-lo |
kk |
| 14:27.23 |
Dr_Phreakenstein |
goodnight,
kids |
| 14:27.48 |
``Erik |
later |
| 14:27.48 |
Dr_Phreakenstein |
be safe at
work, and watch out for falling daves, safes, and
powerlines |
| 14:28.44 |
Dr_Phreakenstein |
rember, US
plugs are dangerous! |
| 14:28.50 |
Dr_Phreakenstein |
remember |
| 14:29.35 |
d-lo |
as my Basic
Electricity Instructor always said: 60Hz?!? Why yes it
does! |
| 14:29.48 |
Dr_Phreakenstein |
:) |
| 14:30.45 |
starseeker |
estimates his car's wind profile and decides to risk
it... |
| 14:31.42 |
d-lo |
geek |
| 14:31.43 |
d-lo |
:) |
| 14:31.55 |
``Erik |
heh, I'd
heard at some point that the big safety problem with the US power
grid was more about the frequency, but it may've been damn swede
propoganda |
| 14:32.31 |
``Erik |
the wind
barely effected me on the way in, the suvs and trucks didn't seem
bothered, either |
| 14:38.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) |
| 14:38.49 |
``Erik |
contemplaes the next code hackery to
inflict |
| 14:39.37 |
d-lo |
options? |
| 14:39.37 |
``Erik |
uhm, mostly
isst shtuff |
| 14:39.37 |
d-lo |
right, but
what parts are on the chopping block? |
| 14:40.05 |
``Erik |
local library
linking (getting rid of distributed and the networking overhead)?
conversion to libpkg for distributed? arsing out the cut feature?
resizable windows? elimination of the mysql dependancy? |
| 14:40.32 |
d-lo |
I would go
with the pibpkg thing :) |
| 14:40.36 |
d-lo |
libpkg
even. |
| 14:40.44 |
``Erik |
only so you'd
have someone to ask questions of O.o :> |
| 14:41.06 |
d-lo |
that and see
another implementation of it to draw exp from :) |
| 14:41.16 |
d-lo |
either way,
its purely selfish :) |
| 14:41.19 |
``Erik |
hrm, the
tpkg.c thing isn't useful enough? |
| 14:42.07 |
d-lo |
its been a
huge help, but hasn't answered all my q's. |
| 14:42.50 |
d-lo |
I R Newb,
'member? |
| 14:43.18 |
``Erik |
surspects that with recent workstations, distributed is
actually a slowdown for isst, it runs awfully snappy with all 3
components running on the workstation, with the overhead of all
thsoe packet copies and the compression/decompession of it
all |
| 14:44.43 |
d-lo |
well, if you
are already operating at the far right of 'the curve' then yeah, no
reason for distributed. |
| 14:48.41 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33750 10/brlcad/trunk/src/adrt/slave/slave.c:
comment on a noticed crash, will deal with it later. |
| 15:02.57 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33751 10/brlcad/trunk/src/adrt/ (9 files in 3
dirs): move geometry loading stuff from slave/ to
libtienet/ |
| 15:03.55 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 15:28.29 |
*** join/#brlcad brlquestions
(n=user@60.Red-79-152-3.dynamicIP.rima-tde.net) |
| 15:37.39 |
d-lo |
<PROTECTED> |
| 15:39.45 |
``Erik |
uhm, doesn't
orbit have something to do that? or libidl? |
| 15:40.30 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D758.dip.t-dialin.net) |
| 15:40.59 |
d-lo |
dunno :) I
want something simple, lgpl and portable |
| 15:42.30 |
``Erik |
<-- has
only bothered with uuids in java, they seem like a using
thermobaric when a pistol would suffice most of the time
O.o |
| 15:43.40 |
d-lo |
well, I want
to make it as simple as the Java implementation... but If i have to
generate all 128 bits randomly, then so be it. Just don't know
much about random seeding and predictability on
computers. |
| 15:43.58 |
``Erik |
seeding is
just a number, random is not |
| 15:44.04 |
brlquestions |
Hi everybody
! |
| 15:44.36 |
``Erik |
but if you
hash the hostname (or a mac address), time and semirandom, it
should be good |
| 15:45.14 |
``Erik |
hrm, libuuid
is part of e2fsprogs |
| 15:45.26 |
d-lo |
exactly. If
its not as simple as randomly taking 128 bytes, then I might as
well find a simple lib rather than recreate the wheel. |
| 15:45.33 |
d-lo |
yeah saw that
one. |
| 15:45.52 |
``Erik |
the versions
are explicitely defined |
| 15:46.08 |
d-lo |
right, I just
want type 4 (Random) |
| 15:47.53 |
d-lo |
nm, OSSP
looks like a solid choice. thanks! |
| 15:50.21 |
``Erik |
ah, mit
license, cool beans |
| 15:51.50 |
brlquestions |
working on a brute force fillet ... CPU about to burn
! |
| 16:02.43 |
*** join/#brlcad samrose
(n=samrose@adsl-68-73-203-107.dsl.sfldmi.ameritech.net) |
| 17:04.53 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D758.dip.t-dialin.net) |
| 17:41.23 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-236-198.dclient.hispeed.ch) |
| 18:20.21 |
CIA-40 |
BRL-CAD:
03starseeker * r33752 10/brlcad/trunk/src/libged/ (glob.c qray.c):
(log message trimmed) |
| 18:20.21 |
CIA-40 |
BRL-CAD:
Problem with MGED starting up was due to errors getting returned by
ged commands |
| 18:20.21 |
CIA-40 |
BRL-CAD: if a
database was not open, despite this being a valid state to
attempt |
| 18:20.21 |
CIA-40 |
BRL-CAD:
commands. The fix is two-fold. First, glob.c has had its logic for
checking on |
| 18:20.23 |
CIA-40 |
BRL-CAD: the
state of the database moved to where it actually needs it - the
regexp |
| 18:20.25 |
CIA-40 |
BRL-CAD:
matching part. Second, if the wdbp is null return OK, and do this
BEFORE the |
| 18:20.27 |
CIA-40 |
BRL-CAD:
database open check. It may be that some libged commands will need
to make the |
| 18:25.46 |
starseeker |
so far,
opendb will successfully open a file but I don't get the background
color update specified in the .mgedrc file. However, I do get the
settings imported into the color preferences panel and can
successfully apply them |
| 18:26.36 |
starseeker |
I guess this
makes sense - if the user locally overrides the bkg color you don't
want it switching everytime a new file is opened |
| 18:27.05 |
starseeker |
wonder if
there should be a special case for no file previously
opened |
| 18:42.21 |
starseeker |
brlcad:
"gets" man page? |
| 18:44.00 |
starseeker |
you mean the
Tcl gets command? |
| 18:44.29 |
brlcad |
yes |
| 18:44.34 |
brlcad |
man n
gets |
| 18:45.07 |
starseeker |
do I set up a
standard tcl file handler and use that then? |
| 18:45.17 |
brlcad |
pretty sure
that problem is due to our gets replacement that handles the stdin
redirect, and it may just be logic that didn't get migrated to
ged |
| 18:46.37 |
brlcad |
sorry, mac
manual page doesn't have the example -- this: http://tmml.sourceforge.net/doc/tcl/gets.html |
| 18:46.38 |
starseeker |
the gets
manpage here has no example - is there another
somewhere? |
| 18:46.43 |
starseeker |
ah
:-) |
| 18:47.21 |
brlcad |
basically
that exact example won't work |
| 18:47.29 |
brlcad |
and of course
it should :) |
| 18:47.37 |
starseeker |
all
rightie... |
| 18:47.39 |
brlcad |
it's not a
tcl problem, it's because we replace gets |
| 18:47.48 |
brlcad |
so we're
doing something wrong |
| 18:47.50 |
starseeker |
with
ged_get? |
| 18:47.54 |
brlcad |
dunno |
| 18:48.00 |
brlcad |
might be
tcl-only in stc/tclscripts |
| 18:48.55 |
starseeker |
hmm |
| 18:49.28 |
brlcad |
check
ged/mged first |
| 18:56.36 |
brlcad |
example:
[morrison@ocho (Thu Feb 12 13:54:26) ~]$ brlcad-config --libs
bu |
| 18:56.37 |
brlcad |
-L/usr/brlcad/rel-7.12.6/lib -lbu -ltcl8.5
-Xlinker -framework CoreFoundation -lpng -lm -lpthread |
| 18:57.03 |
brlcad |
[morrison@ocho (Thu Feb 12 13:54:40) ~]$
brlcad-config --ldflags bu |
| 18:57.03 |
brlcad |
-L/usr/brlcad/rel-7.12.6/lib -pipe
-fno-strict-aliasing -fno-common -fexceptions
-Wl,-search_paths_first -Wnewline-eof -g -O3 |
| 19:05.08 |
starseeker |
brlcad: is
your error "can't read "line": no such variable ? |
| 19:07.38 |
brlcad |
yep |
| 19:07.49 |
brlcad |
or it'll
crash, can get a couple things |
| 19:08.26 |
brlcad |
might just
need an "upvar $varname" |
| 19:12.00 |
starseeker |
there's an
upvar $args vname |
| 19:18.25 |
starseeker |
interesting -
works in -c mode |
| 19:20.11 |
``Erik |
<PROTECTED> |
| 19:21.06 |
starseeker |
eh? |
| 19:21.28 |
starseeker |
what
happened? |
| 19:21.37 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33753 10/brlcad/trunk/src/libged/ (74 files):
remove executable property from .c files. |
| 19:21.47 |
starseeker |
ah - I was
wondering about that |
| 19:22.10 |
*** join/#brlcad _sushi__
(n=_sushi_@77-58-236-198.dclient.hispeed.ch) |
| 19:28.24 |
*** join/#brlcad samrose
(n=samrose@adsl-68-73-203-107.dsl.sfldmi.ameritech.net) |
| 19:29.23 |
CIA-40 |
BRL-CAD:
03davidloman * r33754 10/rt^3/trunk/ (31 files in 3 dirs): added a
simple uuid generation library from OSSP (http://www.ossp.org) |
| 19:33.30 |
d-lo |
hi
mafm! |
| 19:43.59 |
CIA-40 |
BRL-CAD:
03starseeker * r33755 10/brlcad/trunk/src/tclscripts/mged/text.tcl:
Add upvar for incoming variable so gets functions as expected on
mged command line. |
| 19:44.36 |
starseeker |
brlcad: you
called it - just took me a bit to figure out how to use it and
test |
| 19:44.42 |
brlcad |
cool |
| 19:45.19 |
starseeker |
mged -c and
mged work very differently in some ways, don't they |
| 19:46.30 |
CIA-40 |
BRL-CAD:
03starseeker * r33756 10/brlcad/trunk/TODO: Take gets bug off of
todo list - may have already fixed the File->Open but need to
confirm on more machines. |
| 19:50.34 |
louipc |
If jove is
deprecated should it be disabled by default? |
| 19:58.00 |
brlcad |
starseeker:
yep |
| 19:58.02 |
brlcad |
louipc:
meh |
| 19:58.54 |
starseeker |
brlcad:
File-Open is fixed? |
| 19:58.57 |
brlcad |
in the sake
of being completely self-contained, I think we should still provide
'some' minimal editor .. just not jove |
| 19:59.04 |
brlcad |
maybe an old
version of vi |
| 19:59.21 |
louipc |
ah
hehe |
| 19:59.38 |
brlcad |
but that'd be
pointless until I get a terminal ported anyways |
| 19:59.51 |
brlcad |
starseeker:
don't know |
| 20:00.05 |
brlcad |
i'm working
on something else |
| 20:00.24 |
louipc |
there aren't
any plans to deprecate mged -c are there? |
| 20:01.24 |
starseeker |
brlcad:
what's yep? |
| 20:01.47 |
starseeker |
oh, the mged
remark? |
| 20:02.04 |
``Erik |
likes mged -c, but would like jove to be removed sooner than
later :) |
| 20:02.19 |
louipc |
yeah |
| 20:05.09 |
``Erik |
what's a good
svn post-commit hook? the included one keeps failing with no useful
message |
| 20:05.58 |
starseeker |
we could
always use the original vi from 4BSD :-) |
| 20:06.38 |
starseeker |
thinks it would be cruel and unusual punishment for folks
used to jove though |
| 20:06.44 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1096600726.dsl.bell.ca) |
| 20:06.59 |
d-lo |
MUWAHAHAHA |
| 20:07.50 |
``Erik |
ed,
damnit. |
| 20:08.23 |
d-lo |
Ed is down
here talking to Bob. |
| 20:08.33 |
``Erik |
/bin/ed |
| 20:08.43 |
d-lo |
=D |
| 20:09.04 |
``Erik |
"I used ed to
edit files. Ed, go write me my files." |
| 20:09.22 |
louipc |
yeah I dunno,
I think editors are widespread enough that you shouldn't need to
ship one with your software, unless there's a particular need for
that editor |
| 20:09.38 |
d-lo |
I think Ed
needs a new sign on his door: "/bin/ed" |
| 20:09.51 |
``Erik |
we need to
have one in our 'special' list to launch stuff like red and oed and
those |
| 20:10.16 |
d-lo |
``Erik: so,
basicly, brlcad needs /special/ed ? |
| 20:10.23 |
d-lo |
:) |
| 20:10.31 |
louipc |
``Erik: a
guaranteed fallback? |
| 20:11.16 |
``Erik |
ed is the
guaranteed fallback ... :D src/mged/tedit.c |
| 20:11.23 |
louipc |
haha it
is |
| 20:11.54 |
``Erik |
will just delete that annoying emacs line and make it all
better O:-) |
| 20:13.43 |
``Erik |
hrm, on the
bsd's, emacs and vim tend to live in /usr/local/bin O.o wonder if
that should be done to have a set of paths and programs and permute
them, instead of singly hard coding that |
| 20:14.24 |
louipc |
yeah
probably |
| 20:14.36 |
``Erik |
having
/usr/bin/emacs and /usr/bin/vim seems a little wrong to me :D like
leenewx weenies who have never done critical system recovery and
don't know about partitions |
| 20:15.22 |
louipc |
we use live
cds |
| 20:15.28 |
louipc |
:D |
| 20:15.39 |
``Erik |
my cd's are
all inorganic, so, uh, dead |
| 20:18.44 |
louipc |
hmm this
could be a replacement candidate http://www.bostic.com/vi/ |
| 20:19.08 |
brlcad |
louipc:
heaven's no |
| 20:19.23 |
brlcad |
mged -c is
here to stay for probably as long as there is an mged |
| 20:19.42 |
brlcad |
starseeker:
that's actually what I was thinking of re old vi |
| 20:19.44 |
louipc |
brlcad: ok
good to hear |
| 20:20.59 |
brlcad |
louipc: the
point of shipping one is really "just in case" there isn't a system
editor (extreme portability, embedded environments, new platforms,
etc) |
| 20:22.12 |
brlcad |
or on the off
chance that it's a system that doesn't have things properly
configured, we do something sensible other than something stupid
like Can't open display: |
| 20:22.36 |
brlcad |
X11 being
particularly notorious for horrible messages |
| 20:25.41 |
brlcad |
``Erik: it is
wrong, none should be listed -- but jove makes for a horrible
default and letting it search PATH would be a security
weakness |
| 20:28.29 |
louipc |
nice. that vi
^ is smaller than nano |
| 20:29.21 |
``Erik |
oh, nvi,
that's the one included in the bsd's for /usr/bin/vi |
| 20:30.02 |
``Erik |
almost 71000
lines, ed is 3500 |
| 20:30.11 |
louipc |
haha |
| 20:31.22 |
d-lo |
Ed is rather
touchy about that, so just keep your voice down. |
| 20:38.42 |
``Erik |
vim weighs in
at 264,291, and emacs at 1,166,933 |
| 20:39.51 |
brlcad |
interestingly, vim is well past the point
at which folks used to complain about emacs' size back in the
90's |
| 20:39.56 |
``Erik |
hrm, I did
vim with sloccount, which eliminates blank lines and stuff, ed
scores 2750 and 45,326 when I use the same metric |
| 20:40.14 |
``Erik |
nvi
45k |
| 20:40.23 |
``Erik |
eight megs
and constantly swapping? |
| 20:40.32 |
starseeker |
plots to include nvi quietly one night... |
| 20:40.33 |
brlcad |
thinks ``Erik should write a drupal sloccount plugin for the
website |
| 20:40.37 |
louipc |
:D |
| 20:41.00 |
starseeker |
brlcad: How
much longer before we can strip out jove altogether? |
| 20:41.10 |
``Erik |
heh, I have
to fix my svn mail hook first, and do that command for mged
O.o |
| 20:41.43 |
brlcad |
starseeker:
see doc/deprecation.txt |
| 20:43.31 |
louipc |
looong
time |
| 20:43.35 |
brlcad |
thinks we should have a little "vgr" login widget on the
website ala cgi:irc where you could log onto a simh
session |
| 20:44.07 |
``Erik |
indeed |
| 20:44.12 |
brlcad |
basically
around 7.22 |
| 20:44.51 |
``Erik |
I was kinda
thinking.. mebbe it should spawn a fresh instance for every user
and let htem have root on a temp copy of the disk i
mage |
| 20:44.59 |
brlcad |
yeah |
| 20:45.19 |
brlcad |
actually a
whole lot harder to do anything but root probably |
| 20:45.30 |
``Erik |
plus a hell
of a lot more boring |
| 20:45.42 |
starseeker |
grumbles a little about having to leave jove in so long when
it can't handle files we might need it to... |
| 20:45.46 |
starseeker |
oh,
well |
| 20:45.53 |
brlcad |
another
interesting one would be a web-based mged where your command prompt
would send commands to an "mged -c" instance |
| 20:47.27 |
louipc |
attach
(nu|X|ogl|web)[nu]? |
| 20:47.36 |
brlcad |
heh |
| 20:53.48 |
CIA-40 |
BRL-CAD:
03brlcad * r33757 10/brlcad/trunk/ (AUTHORS include/raytrace.h
src/librt/db_comb.c): |
| 20:53.48 |
CIA-40 |
BRL-CAD: add
a new rt_comb_get_color() routine to librt that returns the color
for a |
| 20:53.48 |
CIA-40 |
BRL-CAD:
given combination. this change comes inspired by a code snippet
contribution |
| 20:53.48 |
CIA-40 |
BRL-CAD: from
Van Hoa Le (SAIC) that was using a similar routine for their
purposes. |
| 21:02.36 |
*** join/#brlcad IriX64_
(n=IriX64@bas2-sudbury98-1096600919.dsl.bell.ca) |
| 21:25.24 |
``Erik |
*grump* |
| 21:33.38 |
CIA-40 |
BRL-CAD:
03brlcad * r33758 10/brlcad/trunk/ (include/raytrace.h
src/librt/db_comb.c): oops, sry bob et al. fix typo and sig to
unbreak the build |
| 21:58.32 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 22:07.53 |
``Erik |
wow that's
slow |
| 22:18.18 |
*** join/#brlcad smurfette
(n=Pandora@c-69-242-189-29.hsd1.mo.comcast.net) |
| 22:26.16 |
*** join/#brlcad elite01_
(n=omg@unaffiliated/elite01) |
| 22:38.46 |
brlcad |
``Erik: fix
normals should probably be rewritten |
| 22:39.00 |
brlcad |
it's
presently an O(n^3) algorithm (or worse) |
| 23:00.46 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33759 10/brlcad/trunk/ (4 files in 3 dirs):
beginnings of nmg_fix_normals mged cmd |
| 23:07.44 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:28.53 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:39.30 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 01:40.34 |
``Erik |
O.o |
| 01:41.10 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
| 02:24.14 |
*** join/#brlcad inacio
(n=inacio@c-71-60-83-9.hsd1.pa.comcast.net) |
| 02:32.28 |
starseeker |
``Erik:
help |
| 02:33.05 |
``Erik |
heh, uh, O.o
no, the appropriate way to fix a light socket is not with a
paperclip? |
| 02:33.39 |
starseeker |
where would
autotools be getting lib/itcl3.4 instead of lib? |
| 02:34.01 |
``Erik |
erm, from a
script? |
| 02:34.12 |
starseeker |
ok, but which
script? |
| 02:34.34 |
``Erik |
<-- not
sure what you're talking about |
| 02:34.38 |
starseeker |
apparently no
one else is having this problem - me fears autotools is doing
something odd |
| 02:34.54 |
starseeker |
oh, my
itcl/itk installation is acting oddly |
| 02:35.04 |
starseeker |
I think it
may be why I can't start archer |
| 02:35.58 |
``Erik |
<-- never
really dicked with the itcl/itk stuff other than merging in some
cvs stuff to make it work with tcl85 |
| 02:36.17 |
starseeker |
ah |
| 02:36.54 |
starseeker |
hunts for some sort of "minimal" itk test
file |
| 02:38.17 |
``Erik |
to the best
of my knowledge, itcl/itk is a nasty hack to emulate basic oo type
stuff for tcl/tk, is going to be deprecated by tcl86 or something,
and I have no clue what it's used for or why in brlcad :D I haven't
spotted any of its goofy syntax in any tcl script I've dug into,
unless I'm mistaken about the goofiness of it |
| 02:38.47 |
starseeker |
uh
oh |
| 02:39.03 |
starseeker |
I think Bob
has been using it quite a bit, both in archer and possibly his
libtclcad |
| 02:39.21 |
``Erik |
is generally unhappy when he has to venture into tcl land,
likes the straight C path to rt* |
| 02:39.29 |
starseeker |
agrees |
| 02:39.48 |
``Erik |
were it lithp
or thcheme or thomething, I might feel differently |
| 02:40.11 |
``Erik |
but I was,
uh, mortified by tcl when I messed with it a little around a decade
ago for eggdrop stuff |
| 02:40.13 |
starseeker |
ironically
enough, this problem started when I tried to get a tcl/tk debugger
working in bwish in order to debug archer |
| 02:40.30 |
``Erik |
I even TRIED
to like it! it shared certain things I could claim were almost
scheme like |
| 02:40.57 |
``Erik |
meh, shoulda
just shoved a bunch of printf() and echo ""'s in |
| 02:41.07 |
starseeker |
apparently |
| 02:41.14 |
starseeker |
that just
feels so... crude |
| 02:41.20 |
starseeker |
to say
nothing of time consuming |
| 02:42.13 |
``Erik |
often uses printf() debugging in C, even though he knows gdb
reasonably well |
| 02:45.28 |
starseeker |
in this case,
I know what's failing - I'm just not sure WHY |
| 02:46.18 |
``Erik |
the nice
thing about the printf style is you pick and choose all the data
you want to examine and where, then just pull the trigger and get a
nice log of what the program did to contemplate |
| 02:46.39 |
``Erik |
instead of
setting break points and examining before continuing |
| 02:47.03 |
``Erik |
different
tools for different problems *shrug* dismissing one 'just because'
is limiting yourself :D |
| 02:47.33 |
starseeker |
oh, sure -
I've used printf sometimes too |
| 02:48.01 |
starseeker |
but in the
case of huge mass of code where I don't know what any of it is
doing... |
| 02:48.43 |
``Erik |
mass, or
mess? |
| 02:48.50 |
``Erik |
:D |
| 02:49.24 |
starseeker |
isn't ready to call it a mess yet... |
| 02:49.29 |
starseeker |
maybe
later |
| 02:49.41 |
``Erik |
<-- never
debugged tcl stuff where he didn't have a good idea of what was
going on and where the problem was before |
| 02:49.52 |
starseeker |
ah |
| 02:50.20 |
``Erik |
http://crit.brlcad.org:9090/
ucw sorta doing something almost semi interesting |
| 02:50.59 |
``Erik |
oddly, (push
val history) didn't work, but (setf history (cons val history))
did |
| 02:51.30 |
starseeker |
cool |
| 02:51.38 |
starseeker |
is impressed |
| 02:53.42 |
``Erik |
oh, heh, I
screwed something up |
| 02:56.35 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128565748.dsl.bell.ca) |
| 03:01.11 |
``Erik |
sweet,
idiocracy on tv |
| 03:04.12 |
Dr_Phreakenstein |
so... |
| 03:04.20 |
Dr_Phreakenstein |
isn't that
what is usually on? |
| 03:07.06 |
``Erik |
no, usually
it's idiotic, this is a movie mocking that :D |
| 03:07.14 |
``Erik |
starseeker:
fixed that ucw page, check it out now O.o |
| 03:07.53 |
starseeker |
heh -
neat? |
| 03:08.20 |
``Erik |
it's weired
wiring it up, I THINK that involves all teh hard pars |
| 03:08.21 |
``Erik |
parts |
| 03:08.38 |
starseeker |
wonders if anyone else has successfully muddled through
ucw |
| 03:08.54 |
``Erik |
um, there're
like, 4, apparently |
| 03:09.32 |
``Erik |
http://bees-kneesfilms.com is one
of the few ucw sites out there O.o |
| 03:16.51 |
*** join/#brlcad inacio
(n=inacio@c-71-60-83-9.hsd1.pa.comcast.net) |
| 03:19.15 |
``Erik |
wtf |
| 04:12.32 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 04:22.00 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 06:34.08 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 06:59.13 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128565748.dsl.bell.ca) |
| 07:02.59 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 07:26.05 |
mafm |
hi |
| 07:51.54 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:25.59 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:46.33 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:18.49 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33777 10/brlcad/trunk/src/libged/CMakeLists.txt:
additional include directory because of new TCL version |
| 09:37.14 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 09:40.12 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33778 10/rt^3/trunk/include/brlcad/common.h: new
constructor for Vector3D |
| 09:46.11 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33779 10/rt^3/trunk/ (4 files in 2 dirs): some
minor improvements |
| 09:47.15 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33780 10/rt^3/trunk/ (include/brlcad/Database.h
src/coreInterface/Database.cpp): Add() to add an object to the
database |
| 10:41.38 |
*** join/#brlcad madant
(n=madant@117.196.137.167) |
| 11:58.07 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33781 10/rt^3/trunk/ (3 files in 2 dirs): moved the
Hit and HitCallback objects into ConstDatabase.h and deleted the
now unnecessary header |
| 12:30.43 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 12:49.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-136.sbndin.btas.verizon.net) |
| 12:54.08 |
*** join/#brlcad inacio
(n=inacio@c-71-60-83-9.hsd1.pa.comcast.net) |
| 12:58.34 |
*** join/#brlcad inacio
(n=inacio@c-71-60-83-9.hsd1.pa.comcast.net) |
| 13:25.10 |
*** join/#brlcad Satisfied
(n=soros@d57-90-79.home.cgocable.net) |
| 13:30.05 |
Satisfied |
i'm looking
for a cad program for a number of small projects that involves gear
trains and pulley systems.... is brlcad appropriate or should i
look into one of the commercial packages like solidworks or
inventor? |
| 13:34.18 |
``Erik |
are you
looking for something to automatically tell you ratios and number
of teeth and stuff, or model it? and are you looking for drafting
output, or just visualization/analysis? |
| 13:34.35 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:37.02 |
Satisfied |
well, I'm not
anxious to spend hours constructing gears manually. I think
Inventor has builtin templates that for the standard involute
curves and such |
| 13:37.28 |
``Erik |
hm, we have
template and pattern tools, but no automagic gear build |
| 13:37.41 |
_sushi_ |
Satisfied: I
even had to write a complicated program to approximate threads from
oblique cylindrical slices |
| 13:37.57 |
_sushi_ |
The result is
that BRL-CAD becomes overwhelmed with the number of component and
the partitioning algorithm clogs |
| 13:38.09 |
``Erik |
overwhelmed,
or just slow? :D |
| 13:38.12 |
_sushi_ |
BRL-CAD
doesn't have any thread primitive |
| 13:38.25 |
_sushi_ |
``Erik: well
it renders horribly slow |
| 13:38.41 |
_sushi_ |
Just because
there are 20,000 non-overlapping slicesw |
| 13:38.51 |
``Erik |
ohyeah, your
freaky cut case |
| 13:38.53 |
``Erik |
that was
weird |
| 13:38.56 |
_sushi_ |
and one cut
through all that |
| 13:39.03 |
_sushi_ |
with the cut
it's 216 times slower as with |
| 13:39.05 |
``Erik |
john added
the -k to make that go fast for you |
| 13:39.19 |
_sushi_ |
We already
talked about this with Sean and he said there is nothing that can
be done against it |
| 13:39.27 |
_sushi_ |
Well -
BRL-CAD is still the choise #1 :) |
| 13:39.40 |
_sushi_ |
``Erik: what
does the -k do? |
| 13:39.44 |
``Erik |
(there's
something you WON'T see with inventor or solidworks or catia,
satisfied, we listen to the "little guy" users ;) |
| 13:39.52 |
``Erik |
rt -k
<cutting plane> |
| 13:39.55 |
_sushi_ |
``Erik: right
I agree |
| 13:40.18 |
_sushi_ |
``Erik: maybe
I could try to incorporate that into the scripts |
| 13:41.05 |
_sushi_ |
``Erik: right
that's what I hate on commercial packages - they are like if you
don't like it fuck you you already gave us your money |
| 13:41.13 |
``Erik |
but like a
bicycle gear would be something like a squat cylinder to make the
disc, subtract the hole, subtract one cutout for the link, then use
clone or pattern to zip around the edge of the disc, and sub those
tooth cylinders, bam, done |
| 13:41.23 |
_sushi_ |
here you
don't have to give away any money, get the source code plus a
reasonable support |
| 13:41.41 |
_sushi_ |
``Erik: a
bicycle cogwheel would be extremely simple I think |
| 13:41.51 |
_sushi_ |
I am not sure
how I would do the invloute for an ordinary gear though |
| 13:42.04 |
``Erik |
cut an arb8
for a sharp tooth |
| 13:42.27 |
``Erik |
union two
cylinders and cut that comb for a pedal tooth |
| 13:42.52 |
_sushi_ |
but teeth are
not cylinders but some complicated math curve called involute
aren't they? |
| 13:43.11 |
``Erik |
<-- dunno,
archivist is the gearmaster here :D |
| 13:43.29 |
_sushi_ |
But I think
some primitives could be integrated into the program |
| 13:43.32 |
``Erik |
I stay in the
low level guts myself |
| 13:43.37 |
_sushi_ |
But you won't
take my code since it's GPL only :) |
| 13:43.53 |
``Erik |
I thought we
had some gpl pieces already |
| 13:43.57 |
_sushi_ |
And Sean said
something I would have to transfer the copyright |
| 13:44.06 |
``Erik |
ohhh,
yeah |
| 13:44.15 |
_sushi_ |
At least you
could link my tool from your homepage |
| 13:44.22 |
``Erik |
make a wiki
for it |
| 13:44.23 |
``Erik |
:D |
| 13:44.25 |
_sushi_ |
I think in
some jurisdictions this is not even possible |
| 13:44.27 |
``Erik |
wiki
page |
| 13:44.33 |
_sushi_ |
You write
something you have the (c) and you can't give it up |
| 13:44.45 |
_sushi_ |
You can
licence sublicence but not transfer it's you who made it you have
the copyright |
| 13:45.10 |
``Erik |
yeah, the US
isn't like that, and gets really ugly when you start talking things
like "work for hire" issues |
| 13:45.41 |
_sushi_ |
Here is the
thread tool http://ronja.twibright.com/3d/lib/thread.c |
| 13:45.55 |
_sushi_ |
And here is
the hex tool http://ronja.twibright.com/3d/lib/hex.c |
| 13:46.09 |
_sushi_ |
Writing a doc
for it would take too much time for me |
| 13:47.21 |
_sushi_ |
There are
some random thread tables picked from the Internet and embedded
into the program |
| 13:47.40 |
_sushi_ |
It's for
metric only, I have no clue about withworth threads |
| 13:47.53 |
``Erik |
should
probably slap the GPL header on those so'z people know it's
gpl |
| 13:48.02 |
_sushi_ |
All I know
about them is a) they are used on water pipes, b) they are used on
camera and c) they are next to impossible to get here |
| 13:49.16 |
_sushi_ |
``Erik: you
want a full GPL header? |
| 13:50.06 |
``Erik |
I'm just
sayin', GPL demands the gpl header on all files under the gpl,
no? |
| 13:51.14 |
_sushi_ |
where the
fuck do I get this header? |
| 13:51.19 |
_sushi_ |
I am googling
and getting just junk! |
| 13:51.35 |
``Erik |
it's in the
gpl license itself |
| 13:52.40 |
_sushi_ |
is unable to find GPL quickjly |
| 13:53.14 |
``Erik |
http://ronja.twibright.com/3d/lib/thread.c |
| 13:53.17 |
``Erik |
damnit |
| 13:53.24 |
``Erik |
http://bz.bzflag.bz/~erik/gpl.h |
| 13:53.33 |
``Erik |
there ya go,
fill in the blanks :) |
| 13:53.40 |
_sushi_ |
thanks youre
my savior |
| 13:54.00 |
``Erik |
hardly, heh
:D |
| 13:55.47 |
``Erik |
Satisfied:
BRL-CAD is free, download it and give it a try :) we even have
tutorials at http://brlcad.org and
a reasonably active channel here :) |
| 13:55.52 |
_sushi_ |
warning:
million pointer targets differ from billion others |
| 13:56.12 |
_sushi_ |
And it also
rulez |
| 13:57.31 |
_sushi_ |
``Erik: here
with header: http://ronja.twibright.com/3d/lib/hex.c |
| 13:58.51 |
``Erik |
heh, *shrug*
I don't care too much, was just pointing out one of those
non-technical issues that seem to be important these days
(unfortunately) |
| 13:59.18 |
_sushi_ |
``Erik: oh I
thought it's an obstacle |
| 14:00.23 |
``Erik |
nah, just
advice on protecting yourself :) |
| 14:00.47 |
_sushi_ |
What does a
GPL header protect me against? |
| 14:01.13 |
``Erik |
hm,
src/mged/point/ src/other/libpng/ other/tcl/generic/tclDate.c and
src/tab/script.c all seem to be GPL'd |
| 14:02.00 |
``Erik |
some
theoretical protection of your 'intellectual property', and is a
way of letting fellow developers know how they can use your
code |
| 14:02.09 |
``Erik |
without a
header, people might assume it's public domain |
| 14:02.34 |
``Erik |
src/other/libpng/contrib
rather |
| 14:02.39 |
_sushi_ |
``Erik:
that's maybe in the US, here if you don't have any info then you
have to assume it's proprietary |
| 14:03.41 |
``Erik |
<-- ain't
a lawyer, just read that lawyers say it's a good idea to mark your
work with copyright info and if necessary, license info
*shrug* |
| 14:04.04 |
starseeker |
here's a
spring subtracted from an rcc http://bzflag.bz/~starseeker/thread_test.png |
| 14:04.59 |
_sushi_ |
looks like
the thread in which ball bearings run |
| 14:05.09 |
starseeker |
heh |
| 14:05.13 |
starseeker |
just a quick
test |
| 14:05.30 |
starseeker |
tries an arb8 cut, just out of curiosity |
| 14:05.51 |
``Erik |
nerds |
| 14:05.58 |
_sushi_ |
http://ronja.twibright.com/3d/hardware_4.png |
| 14:06.04 |
_sushi_ |
How did you
make the spring? |
| 14:06.18 |
``Erik |
http://static.arstechnica.com/2009/02/15/evercrack.jpg
nice |
| 14:07.51 |
starseeker |
pipe
primitive |
| 14:08.02 |
_sushi_ |
how do you
make a helix with the pipe primitive? |
| 14:11.19 |
starseeker |
it's
documented in Volume III |
| 14:11.43 |
starseeker |
I'm working
on a procdb to automate it, but it's not done yet |
| 14:12.21 |
starseeker |
http://bzflag.bz/~starseeker/thread_cut.png |
| 14:12.39 |
starseeker |
doesn't seem
to be incredibly slow, but I don't have 200+ threads
either |
| 14:15.14 |
starseeker |
_sushi_:
Given time, I might be able to duplicate that setup using a pipe,
but I don't know that there would be much performance
benefit |
| 14:15.42 |
_sushi_ |
And you would
get non-metric thread shape |
| 14:16.11 |
_sushi_ |
http://www.mech.uwa.edu.au/DANotes/threads/mechanics/recircBallBIG.jpeg |
| 14:16.54 |
starseeker |
non-metric? |
| 14:17.03 |
starseeker |
heh - that's
cool |
| 14:17.19 |
starseeker |
talk about a
great candidate for a brlcad model |
| 14:17.50 |
_sushi_ |
starseeker:
normal threads don't look like what you've done |
| 14:17.55 |
_sushi_ |
The thread
has a different shape |
| 14:18.00 |
starseeker |
sure |
| 14:18.15 |
starseeker |
what I did
was a quick test using a spring I happened to have
around |
| 14:18.43 |
starseeker |
I take it you
were able to do metric thread? |
| 14:23.49 |
_sushi_ |
It's not
exactly metric because it has near sinusoidal shape |
| 14:23.53 |
_sushi_ |
But it looks
like metric :) |
| 14:24.16 |
_sushi_ |
metric is
V-shape with round ends |
| 14:24.41 |
_sushi_ |
Actually only
the convex end is round the concave one is V |
| 14:26.04 |
starseeker |
it might be
possible to do that with some insane combination of existing
primitives, but it would be difficult and would almost have to be
scripted |
| 14:26.37 |
_sushi_ |
wouldn't it
be possible to make a thread primitive? |
| 14:26.53 |
_sushi_ |
Cause a
thread is just a stack of slices where the slice
rotates |
| 14:27.11 |
_sushi_ |
Therefore a
cylinder equation would suggest a rough place where the ray
hits |
| 14:27.19 |
starseeker |
that's what
I'm thinking - pipe indicates it is possible, but meta-primitives
like pipe are (geometrically) composed of more simple
primitives |
| 14:27.29 |
_sushi_ |
And then some
local iteration would give the exact place of the hit |
| 14:27.34 |
starseeker |
a sweep
primitive would allow it |
| 14:27.46 |
_sushi_ |
what's a
sweep primitive? |
| 14:28.11 |
starseeker |
basically a
generalization of extrude |
| 14:28.24 |
starseeker |
take a
sketch, and sweep it through 3D space |
| 14:28.25 |
_sushi_ |
if you can
sweep along a spiral... |
| 14:28.27 |
starseeker |
right |
| 14:28.45 |
starseeker |
rotate would
be another subset of sweep |
| 14:29.11 |
_sushi_ |
but this is
rotation and translation running at the same time |
| 14:29.25 |
starseeker |
right -
that's why it would take a general sweep primitive |
| 14:29.28 |
starseeker |
which we
don't have yet |
| 14:29.52 |
_sushi_ |
you can
either sweep a little circle along a spiral |
| 14:30.12 |
_sushi_ |
Or you can
sweep a large slightly eccentric circle along a straight line and
rotate it in the process |
| 14:30.15 |
starseeker |
with sweep,
we would sketch the exact profile of the thread, and sweep in a
spiral |
| 14:30.24 |
_sushi_ |
Or you can
sweep a square and get a funky 4-gang thread |
| 14:30.52 |
starseeker |
_sushi_:
there's a project - make a sweep primitive :-) |
| 14:30.53 |
_sushi_ |
How would you
make a conical thread |
| 14:30.58 |
_sushi_ |
like you have
on wood screws> |
| 14:31.10 |
starseeker |
tries to visualize that |
| 14:31.16 |
_sushi_ |
Would be nice
if we could at least model everything they have in hardware
store |
| 14:31.26 |
_sushi_ |
without
choking the system with a $ 0.1 item |
| 14:31.51 |
starseeker |
_sushi_
thread modeling is not one of our normal use cases |
| 14:31.51 |
_sushi_ |
we have this
height field primitive right? |
| 14:32.02 |
starseeker |
that's out of
date, I believe |
| 14:32.18 |
_sushi_ |
do we have
some kind of bump map? |
| 14:32.45 |
_sushi_ |
cause thread
is a kind of periodical bump map mapped on a cylinder or cone
:) |
| 14:33.10 |
_sushi_ |
Where the
parameter is some combination of the position and angle |
| 14:33.15 |
starseeker |
_sushi_: If
we were going to do it "right", it would be by creating the sweep
primitive |
| 14:33.45 |
_sushi_ |
but imagine
the system throws a ray and if you have 100 turns it has to test
each of them for intersection |
| 14:33.59 |
starseeker |
it's an
optimization problem |
| 14:34.05 |
_sushi_ |
Whereas if
you map on surface you calculate approx place of hit and then just
reiterate to get the exact one |
| 14:34.33 |
_sushi_ |
there's an
interesting electrical component called conical coil |
| 14:34.35 |
starseeker |
probably will
need to go into the details with brlcad |
| 14:34.39 |
_sushi_ |
Which is a
coil wound on a cone :) |
| 14:34.47 |
starseeker |
pipe can
probably do that |
| 14:34.53 |
louipc |
how does the
pipe primitive work? |
| 14:35.06 |
starseeker |
combinations
of cylindars and tori, IIRC |
| 14:35.15 |
louipc |
isn't it like
a psudo primitive? ok |
| 14:35.28 |
starseeker |
I consider it
an example of a metaprimitive |
| 14:35.36 |
louipc |
so you could
expand it to maybe use other shapes other than rcc |
| 14:35.51 |
louipc |
and you would
get the correct shape for what type of thread you want |
| 14:36.07 |
starseeker |
you might be
able to use the logic behind pipe for such purposes, but it
wouldn't be "plug and play" |
| 14:36.19 |
louipc |
like
60degree, acme, square threads |
| 14:36.24 |
starseeker |
that would be
a new primitive |
| 14:36.25 |
louipc |
yeah |
| 14:36.30 |
starseeker |
sweep
:-) |
| 14:36.45 |
louipc |
hmm |
| 14:37.29 |
starseeker |
one of the
earlier projects created part of a revolve primitive, as a stepping
stone to the general case |
| 14:37.35 |
starseeker |
gsoc
project |
| 14:37.49 |
louipc |
yeah you
would need sweep |
| 14:38.15 |
starseeker |
it would be
VERY powerful, given a proper sketch editor |
| 14:38.28 |
louipc |
hehe |
| 14:38.41 |
starseeker |
ours needs a
little help, I'm afraid |
| 14:38.55 |
starseeker |
it does make
a bit more sense now that I understand the data
structures |
| 14:39.41 |
starseeker |
IIRC, sweep
and revolve of sketches is actually a pretty common paradigm in
other cad systems for shape creation |
| 14:39.59 |
starseeker |
its very
general |
| 14:41.26 |
louipc |
yep,
especially for cylindrical stuff |
| 14:41.39 |
starseeker |
the advantage
of CSG the way we do it is that it constrains the model into
representing things with simple geometry. |
| 14:41.40 |
louipc |
lathework |
| 14:42.00 |
starseeker |
that has both
benefits and limitations |
| 14:42.19 |
starseeker |
as long as
the simple geometric representation is a good approximation, it's
better |
| 14:42.27 |
louipc |
yeah |
| 14:42.32 |
starseeker |
where "good"
is defined by the application |
| 14:42.36 |
louipc |
well you have
to choose the right tool for the application |
| 14:42.44 |
louipc |
jinx |
| 14:42.47 |
starseeker |
obviously for
precision surface creation, it's not ideal |
| 14:43.11 |
starseeker |
but then we
don't model too many sports cars ;-) |
| 14:43.49 |
starseeker |
may be speaking too soon though, given brlcad's new
car |
| 14:43.59 |
starseeker |
OK, time to
start getting chores done |
| 14:47.33 |
archivist |
``Erik, I
heard my name :) |
| 14:47.33 |
starseeker |
Not sure what
this paper is or if it is any good, but Figure 10 gives a
reasonable example of what a swept primitive looks like: http://www.unknownroad.com/publications/SweepsTRApril2005.pdf |
| 14:47.33 |
``Erik |
there was
talk about BRL-CAD's ability to do gears :D |
| 14:47.43 |
starseeker |
intends to do that |
| 14:47.53 |
starseeker |
but must do
chores/shopping first |
| 14:47.54 |
archivist |
many sorts of
gears exist |
| 14:48.07 |
starseeker |
should make a
fun tool :-) |
| 14:48.15 |
archivist |
and some have
the fiddle factors |
| 14:48.24 |
starseeker |
tire all over
again :-) |
| 14:49.10 |
``Erik |
bump map is a
visual hack based on normals and exists in shader land...
displacement map would be a closer notion, but is still a shader
issue, not true geometry |
| 14:50.52 |
``Erik |
starseeker:
did you see the updated ucw thingy? |
| 15:03.30 |
starseeker |
the roman
numerals? |
| 15:03.34 |
starseeker |
yeah, that
was cool |
| 15:04.31 |
``Erik |
where you
could input? the first one I showed had the input part broken
:) |
| 15:04.43 |
starseeker |
yeah, input
worked :-) |
| 15:04.56 |
``Erik |
okie, now to
figure out something 'real' to do to extend my knowledge
heh |
| 15:05.03 |
starseeker |
:-) |
| 15:05.11 |
starseeker |
gets real with laundry :-( |
| 15:05.29 |
``Erik |
the guy to
look at my door jam is late |
| 15:24.07 |
*** join/#brlcad jin354
(n=jin354@161.130.146.120) |
| 15:53.51 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 15:59.05 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F777.dip.t-dialin.net) |
| 16:55.39 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:33.59 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:38.40 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:44.35 |
*** join/#brlcad punkrockg
(n=Pandora@c-69-242-189-29.hsd1.mo.comcast.net) |
| 18:47.07 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 19:38.05 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 20:16.37 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 20:39.17 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-136.sbndin.btas.verizon.net) |
| 21:02.08 |
*** join/#brlcad samrose
(n=samrose@sa-ga143065.reshsg.uci.edu) |
| 21:14.20 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-241-205.dclient.hispeed.ch) |
| 21:51.09 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F777.dip.t-dialin.net) |
| 22:51.01 |
*** join/#brlcad samrose
(n=samrose@sa-ga143065.reshsg.uci.edu) |
| 00:16.38 |
*** join/#brlcad BigAToo
(n=BigAToo@mail.fbcelkhart.org) |
| 01:18.58 |
``Erik |
damnit |
| 01:19.06 |
starseeker |
eh? |
| 01:20.59 |
``Erik |
my car broke
down at the gate |
| 01:21.05 |
``Erik |
I just got
home |
| 01:21.10 |
starseeker |
that
SUCKS |
| 01:21.16 |
starseeker |
which
gate? |
| 01:21.18 |
``Erik |
and tomorrow,
I get to walk to the dealership to get them to fix it |
| 01:21.20 |
``Erik |
the 22
gate |
| 01:21.24 |
starseeker |
yuck |
| 01:21.41 |
``Erik |
had it towed
to the dealership right by my house *sigh* |
| 01:22.17 |
``Erik |
is starting to ponder aaa |
| 01:22.27 |
``Erik |
I think the
alternator went out |
| 01:22.37 |
starseeker |
ow |
| 01:23.31 |
``Erik |
while it's
in, I think I'll have them do the front brakes and see if I can get
the faulty ESC replaced under warrantee |
| 01:24.17 |
``Erik |
but tonight,
I have some DRINKIN' to do |
| 01:24.59 |
starseeker |
won't that
preclude functioning tomorrow? |
| 01:25.02 |
``Erik |
huh,
remanufactured alternator is 200-250 |
| 01:25.20 |
``Erik |
no, I tend to
function fairly well |
| 01:25.35 |
``Erik |
hell, if I
show up to work on time, that means I was drinking the night
before... for some reason, I wake up early and ready to
go |
| 01:26.19 |
``Erik |
german, irish
and scottish genes, catholic upbringing... :D |
| 01:26.37 |
starseeker |
ah
:-) |
| 01:26.39 |
``Erik |
not enough
native american to slow me down on that |
| 01:30.07 |
starseeker |
feels sympathy for ``Erik's liver |
| 01:30.20 |
starseeker |
<wince> |
| 01:32.28 |
starseeker |
brlcad: If
search's results are to be used by other commands, should there be
an output option that builds a bu_list of matches? What's a good
way to do "data exchange" on that? |
| 01:33.33 |
starseeker |
glares at clock and decides to get outta here,
bbl |
| 01:37.10 |
``Erik |
try not to
lose an alternator :D |
| 02:17.10 |
Dr_Phreakenstein |
Erik; geico
includes roadside assistance standard |
| 02:17.40 |
``Erik |
allstate
wants to charge for it |
| 02:18.25 |
Dr_Phreakenstein |
plus, you can
save 10-15% in just 15 minutes by calling.. |
| 02:18.55 |
Dr_Phreakenstein |
but
seriously, they are a great company |
| 02:19.08 |
Dr_Phreakenstein |
my wife had a
wreck, her fault... |
| 02:19.20 |
Dr_Phreakenstein |
they took
care of everything, no hassle |
| 02:27.57 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 02:27.57 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 02:30.01 |
Dr_Phreakenstein |
understand |
| 02:43.07 |
yukonbob |
hello
cadheads |
| 02:50.11 |
Dr_Phreakenstein |
hello
yukonbob |
| 03:52.01 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177680293.dsl.bell.ca) |
| 03:52.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 04:05.54 |
``Erik |
bleh |
| 04:53.48 |
brlcad |
starseeker:
yep, I mentioned having a list option at some point .. actually
being in ged helps because you could make a generic output handler
that is wraps obtaining the result in some programmatic
form |
| 04:57.34 |
brlcad |
don't know if
bob got that far in the ged struct, but the idea was to modify the
commands to perform something like ged_log that would either append
to the result_str or bu_log or call a callback handler depending on
the ged struct |
| 05:00.50 |
brlcad |
then you'd
have make some callback that does whatever you want (like fill a
bu_list with bu_vls results) for your application |
| 05:14.16 |
*** join/#brlcad samrose
(n=samrose@sa-ga143065.reshsg.uci.edu) |
| 07:53.43 |
*** join/#brlcad samrose
(n=samrose@sa-ga143065.reshsg.uci.edu) |
| 08:16.59 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33806 10/brlcad/trunk/src/libged/gqa.c: changed to
classical C syntax |
| 08:48.42 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:09.54 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:11.42 |
d-lo |
``Erik:
bummer... you might wanna consider replacing the battery at the
same time as the alternator... a failure of one tends to damage the
other... |
| 11:13.00 |
d-lo |
uses gieco, but has respect for allstate... they took care of
my wife (well, 'to be' wife at the time) when she had an
accident |
| 11:18.38 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 11:41.28 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:52.32 |
CIA-40 |
BRL-CAD:
03brlcad * r33807 10/brlcad/trunk/ (include/pkg.h
src/libpkg/pkg.c): pkg is a good library to start with. refactor
the API documentation out of the implementation file into the
header. need to get doxygen running again in order to also add the
groups/categories and section descriptions. |
| 13:56.02 |
CIA-40 |
BRL-CAD:
03brlcad * r33808 10/brlcad/trunk/src/other/tcl/generic/ (tcl.h
tclDecls.h): quell shadow warnings on index |
| 13:58.57 |
CIA-40 |
BRL-CAD:
03brlcad * r33809 10/brlcad/trunk/src/libpkg/tpkg.c: quell all
extra warnings |
| 13:59.11 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.141) |
| 14:07.51 |
CIA-40 |
BRL-CAD:
03brlcad * r33810 10/brlcad/trunk/include/pkg.h: brevity
consistency |
| 14:08.04 |
PrezKennedy |
i hate
bittorrent so much |
| 14:22.06 |
CIA-40 |
BRL-CAD:
03brlcad * r33811 10/brlcad/trunk/src/libpkg/pkg.c: quell all the
additional warnings minus conversion warnings that can't be quelled
due to the short int prototype |
| 14:22.41 |
louipc |
PrezKennedy:
the protocol? |
| 14:24.45 |
``Erik |
no, he hates
that my new hobby is taking bittorrent movies, editing them so
images of "goatse" and "lemonparty" show up in various places, and
redistributing them :D *duck* |
| 14:24.59 |
brlcad |
paid extra to get roadside assistance with geico .. no longer
have that on my policy though |
| 14:25.02 |
louipc |
hahah! |
| 14:25.32 |
starseeker |
``Erik:
congratulations on the most useless hobby I've ever heard
of |
| 14:25.37 |
CIA-40 |
BRL-CAD:
03brlcad * r33812 10/brlcad/trunk/configure.ac: |
| 14:25.37 |
CIA-40 |
BRL-CAD:
-Wconversion is rather useless since it's mostly for supporting
non-ansi |
| 14:25.37 |
CIA-40 |
BRL-CAD:
compilation where you often don't have a prototype and end up with
default |
| 14:25.38 |
CIA-40 |
BRL-CAD:
parameter types. as a warning category, though, this just causes a
lot of |
| 14:25.39 |
``Erik |
</joke> |
| 14:25.40 |
CIA-40 |
BRL-CAD:
unquellable warnings where shorts are used in a prototype. since
they'd be |
| 14:25.40 |
``Erik |
:D |
| 14:25.42 |
CIA-40 |
BRL-CAD:
passed as (int), they flag a warning but are completely correct
as-is so remove |
| 14:25.44 |
CIA-40 |
BRL-CAD:
-Wconversion |
| 14:25.45 |
louipc |
that's an
awesome hobby |
| 14:26.28 |
starseeker |
even shooting
tin cans in the backyard at least builds skills (well, OK,
depending on intoxication levels...) |
| 14:26.33 |
louipc |
I imagine
working at a tv station and doing that |
| 14:26.41 |
louipc |
:D |
| 14:26.44 |
``Erik |
I d'no, I
called the bmw roadside assistance, even though I didn't have
membership, they charged me a straight $120 for "getting shit taken
care of" (towed to the dealership and dropped off at home), gotta
wonder what the rate of requiring that service is to make it worth
the cost |
| 14:27.13 |
starseeker |
louipc: Was
that you with the porno clip in the Arizona station on superbowl
day (or whenever that was?) |
| 14:27.15 |
brlcad |
``Erik: if
you're up for it and didn't see the notice already, there's a
libpng update worth getting.. |
| 14:27.18 |
PrezKennedy |
louipc, no --
i hate when people who use it max out the connection and prevent
everything else from working correctly |
| 14:27.19 |
``Erik |
and this is
the first time in my life I've ever needed to be towed or help or
anything |
| 14:27.27 |
brlcad |
really? |
| 14:27.30 |
brlcad |
that's messed
up :) |
| 14:27.35 |
``Erik |
uhm, yeah,
probably zlib, too |
| 14:27.53 |
louipc |
PrezKennedy:
hah ok |
| 14:27.58 |
``Erik |
oh, that
superbowl thing was amusing, but it was a lame porn clip to
interject |
| 14:28.22 |
louipc |
starseeker: I
wish I could take credit |
| 14:29.32 |
``Erik |
not sure if I
should bother with upgrading libpng right now or see if I can track
out the weird maus behavior on leopard |
| 14:29.41 |
``Erik |
or dick with
more adrt/isst/etc shit |
| 14:29.53 |
``Erik |
bit annoyed
that lee is calling his thing isst now :/ |
| 14:30.10 |
PrezKennedy |
[p]isst |
| 14:34.55 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33813 10/brlcad/trunk/NEWS: Mention
nmg_fix_normals. It works, but is not registered in $mged_cmds yet
(so no tab completion). |
| 14:40.22 |
brlcad |
``Erik: only
want you'll be able to counter that is by making isst work again on
people's desks.. |
| 14:42.01 |
brlcad |
document it
with a little tutorial, make it "just work", yada yada |
| 14:45.37 |
brlcad |
``Erik: also
src/tclscripts/mged/help.tcl <-- that's where it's missing for
tab-completion |
| 14:46.11 |
brlcad |
mged_cmds
expands off of the ? command, the ? command expands off of the
mged_help_data array |
| 14:46.14 |
``Erik |
hm, coulda
sworn I had put it in there at some point and it didn't
work |
| 14:46.29 |
brlcad |
leaves the rest as an exercise to the
reader |
| 14:47.23 |
``Erik |
once isst
gets the mysql stuff ripped out and the network crap bypassed,
it'll "just work" :/ *sigh* |
| 14:48.08 |
archivist |
mysql suph
should be inserted not ripped out :) |
| 14:49.03 |
``Erik |
mysql is a
pile, postgres is far superior :D and for simply holding triangles,
the kinda database that shoulda been used is called a
"file" |
| 14:49.06 |
``Erik |
:D |
| 14:49.08 |
brlcad |
archivist:
you think a simple interactive 3D viewer should need a mysql
database in order to run? |
| 14:49.19 |
starseeker |
winces |
| 14:49.39 |
archivist |
brlcad,
no |
| 14:50.02 |
brlcad |
hence the
need to rip it out ;) |
| 14:50.31 |
archivist |
but I am
biased to mysql :) |
| 14:50.54 |
d-lo |
bias != speed
|| functionality :P |
| 14:51.22 |
archivist |
speed with
good design in databases |
| 14:51.28 |
``Erik |
lately, I've
been kinda thinking that the entire sql rdbms notion is
fail |
| 14:51.43 |
``Erik |
that's the
thing, mysql is fast in meaningless microbenchmarks, but pigassed
slow on REAL queries |
| 14:52.02 |
``Erik |
because you
have to go through stupid hoops like temporary tables for subselect
and more complicated joins |
| 14:52.13 |
archivist |
fix the
sql |
| 14:52.30 |
archivist |
rewrite
subquries as joins |
| 14:53.39 |
``Erik |
hehehe, but
correct and well designed sql involves subqueries and nontrivial
joins, which mysql fails at :D and sometimes you see where a mysql
user has used another database and doens't use, y'know, 95% of
sql's performance dealies because, well, mysql doesn't support them
:D and you start seeing postgres, oracle, sybase, ingress, etc
running far crappier than they should |
| 14:54.37 |
brlcad |
mm, dragonfly
bsd 2.2 is out |
| 14:54.46 |
``Erik |
thinks he's going to go with a blob in the .g files with a
list of regions and a hash to store the kd-tree |
| 14:55.19 |
``Erik |
then the
regions are walked and rehashed on load to see if the kd-tree needs
to be regenerated |
| 14:55.20 |
archivist |
subqueries
are a crutch some like to rely of to make the sql
readable |
| 14:56.06 |
``Erik |
that way,
straight bots are the core of data used |
| 14:57.07 |
brlcad |
binary
objects in the db with attr hashes on the objects to point to those
binobj's?, should work pretty well |
| 14:59.00 |
``Erik |
yeah, and
hashing the vertex data in the bot itself, so if it changes, I know
to regenerate/invalidate the kd-tree |
| 14:59.28 |
``Erik |
hm, *ponders
a hash function in the primitive table* |
| 15:05.54 |
brlcad |
gah, don't
sully the object space |
| 15:06.06 |
brlcad |
just use
attrs |
| 15:06.20 |
brlcad |
heck, attrs
on binobj's |
| 15:06.44 |
brlcad |
actually,
don't even need attrs, hm |
| 15:07.17 |
brlcad |
just make the
object name be an md5 hash, mark it invisible |
| 15:08.03 |
brlcad |
erh, yeah,
still need the attr on the bot, but still pretty simple |
| 15:08.33 |
brlcad |
no
infrastructure needed and it's not even abusing anything
:) |
| 15:11.40 |
``Erik |
hm, I was
thinking about packing the names and hashsums into the
blob |
| 15:12.38 |
``Erik |
I might do
some experiments to see if caching the kd-tree is necessary, if I
can get it as fast as, say, librt's prep, then I won't even have to
bother |
| 15:12.49 |
``Erik |
but reading
bots from a .g is an important step |
| 15:13.06 |
brlcad |
yeah |
| 15:13.38 |
``Erik |
oh, compile
is done, now I can start modifying stuff heh |
| 15:14.36 |
brlcad |
using just
one blob wouldn't pass the concatenate .g test, per-object blobs
would though |
| 15:15.01 |
``Erik |
hm, but the
tree is an acceleration structure for many regions |
| 15:15.08 |
brlcad |
but no
complaints from me -- caching should be worried about after
everything else is done, even if it is dog-slow |
| 15:15.10 |
``Erik |
and I don't
believe the trees can be merged trivially |
| 15:15.37 |
``Erik |
hehehe iirc,
the, uh, complicated test vehicle took days |
| 15:16.01 |
``Erik |
but that's a
piece of geometry that most cad systems simply cannot load
:) |
| 15:16.19 |
brlcad |
then it can
be the first optimization, but you still don't need it just
yet |
| 15:16.35 |
``Erik |
yeah, I think
my first case for that will be mossworld |
| 15:17.04 |
``Erik |
then mebbe
the m35 for fun, then probably the t62, then up to modern
crap |
| 15:17.28 |
brlcad |
also, iirc,
the one that took days was after using the long-pass kd-tree prep
-- aren't there two, a short that sucks and a long that sucks
slightly less? |
| 15:18.31 |
``Erik |
yeah |
| 15:18.42 |
``Erik |
the 'fast'
one is used for the cut view |
| 15:18.52 |
``Erik |
and both are
single threaded iirc |
| 15:19.23 |
``Erik |
moving them
to multithreaded simd beasties and going for convergance is
probably going to be on my list of shit to do |
| 15:19.41 |
``Erik |
of course, ed
is pushing to "just make it work and move on to other
stuff" |
| 15:19.43 |
brlcad |
people would
probably be just as happy to see a progress bar if it worked over
having cached hashes later ;) |
| 15:20.07 |
``Erik |
yeah, that's
one thing I have been doing to the private part, more status
information |
| 15:20.59 |
``Erik |
if you wanna
check it out, the database is on the bsd opteron, the svn is on the
bsd webserver as isst, make sure "HAX" is defined, that ignores all
user authentication |
| 15:21.19 |
``Erik |
been working
on osX.4 and fbsd, should work dandy either place |
| 15:21.20 |
``Erik |
:) |
| 15:21.29 |
brlcad |
I've tried to
check it out thrice :) |
| 15:21.41 |
``Erik |
really? co
isnt' working? |
| 15:21.52 |
``Erik |
or do you
mean "check it out" as in look at it? |
| 15:22.35 |
brlcad |
nah, I just
get side-tracked looking through the code instead of trying to run
it |
| 15:23.01 |
brlcad |
as in look at
it |
| 15:23.26 |
brlcad |
get the
viewer to actually show me some g'damn geometry in all spinny
clicky goodness |
| 15:23.45 |
``Erik |
it's doable
now |
| 15:24.05 |
``Erik |
I think I
made a lot of progress the last few months in merging the branches
and getting it all portable and shit |
| 15:24.11 |
brlcad |
that's why I
mentioned a tutorial/doc -- sans simple tutorial, it's gonna be
nearly useless to mortal users :) |
| 15:24.40 |
``Erik |
yeah |
| 15:24.54 |
brlcad |
so latest
isn't in cad repo? |
| 15:24.56 |
``Erik |
the current
hot plate item on that is to make the gui part able to run
solo |
| 15:25.00 |
``Erik |
it
is |
| 15:25.11 |
``Erik |
well |
| 15:25.12 |
``Erik |
it's
split |
| 15:25.27 |
brlcad |
then "svn is
on the bsd webserver as isst" would matter for what? |
| 15:25.28 |
``Erik |
and this is
pissing me off, and I got the TL to go yell at the BC for me,
but |
| 15:25.59 |
brlcad |
non-public
features? I don't care to test those out |
| 15:26.01 |
``Erik |
adrt_master
and adrt_slave are the drivers, those are on sourceforge. The gui
component is on our webserver, because it hasn't been ok'd for
public elease |
| 15:26.05 |
brlcad |
I want to see
moss-world spinning |
| 15:26.34 |
brlcad |
o.O |
| 15:26.56 |
``Erik |
we went to BC
and said "hey, this is crippling development, can we just shove
this out there to make things all good?" and she was not
understanding why we'd do that when it isn't even on peoples
desktops et |
| 15:26.58 |
``Erik |
yet |
| 15:27.13 |
``Erik |
I don't think
she understood that it was slowing development by holding that
piece private... and her brain is still in 247 |
| 15:27.49 |
brlcad |
so you asked
someone that makes decisions based on fear if you could do
something they don't understand and they said no |
| 15:27.52 |
brlcad |
I'm
shocked |
| 15:28.10 |
``Erik |
it's all
gtk+, and I didn't wan tot inflict that on the
svnroot/brlcad/brlcad/ repo, I was going to make a toplevel, like
rtcmp |
| 15:29.11 |
brlcad |
yeah, gtk+
would be bad |
| 15:29.27 |
``Erik |
I think gtk
would be good, myself... get rid of that effin' tk crap
:D |
| 15:29.35 |
brlcad |
the original
simple gui version was better than the agar and gtk
crap |
| 15:29.38 |
``Erik |
but *shrug*
might not be a popular sentimate |
| 15:30.04 |
``Erik |
I'm moving
code out of the gui piece and into the libraries as much as
possible, hopefully the gui will become a very trivial
veneer |
| 15:30.50 |
``Erik |
I want to
have all the networking ops as simple function calls with structs
instead of this manual packing/unpacking on both ends |
| 15:31.53 |
``Erik |
sendop;senddata1;senddata2 -> struct
thang { op, data1, data2 } ; sendit(thang) |
| 15:32.36 |
brlcad |
hm, that
doesn't sound like a good idea to me (screwing with the net before
the rest is done).. |
| 15:33.06 |
brlcad |
the net isn't
the problem, maybe not clean but not the problem |
| 15:33.09 |
``Erik |
heh, been
doing it, that's how I've been getting functionality
back |
| 15:33.12 |
``Erik |
no, the net
is the problem |
| 15:33.25 |
``Erik |
the protocols
were not synchronized with the version I got |
| 15:33.29 |
``Erik |
it just
didn't work |
| 15:33.56 |
brlcad |
i mean the
way it does what it does |
| 15:33.57 |
``Erik |
I've been
figuring out what was supposed to be passed and rebuilding them to
gain functionality back |
| 15:34.15 |
``Erik |
and it's a
huge hassle, because it's manual and piecewise, spread through
various areas |
| 15:34.16 |
brlcad |
not the
actual protocol and packing use |
| 15:34.16 |
``Erik |
:) |
| 15:34.33 |
``Erik |
the protocol
and packing was broken (still is, that's why split isn't
working) |
| 15:34.47 |
brlcad |
i get
that |
| 15:35.12 |
``Erik |
*shrug* my
next step is actually to avoid all the netowrking |
| 15:35.25 |
``Erik |
and have a
single binary that "just works" |
| 15:35.31 |
``Erik |
no
distributed aspect |
| 15:36.34 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33814
10/brlcad/trunk/src/tclscripts/mged/help.tcl: add in-editor help
for nmg_fix_normals. This also makes tab completion work for this
command. |
| 15:36.36 |
brlcad |
that sounds
like too many changes at once to me, make things (even more)
unstable as all hell, hard to fix bugs |
| 15:36.59 |
``Erik |
"start
adrt_master, then start adrt_slave and connect it to the master,
then start isst and connect to the master" is too many
steps |
| 15:37.03 |
brlcad |
i'd think
patching the existing net would be much faster in the long run even
if the goal is to eventually rip out the net |
| 15:37.09 |
``Erik |
*shrug*
sledgehammer remodeling, man |
| 15:37.43 |
brlcad |
by the time
you're done sledgehammaring and rebuilding, nobody will be left
waiting to move into the building |
| 15:37.48 |
``Erik |
heh |
| 15:38.00 |
``Erik |
well, I
figure it'll take like 3 days to make it work without the
networking |
| 15:38.09 |
brlcad |
riiight |
| 15:38.22 |
brlcad |
how much
money you got :) |
| 15:38.22 |
``Erik |
and so far,
it's taken more than 3 days to track down and fix each protocol
transaction |
| 15:38.38 |
``Erik |
uhm, not
enough, and they're taking more to fix my car :D |
| 15:38.46 |
``Erik |
3
uninterrupted dedicated days |
| 15:39.02 |
``Erik |
this
nmg_fix_normal thing kinda derailed me |
| 15:39.03 |
brlcad |
so two
weeks |
| 15:39.09 |
``Erik |
mebbe |
| 15:39.26 |
``Erik |
which is
probably how long it'd take to get split view 'just working' over
teh network |
| 15:39.44 |
brlcad |
screw split
view, seriously |
| 15:39.50 |
brlcad |
at least for
now |
| 15:39.58 |
``Erik |
that's the
part that ed is hammering me on |
| 15:40.10 |
brlcad |
the db is the
biggest problem |
| 15:40.17 |
``Erik |
hm |
| 15:40.19 |
``Erik |
*shrug* |
| 15:40.28 |
brlcad |
I can't use
it without a db, that's sorta a huge problem |
| 15:40.39 |
``Erik |
you have one
at the office, but I agree |
| 15:41.20 |
``Erik |
I was
starting to build it up so you could shoot geometry across the
network into the system, so'z the client was responsible for
loading geometry |
| 15:41.22 |
brlcad |
yes, but
users are in that same boat -- they don't have a db or at least
experience with using one with that tool |
| 15:41.36 |
``Erik |
hm |
| 15:41.49 |
brlcad |
they same
that works public makes it work internal -- run X, Y, and Z, and
you'll have spinning tank |
| 15:41.54 |
``Erik |
and since the
code isn't in the sf repo, I can't chekc it out here ;D
hehe |
| 15:43.16 |
``Erik |
putting it
all into a signle binary would make a lot of the ugly of dealing
with it go away |
| 15:43.36 |
``Erik |
debugging 3
networked programs (which don't clean up nicely) is a pain :)
*shrug* |
| 15:43.44 |
brlcad |
"start
adrt_master, then start adrt_slave and connect it to the master,
then start isst and connect to the master" would work great if that
really was all there was to it, but there's the g-adrt data
conversion, insertion into the db, config of tools to use db,
etc |
| 15:44.46 |
``Erik |
the g-adrt.c
program does the database insertion now |
| 15:45.01 |
brlcad |
heck,
"adrt_master && adrt_slave -m localhost && isst -c
localhost" ;) |
| 15:45.46 |
``Erik |
more like gdb
adrt_master, run -v, new terminal, gdb adrt_slave, run localhost,
gdb isst, run :D |
| 15:46.40 |
``Erik |
meh,
jawjacking is fun and all, but it's time to code :D |
| 15:46.42 |
brlcad |
er, actually,
"adrt_master moss.g moss && isst -c localhost" would be
trivial, make adrt_master exec an adrt_slave if none are
attached |
| 15:47.31 |
brlcad |
then one more
exec in isst to system() a master and that's a one-command step
;) |
| 15:48.33 |
``Erik |
system is
evil |
| 15:48.43 |
``Erik |
execlp() if
your'e going down that road, yo |
| 15:49.35 |
``Erik |
I d'no, my
thought is that if I bypass the networking code in the gui and just
call the functions instead, that'd make the chain far simpler and
easier/quicker to hack on |
| 15:57.14 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33815 10/brlcad/trunk/src/adrt/libtienet/
(Makefile.am load.c load.h load_g.c): break future .g loading into
a seperate file. |
| 16:05.55 |
``Erik |
heh, shoulda
taken my laptop to the dealership, they have one of those coffee
machines where you put a little cartridge in for a cup of coffee,
and they had some good stuff in their selection |
| 16:10.29 |
``Erik |
hm, being an
svn noob... how deadly of a sin is it to create a temporary file in
the repo, with intent to merge most of it into another (and throw
away the rest) down the road? |
| 16:11.14 |
``Erik |
oh, uh,
uhhhhhhh shit, oh shit |
| 16:11.25 |
``Erik |
I can't log
into the irix machine |
| 16:39.49 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33816
10/brlcad/trunk/src/adrt/libtienet/load_MySQL.c: move contents of
g-adrt.c into the lib |
| 16:39.51 |
``Erik |
solved |
| 17:09.52 |
``Erik |
wtf |
| 17:10.20 |
``Erik |
ok, this
libpng up will not be trivial. |
| 17:23.22 |
*** join/#brlcad samrose
(n=samrose@dhcp-x198w-222.mobile.uci.edu) |
| 17:58.32 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 18:10.48 |
brlcad |
it's not a
sin with svn |
| 18:11.28 |
brlcad |
it'll track
up in the repo as a file that had a short life and presuming you
remove it the same time that you merge it, the actions will be
associated with each other as one changeset |
| 18:13.19 |
brlcad |
svn isn't
smart enough to know that these N lines from file X were moved to
file Y unless you commit the changes together -- more just change
transactions on a file hierarchy |
| 18:14.50 |
``Erik |
meh,
whatever |
| 18:15.15 |
``Erik |
I'm just
gonna snarf pieces in and move 'em around later |
| 18:16.50 |
brlcad |
yeah, it's no
big deal either way because you can still pull up the change
history on a given file and see that it was temporary |
| 18:16.57 |
brlcad |
it won't
leave turds like cvs |
| 18:17.28 |
``Erik |
Attic/
ftw |
| 18:18.05 |
``Erik |
shakes fist at twingy for a bit |
| 18:18.51 |
``Erik |
seriously,
mang, this was a sudden drop, but, uh, wtf, this is a fail
handoff |
| 18:32.15 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 18:51.36 |
CIA-40 |
BRL-CAD:
03brlcad * r33817 10/brlcad/trunk/TODO: news2tracker.sh may have a
bug or it may have been user error, but someone needs to figure out
which and fix the problem. |
| 18:52.35 |
CIA-40 |
BRL-CAD:
03brlcad * r33818 10/brlcad/trunk/TODO: victor wants inside command
to work again with current edit objects. |
| 18:55.02 |
CIA-40 |
BRL-CAD:
03brlcad * r33819 10/brlcad/trunk/TODO: restore mged mirror command
third-arg-as-axis for backwards compatibility -- request from
victor. |
| 18:55.50 |
CIA-40 |
BRL-CAD:
03brlcad * r33820 10/brlcad/trunk/TODO: request to port g_lint to
windows |
| 18:57.33 |
CIA-40 |
BRL-CAD:
03brlcad * r33821 10/brlcad/trunk/TODO: requests from the modeling
team for a obl-g importer to match up with our
nexporter. |
| 18:58.42 |
CIA-40 |
BRL-CAD:
03brlcad * r33822 10/brlcad/trunk/BUGS: ls -A and/or e -A crash
reportedly when trying to look for objects with a given
attribute. |
| 19:02.59 |
CIA-40 |
BRL-CAD:
03brlcad * r33823 10/brlcad/trunk/include/plot3.h: quell shadow
warnings for y1 on mac os x |
| 19:04.38 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 19:08.06 |
CIA-40 |
BRL-CAD:
03brlcad * r33824 10/brlcad/trunk/src/util/xyz-pl.c: quell
warnings, style cleanup |
| 19:08.56 |
CIA-40 |
BRL-CAD:
03brlcad * r33825 10/brlcad/trunk/src/util/yuv-pix.c: need fb.h for
fb_common_file_size() |
| 19:10.57 |
CIA-40 |
BRL-CAD:
03brlcad * r33826 10/brlcad/trunk/src/util/yuv-pix.c:
cleanup |
| 19:29.28 |
CIA-40 |
BRL-CAD:
03brlcad * r33827 10/brlcad/trunk/ (include/wdb.h
src/libwdb/constraint.c src/util/pc_test.c): change
pc_mk_constraint() to mk_constraint() since it was moved into
libwdb, making it consistent with the others. update the pc_test
example to use it. |
| 19:30.54 |
CIA-40 |
BRL-CAD:
03brlcad * r33828 10/brlcad/trunk/include/raytrace.h: quell log()
shadow warning |
| 19:31.37 |
CIA-40 |
BRL-CAD:
03brlcad * r33829 10/brlcad/trunk/include/bu.h: quell log() shadow
warning |
| 19:34.21 |
CIA-40 |
BRL-CAD:
03brlcad * r33830 10/brlcad/trunk/src/libbu/bitv.c: quell
warning |
| 19:40.42 |
CIA-40 |
BRL-CAD:
03brlcad * r33831 10/brlcad/trunk/src/libbu/ (htond.c htonf.c):
quell warnings about not handling BU_PDP_ENDIAN. it's intentional,
should bomb out or fall through. |
| 19:42.55 |
CIA-40 |
BRL-CAD:
03brlcad * r33832 10/brlcad/trunk/src/burst/burst.c:
cleanup |
| 20:57.41 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F4FD.dip.t-dialin.net) |
| 21:02.36 |
*** join/#brlcad PrezKennedy
(i=Matthew@208.43.126.195) |
| 21:28.37 |
CIA-40 |
BRL-CAD:
03brlcad * r33833 10/brlcad/trunk/src/burst/ (grid.c plot.c prnt.c
vecmath.h): quell warnings and other cleanup |
| 21:30.46 |
CIA-40 |
BRL-CAD:
03brlcad * r33834
10/brlcad/trunk/src/other/tcl/generic/tclIntDecls.h: quell shadow
warnings for index and time |
| 21:38.36 |
CIA-40 |
BRL-CAD:
03brlcad * r33835 10/brlcad/trunk/src/canon/ (canon.h canonize.c
canonlib.c): quell various warnings |
| 21:38.54 |
CIA-40 |
BRL-CAD:
03brlcad * r33836 10/brlcad/trunk/src/canon/ (canonize.c
canonlib.c): ws |
| 21:39.20 |
CIA-40 |
BRL-CAD:
03brlcad * r33837 10/brlcad/trunk/include/ (fb.h fbio.h): quell
shadow warnings on width and height |
| 22:07.34 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:40.41 |
CIA-40 |
BRL-CAD:
03bob1961 * r33838 10/brlcad/trunk/src/libged/gqa.c: Some of the
writes to ged_result_str need to be semaphore
protected. |
| 22:48.01 |
CIA-40 |
BRL-CAD:
03starseeker * r33839
10/brlcad/trunk/src/proc-db/spring.c: |
| 22:48.01 |
CIA-40 |
BRL-CAD: OK,
better - can now delete points and get valid coils in .25 turn
increments. |
| 22:48.01 |
CIA-40 |
BRL-CAD: The
tradeoff (not surprisingly in retrospect) was between number of
control |
| 22:48.02 |
CIA-40 |
BRL-CAD:
points and increments in which the coil can be deleted while being
'coiled'. |
| 22:48.02 |
CIA-40 |
BRL-CAD: 1/4
of a turn is a decent compromise - it may be more important to have
fine |
| 22:48.04 |
CIA-40 |
BRL-CAD:
control when defining end sections. Also, number of turns is now
accurately |
| 22:48.06 |
CIA-40 |
BRL-CAD:
modeled. |
| 23:00.57 |
*** join/#brlcad samrose
(n=samrose@dhcp-x198w-222.mobile.uci.edu) |
| 23:08.40 |
CIA-40 |
BRL-CAD:
03starseeker * r33840 10/brlcad/trunk/src/proc-db/spring.c: Start
to break things out so multiple routines can add points to the same
point list before making the pipe - needed for section
support. |
| 23:16.56 |
CIA-40 |
BRL-CAD:
03brlcad * r33841 10/brlcad/trunk/src/fb/bw-fb.c:
cleanup |
| 23:20.49 |
starseeker |
brlcad: hmm
- to do a pipe that coils in or out, it looks like the best pipe
can do is to periodically adjust the bend radius further out and do
a kind of stepped taper |
| 23:21.18 |
starseeker |
a
continuously variable radius is out |
| 23:21.38 |
starseeker |
we'd need
sweep to really do it right |
| 23:24.32 |
starseeker |
would an
approximate taper be of any interest/use? |
| 23:25.16 |
louipc |
pipe
threads |
| 23:25.28 |
starseeker |
threading is
continuous though |
| 23:26.06 |
starseeker |
with this,
you would have one quarter with radius 300, one with radius 295,
one with 290, etc. etc. etc. |
| 23:26.25 |
louipc |
were you
asking if a tapered helix would be of use? |
| 23:26.48 |
starseeker |
no, I was
asking if the approximation that can be made with the pipe
primitive would be worth the effort to set it up |
| 23:27.09 |
louipc |
hmm, not
sure |
| 23:28.15 |
starseeker |
considering
that pipe ALSO can't do real thread shapes... |
| 23:28.36 |
starseeker |
it might be
ok to have an approximation |
| 23:28.59 |
starseeker |
but sweep
could do the real deal on both counts, so it might make more sense
to wait for sweep |
| 23:29.14 |
louipc |
yea |
| 23:29.40 |
starseeker |
coils can be
handled with pipe, but that's approaching the limits of the
primitive |
| 23:30.11 |
starseeker |
looks at the clock, winces, and decides to head back to the
ranch... |
| 23:31.03 |
louipc |
I can imagine
that it would become obsolete when another metaprimitive that uses
sweeps and can do real thread shapes comes about |
| 23:31.42 |
louipc |
well,
mostly.. |
| 23:36.13 |
``Erik |
heh |
| 23:36.26 |
``Erik |
pipe is
already a meta, it just creates torii and rcc's |
| 23:36.40 |
``Erik |
thus the
weird abitrary limitations |
| 23:39.01 |
*** join/#brlcad samrose
(n=samrose@dhcp-x198w-222.mobile.uci.edu) |
| 23:49.54 |
CIA-40 |
BRL-CAD:
03brlcad * r33842 10/brlcad/trunk/src/fb/ (13 files): quell
warnings |
| 23:52.59 |
CIA-40 |
BRL-CAD:
03brlcad * r33843 10/brlcad/trunk/src/other/tcl/generic/ (tclInt.h
tclIntDecls.h tclIntPlatDecls.h): shadow quellage |
| 00:14.12 |
brlcad |
gah,
drat |
| 00:14.28 |
brlcad |
starseeker:
tcl upgrade is still missing something, maybe in the init.tcl
script |
| 00:15.08 |
brlcad |
regress test
is failing on the fastgen test with a Tcl_Init error Can't find a
usable init.tcl in the following directories... |
| 00:15.31 |
brlcad |
hm, actually
all the mged tests fail with the same error |
| 00:15.36 |
brlcad |
(on mac
10.4) |
| 00:16.02 |
Twingy |
o.O |
| 00:18.00 |
*** join/#brlcad smurfette
(n=Pandora@c-69-242-189-29.hsd1.mo.comcast.net) |
| 00:18.11 |
brlcad |
starseeker:
the failure is on an uninstalled build -- the auto_path is missing
the source search directories which I believe is a mod to our
bundled sources |
| 00:38.51 |
starseeker |
ok, I'll see
if I can find it |
| 00:41.11 |
starseeker |
realizes he's probably going to have to do a diff on the old
tree vs. the default tarball |
| 00:41.14 |
starseeker |
argh |
| 00:50.24 |
brlcad |
svn log the
dir, there aren't that many changes |
| 00:50.59 |
starseeker |
is it an
atomic change or was it rolled in as part of an update? |
| 00:56.49 |
starseeker |
oh, the
unix/Makefile.in? |
| 01:08.04 |
CIA-40 |
BRL-CAD:
03starseeker * r33844
10/brlcad/trunk/src/other/tcl/unix/Makefile.in: Add back in unix
Makefile.in changes |
| 02:33.53 |
starseeker |
tries to figure out where auto_path is getting
/usr/lib |
| 02:49.48 |
starseeker |
oh, it's
sucking in my system TCLLIBPATH |
| 02:59.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 03:04.12 |
starseeker |
blinks |
| 03:04.24 |
starseeker |
the failing
line is: $this configure -menu $itk_component(menubar) |
| 03:04.41 |
starseeker |
$this
contains ::.archer0 |
| 04:44.49 |
starseeker |
ah, ding
nabbit - I forgot my list of National Archive stuff at
work |
| 04:45.16 |
starseeker |
will have to go in on monday |
| 05:04.18 |
starseeker |
ah,
nuts |
| 05:04.33 |
starseeker |
me remembers
regression testing currently needs an in-tree build and starts
over |
| 05:17.22 |
starseeker |
ah
HAH |
| 05:17.38 |
starseeker |
didn't look at the auto_path closely
enough |
| 05:18.56 |
starseeker |
http://pastebin.bzflag.bz/m5ffe7078 |
| 05:19.08 |
starseeker |
somehow,
/usr/lib/* stuff got sucked in |
| 05:19.41 |
starseeker |
anybody else
tried archer with a recent svn checkout built on a machine with
system tcl/tk/itcl/itk already installed? |
| 05:19.55 |
starseeker |
but using
local tcl/tk/itcl/itk for brlcad? |
| 05:35.35 |
starseeker |
eyes libtclcad's tclcad_auto_path |
| 08:48.36 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 10:00.44 |
alex_joni |
how would one
go on with converting a mesh to a solid? |
| 11:48.26 |
d-lo |
alex_joni:
You would have to enclose the mesh or, if its easier, extrude it
out into a solid. |
| 11:48.48 |
alex_joni |
d-lo: I think
the mesh is closed |
| 11:49.44 |
d-lo |
alex_joni:
Well, if its already enclosed, there is a property you can set to
make it a solid instead of just a shell. |
| 11:49.47 |
alex_joni |
(it's a 3D
mesh in STL or any other format) |
| 11:50.17 |
d-lo |
Get the mesh
into solid edit mode. |
| 11:50.59 |
alex_joni |
d-lo:
downloading brl-cad atm :) |
| 11:51.18 |
alex_joni |
(7.12.6
win) |
| 11:52.19 |
d-lo |
Good deal!
:D |
| 12:01.37 |
d-lo |
Meshes are
called BoTs in Brlcad btw. |
| 12:10.43 |
alex_joni |
d-lo: got a
link to a crashcourse in brlcad? |
| 12:10.52 |
alex_joni |
or.. can I do
the stuff I need in Archer? |
| 12:11.49 |
d-lo |
Archer and
BRLCAD are very similar. BRLCAD is much more functional whereas
Archer is less-so, but much prettier on the User Inferface side of
the house. |
| 12:12.02 |
d-lo |
Both,
however, should do what you want to do with BoTs....
maybe |
| 12:12.03 |
alex_joni |
I did start
mged in the past |
| 12:12.20 |
alex_joni |
how would I
go on with importing a STL ? |
| 12:12.21 |
d-lo |
http://brlcad.org/wiki/Documentation |
| 12:13.12 |
d-lo |
page 21 of
this pdf: |
| 12:13.16 |
d-lo |
http://brlcad.org/w/images/6/66/Converting_Geometry.pdf |
| 12:13.26 |
d-lo |
shows the
stl-g conversion steps. |
| 12:13.31 |
alex_joni |
coo |
| 12:14.00 |
d-lo |
It is common
practice to try several conversion paths if the initial try doesn't
work. |
| 12:14.38 |
d-lo |
aka if
stl->g path doesn't work, load the stl file into pro/E or
Unigraphics and export a DXF... then try the dxf ->
g |
| 12:15.12 |
d-lo |
I have used
Blender on occasion to convert files to .dxf and use the dxf->g
converter.... |
| 12:15.30 |
d-lo |
how large is
the stl file you are talking about? |
| 12:15.54 |
alex_joni |
hang on..
just figured out I have only obj's |
| 12:15.58 |
alex_joni |
converting
them to STL now |
| 12:16.00 |
alex_joni |
<
2MB |
| 12:16.32 |
alex_joni |
100k for the
STL |
| 12:16.45 |
d-lo |
ok, no
ginormous files then. |
| 12:16.59 |
alex_joni |
(not at this
point ;) |
| 12:17.04 |
alex_joni |
I have some
40M ones |
| 12:17.07 |
alex_joni |
but not for
now |
| 12:17.18 |
alex_joni |
STL needs to
be ASCII? |
| 12:17.34 |
alex_joni |
n/m -b does
the trick |
| 12:17.41 |
d-lo |
there were
some recent reports of dxf files acting rather strange once the
file size approaches 1.5 gigs... |
| 12:17.45 |
alex_joni |
Using solid
name: s.stl |
| 12:17.45 |
alex_joni |
2100
facets |
| 12:17.46 |
alex_joni |
Making region
(r.stl) |
| 12:17.58 |
d-lo |
sounds like
its working :) |
| 12:18.01 |
alex_joni |
d-lo: ROFL
:) |
| 12:18.05 |
alex_joni |
1.5gig
:) |
| 12:18.39 |
alex_joni |
ok, the .g
opened in archer |
| 12:18.52 |
alex_joni |
I have a tree
on the left (all->r.stl->s.stl) |
| 12:19.19 |
d-lo |
sounds like
it worked |
| 12:19.53 |
alex_joni |
stupid
question.. is there a way to see it? |
| 12:20.03 |
alex_joni |
or should I
raytrace it? |
| 12:20.32 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 12:20.42 |
mafm |
hi |
| 12:21.40 |
d-lo |
raytracing
should work |
| 12:21.43 |
d-lo |
Hi
mafm! |
| 12:33.56 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:38.34 |
alex_joni |
14:15 <
d-lo> there were some recent reports of dxf files acting rather
strange |
| 12:38.34 |
alex_joni |
<PROTECTED> |
| 12:38.43 |
alex_joni |
oops.. wrong
paste :/ |
| 12:42.23 |
alex_joni |
d-lo: can you
check if this is ok? http://eneas.juve.ro/~juve/brlcad/s2.g |
| 12:44.45 |
d-lo |
Looks good so
far... what did you want me to check> |
| 12:44.46 |
d-lo |
? |
| 12:46.00 |
alex_joni |
if there is
anything there |
| 12:46.09 |
alex_joni |
I can't seem
to get it to display or raytrace anything |
| 12:46.24 |
alex_joni |
ahhh... found
it ;) |
| 12:46.33 |
alex_joni |
need to
right-click on s.stl and enable the view |
| 12:46.45 |
d-lo |
Okay, well i
found a problem. |
| 12:46.54 |
d-lo |
the 'bolt
holes' on the base are an issue. |
| 12:47.24 |
d-lo |
they are
supposed to be a subtraction from the main bot, but instead, they
are *part* of the main bot.... thus they are confusing the
raytracer. |
| 12:47.42 |
alex_joni |
d-lo: I don't
really care about the holes ;) |
| 12:47.53 |
alex_joni |
I need to
weld the subparts, so the holes are not interesting .. |
| 12:47.54 |
d-lo |
They should
be removed or replaced. |
| 12:48.02 |
alex_joni |
I
see |
| 12:48.09 |
d-lo |
well, they
holes are making the geometry invalid. |
| 12:48.40 |
d-lo |
just do a
raytrace looking down into the hole from the top and then up from
the bottom.... its a magic 'hole' :) |
| 12:49.58 |
d-lo |
Since they
were supposed to be a subtraction, the holes are 'mini-bots' in
themselves, so they should be seperate solids. Since they aren't,
there are two solids existing in one and have overlapping
faces. |
| 12:50.35 |
d-lo |
the raytracer
determins solidity by the amount of faces hit along the path of a
ray (1st = in, 2nd = out, 3rd = in, etc) |
| 12:51.03 |
d-lo |
so when there
are two faces overlapping, you get the first two hits
immediately |
| 12:51.28 |
d-lo |
and trick the
raytracer into thinking its exited the solid, when, in reality, its
inside it. |
| 12:51.50 |
d-lo |
Now, this may
not matter to your needs, but it will make the raytraced pictures
inaccurate. |
| 12:52.27 |
alex_joni |
I saw
that |
| 12:53.25 |
d-lo |
Looks like
the same phenominon is happening on the top with those 4 (or 8)
cyls |
| 12:54.23 |
d-lo |
I have some
homebrewed tools that can eliminate the boltholes and those cyls
very quickly if you want me to. Just need an email addy to send
the file back when I am done. |
| 12:54.49 |
alex_joni |
d-lo: I have
about 10 of these files, but I don't think the bother is worth it
:) |
| 12:55.04 |
alex_joni |
if I can
convert it to a solid (even if it looks funny around those holes),
I'm happy |
| 12:55.34 |
alex_joni |
now.. you
said there is a flag I can change so I can convert it from g to
some other solid format? |
| 12:55.45 |
d-lo |
alrighty.
Just noticed that the smaething is happening in the middle with
those tab thingys about halfway up |
| 12:56.04 |
d-lo |
Just curious,
why do you need it 'solid' ? |
| 12:56.07 |
alex_joni |
I notice in
attributes it says" |
| 12:56.18 |
alex_joni |
"This is a
solid object (not just a surface)" |
| 12:56.59 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.141) |
| 12:59.27 |
d-lo |
I believe
thats the setting I was talking about.. my desktop is chewing on
optimizing your BoT... when its done I will look at that
attr. |
| 13:00.31 |
d-lo |
where did you
see that message>? |
| 13:02.44 |
alex_joni |
in archer
under advanced |
| 13:02.57 |
alex_joni |
I switched to
mode Advanced |
| 13:03.03 |
alex_joni |
and I have an
attributes tab on the right |
| 13:03.09 |
starseeker |
fyi, Archer
is experimental |
| 13:03.20 |
starseeker |
mged is still
the "workhorse" at the moment |
| 13:03.42 |
alex_joni |
starseeker: I
know that.. a bit too much to chew on atm though |
| 13:03.51 |
starseeker |
ah
:-) |
| 13:04.28 |
d-lo |
I pulled out
those geometric flaws and reoptimized the bot. (got the vertex
count down by over 65% ;) ) |
| 13:04.47 |
d-lo |
but I am
seeing some issues with those triangled shape thingies in the
middle. |
| 13:04.51 |
d-lo |
What is this
btw? |
| 13:07.02 |
alex_joni |
d-lo: it's a
support thingie from a factory |
| 13:07.19 |
alex_joni |
side wall
support |
| 13:07.52 |
alex_joni |
you asked
earlier why I need a solid, I need to import it (an ACIS sat file)
into a robot programming and simulation package.. |
| 13:08.44 |
d-lo |
Cool... well,
those bolt holes are going to mess with your 'Solidity' |
| 13:09.03 |
d-lo |
if you need
100% prime cut Geometry, you will need to get rid of those
flaws. |
| 13:09.27 |
alex_joni |
I see that
g-iges does something, and converts 1 solid to NMG's before
exporting to IGES (according to the log) |
| 13:10.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 13:11.04 |
d-lo |
that sounds
about right. |
| 13:11.47 |
alex_joni |
but trying to
import it in another app it fails on the iges format |
| 13:15.19 |
alex_joni |
I don't
suppose there's an g-acis hidden somewhere? |
| 13:15.21 |
alex_joni |
or g-step
? |
| 13:18.42 |
alex_joni |
d-lo:
http://eneas.juve.ro/~juve/brlcad/s32.g
(this one should be without the holes) |
| 13:23.23 |
d-lo |
alex_joni:
No, no g-acis nor g-step. Do you have another application that
could be used as middleman for the conversion? |
| 13:25.11 |
alex_joni |
yeah, that's
what I'm trying with IGES |
| 13:25.37 |
alex_joni |
(using Alibre
which I have here, but i get "Object reference not set to an
instance of an object." - whatever that might mean |
| 13:26.16 |
d-lo |
Okay, took a
look at s32.g and it looks 100% valid. |
| 13:26.46 |
d-lo |
since its
already a BoT, you might try g-dxf, then dxf->step or
dxf->acis |
| 13:28.32 |
alex_joni |
is dxf
3D? |
| 13:28.45 |
alex_joni |
(the dxf that
g-dxf writes I mean) |
| 13:29.07 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DAEE.dip.t-dialin.net) |
| 13:29.52 |
d-lo |
Yes, I
believe it is. |
| 13:30.00 |
alex_joni |
it seems
so |
| 13:35.40 |
d-lo |
Good deal.
Everything working then? |
| 13:36.38 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:39.53 |
alex_joni |
d-lo: nope
;) |
| 13:40.32 |
d-lo |
whats
brokeded? |
| 13:40.32 |
alex_joni |
d-lo: ACAD
doesn't want to open it .. |
| 13:40.42 |
d-lo |
in what
format |
| 13:40.43 |
d-lo |
? |
| 13:40.57 |
alex_joni |
dxf |
| 13:41.14 |
d-lo |
what other
formats does ACAD open? |
| 13:41.31 |
alex_joni |
it says
"improper table entry name on line 20" |
| 13:41.53 |
d-lo |
whats line 20
look like then? Any illegal characters? |
| 13:42.17 |
alex_joni |
dxf, dwg,
acis, 3ds |
| 13:42.25 |
alex_joni |
20:
r.stl/s.stl |
| 13:42.41 |
alex_joni |
I tried
changing that to a number, then it moves on 4 lines, and complains
about a missing table something |
| 13:42.42 |
CIA-40 |
BRL-CAD:
03starseeker * r33845
10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Clearing the Tcl
auto_path before tclcad_auto_path does its work gets archer up and
running with local tcl/tk. Need to check its impact on builds using
system tcl/tk |
| 13:43.43 |
d-lo |
you could try
dxf->3ds in Blender :/ |
| 13:45.51 |
alex_joni |
heh, now that
would lead a nice conversion path :D |
| 13:46.13 |
alex_joni |
dxf (mesh)
-> obj -> stl -> g -> dxf -> 3ds -> dxf ->
acis |
| 13:47.00 |
alex_joni |
d-lo: thanks
for the effort though :) .. I'll probably go with a non-free
conversion that creates a solid in ACAD from the mesh |
| 13:47.12 |
starseeker |
arrrgh, now
archer crashes when trying to open a file |
| 13:47.15 |
starseeker |
http://pastebin.bzflag.bz/m28988fe4 |
| 13:49.57 |
d-lo |
alex_joni:
You can't take the original dxf straight to g using
dxf-g? |
| 13:50.57 |
alex_joni |
d-lo: nope,
it seems it does only see 2-3 polylines |
| 13:51.14 |
d-lo |
Hrm, where is
this dxf coming from? |
| 13:51.29 |
alex_joni |
some design
studio :) |
| 13:51.49 |
alex_joni |
it would have
been great if they used a SOLID in Acad when they drew
it |
| 13:52.03 |
alex_joni |
then it would
just have worked to export it from Acad, and I would be done with
it |
| 13:53.05 |
alex_joni |
I did notice
this when using g-dxf though: |
| 13:53.07 |
alex_joni |
db_walk_subtree() FAIL on
'/r.stl/s.stl' |
| 13:53.07 |
alex_joni |
nmg_fix_normals: nmg_classify_s_vs_s()
failed for shells x103ac48 and x1043a40 |
| 13:53.08 |
alex_joni |
<PROTECTED> |
| 13:53.56 |
d-lo |
strangeness. |
| 13:54.29 |
alex_joni |
d-lo: given
the conversion path above I'm not _that_ surprised ;) |
| 13:54.54 |
d-lo |
this is yet
another need for a obj-g converter :/ |
| 13:57.52 |
alex_joni |
d-lo: after
messing with the dxf I was able to load it in acad |
| 13:58.08 |
alex_joni |
it's now full
of 3DFACES not POLYMESH (like it was initially) |
| 13:58.12 |
alex_joni |
but it's
still no solid |
| 13:59.27 |
alex_joni |
(messing
meaning hacking the dxf header) |
| 14:01.24 |
d-lo |
Hrm, well,
you might wanna take a look at the DXF standard... maybe there is
something you can edit in the dxf file that will set the objects to
solids... then you can forego the whole bloody conversion path all
together! |
| 14:04.53 |
archivist |
reminds me of
the days of writing dxf fixing scripts |
| 14:24.05 |
starseeker |
sigh, and
RamDebugger still won't run in bwish - after all that it's a
different issue |
| 14:24.17 |
starseeker |
closes down the xterms and heads in to
work... |
| 14:31.12 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 14:59.26 |
yukonbob |
starseeker:
what are you trying to fix w/ RamDebugger? |
| 15:40.35 |
brlcad |
yay, finally
back on-line |
| 15:40.52 |
brlcad |
arrived home to dead internet service last night, now
restored after a two-hour phone call |
| 15:43.11 |
brlcad |
terminology
snafu -- "Archer and BRLCAD are very similar" .. Archer is a
component of BRL-CAD, I believe he meant MGED instead of "BRLCAD"
.. MGED and Archer are very similar |
| 15:43.18 |
brlcad |
( alex_joni
) |
| 15:45.19 |
brlcad |
those
external tools that had trouble with dxf weren't ours -- and that
1.5GB limit is almost certainly a 32-bit app trying to read in the
entire file in and running out of memory |
| 15:45.31 |
brlcad |
(at least,
running out of 32-bit addressable memory) |
| 15:52.08 |
brlcad |
alex_joni:
also, fwiw -- depending on your version of AutoCAD (and I assume
you mean autocad and not a tool from GD specifically called 'ACAD')
-- they're even inconsistent on their interpretation of their DXF
spec |
| 15:53.23 |
brlcad |
dxf spec
itemizes illegal characters, none of which we use iirc, but then
there are some versions of autocad that won't read various other
characters (e.g., the slashes) |
| 15:54.29 |
brlcad |
and there was
a long time where there was ambiguity on whether all faces were
4-points or whether 3-point faces (i.e., triangles) were valid ..
so if you had a triangle and only 4-point 3dfaces were allowed, you
had to repeat the last point per the spec |
| 16:08.59 |
starseeker |
yukonbob: In
theory it would be helpful debugging pure tcl applications like
Archer and rtwizard |
| 16:09.06 |
PrezKennedy |
brlcad,
they're going to get me apple certified |
| 16:09.09 |
PrezKennedy |
how ironic
eh? |
| 16:20.34 |
CIA-40 |
BRL-CAD:
03d_rossberg * r33846 10/rt^3/trunk/ (11 files in 2
dirs): |
| 16:20.35 |
CIA-40 |
BRL-CAD: -
virtual constructor and assignment operator for the
Object |
| 16:20.35 |
CIA-40 |
BRL-CAD: -
some more functionality for the Combination |
| 16:20.35 |
CIA-40 |
BRL-CAD: -
clean-ups |
| 16:20.54 |
brlcad |
PrezKennedy:
ironic? no .. inspiring ;) |
| 16:33.17 |
PrezKennedy |
it only take
40 screws to pop that hard drive outta your laptop...
;) |
| 17:19.39 |
*** join/#brlcad samrose
(n=samrose@dhcp-x198w-162.mobile.uci.edu) |
| 17:38.23 |
alex_joni |
brlcad: ok,
thanks for the insight |
| 17:38.44 |
alex_joni |
(although I'm
not a long time user of BRLCAD, I do know what mged and Archer are
;) |
| 17:39.14 |
alex_joni |
and for the
dxf part, I think you're right, this was using AutoCAD 2009, but I
wouldn't be too surprised if things were different with an older
version |
| 18:13.58 |
starseeker |
grrrrr |
| 18:14.08 |
starseeker |
come on pipe,
figure it out |
| 18:15.16 |
starseeker |
apparently
pipe won't automatically "smooth" the difference between slopes
where two coiling patterns join |
| 18:16.20 |
starseeker |
starts scribbling math to calculate the tgc required to at
least make the transition solid, if not truly
"smooth" |
| 18:25.04 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1212 10/wiki/Main_Page: 3rd party utils |
| 18:25.58 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1213 10/wiki/Third_Party_Utilities: hex |
| 18:28.31 |
brlcad |
PrezKennedy:
I don't have that laptop, only macbook pro's ftw |
| 18:31.34 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1214 10/wiki/Hex: New page: Supported items: * Hex head metric
bolts: M1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 18, 20, 22, 24, 27,
30, 33, 36, 39, 42, 45, 48, 52, 56, 60, 64 * Basic metric threaded
nuts, * ... |
| 18:32.20 |
brlcad |
~nslookup
77.58.247.103 |
| 18:32.41 |
brlcad |
smells sushi edits ;) |
| 18:34.10 |
d-lo |
good thing
you like sushi eh? |
| 18:35.59 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1215 10/wiki/Hex: |
| 18:42.11 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1216 10/wiki/Hex: |
| 18:53.21 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1217 10/wiki/Hex: /* Installation */ |
| 18:55.40 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1218 10/wiki/Hex: /* Installation */ |
| 18:57.35 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1219 10/wiki/Main_Page: /* Projects */ |
| 18:58.19 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1220 10/wiki/Main_Page: /* Projects */ |
| 18:59.13 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-247-103.dclient.hispeed.ch) |
| 18:59.25 |
_sushi_ |
I made a wiki
page about the threade bolts tool http://brlcad.org/wiki/Hex |
| 18:59.34 |
d-lo |
we saw
:) |
| 18:59.39 |
d-lo |
looks
neat! |
| 18:59.49 |
CIA-40 |
BRL-CAD:
03johnranderson * r33847 10/jbrlcad/trunk/ (18 files in 6 dirs):
Fixed a few bugs |
| 19:00.10 |
starseeker |
ah,
OK. |
| 19:00.39 |
starseeker |
shoot - doing
quarter turn tricks over constrains the coil when individual
sections need to be "blended" |
| 19:00.54 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1221 10/wiki/Hex: /* Usage */ |
| 19:00.59 |
starseeker |
OK, guess I
caln live with that |
| 19:03.22 |
CIA-40 |
BRL-CAD:
03starseeker * r33848
10/brlcad/trunk/src/proc-db/spring.c: |
| 19:03.22 |
CIA-40 |
BRL-CAD:
Working example of a coil with a squared end. Will have to give up
quarter turn |
| 19:03.22 |
CIA-40 |
BRL-CAD:
increment control in editing in order to allow pipe to smoothly
join sections - |
| 19:03.22 |
CIA-40 |
BRL-CAD:
that's an acceptable tradeoff. There are other tricks that can be
done |
| 19:03.23 |
CIA-40 |
BRL-CAD:
(including manual pipe editing, for that matter) if something
really weird is |
| 19:03.25 |
CIA-40 |
BRL-CAD:
needed. |
| 19:04.40 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1222 10/wiki/Hex: |
| 19:05.30 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1223 10/wiki/Hex: |
| 19:06.12 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1224 10/wiki/Hex: |
| 19:07.11 |
CIA-40 |
BRL-CAD:
0377.58.247.103 07http://brlcad.org
* r1225 10/wiki/Hex: |
| 19:10.23 |
CIA-40 |
BRL-CAD:
03johnranderson * r33849
10/jbrlcad/trunk/src/org/brlcad/samples/BrlcadJava.java: Addef a
usage message |
| 19:15.02 |
CIA-40 |
BRL-CAD:
03bob1961 * r33850 10/brlcad/trunk/src/ (libged/gqa.c mged/cmd.c
mged/cmd.h mged/setup.c): |
| 19:15.02 |
CIA-40 |
BRL-CAD:
Added a -Ap option to libged's ged_gqa function for creating
psuedo-solid |
| 19:15.02 |
CIA-40 |
BRL-CAD:
wireframe of overlaps. Added a cmd_ged_gqa wrapper to MGED for
using the |
| 19:15.02 |
CIA-40 |
BRL-CAD:
currently displayed objects if no objects were specified on the
command line. |
| 19:22.39 |
_sushi_ |
I am getting
this error when compiling 7.14.0 /bin/sh:
/home/clock/brlcad-7.14.0/src/other/tcl/unix/tclsh: No such file or
director |
| 19:22.42 |
_sushi_ |
y |
| 19:24.23 |
brlcad |
hrm, need
more of the build log |
| 19:25.10 |
_sushi_ |
seems I am
getting this problem
http://www.mail-archive.com/brlcad-tracker@lists.sourceforge.net/msg00113.html |
| 19:25.17 |
_sushi_ |
I am trying
autogen.sh |
| 19:25.29 |
_sushi_ |
autogen.sh
passed |
| 19:25.48 |
brlcad |
ah,
yeah |
| 19:25.52 |
brlcad |
that's
probably the problem |
| 19:26.33 |
brlcad |
_sushi_: can
you post a full build log somewhere? |
| 19:26.52 |
_sushi_ |
now the
./configure is printing endless cycle of configure: Would you like
to continue with /usr as the install prefix? [yes/no] |
| 19:26.54 |
brlcad |
don't have
the problem here to reproduce it so a fix can be made |
| 19:26.55 |
_sushi_ |
configure:
Please answer 'yes' or 'no' |
| 19:26.56 |
_sushi_ |
and ignores
my keyboard input |
| 19:26.58 |
_sushi_ |
configure: |
| 19:27.03 |
_sushi_ |
Even if I
paste "yes\n" in one mouse-click |
| 19:27.12 |
_sushi_ |
Before it
worked without the autogen.sh |
| 19:27.33 |
brlcad |
you're
installing into /usr ? .. yikes |
| 19:27.45 |
_sushi_ |
Yes the
previous brl-cad was installed into usr |
| 19:27.59 |
brlcad |
k, still
surprising :) |
| 19:28.13 |
_sushi_ |
I am actually
reinstalling because of rendering bug in 7.10.4 |
| 19:28.56 |
_sushi_ |
7.10.4
renders my holder incorrectly http://ronja.twibright.com/3d/plazmatron_0.png |
| 19:29.20 |
_sushi_ |
The yellow
thing is interrupted in the middle you can see the wand with the
ball at the end ends in the air it shouldn't |
| 19:29.35 |
_sushi_ |
And the blue
part is having a "horn" sticking out which apparently cannot have
any mechanical function |
| 19:29.54 |
_sushi_ |
Well is there
a way I can get through the endless loop of questions? |
| 19:30.18 |
brlcad |
if it stays
stuck, you can set BRLCAD_ROOT_OVERRIDE and it'll skip the yes/no
question, though I'm curious how it got stuck in a loop |
| 19:30.30 |
brlcad |
post your
configure file somewhere |
| 19:30.47 |
brlcad |
it's a simple
loop that just does a read until it gets a yes or a no |
| 19:31.24 |
_sushi_ |
Good I hacked
the yes test in configure |
| 19:31.58 |
_sushi_ |
replaced read
with assignment =yes :) |
| 19:32.25 |
_sushi_ |
I am still
getting the tclsh error |
| 19:32.43 |
brlcad |
you would
have to rebuild cleanly |
| 19:33.20 |
_sushi_ |
http://twibright.com/typescript |
| 19:33.27 |
_sushi_ |
what should I
do to rebuild cleanly |
| 19:38.19 |
_sushi_ |
The configure
AFTER runjning autogen.sh is at http://twibright.com/configure |
| 19:39.54 |
_sushi_ |
Now it
compiles suspiciously long. The problem may be gone. |
| 19:40.21 |
_sushi_ |
Actually
isn't. Still pops up: /bin/sh:
/home/clock/brlcad-7.14.0/src/other/tcl/unix/tclsh: No such file or
directory |
| 19:41.32 |
_sushi_ |
trying
--enable-all... |
| 19:41.36 |
starseeker |
brlcad:
here's the bomb log from the pipe raytracing crash: http://pastebin.bzflag.bz/m35029930 |
| 19:44.37 |
_sushi_ |
When I do rm
config.cache* then ./configure --prefix=/usr --enable-all then it
crashes on a different error: |
| 19:44.50 |
_sushi_ |
./src/htmltcl.c: In function
'configureCmd': |
| 19:44.50 |
_sushi_ |
./src/htmltcl.c:1351: error:
'HTML_DEFAULT_CSS' undeclared (first use in this
function) |
| 19:49.47 |
brlcad |
http://twibright.com/configure
is a 404 |
| 19:50.12 |
_sushi_ |
ah connection
refused |
| 19:50.17 |
brlcad |
ah, server is
down |
| 19:50.24 |
_sushi_ |
it's a
friend's apache tomcat |
| 19:50.40 |
_sushi_ |
when it
crashes you usually wait for a short time and it's up
again |
| 19:51.24 |
brlcad |
that
backtrace is useless, it's for the wrong thread |
| 19:51.37 |
brlcad |
unfortunately |
| 19:51.45 |
_sushi_ |
brlcad: you
are not talking about my log now are you? |
| 19:51.58 |
brlcad |
yep |
| 19:52.05 |
_sushi_ |
the
typescript is useless? |
| 19:52.34 |
brlcad |
well, yeah,
it's fairly useless too other than it confirmed that it's the same
problem as the one you found on the mailing list |
| 19:52.50 |
brlcad |
but no, I
mean http://pastebin.bzflag.bz/m35029930
isn't useful unfortunately |
| 19:53.22 |
brlcad |
the automatic
bomb report only shows the main thread -- if it's ray-tracing,
there are potentially lots of threads |
| 19:53.31 |
brlcad |
could try -P1
to force single cpu |
| 19:53.59 |
brlcad |
or attaching
with a debugger while it's running to get a proper trace for any
one of the threads |
| 19:55.49 |
_sushi_ |
brlcad:
http://twibright.com/configure
is up again |
| 20:00.28 |
brlcad |
don't see
anything wrong with your configure script unless you have a bused
'read' command |
| 20:00.39 |
brlcad |
run this
one-liner: |
| 20:00.40 |
brlcad |
echo "type
yes or no" ; while true ; do read a ; case "x$a" in
x*[yY][eE][sS]*) a=yes ; break; ;; x*[nN][oO]*) a=no; break; ;; x*)
echo "answer yes or no" ; ;; esac ; done ; echo "you answered
$a" |
| 20:01.50 |
brlcad |
that's the
exact same logic it's using |
| 20:03.55 |
_sushi_ |
makes this -
no loop: |
| 20:03.55 |
_sushi_ |
type yes or
no |
| 20:03.55 |
_sushi_ |
yes |
| 20:03.55 |
_sushi_ |
you answered
yes |
| 20:04.30 |
_sushi_ |
This one
fortunately isn't critical while I can hack it easily |
| 20:04.48 |
_sushi_ |
But how to
get through the one with tcl or the one with CSS I have no
idea |
| 20:06.14 |
_sushi_ |
brlcad: can I
produce some better typescript that tells you more about the
cause/ |
| 20:10.50 |
_sushi_ |
brlcad:
what's interesting if I don't run autogen.sh (using the configure
from the tarball), it doesn't make the infinite yes
loop. |
| 20:11.17 |
_sushi_ |
if my read
were screwed up, then it would happen even in this
situation |
| 20:25.48 |
_sushi_ |
Even
symlinking the system-wide tcl into the required directory doesn't
help - compiles for a long time then makes:
//home/clock/brlcad-7.14.0/src/other/incrTcl/.libs/libitcl.so:
undefined reference to `TclVarHashCreateVar' |
| 20:26.38 |
CIA-40 |
BRL-CAD:
03starseeker * r33851 10/brlcad/trunk/src/proc-db/spring.c:
Successfully squared off both ends of a coil. |
| 20:27.19 |
starseeker |
brlcad:
regression tests succeed for mged on my Mac with latest
checkout |
| 20:30.18 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 20:32.49 |
starseeker |
brlcad:
let's try this: http://pastebin.bzflag.bz/m1967e293 |
| 20:33.01 |
_sushi_ |
brlcad: any
idea wha tI could temporarily do to get around the problem and
compile a BRL-CAD that doesn't produce this raytracing
error? |
| 20:33.14 |
starseeker |
winces at the sight of boolweave |
| 20:37.57 |
CIA-40 |
BRL-CAD:
03starseeker * r33852 10/brlcad/trunk/src/proc-db/ (Makefile.am
coil.c spring.c): Let's get this renamed - it's coil, not spring -
spring is too general in terms of possible geometries. |
| 20:39.21 |
_sushi_ |
I tried
./configure without --prefix, also crashes on tcl |
| 21:12.18 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DAEE.dip.t-dialin.net) |
| 21:39.40 |
brlcad |
cool,
http://www.kenradio.com/content/view/1756/30/ |
| 21:39.46 |
brlcad |
thanks
ken |
| 21:41.07 |
brlcad |
_sushi_: I
know it's not critical, it's just really odd -- if you still have
the busted configure script, add a print statement on the x*) case
to print the $bc_answer |
| 21:41.27 |
brlcad |
otherwise
we'll just ignore it |
| 21:42.10 |
brlcad |
by your
'read' being messed up, the difference is in which interpreter is
getting used, whether read is external or built-in (shell) command,
etc |
| 21:43.07 |
brlcad |
starseeker:
oh, nice -- badmagic's in boolweave are pretty rare |
| 21:43.53 |
brlcad |
_sushi_: give
me a shell somewhere and I could try to produce a build
interactively |
| 21:44.30 |
brlcad |
otherwise,
you could try using the latest sources -- tcl version is different
there |
| 21:46.12 |
brlcad |
starseeker:
wince all you like, but that is actually one of the most valuable
bits of logic in librt |
| 21:46.40 |
brlcad |
highly
optimized and tuned to exact behavior, tolerance corrections,
interference detection, and performance |
| 21:48.01 |
brlcad |
I've
attempted to rewrite it to be "more clean" about a half-dozen times
and every single time I've either killed performance or changed
behavior |
| 21:48.20 |
brlcad |
it'd be
interesting to come up with a test harness that exercises every
line of code in there |
| 21:49.37 |
louipc |
There's some
spam here: http://brlcad.org/d/node/31#comments |
| 21:49.59 |
brlcad |
starseeker:
once it's more complete, coil can move to src/shapes |
| 21:50.10 |
brlcad |
(like at the
point that it gets documentation) |
| 21:50.30 |
brlcad |
louipc: huh,
thanks .. that's odd |
| 21:50.38 |
brlcad |
no comments
are supposed to post without moderation |
| 21:53.31 |
louipc |
hmm, probably
better to lose the comments altogether eh? |
| 21:57.22 |
brlcad |
louipc:
possibly, though there are a few that are useful |
| 22:00.56 |
brlcad |
there's so
few that actually got through, makes me think that they're actually
real people behind them |
| 22:01.05 |
brlcad |
4 in
total |
| 22:06.18 |
brlcad |
woot,
http://dreamcss.blogspot.com/2009/02/10-free-and-useful-open-source.html |
| 22:07.59 |
louipc |
aww they
could have put a more interesting screenshot |
| 22:09.16 |
brlcad |
yeah
:) |
| 22:09.35 |
brlcad |
website needs
another face lift |
| 22:29.49 |
brlcad |
'read' is
failing |
| 22:58.07 |
*** join/#brlcad samrose
(n=samrose@ip67-95-244-194.z244-95-67.customer.algx.net) |
| 23:04.13 |
CIA-40 |
BRL-CAD:
03brlcad * r33853 10/brlcad/trunk/m4/prefix.m4: if stdout is
closed, read will fail on eof and loop infinitely. so we add some
checks for failed read and basic sanity to only ask yes/no 10 times
before giving up. |
| 23:08.26 |
brlcad |
that should
take care of the infinite loop, now on to the next one later
tonight |
| 23:08.31 |
brlcad |
(as I wait
for this build) |
| 23:29.08 |
starseeker |
brlcad: not
wincing at the boolweave code, but at the bug poping up there -
there be dragons for debugging and code sensitivity |
| 23:58.35 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 00:00.08 |
tc-rucho |
oh |
| 00:00.08 |
brlcad |
help view
opendb closedb tra |
| 00:00.11 |
brlcad |
it'll give
help on command(s) |
| 00:00.15 |
tc-rucho |
I
see |
| 00:00.17 |
brlcad |
like man a b
c |
| 00:00.23 |
tc-rucho |
but how to
get help about suboptions of a command? |
| 00:00.45 |
brlcad |
there is no
suboption help for that command |
| 00:00.50 |
brlcad |
but all is
not lost |
| 00:00.56 |
brlcad |
notice the
get/set |
| 00:01.07 |
brlcad |
run any one
of those without arguments and it'll get the current
value |
| 00:01.15 |
brlcad |
run with args
and it'll set |
| 00:02.04 |
tc-rucho |
got
it |
| 00:02.06 |
tc-rucho |
one more
thing |
| 00:02.08 |
brlcad |
now the
kicker, the 'ae' command does exactly the same |
| 00:02.20 |
brlcad |
if you run
ae, how many numbers you see? |
| 00:02.34 |
brlcad |
guess which
one is twist ;) |
| 00:03.01 |
tc-rucho |
how am I
supposed to guess what do {eye, ypr, quat, aet} stand for? I know
aet now, but how about the others? |
| 00:03.26 |
brlcad |
those are
documented in the mged tutorial series |
| 00:03.36 |
brlcad |
one of the
appendices |
| 00:03.41 |
tc-rucho |
mged> ae
45 45 0 |
| 00:03.43 |
tc-rucho |
mged>
ae |
| 00:03.45 |
tc-rucho |
45 45
-4.07111e-15 |
| 00:03.48 |
tc-rucho |
^ wtf?
lol |
| 00:03.58 |
brlcad |
they are also
on the mged help menu somewhere |
| 00:04.02 |
tc-rucho |
I would
expect it to return 45 45 0 |
| 00:04.30 |
brlcad |
that's basic
x86 floating point unit behavior |
| 00:05.07 |
brlcad |
it can't
exactly represent most integer values, that was the closest
approximation |
| 00:05.26 |
brlcad |
far beyond
numerical computation tolerance, mged just lets you know what the
hardware did |
| 00:05.56 |
tc-rucho |
ok, I think
I'm done asking stuff for now. Just one more thing. When I raytrace
something it stays as a background image and no clue how to erase
it, tried the 'fbclear' button in the raytrace menu but got an ugly
'command not found'. Any hint? |
| 00:06.05 |
tc-rucho |
maybe I have
to check something in my path |
| 00:06.22 |
brlcad |
another place
you can find more help on some of the commands, there's an mged
quick reference card on the website under docs |
| 00:06.26 |
``Erik |
export
PATH=$PATH:/usr/brlcad/bin |
| 00:07.04 |
brlcad |
yeah, run
that before you run mged and it should fix it - what version are
you using? |
| 00:10.38 |
``Erik |
wow...
just... wow... http://www.collegehumor.com/picture:1900391 |
| 00:13.20 |
tc-rucho |
7.10.4 |
| 00:17.53 |
tc-rucho |
it would be
really cool if brlcad had something like 'man' for a detailed
explanation of every option available for a command (does it have
it and I didn't notice?) |
| 00:18.58 |
tc-rucho |
oh
yeah |
| 00:19.14 |
tc-rucho |
it does have
a manpage for each command |
| 00:19.24 |
brlcad |
there are
manpages for most of the external commands |
| 00:19.26 |
tc-rucho |
just that
doesn't seem to be accessible from the mged |
| 00:19.30 |
brlcad |
yeah |
| 00:19.31 |
tc-rucho |
yeah, just
noticed |
| 00:19.40 |
brlcad |
brlman will
search the /usr/brlcad manpath |
| 00:19.54 |
brlcad |
but you'll
get better results if you just set your MANPATH |
| 00:20.18 |
brlcad |
we're working
on having more detailed "manpages" for all of the mged commands
too, that's just a hell of a lot of work |
| 00:21.39 |
tc-rucho |
I know, maybe
I will help with that in the future, but I first need to get the
hang of brlcad, it's like drawing using assembly
language |
| 00:21.48 |
tc-rucho |
no fancy
mouse thing |
| 00:21.58 |
brlcad |
at least not
until you're a lot more proficient |
| 00:22.17 |
brlcad |
there are
lots of various shortcuts for most tasks, but it's way too much to
get into for new users |
| 00:22.24 |
brlcad |
just gets
confusing before you learn the basics |
| 00:22.30 |
``Erik |
for a in
`mged -c blah.g 'echo $MGED_CMDS'` ; do echo "Things and stuff"
> $a.help ; done |
| 00:22.40 |
``Erik |
:D
*duck* |
| 00:23.10 |
``Erik |
sorry, I'll
behave :) |
| 00:23.36 |
brlcad |
tc-rucho: if
you do get interested in helping out with the docs, there are about
100 external commands that don't have manpages yet (listed in the
TODO file iirc), and pretty much most/all of the mged commands need
to be expanded for manpage format |
| 00:25.00 |
tc-rucho |
yeah, but
first I need to decide whether or not brlcad is a good solution for
my needs. |
| 00:25.07 |
brlcad |
sure |
| 00:25.22 |
brlcad |
if it's not a
good solution, always looking for good hands to help make it one
;) |
| 00:25.27 |
brlcad |
open dev
team |
| 00:25.47 |
tc-rucho |
good
(: |
| 00:27.40 |
tc-rucho |
would love brlcad if it had some lisp dialect [instead of
tcl] (what's between brackets it's optional) |
| 00:28.14 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 00:28.14 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 00:28.19 |
CIA-40 |
BRL-CAD:
03brlcad * r33885 10/brlcad/trunk/src/libbn/tcl.c: clamp all
floating point values being printed to a string to a corresponding
integer value if the number is within hardware computational
tolerance. the user probably wanted and expects 42 instead of
41.9999999999997. |
| 00:31.09 |
CIA-40 |
BRL-CAD:
03brlcad * r33886 10/brlcad/trunk/NEWS: |
| 00:31.09 |
CIA-40 |
BRL-CAD:
clamp even more values to the closest corresponding integer if
they're within |
| 00:31.09 |
CIA-40 |
BRL-CAD:
hardware tolerance. this change was made in response to unexpected
behavior |
| 00:31.09 |
CIA-40 |
BRL-CAD:
reported by a new user (tc-rucho) learning to use various view
manipulation |
| 00:31.10 |
CIA-40 |
BRL-CAD:
commands. the effect of this change should be pretty pervasive to
most mged |
| 00:31.12 |
CIA-40 |
BRL-CAD:
commands that utilize the libbn routines for printing numbers to
strings (ae |
| 00:31.14 |
CIA-40 |
BRL-CAD:
being one example). |
| 00:32.56 |
tc-rucho |
brlcad: I
think using fractions for internal calcs and then converting to
float for UI output would avoid a lot of float
weirdness |
| 00:33.29 |
brlcad |
heh |
| 00:33.48 |
brlcad |
it sure
would |
| 00:33.55 |
tc-rucho |
(: |
| 00:34.28 |
brlcad |
it'd also be
approximately three orders of magnitude slower for most operations
:) |
| 00:34.49 |
brlcad |
not to
mention require a pretty pervasive data type change
throughout |
| 00:35.18 |
tc-rucho |
it's always
like this T_T |
| 00:35.33 |
tc-rucho |
friggin
floats |
| 00:35.36 |
brlcad |
(we're
talking about affecting something on the order of a quarter-million
lines of code) |
| 00:36.07 |
tc-rucho |
ugh |
| 00:36.17 |
brlcad |
it's much
easier to just test the number and print it cleanly, and account
for floating point fuzz in the calculations |
| 00:36.42 |
brlcad |
that last
change should make what you just saw go away |
| 00:37.44 |
brlcad |
I've toyed
with using something like gmp behind our fastf_t number type to get
exact calculations -- that'd be an interesting gsoc project for
someone to take on |
| 00:41.47 |
tc-rucho |
brlcad: is
there a way to _lock_ tw to a certain value when using the mouse to
rotate the view? |
| 00:42.49 |
brlcad |
ooof, I
believe so, but I don't have the mouse keybindings memorized --
maybe check the shift-grips table on the docs? |
| 01:11.42 |
tc-rucho |
when trying
to modify just 1 element from a parameter array, is there a way to
tell mged to reuse existing value in that position? I mean
something like 'view aet . . 0' which would reuse the current az
and el, and set tw to 0 |
| 01:15.48 |
tc-rucho |
it's not
really that cool to retype everything to change just 1
element |
| 01:16.27 |
*** join/#brlcad tc-rucho
(n=tc-rucho@190.191.172.28) |
| 01:17.00 |
Ralith |
not_so_fastf_t |
| 01:20.11 |
tc-rucho |
oops, seems
my last 2 lines were sent to /dev/null |
| 01:20.26 |
tc-rucho |
when trying
to modify just 1 element from a parameter array, is there a way to
tell mged to reuse existing value in that position? I mean
something like 'view aet . . 0' which would reuse the current az
and el, and set tw to 0 |
| 01:20.26 |
tc-rucho |
it's not
really that cool to retype everything to change just 1
element |
| 01:22.59 |
Ralith |
brlcad: how
would you drop in gmp in an elegant way? I can't see a method
cleaner than replacing every single arithmetic operation with a
preprocessor macro or similar. |
| 01:23.55 |
tc-rucho |
sed -i
? |
| 01:24.59 |
Ralith |
tc-rucho:
even if it was that simple, which it's not, the end result would
still be very ugly |
| 01:27.35 |
tc-rucho |
anyway,
Ralith, is there a way to tell mged to reuse a current value
instead typing it again over and over? |
| 01:27.53 |
Ralith |
no, but try
the up arrow |
| 01:27.56 |
Ralith |
not
afaik* |
| 01:30.24 |
brlcad |
tc-rucho: hm,
can't say that need has actually ever come up to only change twist
-- at least no requests for it |
| 01:30.48 |
brlcad |
you can just
up-arrow and change a previous line if it's a need to repeatedly
test new values |
| 01:31.03 |
brlcad |
there is
command history |
| 01:31.24 |
tc-rucho |
brlcad: no,
if there was no previous line regarding those values there's
nothing to do but to retype the whole thing |
| 01:31.25 |
brlcad |
Ralith: via
compilation with a c++ compiler |
| 01:31.36 |
Ralith |
brlcad:
huh? |
| 01:31.51 |
Ralith |
does GCC have
some special gmp support or something? |
| 01:32.11 |
brlcad |
tc-rucho: you
said retype -- but I think you mean type ;) |
| 01:32.11 |
Ralith |
oh
right |
| 01:32.12 |
Ralith |
C++. |
| 01:32.17 |
Ralith |
operator
overloading. |
| 01:32.19 |
brlcad |
operator
overlaoding |
| 01:32.20 |
brlcad |
right |
| 01:32.22 |
tc-rucho |
brlcad: right
(: |
| 01:32.24 |
Ralith |
I thought all
that code was in C, though |
| 01:32.32 |
brlcad |
it
is |
| 01:32.42 |
Ralith |
moving it to
C++ is acceptable? |
| 01:32.50 |
Ralith |
thought he recalled some reluctance to do
that |
| 01:33.12 |
brlcad |
doesn't mean
that it can't be compiled with a c++ compiler -- we don't hit the
problem cases |
| 01:33.24 |
Ralith |
hm, good
point |
| 01:33.34 |
brlcad |
oh hell,
wouldn't move to that -- it would destroy performance for
real-world use |
| 01:33.51 |
brlcad |
literally, it
is two-to-three *orders* slower .. |
| 01:34.08 |
Ralith |
really? I
didn't know C++ impaired performance that much. |
| 01:34.14 |
brlcad |
no |
| 01:34.16 |
Ralith |
assuming
you're just doing C things in it |
| 01:34.17 |
brlcad |
you're
missing something :) |
| 01:34.40 |
Ralith |
what'm I
missing, then? |
| 01:34.41 |
brlcad |
talking about
replacing fastf_t's with a fixed-precision numeric class
type |
| 01:34.44 |
Ralith |
oh,
yes |
| 01:34.50 |
Ralith |
of
course |
| 01:35.01 |
Ralith |
I thought you
were responding to my question about moving to C++. |
| 01:35.11 |
brlcad |
I was also
responding to that |
| 01:35.16 |
brlcad |
we wouldn't
"move" to C++ |
| 01:35.56 |
brlcad |
if we wanted
to make a fixed-precision compile, we'd would make it work through
the c++ compiler and use the fixed-precision math
pervasively |
| 01:36.52 |
brlcad |
it would be a
compile-time toggle that could be used for various purposes where
the performance hit was acceptible, like regression testing,
certain analyses, certain geometric transformations,
etc |
| 01:36.53 |
Ralith |
and the way
you'd keep that in the same codebase would be by ifdef-ing out the
GMP bits, which would be the only part requiring C++
features? |
| 01:36.56 |
tc-rucho |
brlcad: in a
normal bash session I would do => view aet `view aet | awk
'{print $1 $2 "0"}'` However, if you think it makes sense to add
something like => view aet @ @ 0 where '@' would reuse the
current value for that field, then I will gladly contribute a patch
adding it (: |
| 01:37.09 |
brlcad |
Ralith:
right |
| 01:37.18 |
Ralith |
part of me
thinks that's a hack |
| 01:37.25 |
Ralith |
and part of
me thing that's a wonderfully effective solution |
| 01:37.50 |
Ralith |
hm. |
| 01:37.54 |
brlcad |
it's not a
hack if it works, rather elegant imho |
| 01:38.05 |
brlcad |
still a lot
of work, though |
| 01:38.16 |
Ralith |
yeah, I guess
I just have an innate aversion to the preprocessor. |
| 01:38.31 |
Ralith |
comes from
too much playing with higher level languages |
| 01:38.36 |
brlcad |
have to make
fastf_t's fully pervasive, have to have a whole buffet of operator
functions |
| 01:38.45 |
brlcad |
tc-rucho:
hmmm |
| 01:39.46 |
tc-rucho |
because I
don't think aet will be the only command that will benefice from a
value-reuser |
| 01:40.42 |
brlcad |
command-parsing like that is still
command-specific, though, as args are vastly different from command
to command |
| 01:41.01 |
brlcad |
so either
start a new convention.. or add new subcommands |
| 01:41.06 |
Ralith |
considers finding himself a GSoC project to sign on
to |
| 01:41.07 |
brlcad |
view tw
12 |
| 01:41.22 |
brlcad |
view az
10 |
| 01:42.09 |
tc-rucho |
yeah |
| 01:42.13 |
brlcad |
tc-rucho: how
about the latter, a lot more isolated to just add new view
subcommands |
| 01:42.37 |
tc-rucho |
brlcad: would
they be included in brlcad if I make them? |
| 01:42.45 |
brlcad |
and goes well
with the aim to make the commands more stateless |
| 01:42.50 |
brlcad |
tc-rucho:
absolutely |
| 01:42.55 |
tc-rucho |
good
(: |
| 01:43.13 |
brlcad |
good to have
all three, az|el|tw |
| 01:43.52 |
tc-rucho |
I think it
would be nice to be able to do something like => view tw 0 el
30 |
| 01:44.07 |
tc-rucho |
being 'view'
the main command and the rest options with values |
| 01:44.14 |
brlcad |
sure, gang up
sets of commands on view |
| 01:44.28 |
brlcad |
view ypr 10
200 0 tw 10 |
| 01:44.45 |
brlcad |
similar to
what you ran into for help ;) |
| 01:45.40 |
brlcad |
src/libged/view.c is where the view
command lives |
| 01:45.42 |
tc-rucho |
yeah, I
strongly believe changing the commands model a bit would improve
mged's usability a _LOT_ |
| 01:45.46 |
brlcad |
it calls out
to various other commands |
| 01:45.58 |
brlcad |
we're working
on that |
| 01:46.42 |
tc-rucho |
I'm your man
then (: but I will be able to get my hands on the commands code in
april |
| 01:46.42 |
brlcad |
first step
was getting all the commands out of the application front-end and
in one place in a library (libged) |
| 01:47.01 |
brlcad |
next step
is/was making all the commands modeless (ugh, lots to
do) |
| 01:47.10 |
brlcad |
there's still
a lot more that has to happen |
| 01:48.22 |
tc-rucho |
sure |
| 01:48.24 |
brlcad |
next step
after that is command reduction and consolidation |
| 01:49.06 |
tc-rucho |
I'd love some
tw lock for mouse orbit |
| 01:49.10 |
brlcad |
e.g. instead
of a dozen bot_* commands, there's one bot command with various
subcommands |
| 01:49.34 |
brlcad |
hey, if you
make the mod, there's no reason to not put features like that
in |
| 01:49.58 |
tc-rucho |
I like
that |
| 01:49.59 |
tc-rucho |
(: |
| 01:50.33 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 01:50.36 |
brlcad |
make more
than a couple useful patches and you'd end up working directly on
the code |
| 01:51.11 |
brlcad |
Ralith: are
you applying? |
| 01:51.42 |
Ralith |
brlcad: well,
student applications aren't for a month or so, right? |
| 01:51.48 |
Ralith |
I certainly
like the idea. |
| 01:52.07 |
brlcad |
yeah |
| 01:52.15 |
brlcad |
the problem
here will be slots |
| 01:52.42 |
brlcad |
if we
participate, I'm planning to probably have even fewer students than
last year |
| 01:53.23 |
brlcad |
just 2 or 3,
so it'll be even more competitive |
| 01:53.42 |
tc-rucho |
brlcad: what
do you mean? svn access? |
| 01:53.46 |
brlcad |
tc-rucho:
sure |
| 01:53.48 |
Ralith |
aw. Perhaps
I'll find myself a less high profile mentoring
organization. |
| 01:53.54 |
Ralith |
tc-rucho:
happened to me. |
| 01:54.00 |
tc-rucho |
brlcad: oh,
nice (: |
| 01:54.25 |
brlcad |
Ralith: i'm
not saying you don't have a chance, you have a leg up just by
already being part of the community with a history :) |
| 01:54.41 |
brlcad |
some of last
year's students have leverage too in that regard |
| 01:54.59 |
Ralith |
brlcad: fair.
Are you allowed to apply to multiple organizations and take your
pick of the acceptors? |
| 01:55.18 |
brlcad |
doesn't work
that way exactly, but yes you can apply to multiple
orgs |
| 01:55.31 |
Ralith |
will read up on it |
| 01:55.38 |
brlcad |
if you are
accepted by multiple orgs, though, the orgs sort it out (and maybe
or maybe not involve you) |
| 01:55.43 |
Ralith |
O.o |
| 01:55.50 |
Ralith |
that's...
weird |
| 01:55.56 |
brlcad |
all happens
behind the scenes |
| 01:56.09 |
brlcad |
there's a big
conflict resolution meeting |
| 01:56.18 |
brlcad |
if it's not
resolved beforehand |
| 01:57.03 |
Ralith |
is there a
list of SoCables anywhere? Perhaps some subset of that wanted
features page of yours? |
| 01:57.12 |
Ralith |
(within
BRL-CAD, that is) |
| 01:57.39 |
brlcad |
it works out
well because many acceptances are contingent on a lot of factors ..
like if the project you proposed to one org is considerably more
valuable than it was to another org, or maybe you're right on the
cutoff and they haven't decided on whether to accept you as
N+1 |
| 01:58.04 |
brlcad |
Ralith: yeah,
you can see the materials for last year up on the
website |
| 01:58.04 |
Ralith |
hm, I guess
that is pretty reasonable. |
| 01:58.13 |
brlcad |
has a list of
a dozen or so projects |
| 01:58.19 |
Ralith |
nothing new
since then? |
| 01:58.33 |
brlcad |
I'll probably
cull that down to about a half-dozen this year to focus
applications |
| 01:58.43 |
brlcad |
plenty
new |
| 01:58.47 |
brlcad |
but nothing
that needs to be added |
| 01:59.02 |
Ralith |
'kay
then |
| 01:59.20 |
brlcad |
and students
are always welcome to submit ideas not on the list |
| 01:59.29 |
brlcad |
some of the
best ideas for bz haven't been on our list |
| 02:00.34 |
Ralith |
bzflag is on
SoC? I didn't know they did games. |
| 02:00.45 |
brlcad |
we were their
first game two years ago |
| 02:00.49 |
Ralith |
neat! |
| 02:00.52 |
brlcad |
this will be
year three if we accept |
| 02:00.56 |
``Erik |
wow,
europeans take their winter sports seriously http://www.collegehumor.com/video:1901384 |
| 02:02.13 |
brlcad |
``Erik: do
you just wander through video, joke, and comic forums for hours on
end?? |
| 02:02.27 |
brlcad |
sounds like a
bigger brain-rotting waste of time than watching tv all
day |
| 02:02.31 |
brlcad |
:) |
| 02:02.40 |
tc-rucho |
agrees |
| 02:03.31 |
Ralith |
I dunno, at
least it's interactive |
| 02:04.06 |
``Erik |
yes, yes I
do |
| 02:04.12 |
``Erik |
at least
until I'm caught up |
| 02:04.23 |
brlcad |
shakes head |
| 02:04.31 |
``Erik |
eventually,
I'll make it to the end of the internet, get the highscore and
finally beat it |
| 02:05.49 |
brlcad |
tc-rucho: if
you go diving in, keep in mind that libged is the start of a pretty
big refactoring effort -- and is subject to change |
| 02:06.19 |
brlcad |
not so much
the commands themselves and how they behave but the ged struct and
how data makes it in and out |
| 02:06.41 |
brlcad |
and there's
still a lot more to go to decouple tcl |
| 02:06.44 |
tc-rucho |
brlcad: I was
already considering in getting latest svn sources of BRLCAD to
start diving into it's code |
| 02:07.29 |
brlcad |
also, you
mentioned other languages -- for what it's worth if you've not seen
it, mged can be pretty readily scripted and batched from any
language |
| 02:07.42 |
brlcad |
e.g.,
http://brlcad.org/wiki/SGI_Cube |
| 02:07.42 |
tc-rucho |
brlcad: by
the way, you just mentioned decoupling tcl, what are you implying?
getting rid of it and adopting something else or what? |
| 02:08.09 |
tc-rucho |
yeah, noted
that from the very beginning |
| 02:08.39 |
tc-rucho |
it's just
that having a nice language within mged itself would be nice for
batch stuff |
| 02:09.05 |
Ralith |
tc-rucho:
making the system scripting language independent |
| 02:09.14 |
brlcad |
we're not
getting "rid" of tcl for various reasons, but certainly want to
allow other interpreter environments |
| 02:09.18 |
Ralith |
i.e. make it
straightforward to slot in w/e |
| 02:09.35 |
brlcad |
exactly |
| 02:09.59 |
tc-rucho |
well, in that
case it would be nice to have some lisp dialect as an interpreter
too |
| 02:10.05 |
brlcad |
part of the
libged framework is to make it a generalized command functionality
library that could be tied into any interpreter
environment |
| 02:11.07 |
tc-rucho |
I like that,
so a couple of bindings here and there and one could almost use BF
as a command interpreter (just kidding) |
| 02:11.11 |
brlcad |
initial goal
will be to support tcl and bash, and then python and lisp, at least
as a starting point |
| 02:11.33 |
brlcad |
that should
generalize the interface sufficiently to support most languages
we'd care to bind to |
| 02:11.43 |
tc-rucho |
sure |
| 02:12.16 |
brlcad |
plus it
covers procedural, functional, and OO as well as interactive and
non-interactive parsing |
| 02:12.54 |
brlcad |
(in terms of
a flexible api) |
| 02:13.04 |
tc-rucho |
you have any
dialect in mind for the lisp environment? |
| 02:13.16 |
brlcad |
not
presently |
| 02:13.29 |
brlcad |
clisp,
elisp |
| 02:14.07 |
tc-rucho |
In terms of
implementation quality, I'd stick to SBCL (common lisp) on unixoid
systems, and maybe clisp for winblows |
| 02:15.17 |
tc-rucho |
anyway, seems
this could get pretty interesting. I'd say I'm in (: |
| 02:15.24 |
brlcad |
one of the
main points of picking up a lisp environment would be to provide
something similar to autolisp |
| 02:15.40 |
brlcad |
awesome, glad
to hear it! |
| 02:15.58 |
brlcad |
hope you
stick to it even after you see how much work is involved
;) |
| 02:16.26 |
brlcad |
good stuff,
though, lots of fun and one of the best code bases to make a big
impact |
| 02:17.15 |
tc-rucho |
as soon as I
can get a lisp environment things will get really nice 9In 9My
9Opinion |
| 02:17.55 |
tc-rucho |
however, I'm
definitely not enforcing OO in the lisp environment, it's...
ugly |
| 02:21.34 |
brlcad |
no no, I
meant supporting OO semantics for languages like
python/ruby/etc |
| 02:21.48 |
brlcad |
wouldn't
sully lisp with that |
| 02:22.07 |
brlcad |
might not
even sully the other langs with that, depends on how the bindings
happen |
| 02:23.16 |
brlcad |
ultimately
could just wrap everything in a ged object and do a pass through
with a method for every function if it's a strict OO
language |
| 02:25.47 |
tc-rucho |
anyway, I
have some proposals for the lisp environment, but bindings come
first |
| 02:26.12 |
tc-rucho |
more
specifically, a slight GUI change |
| 02:27.16 |
tc-rucho |
that would
allow keybindings and access to the command prompt in the same
window without any extra hassle |
| 02:27.51 |
tc-rucho |
anyway, I
should continue with my studies, I have a huge exam in a pair of
days |
| 02:30.09 |
brlcad |
heh, actually
we're looking at a rather major GUI change, but that's a ways down
the road |
| 02:30.57 |
brlcad |
have to do a
variety of mged refactorings first, libged cleanup, tcl decoupling,
finish implementing BREP support, geometry engine support, geometry
service support, then the gui has something solid to talk
to |
| 02:31.14 |
brlcad |
there is a
prototype interface hooked in already that a gsoc student worked on
last summer |
| 02:31.37 |
brlcad |
good luck
with your exam tc-rucho ! |
| 02:33.40 |
tc-rucho |
nods |
| 02:34.14 |
tc-rucho |
brlcad: what
text editor do you use? |
| 02:34.33 |
brlcad |
depends what
I'm doing, but usually emacs |
| 02:36.03 |
tc-rucho |
well, some
_wild_ idea for a GUI would be to have most used commands as single
letter commands, and then have some stuff like C-x and
C-c |
| 02:36.26 |
tc-rucho |
but maybe
people would not feel that comfortable with it |
| 02:36.43 |
tc-rucho |
anyway, was
just a quick wild thought |
| 02:37.18 |
brlcad |
there's a
whole design philosophy about making the interface pervasively
modeless, only allowing quasimodalities for context-specific
actions |
| 02:37.46 |
brlcad |
there's a
prototype interaction video that one of the devs worked on that I'm
using as a sort of "starting point" goal |
| 02:38.00 |
tc-rucho |
link? |
| 02:38.33 |
brlcad |
http://brlcad.org/design/gui/ |
| 02:38.44 |
brlcad |
ioe_proto_final.mov is a good starting
point |
| 02:39.23 |
brlcad |
takes about 5
minutes |
| 02:39.52 |
brlcad |
it was
intionally made non-CAD-centric, but the basic design philosophies
still apply |
| 02:42.12 |
brlcad |
~ioe |
| 02:42.19 |
tc-rucho |
I think about
brlcad as a rough diamond. It has an awesome 3d framework and all,
but it lacks a good GUI 9In 9My 9Humble 9Opinion |
| 02:46.05 |
brlcad |
agreed |
| 02:46.30 |
brlcad |
that's why
it's one of our four top project priorities |
| 02:46.40 |
brlcad |
http://brlcad.org/BRL-CAD_Priorities.png |
| 02:46.59 |
brlcad |
with the
other three priorities directly and indirectly supporting
it |
| 02:49.05 |
brlcad |
starseeker: I
think I must recall my victory claim.. I'm getting the Tcl_Init
error again, so there must be more needed (and my test earlier must
not have been a clean test) |
| 03:00.07 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 04:00.10 |
yukonbob |
hello,
cadheads |
| 05:04.44 |
starseeker |
brlcad:
arrrgh. Is it something to do with the tcl upgrade? |
| 05:05.33 |
starseeker |
tried to step through all the changes, but may have missed
something... |
| 05:27.34 |
brlcad |
starseeker:
that's when it started, and it's a problem I recall needing to be
patched the past couple times we've done a tcl upgrade |
| 05:30.35 |
brlcad |
can't say for
certain without dishing through a whole debugging session, and
trying to avoid spending the time to do that frankly |
| 05:30.52 |
starseeker |
brlcad:
arrrgh |
| 05:30.56 |
starseeker |
``Erik:
help |
| 05:31.06 |
starseeker |
you recall
what was needed in the last couple tcl upgrades? |
| 05:33.14 |
brlcad |
i'll go
through a clean rebuild here to see if maybe the failure earlier
today was a false positive |
| 05:33.30 |
starseeker |
]it's
distcheck that's failing? |
| 05:33.42 |
brlcad |
test
fails |
| 05:34.22 |
brlcad |
specific to
doing a make test prior to (ever) doing a make install -- it'll
look in /usr/brlcad so have to make sure there isn't an install
there already |
| 05:34.28 |
starseeker |
Is it MacOSX
only? It seems to work here |
| 05:34.32 |
starseeker |
oh |
| 05:34.36 |
starseeker |
did a make install |
| 05:34.59 |
brlcad |
one of the
sanity checks to make sure in-tree execution works cleanly pulling
the right files |
| 05:35.30 |
starseeker |
Oh, I see it
now |
| 05:35.49 |
brlcad |
it's not a
release stopper |
| 05:36.02 |
brlcad |
but it
shouldn't linger (assuming it is new/returned) |
| 05:36.58 |
brlcad |
could try a
7.14.0 to see if it has the problem |
| 05:37.06 |
starseeker |
ok |
| 05:37.23 |
brlcad |
maybe it was
broken during the prior upgrade and just coincidentally
noticed |
| 05:38.08 |
starseeker |
is bothered he didn't get it patched with that last
effort |
| 05:38.53 |
brlcad |
you fixed a
whole slew of other issues that would have come up,
though |
| 05:38.59 |
brlcad |
so good you
did anyways |
| 05:39.13 |
starseeker |
thanks, but
it makes this one all the more vexing |
| 05:39.27 |
brlcad |
1/10th the
time to find/fix now than to have someone else spend all day
rehunting each one ;) |
| 05:39.35 |
starseeker |
:-) |
| 05:39.51 |
starseeker |
makes a note to join the tcl dev email lists and start making
some noise |
| 05:40.00 |
starseeker |
grumble |
| 05:40.15 |
starseeker |
not that I
had a lot of luck with gentoo |
| 05:40.43 |
brlcad |
gentoo is so
close, should be able to finish it up now |
| 05:41.16 |
starseeker |
assuming they
don't just leave it to the gentoo-science overlay |
| 05:41.26 |
brlcad |
nods |
| 05:41.51 |
brlcad |
haven't seen
a build log in a while to know if there's anything else that needs
changed |
| 05:42.05 |
brlcad |
I took care
of most of the issues I knew about |
| 05:42.11 |
starseeker |
I haven't
tried to do a system build in a long while - it might work
now |
| 05:42.43 |
brlcad |
it should
work as a --disable-all now without a problem |
| 05:42.50 |
starseeker |
cool
:-) |
| 05:43.05 |
starseeker |
will test that once the make test bug is hunted
down |
| 05:43.15 |
brlcad |
incrTcl init
was the last straggler, and that should be taken care
of |
| 05:43.23 |
starseeker |
awesome |
| 05:43.31 |
brlcad |
there are
still the naming conflicts, but that's for later to allow subdir
relinking |
| 05:43.55 |
starseeker |
brlcad: Oh,
that reminds me - bob said you wrote the libtclcad auto_path
command |
| 05:44.10 |
starseeker |
did that
change I made cause any trouble? |
| 05:44.16 |
brlcad |
the function,
yeah |
| 05:44.45 |
brlcad |
what
change? |
| 05:44.57 |
starseeker |
let me
check |
| 05:45.21 |
starseeker |
r33845 |
| 05:46.00 |
brlcad |
oh yeah, that
one.. |
| 05:48.09 |
brlcad |
"probably"
only because tclcadAutoPath() is mostly supposed to allow
relocation overrides and source-dir executions to work, not serve
as install defaults |
| 05:48.29 |
brlcad |
if it works,
it'll be because of how it searches for relocation
execution |
| 05:49.12 |
brlcad |
can't say for
sure, though .. |
| 05:50.16 |
starseeker |
ok. If it
breaks anything I'll revert it - it sidestepped what I was running
into, but it's still not clear to my why auto_path had the system
paths in the first place |
| 05:50.32 |
starseeker |
maybe it's
related to why make test isn't working, for that
matter... |
| 05:50.44 |
brlcad |
I think the
latter is a different problem, and the one that needed fixing --
why it got system paths in the first place |
| 05:51.15 |
brlcad |
think that
implies that it didn't load the right init.tcl to start with or
didn't link the right lib to start with |
| 05:51.24 |
brlcad |
which are
different problems |
| 05:51.51 |
starseeker |
Is that our
build system or the tcl/tk level logic? |
| 05:52.47 |
brlcad |
wouldn't be
the build system -- could be run-time ld paths or tcl init
logic |
| 05:53.53 |
brlcad |
you can check
the ld linkage easily enough (otool -L or ldd) |
| 05:54.23 |
brlcad |
can check the
init logic by breaking in Tcl_Init() and seeing which init.tcl is
loaded |
| 05:57.06 |
starseeker |
ldd looks
OK |
| 06:04.37 |
brlcad |
notes that Bob cheated horribly in
src/mged/setup.c |
| 06:11.30 |
starseeker |
brlcad: did
we need to explicitly set tcl_library? |
| 06:11.35 |
starseeker |
was that the
patch? |
| 06:19.03 |
starseeker |
ummm....
7.14.0 on my machine is trying to use /usr/include/tk.h when
compiling bombardier.c |
| 06:28.17 |
brlcad |
different
issue |
| 06:28.37 |
brlcad |
src/util/Makefile.am, add TK_CPPFLAGS to
bombardier |
| 06:37.08 |
CIA-40 |
BRL-CAD:
03brlcad * r33887 10/brlcad/trunk/configure.ac: default the ogl
interface to off until the various bugs are all fixed. it's
unusable as-is due to said bugs and is just complicating the
support questions. |
| 06:37.08 |
CIA-40 |
BRL-CAD:
03brlcad * r33890 10/brlcad/trunk/NEWS: |
| 06:37.08 |
CIA-40 |
BRL-CAD: Bob
added a new 'gqa' command to mged that runs the formerly
command-line-only |
| 06:37.08 |
CIA-40 |
BRL-CAD:
'g_qa' command including the addition of a new -Ap option that will
visualize |
| 06:37.10 |
CIA-40 |
BRL-CAD: the
overlaps encountered as a series of wireframe edges similar to
rtcheck. |
| 06:37.12 |
CIA-40 |
BRL-CAD:
should rename one of the two to make running the tool
self-consistent inside and |
| 06:37.14 |
CIA-40 |
BRL-CAD:
outside of mged. |
| 06:37.20 |
CIA-40 |
BRL-CAD:
03brlcad * r33888 10/brlcad/trunk/ (NEWS TODO): bob fixed the mged
view initialization bugs where it was starting up under a top view
instead of 3525 with no faceplate initialization. should be mostly
all better now. |
| 07:05.18 |
brlcad |
notes warnings on nmg_fix_normals |
| 07:13.05 |
CIA-40 |
BRL-CAD:
03brlcad * r33891 10/brlcad/trunk/src/libged/ (178
files): |
| 07:13.05 |
CIA-40 |
BRL-CAD:
whew, that is brutal.. tedius header cleanup to denote private
headers as |
| 07:13.05 |
CIA-40 |
BRL-CAD:
private (and in the own section) using relative path syntax. also
make sure |
| 07:13.05 |
CIA-40 |
BRL-CAD:
bio.h comes after the system headers but is listed with system
headers (it's |
| 07:13.06 |
CIA-40 |
BRL-CAD: sort
of a wrapper around stdio). |
| 08:07.55 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 10:11.20 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:44.10 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 10:54.28 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 10:54.28 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 11:05.29 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 11:05.29 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 11:08.20 |
d-lo |
yawns |
| 11:08.23 |
d-lo |
Mornin |
| 11:41.15 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 11:43.43 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.246.241) |
| 12:00.51 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 13:11.46 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:13.44 |
starseeker |
brlcad: I'll
be out one more day, I'm afraid :-( |
| 13:15.51 |
starseeker |
d-lo: I can't
find the email addresses - could you do me a favor and send out an
email again? |
| 13:17.49 |
d-lo |
starseeker:
shore thang. |
| 13:17.55 |
starseeker |
thanks
:-) |
| 13:27.23 |
d-lo |
np |
| 13:55.52 |
brlcad |
starseeker:
okay, np |
| 14:07.21 |
``Erik |
starseeker:
the only caveat with tcl and tk was that one line in
tcl/generic/tclInt.h iirc, tk "just worked". incr is a bit of a
different story |
| 14:08.32 |
``Erik |
was under the impression that elisp had grevious differences
to cl (stuff like scope handling, basic function names, etc), but
kinda remembers reading that autolisp was weird, too
*shrug* |
| 14:09.06 |
``Erik |
supposedly,
CLOS can do all t he oo type things that ruby and python can, plus
a slew of other neat stuff like generic funcs |
| 14:11.32 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:20.11 |
tc-rucho |
``Erik: CLOS
is an awesome OO system, it does not use messages, it uses generic
functions. However, I find OO rather ugly in Lisp. It's like
jailing/restricting oneself rather than liberating |
| 14:20.36 |
tc-rucho |
OO in lisp
usually leads to code that's really difficult to track |
| 14:21.07 |
``Erik |
hm, I'm more
of a scheme weenie, I've only used clos just enough to get a basic
ucw thingy working :) |
| 14:22.47 |
tc-rucho |
well, I use
common lisp as my main lisp dialect, and I really never needed
CLOS, it made things more difficult actually, and heavily OO code
made using CLOS was hell to figure out. |
| 14:23.13 |
tc-rucho |
not even the
original authors were able to keep track of it in order to fix some
stuff, blame CLOS |
| 14:23.36 |
tc-rucho |
so I would be
happier if we stick to just lists for the bindings and
all |
| 14:23.38 |
tc-rucho |
. |
| 14:25.16 |
``Erik |
*shrug* I
still plan on learning it, I've heard arguments both ways so mebbe
I'll find it a handy tool for certain problems, mebbe
not |
| 14:26.02 |
tc-rucho |
points to the second alternative |
| 14:26.09 |
tc-rucho |
anyway |
| 14:26.28 |
``Erik |
but yeah,
with scheme I felt like the combination of lists, vectors, and
assocs is probably 'sufficient' |
| 14:27.37 |
tc-rucho |
have it your
way, give it a try, try to code something complex, then archive it
and look at it again in about 2 months, and if by any chance you
can follow the CLOS code easier than if it used just lists, I would
like some good argument about why use it |
| 14:27.46 |
tc-rucho |
right |
| 14:28.01 |
``Erik |
we'll see
*shrug* :) |
| 14:28.04 |
tc-rucho |
lists and
assocs are all one needs |
| 14:28.06 |
tc-rucho |
(: |
| 14:28.07 |
starseeker |
brlcad: I'm
seeing failures in the test script that appear to be caused by the
messing "Using Tcl library at..." being printed |
| 14:28.19 |
brlcad |
starseeker:
yeah, I know about those |
| 14:28.24 |
brlcad |
it's
benign |
| 14:28.38 |
starseeker |
but
otherwise, the MGED tests seem to run |
| 14:28.43 |
brlcad |
it's because
the script just takes the output of ? and help as-is |
| 14:29.11 |
brlcad |
and there are
a variety of debug and output messages that can appear before the
command list |
| 14:29.32 |
starseeker |
OK - so the
failure you're worried about is something different
then |
| 14:29.45 |
brlcad |
if there was
consistent stderr/stdout separation, could handle it, but there's
not so it is what it is |
| 14:29.45 |
tc-rucho |
``Erik: by
the way, what scheme implementation do you prefer? I really haven't
toyed with scheme (mainly because fucken scsh needs some scheme
implementation for 32bit only) |
| 14:30.27 |
``Erik |
gauche
usually, used to use guile but it's performance was ... poor. have
toyed with chicken and bigloo a little, and mzscheme isn't too
bad |
| 14:30.39 |
brlcad |
starseeker:
yeah, the error is something different -- Tcl_Init
failure |
| 14:30.55 |
starseeker |
so far I
can't reproduce that here |
| 14:31.08 |
brlcad |
on old or new
or both? |
| 14:31.15 |
starseeker |
anywhere |
| 14:31.16 |
tc-rucho |
``Erik: I
find mzscheme (drscheme?) kind of bloated. Wasn't gauche a scheme
-> C implementation? |
| 14:31.20 |
starseeker |
er,
either |
| 14:31.25 |
brlcad |
thought you
encountered it yesterday? |
| 14:31.31 |
brlcad |
when you
removed the installed version |
| 14:31.42 |
``Erik |
no, gauche is
an interpreter, um, shiro.dreamhost.com or something |
| 14:31.46 |
starseeker |
no, that was
the complaint I just mentioned |
| 14:32.01 |
``Erik |
the
interpreter is "gosh" |
| 14:32.33 |
starseeker |
``Erik: then
the compiler had better be "darnit" ;-) |
| 14:33.13 |
``Erik |
no, there's
no straight compiler component, I don't know if it can save
bytecode images, either :/ I used it for q&d scripty type
thangs mostly |
| 14:33.41 |
tc-rucho |
hohoho,
awesome name for a lisp-family interpreter |
| 14:34.56 |
brlcad |
starseeker:
i'm giving it a clean retry now |
| 14:35.17 |
brlcad |
see what you
get with this on a clean tree, it'll .. take a while |
| 14:35.38 |
brlcad |
rm -rf
/usr/brlcad && sh autogen.sh && ./configure
--enable-all && make distclean && sh autogen.sh
&& ./configure --enable-all && make -j4 &&
make test |
| 14:35.45 |
brlcad |
notice the rm
-rf in case you need it.. |
| 14:36.31 |
brlcad |
if that works
for you, then we can call it a closed issue |
| 14:36.52 |
``Erik |
hm, rm -rf
/usr/brlcad/* would be better, so the /usr/brlcad directory stays
and doens't need rootage to recreate it :D |
| 14:37.52 |
brlcad |
meh |
| 14:39.54 |
starseeker |
``Erik: on
my home box, no matter |
| 14:39.56 |
tc-rucho |
``Erik:
although it's not a really big problem, I've always felt more
comfortable with false being just nil and true being T, instead of
#t and #f. Also SBCL is a kick-ass implementation that compiles to
native code (not to mention that CL uses different spaces for
functions and data so a var and a function can share the same
name) |
| 14:41.55 |
starseeker |
tc-rucho: Oh,
he's an SBCL fan :-) |
| 14:42.09 |
starseeker |
so am
I |
| 14:42.20 |
tc-rucho |
starseeker:
good (: |
| 14:42.21 |
``Erik |
is using sbcl on fbsd for ucw :) |
| 14:43.02 |
tc-rucho |
then it's
going to be Common Lisp (SBCL), right? |
| 14:43.14 |
tc-rucho |
I thought
that had not been decided yet |
| 14:43.30 |
``Erik |
for BRL-CAD,
it's not |
| 14:43.35 |
``Erik |
not decided,
that is |
| 14:43.44 |
``Erik |
this is for a
private project |
| 14:43.57 |
starseeker |
ucw =
UnCommon Web |
| 14:44.22 |
starseeker |
ucw is...
odd |
| 14:44.33 |
starseeker |
at least as
far as getting it working |
| 14:44.59 |
d-lo |
no no no
no....ucw = http://www.ultimatechristianwrestling.com/ |
| 14:45.04 |
``Erik |
YOU'RE odd!
:D naw, the continuation based web framework model seems neato to
me |
| 14:45.34 |
``Erik |
you may've
spent a little TOO long in the navy, d-lo. |
| 14:45.46 |
starseeker |
d-lo: that's
gotta be in the top five "URLs I never thought I'd see"
list |
| 14:47.47 |
d-lo |
lol, blame
google. #2 on the list. |
| 14:47.58 |
starseeker |
brlcad: no
point in my doing -j4 on a 2 core machine, yes? |
| 14:48.18 |
brlcad |
whomever
works on making the lisp interface actually work will probably be
the main deciding factor on which lisp is used ;) |
| 14:48.26 |
``Erik |
best bang is
probably -j3, I'd guess |
| 14:48.36 |
brlcad |
so if you
want sbcl, someone needs to get busy ;) |
| 14:49.02 |
starseeker |
alrightie,
the clean test is running |
| 14:49.04 |
brlcad |
starseeker:
yeah, j3 is probably best, but doesn't matter much |
| 14:49.23 |
brlcad |
distclean or
clean? |
| 14:49.40 |
starseeker |
the sequence
you gave above |
| 14:50.01 |
starseeker |
autogen,
distclean, etc. |
| 14:50.31 |
starseeker |
could still
be a mac specific issue though |
| 14:50.50 |
starseeker |
``Erik: Did
you see any major patches to tcl that I missed in that big
roundup? |
| 14:51.32 |
``Erik |
I didn't see
your big roundup... :D the only trick was the line in tclInt.h or
something |
| 14:51.46 |
``Erik |
last I did
it, anyways... they may've made things more interesting |
| 14:52.26 |
starseeker |
erm |
| 14:52.44 |
starseeker |
Bob had some
Windows specific tweaks in there, and there was some SGI/IRIX
makefile logic |
| 14:52.57 |
starseeker |
or tweaks at
least |
| 14:53.20 |
starseeker |
plus the fix
for doc install paths from the gentoo bug |
| 14:53.44 |
starseeker |
oh well, no
matter |
| 14:54.05 |
starseeker |
it could very
well be that 8.5.6 itself introduced a new quirk all on its
own |
| 15:08.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 15:37.16 |
starseeker |
brlcad: OK,
I see it now |
| 15:45.20 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33892 10/brlcad/trunk/ (69 files in 3 dirs):
Upgraded libpng to 1.2.35. |
| 15:45.32 |
starseeker |
It looks like
we need to set tcl_library somewhere |
| 15:45.52 |
starseeker |
or set the
TCL_LIBRARY environment variable |
| 15:49.30 |
starseeker |
based on svn
diff, offhand I don't see any change pertaining to tcl_library that
could have an impact |
| 16:03.00 |
``Erik |
hrm |
| 16:08.23 |
starseeker |
grr:
http://pastebin.bzflag.bz/m3037d4dd |
| 16:11.48 |
starseeker |
export
TCL_LIBRARY=../src/other/tcl/library prior to make test does
succeed |
| 16:19.14 |
starseeker |
the
difficulty is where should it be set, and how to conditionalize its
setting on BUILD_TCL being true |
| 16:27.10 |
``Erik |
sweet, I done
broke the libpng stuff :D |
| 16:27.29 |
d-lo |
awesome! The
dishes are done man! |
| 16:34.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 16:57.13 |
*** join/#brlcad docelic
(n=docelic@78.134.207.11) |
| 17:01.37 |
brlcad |
starseeker:
additionally, tclcadAutoPath() tries to set tcl_library too, could
be some interplay going on |
| 17:01.54 |
brlcad |
good to see
that the problem can be reproduced, though |
| 17:02.09 |
brlcad |
starseeker:
did you test that with 7.14.0 too? |
| 17:02.41 |
brlcad |
if it fails
for 7.14.0, then it's not nearly as important to address now ..
just don't want to take steps backwards if it's new |
| 17:09.59 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 17:09.59 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 17:40.08 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:56.14 |
brlcad |
``Erik: build
failures in libpng's Makefile.am |
| 17:56.40 |
``Erik |
hm, cia is
being slow |
| 17:56.44 |
``Erik |
I fixed it a
few minutes ago |
| 17:56.54 |
brlcad |
cool,
k |
| 17:58.30 |
``Erik |
jabs cia a few times |
| 17:58.34 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33893 10/brlcad/trunk/src/other/libpng/
(Makefile.am autogen.sh config.h.in configure.ac): revert back to
our Makefile.am and remove the leftover autoconf crud. |
| 17:58.38 |
``Erik |
there it goes
heh |
| 18:39.29 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:42.12 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33894 10/brlcad/trunk/src/libged/gqa.c: ', '
doesn't make a lot of sense, hope it's supposed to be
',' |
| 18:44.34 |
brlcad |
``Erik
possible to get an isst screenshot today? |
| 18:44.52 |
brlcad |
could use
something glitzy to show off |
| 18:45.10 |
``Erik |
show off for
what? |
| 18:45.34 |
brlcad |
presentation
putting together |
| 18:46.26 |
``Erik |
sure, gimme a
few to back out a change |
| 18:46.39 |
``Erik |
the,
uh, |
| 18:48.22 |
``Erik |
heh, I blew
up my BRL-CAD |
| 18:49.39 |
brlcad |
starseeker:
similarly, do you have access to a copy of what you brought to the
ccb that you could send my way? |
| 19:02.33 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-189.dclient.hispeed.ch) |
| 19:54.18 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 20:21.08 |
brlcad |
starseeker:
never mind, I pulled images from elsewhere |
| 20:22.22 |
``Erik |
is half interested in how his images will be used if'n
there's time to show the slides off |
| 20:23.01 |
brlcad |
used two of
them |
| 20:23.53 |
``Erik |
assumes the t62 and the depth render went
away? |
| 20:25.05 |
brlcad |
good
guess |
| 20:25.59 |
``Erik |
but but but
the old tank had the dropdown menu showing the modes, and the depth
render looks, y'know, all futuristic! :D |
| 20:28.40 |
brlcad |
only have a
15 min total, there are already two min slotted to adrt .. if I put
more, it'll lose effect |
| 20:28.47 |
``Erik |
ok |
| 20:28.50 |
brlcad |
two is
pushing it, really needs to be one, but I think I can talk to
it |
| 20:28.54 |
brlcad |
as
two |
| 20:29.10 |
``Erik |
lemme know if
you need info |
| 20:31.35 |
brlcad |
k |
| 20:31.45 |
brlcad |
going with
data from last quarter |
| 20:33.17 |
``Erik |
hm, almost
everything has been internal, though my current activity is to make
it can run in 'local' mode (just run a binary and go, single
process with 2 threads) |
| 21:34.22 |
CIA-40 |
BRL-CAD:
03bob1961 * r33896 10/brlcad/trunk/include/ged.h: Added a
declaration for ged_build_tops. |
| 21:35.19 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r33895
10/brlcad/trunk/src/adrt/libtienet/load_MySQL.c: temporarily
disable the converter ... |
| 21:37.23 |
CIA-40 |
BRL-CAD:
03bob1961 * r33897
10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added
nmg_fix_normals.c to libged's windows build. |
| 21:37.41 |
CIA-40 |
BRL-CAD:
03bob1961 * r33898 10/brlcad/trunk/src/other/tcl/generic/tclInt.h:
Move include for common.h after Tcl includes. This gets rid of
warnings about redefining O_BINARY and O_TEMPORARY. |
| 21:58.13 |
*** join/#brlcad user___
(n=chatzill@170.Red-88-26-76.staticIP.rima-tde.net) |
| 22:04.23 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F6F1.dip.t-dialin.net) |
| 22:04.42 |
brlcad |
hm, distcheck
is still busted |
| 22:11.00 |
*** join/#brlcad BigAToo
(n=BigAToo@c-67-163-45-187.hsd1.in.comcast.net) |
| 22:33.38 |
brlcad |
good catch on
the ',' |
| 22:33.54 |
brlcad |
automated
cleanup went afoul |
| 22:34.03 |
``Erik |
make -s makes
it really easy |
| 22:34.46 |
``Erik |
there're
others I skipped, they looked less odd (like const char *argv[] ...
char *blah = argv[1]; ) |
| 22:35.09 |
``Erik |
my distcheck
breaks on not knowing how to aclocal heh |
| 22:39.14 |
brlcad |
I looked and
was mistaken on the export5 for bot's using
nmg_fix_normals |
| 22:39.57 |
``Erik |
yeh, *shrug*
I implemented what was discussed, I saw no easy way to do a
fix_normals on an arbitrary bot, I think ed was right |
| 22:40.21 |
``Erik |
I don't think
bot strongly enforces being a closed solid, it's just all our
conversions to bot happen to come from solids |
| 22:40.32 |
``Erik |
via nmg
topology testing |
| 22:41.00 |
``Erik |
at least from
something like facetize :) |
| 22:41.14 |
brlcad |
it's not
strongly enforced but it is enforced |
| 22:41.27 |
``Erik |
at the bot
level, or the nmg level? |
| 22:41.29 |
brlcad |
the bot
mode |
| 22:41.33 |
brlcad |
as a
bot |
| 22:41.37 |
``Erik |
ah,
hum |
| 22:41.39 |
brlcad |
RT_BOT_SURFACE |
| 22:41.47 |
brlcad |
RT_BOT_SOLID |
| 22:41.51 |
brlcad |
RT_BOT_PLATE,
etc |
| 22:41.55 |
``Erik |
aight |
| 22:42.14 |
``Erik |
I knew we had
plate, I was fairly certain we could have abitrary bots as well
(surface, I guess) |
| 22:42.15 |
brlcad |
if it's a
solid, it should convert directly to an nmg |
| 22:42.42 |
brlcad |
there is an
nmg-bot converter, could turn that into a routine and make a
bot-nmg routine |
| 22:42.53 |
brlcad |
then turn bot
into nmg, fix normals, then back to bot |
| 22:43.07 |
brlcad |
or make a
bot_fix_normals that just does the same algorithm on the bot
structure |
| 22:43.13 |
``Erik |
guess that
depends on the pro-e and iges converter shtuff, d-lo seemed to have
opinions as he just recently went through the pain and suffering
with that little pickup |
| 22:43.14 |
brlcad |
fairly simple
algo |
| 22:43.39 |
``Erik |
has to hammer out the adrt/isst stuff yesterday
:/ |
| 22:44.43 |
brlcad |
true
dat |
| 22:58.26 |
CIA-40 |
BRL-CAD:
03brlcad * r33899 10/brlcad/trunk/regress/mged.sh: |
| 22:58.26 |
CIA-40 |
BRL-CAD:
quell the false-positive ERROR lines about "Using Tcl library
at |
| 22:58.26 |
CIA-40 |
BRL-CAD:
/path/to/something" since it's just diagnostic output. that message
is only |
| 22:58.26 |
CIA-40 |
BRL-CAD:
printed in debug builds and is one of a variety of diagnostic
messages that |
| 22:58.26 |
CIA-40 |
BRL-CAD:
could get displayed. still, quell the one we know will be
shown. |
| 23:00.31 |
brlcad |
starseeker: I
think I found the problem |
| 23:00.39 |
brlcad |
and I think
it's new |
| 23:01.03 |
brlcad |
mged isn't
failing with that message, g_diff is |
| 23:01.45 |
starseeker |
is impressed |
| 23:01.50 |
starseeker |
and
groggy |
| 23:01.55 |
starseeker |
you got the
pics you need? |
| 23:04.37 |
brlcad |
yep |
| 23:08.48 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177680864.dsl.bell.ca) |
| 23:10.37 |
brlcad |
IriX64:
you're voiceless until you do something constructive,
sorry |
| 23:10.54 |
brlcad |
send me a PM
if you'd like to discuss it |
| 23:11.13 |
brlcad |
otherwise,
welcome to lurk and listen |
| 23:24.18 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 23:50.28 |
``Erik |
guess he
didn't like that |
| 23:55.12 |
brlcad |
he was
talking to me in private |
| 23:55.16 |
brlcad |
he's okay
with it |
| 23:56.05 |
``Erik |
but is he
going to wrap up, say, the version thing on mged? i'ts what, 4
lines of code, he was almost done, still no patch? :) |
| 23:56.31 |
``Erik |
or at least
start writing up docs, we have an awful lot that need to be written
at least in draft form |
| 23:59.42 |
brlcad |
probably not,
he'd need a lot more hand-holding and someone telling him exactly
what to do next |
| 00:19.32 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 00:22.50 |
CIA-40 |
BRL-CAD:
03starseeker * r33910 10/brlcad/trunk/src/proc-db/coil.c: OK, can
specify different ending types for the coil now - getting
close |
| 00:31.35 |
CIA-40 |
BRL-CAD:
03starseeker * r33911 10/brlcad/trunk/src/proc-db/coil.c: OK,
probably not all the cleanup needed for freeing things in coil but
its a start |
| 01:51.45 |
PrezKennedy |
woo one more
driving class to go |
| 02:22.52 |
*** join/#brlcad madant
(n=madant@117.196.135.9) |
| 02:32.56 |
``Erik |
w00t, then
it's off to the slave mines to afford a car, insurance, gas, etc
:D |
| 02:48.59 |
``Erik |
huh, did
malcolm mcdowell just call tony blair the queen of
england? |
| 02:55.45 |
``Erik |
http://www.motivatedphotos.com/?id=2627&d=1 |
| 03:03.10 |
madant |
:O http://www.motivatedphotos.com/?id=3759 |
| 04:29.49 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 04:30.49 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 04:30.49 |
*** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 04:30.49 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 04:38.04 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 05:02.13 |
*** join/#brlcad jonored_
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 05:26.21 |
*** join/#brlcad madant (n=madant@117.196.135.9) [NETSPLIT
VICTIM] |
| 05:26.21 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 05:37.31 |
brlcad |
howdy
madant |
| 05:37.55 |
brlcad |
``Erik: hehe,
nice |
| 05:38.26 |
brlcad |
fortunately I
had mad skills long before I got the car |
| 05:41.02 |
madant |
hi
sean |
| 05:41.21 |
brlcad |
madant:
please tell me you're still a student.. :) |
| 05:41.31 |
madant |
had that
interview i was talking about a couple of days back :) |
| 05:41.41 |
brlcad |
oh yeah,
how'd it go? |
| 05:42.04 |
madant |
march is
going to be my most productive month hopefully :) interview was
fine.. just usual funny talk.. no serious stuff.. |
| 05:42.15 |
madant |
hopefully i
am a student still ;) |
| 05:43.07 |
madant |
the results
come out in a couple of weeks.. fingers crossed |
| 05:44.05 |
madant |
when is the
org application deadline ? march 20th ? |
| 05:44.58 |
brlcad |
something
like that |
| 05:45.01 |
brlcad |
~gsoctimeline |
| 05:45.01 |
ibot |
gsoctimeline
is, like,
http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_ |
| 05:45.05 |
madant |
oh
13th.. |
| 05:45.42 |
brlcad |
four whole
days.. :) |
| 05:45.42 |
madant |
a reduction
in the number of orgs and students is expectable right
.. |
| 05:46.24 |
madant |
yeah
seriously .. student application period is 10 days thankfully
.. |
| 05:47.26 |
madant |
april 20th to
august mid seems ok for coding |
| 05:47.27 |
brlcad |
the student
application period would be extended a lot more readily than the
org one |
| 05:47.48 |
brlcad |
the org one
has never been extended iirc, the student one has several
times |
| 05:48.47 |
madant |
yeah but i
wonder whether larger number of applications is exactly what google
is looking forward to this time.. |
| 05:49.06 |
brlcad |
well last
year, the timing was horrible and applications were *way*
down |
| 05:49.42 |
brlcad |
as the first
week corresponded with easter, which pretty much resulted in nearly
no applications from US and much of Europe |
| 05:50.01 |
madant |
anyways imho
almost all open source organizations applied last year right
? |
| 05:50.02 |
brlcad |
which is
great for the non-US crowd, but overall submissions were down like
50% :) |
| 05:50.22 |
brlcad |
yeah, there
was like 500 or 600 orgs that applies last year |
| 05:50.28 |
brlcad |
with about
135 accepted |
| 05:50.54 |
madant |
but steadily
over the years more and more students are getting to know about the
existence of GSoC |
| 05:51.43 |
madant |
in my first
year of gsoc there was only me from my univ .. then next year there
were 3 selected , and last year 7 or so .. and maybe 100
applications ;) |
| 05:52.10 |
brlcad |
ah, 175
orgs |
| 05:52.12 |
madant |
are we making
a poster ? |
| 05:52.21 |
madant |
175 orgs last
year :O ? |
| 05:52.39 |
brlcad |
1125 students
last year |
| 05:52.46 |
brlcad |
it'll be
about 1000 students this year |
| 05:53.11 |
madant |
that's still
decent :) |
| 05:53.19 |
madant |
hopefully the
dropout rate will be lower |
| 05:53.40 |
brlcad |
unlikely |
| 05:53.51 |
brlcad |
that's been
pretty constant every year |
| 05:53.57 |
brlcad |
about 80%
pass |
| 05:54.14 |
brlcad |
80/82/80/83
for the four years |
| 05:54.16 |
madant |
statistical
certainty :P |
| 05:54.50 |
brlcad |
probably
about about 20% should be failed that are passed |
| 05:55.40 |
brlcad |
topic
discussed at the summit, giving bad students many many attempts to
succeed |
| 05:56.27 |
madant |
yeah i
remember a lot of discussion on the same even in the student
group.. basically some mentors were really pissed off i think
.. |
| 05:57.25 |
madant |
and besides
the existence of only two checkposts is also a
constraint |
| 05:57.59 |
brlcad |
madant: so
you know, we may take a slot less this year if we're accepted ..
but iff we are accepted, making more progress on any of last year's
projects will be high priority |
| 05:59.07 |
madant |
hmm.. hows
mafm doing ? would he need help in gui ? i mean slot for another
student ? |
| 05:59.09 |
brlcad |
there's only
two google checkpoints, orgs are allowed to do more (technically
our checkpoints were weekly) |
| 05:59.24 |
brlcad |
I don't think
mafm is a student any longer iirc |
| 05:59.32 |
madant |
oh.. |
| 05:59.56 |
brlcad |
otherwise,
yeah, the gui needs to be continued |
| 06:00.40 |
PrezKennedy |
gotta make it
simple for us windoze folk ;) |
| 06:00.51 |
brlcad |
I think I'd
like only three students so more time can be spent working with the
various projects |
| 06:01.09 |
brlcad |
PrezKennedy:
all in good time |
| 06:01.13 |
madant |
is the ogre
installation complicated in windoze ? |
| 06:01.32 |
brlcad |
not
really |
| 06:01.38 |
brlcad |
it's the main
platform iirc |
| 06:01.46 |
brlcad |
or at least
one of them |
| 06:01.57 |
madant |
but not
really 'just simply works' level either right ;) ? |
| 06:02.12 |
brlcad |
not much on
windows just simply works |
| 06:02.41 |
brlcad |
not really
worried too horribly about build system issues |
| 06:03.07 |
madant |
oh.. so major
work is interfacing with libged etc. ? |
| 06:03.28 |
madant |
i mean adding
functionality to gui ? |
| 06:03.42 |
brlcad |
interfacing
with either libged or new geometry service, but moreso adding
functionality to the gui |
| 06:04.15 |
brlcad |
he never did
get to many of the usability issues, and the basic pervasive
command framework |
| 06:04.24 |
brlcad |
context |
| 06:04.29 |
brlcad |
er, context
windows |
| 06:05.03 |
brlcad |
i.e. actually
make it *look* and feel like the ioe prototype |
| 06:05.11 |
madant |
ha |
| 06:05.18 |
brlcad |
lot of
work |
| 06:05.33 |
madant |
yeah.. i have
always felt gui IS A LOT of work. |
| 06:05.56 |
brlcad |
that's why it
was really one of the main goals of the project |
| 06:06.14 |
madant |
all the more
reason it should be done once and (approximately) for all properly
:) |
| 06:06.30 |
brlcad |
mafm wanted
to work more on the 3D interaction aspects and libged integration,
though, which was also good/needed |
| 06:07.17 |
brlcad |
but
particularly for a new gui, I think it'll get a lot more momentum
if it looks good, clean, and modular right from the start even if
the backend functionality isn't there yet |
| 06:07.35 |
brlcad |
coding
complete |
| 06:07.38 |
brlcad |
deep not
wide |
| 06:08.32 |
madant |
hmm.. modular
is always good |
| 06:08.37 |
madant |
hmm.. i will
wrap up this mathvm in a couple of days.. a good way to start
march.. i have been dragging it along too much.. need to
concentrate on actual parametrics and constraints.. |
| 06:08.56 |
madant |
*too
long |
| 06:10.00 |
brlcad |
you know,
another project came up a couple weeks ago that I was wishing I had
that library for :) |
| 06:10.22 |
madant |
what was it
? |
| 06:10.29 |
brlcad |
at least we
were discussing various metrics of the real world modelers that use
brl-cad for modeling various assets |
| 06:10.45 |
brlcad |
and the topic
of where the time is spent when modeling |
| 06:11.08 |
brlcad |
(for the guys
that spend literally 8hr/day every day of the week most days of the
year) |
| 06:12.30 |
brlcad |
of the time
spent modeling, how much time is "new work" vs "rework" .. and
particularly for the rework, there is an general feeling that the
rework rate is 1) high and 2) closely correllates with the number
of interfaces |
| 06:12.45 |
madant |
which is
really the weirdest part.. i mean with the obvious gain of
(significant) reduction in modeling time and changes ( particularly
since most designs go through a lot of iterations) i find it really
surprising that not only do open-source solutions exist.. not even
a fully functional commercial solution exists |
| 06:13.22 |
brlcad |
i.e. that a
lot of time is spent moving things around that relate to each
other, but since there are no parametric values or contraints to
tie objects together, that a lot of time is spent manually fixing
the cascade changes that occur when something needs to be
moved/changed |
| 06:13.37 |
madant |
*er i meant
not only do open-source solutions not exist :) |
| 06:13.45 |
brlcad |
nods |
| 06:14.24 |
brlcad |
there are
often commercial solutions, they're just closed source proprietary
and you don't know that's what they're doing under the
hood |
| 06:14.45 |
brlcad |
like one of
the things we're working on now -- raytracing trimmed
nurbs |
| 06:15.06 |
madant |
scratches his head |
| 06:15.09 |
brlcad |
there are a
few papers on a couple techniques, but it's exceptionally hard to
implement it and have it actually be robust |
| 06:15.31 |
brlcad |
yet many CAD
packages do provide it .. just nobody publishes how they
accomplished it |
| 06:15.47 |
madant |
ah that
sucks.. |
| 06:16.49 |
brlcad |
a great paper
that come out just last year actually did publish how they did it,
but then they patented the process :) |
| 06:17.39 |
madant |
ok.. that i
can still live with |
| 06:17.41 |
madant |
:) |
| 06:18.13 |
brlcad |
software
patents, at least in the US, are very actively
protected |
| 06:18.36 |
brlcad |
particularly
for the major industries (which CAD is) |
| 06:19.00 |
madant |
oh i didn't
mean copying it.. :P |
| 06:19.23 |
brlcad |
yeah, it's
better than nothing |
| 06:19.29 |
brlcad |
might inspire
a new approach |
| 06:19.35 |
madant |
exactly |
| 06:19.50 |
madant |
i really
don't understand the concept of not publishing a nice
idea |
| 06:20.08 |
madant |
let alone a
nice implementation |
| 06:31.39 |
jonored_ |
That's odd...
on ellipsoids and cylinders I seem to be able to slice properly
with the order I expect curvatures to be in, but for a torus, it
seems to be switched... |
| 06:34.05 |
brlcad |
switched? |
| 06:35.57 |
jonored_ |
As in I get
the result I expect if I swap crv_c2 and crv_c1 for a torus, but
not otherwise. |
| 06:36.28 |
jonored_ |
crv_pdir
should always be the direction tht crv_c1 is associated with,
right? |
| 07:15.19 |
brlcad |
jonored_: eh,
wth are you talking about? :) |
| 07:19.42 |
brlcad |
there's the
torus radius and then the radius of the tube itself, plus a
position and vector to place/orient it |
| 07:20.06 |
brlcad |
says he'll pick up this talk later, must
wander |
| 08:26.00 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:49.46 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:54.08 |
*** join/#brlcad madant
(n=madant@117.196.135.9) |
| 10:44.18 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:26.00 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:29.01 |
d-lo |
mornin
all |
| 11:33.17 |
alex_joni |
g'morning |
| 11:54.08 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 12:04.52 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:50.53 |
*** join/#brlcad madant
(n=madant@117.196.140.170) |
| 13:08.27 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14CABE.dip.t-dialin.net) |
| 13:43.36 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 13:47.51 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 13:57.34 |
*** join/#brlcad madant
(n=madant@117.196.140.170) |
| 14:02.24 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 14:02.24 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 14:35.13 |
*** join/#brlcad ``Erik_
(n=erik@ftp.brlcad.org) |
| 14:37.12 |
*** join/#brlcad _sushi__
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 14:43.55 |
*** join/#brlcad _sushi___
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 15:14.04 |
``Erik_ |
all my
connection are belong to comcast :( |
| 15:19.31 |
d-lo |
suckage... |
| 15:19.46 |
d-lo |
well, you can
always haxor da gibson! |
| 15:21.19 |
``Erik_ |
rather haxor
a fender O:-) |
| 15:23.49 |
starseeker |
tries compiling SCL on his box and winces - looks like Code
Modernization will have to take place here, to say nothing of build
system work |
| 15:24.03 |
starseeker |
alright, time
to play in traffic |
| 15:24.24 |
d-lo |
So, I think
FATE might be falling apart. Without SD there (and the fact that
few listen to any one else) it might be the begining of the
end! |
| 15:25.47 |
``Erik_ |
heh,
nifty |
| 15:26.02 |
``Erik_ |
fng seems to
have survived a handoff pretty well |
| 15:27.04 |
d-lo |
there were a
couple of 'angry' posts about FNG guys pillaging FATE traderoutes,
and a few "beat them like redheaded step children'
jokes |
| 15:27.21 |
d-lo |
followed by a
few piping up saying "Fate did that to me when i was in FNG, so
stick it." |
| 15:27.27 |
``Erik_ |
new people
who were buggywhipped when found out |
| 15:27.33 |
d-lo |
quite funny
akshuly |
| 15:27.58 |
``Erik_ |
a bunch of
newbs in 86 got pulled in, and after they got smacked, there was a
lot of whining when fate was pillaging and even attacking
fng |
| 15:28.42 |
``Erik_ |
*shrug* I've
barely put any attention to that game lately, and even less to wow
:) too much code to do |
| 15:29.29 |
d-lo |
feck, besides
my best efforts... gotta race condition to track down
:/ |
| 15:33.07 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:07.36 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 16:10.07 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 16:10.07 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 16:14.53 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 16:54.59 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 17:03.16 |
jonored_ |
brlcad: I
don't think that rt_tor_curve works quite right, unless I am
misunderstanding things. Unless I am mistaken, it assumes that the
smaller curvature is always associated with the major radius, and
then computes a direction for that curvature that is pointing
around the cross-section of the torus... but that block of stuff in
the conditional I don't quite understand. |
| 17:17.34 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:17.34 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 18:07.42 |
brlcad |
jonored_:
what are you up to? |
| 18:12.16 |
jonored_ |
brlcad:
making toolpaths which use arcs when the curvature in the plane of
the path is nonzero. |
| 18:13.20 |
brlcad |
hm |
| 18:13.39 |
brlcad |
well
something that may be of assistance, you can visualize the
curvature computations |
| 18:14.14 |
brlcad |
there's a
render lighting mode specifically for it |
| 18:15.28 |
brlcad |
rt -l 4 and
rt -l 5 |
| 18:15.58 |
jonored_ |
I just
finally got my head (and a computer algebra system) around the math
to get what that the curvature of an arbitrary intersection should
be. Oh, I'll take a look at that. |
| 18:15.59 |
CIA-40 |
BRL-CAD:
03starseeker * r33912 10/brlcad/trunk/src/proc-db/coil.c: Start
working out a way to support specifying multiple sections of coil
with different properties. |
| 18:16.16 |
jonored_ |
Does one draw
with one curvature and the other with the other one? |
| 18:18.44 |
jonored_ |
looks up the model. |
| 18:18.48 |
brlcad |
same
curvature, different visualizations |
| 18:19.01 |
brlcad |
one is the
inverse radius of curvature |
| 18:19.17 |
brlcad |
the other
shows the direction |
| 18:19.32 |
brlcad |
so magnitude
or dir visualization |
| 18:20.31 |
brlcad |
can see the
actual logic in src/rt/view.c, look for RT_CURVATURE |
| 18:24.57 |
brlcad |
to be honest,
I've not looked at the torus' curvature code in years and it'd take
a while to digest what is going on there exactly |
| 18:32.25 |
jonored_ |
Okay. How
likely is it that it might be almost all right but not quite? I'm
pretty sure that at least it's not keeping the first curvature
smaller than the second. |
| 18:32.41 |
*** join/#brlcad smurfette
(n=user@c-69-242-189-29.hsd1.mo.comcast.net) |
| 18:33.28 |
jonored_ |
(or is that
expected behavior?) |
| 18:43.46 |
brlcad |
that's
certainly possible, we find bugs in even some of the oldest parts
of the code from time to time |
| 18:43.55 |
brlcad |
kinda really
rare, but possible |
| 18:49.15 |
jonored_ |
Okay. I'll
keep staring at it until I understand what's going on in the last
bit that I haven't understood, and if I'm still convinced it's not
right, I'll send a patch. |
| 18:53.24 |
brlcad |
sounds
great |
| 18:55.18 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:59.03 |
CIA-40 |
BRL-CAD:
03starseeker * r33913 10/brlcad/trunk/src/proc-db/coil.c: More
progress to getting multiple sections working in coil |
| 19:31.10 |
CIA-40 |
BRL-CAD:
03bob1961 * r33914 10/brlcad/trunk/src/ (archer/archer.bat
mged/mged.bat util/rtwizard.bat): Update CAD_VERSION. |
| 19:34.58 |
CIA-40 |
BRL-CAD:
03starseeker * r33915 10/brlcad/trunk/src/proc-db/coil.c: Section
processing is (sort of) working - looks like the pipe primitive
doesn't like sections with anything different except pitch
though. |
| 19:41.28 |
starseeker |
expects helix angle and pitch to at least work - sort that
out after lunch... |
| 21:07.23 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 22:42.41 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178015677.dsl.bell.ca) |
| 23:11.16 |
CIA-40 |
BRL-CAD:
03starseeker * r33916 10/brlcad/trunk/src/proc-db/coil.c: Clean up
capping of 'default' endings - now nt=1 produces one turn of a
regular coil by default. |
| 23:14.29 |
*** join/#brlcad bitminer
(n=bitminer@h96-60-81-27.vrnawi.dsl.dynamic.tds.net) |
| 23:34.51 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:46.07 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-71.sbndin.btas.verizon.net) |
| 23:46.30 |
CIA-40 |
BRL-CAD:
03starseeker * r33917 10/brlcad/trunk/doc/docbook/system/man1/en/
(Makefile.am coil.xml): Add man page for coil tool |
| 23:46.41 |
brlcad |
uh oh, time
to move it :) |
| 23:49.04 |
CIA-40 |
BRL-CAD:
03brlcad * r33918 10/brlcad/trunk/TODO: two more items identified
yesterday, top -u isn't working or the docs are out of sync and
there is a view message if you try to change the view before
displaying geometry. |
| 23:49.22 |
starseeker |
brlcad: on
it :-) |
| 23:49.23 |
CIA-40 |
BRL-CAD:
03starseeker * r33919 10/brlcad/trunk/src/ (4 files in 2 dirs):
Move coil into shapes |
| 23:51.17 |
starseeker |
that took
more trouble that I would have guessed, but at least it's in there
now |
| 23:52.02 |
brlcad |
fg |
| 23:52.16 |
starseeker |
can now generate the necessary shapes to do the remaining
screens for the article |
| 23:52.19 |
starseeker |
fg? |
| 23:52.29 |
brlcad |
pics or it
doesn't exist! |
| 23:52.40 |
starseeker |
ok... |
| 23:52.41 |
brlcad |
~ww |
| 23:52.42 |
ibot |
Can I get a
woot woot? |
| 23:52.54 |
starseeker |
goes for wonky... |
| 23:58.41 |
starseeker |
http://bzflag.bz/~starseeker/coil_fun.png |
| 23:59.30 |
``Erik |
dude, you
broke your slinky |
| 23:59.39 |
brlcad |
neat |
| 23:59.46 |
brlcad |
can model my
mattress |
| 00:14.00 |
brlcad |
PrezKennedy:
what happened to osgaming.net? |
| 00:14.18 |
brlcad |
if you need a
new home, could use one of my servers |
| 00:15.38 |
PrezKennedy |
if i recall,
the moved the data somewhere else and i just never bothered to
setup the site again |
| 00:15.52 |
PrezKennedy |
i really
should since it was by far the most successful thing ive worked on
online |
| 00:16.15 |
PrezKennedy |
brlcad, did
you ever come up with a name for the second server? |
| 00:22.49 |
brlcad |
nope |
| 01:31.36 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 01:31.36 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 02:34.22 |
Ralith |
osgaming.net? |
| 02:34.25 |
Ralith |
that sounds
interesting |
| 02:45.26 |
Axman6 |
read that as orgasming.net |
| 03:43.45 |
yukonbob |
evening,
cadheads :) |
| 03:44.27 |
yukonbob |
?is there a
brlcad entry for gsoc2009? |
| 05:44.08 |
PrezKennedy |
haha nice one
Axman6 |
| 05:44.30 |
Axman6 |
heh, i love
#brl-cad lag XD |
| 06:49.15 |
brlcad |
yukonbob: not
yet, applications haven't opened yet |
| 06:49.42 |
yukonbob |
hey
brlcad |
| 06:49.47 |
brlcad |
hey |
| 06:50.10 |
yukonbob |
thought they closed in start of March (but I haven't been
following closely :P) |
| 06:50.26 |
yukonbob |
brlcad: is
there an "idea sheet" for BRLCAD
submission-possibilities? |
| 06:51.55 |
yukonbob |
brlcad: also,
see my note earlier re: itcl/tcl8.6? Full intergration of itcl w/
8.6 release! |
| 06:52.09 |
yukonbob |
(dunno if you
already knew; I just found out yesterday) |
| 06:58.44 |
brlcad |
yukonbob:
http://brlcad.org/~sean/ideas.html
is always a good staring point |
| 06:59.07 |
brlcad |
the best
ideas come from the students directly often |
| 06:59.08 |
yukonbob |
also sees applications == Mar 9-13 |
| 06:59.28 |
brlcad |
yes |
| 06:59.42 |
yukonbob |
brlcad: Are
there plans for participation this year, plans to not participate,
or simply no plans (yet)? |
| 06:59.59 |
brlcad |
the 2008 list
is still relevant if we participate |
| 07:01.10 |
brlcad |
still not
time to decide but probably applying at least, just maybe fewer
slots |
| 07:01.21 |
brlcad |
not that it's
relevant to the program |
| 07:03.08 |
yukonbob |
right
s/participate/apply/ |
| 09:32.51 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-236-47.dclient.hispeed.ch) |
| 10:03.49 |
alex_joni |
brlcad: I
notice you have Adobe 3D PDF exporte on the list |
| 10:04.13 |
alex_joni |
basicly the
things in the 3D PDF are U3D's (which are further down the
list) |
| 10:05.13 |
alex_joni |
I managed to
create U3D's with meshlab, and embed them into a pdf from latex +
Movie15 package |
| 10:06.18 |
alex_joni |
the
conversion Meshlab does is using the sample IDTF converter provided
with the sample U3D library (http://sourceforge.net/projects/u3d) |
| 10:11.49 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 10:11.49 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 10:57.19 |
*** join/#brlcad elite01
(n=omg@cl-213.dus-01.de.sixxs.net) |
| 14:23.54 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DC61.dip.t-dialin.net) |
| 14:29.39 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 14:29.39 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 15:08.02 |
brlcad |
alex_joni:
*nod* |
| 15:08.08 |
brlcad |
sounds like
two birds with one stone :) |
| 15:14.29 |
brlcad |
from our
toolchain perspective, there are a lot of integration issues that
would have to be sorted out |
| 15:28.35 |
brlcad |
having a
g-u3d and/or a g-pdf exporter, a u3d-g importer .. the g-pdf in
particular would be tricky given the current 'path' involves
latex+movie15 and how that could be achieved
programmatically |
| 16:30.24 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 16:45.35 |
brlcad |
hi
samrose |
| 16:46.24 |
samrose |
hey
brlcad |
| 16:47.08 |
samrose |
opensourceecology is interested in
learning brlcad. ultimately, interested in extending it and making
easy to use |
| 16:47.27 |
samrose |
any
suggestions for learning brlcad? |
| 16:47.42 |
samrose |
some of the
non-programmers are finding it extremely tough |
| 16:52.12 |
*** join/#brlcad bitminer
(n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) |
| 16:52.24 |
samrose |
we are going
to also document our learning |
| 16:52.25 |
samrose |
as we
go |
| 16:52.29 |
samrose |
on
brlcad |
| 17:13.37 |
brlcad |
samrose:
*nod* |
| 17:13.57 |
brlcad |
one of our
biggest (specific) long-term goals is making brl-cad a lot easier
to use |
| 17:14.07 |
samrose |
maybe I'll
also make some screencasts |
| 17:15.14 |
brlcad |
there are
lots of ways folks can help make brl-cad easier to use |
| 17:15.24 |
samrose |
I am trying
to convince http://openfarmtech.org/index.php?title=Main_Page
(open source ecology) that despite difficulty, that learning
brl-cad will be worth the investment. I am creating a foundation in
march, and interested in investing in developing
brl-cad |
| 17:15.26 |
brlcad |
there is a
massive documentation project under way that you could help out
with |
| 17:15.48 |
brlcad |
that sounds
fantastic |
| 17:15.57 |
samrose |
we will see
if we can figure out a way to combine that with existing
workflows |
| 17:16.09 |
samrose |
where id
documentation project happening at? |
| 17:16.18 |
brlcad |
here |
| 17:16.36 |
samrose |
this one
http://brlcad.org/ |
| 17:16.37 |
samrose |
? |
| 17:16.38 |
brlcad |
starseeker is
the lead on that effort, there are various tasks and pieces
involved |
| 17:16.49 |
samrose |
here on IRC
channel too, eh? |
| 17:17.43 |
samrose |
also, many
emerging fablab projects could participate, if we could find a way
to help them do so while they are working on what they are working
on |
| 17:17.48 |
brlcad |
samrose:
yeah, that's our main website -- the documentation I refer to is
organizing and presenting existing docs better, converting docs to
a revision-controllable format, and making them easier to work with
in our tools and via the website |
| 17:18.01 |
samrose |
ah,
ok |
| 17:18.43 |
samrose |
getting all
of this stuff from pdf to wiki pages or into revision control, eh?
http://brlcad.org/wiki/Documentation |
| 17:18.45 |
brlcad |
most of our
discussions happen here on the channel or via our brlcad-devel
mailing list |
| 17:18.53 |
brlcad |
yes |
| 17:18.55 |
brlcad |
and
more |
| 17:19.01 |
brlcad |
there's a lot
more documentation than that |
| 17:19.08 |
brlcad |
but that's
more than enough to start with |
| 17:19.08 |
samrose |
huh |
| 17:19.54 |
brlcad |
the first
steps are converting the docs to docbook format (an xml-based
markup format for technical docs), then generating the output
formats we need (web, pdf, doc, html, etc) |
| 17:20.19 |
samrose |
seems like a
programming task, if you ask me. writing some scripts that can get
data from x and put it into y with as many changes/conversions
needed done during the process as possible |
| 17:20.37 |
samrose |
I am familari
with docbook |
| 17:20.43 |
samrose |
familiar that
is :) |
| 17:20.47 |
brlcad |
:) |
| 17:20.58 |
brlcad |
yeah, that
part of it is more a programming task |
| 17:21.11 |
brlcad |
though the
input docs are in a wide variety of formats and
quantities |
| 17:21.52 |
samrose |
what kind of
revision control are you going to put them into, if I may
ask? |
| 17:21.55 |
brlcad |
hundreds of
pages in msword-only, pdf-only, html, latex, and manual page come
to mind |
| 17:22.05 |
brlcad |
our svn
repo |
| 17:22.17 |
samrose |
ok |
| 17:22.37 |
brlcad |
much of it
already is there and done |
| 17:22.48 |
samrose |
even though
there are pages in msword, pdf, etc, there are some tools out there
that can help with this |
| 17:22.48 |
brlcad |
it's been a
project under way for quite a while |
| 17:23.01 |
brlcad |
yeah, and
they tend to do a horrific job :) |
| 17:23.06 |
samrose |
hehe |
| 17:23.11 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 17:23.36 |
samrose |
well, where
do you need help these days? |
| 17:23.44 |
brlcad |
in any
regard, that's the work -- using tools, some manual, some
automated, some scripting, etc -- hundreds of pages of
docs |
| 17:24.12 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:24.12 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 17:24.12 |
brlcad |
there's also
a variety of docs that still need to be
written/rewritten |
| 17:24.27 |
samrose |
you should
put those in your wiki, maybe? |
| 17:24.35 |
brlcad |
oh,
absolutely |
| 17:24.39 |
samrose |
then again,
what do I know... |
| 17:25.00 |
samrose |
but, I think
media wiki export to docbook will be easy for you |
| 17:25.22 |
brlcad |
one of the
things I'm trying to get working is complete bidirectional editing
of the docs through the website (ideally through the wiki) and to
revision control docbook on the backend |
| 17:26.22 |
brlcad |
unfortunately, wiki markup by itself isn't
sufficient for all except the most basic layout needs |
| 17:26.28 |
samrose |
so, that the
wiki will export saved revisions as docbook to repo,
eh? |
| 17:26.54 |
brlcad |
yeah, that'd
be the goal, so really anyone could edit a document either via
checkout or via the website |
| 17:27.21 |
brlcad |
and not have
manual sync'ing, or manual export/import/merge steps |
| 17:27.28 |
samrose |
hmmm... this
is related to another project that I was working on, where we were
trying to find ways to push wiki pages into print quality pages
(ConTexT in that case) |
| 17:27.48 |
brlcad |
hopefully
avoiding unidirectional editing |
| 17:28.15 |
samrose |
so, you could
check an edit in to revision control, or edit a wiki page,
basically |
| 17:30.14 |
brlcad |
basically |
| 17:30.41 |
brlcad |
first step
was thinking to make either a drupal or mediawiki plugin that could
simply display the docbook for a given page/document that would
correspond to a given file |
| 17:31.00 |
samrose |
mediawiki
plugin would probably work |
| 17:31.19 |
samrose |
you could
write php that would sync with svn |
| 17:31.27 |
samrose |
and back the
other way |
| 17:32.12 |
brlcad |
and when an
edit was made, it'd go through a validation step, and get committed
or scheduled for commit |
| 17:32.15 |
samrose |
but, you were
saying that MW markup is missing formatting you need for
docbook |
| 17:32.41 |
brlcad |
right, that's
why it'd just display the docbook straight up as a first
step |
| 17:32.55 |
samrose |
it could
actually run a command line command, if everything you needed
existed as commands that could be run from shell :) |
| 17:33.06 |
brlcad |
e.g. have one
section/page that has the editable docbook, and another (read-only)
that would be the rendered result |
| 17:33.25 |
samrose |
like a
"release" page |
| 17:33.40 |
samrose |
so, you might
use branches in svn to track that |
| 17:33.44 |
samrose |
or
tags |
| 17:33.47 |
brlcad |
so
hourly/nightly/manually/automatically/whatever, it would update
from svn sources and rerender as needed |
| 17:33.58 |
brlcad |
yeah,
something like that |
| 17:34.14 |
samrose |
the docbook
idea is cool, because you could build a book as needed from
pages |
| 17:34.24 |
brlcad |
yeah, that's
part of the goal |
| 17:34.29 |
brlcad |
we have
several books as is |
| 17:35.21 |
samrose |
I am working
on something similar with decentalized revision control right now
as package management for digital design. I know it won't work for
you, but I could also |
| 17:35.32 |
samrose |
think about
ways to sync with documentation |
| 17:35.52 |
louipc |
this sounds
pretty awesome |
| 17:36.11 |
samrose |
so, we would
pull brl-cad book, and could push changes in ways that you need, so
that you can review and commit |
| 17:36.44 |
samrose |
this is built
in mercurial, python, bugseverywhere, exelearning, possibly more (a
small wiki engine called hatta wiki) |
| 17:36.57 |
samrose |
everything
syncs with mercurial repo |
| 17:36.58 |
brlcad |
samrose:
distributed vs centralized revision control wouldn't/shouldn't
really affect this -- most of the work is in how to display on the
site, how it's integrated as a plugin, etc |
| 17:37.30 |
samrose |
yeah, so
anyone could edit, and there could be a plugin that would send you
edits as commits in a form that you can use |
| 17:37.49 |
brlcad |
ideally, one
could make a much more complex mediawiki plugin that uses docbook
as the entire format, renders the page using docbook as an
alternate wiki markup |
| 17:38.10 |
brlcad |
along with
commit hooks on changes, of course |
| 17:38.43 |
samrose |
well, i think
there is already a docbook conversion for MW |
| 17:38.52 |
brlcad |
export
only |
| 17:38.54 |
brlcad |
one-way |
| 17:38.57 |
samrose |
ah |
| 17:39.28 |
brlcad |
and if I put
docbook into an edit page, it certainly won't render it
;) |
| 17:39.56 |
brlcad |
barely deals
with the html it supports |
| 17:40.00 |
MinuteElectron |
is docbook
latex? |
| 17:40.19 |
brlcad |
MinuteElectron: no, docbook is an xml or
sgml-based markup |
| 17:40.31 |
samrose |
I am thinking
that in addition to what you suggest above, that if there is a
specification for what you are looking for in commits/edits, that
this could also be built into other systems |
| 17:40.35 |
MinuteElectron |
ok |
| 17:40.50 |
brlcad |
one of the
toolchains effectively converts docbook into a latex format and
uses latex tools to render it (for pdf, rtf, etc) |
| 17:42.54 |
samrose |
http://wiki.blender.org/index.php/Meta:Guides/Wiki_conversions/DocBook_to_Wiki |
| 17:43.00 |
samrose |
perl! |
| 17:43.02 |
samrose |
hahaha |
| 17:43.06 |
brlcad |
samrose:
yeah, it really should be generalizable to any project and most
revision-control backends |
| 17:44.00 |
samrose |
so, basically
you can say: "this is what we need from you in the form of edit
commits" I think you are saying it needs to be docbook |
| 17:44.06 |
brlcad |
yeah, I've
seen what they did -- sort of a similar idea, but I think that's a
flop on execution |
| 17:44.23 |
samrose |
heh, that was
just a quick google search |
| 17:44.28 |
brlcad |
it shouldn't
just dumb down docbook to mediawiki markup if you want
bidirectional |
| 17:44.37 |
samrose |
I
see |
| 17:46.17 |
brlcad |
requiring
editors to understand basic docbook is a reasonable first-step
compromise |
| 17:46.32 |
brlcad |
even our
non-technically inclined editors have been able to use
it |
| 17:46.40 |
samrose |
yeah. or it
may be worth making a really good conversion system |
| 17:46.53 |
samrose |
well, that is
true |
| 17:47.11 |
brlcad |
just requires
a simple tutorial, existing examples |
| 17:47.29 |
brlcad |
not really
any more complicated than wikitext markup, just more
verbose |
| 17:47.35 |
brlcad |
and more
expressive/formalized |
| 17:47.42 |
samrose |
yeah, I think
most could handle it |
| 17:48.06 |
brlcad |
there's even
a wiki based on docbook, but I think mediawiki does a much better
job really |
| 17:48.57 |
samrose |
yeah. hmmm...
I wonder how quickly the DTD of docbook could be programmatically
mapped. |
| 17:49.18 |
samrose |
(just
thinking out loud) |
| 17:50.39 |
samrose |
like this
python script could work, it just needs to be more complete:
http://wiki.blender.org/index.php/Meta:Guides/Wiki_conversions/DocBook_to_Wiki |
| 17:53.09 |
samrose |
I am just
thinking about how to get people who are already doing flex fab
projects to 1. use brlcad 2. be able to quickly jump into
documentation as they go |
| 17:53.46 |
samrose |
I think we
can do it over the next year or so |
| 17:53.53 |
brlcad |
what are the
needs? |
| 17:53.58 |
samrose |
over time,
get more people doing 1, and 2 |
| 17:54.00 |
brlcad |
what do you
need a CAD system to do? |
| 17:54.41 |
samrose |
people need
solid geo modeling to document designs, so that others can
collaborate on designs with them |
| 17:54.44 |
samrose |
for one
thing |
| 17:55.07 |
brlcad |
to document
the design in what manner? |
| 17:55.24 |
samrose |
geometric
dimensions |
| 17:55.59 |
samrose |
many designs
that are intended to be executed by cnc machinery |
| 17:56.39 |
samrose |
perhaps CAD
is not needed in every case, but there is clearly a
demand |
| 17:56.52 |
brlcad |
the latter is
closer to doable now than the prior with where things currently
stand |
| 17:57.22 |
samrose |
you mean with
brlcad in general? |
| 17:57.33 |
brlcad |
there's a lot
of work that has to go into our toolset before we can have
automatic dimensioning for things like generating drawings and
other drafting docs |
| 17:57.39 |
brlcad |
yeah, in
general |
| 17:58.00 |
samrose |
Well,
automatic dimensioning is actually not a requisite |
| 17:58.14 |
samrose |
just *some*
usuable 3D FLOSS CAD software |
| 17:58.16 |
samrose |
:) |
| 17:58.25 |
samrose |
and, the
knowledge of how to use it |
| 17:58.26 |
bitminer |
Is meida wiki
being used currently? If so where is the search bar? Online wiki
editor for Doc Book http://code.google.com/p/owed/ |
| 17:58.41 |
samrose |
OSE uses
media wiki |
| 17:58.47 |
brlcad |
well we're by
far the best and most developed 3d f/oss cad software
:) |
| 17:58.59 |
samrose |
yeah, that is
the conclusion I came to |
| 17:59.18 |
brlcad |
bitminer:
interesting, i've not seen that project |
| 17:59.31 |
bitminer |
Just using
some google foo |
| 17:59.57 |
brlcad |
samrose: our
biggest failing atm is gui usability -- the learning curve on mged
(our main editor) is very steep |
| 18:00.13 |
bitminer |
Sorry to
return to doc book in this conversation, but thought you could use
the info |
| 18:00.43 |
brlcad |
"This project
is abandoned" |
| 18:01.04 |
samrose |
could be
worth doing an autopsy on, though |
| 18:01.17 |
samrose |
mged was the
objection that lots of people raised to me |
| 18:01.24 |
samrose |
so I am
trying to convince them to learn it |
| 18:01.57 |
samrose |
but, then, I
am also thinking about how users could drive evolution at the same
time. |
| 18:02.32 |
bitminer |
I have needed
(docbook) wiki in the past, never obatained it though. Likey a
project in and of itself. |
| 18:02.42 |
samrose |
I think I
could get funds to hel towards gui interface design, but I want to
work both with brlcad and people in the field |
| 18:02.44 |
brlcad |
bitminer:
more I read it, looks like they never finished and it's not a
mediawiki plugin but a new wiki? |
| 18:03.06 |
bitminer |
As for using
mged and UI. Yes it is steep, but so too was learning
Unigraphics. |
| 18:03.19 |
bitminer |
With all the
gui bells and whistles |
| 18:03.30 |
samrose |
anyway, I
think I can convince people to use mged now |
| 18:04.06 |
samrose |
I did not
realize that your existing documents are in svn so that alone
really helps |
| 18:04.35 |
bitminer |
I though I
saw doc book in trunk? Yes ... checking... |
| 18:05.01 |
samrose |
thanks brlcad
bitminer. I'll talk to you later |
| 18:05.42 |
brlcad |
samrose: if
it's any consolation, the expert brl-cad modelers are usually more
efficient in mged than they are in other commercial cad
systems |
| 18:05.51 |
brlcad |
it just took
a while for them to get to that level of proficiency |
| 18:06.36 |
brlcad |
bitminer:
yes, doc/docbook has most of the docs that have already been
converted |
| 18:06.56 |
bitminer |
What I
thought from snooping arround. Just getting started
though. |
| 18:07.16 |
brlcad |
there are
still hundreds of 'pages' of docs, and hundreds of files, that
still have to be converted |
| 18:07.48 |
brlcad |
e.g., there
are more than 400 tools in brl-cad -- there is a manual page for
nearly all of them that needs to be converted |
| 18:07.57 |
brlcad |
fortunately,
that's a good one for automatic conversion |
| 18:08.05 |
bitminer |
I know that
doing this progrmatically, being programmers is encticing, but how
hard would it be to do it ... mmm... huh... manually. |
| 18:08.39 |
brlcad |
similarly,
though, there are 300+ different mged commands which is all over
the place |
| 18:09.00 |
brlcad |
bitminer: a
lot of it is being done manually |
| 18:09.08 |
brlcad |
it's just
really tedious too :) |
| 18:09.30 |
bitminer |
So what would
be target for auto convert and what would need to be done
manualy? |
| 18:11.25 |
brlcad |
bitminer:
target is having docbook files instead of troff manpage format
files :) |
| 18:14.01 |
brlcad |
the html docs
and msword docs tend to require a lot more manual
effort |
| 19:12.20 |
yukonbob |
morning,
cadheads |
| 19:28.34 |
*** join/#brlcad PrezKennedy
(n=Matthew@whitecalf.net) |
| 20:28.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-39.sbndin.btas.verizon.net) |
| 20:30.28 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 21:06.16 |
starseeker |
about
autoconverting docs - the existing man pages have been run through
an autoconversion process that produces "close" to correct output.
The MGED commands, which are the current focus due to their being
"user visible" in the MGED environment itself, typically do not
have man pages to start with. Those are being hand converted,
using the Volume II appendix as a starting point and a docbook
template into which the information is inserted |
| 21:06.58 |
starseeker |
However, just
getting the documentation into docbook is only the first step,
although probably the most tedious one |
| 21:07.51 |
starseeker |
virtually all
the documentation we have besides the chapters in the Volume II and
III books needs to be carefully checked to make sure they are still
current, correct and clear |
| 21:12.20 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-60.dclient.hispeed.ch) |
| 21:15.30 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 21:47.16 |
CIA-40 |
BRL-CAD:
03brlcad * r33923 10/brlcad/trunk/ (TODO src/mged/cmd.c): make sure
all of the view commands have the view to work with. this should
remove the 'A view does not exist' messages from the GED view
check. |
| 23:12.17 |
CIA-40 |
BRL-CAD:
03brlcad * r33924 10/brlcad/trunk/include/vmath.h: drop the signbit
on zeros during INTCLAMP so we don't print '-0'. achieve this via
simple (double)(long) cast. should be just a minor cosmetic
change. |
| 23:14.38 |
brlcad |
starseeker:
another thought came to mind about the tcl upgrade -- did you apply
bob's 2x command length patch? |
| 23:19.20 |
starseeker |
I believe I
did |
| 23:19.38 |
starseeker |
I think that
was one of two I had applied at the outset - it should say in the
commit message |
| 23:23.45 |
brlcad |
okay,
cool |
| 23:24.15 |
starseeker |
still hasn't had time to work on blt yet - the one naive
attempt to put latest cvs blt into the brlcad tree resulted in a
compile error |
| 23:24.31 |
brlcad |
they were
working on our patch reviewing it |
| 23:24.44 |
starseeker |
hmm. when
was that? |
| 23:24.51 |
brlcad |
couple days
ago |
| 23:24.58 |
starseeker |
ah, cool
:-) |
| 23:25.27 |
starseeker |
half agrees with Bob that we might want to revert Tcl/Tk
upgrade til after the release - Archer will at least work on some
platforms that way |
| 23:25.45 |
starseeker |
is probably the only one with the X/Tk
conflict |
| 23:27.18 |
CIA-40 |
BRL-CAD:
03brlcad * r33925 10/brlcad/trunk/autogen.sh: another tweak from
sebastian pipping, adds support for the old automake libtool macro,
AM_PROG_LIBTOOL. |
| 00:34.20 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 01:30.35 |
``Erik |
*readreadread* |
| 01:30.44 |
``Erik |
hm |
| 01:31.27 |
``Erik |
bah, nascar
is still on, I want my cartoons *pout* |
| 01:46.01 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 01:48.15 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-39.sbndin.btas.verizon.net) |
| 02:13.20 |
*** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
[NETSPLIT VICTIM] |
| 02:13.20 |
*** join/#brlcad PrezKennedy (n=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 02:13.20 |
*** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 02:36.16 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 02:36.16 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 04:06.54 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 06:08.29 |
starseeker |
brlcad: I
made a test manually of a coil coiling inward: http://bzflag.bz/~starseeker/coil_in_ex.png
what do you think? Is it a good enough approximation to be
worthwhile? |
| 08:57.02 |
archivist |
hmm cnc wire
bending |
| 09:03.52 |
brlcad |
starseeker:
I'd still probably say not really -- even that test looks oddly
shaped enough that I'd think it was a bug instead of an
approximated implementation detail |
| 09:05.17 |
brlcad |
maybe if you
could control how approximated it was at the expense of speed (like
100 or 1000 bends just to make one turn) |
| 09:05.35 |
brlcad |
but yeah, not
at the quarter-turn |
| 09:07.07 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 10:19.33 |
CIA-40 |
BRL-CAD:
03brlcad * r33926 10/brlcad/trunk/src/libged/draw.c: recogized typo
and fixd it |
| 10:23.46 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:37.39 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:24.16 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:50.39 |
d-lo |
Mornin
all! |
| 11:50.53 |
d-lo |
brlcad: Still
awake or just woke up? |
| 12:12.33 |
d-lo |
``Erik: Have
any essssspertize on decompliation / assembly ? |
| 12:19.18 |
*** join/#brlcad TC-Rucho
(n=tc-rucho@190.191.172.28) |
| 12:19.32 |
TC-Rucho |
hello |
| 12:30.51 |
brlcad |
d-lo: still
awake |
| 12:31.53 |
d-lo |
machine.... |
| 12:32.14 |
d-lo |
I take it you
rcurrent work location will be the work location for the day then ?
:)\ |
| 12:32.18 |
brlcad |
trying to fix
a stupid resize bug |
| 12:32.49 |
d-lo |
as in GUI
widget resize? |
| 12:33.06 |
brlcad |
it'd be
tricky to try and get out right now with the snow depth on top of
ice |
| 12:33.24 |
d-lo |
how much snow
you get so far? |
| 12:33.33 |
d-lo |
I got <1"
at home :/ |
| 12:33.43 |
d-lo |
they *said*
5-8" |
| 12:33.49 |
brlcad |
it iced
through most of the night and has been snowing few a few hours
since, maybe 4-6" total |
| 12:34.02 |
d-lo |
I got excited
and broke out the sleds :/ I think i cursed it. |
| 12:35.47 |
d-lo |
brlcad: do
you have any exp with disassembly/decompilation? |
| 12:54.09 |
brlcad |
sure |
| 12:54.53 |
brlcad |
rarely need
it these days, though .. usually just to check out what the
optimizer did |
| 12:58.09 |
d-lo |
I might have
to pick your brain when next I see you then. |
| 12:59.24 |
brlcad |
some
knowledge rot, best to just speak and hit me up with tools at my
fingertips, and a wider audience if need be |
| 13:00.39 |
d-lo |
Well i have a
binary in which I do not have the source for, but I know that it
uses a certain open sourced library |
| 13:01.07 |
d-lo |
I am trying
to find a specific function call so I can hook into it and
watch/log the data flow. |
| 13:01.13 |
d-lo |
(Personal
project btw) |
| 13:01.45 |
brlcad |
hook into
it.. |
| 13:01.58 |
brlcad |
java? |
| 13:02.18 |
d-lo |
hook's a bad
word to use.... um. place a 'watch point' for logging/viewing in a
console. |
| 13:02.42 |
d-lo |
No, not java.
I believe the original language was MSVC6.0 |
| 13:04.55 |
TC-Rucho |
is there a
way to hide/erase the objects that are used for boolean subtraction
when drawing a region? |
| 13:05.06 |
TC-Rucho |
all this
wireframing is driving me nuts |
| 13:05.14 |
brlcad |
hm, that's a
pretty hefty goal, even to just watch and log without narrowing
down and knowing a lot more about that code |
| 13:05.48 |
d-lo |
*sigh* i
know. |
| 13:06.00 |
brlcad |
TC-Rucho: I
believe you can change how the negatives are drawn that might
help |
| 13:06.28 |
brlcad |
"maybe", but
there is no way to turn them off outright without switching to a
different render mode |
| 13:06.52 |
TC-Rucho |
hmm |
| 13:07.00 |
d-lo |
I have
tracked down what exact lib its using, gotten the source for that
and have found (in the dissassembled asm) where the headers I want
are imported...but after that I am at a loss :/ |
| 13:07.09 |
d-lo |
Okay, I stop
the OffTopic banter for now ;) |
| 13:07.57 |
TC-Rucho |
brlcad: I
don't know where to start to change that right now |
| 13:08.03 |
TC-Rucho |
any more
obvious hint? |
| 13:08.13 |
brlcad |
TC-Rucho:
yeah, hold on |
| 13:08.36 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 13:08.36 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 13:16.21 |
brlcad |
TC-Rucho: hm,
i'm not finding the option either, only the one that changes all
linewidths |
| 13:16.27 |
brlcad |
TC-Rucho:
something else you can do though |
| 13:16.30 |
brlcad |
two things
actually |
| 13:16.53 |
brlcad |
one is to
utilize ray-tracing more -- it's there to help show the
evaluated/shaded result |
| 13:17.18 |
TC-Rucho |
I don't like
the mged GUI, I find it ugly, so I use the console
style |
| 13:17.32 |
brlcad |
with the
raytrace control panel open, it supposed to be simple enough to
render, turn off the framebuffer, turn on and render, repeat,
etc |
| 13:17.34 |
TC-Rucho |
I do raytrace
from time to time to see wtf is going on |
| 13:17.48 |
TC-Rucho |
yeah, already
doing that |
| 13:18.17 |
brlcad |
another thing
you can do, which will entirely depend on your objects |
| 13:18.26 |
brlcad |
is to display
them evaluated instead of unevaluated |
| 13:18.45 |
TC-Rucho |
that sounds
interesting, keep talking |
| 13:18.46 |
brlcad |
what are you
using now to display objects? |
| 13:19.02 |
brlcad |
draw?
e? |
| 13:19.06 |
TC-Rucho |
draw |
| 13:19.20 |
brlcad |
so instead of
draw, you could use either ev or E |
| 13:19.27 |
brlcad |
subtlely
different results |
| 13:19.50 |
brlcad |
it'll
evaluate the booleans in polygonal mode and show an evaluated
polygon |
| 13:20.05 |
brlcad |
some like it
more, sometimes too much, just depends on the model |
| 13:20.30 |
brlcad |
if the
geometry gets too complex, there are limitations to what can be
evaluated |
| 13:20.52 |
brlcad |
it'll give
you more wireframe instead of less, of course, but it might
help |
| 13:21.03 |
TC-Rucho |
yeah, I'm
working with spheres and it's getting really messy |
| 13:21.54 |
brlcad |
and if you
have an open-gl-enabled mged, there's yet a third thing you can try
that displays in shaded mode all the time |
| 13:22.10 |
TC-Rucho |
which would
be? |
| 13:23.41 |
brlcad |
it's an
experimental mode, so use at own caution, and only with ogl display
manager, but iirc, it is enabled by turning on z-buffering, turning
off lighting, run 'set shaded_mode 2' and redraw your
objects |
| 13:24.49 |
TC-Rucho |
already tried
that about an hour ago, and all it does is fill the object with a
plain color, no shades, so it's really not useful at all
imo |
| 13:25.15 |
TC-Rucho |
want to see a
screenshot? |
| 13:25.49 |
brlcad |
then it's not
enabled correctly |
| 13:26.10 |
TC-Rucho |
http://tc-rucho.homelinux.net/Scrots/crappy-shade.png |
| 13:26.13 |
TC-Rucho |
that's what I
get |
| 13:26.16 |
brlcad |
those first
two enable/disable steps are required |
| 13:26.23 |
TC-Rucho |
hmm, let's
see |
| 13:26.38 |
brlcad |
yeah, that's
just not enabled correctly |
| 13:27.16 |
TC-Rucho |
I'll try to
enable that with mged gui first, brb |
| 13:27.21 |
brlcad |
it's not
meant to be easy yet. you're using a dev hook at this point, so
it's all manual |
| 13:28.27 |
brlcad |
i might have
the toggling off on one of them too, easy enough to tell when it
works though |
| 13:29.35 |
TC-Rucho |
z-buffering
on |
| 13:29.37 |
brlcad |
the real fix
for that is in the pipeline, part of the bigger BREP support
effort |
| 13:29.41 |
TC-Rucho |
now the
light |
| 13:30.24 |
TC-Rucho |
lighting off
and yet the same thing when redrawing |
| 13:30.26 |
TC-Rucho |
=/ |
| 13:30.39 |
brlcad |
there's at
least four combinations there |
| 13:30.45 |
brlcad |
to
try |
| 13:30.48 |
TC-Rucho |
yeah |
| 13:30.52 |
TC-Rucho |
I'm on my
way |
| 13:31.04 |
brlcad |
i don't have
an ogl-enabled build at the moment |
| 13:31.34 |
TC-Rucho |
ok, this can
be really haired, but it's Zbuffer off, lighting on |
| 13:31.57 |
brlcad |
sounds about
right |
| 13:32.24 |
TC-Rucho |
ok, got to
get it working in the console based mged |
| 13:32.31 |
TC-Rucho |
I'll be back
in a minute |
| 13:32.52 |
brlcad |
what are you
working on? |
| 13:33.02 |
TC-Rucho |
oh, Z
clipping must be on too |
| 13:33.43 |
TC-Rucho |
I'm drawing
my webcam for the sake of learning how to use BRL CAD. I've had
some rough times trying to move objects (actually still haven't
figured out how to move regions in space) |
| 13:33.55 |
brlcad |
oed |
| 13:34.13 |
brlcad |
there's a
whole tutorial geared towards teaching that |
| 13:34.14 |
TC-Rucho |
I tried sed
and ted (which I found awesomely useful) |
| 13:34.35 |
brlcad |
sed is for
primitives |
| 13:34.43 |
brlcad |
oed is for
everything else |
| 13:34.51 |
TC-Rucho |
I
see |
| 13:34.55 |
brlcad |
object
edit |
| 13:35.15 |
brlcad |
oed /
my_region/path/to/primitive |
| 13:35.25 |
brlcad |
rot 50 0
0 |
| 13:35.28 |
brlcad |
accept |
| 13:50.24 |
TC-Rucho |
wouldn't that
commandline be for editing a single primitive instead of a whole
region? |
| 14:05.40 |
brlcad |
nope |
| 14:05.56 |
brlcad |
the primitive
is only required to set an explicit keypoint |
| 14:06.53 |
brlcad |
so it will
rotate about the primary vertex point of the given primitive
specified, but apply a matrix between the left-hand and right-hand
side for a given /arbitrary/path/to/objects |
| 14:08.12 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 14:08.13 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 14:23.03 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:45.06 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 14:55.50 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:03.20 |
TC-Rucho |
I was
wondering, does brlcad have at least a 1 step-only
undo? |
| 15:06.09 |
TC-Rucho |
guess
not |
| 15:06.12 |
TC-Rucho |
=/ |
| 15:06.27 |
TC-Rucho |
note to self:
always triple check before doing a killtree |
| 15:15.12 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:16.05 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 15:38.16 |
*** join/#brlcad madant
(n=madant@117.196.140.99) |
| 15:55.56 |
brlcad |
TC-Rucho:
it's a two-step undo, cp file.g backup.g, later cp backup.g file.g
to undo |
| 15:57.39 |
brlcad |
best practice
is to make backups of your .g file every N timeframes (e.g. daily)
so that at worst you've never lost more than N work (e.g. a day's
worth) |
| 15:58.52 |
brlcad |
that'll be
addressed with the new gui, but it's still simply not a high
priority since the geometry command layer is designed just like the
unix command line and is intentionally unforgiving |
| 15:59.29 |
brlcad |
you could
just as well create proc overrides that makes backups for you or
prompts for confirmation just like some folks do with
rm |
| 16:00.20 |
brlcad |
again, not
something being avoided, just not a priority until shaded displays
and the new command layer is in place |
| 16:27.45 |
``Erik |
d'lo: uh, a
little, mostly quite antiquated, though |
| 16:30.42 |
d-lo |
Hrm,
okay. |
| 16:30.53 |
d-lo |
Looks like I
am on my own :/ |
| 16:31.08 |
d-lo |
``Erik: You
braving the roads or calling today a wash? |
| 16:31.58 |
brlcad |
d-lo: it's
usually infinitely easier to snoop the wires |
| 16:32.36 |
brlcad |
if there's
any net communication, or port protocol i/o, or even file
i/o |
| 16:33.02 |
brlcad |
a lot easier
to meter that doesn't require dissassembly or trying to inject
man-in-the-middle code |
| 16:33.19 |
d-lo |
Well, thats
just the issue. ;) I need to see the data BEFORE it gets
encrypted. |
| 16:33.22 |
``Erik |
this is my
rdo |
| 16:33.41 |
``Erik |
which is
good, as they haven't plowed my neighborhood yet :) |
| 16:34.34 |
brlcad |
d-lo: ah,
then your best bet is probably to run the app through a debugger,
break it right before the data is encrypted, then step through the
assembly one instruction at a time watching how all the register
data changes |
| 16:34.50 |
brlcad |
very tedius,
but doable |
| 16:35.21 |
``Erik |
hm, I forget
if ndisasm attempts to generate labels or just uses
offsets |
| 16:36.15 |
brlcad |
yeah, there
are some intelligent tools that will rebuild from symbols and
labels if they are there |
| 16:36.44 |
brlcad |
another
toolset to learn though, debugger is simple low-level |
| 16:36.53 |
d-lo |
brlcad:
Right. Thats the approach I am trying to take. As a step before,
since I know its using openSSL, then I am trying to grab the
offsets for the functions to make my searching in pure asm
easier. |
| 16:37.04 |
``Erik |
so you're
picking that old project up again? heh |
| 16:37.10 |
d-lo |
yeah.
;) |
| 16:37.53 |
d-lo |
I am usin
IDA. Its doing a pretty good job thus far, but working on a 20MB
binary is kicking my laptop in the nuts :( |
| 16:38.03 |
``Erik |
there should
be something like a _call directive going on that should make it a
lot more readoable |
| 16:38.44 |
``Erik |
readable,
even |
| 16:39.13 |
``Erik |
there should
be a "wakethefuckuperik" directive that makes my sentences a lot
more readable :D |
| 16:42.19 |
brlcad |
yay,
finally! |
| 16:42.34 |
brlcad |
g'damn that
was more difficult than it should have been |
| 16:45.13 |
CIA-40 |
BRL-CAD:
03brlcad * r33927 10/brlcad/trunk/src/libged/draw.c: add support to
ignore a new '-R' option that implies draw should not resize the
view. since the actual resize logic is still in the front-end, we
just ignore it (and -A, -o) here. |
| 16:46.53 |
CIA-40 |
BRL-CAD:
03brlcad * r33928 10/brlcad/trunk/src/mged/chgview.c: add a -R
option to the edit_com() interface affecting e/draw/B so that they
don't resize/autoview the view if the -R option is
provided |
| 16:52.32 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E5DC.dip.t-dialin.net) |
| 16:53.29 |
TC-Rucho |
brlcad:
wouldn't it be more conveniente to have oed to work like this?: oed
/path/to/group-or-primitive-to-work-with
/path/to/reference-primitive <br/> What's the point in
telling oed where is it contained? (the rlh path). |
| 16:54.05 |
CIA-40 |
BRL-CAD:
03brlcad * r33929 10/brlcad/trunk/ (NEWS
src/mged/chgmodel.c): |
| 16:54.05 |
CIA-40 |
BRL-CAD: make
the 'make' command use the existing view size when creating new
objects by |
| 16:54.05 |
CIA-40 |
BRL-CAD:
utilizing the new -R option on the draw command. this is a change
to make's |
| 16:54.05 |
CIA-40 |
BRL-CAD:
behavior when there are no objects displayed since previously, it
would create |
| 16:54.05 |
CIA-40 |
BRL-CAD: an
object sized to the view, but then autoview to size the view out.
this would |
| 16:54.08 |
CIA-40 |
BRL-CAD:
result in unexpected view changes that would get compounded if the
user called |
| 16:54.10 |
CIA-40 |
BRL-CAD:
make/draw/kill repeatedly. |
| 16:54.37 |
brlcad |
TC-Rucho:
it'd be easier to just say "oed object" or "oed /path/to/object"
but that would imply automatic keypoints based on "something"
(perhaps the center of the bounding box for that
object) |
| 16:55.16 |
TC-Rucho |
brlcad: what
about just oed /path/to/group/and/reference-primitive |
| 16:55.32 |
brlcad |
then where
does it apply the matrix? |
| 16:55.43 |
TC-Rucho |
to the
greatest group mentioned in the path |
| 16:55.51 |
brlcad |
"greatest"? |
| 16:56.05 |
TC-Rucho |
parent? |
| 16:56.13 |
TC-Rucho |
for
example: |
| 16:56.17 |
brlcad |
if "path" is
the object you wanted to change, then that'd be no different than
oed / /path/to/group/and/reference-primitive |
| 16:56.37 |
brlcad |
so you saved
two keystrokes and introduced ambiguity :) |
| 16:56.45 |
brlcad |
there is just
one path |
| 16:57.10 |
brlcad |
the arguments
are the left-hand side of that one path, and the right-hand
side |
| 16:57.40 |
TC-Rucho |
if I want to
edit group I go with oed group/and/reference-primitive if I want
to edit path I go with oed /path/to/group/and/reference-primitive.
Is that ambiguous? |
| 16:57.45 |
brlcad |
every where
there is a slash, you can inject a transformation
matrix |
| 16:58.35 |
brlcad |
no, you're
still not understanding what it means to be a path I
think |
| 16:58.44 |
TC-Rucho |
maybe |
| 16:59.02 |
brlcad |
the tutorial
does a pretty good job with examples to explain it in detail,
fwiw |
| 16:59.12 |
brlcad |
including the
implications and rationale |
| 17:00.23 |
brlcad |
but even
using a filesystem path metaphor as an example, "oed
/path/to/group/and/primitive" could imply that you want to edit the
'path' object or the 'primitive' object in that path'ed
context |
| 17:00.58 |
brlcad |
the only
reason you specify a path at all is to obtain a keypoint -- you
still have to say what object in what context no matter
what |
| 17:01.32 |
brlcad |
e.g. to
qualify instance editing versus global editing |
| 17:01.39 |
TC-Rucho |
it took me a
while to get what was it all about since I was getting a shitty
error about "Unable to find solid matching path" (later figured out
it was because I did not draw one of the objects) |
| 17:02.15 |
TC-Rucho |
hmm, I'll
have to experiment about that |
| 17:02.22 |
brlcad |
yes, you have
to load the objects for editing (via draw/e/B) before you can oed,
sed works that way too |
| 17:02.46 |
brlcad |
'who' tells
you what objects are editable |
| 17:04.01 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:04.01 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 17:04.03 |
brlcad |
another
simple example, you have a room with a bed and a chair, constructed
with some primitives .. there's a "room", "chair", and "bed" object
as well as their primitives in the database |
| 17:04.15 |
TC-Rucho |
I don't yet
see the difference in doing oed /combination region/primitive
and oed / region/primitive |
| 17:04.40 |
brlcad |
"oed /
room/chair/leg/arb8" means "move the room" |
| 17:04.52 |
TC-Rucho |
aye |
| 17:05.07 |
brlcad |
"oed /room
chair/leg/arb" means "move just that one chair in that
room" |
| 17:05.25 |
brlcad |
"oed /
chair/leg/arb8" would mean "move all chairs" |
| 17:06.11 |
TC-Rucho |
really?, I
would have bet that "oed / chair/leg/arb" meant "move just that
one chair" |
| 17:06.34 |
brlcad |
they are
named references |
| 17:06.56 |
brlcad |
so if you use
'chair' as a name elsewhere and you move /chair, you move
everything |
| 17:07.41 |
brlcad |
depends how
your hierarchy is contstructed |
| 17:08.39 |
brlcad |
it's a basic
set of directed acyclic graphs where you can apply a matrix to any
node in the graph |
| 17:08.51 |
brlcad |
same concept
as for any other CAD system really |
| 17:09.52 |
brlcad |
main
difference is different terms, assemblies regions parts
combinations primitives groups |
| 17:10.28 |
TC-Rucho |
well, I've
used AutoCAD, totally different paradigm, and when I reached the
oed part, I was confused as hell, because I thought of it as a
referencing system like AutoCAD's move/copy/whatever where one
selects a group of objects, then a reference point, and an end
point |
| 17:10.54 |
TC-Rucho |
so I thought
of oed as oed /group/to/work/with
/path/to/reference-primitive |
| 17:10.58 |
``Erik |
ow |
| 17:11.09 |
``Erik |
got ~6-7" of snow, just finished shoveling |
| 17:11.11 |
brlcad |
main
difference with a system like autocad is that every object (well,
most objects) are automatically wrapped in a container object by
default |
| 17:11.34 |
brlcad |
so to change
all instances, it involves a more explicit action
usually |
| 17:12.17 |
brlcad |
TC-Rucho: oed
is like "oed /group/to/work/with /path/to/reference-primitive"
:) |
| 17:12.31 |
brlcad |
your words
and what those slashes mean are just not connecting |
| 17:12.56 |
brlcad |
means that
this is some valid path:
/group/to/work/with/path/to/reference-primitive |
| 17:13.21 |
brlcad |
and you want
to edit the 'path' object instance referenced in the 'with'
object |
| 17:13.37 |
brlcad |
using
'reference-primitive' as the keypoint |
| 17:14.32 |
brlcad |
(more
specifically, the 'reference-primitive' keypoint in the
'/group/to/work/with/path/to' context) |
| 17:15.46 |
brlcad |
it really is
one of those lightbulb issues that should suddenly go off
eventually and you'll wonder how you ever understood it
differently |
| 17:16.12 |
TC-Rucho |
right, but
still, I don't quite see the difference in doing oed /
/region/primitive and oed /group region/primitive |
| 17:16.31 |
TC-Rucho |
hmm |
| 17:16.49 |
TC-Rucho |
I tried both,
and they work the same way |
| 17:17.12 |
brlcad |
they'll give
the same end-result until you have 'region' used in multiple
places |
| 17:17.22 |
brlcad |
(not in
'group') |
| 17:18.44 |
TC-Rucho |
ok, I have
just modelled some basic stuff, now I'll complete the webcam model,
and maybe I'll get what you mean once the modell get's bigger and
more complex (although I think I would need to reuse some regions
in order to see what you mean) |
| 17:18.48 |
brlcad |
seriously,
oed tutorial |
| 17:18.51 |
brlcad |
it will
explain a lot |
| 17:19.12 |
TC-Rucho |
I've been
reading it for a long while now |
| 17:19.30 |
TC-Rucho |
it's just
that it puzzled me out since I had a preconcept about how it should
work |
| 17:21.22 |
brlcad |
hm, that
discussion gave me an idea for a terminology doc |
| 17:22.46 |
TC-Rucho |
yeah, that
left hand path and right hand path notation is not what I would
call "clear" but anyway |
| 17:24.24 |
brlcad |
having to
specify the path to a primitive for a keypoint is really the point
of confusion |
| 17:25.37 |
brlcad |
that's a
technical limitation by the fact that there is no keypoint and
deriving an implicit keypoint based on bounding box sizes is
questionable (someone will still probably do it
eventually) |
| 17:34.14 |
d-lo |
I say: Take
the average of the 8 points of the Boundingbox and make that
default keypoint for oed. |
| 17:37.21 |
TC-Rucho |
brlcad: I got
it now, the only way to understand the difference is to group some
regions, and implicitly reusing the regions by making copies of the
group |
| 17:37.29 |
TC-Rucho |
it is all
clear now |
| 17:40.41 |
``Erik |
hrmmm |
| 17:40.55 |
``Erik |
*snrkt* |
| 17:47.57 |
brlcad |
heh |
| 17:48.28 |
brlcad |
d-lo: that is
the idea, what I meant by "someone will still probably do it
eventually" |
| 17:49.10 |
brlcad |
the problem
then becomes unexpected behavior issues since that keypoint isn't
exactly easily worked with until a variety of other commands are
updated too |
| 17:49.21 |
CIA-40 |
BRL-CAD:
03brlcad * r33930 10/brlcad/trunk/doc/ (2 files in 2 dirs):
document the new -R option for e/draw/B in the old htmls docs and
for B in the new docbook docs |
| 17:49.45 |
brlcad |
rotate and
translate something around, add an object, reverse the rotation and
you find out it's not reversible |
| 17:50.39 |
d-lo |
Well thats
just operator error/dumbness. Code can't fix that ;) |
| 17:51.00 |
``Erik |
*nod* plus
the issue when you have something like a bigassed box with a tiny
little cylinder sticking way out and the keypoint is off in space
instead instead of where you think it 'should' be |
| 17:51.49 |
``Erik |
ponders allowing keypoints to be manually selected and saved
as attr's to be future default for that comb |
| 17:51.51 |
brlcad |
d-lo: right,
but usability and interface design can seriously make is a
non-issue vs a major/subtle cause for confusion and unexpected
behavior |
| 17:52.41 |
brlcad |
yeah, some
what to manage keypoints more as more than data values,
second-class citizens in the db sense would be good |
| 17:53.15 |
brlcad |
having things
like 'l' and analyze report the keypoints would help, visually
showing keypoints, etc |
| 17:53.26 |
``Erik |
ooh, here's a
good case to screw the 'center of bb' approach, imagine a cylinder
with one side slightly cupped (rcc - sph), that'd come out close to
the center of the sphere, not the physical object :) |
| 17:54.45 |
brlcad |
negatives are
the worst, the expected keypoint is usually the center of mass on
the positive evaluated space |
| 17:54.54 |
brlcad |
s/mass/volume/ |
| 17:55.39 |
``Erik |
and "wait
while we run rtweight to find the cm" is probably not tolerable
:D |
| 17:55.47 |
brlcad |
:) |
| 17:57.14 |
d-lo |
``Erik: that
might mess up a center of mass approach, but not for center of BB.
especially if the center of BB is being used for a simple default
keypoint for oed. |
| 17:57.15 |
``Erik |
out of
curiosity, when nurbs is working to satisfaction... will it be
'just another primitive', or are we going to push to be kinda a
nurbs only engine (mebbe with construction information stored to
allow old style editing)? |
| 17:58.20 |
``Erik |
um, bb is
computed in a way that it should be close to the union of all
primitives in the tree, even if there're subtractions,
iirc |
| 17:59.46 |
``Erik |
if this prims
minX < bb minX, bb minX = this prims minX; ... |
| 17:59.57 |
d-lo |
so a bounding
box is *not* maxX, minX, maxY, minY, max Z, min Z ? |
| 18:00.01 |
brlcad |
just another
primitive |
| 18:00.10 |
CIA-40 |
BRL-CAD:
03brlcad * r33931 10/brlcad/trunk/doc/docbook/system/man1/en/
(Makefile.am g_qa.xml gqa.xml): the mged command is gqa instead of
g_qa, rename accordingly |
| 18:00.15 |
brlcad |
with a bunch
of support to go from csg->nurbs on the fly |
| 18:00.44 |
brlcad |
so we can
still leverage the optimizations and guarantees if there are
implicits |
| 18:01.05 |
``Erik |
try it out,
dave, make a sub comb and do make_bb on it :) |
| 18:01.09 |
brlcad |
but make it
even easier to visualize and analyze anything via the
bridge |
| 18:02.18 |
``Erik |
aight, I was
under the impression that nurbs could represent any geometry we
currently have perfectly (within floating point fuzz), so *shrug*
was just wondering. it's my day off, my brain ain't fully in gear,
nor will it be |
| 18:03.01 |
brlcad |
does a final distcheck, suggests others that might care about
release compilation do so as well for their favored
environment |
| 18:04.01 |
brlcad |
``Erik: it
can for the most part .. it's just wildly more complex to store and
deal with than other primitives and about an order of magnitude
more data values to represent the same thing |
| 18:04.10 |
d-lo |
``Erik: Hrm,
just tried it and it performed as expected it to :/ |
| 18:04.26 |
brlcad |
sphere goes
from having about 6 values to over a hundred for a decent
approximation |
| 18:04.36 |
brlcad |
similar for
arb8's |
| 18:05.12 |
d-lo |
``Erik: ah, I
see what you mean now. |
| 18:05.21 |
brlcad |
instead of 24
values, suddenly becomes about 300 values |
| 18:22.36 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 18:23.10 |
``Erik |
thought nurbs could do a sphere in 2
patches |
| 18:23.34 |
``Erik |
or was it 4
(tetrahedron-like) |
| 18:24.27 |
``Erik |
d-lo: how you
expect things to work probably isn't how joe blow off the street
does :D you're tainted |
| 18:29.56 |
d-lo |
Well, I think
the number of tainted users > number of Joe Blow Off the Streets
;) |
| 18:47.26 |
*** join/#brlcad bitminer
(n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) |
| 18:47.33 |
``Erik |
in the tiny
self-selecting community you see here, sure, but there are what,
670,000 known downloads? I'm imagining a fairly large number of
those are unvoiced first time users :) |
| 18:54.37 |
d-lo |
won't mention his script
"DownloadMetricPadder.sh" |
| 18:54.43 |
d-lo |
:D |
| 18:55.55 |
d-lo |
but you are
right, there are prolly alot of first timers that end up shying
away :/ |
| 18:58.48 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 18:58.48 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 18:58.51 |
brlcad |
TC-Rucho: you
have a full tcl interp there so that can be used |
| 18:58.56 |
``Erik |
tcl
sub-expressions |
| 18:59.00 |
TC-Rucho |
I checked
some tcl's docs and according to them, [expr {2*2}] should be fine
to include in an input line |
| 18:59.02 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 18:59.08 |
brlcad |
yep |
| 18:59.11 |
TC-Rucho |
but it keeps
telling me error |
| 18:59.19 |
brlcad |
only caveat
is default globbing |
| 18:59.25 |
TC-Rucho |
mged> in
fuck.s rcc 0 0 0 [expr {2*2}] [expr {2*2*2}] 0 5 |
| 18:59.26 |
TC-Rucho |
Error: extra
characters after close-brace |
| 18:59.31 |
``Erik |
* will mess
up globbing |
| 19:00.03 |
brlcad |
we have a
globbing evaluation mode enabled by default so that things like
"draw *.r" will work |
| 19:00.34 |
brlcad |
which
includes character classes, draw [a-z]*.c |
| 19:00.48 |
brlcad |
so those
conflict with tcl evaluation |
| 19:00.54 |
TC-Rucho |
seems that I
should disable globbing to input stuff, but still, is there a more
elegant way? |
| 19:00.55 |
brlcad |
you can have
one or the other, default is globbing |
| 19:00.58 |
``Erik |
[expr {2\*2}]
works, or you can turn off globbing |
| 19:01.05 |
brlcad |
you can
toggle it off with: set glob_compat_mode 0 |
| 19:01.12 |
brlcad |
or you can
escape the globbing chars |
| 19:01.37 |
brlcad |
in fuck.s rcc
0 0 0 \[expr {2\*2}\] \[expr {2\*2\*\2}\] 0 5 |
| 19:02.11 |
TC-Rucho |
I think it
would be better to scape globbing rather than tcl
expressions |
| 19:02.26 |
TC-Rucho |
like draw
\*.r |
| 19:02.34 |
TC-Rucho |
and keep
[expr {2*2}] working |
| 19:02.37 |
``Erik |
odd choice of
primitive name O.o |
| 19:02.55 |
brlcad |
probably a
'part' primitive ;) |
| 19:03.12 |
brlcad |
ah, rcc,
guess it's an approximation |
| 19:03.28 |
``Erik |
people are
more apt to treat the geometry tree like a filesystem than an
expression engine *shrug* |
| 19:03.28 |
TC-Rucho |
``Erik: heh,
that's because this tcl expression thing was getting on my
nerves |
| 19:03.45 |
TC-Rucho |
lol |
| 19:03.58 |
TC-Rucho |
@brlcad | ah,
rcc, guess it's an approximation <--- lol xD |
| 19:04.06 |
brlcad |
TC-Rucho:
it's been oft-discussed, how to get the best of both worlds -- the
folks that want globbing would cry bloody murder, and they're the
expert modelers |
| 19:04.06 |
``Erik |
if you don't
use globbing, turn it off, set that to be default in your .mgedrc
*shrug* it's all good |
| 19:04.49 |
brlcad |
those that
know how to write tcl can easily just set the var and be done with
it |
| 19:05.50 |
TC-Rucho |
tcl == ugly
mix of C and... bash? anyway, we'll have lisp bindings eventually
and everything will be good |
| 19:07.03 |
``Erik |
I think tcl
is older than bash, but it does take cues from the bourne/korn
family |
| 19:08.13 |
``Erik |
(dang linux
weenies, all not knowin' the history of it all :) |
| 19:09.02 |
``Erik |
huh, bash
precedes tcl by a year, neat :) |
| 19:10.20 |
TC-Rucho |
(: |
| 19:18.32 |
brlcad |
TC-Rucho:
awesome -- native bindings? |
| 19:18.49 |
TC-Rucho |
brlcad:
hm? |
| 19:19.15 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:21.06 |
TC-Rucho |
brlcad: well,
my usability goal is to get a lisp repl for mged, so that one can
use lisp directly to input commands, math and scripting |
| 19:22.05 |
bitminer |
While were on
the topic of TCL... any one have difficulty building lib Bacon
Lettus and Tomato ... libBLT in windows. I am getting error :
error LNK2019: unresolved external symbol _TclInitSubsystems
referenced in function _TkConsoleCreate |
| 19:22.30 |
bitminer |
Need me a BLT
right now. |
| 19:22.43 |
TC-Rucho |
.. bacon,
lettus, tomato... that sounds like a salad |
| 19:22.53 |
louipc |
sandwich |
| 19:23.00 |
TC-Rucho |
right,
sandwitch |
| 19:23.03 |
bitminer |
It's more
like C soup |
| 19:24.01 |
brlcad |
TC-Rucho:
right, but binding to mged commands how? you can bind straight to
the lib, through the mged binary (ugh), through a custom interp,
etc |
| 19:24.30 |
brlcad |
would be
awesome to have a swig interface to libged so there'd be bindings
available in everything they support |
| 19:24.36 |
bitminer |
it is
externed via extern void TclInitSubsystems _ANSI_ARGS_((CONST char
*argv0)); in tkConsole.c |
| 19:24.59 |
bitminer |
wraped in
some suspicous #ifdefs |
| 19:25.14 |
brlcad |
bitminer: hm,
you're compiling using the msvc build files or
autotools? |
| 19:25.36 |
bitminer |
Was trying
autotools in Cygwin. I have had more luck in msvc |
| 19:25.41 |
bitminer |
so msvc for
now |
| 19:26.00 |
TC-Rucho |
brlcad: I
have not even started with that, what I've said is the 1st global
usability goal. I'm just giving my first steps modelling with
brlcad (you may have noticed already). Once I know it enough so as
to make improvements I'll grab the source and/or make the lisp repl
using bindings to libmged or whatever I see fits best |
| 19:26.16 |
brlcad |
the msvc8
files should be the most up-to-date and are what are used to make
releases |
| 19:26.36 |
bitminer |
I have done
some Swig in the past binding C# to C++ in linux allwoing Windforms
apps wirtten in windwos to be run in Linux on Mono |
| 19:26.51 |
brlcad |
the 9 files
shouldn't be far behind, the other dir relies on cmake but only
compiles the libs |
| 19:27.19 |
bitminer |
I have
noticed that the msvc files only support release |
| 19:27.32 |
brlcad |
that's a
bob-ism |
| 19:27.39 |
brlcad |
he got tired
of managing both |
| 19:27.45 |
bitminer |
This was one
of my first issues and MSVC defaults to debug on start up. I
emailed this to the mailing list |
| 19:28.12 |
bitminer |
bob-ism? |
| 19:28.24 |
brlcad |
bob, one of
the devs |
| 19:28.38 |
brlcad |
he does a
variety of quirky things :) |
| 19:28.40 |
bitminer |
Ok |
| 19:29.02 |
bitminer |
Are you using
CMake to generate the VS project files? |
| 19:29.04 |
brlcad |
doesn't talk
much, just likes to quietly code |
| 19:29.10 |
brlcad |
no |
| 19:29.14 |
brlcad |
though that
would be cool |
| 19:29.26 |
bitminer |
It is a
suposed rumored feature of CMake |
| 19:29.33 |
brlcad |
yes, it
is |
| 19:29.45 |
brlcad |
and it works
-- that's the other cmake-based build I mentioned that we
have |
| 19:29.52 |
brlcad |
it just
doesn't build everything |
| 19:30.28 |
brlcad |
our build
system is pretty big.. takes many weeks/months to set everything up
that we need with any build tool |
| 19:30.37 |
bitminer |
Ok so I could
possibly use Cygwin autotolls or CMake, Windows env Cmake, or
Windows env Visual Studio |
| 19:30.58 |
``Erik |
hrm, here's a
posting claiming that swig doesn't play with lisps (but does with
scheme and erlang) |
| 19:31.00 |
brlcad |
well yes and
no, more no than yes |
| 19:31.11 |
``Erik |
though
uffi/cffi around libged would be neat |
| 19:31.17 |
brlcad |
bitminer: you
can use autotools or the msvc8/msvc9 project files to get a full
build |
| 19:31.25 |
brlcad |
the cmake
build files will only build the libraries |
| 19:31.42 |
bitminer |
Ok got it
thanks |
| 19:31.43 |
brlcad |
we have like
two dozen libraries |
| 19:31.48 |
brlcad |
and over 400
binaries |
| 19:32.22 |
bitminer |
holy
cats |
| 19:32.28 |
brlcad |
mged is just
one of them :) |
| 19:32.46 |
brlcad |
granted, it's
the biggest by far |
| 19:33.03 |
d-lo |
heh, binary
envy. |
| 19:33.23 |
brlcad |
most of that
400 are unix-style commands that do one thing and are streamable so
you can tie them together for much more powerful
functionality |
| 19:34.01 |
brlcad |
ala cat | awk
| sed | grep, ours focus on geometry, images, and data file
processing |
| 19:34.22 |
bitminer |
How do they
communicate, MPI, sockets, carrier pigions? |
| 19:34.27 |
starseeker |
unix
pipes |
| 19:34.35 |
starseeker |
bites us when
working on Windows though |
| 19:34.40 |
brlcad |
pipes and
sockets |
| 19:34.54 |
bitminer |
got
it |
| 19:35.06 |
bitminer |
Look a boost
for IPC? |
| 19:35.27 |
brlcad |
the SGI_Cube
example on the wiki shows a couple commands being used for image
processing/conversion |
| 19:35.43 |
brlcad |
yeah, I've
looked at it before .. what about it? :) |
| 19:35.51 |
bitminer |
Inter Process
Communication (IPC) |
| 19:36.24 |
``Erik |
yeah, we know
what ipc is... :) |
| 19:36.33 |
bitminer |
Most of the
code looks to be C. What is your take on C++ in this project and
Boost C++ and 0x support |
| 19:37.11 |
``Erik |
the work in
rt^3 is using boost at the moment, and c++ is starting to creep
into the codebase :/ |
| 19:37.15 |
brlcad |
most of the
bigger project infrastructure for the new modeling interface is
being done in C++ (using boost and stl heavily) |
| 19:37.26 |
brlcad |
all the new
brep/nurbs work is c++ |
| 19:37.43 |
bitminer |
So it is an
option then? |
| 19:38.11 |
brlcad |
all of our
existing core libs are going to stay pure C (libbu, libbn, librt,
libwdb, etc) |
| 19:38.21 |
brlcad |
but new code,
it's an option |
| 19:38.37 |
bitminer |
OK. Will
Boost compile on all your platforms? |
| 19:39.10 |
brlcad |
it's just not
cool to be half-assed about it, using little tidbits of C++
throughout a code that is 95% plain C isn't cool |
| 19:39.16 |
brlcad |
just makes
for bad C++ and bad C |
| 19:39.34 |
brlcad |
yeah, most of
boost compile's fine -- at least no issues so far |
| 19:39.55 |
bitminer |
Yes I can
understand wanting to maintain consistency. |
| 19:39.56 |
``Erik |
yeah, if
someone commits c++ stuff in a .c file, I'll break their kneecaps
O.o I'll try to be gentle about kneecap breaking if it's
c99 |
| 19:39.58 |
``Erik |
:D |
| 19:40.07 |
brlcad |
the new
parametric constraint solving system that madant has been working
on is the closest to causing boost to snap, but it's been
fine |
| 19:43.52 |
brlcad |
ponders gsoc projects |
| 19:44.12 |
bitminer |
Yes I think I
read about this using Spirit? GSOC proj? for parametric
modeling |
| 19:44.18 |
brlcad |
yep |
| 19:45.06 |
bitminer |
Well I'll
keep banging on the Win32 build. |
| 19:45.07 |
brlcad |
``Erik:
irix64 said he has a patch for you to review on his site if you're
interested, dunno when he'll be back on |
| 19:45.30 |
louipc |
hehe he pms
me about the patches too |
| 19:45.36 |
``Erik |
ok |
| 19:45.38 |
brlcad |
bitminer:
send the error to the devel mailing list, To Bob or whomever
;) |
| 19:45.39 |
louipc |
but he
disappears before I can respond |
| 19:45.46 |
``Erik |
I'll keep an
eye out for him |
| 19:45.54 |
brlcad |
sounds like
it might be something new -- tcl was just upgraded |
| 19:46.11 |
brlcad |
might be
easier to install activestate's tcl and then just change the
linkage to use that instead of building |
| 19:46.18 |
bitminer |
Ok will do..
There were multiple. I fixed most just stuck on libBLT at the
moment. |
| 19:46.22 |
brlcad |
louipc:
really? jeez |
| 19:46.32 |
brlcad |
louipc: let
me know if it gets to be a problem |
| 19:46.41 |
louipc |
it's all
cool |
| 19:46.49 |
brlcad |
k |
| 19:47.20 |
brlcad |
starseeker:
the tcl folks liked your archer screenie |
| 19:47.33 |
``Erik |
he needs a
lot of steering and handholding, I'd hate to see his enthusiasm
crushed, though :) |
| 19:47.38 |
starseeker |
oh, the tire
wizard? :-) |
| 19:47.43 |
brlcad |
they
(jokingly) said the gui looked dated, referring to ttk
updates |
| 19:48.14 |
brlcad |
but that the
tire looked great ;) |
| 19:48.17 |
``Erik |
(does ttk
mean that aquatk is now a dead-end) |
| 19:48.20 |
starseeker |
would love to take a stab at using ttk |
| 19:48.27 |
brlcad |
``Erik:
hardly |
| 19:48.43 |
``Erik |
<-- has
managed to avoid that entire chunk for the most part |
| 19:49.16 |
``Erik |
I made a
button in wish once, otherwise I just imitate code already there
for my patches and hope I guessed right :) |
| 19:50.22 |
starseeker |
had to fight the busting of Archer with the lastest tcl/tk as
an excuse to take Archer apart and put it back together using ttk
widgets |
| 19:50.39 |
starseeker |
er, fight
using it as an excuse |
| 19:54.14 |
starseeker |
figures Archer is having enough trouble without me messing
with it like that ;-) |
| 19:56.51 |
starseeker |
brlcad: Are
you close to tagging for the release? |
| 20:04.22 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
| 20:11.19 |
``Erik |
reboots brlcad's new machine again |
| 20:11.32 |
starseeker |
``Erik: is
that the new bz server? |
| 20:11.51 |
``Erik |
yeah |
| 20:12.18 |
``Erik |
I'm being
aggressive about keeping it bleeding edge until everything is
migrated to it, so we have a good launch point |
| 20:12.26 |
``Erik |
bleeding
stable edge, that is |
| 20:12.35 |
starseeker |
ah |
| 20:12.51 |
starseeker |
should migrate his stuff to that one and free up some
space |
| 20:13.37 |
``Erik |
and it's back
up |
| 20:13.57 |
starseeker |
``Erik: At
some point can you show me how to get to that box? |
| 20:14.00 |
``Erik |
looks like it
has an 80 gig drive in it |
| 20:14.09 |
starseeker |
er, well
nevermind :-) |
| 20:14.25 |
starseeker |
will just suck it up and get a terabyte
drive |
| 20:14.33 |
``Erik |
hm, I don't
see you in the passwd file |
| 20:14.41 |
d-lo |
I thought it
was supposed to have >80 |
| 20:15.13 |
``Erik |
oh, wait,
120g |
| 20:15.41 |
``Erik |
that's odd,
there may be an unallocated partition |
| 20:18.35 |
``Erik |
aah, reading
it wrong, 80g for home |
| 20:18.49 |
``Erik |
refers back to where he stated his brain would not be
functioning today |
| 20:25.43 |
starseeker |
was dbbinary
the one that got renamed to bo? |
| 20:26.26 |
starseeker |
checks NEWS |
| 20:29.15 |
starseeker |
ah,
yes |
| 20:39.35 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 20:39.35 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 20:41.17 |
CIA-40 |
BRL-CAD:
03starseeker * r33932 10/brlcad/trunk/doc/docbook/system/man1/en/
(9 files): Add more MGED docbook man pages by Janine and
Cliff |
| 20:59.39 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 20:59.39 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 21:12.56 |
*** join/#brlcad cad33
(n=424ca4ee@bz.bzflag.bz) |
| 22:24.34 |
TC-Rucho |
hey guys, if
you like to do inline math just like me and hate that \[expr
{mathstuff}\] gay sh*t, you can type in => \[proc unknown args
{set ::that \[expr $args\]}\] so you can just do \[mathstuff\]
(: |
| 22:25.37 |
TC-Rucho |
this works by
setting the unknown handler to perform an [expr ...] to the screwed
up input (math without preceding expr) |
| 22:25.44 |
TC-Rucho |
hope you like
it |
| 22:26.35 |
TC-Rucho |
note: and
desabling globbing it get's even better |
| 22:28.02 |
TC-Rucho |
brlcad:
should I add this to the brlcad-wiki as a tip? |
| 22:28.30 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 22:34.41 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 22:40.51 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-39.sbndin.btas.verizon.net) |
| 23:03.58 |
*** join/#brlcad tc-rucho1
(n=tc-rucho@190.191.172.28) |
| 23:05.02 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 23:07.56 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38)
[NETSPLIT VICTIM] |
| 23:07.56 |
*** join/#brlcad bitminer
(n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad smurfette
(n=user@c-69-242-189-29.hsd1.mo.comcast.net) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 23:07.56 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 23:09.27 |
*** join/#brlcad elite01
(n=omg@cl-213.dus-01.de.sixxs.net) |
| 23:11.06 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177871980.dsl.bell.ca) |
| 23:27.23 |
*** mode/#brlcad [+o tofu] by ChanServ |
| 23:27.50 |
``Erik |
*yawn* |
| 23:28.21 |
``Erik |
bar
commercials on tv heh |
| 23:28.32 |
elite01 |
some movie on
vlc heh |
| 23:29.04 |
``Erik |
I was
laughing at the existance of, not just commenting on what I was
seeing :D vlc is good stuff, though |
| 23:32.57 |
*** join/#brlcad bitminer69er
(n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net) |
| 23:33.05 |
brlcad |
tc-rucho1:
hah, that's a really fantastic way to abuse tcl |
| 23:36.21 |
brlcad |
great
hack/tip |
| 23:57.18 |
``Erik |
\[mathstuff\]
makes me think LaTeX |
| 23:57.55 |
``Erik |
that'd be
awesome if tcl were kicked to understand tex math mode, one step
closer to literate programming :D |
| 23:58.35 |
``Erik |
(or generate
tex from the tcl) |
| 00:00.55 |
starseeker |
brlcad:
There we go - this is a combination of the cottbus.de improvements
and my own tweaks: http://bzflag.bz/~starseeker/scl-3.2.tar.gz |
| 00:03.34 |
starseeker |
I don't know
about the make being triggered by configure, but presumably it can
be made to do what is needed for a subconfigure |
| 00:03.47 |
starseeker |
humbly chews on crow... |
| 00:05.47 |
``Erik |
chews on his salsbury steak |
| 00:05.50 |
``Erik |
I think mine
tastes better |
| 00:05.50 |
``Erik |
:D |
| 00:13.40 |
starseeker |
probably
:-) |
| 00:14.28 |
starseeker |
wonders if brlcad has tried crow meat on his far reaching
culinary adventures |
| 00:14.43 |
starseeker |
somebody must
have tried eating one at some point |
| 00:14.58 |
starseeker |
woot - builds
on linux successfully too |
| 00:34.16 |
louipc |
I had
pidgeon |
| 00:41.00 |
starseeker |
how was
it? |
| 00:41.06 |
``Erik |
DOVE
MURDERER! |
| 00:52.20 |
louipc |
oh it was
good, tasted like chicken |
| 00:53.05 |
louipc |
you can
probably find it in an authentic chinese restaurant. it might
depend on the time of year |
| 01:12.14 |
starseeker |
ah, there we
go |
| 01:12.37 |
starseeker |
./configure
and make now behave (by default anyway) as expected: http://bzflag.bz/~starseeker/scl-3.3.tar.gz |
| 01:16.42 |
starseeker |
makes note to figure out needed targets for install,
distclean, etc. and heads home |
| 01:17.17 |
``Erik |
looks at the clock and shakes his head |
| 01:17.48 |
starseeker |
was in one of his frustrated moods today and wanted to get
SOMETHING useful done |
| 01:19.08 |
``Erik |
productivity
is over-rated |
| 01:19.28 |
``Erik |
go home
before your wench selects other body parts for the pickle-jar, boy
:D |
| 01:19.38 |
starseeker |
winces and logs out |
| 03:21.51 |
starseeker |
grinds his teeth as the scl bundle that succeeded on OSX and
Linux fails immediately on his home box |
| 03:24.39 |
louipc |
just
building? |
| 03:33.41 |
starseeker |
yeah - the
lex scanner is throwing out c code with two statics in
it |
| 03:41.43 |
starseeker |
actually,
there are several steps to the final expscan.c |
| 03:48.51 |
``Erik |
is the
compilation host specific? |
| 03:50.08 |
``Erik |
if it's not,
I'd argue that it's acceptable to put the compiled .c file output
into the repo to avoid the yacc/lex chain |
| 04:07.31 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 04:30.37 |
starseeker |
``Erik: not
sure |
| 06:26.47 |
CIA-40 |
BRL-CAD:
03homovulgaris * r33951 10/brlcad/trunk/src/libpc/pcMathGrammar.h:
adding various operators to the expression grammar |
| 07:26.05 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-225-235.dclient.hispeed.ch) |
| 08:18.59 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:33.15 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 09:22.04 |
CIA-40 |
BRL-CAD:
03homovulgaris * r33952 10/brlcad/trunk/src/libpc/ (pcMathGrammar.h
pcMathLF.h pcMathVM.h): pcMath VariableGrammar completely defined
also taking into account closures |
| 09:52.48 |
brlcad |
woot |
| 10:49.20 |
*** join/#brlcad madant
(n=madant@117.196.149.246) |
| 12:42.09 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-241.sbndin.btas.verizon.net) |
| 12:44.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 13:08.35 |
*** join/#brlcad madant_
(n=madant@117.196.140.81) |
| 13:15.11 |
*** part/#brlcad madant_
(n=madant@117.196.140.81) |
| 13:15.18 |
*** join/#brlcad madant_
(n=madant@117.196.140.81) |
| 13:21.04 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:55.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-241.sbndin.btas.verizon.net) |
| 14:15.39 |
*** join/#brlcad madant_
(n=madant@117.196.130.236) |
| 14:21.12 |
CIA-40 |
BRL-CAD:
03brlcad * r33953 10/brlcad/trunk/NEWS: bob added centroids and
moments of intertia to the gqa command |
| 14:24.38 |
CIA-40 |
BRL-CAD:
03brlcad * r33954 10/brlcad/trunk/NEWS: bob fixed a handful of smp
bugs in gqa where there were critical sections that were not being
semaphore-protected. |
| 14:28.00 |
CIA-40 |
BRL-CAD:
03brlcad * r33955 10/brlcad/trunk/NEWS: bob make gqa handle reading
in density files better. now handles arbitrary blank lines and
comment lines. also fixed a bug where it was writing past the end
of an array. |
| 14:34.34 |
CIA-40 |
BRL-CAD:
03brlcad * r33956 10/brlcad/trunk/NEWS: |
| 14:34.34 |
CIA-40 |
BRL-CAD: bob
fixed doing a copy action on Windows, and doing a paste for any
platform. |
| 14:34.34 |
CIA-40 |
BRL-CAD:
previously, pasting would wipe out whatever was selected (which
would normally |
| 14:34.34 |
CIA-40 |
BRL-CAD: make
sense but not for read-only command console selections). this
addresses sf |
| 14:34.34 |
CIA-40 |
BRL-CAD: bug
2278235 reported by lbutler (Can't cut-and-paste under
Windows) |
| 14:38.50 |
CIA-40 |
BRL-CAD:
03brlcad * r33957 10/brlcad/trunk/NEWS: |
| 14:38.51 |
CIA-40 |
BRL-CAD: bob
fixed a bug in mged where the last character would end up getting
ignored. |
| 14:38.51 |
CIA-40 |
BRL-CAD: the
only key combination he found that produced that behavior was
a |
| 14:38.51 |
CIA-40 |
BRL-CAD:
control-key-slash binding. overriding the binding (to do nothing)
fixed the |
| 14:38.51 |
CIA-40 |
BRL-CAD:
issue for bob. no word yet from peter_gillissen that reported this
bug as sf |
| 14:38.53 |
CIA-40 |
BRL-CAD: bug
2555653 (Neglecting last character command-line). |
| 14:39.13 |
brlcad |
there, that
should do it |
| 14:44.22 |
CIA-40 |
BRL-CAD:
03brlcad * r33958 10/brlcad/trunk/ChangeLog: update the changelog
with changes since the last release, 2009-02-06. preparing for
release 7.14.4 |
| 14:48.18 |
CIA-40 |
BRL-CAD:
03brlcad * r33959 10/brlcad/trunk/ (NEWS include/conf/PATCH): bump
it! 2009-03-06 is release day for 7.14.4 |
| 15:04.28 |
CIA-40 |
BRL-CAD:
03bob1961 * r33960 10/brlcad/trunk/src/tclscripts/lib/Command.tcl:
This applies the same bug fixes that were applied to MGED (i.e. bug
#2555653 - the command line has an extra character at the end that
is not used and cannot be removed; bug #2278235 - can't cut-n-paste
under Windows) |
| 15:04.35 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 15:05.19 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 15:31.28 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 15:37.11 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 15:41.03 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 15:44.16 |
CIA-40 |
BRL-CAD:
03bob1961 * r33961 10/brlcad/trunk/src/tclscripts/ (lib/Command.tcl
mged/text.tcl): Disallow cut operation in command
windows. |
| 15:46.20 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 16:13.48 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 16:40.47 |
*** join/#brlcad Don__
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 16:44.23 |
*** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198)
[NETSPLIT VICTIM] |
| 16:46.00 |
*** join/#brlcad Don_
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 16:46.00 |
*** join/#brlcad ewilhelm
(n=ewilhelm@pool-71-111-78-159.ptldor.dsl-w.verizon.net) [NETSPLIT
VICTIM] |
| 16:47.53 |
*** join/#brlcad astrobear
(n=ib@unaffiliated/ibuffy) |
| 16:48.14 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 16:51.23 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:55.53 |
*** join/#brlcad astrobear
(n=ib@unaffiliated/ibuffy) |
| 17:23.21 |
*** join/#brlcad madant__
(n=madant@117.196.133.187) |
| 17:48.38 |
*** join/#brlcad astrobear
(n=ib@unaffiliated/ibuffy) |
| 17:51.47 |
CIA-40 |
BRL-CAD:
03bob1961 * r33962 10/brlcad/trunk/src/mged/setup.c: Fixed
typo. |
| 17:53.01 |
CIA-40 |
BRL-CAD:
03bob1961 * r33963 10/brlcad/trunk/src/mged/rtif.c: Modify f_nirt
and f_vnirt to strip _mged_ prefix before calling
libged. |
| 17:57.23 |
CIA-40 |
BRL-CAD:
03bob1961 * r33964 10/brlcad/trunk/src/ (mged/setup.c
tclscripts/mged/ray.tcl): This fixes the "Pick Edit-Primitive" mode
in MGED. |
| 18:05.00 |
*** join/#brlcad astrobear
(n=ib@unaffiliated/ibuffy) |
| 18:05.29 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-232-153.dclient.hispeed.ch) |
| 18:30.56 |
brlcad |
heh, bears in
space |
| 18:39.23 |
brlcad |
wow. trunk
passes distcheck but stable doesn't (from the last
release) |
| 18:39.36 |
brlcad |
sounds like
someone didn't follow through! :) |
| 18:39.52 |
starseeker |
uh
oh |
| 18:39.57 |
starseeker |
did I mess up
again? |
| 18:40.11 |
brlcad |
no
worries |
| 18:40.22 |
starseeker |
what was
busted?? |
| 18:40.24 |
brlcad |
does rtwizard
work for you? |
| 18:41.02 |
starseeker |
hmm - not
popping up a window here |
| 18:41.11 |
starseeker |
oh, there it
goes |
| 18:41.18 |
brlcad |
don't know
how extensive, just distcheck for the 7.14.2 stable merge didn't go
well (or released with a failing distcheck) .. bunch of
regress/mged files missing from the dist |
| 18:41.32 |
brlcad |
starseeker:
oh, that reminds me |
| 18:41.36 |
brlcad |
specific
feature request there |
| 18:41.48 |
brlcad |
should be a
really quick change |
| 18:41.52 |
starseeker |
sure |
| 18:42.34 |
starseeker |
blast it,
rtwizard is busted |
| 18:42.35 |
brlcad |
adding a
button to rtwizard that saves a shell script of what it would do
instead of running the steps |
| 18:42.53 |
starseeker |
"unrecognized
unit type - Unknown_unit |
| 18:43.04 |
brlcad |
rutroh |
| 18:43.28 |
brlcad |
archer not
working isn't a show-stopper but rtwizard is |
| 18:45.37 |
*** join/#brlcad ``Erik
(n=erik@ftp.brlcad.org) |
| 18:45.48 |
starseeker |
seeks the Wisdom of Bob |
| 18:46.08 |
starseeker |
It's an error
on db load... |
| 18:46.12 |
brlcad |
try first
:) |
| 19:35.54 |
CIA-40 |
BRL-CAD:
03brlcad * r33965 10/brlcad/trunk/HACKING: update the merge steps
to allow for a little more copy-pasting love next time. probably
could make this into a script using propsets to track the last
merged revision id. something to think about next
month. |
| 19:44.01 |
starseeker |
That's....
really weird |
| 19:45.35 |
brlcad |
hm, I just
ran into the "slow framebuffer" bug, hum. |
| 19:46.47 |
starseeker |
brlcad:
rtwizard does not appear to be busted after all, at least not in
the way I was thinking |
| 19:47.13 |
starseeker |
I was getting
Unknown_unit on failure, but I just checked the database and it is
an unknown unit |
| 19:47.21 |
starseeker |
very
strange |
| 19:47.31 |
starseeker |
with a
"normal" unit it is working fine |
| 19:47.39 |
brlcad |
okay,
good |
| 19:47.55 |
brlcad |
was about to
just comment that it seems to be working for me here |
| 19:48.00 |
brlcad |
just aweful
slow |
| 19:49.36 |
starseeker |
probably
shouldn't wipe out on Unknown_unit, but I don't suppose it's a
common sitution |
| 19:50.25 |
brlcad |
probably
not |
| 19:50.55 |
brlcad |
i'd say leave
it be unless you plan on writing a new wizard rendering
interface |
| 19:51.32 |
brlcad |
someone
should do that.. it'd probably end up being the most utilized tool
by the analysts |
| 19:53.33 |
CIA-40 |
BRL-CAD:
03brlcad * r33966 10/brlcad/trunk/NEWS: annotate the last-minute
injection by bob to fix Pick Edit-Primitive mouse interaction mode.
he fixed it so it works again. |
| 19:57.40 |
starseeker |
is still pissed at himself for somehow messing up on the last
release... |
| 19:57.46 |
starseeker |
somehow this
isn't my week |
| 19:57.49 |
brlcad |
aha, the
delay only happens with remote fbserv's |
| 19:58.13 |
starseeker |
so the
question is whether it's the network's fault or
fbserv's? |
| 19:58.18 |
brlcad |
starseeker:
heh, it was minor, forget about it |
| 19:58.21 |
brlcad |
oh, it's
fbserv's |
| 19:58.39 |
brlcad |
there's no
reason it can't shovel a 1024x1024 image in an instant |
| 19:58.45 |
starseeker |
hrm |
| 19:58.49 |
brlcad |
it's taking
15sec or so |
| 19:58.53 |
starseeker |
ow |
| 19:59.02 |
brlcad |
see if you
get it: |
| 19:59.04 |
starseeker |
sounds like a
job for Shark |
| 19:59.10 |
brlcad |
fbserv 1
/dev/X & |
| 19:59.14 |
brlcad |
oops |
| 19:59.19 |
brlcad |
fbserv -s1024
1 /dev/X & |
| 19:59.46 |
brlcad |
rt -F1 -s1024
db/moss.g all.g |
| 20:00.37 |
brlcad |
nasty |
| 20:00.52 |
starseeker |
yeah, it's
slower no question |
| 20:01.01 |
starseeker |
hauls out shark |
| 20:03.04 |
brlcad |
it's all I/O
waiting, you'll be hard pressed to find it with shark, but
maybe |
| 20:03.32 |
starseeker |
ah, so more
up dtrace's alley? |
| 20:04.04 |
brlcad |
actually,
old-school gprof might help since it has a wallclock counter
iirc |
| 20:04.43 |
brlcad |
you need
something that checks wallclock time, not just cputime -- maybe a
way to get shark to show system i/o |
| 20:05.16 |
brlcad |
oh, or maybe
better yet |
| 20:05.23 |
brlcad |
run shark on
fbserv |
| 20:05.48 |
brlcad |
that'll
probably say blitting, but should lead to the calls on the server
side that are responding |
| 20:06.07 |
brlcad |
which maybe
help point to where on the client, and who's problem it
is |
| 20:07.22 |
brlcad |
yet another
option, recompile and/or enable libpkg debugging to see what the
chatter looks like |
| 20:08.15 |
starseeker |
Hmm -
profiling fbserv, 50.5% was X24_blit |
| 20:08.34 |
brlcad |
"that'll
probably say blitting" ;) |
| 20:09.02 |
starseeker |
yep, you were
right :-) |
| 20:09.45 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:11.03 |
brlcad |
there's
probably a way to get at the libpkg debug vars through
rt |
| 20:11.55 |
brlcad |
my suspicion
is that it's sending one pixel per packet, and is just busy waiting
on the network to send 1024x1024 packets |
| 20:12.01 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 20:12.21 |
starseeker |
what does
bu_bitv_clear do? |
| 20:12.26 |
brlcad |
wow, even rt
-i is slow |
| 20:12.33 |
brlcad |
actually,
even slower |
| 20:12.51 |
brlcad |
bu_bitv_clear() erases a bit
vector |
| 20:13.32 |
starseeker |
ok, part of
ray shooting |
| 20:13.43 |
brlcad |
right |
| 20:13.48 |
brlcad |
at least,
that'd be my guess |
| 20:13.57 |
brlcad |
several
primitives use bit vectors for their book keeping |
| 20:19.06 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 20:19.06 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| GSoC 2008 Highlight: new prototype gui, check it out! || Source
Release 7.14.2 is posted (20080207) |
| 20:19.38 |
brlcad |
with the fb
at 1024x1024, any rt -i > -s512 runs dog slow, yet smaller is
fine |
| 20:19.56 |
brlcad |
without -i
though, any rt > 600 runs slow, yet 600 is fine |
| 20:20.15 |
starseeker |
on remote
display? |
| 20:20.23 |
brlcad |
yeah, same
fbserv as above example |
| 20:20.42 |
brlcad |
-i will make
it 8x slower |
| 20:20.51 |
brlcad |
because it's
multiple passes |
| 20:22.21 |
brlcad |
which is
fine, I'd expect that -- it's either fbserv's processing, the
packetsize/mode from rt, the network transfer itself, or something
in libpkg |
| 20:23.22 |
CIA-40 |
BRL-CAD:
03brlcad * r33967 10/brlcad/trunk/BUGS: |
| 20:23.22 |
CIA-40 |
BRL-CAD: was
finally able to pin down a reproducible-yet-previously just rumored
bug |
| 20:23.22 |
CIA-40 |
BRL-CAD:
about 'slow renderings' to some problem with remove fbserv's.
Problem minimally |
| 20:23.22 |
CIA-40 |
BRL-CAD:
occurs with an fbserv running a /dev/X interface >512 pixels
wide for -i or |
| 20:23.22 |
CIA-40 |
BRL-CAD:
(more interestingly) >600 without -i. |
| 20:23.50 |
starseeker |
blinks - profiling of the interactive rt -i results in 46%
time spent in ml_set_interrupts_enabled |
| 20:24.02 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 20:24.06 |
brlcad |
gprof? |
| 20:24.20 |
brlcad |
what's
calling that? |
| 20:24.24 |
starseeker |
shark |
| 20:24.27 |
starseeker |
not sure
yet |
| 20:24.41 |
brlcad |
click the
little arrow |
| 20:25.01 |
starseeker |
seems to have
something to do with semaphore_wait_signal_trap |
| 20:25.18 |
brlcad |
that'd be
thread contention |
| 20:25.20 |
brlcad |
tests |
| 20:25.33 |
starseeker |
find_user_regs is the last
entry |
| 20:25.39 |
starseeker |
for that
subtree at least |
| 20:25.45 |
brlcad |
nope, still
slow with -P1 |
| 20:26.26 |
brlcad |
I still
suspect it's some buffering packet size issue |
| 20:26.32 |
starseeker |
yeah,
probably |
| 20:26.40 |
starseeker |
hunts gprof docs |
| 20:27.06 |
``Erik |
<PROTECTED> |
| 20:27.30 |
brlcad |
--enable-profiling |
| 20:27.43 |
brlcad |
(which just
adds the -pg to the right places |
| 20:27.56 |
starseeker |
ah, build
time |
| 20:27.57 |
starseeker |
k |
| 20:28.15 |
brlcad |
yeah,
complete recompile |
| 20:28.34 |
brlcad |
then you run
the app(s) and they'll leave little gmon.out file turds
everywhere |
| 20:28.58 |
brlcad |
then when you
run gprof, it reads the turds and the binary and produces the call
tree |
| 20:29.15 |
``Erik |
sometimes
app.gmon iirc, depends on the os |
| 20:33.15 |
starseeker |
hrm - is
rem_write the remote write command? |
| 20:35.56 |
starseeker |
If shark's
Time Profile (All Thread States) is getting close to wall clock
capture, rt is spending virtually all its time in rem_write and
fbserve is in libSystem.B.dylib's select, called by fbserve
main |
| 20:39.02 |
starseeker |
is somewhat confused - why would rem_write be slow but
pkg_2send be fast? |
| 20:40.00 |
starseeker |
oh, wait -
pkg_2send is the top call |
| 20:40.54 |
starseeker |
ok, that's
odd but makes more sense |
| 20:43.40 |
starseeker |
brlcad: just
curious - are the hardcoded numbers at pkg.c:1103 of any
concern? |
| 20:48.27 |
starseeker |
notices the HAVE_WRITEV flag - nevermind |
| 21:22.16 |
brlcad |
starseeker:
hard-coded numbers are always a concern, but much harder to avoid
with networking code |
| 21:22.51 |
brlcad |
easy enough
buck-shot test though |
| 21:23.43 |
brlcad |
ah, no
matter, that's in an else block that isn't reached |
| 21:24.49 |
brlcad |
finishes reading what starseeker said and realizes you
realized that too |
| 21:31.42 |
starseeker |
gprof has
most of the calls going to _pkg_glong, __pkg_inget, and
_pkg_gshort |
| 21:31.48 |
starseeker |
for
rt |
| 21:32.28 |
starseeker |
didn't do a
time breakdown though |
| 21:34.18 |
starseeker |
oh, I
see |
| 21:34.39 |
brlcad |
oh, that is
cool .. libpkg debugging is turned on if you just touch a file or
set an ENV var |
| 21:36.05 |
brlcad |
okay, so
eliminated that thought -- it is just sending one packet per
scanline |
| 21:36.16 |
brlcad |
not per
pixel |
| 21:44.23 |
starseeker |
sees story about idea of API for congressional data and
cheers |
| 21:44.28 |
starseeker |
has had that idea for quite a while |
| 21:44.38 |
starseeker |
doubt it will
ever happen though |
| 21:49.03 |
brlcad |
tries for the fifth time to successfully merge without
getting a connection abort |
| 21:55.42 |
starseeker |
interesting -
the files generated for the step class library build on the Mac do
NOT have the double static instances |
| 21:56.55 |
starseeker |
wonders what is foobared on his home box this
time |
| 21:57.08 |
brlcad |
user
error |
| 21:57.57 |
starseeker |
for a fully
automated build process? Well, maybe, but I don't know that my
week has been THAT bad... |
| 21:58.45 |
brlcad |
there's no
such thing as fully automated ;) |
| 21:59.15 |
brlcad |
ours is
"fully automated" for many configurations and we could/do? document
it as such, but there are still plenty of configurations that
cannot be accounted for |
| 21:59.29 |
starseeker |
true |
| 21:59.31 |
brlcad |
a few flags,
a few settings |
| 21:59.48 |
starseeker |
suspects flex/yacc setup is wonky... |
| 22:00.22 |
brlcad |
usually |
| 22:00.41 |
brlcad |
that's neat..
breaking on rem_write |
| 22:00.51 |
brlcad |
c to render
one line at a time :) |
| 22:00.53 |
starseeker |
at least it's
working on OSX and Linux here if it comes to that |
| 22:00.55 |
brlcad |
click click
click |
| 22:01.00 |
starseeker |
heh - cool
:-) |
| 22:01.13 |
starseeker |
are you
seeing what I was with performance bottlenecks? |
| 22:01.30 |
brlcad |
i'm not
looking at that, figured you were |
| 22:01.36 |
starseeker |
ah |
| 22:01.52 |
brlcad |
no sense
doing things twice ;) |
| 22:02.45 |
starseeker |
heh - well,
I'm trying at least. If it's sending one scan line at a time...
hmm... |
| 22:04.25 |
starseeker |
is spoiled by Shark and blinks at gprof's
output |
| 22:07.33 |
starseeker |
brlcad: any
idea why gprof isn't giving me any % time? |
| 22:07.49 |
starseeker |
or rather,
possible causes of it not doing so? |
| 22:09.02 |
brlcad |
it's all in
the opts, I don't remember my gprof foo |
| 22:09.22 |
brlcad |
-F, looks
like it |
| 22:10.03 |
brlcad |
hah, did not
know about -E mcount |
| 22:10.10 |
brlcad |
that would
have been useful a few years ago |
| 22:10.16 |
brlcad |
shakes fist |
| 22:10.22 |
starseeker |
what is
moncount I wonder |
| 22:11.00 |
brlcad |
some
thing |
| 22:11.07 |
brlcad |
it's their
monitor counter |
| 22:11.34 |
brlcad |
basically
it's spending a lot of time in the profiler code itself because of
a lot of calls, so it shows up |
| 22:11.40 |
starseeker |
ah |
| 22:11.44 |
brlcad |
-E moncount
would make it go away |
| 22:11.51 |
brlcad |
so will -F
though, if you use it |
| 22:12.10 |
``Erik |
schrödinger's
profiler |
| 22:12.43 |
brlcad |
if this last
merge fails, I'm going to give up doing it from yonder busted
network |
| 22:13.02 |
*** join/#brlcad astrobear
(n=ib@unaffiliated/ibuffy) |
| 22:13.25 |
brlcad |
hugs the stellar bear |
| 22:13.26 |
starseeker |
usually has to do it in sub-directory
merges |
| 22:14.40 |
*** join/#brlcad astrobear
(n=ib@unaffiliated/ibuffy) |
| 22:14.57 |
brlcad |
so far, a
very clean merge, but the net keeps dropping out |
| 22:15.10 |
starseeker |
fun |
| 22:15.43 |
starseeker |
does subdirs to make "bite sized" chunks that can slip
between network outages |
| 22:16.10 |
starseeker |
wonder if
they can make the subversion commit routine more robust to network
drops somehow... |
| 22:16.52 |
brlcad |
I'm not sure
if doing subdirs will make an impact on what revision sets it will
attempt to apply |
| 22:17.05 |
starseeker |
hmm, that's a
point |
| 22:31.00 |
*** join/#brlcad smurfette
(n=user@c-69-242-189-29.hsd1.mo.comcast.net) |
| 23:16.00 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:21.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-241.sbndin.btas.verizon.net) |
| 23:29.48 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 23:34.49 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:55.23 |
bjorkintosh |
is it
possible to run the mged session on one machine and the display on
another, remotely? |
| 00:56.34 |
bjorkintosh |
eg: having
mged on asimov and the display portion on acclarke? |
| 01:06.16 |
bjorkintosh |
fbserv |
| 01:06.18 |
bjorkintosh |
never
mind! |
| 01:18.23 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 02:07.17 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:28.35 |
yukonbob |
hello,
cadheads |
| 02:43.06 |
starseeker |
braces himself and starts committing step
stuff |
| 04:03.35 |
starseeker |
is forced to do a retake tomorrow - too much junk that must
be cleaned out of the original NIST tarball before it is
committed |
| 04:04.37 |
bjorkintosh |
hmm. |
| 04:04.46 |
bjorkintosh |
i have fbserv
running on an other machine... |
| 04:04.59 |
bjorkintosh |
is it at all
possible to seperate the command window from the graphics
window? |
| 04:05.15 |
bjorkintosh |
so that the
graphics window is hosted on the remote machine? |
| 04:06.11 |
bjorkintosh |
great. a
crash. |
| 04:10.07 |
brlcad |
bjorkintosh:
you should be able to display it remotely via simple remote
X11 |
| 04:10.18 |
brlcad |
just set your
DISPLAY |
| 04:10.36 |
bjorkintosh |
i have. but
i'd like to have the command window on this machine and the
graphics window on the other machine. |
| 04:10.40 |
bjorkintosh |
is it
currently possible? |
| 04:11.04 |
brlcad |
technically,
probably |
| 04:11.14 |
brlcad |
but not
exactly a tested configuration |
| 04:11.22 |
bjorkintosh |
ah
okay. |
| 04:11.25 |
bjorkintosh |
any hints
then? |
| 04:12.01 |
brlcad |
try "attach
remotehost:0" |
| 04:12.17 |
brlcad |
half-blind
stab |
| 04:12.21 |
bjorkintosh |
in
mged? |
| 04:12.23 |
bjorkintosh |
okay. |
| 04:12.25 |
brlcad |
yep |
| 04:12.30 |
brlcad |
in the
command window |
| 04:12.51 |
brlcad |
might not
recognize the syntax |
| 04:13.42 |
brlcad |
ah,
nfg |
| 04:14.43 |
bjorkintosh |
nfg? |
| 04:15.12 |
brlcad |
~nfg |
| 04:15.38 |
brlcad |
ibot: wake
up |
| 04:15.39 |
ibot |
ACTION throws
a barrel-full of ice water on up and shouts "GOOD
MORNING!!!!" |
| 04:15.49 |
brlcad |
nfg -> no
fucking good |
| 04:16.13 |
brlcad |
bjorkintosh:
well, you could set DISPLAY, then run mged -c, attach X |
| 04:16.51 |
brlcad |
could even
run gui and the classic console will still work |
| 04:17.13 |
brlcad |
aha |
| 04:17.18 |
brlcad |
"gui
remotehost:0" |
| 04:17.45 |
brlcad |
it'll create
both, but should do the trick for arbitrary hosts |
| 04:17.48 |
bjorkintosh |
mged -c
works. |
| 04:18.18 |
brlcad |
gui is what
you wanted |
| 04:18.23 |
brlcad |
gui -d
remotehost:0 |
| 04:20.25 |
bjorkintosh |
ah i
see. |
| 04:20.36 |
bjorkintosh |
it creats an
identical screen on the remote machine. |
| 04:20.45 |
bjorkintosh |
so i now have
two command windows and two graphics windows. |
| 04:20.52 |
bjorkintosh |
one on this,
and the other on the remote machine. |
| 04:20.59 |
bjorkintosh |
so what's the
fbserv bit for then? |
| 04:22.22 |
bjorkintosh |
hah! this
kicks ass. |
| 04:23.50 |
brlcad |
yeah, and
they all work together |
| 04:24.33 |
brlcad |
so if you
really only wanted one command window on hostA and a graphics
window on hostB, you'd issue gui for the other and then close the
corresponding windows you don't want |
| 04:24.58 |
bjorkintosh |
aha! |
| 04:25.29 |
brlcad |
(note, mged
will shutdown if you close all the graphics windows) |
| 04:25.55 |
bjorkintosh |
i now have
the image displayed on 2 different screens. :D |
| 04:26.00 |
brlcad |
if you want
no graphics windows, then you go with mged -c and manually run
gui |
| 04:26.23 |
bjorkintosh |
the machine
running brlcad has no X, but i have two other ones which
do. |
| 04:26.32 |
bjorkintosh |
and they're
both currently showing the image as desired. |
| 04:27.03 |
brlcad |
fbserv is the
framebuffer server -- framebuffers are used for displaying raster
images, not for 3D interactive displays (we call those "display
managers" or dm's) |
| 04:28.49 |
brlcad |
the graphics
window is technically a display manager plus an overlayed
framebuffer server -- you can see how those two interact with each
other via the raytrace control panel |
| 04:32.13 |
brlcad |
bjorkintosh:
you said mged crashed earlier -- do you happen to have a bomb log
file(s) in your directory? |
| 04:32.33 |
brlcad |
if you do,
please upload to ftp.brlcad.org/incoming via anon ftp |
| 04:32.48 |
brlcad |
or post it
somewhere easily accessible |
| 04:33.31 |
bjorkintosh |
okay. if it
happens again, i'll send it your way. |
| 04:33.40 |
bjorkintosh |
i deleted it
immediately in annoyance. |
| 04:35.31 |
brlcad |
ah,
k |
| 04:41.34 |
bjorkintosh |
Zzzz. or i
won't wake up in the morning. |
| 04:41.36 |
bjorkintosh |
thanks
again. |
| 05:37.25 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.92.186.200) |
| 06:54.29 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 07:17.53 |
*** join/#brlcad Don__
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 07:36.06 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:18.18 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:48.42 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:50.20 |
*** join/#brlcad Don_
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 10:48.41 |
CIA-40 |
BRL-CAD:
03davidloman * r33979 10/rt^3/tags/gsph0/: Tagged for
GeometeryService phase Zero milestone. |
| 11:21.19 |
d-lo |
huh.
Raytracing in DX11: http://tech.slashdot.org/article.pl?sid=08/03/31/1423247 |
| 11:46.12 |
d-lo |
Code Religion
question: 'Goto' statement in modern C and C++: Good, Neutral,
Evil, and why? |
| 11:49.02 |
d-lo |
My personal
take is: Evil as it leads to spaghetti and can easily be avoided by
some re-structuring. What are other people's opinions? |
| 11:59.40 |
CIA-40 |
BRL-CAD:
03davidloman * r33980 10/rt^3/trunk/ (4 files in 3 dirs): Removal
of Boost libraries. Didn't work as well as I would have liked. Die
boost, die. |
| 12:17.52 |
*** join/#brlcad ``Erik
(n=erik@ftp.brlcad.org) |
| 12:36.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-10.sbndin.btas.verizon.net) |
| 12:37.17 |
brlcad |
d-lo: it is
neither evil nor non-evil, just one of many tools available (and
one often misunderstood/misused) -- whether it's the right tool for
the job depends entirely on the situation |
| 12:40.30 |
brlcad |
it rarely is
actually needed and beneficial, but there are some times when a
localized goto is better than various alternate
restructurings |
| 12:42.20 |
brlcad |
that said,
they are very rarely the best tool |
| 12:43.51 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:04.01 |
d-lo |
brlcad: okay
cool. I ran across some in rt^3, so i figured I would
ask. |
| 13:13.56 |
brlcad |
d-lo: where
at? |
| 13:14.32 |
brlcad |
ah, I
see |
| 13:14.44 |
brlcad |
all
throughout ogre and some of the new code |
| 13:15.34 |
d-lo |
I am not so
much opposed to the stuff in ogre, since its being used as a lib.
Just the stuff we have control over. :/ |
| 13:16.42 |
brlcad |
I see why
he's using it, related to the 'exceptions' that libbu can throw
with BU_SETJUMP/BU_UNSETJUMP |
| 13:17.18 |
d-lo |
lack of exp
talking here: wouldnt a try/catch/finally work just as
well? |
| 13:17.24 |
brlcad |
it's actually
a pretty reasonable use in that place |
| 13:17.25 |
brlcad |
nope |
| 13:17.55 |
brlcad |
those are c++
constructs that only work with c++ exceptions, hence the quoted
'exceptions' :) |
| 13:19.49 |
brlcad |
there is an
equivalent logical structure using if/then that could be used --
but it's only arguably better because you're already
jumping |
| 13:20.06 |
brlcad |
jumps are
very low-level C |
| 13:20.28 |
brlcad |
you could
implement C++ exceptions using them (and many compilers do/did),
for example |
| 13:20.31 |
d-lo |
hence
'faster' ? |
| 13:20.43 |
brlcad |
they are ..
exceptionally faster |
| 13:20.47 |
brlcad |
but that's
not the reason |
| 13:21.36 |
brlcad |
they're just
one of the ways in C you can achieve a multiple-scope break in
logic flow |
| 13:22.00 |
d-lo |
so its more
coding style than anything else? |
| 13:22.22 |
brlcad |
try/catch/finally are really glorified
syntactic setjump/longjump/goto's for that matter |
| 13:22.36 |
brlcad |
not really
coding style -- he's responding to libbu |
| 13:22.42 |
brlcad |
actually,
librt |
| 13:22.59 |
brlcad |
which will
throw a jump on failure for some routines |
| 13:23.20 |
brlcad |
so he catchs
it and returns gracefully |
| 13:23.24 |
d-lo |
hrm, I will
have to look at that deeper sometime soon i suppose.... |
| 13:24.50 |
brlcad |
quick
example: |
| 13:24.52 |
brlcad |
<PROTECTED> |
| 13:24.52 |
brlcad |
<PROTECTED> |
| 13:24.52 |
brlcad |
<PROTECTED> |
| 13:24.52 |
brlcad |
<PROTECTED> |
| 13:24.54 |
brlcad |
END_MARK: |
| 13:24.57 |
brlcad |
<PROTECTED> |
| 13:25.24 |
brlcad |
first pass
through, the jump point is set on that if line |
| 13:26.29 |
brlcad |
and it
evaluates false, does the unitize and rt_shootray |
| 13:26.34 |
brlcad |
if
rt_shootray() has a failure, it may jump -- which will return logic
back to that if line and it'll evaluate true |
| 13:26.54 |
brlcad |
at which
point it goes to endmark, unsets the jump, and continues on its
way |
| 13:27.21 |
brlcad |
in this
particular example, there was nothing important that needed to
occur, but could have easily had more after rt_shootray() that
would have been important to avoid |
| 13:27.26 |
d-lo |
cool. Makes
sense. :) |
| 13:27.40 |
brlcad |
you can
acheive the same in that particular example with just: |
| 13:27.53 |
brlcad |
if
(!BU_SETJUMP) { |
| 13:27.59 |
brlcad |
<PROTECTED> |
| 13:27.59 |
brlcad |
<PROTECTED> |
| 13:28.02 |
brlcad |
} |
| 13:28.06 |
brlcad |
BU_UNSETJUMP; |
| 13:28.16 |
brlcad |
but that's
specific to that snippet |
| 13:28.42 |
brlcad |
and arguably
less explicit |
| 13:29.03 |
brlcad |
that's closer
to what we do in our own code, though, with the jumps |
| 13:30.08 |
d-lo |
pretty neat.
Has it been benchmarked to an equivilent try/catch? I would be
curious as to the results! |
| 13:32.14 |
brlcad |
you can't use
try/catch |
| 13:32.23 |
brlcad |
they're not
c++ exceptions |
| 13:32.37 |
d-lo |
righto, hence
'equivlent' |
| 13:33.08 |
brlcad |
that is an
equivalent mechanism, what do you mean? |
| 13:33.43 |
d-lo |
Jumping is a
failure recovery mechanism (at least used like this),
correct? |
| 13:33.47 |
brlcad |
if/then vs
if/goto? not really much difference performance-wise |
| 13:33.57 |
brlcad |
sure
is |
| 13:34.20 |
brlcad |
or a
roll-back logic redirect |
| 13:34.46 |
d-lo |
and the above
code snippet is trying to call rt_shootray(&ap) all the while
ready to catch a failure of that call.... right? |
| 13:34.58 |
brlcad |
yep |
| 13:35.23 |
brlcad |
specifically
an abnormal failure that is raised by a jump |
| 13:37.15 |
d-lo |
so, the C++
equivlient would be something like: |
| 13:37.31 |
d-lo |
try
{ |
| 13:37.39 |
d-lo |
VUNITIZE(ap.a_ray.r_dir); |
| 13:37.39 |
d-lo |
rt_shootray(&ap); |
| 13:37.39 |
d-lo |
} catch
(OmgWtfHappendToRtShootRayException e) { |
| 13:37.39 |
d-lo |
//stuff |
| 13:37.39 |
d-lo |
} finally
{ |
| 13:37.41 |
d-lo |
//more
stuff |
| 13:37.46 |
d-lo |
} |
| 13:37.48 |
brlcad |
that would
only work if rt_shootray threw c++ exceptions |
| 13:37.53 |
d-lo |
bah, that
paste didn't work. |
| 13:37.55 |
brlcad |
it doesn't
throw c++ exceptions |
| 13:37.59 |
brlcad |
rt_shootray
can't throw a c++ exception because it's not a c++
library |
| 13:38.02 |
d-lo |
right, i get
that. |
| 13:38.47 |
brlcad |
so it's not
an option .. :) |
| 13:38.47 |
d-lo |
"But if it
did", how would the performance compare..... |
| 13:38.52 |
brlcad |
oh
hell |
| 13:38.57 |
brlcad |
c++
exceptions are absurdly expensive |
| 13:39.03 |
brlcad |
there have
been lots of comparisons |
| 13:39.30 |
brlcad |
it doesn't
really get much cheaper than a jump -- it literally amounts to a
one-line jmp assembly instruction usually |
| 13:39.39 |
d-lo |
kk |
| 13:39.46 |
brlcad |
c++
exceptions are one to two orders faster |
| 13:40.03 |
brlcad |
which is why
studio has entire compilation modes with c++ exceptions
on/off |
| 13:40.04 |
d-lo |
on a side
note, I need to learn asm :/ |
| 13:40.45 |
brlcad |
runs |
| 13:51.27 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 14:41.51 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:56.01 |
*** join/#brlcad BigAToo
(n=BigAToo@64.255.115.3) |
| 15:36.21 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 15:49.11 |
*** join/#brlcad ``Erik__
(n=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:50.21 |
d-lo |
``Erik__:
Heya! |
| 16:44.44 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 16:50.01 |
``Erik__ |
oi |
| 16:51.14 |
d-lo |
howdy
stranger! |
| 16:52.07 |
d-lo |
whats
new? |
| 16:54.27 |
CIA-40 |
BRL-CAD:
03davidloman * r33981 10/rt^3/trunk/ (69 files in 15 dirs): Removed
typedefs from iBMECommon.h. Refactored all .h and .cxx files
accordingly. |
| 16:59.11 |
CIA-40 |
BRL-CAD:
03starseeker * r33982 10/brlcad/trunk/ (499 files in 49 dirs): (log
message trimmed) |
| 16:59.12 |
CIA-40 |
BRL-CAD:
Begin the process of adding NIST's STEP Class Libraries code to the
BRL-CAD |
| 16:59.12 |
CIA-40 |
BRL-CAD:
tree. This first commit sets up the build logic for a
src/other/step |
| 16:59.12 |
CIA-40 |
BRL-CAD:
subconfigure and imports a step tree which is the original NIST
STEP 3.2 |
| 16:59.12 |
CIA-40 |
BRL-CAD:
release, minus some temporary files and an old file in src/cldai
that causes |
| 16:59.14 |
CIA-40 |
BRL-CAD:
conflicts on case insensitive filesystems. This is not expected to
be a |
| 16:59.16 |
CIA-40 |
BRL-CAD:
buildable configuration - it is included to preserve the original
state of the |
| 17:19.04 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.92.185.81) |
| 17:25.59 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-10.sbndin.btas.verizon.net) |
| 17:39.22 |
CIA-40 |
BRL-CAD:
03starseeker * r33983 10/brlcad/trunk/src/other/step/ (83 files in
25 dirs): (log message trimmed) |
| 17:39.22 |
CIA-40 |
BRL-CAD:
Update STEP code to version from |
| 17:39.22 |
CIA-40 |
BRL-CAD:
http://www.statik.tu-cottbus.de/fileadmin/project_dth/scl/
This configuration |
| 17:39.22 |
CIA-40 |
BRL-CAD: is
closer to building on many platforms but will need special options
to |
| 17:39.22 |
CIA-40 |
BRL-CAD:
configure not supplied by default. As this is not the final form
the libraries |
| 17:39.26 |
CIA-40 |
BRL-CAD: will
take in the BRL-CAD tree no attempt is made to work with this
build |
| 17:39.28 |
CIA-40 |
BRL-CAD:
structure. One more commit will be needed for a file renaming but
after that |
| 17:39.38 |
d-lo |
go go gadget
STEP! |
| 17:41.46 |
CIA-40 |
BRL-CAD:
03starseeker * r33984
10/brlcad/trunk/src/other/step/src/cldai/sdaiDaObject.cc: Add back
in the properly named sdaiDaObject.cc |
| 17:41.52 |
starseeker |
OK, now the
real fun |
| 17:44.07 |
starseeker |
takes what he has building so far and attemps to make
something that won't bust distcheck |
| 17:49.11 |
starseeker |
debates nuking and re-adding vs. gradually shifting to
working... |
| 17:49.52 |
CIA-40 |
BRL-CAD:
03indianlarry * r33985 10/brlcad/trunk/src/libged/clone.c: updated
clone command to re-number and work with the naming convention used
in 'build_region' tclscript |
| 17:53.42 |
CIA-40 |
BRL-CAD:
03indianlarry * r33986 10/brlcad/trunk/src/librt/mirror.c: updated
rt_mirror to fix bug 2679693, looks like the radius vectors were
getting paired wrong in the mirror |
| 18:01.34 |
d-lo |
``Erik: You
around? |
| 18:07.29 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 18:08.20 |
d-lo |
heh, ``Erik :
you having connection problems or what? ;) |
| 18:19.35 |
``Erik_ |
always |
| 18:19.56 |
d-lo |
whats
new? |
| 18:21.40 |
CIA-40 |
BRL-CAD:
03starseeker * r33987 10/brlcad/trunk/src/other/step/ (16 files):
Start setting up standard README, COPYING, NEWS, etc.
files |
| 18:23.02 |
d-lo |
``Erik: When
could you sit down and talk to me about specifics of that Lisp web
framework? I have the itch to move forward with a web- base game
;) |
| 18:24.34 |
CIA-40 |
BRL-CAD:
03starseeker * r33988 10/brlcad/trunk/src/other/step/
(arch_template/ bin/): Clear out arch_template and bin |
| 18:24.53 |
``Erik_ |
*shrug* I
should be in tomorrow, it's an odd thing though |
| 18:25.55 |
d-lo |
*chuckle* the
ucw google search stil makes me laugh :) |
| 18:29.13 |
d-lo |
might use php
though. Which would you recommend for storage sql or flat
file? |
| 18:45.43 |
CIA-40 |
BRL-CAD:
03starseeker * r33989 10/brlcad/trunk/src/other/step/ (80 files in
7 dirs): More inching forward in STEP |
| 18:47.21 |
CIA-40 |
BRL-CAD:
03starseeker * r33990 10/brlcad/trunk/src/other/step/misc/ (.
Makefile.am Makefile.defs flawfinder libtool.m4): Add step/misc
directory |
| 18:54.40 |
CIA-40 |
BRL-CAD:
03homovulgaris * r33991 10/brlcad/trunk/src/other/boost/ (996 files
in 124 dirs): boost update particularly phoenix |
| 18:59.31 |
*** join/#brlcad madant
(n=madant@117.196.146.10) |
| 19:09.55 |
CIA-40 |
BRL-CAD:
03starseeker * r33992 10/brlcad/trunk/src/other/step/ (8 files in 8
dirs): Add some Makefile.am files to various
directories |
| 19:31.01 |
brlcad |
howdy
madant |
| 19:33.10 |
brlcad |
notes that distcheck is busted |
| 19:33.22 |
starseeker |
brlcad: I
know, I know |
| 19:33.25 |
starseeker |
working on it
;-) |
| 19:33.57 |
CIA-40 |
BRL-CAD:
03starseeker * r33993 10/brlcad/trunk/src/other/step/src/ (123
files in 8 dirs): Merge in most of the changes made thus far.
Probably won't build yet as new Makefile.am stuff is untested, but
getting close |
| 19:37.04 |
brlcad |
first commit
step should have been to just extra_dist it from src/other or
conditionalize it, then work on cleaning up src/other/step/*, then
deconditionalize it -- that way it stays working |
| 19:37.27 |
starseeker |
ok, I'll put
that in for now |
| 19:37.55 |
brlcad |
do you know
how to conditionalize it? |
| 19:38.14 |
starseeker |
sort
of |
| 19:40.17 |
CIA-40 |
BRL-CAD:
03starseeker * r33994 10/brlcad/trunk/src/other/Makefile.am:
EXTRA_DIST step for now |
| 19:42.03 |
starseeker |
that get it
for now? |
| 19:44.35 |
brlcad |
don't know,
busy reading what we're going to talk about in 15 min
;) |
| 19:45.19 |
brlcad |
fyi, though,
I have some questions -- like what's up with the stuff deleted --
commit message doesn't say what/why |
| 19:45.41 |
brlcad |
would have
thought clcore was kinda important, for example |
| 19:45.56 |
brlcad |
unless it's
just for the editor |
| 19:47.04 |
brlcad |
and it looks
like build is still busted, you have subconfigure enabled in
configure |
| 19:47.10 |
brlcad |
returns to reading |
| 19:49.32 |
CIA-40 |
BRL-CAD:
03starseeker * r33995 10/brlcad/trunk/configure.ac: Disable step
subconfigure until it's working |
| 19:50.34 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:01.34 |
CIA-40 |
BRL-CAD:
03starseeker * r33996 10/brlcad/trunk/src/other/step/Makefile.am:
Stuff the other dirs behind EXTRA_DIST for now, and bring them out
later if they should be elsewhere. |
| 20:03.58 |
CIA-40 |
BRL-CAD:
03brlcad * r33997 10/brlcad/trunk/doc/TODO.BREP: add a missing
important plane specialization of surfaces analogous to lines vs
curves |
| 20:37.55 |
madant |
hi brlcad :)
nothing much.. i need to sort out some crappy spirit and phoenix
includes.. :) going to sleep now :) |
| 21:30.34 |
CIA-40 |
BRL-CAD:
03brlcad * r33998 10/brlcad/trunk/doc/TODO.BREP: Added few more
queries. |
| 21:52.33 |
*** join/#brlcad PrezKennedyJR
(i=Matthew@whitecalf.net) |
| 22:03.00 |
CIA-40 |
BRL-CAD:
03brlcad * r33999 10/brlcad/trunk/doc/TODO.BREP: Breakout of
raytracing dependencies |
| 22:06.53 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-10.sbndin.btas.verizon.net) |
| 01:20.11 |
starseeker |
brlcad: If
it's r33993, that's just headers and changes to c files |
| 01:33.54 |
starseeker |
prepares to shift the headers back into their individual
directories |
| 01:43.32 |
CIA-40 |
BRL-CAD:
03starseeker * r34000 10/brlcad/trunk/src/other/step/ (21 files in
2 dirs): Put cldai headers back where they came from |
| 01:46.49 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 01:46.49 |
*** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
[NETSPLIT VICTIM] |
| 01:49.42 |
CIA-40 |
BRL-CAD:
03starseeker * r34001 10/brlcad/trunk/src/other/step/ (22 files in
2 dirs): Put cleditor headers back where they came from |
| 01:50.28 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 02:00.24 |
CIA-40 |
BRL-CAD:
03starseeker * r34002 10/brlcad/trunk/src/other/step/ (40 files in
2 dirs): Put clstepcore headers back where they came
from |
| 02:04.30 |
CIA-40 |
BRL-CAD:
03starseeker * r34003 10/brlcad/trunk/src/other/step/ (24 files in
2 dirs): Put clutils headers back where they came from |
| 02:10.48 |
*** join/#brlcad muale
(n=n3wm0nk@pool-71-172-120-145.nwrknj.east.verizon.net) |
| 02:12.30 |
brlcad |
starseeker:
yeah, I see that now going back through my commit log mails ..
maybe just more headers than I expected or all the 'c's in the
names |
| 02:14.55 |
brlcad |
which is
odd.. I swear my svn update said a slew of .cc/.c files |
| 02:15.12 |
brlcad |
only reason
it caught my attention |
| 02:15.19 |
brlcad |
oh
well |
| 02:15.30 |
starseeker |
brlcad: Now
I remember what the issue was - a lot of files assume the .h files
ARE all in the same directory |
| 02:15.41 |
brlcad |
wonders why cruisecontrol still says distcheck is
failing |
| 02:15.42 |
starseeker |
or at least
included |
| 02:15.58 |
brlcad |
how
so? |
| 02:16.14 |
brlcad |
#include
"somefilenotinthisdir.h"? |
| 02:16.44 |
brlcad |
that'd mean
their build system was setting the cppflags |
| 02:16.49 |
starseeker |
mostly
#include <somefile.h> |
| 02:17.02 |
brlcad |
yeah, same
thing |
| 02:17.06 |
brlcad |
just bad
style |
| 02:17.37 |
starseeker |
the build
(originally) takes place in a directory called
editorCore |
| 02:17.51 |
starseeker |
looks like
they copied a bunch of stuff somewhere to build it |
| 02:17.52 |
starseeker |
ick |
| 02:18.05 |
starseeker |
what's the
correct solution? |
| 02:18.27 |
starseeker |
at
-I../src/clwhatever to the Makefile.am s? |
| 02:18.32 |
starseeker |
er
s/at/add |
| 02:19.01 |
starseeker |
or I can
change the references to "../clwhatever/file.h" |
| 02:19.07 |
brlcad |
either to the
Makefile.am's or to the configure.ac if it makes sense to be
project-wide |
| 02:19.25 |
brlcad |
nah, I
wouldn't recommend that -- ties to the dir structure, which could
change |
| 02:20.02 |
brlcad |
only
"clwhatever/file.h" if you wanted to leave everything in include/
and have include/clwhatever |
| 02:20.05 |
starseeker |
is leary of doing it at the configure.ac level, so am files
it is - just libwhatever_la_CXXFLAGS = -I... |
| 02:20.38 |
brlcad |
given how it
looks like scl is organized, Makefile.am sounds like the right
approach |
| 02:20.42 |
starseeker |
brlcad: that
might make sense once I figure out which headers are actually
intended as "API" headers |
| 02:21.04 |
starseeker |
takes a stab at it |
| 02:21.14 |
brlcad |
could 'maybe'
have the lower-level C libs be "global" cppflags (ala include/) but
wouldnt' matter much |
| 02:21.27 |
brlcad |
that'd be
useful |
| 02:21.52 |
brlcad |
if you can
discern the difference, then the local includes should be
identified via #include "./file.h" |
| 02:22.12 |
brlcad |
so you can
distinguish private from public headers on use |
| 02:22.32 |
starseeker |
nods |
| 02:22.38 |
brlcad |
and get rid
of the <>'s |
| 02:23.20 |
brlcad |
that should
be for finding system headers or nominally for system-"installed"
headers |
| 02:24.00 |
starseeker |
that's what I
thought |
| 02:25.29 |
CIA-40 |
BRL-CAD:
03starseeker * r34004
10/brlcad/trunk/src/other/step/src/clstepcore/Makefile.am: Add
includes needed for original header locations in
clstepcore |
| 02:26.00 |
starseeker |
thinks commit 40000 should be a new modeler for BRL-CAD
:-) |
| 02:26.09 |
brlcad |
heh |
| 02:28.44 |
CIA-40 |
BRL-CAD:
03starseeker * r34005
10/brlcad/trunk/src/other/step/src/cleditor/Makefile.am: Add
includes needed for original header locations in
cleditor |
| 02:31.54 |
starseeker |
OK, that may
do it |
| 02:31.57 |
CIA-40 |
BRL-CAD:
03starseeker * r34006
10/brlcad/trunk/src/other/step/src/cldai/Makefile.am: Add includes
needed for original header locations in cldai |
| 02:41.18 |
CIA-40 |
BRL-CAD:
03starseeker * r34007
10/brlcad/trunk/src/other/step/src/exppp/Makefile.am: Whoops - fix
noinst_HEADERS in exppp |
| 02:50.02 |
CIA-40 |
BRL-CAD:
03starseeker * r34008
10/brlcad/trunk/src/other/step/src/clstepcore/Makefile.am: Add the
clstepcore headers to Makefile.am as noinst for now. |
| 03:21.54 |
yukonbob |
hello,
cadheads |
| 03:25.30 |
bjorkintosh |
ah it's the
'hello, cadheads' bot. |
| 03:34.07 |
yukonbob |
ah, it's the
"ah it's the 'hello, cadheads' bot." bot |
| 03:36.10 |
bjorkintosh |
it is none
other but i. |
| 03:36.12 |
bjorkintosh |
bows. |
| 03:37.23 |
brlcad |
waves |
| 03:37.51 |
yukonbob |
evening
bjorkintosh, brlcad |
| 03:37.52 |
bjorkintosh |
i'm now
setting up a 4th machine to gui -d host:0 on :D |
| 03:37.58 |
brlcad |
heh |
| 03:38.05 |
yukonbob |
checks in from Airport -- free wifi,
yay!!1 |
| 03:38.13 |
yukonbob |
*airport |
| 03:38.14 |
bjorkintosh |
it's teh
AW3S0M3! |
| 03:42.38 |
yukonbob |
what's new,
brlcad ? |
| 03:43.25 |
brlcad |
documented
brep planning, new dev making awesomeness happen, new
release |
| 03:43.45 |
brlcad |
contentedly wanders off for a bit |
| 03:44.55 |
yukonbob |
checks page for release details... |
| 03:47.26 |
yukonbob |
updates svn |
| 05:22.13 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 05:45.54 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 06:08.38 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 07:56.30 |
*** join/#brlcad madant (n=madant@117.196.146.10) [NETSPLIT
VICTIM] |
| 08:10.50 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:29.50 |
*** join/#brlcad _sushi__
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:42.13 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 08:43.16 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:56.19 |
brlcad |
morning
d_rossberg |
| 08:56.51 |
d_rossberg |
morning
brlcad |
| 09:52.44 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 10:00.24 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:28.46 |
d-lo |
mornin
all! |
| 11:18.33 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-91.sbndin.btas.verizon.net) |
| 11:29.34 |
brlcad |
howdy
d-lo |
| 11:30.10 |
*** join/#brlcad madant
(n=madant@117.196.139.36) |
| 11:30.43 |
d-lo |
is reading up on the use of /dev/poll for IO multiplexing.
Purty neat akshually. |
| 11:34.03 |
brlcad |
creative, but
very non-portable |
| 11:34.11 |
d-lo |
yeah I know
:/ |
| 11:34.14 |
d-lo |
still neat
:) |
| 11:34.18 |
d-lo |
good brain
food. |
| 11:34.26 |
brlcad |
nods |
| 11:34.46 |
d-lo |
besides, who
needs windows support. pffft. |
| 11:34.48 |
brlcad |
old
sysvism |
| 11:34.50 |
d-lo |
=D |
| 11:34.52 |
brlcad |
not just
windows |
| 11:34.58 |
brlcad |
that's not
even portable across various unices |
| 11:35.44 |
brlcad |
it's a
relatively new/old sysv construct |
| 11:36.14 |
brlcad |
old sysv
systems are like old at&t unix (which I don't think had a
/dev/poll, but was sysv nonetheless) |
| 11:36.39 |
brlcad |
linux adopted
some sysv, most distros probably include it |
| 11:36.41 |
brlcad |
and
solaris |
| 11:37.00 |
brlcad |
but no bsds,
no mac, no hp, maybe aix, etc |
| 11:37.29 |
brlcad |
and flaky
across various versions of those that do support it |
| 11:38.21 |
d-lo |
heh,
'flaky'... is that a technical term? :) |
| 11:38.33 |
brlcad |
yep |
| 11:38.56 |
brlcad |
there are
lots of flakey interfaces when it comes to
communication |
| 11:41.16 |
brlcad |
that's what
makes interfaces like libpkg that are well tested and robust to
environments/platforms/events/conditions very useful |
| 11:41.46 |
d-lo |
question on
libpkg: how well does it handle multiple connections? |
| 11:42.42 |
brlcad |
handles them
just fine |
| 11:42.45 |
brlcad |
it's point to
point client-server based, so you do what you want with the
descriptor |
| 11:43.37 |
brlcad |
it pushes
most of the logic up into the application layer |
| 11:43.43 |
d-lo |
poorly worded
question :) I ment to ask: Is there any utility in libpkg for
managing multiple connections at once? |
| 11:45.28 |
brlcad |
what do you
mean by managing them? it doesn't really manage the connection,
that's the app's job -- it just establishes a point to point and
you do with that as you please |
| 11:45.39 |
brlcad |
from there
you can build up pretty much any network infrastructure |
| 11:46.04 |
d-lo |
kk, thats
what I thought. Just wanted to make sure I wasn't missing anything
obvious.... |
| 11:46.05 |
brlcad |
be that a
token-ring, simple client-server, peer to peer shared,
whatever |
| 11:48.26 |
*** join/#brlcad d_rossbe1g
(n=rossberg@bz.bzflag.bz) |
| 11:48.36 |
d-lo |
cool.
subject change: I would like to revisit our discussion about how
the .g data in the svn is going to be stored |
| 11:49.36 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 11:50.33 |
d-lo |
I cannot
remember what we desided was the best amount of geometry to include
in a single .g file: A comb, A region, or a single
Prim.... |
| 11:51.13 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 11:52.23 |
brlcad |
per
object |
| 11:53.00 |
d-lo |
okay, 1 .g
contains a single db object. And the actual file names were going
to be the UUID ? |
| 11:54.16 |
brlcad |
a single db
object sans _GLOBAL even |
| 11:54.53 |
brlcad |
which might
take a few minor back-end changes to make sure it doesn't stub them
in |
| 11:56.55 |
brlcad |
what names
become an effective mapping will be probably need to be heavily
tied to a given backend storage manager that decides how to map a
request to a storage mechanism |
| 11:59.59 |
d-lo |
hrm, I had no
idea that subversion REQUIRES Apache Portable Runtime... I was
under the assumption that it could be built without it. |
| 12:00.02 |
d-lo |
:/ |
| 12:00.23 |
brlcad |
using uuid is
maybe what it'll end up needing to be, but the danger there will be
ending up needing to perform some O(n) lookup for every object
name, table of content inconsistency problems, etc |
| 12:00.51 |
brlcad |
lots of codes
use apr, sort of like our libbu |
| 12:01.07 |
d-lo |
could you
explain '0(n)' ...i don't understand that. |
| 12:01.22 |
brlcad |
basically a
linear lookup cost |
| 12:01.33 |
brlcad |
the
complexity of a given action |
| 12:01.46 |
brlcad |
ideally you
want O(1), constant cost |
| 12:01.58 |
d-lo |
ah, i
c. |
| 12:01.59 |
d-lo |
thanks |
| 12:02.13 |
brlcad |
i.e., if i
ask for X, it takes you exactly "one step" to give me X |
| 12:03.14 |
brlcad |
if you have
to even look down a list for X, that becomes O(n) linear time, or
possibly O(logn) or O(nlogn) if you use some hierarchical container
or hashes |
| 12:03.55 |
brlcad |
the easiest
first step is to probably just directly map a .g to a scoped
context, i.e. a directory |
| 12:04.25 |
brlcad |
with each
object in the .g mapping to a file in that dir with the name being
the name of that object from the .g |
| 12:04.35 |
brlcad |
that would
maintain O(1) |
| 12:05.22 |
d-lo |
so.... one
'master' .g that knows the location of all other data? |
| 12:06.20 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 12:07.05 |
brlcad |
not exactly,
it amounts to how many problems are you trying to solve
next |
| 12:07.30 |
d-lo |
you've got me
99% confused now. |
| 12:07.39 |
brlcad |
first step
was deliver a .g when someone asks for a .g, right? |
| 12:08.04 |
brlcad |
i'm saying
next step would be to deliver a sub portion of a .g when someone
asks for it |
| 12:08.06 |
d-lo |
correct |
| 12:08.29 |
d-lo |
so then they
would supply a filename and an objectname or would filename be
assumed? |
| 12:08.56 |
brlcad |
i'd turn it
into a path request right away since that's already
implied |
| 12:09.24 |
brlcad |
first allowed
was whatever://localhost/file.g |
| 12:09.33 |
brlcad |
now you'd be
allowing whatever://localhost/file.g/object |
| 12:10.20 |
d-lo |
feck, now i
have to get and build openSSL for APR :/ |
| 12:10.26 |
d-lo |
okay I
understand now. |
| 12:11.03 |
brlcad |
you wouldn't
even have to break up the .g files yet to make that work if you
didn't want to, and have the storage manager do the object lookup
with a folder filled with .g files |
| 12:11.39 |
brlcad |
then next
step might be to have a storage manager that turns the .g files
into dirs and has a .g per object in each of the various .g
subdirs |
| 12:11.46 |
d-lo |
Question: If
no other data bout 'object' is known except the path to it, how
will the GS get a handle on it without walking the tree? (aka,
deviating from linear time?) |
| 12:12.55 |
brlcad |
that last
step I mentioned returns it to linear time |
| 12:13.04 |
brlcad |
er sorry,
constant time |
| 12:13.19 |
brlcad |
as path would
map to file/data |
| 12:15.22 |
brlcad |
note that an
object-scoped request, like //localhost/file.g/path/to/object is
still constant -- it just means load three objects (path, object,
and to) in the file.g context |
| 12:16.13 |
brlcad |
that'd be
interesting actually |
| 12:17.42 |
brlcad |
broken out
per file like that into dirs, it could conceivably outperform
current single-file accessat least the asymptotic complexity is
less on paper |
| 12:18.36 |
brlcad |
just bigger
constants (multiple file and operating system overhead) |
| 12:19.12 |
d-lo |
so are you
saying have less .g files that are 'higher' in the heirarchy or
more .g files 'lower' in the heirarchy? *confused* |
| 12:20.21 |
starseeker |
d-lo: heck
with subversion, build on top of git ;-) |
| 12:20.22 |
brlcad |
that turning
a dir filled with .g's into a dir of dirs filled with
per-object-g's could conceivably outperform |
| 12:20.34 |
brlcad |
git doesn't
have libs |
| 12:20.41 |
brlcad |
and isn't
portable |
| 12:20.48 |
starseeker |
reflects that a power outage is a great way to interrupt a
hacking session |
| 12:21.56 |
d-lo |
Okay, so,
instead of a single dir with a bajillion .g's in it, organize it
into a heirarchy of dirs with the .g's sitting at the 'bottom' of
the heirarchy? |
| 12:22.09 |
starseeker |
brlcad: very
true |
| 12:22.13 |
starseeker |
blegh |
| 12:22.42 |
starseeker |
checks on openssl's license - thought it was
weird |
| 12:23.40 |
d-lo |
just read
it... don't think it will be a problem. |
| 12:24.11 |
starseeker |
yeah, looks
OK |
| 12:24.18 |
starseeker |
checks APR |
| 12:24.59 |
d-lo |
besides, svn
requires libserf which requires openSSL.... so, if anything in this
stupid req tree precludes us from using it, we might have a problem
:/ |
| 12:25.13 |
brlcad |
d-lo: I
wouldn't start with a hierarchy of dirs, just a single
scope |
| 12:25.58 |
starseeker |
d-lo: Right.
I just thought we should check since my original understanding was
that the long term goal is to have a geometry server in every
install of BRL-CAD |
| 12:26.38 |
brlcad |
having a
hierarchy adds additional complexity not yet needed -- not clear
that's what we'd want to end up with down the road |
| 12:27.08 |
brlcad |
maybe it is,
but hard to say until that feature is being addressed because it
gets nasty when things are no longer at a fixed depth in the
hierarchy |
| 12:27.12 |
starseeker |
hmm - APR is
Apache License 2.0 |
| 12:28.07 |
brlcad |
apache
license is fine |
| 12:28.23 |
brlcad |
it's
basically a more verbose bsd license |
| 12:28.33 |
d-lo |
LGPL =
Library General Public License? |
| 12:28.51 |
starseeker |
Ah. Is this
the one that was GPL incompatible because of the patent
thing? |
| 12:28.55 |
brlcad |
~lgpl |
| 12:28.56 |
ibot |
hmm... lgpl
is the Lesser General Public License, see http://www.gnu.org/copyleft/lesser.txt
or http://www.fsf.org/licenses/lgpl.txt |
| 12:29.15 |
brlcad |
used to be
library, but fsf changed it to be lesser to try to get more folks
to use gpl |
| 12:29.47 |
d-lo |
ah, okay.
Then the license for 'neon' is okay. |
| 12:30.22 |
brlcad |
is that what
they use? |
| 12:30.51 |
brlcad |
when I
surveyed them a couple years ago, everything in svn and needed by
svn was fine license-wise |
| 12:31.40 |
d-lo |
yeah, neon =
Library GPL |
| 12:32.20 |
brlcad |
note that's
just what they call it :) |
| 12:32.31 |
brlcad |
lots of folks
were pissed by fsf trying that |
| 12:32.33 |
d-lo |
well, I am
going to double check since the dependancy chain is getting bigger
than I expected :/ |
| 12:32.45 |
CIA-40 |
BRL-CAD:
03starseeker * r34009 10/brlcad/trunk/src/other/step/conf/ (. MAJOR
MINOR PATCH): Ahem - as I was trying to do before the power went
out, add in conf so step configure has some version numbers to work
with. |
| 12:33.03 |
brlcad |
it's just
manipulative, trying to coerce based on the name
implications |
| 12:33.17 |
starseeker |
FSF is famous
for being manipulative |
| 12:33.29 |
d-lo |
right :) I
learned quickly to not trust the names, but, rather, read the fine
print. |
| 12:33.32 |
starseeker |
to be fair,
they are open about having a political agenda to push |
| 12:33.52 |
brlcad |
d-lo:
question earlier, perhaps lost during the irc reconnect -- curious
why you asked whether pkg managed connections? |
| 12:34.09 |
starseeker |
still steers clear of the GNU Free Documentation License -
that was a real let-down |
| 12:34.11 |
d-lo |
I will need
someone to sit down and show me more about the build system, aka
subbuilds and the NODIST stuff. |
| 12:35.06 |
d-lo |
brlcad: I
asked that because i couldn't remember if libpkg did the managing
or not. Wanted to make sure I wasn't missing something important
and running off to re-invent the wheel. |
| 12:38.44 |
brlcad |
d-lo:
brlcad/src/fbserv/fbserv.c is an example how the framebuffer server
handles multiple requests |
| 12:38.49 |
brlcad |
just keeps
the clients in an array |
| 12:38.54 |
brlcad |
simple easy
to grok |
| 12:39.42 |
brlcad |
support
interleaved requests and updates |
| 12:39.42 |
brlcad |
just a few
lines of code |
| 12:40.51 |
brlcad |
follow the
"clients" keyword and it should be relatively obviously |
| 12:45.21 |
d-lo |
pretty
sexy. |
| 12:46.11 |
CIA-40 |
BRL-CAD:
03starseeker * r34010 10/brlcad/trunk/src/other/step/ (3 files in 3
dirs): Add in some more headers to scl Makefile.ams |
| 12:48.14 |
brlcad |
starseeker:
when you get the chance, maybe try a distcheck on a fresh checkout
-- still getting failure notices since the addition |
| 12:49.25 |
brlcad |
and yeah, I
know -- I don't know why either, should be okay .. but it's not at
least accordingly to cruisecontrol |
| 12:49.36 |
brlcad |
and can't get
to log just yet |
| 12:54.30 |
brlcad |
hah, cute:
http://www.compasslearningodyssey.com/sample_act/math3_4/MA3CA05a-package_preloader.swf |
| 12:54.44 |
brlcad |
could do
something similar for the brl-cad primitives! |
| 12:55.29 |
starseeker |
brlcad: OK,
will do |
| 13:01.39 |
CIA-40 |
BRL-CAD:
03starseeker * r34011 10/brlcad/trunk/src/other/step/src/ (3 files
in 3 dirs): Oh, yeah - those include links shouldn't assume
in-source build |
| 13:02.17 |
starseeker |
starts distcheck running and starts prepping for the
road... |
| 13:06.03 |
``Erik_ |
*readreadread* |
| 13:06.39 |
d-lo |
eh? |
| 13:07.36 |
brlcad |
means he's
reading the backlog |
| 13:08.37 |
d-lo |
guess I am
not as fluent in l33tsp34k as I thought :/ |
| 13:10.30 |
``Erik_ |
z0mfglolf34d|ngl0gz0rz |
| 13:10.53 |
``Erik_ |
sorry, fit of
geek tourettes there O:-) |
| 13:10.54 |
brlcad |
lolomfgponies! |
| 13:11.08 |
``Erik_ |
l0llerk0pt0r |
| 13:11.59 |
``Erik_ |
um, direct
link to a file doesn't guarantee O(1), some fs's are not constant
in resolving the file name to the initial inode |
| 13:12.07 |
d-lo |
l0ll3rsk8t3s |
| 13:12.30 |
brlcad |
``Erik_: O(1)
to the app's logic, that's all we control |
| 13:12.35 |
``Erik_ |
(they tend to
be damn fast, but I had a directory with ~17k files and getting the
file handle took several seconds) |
| 13:13.09 |
brlcad |
just not from
a global view, sure |
| 13:13.43 |
d-lo |
question:
Does a linker error of: lib/libz.a(crc32.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared
object; recompile with -fPIC |
| 13:13.53 |
d-lo |
tell me that
its a 32 bit lib? |
| 13:13.55 |
``Erik_ |
*shrug* I
argue that it's important to understand and consider the limits of
the OS and hw, too, but *shrug* :) |
| 13:14.30 |
brlcad |
d-lo: not
necessarily |
| 13:14.50 |
brlcad |
``Erik_: uhm,
I'd generally think that goes without saying? |
| 13:14.51 |
``Erik_ |
-fPIC
instructs it to make position independant code, required for a
shared object |
| 13:15.26 |
brlcad |
mostly
because it ends up with a lot of navel gazing and speculative
jabber that isn't productive |
| 13:16.08 |
``Erik_ |
heh, 'cept
I've seen it come back to bite projects that worry about squeezing
performance |
| 13:16.19 |
brlcad |
so? |
| 13:16.32 |
brlcad |
"bad things
can happen" |
| 13:16.39 |
brlcad |
i don't find
that surprising |
| 13:16.53 |
d-lo |
-fPIC is a
compiler flag? |
| 13:16.57 |
brlcad |
yes |
| 13:17.06 |
d-lo |
kk
danke |
| 13:17.31 |
brlcad |
you shouldn't
have to add it on your code, though -- libtool handles
that |
| 13:17.42 |
``Erik_ |
*shrug* just
admitting that is taking it into consideration, knowing how to cope
with it is understanding those limits, otherwise you have stupid
code and people blaming the wrong things |
| 13:17.58 |
d-lo |
hrm, well I
am following the install directions to the letter and its giving me
that error |
| 13:18.35 |
brlcad |
``Erik_: this
is exactly the kind of speculative jabber that I mean, though --
it's not solving an actual problem |
| 13:18.37 |
``Erik_ |
all those
#include "../something" lines in teh step stuff, hope that doesn't
mess up too much |
| 13:19.13 |
brlcad |
if we
implemented ours via a given O(1) approach, and found an OS
problem, that would be an actual then that could be looked
into |
| 13:19.29 |
``Erik_ |
<-- just
trying to get his brain back into gear :) |
| 13:22.13 |
d-lo |
and stay
out! |
| 13:22.19 |
d-lo |
=D |
| 13:23.08 |
``Erik |
heh |
| 13:41.57 |
starseeker |
forgot how long a distcheck takes on this machine
:/ |
| 13:44.46 |
brlcad |
distcheck -j#
will work |
| 13:48.57 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 13:48.57 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 13:50.21 |
starseeker |
only has 2 cpus and they both seem to be working
:-( |
| 13:50.47 |
starseeker |
will probably upgrade in a year or two... |
| 13:50.54 |
starseeker |
tis getting
slow |
| 13:51.20 |
brlcad |
my trusty old
box takes a couple hours to distcheck now |
| 13:51.29 |
brlcad |
used to be
about an hour before opennurbs :) |
| 13:52.43 |
starseeker |
heh |
| 13:53.06 |
starseeker |
yeah, the two
sure ways to crush my box into performance hell are compiling KDE
and compiling Openoffice |
| 13:53.57 |
starseeker |
blinks |
| 13:54.10 |
starseeker |
distcheck
just passed on my machine: brlcad-7.14.5 archives ready for
distribution |
| 13:59.04 |
starseeker |
will try again when he gets in |
| 14:05.34 |
brlcad |
starseeker:
huh |
| 14:06.24 |
brlcad |
starseeker:
then maybe it's something wrong with the cruisecontrol script that
needs to get fixed |
| 14:07.11 |
brlcad |
maybe just
needs another configure.ac update or something to make it
reautogen |
| 14:15.14 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 14:15.14 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 14:26.29 |
d-lo |
I just priced
a Quad 3GHz AMD with 4GB 1033MHz ram on a MB with onboard nVidia
9600 and 8 channel audio machine (no case) for about $350 if you
DIY |
| 14:32.09 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:42.34 |
CIA-40 |
BRL-CAD:
03indianlarry * r34012 10/brlcad/trunk/src/ (libged/clone.c
tclscripts/mged/help.tcl): Added 'clone' to mged_help_data table
and added print_usage() when to few args |
| 14:56.03 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:01.12 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 15:26.13 |
madant |
hates namespaces |
| 15:26.43 |
namespaces |
hates madant. |
| 15:26.49 |
madant |
:P |
| 15:26.53 |
d-lo |
=D |
| 15:27.11 |
*** join/#brlcad ``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:50.34 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:52.58 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 15:54.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-91.sbndin.btas.verizon.net) |
| 16:05.06 |
CIA-40 |
BRL-CAD:
03homovulgaris * r34013 10/brlcad/trunk/src/other/boost/ (8 files
in 4 dirs): another boost update: spirit and phoenix
related |
| 16:10.17 |
CIA-40 |
BRL-CAD:
03homovulgaris * r34014 10/brlcad/trunk/src/libpc/ (7
files): |
| 16:10.17 |
CIA-40 |
BRL-CAD:
modifications for the usage of boost::spirit namespace instead
of |
| 16:10.17 |
CIA-40 |
BRL-CAD:
boost::spirit::classic, generic includes added to be replaced with
the specific |
| 16:10.19 |
CIA-40 |
BRL-CAD:
header files for the pertinent spirit and phoenix functions; also
code syntax |
| 16:10.21 |
CIA-40 |
BRL-CAD:
corrections in pcMathGrammar, pcMathLF and pcMathVM |
| 16:35.07 |
CIA-40 |
BRL-CAD:
03starseeker * r34015 10/brlcad/trunk/src/other/step/m4/prefix.m4:
Whoops - put the right prefix.m4 back |
| 16:42.25 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.92.168.117) |
| 17:05.36 |
CIA-40 |
BRL-CAD:
03starseeker * r34016 10/brlcad/trunk/src/other/step/ (11 files in
5 dirs): More step build tweaks. |
| 17:06.19 |
*** join/#brlcad _``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:16.12 |
CIA-40 |
BRL-CAD:
03starseeker * r34017 10/brlcad/trunk/src/other/step/ (configure.ac
include/Makefile.am include/conf/Makefile.am): Few more fixes for
step build system |
| 17:16.43 |
*** join/#brlcad __``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:37.43 |
CIA-40 |
BRL-CAD:
03starseeker * r34018
10/brlcad/trunk/src/other/step/include/conf/Makefile.am: One more
misc Makefile.am cleanup |
| 17:38.00 |
*** join/#brlcad ___``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:42.17 |
CIA-40 |
BRL-CAD:
03starseeker * r34019 10/brlcad/trunk/src/other/step/ (8 files in 3
dirs): Clean up old config stuff in step |
| 18:00.50 |
*** join/#brlcad madant
(n=madant@117.196.138.140) |
| 18:05.04 |
*** join/#brlcad rahul_cool
(i=3b5bc963@gateway/web/ajax/mibbit.com/x-d7cc2a6d35286a1e) |
| 18:05.32 |
rahul_cool |
hiiiii
all |
| 18:06.17 |
rahul_cool |
i wanna take
part in gsoc 2009 on the project "CSG ray-trace
optimizations".... |
| 18:06.25 |
rahul_cool |
can any one
help me...... |
| 18:07.02 |
*** join/#brlcad ___``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 18:13.44 |
brlcad |
rahul_cool:
if you have to ask for help, then maybe not -- that's not an easy
task :) |
| 18:14.04 |
brlcad |
also, note
that the suggested list for 2009 hasn't been uploaded
yet |
| 18:16.21 |
brlcad |
if you have a
more specific question, go ahead an ask |
| 18:21.32 |
starseeker |
``Erik:
Yeah, you called it |
| 18:22.34 |
starseeker |
hmm... |
| 18:22.38 |
starseeker |
actua..y... |
| 18:43.08 |
starseeker |
grr the
express.h include references most of the other express.h
files |
| 18:43.14 |
starseeker |
er express .
files |
| 18:43.24 |
starseeker |
express .h
files come on bz |
| 18:43.38 |
starseeker |
this thing is
so interrelated it's amazing |
| 18:47.30 |
brlcad |
it's common
to have an interface file like that referencing other header
files |
| 18:48.02 |
brlcad |
that's the
same for the opennurbs headers if you recall, started with
opennurbs.h, that just basically includes every other non-private
api header |
| 18:48.12 |
starseeker |
right |
| 18:48.32 |
starseeker |
now will move a bunch of headers AGAIN to include, but this
time in express, exppp, etc directories |
| 18:48.40 |
brlcad |
kinda what
I'd like to do with bu/bn/rt too, one bu.h header that isn't 10k
lines long |
| 18:48.59 |
brlcad |
instead
breaks up the api into logical sections and bu.h just includes
those various section headers |
| 18:49.12 |
starseeker |
do you want
express.h as a "toplevel" including all the other "express/*.h"
headers? |
| 18:49.20 |
brlcad |
how'd they do
it? |
| 18:49.41 |
starseeker |
<snort>
they stuffed all of them in express with the source
files |
| 18:49.48 |
brlcad |
sometimes
there's a good reason to not include *.h (especially if some are
private, but even for non-private) |
| 18:50.13 |
starseeker |
Oh, I'm only
going to move the ones either needed by express.h or explicitly
included by (e.g.) fedex_plus |
| 18:50.45 |
brlcad |
ah, for the
ones that you already determine are public |
| 18:50.49 |
starseeker |
right |
| 18:51.00 |
starseeker |
only putting
them in include or include/express if forced to |
| 18:51.01 |
brlcad |
then yeah,
could just include include/express/*.h |
| 18:51.11 |
brlcad |
though that
might be redundant |
| 18:51.20 |
brlcad |
if it's
hierarchical and not just two-level |
| 18:51.42 |
starseeker |
right now its
flat |
| 18:52.34 |
starseeker |
I was
thinking to stick all of 'em that are needed in include/express for
now, change the includes to "express/file.h", and sort it out later
if we want more structure |
| 18:55.07 |
brlcad |
why bother
changing the includes? |
| 18:55.14 |
brlcad |
just add
include/express to the cppflags |
| 18:55.39 |
starseeker |
Yeah, I guess
that will work |
| 18:55.54 |
starseeker |
doesn't like trusting flags, but supposes he
should |
| 19:12.02 |
starseeker |
brlcad: step
has a memory.h and so does /usr/include - which one wins if I
inclulde include/express ? |
| 19:17.46 |
brlcad |
as "memory.h"
it should select a -I directed path first before default system
include dirs |
| 19:18.52 |
brlcad |
as
<memory.h> it could be unreliable -- forget gcc's rules on
that |
| 19:19.09 |
brlcad |
think it
still means try system first |
| 19:19.18 |
starseeker |
k |
| 19:36.47 |
starseeker |
gah - the
yylineno issue is still there |
| 19:37.12 |
starseeker |
considers tearing hair out |
| 19:38.32 |
starseeker |
bison < 2
doesn't create it automatically, bison > 2 does |
| 19:38.49 |
starseeker |
can't find a way to conditionally create it (so
far) |
| 19:40.06 |
*** join/#brlcad madant_
(n=madant@117.196.128.161) |
| 19:40.10 |
CIA-40 |
BRL-CAD:
03starseeker * r34020 10/brlcad/trunk/src/other/step/ (60 files in
7 dirs): OK, one more time with the step include files. |
| 19:43.09 |
starseeker |
decides against tearing hair out and opts for
researching |
| 19:45.57 |
d-lo |
the girls
love bald..... |
| 19:47.37 |
starseeker |
mine
doesn't |
| 19:51.22 |
CIA-40 |
BRL-CAD:
03starseeker * r34021
10/brlcad/trunk/src/other/step/src/express/Makefile.am: OK, looks
like a flag may be needed for flex |
| 19:51.57 |
starseeker |
if that
works, I can undo the scary hack and slash renaming I did in
express |
| 20:07.39 |
``Erik |
comcast is
awesome! |
| 20:49.04 |
PrezKennedyJR |
snap out of
it man! |
| 21:02.30 |
starseeker |
brlcad: Ah,
nuts. when running distcheck it claims the step directory is
already configured |
| 21:04.54 |
starseeker |
must have gotten too cute with the
configure.ac |
| 21:11.19 |
brlcad |
really should
probably start with enigma's more simple configure.ac
:) |
| 21:11.37 |
brlcad |
ours has all
sorts of automatic caching and various overrides |
| 21:11.58 |
brlcad |
some that
don't work without previous tests |
| 21:15.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-91.sbndin.btas.verizon.net) |
| 21:20.53 |
*** join/#brlcad cad14
(n=d41b3c30@bz.bzflag.bz) |
| 21:22.51 |
CIA-40 |
BRL-CAD:
03brlcad * r34022
10/brlcad/tags/rel-7-14-4/src/other/tk/unix/Makefile.in: temp
remove to replace with SHLIB_SUFFIX patched version |
| 21:23.18 |
CIA-40 |
BRL-CAD:
03brlcad * r34023
10/brlcad/tags/rel-7-14-4/src/other/tk/unix/Makefile.in: apply the
SHLIB_SUFFIX fix that lets it make the symlink/copy for m3
folks |
| 21:48.21 |
CIA-40 |
BRL-CAD:
03brlcad * r34024 10/brlcad/trunk/BUGS: dwayne reports that
rtwizard won't display line drawings for objects that are inside
other objects, like a vehicle with crew inside. select vehicle as
ghost, crew as solid, and crew as line. |
| 22:00.55 |
CIA-40 |
BRL-CAD:
03brlcad * r34025 10/brlcad/trunk/configure.ac: make a nop mod to
hopefully unstick cruisecontrol failures |
| 22:08.58 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 22:15.01 |
brlcad |
===
configuring in src/other/step
(/Volumes/wsbh/CI/projects/brlcad-trunk/work/src/other/step) |
| 22:15.05 |
brlcad |
configure:
running /bin/sh ./configure '--prefix=/usr/brlcad'
'--enable-symbols'
--cache-file=../../../config.cache.darwin9.6.0.pawl.arl.army.mil
--srcdir=. |
| 22:15.08 |
brlcad |
configuring
SCL 3.1.0 |
| 22:15.10 |
brlcad |
No
architecture info specified... specify the architecture directory
using --with-arch=specify-arch-directory-here |
| 22:15.14 |
brlcad |
configure:
error: ./configure failed for src/other/step |
| 22:16.17 |
brlcad |
that's what
it's presently erroring out on even after that last poke (and it's
disabled, so something is apparently wrong) |
| 22:16.30 |
brlcad |
(with the
cruisecontrol config) |
| 22:16.46 |
brlcad |
probably just
need to re-enable it and see if it'll work |
| 22:20.38 |
*** join/#brlcad cad99
(n=42ead11b@bz.bzflag.bz) |
| 22:24.52 |
*** join/#brlcad cad99
(n=42ead11b@bz.bzflag.bz) |
| 22:37.56 |
``Erik |
oh,
starseeker, check out "brlman rtarea", i'ts cool |
| 00:53.53 |
*** join/#brlcad cad00
(n=42ead11b@bz.bzflag.bz) |
| 00:56.00 |
``Erik |
huh, weird,
hulu changed their buffer display, now it almost looks like cell
phone bars |
| 01:38.00 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 01:42.34 |
starseeker |
``Erik:
yeah, awf isn't up to the new man output |
| 01:42.58 |
starseeker |
need to make
brlman a wrapper around man |
| 01:45.48 |
starseeker |
brlcad: the
--with-arch arg requirement is from the original configure script
in the NIST distribution |
| 01:45.55 |
starseeker |
it shouldn't
be present any more |
| 01:46.22 |
starseeker |
also, the new
configure scripts have 3.2.0 as the version |
| 01:50.39 |
starseeker |
I would
suggest clearing out the src/other/step subdirectory and checking
it out clean, if that's possible |
| 02:27.28 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 02:31.45 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:35.18 |
brlcad |
settles down with the best wings in
baltimore |
| 02:35.23 |
brlcad |
(thusfar) |
| 02:37.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 03:17.07 |
starseeker |
scowls at configure.ac... why are you breaking
distcheck? |
| 03:18.18 |
starseeker |
scripts a distcheck build to get full logging and sleeps on
it |
| 03:19.26 |
starseeker |
brlcad:
Would a configure.in file being checked in originally in
src/other/step cause problems with subsequent configure.ac builds,
even if removed from the repository? |
| 03:19.41 |
starseeker |
'cause
somehow it's getting the old build system |
| 04:03.18 |
brlcad |
starseeker: I
don't know, it could be some generated file like aclocal.m4 or
acinclude.m4 |
| 04:03.44 |
brlcad |
could be
somehow specific to the checkout it's working with, hard to say
without looking at the filesystem |
| 04:17.07 |
starseeker |
Uhhhh.
distcheck failed for me without involving step afaict: make[3]:
*** No rule to make target `unix/config.status', needed by
`distdir'. Stop. |
| 04:18.40 |
starseeker |
that was at
src/other/tcl |
| 04:32.10 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-ae684e13fc106687) |
| 04:37.20 |
``Erik |
so either add
tcl/unix/config.status to the repo or delete it form the
Maekfile.am |
| 04:42.56 |
starseeker |
but when/why
did it change? |
| 05:58.24 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.96.200.142) |
| 06:27.56 |
*** join/#brlcad Don_
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 06:29.28 |
*** join/#brlcad madant
(n=madant@117.196.145.129) |
| 07:15.36 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.96.46.229) |
| 07:23.09 |
*** join/#brlcad madant_
(n=madant@117.196.128.139) |
| 08:17.08 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 10:00.15 |
*** join/#brlcad ddreeves
(n=4382fd0e@bz.bzflag.bz) |
| 10:16.25 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 10:28.09 |
*** join/#brlcad dreeves__
(n=dreeves@67.130.253.14) |
| 10:47.28 |
brlcad |
starseeker:
something else is wrong |
| 10:47.45 |
brlcad |
there should
and needs to be a config.status (and it doesn't belong in the repo,
it's generated by configure) |
| 10:49.08 |
bjorkintosh |
goodness man,
do you sleep? |
| 10:49.13 |
brlcad |
don't know
why it'd be listed in tcl/tk's Makefile.am EXTRA_DIST, though, that
could be the problem |
| 10:51.05 |
brlcad |
bjorkintosh:
I try not to |
| 10:51.24 |
bjorkintosh |
makes
sense. |
| 10:51.24 |
brlcad |
it's a nasty
disease |
| 12:06.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 12:26.02 |
*** join/#brlcad madant
(n=madant@117.196.147.36) |
| 14:15.58 |
madant |
WILL test the MathVM today :P |
| 14:19.00 |
brlcad |
:) |
| 14:21.02 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 14:49.29 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 15:10.13 |
brlcad |
has the initial application in |
| 16:04.57 |
dreeves__ |
I don't know
if it is appropriate place for me to ask this but is there a
document with a little more detail about the approach if the new
gui and how it will tie in to the geometry service or is this
currently in the works. If so is it possible to get privy to those
discussions/work? |
| 16:25.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 16:58.03 |
brlcad |
dreeves__:
there are some other docs but much of it is very much a work in
progress |
| 16:58.30 |
brlcad |
the
discussions are intentionally supposed to be completely open so
you're more than welcome to join in |
| 16:58.59 |
brlcad |
some of them
happen here on irc, some on the channel, and alas some in person
for the few that can |
| 16:59.07 |
brlcad |
er, mailing
list too |
| 16:59.34 |
brlcad |
there are a
few docs and details on the wiki, and feel free to ask any
questions here or on the devel mailing list |
| 17:13.26 |
madant |
:) seems like
we are going to have a good number of applications this
summer |
| 17:54.38 |
brlcad |
any devs
present? starseeker? |
| 18:08.01 |
CIA-40 |
BRL-CAD:
03homovulgaris * r34026 10/brlcad/trunk/src/libpc/ (pcMathVM.cpp
pcMathVM.h): adding BranchNode definition and methods to
pcMathVM |
| 18:10.48 |
``Erik |
O.o |
| 18:11.45 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:14.06 |
starseeker |
here |
| 18:14.14 |
starseeker |
what's
up? |
| 18:15.03 |
starseeker |
scowls at configure.ac - why are you haulting when step has a
config.status file but not haulting when enigma has a config.status
file |
| 18:15.44 |
starseeker |
oh, I see -
it's in the tarball |
| 18:15.46 |
starseeker |
hmm |
| 18:16.21 |
brlcad |
http://socghop.appspot.com <--
log in, edit profile, create a link_id |
| 18:16.44 |
brlcad |
anyone
interested in mentoring gsoc this year if we're accepted needs to
do that |
| 18:18.30 |
starseeker |
brlcad: you
just use brlcad for your link_id? |
| 18:20.01 |
brlcad |
yep |
| 18:20.31 |
starseeker |
OK, I'm
in |
| 18:21.18 |
starseeker |
do I need to
associate myself with brlcad somehow? |
| 18:21.26 |
brlcad |
nope |
| 18:21.34 |
starseeker |
k |
| 18:21.36 |
brlcad |
just tell me
your id |
| 18:21.42 |
``Erik |
erikg |
| 18:21.42 |
starseeker |
link_id? |
| 18:23.56 |
``Erik |
heh 'do you
know what "irony" is?' 'is it like "stony" or "woody" but a lot
better to make swords out of?' |
| 18:24.25 |
starseeker |
well, irony
CAN cut... |
| 18:25.36 |
starseeker |
brlcad:
would it be OK to create a wiki page on brlcad with pdf versions of
some of the NIST publications on the step libs? so far total size
would < 5 megs total for the papers |
| 18:27.02 |
brlcad |
starseeker:
dont' see why not |
| 18:27.23 |
starseeker |
cool -
thanks. That way if the site goes byebye we still have the docs
too :-) |
| 18:27.56 |
``Erik |
could just
shove it in your public_html/ as a "personal page", as
well |
| 18:28.25 |
starseeker |
oh, sure.
But this way anyone wanting to do something with BRL-CAD + STEP
will find them |
| 18:28.39 |
starseeker |
my personal
site is just a grab bag ATM |
| 18:29.13 |
brlcad |
there needs
to be a brlcad.org/wiki/STEP page, maybe also a /wiki/STEP/NIST to
talk about that portion |
| 18:33.52 |
CIA-40 |
BRL-CAD:
03starseeker * r34027 10/brlcad/trunk/src/other/step/Makefile.am:
Oops, step's configure.ac should be in the DISTCLEANFILES
list. |
| 18:35.50 |
brlcad |
anything
received during checkout shouldn't be in
distcleanfiles... |
| 18:37.00 |
starseeker |
oh, really?
whoops - I guess enigma must generate it |
| 18:37.35 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34028 10/rtcmp/trunk/ (rt/rt.c rtcmp.h tri.c):
remove references to brlcad/machine.h. casting in ntohd/htond to
quell warnings. |
| 18:39.43 |
starseeker |
hmm, no
enigma's configure.ac is checked in... |
| 18:42.36 |
dreeves__ |
brlcad are
there any docs other than the 3 uml diagrams ? |
| 18:43.34 |
dreeves__ |
I have
searched the wiki and didn't locate anything else |
| 18:45.13 |
brlcad |
starseeker:
enigma lists *configure* in distcleanfiles, not
configure.ac |
| 18:45.18 |
brlcad |
you said
configure.ac |
| 18:45.18 |
starseeker |
ah |
| 18:45.22 |
starseeker |
whooops |
| 18:45.52 |
brlcad |
dreeves__:
yes there are, but did you have a particular question -- glad to
just explain things ;) |
| 18:47.24 |
starseeker |
smacks self upside the head |
| 18:47.41 |
CIA-40 |
BRL-CAD:
03starseeker * r34029 10/brlcad/trunk/src/other/step/Makefile.am:
Add configure to DISTCLEANFILES. Previous commit message was
incorrected - added configure.ac to EXTRA_DIST files, NOT
DISTCLEANFILES. |
| 18:48.14 |
dreeves__ |
I guess I'm
just toying with the idea of maybe getting involved in maybe
helping out with that.... Was really look to see if you had
mockups of what the new gui might look like with some possible
flows...Also was interested in how the gui would interact with the
service i.e. the gui knowing which parameters were editable or are
you all thinking that would be just built into the gui
itself |
| 18:49.38 |
dreeves__ |
I could
probably go on and on but I thought I would get educated with what
the team had done first before I just started hammering everyone
with a million questions |
| 18:49.45 |
brlcad |
dreeves__:
ah, then should definitely also take a look at this: |
| 18:50.01 |
brlcad |
http://brlcad.org/design/ |
| 18:50.10 |
dreeves__ |
cool |
| 18:50.11 |
dreeves__ |
thanks |
| 18:50.26 |
brlcad |
the gui link
in particular includes an extensive gui interaction
mock-up |
| 18:51.33 |
brlcad |
it was
intentionally made application agnostic and doesn't show CAD
interface aspects yet, but the same basic ideas of localized
modelessness, universal command access, pervasive drag and drop,
context panels, etc |
| 18:54.17 |
dreeves__ |
Just so I'm
clear this is intended to be an mged replacement
correct? |
| 18:59.09 |
brlcad |
long term,
yes |
| 18:59.34 |
dreeves__ |
umm what
would it be in the short term? |
| 18:59.50 |
dreeves__ |
or are you
just saying it would take a while to replace mged? |
| 19:00.34 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34030 10/rtcmp/trunk/rt/rt.c: comments to help
understand interface to librt |
| 19:00.56 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34031 10/rtcmp/trunk/ (adrt/adrt.c
configure.ac): updates to handle updated tie interface |
| 19:00.57 |
brlcad |
dreeves__:
the latter |
| 19:01.03 |
madant |
dreeves__ :
it would take a while |
| 19:01.06 |
madant |
oops
:D |
| 19:01.06 |
dreeves__ |
ah
ok |
| 19:01.46 |
brlcad |
dreeves__: so
if you're interested, here's the big picture as I see
it |
| 19:02.04 |
dreeves__ |
ok? |
| 19:02.05 |
CIA-40 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r1232 10/wiki/STEP: Need to make a step wiki page - just rough out
some categories for now - flesh out later |
| 19:02.48 |
brlcad |
mged's great
in many ways, *lots* of functionality, powerful interface, it's
been doing what it's doing forever but it's incredibly difficult to
learn and takes a long time to master |
| 19:03.19 |
brlcad |
that said, it
really is *filled* with functionality, hundreds of staff-years of
effort that would take even a big team many years to
replicate |
| 19:03.27 |
brlcad |
so we really
can't afford to do that |
| 19:03.56 |
brlcad |
on top of
that, there is a ton of other functionality in brl-cad that many
people don't know about or don't know how to use (the other 399
applications) |
| 19:04.30 |
brlcad |
basically,
our usability needs to improve in a major way |
| 19:04.48 |
brlcad |
but not such
that we just lose everything that has been invested, therein enters
LIBGED |
| 19:05.25 |
brlcad |
libged is a
refactoring project that has been going on for almost a year now to
take most of the best aspects of mged out of mged, and putting that
logic into a library so it can be more readily reused |
| 19:05.55 |
brlcad |
libged by
itself, though, obviously won't make usability any better, for that
we need a better gui |
| 19:06.37 |
brlcad |
on that front
enters a refactoring prototype that was started several years ago
-- archer; basically mged's gui rewritten but still using mged's
geometry management and command functionality under the
hood |
| 19:06.48 |
brlcad |
also enter
last year's gsoc project to start a completely new gui
interface |
| 19:07.38 |
brlcad |
what remains
is the infrastructure to tie the gui to the backend while also
pulling in "the rest" of brl-cad under that same
interface |
| 19:08.08 |
brlcad |
that is where
the geometry service and geometry engine are at, they tie the front
to the back |
| 19:09.31 |
brlcad |
the intent of
the geometry engine is to modularize the geometry management API,
provide better type encapsulation and geometry management features
similar to other CAD kernels like ACIS or Granite |
| 19:10.21 |
brlcad |
the geometry
engine basically wraps libbu, libbn, librt, libwdb, and the new
libged into a clean API |
| 19:10.31 |
dreeves__ |
Yeah I
grabbed the latest rt^3 package and got it to compile but seems
like all the apps are just outputting timing type of things I'm
sure I'm missing something but I didn't see any guis |
| 19:11.40 |
brlcad |
dreeves__:
the rt^3 module hasn't really been cleaned up and unified yet, so
you're sort of seeing a little of the gui work that happened during
gsoc, some of the GE work, and a lot of the GS work |
| 19:12.14 |
brlcad |
and the three
don't yet play with each other much given they're all being
developed in parallel |
| 19:12.23 |
dreeves__ |
oh ok that's
fine I just wanted to see what had been done so far |
| 19:12.30 |
brlcad |
(as they
really are three independent projects) |
| 19:12.37 |
dreeves__ |
ok |
| 19:13.31 |
dreeves__ |
I just
flipped through some of the gui design I take it that is more of a
concept type thing, survey of different style of guis if you
will |
| 19:13.37 |
brlcad |
so
project-wise related to improving the interface, there's BREP
support, LIBGED refactoring, GE design, GS implementation, and the
GUI itself |
| 19:14.02 |
brlcad |
dreeves__:
it's not a survey, it's an actual interaction prototype |
| 19:14.28 |
dreeves__ |
oh I must
doing something wrong I will go back and look at it
again |
| 19:14.40 |
brlcad |
what's
missing is how that would actually look and act with a 3D context,
geometry actions, object palettes, etc |
| 19:14.56 |
brlcad |
this:
http://brlcad.org/design/gui/ioe_proto_final.mov |
| 19:15.04 |
dreeves__ |
ok |
| 19:15.33 |
brlcad |
it is a
survey of different *interactions* you might encounter in the gui,
just not multiple guis |
| 19:16.33 |
brlcad |
the important
aspect is how tasks are managed, how contexts are managed, command
interaction, how the overall menu works, the clipboard,
etc |
| 19:17.09 |
madant |
dreeves__:
are u already an open source contributor ? |
| 19:17.57 |
dreeves__ |
no |
| 19:18.27 |
brlcad |
your name is
very familiar |
| 19:18.33 |
dreeves__ |
why am I
stepping on toes and just don't know it |
| 19:18.43 |
dreeves__ |
yes I use to
work at brl about 20 years ok |
| 19:18.44 |
dreeves__ |
ago |
| 19:18.55 |
brlcad |
yes, that
just clicked with me |
| 19:18.56 |
brlcad |
gsi |
| 19:19.01 |
madant |
:) |
| 19:19.03 |
dreeves__ |
yep |
| 19:20.10 |
brlcad |
that's very
interesting, for many reasons.. :) |
| 19:20.24 |
brlcad |
you still
coding these days? |
| 19:20.25 |
dreeves__ |
:) |
| 19:20.32 |
dreeves__ |
oh yeah very
much so |
| 19:20.52 |
dreeves__ |
just not open
source |
| 19:20.56 |
brlcad |
nods |
| 19:21.08 |
brlcad |
something you
maybe haven't seen: http://brlcad.org/BRL-CAD_Priorities.png |
| 19:21.20 |
madant |
:) 20+ years
omg .thats like awesome experience :) |
| 19:21.22 |
dreeves__ |
nope |
| 19:21.41 |
dreeves__ |
Yeah I loved
working on brlcad |
| 19:22.57 |
madant |
you must have
worked with Mike et al. ? :) |
| 19:23.10 |
dreeves__ |
I meet him a
few times |
| 19:23.42 |
brlcad |
dreeves__: I
take it you stay in touch with Harry, maybe some of the other guys
still out at apg? |
| 19:24.14 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-131.dclient.hispeed.ch) |
| 19:24.25 |
dreeves__ |
I remember
having a conversion with him when he was working NMG that was a
very interesting discussion |
| 19:24.57 |
brlcad |
you'll hear
much of the same still going on :) |
| 19:25.13 |
dreeves__ |
No Harry and
I sort of went our own ways... |
| 19:25.29 |
dreeves__ |
I miss Harry
will have to get that way to see him soon |
| 19:25.29 |
brlcad |
the BREP
effort under way is our #1 priority in many ways |
| 19:25.39 |
brlcad |
ah,
shame |
| 19:26.04 |
brlcad |
he's actually
one of the few I don't think I've had the pleasure of meeting
personally yet |
| 19:26.06 |
dreeves__ |
Are you
nugging me toward that? |
| 19:26.19 |
dreeves__ |
Have you an I
meet? |
| 19:26.45 |
brlcad |
don't think
so unless you've been over to see the CAD team |
| 19:27.03 |
dreeves__ |
Do you know
if Ed, Paul and Keith are still out there? |
| 19:27.06 |
brlcad |
(in the last
10 years or so) |
| 19:27.10 |
dreeves__ |
no |
| 19:27.24 |
dreeves__ |
i haven't
unfortunately |
| 19:27.25 |
brlcad |
ed is, he's
current acting team lead |
| 19:27.38 |
dreeves__ |
realllllly.... |
| 19:27.40 |
dreeves__ |
:) |
| 19:27.50 |
brlcad |
paul has been
promoted into managerial oblivion, no longer does anything
productive |
| 19:28.02 |
dreeves__ |
I really
liked working with him |
| 19:28.08 |
brlcad |
er, you mean
deitz or tanenbaum? |
| 19:28.21 |
brlcad |
well, same
holds for both I suppose :) |
| 19:28.23 |
dreeves__ |
deitz |
| 19:28.44 |
brlcad |
he's leads
one of the directorates |
| 19:29.06 |
dreeves__ |
I probably
shouldn't refer to him has Paul I suppose I don't mean any
disrespect |
| 19:29.21 |
brlcad |
nah, he's
still paul |
| 19:29.28 |
brlcad |
http://www.linkedin.com/pub/4/a19/206 |
| 19:30.09 |
dreeves__ |
Yeah I was
sure he was but I didn't want anyone on here to get the wrong
idea |
| 19:30.16 |
brlcad |
keith retired
and came back as a contractor, doesn't write code though -- still
does some modeling |
| 19:30.50 |
dreeves__ |
Yeah that is
mostly what he before he is awesome at the modeling
though |
| 19:32.28 |
brlcad |
dwayne kregel
is one of the best brl-cad modelers out there now, he's helped
inspire a lot of my ideas for things we need to work on |
| 19:32.47 |
dreeves__ |
So funny I
went to HS with him |
| 19:32.48 |
brlcad |
victor is
back and modeling again |
| 19:32.53 |
dreeves__ |
aberdeen |
| 19:33.08 |
brlcad |
yeah, I think
he told me that one |
| 19:33.12 |
brlcad |
*once |
| 19:33.22 |
brlcad |
big
D |
| 19:33.29 |
brlcad |
awesome
guy |
| 19:33.42 |
dreeves__ |
Yes he is a
very tall guy |
| 19:33.55 |
dreeves__ |
small world
though |
| 19:34.28 |
dreeves__ |
brlcad what
is your email? |
| 19:35.53 |
dreeves__ |
BTW I will
check out the priorities maybe I will redirect my energy a
little |
| 19:36.19 |
brlcad |
note that
those are open source priorities |
| 19:36.26 |
brlcad |
very close to
but not exactly the same as ARL priorities |
| 19:37.18 |
brlcad |
ARL funds the
cad team in more specific ways obviously to work on
enhancements |
| 19:38.06 |
brlcad |
thinks who else gsiwise is still around |
| 19:38.21 |
brlcad |
adam |
| 19:41.42 |
dreeves__ |
adam came on
after I left |
| 19:42.12 |
brlcad |
ah |
| 19:43.40 |
brlcad |
there's
another guy but I can't remember his name |
| 19:46.12 |
brlcad |
probably a
few names you recognize:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/AUTHORS |
| 19:46.37 |
dreeves__ |
so does your
cad team basically work at what use to be brl? |
| 19:46.53 |
dreeves__ |
I thought Lee
Butler lead the cad team did he leave? |
| 19:47.05 |
brlcad |
he
left |
| 19:47.23 |
dreeves__ |
Yeah I wend
through that list the other night know quite a few people on
it |
| 19:48.21 |
brlcad |
Lee is still
around, but he went to work on his phd for a year then came back to
lead the modeling team and just recently moved onto another
team |
| 19:48.58 |
dreeves__ |
oh
ok |
| 19:49.00 |
brlcad |
still at the
same place, maybe even the same building |
| 19:49.17 |
dreeves__ |
I will have
to send ed and email |
| 19:49.34 |
brlcad |
he knows
:) |
| 19:49.40 |
dreeves__ |
ok |
| 19:49.44 |
dreeves__ |
:) |
| 19:49.50 |
dreeves__ |
What does he
think? |
| 19:53.59 |
brlcad |
he thinks
he's ready to retire :) |
| 19:54.23 |
dreeves__ |
LOL!!
:) |
| 19:55.40 |
dreeves__ |
So what's up
with the work on Java? |
| 19:56.27 |
brlcad |
wonders if dreeves__ notices that he has other messages..
:) |
| 19:56.47 |
brlcad |
john anderson
started that just playing around a couple years ago |
| 19:56.54 |
brlcad |
s/couple/many/ |
| 19:57.11 |
brlcad |
got a simple
ray query working, and it sat for a while |
| 19:57.39 |
brlcad |
then another
big java project started at arl, and it revived some attention on
that project |
| 19:57.44 |
dreeves__ |
Just noticed
sorry |
| 20:47.13 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:49.13 |
ysselive |
dreeves__:
btw, more you may not have seen -- screenie of the "Archer"
prototype interface I mentioned -- http://brlcad.org/tmp/archer.png |
| 20:49.26 |
ysselive |
Archer is the
test bed for most of the LIBGED refactoring |
| 20:49.59 |
ysselive |
and will
likely merge with MGED at some point (replacing mged's gui) as an
intermediate step until the other new GUI is ready |
| 20:56.21 |
MrStayPuft |
dreeves__:
another one of interest: http://brlcad.org/tmp/brepstep.jpg |
| 21:05.18 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 21:06.10 |
CIA-40 |
BRL-CAD:
03starseeker * r34032 10/brlcad/trunk/src/other/step/ (Makefile.am
autogen.sh): Don't need autogen.sh in this directory while step is
acting as a part of brlcad |
| 21:12.40 |
brlcad |
gets the munchies |
| 21:17.59 |
``Erik |
wonders if that was staypuft or staypuffed
O.o |
| 21:18.10 |
starseeker |
brlcad:
config.status is in both EXTRA_DIST and DISTCLEANFILES in the tcl
Makefile.am - is that intentional? |
| 21:18.57 |
brlcad |
it's mr stay
puft |
| 21:19.00 |
brlcad |
http://en.wikipedia.org/wiki/Stay_Puft_Marshmallow_Man |
| 21:19.16 |
brlcad |
starseeker:
probably not |
| 21:19.38 |
``Erik |
someone has
stayed up too late to catch the lame joke :D |
| 21:19.48 |
brlcad |
not that they
have much to do with each other .. being a distcleanfile doesn't
mean it'll be included in the dist |
| 21:19.56 |
starseeker |
right |
| 21:20.06 |
starseeker |
the failure
on distcheck has something to do with it though |
| 21:20.09 |
``Erik |
$16k for a
windows machine, ow |
| 21:20.23 |
brlcad |
``Erik: or I
didn't stay up late enough? puffing glue? |
| 21:20.38 |
brlcad |
puffing a
joint? |
| 21:20.43 |
``Erik |
the latter,
yeah |
| 21:20.46 |
brlcad |
ah |
| 21:20.49 |
brlcad |
then I caught
it |
| 21:20.54 |
brlcad |
just wasn't
funny :) |
| 21:21.07 |
``Erik |
<-- said
it was lame, not funny :D |
| 21:21.11 |
brlcad |
hehe |
| 21:21.32 |
``Erik |
has mysql and apache22 running on the new machine,
btw |
| 21:22.26 |
starseeker |
brlcad: Any
prior knowledge of the stepmod project on sourceforge? |
| 21:24.17 |
starseeker |
Hmm, cool,
NIST made some code for controlling a machining center using the
STEP-NC spec |
| 21:24.28 |
brlcad |
starseeker:
yeah, prior guilty knowledge, yes |
| 21:24.33 |
starseeker |
heh |
| 21:24.42 |
starseeker |
anything
useful there? |
| 21:26.57 |
brlcad |
probably, but
it was heavily biased towards lifecycle aspects of step |
| 21:27.12 |
brlcad |
MUCH of step
has little/nothing to do with geometry |
| 21:27.41 |
brlcad |
hinted at by
geometry starting at application protocol two *hundred* and three
.. |
| 21:28.05 |
CIA-40 |
BRL-CAD:
03homovulgaris * r34033 10/brlcad/trunk/src/libpc/pcMathGrammar.h:
Complete description of the Expression Grammar : Stage
1/4 |
| 21:28.11 |
brlcad |
~madant++ |
| 21:28.59 |
starseeker |
hmm - looks
like we're not the only ones playing around with NIST SCL:
http://code.google.com/p/fbics/ |
| 21:29.02 |
brlcad |
starseeker:
one interesting piece they do is ap28 though .. that didn't exist
until recently |
| 21:29.07 |
madant |
huh |
| 21:29.21 |
starseeker |
ah, nuts -
he's going GPLv3 |
| 21:29.25 |
brlcad |
(AP28 is
STEP-XML) |
| 21:29.30 |
starseeker |
ah, cool
:-) |
| 21:29.53 |
brlcad |
problem
there, though, being no CAD software dumps that out that I'm aware
of yet |
| 21:30.01 |
brlcad |
so not a high
priority |
| 21:30.07 |
starseeker |
true. |
| 21:30.24 |
brlcad |
still have to
deal with ap21 files |
| 21:30.27 |
starseeker |
ponders using it as a good BRL-CAD archival output format,
but that's also low priority... |
| 21:32.21 |
brlcad |
looks like
it's a new project |
| 21:32.30 |
brlcad |
there is no
code to it other than scl |
| 21:32.42 |
brlcad |
so you could
check it out and see what mods he's made |
| 21:33.05 |
starseeker |
maybe, but
since it's public domain code he's allowed to make his modes
GPLv3 |
| 21:33.10 |
brlcad |
wow, very new
.. last commit was just yesterday |
| 21:33.20 |
brlcad |
and that was
r2 |
| 21:33.29 |
starseeker |
could ask him, I suppose |
| 21:33.40 |
brlcad |
i mean he's
done nothing thusfar |
| 21:33.41 |
brlcad |
even to
scl |
| 21:33.46 |
starseeker |
ah,
ok |
| 21:34.21 |
starseeker |
can't find a license on the stepmod stuff |
| 21:35.27 |
evilcad |
there is no
stepmod stuff |
| 21:35.43 |
starseeker |
http://stepmod.cvs.sourceforge.net/stepmod/ |
| 21:35.44 |
evilcad |
he's not done
anything yet |
| 21:35.49 |
starseeker |
aj |
| 21:35.50 |
starseeker |
ah |
| 21:35.52 |
evilcad |
oh |
| 21:35.58 |
evilcad |
crossed the
streams |
| 21:36.01 |
evilcad |
meant
fbics |
| 21:36.08 |
starseeker |
and the
universe is destroyed! :-) |
| 21:36.25 |
evilcad |
i was told
it's a very bad thing to do |
| 21:44.56 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 21:47.11 |
starseeker |
grr - bad
project, publish licensing restrictions clearly |
| 21:51.38 |
starseeker |
Hey ``Erik:
http://sourceforge.net/projects/e7bfc/ |
| 21:52.15 |
starseeker |
windows only,
unfortunately |
| 22:05.22 |
CIA-40 |
BRL-CAD:
03starseeker * r34034 10/brlcad/trunk/src/other/ (tcl/Makefile.am
tk/Makefile.am): config.status doesn't belong in EXTRA_DIST, was
breaking make distcheck. |
| 22:21.39 |
starseeker |
confound
it |
| 22:23.59 |
starseeker |
the distcheck
tarball is pulling in expparse.c and expscan.c even though they are
included in DISTCLEANFILES in the Makefile.am! That's apparently
enough to stop bison from running, and since expparse.h is NOT
being snarfed in as well the build fails |
| 22:25.38 |
starseeker |
brlcad: I'm
not familiar yet with the distcheck rules for tarball building are
implemented - is there a chance that some stray cp *.c command in
there somewhere is pulling in files despite their being on the
DISTCLEAN list? |
| 22:42.19 |
*** join/#brlcad redvsblue
(n=blah@c-69-242-189-29.hsd1.mo.comcast.net) |
| 22:47.05 |
starseeker |
is forced to put it on hold |
| 22:52.58 |
``Erik |
nifty,
starseeker, but I chose bf as a minimal basis for a case study
:D |
| 22:53.18 |
``Erik |
at he moment,
I think I'm gonna check out clozure (for some reason, I had it and
clojure confused) |
| 23:11.35 |
evilcad |
starseeker:
again, being in distcleanfiles has nothing to do with being
included in the dist -- it's just a list of what to try to remove
if someone runs distclean |
| 23:12.23 |
evilcad |
those .c
files are included because they are either listed as extra_dist
and/or because it figured out that they need to be included because
they are .l/.y generated |
| 23:18.46 |
Ralith |
wonders what evilcad is eviling |
| 23:21.32 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1233
10/wiki/Google_Summer_of_Code/2009: New page: = Getting started =
Students participating with BRL-CAD in the 2008 GSoC have a
'''[[Google_Summer_of_Code/Checklist|checklist]]''' of actions to
attend to before getting started on thei... |
| 23:23.32 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1234
10/wiki/Google_Summer_of_Code/2009: |
| 23:28.43 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1236
10/wiki/Google_Summer_of_Code/2009: /* Additional Information
*/ |
| 23:28.44 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1235
10/wiki/Google_Summer_of_Code/2009: /* Additional Information
*/ |
| 23:33.57 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1237
10/wiki/Google_Summer_of_Code/2009/Project_Ideas: Redirecting to
[[Google Summer of Code/Project Ideas]] |
| 23:43.19 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1238
10/wiki/Google_Summer_of_Code/Project_Ideas: comment out a few to
reduce the list |
| 23:45.51 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1239
10/wiki/Google_Summer_of_Code/Project_Ideas: commenting out not
working so hot, just remove them and rely on revision
history |
| 23:50.08 |
brlcad |
Ralith: heh,
just evil craziness in another channel :) |
| 23:51.21 |
Ralith |
oo, SoC
infos |
| 23:51.31 |
``Erik |
uh huh,
rrrriiiiiggggghhhhhhtttttt |
| 23:52.30 |
``Erik |
ah HA, that's
where I stashed it *whew* |
| 23:52.53 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1240
10/wiki/Google_Summer_of_Code: update to 2009 |
| 23:52.57 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1241
10/wiki/Google_Summer_of_Code/2009: |
| 00:01.07 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1242
10/wiki/Google_Summer_of_Code/2008/Project_Ideas: add the ideas as
they ended for 2008, include a warning notice |
| 00:01.48 |
brlcad |
anyone wanna
make a poster? |
| 00:01.55 |
brlcad |
something
like http://brlcad.org/wiki/Image:Brlcad_gsoc2008_flyer.jpg |
| 00:02.04 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1243
10/wiki/Google_Summer_of_Code/2008: /* Additional Information */
refer to 2008 specifically |
| 00:02.28 |
brlcad |
complete
liberty to make it cool |
| 00:09.30 |
starseeker |
brlcad: Ah,
so anything .l or .y generated is supposed to be included in
generated form? |
| 00:09.40 |
starseeker |
that puts a
different slant on it |
| 00:11.47 |
brlcad |
starseeker:
possibly |
| 00:12.01 |
brlcad |
but actually,
I think it's saying that it's a BUILT_SOURCES makes it
included |
| 00:12.36 |
brlcad |
since you're
supposed to be able to build straight from a dist (at least that's
one of the schools of thought) |
| 00:13.19 |
brlcad |
either way,
it's probably some _SOURCES decl that makes it be
included |
| 00:15.13 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1244
10/wiki/Google_Summer_of_Code: clean up the preamble |
| 00:16.14 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1245
10/wiki/Google_Summer_of_Code: /* Getting Started */ smaller image
since it's now out of date |
| 00:18.45 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1246
10/wiki/Google_Summer_of_Code/Acceptance: /* Assign copyright and
license under the LGPL */ |
| 00:21.39 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1247
10/wiki/Google_Summer_of_Code: /* Getting Started */ |
| 00:29.18 |
``Erik |
I'll
participate in braintorming and critique, but I claim no ability in
visual creativity |
| 00:29.37 |
``Erik |
if'n you're
talking code or music, ... :D |
| 00:36.08 |
starseeker |
brlcad:
Except expparse.h is in BUILT_SOURCES, and doesn't seem to get
included |
| 00:36.17 |
starseeker |
sticks it in EXTRA_DIST and tries again |
| 00:38.26 |
madant |
brlcad: which
program was used for last flyer ? |
| 00:40.56 |
brlcad |
starseeker:
ah, hm, maybe put BUILT_SOURCES in EXTRA_DIST |
| 00:41.08 |
brlcad |
madant: mm,
don't recall |
| 00:41.36 |
brlcad |
probably
Pages |
| 00:41.57 |
madant |
yeah the
header says Photoshop :) |
| 00:42.25 |
brlcad |
ah, could
have been just that too |
| 00:43.11 |
``Erik |
how does it
say photoshop? could it be that pages output a semi-photoshopis
header to attempt to force compatability? |
| 00:43.40 |
``Erik |
mebbe even as
much as spoofing client, like opera can do for web stuff? :D just
random blabbering here, hain't looked into it myself |
| 00:44.12 |
brlcad |
nah, I
vaguely recall throwing it together quickly in PS |
| 00:44.33 |
``Erik |
okie |
| 00:44.42 |
brlcad |
doesn't take
much to whip together a flyer |
| 00:44.51 |
``Erik |
brlcad, do
you happen to recall the prices of the different long term parkings
at the airport? |
| 00:45.56 |
brlcad |
http://www.bwiairport.com/en/parking/information-rates |
| 00:46.24 |
``Erik |
so that's a
no. :) all heil google |
| 00:48.25 |
``Erik |
that's,
dude |
| 00:48.39 |
``Erik |
thanks,
even |
| 00:49.34 |
brlcad |
10/daily is
all i ever remember |
| 00:50.34 |
``Erik |
I think
park&ride is about there |
| 00:51.02 |
``Erik |
I think I
like the notion of having to present a ticket for them to let you
on the lot and stuff more than the automated garage |
| 00:51.07 |
``Erik |
at the loss
of overhead protection |
| 00:53.09 |
brlcad |
riight,
having some dude making minimum wage take a ticket from you makes
it more safe than a security patrolled garage with
cameras |
| 00:53.53 |
``Erik |
heh |
| 00:54.01 |
starseeker |
regrets not having before and after pictures of Sean with his
old/new cars |
| 00:54.36 |
``Erik |
minimum wage
dudes walking the garages and watching the cameras |
| 00:54.46 |
``Erik |
with no
notion of needing a ticket to get to your car |
| 00:54.58 |
brlcad |
airport
staff |
| 00:55.01 |
brlcad |
they're
unionized |
| 00:55.17 |
``Erik |
I might do
that |
| 00:56.04 |
``Erik |
last time I
left it in the park&go thingy, came back with a bmw on one side
and an mb on the other, I d'no, mebbe some fucktard in a lumina
might park next to me and bang my door up *cough*
*duck* |
| 00:56.07 |
``Erik |
I guess I'll
wing it :D |
| 00:56.31 |
``Erik |
*shrug* in
the end, it's just a car, 60k o not |
| 00:56.41 |
``Erik |
I'll stop
being a ginormous varginer now |
| 00:59.13 |
starseeker |
brlcad: Any
preferencs for visuals on the poster? |
| 00:59.25 |
brlcad |
starseeker:
nope |
| 00:59.44 |
starseeker |
hmm. |
| 01:00.22 |
brlcad |
you can see
what other orgs have done on the site for previous
years |
| 01:00.43 |
``Erik |
wait,
no |
| 01:00.47 |
``Erik |
there is a
preference |
| 01:00.49 |
``Erik |
we prefer
awesome |
| 01:01.08 |
brlcad |
http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers |
| 01:01.25 |
starseeker |
``Erik:
well, so much for me doing it then :-P |
| 01:01.38 |
``Erik |
iirc, our
last had a 3 panel corner with a sphflake in it |
| 01:02.18 |
``Erik |
in fact, is
it acceptable to adjust the dates and stuff on the old poster and
re-use it? |
| 01:02.31 |
brlcad |
should use
the 2009 logo/info |
| 01:02.41 |
``Erik |
ah |
| 01:08.20 |
brlcad |
bz's last
year was awesome, probably the best to date of all orgs |
| 01:11.07 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 01:12.49 |
``Erik |
punker is
dj'ing, http://troubleradio.net/ |
| 01:38.22 |
redvsblue |
:D |
| 02:43.03 |
yukonbob |
bzflag poster
-is- cool ;) |
| 02:48.58 |
starseeker |
has fun with gimp: http://bzflag.bz/~starseeker/concept_to_reality.png |
| 02:50.04 |
brlcad |
starseeker:
nice picture |
| 02:53.27 |
``Erik |
huh, olmos
has put on quite a gut |
| 03:07.15 |
*** join/#brlcad Briggs_
(n=chatzill@adsl-70-238-171-170.dsl.stlsmo.sbcglobal.net) |
| 03:07.36 |
Briggs_ |
I had a quick
question about NMG and booleans in BRL CAD.... |
| 03:07.50 |
Briggs_ |
does NMG
support boolean operations between two NMG structures
directly? |
| 03:08.02 |
brlcad |
yep |
| 03:08.20 |
Briggs_ |
brlcad: ahhh
great. |
| 03:08.31 |
brlcad |
nmg_evaluate_boolean() |
| 03:08.52 |
Briggs_ |
so it should
be possible to get untesselated version of these NMG structures and
translate into another n-gon structure. |
| 03:09.58 |
brlcad |
that's
exactly what it does |
| 03:10.08 |
Briggs_ |
brlcad: thank
you so much :) |
| 03:10.29 |
Briggs_ |
brlcad: any
comments on the robustness of BRL CADS implementation of booleans
on NMG structures? |
| 03:10.30 |
brlcad |
there's a
handful of funcs, nmg_bool(), nmg_do_bool(), |
| 03:12.01 |
Briggs_ |
one other
question, does NMG have any utility functions for building a NMG
from a 'polygon soup'/much more primitive data? |
| 03:12.22 |
brlcad |
the lib is
pretty robust for 99.9% of models, but there are plenty of
numerical issues that can arise |
| 03:12.37 |
brlcad |
particularly
if you're evaluating degenerate or invalid geometry |
| 03:12.48 |
*** join/#brlcad joeedh
(n=chatzill@208.187.196.98) |
| 03:13.15 |
brlcad |
plus there
are tolerance structures that you provide that will heavily affect
an evaluation |
| 03:13.49 |
brlcad |
(e.g., set a
horribly low tolerance and you end up evaluating degenerate
cases) |
| 03:14.57 |
brlcad |
as for a
utility functions to build up from polygon soup .. probably .. but
would have to dig around |
| 03:16.06 |
brlcad |
looking at
the importers (src/conv) would probably be a reasonable starting
point or straight to the nmg funcs (in src/librt and
src/librt/primitives/nmg) |
| 03:16.33 |
Briggs_ |
brlcad: yeah
I figured I might just modify an importer that exists. |
| 03:17.02 |
brlcad |
if it turns
out there isn't something, would be a great addition to
make |
| 03:17.04 |
Briggs_ |
brlcad: the
biggest difference between my representation and NMG is I dont
store shell/region info. |
| 03:17.30 |
Briggs_ |
so I just
worry about being able to derive that succesfully. |
| 03:17.41 |
brlcad |
nods |
| 03:18.41 |
Ralith |
starseeker:
neat! |
| 03:18.44 |
joeedh |
how would you
pass data back? |
| 03:19.17 |
Briggs_ |
convert back
from the NMG structure. |
| 03:19.23 |
Briggs_ |
thats
probably the easiest part actually. |
| 03:19.57 |
joeedh |
is confused; he thought people told him earlier this would
only work on triangulated datasets |
| 03:20.23 |
joeedh |
so I guess
I'm wondering if it passes back triangulated data |
| 03:20.27 |
Briggs_ |
joeedh: did
they say 'triangulated' or 'tesselated'... I think in BRL-CAD world
there is a difference. |
| 03:20.44 |
Briggs_ |
'tesselated'
dataset == explicit BREP reprenseation of a CSG
primitive |
| 03:20.44 |
joeedh |
vaguely remembers both, isn't sure though |
| 03:20.51 |
Briggs_ |
that doenst
mean triangulated nessecarilly |
| 03:20.58 |
Briggs_ |
(or at least
thats the impression I got from reading the docs) |
| 03:21.30 |
brlcad |
yeah,
triangulated implies .. triangles |
| 03:21.40 |
brlcad |
the nmg lib
deals with arbitrary polygons |
| 03:21.55 |
joeedh |
right. |
| 03:22.05 |
brlcad |
if you only
want triangles, you can use nmg |
| 03:22.10 |
brlcad |
or you can
use bots |
| 03:22.41 |
Briggs_ |
nah, we
definitely want polygons with interior bounded loops for holes as
option |
| 03:22.44 |
brlcad |
pretty simple
to turn an nmg into triangles |
| 03:23.26 |
joeedh |
how does it
handle data like uv textures, or vertex colors, attached to the
mesh? |
| 03:23.54 |
Briggs_ |
suspects thats probably not a concern for NMG... may have to
be extended. |
| 03:24.16 |
brlcad |
nmg
structures are purely geometric |
| 03:24.51 |
Briggs_ |
this sounds
like great starting point for what I want to use it for though
:) |
| 03:27.13 |
CIA-40 |
BRL-CAD:
03starseeker * r34035
10/brlcad/trunk/src/other/step/src/express/Makefile.am: Add
BUILT_SOURCES to EXTRA_DIST for step |
| 03:27.24 |
brlcad |
the
structures could be extended to include user data too |
| 03:29.52 |
joeedh |
yeah we'd
have to do that. |
| 03:30.10 |
Briggs_ |
I remember
looking at NMG code, its fairly straightforward. |
| 03:31.22 |
brlcad |
so what are
you guys working on? |
| 03:31.42 |
Briggs_ |
brlcad: we
are blender devs, working on the mesh system. |
| 03:31.51 |
Ralith |
the current
materials system can't handle UV maps? |
| 03:32.08 |
brlcad |
aha,
cool |
| 03:32.21 |
Briggs_ |
brlcad: I
wrote a non-manifold brep (not quite as heavy as NMG) and now that
we can do n-gons, I really wanted to look at having booleans that
dont stink |
| 03:32.22 |
Ralith |
Briggs_: oo,
neat! |
| 03:32.32 |
Briggs_ |
brlcad:
joeedh here is working on finishing up the API for the
brep/kernel. |
| 03:32.42 |
Ralith |
having high
quality blender i/o to BRL-CAD would be awesome. |
| 03:33.35 |
Briggs_ |
Ralith:
:) |
| 03:34.05 |
Ralith |
playing with
blender was my first foray into computer
graphics/modeling |
| 03:34.23 |
Briggs_ |
its come a
long way! |
| 03:34.31 |
joeedh |
yeah it
really has |
| 03:34.46 |
Ralith |
yup |
| 03:35.42 |
joeedh |
btw, does
brl-cad have code to triangulate arbritrary complex
polygons? |
| 03:35.50 |
brlcad |
Briggs_:
perhaps interesting to know that comprehensive brep support
(including nurbs) is one of our current development
priorities |
| 03:36.11 |
brlcad |
one of the
later tasks for next year include implementing (spline surface)
brep on brep CSG evaluation |
| 03:36.19 |
Briggs_ |
brlcad: ahhh
thats very nice. |
| 03:36.39 |
brlcad |
presently
working on high performance ray trace evaluation and conversion
support (step) |
| 03:36.47 |
Briggs_ |
brlcad: I
actually originally looked at the NMG source when designing the new
blender mesh kernel and I noticed that there were already pointers
in the NMG structs to data like that which were not
used. |
| 03:37.04 |
Briggs_ |
or didn't
seem to be used yet. |
| 03:38.01 |
brlcad |
joeedh:
yes |
| 03:38.14 |
brlcad |
check out
src/librt/primitives/nmg/nmg_tri.c and nmg_misc.c |
| 03:38.20 |
joeedh |
ooh
cool |
| 03:39.21 |
Briggs_ |
Ralith:
something I thought would be interesting is to use blender as
interface to BRL-CAD CSG primitives/trees. |
| 03:39.33 |
brlcad |
believe it
does a slice n' dice to turn non-convex faces into workable
pieces |
| 03:40.04 |
brlcad |
Briggs_: you
recall which structure in question? |
| 03:40.20 |
brlcad |
I just looked
and didn't see a user data pointer like we usually have |
| 03:40.31 |
Ralith |
Briggs_: that
would be very nice; does the blender renderer handle that kind of
geometry? |
| 03:40.35 |
Ralith |
given
librt |
| 03:40.40 |
joeedh |
brlcad: this
looks a little like trapezoidal decomposition (from a quick look at
the code). does your version produce nice
tesselations? |
| 03:40.41 |
Briggs_ |
brlcad: it
was the edge(not edgeuse I think) that had pointer to curve
data. |
| 03:40.59 |
Briggs_ |
Ralith: no, I
would probably have to have it spit out an NMG. |
| 03:41.02 |
Briggs_ |
Ralith: and
then render that. |
| 03:41.17 |
Ralith |
Briggs_:
wouldn't that really kill quality on smooth surfaces?
:/ |
| 03:41.20 |
Briggs_ |
Ralith: which
isnt quite as 'cool'. |
| 03:41.23 |
Ralith |
not
nearly. |
| 03:41.24 |
Briggs_ |
yeah it would
:/ |
| 03:41.38 |
Ralith |
is that how
nurbs are implemented? |
| 03:41.45 |
Ralith |
convert to
mesh for render? |
| 03:41.49 |
Briggs_ |
blenders
nurbs are triangulated, yeah |
| 03:42.02 |
Briggs_ |
blenders
raytracer only understands a bag of triangles. |
| 03:42.14 |
Ralith |
too much work
to extent it? |
| 03:42.16 |
brlcad |
joeedh: not
nice according to recent research measures, but certainly good
enough for most purposes -- it depends |
| 03:42.34 |
Ralith |
I
mean |
| 03:42.39 |
Ralith |
you could
just call librt for raycasting |
| 03:42.42 |
joeedh |
<PROTECTED> |
| 03:42.51 |
Ralith |
so it might
not be too much work |
| 03:42.59 |
Briggs_ |
joeedh: you
mean scanfill? |
| 03:42.59 |
joeedh |
we
implemented an ear clipper tesselator, which produces nice
tesselations but is kindof slow. |
| 03:43.03 |
joeedh |
yeah |
| 03:43.16 |
Briggs_ |
joeedh:
quality is not an issue for drawing, but for
conversion. |
| 03:43.34 |
Briggs_ |
well I guess
renderer we woudl want nicer quality.... |
| 03:43.43 |
brlcad |
Briggs_: hm,
curve data sounds like spline data, not material
informaiton |
| 03:44.39 |
Ralith |
Briggs_: I
don't know much about raytracer design, let alone blender's
implementation, but it seems like librt will do the hard bits for
you. |
| 03:44.41 |
Briggs_ |
brlcad:
sorry, I think we are geting two seperate lines of conversation
mixed up :) |
| 03:45.04 |
Briggs_ |
Ralith:
possibly, it becomes a more difficult problem when you factor in 3d
procredural textures/ect I think. |
| 03:45.34 |
Ralith |
hm, it might
be an interesting study to see if using librt in other cases too
would speed the renderer up. |
| 03:45.40 |
Ralith |
BRL-CAD is
very heavily optimised. |
| 03:46.15 |
Ralith |
yeah, I
thought there'd be more to it, but I would hope that the renderer
was designed to be extensible. |
| 03:46.15 |
Briggs_ |
brlcad: when
I said that there were some unused pointers I saw in NMG last time
I looked I was commenting on the fact that you are not invetigating
comprehensive brep support |
| 03:46.25 |
Briggs_ |
Ralith:
blenders renderer? |
| 03:46.27 |
Ralith |
yeah |
| 03:46.33 |
Briggs_ |
Ralith: not
really :) |
| 03:46.34 |
Ralith |
Briggs_:
actually, comprehensive brep support is WIP right now. |
| 03:46.36 |
Ralith |
oh. |
| 03:46.38 |
Ralith |
that's a
shame. |
| 03:46.51 |
Ralith |
I wonders,
does yafray support CSG? |
| 03:46.53 |
Briggs_ |
brlcad: are
'now' investigating even... not 'not'. |
| 03:47.27 |
joeedh |
Ralith: I
don't think so. |
| 03:47.29 |
Briggs_ |
Ralith:
blenders renderer was originally probably written to work 'just
enough' for the productions that they did when it was just an in
house tool |
| 03:47.55 |
Ralith |
Briggs_:
thought that might be the case, but it seems like it's been
extended an awful lot since then |
| 03:47.56 |
joeedh |
well it's
been heavily refactored since then. though some of the ore evil
optimizations remain,ger. |
| 03:48.13 |
joeedh |
it's still a
production tool first though :) so not the best thing in the
world |
| 03:48.24 |
joeedh |
ore ==
more |
| 03:49.28 |
Briggs_ |
Ralith: yeah,
but I think once again these things are just 'bolted on' to serve
some immediate need. |
| 03:49.39 |
brlcad |
more
specifically, comprehensive nurbs/brep support is what's presently
a work in progress -- we have an old nurbs implementation from a
long time ago but are now working on a completely new
implementation using new research (starting from rt06) |
| 03:50.05 |
Briggs_ |
brlcad: ahh
ok. |
| 03:50.09 |
Ralith |
this is why I
love the BRL-CAD project; simultaneously ancient and cutting
edge. |
| 03:50.23 |
brlcad |
as for "brep"
support, technically nmgs fit that bill (and the old nurbs
implementation uses the nmg structures for the topological
structure) |
| 03:51.03 |
brlcad |
but they're
much more heavily used as a polygonal structure as you've
noticed |
| 03:51.07 |
brlcad |
(nmgs) |
| 03:53.50 |
Briggs_ |
right. |
| 03:58.28 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.4 posted this weekend (20080313) || GSoC 2009
Begins! |
| 04:15.34 |
Axman6 |
Release
7.14.4 posted this weekend (20080313) ? |
| 04:15.44 |
Axman6 |
that's... a
little while ago right? |
| 04:30.26 |
brlcad |
heh |
| 04:30.45 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.4 posted this weekend (20090313) || GSoC 2009
Begins! |
| 04:37.10 |
Axman6 |
:) |
| 04:38.01 |
CIA-40 |
BRL-CAD:
03starseeker * r34036 10/brlcad/trunk/ (configure.ac
src/other/Makefile.am): |
| 04:38.01 |
CIA-40 |
BRL-CAD:
FINALLY - make distcheck passes with src/other/step added in. Need
to revisit |
| 04:38.01 |
CIA-40 |
BRL-CAD: the
handling of yylineno in express, but otherwise no major known
issues. Right |
| 04:38.01 |
CIA-40 |
BRL-CAD: now
no test logic is hooked up, and probably isn't needed for BRL-CAD
purposes. |
| 04:51.33 |
``Erik |
wow, why
didn't I notice that the first time... she's eating sushi the right
way |
| 04:51.41 |
``Erik |
bsg... with
her fingers O.o |
| 05:01.12 |
Axman6 |
what is the
right way to eat sushi? |
| 05:09.31 |
Axman6 |
pokes ``Erik in the sushi roll |
| 06:02.28 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 06:15.23 |
*** join/#brlcad Manjunath
(n=7aa7b3ec@bz.bzflag.bz) |
| 06:50.16 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-131.dclient.hispeed.ch) |
| 06:52.54 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.92.148.106) |
| 11:18.14 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1248
10/wiki/GSoC: create a shortcut |
| 11:27.47 |
brlcad |
starseeker:
hm, you made it harder for yourself trying to mix a white
background with a black background but it's certainly a
start |
| 11:29.20 |
brlcad |
I'd suggest
ditching the contrast, maybe just go with the tire taking up a
third of a page, then blend the logo into the opposite corner, then
use the remaining two corners for the info |
| 11:29.54 |
brlcad |
and you don't
need to make it speculative -- we'll know on monday |
| 11:30.01 |
brlcad |
dates are on
the timeline |
| 11:33.26 |
brlcad |
logo is here:
http://code.google.com/p/google-summer-of-code/downloads/list?can=2&q=logo+2009&colspec=Filename+Summary+Uploaded+Size+DownloadCount |
| 12:30.12 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:12.26 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 13:32.02 |
``Erik |
hrm |
| 13:34.12 |
``Erik |
_sushi_: I
was just cleaning up a directory, saw a file named 'thread.c' and
was trying to figure out if it was an experiment to test/break some
kernel threading capability, took me a bit to realize it was your
bolt generator... that's another reason for proper informative
comments (license, author, purpose) at the beginning of a source
file :D |
| 13:35.38 |
``Erik |
brlcad: bz
doesn't have any single player capability, does it? I'm preparing a
travel care package here :) |
| 13:35.58 |
brlcad |
it does, it's
just not fun |
| 13:36.11 |
brlcad |
you can start
your own server and play against bots |
| 13:36.25 |
brlcad |
good for
newbies, but gets old real fast |
| 13:36.29 |
``Erik |
hm |
| 13:36.43 |
``Erik |
I think I'd
rather hack code, then |
| 13:36.49 |
``Erik |
sounds like
weak bots |
| 13:38.01 |
``Erik |
uhm, I got
mysql and apache running, but I haven't tested anything. In all
likelyhood, a lot of the php pages will fail due to missing
dependancies |
| 13:38.25 |
brlcad |
they're
actually pretty good bots |
| 13:38.29 |
``Erik |
and for all I
know, none of the tables survived transport... a combination of
laziness and ethics prevents me from digging in |
| 13:38.34 |
brlcad |
especially
when they swarm you in numbers |
| 13:38.39 |
``Erik |
good
strategically, or technically? |
| 13:38.54 |
brlcad |
a little of
both |
| 13:38.56 |
``Erik |
I enjoy
sloppy but strategic bots, precise immediate bots are no
fun |
| 13:39.16 |
brlcad |
they lean
towards the latter slightly |
| 13:40.07 |
``Erik |
I think
starcraft was an excellent example of how to do them... they messed
up a lot, but the bot was reasonably forward thinking... definitely
not human class, but enough that appropriate strategy and tactics
were required to dominate :) |
| 13:40.32 |
``Erik |
quake style
aimbot things are just not fun :) |
| 13:40.50 |
``Erik |
will code, instaed |
| 13:40.53 |
``Erik |
instead |
| 13:41.26 |
``Erik |
mebbe look at
how libdm can be used for a 'rich' immediate display, for a public
adrt client |
| 13:41.39 |
``Erik |
provided the
battery holds out :/ |
| 13:41.42 |
brlcad |
that'd be
cool |
| 13:42.17 |
``Erik |
do you know
if they got rid of that 'no extra laptop battery on flights'
rule? |
| 13:42.51 |
``Erik |
(heh, or how
they'd react to bringing an extra laptop to circumvent that
fucktarded rule) |
| 13:42.52 |
*** join/#brlcad madant
(n=madant@117.196.141.189) |
| 13:42.53 |
brlcad |
I've never
stopped carrying two and never had a problem |
| 13:43.18 |
``Erik |
hm, was a
link on smacksnot, I might have to buy a second for my macbook,
even though I haven't gotten close to dead yet |
| 13:43.54 |
``Erik |
heh, mebbe
I'll look into that gimpy mouse behavior, or mebbe I'll just hack
lisp code so I can retire :D |
| 13:44.11 |
``Erik |
either way, I
won't be randomly jabbering on irc, so something good might happen
O:-) |
| 13:57.07 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:35.06 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 14:59.16 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:13.14 |
``Erik |
I LOVE
COMCAST! |
| 15:13.25 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.92.199.106) |
| 15:25.17 |
brlcad |
starseeker:
hmm, better blend of the two images with the tire and moko but
still several issues -- text needs a different font, would be nice
to showcase tire better/bigger, bullets look cheesy (gov't is
already messing with ya, eh?), url should be a one-liner, and the
gsoc logo image clashes (maybe make the entire footer that
color) |
| 15:28.20 |
``Erik |
heh |
| 15:28.41 |
``Erik |
:( I envy
you, the dirty reality of protecting you is fucking
brutal |
| 15:28.42 |
``Erik |
:( |
| 15:47.11 |
brlcad |
wonders what ``Erik is talking about |
| 15:49.22 |
brlcad |
btw, looks
like fancast only has some of hulu and other shows |
| 16:05.01 |
*** join/#brlcad hippieindamakin8
(n=hippiein@59.96.35.103) |
| 17:21.42 |
*** join/#brlcad andrecastelo
(n=chatzill@201008170151.user.veloxzone.com.br) |
| 17:34.33 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-23.dclient.hispeed.ch) |
| 17:45.07 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:12.25 |
*** join/#brlcad andrecastelo_
(n=chatzill@189.71.7.225) |
| 18:13.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 19:08.24 |
*** join/#brlcad madant_
(n=madant@117.196.130.247) |
| 19:12.01 |
CIA-40 |
BRL-CAD:
03brlcad * r34037 10/brlcad/trunk/src/other/step/src/ (4 files in 4
dirs): more distcheck fixes. few files missing from dist and a few
that can die with the old build system gone. |
| 19:31.16 |
bjorkintosh |
<PROTECTED> |
| 19:33.44 |
brlcad |
bjorkintosh:
kind of an open-ended question |
| 19:34.29 |
brlcad |
decent
content and animation modeler |
| 19:35.19 |
bjorkintosh |
have you used
it much? |
| 19:36.03 |
brlcad |
I've followed
and used blender long before it was ever open source |
| 19:36.40 |
bjorkintosh |
so how would
you compare it's purposes with brl cad's? |
| 19:36.41 |
brlcad |
more
following than using, and the little use I have had is quickly
forgotten |
| 19:36.47 |
bjorkintosh |
are they more
or less the same? |
| 19:36.55 |
bjorkintosh |
ah |
| 19:36.55 |
brlcad |
eh |
| 19:36.56 |
brlcad |
less |
| 19:37.13 |
brlcad |
it's like
comparing maya to catia |
| 19:37.25 |
bjorkintosh |
makes
sense. |
| 19:37.29 |
brlcad |
they have so
little to do with each other beyond the "it does
modeling" |
| 19:37.45 |
brlcad |
how they do
it and for what purposes and with what fidelity is completely
different |
| 19:37.56 |
brlcad |
the same
holds for brl-cad and blender |
| 19:38.23 |
brlcad |
blender would
make for a horrible cad system and we make for a horrible content
modeler |
| 19:39.04 |
brlcad |
and no, you
can't really do both -- the domains are massive and
separate |
| 20:13.55 |
Briggs_ |
nods |
| 20:14.09 |
Briggs_ |
blender would
stink at cad. |
| 20:15.38 |
Briggs_ |
although
there are some people who only use a small sub-set of what most CAD
systems provide and have been able to get by with doing just a
small bit of additional scripting/tools in Blender. |
| 20:21.40 |
yukonbob |
hello,
cadheads |
| 20:26.56 |
*** join/#brlcad madant_
(n=madant@117.196.129.16) |
| 20:55.56 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 21:04.38 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 21:08.18 |
starseeker |
invites someone else to attack the poster question - art
skills are not his forte |
| 21:08.45 |
starseeker |
will keep trying if he must, but the odds aren't promising
:-/ |
| 21:11.25 |
starseeker |
brlcad:
<snort> that logo would clash with anything |
| 21:13.00 |
starseeker |
contemplates distorting the logo... |
| 21:17.15 |
brlcad |
starseeker:
it's an improvement over the first, just still with some issues
:) |
| 21:17.48 |
brlcad |
the logo
clashes because it's free-floating and has a hard
corner |
| 21:18.03 |
starseeker |
ok, working
on that - give me a sec |
| 21:18.09 |
brlcad |
that top-left
has to "disappear" |
| 21:18.43 |
starseeker |
uh - the
tire? |
| 21:19.00 |
brlcad |
either as a
fade (which would be incredibly hard to do well) or as a footer or
corner or similar ornamentation |
| 21:19.04 |
madant_ |
where where
:) is the flyer ? |
| 21:19.09 |
brlcad |
no, the
top-left to the logo |
| 21:19.15 |
brlcad |
the tire
looks good |
| 21:19.23 |
brlcad |
should
emphasize it, make it bigger |
| 21:19.32 |
brlcad |
madant_: not
ready :) |
| 21:20.00 |
madant_ |
i meant is
the work in progress online ? :) |
| 21:20.49 |
madant_ |
does not like power outages |
| 21:22.15 |
starseeker |
ah |
| 21:25.33 |
starseeker |
brlcad: a
fade like this better? http://bzflag.bz/~starseeker/poster2a.png |
| 21:25.40 |
starseeker |
goes to get food |
| 21:29.44 |
brlcad |
yeah, that's
much better |
| 21:30.21 |
brlcad |
I made a
redirect if you want to shorten the url, http://brlcad.org/wiki/GSoC |
| 21:32.48 |
brlcad |
woot,
distcheck passes |
| 21:33.38 |
alex_joni |
brlcad:
started reading the HACKING page (following the GSoC link), and I
noticed a minor typo (incouraged vs. encouraged).. |
| 21:34.36 |
madant_ |
looks good ..
openmoko in the background ? |
| 21:35.24 |
alex_joni |
yeah, teh
flyer is nice .. the only thing I don't like about it is the GSoC
logo, but that's google's fault ;) |
| 21:35.47 |
madant_ |
yeah.. even
the t-shirt i got was childish :P with flowers :D |
| 22:41.08 |
CIA-40 |
BRL-CAD:
03brlcad * r34038 10/brlcad/trunk/HACKING: fix an incouraged typo
alex_joni noticed as well as a half-dozen others
noticed. |
| 22:42.36 |
brlcad |
thx
alex_joni |
| 23:26.23 |
bjorkintosh |
<PROTECTED> |
| 23:56.27 |
elite01 |
pervert
:( |
| 01:01.10 |
yukonbob |
brlcad: re:
gsoc -- we need to have a front-and-center permalink to the GSOC
wiki on the main website... |
| 01:01.39 |
yukonbob |
re: mentoring
-- I'd consider helping however I can... |
| 01:09.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 01:22.25 |
brlcad |
yukonbob: was
planning on adding a news item if we get accepted, but yeah, it
would be nice to have a better more visible link |
| 01:27.41 |
yukonbob |
nods... |
| 01:29.06 |
yukonbob |
brlcad: I'm
-=happy=- to help however I can, if you (or anybody else) thinks I
can assist. |
| 01:31.37 |
yukonbob |
my sched is
pretty booked, but, as I said, if I can help, let me know
how. |
| 01:31.51 |
yukonbob |
(re: booked
-- full time work :P ) |
| 01:36.24 |
yukonbob |
starseeker:
fwiw, I don't think the wheel should have the 'schematics' in the
background 'bleed-through' it; ie: turn the transparency in the
wheel assembly off. (on my $0.02). |
| 01:36.28 |
yukonbob |
*only
my |
| 01:41.55 |
starseeker |
brlcad:
sure, one sec |
| 01:42.35 |
starseeker |
yukonbob:
there are a few ways to do it - I was going for the "fade" from
design to reality |
| 01:42.52 |
yukonbob |
starseeker:
hi :) |
| 01:42.56 |
starseeker |
howdy
:-) |
| 01:43.13 |
yukonbob |
I see the
fade from wireframe -> "reality", and I like it. |
| 01:43.32 |
starseeker |
let me get
the core images up for brlcad quick |
| 01:43.33 |
yukonbob |
what I'm
talking about is the subtle "schematics" in the background showing
through the "real" rim |
| 01:43.51 |
starseeker |
you mean the
moko schematics? |
| 01:44.05 |
yukonbob |
I guess so
:) |
| 01:44.16 |
brlcad |
yukonbob: I'm
sure you can assist (e.g., could be a backup mentor again, could
work on that visible link) |
| 01:44.30 |
brlcad |
could also
work on the ideas page |
| 01:44.40 |
yukonbob |
hey brlcad
: |
| 01:44.43 |
yukonbob |
:) |
| 01:44.50 |
brlcad |
that needs to
be separated into two categories -- high priority and secondary (or
something similar) |
| 01:44.54 |
brlcad |
hi
:) |
| 01:45.33 |
brlcad |
also could
use some more items, few refactoring code cleanup tasks would be
good |
| 01:46.01 |
yukonbob |
would toss "convert bwish to a "standard wish/tlcsh loadable
module" |
| 01:46.04 |
yukonbob |
into that
list. |
| 01:46.22 |
yukonbob |
*wish/tclsh |
| 01:46.36 |
brlcad |
sure, go for
it |
| 01:49.17 |
starseeker |
brlcad: here
you go: http://bzflag.bz/~starseeker/gsoc/ |
| 01:50.13 |
starseeker |
let me know
if you want the non-transparent version of the tire |
| 02:03.57 |
yukonbob |
will add to
bwish to wiki list tonight, and look at organizing whole list...;
am now in transit. |
| 02:08.15 |
brlcad |
starseeker:
could use a bigger tire |
| 02:08.27 |
brlcad |
yukonbob:
cool, thx |
| 02:09.08 |
brlcad |
we have to
have the list finalized by noon (EDT) |
| 02:09.23 |
brlcad |
that's when
they'll review our app |
| 02:12.18 |
dreeves |
brlcad
looking at extrude.c in librt in the rt_extrude_shot function it
doesn't appear to ever free the memory for the normals that are
allocated in the FindRoots function... |
| 02:17.14 |
brlcad |
dreeves: not
surprising, that's a bit of code that is rarely ever
used |
| 02:17.28 |
brlcad |
it shouldn't
be allocating memory at all |
| 02:17.44 |
brlcad |
calling a
malloc in the middle of a ray shot is very bad |
| 02:17.46 |
dreeves |
Yeah that is
what I was looking into just to get my feet wet |
| 02:17.59 |
brlcad |
there's a
todo entry to make it work without alloc |
| 02:18.05 |
dreeves |
I saw that on
your list of things todo |
| 02:18.10 |
brlcad |
ah,
cool |
| 02:19.52 |
brlcad |
if anything,
it could batch them or preallocate during prep, but it really would
be best to avoid allocation altogether to compute the
roots |
| 02:20.32 |
brlcad |
and even
better still to get an arbitrary degree curve polynomial root
solver into libbn |
| 02:20.54 |
brlcad |
there is a
polynomial solver in libbn, but is compile-time wired to a given
max degree |
| 02:22.00 |
dreeves |
I was
thinking in the prep function |
| 02:22.44 |
dreeves |
I'm thinking
about it but seems like an arbitrary degree curve is what is
standing in the way of getting rid of the alloc's |
| 02:24.16 |
dreeves |
obviously but
I'm sure we once we know the degree of the curve we can pre
allocate the memory but the problem is management of that memory
that is what I'm working on right now |
| 02:24.52 |
dreeves |
I will go
check out libbn |
| 02:28.56 |
brlcad |
starseeker:
never mind, took care of it |
| 02:29.30 |
brlcad |
dreeves:
yeah |
| 02:32.42 |
brlcad |
also, the
solver in libbn probably isn't the right type or have the right
stability conditions -- would take a bit of testing to verify its
use |
| 02:38.10 |
dreeves |
Yeah I assume
you are talking about the root solvers in poly.c so yeah those seem
to be specialized cases of root finders not somuch I can adjust the
max degree then recompile...I was going to experiment with the test
case of the sketch to just call to that root finder vs the one
findroots just to see the impact on performance but that's ok I
think I can work with the find roots |
| 02:38.27 |
starseeker |
brlcad: just
resize, or re-render? |
| 02:38.42 |
brlcad |
starseeker:
never mind :) |
| 02:38.59 |
brlcad |
can you
repost your last version? |
| 02:44.29 |
starseeker |
of the
poster? uh, one sec... |
| 02:45.17 |
brlcad |
yeah |
| 02:46.43 |
starseeker |
http://bzflag.bz/~starseeker/gsoc/poster2a.png |
| 02:46.49 |
starseeker |
that
one? |
| 02:48.44 |
brlcad |
yep,
thanks |
| 02:57.28 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 03:34.55 |
brlcad |
how about
this? http://brlcad.org/~sean/tmp/brlcad_gsoc2009_poster.png |
| 03:47.06 |
*** join/#brlcad madant_
(n=madant@117.196.129.20) |
| 03:56.04 |
louipc |
looks
rustic |
| 04:11.54 |
starseeker |
brlcad:
font's a bit hard to read, but looks good |
| 04:13.25 |
brlcad |
starseeker:
which one? |
| 04:14.03 |
starseeker |
the
"Interested in 3D CAD Software?" one |
| 04:15.01 |
starseeker |
but obviously
my design chops are minimal - I would have cheerfully used the
previous fonts ;-) |
| 04:16.06 |
starseeker |
I don't know
how workable it is, but would it be possible to have an orange
"fill color" in the brlcad.org/wiki/gsoc link, to match the logo
next to it? |
| 04:18.20 |
brlcad |
nah, that's
good feedback |
| 04:18.33 |
brlcad |
had the same
inclination, but always good to hear it from others to
confirm |
| 04:18.50 |
brlcad |
that's the
point of getting a critique :) |
| 04:19.31 |
starseeker |
critiquing artwork probably comes under the "net negative
producer" you studied in that management class, as a rule
;-) |
| 04:19.41 |
brlcad |
heh |
| 04:20.04 |
starseeker |
's thought was that an "engineering" app should strive for a
crisp, clean look... |
| 04:20.23 |
starseeker |
unfortuantely
that's waaaay to easy to make into "default and boring" |
| 04:28.28 |
brlcad |
true, would
normally go for that, but then the logo becomes even more
distracting |
| 04:28.56 |
brlcad |
easier to
follow that style than fight it given it's so distinct |
| 04:31.50 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-ae59e4bdb9e611b6) |
| 04:40.40 |
starseeker |
fight the
good fight! ;-) |
| 04:47.50 |
brlcad |
http://brlcad.org/~sean/tmp/brlcad_gsoc2009_poster2.png |
| 05:01.12 |
starseeker |
yeah, that
works better :-) |
| 05:02.27 |
starseeker |
What do you
think about the Google Summer of Code 2009... paragraph? does it
need a non-white fill? I'm not sure, just asking |
| 05:21.15 |
brlcad |
hm, http://brlcad.org/~sean/tmp/brlcad_gsoc2009_poster3.png |
| 05:23.49 |
starseeker |
yeah, I like
that |
| 05:23.54 |
starseeker |
that one gets
my vote :-) |
| 05:25.12 |
starseeker |
brlcad:
should the color bar fade ins be parallel to the tire fade in, or
should the light sides be on the right? |
| 05:25.38 |
starseeker |
is wondering if the left side looks "washed out" if all the
fading is on that side |
| 05:25.56 |
starseeker |
would mean
the logo would be on the left though... |
| 05:25.58 |
starseeker |
hmm |
| 05:26.09 |
brlcad |
it washes out
if there's too much transparency |
| 05:26.23 |
brlcad |
and it's
unbalanced if it's just solid |
| 05:30.34 |
dreeves |
I got rid of
the memory allocation from the root find but it only increased the
speed by 30% is that what you would expect? or more
increase? |
| 05:30.56 |
starseeker |
yeah, I think
you've got it brlcad |
| 05:31.01 |
starseeker |
nice
job |
| 05:37.36 |
brlcad |
dreeves: I
would expect a fair bit more, but depends on how many bezier's are
in the sketch |
| 05:37.56 |
dreeves |
just
1 |
| 05:38.12 |
dreeves |
It's the
sketch you attached to the tracker |
| 05:41.00 |
yukonbob |
re: solid
block in gsoc poster vs. fading block (and text fill-colour): too
bad it's unbalanced... that block ("balance of poster" vs. text
readability) is at odds with itself... |
| 05:41.14 |
dreeves |
I just
focused on the root finder because I clocked it and it was taking
about 93% of the overall time to raytrace |
| 05:41.58 |
yukonbob |
brlcad: do
you have an example of the solid block, for comparison's
sake? |
| 05:42.39 |
yukonbob |
if they're
both (top and bottom) solid, does the poster look "out of
balance"? |
| 05:44.13 |
brlcad |
dreeves: 93%
sounds about right .. that's why I'd expect more than 30% if it
drops to near zero |
| 05:47.04 |
dreeves |
ok drilled
down into some of the funcs called from findRoots and noticed they
are allocing mem to |
| 05:47.10 |
dreeves |
will work on
those |
| 05:53.31 |
brlcad |
mallocs show
up as a real hot spot on the profiler if they occur during any
*_shot() evaluation (even once per ray) |
| 06:07.21 |
brlcad |
http://brlcad.org/~sean/tmp/brlcad_gsoc2009_poster4.png |
| 06:13.52 |
yukonbob |
brlcad: that
looks better, imo. Here's what else I'd consider: Make the wheel
assembly -not- transparent in any way; no 'bleeding' of the
schematic through the wheel; the wheel simply fades across itself
from wireframe to raytraced. The mask for the wheel is 100% (ie:
solid) for everything that describes the wheel, but nothing that's
blank. The bottom layer is the OpenMoko schematic, the middle layer
are the bars&text (solid, or at least |
| 06:15.23 |
yukonbob |
The net
effect would be the wheel covers everything, the bars are more
solid (making the text more readable), and the openmoko gfx is
showing in all other areas. |
| 06:15.53 |
yukonbob |
the mask for
the wheel could be the image of the wheel itself, with some hand
edits around the wireframe section on the left. |
| 06:17.02 |
yukonbob |
The mask
would be a completely solid blob... (ie: the holes in the rim would
show white, not openmoko gfx). |
| 06:19.19 |
yukonbob |
in fact... I
think I'd adjust the mask for the wireframe to move the visibility
left -- it looks like some of the wireframe hits the text in the
top bar |
| 06:20.49 |
yukonbob |
would install GIMP if he wasn't in middle of re-building
world |
| 06:20.59 |
yukonbob |
what's the
due-date for this poster? |
| 06:23.13 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 06:24.55 |
brlcad |
it's not
worth spending a whole lot more time on, frankly |
| 06:25.03 |
yukonbob |
hehe |
| 06:25.04 |
yukonbob |
:) |
| 06:25.07 |
brlcad |
but
technically, it's not "due" .. just good marketing |
| 06:25.13 |
brlcad |
after
acceptance |
| 06:28.06 |
yukonbob |
is GIMP
project? |
| 06:28.24 |
brlcad |
photoshop |
| 06:28.37 |
yukonbob |
ah |
| 06:28.51 |
yukonbob |
<-- not a photoshop person |
| 06:39.01 |
brlcad |
http://brlcad.org/~sean/tmp/brlcad_gsoc2009_poster5.png |
| 06:39.11 |
brlcad |
some of those
ideas |
| 06:40.43 |
brlcad |
not quite as
big a fan of the solid bars, though, fairly plain |
| 06:41.20 |
brlcad |
probably
would work with a really light gradient, but I think it's at a good
enough point for this year |
| 06:41.40 |
brlcad |
need to focus
on the ideas list |
| 06:46.44 |
yukonbob |
I think
you're right re: solid bars --- I like gradient in bottom bar of
poster4, though... |
| 06:47.03 |
yukonbob |
keeps text
more readable than other gradients. |
| 06:50.02 |
yukonbob |
Zzzzz |
| 06:52.08 |
brlcad |
agrees |
| 06:52.21 |
brlcad |
v4 it
is |
| 06:59.20 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 07:25.10 |
CIA-40 |
BRL-CAD:
03brlcad * r34041 10/brlcad/trunk/src/tclscripts/rtwizard/lib/
(MGEDpage.itk PictureTypeBase.itcl): |
| 07:25.10 |
CIA-40 |
BRL-CAD:
implement support to actually utilize the perspective mode setting
(apparently |
| 07:25.10 |
CIA-40 |
BRL-CAD: it
was never wired up). this makes it work though there is still some
quirk |
| 07:25.10 |
CIA-40 |
BRL-CAD:
where you sometimes need to display one of the other render 'steps'
so that it |
| 07:25.10 |
CIA-40 |
BRL-CAD:
finds the setting. |
| 07:27.29 |
CIA-40 |
BRL-CAD:
03brlcad * r34042 10/brlcad/trunk/NEWS: |
| 07:27.29 |
CIA-40 |
BRL-CAD:
implement support to actually utilize the perspective mode setting
(apparently |
| 07:27.29 |
CIA-40 |
BRL-CAD: it
was never wired up). this makes it work though there still flimsy
(need the |
| 07:27.29 |
CIA-40 |
BRL-CAD: main
view). this was noticed and requested by a few folks on and off the
cad |
| 07:27.29 |
CIA-40 |
BRL-CAD: team
(gillich and various analysts iirc). |
| 07:30.45 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1252
10/wiki/GSOC: Redirecting to [[Google Summer of Code]] |
| 07:31.00 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1253
10/wiki/Gsoc: Redirecting to [[Google Summer of Code]] |
| 07:31.27 |
*** join/#brlcad madant_
(n=madant@117.196.130.93) |
| 07:37.49 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Brlcad gsoc2009
flyer.png]]": BRL-CAD GSoC 2009 Flyer |
| 07:40.32 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1255
10/wiki/Google_Summer_of_Code/2008: add the 2008 flyer to give it
some identity |
| 07:40.58 |
*** join/#brlcad Kamran
(n=qadir010@58-27-157-151.wateen.net) |
| 07:41.06 |
Kamran |
hi
all |
| 07:42.01 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1256
10/wiki/Google_Summer_of_Code/2009: add the 2009 flyer |
| 07:42.10 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1257
10/wiki/Google_Summer_of_Code: update to the 2009 flyer |
| 07:44.37 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1258
10/wiki/Google_Summer_of_Code/Flyers: start a gallery |
| 07:46.41 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1259
10/wiki/Google_Summer_of_Code: link to the flyers page |
| 07:46.50 |
brlcad |
howdy
Kamran |
| 07:50.56 |
Kamran |
i want to
work on Web-based solid geometry model repository |
| 07:53.20 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1260
10/wiki/Google_Summer_of_Code/Project_Ideas: organize into
high-priority and other |
| 07:53.21 |
brlcad |
what can you
tell me about that task? |
| 07:53.39 |
brlcad |
(that are you
ideas for it, I know what's on the ideas page) |
| 07:56.18 |
Kamran |
we can save
the geomatries in xml formats |
| 07:56.38 |
Kamran |
and then
publish that xml in repository for sharing |
| 07:59.30 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1261
10/wiki/Google_Summer_of_Code/Project_Ideas: link to the design
movie for the gui task |
| 08:00.50 |
brlcad |
Kamran: hm,
the problem there would be that we have a format already --
introducing xml on the backend would provide very little gain and
be rather cumbersome to accomplish efficiently |
| 08:01.31 |
brlcad |
this can't be
just some generic model repository, it needs to relate to our tools
and formats for engineering and solid modeling purposes |
| 08:02.27 |
brlcad |
e.g. if xml
was going to be on the backend, i'd think STEP-XML would make a
better choice than anything we'd come up with in a summer for
compatibility, but that is a beast in itself (and you could
probably spend all summer writing a converter) |
| 08:03.43 |
Kamran |
so how a
student can achieve it using Drupal or Mediawiki? |
| 08:04.16 |
Kamran |
i think if
converter is implmented that would be, it will be
achieved? |
| 08:06.03 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1262
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Web-based solid
geometry model repository */ add some notes as this tends to be a
hot topic |
| 08:06.19 |
brlcad |
Kamran: no te
entiendo |
| 08:07.08 |
brlcad |
drupal/mediawiki just provide a plugin
framework from which to work in, with the point being that it's not
a fully custom system that someone has to wade through
later |
| 08:07.50 |
brlcad |
there are
other options like a rails project, possibly ajax, or some other
framework .. just not completely/mostly home-grown |
| 08:08.53 |
brlcad |
as for the
converter, my point was that we have a compact and efficient .g
file format as well as a couple dozen importers and exporters --
ideally, models could be automatically stored and converted between
the various supported formats |
| 08:10.07 |
Kamran |
if i have to
work on this web-based repository, i have to patach the repository
or not? |
| 08:12.41 |
brlcad |
patch the
repository? |
| 08:12.43 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1263
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Additional Projects
*/ all is not lost. |
| 08:13.02 |
brlcad |
you're making
a repository .. it's a matter of what goes into the repository and
how you store things |
| 08:13.03 |
Kamran |
yes |
| 08:13.13 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:18.45 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1264
10/wiki/Google_Summer_of_Code/Project_Ideas: add
difficulties |
| 08:19.59 |
brlcad |
Kamran:
brl-cad is a collection of more than 400 tools, to suggest a model
repository, your proposal should reference which tools you will be
using and how -- I'd suggest checking out the source code and
reading HACKING and src/README for starters (there's a section on
the various dirs) |
| 08:20.34 |
Kamran |
thanks |
| 08:34.09 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1265
10/wiki/Google_Summer_of_Code/Project_Ideas: add a bug-fix task and
annotate the 2008 projects |
| 08:34.33 |
brlcad |
np |
| 08:48.52 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1266
10/wiki/Google_Summer_of_Code/Project_Ideas: merge mged and
archer |
| 08:54.33 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1267
10/wiki/Google_Summer_of_Code/Project_Ideas: /* CSG evaluation of
Boundary Representations */ boole and esolid |
| 08:58.30 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1268
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Geometry database
(i.e. ".g" file format) enhancements */ |
| 08:59.37 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1269
10/wiki/Google_Summer_of_Code/Project_Ideas: swap |
| 09:09.11 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1270
10/wiki/Google_Summer_of_Code/Project_Ideas: implict to explicit
brep support |
| 09:21.42 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1271
10/wiki/Google_Summer_of_Code/Project_Ideas: fixed precision
project |
| 10:03.42 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:26.37 |
madant_ |
brlcad: nice
fonts ;) |
| 10:28.22 |
madant_ |
starseeker:
:) I like the poster |
| 10:54.41 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1272 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Constraints
and Parametrics */ Short Introduction added |
| 11:22.21 |
*** join/#brlcad Kamran
(n=qadir010@58-27-157-151.wateen.net) |
| 11:39.42 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 12:49.51 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 13:02.46 |
starseeker |
madant_:
thanks :-) |
| 13:03.03 |
starseeker |
brlcad pulled
it together |
| 13:03.19 |
starseeker |
just took some screenshots and blended 'em |
| 13:16.49 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-346e276e35b4e6eb) |
| 13:42.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 14:39.18 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1273
10/wiki/Google_Summer_of_Code/Project_Ideas: AquaTk
MGED |
| 14:41.00 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1274
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Additional Projects
*/ |
| 14:49.31 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1275
10/wiki/Google_Summer_of_Code/Project_Ideas: add initial mentor
list |
| 14:50.01 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1276
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors
*/ |
| 14:52.45 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1277
10/wiki/Google_Summer_of_Code/Project_Ideas: /* High Priority
Projects */ |
| 14:54.47 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1278
10/wiki/Google_Summer_of_Code/Project_Ideas: move mentors to the
end |
| 14:55.57 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1279
10/wiki/Google_Summer_of_Code/Project_Ideas: don't link to contact
page, requires login |
| 14:57.54 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1280
10/wiki/Google_Summer_of_Code/2009: /* Getting started */ don't be
redundant |
| 14:59.23 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1281
10/wiki/Google_Summer_of_Code/2009: /* Getting started
*/ |
| 15:00.49 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1282
10/wiki/Google_Summer_of_Code/2009: /* Getting started */
reword |
| 15:03.42 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1283
10/wiki/Google_Summer_of_Code: /* Previous years BRL-CAD has
participated */ |
| 15:09.16 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1284
10/wiki/Google_Summer_of_Code: link both posters |
| 15:56.38 |
*** join/#brlcad dreeves2
(n=c752f348@bz.bzflag.bz) |
| 16:02.03 |
*** join/#brlcad cad33
(n=c752f348@bz.bzflag.bz) |
| 16:16.26 |
starseeker |
brlcad: any
idea when they'll announce the projects chosen? |
| 16:17.47 |
d-lo |
18th I
thought.... |
| 16:20.14 |
ashishrai |
hey !! where
are the project ideas for BRL-CAD - can u please give the specific
link :) |
| 16:20.21 |
ashishrai |
for
GSoC |
| 16:20.57 |
starseeker |
http://brlcad.org/wiki/Google_Summer_of_Code |
| 16:21.16 |
starseeker |
http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
| 16:21.36 |
ashishrai |
starseeker:
thanks :) |
| 16:21.39 |
starseeker |
remember
though, selected orgs aren't known yet |
| 16:22.07 |
ashishrai |
brlcad will
be :) |
| 16:22.21 |
brlcad |
ashishrai:
it's not guaranteed |
| 16:22.41 |
brlcad |
probably
80/20 chances |
| 16:23.02 |
ashishrai |
i just hope
so |
| 16:23.04 |
ashishrai |
:) |
| 17:01.02 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 17:01.13 |
*** join/#brlcad madant_
(n=madant@117.196.151.151) |
| 17:07.11 |
tedcx |
How do we get
rid of jaggies in the renderings? |
| 17:07.44 |
starseeker |
uh... higher
resolution render? |
| 17:07.57 |
starseeker |
depends on
whether it's a geometry issue |
| 17:09.46 |
brlcad |
tedcx: you
can either turn on jittering (e.g. -j8) or increase your render
size and scale down (recommended) or both (for best
quality) |
| 17:13.12 |
tedcx |
is jittering
"dithering"? |
| 17:15.28 |
brlcad |
nope |
| 17:15.55 |
brlcad |
normally when
you render an image, rays are fired in the exact center of a given
pixel |
| 17:16.10 |
brlcad |
jittering has
it fire randomly within the pixel to avoid aliasing
artifacts |
| 17:17.49 |
brlcad |
-j8 means
fire 8 random rays and it then picks the most consistent result
(doesn't average/smooth the values still for various
reasons) |
| 17:18.26 |
brlcad |
thinks there needs to be a jitter-style option that does
averaging |
| 17:21.08 |
CIA-40 |
BRL-CAD:
03brlcad * r34043 10/brlcad/trunk/TODO: implement a jitter-style
averaging option for rt |
| 17:25.48 |
tedcx |
and are the
"framebuffers" just that or does the "ogl" really write ogl to
whatever graphics card you happen to have? |
| 17:31.57 |
starseeker |
glares as rt enters some kind of colorview
loop |
| 17:37.06 |
brlcad |
tedcx: the
framebuffer type is a framebuffer communications layer detail, just
what protocol it talks to the framebuffer with |
| 17:37.27 |
brlcad |
all the
framebuffers are raster contexts, the display managers are 3D
contexts |
| 17:38.22 |
brlcad |
so the ogl
framebuffer does end up making OpenGL calls to on an OpenGL
context, but that doesn't mean it's 3D data that you can spin
around (because it's a framebuffer, i.e., a raster image
display) |
| 17:44.49 |
brlcad |
nice quote..
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." |
| 17:44.53 |
brlcad |
from
Kernigan |
| 17:45.09 |
d-lo |
lol |
| 17:45.10 |
brlcad |
or this one,
Einstein: "Any intelligent fool can make things bigger, more
complex, and more violent. It takes a touch of genius -- and a lot
of courage -- to move in the opposite direction." |
| 17:47.13 |
brlcad |
hah,
fantastic... "The end is the same for everybody. We're all worm
food." |
| 17:48.04 |
archivist |
was Kernigan
responsible for the index entry for recursion in the C
book |
| 17:48.47 |
archivist |
which of
course points to the index page |
| 17:48.47 |
``Erik |
recursion:
see recursion. ? |
| 17:49.35 |
archivist |
index at back
og the second edition |
| 17:49.52 |
brlcad |
this must be
cool quote day |
| 17:49.55 |
brlcad |
"If you need
to cut, there's no tool as good as a sharp knife. If you need to
turn a screw, a sharp knife probably isn't the right tool. If you
have a guy who's a sharp knife, and you're using him to turn
screws, maybe the problem isn't him. Maybe the problem is
you." |
| 17:50.39 |
``Erik |
cool, where's
that from? |
| 17:51.25 |
louipc |
that is a
good one |
| 17:51.31 |
brlcad |
random /.
user quote |
| 18:03.01 |
starseeker |
hmm -
"imperfection is the greatness of man" |
| 18:03.20 |
starseeker |
not sure if
it makes sense, but it sounds deep |
| 18:13.52 |
*** join/#brlcad madant
(n=madant@117.196.133.81) |
| 18:30.35 |
bjorkintosh |
ayn rand will
strongly disagree. |
| 18:32.40 |
CIA-40 |
BRL-CAD:
03bob1961 * r34044 10/brlcad/trunk/src/libged/gqa.c: Added code to
free rtip. |
| 18:51.49 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 20:05.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 21:22.38 |
starseeker |
is mildly bemused by the slashdot discussion of quirky
programmers |
| 21:29.32 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 21:41.21 |
CIA-40 |
BRL-CAD:
03starseeker * r34045 10/brlcad/trunk/src/other/step/README: Add a
few notes on the current state of the STEP libraries. Since things
are now passing distcheck, pass the baton over to the 'make
functionality fixes and develop new functionality'
folk. |
| 21:48.24 |
*** join/#brlcad cad63
(n=c752f348@bz.bzflag.bz) |
| 22:58.40 |
bjorkintosh |
there's
another type besides the quirky? |
| 23:14.11 |
CIA-40 |
BRL-CAD:
03brlcad * r34046 10/brlcad/trunk/NEWS: bob fixed a tiny memory
leak in gqa making it free the rtip |
| 23:33.18 |
brlcad |
starseeker:
you did more than just take screenshots and blend them -- set up
the whole framework for the design |
| 23:33.22 |
brlcad |
thanks |
| 23:34.10 |
brlcad |
i just did
the typesetting |
| 00:00.09 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 00:00.09 |
Ralith |
a model of
one of those would be pretty neat too. |
| 01:25.36 |
*** join/#brlcad JoanW
(n=5b698faa@bz.bzflag.bz) |
| 01:47.04 |
*** join/#brlcad samrose
(n=samrose@oh-69-69-33-40.sta.embarqhsd.net) |
| 02:11.19 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 02:13.08 |
dreeves |
I sent the
patch to you brlcad I will work on pushing it to sf but I was
having problems so decided to be lazy for now |
| 02:13.18 |
dreeves |
and send it
directly to you |
| 02:23.27 |
dreeves |
ok got it
submitted to sourceforge |
| 02:34.35 |
brlcad |
nice, just
saw it |
| 02:35.09 |
brlcad |
didn't get
anything direct though (at least not yet |
| 02:35.29 |
brlcad |
but no
matter, I see the tracker |
| 02:44.02 |
*** join/#brlcad dreeves_
(n=IceChat7@67.130.253.14) |
| 03:02.40 |
starseeker |
<snort>
they're already offering discounts to try and get people to come to
SIGGRAPH 2009 |
| 03:03.11 |
starseeker |
<sarcasm>wonder if perhaps they're worried about the
economy...</sarcasm> |
| 03:13.54 |
dreeves |
Sorry about
that I guess I should have spent a little more effort figuring it
out |
| 03:13.55 |
bjorkintosh |
are SIGGRAPH
papers any good? |
| 03:15.22 |
dreeves |
there is
still room for improvement on the performance. Actually lost 15%
somewhere on the end maybe something for later... |
| 03:16.49 |
dreeves |
probably move
on to the NURBS stuff I suppose...although I think that is quite
abit more involved. |
| 03:22.53 |
starseeker |
bjorkintosh:
yesh |
| 03:22.55 |
starseeker |
er
yes |
| 03:23.25 |
starseeker |
all
conferences will have ups and downs in paper quality, but SIGGRAPH
has lots of very good papers |
| 03:34.08 |
bjorkintosh |
really? |
| 03:48.16 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-39632265f0993dad) |
| 06:31.03 |
*** join/#brlcad ewilhelm_
(n=ewilhelm@pool-71-111-78-159.ptldor.dsl-w.verizon.net) |
| 07:13.50 |
*** join/#brlcad madant
(n=madant@117.196.133.86) |
| 07:21.29 |
madant |
slept for 15 hours straight :O |
| 08:19.29 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:24.10 |
*** join/#brlcad madant
(n=madant@117.196.142.174) |
| 09:51.15 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:00.17 |
madant |
howdy
mafm |
| 10:55.36 |
d-lo |
Morning
all. |
| 10:55.56 |
d-lo |
Bad traffic +
thick fog = scary drive :/ |
| 10:59.53 |
madant |
does not have a driving license :P |
| 11:00.11 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:08.02 |
d-lo |
Hrm, lemme
think: Bad traffic + thick fog + no license = even
scarier!!! |
| 11:22.03 |
*** join/#brlcad _sushi__
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:28.52 |
madant |
d-lo: :P
true |
| 11:30.01 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-cdc87fe2db0fc4ac) |
| 11:35.46 |
mafm_ |
hi |
| 11:40.14 |
madant |
hey
:) |
| 11:41.30 |
madant |
freaky way to
do pull-ups :p http://www.crossfit.com/mt-archive2/Queens-Palace-Pullup.html |
| 11:42.44 |
d-lo |
Just goes to
show how well proper incentive can motivate! |
| 11:45.26 |
d-lo |
This one
looks strangely familiar...... http://www.crossfit.com/mt-archive2/crossfit-AnzioAnnie.html
;) |
| 11:47.04 |
brlcad |
it'd be a lot
more impressive if he was doing them off the barrel tip
:) |
| 11:47.44 |
d-lo |
True, but
with photoshot, anything is possible! :) |
| 11:47.46 |
brlcad |
thick fog +
rowing = eerie cool row :) |
| 11:48.01 |
d-lo |
Yeah, i was
wonding about that on the drive in :) |
| 11:48.18 |
brlcad |
fortunately
not all the crews have started so the traffic was pretty
low |
| 11:48.26 |
madant |
:D |
| 11:48.42 |
d-lo |
nice. Do you
compete or is it just for the halibut? |
| 11:48.45 |
brlcad |
it can get
very scary |
| 11:48.58 |
brlcad |
I
compete |
| 11:49.13 |
brlcad |
do ocd and
competitive to just paddle about |
| 11:50.24 |
madant |
has a backwater district nearby :) |
| 11:50.31 |
d-lo |
On a somewhat
related note, i found out that my Patriot can corner VERY well :)
90 degree curve came up on me a bit suddenly and I had to take it a
bit faster than I wanted :) Stiff suspension FTW. |
| 11:50.49 |
d-lo |
"every thing
I know about performance driving I learned from Top Gear"
:) |
| 11:51.14 |
brlcad |
is starving |
| 11:51.36 |
brlcad |
madant: those
look like fun pull-ups actually |
| 11:51.56 |
brlcad |
I can see
doing that |
| 11:52.24 |
madant |
yeah i mean
height really doesnt matter ;) but a nice pic nevertheless
:) |
| 11:53.01 |
madant |
I can do 20
.. ok 19 :P |
| 11:53.27 |
madant |
though not
confident about 20 at that height :) |
| 11:54.04 |
brlcad |
hehe, nice ..
http://www.torch.aetc.af.mil/shared/media/photodb/photos/061228-F-1936B-010.JPG |
| 11:54.55 |
d-lo |
lol\ |
| 11:55.36 |
d-lo |
brlcad: If
you can get to see the most recent Top Gear (the one where the road
test the Ford Fiesta) then you really REALY should. |
| 11:56.09 |
d-lo |
I laughed my
throat raw. That Humvee pic reminded me of it btw :) |
| 11:57.18 |
madant |
yikes..
:) |
| 12:03.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 12:18.41 |
CIA-40 |
BRL-CAD:
03indianlarry * r34055 10/brlcad/trunk/src/other/step/src/ (4 files
in 4 dirs): Added standard C++ library via LIBSTDCXX variable to
build where needed. |
| 12:35.23 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:40.21 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-df09e762b5abd51c) |
| 14:53.27 |
brlcad |
madant: woot,
top 20 :) |
| 14:54.33 |
madant |
huh
/ |
| 14:56.15 |
brlcad |
https://www.ohloh.net/p/brlcad/contributors |
| 14:57.42 |
madant |
:) aah.. it
is going to get better ;) |
| 14:58.25 |
madant |
am sure i
would have been way lower if they didn't only count number of
commits :D |
| 14:59.55 |
brlcad |
I've been
wanting to do some mega visualization at some point |
| 15:02.06 |
madant |
mega
visualization ;) ? |
| 15:04.28 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 15:15.01 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 15:22.53 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT
VICTIM] |
| 15:25.01 |
*** join/#brlcad CIA-40 (n=CIA@208.69.182.149.simpli.biz)
[NETSPLIT VICTIM] |
| 15:27.36 |
dreeves |
how does the
stuff work we submit as a patch? Does it get included in the next
release or is somewhat unknown because someone needs to make time
to look it over? |
| 15:32.11 |
*** join/#brlcad ``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:36.41 |
madant |
dreeves:
depends on the type of patch i guess.. mostly it gets added to the
trunk pretty fast once someone has a look at it .. some need a lot
of regression tests and might take longer.. if the person
submitting the patch has been given commit access then he is given
the right to close the patch tracker as well.. brlcad would
obviously be able to clarify all this better :) |
| 15:46.49 |
dreeves |
no big I was
just curious if there was a formal process or if it was just
somewhat loose. I think what I submitted is fairly low priority
because I would guess not many people are using that feature. Also
it is just a performance improvement. |
| 15:51.57 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:00.35 |
brlcad |
madant, yeah
visualization kinda like the code storm, but actually somewhat more
practical :) |
| 16:01.30 |
brlcad |
dreeves: the
latter, one of the existing devs takes the time to review and
test/evaluate the patch |
| 16:04.33 |
brlcad |
yeah,
basically what madant said -- it's not at all a formalized process
very much intentionally |
| 16:06.47 |
brlcad |
highly
formalization in open source projects is often a sign of a dying
project, most operate under meritocratic and high-iteration agile
practices (or at least gravitate towards them) |
| 16:07.29 |
dreeves |
Yeah I'm not
a big fan of very formalized process at all |
| 16:07.49 |
dreeves |
good way to
bring a project to it's knees |
| 16:07.52 |
brlcad |
that said,
yeah, your patch isn't what I'd call "high-priority" but it's
actually very important because it's from a new contributor
:) |
| 16:08.06 |
dreeves |
:) |
| 16:08.37 |
brlcad |
and it's not
just a performance improvement, it's a _substantial_ performance
improvement |
| 16:08.40 |
brlcad |
:) |
| 16:09.25 |
dreeves |
I think there
is still room for more improvement but I want to get on to the high
priority stuff I really just did that get warmed up |
| 16:10.31 |
dreeves |
I didn't want
to start with something where I was trying to get familiar with
what was what at the same time as tackling a tough problem i.e.
NURBS |
| 16:10.52 |
brlcad |
nods |
| 16:11.53 |
madant |
brlcad: hmm..
yeah it would be fun .. information visualization is always
nice |
| 16:26.43 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:30.31 |
brlcad |
dammit,
sf.net is down right as I submit |
| 16:30.50 |
brlcad |
~ping
sourceforge.net |
| 16:30.51 |
ibot |
pong
sourceforge.net |
| 16:34.30 |
brlcad |
there we
go |
| 16:35.29 |
d-lo |
<PROTECTED> |
| 16:35.30 |
ibot |
pong
sourceforge.net |
| 16:35.44 |
d-lo |
~google |
| 16:35.45 |
ibot |
hmm... google
is at http://www.yahoo.com |
| 16:35.55 |
brlcad |
~d-lo is a
BRL-CAD developer |
| 16:35.56 |
ibot |
brlcad:
okay |
| 16:36.05 |
brlcad |
~d-lo |
| 16:36.06 |
ibot |
hmm... d-lo
is a BRL-CAD developer |
| 16:38.19 |
dreeves |
didn't mean
to include that other stuff I forgot about messing around
that |
| 16:41.52 |
dreeves |
actually only
3 files should have been in there |
| 16:43.15 |
*** part/#brlcad ewilhelm
(n=ewilhelm@pool-71-111-78-159.ptldor.dsl-w.verizon.net) |
| 16:47.00 |
brlcad |
dreeves: I
know, it was obvious |
| 16:47.00 |
brlcad |
i wouldn't
have even mentioned it save for the other issues |
| 16:47.00 |
brlcad |
all minor,
but patch acceptance generally puts it in the submitter's hands to
fix it so the issues are resolved earlier instead of
later |
| 16:47.01 |
brlcad |
(as the goal
is to give commit) |
| 16:49.06 |
dreeves |
absolutely
yeah don't let me slide on anything I want comply no
problem |
| 16:49.35 |
starseeker |
A bat hanging
on to the space shuttle as it launches... awesome :-) |
| 16:49.43 |
dreeves |
I tried to
follow the style but obviously hasn't been the style I have been
follow as of late so habits and such |
| 16:50.26 |
dreeves |
So do I just
re attach a new patch or is it a new submit altogether |
| 16:51.08 |
dreeves |
btw it is
only 3 files |
| 16:53.13 |
d-lo |
Hrm, if a
small peice of foam can cause a catastrophic loss of the
orbiter.... i wonder what fate that bat has condemned them to?
:/ |
| 16:54.41 |
dreeves |
I'm sure the
"small" piece of foam was considerably larger than the
bat |
| 16:55.45 |
dreeves |
was the brace
style the only thing you noticed when reviewing the
code? |
| 16:55.47 |
starseeker |
yeah, no one
is worried that the bat will cause launcher damage |
| 16:56.35 |
starseeker |
wonders if there is a bat version of the Darwin
award... |
| 16:56.51 |
dreeves |
However I
pretty sure the bat didn't make it |
| 16:57.08 |
d-lo |
Dunno, sounds
like the basis for Samuel Jacksons next movie: Bats on a
Shuttle... |
| 16:59.13 |
brlcad |
dreeves: not
a problem .. there are probably four distinct styles throughout the
brl-cad sources -- just try to police new code and hit up files for
consistency as they are worked on |
| 16:59.39 |
brlcad |
most of the
files have issues, it'd takes many weeks of tedium to hit up
everything (it can only partially be automated) |
| 17:00.13 |
dreeves |
ok no
problem |
| 17:00.14 |
brlcad |
dreeves:
braces was the only stylistic thing I noticed that
mattered |
| 17:01.08 |
brlcad |
the other
stylistic changes are not worth policing unless someone
specifically wants to go on a rampage |
| 17:01.41 |
dreeves |
I was trying
to follow the correct style but in my day job I use the other style
so I will need to get the settings in my editor so I don't
forget |
| 17:01.42 |
brlcad |
or is just
egregiously annoying like spaces before commas |
| 17:01.50 |
brlcad |
nods |
| 17:01.56 |
brlcad |
I use the
other style on a few other projects |
| 17:02.04 |
dreeves |
hey the 30
setting that should should have been 64 |
| 17:02.05 |
brlcad |
some people
have religion on one vs the other |
| 17:02.20 |
brlcad |
to me, it's
just more important that the code is consistent |
| 17:02.46 |
dreeves |
Yeah I'm not
religious on that kind of stuff would rather spend my energy on
more useful things |
| 17:02.54 |
brlcad |
minimally
per-file consistent, ideally globally consistent (sans
src/other) |
| 17:02.56 |
dreeves |
yes I
agree |
| 17:03.54 |
dreeves |
that setting
was in the bezier_2d_isect.c before but if I'm to pre allocate the
buffers then the setting needs to come from extude.c |
| 17:05.48 |
dreeves |
I tried to
think of a way to get rid of it all together but at the time I was
tired (no sleep in 30+ hours) and I couldn't think of anything. So
I gave in a moved the setting to extude.c and passed into
bezier_2d_isect.c |
| 17:07.02 |
dreeves |
I was just
messing around and wanted to see what it would like like if I
changed the setting to 30 vs 64. Didn't make much of an impact on
either. I'm sure it would with a more complex shape |
| 17:10.52 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 17:15.02 |
brlcad |
yeah, it
sounds like the maximum number of intersects through the
sketch |
| 17:15.11 |
brlcad |
just at a
quick glance |
| 17:15.22 |
brlcad |
if that's
true, even 64 is kinda sketchy (no pun intended) |
| 17:15.41 |
brlcad |
some simple
grided sketch would blow out the limit |
| 17:19.33 |
dreeves |
no i don't
think that is what that number is |
| 17:20.20 |
dreeves |
I think that
is the number of times to subdivide the curve in order to resolve
down to a single segment of the curve to find the particular
intersection |
| 17:26.09 |
*** join/#brlcad madant
(n=madant@117.196.144.14) |
| 17:26.10 |
brlcad |
ah,
hm |
| 17:26.33 |
brlcad |
then that
sounds particularly asinine |
| 17:26.52 |
brlcad |
especially if
it has a ton of control points |
| 17:27.08 |
brlcad |
unless that's
between each pair of control points |
| 17:28.19 |
brlcad |
probably
should be based adaptive based on the amount of curvature in a
given piecewise region |
| 17:30.12 |
dreeves |
yeah checks
the curvature |
| 17:31.01 |
dreeves |
it tries to
subdivide to get down to little or no curvature but at some point
it stops which the maxlevel setting |
| 17:33.18 |
dreeves |
let me
restate |
| 17:34.53 |
brlcad |
aha.. so then
after a given minimized curvature, it then performs MAXDEPTH
samples of that piece |
| 17:34.57 |
brlcad |
that's not so
bad then |
| 17:35.11 |
brlcad |
probably even
overkill depending on that curvature setting |
| 17:35.36 |
dreeves |
exactly that
is why I was playing around with the number a little |
| 17:36.09 |
dreeves |
no I
misspoke |
| 17:36.19 |
dreeves |
I was saying
exactly to the overkill part |
| 17:36.40 |
dreeves |
but the
algorithm doesn't exactly work that way |
| 17:38.06 |
dreeves |
it divides
the control polygon down to attempt to consider a single segment of
the polygon but it also looks at curvature to make sure it is only
considering a case where the ray will only cross that segment
once |
| 17:38.40 |
dreeves |
if the
curvature is not "flat" enough it will continue to
subdivide |
| 17:40.26 |
dreeves |
however it
gives on continuing to subdivide if it reaches the max
subdivides |
| 17:41.30 |
dreeves |
the is
actually no limit on how far it will subdivide |
| 17:41.56 |
dreeves |
it only
consider the depth after it has gotten to a single segment of the
control polygon |
| 17:42.42 |
dreeves |
I can imagine
some situations that could cause it problems but I think they are
pretty extreme |
| 17:44.43 |
dreeves |
If I right I
think control polygons 2 to 32nd power is where you will see the
algorithm start to have problems. Well maybe a few powers lower
but in that area |
| 17:45.43 |
dreeves |
no actually
64th power |
| 17:53.33 |
dreeves |
Hope what I
wrote makes since here reading backup I realize I'm dropping
words... |
| 17:54.16 |
dreeves |
Of course I
could be completely off track but that is what I think is going
on |
| 18:01.14 |
*** join/#brlcad ashish
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-f77d495992c1e9eb) |
| 18:22.29 |
*** join/#brlcad madant_
(n=madant@117.196.133.222) |
| 18:24.04 |
brlcad |
dreeves: you
could toss in a zero-tolerance check on the polygon points -- if
they're all within computation tolerance, halt |
| 18:43.47 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-87.sbndin.btas.verizon.net) |
| 18:56.57 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 19:09.54 |
CIA-40 |
BRL-CAD:
03bob1961 * r34056 10/brlcad/trunk/src/librt/shoot.c: Modified
rt_res_pieces_clean() to skip uninitialized rt_piecestate
structures. |
| 19:47.23 |
*** join/#brlcad cad58
(n=c752f349@bz.bzflag.bz) |
| 19:58.55 |
*** join/#brlcad andrecastelo
(n=chatzill@201008160086.user.veloxzone.com.br) |
| 20:04.37 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 20:07.33 |
*** join/#brlcad dreeves
(n=c752f349@bz.bzflag.bz) |
| 20:09.27 |
dreeves |
brlcad had to
go to the office after my comments so I didn't see what you wrote a
response if anything |
| 20:30.39 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 20:31.06 |
kanzure |
considers working on a project listed on http://brlcad.org/wiki/Google_Summer_of_Code/2009/Project_Ideas |
| 20:42.15 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 20:42.18 |
*** join/#brlcad madant
(n=madant@117.196.130.208) |
| 21:03.04 |
brlcad |
ah, dreeves
left |
| 21:03.06 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-236-246.dclient.hispeed.ch) |
| 21:03.07 |
brlcad |
kanzure: glad
to hear it! |
| 21:06.29 |
kanzure |
brlcad:
Should I just submit a project proposal, or how does this
work? |
| 21:10.57 |
madant |
congrats
:) |
| 21:19.51 |
madant |
hmm.. and
they have changed the timeline as brlcad predicted :D |
| 21:21.33 |
brlcad |
kanzure:
discussion |
| 21:22.19 |
brlcad |
what do you
want to work on? why? who are you? (the 2cent gist version) why
do you want to work on brl-cad, what are your goals,
etc |
| 21:22.34 |
brlcad |
madant:
:) |
| 21:25.08 |
madant |
next 10 days
are going to be fun on the channel and mailing list :) |
| 21:29.18 |
madant |
brlcad: gsoc
blog says "larger student peer groups in each project"
;) |
| 21:41.43 |
kanzure |
hm, it's
entirely possible that you guys don't remember me :) |
| 21:41.46 |
kanzure |
http://heybryan.org/om.html |
| 21:42.06 |
kanzure |
http://heybryan.org/~bbishop/docs/gears/gears.html |
| 21:42.43 |
kanzure |
interchangeable/intercompatible parts and
automatic instruction generators, researcher here at the Automated
Design Lab at UT Austin :-) |
| 21:43.45 |
kanzure |
so in
particular I'd probably end up working on the parametric library or
web thingy for design repository, in particular my background has
been in open source hardware design packaging (much like "dot deb"
and "dot rpm" files except, uh, for hardware) |
| 21:45.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-87.sbndin.btas.verizon.net) |
| 21:47.36 |
kanzure |
some stuff
I've recently been doing (sadly, it's not with BRLCAD):
http://heybryan.org/books/Manufacturing/pythonocc/2009-03-15_3.png |
| 21:50.23 |
*** join/#brlcad samrose
(n=samrose@oh-69-69-33-40.sta.embarqhsd.net) |
| 21:51.47 |
brlcad |
oh yeah, I
guess I didn't announce it here yet :) |
| 21:51.51 |
brlcad |
we made it
into gsoc 2009 |
| 21:52.11 |
brlcad |
hurrahs |
| 21:52.35 |
kanzure |
http://heybryan.org/bioreactor/membraneless_filtration/2009-03-18_spiral.jpg
(warning: face) |
| 21:52.43 |
kanzure |
brlcad:
remember my work on spirals? |
| 21:52.45 |
kanzure |
:) |
| 21:52.51 |
kanzure |
now this just
needs to be tested in real life. |
| 21:53.02 |
brlcad |
<PROTECTED> |
| 21:53.13 |
kanzure |
DNS-wise? |
| 21:53.30 |
brlcad |
hah,
yes |
| 21:53.35 |
brlcad |
resolves to
127.0.0.1 |
| 21:53.47 |
_sushi_ |
resolves to 127.0.0.1 too |
| 21:54.02 |
kanzure |
http://66.112.232.182/bioreactor/membraneless_filtration/2009-03-18_spiral.jpg
(warning: face) |
| 21:54.05 |
kanzure |
try
that? |
| 21:54.24 |
brlcad |
kanzure: and
to answer your question, I did remember the name, just not the
connection |
| 21:54.29 |
kanzure |
okay |
| 21:56.21 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 21:56.31 |
brlcad |
madant: hm,
that's actually an interesting quote on the blog .. have to talk to
lh about it |
| 21:57.52 |
brlcad |
bz's going to
test almost the exact opposite mentoring-wise as our experience
indicated that we needed fewer students in order to better engage
them |
| 21:58.03 |
madant |
kanzure: what
does pythonocc do ? |
| 21:58.04 |
brlcad |
probably just
that there's a sweet spot that orgs have to find |
| 21:58.08 |
kanzure |
do mentoring
organizations have a minimum team size? |
| 21:58.16 |
brlcad |
nope |
| 21:58.17 |
kanzure |
madant:
pythonOCC == python bindings to OpenCASCADE |
| 21:58.20 |
kanzure |
http://pythonocc.org/ |
| 21:58.24 |
madant |
ah..
:) |
| 21:58.32 |
kanzure |
so I was just
putting together pythonOCC + the HeeksCAD interface
together |
| 21:58.35 |
kanzure |
since they
both use wxWidgets |
| 21:59.43 |
madant |
k..
opencascade is pretty neat ;) |
| 22:00.03 |
kanzure |
but the API
*sucks*. I mean, coming from the perspective of trying to figure
out how to write a simpler wrapper for it, or something, it's just
huge and hairy |
| 22:00.12 |
brlcad |
thinks they still fail the freeness test |
| 22:00.26 |
brlcad |
open yes,
just not free |
| 22:00.33 |
archivist |
kanzure,
author of HeeksCAD often is in #cam |
| 22:00.42 |
kanzure |
archivist:
thank you for the heads up |
| 22:01.06 |
madant |
freeness
maybe :) but not many CAE tools in open source scene otherwise
right ? |
| 22:01.08 |
kanzure |
brlcad:
apparently they are changing their licensing actually |
| 22:01.35 |
brlcad |
they've said
that for a couple years |
| 22:01.39 |
kanzure |
oh
:( |
| 22:01.58 |
brlcad |
and they did
tweak it once about two years ago, as it was originally entirely
ambiguous |
| 22:02.35 |
madant |
they had
BRL-CAD in one of their CDs or something if i remember correctly
? |
| 22:02.45 |
brlcad |
did
they? |
| 22:02.48 |
brlcad |
that'd
surprise me |
| 22:02.50 |
kanzure |
why? |
| 22:02.56 |
kanzure |
I mean, why
would they put it on? |
| 22:02.58 |
brlcad |
or at least
be news to me |
| 22:03.21 |
madant |
let me see
:) |
| 22:03.27 |
kanzure |
we were
hoping that pythonocc would make it into gsoc, but that didn't
happen this year |
| 22:03.37 |
kanzure |
but brlcad is
a good alternative, heh |
| 22:03.47 |
brlcad |
I'm all for
competition and collaboration, but that project has just smelled
bad from the beginning |
| 22:05.12 |
brlcad |
seemed more
of a failed commercial attempt that was dumped onto a website with
an "Open" label slapped onto it in order to try to attract some
business, then when that didn't work, they kept tweaking the
license to try to actually open it up "just enough" to get some
revenue through providing commercial API support |
| 22:05.13 |
madant |
ah maybe it
was the CAELinux dvd :) |
| 22:05.21 |
kanzure |
the giant DVD
library? :) |
| 22:06.01 |
kanzure |
ah, what I
think I meant to say was that OpenCASCADE recently became "open"
and "free" enough to warrant debian packaging and inclusion into
the main repositories |
| 22:06.05 |
brlcad |
i could be
completely wrong in that perception, but i was pretty excited to
try and join our geometry engines several years back only to be
sorely disappointed on many fronts |
| 22:06.09 |
kanzure |
(6.3.0 hit
the repositories last week) |
| 22:06.27 |
kanzure |
brlcad: can
you describe what happened on that front in particular? |
| 22:07.58 |
brlcad |
kanzure: well
part of what I just mentioned, that their entire intentions haven't
felt like they're with any actual regard or interest with F/OSS
development of CAD |
| 22:08.02 |
madant |
hmmm
opencascade in debian and not in non-free ? i remember somebody was
trying to package salome and opencascade a year ago.. |
| 22:08.34 |
kanzure |
things that
sound interesting: 1.3, 1.7, 1.10, 2.8 (from the wiki
page) |
| 22:08.38 |
brlcad |
doing only
the minimum they can get away with to conjure up business, not
being open to the community at large |
| 22:08.47 |
kanzure |
brlcad: no, I
mean the joining of the geometry engines :) |
| 22:08.54 |
kanzure |
sorry for the
ambiguity |
| 22:08.59 |
brlcad |
I mean that
too |
| 22:09.13 |
kanzure |
oh |
| 22:09.15 |
brlcad |
there's no
technical discussion to be had if there are legal issues and
project management issues |
| 22:09.28 |
kanzure |
were their
headers weird or something? |
| 22:09.29 |
kanzure |
ah, I
see. |
| 22:09.40 |
madant |
brlcad: news
coming up at main page ;) ? |
| 22:10.17 |
brlcad |
their license
originally was completely proprietary iirc, the only thing "open"
about them was that you could get the source code (but you couldn't
redistribute) and they had the word "Open" in their
name |
| 22:10.29 |
brlcad |
madant:
mailing list first, but yeah |
| 22:10.33 |
brlcad |
probably
later today |
| 22:11.11 |
kanzure |
where is the
brlcad-devel mailing list located? is it on the sf.net
server? |
| 22:11.17 |
brlcad |
yes,
sf |
| 22:11.58 |
kanzure |
http://lists.sourceforge.net/lists/listinfo/brlcad-devel |
| 22:11.59 |
kanzure |
aha |
| 22:13.58 |
louipc |
heh opennurbs
seems kind of closed when it comes to the community too |
| 22:14.07 |
Ralith |
yay,
gsoc! |
| 22:15.04 |
madant |
hey Ralith,
howdy |
| 22:15.14 |
Ralith |
hullo |
| 22:15.31 |
kanzure |
louipc: isn't
that the blender module? |
| 22:16.01 |
Ralith |
so I know
we've got plenty of engs in here |
| 22:16.08 |
Ralith |
anyone have
any thoughts on the hp50g calculator? |
| 22:16.42 |
kanzure |
huh, you guys
were solving constraint satisfaction problems with
graphs |
| 22:16.44 |
Ralith |
I discovered
my ti-89's not talking with my computer anymore. |
| 22:16.47 |
madant |
has never used a graphing calculator :D |
| 22:16.57 |
kanzure |
has done some work on graph grammars for graph-based design
automation. |
| 22:17.08 |
kanzure |
http://brlcad.org/wiki/Libpg_:_A_parametrics/constraint_library |
| 22:17.12 |
louipc |
kanzure: no
that's the rhino 3d nurbs library |
| 22:17.14 |
louipc |
http://www.opennurbs.org/ |
| 22:17.31 |
madant |
kanzure:
graphs .. well my initial idea was that bgl would be useful.. but
now i think maybe not.. |
| 22:17.44 |
kanzure |
bgl? |
| 22:18.03 |
madant |
boost graph
library |
| 22:18.10 |
kanzure |
so, our lab
uses software called "GraphSynth" |
| 22:18.17 |
kanzure |
it's a graph
grammar solver for engineering problems, more or less |
| 22:18.28 |
madant |
boost's
hypergraph support the last time i checked was not that
great.. |
| 22:18.29 |
kanzure |
one student
is doing gear-based automated design and optimization, another is
doing linkages, and another is doing product
disassembly |
| 22:18.41 |
louipc |
kanzure:
brl-cad requires opennurbs |
| 22:18.45 |
kanzure |
so it might
be interesting to integrate the graph functionality into
libpg |
| 22:19.15 |
madant |
kanzure: what
exactly do u mean by graph functionality ? |
| 22:19.19 |
archivist |
hmm
gears |
| 22:19.31 |
kanzure |
archivist:
did you see the link? |
| 22:19.49 |
kanzure |
http://heybryan.org/~bbishop/docs/gears/gears.html |
| 22:20.10 |
kanzure |
madant: I
mean the graphsynth classes for the representation of graphs,
generating thousands of solutions for a given graph, and so
on |
| 22:20.37 |
kanzure |
(just the
other day we were generating a thousand 'design solutions' from a
given 'specification graph' (these aren't the actual terribly
convoluted names they have, but that's what they are)) |
| 22:20.51 |
madant |
:) |
| 22:21.06 |
madant |
just checking
out the graphsynth page |
| 22:21.45 |
kanzure |
think of it
as a search-and-replace system that goes through the entire tree of
possible substitutions given a set of 'replace rules' (a "rule
set") |
| 22:22.02 |
louipc |
those are
some funky gears |
| 22:22.07 |
kanzure |
it's a hack
to glxgears :) |
| 22:22.29 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 22:22.43 |
kanzure |
I was going
to write a gear visualizer/CAD-generator with pythonocc |
| 22:22.49 |
Ralith |
there's a
cool xscreensaver module that generates very (infinitely?) long
serieses of properly interlocking gears |
| 22:22.54 |
kanzure |
but I haven't
got around to that yet |
| 22:23.00 |
madant |
hmm. and the
design is effectively a 'configuration' expressed in XML
? |
| 22:23.02 |
kanzure |
Ralith: oh?
I've never seen that, is that in the standard X11
package? |
| 22:23.05 |
kanzure |
madant:
yes |
| 22:23.08 |
Ralith |
no
idea |
| 22:23.13 |
Ralith |
it might not
even be on my system |
| 22:23.21 |
archivist |
glxgears |
| 22:23.23 |
kanzure |
Ralith: ah,
maybe it's in the xscreensaver package (sorry, didn't
read) |
| 22:23.24 |
Ralith |
I always set
my screensavers to random, so I can't help beyond that |
| 22:23.29 |
kanzure |
glxgears
doesn't do interlocking of infinitely many gears |
| 22:23.35 |
Ralith |
might even
haev only been in the freebsd distrib |
| 22:23.42 |
Ralith |
yeah this is
much more advanced than glxgears |
| 22:23.46 |
Ralith |
nicer looking
models, too |
| 22:23.49 |
kanzure |
anyway, it
sucks because it's not actual CAD |
| 22:23.55 |
kanzure |
it's just a
cylinder and some OpenGL calls |
| 22:24.03 |
kanzure |
kinda useless
for lab research :) |
| 22:24.12 |
Ralith |
I wouldn't
think parametric gears would be very hard |
| 22:24.17 |
kanzure |
not at
all |
| 22:24.17 |
madant |
kanzure: does
graphsynth support hypergraphs ? |
| 22:24.31 |
kanzure |
madant:
please excuse me, I'm not as well versed in hypergraphs as I should
be |
| 22:24.36 |
madant |
nods |
| 22:24.38 |
kanzure |
is this where
there are vertices with multiple edges? |
| 22:24.45 |
Ralith |
hm |
| 22:24.55 |
Ralith |
brlcad: does
BRL-CAD have any sort of geargen tool? |
| 22:25.05 |
bjorkintosh |
geargen? gear
generator? |
| 22:25.07 |
Ralith |
yeah |
| 22:25.08 |
kanzure |
yes |
| 22:25.13 |
kanzure |
madant: is
that what a hypergraph is? |
| 22:25.14 |
Ralith |
okay,
cool |
| 22:25.23 |
kanzure |
Ralith: no, I
wasn't answering you |
| 22:25.26 |
Ralith |
oh |
| 22:25.45 |
Ralith |
I ask because
we've got weird things like tire generators and fence generators
but I don't recall ever seeing a gear generator |
| 22:25.45 |
madant |
kanzure: the
hypergraph idea is basically that you can have edges between
edges.. |
| 22:25.58 |
bjorkintosh |
fence
generator? |
| 22:26.00 |
bjorkintosh |
whoa! |
| 22:26.03 |
Ralith |
chain link
fence |
| 22:26.07 |
bjorkintosh |
is in white
picket ... |
| 22:26.08 |
bjorkintosh |
oh
okay. |
| 22:26.13 |
kanzure |
madant: blah?
wha? |
| 22:26.13 |
bjorkintosh |
*as
in. |
| 22:26.46 |
kanzure |
madant:
http://en.wikipedia.org/wiki/Hypergraph |
| 22:26.48 |
kanzure |
"In
mathematics, a hypergraph is a generalization of a graph, where
edges can connect any number of vertices. " |
| 22:26.52 |
kanzure |
in which
case, yes |
| 22:29.19 |
louipc |
hmm! those
generators used to be prefixed with mk_ |
| 22:29.32 |
louipc |
now I don't
know what the generators are blah |
| 22:29.48 |
kanzure |
just grep
over the source for 'gear' :-) |
| 22:29.53 |
kanzure |
grep -H -I -R
"gear" * |
| 22:30.05 |
madant |
kanzure: if
you consider a constraint network.. it eventually has lets say a
set of nodes( variables) and constraints( edges between two or
moredependent variables) but constraints might depend on other
constraints as well.. so you have hyperedges connecting two or more
edges which can effectively be broken down into edges between many
vertices.. |
| 22:30.31 |
kanzure |
I
see |
| 22:30.56 |
Ralith |
kanzure:
hehe |
| 22:30.59 |
louipc |
kanzure:
that's not very efficient, and doesn't help those who only
installed the binary |
| 22:31.06 |
madant |
consider a
constraint which depends on two other constraints for instance
.. |
| 22:31.11 |
kanzure |
madant:
right |
| 22:31.27 |
madant |
so graphsynth
supports hypergraphs ? |
| 22:32.47 |
kanzure |
the answer is
complicated. yes in the sense that the constraint network can be
represented, no in the sense that the way that you solve it is not
by treating it as a hypergraph |
| 22:32.50 |
kanzure |
I don't know
if that makes sense |
| 22:33.19 |
kanzure |
see, when a
constraint network would be added into graphsynth, the "rules"
would be called forth to solve a particular subset of the
graph |
| 22:33.32 |
kanzure |
then it would
be possible, say, to find the next part of the constraint network
needs to be updated |
| 22:33.36 |
kanzure |
dependent on
the last modification that was made |
| 22:33.53 |
kanzure |
which is
essentially solving the same thing, no? |
| 22:34.20 |
madant |
looking at the grammar.. |
| 22:34.35 |
kanzure |
well that's
the thing, the grammars are hand-crafted |
| 22:34.51 |
kanzure |
like I said,
one researcher has made a grammar for gear generation, another for
linkages (or is working on it), another for product
disassembly |
| 22:35.22 |
kanzure |
(and there's
a few others- one for how to tie a tie, electronics (filter
circuits), and stuff I'm forgetting) |
| 22:35.42 |
madant |
kanzure: i
meant the basic designGraph class |
| 22:36.29 |
madant |
what are the
node classes ? |
| 22:36.48 |
kanzure |
vertices. |
| 22:36.58 |
kanzure |
what are you
asking? the name of the node class is 'node' IIRC |
| 22:37.14 |
madant |
i mean they
directly correlate with the variables right ? |
| 22:37.48 |
kanzure |
uhrm, sort
of. each node has a list of labels, and it's possible for a node to
only have one label, so in this case that label might be a variable
related to the constraint expression, yeah |
| 22:38.11 |
louipc |
starseeker:
should src/libged/tire.c be removed since it's already in
src/shapes/tire.c? |
| 22:38.59 |
madant |
ah.. so
designGraph is basically an implementation of a directed graph
right ? but hypergraphs are not effectively reducible to directed
graphs |
| 22:39.27 |
kanzure |
directed
means that edges point in a certain direction |
| 22:39.33 |
kanzure |
but in this
case, edges are bidirectional |
| 22:39.51 |
kanzure |
I mean, each
node has a list of the edges that are connected to it |
| 22:40.32 |
brlcad |
oof, turn my
head for just a few minutes.. |
| 22:40.45 |
madant |
:D |
| 22:43.17 |
brlcad |
louipc:
mcneal & assoc. were very upfront from the very beginning that
there was no support, no community, and a simple PD license, and
open about the fact that their intent was more converters and that
they have no intention of helping folks use it for analytic or
modeling purposes .. big difference in intent and
flexibility |
| 22:43.58 |
madant |
kanzure:
consider this hypergraph ( vertices : A,B,C,D,E,F
Edges/Constraints: A perp. B, Cperp. D, E parallel F if A perp. B
and C perp. D else E perp. F) how would this be represented in
graphsynth |
| 22:44.08 |
madant |
6 variables
and 3 constraints |
| 22:45.05 |
kanzure |
I would have
to play around with possible representation methods :) |
| 22:45.14 |
kanzure |
one idea that
comes to mind is using nodes for
perpendicularity/parallelism |
| 22:45.16 |
brlcad |
kanzure: 404
on http://66.112.232.182/~bbishop/docs/gears/gears.html |
| 22:45.31 |
kanzure |
so if two
nodes are connected by "parallel" or "perpendicular", then that's
that. |
| 22:46.05 |
brlcad |
Ralith: don't
think so, but pretty simple to create with the pattern tool ..
something I did in a couple minutes a couple years ago here:
http://brlcad.org/tmp/gear/ |
| 22:46.30 |
brlcad |
bjorkintosh:
there's a picket fence generator too |
| 22:46.43 |
kanzure |
ah, you were
the one who did /tmp/gear |
| 22:46.46 |
Ralith |
hm |
| 22:46.48 |
kanzure |
remembers seeing that a few weeks ago |
| 22:47.17 |
Ralith |
not the most
gearlike, but I imagine that's not a limitation of the
system |
| 22:47.23 |
brlcad |
louipc: ls
src/shapes |
| 22:47.35 |
madant |
kanzure: just
describe the new graph for me ? |
| 22:47.42 |
bjorkintosh |
haha |
| 22:47.46 |
bjorkintosh |
who put these
things in there, brlcad? |
| 22:48.19 |
brlcad |
louipc: look
at the implementation of src/shapes/tire.c ..
ged_tire() |
| 22:48.26 |
madant |
kanzure: u
mean two nodes and multiple edges between them ? |
| 22:49.06 |
madant |
kanzure: in
that case? lets say the nodes are P(perpendicularity) and U (
parallel) .. how do u model the third constraint ? |
| 22:49.21 |
kanzure |
madant: what
does the if/then statement signify? "if A per. B" does that mean
"if A perp. B is possible" ? |
| 22:49.48 |
brlcad |
kanzure:
/tmp/gear was a quick example for someone based on known curvature
parameters, forget who though |
| 22:50.04 |
madant |
kanzure: if A
perp. B is satisfied |
| 22:50.15 |
kanzure |
then that
should be in the grammar rules |
| 22:50.28 |
brlcad |
bjorkintosh:
various developers -- creating a procedural modeling tool that
generates something is actually a great way to become familiar with
the code base |
| 22:50.34 |
kanzure |
it would be a
new rule: "if you see this graph structure, then make this
modification" |
| 22:50.48 |
bjorkintosh |
you don't
say. |
| 22:50.53 |
starseeker |
has considered making a gear generator, but coils were more
manual labor for a usable result and less tractable to creation via
tools like clone |
| 22:50.56 |
kanzure |
in particular
it would be, using the model I suggested off the top of my head,
"if you see A-perp-B (vertices: A, perp, B), then do blah blah
blah" |
| 22:51.11 |
kanzure |
erm, sorry,
vertices: A, perpSOME_ID_NUMBER, B |
| 22:51.21 |
kanzure |
the
perpendicularity between the two is supposedly unique
:-) |
| 22:51.26 |
brlcad |
so we often
have new developers try to write an app that makes something (of
their choice), they end up learning some of libbu, libbn, librt,
libwdb and we end up with a simple tool that generates some shape
procedurally usually |
| 22:51.30 |
starseeker |
gears will
probably come later, but the variety is amazing in gears and much
thought would be needed to create a sufficiently general
framework |
| 22:51.34 |
madant |
kanzure: k
:) |
| 22:51.42 |
kanzure |
starseeker:
oh? |
| 22:51.51 |
kanzure |
starseeker:
that's kind of the work that I'm supposed to be doing right now for
the lab |
| 22:52.05 |
kanzure |
in
particular, I'm also supposedly coming up with a way to display
helical gears, worm gears, bevel gears, etc. etc. |
| 22:52.11 |
starseeker |
cooool
:-) |
| 22:52.11 |
Ralith |
starseeker:
isn't most of the variety just in the details of the tooth
shape? |
| 22:52.27 |
kanzure |
and I get to
ignore tooth shape (more or less)- which I know you guys are going
to hate me for |
| 22:52.31 |
starseeker |
Ralith:
tooth shape, tooth spacing, overall gear shape, gear
interior... |
| 22:52.40 |
brlcad |
e.g., I wrote
the chain link 'fence' tool probably a decade ago -- it comes in
handy for generating scenes for something that would otherwise be
very painstaking to model by hand (it generates a physically
accurate chain link fence with all the bends and individual
wires) |
| 22:52.42 |
kanzure |
madant: I
think it can be useful for parametrics. I'll definitely talk it
over with some labmates soon. |
| 22:53.13 |
madant |
kanzure: so
effectively the constraint graph in itself does not represent the
problem entirely ? |
| 22:53.23 |
Ralith |
starseeker:
doesn't strike me as terribly hard to abstract. |
| 22:53.40 |
brlcad |
you probably
have starseeker drooling now .. he's been talking about gears and
coils for a while :) (and now has the latter mostly
working) |
| 22:53.44 |
kanzure |
madant:
maybe. I'm still not sure- why is there an if/then in your
constraint specification? |
| 22:53.59 |
starseeker |
sticks tounge out at brlcad |
| 22:54.13 |
kanzure |
starseeker:
you should definitely check out the code in the directory I keep
linking to |
| 22:54.19 |
madant |
kanzure: it
is a possible logical constraint right :) |
| 22:54.19 |
kanzure |
http://heybryan.org/~bbishop/docs/gears/ |
| 22:54.27 |
starseeker |
Ralith: It
isn't hard to abstract - that's one of the reasons it's a good
candidate for a tool |
| 22:54.33 |
starseeker |
looks |
| 22:54.53 |
madant |
since
constraints effectively have two states : only constraints possible
between them are in essence logical |
| 22:54.54 |
kanzure |
madant: can
you give me an example of a situation where I inadvertedly used a
logical constraint in a CAD app without perhaps knowing
it? |
| 22:55.10 |
starseeker |
kanzure:
Can't see it from here - I'll have to look later |
| 22:55.21 |
kanzure |
starseeker:
blah, some of you are unable to load the pages, while others in
this channel can |
| 22:55.24 |
kanzure |
wtf? |
| 22:55.57 |
madant |
kanzure: :)
am not really sure if any CAD application supports it.. I mean i
have only worked with CATIA and it doesn't.. |
| 22:56.08 |
Ralith |
starseeker:
well, what did you mean by "much thought would be needed to create
a sufficiently general framework"? |
| 22:56.09 |
starseeker |
Ralith: a
lot of the work involved with a gear tool would be identifying what
the standard methods are for specifying gear type, size, etc. and
wiring up the logic to generate the proper geometry based on those
numbers |
| 22:56.30 |
kanzure |
yay |
| 22:56.34 |
Ralith |
yeah, I
imagine it would be mostly research |
| 22:56.35 |
kanzure |
starseeker:
we should definitely collaborate on this |
| 22:56.35 |
starseeker |
for each gear
type, there may be a whole sub-set of specifications to look
at |
| 22:56.39 |
madant |
kanzure: but
not sure if many CAD applications support it internally.. will have
to think of a case :) |
| 22:56.41 |
Ralith |
it sounds
ilke an interesting task, though |
| 22:56.46 |
kanzure |
Ralith: I'm
working with somebody who has done most of that work |
| 22:56.49 |
kanzure |
that research
work, I mean |
| 22:56.58 |
Ralith |
kanzure:
cool; has he published his findings anywhere? |
| 22:57.03 |
kanzure |
paper in
progress |
| 22:57.04 |
kanzure |
:) |
| 22:57.10 |
starseeker |
kanzure:
It'll be a while before I can devote much time to it - I've got
other more pressing tasks :-/ |
| 22:57.17 |
Ralith |
let me know
when it's up |
| 22:57.19 |
Ralith |
I might just
write this |
| 22:57.20 |
madant |
kanzure: how
many people are working with parametrics and constraints at UT
? |
| 22:57.37 |
kanzure |
madant: I
don't know anybody who is explicitly working on that problem.
:( |
| 22:57.38 |
kanzure |
it's so
sad |
| 22:57.49 |
brlcad |
kanzure: I
believe unigraphics can get you into some situations where you use
constraints implicitly |
| 22:57.51 |
kanzure |
I guess
there's me. |
| 22:58.16 |
brlcad |
it's got a
red-light/green-light to let you know if you're fully constrained
or under/over too, interesting concept |
| 22:58.33 |
starseeker |
Ralith: then
for each gear type, you have to think about precisely what geometry
you want to use to represent it. For example, would it be better
to use sketches for gear patterns that can be represented as
extrusions, or should such gears be combinations of arbs and
tgcs? |
| 22:58.43 |
kanzure |
yes, I've
seen something like that in Solidworks re: red/green light for
over/under constrained |
| 22:58.49 |
starseeker |
extrusions
would do for a lot of types, but not all |
| 22:58.59 |
madant |
brlcad: i
like the similar feature in catia sketcher.. where they show u
overconstrained and underconstrained and correctly constrained
elements in different colours |
| 22:59.06 |
Ralith |
yeah, I
realized that |
| 22:59.09 |
kanzure |
starseeker:
in my case, the generated CAD file would have to be dependent on
the variables that the optimization engine is spitting
out |
| 22:59.12 |
Ralith |
we can't
twist extrusions yet, can we? |
| 22:59.14 |
kanzure |
so that kind
of solves that problem eh? |
| 22:59.22 |
kanzure |
but makes for
a perhaps overly constrained gear generator in the end of course
:) |
| 22:59.36 |
brlcad |
has wanted similar lights for constraining once it's all
working, but even now for overlap reporting |
| 22:59.55 |
starseeker |
kanzure: In
part. You also want to be able to manually specify gears from the
command line (or, better, from within MGED) using standard
parameters |
| 23:00.00 |
kanzure |
right |
| 23:00.05 |
kanzure |
no argument
there. |
| 23:00.16 |
Ralith |
some sort of
extrude along a path describing rotation as well as direction; is
there a name for that? |
| 23:00.20 |
madant |
ah.. so it is
effectively : if ( constraint1 = true , constraint 2= true .... )
then constraints=true ;) hypegraph :D |
| 23:00.20 |
kanzure |
madant: so
was your logic constraint spec an imaginary one? :) |
| 23:00.35 |
starseeker |
Ralith:
sounds like sweep |
| 23:00.39 |
Ralith |
that's
it |
| 23:00.44 |
Ralith |
we don't have
that yet, right? |
| 23:00.47 |
starseeker |
right |
| 23:00.55 |
Ralith |
'cuz that
would make things easier. |
| 23:01.00 |
starseeker |
indeed |
| 23:01.02 |
kanzure |
madant: yeah,
the solutions would be those graphs where "all constraints have
been satisfied" (or eliminated, or completely replaced, or
something) |
| 23:01.32 |
madant |
kanzure: yep
:) |
| 23:01.41 |
kanzure |
what would
BRLCAD do with multiple solutions to a constraints satisfaction
problem anyway? |
| 23:01.46 |
Ralith |
in fact, I'm
not sure how you'd represent those twisted gears with simple
operations on primitives--though I'm no modeler. |
| 23:01.53 |
kanzure |
would it let
the user pick from a list ? is that how this goes? |
| 23:02.07 |
starseeker |
twisted
gears? like on oil rig drilling? |
| 23:02.13 |
Ralith |
I dunno about
oil rigs |
| 23:02.13 |
starseeker |
yeah, those
would be a problem |
| 23:02.15 |
kanzure |
helical
gears? |
| 23:02.18 |
madant |
yeah the idea
is to present the user with the range of options.. |
| 23:02.26 |
Ralith |
I saw these
in a lathe's gearbox |
| 23:02.28 |
madant |
asking him
for either further constraints or values |
| 23:02.48 |
starseeker |
runs through the primitives in his mind... |
| 23:02.54 |
Ralith |
imagine
taking a normal gear with fine teeth, then twistingthe top and
bottom half in opposite directions |
| 23:03.03 |
Ralith |
such that the
teeth are no longer parallel to the axis |
| 23:03.12 |
*** join/#brlcad Dr_Phreakenstein
(n=phreak@216.151.24.198) |
| 23:03.16 |
starseeker |
Oh, that's
less of a problem |
| 23:03.26 |
Ralith |
they're used
to increase contact area between the gears |
| 23:03.38 |
kanzure |
madant: so I
guess all that I need to do now is figure out how to make grammar
rules for solving constraints problems |
| 23:03.48 |
kanzure |
and then get
the professor to put up a real GPL license for
graphsynth |
| 23:03.55 |
kanzure |
and then
integrate the code and go from there :p |
| 23:04.38 |
madant |
kanzure: i
will read up on graphsynth today .. is there any documentation
other than http://www.me.utexas.edu/~adl/graphsynth/ |
| 23:05.43 |
kanzure |
not
really. |
| 23:05.54 |
kanzure |
there's some
related stuff here: heybryan.org/~bbishop/docs/repo/ |
| 23:06.04 |
kanzure |
some example
graphs of designs: http://heybryan.org/~bbishop/docs/repo/2009-02-20_FS/ |
| 23:06.14 |
starseeker |
I was
thinking of connections like those visible in page two of this
patent: http://www.google.com/patents?id=9WEUAAAAEBAJ |
| 23:06.32 |
kanzure |
madant: this
might be helpful, some powerpoints? http://heybryan.org/~bbishop/docs/repo/presentations/ |
| 23:06.37 |
madant |
kanzure: :( i
don't have access to windows :P |
| 23:06.48 |
Ralith |
starseeker:
those count as gears? |
| 23:06.59 |
starseeker |
It's remotely
possible that some application of tgc subtractions could produce
that sort of effect... |
| 23:07.12 |
kanzure |
madant: there
should be some odf presentations there, and if not, don't worry- I
don't have access to windows either :) |
| 23:07.16 |
starseeker |
Ralith: they
can. It's called a twisted prism |
| 23:07.23 |
Ralith |
sounds...
arcane. |
| 23:07.26 |
Ralith |
what're they
used for? |
| 23:07.40 |
starseeker |
Lots of HP
printer cartridges have used it |
| 23:07.49 |
madant |
nah.. i meant
the actual graphsynth program |
| 23:07.52 |
Ralith |
I mean I can
see in the drill application it would keep the connections
tight |
| 23:07.57 |
Ralith |
but in
gears? |
| 23:08.08 |
starseeker |
it has the
advantage of the turning mechanism also pulling the component
toward the socket |
| 23:08.10 |
kanzure |
madant:
nope. |
| 23:08.26 |
starseeker |
Ralith: hang
on, I'll see if I can find a picture |
| 23:08.29 |
kanzure |
btw, I've
been able to compile it on monodevelop under linux |
| 23:09.12 |
brlcad |
kanzure: how
long ago was dns changed? |
| 23:09.18 |
brlcad |
(on
heybryan.org) |
| 23:09.21 |
kanzure |
brlcad: it
wasn't! :) |
| 23:09.27 |
kanzure |
I mean, I've
never set it to 127.0.0.1 |
| 23:09.34 |
kanzure |
and it hasn't
been changed recently |
| 23:09.46 |
brlcad |
then you have
a bad name server somewhere in there or an expired name or
something.. |
| 23:09.57 |
kanzure |
hrm. |
| 23:10.01 |
madant |
hmm.. this is
interesting : http://minion.sourceforge.net/ |
| 23:10.07 |
kanzure |
but then why
doesn't the IP address work? |
| 23:10.27 |
Ralith |
heybryan.org
works for me |
| 23:10.58 |
madant |
works for me
too @opendns |
| 23:11.12 |
kanzure |
haha,
somebody's using opendns? :) |
| 23:11.16 |
Ralith |
:P |
| 23:11.25 |
Ralith |
is using level3's servers |
| 23:11.32 |
starseeker |
Ralith: not
ideal, but
http://www.google.com/patents?id=dGyEAAAAEBAJ&pg=PA37&dq=twisted+prism+gear+helical&source=gbs_selected_pages&cad=1_1 |
| 23:11.32 |
brlcad |
kanzure: ah,
there's your problem |
| 23:11.37 |
brlcad |
all four of
your name servers are dead |
| 23:11.56 |
kanzure |
but then what
about you being unable to use my IP to access the same
content? |
| 23:12.08 |
starseeker |
Ralith:
element 37a |
| 23:12.08 |
kanzure |
madant: so,
minion spits out a list of solutions? |
| 23:12.13 |
brlcad |
looks like
afraid.org lost their name |
| 23:12.22 |
Ralith |
starseeker:
yeah, I saw... isn't that another interlock? |
| 23:12.32 |
kanzure |
http://minion.sourceforge.net/gsoc/index.html |
| 23:12.41 |
starseeker |
Ralith: It's
a combination of interlock and driver |
| 23:12.43 |
Ralith |
or is 39a a
matching gear |
| 23:12.55 |
madant |
not sure..
just came across it :) scalability seems to be one of their great
aims ;) |
| 23:13.01 |
starseeker |
yes, 39a is
the matching socket |
| 23:13.05 |
Ralith |
socket? |
| 23:13.13 |
Ralith |
still not a
gear, then |
| 23:13.29 |
starseeker |
many of these
gear types have helical components, but some of them get rotation
only from that twisted prism |
| 23:13.36 |
Ralith |
well, either
way, it's an interesting shape |
| 23:13.42 |
kanzure |
madant: it's
weird, they seem to be about visualization of results?
wtf |
| 23:13.45 |
Ralith |
and
apparently one we can't model. |
| 23:14.18 |
starseeker |
I doubt it.
I've been trying to envison some sort of tgc subtraction which
could do it, but I doubt it |
| 23:14.46 |
Ralith |
would a sweep
cover those? |
| 23:14.58 |
starseeker |
If
sufficiently general, yes |
| 23:15.14 |
Ralith |
I'm guessing
sweeps are pretty nontrivial to implement, then. |
| 23:15.23 |
Ralith |
seems very
useful, though... |
| 23:15.42 |
starseeker |
yes and yes
:-) |
| 23:16.03 |
madant |
kanzure: ?
visualization |
| 23:16.08 |
kanzure |
in their gsoc
page |
| 23:16.43 |
madant |
ah those are
just their ideas page right :) |
| 23:18.00 |
madant |
hmm they have
a solver independent modeling language too.. nice .. my idea for
libpc is somewhat the same in the long run.. i mean multiple
solvers for the same constraint network |
| 23:18.47 |
starseeker |
Well, enough
tgc playing with an arb6 MIGHT produce something interesting, but I
don't think it can do it |
| 23:18.54 |
kanzure |
shouldn't it
just implicitly find all possible solutions, madant ? |
| 23:19.22 |
madant |
kanzure: i
liked their work too a bit http://www.gecode.org/ |
| 23:20.16 |
madant |
kanzure: oh
the mutliple solvers ? i was just thinking it might be possible
that some solvers are better for some graphs / problems |
| 23:20.34 |
madant |
kanzure: i
was not implying running a set of solvers for getting the complete
set of solutions |
| 23:21.43 |
kanzure |
ah, better as
in more efficient |
| 23:21.43 |
kanzure |
okay |
| 23:23.14 |
madant |
is diybio fun
;) ? |
| 23:23.18 |
kanzure |
very |
| 23:23.35 |
kanzure |
scroll down
to the bottom of my homepage and I have a link to some recent work
I've been doing with 'sharpie microfluidics' |
| 23:23.51 |
kanzure |
i.e.
prototyping a "lab on a chip" with a sharpie and a few spare CDs
using surface tension and the capillary force ;-) |
| 23:24.42 |
brlcad |
kanzure: huh,
did minion make it? |
| 23:24.55 |
brlcad |
ah,
no |
| 23:25.27 |
brlcad |
going to say,
just having two ideas and being that domain-specific .. nearly
impossible |
| 23:25.53 |
madant |
kanzure:
can't find it :P link ? |
| 23:26.03 |
brlcad |
madant: that
does look like an interesting project, though :) |
| 23:26.13 |
kanzure |
madant:
http://groups.google.com/group/diybio/msg/1197606e3c3dc439 |
| 23:26.55 |
kanzure |
(there were
40 messages in that thread .. some of the more recent messages have
been about prototyping microchannels via human hair + sharpie.. but
anyway) |
| 23:27.03 |
madant |
brlcad:
yeah.. i will check out their papers tomorrow .. er.. today ( 5 am
here) .. |
| 23:27.06 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:27.16 |
brlcad |
pretty bold
performance claims |
| 23:27.17 |
madant |
should get going to try the Crossfit Murph |
| 23:27.33 |
brlcad |
not just an
order.. orders* faster |
| 23:27.55 |
brlcad |
license is a
non-starter though, maybe they'd consider changing it |
| 23:27.59 |
madant |
kanzure: see
you around.. will definitely check out graphsynth today |
| 23:28.05 |
kanzure |
okay, neat
:) |
| 23:28.13 |
kanzure |
mentions again that he's considering brlcad for
gsoc |
| 23:28.14 |
kanzure |
heh |
| 23:28.18 |
brlcad |
heh |
| 23:28.20 |
madant |
brlcad:
maybe.. most probably students or profs somewhere.. |
| 23:28.43 |
brlcad |
yeah,
http://minion.sourceforge.net/people.html |
| 23:29.28 |
madant |
ok.. :) be
back in an hour.. |
| 23:29.34 |
brlcad |
would be
fantastic if they relicensed as lgpl or bsd |
| 23:29.40 |
brlcad |
cya
madant |
| 23:48.01 |
starseeker |
hmm, this is
as close to a twisted prism shape as I can come in a short trial:
http://bzflag.bz/~starseeker/twisted.png |
| 23:48.07 |
starseeker |
not so
good |
| 23:59.02 |
brlcad |
heck of a lot
easier with brep :) |
| 23:59.10 |
brlcad |
but probably
not as fast |
| 00:03.11 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1242451023.dsl.bell.ca) |
| 00:06.58 |
louipc |
brlcad: re:
opennurbs hah they told me they were collecting email addresses so
they can contact people when there are updates |
| 00:08.48 |
brlcad |
heh, I'd
believe that too :) |
| 00:10.11 |
brlcad |
there's just
no harm in supporting your competition to make importers/exporters
for their format to 3dm (rhino) format -- either supports existing
rhino customers (via export functionalit) or helps steal/convert
customers from their competition :) |
| 00:10.29 |
brlcad |
pretty
brilliant actually, i think |
| 00:10.36 |
brlcad |
(for a
commercial code) |
| 00:10.55 |
louipc |
yeah it's in
the spirit of commercial interests really |
| 00:11.14 |
brlcad |
yeah, but the
point was that they've been very up-front about that from the
start |
| 00:11.19 |
bjorkintosh |
brlcad, rhino
strikes me as a maya/blender sorta competitor... |
| 00:11.21 |
bjorkintosh |
am i
wrong? |
| 00:11.29 |
louipc |
not what you
immediately think when you see the word 'open' |
| 00:11.47 |
brlcad |
that they're
doing it for business reasons and not for open source, but still
providing it gratis |
| 00:12.03 |
brlcad |
bjorkintosh:
they are very much |
| 00:12.16 |
louipc |
so yeah..
that's why I'm not so thrilled about brl-cad using it |
| 00:12.19 |
louipc |
shrugs |
| 00:12.33 |
brlcad |
bjorkintosh:
their opennurbs library, however, is tiny slice of a much more
extensive geometry toolkit |
| 00:12.52 |
bjorkintosh |
ah
okay. |
| 00:13.14 |
brlcad |
and has
actually only little to do with what rhino itself does |
| 00:13.28 |
brlcad |
louipc: how
so? |
| 00:13.36 |
brlcad |
because it's
not free software? |
| 00:14.17 |
brlcad |
it's public
domain, doesn't get much more "do whatever you want with it" ..
just with the caveat of "but don't come crying back for more from
me" |
| 00:14.18 |
louipc |
because
upstream is uncooperative |
| 00:14.43 |
brlcad |
someone could
turn it into a f/oss project if they wanted |
| 00:15.05 |
brlcad |
i'm cool with
that -- now if there was any ambiguity and they pretended to be
open source... |
| 00:15.29 |
brlcad |
that's
effectively malicious intent |
| 00:15.40 |
brlcad |
or at least
subversive |
| 00:15.43 |
brlcad |
they're not
doing that |
| 00:17.32 |
brlcad |
louipc: plus,
the framework itself is pretty phenomenal just as a 'container' ..
very clean API, probably saved at least a couple *years* of
development effort with no other solution on par with as flexible
usage rights |
| 00:20.18 |
starseeker |
anybody want
to contact the minion folk about licensing? |
| 00:27.13 |
madant |
is back |
| 00:27.36 |
madant |
starseeker: i
was thinking of mailing them |
| 00:28.13 |
madant |
LGPL or GPL
? |
| 01:00.13 |
brlcad |
it's already
GPL |
| 01:00.21 |
brlcad |
that's
nfg |
| 01:00.46 |
brlcad |
ideally lgpl
or bsd |
| 01:01.16 |
madant |
:) ha..
probably starseeker would be tetter at persuading them
:D |
| 01:01.31 |
brlcad |
don't make
them any promises, but they might like to know why we're
interested |
| 01:02.22 |
madant |
hmm |
| 01:02.48 |
madant |
i guess first
i should try building it :D |
| 01:47.05 |
*** join/#brlcad Twerpling
(i=Twerplin@c-69-250-127-183.hsd1.md.comcast.net) |
| 01:53.54 |
*** join/#brlcad _``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 02:03.58 |
starseeker |
madant: Nah,
go for it |
| 02:05.38 |
starseeker |
stares in awe at the number of upgrades waiting for him in
gentoo and realizes he has waited too long since his last
update |
| 02:05.41 |
starseeker |
groan |
| 02:05.57 |
starseeker |
plus a full
kde rebuild against qt 4.5 |
| 02:06.07 |
starseeker |
the power
bill will be higher this month... |
| 02:12.25 |
*** join/#brlcad __``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 02:17.53 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 02:18.40 |
*** join/#brlcad rahul_cool
(i=dce324a3@gateway/web/ajax/mibbit.com/x-65d3501ca96e87cf) |
| 02:19.12 |
rahul_cool |
hello
all |
| 02:20.33 |
rahul_cool |
i have a
problem in configuring brlcad source code |
| 02:21.12 |
rahul_cool |
when i gave
the command svn checkout it says that it could not connect to
site |
| 02:21.31 |
rahul_cool |
can anyone
help please |
| 02:31.58 |
louipc |
rahul_cool:
you should post the exact message |
| 02:38.56 |
rahul_cool |
i have
download svn with the help of following command... "sudo apt-get
install subversion" |
| 02:39.20 |
rahul_cool |
the output
is... |
| 02:39.39 |
rahul_cool |
svn: OPTIONS
of 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk':
could not connect to server (https://brlcad.svn.sourceforge.net) |
| 02:40.15 |
rahul_cool |
i gave this
command many times and always same output appears |
| 02:40.39 |
rahul_cool |
i gave svn
checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 02:42.17 |
madant |
do u have to
use a proxy to access the sites ? |
| 02:42.52 |
rahul_cool |
i tried
.subversion/servers command and the output is permission
denied |
| 02:44.25 |
madant |
er..
.subversion/servers command ? you have to edit that file and put in
the proper proxy host and port etc. |
| 02:44.53 |
dreeves |
can you ping
the brlcad.svn.sourceforge.net |
| 02:45.05 |
dreeves |
server |
| 02:46.05 |
rahul_cool |
yes i am able
to access this site |
| 02:46.15 |
dreeves |
then you
don't have a proxy issue |
| 02:46.34 |
dreeves |
can you touch
x in the directory where you are attempting to checkout |
| 02:47.20 |
rahul_cool |
touch x
means??i did not get u |
| 02:47.35 |
dreeves |
type the
command 'touch x' |
| 02:47.46 |
rahul_cool |
ok |
| 02:48.05 |
dreeves |
if it works
means you have access to write to the directory you are
in |
| 02:48.06 |
madant |
you are able
to access the server by using the ping command from the shell ?
correct ? |
| 02:48.21 |
dreeves |
good
question? |
| 02:49.35 |
rahul_cool |
i didnot try
ping command i access that site by putting its url address on
net |
| 02:49.57 |
dreeves |
no madant is
right you need to try in the shell |
| 02:50.09 |
dreeves |
you could
have a proxy setup in the browser |
| 02:50.32 |
rahul_cool |
ok... i
try |
| 02:52.00 |
dreeves |
well |
| 02:53.07 |
dreeves |
sorry madant
I hope I didn't step on you there, habit I get this issue seems
like every day at work it always 1 of 3 things |
| 02:53.55 |
madant |
hehe :D not
at all.. |
| 02:54.04 |
dreeves |
cool |
| 02:54.17 |
madant |
scratches his trying to understand where the stepping might
have happened :D |
| 02:54.29 |
madant |
yikes |
| 02:54.43 |
madant |
scratches his HEAD trying to understand where the stepping
might have happened :D |
| 02:54.59 |
dreeves |
oh i didn't
on purpose |
| 02:55.47 |
madant |
:D now i am
plain confused .. :) how's the code surfing coming along dreeves
? |
| 02:55.50 |
dreeves |
but you where
kind of talking to rahul and then I jumped in and I'm new to this
so I'm not certain of the exact protocols/formalities |
| 02:56.11 |
dreeves |
cool I'm
getting there |
| 02:56.25 |
madant |
shouts screw formalities :D |
| 02:56.41 |
dreeves |
yeah I
typically do |
| 02:57.14 |
dreeves |
I'm familiar
with the code but some of the math I have to get back into it has
been a little while since i have really done it at this
level |
| 02:57.39 |
dreeves |
some code has
changed since I worked on it before but most is the
same |
| 02:58.05 |
madant |
thought about
what exactly you want to work on ? i might have missed some IRC
discussion |
| 02:58.49 |
madant |
i wonder how
it must have been all those years ago .. :) |
| 02:58.54 |
dreeves |
yeah I think
I'm going to give a hand at nurbs |
| 02:59.06 |
dreeves |
being I'm
rusty at math |
| 02:59.39 |
*** join/#brlcad rahul_cool
(i=dce324a3@gateway/web/ajax/mibbit.com/x-c85f824f88c5af5c) |
| 03:00.08 |
rahul_cool |
i gave the
command |
| 03:00.25 |
rahul_cool |
ping https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk |
| 03:00.32 |
rahul_cool |
the output
comes |
| 03:00.41 |
madant |
just 'ping
brlcad.svn.sourceforge.net ' |
| 03:00.49 |
rahul_cool |
ping: unknown
host https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk |
| 03:01.58 |
rahul_cool |
ok..........on that command |
| 03:02.03 |
rahul_cool |
the output
is |
| 03:02.05 |
rahul_cool |
PING
svn.sourceforge.net (216.34.181.65) 56(84) bytes of
data. |
| 03:02.31 |
rahul_cool |
and still the
process is not over |
| 03:02.50 |
dreeves |
are you
something like 64 bytes from .... |
| 03:04.12 |
rahul_cool |
sorry, but i
dont understand your question |
| 03:04.28 |
madant |
rahul_cool :
press Ctrl-C and see if you have 100 % packet loss |
| 03:05.13 |
rahul_cool |
yes 210
packets transmitted, 0 received, 100% packet loss, time
209062ms |
| 03:05.24 |
madant |
rahul_cool:
do you have any idea if you use an http proxy in your browser
settings ? |
| 03:05.53 |
rahul_cool |
yes i do use
in browser settings |
| 03:06.24 |
madant |
you have to
edit the .subversion/servers file to use the same proxy
settings |
| 03:06.48 |
madant |
i hope the
comments in the files are understandable enough for you to edit
it. |
| 03:07.07 |
rahul_cool |
ok |
| 03:07.24 |
rahul_cool |
i try
it |
| 03:08.10 |
madant |
you just have
to uncomment(remove the initial hash) two lines and put in the
proper proxy host and proxy port |
| 03:08.22 |
madant |
below the
[global] line |
| 03:08.56 |
madant |
and then try
svn checkout http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad just in case the https is giving u trouble |
| 03:09.41 |
madant |
rahul_cool: u
are doing a BS in computer science ? |
| 03:09.52 |
rahul_cool |
no
btech |
| 03:10.03 |
madant |
which year
? |
| 03:10.10 |
rahul_cool |
final
year |
| 03:10.14 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 03:10.18 |
madant |
which Univ /
college ? |
| 03:10.30 |
rahul_cool |
NIT
Kurukshetra |
| 03:11.17 |
rahul_cool |
In our
college we rarely use linux |
| 03:13.15 |
madant |
hehe.. np ..
simple things can appear complicated in the beginning
:) |
| 03:13.51 |
rahul_cool |
may i know
what u are doing?? |
| 03:14.28 |
madant |
er. me ? :D i
just passed out from IIT Kharagpur last year.. on a sabbatical
since september |
| 03:14.50 |
rahul_cool |
ok. |
| 03:15.22 |
rahul_cool |
can u plz
tell me where is .subversion/servers file?? |
| 03:15.47 |
madant |
in ur home
directory |
| 03:16.31 |
rahul_cool |
no it is not
there |
| 03:16.54 |
madant |
there is a
hidden folder .subversion . in it there is a file called servers..
if you use vim u can straight away edit it from the shell using
'vim ~/.subversion/servers' |
| 03:17.36 |
madant |
in that case
u can edit the default settings at
/etc/subversion/servers |
| 03:17.39 |
madant |
as
root |
| 03:18.40 |
rahul_cool |
got
it |
| 03:18.47 |
madant |
dreeves: any
thoughts about what exactly in nurbs ;) ? |
| 03:19.44 |
madant |
i really
loved the idea of NURBS the first time i heard about it.. as all
great ideas come.. simple yet powerful :D |
| 03:20.15 |
rahul_cool |
sorry..i dont
have any idea |
| 03:20.31 |
madant |
rahul_cool:
? |
| 03:20.40 |
madant |
sorry i
didn't get you |
| 03:21.06 |
rahul_cool |
oh oh
sorry...i thought nurbs thing |
| 03:24.40 |
rahul_cool |
hey we use
http proxy 172.16.0.1 but in that file what we have to write in
http host |
| 03:25.10 |
madant |
under the
[global] section |
| 03:25.30 |
madant |
you must have
something like # http-proxy-host =
defaultproxy.whatever.com |
| 03:25.40 |
rahul_cool |
yes |
| 03:25.55 |
madant |
replace it
with http-proxy-host = 172.16.0.1 |
| 03:26.12 |
rahul_cool |
i was doing
the same |
| 03:26.22 |
madant |
and similarly
with the next line http-proxy-port .. replace it with the port you
have to use |
| 03:26.37 |
madant |
and make sure
you remove th # at the beginning of the line |
| 03:27.10 |
rahul_cool |
ya
... |
| 03:27.24 |
madant |
and once you
have saved the changes.. svn checkout http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 03:29.38 |
madant |
getting error
messages again? |
| 03:31.09 |
rahul_cool |
wait
plz |
| 03:33.25 |
rahul_cool |
it is saying
option expected |
| 03:33.45 |
madant |
did you fill
in the http-proxy-port ? |
| 03:33.53 |
rahul_cool |
yes |
| 03:33.55 |
rahul_cool |
8181 |
| 03:34.03 |
rahul_cool |
svn:
/etc/subversion/servers:73: Option expected |
| 03:34.59 |
madant |
tell me what
is on line no: 73 of the servers file |
| 03:36.03 |
rahul_cool |
http-proxy-host = 172.16.0.1 |
| 03:36.58 |
madant |
it is the
http-proxy-host line right ? make sure it is exactly
'http-proxy-host = 172.16.0.1' and at the end of the line do a CR
(Enter) just in case |
| 03:38.50 |
rahul_cool |
thanz
buddy............. |
| 03:38.52 |
*** join/#brlcad copenhague
(n=copenhag@d206-75-233-96.abhsia.telus.net) |
| 03:38.58 |
rahul_cool |
its working
great |
| 03:38.59 |
madant |
no more
errors ? |
| 03:39.05 |
rahul_cool |
no |
| 03:39.10 |
madant |
k.. have fun
hacking brl-cad :) |
| 03:39.37 |
rahul_cool |
hey can u
help me in running brlcad?? |
| 03:40.02 |
madant |
er ? come
back to irc if you need any help ? |
| 03:40.29 |
rahul_cool |
can u give me
ur id...just in case... |
| 03:40.31 |
copenhague |
hello anyone
using salome over here? |
| 03:40.36 |
madant |
somebody will
be here most of the time.. |
| 03:40.50 |
madant |
copenhague:
anything particular ? |
| 03:41.01 |
copenhague |
just looking
for inputs |
| 03:41.11 |
copenhague |
i'm thinking
about installing it |
| 03:41.31 |
copenhague |
i think
salome is better than bricad |
| 03:41.40 |
copenhague |
what do you
think madant? |
| 03:41.41 |
madant |
aah.. i tried
it out last year.. :D remember the installation was tough on debian
:D |
| 03:41.58 |
copenhague |
now theres
the caelinux right? |
| 03:42.05 |
copenhague |
i'm on
opensuse |
| 03:42.28 |
madant |
er.. u meant
to say salome is better than brlcad ? |
| 03:42.34 |
madant |
grrr..
:D |
| 03:42.46 |
copenhague |
i don't
know |
| 03:42.49 |
copenhague |
you tell
me |
| 03:43.01 |
copenhague |
i have the
feel that is better |
| 03:43.08 |
madant |
i don't think
so.. last time i checked salome's UI and functionality was very
minimal and besides they deal with different things
really |
| 03:43.37 |
copenhague |
i think i'll
try bricad then |
| 03:43.56 |
madant |
brlcad
:) |
| 03:44.04 |
madant |
what do u
plan to use it for ? |
| 03:44.27 |
copenhague |
is there a nc
simulation on bricad? |
| 03:44.41 |
copenhague |
just to 3d
designs, modeling |
| 03:44.48 |
madant |
:) am not an
expert |
| 03:45.01 |
copenhague |
i'm a cnc
programmer and looking for modeller for free |
| 03:45.03 |
madant |
u planning to
do designs or numerical simulation ? |
| 03:45.08 |
madant |
ah..
ok.. |
| 03:45.21 |
copenhague |
designs |
| 03:45.32 |
copenhague |
and or
numerical simulations |
| 03:46.02 |
bjorkintosh |
which cnc
machine do you work with, copenhague? |
| 03:46.07 |
madant |
hmm.. i don't
have a good answer .. so i must shut up :D |
| 03:46.37 |
madant |
llikes stereolithography better ;) |
| 03:46.51 |
copenhague |
all kind, i
do programming bjorkintosh |
| 03:47.00 |
copenhague |
mills 3, 4
axis |
| 03:47.06 |
copenhague |
multiaxis
machines |
| 03:47.07 |
bjorkintosh |
lathes? |
| 03:47.09 |
bjorkintosh |
okay. |
| 03:47.19 |
copenhague |
i'm strong on
multiaxis not lathe anymore |
| 03:47.34 |
copenhague |
the multiaxis
are lathe as-well |
| 03:47.41 |
copenhague |
you? |
| 03:48.12 |
madant |
is off to church :O |
| 03:48.28 |
copenhague |
bjorkintosh,
are you into cnc? |
| 03:48.48 |
copenhague |
is there a
good cnc tool for linux other than gcam |
| 03:48.51 |
copenhague |
? |
| 03:49.35 |
madant |
copenhague ,
you should stick around.. there are some crazy people on this
channel who will be able to offer better comments :) |
| 03:49.51 |
copenhague |
sure,
thanks |
| 03:49.58 |
copenhague |
i'll be back
all teh time |
| 03:50.00 |
bjorkintosh |
copenhague,
not me. there're some crazy people ... ah, what madant
said. |
| 03:50.17 |
copenhague |
so you guys
think that i'm crazy hum. |
| 03:50.19 |
copenhague |
:) |
| 03:50.22 |
copenhague |
just
joking |
| 04:00.19 |
bjorkintosh |
i'd never
seen salome. |
| 04:00.45 |
copenhague |
http://caelinux.com/CMS/index.php?option=com_joomlaboard&Itemid=52&func=view&id=2495&catid=2 |
| 04:01.13 |
copenhague |
the last audi
car was all designed with salome and caelinux |
| 04:01.30 |
bjorkintosh |
hah. |
| 04:01.35 |
bjorkintosh |
that tells me
nothing, to be honest. |
| 04:01.48 |
bjorkintosh |
a good number
of cars were designed long before CAD tools came to
exist. |
| 04:02.02 |
copenhague |
i
know |
| 04:05.07 |
*** part/#brlcad Twerpling
(i=Twerplin@c-69-250-127-183.hsd1.md.comcast.net) |
| 04:18.25 |
*** join/#brlcad madant
(n=madant@117.196.143.210) |
| 04:19.02 |
Ralith |
bjorkintosh:
it tells you audi thought it was the appropriate tool |
| 04:20.28 |
bjorkintosh |
i rather
think it was arbitrary. |
| 04:20.45 |
dreeves |
Yeah but to
bjorkintosh that still doesn't really mean anything it could have
been the appropriate tool for alot of reasons that may not be
relevant to anyone else |
| 04:20.48 |
bjorkintosh |
they could
have achieved the same results with a good #2 pencil and a great
drawing curve. |
| 04:21.13 |
bjorkintosh |
and some
rulers too :) |
| 04:21.52 |
bjorkintosh |
but i'm
looking at salome's screenshots. |
| 04:22.10 |
bjorkintosh |
is it
pronounced 'saloMAY' or 'saLOAM'? |
| 05:24.35 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 06:04.27 |
*** join/#brlcad dreeves_
(n=dreeves@67.130.253.14) |
| 06:05.34 |
dreeves_ |
brlcad I
think addressed all the issues you brought please let me know if
you catch anymore style problems. I have defined the style in my
editor so I don't have to remember to follow the style |
| 06:05.44 |
dreeves_ |
I submitted a
new patch |
| 06:08.56 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 06:09.49 |
dreeves_ |
ok so I think
I did that wrong I submitted a whole new tacker but I realized I
should have attached so I opened the other tracker and attached
sorry about that |
| 06:13.45 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-d2fbbb50ff0f93f1) |
| 07:10.21 |
rahul_cool |
hello
all |
| 07:11.11 |
rahul_cool |
when i gave
the command ./autogen.sh for configuring ...the output
comes |
| 07:11.14 |
rahul_cool |
Unable to
locate GNU Autoconf. |
| 07:13.45 |
rahul_cool |
any one here
to solve this problem please |
| 07:39.04 |
rahul_cool |
on giving
./configure command the output comes........ |
| 07:39.16 |
rahul_cool |
configure:
error: *** compiler cannot create working executables, check
config.log *** |
| 08:32.10 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:33.13 |
*** join/#brlcad tedcx
(n=root@c-76-115-203-233.hsd1.or.comcast.net) |
| 09:52.34 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:14.59 |
piksi |
brlcad: the
no.1 thing brl-cad would need for realistic usage in architecture
and building industry is IFC |
| 10:56.40 |
*** join/#brlcad rahul_cool
(i=dce324a3@gateway/web/ajax/mibbit.com/x-9ec90ac55dff52bf) |
| 10:57.40 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:04.10 |
*** join/#brlcad LiDongyang
(n=user@122.139.161.197) |
| 11:07.02 |
rahul_cool |
hiiiiiiii |
| 11:08.08 |
_sushi_ |
brlcad: do
people keep telling you which all things are necessary in
brl-cad? |
| 11:18.54 |
louipc |
rahul_cool:
do you have autoconf installed? |
| 11:23.57 |
*** join/#brlcad LiDongya`
(n=user@222.161.68.72) |
| 11:33.21 |
brlcad |
rahul_cool:
for what it's worth, gsoc requires participants to be highly
self-motivated able to figure out problems on your own -- we're
here to help you when you get stuck, not hold you hand every step
of the way -- just keep that in mind |
| 11:37.59 |
brlcad |
dreeves_:
okay, will look at it |
| 11:40.28 |
brlcad |
piksi:
agreed, and actually rather doable given our object representation
and attribute/value system |
| 11:41.32 |
brlcad |
ifc data is
essentially metadata over a functional building representation, not
unlike what we do for modeling vehicles functionally for ballistic
analyses |
| 11:43.10 |
piksi |
brlcad: do
excuse my ignorance (haven't yet dug deep into brl features) but
how are materials represented in brl models? are composite
materials easy to use with the current system (e.g. a wall with
concrete + structural steel with insulation on top of it and panels
on top of that etc...) ? |
| 11:44.14 |
*** join/#brlcad madant
(n=madant@117.196.134.229) |
| 11:45.32 |
brlcad |
piksi: right
now, brl-cad defines material properties at a "region" level --
which is intended to refer to a single relatively homogeneous
material type per region, but then also allows application-specific
attributes to be associated with any object |
| 11:48.12 |
brlcad |
e.g. a wall
with concrete + structural steel would either be defined with a
concrete wall region and the structural steel actually modeled
(which is usuall trivial with CSG) as a region, or you make one
"wall" region and assign it the responsive properties of
'concrete+steel' as a material, or you can make it concrete and
assign it an application-specific set of attributes (such as the
structural steel properties) |
| 11:49.26 |
brlcad |
the same
continues with the insulation and panels -- brl-cad is intently
designed for high-resolution modeling so you could either physicaly
represent the insulation and panels as geometric regions, or
similar to the structural steel just associate them as
application-specific data associated with said "wall"
region |
| 11:49.40 |
brlcad |
hopefully
that makes some sense to you |
| 11:49.56 |
brlcad |
I used a fair
bit of brl-cad geometric terminology in there |
| 11:50.14 |
brlcad |
an ifc-g
importer would certainly be interesting.. |
| 11:50.23 |
brlcad |
especially
given it's also founded in express like step |
| 11:53.32 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 12:04.26 |
*** join/#brlcad andrecastelo
(n=chatzill@201008160086.user.veloxzone.com.br) |
| 12:25.09 |
*** join/#brlcad madant
(n=madant@117.196.131.64) |
| 15:31.30 |
*** join/#brlcad ashishrai
(i=dce36163@gateway/web/ajax/mibbit.com/x-139397f569e3a6e6) |
| 15:36.44 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 16:04.34 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 16:16.48 |
madant |
looking at brl-cad codeswarm : a lot of mike and jra
awesomeness till now.. lots of years left :D |
| 16:27.48 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 16:40.36 |
madant |
morrison was
brlcad :P ? |
| 16:42.20 |
madant |
and now
brlcad is morrison :D |
| 16:42.41 |
*** join/#brlcad Stuart
(n=Stuart@202-89-182-26.static.dsl.amnet.net.au) |
| 16:43.27 |
brlcad |
madant:
awesome, you should post the video up on the website! |
| 16:43.54 |
brlcad |
if there's a
way to combine names, that'd be useful |
| 16:44.13 |
brlcad |
because
several of the devs went from one username to another when the
project went open source and moved to sourceforge |
| 16:45.37 |
madant |
hmm.. i
havent made the video yet.. will put in better colours and
tweaking.. for the video i have to output each frame to png and
then combine them to make a .avi or .mov |
| 16:46.19 |
madant |
don't think
there is a name combine feature .. but supports a regex based
legend and colouration |
| 16:46.32 |
brlcad |
like
morrison->brlcad and jra->johnranderson and
bparker->bob1961, etc |
| 16:46.40 |
brlcad |
ohloh has a
list of how they all map somewhere |
| 16:46.52 |
CIA-40 |
BRL-CAD:
03bob1961 * r34057 10/brlcad/trunk/src/librt/shoot.c: A slightly
better mod to rt_res_pieces_clean() that skips uninitialized
rt_piecestate structures. |
| 16:47.01 |
brlcad |
speak of the
devil.. :) |
| 16:47.07 |
madant |
hah
:) |
| 16:48.56 |
brlcad |
wonders how it visualizes the open sourcing "event" that made
massive changes |
| 16:50.19 |
brlcad |
madant: not
sure if it's useful, but might be able to correlate what you're
looking at with this: http://brlcad.org/OLD/statcvs/
and http://brlcad.org/OLD/statcvs.normalized/ |
| 16:51.13 |
brlcad |
needs to run that again |
| 17:17.41 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:37.39 |
brlcad |
howdy
mafm_ |
| 17:40.22 |
kanzure |
hrm, so
what's up with that multitouch thread? |
| 17:41.26 |
*** join/#brlcad dreeves
(n=4382fd0e@bz.bzflag.bz) |
| 17:53.40 |
piksi |
brlcad:
thanks for a good explanation, i thjink i understood the principles
:-) |
| 18:08.01 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 18:13.12 |
*** join/#brlcad madant
(n=madant@117.196.132.30) |
| 18:18.23 |
*** join/#brlcad dreeves
(n=4382fd0e@bz.bzflag.bz) |
| 18:42.58 |
kanzure |
so I'm
writing up an email for the list regarding the
parametrics/constraints stuff yesterday, is there anything in
particular I should include that I might forget? |
| 19:19.15 |
brlcad |
kanzure: heh,
kind of a loaded question ;) |
| 19:20.24 |
kanzure |
too late now
:) sent the email |
| 19:20.27 |
kanzure |
gives his fingers a break. |
| 19:27.34 |
brlcad |
good lord
man |
| 19:27.46 |
kanzure |
bwahah |
| 19:28.05 |
brlcad |
there's like
10 discussions there |
| 19:28.09 |
kanzure |
that's
right. |
| 20:06.27 |
CIA-40 |
BRL-CAD:
03bob1961 * r34058 10/brlcad/trunk/src/librt/tree.c: Minor
formatting. |
| 20:10.14 |
CIA-40 |
BRL-CAD:
03bob1961 * r34059 10/brlcad/trunk/ (5 files in 3 dirs): Added
ged_inside_internal() to libged and modified ged_inside() to call
it. Mged also calls this when getting the inside of something being
edited. |
| 21:44.36 |
kanzure |
brlcad:
freedns.afraid.org is back up. |
| 21:56.08 |
brlcad |
kanzure: the
website may be, but the dns is still down |
| 21:56.12 |
brlcad |
try a direct
query |
| 21:56.17 |
brlcad |
nslookup
@ns1.afraid.org heybryan.org |
| 21:57.01 |
brlcad |
er,
s/nslookup/dig/ |
| 21:58.04 |
kanzure |
and your
claim that the reason that I don't yet have these problems is
because it's cached on some DNS server I'm using? |
| 21:58.30 |
kanzure |
hrm. maybe
you're just in a crummy geographical location with bad
nameservers? |
| 22:00.41 |
brlcad |
kanzure: heh,
I'm sitting a few hundred feet away from one of the 13 root name
servers on the planet |
| 22:01.41 |
brlcad |
"H" is right
here |
| 22:04.38 |
brlcad |
kanzure: my
money is on afraid.org doing something wrong or their ISP doing
something wrong |
| 22:04.53 |
brlcad |
for starters,
they have self-referential DNS .. you're not supposed to do
that |
| 22:06.29 |
brlcad |
could try
http://freedns.ws/en/ or
http://zoneedit.com |
| 22:09.35 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 22:23.57 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 23:03.17 |
*** join/#brlcad dreeves
(n=4382fd0e@bz.bzflag.bz) |
| 23:49.52 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 23:54.00 |
*** join/#brlcad cad59
(n=4f726701@bz.bzflag.bz) |
| 23:58.06 |
*** join/#brlcad Twerpling
(i=Twerplin@c-69-250-127-183.hsd1.md.comcast.net) |
| 23:58.10 |
*** part/#brlcad Twerpling
(i=Twerplin@c-69-250-127-183.hsd1.md.comcast.net) |
| 00:02.36 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 00:11.26 |
starseeker |
where was
that website with the gear stuff (that I couldn't access
yesterday?) |
| 00:36.19 |
*** join/#brlcad copenhague
(n=copenhag@d206-75-233-96.abhsia.telus.net) |
| 01:00.12 |
*** join/#brlcad copenhague
(n=copenhag@d206-75-233-96.abhsia.telus.net) |
| 01:03.28 |
*** join/#brlcad madant
(n=madant@117.196.130.28) |
| 01:10.52 |
brlcad |
dreeves:
yes |
| 01:11.23 |
brlcad |
starseeker:
pictures are worth a thousand words and probably ten thousand
equations |
| 01:11.28 |
brlcad |
(to most
people) |
| 01:11.50 |
starseeker |
ok, I'll give
it my best shot |
| 01:12.14 |
brlcad |
doesn't have
to be comprehensive, just a few illustrative examples |
| 01:12.25 |
starseeker |
nods |
| 01:12.37 |
brlcad |
or maybe a
table that shows two variables |
| 01:12.56 |
starseeker |
what I need
to do is provide the tools (intellectual, if not code) to allow
people to make use of overall length as a measurement |
| 01:13.14 |
brlcad |
e.g.,
http://local.wasp.uwa.edu.au/~pbourke/geometry/superellipse/superellipse11.gif |
| 01:13.25 |
brlcad |
speaks
wonders with a simple table |
| 01:13.31 |
starseeker |
converting
length into something useful for a coil isn't so simple |
| 01:13.56 |
starseeker |
ah,
yes |
| 01:14.04 |
starseeker |
's situation is a bit different |
| 01:15.45 |
starseeker |
I need to
teach people how to compute some other input value based on length
(unless I just skip that, but since overall length is one of the
simplest measurements a modeler can make for a coil I hate to
ignore it, too...) |
| 01:15.54 |
brlcad |
similarly,
http://cgkit.sourceforge.net/tutorials/materials/specular.jpg |
| 01:16.12 |
starseeker |
nods |
| 01:16.21 |
brlcad |
of course
it's different, the point is that you can pack a lot of data in by
picking two useful variables |
| 01:16.21 |
starseeker |
I actually do
that for most of the coil settings :-) |
| 01:16.44 |
madant |
wakes up and realises he has a lot to read
:D |
| 01:16.47 |
starseeker |
yes, but it's
worse than that - there are two different equations that have to be
used |
| 01:17.01 |
starseeker |
based on
certain geometric behaviors |
| 01:17.01 |
brlcad |
i'm sure it
is |
| 01:17.08 |
brlcad |
but in the
end, you're making a spring |
| 01:17.12 |
starseeker |
sure |
| 01:17.15 |
brlcad |
so you show a
few tables |
| 01:17.30 |
brlcad |
they don't
need to know every shape ever possible |
| 01:17.42 |
starseeker |
oh, I
know |
| 01:18.02 |
starseeker |
but using
length to calculate parameters is something else again |
| 01:18.13 |
starseeker |
can't just
show examples |
| 01:18.17 |
starseeker |
need to
outline method |
| 01:18.28 |
brlcad |
e.g. the
superellipse table has a dozen other parameters that you could
tweak that would make things even more complicated -- they're just
not nearly as useful and the extra information really just confuses
the core explanation |
| 01:19.58 |
starseeker |
nods |
| 01:20.26 |
starseeker |
Realistically, I don't HAVE to say a word
about overall length - it's not an input parameter |
| 01:20.41 |
starseeker |
could just
leave it up to the modeller |
| 01:22.19 |
starseeker |
was just
trying to anticipate difficulties that would come up in real world
use |
| 01:41.03 |
brlcad |
you could
certainly make it an input parameter as that's probably very true
:) |
| 01:42.12 |
brlcad |
to me a
coil's basic properties are it's overall length, radius, wire
thickness, and number of windings or density of
windings |
| 01:43.05 |
brlcad |
if the user
has to perform a bunch of calculations to arrive at their desired
length, that sounds like something prime for the application to
handle for them |
| 01:45.35 |
brlcad |
otherwise my
basic point regarding the diagrams was that you should just enough
to get the gist of what it is and does, not necessarily explain
every or even most of the details -- that can be captured in the
writeup and (if needed) the equations themselves |
| 01:51.07 |
starseeker |
nods |
| 01:53.16 |
starseeker |
the problem
with length as an input parameter is it makes ONE of several other
parameters unnecessary, but not uniquely - e.g. length + pitch +
wire diameter will settle helix angle (in most cases, there is
actually one corner case with two solutions) but by the same token
length + wire diameter + helix angle will settle pitch. I'm still
not sure how to automagically use length "correctly" to solve for
the right value |
| 01:53.43 |
starseeker |
short of a
lot of special case programming (yuck) |
| 02:01.37 |
brlcad |
you allow the
unnecessary parameters and just do a validation check on your
arguments |
| 02:02.36 |
brlcad |
think of how
rt will let you specify an image -- you can specify a square image
size, width, height, aspect ratio, cell size, and a few other
things .. and specifying any of those often makes any of the others
unnecessary |
| 02:02.53 |
brlcad |
but it still
lets you, and deals with the calcs and validation |
| 02:03.07 |
brlcad |
well pseudo
validation, last one wins iirc |
| 02:03.36 |
brlcad |
yep, last
one |
| 02:03.50 |
brlcad |
(e.g., rt
-s1024 -n512 -w512) |
| 02:32.02 |
*** join/#brlcad madant_
(n=madant@117.196.136.61) |
| 02:43.41 |
starseeker |
brlcad: ok,
so I would put in the equations for each parameter deducable from
length, solve whichever ones I could based on inputs, and if one
input was "missing" that length is supposed to substitute for that
calculation would succeed and would replace the
default? |
| 02:44.40 |
starseeker |
supposes he might as well, since he needs to add the ability
to do left and right handed coiling anyway |
| 02:44.49 |
brlcad |
you have a
set of parameters you "need" to calculate |
| 02:44.56 |
brlcad |
to calculate
the coil, that is |
| 02:45.07 |
starseeker |
yes |
| 02:45.15 |
brlcad |
presumably
there is some default if you just run the program? |
| 02:45.20 |
brlcad |
(should
be) |
| 02:45.22 |
starseeker |
yes |
| 02:45.36 |
brlcad |
then each arg
adjusts the defaults however it makes sense |
| 02:45.45 |
brlcad |
sort of like
an overlay |
| 02:46.11 |
brlcad |
so if given
-l 100 .. all those inputs are adjusted however makes sense for -l
100 to work |
| 02:46.27 |
starseeker |
there isn't a
unique solution to that |
| 02:46.40 |
brlcad |
then if
followed by some other arg -coil_density 1.0, whatever, even
something that conflicts, it readjusts |
| 02:46.52 |
brlcad |
but there is
a consistent solution I bet |
| 02:47.03 |
starseeker |
consistent? |
| 02:47.07 |
brlcad |
'valid' |
| 02:47.12 |
starseeker |
sure,
several |
| 02:47.31 |
brlcad |
so they've
underspecified, but it's enough to work with |
| 02:47.36 |
brlcad |
technically
the defaults are underspecified |
| 02:48.24 |
madant_ |
needs a faster computer :D |
| 02:48.59 |
starseeker |
yes, but what
is the "preferred" way to adjust? reduce number of coils and tweak
wire diameter? change the helix angle? |
| 02:49.16 |
starseeker |
I suspect the
answer to that is "yes", which is where the problem comes
in |
| 02:50.23 |
starseeker |
If I
underspecify by one input parameter and add length, I expect length
to be solved for the missing parameter |
| 02:50.32 |
starseeker |
if I
underspecify by two, it gets less clear |
| 02:50.56 |
starseeker |
underspecifying by one is a fair bit of
work (solve the length equations for all variables) but
doable |
| 02:51.09 |
starseeker |
the second
involves "picking something" |
| 02:51.52 |
starseeker |
presumably
the default would usually be zero helix angle, I
guess... |
| 02:52.07 |
starseeker |
maybe that
could be the "last assumption to go..." |
| 02:55.19 |
*** join/#brlcad double-yang
(n=bravehea@124.115.173.231) |
| 02:57.24 |
brlcad |
'yes' |
| 03:02.55 |
brlcad |
like I said,
I'd expect the dominant params be
length+coil_diameter+wire_diameter+#coils if I was making
one |
| 03:03.20 |
brlcad |
but then I
don't have a need to make coils repeatedly as a modeling task,
that's just my common sean expectation |
| 03:03.53 |
brlcad |
pitch to me
is just a specialization that replaces #coils |
| 03:04.16 |
brlcad |
and
pitch+#coils replaces length |
| 03:04.35 |
starseeker |
pitch is
spacing between coils |
| 03:04.51 |
brlcad |
yeah |
| 03:04.55 |
starseeker |
well,
ok |
| 03:05.07 |
starseeker |
stores those to use as defaults... |
| 03:05.39 |
brlcad |
internally
maybe you turn everything into just #coils and pitch |
| 03:05.54 |
starseeker |
no, helix
angle is distinct |
| 03:05.59 |
starseeker |
as is wire
diameter |
| 03:06.30 |
brlcad |
i mean per
that example if that was your dependency matrix, you find *some*
set that you use internally |
| 03:06.37 |
starseeker |
oh |
| 03:07.08 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177592936.dsl.bell.ca) |
| 03:07.09 |
brlcad |
e.g., rt
doesn't store -s1024 anywhere |
| 03:07.31 |
brlcad |
it just keeps
a buffer and a width and height |
| 03:07.36 |
starseeker |
oh,
sure |
| 03:07.56 |
starseeker |
brlcad: I
take it you haven't played with the existing coil tool much?
:-) |
| 03:08.04 |
brlcad |
so it might
get a little tricky, but it should be doable given you can make a
default coil |
| 03:08.28 |
brlcad |
i don't have
to play with the tool to know how argument handling should be able
to work :) |
| 03:08.33 |
starseeker |
heh |
| 03:08.39 |
*** join/#brlcad andre|away_
(n=chatzill@189.71.33.19) |
| 03:08.41 |
brlcad |
even for
outright conflicting args, it doesn't matter |
| 03:09.14 |
starseeker |
as a user might prefer a warning if he feeds in conflicting
args... |
| 03:09.33 |
brlcad |
always a good
thing |
| 03:09.41 |
brlcad |
could even
halt |
| 03:09.51 |
starseeker |
nods |
| 03:09.59 |
brlcad |
s/could/should/ |
| 03:10.22 |
brlcad |
just not
requisite, not much halts as it is |
| 03:10.44 |
starseeker |
sighs - nevermind about proofreading, looks like it will be a
while (more functionality to add first) |
| 03:11.32 |
starseeker |
starts visualizing how to deal with length issues...
hmm... |
| 03:12.07 |
starseeker |
ah well, low
priority anyway |
| 03:12.21 |
starseeker |
brlcad:
thanks for the feedback/help :-) |
| 03:12.39 |
brlcad |
that's why
it's often/usually good to implement the interface/api/args before
the implementation so you can think about it from the user's
perspective before getting bogged down in what the implemenation
needs :) |
| 03:13.02 |
brlcad |
otherwise you
just end up exposing implementation detail to the user and that
makes them go 'wtf' |
| 03:13.16 |
brlcad |
dsp anyone..
wtf |
| 03:13.35 |
starseeker |
got scared off initially by all the math needed to handle
length ;-) Existing parameters are actually based on how springs
are "usually" defined |
| 03:13.51 |
starseeker |
just happens
that length is the easy one to <measure> |
| 03:13.55 |
starseeker |
chuckles at dsp |
| 03:14.34 |
brlcad |
well, there's
usually defined by *spring-makers* and by *consumers* of
spring-makers .. which are rarely the same |
| 03:14.57 |
starseeker |
nods |
| 03:16.48 |
starseeker |
actually, for
springs with severe helical angle length can be a bit tricky too,
come to think of it... |
| 03:17.57 |
brlcad |
kinda what
I'm referring to:
http://www.lovells.com.au/catalogue/2004-08_catalogue_4x4_springs_v2.pdf |
| 03:18.03 |
brlcad |
page
4 |
| 03:18.24 |
brlcad |
that's how I
think of springs, how I'd be trying to specify one |
| 03:19.30 |
dreeves |
So is the
nurbs implementation displaying the wireframe correctly
now? |
| 03:19.42 |
brlcad |
it should
be |
| 03:19.49 |
brlcad |
just it won't
show trimmed surfaces |
| 03:20.03 |
brlcad |
it'll show
that outer extent, maybe the trimming curve itself |
| 03:20.14 |
brlcad |
(too) |
| 03:20.37 |
starseeker |
brlcad:
thank you for that link, that's very helpful |
| 03:21.31 |
brlcad |
dreeves: it
doesn't tessellate the surfaces yet, just the extents, if that's
what you mean by correctly |
| 03:21.52 |
brlcad |
but
otherwise, yeah - I don't know of any actual "problem" with what it
shows other than being simple |
| 03:22.02 |
dreeves |
yes that is
what I was asking |
| 03:22.03 |
brlcad |
raytracing is
where there are problems |
| 03:22.38 |
brlcad |
eek, I gotta
catch some z's before practice |
| 03:22.39 |
dreeves |
right but I'm
just trying to get an idea of what I'm shooting for :) |
| 03:23.00 |
dreeves |
practice for
what? |
| 03:24.37 |
brlcad |
dreeves: if
you want to start with a tangible issue on the current code base,
you could look at breplicator or one of the other two cubes, take
any corner point of the cube and pull it inward to make two of the
faces non-planar |
| 03:24.51 |
brlcad |
that's a
relatively specific bug that will probably lead deep down the
rabbit hole |
| 03:24.58 |
brlcad |
practice for
crew |
| 03:25.01 |
brlcad |
rows |
| 03:25.23 |
starseeker |
just not
gently down a stream ;-) |
| 03:26.32 |
brlcad |
mm, yeah..
kinda windy tomorrow and cold |
| 03:26.53 |
brlcad |
welp, ta
ta |
| 03:26.59 |
starseeker |
later - have
fun! |
| 03:28.39 |
double-yang |
I'm a student
who wants to apply GSoC project. |
| 03:29.09 |
double-yang |
May I ask
someting about that? |
| 03:29.27 |
madant_ |
hi
double-yang |
| 03:29.34 |
brlcad |
starseeker:
http://www.vanel.com/compression.php?lang=english |
| 03:29.44 |
madant_ |
what do you
have in mind ? |
| 03:29.47 |
brlcad |
yummy,
http://www.vanel.com/compression-conical.php?lang=english |
| 03:30.25 |
brlcad |
welcome
double-yang, glad to hear it, gotta run, have fun talking to the
other guys ;) |
| 03:30.43 |
double-yang |
I'm
considering |
| 03:31.23 |
double-yang |
@brlcad:Thanks |
| 03:33.37 |
madant_ |
double-yang:
any specific ideas on what you would liek to work on ? |
| 03:34.36 |
double-yang |
@brlcad:I saw
you assorted those idears inyo two parts, High Priority and
Additional |
| 03:34.38 |
madant_ |
s/liek/like |
| 03:35.51 |
double-yang |
madant_:Implicit to Explicit boundary
representation support |
| 03:37.36 |
double-yang |
madant_:I'm
interest in this one |
| 03:38.44 |
double-yang |
madant_:What
do you prefer? |
| 03:39.11 |
madant_ |
sorry didn't
get you |
| 03:39.54 |
double-yang |
http://brlcad.org/wiki/Google_Summer_of_Code/2009/Project_Ideas |
| 03:40.34 |
madant_ |
:) hehe..
oh.. i have been working with brl-cad since last year on
parametrics and constraints :) |
| 03:40.56 |
double-yang |
Oh,sorry. |
| 03:41.09 |
madant_ |
I wrote 1.7
:) |
| 03:41.23 |
double-yang |
Great! |
| 03:41.36 |
madant_ |
not at all ..
so have you thought about how you would go about the project
? |
| 03:43.11 |
madant_ |
the existing
brep files give a pretty good idea about the work
involved |
| 03:43.29 |
double-yang |
I'm a student
in physics department |
| 03:43.42 |
madant_ |
ah kewl.
which univ. |
| 03:44.20 |
double-yang |
Northwest
Univ in China |
| 03:45.41 |
madant_ |
hehe nice :)
ä½ å¥½é©¬ |
| 03:46.41 |
double-yang |
ÄãÖÐÎIJ»´í:) |
| 03:47.52 |
madant_ |
argh..
something wrong with encoding.. am only getting
ÄãÖÐÎIJ»´í:) |
| 03:48.03 |
madant_ |
nyways poolio
is the brep guy :) |
| 03:50.57 |
double-yang |
ÄãÖÐÎIJ»´í
means your Chinese is good :) |
| 03:52.55 |
double-yang |
madant_:So
are you a mentor of the GSoC ? |
| 03:53.40 |
madant_ |
double-yang:
hehe.. i meant i am only getting some weird roman charaters only
instead of the chinese logographs.. must be something to do with my
client settings |
| 03:53.50 |
madant_ |
double-yang:
and nope i am not a mentor :) |
| 03:54.22 |
madant_ |
is very much interested in Physics albeit an architect by
education :D |
| 03:54.45 |
double-yang |
:) |
| 03:55.00 |
madant_ |
is still in an earnest approach to finishing the 10 volumes
of Landau's course of theoretical physics |
| 03:55.50 |
madant_ |
double-yang:
have u already built brl-cad ? |
| 03:56.04 |
madant_ |
and did u
check out the brep code for ell, nmg etc ? |
| 03:56.56 |
double-yang |
madant_:No,
actually. |
| 03:57.15 |
double-yang |
I'm a new guy
here |
| 03:58.19 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 03:58.53 |
double-yang |
You know that
Open Source is not very popular in my nation. |
| 03:59.01 |
madant_ |
no problem :)
everybody is new at some point .. |
| 03:59.21 |
madant_ |
you could
check out the subversion repository and tinker around
:) |
| 03:59.27 |
madant_ |
http://brlcad.org/wiki/SVN |
| 04:00.41 |
double-yang |
Thanks for
your link. |
| 04:02.08 |
madant_ |
you can also
view the code online at http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/ |
| 04:03.32 |
madant_ |
the
primitives are here.. as mentioned in the wiki some of them already
have brep
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/librt/primitives/ |
| 04:05.11 |
double-yang |
These will be
a great of help!:) |
| 04:08.29 |
double-yang |
It's really a
exciting experience to chat with all of you. |
| 04:10.18 |
madant_ |
double-yang:
our pleasure.. do come back and tell us your brl-cad building
experience and further adventures |
| 04:10.49 |
double-yang |
madant_:Sure.:) |
| 04:12.17 |
double-yang |
madant_:It's
time for lunch.I have to go. |
| 04:13.21 |
madant_ |
bye
double-yang |
| 04:13.38 |
double-yang |
madant_:Nice
to talking to you.Bye.:) |
| 04:36.21 |
*** join/#brlcad jonored_
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 05:15.01 |
*** join/#brlcad madant_
(n=madant@117.196.145.180) |
| 05:50.42 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 06:02.01 |
*** join/#brlcad madant_
(n=madant@117.196.148.148) |
| 06:23.43 |
*** join/#brlcad anirudh
(i=75c77135@gateway/web/ajax/mibbit.com/x-921b0e406d6af1f5) |
| 06:25.20 |
anirudh |
hi |
| 06:25.28 |
anirudh |
any mentors
around here |
| 06:25.39 |
anirudh |
for google
soc |
| 06:29.20 |
anirudh |
hey |
| 06:29.24 |
anirudh |
anyone around
? |
| 06:40.52 |
yukonbob |
hey,
cadheads |
| 06:41.03 |
yukonbob |
anirudh:
what's your question? |
| 06:42.07 |
anirudh |
hey |
| 06:42.15 |
anirudh |
i want to
propose an idea |
| 06:42.30 |
anirudh |
its not on
the list, its simple |
| 06:42.53 |
anirudh |
CAD
manipulations using Multitouch gestures |
| 06:43.14 |
anirudh |
can i do a
proposal based on something like that :) |
| 06:48.12 |
anirudh |
anyone
around |
| 06:48.38 |
yukonbob |
sounds like
you're proposing a new input device and driver and complete
suppport in the application... |
| 06:49.19 |
*** join/#brlcad anirudh
(i=75c77135@gateway/web/ajax/mibbit.com/x-47fa24cfc39f8a5c) |
| 06:49.24 |
yukonbob |
;) |
| 06:49.27 |
anirudh |
no |
| 06:49.37 |
yukonbob |
go
on... |
| 06:49.45 |
anirudh |
can you copy
paste the last chat u said :P i got dc |
| 06:50.16 |
yukonbob |
I was saying
that it sounds like you're proposing a new device, driver and
BRL-CAD interface... |
| 06:50.43 |
yukonbob |
remember that
the project ought to be achievable in the timeframe
proposed. |
| 06:51.06 |
anirudh |
not a device
exactly, a lot of people have alredy built their DIY Multitouch
tables |
| 06:51.17 |
anirudh |
have you seen
touchlib ? |
| 06:51.25 |
anirudh |
its an open
source tracker for touches |
| 06:51.50 |
yukonbob |
I've heard of
it, not programmed against it... |
| 06:52.17 |
yukonbob |
do you have
experience programming against touchlib, and have a working
device? |
| 06:52.19 |
anirudh |
the TUIO
protocol it has, i have to send TUIO data on port 3000 and BRLCAD
will listen to that data |
| 06:52.22 |
anirudh |
yeah |
| 06:52.30 |
anirudh |
www.sparsh-i.com |
| 06:52.43 |
anirudh |
check out the
video i've put up of my device :) |
| 06:53.13 |
anirudh |
CAD
manipulations using multitouch would add a lot of functionality and
ease the interaction process |
| 06:53.27 |
anirudh |
the way
people interact with CAD |
| 06:53.39 |
anirudh |
it'll ease
the process, i believe ;) |
| 06:54.00 |
yukonbob |
I'm imagining
easing spinning/flipping a la Jeff Hahn |
| 06:54.14 |
yukonbob |
for wireframe
static views.... |
| 06:54.17 |
anirudh |
yeah |
| 06:54.17 |
anirudh |
right
:) |
| 06:54.30 |
anirudh |
that's
precise , but it wasnt CAD i believe |
| 06:55.21 |
yukonbob |
the vids I've
seen were sorting photographs, navigating blobs of "Lava lamp" goo
;) |
| 06:56.18 |
yukonbob |
anirudh: do
you have a direct link to the video, so I can view via mplayer (/me
doesn't have flash-enabled ffox) |
| 06:56.19 |
anirudh |
yeah |
| 06:56.20 |
anirudh |
thats for the
eye candy :P |
| 06:56.20 |
anirudh |
I plan
drawing based on Gestures |
| 06:57.18 |
anirudh |
its uploaded
on vimeo |
| 06:57.18 |
anirudh |
can you
access that ? |
| 06:57.22 |
anirudh |
wait |
| 06:58.17 |
anirudh |
flv works
? |
| 06:58.22 |
anirudh |
http://www.vimeo.com/moogaloop/play/clip:2953423/d1d4af0d0fe684209fb3beb8b344e662/1237564800/video.flv?q= |
| 06:58.40 |
anirudh |
i got a
direct link via keepvid site, it allows direct downloading of
videos |
| 06:58.47 |
anirudh |
yukon you
around ? |
| 06:59.18 |
yukonbob |
y |
| 06:59.36 |
yukonbob |
I think your
paste was truncated... |
| 06:59.54 |
anirudh |
didnt it work
? |
| 07:00.26 |
anirudh |
http://www.vimeo.com/moogaloop/play/clip:2953423/d1d4af0d0fe684209fb3beb8b344e662/1237564800/video.flv |
| 07:00.35 |
anirudh |
see it now, i
hope it should work ! |
| 07:00.36 |
anirudh |
:) |
| 07:01.10 |
anirudh |
see the DJ
app on multitouch, music mixing we did on the touch
surface |
| 07:02.48 |
anirudh |
now a days
making MT pads and tables isnt hard with so much DIY info around...
Dell's XT laptop and HP Touchsmart are alredy popular, Apple will
be releasing all its screens soon based on Multitouch |
| 07:03.17 |
yukonbob |
hrmm... no
dice (via curl) |
| 07:03.30 |
anirudh |
?? |
| 07:03.39 |
yukonbob |
better via
ffox... |
| 07:03.41 |
yukonbob |
1
sec |
| 07:03.47 |
anirudh |
yep
:P |
| 07:11.22 |
yukonbob |
nice |
| 07:11.27 |
yukonbob |
all your own
footage? |
| 07:15.46 |
*** join/#brlcad sourav
(i=d2d43703@gateway/web/ajax/mibbit.com/x-fa6b69a709c7f646) |
| 07:18.30 |
yukonbob |
needs to hit hay --- anirudh, I'd post the idea to the wiki,
and if you have the cycles, don't hesitate to begin a
proof-of-concept or some other demo |
| 07:19.23 |
yukonbob |
see: http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
| 07:19.41 |
anirudh |
yeah |
| 07:19.51 |
anirudh |
its me and my
classmates on the video :) |
| 07:19.59 |
yukonbob |
nice
indeed. |
| 07:20.20 |
anirudh |
hey, also
give me ur google talk id , if u use that |
| 07:20.40 |
yukonbob |
don't have
one atm... |
| 07:21.23 |
yukonbob |
I need to hit
hay (work tomorrow), but don't hesitate to talk to me, brlcad (the
user here in IRC), or starseeker, or ``Erik |
| 07:22.20 |
anirudh |
hehe
yea |
| 07:22.31 |
yukonbob |
chat later
:) |
| 07:22.48 |
anirudh |
bbye :) so
you got my idea, right ? :) |
| 07:22.50 |
anirudh |
thanks |
| 07:22.52 |
hippieindamakin8 |
anirudh, u
sent that proposal of mt eh ? |
| 07:22.53 |
anirudh |
laters
man |
| 07:23.00 |
anirudh |
yeah |
| 07:23.09 |
anirudh |
yep
hippie |
| 07:23.24 |
hippieindamakin8 |
wait that was
ashish kumar rai |
| 07:24.04 |
anirudh |
??? |
| 07:24.17 |
anirudh |
is confused |
| 07:24.24 |
anirudh |
what's up ?
are you ashish ? |
| 07:27.23 |
hippieindamakin8 |
anirudh, no
:) i am hippieindamakin8 :) |
| 07:29.23 |
*** join/#brlcad double-yang
(n=bravehea@124.115.173.231) |
| 07:43.54 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 07:55.15 |
*** part/#brlcad anirudh
(i=75c77135@gateway/web/ajax/mibbit.com/x-47fa24cfc39f8a5c) |
| 08:05.12 |
*** join/#brlcad madant
(n=madant@117.196.148.148) |
| 08:56.00 |
brlcad |
yawns |
| 09:05.11 |
madant |
huh awake
already ? i thought u just went to sleep |
| 09:06.13 |
madant |
is getting his lappie heating up trying to build
minion |
| 09:27.20 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:32.54 |
*** join/#brlcad cad84
(n=c30722f9@bz.bzflag.bz) |
| 10:41.14 |
*** join/#brlcad madant
(n=madant@117.196.148.148) |
| 11:13.55 |
madant |
aah
apparently double-yang's real name is Yang Yang :) |
| 11:35.49 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:51.18 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:59.43 |
brlcad |
madant: I had
:) |
| 11:59.57 |
brlcad |
few hours is
plenty |
| 12:00.16 |
brlcad |
if I could
get away with less and function safely, I would :) |
| 12:06.18 |
*** join/#brlcad madant
(n=madant@117.196.148.148) |
| 12:10.59 |
*** join/#brlcad andre|away
(n=chatzill@189.71.33.19) |
| 12:53.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 13:13.45 |
*** join/#brlcad madant
(n=madant@117.196.145.150) |
| 13:22.32 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:50.18 |
*** join/#brlcad cad85
(n=4eb73307@bz.bzflag.bz) |
| 13:52.33 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 13:52.49 |
CIA-40 |
BRL-CAD:
0378.183.51.7 07http://brlcad.org *
r1285 10/wiki/Building_from_SVN: /* Install */ |
| 14:00.40 |
*** join/#brlcad double-yang
(n=bravehea@124.115.173.231) |
| 14:01.02 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.33.19) |
| 14:08.19 |
*** join/#brlcad madant_
(n=madant@117.196.135.163) |
| 14:30.56 |
*** join/#brlcad madant
(n=madant@117.196.135.163) |
| 14:36.42 |
CIA-40 |
BRL-CAD:
03Louipc 07http://brlcad.org *
r1286 10/wiki/URL_URI_URN_Implimentations: Typos |
| 15:15.31 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34060 10/rt^3/trunk/ (4 files in 2 dirs): added the
arb8 object |
| 15:17.51 |
brlcad |
neat |
| 15:18.07 |
brlcad |
louipc: care
to take a stab at fixing that bug :) |
| 15:19.09 |
louipc |
brlcad: can
you reproduce it or is it just me? |
| 15:19.14 |
madant |
brlcad: how
was rowing :) |
| 15:25.41 |
louipc |
brlcad:
you're referring to the ogl reattach bug right? |
| 15:25.48 |
brlcad |
louipc:
yes |
| 15:25.50 |
brlcad |
madant:
fantastic |
| 15:25.59 |
brlcad |
actually
kinda crappy today, but fantastic to be rowing |
| 15:26.15 |
brlcad |
was windy,
boat couldn't be set well |
| 15:26.26 |
louipc |
arr |
| 15:27.00 |
brlcad |
matey |
| 15:27.06 |
louipc |
I would like
to stab the bug, but I think it's beyond my sorry level of
understanding |
| 15:27.07 |
madant |
learned swimming only recently :D , would love to row
sometime |
| 15:27.35 |
brlcad |
rowing
doesn't generally require swimming unless you're doing something
wrong :) |
| 15:27.53 |
louipc |
haha |
| 15:27.58 |
louipc |
swimming is a
good back-up |
| 15:28.38 |
brlcad |
the oars
float ;) |
| 15:31.37 |
madant |
:D
hah.. |
| 15:32.21 |
madant |
i would
really not like to be in the middle of a big lake and not know
swimming :D even if it is a big boat :P |
| 15:34.04 |
brlcad |
there's a
"flip test" in crew where they intentionally put you in a single
skull boat and make you flip it (with you in it) |
| 15:34.52 |
brlcad |
the test is
to unstrap yourself from the boat (so you don't drown), get out
from under it, flip the boat back over, and then actually get back
into the boat (which is way way harder than it sounds) |
| 15:35.14 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 15:35.31 |
starseeker |
wonders why the heck he slep so late and gets his butt in
gear... |
| 15:42.04 |
brlcad |
hopefully not
first gear ;) |
| 15:42.22 |
brlcad |
is excited about the bsg finale |
| 15:45.17 |
madant |
doesnt like his image of flip test :D |
| 15:46.46 |
jonored_ |
brlcad:
Sounds like what I was doing the first several times out in a
kayak... |
| 15:48.01 |
jonored_ |
Well, apart
from the intentional part. That was only in the lake. |
| 15:49.18 |
madant |
hmm..
kayaking is quite different from rowing ? |
| 15:52.49 |
brlcad |
they make you
do it in a single simply because it *will eventually
happen |
| 15:52.55 |
brlcad |
just a matter
of time :) |
| 15:53.09 |
_sushi_ |
rowing on a
gym rowing machine doesn't require swimming :) |
| 15:53.16 |
jonored_ |
madant: It
is, but the practice is the same idea. Although in a kayak there's
the stuff you do after that of learning to just get back up without
getting out of the boat. |
| 15:53.37 |
_sushi_ |
eskimo? |
| 15:53.39 |
brlcad |
there was a
great shot at the olympics last year where this pair was *way*
ahead of the competition .. and they ended up flipping like 20ft in
front of the finish line |
| 15:53.53 |
brlcad |
they tried
swimming with their boat across the finish line |
| 15:53.59 |
brlcad |
didn't quite
make it, but was hilarious |
| 15:55.17 |
jonored_ |
Hilarious.
sushi: Yep. Girlfriend can do it in a small kayak but not a sea
one, and I can't yet at all. Going to be able to. |
| 15:55.39 |
_sushi_ |
do you need
strength for that? |
| 15:55.39 |
louipc |
kayaks are
awesome |
| 15:55.52 |
brlcad |
_sushi_:
rowing on an erg is more akin to torture .. |
| 15:56.43 |
brlcad |
at least
outside you have these amazing sights (water, waves,
sunrises/sunsets, etc), sounds of the water and boats, fresh air ..
serene |
| 15:57.09 |
_sushi_ |
I don't find
water waves sounds of water boats and fresh air amazing |
| 15:57.15 |
_sushi_ |
But i find
sunsets and sunrises amazing |
| 15:57.34 |
_sushi_ |
But what's
really amazing is the sun in noon |
| 15:57.36 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34061 10/rt^3/trunk/ (10 files in 2 dirs): IsValid
method is now required for all Objects |
| 15:58.25 |
brlcad |
in the best
times of the year (end of spring, beginning of fall), I usually get
to see the sunrise over the water and sunsets almost on a daily
basis |
| 15:58.37 |
brlcad |
it can be
very surreal |
| 15:58.44 |
_sushi_ |
I saw a
sunset at the sea once |
| 15:58.49 |
_sushi_ |
Nothing
really special |
| 15:58.58 |
_sushi_ |
I find
sunsets in Prague more beautiful |
| 15:59.06 |
brlcad |
not really
the same thing at sea |
| 15:59.40 |
_sushi_ |
Those are
sights everyone knows |
| 15:59.54 |
_sushi_ |
But
interesting is for example a red beam of light going through fog in
the night |
| 15:59.59 |
_sushi_ |
You can see
how the fog is moving inside |
| 16:00.59 |
brlcad |
exactly what
I'm trying to say, it's NOT something you normally see anywhere
unless you live at a marina |
| 16:01.24 |
_sushi_ |
why does a
marina sunset special? |
| 16:01.34 |
brlcad |
the fog
rushes out as the sunrise begins, the hour preceeding is tiny white
and red lights of your boat and other small craft |
| 16:01.55 |
_sushi_ |
what is tiny
white? |
| 16:02.02 |
brlcad |
very quiet,
water can be almost glasslike |
| 16:02.38 |
_sushi_ |
oh that
sounds sureeal |
| 16:02.44 |
brlcad |
boats have
lights just like cars |
| 16:02.52 |
brlcad |
well, not
just like them |
| 16:02.54 |
brlcad |
but
similar |
| 16:03.19 |
_sushi_ |
don't boats
make waves? |
| 16:03.21 |
brlcad |
white light
in front to let other boats know which way you are facing,
red/green in rear (to let you know which side you are
on) |
| 16:03.32 |
_sushi_ |
How can it be
glasslike when there are boats running around? |
| 16:03.38 |
_sushi_ |
Or do they
shine even when they are parked? |
| 16:04.03 |
brlcad |
crew boats
barely disturb the water, they sort of slice through it |
| 16:04.16 |
_sushi_ |
what's a crew
boat? |
| 16:04.32 |
brlcad |
if you have a
good crew, you literally only see small concentric puddles where
the oars went in and a small V behind the boat |
| 16:04.58 |
_sushi_ |
and if you
have a bad crew? |
| 16:06.41 |
brlcad |
http://www2.sacschool.com/uploads/images/Rowing%20Club%20-%20Facilities.jpg |
| 16:07.10 |
brlcad |
then the
water is just distrubed a little more, not quite as
precise |
| 16:07.17 |
_sushi_ |
how much watt
do you generate when rowing? |
| 16:07.38 |
_sushi_ |
I mean net
mechanical output on the body->boat interface |
| 16:08.07 |
brlcad |
yeah, I know
what you mean -- I forget the actual numbers |
| 16:08.45 |
brlcad |
rowing is
actually rated as one of the highest VO2 maxing sports out there as
it activates almost every muscle in the body |
| 16:09.17 |
_sushi_ |
I think about
5 sports are now rated as the higest VO2max |
| 16:09.24 |
_sushi_ |
swimming
cycling etc. |
| 16:09.29 |
_sushi_ |
depends on
who you are talking to |
| 16:09.45 |
_sushi_ |
I am sure you
ask a programmer he will tell you programming is the highest VO2
maxing sport out there |
| 16:10.05 |
brlcad |
don't have
the reference, but like the top 10 VO2-max tested athletes is
something like half rowers and half cylists |
| 16:10.19 |
_sushi_ |
Does it also
activate the ear drum tension muscle? |
| 16:10.26 |
brlcad |
heh |
| 16:10.27 |
_sushi_ |
yeah lance
armstrong |
| 16:10.39 |
_sushi_ |
his body is
directly oxidizing steroidz |
| 16:11.10 |
_sushi_ |
lance always
wins because the other cyclists puncture on the hypodermic needles
he leaves behind |
| 16:11.48 |
brlcad |
http://en.wikipedia.org/wiki/VO2_max#VO2_max_Levels
has a little tidbit about the max capacity of rowers in the third
paragraph |
| 16:12.51 |
_sushi_ |
<PROTECTED> |
| 16:12.57 |
_sushi_ |
I am sure I
must be the other group |
| 16:14.13 |
_sushi_ |
Siberian dogs
running in the Iditarod Trail Sled Dog Race sled race have VO2
values as high as 240 ml/kg/min. |
| 16:14.20 |
_sushi_ |
I think we
need some genetic conditioning |
| 16:14.54 |
brlcad |
mine has more
than doubled in the past when I've gone from static (being a lazy
punk) to training mode (2x per day, 6 days per week) |
| 16:15.12 |
_sushi_ |
how old were
you when you did it? |
| 16:15.13 |
brlcad |
took more
than a season |
| 16:15.38 |
brlcad |
mid-20's |
| 16:15.48 |
_sushi_ |
I started to
go to work on bike |
| 16:15.56 |
_sushi_ |
I threw out
my municipal transport prepaid |
| 16:16.03 |
_sushi_ |
I don't know
if this increases my VO2max |
| 16:16.08 |
_sushi_ |
but I stopped
feeling like zombie |
| 16:16.13 |
_sushi_ |
and I need
less hours of sleep |
| 16:16.16 |
_sushi_ |
and my face
looks better |
| 16:16.30 |
_sushi_ |
I go
comfortable pace |
| 16:16.37 |
_sushi_ |
As fast as
comfortable |
| 16:16.47 |
brlcad |
resting heart
rate is often correlated -- did your HR decrease? |
| 16:16.55 |
brlcad |
if it did,
VO2 almost certainly incrased |
| 16:16.56 |
_sushi_ |
I don't
know |
| 16:17.41 |
_sushi_ |
I am too lazy
to measure |
| 16:17.42 |
*** join/#brlcad madant
(n=madant@117.196.134.36) |
| 16:19.47 |
_sushi_ |
brlcad: can a
comfotable physicalactivityincreaqse VO2max? |
| 16:20.54 |
madant |
increase in
VO2max by comfort ..don't think so :) |
| 16:21.06 |
_sushi_ |
torture is
necessary? |
| 16:21.36 |
madant |
haha.. well
not torture per se.. i hear high intensity interval training is
pretty effective |
| 16:21.52 |
_sushi_ |
what is
that? |
| 16:22.11 |
madant |
weirdly remember the quote "Pain is inevitable, Suffering is
Optional" |
| 16:23.10 |
madant |
well interval
training is when you do say 20 seconds of strenuous work followed
by 10 seconds of recovery.. or some similar interval..
:) |
| 16:23.20 |
madant |
http://en.wikipedia.org/wiki/High-intensity_interval_training |
| 16:23.20 |
brlcad |
_sushi_:
yeah, I don't think you can without increasing your anaerobic
threshold |
| 16:23.25 |
_sushi_ |
like
strenuous dishwashing? |
| 16:23.28 |
brlcad |
(which is
akin to torture) |
| 16:23.54 |
brlcad |
loves interval training when at the gym |
| 16:23.55 |
madant |
_sushi_: can
imagine dishwashing being pretty strenuous :D |
| 16:24.02 |
_sushi_ |
brlcad: I
don't understand do you think comfotable bike ride increases my Vo2
max? |
| 16:24.14 |
brlcad |
don't like
interval when out on the road though for some reason |
| 16:24.21 |
brlcad |
_sushi_: no,
I don't |
| 16:24.31 |
brlcad |
I think it
maintains your max |
| 16:24.38 |
brlcad |
plenty of
other benefits, of course |
| 16:24.47 |
brlcad |
just not your
max oxygen capacity |
| 16:24.49 |
_sushi_ |
can you die
from having low VO2max? |
| 16:24.53 |
brlcad |
at least not
after a couple weeks |
| 16:24.53 |
madant |
I don't like
going to the gym :) more of a bodyweight exercise person
:D |
| 16:25.15 |
brlcad |
_sushi_: heh,
of suffocation, sure :) |
| 16:25.24 |
madant |
haha
:D |
| 16:25.24 |
brlcad |
VO2max ==
0.0L/min |
| 16:25.28 |
_sushi_ |
lol |
| 16:25.45 |
_sushi_ |
that must be
my figure |
| 16:25.46 |
_sushi_ |
or
negative |
| 16:26.07 |
brlcad |
it's
exceptionally low, though .. try breathing through a coffee
stirring straw .. see how long you can keep it up |
| 16:26.19 |
brlcad |
generally not
enough for most people |
| 16:27.06 |
brlcad |
you can
adjust to crazy low values, though |
| 16:27.09 |
_sushi_ |
I once run
12km in 55 minutes |
| 16:27.12 |
_sushi_ |
and it was
comfortable |
| 16:27.17 |
brlcad |
folks living
in high-altitudes do it all the time |
| 16:27.26 |
_sushi_ |
if I leave
out stress on the knees |
| 16:27.33 |
_sushi_ |
So it doesn't
increase my VO2max>? |
| 16:28.45 |
brlcad |
no, that just
increases your cardiovascular efficiency, aerobic
capacity |
| 16:28.52 |
_sushi_ |
omg |
| 16:28.56 |
brlcad |
to increase
your max, you have to press your anaerobic capacity |
| 16:29.02 |
_sushi_ |
aha |
| 16:29.17 |
_sushi_ |
like in
gym? |
| 16:29.18 |
brlcad |
(while
sustaining/increasing aerobic) |
| 16:29.25 |
brlcad |
heh, doesn't
matter where |
| 16:29.36 |
_sushi_ |
weight
lifting is anaerobic |
| 16:29.43 |
brlcad |
yes, usually
is |
| 16:29.50 |
_sushi_ |
does it
increase VO2max? |
| 16:29.53 |
brlcad |
you can
actually do aerobic weight lifting |
| 16:29.56 |
brlcad |
it just looks
silly |
| 16:30.27 |
_sushi_ |
fortunatelly
gay guys on dates don't test VO2max |
| 16:30.31 |
_sushi_ |
they just
test muscle mass |
| 16:30.33 |
brlcad |
it rarely
does afaik simply because you end up taking so many breaks -- you
don't sustain/increase your aerobic, it decreases if you only
lift |
| 16:30.38 |
_sushi_ |
and training
for that is comfortable for me :) |
| 16:31.00 |
brlcad |
if you did
circuit training though, you probably could increase it |
| 16:31.10 |
_sushi_ |
circuit
training? |
| 16:31.15 |
_sushi_ |
I do circuit
design |
| 16:31.42 |
brlcad |
heh, not the
same thing |
| 16:31.48 |
_sushi_ |
what is
it? |
| 16:31.56 |
brlcad |
http://en.wikipedia.org/wiki/Circuit_training |
| 16:32.47 |
brlcad |
basically
sort of like weight lifting with NO breaks |
| 16:33.15 |
madant |
longs to go beyond the 6 minute mile |
| 16:33.18 |
brlcad |
you have to
lift less weight because eventually you'll be out of breath as your
muscles are activated |
| 16:33.32 |
brlcad |
madant: 6min?
that's pretty damn good |
| 16:33.43 |
madant |
er.. 6:12
:D |
| 16:33.51 |
_sushi_ |
can do it on a bicycle |
| 16:33.52 |
brlcad |
for casual
gym go-er at least |
| 16:33.58 |
brlcad |
heh |
| 16:34.05 |
_sushi_ |
I am always
amused when I realize |
| 16:34.10 |
madant |
but after
that mile i am pretty bust :D |
| 16:34.27 |
_sushi_ |
when I cough
up blood it's just a barely average untrained person
performance |
| 16:34.47 |
_sushi_ |
Maybe
something is wrong with my body |
| 16:35.04 |
_sushi_ |
some chemical
is missing in some chain? |
| 16:35.14 |
madant |
you cough up
blood ? |
| 16:35.29 |
_sushi_ |
I don't mean
it literally |
| 16:35.37 |
madant |
ah thought so
:D |
| 16:36.04 |
madant |
has a bad sense of humor |
| 16:36.07 |
brlcad |
my best mile
was somewhere around 4:50 iirc |
| 16:36.20 |
madant |
brlcad:
awesome :) |
| 16:36.25 |
brlcad |
but that was
back in HS/college, no fucking way now :) |
| 16:36.37 |
brlcad |
my knees
would explode |
| 16:36.42 |
louipc |
hmm! mged -c
doesn't even offer ogl as an attach option in my latest
build |
| 16:36.58 |
brlcad |
louipc: yeah,
current trunk defaults ogl off for now |
| 16:37.07 |
brlcad |
because of a
couple bugs.. :) |
| 16:37.15 |
_sushi_ |
brlcad: that
was with rocket engine in the ass? |
| 16:37.17 |
madant |
brlcad: for
me still pretty much VO2max is the issue.. legs are ok
;) |
| 16:37.35 |
madant |
hahah
:D |
| 16:38.12 |
_sushi_ |
Rule #1: if
the spoon doesn't stand in your protein shake, you'll not build up
any muscles |
| 16:38.30 |
_sushi_ |
I thought
I'll die when we had running on the high school |
| 16:38.40 |
_sushi_ |
I guess for
me even youth didn't help |
| 16:39.03 |
_sushi_ |
I just
decided to triple the amount of protein in my shakes |
| 16:39.09 |
madant |
_sushi_: :) i
have never had protein shakes :D and i don't have big muscles
either :D but they are growing.. just takes longer i guess .. and
size strength correlation is very fuzzy :) |
| 16:39.12 |
louipc |
brlcad:
ahh |
| 16:39.18 |
_sushi_ |
Maybe I'll be
able to put on some nanograms of muscle mass |
| 16:39.25 |
madant |
not to
mention size-strength-endurance :D |
| 16:39.44 |
_sushi_ |
madant: in
me, protein shakes grow probably only fat |
| 16:40.02 |
_sushi_ |
I can select
if I want to be bones-skin or bones-fat-skin |
| 16:40.09 |
madant |
is a dumbo on the nutrition front |
| 16:40.22 |
_sushi_ |
If the cycle
that synthesizes muscle were implemented in me, it would
help |
| 16:41.19 |
_sushi_ |
my doctor
said I have "slim heart" and that I am "generally
asthenic" |
| 16:41.30 |
_sushi_ |
I guess it's
just a medical word for "your DNA is crap" |
| 16:41.37 |
madant |
:D |
| 16:42.05 |
_sushi_ |
or "half of
the protein codes that make a functioning male from you are
overwritten by a random garbage" |
| 16:45.35 |
_sushi_ |
Is there a
way how to monitor your total muscle mass? |
| 16:46.55 |
louipc |
dip yourself
in chocolate |
| 16:49.52 |
_sushi_ |
and slurp it
all up? |
| 16:50.37 |
louipc |
you would
have to know the mass of your fat/bone/skin/organs and subtract it
from your total mass. hmm |
| 17:48.26 |
*** join/#brlcad cad39
(n=3bb29912@bz.bzflag.bz) |
| 17:57.03 |
brlcad |
woo hoo,
subversion 1.6 is out |
| 18:01.31 |
starseeker |
awesome |
| 18:01.39 |
starseeker |
checks subversion new features list |
| 18:03.01 |
starseeker |
hmm... tree
conflicts |
| 18:04.19 |
starseeker |
wonders how they will factor in with stable
merges... |
| 18:04.51 |
*** join/#brlcad jonored_
(n=jonored@pool-72-74-104-129.bstnma.east.verizon.net) |
| 18:05.06 |
brlcad |
interactive
conflict resolution |
| 18:05.06 |
starseeker |
yay -
improved interactive conflict resolution at command
line |
| 18:06.21 |
starseeker |
sqlite is now
required |
| 18:13.40 |
starseeker |
is reminded of other potential uses for sqlite and looks up
its docs... |
| 18:14.58 |
brlcad |
tis very
simple to use, pretty tiny lib |
| 19:27.36 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 19:37.15 |
brlcad |
hello
BigAToo |
| 20:23.17 |
*** join/#brlcad mota__
(n=mota@117.199.117.93) |
| 20:23.28 |
*** part/#brlcad mota__
(n=mota@117.199.117.93) |
| 20:24.50 |
*** join/#brlcad anirudhsharma
(n=mota@117.199.117.93) |
| 20:25.02 |
anirudhsharma |
hi any
mentors around here |
| 20:25.13 |
anirudhsharma |
hippie you
there ? |
| 20:27.21 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 20:28.35 |
anirudhsharma |
hi
starseeker |
| 20:28.38 |
anirudhsharma |
are you
there |
| 20:28.48 |
anirudhsharma |
need to
discuss my thing with you |
| 20:28.52 |
anirudhsharma |
google soc
idea |
| 20:34.56 |
hippieindamakin8 |
anirudhsharma, yeah |
| 20:35.29 |
anirudhsharma |
what's your
name dude ? |
| 20:35.30 |
starseeker |
anirudhsharma: what's up? |
| 20:35.37 |
anirudhsharma |
pretty good ,
yeah |
| 20:36.33 |
anirudhsharma |
hey
dude |
| 20:36.41 |
anirudhsharma |
when do the
mentors come online |
| 20:36.48 |
anirudhsharma |
need to
discuss my idea with them |
| 20:37.06 |
anirudhsharma |
since my
exams are going on , i can't really :) hehe |
| 20:48.30 |
brlcad |
tries to go into more detail for daniel |
| 20:50.01 |
brlcad |
~anirudhsharma-- |
| 20:50.02 |
brlcad |
that'd be
interesting, use a karma point system while evaluating
applicants |
| 21:36.37 |
*** join/#brlcad dreeves_
(n=dreeves@67.130.253.14) |
| 22:02.08 |
Ralith |
people always
work out how to abuse quantitative systems |
| 22:26.05 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 22:57.56 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 23:18.06 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.33.19) |
| 23:19.26 |
andrecastelo |
good evening
everyone :) |
| 23:21.50 |
madant |
andrecatstelo: howdy.. just woke up 4: 45
am here :D |
| 23:24.02 |
andrecastelo |
madant: hehe,
good evening from gmt - 3 :D |
| 23:27.36 |
madant |
:D what are u
upto these days ;) |
| 23:38.54 |
andrecastelo |
madant:
finishing some class projects due to next week ;) |
| 23:39.11 |
andrecastelo |
i'm trying to
move 'open source development' up in the priority list |
| 23:39.13 |
andrecastelo |
:D |
| 23:45.57 |
*** join/#brlcad redvsblue
(n=pancake@c-69-242-189-29.hsd1.mo.comcast.net) |
| 00:08.13 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 00:45.18 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:09.21 |
``Erik__ |
fucking
goddamn motherfucking |
| 04:00.00 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 05:27.20 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 06:46.42 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:21.16 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:23.16 |
*** join/#brlcad madant
(n=madant@117.196.145.149) |
| 10:31.31 |
d-lo |
Mornin! |
| 10:58.21 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 10:58.21 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 10:58.21 |
*** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198)
[NETSPLIT VICTIM] |
| 10:58.21 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 11:19.59 |
*** join/#brlcad reddy
(i=8984030b@gateway/web/ajax/mibbit.com/x-10aee6cfe6bc4020) |
| 11:40.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 11:42.23 |
brlcad |
howdy |
| 11:49.16 |
d-lo |
hai! |
| 11:49.33 |
*** join/#brlcad PrezKennedyJR
(i=Matthew@whitecalf.net) |
| 11:57.50 |
*** join/#brlcad piksi_ (i=piksi@pi-xi.net) |
| 12:06.48 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:12.39 |
*** join/#brlcad madant_
(n=madant@117.196.136.120) |
| 13:06.50 |
*** part/#brlcad reddy
(i=8984030b@gateway/web/ajax/mibbit.com/x-10aee6cfe6bc4020) |
| 13:42.58 |
``Erik |
takes a few to say some impolite things to the
universe. |
| 13:44.45 |
d-lo |
``Erik: Whats
going on? |
| 13:45.32 |
``Erik |
had a booboo
yesterday, no car |
| 13:45.59 |
``Erik |
nose drifted
on me, the sheriff thinks mebbe something in the steering linkage
broke :/ ate a curb, which is a biggie on something like
that |
| 13:46.59 |
d-lo |
injuries? |
| 13:47.04 |
``Erik |
given that
the blue one had been in a frame damaging episode and the black one
was ground hard by a kid who thinks subs are part of a performance
car, mebbe I need to STOP buying these things used |
| 13:47.08 |
``Erik |
no, it was
just a curb bump |
| 13:47.15 |
``Erik |
in your car,
you woulda laughed and kept rolling |
| 13:47.37 |
d-lo |
Well,
different machines for different purposes. |
| 13:48.03 |
``Erik |
I'm gettin'
old, man. the purpose is looking more and more like a point A to
point B thing |
| 13:48.09 |
d-lo |
How bad is
the insurence deductable going to be? |
| 13:48.14 |
``Erik |
1k |
| 13:48.25 |
``Erik |
and my fault,
so yet more premium |
| 13:48.25 |
d-lo |
is having a bad spelin day. |
| 13:48.40 |
d-lo |
well thats
plain shitty. |
| 13:49.14 |
``Erik |
I can eat
it... the car is paid off and I have enough to run off and buy a
reasonably nice car out of pocket, but *shrug* still
sucks |
| 13:49.29 |
d-lo |
take a few
years off and get a good ol reliable honda. |
| 13:49.33 |
d-lo |
:) |
| 13:49.51 |
``Erik |
heh, I drove
dumber in my old honda than I've done in any of the bmw's
:) |
| 13:49.58 |
d-lo |
Do the damage
is all cosmetic? |
| 13:50.00 |
``Erik |
was a $300
crapper, and I tore the shit out of it |
| 13:50.09 |
``Erik |
no, the front
right wheel was shifted |
| 13:50.37 |
``Erik |
apparently, I
hate the front starboard wheel. A lot. |
| 13:50.41 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 13:50.47 |
``Erik |
that was the
one I demolished in the blue one |
| 13:51.30 |
d-lo |
I think you
need to start driving in the middle of the road. Keep those curbs
equidistant ;) |
| 13:51.47 |
``Erik |
yeah, y'know,
folk around here don't appreciate that missoura style
driving |
| 13:52.04 |
archivist |
just
concentrate on driving! |
| 13:52.16 |
``Erik |
backroads of
the ozarks, people seriously drive in the middle and only move to
the side when there's oncoming traffic |
| 13:52.37 |
``Erik |
I was
concentrating! I just went around the corner to buy a pizza :( the
nose drifted out when it REALLY should not have |
| 13:53.01 |
``Erik |
I mean, I
stop, I turn right, the nose slides... wtf, it's a rear wheel
vehicle, if I was being stupid, the ass woulda gave out |
| 13:53.04 |
``Erik |
er |
| 13:53.06 |
``Erik |
turn
left |
| 13:53.11 |
``Erik |
(across
traffic) |
| 13:53.44 |
d-lo |
The only
accident I have ever been in involved the steering column giving
out.... so I know the drill :/ |
| 13:53.45 |
``Erik |
starts wondering if some of the debris he collected was not
his own and that's what he tagged and slid on
O.o |
| 13:54.41 |
d-lo |
....you could
get a Tesla! |
| 13:55.04 |
``Erik |
at the
moment, I'm trying to figure out if it'd be more economically
viable to buy a used car and sell it when I get my m back, or rent
one |
| 13:55.05 |
``Erik |
heh |
| 13:55.15 |
``Erik |
tesla's are
nice, but they have competition in their niche now :) |
| 13:55.38 |
d-lo |
Does your
insurance cover rentals? |
| 13:55.47 |
``Erik |
and I kinda
like the comfort factor more than the go-kart factor :/ I'm
old |
| 13:55.53 |
``Erik |
no |
| 13:55.57 |
d-lo |
feck |
| 13:56.04 |
``Erik |
supposedly,
allstate has a discount agreement with enterprise |
| 13:56.07 |
d-lo |
and the BMW
dealer doesn't have a loner? |
| 13:56.09 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 13:56.10 |
``Erik |
but I didn't
pay for rental coverage |
| 13:56.37 |
``Erik |
I'm sure they
do, and they'd probably give me one and a handjob given how much
money I've given them, but I'm waiting for the inspector to look
over my car |
| 13:56.51 |
d-lo |
thats the way
it always goes, isn't it.... |
| 13:57.04 |
``Erik |
indeed |
| 13:57.18 |
d-lo |
inspector =
insurance adjustor? |
| 13:57.21 |
``Erik |
I need to
push this lisp shit so'z I can get a positive cash flow and retire
here :) never drive again heh |
| 13:57.34 |
``Erik |
um, she
called him an inspector, but I'm sure it's the same |
| 13:57.54 |
``Erik |
job is to
look over the vehicle and come up with an estimate and options on
repair/replacement(iftotalled) |
| 13:59.05 |
``Erik |
I'm hoping
it's just a matter of some new a-frames, wheel, tire, air dam,
fender, and some steering stuff |
| 13:59.27 |
d-lo |
ah, okay.
inspector == adjustor. |
| 13:59.41 |
d-lo |
so, how did
the Po-Po call it? |
| 13:59.59 |
``Erik |
the sheriff
figured that something in the steering probably broke |
| 13:59.59 |
d-lo |
Failure to
control vehicle or something? |
| 14:00.04 |
``Erik |
no
ticket |
| 14:00.12 |
d-lo |
no fault!
awesome. |
| 14:00.15 |
``Erik |
gave me a
ride home |
| 14:00.19 |
d-lo |
:) |
| 14:00.21 |
``Erik |
insurance is
saying it's all my fault, of course |
| 14:00.35 |
d-lo |
well, they
have to bill someone :( |
| 14:00.42 |
``Erik |
of
course |
| 14:00.53 |
d-lo |
its not like
those monthly payments you make actually mean
anything... |
| 14:01.00 |
``Erik |
doubt I'd
have much of a court case, though |
| 14:01.16 |
``Erik |
heh, dude,
after the blue one, I'm so far ahead I just don't care |
| 14:01.55 |
brlcad |
or
two! |
| 14:01.59 |
d-lo |
Well, if you
work closely with the mechanics, you might be able to have them
'officially state' the failure. Could help keep your rates
down. |
| 14:02.11 |
``Erik |
perhaps |
| 14:02.15 |
``Erik |
I intend to
be involved |
| 14:02.25 |
``Erik |
hey, brlcad,
can I borrow your car for a bit? ;) |
| 14:02.35 |
d-lo |
brlcad: get
to swim today? ;) |
| 14:02.38 |
archivist |
methinks
NO |
| 14:02.45 |
brlcad |
d-lo:
almost! |
| 14:02.52 |
brlcad |
guy right
next to me did |
| 14:03.04 |
``Erik |
swim? |
| 14:03.15 |
``Erik |
oh, was this
a rowwing morning? |
| 14:03.19 |
``Erik |
rowing,
even |
| 14:03.21 |
archivist |
fell
in |
| 14:03.26 |
brlcad |
we were on
the docks and I was pushing one of the eight-man boats away from
the docks |
| 14:03.39 |
brlcad |
high winds,
it was drifting back into the docks and towards our
boat |
| 14:04.00 |
brlcad |
I slip
slightly, but got my footing, then I hear *splash* |
| 14:04.09 |
d-lo |
doh! |
| 14:04.10 |
brlcad |
my bowman was
in the water |
| 14:04.16 |
``Erik |
do you wear
surf shoes when you do that? |
| 14:04.31 |
brlcad |
no, there are
shoes in the boat |
| 14:04.38 |
``Erik |
(guy? as a
bowman? I thought they were usually skinny chicks) |
| 14:04.53 |
brlcad |
so folks are
usually in shoes or flip flops, and take them off to get strapped
into the boat |
| 14:05.07 |
``Erik |
s/are
shoes/are no shoes/ ? |
| 14:05.29 |
brlcad |
8-man boat, I
was in "2 seat", so there's one buy behind me in "1 seat" aka "bow
seat", also the "bow man" |
| 14:05.53 |
``Erik |
wouldn't that
be... a stern man? :D |
| 14:05.54 |
brlcad |
``Erik: no,
there ARE shoes attached to the boat |
| 14:05.59 |
``Erik |
ohhhh |
| 14:06.03 |
brlcad |
no, they go
backwards :) |
| 14:06.40 |
``Erik |
ponders turtling when your shoes are bolted to the boat
O.o |
| 14:06.54 |
brlcad |
anyways,
basically a guy fell off the docks and into the water |
| 14:07.05 |
brlcad |
ice freaking
cold, 10mph winds |
| 14:07.16 |
brlcad |
pretty funny,
it happens |
| 14:07.36 |
d-lo |
``Erik: Shoes
glued to boat == incentive not to sink. Its a throw back to the
viking days :) |
| 14:07.40 |
``Erik |
was in a canoe that rolled in lagoon in mebbe 20f,
UNfun |
| 14:07.46 |
brlcad |
d-lo: hehe,
indeed |
| 14:08.08 |
brlcad |
they are all
"quick release" velcro style in case the boat flips |
| 14:08.16 |
``Erik |
upside down,
wet, freezing... everything goes crazy |
| 14:08.45 |
d-lo |
20 degree
water will confuse pretty quick :) |
| 14:08.45 |
brlcad |
one of the
things you get tested for in order to row alone, flipping the boat
fully strapped in |
| 14:09.17 |
``Erik |
assumed the boat was a simple aluminium monocoque structure,
didn't think there'd be shoes glued in :) |
| 14:09.26 |
d-lo |
Hrm, is that
a 'phobia? |
| 14:09.33 |
brlcad |
there's
barely any metal on them boats |
| 14:09.37 |
brlcad |
that'd be
insane |
| 14:09.41 |
``Erik |
20f air temp,
I'm sure the water was a bit warmer |
| 14:09.44 |
brlcad |
and
heavy |
| 14:09.59 |
``Erik |
hm, all
fiberglass now? |
| 14:10.04 |
brlcad |
they're all
fibreglass/composites -- just the oar riggers are metal |
| 14:10.17 |
``Erik |
pheers nanotube boats |
| 14:10.19 |
brlcad |
some older
boats are thin wood (and insanely heavy) |
| 14:10.40 |
``Erik |
aight, I d'no
rowing :) canoes and day sailors |
| 14:10.52 |
``Erik |
so I'm kinda
assuming a lot of canoe traits |
| 14:10.53 |
brlcad |
they're like
bicycles .. the price jacks up really fast to save just a couple
pounds weight |
| 14:11.53 |
d-lo |
only knows boats with a sink/surface ratio == 1.0
;) |
| 14:12.23 |
``Erik |
I thought the
person with the box facing 'the wrong way' was called the bowman?
is that a... cockswain? |
| 14:12.23 |
brlcad |
yeah, not
really the same construction at all -- most crew boats are so light
that you're only allowed to step on just one part in the
boat |
| 14:12.24 |
brlcad |
otherwise
it's so thin, you can step right through it |
| 14:12.26 |
``Erik |
<-- too
weak to row, too fat to be a cockswain :) |
| 14:12.32 |
brlcad |
heh,
coxswain |
| 14:12.44 |
``Erik |
cock |
| 14:12.45 |
``Erik |
swain |
| 14:13.02 |
``Erik |
she's a cock
swan, and you know it :> *duck* |
| 14:13.14 |
``Erik |
sorry, I'll
behave O:-) |
| 14:13.28 |
brlcad |
oh, most of
them are shorty cuties (the girls at least) |
| 14:14.22 |
d-lo |
phears short girls who can beat most men at arm wrestling
8-| |
| 14:14.50 |
``Erik |
coxswain
doesn't row, they face the other way and give
instructions |
| 14:14.52 |
``Erik |
iirc |
| 14:15.00 |
archivist |
admits watching the ladies 8's in Cambridge UK
entertaining |
| 14:15.30 |
d-lo |
new book:
"How to beat a joke to death" by ``Erik . |
| 14:15.44 |
starseeker |
``Erik:
given your luck with cars, maybe we should get you a motorcycle
:-) |
| 14:15.48 |
``Erik |
oh... that
was a joke? :> |
| 14:15.57 |
``Erik |
trying to
kill me off, cliff??? |
| 14:16.15 |
d-lo |
starseeker: I
was thinking an uparmored MRAP vehicle. |
| 14:16.17 |
archivist |
you dont need
help |
| 14:16.23 |
``Erik |
was on the
phone with my mom this morning, she said I needed a jeep, I told
her I need a tonka truck |
| 14:16.34 |
starseeker |
``Erik: In
such a vehicle you would be compelled to drive carefully
;-) |
| 14:16.58 |
d-lo |
I can see
``Erik in a jeep. That fits. |
| 14:17.09 |
starseeker |
my
grandparents have an old 70s caddy - good luck flipping that
sucker |
| 14:17.18 |
``Erik |
the nose
drifted! it was effin' weird, the sheriff said that something
probably broke as I was cornering! |
| 14:17.19 |
d-lo |
33"
mudders... 152 KC lamps on the double rollbar... |
| 14:17.42 |
``Erik |
I mean, from
a stop, across a left turn, in a rwd... the nose drifts |
| 14:17.43 |
``Erik |
wtf? |
| 14:18.03 |
brlcad |
<PROTECTED> |
| 14:18.05 |
starseeker |
hmm - well,
we could get you one of those racing cars that can blow apart and
leave the driver intact |
| 14:18.16 |
starseeker |
brlcad: uh,
oh - is he sick? |
| 14:18.20 |
``Erik |
how's the dog
doing? still trying to stick his nose in fire? |
| 14:18.27 |
brlcad |
starseeker:
no, he's dying |
| 14:18.32 |
starseeker |
:-( |
| 14:18.33 |
``Erik |
starseeker:
that's what I have. |
| 14:18.37 |
``Erik |
he's what, 17
now? |
| 14:18.42 |
brlcad |
he's just
very old, conjestive heart failure |
| 14:18.47 |
brlcad |
yeah,
17 |
| 14:18.49 |
starseeker |
brlcad:
sorry to hear that |
| 14:18.52 |
d-lo |
hell, that
sucks. |
| 14:18.59 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 14:19.04 |
``Erik |
blind, deaf,
.. a fighter |
| 14:19.04 |
starseeker |
remembers what it was like losing his dog when he was
young |
| 14:19.05 |
brlcad |
most days are
good, but last night wasn't one of them |
| 14:19.28 |
brlcad |
he's coming
into a higher dosage of meds now, but need to keep an eye on
him |
| 14:19.47 |
starseeker |
you don't
find a better friend than a good dog |
| 14:20.05 |
``Erik |
sure can
smell out a piece of hotdog that fell, though heh :) |
| 14:20.06 |
d-lo |
brlcad: Are
you going to let nature take its course or are you going to have
him put down? |
| 14:20.22 |
brlcad |
d-lo:
depends |
| 14:20.47 |
starseeker |
``Erik: heh,
no kidding. |
| 14:21.05 |
brlcad |
will let
nature take it's course unless he's suffering for more than a day
or two |
| 14:21.36 |
starseeker |
's dog used to follow us around whenever we brought food out
- figured out pretty quick that small kids dropped food a fairly
high percentage of the time |
| 14:21.41 |
d-lo |
brlcad: we
made the same choice when it came to Sandy's 15 y/o cat.
|
| 14:21.59 |
brlcad |
he's only had
two brief episodes where he's what I'd consider suffering, only to
get better the next days (and stay better for a couple months
afterwards) |
| 14:22.33 |
d-lo |
well thats
good then. |
| 14:22.58 |
``Erik |
at j-lo's
bday a couple years ago, we went to the park off the road to the
island, brlcad's dog kept trying to shove his face into the coals
to get at grease drippings and bits of hotdogs and hamburgers
:) |
| 14:23.11 |
starseeker |
ow |
| 14:23.22 |
starseeker |
j-lo? |
| 14:23.35 |
``Erik |
wow, a couple
years ago heh :( nettie was preggo iirc, and twingy's gf was
visiting or something |
| 14:24.19 |
starseeker |
dogs are
crazy for food even when they can see |
| 14:24.57 |
``Erik |
googles for "dognip" |
| 14:25.05 |
brlcad |
he would have
totally gone for that food even with his eyesight |
| 14:25.07 |
``Erik |
huh, whuddya
know, "meat" |
| 14:25.12 |
starseeker |
ours was
given a piece of cake for his birthday once - he ate it in one
gulp, realized what it was and proceeded to spend the next 10
minutes chasing the plate all over the yard licking at
it |
| 14:25.20 |
brlcad |
and probably
gotten it without getting hurt even, but didn't want to risk it
with him blind |
| 14:25.57 |
``Erik |
plus the
issue of the grill burning the top of his head :( poor little
guy |
| 14:26.37 |
brlcad |
barney lives
to eat, the days he can't eat are the days I know he's not happy..
when there are fewer happy days than unhappy days, it'll be
time |
| 14:27.17 |
starseeker |
nods |
| 14:27.34 |
``Erik |
he's a good
little guy, I'm glad I got to meet him :) |
| 14:28.06 |
brlcad |
starseeker:
couple years ago I accidentally dropped an entire buffalo wing
(drumstick) .. big one too .. barney snatched it up and swallowed
it whole in about half a second |
| 14:28.18 |
starseeker |
hehe |
| 14:28.20 |
``Erik |
wow, that
musta hurt the next day |
| 14:28.20 |
brlcad |
I just
blinked in disbelief, moment of panic, more disbelief |
| 14:28.33 |
brlcad |
nope, didn't
even phase him |
| 14:28.48 |
starseeker |
has concluded that "gulp then taste" approach is common to
most dogs |
| 14:29.03 |
starseeker |
at least,
until they get fed an onion |
| 14:29.18 |
``Erik |
hah |
| 14:29.24 |
brlcad |
thing is,
he's a tiny dog .. I swear the drumstick was bigger than his
mouth |
| 14:29.36 |
starseeker |
wow |
| 14:29.36 |
brlcad |
like a snake,
detached that jaw and sucked it down |
| 14:29.37 |
``Erik |
gf's son just
decided he likes onion a lot, still trying to puzzle that one
out |
| 14:30.06 |
starseeker |
has fought the good fight against onions for 20 years
;-) |
| 14:30.22 |
starseeker |
brlcad:
impressive :-) that would have made a great video |
| 14:30.30 |
``Erik |
I used to
hate them, decided I love 'em... nice bulking item |
| 14:30.39 |
``Erik |
heh, youtube
ftw? O.o |
| 14:31.05 |
starseeker |
depending on
the dog/drumstick size ratio, could have made america's
funniest |
| 14:31.12 |
``Erik |
he swallowed
the bone? |
| 14:31.30 |
d-lo |
"Drumstick/Dog size ratio"
......lol |
| 14:31.47 |
starseeker |
new standard
unit |
| 14:32.21 |
starseeker |
alrightie,
time to stick the bills in the mail (ouch) |
| 14:32.21 |
``Erik |
my car gets
32 kfc drumsticks to the poodle, and that's how I like
it! |
| 14:32.22 |
brlcad |
``Erik: he
swallowed the drumstick thing whole, one swipe |
| 14:32.40 |
brlcad |
nice big
breaded one from pats |
| 14:33.21 |
starseeker |
``Erik: I
wouldn't tell the SPCA you consider poodles a unit of distance
;-) |
| 14:33.22 |
``Erik |
'k, I'm not a
chicken eater, it has chemical reprecussions... so'z help me out
here, there was bone inside of what your dog swallowed? |
| 14:33.33 |
``Erik |
unit of
volume, starseeker, get it right |
| 14:33.50 |
starseeker |
well, from
the standpoint of a car... |
| 14:36.29 |
d-lo |
I *think* the
next Top Gear is the one where they are going to be road testing
the Tesla and a bunch of other 'alternate' fuel cars... i really
wanna see that one. |
| 14:37.11 |
``Erik |
would rather just work from home and have the needed stores
be walking distance :( |
| 14:37.39 |
brlcad |
``Erik: yes,
a pretty big one |
| 14:37.58 |
``Erik |
brlcad: and
he... didn't have issue passing it? O.O |
| 14:38.25 |
d-lo |
``Erik: would
like to see a nation wide system of pneumatic tubes. Even if they
only moved things and not people. *THOOMP* "Honey! Pizza's
here!" |
| 14:38.28 |
``Erik |
I'm thinkin'
something mebbe 15 cm long |
| 14:38.33 |
``Erik |
10-15 |
| 14:38.49 |
``Erik |
*thoomp*
wait, suicide booth? BITE MY SHINEY METAL ASS |
| 14:38.53 |
d-lo |
lol |
| 14:39.19 |
_sushi_ |
lol |
| 14:39.29 |
_sushi_ |
I have a
pneumatic tube on my bicycle |
| 14:39.33 |
_sushi_ |
Makes a
smooth ride |
| 14:40.11 |
``Erik |
dave, I think
I have my lithp distance calculator working correctly, I need to
test it out some... if it works, then I can do a pretty simple a*
style 'best path' solver |
| 14:40.23 |
d-lo |
lithp?
haha |
| 14:40.39 |
``Erik |
lithp, yeth.
yethterdayth flight gave me thome coding time |
| 14:40.40 |
d-lo |
Sexy! |
| 14:41.18 |
``Erik |
once I have
teh fng data in, I'm thinking the appropriate algo is
to: |
| 14:41.48 |
``Erik |
take the
subset of jg's higher than current. For each, solve which is the
shortest time to terminal desination. |
| 14:42.08 |
``Erik |
Given the
best single move, repeat. |
| 14:42.57 |
``Erik |
reasonable? |
| 14:43.05 |
d-lo |
Hrm, whats
the problem you are trying to solve? I don't see it. |
| 14:43.26 |
``Erik |
um, I have a
fleet at alpha, I want to get to beta... what's the fastest I can
get there? |
| 14:43.33 |
``Erik |
give me the
convoluted path |
| 14:43.39 |
brlcad |
``Erik: sorta
like these: (but a lil bigger) http://www.ironhorsepa.com/wings.jpg |
| 14:44.04 |
``Erik |
there's
nothing in that image to confer size |
| 14:44.10 |
brlcad |
no trouble
passing it at all (he's used to eating tons of wierd stuff -- he
used to eat almost whatever I ate) |
| 14:44.26 |
``Erik |
scale,
rather |
| 14:44.53 |
d-lo |
okay got it.
How does the logic handle if yoru fleet isn't on a FNG controlled
planet? or a planet without a JG? |
| 14:45.23 |
d-lo |
brlcad: damn
it, now I am hungry. |
| 14:45.28 |
``Erik |
d-lo: say I
have fleet in a sector on no jg, there's a l2 jg in the secor,
there's an l9 jg in the region, I want to go to a new galaxy... I
assume my algo will tell me to jump to the l2, then jump to the l9,
then jump to the target |
| 14:45.47 |
``Erik |
0 is a valid
number, I'm not roman. |
| 14:46.04 |
brlcad |
d-lo: me
too! |
| 14:46.20 |
d-lo |
``Erik: okay,
cool. Then yes, sounds reasonable. |
| 14:46.21 |
``Erik |
*sob* and I
ain't got no car to meet up |
| 14:46.43 |
d-lo |
The
'distance' logic in AE is rather stupid if I remember
correctly. |
| 14:46.46 |
``Erik |
I'm fighting
the urge to over-engineer and bring up guild-hopping, though I'd
like it |
| 14:46.52 |
d-lo |
``Erik: I'll
fly if you buy :) |
| 14:46.57 |
``Erik |
stupid
stupid, not stupid easy |
| 14:47.04 |
``Erik |
I'm ~45
minutes from post |
| 14:47.28 |
d-lo |
eh, its
monday. quiet as death around here. |
| 14:47.41 |
``Erik |
there're 3
distinct computation paths for intergalactic distance |
| 14:47.46 |
``Erik |
it's
fugly |
| 14:48.05 |
d-lo |
i remember
finding an image that showed the basics of 'distance' |
| 14:48.13 |
d-lo |
I personally
thought it was stupid |
| 14:48.16 |
``Erik |
I think I
pasted tat pentagram around |
| 14:48.51 |
``Erik |
it's what
made me look for a x5, so I could maximize my trade
partners |
| 14:50.05 |
``Erik |
if'n someone
wants to cruise by to pick me up and head to something like duclaws
or la tolteca or soemthing, I'll buy their lunch... it's a trip,
though |
| 14:50.13 |
``Erik |
so'z I don't
expect any takers :) |
| 14:50.43 |
d-lo |
I hven't seen
any coordination here for lunch... yet. |
| 14:51.51 |
``Erik |
if I'm gonna
be involved, coordination has to be, like, now. :) it's all cool, I
mean, I'm too far away |
| 14:52.06 |
brlcad |
folks
interested in being a mentor should log in at http://socghop.appspot.com and
request it |
| 14:52.10 |
``Erik |
ain't no hard
feelings if ya'll don't go through fruity hoops and drive way out
of your way |
| 14:52.38 |
``Erik |
I'm listed as
admin on that, does that mean I'm not a regular mentor? |
| 14:52.47 |
brlcad |
``Erik, d-lo,
starseeker, yukonbob come to mind for starters |
| 14:53.09 |
brlcad |
``Erik: being
an admin is separate from being a mentor |
| 14:53.28 |
``Erik |
I can take a
student if needed, or I can just sit back and help questions... I
think I'll pass on the summit, though, ok? |
| 14:53.36 |
brlcad |
sure |
| 14:53.47 |
brlcad |
nice to send
new folks each year anyways |
| 14:53.56 |
``Erik |
that's what I
was thinking |
| 14:54.13 |
``Erik |
<-- felt
awful out of place last year :/ |
| 14:54.28 |
brlcad |
plus you'd
get to avoid chicago and large bottles of vodka :) |
| 14:54.40 |
``Erik |
well,
chicago, mebbe |
| 14:54.47 |
``Erik |
though it's
not that bad of a spot |
| 14:55.03 |
brlcad |
you weren't
exactly happy-go-lucky in the airport |
| 14:55.04 |
``Erik |
I just spent
time in layover in minneapolis and charlotsville |
| 14:55.19 |
``Erik |
I hate
flying. I hate what 9/11 has turned flying into. |
| 14:55.34 |
brlcad |
suspects you haded flying before security
changes |
| 14:55.39 |
brlcad |
hated even
too |
| 14:55.41 |
``Erik |
no, I used to
love it |
| 14:55.46 |
``Erik |
especially
small planes |
| 14:55.59 |
brlcad |
well, outside
of missouri, large international airports |
| 14:56.03 |
``Erik |
I want to get
my private v license, mebbe a sports license |
| 14:56.04 |
brlcad |
lots of peeps
on the move |
| 14:56.49 |
``Erik |
I dislike
crowds, and I dislike the strip search "everyone's a criminal until
proven otherwise" approach to airport security |
| 14:57.35 |
``Erik |
but I love
the feeling of a small twin turboprop wiggling up into the
air |
| 14:59.19 |
``Erik |
(didn't help
that I was desperate for a piss when ya got pulled
over) |
| 15:00.22 |
d-lo |
I am not a
big fan of small aircraft's ability to rapidly drop in altitude and
make your complimentry Coke hover 8" off your tray
table. |
| 15:00.34 |
d-lo |
It tests my
faith in engineering a bit. |
| 15:00.51 |
CIA-40 |
BRL-CAD:
03137.71.226.54 07http://brlcad.org
* r1289 10/wiki/Documentation: test |
| 15:01.07 |
``Erik |
haven't had
that episode yet, but, zomfg, I want to! |
| 15:01.46 |
``Erik |
and damn well
engineered aircraft can sustain -8 g's... so, uh, the engineering
is there, dude |
| 15:01.51 |
``Erik |
the pilot may
not be, but ... |
| 15:01.59 |
CIA-40 |
BRL-CAD:
03137.71.226.54 07http://brlcad.org
* r1290 10/wiki/Documentation: Undo revision 1289 by
[[Special:Contributions/137.71.226.54|137.71.226.54]] ([[User
talk:137.71.226.54|Talk]]) |
| 15:01.59 |
d-lo |
small twin
turbo out or Albany, NY to Cinncinati. Hit some weather blowing
off the great lakes.... unfun. |
| 15:02.54 |
``Erik |
I'd like to
get a vfr commutor and sport license as some point in my
life |
| 15:03.12 |
``Erik |
with a
seaplane label, if I can |
| 15:03.15 |
d-lo |
just because
the Engineers planned something on paper/computer bears nothing on
how its put together on the assembly line nor on the
underpaid,slackass maintainers/mechanics :) |
| 15:03.23 |
``Erik |
well |
| 15:03.34 |
``Erik |
the weather
and the pilot had issues... it was bad |
| 15:03.44 |
``Erik |
did the wings
come off of the plane? no? then the engineers were good |
| 15:04.09 |
d-lo |
Heh, you
would make a horrible Nuke :P |
| 15:04.22 |
``Erik |
if your
drinks are at 0g in a sustained bit due to such a conflict, I'd
imagine the engineers did good |
| 15:04.23 |
``Erik |
:) |
| 15:05.09 |
``Erik |
yeah, ya
nukes are all pansies |
| 15:05.25 |
d-lo |
Mushrooms, we
are all *Mushrooms* |
| 15:05.29 |
d-lo |
there is a
difference. |
| 15:05.36 |
``Erik |
"omg, I
dropped this 20 pound wrench on my toe when I was barefoot, even
though the sign says wear stealtoes... qq, ) |
| 15:05.47 |
d-lo |
lol |
| 15:06.09 |
d-lo |
thats
'Darwinism in Action' right there. |
| 15:07.07 |
``Erik |
I wouldn't
wanna be a nuke, I know I fuck up, I fuck up a lot... in code, I
catch MOST of those... but before people die, someone else gets a
fair shot at what I did |
| 15:07.16 |
``Erik |
and, y'know,
if I fuck up, tell me ! I love it, it makes me better. |
| 15:08.33 |
d-lo |
Nah, I only
said that because of your Engineering Atttitude :) I will refine
that statement and say that you would make a great Nuke
Electrician, but not a good Nuke Electronics Tech or Mechanic :)
|
| 15:08.46 |
d-lo |
Wire-biters
get away with a lot :) |
| 15:08.53 |
``Erik |
I'd never
want to be a dike wrangler. |
| 15:09.26 |
d-lo |
lol, thats a
new one. |
| 15:09.39 |
``Erik |
I don't like
people getting dead, I want as many folk between me and them as
possible |
| 15:12.05 |
``Erik |
so help me
out here, you stated 3 or so MOS's, which is which? |
| 15:14.05 |
d-lo |
Not MOS's,
ratings:) |
| 15:14.42 |
d-lo |
Nukes are
MM's, EM's, and ET's: Machinist Mate, Electrician Mate, and
Electronics Technicians. |
| 15:14.59 |
``Erik |
rating like
E-X ? |
| 15:15.19 |
d-lo |
-or- Knuckle
Draggers, Wire-biters, and Twigets. |
| 15:15.38 |
d-lo |
i dont
understand 'e-x'... |
| 15:15.56 |
``Erik |
oh, e3 e5
e8... |
| 15:16.01 |
``Erik |
all bow down,
it's an e9 |
| 15:16.07 |
``Erik |
bwahahhaha,
basic, an e1 |
| 15:16.15 |
d-lo |
thats rank,
not to be confused with rate |
| 15:16.56 |
d-lo |
rate = job,
rank = position in food chain. |
| 15:17.14 |
``Erik |
ahh |
| 15:17.43 |
``Erik |
so help me
out here, what's the laymans vew of mm em et |
| 15:18.06 |
``Erik |
and, uh,
ne |
| 15:18.52 |
d-lo |
EM =
Electricians. Handle mainline power, generators, converters, blah
blah, blah... basiclally any electronics/electrical not directly
reactor related. |
| 15:19.09 |
d-lo |
ET =
Electronics Techs. Handle the solid state Reactor Protection
junk. |
| 15:19.22 |
d-lo |
ET = low
voltage wimps. |
| 15:19.46 |
d-lo |
MM =
Mechanics. Pipes, steam, oil systems, cooling systems,
etc. |
| 15:20.24 |
d-lo |
and then the
sub group of MM's called ELTs (Engineeing Lab Techs) who do all the
water and radio chemistry. |
| 15:20.55 |
_sushi_ |
d-lo: are you
sure youre not divulging any army secrets? |
| 15:20.59 |
d-lo |
Throw in an
o-ganger to keep us dirty enlisted from taking over the engineroom
and voila, you have EngDiv of a sub. |
| 15:21.05 |
``Erik |
in your
parlance, I woulda probably gone towards et before I decided to say
"fuck all ya'll" to the military :) |
| 15:21.18 |
``Erik |
still not
sure what "nuke electrician" qualifies as :) |
| 15:21.33 |
d-lo |
_sushi_:
Army? nope. This is all Navy :) and its not secret in any way.
Just ask Google. |
| 15:21.39 |
d-lo |
EM |
| 15:21.39 |
``Erik |
karel: 'sall
navy, and I'm sure it's all in wikipedia |
| 15:22.18 |
d-lo |
EM =
Electrician's Mate (rate) |
| 15:23.08 |
``Erik |
shittiest
$1017 pizza ever. |
| 15:23.21 |
d-lo |
ranks: (from
E1 to E9): SR EMFA, EMFN, EM3, EM2, EM1, EMC, EMCS,
EMCM |
| 15:23.51 |
d-lo |
:/ I can
imagine. |
| 15:25.07 |
``Erik |
I have to go
get rich so I can make someone else drive me |
| 15:25.07 |
``Erik |
did enough jrotc to come in as e3, but is too old
now |
| 15:25.14 |
``Erik |
also; I d'no
if I want my title to be "semen" |
| 15:25.36 |
d-lo |
Electricians
are Firemen :) |
| 15:25.43 |
d-lo |
hoooya! |
| 15:25.57 |
``Erik |
does that
mean ya'll start fires? ;) |
| 15:26.15 |
d-lo |
Aquitted. No
Proof. |
| 15:26.41 |
``Erik |
SO |
| 15:26.45 |
``Erik |
I had a
brainfart the other day |
| 15:26.45 |
d-lo |
Butyes, I
have been party to a 27,000V fire :/ |
| 15:26.58 |
``Erik |
on
transportation between solar systems |
| 15:27.10 |
``Erik |
got time to
talk shit? |
| 15:27.13 |
d-lo |
Transformer
varnish stinks when it melts :( |
| 15:27.18 |
d-lo |
sure. |
| 15:27.18 |
``Erik |
oh hell
yeah |
| 15:27.37 |
``Erik |
fucking
transformers are the stinkiest components around until you overload
a dielectric capacitor |
| 15:28.12 |
d-lo |
I have only
seen one of them big oil filled caps blow. that was just messy,
not stinky. |
| 15:28.19 |
``Erik |
here's my
thought, every ss is connect to another by a brane, some solar
systems have multible branes, each starting ss has a single
brain |
| 15:28.27 |
d-lo |
so, brainfart
= good or bad? |
| 15:28.59 |
d-lo |
hold on. this
brainstorming for a new game concept? |
| 15:29.14 |
``Erik |
branes are
randmonly linked between planets, so even if you have the physical
location of a planet, you may not have the shortest path to
it |
| 15:29.19 |
``Erik |
ae
knockoff |
| 15:29.25 |
d-lo |
kk, onboard
now. |
| 15:29.52 |
d-lo |
okay, a game
I am stealing conepts from calls branes 'Starlanes' |
| 15:29.57 |
d-lo |
so I
gotcha |
| 15:30.03 |
``Erik |
it's an old
string theory idea |
| 15:30.37 |
``Erik |
but the
notion is that solar systems are connected by subspace rifts that
can be ridden |
| 15:30.56 |
``Erik |
physical
locality is seperate from "hyperspace" locality |
| 15:31.40 |
``Erik |
players start
in fairly isolated areas and access the big mess later in their
career |
| 15:32.06 |
d-lo |
big mess =
the rest of the super vast universe? |
| 15:32.20 |
``Erik |
and there's
no easy way to know how long ti takes to get to a target given just
its coordinates |
| 15:32.23 |
``Erik |
yeah |
| 15:32.56 |
d-lo |
check this
link: |
| 15:32.59 |
d-lo |
http://www2.worldvillage.com/wv/gamezone/images/screens/asc1.jpg |
| 15:33.21 |
``Erik |
ok, what'm I
looking at? |
| 15:33.30 |
d-lo |
game is
called acendancy. the dots on the screen are solar systems and the
lines represent the only travelable paths between
systems. |
| 15:33.58 |
d-lo |
its also a 2D
screenshot of a 3D universe, so its slightly flattened. |
| 15:33.58 |
``Erik |
sounds about
right |
| 15:34.10 |
``Erik |
it's not a
new concept, just one I haven't seen much |
| 15:34.22 |
d-lo |
Personnally,
I love the idea. |
| 15:34.33 |
``Erik |
I'm trying to
put the playability into aspect here :) |
| 15:34.39 |
d-lo |
puts some
'geographical' stragedy back into the game. |
| 15:34.59 |
d-lo |
'Take this
system and we can lock down this whole sector..." |
| 15:35.02 |
``Erik |
also reduces
guild-centric stuff a bit |
| 15:35.24 |
``Erik |
this wussy is
no longer "just right there", but down this twisted narrow unmapped
path |
| 15:35.57 |
d-lo |
Ascendancy is
Abandonware, you sould grab a DL and check some of the ascpects of
game play. they have some wicked ideas. |
| 15:36.00 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:36.19 |
hippieindamakin8 |
hey
madant_ |
| 15:36.23 |
``Erik |
ah, abandonia
for the win |
| 15:36.55 |
madant_ |
hey
hippieindamakin8 , just about steeping out.. how's the proposal
coming along |
| 15:36.58 |
``Erik |
I'll have to
grab a dos emulator |
| 15:36.58 |
d-lo |
right
on. |
| 15:37.22 |
hippieindamakin8 |
madant_,
working on it :| |
| 15:37.22 |
d-lo |
DosBox makes
it super easy. Ascendancy runs 'out of the box' i
think. |
| 15:39.23 |
hippieindamakin8 |
madant_, got
3 term papers this week :| one on "geometric approximation via
coresets","curve fitting of unorganized data points" and "NOx
emmisions" |
| 15:39.30 |
hippieindamakin8 |
*due this
week |
| 16:52.54 |
starseeker |
brlcad:
thinking about a "material object" as distinct from a "geometry
object" in the database - would it be desirable to store all
material objects by default in a hidden _materials toplevel
combination or some such? |
| 16:52.55 |
starseeker |
or maybe just
not list them by default with ls? |
| 16:55.53 |
starseeker |
also, would
we want to define a default structure for such objects that stores
certain "standard" info, or just use an attribute system to attach
attributes to the material object? |
| 16:57.01 |
starseeker |
's inclination would be to at least have density and shader
settings as default information |
| 17:17.56 |
*** join/#brlcad dreeves
(n=c752f34a@bz.bzflag.bz) |
| 17:50.40 |
CIA-40 |
BRL-CAD:
03starseeker * r34062 10/brlcad/trunk/db/goliath.asc: Add source
attribute to goliath model. |
| 17:53.48 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 18:15.34 |
CIA-40 |
BRL-CAD:
03starseeker * r34063 10/brlcad/trunk/ (5 files in 2 dirs): (log
message trimmed) |
| 18:15.34 |
CIA-40 |
BRL-CAD:
Switch brlman from a wrapper invoking awf to a wrapper invoking the
system man |
| 18:15.34 |
CIA-40 |
BRL-CAD:
command. awf is not able to correctly handle output generated by
the new |
| 18:15.34 |
CIA-40 |
BRL-CAD:
docbook man page generation process. The brlman shortcut is
preserved for those |
| 18:15.34 |
CIA-40 |
BRL-CAD: not
wishing to manually specify the path to the BRL-CAD man pages.
awf |
| 18:15.36 |
CIA-40 |
BRL-CAD:
originally was intended to supply man page reading functionality on
systems |
| 18:15.38 |
CIA-40 |
BRL-CAD:
without their own man command, but nowadays the only major
environment without a |
| 18:43.33 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 19:02.32 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 19:03.25 |
*** join/#brlcad ``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 19:09.05 |
brlcad |
starseeker:
.g files already have object categorization for geometric and
non-geometric |
| 19:11.05 |
brlcad |
major type 3
is particularly relevant and would probably be what to
use |
| 19:13.35 |
brlcad |
got a build
failure after 34063 |
| 19:23.36 |
starseeker |
hmm |
| 19:23.38 |
starseeker |
rebuilds |
| 19:24.02 |
starseeker |
ah |
| 19:24.04 |
starseeker |
sorry |
| 19:27.19 |
starseeker |
prods CIA |
| 19:29.13 |
starseeker |
brlcad:
should be fixed now |
| 19:33.22 |
starseeker |
brlcad:
you're referring to DB5_MAJORTYPE_ATTRIBUTE_ONLY in
db5.h? |
| 19:36.13 |
brlcad |
well yeah,
that's the low-level implementation detail |
| 19:36.40 |
brlcad |
you can read
about it a little bit on the v5 spec document, http://brlcad.org/OLD/newdb/newdb.html |
| 19:41.38 |
brlcad |
rationale and
organizational layout from there is good |
| 19:43.41 |
starseeker |
can minor
types be assigned to this type of major type as well? |
| 19:44.42 |
brlcad |
all objects
have a major+minor |
| 19:52.32 |
brlcad |
right now,
all DB5_MAJORTYPE_ATTRIBUTE_ONLY objects are minor type
0 |
| 19:59.23 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-4.dclient.hispeed.ch) |
| 20:07.14 |
starseeker |
suggests creating a minor type for material
objects |
| 20:26.20 |
brlcad |
probably a
good idea |
| 20:27.12 |
brlcad |
but that'd
also imply a different structure to the underlying private
data |
| 20:27.26 |
brlcad |
which may or
may not be the case, depends on the implementation |
| 20:31.03 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 21:03.37 |
*** join/#brlcad andax
(n=andax__@d213-102-40-13.cust.tele2.ch) |
| 21:41.35 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 21:45.24 |
brlcad |
cheers for progress |
| 22:30.05 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 22:42.24 |
starseeker |
sees two types of data that it would make immediate sense to
associate with a material object. One is (obviously) the density,
and the other is shader properties |
| 22:43.00 |
starseeker |
shader
properties might be either directly stored in the material object,
or might be created as a "shader object" which is then pointed to
by the material object |
| 22:43.58 |
starseeker |
I'm not sure
of the relative merits, offhand |
| 22:45.55 |
starseeker |
there would
be a (very slight) space savings for cases where no shader settings
are defined or two materials share the same shader settings if
shader objects were used, but unless there is some other use for
shader objects the extra abstraction might just clutter up the
database with 2x the needed object names |
| 22:46.27 |
starseeker |
in the case
where all materials DO have their own shaders |
| 22:47.10 |
brlcad |
shaders would
actually be another potential object type |
| 22:47.20 |
starseeker |
right |
| 22:47.26 |
brlcad |
where a given
material references some shader object(s) |
| 22:47.39 |
starseeker |
is it worth
the extra abstraction? |
| 22:47.47 |
brlcad |
the point,
though, with regards to the minor type is how it is actually
stored |
| 22:47.50 |
brlcad |
the bits in
the record |
| 22:48.22 |
starseeker |
hmm. |
| 22:48.26 |
brlcad |
since you
could conceivably implement the whole thing as-is and handle it
just as transparently at the api level |
| 22:48.32 |
brlcad |
or app level
even |
| 22:48.46 |
brlcad |
as that is
domain-specific (which is exactly what the attributes were designed
to support) |
| 22:49.32 |
starseeker |
nods - I had been assuming what makes the material object
interesting is the density being an "attribute on an attribute", so
to speak |
| 22:50.42 |
starseeker |
we could of
course stuff the info into material_name and material_density
attributes on regions |
| 22:51.42 |
brlcad |
right |
| 22:51.54 |
brlcad |
then it's
just an issue of data replication and verification |
| 22:52.17 |
brlcad |
i'm leaning
towards just doing exactly like what we do with
combinations |
| 22:52.22 |
brlcad |
everything is
a named reference |
| 22:53.34 |
starseeker |
I'm not
following - what are you referencing for material info? |
| 22:53.41 |
brlcad |
so there
would still be a material id attribute of sorts, but instead of
being GIFTmater=4, it would become something like material="steel",
and there would be an attribute/material object named 'steel' with
the information for that material |
| 22:53.55 |
starseeker |
ah |
| 22:54.20 |
starseeker |
likes the idea of there being one material object named
"steel" per db |
| 22:54.31 |
brlcad |
the
combination reference is if I have a combination that is u sph1 u
sph2, those are named references that imply there are (or should
be) objects named sph1 and sph2 |
| 22:54.41 |
starseeker |
right |
| 22:54.58 |
starseeker |
so a material
attribute implies there should be a steel material
object |
| 22:55.07 |
brlcad |
if they're
just treated as objects, then databases can be merged together and
the same logic we use now for name collisions applies |
| 22:55.15 |
starseeker |
nods |
| 22:55.18 |
brlcad |
right |
| 22:55.22 |
starseeker |
I like
it |
| 22:55.49 |
starseeker |
that also
avoids two regions claiming to be steel but with differrent
material_density attributes, since they're both referencing the
same steel material object |
| 22:55.56 |
brlcad |
then if down
the road we wanted to assign textures or shaders, that would maybe
be a similarly assigned attribute |
| 22:56.02 |
brlcad |
(on the
material object) |
| 22:56.12 |
starseeker |
nice |
| 22:56.27 |
starseeker |
starting to
"feel" like a BRL-CAD-esque solution |
| 22:57.09 |
brlcad |
I believe in
the original material design we worked on a few years back, there
was even a way to base one material off of an existing material,
giving hierarchical properties |
| 22:57.22 |
brlcad |
something to
think about again if it gets a proper object |
| 22:57.47 |
starseeker |
's current thought on shaders is to expand the densities
parsing to (optionally) handle shader settings - when a material
object is created from a densities file, it could optionally
generate the shader object if supplied (and not already found in
the database) |
| 22:58.24 |
starseeker |
brlcad: hmm.
what material properties would you want to inherit? a density
defined as a function of another density? |
| 22:59.21 |
brlcad |
on an only
somewhat related side note, I think shader objects are a fantastic
direction to go in |
| 22:59.32 |
brlcad |
instead of
the shader string presently used |
| 22:59.50 |
starseeker |
whole-heartedly agrees |
| 22:59.51 |
brlcad |
a lot more
complicated though |
| 23:02.42 |
brlcad |
starseeker:
basically it's like classes or scopes -- answering your inheritance
question -- there are a set of parameters for a given material like
it's density, modulus, strength, shearing factors, shader
properties, etc |
| 23:03.22 |
starseeker |
what are you
seeing as the major complications with shader objects? |
| 23:03.30 |
starseeker |
ah, got
it |
| 23:03.32 |
brlcad |
there are
very often materials used that are just slight tweaks of other
materials -- a variant of "steel" that is "hardened steel #83" that
has all the same properties as the prevoius 82 but this one has a
slightly different density |
| 23:04.46 |
brlcad |
material
properties are fairly fixed (e.g., minimally just need a name and a
density) -- there are a set of attributes that can be
itemized |
| 23:05.12 |
brlcad |
shaders,
though, are a little more dynamic, are wildly different from shader
to shader |
| 23:06.19 |
brlcad |
just would
have to be careful to implement a shader object so that the
serialized guts aren't going to limit "upgrades" |
| 23:07.07 |
brlcad |
I can add a
new parameter to the pervasive phong shader now and it won't hose
anything or require the latest version to work, if it was tied to a
db object and binary parsing, that becomes something we'd have to
pay attention to |
| 23:12.05 |
starseeker |
hmm |
| 23:12.41 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 23:42.52 |
``Erik |
wonders how embedded parms would interact with other
rendering methods (edge, photon mapping, radar analysis,
etc) |
| 00:04.05 |
*** join/#brlcad madant
(n=madant@117.196.132.90) |
| 00:35.04 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-59.sbndin.btas.verizon.net) |
| 02:51.56 |
*** join/#brlcad madant
(n=madant@117.196.132.139) |
| 02:53.36 |
yukonbob |
hello,
cadheads |
| 03:34.16 |
pacman87 |
howdy,
yukonbob |
| 03:37.41 |
*** join/#brlcad madant
(n=madant@117.196.138.147) |
| 03:55.18 |
starseeker |
is surprised by how much info the gsoc mentor form
requires |
| 03:58.26 |
yukonbob |
hey
pacman87 |
| 04:09.48 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 04:31.57 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 04:33.44 |
starseeker |
ah, there's
pixie's rib parser:
http://pixie.svn.sourceforge.net/viewvc/pixie/trunk/src/rndr/rndr.cpp?revision=1193&view=markup |
| 04:37.51 |
brlcad |
notes that task is listed: http://brlcad.org/~sean/ideas.html |
| 04:39.05 |
brlcad |
another
integration idea was to test out pixie itself as a "shader" or as
an rt lighting model |
| 04:41.55 |
pacman87 |
brlcad: is
the "cylindrical wedge" on that list (under primitives) just a
cylinder with base/top at an arbitrary angle? |
| 04:43.57 |
brlcad |
pacman87:
http://mathworld.wolfram.com/CylindricalWedge.html |
| 04:44.15 |
brlcad |
pretty simple
primitive |
| 04:44.32 |
pacman87 |
looks like
it |
| 04:45.25 |
brlcad |
basically a
tgc/rcc but sliced through the side and one base at an arbitrary
orientation |
| 04:47.35 |
brlcad |
input params
are somewhat different |
| 04:47.55 |
pacman87 |
yeah, that's
what i was thinking about |
| 04:48.12 |
pacman87 |
same thing
with the hyp |
| 04:48.27 |
pacman87 |
a few
different ways to specify dimensions |
| 04:48.41 |
brlcad |
not sure if
it could be easily generalized to a generalized conical wedge
instead of right circular |
| 04:49.26 |
pacman87 |
radius,
height vector, and two normal vectors for the surfaces? |
| 04:50.38 |
brlcad |
cylindrical
wedge starts getting down into the weeds of being an interesting
starter primitive for someone to learn with |
| 04:51.07 |
brlcad |
somewhat
limited uses though |
| 04:51.23 |
pacman87 |
yeah, but it
being on the TODO list struck me as a "why hasn't it happened
yet?" |
| 04:52.32 |
brlcad |
nah, I'm
thinking actually something like tgc where top ij vectors are maybe
2:1 and bottom vectors are 1:2 (looks sorta twisted), then slice
through side and base |
| 04:52.58 |
brlcad |
that's the
ideas page, not quite the same as the TODO file |
| 04:53.17 |
brlcad |
though both
contain items that are just "would be nice to have" regardless of
priority |
| 04:53.25 |
pacman87 |
it'd be nice
if each primitive had all of its dimensions editable, and the user
selects which set are driving, and leaving the rest
driven |
| 04:54.25 |
brlcad |
not
necessarily things that we are actively pursuing |
| 04:54.25 |
pacman87 |
ah, i should
read the url and/or the page title |
| 04:54.27 |
brlcad |
heh, or the
big paragraph at the beginning ;) |
| 04:54.29 |
*** join/#brlcad dreeves_
(n=IceChat7@67.130.253.14) |
| 04:55.02 |
yukonbob |
that
cylindrical wedge is perdy |
| 04:55.03 |
pacman87 |
one of my big
questions with the sweep is how to manage the 'orientation along
the path' |
| 05:04.48 |
brlcad |
you could
limit the orientation to make it piecewise -- make the sweep only
have a starting orientation/azimuth and an ending
azimuth |
| 05:05.03 |
brlcad |
then linearly
interpolate |
| 05:05.48 |
brlcad |
or would take
the spline input curve and allow the specification of N
orientations along that path ranged from 0.0 to 1.0 distance along
the sweep curve (and then linearly interpolate) |
| 05:10.45 |
brlcad |
autocad
allows the sketch to be perpendicular or at an angle, along a
spline path, with twisting angles (azimuths), and scaling
factors |
| 05:11.08 |
brlcad |
twists and
scales are both linearly interp'd, though twists can be more than
360 |
| 05:11.44 |
brlcad |
http://www.dailyautocad.com/autocad/3d-modeling-8-using-sweep-command/ |
| 05:12.11 |
pacman87 |
most of my
experience is from solidworks |
| 05:13.45 |
brlcad |
similar
flexibility |
| 05:13.49 |
brlcad |
http://www.solidsmack.com/how-the-heck-is-this-made-creating-solidworks-spirals-sweeps-and-helixes/2008-10-01/ |
| 05:16.17 |
brlcad |
not sure how
they did the hourglass other than by tying multiples together or if
solidworks has keypoints |
| 05:18.43 |
brlcad |
aha, guide
curves |
| 05:18.48 |
brlcad |
http://www.youtube.com/watch?v=3OUCd8Fp0cE |
| 07:54.27 |
*** join/#brlcad madant_
(n=madant@117.196.151.246) |
| 08:17.39 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 08:17.46 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 08:21.43 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
| 08:23.38 |
*** join/#brlcad MinuteEl1ctron
(n=MinuteEl@bz.bzflag.bz) |
| 08:30.52 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 08:37.38 |
*** join/#brlcad madant_
(n=madant@117.196.138.104) |
| 08:41.01 |
madant_ |
to anybody
interested :) theoretical foundations of geometric constraint
solving.. the references are the good part ;) http://www.cs.purdue.edu/homes/cmh/electrobook/theory.html |
| 08:49.17 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1291 10/wiki/Libpc: Basic Structure |
| 08:49.39 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1292 10/wiki/Developer_Documents: /* Development Projects
*/ |
| 08:50.38 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:53.42 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:55.22 |
*** join/#brlcad madant__
(n=madant@117.196.140.211) |
| 09:57.21 |
*** join/#brlcad madant
(n=madant@117.196.140.211) |
| 11:26.11 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 12:36.00 |
mafm |
brlcad: any
candidate for the GUI framework? |
| 12:37.02 |
d-lo |
Why are *YOU*
so interested, eh? =D |
| 12:37.16 |
mafm |
because I
might have to do some mentoring |
| 12:37.56 |
mafm |
or hide
behind the armchair in the case that s/he embarrases me with
his/her skills :) |
| 12:43.03 |
mafm |
d-lo: are you
going to be a mentor this year? does it depend on the projects
elected, I guess |
| 12:43.27 |
d-lo |
mafm: could
be one! |
| 12:47.26 |
mafm |
d-lo: I don't
if I should say congrats, or I feel for you :) |
| 12:50.12 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:23.44 |
*** join/#brlcad madant
(n=madant@117.196.144.175) |
| 13:49.25 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:50.25 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 14:04.46 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 14:06.13 |
``Erik_ |
"csg ray
trace optimisations" sounds insanely vague O.o |
| 14:25.00 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 14:53.23 |
starseeker |
sees the article on the Texas school board and
winces |
| 15:07.24 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:24.27 |
*** join/#brlcad ``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:57.07 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:57.10 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 16:00.04 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
| 16:07.32 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34073 10/brlcad/trunk/src/conv/CMakeLists.txt:
included g5-g4 downgrade tool |
| 16:11.35 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34074 10/rt^3/trunk/ (include/brlcad/Object.h
src/coreInterface/Object.cpp): the return value of Copy() is always
ignored |
| 16:13.43 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34075 10/rt^3/trunk/ (8 files in 2 dirs): revised
error handling |
| 16:52.14 |
*** join/#brlcad cad38
(n=c752f34a@bz.bzflag.bz) |
| 17:11.35 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 17:25.05 |
CIA-40 |
BRL-CAD:
03Adminssmith 07http://brlcad.org *
r1293 10/wiki/Main_Page: |
| 17:46.39 |
starseeker |
brlcad: hmm,
the db5.h header has a DB5_MINORTYPE_BRLCAD_COMBINATION entry, but
the spec lists combinations as a non-geometry type |
| 18:06.39 |
d-lo |
www.nbos.com |
| 18:17.31 |
``Erik |
nifty, I'm
back online |
| 18:17.36 |
``Erik |
yay,
comcast! |
| 18:17.45 |
d-lo |
They finally
fix your connection? |
| 18:17.50 |
``Erik |
no |
| 18:17.53 |
``Erik |
yay, they
suck. :D |
| 18:22.13 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Adminssmith]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
| 18:22.42 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1294
10/wiki/Main_Page: Undo revision 1293 by
[[Special:Contributions/Adminssmith|Adminssmith]] ([[User
talk:Adminssmith|Talk]]) |
| 18:23.23 |
``Erik |
huh, nutty,
one of their distributors is in bellevue, wa |
| 18:23.36 |
``Erik |
drove there to buy cd's and blue hair dye back in the
day |
| 18:26.34 |
d-lo |
blue? heh.
heheh.. ....ROFL |
| 18:26.51 |
``Erik |
O.o what?
:D |
| 18:27.01 |
``Erik |
it was the
mid 90's in the seattle area |
| 18:27.06 |
``Erik |
I was COOL,
yo! (or somethin') |
| 18:27.38 |
hippieindamakin8 |
``Erik, mid
90s and Seattle woah wat a place to be :) |
| 18:28.17 |
hippieindamakin8 |
but i would
prefer going back to the times of woodstock and me a hippie
;) |
| 18:28.29 |
hippieindamakin8 |
68 i
meant |
| 18:34.23 |
starseeker |
mutter
mutter... grip and joint have geometry minor types too, despite
having minor types in major type 1 |
| 18:36.09 |
starseeker |
not
clean |
| 18:43.50 |
starseeker |
wishes these geometry minor types could have been assigned in
an order based on mathematical grouping... oh,
well |
| 18:46.01 |
CIA-40 |
BRL-CAD:
03starseeker * r34076
10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add in content
up to geometry minor types table. |
| 18:55.08 |
CIA-40 |
BRL-CAD:
03starseeker * r34077
10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add geometry
attributes minor type section. |
| 18:55.36 |
starseeker |
whoops, that
was a major type session |
| 19:42.49 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 20:00.13 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 20:40.20 |
*** join/#brlcad tina__
(n=tina@f053144017.adsl.alicedsl.de) |
| 20:42.24 |
*** part/#brlcad tina__
(n=tina@f053144017.adsl.alicedsl.de) |
| 20:44.35 |
*** join/#brlcad BigAToo
(n=BigAToo@66.103.88.193) |
| 20:48.45 |
*** join/#brlcad BigATo1
(n=BigAToo@66.103.88.193) |
| 21:07.04 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.33.19) |
| 21:45.18 |
CIA-40 |
BRL-CAD:
03starseeker * r34078
10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add spec
contents up to Object Length. |
| 21:51.02 |
starseeker |
<snort>
I like the part were it says "detailed specifications of each of
these are necessary..." |
| 22:06.19 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-172.dclient.hispeed.ch) |
| 22:07.13 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1295 10/wiki/Animation: /* Compositing an animation */ |
| 22:11.54 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1296 10/wiki/Animation: /* With Mencoder */ |
| 22:12.20 |
*** join/#brlcad csanyipal
(n=csanyipa@252-144-85-95.dynamic.stcable.net) |
| 22:12.28 |
csanyipal |
howdy! |
| 22:13.47 |
csanyipal |
I want just
to say that that I wrote down a small addon to http://brlcad.org/wiki/Animation. |
| 22:14.16 |
csanyipal |
One can use
Mencoder to create an animation from png files. |
| 22:14.33 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 22:53.23 |
Ralith |
wonders if there are any version control systems that don't
suffer horrible lag when dealing with codebases this
large |
| 22:55.21 |
Ralith |
huh, this is
weird |
| 22:55.45 |
Ralith |
'svn diff' is
showing lots of changes that I didn't make; it's like instead of
applying some revisions it just skipped them and assumed I'd
deleted them. |
| 22:56.43 |
Ralith |
is tempted to revert his changes, but that'd mean starting
over from scratch. |
| 22:56.50 |
Ralith |
that's what I
get for going idle for a long period, I guess |
| 23:07.45 |
Ralith |
looks like
something to do with lineendings. |
| 23:09.03 |
Ralith |
someone wiped
out all the ^Ms and for some reason svn thinks I put them
back? |
| 23:17.15 |
Ralith |
begins making extensive use of revert
--recursive |
| 23:20.32 |
Ralith |
looks like
it's mostly in .dsp files. |
| 23:21.39 |
Ralith |
okay, that
halved the diff size. |
| 23:23.56 |
Ralith |
.dsp files
are huge. |
| 23:26.27 |
Ralith |
hey, I wonder
how hard it would be to write a tool to evaluate a single line of
cpp syntax in context. |
| 23:27.39 |
``Erik |
"cpp syntax
in context"? |
| 23:27.39 |
Ralith |
okay, I'm
back down to my actual changes! yay! :D |
| 23:28.08 |
Ralith |
``Erik: as
in, considering other cpp expressions in the file, such as includes
and defines, as would be necessary for useful behavior in most
cases. |
| 23:28.21 |
Ralith |
basically,
run cpp on the file and extract the corresponding line. |
| 23:28.47 |
Ralith |
does cpp
offer any way to determine the corresponding line, or would that
have to be hacked on? |
| 23:28.52 |
``Erik |
ah, I usually
just do gcc -E | less and search for something close |
| 23:29.03 |
Ralith |
yeah, but
wouldn't it be awesome to have it bound in emacs? |
| 23:29.30 |
Ralith |
perhaps a
minibuffer message showing the expansion, and a keybind to perform
the replacement. |
| 23:30.12 |
``Erik |
I'm sure a
little elithp could handle that fairly easily, provided you can
pull the actual command to compile the object |
| 23:30.54 |
Ralith |
wouldn't it
just be a matter of running cpp on it? |
| 23:31.04 |
Ralith |
still not
sure how to extract the relevant line(s) though. |
| 23:31.16 |
``Erik |
post-cpp code
has #1234 springled through it to help the compiler get line
numbers correct, be a matter of finding the greatest line indicator
before your line of interest, then counting (mebbe doing 5 or so
lines to help with context) |
| 23:31.29 |
Ralith |
oo |
| 23:31.31 |
Ralith |
that's
helpful |
| 23:31.44 |
``Erik |
gcc -E
myprog.c > myprog.cpp ; grep '^#[0-9]' myprog.cpp |
| 23:31.57 |
Ralith |
is gcc -E
perferable to cpp? |
| 23:31.58 |
``Erik |
(or .e if you
don't want to confuse the more retarded c++ developers) |
| 23:32.07 |
Ralith |
lol |
| 23:32.09 |
``Erik |
um, they
should execute the same code |
| 23:32.17 |
Ralith |
hm, I suppose
one problem would be getting the include paths right |
| 23:32.33 |
``Erik |
yup, thus my
comment about getting the actual command to compile the object
:) |
| 23:32.38 |
Ralith |
ahh, that's
what you meant. |
| 23:32.41 |
``Erik |
then you
could s/-c -o blah.o/-E/ |
| 23:32.47 |
Ralith |
yeah. |
| 23:32.58 |
Ralith |
perhaps have
it parse Makefiles? |
| 23:33.03 |
Ralith |
that's
getting kind of specialized though |
| 23:33.39 |
Ralith |
...weird, I
appear to have finished these changes. |
| 23:33.56 |
``Erik |
iirc, emacs
has the ability to execute make with some combination of 18 keys
held down simultaniously |
| 23:34.24 |
``Erik |
finding how
it does that, and changing it to do "rm thisfile.o && make
thisfile.o" to crib it |
| 23:34.31 |
Ralith |
only three,
actually. I used to know it, but I've been using enough arcane
toolchains lately that I've just been running a terminal instance
in the same desktop and switching to that. |
| 23:34.43 |
``Erik |
or, if you
use bsd make instead of gnu make, make -V might be able to do
it |
| 23:34.55 |
Ralith |
well, that's
unportable |
| 23:35.10 |
``Erik |
yeah, but
expecting to use gcc is unportable, as well |
| 23:35.46 |
``Erik |
would imagine a couple big honkin' (cond)
statements |
| 23:35.48 |
Ralith |
point. |
| 23:35.56 |
Ralith |
yeah that's
just inelegant |
| 23:36.11 |
Ralith |
at least
assuming gcc works across probably 95% of installations |
| 23:36.31 |
Ralith |
certainly in
our case. |
| 23:36.35 |
``Erik |
hrm |
| 23:36.45 |
``Erik |
'cept we test
compile on like 5 different compilers, dude |
| 23:36.53 |
Ralith |
but what do
we all *use*? |
| 23:36.58 |
``Erik |
mipspro,
sunw, ... |
| 23:37.04 |
``Erik |
a couple
msvc's |
| 23:37.28 |
``Erik |
mebbe we
should use tendra :D |
| 23:37.32 |
Ralith |
besides, we'd
have to assume makefiles to get anywhere |
| 23:37.47 |
Ralith |
and that's
probably less common than gcc in the world at large |
| 23:37.54 |
Ralith |
well, who
knows |
| 23:38.06 |
``Erik |
aaanyways,
it's all shades of grey, where to draw the line is an engineering
decision :) |
| 23:38.10 |
Ralith |
ultimately I
think gcc's a reasonable assumption for the purposes of a
convenience tools. |
| 23:38.13 |
Ralith |
tool* |
| 23:38.21 |
``Erik |
primarily developes on FBSD, which has been itching to dump
gcc for quite a while |
| 23:38.33 |
``Erik |
some argued
tendra, now there's another one that's getting
attention |
| 23:38.34 |
Ralith |
pcc does look
shiny., |
| 23:38.41 |
bjorkintosh |
in favor of
what? |
| 23:38.44 |
Ralith |
see
above |
| 23:38.49 |
``Erik |
izzit
pcc? |
| 23:38.52 |
Ralith |
pretty
sure. |
| 23:39.03 |
Ralith |
that's the
one that, iirc, OpenBSD has been giving lots of attention
to |
| 23:39.09 |
``Erik |
sounds about
right *shrug* I d'no, I got tired of all the bikeshedding around
that topic |
| 23:39.17 |
Ralith |
and OpenBSD
seems to have a habit of starting trends. |
| 23:39.33 |
Ralith |
pcc is
interesting to me because last I heard of it it was much faster
than gcc. |
| 23:39.52 |
Ralith |
not that
that's *too* valuable in the long run, but handy in a dev
environment, and on source-based systems. |
| 23:40.05 |
``Erik |
fast
compiling, or faster generated code? |
| 23:40.08 |
Ralith |
the
former |
| 23:40.22 |
Ralith |
I'd be
surprised if they could match gcc's slew of optimization
options. |
| 23:41.04 |
``Erik |
the bsd's
feed off of eachother a lot, they're all radically different than
eachother (far more different than linux distros), but have a lot
of community overlap and listen to eachother well, it's
neat |
| 23:41.22 |
``Erik |
uhm, until
recently, gcc was pretty shitty at optimizing, even microsoft was
wiping the floor with gcc3 |
| 23:41.22 |
Ralith |
yeah, BSD's
awesome. |
| 23:41.29 |
Ralith |
right, until
recently. |
| 23:41.33 |
Ralith |
not so
anymore. |
| 23:41.36 |
Ralith |
(or so I
hear.) |
| 23:41.42 |
``Erik |
the new, uh,
TSA code in 4 made gcc40 far slower, but it sped up a lot pretty
fast |
| 23:42.01 |
Ralith |
I have to
confess I've installed linux on my desktop, though |
| 23:42.13 |
``Erik |
used to have linux machines, now only has them at work
:) |
| 23:42.13 |
Ralith |
sometimes you
just gotta run some flash :P |
| 23:42.22 |
``Erik |
<-- pets
his hackintops |
| 23:42.43 |
Ralith |
and I've also
been toying with graphics stuff lately, and nvidia hasn't released
a Cg compiler for FreeBSD yet. |
| 23:43.16 |
Ralith |
I really wish
the hardware industry was more open. |
| 23:43.17 |
``Erik |
the first
thing I did when I bought my old g3 ibook was watch strongbad
email. all of it. :D |
| 23:44.02 |
``Erik |
nvidia drags
its feet a LOT with the fbsd stuff, I had to email them to get a
release to allow a 3 year old card to work :( |
| 23:44.20 |
Ralith |
I'm just
thankful they support it at all. |
| 23:44.37 |
``Erik |
that was a
fight and a half heh |
| 23:44.47 |
Ralith |
well, less
thankful, more amazed. |
| 23:44.56 |
``Erik |
they didn't
move until people were reverse engineering their hardware out in
public |
| 23:45.09 |
Ralith |
it's even
somewhat more stable than the nvidia/X I have set up on this linux
box |
| 23:45.21 |
``Erik |
I imagine it
was just to throw a carrot to prevent their "vital secrets" from
being figured out by angsty fbsd fools |
| 23:45.22 |
``Erik |
:) |
| 23:45.25 |
Ralith |
though that
may be more due to FreeBSD than nvidia. |
| 23:45.29 |
Ralith |
lol |
| 23:45.33 |
Ralith |
that reminds
me |
| 23:45.38 |
Ralith |
how's ATI
doing with that whole releasing the docs thing? |
| 23:45.40 |
``Erik |
quickest way
to make a fbsd unstable - nvidia driver. :D |
| 23:45.45 |
``Erik |
<-- hasn't
been following |
| 23:46.28 |
Ralith |
'kay |
| 23:46.35 |
Ralith |
cuz that was
really exciting when I first heard about it |
| 23:46.41 |
Ralith |
but didn't
really seem to go anywhere. |
| 23:49.30 |
``Erik |
"marylin
manson???" "yeah, it's all his or her fault! I'm going to give him
or her a piece of my mind or penis" hah |
| 23:51.41 |
Ralith |
``Erik: on a
more topical subject: I'm a bit unsure what proper procedure is for
me with respect to committing code (in this case, a removal of the
redundant vecmath.h from lgt). I've got write access, or did last
I checked, but I'm uncertain if I should be requesting review
(after testing to the best of my ability, of course) before
checking changes in. |
| 23:53.23 |
Ralith |
(said removal
is nontrivial as it required swapping out macros with different
syntax, and I know of no clear way to verify that it all still
works the same once compiled) |
| 23:55.12 |
``Erik |
the benchmark
suite? :) |
| 23:55.20 |
Ralith |
covers
lgt? |
| 23:55.28 |
``Erik |
commits can
always be undone, but if you want review, you can always post the
patch somewhere |
| 23:55.34 |
``Erik |
oh, lgt,
um |
| 23:55.37 |
``Erik |
d'no |
| 23:56.04 |
Ralith |
yeah, I'm
just wondering if I should make a point of requesting
review. |
| 23:57.26 |
``Erik |
depends on
how confident you are :) it'll get reviewed either way |
| 23:58.13 |
``Erik |
the commit
bit is the "we trust you enough to do what's right, or suffer the
horrible reprecussions" |
| 23:58.28 |
Ralith |
kk, thanks
for clearing that up |
| 23:58.42 |
``Erik |
w00t, clear
as mud! :D |
| 00:00.28 |
Ralith |
mud can be an
improvement. |
| 00:06.20 |
``Erik |
"AIG stands
for arrogance, incompetence and greed" nice |
| 00:08.53 |
Ralith |
xkcd made a
good point recently |
| 00:09.09 |
Ralith |
$200 or so
million is not a very big fraction of the bailout. |
| 00:10.43 |
Ralith |
I'm more
concerned by how we seem to be giving bailout money to companies
which don't operate in the US at all. |
| 00:10.56 |
Ralith |
but then when
I think about that much longer |
| 00:11.25 |
Ralith |
I realize I
don't have a fraction of the experience necessary to dictate what
is and is not reasonable |
| 00:11.29 |
Ralith |
so I go back
to programming instead. |
| 00:14.27 |
``Erik |
they don't
seem to have the experience necessary to dictate what is and is not
reasonable, either :) |
| 00:14.30 |
louipc |
what are the
repercussions? :O |
| 00:15.06 |
Ralith |
``Erik: this
is true; that does not make me any more well-equipped to form a
useful opinion. |
| 00:15.16 |
Ralith |
other than
"whoever put those guys in charge should be shot" |
| 00:15.16 |
``Erik |
depends on
how you break it, louie... could be "this doens't seem right, fix
it" for a minor goof to the "tire iron" treatment for damage to the
repo history |
| 00:15.51 |
Ralith |
didn't know you could do that, bar a serious svn
bug |
| 00:16.25 |
``Erik |
I know you
could with cvs, fairly easily if you mucked with the wrong
commands |
| 00:16.37 |
``Erik |
like deleting
revisions that aren't HEAD |
| 00:17.02 |
``Erik |
cvs admin -o
<-- thermonuclear cleaning tool, don't do it unless you REALLY
know what you're doing :) |
| 00:17.04 |
Ralith |
well, you
*shouldn't* be able to. |
| 00:18.27 |
louipc |
hmm! |
| 00:18.32 |
Ralith |
not unless
the repository's stored locally anyway |
| 00:19.43 |
``Erik |
admin's a
remote command, from back in the days when real programmers didn't
make mistakes O:-) |
| 00:20.13 |
louipc |
you can't
trust open source contributors to be real programmers
hehe |
| 00:26.39 |
Ralith |
sad but
true. |
| 00:41.29 |
Ralith |
``Erik: know
of a generic max/min macro pair (e.g. #define MAX(x,y)
((x)>(y)?(x):(y))) defined anywhere? If not, is that a
reasonable addition to vmath.h? |
| 00:49.40 |
``Erik |
uhm, a lot of
os's provide them in basic headers |
| 00:50.26 |
Ralith |
really? |
| 00:51.40 |
``Erik |
/usr/include/sys/param.h on fbsd and
osX |
| 00:52.53 |
``Erik |
and our
common.h has FMAX |
| 00:53.04 |
Ralith |
ahh. |
| 00:53.06 |
Ralith |
perfect. |
| 00:54.51 |
Ralith |
if I drop an
FABS in there, I think it'd complete the coverage of what's missing
from vmath.h that was in vecmath.h. |
| 00:54.57 |
Ralith |
does so. |
| 00:55.09 |
``Erik |
but fabs() is
part of the iso standard |
| 00:56.04 |
Ralith |
yeah, but
fabs() isn't really appropriate when you're dealing with e.g. a
long int |
| 00:56.04 |
``Erik |
then abs() is
right? :) |
| 00:56.13 |
Ralith |
...I can't
believe I didn't notice that. |
| 00:56.26 |
``Erik |
notes that fmin and fmax seem to be iso
now |
| 00:56.28 |
Ralith |
smacks self. |
| 00:56.38 |
``Erik |
ooh, me too,
me too! |
| 00:56.40 |
Ralith |
yeah, but
there does not appear to be a corresponding min and max |
| 00:56.41 |
``Erik |
smacks ralith |
| 00:56.41 |
``Erik |
:D |
| 00:56.43 |
Ralith |
D: |
| 00:56.54 |
Ralith |
so in that
case the common.h defines will get to come out and
play. |
| 00:57.10 |
``Erik |
yeh |
| 00:58.10 |
``Erik |
my manpages
attribute abs/fabs to c99, wonder if they were everywhere but not
standardized before that :/ |
| 01:06.08 |
Ralith |
hm. |
| 01:06.22 |
Ralith |
what's the
correct abs function to use for a fastf_t? |
| 01:06.44 |
Ralith |
I think I'll
just use a (:?) expr there. |
| 01:06.58 |
Ralith |
'cuz it could
theoretically be anything, right? |
| 01:12.40 |
Ralith |
okay, seems
to build. |
| 01:13.11 |
Ralith |
lets the rest of BRL-CAD do so. |
| 01:17.57 |
``Erik |
'cept it's
always double |
| 01:19.17 |
Ralith |
well, if that
was the point of it, we'd just be using double. |
| 01:20.02 |
Ralith |
this makes it
much easier to change things for new hardware or special
requirements |
| 01:20.14 |
Ralith |
e.g. the GMP
type that was discussed a little while ago |
| 01:20.29 |
Ralith |
or on some
theoretical platform where single precision float is much
faster |
| 01:20.42 |
Ralith |
and so
on. |
| 01:22.27 |
Ralith |
is it safe to
run 'make install' parallel to 'make benchmark'? |
| 01:32.12 |
``Erik |
might skew
things by introducing page misses and cache line misses |
| 01:32.36 |
``Erik |
and possibly
'biglock' events or cli/sti swaps |
| 01:34.34 |
Ralith |
well, moot
now anyway. |
| 01:38.53 |
Ralith |
is it just me
or is BRL-CAD faster to build these days? |
| 02:31.38 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 02:45.08 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 02:56.33 |
``Erik |
"nascar - the
most exciting version of traffic" |
| 02:59.54 |
*** join/#brlcad flyan
(i=flyan@210.77.14.133) |
| 03:15.30 |
*** join/#brlcad deeeffache
(n=deeeffac@99.141.236.239) |
| 03:35.16 |
*** join/#brlcad flyan_
(i=flyan@210.77.14.133) |
| 04:09.26 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 04:23.21 |
deeeffache |
does BRL CAD
get a lot of commercial/business use? |
| 04:45.04 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 05:35.47 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 05:39.10 |
Ralith |
stretches |
| 05:39.17 |
Ralith |
good to have
this done: |
| 05:39.29 |
CIA-40 |
BRL-CAD:
03ralith * r34079 10/brlcad/trunk/src/lgt/ (14 files): Removed the
largely redundant vecmath.h from lgt, replacing uses with vmath
macros. |
| 05:40.20 |
Ralith |
deeeffache:
the documentation says as much, though I don't recall ever seeing
explanations of by who, exactly. |
| 05:40.52 |
Ralith |
deeeffache:
it's certainly production-quality; bar friendly GUI, I'd even go so
far as to say the quality is above most commercial
software. |
| 05:53.20 |
deeeffache |
I agree on
the quality, I just always hear of autocad or pro/e or
solidworks |
| 05:59.59 |
Ralith |
sure, and you
always hear of windows too. |
| 06:00.46 |
Ralith |
not to be a
linux fanboy or anything, but it's an apt metaphor. |
| 06:12.37 |
deeeffache |
Ill rephrase,
i always see those under the required skill section on job
postings |
| 06:12.58 |
Ralith |
ah. |
| 06:13.11 |
Ralith |
Well, not
much we can do about that beyond further improve
BRL-CAD. |
| 06:13.39 |
Ralith |
We've got
some pretty cool features in the pipeline. |
| 06:15.37 |
deeeffache |
Yeah, ive
been reading the project ideas, id love to see the material
properties and physics integration |
| 06:16.55 |
Ralith |
that's the
least of it; the code's undergoing a refactor to allow full editing
capabilities as a library, and there's work to support version
control and remote collaboration too, iirc. |
| 06:37.36 |
CIA-40 |
BRL-CAD:
03ralith * r34080 10/brlcad/trunk/src/burst/ (Makefile.am grid.c
paint.c plot.c prnt.c vecmath.h): Removed another redundant
vecmath.h from burst, replacing uses with vmath.h
macros. |
| 06:40.12 |
Ralith |
that one was
much easier. |
| 07:27.27 |
*** join/#brlcad madant
(n=madant@117.196.142.98) |
| 07:31.11 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1297 10/wiki/Animation: /* With Mencoder */ |
| 07:32.04 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1298 10/wiki/Animation: /* With Mencoder */ |
| 08:17.49 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1299 10/wiki/Animation: /* With Mencoder */ |
| 08:18.12 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1300 10/wiki/Animation: /* With Mencoder */ |
| 08:21.49 |
*** join/#brlcad madant_
(n=madant@117.196.139.1) |
| 08:29.05 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:44.40 |
*** join/#brlcad madant__
(n=madant@117.196.145.166) |
| 09:00.27 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:05.12 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:34.21 |
d-lo |
morning
all! |
| 10:39.30 |
mafm_ |
hi
d-lo |
| 10:41.11 |
d-lo |
whats shakin
mafm? |
| 10:42.06 |
mafm_ |
not much,
reading thedailywtf during a pause :) |
| 10:43.09 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 10:58.04 |
*** join/#brlcad madant_
(n=madant@117.196.150.228) |
| 11:28.52 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 11:31.55 |
*** join/#brlcad madant__
(n=madant@117.196.149.80) |
| 12:12.23 |
*** join/#brlcad madant__
(n=madant@117.196.145.249) |
| 12:53.51 |
*** join/#brlcad csanyipal
(n=csanyipa@22-144-85-95.dynamic.stcable.net) |
| 12:54.07 |
csanyipal |
howdy |
| 12:54.53 |
*** join/#brlcad d_rossberg
(n=rossberg@66.111.56.50) |
| 13:11.07 |
*** join/#brlcad madant
(n=madant@117.196.140.107) |
| 13:44.52 |
CIA-40 |
BRL-CAD:
03bob1961 * r34081 10/brlcad/trunk/src/ (9 files in 3 dirs): Modify
bwish and archer to NOT use BLT. |
| 14:04.35 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1301
10/wiki/Google_Summer_of_Code: 2009 |
| 14:06.46 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1302
10/wiki/Google_Summer_of_Code/2009: we're in, update
info |
| 14:07.16 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.209.227.dynamic.adsl.gvt.net.br) |
| 14:14.07 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1303
10/wiki/Google_Summer_of_Code: update info, reorganize |
| 14:35.56 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 14:35.56 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad deeeffache (n=deeeffac@99.141.236.239)
[NETSPLIT VICTIM] |
| 14:35.56 |
*** join/#brlcad PrezKennedyIII
(i=Matthew@whitecalf.net) |
| 14:35.56 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 14:35.56 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 14:35.56 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad CIA-40 (n=CIA@208.69.182.149.simpli.biz)
[NETSPLIT VICTIM] |
| 14:35.57 |
*** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad redvsblue
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 14:35.57 |
*** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38)
[NETSPLIT VICTIM] |
| 14:35.57 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.209.227.dynamic.adsl.gvt.net.br) [NETSPLIT
VICTIM] |
| 14:35.57 |
*** join/#brlcad d_rossberg (n=rossberg@66.111.56.50)
[NETSPLIT VICTIM] |
| 14:35.58 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 14:35.58 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 14:35.58 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 14:47.18 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 14:47.18 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 14:47.34 |
*** join/#brlcad pacman87 (i=500@resnet-46-40.dorm.utexas.edu)
[NETSPLIT VICTIM] |
| 14:47.34 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 15:47.58 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 15:47.58 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.4 posted this weekend (20090313) || GSoC 2009
Begins! |
| 16:10.18 |
*** join/#brlcad pacman87 (i=500@resnet-46-40.dorm.utexas.edu)
[NETSPLIT VICTIM] |
| 16:10.18 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 17:31.45 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:31.45 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.4 posted this weekend (20090313) || GSoC 2009
Begins! |
| 17:35.19 |
*** join/#brlcad PrezKennedyIII
(i=Matthew@whitecalf.net) |
| 17:45.58 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-f50427b097277774) |
| 18:19.43 |
CIA-40 |
BRL-CAD:
03bob1961 * r34085 10/brlcad/trunk/src/archer/archer: Make the
initial window size a little smaller. Eventually, the window size
and location will be saved and used at startup. |
| 18:41.48 |
CIA-40 |
BRL-CAD:
03bob1961 * r34086
10/brlcad/trunk/src/other/tk/library/panedwindow.tcl: Hack to get
around the occassional complaining from the panedwindow about
identify being a bad option. |
| 18:46.14 |
*** join/#brlcad smurfette
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) |
| 19:33.16 |
CIA-40 |
BRL-CAD:
03bob1961 * r34087 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Modified the buildComboBox method to
use ttk::combobox. |
| 19:52.33 |
CIA-40 |
BRL-CAD:
03bob1961 * r34088
10/brlcad/trunk/src/tclscripts/archer/GeometryEditFrame.tcl:
Modified the buildComboBox method to use ttk::combobox. |
| 19:52.48 |
CIA-40 |
BRL-CAD:
03bob1961 * r34089
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Minor
cleanup. |
| 19:59.48 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 20:16.49 |
brlcad |
mafm_:
heh |
| 20:19.55 |
kanzure |
madant: Hey.
Dawn, right? |
| 20:19.58 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 20:20.06 |
kanzure |
madant: I
just came across this: http://code.google.com/p/descomp/ |
| 20:20.07 |
kanzure |
that's you,
right? |
| 20:20.25 |
kanzure |
Do you have
any of the Stiny papers on parametric shape grammars? |
| 20:20.53 |
brlcad |
Ralith:
various editors and stream tools will automatically strip out the
carriage returnss, the windows files in svn certainly haven't
changed line ending anytime soon |
| 20:21.10 |
brlcad |
Ralith: oh
yeah, and nice refactoring! |
| 20:28.06 |
brlcad |
svn
intentionally left out that horrible feature of cvs admin, no way
to nuke revisions other than dumping the backend repository and
filtering out revision(s) (via svndumpfilter) |
| 20:29.29 |
brlcad |
abs/fabs/min/max are all portability
problematic prior to c99 |
| 20:30.46 |
brlcad |
deeeffache:
what would constitute a lot? |
| 20:32.11 |
brlcad |
ah, see you
all already hashed that out as well. :) |
| 20:35.59 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 20:51.23 |
CIA-40 |
BRL-CAD:
03brlcad * r34090 10/brlcad/trunk/NEWS: bob changed archer/bwish to
no longer use BLT. annotate the change to our external
dependencies. |
| 20:58.40 |
*** join/#brlcad BenReilly
(n=benreill@d154-5-59-169.bchsia.telus.net) |
| 21:02.27 |
BenReilly |
Hello
everyone. I'm looking at applying to GSoC, and to begin, I'd like
to know what sort of software development experience BRL-CAD would
be looking for in their candidates. |
| 21:02.56 |
brlcad |
howdy
BenReilly |
| 21:03.07 |
CIA-40 |
BRL-CAD:
03brlcad * r34091 10/brlcad/trunk/NEWS: reduced archer's initial
and maximum window size from 2048x1600 to 1400x1100 (with max at
1600x1200) |
| 21:03.50 |
brlcad |
BenReilly:
experience isn't nearly as much of an issue (depending on the
project) as is the ability to learn quickly and take
initiative |
| 21:04.11 |
``Erik |
enough to be
successful at your project, but not so much that it doesn't provide
a fun challenge? :D |
| 21:04.28 |
brlcad |
ell
said |
| 21:04.36 |
brlcad |
'well said'
even |
| 21:06.28 |
BenReilly |
Right, of
course. As well, though I don't mean to pile too many questions on
you, how much C/C++ experience are you looking for. For instance,
some ideas require a "familiarity" with the language, and I would
like to know how extensive my familiarity should be. I ask because
I have not worked a lot with C or C++, but I have a strong
knowledge of Java and general programming language syntax and
such. |
| 21:07.02 |
pacman87 |
BenReilly: it
depends on the project |
| 21:07.16 |
*** join/#brlcad samrose
(n=samrose@adsl-68-73-206-130.dsl.sfldmi.ameritech.net) |
| 21:08.13 |
pacman87 |
the hardest
part of my project last year was working through all the
math |
| 21:08.15 |
``Erik |
I'd imagine
one of the biggest hurdles for java->c/c++ is grasping pointers.
if you're comfortable with those, the rest is just minor
syntax |
| 21:08.55 |
``Erik |
of course, we
have chunks that are java and tcl/tk, as well *shrug* |
| 21:08.56 |
BenReilly |
``Erik:
That's what I've heard. |
| 21:10.19 |
``Erik |
tell ya what,
figure out what you'd like to do, then we can talk about what level
of ability might be needed for that? |
| 21:11.12 |
``Erik |
(unless
brlcad has a better idea) |
| 21:11.35 |
BenReilly |
Sounds good.
Well, one that caught my eye was the "New Geometry
Converter" |
| 21:11.39 |
BenReilly |
Would you
like a link? |
| 21:11.50 |
``Erik |
which
format? |
| 21:12.52 |
BenReilly |
In terms of
converting? Let's go with POV-Ray. |
| 21:13.47 |
``Erik |
ooh, that'll
be a tough one, but it shouldn't require a lot of C knowledge. it'd
be quite a bit of effort mapping and translating the different
primitive sets and re-creating the procedural stuff in POV,
though |
| 21:14.48 |
``Erik |
started one a while back hoping to hack it out in a day or
two for performance comparisons, decided it was not a 1-2 day hack
:D |
| 21:16.38 |
BenReilly |
Ah, I see. So
then, what sort of steps would be involved in that kind of
project? |
| 21:17.18 |
BenReilly |
Is it simply
(though perhaps not truly "simply") converting a brl-cad file to
and from a .pov file? |
| 21:17.44 |
``Erik |
ayup |
| 21:18.06 |
``Erik |
g-pov -o
mything.pov mything.g all.g |
| 21:18.14 |
``Erik |
pov-g
mything.pov mything.g |
| 21:18.17 |
brlcad |
bbiab |
| 21:18.18 |
BenReilly |
Well then, I
suppose that I should become familiar with the brl-cad files then,
eh? |
| 21:18.25 |
brlcad |
always a good
thing ;) |
| 21:18.29 |
``Erik |
make those
g-pov/pov-g things and it's a full converter |
| 21:18.47 |
BenReilly |
Gotcha |
| 21:19.07 |
*** join/#brlcad andax
(n=andax__@d213-102-40-60.cust.tele2.ch) |
| 21:20.16 |
``Erik |
the tricky
part is we have primitives they don't, they have primitives we
don't, and some of the primitives shared are subtly different.
Additionally, pov allows things like logical constructs and loops
(turing complete, yo!) where BRL-CAD is static geometry |
| 21:21.11 |
BenReilly |
brb |
| 21:21.57 |
``Erik |
(E.G. pov can
do "for(i=0;i<100;i++) rotate(sph, somepoint, i*2);" to generate
100 sph's rotated around a point, where in BRL-CAD, you need those
100 sph's in the .g file) |
| 21:25.36 |
BenReilly |
Haha, wow.
Now I would imagine that in converting a .g file to .pov, it would
be great to be able to take those 100 rotate() calls and drop them
into a for loop, no? |
| 21:26.35 |
BenReilly |
Though that
in itself would not be trivial for anything but a single call
repeated x times. |
| 21:32.43 |
BenReilly |
Pardon me, I
misread the last part of your example. |
| 21:32.53 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 21:33.00 |
BenReilly |
In any case,
I'm going to go poke around brl-cad and see what it's all
about |
| 21:33.13 |
BenReilly |
Thanks for
the info |
| 21:37.29 |
BenReilly |
And I'll be
off. Perhaps I'll talk to you later. |
| 21:37.41 |
*** part/#brlcad BenReilly
(n=benreill@d154-5-59-169.bchsia.telus.net) |
| 21:57.29 |
Ralith |
brlcad: the
weird thing was, my local copies had *added* ^Ms |
| 21:57.33 |
Ralith |
also, thanks
:] |
| 21:58.19 |
Ralith |
needs to decide on a project to apply for |
| 22:45.48 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 22:54.35 |
jonored_ |
also needs to work out a project to apply for. Unsure as to
whether to apply for finishing a real run through the G-code
thing. |
| 23:38.41 |
deeeffache |
brlcad: im
not sure, I was looking to find some companies that use it as their
primary CAD software and have not found any so far. |
| 00:14.59 |
``Erik |
http://www.collegehumor.com/video:1905311
O.O neat |
| 00:50.19 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:54.07 |
*** join/#brlcad BigAToo
(n=BigAToo@70.43.244.82.nw.nuvox.net) |
| 01:44.32 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-23611fde1c4dab83) |
| 01:57.34 |
``Erik |
dangit, this
fortune cookie says "you are not a winner. try again."
:( |
| 02:10.18 |
starseeker |
reflects that's almost exactly how he felt doing taxes
:-/ |
| 02:22.14 |
brlcad |
deeeffache:
the U.S. Army Research Laboratory is one of the few places that use
it as their primary |
| 02:22.33 |
brlcad |
as it's
specifically tuned to their needs (and comes from them and
continues to have development funded by them, etc) |
| 02:23.28 |
brlcad |
which
actually happens to be more of an expert-driven CAE environment,
but with strong solid modeling and geometry needs too |
| 03:07.09 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 03:54.52 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 04:17.01 |
*** join/#brlcad madant
(n=madant@117.196.142.238) |
| 05:34.15 |
deeeffache |
brlcad: thats
good to hear. My initial assumption was that they open sourced it
because they were moving on to something "better" |
| 07:33.21 |
brlcad |
deeeffache:
nope, it was opened sourced after many years of effort not because
it's not in use, but quite the opposite -- ARL is heavily dependent
on and supportive of BRL-CAD, but has relatively limited
development capacity because of other priorities (they're not in
the software business after all, they do research and analysis
work) |
| 07:35.56 |
brlcad |
going open
source was (successfully) argued as a means to give back to the
community (tax-payer funded) and encourage/allow open community
development, to potentially see BRL-CAD development accelerate
faster than ARL can directly fund (and for more varied interests)
-- a win/win situation |
| 07:47.49 |
Ralith |
``Erik: a
fortune cookie says that? |
| 07:47.57 |
Ralith |
since when
can you win something from fortune cookies |
| 07:49.25 |
brlcad |
kudos to
Peter Kan for getting his app in first/early :) |
| 07:49.37 |
Ralith |
needs to do that. |
| 07:50.00 |
brlcad |
indeed |
| 07:50.38 |
brlcad |
keep in mind
that you can get something in quickly and then continue to revise
it through the sochop interface |
| 07:51.16 |
Ralith |
oh,
really? |
| 07:51.21 |
Ralith |
that's
handy |
| 07:51.41 |
brlcad |
it's after
the deadline that it gets locked down |
| 07:53.16 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 07:53.39 |
brlcad |
morning
d_rossberg |
| 07:53.42 |
Ralith |
so why is the
oop API project identified as high difficulty? I always thought of
wrappers like that as being relatively straightforward. |
| 07:53.55 |
d_rossberg |
moin moin
brlcad |
| 07:56.24 |
brlcad |
Ralith:
mostly because it requires a fair bit of background knowledge that
most people don't have -- knowledge of OOP design patterns,
knowledge of our libraries (librt, libwdb, libged, libbn, libbu),
(basic) familiarity with geometry engines like acis or granite,
.. |
| 07:57.10 |
brlcad |
it's also a
lot of work, a lot of places to get something very wrong or make
something very poorly designed |
| 07:58.37 |
Ralith |
ah. |
| 07:59.58 |
brlcad |
you can get
away with only having two of those three, heck even just OO design
.. but then you'd have to be even more adept at learning a large
codebase quickly (and working on an effort that is already under
way too) |
| 08:00.34 |
Ralith |
is there
documentation available for acis/granite? |
| 08:00.59 |
brlcad |
just what you
can find by searching, they're commercial CAD engines |
| 08:01.28 |
Ralith |
well, that
doesn't necessarily mean there aren't good docs up
anywhere. |
| 08:01.29 |
Ralith |
checks |
| 08:01.29 |
brlcad |
don't really
want to use them either (in case there are patent issues, for
example), but should be aware of their scope and intent |
| 08:03.31 |
deeeffache |
What happened
to the project priorities on the wiki faq? http://brlcad.org/wiki/FAQ |
| 08:05.56 |
Ralith |
Are the
doxygen docs hosted on brlcad.org? |
| 08:06.07 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34092 10/brlcad/trunk/ (include/bu.h
src/libbu/avs.c): added const specifiers to
bu_avs_add_nonunique()'s parameters |
| 08:07.46 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34093 10/brlcad/trunk/src/libged/CMakeLists.txt:
added bu_flip.c and bu_sync.c to stay in sync with
Makefile.am |
| 08:08.44 |
brlcad |
Ralith: mmm..
only an old copy, I believe |
| 08:09.11 |
Ralith |
mightn't it
be a Good Thing to make them available there? |
| 08:09.13 |
brlcad |
http://brlcad.sourceforge.net/doxygen/index.html |
| 08:09.20 |
brlcad |
sure
would |
| 08:09.43 |
brlcad |
just nobody
has taken the time to do it, busy with other things |
| 08:10.27 |
Ralith |
ah well. I'd
take care of it were it covered by svn. |
| 08:12.02 |
Ralith |
I don't
suppose you'd know why g3d depends on the SVN version of
OGRE? |
| 08:12.54 |
brlcad |
deeeffache:
fixed |
| 08:13.04 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1304
10/wiki/FAQ: they're not in my dir |
| 08:13.46 |
brlcad |
Ralith: I
believe there were build system problems that was only fixed in
latest svn -- mafm can surely recall better though |
| 08:14.12 |
Ralith |
build system
problems? O.o |
| 08:14.17 |
Ralith |
well, I guess
I'll wait for mafm to show. |
| 08:14.29 |
Ralith |
and get ogre
updated here while I'm at it. |
| 08:14.49 |
brlcad |
d_rossberg:
heh, subliminal slip? .. bu_* ? :-) |
| 08:14.55 |
deeeffache |
blasted
~sean, thanks! |
| 08:16.24 |
brlcad |
Ralith:
assuming they'd build clean out of the box or with a simple
bootstrapping, they'd be a prime candidate to become an
svn:externals |
| 08:17.13 |
Ralith |
brlcad: isn't
it bad practice to make such assumptions of a trunk? |
| 08:17.34 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:17.36 |
Ralith |
(assuming
that mafm was aware of the bugfix branch and refrained from its use
because it didn't work) |
| 08:17.37 |
brlcad |
never said
it'd need to be trunk |
| 08:17.53 |
Ralith |
I'm not
familiar with externals |
| 08:17.58 |
Ralith |
can you force
certain revisions, or something? |
| 08:19.05 |
brlcad |
it just takes
a repository path like checkout, so yeah -- regular revision syntax
works just fine |
| 08:19.26 |
brlcad |
not that
using trunk would be horrible -- they're actually a pretty stable
trunk last time I was working off svn at least |
| 08:20.16 |
Ralith |
their page
gives that impression too, but it would still result in
unpredicttable behavior |
| 08:20.21 |
Ralith |
-t |
| 08:20.40 |
Ralith |
especially if
some sort of breaking API change came along. |
| 08:22.13 |
Ralith |
well, I'll
see if I can make g3d work with stable and make the whole issue
moot. |
| 08:22.25 |
brlcad |
goes both
ways, arguably easier to fix (less time-intensive) the sooner the
change occurs before code is entrenched around the old
code/api |
| 08:23.08 |
Ralith |
does make our
own trunk less stable with respect to g3d, though. |
| 08:23.17 |
Ralith |
not that that
matters too much at this stage, I suppose |
| 08:23.43 |
brlcad |
moot issue,
though -- that wasn't/isn't a production release code yet -- it's a
"get it working" project, basic fundamentals |
| 08:23.49 |
*** join/#brlcad madant
(n=madant@117.196.136.62) |
| 08:24.48 |
brlcad |
more
important at this point that it just not actually take up any time
(which it didn't/doesn't), so the focus can be on the
interface |
| 08:25.12 |
Ralith |
yeah |
| 08:35.06 |
Ralith |
brlcad:
remind me why mafm didn't use CEGUI? |
| 09:25.47 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:44.36 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-3fbc3be046b60aa5) |
| 10:24.50 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:05.20 |
*** join/#brlcad PrezKennedyIII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 11:05.20 |
*** join/#brlcad deeeffache (n=deeeffac@99.141.236.239)
[NETSPLIT VICTIM] |
| 11:44.14 |
starseeker |
notes that as of last night, trunk passed make distcheck on
gentoo |
| 11:49.32 |
*** join/#brlcad madant
(n=madant@117.196.136.12) |
| 12:11.49 |
*** join/#brlcad madant_
(n=madant@117.196.133.129) |
| 13:01.49 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34094 10/rt^3/trunk/ (2 files in 2 dirs): SetName()
and SetMatrix() for leaf nodes |
| 13:03.08 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34095 10/rt^3/trunk/include/brlcad/ConstDatabase.h:
removed unnecessary virtual |
| 13:06.36 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34096 10/rt^3/trunk/ (3 files in 2 dirs): read and
write Object-attributes (bu_attribute_value_set) |
| 13:24.06 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 13:24.30 |
madant_ |
kanzure:
stiny's papers are awesome albeit old, a good resource is cumincad
.. the membership to acadia, caadria, ecaade etc. are pretty cheap
but really worth it. I like the later approaches by Knight etc.
Mathematical formalism of shape grammars is cute indeed but
practical applications would be a greater awesomeness
:D |
| 13:24.52 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 13:37.32 |
*** join/#brlcad ``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 13:46.28 |
CIA-40 |
BRL-CAD: 03D
rossberg 07http://brlcad.org *
r1305 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: |
| 13:47.01 |
brlcad |
heh,
punctuation |
| 13:47.45 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 13:55.14 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 13:55.38 |
brlcad |
howdy
dreeves |
| 13:55.49 |
dreeves |
hey |
| 13:55.58 |
CIA-40 |
BRL-CAD: 03D
rossberg 07http://brlcad.org *
r1306 10/wiki/CoreInterface_Hallo_World_Example: coreInterface
"Hello World" example |
| 13:58.38 |
dreeves |
How's the
rowing brlcad? |
| 14:02.50 |
brlcad |
dreeves:
chilly, but great |
| 14:10.14 |
CIA-40 |
BRL-CAD: 03D
rossberg 07http://brlcad.org *
r1307 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: added the tree
walker example |
| 14:11.17 |
kanzure |
madant_:
http://groups.google.com/group/openmanufacturing/msg/82dd7c56fcfaefb4?
re: shape grammars. |
| 14:16.40 |
CIA-40 |
BRL-CAD: 03D
rossberg 07http://brlcad.org *
r1308 10/wiki/CoreInterface_Tree_Walker_Example: coreInterface tree
walker example |
| 14:52.32 |
*** join/#brlcad madant
(n=madant@117.196.143.212) |
| 14:53.44 |
*** join/#brlcad _sushi__
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 14:55.07 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34097
10/rt^3/trunk/src/coreInterface/Combination.cpp: it looks like a
non-region combination may have other boolean operations than
unions too |
| 15:48.06 |
CIA-40 |
BRL-CAD: 03D
rossberg 07http://brlcad.org *
r1309 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: added the
PrintTitle example |
| 15:59.50 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 16:15.04 |
CIA-40 |
BRL-CAD:
03starseeker * r34098 10/brlcad/trunk/doc/TODO.BREP: Add some
notes/brainstorming related to the question of deciding if two
points are the same point when they have error bounds. |
| 17:20.06 |
starseeker |
make
distcheck passes on the mac |
| 17:51.51 |
brlcad |
woot |
| 17:56.17 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.3.209) |
| 18:00.56 |
*** join/#brlcad ``Erik
(n=erik@ftp.brlcad.org) |
| 18:01.24 |
``Erik |
stupid
comcrap |
| 18:03.45 |
*** join/#brlcad beebee_
(n=boerrebj@ti0036a380-0289.bb.online.no) |
| 18:18.04 |
brlcad |
howdy
beebee_ |
| 18:18.14 |
beebee_ |
hello |
| 18:19.43 |
brlcad |
wonders if there are any others interested in being a gsoc
mentor, send me a note in private or public if
interested |
| 18:21.41 |
beebee_ |
sorry, I am
new to brlcad development, but i hope you find a mentor. I would
love to see that some of the proposals gets implemented |
| 18:22.06 |
``Erik |
I can ask
indianlarry for ya, if you haven't already |
| 18:23.46 |
jonored |
On the other
side, any suggestions for someone who wants to write up a proposal
and likes math a bunch? |
| 18:26.41 |
brlcad |
beebee_: we
have mentors, just reminding a few other devs that hang out in here
that they have the opportunity :) |
| 18:26.57 |
brlcad |
``Erik: I
asked him, he said yes, but he still hasn't gone to sochop
yet |
| 18:27.25 |
brlcad |
jonored: heh,
you mean suggestions for a project proposal? |
| 18:28.01 |
``Erik |
aight, got
him on the page now |
| 18:29.01 |
jonored |
brlcad:
...yes? I suppose I should go read the webpage again and try to
find one... |
| 18:30.40 |
brlcad |
jonored, the
more math-intenseive suggestions are actually all annotated on the
ideas page |
| 18:30.43 |
brlcad |
just search
for math |
| 18:31.10 |
``Erik |
all ur maff r
belong to teh cheezburger kittehs |
| 18:31.59 |
jonored |
Okay. I did
finally work out that curvature of an intersection of a plane and a
surface thing, and kinda liked the doing. |
| 18:32.58 |
brlcad |
right, that
was your patch last year, yes? |
| 18:33.24 |
brlcad |
er, not
surface, but line and curve? |
| 18:34.07 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 18:34.12 |
jonored |
Never passed
stuff in. I was just digging through trying to be able to slice a
surface with a plane and interpolate the curve with
arcs. |
| 18:36.14 |
jonored |
And there
isn't somewhere that I know it'd fit outside of the reprap-specific
stuff I was doing. |
| 18:38.06 |
brlcad |
ah, jonored
.. confused you with jdoliner :) |
| 18:38.16 |
brlcad |
he's the one
that had the line intersection patch |
| 18:39.55 |
jdoliner |
hmm it just
buzzed me |
| 18:40.09 |
jdoliner |
I guess you
weren't actually looking for me though |
| 18:41.21 |
jonored |
Ah, okay.
That would explain that. Would digging into constraints &
parametrics be something viable? |
| 18:42.28 |
brlcad |
jdoliner:
nope, just talking about you |
| 18:42.51 |
jdoliner |
I see, carry
on then gents |
| 18:42.56 |
brlcad |
jonored:
possibly, but you'd need to coordinate that with madant since it's
a previous gsoc project already "in progress" |
| 18:43.28 |
brlcad |
you'd have to
sort out who's working on what since he'll possibly continue
working on it as well this year |
| 18:43.35 |
brlcad |
(and you
can't collaborate on a group project) |
| 18:44.13 |
brlcad |
have to be
separatable tasks with your own goals -- otherwise, yeah --
fantastic area to work on |
| 18:47.39 |
*** join/#brlcad boerrebj_
(n=boerrebj@ti0036a380-1997.bb.online.no) |
| 18:50.46 |
brlcad |
``Erik: tell
larry that he has to accept the invite next |
| 18:51.22 |
``Erik |
he's filling
out the form right now |
| 18:52.00 |
brlcad |
happy happy
joy joy |
| 18:52.12 |
jonored |
Okay. So
interesting, but it'd take effort to fit it into gsoc. CSG of
BREP? |
| 18:52.47 |
``Erik |
he's all good
now? |
| 18:53.36 |
``Erik |
huh,
actually, I coulda clicked in and accepted him, too |
| 18:57.02 |
brlcad |
yep, he's
good |
| 18:57.32 |
brlcad |
jonored: CSG
of BREP is pretty tough, but very high priority too :) |
| 18:57.49 |
brlcad |
very much
related to what starseeker and I are presently working
on |
| 19:11.50 |
starseeker |
hoovers up articles on intersection
algorithms |
| 19:13.29 |
jonored |
I should
probably write that up then, it sounds like fun. And start reading.
Or rather, continue reading, as now I've gotten
distracted. |
| 19:22.53 |
brlcad |
cool |
| 19:23.00 |
brlcad |
that should
be a fun project |
| 19:23.15 |
brlcad |
jonored: you
may also want to check out some of the more recent notes in
doc/TODO.BREP |
| 20:05.30 |
CIA-40 |
BRL-CAD:
03Paulcs 07http://brlcad.org *
r1311 10/wiki/Animation: /* With Mencoder */ |
| 20:07.29 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:18.30 |
starseeker |
raises eyebrows - apparently MeshLab is using Eigen.
Hmm |
| 20:32.25 |
starseeker |
make
distcheck passed on 64 bit Redhat Linux |
| 20:53.44 |
hippieindamakin8 |
hey
brlcad |
| 20:59.34 |
brlcad |
howdy
hippieindamakin8 |
| 21:02.15 |
hippieindamakin8 |
hey rt now
opennurbs just supports the brep and the interconversion of the
representations is wat is expected isnt it |
| 21:02.28 |
hippieindamakin8 |
i went
through the papers of esolid and bit of boole |
| 21:04.26 |
hippieindamakin8 |
brlcad, wat
do u exactly mean by BREP-on-BREP CSG evaluations ? |
| 21:06.45 |
brlcad |
basically,
you have some spline-surface object (a NURBS object) and another
spline-surface object that overlap and there's a specified boolean
evaluation of subtraction, intersection, or union -- evaluate the
surfaces and derive the resulting spline-surface object |
| 21:07.57 |
hippieindamakin8 |
brlcad, this
includes nm objects |
| 21:08.13 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 21:08.44 |
brlcad |
what are nm
objects |
| 21:08.58 |
hippieindamakin8 |
non -
manifold |
| 21:09.28 |
hippieindamakin8 |
brlcad, the
project involves computationally optimised evaluations of the
breps |
| 21:09.38 |
hippieindamakin8 |
is it
? |
| 21:12.19 |
brlcad |
they're not
optimised |
| 21:12.23 |
brlcad |
they're just
evaluated |
| 21:12.44 |
brlcad |
they from an
unevaluated form to an evaluated form |
| 21:13.09 |
brlcad |
and no, I
don't think it'd necessarily need to include non-manifold geometry
but it would need to handle n-manifold geometry |
| 21:13.11 |
hippieindamakin8 |
yeah
basically the evaluation of the booleans is wat has to be
done |
| 21:14.16 |
hippieindamakin8 |
brlcad, yeah
true it is very rarely that we encounter the non-manifold
geometries (may be because of the degenerate cases of the boolean
operations on csgs) |
| 21:15.05 |
brlcad |
wonders if hippieindamakin8 has something against the word
"what" |
| 21:15.17 |
hippieindamakin8 |
:) |
| 21:28.48 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 22:03.58 |
Ralith |
hey
jonored! |
| 22:04.00 |
Ralith |
how's the
slicer? |
| 22:08.02 |
*** join/#brlcad andax
(n=andax__@d213-102-40-152.cust.tele2.ch) |
| 22:34.38 |
*** join/#brlcad ``Erik___
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 22:48.53 |
``Erik |
O.o |
| 22:58.41 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 23:43.26 |
bjorkintosh |
jonored did
not want to talk about the slicer. |
| 23:52.19 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 00:04.50 |
Ralith |
pokes jonored |
| 00:05.46 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.198.192) |
| 00:20.45 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:43.16 |
*** join/#brlcad Lez
(n=lezardfl@189.58.212.25.dynamic.adsl.gvt.net.br) |
| 00:51.40 |
``Erik |
eeks, take
that somewhere private, ralith O.O |
| 00:52.20 |
Ralith |
prude. |
| 01:09.55 |
Ralith |
discovers that all the pkgconfig files appear to be
broken. |
| 01:09.59 |
Ralith |
does something about this. |
| 01:11.14 |
CIA-40 |
BRL-CAD:
03ralith * r34099 10/brlcad/trunk/misc/pkgconfig/ (13 files): Fixed
fatal dependent variable mis-ordering |
| 01:29.35 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.212.25.dynamic.adsl.gvt.net.br) |
| 01:40.48 |
kanzure |
Hi all. Has
anyone any experience with elmerfem? |
| 02:03.47 |
Ralith |
dear god it's
hard to get RBGui to build |
| 02:34.53 |
Ralith |
rewrites most of g3d's build system |
| 02:41.02 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.198.192) |
| 02:43.35 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.198.192) |
| 02:46.20 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.198.192) |
| 02:51.53 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 03:20.39 |
CIA-40 |
BRL-CAD:
03ralith * r34100 10/rt^3/trunk/src/g3d/ (10 files in 2 dirs):
Extensive build system cleanup/reliability fixes: BRL-CAD is now
correctly autodetected, reliability of all other dependency
detection has vastly improved. |
| 03:21.37 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:24.30 |
Ralith |
brlcad: do
you know if mafm's returning this year to GSoC on the
GUI? |
| 03:27.50 |
Ralith |
also, seems
to work fine(ish) on OGRE 1.6.1 |
| 03:28.06 |
Ralith |
the build
system's largely Done Right now :] |
| 03:47.44 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-199c8c222cf2d764) |
| 03:50.21 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 04:27.32 |
brlcad |
Ralith:
actually I don't know -- he's had personal matters to take care of,
he may not |
| 04:27.55 |
brlcad |
glad to hear
it worked ;) |
| 04:29.41 |
Ralith |
I think I'll
apply for that, then |
| 04:29.50 |
Ralith |
seeing as
I've some degree of familiarity with it |
| 04:33.48 |
brlcad |
feel free to
mail him or the mailing list to check up with him |
| 04:34.25 |
brlcad |
it would be
nice to see someone continue making progress |
| 04:57.55 |
Ralith |
yeah, I'm
looking forward to having it hooked up and doing things |
| 04:58.30 |
Ralith |
I'll see if I
can get in touch with him, and get my app started in the
meantime |
| 05:37.16 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 06:01.42 |
brlcad |
Ralith: if
you do apply for a previous gsoc project, please try to also put
forward another application for one of the other ideas as
well |
| 06:01.57 |
brlcad |
that goes for
anyone and any previous gsoc project |
| 06:03.55 |
brlcad |
it often
happens that some of the most desirable students all put in for the
same project, rejecting several desirable students that would have
otherwise been selected for a different project |
| 06:04.40 |
brlcad |
course that's
only if someone can put together two *good* applications, and the
second one doesn't decrease the quality of the first one! if you
just have time for one, then so be it |
| 06:05.18 |
brlcad |
also an even
better reason to submit it earlier rather than later so we can give
feedback and gauge whether there are conflicts |
| 06:06.32 |
Ralith |
there're
multiple people going for that one? |
| 06:07.30 |
Ralith |
I'm certainly
happy to apply to another, though; I'm quite interested in getting
in on GSoC, so anything that increases my chances... |
| 06:07.48 |
Ralith |
not to
mention this is a fun project. |
| 06:08.06 |
brlcad |
there usually
are three or four projects that get several submissions each by the
deadline |
| 06:08.45 |
brlcad |
last year,
there were about 20 valid interesting applications, about 10 of
those were very good, from there we narrowed down on 4 |
| 06:08.57 |
Ralith |
while you're
around; do you remember if there was any reason g3d is using RBGui
rather than something more active? |
| 06:09.02 |
Ralith |
the project's
outright abandoned these days. |
| 06:09.29 |
Ralith |
says as much
on the site, and it took me half an hour of hacking to make it and
its dependent lib build, including writing a build system for
it. |
| 06:09.45 |
brlcad |
yeah, there
was a long long series of discussions about a gui
framework |
| 06:10.46 |
Ralith |
so,
preferable to adopt RBGui over switching it out? |
| 06:10.59 |
brlcad |
rbgui being
dead was one of its downsides, but wasn't seen as a huge one iff it
did everything that was needed (and it had several very interesting
extension aspects) -- it was on par with two or so others iirc, and
it came down to just running with any one of them |
| 06:11.12 |
brlcad |
no, not tied
to rbgui |
| 06:11.51 |
brlcad |
it was just
to move past dwelling on it since there were so many questions
about it vs others that really couldn't be answered without just
trying it out |
| 06:12.33 |
Ralith |
hm. I'd
imagined there must have been some compelling reason to work off of
a dead project. |
| 06:12.52 |
brlcad |
if it can be
made to work, great -- I highly suspect we will end up with a lot
of customized widgets and interactions as it starts coming to
demo-state |
| 06:13.31 |
brlcad |
Ralith: have
you seen their demo? |
| 06:13.36 |
Ralith |
I don't think
so |
| 06:14.08 |
brlcad |
some of the
previous discussion, fwiw -- http://brlcad.org/wiki/Talk:OpenGL_GUI_Framework |
| 06:14.10 |
Ralith |
I'll admit
that when brought to a working state it doesn't look half bad in
g3d |
| 06:14.36 |
Ralith |
quite
modern. |
| 06:14.50 |
brlcad |
http://rightbraingames.com/Gui.wmv |
| 06:15.16 |
Ralith |
pulls it down |
| 06:16.23 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 06:19.00 |
Ralith |
...that is
*very* aesthetically appealing |
| 06:19.43 |
Ralith |
put even a
reasonably usable editor behind that and we'd probably get quite
the spike in users out of ooh-shiny factor alone. |
| 06:19.57 |
brlcad |
nods |
| 06:20.20 |
brlcad |
the basic
skinny about cegui (which I love in concept, btw), is that it
doesn't/didn't yet have vector gui elements, and some widgets are
missing |
| 06:21.06 |
Ralith |
anything
really that hard to add? |
| 06:21.09 |
Ralith |
oo, those
spline widgets are neat |
| 06:21.39 |
brlcad |
yeah, it
would be -- cegui is based around a markup description layer
similar to html |
| 06:21.53 |
Ralith |
that
extensively? I thought that was just for layout. |
| 06:21.55 |
brlcad |
so window
decorations and borders are all themed using images |
| 06:22.22 |
Ralith |
do you know
how extensive RBGui's vector support is? |
| 06:22.41 |
brlcad |
have talked
to a couple of the devs that work on it before -- they plan to add
it at some point, just will take a lot of api changes |
| 06:22.49 |
brlcad |
nope |
| 06:22.54 |
Ralith |
kk |
| 06:23.09 |
brlcad |
yeah, isn't
to say that rbgui solves that problem |
| 06:23.11 |
Ralith |
first glance
suggests just fills and gradients, but I haven't looked at the code
yet, and those cover most practical use cases anyway I
guess |
| 06:23.11 |
brlcad |
either |
| 06:23.21 |
brlcad |
more just
what came up about cegui |
| 06:24.01 |
brlcad |
yeah, it's a
simple enough library that the assertion was it can probably do
just about everything we need it for in the immediate future
regardless |
| 06:24.26 |
brlcad |
as could a
couple others, and if we had to live with maintaining rbgui or one
of the others, so be it |
| 06:24.26 |
Ralith |
well, you've
talked me into agreement with the decision. |
| 06:24.45 |
Ralith |
as you say,
considering the amount of customization we're ultimately likely to
apply to anything, that's not unreasonable. |
| 06:25.05 |
brlcad |
still better
than rolling our own :0 |
| 06:25.18 |
Ralith |
indeed. |
| 06:25.30 |
brlcad |
now another
option that came up just in the last year |
| 06:25.46 |
brlcad |
that was
previously a non-starter due to licensing.. qt |
| 06:26.05 |
brlcad |
could see
someone trying out a qt+ogre swap out |
| 06:26.12 |
Ralith |
qt has bad
licensing? |
| 06:26.19 |
Ralith |
I thought it
was LGPL |
| 06:26.28 |
brlcad |
that just
happened this year |
| 06:26.31 |
Ralith |
ah,
right |
| 06:26.58 |
Ralith |
well, I
dunno. Qt can't render inside an OpenGL context, can
it? |
| 06:27.29 |
brlcad |
hm, I don't
know -- would be a little surprised if it couldn't |
| 06:27.32 |
Ralith |
if that's
correct, that limits our freedom in design
significantly. |
| 06:27.33 |
Ralith |
really? |
| 06:28.02 |
Ralith |
I'd be
surprised if it did; maybe I have a misconception of it, but it
seems wholly targeted at, uh |
| 06:28.05 |
Ralith |
not sure what
the term is |
| 06:28.06 |
Ralith |
normal
apps? |
| 06:29.25 |
Ralith |
I wouldn't
expect gtk to render within a OpenGL context, either. |
| 06:29.29 |
Ralith |
never seen
them used that way, certainly |
| 06:29.54 |
Ralith |
every Qt/gtk
opengl app I've seen always just had an embedded context, with the
GUI surrounding it. |
| 06:30.17 |
Ralith |
not that that
doesn't have a history of working perfectly well, but I like the
possibilities offered by having them render to the same
place. |
| 06:30.26 |
brlcad |
nods |
| 06:30.36 |
Ralith |
not to
mention the plain visual appeal of all the neat fading, smooth
movement, etc. that RBGui implements and that can't be reliably
done otherwise. |
| 06:30.41 |
brlcad |
certainly can
say definitely without some research/testing |
| 06:30.47 |
Ralith |
yeah |
| 06:31.35 |
brlcad |
rbgui gets
away with it simply by rendering everything itself, which has the
cost of lost native look and feel (which is a good and bad
thing!) |
| 06:31.57 |
brlcad |
i don't mind
not looking native if it looks really good, and it
should |
| 06:32.01 |
Ralith |
I'm not sure
anyone expects a modeling app to have native look and feel
thesedays. |
| 06:32.10 |
Ralith |
or maybe
that's just graphics apps. |
| 06:32.42 |
brlcad |
yeah,
modeling is a lot like the gaming industry in that regard where
custom guis are more the norm than the exception |
| 06:33.00 |
Ralith |
and beyond
that, native look and feel is only an element on
OSX/Windows |
| 06:33.07 |
brlcad |
http://doc.trolltech.com/3.3/opengl.html
seems to indicate it's like any other widget |
| 06:33.17 |
brlcad |
implying it
could be layered as needed |
| 06:33.26 |
Ralith |
it's
nigh-impossible to guarantee an app fits in well on a *nix
environment. |
| 06:33.37 |
Ralith |
oh, I didn't
know Qt had capacity for that kind of layering. |
| 06:33.41 |
Ralith |
I guess it
would make sense. |
| 06:34.09 |
Ralith |
would be an
odd omission for something so large and widely used |
| 06:35.04 |
brlcad |
Ralith:
you've seen the IOE video, yes? |
| 06:35.08 |
Ralith |
yup |
| 06:35.13 |
brlcad |
okay,
great |
| 06:35.14 |
Ralith |
it was quite
a while back though |
| 06:35.42 |
Ralith |
it struck me
as very unique |
| 06:35.50 |
brlcad |
that pretty
much surveys the basic look, feel, and interaction direction I'd
like to start with |
| 06:35.54 |
Ralith |
have a link
for it? I should probably review it. |
| 06:36.04 |
brlcad |
brlcad.org/design/gui |
| 06:36.10 |
Ralith |
hehe |
| 06:36.28 |
Ralith |
_final or
_full? |
| 06:38.30 |
brlcad |
final I
believe |
| 06:39.05 |
brlcad |
interesting
qt interface with opengl contexts,
http://www.qtsoftware.com/images/customers/coolapps/realflow4.jpg |
| 06:39.33 |
Ralith |
that looks
about like what I'd expect |
| 06:39.45 |
Ralith |
blender-style
UIs have always felt a lot more integrated to me, tbh |
| 06:39.48 |
brlcad |
yeah |
| 06:42.01 |
brlcad |
a little
better, http://chaos.troll.no/%7Egunnar/jambi_image_viewer.jpg |
| 06:42.40 |
brlcad |
it's faked,
though ;) |
| 06:42.47 |
brlcad |
rather, it's
just an image |
| 06:42.54 |
Ralith |
yeah, looked
that way |
| 06:43.01 |
Ralith |
(I can tell
because of the pixels and etc) |
| 06:43.25 |
Ralith |
that and the
inconsistent widgets. |
| 06:43.51 |
Ralith |
...and the
"Image Viewer" in the title. |
| 06:44.25 |
Ralith |
I suppose I
like the idea of sticking with RBGui, then, and extending it to fit
our needs; might well even be easier than adapting a more
fully-realized lib. |
| 06:44.32 |
brlcad |
here's what I
was looking for |
| 06:44.52 |
brlcad |
more in line,
http://stellarium.org/img/screenshots/0.10-stel_gui.jpg |
| 06:45.06 |
Ralith |
...that's
Qt?> |
| 06:45.09 |
brlcad |
yep |
| 06:45.12 |
Ralith |
wow. |
| 06:45.17 |
Ralith |
because that
doesn't look like Qt at all. |
| 06:45.20 |
Ralith |
that looks
fully integrated. |
| 06:45.26 |
Ralith |
I wonder how
hard it was for them to do that. |
| 06:45.56 |
brlcad |
yeah, qt's
various classes (QtButton, etc) can have their display method
overridden in various ways |
| 06:45.59 |
Ralith |
still
probably can't offer the more 'fun' visual effects, but that's
pretty impressive. |
| 06:46.16 |
brlcad |
basically
allowing custom widget look and feel |
| 06:46.40 |
brlcad |
while still
providing all the same "basic widgets" that you want like tabs,
sliders, scrollers, textareas, etc |
| 06:47.24 |
brlcad |
yeah, don't
know how hard in practice that is, just have seem several projects
customize their qt gui that way |
| 06:47.38 |
brlcad |
if we ended
up with something like that, I'd be content to live with qt
;) |
| 06:47.40 |
Ralith |
example code
in abundance, then. |
| 06:47.56 |
brlcad |
or rbgui, or
whatever, means to an end |
| 06:48.33 |
Ralith |
is inclined to favor the status quo for now, in the absence
of any compelling reason to switch. |
| 06:49.15 |
Ralith |
reminds me, I
recall reading on the Ogre forums a while back of someone working
on a GPU backend for Cairo |
| 06:56.42 |
Ralith |
http://github.com/akyrtzi/cairo-gral/tree/master |
| 06:56.45 |
Ralith |
may be of
interest. |
| 06:57.45 |
brlcad |
wow,
stellarium gui is really impressive |
| 06:58.42 |
Ralith |
installs |
| 06:58.48 |
Ralith |
what's caught
your eye with it? |
| 06:59.17 |
brlcad |
it's very
neatly integrated |
| 07:00.32 |
brlcad |
translucent
overlay windows, persistent menus, an info bar, a persistent info
overlay, drawer menus, clean window/full-screen support |
| 07:03.01 |
Ralith |
hm. I wonder
what license they use, and how easily torn out their GUI code
is. |
| 07:03.41 |
brlcad |
gpl |
| 07:03.49 |
Ralith |
ah. |
| 07:03.56 |
Ralith |
that would be
a problem, then, right? |
| 07:04.00 |
Ralith |
as far as
taking directly. |
| 07:04.08 |
brlcad |
to use their
code direclty, yes |
| 07:04.20 |
Ralith |
gaaah |
| 07:04.24 |
Ralith |
something on
my system hates xinerama |
| 07:04.36 |
Ralith |
my mouse
keeps dying >:| |
| 07:04.53 |
Ralith |
anyway. |
| 07:04.57 |
Ralith |
Qt's an
awfully big dependency. |
| 07:05.11 |
brlcad |
intersting
that they have many of the same widgets as ioe, just in different
places, slightly different behaviors |
| 07:06.38 |
Ralith |
brb, need to
restart X |
| 07:07.48 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 07:08.51 |
brlcad |
yes, it is a
big dep. if it did exactly what we needed, though, I'd certainly
live with that over anything else that didn't give us a crisp
beautiful gui |
| 07:09.05 |
brlcad |
if we could
get that gui with something else, something smaller, even
better |
| 07:11.20 |
Ralith |
for all its
size, does Qt actually offer much relevant to us that RBGui
doesn't? |
| 07:16.01 |
brlcad |
that's hard
to say without doing an evaluation |
| 07:16.27 |
brlcad |
laying out
some of the basic requirements and features and directly doing a
comparison |
| 07:16.49 |
brlcad |
or just
dropping the code in and giving it a go to see how it
works |
| 07:18.00 |
brlcad |
the glitzy
things that make stellarium very compelling are not exactly
provided by qt directly either, so it's really just a matter of
widgets and extensibility |
| 07:18.23 |
Ralith |
nods |
| 07:18.36 |
Ralith |
examines the RBGui widget implementations |
| 07:19.41 |
brlcad |
rbgui is so
simple that my initial reaction last year was that we could
probably gut and extend rbgui to do what we needed with a minimal
amount of effort (no less than most frameworks), at least to get to
an end state that looks and feels like IOE |
| 07:21.25 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 07:21.52 |
brlcad |
where rbgui
will fail is if we need native look and feel, native widget support
and the bells and whistles that come with native widgets (like
pervasive spell-checking, copy paste support, shortcut navigation
and selection keybindings, etc) |
| 07:22.51 |
Ralith |
copy/paste
support should at the very least be trivial to tack on. |
| 07:23.01 |
Ralith |
at least in
X |
| 07:23.02 |
brlcad |
each feature
individually is trivial |
| 07:23.15 |
brlcad |
there are
just about a hundred of them :) |
| 07:23.18 |
Ralith |
point. |
| 07:24.09 |
Ralith |
and Qt is
very, very well supported. |
| 07:24.38 |
Ralith |
and
documented, and ported, and maintained, and... |
| 07:24.46 |
brlcad |
and big
;) |
| 07:25.01 |
Ralith |
the
counterpoint to that is that most users will have it
anyway. |
| 07:25.11 |
brlcad |
but yeah,
it'd be a non-issue otherwise |
| 07:25.19 |
brlcad |
as it pretty
much just works |
| 07:25.50 |
Ralith |
it certainly
has its attractions. |
| 07:26.51 |
brlcad |
so that could
be a gsoc project in itself |
| 07:27.03 |
brlcad |
make [insert
toolkit here] work |
| 07:27.30 |
Ralith |
not nearly as
fun as getting g3d able to actually interact with some geometry,
though. |
| 07:27.32 |
brlcad |
taking it all
the way to matching most of the look and feel intended with
customizations |
| 07:27.45 |
brlcad |
true |
| 07:28.00 |
brlcad |
but the
latter is also complicated by the fact that the backend is a
rapidly moving target |
| 07:28.19 |
brlcad |
there's the
libged library (which it presently hooks to) |
| 07:28.35 |
brlcad |
and which
will give it most of mged's command-line functionality |
| 07:29.13 |
brlcad |
and there's
also the new geometry engine, which is ready for basic geometry
management but not for a full-blown editor just yet (not this
summer) |
| 07:29.46 |
brlcad |
and there's
the geometry service, which is what it should ultimately be using
but is even farther still away from completion |
| 07:30.07 |
Ralith |
so, time
might be best spent on the frontend? |
| 07:30.33 |
brlcad |
probably,
that's the one piece that can be worked on in relative
isolation |
| 07:30.59 |
Ralith |
alright. |
| 07:31.10 |
brlcad |
or working
entirely on the backend, working on one of those three, but then
there's not much to see |
| 07:31.34 |
brlcad |
doing just a
little of the front and little of the back would be a bit of a mess
I think |
| 07:31.34 |
Ralith |
and a lot
more familiarity with BRL-CAD required, no? |
| 07:32.20 |
brlcad |
depends, for
GE yes, for GS slightly less so, for GED not really (it's mostly
refactoring and api cleanup now, almost done) |
| 07:33.16 |
Ralith |
I think my
real reservation about Qt is not so much its raw size as that it
tries to be an entire application framework rather than just a
GUI. |
| 07:33.24 |
Ralith |
that said, I
suppose this is not necessarily a bad thing. |
| 07:33.33 |
brlcad |
that is
true |
| 07:33.54 |
Ralith |
if it's good
at what it does--which I don't know--that might make things a lot
easier. |
| 07:35.07 |
brlcad |
it would be a
gsoc-sized project to convert existing rbgui portion over to qt,
i'm sure there's refactoring that would need to happen along the
way |
| 07:35.46 |
Ralith |
I'm not sure
it wouldn't be easier to start mostly from scratch |
| 07:35.59 |
Ralith |
considering
that even an interface to Ogre is missing |
| 07:36.40 |
brlcad |
hm, I
wouldn't like that -- there's a lot of good effort invested
already |
| 07:36.55 |
Ralith |
that's my
feeling too. |
| 07:36.55 |
brlcad |
things like
various mouse interaction modes for example |
| 07:37.27 |
brlcad |
I'd rather
see it evolve that be replaced, even if it feels like it's a slower
path |
| 07:37.33 |
Ralith |
it's hard to
say how much of it would survive such a major switch |
| 07:38.08 |
Ralith |
but, I
certainly see your point, and I'm sure such an approach is not
infeasible. |
| 07:38.29 |
brlcad |
perfectly
valid to evolve into something completely new |
| 07:40.16 |
brlcad |
but that
would be determined by doing the work and seeing the incremental
steps it needs to take to get there |
| 07:40.39 |
Ralith |
yeah. |
| 07:42.16 |
brlcad |
another good
gsoc project.. de-tcl'fying the core libraries (libbu, libbn,
libwdb, librt, libged) |
| 07:42.24 |
Ralith |
there's TCL
in those? O.o |
| 07:42.25 |
brlcad |
that's a big
refactoring task |
| 07:42.47 |
Ralith |
what's it
doing there? |
| 07:42.48 |
brlcad |
the C api of
tcl |
| 07:43.11 |
brlcad |
tcl actually
has a very nice C library |
| 07:43.23 |
Ralith |
huh? |
| 07:43.33 |
Ralith |
maybe I just
need to look at the code |
| 07:44.39 |
brlcad |
tcl provides
a slew of basic utility classes and callback mechansisms that
slowly integrated into the libs over two decades |
| 07:45.13 |
brlcad |
things like
hash tables, appending results to strings, and evaluating
callbacks |
| 07:46.09 |
Ralith |
so, move
implementations of all that into libbu? |
| 07:46.10 |
brlcad |
that aspect
of tcl is actually very nice, but for simple containment reasons,
I'm reverting a decision that was made about 15 years ago to allow
tcl to mix in with core code |
| 07:46.50 |
brlcad |
yeah, some
things we have implementations for, other things would need some
basic support added or alternatives found |
| 07:47.31 |
Ralith |
sounds fairly
straightforward. |
| 07:48.01 |
Ralith |
if
involved. |
| 07:48.30 |
brlcad |
it is, it's
just a lot of work |
| 07:48.48 |
brlcad |
probably
would end up refactoring somewhere around ... |
| 07:48.59 |
brlcad |
does a quick line count check for tcl'isms |
| 07:51.41 |
brlcad |
so at a
minimum, that is refactoring about 4000 lines of code |
| 07:54.10 |
Ralith |
refactor
linecounts can be misleading |
| 07:54.32 |
Ralith |
considering
how much can be done with careful application of regular
expressions. |
| 07:54.46 |
brlcad |
also includes
about 200 functions apparently .. so expand that out to all callers
and you're probably looking at 20k or so |
| 07:55.51 |
brlcad |
you could do
a few things with regexps, but it'll still be a little
tedious |
| 07:56.38 |
Ralith |
well,
sure. |
| 07:56.47 |
brlcad |
most of it
won't just be a function change though, it'll be a different
interface and there will be a hundred files that have to be
hand-edited because of all the different styles of use |
| 07:57.40 |
brlcad |
plus given
this hits the grand-daddy librt library, extra care would have to
be taken to verify changes don't break anything |
| 07:58.08 |
Ralith |
at least the
benchmark suite is helpful there. |
| 07:59.07 |
brlcad |
that's just a
minimum, but yeah |
| 08:01.47 |
Ralith |
there's also
plenty to be said for a very well-defined task. |
| 08:03.05 |
brlcad |
refactoring
tasks are often my favorite to work on |
| 08:03.38 |
brlcad |
they're well
defined, you usually have an exact work list that you can identify,
however long and tedious it may be |
| 08:04.11 |
brlcad |
i'll have the
files in my emacs buffer and can watch the % complete increase as I
make progress |
| 08:04.52 |
brlcad |
best part is
usually the "clean" feeling that usually results |
| 08:04.59 |
Ralith |
yeah. |
| 08:05.12 |
brlcad |
and
invariably, the code is then easier for others to understand and
extend with new functionality |
| 08:05.55 |
brlcad |
seems to
happen every time, gets cleaned up then someone takes it to the
next level |
| 08:11.39 |
Ralith |
reviews the gsoc paperwork |
| 08:27.17 |
Ralith |
I should be
able to get my applications in tomorrow. |
| 09:06.08 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-239-242.dclient.hispeed.ch) |
| 09:46.48 |
*** join/#brlcad andrecastelo_
(n=chatzill@189.71.13.123) |
| 10:04.58 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 12:09.57 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1312 10/wiki/Libpc: /* Objectives */ |
| 12:20.47 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 12:34.16 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1313 10/wiki/Libpc: /* Structure */ |
| 12:42.34 |
*** join/#brlcad madant
(n=madant@117.196.128.25) |
| 13:38.29 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 13:39.33 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-16e4f5c8f811b3db) |
| 14:36.43 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:49.05 |
``Erik |
<PROTECTED> |
| 15:12.00 |
*** join/#brlcad madant
(n=madant@117.196.145.133) |
| 15:41.27 |
*** join/#brlcad okias
(n=5864db99@bz.bzflag.bz) |
| 15:48.54 |
starseeker |
gapes in awe at the stellarium |
| 15:48.59 |
starseeker |
screenshot |
| 15:50.23 |
starseeker |
As to the
point about it being GPL - that will be true for ALL code (up until
QT4.5) using QT. It was a licensing requirement |
| 15:51.01 |
starseeker |
many will
probably stick with GPL, but it wouldn't hurt (if there is
interest) to talk to the authors and see if they would be willing
to re-license under LGPL now that they can |
| 15:51.43 |
starseeker |
if we find a
code base that is genuinely interesting in terms of wanting to drop
code straight into BRL-CAD, that's certainly a reasonable first
step |
| 15:52.06 |
starseeker |
if they say
no, not a big deal - we simply identify the techniques used to
achieve the effect and write our own solution |
| 15:53.22 |
starseeker |
I've never
seen QT used in that way before, but seeing that it can be makes my
interest in it rise by at least a factor of 2. |
| 16:00.25 |
``Erik |
nifty
app |
| 16:06.43 |
starseeker |
wooof.
apparently my system isn't up to handling that |
| 16:07.22 |
starseeker |
checks website for minimum hardware
requirements |
| 16:08.06 |
starseeker |
hmmmm |
| 16:08.31 |
starseeker |
my system is
much faster than that.... |
| 16:08.34 |
starseeker |
weird |
| 16:08.51 |
``Erik |
doing
something silly like running linux on it? :D |
| 16:09.17 |
starseeker |
uh, vice
versa actually |
| 16:09.30 |
``Erik |
meant the system |
| 16:09.37 |
starseeker |
heh |
| 16:09.46 |
``Erik |
english sucks
for context sensitive statements :D |
| 16:10.26 |
``Erik |
hopes it has a 'light pollution' slider
O.o |
| 16:13.02 |
starseeker |
yuck: frames
per second = 0.018 |
| 16:16.32 |
``Erik |
fires it up |
| 16:20.12 |
starseeker |
wonders if his nvidia support didn't get reset or
something... |
| 16:22.49 |
``Erik |
hm, a light
pollution selector |
| 16:22.54 |
``Erik |
acceptable, I
suppose |
| 16:24.16 |
starseeker |
yech. well,
bzflag does it too so it's not stellarium's fault |
| 16:24.24 |
starseeker |
starts checking nvidia driver versions |
| 16:24.28 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-8d422da770869a68) |
| 16:25.49 |
starseeker |
oh, cute,
it's using the software one. why???? |
| 16:25.53 |
starseeker |
alrightie... |
| 16:26.05 |
``Erik |
50fps here
:) |
| 16:26.11 |
``Erik |
that's a
pretty nifty app |
| 16:30.20 |
starseeker |
yep, there we
go |
| 16:30.38 |
starseeker |
in the 40
range here (after fixing acceleration) |
| 16:30.43 |
starseeker |
that is
cool |
| 16:31.03 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 16:32.29 |
``Erik |
I might stick
my head out tonight to look for saturn |
| 16:39.33 |
``Erik |
wonders why he has to put .cvsignore in his .cvsignore
O.o |
| 16:47.02 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 17:30.58 |
*** join/#brlcad madant
(n=madant@117.196.135.248) |
| 17:52.59 |
brlcad |
starseeker:
it's not a big deal either way, it's really not that hard to design
a custom interface (even with or without qt) |
| 17:53.41 |
brlcad |
we're talking
about days or weeks of time, not months, generally
speaking |
| 17:54.35 |
brlcad |
but yeah,
stellarium is one of several projects that have a really nice
custom interface (there are others) |
| 18:21.00 |
starseeker |
brlcad:
Indeed. That's what inclines me more towards QT in fact - since it
allows the custom part (and that wouldn't be a big deal, agreed) it
gives us for free native look and feel when/if we want it, which is
a lot harder and more maintainance headache |
| 18:36.10 |
brlcad |
not quite for
free, but it does make that option a little bit easier |
| 18:37.43 |
brlcad |
starseeker:
another really nice 'streamlined' but gorgeous interface to look at
is one of the apple opengl source code demo
applications |
| 18:40.25 |
brlcad |
that's
actually more in-line with what I would really like to see for an
initial pre-release interface with single main display manaer
context with some bindings, text overlays, crisp opengl with
various render modes available, and an on-demand command
prompt |
| 18:41.03 |
brlcad |
alas, that
demo itself is mac-specific |
| 18:45.52 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 18:50.34 |
starseeker |
brlcad: any
movies of it? |
| 19:18.55 |
brlcad |
starseeker:
hm, no |
| 19:37.52 |
*** join/#brlcad andrecastelo
(n=chatzill@189.71.13.123) |
| 19:40.29 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 20:02.09 |
brlcad |
contemplates stealing a couple of the bz buttons for menu
items |
| 21:04.37 |
*** join/#brlcad andax
(n=andax__@d213-102-41-93.cust.tele2.ch) |
| 21:55.17 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 22:28.08 |
Ralith |
brlcad: I
find myself still wondering if the benefits of relatively easy
native integration are worth the effort necessary to openglify it;
blender, for example, seems to get by fine with little to no native
integration. |
| 22:28.15 |
Ralith |
(re:
Qt) |
| 22:28.59 |
Ralith |
also, do you
ever sleep? :P |
| 22:29.59 |
andax |
Ralith:
opengl is not supported by all graphics cards. would there be
alternatives? |
| 22:30.19 |
Ralith |
it's
not? |
| 22:31.05 |
andax |
i remember i
had a Asus AMD64 board with onboard graphics card (Chrome) which
had no opengl |
| 22:31.35 |
Ralith |
I would be
very surprised if that's the case. |
| 22:31.54 |
Ralith |
besides,
anybody who expects to use a modern CAD app will need OpenGL one
way or another. |
| 22:31.58 |
Ralith |
it's the
industry standard |
| 22:35.13 |
Ralith |
that said, I
believe RBGui + Ogre will allow us to run on DirectX for no extra
effort |
| 22:36.24 |
andax |
it was a via
s3 unichrome pro graphics card. okay, it was a cheap office PC but
i remember i had vector graphics even on our first DOS-box with a
8086 CPU and wondered why i need that opengl support from hardware
side for practically all 3d applications |
| 22:37.47 |
*** join/#brlcad andax_
(n=andax__@d213-102-40-81.cust.tele2.ch) |
| 22:38.44 |
Ralith |
because
OpenGL is the standard. |
| 22:39.04 |
Ralith |
ancient
hardware doesn't always implement the standards; this is one of the
reasons it has been superseded. |
| 22:39.11 |
kanzure |
Hi all, does
anyone know of anything capable of converting a .sldprt file that I
have laying around here? |
| 22:40.06 |
Ralith |
kanzure: from
solidworks? I think you'll have to convert it to something more
standard using solidworks as an intermediary first. |
| 22:42.15 |
Ralith |
andax: you
have to admit, "there used to be some hardware that didn't support
it" is not a very strong argument. |
| 22:42.21 |
Ralith |
as it could
be applied to anything. |
| 22:42.46 |
kanzure |
Ralith: I
don't have solidworks. |
| 22:42.47 |
andax_ |
Ralith: yes,
but on the other hand we already had 3d graphics on this acient
hardware before anyone talked about opengl. i remember f-18 flight
simulation from microprose, for example :) |
| 22:42.56 |
Ralith |
kanzure: that
sounds like a problem. |
| 22:42.57 |
kanzure |
Blah. I told
these guys why they shouldn't use non-free software. |
| 22:43.09 |
kanzure |
throws a fit |
| 22:43.16 |
Ralith |
andax_:
usually not hardware accelerated, though. |
| 22:43.25 |
Ralith |
you can
always use mged. |
| 22:43.37 |
kanzure |
? |
| 22:43.43 |
kanzure |
to convert
the file? |
| 22:44.04 |
Ralith |
was talking
to andax_ |
| 22:44.06 |
kanzure |
the problem
is that I have a dot sldprt file, and a dot stl of the file, but
the dot stl is wrong- there are some triangle errors and so on that
'netgen' is able to find though not fix |
| 22:44.26 |
kanzure |
maybe I'll go
pray to the netgen folks for "Dr. STL" to start working |
| 22:45.08 |
kanzure |
context-
here's what I've been doing today- http://www.youtube.com/watch?v=sPY84NelFO4 |
| 22:49.30 |
Ralith |
kanzure:
meshlab maybe? |
| 22:53.08 |
kanzure |
haven't heard
of it |
| 22:53.25 |
Ralith |
it seems to
be good at cleaning up that sort of thing |
| 22:56.45 |
kanzure |
http://meshlab.sourceforge.net/wiki/index.php/Compiling |
| 22:56.49 |
kanzure |
wtf is wrong
with these people? :p |
| 22:58.06 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 22:58.07 |
Ralith |
? |
| 22:58.23 |
kanzure |
guess they've
never heard of dependency management and autogen |
| 22:58.54 |
Ralith |
where do you
get that idea? |
| 22:59.02 |
Ralith |
just because
they list the dependencies? |
| 22:59.42 |
kanzure |
because I
downloaded it and I have to manually compile all of these sub
packages or whatever |
| 23:00.01 |
Ralith |
or you could
just, you know, install them with your package manager. |
| 23:00.02 |
kanzure |
also, that's
a non-standard way of listing dependencies |
| 23:00.11 |
kanzure |
nope, they
are not available from the package manager |
| 23:00.12 |
Ralith |
there's a
standard way? |
| 23:00.15 |
kanzure |
I checked
before I started ranting :) |
| 23:00.18 |
Ralith |
that's your
distro's fault, then |
| 23:00.19 |
Ralith |
not
theirs |
| 23:00.31 |
kanzure |
well, most
distributions have standdard ways of managing
dependencies |
| 23:00.33 |
kanzure |
not
really |
| 23:00.37 |
kanzure |
they could
have just picked any standard format |
| 23:00.46 |
kanzure |
for instance,
on debian there is an 'alien' tool to convert between rpm and to
deb and such |
| 23:00.51 |
Ralith |
then they
would have been unable to support the others. |
| 23:00.56 |
Ralith |
and that's a
binary release, not source. |
| 23:01.18 |
kanzure |
recalls obtaining source packages through package
managers |
| 23:01.22 |
Ralith |
they're not
responsible for making their tools available in your repository of
source |
| 23:01.26 |
Ralith |
er |
| 23:01.27 |
Ralith |
of
choice |
| 23:01.38 |
Ralith |
that's up to
whoever manages the repository |
| 23:01.39 |
kanzure |
I guess they
could make it completely unavailable |
| 23:01.52 |
Ralith |
if you don't
like it, ask whoever manages the repository to include
it |
| 23:01.59 |
brlcad |
2yeah, same
here |
| 23:02.04 |
kanzure |
still, lack
of a make file.. |
| 23:02.17 |
Ralith |
nothing big
comes with makefiles |
| 23:02.22 |
Ralith |
qmake is a
build system that generates makefiles. |
| 23:02.29 |
Ralith |
just like
autotools, cmake, etc |
| 23:02.31 |
kanzure |
so is
autogen, like I mentioned :) |
| 23:02.32 |
kanzure |
yeah |
| 23:02.32 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
| 23:02.43 |
Ralith |
there's
nothing wrong with using something other than autotools |
| 23:02.54 |
kanzure |
there's
something wrong with using nothing. |
| 23:02.58 |
Ralith |
they're using
qmake |
| 23:03.01 |
Ralith |
qmake !=
nothing |
| 23:03.06 |
kanzure |
wtf? /me
checks the directory again |
| 23:03.30 |
Ralith |
brlcad: did
you get my earlier comment? |
| 23:03.32 |
kanzure |
how can you
tell? |
| 23:03.38 |
Ralith |
kanzure:
because it says so in the wiki page you linked. |
| 23:03.39 |
kanzure |
ah, there's a
make file at least |
| 23:05.33 |
kanzure |
okay,
nevermind, you're right. |
| 23:07.36 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 23:07.42 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
| 23:36.19 |
*** join/#brlcad starseeker_
(n=CY@c-68-33-217-173.hsd1.md.comcast.net) |
| 23:36.32 |
starseeker_ |
hmm - is bz
having trouble? |
| 23:36.58 |
starseeker_ |
can't ssh in |
| 23:48.01 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 00:09.24 |
*** join/#brlcad ``Erik_
(n=erik@ftp.brlcad.org) |
| 00:09.32 |
``Erik_ |
points and laughs at starseeker some |
| 00:09.38 |
``Erik_ |
points and laughs at starseeker some/part |
| 00:09.47 |
*** part/#brlcad ``Erik_
(n=erik@ftp.brlcad.org) |
| 00:09.58 |
``Erik |
woops,
accidently tapped the up arrow |
| 00:11.28 |
``Erik |
it does seem
to be dropping packets, though |
| 00:12.00 |
``Erik |
or, rather, a
router close to it is dropping packets :/ |
| 00:12.39 |
brlcad |
yeah, there's
some networking problem |
| 00:12.46 |
brlcad |
50-90% packet
loss |
| 00:12.47 |
``Erik |
with
"pnap" |
| 00:12.56 |
brlcad |
been going
since about 18:36 EDT |
| 00:13.26 |
brlcad |
seems to be a
main sago router, main website doesn't come up nor various routers
will ping without loss |
| 00:14.13 |
``Erik |
traceroute
indicates sago's uplink provider (pnap) is having issues between
their backbone and sagos drop |
| 00:18.14 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 00:26.14 |
Ralith |
brlcad:
ping? |
| 00:32.13 |
brlcad |
Ralith:
pong? |
| 00:37.13 |
Ralith |
there we
are. |
| 00:37.47 |
Ralith |
was '16:02:36
< brlcad> yeah, same here' a reply to my comment on
Qt? |
| 00:38.59 |
brlcad |
is painfully dealing with the network woes at the moment,
apologies on delay |
| 00:39.10 |
Ralith |
no
worries |
| 00:40.18 |
brlcad |
the "yeah,
same here" comment was due to the networking problems.. went to the
wrong channel |
| 00:40.23 |
Ralith |
ahh. |
| 00:40.46 |
brlcad |
I type and
then it shows up anywhere from 1 to 60 seconds later |
| 00:41.02 |
Ralith |
that would be
very frustrating. |
| 00:41.15 |
Ralith |
so, bad time
to discuss UI toolkits further I guess :P |
| 00:43.36 |
brlcad |
is reading the backlog |
| 00:44.15 |
brlcad |
ah, I see now
-- your comment |
| 00:44.35 |
brlcad |
I wouldn't
pick qt for native integration capability, just a side comment I
think |
| 00:44.55 |
brlcad |
it's more the
other things (widget-wise) that qt or rbgui or whatever
provide |
| 00:45.13 |
brlcad |
and no, I try
not to sleep |
| 00:45.18 |
brlcad |
a piece of
you dies every time you sleep! |
| 00:45.20 |
Ralith |
lol |
| 00:46.10 |
Ralith |
looks over Qt's widget offerings |
| 00:46.11 |
brlcad |
kanzure, you
see the gsoc list of converters that folks could work on?
:) |
| 00:46.22 |
brlcad |
I suspect
that will answer your question about sldprt files |
| 00:46.43 |
kanzure |
heh |
| 00:46.50 |
kanzure |
that did turn
up in my search results a few hours ago actually |
| 00:46.53 |
kanzure |
(the wiki
page in particular) |
| 00:47.06 |
brlcad |
we show up on
a lot of search results.. |
| 00:47.35 |
brlcad |
I often go
hunting for something only to find a brl-cad page in the top list
of results (or the top result) ... dammit! ;) |
| 00:47.39 |
brlcad |
if we had it,
I wouldn't be loking :) |
| 00:48.03 |
brlcad |
we're just
often apparently a main source for even discussing some
matters |
| 00:48.16 |
Ralith |
BRL-CAD is
extremely unique |
| 00:48.19 |
Ralith |
that has that
result. |
| 00:49.12 |
brlcad |
actually I
think it happened just yesterday when we were talking about guis
and I went to search for that screenshot I was looking
for |
| 00:49.35 |
brlcad |
top result
was that wiki discussion page about gui options |
| 00:50.05 |
brlcad |
ah, the rbgui
avi |
| 00:50.38 |
brlcad |
nay a link on
rightbraingames, but our wiki sure came up |
| 00:50.56 |
brlcad |
dmaybeprobably just the way I phrased
it |
| 00:51.19 |
Ralith |
helps that
rightbraingames has barely a web presence |
| 00:51.29 |
Ralith |
and that you
wrote most of the relevant wiki pages. |
| 00:52.18 |
``Erik |
heh, I was
looking for something about some archaic computer a few days ago
and ended up at http://ftp.brl.mil
O.o |
| 00:53.23 |
Ralith |
hmm, Qt's
docs look really good. |
| 01:00.28 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 01:11.42 |
Ralith |
in fact it
looks pretty fun to dev for |
| 01:34.51 |
``Erik |
the before,
in the long long ago, I used qt due to the awesome docs and
tutorials, but ended up switching to gtk+ because of the repaint on
resize issue (as well as the painful compile times of c++ on a
120mhz cpu with 48m ram) |
| 01:34.51 |
``Erik |
the before
time, rather |
| 01:34.53 |
Ralith |
that's quite
the before time. |
| 01:35.07 |
Ralith |
Qt still has
painful compile times, but that shouldn't be a real
issue |
| 01:35.22 |
Ralith |
since even
devs will need to compile it at most once, barring
upgrades |
| 01:41.01 |
``Erik |
um, I meant
compiling the programs that use qt :) |
| 01:41.09 |
Ralith |
ah. |
| 01:41.18 |
Ralith |
hopefully
that isn't too bad. |
| 01:41.27 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 01:42.26 |
``Erik |
hm, I'm under
the impression that the BRL-CAD compile is disproportionately
dominated by OpenNURBS (the only significant chunk of c++, iirc)
:/ |
| 01:43.06 |
Ralith |
the BRL-CAD
compile isn't that bad. |
| 01:43.25 |
``Erik |
I know on
this machine I'm running a portmanager on right now, c++ ports
grind the machine down to a halt, and beat on swap a lot
:( |
| 01:43.26 |
Ralith |
g3d should be
a significantly smaller codebase, depiste C++ness |
| 01:43.40 |
``Erik |
gtk+ compiles
faster than cmake heh :( |
| 01:43.46 |
Ralith |
:P |
| 01:44.11 |
``Erik |
pheer my
650mhz p3 with 128m ram! PHEER IT! |
| 01:44.36 |
Ralith |
lol |
| 02:04.00 |
Ralith |
brlcad:
discovery! Qt appears to ship with support for drawing to
OpenGL! |
| 02:04.01 |
Ralith |
:D |
| 02:07.32 |
Ralith |
brb |
| 02:28.15 |
Ralith |
returns |
| 02:42.27 |
brlcad |
``Erik:
openNURBS did increase the compile time by approximately 50-150%
depending on plat, compiler, and memory |
| 02:43.28 |
brlcad |
and increased
overall code size by about 20% with about 200k of
sources |
| 02:43.47 |
brlcad |
c++ just
compiles a whole lot slower than c |
| 02:44.48 |
brlcad |
Ralith: I
know -- it wouldn't be very useful or interesting toolkit without
an opengl widget :) |
| 02:44.54 |
Ralith |
nonono |
| 02:45.05 |
Ralith |
drawing to
OpenGL a la stellarium |
| 02:45.13 |
Ralith |
that's not a
custom hackjob there |
| 02:45.21 |
Ralith |
see:
http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ |
| 02:45.37 |
Ralith |
I grabbed and
build the code; runs great, looks simple to duplicate |
| 02:46.27 |
brlcad |
ah, yeah,
that too |
| 02:48.30 |
brlcad |
that's not
quite what stellarium is doing iirc, but akin to Glitz |
| 02:49.24 |
Ralith |
what's
stellarium doing, then? |
| 02:49.32 |
Ralith |
this seems to
be what we need. |
| 02:50.41 |
brlcad |
iirc, they're
inheriting off of the various qt widget classes and overriding the
drawing routine |
| 02:51.09 |
brlcad |
instead just
drawing an alpha-channeled image for many of those
items |
| 02:52.16 |
brlcad |
the image
drawing is still done through qt, though, so it has the option to
use ogl acceleration to blit the image as texture quads on the
backend |
| 02:52.26 |
brlcad |
*textured |
| 02:53.02 |
Ralith |
in the
example I linked, if I'm reading it correctly, it's basically just
saying "Here's my GUI; render it with OpenGL, please." |
| 02:53.12 |
Ralith |
and then
overriding the background to draw the 3D stuff through normal
OpenGL calls. |
| 02:54.20 |
Ralith |
of course,
there'd be a bit more work in our case since there's the need to
hook everything up to Ogre instead of pure OpenGL |
| 02:54.52 |
brlcad |
actually I
think it'll work easier the other way around |
| 02:55.04 |
Ralith |
other way
around? |
| 02:55.27 |
brlcad |
setting up
the window/view/context(s) with qt and then initializing ogre at a
lower level to use that context |
| 02:55.52 |
Ralith |
ah, you're
probably right |
| 02:56.20 |
brlcad |
instead of
starting up with ogre and finding a way to initialize qt to use
it |
| 02:56.42 |
Ralith |
I think
there's even some example code of putting Ogre inside Qt that could
be leveraged |
| 02:56.52 |
Ralith |
since it's
basically the same mechanisms |
| 02:56.57 |
brlcad |
yep |
| 02:58.37 |
Ralith |
sounds like a
plan. |
| 03:03.09 |
brlcad |
"The network
issue has been resolved. There was a major DDoS attack that
flooded Sago's bandwidth. The IPs that were being attacked have
been null routed which stopped the DDoS attack." |
| 03:03.23 |
Ralith |
yay! |
| 03:31.25 |
Ralith |
brlcad: where
does submitting a formal gsoc application fit in to the
participation checklist? |
| 03:32.23 |
Ralith |
it's
suggested elsewhere that commit access should be obtained
beforehand, but that's the last item on said list, which also
includes references to mentor discussions and design docs and such,
which seems inconsistent. |
| 03:35.54 |
Ralith |
to put it
more simply, I'm wondering what I should get done before sending in
my app; for example, should I update the OpenGL GUI page with
documentation of what we've discussed? |
| 03:35.55 |
brlcad |
Ralith: the
participation checklist is for those already applied and selected,
sort of a to-do list after the fact |
| 03:36.00 |
Ralith |
ahh. |
| 03:36.24 |
brlcad |
the getting
started section at http://brlcad.org/wiki/Google_Summer_of_Code
is the first steps |
| 03:36.39 |
Ralith |
because it
contains many items that are elsewhere emphasized as things to do
beforehand. |
| 03:36.46 |
brlcad |
yeah, it
overlaps |
| 03:39.22 |
brlcad |
independent
lists each with items not on the other .. should probably combine
them into one, one list with two sections perhaps |
| 03:40.19 |
brlcad |
e.g., first
one says to interact on #brlcad , the other is specific to
introduce yourself (and your project) |
| 03:40.23 |
brlcad |
if you hadn't
already |
| 03:40.46 |
Ralith |
kk |
| 04:12.02 |
*** join/#brlcad copenhague
(n=copenhag@d206-75-233-96.abhsia.telus.net) |
| 04:21.53 |
Ralith |
brlcad: is
scripting language support a responsibility of the editor, or
something to be provided by an external library? |
| 05:44.50 |
starseeker |
Arrrgh - I
wish I wasn't broke...
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX:IT&item=250395300975 |
| 05:46.39 |
starseeker |
oh well, no
storage anyway |
| 05:49.23 |
Ralith |
now that
would be cool to model. |
| 05:49.54 |
Ralith |
we should
build up a bunch of neat blueprints like that and suggest people
model them for future SoCs :D |
| 06:37.35 |
*** join/#brlcad madant
(n=madant@117.196.144.31) |
| 06:49.25 |
*** join/#brlcad madant
(n=d@117.196.144.31) |
| 07:24.33 |
yukonbob |
hello,
cadheads (from Las Vegas!) |
| 07:25.45 |
Ralith |
hello,
yukonbobhead! |
| 07:25.50 |
Ralith |
what're you
up to down there? |
| 07:28.45 |
yukonbob |
Ralith:
hi |
| 07:29.49 |
yukonbob |
Ralith:
visiting wife + kid... I'm working in Vancouver, she's working in
Alberta (with baby), and believe it or not, this was
convenient. |
| 07:30.18 |
yukonbob |
(she' was
presenting paper earlier this week in Vegas; she's a cultural
anthropologist) |
| 07:30.25 |
Ralith |
that doesn't
sound like much fun :/ |
| 07:30.34 |
Ralith |
(the
vancouver/alberta thing, not the paper thing) |
| 07:30.36 |
yukonbob |
Ralith: no
fun at all... |
| 07:30.48 |
yukonbob |
Ralith:
looking forward to the end of this situation |
| 08:44.25 |
Ralith |
brlcad: you
there? |
| 08:44.29 |
brlcad |
yep |
| 08:44.59 |
Ralith |
how does
'stubbing' functionality by backing it with libged
sound? |
| 08:45.23 |
Ralith |
will the
interfaces be similar enough for it to be easily converted to the
geometry service? |
| 08:45.50 |
brlcad |
scripting
support is going to be handled by the front-end, but probably a
plugin facility in the geometry service's domain |
| 08:46.11 |
brlcad |
or a layer
in-between |
| 08:46.49 |
brlcad |
that sounds
good -- that's sort of what mafm's work to date did |
| 08:47.09 |
Ralith |
I wasn't
aware that mafm's work to date did much talking to BRL-CAD at
all. |
| 08:47.59 |
Ralith |
re:
scripting, that leaves me a little unclear |
| 08:48.25 |
Ralith |
g3d is
expected to implement scripting in the short term, but eventually
it will be separated out? |
| 08:49.32 |
brlcad |
yeah, it
already uses libged to open a .g geometry file, display geometry,
undisplay, etc |
| 08:50.49 |
Ralith |
ah. |
| 08:50.51 |
brlcad |
basically,
most things will have to be handled by the application in the short
term and/or worked with the other bigger projects as they come to
fruition |
| 08:51.08 |
Ralith |
kk |
| 08:51.29 |
Ralith |
sounds like a
standalone scripting system would make yet another good soc
project |
| 08:51.34 |
Ralith |
well |
| 08:51.36 |
Ralith |
maybe
not |
| 08:51.43 |
Ralith |
as it'd have
a pretty ill defined interface for the time being, I
think |
| 08:52.15 |
brlcad |
example, when
this is done, an application wouldn't need (or want) to have to
maintain ged structures -- that would happen by the service
automatically |
| 08:53.08 |
brlcad |
the goal is
for the client to be a thin-client, minimum functionality with most
of the logic happening on an application-backend through a
plugin-architecture |
| 08:53.32 |
brlcad |
notes that this is better explained with pictures, but maybe
you get the gist |
| 08:54.10 |
Ralith |
I think I do,
especially since it's a very clean way to do things. |
| 08:54.12 |
Ralith |
very
unixy. |
| 08:54.32 |
Ralith |
which is
something increasingly (and worryingly) rare among large-scale
projects. |
| 08:54.50 |
brlcad |
that's why,
though, I was mentioning yesterday that the goal shouldn't be so
much to focus on how it interacts with geometry, libged, librt,
geometry engine, geometry service, et al, but to work on the gui
itself and getting that framework set up (polished, clean look and
feel, etc) |
| 08:55.00 |
Ralith |
yeah |
| 08:55.02 |
Ralith |
that makes
perfect sense |
| 08:55.16 |
Ralith |
no point
spending devtime on something that'll be deprecated in short order,
and was never really good practice to start with. |
| 08:55.51 |
brlcad |
a little less
exciting perhaps, but it's the only known step without -- as you
note -- working on a backend feature like a scripting module in the
geometry service |
| 08:55.59 |
brlcad |
which would
be cool, but yeah -- another project in itself |
| 08:56.38 |
brlcad |
right, the
measures g3d already goes to for opening a .g is arguably already
"too much", but it is nice to at least be able to see some geometry
:) |
| 08:56.50 |
Ralith |
I dunno,
there's a *lot* of awesome-factor in building a script-independent
scripting system as you've described. |
| 08:56.52 |
brlcad |
and libged
does make that really easy |
| 08:57.50 |
Ralith |
I figure
having enough of a backend to enable meaningful tests of usability
is important. |
| 08:58.06 |
Ralith |
it's hard to
study how practical something is to complete a task if you can't
actually complete the task. |
| 08:59.07 |
Ralith |
by the way,
is the BREP stuff still not very far along? I'm wondering how far
we are from easy tesselation of arbitrary geometry. |
| 08:59.22 |
Ralith |
'cuz that
could ad major shiny-points to a demo. |
| 08:59.32 |
brlcad |
there has
been some progress, but nothing you could rely on for
gsoc |
| 09:00.17 |
brlcad |
still, even
if it could do wireframe, or shaded display of unevaluated CSG,
that much is all doable now |
| 09:00.41 |
Ralith |
good
point |
| 09:00.58 |
Ralith |
unevaluated
is plenty for some nice looking demos. |
| 09:01.26 |
brlcad |
and for mesh
models, they'll look the same |
| 09:01.36 |
brlcad |
no
booleans |
| 09:01.50 |
Ralith |
well, mesh
models isn't really what we're here for |
| 09:02.07 |
Ralith |
though that
would work well for pretty pictures. |
| 09:03.13 |
brlcad |
yep |
| 09:07.11 |
brlcad |
as for the
scripting separation, if you think of the application having a
front-end and a back-end, where the front is the gui (or the V in
an MVC separation) and the back contains modular functionality in
plugins |
| 09:07.51 |
brlcad |
one of the
back modules is a command shell, that effectively provides a
terminal service |
| 09:08.48 |
brlcad |
within that
terminal service, you're basically running a command shell (e.g.,
tclsh, bash, python that (for now) hooks through those environments
to libged) |
| 09:09.07 |
*** join/#brlcad madant
(n=d@117.196.141.132) |
| 09:10.09 |
brlcad |
that command
layer itself would be a nice contained project in itself because
it's easy enough to whip up an application testing harness that
provides a command prompt and lets you switch between different
scripting languages on the fly |
| 09:10.37 |
Ralith |
hm |
| 09:10.52 |
Ralith |
so [GUI
actions trigger] commands trigger editing actions? |
| 09:11.11 |
brlcad |
explain? |
| 09:12.00 |
Ralith |
I'm having
trouble seeing how the command line could be a plugin without
duplication of the editing bindings between the GUI and the
scripting system. |
| 09:12.15 |
Ralith |
unless the
GUI is a wrapper of the command line |
| 09:12.48 |
Ralith |
which could
work, assuming multiple shells can be used, and has some neat side
effects like being able to easily show a command for every gui
action. |
| 09:13.25 |
brlcad |
the latter --
every action in the system can be defined as a series of scriptable
non-modal command actions |
| 09:13.44 |
brlcad |
that's
actually how the geometry service is presently
organized |
| 09:13.59 |
Ralith |
okay |
| 09:14.10 |
Ralith |
so multiple
shells can be used in parallel then? |
| 09:14.14 |
Ralith |
could be
confusing. |
| 09:14.15 |
brlcad |
absolutely |
| 09:14.33 |
brlcad |
that'd be up
to the app to limit is possible |
| 09:14.52 |
Ralith |
oo, I
know |
| 09:14.54 |
brlcad |
present an
actual terminal window, for example |
| 09:14.56 |
Ralith |
command
prompt. |
| 09:15.02 |
Ralith |
shell-specific prompt. |
| 09:15.06 |
brlcad |
right |
| 09:15.08 |
Ralith |
that would
disambiguate nicely |
| 09:15.17 |
Ralith |
also minimize
confusion when using someone else's workstation |
| 09:15.32 |
*** join/#brlcad madant_
(n=d@117.196.141.132) |
| 09:15.33 |
brlcad |
that's what I
was saying about running a command shell (within a terminal
service) |
| 09:15.51 |
Ralith |
hm? |
| 09:15.56 |
brlcad |
terminal is
basically a given console, in that console, you'd only be running
one shell at a time |
| 09:16.10 |
brlcad |
but could
certainly switch shells if you wanted |
| 09:16.23 |
brlcad |
just like a
unix command terminal/console |
| 09:16.42 |
Ralith |
I was
imagining the situation in which the g3d user is running an
arbitrary shell |
| 09:16.49 |
Ralith |
the GUI would
have to use its own console |
| 09:17.11 |
Ralith |
which
prevents awesome stuff like sharing command history between GUI
actions and manually entered commands |
| 09:17.17 |
brlcad |
wouldn't
exactly be arbitrary as we'd have to make it work for each shell we
want to support |
| 09:17.31 |
Ralith |
arbitrary in
the sense that it might not be the one the GUI's using. |
| 09:17.39 |
brlcad |
they would
have a shared command history, though |
| 09:17.46 |
Ralith |
how do you do
that across different shells? |
| 09:17.52 |
brlcad |
that's where
everything is eventually going to filter through the geometry
service |
| 09:17.56 |
Ralith |
different
syntaxes. |
| 09:18.08 |
Ralith |
you'd have to
have some sort of action -> shell command convertor |
| 09:18.14 |
brlcad |
that's
actually where commands will be handled -- just right now, that's
in libged |
| 09:18.56 |
Ralith |
and you'd
need to go from GUI shell -> abstract action -> user shell
just to generate the history entry. |
| 09:19.04 |
Ralith |
or am I
misunderstanding? |
| 09:19.43 |
brlcad |
more like
"gui action -> gs command(s) -> ged command(s)" and "terminal
command -> gs command -> ged command" |
| 09:20.15 |
Ralith |
ah. |
| 09:20.23 |
Ralith |
I was
referring to command history in the shell context. |
| 09:20.41 |
Ralith |
this would be
a valuable learning tool, because it'd show you how to do
everything you depend on the GUI for by hand. |
| 09:21.16 |
Ralith |
not critical
to a functional interface, sure, but I bet it would drastically
increase the use of the more advanced capabilities granted by
scripting. |
| 09:21.30 |
brlcad |
ah yeah ..
making the terminal show history for gui actions would just be
confusing I think -- I see that happening as more of a command
transcript |
| 09:22.03 |
brlcad |
where you
could ask the gs for a history transcript, and you'll see combined
gui and/or console commands |
| 09:22.20 |
Ralith |
yeah, I
follow |
| 09:22.44 |
Ralith |
I just really
like the idea of showing users how to do things a more efficient
way. |
| 09:23.09 |
brlcad |
most of the
gui actions are asynchronous, most of the console are synchronous
(at least by default) |
| 09:23.11 |
Ralith |
there won't
be nearly as much use of the command line if you have to dig into
documentation to use it. |
| 09:24.02 |
Ralith |
but I suppose
my point this whole time is that a good design makes that
impractical. |
| 09:24.28 |
brlcad |
makes what
impractical? |
| 09:25.24 |
Ralith |
mapping GUI
actions onto shell commands |
| 09:25.47 |
brlcad |
ah,
yeah |
| 09:26.06 |
brlcad |
I mean you
could -- gs commands will map pretty much 1-1 with shell
commands |
| 09:26.32 |
Ralith |
but would it
be practical to go from gs command to shell command? |
| 09:26.33 |
brlcad |
that's why
you'll be able to pull up an editing history regardless of actions
being performed through the gui or via command-line |
| 09:26.43 |
Ralith |
and beyond
that, there's higher level stuff that could be mapped but would do
so really badly |
| 09:26.49 |
Ralith |
e.g. complex
chains of actions |
| 09:27.10 |
Ralith |
things that
would take significant amounts of script to produce |
| 09:27.14 |
brlcad |
yeah -- many
gui actions will translate to multiple commands, even a single
"click" |
| 09:27.58 |
brlcad |
which could
later be abstracted out into a single meta-command possibly, but
there will always be something even more "meta"
possible |
| 09:28.04 |
Ralith |
yup. |
| 09:28.15 |
Ralith |
which, I
suppose, dooms the whole idea, irrespective of implementation
details. |
| 09:29.51 |
brlcad |
if you recall
the command prompt in the IOE demo, that's basically a single
command that would feed/translate directly to the gs as a gs
command and map 1-1 with a ged command |
| 09:30.10 |
brlcad |
and be an
"action" that is scripting agnostic, raw command |
| 09:30.14 |
Ralith |
yeah |
| 09:30.33 |
Ralith |
but a proper
implementation should allow full expressions, be they oneliners, in
that context imo |
| 09:30.45 |
Ralith |
which
includes things like loops which map onto many gs
commands. |
| 09:31.08 |
brlcad |
not for the
on-demand command prompt -- there is no interpreter |
| 09:31.16 |
Ralith |
oh? |
| 09:31.29 |
Ralith |
are you sure
that's a good idea? |
| 09:31.56 |
Ralith |
you'd need to
define a human-readable (and succinct enough to be enterable)
syntax for gs commands |
| 09:32.03 |
Ralith |
and it'd
detract from the power significantly. |
| 09:32.19 |
brlcad |
there is
*still* a command console |
| 09:32.31 |
brlcad |
i'm referring
to the on-demand command prompt |
| 09:32.38 |
brlcad |
which is
separate from the console prompt |
| 09:32.53 |
Ralith |
I had thought
that would just be a convenient method of accessing it. |
| 09:34.00 |
brlcad |
it's possible
that the on-demand prompt could allow some form of one-liner
scripting, but would not want to complicate it's simple
expressivity for things that the command console will handle
already |
| 09:35.07 |
Ralith |
the command
console can handle simple 1:1 commands too, though |
| 09:35.19 |
Ralith |
so I don't
see how such a shell is out of place in the on-demand
prompt. |
| 09:35.29 |
Ralith |
or,
wait |
| 09:35.33 |
brlcad |
yes it's 1-1,
but it does it within a shell |
| 09:35.38 |
Ralith |
the prompt is
focused on UI actions? |
| 09:35.41 |
*** join/#brlcad madant
(n=d@117.196.141.132) |
| 09:35.44 |
brlcad |
and you can
switch shells |
| 09:35.50 |
Ralith |
rather than
the shell being focused on editing actions? |
| 09:36.09 |
brlcad |
not sure I
understand your question |
| 09:36.36 |
Ralith |
e.g. you'd
use the prompt to save a file to local disk, and the shell to
create a region. |
| 09:37.29 |
Ralith |
in the IOE
demo the shell was for performing environment and overarching UI
related actions, rather than directly controlling the
programs. |
| 09:37.40 |
Ralith |
er |
| 09:37.43 |
Ralith |
the on demand
prompt |
| 09:40.34 |
brlcad |
there was no
shell in the IEO demo, just that on-demand command prompt -- but
yeah, that on-demand could potentially allow environment/ui actions
or lower-level commands |
| 09:40.59 |
brlcad |
those can
happen on a terminal console as well, though, as it's all going
through the same system |
| 09:41.24 |
brlcad |
I don't see
much of the gui being inaccessible from the command
prompt |
| 09:42.18 |
Ralith |
then I'm kind
of confused as to why we need to introduce an entirely new syntax
to what could just be another interface to the shell. |
| 09:42.32 |
brlcad |
be able to be
in either and affect the other, or at least introspect the other as
the "model" is still being managed by the backend gs state and both
the command prompt and gui just reflect that state |
| 09:42.52 |
brlcad |
what OS do
you use? |
| 09:42.59 |
Ralith |
*nixes in
general |
| 09:43.02 |
Ralith |
Linux at the
moment |
| 09:43.15 |
Ralith |
though I do
find myself at windows often. |
| 09:44.40 |
brlcad |
that
on-demand prompt is inspired by and modeled after application
launchers |
| 09:45.08 |
brlcad |
akin to
"quicksilver" on a mac if you've ever used that |
| 09:45.10 |
Ralith |
my ideal
application launcher is a quick-loading one-line
terminal. |
| 09:45.14 |
Ralith |
I
haven't. |
| 09:45.49 |
brlcad |
I believe
"Launchy" is sort of similar (just not nearly as awesome as
quicksilver) for linux and windows |
| 09:45.58 |
Ralith |
haven't used
that either >_> |
| 09:45.58 |
brlcad |
http://en.wikipedia.org/wiki/Quicksilver_(software) |
| 09:46.02 |
Ralith |
I keep my UI
simple. |
| 09:46.12 |
brlcad |
ahh, here
http://en.wikipedia.org/wiki/Comparison_of_application_launchers |
| 09:46.13 |
Ralith |
running
xmonad, a minimalist tiling window manager, at the
moment. |
| 09:46.18 |
brlcad |
nods |
| 09:46.36 |
Ralith |
window
management in the IOE reminded me of it. |
| 09:47.35 |
brlcad |
basically
it's a way to "DO THIS" on-demand when you don't have an
interactive command prompt available, accessed via a quick hot-key
like alt+space |
| 09:47.43 |
Ralith |
I
follow |
| 09:47.54 |
Ralith |
but I don't
see how that's not offered by a shell. |
| 09:48.04 |
brlcad |
it is offered
by the shell |
| 09:48.20 |
brlcad |
but the shell
is something persistent or something you launch, stays around, uses
screen real-estate, etc |
| 09:48.24 |
Ralith |
then why go
to the effort of specifying an entirely new syntax? |
| 09:48.34 |
Ralith |
shell in the
sense of the actual interpreter |
| 09:48.45 |
Ralith |
not the
terminal that's displayed |
| 09:49.12 |
Ralith |
it seems like
this would add a significant amount to what you'd have to learn for
relatively little benefit. |
| 09:49.31 |
Ralith |
which
infringes on the critical usability factor. |
| 09:49.48 |
Ralith |
since it is,
in effect, an entirely new 'language' |
| 09:49.54 |
brlcad |
could just be
a terminology mismatch, shell to me means 'command shell' in a
traditional sense like bash/tcsh/tclsh, those are shells -- entire
interpreter environments |
| 09:50.13 |
Ralith |
that's what I
mean |
| 09:50.27 |
Ralith |
the entry box
wouldn't be persistent, but the interpreter can be. |
| 09:50.37 |
brlcad |
there is no
new language, it basically is the common subset of all shell
interpreters |
| 09:50.40 |
Ralith |
which is
nice, because it allows for continuous state |
| 09:50.50 |
Ralith |
how do you do
that when they have such varied syntax? |
| 09:50.52 |
brlcad |
the
interpreters without their scripting harness -- the command
portion |
| 09:51.28 |
Ralith |
you'd have to
limit supported interpreters to those with identical function call
syntax, or something. |
| 09:51.38 |
Ralith |
I can't see
that working at all; I must be missing something |
| 09:52.12 |
brlcad |
not sure what
syntax you're referring to that would be different.. there is no
syntax to learn other than the commands themselves, which are
mostly verb+noun or noun+verb |
| 09:52.36 |
Ralith |
not so in
python, afaik |
| 09:52.39 |
Ralith |
that's much
more C like. |
| 09:53.04 |
Ralith |
it's largely
a coincidence that the popular shells that consist of most of your
examples tend to offer similar command syntax. |
| 09:53.29 |
Ralith |
and even for
them things like setting variables differ, although that may be
outside of the scope you describe. |
| 09:53.38 |
brlcad |
it's really
hard to explain given you've not used any of those application
launchers :) |
| 09:53.47 |
Ralith |
these
application launchers all use their own language. |
| 09:53.51 |
Ralith |
it's a very
simple one, yes |
| 09:53.56 |
Ralith |
but it's
still something you have to learn |
| 09:53.56 |
brlcad |
yes, there is
no state, no variables, no scripting. just a "do this" |
| 09:54.05 |
Ralith |
so it's
another language. |
| 09:54.18 |
brlcad |
not
really |
| 09:54.32 |
Ralith |
and thus
another barrier to optimal usability--although I suppose that's
limited, since the actions would be replicated in the other two
environments.. |
| 09:55.06 |
Ralith |
well, I
imagine shell syntax for something is usually going to be very
different from prompt syntax for it. |
| 09:55.17 |
Ralith |
just as the
GUI way of doing something would be. |
| 09:56.01 |
Ralith |
it may be a
very simple language, and even a very intuitive one, but it's still
something clearly differentiated from a shell. |
| 09:56.34 |
brlcad |
back to the
original example where a single gui action would translate to one
or more 'gs commands', the on-demand prompt is basically a 1-1 to a
gs command as well |
| 09:56.35 |
Ralith |
but I'm
realising now that that's not such a disadvantage, given that its
use is entirely optional. |
| 09:57.04 |
Ralith |
and that new
users won't be depending on a GUI element they've never encountered
before. |
| 09:57.38 |
Ralith |
you've still
got to define the language, simple as it may be. |
| 09:57.52 |
brlcad |
I still don't
get where you're getting language from |
| 09:58.01 |
brlcad |
there is no
logic/syntax other than "command + args" |
| 09:58.10 |
brlcad |
there are no
variables, no conditionals |
| 09:58.17 |
brlcad |
to logical
constructs |
| 09:58.20 |
brlcad |
s/to/no/ |
| 09:58.26 |
Ralith |
okay. |
| 09:58.35 |
Ralith |
you've still
got to define a set of these commands. |
| 09:58.40 |
brlcad |
"draw
object" |
| 09:58.49 |
Ralith |
I guess that
wouldn't be that much more work than binding a new scripting
language at that point, though |
| 09:58.51 |
brlcad |
absolutely,
that we're doing implicitly with libged |
| 09:58.57 |
Ralith |
huh? |
| 09:59.12 |
brlcad |
that defines
a set of understood geometry editing commands in a "command+args"
structure |
| 09:59.21 |
Ralith |
ah. |
| 09:59.34 |
Ralith |
and it'd be a
simple matter to map literal commands onto that. |
| 09:59.49 |
brlcad |
example
literal command? |
| 09:59.58 |
Ralith |
draw
object |
| 10:00.07 |
Ralith |
(as opposed
to the actual ged library call) |
| 10:01.04 |
brlcad |
that might be
the missing link -- ged library calls are intentionally a
collection of commands as functions |
| 10:01.20 |
Ralith |
which is why
it's a simple matter. |
| 10:01.24 |
brlcad |
pretty every
mged command now corresponds to a libged function |
| 10:01.28 |
brlcad |
a single
function |
| 10:01.37 |
brlcad |
ged_[command]() |
| 10:02.32 |
brlcad |
so you say
"draw object", that basically calls ged_draw(argc=2, argv={"draw",
"object"}); |
| 10:02.41 |
brlcad |
plus a ged
state structure |
| 10:03.07 |
brlcad |
so it knows
in what context to invoke that command |
| 10:04.03 |
brlcad |
so we are
defining commands, sets of commands, and arguments, but the intent
is that those remain modular modeless actions |
| 10:04.29 |
brlcad |
a gui action
may translate to 100 ged_*() commands through the geometry
service |
| 10:05.20 |
brlcad |
the command
terminal will allow scripting in an environment, provide variables
and logical structures, and basically map commands directly to
their ged_* counterparts |
| 10:05.38 |
Ralith |
or as closely
as permitted by the shell. |
| 10:05.40 |
brlcad |
an on-demand
command basically maps directly to one ged_* command |
| 10:06.01 |
brlcad |
example? |
| 10:07.04 |
brlcad |
all command
shells I know of boil down (or can be boiled down) fundamentally to
command+args |
| 10:08.11 |
Ralith |
well, python
isn't a command shell in the traditional sense, for
example |
| 10:09.14 |
brlcad |
especially
all interactive prompts like bash/tclsh but even non-interactives
like python/lisp/perl translate |
| 10:10.18 |
Ralith |
I mean, the
syntax will differ between calling a python function and executing
a bash command. |
| 10:11.16 |
brlcad |
oh yeah,
syntax will definitely differ -- that "translation" is what I was
referring to earlier about having to take efforts to hook in a new
scripting interface |
| 10:13.24 |
brlcad |
for an
object-based language like python, a really simple way to avoid
most of the issues is to make a "ged object" that then becomes your
object that takes "command+args" parameters |
| 10:14.00 |
brlcad |
at least one
of several ways it could be handled |
| 10:14.56 |
brlcad |
there the
difference is mostly noun+verb's instead of usual verb+noun's style
you find elsewhere |
| 10:15.25 |
brlcad |
that's where
something like swig should hopefully make life a little easier
since we just define the functions/commands and then swig does the
mappings to various languages for us |
| 10:15.39 |
Ralith |
yeah. |
| 10:18.37 |
brlcad |
i guess the
original point about the on-demand command prompt, though, was
simply that it would effectively be like the mged command prompt
without the tcl scripting capability -- syntax is identical and
basically becomes a way to run a single command very quickly (and
transiently) |
| 10:19.16 |
brlcad |
not strictly
necessary, more of a power-user function at that, but much less
intrusive than a terminal (and generally *much* faster/efficient
too) |
| 10:23.26 |
Ralith |
yeah, I
follow |
| 10:23.26 |
Ralith |
makes sense
now. |
| 10:23.50 |
Ralith |
It might be
worth considering offering a similar functionality that pipes into
the shell, too, though |
| 10:24.06 |
Ralith |
simply
because it'd be handy to be able to access the shell interface from
anywhere with a minimum of effort. |
| 10:24.19 |
Ralith |
or so I
imagine |
| 10:24.23 |
brlcad |
I'd hope a
hot-key that pops up the terminal? |
| 10:24.46 |
brlcad |
I'd like an
on-demand *terminal* as well, one that you can hide/unhide, but
that is always available |
| 10:25.10 |
brlcad |
ideally
overlayed on the display |
| 10:25.17 |
brlcad |
like command
overlays for most games |
| 10:27.08 |
Ralith |
that provides
that pretty well, then. |
| 10:33.30 |
Ralith |
brlcad:
submitting my first draft proposal now. |
| 10:33.35 |
brlcad |
cool |
| 10:34.36 |
Ralith |
I went on for
a while about it, and made an effort to provide the relevant
background, so I hope it isn't overly verbose. |
| 10:35.17 |
Ralith |
quite open to
suggestions for changes. |
| 10:40.08 |
Ralith |
in fact,
please do let me know if you have any input. |
| 10:41.13 |
Ralith |
tomorrow I'll
see if I can write another one up for the de-TCLification of the
std libs, but I think it's late enough tonight,. |
| 10:53.18 |
brlcad |
alright
cool |
| 10:55.40 |
Ralith |
thanks for
the discussion |
| 11:01.50 |
brlcad |
likewise |
| 11:02.32 |
brlcad |
good to get
some of this stuff out of my head, and to bounce old/new ideas off
of others |
| 11:03.10 |
brlcad |
I really need
to upload all of the design and docs that have gone into things to
date (along with a ton of other BRL-CAD things that would be cool
to upload) |
| 11:07.01 |
Ralith |
like
what? |
| 11:09.17 |
brlcad |
hard to
categorize, it's a lot of stuff |
| 11:10.26 |
brlcad |
renderings/images, technical papers,
design documents, tutorials, various data sets, geometry models,
.. |
| 11:10.37 |
Ralith |
sounds
neat |
| 11:10.52 |
Ralith |
any reason
not to just throw it up somewhere and work it out from
there? |
| 11:14.12 |
*** join/#brlcad madant
(n=d@117.196.129.159) |
| 11:18.12 |
brlcad |
yeah, some of
it would be very misleading, some of it is not republishable as-is,
some of it is almost entirely useless, it needs at least a pass
through |
| 11:18.59 |
brlcad |
like in my
gui research, there are dozens of shots and mockups of an LCARS
interface (from star trek) |
| 11:19.24 |
brlcad |
was just for
kicks many years ago while thinking through some ideas and wouldn't
really be useful for anything |
| 11:19.39 |
Ralith |
ah,
misleading would be a problem. |
| 11:19.43 |
brlcad |
more
distraction and FUD factors of having too much junk |
| 11:19.55 |
Ralith |
makes
sense |
| 11:26.04 |
*** join/#brlcad ashishrai
(i=d2d43dfb@gateway/web/ajax/mibbit.com/x-ccc367e0f5cc43d6) |
| 13:11.11 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:12.44 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 14:38.00 |
*** join/#brlcad madant
(n=d@117.196.139.99) |
| 16:11.41 |
*** join/#brlcad ashishrai
(i=dce36163@gateway/web/ajax/mibbit.com/x-977581b739ac3c13) |
| 16:13.40 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 17:58.37 |
brlcad |
starseeker:
coil command needs a manual page to be in src/shapes |
| 18:00.42 |
CIA-40 |
BRL-CAD:
03brlcad * r34101 10/brlcad/trunk/NEWS: annotate the 7.14.4 release
with emphasis on the gqa enhancements in mged and the new coil
shape tool |
| 18:02.09 |
CIA-40 |
BRL-CAD:
03brlcad * r34102 10/brlcad/trunk/TODO: there is a coil tool now,
but needs a manual page |
| 18:29.59 |
starseeker |
brlcad:
ok |
| 18:31.13 |
starseeker |
brlcad: um.
there's a coil.xml file that should be creating a coil man
page |
| 18:35.23 |
starseeker |
um - is
anyone else not able to svn co the brlcad tree? |
| 18:37.11 |
madant |
update
working for me :) |
| 18:40.13 |
starseeker |
growl |
| 19:18.24 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 19:25.12 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 19:30.43 |
brlcad |
starseeker:
ah! okay |
| 19:31.15 |
brlcad |
just noticed
all the .1's in src/shapes and it seemingly missing for that
one |
| 19:31.26 |
brlcad |
side effect
of having a separate doc dir |
| 19:32.39 |
CIA-40 |
BRL-CAD:
03brlcad * r34103 10/brlcad/trunk/TODO: coil has a manual page,
just in doc/docbook give it's new-style |
| 20:24.47 |
*** join/#brlcad andax
(n=andax__@d213-102-41-199.cust.tele2.ch) |
| 21:07.39 |
*** join/#brlcad madant (n=d@117.196.139.99) [NETSPLIT
VICTIM] |
| 21:07.39 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 21:07.39 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) [NETSPLIT
VICTIM] |
| 21:07.39 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 21:26.49 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
| 21:30.19 |
*** join/#brlcad pacman871
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 21:41.45 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 22:21.27 |
brlcad |
waves to pacman87, wb |
| 22:21.35 |
starseeker |
arrrrrrgh |
| 22:21.44 |
starseeker |
why can't I
connect to the sf server?? |
| 22:21.55 |
starseeker |
upgraded to 1.6.0 even |
| 22:22.05 |
pacman87 |
waves back |
| 22:22.58 |
brlcad |
starseeker:
sf doesn't like you |
| 22:23.38 |
starseeker |
apparently |
| 22:23.44 |
starseeker |
svn checkout
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 22:23.48 |
starseeker |
svn: OPTIONS
of 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk':
could not connect to server (https://brlcad.svn.sourceforge.net) |
| 22:24.28 |
brlcad |
works
here |
| 22:25.53 |
starseeker |
ok, it's some
sort of general failure |
| 22:27.19 |
starseeker |
checks how subversion was built |
| 22:38.17 |
``Erik |
hrm, issues
connecting to bz, issues connecting to sf, ... hrmmmm |
| 22:39.14 |
``Erik |
though I do
vagually recall seeing 'OPTIONS' related errors connecting to an
svn server being due to a proxy that doesn't pass the 4 or so
extensions |
| 22:40.21 |
brlcad |
ah, good
point -- starseeker, they changed some of the http/webdav
negotiation in 1.6.0 .. supposedly to require much fewer
connections and speed everything up |
| 22:40.30 |
brlcad |
might have
introduced a bug for some network/sever configurations |
| 22:48.47 |
starseeker |
brlcad: more
likely I did something to my system in that last
upgrade |
| 22:51.41 |
starseeker |
grits his teeth and runs revdep-rebuild |
| 23:06.13 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 23:17.17 |
starseeker |
oh, cute:
http://bugs.gentoo.org/show_bug.cgi?id=263497 |
| 23:20.32 |
starseeker |
now I get to
upgrade the friggin kernel |
| 23:21.48 |
brlcad |
heh |
| 23:22.07 |
brlcad |
or downgrade
glibc ;) |
| 23:22.39 |
brlcad |
i'm sure you
could manually hack the build to make it work, it's just that
socket() call getting a bad enum value |
| 23:22.51 |
starseeker |
oh,
sure |
| 23:23.08 |
starseeker |
but if I'm
going to start getting grief for running an old kernel, might as
well update it now |
| 23:24.49 |
brlcad |
seems pretty
obscure, specific to a networking code that is already using
updated glibc interface with a specific socket option |
| 23:25.19 |
starseeker |
hopes we won't see this sort of grief if/when we use
subversion in the geometry server |
| 23:25.56 |
brlcad |
curious,
which enum(s) is 0x80001 ? |
| 23:26.18 |
brlcad |
(look in
/usr/include/sys/socket.h) |
| 23:27.40 |
brlcad |
might be
easier to look at svn's sources and find that select()
call |
| 23:28.10 |
brlcad |
er,
s/select/socket/ |
| 23:28.36 |
``Erik |
hugs bsd for providing a unified cohesive system with some
great release engineering :D |
| 23:29.49 |
starseeker |
don't see
0x80001 in that file |
| 23:29.57 |
starseeker |
opps |
| 23:30.03 |
starseeker |
has to vacuum now |
| 23:30.33 |
``Erik |
I'd guess
that's a combination of flags |
| 23:30.42 |
``Erik |
or'd
together |
| 23:33.36 |
brlcad |
looks like
the neon library is actually the one to blame with the socket()
call |
| 23:35.21 |
brlcad |
aha, found
it |
| 23:35.28 |
brlcad |
they're using
SOCK_CLOEXEC, new flag |
| 23:35.39 |
brlcad |
instead of
just SOCK_STREAM |
| 23:39.14 |
brlcad |
ah, which is
the high 0x80000 bit, so if it was just 0x1, it'd work just
fine |
| 23:39.34 |
brlcad |
returns to coding, content |
| 23:40.23 |
``Erik |
coding, not
migrating machines? :D *duck* |
| 23:47.15 |
brlcad |
absolutely,
this is a coding weekend |
| 23:47.24 |
brlcad |
planned |
| 00:08.16 |
``Erik |
heh |
| 00:08.38 |
``Erik |
up's the new machine again |
| 00:45.56 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 01:24.40 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 01:31.29 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:12.57 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 02:16.14 |
starseeker |
ah, there we
go |
| 02:16.23 |
starseeker |
builds |
| 02:17.14 |
brlcad |
starseeker:
in case you're interested, there is a gsoc mailing list if i didn't
mention it before |
| 02:17.21 |
brlcad |
one
specifically for mentors, the other for everyone |
| 02:17.45 |
brlcad |
you don't
have to join, as I relay the important action-required info, but if
you're interested |
| 02:19.08 |
starseeker |
brlcad: Ah,
ok - thanks :-) |
| 02:19.13 |
starseeker |
pulls up gsoc page |
| 02:19.58 |
brlcad |
the one with
everyone can get absurdly noisy as there are about 7000
members |
| 02:20.09 |
brlcad |
and even the
mentor one from time to time (1000 or so members) |
| 02:20.45 |
brlcad |
but the
mentor one is particularly insightful at times, as it's a buffet of
open source devs talking about interesting matters |
| 02:21.11 |
brlcad |
wishes he could easily excavate the dirt between his two
basements |
| 02:21.44 |
starseeker |
hire an army
of moles ;-) |
| 02:22.56 |
brlcad |
I thought
about that actually |
| 02:23.02 |
brlcad |
well not
moles, but kids |
| 02:23.26 |
brlcad |
minimum wage
manual labor ftw |
| 02:23.40 |
kanzure |
gah, trying
to get gmsh compile with OCC support, it turns out OCC src is
distributed with config.h in the wrong place |
| 02:25.16 |
kanzure |
brlcad: where
is that mailing list? is this it?
http://groups.google.com/group/google-summer-of-code-mentors-list |
| 02:26.16 |
brlcad |
yes |
| 02:27.11 |
starseeker |
puts in request to be added |
| 02:27.56 |
kanzure |
don't know
how insightful it can be about open source development if even the
archives are subscribers-only |
| 02:28.11 |
brlcad |
it's private
with good reason |
| 02:28.30 |
brlcad |
mentors that
are added are verified so that discussions can be private if
they're about specific orgs or people |
| 02:30.18 |
kanzure |
I
see. |
| 02:30.32 |
kanzure |
whaa |
| 02:30.33 |
kanzure |
http://geuz.org/pipermail/gmsh/2008/003110.html |
| 02:30.34 |
brlcad |
kanzure:
mostly matters of how organizations are run, how they participate
with their communities, some legal matter discussions, suggestions
on how to improve a community, etc |
| 02:30.36 |
kanzure |
isn't that
me? |
| 02:30.43 |
kanzure |
this is so
disappointing |
| 02:30.54 |
brlcad |
it's not
exactly relevant to the open source community at large either,
specific to orgs and mentorship for the most part |
| 02:31.15 |
brlcad |
with a lot of
prominent voices chiming in on what works and doesn't work for
them |
| 02:32.05 |
brlcad |
kanzure:
disappointing that you were trying again last year around this
time? :) |
| 02:32.17 |
kanzure |
yes
:( |
| 02:32.23 |
brlcad |
hehe |
| 02:32.53 |
starseeker |
hah - Battle
for Wesnoth is a gsoc project |
| 02:33.11 |
kanzure |
I think what
happens is that I do just enough work to exhaust myself on
something only to wait just long enough to forget
everything |
| 02:33.25 |
kanzure |
and then I
discover some beautiful post a year later and it seems to have
exactly nearly what I'm looking for |
| 02:33.29 |
kanzure |
and then I
find out that it was me. |
| 02:34.05 |
brlcad |
starseeker:
yep, their second year |
| 02:34.07 |
brlcad |
I pressed on
them to apply last year, helped give advice on putting their org
application together |
| 02:34.17 |
starseeker |
awesome
:-) |
| 02:34.29 |
brlcad |
worked out
nicely, they're a great group of folks |
| 02:34.32 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:37.40 |
kanzure |
there was a
Slashdot comment about this recently, something like "isn't it odd
that when you search the slashdot archives you sometimes find that
one insightful comment from a discussion from a few years ago and
when you go to look who wrote it .. it was you?" |
| 02:37.40 |
starseeker |
hmm -
panotools has a "3D extension" idea |
| 02:37.44 |
kanzure |
but I've lost
it. |
| 02:37.45 |
starseeker |
wonder if
they know how hard that is |
| 02:37.57 |
starseeker |
kanzure:
yeah, saw that :-) |
| 02:38.18 |
kanzure |
<-- karma
whore. |
| 03:02.12 |
brlcad |
~kanzure++ |
| 03:30.43 |
starseeker |
grrrrrrr |
| 03:30.53 |
starseeker |
has had it with the auto_path annoyance and starts
tracking |
| 03:41.24 |
kanzure |
huh, anyone
know who pacman87 is? |
| 03:42.52 |
*** join/#brlcad pacman87
(i=500@resnet-46-102.dorm.utexas.edu) |
| 03:42.57 |
kanzure |
hey
pacman87 |
| 03:43.16 |
brlcad |
kanzure, of
course |
| 03:43.28 |
pacman87 |
kanzure:
hi |
| 03:43.32 |
kanzure |
he's probably
living a block away from me |
| 03:43.45 |
pacman87 |
who,
me? |
| 03:43.50 |
kanzure |
nods |
| 03:43.51 |
kanzure |
jester? |
| 03:43.56 |
pacman87 |
blanton |
| 03:44.00 |
kanzure |
castilian |
| 03:44.10 |
pacman87 |
ah |
| 03:44.24 |
pacman87 |
you're ME
freshman? |
| 03:44.28 |
kanzure |
yes |
| 03:44.51 |
pacman87 |
what classes
are you taking? |
| 03:44.58 |
kanzure |
nothing
interesting |
| 03:45.11 |
pacman87 |
yeah, that
was my first sem, too |
| 03:45.30 |
pacman87 |
then i took
18 hours second sem |
| 03:45.44 |
kanzure |
I did that
backwards, but anyway |
| 03:45.53 |
kanzure |
didn't know
that there was anyone working with brlcad on campus
here |
| 03:46.06 |
pacman87 |
i was GSoC
last year |
| 03:46.17 |
brlcad |
and a
fantastic gsocer at that |
| 03:46.20 |
pacman87 |
:D |
| 03:46.22 |
kanzure |
hm |
| 03:46.24 |
brlcad |
awesome new
primitives |
| 03:46.25 |
kanzure |
we should
probably meet up some time. |
| 03:46.31 |
pacman87 |
added the hyp
and started the rev |
| 03:46.39 |
brlcad |
almost
finished rev |
| 03:46.43 |
kanzure |
maybe I'll
show you the austin fab lab that I'm helping to throw
together |
| 03:48.05 |
starseeker |
brlcad: Ah
HA |
| 03:48.30 |
starseeker |
something,
somewhere on my system, is setting ITCL_LIBRARY and
ITK_LIBRARY |
| 03:48.36 |
brlcad |
"take on me"
is a great ah-ha song |
| 03:48.49 |
starseeker |
looks like
libtclcad is treating that as an explicit override |
| 03:48.56 |
starseeker |
heh |
| 03:48.57 |
brlcad |
that's a
sure-fire way to screw up autopathing |
| 03:49.09 |
pacman87 |
anyone want
to help me debug an "undefined reference" problem in a .so for
something unrelated to brlcad? |
| 03:49.15 |
brlcad |
those are
supposed to be explicit overrides |
| 03:49.21 |
kanzure |
sure, why
not |
| 03:49.27 |
brlcad |
tcl_library,
tk_library, itcl_library, itk_library |
| 03:49.30 |
starseeker |
shouldn't
that be disabled if itcl/itk is specified as the internal
copy? |
| 03:49.42 |
brlcad |
nope |
| 03:49.59 |
brlcad |
it's an
environment var override -- the environment is wrong |
| 03:50.11 |
kanzure |
the
environment is never wrong :) |
| 03:50.12 |
kanzure |
snickers |
| 03:50.14 |
brlcad |
like setting
ld_library_path and expecting it to find the right libs |
| 03:50.22 |
kanzure |
starseeker:
what are you working on? |
| 03:50.44 |
pacman87 |
i'm trying to
compile the qt4 branch of moto4lin, and it uses p2kmoto
(libp2kmoto.so) |
| 03:50.49 |
starseeker |
archer won't
start on my system, because it's mixing the internal tcl/tk and
system itcl/itk |
| 03:50.55 |
brlcad |
the entire
point of the vars is so that regardless of what it was compiled
for, I can at run-time make it use anything |
| 03:51.26 |
pacman87 |
moto4lin
builds libp2kqt.so, which is trying to link to symbols defined in
libp2kmoto.so |
| 03:52.39 |
brlcad |
starseeker:
mixing internal tcl/tk with system itcl/itk 'can' work, but depends
on the revisions, search paths, and init files it finds |
| 03:53.12 |
brlcad |
if it finds
the 3.2 itcl init files first, it won't load a 3.4
install |
| 03:53.58 |
pacman87 |
"nm
/usr/local/lib/libp2kmoto.so" shows the symbols are defined, but
"nm libp2kqt.so" says they're undefined |
| 03:54.11 |
pacman87 |
and i don't
know how to fix it |
| 03:56.53 |
brlcad |
pacman87: er,
if it's a partially resolved lib, just means you have to provide
both libs on the linker line (in order) |
| 03:57.31 |
pacman87 |
and the
linker line would be in the Makefile? |
| 03:57.49 |
brlcad |
depends how
they do their build, but yeah usually |
| 03:58.07 |
brlcad |
can always
link by hand if need be too |
| 03:59.19 |
pacman87 |
how would i
do that? |
| 04:05.06 |
brlcad |
well paste a
log of it failing |
| 04:05.08 |
starseeker |
well, that's
closer |
| 04:05.18 |
brlcad |
that should
show you the compile/linker line |
| 04:05.21 |
starseeker |
looks like
maybe iwidgets is messing up again... |
| 04:05.37 |
brlcad |
really?
haven't seen iwidgets be a problem in years |
| 04:05.46 |
brlcad |
there is an
iwidgets override too iirc |
| 04:05.58 |
pacman87 |
brlcad: i
think i fixed it |
| 04:06.13 |
pacman87 |
i uncommented
two lines in the CMakeLists.txt file relating to
p2kmoto |
| 04:06.39 |
brlcad |
:)_ |
| 04:06.58 |
pacman87 |
ouch,
segfault |
| 04:07.00 |
starseeker |
hang on,
here's the log: http://pastebin.bzflag.bz/d3e0053b5 |
| 04:10.52 |
starseeker |
well, setting
IWIDGETS_LIBRARY didn't fix it |
| 04:11.35 |
brlcad |
starseeker:
looks like you're getting a system iwidgets |
| 04:11.45 |
brlcad |
bob has a
modification on exactly that line it's failing on |
| 04:11.52 |
starseeker |
yeah, not
surprsied |
| 04:12.03 |
starseeker |
is looking to figure out how to point it to local
version |
| 04:12.06 |
pacman87 |
it probably
doesn't help that moto4lin hasn't been touched in 14
months |
| 04:12.36 |
starseeker |
gentoo must
be cluttering up the environment with a bunch of explicit setting
of flags or something |
| 04:12.43 |
starseeker |
s/flags/paths |
| 04:12.45 |
brlcad |
starseeker:
it's tcl, you can update the system iwidgets file directly
too |
| 04:12.52 |
brlcad |
see if that
at least fixes it |
| 04:12.54 |
starseeker |
true |
| 04:13.08 |
brlcad |
diff your
system panedwindow.itk to the one in src/other/iwidgets |
| 04:13.21 |
brlcad |
er,
src/other/iwidgets/generic/panedwindow.itk |
| 04:13.37 |
brlcad |
should be at
least three lines, two commented out with "Bob
Modification" |
| 04:14.12 |
brlcad |
looks like
it's a bug in iwidgets that he fixed |
| 04:14.28 |
starseeker |
yep, see
it |
| 04:15.33 |
brlcad |
it uses _ret
without sanity checking it first, the for loop might be empty if
there are no active panes |
| 04:15.46 |
starseeker |
yeah, that
did it |
| 04:15.46 |
brlcad |
resulting in
the error trace you saw |
| 04:16.51 |
brlcad |
bets ArcherCore.tcl could just wrap that line in a try/catch
and it'd also prevent the failure |
| 04:17.19 |
brlcad |
that'd be
good to try, cause if it worked, then it'd work with vanially
iwidgets |
| 04:17.39 |
starseeker |
I think I saw
three separate modifications to that file though |
| 04:17.48 |
starseeker |
any chance of
upstream incorporating it? |
| 04:19.22 |
brlcad |
try
that |
| 04:19.36 |
CIA-40 |
BRL-CAD:
03brlcad * r34104
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: try catching
the error in case we're using a system iwidgets that doesn't have
bob's patch for referencing the unitialized _ret var in
panedwindow |
| 04:19.36 |
brlcad |
i'm sure
upstream would |
| 04:19.45 |
brlcad |
that is the
that I was referring to, btw |
| 04:20.17 |
starseeker |
er, sept 2002
last iwidgets release - nevermind |
| 04:20.29 |
brlcad |
it's
considered "done" iirc |
| 04:20.36 |
starseeker |
winces |
| 04:20.43 |
starseeker |
we're the
only ones who hit that bug? |
| 04:21.50 |
starseeker |
ah |
| 04:22.05 |
starseeker |
so if it
fails it can be safely ignored? |
| 04:22.14 |
starseeker |
that's
handy |
| 04:23.49 |
brlcad |
if it fails,
there are no active panes yet, so nothing needs to
happen |
| 04:24.03 |
brlcad |
"should"
work.. but give it a try |
| 04:24.15 |
brlcad |
might be more
places it needs catched |
| 04:27.14 |
brlcad |
waits to hear the result... |
| 04:33.20 |
starseeker |
heh - sorry,
had stuff to take care of - one sec... |
| 04:34.59 |
starseeker |
yep, looks
like that got it |
| 04:35.03 |
starseeker |
nice
:-) |
| 04:37.28 |
brlcad |
the iwidgets
dev still responds to patches, so would probably be worthwhile to
clean up and upload a diff |
| 04:38.28 |
starseeker |
rebuilds with ogl enabled to properly test
archer |
| 04:40.23 |
starseeker |
brlcad:
IIRC, we disabled ogl because it was crashing on some
platforms? |
| 04:40.38 |
starseeker |
plus the slow
updating with rt? |
| 04:40.55 |
brlcad |
more "bad
behavior" than crashing |
| 04:41.02 |
starseeker |
ah |
| 04:42.16 |
starseeker |
well, I've
never debugged ogl but there's always a first time... |
| 04:45.02 |
brlcad |
slow remote
fb updates |
| 04:45.20 |
starseeker |
I thought
that was for everything? |
| 04:45.31 |
starseeker |
recalls poking at libpkg but not seeing anything
conclusive |
| 04:45.40 |
starseeker |
was that ogl
specific? |
| 04:46.21 |
brlcad |
I don't
recall, but it was at least remotefb->oglfb with specific sizes
being much worse than others |
| 04:46.54 |
brlcad |
and iirc,
wasn't in the libpkg layer, think that came up clean |
| 04:47.13 |
starseeker |
seemed to
be |
| 04:49.45 |
brlcad |
was directly
in the fbserv or sending side |
| 04:50.04 |
brlcad |
not crossing
the wire |
| 05:43.13 |
*** join/#brlcad ``Erik_
(n=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 05:44.25 |
Ralith |
ogl was
crashing on freebsd w/ nvidia drivers, at least for a
while |
| 06:36.44 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 07:15.58 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:24.46 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 07:33.18 |
Ralith |
brlcad: is
the content portion of a GSoC application publicly
visible? |
| 07:34.27 |
brlcad |
Ralith: only
if the student(s) post their application to the wiki or elsewhere
beforehand |
| 07:34.40 |
brlcad |
the content
becomes visible after students are selected |
| 07:35.24 |
Ralith |
huh. The
tooltips suggest that only the abstract is ever published like
that. |
| 07:47.49 |
brlcad |
ah, that may
be |
| 07:48.18 |
brlcad |
yeah, was
just abstrcat in previous years |
| 07:48.31 |
brlcad |
there's a
small window to tweak those before they go live usually
too |
| 07:53.55 |
Ralith |
so the
content *isn't* ever public? |
| 07:54.03 |
Ralith |
at least in
the past? |
| 07:54.42 |
Ralith |
de-TCLification application
submitted. |
| 07:58.17 |
Ralith |
brb |
| 07:59.03 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:02.27 |
Ralith |
looking
forward to any/all feedback. |
| 08:04.45 |
madant |
Ralith: I
think google's concern is with privacy issues and all
:D |
| 08:05.32 |
Ralith |
madant: well,
I don't think I have a reasonable expectation of privacy in the
legal sense for that sort of thing. |
| 08:06.20 |
madant |
:) |
| 08:06.58 |
madant |
apparently
some people are :D like when we started an introduction thread in
the group and some people had a problem with that too
:D |
| 08:07.12 |
Ralith |
O.o |
| 08:07.19 |
Ralith |
people are
weird. |
| 08:07.31 |
Ralith |
not that a
soc app is the worst of things a future employer might find upon
googling. |
| 08:07.42 |
madant |
hahaha
:D |
| 08:08.21 |
Ralith |
"But I don't
want the internet to know I'm ga^H^Han amateur
engineer!" |
| 08:08.25 |
madant |
I think the
best approach as brlcad mentioned is to post the application at
appspot and then reflect the same on the wiki and even better on
the mailing list.. :) i will be doing that today :) |
| 08:08.41 |
Ralith |
what's this
now? |
| 08:09.04 |
Ralith |
applicants
are expected to mirror their applications on the mailing list and
the wiki? |
| 08:09.25 |
madant |
not as a
compulsion or anything :) |
| 08:10.26 |
madant |
the only
technical necessity is the appspot application :) |
| 08:11.08 |
Ralith |
well, sure,
but you're not *technically* expected to make contributions to
establish your ability to read and write useful code. |
| 08:11.33 |
Ralith |
I just didn't
see any mention of an expectation to repost your application
anywhere on the wiki instructions |
| 08:11.51 |
Ralith |
brlcad: can
you clarify? |
| 08:13.58 |
brlcad |
Ralith: great
(regarding the detcl), should have feedback sometime tomorrow
hopefully |
| 08:14.19 |
brlcad |
or you can
keep pinging any of the mentors here too ;) |
| 08:14.23 |
madant |
Ralith: did
you read the "Applications, wiki, and early submission" mail from
brlcad :) .. ah he is here :D |
| 08:14.52 |
Ralith |
brlcad:
heh |
| 08:15.07 |
Ralith |
madant: I
only just recently got on the ML, and I don't usually keep a close
eye on my email; let me load up thunderbird. |
| 08:15.31 |
Ralith |
is very much an IRC person. |
| 08:16.10 |
madant |
http://www.nabble.com/Applications%2C-wiki%2C-and-early-submission-td22731057.html |
| 08:16.11 |
brlcad |
and that's
right -- there's no "requirement" to cross-post to the wiki -- just
some folks like to do that to share their application with others
or to get discussion/feedback before it goes into the socghop
interface |
| 08:16.15 |
Ralith |
oh, crap,
forgot to confirm my subscription. |
| 08:16.25 |
Ralith |
madant:
thanks |
| 08:16.36 |
Ralith |
brlcad: ah,
so no point to once it's on google? |
| 08:17.08 |
Ralith |
thought the wiki bit was odd because those concerned would be
able to see it on google already, and that would explain
it. |
| 08:17.41 |
brlcad |
Ralith: no --
the same point could still hold, sharing the details of your
application with the community at large |
| 08:18.02 |
Ralith |
hm, that
reminds me, I should probably grab a wiki account. |
| 08:18.12 |
Ralith |
ooh,
recaptcha! |
| 08:18.14 |
Ralith |
kudos! |
| 08:18.34 |
madant |
:) i love it
too :D |
| 08:19.07 |
Ralith |
oh, looks
like I already registered and forgot. |
| 08:19.09 |
brlcad |
there's no
real "secret" to an application imho, some orgs require them to be
hashed out publicly before they go into the app interface
even |
| 08:20.53 |
brlcad |
example,
http://my.bzflag.org/w/User:IneQuation.pl |
| 08:21.28 |
brlcad |
or
http://my.bzflag.org/wiki/index.php?title=User:Nightstrike&oldid=5617 |
| 08:22.08 |
brlcad |
or http://my.bzflag.org/w/User:Will07c5
.. where we could quickly tell the student that his priorities were
almot all wrong originally and woefully lacking in
detail |
| 08:28.41 |
CIA-40 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1314 10/wiki/User:Ralith: Page created w/ GSoC
applications |
| 08:28.53 |
Ralith |
CIA is
neat. |
| 08:29.15 |
Ralith |
are the bots
open source? |
| 08:29.22 |
Ralith |
i.e. would it
be easy to host one independent of the service? |
| 08:29.58 |
brlcad |
yeah, the
whole system can be retrieved and run independently |
| 08:30.17 |
brlcad |
it's a pretty
complex system though |
| 08:30.45 |
Ralith |
neat! |
| 08:30.56 |
Ralith |
it's the
ability to do so that matters, really |
| 08:31.07 |
brlcad |
the bots
themselves are pretty simple -- they just say what they're told to
say |
| 08:31.14 |
Ralith |
although I
can't help but think that it might not be hard to make a
lightweight version that just attached to a single repo and/or set
of RSS feeds |
| 08:31.46 |
brlcad |
if that's all
you want, there are probably easier means (like libIRC or an
existing bot like supybot or blootbot) |
| 08:32.03 |
Ralith |
I thought
that was the major selling point? |
| 08:33.05 |
brlcad |
selling point
of what? |
| 08:33.54 |
brlcad |
cia's focus
is more around commit data, which isn't caputureed well with rss
fields and suffers other drawbacks |
| 08:34.24 |
brlcad |
there are
bots (supy for example) that will poll an rss feed and announce
changes |
| 08:34.35 |
brlcad |
tend to be
rather flakey |
| 08:35.38 |
Ralith |
I mean, I
thought the main point of CIA was to offer a commit announce
bot. |
| 08:36.02 |
Ralith |
you could
implement a bot by more reliable means than RSS feeds, e.g.
post-commit hooks; I just mentioned RSS feeds cuz they're nice and
generic. |
| 08:36.03 |
brlcad |
yeah, one of
the main original points |
| 08:36.32 |
brlcad |
cia uses /
prefers post-commit hooks |
| 08:36.52 |
brlcad |
or it'll take
e-mail notifications |
| 08:37.03 |
brlcad |
or it'll take
xml rpc updates |
| 08:37.12 |
brlcad |
or it can
poll for updates |
| 08:38.35 |
Ralith |
right |
| 08:38.42 |
Ralith |
but it seems
a little odd to use a centralized service for that |
| 08:38.48 |
Ralith |
rather than
instantiate something lightweight for each project |
| 08:39.19 |
brlcad |
the
complexity in the system is that it's geared with performance and
scalability in mind, also keeps track of daily commit histories,
automatically presents the data through a load-balanced web site,
and a little bit more |
| 08:39.52 |
brlcad |
mostly
because it's so easy to set up and someone else maintains
it |
| 08:40.42 |
brlcad |
you just drop
in a commit notifier, and that's it .. everything else including
running bots, the web site, the project listing on the site, all
happening automatically |
| 08:41.47 |
brlcad |
kinda like
how ibot is in about 100 channels .. even though there are dozens
of irc factoid bots out there that projects could/do use by
themselves |
| 08:42.27 |
brlcad |
someone else
manages and maintains it, and I don't have to care |
| 08:44.11 |
archivist |
I run a multi
channel bot, can be fun |
| 08:44.55 |
Ralith |
good
point. |
| 08:45.10 |
Ralith |
that makes a
lot of sense |
| 11:09.34 |
*** join/#brlcad madant_
(n=d@117.196.143.31) |
| 11:10.22 |
d-lo |
*readreadread* |
| 11:10.36 |
d-lo |
mernin
all |
| 11:10.52 |
madant_ |
mernin d-lo
:) |
| 11:27.52 |
*** join/#brlcad madant_
(n=d@117.196.135.15) |
| 12:16.12 |
starseeker |
hmm. built
with enable-profiling, but don't see any a.out files from
rt |
| 12:22.50 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
| 12:28.45 |
``Erik |
hm, what is
the bots webpage url? |
| 12:29.08 |
``Erik |
d-lo: you
missed the big jg crash in e79! |
| 12:31.58 |
d-lo |
I
know. |
| 12:32.21 |
d-lo |
Care level is
pretty low. Good weather (minus the tornado :/) this weekend.
hard to stay indoors :) |
| 12:33.11 |
``Erik |
it was sloppy
and slow, there were plenty of long breaks of activity
:) |
| 12:33.40 |
``Erik |
breaks from
activity, rather |
| 12:34.04 |
``Erik |
yesterdays
hail almost makes me happy my car is in the shop and not infront of
the house heh |
| 12:35.06 |
*** join/#brlcad madant
(n=d@117.196.137.242) |
| 12:35.56 |
d-lo |
heh, thats
kinda funny. We didn't get hail up at our place. just a nice view
of the 'nado to the NW of us and a spit of rain. |
| 13:10.29 |
*** join/#brlcad madant_
(n=d@117.196.138.162) |
| 13:21.41 |
starseeker |
uh...
tornado? |
| 13:21.47 |
starseeker |
pics? |
| 13:24.28 |
d-lo |
Heh, didn't
snap any. I looked out the window to see some nasty looking storm
clouds. Flipped on the TV only to see News channel 8 basicly
saying "OMGOMGOMGOMGTORNADO". Looked out the window again and saw
what looked like a 'funnel', but mostly obscured by neighboring
houses. |
| 13:24.41 |
starseeker |
ah
:-) |
| 13:24.53 |
d-lo |
Power went
out abou then, and I called the ball and got the family into the
basement. |
| 13:25.05 |
starseeker |
indeed |
| 13:25.46 |
d-lo |
Nothing bad
happened, infact, the rain was quite pathetic. no cool air-raid
sirens from the local VFDs... no awesome 2" hail... just about 5
minutes of torrential downpour. |
| 13:25.51 |
d-lo |
then... all
over. |
| 13:26.00 |
d-lo |
su was out 30
mins later :/ |
| 13:26.04 |
d-lo |
su=
sun |
| 13:26.24 |
starseeker |
phew |
| 13:27.20 |
d-lo |
yeah, I guess
I should be more thankful than disappointed :) |
| 13:28.19 |
starseeker |
unless you
REALLY don't like your current roof/home siding |
| 13:31.39 |
d-lo |
I just wanted
to see a car get thrown like a toy tonka truck.... its on my Bucket
list. |
| 13:38.28 |
starseeker |
ah |
| 13:38.43 |
starseeker |
well, you
could take up storm chasing as a hobby ;-) |
| 13:38.51 |
starseeker |
doubt the
insurance guys would go for it though |
| 13:41.00 |
d-lo |
Well, if i
ever become independantly wealthy, a widower and without
children.... then storm chasing might be fun :) |
| 14:31.12 |
starseeker |
realizes he needs to bring set theory/Venn diagram logic into
the point question |
| 14:31.39 |
starseeker |
wonder if
ASCII has set notation characters |
| 14:46.48 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 14:53.31 |
mafm_ |
hi |
| 15:10.00 |
*** join/#brlcad cad73
(n=803f1020@bz.bzflag.bz) |
| 15:10.33 |
*** join/#brlcad madant
(n=d@117.196.142.56) |
| 15:26.28 |
*** join/#brlcad ziactn
(n=7934900c@bz.bzflag.bz) |
| 15:33.56 |
CIA-40 |
BRL-CAD:
03brlcad * r34105 10/brlcad/trunk/src/external/Cubit/ (Makefile.am
g-sat.cpp g-sat.cxx): Rename g-sat.cxx to g-sat.cpp to be
consistent with the other C++ sources in the 'brlcad'
module. |
| 15:43.27 |
CIA-40 |
BRL-CAD:
03brlcad * r34106 10/brlcad/trunk/src/librt/ (bezier_2d_isect.c
comb.c cut.c db5_bin.c db5_types.c): apparently don't need to
include nmg.h, not using nmg routines/structures. |
| 15:47.11 |
madant |
brlcad never
sleeps :P |
| 15:48.13 |
CIA-40 |
BRL-CAD:
03brlcad * r34107 10/brlcad/trunk/TODO: reverting a very old
decision. separate the nmg routines from librt into their own
library. |
| 15:51.15 |
CIA-40 |
BRL-CAD:
03brlcad * r34108 10/brlcad/trunk/TODO: downgrade expected list of
items for next release until later save for a few relatively simple
ones |
| 15:51.58 |
CIA-40 |
BRL-CAD:
03brlcad * r34109 10/brlcad/trunk/TODO: bob made the inside command
work on edit primitives (this was on-schedule, just hadn't been
moved up for current release) |
| 15:55.26 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 15:59.59 |
CIA-40 |
BRL-CAD:
03brlcad * r34110 10/brlcad/trunk/misc/win32-msvc8/ (Makefile.am
g_diff/ g_lint/ g_transfer/): start of stubs for the rest of the
gtools |
| 16:02.01 |
CIA-40 |
BRL-CAD:
03brlcad * r34111 10/brlcad/trunk/misc/win32-msvc8/ (7 files in 4
dirs): step closer on gtools stub using g_qa.vcproj as forked
base |
| 16:04.34 |
CIA-40 |
BRL-CAD:
03brlcad * r34112 10/brlcad/trunk/misc/win32-msvc8/ (3 files in 3
dirs): last step, update content to compile the right source files.
probably still need minor source file changes to compile on
windows. |
| 16:06.59 |
CIA-40 |
BRL-CAD:
03brlcad * r34113
10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: can't imagine
the uuid's are right, but this will hook the three new gtools into
the windows build -- g_diff, g_lint, and g_transfer. |
| 16:11.43 |
CIA-40 |
BRL-CAD:
03brlcad * r34114 10/brlcad/trunk/misc/win32-msvc8/ (4 files in 4
dirs): update the deps. only g_qa needs libged, g_transfer needs
libpkg and winsock |
| 16:12.46 |
CIA-40 |
BRL-CAD:
03brlcad * r34115 10/brlcad/trunk/src/gtools/g_diff.c: g_diff
doesn't use ged |
| 16:34.02 |
CIA-40 |
BRL-CAD:
03brlcad * r34116 10/brlcad/trunk/src/gtools/ (g_diff.c g_lint.c
g_qa.c g_transfer.c): ws, style consistency cleanup |
| 16:35.58 |
CIA-40 |
BRL-CAD:
03brlcad * r34117 10/brlcad/trunk/src/gtools/g_diff.c: ugh, libged
atrociously still has wdb_obj and friends (e.g., wdb_create_cmd) so
DO have to include ged.h here. suckage. |
| 16:36.56 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 16:36.56 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.4 posted this weekend (20090313) || GSoC 2009
Begins! |
| 16:37.31 |
CIA-40 |
BRL-CAD:
03brlcad * r34118
10/brlcad/trunk/misc/win32-msvc8/g_diff/g_diff.vcproj: g_diff does
use libged for the blasted wdb_obj funcs like wdb_create_cmd,
wdb_get_tcl, and wdb_init_obj. |
| 16:42.54 |
*** join/#brlcad dreeves
(n=c752f348@bz.bzflag.bz) |
| 16:43.38 |
CIA-40 |
BRL-CAD:
03brlcad * r34119 10/brlcad/trunk/ (TODO include/ged.h): annotate
the fixme items that the wdb and view objects in libged still need
to be refactored/renamed |
| 16:46.44 |
CIA-40 |
BRL-CAD:
03brlcad * r34120 10/brlcad/trunk/TODO: might not 'compile', but
g_lint is hooked into the windows build now so remove the todo
until we know there's a problem. |
| 16:57.22 |
brlcad |
Ralith:
interesting thread on /. about firefox's planned taskbar -- that's
very similar to what we were discussing the other day |
| 16:57.26 |
brlcad |
http://people.mozilla.com/~faaborg/files/labs/taskFoxi1.png |
| 16:58.37 |
brlcad |
(particularly
idea2 if you want to get specific on overlay integration and look
n' feel) |
| 16:59.04 |
brlcad |
except for
the silly ellipses around the action/verbs |
| 17:24.17 |
brlcad |
things are
looking really well for those that have already put an application
in.. submission counts are quite low this year thusfar |
| 17:24.39 |
brlcad |
much better
chances that previous years .. wonder how much of a "get it in at
the last minute" rush there will be |
| 17:24.48 |
madant |
:) |
| 17:25.09 |
madant |
i expected a
lot more discussion on the irc myself |
| 17:25.26 |
brlcad |
every year
seems to be a different twist |
| 17:25.33 |
madant |
will submit in an hour :) |
| 17:25.35 |
mafm |
maybe they
extend the period for 1 month this year :P |
| 17:25.44 |
brlcad |
mafm:
unlikely |
| 17:25.48 |
madant |
mafm
lol |
| 17:26.14 |
brlcad |
i mean, maybe
.. but last year the week or so extension didn't really do much but
add some last minute desperation submissions that were pretty
bad |
| 17:26.33 |
brlcad |
got the count
up, but none that made it |
| 17:26.57 |
madant |
and besides i
wonder if google is really concerned about increasing the total
number of applications this year :) |
| 17:27.04 |
brlcad |
this year,
there just hasn't been nearly as much advertising (by google,
didn't get the /. headline, etc) |
| 17:27.17 |
brlcad |
yeah, I'm not
worried |
| 17:27.27 |
brlcad |
I mean, we're
only asking for 3 or 4 slots |
| 17:27.31 |
mafm |
Debian also
talks about less and less applicants |
| 17:27.42 |
mafm |
anybody
taking the GUI one? |
| 17:27.47 |
brlcad |
so we only
need 3 or 4 good applications, and we already have at least two
that I'd be happy with :) |
| 17:28.50 |
brlcad |
mafm:
actually, there is a good application in application in to continue
what you started |
| 17:29.23 |
d-lo |
whoa....
deja-vu |
| 17:29.37 |
brlcad |
s/a good
application/an/ :) |
| 17:29.40 |
d-lo |
needs to know if it was *the same* black
cat..... |
| 17:30.01 |
d-lo |
;) |
| 17:30.05 |
brlcad |
not enough
samples to qualify it as good or bad yet :) |
| 17:30.44 |
madant |
can't figure out the word limit for the
proposal |
| 17:31.00 |
mafm |
7500 last
year, IIRC |
| 17:31.07 |
mafm |
erm,
characters |
| 17:31.13 |
madant |
haha
:D |
| 17:31.50 |
mafm |
brlcad: one
of the two that you're happy with? from whom? |
| 17:32.00 |
madant |
wonders whether writing or reading is
tougher |
| 17:32.38 |
brlcad |
mafm: why
applicants of course |
| 17:33.37 |
madant |
brlcad:
:D |
| 17:33.48 |
mafm |
I mean the
nickname, so I'll talk to him/her if I see $1 |
| 17:34.15 |
brlcad |
no point in
calling people out, hang around and you'd find out ;) |
| 17:34.53 |
brlcad |
i know what
you meant, just not going to get into who has submitted what apps
unless they reveal it themselves just for sake of discretion until
selections are made |
| 17:34.54 |
madant |
:) besides it
is not fair to announce names before the final list is
out |
| 17:35.35 |
mafm |
it was just
curiosity, no list is definitive until all applications are in,
anyway |
| 17:35.42 |
brlcad |
also what's
cool about putting your proposals on the wiki -- so other students
can see what they're up against and can improve each other's work
or submit for other areas |
| 17:36.39 |
mafm |
I didn't
found the new ones in the wiki, where are they linked? |
| 17:36.44 |
brlcad |
thinks everyone should submit for (exactly) two ideas
regardless just so desirable individuals aren't left out because of
a competitive submission topic |
| 17:37.06 |
mafm |
(that's why I
came to the channel, to ask directly :) ) |
| 17:37.09 |
brlcad |
like the web
geometry database last year.. geez. There was more than a half
dozen submissions for it |
| 17:37.25 |
brlcad |
you can check
the recent changes |
| 17:37.25 |
madant |
and none got
selected :O |
| 17:37.30 |
brlcad |
yep |
| 17:37.34 |
brlcad |
actually one
did |
| 17:37.47 |
brlcad |
but she was
lost to a coin toss with another org that conflicted |
| 17:38.09 |
brlcad |
so one of you
four last year got lucky :) |
| 17:38.17 |
madant |
ah nice
:) |
| 17:39.23 |
brlcad |
and yes,
there was an actual coin toss by leslie since we both wanted her
with pretty equal justifications and the student wanted to work
with both equally |
| 17:39.40 |
mafm |
I had already
done that, but only saw something new for libpc (aside from older
devels) in the last few days |
| 17:39.45 |
mafm |
gonna dig
further |
| 17:39.50 |
madant |
brlcad: wow
talk about coins and destiny :P |
| 17:40.24 |
brlcad |
mafm: does it
matter? shouldn't you be working on your proposals? :) |
| 17:40.32 |
brlcad |
or do you
intend to mentor? |
| 17:40.35 |
brlcad |
or just
watch? :) |
| 17:40.47 |
brlcad |
(all three
are options, of course) |
| 17:41.23 |
brlcad |
madant: yeah,
i'm pretty happy with last year's results though |
| 17:41.43 |
brlcad |
wished more
progress could be made, of course, but that can almost always be
said ;) |
| 17:41.47 |
madant |
mafm:
http://brlcad.org/wiki/User:Ralith
read this ? |
| 17:42.37 |
mafm |
madant:
reading it right now |
| 17:42.56 |
madant |
brlcad: :D
lets hope this year is much more productive.. I feel like we have a
bunch of very interesting people.. i mean the ones who came on the
channel at least |
| 17:42.57 |
mafm |
brlcad: I
don't think that I'm eligible, and besides that I don't think that
I would apply this year |
| 17:43.11 |
mafm |
just checking
the proposals for curiosity |
| 17:43.34 |
mafm |
and to maybe
help people in that part, even if not officially a
mentor |
| 17:43.47 |
mafm |
but if it's
ralith, he's already an insider :) |
| 17:43.52 |
brlcad |
mafm: btw, I
believe I am about ready to make an executive decision regarding
the gui |
| 17:44.07 |
brlcad |
mafm: ah
right, understand |
| 17:44.12 |
brlcad |
then you
should mentor! |
| 17:45.13 |
brlcad |
ralith IS an
insider .. but also just getting started with coding on BRL-CAD,
getting new devs up and coding is always good even if they've been
in the channel for years :) |
| 17:45.27 |
brlcad |
mafm: even as
a backup mentor, you'll at least get a t-shirt |
| 17:45.30 |
madant |
Mentor Manuel
Montecelo :) |
| 17:45.31 |
brlcad |
:) |
| 17:46.26 |
mafm |
well, it
depends on the obligations |
| 17:47.22 |
mafm |
my father
died a few days ago and I have tonnes of things to do, delayed and
new ones due to this "ocurrence" |
| 17:47.59 |
mafm |
what's the
executive decision about the gui, using another toolkit (reading
proposal right now)? |
| 17:49.26 |
madant |
mafm: really
sorry to hear that. I know irc doesnt offer a good channel to
convey what one feels very clearly .. nyways.. hope he had a great
time |
| 17:49.45 |
mafm |
thanks |
| 17:49.57 |
mafm |
he did, most
of the time |
| 17:50.28 |
madant |
today was the
death anniversary of my grandmom. went to the cemetery, church etc
:) |
| 17:50.33 |
mafm |
he was kind
of a Big Fish kind of person, not so exaggerated, but
well |
| 17:51.33 |
madant |
mafm: hehe :)
my dad is a Big Fish kind of person too :D |
| 17:52.16 |
mafm |
he died of
cancer with multiple "branches", I think that the Big Fish
character also did |
| 17:52.48 |
mafm |
so the last
months were not very pleasant :( |
| 17:52.56 |
madant |
hmm. can
imagine |
| 17:53.57 |
madant |
brlcad:
should i first post my assesment of the current status of libpc
plus my plan first to the group / wiki and then submit to appspot
like after 2 days probably ? |
| 17:54.11 |
mafm |
but well, he
did not suffer so much as it was expected etc, so at least it's
something |
| 17:54.42 |
madant |
mafm: when
was this ? |
| 17:54.59 |
mafm |
died? less
than 2 weeks ago |
| 17:55.31 |
madant |
ok .. what
are ur plans now that school is over ? |
| 17:55.42 |
mafm |
madant: you
were from india, right? when you talk about church, which
one? |
| 17:55.55 |
madant |
well I am a
roman catholic :) |
| 17:56.16 |
madant |
has ancestors who were baptised by St. Thomas around 2000
years ago apparently :D |
| 17:56.41 |
madant |
is definitely not very religious though :P |
| 17:56.58 |
mafm |
are you from
Goa or some region with more european culture, or doesn't have
anything to do? |
| 17:57.16 |
madant |
mafm: nope
100 % Indian :P |
| 17:57.42 |
mafm |
I'm not
officially out of school, the final project to get the degree was
to be presented in 20th of march, but it couldn't be... so I still
have to finish some bits and present it |
| 17:58.49 |
mafm |
that's why I
don't know exactly whether I would be eligible for gsoc
:) |
| 17:59.29 |
madant |
ah.. u could
ask Leslie you know.. at the channel ? |
| 18:00.10 |
mafm |
IIRC Goa even
had candidates for the Pope "elections", and never went there but
several friends did |
| 18:00.30 |
mafm |
well, I don't
know whether I'd like to apply to something |
| 18:00.54 |
mafm |
my first
option would be to continue the GUI project, but well
:D |
| 18:01.39 |
mafm |
and after
many years without holidays, it doesn't look a very attractive
prospect (even if gsoc is) |
| 18:01.49 |
mafm |
summer
holidays, that is |
| 18:02.35 |
madant |
:) |
| 18:03.37 |
mafm |
btw, I was
supposed to be roman catholic too, but I only believed as a
child |
| 18:03.44 |
brlcad |
mafm: really
sorry to hear about your father, I can only imagine the suffering
and pain but hope you're well |
| 18:04.34 |
brlcad |
madant: sure,
that'd work |
| 18:04.37 |
mafm |
besides,
nobody expects the spanish inquisition, with "almost-fanatical
devotion to the pope" chief weapon, etc :P |
| 18:04.59 |
madant |
mafm: me too
:) I was even an altar boy. |
| 18:05.20 |
mafm |
brlcad:
thanks too :) |
| 18:05.49 |
madant |
goes to church on sundays so that his mom doesn't feel "All
is lost" :D |
| 18:06.42 |
mafm |
I'm more or
less OK, the worse part was the initial shock, and to pretend that
everything was alright (so neither him or other people in the
family knew the truth) |
| 18:07.50 |
mafm |
I stopped
going to the church at around 15 I think, and now that my father
died the priest wanted me to repent and come back to the shepherd
:P |
| 18:08.05 |
madant |
:) |
| 18:08.25 |
mafm |
brlcad: so
the dramatic change was about Qt? |
| 18:08.41 |
brlcad |
hm? |
| 18:08.43 |
brlcad |
dramatic
change? |
| 18:10.10 |
mafm |
brlcad: well,
whatever the executive decision would be :) |
| 18:11.31 |
hippieindamakin8 |
hey
ppl |
| 18:11.39 |
mafm |
hi
hippieindamakin8 |
| 18:11.57 |
hippieindamakin8 |
hey mafm ! so
are u mentoring this year ? |
| 18:12.46 |
mafm |
dunno
yet |
| 18:13.38 |
hippieindamakin8 |
madant, you
are from goa or kerala ? |
| 18:13.56 |
mafm |
I wasn't
involved in development after gsoc except for a bit towards the end
of last year, IIRC |
| 18:15.24 |
madant |
hippieindamakin8: kerala :) |
| 18:16.23 |
hippieindamakin8 |
madant, i
just googled you and ur current location is thrissur apparently
:) |
| 18:19.59 |
madant |
wow
:) |
| 18:20.10 |
madant |
well it is
around 40 kilometer off |
| 18:20.33 |
madant |
fears google |
| 18:20.38 |
hippieindamakin8 |
madant, cant
expect more from google maps :). |
| 18:20.56 |
hippieindamakin8 |
madant, that
must be an awesome picturesque country side then |
| 18:21.26 |
d-lo |
if you do a
traceroute to www.google.com, you will see that the primary DNS
server is www.sky.net ;) |
| 18:22.44 |
mafm |
madant:
you're in for another edition with a new proposal for
libpc? |
| 18:23.05 |
madant |
yep
:) |
| 18:23.25 |
madant |
god's own
country :) |
| 18:23.36 |
madant |
or
countryside as the case maybe :P |
| 18:24.30 |
mafm |
well, good
luck then :) |
| 18:24.41 |
madant |
mafm: yes,
would love to make some progress :) |
| 18:25.38 |
madant |
mafm: thank
you :) , i do need a lot of luck to stay on track :) |
| 18:28.59 |
mafm |
madant: what
are you doing at school, degree, master...? |
| 18:29.55 |
madant |
mafm:
masters |
| 18:30.17 |
madant |
mafm: you
planning on a masters after ur thesis ? |
| 18:30.18 |
hippieindamakin8 |
madant, where
? |
| 18:31.40 |
starseeker |
is starting to wonder if he'll need the constraint system to
resolve this. erk |
| 18:31.41 |
madant |
hippieindamakin8: i have two options :) 1
is IISc , 2 IIMB |
| 18:32.04 |
madant |
starseeker:
:) resolve what ? |
| 18:32.05 |
mafm |
madant: not
sure yet, I don't like much the opportunities in the univs around,
and I cannot easily move elsewhere in the next months |
| 18:32.40 |
hippieindamakin8 |
madant, in
architechture ? or smthing else like cs ? |
| 18:32.56 |
hippieindamakin8 |
i.e at
IISC |
| 18:33.03 |
madant |
IISc :
Sustainability IIMB : MBA :) |
| 18:33.14 |
starseeker |
madant:
looking at comparing two points with error bounds, deciding if they
are similar or not. In isolation that's pretty simple, but if
there are three or more points "in range" look out |
| 18:33.26 |
starseeker |
er
s/similar/the same/ |
| 18:33.58 |
madant |
starseeker:
did u see the discussion on checking the collinearity of three
points using the determinant ? |
| 18:34.36 |
hippieindamakin8 |
madant, wat
is this discussion abt ? |
| 18:34.50 |
madant |
wonders whether that would be any use here
though |
| 18:35.21 |
madant |
it was an
excerpt from Beautiful Code book |
| 18:35.30 |
starseeker |
madant: that
might help when it comes time to look at implementation techniques,
but first I need a decision methodology |
| 18:36.19 |
madant |
starseeker:
can you point me to the problem ? as in any doc /code ? i remember
seeing u and sean talking about it but didn't pay
attention |
| 18:36.32 |
starseeker |
i.e. given
3,4,...,n points with overlapping error bounds, how do I decide
which ones should be regarded as being the same point and which
should be treated as different? |
| 18:36.51 |
starseeker |
there are a
few notes in doc/TODO.BREP |
| 18:37.37 |
CIA-40 |
BRL-CAD:
03117.196.142.56 07http://brlcad.org * r1315
10/wiki/User:Homovulgaris: Proposal Draft Added |
| 18:38.05 |
madant |
starseeker:
error bounds? |
| 18:38.53 |
starseeker |
BRL-CAD has a
tolerance on dimensions - anything smaller than that tolerance can
be ignored when, for example, doing overlap checks |
| 18:39.24 |
starseeker |
so any point
has a value (x,y,z) |
| 18:39.51 |
starseeker |
x has a
tolerance or error bound of delta_x |
| 18:39.56 |
starseeker |
same for y
and z |
| 18:40.16 |
starseeker |
x, y, and z
themselves are presumably stored as floating point
numbers |
| 18:41.27 |
madant |
ok.. so
different points would be points which are further apart than
sqrt(delta_x^2+delta_y^2+delta_z^2) |
| 18:41.29 |
starseeker |
so given two
points (x1,y1,z1) and (x2,y2,z2), if their delta ranges overlap
they might need to be treated as being the "same" point |
| 18:42.14 |
starseeker |
madant:
maybe, but I'm not sure if the error bound is spherical or cubic in
x,y,z space |
| 18:42.36 |
hippieindamakin8 |
starseeker,
it is cubic in space |
| 18:42.47 |
starseeker |
that's been
my assumption |
| 18:42.55 |
hippieindamakin8 |
starseeker,
and it depends on the extent of overlap isnt it ? |
| 18:43.25 |
starseeker |
hippieindamakin8: it might. these are
the issues I'm trying to work through now |
| 18:43.35 |
madant |
hmm.. in
effec the check is whether (x1-delta_x1,x1+delta_x1) and
(x2-delta_x2,x2+delta_x2) intervals overlap right ? |
| 18:43.41 |
starseeker |
right |
| 18:43.43 |
madant |
and similarly
for other coordinates |
| 18:44.11 |
hippieindamakin8 |
starseeker,
cubic if error is the worst case |
| 18:44.29 |
starseeker |
but if one
point overlaps with two other points and those two other points
don't overlap, it makes no sense to treat both of those points as
being the same as the original point |
| 18:44.37 |
hippieindamakin8 |
*if error is
taken in the worst case |
| 18:44.52 |
madant |
hmm.. so if
there are n coordinates you the worst case is checking all the
C(n,2) combinations right ? |
| 18:44.59 |
starseeker |
A may equal
B, and A may equal C, but if B != C then A may NOT equal B AND
C |
| 18:45.37 |
hippieindamakin8 |
madant, rt
but split into regions |
| 18:45.40 |
starseeker |
madant: I'm
not sure - hopefully some sort of decision metric can be found, but
it might be that to correctly decide things such a worst case is
unavoidable |
| 18:45.43 |
hippieindamakin8 |
*the
space |
| 18:46.38 |
madant |
starseeker:
interesting problem ? did you find any literature on this
? |
| 18:46.58 |
starseeker |
madant: Not
yet. I've been looking, but it may be I don't know the correct
keywords |
| 18:46.58 |
madant |
s/interesting
problem ? / interesting problem ! :) |
| 18:47.50 |
starseeker |
it gets even
more complex if you allow different points to have different
deltas |
| 18:48.09 |
pacman87 |
starseeker:
have you looked at clustering algorithms? |
| 18:48.46 |
madant |
so in the
above scenario what do u want the result to be ? A,B and C all
"mutually" different |
| 18:49.25 |
starseeker |
madant:
that's one of the questions - what the "correct" answer should
be |
| 18:49.32 |
pacman87 |
if two points
are the same, do you treat that location as the mean of the two
points? |
| 18:49.53 |
starseeker |
pacman87: no
decision made about how to handle it yet :-) |
| 18:50.09 |
starseeker |
pacman87:
clustering? no I hadn't |
| 18:50.37 |
madant |
starseeker:
what is the final purpose of categorizing the points ? i mean is
the result to be used in some other process ? |
| 18:50.37 |
hippieindamakin8 |
starseeker,
why cant there be an algo which in its worst case is O(n^2), where
you check if each point lies in the error bound a point and go
checking for each point |
| 18:51.02 |
starseeker |
hippieindamakin8: That's probably what
will happen, or something like it |
| 18:51.09 |
hippieindamakin8 |
and this can
be worked upon using randomized algos |
| 18:51.19 |
pacman87 |
http://en.wikipedia.org/wiki/Cluster_analysis |
| 18:51.26 |
hippieindamakin8 |
or planar
subdivision and parallel analysis |
| 18:51.53 |
starseeker |
madant: When
we evaluate breps with a ray, we may hit edge cases where the
question of point equality will come up. If so, we want to have a
consistent procedure implemented that we can call |
| 18:52.55 |
starseeker |
pacman87:
Hmm, yeah, looks like I was thinking about clustering algorithms
without knowing what they were called :) |
| 18:54.20 |
hippieindamakin8 |
pacman87, yup
:P (i worked on k-means when working on my industrial
intern) |
| 18:54.24 |
pacman87 |
one of my
programming assignments covered it, but in the context of data
mining |
| 18:54.27 |
*** join/#brlcad boerrebj_
(n=boerrebj@ti0036a380-1283.bb.online.no) |
| 18:55.03 |
pacman87 |
off to class,
back later |
| 18:59.29 |
hippieindamakin8 |
starseeker,
similar to wat i said.. kmeans takes the worst possible time of
O(n^2) and the expected value is O(n) which isnt bad |
| 18:59.35 |
hippieindamakin8 |
and it is
easier to implement |
| 19:01.36 |
*** join/#brlcad boerrebj__
(n=boerrebj@ti0036a380-1776.bb.online.no) |
| 19:01.37 |
madant |
still can't figure out how k-means algorithm solves
starseeker's dilemma of what the result should
be |
| 19:02.13 |
hippieindamakin8 |
again ponders over the problem. |
| 19:22.15 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 19:22.15 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:22.15 |
*** join/#brlcad boerrebj__
(n=boerrebj@ti0036a380-1776.bb.online.no) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad boerrebj_
(n=boerrebj@ti0036a380-1283.bb.online.no) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad ``Erik
(n=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 19:22.15 |
*** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38)
[NETSPLIT VICTIM] |
| 19:22.46 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 19:22.46 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 19:22.46 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad CIA-40 (n=CIA@208.69.182.149.simpli.biz)
[NETSPLIT VICTIM] |
| 19:22.46 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT
VICTIM] |
| 19:22.46 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 19:22.46 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 19:25.12 |
hippieindamakin8 |
starseeker,
if we find out the intersections what next ? if i have found out
the combination of cubes in the space which overlap to some extent
or completely (provided they all have the same error ), there shall
be situations where A intersects B, B intersects C and A doesnt
intersect C. |
| 19:25.12 |
starseeker |
exactly |
| 19:25.39 |
hippieindamakin8 |
estimates that the above step takes approximately
O(nlogn) |
| 19:25.39 |
starseeker |
probably the
thing to do is to find the two closest points within the identified
subset, treat those as being the same, and follow the cascade of
consequences as far as other decisions |
| 19:25.39 |
starseeker |
if A is
closer to B than it is to C, set A=B and A!=C |
| 19:25.39 |
starseeker |
but "closer"
might not be enough |
| 19:25.39 |
madant |
starseeker:
as pacman87 asked in case two points are found to be the same do u
take their median to be the new point ? |
| 19:25.39 |
hippieindamakin8 |
starseeker,
the better thing would be divide the bounding box into a mesh of
cubes and then work on it ? |
| 19:25.39 |
starseeker |
the metric I
am considering is relative volume of overlap between A and B's
delta box vs. the same volume calculated for A and C |
| 19:25.39 |
starseeker |
madant: I
don't know |
| 19:25.39 |
starseeker |
hippieindamakin8: what do you
mean? |
| 19:25.40 |
hippieindamakin8 |
as in in each
cube all the points are approximated to a single point which is
either the centroid of those points or center of the
cube |
| 19:25.40 |
hippieindamakin8 |
and the size
of this smaller cube shall be the error bound |
| 19:26.04 |
starseeker |
hippieindamakin8: you're considering the
subcase of many points all within the same collection of bounding
boxes? |
| 19:26.41 |
hippieindamakin8 |
i meant one
bounding box (bounding all the space into
consideration) |
| 19:26.58 |
starseeker |
needs to make an organized illustration of the various cases
for n=3 points to think about |
| 19:27.35 |
starseeker |
hippieindamakin8: That might result in
more point consolidation that we want |
| 19:28.43 |
hippieindamakin8 |
starseeker,
yeah true but the size of the smaller boxes can be increased to
decrease the extent of consolidation obtained |
| 19:29.59 |
starseeker |
hmm. I'll
have to think some more |
| 19:30.13 |
hippieindamakin8 |
tries to look into the 'approximation algos for geometry '
literature if he can find smthing which can help |
| 20:16.13 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-202.dclient.hispeed.ch) |
| 20:34.49 |
CIA-40 |
BRL-CAD:
03r_weiss * r34121 10/brlcad/trunk/src/rt/ (main.c opt.c
viewarea.c): updates to rtarea adding center
computations |
| 20:46.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-64.sbndin.btas.verizon.net) |
| 21:46.26 |
brlcad |
alright
weiss, progress! |
| 22:00.34 |
madant |
brlcad: weiss
new developer ? |
| 22:01.46 |
Ralith |
hey
mafm! |
| 22:01.57 |
Ralith |
I see you've
seen my proposal. |
| 22:01.59 |
mafm |
hi
Ralith |
| 22:01.59 |
Ralith |
any
comments? |
| 22:02.02 |
madant |
ah the gui
heroes meet :D |
| 22:02.09 |
mafm |
gui
heroes |
| 22:02.13 |
Ralith |
hehe |
| 22:02.16 |
Ralith |
I haven't
earned that yet. |
| 22:02.16 |
mafm |
...
:P |
| 22:02.19 |
mafm |
1
sec |
| 22:15.00 |
*** join/#brlcad kanzure
(n=bryan@66.112.232.153) |
| 22:20.51 |
brlcad |
mafm: though
you had good reason (wrt, "I wasn't involved in development after
gsoc except for a bit towards the end of last year"), personal
reasons |
| 22:21.03 |
brlcad |
hopefully
you'll be knee deep in code here again soon ;) |
| 22:21.26 |
brlcad |
someone needs
to help weiss with his patch |
| 22:21.42 |
brlcad |
that needs to
be reverted/fixed |
| 22:21.46 |
starseeker |
somebody
rang? ;-) |
| 22:21.51 |
starseeker |
what's
busted? |
| 22:21.58 |
starseeker |
I haven't
tried building yet |
| 22:28.15 |
starseeker |
hmm - builds
OK, doesn't seem to crash... |
| 22:28.40 |
brlcad |
it's not a
compile problem |
| 22:28.47 |
brlcad |
the patch has
some problems |
| 22:28.51 |
brlcad |
I sent a note
to the list |
| 22:29.21 |
brlcad |
iirc, I
*think* he's on the list -- if he's not, he should be |
| 22:30.02 |
brlcad |
madant: yeah,
very green |
| 22:31.00 |
starseeker |
ah, yes I see
it |
| 22:33.42 |
brlcad |
starseeker:
and it's kinda important -- I was going to tag the source release
later tonight |
| 22:33.49 |
brlcad |
most of the
changes shouldn't take long at all |
| 22:34.18 |
starseeker |
revert til
after the tag, or fix? that's user visible if left in |
| 22:34.19 |
brlcad |
and that'd be
a good one to make the release so it can be communicated with s2
golks |
| 22:34.22 |
starseeker |
k |
| 22:34.35 |
brlcad |
yeah, I
wouldn't leave it in for release |
| 22:34.41 |
brlcad |
I'd revert if
he can't fix it today |
| 22:34.57 |
brlcad |
in fact I'll
just revert it right now |
| 22:35.03 |
starseeker |
he's gone, so
it'd be up to him seeing it on the list tonight |
| 22:35.07 |
starseeker |
k |
| 22:35.36 |
Ralith |
brlcad:
interesting concepts on that firefox image |
| 22:35.51 |
Ralith |
doesn't look
quite as powerful as what you had in mind, but I certainly see the
similarities |
| 22:36.06 |
brlcad |
it's not as
powerful just because all they have to work with is a web
browser |
| 22:36.14 |
brlcad |
and they
don't have inherint commands already |
| 22:36.23 |
brlcad |
we already
have hundreds to work with |
| 22:36.31 |
mafm |
brlcad: so
what's that executive decision? |
| 22:37.01 |
mafm |
Ralith:
probably you worked with the code more than me lately |
| 22:37.03 |
brlcad |
mafm: that we
need a better gender ratio in this channel |
| 22:37.12 |
brlcad |
it's a g'damn
sausage fest in here |
| 22:37.16 |
brlcad |
j/k
;) |
| 22:37.21 |
mafm |
hot chicks?
that's fine for me :P |
| 22:37.43 |
mafm |
Ralith:
anyway, if I can be of any help let me know, and I'll try to keep
an eye |
| 22:37.53 |
Ralith |
mafm: I've
been toying with the build system more than the actual code,
really |
| 22:37.59 |
Ralith |
oh, that
reminds me |
| 22:38.05 |
Ralith |
mafm: why did
you require Ogre 1.7.0? |
| 22:38.21 |
Ralith |
it seems to
work fine on 1.6.1 |
| 22:38.31 |
mafm |
1.7.0 as
opposed to stable releases? |
| 22:38.38 |
mafm |
IIRC there
was something like 1.4 stable by that time |
| 22:38.55 |
brlcad |
mafm: there's
a couple things I still intend to check on, but basically that we
should just run with making Qt work |
| 22:38.56 |
mafm |
and they
didn't have some functionalities that RBGui needed by
then |
| 22:39.07 |
mafm |
so I used
trunk, or something like that |
| 22:39.15 |
brlcad |
only on the
thin client front, though, not the entire application back-end or
other tools for now |
| 22:39.42 |
mafm |
I
see |
| 22:40.01 |
brlcad |
still need to
verify a couple things with regards to a few widgets |
| 22:40.04 |
mafm |
I never used
Qt, but other than using a precompiler, I heard that it's not very
difficult |
| 22:40.09 |
brlcad |
and how it
integrates with ogre |
| 22:40.25 |
brlcad |
the
precompiler is the one big hassle that leaves a bad
taste |
| 22:40.30 |
mafm |
last time
that I checked RBGui (january I think) it was in the same
state |
| 22:40.37 |
brlcad |
should see if
there are any facilities to avoid using it |
| 22:40.47 |
mafm |
so, well,
it's nice but... :) |
| 22:40.48 |
brlcad |
yeah, I'm not
surprised |
| 22:40.56 |
brlcad |
rbgui being
dead wasn't a problem :) |
| 22:41.35 |
brlcad |
it's more
just where we'd end up after it's fully customized, simple widgets
with limited behavior |
| 22:41.56 |
Ralith |
brlcad: I get
the impression that the precompiler contributes a lot to the ease
of development with Qt |
| 22:42.06 |
Ralith |
what's so
unappetising about it? |
| 22:42.23 |
brlcad |
I'd see us
wasting a lot of cycles making a hundred dumb things work (like we
do with Tk now) like getting select/copy/paste working on a text
widget |
| 22:43.06 |
brlcad |
Ralith: I
suppose I just haven't drank the coolaid yet -- I like my sources
to compile with a preprocessor and a compiler |
| 22:43.09 |
mafm |
I had thought
about getting rid of Mocha for one, I think that RBGui uses only a
few simple classes from it... but if it's not going to be used, one
thing less to worry abount :) |
| 22:43.31 |
Ralith |
brlcad: I
certainly understand the sentiment, but I wouldn't write it off
immediately. |
| 22:44.03 |
Ralith |
mafm: yeah,
before I realized how apt Qt might be, I saw that as one of the
first things I'd try to work on |
| 22:44.11 |
Ralith |
much of what
mocha provides is even already in BRL-CAD somewhere. |
| 22:44.23 |
brlcad |
Ralith: I'm
not writing it off, I just don't like things that lock you in to
more than an API |
| 22:44.54 |
brlcad |
similar to
the openthreads declarations, pragmas, and other tool-specific
language overlays that some projects run with |
| 22:46.10 |
starseeker |
thinks he remembers the QT precompiler being fairly essential
for hiding a LOT of really nasty details, but it's been a
while |
| 22:46.50 |
starseeker |
last time I
was looking at it was when someone was trying to integrate lisp
CFFI with QT, iirc |
| 22:47.09 |
Ralith |
given the
degree to which Qt is an entire application framework, rather than
just a widget toolkit, I'd imagine general dependency on it might
be hard to avoid if we want to take advantage of all that it
offers. |
| 22:47.43 |
CIA-40 |
BRL-CAD:
03brlcad * r34122 10/brlcad/trunk/src/rt/ (main.c opt.c
viewarea.c): revert r34121 due to a variety of issues given I'm
about to tag a source release. most pertinent to the release is the
addition of an rt option (-y) that doesn't apply to any of the
other raytrace applications. |
| 22:49.07 |
mafm |
Ralith:
what's your primary OS? FreeBSD? |
| 22:49.15 |
Ralith |
mafm: linux,
at the moment. |
| 22:49.22 |
Ralith |
freebsd
laptop died and I had to get a new system up quick |
| 22:50.31 |
mafm |
I
see |
| 22:51.03 |
mafm |
RBGui was
easy to build for me (with the patches), but that was a while ago
:D |
| 22:51.09 |
Ralith |
patches? |
| 22:51.36 |
mafm |
yep,
src/other includes original RBGui with further patches |
| 22:51.43 |
mafm |
and the same
for Mocha |
| 22:51.55 |
mafm |
I think that
OIS and OGRE did not need them |
| 22:52.00 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 22:52.25 |
mafm |
they were
basic patches implementing little stuff, cleaning headers,
etc |
| 22:52.52 |
Ralith |
oh, I'd
forgotten about that. |
| 22:52.59 |
Ralith |
that explains
that. |
| 22:54.13 |
mafm |
+float
PosixPlatformManager::getDoubleClickTime( ) |
| 22:54.15 |
mafm |
+{ |
| 22:54.16 |
mafm |
+ //
... |
| 22:54.18 |
mafm |
<PROTECTED> |
| 22:54.19 |
mafm |
:) |
| 22:54.38 |
mafm |
missing
things like that, it didn't even compile -- I guess that nobody had
tested it in linux before releasing |
| 22:55.18 |
mafm |
they were
small things like that IIRC, anyway, it must be in SVN logs shortly
after importing |
| 22:56.52 |
Ralith |
yeah, I had
to add that in too |
| 22:59.13 |
``Erik |
nice |
| 23:01.14 |
mafm |
I think that
I filled some of those with real implementations, but well
:) |
| 23:01.30 |
mafm |
as I said, it
must be in SVN |
| 23:01.50 |
mafm |
does Qt
render inside the opengl context, or around it? |
| 23:01.56 |
Ralith |
it can do
either |
| 23:02.04 |
Ralith |
I plan to do
the former |
| 23:02.15 |
mafm |
nice |
| 23:02.36 |
mafm |
have you
checked some example application or so? |
| 23:02.53 |
Ralith |
it's all
linkified in my official gsoc application |
| 23:02.58 |
Ralith |
lemme dig
that up |
| 23:03.25 |
Ralith |
http://doc.trolltech.com/4.5/demos-boxes.html |
| 23:03.28 |
mafm |
oh, I don't
have access to it, only to the wiki |
| 23:05.51 |
mafm |
goody |
| 23:05.58 |
madant |
Ralith: wow @
the boxes O.o |
| 23:06.03 |
Ralith |
? |
| 23:06.12 |
mafm |
seems like a
good replacement of RBGui for this task |
| 23:06.14 |
mafm |
:) |
| 23:06.17 |
Ralith |
that's my
thought. |
| 23:08.25 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1316
10/wiki/Google_Summer_of_Code: update apply url to socghop
site |
| 23:08.29 |
mafm |
btw Ralith,
what/where are you studying? |
| 23:09.25 |
mafm |
for some
reason I thought that you were already a teacher or something like
that, when you told me last year that you were interested in the
project |
| 23:09.49 |
Ralith |
people always
seem to get that kind of impression from me |
| 23:09.53 |
Ralith |
probably 'cuz
I'm such a grammar nazi |
| 23:10.35 |
Ralith |
actually, I
only just got accepted to a college; last year I didn't even
qualify for SoC, or I would have applied then, too. |
| 23:11.20 |
brlcad |
mafm: if I'm
undertanding everything I've read to date, especially since 4.0,
they've moved towards rendering everything through a generalized
backend that gives them an opengl context to work with |
| 23:11.34 |
brlcad |
allowing the
easily zoomable interfaces, simple vector scaling, accelerated
rendering |
| 23:11.58 |
brlcad |
but even if
they didn't, yeah -- our entire window should be opengl, that's
still the goal |
| 23:12.08 |
brlcad |
one big
context with widgets in it |
| 23:12.09 |
madant |
this qt looks
nothing like my "memory" of Qt :P |
| 23:12.20 |
Ralith |
hehe |
| 23:12.39 |
brlcad |
madant: kde
gives it a bad name ;) |
| 23:13.28 |
madant |
is a core gnome-er .. well now xmonader :) |
| 23:13.54 |
mafm |
vector
scaling... one of the things that you wanted last year already
:) |
| 23:13.57 |
madant |
i always feel
kde looks childish :P |
| 23:14.32 |
Ralith |
there we
go |
| 23:14.34 |
Ralith |
application
linkified |
| 23:14.35 |
CIA-40 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1317 10/wiki/User:Ralith: Added links from GUI SoC
application |
| 23:19.12 |
madant |
Ralith: how's
reprap ;) ? |
| 23:19.47 |
Ralith |
madant: in
general or in particular? |
| 23:19.55 |
madant |
in particular
;) |
| 23:20.29 |
Ralith |
my machine's
nearly finished |
| 23:20.41 |
madant |
awesome
:) |
| 23:20.42 |
Ralith |
just need to
wire things up and build the extruder barrel |
| 23:21.03 |
madant |
hah.. then
onto a few kids ;) |
| 23:21.41 |
mafm |
I read about
reprap somewhere in the last few days, can't remember
where |
| 23:22.45 |
mafm |
Ralith: maybe
the fact that you didn't apply for soc gave me the impression of
being a post-student :D |
| 23:22.59 |
Ralith |
could
be |
| 23:29.21 |
brlcad |
several of
the guys I work with are technically students and a decade or two
older than I .. you can be a student at any age / stage of life
;) |
| 23:32.33 |
Ralith |
not much is
as rewarding as learning about cool stuff, after all. |
| 23:38.41 |
madant |
will be back after a 5km run : 5 am here
:D |
| 23:44.42 |
brlcad |
madant:
awesome |
| 23:44.53 |
brlcad |
see you in 20
minutes ;) |
| 23:52.07 |
mafm |
I used to go
to exams with people of 70 around me |
| 23:53.32 |
brlcad |
my professors
for some courses were students with me in other courses at the
university |
| 23:54.21 |
Ralith |
neat! |
| 23:55.21 |
brlcad |
I knew I was
over my head when my calc III professor was in the same course with
me on (graduate level) game theory .. that was three weeks of utter
hell |
| 23:55.53 |
brlcad |
I would have
had to drop half my workload just to keep up |
| 23:57.41 |
*** join/#brlcad andrecastelo
(n=andrecas@189.71.13.123) |
| 23:59.29 |
brlcad |
howdy
andrecastelo |
| 00:02.02 |
mafm |
lol
:) |
| 00:02.04 |
mafm |
hi
andrecastelo |
| 00:02.24 |
mafm |
in my case,
it's because many ppl take advantage at distance learning just for
fun |
| 00:02.48 |
mafm |
or, in the
case of businessman or polititians, to get a degree as lawyers or
so |
| 00:03.23 |
mafm |
so half of
ppl is more or less young ppl as in other unis, specially for
engineerings as me |
| 00:03.35 |
mafm |
but other ppl
are of old age |
| 00:04.07 |
mafm |
there are
even programs for inmates in prisons, and ppl working abroad in
different places of Europe and America |
| 00:04.12 |
mafm |
it's funny
:) |
| 00:09.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-64.sbndin.btas.verizon.net) |
| 00:12.13 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 00:13.50 |
andrecastelo |
hi brlcad,
mafm :D |
| 00:15.13 |
mafm |
andrecastelo:
applying for gsoc? |
| 00:28.40 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1318
10/wiki/Google_Summer_of_Code/Checklist: expand the checklist into
four main sections, one during the application period, then before
coding begins, and then while coding, then after it's all
done |
| 00:30.02 |
Ralith |
yay! |
| 00:32.55 |
andrecastelo |
mafm: nope
:( |
| 00:33.00 |
andrecastelo |
mafm:
you? |
| 00:33.28 |
madant |
took 23:30 :| |
| 00:34.48 |
mafm |
andrecastelo:
not sure yet, and not sure if as mentor or student... still
checking project ideas and so on, and thinking about my
future |
| 00:34.52 |
mafm |
andrecastelo:
why not? |
| 00:35.19 |
madant |
howdy castelo
;) |
| 00:35.21 |
mafm |
madant: you
need to drink more tea :P |
| 00:35.34 |
madant |
is a coffee person |
| 00:35.46 |
madant |
where is
pacman87 :) that would make it a perfect reunion :) |
| 00:35.59 |
pacman87 |
right here
:D |
| 00:36.12 |
madant |
andrecastelo:
thinking about future is never easy i guess |
| 00:36.18 |
mafm |
madant:
heretic! |
| 00:36.23 |
madant |
pacman87: yay
:P |
| 00:36.30 |
mafm |
I love coffee
too, too much :( |
| 00:36.50 |
madant |
why the sad
face . coffee is life :) |
| 00:36.56 |
madant |
pacman87: how
is school . |
| 00:37.22 |
andrecastelo |
madant: true,
perfect reunion :) |
| 00:38.14 |
brlcad |
hehe |
| 00:38.14 |
madant |
and did
something happen in the direction of the clustering
discussion |
| 00:38.14 |
pacman87 |
madant: busy.
i'm working on making tetris with a 6811, and writing a darknet
F2F client |
| 00:38.14 |
mafm |
madant:
because I can't drink as much as I would like |
| 00:38.42 |
pacman87 |
madant: i
think the clustering discussion was more an idea-gathering than a
decide-something |
| 00:39.00 |
yukonbob |
hello,
cadheads |
| 00:39.50 |
madant |
pacman87:
6811 sounds kewl.. :) |
| 00:40.32 |
pacman87 |
512 B ram,
512 B rom |
| 00:40.53 |
madant |
haha .. and a
lot of tinkering around ;) |
| 00:40.53 |
pacman87 |
we're
interfacing external eeprom using the address/data bus |
| 00:41.10 |
madant |
ah it is like
a project or a competition ? |
| 00:41.16 |
pacman87 |
a bit of
both |
| 00:41.22 |
pacman87 |
it's for
class |
| 00:41.26 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:41.30 |
pacman87 |
and there's a
competition at the end |
| 00:41.31 |
madant |
whats the F2F
client for |
| 00:41.40 |
pacman87 |
concurrent
and distributed systems programming |
| 00:41.53 |
pacman87 |
it's a 'chose
your own project' |
| 00:41.56 |
brlcad |
the 6811 is
actually faster than the first hardware that ran brl-cad .. memory
not far off too |
| 00:42.15 |
brlcad |
it was just
bigger than a refrigerator back then |
| 00:42.19 |
madant |
brlcad: what
was that monster :D |
| 00:42.27 |
``Erik |
hrm,
pdp11/70? |
| 00:43.26 |
pacman87 |
i want to
find a graphics LCD panel that i can interface directly to the
display RAM from the address/data bus |
| 00:43.34 |
pacman87 |
memory-mapped
IO style |
| 00:43.43 |
pacman87 |
but i haven't
found any drivers that do that yet |
| 00:44.38 |
``Erik |
there'll
still have to be some kinda controller in the mix to translate,
pacman :/ lcd's and memory work a bit differently |
| 00:45.12 |
``Erik |
probably be
easier to just glue i2c components together or
somethin' |
| 00:45.22 |
madant |
has always wondered whether higher polyomino games would be
nice |
| 00:45.58 |
pacman87 |
``Erik: yeah,
i know; i'm looking for a controller that will let me talk to the
display ram, and the controller syncs the display ram with the LCD
panel |
| 00:45.59 |
``Erik |
(6811 or
6812? I thought motorola discontinued 6811's in favor of 6812's a
long time ago, a 6812 can run 6811 code 'and then
some') |
| 00:46.38 |
``Erik |
<-- did
some assembly and low level C on both those chips back in college
:) fun stuff |
| 00:46.47 |
pacman87 |
6811. we use
the 6812 for most of the stuff we do, but the point of this is to
do external memory |
| 00:47.29 |
``Erik |
hm, I thought
you could get 6812's with no internal memory |
| 00:48.04 |
``Erik |
has been tempted to figure out how to get his pics talking to
old simm ram |
| 00:48.07 |
pacman87 |
it's also
possible that UT has some big stock of 6811s from before they
stopped making them |
| 00:48.39 |
pacman87 |
and our 6812s
are on dev boards with serial monitors to program them |
| 00:51.30 |
``Erik |
of course,
I've also been tempted to buy a 68040 and build an old school unix
box out of it, I seem to get tempted an awful lot and act an awful
little ;) |
| 00:53.44 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.209.20.dynamic.adsl.gvt.net.br) |
| 01:02.11 |
mafm |
night, folks
:) |
| 01:03.30 |
Lezard |
well i`m
interested in one of the project ideas, could you guys give me more
information in the MGED User Interface Improvements
project? |
| 01:04.44 |
brlcad |
Lezard:
thanks, that helps :) |
| 01:05.03 |
brlcad |
so our main
modeler right now is called MGED |
| 01:05.42 |
brlcad |
it's actually
probably best explained by just running it -- it's not easy to
learn, not easy interface to discvoer |
| 01:06.14 |
brlcad |
basically, if
you look at the screenshots on http://brlcad.org/gallery/ under
the screenshots section, you'll see various pictures of it
running |
| 01:06.37 |
brlcad |
meant here |
| 01:07.15 |
Lezard |
looking at the screenshots |
| 01:07.37 |
Lezard |
well... i
really agree that you need a more friendly interface, at least from
what i see with the screenshots |
| 01:09.27 |
brlcad |
the interface
is being overhauled completely |
| 01:09.39 |
brlcad |
that has been
in the works for a while and was a gsoc project last
year |
| 01:09.47 |
Lezard |
hmm |
| 01:09.51 |
brlcad |
but in the
meantime, mged can and should still be made easier to
use |
| 01:09.51 |
Lezard |
did anyone
apply? |
| 01:10.14 |
brlcad |
just one
person has applied to continue that project again this year
thusfar |
| 01:10.31 |
Ralith |
waves |
| 01:10.37 |
Lezard |
hello Ralith
o/ |
| 01:10.41 |
Ralith |
hullo |
| 01:11.04 |
Lezard |
My main
problem is that i`m not a Tcl/Tk expert... |
| 01:11.19 |
Ralith |
I'm sure it's
not hard to learn |
| 01:11.29 |
Lezard |
I`m a
researcher in my university in the HCI lab |
| 01:11.32 |
brlcad |
Lezard: mged
is about 1/3rd tcl/tk and about 2/3rds C |
| 01:11.55 |
Lezard |
so i got
kinda interested in the project, after all i could test my
skills |
| 01:11.56 |
brlcad |
so much of
what can be done to make it easier to use can be done on the C
side |
| 01:12.09 |
*** join/#brlcad objorn
(n=safar@unaffiliated/objorn) |
| 01:12.22 |
brlcad |
like better
introspection, help system, cleaned up command layer,
etc |
| 01:12.42 |
brlcad |
the gui
aspects are tcl/tk though -- the new system is where that changes
it up to C/C++ |
| 01:13.09 |
Lezard |
well i`m more
interested in the gui aspects |
| 01:13.20 |
brlcad |
having
someone with HCI experience take a hack at mged would be phenomenal
-- you'd have a pretty big opportunity to make a big
impact |
| 01:13.45 |
brlcad |
there are
something on the order of 200k downloads a year, about 20k a month
that would benefit from better usability ;) |
| 01:14.06 |
Ralith |
I'd also love
to have your input on my work on the new system, if I get
accepted |
| 01:14.40 |
brlcad |
yeah, there's
the guy that has that application in for continuing last year's
work thusfar ;) |
| 01:15.17 |
Lezard |
so you think
that even if my Tcl/Tk skills aren`t very advanced, i should apply
? |
| 01:15.23 |
objorn |
where are the
32bit builds? |
| 01:15.26 |
brlcad |
starseeker:
you know any word about whether weiss is working on fixing
it? |
| 01:15.38 |
brlcad |
objorn: for
binary builds, you have to go back a few releases |
| 01:15.41 |
objorn |
i only see
64bit
http://sourceforge.net/project/showfiles.php?group_id=105292&package_id=113559 |
| 01:15.45 |
objorn |
okay |
| 01:15.45 |
Ralith |
Lezard:
certainly; GSoC's all about learning. |
| 01:16.05 |
brlcad |
generally
recommend just building the latest from source regardless if you
can |
| 01:16.06 |
Ralith |
Lezard: of
course, you might want to look over some docs on it beforehand so
you have some idea what you're getting into |
| 01:16.28 |
brlcad |
Lezard: what
languages would you say you know pretty well? |
| 01:16.59 |
brlcad |
tcl/tk is a
frustrating blessing .. sometimes great to work with and sometimes
makes you go looking for a shotgun |
| 01:17.13 |
Lezard |
well, i`m
confident in my php and pascal, my C is about average |
| 01:17.26 |
Lezard |
as my
python |
| 01:17.36 |
brlcad |
tcl's not
"too" dissimilar from php |
| 01:18.12 |
madant |
Lezard: php
and pascal , interesting combination |
| 01:18.18 |
brlcad |
the syntax is
definitely different, check out http://www.tcl.tk/about/language.html |
| 01:18.43 |
madant |
Lezard: what
do / did u do in pascal ? |
| 01:21.15 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 01:22.30 |
Lezard |
madant: Well,
last thing i did in pascal was a program to manage a
store |
| 01:22.31 |
brlcad |
typ0: so the
iges converter.. have you worked with iges before? |
| 01:22.44 |
Lezard |
nothing too
complicated i guess... |
| 01:22.58 |
brlcad |
typ0:
http://en.wikipedia.org/wiki/IGES
has a link to the spec iirc |
| 01:23.04 |
typ0 |
thanks |
| 01:23.08 |
typ0 |
didn't work
with it before |
| 01:23.28 |
typ0 |
but i can use
the student bonding period to study the current converter source
code |
| 01:23.34 |
madant |
Lezard:
hehe.. not at all. I was just asking since pascal is a relatively
uncommon language skill ;) |
| 01:23.34 |
typ0 |
and
familiarize myself with the format |
| 01:23.42 |
Lezard |
sorry if i
took a long time to answer, i`m doing the laundry |
| 01:23.52 |
Lezard |
well, yeah, i
learned it in my last university... |
| 01:24.24 |
Lezard |
used it for
some programs in class, and to code that managing program to a
friend |
| 01:24.47 |
brlcad |
madant:
actually I think it's pretty common (for some of us older folk) ..
just not one many will admit to knowing/using ;) |
| 01:24.56 |
brlcad |
often an
"intro to programming" language ;) |
| 01:25.12 |
Lezard |
Agreed |
| 01:25.27 |
Lezard |
I know other
languages as well, but it has been sometime since i
code... |
| 01:25.28 |
madant |
brlcad: :)
yeah i remember a friend of mine having to deal with pascal for
some algorithms which were written a decade ago :) |
| 01:25.37 |
madant |
er .. make it
two decades ago :) |
| 01:26.03 |
Lezard |
But i know
that at least my algorithms logic is still fine... at least was
last year in the Coding Arena... |
| 01:26.06 |
madant |
I hear it is
pretty good for mathematical stuff / |
| 01:26.08 |
madant |
? |
| 01:26.08 |
Lezard |
were |
| 01:28.12 |
*** join/#brlcad deeeffache
(n=deeeffac@adsl-99-145-15-192.dsl.emhril.sbcglobal.net) |
| 01:28.17 |
madant |
had an introduction to computers in LOGO |
| 01:29.05 |
Lezard |
Man, i should
be sleeping |
| 01:29.13 |
Lezard |
its going to
be a long night |
| 01:29.36 |
madant |
Lezard: gn,
do come back if u need any help regarding brl-cad |
| 01:30.00 |
Lezard |
I`m not goint
to sleep, i need to finish some stuff for my class
tomorrow |
| 01:30.04 |
brlcad |
Lezard: a
little piece of you dies every time you sleep! |
| 01:30.19 |
Lezard |
agreed |
| 01:30.22 |
madant |
agrees with this philosophy of brlcad's :P |
| 01:30.23 |
brlcad |
thinks that will be one of his new phrases worth repeating ad
infitum |
| 01:30.48 |
brlcad |
hello
deeeffache |
| 01:30.58 |
deeeffache |
hola |
| 01:31.28 |
brlcad |
g'dammits ..
cruise control is stuck again |
| 01:32.50 |
Ralith |
madant:
what're you applying for, again? |
| 01:33.32 |
madant |
Ralith:
further work in libpc :) http://brlcad.org/wiki/User:Homovulgaris |
| 01:33.55 |
Ralith |
oo, that
stuff! |
| 01:33.56 |
Ralith |
awesome! |
| 01:33.57 |
Ralith |
:D |
| 01:34.46 |
madant |
i think the
gui will be more visually appealing not to mention awesome
:) |
| 01:34.53 |
Ralith |
is looking forward to having that working |
| 01:35.10 |
Ralith |
eh, the GUI's
worthless without a powerful backend |
| 01:35.33 |
Ralith |
it's just
there to hold people's attention long enough to become comfortable
with the package |
| 01:35.34 |
madant |
Ralith: which
univ do u go to ? |
| 01:35.59 |
Ralith |
not actually
in univ yet; turns out SoC lets you in if you've got an acceptance
letter. |
| 01:36.25 |
``Erik |
*readreadread* pascal pascal, or
delphi? |
| 01:36.42 |
Ralith |
I do look
forward to making a shiny and usable GUI, but the GUI is an
enabler |
| 01:37.07 |
Ralith |
the point of
BRL-CAD is, after all, not just to model things. |
| 01:37.16 |
brlcad |
visually
appealing AND awesome |
| 01:37.22 |
Ralith |
hehe |
| 01:37.26 |
brlcad |
we could just
name the binary "awesome" |
| 01:37.36 |
Ralith |
isn't there
already a window manager called that? |
| 01:37.42 |
brlcad |
ah, yeah,
probably ;) |
| 01:37.46 |
``Erik |
teh-awesom3z.7.14.4.tar.bz2 |
| 01:38.18 |
Ralith |
aw3d. Reads
as 'awed' |
| 01:38.29 |
Lezard |
brb |
| 01:38.33 |
Lezard |
going to cook
my dinner |
| 01:38.37 |
brlcad |
yeah,
actually 'awesome' wm has a lot of the same usability
considerations as the new gui |
| 01:38.45 |
Ralith |
hehe |
| 01:39.02 |
brlcad |
similar HCI
backings |
| 01:39.08 |
Ralith |
I guess that
kind of design is just inherently awesome. |
| 01:43.33 |
brlcad |
has the munchies |
| 01:44.03 |
brlcad |
debates
hitting up the bar down the street for some
satisfaction |
| 01:49.03 |
brlcad |
non-overlapping windows, everything can be
performed with a keyboard, swappable contexts/tabs/tiles, automatic
default unobscured layout arrangement, .. |
| 01:49.13 |
brlcad |
reminding himself out loud |
| 02:00.24 |
brlcad |
starseeker:
yeah, saw the start of that :) pretty cool |
| 02:00.34 |
brlcad |
starseeker:
so was reading your brep notes |
| 02:00.44 |
brlcad |
heh,
gmta |
| 02:02.44 |
yukonbob |
http://pastebin.ca/1377525 |
| 02:03.02 |
brlcad |
howdy
yukonbob |
| 02:03.05 |
yukonbob |
:) |
| 02:03.26 |
brlcad |
yukonbob:
er.. you're running autoconf there |
| 02:03.27 |
yukonbob |
Noteable for
above paste: NetBSD 5_RC3, pkgsrc. |
| 02:03.31 |
brlcad |
that won't
work |
| 02:03.38 |
brlcad |
needs to be
the full toolchain |
| 02:03.41 |
brlcad |
./autogen.sh |
| 02:03.45 |
yukonbob |
nods |
| 02:03.49 |
yukonbob |
will continue
from there :) |
| 02:04.07 |
brlcad |
more
specifically, if you want to do it manually, you're missing
aclocal |
| 02:04.26 |
brlcad |
there's a
comment in autogen.sh some ways down that describes the manual
steps |
| 02:04.36 |
brlcad |
lists them
out |
| 02:04.52 |
brlcad |
autoreconf
should do the trick too with the right options |
| 02:05.26 |
yukonbob |
will poll the tools; thx for the directional
hint |
| 02:06.29 |
brlcad |
any reason
you're not running autogen.sh ? |
| 02:07.01 |
yukonbob |
brlcad: is
wrapped in old(er) config I had for pkgsrc... need to give it some
hints. |
| 02:07.29 |
brlcad |
hm? |
| 02:07.49 |
brlcad |
ah, you mean
you have a pkgsrc target that is set up to run autoconf directly
like that? |
| 02:07.55 |
yukonbob |
yup
:) |
| 02:08.00 |
brlcad |
that
shouldn't have ever worked... |
| 02:08.03 |
yukonbob |
I'll give it
more specific hints... |
| 02:08.23 |
brlcad |
maybe from a
source checkout after aclocal had already ran |
| 02:08.38 |
brlcad |
er,
s/checkout/tarball/ |
| 02:08.50 |
brlcad |
but still..
unusual |
| 02:08.52 |
yukonbob |
brlcad: good
guess... |
| 02:09.41 |
yukonbob |
I've
certainly had the whole affair successfully wrapped in pkgsrc
before, including ripping out all in-tree options like Tcl, ITcl,
Tk, various gfx libs, etc., etc. |
| 02:10.07 |
yukonbob |
just working
on re-implementing with "modern" co |
| 02:10.14 |
brlcad |
should be
running either "autoreconf -i -f -I m4" or autogen.sh |
| 02:10.14 |
yukonbob |
s/co/checkout/ |
| 02:10.19 |
yukonbob |
nods |
| 02:10.36 |
yukonbob |
will retry
l8r tonight... |
| 02:10.40 |
brlcad |
ideally the
latter so we can control it ;) |
| 02:10.52 |
yukonbob |
noted |
| 02:10.59 |
yukonbob |
gets kicked out of cafe... |
| 02:11.06 |
brlcad |
oh
noes! |
| 02:11.11 |
yukonbob |
:) |
| 02:11.12 |
brlcad |
ze
coffeee! |
| 02:11.19 |
yukonbob |
chat later,
brl-nerds |
| 02:11.24 |
brlcad |
cya
geek |
| 02:16.16 |
*** join/#brlcad typ0_
(n=coder@um-sd06-125-2.uni-mb.si) |
| 02:19.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-64.sbndin.btas.verizon.net) |
| 02:48.11 |
objorn |
brl-cad is
simply 400 applications... |
| 02:49.13 |
objorn |
-simply |
| 02:49.17 |
objorn |
i did not
realize this |
| 02:49.30 |
objorn |
now i'm
looking at the wiki trying to figure out how to use it |
| 02:51.33 |
objorn |
ah,
mged |
| 02:51.49 |
objorn |
brlcad/bin$
./mged |
| 02:51.51 |
objorn |
./mged: error
while loading shared libraries: libtermio.so.19: cannot open shared
object file: No such file or directory |
| 02:52.24 |
objorn |
i downloaded
the packages and haven't done ./configure, make, or make
install |
| 02:52.44 |
objorn |
but i also
can't find autogen.sh using find . -name autogen.sh |
| 02:53.13 |
objorn |
in the brlcad
folder |
| 03:04.49 |
brlcad |
huh, objorn
where'd you get a source tarball from? |
| 03:05.37 |
objorn |
i'm guessing
it's binary |
| 03:05.48 |
objorn |
i got the
install instructions confuesed |
| 03:06.33 |
starseeker |
brlcad:
here's the ascii art in the TODO.BREP taken a bit further:
http://bzflag.bz/~starseeker/points.pdf |
| 03:06.38 |
objorn |
so putting
brlcad/ in /usr will solve the problem? |
| 03:06.54 |
objorn |
is highly considering just downloading from
source |
| 03:06.56 |
brlcad |
yeah |
| 03:07.12 |
brlcad |
if this is
for gsoc, you should start from a source chekcout |
| 03:07.44 |
objorn |
it's for my
own interest |
| 03:08.21 |
objorn |
i have a
feeling i will being needing to use it in about a year so i should
become familiar now |
| 03:09.02 |
brlcad |
ok,
cool |
| 03:34.25 |
Ralith |
starseeker:
what is that, and why does it make xpdf lock up? |
| 03:43.59 |
brlcad |
starseeker:
what's missing from that art is the sample
determination |
| 03:45.09 |
brlcad |
Ralith:
something about how it's encoded.. massively eating up cpu
here |
| 03:45.29 |
brlcad |
it's just a
bunch of simple lines, but something wrong with the pdf |
| 03:45.54 |
Ralith |
doesn't even
eat much CPU here |
| 03:45.56 |
Ralith |
just
locks |
| 03:47.06 |
pacman87 |
it was taking
up all of one core for me |
| 03:47.38 |
pacman87 |
i gave up and
closed it |
| 03:49.36 |
brlcad |
re-encodes it |
| 03:50.16 |
brlcad |
http://bzflag.bz/~sean/points.pdf |
| 03:52.12 |
brlcad |
few cases not
missing, not that it matters -- the three-case can be considered
to cover all possibilities pair-wise if you treat one of them, say
C, as being the test sample (just that several options become
invalid samples) |
| 03:55.32 |
brlcad |
also not
clear that the representative shape is accurate -- they end up
being distance checks with a tolerance so those should be spheres
of uncertainty |
| 03:55.52 |
brlcad |
for
computational reasons as well as just not inducing an aliasing
bias |
| 03:57.25 |
brlcad |
it'd be
square/rectangular if the comparisons were done per coordinate
component individually but they're not (intentionally) as it would
introduce an artificial shape factor (and be more
book-keeping) |
| 03:57.38 |
brlcad |
interesting
idea, though, for certain |
| 03:57.47 |
brlcad |
and assuming
I'm just not missing something |
| 04:02.12 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 04:05.49 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 04:38.34 |
starseeker |
brlcad: I
doubt you are |
| 04:38.34 |
starseeker |
I thought the
comparisons would be done per component, but if not then yes it
would be spheres |
| 04:38.50 |
brlcad |
yeah, nah --
they are point-point distances |
| 04:39.15 |
starseeker |
it doesn't
actually matter too much - I just need to re-draw the cases with
spheres |
| 04:39.22 |
starseeker |
might
eliminate a few, not sure |
| 04:39.35 |
brlcad |
doing it per
component is smaller, but a biased shape |
| 04:39.53 |
brlcad |
don't redraw,
it gets the point across |
| 04:40.02 |
brlcad |
no pun
intended |
| 04:40.05 |
starseeker |
heh |
| 04:40.13 |
starseeker |
scolds inkscape for doing such a sucky pdf |
| 04:40.28 |
brlcad |
looks like
they use cairo |
| 04:40.34 |
starseeker |
yeah |
| 04:40.34 |
brlcad |
so might be
cairos fault for the crap |
| 04:40.46 |
brlcad |
either way,
something really wrong with it :) |
| 04:40.55 |
starseeker |
I wondered
why it rendered so slow |
| 04:42.03 |
starseeker |
heh - spheres
would actually mean circles, and that would (probably) make it
proper Venn diagrams after all :-) |
| 04:42.20 |
brlcad |
so the trick
with the tests are all mostly just a matter of accumulated error
tracking with a given comparison tolerance |
| 04:43.17 |
starseeker |
well, unless
we need to decide which points with overlapping error bounds to
regard as the same - that's where it gets iffy |
| 04:43.42 |
brlcad |
another way
to think of why boxes would be an issue is the effect it would
cause on a point-collapse operation |
| 04:43.59 |
brlcad |
the direction
of approach between two points would actually affect their
collapse |
| 04:44.07 |
brlcad |
you want it
direction invariant |
| 04:44.15 |
starseeker |
true. |
| 04:44.36 |
starseeker |
I was
assuming we were constrained by the realities of xyz 3d point
storage |
| 04:45.07 |
brlcad |
nah, because
we do actual distance calcs between the points |
| 04:45.19 |
starseeker |
what did you
have in mind for a collapsing algorithm? |
| 04:45.31 |
starseeker |
nearest point
with overlapping error bounds? |
| 04:45.31 |
brlcad |
DIST_PT_PT()
in vmath, for example |
| 04:46.00 |
brlcad |
well naive
first implementation, yes, but that's a very dumb clustering
technique that will have problems |
| 04:46.06 |
starseeker |
agreed |
| 04:46.21 |
starseeker |
my second
pass was largest shared error bound volume |
| 04:46.45 |
starseeker |
but that also
seems to have some weaknesses |
| 04:47.10 |
starseeker |
I was trying
to find papers on techniques earlier today (should be in the
scrollback, come to think of it) |
| 04:47.13 |
brlcad |
basically if
you have two points A and B that are near each other within the
distance tolerance, there's an entire ellipsoid where they are
within tolerance |
| 04:47.34 |
brlcad |
and
conceivably, any value in there would suffice as a
solution |
| 04:47.53 |
starseeker |
for free
points in space, that might do |
| 04:47.56 |
brlcad |
picking A or
B is usually the case, but that's actually on the surface of the
ellipsoid instead of some mean/average/inner point |
| 04:48.06 |
starseeker |
I'm worried
about things like the vertex of an arb8 though |
| 04:48.20 |
brlcad |
picking
anything *other* than A or B, though, is changing your inputs and
can cause cascade failures |
| 04:48.32 |
brlcad |
or
accumulated error |
| 04:48.37 |
starseeker |
what about
three points with one being overlapped by the other two but the
other two mutually exclusive? |
| 04:49.12 |
starseeker |
and so on...
n points means a lot of those sorts of possibilities |
| 04:49.28 |
brlcad |
yeah, that's
the point drift problem |
| 04:49.53 |
brlcad |
A and B are
within tol, B and C within tol, but not A and C .. so what
happens |
| 04:50.01 |
starseeker |
exactly |
| 04:50.11 |
brlcad |
you make a
decision and that can cascade a failure |
| 04:50.28 |
starseeker |
as near as I
can tell you have to pick one and say the other one is a no-go,
unless you have something better <hopes> |
| 04:50.55 |
brlcad |
what you
suggest is basically what nmg code does now |
| 04:51.02 |
starseeker |
winces |
| 04:51.15 |
starseeker |
ouch |
| 04:52.42 |
starseeker |
uncle -
what's the better solution? |
| 04:52.45 |
brlcad |
it makes a
decision on the first comparison A<>B and clamps B to A if
within tol to maintain data integrity, then comparing C, determines
it's outside bounds and rejects it |
| 04:53.07 |
brlcad |
or determines
it's within and clamps to A as well, etc |
| 04:54.17 |
starseeker |
what bounds
is it comparing C to? B and C shouldn't both be clamped to A,
correct? |
| 04:54.38 |
brlcad |
okay, so
there are a couple things that we can try, but not making promises
that we'll actually solve it for all conditions .. garbage in will
result in garbabe out |
| 04:54.57 |
brlcad |
it really
depends on what the algorithm is attempting to
accomplish |
| 04:55.29 |
brlcad |
it was
comparing C to the same distance tolerance, A<>C |
| 04:55.58 |
starseeker |
so B and C
WOULD end up the same point after clamping? |
| 04:56.16 |
brlcad |
all three at
A or C rejected |
| 04:56.32 |
brlcad |
that's just
explaining basically what it presently does |
| 04:56.40 |
brlcad |
oversimplified |
| 04:56.47 |
starseeker |
nods |
| 04:57.08 |
brlcad |
where it
really fails, though, is that it doesn't know it clamped B to
A |
| 04:57.19 |
starseeker |
blinks |
| 04:57.43 |
starseeker |
yeah, that
could be a problem |
| 04:57.43 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 04:57.48 |
brlcad |
topologically, it may have been the actual
case that B<>C was the right two to combine and A was just
something close by |
| 04:58.02 |
brlcad |
and had the
order of operations even changed, it would have worked out
correct |
| 04:59.07 |
brlcad |
jeez, eva
mendes is smokin' |
| 04:59.25 |
brlcad |
anyways |
| 04:59.35 |
brlcad |
so the idea
is that we have to track the decision |
| 04:59.45 |
objorn |
i want to
enable opengl support, yes? |
| 04:59.55 |
brlcad |
objorn: no,
not necessary |
| 05:00.11 |
objorn |
what's the
benefit of using it? |
| 05:00.12 |
brlcad |
doesn't
affect anything to disable/enable it -- it'll use X11
routines |
| 05:00.26 |
starseeker |
archer needs
ogl, I think that's about it |
| 05:00.29 |
brlcad |
it's just
what underlying protocol does it speak, doesn't actually change
what features are provided |
| 05:00.35 |
brlcad |
doesn't give
you shaded displays, for example |
| 05:00.56 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 05:00.59 |
starseeker |
actually, at
present archer doesn't seem to display anything without
ogl... |
| 05:01.05 |
objorn |
how do you
enable it through configure? ./configure USE=opengl |
| 05:01.08 |
objorn |
:P |
| 05:01.18 |
objorn |
seriously
though, i'm not sure |
| 05:01.23 |
starseeker |
./configure
--help |
| 05:01.27 |
objorn |
thanks |
| 05:02.24 |
starseeker |
brlcad: is
tracking the decision O(n^2) or worse? |
| 05:02.53 |
brlcad |
starseeker:
so to track the decision, the simplest way is to simply take the
average of the two points and track the error volume |
| 05:04.36 |
objorn |
./configure
--enable-OpenGL[=yes] |
| 05:04.38 |
objorn |
? |
| 05:05.13 |
starseeker |
--with-ogl |
| 05:05.31 |
objorn |
thank you
starseeker |
| 05:05.47 |
brlcad |
so with
A<>B, it determines they're within tol, giving a resulting AB
point (call it D) and the maximal error of that point (which after
the first comparison is just the tolerance) .. then compares D
using that error against C with the starting tolerance, resulting
in a DC point, call it E |
| 05:06.23 |
starseeker |
ok |
| 05:06.46 |
brlcad |
E's error is
possibly going to be bigger than D's, error is accumulating as more
points are combined |
| 05:06.51 |
starseeker |
do we then
check B and C for distance from E? |
| 05:07.16 |
brlcad |
so if you had
a string of points within tolerance, they can actually all collapse
with a resulting large error bounds |
| 05:07.22 |
starseeker |
right |
| 05:07.41 |
starseeker |
in the worst
case, we go from a long line of points to one point with a huge
error bound? |
| 05:07.45 |
brlcad |
but it's kept
track of that error and theoretically, nothing will be left
out |
| 05:07.50 |
brlcad |
just possibly
too much brought in |
| 05:08.11 |
brlcad |
right, that
should be the worst case I *think* |
| 05:08.24 |
brlcad |
not
realistic, but conceivable |
| 05:09.39 |
starseeker |
so if a ray
passes within the error bound of the point, is it a
hit? |
| 05:10.01 |
brlcad |
now the trick
is when we run into a future operation that results in
topologically invalid geometry (non-manifold for example), we can
actually back out a decision and try to find one that will result
in valid geometry |
| 05:11.05 |
brlcad |
if we were to
get really fancy, each decision becomes a new graph in a decision
tree and we have a parametric decision tree |
| 05:11.15 |
brlcad |
but that's
fugly and expensive |
| 05:11.22 |
starseeker |
nods |
| 05:12.57 |
starseeker |
bemusedly wonders if we can use metaballs to keep track of
the error bound :-) |
| 05:13.58 |
starseeker |
alright, I
should get some sleep here :-P |
| 05:14.26 |
starseeker |
back after
regaining consciousness |
| 05:15.15 |
brlcad |
there's
actually a good argument for maintaining a fixed error |
| 05:15.38 |
brlcad |
and rejecting
C if it's not within that D average point within error |
| 05:15.51 |
brlcad |
not
accumulating error |
| 05:16.16 |
brlcad |
basically
clamping error to some fixed magic tolerance slightly larger than
the distance tolerance |
| 05:23.38 |
brlcad |
(like
sqrt(distance tolerance)) |
| 05:24.07 |
brlcad |
for
fractional tolerances of course |
| 05:28.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 05:32.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 05:33.38 |
brlcad |
the bigger
issue is generally going to be that there are at least two main
tolerances.. there's our absolute calculation tolerance for
presumably what the hardware can handle, and a model tolerance,
which is generally many orders of magnitude larger |
| 06:41.12 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 07:17.06 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:40.18 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 08:14.49 |
*** join/#brlcad PrezKennedyJR
(i=Matthew@whitecalf.net) |
| 08:25.40 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:31.51 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 09:31.32 |
*** join/#brlcad Lez
(n=lezardfl@189.58.209.254.dynamic.adsl.gvt.net.br) |
| 10:12.03 |
*** join/#brlcad madant
(n=d@117.196.142.112) |
| 12:02.23 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:49.59 |
brlcad |
yawns |
| 13:10.40 |
*** join/#brlcad madant
(n=madant@117.196.140.132) |
| 13:25.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 13:25.32 |
madant |
loves waking up at 4 pm :) |
| 13:25.36 |
*** join/#brlcad Don_
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 13:42.59 |
brlcad |
madant: heh,
fantastic :) |
| 14:05.15 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 14:49.56 |
*** join/#brlcad ``Erik
(n=erik@ftp.brlcad.org) |
| 15:33.37 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 15:49.01 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 15:53.56 |
``Erik |
hrm, *ponder*
I have 4 photographs of an object with different lighting angles,
it'd be really gnarley if we had an app that attempted to generate
a 3d .g file from those images (random thought) |
| 15:54.22 |
brlcad |
``Erik: put
in for a dri :) |
| 15:54.36 |
``Erik |
http://www.math.ubc.ca/~cass/Euclid/ybc/ybc.html
are the images in question |
| 15:54.39 |
brlcad |
that's not
far off from what I proposed a few years gack |
| 15:56.27 |
``Erik |
babylonion
geometric theory, pheer |
| 16:11.46 |
*** join/#brlcad Lez
(n=lezardfl@189.58.209.254) |
| 16:13.01 |
*** join/#brlcad madant
(n=madant@117.196.131.88) |
| 16:24.03 |
brlcad |
waves to madant |
| 16:44.59 |
madant |
waves back |
| 16:45.10 |
``Erik |
does the wave, too |
| 16:46.18 |
madant |
all we need
is a little resonance for an IRC disaster :) |
| 16:48.14 |
madant |
brlcad: did u
have a look at the draft ? |
| 16:48.47 |
brlcad |
madant:
briefly, reading in more detail later today |
| 16:49.17 |
brlcad |
er, no --
yours was to the list, yes I did read that |
| 16:49.50 |
madant |
will be back after dinner :) |
| 16:53.03 |
brlcad |
resounding
comment to offer would be that I'd like you to emphasize achieving
some actual user-visible integration/impact this summer, even if it
means leaving some portions not quite resolved (like the grammar,
or even portions of the solving framework) |
| 16:59.46 |
CIA-40 |
BRL-CAD:
03brlcad * r34123 10/brlcad/trunk/TODO: |
| 16:59.46 |
CIA-40 |
BRL-CAD:
annotate intent to add material objects, shader objects, and image
objects to v5 |
| 16:59.46 |
CIA-40 |
BRL-CAD: as
has been discussed and mused over the years. really need material
objects |
| 16:59.46 |
CIA-40 |
BRL-CAD:
soon, which implies having shader objects even sooner. image
objects can wait, |
| 16:59.46 |
CIA-40 |
BRL-CAD:
though. |
| 17:01.05 |
``Erik |
is kinda wishing he had a glidepad on his desktop
:/ |
| 17:03.57 |
madant |
brlcad: true,
i'd like for some visible integration myself :) Nothing helps
further progress like a basic working system. |
| 17:04.17 |
madant |
and the
actual issues will come up only when things are
user-visible |
| 17:05.08 |
madant |
I think i
could spend less time on the "perfect solver" and devote that time
to user-interfacing |
| 17:05.43 |
madant |
``Erik,
glidepad ? |
| 17:07.18 |
``Erik |
um,
touchpad |
| 17:07.44 |
``Erik |
the macbook
is spoiling me with that bigassed glass beast |
| 17:08.05 |
``Erik |
having to
actually push a mouse button down sucks :D |
| 17:08.08 |
``Erik |
</whine> |
| 17:09.27 |
madant |
``Erik, :P
don't be too lazy :D |
| 17:09.54 |
madant |
doesnt like the mouse at all |
| 17:10.51 |
madant |
though
engineering-wise pretty neat for its time :) |
| 17:11.00 |
``Erik |
well, having
to click a small 'next' button 68 times is a bitch, the mouse tends
to want to move, on my lappie, I'd just tap and not think about the
location of the pointer, making it a soft 'next' button of its
own |
| 17:11.10 |
``Erik |
its time? you
mean like '62? :D |
| 17:11.58 |
``Erik |
68,
rather |
| 17:12.14 |
madant |
was just now checking that |
| 17:12.30 |
``Erik |
doug
engelbart, though the trackball was '52 |
| 17:12.52 |
madant |
wow 52 .. :D
must have looked like a monster :) |
| 17:13.30 |
``Erik |
picture
doesn't make it look too bad, canadian 5-pin ball (which is about
the size of a modern 'good' trackball) |
| 17:13.37 |
``Erik |
there's a pic
on the wikipedia article for meeces |
| 17:14.37 |
madant |
ah well looks
straight out of a science fiction b/w movie |
| 17:15.27 |
madant |
"cutting
edge" has progressed a lot in 50 years :) |
| 17:30.22 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.209.254) |
| 17:40.32 |
brlcad |
madant: yeah,
I think that'd be *really* good to focus on -- pick one
user-visible goal for the project and then organize your activities
around making that happen on the backend, only exactly what's
needed for that feature |
| 17:41.56 |
brlcad |
like you
could make a 'validate' tool that calls the prep/constraint
validation checks for a few primitives |
| 17:42.45 |
brlcad |
or the
ability inside mged to create a parametric equation object that
talks to other objects and will evaluate |
| 17:42.56 |
brlcad |
something
succint and visible |
| 17:45.14 |
``Erik |
wonders if dwaynes g_qa gui would be a good soc
project? |
| 17:45.17 |
madant |
sounds
logical , and very rigorously measurable too in terms of progress
:) |
| 17:46.12 |
brlcad |
``Erik: yeah,
absolutely |
| 17:46.26 |
brlcad |
or better
yet, a plugin in the new gui |
| 17:46.34 |
brlcad |
if said
plugin underpinnings was in place |
| 17:48.20 |
madant |
g_qa gui
? |
| 17:50.03 |
brlcad |
yeah |
| 17:50.42 |
``Erik |
http://sourceforge.net/tracker/?func=detail&aid=2717388&group_id=105292&atid=640805 |
| 17:51.32 |
madant |
``Erik, was
reading that ;) |
| 17:52.13 |
``Erik |
of course,
there's been discussion about that in person between a few
different people that isn't reflected in the tracker yet
:) |
| 17:53.04 |
``Erik |
like storing
plot files in the .g for easy resource mgmt/transfer. whether it's
a seperate app, part of mged (or archer or whatever), or all of the
above |
| 17:53.08 |
``Erik |
etc |
| 17:53.47 |
madant |
brlcad:
plugin underpinnings ? |
| 17:57.38 |
brlcad |
madant: the
thin-client gui is supposed to be a heavily plugin-based
architecture (on the front-end and back-end) |
| 17:58.18 |
brlcad |
hm, that
reminds m e |
| 17:59.44 |
madant |
aha, an
extensible gui :) nice.. seems like brl-cad is going to look quite
different in the coming days ;) |
| 18:00.59 |
brlcad |
madant: that
is all part of the plan, yes |
| 18:01.21 |
brlcad |
all in line
with things spelled out here: http://brlcad.org/BRL-CAD_Priorities.png |
| 18:01.31 |
brlcad |
just more of
the details on how |
| 18:05.33 |
CIA-40 |
BRL-CAD:
03brlcad * r34124 10/brlcad/trunk/src/external/Makefile.am: aha,
fix distcheck for when Cubit isn't being built |
| 18:10.38 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 18:12.09 |
Malyce |
hi
? |
| 18:12.32 |
Malyce |
I am new to
IRC :P |
| 18:13.39 |
Malyce |
I had a
couple of questions about the idea of implementing an API for
BRL-CAD |
| 18:14.30 |
``Erik |
ok? |
| 18:15.05 |
Malyce |
oh |
| 18:15.15 |
Malyce |
are you the
admin ? |
| 18:15.34 |
``Erik |
I think I'm
tagged as one of them O.o just ask your questions, they'll get
answered (eventually) |
| 18:15.59 |
Malyce |
I was
wondering whether there was some work already done in the
direction. |
| 18:16.15 |
Malyce |
ALso, what
part of the code should I try to read, to get an
understanding |
| 18:16.20 |
Malyce |
? |
| 18:18.17 |
Malyce |
I would think
that creating an API would involve knowing the core aspects of the
geometry engine of BRL |
| 18:20.04 |
Malyce |
Is the Doxy
of the code unavailable ? It seems so from the website |
| 18:20.59 |
Malyce |
I had done
some research on BRL last year. I was unable to find documentation
for the code. Is it just me, or is documentation played down in the
open source industry ? |
| 18:27.50 |
madant |
Malyce: Doxy
is there but not very updated, depends on the part of brl-cad code
you were looking up. |
| 18:28.04 |
madant |
did u check
out the svn and try building the doxygen output ? |
| 18:28.34 |
madant |
:) I am a
last year gsoc participant and found brl-cad's code pretty well
commented ;) |
| 18:34.22 |
Malyce |
I am trying
it out now |
| 18:34.38 |
Malyce |
Ok, but I
wanted to look at a sort of overview, if you know what I
mean |
| 18:34.46 |
Malyce |
doxy is so
nice |
| 18:47.48 |
Malyce |
Can you point
me to the Doxy config file ? |
| 18:57.24 |
``Erik |
misc/Doxyfile |
| 19:10.00 |
brlcad |
howdy
Malyce |
| 19:23.49 |
Malyce |
hiya |
| 19:26.47 |
brlcad |
Malyce: there
is actually a lot of documentation, it's just not neatly organized
and in lots of places |
| 19:27.56 |
brlcad |
the code is
pretty well commented throughout, but there is also
this |
| 19:27.56 |
brlcad |
http://brlcad.sourceforge.net/doxygen/index.html |
| 19:28.30 |
brlcad |
was last ran
a couple years ago -- but the api of the libs hasn't really changed
in a drastic way since then |
| 19:28.37 |
Malyce |
thanks |
| 19:28.42 |
Malyce |
makes my life
easier |
| 19:28.49 |
brlcad |
someone(tm)
should get the doxygen system updating automatically on brlcad.org
of course... :) |
| 19:32.30 |
Malyce |
I have some
API experience |
| 19:33.12 |
Malyce |
in that, I
have been working as an RA to formalize Solidworks. I used the VBA
API for SW |
| 19:33.48 |
Malyce |
But, I have
never developed an API. I do have C/C++ exp, 6 yrs plus of Uni and
high school |
| 19:34.02 |
Malyce |
so, I was
wondering whether I was qualified for the job. |
| 19:34.40 |
Malyce |
I don't
really know where I would start, to design an API. Reading a lot of
wikipedia right now. |
| 19:36.11 |
Malyce |
But I assume,
the basic premise is that the API is linked to the Geometry engine
for the output to user, and for the input from the user, it feeds
it back. |
| 19:36.45 |
Malyce |
So, I should
take a close look at the how the GUI interfaces with BRL, because
that is the same interface that the API would use ? |
| 19:37.30 |
Malyce |
Any pointers,
where this would be ? |
| 19:39.30 |
Malyce |
So, one of
the GUIs is MGED. |
| 19:43.40 |
Malyce |
The GUI seems
to be primitive. Is there a way to use BRL-CAD, command line
? |
| 19:46.11 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34125 10/brlcad/trunk/src/adrt/librender/cut.c:
pointer wrangling. |
| 19:58.16 |
Malyce |
Found the cmd
line in MGED. Is there a brief explanation of the BRL code
structure somewhere. I can understand the doxygen, but I can't seem
to get the overally structure of BRL. Am I being retarded
? |
| 20:01.01 |
Malyce |
Am I missing
something obvious ? |
| 20:01.03 |
*** join/#brlcad andax
(n=andax__@d213-102-40-177.cust.tele2.ch) |
| 20:05.45 |
*** join/#brlcad madant
(n=madant@117.196.130.75) |
| 20:13.19 |
Malyce |
For example ,
where is the GUI initialisation done ? |
| 20:13.35 |
Malyce |
in Libdm
? |
| 20:18.03 |
*** join/#brlcad dreeves
(n=c752f34a@bz.bzflag.bz) |
| 20:32.56 |
CIA-40 |
BRL-CAD:
03r_weiss * r34126 10/brlcad/trunk/ (3 files in 2 dirs): updates to
rtarea adding center computations |
| 20:37.47 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 21:02.27 |
*** join/#brlcad madant
(n=madant@117.196.129.253) |
| 21:11.09 |
brlcad |
Malyce: sorry
for the delays, busy day :) |
| 21:11.17 |
brlcad |
gimme a sec
and I"ll answer all the ?'s |
| 21:11.33 |
Malyce |
np |
| 21:15.00 |
``Erik |
didn't know that poking a smoke detector with a measuring
tape constituted 'busy' :D *duck* |
| 21:16.17 |
alex_joni |
``Erik:
flaming measuring tape? |
| 21:22.43 |
``Erik |
measuring
tapes wearing mesh shirts and cutoffs? O.o |
| 21:25.48 |
CIA-40 |
BRL-CAD:
03r_weiss * r34127 10/brlcad/trunk/
(doc/docbook/system/man1/en/rtarea.xml src/rt/rtarea.1): updates to
rtarea documentation |
| 21:30.14 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 21:44.03 |
mafm |
hi
there |
| 21:44.51 |
*** join/#brlcad madant
(n=madant@117.196.129.255) |
| 21:54.04 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 22:15.17 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 22:26.51 |
brlcad |
howdy
mafm |
| 22:27.01 |
Ralith |
hullo
mafm |
| 22:27.44 |
brlcad |
Malyce: an
RA? revenue assurance? |
| 22:28.18 |
mafm |
-
Cubit/g-sat.cxx |
| 22:28.20 |
mafm |
+
Cubit/g-sat.cpp |
| 22:28.34 |
mafm |
``Erik was
ranting about cpp a few days ago.. :D |
| 22:28.52 |
brlcad |
he rants
about a lot of things |
| 22:29.30 |
*** join/#brlcad madant
(n=madant@117.196.129.154) |
| 22:30.30 |
brlcad |
Malyce: as
for overall structure, read volume I under docs on the website (the
first doc link) for some basic philosophy, as well as HACKING file
(near the middle is a description of the various dirs), and perhaps
src/README for a little more detail |
| 22:31.12 |
*** join/#brlcad ``Erik__
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 22:31.31 |
brlcad |
Malyce:
depending on which API you're referring to, it actually has very
little to do with the GUI -- more to do with the geometry
engine |
| 22:31.51 |
brlcad |
there's a
project to build up a geometry API similar to the acis/granite/etc
engines |
| 22:33.14 |
Malyce |
Research
Assistant |
| 22:33.18 |
brlcad |
if you want
to work on the gui, there are a couple specific projects possible
in that regard |
| 22:33.18 |
Malyce |
sorry for the
confusion |
| 22:33.25 |
brlcad |
ahh,
okay |
| 22:33.50 |
Malyce |
not
really |
| 22:33.57 |
Malyce |
I wanted to
work on the API |
| 22:34.07 |
Malyce |
I thought it
would be interesting |
| 22:34.10 |
brlcad |
'the API' ..
what does that mean to you? |
| 22:34.21 |
brlcad |
there are
many APIs in BRL-CAD |
| 22:34.26 |
brlcad |
there are a
dozen libraries |
| 22:34.27 |
objorn |
what is the
benchmark suite? |
| 22:35.07 |
brlcad |
objorn: the
benchmark suite is a toolchain that will evaluate your system
performance and report a performance metric that very closely
represents your expected computation capacity |
| 22:35.50 |
objorn |
interesting |
| 22:36.00 |
brlcad |
reports a
statistical measurement (similar to GFLOPS but unrelated) of your
performance that traces back through a couple decades of
computing |
| 22:36.00 |
Ralith |
also, verify
render results with known-good images |
| 22:36.07 |
Malyce |
OOP Geometry
API |
| 22:36.26 |
objorn |
this is
useful for? |
| 22:36.33 |
brlcad |
yeah, it's
also a verification / test suite |
| 22:36.57 |
Malyce |
Does it mean,
that I will be summarizing the existing interfaces into a bigger
interface, which will be more standardized |
| 22:36.57 |
brlcad |
objorn: to
know how fast a machine is under real-world use |
| 22:37.12 |
brlcad |
Malyce: an,
no -- not for the OOP Geometry API |
| 22:37.29 |
brlcad |
the OOP
geometry api is basically developing something like the ACIS engine
for BRL-CAD |
| 22:37.31 |
objorn |
ah, so if
there's a deadline, you'll have a good idea of how much more
computer power you need or when to start |
| 22:37.57 |
``Erik |
*rantrantrant* :D |
| 22:38.31 |
brlcad |
we presently
have the extensive LIBRT library API which provides most geometry
services but it's not very clean/organized, not OO, and lacking
some features |
| 22:38.38 |
Malyce |
Does it mean,
that I will be summarizing the existing interfaces into a bigger
interface, which will be more standardized ? |
| 22:38.43 |
brlcad |
objorn: one
possible use, sure |
| 22:38.55 |
brlcad |
objorn: also
very useful when buying new hardware |
| 22:39.01 |
Malyce |
so, the new
API interface will just provide a nicer interface ? |
| 22:39.18 |
Malyce |
to an
existing set of interfaces |
| 22:39.55 |
brlcad |
new computer
vender comes out with a new system, claims it'll be 5x faster than
the previous version... this gives a very accurate unbiased
measurement that makes it really easy to compare one machine to
another under controllable conditions |
| 22:40.07 |
brlcad |
Malyce: on
top of the existing set of interfaces, yet |
| 22:40.10 |
brlcad |
s/yet/yes |
| 22:40.48 |
starseeker |
makes note to self to look at reorganizing the header files
in include to be in subdirectories pertaining to individul
libraries |
| 22:40.53 |
brlcad |
Malyce: have
you ever worked with granite or acis? |
| 22:41.04 |
Malyce |
I have worked
with the SW API only |
| 22:41.06 |
starseeker |
checks if that is in the TODO... |
| 22:42.06 |
Malyce |
SW:
Solidworks |
| 22:42.34 |
brlcad |
very
similar |
| 22:42.59 |
brlcad |
there is a
project already under way related to this api in the rt^3
module |
| 22:43.10 |
Malyce |
the API you
want to implement should be similar to that used by Solidworks
? |
| 22:43.34 |
Malyce |
If there is a
project already underway, is it still possible for me to apply with
this idea ? |
| 22:44.07 |
brlcad |
http://brlcad.svn.sourceforge.net/svnroot/brlcad/rt^3/trunk/src/ |
| 22:44.17 |
CIA-40 |
BRL-CAD:
03starseeker * r34128 10/brlcad/trunk/TODO: Add a note to look into
reorganizing the headers so it is clearer which .h files pertain to
individual libraries. |
| 22:44.22 |
brlcad |
Malyce: of
course, just means you won't be working in isolation |
| 22:44.28 |
brlcad |
you have to
coordinate with the other developers |
| 22:44.49 |
Malyce |
So, the specs
have already been decided, and the structure has been set
? |
| 22:44.51 |
brlcad |
doable, just
have to work on the API and be involved in a lot of
discussions |
| 22:45.03 |
brlcad |
none of the
gsoc projects are meant to be done by students alone :) |
| 22:45.22 |
brlcad |
some of the
structure is set, most is a work in progress that will continue to
evolve |
| 22:45.31 |
Malyce |
And any new
programmer, just has to follow the pattern already established.
i.e, the programming method implemented so far ? |
| 22:45.34 |
Malyce |
I
see |
| 22:45.39 |
brlcad |
the engine
has to take into accout, for example, what our existing libraries
already do |
| 22:45.47 |
brlcad |
so that you
can leverage those facilities |
| 22:45.51 |
brlcad |
and not
reinvent the wheel |
| 22:46.07 |
brlcad |
we don't want
you to reimplement what has already been done |
| 22:46.30 |
brlcad |
it's more
about making a clean API that can be grown and tested that we will
want to use in our own tools |
| 22:46.49 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 22:47.01 |
brlcad |
coreInterface
and GeometryEngine are the two main efforts thusfar -- those two
need to merge at some point |
| 22:47.28 |
Malyce |
Would it be
possible for me to get the specs so far ? |
| 22:47.47 |
brlcad |
most of what
is available is on the wiki or on the website |
| 22:47.57 |
Malyce |
I will read
through it |
| 22:48.12 |
brlcad |
http://brlcad.org/wiki/Developer_Documents |
| 22:48.22 |
brlcad |
"BRL-CAD's
core C++ interface" is one |
| 22:48.56 |
brlcad |
"Geometry
Service" is another, closely related, but more focusing on
something a layer above the C++ API |
| 22:49.35 |
brlcad |
and finally,
more at http://brlcad.org/wiki/IBME_GeometryEngine |
| 22:49.56 |
brlcad |
that core
interface effort and the ibme ge work are the two that need to
merge |
| 22:52.12 |
*** join/#brlcad cad85
(n=d4c92c1e@bz.bzflag.bz) |
| 22:52.32 |
cad85 |
hello
tanmay! |
| 22:52.54 |
cad85 |
we know you
are hereeee!! |
| 22:53.22 |
Ralith |
O.o |
| 22:53.32 |
Malyce |
0.o |
| 22:53.53 |
brlcad |
cad85: who is
tanmay? |
| 22:53.59 |
cad85 |
if you are
wondering what i am saying i am just greeting my friend |
| 22:55.38 |
cad85 |
bye |
| 22:55.41 |
*** part/#brlcad cad85
(n=d4c92c1e@bz.bzflag.bz) |
| 22:55.58 |
Ralith |
that was
odd. |
| 22:56.07 |
brlcad |
yep |
| 22:56.42 |
Malyce |
uh please
ignore them |
| 22:56.48 |
``Erik |
hm, if'n ya
GSOCers haven't put your proposal up on the goog site yet, do it
soon |
| 22:56.49 |
Malyce |
friends
playing a prank |
| 22:57.07 |
``Erik |
they're
trying to get estimates for how many proposals there will be (I
believe you can edit them once you put them up) |
| 22:57.30 |
Ralith |
has done so. |
| 22:57.37 |
``Erik |
ralith++ |
| 22:57.37 |
brlcad |
~ralith++ |
| 22:57.42 |
brlcad |
fail! |
| 22:57.45 |
Ralith |
:D |
| 22:57.49 |
mafm |
ERIK
FAIL |
| 22:57.59 |
brlcad |
heh |
| 22:58.03 |
``Erik |
has no interest in manipulating that steaming pile of
bot |
| 22:58.11 |
``Erik |
just making a
general statement :) |
| 22:59.06 |
Ralith |
is there a
list of who's mentoring somewhere? |
| 22:59.54 |
``Erik |
yeah |
| 23:02.35 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 23:05.17 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1319
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors */ update
list for the 2009 folks |
| 23:06.43 |
Ralith |
hehe |
| 23:07.38 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177680193.dsl.bell.ca) |
| 23:08.52 |
Malyce |
With regards
to Geometry Services, why would you need a layer above C++ API
? |
| 23:11.23 |
brlcad |
it's a
distributed network service interface |
| 23:11.47 |
brlcad |
a way to
bridge communication with other applications what want to remain
loosely coupled |
| 23:12.45 |
brlcad |
e.g., a java
application that wanted to access brl-cad geometry, get display
lists, shoot rays, but not have to maintain a JNI wrapper or be
tied to binary distribution issues |
| 23:13.43 |
brlcad |
or even in
our own tool so that we can have a service talk to other geometry
servers, allow distributed shared access to geometry,
etc |
| 23:16.44 |
``Erik |
so is v6
going to keep the 'flat' namespace or move to an fs like heirarchal
one? |
| 23:19.20 |
brlcad |
it'll be more
like svn -- you talk over a protocol and something happens on the
backend |
| 23:19.55 |
Malyce |
Will the
Geometry API be expected to perform such tasks as well
? |
| 23:20.03 |
brlcad |
Malyce: not
at all |
| 23:22.55 |
Malyce |
Thanks a lot
for your help. Goodnight. |
| 23:28.23 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:44.33 |
``Erik |
we don't take
kindly to folk who don't take kindly 'round here |
| 00:05.24 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 00:07.10 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 00:23.43 |
CIA-40 |
BRL-CAD:
03216.171.189.59 07http://brlcad.org * r1320
10/wiki/Google_Summer_of_Code/Project_Ideas: /* Aqua MGED on Mac OS
X */ fix external link syntax |
| 00:23.50 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 01:20.07 |
yukonbob |
http://pastebin.ca/1378510 |
| 01:20.14 |
yukonbob |
^--- another
build issue |
| 01:20.22 |
yukonbob |
(hello,
cadheads |
| 01:20.23 |
yukonbob |
) |
| 01:21.03 |
Ralith |
looks like
you're not linking to libstdc++ |
| 01:21.11 |
Ralith |
but isn't
librt all C? |
| 01:21.35 |
yukonbob |
Ralith: re:
all C -- no idea. |
| 01:22.25 |
yukonbob |
re: libstdc++
agreed... (/me not a C++ person)...so I'm only one experiencing
this, I guess... |
| 01:22.39 |
Ralith |
what're you
trying to do? |
| 01:22.52 |
yukonbob |
just
./autogen.sh, configure ,make |
| 01:23.11 |
yukonbob |
is SVN
co |
| 01:23.31 |
yukonbob |
34122,
fwiw |
| 02:01.47 |
mafm |
night |
| 02:13.33 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:35.51 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 02:47.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 02:53.54 |
*** join/#brlcad Lez
(n=lezardfl@189.58.209.254.dynamic.adsl.gvt.net.br) |
| 03:26.10 |
brlcad |
Ralith:
librt's api is all C, but some of the implementation details
involve a C++ library (openNURBS) |
| 03:26.25 |
brlcad |
so you end up
needing libc++ |
| 03:26.27 |
Ralith |
ah,
right |
| 03:26.42 |
Ralith |
what was
wrong with yukonbob's setup? |
| 03:29.02 |
brlcad |
the test for
libc++ probably failed |
| 03:29.30 |
brlcad |
it's trying
to link the 'comb' program there |
| 03:29.42 |
brlcad |
comb only
uses librt.la and it's dependent RT_LIBS |
| 03:29.53 |
brlcad |
RT_LIBS="${BN} ${BN_LIBS} ${BU} ${BU_LIBS}
${REGEX} ${LIBM} ${SYSV} ${OPENNURBS}" |
| 03:30.10 |
brlcad |
OPENNURBS='${top_builddir}/src/other/openNURBS/libopenNURBS.la
${LIBSTDCXX}' |
| 03:30.42 |
brlcad |
so my guess
is he actually doesn't have a libstdc++ |
| 03:31.16 |
brlcad |
configure
should probably warn very verbosely if that happens, just pretty
rare |
| 03:31.32 |
brlcad |
but it's also
rather compiler-dependent |
| 03:34.26 |
Ralith |
I can't
imagine a system not having libstdc++ O.o |
| 03:35.36 |
brlcad |
note to
students that haven't posted their app yet, you're supposed to
submit what you have, whatever you have ASAP so they can get a
headcount |
| 03:36.39 |
pacman87 |
takes note |
| 03:42.14 |
Ralith |
which they is
this? |
| 03:42.16 |
Ralith |
google? |
| 03:42.23 |
brlcad |
yes |
| 03:42.40 |
brlcad |
they're
trying to decide whether to extend the deadline or not |
| 03:42.44 |
Ralith |
ah. |
| 03:42.53 |
brlcad |
which I
suppose should mean don't submit it if you want them to extend it
:) |
| 03:43.01 |
Ralith |
heh |
| 03:43.09 |
pacman87 |
does BRL-CAD
have a generalized nth order equation solver? |
| 03:43.42 |
brlcad |
pacman87:
generalized, but the maximum n is compile-time limited |
| 03:44.02 |
brlcad |
not sure how
stable it is at higher orders |
| 03:44.31 |
pacman87 |
ah. i was
trying to see how to gracefully degrade for higher-order splines
that didn't have analytical solutions |
| 03:45.29 |
brlcad |
rt_poly_roots() |
| 03:45.38 |
brlcad |
see
src/util/roots_example.c |
| 03:47.12 |
brlcad |
ran a
performance analysis last year and was shocked to find that we
outperform almost everyone, just a couple obscure solvers that came
within 10% |
| 03:48.13 |
pacman87 |
my revolve
approach collapses the 3d intersection to 2d by converting the ray
line into a hyperbola |
| 03:48.23 |
pacman87 |
so i'd
intersect the spline with a hyperbola |
| 03:48.31 |
yukonbob |
waves to pacman87 |
| 03:48.36 |
yukonbob |
waves to brlcad |
| 03:48.37 |
pacman87 |
waves back |
| 03:48.54 |
yukonbob |
waves to anybody within raytracing
distance |
| 03:49.19 |
pacman87 |
activates a cloak and returns zero-length hit segments
:P |
| 03:49.27 |
brlcad |
given
raytracing uses infinite rays, wouldn't that be everyone?
:) |
| 03:49.43 |
yukonbob |
they could be
obscured, I was thinking. |
| 03:50.05 |
yukonbob |
should know better than to bastardize tech. with a bunch of
ubernerds |
| 03:50.26 |
yukonbob |
rays are
bounded by #brlcad |
| 03:50.27 |
yukonbob |
;) |
| 03:50.43 |
brlcad |
plus we're
one of the few raytracers that be default evaluates all points on
the ray, not just first hit like most |
| 03:51.04 |
brlcad |
for analysis
and solid modeling purposes ;) |
| 03:51.13 |
yukonbob |
go
figure! |
| 03:51.56 |
yukonbob |
reads scrollback to see if other comments on latest
pastebin... |
| 03:52.18 |
yukonbob |
sees comments |
| 03:52.47 |
brlcad |
pacman87:
what kind of spline? |
| 03:53.10 |
pacman87 |
the 2-d
spline from the sketch primitive |
| 03:55.08 |
yukonbob |
/usr/lib/libstdc++.a |
| 03:55.09 |
yukonbob |
/usr/lib/libstdc++.so |
| 03:55.09 |
yukonbob |
/usr/lib/libstdc++.so.6 |
| 03:55.09 |
yukonbob |
/usr/lib/libstdc++.so.6.0 |
| 03:55.09 |
yukonbob |
/usr/lib/libstdc++_p.a |
| 03:55.11 |
yukonbob |
/usr/lib/libstdc++_pic.a |
| 03:55.19 |
yukonbob |
^-- from
"locate" |
| 03:55.54 |
yukonbob |
is there such
a think as libc++? |
| 03:56.40 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.198.192) |
| 04:00.27 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-143-241.3g.claro.net.br) |
| 04:00.29 |
brlcad |
yukonbob: no,
those are it |
| 04:00.41 |
brlcad |
so what did
configure report for the libstdc++ test? |
| 04:00.49 |
brlcad |
it's int he
config.log and/or in your configure output |
| 04:02.04 |
brlcad |
pacman87: no,
I mean what order and type |
| 04:02.16 |
AlexandreGuedes |
Hello |
| 04:02.19 |
brlcad |
b-spline?
nurbs curve, bezier? |
| 04:02.37 |
brlcad |
nth order,
limited to 4th order? |
| 04:02.43 |
brlcad |
howdy
AlexandreGuedes |
| 04:04.20 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-142-217.3g.claro.net.br) |
| 04:05.11 |
AlexandreGuedes_ |
brlcad: I
would like to know if develop importers and exporters would be
important |
| 04:05.30 |
brlcad |
AlexandreGuedes_: importers and exporters
are always cool to have |
| 04:05.36 |
yukonbob |
brlcad: will
rebuild and check. |
| 04:05.49 |
brlcad |
especially if
it's a format you're pretty familiar with |
| 04:06.08 |
brlcad |
or if it's
just a really important importer that we don't have or need
improved |
| 04:06.31 |
pacman87 |
brlcad: since
the hyperbola of the converted ray is second order, i had started
last year with a limit of 2nd order splines |
| 04:06.50 |
AlexandreGuedes_ |
I already
developed some importers for opengl |
| 04:07.53 |
brlcad |
pacman87:
it's perhaps worth noting that there are specific spline solvers
within the code as well (though not in as pretty polynomial
form) |
| 04:08.10 |
brlcad |
but 2nd order
should be perfectly fine for the general solver |
| 04:08.20 |
Ralith |
AlexandreGuedes_: what formats might you
work with? |
| 04:08.23 |
AlexandreGuedes_ |
brlcad: My it
doubts was if that is really important |
| 04:08.34 |
AlexandreGuedes_ |
obj and
vrml |
| 04:08.42 |
Ralith |
pretty sure
we already have vrml |
| 04:09.23 |
AlexandreGuedes_ |
but i can
develop othres |
| 04:09.27 |
brlcad |
AlexandreGuedes_: those are two pretty
popular formats, would be very useful to have .. would have to have
a plan for what would happen if you finish early though |
| 04:09.28 |
AlexandreGuedes_ |
others |
| 04:09.56 |
brlcad |
Ralith: there
are exporters for both of those but neither has an
importer |
| 04:09.59 |
Ralith |
ahh. |
| 04:10.11 |
brlcad |
surprisingly
enough .. the importer is actually even easier |
| 04:10.18 |
AlexandreGuedes_ |
I could
develop how many I get |
| 04:11.06 |
AlexandreGuedes_ |
after i can
get Global illumination renderer |
| 04:11.16 |
AlexandreGuedes_ |
if i have
tiem |
| 04:11.20 |
brlcad |
I'd expect
those two importers would really only take a week or so each
actually, maybe even just a few days each .. depends on how
extensive you get into the obj format |
| 04:11.23 |
AlexandreGuedes_ |
time* |
| 04:12.03 |
brlcad |
their
exporters are more involved |
| 04:12.13 |
brlcad |
mm.. global
illum would be awesome |
| 04:12.16 |
AlexandreGuedes_ |
hmmm |
| 04:12.29 |
brlcad |
AlexandreGuedes_: have you worked on
global illumination and rendering before? |
| 04:13.45 |
brlcad |
AlexandreGuedes_: I would suggest if you
can make the time, to submit two applications just so you have a
better chance of getting selected on your abilities more than the
priority of what it is you're proposing to work on |
| 04:13.50 |
AlexandreGuedes_ |
little |
| 04:14.41 |
brlcad |
but yeah,
those sound like great areas to be proposed |
| 04:14.44 |
brlcad |
either or
both |
| 04:14.49 |
AlexandreGuedes_ |
i like use
openGL and C there is other intersting idea ? |
| 04:15.01 |
brlcad |
wouldn't mixt
the global illum on the same proposal though |
| 04:15.44 |
AlexandreGuedes_ |
ok. |
| 04:16.14 |
brlcad |
there's an
entire opengl GUI project, but that will likely be pretty
competitive |
| 04:16.41 |
brlcad |
you could
always propose your own project as well |
| 04:18.01 |
Ralith |
there's that
-> OpenGL/C interactive program exporter |
| 04:18.10 |
Ralith |
that'd be
pretty cool |
| 04:18.28 |
AlexandreGuedes_ |
how
interactive ?? |
| 04:18.50 |
brlcad |
Ralith: oh
you mean on the orange ideas page? |
| 04:18.53 |
Ralith |
yeah |
| 04:19.00 |
brlcad |
right |
| 04:19.05 |
brlcad |
AlexandreGuedes_: it's another exporter
idea |
| 04:19.08 |
brlcad |
see, http://brlcad.org/~sean/ideas.html |
| 04:19.15 |
Ralith |
AlexandreGuedes_: free camera
movement/zoom would probably cover it fine. |
| 04:19.24 |
Ralith |
along with
some way to select what region(s) to show |
| 04:19.46 |
brlcad |
having an
exporter/importer that dumps out opengl code (display lists, direct
mode calls, retained mode, etc) |
| 04:19.57 |
Ralith |
oh, that kind
of thing! |
| 04:20.00 |
Ralith |
that works
too. |
| 04:20.18 |
Ralith |
of course,
you'd have to tesselate everything first and I'm not sure how easy
that is w/o the brep stuff finished yet. |
| 04:20.38 |
AlexandreGuedes_ |
i can figure
out |
| 04:20.56 |
brlcad |
Ralith: not
necessarily |
| 04:21.01 |
Ralith |
oh? |
| 04:21.04 |
brlcad |
glu has some
primitives |
| 04:21.19 |
brlcad |
has nurbs
surfaces, for example |
| 04:21.26 |
Ralith |
yeah, but you
can't subtract/intersect them, can you? |
| 04:21.27 |
brlcad |
and various
quadrics |
| 04:22.12 |
Ralith |
I guess you
could just tesselate the regions that involved
subtraction/intersection, or even just the relevant sets of
primitives |
| 04:22.14 |
brlcad |
no, you'd
still have to have evaluated CSG, just wouldn't necessarily need to
tessellate or sample |
| 04:22.49 |
Ralith |
er, how do
you manage, then? |
| 04:23.07 |
brlcad |
AlexandreGuedes_: I like the idea for
converters, do apply :) |
| 04:23.22 |
AlexandreGuedes_ |
hum.. |
| 04:23.24 |
brlcad |
but do
plan/mention for more than those two |
| 04:23.44 |
AlexandreGuedes_ |
i'll offer
something |
| 04:23.50 |
brlcad |
and them
maybe a non-converter backup in an area that interests
you |
| 04:24.00 |
brlcad |
cool |
| 04:24.22 |
AlexandreGuedes_ |
<PROTECTED> |
| 04:24.35 |
AlexandreGuedes_ |
if i
have* |
| 04:25.27 |
pacman87 |
AlexandreGuedes_: submit it early and get
feedback - you can update it until the deadline |
| 04:25.47 |
pacman87 |
should follow that advice, too |
| 04:26.04 |
brlcad |
AlexandreGuedes_: absolutely, and what
pacman87 said :) |
| 04:26.33 |
Ralith |
oh yeah that
reminds me |
| 04:26.40 |
AlexandreGuedes_ |
thanks a
lot |
| 04:26.48 |
Ralith |
I'm going to
be on a bit less (not completely gone, though) until
monday |
| 04:27.05 |
AlexandreGuedes_ |
last
question... There is already much submissions ? |
| 04:27.46 |
AlexandreGuedes_ |
many
submissions *** |
| 04:27.51 |
brlcad |
and for
anyone that's wondering/working/waiting, don't let not having a
patch stop you from submitting your proposal -- there's time after
the deadline |
| 04:28.07 |
brlcad |
AlexandreGuedes_: no, submissions are way
down this year .. so you're chances are pretty good |
| 04:28.49 |
brlcad |
also, the
more detail in your proposal, the better .. that's the biggest
problem with most proposals |
| 04:28.54 |
brlcad |
not enough
detail/information |
| 04:29.12 |
brlcad |
say how,
what, why, when, where.. ;) |
| 04:29.37 |
AlexandreGuedes_ |
ok no
detail |
| 04:29.58 |
brlcad |
heh |
| 04:30.19 |
AlexandreGuedes_ |
where are you
from ? |
| 04:30.48 |
pacman87 |
UT
Austin |
| 04:30.48 |
brlcad |
Panama |
| 04:31.16 |
brlcad |
lives in Maryland USA |
| 04:32.05 |
AlexandreGuedes_ |
I'm from
Brazil.. |
| 04:32.17 |
brlcad |
your IP is a
give-away |
| 04:32.59 |
AlexandreGuedes_ |
my
? |
| 04:33.11 |
brlcad |
yeah, brazil
ip/dns |
| 04:36.02 |
AlexandreGuedes_ |
And about
most of others brl-cad developers... |
| 04:36.48 |
brlcad |
AlexandreGuedes_: all over -- usa,
germany, portugal, india, netherlands, and spain come to
mind |
| 04:37.25 |
brlcad |
wanders off to nap before his morning row in four
hours |
| 04:37.44 |
brlcad |
laments |
| 04:38.11 |
Ralith |
a whole four
hours? |
| 04:38.15 |
Ralith |
you're
killing yourself, you know. |
| 04:38.48 |
pacman87 |
brlcad
doesn't need sleep, he just takes naps every few days |
| 04:38.49 |
brlcad |
I know,
saddens the soul |
| 04:40.02 |
brlcad |
need some
rest before the really hard workout though.. or it can be a painful
row |
| 04:40.03 |
brlcad |
waves |
| 04:41.54 |
AlexandreGuedes_ |
April Fool's
Day |
| 04:42.32 |
AlexandreGuedes_ |
In Brazil is
already |
| 04:43.58 |
AlexandreGuedes_ |
there is
april fool's day in USA ? |
| 04:44.21 |
pacman87 |
yes |
| 04:44.56 |
starseeker |
laments the "All news sites will be annoying for a day"
day |
| 04:45.33 |
starseeker |
although it
is morbidly amusing to see slashdot's standards for news actually
drop - hard to believe it's possible :-P |
| 04:50.31 |
Ralith |
slashdot?
Lower its standards? |
| 04:50.33 |
Ralith |
Madness! |
| 05:11.00 |
yukonbob |
checking
whether the Standard C++ library is available... no |
| 05:11.10 |
yukonbob |
^---... but
no "loud complaints" |
| 05:33.59 |
Ralith |
weird. |
| 06:02.03 |
yukonbob |
will review tmorrow |
| 06:02.11 |
yukonbob |
for now,
zeeeeeeeeeee |
| 06:02.40 |
pacman87 |
goodnight |
| 06:02.53 |
pacman87 |
still has 200 pages of gov to read for the test
thurs |
| 06:12.00 |
AlexandreGuedes_ |
good
night |
| 07:13.53 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:06.35 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:25.41 |
*** join/#brlcad _sushi__
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:42.33 |
brlcad |
yawns |
| 08:48.39 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:10.53 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 09:56.51 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:01.41 |
mafm |
hi
pplz |
| 10:02.24 |
brlcad |
howdy
mafm |
| 10:03.46 |
mafm |
mmm, it's too
early, go back to bed brlcad! |
| 10:03.48 |
mafm |
:P |
| 10:03.53 |
brlcad |
heh |
| 10:07.53 |
Ralith |
hey
mafm |
| 10:07.56 |
Ralith |
brlcad
doesn't have a bed |
| 10:08.01 |
Ralith |
he just
slumps over on his desk now and then |
| 10:09.12 |
brlcad |
back in my
younger days, I could just lay down right on the floor, however
hard/cold, wherever I was at and have a perfectly good couple-hour
nap |
| 10:09.45 |
mafm |
oh, I see...
so that's the backspace key stamped in his forehead...
:) |
| 10:11.06 |
mafm |
hmm, so the
number of proposals for gsoc is that low, really? |
| 10:11.20 |
mafm |
(I mean in
general, not only in brl-cad) |
| 10:11.28 |
Ralith |
shh, don't
tell anyone |
| 10:11.31 |
Ralith |
I like my
good odds :] |
| 10:11.34 |
brlcad |
:) |
| 10:11.44 |
_sushi_ |
brlcad: what
do you call younger days? |
| 10:11.47 |
hippieindamakin8 |
mafm, many
like me are still working on them :) |
| 10:11.54 |
hippieindamakin8 |
_many_ |
| 10:12.18 |
Ralith |
many? |
| 10:12.52 |
brlcad |
_sushi_: days
before today |
| 10:13.01 |
_sushi_ |
I turned 30
recently |
| 10:13.05 |
_sushi_ |
I feel like
middle aged |
| 10:13.07 |
Ralith |
hippieindamakin8: whatchya planning on
applying for? |
| 10:13.10 |
_sushi_ |
I am already
training the coffin jump |
| 10:13.25 |
mafm |
hippieindamakin8: well, deadline is in a
couple of days :) |
| 10:13.47 |
_sushi_ |
I didn't
manage to get a relationship before 30 |
| 10:14.02 |
_sushi_ |
But with a
lot of hard work I at least managed to get sex before 30! Wohoo! I
made it! |
| 10:14.02 |
Ralith |
aw. |
| 10:14.06 |
Ralith |
hehe |
| 10:14.14 |
hippieindamakin8 |
Ralith, mafm
i am applying for the brep evaluation |
| 10:14.18 |
_sushi_ |
Lot of brute
force sifting through the population helped |
| 10:14.19 |
Ralith |
oo,
cool! |
| 10:14.23 |
Ralith |
best of luck
to you! |
| 10:14.26 |
Ralith |
that stuff
needs doing. |
| 10:14.37 |
_sushi_ |
brlcad: how
old are you now? |
| 10:14.47 |
mafm |
_sushi_:
congrats! |
| 10:14.50 |
_sushi_ |
brlcad: do
you have kidneys like bricks now from sleeping on cold
floor? |
| 10:14.51 |
_sushi_ |
mafm:
thanks |
| 10:15.06 |
hippieindamakin8 |
Ralith, i am
going through some research papers. Busy schedule at school is
making it really difficult for me to concentrate here
:( |
| 10:15.08 |
brlcad |
nope |
| 10:15.30 |
Ralith |
hippieindamakin8: just don't hestitate to
submit a draft app early. |
| 10:15.36 |
Ralith |
you can
always revise. |
| 10:15.41 |
hippieindamakin8 |
Ralith, sure
:) |
| 10:15.54 |
brlcad |
mostly just
back pain from having too much bad posture, accumulated over time
-- only reason floor-sleeping isn't so satisfying now |
| 10:16.23 |
Ralith |
I can only
floorsleep and such when I'm really short on rest |
| 10:16.27 |
Ralith |
and I'm
pretty young |
| 10:17.04 |
brlcad |
congratulates _sushi_ for getting his cherry popped before
30. heh. |
| 10:17.07 |
Ralith |
guess that
comes from having a bed right next to my workstation |
| 10:17.14 |
_sushi_ |
lol |
| 10:17.24 |
_sushi_ |
I am sure
there are nerds who get even worse rate than 30 years |
| 10:17.33 |
mafm |
brlcad: odd,
I have a hairdresser friend who lies in the floor after work, her
backache is relieved |
| 10:17.36 |
Ralith |
did RMS ever
get laid? |
| 10:18.09 |
_sushi_ |
RMS might
profit from a gym |
| 10:18.13 |
brlcad |
mafm:
hopefully not at the office.. lot of hair on the floor
:) |
| 10:18.34 |
mafm |
Ralith: he
did AFAIK, at least he had a mexican girlfriend a while ago (that's
why he learned spanish) |
| 10:18.50 |
_sushi_ |
oh |
| 10:18.55 |
_sushi_ |
I hope he
didn't manage that before 30 |
| 10:19.00 |
_sushi_ |
because then
I would feel really asocial |
| 10:19.03 |
Ralith |
lol |
| 10:19.06 |
_sushi_ |
Girlfriend! |
| 10:19.11 |
_sushi_ |
I didn't even
get into that level. |
| 10:19.14 |
_sushi_ |
What's the
cheat code? |
| 10:19.28 |
mafm |
brlcad: I
guess that he does it privately, but I'm not so intimate friend as
to ask some of the related questions :) |
| 10:19.28 |
_sushi_ |
iddbf? |
| 10:19.52 |
mafm |
well,
stallman must be in his fifties or older now |
| 10:19.57 |
_sushi_ |
OK
good |
| 10:20.06 |
_sushi_ |
there are
still people who are more asocial than me |
| 10:20.07 |
Ralith |
considering
he was in college in the 80s, right? |
| 10:20.22 |
brlcad |
he's
56 |
| 10:20.25 |
mafm |
he was
already at mit ai lab in the late 70s I think |
| 10:20.34 |
Ralith |
oh,
right |
| 10:20.49 |
hippieindamakin8 |
=> RMS
might have been a hippie too :P |
| 10:20.56 |
Ralith |
I'm always
disconcerted when I hear about AI research that long
ago |
| 10:21.06 |
Ralith |
I generally
think of computer research as stuff that gets worked out pretty
quick |
| 10:21.31 |
_sushi_ |
hippieindamakin8: I guess he still looks
like one |
| 10:21.42 |
mafm |
Linus met his
wife teaching inet to non-it ppl at univ, telling her to write him
email for practicing (nice trick, that) |
| 10:21.47 |
brlcad |
Ralith: it
often is .. then there are research papers for three decades
afterwards that all claim to have done it again for the first time
;) |
| 10:22.03 |
Ralith |
lol |
| 10:22.15 |
Ralith |
reminds me of
something I've noticed |
| 10:22.49 |
Ralith |
having toyed
with graphics programming some, I've noticed that it usually takes
5+ years for something somebody successfully demonstrated in a
thesis to actually be implemented in a commercial game |
| 10:22.53 |
mafm |
most of the
work in mit ai lab by that time was to create OSs and lisp
machines, I think :) |
| 10:23.14 |
brlcad |
much of it is
solved, but limited by cpu power .. so as the chips get faster, old
ideas that were completely impractical become entirely practical
and implementable |
| 10:24.49 |
brlcad |
Ralith:
that's about the general trend I often see too, similar to how the
emerging technology that is showcased at siggraph .. often becomes
commercial commonplace about 3-6 years after if it's a hot
topic |
| 10:25.07 |
mafm |
IIRC (from
Free as in Freedom book and similar resources), Stallman stallet to
get mad at software practices when ppl took stuff out of mit to
implement LISP machines commercially |
| 10:25.49 |
mafm |
he started to
copy and reimplement the new features like crazy so that mit
versions were equally capable as commercial versions |
| 10:25.54 |
hippieindamakin8 |
Ralith, but
rt now with the GPUs in the market, the implementation would be
smooth |
| 10:26.01 |
brlcad |
like seeing
epaper five years ago at siggraph, and this past year seeing it
become reality with amazon's kindle in 2007 |
| 10:26.05 |
Ralith |
brlcad: that
seems really long, even considering the devtime of a big
project |
| 10:26.07 |
hippieindamakin8 |
rather
awesome GPUs |
| 10:26.15 |
Ralith |
hippieindamakin8: I dunno about this whole
raytracing thing. |
| 10:26.50 |
Ralith |
it amounts to
using slower techniques for less appealing visuals |
| 10:26.54 |
_sushi_ |
self-pities |
| 10:27.13 |
mafm |
saw the same in grid technologies... in example cloud
computing, already present in some congresses years ago, like the
Amazon guy |
| 10:28.27 |
Ralith |
cloud
computing is just silly. |
| 10:28.29 |
brlcad |
Ralith: the
technique becomes faster than the raster approaches as soon as you
turn "all" the features on |
| 10:28.30 |
hippieindamakin8 |
Ralith,
doesnt that imply that faster computation = better
visuals |
| 10:28.34 |
Ralith |
I, for one,
will not give up control over my system. |
| 10:28.46 |
Ralith |
hippieindamakin8: but we already *have*
great visuals., |
| 10:28.51 |
Ralith |
no reason to
sacrifice them. |
| 10:29.15 |
brlcad |
that is, to
get the same picture, all the hacks and hoops you end up needing
disappear with a much more simple algorithm |
| 10:29.50 |
mafm |
Ralith: it's
more practical for startups demanding big storage or processing
growing by the hour, think of flick-like sites when
starting |
| 10:29.51 |
Ralith |
brlcad: for
practical purposes, though, it's still much slower. |
| 10:29.59 |
Ralith |
eventually,
when power is moot, sure |
| 10:30.01 |
brlcad |
for current
purposes |
| 10:30.02 |
Ralith |
not
now. |
| 10:30.22 |
Ralith |
mafm: for
hosting a website or something, sure |
| 10:30.32 |
brlcad |
the only
reason it's even being talked about is because at the high end of
the spectrum, it's starting to get close |
| 10:30.33 |
mafm |
flickr, or
whatever the spelling :) |
| 10:30.56 |
brlcad |
the cost of a
superbly complex raster system with great visuals, something like
the complexity of the crysis engine |
| 10:31.14 |
brlcad |
starts
approaching the cost of advanced ray-tracing that gives equivalent
results |
| 10:31.24 |
mafm |
they're
trying to lure scientists to use clouds too... but transferring
multi-GB datasets back and forth for processing for a few hours
it's not very nice :D |
| 10:32.00 |
mafm |
but the
personal computing, a la windows7, I think that it's a bit of
non-sense right now (and I also don't like where all of this is
heading) |
| 10:32.24 |
Ralith |
I wouldn't be
too concerned; MS certainly won't keep its marketshare
forever. |
| 10:32.51 |
Ralith |
and so far
nobody's tried hardware lockin to a particular system, beyond the
issues of driver support which are lessening these
days. |
| 10:34.19 |
brlcad |
Ralith:
speaking of seeing things in research that deploy 5 or so years
later -- that's been the raging research competition between the
powerhouses, the likes of Intel and NVIDIA, and all the chest
thumping about who can do ray-tracing better/faster |
| 10:34.34 |
brlcad |
because it's
expected that tipping point will happen within a couple
years |
| 10:34.34 |
Ralith |
really?
nVidia's getting in on that? |
| 10:34.38 |
Ralith |
I thought it
was mostly intel |
| 10:34.56 |
brlcad |
oh yeah,
nvidia's been right there in the research |
| 10:35.13 |
Ralith |
hm. |
| 10:35.22 |
Ralith |
well, I'll be
interested to see what results |
| 10:35.26 |
brlcad |
had a massive
session at siggraph just last year showcasing their implementation
of ray-tracing on the gpu in response to intel's massive demo of
larrabe |
| 10:35.40 |
brlcad |
it's been
going back and forth |
| 10:37.46 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-155-247.3g.claro.net.br) |
| 10:38.16 |
hippieindamakin8 |
has seen the examples of ray tracing on Nvidia CUDA machines
and can say that they were beyond brilliant |
| 10:38.20 |
Ralith |
what
interests me about larrabee is (if I understand it correctly) the
freedom from API it offers. |
| 10:38.48 |
Ralith |
I imagine
we'll see all sorts of things when people are no longer limited to
what's defined in a spec like that |
| 10:39.19 |
mafm |
Ralith: a
gsoc idea you might be interested in ;) : Amazon EC2 AMI Images and
tools: create official Debian images and tools for the Amazon EC2
cloud-computing environment |
| 10:39.43 |
hippieindamakin8 |
Ralith, CUDA
is also very good in that respect |
| 10:40.01 |
Ralith |
hippieindamakin8: eh, it'll be a while
before nvidia's hardware is truly general-purpose-ified |
| 10:40.12 |
Ralith |
oh there's an
idea |
| 10:40.20 |
Ralith |
brlcad: has
anyone considered porting librt to CUDA? |
| 10:40.32 |
brlcad |
"porting" it?
heh |
| 10:40.33 |
Ralith |
or bits
thereof, at least? |
| 10:40.36 |
hippieindamakin8 |
i can
consider that :) |
| 10:40.39 |
Ralith |
isn't sure what would be involved |
| 10:41.36 |
brlcad |
there's ways
cuda could be leveraged -- it'd take a fair bit of structuring but
could be leveraged at the primitive level fairly
decently |
| 10:42.19 |
Ralith |
then again, I
suppose librt's pretty damn fast anyway |
| 10:42.29 |
Ralith |
so not much
need. |
| 10:42.37 |
brlcad |
would have to
improve support for ray-bundling, and reimplement most of the
complex prep() and shot() routines for most primtives to be
vectorized |
| 10:43.09 |
Ralith |
wouldn't that
much be of benefit anyway on modern CPUs? |
| 10:43.44 |
mafm |
btw, isn't
there any plan for multi-threading? it's beeing a trend in the last
few years for most projects |
| 10:44.05 |
brlcad |
nah, you
could certainly increase the performance of even librt using it --
but you'd also get just as much benefit from working on things like
ray bundling, cacheline fitted data structures, cache coherent
structure access, and vectorized ray evaluation |
| 10:44.34 |
Ralith |
raytracing is
very parallelizable, I believe. |
| 10:44.41 |
brlcad |
should give
an increase on optical image rendering on the order of around
2x-20x if you did *everything* |
| 10:44.57 |
Ralith |
but I'm not
really convinced that there's much point |
| 10:45.02 |
brlcad |
of course
it's parallelizable, brl-cad's rt was the first to show that
:) |
| 10:45.08 |
Ralith |
hehe |
| 10:45.12 |
Ralith |
I mean, if I
can render havok in under a minute on consumer hardware |
| 10:45.16 |
``Erik |
obscenely
parallel, every primary could be its own thread |
| 10:45.44 |
``Erik |
parallel prep
would be awesome, though |
| 10:45.53 |
Ralith |
then again, I
don't have a very good idea of what normal model complexity tends
to be |
| 10:46.03 |
brlcad |
Ralith: it's
the difference between taking 30 seconds and potentially 2 frames
per second interactive |
| 10:46.12 |
``Erik |
has working geometry that takes about 60 seconds to prep and
30 to raytrace :( |
| 10:46.59 |
Ralith |
that's a lot
of prep |
| 10:47.11 |
Ralith |
brlcad: fair,
and I suppose in not too long it'll be even closer to
raeltime. |
| 10:47.20 |
Ralith |
realtime* |
| 10:47.45 |
brlcad |
it makes a
lot of existing models realtime |
| 10:48.39 |
brlcad |
the adrt
stuff that erik has been working on does much of the tricks for
polygonal models, gets a decent performance boost that allows for
realtime raytraced interaction |
| 10:48.43 |
Ralith |
realtime
librt would be neat. |
| 10:49.05 |
brlcad |
http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas#CSG_ray-trace_optimizations |
| 10:49.37 |
brlcad |
if all done,
those would likely result in massive performance boosts, order of
magnitude sorts |
| 10:49.46 |
Ralith |
damn. |
| 10:50.11 |
brlcad |
exploiting
cache coherency, branch minimization, data vectorization,
accelerated spacial partitioning, and other optimization
techniques |
| 10:50.34 |
``Erik |
os/embedded/criticalsystems geeks would
argue that you mean interactive, not realtime :) |
| 10:51.11 |
Ralith |
:P |
| 10:51.25 |
Ralith |
os/embedded/criticalsystems geeks don't do
much raytracing. |
| 10:51.37 |
``Erik |
erm, you
might be surprised |
| 10:51.45 |
Ralith |
hm? |
| 10:52.05 |
mafm |
they raytrace
models of lara croft in their basements! |
| 10:52.28 |
``Erik |
a lot of
raytracing has nothing to do with generating images :) |
| 10:52.43 |
mafm |
soft realtime
is ok for multi-media |
| 10:53.03 |
Ralith |
``Erik:
that's why I said *much* |
| 10:53.06 |
Ralith |
rather than
any. |
| 10:53.52 |
mafm |
ah, they
might use some of it for physics? |
| 10:55.06 |
Ralith |
raytracing
for physics? |
| 10:55.08 |
Ralith |
never heard
of that. |
| 10:55.15 |
Ralith |
for that
matter, physics in realtime? |
| 10:55.30 |
Ralith |
(that is,
technical realtime, rather than interactive) |
| 10:55.36 |
mafm |
I mean
representations of models from data gathered by radar-like devices
and such, automatic control of vehicles (mars robots) |
| 10:56.11 |
mafm |
I don't know
if some techniques related to raytracing could be used for
that |
| 10:56.15 |
``Erik |
O.o so you've
never heard of things like collision detection systems, combat
HUDs, flight control systems, etc, ralith? |
| 10:56.34 |
Ralith |
``Erik: never
imagined that that sort of thing used raytracing. |
| 10:56.35 |
Ralith |
tmyk! |
| 10:57.06 |
Ralith |
thinks HUDs are awesome and should be
everywhere. |
| 10:57.21 |
``Erik |
I d'no the
guts, I do know that there's often raytracing to do physics and ai
bits in ogl and d3d games |
| 10:57.22 |
Ralith |
augmented
reality ftw. |
| 10:57.29 |
Ralith |
well, that's
not 'realtime' |
| 10:58.00 |
``Erik |
so I coudl
imagine 'real life' systems (or high end simulators) doing the
same |
| 10:58.47 |
Ralith |
but... that's
still not realtime systems, is it? |
| 11:01.07 |
mafm |
I can see
many situations where that's useful |
| 11:01.15 |
mafm |
or will be
exploited |
| 11:01.27 |
``Erik |
*shrug* I
d'no, I can imagine a fair numberof scenarios where time guarantees
on raytracing could be handy |
| 11:04.01 |
Ralith |
I dunno if
it's used like that currently, though. |
| 11:04.02 |
mafm |
think of
rendering a scene with objects in the foreground with transparency
showing objects in the background visible |
| 11:04.02 |
mafm |
kind of
Terminator :) |
| 11:04.02 |
Ralith |
like I
said. |
| 11:04.02 |
Ralith |
We need HUDs
EVERYWHERE. |
| 11:04.02 |
``Erik |
(and I'm a
bit of an OS geek and have done simple embedded programming before,
so a bit sensitive on people propogating blizzards word
abuse) |
| 11:04.02 |
Ralith |
:D |
| 11:04.02 |
``Erik |
</rant>
:D |
| 11:04.25 |
``Erik |
most of my
personal projects right now fall into the soft realtime need, and
that's just cheezy web crap |
| 11:04.26 |
mafm |
:D |
| 11:04.47 |
mafm |
hates cheezy web :( |
| 11:05.15 |
``Erik |
but it's good
cheese! real cheese, not processed cheese |
| 11:05.41 |
Ralith |
yum! |
| 11:05.44 |
``Erik |
that'sa gouda
cheesa! |
| 11:07.46 |
mafm |
lol |
| 11:07.50 |
``Erik |
back to librt
speed improvements, there's been discussion on replacing
src/librt/primitive/bot/* with src/adrt/libtie/* stuff for the
speed boost, but making libties tricks ubiquitous through librt
would be awesome |
| 11:08.41 |
*** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 11:08.41 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 11:08.41 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 11:08.41 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 11:08.41 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 11:09.27 |
``Erik |
postage stamp
bundling, cache coherency, improved scene partition (I'll bring up
my old argument that tree based approaches have necessary slow
warts, a graph with neighbor awareness (see portal/sector stuff)
would be preferable) |
| 11:09.55 |
``Erik |
portable
vectorization with fallback for cpu's lacking simd
instructions |
| 11:10.32 |
``Erik |
making prep
way faster would be awesome, too |
| 11:11.53 |
Ralith |
well, I'm
heading to bed in preparation for a long flight
tomorrow. |
| 11:12.09 |
Ralith |
I guess I'll
assume the fact that I haven't gotten any proposal feedback yet a
good thing? |
| 11:12.29 |
brlcad |
yep |
| 11:12.34 |
Ralith |
:) |
| 11:12.40 |
``Erik |
and you can
render havoc pretty fast on consumer hardware... if you're doing a
low resolution and low quality rendering. |
| 11:12.52 |
Ralith |
true,
true |
| 11:13.11 |
``Erik |
try doing a
poster grade render :) now try doing it with photon mapping (or mlt
if someone pics it up) |
| 11:13.28 |
Ralith |
I'll leave
that one running overnight. |
| 11:13.42 |
``Erik |
poster grade
with simple phong was around 24 hours an image on high end
gear |
| 11:13.42 |
Ralith |
luckily, I
don't generally need poster-grade renders to model
>_> |
| 11:14.31 |
``Erik |
when ya need
14 images in 2 days, ... I was scrounging machines for that
:) |
| 11:15.06 |
``Erik |
and I had to
post-process the images because they came out a little too dark and
I didn't have the time to re-render them :( |
| 11:15.20 |
``Erik |
so, yeah,
there's a point :) |
| 11:15.30 |
mafm |
"night"
Ralith :D |
| 11:15.35 |
Ralith |
night! |
| 11:16.08 |
``Erik |
have a good
flight :) |
| 11:19.47 |
Ralith |
thanks |
| 11:26.35 |
madant |
brlcad: :)
for user-accessibility should i think about modifications in mged
or integration with libged ? |
| 11:26.59 |
madant |
and how woudl
it fit into the new gui plan |
| 11:30.54 |
madant |
i feel like
sticking to the capability to make a constraint object within mged
sounds good |
| 11:31.43 |
madant |
and then a
user command like solve(constr.1) or something similar |
| 11:32.20 |
madant |
which would
evaluate , display solution space / update geometry |
| 11:33.38 |
CIA-40 |
BRL-CAD:
03Erik 07http://brlcad.org * r1321
10/wiki/Google_Summer_of_Code/Project_Ideas: add g_qa feature
request |
| 11:37.04 |
d-lo |
Mornin
all! |
| 11:43.41 |
``Erik |
silence,
maggot! |
| 11:43.44 |
``Erik |
I mean, uh,
hey |
| 11:44.13 |
d-lo |
You going on
the YUMMY E39 party crash? |
| 11:44.31 |
``Erik |
with what? I
blew my load on slz |
| 11:44.54 |
d-lo |
wishes there could be asset transfers in the game
:/ |
| 11:45.03 |
``Erik |
heh,
indeed |
| 11:45.21 |
d-lo |
...would
totaly ruin the game balance, but would be cool for a little while
:) |
| 11:46.05 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 11:46.07 |
``Erik |
http://www.collegehumor.com/video:1905754
heh |
| 11:51.25 |
mafm |
hi
d-lo |
| 11:51.41 |
d-lo |
howdy
mafm |
| 11:52.03 |
mafm |
it seems that
LHC finally made it: "I can confirm that, yes, the first stages of
the experiment resulted in the appearance of a miniscule black
hole," said the spokesperson to gathered reporters on Monday. "The
black hole is being kept under quarantine and our scientists have
been monitoring its progression," he explained. --http://www.thetechherald.com/article.php/200914/3354/ |
| 11:52.18 |
mafm |
so you were
right d-lo :P |
| 11:52.57 |
d-lo |
``Erik: Do
you know whats up with Hellbent? Profile shows inactive 74
days... |
| 11:53.01 |
mafm |
I'd say,
bring Ballmer to throw a few chairs at it to tame it down
:) |
| 11:54.05 |
d-lo |
Hrm, if I had
to pick... I dunno which I would go for: Obliteration via Nuclear
war, or sucked into a Black Hole that started in Europe....
:/ |
| 11:54.59 |
d-lo |
lol: "Many
had bitterly said the consequences could be as extreme as the Earth
being sucked into the black hole the LHC collisions may create as a
side effect of the experiment. Others claimed time travellers with
more sophisticated technology than ours could make use of the hole
to invade the Earth and enslave mankind." |
| 11:55.05 |
d-lo |
Too many
scifi movies... |
| 11:58.19 |
mafm |
:D |
| 11:58.34 |
mafm |
the bad thing
is that many ppl will believe this news :| |
| 11:58.54 |
``Erik |
... I hate
april 1st |
| 11:59.02 |
``Erik |
no, d-lo, no
clue :/ |
| 11:59.23 |
mafm |
let's hope
scientology church take it seriously and immolate themselves :P
:) |
| 11:59.59 |
``Erik |
no, they'd
just buy a lot of DC-9's and fly to another planet with
volcanos |
| 12:00.11 |
``Erik |
would donate $10 to help them get to venus
D: |
| 12:00.12 |
``Erik |
:D |
| 12:00.48 |
``Erik |
('cept beck,
he can stay) |
| 12:00.58 |
mafm |
would double that! |
| 12:05.04 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.209.254) |
| 12:06.11 |
Maloeran |
Ahah, neat
article mafm |
| 12:07.31 |
d-lo |
``Erik: got
any 'cyclers built yet? |
| 12:28.44 |
mafm |
:) |
| 12:31.31 |
*** join/#brlcad cad48
(n=c1e1bb42@bz.bzflag.bz) |
| 12:31.35 |
*** part/#brlcad cad48
(n=c1e1bb42@bz.bzflag.bz) |
| 12:45.51 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:04.26 |
d-lo |
``Erik:
E37:73:06:31 |
| 13:05.52 |
``Erik |
aight,
putting together a maid service |
| 13:06.09 |
``Erik |
might take a
couple hours, I tend to be up in the northern part |
| 13:07.15 |
``Erik |
1:10 to get
the 74 jg, 5 minutes to hop over to that astro |
| 13:08.55 |
d-lo |
yeah, I have
most of your astros bookmarked so they show up on the Map
;) |
| 13:09.05 |
``Erik |
pheer
O.o |
| 13:09.09 |
``Erik |
jotes |
| 13:09.16 |
``Erik |
jots down a note... "don't piss dave off" |
| 13:10.42 |
d-lo |
....hrmm...
no fleet, most locations known..... hrm.... *EVIL
LAUGH* |
| 13:10.58 |
d-lo |
=D |
| 13:11.17 |
``Erik |
hm, yes, 15
prings, 15 pshields, 3-4 dn's, and a fighter cloud on each,
definitely soft targets :D |
| 13:11.29 |
``Erik |
no MOBILE
fleet |
| 13:11.53 |
d-lo |
True. true.
but how dangerous is a person who just doesn't care about fleet
anymore? ;) |
| 13:11.54 |
``Erik |
yoda is slz
gm now, btw |
| 13:12.16 |
d-lo |
...wha?
aren't we at war with slz? |
| 13:12.33 |
``Erik |
unofficially |
| 13:12.54 |
d-lo |
why that
little green shit. lol |
| 13:12.58 |
``Erik |
more of a
"damnit, we're not farms, and you're warring on a madp" |
| 13:13.17 |
``Erik |
unfortunately, he has intel on our
strongholds :( |
| 13:13.30 |
``Erik |
though I
think he was like 32 or 33 |
| 13:13.58 |
``Erik |
mebbe he'll
get them to back off of fng *shrug* who knows |
| 13:14.36 |
``Erik |
that crash
eliminated over 1/3 of slzs total fleet, mostly of their higher
level members, so they're not exactly a huge threat |
| 13:14.37 |
d-lo |
well,
"personal vendettas" can be really fun ;) |
| 13:16.34 |
``Erik |
ooh, you've
been called out on your hit, ya didn't post br |
| 13:17.54 |
d-lo |
*shrug* I'll
get to it ;) |
| 13:43.56 |
*** join/#brlcad madant
(n=madant@117.196.133.191) |
| 13:53.10 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-190-186.3g.claro.net.br) |
| 13:56.45 |
brlcad |
madant:
either really -- a libged modification is an mged modification --
it adds a new command |
| 13:57.58 |
madant |
was thinking whether a menu option would be nice.. but i
guess a functioing command interface is a more important target
:) |
| 13:58.50 |
madant |
needs to seriously go through libged after months of
stalling |
| 14:02.51 |
brlcad |
libged is
easy -- if you can make a simple test program with argc/argv, that
converts very simply over to a libged function |
| 14:04.33 |
madant |
hmm..
convenient :) ( evil grin ) |
| 14:07.41 |
madant |
oh and
brlcad, i ran a sub 6 minute mile ;) 2.1 km in 7:49 : |
| 14:07.50 |
madant |
:D felt like
i was going to die |
| 14:09.24 |
brlcad |
excellent |
| 14:11.38 |
*** join/#brlcad _sushi__
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 14:30.38 |
hippieindamakin8 |
hey madant
brlcad |
| 14:31.24 |
hippieindamakin8 |
madant, just
went out on a jog of 2 km (in arnd 13 min) |
| 14:33.39 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 14:46.05 |
*** join/#brlcad kanzure__
(n=bryan@66.112.232.173) |
| 14:53.45 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 14:56.10 |
kanzure |
brlcad: I'll
try to send out an email in a few hours about the web repository
ideas. |
| 14:56.33 |
kanzure |
but
pre-emptive constructive criticism about better ideas would be
acceptable :) |
| 15:13.52 |
*** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
[NETSPLIT VICTIM] |
| 15:21.31 |
brlcad |
hello
hippieindamakin8 |
| 15:21.51 |
brlcad |
kanzure:
please do |
| 15:22.03 |
*** join/#brlcad madant
(n=madant@117.196.146.22) |
| 15:22.10 |
brlcad |
it'll be a
rush the closer to the deadline it gets, and become harder to get
good responses/reviews in the later they are |
| 15:34.35 |
*** join/#brlcad andrecastelo
(n=andrecas@189.71.13.123) |
| 15:35.04 |
*** join/#brlcad dreeves
(n=c752f34a@bz.bzflag.bz) |
| 15:36.22 |
andrecastelo |
hi brlcad,
``Erik |
| 15:36.34 |
andrecastelo |
:) |
| 15:46.34 |
CIA-40 |
BRL-CAD:
03117.196.146.22 07http://brlcad.org * r1322
10/wiki/User:Homovulgaris: /* Abstract */ main objective
changed |
| 15:48.23 |
madant |
hippieindamakin8, speed up ;) unless of
course you were enjoying some wonderful scenery while
jogging |
| 15:49.40 |
hippieindamakin8 |
madant, in
iit kanpur's stadium .. there wont be any scenery there nor chiks
:) |
| 15:50.26 |
madant |
haha :) ah u
are from iitk .. kewl.. i hear it is a very study-oriented place
:P |
| 15:50.50 |
madant |
u doing UG
there ? which subbject ? |
| 15:50.55 |
madant |
s/subbject/dept. |
| 15:54.22 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187-24-41-215.3g.claro.net.br) |
| 15:55.08 |
hippieindamakin8 |
madant, dude
yeah !that is the reason writing an app becomes difficult. majoring
in mechanical engineering.(subject of interest:computational
geometry) |
| 16:08.39 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1323 10/wiki/User:Homovulgaris: /* Proposal */ change of
priorities |
| 16:18.16 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1324 10/wiki/User:Homovulgaris: /* Schedule */ |
| 16:19.26 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1325 10/wiki/User:Homovulgaris: /* Other Notes */ |
| 16:19.34 |
madant |
loves cia wiki updates ;) |
| 16:21.19 |
d-lo |
that you
making all that IRC vomit? :) |
| 16:21.41 |
madant |
moi
:) |
| 16:22.55 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1326 10/wiki/User:Homovulgaris: Text shifted to Notes since
priorities have been changed |
| 16:24.07 |
madant |
hippieindamakin8, :) which year are u in
? |
| 16:25.52 |
hippieindamakin8 |
4rth |
| 16:38.49 |
hippieindamakin8 |
starts editing the wiki <but feels that the cia updates
would rather embaress him> |
| 16:41.44 |
starseeker |
nah, go for
it - we've all been there |
| 16:44.55 |
hippieindamakin8 |
starseeker,
:) thanks and did u find any thing better w.r.t the problem u were
working on ? |
| 16:45.41 |
starseeker |
brlcad and I
discussed it some |
| 16:46.00 |
starseeker |
probably want
to back up and see if we really need the solution to that specific
problem |
| 16:46.09 |
hippieindamakin8 |
:) |
| 16:47.07 |
hippieindamakin8 |
starseeker,
once i submit my application, i shall send in a mail(read as spam)
on the list with my idea of the solution |
| 16:47.41 |
*** join/#brlcad PrezKennedyIII
(i=Matthew@whitecalf.net) |
| 16:47.59 |
starseeker |
sounds
good |
| 17:16.22 |
*** join/#brlcad dreeves
(n=c752f34a@bz.bzflag.bz) |
| 17:34.50 |
``Erik |
if you feel
like it'd be embarrassing, just remember, were still too busy
laughing at starseeker to bother picking on you ;)
*duck* |
| 17:36.31 |
d-lo |
lol |
| 17:36.49 |
d-lo |
You can also
blame any mistakes you make on the LHC. |
| 17:36.49 |
``Erik |
that astro is
swept, dave |
| 17:37.17 |
d-lo |
saw that.
5200 cyclers is hardly 'no mobile' =D |
| 17:38.08 |
``Erik |
woulda
figured the 17000 ft's and 240 hc's woulda gotten more
attention |
| 17:40.53 |
AlexandreGuedes |
hi |
| 17:41.17 |
AlexandreGuedes |
when I'm
compiling my build. |
| 17:41.30 |
AlexandreGuedes |
is normal a
lot of warning ? |
| 17:41.46 |
``Erik |
in the
src/other directory, yes... shouldn't be many outside of
that |
| 17:50.17 |
AlexandreGuedes |
i got some
errors |
| 17:50.52 |
AlexandreGuedes |
make[2]: ***
[libdm_la-color.lo] Error 1 |
| 17:51.37 |
AlexandreGuedes |
someone knows
this error? |
| 18:00.32 |
``Erik |
can you paste
more of the backlog to http://pastebin.bzflag.bz/ ? (the
actual error is before that line) |
| 18:07.11 |
AlexandreGuedes |
ok.. |
| 18:07.30 |
AlexandreGuedes |
http://pastebin.bzflag.bz/m6f0cdb29 |
| 18:15.13 |
madant |
AlexandreGuedes, error: X11/Xlib.h: No
such file or directory = you don't have the required x11-dev
libraries |
| 18:15.19 |
madant |
which
platform are you on |
| 18:15.29 |
AlexandreGuedes |
ubuntu |
| 18:16.10 |
madant |
install
libx11-dev |
| 18:16.30 |
madant |
and libxi-dev
too |
| 18:16.33 |
AlexandreGuedes |
ok... |
| 18:18.26 |
AlexandreGuedes |
thanks |
| 18:18.28 |
hippieindamakin8 |
madant, that
is for most of the debian based distro users :) |
| 18:18.41 |
AlexandreGuedes |
apt-get
install xserver-xorg-dev |
| 18:18.54 |
AlexandreGuedes |
:) |
| 18:22.55 |
madant |
hippieindamakin8, true i remember a
similar situation from a couple of days ago too IIRC |
| 18:23.19 |
hippieindamakin8 |
madant, i too
encountered the same problem. :) |
| 18:23.42 |
madant |
ah.. so it
was u ? :D |
| 18:23.52 |
hippieindamakin8 |
madant, it
was me an year ago :P |
| 18:23.59 |
madant |
ah ok
:D |
| 18:24.09 |
hippieindamakin8 |
loves debian and KDE |
| 18:24.48 |
madant |
AlexandreGuedes, I am not sure if the
package name is xserver-xorg-dev for debian.. use apt-file search
feature for locating the correct packages ? |
| 18:25.48 |
AlexandreGuedes |
hmm
ok |
| 18:30.15 |
hippieindamakin8 |
madant, i
dont think xserver-xorg-dev has libx11-dev headers |
| 18:31.34 |
hippieindamakin8 |
AlexandreGuedes, apt-get install
xserver-xorg-dev libx11-dev libx9-dev |
| 18:32.06 |
hippieindamakin8 |
*libx9-dev/libxi-dev |
| 18:34.33 |
AlexandreGuedes |
hippieindamakin8: thanks |
| 18:34.44 |
madant |
does not even have xserver-xorg-dev installed
:D |
| 18:35.25 |
hippieindamakin8 |
madant,
interesting :) neways they are the development files |
| 18:35.28 |
AlexandreGuedes |
now think it
is ok |
| 18:35.31 |
hippieindamakin8 |
madant, which
distro ? |
| 18:35.39 |
madant |
debian
unstable |
| 18:35.58 |
hippieindamakin8 |
madant,
awesome |
| 18:36.43 |
madant |
whats awesome
about it :P I like it though :D |
| 18:37.33 |
hippieindamakin8 |
madant, i
meant i too use the same. i dont find many ppl who are using debian
unstable. |
| 18:38.25 |
madant |
OS space is
pretty huge :) |
| 18:51.41 |
mafm |
madant
rulez! |
| 18:51.59 |
mafm |
and
hippieindamakin8 rulez too :P |
| 18:53.00 |
madant |
oh and lets
not forget mafm :) |
| 18:53.13 |
madant |
people still
pester you about rand() :P |
| 18:53.15 |
madant |
? |
| 18:53.46 |
mafm |
that question
is not for me, I guess |
| 18:55.10 |
madant |
mafm: ah
maybe i am confused.. i remember some debian fan here being
pestered about int rand() { return 4; } or something similar
:) |
| 18:56.26 |
mafm |
ahh |
| 18:56.37 |
mafm |
well, that
part was a joke |
| 18:57.23 |
mafm |
but I was
suffering a lot because of that yes, my workmates were fedora
fascists :P |
| 18:58.02 |
mafm |
incidentally,
one of them got fed up of fedora in his laptop (unstable, sluggish,
etc) and installed debian a while after that :) |
| 18:58.08 |
mafm |
but I don't
work there anymore |
| 18:58.34 |
hippieindamakin8 |
madant, mafm
:P |
| 18:59.20 |
madant |
ah .. so my
memory doesnt suck :P |
| 19:03.49 |
kanzure |
brlcad: ok,
sent. |
| 19:26.14 |
AlexandreGuedes |
How I can
know which are the dependeces (libs) before start the make build
? |
| 19:27.29 |
hippieindamakin8 |
madant, i
cant find a create content tab in my profile :| on brlcad
wiki |
| 19:27.36 |
hippieindamakin8 |
wiki and the
site |
| 19:32.24 |
hippieindamakin8 |
madant, nvm
:| |
| 19:37.19 |
madant |
hippieindamakin8, whats the error
? |
| 19:37.47 |
madant |
AlexandreGuedes, did u try building again
? got any further errors ? |
| 19:38.27 |
hippieindamakin8 |
wanted to put
in my proposal |
| 19:38.28 |
hippieindamakin8 |
madant,
nthing resolved it |
| 19:38.32 |
AlexandreGuedes |
now i'm
having other error |
| 19:38.33 |
madant |
regarding a
list of dependencies.. well there aren't many.. :) x11, xi etc. are
a few .. but mostly brl-cad code is pretty self-sufficient
:) |
| 19:38.45 |
madant |
AlexandreGuedes, paste ;) |
| 19:39.43 |
AlexandreGuedes |
http://pastebin.bzflag.bz/d7f7f4d2e |
| 19:40.09 |
AlexandreGuedes |
undefined
reference to `X24_close_existing' ... |
| 19:41.17 |
madant |
hmm..
tclcad.. try ./configure with the --enable-all option and then
make |
| 19:43.17 |
AlexandreGuedes |
Ok, I'm
trying |
| 19:46.16 |
AlexandreGuedes |
Which
platform is better for build brlcad? |
| 19:47.05 |
mafm |
debian, of
course! |
| 19:47.23 |
mafm |
some
alianated ppl might suggest freebsd or something... :P |
| 19:48.30 |
hippieindamakin8 |
mafm, freebsd
is good too but they are incomprehensible philosophies |
| 19:48.38 |
mafm |
(just
kidding, any supported platform should do) |
| 19:48.40 |
hippieindamakin8 |
*they
are/they have |
| 19:48.52 |
mafm |
such
as? |
| 19:50.34 |
mafm |
brlcad: it's
full of spam http://pastebin.bzflag.bz/m16956c60 |
| 19:50.36 |
AlexandreGuedes |
madant: I had
already done, but this happening the same error |
| 19:50.52 |
hippieindamakin8 |
mafm, i ll
just get the list of them from my prof :P |
| 19:51.56 |
*** join/#brlcad andrecastelo
(n=andrecas@189.71.13.123) |
| 19:52.33 |
AlexandreGuedes |
madant: may i
should cleanup ? |
| 19:53.36 |
mafm |
AlexandreGuedes: it seems something
internal (funcions being in brlcad code, so maybe it's autoconf
missing something), you might want to wait for ``Erik or brlcad to
come around |
| 19:53.45 |
brlcad |
~dreeves++ |
| 19:53.59 |
mafm |
a cleanup and
--enable-all might help, though |
| 19:55.28 |
AlexandreGuedes |
thanks |
| 19:55.41 |
AlexandreGuedes |
i ll try
it |
| 19:56.41 |
AlexandreGuedes |
got the
source from sourceforge, there are difference from svn source
? |
| 19:56.49 |
AlexandreGuedes |
i
got* |
| 19:58.19 |
CIA-40 |
BRL-CAD:
03brlcad * r34129 10/brlcad/trunk/doc/README.Linux: note that
ubuntu/debian folks should install xserver-org-dev libx11-dev and
libxi-dev |
| 19:59.58 |
brlcad |
mafm, yep,
the pastebin doesn't have any spam preventions .. gets hit every
couple minutes |
| 20:00.04 |
brlcad |
feel free to
fix that ;) |
| 20:00.05 |
*** join/#brlcad madant_
(n=madant@117.196.128.14) |
| 20:00.34 |
brlcad |
AlexandreGuedes: svn sources are the very
latest, source tarball is our last release |
| 20:00.52 |
brlcad |
for gsoc,
you'll want to be using the latest svn sources |
| 20:01.24 |
*** join/#brlcad andax
(n=andax__@d213-102-40-30.cust.tele2.ch) |
| 20:01.39 |
AlexandreGuedes |
i'll start a
checkout just now |
| 20:09.31 |
mafm |
dunno
anything about pastebins :( |
| 20:12.50 |
brlcad |
mafm: nor do
I, don't need to know much about pastebin to run one and to install
a captcha so it doesn't get spammed ;) |
| 20:16.40 |
``Erik |
recaptcha is
already installed on that box, right? just a matter of figuring out
how to wire it into the php? |
| 20:17.50 |
brlcad |
yeah,
recaptcha is tiny, just a few files |
| 20:18.06 |
brlcad |
just usually
have to add a few lines to whatever form page |
| 20:18.17 |
mafm |
I thought
that it was some kind of lil' specialized cms |
| 20:18.27 |
mafm |
erm |
| 20:18.28 |
brlcad |
heck,
upgrading the pastebin might have a captcha option |
| 20:18.40 |
mafm |
I'm busy with
miss LH, she doesn't like me! :P |
| 20:18.53 |
brlcad |
she say
no? |
| 20:20.49 |
mafm |
more or
less |
| 20:23.09 |
brlcad |
well, is it
more or is it less? :) |
| 20:24.26 |
madant_ |
:D |
| 20:26.37 |
mafm |
it's less
than more, but less is more |
| 20:26.56 |
mafm |
it all
depends on the meaning of "enrolled", I can't get such a
paper |
| 20:27.08 |
madant_ |
:) |
| 20:27.36 |
mafm |
I can get
only a paper telling that I finished all the courses, and I have
the letter accepting my project |
| 20:27.43 |
mafm |
but I don't
even have a card this year |
| 20:36.40 |
mafm |
uhm, that
apparently is also OK |
| 20:42.07 |
CIA-40 |
BRL-CAD:
03brlcad * r34130 10/brlcad/trunk/NEWS: |
| 20:42.07 |
CIA-40 |
BRL-CAD: note
that richard and keith added support to rtarea to computer center
of |
| 20:42.07 |
CIA-40 |
BRL-CAD:
presented/exposed area. this is related to sf patch 1942589
(Exposed & |
| 20:42.07 |
CIA-40 |
BRL-CAD:
Presented Region Area Center points) from andrecastelo but it was
determined |
| 20:42.07 |
CIA-40 |
BRL-CAD: that
the patch was incomplete/unusable. this feature has been requested
by |
| 20:42.08 |
CIA-40 |
BRL-CAD:
analyst users (specifically from r. dibelka as well). |
| 20:55.54 |
AlexandreGuedes |
Yehh!! I
got!!!! |
| 20:57.24 |
AlexandreGuedes |
mafm: make
run ok now |
| 20:58.08 |
mafm |
AlexandreGuedes: congrats, you just burned
the equivalent power to a trip from Porto Alegre to Ouro
Preto! |
| 20:58.10 |
mafm |
;) |
| 20:58.11 |
AlexandreGuedes |
i cleanup and
restart build |
| 20:59.58 |
AlexandreGuedes |
thanks.. the
next stage is something from todo list |
| 21:01.50 |
mafm |
:) |
| 21:04.00 |
mafm |
you're
welcome |
| 21:08.00 |
*** join/#brlcad madant__
(n=madant@117.196.129.53) |
| 21:20.23 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 21:21.25 |
*** join/#brlcad SniX
(n=sylvain@R9d61.r.pppool.de) |
| 21:21.37 |
SniX |
hi |
| 21:29.19 |
madant |
hi
SniX |
| 21:32.00 |
SniX |
is it
possible to use FME using brl-cad? |
| 21:32.16 |
SniX |
maybe
exporting to another package? |
| 21:32.27 |
brlcad |
you mean
FEM? |
| 21:34.01 |
SniX |
yep,
sorry |
| 21:36.25 |
brlcad |
what do you
mean by 'use' then? you can certainly import most FEM's as
polygonal/triangle data |
| 21:36.36 |
brlcad |
and export
those out to other packages |
| 21:36.41 |
brlcad |
using our
importers and exporters |
| 21:36.51 |
brlcad |
depends on
the format's you're wanting to go to/from |
| 21:48.59 |
SniX |
thanks. |
| 21:49.57 |
SniX |
how do I use
a model in another? say I model a screw and want to use
it. |
| 21:56.10 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 21:58.23 |
brlcad |
SniX: it
depends really what you're trying to do |
| 21:59.01 |
brlcad |
sounds like
you probably just want to make a group/assembly, add both
objects |
| 21:59.16 |
brlcad |
g or comb
command |
| 21:59.19 |
brlcad |
(in
mged) |
| 22:01.01 |
SniX |
(my last
question was not FEM related). I am thinking about libraries of
models. is there something like "import"? |
| 22:09.06 |
brlcad |
SniX: we have
a variety of importers |
| 22:09.12 |
brlcad |
ls -la
/usr/brlcad/bin/*-g |
| 22:09.18 |
brlcad |
those g files
can be opened with mged |
| 22:09.28 |
brlcad |
and imported
into other g files |
| 22:16.11 |
SniX |
with
dbconcat? |
| 22:16.27 |
brlcad |
yes |
| 22:22.21 |
CIA-40 |
BRL-CAD:
03brlcad * r34131 10/brlcad/trunk/misc/ (10 files in 10 dirs):
remove BLT from windows build |
| 22:34.58 |
madant |
hmm.. wicked
Rube Goldberg http://www.youtube.com/watch?v=vrCb_fNmSTA |
| 22:47.33 |
mafm |
brlcad: were
the wiki accounts wiped out? |
| 22:51.38 |
madant |
mafm: huh
? |
| 22:52.00 |
mafm |
I can't login
in and it won't recognize my mail addresses |
| 22:52.32 |
madant |
weird..
working for me |
| 22:54.43 |
mafm |
then I'm
afraid I got amnesia and virulent stupidity or
something |
| 22:54.45 |
mafm |
:| |
| 22:57.37 |
madant |
i think
hippieindamakin8 was also having some trouble with the wiki earlier
though he figured it out i think. |
| 22:58.28 |
hippieindamakin8 |
madant,
exactly it worked for me in few minutes :) |
| 22:59.44 |
brlcad |
mafm: the
geometry converter API doesn't require knowing geometry
formats |
| 22:59.49 |
brlcad |
it's a
refactoring project |
| 22:59.57 |
brlcad |
we have a
bunch of converters, importers/exporters |
| 23:00.04 |
brlcad |
it's turning
them into functions instead of applications |
| 23:00.19 |
brlcad |
sort of like
how libged turned all of mged's commands into functions |
| 23:00.38 |
brlcad |
mafm: no,
accounts have never been removed |
| 23:01.23 |
mafm |
huh, now it
works :) |
| 23:05.00 |
mafm |
hmm, still
that of the exporters is low priority and not specially
thrilling |
| 23:08.03 |
mafm |
I also don't
want to submit anything related to GUI if not complementary with
Ralith's proposal, I like it and think that it's better "channeled"
than my RBGui one last year :) |
| 23:18.31 |
CIA-40 |
BRL-CAD:
03brlcad * r34132 10/brlcad/trunk/include/config_win.h: remove dead
code, define off_t instead of typedef it for some
reason |
| 23:20.43 |
CIA-40 |
BRL-CAD:
03brlcad * r34133 10/brlcad/trunk/configure.ac: check for the old
BSD bcmp() function for Windows even though it is part of POSIX
1003.1-2001 |
| 23:24.50 |
CIA-40 |
BRL-CAD:
03brlcad * r34134 10/brlcad/trunk/src/libsysv/ (Makefile.am
bcmp.c): add support for bcmp() for windows. g_diff uses it and
windows (98) doesn't seem to have it, so implement a simple PD
version. |
| 23:29.02 |
CIA-40 |
BRL-CAD:
03brlcad * r34135 10/brlcad/trunk/ (3 files in 3 dirs): add bcmp.c
to the other build files |
| 23:30.44 |
*** join/#brlcad BigAToo
(n=BigAToo@mail.fbcelkhart.org) |
| 23:32.10 |
CIA-40 |
BRL-CAD:
03brlcad * r34136 10/brlcad/trunk/src/gtools/g_transfer.c: make
sure we have SIGPIPE for Windows |
| 23:37.31 |
brlcad |
mafm: of
course :) |
| 23:38.10 |
brlcad |
(and yes,
discussions should almost always be public, unless it's a personal
issue) |
| 23:38.36 |
brlcad |
not being
high-priority doesn't mean it's low priority |
| 23:38.59 |
brlcad |
it just means
it'll take a little more student-excitement and a better
proposal |
| 23:43.11 |
mafm |
I guessed
that it was something like that, thus my "...and not specially
thrilling" subjective comment :) |
| 23:43.13 |
mafm |
sigh |
| 23:43.27 |
CIA-40 |
BRL-CAD:
03brlcad * r34137 10/brlcad/trunk/src/gtools/Makefile.am: g_diff
uses libtclcad for tclcad_auto_path() and
tclcad_tcl_library() |
| 23:44.02 |
CIA-40 |
BRL-CAD:
03brlcad * r34138 10/brlcad/trunk/src/gtools/g_lint.c: use rand()
instead of random() since the precision isn't that important here
and one isn't available on Windows. |
| 23:46.26 |
*** join/#brlcad Lez
(n=lezardfl@189.58.209.254.dynamic.adsl.gvt.net.br) |
| 23:46.30 |
mafm |
well, latish
here, going to sleep |
| 23:46.32 |
mafm |
night |
| 23:48.28 |
CIA-40 |
BRL-CAD:
03brlcad * r34139 10/brlcad/trunk/NEWS: verified that they now
compile, annotate that g_lint, g_transfer, and g_diff are ported to
windows given they now compile (and seem to run). |
| 23:48.39 |
brlcad |
cya
mafm |
| 23:49.18 |
brlcad |
i'm sure
there's probably some collaborative piece of the gui work to be
done -- like backend work hooking up the geometry service and
getting that talking |
| 23:49.51 |
mafm |
I'll see
tomorrow |
| 23:50.44 |
mafm |
I don't have
too much work left to do this week :) |
| 23:50.46 |
mafm |
night |
| 23:50.52 |
CIA-40 |
BRL-CAD:
03brlcad * r34140 10/brlcad/trunk/BUGS: windows build seems jacked
up. stuff compiling in the wrong order. |
| 00:13.48 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 00:22.05 |
*** join/#brlcad typ0_
(n=coder@um-sd06-125-2.uni-mb.si) |
| 00:22.21 |
AlexandreGuedes |
brlcad: where
i can get .g file format specification ? |
| 00:59.34 |
yukonbob |
hello,
cadheads |
| 01:04.25 |
madant |
AlexandreGuedes, best bet is the code +
http://ftp.arl.army.mil/~mike/papers/brlcad5.0/newdb.html |
| 01:16.59 |
AlexandreGuedes |
madant: this
link is not working, but I found: http://brlcad.org/OLD/newdb/newdb.html |
| 01:17.18 |
AlexandreGuedes |
is the same
thing ? |
| 01:21.30 |
madant |
AlexandreGuedes, yep :) |
| 01:22.07 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 01:22.28 |
madant |
hmm.. er..
the army.mil one says draft 19 july |
| 01:26.22 |
AlexandreGuedes |
WARNING: this
document is out of date and incomplete, but a useful start for
those writing to the .g format. See the librt and libwdb interfaces
for more up-to-date information. |
| 01:27.08 |
madant |
exactly
:) |
| 01:27.25 |
AlexandreGuedes |
it iis
ok |
| 01:27.49 |
AlexandreGuedes |
i should
develop a sample patch... |
| 01:28.04 |
AlexandreGuedes |
Someone could
tell as should be a patch ? |
| 01:28.14 |
madant |
have u
succeeded in checking out the repo and building ? |
| 01:28.27 |
AlexandreGuedes |
yes... |
| 01:28.35 |
AlexandreGuedes |
and make
install.. |
| 01:28.51 |
AlexandreGuedes |
is all runing
.. |
| 01:29.24 |
madant |
well you
could take up any of the manageable things on the BUGS list or any
small feature request at the sourceforge tracker or the things in
the main TODO.. small things ofcourse :) |
| 01:29.55 |
AlexandreGuedes |
hmm |
| 01:29.55 |
madant |
AlexandreGuedes, I am not a mentor :) just
a contributor |
| 01:30.11 |
AlexandreGuedes |
ok |
| 01:30.33 |
AlexandreGuedes |
tha pache can
be a file .. ? |
| 01:30.43 |
AlexandreGuedes |
the
patch* |
| 01:31.59 |
madant |
AlexandreGuedes, how to create a patch is
mentioned here
http://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804 |
| 01:32.52 |
madant |
It is just an
easy method for transmitting whatever changes you have made to the
code for removing the bug, or implementing a new feature etc. so
that a developer can easily apply it , check it etc. |
| 01:34.34 |
madant |
the diff tool
as well as svn diff basically concatenates all the changes you have
made to a single patch file which you can submit at the sourceforge
page i mentioned above |
| 01:35.29 |
madant |
then someone
from brl-cad can check the patch by applying it using the patch
tool etc. |
| 01:35.45 |
madant |
thinks maybe this will explain things better than moi :)
http://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/ |
| 01:36.01 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 01:40.13 |
AlexandreGuedes |
hhmm now I
comprehended |
| 01:41.58 |
madant |
no problem :)
go have some awesome time reading brl-cad code ;) some of it is
decades old and still awesome |
| 01:44.31 |
AlexandreGuedes |
is a lot of
code lines |
| 01:48.53 |
madant |
heh.. indeed
;) http://www.ohloh.net/p/brlcad/analyses/latest |
| 01:51.19 |
AlexandreGuedes |
ohhh |
| 03:02.04 |
brlcad |
AlexandreGuedes: you don't really need the
.g file specification to make a converter |
| 03:02.18 |
brlcad |
there is an
API for accessing/creating/reading geometry |
| 03:02.42 |
brlcad |
src/librt and
include/raytrace.h include/rtgeom.h and include/wdb.h |
| 03:30.44 |
AlexandreGuedes |
i'm
back |
| 03:39.05 |
AlexandreGuedes |
brlcad: ok
i'm analising it |
| 03:40.02 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 03:57.54 |
brlcad |
AlexandreGuedes: great |
| 03:57.57 |
*** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 03:57.57 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 03:57.57 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT
VICTIM] |
| 03:58.31 |
brlcad |
AlexandreGuedes: librt is where most of
the exporters work, libwdb is used by most of the
importers |
| 03:58.31 |
brlcad |
librt is
read/write -- libwdb is write-only |
| 03:59.38 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 03:59.54 |
AlexandreGuedes |
There is some
specific documentation ? |
| 04:00.13 |
AlexandreGuedes |
i'm lookin it
now.. Converting_Geometry.pdf |
| 04:00.13 |
brlcad |
there is
quite a bit of documentation, dpends what you're trying to
do |
| 04:00.24 |
brlcad |
yeah, that's
a good starting point |
| 04:00.35 |
brlcad |
for an
exporter, this simple example is relevant: http://brlcad.org/wiki/Example_db_walk_tree |
| 04:01.37 |
brlcad |
looking at
the existing converters is also good |
| 04:01.41 |
brlcad |
src/conv |
| 04:05.32 |
AlexandreGuedes |
there are
already converters from .g to .vrml, .obj, .x3d |
| 04:07.35 |
AlexandreGuedes |
brlcad: some
formats can represent many properties.. |
| 04:08.27 |
AlexandreGuedes |
which ones of
them are more important for brlcad ? |
| 04:09.18 |
brlcad |
AlexandreGuedes: the ones that deal with
the geometry itself of course |
| 04:09.33 |
brlcad |
other
metadata specifically related to solid modeling and
solidity |
| 04:09.38 |
brlcad |
the
hierarchy, if any |
| 04:10.23 |
brlcad |
the rest is
mostly attribute, parametrics, or 2D data that isn't easily
converted |
| 04:11.39 |
AlexandreGuedes |
mostly :
points, vectors, vertexes ... |
| 04:13.48 |
brlcad |
ah, yeah --
the 1D/2D/drafting entities can either be imported as sketch data,
just stashed as attributes, or ignored |
| 04:13.58 |
brlcad |
they're not
directly related to solid modeling generally speaking |
| 04:14.41 |
brlcad |
and solid
modeling does take precedence over other purposes like design,
drafting, and machining .. until there are devs to better support
those domains |
| 04:46.05 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 04:51.49 |
*** join/#brlcad cad07
(n=3cf9db5d@bz.bzflag.bz) |
| 05:05.36 |
*** join/#brlcad andre|away
(n=Andre_Ca@189.71.13.123) |
| 05:08.19 |
AlexandreGuedes |
brlcad: are
you here ? |
| 05:09.05 |
brlcad |
~ask |
| 05:09.05 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
| 05:09.34 |
AlexandreGuedes |
brlcad: i'm
writing my project |
| 05:09.51 |
brlcad |
highly recommends submitting two applications if you have the
time |
| 05:10.01 |
brlcad |
AlexandreGuedes: great |
| 05:10.35 |
AlexandreGuedes |
i'll offer
importers to vrml, obj and x3d |
| 05:10.55 |
AlexandreGuedes |
and a
interactive vizualization... |
| 05:11.19 |
AlexandreGuedes |
using
opengl.. |
| 05:11.45 |
brlcad |
the
converters can all go together on the same applications |
| 05:11.48 |
AlexandreGuedes |
brlcad: You
think that is very or little ? |
| 05:12.15 |
brlcad |
it's not
clear until you start coding |
| 05:12.27 |
brlcad |
depends how
good you are at reading exising code |
| 05:14.24 |
AlexandreGuedes |
And the
interactive visualization can be together ? |
| 05:15.10 |
brlcad |
interactive
visualization using opengl will be very difficult without finishing
the impementation of BREP support |
| 05:16.09 |
brlcad |
at least
implementing BREP tessellation support and CSG to BREP conversion
support |
| 05:17.08 |
brlcad |
still, please
do submit both even stubbed out and we can discuss them in further
detail. |
| 05:17.18 |
brlcad |
wanders |
| 05:20.52 |
AlexandreGuedes |
Unfortunately
gsoc deadline coincided with other commitments... |
| 05:21.17 |
AlexandreGuedes |
this week i
have others deadlines |
| 05:31.31 |
deeeffache |
Hey, if you
wanted to create something that would generate.. say, a gear, that
worked like, 'creategear numberteeth radius,' would it be best to
write a shell script or is there another way of handling
this? |
| 05:41.35 |
*** join/#brlcad Ralith|trip
(i=40f692fb@gateway/web/ajax/mibbit.com/x-68f140c27b9f8f2d) |
| 05:41.44 |
Ralith|trip |
checks in |
| 05:57.47 |
*** part/#brlcad Ralith|trip
(i=40f692fb@gateway/web/ajax/mibbit.com/x-68f140c27b9f8f2d) |
| 05:59.03 |
yukonbob |
deeeffache:
could be done in Tcl, using mged for example. |
| 06:14.58 |
AlexandreGuedes |
brlcad: hey,
thanks |
| 06:15.32 |
AlexandreGuedes |
now i'm
understandig more about brlcad models |
| 06:17.55 |
AlexandreGuedes |
i'll be away,
see you later |
| 06:33.51 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-134-105.3g.claro.net.br) |
| 06:35.00 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 08:29.44 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:35.29 |
d_rossberg |
brlcad: your
comment on the new importer proposal is private |
| 08:35.52 |
d_rossberg |
i.e. the
student should not be able to see it |
| 08:47.34 |
*** join/#brlcad madant
(n=madant@117.196.149.244) |
| 10:15.59 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:19.08 |
*** join/#brlcad madant
(n=madant@117.196.145.122) |
| 10:27.44 |
CIA-40 |
BRL-CAD:
0385.186.3.59 07http://brlcad.org *
r1327 10/wiki/Talk:Animation: New page: Hello |
| 10:54.12 |
*** join/#brlcad madant
(n=d@117.196.145.122) |
| 10:56.28 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Talk:Animation]]": content
was: 'Hello' (and the only contributor was
'[[Special:Contributions/85.186.3.59|85.186.3.59]]') |
| 10:56.51 |
brlcad |
d_rossberg:
really?? oops, thanks! |
| 11:07.31 |
mafm |
hi |
| 11:08.33 |
*** join/#brlcad madant
(n=d@117.196.145.122) |
| 11:20.00 |
*** join/#brlcad andre|away_
(n=Andre_Ca@189.71.13.123) |
| 11:25.50 |
mafm |
brlcad: mail
FAIL: "It was never expected that the project woluThere is also a
separate MGED+Archer" |
| 12:06.19 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:09.37 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 12:31.19 |
brlcad |
mafm: ah,
oops, thanks -- "never expected that the project would 'finish' as
it's a multi-year effort." |
| 12:43.06 |
mafm |
brlcad: I
figured it out, just noted it in the case that you want to fix it
:) |
| 12:43.06 |
mafm |
bbiab |
| 12:52.21 |
brlcad |
fixed and extended |
| 13:00.23 |
``Erik |
cocks an eyebrow at the 'tops' program on his
mac |
| 13:09.07 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 13:17.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 13:36.42 |
*** join/#brlcad madant
(n=d@117.196.141.148) |
| 14:26.46 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 14:31.51 |
starseeker |
wills his nosebleed to stop so he can get on the friggin
road |
| 14:33.50 |
brlcad |
gives starseeker some cocaine to congeal the
bleeding |
| 14:34.11 |
starseeker |
heh - best
example ever of cure being worse than disease |
| 14:37.26 |
_sushi_ |
Do you know
how to feed a long content of a Makefile variable into
xargs? |
| 14:37.37 |
brlcad |
you probably
wouldn't think that after trying it ;) |
| 14:39.14 |
brlcad |
_sushi_: grep
variable Makefile | xargs ... |
| 14:40.25 |
brlcad |
or just the
content: grep variable Makefile | sed 's/[^=][^=]*=[ ]*//g' |
xargs |
| 14:41.57 |
``Erik |
that assumes
that the variable isn't split with escaped newlines |
| 14:41.59 |
_sushi_ |
I have
variable $(GENERATED) which is a dynamically computed list of all
files generated during compilation of Ronja |
| 14:42.09 |
_sushi_ |
I cannot grep
it out of the Makefile. It's not written there. |
| 14:42.26 |
``Erik |
if you have a
bsd make handy, do "make -V VARIABLE" |
| 14:42.26 |
_sushi_ |
It's so many
kilobytes it cannot be passed on a commandline. |
| 14:42.36 |
``Erik |
gnumake is
r-tarded |
| 14:43.05 |
_sushi_ |
I need it for
gnu make |
| 14:43.13 |
_sushi_ |
it apparently
doesn't have -V |
| 14:43.43 |
_sushi_ |
is there a
limit on size of environment variable? |
| 14:43.50 |
brlcad |
true dat
about escaped newlines, though easy to unescape all lines before
the grep too -- one of our scripts does that |
| 14:44.10 |
brlcad |
_sushi_: most
have some upper limit |
| 14:44.21 |
brlcad |
65k on many
nowdays |
| 14:45.06 |
``Erik |
woke up too early, is already hungry :/ |
| 14:45.57 |
``Erik |
wow, sgi for
25m? O.o |
| 14:48.01 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1328
10/wiki/Developer_Documents: stub in a development tips section for
emacs and studio |
| 14:48.26 |
_sushi_ |
wow, it
works |
| 14:48.30 |
brlcad |
``Erik: lee
is up for lunch |
| 14:48.38 |
``Erik |
yeah, talked
to him about 20m ago |
| 14:48.52 |
brlcad |
_sushi_: what
does? |
| 14:49.00 |
_sushi_ |
export
GENERATED |
| 14:49.03 |
_sushi_ |
calling an
external script |
| 14:49.09 |
``Erik |
jim isn't
interested in a real lunch, just a bowling alley trip or
something |
| 14:49.14 |
_sushi_ |
and there for
filename in $GENERATED; do rm $filename; done |
| 14:49.25 |
``Erik |
I was kinda
thinking japan house, sake might help this headache out
:) |
| 14:58.09 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187-24-1-98.3g.claro.net.br) |
| 15:08.59 |
_sushi_ |
now it's
already working with GENERATED :) |
| 15:09.38 |
*** join/#brlcad madant
(n=d@117.196.134.27) |
| 15:25.22 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 15:25.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 15:27.36 |
*** join/#brlcad boerrebj_
(n=boerrebj@ti0036a380-1610.bb.online.no) |
| 15:28.14 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1329
10/wiki/Emacs: add some functions, style, and behavior
setups |
| 15:30.43 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1330
10/wiki/Emacs: pre markers so [] display |
| 15:53.07 |
*** join/#brlcad gaurav_hiiii
(n=chatzill@64.251.25.150) |
| 16:22.57 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1331 10/wiki/User:Hippieindamakin87: New page: ==Suryajith== I am
a final year undergraduate at Indian Institute of
Technology,Kanpur, majoring in Mechanical engineering.
===Abstract=== I wish to implement a library/routine which
comp... |
| 16:27.20 |
*** join/#brlcad madant_
(n=d@117.196.143.218) |
| 16:53.33 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 17:14.37 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 17:24.06 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-247-216.dclient.hispeed.ch) |
| 18:08.07 |
CIA-40 |
BRL-CAD:
03brlcad * r34141 10/brlcad/trunk/misc/win32-msvc8/ (4 files in 4
dirs): update uuids |
| 18:09.20 |
CIA-40 |
BRL-CAD:
03brlcad * r34142 10/brlcad/trunk/src/gtools/g_diff.c: include
sysv.h for bcmp() |
| 18:13.41 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1332 10/wiki/User:Hippieindamakin87: |
| 18:35.44 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1333
10/wiki/Google_Summer_of_Code/Project_Ideas: remove the priority
distinction |
| 19:30.59 |
CIA-40 |
BRL-CAD:
03brlcad * r34143 10/brlcad/trunk/include/sysv.h: hah, missed
committing this fracking declaration |
| 19:48.52 |
CIA-40 |
BRL-CAD:
03brlcad * r34144 10/brlcad/trunk/bench/run.sh: typo |
| 19:54.15 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1334
10/wiki/Google_Summer_of_Code/Project_Ideas: restore a benchmark
database website idea |
| 20:01.02 |
*** join/#brlcad andax
(n=andax__@d213-102-41-51.cust.tele2.ch) |
| 20:48.03 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 21:19.10 |
jdoliner |
brlcad could
you provide a bit of guidance on a patch? |
| 21:25.03 |
brlcad |
jdoliner:
sure, fix something ;) |
| 21:26.40 |
brlcad |
i.e., look at
the BUGS file -- most of those items are a lot less work than the
TODO file items (though todo also has a few tasks that are pretty
simple) |
| 21:27.14 |
brlcad |
another thing
is to start trying out a variety of the command-line tools until
you find some unexpected behavior or a crash, then fix
that |
| 21:27.20 |
brlcad |
usually
doesn't take too long ;) |
| 21:29.19 |
jdoliner |
yes I'm
working on bug: 2561346 |
| 21:36.07 |
brlcad |
looks |
| 21:36.22 |
jdoliner |
it has to do
with tesselation failure |
| 21:39.58 |
jdoliner |
so I need a
bit of help on the flow of the program |
| 21:40.30 |
jdoliner |
nmg_booltree_lead_trees is
failing |
| 21:45.57 |
jdoliner |
tess* that
is |
| 21:46.41 |
jdoliner |
and it's
gotta be failing since ip-idb_meth->ft_tessellate is
failing |
| 21:48.00 |
jdoliner |
but I don't
really know what that references at all |
| 21:48.53 |
mafm |
brlcad:
requirements are the usual: proposal in the wiki, mailing list, and
sending patches? |
| 21:49.14 |
brlcad |
mafm:
yeah |
| 21:49.37 |
mafm |
patches being
in the interim period, right? |
| 21:49.37 |
brlcad |
jdoliner: so
did you get john's response? |
| 21:49.41 |
brlcad |
what the
problem was |
| 21:49.58 |
jdoliner |
no I didn't
get john's response |
| 21:50.04 |
jdoliner |
did he send
one? |
| 21:50.18 |
brlcad |
jdoliner:
read the comments on the bug ;) |
| 21:51.06 |
jdoliner |
oh yes I did
see that |
| 21:51.08 |
brlcad |
also might as
well mention that ip->idb_meth is a callback table to specific
primitives -- ft_tessellate calls a primitive's tess()
function |
| 21:51.34 |
brlcad |
so if it's an
ellipsoid, ft_tessellate() is a function pointer to
ell_tess() |
| 21:51.49 |
jdoliner |
in this case
it seems to be rt_extrude_tess() |
| 21:51.56 |
brlcad |
right |
| 21:52.18 |
jdoliner |
and that's
the function I think I should modify, am I right about
that? |
| 21:52.33 |
brlcad |
probably one
of several really given what the problem is |
| 21:52.38 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187-24-53-56.3g.claro.net.br) |
| 21:52.45 |
brlcad |
it's a matter
of garbage-in == garbage-out |
| 21:53.01 |
AlexandreGuedes |
hi |
| 21:53.06 |
brlcad |
it's bad
geometry, so we can either detect it and abort or fix it
automatically if it's fixable |
| 21:53.11 |
mafm |
brlcad:
patches being in the interim period, right? |
| 21:53.11 |
brlcad |
hello
AlexandreGuedes |
| 21:53.17 |
brlcad |
mafm: what
does that mean? |
| 21:53.18 |
mafm |
hi
AlexandreGuedes |
| 21:53.42 |
mafm |
that patches
doesn't have to be submitted before 3rd April deadline |
| 21:54.09 |
mafm |
just with
time enough to evaluate it properly |
| 21:54.27 |
brlcad |
oh heck no --
patches can be submitted all the way up until we finalize
selections (though the earlier the better obviously) |
| 21:54.30 |
jdoliner |
well it
certainly is fixable |
| 21:54.39 |
brlcad |
which is like
april 15th maybe? forget the timeline |
| 21:54.51 |
jdoliner |
yes april
15th is correct |
| 21:55.23 |
brlcad |
jdoliner: in
this case, definitely -- you can detect that various segments need
to be reversed if they don't form a loop |
| 21:55.30 |
jdoliner |
1 question,
is there any worry with fixing it, that we're maybe changing some
feature of the geometry that the user wanted? |
| 21:55.59 |
brlcad |
and if that's
the approach taken, reversing the segments, it probably belongs in
import5() so that it's fixed once read off of the disk |
| 21:57.44 |
mafm |
goody |
| 21:57.47 |
jdoliner |
k so we want
to make sure, anytime we import that we don't have these reversed
segments |
| 22:00.00 |
jdoliner |
where can I
find the import5() function? |
| 22:17.35 |
brlcad |
jdoliner:
same file as tess() |
| 22:18.02 |
brlcad |
src/librt/primitives/sketch has the sketch
primitive that is used with the extrude primitive |
| 22:18.43 |
brlcad |
jdoliner:
alternative, you could make sure you only write out / export
"correct" sketches .. but that will still allow them to be
initially created and cause bad behavior |
| 22:19.25 |
brlcad |
alternative
is to just detect the problem during import and print a message
that there are incorrectly oriented segments |
| 22:19.46 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 22:19.53 |
brlcad |
put that
detection in a function, then it could be added to
import/export/prep/tess/whatever |
| 22:20.38 |
jdoliner |
sorry that's
nmg_booltree_lead_tess you're talking about |
| 22:20.53 |
jdoliner |
because Im
not finding anything called import when I search |
| 22:23.36 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 22:26.24 |
jdoliner |
k nm found
it |
| 22:30.40 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1335 10/wiki/User:Hippieindamakin87: |
| 22:32.07 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1336 10/wiki/User:Hippieindamakin87: /* Proposed approach
*/ |
| 22:33.05 |
hippieindamakin8 |
brlcad,
comments please |
| 22:33.08 |
hippieindamakin8 |
http://brlcad.org/wiki/User:Hippieindamakin87 |
| 22:33.51 |
hippieindamakin8 |
madant_, mafm
^ |
| 22:38.58 |
mafm |
nice,
hippieindamakin8 |
| 22:39.16 |
hippieindamakin8 |
mafm,
comments :) |
| 22:39.37 |
mafm |
aesthetically? |
| 22:39.42 |
mafm |
technically,
no idea :) |
| 22:40.08 |
hippieindamakin8 |
mafm,
:D |
| 22:40.22 |
hippieindamakin8 |
mafm, meant
technically |
| 22:41.00 |
hippieindamakin8 |
should be
getting ready with a bug fix .. now i can do my course projects for
the next 2-3 days |
| 22:41.28 |
mafm |
hippieindamakin8: I don't know much about
b-reps or CSG or anything :P |
| 22:41.47 |
mafm |
as a
proposal, if you want to submit that as application in the google
app |
| 22:42.00 |
mafm |
it should
have maybe less detail (or maybe not) |
| 22:42.16 |
hippieindamakin8 |
mafm, are u
familiar with the computational geometry algos using approximation
? |
| 22:42.24 |
mafm |
but it must
contain milestones, plans for it (in weeks or something) and this
kind of thing |
| 22:43.10 |
hippieindamakin8 |
mafm, rt
exactly |
| 22:43.17 |
hippieindamakin8 |
i forgot to
mention the timeline :| |
| 22:43.25 |
mafm |
http://brlcad.org/wiki/OpenGL_GUI_Framework#Initial_Project_from_GSoC_2008 |
| 22:43.58 |
hippieindamakin8 |
mafm, thanks
i shall add it to both of them |
| 22:43.59 |
mafm |
I think that
mine from last year works pretty well (it's incomplete, lacking
personal info and so on, but gives you an idea about milestones,
deliverables and other sections) |
| 22:44.49 |
mafm |
(my full
proposal was more detailed, now that I see it in detail :) -- I can
provide you one of my proposals where you can see the overall
structure ) |
| 22:45.26 |
mafm |
and I'm not
familiar with the details of CAD or rendering in any sense, I only
take part in the infrastructure of things -- GUI, interfaces, etc
:) |
| 22:45.44 |
hippieindamakin8 |
mafm, i ll
try to add it in :) i just have gone through madant_ 's
proposal |
| 22:46.27 |
hippieindamakin8 |
mafm, havent
u put in any app this year? |
| 22:46.48 |
mafm |
I'm trying,
right now |
| 22:48.01 |
mafm |
madant_'s one
is also a good think to inspire you, specially with the
schedule |
| 22:48.41 |
mafm |
but hey,
brlcad is the Big Boss, so take advantage of him (erm... with
tender and care :) ) |
| 22:48.43 |
hippieindamakin8 |
yeah that is
elaborate |
| 22:48.53 |
hippieindamakin8 |
mafm, yeah
;) |
| 23:07.44 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 23:08.22 |
Malyce |
Hello |
| 23:08.33 |
Malyce |
I was reading
through the Core C++ interface |
| 23:09.01 |
Malyce |
where can I
find the class diagram for it ? |
| 23:09.47 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 23:10.18 |
brlcad |
hippieindamakin8: even at a glance,
already better than last year :) |
| 23:10.59 |
brlcad |
you need to
include a timeline with some basic goals/deliverables/objectives
spelled out -- something that can help track progress |
| 23:11.03 |
*** join/#brlcad Lezard
(n=lezardfl@189.58.208.16) |
| 23:11.10 |
brlcad |
that goes for
others as well, if you don't have a timeline yet |
| 23:11.22 |
brlcad |
it'll be one
of my first comments |
| 23:11.24 |
hippieindamakin8 |
brlcad,
working on it. thanks |
| 23:11.29 |
hippieindamakin8 |
:) |
| 23:11.59 |
mafm |
hippieindamakin8: also, make sure to read
all the required stuff in the website |
| 23:12.02 |
brlcad |
also, feel
free to link to a personal site or portfolio or paper or whatever
if you have it to share |
| 23:12.29 |
brlcad |
doesn't need
to be a resume, frankly don't care much where you've worked -- but
if you can show things you've actually done, that can be
useful |
| 23:12.38 |
hippieindamakin8 |
brlcad, sure.
i ll put the links. |
| 23:13.06 |
brlcad |
hippieindamakin8: yeah, what mafm said too
-- there's a list of things you should be sure to
include/cover |
| 23:13.11 |
hippieindamakin8 |
brlcad, rt
now the ftp site of uNC is down so i shall put up the acm
links |
| 23:13.12 |
mafm |
hippieindamakin8: such as:
http://brlcad.org/wiki/Google_Summer_of_Code/Acceptance#List_your_milestones |
| 23:13.19 |
Malyce |
hiya |
| 23:13.22 |
mafm |
(and the rest
of things in that page) |
| 23:13.29 |
mafm |
hi
Malyce |
| 23:13.39 |
Malyce |
I managed to
find the UML diagrams for Geometry engine and services |
| 23:13.49 |
brlcad |
hippieindamakin8: don't want links to
other people's stuff, I mean *your* stuff if you have
anything |
| 23:13.51 |
Malyce |
but couldn't
find the one for Core C++ interface |
| 23:13.51 |
hippieindamakin8 |
brlcad, with
sleeplessness i forgot abt the requirements |
| 23:14.06 |
hippieindamakin8 |
brlcad, as in
anything related to that ? |
| 23:14.11 |
Malyce |
Could you
pass me a link ? |
| 23:14.59 |
mafm |
sorry Malyce,
that's classified information |
| 23:15.12 |
hippieindamakin8 |
i shall set a
link to my resume/site. my paper isnt anywhere close to this
:P |
| 23:15.46 |
mafm |
(malyce: I
mean... I don't know, maybe other people does ;) ) |
| 23:16.06 |
hippieindamakin8 |
mafm, i just
got a hosting from drupal(the free one) a couple of weeks ago :P
that is pretty decent as a matter of fact |
| 23:16.35 |
mafm |
:) |
| 23:16.47 |
Malyce |
eh ?
ok |
| 23:17.00 |
Malyce |
as long as
the discussion is about passing links to previous works |
| 23:17.13 |
Malyce |
I don't
really have links to what I have done |
| 23:17.37 |
Malyce |
But, for the
past year, I have been working as a research assistant to formalize
Solidworks 2008 |
| 23:18.21 |
Malyce |
I wrote VBA
code for the Solidworks API, to extract CAD data to OmDoc(XML) and
HASCASL(Haskell) |
| 23:18.48 |
Malyce |
And in the
end, basically creating pointclouds from the CAD data |
| 23:19.04 |
Malyce |
Would such an
explanation be any good ? |
| 23:20.11 |
mafm |
Malyce: if
you're planning an application, you should read http://brlcad.org/wiki/Google_Summer_of_Code/Acceptance
and do something like http://brlcad.org/wiki/User:Homovulgaris |
| 23:21.00 |
mafm |
milestones,
schedule and other stuff depends heavily on what task do you plan
to tackle |
| 23:21.05 |
hippieindamakin8 |
madant_'s app
has become an example aint it :) |
| 23:21.10 |
mafm |
but in
general, it should give you an idea |
| 23:21.24 |
brlcad |
Malyce: there
aren't uml diagrams for the coreInterface -- but there is writeup
for it on the wiki |
| 23:21.32 |
Malyce |
Yes, I read
that. |
| 23:21.35 |
brlcad |
and the
classes are pretty neatly organized -- it's not that
complex |
| 23:21.49 |
Malyce |
oh, you mean
the one from the Developer docs ? |
| 23:22.00 |
brlcad |
Malyce: also
note that the uml diagrams that you read are likely out of date -
but they do still have useful information |
| 23:22.05 |
mafm |
hippieindamakin8: I had the link
around |
| 23:22.16 |
brlcad |
mostly on
what those uml diagrams call the GeometryEngine is not
entirely/still true |
| 23:22.27 |
brlcad |
and yes, the
dev docs |
| 23:22.27 |
hippieindamakin8 |
mafm,
madant_ would be elated if he hears this |
| 23:23.02 |
hippieindamakin8 |
neways i
better complete editing the proposal. its already 4:55 am and got a
class from 10. |
| 23:23.18 |
Malyce |
I read a todo
list in the repository for Geometry Engine |
| 23:23.28 |
mafm |
Malyce: also
mine http://brlcad.org/wiki/OpenGL_GUI_Framework
(personal info, background and so on not included), was accepted
last year |
| 23:23.45 |
brlcad |
hippieindamakin8: for references, I meant
personal-portfolio information, like if you had a personal website
where you show other projects you work on |
| 23:23.48 |
brlcad |
if not, no
big deal |
| 23:23.49 |
Malyce |
It tells
about what should be the end product, but not about the current
issues |
| 23:23.51 |
mafm |
hippieindamakin8: get to work! :P
:) |
| 23:23.52 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 23:24.14 |
hippieindamakin8 |
brlcad, i do
have one. |
| 23:24.18 |
hippieindamakin8 |
i ll link it
up |
| 23:24.20 |
Malyce |
Is there such
a todo list, where I can find what part people are currently
working ? |
| 23:25.20 |
brlcad |
Malyce:
mostly by hanging out in irc and talking -- we don't keep anything
documented like that because it is *constantly* changing for the
most part |
| 23:26.36 |
Malyce |
I see. So to
include a concrete list of what I can achieve, I should go through
the current state of the repository ? |
| 23:26.57 |
Malyce |
I don't want
to sound too vague, when I write a list of objectives. |
| 23:27.44 |
brlcad |
yeah, the
more specific you can be, the better |
| 23:27.57 |
brlcad |
it is
expected that you will have to learn much as you get
started |
| 23:28.06 |
brlcad |
so pad for
some of that time in your proposal |
| 23:28.19 |
brlcad |
there will
have to be a lot of time for communication/discussion too
throughout |
| 23:28.31 |
brlcad |
no student
should be working in a vacuum |
| 23:29.08 |
brlcad |
as for the
state of the repository, that's best understood by looking through
what you can and asking questions -- I can probably answer a lot
more quickly than you can find |
| 23:29.17 |
brlcad |
or at least
point you in the right direction |
| 23:29.35 |
brlcad |
there's not
much time left so there will be more time to tweak after the
deadline |
| 23:29.48 |
mafm |
brlcad: the
global illumination rendered was not done by
andrecastelo? |
| 23:29.53 |
mafm |
renderer*
even |
| 23:30.02 |
Malyce |
You said
yesterday about the future merging of Core interface with Geometry
Engine |
| 23:30.18 |
Malyce |
I have taken
a look at both. I am still formulating some good
objectives |
| 23:30.24 |
Malyce |
Any hints
? |
| 23:31.45 |
brlcad |
mafm: what do
you mean? he worked on it, but he didn't finish |
| 23:32.20 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@187-24-72-109.3g.claro.net.br) |
| 23:32.32 |
brlcad |
in fact, he
didn't get to the global illumination aspect, he got to basic flat
shade ray-tracing |
| 23:32.47 |
brlcad |
Malyce: are
you the one familiar with SW? |
| 23:32.56 |
Malyce |
yes |
| 23:33.01 |
brlcad |
okay |
| 23:33.11 |
Malyce |
I have been
working on it for quite a while |
| 23:33.16 |
Malyce |
not as a
modeller though |
| 23:33.23 |
Malyce |
only with VB
and the API |
| 23:33.48 |
brlcad |
well to
relate to their api a little bit -- if I remember their api
correctly, their approach does things a little like if we merged
our geometry service together with the geometry engine |
| 23:34.08 |
brlcad |
basically
that you attach to their geometry engine and send it
actions/queries to perform |
| 23:34.16 |
mafm |
ah ok, it'll
be a WIP too |
| 23:35.01 |
Malyce |
Hmm, I
thought core services' syntax resembled more like their API
syntax |
| 23:35.20 |
brlcad |
the goal of
the geometry engine is to separate service actions, access control,
and revisioning from the core representation and capabilities of
geometry |
| 23:35.21 |
Malyce |
I haven't
seen any examples for either Geometry Engine or
services |
| 23:35.39 |
brlcad |
there are
some coreinterface examples on the wiki |
| 23:35.43 |
Malyce |
Yes |
| 23:35.46 |
Malyce |
I have
seen |
| 23:35.49 |
brlcad |
k |
| 23:35.54 |
Malyce |
but not for
Geometry engine/services |
| 23:36.06 |
Malyce |
Are there any
? |
| 23:36.33 |
brlcad |
for all
intensive purposes GeometryEngine==coreInterface |
| 23:36.51 |
brlcad |
geometry
service is not involved |
| 23:37.01 |
Malyce |
I think I am
beginning to understand. |
| 23:37.25 |
Malyce |
So, when you
said you wanted to merge core interfaces with geometry engine, they
both complement each other |
| 23:37.25 |
mafm |
brlcad, from
your ideas list: Create a 3D geometry browser graphical interface
using a common graphics engine (e.g. OGRE, Open Scene Graph,
Crystal Space) -- isn't this the GUI that we've been
making? |
| 23:37.33 |
brlcad |
the
GeometryService *project* required the dev that was working on it
to define some aspects of a GeometryEngine before one existed,
before coreInterface was even to the point it is at now |
| 23:37.35 |
Malyce |
instead of
substituting each other |
| 23:38.08 |
Malyce |
ok |
| 23:38.13 |
brlcad |
so the GS dev
ended up duplicating some of the same design that was implemented
by the other dev that was working on the coreInterface
(d_rossberg) |
| 23:38.27 |
brlcad |
so they
should be merged |
| 23:38.46 |
brlcad |
I think
coreInterface has a lot more design to it already, but still has a
LONG way to go |
| 23:38.51 |
Malyce |
So, is the
plan to extend core interfaces, till it converges with Geometry
engine ? |
| 23:38.58 |
brlcad |
yeah,
sorta |
| 23:39.06 |
Malyce |
Sound
cool |
| 23:39.17 |
brlcad |
in my mind,
coreInterface is the GE but with a bad name :) |
| 23:39.27 |
Malyce |
Is the wiki
out of date ? |
| 23:39.39 |
brlcad |
but then
there are some aspects in the currently GS/GE-named GE that need to
merge with it |
| 23:39.45 |
brlcad |
not horribly
no |
| 23:39.58 |
brlcad |
that's where
things are at -- a lot of work remains |
| 23:40.36 |
brlcad |
so probably
your first step would be to work with d_rossberg and d-lo to merge
the two or find the best way to consolidate them |
| 23:41.14 |
Malyce |
So core
interfaces needs to cover all the standard libraries that BRL devs
work with ? |
| 23:41.24 |
Malyce |
Should I put
that down as an objective ? |
| 23:41.36 |
brlcad |
then itemize
a few specific goals, like maybe adding support for all of the
primitive types, or maybe defining brep entities, or maybe adding
hierarchy traversal support, etc |
| 23:42.04 |
brlcad |
brl-cad's
core libraries are presently LIBBU, LIBBN, LIBRT, LIBWDB, and
LIBGED |
| 23:42.20 |
brlcad |
the Geometry
Engine is an OO layer that sits on top of that
functionality |
| 23:42.45 |
brlcad |
and uses
those libraries to provide functionality |
| 23:43.05 |
Malyce |
Pardon me. I
understand some of your lingo, but others I don't get: Defining
brep entities ? |
| 23:43.28 |
brlcad |
depending on
what portion of the API you work on, the task may even involve some
refactoring -- pushing functionality that is in libged into librt,
for example, so that the GE can use it more effectively |
| 23:43.40 |
brlcad |
brep is
"boundary representation" |
| 23:43.52 |
brlcad |
http://en.wikipedia.org/wiki/Boundary_representation |
| 23:44.21 |
Malyce |
Hierarchy
transversal support has to do with inheritance ? Or does it have
something to do with model parts ? |
| 23:44.23 |
brlcad |
http://en.wiki.mcneel.com/content/upload/images/Brep_structure.gif
<-- pretty good image |
| 23:44.29 |
brlcad |
albeit
detailed |
| 23:44.41 |
brlcad |
model parts
.. traversing down a model hierarchy |
| 23:44.48 |
brlcad |
doing things
while you traverse |
| 23:44.52 |
brlcad |
it's a common
operation in librt |
| 23:45.00 |
Malyce |
That seems
like something I am much more familiar with |
| 23:45.01 |
brlcad |
it becomes a
set of iterators in OO |
| 23:45.16 |
Malyce |
Sounds
simple |
| 23:45.30 |
brlcad |
that's why
one of daniel's examples is traversal iirc -- you can see the
difference |
| 23:45.34 |
brlcad |
looks for the link |
| 23:46.27 |
brlcad |
http://brlcad.org/wiki/Example_db_walk_tree |
| 23:46.40 |
brlcad |
that uses
librt to traverse a geometry file and print all regions |
| 23:47.02 |
Malyce |
Thanks a ton
brlcad |
| 23:47.11 |
Malyce |
this was
exactly the sort of thing I was looking for |
| 23:47.16 |
brlcad |
this is
similar but with the C++ interface as it currently stands:
http://brlcad.org/wiki/CoreInterface_Tree_Walker_Example |
| 23:47.59 |
brlcad |
notes that needs lots of improvement :) |
| 23:48.43 |
brlcad |
no reason the
C++ version should be that much more text than the C version
:) |
| 23:48.57 |
brlcad |
though in all
fairness, they do slightly different things |
| 23:49.01 |
Malyce |
ok, dumb
question maybe, but is it not possible to save the file, and just
run the db_walk to get the same result ? |
| 23:49.13 |
brlcad |
hm? |
| 23:49.26 |
Malyce |
It seems you
have hierarchy transversal in the geometry files, but not in core
interfaces, is it not ? |
| 23:49.28 |
brlcad |
save what
file? |
| 23:49.46 |
Malyce |
I assumed the
first example was transversal inside a stored database
file |
| 23:50.11 |
brlcad |
our geometry
database files (our .g file format) contain geometry with
hierarchical information |
| 23:50.27 |
Malyce |
yes |
| 23:50.46 |
brlcad |
say you open
a file and want to list all objects, that's easy enough, but say
you want to print the hierarchy itself, then you need to traverse
over the objects in their hierarchy order |
| 23:50.49 |
Malyce |
so, why can't
a dirty shortcut like the one I mentioned above be used
? |
| 23:51.01 |
Malyce |
oh |
| 23:51.22 |
Malyce |
So the
hierarchy isn't preserved ? |
| 23:51.38 |
brlcad |
of course
it's preserved, but it's just bits on a disk |
| 23:51.53 |
Malyce |
so
? |
| 23:52.07 |
brlcad |
so I think
you're missing something :) |
| 23:52.35 |
brlcad |
the API in
this case is a routine to walk down a tree |
| 23:52.42 |
Malyce |
Is this the
difference between doing it in realtime, and retrieving the info
from storage ? |
| 23:52.48 |
brlcad |
on the C side
in librt, one of those functions is db_walk_tree() |
| 23:53.12 |
brlcad |
you provide
various callbacks to db_walk_tree() to tell it what to do when it
encounters various object types |
| 23:53.26 |
brlcad |
your
callbacks are invoked, and your application does what it needs
to |
| 23:54.09 |
brlcad |
that's very
much a procedural method of iteration, what one would generally
expect with a C api |
| 23:54.25 |
brlcad |
for the C++
api, I would generally expect something else |
| 23:55.00 |
Malyce |
like
? |
| 23:55.21 |
Malyce |
Just
something higher level ? |
| 23:55.36 |
brlcad |
which is what
is shown in that example for the coreInterface -- there it defines
a TopObjectIterator along with a callback, and as it iterates over
'good' objects (wtf), it calls that callback |
| 23:56.31 |
brlcad |
expectation
is what it does -- iterator pattern instead of procedural
callbacks |
| 23:58.35 |
Malyce |
And we can't
have the same thing in C ? |
| 23:58.43 |
Malyce |
Is the
difference in Classes ? |
| 23:58.54 |
Malyce |
iterators are
not possible in C ? |
| 23:59.27 |
mafm |
languages
with OO capabilities are cleaner in some ways, as this one
:) |
| 23:59.46 |
brlcad |
mafm: right,
there are no iterators |
| 00:00.09 |
brlcad |
at best, you
could have an iterator function that is given an iteration state
object |
| 00:00.12 |
Malyce |
I never
realised this |
| 00:00.21 |
mafm |
you can
create roughly the same functionality with C structs, but sometimes
it's not as clean and usually ppl doesn't work with those idioms in
C language |
| 00:00.36 |
brlcad |
sort of like
strsep() .. it's not nearly as clean as just
iterator++; |
| 00:00.49 |
Malyce |
Ease of use.
yes, classes are nice |
| 00:01.02 |
brlcad |
with
strsep(), you keep calling strsep and keep feeding it a new (state)
pointer |
| 00:01.07 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-180-46.3g.claro.net.br) |
| 00:01.10 |
Malyce |
Which is why
you want the CoreInterfaces in C++ |
| 00:01.18 |
brlcad |
we have a C
api |
| 00:01.28 |
brlcad |
the entire
point is to provide a new/clean OO C++ API |
| 00:01.37 |
Malyce |
But, for the
unified API, youd rather use C++ |
| 00:01.40 |
Malyce |
ok |
| 00:01.42 |
brlcad |
hm? |
| 00:01.47 |
Malyce |
same
thing |
| 00:01.50 |
brlcad |
there is no
'unified' api |
| 00:02.02 |
brlcad |
there are the
C libs, and this new C++ library |
| 00:02.12 |
Malyce |
the merging
of Coreinterfaces with GeomEngine |
| 00:02.14 |
brlcad |
the C++ one
sits on top of the C ones |
| 00:02.54 |
brlcad |
well, that's
more just a "current state of affairs" .. there are two things that
have the exact same goals, but were simply designed by two
different devs mostly in isolation |
| 00:03.11 |
brlcad |
they need to
merge simply because they are the same thing -- the differences
have to be reconciled |
| 00:04.03 |
Malyce |
The Tree
walker example, is that hypothetical ? |
| 00:04.13 |
brlcad |
no, we do
that sort of thing all the time |
| 00:04.26 |
brlcad |
you can find
dozens of examples of it throughout the brl-cad code |
| 00:04.30 |
Malyce |
Or, if it
works, then don't you already have traversal support ? |
| 00:04.54 |
brlcad |
we have
traversal support in C -- that's the db_walk_tree() function (and
there are about 6 others too) |
| 00:05.09 |
brlcad |
that one in
C++ was just implemented like last week |
| 00:05.28 |
Malyce |
so, you do
have traversal support in C++ now ? |
| 00:05.43 |
brlcad |
the one you
just saw... |
| 00:05.58 |
Malyce |
k, is there
anything I can add ? |
| 00:06.13 |
brlcad |
undoubtedly |
| 00:06.24 |
brlcad |
again, that
code is brand new, hasn't even been reviewed by anyone
really |
| 00:06.34 |
brlcad |
and it's
actually longer than the C example |
| 00:06.43 |
Malyce |
Yes,
funnily |
| 00:06.44 |
brlcad |
that's not
right -- something could be improved there I'm sure |
| 00:07.09 |
Malyce |
I'll add that
to my list |
| 00:07.16 |
Malyce |
anything else
that comes to mind ? |
| 00:07.23 |
brlcad |
to say you're
going to work on that would be missing the boat a little bit though
-- there's hundreds of pieces of functionality like that in LIBRT
that need to be translated to OO C++ API form |
| 00:07.43 |
brlcad |
you're
obviously not going to implement everything |
| 00:08.00 |
brlcad |
mafm: here!,
I can't keep toggling |
| 00:08.08 |
brlcad |
and it
shouldn't be private |
| 00:08.21 |
brlcad |
doesn't
matter if there's something else also being discussed |
| 00:08.36 |
mafm |
ah ok, sorry
:D |
| 00:08.39 |
Malyce |
But, you need
a specific list of goals |
| 00:08.45 |
brlcad |
Malyce:
yes |
| 00:08.53 |
Malyce |
Saying that I
wish to extend Coreinterfaces won't be enough |
| 00:09.06 |
Malyce |
I'll need
more specifics ? |
| 00:09.21 |
brlcad |
so you could
work on cleaning up tree traversal -- to do that I'd suggest
looking at those two examples as well as the other iterators in
librt .. see how they could be defined best as c++ |
| 00:11.15 |
mafm |
brlcad: so do
I repeat the questions here? |
| 00:11.25 |
brlcad |
Malyce:
probably best is to peruse what librt presently does, what
coreInterface presently does, and what the other GS/GE-defined
engine does .. then describe those categorical areas of the API --
those categories of API in LIBRT very likely correspond to objects
in C++ |
| 00:11.27 |
mafm |
the 1st one
was already posted in this channel |
| 00:11.42 |
brlcad |
the basic
structs in C mostly correspond to C++ classes nearly
1-1 |
| 00:12.02 |
brlcad |
mafm: yes,
the discussion log would be useless for others
otherwise |
| 00:12.17 |
brlcad |
what was the
first question? |
| 00:12.26 |
mafm |
brlcad, from
your ideas list: Create a 3D geometry browser graphical interface
using a common graphics engine (e.g. OGRE, Open Scene Graph,
Crystal Space) -- isn't this the GUI that we've been
making? |
| 00:12.34 |
brlcad |
that is the
gui |
| 00:12.47 |
brlcad |
more
specifically, that would ideally be a plugin in the new gui
infrastructure |
| 00:13.45 |
brlcad |
more
interestingly, it becomes a plugin in the gui infrastructure that
talks to the geometry service for getting geometry |
| 00:14.10 |
brlcad |
this is a
great article by a friend on the drupal dev team: http://webchick.net/embrace-the-chaos |
| 00:14.20 |
mafm |
I don't
understand, isn't "browser" the view? |
| 00:15.06 |
Malyce |
You mentioned
support for primitives |
| 00:15.20 |
Malyce |
a quick look
reveals revolves, bsplines etc |
| 00:15.26 |
Malyce |
I can move
this to C++ |
| 00:15.39 |
Malyce |
And I have
worked with these before in SW |
| 00:15.51 |
Malyce |
So I have an
idea of what to do |
| 00:16.04 |
brlcad |
Malyce:
there's no moving |
| 00:16.20 |
brlcad |
you're
creating a library that sits on top of libbu, libbn, librt, libwdb,
libged :) |
| 00:16.32 |
Malyce |
that is what
I meant. Sorry, my lingo sucks |
| 00:16.47 |
Malyce |
but, I can do
that |
| 00:16.53 |
brlcad |
if working
with entites is more familiar, then start there |
| 00:17.05 |
Malyce |
It seems like
a big chunk of work |
| 00:17.17 |
brlcad |
absolutely |
| 00:17.23 |
Malyce |
coupled with
hierarchy transversal, I think it will keep me occupied |
| 00:17.30 |
Malyce |
big enough
objective ? |
| 00:17.43 |
brlcad |
you should
post whatever you come up with onto the brlcad-devel mailing list,
see if you can get rossberg to comment on your goals |
| 00:18.06 |
brlcad |
he'd likely
be the mentor or d-lo if you worked on that project |
| 00:18.06 |
Malyce |
I think that
covering all the primitives would be hard |
| 00:18.15 |
brlcad |
then maybe
focus on just that |
| 00:18.29 |
mafm |
2nd question:
Create a ray-trace service daemon with a simple tcp communications
interface (similar to remrt, but more of a persistent daemon) -- do
you think that is it doable as gsoc project? I don't think that
this raytracing is covered by geometry service |
| 00:18.37 |
brlcad |
traversal was
just an easily demonstrateable point since there are already demos
of both in both APIs |
| 00:18.58 |
brlcad |
mafm:
ray-tracing is covered by the GS |
| 00:19.07 |
brlcad |
it's actually
one of its critical requirements |
| 00:19.39 |
brlcad |
it's being
developed specifically to callers to shoot rays at geometry and get
back the results :) |
| 00:19.59 |
brlcad |
s/to callers
to/so callers can/ |
| 00:20.34 |
mafm |
good, so
scrap that one too :) |
| 00:20.52 |
brlcad |
so the task
there, mafm, could be to work on the GS directly and work on the
class(es) that get hooked into by the job manager that will issue
rays |
| 00:21.03 |
brlcad |
that'd be a
pretty hot topic |
| 00:21.10 |
brlcad |
why scrap
it? |
| 00:21.15 |
mafm |
the 3rd one
was a curiosity -- Implement or integrate a RenderMan-compliant
interface (e.g. Pixie) to BRL-CAD's ray-trace library -- my gsoc of
2007 was with Aqsis, rival of Pixie :) but it was not about
rendering, but multithreading |
| 00:21.41 |
mafm |
oh, I meant,
if dlo or daniel are already working on it... |
| 00:21.49 |
brlcad |
pixie is all
lgpl, aqsis has nasty gpl portions ;) |
| 00:21.55 |
brlcad |
otherwise,
yeah, same thing |
| 00:21.57 |
Malyce |
devs@brlcad.org ? i think it might take
too long for him to respond. Maybe I should proceed with writing
this stuff down and submitting ? |
| 00:22.06 |
brlcad |
mafm: they're
huge tasks |
| 00:22.18 |
brlcad |
collaborative
efforts would be way cooler than independent efforts |
| 00:22.23 |
brlcad |
Malyce:
no |
| 00:22.28 |
brlcad |
see the
wiki |
| 00:22.32 |
mafm |
Malyce: you
should submit the application nevertheless, otherwise you'll miss
the deadline |
| 00:22.36 |
brlcad |
it has
instructions in the gsoc pages on getting there |
| 00:22.53 |
brlcad |
yeah, you
should submit asap just so you're in -- you can tweak and update
afterwards |
| 00:23.01 |
mafm |
Malyce: you
can edit the proposal later. also the address is wrong. |
| 00:23.11 |
brlcad |
I'd suggest
submitting it as soon as you have it done, then post to the list
for feedback |
| 00:23.21 |
brlcad |
and/or to a
user wiki page |
| 00:23.35 |
Malyce |
I have more
than 12 hrs, right ? |
| 00:23.50 |
Malyce |
just to be
sure |
| 00:23.52 |
Malyce |
? |
| 00:23.57 |
brlcad |
Malyce: *you*
do.. but it would be nice if we could have some time to review and
discuss it :) |
| 00:24.02 |
Malyce |
yes |
| 00:24.04 |
Malyce |
certainly |
| 00:24.06 |
Malyce |
I will do
that |
| 00:24.31 |
mafm |
about
rendermans: http://en.wikipedia.org/wiki/Pixie_(renderer)
says GPL and LGPL, anyway BRL-CAD would not use them (but the other
way around), so I don't kow why that would matter :) |
| 00:24.37 |
brlcad |
i mean we'll
have the upcoming week, but its only going to get harder as the
deadline approaches and there are a dozen half-discussed
applications |
| 00:24.45 |
brlcad |
I expect a
little bit of a flurry of discussion tomorrow |
| 00:24.48 |
mafm |
anyway, I
didn't touch any renderman-specific part, so nevermind
:) |
| 00:24.53 |
brlcad |
seems to be
accellerating as the deadline approaches |
| 00:25.03 |
brlcad |
agree that it
should have been a monday deadline instead of a friday one
:) |
| 00:25.08 |
brlcad |
but therein
is the planning |
| 00:25.20 |
brlcad |
mafm:
okay |
| 00:25.48 |
brlcad |
it's not
actually implementing renderman spec (though that is an option) ..
as that is indeed a project in itself |
| 00:26.39 |
brlcad |
it's hooking
into something like aqsis/pixie as either a lighting model or
shader .. and making their code use librt to shoot at the geometry
(instead of whatever they implemented) |
| 00:27.03 |
mafm |
I mean, I
don't know how to map their operations to brlcad's :) |
| 00:27.11 |
brlcad |
so using
their code to parse the renderman scripts, manage textures, etc,
but use our ray-tracing |
| 00:27.16 |
brlcad |
fair
enough |
| 00:27.35 |
brlcad |
it's a bit of
a project to say the least -- would probably require modifying
pixie to call our tracer |
| 00:27.45 |
brlcad |
unless they
really made it that cleanly modular |
| 00:27.56 |
brlcad |
would
definitely require hooks on our end, probably a new
shader |
| 00:28.03 |
mafm |
I think that
I'll settle in something between GUI and the GS, or some part of
the GS |
| 00:28.46 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) |
| 00:29.34 |
brlcad |
getting the
GUI talking to the GS and/or working directly on the GS are both
pretty high-priority/valuable/cool projects |
| 00:29.43 |
brlcad |
pretty
well-defined too |
| 00:30.14 |
brlcad |
I kinda like
the goal of making the GS shoot rays for you |
| 00:32.25 |
mafm |
the GS would
be a kind of remote daemon accepting commands via TCP, to perform
operations on an open geometry |
| 00:32.41 |
mafm |
and sending
data back and forth for visualization in the GUI |
| 00:32.42 |
mafm |
right? |
| 00:33.37 |
mafm |
so what we
need is a wrapper in the thin client that it's the gui, a kind of
couterpart of GS for the client (or clients) |
| 00:33.48 |
brlcad |
the GS has an
example daemon already (gs0) |
| 00:34.24 |
brlcad |
you could
hook it into the gui, or just make your own little daemon that just
issues commands and demonstrates capability |
| 00:34.41 |
brlcad |
once you had
it working, could then work on hooking it up |
| 00:34.49 |
brlcad |
and ripping
out the libged components in the gui |
| 00:35.13 |
brlcad |
it already
has enough hooks to open geometry and list objects |
| 00:35.41 |
mafm |
gs0 is the
server/-ice part, right? or an example of how a client should call
the GS? |
| 00:39.32 |
mafm |
I don't know
if the client component talking to the GS would be better modelled
as a separate process, as an object instantiable by the gui with
mostly hardcoded API (functions), or with an interpreter that would
validate commands before sending them over to the GS |
| 00:39.42 |
mafm |
reading the wiki, searching for that info |
| 00:40.11 |
brlcad |
it might be
the server part, I forget |
| 00:40.18 |
brlcad |
either way,
writing a client is trivial |
| 00:41.16 |
brlcad |
the point of
the service is to not have to hard-code a list of commands in
various places -- so you'd either just pass the command to the GS
and have it tell you if it's valid or not, or have a routine on the
GS that reports a manifest of valid commands |
| 00:41.30 |
brlcad |
probably
better served reading the sources |
| 00:42.12 |
mafm |
imagine a db
like mysql |
| 00:43.15 |
mafm |
notes: db, not proper rdbms :P ;) |
| 00:43.15 |
Malyce |
what are
'nmg's ? |
| 00:43.16 |
brlcad |
the GS is
only accessible over a socket |
| 00:43.16 |
brlcad |
whether local
or remote |
| 00:43.19 |
brlcad |
Malyce: nmgs
are n-manifold geometry |
| 00:43.25 |
Malyce |
k |
| 00:43.38 |
brlcad |
for all
intensive purposes, they're boundary representation
geometry |
| 00:43.39 |
mafm |
the GS could
provide kind of libmysql libraries, so the clients can use those
libraries to talk directly to the rdbms, abstracting network
operations and all that |
| 00:43.58 |
brlcad |
technically,
they are an implementation of the radial edge data structure for
representing boundary representation geometry |
| 00:44.17 |
brlcad |
there are
links on wikipedia for all of those terms I used if you don't know
what they are :) |
| 00:44.33 |
Malyce |
For some
reason, the b-spline primitive seems to be quite big, compared to
others. I assume, this is because other primitives build on it
? |
| 00:44.50 |
brlcad |
mafm:
possibly, but for simplicity, only care right now about getting the
socket communication working |
| 00:45.03 |
brlcad |
the geometry
engine is the compiled library interface |
| 00:45.17 |
brlcad |
the service
is a true service, you'll connect to a port and chatter |
| 00:45.18 |
yukonbob |
hello,
cadheads, GSOC'rs |
| 00:45.22 |
brlcad |
howdy
yukonbob |
| 00:45.28 |
brlcad |
yukonbob: are
you signed up? |
| 00:45.28 |
pacman87 |
hi
yukonbob |
| 00:45.31 |
brlcad |
someone's not
signed up |
| 00:45.52 |
yukonbob |
what's the
signup drlil? |
| 00:45.54 |
yukonbob |
*drill |
| 00:46.01 |
brlcad |
Malyce: don't
bother looking at the bspline primitive |
| 00:46.05 |
brlcad |
it's going
away |
| 00:46.13 |
brlcad |
sochop.appspot.com |
| 00:46.31 |
Malyce |
what about
n-manifolds ? |
| 00:46.33 |
brlcad |
create a
profile, request to be added to brl-cad, I confirm, you reconfirm,
and we're good |
| 00:46.35 |
yukonbob |
"sochop":
cute. |
| 00:46.43 |
brlcad |
er,
socghop |
| 00:46.51 |
brlcad |
sochop would
have been better |
| 00:47.24 |
brlcad |
Malyce: what
about them? |
| 00:47.54 |
brlcad |
n-manifolds
are topological structure -- you'll end up needing most of
that |
| 00:48.04 |
brlcad |
look at how
primitives are already being supported by the core
interface |
| 00:48.23 |
brlcad |
leaves for a bit |
| 00:48.31 |
Malyce |
theay are
still going to be needed ? |
| 00:48.55 |
poolio |
howdy all,
brlcad |
| 00:49.11 |
brlcad |
Malyce: yes,
everything except bsplines |
| 00:49.15 |
brlcad |
howdy
poolio |
| 00:50.04 |
Malyce |
where exactly
is core interface in src ? |
| 00:51.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 00:53.10 |
yukonbob |
Malyce: core
interface to what? |
| 00:54.23 |
Malyce |
Core C++
Interfaces |
| 00:55.20 |
mafm |
yukonbob: I
think that it's daniel's project |
| 00:57.03 |
poolio |
If anyone is
interested in knowing more about brep/needs help understanding
what's currently there, I can lend a hand...maybe :) |
| 00:58.39 |
yukonbob |
fsck... that
sign-in keeps crashing my browser |
| 00:58.57 |
mafm |
yukonbob:
konqueror? |
| 00:59.14 |
yukonbob |
ffox |
| 00:59.34 |
poolio |
yukonbob: is
this on linux? I've had a ton of stability issues with ffox
lately |
| 01:00.20 |
mafm |
I had to do
stuff with ffox, konqueror sometimes crashed |
| 01:00.38 |
yukonbob |
poolio:
NetBSD |
| 01:00.46 |
mafm |
yay for
foss-unfriendly google gsoc stuff :D |
| 01:01.35 |
Malyce |
so, does
anyone know, where the actual code for Core C++ Interfaces is in
the src directory ? |
| 01:03.11 |
mafm |
Malyce: it's
in rt^3 module, src/coreInterface |
| 01:04.49 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 01:08.50 |
Malyce |
thanks |
| 01:12.17 |
Malyce |
Is this all
? |
| 01:12.29 |
Malyce |
Seems there
is no support as of yet for any primitive support |
| 01:12.47 |
Malyce |
scratch the
second 'support' |
| 01:13.05 |
mafm |
there's no
private development AFAIK, so all that it's developed should be
there |
| 01:13.49 |
Malyce |
except for
arb8 |
| 01:14.16 |
Malyce |
so, arb8 is
the only primitive so far supported by Core C++
Interfaces |
| 01:14.42 |
mafm |
shrugs |
| 01:16.14 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 01:17.13 |
Malyce |
ok |
| 01:17.38 |
Malyce |
I had
thought, it would be possible to include support for a single
primitive within 5-15 hours |
| 01:17.52 |
Malyce |
but I guess
that was far too optimistic |
| 01:24.30 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1337 10/wiki/User:Hippieindamakin87: |
| 01:30.26 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1338 10/wiki/User:Hippieindamakin87: /* Timeline */ |
| 01:38.49 |
AlexandreGuedes |
How many
students will be accepted for brl-CAD in gsoc 2009 ? |
| 01:39.02 |
AlexandreGuedes |
two
? |
| 01:39.35 |
mafm |
brlcad:
back? |
| 01:39.47 |
mafm |
AlexandreGuedes: for brl-cad? up to 4, I
think |
| 01:41.01 |
AlexandreGuedes |
mafm: You are
trying to ? |
| 01:44.22 |
mafm |
AlexandreGuedes: yes |
| 01:57.36 |
AlexandreGuedes |
mafm: Will it
be Sean sleeping now? |
| 01:57.39 |
AlexandreGuedes |
incredible |
| 01:57.56 |
mafm |
maybe
8| |
| 01:59.39 |
*** join/#brlcad andrecastelo
(n=Andre_Ca@189.71.13.123) |
| 01:59.48 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 02:01.36 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1339 10/wiki/User:Hippieindamakin87: |
| 02:02.34 |
brlcad |
probably
somewhere between 2 and 5 slots, depends on a lot of
factors |
| 02:02.56 |
brlcad |
like the fact
that many of you haven't posted your applications yet, which may
result in us getting fewer slots regardless of what we request
:) |
| 02:03.14 |
brlcad |
Malyce: core
interfaces is in the rt^3 module |
| 02:03.24 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/ |
| 02:04.07 |
brlcad |
poolio:
you're also welcome to be a mentor if you're interested (a backup
mentor) .. and all you'd have to do at a minimum is be willing to
sign up and accept a free t-shirt ;) |
| 02:05.13 |
brlcad |
Malyce:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt%5E3/trunk/src/coreInterface/
.. there are two primitives at a glance |
| 02:05.23 |
brlcad |
arb8 and
halfspace |
| 02:05.53 |
brlcad |
AlexandreGuedes: sleepiwhat? |
| 02:06.16 |
Malyce |
I have
completed my proposal |
| 02:06.20 |
Malyce |
I will post
it soon |
| 02:06.22 |
brlcad |
awesome |
| 02:06.30 |
AlexandreGuedes |
brlcad:
heuehue |
| 02:06.33 |
brlcad |
yukonbob: no
account yet? |
| 02:06.43 |
Malyce |
I have a
question. How do I attach my cover letter and Resume ? |
| 02:07.13 |
brlcad |
not really
necessary, but you're welcome to include/link to it if you like --
basic background information about yourself can sometimes be
interesting |
| 02:07.33 |
brlcad |
more
interesting is usually how you work and interact, how quickly you
learn, how much a pain in the ass you can be, etc ;) |
| 02:08.14 |
Malyce |
Then I guess
no need for resume |
| 02:08.24 |
Malyce |
But I'd like
to put in a short cover letter |
| 02:08.29 |
brlcad |
link it if
you think it'll help ;) |
| 02:08.40 |
brlcad |
if it'll be a
waste of time, don't link it ;) |
| 02:08.56 |
Malyce |
Can I create
a new document in the GSOC toolbar, and add it ? |
| 02:09.07 |
Malyce |
Just a short
letter |
| 02:09.49 |
brlcad |
time is often
well spent adding more detail to the proposal, or working on a
second backup proposal, or working on a patch |
| 02:09.53 |
brlcad |
i dunno
really, give it a try |
| 02:13.43 |
mafm |
Malyce: this
is not applying for a job, cover letters are not needed. a link to
your CV might come in handy, though |
| 02:14.53 |
Malyce |
I wanted to
give my background in working with Solidworks API |
| 02:15.58 |
mafm |
you can add
that in the "Content" section of the application too, as past
experience for instance |
| 02:17.53 |
Malyce |
allright |
| 02:20.17 |
*** join/#brlcad andrecastelo
(n=Andre_Ca@189.71.13.123) |
| 02:21.58 |
mafm |
brlcad:
coreInterface is in a very early stage of development it seems, and
what's about iBME? it appears to include some plan for GUI
too... |
| 02:22.51 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 02:25.29 |
brlcad |
Malyce: be
sure to read this if you haven't yet:
http://brlcad.org/wiki/Google_Summer_of_Code/Application_Guidelines |
| 02:26.05 |
brlcad |
also worth
including in your proposal is what you hope to gain out of
participating in GSoC and what plans for your project (if any) do
you have after GSoC is over |
| 02:29.43 |
Malyce |
ok |
| 02:29.49 |
Malyce |
I will edit
my proposal |
| 02:29.57 |
Malyce |
but I have
already posted it |
| 02:30.02 |
Malyce |
iamtanmay |
| 02:37.00 |
mafm |
brlcad: you
tell me to talk in the channel, but then ignore when I talk
:P |
| 02:41.33 |
yukonbob |
brlcad: my
browser crashes trying to register :P !!! |
| 02:45.13 |
mafm |
well, going
to sleep |
| 02:45.15 |
mafm |
night |
| 02:47.48 |
brlcad |
wasn't ignoring him, wouldn't have answered pm either
:P |
| 02:53.55 |
*** join/#brlcad andrecastelo
(n=Andre_Ca@189.71.13.123) |
| 02:55.49 |
Malyce |
So, how to I
get feedback from d_rossberg ? |
| 02:56.52 |
brlcad |
AlexandreGuedes: so you know, I generally
don't answer "hello" messages in PMs -- but I'm more than happy to
talk once you say something more than hello |
| 02:57.03 |
brlcad |
if it's a dev
or gsoc question, though, it probably shouldn't be in
private |
| 02:57.45 |
brlcad |
Malyce: post
to the brlcad-devel mailing list, and ask for feedback from him or
others (or leave it open-ended) |
| 02:58.17 |
Malyce |
can you give
me the mailing list ? The one on the GSOC website was
wrong |
| 02:58.25 |
AlexandreGuedes |
brlcad: I
have a question about patch to gsoc acceptance.. |
| 02:59.00 |
AlexandreGuedes |
As sample
patch I could implement an alteration that allows users to
visualize the exported model. |
| 02:59.27 |
AlexandreGuedes |
That would be
interesting and acceptable? |
| 02:59.41 |
brlcad |
Malyce: wrong
how so? it shouldn't be |
| 02:59.45 |
AlexandreGuedes |
I should use
glut and opengl functions. |
| 03:00.02 |
brlcad |
Malyce: it's
also on our wiki under the submission guidelines |
| 03:00.30 |
brlcad |
AlexandreGuedes: we have a modeler and
ray-tracing system for visualizing models.. :) |
| 03:01.02 |
Malyce |
where can I
find info on the patch that we have to do ? |
| 03:01.11 |
brlcad |
plus, how are
you going to visualize a boolean operation between an implicit
ellipsoid and a torus? |
| 03:01.11 |
AlexandreGuedes |
brlcad: but
is to visualizing exported models... |
| 03:01.44 |
brlcad |
Malyce: what
do you mean? |
| 03:02.38 |
Malyce |
Do we have to
write a patch as a prerequisite to GSOC ? |
| 03:02.39 |
brlcad |
you do
whatever patch you want to do |
| 03:02.53 |
Malyce |
Is it
necessary ? |
| 03:02.58 |
AlexandreGuedes |
brlcad: it is
just to modes that were already exported |
| 03:03.02 |
Malyce |
Or is it
complementary ? |
| 03:03.12 |
brlcad |
technically,
no you don't *have* to .. but your chances will be massively
hindered if you don't at least do something |
| 03:03.21 |
brlcad |
if you can do
something impressive, that can *greatly* increase your
chances |
| 03:03.54 |
brlcad |
AlexandreGuedes: native tounge portuguese
or spanish? |
| 03:04.46 |
AlexandreGuedes |
portuguese |
| 03:05.11 |
yukonbob |
brlcad:
"linkid" can be arbitrary string? |
| 03:05.20 |
brlcad |
basically
you'll be considered whether you make a patch or not -- but most
have submitted a patch and that *really* helps get a feel for how
you code and where we're starting |
| 03:05.28 |
brlcad |
yukonbob:
whatever you want it to be |
| 03:05.46 |
brlcad |
AlexandreGuedes: ah, okay .. I can only
read that and not very well, fluent in spanish |
| 03:06.04 |
Malyce |
I could work
on the Hierarchy Transversal Support |
| 03:06.18 |
brlcad |
so
AlexandreGuedes -- I wouldn't suggest an exported model viewer,
it's more important for us to import than export :) |
| 03:06.48 |
AlexandreGuedes |
ok.. |
| 03:07.04 |
Malyce |
would that be
something acceptable ? |
| 03:07.17 |
Malyce |
if I could
work on it and improve it somewhat ? |
| 03:08.18 |
brlcad |
AlexandreGuedes: how much time do you
think you have for a patch? |
| 03:08.39 |
brlcad |
that can
kinda steer how big of an idea you might be able to handle -- a
couple hours, couple days? |
| 03:08.44 |
yukonbob |
brlcad:
submitted |
| 03:08.48 |
brlcad |
ok |
| 03:09.14 |
AlexandreGuedes |
brlcad: i can
submit my patch after 3 april ? |
| 03:09.20 |
brlcad |
AlexandreGuedes: yes |
| 03:09.35 |
Malyce |
Oh, that
would be great |
| 03:09.35 |
brlcad |
just should
let someone know if that's the plan, maybe state it in your
proposal |
| 03:09.51 |
brlcad |
you have all
the way up until we do final rankings and select |
| 03:09.56 |
brlcad |
but obviously
the sooner the better |
| 03:10.11 |
AlexandreGuedes |
i have enough
time |
| 03:10.11 |
Malyce |
Or maybe if
you could suggest another idea, I could work on it
faster |
| 03:10.16 |
brlcad |
as we'll be
less inclined to bump you much higher/lower the closer we are to
the deadline |
| 03:11.11 |
brlcad |
fixing bugs
is always a great way to show your skill as it involves
comprehending and navigating code more than writing it |
| 03:11.15 |
brlcad |
writing code
is pretty easy |
| 03:11.35 |
brlcad |
reading it is
hard |
| 03:12.07 |
Malyce |
where can I
see the bug list ? |
| 03:12.07 |
brlcad |
yet with open
source, unlike school work and short-lived commercial products, you
usually end up reading code WAY more than you write
code |
| 03:12.28 |
brlcad |
there's a
BUGS file in the source checkout as well as a bugs tracker on
sourceforge |
| 03:12.44 |
brlcad |
Malyce: I'm
really getting the feeling that you've not read everything that
you're supposed to read on the wiki |
| 03:12.54 |
brlcad |
most of this
is even itemized there :) |
| 03:13.03 |
Malyce |
I've tried,
sorry. |
| 03:13.08 |
brlcad |
the brl-cad
wiki, not the gsoc wiki |
| 03:14.55 |
AlexandreGuedes |
brlcad:
ok... |
| 03:15.06 |
brlcad |
so there's
this: http://brlcad.org/wiki/Google_Summer_of_Code/Checklist
as well as
http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/HACKING |
| 03:15.11 |
brlcad |
both good
reading to get started |
| 03:15.19 |
brlcad |
the latter
describes where the trackers are |
| 03:15.30 |
brlcad |
http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/BUGS
is the venerable bugs file |
| 03:15.39 |
brlcad |
https://sourceforge.net/projects/brlcad
has the trackers |
| 03:15.46 |
AlexandreGuedes |
i'll try fix
a bug |
| 03:15.56 |
brlcad |
difference is
basically internally reported bugs vs externally reported
bugs |
| 03:16.38 |
Malyce |
You are
right, I hadn't seen this page |
| 03:17.38 |
brlcad |
if you want
to try a new code project, I suggest a simple importer that we
don't have like obj-g, x3d-g, or vrml-g (but should still follow
our HACKING guidelines) |
| 03:18.28 |
AlexandreGuedes |
brlcad: it is
just i would propouse |
| 03:19.26 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1340
10/wiki/Google_Summer_of_Code/Application_Guidelines: link to the
checklist in a few more places |
| 03:19.48 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1341
10/wiki/Google_Summer_of_Code/Application_Guidelines: silly
preview |
| 03:20.08 |
AlexandreGuedes |
i'm writing
my document ... |
| 03:20.33 |
brlcad |
Malyce:
http://brlcad.org/wiki/Google_Summer_of_Code/2009
is where the checklist was principally mentioned |
| 03:22.21 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1342
10/wiki/Google_Summer_of_Code: /* Getting Started */ |
| 03:23.07 |
Malyce |
The first
bug: "Windows MSVC build files seem to have the project
dependencies all |
| 03:23.08 |
Malyce |
<PROTECTED> |
| 03:23.33 |
Malyce |
It would be
easier for me to fix. But, will it count as a good patch
? |
| 03:25.05 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1343
10/wiki/Google_Summer_of_Code/Checklist: er, wtf.. send them to the
subscribe page, not the archives |
| 03:25.29 |
brlcad |
Malyce:
better than nothing, but would certainly prefer code over build
system |
| 03:25.43 |
brlcad |
and that task
is WAY more tedious than you are aware |
| 03:26.36 |
brlcad |
we have 400+
applications in BRL-CAD, about two-dozen libraries |
| 03:27.02 |
brlcad |
specifying
dependencies for 400+ items is rather grueling :) |
| 03:28.07 |
Malyce |
I
see |
| 03:28.09 |
Malyce |
* bot-bldxf
fails in db_walk_tree(), interface may have changed |
| 03:28.10 |
Malyce |
? |
| 03:28.18 |
Malyce |
too trivial
? |
| 03:29.39 |
brlcad |
m, I don't
recall what that bug entailed |
| 03:29.48 |
brlcad |
so no, not
too trivial if you figure that out and fix it ;) |
| 03:30.12 |
Malyce |
allright |
| 03:30.13 |
brlcad |
not too
exciting a bug to fix, but certainly more useful than build
system |
| 03:31.09 |
jonored |
Is there
another branch that the brep primitive is being worked on in, or is
trunk it? |
| 03:33.35 |
brlcad |
trunk is
it |
| 03:34.24 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 03:34.30 |
brlcad |
and I just
verified, the lists are not incorrect |
| 03:35.05 |
Malyce |
Thanks a lot
brlcad. I will get some sleep now, and then work on the
patch. |
| 03:35.08 |
Malyce |
Goodnight |
| 03:35.22 |
brlcad |
cool,
cya |
| 03:40.10 |
jonored |
So writing
rt_brep_norm and maybe rt_brep_curve would be a good patch? they
seem to not be there in trunk. |
| 03:50.57 |
brlcad |
jonored: wow,
and would be impressive if you actually did.. |
| 03:51.15 |
brlcad |
you know what
is involved there? :) |
| 03:58.20 |
jonored |
The first one
looks like it's not that bad... it looks like the uv coordinates
are stored and passed back, and for the normal it seems like that
should be either calling EvNormal or taking the cross product of
the u and v derivatives... am I missing something entirely?
Curvature would take thinking about calc, though. |
| 03:59.18 |
brlcad |
it'll hard to
implement and verify without brep ray tracing being
complete |
| 03:59.25 |
brlcad |
it only works
on some basic shapes at the moment |
| 03:59.38 |
brlcad |
though I
suppose you could use one of the test cases we already have that
render correctly |
| 03:59.43 |
brlcad |
and get uv
working right there |
| 03:59.57 |
brlcad |
hey, no --
that's cool -- go for it :) |
| 04:12.29 |
*** join/#brlcad madant
(n=d@117.196.132.207) |
| 04:15.36 |
andrecastelo |
nice mail,
brlcad |
| 04:15.57 |
andrecastelo |
just finished
reading the tale of two developers ;) |
| 04:16.58 |
bjorkintosh |
tail of two
developers? |
| 04:17.03 |
bjorkintosh |
was a
bikeshed involved? |
| 04:17.58 |
andrecastelo |
bjorkintosh:
the dreaded bike shed ;) |
| 04:18.08 |
andrecastelo |
bjorkintosh:
http://webchick.net/embrace-the-chaos |
| 04:18.35 |
brlcad |
thanks
andrecastelo |
| 04:18.53 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 04:19.58 |
brlcad |
love it,
particularly relevant for some of the devs on brl-cad and new devs
in general |
| 04:20.03 |
brlcad |
one of the
hardest tendencies to break |
| 04:20.30 |
brlcad |
but one that
almost *invariably* happens with impassioned open source
devs |
| 04:22.06 |
andrecastelo |
i was never
much of a pat person ;) i remember last year, someone said he/she
(don't remember now) liked big commits |
| 04:23.10 |
bjorkintosh |
Pat works in
isolation |
| 04:23.20 |
bjorkintosh |
pat is just a
skunk-works kinda guy. |
| 04:23.42 |
bjorkintosh |
probably
should be working for said organization. |
| 04:24.37 |
bjorkintosh |
hah. |
| 04:37.48 |
starseeker |
fixes archer icon colors |
| 04:40.18 |
yukonbob |
heads for home... maybe a coffee on the
way.. |
| 05:01.44 |
brlcad |
plays with the concept, still far from done: http://brlcad.org/tmp/arb8faces.png |
| 05:10.34 |
*** join/#brlcad Ralith|trip
(i=482b4af3@gateway/web/ajax/mibbit.com/x-93b0bfd208df83dd) |
| 05:10.42 |
Ralith|trip |
checks in again |
| 05:37.07 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 06:04.25 |
AlexandreGuedes |
brlcad:
hi |
| 06:04.44 |
AlexandreGuedes |
file formats
like obj vrml and x3d |
| 06:05.14 |
AlexandreGuedes |
are not CGS
system |
| 06:06.09 |
AlexandreGuedes |
i should
convert these in a BOT |
| 06:07.24 |
AlexandreGuedes |
(Bag of
Triangles) |
| 07:42.25 |
AlexandreGuedes |
brlcad: are
you on ? |
| 07:43.07 |
alex_joni |
AlexandreGuedes: it's night over
there |
| 07:43.11 |
alex_joni |
wait a couple
hours |
| 07:43.24 |
AlexandreGuedes |
hum.. |
| 07:43.48 |
AlexandreGuedes |
alex_joni:
where are you from ? |
| 07:50.14 |
pacman87 |
~ask |
| 07:50.14 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
| 07:50.55 |
pacman87 |
AlexandreGuedes: ^^ |
| 07:51.33 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 07:51.46 |
b0ef |
was any work
started on the new interactive gui? |
| 08:12.17 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:20.10 |
alex_joni |
AlexandreGuedes: .ro |
| 08:23.18 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:43.36 |
brlcad |
AlexandreGuedes: yes, they are non-csg, so
you convert to a non-csg during export (there are plenty of
examples of other converters), or pick another converter that does
support csg (like pov-g) |
| 08:44.23 |
brlcad |
b0ef: yes,
but discussion for later |
| 09:46.19 |
CIA-40 |
BRL-CAD:
03202.3.77.143 07http://brlcad.org
* r1344 10/wiki/User:Hippieindamakin87: /* Deliverables
*/ |
| 09:58.24 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:59.37 |
CIA-40 |
BRL-CAD:
03202.3.77.143 07http://brlcad.org
* r1345 10/wiki/User:Hippieindamakin87: |
| 10:05.05 |
hippieindamakin8 |
brlcad, any
comments ? |
| 10:06.38 |
hippieindamakin8 |
on the
wiki |
| 10:09.51 |
mafm |
hallo |
| 10:11.23 |
hippieindamakin8 |
hey
mafm |
| 10:11.30 |
hippieindamakin8 |
good
morning |
| 10:22.58 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1346 10/wiki/User:Hippieindamakin87: |
| 10:46.04 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1347 10/wiki/User:Hippieindamakin87: |
| 10:51.10 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1348 10/wiki/User:Hippieindamakin87: |
| 10:56.37 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:36.56 |
AlexandreGuedes |
my plan is
use simple shapes like triangles to represent a model |
| 11:37.39 |
mafm |
AlexandreGuedes: did you submit
them? |
| 11:38.20 |
AlexandreGuedes |
not
yet |
| 11:41.39 |
*** join/#brlcad madant
(n=d@117.196.128.52) |
| 11:47.42 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 11:49.33 |
mafm |
AlexandreGuedes: you only have a few hours
left |
| 11:49.48 |
mafm |
madant:
hippieindamakin8: welcome back |
| 11:49.57 |
AlexandreGuedes |
i'm
finishing |
| 11:50.13 |
mafm |
nice
:) |
| 11:50.25 |
AlexandreGuedes |
thanks |
| 11:50.28 |
hippieindamakin8 |
mafm, hey
:) |
| 11:50.41 |
hippieindamakin8 |
mafm, making
a presentation on NOx emmisions :P |
| 11:50.43 |
AlexandreGuedes |
this week i
had many dead lines.. |
| 11:52.06 |
mafm |
AlexandreGuedes: be sure to submit to
google first to not have problems later, then try to follow the
specific brlcad deadlines: submitting it to the mailing list,
creating pages in the wiki, starting to think about a patch if you
haven't yet, etc :) |
| 11:52.31 |
mafm |
hippieindamakin8: I hope that you're not
making a hands-on NOx emission! |
| 11:52.49 |
mafm |
or rather,
live methane emission |
| 11:52.50 |
mafm |
:P |
| 11:53.37 |
hippieindamakin8 |
:P mafm nope
.my term paper for the energy systems course was on NOx emmisions
and HCCI technology |
| 11:57.26 |
mafm |
nice |
| 11:57.52 |
mafm |
maybe you
should apply for tata instead of brlcad! ;) |
| 12:02.47 |
brlcad |
AlexandreGuedes: our format is very
generalized and flexible, so you will be able to import their
geometry into our container with pretty much 1-1 faithful
preservation |
| 12:02.59 |
brlcad |
if they have
polygons, you import as nmg |
| 12:03.06 |
brlcad |
if they have
triangles, you import as bot |
| 12:03.13 |
brlcad |
if they have
primitives, you import as primitives, etc |
| 12:03.47 |
brlcad |
hippieindamakin8: not yet -- said
submitting near the deadline would make things more tough! several
need a review |
| 12:04.31 |
hippieindamakin8 |
brlcad, i do
understand :) u did tell us that u would be extremely busy at this
point of time |
| 12:07.26 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 12:08.04 |
mafm |
wants a percentage of google stipends for herding gsoc
students into brlcad trap :P |
| 12:21.36 |
hippieindamakin8 |
mafm, how abt
keep mafm happy fund :P |
| 12:25.40 |
mafm |
yay, that'll
make it :D |
| 12:26.30 |
mafm |
I'll donate 1
or 2 pennies to brlcad too, for his patience |
| 12:26.42 |
mafm |
brlcad-the-man, I mean |
| 12:27.57 |
mafm |
bbiab |
| 12:32.31 |
*** join/#brlcad madant
(n=d@117.196.133.97) |
| 12:42.28 |
starseeker |
brlcad: nice
sketch! |
| 12:42.55 |
starseeker |
I'd suggest
that it might be better to have the green faces non-transparent,
and leave the center cube transparent |
| 12:44.50 |
starseeker |
but a VERY
nice job - I take it you did that in BRL-CAD itself? |
| 12:45.24 |
hippieindamakin8 |
hey
starseeker |
| 12:47.00 |
starseeker |
howdy |
| 12:48.26 |
*** join/#brlcad elite01_
(n=omg@unaffiliated/elite01) |
| 12:50.35 |
*** join/#brlcad madant
(n=d@117.196.135.227) |
| 12:56.54 |
starseeker |
hippieindamakin8: I notice you suggest the
use of LiDIA, which would in turn involve LAPACK. That's a pretty
hefty set of requirements |
| 12:56.55 |
*** join/#brlcad madant_
(n=d@117.196.135.227) |
| 12:59.05 |
hippieindamakin8 |
starseeker,
yeah but re-implementing the multi-precision floating point libs
takes way too much of time |
| 12:59.25 |
starseeker |
Hmm. Need
brlcad to weigh in on this |
| 12:59.42 |
starseeker |
LiDIA's
license is a little funky |
| 13:00.20 |
hippieindamakin8 |
aah is it
? |
| 13:00.31 |
starseeker |
it MIGHT be
ok, but it needs studying |
| 13:00.32 |
hippieindamakin8 |
looks at the documentation of LiDIA |
| 13:00.50 |
starseeker |
their
statement that it's "OK for noncommerical use" on the website is
worrisome |
| 13:01.21 |
hippieindamakin8 |
aah :| that
is not very good |
| 13:02.48 |
hippieindamakin8 |
starseeker, i
planned on tweaking arnd with the BOOLE system which already uses
the package LiDIA. |
| 13:03.21 |
starseeker |
the actual
license text isn't standard, at a quick read |
| 13:03.24 |
starseeker |
checks BOOLE |
| 13:03.37 |
hippieindamakin8 |
starseeker,
:| |
| 13:03.50 |
hippieindamakin8 |
Copyright
1997 The University of North Carolina at Chapel Hill. |
| 13:03.50 |
hippieindamakin8 |
<PROTECTED> |
| 13:03.50 |
hippieindamakin8 |
<PROTECTED> |
| 13:03.50 |
hippieindamakin8 |
<PROTECTED> |
| 13:03.50 |
hippieindamakin8 |
<PROTECTED> |
| 13:03.53 |
hippieindamakin8 |
<PROTECTED> |
| 13:03.54 |
hippieindamakin8 |
<PROTECTED> |
| 13:04.05 |
starseeker |
ow |
| 13:04.33 |
starseeker |
yeah, that
makes it sound like commercial use could be a problem |
| 13:04.34 |
hippieindamakin8 |
starseeker,
that shouldnt be a problem ! |
| 13:04.54 |
starseeker |
they specify
educational, research and non-profit purposes |
| 13:05.05 |
starseeker |
that means
other purposes do NOT have permission |
| 13:05.06 |
hippieindamakin8 |
:| |
| 13:05.25 |
hippieindamakin8 |
so i need to
re write the proposal |
| 13:06.41 |
hippieindamakin8 |
starseeker,
will get back to u in 5 mins. going to another lab in the next
building |
| 13:07.13 |
starseeker |
I've got to
get going myself |
| 13:07.21 |
starseeker |
just thought
I'd point out the potential issue there |
| 13:09.21 |
hippieindamakin8 |
starseeker,
any suggestions on how i should proceed ? |
| 13:10.08 |
starseeker |
are there any
similar libs with clearer licensing? |
| 13:10.34 |
starseeker |
You might
check with brlcad when he gets in - he has a broader knowledge of
this sort of software than I do |
| 13:10.43 |
hippieindamakin8 |
yeah nlt
starseeker |
| 13:11.18 |
hippieindamakin8 |
i have
checked nlt too . but planned on using liDIA as it was already
implemented in BOOLE |
| 13:11.53 |
hippieindamakin8 |
*ntl |
| 13:12.49 |
starseeker |
hippieindamakin8: do you have a link to
BOOLE handy? |
| 13:12.55 |
hippieindamakin8 |
yeah |
| 13:13.04 |
hippieindamakin8 |
http://www.cs.unc.edu/~geom/CSG/boole.html |
| 13:14.06 |
hippieindamakin8 |
starseeker,
if LiDIA cant be used then ntl(http://www.shoup.net/ntl/) can be
used along with GMP |
| 13:15.15 |
starseeker |
NTL is GPL,
not LGPL |
| 13:15.22 |
hippieindamakin8 |
http://www.cs.unc.edu/~geom/CSG/BOOLE-DOCS/copyright |
| 13:15.39 |
starseeker |
yeah, saw
that |
| 13:16.06 |
starseeker |
you should
ask brlcad about those license questions and whether they make
using those in the project a non-starter |
| 13:16.31 |
hippieindamakin8 |
yeah
:| |
| 13:16.55 |
starseeker |
ok, I gotta
run |
| 13:17.11 |
hippieindamakin8 |
starseeker,
thanks and cya |
| 13:35.58 |
``Erik |
*readreadread* |
| 13:36.41 |
``Erik |
a patch lets
us know you are able to a) use subversion and b) build the system.
I wouldn't sweat the patch phase too much :) |
| 13:37.07 |
``Erik |
dependancies
... all that info is defined in the makefile.am, so it could be a
reasonably simple translation issue (though tedious,
yes) |
| 13:37.31 |
``Erik |
all heil the
bikeshed! |
| 13:38.12 |
``Erik |
brlcad:
perhaps we should generate a list of pre-acceptance patch ideas
next time around? |
| 13:39.51 |
``Erik |
musta picked
up a stomach virus or something, was bugging me yesterday, now it's
messing with me bad 'nuff that I can't drive far :( had to call
into work |
| 13:40.26 |
``Erik |
stopped by
the shop, got an updated estimate, gonna be another month to repair
:( and close to the $ for a total :( sucks |
| 13:40.40 |
``Erik |
a lot of the
pieces are 3x the price of a normal component for a 3
series |
| 13:40.44 |
``Erik |
sucks. |
| 13:43.38 |
mafm |
3
series? |
| 13:49.55 |
bjorkintosh |
bmw. |
| 13:50.17 |
bjorkintosh |
what's wrong
with your vehicle, ``Erik ? |
| 13:51.13 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 13:56.52 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 14:01.07 |
``Erik |
bumped a
curb |
| 14:01.25 |
``Erik |
http://brlcad.org/~erik/m3-2/ |
| 14:02.13 |
``Erik |
(looks bad
there, they'd pulled the bumper cover out and removed the plastic
cover from teh wheelwell) |
| 14:03.19 |
``Erik |
and for some
reason, brlcad refuses to loan me his brand new lotus O.o :D
*duck* |
| 14:04.02 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 14:13.04 |
brlcad |
still isn't satisfied.. http://brlcad.org/tmp/edit_arb8_1024.png |
| 14:13.10 |
brlcad |
but
better |
| 14:13.51 |
AlexandreGuedes |
i should link
papers ? |
| 14:14.09 |
AlexandreGuedes |
in my project
... |
| 14:14.15 |
brlcad |
starseeker:
yeah, the sketch was all done in brl-cad, that latter had a little
compositing done to it to get the right emphasis |
| 14:14.26 |
``Erik |
if you want,
alexandre |
| 14:15.09 |
brlcad |
we have
permission from the boole authors to do what we want with
boole |
| 14:15.35 |
``Erik |
boole
project? O.o |
| 14:15.46 |
brlcad |
has/had that in e-mail somewhere -- could probably talk to
manocha again and get another okay if it became critical
issue |
| 14:15.48 |
``Erik |
google isn't
helpful, it gives me george boole plus some lithp stuff |
| 14:16.54 |
``Erik |
has spent the morning on the phone in legal and contractual
type things, so may be apt to go all pointy-haired retarded at any
moment, btw... like requesting signed approval via fax for boole,
whatever that is :D *duck* *run* *hide* |
| 14:17.16 |
brlcad |
``Erik:
possibly (re patch ideas) .. I was thinking of identifying
TODO/BUGS items with a "QUICKIE" label of some sort for the ones
that should be pretty simple (less than a full day's
effort) |
| 14:17.51 |
``Erik |
we have to
fight the notion of a 'veteran' grabbing a quickie just to get it
knocked off, though |
| 14:18.01 |
brlcad |
AlexandreGuedes: you can link papers if it
helps clarify |
| 14:18.09 |
``Erik |
the "just do
it" vs training opportunity is a beeyotch |
| 14:18.27 |
brlcad |
more
interesting is to usually link to a portfolio / profile if you have
one, but if not that's fine too |
| 14:18.42 |
brlcad |
``Erik:
search for "boole csg" |
| 14:18.48 |
brlcad |
work done at
UNC |
| 14:18.56 |
``Erik |
unc? |
| 14:19.05 |
``Erik |
I think I've
seen this before |
| 14:19.08 |
brlcad |
university of
north carolina at chapen hill |
| 14:19.12 |
brlcad |
you
have |
| 14:19.17 |
brlcad |
that's our
bradley |
| 14:19.17 |
``Erik |
was this one
of the utah rt posters? |
| 14:19.36 |
brlcad |
the only
folks (in academia) that I know of that got an actual vehicle .g
transfer |
| 14:19.51 |
brlcad |
no,
boole/esolid are older research |
| 14:19.56 |
``Erik |
wants to arl1 the hilux |
| 14:20.17 |
AlexandreGuedes |
brlcad:
papers tha had wirte, but they aren't strongly related with
brl-cad... |
| 14:20.39 |
``Erik |
alexandre:
we're looking for competency and utility, not necessarily
relation |
| 14:20.54 |
brlcad |
dinesh and
john keyser are the guys behind those works, you may have
met/remember them from siggraph |
| 14:21.32 |
AlexandreGuedes |
ok
thanks |
| 14:21.38 |
``Erik |
someone who
did mad awesome code in say firefox would be a big bump up when we
try to select :) |
| 14:21.50 |
brlcad |
AlexandreGuedes: that wasn't for you, that
was for ``Erik ;) |
| 14:22.09 |
brlcad |
AlexandreGuedes: it's your judgement to
determine whether it's worth linking them or not |
| 14:22.47 |
``Erik |
uh, someone
said something about gsoc not being about applying for a job... I'd
argue that's incorrect, but it's a short term contract job, so the
focus is different |
| 14:22.56 |
AlexandreGuedes |
brlcad: I was
thanking eriki by the information |
| 14:23.07 |
``Erik |
it's about
saying "I can do awesome things that you want", not "I'll be an
awesome team member for the next 20 years" |
| 14:23.31 |
hippieindamakin8 |
hey
brlcad |
| 14:23.45 |
hippieindamakin8 |
starseeker,
and i had a discussion on the licences |
| 14:23.58 |
brlcad |
typ0: I don't
generally answer "hellos" via PM -- if you have something to say or
ask, I'd be more than happy to talk but it's not the "IRC-way" to
do a "hi ..[wait].. hi ..[wait].. are you there? .. [wait] .. "
just say what you were going to say |
| 14:24.19 |
``Erik |
happy people
get paid to do what what love, hopefully we attract folk who are
happy doing stuff in open source BRL-CAD land and they continue to
contribute :) |
| 14:24.48 |
``Erik |
oh, uh,
uhhhhh esr has something about that |
| 14:24.51 |
``Erik |
"don't ask to
ask" |
| 14:24.51 |
hippieindamakin8 |
brlcad, wat
do u say about it |
| 14:25.07 |
brlcad |
``Erik:
actually i'd rather them sell the latter :P |
| 14:25.13 |
jonored |
Is it known
(off the top of people's heads) to not be valid to translate a
spline between two surfaces (with a not-unreasonable error formula)
by translating its control points?... |
| 14:25.21 |
brlcad |
and the point
is to acquire new devs, not just get some code out of
folks |
| 14:25.40 |
``Erik |
we want the
20 year folk, yes. But we don't need the full grilling that those
guys recieve... |
| 14:25.42 |
brlcad |
the
short-term contract is just the mechanism to help kick things off
and keep bills paid |
| 14:25.56 |
hippieindamakin8 |
as in LiDIA
and boole's licences arent straightforward. if instead of LidIA
,ntl(which is just GPL and not LGPL) is used along with GMP how bt
it |
| 14:26.27 |
``Erik |
and I like to
imagine that it's an important and fun project with nice and fun
people, so there's a lot of imputus to stick around |
| 14:26.35 |
hippieindamakin8 |
brlcad,
``Erik ^ |
| 14:26.45 |
``Erik |
but it's
definitely not a "bust out the cv and wear a tie" deal |
| 14:27.47 |
``Erik |
perhaps I'd
be better in phrasing it that the goal is to impress the geeks, not
a pointy haired mgmt type :) |
| 14:28.54 |
brlcad |
yeah, thats
pretty much what I said to folks last night too .. don't really
care who you are or what school you go to -- care about what you
want to do, your ability to do that work, and your short/long term
interests |
| 14:29.49 |
``Erik |
*nod*
sage |
| 14:29.52 |
brlcad |
thinks http://brlcad.org/tmp/edit_arb8_1024.png
makes for a decent BREP image too |
| 14:30.07 |
brlcad |
hmm |
| 14:30.32 |
``Erik |
heh, mensa is
a fistful of 'smart' useless people, people who really matter dont'
join mensa, they go do something real :D |
| 14:30.45 |
brlcad |
has a little
problem that I made the numbers too small to scale it down to
128x128 |
| 14:30.51 |
``Erik |
it's what ya
do, not what ya have |
| 14:30.55 |
brlcad |
not really
readable under 512x512 |
| 14:31.24 |
brlcad |
thinks ``Erik is gazing a little to deeply into his mensa
navel now :) |
| 14:31.35 |
``Erik |
declined the
invite |
| 14:31.50 |
``Erik |
had better
things to do than pay for a circlejerk |
| 14:32.18 |
brlcad |
and no way,
you can borrow Elle .. she's seen what you do to your
babies |
| 14:32.34 |
brlcad |
heh,
s/,// |
| 14:32.34 |
``Erik |
this morning,
for example, I'm figuring out the relationship between REST and
continuation based web frameworks |
| 14:32.53 |
``Erik |
heh, wow,
that erroneous grammer could be... fatal :D |
| 14:33.27 |
``Erik |
they're
digging to look for mechanical failure :/ |
| 14:33.49 |
``Erik |
I doubt
they'd be able to identify any with legal sureness,
though |
| 14:33.51 |
``Erik |
sucks |
| 14:34.10 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@187-24-10-94.3g.claro.net.br) |
| 14:34.19 |
poolio |
brlcad: was
that around when I was working on brep code? |
| 14:34.26 |
brlcad |
doesn't even want to know how you happened to hit a
curb |
| 14:34.31 |
brlcad |
poolio: no, I
just did that this morning |
| 14:34.31 |
``Erik |
<-- would
be willing to swap cars on a drive to lunch some day, just to see
what it's about, though :) |
| 14:34.32 |
``Erik |
well |
| 14:34.34 |
``Erik |
I
stopped |
| 14:34.38 |
``Erik |
I started
moving and turned left |
| 14:34.54 |
``Erik |
and then the
car quit turning and went straight a bit |
| 14:34.57 |
``Erik |
and there was
a curb in the way |
| 14:35.23 |
``Erik |
tha'ts my
best recollection, of course your brain goes all sorts of nutty
when you're in an accident like that, so *shrug* who
knows |
| 14:35.50 |
brlcad |
sure, blame
it on the curb |
| 14:35.58 |
``Erik |
it jumped
outta nowhere, honest |
| 14:36.06 |
brlcad |
they do
that |
| 14:36.20 |
``Erik |
almost got
rear-ended by a truck this morning, tailgating me and a squirrel
when whacko on the road |
| 14:37.46 |
``Erik |
how's release
coming? saw a couple commits last night |
| 14:40.47 |
CIA-40 |
BRL-CAD:
03202.3.77.11 07http://brlcad.org *
r1349 10/wiki/User:Hippieindamakin87: /* Proposed approach
*/ |
| 14:42.27 |
typ0 |
BRL-CAD
7.10.4 isn't launching on my PPC Mac |
| 14:43.13 |
typ0 |
it complains
about using CoreFoundation functionality after fork() without an
exec() |
| 14:43.30 |
typ0 |
when i try to
launch mged |
| 14:53.35 |
``Erik |
which version
of osX? |
| 14:53.41 |
typ0 |
Leopard |
| 14:53.43 |
typ0 |
10.5.6 |
| 14:54.09 |
``Erik |
hrm, we have
10.4 on ppc, but only intel for 10.5 |
| 14:54.35 |
``Erik |
can you paste
the full error log to http://pastebin.bzflag.bz/
? |
| 14:54.39 |
typ0 |
sure |
| 14:55.50 |
typ0 |
http://pastebin.bzflag.bz/m5dfb3330 |
| 14:56.37 |
``Erik |
thanks...
*guru meditation* |
| 14:57.00 |
``Erik |
smells like
forkbomb prevention gone awry |
| 14:57.03 |
typ0 |
if i follow
those instructions and with gdb I break on that symbol, i can't
even do much |
| 14:57.13 |
typ0 |
because the
program exits with interrupted syscall |
| 14:57.32 |
typ0 |
i've seen
this error before, i think in a php lib |
| 14:57.42 |
``Erik |
is it
acceptable to suggest grabbing 7.14.4 from the site and compiling
yourself? |
| 14:57.43 |
typ0 |
probably a
leopard restriction |
| 14:57.49 |
typ0 |
of
course |
| 14:58.00 |
``Erik |
7.10.4 is
very outdated :) |
| 14:58.22 |
typ0 |
i want to
write an application to improve IGES importer/exporter |
| 14:58.31 |
typ0 |
any useful
tips ? |
| 14:58.38 |
``Erik |
oh, then you
don't want 7.14.4, you want the svn 'trunk' checkout |
| 14:59.48 |
hippieindamakin8 |
brlcad,
help |
| 15:00.05 |
``Erik |
(which should
be named "7.14.6" real soon now, if hippie would quit bugging
brlcad) |
| 15:00.05 |
``Erik |
:D |
| 15:00.11 |
``Erik |
'sup,
hippie? |
| 15:00.45 |
hippieindamakin8 |
``Erik, the
problem is that the packages i intended to use are MAPC and LiDIA
initially |
| 15:00.54 |
``Erik |
license
issues? |
| 15:01.14 |
hippieindamakin8 |
yeah |
| 15:01.33 |
hippieindamakin8 |
``Erik, the
licence issues are like this both MAPC and LiDIA are
copywrit. |
| 15:01.41 |
hippieindamakin8 |
or
copyrighted |
| 15:02.12 |
``Erik |
hm, sit on
it. we'll think. if it's just gpl, and we don't want to further
infect the primary repo, it may be doable as a new
module |
| 15:02.31 |
hippieindamakin8 |
``Erik,
neither of them is gpl either |
| 15:02.40 |
``Erik |
oh, uh, url's
for licenses? |
| 15:02.51 |
``Erik |
dreads having to summon a legal team :( |
| 15:02.52 |
hippieindamakin8 |
i actually
couldnt find any exact arithmetic packages which are
LGPL |
| 15:03.02 |
``Erik |
isn't gmp
lgpl? |
| 15:03.10 |
hippieindamakin8 |
``Erik, it
is |
| 15:03.38 |
hippieindamakin8 |
``Erik,
http://brlcad.org/wiki/User:Hippieindamakin87#Proposed_approach |
| 15:03.42 |
hippieindamakin8 |
this is my
approach |
| 15:03.49 |
``Erik |
gmp is an
exact precision package, no? do I fail to see
something? |
| 15:04.22 |
hippieindamakin8 |
``Erik,
ftp://ftp.informatik.tu-darmstadt.de/pub/TI/systems/LiDIA/current/COPYING |
| 15:04.35 |
``Erik |
exact
arithmetic, lazy evaluation... talkin' haskell here? :D |
| 15:06.46 |
hippieindamakin8 |
``Erik, their
implementation in c++ |
| 15:07.19 |
hippieindamakin8 |
``Erik, i had
a plan of spawning a functional programming language from C++ to do
this processes |
| 15:07.55 |
hippieindamakin8 |
``Erik, how
abt that ? |
| 15:08.08 |
hippieindamakin8 |
prefers python for that |
| 15:08.49 |
``Erik |
in theory, we
intend to introduce python, common lisp, and something else as
basic scripting langauges to BRL-CAD |
| 15:09.32 |
``Erik |
so,
personally, the notion of python is not a showstopper in my mind...
but I may be wrong, I defer to brlcad for an official
stance |
| 15:09.37 |
hippieindamakin8 |
``Erik, ur
comments on the procedure ? |
| 15:10.13 |
``Erik |
I've made all
the comments I'm comfortable making :) my brain isn't 100% today...
called in sick to work, etc |
| 15:11.03 |
hippieindamakin8 |
``Erik, i am
very comfortable with python so that is the reason i wanted to
implement it with python |
| 15:11.16 |
``Erik |
also; my
proxy is farting on the ftp notion, so'z I can't view all the
relevant data :( |
| 15:11.27 |
hippieindamakin8 |
ohh |
| 15:11.33 |
``Erik |
<-- far
more of a ruby fan than python :) |
| 15:12.00 |
``Erik |
guido has
something rollin', but I think he misses a few critical
points |
| 15:12.15 |
``Erik |
I think the
next ruby is gonna remove some important stuff that I don't think
matz groks :( |
| 15:12.26 |
hippieindamakin8 |
``Erik, for
the gsoc i ll code in python and then port it to ruby once i get
more familiar with ruby by the end of summers |
| 15:12.58 |
``Erik |
make sure
that plan is in your proposal |
| 15:13.03 |
jonored |
seems to remember something about someone doing a test and
python coming out 400 times slower than C++, and 100 times slower
than common lisp, on some basic numerical
stuff... |
| 15:13.24 |
``Erik |
micro-benchmarks tend to produce stupid
numbers like that :( |
| 15:13.53 |
``Erik |
I've seen
some where common lisp blows c++ out of the water... |
| 15:14.13 |
``Erik |
the caveats
are critical :) |
| 15:14.55 |
jonored |
The only ones
I've seen on that are where it's testing stuff that gets
essentially compiled out... that one was (I think) just matrix
multiplication. |
| 15:15.29 |
hippieindamakin8 |
jonored, for
matrix multiplications fortran is much faster than anything
else |
| 15:15.31 |
``Erik |
fortran
stomps C on naive matrix mults on modern hardware... |
| 15:15.35 |
``Erik |
aint' sayin'
much, yo |
| 15:16.50 |
``Erik |
(and the ONLY
reason fortan wins is because their multidimensional arrays are
column major instead of row major, so it just happens to tweak the
cache lines a little better) |
| 15:19.56 |
``Erik |
is doing cl stuff in personal time due to the faster "time to
market" aspect :) |
| 15:20.52 |
jonored |
is in general very keen on common lisp. The only irritation
is that it doesn't have first-class continutions and scheme
does... |
| 15:22.40 |
brlcad |
no python for
gsoc with only a few exceptions (ged/ge/gs scripting and web
stuffs) |
| 15:22.48 |
hippieindamakin8 |
``Erik,
listen so technically openNURBs library which is being used
shouldnt be used is it ? |
| 15:23.00 |
brlcad |
there's not
enough time to be productive and integrate something well with the
code base |
| 15:23.16 |
*** join/#brlcad madant
(n=d@117.196.128.181) |
| 15:23.22 |
hippieindamakin8 |
brlcad, so
the implementation shall purely be in C++ |
| 15:23.37 |
brlcad |
it's one
thing for an existing core dev to pick up a python project,
entirely different for someone new just picking something familiar
without regard to what we have or the impact |
| 15:23.57 |
``Erik |
jonored:
there're a couple addons that provide zomfg call/cc, I'm a scheme
head myself :) #ucw is the channel for the framework I'm using, it
provides call/cc |
| 15:24.06 |
*** join/#brlcad madant
(n=madant@117.196.128.181) |
| 15:24.34 |
``Erik |
aight,
there's your answer, python ain't cool for a gsoc, it's down teh
road for the gurus |
| 15:24.43 |
*** join/#brlcad devilsadvocate
(n=devilsad@202.3.77.11) |
| 15:25.12 |
``Erik |
note all the
cya I threw down in that avenue :D |
| 15:25.36 |
hippieindamakin8 |
brlcad, i was
just proposing tht python shall be used only in the library( away
from the core code) |
| 15:26.13 |
hippieindamakin8 |
brlcad, if
that is wat you say, i shall implement the said routines in c++
itself |
| 15:26.21 |
``Erik |
is, um,
what's its name... swag? is that gsoc purvue? |
| 15:27.00 |
``Erik |
we had a
summer student try&fail on it |
| 15:27.42 |
``Erik |
(unified
interface between a large set of languages) |
| 15:31.17 |
brlcad |
tick tock on
the applications for any still remaining |
| 15:32.33 |
brlcad |
mentors, feel
free to start commenting on them if you haven't already |
| 15:32.45 |
brlcad |
I won't be
commenting for at least an hour still |
| 15:33.01 |
``Erik |
hm |
| 15:33.14 |
brlcad |
hippieindamakin8: you didn't upset me in
the least, it was a valid question |
| 15:33.15 |
``Erik |
*look* 10 in
the queue |
| 15:33.40 |
hippieindamakin8 |
brlcad, yeah
thats very true that python all of a sudden :) |
| 15:34.01 |
``Erik |
imagines that the only ways to piss brlcad off is to either
key his car or shit on his rug |
| 15:34.06 |
``Erik |
(sorry 'bout
the rug) |
| 15:34.10 |
brlcad |
if you'd
brought it up two weeks ago, we could have discussed in better
detail ;) |
| 15:34.27 |
hippieindamakin8 |
brlcad, :|
yeah |
| 15:34.47 |
``Erik |
y'know if
d'lo is gonna log on and say hi when he gets to his families
place? |
| 15:35.03 |
brlcad |
doesn't care about his rug, now crap on my plasma, I might
care .. but then I'd wonder how you got it up that
high |
| 15:35.04 |
hippieindamakin8 |
but still
with respect to the proposal my proposal submitted , i dint intend
to use anything other than C/C++ |
| 15:35.36 |
``Erik |
note it in
your proposal. |
| 15:35.47 |
``Erik |
or if it is
noted, sorry for making noise :) |
| 15:36.13 |
``Erik |
looks at the proposals... |
| 15:36.56 |
typ0 |
brlcad: is
there a description of the new features in IGES 5.3 comparing to
5.0 |
| 15:37.11 |
typ0 |
that i can
use to create a task list with a schedule |
| 15:38.45 |
jonored |
is going to have a sadly rushed proposal, but will have
something in before the deadline... and hopes that a good patch
afterwards could help a bit with a somewhat technically weaker
proposal write-up. |
| 15:38.57 |
CIA-40 |
BRL-CAD:
03202.3.77.11 07http://brlcad.org *
r1350 10/wiki/User:Hippieindamakin87: /* Timeline */ |
| 15:38.58 |
``Erik |
ugh. too much
marketspeak |
| 15:40.12 |
*** join/#brlcad lifeeth
(n=praneeth@unaffiliated/lifeeth) |
| 15:41.16 |
brlcad |
typ0: that's
part of the leg work for that project |
| 15:41.26 |
typ0 |
ok |
| 15:41.27 |
brlcad |
I'm sure
someone, somewhere, has that information |
| 15:41.30 |
brlcad |
I certainly
don't :) |
| 15:41.33 |
typ0 |
eheh |
| 15:41.38 |
``Erik |
naturally,
dawn is incredibly verbose, but quite high level |
| 15:41.40 |
typ0 |
i searched
around and didn't find much |
| 15:41.46 |
brlcad |
iirc, you can
get at least comment drafts for iges online now |
| 15:41.59 |
typ0 |
i can do it
during the community bonding period |
| 15:42.02 |
typ0 |
should i get
accepted |
| 15:42.03 |
brlcad |
the 6.0 draft
for example |
| 15:42.08 |
typ0 |
cool |
| 15:42.15 |
brlcad |
that was a
couple years ago though |
| 15:42.30 |
brlcad |
i might have
it stashed away, can check .. should you get accepted |
| 15:42.58 |
typ0 |
ok i'll work
on the application |
| 15:43.45 |
``Erik |
o.O |
| 15:44.21 |
``Erik |
well, typ0...
would you be interested in being part of our community even if you
weren't accepted to our gsoc presense? |
| 15:45.23 |
*** join/#brlcad madant
(n=madant@117.196.146.192) |
| 15:46.52 |
typ0 |
well i find
the IGES idea quite doable and interesting |
| 15:47.15 |
typ0 |
and always
had an interest in CAD systems, even if i don't know a lot about
them |
| 15:47.45 |
typ0 |
so i can do
the project , and even continue working on it post-gsoc |
| 15:47.55 |
typ0 |
and take it
from there |
| 15:48.05 |
typ0 |
btw, latest
svn is not compiling on my mac |
| 15:48.07 |
typ0 |
http://pastebin.bzflag.bz/m7085cb13 |
| 15:48.07 |
``Erik |
I'm not
grilling you, I'm just trying to learn more of your interests and
abilities :) |
| 15:48.37 |
``Erik |
up's on his mac |
| 15:48.51 |
typ0 |
;) |
| 15:49.11 |
``Erik |
effin'
configure.ac change :( *wait* |
| 15:49.53 |
``Erik |
the paste
looks like you're missing X headers |
| 15:50.12 |
``Erik |
both the X
package and the X developer package need to be installed
:/ |
| 15:50.34 |
``Erik |
ooh, automake
error |
| 15:50.42 |
``Erik |
error, not
warning, a full-up error |
| 15:51.13 |
typ0 |
i think i
have all the latest X11 stuff |
| 15:51.18 |
CIA-40 |
BRL-CAD:
03d_rossberg * r34145 10/rt^3/trunk/ (4 files in 2 dirs): added the
ellipsoid (ID_ELL) primitive |
| 15:52.12 |
brlcad |
libtkhtml
apparently isn't listing it's deps, needs Xlib |
| 15:52.41 |
brlcad |
probably
something their build file is doing |
| 15:52.59 |
brlcad |
try going to
that directory (src/other/tkhtml) and manually building |
| 15:53.29 |
brlcad |
add
-lX11 |
| 15:53.52 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 15:57.10 |
typ0 |
rm -f
libTkhtml3.0.dylib |
| 15:57.10 |
typ0 |
gcc (...)
-L/usr/lib -L/usr/local/lib
-L/System/Library/Frameworks/Tcl.framework/Versions/8.4
-ltclstub8.4 -L/System/Library/Frameworks/Tk.framework/Versions/8.4
-ltkstub8.4 -lX11 |
| 15:57.11 |
typ0 |
ld: library
not found for -lX11 |
| 15:57.11 |
typ0 |
collect2: ld
returned 1 exit status |
| 15:57.11 |
typ0 |
make: ***
[libTkhtml3.0.dylib] Error 1 |
| 15:57.53 |
brlcad |
so you either
need a library search path (-L...), or you don't have
it |
| 15:58.06 |
``Erik |
wow, qt as an
indicator for platform popularity, lame :) |
| 15:58.23 |
AlexandreGuedes_ |
I submitted
my project |
| 16:00.48 |
``Erik |
hah, wow,
whining about homework being a timekiller, uncool |
| 16:01.07 |
brlcad |
AlexandreGuedes_: great! |
| 16:01.07 |
typ0 |
yeah
-L/usr/X11/lib did it |
| 16:01.17 |
CIA-40 |
BRL-CAD:
03202.3.77.11 07http://brlcad.org *
r1351 10/wiki/User:Hippieindamakin87: /* Abstract */ |
| 16:01.52 |
AlexandreGuedes_ |
Someone can
confirm.. ? |
| 16:02.30 |
``Erik |
most systems
have /usr/X /usr/X11 and /usr/X11R6 pointing to the same real
directory |
| 16:02.51 |
typ0 |
yeah |
| 16:02.58 |
``Erik |
fbsd recenty
moved /usr/X11R6 to /usr/locla |
| 16:03.01 |
``Erik |
local,
even |
| 16:03.10 |
typ0 |
but in this
case the Makefile only made reference to /usr/lib and
/usr/local/lib |
| 16:03.19 |
``Erik |
*shrug*
./configure LDFLAGS=-L/usr/X11/lib |
| 16:03.20 |
``Erik |
:) |
| 16:03.42 |
brlcad |
either way,
the autoconf/automake tests should have found it since we just let
their tests do their thing during configure .. so something awry
there |
| 16:04.10 |
``Erik |
ok, mediafire
for a resume sucks goat balls. get a real effin' homepage to post
that. |
| 16:04.25 |
typ0 |
i have the
latest X11 package from apple (xquartz.macosforge.org) |
| 16:04.30 |
``Erik |
sucks, cuz I
like the idea, but the presentation blew :( |
| 16:04.51 |
*** part/#brlcad devilsadvocate
(n=devilsad@202.3.77.11) |
| 16:12.17 |
AlexandreGuedes_ |
It is
possible confirm if my submission were successfully? |
| 16:13.47 |
``Erik |
dude,
alexandre, wtf is with all the xml explosion that came through as
text? |
| 16:14.25 |
``Erik |
divs and font
types and stuff, and there's like 5 lines of content in that 3 page
monstrosity |
| 16:15.05 |
``Erik |
I created
src/conv/Formats.cvs a while back, d'no if you saw that |
| 16:20.25 |
``Erik |
wow, chinese
place says 25 minutes |
| 16:25.22 |
AlexandreGuedes_ |
``Erik: i can
erase it ? |
| 16:25.40 |
``Erik |
erase what,
the csv? |
| 16:26.45 |
``Erik |
bbaib,
heading to pick up lunch |
| 16:28.19 |
AlexandreGuedes_ |
the lines
with div and font types |
| 16:31.11 |
andrecastelo |
``Erik:
that's melange making us crazy :( |
| 16:31.32 |
andrecastelo |
i had those
appear more than once when I submitted |
| 16:32.43 |
typ0 |
the iges
converter works as a separate binary, ie, can i implement command
line parameters to specify the desired version to export/import
? |
| 16:32.50 |
*** join/#brlcad devilsadvocate
(n=devilsad@202.3.77.11) |
| 16:34.20 |
typ0 |
(i assume so
since there is command line options parsing in the
source) |
| 16:53.43 |
jonored |
...And
submitted. Short, but submitted. |
| 17:01.29 |
``Erik |
needs to learn how to say "thank you" and "chopsticks" in
chinese O.o |
| 17:02.44 |
AlexandreGuedes_ |
hard |
| 17:08.55 |
andrecastelo |
``Erik: easy,
domo arigato for thank you |
| 17:09.02 |
andrecastelo |
joking
;) |
| 17:17.30 |
``Erik |
mr robato?
what? |
| 17:26.43 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1352 10/wiki/User:Hippieindamakin87: |
| 17:28.16 |
CIA-40 |
BRL-CAD:
03Suryajith 07http://brlcad.org *
r1353 10/wiki/User:Hippieindamakin87: |
| 17:57.56 |
pacman87 |
is it
possible to create a degenerate NURBS that's a line instead of a
surface? |
| 17:58.19 |
*** part/#brlcad lifeeth
(n=praneeth@unaffiliated/lifeeth) |
| 18:15.17 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 18:15.36 |
Malyce |
Hi. I was
trying to make a patch to fix one of the bugs |
| 18:15.46 |
Malyce |
* bot-bldxf
fails in db_walk_tree(), interface may have changed |
| 18:15.57 |
Malyce |
What is
bot-bldxf ? |
| 18:17.30 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:24.22 |
typ0 |
hmm, i
finished building svn and mged launched, printed out a line about
using Tcl scripts from a directory, and then gave a bus
error |
| 18:24.26 |
typ0 |
Thread 0
Crashed: |
| 18:24.26 |
typ0 |
0
libdm.19.dylib 0x001447d8 X_open_dm + 1644
(dm-X.c:343) |
| 18:28.38 |
*** part/#brlcad devilsadvocate
(n=devilsad@202.3.77.11) |
| 18:34.56 |
typ0 |
btw, i just
submitted my application |
| 18:35.21 |
typ0 |
if there's
anything i should clarify or improve, i'd appreciate the feedback
:) |
| 18:35.40 |
pacman87 |
typ0: do you
have a wiki page yet? |
| 18:35.51 |
typ0 |
no |
| 18:38.09 |
typ0 |
i will create
it |
| 18:39.56 |
Malyce |
hints
? |
| 18:40.25 |
Malyce |
The tracker
has no mention of it |
| 18:40.34 |
Malyce |
its in the
BUGS list only |
| 18:42.39 |
Malyce |
Do all
applicants need a wiki page ? |
| 18:43.00 |
pacman87 |
not required,
but useful to bounce ideas around |
| 18:43.17 |
pacman87 |
how many
applicants are here now? |
| 18:44.15 |
Malyce |
as admin,
shouldn't you be able to tell ? |
| 18:44.29 |
pacman87 |
i'm not
admin |
| 18:44.40 |
Malyce |
is brlcad
still around ? |
| 18:44.49 |
Malyce |
or mafm
? |
| 18:44.49 |
pacman87 |
and i meant
'here' as in 'this channel' |
| 18:47.25 |
Malyce |
how do I find
out, what bot-bldxf means ? |
| 18:59.28 |
CIA-40 |
BRL-CAD:
03Carlosvsilva 07http://brlcad.org
* r1354 10/wiki/User:Carlosvsilva: Initial creation |
| 19:03.47 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-153-219.3g.claro.net.br) |
| 19:15.11 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:19.35 |
madant |
is now moderately un-sick :) |
| 19:20.35 |
hippieindamakin8 |
hey
madant |
| 19:21.30 |
madant |
hey
hippieindamakin8 |
| 19:24.45 |
Malyce |
hi madant.
Can you tell me how I can find out what 'bot-bldxf' means. It was
in the BUGS file, as in "* bot-bldxf fails in db_walk_tree(),
interface may have changed" |
| 19:24.51 |
Malyce |
? |
| 19:26.50 |
brlcad |
Malyce: by
asking -- bots are "bags of triangles" -- bldxf is "build a
dxf" |
| 19:26.57 |
brlcad |
it's a
horrible name, but it means make a dxf from a bot |
| 19:27.13 |
brlcad |
if you're
just getting started on that one, try for another bug |
| 19:27.34 |
brlcad |
there's
another tool that technically makes bot-bldxf
deprecated |
| 19:27.42 |
Malyce |
rats |
| 19:27.52 |
Malyce |
I was already
in the middle of it |
| 19:27.56 |
madant |
Malyce,
bot-bldxf and other dxf conversion tools are there in src/conv/dxf
directory |
| 19:28.00 |
brlcad |
well, you are
welcome to fix it |
| 19:28.00 |
Malyce |
I had read
and understood the code |
| 19:28.05 |
madant |
oops.. brlcad
beat me to it :D |
| 19:28.26 |
brlcad |
it's not
going away right away, and still perfectly serves the purpose of
the patch |
| 19:29.13 |
brlcad |
but the fact
that it's missing a manual page means it was an
unpublished/unfinished tool that never turned into a production
tool |
| 19:29.50 |
brlcad |
and since
then, there is now a bot_dump command that will export obj, dxf,
vrml |
| 19:31.23 |
brlcad |
Malyce: what
is your project? |
| 19:32.20 |
Malyce |
Extension of
Core C++ Interfaces |
| 19:32.34 |
Malyce |
I said I
would add primitive support |
| 19:32.46 |
brlcad |
so add
another primitive to the core interface |
| 19:33.01 |
brlcad |
daniel just
added another one today, you could use that as an
example |
| 19:33.12 |
Malyce |
how much time
did it take him ? |
| 19:33.19 |
brlcad |
ask
him |
| 19:33.45 |
Malyce |
I am worried
that it might take too long for the purpose of the
patch. |
| 19:33.52 |
brlcad |
so ask him
:) |
| 19:34.04 |
Malyce |
how ? The
mailing list ? |
| 19:34.10 |
brlcad |
the code
isn't that horribly complex, I can't imagine it was more than a day
or two |
| 19:34.13 |
brlcad |
sure |
| 19:34.24 |
brlcad |
probably just
a couple hours |
| 19:34.28 |
Malyce |
allright |
| 19:34.30 |
brlcad |
if even
that |
| 19:34.50 |
Malyce |
I should
probably alter my proposal then |
| 19:35.02 |
Malyce |
Because I
estimated 10-15 hours per primitive |
| 19:35.03 |
brlcad |
you could
implement the torus -- that should be fairly easy |
| 19:35.06 |
Malyce |
I wasn't
sure |
| 19:35.15 |
brlcad |
why would you
alter it now |
| 19:35.29 |
brlcad |
I don't know
how long it'll take -- ASK HIM :) |
| 19:35.37 |
Malyce |
yes |
| 19:35.37 |
Malyce |
I am on
it |
| 19:36.03 |
brlcad |
mine is just
a guess, but I'm also very familiar with that code |
| 19:36.37 |
brlcad |
your first
one would probably take a bit longer, but you'd be pretty familiar
after a couple |
| 19:39.20 |
Malyce |
he added
ellipsoid i see |
| 19:39.44 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 19:40.32 |
brlcad |
yeah, I would
have too |
| 19:40.40 |
brlcad |
he's probably
working on tgc or torus next ;) |
| 19:40.50 |
brlcad |
you'll
certainly get his attention with that patch ;) |
| 19:41.02 |
brlcad |
and he'd
likely be the mentor for your project, so good to talk to
him |
| 19:41.37 |
brlcad |
(though we do
group mentoring, you can call on anyone -- he's just the lead on
that area) |
| 19:42.14 |
Malyce |
Is it ok, if
I send it to the mailing list ? Won't it spam everyone
? |
| 19:42.28 |
brlcad |
the dev list
is pretty small |
| 19:42.45 |
brlcad |
the news and
user mailing lists are the big ones |
| 19:43.11 |
*** join/#brlcad andrecastelo
(n=andrecas@150.165.134.157) |
| 19:43.18 |
andrecastelo |
hi
guys |
| 19:44.17 |
brlcad |
howdy
andrecastelo |
| 19:44.25 |
andrecastelo |
howdy
brlcad |
| 19:44.27 |
brlcad |
how'd the
applications go? |
| 19:44.35 |
andrecastelo |
i've sent
only one, to blender |
| 19:44.45 |
brlcad |
cool, what
for? |
| 19:45.15 |
andrecastelo |
blender's
interface is being refactored and the way the inner data is
accessed is changing |
| 19:45.29 |
andrecastelo |
and the big
refactor will happen on version 2.5 |
| 19:45.55 |
andrecastelo |
with the
refactoring, the python scripts will become
incompatible |
| 19:46.08 |
andrecastelo |
so the
application was to port some import/export scripts to the new
system :) |
| 19:47.17 |
andrecastelo |
brlcad, how
were the proposals this year? |
| 19:47.37 |
andrecastelo |
everyone was
talking about a low number of proposals, i wonder why |
| 19:47.50 |
madant |
andrecastelo,
blender sounds kewl :) how is school ? |
| 19:47.52 |
brlcad |
andrecastelo:
curious actually |
| 19:48.02 |
brlcad |
our
applications were down about 25% from last year |
| 19:48.19 |
madant |
is always reminded of "Catelo's Castle" whenever he sees the
surname castelo :) |
| 19:48.34 |
brlcad |
bz's
applications are actually up about 40% from last year |
| 19:48.37 |
madant |
brlcad: and
quality-wise ;) ? |
| 19:48.45 |
brlcad |
quality is
better for both |
| 19:48.50 |
andrecastelo |
madant, i'm
currently in between semesters |
| 19:49.05 |
andrecastelo |
so, i'm free
of them :) |
| 19:49.08 |
madant |
hmm.. bz beat
us ( brl-cad - brlcad) :P |
| 19:49.10 |
andrecastelo |
and thus i'm
a happy man |
| 19:49.32 |
andrecastelo |
madant,
castelo = castle :) |
| 19:49.45 |
brlcad |
madant: the
game has an quite an appealing advantage :) |
| 19:49.48 |
madant |
andrecastelo,
i used to love both :) bunking classes and doing work in between
semesters :P |
| 19:50.30 |
madant |
is not at all a gamer :D == feels stupid about pushing keys
and moving the mouse imagining you are in a different
world |
| 19:50.30 |
andrecastelo |
i felt
demotivated this last semester, had some really bad
teachers |
| 19:50.57 |
hippieindamakin8 |
madant, but u
should try playing bzflag dude |
| 19:51.06 |
madant |
andrecastelo,
aah.. nice :) well Dawn = dawn, Thomas = twin .. :P |
| 19:51.08 |
andrecastelo |
i tried
bzflag but i do not have good reflexes |
| 19:51.36 |
madant |
is pretty sure he would suck at games too
;) |
| 19:51.37 |
hippieindamakin8 |
andrecastelo,
neither do i . but it is fun with that arena and those options
:) |
| 19:51.40 |
CIA-40 |
BRL-CAD:
03brlcad * r34146 10/brlcad/trunk/ (8 files in 7 dirs): peanut
butter release time, peanut butter release 7.14.6 with a baseball
bat |
| 19:52.00 |
madant |
ah what the
hell :) |
| 19:52.10 |
madant |
is installing bz |
| 19:52.15 |
hippieindamakin8 |
the only
games i play are "frets on fire" and "bzflag" |
| 19:52.21 |
starseeker |
blinks - peanut butter with baseball bats? |
| 19:52.32 |
hippieindamakin8 |
madant, put
the server as bzf.bzflag.net |
| 19:52.56 |
madant |
ok
:) |
| 19:52.59 |
hippieindamakin8 |
madant, the
lag from there was minimal when i was playing bzflag in
bangalore |
| 19:53.58 |
madant |
hippieindamakin8, thanks :) hope i don't
get addicted |
| 19:54.12 |
CIA-40 |
BRL-CAD:
03brlcad * r34147
10/brlcad/trunk/misc/win32-msvc8/g_diff/g_diff.vcproj: g_diff needs
libtclcad, oops on r34146 |
| 19:54.23 |
brlcad |
notes that starseeker definitely needs some peanut butter
jelly time |
| 19:54.25 |
hippieindamakin8 |
madant, it is
very rarely that some one joins tht game |
| 19:54.29 |
pacman87 |
you all up
for a bzflag game? |
| 19:54.45 |
brlcad |
pacman87:
hah, wish I could |
| 19:54.52 |
brlcad |
later today,
sure |
| 19:55.00 |
brlcad |
pacman87: who
all'd you apply to? |
| 19:55.06 |
pacman87 |
just
here |
| 19:55.15 |
madant |
pacman87,
hehe .. break from 6811 ;) |
| 19:55.20 |
brlcad |
ah, okay,
cool |
| 19:55.39 |
pacman87 |
i realized
the bzflag cheat prevention really needs the modularization of game
logic |
| 19:55.46 |
pacman87 |
so the server
can use the same code as the client |
| 19:56.25 |
brlcad |
it doesn't
"really" need it, but it would greatly help it |
| 19:56.44 |
brlcad |
i had started
more in-depth cheat preventions years ago with server-side dr and
shot tracking |
| 19:56.57 |
brlcad |
but my goal
was a networking optimization so I never committed it |
| 19:57.20 |
pacman87 |
unfortunate |
| 19:57.28 |
brlcad |
as there was
a net problem with players teleporting across the server (it was a
packet culling technique based on how close the other players were
from you) |
| 19:57.41 |
brlcad |
made network
use nearly linear |
| 19:58.11 |
brlcad |
would have
allowed bzflag servers to support something like 100 players on a
server that today can only support about 12 playesr |
| 19:58.20 |
pacman87 |
impressive |
| 19:58.26 |
brlcad |
if it wasn't
for those damn teleporters :) |
| 19:58.36 |
brlcad |
then I got
sidetracked before I finished implementing waypoints |
| 19:58.43 |
pacman87 |
you'd have to
do something like Portal |
| 19:58.47 |
brlcad |
but the basic
logic for server-side cheat checking was easily doable |
| 19:58.48 |
hippieindamakin8 |
brlcad, but
the teleporters add much more fun to that game ;) |
| 19:58.57 |
madant |
grr... what
is a good bzflag approach on TwinView :) windowed mode |
| 19:59.11 |
pacman87 |
madant: use
top/bottom |
| 19:59.19 |
pacman87 |
and you can
get the radar to fill the second screen |
| 19:59.21 |
brlcad |
madant: code
up something better |
| 19:59.29 |
pacman87 |
set opacity
to full |
| 19:59.35 |
pacman87 |
and size to
max |
| 19:59.48 |
madant |
pacman87, :)
seems like u ar sitting at a battlestation ;) |
| 20:00.06 |
pacman87 |
you may need
to set the radar size in your conf file |
| 20:00.19 |
madant |
yeah i need
to do some tinkering :) |
| 20:00.32 |
madant |
brlcad: :)
hopefully when i get addicted to the game :D |
| 20:00.44 |
pacman87 |
if you want
to play, let me know |
| 20:01.02 |
madant |
pacman87,
sure :) brlcad plays a lot too ? |
| 20:01.16 |
pacman87 |
not that i
know of |
| 20:02.18 |
poolio |
brlcad: do
none of your supervisors read the commit messages? :P |
| 20:03.09 |
pacman87 |
madant:
my.inexplicably.org:5156 |
| 20:03.10 |
starseeker |
brlcad:
dunno what that means and maybe I'm better off that way
;-) |
| 20:08.17 |
CIA-40 |
BRL-CAD:
03starseeker * r34148
10/brlcad/trunk/doc/docbook/BRL-CAD_db_format.xml: Add content for
spec up to tables in Padding and Length Rounding - need to check
those more carefully before redoing. |
| 20:14.00 |
brlcad |
madant: used
to play a lot (one of the best, actually), but not in a long
time |
| 20:14.46 |
brlcad |
poolio: it's
an open source project, meritocracy rules the code, devs do as devs
do |
| 20:15.49 |
madant |
:) i got
quicked out for jitter |
| 20:15.54 |
madant |
just
now |
| 20:16.11 |
brlcad |
shakes head at starseeker .. next you'll be telling me that
you don't know what "badger, badger, badger" means
too |
| 20:16.33 |
starseeker |
eh? |
| 20:16.39 |
brlcad |
slaps forehead |
| 20:16.55 |
madant |
pacman87,
unable to connect :) |
| 20:17.15 |
pacman87 |
madant: in
bzflag? |
| 20:17.34 |
starseeker |
has the distinct sensation of being back in high school
listening without comprehension to the slang of his peers
;-) |
| 20:17.36 |
brlcad |
you have some
google homework, your lady will probably find it funny
:) |
| 20:17.40 |
madant |
i mean i
connected to bzf.bzflag.. |
| 20:18.00 |
pacman87 |
sorry, it's
port 5161 |
| 20:18.08 |
madant |
ah ok
:) |
| 20:18.56 |
starseeker |
I dunno...
her sense of humor is not to be trifled with |
| 20:20.43 |
Malyce |
BRL, I can't
seem to be able to post on the 'brlcad-devel@lists.sourceforge.net'
list |
| 20:20.48 |
Malyce |
although I
subscribed |
| 20:21.48 |
Malyce |
ah no, I
see |
| 20:21.50 |
Malyce |
its
ok |
| 20:25.08 |
starseeker |
Hmm - BNF
description of VRML 2.0 - cool http://graphcomp.com/info/specs/sgi/vrml/spec/part1/grammar.html |
| 20:26.02 |
starseeker |
idly contemplates the creation of a BNF definition for .g
files, wonders if the spec has enough info to make
one... |
| 20:33.18 |
brlcad |
starseeker:
sure does, but wouldn't likely be efficient in the
least |
| 20:33.27 |
brlcad |
have thought
about it before too, though |
| 20:33.32 |
brlcad |
would be neat
in itself |
| 20:33.48 |
brlcad |
just not too
incredibly practical for binary files |
| 20:35.02 |
madant |
pacman87, :)
i guess my brain has to get used to watching 3d rendered motion :D
( last game i played was probably 5 years ago :P) |
| 20:35.12 |
pacman87 |
ah |
| 20:35.17 |
starseeker |
formality
might be useful as a framework though |
| 20:35.18 |
pacman87 |
it's a good
start |
| 20:35.25 |
pacman87 |
there's hope
for you yet :P |
| 20:35.40 |
madant |
:P |
| 20:35.48 |
pacman87 |
madant: you
could always just make your radar really big |
| 20:35.53 |
pacman87 |
and ignore
the rest of the screen |
| 20:35.59 |
pacman87 |
then it's
back to 2d motion |
| 20:37.55 |
starseeker |
distcheck
good on the mac |
| 20:39.04 |
madant |
pacman87,
yeah.. i feel like that is the best approach for me :d |
| 20:39.58 |
pacman87 |
try some of
the big/popular maps at the top of the list |
| 20:40.03 |
pacman87 |
and don't get
discouraged |
| 20:44.12 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 20:44.13 |
brlcad |
starseeker:
cool, thanks |
| 20:44.29 |
Malyce |
hey BRL, I am
having a problem compiling on Cygwin |
| 20:44.36 |
Malyce |
I ran the
configure script |
| 20:44.49 |
Malyce |
And the first
time, it told me that X11 wasn't installed |
| 20:45.22 |
Malyce |
Installed
X11, reran script. It now says X11 is enabled, but Xi library was
not found |
| 20:45.58 |
Malyce |
I followed
the guide at: http://gears.aset.psu.edu/hpc/guides/cygwin/ |
| 20:46.50 |
Malyce |
Couldn't do
the last step, since for some reason Cygwin setup didn't install
the startxwin.bat file |
| 20:47.05 |
Malyce |
Workarounds
? |
| 20:47.10 |
brlcad |
install it by
hand? |
| 20:47.28 |
Malyce |
The Xi
library ? |
| 20:47.34 |
brlcad |
you can
disable all X11 stuff if you don't mind not having a
gui |
| 20:47.52 |
Malyce |
yes |
| 20:47.55 |
Malyce |
that would be
great |
| 20:47.59 |
Malyce |
how
? |
| 20:48.06 |
brlcad |
--without-x11 |
| 20:53.23 |
Malyce |
./configuration --witout-x11 ? |
| 20:53.25 |
Malyce |
without |
| 20:54.10 |
pacman87 |
./configure
--without-x11 |
| 20:57.16 |
pacman87 |
and you'll
probably have to run 'mged -c' |
| 20:58.53 |
Malyce |
no, won't be
running mged |
| 21:01.11 |
*** join/#brlcad dreeves
(n=IceChat7@67.130.253.14) |
| 21:01.13 |
starseeker |
brlcad: OK,
Good on 64 bit linux too |
| 21:05.13 |
Malyce |
"Warning:
Neither YACC parser nor LEX scanner was found." Will this affect
Core C++ Interfaces or librt stuff ? |
| 21:06.28 |
Malyce |
Also
"Floating point implementation is not IEEE754 compliant. htond and
htonf may be incorrect" |
| 21:06.53 |
brlcad |
Malyce:
no |
| 21:10.04 |
CIA-40 |
BRL-CAD:
03brlcad * r34149 10/brlcad/trunk/BUGS: keep with a lot of objects
in mged isn't working right. just prints out a usage statement. I
haz test case. reported by lee and verified. |
| 21:13.13 |
CIA-40 |
BRL-CAD:
03brlcad * r34150 10/brlcad/trunk/BUGS: |
| 21:13.13 |
CIA-40 |
BRL-CAD:
verified another bug in the facetize -n commmand with lee where it
is giving |
| 21:13.13 |
CIA-40 |
BRL-CAD:
spurious 'color index out of range' errors on (at least) some
3-manifold |
| 21:13.13 |
CIA-40 |
BRL-CAD:
surfaces. the painting algorithm in nmg_manif.c seems
incomplete/flawed. |
| 21:14.44 |
CIA-40 |
BRL-CAD:
03brlcad * r34151 10/brlcad/trunk/ChangeLog: last thing, update
Changelog with items since 2009-03-06, ready to tag. |
| 21:19.52 |
Malyce |
Warning:
Can't figure out how to do Dynamic loading or shared libraries on
this system |
| 21:19.54 |
Malyce |
Bad
? |
| 21:27.22 |
brlcad |
pretty bad,
but not fatal -- did you run autogen.sh ? |
| 21:29.37 |
Malyce |
before
./configure ? |
| 21:29.39 |
brlcad |
yes |
| 21:29.41 |
Malyce |
I think I
tried |
| 21:29.45 |
brlcad |
heh |
| 21:29.51 |
Malyce |
didn't work
for some reason |
| 21:30.09 |
Malyce |
I am
'make'ing right now |
| 21:30.09 |
brlcad |
given you're
on a relatively obscure configuration, that's probably why you're
getting that message |
| 21:30.23 |
brlcad |
you need a
set of the gnu autotools that has been made for cygwin |
| 21:30.36 |
Malyce |
should I
stop, and restart ? |
| 21:30.48 |
brlcad |
plus, you
should be working from svn, not a source tarball ;) |
| 21:30.51 |
brlcad |
I
would |
| 21:31.01 |
brlcad |
you can keep
struggling if you like |
| 21:31.11 |
brlcad |
see if you
get enough built to test a patch |
| 21:31.22 |
Malyce |
right, so
first I should get the autotools |
| 21:31.28 |
Malyce |
second,
checkout svn |
| 21:31.31 |
Malyce |
and then
retry |
| 21:31.33 |
Malyce |
? |
| 21:32.24 |
brlcad |
yeah,
ideally |
| 21:35.08 |
Malyce |
Autoconf,
Automake and libtools, all three ? |
| 21:35.50 |
brlcad |
yes |
| 21:36.08 |
brlcad |
and they in
turn will want m4 and perl, maybe other minor deps |
| 21:44.19 |
Malyce |
no pain, no
gain |
| 21:46.24 |
CIA-40 |
BRL-CAD:
03brlcad * r34152 10/brlcad/branches/STABLE/ (2511 files in 220
dirs): merge trunk to STABLE from r33968 through HEAD r34151 for
release 7.14.6 |
| 22:00.32 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 22:14.20 |
CIA-40 |
BRL-CAD:
03brlcad * r34153 10/brlcad/tags/rel-7-14-6/: |
| 22:14.20 |
CIA-40 |
BRL-CAD: tag
release 7.14.6 |
| 22:14.20 |
CIA-40 |
BRL-CAD:
tested: source build, binary mac 32-bit intel, binary linux 32-bit
intel, binary linux 64-bit amd, binary linux 64-bit
ia64/altix |
| 22:24.52 |
poolio |
brlcad: sweet
:) |
| 22:25.27 |
madant |
yay
:) |
| 22:25.39 |
madant |
is off to sleep after a very weird day and
night |
| 22:36.46 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 22:39.20 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 22:54.09 |
CIA-40 |
BRL-CAD:
03brlcad * r34154 10/brlcad/trunk/ (NEWS README
include/conf/PATCH): update post tagging to dev version 7.14.7
(haha). this may still end up being a 7.16 release.. |
| 22:55.41 |
brlcad |
thinks this has been an exhausting day |
| 22:56.13 |
brlcad |
some of you
that didn't include nearly enough detail are going to have to make
edits up on the wiki.. :P |
| 22:56.24 |
brlcad |
didn't post
early enough to get a good review |
| 22:56.47 |
brlcad |
stupid that
the app prevents edits, but we'll deal |
| 22:57.30 |
madant |
we shall
overcome :D |
| 23:08.14 |
brlcad |
so it looks
like we get a preliminary slot count on the 7th |
| 23:09.25 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're
reviewing applications, preliminary slot count on 7th, selections
announced on the 15th |
| 23:09.54 |
madant |
11
action-packed days |
| 23:11.59 |
madant |
is sleep-deprived and high on orange juice |
| 23:13.23 |
madant |
brlcad: what
is the maximum possible number of slots ? the total number of
registered mentors ? |
| 23:31.14 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 00:50.49 |
CIA-40 |
BRL-CAD:
03Pacman87 07http://brlcad.org *
r1355 10/wiki/User:Pacman87: Updated to include 2009 GSoC proposal
for discussion |
| 01:03.37 |
madant |
still envies pacman87 last year renderings
;) |
| 01:03.59 |
madant |
still evnies pacman87's last year renderings
;) |
| 01:25.26 |
bjorkintosh |
twice! |
| 01:34.58 |
madant |
produces a lot of IRC Vomit for a 1 channel irc
person |
| 02:45.05 |
yukonbob |
evening,
cadheads |
| 02:53.00 |
typ0 |
my mged isn't
launching |
| 02:53.22 |
typ0 |
crashes with
bus error on this line: |
| 02:53.26 |
typ0 |
DisplayWidth(pubvars->dpy, |
| 02:53.27 |
typ0 |
<PROTECTED> |
| 02:53.59 |
typ0 |
in
X_open_dm() of libdm/dm-X.c |
| 02:54.37 |
typ0 |
pubvars->dpy value is
25268232 |
| 02:55.05 |
typ0 |
DefaultScreen
returns 1 |
| 02:57.35 |
yukonbob |
typ0:
details? Platform, BRL-CAD version... |
| 02:57.54 |
typ0 |
Mac OS X
10.5.6 , brl-cad svn trunk |
| 02:58.00 |
typ0 |
PPC |
| 02:59.10 |
typ0 |
brl-cad has
version number 7.14.5 |
| 02:59.45 |
yukonbob |
thinks .6 was just published today... |
| 02:59.58 |
typ0 |
yeah i
already ran svn update |
| 03:00.06 |
yukonbob |
(not that I'd
expact it to fix this issue...) |
| 03:00.46 |
yukonbob |
typ0: I'm
-not- a Mac guy -- have to wait for somebody else to chime in
:P |
| 03:01.09 |
typ0 |
;) |
| 03:08.44 |
*** join/#brlcad Ralith|trip
(i=40f692fb@gateway/web/ajax/mibbit.com/x-1159573b4dec5e26) |
| 03:10.36 |
typ0 |
DisplayWidth
should return my LCD screen width ? |
| 03:24.29 |
Ralith|trip |
checks in some more |
| 03:29.14 |
typ0 |
well all the
X related functions are crashing for me in this file |
| 03:29.19 |
typ0 |
for some
strange reason |
| 03:37.16 |
yukonbob |
typ0: you
running X, or stricly Aqua? |
| 03:37.21 |
yukonbob |
*strictly |
| 03:37.59 |
typ0 |
X11, latest
code from Apple |
| 03:38.03 |
typ0 |
from here:
http://xquartz.macosforge.org/ |
| 03:44.31 |
yukonbob |
prepares to fly out... |
| 03:44.41 |
yukonbob |
hope your
problem is solved soon, typ0 |
| 03:46.09 |
typ0 |
cheer |
| 03:46.09 |
typ0 |
s |
| 03:46.19 |
typ0 |
going to
slee |
| 03:46.20 |
typ0 |
p |
| 03:47.52 |
*** join/#brlcad pacman87
(i=500@resnet-46-102.dorm.utexas.edu) |
| 03:52.08 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 03:57.33 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 06:26.00 |
*** join/#brlcad madant
(n=madant@117.196.149.45) |
| 06:30.43 |
hippieindamakin8 |
good morning
Ralith madant |
| 10:17.18 |
*** join/#brlcad elite01
(n=omg@cl-213.dus-01.de.sixxs.net) |
| 10:32.26 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 10:43.17 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 12:00.36 |
*** join/#brlcad madant
(n=madant@117.196.133.211) |
| 12:10.58 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 12:38.23 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 12:40.04 |
``Erik |
*yawn* |
| 12:48.29 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 13:00.15 |
brlcad |
no
kidding |
| 13:05.27 |
``Erik |
my yawn was
just waking up, not "been awake for 8 years now" : |
| 13:05.28 |
``Erik |
:D |
| 13:47.15 |
Malyce |
Urm, I
selected autoconf, automake and libtools in the installer package
for Cygwin. Is this sufficient |
| 13:47.16 |
Malyce |
? |
| 13:50.54 |
``Erik |
should be,
um |
| 13:51.06 |
``Erik |
automake
should list autoconf as a dependancy |
| 13:51.19 |
``Erik |
you might
need some X compatability shtuff |
| 13:52.02 |
``Erik |
the package
has an "autogen.sh" script that will attempt to look for stuff and
run the right programs to generate configure for you |
| 13:52.30 |
``Erik |
if you're on
windows and you have msvc, there are msvc build packages I think in
misc/ |
| 13:52.39 |
Malyce |
I will be
using --without-x-11 |
| 13:52.50 |
Malyce |
x-11 is a
pain in the *** |
| 13:52.54 |
``Erik |
that'd be
--without-x11 |
| 13:53.00 |
``Erik |
there's no
dash there :) |
| 13:53.06 |
Malyce |
k |
| 13:53.31 |
Malyce |
I was worried
about the M4 and perl dependencies that Autoconf and automake
have |
| 13:53.41 |
``Erik |
we're a unix
shop (not linux, unix), so disabling X might be busted |
| 13:53.56 |
Malyce |
I did see
some perl packages in the install and selected them |
| 13:54.06 |
Malyce |
I pray
not |
| 13:54.29 |
``Erik |
*shrug* give
it a go, if ya see problems you don't understand, throw 'em out in
channel, someone will tell a something, eventually :) |
| 13:54.55 |
Malyce |
I couldn't
find M4 support in the install package |
| 13:55.05 |
Malyce |
I looked
under dev |
| 13:55.13 |
``Erik |
m4 is a core
thing, autoconf depends on it |
| 13:55.13 |
Malyce |
I hope it is
supported |
| 13:55.25 |
``Erik |
if you have
autoconf, you have m4 |
| 13:55.27 |
Malyce |
I hope the
installer is smart enough to realise that |
| 13:55.30 |
Malyce |
ok |
| 13:57.03 |
Malyce |
how do I do a
svn checkout from sourceforge ? |
| 13:57.19 |
Malyce |
I heard that
I shouldn't just download the GNU tarball |
| 13:57.22 |
``Erik |
um, you read
the instructions on the sourceforge page. |
| 14:00.23 |
``Erik |
got it
rolling? |
| 14:00.32 |
``Erik |
um, it's
/brlcad/brlcad/trunk iirc |
| 14:01.39 |
Malyce |
that's what I
wanted |
| 14:01.53 |
Malyce |
The help page
on SF didn't say anything |
| 14:01.54 |
Malyce |
thx |
| 14:02.12 |
``Erik |
np, a 'source
view' woulda given ya that |
| 14:03.04 |
``Erik |
I'm sure gory
details are on http://brlcad.org,
too :) |
| 14:04.10 |
Malyce |
http://brlcad.svn.sourceforge.net/brlcad/brlcad/trunk
iirc ? |
| 14:04.59 |
``Erik |
my repo has
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk |
| 14:05.35 |
``Erik |
that's an
accredited account, though, yours would be http: until you get a
commit bit |
| 14:05.54 |
Malyce |
you mean
become a SF member first ? |
| 14:06.20 |
``Erik |
you must have
an sf account to commit, and you must prove that you're
semi-competent before you get commit access |
| 14:06.21 |
``Erik |
:) |
| 14:06.39 |
``Erik |
we usually
request a simple patch via the sf tracker |
| 14:10.04 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:24.10 |
mafm |
hi
folks |
| 14:28.43 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:33.15 |
dreeves |
brlcad did
you ever get a chance to check out that patch...no big deal I was
just making sure there wasn't still something wrong with
it |
| 14:35.03 |
Malyce |
Isn't that
the only GSOC patch so far ? |
| 14:37.12 |
dreeves |
no I'm not
part of the GSOC |
| 14:40.15 |
brlcad |
~cadsvn |
| 14:40.15 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 14:40.43 |
Malyce |
Where are the
GSOC patches then ? |
| 14:41.03 |
Malyce |
I thought
they would be in the SF tracker |
| 14:41.06 |
brlcad |
dreeves: I
looked through it and was better -- just hadn't tested it
yet |
| 14:41.27 |
brlcad |
dreeves: and
nice follow up on the license/copyright check |
| 14:41.33 |
``Erik |
can the https
avenue be used by anonymous? |
| 14:41.50 |
brlcad |
I'd talked to
Elaine about that paper and the work, she didn't have the source
link though (and acm had since dropped it) |
| 14:42.02 |
brlcad |
``Erik:
yeah |
| 14:42.08 |
``Erik |
coo' |
| 14:42.18 |
brlcad |
it'll just
prompt for user/pass on first commit |
| 14:43.04 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:46.23 |
*** mode/#brlcad [-b %*!*IriX64@*] by
brlcad |
| 14:46.37 |
*** mode/#brlcad [-b %*!smallfoo*@*] by
brlcad |
| 14:46.53 |
*** mode/#brlcad [-b *!*gruni@rootgeek.org] by
brlcad |
| 14:46.55 |
``Erik |
wow, banned
even? |
| 14:47.07 |
brlcad |
no, quiets
are implemented in the banlist |
| 14:47.14 |
brlcad |
that's the
leading % |
| 14:47.21 |
``Erik |
oh, used to
efnet :) |
| 14:47.37 |
*** mode/#brlcad [-b *!smallfoo*@*] by
brlcad |
| 14:47.43 |
``Erik |
woulda thunkt
+m and +v's around |
| 14:47.49 |
brlcad |
there, I'll
get it right eventually :) |
| 14:48.20 |
brlcad |
too much
effort, have to voice everyone instead of the one that was causing
the problem |
| 14:48.26 |
``Erik |
*server
migration supersubliminal message* |
| 14:48.40 |
brlcad |
and he wasn't
trying to subvert it, did well |
| 14:49.09 |
``Erik |
he's a good
guy, I like him... works hard, just not a guru |
| 14:49.30 |
``Erik |
I want to
help him maximize his contribution |
| 14:49.52 |
``Erik |
so he can
have synergy with the, uh, cmmi, uh, buzzword,
something |
| 14:50.34 |
dreeves |
brlcad no
problem on the code making sure you weren't still waiting on me for
something...I have the source code for that paper if you want
it |
| 14:50.49 |
``Erik |
url? |
| 14:52.40 |
*** join/#brlcad Briggs
(n=chatzill@adsl-70-238-154-89.dsl.stlsmo.sbcglobal.net) |
| 14:53.13 |
Briggs |
does brl cad
have a central library for things like vectors, matrices,
triangle/ray intersections/ect or are routines for these things
spread across the source code? |
| 14:53.13 |
``Erik |
assigns it to brlcad :D |
| 14:53.16 |
``Erik |
*dodge* |
| 14:53.34 |
``Erik |
sorta,
include/vmath.h has an awful lot |
| 14:53.48 |
Briggs |
danke |
| 14:54.02 |
``Erik |
intersections
are handled by librt |
| 14:54.18 |
Briggs |
right. |
| 14:54.24 |
Briggs |
will scour the source. |
| 14:54.45 |
Briggs |
hrmm. anyone
have experience browsing brl cads source with cscope? does it deal
with it well? |
| 14:55.00 |
``Erik |
our geometry
has negatives, we don't solve intersection until the ray is
fired |
| 14:55.19 |
``Erik |
yeah, cscope
works well, takes a good chunk of time to generate the hash,
though |
| 14:55.31 |
Briggs |
I can always
go make a cup of coffee or something :) |
| 14:55.44 |
``Erik |
~2m on my
workstation |
| 14:55.54 |
Briggs |
ahh thats not
horrible |
| 14:56.15 |
``Erik |
dude, that's
120 seconds of starting at a blank screen |
| 14:56.16 |
``Erik |
:D |
| 14:56.47 |
Briggs |
it takes
about that long to make a good cup of coffee... |
| 14:56.49 |
Briggs |
:) |
| 14:56.54 |
Briggs |
or
tea |
| 14:57.02 |
``Erik |
depends on
your definition of good... |
| 14:57.10 |
Briggs |
this is
true |
| 14:57.24 |
``Erik |
I have the
press and all that, but I seem to be willing to mix some instants
to get my cup |
| 14:57.26 |
``Erik |
:( |
| 14:57.37 |
``Erik |
I have
friends that would stab me for that |
| 14:57.39 |
Briggs |
haha |
| 14:57.50 |
Briggs |
I was going
to get one of those one-cup thingies. |
| 14:58.08 |
Briggs |
but instant
is probably even less hassle. |
| 14:58.43 |
``Erik |
tell ya what,
though, I have a one cup water heater, I throw a teaspoon loaded
with 'mountain brew' and one general int 'french vanilla', it's a
decent cup |
| 15:06.42 |
``Erik |
brlcad: I
honestly don't think you should waste your time or mine moving
hunks of metal, if we can tap an m3 guy and like rich, that's be a
better utilization of assets, no? I don't grok why we can't trust
them with that |
| 15:07.53 |
``Erik |
we do remote
clean shutdown, they do the monkey work, hit the power buttons, we
verify they came up... mebbe stop by and see that the bolts are
good, it's donw |
| 15:10.52 |
``Erik |
fuck fuck
fuckity fuck *pats down teh hairs that are trying to go
pointy* |
| 15:23.54 |
mafm |
(obcenity
overflow) |
| 15:29.28 |
Briggs |
wonders why lists in python have no 'copy'
method. |
| 15:29.31 |
Briggs |
whoops, wrong
channel. |
| 15:30.54 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 15:32.12 |
*** join/#brlcad madant
(n=madant@117.196.141.240) |
| 15:36.07 |
mafm |
hi
madant |
| 15:41.57 |
``Erik |
Briggs: cuz
guido didn't say so? :D |
| 16:05.22 |
brlcad |
Briggs:
because it's built in? listA = list() ; listB =
list(listA) |
| 16:05.54 |
Briggs |
brlcad: this
is true |
| 16:06.24 |
Briggs |
brlcad: just
that python is usually consistent about these things so I was
suprised to find 'somelist.copy()' didnt work |
| 16:06.44 |
Briggs |
well I guess
a lot of basic builtin types dont have copy() method...
hrmmm |
| 16:06.51 |
Briggs |
nevermind,
was wrong channel anyway like I said :) |
| 16:08.34 |
*** part/#brlcad Briggs
(n=chatzill@adsl-70-238-154-89.dsl.stlsmo.sbcglobal.net) |
| 16:10.10 |
mafm |
brlcad: I've
been sidetracked yesterday, I haven't completed my application.
however, the biggest problem as you know is that I haven't had time
to prepare for gsoc, and the projects where I could be more
productive are quite vague |
| 16:10.48 |
mafm |
kind of, I
cannot think of any workable plan linking the new GUI and GS if I
don't know much about the details of GS, and the GUI is still to be
desined and built |
| 16:11.11 |
mafm |
designed*
even |
| 16:11.56 |
mafm |
and I think
that I can still edit the application, but I guess that this would
be cheating |
| 16:20.48 |
brlcad |
it's not
cheating if it lets you, don't think it allows you to edit more
than the abstract |
| 16:25.16 |
poolio |
well then
couldn't you just have a really really long abstract? |
| 16:41.54 |
madant |
there is a
word limit .. 500 ? |
| 16:46.33 |
poolio |
ah
well |
| 16:57.27 |
mafm |
500
characters |
| 16:57.42 |
mafm |
and I left
blank the content too |
| 17:00.25 |
mafm |
it's not
editable anyway |
| 17:19.47 |
*** join/#brlcad francois
(n=francois@cho94-4-82-234-190-36.fbx.proxad.net) |
| 18:04.29 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 18:57.27 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 19:15.17 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 19:20.28 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:32.56 |
Malyce |
sh
autogen.sh |
| 19:33.27 |
Malyce |
line 79:
$'\r': command not found |
| 19:34.35 |
Malyce |
line 97:
syntax error near unexpected token '$'{\r'' |
| 19:35.08 |
Malyce |
line 97:
'ident (){ |
| 19:35.48 |
Malyce |
is this a GBS
problem ? |
| 19:37.36 |
*** part/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:37.59 |
``Erik |
huh, are you
using windows or something? |
| 19:38.07 |
Malyce |
cygwin on
xp |
| 19:41.31 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:48.13 |
Malyce |
I did select
Autoconf, Automake and libtools in the setup package |
| 19:48.34 |
Malyce |
mebbe they
are not the latest versions ? |
| 19:48.59 |
``Erik |
I imagine
it's a line ending issue |
| 19:49.28 |
Malyce |
autoconf
2.63 |
| 19:49.39 |
Malyce |
automake
1.10 |
| 19:50.14 |
``Erik |
hrm, svn says
that file is 'native' line ending :/ |
| 19:50.16 |
Malyce |
libtools
2.2.7a |
| 19:50.27 |
Malyce |
what must I
do ? |
| 19:52.18 |
``Erik |
I don't know,
I'm guessing that your pull has some "not quite right" files :( I
don't know, I'm sorry :( |
| 19:53.05 |
Malyce |
rats |
| 19:53.26 |
Malyce |
all I want to
do, is compile a couple of files from core c++
interfaces |
| 19:53.43 |
Malyce |
any
workarounds ? |
| 19:54.06 |
``Erik |
windows is
not a core target, and cygwin is not the usual windows avenue for
us :( |
| 19:54.24 |
Malyce |
then, what is
? |
| 19:54.34 |
``Erik |
\r is C for a
line return, dos/windows kinda looks at \n as a \r\n |
| 19:54.48 |
``Erik |
mac, bsd,
linux, irix, solaris, uhm |
| 19:54.58 |
Malyce |
wouldn't mind
switching |
| 19:55.02 |
Malyce |
just not
right now |
| 19:55.11 |
``Erik |
winderz has
msvc8 and 9 proj files |
| 19:55.32 |
``Erik |
if you can
figure out how to make it work on cygwin, that'd be
awesome |
| 19:55.50 |
Malyce |
Maybe I will.
Just, not today |
| 19:55.57 |
Malyce |
will msvc
express do ? |
| 19:56.19 |
``Erik |
<--
doesn't know |
| 19:56.34 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 19:56.36 |
Malyce |
perhaps I
should wait till BRL shows up |
| 19:57.22 |
Malyce |
oh, btw,
where do the GSOC patches go ? |
| 19:57.29 |
Malyce |
not the SF
tracker ? |
| 20:00.11 |
``Erik |
sf tracker is
good, mention your irc handle in the info or something |
| 20:00.26 |
*** join/#brlcad andax
(n=andax__@d213-102-40-21.cust.tele2.ch) |
| 20:00.52 |
``Erik |
either brlcad
or I will review it and annotate internal info |
| 20:01.21 |
``Erik |
and either
apply it, or hand out a commit bit and let you apply it |
| 20:01.24 |
``Erik |
*shrug* |
| 20:01.42 |
Malyce |
was just
curious |
| 20:01.51 |
Malyce |
all the
patches there seem to be somewhat old |
| 20:02.04 |
``Erik |
yes, we knock
the easy ones out fast |
| 20:02.13 |
Malyce |
with GSOC
happening, I woulda thought it would be filled with GSOC
patches |
| 20:02.34 |
Malyce |
or mebbe
everyone is working late like me |
| 20:02.36 |
``Erik |
some patches
are many years old, most gsoc patches don't sit more than 24
hours |
| 20:02.46 |
Malyce |
ahhh |
| 20:03.07 |
Malyce |
is that
because they don't do anything useful ? |
| 20:03.15 |
Malyce |
just
demonstrate coding capability ? |
| 20:04.17 |
Malyce |
or because
they are no good ? |
| 20:04.32 |
``Erik |
more a factor
of the time a commiter has to apply |
| 20:04.58 |
Malyce |
? |
| 20:05.13 |
``Erik |
if I can look
at a patch, vouch for it and apply it in 15 minutes, it's in... if
it takes a week to understand, well, I might not have a week to
spend doing that |
| 20:05.46 |
``Erik |
if it's an
important patch, I'll spend more time than if it's not
*shrug* |
| 20:05.54 |
Malyce |
so, a patch I
make should be very readable, or its out ? |
| 20:06.19 |
``Erik |
your patch
should be correct, the result code should be readable |
| 20:06.42 |
``Erik |
and it's all
shades of grey, a patch readability alone is not in/out stuff
:) |
| 20:07.04 |
``Erik |
get to
codin'! |
| 20:07.10 |
Malyce |
I have
been |
| 20:07.18 |
Malyce |
In the time
it takes to compile this thing |
| 20:07.32 |
Malyce |
How many GSOC
patches have been submitted so far ? |
| 20:07.53 |
``Erik |
I don't know,
and if I did, I don't know if I should tell you :) |
| 20:08.04 |
Malyce |
I
see |
| 20:08.08 |
Malyce |
why not
? |
| 20:08.29 |
``Erik |
for
which? |
| 20:08.41 |
Malyce |
why if you
knew, you wouldnt tell |
| 20:09.01 |
``Erik |
the latter, I
don't want to foster a competitive environment, I don't think gsoc
is about winners and losers |
| 20:09.16 |
Malyce |
its not
? |
| 20:09.20 |
Malyce |
hahaha |
| 20:09.54 |
Malyce |
A 5000 dollar
internship *is* about winners and losers |
| 20:10.05 |
Malyce |
right now, I
am struggling not to be the latter |
| 20:10.14 |
Malyce |
sorry, 4500
dollars |
| 20:10.16 |
``Erik |
well, they're
flexible, their goal is to see good things done, and yeah, $5k is a
nice little bump, but that's not the point of it, that's just a
carrot |
| 20:10.29 |
Malyce |
pretty juicy
carrot |
| 20:10.44 |
``Erik |
5k, 4.5 to
the student, .5 to the mentor (but we waive the mentor
$'s) |
| 20:11.26 |
Malyce |
does the .5
then go to BRL-CAD as an org ? |
| 20:11.31 |
Malyce |
or is it just
gone ? |
| 20:11.42 |
``Erik |
do up your
patch, do your application or two, we discuss the merits of the
projects and people |
| 20:11.54 |
``Erik |
we waive it,
we don't accept it at all. google keeps it |
| 20:12.16 |
Malyce |
why ? its not
like google needs more $ |
| 20:12.27 |
``Erik |
$500 is not
worth the liability of for pay activities combining with gov't
work |
| 20:12.51 |
Malyce |
I see. There
are too many strings attached ? |
| 20:13.03 |
``Erik |
*shrug* it's
a risk |
| 20:13.35 |
``Erik |
my salary is
tax dollars, so getting paid by google is ... double-charging
effectively |
| 20:14.03 |
Malyce |
what is your
line of work ? |
| 20:15.00 |
``Erik |
computer
scientist, us army research lab, survibility/lethality analyses
directorate, software development branch, advanced computer systems
tema |
| 20:15.38 |
Malyce |
You are one
of the original BRL-CAD ppl ? |
| 20:15.44 |
Malyce |
*GASPS* |
| 20:15.48 |
``Erik |
I've been
accused of being a real computer scientist, not a sofwtare
engineer |
| 20:15.52 |
``Erik |
not original,
but on the team |
| 20:16.07 |
Malyce |
I
see |
| 20:16.15 |
Malyce |
Yes, they are
very different things |
| 20:16.28 |
Malyce |
I am more of
the opposite |
| 20:16.42 |
Malyce |
although I am
supposed to be a CS, I am becoming a CE |
| 20:17.14 |
``Erik |
yeh, pointy
hairs like sloc, not idea pontification |
| 20:17.16 |
mafm |
Malyce:
re:gsoc patches: you can see that in the patch manager of
sourceforge, with a bit of guessing |
| 20:17.33 |
Malyce |
is brlcad
also one of the founding ppl ? |
| 20:17.45 |
Malyce |
mafm: Yes, I
did that yesterday |
| 20:17.55 |
Malyce |
I am a
curious crow |
| 20:17.57 |
``Erik |
10 days of
grunt coding seems more impressive to them than lava lamp
meditation for 5 days and 2 days coding |
| 20:18.21 |
Malyce |
CS is
*hard* |
| 20:18.34 |
``Erik |
brlcad is the
dude kinda being our point guard, but he was shitting hsi diapers
when BRL-CAD started |
| 20:18.36 |
Malyce |
as hard as
abstract math |
| 20:18.46 |
Malyce |
i
see |
| 20:19.01 |
Malyce |
are there
other founding members still here ? |
| 20:19.09 |
``Erik |
no |
| 20:19.20 |
Malyce |
hey, are you
there in one of the pix on the site ? |
| 20:19.23 |
``Erik |
the core guy
until 2000 died in a car accident |
| 20:19.35 |
Malyce |
ow |
| 20:19.43 |
``Erik |
other
importnat people have retired or moved on to other
projects |
| 20:20.12 |
``Erik |
pix on the
site? |
| 20:21.14 |
``Erik |
if you look
at ohloh, it makes things pretty obvious :) |
| 20:21.17 |
Malyce |
#!/bin/sh |
| 20:21.17 |
Malyce |
#
a u t o g e n . s h |
| 20:21.17 |
Malyce |
# |
| 20:21.17 |
Malyce |
# Copyright
(c) 2005-2009 United States Government as represented
by |
| 20:21.17 |
Malyce |
# the U.S.
Army Research Laboratory. |
| 20:21.22 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 20:21.34 |
``Erik |
dude,
http://pastebin.bzflag.bz |
| 20:22.23 |
Malyce |
oh
hell |
| 20:22.25 |
Malyce |
sorry |
| 20:22.28 |
Malyce |
http://brlcad.org/gallery/d/230-2/Mike+Muss.jpg |
| 20:22.32 |
Malyce |
that's what I
meant |
| 20:22.34 |
``Erik |
I came tot he
lab in '03 and one of my first tasks was to rewrite teh build
system from cake into automake, so those am files are all fairly
new |
| 20:22.51 |
Malyce |
so, that
can't be you there |
| 20:23.07 |
``Erik |
hm, no,
that's mike in the chair, uh, owen something standing with the
beard |
| 20:23.21 |
``Erik |
though one of
those pdp top-plates might be on my book case |
| 20:23.36 |
mafm |
Malyce: the
point is that patches are public and are to be submitted there, so
no need to ask :) |
| 20:24.06 |
Malyce |
mafm: but
there are no recent ones, except one by drreeves |
| 20:24.25 |
Malyce |
mafm: it
can't be that noone has submitted a patch yet |
| 20:24.35 |
``Erik |
that's where
the patches go |
| 20:24.51 |
Malyce |
Erik: I
remember looking at the pic last year or the year
before |
| 20:25.03 |
Malyce |
and thinking,
there was a time when ppl wore that to work ? |
| 20:25.16 |
Malyce |
'the
suit' |
| 20:25.16 |
``Erik |
was the 70's,
man :D |
| 20:25.17 |
mafm |
Malyce:
that'd be the case :) |
| 20:25.39 |
Malyce |
*GASPS
AGAIN* |
| 20:25.45 |
Malyce |
that can't be
right |
| 20:26.03 |
``Erik |
make a patch,
submit it! |
| 20:26.07 |
Malyce |
on
it |
| 20:26.08 |
``Erik |
shut up and
code! |
| 20:26.09 |
``Erik |
:D |
| 20:26.20 |
Malyce |
but its no
good if I can't even compile my code, now is it ? |
| 20:26.28 |
Malyce |
which is why
I wait |
| 20:26.28 |
mafm |
the deadline
for patches is in 1 week or so, not sure -- but the sooner the
better |
| 20:26.47 |
Malyce |
my problem is
that I am still struggling to compile the svn checkout |
| 20:26.59 |
Malyce |
not much I
can do till I get that done |
| 20:27.06 |
``Erik |
we won't
straight up say no, if you put down a patch that ain't right, we'll
tell you and see about making it right |
| 20:27.34 |
Malyce |
I would be
ashamed to submit something I did not feel I tried 100% to make
right |
| 20:27.40 |
``Erik |
but we'll get
to some point where we sit down and try to order applicants, we
have to come up with a real order and start saying "sorry, you
didn't make it" |
| 20:27.49 |
``Erik |
so it's a lot
better to submit early |
| 20:28.11 |
Malyce |
Then I will
submit a not-yet compiled patch now |
| 20:28.16 |
Malyce |
and fix it as
soon as I can |
| 20:28.32 |
``Erik |
rather you
got it working, first, but *shrug* |
| 20:29.10 |
``Erik |
if a patch is
JUST to make it work on a certain platform, that's a good
thing |
| 20:29.35 |
``Erik |
if a patch is
"I did stuff, btu nothing works", well.. what are we supposed to
think about that? :D |
| 20:29.38 |
``Erik |
know what I
mean? |
| 20:30.28 |
mafm |
1. Patch
doesn't compile |
| 20:30.30 |
mafm |
2.
??? |
| 20:30.36 |
mafm |
3. No
profit |
| 20:30.37 |
Malyce |
so I wait
then, till brlcad shows up and gives me a hint on how to compile
the checkout |
| 20:30.48 |
mafm |
:) |
| 20:30.52 |
``Erik |
I don't know
if he can give you a hint |
| 20:30.55 |
Malyce |
in the
meantime, I am coding, just can't compile anything |
| 20:31.04 |
Malyce |
any
suggestions then ? |
| 20:31.05 |
``Erik |
you're not in
our turf, dude, :( |
| 20:31.19 |
``Erik |
I'd imagine
it's a line ending related issue |
| 20:31.24 |
``Erik |
but that's an
educated guess |
| 20:31.35 |
Malyce |
yes, I plan
to burn my current machine and get one with linux |
| 20:31.48 |
Malyce |
just as soon
as I get this code to compile |
| 20:31.50 |
``Erik |
I mean,
windows? really? I have one windows machine, it's at work and I
don't touch it |
| 20:31.57 |
Malyce |
sorry |
| 20:32.08 |
``Erik |
if you can
figure out how to make it work on cygwin, that'd be
awesome |
| 20:32.18 |
``Erik |
but it's not
like we left it broken on purpose |
| 20:32.24 |
Malyce |
My older
machine would have been able to get linux running up and
fast |
| 20:32.28 |
Malyce |
but its
kaputs |
| 20:32.35 |
``Erik |
if we knew
the answer, it'd be fixed in teh repo :) |
| 20:32.42 |
Malyce |
and the new
one is a lightweight with SSD HD |
| 20:32.54 |
Malyce |
installing
Cygwin typically takes 2 hours |
| 20:33.05 |
Malyce |
installing an
OS would be a nightmare |
| 20:33.17 |
Malyce |
so, I am
playing it safe for just now |
| 20:33.25 |
mafm |
:D |
| 20:33.36 |
mafm |
installing
current linuz distros takes less than 2h for sure |
| 20:33.40 |
Malyce |
sorry, I am a
poor student |
| 20:33.46 |
Malyce |
on a standard
HD, yes |
| 20:33.53 |
Malyce |
not on flash
memory |
| 20:34.39 |
mafm |
not really
:) |
| 20:35.00 |
Malyce |
I tried
running VNC server on one of my lab machines |
| 20:35.05 |
Malyce |
they are all
Solaris |
| 20:35.08 |
mafm |
now, I'm not
telling you to install it, and it's a bit difficult if you haven't
done it before, but for sure it doesn't take that much
time |
| 20:35.12 |
Malyce |
but I don't
have rights on them |
| 20:35.16 |
``Erik |
well, tell ya
what, we don't care what os you run. btu this ain't a class, we're
not inventing work for people, so no one has all the answer for
ya |
| 20:35.26 |
Malyce |
I
understand |
| 20:35.36 |
``Erik |
if you push
and fix a platform we don't currently support, that's totally
awesome |
| 20:35.37 |
Malyce |
I don't wanna
look like a whine baby |
| 20:35.40 |
``Erik |
but we don't
invent work |
| 20:35.45 |
Malyce |
of
cours |
| 20:35.56 |
andax |
mafm: as long
as you do not compile your distribution from source, it takes less
than 2 hours, yes |
| 20:36.20 |
Malyce |
is there any
way, I can only compile a portion of the code ? |
| 20:36.23 |
Malyce |
there should
be |
| 20:36.36 |
mafm |
andax: yes
well, I was not talking about gentoo :D |
| 20:36.37 |
``Erik |
had a rhel cd that went from naked system to enterprise
production system in about 15 minutes O.o many years
ago |
| 20:36.39 |
Malyce |
no linking,
only compiling |
| 20:36.54 |
``Erik |
um, if your'e
on the automake system, I made a "depends" rule for
make |
| 20:37.32 |
mafm |
Malyce:
haven't you got linuz accounts in the lab? |
| 20:37.40 |
Malyce |
I guess its
hands-on gcc/g++ compiling |
| 20:37.41 |
Malyce |
yes |
| 20:37.44 |
Malyce |
but no
rights |
| 20:37.51 |
Malyce |
:D |
| 20:38.01 |
``Erik |
it's in
misc/Makefile.defs I think, you can do, like, cd src/rt &&
make depends and it'll "do the right thing" |
| 20:38.07 |
``Erik |
no install
dealie, tho |
| 20:38.15 |
Malyce |
that's
fine |
| 20:38.24 |
``Erik |
that'd be a
great pre-acceptance patch |
| 20:38.40 |
Malyce |
sarcasm
? |
| 20:39.04 |
``Erik |
no,
seriously, if you make something like "install-recursive", that'd
be awesome |
| 20:39.27 |
Malyce |
you mean if I
can make the thing install on cygwin ? |
| 20:39.45 |
``Erik |
or grab a
linux box or whatever |
| 20:40.09 |
``Erik |
any other
student looking for a patch idea, whatever :) |
| 20:40.09 |
brlcad |
Malyce: you
need help on compiling? |
| 20:40.12 |
Malyce |
Yes, I will
hunt for one. Should be able to borrow one |
| 20:40.14 |
brlcad |
that's not a
good sign.. :) |
| 20:40.16 |
Malyce |
uh
huh |
| 20:40.24 |
Malyce |
its on
cygwin |
| 20:40.30 |
Malyce |
i followed
the steps |
| 20:40.38 |
Malyce |
but
autogen.sh died on me |
| 20:40.47 |
brlcad |
is cygwin
your only platform? |
| 20:40.52 |
Malyce |
for
now |
| 20:40.54 |
``Erik |
\r issue on
cyggy |
| 20:40.59 |
``Erik |
autogen.sh
craps out |
| 20:40.59 |
``Erik |
just back
from crew? :) |
| 20:41.12 |
brlcad |
no, just been
wandering around the house doing things |
| 20:41.30 |
brlcad |
watched
heroes, had lunch, took some pics, worked on the house |
| 20:41.38 |
brlcad |
got through
e-mail |
| 20:41.40 |
``Erik |
didja read
backlog? I'm hoping I didn't say incorrect stuff |
| 20:41.48 |
brlcad |
not
really |
| 20:41.49 |
brlcad |
at least not
yet |
| 20:41.56 |
andax |
the fastest
of my installation of a open source operating system was
DOSminix2.0. It is DOS-dependent, therefore not a entire operating
system but runs very nicely out of a Windows-Box |
| 20:41.59 |
Malyce |
ok. I guess I
will try stealing someone's machine then |
| 20:42.19 |
brlcad |
Malyce: you
should be able to get it to work |
| 20:42.27 |
brlcad |
I've done a
full build on cygwin several times |
| 20:42.34 |
Malyce |
that's great
news |
| 20:42.39 |
Malyce |
do
advise |
| 20:42.46 |
``Erik |
malyce: we
want cyggy and windows people, we just don't do it ourselves
much |
| 20:43.07 |
brlcad |
if you have
\r's in your files, then you maybe got the files in a bad
way |
| 20:43.14 |
brlcad |
where are
those sources from? |
| 20:43.14 |
Malyce |
I remember
selecting Autoconf, Automake and libtools during
installation |
| 20:43.18 |
Malyce |
SF |
| 20:43.24 |
brlcad |
how? |
| 20:43.28 |
``Erik |
autogen.sh
has the 'native' eol style int he repo |
| 20:43.29 |
brlcad |
from svn
through cygwin? |
| 20:44.02 |
brlcad |
and is it a
binary svn from tigris, or from somewhere else? |
| 20:44.20 |
Malyce |
http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk |
| 20:44.29 |
Malyce |
svn
checkout |
| 20:44.36 |
``Erik |
the
svn.ex |
| 20:44.39 |
brlcad |
if you
checked out with an svn built *in* cygwin, it should work just
fine |
| 20:44.41 |
Malyce |
through win
xp |
| 20:45.42 |
``Erik |
no, where did
you get the svn executable |
| 20:45.42 |
Malyce |
svn, exe
? |
| 20:45.42 |
brlcad |
yes..
where? |
| 20:45.42 |
Malyce |
I am using
tortoise on Win XP |
| 20:45.42 |
brlcad |
there's your
problem |
| 20:45.42 |
Malyce |
should I have
done that from inside Cygwin ? |
| 20:45.43 |
brlcad |
if you're
going to check out the sources outside cygwin, it makes "windows"
text files |
| 20:45.43 |
Malyce |
I
see |
| 20:45.45 |
``Erik |
with the
extra \r |
| 20:45.46 |
brlcad |
if you check
out within cygwin, it'll make "*nix" text files |
| 20:45.51 |
``Erik |
<- points
up where he siad that :D |
| 20:45.56 |
Malyce |
ha |
| 20:45.59 |
brlcad |
see, listen
to ``Erik |
| 20:45.59 |
Malyce |
cool |
| 20:46.09 |
brlcad |
and don't mix
your gui/cygwin tools :) |
| 20:46.19 |
brlcad |
if you do a
tortoise checkout, build it with studio |
| 20:46.24 |
Malyce |
now I need to
figure out how to get cygwin to connect ot the net |
| 20:46.26 |
Malyce |
allright |
| 20:46.27 |
brlcad |
why aren't
you building with studio? |
| 20:46.30 |
Malyce |
I
could |
| 20:47.08 |
``Erik |
now I
wouldn't have known that tortoise screws the pooch like that, but
*shrug* \r is the issue, windows vs unix |
| 20:47.20 |
Malyce |
msvc express
2008 will do ? |
| 20:47.22 |
brlcad |
yeah |
| 20:47.27 |
Malyce |
ok |
| 20:47.27 |
``Erik |
should |
| 20:47.36 |
brlcad |
you could
even fix the problem, because probably only autogen.sh is all that
needs fixed |
| 20:47.43 |
brlcad |
the source
files will be parsed okay by gcc |
| 20:47.56 |
brlcad |
could just
strip the carriages |
| 20:47.59 |
Malyce |
allright |
| 20:48.13 |
Malyce |
all 35 pages
of them ? |
| 20:48.19 |
brlcad |
huh? |
| 20:48.24 |
brlcad |
pages? |
| 20:48.27 |
``Erik |
I like the
notion of a clean build on cygwin |
| 20:48.38 |
Malyce |
when I paste
the text in an editor |
| 20:48.44 |
Malyce |
it came to 35
pages I think |
| 20:48.52 |
brlcad |
pretty
irrelevant number |
| 20:48.57 |
Malyce |
k |
| 20:49.19 |
brlcad |
it's a shell
script .. coulda made the whole thing one line |
| 20:50.04 |
brlcad |
fixes that muuss picture name |
| 20:50.27 |
``Erik |
what's the
other dudes name? this is bugging me, I knew it... |
| 20:50.43 |
brlcad |
was out of diapers by the time brl-cad started
:) |
| 20:51.07 |
``Erik |
not what your
wife siad *coug* *dck* *run* |
| 20:51.43 |
``Erik |
'79? |
| 20:51.46 |
brlcad |
Malyce: whom
all have you applied with? |
| 20:52.07 |
Malyce |
I had wanted
to also apply to ptolemy |
| 20:52.16 |
Malyce |
but I decided
to focus only on brl |
| 20:52.45 |
``Erik |
get a good
app in, if you have time, apply to ptolemy, too... :) |
| 20:52.54 |
brlcad |
Malyce: also,
several apply but don't read our application instructions either
and get major points knocked off them by not submitting a
patch |
| 20:53.08 |
Malyce |
isn't the
deadline over ? |
| 20:53.10 |
brlcad |
always good
to keep both going |
| 20:53.15 |
``Erik |
not
yt |
| 20:53.19 |
Malyce |
what
? |
| 20:53.25 |
Malyce |
I thought it
was done yesterday |
| 20:53.26 |
brlcad |
brl-cad's
going to be pretty competitive, less than 30% chances for any
individual |
| 20:53.45 |
brlcad |
the
submit-your-application deadline has passed |
| 20:53.47 |
yukonbob |
fight! |
| 20:53.55 |
``Erik |
I thought
there was a bit mroe time, I thought the final cutoff was like the
20th? |
| 20:54.08 |
pacman87 |
``Erik:
that's the final acceptance decision |
| 20:54.23 |
pacman87 |
applying
deadline was friday noon pst |
| 20:54.24 |
brlcad |
they can't
submit, but tweaks and responses can still be made |
| 20:54.44 |
brlcad |
which was a
shame.. should have given the students the weekend at
least |
| 20:54.51 |
``Erik |
ok, I know
les threw out a "damnit, apply!" last week |
| 20:54.56 |
brlcad |
the firm
deadline bullcrap is annoying too |
| 20:55.08 |
brlcad |
at least that
didn't affect us |
| 20:55.18 |
pacman87 |
gov test took
over my life until thursday night |
| 20:55.28 |
brlcad |
gov
test? |
| 20:55.36 |
brlcad |
someone make
you pee in a cup? |
| 20:55.40 |
pacman87 |
government |
| 20:55.47 |
brlcad |
heh |
| 20:55.48 |
pacman87 |
no, test on
my knowledge of gov |
| 20:55.49 |
pacman87 |
lol |
| 20:55.52 |
brlcad |
I know 'gov'
meant that |
| 20:55.58 |
brlcad |
but not what
*you* meant by that |
| 20:56.08 |
brlcad |
s/meant/mean/ |
| 20:56.16 |
pacman87 |
it's the only
class i actually have to take to graduate |
| 20:56.20 |
brlcad |
ahh |
| 20:56.22 |
pacman87 |
the other
ones are just for fun |
| 20:56.26 |
brlcad |
that sounds
absolutely.. |
| 20:56.27 |
brlcad |
horrible |
| 20:56.55 |
pacman87 |
ie, computer
architecture, concurrent/dist sys, microprocessors, and solid-state
electronics |
| 20:57.04 |
brlcad |
cool |
| 20:57.10 |
mafm |
pacman87:
couldn't apply? |
| 20:57.15 |
pacman87 |
no, i got it
in |
| 20:57.15 |
brlcad |
distributed
systems should be fun |
| 20:57.18 |
pacman87 |
but it was
rushed |
| 20:57.27 |
mafm |
brlcad: it's
a bit annoying specially because in past years they extended it too
much |
| 20:57.28 |
brlcad |
the rest,
meh, to much CE :) |
| 20:57.56 |
pacman87 |
i want to end
up in embedded systems or computer arch |
| 20:58.20 |
pacman87 |
i'm just
taking a long way through ME to get there |
| 20:58.52 |
brlcad |
decides to go to the grocery store just so he can get a
little vitamin D on this fine day |
| 20:58.56 |
``Erik |
those all
sound fun to me |
| 20:59.14 |
mafm |
mechanical
engineering? |
| 20:59.18 |
pacman87 |
yes |
| 20:59.32 |
``Erik |
brlcad:
here's my grocery list O.o |
| 20:59.41 |
mafm |
meh, the
unwashed masses taking over poor CE/CS :( :P |
| 20:59.55 |
``Erik |
ce and cs are
wayyyyyy different |
| 21:00.22 |
mafm |
I know, but
AFAIK in Europe it's mosly CE all around |
| 21:00.47 |
``Erik |
yeah, cs is
misunderstood as ce here in the US |
| 21:00.47 |
mafm |
and people
from any other science field taking jobs from us :D |
| 21:00.51 |
*** join/#brlcad andrecastelo
(n=Andre_Ca@189.71.14.52) |
| 21:00.59 |
Malyce |
haha |
| 21:01.14 |
mafm |
i.e.,
mathematicians working as VB mouse engineers |
| 21:01.16 |
``Erik |
wait, what?
damn fuckers in india stealing jobs from teh us? what? :D
*duck* |
| 21:01.17 |
mafm |
stuff like
that :P |
| 21:01.21 |
``Erik |
I mean, uh,
hi! |
| 21:01.32 |
mafm |
:) |
| 21:02.06 |
mafm |
just kidding,
but I have telecom eng. with me at work |
| 21:02.11 |
``Erik |
morning,
andre |
| 21:02.16 |
mafm |
and they make
my life... less interesting |
| 21:02.31 |
mafm |
previously it
was physicists... oh dear |
| 21:02.57 |
``Erik |
hm, I get to
see engineers and physicists trying to write c++, it's ...
interesting |
| 21:02.58 |
mafm |
grid storage
admins mounting volumes with NFS, not knowing how RPC worked
internally... |
| 21:03.42 |
``Erik |
heh, yeah,
beating down a screw with a hammer |
| 21:04.39 |
mafm |
now I have
telecom eng. girls trying to tell me how to interface a WS, telling
me that the WS should access caller system's DB
directly |
| 21:05.41 |
mafm |
so, when you
access some webservice of say, amazon, they should mess back with
the tables of your DB :P |
| 21:05.47 |
madant |
is a damn Indian :D |
| 21:06.04 |
madant |
feels it is awesome to wake up at 2:30 am |
| 21:06.18 |
``Erik |
yes, dawn, I
know :) kinda part of my joke there |
| 21:06.42 |
mafm |
madant: it
depends who's with you in the bed, I guess |
| 21:06.50 |
starseeker |
's jaw hits the floor in awe - unless I'm missing something,
they've open sourced the REDUCE computer algebra
system |
| 21:07.08 |
``Erik |
that's too
math geek for me, cliff :( |
| 21:07.09 |
madant |
``Erik, I
think partly the trend is changing now .. Maybe we will have more
chinese tech support in 5 years :D |
| 21:07.31 |
``Erik |
I was half
considering learning indian and moving out there for a few
years |
| 21:07.32 |
madant |
mafm: Indeed
:D |
| 21:07.54 |
brlcad |
madant: so
you seen the jai ho music video with the pussycat
dolls? |
| 21:08.02 |
*** join/#brlcad typ0_
(n=coder@um-sd06-125-2.uni-mb.si) |
| 21:08.04 |
madant |
Some parts
are really great , "cheap". scenic :) |
| 21:08.15 |
madant |
brlcad: not
really :D |
| 21:08.31 |
brlcad |
either of
those lines humorously works as an answer |
| 21:08.45 |
madant |
brlcad: I
liked Danny Boyle's Trainspotting better ;) |
| 21:08.46 |
``Erik |
madant: I
think I"d be more interested in looking at the incredible
history |
| 21:08.53 |
``Erik |
I'm a bit of
a history/archeology buff |
| 21:09.14 |
``Erik |
and india is
home to one of the 7 original civilzations |
| 21:09.20 |
starseeker |
``Erik:
computer algebra is for people who aren't math geeks but want the
correct answers to math questions :-) |
| 21:09.22 |
madant |
``Erik, the
church i sometimes go to :P is around 1200 years old |
| 21:09.44 |
``Erik |
screw 1200
years you got the fucking oldest dock in the world, fucking 4k
years old |
| 21:09.48 |
madant |
had to study sanskrit for 5 years |
| 21:10.11 |
Malyce |
I had to for
4 |
| 21:10.18 |
Malyce |
it wasn't all
bad |
| 21:10.24 |
madant |
``Erik, there
was even a recent discovery of something 10k years old in the
indian ocean/arabian sea if i am not mistaken |
| 21:10.28 |
``Erik |
lothal? |
| 21:10.33 |
starseeker |
``Erik:
<snort> REDUCE might actually qualify as computer archeology
- it's earliest development may predate BRL-CAD's |
| 21:10.36 |
brlcad |
but is it one
of the original alien-seeded civilizations |
| 21:10.54 |
``Erik |
lisp is alien
technology. |
| 21:11.30 |
mafm |
10k years
old? peanuts, in Iberian peninsula the neanderthals already played
WoW |
| 21:11.31 |
madant |
``Erik,
Lothal is still just around 5k .. |
| 21:11.32 |
brlcad |
alienware
makes computers for lisp? |
| 21:11.33 |
``Erik |
all
thingscomputer are history, not archeology :( |
| 21:11.54 |
Malyce |
mafm:
ahahahaha |
| 21:12.19 |
``Erik |
shit like
lothal makes me read articles and ponder existance |
| 21:12.29 |
Malyce |
Erik: Why
? |
| 21:12.37 |
``Erik |
dude, it's
awesome |
| 21:12.41 |
madant |
brlcad, also
i like the song "O Saya" and the wordless "Latika's theme" much
better than Jai ho :D |
| 21:12.55 |
starseeker |
daydreams about alienware lisp machines... |
| 21:12.58 |
``Erik |
the first
known dock, cut channel and a planned city |
| 21:12.58 |
Malyce |
Erik:
*shrugs* |
| 21:13.05 |
Malyce |
I
know |
| 21:13.32 |
madant |
and such a
LONG time ago :D |
| 21:13.34 |
``Erik |
fucking dude,
they had communical plumbing millenia before the western
world |
| 21:13.54 |
mafm |
communal? |
| 21:13.59 |
Malyce |
I wanna see
the Bering strait someday |
| 21:14.02 |
``Erik |
yeah, heh
:) |
| 21:14.10 |
Malyce |
Don't you
mean Mohenjo Daro ? |
| 21:14.18 |
``Erik |
houses had
tehir own damn plumbing |
| 21:14.46 |
Malyce |
That's Indus
valley civ |
| 21:14.51 |
``Erik |
they waren't
stupid back then, just lacked the info base we have now |
| 21:15.12 |
Malyce |
I am not sure
that's Lothal though |
| 21:15.15 |
mafm |
they didn't
have youtube, so their productivity excelled |
| 21:15.22 |
``Erik |
iirc,
archeologists claim there were 7 original civilizations |
| 21:15.35 |
``Erik |
indus valley
was one of the earlier ones and had some of the most modern
features |
| 21:15.40 |
Malyce |
Lothal is
supposed to be an underwater artifact, not well
explored |
| 21:15.57 |
Malyce |
Indus valley
was the one with the plumbing and the planning |
| 21:16.02 |
Malyce |
that we do
know abt |
| 21:16.06 |
``Erik |
I thought
lothal was exposed, just a town on the river |
| 21:16.20 |
Malyce |
town
? |
| 21:16.27 |
Malyce |
maybe |
| 21:16.41 |
Malyce |
let me
consult the great wikipedia |
| 21:16.58 |
``Erik |
I d'no, best
I've heard was that lothal krunked rome in tech and did it 1000
years earlier |
| 21:17.51 |
Malyce |
It was part
of Indus valley |
| 21:18.02 |
``Erik |
yeah, but
its' the gem |
| 21:18.06 |
Malyce |
I was
thinking of another submerged artifact |
| 21:18.15 |
``Erik |
no, we
haven't found atlantis yet :D |
| 21:18.22 |
Malyce |
haha |
| 21:18.36 |
``Erik |
the thing out
by the straits of gibraltor, sorry, that was artifact from the boat
radar paths |
| 21:18.52 |
Malyce |
no, there was
a mythical city in India |
| 21:18.53 |
mafm |
Gibraltar* |
| 21:18.55 |
Malyce |
sort of like
Troy |
| 21:19.13 |
``Erik |
I do not
spell good when I'm drunk. Fuck off. :D |
| 21:19.15 |
Malyce |
myth, but
whether the artifact was the same, unverified |
| 21:19.23 |
madant |
:D |
| 21:19.40 |
mafm |
your annoying grammar fascist :P |
| 21:20.00 |
``Erik |
I'll be more
of a bitch than you when I'm together, trust me |
| 21:20.10 |
madant |
is fascinated by chinese civilizations too .. it takes a hell
of a people to stand 1000 year dynasties |
| 21:20.19 |
``Erik |
so, yeah, I
like archeology and ancient history a lot |
| 21:20.23 |
Malyce |
Dwarka |
| 21:20.43 |
``Erik |
china is
awesome, back int he 4 seasons and the warring kingdoms
period |
| 21:21.09 |
``Erik |
japan learned
and integrated a lot from china, it's all awesome |
| 21:21.19 |
madant |
``Erik, and
to imagine how a common writing system without a common speech
system emerged is unbelievable :) |
| 21:21.22 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 21:21.27 |
madant |
even finds it illogical at times |
| 21:21.29 |
Malyce |
but it is a
coincidence that you mention Atlantis |
| 21:21.44 |
Malyce |
Dwarka was
supposed to have sunk as well |
| 21:21.59 |
``Erik |
<-- was
just a kid, but loved going to the 'theme park' on okinawa that
imitated edo period japan, plus the big holidays wehre they all got
dressed up |
| 21:22.19 |
Malyce |
you lived in
Japan ? |
| 21:22.25 |
``Erik |
'85 to
'88 |
| 21:22.32 |
Malyce |
I want to
live there someday |
| 21:22.33 |
``Erik |
around
kadnea |
| 21:22.36 |
``Erik |
kadena |
| 21:22.40 |
Malyce |
watch too
much anime |
| 21:22.44 |
madant |
think japanese women still walk funny :) |
| 21:22.51 |
``Erik |
no, I'm not a
huge animae fan |
| 21:22.55 |
Malyce |
madant: what
?? |
| 21:23.06 |
``Erik |
sorry,
madant, I'll stop romping them so they can walk normal for
ya |
| 21:23.09 |
``Erik |
*duck* |
| 21:23.16 |
madant |
haha
:D |
| 21:23.46 |
madant |
is confounded by Japan too.. How could someone close down
their borders for 200 years |
| 21:24.05 |
madant |
Malyce, the
kimono effect :D |
| 21:24.08 |
mafm |
off-topic
(?): Leslie on deadlines: "For all you procrastinators out there,
please check out Sean's story. If you want something badly enough,
you will find a way to make it happen." |
| 21:24.11 |
Malyce |
ahhhhhh |
| 21:24.20 |
mafm |
lol |
| 21:24.21 |
Malyce |
mafm: really
? |
| 21:24.30 |
mafm |
yep, right
now in the mailing list |
| 21:24.32 |
madant |
mafm, :) what
is Sean's story :O ? |
| 21:24.47 |
``Erik |
the us closed
borders for a long time |
| 21:24.56 |
Malyce |
I will only
do that once I have finished with brl thoudh |
| 21:24.57 |
madant |
``Erik, the
did ? |
| 21:25.02 |
madant |
*they |
| 21:25.05 |
``Erik |
ww1 forced
things open |
| 21:25.10 |
``Erik |
ww2 make it a
fact |
| 21:25.23 |
mafm |
madant: one
post @ gsoc-discuss, telling about his exams and application to
Haiku I think (I just fly over posts) |
| 21:25.50 |
``Erik |
don't screw
with les, she don't take crap |
| 21:26.01 |
mafm |
it's funny
that she calls procrastinators to ppl complaining about deadlines,
but the ppl complaining usually are pretty stupid |
| 21:26.39 |
``Erik |
she has mebbe
a thousand people bugging her |
| 21:26.44 |
``Erik |
step off, yo
:D |
| 21:26.53 |
madant |
feels paranoid now :D |
| 21:27.04 |
madant |
brlcad, can
you see my submitted application :D |
| 21:27.50 |
madant |
mafm, what is
the name of the post ? Application Deadline / |
| 21:27.54 |
``Erik |
mentors are
supposed to be the first interface, if they can't help, it goes to
org admins... if they can't help, THEN it goes to les and
chris |
| 21:28.06 |
mafm |
madant:
yes |
| 21:28.43 |
mafm |
Sean is the
guy who began the thread, Leslie has posted just now |
| 21:28.51 |
mafm |
or like 20
mins ago |
| 21:29.20 |
mafm |
complaints
are in many other threads, though |
| 21:29.28 |
madant |
``Erik, and
my comment about 1200 year old church was really that if there
could be a 1200 year old church here, (there is one even roughly
2000 year old too nearby :D) , there could be a lot more
;) |
| 21:30.04 |
``Erik |
one of my
bigger thrills in the US was going to cahokia |
| 21:30.28 |
mafm |
1200 for a
church (building) is not very very common, but there are lots of
structures older than that all around |
| 21:30.29 |
``Erik |
was a
bustling metropolis around 1100 or 1200, before european
incursion |
| 21:30.34 |
madant |
mafm: argh..
i thought Sean = brlcad and was confused |
| 21:30.35 |
mafm |
all of the
roman empire, for one |
| 21:30.55 |
mafm |
madant: ah
no, it was just a random Sean, not Teh Sean |
| 21:31.10 |
mafm |
a lesser
devil, so to speak |
| 21:31.11 |
mafm |
:P |
| 21:32.00 |
madant |
``Erik,
sometimes I wonder how much things have changed since say 4000
years ago and how some things haven't :) for instance some of the
works of Aristotle seems so organized so structured, it doesnt seem
like something written such a long time ago |
| 21:32.23 |
madant |
except for
the slavery etc. :D |
| 21:32.46 |
``Erik |
:) some day,
I want to buy a plot of land and go start making stone tools and
see how far I can get |
| 21:32.53 |
mafm |
slavery was
much worse in the middle ages |
| 21:33.05 |
``Erik |
um, I'd argue
that the notion of a "wave slave" carries that
tradition |
| 21:33.11 |
mafm |
everything
was worse in the middle ages, in western world, really |
| 21:33.17 |
``Erik |
not as
horrible, but still a notion |
| 21:33.20 |
mafm |
(and past
middle ages too, well) |
| 21:34.41 |
*** join/#brlcad pacman87
(i=500@resnet-46-102.dorm.utexas.edu) |
| 21:34.54 |
madant |
``Erik, well
i think you would get pretty far :) |
| 21:35.13 |
``Erik |
I think it'd
be neat to get a view into what life was like |
| 21:35.40 |
``Erik |
I've been
exposed to a lot more cultural knowledge, but I think an awful lot
has been lost |
| 21:36.25 |
``Erik |
I mean,
y'know, ada lovelace... can I go from banging rocks to what she was
doing? |
| 21:36.29 |
``Erik |
or turing? or
... |
| 21:36.40 |
``Erik |
it'd be an
interesting experiment |
| 21:37.10 |
``Erik |
and I'm all
over crap like ö |
| 21:37.19 |
``Erik |
http://primitiveways.com/ |
| 21:39.28 |
madant |
``Erik,
Turing unlikely :D but then again information in hindsight is
.. |
| 21:40.23 |
madant |
i think
reaching roughly 1700 to 1800 will be ok ok .. after that even
methods of production become so specialized etc. |
| 21:40.42 |
Malyce |
You know the
shoes that Oetzi the iceman wore ? |
| 21:40.44 |
``Erik |
allz I gotta
do is find ahardware store with a stock of inifinte tape
rolls |
| 21:40.55 |
``Erik |
otzi, in the
alps |
| 21:40.59 |
Malyce |
some shoe
company tried to buy and copyright the designs |
| 21:41.08 |
``Erik |
had an arrow
head in his hip, right? |
| 21:41.10 |
Malyce |
yes |
| 21:41.32 |
``Erik |
iirc, his
belt had a hidden pocket |
| 21:41.41 |
``Erik |
big news in
the archeology community |
| 21:41.57 |
Malyce |
a czech
company |
| 21:41.58 |
``Erik |
around 3k old
and had his skin on him |
| 21:42.21 |
``Erik |
some german
tourists saw him, cops thought he was a recent murder |
| 21:42.42 |
Malyce |
lots of ppl
tried to say they saw him first |
| 21:42.57 |
Malyce |
there was
even a woman who claimed she spit on him when she saw him
first |
| 21:43.12 |
Malyce |
so that her
DNA could be verified to show that she 'discovered' him |
| 21:43.26 |
Malyce |
so far DNA
analysis: 'inconclusive' |
| 21:43.26 |
``Erik |
yeah, I know
the story :) there were a couple pete bog bodies that got similar
attention up in ireland or so |
| 21:43.41 |
Malyce |
The poor
bastard |
| 21:43.52 |
Malyce |
he was pretty
f****d up |
| 21:43.59 |
``Erik |
but otzi is
one of the oldest |
| 21:44.01 |
Malyce |
what a way to
die |
| 21:44.23 |
Malyce |
apparently he
was attacked more than once |
| 21:44.30 |
``Erik |
best I grok,
he was pissing folk off, they chased him, shot an arrow in him, he
ended up stopping in the snow after a while |
| 21:44.44 |
``Erik |
one theory is
that he was part of a group and they ditched him |
| 21:44.58 |
``Erik |
had a copper
axe I think |
| 21:45.09 |
``Erik |
pricy blingy
at the time |
| 21:45.12 |
Malyce |
he was all
cut up |
| 21:45.20 |
Malyce |
and had blunt
trauma |
| 21:45.32 |
Malyce |
and was shot
with an arrow that hit somewhere vital |
| 21:45.44 |
Malyce |
shoulder |
| 21:45.49 |
``Erik |
hm, I recall
that he was beaten up a bit, but was it was the arrow in the hip
that put him dow |
| 21:45.50 |
``Erik |
n |
| 21:45.58 |
``Erik |
thought it
was the hip, I may misrecall |
| 21:46.00 |
Malyce |
but, would
have died even with modern medical aid |
| 21:46.07 |
Malyce |
shoulder |
| 21:46.13 |
Malyce |
so says the
almighty wiki |
| 21:46.17 |
``Erik |
aight |
| 21:46.29 |
``Erik |
I"m working
on memory from papers, not the almighty wiki |
| 21:46.38 |
``Erik |
ötzi I
thought |
| 21:46.44 |
``Erik |
named after
the mountain |
| 21:46.53 |
Malyce |
apparently he
also had companions |
| 21:47.03 |
Malyce |
Oetzal
alps |
| 21:47.06 |
``Erik |
*point* said
that |
| 21:47.30 |
``Erik |
whci'd be
ötzal in german :) |
| 21:47.40 |
Malyce |
yes |
| 21:47.57 |
``Erik |
german
tourists found him, right? |
| 21:48.00 |
Malyce |
I am only
saying Oetz because I have switched my keyboard to
english |
| 21:48.10 |
Malyce |
allegedly |
| 21:48.10 |
``Erik |
there was a
stink between germany and switzerland about him |
| 21:49.04 |
Malyce |
but the dude
was pretty well equipped |
| 21:49.07 |
``Erik |
um ummmm,
have you read about the jutland disc? um, copper and gold, looks
like a 5k old astronomy table? |
| 21:49.10 |
Malyce |
had a lot of
gear on him |
| 21:49.25 |
``Erik |
he had bone
and leather gear and an un-shafted copper axehead |
| 21:49.26 |
Malyce |
not |
| 21:49.27 |
Malyce |
yet |
| 21:49.35 |
Malyce |
and
flint |
| 21:49.43 |
Malyce |
and lots of
nice little trinkets |
| 21:49.49 |
``Erik |
yeah, flint
and uh, moss in his belt pocket |
| 21:49.52 |
Malyce |
including
many different kinds of moss |
| 21:50.11 |
Malyce |
he had nice
clothes to go |
| 21:50.15 |
``Erik |
the notion of
a belt pocket was huge |
| 21:50.40 |
Malyce |
the wiki is
empty on 'jutland disc' |
| 21:50.40 |
``Erik |
that he had
moss and flint and iron, kinda twisted the community :) |
| 21:50.44 |
``Erik |
um |
| 21:50.48 |
``Erik |
I'll find it,
hold up |
| 21:52.18 |
``Erik |
fuck
mighttake me some time |
| 21:53.52 |
``Erik |
http://2.bp.blogspot.com/__Xy7sukjiYU/SYMV9NI0P2I/AAAAAAAAALA/IDk1DKG7WHc/s320/xin_5007032416365151425951.jpg
comes up and is nice, but not what I'm thinkin' of |
| 21:54.43 |
``Erik |
http://www.cyberia.org.uk/thedisk.html |
| 21:54.49 |
*** join/#brlcad Ralith|trip
(i=40f692fb@gateway/web/ajax/mibbit.com/x-dd22cac15d90fe56) |
| 21:56.27 |
Ralith|trip |
so, everyone
get their apps in? |
| 21:57.20 |
Malyce |
what is
unique about this disk ? |
| 21:57.38 |
Malyce |
I woulda
thought lots of roman stuff would have been found |
| 21:57.46 |
``Erik |
14
apps |
| 21:58.24 |
``Erik |
malyce: it's
far older than roman stuff, and provides insanely accurate
astronomical info, like, unmatched until 1600 or so |
| 21:59.01 |
Malyce |
It shows the
big dipper, sun, crescent moon and a couple of boats |
| 21:59.11 |
Malyce |
how is that
accurate astronomical info ? |
| 21:59.12 |
``Erik |
there's
transit info on it |
| 21:59.15 |
``Erik |
supposedly |
| 21:59.26 |
Malyce |
although I
know that the Egyptians were into that kinda stuff |
| 21:59.29 |
``Erik |
that ignores
the heliocentric fallacy, etc |
| 21:59.30 |
Malyce |
transit info
? |
| 21:59.37 |
Malyce |
oh
hell |
| 21:59.39 |
Malyce |
you are
right |
| 21:59.44 |
Malyce |
why didn't I
think of that |
| 22:00.07 |
Malyce |
so, just
heliocentricity ? anything else ? |
| 22:00.17 |
``Erik |
those dang
weirdos dancing around fires and shit before good old roman
culture, they knew what they were doin' |
| 22:00.22 |
Ralith|trip |
lol |
| 22:00.38 |
Malyce |
anything else
except heliocentricity ? |
| 22:00.45 |
madant |
Malyce, i
think probably correct relative location of stars of the big dipper
etc. ? |
| 22:00.52 |
``Erik |
they had
mapped correct keppler orbits, dude |
| 22:01.12 |
Malyce |
there is
nothing about the position of the stars |
| 22:01.15 |
``Erik |
they made the
jump to say that the earth orbits the sun |
| 22:01.17 |
Malyce |
even I can
tell its wrong |
| 22:01.28 |
Malyce |
but kepler
orbits |
| 22:01.35 |
Malyce |
and
heliocentricity |
| 22:01.38 |
``Erik |
I'm assuming
the translations I've read are right |
| 22:01.47 |
Malyce |
the big
dipper seems wrong |
| 22:01.50 |
Malyce |
for
sure |
| 22:02.11 |
``Erik |
my impression
is that these dudes had an accurate summary of the solar system
long before copernicus and them |
| 22:02.15 |
Malyce |
but how the
kepler orbits ? |
| 22:02.35 |
Malyce |
that implies
ellipses, not circles if I remember |
| 22:02.37 |
``Erik |
the addon
side bars are supposed to be the formulas |
| 22:02.46 |
``Erik |
it went
through like 4 revisions |
| 22:02.46 |
Malyce |
the boats
? |
| 22:03.27 |
``Erik |
*shrug* it's
a neat artifact :() |
| 22:03.28 |
``Erik |
:) |
| 22:04.02 |
Malyce |
hmmm.... must
find out more |
| 22:04.33 |
Malyce |
I would have
thought that all the banging by those roman troops would have made
the damn thing anything, but precise |
| 22:04.48 |
Malyce |
but,
cool |
| 22:04.49 |
``Erik |
´this was way
before the roman conquest of the area, supposedly |
| 22:05.03 |
``Erik |
like, 1k
years before |
| 22:05.13 |
``Erik |
northern
touton area |
| 22:05.16 |
``Erik |
iirc |
| 22:05.50 |
``Erik |
rome was busy
getting their asses kicked by the greeks and the esquatarions at
that time |
| 22:06.42 |
Malyce |
my deep and
extensive knowledge of the roman empire |
| 22:06.48 |
Malyce |
comes from
AOE I and II |
| 22:06.51 |
Malyce |
:D |
| 22:07.05 |
Malyce |
plus the
expansions of cours |
| 22:07.18 |
``Erik |
hehehe, they
got the butts kicked bigtime for a long assed time |
| 22:07.24 |
``Erik |
probably what
made 'em so aggressive |
| 22:07.45 |
``Erik |
then they
went to fiat money and went all insane on expansionism, got
slaughtered in the end |
| 22:08.07 |
Malyce |
they had
their fun in the sun |
| 22:08.20 |
``Erik |
oh, they had
a hell of a run, they were the shit |
| 22:08.37 |
Malyce |
only beaten
so far by the Mongols |
| 22:08.38 |
``Erik |
but they went
all empire and fucked shit up, couldn't sustain it |
| 22:08.51 |
Malyce |
Mongols
rule |
| 22:08.54 |
``Erik |
the mongols
were an annoyance, just like the carthegans |
| 22:09.07 |
Malyce |
they were
more than an annoyance |
| 22:09.17 |
``Erik |
it was
over-extending taht brough them down |
| 22:09.40 |
Malyce |
they were to
the barbarians who settled in the ruins of the roman empire, what
the barbarians were to the roman empire |
| 22:09.41 |
``Erik |
hannibal
fucking shredded them, but ended up limping back home and getting
executed |
| 22:09.59 |
``Erik |
the mongols
got turf, but *shrug* they didn't kncok the might romans down, they
just annoyed 'em |
| 22:10.16 |
``Erik |
fucking
hannibal took rome! but rome won the war |
| 22:10.35 |
Malyce |
why did the
huns turn back ? |
| 22:10.49 |
Malyce |
ahh yes,
attilla had a conversation with the pope |
| 22:11.02 |
Malyce |
but those
weren't the mongols |
| 22:11.13 |
``Erik |
iirc, they
worked out deals and had insuffient stuff to continue the
campaign |
| 22:11.16 |
Malyce |
the mongols
came much later, when rome had been destroyed |
| 22:11.40 |
Malyce |
they came
after germany and poland were somewhat in existence i
think |
| 22:11.43 |
``Erik |
mongols were
way later, western rom was gone, but they did a job on
eastern |
| 22:11.45 |
Malyce |
as
kingdoms |
| 22:12.19 |
Malyce |
have you seen
Mulan ? |
| 22:12.30 |
``Erik |
no |
| 22:12.38 |
Malyce |
its a disney
movie |
| 22:12.38 |
``Erik |
I don't watch
movies much |
| 22:12.43 |
Malyce |
old
classic |
| 22:12.56 |
Malyce |
about how a
chinese girl beats back the mongols |
| 22:13.05 |
Malyce |
I thought the
plot was hilarious |
| 22:13.09 |
``Erik |
heh |
| 22:14.58 |
Malyce |
I am guessing
that you are older than me by about a decade |
| 22:15.06 |
``Erik |
heh,
probably |
| 22:15.52 |
``Erik |
I was at the
very first screening of star wars. that help ya? |
| 22:16.14 |
Malyce |
holy
hell |
| 22:16.33 |
Malyce |
I was at the
very first screening of the remastered version |
| 22:16.36 |
Malyce |
:D |
| 22:16.52 |
``Erik |
heh :( '77, i
was there, man |
| 22:17.04 |
``Erik |
I WAS
THERE!!!! </60's nam vet hippy> |
| 22:17.11 |
Malyce |
haha |
| 22:17.18 |
Malyce |
that puts you
at two decades then |
| 22:17.27 |
Malyce |
but you said
you were a kid in 85 |
| 22:17.35 |
``Erik |
I was
young |
| 22:17.43 |
``Erik |
was in
diapers in 77 |
| 22:17.54 |
Malyce |
ok, that
fixes it |
| 22:17.59 |
Malyce |
slightly over
a decade |
| 22:18.01 |
``Erik |
:) |
| 22:18.03 |
``Erik |
32 |
| 22:18.10 |
Malyce |
yes |
| 22:18.26 |
Malyce |
but gives you
bragging rights |
| 22:18.38 |
Malyce |
wait, what
were you doing watching SW in diapers ? |
| 22:19.41 |
``Erik |
my parents
are geeks, they took me |
| 22:19.50 |
Malyce |
and you
remember ?? |
| 22:19.55 |
``Erik |
of course
nto! |
| 22:19.58 |
Malyce |
wow you have
good memory |
| 22:20.00 |
Malyce |
huh
? |
| 22:20.10 |
``Erik |
but, y'know,
they said it, and, it's a hell of a braggin' line |
| 22:20.45 |
Malyce |
haha |
| 22:22.07 |
``Erik |
WANT MY CAR
BAKC!`#!~@ |
| 22:26.02 |
bjorkintosh |
what did you
do to it? |
| 22:26.27 |
``Erik |
bumped a
curb |
| 22:27.05 |
``Erik |
rental trash
nd my pickup woulda just bounced, the m3 destroyed itself
:( |
| 22:27.05 |
brlcad |
mafm: but
still a devil nonetheless muahaha |
| 22:29.18 |
Malyce |
brlcad: he
meant you were the bigger devil |
| 22:29.53 |
mafm |
brlcad:
reading your post |
| 22:30.05 |
mafm |
madant: post
alert, this time it's Teh Sean for real :) |
| 22:34.27 |
mafm |
brlcad: good
post, btw |
| 22:35.08 |
mafm |
``Erik:
what's your car? |
| 22:36.18 |
Ralith|trip |
mafm: what
was that site you had w/ the mailing list archives? |
| 22:37.16 |
mafm |
Ralith|trip:
ml archives? dunno what you're talking about :) |
| 22:45.43 |
madant |
mafm: thanks
.. nice read |
| 22:46.15 |
madant |
brlcad:
awesome post :) i especially like "egregiously presumptuous"
:P |
| 22:51.24 |
Ralith|trip |
mafm: well
what post are you talking about |
| 22:52.19 |
mafm |
ah... gsoc
discuss |
| 22:52.54 |
mafm |
Ralith|trip:
http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/c5ce50861adfdd74?hl=en |
| 22:53.09 |
Ralith|trip |
ah,
ty |
| 22:53.30 |
madant |
hmm.. 7742
members wow :) |
| 23:02.08 |
Ralith|trip |
hm. Anyone
know where to find docs/tips on bit-packing? |
| 23:11.57 |
mafm |
nope |
| 23:13.25 |
Ralith|trip |
:/ |
| 23:13.28 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 23:59.24 |
mafm |
night |
| 00:07.12 |
Malyce |
svc co
svn://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad-sf |
| 00:07.26 |
Malyce |
svn: can't
connect ot host: Connection refused |
| 00:07.29 |
Malyce |
to |
| 00:19.06 |
*** join/#brlcad Ralith|trip
(i=40f692fb@gateway/web/ajax/mibbit.com/x-969114c0f859777f) |
| 00:21.29 |
Malyce |
what did I do
wrong ? |
| 00:21.45 |
Ralith|trip |
you looked at
it funny |
| 00:21.48 |
Ralith|trip |
we don't
allow that around here |
| 00:21.53 |
Malyce |
rats |
| 00:21.57 |
Malyce |
I knew
it |
| 00:22.21 |
Malyce |
was my syntax
wrong ? |
| 00:22.29 |
Malyce |
or was it the
repo address |
| 00:22.58 |
Malyce |
syntax |
| 00:23.06 |
Malyce |
fixed |
| 00:25.07 |
Malyce |
though, I am
not sure why the other one didn't work |
| 00:25.41 |
Malyce |
svn://
instead of http:// |
| 00:34.04 |
brlcad |
only certain
protocols are allowed |
| 00:34.14 |
brlcad |
have to
follow the checkout instructions ;) |
| 00:40.41 |
Malyce |
and where can
I read these instructions |
| 00:41.00 |
Malyce |
? |
| 00:43.04 |
Malyce |
are these SF
specific or do you mean general unix syntax ? |
| 00:46.24 |
brlcad |
Malyce: even
the general sf instructions say to use http/https instead of
svn |
| 00:47.12 |
Malyce |
again, where
are these instructions ? |
| 00:47.30 |
Malyce |
on the SF
main page, there is news about new project. There is a help button
at the bottom |
| 00:47.38 |
Malyce |
but the help
is pretty useless |
| 00:47.42 |
brlcad |
Malyce: have
you looked? |
| 00:48.13 |
Ralith|trip |
the new
layout does make it kind of hard to find if you don't know where to
look |
| 00:48.52 |
Malyce |
I tried the
first time I tried to checkout from XP |
| 00:48.53 |
brlcad |
Ralith|trip:
i'm not talking about hunting around the repo -- there are docs on
our site and on sf.net that say exactly what to use |
| 00:49.23 |
brlcad |
i mean, if
you even put "brl-cad svn" into google, it's in the top
results |
| 00:49.32 |
Ralith|trip |
I was
referring to the docs on source forge |
| 00:49.33 |
brlcad |
hence my
question of whether he even looked |
| 00:49.42 |
Ralith|trip |
didn't know
it was that googleable, though |
| 00:49.59 |
Malyce |
I did look
into the SF page, but I didn't google that |
| 00:50.06 |
Ralith|trip |
always
google |
| 00:50.14 |
Malyce |
then someone
told me the repo address |
| 00:50.19 |
Malyce |
Erik |
| 00:50.21 |
brlcad |
http://brlcad.org/wiki/Building_from_SVN
is the page, under our Documentation |
| 00:50.23 |
Malyce |
and it
worked |
| 00:50.31 |
brlcad |
and it's been
said here too :) |
| 00:50.33 |
brlcad |
~cadsvn |
| 00:50.34 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 00:50.52 |
Malyce |
is this an
IRC service ? |
| 00:51.04 |
brlcad |
so... someone
told you here.. don't you have logs? |
| 00:52.33 |
Malyce |
Erik |
| 00:52.57 |
brlcad |
what about
him? |
| 00:53.03 |
madant |
hmm.. another
great morning :) |
| 00:53.09 |
brlcad |
howdy
madant |
| 00:53.12 |
pacman87 |
hi
madant |
| 00:53.17 |
Malyce |
he gave me
the url |
| 00:53.34 |
Ralith|trip |
tries to work out how to bit-pack floats given min, max, and
desired precision values |
| 00:53.45 |
madant |
hi all :)
just heading out to town . |
| 00:53.47 |
Malyce |
but i used it
inside windows the first time, so i didn't have the svn:/https:
problem |
| 00:53.52 |
brlcad |
Malyce, yes,
you already said that.. :) I presume over IRC? don't you have
logs? |
| 00:54.01 |
Malyce |
I should pay
more attention to the brl-wiki |
| 00:54.07 |
Malyce |
I
checked |
| 00:54.47 |
Malyce |
is it
possible to also read the backlog when I am not on the channel
? |
| 00:54.55 |
brlcad |
~logs |
| 00:54.56 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 00:55.15 |
brlcad |
it's
generally better to stay on the channel, though, like via a screen
session |
| 00:55.38 |
brlcad |
with irc
hilight history over a screen session, you're always on irc and can
review logs/history/hilight |
| 00:56.28 |
brlcad |
i'm sure
there are tutorials on the web, but basically running screen+irssi
or simply leaving an irc client running and just using /away while
minimizing as an alternative to screen |
| 00:56.52 |
Malyce |
I am always
on IRC unless I am offline |
| 00:57.15 |
Malyce |
so, to read
the backlog, I'll go to ibot |
| 00:57.37 |
Malyce |
I thought you
meant the IRC client logs |
| 00:57.39 |
Malyce |
heh |
| 00:57.56 |
pacman87 |
I log IRC
chats through my client |
| 00:58.09 |
Ralith|trip |
doesn't
everyone? |
| 00:58.30 |
Malyce |
its auto with
mIRC |
| 00:59.05 |
brlcad |
Malyce: many
are *always* on IRC even when offline, that's part of the beauty of
screen |
| 00:59.28 |
Malyce |
how so
? |
| 00:59.40 |
brlcad |
and I was
referring to *your* irc logs earlier, but there are also general
channel logs |
| 00:59.59 |
Malyce |
you mean the
url you gave just now ? |
| 01:00.18 |
brlcad |
those would
be the general channel logs |
| 01:00.28 |
brlcad |
the one that
ibot mentioned are the general logs |
| 01:00.41 |
Malyce |
what is ibot
? |
| 01:00.54 |
Malyce |
just a
channel bot ? |
| 01:00.54 |
brlcad |
an irc bot
with lots of factoids |
| 01:01.11 |
Malyce |
so, you
invoked it ? |
| 01:01.12 |
brlcad |
a
multiple-channel bot, hundreds of channels |
| 01:01.21 |
brlcad |
no |
| 01:01.46 |
Malyce |
when does it
provide info ? |
| 01:01.53 |
brlcad |
when you ask
it? |
| 01:02.25 |
brlcad |
Malyce: I
take it you're very new to IRC? |
| 01:02.28 |
Malyce |
i didn't ask
it anything, did you ? |
| 01:02.31 |
Malyce |
very very
new |
| 01:02.57 |
Malyce |
I knew about
bot's from the Basshunter song |
| 01:03.01 |
Malyce |
Boten
Anna |
| 01:03.07 |
brlcad |
you get
ibot's attention with ~ or with its name prefixed to the
line |
| 01:03.08 |
Malyce |
then did some
wiki reading |
| 01:03.25 |
Malyce |
cool |
| 01:03.34 |
brlcad |
the bot has
various tidbits of information, humor, actions, and other services
it provides |
| 01:03.35 |
Malyce |
~what's
up |
| 01:03.36 |
ibot |
Up is the
direction away from the central point of gravity. |
| 01:03.43 |
Malyce |
ahahahahaha |
| 01:03.58 |
Malyce |
this is so
cooooool |
| 01:04.41 |
brlcad |
it can be
very useful and entertaining, but try to keep the public usage
tamed -- you can talk to it in private or in #botpark if you want
to "play" |
| 01:04.56 |
Malyce |
I have a new
friend now |
| 01:04.58 |
Malyce |
:D |
| 01:05.19 |
brlcad |
~malyce is
very very new to IRC, but learning quickly |
| 01:05.20 |
ibot |
brlcad:
okay |
| 01:05.37 |
brlcad |
ibot:
malyce? |
| 01:05.38 |
ibot |
i heard
malyce is very very new to IRC, but learning quickly |
| 01:05.41 |
Ralith|trip |
wow |
| 01:05.59 |
Ralith|trip |
##c++ is
full |
| 01:06.06 |
brlcad |
"full"? |
| 01:06.13 |
Ralith|trip |
or under
attack, or something? |
| 01:06.16 |
Ralith|trip |
I got shunted
to overflow |
| 01:06.21 |
pacman87 |
bouncers at
the door? |
| 01:06.27 |
Ralith|trip |
prety
much |
| 01:06.29 |
Ralith|trip |
pretty* |
| 01:06.32 |
brlcad |
Ralith|trip:
I got in just fine |
| 01:06.37 |
Ralith|trip |
hm. |
| 01:06.44 |
Ralith|trip |
probably
filtering unregistered users |
| 01:06.53 |
Ralith|trip |
gives Ralith a sidelong look |
| 01:07.27 |
Ralith|trip |
more likely,
filtering mibbit users |
| 01:07.41 |
Ralith|trip |
oh
well. |
| 01:08.18 |
brlcad |
you're not
identified |
| 01:08.44 |
Ralith|trip |
hmm |
| 01:08.49 |
brlcad |
don't
remember my modes, but pretty sure one of the modes (+Pcflnrt
#overflow 777) means kick you to overflow |
| 01:09.03 |
Ralith_ |
yay |
| 01:09.18 |
Ralith_ |
victory |
| 01:13.20 |
brlcad |
yukonbob:
request pending for you |
| 01:13.24 |
brlcad |
poolio: you
too, pending request |
| 01:20.04 |
poolio |
brlcad: gsoc
stuffs? |
| 01:20.45 |
brlcad |
yes |
| 01:20.49 |
brlcad |
poolio: are
you on the devel list? |
| 01:21.00 |
brlcad |
sending out a
gsoc e-mail |
| 01:21.41 |
Ralith_ |
oo |
| 01:24.18 |
brlcad |
anyone who
has already submitted an application -- do you get an e-mail
notification if a comment is posted? |
| 01:25.31 |
Ralith_ |
I don't think
I've had any comments posted. |
| 01:25.37 |
Ralith_ |
didn't
yesterday, anyway |
| 01:25.39 |
Ralith_ |
rechecks |
| 01:26.48 |
Ralith_ |
there's a
'subscribe to updates button,' suggesting that such a thing might
be opt in |
| 01:27.01 |
brlcad |
okay, that's
good to know |
| 01:27.19 |
brlcad |
mentors get
two buttons (one for public, another for private) |
| 01:27.21 |
Ralith_ |
it's not
clear whether that means notify on edits, comments, or
both |
| 01:27.28 |
brlcad |
tediously had
to subscribe to everything |
| 01:33.40 |
Ralith_ |
wonders how long it takes the mailing list to get stuff
out |
| 01:36.10 |
poolio |
brlcad:
woops, I wasn't :) |
| 01:36.14 |
brlcad |
i've seen
anywhere from less than a minute to the next day |
| 01:36.24 |
brlcad |
poolio: ah,
okay |
| 01:36.26 |
brlcad |
thought
so |
| 01:36.31 |
brlcad |
removes poolio from the CC line |
| 01:36.47 |
Ralith_ |
the next day?
O.o |
| 01:36.52 |
poolio |
I just
subscribed to it though |
| 01:37.16 |
Ralith_ |
I guess I
shouldn't bother eagerly spamming refresh on gmail. |
| 01:37.53 |
brlcad |
usually
within 5 minutes |
| 01:41.18 |
brlcad |
cool, gives
an e-mail and a count |
| 01:41.33 |
brlcad |
this is gonna
be a flurcking ton of e-mail... |
| 01:43.47 |
poolio |
brlcad: err,
what's going on? |
| 01:43.56 |
brlcad |
hm? |
| 01:44.19 |
brlcad |
poolio: i was
just drafting up a message about gsoc to the list, making sure all
the mentors are included |
| 01:44.35 |
poolio |
ah cool
cool |
| 01:44.58 |
brlcad |
poolio: you
still have to confirm on socghop site too |
| 01:45.37 |
poolio |
yeah I know,
I'm filling out the forms now |
| 01:45.41 |
brlcad |
it's a silly
3-way ping-pong |
| 01:45.45 |
Ralith_ |
confirm? |
| 01:45.52 |
Ralith_ |
poolio's
mentoring? |
| 01:46.19 |
brlcad |
always good
to have backup mentors |
| 01:46.29 |
Ralith_ |
cool |
| 01:46.52 |
brlcad |
anyone that's
not a student could conceivably be a mentor, *especially* if they
have already worked with the code |
| 01:47.06 |
brlcad |
but even that
is technically not requisite.. depends on the
student/project/org |
| 01:51.08 |
poolio |
brlcad: I
think I'm done...? |
| 01:51.13 |
poolio |
Ralith_: Yep
:) |
| 01:52.17 |
Ralith_ |
heads off |
| 01:52.19 |
Ralith_ |
back home
tomorrow. |
| 01:54.54 |
poolio |
brlcad: do
you know how many slots we have yet? |
| 02:00.28 |
brlcad |
preliminary
slots will be on tuesday iirc |
| 02:00.41 |
brlcad |
but we're not
taking more than 5 regardless |
| 02:00.53 |
brlcad |
and
technically as few as 1 |
| 02:08.16 |
dreeves |
brlcad I have
an image of the simple brep I was wondering if you had a minute to
look and tell me if it looks correct? |
| 02:15.18 |
dreeves |
I emailed and
image to you |
| 02:17.12 |
brlcad |
okay |
| 02:48.35 |
brlcad |
dreeves: test
case in what regard? |
| 02:48.55 |
brlcad |
is that one
of the breps made from one of the proc-db tools? |
| 02:49.18 |
brlcad |
and what do
you mean by "this is using the utah code"? |
| 02:50.43 |
dreeves |
yes it is
brep_simple from the proc-db |
| 02:52.01 |
dreeves |
the utah code
is the code written by William Martin from University of
Utah |
| 02:52.28 |
brlcad |
i'm familiar
with the project |
| 02:52.53 |
dreeves |
I just didn't
know if I had a good test case or not |
| 02:53.04 |
brlcad |
so you made a
brep using brep_simple, then exported that out to whatever they're
taking as input? |
| 02:53.24 |
brlcad |
brep_simple
is certainly a starting point |
| 02:53.30 |
dreeves |
No I pulled
the source into librt |
| 02:53.30 |
brlcad |
or
breplicator's cube |
| 02:53.54 |
brlcad |
so you hooked
into _shot() and _prep() to hand off to their code? |
| 02:54.00 |
dreeves |
Yeah I tried
that one to and it looked good |
| 02:54.34 |
brlcad |
how are you
using their code? |
| 02:54.52 |
dreeves |
More as a
reference than anything |
| 02:55.16 |
dreeves |
I just
replaced brep_intersect with their code |
| 02:55.50 |
dreeves |
I'm still
using everything outside that |
| 02:56.05 |
dreeves |
So did you
say it looked right? |
| 02:56.32 |
brlcad |
no, it's not
right, but it looks good |
| 02:57.12 |
dreeves |
Yeah that is
what I thought...So what's the main thing that is
wrong? |
| 02:57.32 |
brlcad |
there's
errors on the back side |
| 02:57.46 |
brlcad |
that could
the the additional parity work that brep_shot() does after
brep_intersect() |
| 02:58.24 |
brlcad |
if their
tracer is robust, much of that may even simplify |
| 02:58.28 |
dreeves |
Are you
talking about what looks like the little dots |
| 02:58.43 |
brlcad |
right |
| 02:58.46 |
dreeves |
ok |
| 02:58.54 |
dreeves |
Yeah I
noticed that |
| 02:59.07 |
brlcad |
there are
various edge cases that have to be accounted for |
| 02:59.46 |
dreeves |
Yeah let me
go take a look at that |
| 02:59.46 |
brlcad |
where any two
surfaces join, where trimmings join, grazing tangentially to a
surface, going through a corner, going through multiple
corner/edges, etc |
| 03:00.01 |
brlcad |
I'd start by
simplifying brep_shot() |
| 03:00.19 |
brlcad |
you should
also probably be working on a branch so your changes can be
tracked/seen/shared |
| 03:00.21 |
dreeves |
Yeah that is
what I'm going to take a look at |
| 03:01.46 |
dreeves |
sure |
| 03:03.45 |
brlcad |
you could
start by checking the a_onehit flag in shot() -- if that is set,
you only need to know the first/surface hit and can return
quickly |
| 03:03.52 |
brlcad |
that will
give better optical renderings |
| 03:04.02 |
brlcad |
then if
a_onehit is not set, return all hit segments |
| 03:04.19 |
brlcad |
where you'll
need to know when you go in/out through the solid |
| 03:04.51 |
brlcad |
that skewed
cube is a good example because you can get two segments if you
shoot through that tip and through the main body |
| 03:05.31 |
yukonbob |
reads scrollback |
| 03:07.44 |
dreeves |
ok I will
play around with it |
| 03:12.44 |
brlcad |
dreeves:
okay, you have commit access |
| 03:12.49 |
brlcad |
be sure to
read HACKING in detail if you've not already (particularly with
respect to commit acces and responsibility) |
| 03:13.16 |
brlcad |
suggest you
commit as you work to a branch for now for that thread of
work |
| 03:13.37 |
brlcad |
maybe
/svnroot/brlcad/brlcad/branches/utah_brep or something |
| 03:14.33 |
starseeker |
gets REDUCE (sort of) working - yet again Emacs is the
default interface :-/ |
| 03:18.10 |
dreeves |
ok brlcad I
will commit soon |
| 03:18.56 |
starseeker |
When you stop
and think, it really is incredible how much mathematical crunching
power can be downloaded for free these days :-) |
| 03:25.49 |
brlcad |
starseeker:
you've made the same mistakes I've been making |
| 03:25.54 |
brlcad |
have to
repost your comments |
| 03:25.58 |
brlcad |
they're
private by default |
| 03:30.36 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 03:36.03 |
brlcad |
dreeves:
shared your image with the mailing list |
| 03:36.15 |
dreeves |
cool |
| 03:36.34 |
dreeves |
Maybe I
should get on the mailing list |
| 03:41.08 |
brlcad |
dreeves: on
second thought, forget using a branch -- just work on trunk for
now |
| 03:41.26 |
brlcad |
we can work
out what to do about a conflict when one arises |
| 03:41.51 |
brlcad |
in the
meantime, maybe just have #ifdef sections for old/new |
| 03:42.23 |
dreeves |
Yeah I'm
trying to be careful to minimize the existing code I touch for
now....once things look right I will clean up |
| 03:42.24 |
brlcad |
brep is all
WIP so it's not subject to controls beyond what we need to
collaborate, so might as well use trunk |
| 03:42.54 |
dreeves |
Hey how do I
get on the mailing list I know I have seen it somewhere but I can't
find it now |
| 03:42.56 |
brlcad |
plus this is
priority, and i'm frankly surprised that you got it working that
easily |
| 03:43.17 |
brlcad |
i'm like 80%
sure that acne you saw is probably a bug in the existing
code |
| 03:44.00 |
dreeves |
Yeah I still
have more to do in the trimming department there |
| 03:44.20 |
dreeves |
I think I
know what is going on with the acne problem |
| 03:44.39 |
dreeves |
First things
first is to clean up trimming |
| 03:52.07 |
poolio |
dreeves:
purty image :D |
| 03:52.11 |
brlcad |
i'm actually
not convinced that's trimming |
| 03:52.48 |
brlcad |
those are
outer-trim surfaces where the trims match the edges (i.e. nothing
to trim) |
| 03:53.07 |
brlcad |
that's why
it's 80% that it's something on our existing side |
| 03:53.14 |
brlcad |
i.e. in the
parity checking |
| 03:53.53 |
brlcad |
either point
collapse/merging or it really is missing both surfaces
numerically |
| 03:54.36 |
brlcad |
and please do
commit asap, would like to test this out as well :) |
| 04:01.41 |
dreeves |
Ok I
will |
| 04:01.53 |
dreeves |
So how do I
get on the mailing list? |
| 04:03.17 |
dreeves |
nm I found
it |
| 04:03.20 |
louipc |
I think you
need to sign up on sourceforge |
| 04:55.24 |
starseeker |
brlcad: ah,
thanks |
| 04:57.16 |
starseeker |
dreeves: nice
work! |
| 04:59.24 |
dreeves |
thanks |
| 05:00.41 |
dreeves |
Still issues
but I think we are getting closer |
| 05:08.20 |
dreeves |
brlcad those
spots are being caused by the shader...seems like the surface
normals are messed up |
| 05:30.29 |
dreeves |
Ok fixed the
spots they were caused because I had my root finder tolerance set
too low up'd it and spots went away |
| 05:34.38 |
dreeves |
brlcad sent
you an updated image with spots gone...working on trimming
some |
| 05:41.51 |
*** join/#brlcad dreeves
(n=dreeves@67.130.253.14) |
| 05:48.48 |
*** join/#brlcad deeeffache
(n=deeeffac@adsl-99-151-192-240.dsl.emhril.sbcglobal.net) |
| 05:55.35 |
dreeves |
brlcad btw in
your message I think you said it lacked some optimizations I assume
you are talking about ray/plane optimization, it does have that in
it |
| 05:56.11 |
dreeves |
I will try to
commit tomorrow night latest and then you can check it out for
yourself |
| 05:56.31 |
dreeves |
maybe tonight
if I get the trimming stuff straightened out |
| 06:00.15 |
*** join/#brlcad andrecastelo_
(n=Andre_Ca@201008161042.user.veloxzone.com.br) |
| 06:35.33 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 06:53.59 |
*** join/#brlcad madant
(n=madant@117.196.134.66) |
| 07:17.10 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:26.46 |
*** join/#brlcad andrecastelo
(n=Andre_Ca@189.71.30.67) |
| 08:01.56 |
*** join/#brlcad cad63
(n=ca727801@bz.bzflag.bz) |
| 08:55.53 |
brlcad |
dreeves: the
optimizations I'm thinking of are actually the ones in the 2006
paper that made nurbs raytracing interesting in the first place
:0 |
| 08:56.29 |
brlcad |
using
vectorized evaluation and compact representation to get interactive
results |
| 08:57.25 |
brlcad |
given you
have something, I'd hope you'd already commit what you
have |
| 08:57.42 |
brlcad |
doesn't need
to be complete and tells a better story the more little steps you
break it up, even if there are 500 intermediate steps before it
"works" |
| 08:58.10 |
brlcad |
helps others
to understand the code by watching the work in progress, mistakes
and changes all |
| 09:27.32 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:31.31 |
*** join/#brlcad Lez
(n=lezardfl@189.58.208.46.dynamic.adsl.gvt.net.br) |
| 10:56.15 |
mafm |
hi |
| 11:31.49 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:44.10 |
brlcad |
howdy
mafm |
| 11:45.18 |
mafm |
:) |
| 11:45.55 |
mafm |
-> Today
Debian gets one step closer to really becoming 'the universal
operating system' by adding two architectures based on the FreeBSD
kernel to the unstable archive. |
| 11:46.10 |
mafm |
One Swirl To
Rule Them All. |
| 12:44.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 13:10.20 |
CIA-40 |
BRL-CAD:
03ddreeves70 * r34159
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: This is code
that works well with the test cube |
| 13:11.19 |
dreeves |
brlcad I
committed but the trimming isn't there and there currently is a
hack in it that I think is need because the trimming isn't there I
have the code for trimming I believe but haven't had a chance to
work on it |
| 13:12.27 |
dreeves |
brlcad I have
my editor settings hopefully set to comply with the rules outlined
in the HACKING guide if you spot please let me know |
| 13:13.11 |
brlcad |
dreeves:
cool |
| 13:13.13 |
dreeves |
also I
haven't had a chance to read the rules on committing (well I
scanned them). I just scanned through that because I didn't have
commit access at the time |
| 13:13.30 |
brlcad |
rules for
committing are pretty simple |
| 13:13.34 |
brlcad |
don't break
stuff |
| 13:13.37 |
brlcad |
and when you
do, fix it ;) |
| 13:13.49 |
dreeves |
I think I can
handle that |
| 13:14.15 |
brlcad |
consistency
updates are always good as are other cleanups through the code --
shouldn't be mixed in with logic changes if you can help it
though |
| 13:15.10 |
brlcad |
you'll find
all sorts of styles throughout, it's a bit of an on-going cleanup
to make everything consistent but they should minimally be
self-consistent within a given file |
| 13:15.27 |
dreeves |
I will
try...but to be honest I usually scan the code right before I
commit and I haven't had the chance to do that on this code because
I wanted to go ahead and commit |
| 13:15.44 |
brlcad |
also we work
on a monthly iteration cycle for releases, so commits should "slow
down" near the end of the month and be more focused on just bug
fixes and cleanup or holding until the release is
tagged |
| 13:15.53 |
dreeves |
Yeah I have
noticed that |
| 13:16.30 |
dreeves |
Do you want
me to go ahead and commit the code for the extrude or well you
still handle that via the patch? |
| 13:16.43 |
brlcad |
i'll can
still handle that |
| 13:16.48 |
dreeves |
ok |
| 13:17.01 |
brlcad |
something I
wanted to look into with that anyways, let you know if I change my
mind :) |
| 13:17.01 |
dreeves |
Well I'm off
to my day job :) |
| 13:17.06 |
brlcad |
cya! |
| 13:17.08 |
brlcad |
and
thanks |
| 13:17.11 |
brlcad |
cool
progress |
| 13:17.21 |
brlcad |
oh, last
commit 'note' |
| 13:17.28 |
brlcad |
you can't
really commit too frequently |
| 13:17.35 |
dreeves |
thanks needs
work...I did |
| 13:17.37 |
brlcad |
but you can
certainly commit too infrequently |
| 13:17.46 |
dreeves |
:) |
| 13:19.00 |
dreeves |
I have 2
issues in the code you that I think once addressed we will be able
to handle the complex geometries...One is trims and the other is a
big ole fat hack in the shot code |
| 13:19.25 |
dreeves |
later... |
| 13:28.31 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 13:33.52 |
_sushi_ |
Anyone knows
how to force CUPS to print A4 instead of A4 cut off to Letter
size? |
| 13:34.08 |
_sushi_ |
I switched
from Letter to A4 in already about 3 different config files and
restarted cups and still doesn't work |
| 13:34.24 |
_sushi_ |
cd
/etc |
| 13:35.26 |
_sushi_ |
replaces all occurences of "Letter" on /dev/hda with
"A4" |
| 13:36.54 |
_sushi_ |
Lol:
DefaultPageSize, DefaultPageRegion, DefaultImageableArea,
DefaultPaperDimension |
| 13:37.27 |
_sushi_ |
sets the dimension of all conceivable objects in the Universe
to A4 |
| 13:58.53 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 15:13.49 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 15:36.26 |
*** join/#brlcad dreeves2
(n=c752f348@bz.bzflag.bz) |
| 15:37.59 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 15:42.55 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:43.01 |
*** join/#brlcad Malyce
(n=iamtanma@deimos.jacobs-university.de) |
| 15:44.07 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187-24-30-229.3g.claro.net.br) |
| 15:54.33 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-146-80.3g.claro.net.br) |
| 15:59.10 |
brlcad |
comments for
most of you on the socghop site |
| 15:59.14 |
brlcad |
(students) |
| 16:02.52 |
pacman87 |
goes to check |
| 16:03.19 |
hippieindamakin8 |
hasnt found any |
| 16:03.34 |
brlcad |
hippieindamakin8: you're one of the few
remaining, patience :) |
| 16:03.47 |
hippieindamakin8 |
brlcad, sure
:) |
| 16:03.52 |
starseeker |
brlcad: ah,
thanks for restating my question |
| 16:03.55 |
brlcad |
yours was
longer and I'm getting fatigue :) |
| 16:04.06 |
brlcad |
starseeker:
just the one, dont' know if there were others |
| 16:04.24 |
brlcad |
doesn't like the html-enabled comment box .. pastes should be
plain-text |
| 16:13.18 |
pacman87 |
same thing
happened to me when i pasted my application |
| 16:20.48 |
brlcad |
hippieindamakin8: fwiw - a lot better than
last year, but still a lot of issues to sort out too |
| 16:20.53 |
brlcad |
let me know
if you have any questions |
| 16:22.06 |
Malyce |
hey
brl |
| 16:22.09 |
Malyce |
read the
comment |
| 16:22.12 |
brlcad |
howdy
Malyce |
| 16:22.14 |
Malyce |
how do i get
onto the wiki |
| 16:22.19 |
Malyce |
do you mean
the brl wiki ? |
| 16:23.34 |
hippieindamakin8 |
runs to look at the comment |
| 16:23.47 |
typ0 |
brlcad: any
comments on the IGES converter ? |
| 16:25.11 |
``Erik |
<PROTECTED> |
| 16:30.23 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 16:40.38 |
hippieindamakin8 |
brlcad, do i
discuss with you out here ? |
| 16:40.59 |
hippieindamakin8 |
or do i put
up a reply out there on melange ? |
| 16:41.10 |
brlcad |
hippieindamakin8: yes |
| 16:42.16 |
hippieindamakin8 |
brlcad, the
precision computation is worth it for getting the exact vertices
and the edges.Though i did propose on simplifying the sturm
sequence solving process by approximations |
| 16:42.33 |
hippieindamakin8 |
ESOLID does
it without any approximations. |
| 16:43.44 |
hippieindamakin8 |
because we
need to have the vertices and edges right for the intersections.but
again like the paper on ESOLID says some are rendered without this
precise computation with a good tolerance |
| 16:44.10 |
brlcad |
true, though
they still take "forever" in comparison :) |
| 16:45.09 |
hippieindamakin8 |
brlcad,
approximations like formulation of low degree equations for sturm
sequences with precise computation is halfway between these
two |
| 16:45.23 |
hippieindamakin8 |
two == ESOLID
and BOOLE |
| 16:45.25 |
brlcad |
basicaly,
right almost all the time -> very slow OR right only some of
the time -> fast |
| 16:45.42 |
hippieindamakin8 |
brlcad, yeah
:) |
| 16:46.26 |
brlcad |
but was
boole's "failing" something that could have been solved with better
book-keeping or failure detection/recovery on top |
| 16:47.31 |
hippieindamakin8 |
brlcad, how
is that ? |
| 16:48.48 |
hippieindamakin8 |
dint get the word book-keeping in this context
:| |
| 16:49.06 |
brlcad |
dreeves:
question for when you see this -- curious, what sort of performance
difference was there between what is previously/currently
implemented and having utah do the eval? |
| 16:49.33 |
brlcad |
hippieindamakin8: keeping track of a
graph/stack/tree/whatever of decisions that are made about the
topology |
| 16:49.48 |
hippieindamakin8 |
brlcad,
aah |
| 16:50.22 |
brlcad |
so you decide
A==B and later run into degenerate geometry .. maybe if the
tolerance was locally constrained and A!=B it would have
worked |
| 16:51.05 |
brlcad |
keeping track
of the topological decisions seems (to me) like a very strong way
to have failure recovery while still searching a solution space
very quickly with imprecise numerics |
| 16:51.23 |
brlcad |
you only work
harder if you're degenerate or within ambiguous
tolerances |
| 16:51.24 |
hippieindamakin8 |
brlcad, i
completely agree with that point |
| 16:51.48 |
brlcad |
it's just a
lot harder to code it that way :) |
| 16:52.05 |
hippieindamakin8 |
brlcad, its
worth a try aint it ? :) |
| 16:52.25 |
hippieindamakin8 |
degenerate
cases are the worst |
| 16:57.35 |
hippieindamakin8 |
brlcad, i ll
update the application/append another comment on the
appspot |
| 17:00.17 |
dreeves2 |
brlcad I
didn't really keep up but seems like the utah was a little faster
until I up'd the tolerance (but again this is just feel not by the
numbers) |
| 17:01.44 |
*** join/#brlcad dreeves2
(n=c752f348@bz.bzflag.bz) |
| 17:01.52 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 17:05.04 |
dreeves2 |
brlcad if you
responded to my last comment I didn't see it because I'm having to
use the web interface to irc...I need to get irc working from here
but haven't taken the time to investigate |
| 17:05.53 |
pacman87 |
dreeves2: you
didn't miss anything |
| 17:06.12 |
dreeves2 |
did you see
my comment about speed? |
| 17:06.55 |
pacman87 |
dreeves2:
brlcad I didn't really keep up but seems like the utah was a little
faster until I up'd the tolerance (but again this is just feel not
by the numbers) |
| 17:07.54 |
brlcad |
hippieindamakin8: okay |
| 17:08.02 |
dreeves2 |
thanks that
is it |
| 17:10.46 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:10.46 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're
reviewing applications, preliminary slot count on 7th, selections
announced on the 15th |
| 17:13.01 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 17:15.28 |
brlcad |
dreeves2:
that's kinda scary actually, because the current implementation is
basically dog-slow :) |
| 17:15.36 |
brlcad |
but certainly
workable |
| 17:15.46 |
brlcad |
if it works,
that will be the biggest factor |
| 17:16.52 |
brlcad |
wanders off for a bit |
| 17:24.58 |
dreeves2 |
brlcad yeah
I'm sure there is a ton of work to optimize and make fast. Like I
said I didn't really look at numbers or pay attension. My focus
was completely on getting the intersections right. There are
several things that I noticed that could speed it up but I want to
get it fully functional first then worry about
performance |
| 17:25.55 |
starseeker |
nods vigorously :-) |
| 17:34.49 |
*** join/#brlcad madant
(n=madant@117.196.129.23) |
| 17:39.19 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-239-204.dclient.hispeed.ch) |
| 17:41.51 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-175-113.3g.claro.net.br) |
| 18:01.01 |
CIA-40 |
BRL-CAD:
03starseeker * r34160 10/brlcad/trunk/ (4 files in 2 dirs): Convert
bolt man page to docbook |
| 18:23.28 |
CIA-40 |
BRL-CAD:
03starseeker * r34161 10/brlcad/trunk/ (4 files in 2 dirs): Convert
gastank man page to docbook |
| 18:36.45 |
CIA-40 |
BRL-CAD:
03starseeker * r34162 10/brlcad/trunk/ (4 files in 2 dirs): Convert
handle man page to docbook |
| 19:02.10 |
brlcad |
starseeker:
as entire dirs are done being converted, should remove the manpage
copies in that dir so we have minimal duplicates to keep
updated |
| 19:02.37 |
starseeker |
brlcad:
right |
| 19:02.49 |
starseeker |
in this case,
doing it as I go - that ok? |
| 19:03.13 |
starseeker |
if fewer
commits is better, I can wait |
| 19:03.47 |
brlcad |
nothing to do
with commit count, just more as a progress measure |
| 19:03.55 |
starseeker |
ah,
k |
| 19:03.59 |
``Erik |
looks at doc/docbook/system/man1/en/ and src/rt/
O.o |
| 19:04.10 |
brlcad |
didn't know
you were removing as you went -- there are a few in there that
haven't been removed iirc |
| 19:04.23 |
starseeker |
yeah, I need
to do a bit of cleanup |
| 19:04.25 |
brlcad |
(e.g. rtarea
came up when richard was working on it) |
| 19:04.31 |
starseeker |
nods |
| 19:04.41 |
brlcad |
just don't
want to get into an indeterminate state with mixes |
| 19:04.49 |
starseeker |
I'll pick off
the strays once I get through shapes |
| 19:05.11 |
brlcad |
either dir at
a time, or keep 'em in sync so we know what is left to do at a
dir/file level |
| 19:05.20 |
``Erik |
imagines uninstall would fail right now due to
that |
| 19:05.46 |
starseeker |
``Erik: ok,
ok I'll do it now ;-) |
| 19:05.55 |
brlcad |
``Erik:
uninstall doesn't fail on missing files (at least the automake
uninstall doesn't) |
| 19:06.09 |
``Erik |
ah, it uses
rm -f? |
| 19:06.17 |
brlcad |
yeah |
| 19:06.29 |
``Erik |
I know the
bsd pkg_delete gets bitchy on missing iles |
| 19:06.35 |
``Erik |
files, or
fiels with changed md5sums |
| 19:07.08 |
``Erik |
but that
should go clean, since it generates a manifest after install is
complete |
| 19:07.11 |
``Erik |
*shrug* |
| 19:07.15 |
``Erik |
stops blabbering and codes some |
| 19:08.22 |
*** join/#brlcad Malyce2
(n=iamtanma@deimos.jacobs-university.de) |
| 19:09.15 |
brlcad |
~seen
jdoliner |
| 19:09.18 |
ibot |
jdoliner
<n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net> was last seen
on IRC in channel #brlcad, 3d 20h 42m 54s ago, saying: 'k nm found
it'. |
| 19:21.37 |
CIA-40 |
BRL-CAD:
03starseeker * r34163 10/brlcad/trunk/src/ (24 files in 7 dirs):
Remove old man pages that have been incorporated into the docbook
system. |
| 19:21.47 |
starseeker |
there we
go |
| 19:29.13 |
CIA-40 |
BRL-CAD:
03starseeker * r34164 10/brlcad/trunk/ (4 files in 2 dirs): Convert
picket_fence man page to docbook |
| 19:39.35 |
CIA-40 |
BRL-CAD:
03starseeker * r34165
10/brlcad/trunk/doc/docbook/system/man1/en/bolt.xml: Whoops - fix
bolt author. |
| 19:40.57 |
mafm |
~starseeker++ |
| 19:41.37 |
CIA-40 |
BRL-CAD:
03starseeker * r34166 10/brlcad/trunk/ (4 files in 2 dirs): Convert
window man page to docbook |
| 19:46.55 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 19:46.55 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're
reviewing applications, preliminary slot count on 7th, selections
announced on the 15th |
| 19:53.53 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 19:53.53 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're
reviewing applications, preliminary slot count on 7th, selections
announced on the 15th |
| 20:01.21 |
CIA-40 |
BRL-CAD:
03starseeker * r34167 10/brlcad/trunk/doc/docbook/system/man1/en/
(bolt.xml gastank.xml handle.xml window.xml): it's window_frame(1),
not winfrm(1) |
| 20:07.27 |
*** join/#brlcad Malyce
(n=smartmin@deimos.jacobs-university.de) |
| 20:07.40 |
Malyce |
hi |
| 20:07.52 |
Malyce |
I tried
compiling on ubuntu |
| 20:08.06 |
madant |
howdy
Malyce |
| 20:08.08 |
madant |
and
? |
| 20:08.09 |
Malyce |
autogen.sh
gives autreconf and libtoolize failure |
| 20:08.38 |
Malyce |
what should I
do ? |
| 20:09.15 |
madant |
hmm.. weird..
pastebin error message ? |
| 20:10.00 |
Malyce |
this is what
i get |
| 20:10.01 |
Malyce |
Reading
package lists... Done |
| 20:10.01 |
Malyce |
Building
dependency tree |
| 20:10.01 |
Malyce |
Reading state
information... Done |
| 20:10.01 |
Malyce |
E: Couldn't
find package autoreconf |
| 20:10.32 |
Malyce |
sorry |
| 20:10.37 |
Malyce |
i posted the
wrong messages |
| 20:10.42 |
Malyce |
this is what
i get .. |
| 20:10.45 |
Malyce |
Preparing the
BRL-CAD build system...please wait |
| 20:10.45 |
Malyce |
Found GNU
Autoconf version 2.63 |
| 20:10.45 |
Malyce |
Found GNU
Automake version 1.10.2 |
| 20:10.45 |
Malyce |
Found GNU
Libtool version 2.2.6 |
| 20:10.45 |
Malyce |
Automatically
preparing build ... Warning: autoreconf failed |
| 20:10.45 |
Malyce |
Attempting to
run the preparation steps individually |
| 20:10.47 |
Malyce |
Preparing
build ... ERROR: libtoolize failed |
| 20:11.23 |
starseeker |
use http://pastebin.bzflag.bz/ |
| 20:12.09 |
CIA-40 |
BRL-CAD:
03starseeker * r34168 10/brlcad/trunk/ (4 files in 2 dirs): Convert
window_frame man page to docbook |
| 20:13.09 |
Malyce |
http://pastebin.bzflag.bz/m393a0eda |
| 20:13.49 |
``Erik |
which
OS? |
| 20:13.54 |
Malyce |
Ubuntu |
| 20:13.56 |
starseeker |
ubuntu
linux |
| 20:14.16 |
starseeker |
do you have
all the autotools installed? |
| 20:14.21 |
Malyce |
yes |
| 20:14.29 |
``Erik |
hm, I know
the macs rename libtoolize 'glibtoolize', have you checked to make
sure libtoolize installed with a 1.5 or later version, and tried
running it manually? |
| 20:14.29 |
starseeker |
huh |
| 20:14.37 |
Malyce |
and automake,
libtools, m4 etc |
| 20:14.39 |
madant |
Malyce, no
idea why libtoolize is failing.. :) i have never faced it .. you
should wait for our build ( and in general) guru brlcad
:) |
| 20:15.00 |
madant |
``Erik,
libtool provides /usr/bin/libtoolize in debian, same for ubuntu i
guess |
| 20:15.35 |
madant |
and this is
the output of running ./autogen.sh ? |
| 20:15.38 |
Malyce |
yes |
| 20:16.47 |
``Erik |
hmmmm, I'm
still using 1.5.26, wonder if something changed in 2 |
| 20:18.32 |
madant |
Malyce, just
make sure you have the latest revision and no changes from the
trunk etc ? I myself have autoconf 2.63 automake 1.10.1 and
libtool 2.2.6 and no probs :) |
| 20:19.21 |
``Erik |
imagines running libtoolize -cf by hand will provide more
informatin |
| 20:19.34 |
``Erik |
s/n$/o&/ |
| 20:19.55 |
Malyce |
I co this
morning |
| 20:19.58 |
madant |
what is the
output if you run autoreconf manually ? |
| 20:20.30 |
``Erik |
*sigh*
autoreconf will need the m4 directory wired into it and will try to
make libtoolize silent |
| 20:24.34 |
CIA-40 |
BRL-CAD:
03starseeker * r34169 10/brlcad/trunk/ (4 files in 2 dirs): Convert
wire man page to docbook. |
| 20:25.59 |
Malyce |
how should i
run the autoreconf manually ? |
| 20:26.05 |
Ralith |
returneth! |
| 20:27.25 |
mafm |
chanting hymns for returneth Ralith |
| 20:27.32 |
madant |
Malyce, is
the ./autogen.sh --verbose output any different ? |
| 20:35.24 |
Malyce |
just ran the
autogen --verbose |
| 20:35.27 |
Malyce |
but the
output is the same |
| 20:35.34 |
Malyce |
just quote
detailed |
| 20:35.40 |
Malyce |
i can post
the output if it would help |
| 20:35.41 |
Malyce |
? |
| 20:35.49 |
louipc |
yeah put it
in a pastebin |
| 20:36.33 |
Malyce |
http://pastebin.bzflag.bz/m52ab321c |
| 20:37.44 |
hippieindamakin8 |
brlcad,
``Erik there was a bug on bug tracker on sf which was "latest svn
failed on debian sid" |
| 20:38.25 |
hippieindamakin8 |
the build was
successful with some minimal errors during the build (these errors
are generally ignored) |
| 20:42.49 |
madant |
weird , why
the tick and quote=> 'ibtoolize: Failed to create
`m4 |
| 20:46.30 |
louipc |
I thought the
same thing |
| 20:52.47 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177593680.dsl.bell.ca) |
| 20:53.50 |
``Erik |
now why would
libtoolize want to create m4, and is it trying to make it as a dir
or file? O.o |
| 21:14.41 |
starseeker |
prepares some more nurbs test cases to put in the
repository |
| 21:15.34 |
brlcad |
suspects malyce *doesn't* have the autotools installed, at
least not some of the tools |
| 21:17.31 |
brlcad |
ah, verbose
log |
| 21:20.44 |
brlcad |
"'ibtoolize"
certainly looks wrong |
| 21:25.33 |
CIA-40 |
BRL-CAD:
03brlcad * r34170 10/brlcad/trunk/TODO: implement
prim->brep |
| 21:28.30 |
CIA-40 |
BRL-CAD:
03brlcad * r34171 10/brlcad/trunk/TODO: need a routine to convert
from NMG to BREP, ideally for both NURBS and polygonal NMG objects.
makes it easier to update functionality to the new data
types. |
| 21:30.04 |
CIA-40 |
BRL-CAD:
03brlcad * r34172 10/brlcad/trunk/TODO: need _tess() for brep
primitive |
| 21:34.53 |
brlcad |
gives mafm some high praises |
| 21:36.23 |
starseeker |
brlcad: any
idea why asc2g would say m_object_table[0].m_object is NULL
? |
| 21:36.41 |
poolio |
brlcad: I
started on nmg -> brep...I think it may work for polygonal NMG
objects, bu I believe it had some bugs |
| 21:36.52 |
brlcad |
poolio: yeah,
I saw that |
| 21:37.04 |
brlcad |
my eyebrow
went all crooked |
| 21:37.19 |
poolio |
I also think
there's a newer version around here (locally) that I forgot to
commit |
| 21:37.35 |
brlcad |
ahh, should
hunt that shtuff down! :) |
| 21:38.07 |
poolio |
Cause I
remember proclaiming myself done with arb*, and then I moved onto
the other shapes |
| 21:38.24 |
starseeker |
grr. Well,
looks like the .g goes in the repository, with hunting down the
asc2g bug being on the list |
| 21:38.52 |
brlcad |
you mean
g2asc I hope ;) |
| 21:38.54 |
mafm |
brlcad:
why? |
| 21:38.58 |
brlcad |
otherwise,
"there's your problem" :) |
| 21:39.19 |
starseeker |
not
sure |
| 21:39.35 |
brlcad |
starseeker:
.g is certainly better than nothing, but maybe just shove it up on
the website then |
| 21:39.40 |
brlcad |
or into the
wiki |
| 21:39.52 |
starseeker |
k |
| 21:40.06 |
brlcad |
a wiki page
showing the progress would be pretty useful |
| 21:40.16 |
brlcad |
before after
sets like you started |
| 21:40.31 |
starseeker |
hmm. ok,
that should be doable |
| 21:40.44 |
starseeker |
let me get
this file up somewhere for dreeves when he gets back
:-) |
| 21:42.13 |
starseeker |
here's the
g2asc output for the file: http://pastebin.bzflag.bz/m360c1791 |
| 21:43.08 |
starseeker |
doesn't see how g2asc is preserving the brep/nurbs info in
the asc file, to be honest |
| 21:43.52 |
brlcad |
starseeker:
ah |
| 21:43.53 |
brlcad |
yeah |
| 21:44.02 |
brlcad |
tclget/put
havent' been implemented apparently |
| 21:44.11 |
starseeker |
ooo, that'll
do it |
| 21:44.28 |
starseeker |
ok, here's
the .g: http://bzflag.bz/~starseeker/nurbs_tests.g |
| 21:44.31 |
brlcad |
I mean, just
looking at that output, that is clear |
| 21:44.50 |
starseeker |
I thought so,
but I wasn't sure if there was some magic going on ;-) |
| 21:45.07 |
mafm |
brlcad: *
brlcad gives mafm some high praises -- why? |
| 21:45.41 |
brlcad |
mafm: oh just
talking about you to other mentors |
| 21:45.58 |
mafm |
ah |
| 21:46.06 |
mafm |
what
for? |
| 21:46.18 |
brlcad |
nosey, eh?
:) |
| 21:46.27 |
brlcad |
just talking
about you, not to you ;) |
| 21:46.40 |
mafm |
well, it's
you who ignited the curiosity :) |
| 21:46.52 |
brlcad |
I know, it's
more fun that way |
| 21:46.58 |
mafm |
btw, have you
seen my reply in google thingy? I can't sign up as
mentor |
| 21:47.09 |
brlcad |
I know why
you can't sign up |
| 21:47.31 |
brlcad |
can't be a
mentor and a student |
| 21:47.37 |
mafm |
yes |
| 21:47.41 |
brlcad |
and given you
have multiple apps in, you're fixed as a student |
| 21:47.51 |
mafm |
however I'll
try to advise anyway, if anybody would find my advise useful
:P |
| 21:48.05 |
brlcad |
nods |
| 21:48.09 |
brlcad |
that would be
appreciated and useful |
| 21:48.15 |
brlcad |
if someone
continues that work |
| 21:49.02 |
mafm |
well, in fact
I already advised a few ppl under the hood :P |
| 21:50.18 |
mafm |
brlcad: if my
apps go bad, maybe I can sign up officially as mentor too? melange
gods might provide... :) |
| 21:55.07 |
madant |
mafm, did u
see Malyce's error, i faintly remember having a similar problem (
quote, tick and unnecessary characters :D ) in debian long back..
it disappeared of course .. it might be a debian bug |
| 21:56.07 |
mafm |
madant: can't
remember, I did have problems last year but it was for another
reason (autotools version or similar) |
| 22:01.01 |
brlcad |
mafm: nope,
not really possible unless you know before the 15th that you're
rejected from everywhere you applied and could get an admin to
remove your student status |
| 22:01.18 |
brlcad |
students
aren't announced until the 20th, so I suspect "no" :) |
| 22:03.04 |
mafm |
:/ |
| 22:03.19 |
mafm |
well,
unofficial mentor will do |
| 22:04.24 |
madant |
mafm: t-shirt
would be nice ;) |
| 22:04.43 |
hippieindamakin8 |
recounts that he sounded stupid talking abt the debian sid
compile without checking the complete
log/comment. |
| 22:04.56 |
starseeker |
dreeves: OK,
if it's helpful I've got some test nurbs shapes up at http://bzflag.bz/~starseeker/nurbs_tests.g
and a script to raytrace them all at http://bzflag.bz/~starseeker/nurbs_tests.sh
- should be a bit more of a workout than brep_simple
;-) |
| 22:05.22 |
brlcad |
thinks starseeker should implement tclget/put support
;) |
| 22:05.38 |
starseeker |
me too
:-) |
| 22:05.38 |
brlcad |
has to be
done eventually anyways, now there's actually a compelling reason
;) |
| 22:05.52 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 22:06.32 |
starseeker |
should also go to the gym, and since that closes that'll have
to be first... |
| 22:06.38 |
mafm |
madant: well,
that's a shame, yes |
| 22:07.01 |
Malyce |
do you guys
know brlcad's email ? |
| 22:07.13 |
Malyce |
I could just
send my compile pastebin's to him |
| 22:07.22 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-146-147.3g.claro.net.br) |
| 22:07.26 |
starseeker |
he can see
them on pastebin.bzflag.bz |
| 22:07.47 |
starseeker |
or are they
too big for it? |
| 22:07.49 |
Malyce |
shouldn't I
send him the urls ? |
| 22:07.57 |
``Erik |
say the URL
in channel |
| 22:08.06 |
``Erik |
it may be
possible that someone else coudl help you, too... O.o |
| 22:08.10 |
Malyce |
http://pastebin.bzflag.bz/m52ab321c |
| 22:08.15 |
Malyce |
http://pastebin.bzflag.bz/m393a0eda |
| 22:08.25 |
Malyce |
I did that,
like half an hour ago, remember ? |
| 22:09.06 |
Malyce |
Besides, I
don't have access to that machine anymore right now |
| 22:09.17 |
``Erik |
sh -xe
libtoolize -a -c <-- would probably tell ya a lot
more |
| 22:09.19 |
``Erik |
:D |
| 22:09.21 |
Malyce |
If somebody
can tell me what went wrong, I'll try it out |
| 22:09.41 |
Malyce |
ok |
| 22:09.54 |
Malyce |
This was me
building on Ubuntu |
| 22:10.00 |
Malyce |
I also did it
on Cygwin |
| 22:10.10 |
Malyce |
There,
autogen.sh went without a hitch |
| 22:10.18 |
Malyce |
but,.. |
| 22:10.21 |
louipc |
hehehe try to
get it working on ubuntu first |
| 22:10.29 |
brlcad |
Malyce: yet
again, one of the downsides of not using 'screen' to stay on irc ..
I commented on your pastebin while you were gone |
| 22:10.39 |
Malyce |
oh |
| 22:10.44 |
Malyce |
rats |
| 22:10.55 |
Malyce |
It was a
different machine |
| 22:11.06 |
``Erik |
if you auto*
on cygwin, the resultant may possibly not be ok for a
leenewx |
| 22:11.12 |
brlcad |
haven't seen
that specific problem before, but you can try to run exactly what
autogen.sh is running to see why (like try what ``Erik
suggested) |
| 22:11.32 |
Malyce |
ok |
| 22:11.42 |
``Erik |
also; you
could try googling the issue, surely this isn't the only place it's
existed :D I see an ubuntu link when I chuck it in
google... |
| 22:11.47 |
Malyce |
and just that
one command will do the same ? |
| 22:11.52 |
brlcad |
only thing I
can think of is the "-I m4" is confusing that version of
libtoolize |
| 22:12.07 |
louipc |
:D |
| 22:14.00 |
Malyce |
Can I ask
about the Cygwin build ? I don't have immediate access to the
Ubuntu machine, will get it soon |
| 22:15.33 |
Malyce |
http://pastebin.bzflag.bz/m6cb9d321 |
| 22:15.44 |
brlcad |
starseeker:
if you serialize the BREP similar to what 'l' outputs but just
using a shorthand single-letter notation, you can get
tclget/adjust/form for free |
| 22:15.46 |
Malyce |
Although
autogen.sh runs without a hitch, configure dies on me |
| 22:16.18 |
brlcad |
see
rt_ell_parse[] in src/librt/primitives/ell/ell.c for an
example |
| 22:16.24 |
``Erik |
awesome |
| 22:16.40 |
brlcad |
you'd have to
have vars for the entity count, then other vars for values for each
entity type |
| 22:16.58 |
brlcad |
pretty huge
table, but should be less than 52 entities I'd think |
| 22:17.13 |
brlcad |
(not that
they need to be short, but is consistent) :) |
| 22:17.29 |
starseeker |
ok
:-) |
| 22:18.02 |
brlcad |
otherwise
you'll have to find a compressed shorthand to store, maybe
openNURBS has a text serialization routine |
| 22:18.17 |
brlcad |
probably
easier to define the table |
| 22:21.51 |
Malyce |
hints
? |
| 22:23.12 |
brlcad |
ehm, what
erik said to try |
| 22:23.17 |
brlcad |
basically run
the steps manually |
| 22:23.38 |
brlcad |
see what's
breaking, see if the options make sense with that version of the
tool's documentation |
| 22:23.46 |
Malyce |
I will try
that out in a couple hrs, when I get to steal the machine
back |
| 22:24.01 |
Malyce |
but I was
also asking for the Cygwin build |
| 22:24.10 |
Malyce |
that's the
last pastebin i posted |
| 22:24.20 |
Malyce |
autogen.sh
ran fine there |
| 22:24.33 |
Malyce |
./configure
--without-x11 broke down |
| 22:25.03 |
``Erik |
um, cygwin is
gonna try to look like unix, which'll make configure need
x11 |
| 22:25.14 |
brlcad |
try running
./autogen.sh --verbose, see if there are any warnings |
| 22:25.18 |
``Erik |
cygwin should
have all the right x11 crap with it |
| 22:25.55 |
brlcad |
otherwise,
read the configure script and see what looks wrong -- it's a shell
script, those are errors near the very beginning of the
file |
| 22:26.01 |
``Erik |
feel free to
make configure.ac grok cygwin and try to do the right thing, but I
suspect that'd require fixing tcl/tk |
| 22:26.02 |
``Erik |
:D |
| 22:26.15 |
``Erik |
(and yes,
those broken lines are setting the version info) |
| 22:27.23 |
Malyce |
well, 15th
time's the charm (crosses fingers and toes) |
| 22:27.43 |
louipc |
haha |
| 22:30.56 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34173 10/brlcad/trunk/src/conv/intaval-g.py:
don't assume that pythong is /usr/bin/python, use /usr/bin/env to
find it |
| 22:32.46 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34174 10/brlcad/trunk/ (INSTALL m4/Makefile.am
m4/python.m4 m4/sdl.m4): Remove python.m4 and sdl.m4 |
| 22:37.36 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r34175 10/brlcad/trunk/src/adrt/libtienet/
(Makefile.am g-adrt.c): start putting in g-adrt |
| 22:38.54 |
``Erik |
hopes he busted it all up good 'nuff to piss some people off
:D |
| 23:01.11 |
Malyce |
in Arb8.cpp,
the number of vertices is a size_t type. Would it be ok, for me to
simply typecast it to int ? |
| 23:01.19 |
Malyce |
in
CoreInterfaces |
| 23:06.10 |
mafm |
what
for? |
| 23:06.20 |
Malyce |
I want to
pass it to other functions |
| 23:06.37 |
Malyce |
I guess it
should be ok. number of vertices has to be an integer |
| 23:06.55 |
mafm |
do you know
what a size_t is? :) |
| 23:07.05 |
Malyce |
its what you
get from sizeof |
| 23:07.11 |
Malyce |
size in
bytes |
| 23:07.21 |
Malyce |
oh
shoot |
| 23:07.35 |
Malyce |
sorry, (conks
himself on the head) |
| 23:08.34 |
mafm |
actually,
using int is better than an unsigned int sometimes |
| 23:08.47 |
mafm |
but size_t is
the type used for indexes and the like |
| 23:08.50 |
Malyce |
here, it has
to be an integer |
| 23:09.06 |
Malyce |
I haven't
seen it being used outside of sizeof |
| 23:09.13 |
mafm |
unsigned int,
32 bits in 32 bit architectures, 64 in 64 bits |
| 23:09.15 |
Malyce |
why
? |
| 23:09.23 |
``Erik |
not
always |
| 23:09.45 |
mafm |
well, because
it's the number of elements that you can address |
| 23:09.47 |
``Erik |
some 64b
archs make a uint32_t when you say unsigned int |
| 23:10.11 |
Malyce |
is it ok for
me to typecast it ? |
| 23:10.31 |
Malyce |
numerically,
it will be the same. integer to integer |
| 23:10.44 |
Malyce |
value won't
change |
| 23:10.56 |
mafm |
``Erik: I
mean size_t, that it's defined as an unsigned int(eger) of 32 or
64, not literal "typedef unsigned int size_t" :) |
| 23:11.45 |
mafm |
Malyce: you
might even change the original, but probably who did that created
it size_t for a reason |
| 23:11.52 |
``Erik |
isn't sure where/what malyce means, sees no function name or
line number or anything |
| 23:12.39 |
mafm |
I doubt
you'll have more than INT_MAX number of vertices in a given thingy,
so it should be safe, but don't take my word as law :) |
| 23:13.22 |
``Erik |
if it's used
as an offset or pointer, might run into issues past the 4gb mark,
though... |
| 23:13.22 |
Malyce |
size_t
NumberOfVertices(void) const throw(); |
| 23:13.34 |
Malyce |
I don't think
so |
| 23:14.09 |
``Erik |
ahhhhhh, in
rt^3, ok |
| 23:14.10 |
Malyce |
the
corresponding Arb8.c comments say (rt_arb_std_type), that return
should be 0-8 |
| 23:14.29 |
Malyce |
so, the
return value will be 0-8, irrespective of size_t or int |
| 23:14.36 |
Malyce |
just being
cautious |
| 23:16.31 |
mafm |
Malyce: the
point is that maybe it makes more sense that you use size_t in your
code, or maybe it doesn't matter if you use different types, it's
hard to say for me :) |
| 23:16.48 |
``Erik |
hrm, the
function used to fill ret is returning a regular old int
:/ |
| 23:17.50 |
mafm |
I prefer to
use the same types everywhere instead of casting, but I don't know
if this is carefully maintained in coreInterface or not (according
to what ``Erik says, it seems not :) ) |
| 23:18.05 |
Malyce |
I don't know
why it wasn't typecasted in the function itself, that's my
point |
| 23:18.34 |
Malyce |
But, I do
*need* to typecast it to use it elsewhere, no choice
there |
| 23:18.46 |
Malyce |
wanted to
know the side effects |
| 23:18.52 |
``Erik |
doesn't know, would ask DRoßerg |
| 23:18.53 |
mafm |
why? the
compiler should issue a warning, not an error |
| 23:19.17 |
Malyce |
k, will ask
DRossberg |
| 23:19.19 |
``Erik |
~seen
drossberg |
| 23:19.24 |
ibot |
i haven't
seen 'drossberg', ``Erik |
| 23:19.37 |
mafm |
anyway,
casting from size_t to int won't cause problems unless you pass the
2GB barrier :) |
| 23:19.49 |
mafm |
~seen
d_rossberg |
| 23:19.50 |
ibot |
d_rossberg
<n=rossberg@bz.bzflag.bz> was last seen on IRC in channel
#brlcad, 4d 14h 43m 58s ago, saying: 'i.e. the student should not
be able to see it'. |
| 23:20.07 |
Malyce |
so it won't
be an issue, since the return is known to be between
0-8 |
| 23:20.18 |
mafm |
that would be
correct |
| 23:20.23 |
Malyce |
cool |
| 23:20.36 |
``Erik |
or negative
on error |
| 23:20.37 |
``Erik |
? |
| 23:20.43 |
Malyce |
hihi |
| 23:21.18 |
mafm |
in C++ you
can use: int blah = static_cast<int>(teh_var); |
| 23:21.50 |
mafm |
``Erik: if
the signature of the function is size_t, returning a negative
number is kind of a ... bad design, I guess |
| 23:21.57 |
``Erik |
yeh |
| 23:22.07 |
mafm |
is kind ->
would be :) |
| 23:22.08 |
``Erik |
well, it's
signed int in librt |
| 23:22.44 |
madant |
Malyce,
things are much better understood with a short code excerpt @
pastebin showing what u want to do :) |
| 23:22.50 |
mafm |
so maybe it's
the signature of the function in CoreInterface which slightly
wrong |
| 23:23.12 |
mafm |
+1
madant |
| 23:23.30 |
``Erik |
*shrug* shoot
daniel an email or try to catch him on irc, he may've had a reason
for doing it that way, I d'no :) |
| 23:24.54 |
mafm |
or shoot him
directly, then ask :) |
| 23:25.12 |
Malyce |
Panda: an
animal that eats, shoots and leaves |
| 23:25.16 |
madant |
thinks using size_t for denoting the "size" of things - arity
of a function, number of points in a primitive etc. etc. - is just
pedantic :D |
| 23:26.17 |
``Erik |
I'd argue
more misleading than pedantic... size_t insinuates some relation to
pointers 'n stuff, no? |
| 23:26.27 |
mafm |
would say yes |
| 23:27.05 |
Malyce |
http://pastebin.bzflag.bz/d5d2fe1cd |
| 23:27.21 |
Malyce |
just a small
something i was experimenting |
| 23:27.52 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-169-90.3g.claro.net.br) |
| 23:28.15 |
Malyce |
I should have
commented it |
| 23:29.43 |
Malyce |
http://pastebin.bzflag.bz/d3ca55d6d |
| 23:29.48 |
Malyce |
commented
version |
| 23:30.22 |
``Erik |
hrmmmm |
| 23:31.44 |
mafm |
Malyce: ret
might be uninitialized |
| 23:31.51 |
mafm |
and returned
as such |
| 23:32.25 |
Malyce |
I thought
that |
| 23:32.28 |
``Erik |
that centroid
func doesn't quite smell right to me |
| 23:32.34 |
Malyce |
I should make
it =0; |
| 23:32.49 |
``Erik |
hrm, guess it
is heh |
| 23:32.58 |
``Erik |
must be tired |
| 23:33.10 |
Malyce |
I thought so
too. It has to be *heh* |
| 23:33.14 |
Malyce |
I knew
it |
| 23:33.44 |
mafm |
Malyce: also,
in C++ you can declare "npoints" in the same place: int npoints =
(int) NumberOfVertices(); |
| 23:34.41 |
mafm |
if you're not
going to use it outside that scope, that is :) |
| 23:35.01 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 23:35.10 |
mafm |
well, I go to
bed now, take care gentlemen (and ladies? :) ) |
| 23:35.15 |
mafm |
night |
| 23:35.18 |
Malyce |
good
nigt |
| 23:35.25 |
Malyce |
sweet
dreams |
| 23:35.25 |
``Erik |
later,
mafm |
| 23:36.27 |
Malyce |
oh, I
remembered |
| 23:36.38 |
Malyce |
the reason I
did not initialise ret = 0; |
| 23:36.57 |
Malyce |
its a point_t
type. I don't know what that looks like |
| 23:37.15 |
Malyce |
*investigates* |
| 23:38.39 |
``Erik |
typedef
fastf_t point_t[4]; |
| 23:38.40 |
``Erik |
or
so |
| 23:39.09 |
``Erik |
fully
resolved out to typedef double point_t[4]; |
| 23:39.31 |
Malyce |
I can
understand the first 3, but what do you do with double no. 4
? |
| 23:39.45 |
``Erik |
xyzw |
| 23:39.46 |
Malyce |
x,y,z,? |
| 23:39.50 |
Malyce |
ahahaha |
| 23:39.57 |
Malyce |
seriously,
what is w ? |
| 23:40.08 |
``Erik |
homogenous
coordinates |
| 23:40.31 |
Malyce |
so it is the
index of the local coords being used ? |
| 23:40.38 |
Malyce |
coord sys
that is |
| 23:42.58 |
Malyce |
where is this
defined ? |
| 23:44.47 |
madant |
``Erik, mafm
:) yeah maybe misleadingly pedantic :P |
| 23:44.51 |
Malyce |
uh, I think
it is only three points |
| 23:44.57 |
Malyce |
#define
ELEMENTS_PER_POINT3 |
| 23:45.28 |
Malyce |
typedef
fastf_tpoint_t[ELEMENTS_PER_POINT]; |
| 23:46.10 |
madant |
off to a 5km run |
| 23:46.40 |
``Erik |
okie, sorry,
was thinking hvect_t |
| 23:46.44 |
``Erik |
too used to
opengl O:-) |
| 23:48.55 |
Malyce |
so, I
initialize it to {0,0,0}, origin, is okie ? |
| 23:50.15 |
``Erik |
should
be |
| 23:50.37 |
``Erik |
VSET(ret,0,0,0); :D |
| 23:50.46 |
``Erik |
VSETALL(ret,0); |
| 23:51.00 |
Malyce |
useful. will
keep that in mind |
| 23:51.19 |
``Erik |
(just in case
we go turn all that stuff into simd stuff some day) |
| 23:51.37 |
Malyce |
how so
? |
| 23:53.16 |
Malyce |
how is that
useful, in parralel processing ? |
| 23:55.27 |
Ralith |
scatter
instruction support? |
| 23:55.29 |
Malyce |
ugh,
parallel |
| 23:55.56 |
Malyce |
so, all the
user defined ops are already there ? |
| 23:55.58 |
Malyce |
ahhh |
| 23:56.10 |
Ralith |
what? |
| 23:56.32 |
Malyce |
when you use
scatter/gather instructions, you can give it user defined
operations to perform |
| 23:56.51 |
Malyce |
collective
operations |
| 23:57.06 |
Malyce |
i take it
that is what you meant |
| 00:34.03 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:46.19 |
yukonbob |
hi,
cadheads |
| 00:57.25 |
CIA-40 |
BRL-CAD:
03starseeker * r34176 10/brlcad/trunk/doc/docbook/system/man1/en/
(6 files): Add debug* MGED command docbook man pages (Janine and
Cliff) |
| 01:00.01 |
*** join/#brlcad tessier_
(n=treed@kernel-panic/sex-machines) |
| 01:00.03 |
tessier_ |
WOW |
| 01:00.23 |
tessier_ |
I've known
about brl-cad for many years. Since the mid-90's I
think. |
| 01:00.36 |
tessier_ |
It has always
languished in obscurity. Glad to see it is finally taking
off! |
| 01:01.02 |
starseeker |
:-) |
| 01:01.06 |
starseeker |
open source
helps that |
| 01:01.52 |
starseeker |
tessier_: did
you ever use it? |
| 01:01.56 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 01:02.12 |
tessier_ |
I compiled it
once. Fired it up. No no clue wtf I was doing. Never touched it
again. |
| 01:02.18 |
tessier_ |
Had no
clue |
| 01:02.39 |
``Erik |
kebert
xela |
| 01:02.55 |
``Erik |
academic,
gov't or industry, tessier? :) |
| 01:03.33 |
``Erik |
(supposedly
we had a couple thousand registered sites before going open
source) |
| 01:05.41 |
dreeves |
starseeker
thanks I will take a look |
| 01:09.19 |
tessier_ |
I am in what
you would call industry |
| 01:13.20 |
``Erik |
I think the
only industry chunks where BRL-CAD got serious traction before
going open sources defense |
| 01:25.30 |
CIA-40 |
BRL-CAD:
03starseeker * r34177 10/brlcad/trunk/doc/docbook/system/man1/en/
(Makefile.am decompose.xml delay.xml dm.xml): Add the rest of the
d* MGED command docbook man pages (Janine and Cliff) |
| 01:39.48 |
AlexandreGuedes |
brlcad |
| 01:41.48 |
AlexandreGuedes |
I can answer
the comment about the my project there ? |
| 02:20.03 |
madant |
AlexandreGuedes, you can use the channel
for discussion, response to the comment or otherwise , and you can
post a response comment at the application as well , i think
:) |
| 02:41.45 |
``Erik |
(don't ask to
ask, brlcad will read the backlog. and http://www.catb.org/~esr/faqs/smart-questions.html
:) |
| 03:06.36 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 03:35.18 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:35.43 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 03:57.00 |
*** join/#brlcad madant_
(n=madant@117.196.132.145) |
| 04:25.43 |
*** join/#brlcad piksi_ (i=piksi@pi-xi.net) |
| 04:37.48 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-143-51.3g.claro.net.br) |
| 04:58.50 |
*** join/#brlcad andrecastelo_
(n=Andre_Ca@189.71.32.30) |
| 05:24.30 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 05:39.24 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177726493.dsl.bell.ca) |
| 06:54.20 |
CIA-40 |
BRL-CAD:
03ddreeves70 * r34178
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 06:54.20 |
CIA-40 |
BRL-CAD:
fixed a bug that was causing some error points in the hit point
list returned. |
| 06:54.20 |
CIA-40 |
BRL-CAD: I
wasn't initializing the hit bool in the intersect function. This
was causing |
| 06:54.20 |
CIA-40 |
BRL-CAD: at
random times for the ray origin to show up on the hit point
list. |
| 06:56.03 |
dreeves |
good news I
was able to get rid of the big ole hack in shot found the bug that
was causing that. I think the main issue is lack of trimming
now |
| 06:56.51 |
brlcad |
lack of
trimming? |
| 06:56.58 |
brlcad |
it's trimming
from the looks of things |
| 06:57.07 |
brlcad |
dreeves: did
you get the sample breps? |
| 06:57.43 |
dreeves |
yes I have
raytraced some it is handing them much better with the bug
fix |
| 06:58.05 |
dreeves |
Although
there is still issues but I think those are because of the lack of
trimming |
| 06:58.29 |
dreeves |
The box had
no problems |
| 06:58.42 |
dreeves |
the cone hit
some issues about mid way up |
| 07:00.26 |
dreeves |
I haven't
converted the trimming code over yet |
| 07:01.13 |
brlcad |
okay, hrm..
looked like you had |
| 07:01.18 |
dreeves |
I have
started but I'm still matching up how open nurbs stores trims vs
the utah code |
| 07:02.21 |
dreeves |
No I think if
I had that working we would have fully functional nurbs
raytracer |
| 07:02.38 |
dreeves |
because I
think most everything else is extremely close |
| 07:03.21 |
brlcad |
thoughts on
the tolerance issues? |
| 07:03.47 |
brlcad |
I mean the
issue of having to hard-code tolerances for this given set of
inputs, then find a different set of inputs where those tolerance
assumptions are no longer valid, for example |
| 07:07.16 |
brlcad |
dreeves: by
the way, very impressive progress |
| 07:07.19 |
brlcad |
to say the
least |
| 07:08.17 |
dreeves |
I think I
need to think that a bit because I messed with that a little and
didn't get the results I expected I set aside for the time to focus
on the big ole hack because that was really bothering
me |
| 07:08.31 |
dreeves |
thanks brlcad
it is cool to work on this |
| 07:09.19 |
brlcad |
it's nice to
see someone that can just jump in and make progress, I can't even
mentally make the context switch to dig into that code without
getting a lot of other things off my plate |
| 07:09.22 |
dreeves |
It's alot of
fun |
| 07:09.34 |
brlcad |
which hasn't
happened in a long while, and as such progress has been very very
slow |
| 07:10.34 |
dreeves |
Well I think
think the things you are doing are every bit as valuable to this
project |
| 07:11.28 |
dreeves |
It has been a
little while but it seems I'm getting into the swing of
it |
| 07:11.59 |
dreeves |
In fact
without some of the things you are doing there would be no project
for me to have this fun with thanks!! |
| 07:12.05 |
CIA-40 |
BRL-CAD:
03brlcad * r34179 10/brlcad/trunk/AUTHORS: note the recent code
contributions from dreeves. he's been working on the nurbs/brep
ray-tracing, woot |
| 07:12.26 |
brlcad |
oh I'm not
downplaying anything I do, just that haven't made much progress on
that task :) |
| 07:12.41 |
brlcad |
which does
get frustrating, of course, even when I know it's for other reasons
;) |
| 07:12.59 |
dreeves |
Yeah I can
understand that |
| 07:13.34 |
brlcad |
just like
it's frustrating that we don't have a new gui yet, but I knew 8
years ago that it would take a long while to get everything in
place (and it's finally starting to come together
maintainably) |
| 07:13.42 |
dreeves |
You seem to
be working day an night on your stuff |
| 07:13.59 |
brlcad |
pretty much,
love it ;) |
| 07:14.26 |
brlcad |
which reminds
me.. would be cool to run the speckle activity graph
again |
| 07:14.28 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:14.38 |
brlcad |
given it's
been several years since the last time |
| 07:14.43 |
dreeves |
Yeah as you I
am very interested in the gui. I don't know if you or not but my
start I was a modeler |
| 07:15.06 |
brlcad |
nods |
| 07:15.26 |
dreeves |
so quite abit
of experience with the "gui" |
| 07:16.46 |
brlcad |
the bigger
issue with evolving brl-cad's modeling interface is doing so in a
way that improves the interface without pissing off current expert
modelers, which generally involves lots and lots of small
incremental changes and even more refactoring |
| 07:17.14 |
brlcad |
that's the
part that I seem to enjoy a lot of, refactoring the codebase into
reusable organized sections |
| 07:17.28 |
dreeves |
Yeah I fight
that problem all the time trust me. |
| 07:17.48 |
brlcad |
mged's
finally at the point where we have most of its "meat" out of it now
and into a library |
| 07:18.00 |
brlcad |
that took
about a year and a half of almost non-stop effort by
bob |
| 07:18.04 |
brlcad |
and
others |
| 07:18.19 |
yukonbob |
listens in... |
| 07:18.38 |
dreeves |
Yeah I
remember way when hacking mged code to add commands |
| 07:18.40 |
brlcad |
archer is a
good refactoring that fixes many of the bigger fuglinesses in mged,
it will be nice to see those two merge |
| 07:18.58 |
brlcad |
adding new
mged commands is still fun (and now even easier than ever)
;) |
| 07:19.22 |
brlcad |
still more
work needed on libged, but it's definitely coming together as a
stateless command API |
| 07:19.35 |
dreeves |
Yeah arch
definitely seems like a step up but I think in the end it is
important for the interface to get more intuitive |
| 07:19.59 |
brlcad |
need a few
new facilities like active selection sets, but then it should be
fully quasi-modeless |
| 07:20.21 |
brlcad |
sure, archer
is just one of those incremental steps |
| 07:21.00 |
dreeves |
You know
something to think about would be how to you encapsulate all the
behavior associated with a primitive |
| 07:21.11 |
brlcad |
that gives
current modelers their same commands, familiar terminology, and
similar options, but still shocks them with window management and
extra information panels (hierarchy views, edit panels, single
window default views, etc) |
| 07:21.44 |
brlcad |
they're
pretty much encapsulated as it is minus a few rogue commands that
still need to be pushed up into librt |
| 07:22.31 |
brlcad |
95% of a
primitive is in a dir in src/librt/primitive/ with the callback
table for each 'method' of interest |
| 07:22.38 |
dreeves |
what I'm
talking about is a primitive knows everything about itself how to
rt, how to read, write and edit |
| 07:23.01 |
brlcad |
that's what
it does now |
| 07:23.17 |
dreeves |
Really |
| 07:23.35 |
dreeves |
I thought
editing behavior was in libged and rt was in librt? |
| 07:23.40 |
brlcad |
yeah, that's
the callback table I was referring to |
| 07:24.07 |
brlcad |
there's a
hook for prep, shot, read, write, describe, plot, ... etc, about 20
different things that defines a primitive |
| 07:24.48 |
dreeves |
agreed librt
definitely has most but appears to lack the hooks for editing?? but
again I could definitely be missing something |
| 07:25.27 |
brlcad |
the 5% that
isn't in there are the bits that need to be refactored and pushed
up as another hook or two, which includes things like 'mirror'
(specific copy contructor), 'typein' (well-defined explicit
constructor), and 'make' (default constructor) |
| 07:25.41 |
brlcad |
yeah, editing
is in that 5% -- it's actually not a lot of hooks |
| 07:25.43 |
dreeves |
oh
ok |
| 07:27.05 |
brlcad |
the biggest
thing presently lacking is object validation as a specific callback
routine |
| 07:27.12 |
brlcad |
right now
that happens during the prep() callback for raytracing |
| 07:27.20 |
brlcad |
or for some
primitives during read/write |
| 07:27.31 |
brlcad |
but not as a
specific callback in itself |
| 07:27.35 |
brlcad |
that is
needed |
| 07:27.51 |
dreeves |
how do you do
the * dreeves nods in irc |
| 07:27.54 |
brlcad |
that's
related to the parametric constraint support too |
| 07:28.27 |
brlcad |
shows dreeves how to use "/me shows dreeves how to use
/me" |
| 07:28.46 |
dreeves |
nods |
| 07:28.50 |
dreeves |
ah
ok |
| 07:28.52 |
dreeves |
thanks |
| 07:28.55 |
brlcad |
np |
| 07:30.08 |
dreeves |
Yeah I have
been nosing around a little in what is going on with the libged
stuff but for the most part trying to focus on this brep
stuff |
| 07:30.32 |
dreeves |
seems like
plenty of people focusing on mged currently |
| 07:30.53 |
brlcad |
nothing
complicated, literally a straightforward refactoring of all
commands in mged to make them a single argc/argv style
function |
| 07:31.20 |
brlcad |
but that in
itself requires/required rewriting *many* of the commands to make
them work stateless and to work without Tcl |
| 07:31.39 |
dreeves |
Yeah that was
what I was about ask |
| 07:32.09 |
brlcad |
entailed
refactoring about 100k-150k lines of code |
| 07:32.54 |
brlcad |
just to get
them into the simple form they are now of
ged_[command]() |
| 07:35.13 |
dreeves |
so if memory
serves me right wasn't the original commands in the whole argc/argv
form (not factored out but in that form within mged) |
| 07:37.58 |
brlcad |
they were
already 'mostly' in an argc/argv form but they weren't
stateless |
| 07:38.25 |
brlcad |
many/most of
them were tightly integrated with mged's various global state
objects and edit modes |
| 07:39.04 |
brlcad |
so they would
just set flags and expect things to happen or add things to some
random global, etc |
| 07:39.07 |
dreeves |
yeah that is
definitely true I remember |
| 07:39.23 |
brlcad |
very ugly in
some places |
| 07:39.33 |
dreeves |
I remember
that made things tough on a young programmer |
| 07:39.34 |
brlcad |
most of that
is *much* more clean now |
| 07:39.53 |
brlcad |
the commands
get passed a "working set" of objects and views to work
on |
| 07:40.14 |
brlcad |
they fill out
results for that working set |
| 07:40.21 |
dreeves |
Yeah thats
cool |
| 07:40.31 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:40.31 |
brlcad |
de-coupling
tcl was the other big task |
| 07:40.52 |
dreeves |
Yeah I
imagine that was a very big task |
| 07:41.05 |
brlcad |
but that was
mostly changing a lot of function calls from
tcl-things-that-does-something-like-printf to a
bu-routine-that-does-something-like-printf |
| 07:41.14 |
brlcad |
not tricky
logic-wise |
| 07:41.26 |
brlcad |
just
thousands of lines of code in mostly non-scriptable
ways |
| 07:41.30 |
brlcad |
tedious |
| 07:41.44 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:41.47 |
dreeves |
I was going
to say that sounds very very tedious |
| 07:42.09 |
dreeves |
take a
special kind of person or people to do that |
| 07:42.16 |
brlcad |
yeah |
| 07:42.39 |
dreeves |
Has Ed seen
the progress on the brep stuff? |
| 07:43.07 |
brlcad |
absolutely |
| 07:43.14 |
brlcad |
pretty
exciting |
| 07:43.28 |
dreeves |
Yeah I didn't
know if he had seen it yet |
| 07:43.39 |
dreeves |
He really
helped get me set on the right path |
| 07:43.42 |
brlcad |
yeah, we've
talked about it several times, yesterday included |
| 07:44.01 |
dreeves |
talking to me
on the phone the other day |
| 07:44.06 |
brlcad |
yeah, he told
me |
| 07:44.24 |
dreeves |
saved me a
lot of retrenching time |
| 07:46.32 |
dreeves |
Ok I'm
rerunning the test cases I had forgotten that I had uncommented the
incomplete trimming code so bunch of blank images |
| 07:47.21 |
dreeves |
needs to check to see if he committed that
code |
| 07:49.11 |
dreeves |
hey you want
me to send you the images or post them on the mailing
list? |
| 07:49.37 |
brlcad |
heh, saw
that |
| 07:49.46 |
brlcad |
you did,
commented it out |
| 07:50.22 |
brlcad |
mailing list
posts are almost always better (to brlcad-devel unless you clean it
up as a 'preview' for the unwashed user masses) |
| 07:50.39 |
brlcad |
just so it
hits more eyes |
| 07:50.51 |
dreeves |
yeah I just
checked |
| 07:50.55 |
brlcad |
another
option is to set up some development progress page on the wiki and
post a link to that to brlcad-devel |
| 07:51.39 |
dreeves |
that would be
cool I will admit I don't know how to do that though |
| 07:52.08 |
dreeves |
I could
probably figure it out if you tell me I have the capability from a
permission stand point |
| 07:52.17 |
yukonbob |
!! clock!
Haven't seen him in ages... |
| 07:52.31 |
brlcad |
dreeves: you
do, the wiki is wide open |
| 07:53.03 |
brlcad |
should create
an account on the wiki just so you don't have to keep answering a
captcha, but from there it's very simple |
| 07:53.14 |
brlcad |
just like
editing wikipedia |
| 07:54.02 |
brlcad |
basically,
would probably start by editing this page and adding a link to a
new brep/nurbs page: http://brlcad.org/wiki/Developer_Documents |
| 07:55.12 |
brlcad |
you can use
another dev page (like http://brlcad.org/wiki/Revolve_Primitive
) as an example |
| 07:55.33 |
brlcad |
maybe
http://brlcad.org/wiki/BREP_Primitive
for that matter |
| 07:57.14 |
dreeves |
ok I will
give it a go |
| 08:04.52 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1356
10/wiki/FAQ: what does BRL mean? |
| 08:07.07 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1357
10/wiki/FAQ: how do you pronounce brl-cad |
| 08:07.35 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 08:10.00 |
CIA-40 |
BRL-CAD:
03brlcad * r34180 10/brlcad/trunk/doc/description.txt: unacceptible
is unacceptable |
| 08:10.44 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1358 10/wiki/Developer_Documents: |
| 08:13.04 |
CIA-40 |
BRL-CAD:
03brlcad * r34181 10/brlcad/trunk/doc/description.txt: gah, more
non-acceptablisms |
| 08:14.16 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1359 10/wiki/BREP_Primitive: New page: {{DesignDocument}} =
Overview = More to follow just starting this page. Will try to
populate all the sections tomorrow with status of the work on BREP.
= Internal Representation = = ... |
| 08:15.19 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1360
10/wiki/FAQ: how to spell brl-cad |
| 08:18.26 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Box.png]]": BREP
Box in the nurb_tests.g that was provided to me by
starseeker. |
| 08:20.36 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1362 10/wiki/BREP_Primitive: |
| 08:21.47 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep Cone.png]]":
Brep of a cone provide in the nurbs test by starseeker |
| 08:24.13 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1364 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 08:25.56 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1365 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 08:27.40 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Cylinder.png]]" |
| 08:28.21 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1367 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 08:28.40 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1368 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 08:30.10 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
dentedSphere.png]]" |
| 08:30.23 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r1370
10/wiki/FAQ: what is brl-cad and what license do we
use? |
| 08:31.08 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Pipe.png]]" |
| 08:31.59 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Torus.png]]" |
| 08:33.39 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1373 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 08:34.50 |
dreeves |
brlcad I have
them posted I suppose I will go send a message on the mailing
list |
| 08:35.16 |
dreeves |
More work
todo on that page plus more images but I need to grab a few hours
sleep |
| 08:40.03 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 08:41.02 |
brlcad |
dreeves:
sounds good |
| 08:41.30 |
brlcad |
looks good
too |
| 08:45.09 |
dreeves |
ok I also
sent mail to the mailing list but I haven't seen it show up
yet |
| 08:46.19 |
dreeves |
brlcad I
really like the pipe and the torus...although on the torus I see a
few spots but I can think I could bump the tolerance and get rid of
those but right now I want to focus on trimming I will get back to
that in due time |
| 09:39.56 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:40.51 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:40.57 |
mafm |
hi |
| 09:41.33 |
hippieindamakin8 |
hey
mafm |
| 10:02.28 |
brlcad |
dreeves:
yeah, the pipe is particularly impressive |
| 10:02.38 |
brlcad |
it has some
acne problems as well on one of the tips |
| 10:02.45 |
brlcad |
probably
trimming related |
| 10:10.27 |
dreeves |
I think I
have the others look good now... I guess I'm not sure it is
trimming again for some reason I am getting an odd intersection
count. I just throw away the last intersection and it looks great.
However, the dented sphere will still probably messed up. Just
got think those issue shouldn't be cause by timming. Also bumped
the tolerance seemed to eliminate the acne |
| 10:19.43 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Cone.png]]" |
| 10:20.18 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Cylinder.png]]" |
| 10:21.56 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Torus.png]]" |
| 10:25.05 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Torus.png]]" |
| 10:25.50 |
dreeves |
brlcad when
you have a chance I have updated the images with the changes I
talked about |
| 10:27.43 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 10:28.16 |
CIA-40 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep dentedSphere.png]]" |
| 10:38.05 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-137-248.3g.claro.net.br) |
| 10:56.53 |
brlcad |
dreeves:
nice! definitely looking much better |
| 10:58.53 |
brlcad |
there are
still a variety of parity problems causing the acne, but it's
definitely getting reduced |
| 11:00.02 |
brlcad |
dented sphere
is particularly odd as the inner sphere seems to be inverted with
wrong normals |
| 11:00.51 |
brlcad |
the last bit
of acne on the pipe is probably a parity issue hitting that back
face |
| 11:01.00 |
dreeves |
Yeah some
strange things going on with that one. On a good note though I
think it is clear from the cylinder where we aren't
trimming |
| 11:01.30 |
dreeves |
So now I have
good test case for trouble shooting the trimming. So I think I
will get that fixed next then focus on the tolerance
issues |
| 11:01.39 |
brlcad |
cool |
| 11:01.54 |
brlcad |
goes to shower |
| 11:02.15 |
dreeves |
The utah
paper makes reference to particular watching the
tolerances |
| 11:05.01 |
CIA-40 |
BRL-CAD:
03ddreeves70 * r34182
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: more tweaking
of the tolerances in BREP |
| 11:05.34 |
*** join/#brlcad madant
(n=madant@117.196.134.214) |
| 11:40.20 |
*** join/#brlcad madant
(n=madant@117.196.129.147) |
| 12:03.03 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 12:46.49 |
*** join/#brlcad madant
(n=madant@117.196.135.83) |
| 12:49.43 |
*** join/#brlcad Malyce
(n=iamtanma@deimos.jacobs-university.de) |
| 13:01.40 |
Malyce |
I tried sh
-xe libtoolize -a -c |
| 13:01.56 |
Malyce |
gave me:
Can't open libtoolize |
| 13:02.48 |
Malyce |
also, stole a
machine with Vstudio 2008 |
| 13:02.56 |
Malyce |
where are the
VC proj files ? |
| 13:04.08 |
*** join/#brlcad dreeves_
(n=dreeves@67.130.253.14) |
| 13:04.34 |
Malyce |
the first
line was on a ubuntu machine, where autogen.sh was complaining that
libtoolize and autoreconf failed |
| 13:08.03 |
*** part/#brlcad dreeves_
(n=dreeves@67.130.253.14) |
| 13:08.39 |
*** join/#brlcad dreeves_
(n=dreeves@67.130.253.14) |
| 13:16.43 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:17.17 |
brlcad |
Malyce: for
what it's worth, I'm starting to get the impression that you don't
look for things very hard or for very long |
| 13:17.55 |
brlcad |
gsoc and open
source development in general really requires a lot of independent
thinking and problem solving skills |
| 13:18.59 |
Malyce |
I understand
what you mean |
| 13:19.11 |
_clock_ |
brlcad: do
you like gsoc? |
| 13:19.26 |
brlcad |
you really
should have absolutely no problem finding the vc proj files, and
you asking for them just shows that you either didn't look and was
looking for a quick answer or you sort of looked but didn't
immediately find it so you asked |
| 13:19.38 |
brlcad |
_clock_:
absolutely, it's a pretty great program |
| 13:19.42 |
Malyce |
i must be
missing something obvious |
| 13:19.48 |
Malyce |
its not in
the svn checkout |
| 13:19.54 |
Malyce |
and no
mention on the wiki |
| 13:20.00 |
Malyce |
or did i miss
something? |
| 13:20.01 |
brlcad |
it is in the
svn checkout |
| 13:20.23 |
brlcad |
how did you
look for it? |
| 13:20.42 |
brlcad |
randomly
browsing around directories isn't exactly effective on any large
codebase |
| 13:21.04 |
brlcad |
you have to
use an effective searching mechanism |
| 13:21.19 |
Malyce |
I looked on
the wiki first, when it wasn't obvious |
| 13:21.29 |
Malyce |
I found a
directory in /misc |
| 13:21.43 |
alex_joni |
Malyce: I
think I compiled brlcad once a couple years ago, but I don't really
follow it |
| 13:21.51 |
Malyce |
but there
doesn't seem to be a single .proj file, or am I wrong ? |
| 13:21.52 |
alex_joni |
still it took
me < 1 minute to find this:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/README.Windows?revision=28028&view=markup |
| 13:22.18 |
brlcad |
alex_joni:
yep, or barring that there is also google, which points you
straight to the file too |
| 13:22.41 |
brlcad |
if it's not a
lack of effort, it's a lack of process/tools |
| 13:23.43 |
brlcad |
and yes, part
of gsoc is certainly learning -- learning how to approach a task
and how to find things is an important skill |
| 13:24.37 |
Malyce |
i googled
'brl-cad building vc++ project' |
| 13:24.42 |
Malyce |
and then
looked on the wiki |
| 13:24.51 |
Malyce |
but yes, I am
incompetent |
| 13:25.03 |
Malyce |
but not for
lack of trying |
| 13:25.27 |
brlcad |
heh, not
incompetent |
| 13:25.58 |
brlcad |
just need to
hone those skills a bit, look a bit harder, bit more thorough until
you learn more |
| 13:26.03 |
alex_joni |
Malyce: don't
get discouraged immediately |
| 13:26.07 |
Malyce |
Right now, I
am sitting in front of three machines, trying to get this thing to
compile |
| 13:26.13 |
alex_joni |
it takes a
while to get used to the OSS way of doing things |
| 13:26.17 |
Malyce |
but I am new
to this |
| 13:26.36 |
alex_joni |
Malyce: I
think the most important skill one needs to bring is
patience |
| 13:26.40 |
Malyce |
if I am slow,
it is my inexperience |
| 13:26.54 |
Malyce |
but back to
the point, the readme mention MSVC6 and 7 |
| 13:27.06 |
Malyce |
the directory
has 8 and 9 |
| 13:27.15 |
alex_joni |
if you're
patient enough to read things before you jump ahead, sometimes it's
lots easier to get things working |
| 13:27.35 |
alex_joni |
Malyce: means
that document is probably outdated (you can see the last change
date ~2 years ago) |
| 13:27.38 |
Malyce |
It says that
it is possible to build on 8 |
| 13:27.49 |
brlcad |
for what it's
worth, "brl-cad building vc++ project" isn't a great search term --
vc++ won't match much and the other terms are pretty
general |
| 13:28.03 |
brlcad |
your original
query here was actually better, you called it vcproj |
| 13:28.04 |
Malyce |
right, what
should I have looked for ? |
| 13:28.15 |
Malyce |
I think I
looked for that too |
| 13:28.16 |
brlcad |
searching for
"brl-cad vcproj" probably would have been a lot more
effectiv |
| 13:28.42 |
Malyce |
or
not |
| 13:29.19 |
brlcad |
looks right
to me, the first links point you at misc/win32-msvc8 |
| 13:29.32 |
Malyce |
yes |
| 13:29.35 |
Malyce |
my
mistake |
| 13:29.38 |
brlcad |
down the
line, almost the entire page points to that dir |
| 13:29.42 |
Malyce |
yes |
| 13:30.12 |
Malyce |
makes sense
now |
| 13:31.14 |
brlcad |
Malyce:
really not trying to be hard on you, fwiw |
| 13:31.26 |
brlcad |
I do want you
to do better, for your sake and ours :) |
| 13:31.30 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 13:31.55 |
alex_joni |
brlcad: otoh,
I always fopund it helpful when new people come around and report
things that are not intuitive or easy to find |
| 13:32.10 |
alex_joni |
it's great to
get fresh eyes on something that feels natural to me... |
| 13:32.21 |
alex_joni |
especially
documentation |
| 13:32.46 |
brlcad |
it's a skill
like any other -- finding doc/README.Windows would have also
worked, which the README and INSTALL point you at (or at least one
of them does, iirc) -- which at least pushes you in the right
direction even with it being a little dated |
| 13:32.59 |
brlcad |
yeah, it's
useful feedback |
| 13:33.28 |
brlcad |
the windows
readme certainly needs updating, that was at least
uncovered |
| 13:34.03 |
Malyce |
you are
right, I am making too many noob mistakes |
| 13:34.05 |
brlcad |
and knowing
which of the 300 dirs in misc/win32-msvc8 dirs is the one to start
with |
| 13:34.20 |
brlcad |
though if you
read the list carefully, only one makes sense |
| 13:34.49 |
Malyce |
brl-cad |
| 13:35.15 |
brlcad |
bingo |
| 13:35.21 |
brlcad |
sans hypen of
course |
| 13:35.25 |
brlcad |
hyphen
even |
| 13:37.39 |
alex_joni |
that might be
even easier to find, if someone knows what a .sln file
is |
| 13:38.22 |
alex_joni |
"This is a
structure file for organizing projects in Microsoft Visual Studio.
It contains text-based information about the project environment
and project state." |
| 13:38.51 |
Malyce |
MSVS shows it
in the open dialog |
| 13:40.15 |
hippieindamakin8 |
brlcad, when
we discussed the thing that we take care of the changes in
topology, but the matter is that with approximate calculations one
very rarely hits the change in topology.For example: we are solving
for the intersection and we get new set of patches. it is not in
everycase that we encounter the degenerate casee |
| 13:40.30 |
hippieindamakin8 |
*casee/
case |
| 13:41.10 |
*** join/#brlcad madant
(n=madant@117.196.140.107) |
| 13:49.09 |
hippieindamakin8 |
and as a
matter of fact topology of each patch shall be computed according
to the steps mentioned.but i am just thinking would it be
absolutely necessary to have a data structure storing the
changes |
| 13:54.32 |
*** join/#brlcad PrezKennedy
(i=Matthew@208.43.126.194) |
| 14:05.27 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 14:13.29 |
Malyce |
Checking out
from, http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/,
doesn't get the CoreInterface .cpp files ? |
| 14:14.37 |
*** join/#brlcad piksi_
(i=piksi@83.145.207.200) |
| 14:21.50 |
Malyce |
The wiki says
that, that should check out the entire brl-cad, but the
CoreInterface files don't get checked out |
| 14:24.02 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 14:44.08 |
louipc |
what are
those? |
| 14:48.42 |
Malyce |
arb8.cpp,
Ellipsoid.cpp etc in
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt%5E3/trunk/src/coreInterface/
, I think I must have made a checkout mistake somehow. |
| 14:49.10 |
Malyce |
Arb8.cpp |
| 14:55.30 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 14:56.54 |
louipc |
you have to
checkout the rt^3 tree then |
| 14:57.33 |
louipc |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/ |
| 14:57.48 |
Malyce |
I was
thinking that. The wiki specifically says though that brlcad/brlcad
gives you everything |
| 14:58.47 |
louipc |
hmm what page
is that? |
| 14:59.12 |
Malyce |
https://brlcad.svn.sourceforge.net/svnroot/brlcad/rt^3/trunk,
actually |
| 14:59.19 |
Malyce |
http://brlcad.org/wiki/SVN |
| 14:59.39 |
louipc |
right |
| 15:00.31 |
louipc |
I guess rt^3
is not considered part of the BRL-CAD suite |
| 15:01.48 |
Malyce |
could be. I
will know, once the co is done |
| 15:02.01 |
louipc |
it's not
shipped with tarballs |
| 15:02.36 |
louipc |
it's a
separate interface |
| 15:04.24 |
mafm |
rt3 is
experimental stuff, it's not in the main repository :) |
| 15:07.02 |
Malyce |
mafm: the
Install file says that support is not very strong for sys outside
Linux |
| 15:07.20 |
Malyce |
I wanted to
work on only the CoreInterface files |
| 15:07.35 |
Malyce |
Any way to
make this easier ? |
| 15:09.40 |
d_rossberg |
Malyce: which
programming environment are you most familar with? |
| 15:10.59 |
Malyce |
C/C++ on Unix
systems. I just haven't much experience in building large projects
though. |
| 15:11.46 |
d_rossberg |
which tools
do you use un the Unix systems? (command line, eclipse,
...) |
| 15:11.54 |
Malyce |
command
line |
| 15:12.33 |
d_rossberg |
and which
editor (vi, nedite, kate, ...) |
| 15:12.43 |
Malyce |
usually
nedit |
| 15:12.45 |
louipc |
hehe |
| 15:13.19 |
d_rossberg |
ok, did you
ever wrote a makefile? |
| 15:13.45 |
Malyce |
I had to
once. I usually just read them and hope they work |
| 15:14.12 |
Malyce |
but, its not
too hard |
| 15:15.08 |
d_rossberg |
therefore,
you are able to write a simple makefile which includes some
libraries |
| 15:15.11 |
Malyce |
Are you
suggesting that I manually compile the CoreInterface ? |
| 15:15.28 |
d_rossberg |
Malyce: at
this stage: yes |
| 15:15.46 |
Malyce |
allright.
actually that would be a relief, if its possible. |
| 15:16.34 |
d_rossberg |
you should
first buld the brlcad distribution |
| 15:16.44 |
Malyce |
I am still
struggling with that |
| 15:16.58 |
d_rossberg |
this will
give you the libraries you need for the core interface |
| 15:17.03 |
louipc |
blame ubuntu
:D |
| 15:17.08 |
Malyce |
also, svn
keeps resetting my connection after around 30 minutes of checking
out |
| 15:17.12 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 15:17.40 |
d_rossberg |
i'm working
with ubuntu right now, no problem |
| 15:17.49 |
Malyce |
$ svn
checkout http://brlcad.svn.sourceforge.net/svnroot/brlcad/rt^3/trunk
brlc |
| 15:17.49 |
Malyce |
ad-sf-rt3 |
| 15:19.09 |
d_rossberg |
something
like this |
| 15:19.26 |
Malyce |
what am I
doing wrong ? |
| 15:21.00 |
mafm |
Malyce:
aren't you working in linux? what's the problem if the support is
not good for other systems then? :) |
| 15:21.37 |
mafm |
and the reset
problem might be something wrong with the router or something, it
shouldn't be a problem of software |
| 15:21.56 |
Malyce |
I have been
trying to build BRL-CAD on Ubuntu(netbook), Cygwin, Visual Studio
2008 so far |
| 15:22.10 |
Malyce |
for rt^3,
that will narrow my options down to Ubuntu |
| 15:22.46 |
d_rossberg |
Malyce, your
commandline should be ok, it worked for me |
| 15:22.46 |
Malyce |
Tortoise SVN
in Win XP manages to do the checkout completely, but not svn from
inside cygwin |
| 15:22.49 |
mafm |
you can use
"svn checkout --depth=immediates" |
| 15:23.36 |
mafm |
or -N for
non-recursive, and adding excplicitly the directories that you care
about |
| 15:23.44 |
d_rossberg |
there are
graphical frontends for svn on linux too |
| 15:24.04 |
Malyce |
svn:
Shallowing of working copy depths is not yet supported |
| 15:24.05 |
mafm |
you won't
need whole OGRE 3D engine that it's inside src/other for example,
if you only want to work in CoreInterface |
| 15:25.08 |
mafm |
so you can
checkout
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt%5E3/trunk/src/coreInterface/
only :) |
| 15:25.29 |
Malyce |
just
did |
| 15:26.30 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:26.41 |
mafm |
good
:) |
| 15:28.29 |
Malyce |
Yessss |
| 15:30.06 |
Malyce |
also, co this
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt%5E3/trunk/include/brlcad/ |
| 15:30.09 |
Malyce |
for the
headers |
| 15:30.54 |
Malyce |
d_rossberg: I
think that is all |
| 15:30.55 |
Malyce |
? |
| 15:32.27 |
Malyce |
I will try
building BRL-CAD on Ubuntu on a standard laptop instead of a
netbook and see if that is better |
| 15:32.34 |
d_rossberg |
you may put
http://brlcad.svn.sourceforge.net/viewvc/brlcad
into your webbrowser to see what is left, but these two branches
are what i'm using |
| 15:33.18 |
Malyce |
It is not
possible, I suppose for me to copy the main libraries without
building BRL-CAD ? |
| 15:33.55 |
Malyce |
I will only
need librt |
| 15:34.04 |
d_rossberg |
the hardware
itself should not make a difference but the Ubuntu distribution you
are using |
| 15:35.07 |
Malyce |
9.04 on both
machines |
| 15:37.42 |
d_rossberg |
you need to
be able to build BRL-CAD by yourself because sometimes there are
changes on the core libraries neccessary |
| 15:39.33 |
``Erik |
moo |
| 15:40.38 |
d_rossberg |
the number of
the distribution may not say all, your autoconf and libtool
versions are different from mine (for example) |
| 15:40.39 |
louipc |
yeah a
netbook is a bit of an awkward development platform eh? |
| 16:07.07 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 16:23.55 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 16:28.08 |
*** part/#brlcad tessier_
(n=treed@kernel-panic/sex-machines) |
| 16:34.54 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 16:37.52 |
*** join/#brlcad Malyce
(n=iamtanma@deimos.jacobs-university.de) |
| 16:45.15 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-234-136.dclient.hispeed.ch) |
| 16:51.06 |
*** join/#brlcad Malyce2
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 17:02.22 |
CIA-40 |
BRL-CAD:
03bob1961 * r34183 10/brlcad/trunk/src/ (27 files in 6 dirs):
Modified Archer to use the ttk widgets. |
| 17:20.02 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 17:37.37 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 17:40.09 |
*** join/#brlcad PrezKennedy
(i=Matthew@208.43.126.194) |
| 17:46.46 |
*** join/#brlcad piksi_
(i=piksi@83.145.207.200) |
| 17:51.22 |
``Erik |
*burp* |
| 17:53.24 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-148-64.3g.claro.net.br) |
| 17:57.35 |
*** part/#brlcad piksi_
(i=piksi@83.145.207.200) |
| 18:34.51 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 18:55.59 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 19:03.48 |
pacman87 |
any news on
the prelim slot count? |
| 19:06.22 |
brlcad |
not till
thursday |
| 19:07.02 |
pacman87 |
update the
channel topic? |
| 19:10.32 |
brlcad |
ahh,
yeah |
| 19:10.41 |
brlcad |
she
originally said "thursday the 7th" |
| 19:12.22 |
brlcad |
BRL-CAD Open
Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step:
applications have been reviewed, respond to comments, preliminary
slot count on 9th, selections announced on the 20th |
| 19:12.36 |
brlcad |
we'll know by
the 15th, but we're not supposed to tell you until the 20th
:) |
| 19:12.50 |
pacman87 |
ok,
thanks |
| 19:13.04 |
brlcad |
kinda cruel
and unusual if you ask me |
| 19:14.06 |
brlcad |
thinks someone should write up a comparison of http://trepan.bzflag.bz/vectors.h
to our vmath.h for something number-intensive |
| 19:21.54 |
*** join/#brlcad dreeves
(n=IceChat7@64.178.177.71) |
| 19:27.25 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-132-173.3g.claro.net.br) |
| 19:43.30 |
*** join/#brlcad madant_
(n=madant@117.196.130.53) |
| 19:59.48 |
*** join/#brlcad andax
(n=andax__@d213-102-40-182.cust.tele2.ch) |
| 20:05.08 |
*** join/#brlcad Malyce
(n=smartmin@deimos.jacobs-university.de) |
| 20:07.57 |
*** join/#brlcad madant_
(n=madant@117.196.129.50) |
| 20:19.49 |
Malyce |
(Ubuntu)
./configure died with: error: c compiler cannot create
executables |
| 20:19.49 |
Malyce |
Solutions on
google said to install libc6 libc6-dev gcc g++ build-essential, all
of which I have latest version |
| 20:19.51 |
Malyce |
http://bzflag.pastebin.ca/1385248 |
| 20:20.07 |
Malyce |
config.log |
| 20:21.37 |
``Erik |
for some
reason, your configure is putting newlines in the version string,
it shouldn't be doing that :/ something is probably messed
up/incompatible with your autotools |
| 20:22.34 |
``Erik |
early on in
your configure, you should have a line like
PACKAGE_VERSION='7.14.7' |
| 20:22.45 |
Malyce |
yes, I had to
manually fix that |
| 20:23.06 |
Malyce |
I suppose it
messed up conftest.c as well |
| 20:24.06 |
brlcad |
ahh, I've
seen that newline issue |
| 20:24.19 |
brlcad |
i think it's
related to the carriage returns or just that particular version of
autoconf |
| 20:24.24 |
brlcad |
(on
cyg) |
| 20:24.36 |
Malyce |
this is
ubuntu |
| 20:24.38 |
brlcad |
the last user
that ran into it just hard-wired the numbers into
configure.ac |
| 20:25.03 |
brlcad |
Malyce: was
the checkout done on ubuntu or on a shared volume? |
| 20:25.18 |
Malyce |
cygwin |
| 20:25.23 |
brlcad |
heh |
| 20:25.24 |
Malyce |
this is so
messed up |
| 20:25.39 |
``Erik |
#!~31
*scrolls up to where he said it'd cause problems if malyce did
that* |
| 20:26.01 |
brlcad |
hehe, i've
honestly never seen someone have this much trouble compiling the
package :) |
| 20:26.15 |
brlcad |
lots of ways
to improve I suppose :) |
| 20:26.19 |
Malyce |
noob, noob,
noob |
| 20:26.23 |
brlcad |
Malyce: edit
your configure.ac file |
| 20:26.30 |
Malyce |
so I should
co again on ubuntu ? |
| 20:26.37 |
brlcad |
try the edit
first |
| 20:26.40 |
brlcad |
it's quick
and simple |
| 20:26.50 |
brlcad |
look for the
four define lines near the beginning |
| 20:27.10 |
Malyce |
like this:
define([MAJOR_VERSION], [patsubst(esyscmd([cat
include/conf/MAJOR]), [ |
| 20:27.11 |
Malyce |
])]) |
| 20:27.13 |
brlcad |
comment them
out and just set them directly in VAR=value form (e.g.
MAJOR_VERSION=7) |
| 20:27.53 |
brlcad |
makes sure that'll work |
| 20:28.19 |
Malyce |
you want me
to set them to the actual numbers, and not the path, right
? |
| 20:28.23 |
brlcad |
okay, that
won't work |
| 20:28.59 |
brlcad |
define([VAR],
[#]) |
| 20:29.11 |
brlcad |
where # is
the number from the corresponding file |
| 20:29.24 |
brlcad |
not all that
patsubst stuff |
| 20:34.54 |
Malyce |
define([MAJOR_VERSION],[7])
define([MINOR_VERSION],[14]) define([PATCH_VERSION],[7])
define([CAD_VERSION],[7.14.7]) |
| 20:39.55 |
Malyce |
http://bzflag.pastebin.ca/1385272 |
| 20:40.00 |
Malyce |
It looks the
same |
| 20:40.17 |
brlcad |
you have to
run autogen.sh after editing configure.ac |
| 20:40.27 |
brlcad |
(always) |
| 20:40.38 |
Malyce |
ok |
| 20:41.27 |
brlcad |
for any
autotools project, any time you edit a makefile* or configure*
file, you should rerun the bootstrapping step, whatever that may
be |
| 20:41.44 |
brlcad |
usually
./autogen.sh or ./buildconf or autoreconf -vis or something else
they document |
| 20:49.15 |
brlcad |
Malyce: how'd
that go? |
| 20:55.18 |
Malyce |
http://bzflag.pastebin.ca/1385297 |
| 20:55.24 |
Malyce |
two warnings,
one error |
| 20:58.51 |
brlcad |
infig.status?! wtf is that? |
| 20:58.58 |
brlcad |
should be
config.status |
| 20:59.26 |
brlcad |
if really
sounds like you have a busted configuration |
| 20:59.50 |
brlcad |
really seems
like something is wrong with your gnu autotools install |
| 21:00.48 |
``Erik |
would think a) try a fresh checkout to a linux filesystem, or
b) try to autoreconf a different project and see how that
works |
| 21:00.52 |
brlcad |
you're also
missing at least three other things that you'd need to install
before you can build -- a lexer (lex), a parser (yacc/bison), and
libXi-dev/libXi |
| 21:02.08 |
Malyce |
apt-get
install libXi-dev |
| 21:02.14 |
brlcad |
I've built
cleanly on debian very recently, so I really doubt the problems are
some problem with the autotools, and our build system certainly
hasn't changed |
| 21:02.51 |
brlcad |
more than
likely , it's something wrong -- maybe could try reinstalling
m4/perl/automake/libtool/autoconf |
| 21:03.23 |
Malyce |
similarly, I
do 'install lex bison automake autoconf libtool' |
| 21:05.06 |
Malyce |
will Flex do
? |
| 21:05.15 |
brlcad |
yes |
| 21:05.42 |
brlcad |
this sounds
like a pretty vanilla system |
| 21:06.52 |
Malyce |
so, I just
installed bison flex libXi-dev. I should autoremove the rest, then
install them again ? |
| 21:07.07 |
brlcad |
I'd suggest
it, just to test |
| 21:07.17 |
brlcad |
something
does seem quite wrong |
| 21:08.19 |
*** join/#brlcad PrezKennedy
(i=Matthew@208.43.126.194) |
| 21:10.53 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 21:21.14 |
Malyce |
btw, what
about the floating point implementation that was not IEEE754
compliant warning ? |
| 21:21.34 |
Malyce |
also, same
config error |
| 21:21.52 |
Malyce |
just finished
uninstalling-installing-autogen-configure |
| 21:23.01 |
*** join/#brlcad PrezKennedy
(i=Matthew@208.43.126.194) |
| 21:25.08 |
Malyce |
http://bzflag.pastebin.ca/1385345 |
| 21:29.31 |
hippieindamakin8 |
brlcad,
posted a comment on the appspot portal |
| 21:30.39 |
hippieindamakin8 |
is in a hurry as he has his final year engineering project
presentation tommorow and all the components of mechanical system
stopped working |
| 21:37.24 |
*** join/#brlcad madant__
(n=madant@117.196.129.114) |
| 21:39.00 |
Malyce |
entering-
./config.status gives me - .infig.status: error: cannot find
input file: |
| 21:39.40 |
Malyce |
which is the
same thing ./configure is telling me. |
| 21:40.14 |
Malyce |
so, this is a
line ending issue ? |
| 21:41.12 |
Malyce |
yes, I
resolved the problem. I checked out from svn and ran the same
thing. It must have been because I had co on cygwin earlier. No
autotools issue here |
| 22:37.09 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 22:45.28 |
``Erik |
autodesk and
softworks offering free demos? O.O |
| 22:54.42 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 23:08.41 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 23:31.34 |
brlcad |
Malyce: glad
to hear the problem is solved! so do you have a build? |
| 23:34.20 |
*** join/#brlcad Malyce2
(n=iamtanma@deimos.jacobs-university.de) |
| 23:40.38 |
Malyce2 |
yes
sir |
| 23:40.44 |
Malyce2 |
its all up
and running |
| 23:40.52 |
Malyce2 |
ran the
benchmarks and the install |
| 23:40.53 |
``Erik |
huzzah |
| 23:42.00 |
Malyce2 |
I am
installing Ubuntu on my own machine right now. I will transfer the
files and run the benchmark again to check. Is that ok
? |
| 23:44.19 |
``Erik |
if the new
box has the same arch, os and packages, should be |
| 23:44.36 |
``Erik |
erm, and the
source is in the same path |
| 23:44.53 |
``Erik |
like, if it
was /usr/home/joeblow on the old machine and /home/malyce on the
new one, that'd probably fail |
| 23:45.12 |
Malyce2 |
I think I'll
play it safe, and rerun from autogen |
| 23:48.27 |
*** join/#brlcad madant_
(n=madant@117.196.131.130) |
| 23:54.19 |
yukonbob |
waves to teh cadheads |
| 00:02.39 |
brlcad |
howdy
yukonbob |
| 00:07.55 |
yukonbob |
hey
brlcad |
| 00:08.00 |
yukonbob |
how're
trix? |
| 00:30.29 |
yukonbob |
restarts build process with a release, vs. svn
co |
| 00:54.56 |
brlcad |
yukonbob:
going pretty good |
| 00:55.11 |
brlcad |
yukonbob:
feel free to comment on any gsoc applications to the
students |
| 00:55.23 |
brlcad |
socghop.appspot.com |
| 00:56.06 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 00:56.47 |
brlcad |
waves to dreeves |
| 00:58.44 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 00:59.21 |
dreeves |
waves back |
| 00:59.38 |
dreeves |
to brlcad |
| 01:00.33 |
yukonbob |
brlcad: will
do -- am changing geography right now to settle into some quality
computer time ;) |
| 01:00.52 |
starseeker |
is impressed gCAD3D is able to import the OpenMoko CAD
files |
| 01:04.28 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 01:19.53 |
starseeker |
sets up a test raytrace of the openbook d part and heads
home |
| 01:29.57 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 01:34.38 |
mafm |
night |
| 01:43.26 |
Ralith_ |
night |
| 01:56.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 02:06.58 |
``Erik |
http://news.ycombinator.com/item?id=549899
<-- BRL-CAD being pimped O.o |
| 02:07.57 |
Ralith |
cool! |
| 02:09.26 |
Ralith |
I want one of
those keyboards with extra mod keys |
| 02:11.03 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 02:25.27 |
*** join/#brlcad starseeker_
(n=CY@c-68-33-217-173.hsd1.md.comcast.net) |
| 02:25.41 |
starseeker_ |
hrm - anyone
else not able to connect to brlcad.org? |
| 02:27.42 |
starseeker_ |
or
bzflag.bz? |
| 02:28.01 |
starseeker_ |
has apparently offended the gods |
| 02:32.05 |
``Erik |
lame, it
pings but it doesn't let me ssh in |
| 02:32.14 |
``Erik |
or let me
pull up the page |
| 02:33.29 |
starseeker_ |
hope I didn't
bust anything :-( |
| 02:36.27 |
``Erik |
imagines the machine might be overburdened |
| 02:36.47 |
``Erik |
my putzy
little home server gets like that when I go heavy into
swap |
| 02:37.02 |
``Erik |
and usually
something like 4 load during that heh :D |
| 02:38.08 |
starseeker_ |
winces - I didn't THINK I put up too much data with the CAD
files... I hope that's not it... |
| 02:39.28 |
``Erik |
hm, that
machine was awfully tight on space |
| 02:41.34 |
``Erik |
hm, kernel
response to ping is fast, but irc response is slow, smells like io
thrashing to me :( |
| 02:41.48 |
``Erik |
load is
55 |
| 02:41.59 |
``Erik |
usr is
full |
| 02:42.29 |
``Erik |
annnddddd the
kernel is too old to give me the io info I'm lookin' for in the way
I'm used to heh |
| 02:45.59 |
Ralith |
I can get to
the web page, but the web page can't get to the db
server. |
| 02:46.16 |
starseeker_ |
ah
hell |
| 02:46.18 |
Ralith |
which is odd,
considering that the db server is on the same machine. |
| 02:46.38 |
Ralith |
The MySQL
error was: Lost connection to MySQL server during
query. |
| 02:46.44 |
``Erik |
db server
may've crapped itself when a write to /usr failed due to it being
full |
| 02:47.00 |
Ralith |
I remember
filling /var on my laptop once |
| 02:47.05 |
Ralith |
produced very
strange behavior. |
| 02:47.39 |
``Erik |
not all apps
behave intelligently when write() or fprintf() fail |
| 02:47.57 |
starseeker_ |
I got in with
ssh |
| 02:48.05 |
starseeker_ |
erases Neo Freerunner files |
| 02:49.28 |
starseeker_ |
no, that
can't be it |
| 02:49.39 |
``Erik |
brlcad seems
to be coming back up now |
| 02:49.41 |
starseeker_ |
that was only
a couple hunderd megs |
| 02:49.44 |
``Erik |
the page,
that is |
| 02:49.45 |
``Erik |
um,
yes |
| 02:49.53 |
``Erik |
it's that
close |
| 02:50.01 |
``Erik |
tehre's 300
megs free right now |
| 02:50.15 |
starseeker_ |
bloody |
| 02:50.23 |
starseeker_ |
well, so much
for that idea |
| 02:50.52 |
``Erik |
<-- points
where he said that the machine was tight on space :) |
| 02:51.16 |
``Erik |
when the
migration happens, there'll be more space available |
| 02:53.02 |
starseeker_ |
clears out all the openmoko files except the readmes for
later reference |
| 02:53.16 |
starseeker_ |
ok, up to
350 |
| 02:53.45 |
``Erik |
irssi, mysql
and httpd were freaking out on not being able to write to
/usr |
| 02:53.51 |
starseeker_ |
prepares to back up his dir there and clean out everything he
can |
| 02:55.55 |
starseeker_ |
nuts, I was
going to have my nice little pocket of free, high quality CAD
files |
| 02:56.03 |
starseeker_ |
well, no
matter |
| 02:56.21 |
starseeker_ |
only the .g
files really NEED to be there |
| 02:56.53 |
starseeker_ |
;-) |
| 03:01.15 |
``Erik |
make brlcad
migrate the server, then you'll have ~25g to use :D |
| 03:06.23 |
starseeker_ |
hmm, maybe
http://www.ibiblio.org would
be interested? Virtual AGC certainly takes up some
space |
| 03:08.23 |
Ralith |
starseeker_:
CAD files of what? |
| 03:09.11 |
starseeker_ |
OpenMoko
phone case and VIA OpenBook laptop computer case |
| 03:09.14 |
starseeker_ |
so
far |
| 03:09.20 |
starseeker_ |
nurbs based
models |
| 03:09.24 |
starseeker_ |
professional
quality |
| 03:09.37 |
``Erik |
pheer my
professional quality, uh, cube |
| 03:09.47 |
starseeker_ |
heh |
| 03:10.01 |
``Erik |
had to make one in metal tech long ago |
| 03:10.12 |
starseeker_ |
once we can
raytrace the simple cases, we can attempt to raytrace THOSE
models |
| 03:10.26 |
``Erik |
milled
aluminum, forget the accuracy it needed, but it had to be pretty
precise |
| 03:11.16 |
Ralith |
starseeker_:
where did you get CAD designs for a VIA laptop? O.o |
| 03:11.20 |
Ralith |
how're they
licensed? |
| 03:11.43 |
starseeker_ |
http://www.viaopenbook.com/ |
| 03:11.49 |
``Erik |
a very
flexible license he got form http://ninjas-r-us.com/ |
| 03:11.58 |
starseeker_ |
Creative
Commons Attribution-Share Alike 3.0 Unported |
| 03:12.09 |
starseeker_ |
just the
case, mind you |
| 03:12.18 |
Ralith |
cool! |
| 03:12.42 |
Ralith |
I didn't know
we had the code to import NURBS to .g |
| 03:12.52 |
starseeker_ |
we don't
directly |
| 03:12.54 |
starseeker_ |
yet |
| 03:13.05 |
starseeker_ |
3dm-g is the
path, but that needs Rhino |
| 03:13.23 |
Ralith |
ah. |
| 03:13.52 |
starseeker_ |
once we get a
STEP importer that handles NURBS, we can just export from whatever
to STEP and (in theory) be good to go |
| 03:13.55 |
Ralith |
so, sounds
like BREP is moving along at a fair clip then, if we're already
looking at stress tests |
| 03:14.59 |
starseeker_ |
dreeves has
been looking at some of the work out of utah and applying it -
exciting stuff |
| 03:15.10 |
Ralith |
utah? |
| 03:15.19 |
Ralith |
major kudos
to him |
| 03:15.43 |
Ralith |
is anyone
actually working on a STEP importer? |
| 03:16.30 |
starseeker_ |
we're shaking
down the NIST STEP Class Library code right now |
| 03:16.35 |
starseeker_ |
that should
help with an importer |
| 03:20.05 |
starseeker_ |
exciting
stuff |
| 03:22.42 |
Ralith |
yeah |
| 03:25.35 |
starseeker_ |
Right now, I
know of three sources for potentially good CAD models that are open
source - OpenMoko, VIA OpenBook, and (possibly) some of the files
at http://space.jpl.nasa.gov/models/ |
| 03:26.04 |
starseeker_ |
the most
interesting of the latter uses Inventor, which is not a format
BRL-CAD has an importer for |
| 03:26.42 |
starseeker_ |
might be able
to do something with the Open Inventor code, or might be able to
import it and export it through another path |
| 03:28.59 |
Ralith |
the galileo
orbiter? |
| 03:29.15 |
starseeker_ |
no, the
Cassini |
| 03:29.20 |
starseeker_ |
the 300,000k
object one |
| 03:29.31 |
Ralith |
ahh |
| 03:29.34 |
Ralith |
didn't notice
that figure. |
| 03:29.43 |
Ralith |
assumed it
was just a vanilla conversion |
| 03:29.47 |
starseeker_ |
it might be
AutoCAD Inventor, come to think of it |
| 03:29.50 |
starseeker_ |
hmm |
| 03:29.51 |
Ralith |
hehe,
accurate to a fault. |
| 03:29.57 |
starseeker_ |
loves being accurate to a fault |
| 03:30.05 |
Ralith |
thinks it's great fun |
| 03:30.12 |
Ralith |
(thus my love
for CSG over meshes) |
| 03:30.24 |
Ralith |
(even though
I do no work where it matters, and probably won't for
years) |
| 03:30.29 |
starseeker_ |
I'm guessing
the obj files are exports from the big one |
| 03:31.09 |
Ralith |
the others
too, probably |
| 03:31.24 |
Ralith |
I'm surprised
by the size difference though |
| 03:31.41 |
Ralith |
very
inconsistent prims:filesize ratio |
| 03:32.22 |
starseeker_ |
yeah, not
really sure what's in them to be honest |
| 03:32.58 |
starseeker_ |
I managed
after a long and annoying chain to use open source tools to get one
of the obj files visible in BRL-CAD, but it doesn't seem to be any
kind of a solid model |
| 03:33.09 |
starseeker_ |
at least, not
after the conversion process got done with it |
| 03:33.14 |
Ralith |
heh |
| 03:33.22 |
Ralith |
might be best
to take a look with the native tool. |
| 03:33.35 |
starseeker_ |
it's slow as
heck, not much better visually than the dxf... etc. |
| 03:33.36 |
starseeker_ |
yeah |
| 03:34.09 |
Ralith |
the way it
says 'prims' rather than 'tris' suggests a solid model,
though |
| 03:34.11 |
starseeker_ |
I got
reminded today about the OpenBook, so that is making me re-visit my
last look at the Cassini models |
| 03:34.46 |
starseeker_ |
it's ideal to
have open models that make heavy real world use of NURBS, so we can
share a common test case between all contributors |
| 03:34.53 |
*** join/#brlcad Malyce
(n=iamtanma@deimos.jacobs-university.de) |
| 03:34.59 |
Ralith |
yeah |
| 03:39.05 |
starseeker_ |
indeed, that
argument holds for all aspects of CAD, not just NURBS - it just so
happens that NURBS are hot right now :-) |
| 03:42.00 |
Ralith |
and relate
directly to current development efforts |
| 03:47.05 |
starseeker_ |
ok, 890 free
- that may do for now |
| 04:31.13 |
starseeker |
hmm, one
other interesting source of open source CAD models: |
| 04:31.13 |
starseeker |
<PROTECTED> |
| 04:31.16 |
starseeker |
» |
| 04:31.18 |
starseeker |
Login or
register to post comments |
| 04:31.21 |
starseeker |
<PROTECTED> |
| 04:31.25 |
starseeker |
l |
| 04:31.28 |
starseeker |
hmm |
| 04:31.31 |
starseeker |
let's try
that again |
| 04:31.38 |
starseeker |
http://www3.elphel.com/wiki/Elphel_camera_parts#0353-10-01_-_camera_bottom.2C_l.3D104.77mm |
| 04:32.43 |
starseeker |
The pdf
versions are under GFDL with no invariant sections as near as I can
tell, but I don't see any license info on the STEP
files |
| 04:34.25 |
starseeker |
ah, looks
like the short URL works: http://www3.elphel.com/wiki/Elphel_camera_parts |
| 04:39.59 |
Ralith |
neat |
| 05:07.50 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 05:07.57 |
Ralith |
hey
dreeves! |
| 05:16.41 |
dreeves |
hey |
| 06:03.06 |
yukonbob |
_still_ can't get an error-free build going
:P |
| 06:44.55 |
*** join/#brlcad madant
(n=madant@117.196.135.208) |
| 06:52.25 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 06:56.11 |
yukonbob |
nice...
bordering on success now... |
| 07:24.00 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 07:24.06 |
yukonbob |
hi
clock |
| 07:24.25 |
_clock_ |
hi |
| 07:31.19 |
yukonbob |
_clock_:
what's new? |
| 07:31.41 |
_clock_ |
the
brazilians seem to be complicated |
| 07:31.54 |
yukonbob |
? |
| 07:58.03 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 08:07.30 |
*** join/#brlcad madant_
(n=madant@117.196.149.107) |
| 08:13.44 |
hippieindamakin8 |
waves at madant_ |
| 08:25.27 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 08:26.37 |
madant_ |
waves back |
| 09:18.59 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:31.51 |
mafm |
hi |
| 09:34.43 |
*** join/#brlcad madant_
(n=madant@117.196.144.166) |
| 09:55.54 |
*** join/#brlcad madant_
(n=madant@117.196.144.166) |
| 11:04.22 |
*** join/#brlcad madant_
(n=madant@117.196.143.22) |
| 12:07.26 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 12:08.39 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 12:26.43 |
starseeker |
Hmmm...
http://bugcommunity.com/wiki/index.php/BUGbase |
| 12:34.08 |
starseeker |
http://touchkit.nortd.com/download.html |
| 12:35.17 |
starseeker |
interesting |
| 12:54.05 |
CIA-40 |
BRL-CAD:
03johnranderson * r34184
10/jbrlcad/trunk/src/org/brlcad/numerics/BoundingBox.java: Added
doesIntersect(Ray) method |
| 13:34.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 13:34.21 |
``Erik |
heh "If all
else fails... your coworkers are edible" O.o dilbert is kinda, uh,
scary at times |
| 13:36.38 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:56.30 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:02.28 |
*** join/#brlcad madant
(n=madant@117.196.137.224) |
| 14:18.03 |
starseeker |
ah, the
openbook conversion did (sorta) raytrace, after a prep time that
seems to have been on the order of 20 minutes |
| 14:23.08 |
*** join/#brlcad madant_
(n=madant@117.196.129.129) |
| 14:29.38 |
*** join/#brlcad _clock__
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 14:43.37 |
``Erik |
shweet,
pix? |
| 15:12.04 |
yukonbob |
finally... |
| 15:16.36 |
yukonbob |
...feh.
almost |
| 15:17.36 |
CIA-40 |
BRL-CAD:
03brlcad * r34185 10/brlcad/trunk/TODO: |
| 15:17.36 |
CIA-40 |
BRL-CAD:
weiss checked the cpa contribution (and ended up going a better
route) so remove |
| 15:17.36 |
CIA-40 |
BRL-CAD: it
from the list. russell dibelka suggested an interesting feature to
make |
| 15:17.36 |
CIA-40 |
BRL-CAD:
rtarea display a cross-hair or similar indicator, perhaps with
coordinates, if |
| 15:17.36 |
CIA-40 |
BRL-CAD:
rtarea is invoked within mged. |
| 15:19.58 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 15:26.34 |
*** join/#brlcad dreeves
(n=c752f34a@bz.bzflag.bz) |
| 16:16.08 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 16:26.12 |
hippieindamakin8 |
hey brlcad ,
should i add something more to the comment ? |
| 17:16.39 |
starseeker |
``Erik:
http://bzflag.bz/~starseeker/openbook_d2.png |
| 17:17.45 |
``Erik |
neato |
| 17:17.48 |
``Erik |
iiintersting |
| 17:21.28 |
brlcad |
cool |
| 17:21.34 |
brlcad |
looks
horrible, but cool :) |
| 17:22.31 |
brlcad |
hippieindamakin8: not until/unless someone
replies back unless you know there is something more you care to
say |
| 17:29.05 |
``Erik |
thinks all those loops are highly indicative of...
something... what it is, I dunno, but someone who knows more than
me may gleen knowledge from the existance of those... they smell
funny :) |
| 17:32.46 |
*** join/#brlcad madant__
(n=madant@117.196.145.157) |
| 17:33.02 |
starseeker |
``Erik: my
guess is non-working trimming |
| 17:37.40 |
CIA-40 |
BRL-CAD:
03johnranderson * r34186
10/jbrlcad/trunk/src/org/brlcad/geometry/Partition.java: |
| 17:37.40 |
CIA-40 |
BRL-CAD:
Added air code. |
| 17:37.40 |
CIA-40 |
BRL-CAD:
Added ident and air code to the toString() method |
| 17:38.06 |
``Erik |
I guess
isolating piece generating a loop and looking at its equivelant in
a "correct" system (like pro-e) would be the litmus test for
that |
| 17:41.19 |
``Erik |
(I'm being
asked how to clear the command window in mged, anyone know off
hand?) |
| 17:42.10 |
starseeker |
drop down
menu |
| 17:42.27 |
starseeker |
File->Clear Command Window |
| 17:42.55 |
``Erik |
passed, he
says thanks |
| 17:47.38 |
brlcad |
heh |
| 17:47.48 |
brlcad |
woulda just said "hit enter a few times" |
| 17:48.06 |
brlcad |
or "implement
a 'clear' command" |
| 17:48.09 |
``Erik |
woulda assumed a "clear" command *shrug* |
| 17:48.31 |
starseeker |
DID assume a clear command |
| 17:48.40 |
starseeker |
IIRC, it lead
to a discussion about polluting name spaces |
| 17:48.40 |
brlcad |
problem with
'clear' is that it's a shell intrinsic |
| 17:48.51 |
brlcad |
unlike almost
all other commands |
| 17:49.01 |
brlcad |
it's purpose
is to control the console you're running in |
| 17:49.22 |
brlcad |
not many
commands do that, are only console-centric like that |
| 17:49.55 |
brlcad |
so as a ged
command, it would take some sort of api change to tell mged that
some sort of "clear the buffer" was requested |
| 17:50.16 |
brlcad |
unless it's
left/exposed as an mged-only command of course, and doesn't live in
libged |
| 17:50.25 |
brlcad |
which would
make senss |
| 17:50.27 |
starseeker |
thinks the latter makes more sense |
| 17:50.47 |
brlcad |
there ya go,
patch it up ;) |
| 17:50.53 |
brlcad |
should be a
trivial command |
| 17:50.58 |
starseeker |
nods |
| 17:51.01 |
``Erik |
my thought
was that it'd live all in src/tclscripts/mged |
| 17:51.01 |
starseeker |
one
sec... |
| 17:51.12 |
brlcad |
even have a
menu already doing it, so there's a hook already doing
it |
| 17:51.17 |
``Erik |
<PROTECTED> |
| 17:51.28 |
brlcad |
that looks
like it |
| 17:51.44 |
starseeker |
``Erik: you
already have it ready? ;-) |
| 17:51.51 |
``Erik |
nope, that's
the menu cmd |
| 17:52.17 |
``Erik |
I have some
serious nappi^Wcoding to do, instead O:-) |
| 17:56.09 |
``Erik |
(be a good
lowhanging fruit for someone coming up to speed to do,
imho) |
| 18:00.37 |
brlcad |
starseeker:
point being that you can just make a tcl proc that calls that same
line as command (or better yet, refactor that to be 'clear' then
make the menu command call clear) |
| 18:00.58 |
brlcad |
very
low-hanging |
| 18:01.57 |
``Erik |
yes, I was
starting to do the 5minute hack, but held back because someone
somewhere might benefit from doing it |
| 18:02.15 |
``Erik |
(we need to
save easy stuff for new developers, as hard as it is) |
| 18:02.34 |
CIA-40 |
BRL-CAD:
03brlcad * r34187 10/brlcad/trunk/TODO: mged/archer could use a
'clear' command. don't muck it into libged, though. |
| 18:03.07 |
``Erik |
ponders suggesting that task out loud |
| 18:09.51 |
starseeker |
is trying to figure out how to refer to .$id.t from within
somewhere other than openw.tcl... |
| 18:13.03 |
brlcad |
src/tclscripts/mged is fair
game |
| 18:13.56 |
brlcad |
otherwise,
you can actually request it too: set id [get_player_id_t
$w] |
| 18:14.10 |
brlcad |
if you're in
widget code of course -- w is the widget handle |
| 18:23.02 |
brlcad |
er, not
widget, it's the window id |
| 18:23.23 |
brlcad |
e.g.,
".id_0.t" |
| 18:23.35 |
starseeker |
right |
| 18:23.57 |
brlcad |
set
mged_players will list the current top-level windows |
| 18:24.42 |
brlcad |
(basically
every time you run "gui", it makes another player) |
| 18:25.06 |
brlcad |
if anyone has
a recent build, see if tab-completion works |
| 18:25.46 |
``Erik |
seems
to |
| 18:26.05 |
``Erik |
both for
commands and geometric names |
| 18:26.25 |
brlcad |
with 7.14.7
? |
| 18:26.28 |
``Erik |
up and
installed this morning |
| 18:26.29 |
``Erik |
yes |
| 18:26.44 |
brlcad |
k |
| 18:26.45 |
brlcad |
thx |
| 18:26.51 |
``Erik |
BRL-CAD
Release 7.14.7 The BRL-CAD Raytracer RT |
| 18:26.51 |
``Erik |
<PROTECTED> |
| 19:00.28 |
CIA-40 |
BRL-CAD:
03starseeker * r34188 10/brlcad/trunk/ (6 files in 2 dirs): Bob and
Cliff added a clear command to MGED - File->Clear Command Window
also uses it now. |
| 19:01.27 |
``Erik |
bastards,
that coulda been a newbies learning project :D |
| 19:02.47 |
starseeker |
well, now
we're down to 800 other potential projects ;-) |
| 19:04.53 |
brlcad |
thinks that shouldn't have needed to involve bob then too
:P |
| 19:05.25 |
brlcad |
easy access
"just" to ask a question is still a context switch interruption on
whatever he was doing |
| 19:22.37 |
starseeker |
is getting even for stock market context switches
;-) |
| 19:23.51 |
``Erik |
aw, c'mon,
don't turn it into a zero sum game |
| 19:23.59 |
starseeker |
heh |
| 19:32.07 |
brlcad |
starseeker:
problem with clear, busted for classic mode |
| 19:32.16 |
brlcad |
it also
assumes just one player |
| 19:32.49 |
brlcad |
need to fix
"mged -c" use as well as graphical use after you run 'gui' two or
three times |
| 19:52.59 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-243-213.dclient.hispeed.ch) |
| 20:29.02 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 20:49.18 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 21:07.18 |
starseeker |
brlcad: Hmm.
Was that always broken? |
| 21:08.05 |
starseeker |
(the multi
gui I mean, obviously classic is a different case) |
| 21:09.04 |
``Erik |
O.o the menu
approach defaults to the window it was called from.. there was
nothing to be 'broken' until you did what you did |
| 21:09.14 |
starseeker |
ok |
| 21:22.48 |
CIA-40 |
BRL-CAD:
03starseeker * r34189
10/brlcad/trunk/src/tclscripts/mged/clear.tcl: handle case where
mged_players has more than one entry |
| 21:27.51 |
starseeker |
didn't know anyone ran gui from within
MGED |
| 21:48.11 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 21:51.35 |
CIA-40 |
BRL-CAD:
03starseeker * r34190 10/brlcad/trunk/src/tclscripts/mged/
(clear.tcl openw.tcl): |
| 21:51.35 |
CIA-40 |
BRL-CAD: OK,
handle clean with mged -c, multiple gui instances, and put the
window |
| 21:51.35 |
CIA-40 |
BRL-CAD:
command back where it was with the additions for handling character
capture |
| 21:51.35 |
CIA-40 |
BRL-CAD:
(some sort of different behavior happening there, for now just
restore correct |
| 21:51.35 |
CIA-40 |
BRL-CAD:
behavior.) |
| 21:51.56 |
starseeker |
brlcad: that
should be better |
| 21:52.55 |
CIA-40 |
BRL-CAD:
03r_weiss * r34191
10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: bug fixes for
pnts primitive, added partial 'l' command support |
| 22:30.18 |
brlcad |
starseeker:
gui is a valid configuration for getting multiple views,
alternative to multipane (a better one at that |
| 22:30.48 |
brlcad |
technically,
behavior has changed now |
| 22:30.55 |
brlcad |
not sure I
care about it, but it is unexpected behavior |
| 22:31.17 |
brlcad |
it should
clear the text widget that you type "clear" into, not all of
them |
| 22:31.33 |
brlcad |
the menu
option did that, now it'll clear all of them if I read the patch
right |
| 22:31.48 |
brlcad |
plus, I'm
sure it'll still choke an error in -c mode |
| 22:33.55 |
``Erik |
the
update/output going to all windows when you execute a cmd is ...
surprising |
| 22:39.05 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1379 10/wiki/User:Homovulgaris: /* Abstract */ scaling
down |
| 22:39.18 |
brlcad |
that's a
feature |
| 22:39.54 |
brlcad |
kinda useful
at times actually, but it is sort of odd |
| 22:40.11 |
brlcad |
because you
can run mged -c > file and run gui to get a console, then you
have a full transcript |
| 22:40.35 |
brlcad |
that's part
why it's useful, not why it's odd :) |
| 22:41.17 |
brlcad |
not sure if
there's a way for a command that is run in a given text widget to
know which text widget it was invoked from |
| 22:47.12 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1380 10/wiki/User:Homovulgaris: /* Proposal */ time for libged
integration increased by 65 % |
| 22:47.33 |
``Erik |
*shrug* |
| 22:47.34 |
brlcad |
woot |
| 22:47.38 |
brlcad |
~madant++ |
| 22:52.34 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 22:53.29 |
madant__ |
:) |
| 22:57.28 |
CIA-40 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1381 10/wiki/User:Homovulgaris: /* Schedule */ |
| 23:10.19 |
*** join/#brlcad madant_
(n=madant@117.196.128.219) |
| 23:12.55 |
brlcad |
that's
looking much better |
| 23:19.32 |
*** join/#brlcad madant_
(n=madant@117.196.128.219) |
| 23:27.57 |
*** join/#brlcad BigAToo
(n=BigAToo@mail.fbcelkhart.org) |
| 00:07.38 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 00:48.16 |
brlcad |
wow |
| 00:48.28 |
brlcad |
so
preliminary slot allocations were announced |
| 00:48.37 |
brlcad |
checks to see if I'm allowed to share |
| 00:48.47 |
``Erik |
w00t, 0! go
us! |
| 00:49.27 |
brlcad |
hehe |
| 00:50.10 |
brlcad |
looks like
five orgs didn't get their allocations in |
| 00:50.10 |
``Erik |
is kinda surprised at how many most projects got O.o 2 are a
bit lower than I'd expect to see in the
announcemen |
| 00:50.25 |
brlcad |
``Erik: very
likely they asked for that few |
| 00:50.31 |
brlcad |
especially if
they're returning |
| 00:50.39 |
``Erik |
3 |
| 00:50.41 |
brlcad |
'most'
returning get what they ask for |
| 00:50.43 |
``Erik |
um, |
| 00:50.46 |
``Erik |
"bit lower"
as in 0 |
| 00:50.53 |
brlcad |
ah, read the
prolog |
| 00:50.59 |
brlcad |
0 means they
were stupid |
| 00:51.11 |
brlcad |
didn't put
their count into the system |
| 00:52.32 |
``Erik |
*shrug* |
| 00:52.40 |
``Erik |
just a draft,
ain't nothin' set in stone yet |
| 00:53.28 |
brlcad |
yep, might go
down a slot or two |
| 00:53.49 |
brlcad |
but probably
not too likely |
| 00:54.31 |
brlcad |
``Erik: in
any regard, it's enough to rank -- going to keep it pretty simple
this year unless you feel compelled for the chart again |
| 00:54.52 |
``Erik |
huh? chart?
whu? |
| 00:54.53 |
brlcad |
I figure if
everyone marks their top five, they should all sort to the
top |
| 00:55.00 |
brlcad |
``Erik: last
year, the spreadsheet |
| 00:55.03 |
``Erik |
oh |
| 00:55.11 |
``Erik |
um, I read
them all, I haven't commented on any yet |
| 00:55.14 |
``Erik |
or
rated |
| 00:55.38 |
brlcad |
right, I know
:) |
| 00:55.40 |
brlcad |
time to rate
:) |
| 00:55.42 |
``Erik |
I think I
might need to re-read and take notes, and try to correlate a couple
irc names to handles |
| 00:55.52 |
``Erik |
er,
proposals |
| 00:56.00 |
brlcad |
only really
need to rank your top five most interesting |
| 00:56.37 |
``Erik |
a couple of
them, I don't think I understand them well enough to know if I
think they're interesting |
| 00:56.38 |
brlcad |
I marked two
categories already, one for returning and another for what I
thought were really good applications |
| 00:56.57 |
brlcad |
and I believe
daniel has ranked too |
| 00:57.35 |
``Erik |
can see pros and cons to returning, not entirely sure how he
feels on that subject |
| 00:57.35 |
brlcad |
and I think
he basically picked his favorite |
| 00:58.11 |
brlcad |
yeah, I went
back and forth but there's been a general consensus that returning
for one year is cool |
| 00:58.15 |
brlcad |
two years,
not so cool |
| 00:58.19 |
``Erik |
I imagine I'm
not going to be assigned an explicit project, will just be a swiss
army knife |
| 00:58.49 |
brlcad |
it's up to
you, I was planning/hoping you would unless you want to do the
admin evals at mid/final :) |
| 00:59.09 |
``Erik |
nothing this
year has really jumped out at me quite like last years batch
did |
| 00:59.24 |
brlcad |
maybe that's
a good thing :) |
| 01:00.18 |
brlcad |
starseeker:
same for you, time to rank -- let me know if you have
questions |
| 01:00.23 |
brlcad |
yukonbob: too
:) |
| 01:04.05 |
brlcad |
(decided to
not share the slot count for anyone keeping track since it's not
final) |
| 01:05.45 |
brlcad |
wow, some of
the umbrella orgs have really stepped it up slot-wise this
year |
| 01:08.10 |
brlcad |
and wow, way
to go elena .. whipped up a drupal module for her patch
:) |
| 01:13.06 |
Ralith |
oh yeah,
brlcad, I'll have those milestones written up by sunday,
k? |
| 01:14.03 |
Ralith |
unless you
want it sooner |
| 01:15.26 |
brlcad |
Ralith: I
think that'll be okay |
| 01:15.42 |
brlcad |
Ralith:
curious, of your two projects -- is either more appealing than the
other? |
| 01:16.03 |
brlcad |
or better
put, do you think you could enjoy working on either? |
| 01:16.47 |
Ralith |
I would enjoy
both; I'd probably enjoy any not-incredibly-frustrating opportunity
to make a useful contribution in a way that takes advantage of my
skills. |
| 01:16.55 |
Ralith |
that's not to
say I consider them equal, though |
| 01:17.55 |
Ralith |
I'm a little
less confident about the GUI project as it's less well defined, but
I'm very excited to work on it and bring us that much closer to a
modern, userfriendly GUI. |
| 01:18.19 |
Ralith |
whereas the
TCL work is fairly mundane, but I expect still rewarding, as we
discussed. |
| 01:31.16 |
``Erik |
ooh, krod
mandoon in half an hour |
| 01:34.24 |
yukonbob |
views submissions.... |
| 01:38.28 |
yukonbob |
remind me:
Are the "private comments" private w/i the group of mentors, or
private between the student and a single mentor? |
| 01:38.34 |
yukonbob |
``Erik:
---^ |
| 01:38.42 |
yukonbob |
brlcad:
--^ |
| 01:42.04 |
yukonbob |
nm. |
| 01:48.15 |
brlcad |
yukonbob:
private amongst mentors |
| 01:48.22 |
yukonbob |
saw :) |
| 01:48.27 |
brlcad |
see some of
the other existing ones that have comments |
| 01:49.05 |
brlcad |
``erik,
starseeker, yukonbob: be sure to mark any you're willing to mentor
too |
| 01:49.17 |
brlcad |
I can't sign
you up for anything |
| 01:53.08 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 02:08.59 |
*** join/#brlcad PrezKennedy
(n=Matthew@whitecalf.net) |
| 02:09.39 |
yukonbob |
hey
pacman87 |
| 02:09.44 |
yukonbob |
,
PrezKennedy |
| 02:09.48 |
pacman87 |
hi
yukonbob |
| 02:09.53 |
PrezKennedy |
hey
yukonbob |
| 02:25.44 |
``Erik |
knows, has been through this once before
:) |
| 02:30.52 |
yukonbob |
packs out... little more reviewing to do, but is really
pretty easy decision making... |
| 02:58.24 |
*** join/#brlcad madant
(n=d@117.196.129.215) |
| 03:32.37 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.202.25) |
| 03:40.19 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 03:47.54 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.202.25) |
| 03:53.54 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 03:56.43 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 04:08.02 |
starseeker |
brlcad: are
we tracking anywhere who has submitted patches? |
| 05:36.39 |
dreeves |
brlcad you
there? |
| 05:37.10 |
dreeves |
starseeker
you around? |
| 05:59.25 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 06:17.20 |
yukonbob |
dreeves: best
way to ask a question is typically just ask... despite IRC being
realtime, everybody isn't glued here all the time... we do read
scrollback, though :) |
| 06:36.12 |
pacman87 |
the ones who
are glued here all the time fall under the 'against their will'
category in: |
| 06:36.14 |
pacman87 |
~ask |
| 06:36.36 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
| 06:37.04 |
yukonbob |
waves to pacman87 |
| 06:37.10 |
pacman87 |
waves back |
| 06:37.23 |
yukonbob |
late in
Texas, isn't it? |
| 06:37.31 |
pacman87 |
i'm currently
working on my tetris program for the 6811 |
| 06:37.36 |
pacman87 |
yeah, 1:40
am |
| 06:37.45 |
pacman87 |
first class
is at 2pm, though |
| 06:37.51 |
yukonbob |
nods |
| 06:38.00 |
yukonbob |
no work for
me tmo... Good Friday |
| 06:38.16 |
pacman87 |
and i was up
til 4am last night doing the circuit board layout |
| 06:58.54 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 06:59.39 |
*** join/#brlcad madant_
(n=d@117.196.147.30) |
| 07:15.35 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 07:49.55 |
*** join/#brlcad madant
(n=d@117.196.144.18) |
| 08:42.50 |
brlcad |
starseeker:
pretty much in my head, you're welcome to ask them
though |
| 08:51.11 |
*** join/#brlcad madant
(n=d@117.196.145.103) |
| 08:51.15 |
hippieindamakin8 |
gmorning
folks |
| 08:53.22 |
brlcad |
howdy
hippieindamakin8 |
| 08:53.54 |
hippieindamakin8 |
brlcad, yeah
abt the patch i ll be able to submit it in by sunday |
| 08:54.32 |
pacman87 |
wanders off to sleep |
| 08:54.47 |
madant |
follows pacman87 |
| 09:40.13 |
*** join/#brlcad madant_
(n=d@117.196.135.83) |
| 10:19.20 |
*** join/#brlcad madant
(n=d@117.196.143.58) |
| 10:19.31 |
madant |
~sleep |
| 10:19.41 |
ibot |
methinks
sleep is overrated, and a poor substitute for caffeine. |
| 11:11.26 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:04.02 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 12:09.54 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 12:10.27 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 12:10.27 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 12:46.36 |
``Erik |
*yawn* |
| 13:20.52 |
*** join/#brlcad CIA-28
(n=CIA@208.69.182.149.simpli.biz) |
| 13:43.05 |
starseeker |
dreeves:
sorry, I was out cold |
| 13:43.07 |
starseeker |
what's
up? |
| 13:43.48 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 13:44.47 |
dreeves |
starseeker
that's alright I think I figured out what I was going to ask
you |
| 13:46.40 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 14:05.41 |
*** join/#brlcad BigAToo
(n=BigAToo@96.230.124.155) |
| 15:37.35 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-182-70.dsl.lgtpmi.sbcglobal.net) |
| 16:08.04 |
brlcad |
loves this: http://bzflag.bz/tmp/push_button.png |
| 16:20.54 |
pacman87 |
someone wrote
that on the hand dryer in our bathroom |
| 16:40.48 |
*** join/#brlcad dreeves
(n=c752f347@bz.bzflag.bz) |
| 16:48.14 |
``Erik |
free pizza,
w00t |
| 16:48.27 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 19:33.54 |
``Erik |
huh http://www.indiangeek.net/programmer-competency-matrix/ |
| 21:11.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 21:11.56 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 21:26.39 |
*** join/#brlcad Malyce
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 21:28.11 |
Malyce |
hi, I was
trying to make a makefile for the coreInterface code |
| 21:28.38 |
Malyce |
I wasn't sure
exactly how to link the coreInterface files to the already built
brl-cad files |
| 21:28.59 |
Malyce |
I am thinking
the easiest way would be to append to the already existing
makefile |
| 21:29.04 |
Malyce |
for the main
code |
| 21:29.30 |
Malyce |
but, it is
too complex, and I am having trouble understanding it |
| 21:33.57 |
yukonbob |
``Erik: re:
matrix -- "Level 3: maintains a blog with personal insights and
thoughts on programming" |
| 21:39.30 |
``Erik |
it's an
amusing matrix from a winiot newb dev, wouldn't put a lot of stock
in it, but it was amusing :) |
| 21:40.16 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 21:44.56 |
*** join/#brlcad Malyce2
(n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 21:50.43 |
yukonbob |
``Erik: re:
putting stock in: agreed, but a bit interesting... |
| 21:50.53 |
yukonbob |
``Erik: so...
.where's your blog? |
| 21:50.54 |
yukonbob |
:) |
| 21:57.27 |
``Erik |
I have a
blog? |
| 21:59.47 |
Malyce2 |
You have a
blog ? |
| 22:16.57 |
Malyce2 |
soooo, noone
to talk to here ? |
| 22:17.01 |
``Erik |
ssh |
| 22:17.07 |
yukonbob |
we're
sleeping here!! |
| 22:17.09 |
``Erik |
we're trying
to lurk here |
| 22:17.21 |
yukonbob |
sleeps, ``Erik lurks |
| 22:17.34 |
archivist |
admits nothing |
| 22:17.38 |
``Erik |
in the
shadows... waiting to pounce |
| 22:17.45 |
``Erik |
stalks his 12oz prey o.O |
| 22:17.46 |
Ralith |
admits everything! |
| 22:17.50 |
yukonbob |
like a
puma? |
| 22:18.03 |
Malyce2 |
is
bored |
| 22:18.13 |
yukonbob |
Malyce2:
write a patch? |
| 22:18.15 |
alex_joni |
bored? what
is that? |
| 22:18.20 |
Malyce2 |
how do you
guys keep changing your statuses ? |
| 22:18.25 |
yukonbob |
model a
moose? |
| 22:18.30 |
Malyce2 |
That's what I
yam doin |
| 22:18.31 |
alex_joni |
a
supercow |
| 22:18.38 |
Ralith |
a tron
cycle |
| 22:18.39 |
Malyce2 |
That's who I
am, supercow |
| 22:18.40 |
``Erik |
looks at the patch ideas, bug list, todo lists, etc and
wonders how ANYONE could be bored around here
O.o |
| 22:18.44 |
yukonbob |
Ralith++ |
| 22:18.56 |
Malyce2 |
hey, so abt
the makefile thingie |
| 22:19.07 |
Ralith |
boredom is
what happens when you refuse to let yourself do
something. |
| 22:19.14 |
``Erik |
http://www.onlinegamingradio.com/wp-content/uploads/2009/02/tron_guy.jpg
<-- ralith |
| 22:19.42 |
yukonbob |
!HA |
| 22:19.46 |
Malyce2 |
since I am
working with coreInterface, I am making my own makefile. I don't
know how to link it to the already built brl-cad
libraries |
| 22:19.49 |
Malyce2 |
no clue
? |
| 22:20.03 |
``Erik |
probably
something like "-L/usr/brlcad/lib -lrt" |
| 22:20.12 |
Ralith |
don't
hardcode that though |
| 22:20.14 |
Ralith |
get it from
pkgconfig |
| 22:20.39 |
Malyce2 |
I haven't
done this before, and the tut's don't say anything. |
| 22:21.02 |
Malyce2 |
Am I not also
suppose to link with the headers and C files from the main brl-cad
? |
| 22:21.03 |
Ralith |
you using
cmake or GBS? |
| 22:21.08 |
Malyce2 |
GBS |
| 22:21.21 |
Ralith |
google up
some docs |
| 22:21.30 |
Malyce2 |
not used to
working with large projs, so noob here |
| 22:21.33 |
Ralith |
it's not too
hard to set up a simple project and get linker flags from
pkgconfig |
| 22:21.48 |
Malyce2 |
I'll look it
up |
| 22:22.11 |
yukonbob |
thinks he likes cmake |
| 22:22.17 |
Ralith |
likes cmake too. |
| 22:22.31 |
``Erik |
rt^3 should
have autoconf stuff that fills that all in for you,
though |
| 22:22.34 |
Ralith |
y'still want
to use pkgconfig to get paths, though |
| 22:22.59 |
Ralith |
was amazed that nobody had noticed the pkg-config files were
broken. |
| 22:23.03 |
yukonbob |
_does_ wonder why they're inventing a new language though,
instead of intergrating something like python or tcl, which are
finished languages with less-goffy syntax :P |
| 22:23.14 |
yukonbob |
*less-goofy |
| 22:23.18 |
Ralith |
yukonbob:
fewer dependencies perhaps? |
| 22:23.29 |
``Erik |
because those
who don't learn history are doomed to repeat it |
| 22:23.36 |
yukonbob |
``Erik++ |
| 22:23.38 |
Malyce2 |
I am not
using all of rt^3 |
| 22:23.44 |
yukonbob |
Ralith: tcl
is so light, it's stupid. |
| 22:23.48 |
Malyce2 |
only
CoreInterface. You recommend getting all of it ? |
| 22:23.58 |
``Erik |
so? do the
autoconf cycle, run ./configure, then cd into the coreInterface
directory and do maket here |
| 22:24.19 |
``Erik |
or build it
all, once that's done, only your changes will be recompiled,
unchanged stuff will just sit there |
| 22:24.43 |
Ralith |
yukonbob:
owell. |
| 22:24.52 |
Ralith |
cmake is
nevertheless shiny. |
| 22:25.08 |
yukonbob |
nods... |
| 22:25.15 |
``Erik |
so're the 12
other popular auto* imitations |
| 22:25.25 |
yukonbob |
easier for me
to wrap brain around than auto*, libtool, etc. |
| 22:27.25 |
yukonbob |
``Erik: only
other systems I've played with are hand-coded Makefile (great for
trivial tasks), scons, and cmake |
| 22:27.47 |
yukonbob |
java has a
few, but unfortunately are java-bases ;P |
| 22:27.51 |
yukonbob |
*based |
| 22:27.56 |
yukonbob |
(ant) |
| 22:27.57 |
``Erik |
eck, ant
*shudder* |
| 22:28.36 |
``Erik |
auto* is one
of those things where it's all magic and confusing, then there's a
eureka moment and you kick yourself for not seeing it
before |
| 22:28.37 |
Ralith |
I like
cmake's skill at finding deps even with few hints and its
percentful output |
| 22:28.42 |
yukonbob |
"enterprise"
class (i.e.: requires a contract with consultants to make work
reasonably) |
| 22:29.01 |
Ralith |
percent
complete is awesome to have. |
| 22:29.04 |
``Erik |
it's all
really really super-simple, but it does impressive stuff... so
people assume there's more to it :( it's really simple substitution
rules |
| 22:29.18 |
yukonbob |
does _not_ like the %-full output, or the colours... but
feh. |
| 22:29.24 |
Ralith |
colors aren't
necessary |
| 22:29.39 |
Ralith |
but don't
tell me you've never been staring at a firefox build wondering just
how far along it is |
| 22:30.03 |
Ralith |
even if it's
no ETA, it's nice to know whether you're just beginning or about to
finish. |
| 22:30.12 |
``Erik |
runs system update builds in another window and goes to do
other stuff |
| 22:30.23 |
``Erik |
staring at it
won't make it go faster |
| 22:30.32 |
Ralith |
lies! |
| 22:30.35 |
``Erik |
:D what's the
phrase, a watched pot never boils? |
| 22:30.53 |
Ralith |
the problem
is when 'other stuff' conflicts with the build |
| 22:30.56 |
yukonbob |
even a stoped
clock gives the right time, twice a day? |
| 22:31.04 |
yukonbob |
a stich in
time saves 9? |
| 22:31.07 |
Ralith |
e.g.
installing other stuff, fiddling with X, rebooting for w/e
reason... |
| 22:31.16 |
Ralith |
not common
cases but really annoying when they come up |
| 22:31.18 |
``Erik |
a penny saved
is a penny *smacks yukonbob* |
| 22:31.19 |
yukonbob |
let sleeping
dogs lie |
| 22:31.26 |
yukonbob |
LOL |
| 22:31.41 |
yukonbob |
is channelling "too much coffee man vs. cliche
man" |
| 22:32.22 |
yukonbob |
``Erik:
interstingly, your reply is similar to what gave tmcm the edge in
the battle. |
| 22:32.40 |
``Erik |
tmcm? |
| 22:33.14 |
``Erik |
too much
coffee man |
| 22:33.41 |
``Erik |
not on my
usual webcomic rotation |
| 22:33.54 |
yukonbob |
http://library.buffalo.edu/libraries/asl/guides/graphicnovels/img/Coffee1.jpg |
| 22:35.52 |
yukonbob |
http://comixtalk.com/images/july2006/coffee2.png |
| 22:37.29 |
``Erik |
or, uh,
http://www.tmcm.com/comics/webcomics/001_waste
? |
| 22:39.27 |
*** join/#brlcad madant
(n=d@117.196.128.204) |
| 22:42.22 |
*** join/#brlcad Malyce
(n=ubuntu@deimos.jacobs-university.de) |
| 22:58.52 |
Malyce |
why is the
firefox browser in ubuntu, so ridiculously slow ? |
| 22:59.08 |
Malyce |
it really
sucks compared to firefox in windows |
| 23:02.17 |
Malyce |
And I don't
mean the internetss . This app hangs like every 2 secs |
| 23:08.25 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 23:19.42 |
Ralith |
Malyce: it's
not. |
| 23:19.55 |
Ralith |
well, not in
the sense you describe anyway |
| 23:22.09 |
Malyce |
maybe its
because I have Ubuntu mid right now |
| 23:22.40 |
Malyce |
its supposed
to be for Intel Atom processors. But, I find it hard to believe
that any Ubuntu distro would run slower than windows |
| 23:33.25 |
``Erik |
might be
worth monitoring your memory and swap utilization |
| 23:34.43 |
*** join/#brlcad Malyce
(n=ubuntu@deimos.jacobs-university.de) |
| 23:39.32 |
starseeker |
dreeves:
IIRC, the next step for brep is incorporating Utah's
trimming? |
| 23:43.18 |
Ralith |
Malyce: what
normally causes that kind of behavior is you having far too little
memory for what you're trying to do |
| 23:48.48 |
Malyce |
could be
true. Windoze does sometimes lag, because this is a low-end machine
with only 512 megs. But, its seems to handle it much
better |
| 23:49.20 |
Malyce |
I think I
will experiment with other distros, and see |
| 23:59.58 |
Ralith |
this is
probably because you are not trying to run as many apps in
windows. |
| 00:08.28 |
*** join/#brlcad dreeves2
(n=4b407196@bz.bzflag.bz) |
| 00:09.22 |
dreeves2 |
starseeker
was there a reason you were asking about trimming or were you just
curious about status? |
| 00:18.14 |
yukonbob |
dreeves needs
to be told about bitchx, irssi, or similar, and perhaps screen and
some always-on account... |
| 00:18.52 |
yukonbob |
dreeves:
-----^ |
| 00:19.23 |
yukonbob |
(if your
physical self is indeed associated with this network
instance) |
| 00:29.09 |
*** join/#brlcad dreeves2
(n=4b407196@bz.bzflag.bz) |
| 00:47.52 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 01:14.26 |
*** join/#brlcad dreeves2
(i=dreeves@c-75-64-113-150.hsd1.tn.comcast.net) |
| 01:15.26 |
dreeves2 |
hey
starseeker |
| 01:21.37 |
yukonbob |
dreeves2: are
you still 'attached' to the dreeves instance here? |
| 01:29.16 |
dreeves2 |
I'm not near
that computer currently why? |
| 01:35.59 |
yukonbob |
dreeves2:
just wondering why you're logged in 2x ;) -- I noticed you're
earlier (and this?) client was a cgi gateway, and suggested you get
irssi/screen/ and some always-on account, but apparently you're
already setup :) |
| 01:36.17 |
yukonbob |
s/you're
earlier/your earlier/ |
| 01:45.05 |
dreeves2 |
umm no I just
downloaded another client here but that is a good suggestion I have
been thinking I need to get that. I will look into that
later |
| 02:04.31 |
*** join/#brlcad smurfette
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) |
| 02:05.50 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 02:37.59 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 02:38.36 |
*** join/#brlcad smurfette
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad dreeves2
(i=dreeves@c-75-64-113-150.hsd1.tn.comcast.net) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad madant (n=d@117.196.128.7) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 02:38.36 |
*** join/#brlcad dreeves (n=dreeves@64.178.177.71) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 02:38.36 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 02:38.36 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 02:38.36 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 02:43.48 |
*** join/#brlcad smurfette
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad dreeves2
(i=dreeves@c-75-64-113-150.hsd1.tn.comcast.net) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 02:43.48 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 02:43.48 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 02:43.48 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 02:43.48 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 02:43.48 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:45.20 |
*** join/#brlcad madant (n=d@117.196.128.7) [NETSPLIT
VICTIM] |
| 02:45.57 |
*** join/#brlcad dreeves (n=dreeves@64.178.177.71) [NETSPLIT
VICTIM] |
| 02:54.05 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 02:56.27 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:56.49 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 03:19.18 |
*** join/#brlcad PrezKennedyIII
(i=Matthew@whitecalf.net) |
| 05:38.31 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 05:38.31 |
*** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 05:50.26 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 05:50.26 |
*** join/#brlcad kanzure (i=bryan@66.112.232.233) [NETSPLIT
VICTIM] |
| 06:38.30 |
*** join/#brlcad cad67
(n=50fa0d86@bz.bzflag.bz) |
| 07:36.14 |
*** join/#brlcad madant
(n=d@117.196.139.22) |
| 08:18.17 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 08:44.47 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:02.55 |
*** join/#brlcad madant_
(n=d@117.196.142.36) |
| 10:20.42 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 10:41.10 |
*** join/#brlcad Malyce
(n=ubuntu@deimos.jacobs-university.de) |
| 10:42.43 |
Malyce |
I built
brlcad with 'make' in /home/ubuntu/brl-sf I ran ./configure
--prefix=/home/ubuntu/brl-sf for the rt^3 module |
| 10:42.45 |
Malyce |
http://bzflag.pastebin.ca/1389557 |
| 10:43.19 |
Malyce |
the
./configure went fine, but make died |
| 10:45.24 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 12:36.37 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 13:35.41 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 14:38.15 |
*** join/#brlcad elite01_
(n=omg@unaffiliated/elite01) |
| 14:48.05 |
*** join/#brlcad Malyce
(n=ubuntu@wlanaccess-ext.jacobs-university.de) |
| 15:18.09 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 15:44.13 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 16:21.48 |
*** join/#brlcad clark8
(n=DarioDJ@host22-201-dynamic.55-82-r.retail.telecomitalia.it) |
| 16:22.09 |
clark8 |
ei |
| 16:22.59 |
*** part/#brlcad clark8
(n=DarioDJ@host22-201-dynamic.55-82-r.retail.telecomitalia.it) |
| 16:50.48 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 18:43.17 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 19:30.36 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 20:16.00 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 20:30.56 |
*** join/#brlcad madant
(n=d@117.196.142.36) |
| 20:32.16 |
*** join/#brlcad FAMULUS
(n=mark@ool-ad028f27.dyn.optonline.net) |
| 20:34.04 |
FAMULUS |
are there
improvements to g-stl since version 7.12.2? |
| 20:34.35 |
FAMULUS |
g-stl is slow
as molasses |
| 20:42.24 |
tofu |
FAMULUS: not
any changes that will affect it's performance |
| 20:42.27 |
tofu |
patches
welcome ;) |
| 20:44.29 |
Ralith |
FAMULUS:
eventually it'll get deprecated by brep based stuff |
| 20:44.45 |
tofu |
not really,
at least not g-stl |
| 20:45.11 |
tofu |
stl is a
polygonal format -- going through the brep routines might make some
things that used to fail no longer fail |
| 20:45.47 |
tofu |
but the
reason it takes a long time is because it's trying to verify that
the mesh being exported is clean with normals facing outward and
solid |
| 20:46.05 |
tofu |
expensive
operation that wouldn't go away with brep necessarily |
| 20:46.37 |
tofu |
FAMULUS: you
could use the newer bot_dump command that is MUCH faster (as it
makes absolutely no attempt to verify anything being
exported |
| 20:47.02 |
Ralith |
I got the
impression that brep would make mesh generation relatively
reliable, lessening the need for verif. |
| 20:47.52 |
tofu |
sure, more
robust for the things that presently fail (which is like approx
< 1% of geometry, but prevalent enough) |
| 20:48.01 |
FAMULUS |
hey
guys |
| 20:48.06 |
tofu |
still, that's
just not the time-intensive step |
| 20:48.41 |
FAMULUS |
tofu: would
bot_dump be expected to produce usable STL files? |
| 20:48.49 |
tofu |
you can not
do that verification now (hence bot_dump), it's more supposed to be
a guarantee of a solid modeling system to always import/export
solid objects |
| 20:49.07 |
tofu |
FAMULUS: sure
stl is a stupid format |
| 20:49.12 |
tofu |
it doesn't
care |
| 20:49.28 |
tofu |
just if you
feed that STL into another solid modeling system, it may or may not
work |
| 20:49.43 |
tofu |
as it may or
may not be solid |
| 20:49.48 |
FAMULUS |
my target
would be a rapid prototyper |
| 20:50.17 |
tofu |
ideally for a
rapid prototyper, I'd expect a need for solid geometry |
| 20:50.29 |
tofu |
but then
there are lots of other variables |
| 20:50.37 |
FAMULUS |
tofu: ok, so
g-stl is the only way to got now |
| 20:51.03 |
tofu |
if you have a
rapid prototyping system that takes stl inputs, it may very well
clean up on import too or have other ways of dealing with non-solid
mesh geometry |
| 20:51.32 |
tofu |
no, I"d say
try bot_dump out if performance is really a problem and not just an
annoyance, see what the impact is |
| 20:51.49 |
tofu |
otherwise,
make it better ;) |
| 20:51.52 |
FAMULUS |
tofu: ok,
that's my project for today |
| 20:52.02 |
tofu |
the
verification/closure algorithm isn't optimized, I'm
sure |
| 20:52.08 |
FAMULUS |
tofu: my stls
take like days, it's a non starter |
| 20:52.20 |
tofu |
how big of a
mesh? |
| 20:52.31 |
FAMULUS |
10,000
triangesl |
| 20:52.37 |
FAMULUS |
for smaller
pieces |
| 20:52.39 |
tofu |
that's not
that big |
| 20:52.42 |
FAMULUS |
but large
ones |
| 20:52.43 |
tofu |
how many
objects? |
| 20:52.57 |
FAMULUS |
good
question, one sec |
| 20:54.35 |
tofu |
another
issue, stil files are "single object" files, so if you have a
hierarchy or big assembly of objects, the code has to combine them
all into one collection |
| 20:54.54 |
tofu |
that
unification can take a long (O(N^3)) time |
| 20:55.27 |
FAMULUS |
tofu: how do
I get count directly, I can't copy from mged terminal |
| 20:56.43 |
Ralith |
tofu: really?
I would have imagined that traversing even a large tree would be
pretty fast, in human terms |
| 20:57.02 |
Ralith |
performing
all the boolean ops on meshes, perhaps less so |
| 20:57.14 |
FAMULUS |
I'd guess
~200 objects |
| 20:57.43 |
tofu |
nothing to do
with traversing the tree, it's the "merge mesh A into mesh B,
performing pairwise tests across the sets, them merge in mesh C and
do that again, then merge in mesh D, etd etc |
| 20:57.50 |
FAMULUS |
http://prometheusfusionperfection.wordpress.com/2009/02/09/chassis-redesign/ |
| 20:57.58 |
FAMULUS |
this is the
part |
| 20:59.02 |
tofu |
hm, yeah -- I
bet it's the way you're doing your booleans causing it to be a
worst case N^3 |
| 20:59.11 |
tofu |
did you make
any reqgions? |
| 20:59.14 |
tofu |
regions |
| 20:59.21 |
FAMULUS |
tofu: I
think |
| 20:59.22 |
Ralith |
FAMULUS: you
modeled that in mged? Nice! |
| 20:59.38 |
FAMULUS |
`#{mged} 'r
torus_negative#{index} u torus_negative_outer#{index} -
torus_negative_inner#{index} '` #this hollow center of the
torus |
| 20:59.52 |
FAMULUS |
Ralith: ruby
emitting mged commands |
| 21:00.04 |
Ralith |
still
nice. |
| 21:00.05 |
Ralith |
very
pretty. |
| 21:00.09 |
FAMULUS |
Ralith:
thanks! |
| 21:00.12 |
Ralith |
what is
it? |
| 21:00.19 |
hippieindamakin8 |
FAMULUS,
Ralith +1 |
| 21:00.29 |
FAMULUS |
It's a fusion
reactor core |
| 21:00.53 |
FAMULUS |
Ralith:
about: http://prometheusfusionperfection.wordpress.com/about/ |
| 21:00.55 |
Ralith |
and you plan
on rapid prototyping it? O.o |
| 21:01.03 |
``Erik |
the topology
verifier is superlinear, it's an unavoidable suck. B-rep/NURB will
only make it not suck if everything is in nurbs |
| 21:01.42 |
``Erik |
(make mged
accept ruby statements, then we'll be impressed ;) |
| 21:01.47 |
FAMULUS |
Ralith:
alread got test parts:
http://prometheusfusionperfection.wordpress.com/2009/02/20/manifest/ |
| 21:02.15 |
Ralith |
cool! |
| 21:02.19 |
Ralith |
best of luck
to you. |
| 21:03.20 |
Ralith |
are you
expecting to get positive net energy? |
| 21:03.40 |
FAMULUS |
Ralith:
supposedly it's possible with bussard reactor |
| 21:03.48 |
FAMULUS |
Ralith: my
goal for now is first fusion |
| 21:03.59 |
Ralith |
you realize
that research teams with millions in funding haven't managed
that. |
| 21:04.06 |
FAMULUS |
Ralith: I
know |
| 21:04.07 |
tofu |
FAMULUS: it
might take a while for someone to look into it, but you could post
your .g file up somewhere (maybe to the sf.net tracker) to
investigate if there's something simple that can be done to speed
things up |
| 21:04.22 |
FAMULUS |
Ralith:
that's why it's so exciting |
| 21:05.51 |
FAMULUS |
Ralith: the
fusor (the precursor to bussard reactor) has a long tradition of
amateurs (14 or so) |
| 21:06.00 |
FAMULUS |
Ralith: so
it's not unreasonable to think it possible |
| 21:07.12 |
Ralith |
I imagine
so. |
| 21:07.22 |
Ralith |
nevertheless,
you'll embarass a lot of people if you manage |
| 21:08.46 |
Ralith |
looks like
you have a pretty good idea what you're doing,
certainly |
| 21:09.20 |
``Erik |
embarrassing
a lot of people is a good thing |
| 21:09.24 |
FAMULUS |
Ralith: I
lean alot alot every day |
| 21:09.30 |
FAMULUS |
learn^ |
| 21:09.34 |
``Erik |
it's a loud
"get your head out of your ass" |
| 21:09.40 |
``Erik |
also; "a lot"
is two words |
| 21:10.27 |
Ralith |
embarassing
people is indeed positive. |
| 21:10.33 |
Ralith |
especially
people with millions of dollars. |
| 21:11.39 |
FAMULUS |
Ralith: I got
to get mged working before any embarassing happens!~ |
| 21:11.48 |
Ralith |
heh |
| 21:12.06 |
FAMULUS |
brb, heading
to cafe. |
| 21:20.02 |
Ralith |
tofu: just
how fast *is* bot_dump? |
| 21:20.14 |
Ralith |
fast enough
to use it for shaded rendering? |
| 21:22.13 |
*** join/#brlcad FAMULUS
(n=mark@pool-98-116-35-99.nycmny.east.verizon.net) |
| 21:25.43 |
``Erik |
no |
| 21:26.04 |
Ralith |
damn. |
| 21:26.33 |
FAMULUS |
tofu: is
bot_dump available in 7.12.2? |
| 21:29.52 |
Ralith |
FAMULUS: any
reason not to update? |
| 21:30.18 |
Ralith |
also: I
suspect most rapid prototyping services are used to recieving
non-solid STLs from graphic artists and such, so you'll probably be
ok |
| 21:30.45 |
``Erik |
I suspect
most of them charge a fair amount if they have to 'fix' the
geometry |
| 21:31.38 |
CIA-28 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1382 10/wiki/User:Ralith: Added first draft of milestones for
OpenGL GUI SoC proposal |
| 21:32.09 |
Ralith |
I'd be
surprised |
| 21:32.11 |
``Erik |
ralith: iirc,
bot_dump expects bot geometry and just walks the tree dumping raw
numbers |
| 21:32.13 |
Ralith |
but I haven't
done it. |
| 21:32.30 |
Ralith |
``Erik: er,
so not at all useful for generating tesselations of solid
models? |
| 21:32.57 |
``Erik |
a sphere, for
example, is not a bot, so does not dump directly. Would have to go
through the NMG pass before being bot_dump-able |
| 21:33.32 |
``Erik |
we have some
pieces done in a 3d printer at the office, they take stl but they
have to be well defined stl's |
| 21:33.56 |
Ralith |
well, of
course. |
| 21:33.58 |
FAMULUS |
``Erik: does
bot_dump produce stls? |
| 21:34.03 |
Ralith |
brbs |
| 21:34.09 |
Ralith |
wtf, brlcad's
not here |
| 21:34.11 |
Ralith |
oh
well |
| 21:34.18 |
``Erik |
bot_dump
produces funky 'bot' files, but stl's aren't much
different |
| 21:34.43 |
``Erik |
uhhhhhhh, I
think there's a flag to g-stl to ignore topology verification,
which makes it really fast |
| 21:34.58 |
``Erik |
(if not,
there should be *hint* *hint*) |
| 21:36.25 |
FAMULUS |
``Erik: we'll
if I'm stuck with slow g-stl, I was thinking running on a ec2
instance |
| 21:36.38 |
FAMULUS |
``Erik: so I
can forget about it for a while |
| 21:36.51 |
``Erik |
technically,
BOT allows irregular geometry (the kind video game weenies
like) |
| 21:37.06 |
``Erik |
so
bot->printableSTL requires verification |
| 21:37.15 |
``Erik |
knowwutahmean,vern? |
| 21:37.21 |
FAMULUS |
``Erik: which
is what makes it slow |
| 21:37.31 |
``Erik |
ayup
:( |
| 21:37.32 |
FAMULUS |
so the
verification ^ |
| 21:38.02 |
FAMULUS |
``Erik: is
BRL-CAD easy to install on ubuntu |
| 21:38.18 |
``Erik |
I suspect so,
famulus... I don't use linux, so *shrug* |
| 21:38.49 |
``Erik |
I used to
maintain the debian port, but I lost my debian box due to political
cocksuckery |
| 21:39.35 |
``Erik |
"linux" is in
the regular maintenance path, though, so if you have the right deps
installed, it should compile easy |
| 21:39.53 |
FAMULUS |
ok |
| 21:40.05 |
``Erik |
(brlcad,
starseeker and I tend to use redhat mostly, I think starseeker uses
gentoo or something, as well) |
| 21:40.20 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 21:40.43 |
``Erik |
<-- hard
up on fbsd, brlcad is big on osX |
| 21:40.45 |
``Erik |
:) |
| 21:41.07 |
FAMULUS |
``Erik: my
laptop is os x, but EC2 would be ubuntu |
| 21:41.24 |
``Erik |
but we all
have a serious hardon for portability, so we drag it to solaris or
irix once in a while, and I'm big into 'mega' unix portability,
hpux and aix and those |
| 21:41.28 |
FAMULUS |
``Erik: I
can't let g-stl process for days, I need to close my
laptop |
| 21:41.47 |
``Erik |
even has an image sitting around for a BSD4.3 on
vax11/780 |
| 21:41.57 |
``Erik |
why do you
need to close it? |
| 21:42.06 |
``Erik |
I leave my
macbook open for, uh, months at a whack |
| 21:42.11 |
``Erik |
I only shut
it down when I have to fly |
| 21:42.14 |
FAMULUS |
``Erik: you
know, scene changes |
| 21:42.18 |
FAMULUS |
going to
work |
| 21:42.21 |
FAMULUS |
etc |
| 21:42.41 |
``Erik |
huh, well, if
you close your macbook, it sleeps, it doesn't shut down |
| 21:42.53 |
``Erik |
so when you
open it, it loads up the memory image and continues |
| 21:43.06 |
``Erik |
*shrug* |
| 21:43.16 |
FAMULUS |
``Erik:
true |
| 21:43.26 |
FAMULUS |
``Erik: but
you can't really use it without a plug |
| 21:43.31 |
FAMULUS |
``Erik: CPU
pegged |
| 21:43.37 |
``Erik |
"man
nice" |
| 21:43.45 |
``Erik |
"man
batch" |
| 21:44.10 |
FAMULUS |
``Erik: good
idea |
| 21:44.23 |
``Erik |
(leave the
laptop at home *cough*) |
| 21:45.03 |
FAMULUS |
``Erik:
that's what servers are for |
| 21:45.07 |
``Erik |
ayup |
| 21:45.29 |
``Erik |
I seem to be
saying "uh, start it on friday and come back on monday" a lot
lately :( |
| 21:45.30 |
FAMULUS |
``Erik: would
a g-stil web service be useful to community? |
| 21:45.48 |
``Erik |
I'd be
surprised |
| 21:46.00 |
``Erik |
the cost of
such a service would outweigh 99.9999% folks benefits |
| 21:46.23 |
``Erik |
feel free to
try it, but I don't think it'd be ... profitable? |
| 21:46.57 |
FAMULUS |
``Erik: so
I'm the only person with this issue? |
| 21:47.15 |
``Erik |
the "NMG is
slow" is a known issue |
| 21:48.47 |
FAMULUS |
n-manifold
geometry |
| 21:49.50 |
``Erik |
also called
"non-manifold geometry", sometimes both in the same documentation
:( |
| 21:50.06 |
``Erik |
(including,
apparently, the original paper Muuss did) |
| 21:50.14 |
Ralith |
heh |
| 21:50.38 |
``Erik |
was a topic
of discussion last thursday or so |
| 21:50.45 |
FAMULUS |
``Erik: I
don't see a wikipedia article for that |
| 21:50.53 |
Ralith |
FAMULUS: I'd
try disabling the verification in g-stl and sending off the
resultant file. Worst-case scenario, they ask you to send them a
fixed one. |
| 21:51.31 |
FAMULUS |
Ralith:
what's flag for that? |
| 21:51.40 |
Ralith |
no
idea |
| 21:51.50 |
Ralith |
as ``Erik
says, it may not exist. |
| 21:51.52 |
Ralith |
might not be
too hard to add. |
| 21:52.06 |
Ralith |
on an
unrelated note |
| 21:52.09 |
Ralith |
``Erik: you
mentoring? |
| 21:52.28 |
``Erik |
does not see such a flag |
| 21:52.42 |
FAMULUS |
``Erik:
vaporware |
| 21:52.43 |
``Erik |
um, I'm
listed as an admin and kinda thinking my roll will be admin, a
mentor for mentors |
| 21:53.06 |
Ralith |
that probably
works too. |
| 21:53.11 |
Ralith |
could I talk
ya into reviewing my milestones? |
| 21:53.21 |
``Erik |
though I'm
always willing to help with spot details here :) |
| 21:53.43 |
``Erik |
um, yeah, I
suppose I should look at the applicants, yes |
| 21:53.47 |
Ralith |
hehe |
| 21:53.48 |
hippieindamakin8 |
Ralith, done
with the patch ? |
| 21:53.52 |
Ralith |
what
patch |
| 21:53.59 |
``Erik |
we kinda
request a patch up front |
| 21:54.08 |
Ralith |
oh
that |
| 21:54.16 |
``Erik |
to verify
that you know how to code, can use the VCS, etc |
| 21:54.21 |
Ralith |
well,
considering that I've made several miscellaneous commits in the
last few weeks... |
| 21:54.21 |
hippieindamakin8 |
is working on it now :|.. |
| 21:54.29 |
``Erik |
nothin' big,
but it's a stumbling block for many |
| 21:54.30 |
Ralith |
I think I've
got that covered. |
| 21:54.32 |
hippieindamakin8 |
Ralith, that
should do i guess |
| 21:54.58 |
hippieindamakin8 |
loves his fresh archlinux install |
| 21:55.07 |
Ralith |
``Erik:
unless I actually should find myself something else to code
up? |
| 21:55.13 |
Ralith |
perhaps this
g-stl flag, even. |
| 21:55.27 |
Ralith |
also that
reminds me |
| 21:55.42 |
Ralith |
FAMULUS:
getting BRL-CAD running on linux is easy, even if you have to
compile it by hand; I wouldn't be concerned. |
| 21:56.04 |
Ralith |
has ran it on every linux/unix system he's had, and it's
always been one of the easiest bits. |
| 21:56.14 |
FAMULUS |
Ralith: ok
good |
| 21:56.25 |
``Erik |
if you're
committing, you're already in the circle the patch is
for |
| 21:56.32 |
Ralith |
yeah, that's
what I thought. |
| 21:56.47 |
hippieindamakin8 |
Ralith, yeah
watever be the case.. most debian systems have the problem of the
missing libx11-dev files |
| 21:56.48 |
Ralith |
good to have
it confirmed. |
| 21:57.02 |
Ralith |
hippieindamakin8: er, can't you just
install libx11-dev then? |
| 21:57.04 |
hippieindamakin8 |
gets back to work .. :P |
| 21:57.15 |
FAMULUS |
``Erik: have
you guys though about using github? |
| 21:57.22 |
Ralith |
FAMULUS: to
host the repo? O.o |
| 21:57.27 |
``Erik |
erm |
| 21:57.29 |
FAMULUS |
``Erik: makes
it easier to contribute I think |
| 21:57.33 |
hippieindamakin8 |
Ralith, yeah
, u have to :) |
| 21:57.34 |
Ralith |
changing
versioning systems would be a huge deal. |
| 21:57.40 |
Ralith |
hippieindamakin8: well of course you
do |
| 21:57.42 |
Ralith |
but that's
trivial |
| 21:57.44 |
kanzure |
does the
svn-to-git software even work yet? |
| 21:58.04 |
``Erik |
we just went
through the pain of cvs->svn, and I think we like the
centralized VCS |
| 21:58.04 |
``Erik |
:) |
| 21:58.04 |
Ralith |
does like how arch installs headers with everything,
though |
| 21:58.13 |
hippieindamakin8 |
Ralith,
exactly :) |
| 21:58.16 |
``Erik |
effin' HATES how one of his projects has deps that require:
CVS, SVN, darcs, git, ... |
| 21:58.32 |
``Erik |
ralith: if
you like that, check out one of the BSD's |
| 21:58.40 |
``Erik |
we've been
doin' it that way since, uh, the 80's |
| 21:58.40 |
``Erik |
:D |
| 21:58.41 |
Ralith |
I used to run
FreeBSD. |
| 21:58.47 |
Ralith |
I got tired
of waiting hours for firefox to compile :P |
| 21:58.51 |
``Erik |
hehehe |
| 21:58.56 |
Ralith |
arch is a
good compromise |
| 21:59.00 |
``Erik |
pkg_add can
grab a binary |
| 21:59.05 |
Ralith |
minimal and
dev-friendly, but binary-friendly too |
| 21:59.20 |
Ralith |
sure, it
*can*, but the system's really made to use sources, and binaries
can lead to problems |
| 21:59.28 |
``Erik |
*shrug*
whatever makes you happy :) I like fbsd myself, I'm ok with letting
a "portmanager -u -bu -l" run overnight |
| 21:59.42 |
``Erik |
ain't in no
rush these days |
| 21:59.47 |
Ralith |
I've been
knocking back and forth between sourcebased and binbased systems
for a while |
| 22:00.24 |
Ralith |
back on the
VC subject, I have to say, it's *really* nice to be able to do
local commits; helps keep commits small and focused on single
logical changes, and helps keep the main repo fully functional
(i.e. no half-implemented features) |
| 22:01.00 |
``Erik |
hm, do it in
the upstream VCS, mebbe one of your commits will be you fighting
something that someone has an easy answer for |
| 22:01.15 |
Ralith |
huh? |
| 22:01.24 |
``Erik |
if it's
broken, wrap the broken stuff in #if 0, if it's a big breakage,
make a branch |
| 22:01.31 |
Ralith |
sure, that
works |
| 22:01.34 |
Ralith |
but it's a
bit ugly |
| 22:01.53 |
``Erik |
if you commit
something small cuz you're struggling with a lame issue and brlcad
or drossberg or I say "well, dur, just do this", that might save
you many many many hours |
| 22:02.09 |
Ralith |
centralized
versioning encourages making commits relatively large. |
| 22:02.27 |
``Erik |
and my tire
iron encourages keeping them small and frequent |
| 22:02.28 |
``Erik |
O:-) |
| 22:02.30 |
Ralith |
hehe |
| 22:03.29 |
Ralith |
so how
closely are students expected to stick to their
timeline? |
| 22:03.50 |
Ralith |
I need to
write one up, but I really am not sure how much time to allocate to
any given milestone. |
| 22:03.52 |
``Erik |
students are
expected to communicate with their mentors |
| 22:04.55 |
tofu |
on the
contrary, to be *effective*, centralized requires small succinct
commits |
| 22:05.05 |
``Erik |
timelines
change, that's known, *shrug* can't do anything about it, it's
reality. but it's a big growing point in a developers growth to be
able to admit the change happens and work around it, opposed to
pretending it's a failure and trying to hiding it |
| 22:05.13 |
tofu |
at best a
different work breakdown structure, so that you can work on small
pieces that are all fully functional |
| 22:05.36 |
``Erik |
tofu: to be
effective, yes, but some people don't want to present code until
it's "perfect" :( |
| 22:05.39 |
tofu |
there's
nothing inherint to the system that encourages larger commits other
than really bad practice |
| 22:05.41 |
Ralith |
tofu: I'm not
sure that's always feasible. |
| 22:05.55 |
Ralith |
though I
guess I really lack the experience to argue this very
effectively |
| 22:06.05 |
``Erik |
distributed
VCS allows people to go hide in a corner and pretend they're good
citizens |
| 22:06.22 |
tofu |
Ralith: i've
heard that claim many a time over, but not once has it actually
been shown to be true -- it's folks not wanting to change their
work breakdown |
| 22:06.39 |
Ralith |
fine,
fine |
| 22:07.13 |
FAMULUS |
``Erik: I
would argue that git/github lowers the barrier to entry for
contribution |
| 22:07.56 |
FAMULUS |
``Erik: just
fork the repo and off you go |
| 22:08.06 |
``Erik |
I'd argue
that dvcs tends to contribute to bad behavior wrt FOSS
citizenship |
| 22:08.09 |
tofu |
Ralith: and
bot_dump isn't fast/slow -- it just dumps the data for a triangle
mesh to the prescribed format |
| 22:08.12 |
``Erik |
exactly!
"fork the repo" is bad |
| 22:08.29 |
FAMULUS |
``Erik: I say
it's good! |
| 22:08.35 |
tofu |
it doesn't
actually tessellation, you need a BoT to start with |
| 22:08.40 |
Ralith |
tofu: yeah, I
misunderstood; thought you were proposing it as an unchecked
equivalent to g-stl |
| 22:08.41 |
``Erik |
you
disassociate from the community when you do that |
| 22:08.57 |
``Erik |
and that's
the single thing that makes foss awesome, the community... you're
throwing away the #1 advantage |
| 22:09.22 |
FAMULUS |
``Erik: I
completely disagree. If someone does some hotness it wll get
merged |
| 22:09.48 |
FAMULUS |
``Erik: and
even before that, you can see someone is ahead of the main repo
(via the graph) |
| 22:10.00 |
FAMULUS |
``Erik: and
sometimes it's the probem you had |
| 22:10.08 |
``Erik |
I'm learning
a new framework in a new language with a new editor and
everything... I ask really stupid questions, frequently. I share
what I'm doing often. The framework authors and gurus are updating
the framework frequently, and their documentation... because of my
stupidness :) it's good! |
| 22:11.00 |
``Erik |
the gurus
doing hotness will know how to behave with svn, the 'average' new
contributor will greatly benefit and will benefit the community by
making their education public |
| 22:11.01 |
``Erik |
:) |
| 22:12.46 |
tofu |
FAMULUS: this
argument of centralized over distributed is a very old and tired
debate, frankly -- and not one that hasn't been considered and
discussed many times over |
| 22:13.02 |
FAMULUS |
tofu: agreed.
I don't really care |
| 22:13.03 |
tofu |
there are
counter arguments and downsides to distributed |
| 22:13.16 |
tofu |
just as there
are for centralized |
| 22:14.24 |
tofu |
code dumps
are generally very unhealthy for a codebase, no matter how
'hotness' a feature is |
| 22:15.02 |
tofu |
especially if
it's development hasn't been communicated throughout development,
it is very often a foreign mismatched codebase with a near 1 bus
factor |
| 22:16.01 |
tofu |
communication
is key, and you can have healthy/unhealthy communication regardless
of being distributed or centralized, with the only difference being
that distributed doesn't require it and centralized exposes
earlier |
| 22:16.47 |
FAMULUS |
tofu: how do
I invoke dot_dump? |
| 22:16.52 |
FAMULUS |
bot_dump |
| 22:16.54 |
tofu |
when the dev
team is small, i.e. less than 50 or so active committers, the
hierarchical approach that distributed allows isn't really
gained |
| 22:17.28 |
tofu |
are you
asking and answering your own question? |
| 22:17.34 |
tofu |
ah,
dot |
| 22:17.42 |
tofu |
that's the
answer, bot_dump |
| 22:18.00 |
FAMULUS |
ok |
| 22:18.00 |
tofu |
added in
7.14.2 |
| 22:18.03 |
FAMULUS |
ah
ok |
| 22:18.15 |
tofu |
tell me you
at least tried before asking how you run "bot_dump" :) |
| 22:18.17 |
FAMULUS |
so for os x,
I'll have to compile to get that version? |
| 22:18.50 |
tofu |
yes, there
hasn't been a binary os x release in a while |
| 22:19.02 |
FAMULUS |
tofu: ok, so
thats my next move |
| 22:24.11 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 22:27.11 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 22:30.41 |
``Erik |
doh, hah,
karel keeps using _sushi_, for some reason, I got a mental
crosswire on handle vs person |
| 23:07.51 |
Ralith |
mm,
sushi |
| 23:23.29 |
*** join/#brlcad FAMULUS
(n=mark@ool-ad028f27.dyn.optonline.net) |
| 23:25.30 |
yukonbob |
reads scrollback |
| 23:26.09 |
madant |
is a strict non-fish-arian |
| 23:29.04 |
Ralith |
enjoys some easter chocolate as he works on his
timeline |
| 23:29.35 |
``Erik |
drinks some sunday vodka and watches tv |
| 23:36.42 |
madant |
just had some water :| , breakfast in 2.5
hours |
| 23:50.44 |
CIA-28 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1383 10/wiki/User:Ralith: Added first draft of timeline for OpenGL
GUI SoC proposal |
| 23:51.11 |
Ralith |
heh, CIA
dropped the notification before I managed to load the
page. |
| 23:55.17 |
brlcad |
:) |
| 23:59.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 00:09.58 |
FAMULUS |
so i seemed
like I sucessfully compiled truck for OS X, but when I run mged I
get Bus error |
| 00:10.05 |
FAMULUS |
trunk^ |
| 00:10.47 |
brlcad |
FAMULUS: off
of an svn checkout? |
| 00:10.52 |
FAMULUS |
yes |
| 00:10.55 |
``Erik |
bus error is
insanely bad, worse than a segfault, can you provide
backtrace? |
| 00:10.56 |
starseeker |
dreeves:
sorry, off to Easter stuff |
| 00:10.57 |
brlcad |
what was your
configure summary? |
| 00:11.01 |
FAMULUS |
svn checkout
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 00:11.17 |
brlcad |
specifically,
is ogl enabled or disabled? |
| 00:11.22 |
brlcad |
what was your
configure line? |
| 00:11.44 |
FAMULUS |
... |
| 00:11.56 |
FAMULUS |
./configure |
| 00:11.59 |
starseeker |
dreeves:
Mostly curious about status - I had pulled some of the code with
the intent to start looking at it, but if you're ahead of me (and
it sounds like you are if you're identifying differences in
opennurbs vs. utah trimming) I was going to ask if there was
anything I can do to help |
| 00:12.04 |
brlcad |
ok |
| 00:12.08 |
``Erik |
heh, wow, say
"bus fault" and everyone comes to life :D |
| 00:12.41 |
brlcad |
FAMULUS: grep
"OpenGL support" config.log |
| 00:12.46 |
FAMULUS |
k |
| 00:13.00 |
FAMULUS |
configure:47790: result: OpenGL support
(optional).............: no |
| 00:13.10 |
brlcad |
starseeker:
that's the point of frequent commits -- go for it ;) |
| 00:13.20 |
brlcad |
it doesn't
exist if it's not committed |
| 00:13.36 |
brlcad |
slow
committers get to deal with the conflicts/mergine woes
;) |
| 00:13.42 |
brlcad |
FAMULUS:
hrmph |
| 00:14.05 |
starseeker |
brlcad: no,
I mean I was going to see if there was a specific conceptual
question I can look into - I don't have any new code myself
(yet) |
| 00:14.08 |
brlcad |
FAMULUS: you
did an install? |
| 00:14.37 |
FAMULUS |
yes |
| 00:14.57 |
FAMULUS |
sudo make
install |
| 00:15.04 |
FAMULUS |
mged command
responds |
| 00:15.09 |
starseeker |
wants to do whatever he can to keep the nurbs progress going,
without duplicating work if possible :-) |
| 00:15.13 |
FAMULUS |
but then Bus
Error |
| 00:15.34 |
FAMULUS |
Should I svn
from a tag, as opposed to trunk? |
| 00:15.43 |
``Erik |
you should be
on trunk |
| 00:16.03 |
brlcad |
FAMULUS: what
about "mged -c" does that segfault too? |
| 00:17.00 |
FAMULUS |
lets
see |
| 00:18.09 |
FAMULUS |
brlcad: that
seems to work acctually |
| 00:18.18 |
FAMULUS |
Creating
region id=1000, air=0, GIFTmaterial=1, los=100 |
| 00:18.46 |
brlcad |
oh,
interesting -- you'd scripted without -c ? |
| 00:19.28 |
FAMULUS |
my ruby
scripts use -c |
| 00:19.37 |
FAMULUS |
that's what
I'm running now |
| 00:19.44 |
brlcad |
okay |
| 00:19.55 |
FAMULUS |
but just
launching mged my_db.g |
| 00:19.56 |
FAMULUS |
fails |
| 00:20.21 |
brlcad |
so try
running mged -c, attach "nu" default, then run "gui" |
| 00:20.58 |
FAMULUS |
are the
commas line seperators? |
| 00:21.08 |
FAMULUS |
mged
-c |
| 00:21.12 |
FAMULUS |
attach "nu"
default |
| 00:21.23 |
brlcad |
when you run
mged -c, it asks you |
| 00:21.27 |
FAMULUS |
ok |
| 00:21.29 |
FAMULUS |
coming
up |
| 00:22.02 |
FAMULUS |
ok |
| 00:22.05 |
FAMULUS |
when I run
gui |
| 00:22.07 |
FAMULUS |
Bus
Error |
| 00:22.40 |
brlcad |
try again but
instead with "gdb --args mged -c" |
| 00:22.50 |
brlcad |
"run" to
start it off |
| 00:23.24 |
FAMULUS |
Program
received signal EXC_BAD_ACCESS, Could not access
memory. |
| 00:23.25 |
FAMULUS |
Reason:
KERN_PROTECTION_FAILURE at address: 0x0000005c |
| 00:23.25 |
FAMULUS |
0x0012fa51 in
X_open_dm (interp=0x1808c08, argc=6, argv=0xbfffb4a4) at
dm-X.c:343 |
| 00:23.26 |
FAMULUS |
343dmp->dm_width = |
| 00:25.22 |
``Erik |
now that's
interesting |
| 00:25.32 |
``Erik |
but "print
dmp" is ok? |
| 00:25.50 |
``Erik |
does it fill
dm_width ok? |
| 00:25.57 |
FAMULUS |
``Erik: don't
know about print dmp |
| 00:26.54 |
brlcad |
FAMULUS: 10.5
? |
| 00:26.59 |
``Erik |
"print" is a
gdb command |
| 00:27.03 |
FAMULUS |
latest and
greatest |
| 00:27.06 |
brlcad |
are you
up-to-date? |
| 00:27.29 |
FAMULUS |
(gdb) print
dmp |
| 00:27.29 |
FAMULUS |
$1 = (struct
dm *) 0xf19960 |
| 00:28.03 |
``Erik |
print *dmp
? |
| 00:28.14 |
dreeves |
starseeker I
will status you when I get done today |
| 00:28.31 |
``Erik |
you can
explore quite a bit with gdb, if it notes the struct then you have
a good debuggable binary |
| 00:28.58 |
FAMULUS |
http://pastie.org/444641 |
| 00:29.38 |
FAMULUS |
I'm
doublechecking updates, my os is current, but I just installed dev
tools, may be an update for that |
| 00:30.22 |
FAMULUS |
software
update says I'm current |
| 00:30.35 |
``Erik |
dm_width
seems to be set to 0, whcih is wrong, but I don't undersatnd why
you'd get a fault on it |
| 00:31.10 |
``Erik |
try, uh,
-F/dev/X |
| 00:31.13 |
``Erik |
? |
| 00:32.16 |
FAMULUS |
Undefined
command: "-F". Try "help". |
| 00:32.25 |
FAMULUS |
where? |
| 00:33.27 |
*** join/#brlcad madant
(n=d@117.196.142.36) |
| 00:36.21 |
``Erik |
rt -F/dev/Xl
soemfile.g toplevel |
| 00:40.14 |
FAMULUS |
http://pastie.org/444651 |
| 00:43.55 |
``Erik |
looks like ya
didn't give a valid toplvevel solid |
| 00:44.40 |
FAMULUS |
one
sec |
| 00:44.59 |
FAMULUS |
ok |
| 00:45.05 |
FAMULUS |
got
it |
| 00:45.14 |
FAMULUS |
toplevel is a
variable |
| 00:45.21 |
FAMULUS |
that produces
a picture |
| 00:47.09 |
brlcad |
"mged -c
file.g tops" will list your top level objects |
| 00:49.07 |
FAMULUS |
yup |
| 00:49.11 |
FAMULUS |
I got a
render |
| 00:49.51 |
brlcad |
so it's not
the X11 framebuffer, something specific to X11 display
managers |
| 00:50.38 |
Ralith |
hmm. |
| 00:50.53 |
Ralith |
brlcad: it's
trivial to determine whether a given point is inside or outside a
given region, right? |
| 00:51.38 |
brlcad |
Ralith: sure,
shoot a ray, look at that point |
| 00:52.14 |
Ralith |
so it'd be
pretty easy to generate a voxel representation of a given
volume? |
| 00:52.32 |
brlcad |
oh
sure |
| 00:52.58 |
brlcad |
the g_qa code
already does this effectively as to several of the 'rt*'
tools |
| 00:53.04 |
brlcad |
just not in a
clean/simple library form |
| 00:53.13 |
Ralith |
and then you
could tesselate that for an approximate solid mesh. |
| 00:53.26 |
brlcad |
one of the
refactoring todos is to turn gqa's code into a sampling
routine |
| 00:53.36 |
Ralith |
you'd lose
detail on hard edges, but it'd work. |
| 00:53.44 |
brlcad |
yep, do some
dulaney triangulation, whatever |
| 00:54.15 |
Ralith |
and I suspect
high resolutions might actually not be all that
expensive |
| 00:54.35 |
brlcad |
that's some
basic csg-to-brep approaches worked out in the 80's that do exactly
that, and are even mildly interesting iff you do adaptive
sampling |
| 00:54.48 |
Ralith |
neat! |
| 00:55.11 |
brlcad |
without
adaptive sampling, it generates horrible tessellations or massively
refined meshes |
| 00:58.20 |
brlcad |
Ralith: if
you're really interested in that -- there's a really good paper
from UNC recently ala 2007/2008 that is a big
improvement |
| 00:59.30 |
Ralith |
I've got more
immediate concerns, and I get the impression the brep stuff will be
providing nice tesselation soon enough anyway; was just
curious |
| 01:00.45 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 01:02.20 |
brlcad |
yeah, the
brep work is a non-approximation approach |
| 01:02.31 |
brlcad |
should be
faithful |
| 01:03.08 |
Ralith |
shame it's
not ready yet |
| 01:03.16 |
Ralith |
would have loved to put "Shaded rendering of geometry" on his
milestones. |
| 01:13.06 |
*** join/#brlcad madant
(n=d@117.196.135.181) |
| 01:31.06 |
starseeker |
dreeves:
cool, thanks! :-) |
| 01:51.57 |
hippieindamakin8 |
Ralith, i put
in a proposal for that |
| 01:52.08 |
Ralith |
for
what? |
| 01:52.22 |
hippieindamakin8 |
brep
evaluation |
| 01:52.32 |
Ralith |
ah. |
| 01:52.36 |
Ralith |
cool |
| 01:52.51 |
Ralith |
here's to
hoping it happens |
| 01:54.10 |
hippieindamakin8 |
Ralith,
:) |
| 01:54.33 |
Ralith |
that's one of
the major barriers to a truly contemporary modeler imo |
| 02:10.39 |
Ralith |
brlcad: let
me know if you have any thoughts on my
milestones/timeline |
| 04:02.33 |
*** join/#brlcad deeeffache
(n=deeeffac@adsl-99-141-217-153.dsl.emhril.sbcglobal.net) |
| 04:16.06 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 04:29.18 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-152-1.3g.claro.net.br) |
| 04:53.37 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-134-156.3g.claro.net.br) |
| 05:48.57 |
dreeves |
starseeker so
here is the deal there is no similarities between really between
how the utah code represents trims and opennurbs represents.
Utah's code is very basic it just basically stores a polyline that
represents the trim whereas opennurbs can be several shapes but
that isn't really the part I'm struggling with. The documentation
on opennurbs is limited i.e. how does the type seam vs mated vs
etc.. affect the seam and the iso setting affect it. I |
| 05:48.57 |
dreeves |
f you can
figure that out. So pretty much I think the utah will be fairly
useless because they aren't close. |
| 05:51.59 |
dreeves |
Just to get
you going if you want to work on it. you may already know this but
the 2d curves are in parameter space so the idea would be to trim
in parameter space much simpler problem |
| 05:52.46 |
dreeves |
So I'm still
working on it but if you find anything out let me know. Right now
I am just approximating the trim curve with a polyline for the time
being |
| 07:20.55 |
dreeves |
starseeker ok
looks like I'm having some success here |
| 07:21.03 |
dreeves |
yahoo |
| 07:21.11 |
dreeves |
still some
issues here |
| 07:42.53 |
*** join/#brlcad madant
(n=madant@117.196.139.248) |
| 07:58.35 |
*** join/#brlcad madant
(n=madant@117.196.139.248) |
| 08:28.37 |
CIA-28 |
BRL-CAD:
03ddreeves70 * r34197
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: This is code
that implements a crude form of the triming it causing some
problems but I just want to update everyone where I'm at on
trimming |
| 08:30.56 |
dreeves |
starseeker
you can also focus on the line nurbs curve intersection code. The
numintersections function in ON_nurbscurve isn't
working |
| 08:55.35 |
madant |
hmmmm,
make[2]: Entering directory `/home/d/wrk/brlcad/src/shapes'
make[2]: *** No rule to make target `wire.1', needed by `all-am'.
Stop. |
| 09:47.33 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 10:55.25 |
*** join/#brlcad madant
(n=madant@117.196.138.114) |
| 11:14.25 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:40.14 |
madant |
mafm, is the
build ok ? |
| 11:40.48 |
mafm |
hi |
| 11:40.55 |
mafm |
madant: the
build? |
| 11:45.22 |
starseeker |
dreeves:
excellent, thank you :-) |
| 11:49.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 11:52.50 |
madant |
i am getting
build error in src/shapes.. |
| 12:01.15 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 12:10.09 |
starseeker |
madant: what
error? |
| 12:10.40 |
madant |
<PROTECTED> |
| 12:11.07 |
starseeker |
you've got an
old makefile |
| 12:11.59 |
madant |
yeah thought
so.. cleaning up now :) |
| 12:19.15 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 12:23.02 |
``Erik |
http://langpop.com/ |
| 12:31.25 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 12:41.44 |
brlcad |
interesting
article at the top of that page |
| 12:46.36 |
``Erik |
the approach
and notion seemed interesting, the results *shrug* meh. Was kinda
surprised that java and c++ were behind C, and how low c++ sat, but
*shrug* meh :) |
| 12:48.16 |
``Erik |
is rdo, gonna go across the street and check up on his car
today :/ |
| 12:48.31 |
``Erik |
ya wiring up
the suns today? |
| 12:49.40 |
``Erik |
think your
ircop friend would be willing to split her logs up daily so'z we
aren't moving 11 gigs of log for the great '09 bz
migration? |
| 12:50.19 |
``Erik |
(would
probably help your home dumps, too) |
| 12:51.33 |
``Erik |
tries not to notice, but big things tend to jump to fg
:( |
| 12:54.51 |
brlcad |
yeah |
| 12:55.27 |
brlcad |
I rotated
some of them on saturday, still need to hit up the big one
though |
| 12:55.33 |
brlcad |
big
ones |
| 12:59.09 |
``Erik |
<--
unwilling to muck with those, wouldn't feel right doing anything
more than saying "hey, uh, can't help but notice, you're causing
some issues in this operation, can you help us?" |
| 12:59.19 |
``Erik |
damn my
ethics |
| 13:00.55 |
``Erik |
I'm keeping
the new machine up to date system wise, and doing the occasional
rsync... itching to see the migration happen so I can try to get
the apache stuff sorted out for my new use. let me know what more I
can do to help *shrug* |
| 13:02.08 |
``Erik |
like the
cylons, I have a plan. And the low hanging fruit is all depending
on the migration happening :D |
| 13:03.01 |
``Erik |
(if irssi
lacks the ability to do time sensitive log file selection, I will
fucking add it) |
| 13:12.22 |
CIA-28 |
BRL-CAD:
03brlcad * r34198 10/brlcad/trunk/src/libged/mirror.c: remove dead
code, clean up indentation |
| 13:15.19 |
CIA-28 |
BRL-CAD:
03brlcad * r34199 10/brlcad/trunk/src/librt/mirror.c:
ws |
| 13:17.05 |
``Erik |
wonders how much of that dead code was his |
| 13:27.19 |
*** join/#brlcad madant
(n=madant@117.196.131.135) |
| 13:38.10 |
brlcad |
pnone |
| 13:38.36 |
``Erik |
heh |
| 14:00.16 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 14:35.20 |
dreeves |
startseeker
have you had a chance to look at it? |
| 14:37.32 |
dreeves |
starseeker in
the nurbs_test.g the nurbs_cyl.r is a good test case of the
trimming trimming appears to be working somewhat but I'm getting
surface acne |
| 14:40.13 |
starseeker |
dreeves: just
getting at it now |
| 14:40.39 |
starseeker |
dreeves:
IIRC, the opennurbs library deliberately doesn't provide the
intersection code for a line + nurbs |
| 14:42.23 |
starseeker |
yeah, I ran
the tests with your update |
| 14:42.38 |
starseeker |
getting
severe acne on all of them |
| 14:43.05 |
dreeves |
That is the
trimming if you turn off the trimming the acne will go
away |
| 14:43.37 |
dreeves |
I'm not 100%
sure right now what is causing that... |
| 14:44.07 |
dreeves |
especially on
the end cap |
| 15:04.29 |
dreeves |
btw yeah they
don't provide one and the one we have added isn't working
numintersections method is failing I believe when it is breaking
down into bezier curves Although I'm not convinced that is the
problem |
| 15:05.45 |
dreeves |
well anyways
I'm headed out for awhile |
| 15:07.54 |
CIA-28 |
BRL-CAD:
03brlcad * r34200 10/brlcad/trunk/src/librt/mirror.c: remove stray
1 |
| 15:10.20 |
mafm_ |
madant:
sorry, had to run outside. I haven't build the project for a while,
so can't help :) |
| 15:11.40 |
typ0 |
what is the
best documentation resource to learn about IGES converter status
? |
| 15:11.50 |
typ0 |
commit logs
? |
| 15:11.56 |
typ0 |
i already
checked the bug-tracker |
| 15:13.52 |
CIA-28 |
BRL-CAD:
03brlcad * r34201 10/brlcad/trunk/src/librt/ (Makefile.am
primitives/table.c table.c): move table.c into the primitives
directory as first step towards refactoring the API in order to
hide the table itself. let primitives contain logic that is
solid-specific |
| 15:15.33 |
CIA-28 |
BRL-CAD:
03brlcad * r34202 10/brlcad/trunk/src/librt/ (Makefile.am mirror.c
primitives/mirror.c): move rt_mirror() up into primitives as well
since it's one of the first table calls |
| 15:16.34 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 15:16.35 |
brlcad |
typ0:
probably reading the source code and/or asking here -- there's not
a lot of documentation |
| 15:17.07 |
brlcad |
commit logs
might be helpful, but seeing as that's an older converter from
pre-open-source days, it may be somewhat thin on
details |
| 15:17.21 |
brlcad |
should read
the two manual pages for it |
| 15:20.41 |
CIA-28 |
BRL-CAD:
03bob1961 * r34203 10/brlcad/trunk/src/archer/plugins/Wizards/
(tankwizard/TankWizard.tcl tirewizard/TireWizard.tcl): Minor mod
related to ripping out BLT. |
| 15:28.56 |
madant |
mafm, no
problem, just needed a bit of cleaning of my files |
| 15:34.09 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 15:36.21 |
brlcad |
hi
Elena |
| 15:39.59 |
madant |
brlcad, do we
(mafm, pacman87, me etc. ) who have commit access need to submit a
patch ? |
| 15:40.20 |
madant |
and seems
like Elena doesn't like you :D |
| 15:43.12 |
typ0 |
cool
thanks |
| 15:45.29 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 15:47.20 |
CIA-28 |
BRL-CAD:
03brlcad * r34204 10/brlcad/trunk/ (include/sysv.h
src/libsysv/bcmp.c): adjust bcmp signature to match posix using
void pointers and size_t |
| 15:50.10 |
CIA-28 |
BRL-CAD:
03brlcad * r34205 10/brlcad/trunk/ (include/sysv.h
src/libsysv/memset.c): do the same to memset, use void and size_t
to match standard |
| 15:51.49 |
brlcad |
madant: the
purpose of the patch is primarily to make sure students are working
with the code, on their way towards being integrated with the
community, and working towards commit access |
| 15:52.45 |
brlcad |
so if you're
doing and have all three of those already, then you probably have
your answer |
| 15:52.46 |
madant |
k, so if i
continue the work with MathGrammar and foundations of libged
integration that works too ? |
| 15:53.09 |
madant |
oh and
brlcad, i had a crappy knee a couple of days ago |
| 15:53.26 |
brlcad |
crappy
knee? |
| 15:53.43 |
madant |
yeah knee
pain after running around 9 kms.. :) |
| 15:53.46 |
brlcad |
and yes,
working with mathgrammar and libged would be perfect |
| 15:53.59 |
madant |
reminded me
of your knee comment regarding reaching college level
speeds |
| 15:54.04 |
brlcad |
I get crappy
knee after much less than 9kms these days :) |
| 15:54.27 |
Elena |
hello |
| 15:54.40 |
brlcad |
howdy
Elena |
| 15:54.47 |
madant |
anyways it
disappeared in a couple of days.. i have never really understood
how the knee gets "hurt" and gets back on track. |
| 15:55.45 |
brlcad |
madant: torn
ligaments that heal |
| 15:55.45 |
Elena |
how are
you? |
| 15:55.45 |
brlcad |
peachy,
you? |
| 15:55.45 |
Elena |
fine |
| 15:56.33 |
brlcad |
nice to see
that you made it onto irc finally :) |
| 15:56.45 |
Elena |
:) |
| 15:57.38 |
dreeves |
starseeker
fyi just for kicks and grins I only looked at the endcaps for the
cylinder and I just special case treated the trims like circles it
worked perfectly that is just a simple distance check (I just
happen to know those trims are circles) so maybe my approx. is
causing more problems than I realized |
| 16:03.19 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Cyl special
trim.png]]": Don't get excited this is very special case
trimming. |
| 16:04.38 |
CIA-28 |
BRL-CAD:
03brlcad * r34206 10/brlcad/trunk/ (5 files in 4 dirs): remove
bcmp() from libsysv (which was added for windows compatibility) as
there is a c89 equivalent (that should be available on windows).
just use memcmp() instead. |
| 16:04.40 |
brlcad |
gets excited |
| 16:05.12 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1385 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 16:05.22 |
brlcad |
purdy |
| 16:06.54 |
dreeves |
yeah don't
get excited that is a very special case trim |
| 16:07.22 |
dreeves |
I just wanted
to prove to myself it wasn't something else goofy going it
wasn't |
| 16:07.52 |
dreeves |
it is my line
nurbs curve intersection isn't working very well |
| 16:09.21 |
CIA-28 |
BRL-CAD:
03brlcad * r34207 10/brlcad/trunk/misc/ (2 files in 2 dirs): remove
bcmp.c from windows build files |
| 16:09.44 |
CIA-28 |
BRL-CAD:
03brlcad * r34208 10/brlcad/trunk/src/libsysv/CMakeLists.txt:
remove bcmp.c, no longer needed/included |
| 16:10.12 |
CIA-28 |
BRL-CAD:
03brlcad * r34209 10/brlcad/trunk/src/gtools/g_diff.c: no longer
need sysv.h |
| 16:10.47 |
CIA-28 |
BRL-CAD:
03brlcad * r34210 10/brlcad/trunk/src/canon/canonlib.c: last usage
of bcmp(), converted to memcmp(). |
| 16:13.53 |
CIA-28 |
BRL-CAD:
03brlcad * r34211 10/brlcad/trunk/BUGS: update rtwizard bug items
(now works with perspective, doesn't seem to hang with latest, and
confirmed line overlay problem) |
| 16:18.02 |
CIA-28 |
BRL-CAD:
03brlcad * r34212 10/brlcad/trunk/src/other/step/ (. include/
misc/): ignore configure-generated files |
| 16:20.18 |
CIA-28 |
BRL-CAD:
03brlcad * r34213 10/brlcad/trunk/src/shapes/: ignore coil
binary |
| 16:24.34 |
brlcad |
typ0:
http://brlcad.org/OLD/reports/arl-tr-315/index.html |
| 16:24.40 |
brlcad |
almost forgot
about that report |
| 16:24.53 |
brlcad |
notes the strong need for more organized docs on the
website |
| 16:46.39 |
typ0 |
sweet |
| 16:46.42 |
typ0 |
cheers |
| 17:19.33 |
brlcad |
hmm |
| 17:19.52 |
brlcad |
hmm2 |
| 17:34.11 |
brlcad |
begins a rotatable logfile configuration for
sportchick |
| 17:39.07 |
CIA-28 |
BRL-CAD:
03bob1961 * r34214 10/brlcad/trunk/src/tclscripts/archer/ (32 files
in 4 dirs): |
| 17:39.08 |
CIA-28 |
BRL-CAD:
Removed the basic, intermediate and advanced modes. Removed the
canvas menus, |
| 17:39.08 |
CIA-28 |
BRL-CAD:
hierarchy label, attributes label and the collapse/expand buttons.
Moved the |
| 17:39.08 |
CIA-28 |
BRL-CAD:
view/edit toolbar items to the primary toolbar. Turned off tearoff
menus. |
| 17:50.04 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 17:50.46 |
dreeves2 |
starseeker I
am not at my computer that I'm connected to irc on so if you have
written anything I can't see it |
| 17:51.32 |
dreeves2 |
but anyway I
have thought of a much better way to evaulate the point in the
curve that won't require us to modify opennurbs I'm going to work
on that when I get a chance later today |
| 17:53.36 |
CIA-28 |
BRL-CAD:
03brlcad * r34215 10/brlcad/trunk/NEWS: bob made a slew of major
gui changes to archer including the removal of the distinct
experience levels. |
| 18:08.02 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 18:17.14 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187.24.16.0) |
| 18:17.29 |
brlcad |
thinks fbsd is fs-confused |
| 18:17.41 |
``Erik |
? |
| 18:17.57 |
brlcad |
it is spewing
filesystem full messages |
| 18:17.59 |
``Erik |
old old OLD
ufs is very slow about updating free lists |
| 18:18.08 |
brlcad |
various
loggers |
| 18:18.18 |
brlcad |
httpd, irssi,
user logging |
| 18:18.21 |
``Erik |
but youd'
have to be fucktarded enough to run an ancient version to see that,
like 5 series |
| 18:18.22 |
``Erik |
:D |
| 18:25.16 |
brlcad |
still, pretty
severe bug |
| 18:25.20 |
brlcad |
probably
needs an fsck |
| 18:25.30 |
brlcad |
can that be
run safely while live? |
| 18:25.49 |
``Erik |
uhmmmmm, I
don't recall if the snapfs was there on 5.2.1 :( |
| 18:26.25 |
brlcad |
something is
seriously hosed with 1.5GB free and it vomiting filesystem full
messages |
| 18:26.53 |
``Erik |
usually it
just took a few minutes to put everything into the free
list |
| 18:27.08 |
``Erik |
yeah, you
have the snapfs man pages |
| 18:27.14 |
brlcad |
there's been
1.5GB free for days |
| 18:27.35 |
``Erik |
df is reading
free mem |
| 18:27.43 |
``Erik |
smoething
must be borked up |
| 18:29.55 |
brlcad |
basically
running bzip2 on all her old log files one at a time -- each new
file seems to generate a dozen or more full messages |
| 18:30.05 |
brlcad |
yet bzip2
completes successfully |
| 18:30.17 |
brlcad |
and even as
more space is freed up, still spews |
| 18:30.45 |
brlcad |
well, I'll
let this run spewing for a few hours |
| 18:31.00 |
AlexandreGuedes |
brlcad: I
answered your comments at Student Proposal |
| 18:31.02 |
brlcad |
should free
up about 4GB |
| 18:31.04 |
``Erik |
yeah, ya got
free space, shouldn't be throwing those alerts |
| 18:31.20 |
brlcad |
and make
syncing better down the road |
| 18:31.25 |
brlcad |
(more
importantly) |
| 18:31.32 |
brlcad |
for post
migration woes |
| 18:32.07 |
``Erik |
heh, pine
just bitched at me on that machine |
| 18:34.18 |
``Erik |
I d'no, it
shouldn't be bitching about that. mebbe it was a bug in that
version, 5.2.1 was a quick 'fix some other bugs' release, the ONLY
release I've ever seen wih the third number |
| 18:34.38 |
``Erik |
is mostly using 7.2 |
| 18:35.01 |
brlcad |
I can't find
hint of it on-line yet though |
| 18:35.15 |
brlcad |
would have
thought plenty of others would have filled up a disk if it was a
simple bug |
| 18:37.13 |
``Erik |
<--
doesn't know, it may require an fsck to regenerate the free block
list :( |
| 18:37.49 |
brlcad |
heh, up to
1.7 free and still bitching :) |
| 18:38.10 |
brlcad |
seems to be
slightly less though |
| 18:38.46 |
starseeker |
dreeves2:
cool! |
| 18:44.46 |
``Erik |
argues for rapid migration instead of fixing the old stuff
O.o |
| 19:01.29 |
dreeves2 |
starseeker
did you see the image of the cylinder I uploaded. Basically
Ignored all trims except for the end cap trims and then I used a
circle to represent the trims that obviously worked great but I
think this idea I have should work |
| 19:01.44 |
starseeker |
yes |
| 19:01.55 |
starseeker |
how do you
plan to make it general? |
| 19:27.33 |
dreeves2 |
look at
closest point to the intersection point then calculate a direction
vector from that point to the intersection point then compare the
normal at that point and the direction vector if they are pointing
the same direction then the point is outside the curve this makes a
couple of assumptions but conceptally that is how it would
work |
| 19:31.31 |
dreeves2 |
Does that
make since? |
| 19:31.55 |
starseeker |
you mean the
closest point on the trimming loop? |
| 19:32.00 |
dreeves2 |
yes |
| 19:32.30 |
dreeves2 |
This is a
methon on ON_Curve that will give you that |
| 19:33.16 |
starseeker |
hmm.
|
| 19:33.54 |
starseeker |
would need to ask Ed about that one |
| 19:33.58 |
dreeves2 |
obviously we
will have to deal some special cases and check
orientation |
| 19:34.09 |
dreeves2 |
of the
loop |
| 19:34.11 |
starseeker |
nods |
| 19:35.41 |
dreeves2 |
Yeah I tried
to give Ed a call to see what he thought but I couldn't get him on
the phone and I have meetings I had to join. If you get his
feedback I would like to hear what he had to say |
| 19:35.59 |
``Erik |
eh? |
| 19:36.41 |
starseeker |
if you like I
can ask him when a good time to call would be - I don't want to
garble it in translation and he will have questions |
| 19:37.15 |
``Erik |
ed is effin'
brilliant, we kinda try to protect him... how the fuck do you think
you have a direct line to him? |
| 19:38.16 |
dreeves2 |
what? |
| 19:38.27 |
starseeker |
``Erik: he's
talked to Ed before |
| 19:39.04 |
``Erik |
aight *shrug*
ed is a valuable resource, not one to be squandered |
| 19:41.01 |
``Erik |
<-- a
little protective :) |
| 19:41.30 |
dreeves2 |
I thought
brep was #1 priority how is asking him a question about it
squandering him? |
| 19:41.36 |
starseeker |
it
isn't |
| 19:42.06 |
``Erik |
I'm being
reactionary... if it's a good brep question, then it's all
good |
| 19:42.27 |
starseeker |
dreeves2: if
I understand correctly, you're proposing to use the normal ON the
trimming curve? |
| 19:43.19 |
starseeker |
isn't quite seeing it... |
| 19:43.22 |
dreeves2 |
yes |
| 19:43.25 |
``Erik |
I kinda
joined in half through a discussion, saw a request for a limited
resource, so'z I threw the 'zomfg wtff' card down, I apologize
:) |
| 19:44.42 |
starseeker |
dreeves2:
taking a flat plane as an example, how would the normal on the
trimming curve be any different from the normal at any possible
intersection point (in or out of the trimming curve?) |
| 19:45.10 |
dreeves2 |
hang on
having to think about something here |
| 19:55.02 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 19:56.00 |
dreeves2 |
ok at any
point on the curve we should be able to calculate a normal it will
be in the plane of the curve. |
| 19:58.54 |
*** join/#brlcad andax
(n=andax__@d213-102-40-157.cust.tele2.ch) |
| 20:22.26 |
dreeves2 |
It would be
the normal at the point returned from the closest point |
| 20:22.48 |
dreeves2 |
Are you
following now? |
| 20:42.17 |
dreeves2 |
``Erik just
for my clarification who is the "we" you were referring to in the
statement "we kinda try to protect him"? |
| 20:43.18 |
``Erik |
core dev
team, brlcad and ed are valuable resource, I try to defend
them |
| 20:45.48 |
louipc |
``Erik: are
you squanderable? :P |
| 20:46.02 |
``Erik |
sure |
| 20:46.11 |
louipc |
haha
kidding |
| 20:46.38 |
dreeves2 |
How did that
become your responsiblity? :) |
| 20:46.53 |
``Erik |
as far as
brlcad development goes, I'll throw my arse under the
bus |
| 20:47.01 |
louipc |
he's the
front-line |
| 20:48.32 |
``Erik |
I have 99% of
the answers, I think the folk who have the other 1%... their time
is more valuabe than mine, so I'll step up |
| 21:04.12 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 21:04.51 |
dreeves2 |
the cgi:irc
stuff sucks but I have to deal with here because of the firewall
stuff here |
| 21:06.39 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-165-159.3g.claro.net.br) |
| 21:30.50 |
brlcad |
looks like
there are a variety of fs errors |
| 21:30.52 |
brlcad |
http://paste.bzflag.bz/m5bb418a3 |
| 21:41.26 |
brlcad |
wow, and it
gets a lot worse |
| 21:43.38 |
brlcad |
too much to
even copy paste.. looks like thousands of issues |
| 21:44.07 |
brlcad |
that
certainly bumps up the migration priority even more |
| 21:44.23 |
brlcad |
this isn't
fixable without a shutdown |
| 21:47.20 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 21:51.25 |
starseeker |
hope I didn't
cause any trouble - had to do a quick svn checkout in
tmp |
| 21:51.33 |
starseeker |
I erased it
pronto |
| 21:55.17 |
brlcad |
different
filesystem |
| 21:55.45 |
brlcad |
the /usr
partition is the one with problems |
| 21:55.49 |
starseeker |
the
wildcat-cad svn checkout started working, wanted to make sure to
grab a copy |
| 21:55.50 |
starseeker |
ah |
| 21:56.16 |
louipc |
ouch |
| 22:06.22 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 22:07.06 |
Ralith |
wow, that
openbook screenshot looks nice! |
| 22:09.22 |
Ralith |
what allows
the edges to be drawn so selectively? |
| 22:09.45 |
starseeker |
to be honest,
I'm surprised it worked that well |
| 22:10.08 |
brlcad |
``Erik: are
you willing to be listed as a mentor for anyone? |
| 22:10.23 |
brlcad |
if so, you
should mark the "I'm willing" checkbox |
| 22:10.43 |
brlcad |
if not, have
to evaluate who will be mentoring then and maybe need to drop a
slot |
| 22:16.14 |
``Erik |
I can, not
what I envisioned myself as doing this rotation, though |
| 22:18.56 |
brlcad |
what did you
envison yourself doing? :) |
| 22:19.07 |
jonored |
brlcad: There
is a GSoC proposal submitted from me for boolean evaluation of CSGs
with the same name (Jonathan Gibbons, nick jonored), but I'm
finding that I'm too swamped by a very harsh semester both
academically and not, and haven't been able to properly complete
the expected pre-acceptance work and really address robustness
issues with what I was thinking for an approach. Hopefully I can
try properly next year :) |
| 22:20.22 |
brlcad |
jonored:
okay, letting us know is really very much appreciated |
| 22:21.04 |
brlcad |
jonored:
maybe you can get involved throughout the year before gsoc next
year |
| 22:21.29 |
brlcad |
a sure-fire
way to help get selected is to already be involved :) |
| 22:22.05 |
jonored |
I've got a
summer that I'm not taking classes over to have a break from
coursework and academic projects to do some code :) |
| 22:25.36 |
brlcad |
sounds like a
fun summer :) |
| 22:27.14 |
hippieindamakin8 |
brlcad, so
wat do you say about the robustness ? |
| 22:27.38 |
hippieindamakin8 |
w.r.t what we
have discussed alongside the application |
| 22:49.59 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 23:06.58 |
poolio |
allo
all |
| 23:14.47 |
brlcad |
howdy |
| 23:17.06 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 23:19.05 |
Ralith |
hey
jonored! |
| 23:19.06 |
Ralith |
how
goes |
| 23:24.22 |
jonored |
Ralith: Not
great, but that's to do with said terrible semester. |
| 23:24.37 |
poolio |
brlcad: so
how many of the slots are you taking? :) |
| 23:29.57 |
Ralith |
jonored: over
soon, at least? |
| 23:34.47 |
jonored |
Over soon.
Hopefully ending with a degree, if not the two that I was aiming
for. |
| 23:49.47 |
brlcad |
poolio:
depends on how many of the existing mentors step up and mark that
they're willing to mentor a given application |
| 23:56.27 |
typ0 |
does anyone
know a place where i can get the IGES 5.2 standard full document
? |
| 00:21.15 |
brlcad |
hippieindamakin8: what do you
mean? |
| 00:22.05 |
brlcad |
typ0: I could
probably put in a request to obtain it through ARL if it comes to
it, but I'd imagine that there are at least some resources
on-line |
| 00:22.44 |
typ0 |
yeah |
| 00:22.54 |
typ0 |
i've been
tracking them down |
| 00:23.14 |
brlcad |
hippieindamakin8: the fact that the final
decision lies here goes without saying :) it's more "why do you
want to do it that way" versus some other way |
| 00:23.14 |
typ0 |
and all i got
were general descriptions of what changed between 5.2 and
5.1 |
| 00:23.49 |
typ0 |
but no full
document of either version so i can understand better what is the
change involved |
| 00:23.53 |
brlcad |
it'll all get
taken into consideration when the final reviews and rankings go in,
and patch submissions are evaluated |
| 00:25.03 |
brlcad |
typ0: er, but
5.3 is linked on the wikipedia page no? |
| 00:25.18 |
typ0 |
yes |
| 00:25.26 |
typ0 |
but since we
are at 5.1 level support |
| 00:25.37 |
typ0 |
i will need
to first implement the 5.2 changes right ? |
| 00:26.15 |
typ0 |
my plan was
getting 5.1/5.2 full documents |
| 00:26.20 |
typ0 |
and with the
help of the changes list |
| 00:26.55 |
typ0 |
check which
area changed, how it changed, and read the appropriate
code |
| 00:31.30 |
brlcad |
doesn't
matter so much to know what is/isn't supported through a given
change as just supporting everything new |
| 00:31.39 |
brlcad |
if anything,
you have an option for 5.1 and another for 5.3 |
| 00:31.57 |
brlcad |
but most of
the point updates have been incremental additions |
| 00:32.05 |
brlcad |
not really
removing things that we might be exporting |
| 00:34.47 |
hippieindamakin8 |
brlcad : when
you said "necessary ", i would rather justify that point as better
accuracy ==> better modelling at the cost of computation to some
extent. |
| 00:36.07 |
brlcad |
it's not to
some extent |
| 00:36.11 |
brlcad |
it's to a
massive extent |
| 00:36.23 |
brlcad |
that's why it
needs more articulate justification |
| 00:37.02 |
brlcad |
otherwise
most of our apps would simply just use fixed/infinite precision
math all the time instead of floating point |
| 00:37.04 |
typ0 |
cool
thanks |
| 00:37.22 |
brlcad |
the reality
is that it's often very impractical and makes some things
practically impossible |
| 00:38.31 |
brlcad |
if it's going
to take several hours to evaluate a single BREP/BREP CSG boolean,
that's not very useful or practical no matter how accurate or
robust it is, for example |
| 00:38.55 |
brlcad |
an extreme
example of course, but not outside of what is possible with that
approach |
| 00:39.13 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 00:48.37 |
hippieindamakin8 |
brlcad,
:P |
| 00:50.29 |
hippieindamakin8 |
brlcad, as a
matter of fact i plan on implementing accurate and floating pt.
math and benchmark them and go with the floating point calculations
first |
| 00:54.08 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 01:33.49 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 01:35.07 |
hippieindamakin8 |
i submitted a
routine which isnt exactly a patch but it is from the list of todo
s . |
| 01:36.59 |
brlcad |
hippieindamakin8: the one you were going
to finish by sunday? :) |
| 01:37.16 |
hippieindamakin8 |
brlcad,
yeah |
| 01:37.18 |
hippieindamakin8 |
:| |
| 01:38.03 |
hippieindamakin8 |
brlcad, too
much of academic load :| (but the best part is i ll get done with
the exams by next weekend) |
| 01:38.10 |
brlcad |
understandable :) |
| 01:38.28 |
hippieindamakin8 |
7 full credit
courses :P |
| 01:38.55 |
brlcad |
decent
load |
| 01:40.23 |
Axman6 |
7? what're
you doing man :| |
| 01:40.34 |
Axman6 |
people who do
5 here are crazy |
| 01:42.03 |
hippieindamakin8 |
Axman6, , had
to ,to graduate this may considering i flunked a couple of courses
last year because of my idiocracy.(and low attendance) the classes
were at 8am and 9 |
| 01:42.17 |
Axman6 |
ew |
| 01:42.18 |
hippieindamakin8 |
*considering
that |
| 01:42.34 |
Axman6 |
10's my
earliest start this semester |
| 01:42.52 |
hippieindamakin8 |
working on a
presentation rt now . have one in 12 hrs. |
| 01:42.59 |
hippieindamakin8 |
rather term
paper |
| 01:46.18 |
*** join/#brlcad jonored
(n=jonored@pool-72-74-122-67.bstnma.east.verizon.net) |
| 01:47.07 |
brlcad |
hippieindamakin8: when does your semester
start? |
| 01:47.29 |
brlcad |
sounds like
you should take a summer class to ease the load |
| 01:47.30 |
hippieindamakin8 |
spring in
december last week and fall in the last week of july |
| 01:48.14 |
hippieindamakin8 |
brlcad, naah
i should be done in this semester the way has been going so
far |
| 01:50.29 |
Axman6 |
assumes he's taking all arts courses, so the work load isn't
that bad at all :P |
| 01:51.09 |
hippieindamakin8 |
hehe Axman6 i
am out of all the humanities ,btw all my humanities have been arts
=> a minor in arts |
| 01:51.46 |
hippieindamakin8 |
Axman6, as
open electives i took some sophomore courses of mathematics to ease
up load |
| 01:52.51 |
hippieindamakin8 |
and some
easier courses like robot dynamics , optimization , energy systems.
the only course i fear rt now is computational geometry |
| 01:57.06 |
AlexandreGuedes |
hi |
| 01:57.23 |
AlexandreGuedes |
to fix it
"g-vrml ignores bots that are created with dxf-g" |
| 01:57.36 |
AlexandreGuedes |
can someone
help me ? |
| 02:04.49 |
dreeves |
starseeker
that approach seemed to work for the cylinder |
| 02:05.30 |
dreeves |
brlcad I got
the cylinder rt the way it is in the image without the special case
trim |
| 02:07.56 |
brlcad |
AlexandreGuedes: you have to be much more
specific |
| 02:08.08 |
brlcad |
dreeves:
awesome |
| 02:08.16 |
brlcad |
what'd it
take? |
| 02:12.14 |
AlexandreGuedes |
brlcad: the
problem would be in g-vrml |
| 02:12.29 |
starseeker |
dreeves:
cccoooolll! |
| 02:12.37 |
starseeker |
what does it
do with the tube? |
| 02:13.55 |
AlexandreGuedes |
<PROTECTED> |
| 02:15.53 |
brlcad |
AlexandreGuedes: "a familiar strategy"?
learn the basics of using both those tools, reproduce the problem,
understand the problem, review the code, walk through suspect
routines with a debugger, fix the problem |
| 02:16.22 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 02:16.51 |
AlexandreGuedes |
maybe this
function bot2vrml in g-vrml |
| 02:18.23 |
dreeves |
I have tried
the tube let me clean up a little then I will tackle the other
geometries |
| 02:18.32 |
dreeves |
s/have/have
not |
| 02:19.58 |
starseeker |
awesome
:-) |
| 02:20.12 |
starseeker |
does ritual geek bow |
| 02:20.37 |
dreeves |
it is nice to
finally see it trim without hacks!! |
| 02:21.02 |
dreeves |
returns geek bow |
| 02:22.20 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 02:22.42 |
AlexandreGuedes |
I am
reproducing the error here |
| 02:23.15 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.202.25) |
| 02:23.20 |
dreeves |
now the next
big challenge is to figure out to interrupt the other attributes of
the various trims |
| 02:23.45 |
starseeker |
interrupt? |
| 02:25.42 |
brlcad |
AlexandreGuedes: there are different types
of bots -- some 'solid' some 'shells' and a few others -- find out
which ones each exports/imports and how the routines work with
those types |
| 02:27.47 |
AlexandreGuedes |
ok I'm doing
some test |
| 02:35.32 |
dreeves |
s/interrupt/interpret/ |
| 02:35.41 |
dreeves |
I can't
spell |
| 03:04.23 |
dreeves |
starseeker
the tube isn't working yet because I'm dealing with inner loops any
different than outer loops all the cylinder's loops are outer
basically inner loops you trim the opposite what you trim with
inner loops |
| 03:06.24 |
*** join/#brlcad cad02
(n=c1a4853d@bz.bzflag.bz) |
| 03:06.59 |
cad02 |
any mentors
here |
| 03:09.36 |
cad02 |
is there Sir
Christopher Sen Morrison |
| 03:10.23 |
*** join/#brlcad cad02
(n=c1a4853d@bz.bzflag.bz) |
| 03:11.36 |
cad02 |
any mentors
for brl-cad please |
| 03:13.46 |
Ralith |
cad02: be
patient. |
| 03:13.57 |
Ralith |
this is not,
as they say, a call center. |
| 03:16.07 |
cad02 |
so what shoud
i do for that,i want to talk to brl-cad mentor,its urgent
please |
| 03:17.00 |
louipc |
cad02: you
may want to send an email to the brlcad-devel mailing
list |
| 03:22.22 |
brlcad |
~ask |
| 03:22.23 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
| 03:22.32 |
brlcad |
bah |
| 03:23.40 |
brlcad |
highly suspects it's an applicant that was recently
reprimanded |
| 03:41.53 |
deeeffache |
i never knew
there was a british knight on the dev team |
| 03:42.24 |
brlcad |
heh |
| 03:44.46 |
poolio |
deeeffache:
AHAHA, I was just typing in "Apparently you've been knighted,
brlcad" but you beat me to it |
| 03:53.12 |
PrezKennedy |
brlcad, im
still stuffed from Fogo de Chao |
| 03:59.58 |
brlcad |
PrezKennedy:
heh |
| 04:00.30 |
brlcad |
is sure there is still some meat in his belly from
there |
| 04:01.08 |
starseeker |
we'll have to
get brlcad a coat of arms that uses mossworld |
| 04:01.54 |
brlcad |
already has a 'Morrison' coat of arms, Scottish heritage
ftw |
| 04:02.54 |
starseeker |
cool! |
| 04:09.32 |
poolio |
awesome. |
| 04:14.06 |
typ0 |
sorry to
interrupt... |
| 04:14.30 |
typ0 |
are there any
issues with IGES 5.1 left to solve ? |
| 04:21.24 |
brlcad |
typ0: nothing
specific comes to mind, but wouldn't really know without having a
slew of iges 5.1 files to test out |
| 04:25.18 |
bjorkintosh |
woohoo! i'm
gonna see sonny rollins |
| 04:38.55 |
typ0 |
yeah |
| 04:39.20 |
typ0 |
they have a
lot of files to test in www.iges5x.org |
| 04:39.32 |
typ0 |
i'll add a
phase to my timeline for this testing |
| 04:44.59 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 04:51.03 |
dreeves |
sweet the
tube looks like tube now trims appear to be fully
functional! |
| 04:51.38 |
dreeves |
slow but
noting a little prepping and subdivision couldn't
improve |
| 05:04.00 |
CIA-28 |
BRL-CAD:
03ddreeves70 * r34216
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: this appears to
have the trims implemented correctly now. Pretty slow needs some
work to make faster but a good first cut. |
| 05:07.00 |
dreeves |
starseeker
which one of the files should I test with from http://bzflag.bz/~starseeker/CAD_MODELS/VIA_OpenBook/ |
| 05:16.22 |
dreeves |
starseeker
nevermind I found what I was looking for |
| 05:35.25 |
typ0 |
does brl-cad
support having BREP Objects as CSG Primitives ? |
| 06:12.00 |
Ralith |
brlcad: with
an approach to communication like that, one can see
why. |
| 06:15.55 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1386 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:18.14 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Cylinder.png]]" |
| 06:19.10 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep Dented
Sphere.png]]" |
| 06:20.06 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1389 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:21.23 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Ellipsoid.png]]" |
| 06:22.15 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1391 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:24.45 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1392 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:25.54 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Paraboloid.png]]" |
| 06:27.00 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1394 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:28.01 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Pipe.png]]" |
| 06:29.23 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep Rebuilt
Sphere.png]]" |
| 06:30.39 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1397 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:32.08 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep Sph Cyl
1.png]]" |
| 06:33.33 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1399 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:33.59 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 06:34.14 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 06:34.20 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep Sph Cyl
2.png]]" |
| 06:35.16 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1401 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:37.35 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 06:37.43 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Sphere.png]]" |
| 06:38.30 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1403 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:39.44 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded a new version of
"[[Image:Brep Torus.png]]" |
| 06:40.58 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1405 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 06:41.52 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep
Tube.png]]" |
| 06:43.49 |
dreeves |
starseeker
brlcad I have updated the wiki with raytraced images some issues I
need to investigate but at least now I don't think it is trims
causing the problem |
| 06:44.52 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 06:46.47 |
dreeves |
I'm working
to see if I can raytrace d2.g |
| 06:48.08 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 06:50.48 |
brlcad |
typ0: yes, we
have a new 'brep' primitive being implemented |
| 06:54.29 |
dreeves |
brlcad i put
the tube image on wiki |
| 06:56.50 |
brlcad |
dreeves:
yeah, I saw! |
| 06:57.03 |
brlcad |
pretty cool
-- is that an inner trim with an outer trim? |
| 06:57.10 |
brlcad |
how's the top
handled? |
| 06:57.11 |
dreeves |
yes |
| 06:57.17 |
brlcad |
awesome |
| 06:57.50 |
brlcad |
so you do
some left/right parity test on the trims to determine if it's a
hit? |
| 06:58.30 |
dreeves |
I find the
closest point on the trim to the hit point in uv space |
| 06:59.06 |
dreeves |
then I get
the normal at that point and make direction vector from the closest
point to the hit point then compare the normal to the dir
vector |
| 06:59.31 |
dreeves |
if they are
pointing the same dir then the point is outside the
curve |
| 07:00.09 |
brlcad |
for an outer
trim, how's that help testing against an inner trim? |
| 07:00.20 |
brlcad |
or worse,
nested trims |
| 07:00.33 |
dreeves |
well inner
trims are nested |
| 07:00.50 |
dreeves |
at least they
are in opennurbs |
| 07:01.20 |
dreeves |
same
check |
| 07:01.23 |
brlcad |
right, but
case of having an inner trim that has another outer trim inside of
it |
| 07:01.40 |
brlcad |
a post
running through your tube example's hole |
| 07:02.11 |
dreeves |
yeah the
difference of the 2 is that an inner you throw away hits inside vs
outside |
| 07:02.34 |
dreeves |
it actually
is pretty simple |
| 07:03.20 |
dreeves |
the first
loop is always an outer trim and all the others according to what I
read are holes... |
| 07:04.09 |
dreeves |
Actually have
no rays on the tube where I have an odd number of hits |
| 07:04.38 |
dreeves |
for that
matter none on any of the geometries except I had 2 on the dented
sphere |
| 07:05.05 |
dreeves |
I think that
is from the singularity trims |
| 07:05.07 |
brlcad |
right, but
iirc, you can have holes in your holes (resulting in non-holes hits
inside) |
| 07:05.52 |
dreeves |
remembers someone saying you can't dig a hole in hole
:) |
| 07:05.55 |
brlcad |
might be
misremembering, but recall going over the need for testing all the
curves to determine if the point was trimmed |
| 07:06.10 |
brlcad |
a pseudo
parity test of sorts (but not really) |
| 07:06.17 |
dreeves |
I'm just
joking btw |
| 07:06.23 |
dreeves |
I know what
you are asking |
| 07:06.55 |
brlcad |
does end up
being parity in UV space iirc, a straight line in any
direction |
| 07:07.04 |
dreeves |
Yeah I do
check every trim every time unless I determine the point is
trimmed |
| 07:07.37 |
dreeves |
not the way I
did it the code that was there previously definitely went that
way |
| 07:08.03 |
dreeves |
but I decided
against that was having to many problems with tolerance
issues |
| 07:08.30 |
dreeves |
my special
case trim lead me down that path |
| 07:09.03 |
brlcad |
maybe just
need an even more 'special case' :) |
| 07:09.55 |
dreeves |
Well knock on
wood so far every test case I have thrown at it it is handling the
trims looks like we still have some issues with normal on some of
the spheres |
| 07:10.34 |
brlcad |
yeah, the
dented sphere looks pretty wrong |
| 07:10.54 |
dreeves |
I'm fairly
sure those are normal issues because if it was missing hit points I
would be getting odd number of hits which I'm not |
| 07:12.03 |
dreeves |
I think I'm
getting those issues near face boundaries but I'm not sure
yet |
| 07:13.16 |
dreeves |
would you say
that dent looks right or not? Maybe I should build an actual dent
sphere and compare |
| 07:15.20 |
brlcad |
doesn't look
right to me |
| 07:15.34 |
brlcad |
edges seem
too dark, highlight is peculiar |
| 07:15.50 |
brlcad |
almost like
it's bulging out instead of in |
| 07:16.31 |
dreeves |
probably
should maybe rt from different angles like from the side then it
will be obvious what is going on |
| 07:21.52 |
dreeves |
the code is
very much in prototype form right now btw |
| 07:22.56 |
brlcad |
it's quite
possible that it's actually correct too, just a lot of unnatural
distoration due to lacking global illumination |
| 07:23.37 |
dreeves |
right I'm
more concerned with what looks like the 2 rips in the
surface |
| 07:24.05 |
dreeves |
the rebuilt
sphere is showing the problem as well |
| 07:24.18 |
dreeves |
Do you know
where those test cases came from? |
| 07:28.33 |
dreeves |
The rips
could be from tolerances I guess I will focus on that next. I'm
going to leave the rt of starseeker's d2.g (the laptop part) i
think if it works will probably take hours |
| 07:28.49 |
brlcad |
not quite the
same setup, but interesting nonetheless: http://brlcad.org/tmp/dented_sph.png |
| 07:29.17 |
brlcad |
so maybe it
is right |
| 07:29.46 |
brlcad |
though
interesting that the lights are that different |
| 07:30.55 |
dreeves |
are you
certain that you got all the dimension the same? |
| 07:31.03 |
brlcad |
not at
all |
| 07:31.10 |
brlcad |
just
eyeballed up something similar |
| 07:31.25 |
dreeves |
yeah you case
makes its point though |
| 07:31.48 |
dreeves |
but the
difference in dimension could explain the difference in the
lighting |
| 07:31.59 |
brlcad |
yep |
| 07:32.48 |
brlcad |
betting the
3dm one is probably pretty tiny |
| 07:33.02 |
dreeves |
This is where
I wish I had direct access to more powerful machines I think I
could definitely trouble shoot these more complex
examples |
| 07:33.32 |
dreeves |
Yeah very
small I think |
| 07:33.48 |
dreeves |
faster is
what I meant to say |
| 07:34.14 |
dreeves |
I think I
will be able to trouble shoot them but I'm going to have to
optimize just to be able to troubleshoot |
| 07:35.44 |
dreeves |
I think we
are making good progress what do you think? |
| 07:36.00 |
brlcad |
fantastic
progress |
| 07:36.23 |
brlcad |
and 'we' is
being very generous -- 'you' are making great progress |
| 07:36.29 |
brlcad |
nice
work |
| 07:37.03 |
dreeves |
thanks |
| 07:37.30 |
brlcad |
welp, I have
a presentation to finish up for later today, ttyl! |
| 07:37.45 |
dreeves |
but I wasn't
hamming for a compliment I was just curious because you had seen
previous attempts at this and I was interested in your view of
comparsion |
| 07:38.20 |
brlcad |
the devil is
in the robustness |
| 07:38.28 |
dreeves |
agreed |
| 07:38.48 |
dreeves |
ok well ttyl
I have to grab some sleep I have early meetings |
| 07:39.14 |
brlcad |
previous
efforts were also quick to show quick progress on sample cases, but
then every new sample introduced a new problem, often conflicting
.. and the spagetti and tolerance tweaking hell begins
:) |
| 07:39.59 |
brlcad |
your efforts
are pretty quick, though, great to see |
| 07:40.19 |
dreeves |
yeah I'm not
going to be happy until we get some much larger examples going but
I want to clean up the small ones first |
| 07:47.42 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 10:31.47 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:12.48 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 11:13.12 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 11:42.19 |
*** join/#brlcad elite01
(n=omg@cl-213.dus-01.de.sixxs.net) |
| 11:50.58 |
starseeker |
dreeves:
yeah, the d2 model I've only successfully raytraced
overnight |
| 11:51.25 |
starseeker |
I think there
are something like 20+ minutes of prep time - can't recall how long
the actual raytrace took |
| 11:52.13 |
starseeker |
once that one
is working I'll do a proper import of the openmoko model as
openNURBS files and then we can really have some fun
;-) |
| 12:50.21 |
dreeves |
starseeker
yeah the rt still isn't handling that one yet. Did you see the
update on the wiki of the tube? |
| 12:59.53 |
brlcad |
groves to Only by NiN |
| 13:00.49 |
kanzure |
hah. |
| 13:00.53 |
kanzure |
I now knight
you, sir brlcad |
| 13:03.46 |
brlcad |
bows |
| 13:12.00 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:24.15 |
starseeker |
hrm -
segmentation fault on the d2 raytrace here |
| 13:26.22 |
starseeker |
dreeves:
yeah, saw the tube - awesome! :-) |
| 13:27.26 |
starseeker |
groans as he realizes he needs to stop by the
bank |
| 13:27.30 |
starseeker |
yuck |
| 13:47.01 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 14:05.44 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 14:16.12 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 14:35.24 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DD17.dip.t-dialin.net) |
| 14:49.29 |
*** join/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 14:50.07 |
brlcad |
hi
Elena |
| 14:50.50 |
Elena |
hello |
| 14:50.56 |
Elena |
one
sec |
| 14:54.48 |
*** part/#brlcad Elena
(n=ebautu@89.136.118.141) |
| 14:55.56 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 14:56.28 |
elena |
i'm
back. |
| 15:06.40 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 15:08.44 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 15:11.19 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 15:15.53 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 15:16.37 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 15:58.02 |
starseeker |
reclaims his name |
| 16:00.18 |
pacman87 |
and the
thrown? or do you have to raise an army first? |
| 16:00.36 |
pacman87 |
er,
throne |
| 16:06.07 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 16:07.18 |
louipc |
Sir Morrison
will defend your honour. |
| 16:15.33 |
dreeves2 |
Hey brlcad or
starseeker did ed see the trimmed breps yet? I'm curious about his
feedback |
| 16:17.37 |
``Erik |
grumbles, reads, and grumbles some more |
| 16:19.17 |
``Erik |
this is sad,
I'm seein' crap in email before the irc excahnge that caused it
heh |
| 16:20.10 |
``Erik |
yes, sir
morrison will grab a lance and jump on a horse |
| 16:20.12 |
``Erik |
:D |
| 16:23.53 |
``Erik |
ponders the cultural swath of this all |
| 16:23.56 |
brlcad |
wants a lance and a pony |
| 16:24.26 |
``Erik |
waren't all
too long ago that such a form was highly praising in the anglo
culture, y'know? |
| 16:24.46 |
``Erik |
totally has to give brlcad a "my little pony" now
:D |
| 16:25.40 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 16:25.54 |
``Erik |
I gave my
brother a sailor moon doll for his 16th birthday, he retaliated by
giving me a 'callisto' doll from xena the next year :) |
| 16:26.08 |
``Erik |
hopes he didn't say anything insulting O.o |
| 16:27.57 |
``Erik |
brlcad, you
asked me about mentoring rolls... I'm kinda imagining my utility
being as a meta-mentor this go-around, the # of slots vs mentors
seem to match up for that |
| 16:28.25 |
``Erik |
I can take
one on as a specific roll, but I want to let other people do it so
we get a broader experience base |
| 16:43.18 |
starseeker |
could see brlcad taking up jousting if crew gets to be too
mundane ;-) |
| 16:43.54 |
pacman87 |
or do both at
once and joust on the water |
| 16:44.38 |
starseeker |
heh -
"ramming speed!" |
| 16:45.11 |
``Erik |
did ramming speed in canoes, in freezing weather... was on
the losing boat, it sucked |
| 16:48.52 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 16:49.07 |
starseeker |
``Erik: one
too many viewings of Ben Hur? ;-) |
| 16:49.26 |
``Erik |
um, actually,
I've never seen that |
| 16:50.24 |
starseeker |
finally - a
cultural icon I HAVE seen and someone else HASN'T ;-) |
| 16:50.54 |
``Erik |
dons his dunce cap |
| 17:13.19 |
*** join/#brlcad madant
(n=madant@117.196.146.249) |
| 17:29.38 |
``Erik |
nice,
jabbering with a fbsd dude who got a brlcad license back in 'the
day', with the faxes and shit |
| 17:30.51 |
starseeker |
heh,
cool |
| 17:47.11 |
CIA-28 |
BRL-CAD:
03bob1961 * r34217 10/brlcad/trunk/src/archer/plugins/Wizards/
(tankwizard/TankWizard.tcl tirewizard/TireWizard.tcl): Modified the
TireWizard and the TankWizard to use ttk. |
| 17:53.34 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:06.22 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 18:18.01 |
*** join/#brlcad jdoline1
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 18:52.01 |
brlcad |
``Erik:
that's fine, but then you need to be wielding a meta-mentor hammer
to get the other mentors to check the mentor willingness
button |
| 18:52.36 |
brlcad |
at least two
need to step up, or a slot will be dropped |
| 18:52.47 |
brlcad |
will send an e-mail today |
| 18:52.58 |
brlcad |
dreeves2:
yes, he saw it -- talked about it with him for a while |
| 18:53.28 |
brlcad |
one of the
things that might make things work is that I believe nested trims
toggle orientation for each nesting |
| 18:53.41 |
``Erik |
will serve where needed. |
| 19:00.23 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 19:00.51 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:08.54 |
dreeves2 |
brlcad
thanks. You are correct about the nesting and orientation and the
current trim code supports that |
| 19:09.47 |
dreeves2 |
brlcad are
you seeing a problem with the trim of any of the examples? I think
all those trims are working |
| 19:10.10 |
CIA-28 |
BRL-CAD:
03brlcad * r34218 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
document the fact that opendb reports the open database if no
arguments are given |
| 19:10.14 |
dreeves2 |
I think I am
having a normal problem that is affecting good calculation of the
surface normals |
| 19:20.22 |
CIA-28 |
BRL-CAD:
03brlcad * r34219 10/brlcad/trunk/include/rtgeom.h: clean up
comment ws alignment |
| 19:28.54 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-138-78.3g.claro.net.br) |
| 19:32.00 |
dreeves2 |
I meant I'm
having a tolerance issue that is causing problems when calculating
surface normals |
| 19:32.26 |
dreeves2 |
Seems to be
happening when approaching face edges |
| 19:37.55 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 19:47.36 |
CIA-28 |
BRL-CAD:
03bob1961 * r34220
10/brlcad/trunk/src/tclscripts/swidgets/scripts/togglearrow.itk:
Modified Togglearrow to use ttk. |
| 20:00.28 |
*** join/#brlcad andax
(n=andax__@d213-102-40-224.cust.tele2.ch) |
| 20:00.55 |
*** join/#brlcad andax_
(n=andax__@d213-102-40-224.cust.tele2.ch) |
| 20:06.10 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 20:48.15 |
CIA-28 |
BRL-CAD:
03Carlosvsilva 07http://brlcad.org
* r1407 10/wiki/User:Carlosvsilva: Posted reviewed application,
hope to get feedback! |
| 20:59.26 |
typ0 |
is my
application well-defined and good enough for brl-cad
project |
| 20:59.42 |
typ0 |
or are there
some areas which could be improved further ? |
| 21:06.10 |
brlcad |
typ0: before
answering that, did you do everything on our gsoc
checklist? |
| 21:07.05 |
brlcad |
I don't
recall a patch for you iirc, which would be a problem as that's a
pretty big evaluation factor |
| 21:07.55 |
hippieindamakin8 |
brlcad, any
comments ? |
| 21:08.42 |
hippieindamakin8 |
though it was
not a high priority and was minute |
| 21:08.58 |
typ0 |
brlcad: yep,
i read all |
| 21:09.17 |
brlcad |
not talking
about reading it :) |
| 21:09.21 |
typ0 |
and i am now
picking up a good issue to produce a patch |
| 21:09.22 |
brlcad |
those are
action lists ;) |
| 21:09.33 |
typ0 |
yeah, i mean
i done it all except for the patch |
| 21:09.48 |
typ0 |
i was pretty
busy with brlcad not running on the latest X11 for MacOS
X |
| 21:10.01 |
hippieindamakin8 |
brlcad, :)
neways keeping my fingers crossed |
| 21:10.01 |
typ0 |
ultimately i
downgraded and it started working |
| 21:10.30 |
brlcad |
rather late
to be working on a patch :) |
| 21:10.50 |
typ0 |
i spent a lot
of time with the code, but the bug was crossing to the Tk side of
the project, and i wasn't so familiar with it |
| 21:11.02 |
hippieindamakin8 |
retires to bed |
| 21:11.13 |
typ0 |
yeah im
late |
| 21:11.17 |
typ0 |
previously i
thought there was no interest in my application |
| 21:11.27 |
typ0 |
for the lack
of comments and no answering to my questions here |
| 21:11.48 |
hippieindamakin8 |
brlcad, dont
u ever sleep ?or u go on combat naps ? |
| 21:11.57 |
typ0 |
can i still
submit a patch today ? |
| 21:12.27 |
brlcad |
typ0: you
can, it'll just be tough to evaluate it fairly against
others |
| 21:13.30 |
typ0 |
i
see |
| 21:13.44 |
typ0 |
that's why i
have some work from me at http://planet.homeunix.org |
| 21:14.00 |
typ0 |
gSoC 2007 and
other |
| 21:22.31 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 21:25.17 |
*** join/#brlcad dreeves2
(n=c752f347@bz.bzflag.bz) |
| 21:35.58 |
*** part/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 21:36.04 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 22:20.20 |
Ralith |
brlcad:
thanks for the comments! That addressed my major uncertainties
quite nicely. |
| 22:27.30 |
Ralith |
web browsers
should support embedding user-supplied text editors for multiline
entry areas. |
| 22:38.55 |
Ralith |
mafm: you
there? |
| 22:43.40 |
mafm |
Ralith: yes,
I am |
| 22:44.12 |
Ralith |
mafm: how
much does g3d as-is interact with libged? |
| 22:44.25 |
Ralith |
I remember
hearing that it could load geometry; is that the case? |
| 22:46.07 |
CIA-28 |
BRL-CAD:
03brlcad * r34221 10/brlcad/trunk/src/other/Makefile.am: distcheck
fixme |
| 22:47.41 |
mafm |
Ralith: it
uses commands that in turn call g3d directly |
| 22:48.49 |
Ralith |
how much, not
how. |
| 22:48.53 |
Ralith |
what does it
do? |
| 22:49.09 |
mafm |
basically,
nothing, just sample commands if at all |
| 22:49.27 |
mafm |
libged and
higher level services using it were incomplete by that
time |
| 22:49.52 |
Ralith |
so it can't
load geometry? |
| 22:50.21 |
mafm |
see
GedCommand* |
| 22:51.05 |
mafm |
it calls
libged directly, though it should use the geometry server, I don't
know if it's available now |
| 22:51.39 |
mafm |
it won't load
a .g file and show it in the screen, not that |
| 22:52.17 |
mafm |
I started
implementing simple commands, and discovered (and fixed, then with
help from brlcad) some segfaults in libged itself, etc |
| 22:52.27 |
mafm |
part of that
was already after gsoc |
| 22:53.16 |
Ralith |
kk |
| 22:53.17 |
Ralith |
thanks |
| 22:55.03 |
mafm |
I started by
creating an ogre environment with the windows, camera modes, a
console with commands for controlling the application etc; since
the migration to libged was pretty much WIP and there was no
network abstraction over that at the time |
| 22:55.05 |
brlcad |
the geometry
server is to a simple working state now where it will accept a
connection and can deliver geometry |
| 22:57.04 |
Ralith |
oo |
| 22:57.11 |
Ralith |
that sounds
functional enough to hook up to! |
| 22:57.53 |
Ralith |
considering
that I'm cutting back on the amount of functionality that will be
implemented, think that might be a reasonable thing to
do? |
| 22:59.01 |
mafm |
well, I'd say
that you first get Qt working with OGRE |
| 22:59.21 |
Ralith |
of
course |
| 22:59.25 |
mafm |
it might be
trivial, it might not if there are problems with multi-threading
and so on |
| 22:59.52 |
mafm |
then you can
replace the simple windows by mimicking the interface, or enhancing
them while doing so |
| 23:00.05 |
mafm |
you can then
get rid of non-Qt stuff, and go on from there |
| 23:00.26 |
mafm |
the working
commands are pretty basic |
| 23:00.34 |
Ralith |
that's my
first two milestones right there :P |
| 23:01.10 |
mafm |
you need to
convert geometry to be shown in OGRE, that part is not done (I
created a sample tetrahedron, not a proper conversion) |
| 23:02.07 |
mafm |
and a way to
convert back from ogre to libged |
| 23:02.23 |
Ralith |
ogre's just
for display |
| 23:02.40 |
Ralith |
I think it
would be better to go libged -> ogre, edits -> libged, libged
-> ogre |
| 23:02.46 |
mafm |
well, yes,
but you first need to convert a .g to OGRE object, don't know very
well how |
| 23:02.48 |
Ralith |
rather than
libged -> ogre, edits -> ogre, ogre -> libged |
| 23:03.01 |
Ralith |
I wouldn't do
that either |
| 23:03.09 |
Ralith |
just have
some logic for rendering the .g in-situ |
| 23:03.40 |
mafm |
but then need
to be able to tell to libged which vertex that you're selecting to
remove or something like that, I guess (dunno much about the
process of modelling) |
| 23:03.45 |
Ralith |
e.g. I may
try to implement some basic mged-style wireframeness, which would
just look at the primitive type and its params and procedurally
form a wireframe based on that |
| 23:03.51 |
Ralith |
so? |
| 23:04.21 |
Ralith |
all actual
editing of the file should be done through the interface provided
by BRL-CAD |
| 23:04.31 |
Ralith |
remember,
this is supposed to be something of a thin client |
| 23:04.52 |
Ralith |
just a GUI
and state display |
| 23:04.57 |
mafm |
yes, but if
you position the object by clicking with the mouse, you'll have to
convert from OGRE coordinates to brl-cad coordinates |
| 23:05.21 |
Ralith |
er, is there
a reason not to just set things up such that they're
equivalent? |
| 23:05.43 |
Ralith |
it'd be
incredibly convenient to do things like selecting objects would be
incredibly convenient through librt, anyway, I think |
| 23:06.38 |
Ralith |
'cuz that's
what a selection is, really; tracing a ray from the camera's orign
through the screen and finding the first thing it intersects
with |
| 23:07.03 |
mafm |
I don't even
know if OGRE coordinates and brl-cad's are the same |
| 23:07.40 |
mafm |
so (1, 0, 3)
might not be the same point in OGRE display and brl-cad backend
:) |
| 23:08.36 |
mafm |
note that I
say might, actually it's one of the things that I'd had liked to
investigate last summer, but didn't get to that point |
| 23:08.48 |
Ralith |
so if they
aren't, set them up to be so. |
| 23:08.56 |
Ralith |
it's a 3
dimensional cartesian coordinate system |
| 23:09.04 |
Ralith |
they can only
be so different |
| 23:09.38 |
mafm |
I didn't say
that it was a lot of work, just that it needs to be studied
:) |
| 23:10.28 |
mafm |
and if OGRE
doesn't accept .g files, which I guess not, you have to perform
some kind of conversion to "load" the view in OGRE |
| 23:10.59 |
Ralith |
I'm fairly
sure OGRE can render things in ways other than loading
files. |
| 23:11.35 |
mafm |
yes, like
creating so called "manual objects" (as the sample
tetrahedron) |
| 23:13.20 |
mafm |
probably this
step is also not very hard, I just name it as something to be done
not yet implemented in g3d |
| 23:15.05 |
mafm |
if you're
satisfied with the way that commands, camera modes etc work, I'd
say that the next steps would be to hook to the Geometry Service
and start replicating the functionality of the editor |
| 23:15.36 |
mafm |
maybe the
structure of commands as it's now it's not needed, and for GED
commands you can just send them as a string over the
network |
| 23:16.29 |
mafm |
(currently it
does some pre-processing checking number of arguments,
etc) |
| 23:17.08 |
mafm |
brlcad: am I
correct, or am I a bad mentor? :P |
| 23:29.38 |
mafm |
... |
| 00:07.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 02:00.29 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-153-51.3g.claro.net.br) |
| 02:19.30 |
CIA-28 |
BRL-CAD:
03Carlosvsilva 07http://brlcad.org
* r1408 10/wiki/User:Carlosvsilva: Added a patch to my IGES
converter application, to enable the converters to support
different versions of the standard |
| 02:35.35 |
starseeker |
dreeves: I'm
going to look into the prep time, see what's taking so long on the
d2 model |
| 02:37.14 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-173-140.3g.claro.net.br) |
| 02:38.29 |
dreeves |
starseeker
sounds good!! |
| 02:38.47 |
starseeker |
hard to debug
raytracing when the prep time is so long! |
| 02:39.41 |
dreeves |
I'm
investigating what is causing the spots on a few of the
examples |
| 02:39.59 |
dreeves |
Yes agreed
that definitely will slow the process down |
| 02:40.46 |
dreeves |
If I get the
spots problem cleaned up we problem should spend a little time
cleaning up the brep.cpp code |
| 02:41.51 |
dreeves |
are you able
to spend much of your day working on this or is this more of a pet
project at the moment? |
| 02:44.50 |
CIA-28 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1409 10/wiki/User:Ralith: Modified milestones and timeline to
lessen scope |
| 02:46.00 |
Ralith |
brlcad:
^ |
| 02:50.38 |
starseeker |
dreeves: I
can spend some time on it - my difficulty is simply getting up to
speed on the code/concepts in general |
| 02:50.58 |
starseeker |
prep should
be a good place to work though |
| 02:54.10 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 02:54.52 |
dreeves |
yeah that
should be a good place there are a lot of different things a play
here can be a little steep to get started |
| 02:55.26 |
dreeves |
but once you
get into it isn't that bad though |
| 03:00.05 |
dreeves |
I'm sure most
think the spots on dented sphere are missed rays but if they are
they are going all the ray through with out hitting either side
otherwise I would have an odd number of hits along the
ray |
| 03:00.31 |
dreeves |
I fairly
confident something is getting hosed up in calculating the
normal |
| 03:00.39 |
starseeker |
nods |
| 03:01.08 |
dreeves |
does Ed think
it is missed rays? |
| 03:01.22 |
starseeker |
don't
know |
| 03:01.44 |
starseeker |
I don't see
any missed rays - I see a conflict between the shadow effect and
the light reflection effect |
| 03:02.39 |
starseeker |
any idea what
that clipping is on the bottom of Paraboloid? |
| 03:02.40 |
dreeves |
what about
the spots away from the dent? I think the actual dent is fine it
is just some weird optics going on because of the
lighting |
| 03:02.57 |
starseeker |
um. not sure
about those |
| 03:05.47 |
dreeves |
Those are the
spots I'm really concerned about and the ones on the rebuiltSphere
the problem is a little more obvious there |
| 03:53.02 |
*** part/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 03:53.09 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 04:13.18 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 04:13.59 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 04:45.29 |
AlexandreGuedes |
brlcad:
sean |
| 04:45.56 |
AlexandreGuedes |
up to now, i
didn't manage to fix a bug |
| 04:47.42 |
AlexandreGuedes |
would be
important I submit another patch, only to show that I had build the
system ? |
| 04:48.21 |
pacman87 |
the patch is
to show how you code |
| 04:48.36 |
pacman87 |
any patch
would be better than no patch |
| 04:49.58 |
AlexandreGuedes |
this is the
main goal |
| 04:52.18 |
AlexandreGuedes |
pacman87: You
took part in gsoc 2008 with brl-CAD ? |
| 04:54.21 |
pacman87 |
yes |
| 04:54.36 |
pacman87 |
AlexandreGuedes: yes |
| 04:56.49 |
AlexandreGuedes |
are you Dawn
Thomas ? |
| 04:57.08 |
pacman87 |
no |
| 04:57.56 |
pacman87 |
http://brlcad.org/wiki/User:Pacman87 |
| 04:59.33 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 05:01.14 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 05:15.42 |
*** join/#brlcad madant
(n=madant@117.196.145.210) |
| 05:17.44 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 05:27.30 |
AlexandreGuedes |
pacman87: the
submiteds patch are here ?
http://sourceforge.net/tracker/?words=tracker_browse&sort=open_date&sortdir=desc&offset=0&group_id=105292&atid=640804 |
| 05:28.07 |
pacman87 |
add that as a
comment on your application on the GSoC site |
| 05:28.24 |
pacman87 |
and i'm not
the one who's evaluating you |
| 05:29.08 |
pacman87 |
and add you
application to your user page in the wiki (if you haven't already
done so) |
| 05:29.18 |
pacman87 |
add
your* |
| 05:29.29 |
pacman87 |
and put the
link there as well |
| 05:33.22 |
louipc |
pacman87: :O
you're like a prodigy! |
| 05:33.51 |
pacman87 |
louipc:
? |
| 05:34.36 |
louipc |
me/ee 4.0 gpa
:D |
| 05:34.43 |
louipc |
I think
that's nuts |
| 05:41.05 |
pacman87 |
i have fun
:D |
| 05:44.03 |
pacman87 |
currently
juggling a microcontroller project, writing a trusted p2p network,
distributed failure recovery programming lab, modifying another
processor simulator program to include virtual memory, and a few
other things |
| 05:54.44 |
CIA-28 |
BRL-CAD:
03AlexandreGuedes 07http://brlcad.org * r1410
10/wiki/User:AlexandreGuedes: New page: ==SoC Applications==
===Further OpenGL Geometry Editor GUI development===
====Abstract==== Nowadays there are many geometry formats files,
each one is more appropriate to a different appli... |
| 06:06.27 |
CIA-28 |
BRL-CAD:
03AlexandreGuedes 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:ConverterTable.jpg]]" |
| 06:18.48 |
CIA-28 |
BRL-CAD:
03AlexandreGuedes 07http://brlcad.org * r1412
10/wiki/User:AlexandreGuedes: |
| 06:36.44 |
yukonbob |
hi
cadnerds |
| 06:37.06 |
pacman87 |
hi
yukonbob |
| 06:37.11 |
yukonbob |
apologizes for lack of presence.... crappy net connection,
crazy werk. :P |
| 06:37.18 |
yukonbob |
waves to pacman87 |
| 06:38.04 |
pacman87 |
waves, then goes back to figuring out the keypad
interface |
| 06:38.18 |
pacman87 |
somehow
managed to swap rows and columns |
| 06:38.37 |
yukonbob |
keypad
iface... mged? |
| 06:38.47 |
pacman87 |
nope,
microcontroller lab |
| 06:38.54 |
yukonbob |
ah |
| 06:39.00 |
yukonbob |
_that_
interface |
| 06:43.44 |
AlexandreGuedes |
now I have
wiki page |
| 06:44.00 |
AlexandreGuedes |
pacman87: |
| 06:44.33 |
pacman87 |
AlexandreGuedes: i'm not in charge of
anything relating to GSoC |
| 06:44.49 |
AlexandreGuedes |
i
know |
| 06:44.58 |
pacman87 |
just making
sure |
| 06:45.42 |
AlexandreGuedes |
I just said
because you suggested |
| 06:47.19 |
AlexandreGuedes |
Actually I
knew, but up to now I didn't have done |
| 07:16.09 |
Ralith |
22:55:41 <
CIA-28> BRL-CAD: AlexandreGuedes http://brlcad.org * r1410
/wiki/User:AlexandreGuedes: New page: ==SoC Applications==
===Further OpenGL Geometry Editor GUI development===
====Abstract==== Nowadays there are many geometry formats files,
each one is more appropriate to a different appli... |
| 07:16.14 |
Ralith |
CIA's
bugged. |
| 07:16.23 |
Ralith |
one of those
headers is from my userpage. |
| 07:21.03 |
pacman87 |
of course the
CIA's bugged, what do you think the NSA does in their spare time?
:P |
| 07:22.53 |
Ralith |
lol |
| 07:23.46 |
AlexandreGuedes |
Ralith: CIA
is ok, I got your page as model, but I forgot to delete this
sentence "Further OpenGL Geometry Editor GUI
development" |
| 07:24.12 |
Ralith |
oh? I guess I
overlooked it |
| 07:24.22 |
Ralith |
was all worried about competition
>_> |
| 08:08.38 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 08:22.09 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E5EA.dip.t-dialin.net) |
| 08:29.54 |
*** part/#brlcad jdoline1
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 09:00.08 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 09:10.00 |
hippieindamakin8 |
waves |
| 09:10.23 |
pacman87 |
waves back |
| 09:28.43 |
AlexandreGuedes |
o create my
patche but didin't report some new files that I created |
| 09:29.03 |
AlexandreGuedes |
i used "svn
diff > brlcad.patch" |
| 09:31.49 |
pacman87 |
AlexandreGuedes: did you do a svn
add? |
| 09:32.25 |
AlexandreGuedes |
i
didn't |
| 09:32.36 |
AlexandreGuedes |
i must
? |
| 09:33.11 |
pacman87 |
points in the general direction of the svn man
page |
| 09:33.41 |
pacman87 |
4:30am, time
for bed |
| 09:35.12 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E5EA.dip.t-dialin.net) |
| 09:55.45 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 10:04.14 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:09.18 |
CIA-28 |
BRL-CAD:
03AlexandreGuedes 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:WorkScope.jpg]]" |
| 11:21.31 |
d-lo |
stretches. |
| 11:21.34 |
d-lo |
mernin! |
| 11:22.02 |
brlcad |
howdy
d-lo |
| 11:22.18 |
d-lo |
hey there.
How are things? |
| 11:22.45 |
brlcad |
pretty
good! |
| 11:23.54 |
d-lo |
going rowin'
this morning? |
| 11:23.56 |
brlcad |
d-lo: so are
you bol? |
| 11:24.17 |
d-lo |
bol ==
?? |
| 11:24.28 |
brlcad |
awol ->
aol -> bol ;) |
| 11:24.49 |
d-lo |
ah yes, I
see. |
| 11:25.03 |
d-lo |
I am
currently on vacation from vacation... so, back to work
:) |
| 11:28.06 |
CIA-28 |
BRL-CAD:
03AlexandreGuedes 07http://brlcad.org * r1414
10/wiki/User:AlexandreGuedes: AlexandreGuedes |
| 11:29.30 |
AlexandreGuedes |
brlcad: I did
some jobs tonight |
| 11:30.16 |
brlcad |
AlexandreGuedes: kinda very last minute,
isn't it? :) |
| 11:30.23 |
AlexandreGuedes |
I wrote some
comments about it in proposal page |
| 11:30.28 |
brlcad |
you know that
today is the decision day |
| 11:31.03 |
brlcad |
still, thanks
for the updates -- will take a look at them |
| 11:31.17 |
AlexandreGuedes |
brlcad: yes I
know I have some commitments |
| 11:32.08 |
AlexandreGuedes |
but now I'm
free |
| 11:45.05 |
brlcad |
d-lo: have
you seen the gsoc applications yet? |
| 11:45.32 |
brlcad |
can talk in
private about any of them specifically (or via the private comments
on sochop) |
| 11:47.15 |
brlcad |
I went ahead
and assigned you to someone just to have you assigned, but there
are three or four 'finalists' still being evaluated for the last
two slots (they're the ones ranked 1 and 0) |
| 11:47.30 |
d-lo |
brlcad: I
have a huge backlog of GSoC emails to read :/ Been disconnected
for almost two weeks now ;) |
| 11:47.57 |
d-lo |
last time I
read email was about the 2nd/3rd of April |
| 11:48.24 |
brlcad |
I know,
that's why I'm mentioning it now |
| 11:48.29 |
brlcad |
today is the
final selections day |
| 11:48.33 |
brlcad |
in a few
hours |
| 11:49.19 |
brlcad |
at this
point, I don't think there is anything that you "have" to
do |
| 11:49.36 |
brlcad |
the only
thing you "should" do, though, is mark which of the non-negative
applications you'd be willing to mentor |
| 11:49.47 |
brlcad |
there's a
button |
| 11:50.02 |
brlcad |
whether it's
the one I have you assigned to now, or one of the
others |
| 11:50.06 |
d-lo |
I can do a
'button'.... sounds easy ;) |
| 11:50.19 |
brlcad |
lemme know
(in PM) if you have a preference for mentoring one of the other
projects |
| 11:50.20 |
d-lo |
I'll add it
to the queue of 'thingados' today |
| 11:50.47 |
brlcad |
http://socghop.appspot.com/org/list_proposals/google/gsoc2009/brlcad |
| 11:50.55 |
brlcad |
that's where
the fun is at |
| 11:51.05 |
d-lo |
thanks for
the linkage! |
| 11:51.40 |
brlcad |
only daniel
and cliff are "set" mentors |
| 11:51.59 |
brlcad |
the rest can
be adjusted, and the 1-ranked are still tentative |
| 11:52.40 |
brlcad |
er,
1-scored |
| 12:09.30 |
AlexandreGuedes |
brlcad: Were
the decisions already taken? |
| 12:12.51 |
hippieindamakin8 |
waves at brlcad and d-lo |
| 12:14.20 |
d-lo |
Mernin
Hippie! |
| 12:17.47 |
brlcad |
AlexandreGuedes: eh, you did read my last
line there right? :) |
| 12:18.01 |
brlcad |
~dict
tentative |
| 12:18.16 |
brlcad |
well that was
mostly useless |
| 12:19.19 |
brlcad |
~dict 4
tentative |
| 12:19.53 |
d-lo |
'creeping
like snail' lol |
| 12:21.31 |
brlcad |
ersatz
students! |
| 12:22.36 |
AlexandreGuedes |
you are
talking about Student Proposal |
| 12:28.41 |
brlcad |
very
observant |
| 12:30.34 |
AlexandreGuedes |
i made a
confusion here |
| 12:31.52 |
AlexandreGuedes |
I was not
talking about this subject |
| 12:33.59 |
brlcad |
waits for AlexandreGuedes to complete his
thought.. |
| 12:34.29 |
_clock_ |
I talked
about brlcad to an older couple on the train |
| 12:34.40 |
AlexandreGuedes |
when you said
"AlexandreGuedes: eh, you did read my last line there right?
:)" |
| 12:35.16 |
AlexandreGuedes |
i asked "you
are talking about Student Proposal" ? |
| 12:35.22 |
d-lo |
's brain just SCRAMmed :/ |
| 12:35.53 |
brlcad |
AlexandreGuedes: I don't need a replay --
you're just not clarifying anything |
| 12:36.25 |
brlcad |
to clarify,
you could explain what you were asking about instead of saying what
you were not asking about |
| 12:36.59 |
AlexandreGuedes |
but now I had
already understood... |
| 12:37.40 |
AlexandreGuedes |
hehe |
| 12:37.41 |
d-lo |
hahahahahahaha |
| 12:38.08 |
d-lo |
I think I an
going to copy/paste this into my blog.... its great! |
| 12:38.31 |
AlexandreGuedes |
i need sleep
some time |
| 12:39.09 |
brlcad |
is confused and gives up |
| 12:44.29 |
CIA-28 |
BRL-CAD:
03bob1961 * r34222 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Ripped out the edit history
hack. |
| 12:45.19 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 12:46.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 12:48.30 |
d-lo |
brlcad:
lordy you keep it cold in here! 67?! You on crazy
mo-fo. |
| 12:48.36 |
d-lo |
on==one |
| 12:48.50 |
brlcad |
shrugs, felt warm yesterday |
| 12:49.50 |
brlcad |
plus, the
brain slows down when it's warm |
| 12:49.56 |
brlcad |
why most
schools are frigid |
| 12:50.13 |
d-lo |
the real key
is to oxygenate the work place ;) |
| 12:50.29 |
louipc |
hmmm. that's
interesting. |
| 12:50.37 |
d-lo |
bump up o2
levels by 0.5% .... makes a disturbing difference! |
| 12:50.37 |
brlcad |
too much O2
can make you sleepy too |
| 12:50.56 |
brlcad |
O2+warm,
killer |
| 12:51.07 |
brlcad |
called nap
time |
| 12:51.14 |
d-lo |
true, but the
Casinos in Vegas have the concept down pat. Submarines do too
;) |
| 12:53.09 |
d-lo |
as for the
GSoC Student proposals... they are supposed to propse and detail a
work project... correct? |
| 12:53.15 |
brlcad |
two
environments where I'd argue that they want people to think less,
not more ;) keep them subdued to programmed responses (keep
playing, push the knobs we told you to push) |
| 12:54.16 |
brlcad |
wonders if more O2 makes you more inclined to be suggestive
or obey |
| 12:54.41 |
brlcad |
sounds like
an experiment to impose on management! |
| 12:54.53 |
louipc |
hahah |
| 12:56.03 |
d-lo |
actually,
lack of o2 makes you more sleepy than excessive o2 does. If you
are in a casino and start feeling out of breath and/or sleepy,
you'll leave the slots! On a sub, you need to be alert and ready
to go. Thus (on a sub at least) they bump abient o2 levels by
0.25-0.5% above 'the norm'... can't speak to what Casinos bump
theirs to. |
| 12:56.28 |
d-lo |
excessive o2
does make lighting a cigarette much more exciting though
:) |
| 12:56.45 |
brlcad |
not sleepy,
just not thinking at full capacity |
| 12:57.48 |
brlcad |
anyways,
irrelevant with little means to test any theories at this point
;) |
| 12:57.59 |
d-lo |
hrm, i need
to get you on a Tiger cruise on a sub sometime. I think then you
would realize you want the subsailors thinking at 101% capacity
;) |
| 12:58.32 |
d-lo |
...I'll
'borrow' an o2 cyl and start a slow bleed in the building next week
:) |
| 12:58.56 |
louipc |
kaboom |
| 12:59.24 |
d-lo |
louipc: nah,
no boom. Hence the 'slow' bleed ;) |
| 12:59.25 |
brlcad |
warm
body/brain is still pretty well studied, hardly anything motivates
and energizes as well as slightly 'cool' |
| 12:59.31 |
CIA-28 |
BRL-CAD:
03Carlosvsilva 07http://brlcad.org
* r1415 10/wiki/User:Carlosvsilva: Posted the patch in SF.net bug
tracker, added TOC and cleanup formatting |
| 12:59.44 |
d-lo |
as much as I
want a new building, thats not the right way to get it
:) |
| 13:00.04 |
brlcad |
and yes,
they're supposed to propose a project |
| 13:00.14 |
brlcad |
don't waste
your time on the ones already marked negative |
| 13:00.20 |
louipc |
I wonder if
that's why northern countries seem more developed than countries in
warmer climates |
| 13:00.55 |
louipc |
well, the
danger of freezing is definitely motivating. |
| 13:01.01 |
brlcad |
louipc: I'm
sure there is some truth to that |
| 13:01.17 |
brlcad |
but there's
also the issue of environment |
| 13:01.34 |
brlcad |
when you're
in paradise ... who wants to work? |
| 13:01.42 |
louipc |
yep |
| 13:02.12 |
d-lo |
brlcad so you
are saying that warm == paradise? =D |
| 13:03.25 |
brlcad |
in terms of
being 'comfortable' and 'relaxed' and having lazy days on the beach
with a pi?a coloda -- absolutely :) |
| 13:04.14 |
d-lo |
ah, okay. I
was about to point out that a bulk of northern part of Africa is
also very warm :) |
| 13:04.46 |
brlcad |
hydration is
a key feature of paradise ;) |
| 13:06.08 |
d-lo |
good point.
never get a beer locally brewed in the middle east....
blech. |
| 13:17.12 |
mafm |
brlcad: piña
colAda :P |
| 13:18.00 |
mafm |
(that's an n
with a tilde ~ above, if the charset is not showing it
properly) |
| 13:21.17 |
mafm |
d-lo: I was
preparing the application and so I put the "placeholder", but alas
I didn't apply and couldn't withdraw it after that, so that
explains the litter :P |
| 13:22.02 |
d-lo |
ah, I see.
-5 for pathetic excuses. ;) |
| 13:22.28 |
brlcad |
mafm:
different charsets, that's what mine was too |
| 13:22.34 |
brlcad |
??? |
| 13:26.24 |
mafm |
brlcad: I
only see ??? :) |
| 13:27.38 |
madant |
too |
| 13:28.02 |
madant |
swam after 4 months |
| 13:28.34 |
madant |
brlcad:
rowing is not stressful on the knees ? |
| 13:28.38 |
mafm |
but the point
was that it's colada, not coloda (filtered pineapple) |
| 13:28.44 |
brlcad |
madant:
nope |
| 13:28.50 |
d-lo |
wow, you were
swimming at the age of 4 months? not bad madant, not
bad! |
| 13:28.58 |
brlcad |
mafm: just a
typo :P |
| 13:29.04 |
madant |
i mean
compared to running . :) |
| 13:29.08 |
mafm |
the dictionary nazi |
| 13:29.12 |
madant |
d-lo,
ha |
| 13:29.45 |
madant |
brlcad, i
hear that done properly rowing works almost every muscle in your
body ? |
| 13:29.54 |
brlcad |
pretty
much |
| 13:30.27 |
madant |
brlcad,
considering there are a lot of muscles on the face , maybe a rowing
with a lot of gestures would be complete body work out
:P |
| 13:30.53 |
brlcad |
you end up
making a lot of different faces depending on the level of pain
regardless ;) |
| 13:31.01 |
madant |
was afraid that he had forgot swimming. |
| 13:31.48 |
brlcad |
chuckles at
http://www.uksport.gov.uk/assets/Image/newsArchive/rowing_0912_main.jpg |
| 13:34.50 |
louipc |
http://images.nlroei.nl/fotoboek/images/onzrjzytpa/285-8523_IMG.jpg |
| 13:35.10 |
brlcad |
hehe |
| 13:35.37 |
louipc |
this is
comedy gold. I should take up rowing |
| 13:39.51 |
brlcad |
you
should! |
| 13:40.02 |
brlcad |
everyone
should.. fantastic sport :) |
| 13:40.45 |
louipc |
I'm going to
try rock climbing/bouldering first |
| 13:43.03 |
madant |
thinks with these pictures no doubt , rowing rocks
:P |
| 13:43.17 |
madant |
louipc,
bouldering is awesome |
| 13:44.02 |
madant |
likes technical sport climbing, but the low equipment
requirement of bouldering is nice :) |
| 13:45.11 |
_clock_ |
have you ever
done tree climbing? |
| 13:50.21 |
madant |
lives in Kerala-"god's own country"- where people climb even
coconut trees - not to mention a college which teaches advanced
courses on the same :P |
| 13:50.48 |
d-lo |
an advanced
course on Coconut tree climbing? |
| 14:04.00 |
madant |
d-lo, yep
:) |
| 14:04.45 |
d-lo |
awesome,
simply awesome. Is there a degree in 'climbing' ? |
| 14:05.00 |
_clock_ |
I am making a
tree-age-dee |
| 14:05.15 |
_clock_ |
MaSc. |
| 14:05.34 |
_clock_ |
Master of
ascent |
| 14:06.03 |
_clock_ |
I would like
to live in a tree house |
| 14:06.37 |
madant |
http://www.hindu.com/mp/2004/04/12/stories/2004041202230200.htm
this is not exactly the place , but i can't find the link for the
real deal :P |
| 14:07.33 |
madant |
oh forgot to
mention, there is also a elephant in-charge training centre here
too :P |
| 14:07.34 |
d-lo |
is experiencing come culture shock! |
| 14:07.48 |
madant |
should desist :D |
| 14:08.05 |
_clock_ |
I hope
physical fitness is not among requirements |
| 14:08.36 |
_clock_ |
just filled a chocolate Easter bunny with water and put into
a freezer |
| 14:10.22 |
_clock_ |
"We plan to
work as a group and hope to get a telephone" |
| 14:13.22 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 14:15.07 |
CIA-28 |
BRL-CAD:
03indianlarry * r34223 10/brlcad/trunk/src/ (conv/asc2g.c
librt/primitives/bot/bot.c): (log message trimmed) |
| 14:15.07 |
CIA-28 |
BRL-CAD:
Fixed memory issues CAD team was having with 'asc2g' on new Tcl
based ASCII |
| 14:15.07 |
CIA-28 |
BRL-CAD:
format. There were a couple of issues, first memory wasn't being
freed |
| 14:15.07 |
CIA-28 |
BRL-CAD:
correctly from Tcl list object so took Bob's advice and changed
usage |
| 14:15.07 |
CIA-28 |
BRL-CAD: in
rt_bot_adjust(), second 'asc2g' was using Tcl_EvalFile() which
buffers |
| 14:15.11 |
CIA-28 |
BRL-CAD:
entire file into memory again causing issues with some large
Pro-E |
| 14:15.13 |
CIA-28 |
BRL-CAD:
conversions. Changed 'asc2g.c' to load ASCII file in
manageable |
| 14:55.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 14:58.12 |
*** join/#brlcad dreeves2
(n=c752f34a@bz.bzflag.bz) |
| 14:59.14 |
dreeves2 |
starseeker
and brlcad so the rips in dented sphere I think I have determined
those are holes. |
| 15:00.29 |
dreeves2 |
If you rt
from a different angle the problem becomes more obvious |
| 15:00.47 |
dreeves2 |
I have some
work to do there |
| 15:38.05 |
*** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 15:38.33 |
*** part/#brlcad tofu
(n=sean@bz.bzflag.bz) |
| 15:47.59 |
d-lo |
tofu
eh? |
| 16:26.13 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 16:36.31 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 16:57.42 |
*** join/#brlcad dreeves2
(n=c752f34a@bz.bzflag.bz) |
| 17:13.23 |
CIA-28 |
BRL-CAD:
03bob1961 * r34224 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Mods to update things for when not
Archer is not inheriting from itk::Toplevel. |
| 17:13.52 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 17:14.30 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 18:10.12 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1416 10/wiki/User:Jdoliner: Copied in my application, I'll update
this to include more information in about an hour. |
| 18:35.39 |
starseeker |
dreeves: hmm
- here's a backtrace for the raytrace failure with openbook:
http://pastebin.bzflag.bz/m12bd2f0e |
| 18:44.09 |
brlcad_brlcad |
starseeker:
you still have the debug session up? |
| 18:44.37 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 18:45.05 |
starseeker |
yes |
| 18:45.27 |
starseeker |
brlcad_brlcad: still up |
| 18:45.42 |
brlcad_brlcad |
p
i |
| 18:45.48 |
brlcad_brlcad |
p
trim->m_c2i |
| 18:46.07 |
starseeker |
p i ->
0 |
| 18:46.20 |
starseeker |
p
trim->m_c2i -> 3422 |
| 18:47.14 |
starseeker |
p t ->
0 |
| 18:50.07 |
brlcad_brlcad |
p
trimCurve |
| 18:50.43 |
brlcad_brlcad |
and, p
curveApproximations[trim->m_c2i][i] |
| 18:50.51 |
brlcad_brlcad |
suspect
that's what's oob |
| 18:52.02 |
brlcad_brlcad |
ahh,
definitely |
| 18:52.18 |
brlcad_brlcad |
curveApproximations is only
[100][200] |
| 18:52.25 |
brlcad_brlcad |
that index of
3422 is way out of range |
| 18:53.51 |
brlcad_brlcad |
p
loop->TrimCount() |
| 18:54.42 |
starseeker |
(gdb) p
trimCurve |
| 18:54.43 |
starseeker |
$5 = (const
ON_Curve *) 0x8ce6dd0 |
| 18:55.08 |
starseeker |
(gdb) p
curveApproximations[trim->m_c2i][i] |
| 18:55.08 |
starseeker |
$6 = { x =
1.2401802885544486e+151, y = 1.9476649113403901e+243, z =
1.2401796641872861e+151 |
| 18:55.11 |
starseeker |
} |
| 18:55.27 |
brlcad_brlcad |
yeah, random
data |
| 18:55.33 |
brlcad_brlcad |
the last
p? |
| 18:55.37 |
starseeker |
(gdb) p
loop->TrimCount() |
| 18:55.39 |
starseeker |
$7 =
4 |
| 19:02.11 |
CIA-28 |
BRL-CAD:
03brlcad * r34225
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: dumb hack, but
it should affect a curve approximations crash. looks like
trim->m_c2i is about 3500 .. which is about 3400 indices too
many for the previous size of the container. up the limit to
10000. |
| 19:04.47 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-247-193.dclient.hispeed.ch) |
| 19:12.47 |
CIA-28 |
BRL-CAD:
03brlcad * r34226 10/brlcad/trunk/ (3 files in 2 dirs): quell
warnings for virtual destructors, unused vars, and size_t
types |
| 19:23.10 |
CIA-28 |
BRL-CAD:
03brlcad * r34227
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: some style
cleanup, should follow hacking guide |
| 19:26.17 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 19:27.23 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 19:30.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 19:37.27 |
starseeker |
brlcad:
yeah, that let the d2 model raytrace |
| 19:43.55 |
CIA-28 |
BRL-CAD:
03brlcad * r34228
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: quell all
warnings |
| 19:45.02 |
hippieindamakin8 |
hey brlcad
mafm |
| 19:46.42 |
CIA-28 |
BRL-CAD:
03brlcad * r34229 10/brlcad/trunk/include/vector.h: unbustage. the
virtual destructors need to be defined somewhere even if they do
nothing |
| 19:47.34 |
brlcad |
starseeker:
cool |
| 19:47.35 |
brlcad |
maybe you can
make that use a better container |
| 19:48.09 |
brlcad |
maybe an stl
container instead of a fixed array, preallocated to some large size
but increasing in chunks for efficiency |
| 19:48.48 |
brlcad |
of if
anything, some detection logic to make sure it doesn't crash at
least -- abort gracefully if the index is out of range |
| 19:48.57 |
starseeker |
nods |
| 19:49.08 |
brlcad |
right now,
it's just wasting a bit of memory |
| 19:59.07 |
mafm |
hi
hippieindamakin8 |
| 20:01.13 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 20:02.45 |
*** join/#brlcad andax
(n=andax__@d213-102-40-88.cust.tele2.ch) |
| 20:09.41 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1417 10/wiki/User:Jdoliner: Added in timeline |
| 20:16.53 |
starseeker |
looks like
the most expensive part of the preprocessing is in
brep_preprocess_trims lines 225 to 239 |
| 20:32.24 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 20:37.41 |
starseeker |
uhhh...
correct me if I'm wrong, but is the current raytracing using
brep_preprocess_trims for ANYTHING? |
| 20:39.26 |
brlcad |
yeah, during
prep |
| 20:39.37 |
brlcad |
brep_build_bvh() |
| 20:40.12 |
starseeker |
yeah, I know
prep is being called, but I'm not seeing where it's using the
generated information |
| 20:41.47 |
brlcad |
if i'm
understanding brep_preprocess_trims() right, it's rather obscene
implementation |
| 20:42.43 |
brlcad |
looks like
it's iterating over the bounding volume nodes, and for each
bounding volume, seeing what geometry belongs in there by iterating
over very loop's trimming curves |
| 20:43.40 |
brlcad |
ah, not quite
so |
| 20:48.37 |
brlcad |
not sure what
you meant though -- it fills in a set of "surface trees" during
prep, calling brep_preprocess_trims() to set a few
flags |
| 20:48.49 |
CIA-28 |
BRL-CAD:
03brlcad * r34230
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: remove minor
dead code |
| 20:51.15 |
starseeker |
runs a little test... |
| 20:52.05 |
*** join/#brlcad dreeves2
(n=c752f348@bz.bzflag.bz) |
| 20:58.38 |
CIA-28 |
BRL-CAD:
03brlcad * r34231
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: comment
cleanup |
| 21:09.59 |
starseeker |
yeah, I
thought so - commenting out lines 221 to 239 in brep.cpp inside
brep_preprocess_trims has (so far) resulted in identical raytracing
results for the nurbs_tests.g file (it'll take a little while to
finish) |
| 21:10.17 |
dreeves2 |
brlcad
starseeker I noticed from some of the commits something about the
approximation hack...I wouldn't spend to much time on that in the
end state I want to get rid of that approximation altogether the
getclosestpoint function isn't working is the only reason it is
there I plan attempt to fix that method in opennurbs |
| 21:11.27 |
brlcad |
dreeves2:
*nod*, he just had a stack trace, so it was easily
fixed |
| 21:11.35 |
brlcad |
from a crash,
of course |
| 21:11.54 |
dreeves2 |
sure |
| 21:12.01 |
starseeker |
was able to
see that the d2 model doesn't seem to be trimming
properly |
| 21:12.08 |
dreeves2 |
:) I had up'd
it to 10000 in mine |
| 21:12.17 |
dreeves2 |
I didn't
commit sorry about that |
| 21:12.23 |
starseeker |
np |
| 21:12.56 |
dreeves2 |
Yeah did you
see my comment earlier about dented sphere? |
| 21:13.05 |
starseeker |
nods |
| 21:13.26 |
dreeves2 |
yeah
definitely something screwy going on there not quite sure where the
issue is |
| 21:13.56 |
dreeves2 |
I just had
the bright idea to rt at a different angle the morning no time to
investigate |
| 21:14.35 |
dreeves2 |
You say it
isn't trimming properly...How do you know trimming is the
problem? |
| 21:14.52 |
starseeker |
well, I guess
that's fair - I'm not completely sure |
| 21:15.00 |
dreeves2 |
oh
ok |
| 21:15.05 |
starseeker |
I'll post an
image in a couple minutes |
| 21:15.20 |
CIA-28 |
BRL-CAD:
03brlcad * r34232
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: no need to
undef read/write |
| 21:16.38 |
dreeves2 |
You know you
can turn off trimming by commenting out the call to trim in the
intersect function you will also have to check for odd
intersections in the shoot function and just for now remove the
last intersection otherwise the whole ray will be thrown
away |
| 21:17.30 |
dreeves2 |
Yeah I don't
think trimming is the problem with dented sphere because I was
seeing the problem before trimming |
| 21:18.02 |
starseeker |
http://bzflag.bz/~starseeker/d2.png |
| 21:18.31 |
dreeves2 |
sweet you got
something |
| 21:18.52 |
dreeves2 |
bet if you do
what I was saying you will see far more of the geometry |
| 21:19.05 |
starseeker |
turning off
trimming? |
| 21:19.11 |
dreeves2 |
correct |
| 21:19.11 |
starseeker |
yeah, I think
I have that shot somewhere |
| 21:19.40 |
dreeves2 |
did you make
any progress on speeding up preping? |
| 21:19.42 |
starseeker |
I think this
is without trimming: http://bzflag.bz/~starseeker/openbook_d2.png |
| 21:19.53 |
starseeker |
dreeves2:
sorta, but by hack and slash |
| 21:20.09 |
dreeves2 |
did you do
the odd intersection thing I was talking about? |
| 21:20.18 |
starseeker |
I'll commit
in a second - it's a temporary fix but since that whole part of the
code is funky it won't make much difference |
| 21:23.40 |
CIA-28 |
BRL-CAD:
03starseeker * r34233
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 21:23.40 |
CIA-28 |
BRL-CAD:
Comment out this part of the preprocessing trims prep - it's not
currently being |
| 21:23.40 |
CIA-28 |
BRL-CAD: used
in raytracing as far as I can tell and commenting it out reduces
the |
| 21:23.40 |
CIA-28 |
BRL-CAD:
raytracing time on the OpenBook part d example from >20 minutes
to just over 1 |
| 21:23.40 |
CIA-28 |
BRL-CAD:
minute. |
| 21:24.07 |
starseeker |
that may
allow you to raytrace d2.g in something closer to reasonable
time |
| 21:24.27 |
starseeker |
dreeves2:
"odd intersection?" |
| 21:24.31 |
starseeker |
checks archives |
| 21:27.20 |
dreeves2 |
I can't
remember if I left the code in there commented out but it is in the
shot function just before the check for odd intersections. If a
ray comes back with an odd number of intersection shot will throw
away the whole ray |
| 21:28.21 |
dreeves2 |
you can just
remove the last intersection point for rendering purposes it may be
fine but obviously in the end we can do no such thing but just for
now while we are trying to troubleshoot what is going
on |
| 21:28.41 |
starseeker |
ah |
| 21:30.40 |
dreeves2 |
Then you grab
your left foot then hop 10 times on your right while waving at
someone and you may seem just a little less insane :) |
| 21:31.22 |
starseeker |
starts a raytrace inside mged and goes to get more
water |
| 21:31.27 |
starseeker |
heh |
| 21:32.34 |
starseeker |
I'm getting a
LOT of "root diverged" errors |
| 21:32.50 |
starseeker |
that could
explain a lot, come to think of it |
| 21:33.03 |
starseeker |
getting 'em
for all raytraces - even the box |
| 21:33.55 |
dreeves2 |
Yeah that is
because I'm returning the wrong thing from intersect meant to go
back and look what I was suppose to set that to when I missed but
forgot to that |
| 21:36.14 |
dreeves2 |
I just
grabbed something I'm not actually ever really detecting when the
root diverged right now so I think it is safe to ignore those for
the moment |
| 21:36.49 |
starseeker |
nods |
| 21:36.51 |
dreeves2 |
Yeah btw I'm
not using the trim prep at all |
| 21:37.17 |
dreeves2 |
we will
probably do something different in the end |
| 21:37.23 |
starseeker |
nods |
| 21:37.36 |
starseeker |
in the
meantime, no point in killing our processing times for nada
;-) |
| 21:37.55 |
dreeves2 |
that is
amazing that is what was taking the bulk of the 20 mins |
| 21:40.46 |
dreeves2 |
If we get
everything working smoothly I definitely think there are some ways
that we can prep trimming that will make trimming very
fast |
| 21:41.04 |
dreeves2 |
and it won't
take that long to prep |
| 21:44.54 |
starseeker |
nods |
| 21:47.57 |
dreeves2 |
what ae are
you rt? |
| 21:48.29 |
starseeker |
270
0 |
| 21:50.13 |
starseeker |
there we go:
http://bzflag.bz/~starseeker/d2_270_0.png |
| 21:50.47 |
dreeves2 |
is that with
the odd check essentially disabled? |
| 21:50.52 |
starseeker |
no |
| 21:50.54 |
starseeker |
that's
default |
| 21:51.26 |
starseeker |
is surprised by the large positive result at the bottom -
that should be empty |
| 21:52.08 |
starseeker |
hunts up the odd check |
| 21:52.09 |
dreeves2 |
I don't
follow? |
| 21:53.19 |
dreeves2 |
I'm amazed we
are getting something that looks that good considering the issue I
found this morning |
| 21:53.27 |
starseeker |
heh -
point |
| 21:53.43 |
starseeker |
you're
talking about the hits.erase code? |
| 21:53.56 |
starseeker |
it appears to
be be commented out |
| 21:54.07 |
dreeves2 |
yeah
uncomment that then retry |
| 21:54.11 |
starseeker |
k |
| 21:54.26 |
dreeves2 |
sorry don't
mean to sound bossy |
| 21:54.35 |
starseeker |
np
:-) |
| 21:56.12 |
dreeves2 |
how long is
taking to rt? |
| 21:56.50 |
starseeker |
few minutes
for a small image |
| 21:57.19 |
dreeves2 |
Yeah I guess
I'm not to worried about that right now |
| 21:57.34 |
starseeker |
correct
first, then fast :-) |
| 21:57.43 |
dreeves2 |
amen |
| 21:58.59 |
dreeves2 |
I am happy we
are getting anything that resembles the shape at this point
considering how complex that geometry is very
motivating |
| 21:59.34 |
starseeker |
ah, this may
help |
| 21:59.43 |
dreeves2 |
? |
| 21:59.51 |
starseeker |
with the prep
time down to something halfway managable, nirt can now be
used |
| 22:00.15 |
starseeker |
we can get
entry and exit points for single rays |
| 22:00.32 |
dreeves2 |
absolutely |
| 22:00.48 |
*** join/#brlcad dreeves2
(n=c752f348@bz.bzflag.bz) |
| 22:01.02 |
dreeves2 |
irc:cgi
stinks |
| 22:04.56 |
dreeves2 |
starseeker
I'm heading to the house but the home computer is connected so if
you get more results let me know I'm interested in what you see
with the code uncommented |
| 22:05.10 |
starseeker |
k |
| 22:05.14 |
starseeker |
it's coming
up now |
| 22:05.22 |
starseeker |
some
differences, nothing really spectacular |
| 22:05.42 |
dreeves2 |
ok well I
will focus on the dented sphere |
| 22:05.46 |
starseeker |
nods |
| 22:05.58 |
starseeker |
yes, that's
the place to focus |
| 22:06.10 |
starseeker |
if we can't
get those right openbook is surely out of reach :-) |
| 22:06.22 |
dreeves2 |
nods |
| 23:23.17 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187-24-10-69.3g.claro.net.br) |
| 23:39.40 |
louipc |
ooh nice
pix |
| 23:40.46 |
Ralith |
^ |
| 23:45.18 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:00.51 |
starseeker |
dreeves:
here's the other screenshot with the uncommented code: http://bzflag.bz/~starseeker/d2_270_0_2.png |
| 00:02.10 |
Ralith |
also
nice! |
| 00:18.55 |
CIA-28 |
BRL-CAD:
03indianlarry * r34234 10/brlcad/trunk/src/conv/asc2g.c: renamed
getline() to gettclblock() |
| 00:24.48 |
starseeker |
these are
somewhat interesting: http://bzflag.bz/~starseeker/dented_sphere.png |
| 00:24.58 |
starseeker |
http://bzflag.bz/~starseeker/dented_sph_surf_norm.png |
| 00:27.29 |
Ralith |
that doesn't
look dented so much as holed |
| 00:27.54 |
louipc |
blind
hole |
| 00:28.11 |
louipc |
needs
isometric view |
| 00:28.14 |
starseeker |
It does
appear to represent a removal rather than a surface
distortion |
| 00:31.51 |
starseeker |
the surface
normal coloring, however, should be fairly unambiguous |
| 00:32.27 |
starseeker |
if it were an
outward distortion, I would expect the color gradient to run in the
same general direction as that of the main sphere |
| 00:38.09 |
starseeker |
is beginning to think it might be useful to have the option
to draw more complete wireframes for the nurb primitives,
corresponding to their structure |
| 00:38.37 |
starseeker |
relating a
raytrace to the underlying surfaces, edges, etc just by numbers may
be a bit tricky |
| 00:42.38 |
brlcad |
starseeker:
can you create two spheres that match the dented sphere
perfectly? |
| 00:42.59 |
starseeker |
I can
try |
| 00:43.04 |
starseeker |
one
second |
| 00:44.03 |
brlcad |
would be
interesting to run pixdiff/pixcmp on the results if the original
radii and position values are derivable |
| 00:44.13 |
starseeker |
hmm |
| 00:44.24 |
starseeker |
not easily,
at least from the l output |
| 00:45.05 |
brlcad |
can't believe he owes so much this year |
| 00:45.20 |
starseeker |
winces |
| 00:45.30 |
starseeker |
doing the
late night post office thing? ;-) |
| 00:45.46 |
brlcad |
oh hell no,
stopped that 5/6 years ago |
| 00:45.56 |
starseeker |
online
then? |
| 00:45.59 |
brlcad |
e-file |
| 00:46.02 |
brlcad |
yeah |
| 00:46.03 |
starseeker |
nods |
| 00:46.10 |
starseeker |
that's how I
did it too, except for VA |
| 00:46.23 |
brlcad |
used to do it
all by hand, an all-day event, many forms, all the instructions and
subforms |
| 00:46.54 |
starseeker |
yuck |
| 00:47.00 |
brlcad |
until one
year it got so bad that I worked on them for about 20 hours
non-stop (and I knew what I was doing!) and was still running up
against the deadline |
| 00:47.15 |
starseeker |
dreeves:
fwiw, I can confirm that the rebuilt sphere is manifesting as
holes |
| 00:47.30 |
brlcad |
I had about
two-hours till midnight (blen burnie office was open till
midnight), went on-line |
| 00:47.40 |
brlcad |
did the whole
thing in less than half an hour |
| 00:47.47 |
Ralith |
odamn |
| 00:47.54 |
Ralith |
that must
have been a little frustrating. |
| 00:48.08 |
brlcad |
it was more
amazing |
| 00:48.09 |
Ralith |
after 20
hours of work |
| 00:48.39 |
brlcad |
I was dubious
that it'd be at all right with all the various forms I had
(self-employed, depreciation tables, multiple sources of income,
etc) |
| 00:49.30 |
brlcad |
since it
asked more in a wizard-style interface, asking lots of
questions |
| 00:50.08 |
brlcad |
I was already
95% done on paper, so I actually had everything in front of me to
verify and it all matched up nicely |
| 00:50.16 |
brlcad |
so never
again after that |
| 00:50.40 |
brlcad |
this year was
hell though, even on-line ... for many reasons |
| 00:51.18 |
brlcad |
worst.
tax-year. ever. (for me) |
| 00:52.44 |
brlcad |
orders some comfort food |
| 00:57.17 |
starseeker |
figures new house made things nice and
complex... |
| 00:57.28 |
brlcad |
it
did |
| 00:57.41 |
brlcad |
insanely
so |
| 00:57.53 |
brlcad |
especially
purchasing near the end of the year |
| 00:58.00 |
starseeker |
ow |
| 00:58.08 |
yukonbob |
what about
the cocaine and hookers from your rockstar lifestyle as a BRL-CAD
developer? |
| 00:58.17 |
``Erik |
hehehe |
| 00:58.38 |
starseeker |
would hire a CPA or something rather than deal with the
headache of truly complex taxes... |
| 00:58.46 |
brlcad |
yukonbob:
they're paid under the table, *shhh* |
| 00:58.52 |
yukonbob |
heh |
| 00:58.53 |
``Erik |
yes, we take
private jets when we go out for lunch and all that, and wear
leather pants |
| 00:59.05 |
yukonbob |
LOL leather
pants |
| 00:59.10 |
yukonbob |
hawt |
| 00:59.11 |
yukonbob |
! |
| 00:59.17 |
``Erik |
yes, they
are, a lot of chaffing |
| 00:59.36 |
starseeker |
scowls at rebuilt sphere |
| 01:00.35 |
starseeker |
gonna need
some way to know what we're raytracing within the nurb and how
close it is to any edges/verticies/etc |
| 01:02.34 |
``Erik |
hm, since
opennurbs has a container for a straight up brep surface, ya think
the utah teapot might be a good geometry to experiment
with? |
| 01:02.52 |
starseeker |
could
be |
| 01:03.01 |
``Erik |
iirc, it's
just 16 control points |
| 01:03.51 |
brlcad |
teapot isn't
solid geometry |
| 01:04.04 |
``Erik |
wait, no, 28
patches in the original |
| 01:04.14 |
brlcad |
handling
non-solid ON_Brep objects hasn't been looked into |
| 01:04.40 |
``Erik |
ah, okie, I
figured it might be magically handled in the guts of opennurbs :)
*shrug* |
| 01:05.52 |
starseeker |
this is
probably informative once it can be related to the nurbs surfaces:
http://bzflag.bz/~starseeker/rebuilt_sphere_270_0.png |
| 01:05.59 |
brlcad |
same surface
intersection and trimming logic, but that all has to be handled up
in the shot() routine |
| 01:07.51 |
hippieindamakin8 |
silently observes. |
| 01:08.08 |
starseeker |
it's almost
as if the surfaces are being rendered up to some maximum absolute
x, y or z and then nothing |
| 01:08.08 |
brlcad |
not so silent
:) |
| 01:08.16 |
hippieindamakin8 |
:P |
| 01:09.15 |
starseeker |
will have to take a hard look at how the line renderings are
done and see if edges can be incorporated as an
option |
| 01:09.53 |
starseeker |
if those it
would be helpful to be able to see the makeup of the
surfaces |
| 01:11.00 |
starseeker |
suppose it
can be compared with the complete sphere... |
| 01:11.09 |
starseeker |
alright, I'm
getting out of here :-) |
| 01:11.12 |
starseeker |
bbl |
| 01:29.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 01:37.36 |
dreeves |
starseeker
yes I confirmed last night it was holes. BTW it is entirely
possible to see dark spots with out the slow change in color. I
have seen cases where were on the edge of a surfaces and it
calculates a normal perpendicular to the ray. In order to confirm
it wasn't that I checked every normal and when one was near
perpendicular I reset to reverse the ray direction which will make
the pixel light up they didn't |
| 01:39.34 |
dreeves |
so obviously
it was a hole which really surprised me because I wasn't getting
errors for odd number of hit points. If it missed on the front it
should have hit on the other side and reported errors. I isn't
which means it isn't only missing the front but also the surface
behind it |
| 01:41.23 |
dreeves |
that is what
drove me to rt from different ae when I noticed everything went to
hell in a hand basket pdq. Was some what encouraging though
believe it or not because at least it isn't wasn't a tolerance
problem. Just dealing with something wrong. |
| 01:44.59 |
dreeves |
I don't think
it is anything real serious because obviously we are able to
calculate intersection and appear to that we somewhat understand
the trim geometry. BTW I can turn off trimming and still see the
problem so this isn't trimming doing this. |
| 01:47.35 |
dreeves |
The front
side it is scary because it looks like an edge but I don't think it
is because when I shot from the other angle a lot more was missing
than an edge. IMO something is going on with interpretation of the
geometry that is causing the problem |
| 01:48.03 |
brlcad |
dreeves: note
that the phong shader will automatically flip a backward-facing
normal |
| 01:48.37 |
brlcad |
should see
"shade_inputs(object) flip N ..." messages if it does |
| 01:50.33 |
dreeves |
yeah I new
that was the case but if it is near perpendicular and not
perpendicular or more I was thinking it might not be flipping
that |
| 01:50.59 |
dreeves |
either was it
is definitely a hole |
| 01:51.15 |
brlcad |
yeah, if it's
just "nearly" perpendicular, it'll come back |
| 01:51.37 |
dreeves |
are you
saying it will flip it? |
| 01:51.39 |
brlcad |
BN_VECT_ARE_PERP() is using the default
tolerance |
| 01:51.53 |
brlcad |
if it's
nearly perpendicular, it won't |
| 01:52.03 |
dreeves |
right that
was my thinking |
| 01:53.15 |
dreeves |
The delay in
me working this isn't because I'm struggling I just got busy on the
day job. I'm actually pretty confident we can fix this
pdq |
| 01:53.47 |
dreeves |
I was worried
when I thought it was a tolerance issue but now that I know it
isn't I feel better |
| 01:54.48 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 01:55.37 |
brlcad |
nods |
| 01:55.50 |
brlcad |
there are
plenty of tolerance issues remaining, no worries there
;) |
| 01:58.58 |
dreeves |
nods :) |
| 02:36.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 02:53.33 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 03:30.36 |
*** join/#brlcad madant_
(n=madant@117.196.128.248) |
| 03:39.04 |
PrezKennedy |
wtf |
| 03:46.37 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 03:48.17 |
_pseudony |
/nick
_pseudonym |
| 03:48.59 |
pacman87 |
hmm, seems to
be some bugs/omissions in the ipod touch irc client i'm
trying |
| 03:50.16 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 03:52.25 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 03:54.41 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 03:56.02 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 03:57.07 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 03:57.53 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 03:58.04 |
pacman87 |
sorry about
the join/part spam :( |
| 04:00.00 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 04:01.52 |
*** join/#brlcad pacman_87
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
| 04:03.58 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
| 04:04.08 |
poolio |
Err, did
bzflag get klined? |
| 04:22.22 |
*** join/#brlcad madant
(n=madant@117.196.128.248) |
| 04:28.44 |
PrezKennedy |
looks like
it |
| 04:28.52 |
PrezKennedy |
whole bunch
of you guys got dumped at once |
| 04:38.10 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 05:07.02 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 05:31.51 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 05:38.01 |
*** join/#brlcad madant
(n=d@117.196.148.46) |
| 06:15.20 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 06:41.59 |
dreeves |
so I'm having
compile problems in librt can't find mirror.c?? |
| 06:59.07 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 07:19.25 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
| 07:29.23 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 07:31.00 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 07:40.01 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 07:47.01 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 08:01.28 |
*** join/#brlcad madant
(n=d@117.196.129.235) |
| 08:22.41 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 08:22.45 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 08:45.25 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 09:03.10 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 09:35.39 |
*** join/#brlcad elite01_
(n=omg@unaffiliated/elite01) |
| 09:50.33 |
*** join/#brlcad madant
(n=d@117.196.135.125) |
| 10:10.02 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
| 10:20.43 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
| 11:01.12 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 11:13.43 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 11:13.53 |
d-lo |
mernin
all! |
| 11:19.30 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 11:19.46 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 11:20.10 |
d-lo |
howdy there
brlcad! |
| 11:20.21 |
brlcad |
hellos |
| 11:21.17 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 11:21.45 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 11:22.33 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 11:32.14 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 11:34.09 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:34.22 |
mafm |
hi |
| 11:34.55 |
d-lo |
hai
mafm! |
| 11:35.03 |
brlcad |
d-lo: nice
work commenting on the apps |
| 11:35.20 |
d-lo |
puffs out chest. |
| 11:35.21 |
d-lo |
thanks! |
| 11:35.35 |
brlcad |
if any jumped
out at you over the one that you're assigned to, mentors can still
be swapped around |
| 11:35.55 |
brlcad |
technical
mentoring is still group-based, but the mentor assigned does much
of the logistic tracking |
| 11:36.42 |
d-lo |
I was
actually thinking about the GUI project.... might be a better fit
for me. If starseeker doesn't care of course. |
| 11:37.16 |
brlcad |
everyone
wants the gui :) |
| 11:37.46 |
d-lo |
I don't think
i could provide the proper level of mentoring for libpc,
revolve/sweep, or BREP. |
| 11:39.27 |
brlcad |
remember that
it's not so much the technical side, it's just being able to keep
track of how much they've done |
| 11:39.31 |
brlcad |
how active
they've been |
| 11:39.42 |
d-lo |
Importers,
sure, but the hardcore math stuff I am not so strong
with. |
| 11:39.48 |
brlcad |
how much of
what they said they were going to do did they actually
finish |
| 11:40.12 |
d-lo |
okay, thats
as much as i figured. Its the 'technical questions' that are sure
to pop up ;) |
| 11:40.26 |
brlcad |
technical
questions belong to the whole team |
| 11:40.37 |
brlcad |
they should
intentionally be out in the open |
| 11:40.43 |
d-lo |
but i suppose
there is a decent support network in place. |
| 11:41.22 |
brlcad |
for example,
there should be no private discussions -- no PMs on IRC to talk
technical issues |
| 11:41.29 |
d-lo |
pffft. look
at this. 'we can still swap mentors around' but when i take him up
on the offer, its 'Noooooooooooooo sir!' ;) |
| 11:41.36 |
brlcad |
should all be
on this channel or on the wiki or on the devel mailing
list |
| 11:41.37 |
d-lo |
j/k |
| 11:42.06 |
brlcad |
nah, that's
possible -- have to talk to cliff |
| 11:42.33 |
brlcad |
libged
connection is why you were added to the one you're on |
| 11:42.46 |
brlcad |
since that
relates to the GS a bit |
| 11:42.52 |
d-lo |
its all good.
I am happy where I am at. |
| 11:42.53 |
brlcad |
but the gui
has a similar connection |
| 11:43.11 |
d-lo |
can't shy
away from new things *too* much |
| 11:43.13 |
brlcad |
and more
importantly, gui should be using GS directly |
| 11:43.39 |
brlcad |
just I don't
expect it'll actually get that far over the summer |
| 11:43.54 |
d-lo |
well now, i
just might have to crack the whip a bit ;) |
| 11:43.58 |
brlcad |
would rather
see the gui get to a solid framework state with no/little backend
support |
| 11:44.07 |
brlcad |
have it look
good |
| 11:44.12 |
d-lo |
'what the
'ell is Google payin ya for boy?!' :) |
| 11:44.34 |
d-lo |
agreed |
| 11:45.42 |
d-lo |
is there
anyway to make Saunders wire in the gui to the existing build
system vice cmake ? |
| 11:46.57 |
brlcad |
how
so? |
| 11:47.15 |
brlcad |
it alread is
using cmake |
| 11:47.24 |
d-lo |
haven't
looked at it in a while, but doesn't the the new gui, g3d, or
whatever its called use cmake? |
| 11:47.39 |
mafm |
yes, it
is |
| 11:47.52 |
d-lo |
points to mafm. There he is! |
| 11:47.56 |
brlcad |
it works
similar to the gs -- you build and install brl-cad, then it builds
against the brl-cad libs in cmake |
| 11:48.30 |
d-lo |
just
wondering if it would be cleaner to keep the build systems uniform,
thats all. pros/cons? |
| 11:48.38 |
brlcad |
he actually
updated it to use our pkg-config files too, so it finds the deps to
link against nicely |
| 11:48.48 |
mafm |
I just didn't
understand the Saunders, wire and vice words in your phrase
:D |
| 11:49.17 |
brlcad |
d-lo: lemme
know when you're done converting all of the main module build to
cmake and we can talk about integration :) |
| 11:49.54 |
brlcad |
otherwise it
could be an autotools based project, but we'd picked cmake because
it's generally better for new code |
| 11:50.52 |
d-lo |
ah, kk. So
would it be 'better' to make rt^3 build via cmake since its
techically all 'newer' code? |
| 11:51.09 |
brlcad |
yeah |
| 11:51.43 |
d-lo |
strokes his chin. Hrm.... |
| 11:51.58 |
mafm |
isn't it
yet? |
| 11:52.11 |
brlcad |
rt^3's build
predates cmake being useful so it was mirrored off the main
module |
| 11:52.23 |
mafm |
ops
:) |
| 11:52.24 |
brlcad |
mafm: not
yet |
| 11:52.54 |
d-lo |
wonders if a convert to cmake, now, would be better, rather
than waiting till rt^3 gets more complex and
cluttered... |
| 11:53.28 |
brlcad |
it
would |
| 11:53.54 |
brlcad |
further it
goes, the more entrenched and less beneficial a move |
| 11:53.57 |
mafm |
coreInterface
is small, shouldn't be much of a problem I guess, if not
already |
| 11:54.28 |
d-lo |
grumbles about just getting this blasted Work computer
working with autotools... |
| 11:54.44 |
mafm |
ogre &
co. in src/other are using their own build systems (but called from
cmake IIRC), I produced cmake for RBGui and Mocha that will be
gone |
| 11:55.08 |
brlcad |
like the main
module -- the cost vs benefit just isnt there for us to convert the
build to cmake because it's so well developed, complete, with lots
of tuned behavior and options that would be very time-consuming to
replicate and retest in cmake |
| 11:55.37 |
d-lo |
nods at brlcad. |
| 11:55.37 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:55.48 |
brlcad |
so autoconf
isn't going away anytime soon :) |
| 11:56.05 |
brlcad |
we'll just
have two |
| 11:56.30 |
d-lo |
two? build
systems? |
| 11:56.34 |
brlcad |
actually
still works rather nicely to have distinctly separate barrier
between the lib layers |
| 11:57.13 |
brlcad |
yeah, two
build systems -- the core (brlcad) and then an overlay
(rt^3) |
| 11:57.33 |
d-lo |
kk, just
making sure I understood what you typed =D |
| 12:00.21 |
d-lo |
as for
rt^3/src/ director structure, i am thinking of doing some
re-organizing. It kinda bugs me that there are several aspects of
the project going on at the same time with little to no
communications and people are putting things wherever they want
(myself included) |
| 12:01.45 |
d-lo |
and if the
rt^3 dividing lines (GUI, GS, GE) are acceptable, I am thinking of
re-org'ing the dirs a bit to represent that. |
| 12:01.45 |
d-lo |
especially if
we end up with multiple GUIs |
| 12:03.03 |
mafm |
ok for me,
svn preserves history and everything, so no big
disadvantages |
| 12:03.59 |
d-lo |
I think
daniel is the only other major worker bee in the rt3 module, so I
might email him/use the devel mailing list. |
| 12:04.15 |
d-lo |
of course, i
might just re-org now and as permission later ;) |
| 12:04.46 |
brlcad |
yeah, those
should definitely be three distinct "products" by themselves with
GS dependent on GE, GUI dependent on GS, all three dependent on
core |
| 12:04.48 |
d-lo |
and thats
just cause I dont know what is 'politically correct' in the OS
world yet :) |
| 12:05.12 |
d-lo |
core ==
common stuff |
| 12:05.14 |
brlcad |
re-org would
be great, but it should be communicated |
| 12:05.15 |
d-lo |
-or- |
| 12:05.22 |
d-lo |
core ==
brlcad module |
| 12:05.25 |
d-lo |
? |
| 12:05.25 |
brlcad |
brlcad
module |
| 12:05.26 |
d-lo |
kk |
| 12:05.58 |
brlcad |
they may have
some common code, classes that are shared -- but I wouldn't plan
for them having shared sublibs just yet |
| 12:06.33 |
brlcad |
as that
common code probably just belongs down with GE if it is
common |
| 12:08.03 |
brlcad |
should e-mail
daniel (or any dev) directly on dev matters, the mailing list
communicates that openly much better |
| 12:08.15 |
brlcad |
it's a pretty
small list, not like the discussion wanders off-topic into
arguments |
| 12:08.33 |
d-lo |
heh, 'down
with GE'.... 80's rap song about General Electric... |
| 12:09.41 |
brlcad |
how about
proposing the overall reorg structure to the list, then work
towards that structure incrementally |
| 12:11.19 |
d-lo |
brlcad:
working on an email right now. I do not think that it will cause
much of a 'wave in the water' to reorg src/ into src/guis/ src/gs/
src/ge src/common and src/other |
| 12:11.31 |
brlcad |
or at least
making the changes incrementally so that if an issue comes up, it's
not mixed in with 100 other reorg changes |
| 12:11.52 |
d-lo |
nods. Understood |
| 12:12.24 |
brlcad |
heh, I
wouldn't plan on multiple guis until we have a distinct
need |
| 12:12.28 |
d-lo |
plus it will
give a good history and allow people to make fun of me when i do
something stupid =D |
| 12:12.36 |
brlcad |
have enough
work ahead to get one working well |
| 12:12.49 |
brlcad |
what is
src/common? |
| 12:13.25 |
d-lo |
place to put
code common to guis/ gs/ and ge/ (if it actually
exists) |
| 12:14.13 |
brlcad |
bikeshed
difference, but src/GUI, src/GS, src/GE (caps) would reflect their
c++ nature well :) |
| 12:14.23 |
d-lo |
i only
thought that src/common might be useful since the guis may not want
to include the entire libge |
| 12:14.29 |
brlcad |
ah, that was
my point earlier -- if it's actually common, it probably belongs in
GE |
| 12:15.56 |
d-lo |
yeah, i was
thinking about that point, and i can't come up with anything that
the GUIs would need that would be in GE... but I suppose we can
work that issue when it arises |
| 12:16.13 |
d-lo |
'if' it comes
up at all. |
| 12:16.19 |
brlcad |
yeah |
| 12:16.25 |
brlcad |
leave it out
until needed |
| 12:16.37 |
d-lo |
you
minimalist you. |
| 12:16.55 |
hippieindamakin8 |
giggles |
| 12:17.10 |
brlcad |
the various
lib dirs in src/lib* were organized that same way you're suggesting
before GE came on the scene |
| 12:17.25 |
brlcad |
those libs
collectively were the start of a GE themselves |
| 12:17.44 |
brlcad |
geometry,
image, network, numeric, raytrace, and utility (common)
services |
| 12:17.50 |
d-lo |
well then,
sounds like an easy mv command or two! |
| 12:18.01 |
d-lo |
;) |
| 12:18.28 |
brlcad |
most
everything daniel's done to date fits under that geometry
category |
| 12:18.53 |
brlcad |
GS picked up
that network category |
| 12:19.08 |
brlcad |
(so ge longer
has it) |
| 12:26.01 |
d-lo |
your words
speak true. I had felt a disturbance in the rt3 module for some
time, but couldn't put my finger on what it was.... |
| 12:26.03 |
brlcad |
it shouldn't
be too hard to get a consensus on the basic layout -- more just an
issue of merging the right things together without losing any of
the invested effort on the old or various new codes that have since
kicked off |
| 12:27.36 |
brlcad |
there's
actually not much duplication as it is, just four people that have
ignored what the previous coder left in place :) |
| 12:28.02 |
d-lo |
are you
refering to lib* dirs? |
| 12:28.42 |
brlcad |
for the first
guy, yeah |
| 12:28.56 |
brlcad |
then the next
guy ignored the lib dirs and what the second guy added |
| 12:29.15 |
brlcad |
then the next
guy ignored the lib dirs, what the second guy added, and the third
guy, ... :) |
| 12:29.22 |
brlcad |
kinda funny,
but classic |
| 12:29.31 |
brlcad |
mostly
because it's a sandbox |
| 12:29.52 |
brlcad |
wasn't a
pressing need to hardline the organization until
recently |
| 12:30.11 |
brlcad |
so time to
refactor! |
| 12:32.07 |
brlcad |
plus the
switch in build systems made it even more tricky to merge them
half-way through |
| 12:32.17 |
brlcad |
and is really
the brunt of the work even now |
| 12:32.54 |
brlcad |
the org
itself isn't complicated or riddled with pitfalls (unless code is
deleted) |
| 12:33.03 |
brlcad |
it's wiring
up the build |
| 13:17.02 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34235
10/rt^3/trunk/include/brlcad/common.h: |
| 13:17.03 |
CIA-28 |
BRL-CAD: an
exception with an error message similar to bu_bomb |
| 13:17.03 |
CIA-28 |
BRL-CAD: The
implementation/return value of std::exception::what() depends on
the |
| 13:17.03 |
CIA-28 |
BRL-CAD:
compiler (it is not in the standard). That's why there is now
a |
| 13:17.03 |
CIA-28 |
BRL-CAD:
BRLCAD::bad_alloc derived from std::bad_alloc which carries a
hopefully useful |
| 13:17.05 |
CIA-28 |
BRL-CAD:
message. |
| 13:20.39 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34236 10/rt^3/trunk/ (20 files in 2 dirs): the core
interface now compiles under Linux too |
| 14:06.32 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 14:09.46 |
CIA-28 |
BRL-CAD:
03davidloman * r34237 10/rt^3/trunk/src/iBME/Makefile.am: Cleanup:
removed a few straggling references to Boost libs |
| 14:13.43 |
*** join/#brlcad madant
(n=d@117.196.150.228) |
| 14:21.28 |
CIA-28 |
BRL-CAD:
03davidloman * r34238 10/rt^3/trunk/src/other/Makefile.am: Cleanup:
removed Makefile.am that referred to outdated/removed 3rd party
libs |
| 14:22.07 |
*** join/#brlcad madant_
(n=d@117.196.137.213) |
| 14:28.30 |
CIA-28 |
BRL-CAD:
03davidloman * r34239 10/rt^3/trunk/ (configure.ac src/other/uuid/
src/uuid/): moved src/uuid to src/other/uuid |
| 14:31.22 |
CIA-28 |
BRL-CAD:
03davidloman * r34240 10/rt^3/trunk/src/ (GUI/ GUIs/): Refactored
GUI to GUIs |
| 14:31.54 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:51.17 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 15:08.08 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 15:08.45 |
*** join/#brlcad samrose
(n=samrose@adsl-76-226-71-255.dsl.sfldmi.sbcglobal.net) |
| 15:09.00 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 15:09.52 |
brlcad |
waves to elena |
| 15:12.05 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 15:14.42 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) |
| 15:16.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 15:17.23 |
PrezKennedy |
waves to brlcad |
| 15:17.31 |
brlcad |
howdy |
| 15:17.35 |
brlcad |
digest all
that meat yet? |
| 15:17.38 |
PrezKennedy |
yeah! |
| 15:17.43 |
PrezKennedy |
finally |
| 15:27.03 |
``Erik |
uh, way
tmi |
| 16:29.51 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 16:31.40 |
jdoliner |
have
selections been announced publicly somewhere? |
| 16:39.04 |
pacman87 |
jdoliner:
official announcement is still the 20th, i believe |
| 16:40.19 |
pacman87 |
although the
topic disagrees with me |
| 17:01.04 |
jdoliner |
yeah, this is
what led to my confusion as well |
| 17:01.09 |
jdoliner |
how many
slots did yu guys get? |
| 17:01.44 |
brlcad |
5 |
| 17:02.15 |
brlcad |
ah right,
topic .. the selections are pretty near final on the 15th, but we
cannot announce until the 20th |
| 17:03.09 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step:
selections are made, they will be announced (by Google) on the
20th |
| 17:19.39 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
| 17:20.20 |
brlcad |
howdy
poolio |
| 17:20.37 |
poolio |
ahoy! |
| 17:21.11 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 17:21.40 |
hippieindamakin8 |
hey brlcad ,
pacman87 |
| 17:21.51 |
brlcad |
poolio: how
goes the semester? |
| 17:21.58 |
brlcad |
howdy
hippieindamakin8 |
| 17:22.08 |
poolio |
I just was
catching up on e-mail... are the mentor-student assignments all
worked out? |
| 17:22.16 |
brlcad |
yeah |
| 17:22.32 |
brlcad |
unless you
want an assignment, you're welcome to one |
| 17:22.42 |
brlcad |
really shouldn't be assigned, for example |
| 17:22.53 |
poolio |
brlcad: it's
been good, but insanely busy. working two jobs and 7 classes
:) |
| 17:24.46 |
poolio |
hmm, well it
looks like the only project I could possibly be helpful on is the
BREP on BREP one, and it looks like there's already someone who is
not you on that. I'll definitely be idling around here over the
summer and try to provide as much help as I can, maybe even finish
up on some of that CSG -> BREP stuff now that I get
it |
| 17:26.16 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
| 17:26.19 |
brlcad |
poolio: the
assigned mentors are more for logistic tracking, not technical
guidance -- technical is group-shared so you can help out with that
one regardless |
| 17:26.39 |
brlcad |
also,
selections aren't announced, so hush on the projects :) |
| 17:26.43 |
brlcad |
bah |
| 17:26.47 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
| 17:27.01 |
poolio |
will
do |
| 17:27.19 |
brlcad |
also,
selections aren't announced, so hush on the projects ..
:) |
| 17:29.31 |
poolio |
oopsy daisy.
sorry bout that... what I meant to say was if such a project were
accepted into GSOC then ... |
| 17:29.46 |
brlcad |
heh |
| 17:30.35 |
brlcad |
it's okay, if
folks were closely paying attention, it's pretty clear who at least
4 of the 5 are |
| 17:31.13 |
brlcad |
at least ..
"in all likelihood" |
| 17:31.39 |
elena |
;) |
| 17:34.18 |
brlcad |
hm, I suppose
our project priorities ( http://brlcad.org/BRL-CAD_Priorities.png
) conceivably narrows in a little too |
| 17:34.27 |
brlcad |
though there
are a couple outliers, hm, maybe not |
| 17:35.42 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@189-92-135-182.3g.claro.net.br) |
| 18:36.21 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) |
| 18:36.51 |
*** join/#brlcad samrose
(n=samrose@ip-207-145-38-45.iad.megapath.net) |
| 18:42.25 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:06.03 |
dreeves |
brlcad and
starseeker shoot the dented sphere from the side with trimming
definitely not dented |
| 19:06.35 |
dreeves |
So maybe
there still is some issues with trimming |
| 19:30.08 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-243-9.dclient.hispeed.ch) |
| 19:49.33 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 19:53.51 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 20:03.11 |
*** join/#brlcad andax
(n=andax__@d213-102-40-135.cust.tele2.ch) |
| 20:05.35 |
CIA-28 |
BRL-CAD:
03bob1961 * r34241 10/brlcad/trunk/src/ (3 files in 2 dirs):
Updates related to Archer's view-only mode. |
| 20:16.07 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 20:47.23 |
jonored_ |
...Well, I
can get the principal curvatures for a point on a nurbs surface,
but not the associated direction yet... |
| 21:04.38 |
*** join/#brlcad Don_
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 21:15.07 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 22:28.44 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
| 22:32.47 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 23:23.43 |
*** join/#brlcad Don__
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 23:55.24 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FF0E.dip.t-dialin.net) |
| 00:58.28 |
*** join/#brlcad jonored
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 01:01.59 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 01:02.21 |
``Erik |
bakes dinner and watches futurama |
| 01:30.56 |
yukonbob |
afternoon,
cadheads |
| 01:41.17 |
jonored |
finds the implementation of what he just derived in amongst
the openNURBS code, and facepalms. |
| 01:59.07 |
*** join/#brlcad AlexandreGuedes
(n=chatzill@187-24-8-17.3g.claro.net.br) |
| 02:11.55 |
*** join/#brlcad AlexandreGuedes_
(n=chatzill@189-92-173-170.3g.claro.net.br) |
| 02:54.07 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 02:54.07 |
*** join/#brlcad MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 02:54.07 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 02:54.07 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:56.14 |
brlcad |
jonored:
hehe |
| 03:01.26 |
brlcad |
though have
to actually look at the implementation -- some functions they
define (and have implemented in their commercial API product), but
don't actually have an implementation |
| 03:07.59 |
jonored |
The
implementation looks about like what I was headed at. |
| 03:12.39 |
brlcad |
cool |
| 03:13.03 |
brlcad |
that's
frustrating but also releiving to find things like that |
| 03:13.24 |
brlcad |
like working
through a hard math problem, only to realize it's in the answer key
in the back and you got it right |
| 03:13.32 |
jonored |
ON_EvPrincipalCurvatures in
opennurbs_math.cpp - it looks plausible that it's doing what it
should, I haven't checked for exact equivalence but it would be
surprising. |
| 03:14.28 |
jonored |
I've gotten a
chunk more of an idea how to approach issues of applied
differential geometry, at least :) |
| 03:14.47 |
jonored |
(er, would be
surprising to have that much and not doing its job.) |
| 03:35.16 |
``Erik |
yowza, both
daily show and colbert report are on a roll concerning the
"teabaggers" |
| 03:47.17 |
*** join/#brlcad CIA-28 (n=CIA@208.69.182.149.simpli.biz)
[NETSPLIT VICTIM] |
| 05:46.46 |
*** join/#brlcad jonored_
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 06:14.22 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 06:29.03 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 06:29.03 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 06:29.03 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 06:29.03 |
*** mode/#brlcad [+o brlcad] by
irc.freenode.net |
| 06:53.45 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 07:21.22 |
Ralith |
Sir
Morrison |
| 07:21.23 |
Ralith |
hehe |
| 07:26.37 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 07:39.10 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 07:42.29 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 08:26.32 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 08:27.24 |
_pseudo |
irc on my
ipod! |
| 08:27.42 |
pacman87 |
^^ that's me,
btw |
| 08:28.47 |
*** join/#brlcad _pseudo_
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 08:30.16 |
_pseudo_ |
unstable app
+ unstable wireless |
| 08:32.21 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 08:37.36 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 08:40.25 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 09:08.33 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 09:13.11 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 09:14.11 |
pacman87 |
ssh + screen
+ irssi would be a much better solution |
| 09:16.26 |
archivist |
unstable
wireless should be killed at birth |
| 10:24.33 |
d-lo |
yawns. |
| 10:24.39 |
d-lo |
Morning
all! |
| 10:36.17 |
*** join/#brlcad _clock__
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 10:43.06 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:11.55 |
d-lo |
hahahaha:
http://www.rpgjunction.com/verizon_cheque.jpg-48.html |
| 11:45.58 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:48.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 11:51.54 |
brlcad |
a check for
0.002, funny |
| 11:56.06 |
archivist |
I like the
cursor magnifier on that page |
| 12:26.44 |
brlcad |
good
answer |
| 12:26.47 |
brlcad |
(dave) |
| 12:29.07 |
d-lo |
still trying
to get the hang of this Politically Correct talk ;) But
thanks. |
| 12:38.10 |
``Erik |
allows js for that page... yes, a reasonably neat
trick |
| 12:39.02 |
``Erik |
wait, isn't
randall monroe the guy who does xkcd? |
| 12:39.56 |
d-lo |
sure looks
like it. |
| 12:40.12 |
archivist |
a google sez
yes |
| 12:45.17 |
d-lo |
``Erik: how
many astros you got now? 15 |
| 12:48.18 |
hippieindamakin8 |
pacman87,
some of the people i know run irssi on this small device called
pogoplug using ssh+screen |
| 12:48.27 |
``Erik |
15 on epsi, 9
on fenix |
| 12:48.47 |
``Erik |
my two new
epsi astros are throwing up pringles and have no spaceports and
eco's in the 70's |
| 12:48.56 |
``Erik |
plus a few
dn's and some ft cloud over them |
| 12:49.10 |
``Erik |
NOT
profitable targets :D |
| 12:49.37 |
d-lo |
niceness. |
| 12:50.09 |
``Erik |
this exercise
needs to happen, I have two planets with empty production queues
that can churn out levis |
| 12:50.13 |
d-lo |
was poking
around on the epsi site last night and saw your 4K econ. Nice
:) |
| 12:50.25 |
d-lo |
what
excersize? |
| 12:50.39 |
``Erik |
um, the big
gathering in 81 to go jack with anti |
| 12:51.13 |
``Erik |
after thte
slz crash, we got a nap with just about every 'superpower' we're
not friends with heh, but anti has been hitting the newbs left and
right |
| 12:51.15 |
d-lo |
only been
back in the saddle for 2 days now. :) |
| 12:54.09 |
d-lo |
when is the
81ex going to launch? |
| 13:05.37 |
brlcad |
so what level
are you two up to? |
| 13:05.58 |
d-lo |
as in player
level? 54 i think. |
| 13:06.59 |
d-lo |
brlcad: you
still playing? |
| 13:07.09 |
brlcad |
sorta |
| 13:07.24 |
brlcad |
i keep it
going, slowly build up |
| 13:08.15 |
d-lo |
cool. I got
the impression that you quit out of bordom |
| 13:08.52 |
brlcad |
pretty well
fortified now, fewer and fewer pot shots |
| 13:09.19 |
d-lo |
guildless
still working out for ya I see :) |
| 13:09.25 |
brlcad |
pretty
well |
| 13:09.42 |
brlcad |
and a few
guilds that protect me |
| 13:14.01 |
d-lo |
... how is
the ogre library in rt^3 compiled? I don't see how.... |
| 13:16.41 |
d-lo |
nm |
| 13:22.59 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 13:24.08 |
``Erik |
pixie
dust |
| 13:24.21 |
d-lo |
just about
:) |
| 13:24.22 |
``Erik |
I've scrapped
some big fleet in gate crashes, so I'm down to 50ish |
| 13:25.28 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 13:25.33 |
``Erik |
the game has
become more of a combination of espionage against a possible future
competitor and establishing a network of friends to sucker into
seeding a new userbase for me |
| 13:25.35 |
``Erik |
O:-) |
| 13:25.39 |
``Erik |
practices his evil laugh some |
| 13:25.45 |
starseeker |
jeez that was
weird |
| 13:25.56 |
starseeker |
has apparently been knocked off for 2 days |
| 13:26.17 |
starseeker |
mutter... |
| 13:26.23 |
starseeker |
where do we
stash the archives again? |
| 13:27.04 |
``Erik |
archives of
what? |
| 13:27.09 |
starseeker |
irc
chats |
| 13:27.51 |
``Erik |
google tells
me http://ibot.rikers.org/%23brlcad/ |
| 13:28.27 |
d-lo |
``Erik: are
you saying that you have started work on your game? |
| 13:28.29 |
starseeker |
scowls at google for not telling him that |
| 13:28.56 |
``Erik |
planning,
coding toy apps to verify knowledge |
| 13:29.07 |
starseeker |
bookmarks it this time |
| 13:37.23 |
starseeker |
glares at the cat, who is mistaking the living room for a
race track |
| 13:37.46 |
d-lo |
better a
racetrack than a litterbox! |
| 13:39.09 |
madant |
~help |
| 13:39.14 |
``Erik |
give it a
potato http://www.youtube.com/swf/l.swf?video_id=nkHBuh21AMg |
| 13:40.23 |
archivist |
heh on the
same trak as me ``Erik I just been watching that kitteh |
| 13:40.48 |
``Erik |
in ur
intarwebz, steelin' ur branewavez |
| 13:42.20 |
brlcad |
~logs |
| 13:42.21 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 13:52.32 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:53.38 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:18.15 |
*** join/#brlcad dreeves_
(n=IceChat7@64.178.177.71) |
| 14:23.09 |
*** join/#brlcad madant_
(n=d@117.196.132.27) |
| 14:27.50 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 14:29.52 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FE95.dip.t-dialin.net) |
| 14:44.57 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 15:09.40 |
d-lo |
d_rossberg:
are you around? |
| 15:14.04 |
*** join/#brlcad dreeves3
(n=dreeves@64.178.177.71) |
| 15:22.31 |
d_rossberg |
d-lo:
partial, i'm writing a reply to your brlcad-devel mail |
| 15:22.45 |
d-lo |
kk, thats
what I was going to ask about :) |
| 16:18.16 |
brlcad |
responds, open to talk here or list in
follow-up |
| 16:18.56 |
brlcad |
sounds like
there's a disconnect about what the goals of the GS actually
are |
| 16:27.07 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 16:29.13 |
d_rossberg |
brlcad: i
looked at the GE header files in rt^3, they are different from what
i did |
| 16:29.35 |
d_rossberg |
they have
even few in common from what i did in the core interfac |
| 16:31.34 |
d_rossberg |
maybe GE
should be defined more precisely before this can be decided
finally |
| 16:31.54 |
d_rossberg |
(this was the
conclusion of 1)) |
| 16:33.16 |
brlcad |
d_rossberg:
that GE files are very much a work-in-progress -- several of the
classes there belong over in the GS, not the GE, for
example |
| 16:33.37 |
d_rossberg |
this could be
the point |
| 16:33.45 |
brlcad |
all that is
left is a few geometry object classes |
| 16:33.55 |
brlcad |
and that
overlaps very much with what you've done |
| 16:34.13 |
brlcad |
your classes
are more in-line with the direction it still needs to go
regardless |
| 16:34.23 |
d_rossberg |
and many of
them are already in work (the object classes) |
| 16:34.36 |
brlcad |
you mean in
core? |
| 16:36.41 |
d_rossberg |
the cone,
torus etc. (8 pieces) are currently in work for the core
interface |
| 16:37.14 |
brlcad |
much of what
is presently in the GE dir was worked out primarily as a means to
sort out what the GS needed to accomplish its task, some stubbed,
some that needed to be in GS but was put into GE, it's not actually
all been "sorted out" -- the emphasis was on the GS |
| 16:37.44 |
brlcad |
so it can
(and necessarily will) change, quite a bit |
| 16:38.13 |
brlcad |
from a design
goal perspective, though, what was done in jbrlcad and what you've
done in core are what GE is supposed to envelop |
| 16:38.49 |
d_rossberg |
you see, if i
look at what i have (brlcad wiki, sources in rt^3) i have to come
to the conclusion GE != coreInterface |
| 16:39.03 |
d_rossberg |
therefore i
will wait for the changes |
| 16:39.34 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 16:39.49 |
d_rossberg |
e.g. dave may
show how he would like to see the coreInterface integrated into his
concept of a GE |
| 16:40.39 |
d_rossberg |
on the other
side, his top-down approach wasn't so bad |
| 16:41.29 |
d_rossberg |
my impression
was, the the GE is a concept of how a CAD interface should look
like |
| 16:42.06 |
d_rossberg |
then we may
see how this concept can be realised with help of the core
interface |
| 16:42.24 |
brlcad |
yeah, I think
that's the biggest difference |
| 16:42.35 |
brlcad |
you were
coming at it bottom-up, he was top-down |
| 16:43.07 |
brlcad |
your
experience with LIBRT greatly influenced the bottom-up (and is
probably why I like it so much) |
| 16:43.17 |
brlcad |
his top-down
was mostly driven by GS requirements |
| 16:43.52 |
brlcad |
there's a
middle ground in there somewhere I'm sure, and it's closer to LIBRT
than it is to the GS.. |
| 16:45.25 |
d_rossberg |
is away (for some minutes) |
| 16:45.42 |
brlcad |
I would like
to (very LONG-term) end up with an API similar to
Geomis/ACIS/Solidworks, etc, but not so much mirroring their API as
using our libs and requirements and building up an API that allows
apps to be written that utilize the GE (for writing viewers, CAD
modelers, visualization apps, etc) |
| 16:45.58 |
brlcad |
too, must clean house |
| 17:13.04 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 17:46.53 |
``Erik |
clean mine
while you're at it |
| 17:54.05 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 18:15.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 18:38.23 |
*** join/#brlcad dreeves3
(n=dreeves@64.178.177.71) |
| 18:53.15 |
``Erik |
http://www.netzgesta.de/sphere/
heh, noscript makes it look pretty stupid though :) |
| 18:54.25 |
``Erik |
I do like
that it has a fake "guru meditation" window that the js hides,
that's nifty |
| 18:55.17 |
``Erik |
eck, license
suckage, though |
| 18:55.28 |
d-lo |
yeah saw
that. |
| 18:55.39 |
d-lo |
but hey, hack
hac hack. |
| 18:57.22 |
``Erik |
hm,
'onmousemove' is nifty, it's vrry fast on osX ff |
| 19:05.21 |
d-lo |
``Erik: email
sent! |
| 19:06.28 |
``Erik |
w00t |
| 19:08.43 |
B_wooster |
is sorry for the spam |
| 19:21.54 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:58.13 |
``Erik |
has another lowhanging fruit idea for people new to BRL-CAD
development and looking for a tiny project |
| 19:58.46 |
``Erik |
opendb -r
myfile.g for forcing a read-only open (even if the file
permissions allow write) |
| 19:59.44 |
``Erik |
(and a
read-only checkbox in the db open dialog) |
| 20:09.13 |
jonored_ |
Is there
somewhere I can grab a nurbs object to test this with? I can't seem
to find the .g files for the test cases shown at http://brlcad.org/wiki/BREP_Primitive
and would like to see whether I'm getting plausible curvatures
out... |
| 20:27.24 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 20:28.24 |
*** join/#brlcad dreeves3
(n=dreeves@64.178.177.71) |
| 20:52.18 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 20:56.18 |
dreeves3 |
jonored hang
on I will tell you where you can get the .g file |
| 20:57.20 |
dreeves3 |
http://bzflag.bz/~starseeker/nurbs_test.g |
| 20:57.30 |
dreeves3 |
jonored_^^^^^ |
| 20:58.07 |
dreeves3 |
open nurbs is
giving good curvatures....What are you working on? |
| 21:00.40 |
brlcad |
notes that should be http://bzflag.bz/~starseeker/nurbs_tests.g |
| 21:02.18 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r1418
10/wiki/BREP_Primitive: /* Current Images of test cases */ link to
the test geometry |
| 21:06.41 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 21:18.11 |
*** join/#brlcad redvsblue
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) |
| 21:25.20 |
jonored_ |
dreeves2: Oh,
did you already get rt_brep_curve done and just not have it in the
repo? |
| 21:26.49 |
brlcad |
I think he
just meant in general |
| 21:27.03 |
brlcad |
curve() and
norm() are still unimplemented afaik |
| 21:32.15 |
jonored_ |
Actually, I'm
pretty sure that the proper implementation of norm given the
current implementation of shot /is/ an empty method. It looks (at
least to me) that shot is filling it in already. |
| 21:32.44 |
brlcad |
shot does a
guess based on the hit point and ray direction if the primitive did
nothing |
| 21:32.53 |
brlcad |
if that's the
right answer, the primitive should still do that work |
| 21:38.02 |
jonored_ |
I mean that
rt_brep_shot is setting hit_normal already - looks to me like it's
getting the information as part of finding the point anyhow, so
might as well keep it. |
| 22:04.15 |
brlcad |
hmm |
| 22:04.22 |
Ralith |
afternoon
all |
| 22:04.28 |
Ralith |
how goes,
jonored_? |
| 22:08.23 |
jonored_ |
Not bad.
Heading out soon, though. |
| 22:08.40 |
starseeker |
ooo -
http://www.fabathome.org/wiki/index.php?title=Fab@Home:Model_1_Bill_of_Materials#Full_System_CAD_Files |
| 22:10.05 |
brlcad |
starseeker:
heh, interesting find |
| 22:10.30 |
starseeker |
adds it to his archive of open cad goodies |
| 22:10.49 |
starseeker |
will need to
get ahold of a working Solidworks to properly convert it
though |
| 22:10.54 |
brlcad |
good set of
test cases if someone works on the sldprt converter |
| 22:11.18 |
brlcad |
ah, they
provide conversions already too |
| 22:11.35 |
brlcad |
for at least
one of them |
| 22:12.12 |
starseeker |
nods |
| 22:12.21 |
starseeker |
I don't think
that's the full model though |
| 22:14.05 |
brlcad |
wonders if starseeker would rather be mentoring a certain
(unmentionable until the 20th) applicant that is presently assigned
to me given his interest |
| 22:14.12 |
starseeker |
the source
code seems to be BSD licensed - not sure if that applies to the
models... |
| 22:14.15 |
starseeker |
checks |
| 22:14.32 |
starseeker |
ah |
| 22:14.44 |
brlcad |
kinda right
up your alley :) |
| 22:14.44 |
starseeker |
yeah, that
might work |
| 22:15.05 |
brlcad |
related to GS
priority too |
| 22:15.17 |
brlcad |
(loosely) |
| 22:15.19 |
starseeker |
is just a sucker for nice purty screenshots of sophisticated
models in BRL-CAD ;-) |
| 22:15.46 |
starseeker |
not to
mention the test case angle |
| 22:16.24 |
Ralith |
pretty
pictures are always great fun. |
| 22:16.36 |
brlcad |
I think it
would be awesome if you could just upload an unspecified file to a
site and have it give you a sheet of information about it --
objects in the file, types, conversions to other formats, various
automatic renderings |
| 22:16.55 |
Ralith |
mightn't that
be a pretty big CPU load? |
| 22:17.02 |
Ralith |
I suppose
heavy use of nice would render that moot |
| 22:17.02 |
brlcad |
so queue it
up |
| 22:17.21 |
Ralith |
I'd just be
concerned about scalability if it got popular |
| 22:17.30 |
starseeker |
brlcad: that
only works for non-commercial formats though |
| 22:17.40 |
Ralith |
not hard to
distribute, though. |
| 22:17.40 |
starseeker |
proe/solidworks/etc. are a
no-go |
| 22:17.47 |
brlcad |
starseeker:
not necessarily |
| 22:17.51 |
starseeker |
blinks |
| 22:17.52 |
brlcad |
exporting
sure |
| 22:17.56 |
Ralith |
starseeker:
why? patents? |
| 22:17.56 |
brlcad |
but not
importing |
| 22:18.06 |
brlcad |
that's just
up to our ability to read/write them |
| 22:18.06 |
starseeker |
Ralith: file
format parsing |
| 22:18.08 |
jonored_ |
Would look
kind of like thingiverse.com but doing more? |
| 22:18.20 |
brlcad |
sldprt is a
published spec iirc -- that's why it's on my list |
| 22:18.31 |
starseeker |
oh -
solidworks part? |
| 22:18.33 |
brlcad |
sltprt/sldasm
files are like iges |
| 22:18.51 |
brlcad |
complex
support but easily parsed |
| 22:18.56 |
starseeker |
nods |
| 22:19.09 |
brlcad |
someone
motivated could probably whip something up in a really short amount
of time |
| 22:19.15 |
starseeker |
I was sure
Pro-E was a non-starter though? |
| 22:19.44 |
brlcad |
jonored_:
interesting, hadn't heard of them |
| 22:20.17 |
brlcad |
depends -- it
is possible, but it'd take more development effort |
| 22:20.28 |
starseeker |
(actually,
can't take credit for finding the fab@home models - emailed and
asked ;-) |
| 22:20.37 |
brlcad |
the converter
we have wasn't made to be stand-alone -- it was made to be a pro/e
plugin |
| 22:20.56 |
starseeker |
right |
| 22:20.57 |
brlcad |
but the
unigraphics converter, for example, was similarly designed but is
stand-alone |
| 22:21.23 |
starseeker |
either way
though, I'd have thought licensing restrictions would put the
kabosh on wholesale conversions like that |
| 22:21.30 |
brlcad |
their
libraries allow linkage and redistribution after you go through
some horribly absurd locking/unlocking process |
| 22:21.51 |
starseeker |
blinks |
| 22:22.36 |
brlcad |
it's a lot
easier to explain by going through the process but basically (at
least for unigraphics/nx) you link up your exporter against their
libraries and it works just fine for your licensed
system |
| 22:22.42 |
brlcad |
but it won't
work anywhere else |
| 22:22.52 |
starseeker |
ah |
| 22:22.58 |
brlcad |
then there's
another "unlock" step that you apply to your binary |
| 22:23.15 |
brlcad |
takes about a
half-hour (and has nothing to do with cpu time) |
| 22:23.26 |
brlcad |
then that
binary will work anywhere |
| 22:23.37 |
starseeker |
interesting |
| 22:23.54 |
brlcad |
that's how we
used to distribute it .. and one we should get around to updating
and getting working again next time someone needs to poke
NX |
| 22:26.25 |
brlcad |
jonored_:
yeah, looks sort of similar to thingiverse but little more focus on
the models and model data itself and less/no focus on what it's
used for |
| 22:30.14 |
brlcad |
wonders if that is a rails app |
| 22:32.16 |
jonored_ |
doesn't know how they've got that set up, but it's associated
with the reprap crowd. |
| 22:32.28 |
brlcad |
nods |
| 22:32.52 |
brlcad |
understandable, strong focus on rapid
prototyping and machining |
| 22:33.08 |
brlcad |
cool,
http://www.thingiverse.com/thing:249 |
| 22:33.42 |
Ralith |
yeah, it's
zach's |
| 22:34.30 |
starseeker |
hmm -
stl |
| 22:34.47 |
Ralith |
everything
reprap is stl right now. |
| 22:34.52 |
Ralith |
kind of a
shame |
| 22:35.20 |
Ralith |
in fact, it
was reprap and the horrid lack of good CAD free tools that got me
into CAD in the first place |
| 22:35.27 |
brlcad |
starseeker:
if you've not seen this .. contains most of the classics: http://www.lodbook.com/models/ |
| 22:36.06 |
starseeker |
oo -
thanks |
| 22:36.18 |
starseeker |
I'd see the
stanford site with their models |
| 22:36.34 |
Ralith |
stanford
seems to have a lot of small statuettes. |
| 22:36.40 |
brlcad |
yeah, but
they also link to a bunch of other entire repositories of
models |
| 22:37.14 |
brlcad |
Ralith: they
are one of the main powerhouses that kicked off most of the
research on converting laser-scan data into 3D models |
| 22:37.24 |
Ralith |
cool |
| 22:38.09 |
brlcad |
you can't go
to siggraph without seeing a stanford bunny at least .. a few
times |
| 22:38.25 |
starseeker |
hmm... not to
many that sound like they're really "open source" |
| 22:38.30 |
Ralith |
yeah, I"ve
seen that around |
| 22:39.09 |
starseeker |
's favorite visual from last year was a plastic bunny getting
squeezed out of a press :-) |
| 22:39.38 |
hippieindamakin8 |
brlcad, woah
... |
| 22:39.42 |
brlcad |
I'd like our
model repository to specifically cater to unrestricted use copyleft
style |
| 22:39.56 |
starseeker |
would suggest we require it |
| 22:39.56 |
Ralith |
is someone
applying to do that? |
| 22:40.09 |
brlcad |
starseeker:
absolutely -- it's just "how far" |
| 22:40.16 |
starseeker |
ah, good
poing |
| 22:40.17 |
starseeker |
er
point |
| 22:40.31 |
starseeker |
do my
bidding, fingers! |
| 22:40.51 |
brlcad |
e.g. whether
to allow free for any use whatsover, exept commercial use, style
licenses |
| 22:41.01 |
brlcad |
as that is
most of the academic models |
| 22:41.18 |
starseeker |
those are
annoying, but quite common |
| 22:41.31 |
starseeker |
I would say
have a distinct, non-commercial section |
| 22:41.34 |
starseeker |
make it clear
up front |
| 22:42.12 |
Ralith |
that seems to
invite the creation of all sorts of sections for various
licenses |
| 22:42.20 |
Ralith |
not a very
clear place to draw a line. |
| 22:42.25 |
starseeker |
Ralith: no,
not really |
| 22:42.38 |
starseeker |
some sort of
filtered search is the general solution |
| 22:42.55 |
Ralith |
why not just
prominently display the license for each model, and leave it nice
and general? |
| 22:42.58 |
starseeker |
but the
commercial/non-commercial use distinction is pretty
common |
| 22:42.59 |
brlcad |
on the other
extreme, whether to allow something akin to a "GPL" licensed model,
or limit it only to LGPL/BSD/MIT/BY/BY-SA style
licenses |
| 22:43.27 |
starseeker |
isn't even sure what GPL/LGPL really mean for CAD
models |
| 22:43.47 |
brlcad |
Ralith:
mostly to avoid the problem of things like CGAL where all the best
stuff is untouchable, and you have to hunt individually |
| 22:44.08 |
Ralith |
wouldn't a
flexible search system as is par for the course these days
suffice? |
| 22:44.15 |
brlcad |
starseeker:
the spirit of those license, there are "CC equivalents" to
GPL |
| 22:44.24 |
starseeker |
no, you don't
want to parade the non-commercial stuff |
| 22:44.36 |
starseeker |
make it
available, but encourage the totally free licenses |
| 22:44.47 |
Ralith |
I suppose
isolating it would encourage people to license their stuff
otherwise |
| 22:44.52 |
brlcad |
Ralith:
possibly, but still can end up with the issue of having all the
best stuff be untouchable |
| 22:45.07 |
starseeker |
exactly |
| 22:45.33 |
Ralith |
hadn't
considered that many models probably won't already have a license
associated |
| 22:45.48 |
brlcad |
specifically
towards being a repository of freely unencumbered models that I
know I can use |
| 22:45.51 |
Ralith |
(thus
requiring the author to choose one in the context we
present) |
| 22:45.51 |
starseeker |
open source
CAD models are pretty rare |
| 22:46.03 |
brlcad |
exceptionally
rare |
| 22:46.12 |
Ralith |
here's to
hoping we can change that. |
| 22:46.18 |
starseeker |
so the time
to start a trend is now :-) |
| 22:46.21 |
Ralith |
^^ |
| 22:46.42 |
starseeker |
if a good
body of freely available (commercial and non-commercial) models can
be created and get most of the attention, that builds a
momentum |
| 22:47.18 |
Ralith |
good PR for
brl-cad itself, too. |
| 22:47.19 |
hippieindamakin8 |
ex: the model
of the bussard reactor core |
| 22:47.23 |
starseeker |
sort of the
way the FSF built up the GPL - if OpenSolaris had appeared just
when the GPL was getting started, the world would probably look
rather different now |
| 22:48.21 |
Ralith |
hippieindamakin8: got a link for
that? |
| 22:48.23 |
Ralith |
is curious |
| 22:48.38 |
brlcad |
also to be
clear, really don't want to get into the business of how people
license their works -- just want the scope of the repository to be
a well-defined useful resource -- "open source" CAD
models |
| 22:48.39 |
Ralith |
you mean the
model that guy was working on? |
| 22:48.50 |
jonored_ |
hippieindamakin8: I was thinking the same
thing... a good drawing of the internals of a polywell would be
shiny... |
| 22:49.04 |
starseeker |
yes, only
concerned with licensing of cad models as a means to an
end |
| 22:49.16 |
hippieindamakin8 |
Ralith, yeah
the one famulus is working on |
| 22:49.20 |
Ralith |
kk |
| 22:49.39 |
starseeker |
the end being
lots of good quality free models :-) |
| 22:50.12 |
starseeker |
hmm |
| 22:50.21 |
starseeker |
(the cat
insists on being petted) |
| 22:50.31 |
Ralith |
cats do
that. |
| 22:50.46 |
hippieindamakin8 |
http://prometheusfusionperfection.wordpress.com/2009/04/16/fusor-core/ |
| 22:50.50 |
hippieindamakin8 |
Ralith,
^ |
| 22:50.53 |
brlcad |
ideally even
scoping the site even further to distinguish or require that the
models also be solid geometry, so that they are "real world"
models |
| 22:51.00 |
Ralith |
hippieindamakin8: yeah, I remember
that |
| 22:51.46 |
brlcad |
things I
could feed to a CNC or rapid prototyper or an analysis, compute
weights/moments on, calculate volumes, etc |
| 22:53.08 |
Ralith |
oh
yeah |
| 22:53.11 |
Ralith |
jonored_:
how's the slicer doing? |
| 22:53.41 |
hippieindamakin8 |
brlcad, i
guess the repository can be integrated into drupal |
| 22:53.58 |
brlcad |
into anything
really |
| 22:54.22 |
jonored_ |
Ralith: Most
of the way cleaned up, but still taken a back seat to
graduating. |
| 22:55.05 |
Ralith |
of course.
Looking forward to playing with it. |
| 22:57.22 |
Ralith |
brlcad: did
you have any further input on my milestones/timeline? |
| 22:59.19 |
brlcad |
Ralith: not
today :) |
| 22:59.29 |
Ralith |
kk |
| 22:59.34 |
brlcad |
is decompressing a little |
| 22:59.50 |
Ralith |
that's always
nice. |
| 00:50.13 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 00:53.14 |
*** join/#brlcad dreeves2
(n=dreeves@64.178.177.71) |
| 01:07.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 01:11.38 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 01:45.33 |
starseeker |
brlcad: I
agree, real world geometry is the way to go |
| 01:53.28 |
starseeker |
wonders if we can get the ProE files for this sucker:
http://www.longnow.org/projects/clock/prototype1/ |
| 02:00.54 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 02:04.14 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 03:24.45 |
*** part/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 03:24.51 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 03:28.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 04:21.58 |
yukonbob |
happy friday,
cadheads |
| 04:25.19 |
pacman87 |
good
evening |
| 07:10.11 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 07:21.21 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 07:33.59 |
*** join/#brlcad madant
(n=d@117.196.131.31) |
| 08:28.26 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:37.48 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 09:25.44 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 09:57.57 |
*** join/#brlcad _sushi_
(n=_sushi_@77.58.234.64) |
| 11:08.46 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 11:49.26 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 14:03.59 |
*** join/#brlcad dreeves
(n=40b2b147@bz.bzflag.bz) |
| 14:11.06 |
``Erik |
blinks and looks at the microsoft access database sitting in
rt^3 |
| 14:35.47 |
*** join/#brlcad dreeves
(n=IceChat7@64.178.177.71) |
| 14:46.38 |
madant |
searches for his mojo |
| 16:04.12 |
*** join/#brlcad cad24
(n=71808c7b@bz.bzflag.bz) |
| 16:10.19 |
brlcad |
``Erik:
eh? |
| 16:16.33 |
``Erik |
rt^3/docs/BME.eap ? |
| 16:17.51 |
``Erik |
hmmm, that
uml thingy dave uses must use access as the backend |
| 16:27.21 |
brlcad |
ah |
| 17:07.34 |
starseeker |
ew |
| 17:09.08 |
starseeker |
maybe
http://argouml.tigris.org/
could work? |
| 17:11.29 |
*** join/#brlcad FAMULUS
(n=mark@ool-ad028f27.dyn.optonline.net) |
| 17:12.05 |
FAMULUS |
what would
cause an object which has been Blasted to the canvas to show in a
raytrace, but not in wireframe? |
| 17:26.00 |
``Erik |
you mean like
an overlay vs underlay issue? |
| 17:26.21 |
FAMULUS |
``Erik: I
can't see the object in wireframe view |
| 17:26.27 |
FAMULUS |
but I can see
it when I raytrace |
| 17:26.45 |
FAMULUS |
feature or
bug? |
| 17:27.28 |
``Erik |
um, I'm not
quite sure what state your mged is in, if you raytrace and have it
in overlay (I think?) mode, the wireframe will not show |
| 17:27.39 |
brlcad |
starseeker:
give it a go? only way to know would be to try it out |
| 17:28.37 |
brlcad |
FAMULUS:
Settings -> Framebuffer -> turn off "Framebuffer
Active" |
| 17:28.52 |
brlcad |
it's also a
checkbox on the raytrace control panel |
| 17:29.46 |
starseeker |
brlcad: I'll
ask him on Monday |
| 17:30.14 |
starseeker |
doubt it can
import the access database, but maybe he can export it
somehow |
| 17:30.25 |
brlcad |
starseeker:
er, ask him what? :) I know he tried out various tools, most that
just crashed a lot on him |
| 17:30.35 |
brlcad |
the only one
that was mildly stable was the commercial one he's using
now |
| 17:30.48 |
brlcad |
there are
renderings of those class diagrams |
| 17:30.51 |
starseeker |
ask him to
export the data from his commercial tool into some non-access
form |
| 17:30.59 |
starseeker |
nods |
| 17:31.13 |
brlcad |
http://brlcad.org/design/gs/ |
| 17:31.45 |
starseeker |
psd? |
| 17:32.00 |
brlcad |
photoshop |
| 17:32.06 |
starseeker |
ah |
| 17:32.16 |
brlcad |
gimp reads
those iirc |
| 17:32.39 |
starseeker |
wonder why he
stuck the access database into svn |
| 17:32.55 |
brlcad |
what erik
said more than likely |
| 17:33.03 |
brlcad |
it just
happens to be what the software uses on the backend |
| 17:33.21 |
starseeker |
nods |
| 17:33.36 |
brlcad |
it is
otherwise "just a binary file" that the software stores its data
into, whatever the name of that software is |
| 17:33.44 |
brlcad |
or even more,
might just happen to use the same suffix |
| 17:33.51 |
brlcad |
dunno if he
was reading the contents |
| 17:33.58 |
starseeker |
well, if
that's the only thing that works, I guess that's what we go
with |
| 17:34.16 |
starseeker |
emerges argouml to see what it's like |
| 17:34.18 |
``Erik |
notes that the extension there is .eap where access is
technically .mdb, 'file' told me it was access and some googling
shows that the 'jet database' is what access actually calls itself
internally |
| 17:34.44 |
brlcad |
on a more
interesting note .. :) http://brlcad.org/tmp/tgcbug.rt |
| 17:34.51 |
``Erik |
imagines some company wrote a 'jet database' and ms bought
it, now windows tools just use it as a convenient backend, like
sqlite |
| 17:35.19 |
brlcad |
isolated a
tgc failure in havoc that returns only one hit point -- good test
case |
| 17:37.44 |
starseeker |
hmm |
| 17:38.02 |
``Erik |
the aging
'new' bz is all updated again |
| 17:38.04 |
``Erik |
O.o |
| 17:38.39 |
brlcad |
woot |
| 17:38.57 |
``Erik |
most
sarcastic woot ever? :D *duck* |
| 17:39.04 |
brlcad |
nope, good
stuff |
| 17:39.10 |
brlcad |
genuine
wootage |
| 17:39.16 |
starseeker |
brlcad:
confirmed, returns a miss here too |
| 17:39.19 |
starseeker |
odd |
| 17:39.33 |
brlcad |
it's a funky
tgc with a pinched top, but it's a clean shot |
| 17:39.38 |
``Erik |
migration
would equal w00tage :D hop to, boy :D *duck* |
| 17:39.42 |
brlcad |
right into
the side and out the flat disc |
| 17:40.35 |
brlcad |
nirt seems to
plot the right entry and exit values, so kind of odd |
| 17:40.48 |
brlcad |
``Erik: I did
at least finally turn off the german server |
| 17:41.05 |
brlcad |
spent much of
last week sorting that out |
| 17:41.22 |
brlcad |
they didn't
want to "let me go" giving hell about terms I never agreed
to |
| 17:41.32 |
``Erik |
heh |
| 17:41.47 |
``Erik |
lame, as much
as I like the notion of having a backup on another continent, it
sounds like they were being dickish |
| 17:41.57 |
brlcad |
they were, I
was very surprised |
| 17:42.11 |
brlcad |
up until
then, everything had been perfect/better with them |
| 17:42.17 |
``Erik |
did the
florida one agree to migrate your IP pool? |
| 17:42.47 |
``Erik |
lotr on tnt,
btw, good background noise |
| 17:42.53 |
brlcad |
but then they
were royally being dicks when I asked to cancel .. and it was even
originally just going to be temporary (until after bz is migrated,
6 months or so) |
| 17:43.04 |
brlcad |
they haven't
answered |
| 17:44.20 |
brlcad |
even if I had
agreed to an annual contract renewal (which I didn't), my message
to them was 12 days before the end of term .. |
| 17:44.30 |
brlcad |
they claimed
it needed to be 14 days in advance |
| 17:44.38 |
brlcad |
which just
made me even more livid |
| 17:45.20 |
brlcad |
6 e-mails
later that just keep escalating, they finally agreed to my
request |
| 17:45.30 |
brlcad |
very absurd,
disappointing |
| 17:45.44 |
``Erik |
hm, *shrug*
they're probably feeling some economic crunch and have some pointy
haired fuckwit that thinks forcing customers to stay is a viable
business solution |
| 17:46.31 |
``Erik |
lots of
service companies seem to try that :( |
| 17:46.38 |
brlcad |
it's not like
I'm going to just keep paying them for the hell of it, especially
after that |
| 17:47.59 |
brlcad |
especially
given that they had an interesting "we will terminate you
instantly" clause if you put up porn |
| 17:48.16 |
brlcad |
I told them,
do I *really* need to put up porn for you to get the
point? |
| 17:48.56 |
``Erik |
heh, nothin'
like a goatse or lemonparty to get someones attention
O.o |
| 17:49.06 |
brlcad |
especially
given I didn't agree to the term and I was before the end of the
term I didn't agree to anyways |
| 17:49.24 |
brlcad |
yeah, it was
getting rather unpleasant |
| 17:49.44 |
brlcad |
so now I'm
thinking about whether I'd ever go back to them |
| 17:49.52 |
brlcad |
shame really,
it was just going to be temporary |
| 17:50.01 |
``Erik |
there're
still residual scars burnt into the back of my brain from when I
saw a particularly ... 'hardcore' gay porn image iwth "verizon
customer service" stashed in a humor pic site (I'm ok with nsfw,
but this was not safe for human consumption) |
| 17:50.09 |
brlcad |
guess they
don't realize how I throw money away at having servers on standby
*cough* |
| 17:50.32 |
brlcad |
heh |
| 17:50.45 |
brlcad |
when it was
heated, those thoughts were crossing my mind |
| 17:50.46 |
*** join/#brlcad dreeves
(n=IceChat7@64.178.177.71) |
| 17:51.13 |
brlcad |
wouldn't have
taken a whole lot to turn the site into "custom porn" for them with
entire transcripts of our discussions |
| 17:51.58 |
``Erik |
have you seen
http://www.youtube.com/watch?v=YRgNOyCnbqg
? :D |
| 17:53.40 |
``Erik |
aaanyays, the
new machine seems solid. given that the old one provides many
different services, it might be a good time to migrate some of the
less critical or less connected ones over (like mebbe
bind) |
| 17:54.01 |
``Erik |
thinks 'incremental migration' might be a good
strategy |
| 17:54.09 |
``Erik |
until then,
it's still my personal playpen I guess :D |
| 17:58.33 |
brlcad |
I fear
migrating bind actually -- if you want to tackle that one, go for
it |
| 18:01.07 |
CIA-28 |
BRL-CAD:
03brlcad * r34242 10/brlcad/trunk/src/librt/primitives/tgc/tgc.c:
note that the units being displayed are in 'mm' regardless of the
local units set. |
| 18:02.52 |
CIA-28 |
BRL-CAD:
03brlcad * r34243 10/brlcad/trunk/include/raytrace.h: |
| 18:02.52 |
CIA-28 |
BRL-CAD:
allow a NULL parameter to be passed to RT_HIT_NORMAL if they don't
have a normal |
| 18:02.52 |
CIA-28 |
BRL-CAD:
array to be filled in and just want hitp->hit_normal to be
calculated. this |
| 18:02.52 |
CIA-28 |
BRL-CAD:
makes it pretty trivial to update code that used RT_HIT_NORM() over
to |
| 18:02.52 |
CIA-28 |
BRL-CAD:
RT_HIT_NORMAL() by just adding a NULL and 0 flip value. |
| 18:20.22 |
*** join/#brlcad samrose
(n=samrose@ip-207-145-38-45.iad.megapath.net) |
| 18:20.49 |
brlcad |
so for
information purposes, I'm applying to the openusability call for
projects |
| 18:21.04 |
brlcad |
there's
little chance we'll be accepted as the deadline was a couple days
ago, but applying anyways |
| 18:21.17 |
brlcad |
basically,
it's similar to gsoc but specifically focused on
usability |
| 18:21.50 |
brlcad |
and since
usability is one of our biggest problems, I figure why
not |
| 18:21.59 |
brlcad |
(unfortunately, I just heard about the
effort) |
| 18:22.24 |
``Erik |
ratemyui.com?
O.o heh |
| 18:22.26 |
brlcad |
that said,
need to know who (of developers) would be willing to mentor a
usability project? |
| 18:22.29 |
louipc |
that's pretty
cool |
| 18:22.37 |
``Erik |
uiornot.com? |
| 18:22.41 |
brlcad |
(if you have
commit access, you qualify) |
| 18:22.46 |
louipc |
I want all my
console apps to have a vi-like interface hehe |
| 18:22.53 |
brlcad |
louipc:
hehe |
| 18:22.58 |
``Erik |
vi
ftw |
| 18:23.10 |
brlcad |
scratches two names off the list! |
| 18:23.11 |
brlcad |
j/k |
| 18:24.10 |
brlcad |
unlike gsoc,
I don't think they'd actually be coding -- I think their tasks are
specifically towards usability specifications, mockups, specific
guideline formulations, etc |
| 18:24.33 |
brlcad |
need an okay
to give them your e-mail if you're interested |
| 18:25.26 |
brlcad |
was thinking perhaps starseeker and/or ``Erik and whomever
else is interested |
| 18:39.27 |
PrezKennedy |
i want brlcad
to be like emacs... some games and a mail app built right
in |
| 18:45.50 |
brlcad |
I think we
can make that happen |
| 18:46.00 |
brlcad |
even with
justification! |
| 18:46.18 |
brlcad |
games for
those down-time moments when they're waiting for a render or a
conversion to complete |
| 18:46.28 |
brlcad |
mail app for
.. discussing model changes, yeah |
| 18:48.55 |
brlcad |
starseeker:
``Erik: how about it? .. *crickets*? :) |
| 18:49.25 |
archivist |
irc
window? |
| 18:49.33 |
brlcad |
archivist:
hm? |
| 18:49.55 |
brlcad |
archivist:
you up for mentoring a usability project? :) |
| 18:50.34 |
archivist |
dunno /me
never dun nuffink like that |
| 18:51.05 |
brlcad |
would you
like to do somefink like dat? |
| 18:51.52 |
archivist |
I would have
a bias towards a Solidworks look alike :) |
| 18:52.02 |
brlcad |
that would be
fantastic |
| 18:52.24 |
brlcad |
actually,
that's very good usability background to be able to talk about with
the student |
| 18:52.48 |
louipc |
I didn't
think solidworks was very usable |
| 18:53.01 |
archivist |
heh! |
| 18:53.03 |
louipc |
autocad was
better I think |
| 18:53.09 |
archivist |
hell
no |
| 18:53.16 |
brlcad |
the point
would be really to engage the student in a dialog |
| 18:53.23 |
brlcad |
be able to
relate it to what industry does |
| 18:53.31 |
brlcad |
and to how /
why we do things |
| 18:53.51 |
brlcad |
and then (I
gather) to figure out what we can best focus on or how we can best
approach improving our usability |
| 18:54.03 |
brlcad |
such that it
fulfills expectations, is intuitive, is familiar, etc |
| 18:54.18 |
brlcad |
(and
productive, can't forget the most important aspect) :) |
| 18:54.28 |
brlcad |
louipc: you
interested? |
| 18:54.58 |
louipc |
maybe if I
have a partner :P |
| 18:55.09 |
brlcad |
you're not
exactly committing to anything firm just yet -- I just need to be
able to give a list of potential mentors as part of our
application |
| 18:55.36 |
louipc |
so I would
just talk about what I find helps usability? |
| 18:55.48 |
brlcad |
I'd be glad
to partner up there, I have a fair bit of usability training and
experience (contrary to brl-cad's gui, heh) |
| 18:56.13 |
brlcad |
louipc: you
would be mentoring a student that would be working on some specific
aspect of usability |
| 18:56.49 |
louipc |
hah |
| 18:56.49 |
brlcad |
like lets
say, hypothetically, that they were going to look at ways of making
mged's existing menu mess be less of a mess |
| 18:57.17 |
brlcad |
or finding
patterns in our 400+ commands and finding ways to make their
command-line invocation more consistent and intuitive |
| 18:58.27 |
louipc |
Yeah I would
like to, but I don't want to lead anyone on about knowing more than
I really do... |
| 18:59.08 |
louipc |
brlcad: yeah
that sounds alright |
| 18:59.17 |
brlcad |
or maybe
formulating a specific case study on the usability of a prescribed
interaction scenario, like modeling a cup, and going into
excrutiating detail on the various calculatable metrics to suggest
changes that would improve efficiency |
| 18:59.56 |
louipc |
that's a good
one |
| 19:00.08 |
brlcad |
louipc: your
familiarity and mentoring ability more comes from your ability to
speak to (or figure out) what brl-cad does, what CAD does/requires
in general, and to explain that to someone who probably has
absolutely no experience with CAD |
| 19:00.16 |
louipc |
I was kind of
doing that at one point |
| 19:00.48 |
brlcad |
sounds like
we have a winner then! .. would you PM me an e-mail? |
| 19:01.08 |
brlcad |
still an
outstanding question for archivist starseeker ``Erik ... and I'm
sure more of you lurking here! |
| 19:01.40 |
brlcad |
usability is
our biggest problem, this has huge impact potential |
| 19:02.06 |
archivist |
sure
does |
| 19:02.33 |
archivist |
been trying
and watching all sorts over the years |
| 19:02.44 |
PrezKennedy |
brlcad needs
a ribbon :) |
| 19:02.54 |
louipc |
archivist: I
don't like how solidworks is so click-and-point dialog-box heaven
:P |
| 19:03.17 |
archivist |
its faster
once you are used to it |
| 19:03.38 |
brlcad |
PrezKennedy:
are you saying you want to mentor too? :) |
| 19:03.51 |
archivist |
and on a cold
day you can keep one hand in your pocket |
| 19:03.51 |
PrezKennedy |
poor kid
would be ruined for life |
| 19:04.50 |
brlcad |
humorously
and coincedentally relevant: http://corsix.org/gsoc/ribbon.html |
| 19:04.59 |
louipc |
well actually
the point-and-click is more usable for novices |
| 19:05.01 |
PrezKennedy |
brlcad, am i
even qualified to mentor anything? :p |
| 19:05.32 |
brlcad |
PrezKennedy:
undoubtedly |
| 19:08.27 |
PrezKennedy |
scary, but it
could be fun |
| 19:14.00 |
``Erik |
*readreadread* |
| 19:14.37 |
``Erik |
I have
strange notions about usability, I kinda prefer mged -c to mged for
the incredibly rare occasion when I can be assed to do it...
O.o |
| 19:15.00 |
brlcad |
``Erik: so
you could mentor someone specifically about command-line usability
metrics |
| 19:15.07 |
louipc |
``Erik: I
agree |
| 19:15.11 |
brlcad |
they still
propose what they're actually going to work on |
| 19:15.13 |
louipc |
:D |
| 19:15.14 |
brlcad |
similar to
gsoc |
| 19:15.40 |
brlcad |
thinks brl-cad would be a formidable usability playground ..
lots of ways to improve |
| 19:16.45 |
``Erik |
*shrug*
whatever, I suppose |
| 19:21.54 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C548.dip.t-dialin.net) |
| 19:23.18 |
*** join/#brlcad pacman87
(i=500@resnet-46-40.dorm.utexas.edu) |
| 19:23.36 |
brlcad |
``Erik:
cool |
| 19:38.30 |
PrezKennedy |
dont forget
to make it web 2.0! |
| 19:38.58 |
``Erik |
web 7.14,
yo |
| 19:39.32 |
PrezKennedy |
web 3.11 for
workgroups |
| 19:40.09 |
``Erik |
web bob?
O.o |
| 19:40.09 |
archivist |
object
oriented assembler rulz |
| 19:41.17 |
archivist |
sad thing is
that did exist as a book Object oriented assembly language byL.
Dirfman |
| 19:41.31 |
archivist |
worse...I
have it |
| 19:42.30 |
``Erik |
it's called
objc, right? :D |
| 19:42.49 |
``Erik |
C is the
pdp11 assembler, right? |
| 19:45.08 |
archivist |
High Level
Assembler :) |
| 19:45.32 |
archivist |
I shouldnt
joks as that exists as well |
| 19:46.57 |
``Erik |
dang wussies
and yoru labels and stuff *shakes cane* whatever happened to good
old machine code monitors? :D |
| 19:50.01 |
*** join/#brlcad pacman87_
(n=pacman87@bz.bzflag.bz) |
| 19:50.19 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 20:15.43 |
pacman87_ |
ssh + screen
+ irssi + ipod touch ftw |
| 20:22.37 |
brlcad |
heh, where'd
you get an ssh client from? |
| 20:24.39 |
pacman87 |
app
store |
| 20:25.00 |
brlcad |
huh |
| 20:25.31 |
brlcad |
haven't syncd
my phone in few months.. probably should |
| 20:31.25 |
brlcad |
which app do
you have? looks like there's at least 4 |
| 20:32.37 |
brlcad |
jugaari looks
like it might be worth it if it does all it says.. |
| 20:33.01 |
pacman87_ |
iSSH |
| 20:33.22 |
brlcad |
er,
jaadu |
| 20:36.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34244 10/brlcad/trunk/src/ (11 files in 4 dirs): remove
all references and instances of the old deprecated RT_HIT_NORM()
macro, instead using the new RT_HIT_NORMAL() macro. |
| 20:37.57 |
pacman87_ |
i won the
ipod in a coding competition |
| 20:38.05 |
pacman87_ |
got
3rd |
| 20:38.12 |
brlcad |
hah,
awesome |
| 20:38.23 |
pacman87_ |
.2% away from
2nd |
| 20:38.33 |
brlcad |
what was
2nd's prize? :) |
| 20:38.46 |
pacman87_ |
24in
hdtv/monitor |
| 20:38.47 |
brlcad |
acm
competition? |
| 20:39.04 |
pacman87_ |
no, amd
sponsored |
| 20:39.11 |
brlcad |
lemme guess,
first was an amd laptop? :) |
| 20:39.21 |
pacman87_ |
desktop |
| 20:39.25 |
brlcad |
ah |
| 20:39.33 |
pacman87_ |
plus tumer
dard |
| 20:39.38 |
pacman87_ |
card |
| 20:39.46 |
pacman87_ |
quad
core |
| 20:40.14 |
brlcad |
nice
prizes |
| 20:40.45 |
brlcad |
the touch is
probably a more useful productive use of your time than an hdtv
would have been :) |
| 20:41.07 |
*** join/#brlcad DGMurdockIII
(n=dgmurdoc@64-184-10-18.bb.hrtc.net) |
| 20:41.21 |
pacman87_ |
probably |
| 20:41.44 |
pacman87_ |
and my gf
likes playing with it |
| 20:44.23 |
*** join/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 20:44.55 |
*** part/#brlcad _pseudo
(n=irchon@wireless-128-62-174-226.public.utexas.edu) |
| 22:11.52 |
``Erik |
/t 04:42PM
<pacman87_> and my gf likes playing with it |
| 22:11.55 |
``Erik |
O:-) |
| 22:13.39 |
yukonbob |
"hey baby,
wanna i-touch?" |
| 22:14.12 |
yukonbob |
"You mean an
iPod Touch?" |
| 22:14.15 |
yukonbob |
"not
exactly" |
| 22:14.24 |
pacman87_ |
was wondering when someone would say
something... |
| 22:14.35 |
yukonbob |
hi pacman87_
:) |
| 22:14.45 |
pacman87_ |
howdy |
| 22:18.00 |
pacman87 |
ping times to
my ipod vary from 44ms to 1000 |
| 22:18.15 |
pacman87 |
or
15000 |
| 22:18.18 |
pacman87 |
1500 |
| 22:20.09 |
yukonbob |
?ping
times |
| 22:20.37 |
pacman87 |
ssh out, ping
back in |
| 22:21.06 |
yukonbob |
ah... /me
forgot you said Touch, even after was joking about it.
:P |
| 22:21.57 |
pacman87 |
maybe i
shouldn't port bzflag to it :P |
| 22:23.08 |
pacman87 |
wifi access
all over campus is very nice |
| 22:23.23 |
pacman87 |
having the
internet in my pocket :D |
| 22:32.35 |
brlcad |
pacman87: it
was too easy ;) |
| 22:33.25 |
dreeves |
brlcad are
you aware that dented sphere is a revsurface? |
| 22:33.28 |
brlcad |
pacman87:
didn't you hear my rant in the channel about the latency last year
wrt ipod/iphone port of bzflag? |
| 22:33.45 |
brlcad |
dreeves:
yeah, I vaguely recall that |
| 22:33.45 |
pacman87 |
i must've
missed that one |
| 22:33.51 |
pacman87 |
~logs |
| 22:33.52 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 22:34.13 |
brlcad |
not so much a
rant as several semi-extended discussions about why it'd kinda suck
as a client :) |
| 22:34.28 |
pacman87 |
yeah, every
other packet took really long |
| 22:34.34 |
pacman87 |
and ended up
out of order |
| 22:34.43 |
brlcad |
even if you
could buffer up and stabilize the networking, the cpu is a bit of a
problem being somewhat weak |
| 22:34.50 |
brlcad |
and being
fully-interruptible |
| 22:34.57 |
pacman87 |
radar-only! |
| 22:35.03 |
brlcad |
the OS steals
time from everything including itself at times.. |
| 22:35.35 |
brlcad |
even when
your app is running, especially if you make a system
call |
| 22:35.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 22:37.32 |
pacman87 |
i don't
suppose there's an easy to search the online logs |
| 22:37.40 |
brlcad |
nah, it
sucks |
| 22:37.47 |
brlcad |
but I
basically just gave you the abridged version |
| 22:38.08 |
pacman87 |
k |
| 22:44.49 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:54.13 |
hippieindamakin8 |
good morning/
good afternoon folks |
| 22:55.38 |
hippieindamakin8 |
woah
ipod/iphone port of bzflag : cool |
| 23:53.59 |
starseeker |
dreeves: how
is it revolved? around the center of the dent? |
| 00:26.58 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 00:27.19 |
CIA-28 |
BRL-CAD:
03brlcad * r34259 10/brlcad/trunk/src/ (libged/mirror.c
librt/primitives/mirror.c): this is wrong -- librt should ONLY work
with base units. libged or application responsibility to be aware
of units and convert accordingly. push it up into
ged_mirror(). |
| 00:27.59 |
CIA-28 |
BRL-CAD:
03brlcad * r34260 10/brlcad/trunk/src/librt/db_inmem.c:
indent |
| 00:29.06 |
CIA-28 |
BRL-CAD:
03brlcad * r34261 10/brlcad/trunk/src/librt/CMakeLists.txt:
mirror.c and table.c were moved |
| 00:47.06 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:58.19 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:50.13 |
dreeves |
brlcad
starseekerI think I'm going to have to troubleshoot the surface
subdivision algorithm in the bvh stuff because it is what was
causing the problems with dented sphere, rebuilt sphere, etc..
however I can't just turn it off because it is used for the initial
guess. |
| 01:51.29 |
dreeves |
I mean to say
I'm going to have to do that before moving on to the bigger
geometries because I'm seeing similar issues that I saw with the
less complex geometries |
| 01:52.55 |
dreeves |
also probably
need to go ahead and get the more generalized trimming stuff
working because on larger trim curves my approximations may not be
sufficient |
| 02:03.05 |
starseeker |
dreeves:
sounds good |
| 02:03.32 |
starseeker |
the larger
examples aren't of serious interest until we can handle the simper
cases - they are intended as "stress tests" |
| 02:07.34 |
dreeves |
yeah
starseeker I think we are pretty close to handling the simpler
cases ok now except for the distorted sphere fine (but I'm not sure
about that one period) I think if physically make those examples
bigger the raytracer will start showing the problems
again |
| 02:09.20 |
dreeves |
I think we
have to generalize for the simpler cases and make it alot more
robust before tackling the more complex examples I was wanting to
wait but I think I'm seeing the problem with that approach so I
will have to take a step back |
| 02:09.23 |
brlcad |
gets a nifty response from the openusability
folks |
| 02:09.50 |
brlcad |
starseeker:
were you interested in that? (did you see my messages on
friday?) |
| 02:10.22 |
brlcad |
dreeves: hmm,
pulling it back to some of the more basic aspects of the problem...
that sounds very familiar :-) |
| 02:13.30 |
starseeker |
brlcad: I did
see that, but my thought on it is that we're not quite ready for
usability work yet... |
| 02:14.26 |
brlcad |
there's many
places and many ways where usability can be improved |
| 02:14.30 |
brlcad |
we're not
just talking about mged |
| 02:14.34 |
starseeker |
ah |
| 02:14.38 |
brlcad |
though even
mged could use some basic attention |
| 02:14.44 |
brlcad |
or archer for
that matter |
| 02:14.45 |
starseeker |
would the
others generate interest? |
| 02:14.55 |
starseeker |
isn't familiar with openusability...
googles... |
| 02:15.14 |
brlcad |
wouldn't it
be nice if someone specifically paying attention to usability
sorted out exactly how the menu system should be
arranged? |
| 02:15.32 |
starseeker |
yes, it would
be |
| 02:15.36 |
brlcad |
or basic key
bindings for that matter |
| 02:15.42 |
brlcad |
or
information panels |
| 02:15.45 |
brlcad |
or command
line options |
| 02:15.45 |
starseeker |
what are the
mentoring requirements? |
| 02:15.57 |
dreeves |
Well the 2
basic issues right now are 1) the approximation of the trim curve
right now it is hardwired for 100 segments. On a smaller curve
that means a segment may represent something like 0.03 or less in
length but on a larger curve that may represent some like 5 or xxx
in length which obviously that gets to be a problem. I just need
to get away from the approximation approach altogether. The second
issue is the subdividing the surface and surroundi |
| 02:15.57 |
dreeves |
ng the
segment of surface with a bounding box and the current algorithm
grows by some small percentage to account for curving near the
edges well on smaller geometry that fudging maybe sufficient but on
larger geometries that fudging is not near enough |
| 02:16.19 |
starseeker |
figures key bindings will need to be configurable to
Solidworks/Pro-E/Unigraphics to allow work flows to be
preserved |
| 02:16.44 |
brlcad |
sure, that
might be one thing -- but what should our defaults be? |
| 02:16.53 |
starseeker |
nods |
| 02:17.09 |
starseeker |
yeah, that
sounds good - I take it you got a positive response? |
| 02:17.48 |
brlcad |
I certainly
have my notions and background in usability and biases towards
tools I've learned, but that's still different from specifically
and intently sitting down as a project and sorting out what those
defaults should be -- takes time |
| 02:18.55 |
brlcad |
unknown about
whether we can participate this year, but that's not even really
the main focus I think -- just getting ourselves aligned to be
thinking more about usability and prepared to mentor such projects
will be good |
| 02:19.03 |
brlcad |
so even if we
can't participate this year, perhaps next year |
| 02:19.30 |
starseeker |
sure |
| 02:19.39 |
starseeker |
what
specifically do you need me to do? |
| 02:19.46 |
starseeker |
scrolls back... |
| 02:19.48 |
dreeves |
I think once
we have generalized those 2 issues we can handle the bigger and
more complex geometries |
| 02:19.48 |
brlcad |
the mentoring
requirements are more towards being the experts in our domain (CAD,
solid modeling) so that we can have a useful dialog |
| 02:20.03 |
starseeker |
dreeves:
sounds good |
| 02:20.30 |
brlcad |
as they are
students that likely have no background in our area or even
necessarily software design for that matter -- they get students
that focus specifically on usability |
| 02:20.48 |
dreeves |
so I'm not
really pulling back just going back and generalizing the stuff I
have hardwired up to this point |
| 02:21.20 |
brlcad |
dreeves: it
was tounge-in-cheek, not critique :) |
| 02:21.43 |
dreeves |
Oh you didn't
offend me and I definitely took it that way |
| 02:21.56 |
brlcad |
generalizing
what's in place is a form of "going back", and going back is the
approach I'd started down on a while back |
| 02:22.18 |
starseeker |
brlcad: yeah,
I'd certainly be willing to work as mentor on a project like
that |
| 02:22.58 |
brlcad |
starseeker:
great, I figured you would be |
| 02:23.00 |
dreeves |
Yeah the main
reason for what I wrote is mainly if anyone else wanted to work on
this more than anything I just want people to know what needs to be
worked |
| 02:23.31 |
dreeves |
i.e.
starseeker |
| 02:23.48 |
dreeves |
and I know
there are a couple of people looking at things |
| 02:23.50 |
starseeker |
dreeves: I'm
going to be attacking from the "need debugging/analysis
capabilities" side, which should be orthogonal to the thrust of
your work |
| 02:23.53 |
dreeves |
associated
with brep |
| 02:24.05 |
dreeves |
coole |
| 02:24.07 |
dreeves |
cool |
| 02:24.49 |
brlcad |
woot! looks
like my rt_mirror() change works... |
| 02:24.51 |
brlcad |
why does bob
have to make it so complicated sometimes :) |
| 02:24.54 |
starseeker |
once we get
to more complex geometries, we're likely to hit test cases where
it's really hard to get a minimal case (possibly even problems
specifically caused by a case being complex) |
| 02:25.05 |
starseeker |
brlcad:
lol! |
| 02:25.13 |
starseeker |
has wondered this... |
| 02:25.53 |
dreeves |
Did that
other person ever respond what they were doing with curvature the
other day? |
| 02:26.03 |
brlcad |
seriously, he
had the math doing flips because he wanted to specify a point
(sure) and a direction (okay) .. and a distance down that vector
(um) |
| 02:26.20 |
brlcad |
and then
tracking that distance all the way through to librt to the
primitives themselves for a couple of them |
| 02:26.36 |
starseeker |
winces |
| 02:26.37 |
brlcad |
I mean
really.. just move the point |
| 02:27.06 |
dreeves |
:) |
| 02:27.19 |
brlcad |
now the trick
will be to rewire all the primitives to actually use a plane_t
instead of a point+dir |
| 02:28.45 |
dreeves |
ok so he
wasn't really trouble shooting a perceived problem with
opennurbs |
| 02:28.53 |
brlcad |
which is a
nice compact plane equation -- a vector and a distance, 4 values --
but changes things .. probably just derive the point and
dir |
| 02:29.09 |
starseeker |
nods |
| 02:29.32 |
starseeker |
dreeves: no,
Bob is doing libged (prime mover thereof, actually) |
| 02:30.13 |
dreeves |
ok I'm
talking about something else |
| 02:30.46 |
starseeker |
heh - welcome
to irc - multi-threading conversations |
| 02:31.04 |
dreeves |
yeah I'm
learning I'm new to irc |
| 02:32.33 |
dreeves |
it is
basically chatting and I have done plenty of that but usually one
on one |
| 02:33.28 |
brlcad |
dreeves: they
(jonored) was working on implementing the curve()
callback |
| 02:34.48 |
brlcad |
he'd noticed
that the normal was being filled in during shot(), so norm()
perhaps can stay pretty simple (need to verify what others are
doing) .. but that still leaves curve() |
| 02:36.03 |
brlcad |
briefly
mentioned on the 17th if you have logs |
| 02:38.23 |
starseeker |
~logs |
| 02:38.23 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 02:39.28 |
brlcad |
really need
to get website irc log integration with drupal working so we can
search our own content |
| 02:41.03 |
brlcad |
even a cron
job that snatches from ibot and adds to cms would be
better |
| 02:56.18 |
dreeves |
ok the
website with the logs is neat |
| 02:57.49 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177593646.dsl.bell.ca) |
| 02:58.00 |
dreeves |
btw shot
isn't calculating the normal it is being calculated from what is
returned from opennurbs in the intersect function |
| 03:03.49 |
brlcad |
er, but that
happens during shot() right? :) |
| 03:04.09 |
dreeves |
yeah if you
mean it is being called from shot? |
| 03:04.18 |
dreeves |
which it
is |
| 03:05.05 |
brlcad |
right, that's
all that mattered |
| 03:05.11 |
dreeves |
oh
ok |
| 03:05.21 |
brlcad |
it's filling
in the hit_normal |
| 03:05.28 |
brlcad |
normally shot
isn't responsible for doing that |
| 03:05.36 |
dreeves |
obviously I
didn't understand something |
| 03:05.45 |
dreeves |
ah
ok |
| 03:06.41 |
dreeves |
makes since
then |
| 03:06.46 |
brlcad |
also normal
!= curvature, don't know if you were thinking that or
not |
| 03:07.26 |
dreeves |
no I know
that |
| 03:07.57 |
brlcad |
k |
| 03:08.12 |
dreeves |
goes back to look at exactly what is being
returned |
| 03:10.52 |
brlcad |
probably
shouldn't be filling in hit_normal the more I think about
it |
| 03:11.01 |
brlcad |
at least,
norm() really shouldn't be empty |
| 03:11.21 |
brlcad |
I think what
some of the other primtivies do that have the information
calculated early is to stash it into vpriv |
| 03:11.37 |
dreeves |
actually it
is returning the derivative in both s and t and normal is being
calculated from that |
| 03:12.04 |
brlcad |
yeah, then
probably shouldn't do that .. just stash the derivs |
| 03:12.12 |
brlcad |
then norm()
can do the final calculation |
| 03:13.25 |
dreeves |
ok in the
next round of clean up I can do that unless the other person is
working on that. Don't want to step on what they are
doing. |
| 03:16.28 |
dreeves |
I'm
definitely ready to harden what we have now vs keep
tweeking/hacking to make work with the different geometries. I
think that is what is required to take the next big step. What do
you think? |
| 03:18.32 |
dreeves |
you know
since I went back to utah's combination of tolerances I haven't had
to touch them again. Of course that is with this test geometry
that is all roughly the same overall size |
| 03:23.19 |
brlcad |
dreeves:
yeah, I'd just let them work on that part -- it's not exactly
busted as it is |
| 03:23.37 |
brlcad |
it's much
lower-hanging fruit (norm() at least, curve() could be
interesting) |
| 03:24.27 |
brlcad |
if I remember
utah's paper, all of their geometry was pretty small :) |
| 03:24.48 |
brlcad |
elaine
mentioned that it wasn't very robust.. :) |
| 03:27.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-244.sbndin.btas.verizon.net) |
| 03:28.19 |
brlcad |
of course it
was a pretty general comment at the time, but hinted at their
specific effort |
| 03:28.41 |
dreeves |
Yeah it would
be good to have the test geometry scaled up |
| 03:29.27 |
dreeves |
do you know
where nurbs_tests.g came from? |
| 03:33.19 |
brlcad |
yes |
| 03:33.20 |
CIA-28 |
BRL-CAD:
03brlcad * r34262 10/brlcad/trunk/include/vmath.h: note that unlike
much of the rest of vmath.h, the input and output vectors cannot be
the same since it's a macro and the values aren't stored/copied for
efficiency. |
| 03:33.31 |
dreeves |
I'm currently
raytracing the perfume bottle from the opennurbs example data it is
relatively pretty large compared to the test geometry I'm seeing
issues but not sure which is the problem. tolerances or the
subdivision or maybe even trimming |
| 03:33.58 |
brlcad |
they were
created in rhino |
| 03:34.40 |
dreeves |
yes |
| 03:34.49 |
dreeves |
oh the
nurbs_test was? |
| 03:34.54 |
brlcad |
yes |
| 03:35.05 |
brlcad |
those objects
were all directly created in rhino |
| 03:35.11 |
dreeves |
oh
ok |
| 03:35.32 |
dreeves |
can you get
trial versions of rhino? |
| 03:35.48 |
dreeves |
will have to investigate that |
| 03:35.51 |
brlcad |
since we
actually use rhino's format (3dm) as our serialized object data, it
just imports directly |
| 03:37.16 |
brlcad |
they do have
evaluation copies |
| 03:38.02 |
dreeves |
I may have to
grab it create some more test geometry |
| 03:38.03 |
brlcad |
the only
limitation is that they've forever been windows-only |
| 03:38.36 |
dreeves |
that is fine
I have a windows laptop to |
| 03:38.38 |
brlcad |
that's
something we could probably do pretty easily |
| 03:39.02 |
brlcad |
more
exhaustive test geometry |
| 03:39.03 |
dreeves |
I wouldn't
mind if someone else wanted to do that |
| 03:39.34 |
brlcad |
yeah, that
should be pretty simple |
| 03:39.49 |
dreeves |
Yeah same
geometries scaled up and make additional geometries that make use
of all the different types of curves and use of the planar
surface |
| 03:39.51 |
brlcad |
I can see if
I can get my seat set up tomorrow |
| 03:40.00 |
dreeves |
awesome |
| 03:40.08 |
dreeves |
that will
save me significant time |
| 03:40.20 |
dreeves |
since I have
no clue how to use rhino |
| 03:40.24 |
brlcad |
the only
problem with the different curve types is that rhino doesn't expose
much of that through the gui |
| 03:40.41 |
brlcad |
they simplify
it way down and do things automagically as they see fit |
| 03:41.05 |
brlcad |
but shouldn't
be too hard to try to coerce a few trimming types |
| 03:41.29 |
dreeves |
yeah I
figured as much |
| 03:41.54 |
dreeves |
really that
is probably the way it should be but would be nice if they had an
expert mode where you could limit that |
| 03:42.51 |
CIA-28 |
BRL-CAD:
03brlcad * r34263 10/brlcad/trunk/ (3 files in 3 dirs): |
| 03:42.52 |
CIA-28 |
BRL-CAD:
remove the mirror_pt 'distance' parameter from rt_mirror() as it
just |
| 03:42.52 |
CIA-28 |
BRL-CAD:
unnecessarily complicates the interface. point+dir are sufficient.
testing |
| 03:42.52 |
CIA-28 |
BRL-CAD:
seems to indicate no change in functionality so hopefully we're
'good to go' |
| 03:43.25 |
dreeves |
yeah d2 is
difficult to get anything useful from it other ability to
scale |
| 03:43.46 |
CIA-28 |
BRL-CAD:
03brlcad * r34264 10/brlcad/trunk/include/vmath.h: vectors, not
points |
| 03:44.13 |
dreeves |
obviously we
want in the end to be able to handle that one but I think there
probably is a couple more test cases that need to be worked before
we tackle that one |
| 03:48.11 |
brlcad |
thinks the recent effort and successes warrant a
posting |
| 03:48.27 |
dreeves |
ok one more
request on the test geometry one object that has some large
components with small components attached i.e. with the attached
i.e. some like an ellipsoid with blended tubes attached such that
the tubes are wider at the bottom and get more narrow as they go up
but not a cone |
| 03:50.37 |
dreeves |
almost like
one of those balls that have the little rubber spines attached all
over it (except the test geometry can just have maybe less than 10
attached at random places) |
| 03:52.01 |
brlcad |
one kush ball
coming up :) |
| 03:52.43 |
dreeves |
thanks |
| 03:52.53 |
dreeves |
:) |
| 03:58.36 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r0 10/wiki/Special:Log/upload: uploaded "[[Image:Brep Perfume
Bottle.png]]" |
| 04:00.49 |
CIA-28 |
BRL-CAD:
03Ddreeves70 07http://brlcad.org *
r1424 10/wiki/BREP_Primitive: /* Current Images of test cases
*/ |
| 04:17.22 |
starseeker |
dreeves,
brlcad - I'll see if I can throw together some more example
geometry - i've got a working rhino copy |
| 04:18.03 |
starseeker |
doesn't have a clue how to use it either, but sufficient
random clicking should produce some thing |
| 04:18.56 |
CIA-28 |
BRL-CAD:
03brlcad * r34265 10/brlcad/trunk/ (12 files in 11
dirs): |
| 04:18.56 |
CIA-28 |
BRL-CAD:
modify mirror's argument handling to make -p be for point and -o be
for offset |
| 04:18.56 |
CIA-28 |
BRL-CAD:
instead of (confusingly) implying 'scalar point value' and
'origin' |
| 04:18.56 |
CIA-28 |
BRL-CAD:
respectively. update the various docs and test cases as found while
we're at it |
| 04:18.56 |
CIA-28 |
BRL-CAD:
including fixing some really out-of-date old docs. FIXME: really
stupid that |
| 04:18.59 |
CIA-28 |
BRL-CAD:
command help is in more than one place in the tcl
sources. |
| 04:30.59 |
*** join/#brlcad rbfish2k
(n=4850fee3@bz.bzflag.bz) |
| 04:40.52 |
*** join/#brlcad rbfish2k
(n=chatzill@pool-72-80-254-227.nycmny.east.verizon.net) |
| 04:41.25 |
rbfish2k |
hello |
| 04:41.46 |
brlcad |
hello
rbfish2k ! |
| 04:41.52 |
rbfish2k |
i am new
here. |
| 04:42.09 |
brlcad |
i've got to
run but there's generally always someone around -- just have to
post a message and wait |
| 04:42.18 |
brlcad |
welcome! |
| 04:42.27 |
rbfish2k |
thanks |
| 04:42.30 |
rbfish2k |
cya |
| 04:42.38 |
brlcad |
heh |
| 04:43.04 |
starseeker |
well, you
tried :-) |
| 04:43.21 |
brlcad |
he's the guy
from the list |
| 04:50.58 |
hippieindamakin8 |
hello
guys |
| 04:59.20 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 06:21.15 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 06:25.20 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 07:29.03 |
mafm |
hi |
| 07:31.03 |
pacman87_ |
hi mafm et
al |
| 07:48.19 |
*** join/#brlcad Mouette
(n=chatzill@140.109.103.226) |
| 08:40.53 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D01F.dip.t-dialin.net) |
| 08:42.27 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D01F.dip.t-dialin.net) |
| 08:50.40 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D01F.dip.t-dialin.net) |
| 10:30.18 |
*** join/#brlcad madant_
(n=madant@117.196.129.91) |
| 10:30.43 |
*** join/#brlcad madant_
(n=madant@117.196.129.91) |
| 10:47.37 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 10:51.41 |
brlcad |
morning to
the d-lo |
| 11:09.15 |
d-lo |
word to the
brlcad! |
| 11:21.12 |
Ralith |
to the bed |
| 11:21.42 |
Ralith |
oh hey
brlcad |
| 11:21.45 |
Ralith |
when do we
find out who got in? |
| 11:22.19 |
Ralith |
oh
wait |
| 11:22.23 |
Ralith |
12
*noon* |
| 11:22.49 |
Ralith |
hopefully awaits! |
| 11:25.26 |
starseeker |
d-lo: did you
ever take a look at argouml? is it any good? |
| 11:27.27 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 11:28.11 |
d-lo |
nope, didn't
try it out. |
| 11:29.56 |
d-lo |
neat, its got
an online version via jnlp... neat! |
| 11:51.43 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 12:03.14 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D01F.dip.t-dialin.net) |
| 12:19.31 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D01F.dip.t-dialin.net) |
| 13:01.25 |
starseeker |
blinks - Oracle bought Sun |
| 13:02.13 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 13:02.24 |
Axman6 |
yah |
| 13:02.27 |
Axman6 |
:( |
| 13:02.52 |
Axman6 |
i was kind of
hoping it's be Apple (though i knew it'd never happen), mainly
because i wanted my next computer to be an UltraSPARC |
| 13:05.28 |
starseeker |
dearly hopes they don't mess with the open source
stuff |
| 13:10.16 |
starseeker |
that's the
part that concerns me the most - Oracle isn't a very visible player
in the open source sphere |
| 13:11.13 |
starseeker |
if they
decide openoffice, java, mysql and solaris don't need to worry
about being open any more... ouch. They could be forked, but
especially in java's case not very effectively |
| 13:11.57 |
starseeker |
<snort>
Oracle's website is "too busy to handle request" for the press
release |
| 13:12.12 |
starseeker |
well, that's
at least one area they could clearly use Sun's help ;-) |
| 13:21.43 |
Axman6 |
heh, yes
indeed :) |
| 13:24.44 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34266 10/brlcad/trunk/include/config_win.h:
drand48() MS Visual C++ replacement |
| 13:26.35 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34267
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: two additional
bu_vls functions to export |
| 13:29.13 |
``Erik |
hm, oracle
buys sun |
| 13:29.36 |
``Erik |
the
announcement page on oracles site gave me an 'unable to connect to
database' error |
| 13:29.41 |
``Erik |
nifty.
shoulda taken a screenshot |
| 13:30.17 |
``Erik |
axman: you
can always buy an old sun... :) |
| 13:30.45 |
Axman6 |
with a T2? i
don't think so :( |
| 13:31.19 |
``Erik |
ah, heh, why
a t2? you could get a IIe or IIi pretty cheap |
| 13:31.58 |
*** join/#brlcad Murielle
(n=Murielle@unaffiliated/murielle) |
| 13:33.46 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34268
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 13:33.46 |
CIA-28 |
BRL-CAD: test
list for non-emptiness to prevent crash on MS Windows |
| 13:33.46 |
CIA-28 |
BRL-CAD: (one
should not increment an iterator pointing to a containers end()
element) |
| 13:34.39 |
*** join/#brlcad madant
(n=d@117.196.129.91) |
| 13:36.57 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34269 10/brlcad/trunk/src/conv/ (8 files in 7
dirs): reorganized CMake files |
| 13:37.24 |
*** part/#brlcad Murielle
(n=Murielle@unaffiliated/murielle) |
| 13:46.47 |
hippieindamakin8 |
``Erik, error
connecting to the db .. lol |
| 13:59.42 |
``Erik |
heheh
http://lambda-the-ultimate.org/node/3133 |
| 14:02.05 |
d-lo |
lol @LISP
aaahahahahahahaha. |
| 14:02.45 |
d-lo |
LISP: She is
an aging beatnik, who lives in a rural commune with her hippie
cousins SMALLTALK and FORTH. |
| 14:06.40 |
Axman6 |
``Erik:
there's been some recent work on getting haskell to perform really
well on the T2 by someone at my uni, which was sponsored by sun,
who also donated a T2 for the work, and i'd love to play with the
massive amounts of parallelism you can get on one |
| 14:07.43 |
starseeker |
d-lo: ah, but
that beatnik is also a zen coding kung-fu master ;-) And like most
such masters, he lives in humble, isolated circumstances
:-P |
| 14:08.41 |
starseeker |
saddles up and heads out |
| 14:09.20 |
d-lo |
starseeker:
yeah, if thats what you need to believe :) Anyways, the whole
'hippie' comment is where I am deriving my chuckles from
hehehehe. |
| 14:13.34 |
starseeker |
actually,
some of the comp.lang.lisp denziens are a rather commercial
business friendly bunch |
| 14:13.50 |
starseeker |
actively
resent open source |
| 14:14.11 |
starseeker |
claim it
destroys markets and jobs |
| 14:25.31 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 14:25.43 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 14:25.43 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 14:36.57 |
``Erik |
would argue that 'commercial business friendly' and 'open
source' are orthogenal; plenty of open source commercial businesses
and proprietary non-commercial efforts |
| 14:41.36 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:43.42 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:52.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 16:07.21 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 16:22.51 |
madant |
~help |
| 16:44.21 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 16:58.23 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 17:01.38 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 17:06.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 17:06.41 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-234-203.dclient.hispeed.ch) |
| 17:17.33 |
hippieindamakin8 |
waits for the results of gsoc to be
announced |
| 17:35.36 |
Ralith |
``Erik:
indeed; it's mostly just the *way* business is done that OSS
threatens. |
| 17:36.14 |
Ralith |
also, nice
oracle error ^^ |
| 17:37.06 |
hippieindamakin8 |
Ralith, i
seemed to miss out on the OSS thingy what is that ? |
| 17:37.17 |
Ralith |
07:38:37 *
``Erik would argue that 'commercial business friendly' and 'open
source' are orthogenal; plenty of open source commercial businesses
and |
| 17:37.20 |
Ralith |
<PROTECTED> |
| 17:37.26 |
Ralith |
ugh, irssi
linebreak fail. |
| 17:37.37 |
hippieindamakin8 |
aah
:) |
| 17:51.50 |
*** join/#brlcad madant (n=d@117.196.140.0) |
| 17:53.38 |
hippieindamakin8 |
hey
madant |
| 17:57.48 |
pacman87_ |
i still
haven't found a good way to scroll in irssi |
| 17:58.01 |
d-lo |
pgup pgdown
work for me... |
| 17:58.24 |
pacman87_ |
those
af |
| 17:58.43 |
pacman87_ |
arent on my
kb |
| 18:00.01 |
pacman87_ |
i was trying
to figure a way to remap some function keys |
| 18:01.07 |
hippieindamakin8 |
yeah pgup and
pgdown work for me too |
| 18:01.51 |
pacman87 |
my ipod touch
keyboard doesn't have pgup/pgdn |
| 18:02.05 |
pacman87 |
i'm ssh'd
into a server, and running irssi in screen |
| 18:02.39 |
hippieindamakin8 |
aah
:) |
| 18:04.21 |
hippieindamakin8 |
pacman87,
cant u just remap the keys on the server ? |
| 18:04.47 |
pacman87 |
how? i tried
messing with inputrc, but couldn't find any docs on the command
syntax |
| 18:06.34 |
hippieindamakin8 |
i forgot the
file .. let me check i had to modify it when installing this
OS |
| 18:08.22 |
pacman87 |
thanks |
| 18:10.22 |
hippieindamakin8 |
pacman87, it
is .xmodmap |
| 18:10.40 |
pacman87 |
i though that
only worked in X? |
| 18:11.49 |
hippieindamakin8 |
oops
:) |
| 18:18.09 |
CIA-28 |
BRL-CAD:
03brlcad * r34270 10/brlcad/trunk/src/conv/Makefile.am: missing the
patch-g.h header from dist |
| 18:21.28 |
hippieindamakin8 |
pacman87,
which OS are u using ? shouldnt there be a keytable config of the
keytable daemon |
| 18:23.03 |
pacman87 |
freeBSD |
| 18:26.40 |
hippieindamakin8 |
pacman87,
"This one is allready in /etc/inputrc and only needs to be
"uncommented": |
| 18:26.40 |
hippieindamakin8 |
# alternate
mappings for "page up" and "page down" to search the
history |
| 18:26.40 |
hippieindamakin8 |
"\e[5~":
history-search-backward |
| 18:26.40 |
hippieindamakin8 |
"\e[6~":
history-search-forward" |
| 18:27.02 |
pacman87_ |
i found
that |
| 18:27.14 |
hippieindamakin8 |
:P |
| 18:27.32 |
pacman87_ |
it maps
pgup/dn to something else |
| 18:27.54 |
pacman87_ |
instead of
something to pgup/dn |
| 18:30.10 |
pacman87 |
i know the
"\e*" codes for the function keys |
| 18:31.33 |
pacman87 |
"\e[18~" and
"\e[19~" for F7 and F8 |
| 18:31.40 |
hippieindamakin8 |
yeah |
| 18:32.08 |
pacman87 |
"\e[18~":page-up |
| 18:32.08 |
pacman87 |
"\e[19~":page-down |
| 18:32.19 |
pacman87 |
that's
currently in my .inputrc |
| 18:32.45 |
pacman87 |
but i was
guessing on the "page-up" and "page-down" commands |
| 18:32.46 |
hippieindamakin8 |
but true that
i couldnt find anywhere to remap the pg up/dn keys |
| 18:33.36 |
pacman87 |
"\e[17~":"F6" |
| 18:33.36 |
pacman87 |
^ that one
works, print out the string when i press F6 |
| 18:48.05 |
pacman87 |
13
minutes... |
| 18:54.04 |
brlcad |
well, want to
thank all of the applicants beforehand regardless of the
results |
| 18:54.19 |
hippieindamakin8 |
:) |
| 18:54.58 |
brlcad |
in the end,
it was pretty tough decision for several applicants that were all
pretty competitive with each other |
| 18:55.40 |
brlcad |
I know it's
certainly starts out as a summer job since you have to put food in
the mouth, but open source is about volunteerism |
| 18:56.21 |
brlcad |
hope everyone
continues to stay involved and contribute, regardless of the
selections |
| 18:56.30 |
hippieindamakin8 |
sure |
| 19:06.43 |
Ralith |
pacman87: try
"\e[18~":"\e[5~" |
| 19:07.46 |
Ralith |
those look
like POSIX escape sequences, so sending one to the terminal might
work as desired. |
| 19:11.52 |
hippieindamakin8 |
pacman87,
madant Ralith : congrats |
| 19:14.42 |
Ralith |
hippieindamakin8: I got in? :D |
| 19:14.50 |
Ralith |
is trying to check the site but keeps getting server
errors |
| 19:15.08 |
starseeker |
hmm - they
seem a bit overwhelmed... |
| 19:15.09 |
hippieindamakin8 |
Ralith, whats
ur name ? |
| 19:15.10 |
starseeker |
ah |
| 19:15.24 |
Ralith |
hippieindamakin8: Ben |
| 19:15.28 |
hippieindamakin8 |
saunders
? |
| 19:15.32 |
Ralith |
yup |
| 19:15.38 |
hippieindamakin8 |
yeah u are
through :) |
| 19:15.41 |
Ralith |
:D:D:D |
| 19:15.45 |
Ralith |
joy! |
| 19:16.45 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 19:16.53 |
hippieindamakin8 |
1. madant 2.
pacman87 3. Ralith 4. Elena 5.joe |
| 19:17.18 |
Ralith |
brb,
celebrating |
| 19:17.49 |
Ralith |
ty for the
notify |
| 19:18.09 |
hippieindamakin8 |
Ralith,
:) |
| 19:18.14 |
madant |
woke up in the middle of the night to find this going
on |
| 19:18.34 |
madant |
well 48
minutes past 12 :P |
| 19:19.03 |
madant |
yippppeeeeeeeeeeeeeee :) |
| 19:19.23 |
madant |
pacman87:
congrats man :) |
| 19:19.36 |
madant |
hippieindamakin8: thanks a lot dude
:) |
| 19:20.01 |
madant |
Ralith: :)
welcome to gsoc ;) you'd be awesome |
| 19:20.06 |
Ralith |
ty
^^ |
| 19:21.10 |
madant |
and congrats
to us too :) +1 slot ;) |
| 19:21.24 |
madant |
d-lo: :) be
gentle with me :) |
| 19:22.03 |
hippieindamakin8 |
madant, that
statement sounded extremely funny (slapstick) in my head
:P |
| 19:22.20 |
d-lo |
SLAVE! BRING
ME COFFEE!!!!! j/k |
| 19:22.28 |
madant |
brlcad: let's
hope this year is more awesome than last one :D |
| 19:22.34 |
Ralith |
d-lo: that'd
be quite a feat of shipping |
| 19:22.56 |
madant |
hippieindamakin8: my grey cells are still
half asleep :D |
| 19:23.24 |
Ralith |
manages to load his projects page |
| 19:23.25 |
hippieindamakin8 |
madant, get
back to your sleep man :) sleep peacefully |
| 19:23.49 |
madant |
:D damn
brlcad still hasn't changed the sleep factoid |
| 19:24.26 |
madant |
hippieindamakin8: when do the exams begin
? |
| 19:24.50 |
hippieindamakin8 |
madant, they
have already started dude. done with one of them 5 left |
| 19:25.55 |
madant |
we should
have had elena and jdoliner out here too :) |
| 19:27.00 |
brlcad |
d-lo:
hehe |
| 19:27.24 |
madant |
ah the man
himself :) |
| 19:27.53 |
d-lo |
Welcome
aboard all! |
| 19:28.06 |
brlcad |
madant: it's
a passing requirement, no? each year *must* be more
awesome |
| 19:28.06 |
d-lo |
hands out mops and buckets. |
| 19:28.08 |
brlcad |
else
FAIL |
| 19:28.15 |
madant |
wonders how awesome MoRe is going to be :) |
| 19:28.32 |
brlcad |
we juuust
miight not call it "MoRe" .. |
| 19:28.33 |
madant |
quickly picks up the mop and bucket :D |
| 19:28.49 |
d-lo |
well, it will
obviously be more awesome. |
| 19:29.14 |
``Erik |
MOAR.brlcad.org ? |
| 19:29.24 |
madant |
d-lo: damn..
it is tough going to be cheating :D |
| 19:29.30 |
starseeker |
favors models.brlcad.org |
| 19:29.31 |
``Erik |
i can has
more geometryburgers? |
| 19:30.26 |
brlcad |
no, but you
can has cheez |
| 19:30.27 |
madant |
seconds starseeker |
| 19:30.32 |
starseeker |
geometryburgers? is this some unit I am
not familiar with? "I have 3 geometryburgers worth of models in
this repository" |
| 19:31.11 |
madant |
hippieindamakin8: all the best for ur
exams dude.. |
| 19:31.12 |
brlcad |
is inclined to separate it from the brlcad.org domain
altogether to let it have self-identity |
| 19:31.16 |
d-lo |
starseeker:
3.14 geometryburgers = 0.125 metric ass tonnes. |
| 19:31.22 |
hippieindamakin8 |
madant,
thanks :) |
| 19:31.32 |
starseeker |
d-lo: aahhh,
of course |
| 19:31.33 |
``Erik |
mmmm apple
pi |
| 19:32.03 |
brlcad |
hippieindamakin8: yeah, good
luck! |
| 19:32.17 |
d-lo |
will vote for models.brlcad.org only if Megan Fox is
involved. |
| 19:32.27 |
brlcad |
heh |
| 19:33.21 |
hippieindamakin8 |
brlcad,
thanks :) |
| 19:33.30 |
madant |
brlcad: any
stats up yet ? total number of projects/students ? at least they
were true to the larger "student peer group per project"
:) |
| 19:33.33 |
hippieindamakin8 |
Megan Fox eh
? :P |
| 19:33.47 |
jonored |
thinks that the reprap and thingiverse should both expose at
least some dublin core metadata, so that we can aggregate the two
and future similar sites sensibly... |
| 19:34.07 |
jonored |
...er...
wrong project. the brlcad database, not the reprap... wrong project
I want to work on. |
| 19:35.26 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || Congratulations to D.Thomas,
E.Bautu, J.Doliner, T.Ruitenbeek, and B.Saunders! || GSoC2009 Next
Step: do the checklist(!), introduce yourself, meet the mentors,
finalize milestones |
| 19:36.19 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || Congratulations to D.Thomas,
E.Bautu, J.Doliner, T.Ruitenbeek, and B.Saunders! || GSoC2009 Next
Step: do the checklist(!), introduce yourself, meet the mentors,
finalize milestones -- coding begins May 23rd |
| 19:38.19 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 19:42.49 |
madant |
jdoliner: let
me be the first to congratulate you :D |
| 19:44.12 |
jdoliner |
thanks
madant |
| 19:44.19 |
pacman87_ |
is there a
wiki page up yet to list the 2009 projects? |
| 19:44.19 |
jdoliner |
I'm very
excited to working with all of you |
| 19:44.46 |
jdoliner |
i'm looking
for one right now |
| 19:44.47 |
pacman87_ |
congrats
all |
| 19:45.06 |
madant |
pacman87_:
don't think so.. :) |
| 19:45.20 |
madant |
pacman87_: i
meant no page ofcourse :D |
| 19:46.28 |
pacman87_ |
it'd be good
toput names, nicks, and projects together |
| 19:47.08 |
madant |
interesting
:) http://socghop.appspot.com/org/home/google/gsoc2009/systers |
| 19:47.24 |
madant |
when do we
have a similar misters org :D |
| 19:49.58 |
d-lo |
Mysters? no
thanks. might as well paint the letters rainbow and include My
Little Pony icons! |
| 19:49.59 |
brlcad |
pacman87_:
yes, the 2009 page is there ready to be populated .. been ready
since application time ;) |
| 19:51.12 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 19:53.13 |
d-lo |
madant:
actually, there already is a community of men involved in
computing. Check it out as it is the largest collection of
computer geeks in the world: http://www.worldofwarcraft.com |
| 19:53.29 |
pacman87_ |
<PROTECTED> |
| 19:53.31 |
madant |
d-lo:
:P |
| 19:53.39 |
mafm |
who's
clifford yap? starseeker? |
| 19:53.51 |
hippieindamakin8 |
madant,
yeah |
| 19:53.59 |
hippieindamakin8 |
*
mafm |
| 19:54.08 |
``Erik |
some
programmer wannabe, he doesn't have face fuzz, so he's not a real
programmer yet |
| 19:54.09 |
``Erik |
:D |
| 19:54.13 |
madant |
howdy mafm
:) |
| 19:54.14 |
d-lo |
must be feelin frisky because i just saw a potential "He's
your daddy" joke... |
| 19:55.14 |
mafm |
congrats to
all applicants, specially to the selected one |
| 19:55.17 |
mafm |
ones* |
| 19:55.47 |
mafm |
I also
observed that brlcad sacrifice himself and chose the girl as
pupil... neat trick :P |
| 19:55.59 |
madant |
:P
neeeet |
| 19:56.02 |
brlcad |
the mentors
aren't set |
| 19:56.04 |
hippieindamakin8 |
:P |
| 19:56.14 |
mafm |
http://socghop.appspot.com/org/home/google/gsoc2009/brlcad
-- here it is |
| 19:56.19 |
brlcad |
i just can't
get in to change anything |
| 19:56.30 |
mafm |
by what nick
goes Joe Doliner? |
| 19:56.39 |
``Erik |
jdoliner |
| 19:56.41 |
brlcad |
probably
jdoliner :) |
| 19:56.48 |
brlcad |
he's tricky
that way |
| 19:56.49 |
``Erik |
real creative
one there ;> |
| 19:56.53 |
madant |
argh some
people type way too fast |
| 19:58.32 |
pacman87_ |
it's ok, i
type slow |
| 19:58.53 |
pacman87_ |
itouch
kb |
| 19:59.30 |
brlcad |
~seen
elena |
| 19:59.33 |
ibot |
elena
<n=ebautu@89.136.118.141> was last seen on IRC in channel
#brlcad, 4d 2h 27m 54s ago, saying: ';)'. |
| 19:59.49 |
brlcad |
hm, that
doesn't seem right |
| 20:00.03 |
brlcad |
~seen
ebautu |
| 20:00.04 |
ibot |
i haven't
seen 'ebautu', brlcad |
| 20:00.22 |
madant |
nice last
words.. er smileys nevertheless :D |
| 20:00.55 |
*** join/#brlcad andax
(n=andax__@d213-102-41-158.cust.tele2.ch) |
| 20:03.02 |
mafm |
lol,
ok |
| 20:03.09 |
mafm |
I thought
that it might be hippieindamakin8 or something |
| 20:03.18 |
hippieindamakin8 |
mafm, no
:) |
| 20:03.27 |
mafm |
hippieindamakin8: didn't get
selected? |
| 20:03.41 |
hippieindamakin8 |
no
man |
| 20:04.26 |
hippieindamakin8 |
mafm, not
this year too :) |
| 20:04.38 |
mafm |
sorry
:( |
| 20:05.13 |
hippieindamakin8 |
unfortunately
this is the last year i am eligible for the gsoc unless i get
through gradschool admissions next year after working for an
year |
| 20:06.19 |
mafm |
well, you'd
better to to Bangalore and get the big bucks! |
| 20:07.41 |
``Erik |
eligible as a
student, ya mean... :D |
| 20:07.44 |
hippieindamakin8 |
mafm,
bangalore hasnt got big bucks anymore thanks to recession
:) |
| 20:08.04 |
hippieindamakin8 |
``Erik, yeah
. But i ll be arnd from now on |
| 20:08.22 |
``Erik |
ghah, parser
error, unhandled condition, aborting |
| 20:08.48 |
hippieindamakin8 |
mafm, moving
to Pune rt now. (waiting for a confirmation from a university in
Sweden too) |
| 20:11.38 |
madant |
hippieindamakin8: what in pune
? |
| 20:12.06 |
hippieindamakin8 |
joining a
firm called tetrahedrix |
| 20:12.25 |
madant |
recollects pune has India's tallest climbing
wall |
| 20:13.10 |
hippieindamakin8 |
is it ?
naice |
| 20:14.38 |
madant |
hippieindamakin8: sweden sounds exotic
;) |
| 20:14.56 |
mafm |
hippieindamakin8: where's "Pune
rt"? |
| 20:15.10 |
mafm |
ah, in
india |
| 20:15.14 |
hippieindamakin8 |
:P lets see.
they dont have projects now . |
| 20:15.17 |
madant |
or as my prof
said when i told him about wanting to do an internship in
Ghana.."ah.. ghana, well how erotic..er. i mean exotic" |
| 20:15.44 |
hippieindamakin8 |
mafm, it is
near bombay / mumbai |
| 20:15.49 |
hippieindamakin8 |
madant,
lol |
| 20:16.56 |
brlcad |
madant:
doesn't nepal have the world's tallest climbing wall? right next
door to india ;) |
| 20:17.30 |
madant |
hahaha.. :)
indeed.. but climbing everest is more a matter of money these
days.. :D |
| 20:18.13 |
madant |
would suck at traditional climbing big time :) too much
equipment to carry |
| 20:21.11 |
madant |
http://adventure.nationalgeographic.com/2008/09/yosemite/midnight-lightning-photosynth |
| 20:24.20 |
brlcad |
so the next
step is to make sure those timelines/milestones look good --
everyone needs to make sure their project is up on the
wiki |
| 20:24.33 |
brlcad |
i'll fill in
the 2009 page with links soon enough |
| 20:25.14 |
madant |
should get back his "little piece of death" to sober
up. |
| 20:28.24 |
brlcad |
heh |
| 20:40.51 |
CIA-28 |
BRL-CAD:
03r_weiss * r34271 10/brlcad/trunk/src/librt/primitives/table.c:
enable partial 'l' support for pnts primitive |
| 21:16.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 21:22.18 |
brlcad |
woot |
| 21:45.24 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D01F.dip.t-dialin.net) |
| 22:15.02 |
``Erik |
wiggles his toes |
| 22:15.44 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 22:15.56 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 22:16.53 |
``Erik |
"it was made
for elvis, but he found it tacky" |
| 22:20.11 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 22:20.11 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 22:20.11 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 22:20.11 |
*** join/#brlcad bjorkintosh
(n=bjork@ip72-204-40-138.fv.ks.cox.net) [NETSPLIT
VICTIM] |
| 22:20.11 |
*** mode/#brlcad [+o brlcad] by
irc.freenode.net |
| 22:41.56 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:47.10 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 23:10.10 |
CIA-28 |
BRL-CAD:
03r_weiss * r34272
10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: for pnts
primitive, added full 'l' command support |
| 23:17.50 |
jdoliner |
is anyone
here william bowman in real life? |
| 23:18.27 |
``Erik |
no, he's more
of a mail list guy |
| 23:19.22 |
jdoliner |
ah, I
see |
| 23:19.51 |
jdoliner |
I can't seem
to find his email anywhere |
| 23:19.55 |
Ralith |
jdoliner: I'm
william bowman in my imagination! |
| 23:20.34 |
jdoliner |
wonderful,
then in you imagination I'm your apprentice |
| 23:20.44 |
jdoliner |
pleased to
meet you |
| 23:21.07 |
jdoliner |
I guess I'll
just introduce myself on the mailing list and have him email me
back |
| 23:21.33 |
``Erik |
ralith: you
don't have the massive goatee or the cigar, you can't be him
:D |
| 23:21.42 |
Ralith |
:[ |
| 23:22.05 |
Ralith |
he sounds
awesome |
| 23:22.59 |
``Erik |
he's a
character O.o (I share an office with him) |
| 23:59.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 00:05.29 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 00:31.07 |
starseeker |
emerges from his first deep dive into the guts of the brep
code - wow there's a lot to soak in here |
| 00:32.22 |
starseeker |
brlcad: Is
it a reasonable strategy for surface "wireframe" visualization of
nurbs surfaces to randomly sample uv space points and plot points
on the real-space coordinates? kinda a "point cloud" for the nurb
surface? |
| 00:33.06 |
starseeker |
maybe not as
a normal viewing mode but for debugging it would be
handy |
| 00:33.26 |
starseeker |
e.g. the
rebuilt sphere |
| 00:35.07 |
starseeker |
is eying EvPoint for this purpose, once he figures out how to
get the uv domain in which to sample... |
| 00:38.57 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:41.26 |
CIA-28 |
BRL-CAD:
03Pacman87 07http://brlcad.org *
r1425 10/wiki/Google_Summer_of_Code/2009: Updated with accepted
proposals |
| 00:41.39 |
pacman87 |
i'm assuming
that's the right page for that |
| 00:42.11 |
pacman87 |
madant,
jdoliner, et al: feel free to add details |
| 00:42.16 |
pacman87 |
http://brlcad.org/wiki/Google_Summer_of_Code/2009 |
| 00:53.46 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1426 10/wiki/Google_Summer_of_Code/2009: /* Hybrid Representation
through BREP on BREP CSG */ |
| 00:54.18 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1427 10/wiki/Google_Summer_of_Code/2009: /* Hybrid Representation
through BREP on BREP CSG */ |
| 00:54.40 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1428 10/wiki/Google_Summer_of_Code/2009: /* Hybrid Representation
through BREP on BREP CSG */ |
| 00:55.29 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1429 10/wiki/Google_Summer_of_Code/2009: /* Hybrid Representation
through BREP on BREP CSG */ |
| 01:00.17 |
brlcad |
pacman87:
yep, thanks! |
| 01:01.31 |
Ralith |
huh, could
have sworn my mentor was starseeker this morning. |
| 01:03.20 |
brlcad |
jdoliner,
Ralith, madant, pacman87 -- please do keep in mind a few things: 1)
conversations should be public, 2) mentoring should similarly be
public especially technical discussions, and 3) your listed mentor
is predominantly for logistically tracking your
progress |
| 01:04.15 |
pacman87 |
Ralith: are
you Benjamin Saunders? |
| 01:04.24 |
brlcad |
i.e., they're
not your "go-to" person for technical discussions -- those really
should be open forums (here and/or irc) where any/other devs can at
least listen in |
| 01:04.30 |
Ralith |
pacman87:
yup. |
| 01:04.56 |
brlcad |
Ralith: he
was, there were a few swap-ups once the website was finally
accessible again |
| 01:05.00 |
CIA-28 |
BRL-CAD:
03Pacman87 07http://brlcad.org *
r1430 10/wiki/Google_Summer_of_Code/2009: |
| 01:05.01 |
Ralith |
ah. |
| 01:05.06 |
pacman87 |
i suppose i
could've deduced that |
| 01:05.06 |
Ralith |
yeah, I
recall you mentioned that we're using group-mentoring |
| 01:05.13 |
Ralith |
plus it's
always good to have such things in everyone's logs |
| 01:05.14 |
brlcad |
not that it
matters who is listed really :) |
| 01:05.25 |
Ralith |
matters that
I'm not going insane ^^ |
| 01:05.35 |
pacman87 |
oh, and time
zones might also be good for that page |
| 01:05.45 |
brlcad |
well, that's
not necessarily proof *against* that fact, Ralith :) |
| 01:05.50 |
Ralith |
hehe |
| 01:06.18 |
pacman87 |
the
"MoRe.brlcad.org 2" makes me curious... |
| 01:06.27 |
Ralith |
pacman87: I
dunno. I suspect I speak for more than myself when I say that my
sleep schedule is strange and unpredictable enough to make timezone
questionably relevant. |
| 01:06.56 |
brlcad |
pacman87: how
so? |
| 01:07.05 |
pacman87 |
not a
descriptive title |
| 01:07.12 |
brlcad |
ah
:) |
| 01:07.13 |
pacman87 |
wondering
what the project actually is |
| 01:07.22 |
brlcad |
knew exactly what that was ;) |
| 01:07.42 |
``Erik |
O.O http://www.mtv.com/ontv/dyn/the_state/series.jhtml |
| 01:07.56 |
brlcad |
she was an
applicant last year that we lost during conflict resolution, hence
the '2' |
| 01:08.21 |
pacman87 |
ah |
| 01:09.04 |
brlcad |
yes, one of
you four got lucky! ;) |
| 01:10.56 |
brlcad |
starseeker:
sure, but if you're going to do that much, why not use the points
to stich them together and display a mesh instead? |
| 01:11.08 |
starseeker |
sure |
| 01:11.14 |
brlcad |
that's all
things like tor do, sample around the surface parameter space and
display a mesh |
| 01:11.27 |
starseeker |
ok, that's
what I want :-) |
| 01:11.51 |
starseeker |
would like rebuilt sphere to actually look like a sphere in
wireframe... call me crazy... |
| 01:11.57 |
brlcad |
even the old
nurbs code does that -- the only trick is not making too many
edges |
| 01:13.12 |
starseeker |
has yet to get it to give him any
points... |
| 01:13.15 |
brlcad |
since you'll
quickly run out of memory or end up with complex wireframes for
trivial shapes that are expensive to display -- want a 'minimal'
mesh that is barely sufficient |
| 01:13.20 |
starseeker |
nods |
| 01:13.39 |
``Erik |
yeah, screen
full of red == bad |
| 01:14.39 |
``Erik |
meshes will
show ya pretty quick how bad it gets (be good to have LoD on
those) |
| 01:15.30 |
brlcad |
we should
eventually sort out a way to manage levels of detail in the
wireframe, so we can have beautifully smooth curves and detail when
it matters along with being able to bring up entire vehicles
without 'e' taking minutes |
| 01:17.06 |
Ralith |
pacman87:
oooh, sweep prims? Awesome! |
| 01:17.22 |
Ralith |
been wanting
those. |
| 01:17.36 |
brlcad |
be nice to
stack automatic LoD on top of it too, so mged or the display
manager could recognize that an object is less than 2x2 pixels in
screen space, for example, so it only displays a dot,
etc |
| 01:18.57 |
``Erik |
and mebbe
look at refresh time to see if level should be tweaked down on slow
machines or up on fast ones |
| 01:19.19 |
brlcad |
nods |
| 01:19.46 |
``Erik |
(overridable,
of course, for when the gurus know what they're doing) |
| 01:20.13 |
starseeker |
OK, here's
something else from Rhino in the nurbs department: http://bzflag.bz/~starseeker/nurbs_shape1.g |
| 01:20.28 |
starseeker |
looks like
this in Rhino: http://bzflag.bz/~starseeker/shape1_rhino.png |
| 01:20.49 |
starseeker |
and
currently looks like this in my raytrace: http://bzflag.bz/~starseeker/shape1.png |
| 01:21.21 |
``Erik |
thinks one of those is broken |
| 01:21.24 |
brlcad |
cool, looks
about the same to me |
| 01:21.31 |
brlcad |
we're
done! |
| 01:21.35 |
starseeker |
hehe |
| 01:21.40 |
brlcad |
oh I see the
problem |
| 01:21.42 |
brlcad |
ours is
red |
| 01:21.42 |
``Erik |
those aren't
the same ae or perspective |
| 01:21.52 |
``Erik |
so it's
impossible to do a pixel comparison |
| 01:21.55 |
``Erik |
(plus one is
red) |
| 01:22.07 |
starseeker |
brlcad: will
that do for a "next step" geometry test or is that a bit
much? |
| 01:22.12 |
brlcad |
matching view
would help |
| 01:22.18 |
``Erik |
c'mon,
starseeker, if you want a pixel comparison, at LEAST get the ae
right |
| 01:22.21 |
brlcad |
it's a bit
much I'd think |
| 01:22.26 |
starseeker |
sigh |
| 01:22.34 |
starseeker |
ok, I'll take
another stab tomorrow |
| 01:22.36 |
brlcad |
i mean keep
it, great test case |
| 01:22.49 |
brlcad |
but about as
complex as the vase it seems |
| 01:22.57 |
starseeker |
ah |
| 01:23.01 |
brlcad |
how many
surfaces? |
| 01:23.21 |
starseeker |
it's two
extruded curves, one subtracted from the other |
| 01:23.29 |
starseeker |
not sure how
it came out surface wise |
| 01:23.33 |
brlcad |
right, but
what did it store? |
| 01:23.38 |
brlcad |
l in mged
should say |
| 01:23.40 |
``Erik |
making each
surface a different color might help |
| 01:23.53 |
starseeker |
5
faces |
| 01:24.04 |
brlcad |
huh |
| 01:24.07 |
brlcad |
counted 4 |
| 01:24.27 |
starseeker |
I may have
messed up in rhino |
| 01:24.36 |
starseeker |
isn't a rhino expert, unfortunately |
| 01:24.37 |
``Erik |
mebbe the
pinches on the inside split the inside into two faces? |
| 01:25.54 |
starseeker |
incidently,
this shape really shows up the limitations of our current
wireframe routine ;-) |
| 01:25.59 |
brlcad |
starseeker: I
would suggest starting with the primitives (again) but more
methodically making test geometry that test varied (non-uniform and
uniform) scaling |
| 01:26.08 |
starseeker |
ok |
| 01:26.54 |
starseeker |
should read the Rhino tutorial this time
:-P |
| 01:27.40 |
starseeker |
really hits the road this time |
| 01:27.45 |
starseeker |
shopping to
do |
| 01:27.47 |
brlcad |
like a sub-mm
sphere, a unit sphere, a 1m sphere, a 1000m sphere, then for each
of those vertically compressed (a flatish disk, maybe in half) and
vertically stretched (a long ellipsoid, maybe
quadruple) |
| 01:28.06 |
brlcad |
then move on
to the next primitive, repeat |
| 01:28.22 |
brlcad |
each one
should be pretty quick to generate, save |
| 01:28.44 |
brlcad |
that should
make sure the tolerances are working right |
| 01:30.17 |
brlcad |
(keep
screenshots of a consistent view in rhino for comparison, like
35/25 or 45/45 |
| 02:43.33 |
*** join/#brlcad rbfish2k
(n=chatzill@pool-71-125-225-196.nycmny.east.verizon.net) |
| 03:26.46 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 04:03.07 |
*** join/#brlcad madant_
(n=d@117.196.142.178) |
| 04:10.12 |
CIA-28 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1431 10/wiki/User:Ralith: Removed now-irrelevant TCL dep removal
proposal. |
| 04:28.12 |
CIA-28 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1432 10/wiki/Google_Summer_of_Code/2009: Linked to OpenGL GUI
proposal |
| 04:36.18 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 04:51.01 |
CIA-28 |
BRL-CAD:
03brlcad * r34273 10/brlcad/trunk/ (NEWS TODO src/libged/mirror.c
src/mged/setup.c): |
| 04:51.01 |
CIA-28 |
BRL-CAD:
restored the mirror command's ability to take a trailing x|y|z axis
option while |
| 04:51.01 |
CIA-28 |
BRL-CAD:
still utilizing the new command wrappers. instead of calling the
edit wrapper, |
| 04:51.01 |
CIA-28 |
BRL-CAD:
though, we just call the view wrapper and do the edit/redraw
ourselves. works |
| 04:51.01 |
CIA-28 |
BRL-CAD: like
a charm. this was specifically requested by victor cericole
for |
| 04:51.04 |
CIA-28 |
BRL-CAD:
efficiency/familiarity, albeit left it intentionally
undocumented |
| 04:53.19 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 05:40.12 |
*** join/#brlcad dreeves2
(n=40b2b147@bz.bzflag.bz) |
| 05:40.35 |
dreeves2 |
~log |
| 05:40.36 |
ibot |
log is, like,
as piece of wood, or a record, or the opposite of exponentiation,
or http://ibot.rikers.org/%23uphpu/ |
| 06:04.24 |
*** join/#brlcad madant
(n=d@117.196.142.178) |
| 06:20.01 |
*** join/#brlcad madant
(n=d@117.196.142.178) |
| 06:52.05 |
madant |
!peak |
| 07:01.09 |
*** join/#brlcad madant_
(n=d@117.196.139.253) |
| 07:25.31 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 07:48.19 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177593350.dsl.bell.ca) |
| 08:51.56 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:52.17 |
*** join/#brlcad madant
(n=d@117.196.137.152) |
| 09:29.40 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EEE3.dip.t-dialin.net) |
| 09:47.48 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 10:19.57 |
d-lo |
mernin
all! |
| 10:32.36 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:34.39 |
mafm_ |
mernin,
d-lo |
| 10:35.11 |
d-lo |
hai mafm!
How goes it? |
| 10:36.46 |
mafm |
http://edu.gulo.org/index.php?option=com_content&view=article&id=47&Itemid=56 |
| 10:37.04 |
mafm |
considering
attending the emacs course |
| 10:37.16 |
mafm |
"Line editors
and the infamous ed -> vi evolution." |
| 10:37.36 |
mafm |
sounds
amazing as a piece of compuer archaeology :P |
| 10:38.06 |
mafm |
"Religion and
text editors" - spiritual enlightening |
| 10:58.30 |
d-lo |
heh:
http://hasthelargehadroncolliderdestroyedtheworldyet.com/ |
| 10:59.00 |
d-lo |
the html
source is a hoot. |
| 10:59.47 |
*** join/#brlcad madant_
(n=d@117.196.128.151) |
| 11:29.29 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EEE3.dip.t-dialin.net) |
| 11:53.45 |
brlcad |
mafm: sounds
like a great course |
| 11:54.58 |
mafm |
brlcad:
kidding, I guess :P |
| 11:55.05 |
mafm |
s/guess/hope/ |
| 11:55.25 |
brlcad |
mafm: heh,
nope |
| 11:55.42 |
brlcad |
that really
does sound like a nice comprehensive overview of emacs |
| 11:57.26 |
*** join/#brlcad LarsG
(n=89840306@bz.bzflag.bz) |
| 11:58.26 |
LarsG |
Hi... anyone
has some time for a short question? I am trying to (mis-)use brlcad
to convert from dxf to iges... |
| 11:58.57 |
brlcad |
dxf-g,
g-iges |
| 11:58.57 |
LarsG |
I manage to
import both the 2d and the 3d content from my dxf, but from
seperate input files |
| 11:59.16 |
brlcad |
ahh, 2D
export to iges isn't probably going to succeed |
| 11:59.17 |
LarsG |
so now, I
have two g.files (databases) that I would have to merge |
| 11:59.27 |
LarsG |
hm |
| 11:59.29 |
brlcad |
the fact that
dxf-g imports 2D is sheer oddity |
| 11:59.41 |
brlcad |
rather, it's
"new" |
| 11:59.55 |
LarsG |
ok, I can
report it to work as import |
| 12:00.06 |
brlcad |
we don't
generally import non-solid objects, but one of the devs added 2D
support for dxf since they closely map to our sketch
objects |
| 12:01.14 |
*** join/#brlcad LarsG
(n=89840306@bz.bzflag.bz) |
| 12:01.25 |
brlcad |
larsG: we
don't generally import non-solid objects, but one of the devs added
2D support for dxf since they closely map to our sketch
objects |
| 12:01.36 |
mafm |
brlcad: would
you go to one such course? I find it pretty un-amusing, spending 1
whole day (8 hours) lerning how to use a diary or connect to jabber
with emacs :P |
| 12:01.37 |
brlcad |
but might as
well give it a try :) |
| 12:02.08 |
LarsG |
I see, so no
chance to get both exported |
| 12:02.22 |
brlcad |
mafm: I know
most of how to do that with emacs already, but yeah I'd consider
it |
| 12:02.28 |
LarsG |
but for
interest, is there a merge-command to merge two
databases? |
| 12:02.31 |
brlcad |
LarsG: I
don't recall frankly |
| 12:02.44 |
brlcad |
what iges
will do with the sketch objects is the big question |
| 12:02.54 |
brlcad |
LarsG: it's
trivial to merge to .g files |
| 12:03.29 |
brlcad |
you can
dbconcat or use mged File->Import or literally 'cat' the two
files together (assuming you don't have name
collisions) |
| 12:03.48 |
LarsG |
ahhh ok, I
was hoping for something like that |
| 12:04.25 |
brlcad |
dbconcat in
mged is the most 'clean' way |
| 12:05.27 |
LarsG |
ok I try
this |
| 12:07.51 |
LarsG |
hm the only
problem now is that I get two times "all" |
| 12:08.19 |
mafm |
brlcad: I'm
only interested in some bits, and especially first and last day
look like a bit ... preposterous? to me, I don't know what's unholy
about ed to vi evolution, and I don't know why you would want to
use emacs instead of proper and efficient tools for some of the
day5 tasks :) |
| 12:11.17 |
LarsG |
ok, I think I
got it by adding prefixes, still the effect is strange. |
| 12:11.31 |
LarsG |
I can either
display the 3d or the 2d stuff |
| 12:12.46 |
LarsG |
if I switch
off the model in the geombrowser, I can display the dimensions, but
when the model is displayed, the 2d objects stay
invisible |
| 12:22.01 |
brlcad |
mafm: first
day is basically history and basics of use -- what makes that
preposterous? |
| 12:23.42 |
*** join/#brlcad LarsG1
(n=lars@as60223.pc.nus.edu.sg) |
| 12:23.44 |
brlcad |
mafm: if you
don't know why, then it sounds like it's probably a good course for
you too -- some of the topics on day 5 are very powerful
facilities |
| 12:24.33 |
brlcad |
the point is
to teach you why |
| 12:25.07 |
brlcad |
perhaps
address many of your preconceived notions, which sound like you
have quite a few of |
| 12:26.46 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 12:27.01 |
brlcad |
howdy
d_rossberg |
| 12:28.23 |
archivist |
if an editor
need a 5 day course then there is some thing wrong with usability
:) |
| 12:28.35 |
brlcad |
or there's
just that much you can do with it |
| 12:29.30 |
brlcad |
very likely
could spend just as much time covering all the things possible with
vim |
| 12:30.10 |
brlcad |
and I know
entire (multi-week) courses that focus around teaching things like
msstudio |
| 12:30.19 |
archivist |
"Keeping
balances and bank transactions" surely an editor is the wrong place
for banking |
| 12:30.25 |
d_rossberg |
good morning
to all |
| 12:30.30 |
brlcad |
it's not an
editor, that's the point |
| 12:30.56 |
brlcad |
it's an
environment, and a programmable one at that |
| 12:32.26 |
d-lo |
mernin
d_rossberg. How goes things? |
| 12:34.00 |
d-lo |
archivist:
Lets put it this way: In the Terminator movies, skynet is actually
a 'mode' of emacs. |
| 12:34.11 |
mafm |
brlcad:
explaining "infamous ed -> vi evolution" doesn't sound right to
me, or "religion and text editors" |
| 12:34.36 |
brlcad |
mafm:
why? |
| 12:34.44 |
mafm |
trollish |
| 12:34.49 |
brlcad |
it's for
better or worse, a HUGE aspect to the history of the
projects |
| 12:35.03 |
brlcad |
there have
been editor "wars" as long as there have been editors |
| 12:35.34 |
brlcad |
a course on
the editor covering the history of how/why it came to pass not
covering those wars would be like covering WWII and leaving out
Germany |
| 12:38.51 |
brlcad |
I certainly
didn't read it as trollish, though I can see how you would have ..
but just further reinforces that it sounds like you're rather
biased with several preconceptions |
| 12:39.47 |
mafm |
dunno, I just
happen to find emacs useful and use it, I don't know why should I
bother with the wars with vi in a course... maybe I just expect
technical aspects and not other considerations :) |
| 12:39.48 |
brlcad |
could
certainly talk about the ed->vi evolution and editor religion
with or without an agenda -- it's history and perspective (that
many people don't have contrary to his 'infamous'
claim) |
| 12:40.51 |
brlcad |
mafm: heh,
well maybe it's just filler, they have a week to fill after all
;) |
| 12:41.37 |
mafm |
I think that
they just enjoy it (I know some of the people and they do use emacs
to connect to IRC and all that) |
| 12:42.27 |
brlcad |
likewise,
friends that use it for email and finances and other purposes ..
and they're impressively efficient at it |
| 12:42.46 |
archivist |
some time you
need the best tool for the job and not a jack of all
trades |
| 12:42.56 |
brlcad |
not my
preference nor a skill set proficiency that I've learned, but
doesn't mean it's wrong either ;) |
| 12:42.59 |
mafm |
mines aren't
terribly efficient at that, though :) |
| 12:44.10 |
mafm |
in fact they
spend time trying to do that instead of working
properly |
| 12:45.06 |
brlcad |
meh, it's
their time to use -- everyone has hobbies |
| 12:45.11 |
mafm |
I can see why
it's useful to show that you can use emacs as an environment, but
you don't have to showcase all those tools for a whole
day |
| 12:45.53 |
*** part/#brlcad LarsG1
(n=lars@as60223.pc.nus.edu.sg) |
| 12:45.55 |
``Erik |
pheer bill
joys hack around ed to make it 'wysiwig', death to the its teco
clusterfuck! :D |
| 12:46.04 |
mafm |
well, one of
them is doing it during working hours, not as hobby, maybe I'm also
a bit biased because of that :P |
| 12:46.55 |
``Erik |
the only
people who think the emacs/vi religious war isn't friendly are the
newbs and outsiders :) |
| 12:47.07 |
brlcad |
many/most
people have hobby-spillover with their work, that was part of the
point |
| 12:47.18 |
brlcad |
if you don't
allow it, you have unhappy unproductive people |
| 12:47.34 |
``Erik |
(emacs is an
interesting lispos for an archaic variant... all it's missing is a
decent editor) |
| 12:47.38 |
brlcad |
what do you
care if you're doing your part -- unless you're an unhappy
unproductive person :P |
| 12:47.44 |
``Erik |
I think I'm
in a couple fortune files saying something like that
O.o |
| 12:48.14 |
``Erik |
(morning,
all) |
| 12:48.24 |
mafm |
I care
because I have to share his part, when he doesn't do it
:D |
| 12:48.54 |
brlcad |
so, unless
you hate your job? |
| 12:49.06 |
brlcad |
in which
case.. you have a bigger problem |
| 12:50.26 |
mafm |
erm, yes,
it's a sunny day around here... |
| 12:50.28 |
brlcad |
i'd take on
any coworker's project in a minute were it not for time conflicts
and competing priorities, it's nearly all fun stuff to work on (the
comp sci parts) |
| 12:51.01 |
mafm |
;) |
| 12:51.02 |
d-lo |
its begining
to sound like brlcad is wasting too much time sleeping and chatting
on irc! |
| 12:52.24 |
d_rossberg |
d-lo: lot of
work here |
| 12:52.27 |
brlcad |
naw, I'm
happy I got mirror 'fixed' |
| 12:52.45 |
brlcad |
digesting the
next move |
| 12:54.57 |
``Erik |
gheh,
digesting :/ shoulda had more than a salad for dinner last
night |
| 12:55.25 |
mafm |
btw ``Erik,
vi doesn't even deserve to be consider a match to emacs, it's so
inferior that it hurts when you pronounce the name, blagh
:P |
| 12:55.36 |
brlcad |
ahh, that
reminds me .. I *did* have salad (caprese) and an amazing
risotto... must get more! |
| 12:55.52 |
``Erik |
heh, vim is
my weapon of choice, emacs is so... gooby |
| 12:56.30 |
archivist |
is raw vi |
| 12:56.32 |
``Erik |
is using both lately, 'slime' is impressive and hasn't tried
the vim equivalent |
| 12:56.51 |
``Erik |
and I've had
to use ed on a few occasions :) |
| 12:56.55 |
``Erik |
the ONE TRUE
EDITOR |
| 12:57.09 |
mafm |
the ONE LINE
AT A TIME true editor |
| 12:57.27 |
archivist |
although on
windaz I use syn |
| 12:57.28 |
``Erik |
erm less so
than emacs O.o |
| 12:57.42 |
``Erik |
on windows, I
use a fbsd install cd |
| 12:57.44 |
``Erik |
O:-) |
| 12:57.55 |
mafm |
wouldn't
people use sed instead of ed nowadays? |
| 12:58.03 |
mafm |
I never
resorted to use ed |
| 12:58.08 |
``Erik |
uhm... ed is
interactive sed |
| 12:58.16 |
d-lo |
add fuel to fire. |
| 12:58.22 |
d-lo |
vi is
stupid. |
| 12:58.30 |
``Erik |
yes, you're
an ide weenie, you know nothing |
| 12:58.30 |
``Erik |
;D |
| 12:59.05 |
mafm |
yeah, a mouse
engineer :P |
| 12:59.14 |
starseeker |
throws some gasoline on the flamewar by saying he likes nedit
:-P |
| 12:59.44 |
starseeker |
nothing like
a good flamewar in the morning to get the blood moving |
| 12:59.54 |
``Erik |
what would
something about visual studio add to the fire? |
| 13:00.15 |
starseeker |
that's beyond
a mere flamewar ;-) |
| 13:00.18 |
``Erik |
is that the
godwin's law of editors? |
| 13:00.29 |
d-lo |
``Erik: I
dunno what throwing pure evil on a fire would do... |
| 13:00.44 |
mafm |
sure, you're
an editor nazi, ``Erik |
| 13:00.48 |
starseeker |
more like the
framewar breaks up with all sides laughing at the idea of visual
studio as an editor... |
| 13:01.04 |
starseeker |
sort of a
"ok, none of us are as bad as that" effect |
| 13:01.37 |
``Erik |
d-lo: I was
reading a website about interviews at MS last night and one of them
was "you're in an 8x8' roomt with no doors and the prince of
darkness appears before you" |
| 13:01.52 |
d-lo |
ahahahahaha. |
| 13:01.57 |
``Erik |
my thought
was to ask "um, is it bill? or is he the king and steve the prince?
I need to know if I have to dodge chairs..." |
| 13:02.06 |
mafm |
time to
retire for my coffee, now that my evil plan to start a yihad here
at #brlcad :P |
| 13:02.21 |
``Erik |
wonders how that would go over at an ms
interview |
| 13:02.34 |
d-lo |
mafm: no
jihad. I am right and everyone else is wrong. Its as simple as
that. |
| 13:03.02 |
``Erik |
emacs and vim
are awfully hard to use when you can only interface a computer via
a 2 button mouse :( |
| 13:03.13 |
mafm |
erm, now that
my plan (rest of phrase) succeeded* |
| 13:03.21 |
d-lo |
``Erik: My
brother in law (aka the guy who is high up on the Silverlight team)
just bought an iPod. His boss glares at him all day :) |
| 13:03.45 |
starseeker |
lololol |
| 13:04.17 |
``Erik |
hehehe, didja
see the surveillance video of the thief who stole a laptop and
shit, stole the headphones off of a zune, but left the zune?
:D |
| 13:04.30 |
d-lo |
``Erik: true,
but if someone doesn't have a keyboard, I would love to see even an
emacs guru be productive ;) |
| 13:05.01 |
``Erik |
I'd love to
see an emacs guru be productive even with a kbd *cough*
O:-) |
| 13:05.37 |
``Erik |
http://digg.com/comedy/Thief_Steals_Everything_But_The_Zune |
| 13:05.47 |
d-lo |
In fact, I
would bet that if a vi/vim guru sat down at a computer without a
keyboard, he would just stare at the mouse with blood running out
of his ears. |
| 13:06.24 |
``Erik |
heh, vi was
made to interface computers without keyboards :D slow-assed
teletype terminals ftw |
| 13:06.30 |
mafm |
lol |
| 13:10.53 |
``Erik |
rubs the sleep from his eyes and tries to figure out which
task to do today |
| 13:11.38 |
brlcad |
adrt client
ftw! |
| 13:12.01 |
``Erik |
yeah, but I
also have to get the forge pki crap done 'real soon
now' |
| 13:12.02 |
``Erik |
:( |
| 13:12.32 |
``Erik |
plus an
abstract for a paper |
| 13:12.38 |
``Erik |
if not a
chunk of the paper heh |
| 13:13.22 |
brlcad |
hey, you said
"today" .. all the rest of that could be done tomorrow |
| 13:14.03 |
``Erik |
given how
long it takes the adrt stuff to instrument for a peek at what it
may be doing, progress there isn't a "today" thing :( |
| 13:16.51 |
``Erik |
might try to twist it into libpkg to make it a little more
coherent |
| 13:17.13 |
brlcad |
would be teh
awesome |
| 13:24.15 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 13:38.06 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 13:50.43 |
*** join/#brlcad madant
(n=d@117.196.133.180) |
| 14:26.47 |
starseeker |
hmm, slashdot
finally noticed gsoc |
| 14:29.28 |
brlcad |
starseeker:
there was an announcement earlier, just didn't make the
headline |
| 14:29.35 |
brlcad |
it was poorly
worded |
| 14:29.58 |
madant |
5th year
after all :) |
| 14:31.02 |
madant |
so not so
much a of NEWs maybe.. |
| 14:36.22 |
_clock_ |
lol |
| 14:36.27 |
_clock_ |
slashdot is
well informed |
| 14:52.21 |
``Erik |
not
especially... the signal/noise ratio has dropped a LOT |
| 14:52.41 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 14:52.43 |
``Erik |
I tend to get
my fix at hacker news ( http://news.ycombinator.com )
now |
| 14:54.44 |
``Erik |
tends to be a
strong "web 2.0" startup crap angle to a lot, but it also has
general nerdiness stuff |
| 14:59.17 |
PrezKennedy |
not much
noise there... not much of anything really... :P |
| 15:02.08 |
``Erik |
it's fast,
they only keep 210 in the 'hot spool', almost everything I've seen
on slashdot for the last several months, I'd seen on that site
earlier |
| 15:06.06 |
brlcad |
pacman87:
http://www.google.com/search?q=sweep+primitive
|
| 15:06.15 |
brlcad |
you are now
apparently the definitive source! :) |
| 15:08.55 |
starseeker |
brlcad:
here's some boxes at different size points: http://bzflag.bz/~starseeker/nurbs_boxes.g |
| 15:13.18 |
starseeker |
will hit spheres next |
| 15:34.54 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 15:38.12 |
starseeker |
various
spheres: http://bzflag.bz/~starseeker/nurbs_spheres.g |
| 15:38.52 |
mafm |
brlcad
sayeth:
http://tech.slashdot.org/comments.pl?sid=1206403&cid=27661197 |
| 16:00.00 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 16:11.11 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 16:36.32 |
*** join/#brlcad dreeves_
(n=IceChat7@64.178.177.71) |
| 16:40.29 |
*** join/#brlcad madant (n=d@117.196.142.7) |
| 16:46.03 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 17:00.41 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 17:20.23 |
*** join/#brlcad madant_
(n=d@117.196.143.43) |
| 17:30.42 |
``Erik |
huh http://nfg.2y.net/games/ntsc/visual.shtm
we suck at blue |
| 17:34.06 |
archivist |
hence we
called it Never Twice the Same Colour over here |
| 17:34.28 |
``Erik |
hey, PAL,
back off :D |
| 17:34.36 |
``Erik |
</pun>
*duck* |
| 17:34.37 |
archivist |
:) |
| 17:34.48 |
archivist |
Perfect All
Lines |
| 17:35.36 |
archivist |
SECAM System
Essentially Contrary to American Method |
| 17:35.37 |
``Erik |
contends that visual quality is irrelevant as long as
programming quality is nonexistant |
| 17:36.34 |
CIA-28 |
BRL-CAD:
03johnranderson * r34274 10/jbrlcad/trunk/ (6 files in 4
dirs): |
| 17:36.34 |
CIA-28 |
BRL-CAD:
Added ArrayCopy class used it in place of some calls to
Arrays.copy(). |
| 17:36.34 |
CIA-28 |
BRL-CAD: This
is to eliminate use of Java 6 specific stuff |
| 17:36.36 |
``Erik |
"can't polish
a turd"? |
| 17:37.40 |
archivist |
I saw some
shiny turds a couple of years ago while out walking |
| 17:38.22 |
``Erik |
quite the
contrarian today, eh? no matter, I'm enjoying a sake buzz, I
believe I'll say "screw bureacracy" and code some |
| 17:39.11 |
archivist |
I was a TV
engineer way back so Im used to the TV systems and all the
crap |
| 17:39.50 |
``Erik |
the tv and
monitor overlay triangles on the average eye sensitivity chart are
kinda depressing |
| 17:40.24 |
``Erik |
especially
considering how much of a persons life is spent staring at
one... |
| 17:41.37 |
``Erik |
http://www.cameraguild.com/technology/images/colorimetry7.jpg |
| 17:56.15 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 18:08.20 |
brlcad |
howdy
jonored_ |
| 18:11.46 |
jonored_ |
Hihi |
| 18:13.42 |
brlcad |
jonored_: you
get brep_curve() working? :)( |
| 18:15.16 |
jonored_ |
I got it what
looks like partially working with calling the opennurbs routines,
but it's very spotty. |
| 18:15.44 |
brlcad |
how
so? |
| 18:15.47 |
brlcad |
how are you
testing it? |
| 18:17.24 |
jonored_ |
Running it on
the sphere from the nurbs_tests.g set that starseeker has. It comes
back with what looks like a random set of pixels filled, and others
not when I run rt -l 4 on it. All the same color, though, which
looks plausible. |
| 18:19.30 |
jonored_ |
http://users.wpi.edu/~jonored/brlcad/nurbs_sphere.png |
| 18:19.34 |
archivist |
``Erik, worse
when you take in the subtractive colour systems (printing
inks/dyes) as well |
| 18:19.53 |
brlcad |
jonored_:
wow, that is pretty wicked |
| 18:20.04 |
brlcad |
likes more
like random data |
| 18:22.53 |
jonored_ |
Red and blue
for the principal curvatures, though? |
| 18:23.21 |
pacman87 |
jonored_: i
think your cloaking technology needs a bit more work, i can still
see it |
| 18:26.42 |
brlcad |
starseeker:
you seen this? http://brlcad.org/tmp/tirechart.jpg |
| 18:26.55 |
brlcad |
figure
probably, but just in case |
| 18:39.31 |
starseeker |
hmm - not
that particular one |
| 18:47.29 |
starseeker |
brlcad: are
you familiar with Qhull? |
| 18:53.06 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-234-64.dclient.hispeed.ch) |
| 18:56.23 |
brlcad |
nope, not
specifically |
| 18:56.35 |
starseeker |
mike pointed
it out to me |
| 18:57.10 |
brlcad |
wow, heh,
that's pretty lame.. their "images" page is a google 'qhull' images
search |
| 18:57.40 |
starseeker |
not sure what
to make of their COPYING.txt file |
| 18:57.49 |
starseeker |
is that LGPL
compatible? |
| 18:59.18 |
brlcad |
incompatible
because of clause 3 and 4 |
| 18:59.29 |
starseeker |
nuts |
| 18:59.37 |
brlcad |
you can't add
new restrictions |
| 18:59.53 |
brlcad |
the other
three are covered by lgpl already |
| 19:00.02 |
starseeker |
other
3? |
| 19:00.10 |
brlcad |
clauses 1, 2,
and 5 |
| 19:00.14 |
starseeker |
ah |
| 19:00.31 |
starseeker |
well, I guess
it's back to GNU TSL then :-) |
| 19:00.38 |
brlcad |
given how
loosely it's worded though and how old it is, you could probably
get them to relicense |
| 19:01.06 |
starseeker |
hmm |
| 19:01.31 |
starseeker |
wonder if
they're better than TSL at triangulation |
| 19:01.35 |
brlcad |
tsltsl? |
| 19:01.53 |
starseeker |
GNU
Triangulated Surface Library |
| 19:02.03 |
brlcad |
ah,
right |
| 19:02.08 |
brlcad |
GTS
:) |
| 19:02.19 |
starseeker |
ah
:-) |
| 19:02.54 |
brlcad |
curious,
what's it for? |
| 19:03.07 |
brlcad |
i mean, what
you're using it for .. not what gts is for |
| 19:03.24 |
starseeker |
dunno - he
just came in talking about the points primitive and mentioned Qhull
as being of interest |
| 19:03.44 |
brlcad |
ah, the
automatically mesh surfaces |
| 19:03.51 |
brlcad |
sure |
| 19:03.52 |
brlcad |
maybe |
| 19:03.52 |
brlcad |
later |
| 19:03.57 |
starseeker |
exactly |
| 19:03.59 |
brlcad |
irrellevant
at this point :) |
| 19:04.05 |
starseeker |
don't know
what put the bee in his bonnet |
| 19:04.21 |
brlcad |
probably was
just talking to richard |
| 19:04.41 |
``Erik |
nnNGSNngs
*kicks stupid fop repeatedly* |
| 19:05.50 |
*** join/#brlcad Sai
(n=42f03c32@bz.bzflag.bz) |
| 19:06.39 |
brlcad |
he's an
armchair thoughtmonger, wouldn't put too much effort |
| 19:06.42 |
brlcad |
tis
distractionary |
| 19:06.52 |
starseeker |
nods |
| 19:07.07 |
starseeker |
uploading new
nurbs examples created so far |
| 19:07.19 |
brlcad |
saw some tire
pictures getting put to use nicely (geoff) |
| 19:07.44 |
starseeker |
cool :-)
yeah, he asked for those a few days ago |
| 19:08.02 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34275 10/brlcad/trunk/src/adrt/adrt.h: use high
bit of mode type to indicate a change in mode |
| 19:10.45 |
starseeker |
ok, what I've
got so far is here: http://bzflag.bz/~starseeker/nurbs_tests/ |
| 19:11.33 |
brlcad |
cool |
| 19:11.48 |
brlcad |
unfortunately, I can't look at them at the
moment because mged is crashing! |
| 19:11.59 |
starseeker |
a couple of
those cases may be too extreme to be reasonable, not
sure |
| 19:12.01 |
starseeker |
uh
oh! |
| 19:12.07 |
starseeker |
latest
svn? |
| 19:12.18 |
brlcad |
yeah |
| 19:12.24 |
starseeker |
builds |
| 19:12.26 |
brlcad |
think it's a
64bit bug |
| 19:12.29 |
starseeker |
ah |
| 19:12.40 |
starseeker |
won't see that here then |
| 19:13.32 |
starseeker |
``Erik: you
could submit a patch to the FOP guys |
| 19:13.32 |
``Erik |
nifty, make
-j8 gives me this in the docbook stuff: 2009-04-21 15:12:15.997
java[7593] CFLog (0): CFMessagePort: bootstrap_register(): failed
1103 (0x44f), port = 0x15803, name =
'java.ServiceProvider' |
| 19:13.48 |
starseeker |
what
the... |
| 19:13.48 |
``Erik |
submit an
effin' patch upside their effin' heads *cough* |
| 19:13.49 |
brlcad |
shudders in horror at the get_dbip command |
| 19:15.17 |
starseeker |
is viewedge.c
the rtedge logic? |
| 19:15.28 |
``Erik |
yes |
| 19:15.32 |
starseeker |
k |
| 19:15.52 |
starseeker |
mumble mumble
weird src/rt build setup... |
| 19:16.04 |
``Erik |
it could use
some serious rewriting, the algo is a bit clumsy |
| 19:16.25 |
brlcad |
the rt apps
are actually rather nice, just not organized clearly
source-wise |
| 19:16.49 |
brlcad |
there's a
front-end that they all use, then they implement view hooks
(rtuif) |
| 19:17.06 |
brlcad |
there's a
tutorial from 2002 that explains |
| 19:18.14 |
brlcad |
aaaand,
there's the bug bob .. |
| 19:18.21 |
brlcad |
ged_dbip must
die |
| 19:20.37 |
CIA-28 |
BRL-CAD:
03brlcad * r34276 10/brlcad/trunk/src/libged/dbip.c: oh my gawd,
this code needs to die. |
| 19:28.19 |
brlcad |
wonders if that made the last release... |
| 19:30.34 |
CIA-28 |
BRL-CAD:
03brlcad * r34277 10/brlcad/trunk/src/libged/dbip.c: |
| 19:30.34 |
CIA-28 |
BRL-CAD: this
is actually in contention for worst hack to date. fix the
underlying bug |
| 19:30.34 |
CIA-28 |
BRL-CAD:
where a pointer is getting serialized to a string (seriously?!),
but it was |
| 19:30.34 |
CIA-28 |
BRL-CAD:
getting truncated to 32-bits (causing a crash on 64-bit platforms).
change the |
| 19:30.34 |
CIA-28 |
BRL-CAD:
casting and go through void to quell warnings. this routine should
not exist. |
| 19:31.04 |
``Erik |
diffs as morbid curiosity takes over |
| 19:32.24 |
brlcad |
the fact that
it's an mged command whose sole purpose is to return the address of
the currently open database instance pointer.. is . just .
wrong |
| 19:33.27 |
``Erik |
should we all
run into his office and point fingers at him with angry
scowls? |
| 19:33.51 |
brlcad |
that's as bad
as a hack I did in bz several years ago, serializing one of our
singletons into our runtime key/value database in order to avoid
using a global |
| 19:34.07 |
``Erik |
ya damn 2-bit
hacks :D |
| 19:34.10 |
brlcad |
no, there's
code to be written and more important things to be done
:P |
| 19:34.57 |
brlcad |
that code
isn't even necessarily something he wrote, it's been there a while,
just was refactored into libged |
| 19:35.14 |
``Erik |
but but
but... pointing fingers... scowling...! |
| 19:35.18 |
brlcad |
and changed
then, which introduced the bug .. but the serialization was still
there |
| 19:35.57 |
brlcad |
if you want
to do something effective, make get_dbip go away :P |
| 19:36.02 |
``Erik |
would still be interested in seeing what a 64b machien does
when main immediately allocates and fills 4g of ram to see if we
really are 64b clean |
| 19:36.17 |
``Erik |
I'm kinda
more thinking about making isst's "cut" work |
| 19:36.42 |
``Erik |
that might
fit ed's view of effective a bit better :D |
| 19:37.29 |
brlcad |
starseeker:
nice, now I can see the boxes :) |
| 19:37.41 |
brlcad |
even the box
exposes some issues apparently |
| 19:37.55 |
brlcad |
submm vs
1000m and the divergence warnings, for example |
| 19:37.57 |
starseeker |
seems to,
unless I just went too wonky on the dimensions |
| 19:38.03 |
starseeker |
ah,
yes |
| 19:38.29 |
brlcad |
is the
importer making regions and assigning red or are you doing
that? |
| 19:44.02 |
starseeker |
the importer
is |
| 19:47.56 |
``Erik |
hey, brlcad,
recall how big our CVS was when we migrated to svn? |
| 20:01.16 |
*** join/#brlcad andax
(n=andax__@d213-102-41-115.cust.tele2.ch) |
| 20:06.27 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34278 10/brlcad/trunk/src/adrt/ (adrt.h
slave/slave.c): use macro instead of magic shift value |
| 20:30.47 |
CIA-28 |
BRL-CAD:
03brlcad * r34279 10/brlcad/trunk/AUTHORS: |
| 20:30.47 |
CIA-28 |
BRL-CAD:
credit peter stiller for his contributions on BRL-CAD helping sort
out curvature |
| 20:30.47 |
CIA-28 |
BRL-CAD:
calculations for implicitly defined surfaces (was a visiting prof
to brl, circa |
| 20:30.48 |
CIA-28 |
BRL-CAD:
1987-1988 according to ed davisson). ed says he was a nice
guy. |
| 20:30.59 |
brlcad |
``Erik:
details on the iwki |
| 20:37.26 |
brlcad |
find
it? |
| 20:40.32 |
brlcad |
ugh, dammit..
there's another pointer getting serialized |
| 20:40.48 |
brlcad |
an
fbp |
| 20:45.49 |
brlcad |
wow, this one
is old |
| 20:45.54 |
brlcad |
Modified Wed
Jan 28 16:01:12 1998 UTC (11 years, 2 months ago) |
| 20:46.02 |
brlcad |
shakes fist |
| 20:51.57 |
``Erik |
oh, didn't
look, need had already passed |
| 20:52.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34280 10/brlcad/trunk/src/mged/attach.c: yet another
fugly serialization that should not exist. the fbp is also getting
truncated here on 64-bit platforms causing a 'mini crash' when the
window is closed. needs to be refactored into oblivion. |
| 20:56.45 |
``Erik |
um, ok,
megatron O.o |
| 21:08.59 |
brlcad |
``Erik: you
remember what name I gave the new server? |
| 21:24.12 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EEE3.dip.t-dialin.net) |
| 21:42.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-208.sbndin.btas.verizon.net) |
| 21:49.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34281 10/brlcad/trunk/src/mged/attach.c: meh, eliminate
mged_fb_close() since it's only used in one place |
| 22:02.24 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
| 22:12.25 |
CIA-28 |
BRL-CAD:
03brlcad * r34282 10/brlcad/trunk/src/libfb/if_X24.c: ws
indent |
| 22:17.16 |
CIA-28 |
BRL-CAD:
03brlcad * r34283 10/brlcad/trunk/src/libfb/ (fb_generic.c
tcl.c): |
| 22:17.16 |
CIA-28 |
BRL-CAD:
refactor fb_close_existing() out of fb_cmd_close_existing() so that
it will |
| 22:17.17 |
CIA-28 |
BRL-CAD:
close a given fbp without needing to serialize/deserialize a
pointer to a |
| 22:17.17 |
CIA-28 |
BRL-CAD:
string. this is (still) horribly divergent from libfb's callback
interface but |
| 22:17.17 |
CIA-28 |
BRL-CAD: none
of the fb-specific *_close_existing() calls are stored in their
interface |
| 22:17.18 |
CIA-28 |
BRL-CAD: FBIO
object. |
| 22:21.59 |
CIA-28 |
BRL-CAD:
03brlcad * r34284 10/brlcad/trunk/ (include/fb.h
src/mged/attach.c): |
| 22:21.59 |
CIA-28 |
BRL-CAD: make
release() call fb_close_existing() instead of serializing the fbp
pointer |
| 22:21.59 |
CIA-28 |
BRL-CAD: to a
string and going through the tcl interpreter just so we can call
the |
| 22:21.59 |
CIA-28 |
BRL-CAD:
fb_close_existing proc with that address, deserialize, then free.
declare |
| 22:21.59 |
CIA-28 |
BRL-CAD:
fb_close_existing(). avoid the fugly. |
| 22:24.36 |
brlcad |
madant_:
someone cheering on libpc on /., hurry up! :) |
| 22:25.33 |
madant_ |
huh :O :D
where |
| 22:39.59 |
madant_ |
ah found it
:) |
| 22:40.13 |
madant_ |
via google of
all things :D |
| 22:43.42 |
madant_ |
hahaha ..
canada : 1.31 gsoc projects per million :D |
| 22:51.14 |
``Erik |
yay for
hail |
| 22:51.42 |
Ralith |
hail's
neat |
| 22:52.53 |
``Erik |
not when it's
tearing up your house and car :D |
| 22:53.02 |
``Erik |
and it's
over |
| 22:53.22 |
madant_ |
and a gsoc
project with no coding :O
http://socghop.appspot.com/student_project/show/google/gsoc2009/google/t124022446589 |
| 22:53.55 |
``Erik |
15 degrees
and 2cm chunks of ice falling from the sky O.o :D |
| 22:54.19 |
Ralith |
``Erik: that
sounds problematic |
| 22:57.03 |
``Erik |
not for me, I
got home and inside a couple minutes before it started |
| 22:57.10 |
``Erik |
and my car is
still in a shop, not outside :D |
| 22:58.16 |
Ralith |
yay! |
| 23:59.20 |
``Erik |
*nomnomnom* |
| 00:38.42 |
brlcad |
branco:
without installing blender? :) |
| 00:58.23 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 01:01.40 |
brlcad |
thinks you maybe meant brl-cad.. what is the exact error? the
ogl interface is disabled by default via configure, though you
"shouldn't" need it |
| 01:15.17 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 01:48.40 |
*** join/#brlcad LarsG
(n=lars@cl0160.pc.nus.edu.sg) |
| 02:43.07 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 02:46.08 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 02:49.09 |
CIA-28 |
BRL-CAD:
03brlcad * r34298 10/brlcad/trunk/src/libged/rt.c: remove and
undeadify code to print raytrace status. Tcl_Eval doesn't belong in
libged, so make the summary as a simple bu_log for now. include
tcl.h regardless as there still are other tclisms that need to go
away. |
| 02:59.52 |
*** part/#brlcad branco
(n=branco@79.114.106.100) |
| 03:15.40 |
CIA-28 |
BRL-CAD:
03brlcad * r34299 10/brlcad/trunk/src/libged/bigE.c: big style
consistency and ws cleanup. |
| 03:33.14 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 04:20.17 |
starseeker |
archer needs
the ogl interface as of latest trunk, iirc |
| 06:47.12 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 07:25.38 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 07:55.26 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:00.31 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 08:05.06 |
*** join/#brlcad minute
(n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT
VICTIM] |
| 08:05.07 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 08:17.04 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 08:44.12 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 08:47.17 |
*** join/#brlcad downstream
(i=jack@unaffiliated/jack) |
| 08:47.29 |
downstream |
morning |
| 08:47.56 |
downstream |
currently
trying to build 7.14.6 on mac os x |
| 08:48.24 |
downstream |
fails at
libTkhtml3.0.dylib |
| 08:48.30 |
downstream |
missing
symbols: |
| 08:48.44 |
downstream |
ld: Undefined
symbols: |
| 08:48.44 |
downstream |
_XCopyArea |
| 08:48.45 |
downstream |
_XFillPolygon |
| 08:48.45 |
downstream |
_XFillRectangle |
| 08:48.45 |
downstream |
_XGetImage |
| 08:49.05 |
downstream |
sounds like
it needs -L/usr/X11R6/lib -lX11 |
| 08:49.31 |
downstream |
wonder why it
builds on linux, though ;) |
| 09:19.17 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34300
10/brlcad/trunk/misc/win32-msvc/Dll/brlcad.def: access to bu
logging |
| 09:26.10 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34301 10/rt^3/trunk/ (3 files in 2
dirs): |
| 09:26.10 |
CIA-28 |
BRL-CAD:
access to libbu's log messaging system |
| 09:26.10 |
CIA-28 |
BRL-CAD: the
default is no log messages at all |
| 09:51.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 10:05.38 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:45.57 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 10:46.30 |
d-lo |
mornin
all |
| 11:15.28 |
*** part/#brlcad LarsG
(n=lars@cl0160.pc.nus.edu.sg) |
| 11:30.39 |
brlcad |
downstream:
that's libXi, missing a -lXi |
| 11:31.20 |
brlcad |
er, never
mind, you're right -- that is -lX11 |
| 11:33.26 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34302
10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: |
| 11:33.26 |
CIA-28 |
BRL-CAD:
bring the core's C++ interface to live by integrating it into the
brlcad.dll |
| 11:33.26 |
CIA-28 |
BRL-CAD: the
raises a question about giving version numbers to rt^3 or
integrating the affected parts into the brlcad branch |
| 11:36.54 |
downstream |
brlcad:
:) |
| 11:37.23 |
downstream |
why does that
-l only get missed on darwin? |
| 11:37.36 |
downstream |
(assuming
that tarball actually builds on linux) |
| 11:39.18 |
downstream |
should i just
add it to LDFLAGS globally? or better hack the
Makefile.in? |
| 11:40.44 |
CIA-28 |
BRL-CAD:
03brlcad * r34303 10/brlcad/trunk/include/bu.h: include the logging
example snippet in the header with a comment about stderr/stdout
possibly changing. |
| 11:41.58 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 11:45.01 |
``Erik |
should work
fine on osX :/ |
| 11:52.52 |
brlcad |
downstream:
without any more information, I'd assume it's some probably with
automake and configure -- did you run autogen.sh? |
| 11:53.52 |
brlcad |
the X11 tests
that are put into configure are dependent on the version of
automake that was available with autogen.sh was first run so if you
have a source tarball, it may be someone else's
automake/autoconf |
| 11:54.01 |
brlcad |
unless you
rerun autogen.sh again |
| 13:07.24 |
``Erik |
huh, soleil
moon-frye got pretty hot O.o |
| 13:13.14 |
downstream |
brlcad: nope,
only ./configure |
| 13:13.55 |
downstream |
i'll try
redoing the autoconf/automake dance |
| 13:51.04 |
brlcad |
downstream:
you just have to run ./autogen.sh |
| 13:51.06 |
brlcad |
no
dance |
| 13:54.25 |
*** join/#brlcad geocalc
(n=geocalc@lns-bzn-37-82-253-36-164.adsl.proxad.net) |
| 14:05.11 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 14:14.25 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F92E.dip.t-dialin.net) |
| 14:43.01 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F92E.dip.t-dialin.net) |
| 15:02.42 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.249.46) |
| 15:07.45 |
*** join/#brlcad dreeves_
(n=IceChat7@64.178.177.71) |
| 15:22.58 |
downstream |
brlcad: same
result, after autogen.sh & configure |
| 15:23.15 |
downstream |
the -I's are
there, the -L/-l is not |
| 16:44.53 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 17:21.26 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 17:22.10 |
*** part/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
| 19:53.40 |
starseeker |
is intrigued by cscope |
| 19:53.57 |
*** join/#brlcad miqlas
(n=Miranda@nat-8.koli.uni-miskolc.hu) |
| 19:54.01 |
miqlas |
Hello! |
| 19:54.11 |
starseeker |
howd |
| 19:54.36 |
miqlas |
The http://brlcad.org/wiki/Building_from_SVN
page contains some interresting links: |
| 19:54.38 |
miqlas |
<a
href=http://www.titizilaclama.com/
title=ilaçlama >Ilaçlama</a> <a href=http://www.etkinilaclama.net
title=Haºere ilaçlama> Haºere ilaçlama</a> <a
href=http://www.cozumilaclama.net
title=böcek ilaçlama> Böcek ilaçlama</a> <a
href=http://www.pire.biz
title=pire>pire</a> <a title=joomla href=http://www.sanaldev.net/indir/joomla>
joomla tema</a> |
| 19:54.45 |
miqlas |
Please,
remove this... |
| 19:54.58 |
starseeker |
hmm, musta
been spammed... |
| 19:55.00 |
starseeker |
checks |
| 19:56.39 |
miqlas |
Thanks. |
| 19:57.46 |
CIA-28 |
BRL-CAD:
03128.63.32.5 07http://brlcad.org *
r1435 10/wiki/Building_from_SVN: Undo revision 1285 by
[[Special:Contributions/78.183.51.7|78.183.51.7]] ([[User
talk:78.183.51.7|Talk]]) |
| 19:58.38 |
starseeker |
thanks for
pointing it out |
| 20:01.02 |
*** join/#brlcad andax
(n=andax__@d213-102-40-181.cust.tele2.ch) |
| 20:08.31 |
*** join/#brlcad miqlas
(n=HAIKU@nat-6.koli.uni-miskolc.hu) |
| 20:08.34 |
miqlas |
Hello. |
| 20:12.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 20:15.06 |
miqlas |
X server
required for running BRL-CAD? |
| 20:18.27 |
starseeker |
not on
windows - on mac and Linux yes |
| 20:22.35 |
miqlas |
I try to
build BRL-CAD on Haiku. |
| 20:24.06 |
starseeker |
uh. Yeah,
you will almost certainly need X |
| 20:24.30 |
starseeker |
doesn't know about the status of things like Tcl/Tk and OGL
on Haiku |
| 20:24.48 |
miqlas |
We have Tk,
but no Tcl :( |
| 20:25.11 |
miqlas |
I can't build
it :( |
| 20:25.40 |
starseeker |
blinks |
| 20:25.49 |
starseeker |
I didn't know
you could build Tk without Tcl |
| 20:26.16 |
miqlas |
Oh, maybe i
mistyped then. |
| 20:26.26 |
miqlas |
I
check... |
| 20:27.19 |
miqlas |
Yes, Sou have
right, i mistyped, we have Tcl, but no Tk. |
| 20:28.31 |
miqlas |
*You* |
| 20:37.09 |
``Erik |
darn, I was
about to be seriously impressed :D |
| 20:56.14 |
brlcad |
strictly
speaking, X11 isn't required even for mac/linux, you just won't get
gui mged |
| 21:04.38 |
*** join/#brlcad miqlas
(n=HAIKU@nat-6.koli.uni-miskolc.hu) |
| 21:11.56 |
*** join/#brlcad miqlas
(n=HAIKU@nat-6.koli.uni-miskolc.hu) |
| 21:16.29 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 21:35.31 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 21:37.27 |
*** join/#brlcad miqlas_
(n=Miranda@nat-8.koli.uni-miskolc.hu) |
| 21:41.15 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:02.13 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 22:04.02 |
*** join/#brlcad miqlas
(n=Miranda@nat-8.koli.uni-miskolc.hu) |
| 22:04.10 |
brlcad |
miqlas: do
you know jorge? |
| 22:04.33 |
miqlas |
Jorge G.
Mare? |
| 22:04.37 |
brlcad |
yep |
| 22:04.45 |
brlcad |
takes that as a "yes" :) |
| 22:04.50 |
miqlas |
Yes,
sometimes i meet with her on the Haiku IRC. |
| 22:05.13 |
miqlas |
i understand
this word: "yep". No problem. |
| 22:05.31 |
miqlas |
His nickname
is koki |
| 22:06.16 |
miqlas |
You know
him? |
| 22:07.35 |
brlcad |
usually
kokito, no? |
| 22:07.54 |
brlcad |
and I mean
you saying his full name was a "yes" |
| 22:08.19 |
miqlas |
koki or
kokito, i thin it is the same. But he use the koki name on the
official Haiku webpage: http://www.haiku-os.org/user/koki |
| 22:08.21 |
brlcad |
I've only
interacted with him and urias on a few occasions, so no I wouldn't
say I know him |
| 22:08.39 |
brlcad |
yeah, just
happens to be kokito on irc iirc |
| 22:09.07 |
brlcad |
loves haiku, loved beos, wants it to be
better |
| 22:09.14 |
miqlas |
Urias
McCullough, ummcullough is a good person too. |
| 22:09.32 |
miqlas |
brlcad want
it with BRL-CAD :) |
| 22:09.33 |
brlcad |
met a few of
the other developers at the gsoc summits |
| 22:09.45 |
miqlas |
Ah, okay, i
understand. |
| 22:10.18 |
brlcad |
I think
brl-cad would be awesome on haiku :) |
| 22:11.12 |
miqlas |
But! It need
an easy to use, and Haiku native user interface, i think. But yes,
first we will happy for an dirty port too |
| 22:11.13 |
brlcad |
just need
someone to port qt over for the new gui! |
| 22:11.51 |
miqlas |
I hope
somebody take up the tk and qt, and port it well for
Haiku. |
| 22:12.19 |
brlcad |
tk should be
pretty easy |
| 22:12.27 |
brlcad |
it used to
have beos support, just a lot of updates |
| 22:13.10 |
miqlas |
Maybe we will
have it: http://dev.osdrawer.net/projects/activity/qt-beos |
| 22:15.14 |
brlcad |
I've wanted
to work on porting apps to haiku .. |
| 22:15.27 |
miqlas |
I don't say
no :) |
| 22:15.28 |
brlcad |
i usually try
about once or twice a year to get something going |
| 22:15.45 |
brlcad |
have been
following for five years or so |
| 22:15.59 |
miqlas |
But i don't
think i can help to You. I know only configure & make &
make install. |
| 22:16.13 |
miqlas |
And we don't
need "-lm" for Haiku. :) |
| 22:16.20 |
brlcad |
but every
time I get bogged down in bugs and crashes, then exhaust all my
time fixing those bugs with the devs :) |
| 22:17.00 |
brlcad |
it's not
until very recently that it's actually been practical and easy to
compile within haiku itself |
| 22:17.32 |
miqlas |
Yes, i
understand. But hey! You don't need wait so long, we almost have an
alpha system. There is the roadmap for it... |
| 22:17.42 |
miqlas |
This is very
close now. |
| 22:18.27 |
brlcad |
nods |
| 22:18.36 |
brlcad |
they were
very close last year too, and I found a half-dozen bugs for them
:) |
| 22:19.02 |
miqlas |
Remember, we
talking about a pre-alpha os.... |
| 22:19.15 |
brlcad |
yep, all in
good fun |
| 22:19.32 |
miqlas |
Please,
forgive it to the Haiku. It will better and better every
day. |
| 22:19.39 |
brlcad |
like I said,
I dug in and helped fix them too |
| 22:20.26 |
brlcad |
at some
point, I'll do an install, open up a terminal and have gcc at my
disposal with a functional networking stack and I'll be able to
really get started on a porting effort ;) |
| 22:21.11 |
``Erik |
cranks up emacs and lisps out with his parens
out |
| 22:21.34 |
miqlas |
:) |
| 22:22.14 |
miqlas |
This will be
my diplom work, if You interrested: http://www.youtube.com/watch?v=JkGzC167GdM |
| 22:22.39 |
miqlas |
Sorry for the
video quality. This is not the final product. |
| 22:23.57 |
``Erik |
are ya gonna
manufacturer one? |
| 22:24.07 |
miqlas |
not
yet. |
| 22:24.26 |
miqlas |
But may the
university make a sample. |
| 22:25.30 |
``Erik |
nice http://www.collegehumor.com/picture:1908328 |
| 22:26.19 |
brlcad |
miqlas:
that's pretty cool |
| 22:26.29 |
miqlas |
Thanks,
brlcad :) |
| 22:26.47 |
brlcad |
wants someone to model a stirling engine in brl-cad as a test
case for the constraint solving system |
| 22:27.29 |
brlcad |
miqlas:
willing to open-source your model? :) |
| 22:27.37 |
miqlas |
Sorry, i
don't have time now for learning BRL-CAD :( |
| 22:27.56 |
brlcad |
would be a
good brep test case too |
| 22:27.59 |
miqlas |
My diplom
work will be published under CC. |
| 22:28.12 |
brlcad |
which
CC? |
| 22:28.25 |
brlcad |
cc-by? |
| 22:28.57 |
miqlas |
Creative
Commons, Noncommercial-Share Alike |
| 22:29.15 |
brlcad |
ah,
darn |
| 22:29.31 |
miqlas |
I think it is
good for diplom work. And if somebody need it, he can make
derivates. |
| 22:29.42 |
miqlas |
brlcad, it is
not good for You? |
| 22:29.46 |
brlcad |
yeah, just
cc-by-nc isn't lgpl compatible due to the nc clause |
| 22:30.24 |
miqlas |
But i don't
like to see my teacher sell my work in his book. |
| 22:30.26 |
brlcad |
it's an okay
license, just problematic for bundling it with brl-cad
directly |
| 22:31.38 |
miqlas |
Ah, but i
think You don't need thousand s page hungarian language text...
Then i can make an anoither package, only the CAD (may without
parametric things) with lgpl compatible license. |
| 22:32.14 |
miqlas |
Or not? I
don't know lot of things about it.. |
| 22:32.21 |
brlcad |
yeah, I don't
care about your thesis so much (no offense, of course)
:) |
| 22:32.39 |
brlcad |
you can do
whatever you want with it assuming you hold the
copyright |
| 22:32.45 |
miqlas |
You need
parametric or non-parametric model? |
| 22:32.46 |
``Erik |
hard to get
into a thesis when ya don't speak the language :D |
| 22:33.04 |
miqlas |
:) |
| 22:33.05 |
``Erik |
(often hard
to get into a thesis when you DO speak the language
O.o) |
| 22:33.33 |
brlcad |
miqlas:
ideally the original files, whatever those are, and then exports in
a few formats (parametric and non-parametric) like step, iges, and
dxf exports |
| 22:34.37 |
brlcad |
looks like
you probably have sldprt,sldasm files |
| 22:34.53 |
miqlas |
The Hungarian
is an very beautifoul language, i think : http://www.youtube.com/watch?v=DGaRnVTLK4Q |
| 22:35.18 |
miqlas |
And we have
muuuuuch lot of bad words than the english or german. |
| 22:35.49 |
archivist |
miqlas, was
that being rotated or does soliworks 2009 do gases and pressure as
well now /me is at 2004 |
| 22:36.06 |
miqlas |
If You like
the traditional musis: http://www.youtube.com/watch?v=PXhLbq-3uNU
(this is the last link, and i don't post more, You can beluive to
me :) |
| 22:36.34 |
brlcad |
miqlas: feel
free to expand my list then! ..
https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/misc/multilingualSwearList.txt |
| 22:36.54 |
brlcad |
hungarian is
rather under-represented |
| 22:37.22 |
Ralith |
lol |
| 22:37.34 |
miqlas |
archivist: ,
i added an virtual motor like thingie, but in the real life it
works by thermal Stirling-cycle. (Isotherm expansion->Isochoric
displacement->Isothermal compression->Isochoric
displacement) |
| 22:37.57 |
archivist |
heh I used to
know turkish and arabic swear words mid 1960's |
| 22:39.03 |
archivist |
miqlas, I
know how they work :) have done pressure diagrams for steam engine
(turbo pascal) |
| 22:39.39 |
miqlas |
Realy? Oh...
I have excel table for it :) |
| 22:40.32 |
archivist |
modelling a
steam engine expansion governor was fun |
| 22:41.35 |
miqlas |
:) |
| 22:42.14 |
miqlas |
My
stirling-engine video is very old, i almost redesigned now in CATIA
V5 (brlcad, the CATIA format will good for You?). |
| 22:43.06 |
archivist |
http://www.archivist.plus.com/website/tour/dynamo.html
that engine but the code is circa win95 , cant run it now
:( |
| 22:43.46 |
brlcad |
miqlas: hm,
catia is probably the hardest to work with (but exports from there
are fine: step, iges, etc) |
| 22:44.17 |
miqlas |
Okay, the i
will give the modell for You in independent format. |
| 22:44.45 |
miqlas |
This is my
CAxx album, but sorry, there is not all of my work (sometimes i
can't put it to here): http://boly.hu/~miqlas/galeria/index.php?album=g-p-szet |
| 22:44.49 |
brlcad |
awesome |
| 22:45.58 |
brlcad |
that
solidedge gear is pretty cool |
| 22:46.24 |
miqlas |
brlcad, here
is my email address: miqlas(_____at_____)gmail(_dot_)com , feel
free to contact me. |
| 22:47.14 |
miqlas |
brlcad: SEv10
is useless. It is an crap. But i was need use this version, because
the university was have only this. I don't like remember for
that. |
| 22:47.27 |
miqlas |
I have video
about that gearbox, if You want see it. |
| 22:48.19 |
brlcad |
nah, the
model itself is what is most interesting :) |
| 22:50.02 |
miqlas |
http://www.youtube.com/watch?v=SYGRiRTyYV0 |
| 22:50.38 |
miqlas |
My Quadro FX
4000 was don't have enough power for it... |
| 22:51.35 |
miqlas |
brlcad, if
You want i can provide the SolidEdge assembly for You. |
| 22:52.00 |
archivist |
does
solidedge have gear mates? |
| 22:52.14 |
miqlas |
I don't know.
I hate the SE. |
| 22:52.35 |
miqlas |
I was need to
use it, but i hate all of the SE products. May, or may not
have. |
| 22:52.44 |
archivist |
ok |
| 22:53.49 |
miqlas |
brlcad, do
You need the assembly. I can give it to You under GPL. |
| 22:54.51 |
miqlas |
CATIA,
SolidWorks is the best, i think (but not for anything). But for me
the most interresthin thing is the FEA. |
| 22:55.28 |
``Erik |
"Jamie
Hyneman Is A Douchebag" http://www.collegehumor.com/video:1908740
yeesh, what a cockbite |
| 22:56.16 |
miqlas |
But i have
the gearbox only in SEv10 academoc format... |
| 22:56.40 |
miqlas |
On the next
week i can convert it to step for You. |
| 23:03.33 |
miqlas |
In the last
semester i have "CAD-technics" subject. And what we learn? Yes,
AutoCAD. Bah! I use it more than 8 years long... But we use it
...SURPRISE.. with commands. not with icons. Oh my God!... I hate
this subject, because i can use AutoCad very well, and i need draw
lot of small drawings, because my teacher don't belive to me..
:S |
| 23:45.09 |
Ralith |
commands? |
| 00:09.27 |
brlcad |
miqlas: does
the SE assembly include all of that geometry? |
| 00:09.46 |
miqlas |
yes, it
include all of them |
| 00:09.55 |
brlcad |
and how about
LGPL? |
| 00:10.02 |
miqlas |
Ralith: with
commands. Typing with keyboard... |
| 00:10.05 |
brlcad |
or
BSD/MIT |
| 00:10.49 |
Ralith |
miqlas:
what's wrong with that? |
| 00:10.57 |
brlcad |
or CC-BY or
CC-BY-SA |
| 00:11.01 |
Ralith |
done right,
that kind of interface can be a big improvement on a
GUI |
| 00:11.10 |
miqlas |
brlcad : it
was an complex work, and if it will good for BRL-CAD You can use it
for free, and with any licenses. You can select the best for
You. |
| 00:11.29 |
brlcad |
miqlas: I
can't select a license unless you public domain it |
| 00:11.34 |
brlcad |
and I dont'
think you should do that |
| 00:11.50 |
miqlas |
Ralith : what
is wrong? nothing, but i don't want make it. :S |
| 00:12.12 |
Ralith |
:P |
| 00:12.13 |
brlcad |
I care mostly
about you getting attribution for the work |
| 00:12.32 |
miqlas |
Okay, you can
make anything with it. This is belong to the community. MIT,
okay? |
| 00:12.34 |
Ralith |
brlcad: I
think he means he'll use what you suggest. |
| 00:12.35 |
brlcad |
beyond that,
I don't mind -- gpl is just problematic because of how it defines a
collective work |
| 00:12.51 |
brlcad |
miqlas: sure,
that works great |
| 00:13.12 |
miqlas |
Then okay.
:D |
| 00:13.21 |
brlcad |
that website
repository could come in handy right now :) |
| 00:13.27 |
brlcad |
where is
elena? :) |
| 00:13.58 |
miqlas |
Now it have
CC license in the package. I need delete the license, or You belive
to me, i give it to community with MIT? |
| 00:14.15 |
brlcad |
(not a
serious question, she's on the road visiting family right
now) |
| 00:14.16 |
miqlas |
And wich
format You want? SEv10 academic, or independent? |
| 00:14.35 |
brlcad |
miqlas: how
big is it? |
| 00:14.44 |
miqlas |
14
Mb. |
| 00:15.52 |
brlcad |
mm, if you
e-mail that to me saying you are sharing it under the MIT license
and I can replace the CC license with the MIT license, I can do the
work |
| 00:16.23 |
brlcad |
otherwise,
you can add a text file with it or something that has a
statement |
| 00:16.29 |
brlcad |
a README or
something |
| 00:16.44 |
miqlas |
Then native
Sev10 (academic!! You can't open it in industrial version!) format
will be good for You? |
| 00:17.07 |
brlcad |
hm, lemme
check on that |
| 00:17.08 |
brlcad |
not
sure |
| 00:17.35 |
miqlas |
I can convert
with academic version for You to step, or anything else
format |
| 00:18.30 |
brlcad |
oh yeah, then
please do -- the SE format itself isn't useful |
| 00:18.37 |
brlcad |
I was just
going to export as well |
| 00:18.49 |
brlcad |
3ds, step,
iges, dxf |
| 00:18.55 |
brlcad |
all
useful/interesting formats |
| 00:19.04 |
miqlas |
Okay. But
here is now 02:18am, and i don't have SE installed. I will send it
for You at morning. Okay? |
| 00:19.06 |
brlcad |
Hmmm....
http://www.sharewareconnection.com/3ds-export-for-solid-edge.htm
|
| 00:19.12 |
miqlas |
Are You
always onine on IRC? |
| 00:19.20 |
brlcad |
miqlas: okay,
no rush and thank you! |
| 00:19.25 |
brlcad |
yeah, I'm
always on irc |
| 00:19.34 |
brlcad |
if I don't
immediately respond, I eventually will |
| 00:19.38 |
miqlas |
Feel free to
give a beer:) |
| 00:19.50 |
brlcad |
will
certainly! |
| 00:19.59 |
brlcad |
hope to have
the opportunity to some day :) |
| 00:20.23 |
miqlas |
;) |
| 00:20.28 |
brlcad |
good grief..
200 bucks for a shareware 3ds exporter, heh |
| 00:20.50 |
brlcad |
especially
given they're probably using openNURBS which did half the work for
them |
| 00:21.26 |
miqlas |
:) good
marketing. |
| 00:23.03 |
miqlas |
But brlcad
you need make something for the cad assembly... |
| 00:23.55 |
brlcad |
hm? |
| 00:24.21 |
miqlas |
Please, make
the BRL-CAD to very portable app. We, at in the Haiku commiunity
don't like if an app have very special requiments. For example not
portable libraryes, flash, or any bloated things. |
| 00:25.03 |
brlcad |
miqlas: we
have historically been one of the most portable pieces of software
out there -- you end up being very portable after 25 years of
development |
| 00:25.06 |
miqlas |
Please, make
the BRL-CAD very nice, and usable, without readin 500
page. |
| 00:25.46 |
brlcad |
like I said,
we should work now on haiku, at least 99% of our codebase should
work just fine |
| 00:26.01 |
brlcad |
the latter
takes a long time |
| 00:26.30 |
miqlas |
I like to see
more app on Haiku platform, to make it usable for wide userbase,
and we need good, stable, and lightweight apps. I know, the BRL-CAD
is a "monster", but i hope on someday it will work correctly with
Haiku. |
| 00:27.12 |
brlcad |
miqlas: think
of it more like 400 lightweight apps, that is how it is
designed |
| 00:27.12 |
Ralith |
BRL-CAD is a
highly portable monster. |
| 00:28.06 |
brlcad |
miqlas: the
fact that we put them all together is more for distribution
convenience, but brl-cad really is a collection of a LOT of
applications .. not just one 'monster' application |
| 00:28.17 |
miqlas |
I read the
comments of the mplayer guys, and an developer told: The BeOS and
Haiku is a C++ crap, and he don't want support it. Please, never
tell anything like this. Lot of people working on this project for
free, and i like this os. |
| 00:28.47 |
brlcad |
heh, not
likely |
| 00:28.58 |
brlcad |
i'm an
old-time beos fan, big fan |
| 00:29.10 |
miqlas |
Then if You
don't tell Haiku will never be supported, You can get the assembly
for free, with MIT. Thanks. |
| 00:29.12 |
brlcad |
seeing it
survive in any form is a 'good thing' |
| 00:29.46 |
brlcad |
used to run beos as his primary desktop back in the
day |
| 00:29.53 |
brlcad |
for the
little while it lasted |
| 00:29.58 |
Ralith |
brlcad: what
attracts you to it? |
| 00:30.07 |
brlcad |
Ralith:
ooof! |
| 00:30.11 |
brlcad |
what
didn't! |
| 00:30.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 00:30.21 |
miqlas |
brlcad, the
BRL-CAD was running on BeOS? |
| 00:31.21 |
miqlas |
Ralith : you
can check it with Your own eyes, download the image, and write it
to Your flashdrive (500 mb is enough) and boot it. It is very
cool. |
| 00:31.42 |
brlcad |
an OS
designed from the ground up ditching most of the baggage we have
today, geared for absurdly high performance, insane interactivity,
impressive filesystem, multithreading dream |
| 00:31.50 |
Ralith |
miqlas: don't
have that much time atm, and I'd be surprised if it supported my
hardware. |
| 00:32.06 |
Ralith |
brlcad:
sounds cool. Insane interactivity? |
| 00:32.09 |
brlcad |
miqlas: haiku
is getting there, but still not yet nearly as impressive as beos
was during r5 |
| 00:32.14 |
``Erik |
fully
threaded micro? |
| 00:32.51 |
miqlas |
Haiku:
http://www.youtube.com/watch?v=ccniJHjo_Uw
and http://www.youtube.com/watch?v=Z7vM1Gc6_po |
| 00:33.05 |
miqlas |
Fully
threaded, and it use microkernel. |
| 00:33.06 |
brlcad |
Ralith: no
matter what you were doing, the system stayed responsive .. nay a
hiccup |
| 00:33.10 |
Ralith |
oo |
| 00:33.11 |
Ralith |
cool! |
| 00:33.13 |
brlcad |
like playing
a half-dozen movies |
| 00:33.17 |
brlcad |
all
simultaneously |
| 00:33.24 |
Ralith |
and haiku is
a reimpl? |
| 00:33.27 |
brlcad |
rendered to
the faces of a spinning cube |
| 00:33.34 |
brlcad |
while playing
music |
| 00:33.34 |
Ralith |
wow, way back
then? |
| 00:33.38 |
Ralith |
jesus |
| 00:33.44 |
brlcad |
and on an all
pentium 200 |
| 00:33.45 |
Ralith |
how did that
manage to fail |
| 00:33.49 |
brlcad |
s/all/old/ |
| 00:33.57 |
brlcad |
marketing and
microsoft |
| 00:34.01 |
``Erik |
toyed with haiku, never tried be itself,
though |
| 00:34.13 |
miqlas |
BeOS (mother
of Haiku) was closed source. |
| 00:34.22 |
``Erik |
bebox was a
neat machine |
| 00:34.36 |
``Erik |
dual cpu when
it was unheard of |
| 00:34.44 |
``Erik |
and awesome
load LED bars on the front :D |
| 00:34.59 |
miqlas |
Yes
:) |
| 00:35.39 |
Ralith |
now you've
got me interested |
| 00:35.39 |
brlcad |
haiku is a
pretty cool reimplementation, it covers almost all of the original
API, included binary compatibility, and has even started to add
their own improvements |
| 00:35.41 |
Ralith |
miqlas: how's
the HW support? |
| 00:35.48 |
miqlas |
BeOS on dual
300Mhz PII: http://www.youtube.com/watch?v=Qv6twfh2SgI |
| 00:36.01 |
brlcad |
that's the
only hard part af the moment, they're not fully stable, but there
is a 1.0 release coming out soon |
| 00:36.09 |
brlcad |
hardware is
hit or miss |
| 00:36.42 |
brlcad |
and their
performance certainly isn't up to par with beos in most areas, but
then they're working mostly on functional first |
| 00:36.42 |
miqlas |
Ralith :
always better and better. It have native sound + OSS, FreeBSD like
net_stack |
| 00:36.47 |
Ralith |
I wish I had
reason to believe alternative OSs had a chance :/ |
| 00:36.59 |
Ralith |
beyond the
unixen./ |
| 00:37.06 |
brlcad |
their API is
still pretty much considered to be one of the best-designed APIs
ever |
| 00:37.42 |
Ralith |
wow damn that
was a fast bootup |
| 00:37.53 |
Ralith |
pretty GUI
too |
| 00:37.54 |
brlcad |
all GUI
applications were inherintly multithreaded for example |
| 00:37.59 |
brlcad |
without the
dev doing anything really |
| 00:38.14 |
miqlas |
I have AMD
3000+ Sempron, 1Gb ram, and Haiku boot up under 3-4
seconds. |
| 00:38.14 |
brlcad |
which kept
all apps responsive even under heavy load |
| 00:39.03 |
Ralith |
wants :( |
| 00:39.07 |
miqlas |
It can use
more core / more CPU. And You can enable/disable them in
runtime. |
| 00:39.14 |
brlcad |
yeah, fast
bootups were a beos philosophy -- it was originally almost
instantaneous (like less than a second), but even less than 5sec to
usable in latter years -- haiku preserves that (woo
hoo) |
| 00:39.49 |
miqlas |
Ralith, if
You interrested, go to #haiku chanel, here on the Freenode
IRC. |
| 00:40.05 |
Ralith |
miqlas: is
there any interest in ELF support? |
| 00:40.18 |
miqlas |
Sorry, i
don't understand. |
| 00:40.28 |
miqlas |
Haiku have
ELF binaries. |
| 00:40.28 |
Ralith |
linux
binaries |
| 00:40.33 |
Ralith |
oo |
| 00:40.34 |
brlcad |
loves the old Be API call..
is_computer_on_fire(); |
| 00:40.38 |
Ralith |
haha |
| 00:40.39 |
Ralith |
wassat
do |
| 00:40.43 |
brlcad |
and the
other, is_computer_on(); |
| 00:40.49 |
miqlas |
BeOS have ELF
binaries too. |
| 00:41.01 |
Ralith |
miqlas: cool!
Is there Any interest in |
| 00:41.01 |
miqlas |
is_computer_on() is cool too. |
| 00:41.02 |
Ralith |
er |
| 00:41.11 |
brlcad |
it returns
the temperature of the motherboard if the computer is on fire
:) |
| 00:41.12 |
Ralith |
is there any
interest in a linux ABI layer? |
| 00:41.13 |
Ralith |
a la
freebsd |
| 00:41.20 |
Ralith |
brlcad: hehe
^^ |
| 00:41.23 |
miqlas |
What is
ABI? |
| 00:41.27 |
brlcad |
the devs had
a fantastic sense of humor |
| 00:41.32 |
Ralith |
awesome! |
| 00:41.32 |
brlcad |
application
binary interface |
| 00:41.45 |
Ralith |
miqlas:
basically, a layer that'd allow linux binaries to run
directly. |
| 00:41.51 |
Ralith |
FreeBSD has
one, and it's handy. |
| 00:42.01 |
Ralith |
it'd make it
much easier for Haiku to pick up new apps., |
| 00:42.03 |
brlcad |
they're a
ways away from that |
| 00:42.05 |
Ralith |
at least in
binary form. |
| 00:42.08 |
miqlas |
Sorry,
Ralith, but i'm not a developer, i can't say anything about it. Ask
the Haiku dev-s on #haiku. |
| 00:42.08 |
brlcad |
it doesn't
run X11 |
| 00:42.24 |
Ralith |
hm. |
| 00:42.26 |
brlcad |
so many apps
would be useless to it anyways |
| 00:42.28 |
miqlas |
I think it is
not a good idea. It will be a monster... |
| 00:42.28 |
Ralith |
it has its
own display stuff, doesn't it? |
| 00:42.42 |
brlcad |
cept for
command-line apps, which are generally easy to port
regardless |
| 00:42.58 |
brlcad |
yeah, sort of
like mac os x having a custom display system |
| 00:42.59 |
Ralith |
I guess a
wrapper API might be feasible, but that's getting to be a
wine-scale project. |
| 00:43.00 |
miqlas |
X11 is
portable, and we have an old X11, but we don't like the apps, that
require X11. |
| 00:43.10 |
brlcad |
yet being
unixy under the hood |
| 00:43.29 |
Ralith |
miqlas: the
problem is, as cool as haiku is, I can't see it ever being of more
than academic interest :/ |
| 00:43.38 |
Ralith |
it's just so
hard for an alternative OS to take off |
| 00:43.51 |
Ralith |
maybe in
twenty years when everyone's using inherently portable
code... |
| 00:43.52 |
brlcad |
nah, it's a
pretty active project with a lot of momentum |
| 00:44.13 |
brlcad |
you don't
hear about it much only because they're working towards that "first
release" |
| 00:44.16 |
Ralith |
does that
mean much, when it comes to wider acceptance, even in the long
term? |
| 00:44.23 |
miqlas |
Ralith: , i
know, this is why i want BRL-CAD for Haiku. |
| 00:44.33 |
Ralith |
miqlas: I
suppose niche environments is a good place to start. |
| 00:44.42 |
Ralith |
make it 'the
ultimate CAD platform' and you'd get users. |
| 00:45.15 |
``Erik |
the fbsd
linuxulator brings its own problem (mostly linux apps being ...
well, wrong... improper ELF format, etc) |
| 00:45.24 |
brlcad |
Ralith: the
philosophies of the operating system itself and the APIs make it
very appealing to most developers |
| 00:45.33 |
Ralith |
``Erik: it
usually works, though. Even on big stuff. |
| 00:45.46 |
``Erik |
after some
fussing to unfuck the binaries, yeah |
| 00:46.04 |
brlcad |
beos had a
pretty substantial developer following, and those devs are still
around -- many will gladly jump back on board with the development
environment is stable enough to work in |
| 00:46.06 |
``Erik |
that i have
to do "brandelf -t linux /some/binary" is bad |
| 00:46.11 |
Ralith |
brlcad: hm, I
imagine that'd help, but, well... look at WinAPI vs. unix APIs.
Quite a big margin, but windows won out originally, and it's taking
ages to win back. |
| 00:46.23 |
brlcad |
until the 1.0
release, it's a bit of a time drain because you have to wade
through other issues |
| 00:46.36 |
miqlas |
I don'tlike
the Linux philosophy, for example there is ProE, but if You have
wrong libc, You can't run, there is lot of branches, lot of
distros, there is no unified thing. |
| 00:46.44 |
Ralith |
miqlas: yeah
linux has lots of problems |
| 00:46.47 |
Ralith |
I'm not
saying it's good. |
| 00:46.51 |
Ralith |
but it's
successful. |
| 00:46.54 |
Ralith |
(and an
improvement on windows) |
| 00:47.43 |
``Erik |
"less bad
than windows", aim for the stars, man ;) *duck* |
| 00:47.52 |
brlcad |
Ralith: it
also depends how you determine "won out" .. if you're talking about
massive > 50% popularity, sure -- in that regard unix was never
really even a contender |
| 00:48.20 |
brlcad |
old mac os
(before os x) was the only real contender, and be os for all of a
year |
| 00:48.44 |
brlcad |
latter being
arguable at that |
| 00:48.51 |
Ralith |
brlcad: well,
I can't easily see a fourth unique OS easily making more than
1%. |
| 00:49.09 |
``Erik |
you're gonna
irk an amiga fan somewhere talkin' like that, brlcad :) |
| 00:49.14 |
Ralith |
lol |
| 00:49.21 |
brlcad |
good! |
| 00:49.29 |
brlcad |
people should
be irk'd more about their OS |
| 00:49.46 |
brlcad |
they waste a
lot of our time, more than many of the apps run on them |
| 00:50.29 |
Ralith |
heh |
| 00:50.44 |
miqlas |
Guys, what
You think about CATIA V6? |
| 00:50.58 |
Ralith |
In Jan 31,
2009, Haiku obtained a native GCC4 port; this allows modern
applications, like Firefox 3, to be built on Haiku. |
| 00:51.01 |
Ralith |
ooooh. |
| 00:51.02 |
``Erik |
windows has
set the bar awfully low :( it's not acceptable to have to pop the
hood and fiddle with the engine every time you want to drive
somewhere, or bust out the multimeter whenever you want to watch
tv... but *shrug* |
| 00:51.14 |
Ralith |
``Erik: I
agree. |
| 00:51.17 |
Ralith |
but it's
where we are. |
| 00:51.24 |
brlcad |
miqlas: about
the same as what I think about a tree stump |
| 00:51.50 |
miqlas |
What You
think about the tree stump? |
| 00:51.52 |
brlcad |
kind of an
open-ended bait question :) |
| 00:51.58 |
``Erik |
you... want
to build a treehouse on catia? |
| 00:52.00 |
brlcad |
depends
entirely what we're talking about |
| 00:52.23 |
miqlas |
BRL-CAD is
parametric or not? |
| 00:52.42 |
brlcad |
no,
parametric support is being worked on now |
| 00:52.48 |
brlcad |
~seen
madant |
| 00:52.50 |
ibot |
madant
<n=d@117.196.133.180> was last seen on IRC in channel
#brlcad, 2d 10h 21m 48s ago, saying: 'so not so much a of NEWs
maybe.. '. |
| 00:52.54 |
miqlas |
Wow! I like
the parametric modelling. |
| 00:52.56 |
brlcad |
by that
guy |
| 00:53.42 |
brlcad |
this is his
work planned for this summer: http://brlcad.org/wiki/User:Homovulgaris |
| 00:53.53 |
miqlas |
Is tehere any
kinematic solver in BRL-CAD? |
| 00:53.57 |
brlcad |
(low-level
developer speak) |
| 00:54.05 |
brlcad |
there is a
very very basic one |
| 00:54.47 |
``Erik |
the joint
constraint stuff? |
| 00:54.48 |
brlcad |
it's a basic
forward-kinematic system |
| 00:54.50 |
brlcad |
yeah |
| 00:57.56 |
miqlas |
brlcad:
thanks for the informations, an Guys thanks for the talk. But now
here is 02:57. |
| 00:58.00 |
miqlas |
I need to
sleep. |
| 00:58.03 |
Ralith |
seeya |
| 00:58.17 |
brlcad |
cya |
| 00:58.55 |
miqlas |
brlcad :
morning i try to convert the assembly to step,and i send to
You. |
| 00:59.24 |
brlcad |
okay,
awesome |
| 00:59.27 |
``Erik |
night, miqlas
:) |
| 00:59.37 |
miqlas |
Night for
everybody. |
| 01:00.55 |
Ralith |
damn, haiku
looks really cool. |
| 01:01.01 |
Ralith |
wants to play with it now. |
| 01:01.02 |
miqlas |
;D |
| 01:01.10 |
Ralith |
hmm. |
| 01:01.21 |
Ralith |
does anyone
know if AMD ever made good on their promise to open their hardware
docs? |
| 01:01.31 |
Ralith |
for the video
cards |
| 01:01.36 |
Ralith |
for 3D
accel |
| 01:02.08 |
miqlas |
Ralith: :
http://www.haiku-os.org/community/forum/how_to_install_haiku_to_usb_flash_drive_from_windows |
| 01:02.47 |
Ralith |
miqlas: I'm
not on windows :P |
| 01:02.50 |
Ralith |
unfortunately. |
| 01:03.24 |
Ralith |
is there a
list of supported hardware out there anywhere? |
| 01:03.31 |
``Erik |
grab qemu and
set it up with something boring? :) |
| 01:03.45 |
Ralith |
hehe |
| 01:03.46 |
miqlas |
sudo dd
if=haiku.image of=/dev/sda (SDx is a DEVICE, not a
partition!!) |
| 01:03.50 |
Ralith |
that's not as
fun as running it natively |
| 01:04.04 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 01:04.05 |
Ralith |
miqlas: I'd
rather not overwrite my system. |
| 01:04.29 |
miqlas |
Ralith :
http://haikuware.com/hardware-database/ |
| 01:06.45 |
miqlas |
My Haiku
desktop: http://mellbimbo.eu/view-d77595203e5fcf31336d52acff527378.html |
| 01:06.46 |
``Erik |
huzzah, my ld
is brokne |
| 01:06.53 |
Ralith |
miqlas: can
it, theoretically, do 3D accel? |
| 01:07.02 |
Ralith |
assuming
someone writes a driver |
| 01:07.19 |
miqlas |
There is
software and hardware accelerated (Nvidia) OGL. |
| 01:07.37 |
miqlas |
Software
powered by MESA. |
| 01:07.42 |
Ralith |
...WHAT |
| 01:07.48 |
Ralith |
how did they
pull that off |
| 01:08.01 |
miqlas |
Sorry, i
don't understand. |
| 01:08.08 |
Ralith |
how did they
get 3D accel on nvidia hw? |
| 01:08.18 |
miqlas |
It is a magic
:) |
| 01:08.25 |
Ralith |
explainnnnn |
| 01:09.06 |
miqlas |
MESA software
rendering attached to low level nvidia driver, |
| 01:09.12 |
Ralith |
no I
mean |
| 01:09.16 |
Ralith |
how did they
write an nvidia driver |
| 01:09.21 |
Ralith |
that's
undocumented hw |
| 01:09.25 |
brlcad |
miqlas: heh,
cute desktop |
| 01:09.28 |
miqlas |
Reverse
engineering is the answer. |
| 01:09.36 |
Ralith |
that's some
crazy reverse engineering |
| 01:09.42 |
Ralith |
how many
cards does it support? |
| 01:10.23 |
miqlas |
Another
desktop by me: http://mellbimbo.eu/view-f823600c444123689f6a1864e8e812bd.html
(old!) |
| 01:10.38 |
miqlas |
Up to 8600Gt,
if i know correctly. |
| 01:11.34 |
Ralith |
jesus |
| 01:11.40 |
Ralith |
both my
laptop and my desktop would be supported! |
| 01:11.48 |
Ralith |
I'm totally
installing this in dual-boot if I can work out how |
| 01:12.25 |
miqlas |
Ralith :
http://haiku.it.su.se:8180/source/xref/src/add-ons/kernel/drivers/graphics/nvidia/driver.c
<- supported cards. |
| 01:12.30 |
Ralith |
ty |
| 01:12.40 |
Ralith |
er |
| 01:12.41 |
Ralith |
AGP
:| |
| 01:12.47 |
Ralith |
no
PCIe? |
| 01:13.58 |
brlcad |
Ralith: keep
in mind .. this is basically "pre-alpha" |
| 01:14.04 |
Ralith |
brlcad: I
know |
| 01:14.18 |
Ralith |
I'm utterly
amazed it has nvidia support |
| 01:14.40 |
Ralith |
just thinkign
about how awesome it'd be to have full accel., |
| 01:14.42 |
miqlas |
I don't have
PCIe, only AGP, but i tested my roomates's computer, it works with
PCIe |
| 01:14.47 |
Ralith |
ooo |
| 01:14.54 |
Ralith |
:D |
| 01:15.19 |
Ralith |
any tips on
rigging grub up for it? |
| 01:15.40 |
miqlas |
Ralith: ,
sorry i don't understand Yopu :( |
| 01:16.00 |
Ralith |
grub's a
bootloader suitable for dualbooting |
| 01:16.24 |
miqlas |
Yes, but i
never tested it with Haiku. I thin it require chainload
setting. |
| 01:16.43 |
Ralith |
any docs you
can point me at? |
| 01:16.51 |
Ralith |
I'm eager to
try this, but not so much to make my system unbootable
>_> |
| 01:17.07 |
Ralith |
though I
suppose only so much can go wrong if I get the partition resizing
right |
| 01:17.23 |
miqlas |
http://www.haiku-os.org/documents/dev/installing_haiku_to_a_partition_from_linux |
| 01:17.48 |
Ralith |
perfect! |
| 01:17.49 |
Ralith |
thanks. |
| 01:18.13 |
Ralith |
now I just
need to find some time to tweak my partition scheme. |
| 01:18.35 |
miqlas |
This tell,
how to build, but You don't need build it, there is precompiled
images on the net here: http://haiku-files.org/raw/ |
| 01:19.06 |
Ralith |
oo,
nightlies |
| 01:19.30 |
Ralith |
brbs for food |
| 01:20.13 |
miqlas |
Nvidia
informations:
http://haiku.it.su.se:8180/source/xref/src/add-ons/kernel/drivers/graphics/nvidia/README.html |
| 01:20.42 |
miqlas |
last updated
on June 10, 2008... |
| 01:20.49 |
miqlas |
Night,
Guys! |
| 01:21.09 |
miqlas |
Ralith : be
careful, don't make a brick from Your computer :) |
| 01:29.44 |
*** join/#brlcad LarsG
(n=lars@nusnet-216-60.dynip.nus.edu.sg) |
| 01:34.20 |
yukonbob |
hello,
cadheads |
| 01:45.17 |
Ralith |
miqlas: so
long as it doesn't scramble my nvram or something. |
| 01:52.41 |
*** join/#brlcad dreeves_
(n=IceChat7@64.178.177.71) |
| 02:38.06 |
*** part/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 02:38.15 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 03:17.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 03:33.18 |
*** part/#brlcad LarsG
(n=lars@nusnet-216-60.dynip.nus.edu.sg) |
| 04:26.03 |
starseeker |
Ralith: one
thing to remember about Haiku - if Gtk/Qt are ported to it cleanly,
that gives you a LOT of the better open source programs almost for
free. |
| 04:26.23 |
Ralith |
true. |
| 04:26.34 |
starseeker |
the
difficulty with one "free" OS taking on another is usually the
"user experience" is the same |
| 04:26.46 |
starseeker |
e.g.
Gnome/KDE/Windowmaker/etc. on top of X |
| 04:26.53 |
Ralith |
not so,
here. |
| 04:27.07 |
starseeker |
mm? |
| 04:27.23 |
Ralith |
er, haiku
doesn't use those. |
| 04:27.27 |
starseeker |
right |
| 04:27.28 |
Ralith |
unless I'm
drastically misled. |
| 04:27.39 |
Ralith |
plus there's
the whole instaboot thing |
| 04:27.45 |
starseeker |
that's the
key - it is potentially a radical improvment in desktop
experience |
| 04:27.57 |
Ralith |
yeah, I think
it's really got my attention. |
| 04:28.12 |
Ralith |
looks like
it, infact, does *not* have 3D accel anywhere yet,
though. |
| 04:28.26 |
Ralith |
no surprise,
but it'd've been neat |
| 04:28.37 |
starseeker |
X plus
$KERNEL "feels" the same - BeOS gui + massive multithreading is
better :-) |
| 04:28.37 |
starseeker |
ah,
right |
| 04:28.47 |
starseeker |
would not expect 3D accel yet |
| 04:29.19 |
starseeker |
even on Linux
that only works "well" with nvidia drivers |
| 04:29.23 |
Ralith |
indeed. |
| 04:29.31 |
Ralith |
though I
imagine it won't be long till the AMD docs are
implemented. |
| 04:29.38 |
starseeker |
grins |
| 04:29.40 |
Ralith |
? |
| 04:29.46 |
starseeker |
that will be
AWESOME |
| 04:29.54 |
Ralith |
er,
why? |
| 04:29.59 |
Ralith |
I mean, more
hardware support is good and all... |
| 04:30.08 |
starseeker |
will make his next graphics card purchase an AMD card if they
do have proper open drivers |
| 04:30.20 |
Ralith |
I suppose it
is a pretty big first. |
| 04:30.27 |
Ralith |
it looks like
there's an effort to port gallium3d to haiku |
| 04:30.38 |
Ralith |
so I'm hoping
that someone'll port the AMD drivers to that, once they
exist |
| 04:30.45 |
Ralith |
and then the
haiku devs won't have to do anything else |
| 04:30.52 |
Ralith |
they seem to
be taking a very pragmatic attitude to hardware support |
| 04:31.01 |
starseeker |
oh, I should
think that'll be a logical (in fact, THE logical)
target |
| 04:31.24 |
starseeker |
the only
other candidate is probably opengraphics, if they ever get off the
ground |
| 04:31.25 |
Ralith |
ported OSS
for sound, wrapping FreeBSD drivers for wifi and
networking... |
| 04:32.06 |
Ralith |
starseeker:
that's their own hardware, isn't it? |
| 04:32.15 |
starseeker |
which,
opengraphics? |
| 04:32.17 |
Ralith |
yeah |
| 04:32.48 |
starseeker |
that's these
guys: http://wiki.opengraphics.org/tiki-index.php |
| 04:32.55 |
Ralith |
yeah, I'm
looking |
| 04:32.59 |
Ralith |
looks like
hardware to me |
| 04:33.03 |
starseeker |
yep |
| 04:33.18 |
Ralith |
that'd be
neat but, well, I doubt it'll compare to the big two's
products. |
| 04:33.26 |
starseeker |
won't be up
to latest AMD/NVIDIA specs, but a truly open and well supported
driver would be Very Nice |
| 04:33.35 |
Ralith |
indeed. |
| 04:33.43 |
Ralith |
but only for
a subset of uses. |
| 04:33.43 |
starseeker |
particularly
with regards to stability |
| 04:33.47 |
starseeker |
sure. |
| 04:33.56 |
starseeker |
but that
subset probably includes most desktop level effects |
| 04:34.01 |
Ralith |
true,
true |
| 04:34.03 |
starseeker |
ala
enlightenment bling |
| 04:34.09 |
Ralith |
enlightenment
runs in software :P |
| 04:34.16 |
starseeker |
for now
:-) |
| 04:34.16 |
Ralith |
at least,
last time I checked. |
| 04:34.30 |
Ralith |
but yes,
bling is good. |
| 04:34.32 |
starseeker |
iirc, he
claims to get better performance that way because linux 3d support
sucks so bad |
| 04:34.40 |
Ralith |
heh |
| 04:34.44 |
Ralith |
actually |
| 04:34.46 |
Ralith |
I talked with
a dev about it |
| 04:34.51 |
Ralith |
it's not cuz
linux 3d support sucks, iirc |
| 04:34.58 |
starseeker |
oh
really? |
| 04:34.59 |
Ralith |
it's cuz
running multiple OpenGL contexts in parallel sucks I
think? |
| 04:35.03 |
starseeker |
ah |
| 04:35.20 |
Ralith |
cuz all
hardware is designed on the assumption that there's only
one |
| 04:35.23 |
Ralith |
even though
that's not spec |
| 04:35.46 |
starseeker |
enter
opengraphics - where you can fix the design yourself
:-) |
| 04:36.15 |
starseeker |
has a hope that a working opengraphics design might be
(eventually) compressed to be a sort of default "on motherboard"
option |
| 04:36.34 |
starseeker |
vga on
steroids or some such |
| 04:36.54 |
starseeker |
then you can
add in the big bad commercial boys for heavy duty 3D
accel |
| 04:37.56 |
starseeker |
interesting
statement here:
http://www.fsf.org/blogs/community/help-the-open-graphics-project |
| 04:38.05 |
starseeker |
has also had thoughts about "fully open"
computers |
| 04:39.46 |
starseeker |
heh - someone
should design a computer case as an open cad model |
| 04:40.52 |
Ralith |
that wouldn't
be hard |
| 04:40.59 |
starseeker |
well, a good
one would take some work |
| 04:41.00 |
Ralith |
especially if
you didn't mind how it looked |
| 04:41.09 |
starseeker |
it must look
awesome :-) |
| 04:41.14 |
Ralith |
aw. |
| 04:41.57 |
starseeker |
call it...
OpenCase ;-) |
| 04:43.44 |
starseeker |
then you
could use an OpenSparc cpu - make an "OpenSparc Inside" sticker
:-P |
| 04:44.05 |
starseeker |
wonders if anyone manufactures those, come to think of
it |
| 04:48.29 |
starseeker |
via has the
OpenBook model, but that's for a laptop |
| 04:48.35 |
starseeker |
also need a
desktop |
| 04:50.54 |
Ralith |
still, pretty
good start. |
| 04:51.28 |
starseeker |
it
is |
| 04:51.35 |
starseeker |
a LOT of
pieces needed though |
| 04:51.39 |
Ralith |
especially
considering the corporate backing. |
| 04:51.47 |
Ralith |
true, but we
seem to be on the way... |
| 04:51.59 |
starseeker |
for a truly
open motherboard, for example, would need... |
| 04:52.09 |
starseeker |
open RAM
chips |
| 04:52.16 |
starseeker |
open CPU
socket design |
| 04:52.24 |
Ralith |
open ICs in
general seems like it'd be kind of hard :/ |
| 04:52.47 |
Ralith |
unless a
cascade of openness sweeps across the hardware industry |
| 04:53.51 |
starseeker |
well you
would need at least one of every key part of the system |
| 04:53.59 |
starseeker |
openhardware
has some |
| 04:55.18 |
starseeker |
even if you
had all the designs, the trick would be getting the parts
made |
| 04:55.25 |
starseeker |
the up front
costs are huge |
| 04:56.30 |
starseeker |
maybe someday
though - there are still some really good hardware hackers lurking
out there |
| 04:56.35 |
Ralith |
yeah, which
is why I don't see it happening unless someone talks the
corporations into it. |
| 04:56.39 |
starseeker |
nods |
| 04:56.44 |
Ralith |
but that's
been done before. |
| 04:56.47 |
Ralith |
many
times. |
| 04:56.56 |
Ralith |
albeit not
inhardware, most cases. |
| 04:56.59 |
Ralith |
but hey, then
there's via! |
| 04:57.31 |
starseeker |
it would
probably need to be someone who needed the component for some
non-traditional purpose and was willing to do an open design to get
it cheap |
| 04:58.20 |
starseeker |
if the Haiku
guys can eventually get the old BeOS performance on low(er) end
hardware, it might help to make a truly open computer
viable |
| 04:58.35 |
Ralith |
any old BeOS
devs working on the project? |
| 05:00.31 |
starseeker |
dunno |
| 05:01.19 |
starseeker |
one idea I'm
sorry no one put forward before Oracle bought Sun was to suggest
Sun expand its open hardware program to include entire older
generation PC specifications |
| 05:01.33 |
starseeker |
Ralith:
probably old BeOS devs would have IP issues |
| 05:02.25 |
Ralith |
the people
who might care are still around? |
| 05:02.43 |
starseeker |
you mean BeOS
devs? |
| 05:02.55 |
starseeker |
or you mean
Oracle/Sun? |
| 05:03.04 |
Ralith |
BeOS |
| 05:03.15 |
Ralith |
of course the
people who care about open hardware are around :P |
| 05:03.37 |
starseeker |
sure - but
I'm guessing Sun would have been more willing to entertain the idea
before they got bought |
| 05:04.03 |
starseeker |
I'd imagine
there are some of the old BeOS devs floating around, but I don't
really know |
| 05:04.14 |
starseeker |
eeek. OK,
must sleep now |
| 05:05.37 |
Ralith |
kk,
night |
| 06:32.26 |
*** join/#brlcad dreeves
(n=IceChat7@64.178.177.71) |
| 06:40.55 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 07:47.01 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 07:50.56 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 08:07.10 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 08:13.05 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 08:33.54 |
miqlas |
brlcad : are
You here? |
| 08:40.45 |
Ralith |
miqlas: that
driver you linked me was for 2d -_- |
| 08:41.17 |
miqlas |
Ralith, if
You check the readme, it tells there is basic 3d support for some
older videocard. |
| 08:41.31 |
Ralith |
miqlas:
'basic 3d support for some older videocard' is not 3D
accel. |
| 08:41.42 |
miqlas |
"Basic 3D
acceleration for older cards: see the seperately available 3D
accelerant's documentation for details;" |
| 08:42.02 |
Ralith |
also, not
only is that a 2d driver, it's an unmaintained one which stopped
working some time ago, according to #haiku. |
| 08:42.21 |
Ralith |
as part of
the move to Mesa 7 |
| 08:42.32 |
Ralith |
which does
support acceleration, but has no implementations of it. |
| 08:42.36 |
miqlas |
Sorry, i
can't know everything :) |
| 08:42.49 |
Ralith |
'k |
| 08:43.05 |
Ralith |
nevertheless,
cool looking OS. |
| 08:43.18 |
miqlas |
But it give
bigger score in OGLTeapot :) |
| 08:48.29 |
Ralith |
sleeps |
| 08:51.29 |
miqlas |
what is the
good word for an technican draw? It is good for assembly? Sorry,
the english is not my native language.. |
| 08:56.28 |
Ralith |
miqlas:
diagram? blueprint? People just say 'technical drawing' most of
the time, I think. |
| 08:57.24 |
miqlas |
This is a 3d
cad assembly. The "CAD assembly" good for this? |
| 08:57.55 |
miqlas |
And i need
change the MIT license text? (software -> CAD
assembly)? |
| 08:59.05 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 08:59.07 |
Ralith |
If in legal
text, I'd refer to it with more encompassing terms, e.g. 'CAD
file' |
| 08:59.22 |
Ralith |
and the MIT
license may be best left alone, but for a definitive answer wait
for brlcad |
| 08:59.29 |
Ralith |
(i.e. used
as-is) |
| 08:59.37 |
Ralith |
(but I'm sure
it can wait a few hours for him to show) |
| 09:00.59 |
miqlas |
Okay. |
| 09:01.05 |
miqlas |
I need to go
now. |
| 09:01.06 |
miqlas |
Bye! |
| 09:22.56 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:24.40 |
mafm_ |
hi
there |
| 09:45.39 |
pacman87 |
morning,
mafm |
| 09:47.58 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:32.18 |
d-lo |
Mornin
all! |
| 10:43.35 |
mafm |
mernin |
| 11:51.49 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 13:45.59 |
*** join/#brlcad BigAToo
(n=BigAToo@64.255.115.3) |
| 14:27.41 |
starseeker |
took a stab at Haiku + vmplayer, but must wait due to needing
to play with kernel modules |
| 14:31.18 |
``Erik |
http://blogs.zdnet.com/community/?p=234 |
| 14:31.31 |
brlcad |
yep, just
finished reading it :) |
| 14:32.13 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 14:32.19 |
brlcad |
howdy
hippieindamakin8 |
| 14:33.08 |
``Erik |
the different
perspective and explicit pointing out of correlations and
implications may help some people *shrug* :) I figured it may be
valuable for some folk to read |
| 14:34.47 |
brlcad |
yeah, few key
sentences in there |
| 14:34.56 |
CIA-28 |
BRL-CAD:
03brlcad * r34304 10/brlcad/trunk/src/conv/: ignore prodigal
binaries |
| 14:36.23 |
hippieindamakin8 |
hey brlcad
:) |
| 15:02.40 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 15:02.42 |
``Erik |
*headache*
why won't people just fucking let waterfall die |
| 15:03.30 |
_clock_ |
didaktik je
vsudypritomny |
| 15:11.18 |
brlcad |
hippieindamakin8: question about your
patch -- did you test that on anything? |
| 15:24.49 |
*** join/#brlcad madant (n=d@117.196.145.3) |
| 15:31.44 |
*** join/#brlcad dreeves
(n=c752f347@bz.bzflag.bz) |
| 15:54.41 |
hippieindamakin8 |
brlcad, not
on a test object,just checked for compilation errors. planned on
doing it post endsemester exams |
| 15:54.50 |
brlcad |
ah,
okay |
| 15:55.39 |
hippieindamakin8 |
i ll get back
to u on 30th after testing it . sorry for not doing
that |
| 15:56.03 |
brlcad |
it's
okay |
| 15:56.32 |
brlcad |
i was just
looking at myself, and didn't look like it'd compile |
| 15:56.44 |
hippieindamakin8 |
thanks |
| 15:59.19 |
hippieindamakin8 |
brlcad, is it
? |
| 16:01.08 |
hippieindamakin8 |
i ll just
verify everything and get back to you then. with the
results |
| 16:03.41 |
madant |
hippieindamakin8: 30th is the D-day ?
getting out of iit finally ;) ? |
| 16:03.57 |
hippieindamakin8 |
madant, no
:) |
| 16:04.08 |
hippieindamakin8 |
i dropped a
course just before the endsems |
| 16:04.24 |
madant |
damn, what do
you have to do then ? |
| 16:04.30 |
hippieindamakin8 |
it is better
to drop it rather than flunk it. so i ll do it next
semester |
| 16:05.02 |
madant |
yikes, so you
have to stay a semester for a course :O ? |
| 16:05.12 |
madant |
you were dead
sure you were going to flunk it :O ? |
| 16:05.43 |
hippieindamakin8 |
madant, yeah
the prof the last time when he took the course gave an F at the
average score. |
| 16:06.13 |
madant |
thinks psycho profs are the bane of good education
:D |
| 16:10.35 |
hippieindamakin8 |
madant, its
the other way round. they dont want people to fiddle around with
the real world stuff with this average knowledge |
| 16:11.33 |
madant |
never had that bad or good profs :) |
| 16:12.21 |
madant |
brlcad,
though art my mentor :) and elena goes to d-lo ? |
| 16:12.41 |
madant |
oops i meant
thou art my mentor .. :D |
| 16:13.59 |
hippieindamakin8 |
is compiling the package again |
| 16:16.41 |
brlcad |
madant: for
logistics tracking, yeah |
| 16:17.27 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 16:17.38 |
brlcad |
hippieindamakin8: yeah, BU_PTBL_INS
doesn't look right |
| 16:18.09 |
madant |
brlcad:
awesome :) i'll get my act together immediately |
| 16:19.44 |
hippieindamakin8 |
it is of the
type int , but in this file tankill-g.c it has been used this way:
/* save the face in a table */ |
| 16:19.44 |
hippieindamakin8 |
<PROTECTED> |
| 16:21.21 |
brlcad |
well, it's
going to crash -- you never initialize the nmg_vertices (or any of
th bu_ptbl's) |
| 16:22.29 |
brlcad |
similarly,
you don't allocate or initialize the struct vertex |
| 16:23.13 |
hippieindamakin8 |
brlcad, oops
i ll just correct the code and send it to you |
| 16:23.25 |
hippieindamakin8 |
brlcad, just
discard it for now. |
| 16:23.43 |
brlcad |
okay |
| 16:23.47 |
CIA-28 |
BRL-CAD:
03brlcad * r34305
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: ws, indent,
style consistency cleanup |
| 16:23.49 |
brlcad |
otherwise, it
looks like you were going down the right track I think |
| 16:24.41 |
hippieindamakin8 |
yeah i was in
a hurry not to care abt the memory issues. i ll just add them up.
and submit the patch agaon |
| 16:26.05 |
brlcad |
hippieindamakin8: there's an old junk
routine that does almost exactly what that routine needs to
do |
| 16:26.16 |
brlcad |
though it
reads from a file iirc |
| 16:26.26 |
brlcad |
yeah...
nmg_polytonmg() |
| 16:26.31 |
brlcad |
in
nmg_junk.c |
| 16:26.48 |
*** join/#brlcad miqlas
(n=Miranda@193.225.63.8) |
| 16:26.51 |
brlcad |
there you can
see the GET_VERTEX allocation and setting the magic to init
it |
| 16:26.59 |
miqlas |
Hello
brlcad! |
| 16:27.03 |
miqlas |
Do You got
the mail? |
| 16:27.04 |
hippieindamakin8 |
aah i have
taken the observations/procedure from ascii to nmg.c |
| 16:27.07 |
brlcad |
howdy miqlas
! |
| 16:27.08 |
brlcad |
yeah, I got
it |
| 16:27.16 |
brlcad |
fantabulous |
| 16:27.19 |
miqlas |
Can BRL-CAD
open it? |
| 16:27.31 |
hippieindamakin8 |
i ll check
nmg_junk.c |
| 16:27.40 |
miqlas |
Please, send
me a screenshoot about it, if You can... |
| 16:27.42 |
brlcad |
heh, not as a
step file .. that's the converter presently being implemented
:) |
| 16:27.52 |
brlcad |
but I can' go
through another path and import it to show you |
| 16:28.35 |
miqlas |
I can provide
.iges and .stl file too. |
| 16:28.51 |
brlcad |
that would be
awesome |
| 16:28.56 |
brlcad |
save me some
time |
| 16:29.13 |
miqlas |
Do You need
the .stl and .iges file? |
| 16:29.30 |
brlcad |
yeah, both
would be great |
| 16:29.44 |
brlcad |
we have
importers for those to already |
| 16:30.38 |
hippieindamakin8 |
brlcad ,
right. it is mostly what i need. |
| 16:30.47 |
miqlas |
it is cca. 40
mb... |
| 16:31.16 |
brlcad |
miqlas: can
upload via ftp to brlcad.org/incoming |
| 16:31.32 |
miqlas |
okay. i
try... |
| 16:31.48 |
miqlas |
i'm
compressing wit rar, it is ok for You? |
| 16:32.02 |
miqlas |
No it is only
4 mb :) |
| 16:32.09 |
brlcad |
that's
fine |
| 16:32.17 |
miqlas |
40 Mb->4
Mb. Good... :) |
| 16:34.56 |
miqlas |
upload
finished. |
| 16:35.09 |
miqlas |
please, check
the archive.. |
| 16:35.50 |
miqlas |
Can i ask,
the USa military use the BRL-CAD yet? |
| 16:36.03 |
brlcad |
okay, will
check |
| 16:36.07 |
brlcad |
yeah, for
more than 20 years |
| 16:36.11 |
brlcad |
actively
using it |
| 16:36.21 |
miqlas |
Okay.
Thanks. |
| 16:36.49 |
miqlas |
brlcad, did
You checked the license text? it is good? |
| 16:37.41 |
brlcad |
looked good
to me |
| 16:38.42 |
hippieindamakin8 |
brlcad,
madant : see you soon |
| 16:39.03 |
hippieindamakin8 |
gets back to studying taking note of what he has to correct
in the patch. |
| 16:40.20 |
brlcad |
starseeker:
you should have access on the site now |
| 16:40.35 |
brlcad |
created a new
core contributor role that should give nearly complete
access |
| 16:40.59 |
brlcad |
you basically
create a new story and promote it to the main page |
| 16:41.29 |
brlcad |
feel free to
fix the captcha when you notice the bug.. :) |
| 16:48.51 |
CIA-28 |
BRL-CAD:
03brlcad * r34306
10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c: major cleanup
upon remembering nmg_polytonmg() in the junk file. possible
approach for a bot-to-nmg routine. while we're in here, clean up
the ws/style and rip out all the dead code for heaps and
groups. |
| 16:49.46 |
starseeker |
brlcad: cool!
thanks |
| 16:54.15 |
CIA-28 |
BRL-CAD:
03brlcad * r34307
10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c: add missing
headers so the file will actually compile, make all of the routines
static just so someone doesn't try to use them, and add a big
freaking warning about the routines not being vetted for use
yet. |
| 16:55.42 |
CIA-28 |
BRL-CAD:
03brlcad * r34308
10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c:
de-knrify |
| 16:56.56 |
CIA-28 |
BRL-CAD:
03brlcad * r34309
10/brlcad/trunk/src/librt/Makefile.am: |
| 16:56.56 |
CIA-28 |
BRL-CAD:
enable compilation of the nmg_junk.c source file so that the source
can stay in |
| 16:56.56 |
CIA-28 |
BRL-CAD: sync
with the API. all routines in there are static, so strictly
speaking |
| 16:56.56 |
CIA-28 |
BRL-CAD:
compiling the file isn't necessary, but it will help the sources
stay updated. |
| 17:09.13 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 17:14.14 |
d-lo |
go go gadget
brlcad. |
| 17:21.30 |
brlcad |
hehe,
fantastic.. http://www.tgdaily.com/html_tmp/content-view-42154-181.html |
| 17:21.46 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 17:21.53 |
brlcad |
hello
joe |
| 17:34.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 19:04.37 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 19:19.40 |
CIA-28 |
BRL-CAD:
03brlcad * r34310 10/brlcad/trunk/TODO: |
| 19:19.40 |
CIA-28 |
BRL-CAD:
topic came up again today, expand on the need for a 3d plot object
primitive. |
| 19:19.40 |
CIA-28 |
BRL-CAD:
ideally/probably needs to support points, lines, polylines, arcs,
circles, |
| 19:19.40 |
CIA-28 |
BRL-CAD:
spline curves, and text. the _plot() callbacks should then return a
plot object |
| 19:19.40 |
CIA-28 |
BRL-CAD:
instead of the current vlist/polyline data that it returns. all
sorts of |
| 19:19.43 |
CIA-28 |
BRL-CAD:
implications and benefits including automatic wireframe LoD and
optimized |
| 19:19.45 |
CIA-28 |
BRL-CAD:
representation. |
| 19:22.48 |
``Erik |
wonders if there's too much duplication in brlcads notional
outline... isn't a circle just an arc that goes all the way around?
isn't an arc a case of spline? isn't a line a case of spline? isn't
a polyline a set of lines? O.o |
| 19:23.43 |
brlcad |
yes,
mathematically tis true -- but from a modeling and capturing intent
perspective, the subclasses are useful to record (and it's much
less data) |
| 19:24.11 |
brlcad |
it's also
pretty much the standard set of specific entities supported by
drafting systems |
| 19:24.45 |
``Erik |
hm, but
should it be explicitely broken out into seperate entities, or
should, say, 'gimmealine()' create a spline that just happsnt o
have 0 length control vectors at each endpoint? |
| 19:24.55 |
``Erik |
happens
to |
| 19:25.08 |
``Erik |
is the memory
savings worth the added complexity? |
| 19:25.42 |
brlcad |
you have to
have the complexity anyways for the N types, it's rather
minimal |
| 19:26.05 |
brlcad |
not like they
have ray-tracing hooks, for example |
| 19:26.15 |
brlcad |
and if we
import from another system, it's a faithful import |
| 19:26.23 |
``Erik |
*shrug* I'm
just jabbering to try to sound smart :) something that might be
worth considering if it hasn't been |
| 19:27.24 |
``Erik |
being able to
send that kinda info to the raytracer might be useful once we start
adding drafting capabilities |
| 19:28.50 |
``Erik |
(mebbe as a
post-frame overlay) |
| 19:32.29 |
brlcad |
another
possibility would be to have each object be its own object in the
db, given them all their own non-geometry entity code ala
iges/step/dxf .. but that really goes down a road I'm not keen
on |
| 19:33.08 |
brlcad |
hm..
http://www.plasticproto.com/index.php?option=com_content&view=article&id=26&Itemid=34&lang=en |
| 19:36.13 |
*** join/#brlcad cad92
(n=5b21eead@bz.bzflag.bz) |
| 19:37.57 |
brlcad |
also
interesting.. http://www.harmonyware.com/step_supported.html |
| 19:38.57 |
brlcad |
basically a
subset of that list, the 3D non-surface/non-solid/non-reference
entities |
| 19:46.42 |
``Erik |
hehehe "yak
shaving" I like that :D |
| 20:02.24 |
brlcad |
another
option altogether is for _plot() to go away and _brep() take its
place |
| 20:05.46 |
CIA-28 |
BRL-CAD:
03brlcad * r34311 10/brlcad/trunk/TODO: few more entities (thx
collada) |
| 20:23.53 |
``Erik |
huh http://smacklet.com/ |
| 21:03.43 |
archivist |
have you left
that page up for a complete period ``Erik :) |
| 21:03.55 |
``Erik |
yeah
heh |
| 21:04.00 |
``Erik |
I had "drink
coffee" on mine |
| 21:04.01 |
``Erik |
:D |
| 21:04.33 |
archivist |
I had a step
back from what you are doing (i put nothing) |
| 21:08.46 |
CIA-28 |
BRL-CAD:
03brlcad * r34312
10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c: quell symbol
error, nmg_isect_edge3p_shell doesn't exist |
| 21:41.00 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 22:14.36 |
*** join/#brlcad redvsblue
(n=pancake@c-69-247-175-242.hsd1.mo.comcast.net) |
| 23:28.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 23:56.22 |
*** join/#brlcad dreeves
(n=IceChat7@64.178.177.71) |
| 00:18.18 |
CIA-28 |
BRL-CAD:
03brlcad * r34316
10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: |
| 00:18.18 |
CIA-28 |
BRL-CAD:
simplify the export calculations for the point data size: use masks
so we can |
| 00:18.18 |
CIA-28 |
BRL-CAD:
avoid error-prone magic numbers. also remove the unnecessary void
pointer |
| 00:18.18 |
CIA-28 |
BRL-CAD:
casting redundancy in _describe(), BU_LIST_FOR gives us the right
iterator type. |
| 00:19.00 |
CIA-28 |
BRL-CAD:
03brlcad * r34317 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
ws |
| 00:25.52 |
CIA-28 |
BRL-CAD:
03brlcad * r34318 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
cleanup and prepare to fix ifree() |
| 00:27.55 |
CIA-28 |
BRL-CAD:
03brlcad * r34319 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
print the type if we encounter something unexpected to help with
debugging |
| 01:02.53 |
b0ef |
jdoliner: not
really sure what you mean by hybridization between B-REP and CSG;
you will work on NURBS in other words?;) |
| 01:30.59 |
*** join/#brlcad rbfish2k
(n=chatzill@pool-71-125-225-196.nycmny.east.verizon.net) |
| 02:06.58 |
CIA-28 |
BRL-CAD:
03brlcad * r34320
10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: |
| 02:06.58 |
CIA-28 |
BRL-CAD:
restore an _ifree() implementation that still 'cheats' by just
leveraging the |
| 02:06.58 |
CIA-28 |
BRL-CAD: fact
that all of the point structure types have a bu_list element that
we can |
| 02:06.59 |
CIA-28 |
BRL-CAD:
iterate over. we can save a little time by avoiding to dequeue the
points too |
| 02:06.59 |
CIA-28 |
BRL-CAD:
since the list is being wiped out anyways. stub in the _print()
callback |
| 02:07.01 |
CIA-28 |
BRL-CAD:
pretending that rt_pnts_internal is what we're going to use for the
solid |
| 02:07.03 |
CIA-28 |
BRL-CAD:
specific structure. |
| 02:47.14 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 02:52.04 |
CIA-28 |
BRL-CAD:
03brlcad * r34321 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
one more void* elimination along with consolidating the buf size to
one place. |
| 02:57.34 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:11.48 |
CIA-28 |
BRL-CAD:
03brlcad * r34322 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
make the point iteration consistent with the other routines --
don't use a separate head pointer. add a couple magic sanity checks
too |
| 03:16.58 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:53.38 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 03:59.14 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 05:20.22 |
starseeker |
hrm. |
| 05:20.40 |
starseeker |
appears to have exceeded the memory capabilities of his
system |
| 05:29.28 |
Ralith |
haiku runs
nicely on my laptop :D |
| 05:29.36 |
starseeker |
cool! |
| 05:29.40 |
Ralith |
I should
install it to disk and see if it's actually responsive from there
>_> |
| 05:29.53 |
starseeker |
if it
supports the laptop hardware |
| 05:30.07 |
Ralith |
hm? |
| 05:30.12 |
Ralith |
it's running
pretty well right now... |
| 05:30.20 |
Ralith |
full
resolution, functional network, mouse, keyboard |
| 05:30.22 |
starseeker |
wait, are you
running in virtual machine? |
| 05:30.28 |
Ralith |
nope |
| 05:30.31 |
starseeker |
!! |
| 05:30.31 |
Ralith |
booted it
from a USB stick |
| 05:30.32 |
starseeker |
nice |
| 05:30.43 |
Ralith |
pretty
shiny. |
| 05:30.58 |
Ralith |
kinda
dissapointed that ff2 came up though |
| 05:31.01 |
Ralith |
was hoping
for a native browser |
| 05:31.07 |
Ralith |
that is,
custom browser |
| 05:31.11 |
starseeker |
ah |
| 05:31.19 |
starseeker |
thinks that will come after a stable
release |
| 05:31.28 |
starseeker |
probably use
webkit or gecko though |
| 05:33.20 |
Ralith |
yeah, I
remembered reading about some effort to transfer existing work to
webkit |
| 05:41.20 |
Ralith |
300fps
spinning teapot in software |
| 05:41.21 |
Ralith |
not
bad |
| 06:33.19 |
*** join/#brlcad elena
(n=ebautu@92.86.0.28) |
| 06:38.46 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 06:38.58 |
mafm |
hi |
| 06:44.37 |
Ralith |
hi |
| 06:46.33 |
*** join/#brlcad LarsG
(n=lars@nusnet-228-5.dynip.nus.edu.sg) |
| 06:51.29 |
elena |
hello |
| 07:09.17 |
madant |
howdy
mafm |
| 07:09.43 |
madant |
Ralith: how's
the gui planning coming up :) |
| 07:16.02 |
*** part/#brlcad elena
(n=ebautu@92.86.0.28) |
| 07:22.00 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 07:52.36 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:46.25 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 08:58.50 |
brlcad |
wanders off to practice |
| 09:01.27 |
brlcad |
Ralith:
that's pretty cool, so next step is get a compiler installed and
work on a minimum brl-cad compilation? :) |
| 09:03.11 |
Ralith |
maybe! |
| 09:03.18 |
Ralith |
madant:
slower than I'd like |
| 09:07.34 |
madant |
:) one thing
i learned last time is :D most things take longer than you
anticipate :) |
| 09:22.15 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 09:22.23 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 09:50.26 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 09:54.06 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 10:53.20 |
d-lo |
nornin
all! |
| 10:58.57 |
``Erik |
yargh, matey,
shiver me timbers, or somethin' |
| 11:09.41 |
*** join/#brlcad madant_
(n=d@117.196.133.20) |
| 11:24.34 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DF88.dip.t-dialin.net) |
| 11:43.37 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DF88.dip.t-dialin.net) |
| 11:55.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 12:04.04 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 12:12.51 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DF88.dip.t-dialin.net) |
| 12:25.59 |
*** part/#brlcad LarsG
(n=lars@nusnet-228-5.dynip.nus.edu.sg) |
| 12:27.28 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DF88.dip.t-dialin.net) |
| 13:22.28 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DF88.dip.t-dialin.net) |
| 13:22.58 |
``Erik |
cooks up some corned beef hash and eggs
O.o |
| 13:23.22 |
d-lo |
Now *THAT*
sounds good... Mmmmmm |
| 13:23.52 |
``Erik |
the gf
thought I was batshit insane for buying a can of corned beef
hash |
| 13:23.54 |
``Erik |
it's good
shit! |
| 13:24.03 |
``Erik |
fat kid shit,
but good! |
| 13:24.52 |
``Erik |
I think I'll
bring eds lappie back to him tomorrow |
| 13:25.17 |
``Erik |
in th emean
time, this ucw action vs function crap not acting like call/cc
should is strusfrating me. |
| 13:25.50 |
brlcad |
that's good
stuff |
| 13:26.34 |
``Erik |
(it's my rdo,
I think I've dropped more lines of code this morning than in the
last fortnight) |
| 13:28.43 |
brlcad |
just had a delectable plate of his own creation.
yum! |
| 13:29.02 |
``Erik |
think you
guys could spare a corner with a workstation for me? I'm getting
clobbered with questions left and right that burn time and even
lead to philosphical debates :( that he actually stated that he was
doing me a favor by not asking me a question for a WHOLE FUCKING
HOUR |
| 13:29.12 |
``Erik |
I have shit
to do, I need to hide to do it :( |
| 13:30.45 |
``Erik |
indianlarry
takes most of it for me as he's not on a crunch for anything, but
when he's not there or doesn't have the answers...
*grouse* |
| 13:31.14 |
``Erik |
I might be
turnin' those new suns into my chair real soon |
| 13:31.24 |
brlcad |
um, maybe
don't get suckered into philosophical debates |
| 13:32.04 |
``Erik |
hehehe, it's
hard, he has ideas that he needs to be heared, and when ya
disagree, it must be because you didn't understnad him |
| 13:32.05 |
``Erik |
:/ |
| 13:32.14 |
d-lo |
lol |
| 13:32.16 |
brlcad |
i'm sure
that's not all the questions, but that one you can certainly do
something about |
| 13:32.16 |
d-lo |
lock the
door |
| 13:32.30 |
``Erik |
uhhh, he has
a key? :D |
| 13:33.02 |
``Erik |
waterfall/perfection vs
agile/chaotic |
| 13:33.05 |
``Erik |
*sigh*
:D |
| 13:33.09 |
d-lo |
oh, THAT one.
I thought you were talking about the previous owner of cliffs
seat. |
| 13:33.23 |
``Erik |
no, he's
totally controllable, not an issue at all |
| 13:34.50 |
``Erik |
last friday,
I said "ok, if you think that's how it should be, go do it. If it
works, people will follow" way too many times |
| 13:35.29 |
``Erik |
<-- was
seriously close to flipping out, wasn't planning on going to lunch,
but HAD to get out of that environment O.o |
| 13:35.44 |
``Erik |
gave me a
damn headache :D |
| 13:35.48 |
``Erik |
aaaanyways |
| 13:36.31 |
``Erik |
I think I
might have to look for a place to squat in to crank some
productivity, dark and music... O.o |
| 13:36.50 |
d-lo |
You like
headphones? |
| 13:39.50 |
``Erik |
I can't use
headphones for very long, they tend to push on my jaw just below my
ears and give me a headache |
| 13:43.04 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DF88.dip.t-dialin.net) |
| 13:44.02 |
starseeker |
tries to gear up argouml and discovers that a major python
version update on gentoo == pain |
| 13:46.20 |
``Erik |
d-lo, do you
tubesperms do mess duty, or do ya'll get a specialist? |
| 13:46.42 |
``Erik |
s/allothta/pasttesnse()/ |
| 13:48.13 |
d-lo |
Mess duty
only when you are new to the boat and can't stand any
Watchstation. |
| 13:48.20 |
d-lo |
NUB = Non
Useful Body |
| 13:48.26 |
``Erik |
:D |
| 13:48.31 |
d-lo |
NUB = Mess
duty. |
| 13:48.45 |
``Erik |
this somehow
reminds me of navy mess... *cookcoookcook* |
| 13:49.19 |
d-lo |
If you aren't
pulling out 15 day old leftovers, you aren't doing it right imho.
=D |
| 13:49.39 |
``Erik |
hehehe |
| 13:51.49 |
``Erik |
noms his brunch |
| 13:54.56 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34323 10/brlcad/trunk/include/bn.h: stub the
notion of a point |
| 13:58.56 |
brlcad |
enum
ftw |
| 14:00.22 |
``Erik |
public
thinking *shrug* when I get around to the actual draw routines,
mebbe I'll consider applying it |
| 14:01.01 |
``Erik |
mmm salty,
but good, I should buy corned beef hash more often :D |
| 14:03.29 |
``Erik |
heads out to check up on his car, renew his rental contract
and stop by the grocery store O.o |
| 14:06.06 |
*** join/#brlcad madant
(n=d@117.196.145.148) |
| 14:07.55 |
d-lo |
...just don't
go out for pizza! *ducks* |
| 15:01.13 |
*** join/#brlcad mafm (n=mafm@83.49.86.223) |
| 15:01.22 |
mafm |
hi |
| 15:15.23 |
brlcad |
howdy
mafm |
| 15:28.37 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 15:31.07 |
madant |
hi
mafm |
| 15:41.46 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:59.11 |
CIA-28 |
BRL-CAD:
03brlcad * r34324 10/brlcad/trunk/include/nmg.h: alignment cleanup
while looking where data could be attached |
| 15:59.14 |
brlcad |
hippieindamakin8: hola! any progress on
that nmg routine? |
| 15:59.31 |
hippieindamakin8 |
brlcad,
hey |
| 15:59.50 |
hippieindamakin8 |
not yet. just
back from 7 hrs of continous examinations. |
| 16:00.27 |
hippieindamakin8 |
i ll do that
on 30th as soon as i am done with the endsems . got 2 more on
wednesday and i ll be done. |
| 16:02.52 |
hippieindamakin8 |
brlcad, i ll
look through the nmg_junk and the other conversions to nmg and
rewrite it then |
| 16:12.26 |
brlcad |
hippieindamakin8: oh yeah, how'd those
go? |
| 16:12.31 |
brlcad |
your exams
that is |
| 16:12.40 |
CIA-28 |
BRL-CAD:
03brlcad * r34325 10/brlcad/trunk/include/nmg.h: more ws and
comment cleanup |
| 16:13.30 |
brlcad |
hippieindamakin8: when you do look, keep
in mind that nmg_junk alludes to the notion that the way it does it
for polys from file isn't necessarily the 'right' way |
| 16:13.56 |
brlcad |
didn't
investigate exactly what was meant by that comment but I think it
has to do with the fact that the nmg is manually constructed
instead of using functions |
| 16:24.33 |
``Erik |
no no, I seem
to get accosted by curbs when I go out for pizza |
| 17:23.19 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 17:38.54 |
``Erik |
grooves to regina spektor |
| 17:43.39 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:46.16 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:58.01 |
CIA-28 |
BRL-CAD:
03brlcad * r34326 10/brlcad/trunk/include/nmg.h: looks like indent
is messing with some of the defines, reindent. also a few other
minor tweaks for consistency and null out the NMG_FREESTRUCT
pointer after it's free for sanity too. |
| 18:06.19 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:27.28 |
*** join/#brlcad dreeves
(n=c752f348@bz.bzflag.bz) |
| 18:27.52 |
dreeves |
waives at brlcad and starseeker |
| 18:29.14 |
dreeves |
~logs |
| 18:29.15 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 18:54.34 |
brlcad |
howdy
dreeves |
| 18:58.16 |
dreeves |
I have been
very preoccupied with a project but should be freeing up in the
next day or two then maybe we can make some more progress I see you
all have added some more test data thanks!! |
| 18:58.27 |
CIA-28 |
BRL-CAD:
03brlcad * r34327 10/brlcad/trunk/include/raytrace.h: align the
closing scope with the define macro |
| 19:19.45 |
starseeker |
hey
dreeves |
| 19:33.11 |
starseeker |
brlcad: Are
there any worthwhile open source SIMD abstraction libraries out
there? |
| 19:49.49 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 19:50.21 |
elena |
hi. |
| 19:50.57 |
starseeker |
howdy |
| 19:51.04 |
elena |
how are
you? |
| 19:51.12 |
starseeker |
well.
yourself? |
| 19:51.18 |
elena |
fine. |
| 19:51.59 |
elena |
do you have
some spare time now? |
| 19:52.04 |
starseeker |
sure |
| 19:52.42 |
elena |
can we talk
about the project plan? |
| 19:53.12 |
starseeker |
yep. |
| 19:53.18 |
elena |
great! |
| 19:53.39 |
elena |
where do we
start? |
| 19:54.02 |
starseeker |
do you have a
wiki page with your proposal? |
| 19:54.07 |
elena |
yes. |
| 19:54.09 |
elena |
1
sec. |
| 19:55.04 |
elena |
http://brlcad.org/wiki/User:EBautu |
| 19:57.49 |
starseeker |
I guess the
main question at the moment is what features are
needed/desired? |
| 19:59.36 |
elena |
``Erik
mentioned a rating system. |
| 19:59.46 |
``Erik |
wakes up |
| 20:01.09 |
``Erik |
oh, yeah, I
figure the point is a community, there'll be both spammers as well
as well meaning folk who simply produce crap... |
| 20:01.21 |
elena |
basiclly,
browse for models, search, and upload models. |
| 20:02.38 |
starseeker |
right - there
are some fairly obvious core capabilities without which there is no
site. The most important is the model -> web-ready information
capabilities |
| 20:03.37 |
starseeker |
I would say
that the user interaction modes are orthogonal to the "handle CAD
models" core functionality |
| 20:04.00 |
brlcad |
personally
(and open to debate) I'd like the site to effectively counter abuse
in a manner similar to most wikis |
| 20:04.04 |
brlcad |
that is ..
make it easier to remove the content than it is to add it, use
recaptcha for anonymous submissions, and provide a strong feedback
loop (like cia and/or e-mail notifications on changes) |
| 20:04.19 |
starseeker |
agrees |
| 20:04.28 |
starseeker |
recaptcha is
a must |
| 20:04.47 |
``Erik |
no, recaptcha
is NOT a must |
| 20:04.55 |
``Erik |
a strong
community is a must |
| 20:05.17 |
elena |
i think we
should not allow anonymous submissions. |
| 20:05.30 |
starseeker |
``Erik: I
would contend that a strong basis of good quality models will
attract a community |
| 20:05.45 |
elena |
the least you
can do is create an account if you want to submit
something. |
| 20:06.02 |
starseeker |
my concern
with anonymous submissions is being sure that they aren't (say)
something from a company's commercial files |
| 20:06.17 |
brlcad |
elena: put a
lot of thought into that particular topic -- there's a reason to
allow it |
| 20:06.17 |
``Erik |
hackernews
(http://news.ycombinator.com) has
an aggressive moderation community, reddit.com does not... slashdot
uses a designated coop |
| 20:06.40 |
brlcad |
that's not to
say unchecked submissions -- but to allow them with extra
effort |
| 20:06.41 |
``Erik |
this is a
topic that has a lot of random experimentation and little
proof |
| 20:08.03 |
brlcad |
specifically
with regards to starseeker's point, *any* submission should have a
cited source and the submission process allowing that source to be
specified |
| 20:08.54 |
starseeker |
I would
suggest solving the technical problems of CAD model -> web page
is the first order of business - how those tools are used is
(obviously) more complicated from a social standpoint |
| 20:09.29 |
``Erik |
argues that there is no technical solution to a social
issue |
| 20:09.48 |
brlcad |
if the claim
is "I made this", then anonymous wouldn't be allowed -- but if some
random user found the openmoko model and wanted to add it to the
db, nothing should prevent that contribution presuming it's
properly cited (and probably manually reviewed) |
| 20:09.58 |
starseeker |
ok - but
we're doing a gsoc project here, so shouldn't the focus be on
concrete functionality? |
| 20:10.18 |
starseeker |
brlcad: ok,
that makes sense |
| 20:10.54 |
``Erik |
but is the
essense o fthe project to create a pile of code? or is it ot begin
developing a community? |
| 20:11.07 |
starseeker |
I would say
it's the former |
| 20:11.43 |
starseeker |
without the
former, the latter isn't practical |
| 20:11.49 |
brlcad |
I'd rather
the system be set up as open as possible, and just make it easy to
correct and respond to bad use (think wikipedia not journal
submission) |
| 20:11.56 |
``Erik |
*shrug* I
personally believe it's a critical discriminating point |
| 20:12.14 |
brlcad |
``Erik:
developing the community is our job :) |
| 20:12.39 |
``Erik |
I kinda think
the point of any software is to support a community, to develope a
piece of software with no appreciation of a community is ...
pointless |
| 20:12.43 |
brlcad |
the project
is about writing code and becoming a contributor |
| 20:13.05 |
brlcad |
those aren't
orthogonal goals |
| 20:13.09 |
``Erik |
and now; I
walk like an egyption. *dance* |
| 20:13.23 |
starseeker |
blinks |
| 20:13.48 |
brlcad |
elena: so I
mentioned this earlier when you weren't around but just in
case... |
| 20:13.54 |
brlcad |
please do
keep in mind a few things: 1) conversations should be public, 2)
mentoring should similarly be public especially technical
discussions, and 3) your listed mentor is predominantly for
logistically tracking your progress -- i.e., they're not your
"go-to" person for technical discussions -- those really should be
open forums (here and/or irc) where any/other devs can at least
listen in |
| 20:13.54 |
``Erik |
whoa ohh
whoahh ohh woohhha ohh wohhh ohh whoaahhhh |
| 20:14.29 |
brlcad |
mm, and that
should have read (here and/or mailing list) ;) |
| 20:14.31 |
elena |
ok. I know
that. |
| 20:14.37 |
brlcad |
elena: okay,
just making sure :) |
| 20:14.50 |
brlcad |
sometimes a
critical piece of information slips through.. makes all the
difference |
| 20:14.51 |
elena |
thank
you. |
| 20:15.02 |
brlcad |
trying to
make sure everyone gets the same information this year
:) |
| 20:15.17 |
brlcad |
the channel
/topic is useful too ;) |
| 20:15.56 |
starseeker |
has a question - is the intent to recognize the file format
being provided, or to rely on the user to identify the
format? |
| 20:16.41 |
elena |
I didn't do
it before, but we could try to recognize the file
format. |
| 20:16.49 |
elena |
using some
magic bytes maybe? |
| 20:17.32 |
elena |
or simpler,
it's file extension (not sure how general is that)... |
| 20:17.36 |
brlcad |
to me, the
heart of that project from a task perspective is the ability to
upload a .g file (for starters) with annotated metadata, and then
visualize that model categorized through the website (raytrace
renderings along with more fundamental information like file types,
object counts, sizes, dates, license, etc) |
| 20:18.37 |
brlcad |
it doesn't
need to recognize -- there's only a limited set of
types |
| 20:18.52 |
brlcad |
have a
selector on upload that specifies the type, then it can be named
anything |
| 20:19.11 |
elena |
ok. that's
even simpler :) |
| 20:19.14 |
brlcad |
could still
have the uploader require a consistent naming convention
too |
| 20:20.45 |
brlcad |
elena: what
would your preference be in terms of scope -- more focus on
conversion capability or more focus on the site index
itself? |
| 20:21.25 |
elena |
what do you
mean by "site index"? |
| 20:23.03 |
brlcad |
the site
browsability, the web interface itself |
| 20:23.26 |
elena |
aaha. |
| 20:23.40 |
brlcad |
as much as
there are lots of potential ideas where this can/will go, there's
simply not enough time, so narrowing that scope would be
good |
| 20:24.08 |
elena |
usability is
importanta, but i'd like to focus on conversion, too. |
| 20:24.34 |
elena |
conversion
will require me to learn more about brlcad. |
| 20:24.40 |
elena |
not you, the
software :D |
| 20:24.40 |
brlcad |
e.g. making
the front-end framework really easy to use and well organized vs
having support for tracking versions of files vs having support for
importing/exporting various formats cleanly vs rendering views vs
rating/karma system vs robust metadata support, etc |
| 20:24.53 |
brlcad |
the dash
makes all the difference ;) |
| 20:24.56 |
brlcad |
brlcad vs
brl-cad ;) |
| 20:26.33 |
elena |
i'd go with
support import/export, then rating, then rendering, then easy to
use, metadata, etc. |
| 20:26.59 |
brlcad |
now the
all-important question -- why? :) |
| 20:26.59 |
elena |
not sure
about the last one. it might be higher weighted. |
| 20:27.36 |
elena |
import/export
is important. without it we have no content. |
| 20:27.39 |
brlcad |
I can say
that clear licensing is a top-priority regardless and that has a
little bit to do with metadata |
| 20:28.08 |
brlcad |
without the
licensing sorted out, most of the other features are
moot |
| 20:28.21 |
brlcad |
not
complicated, but critical |
| 20:28.22 |
elena |
rating is
important (Erik is right that people may upload bad stuff, by
mistake or willingly). |
| 20:28.44 |
starseeker |
barring a
flood of content site admins can address that manually |
| 20:29.20 |
starseeker |
free CAD
models are currently fairly rare |
| 20:29.25 |
brlcad |
a review
queue solves that, similar to drupals comment moderation
system |
| 20:29.29 |
elena |
then I'd say
that licensing implies registred users for submissions. |
| 20:29.40 |
elena |
not necesary
to say I made this. |
| 20:29.48 |
elena |
but to say I
put this here. |
| 20:30.21 |
brlcad |
depends
entirely on the source and the license |
| 20:30.25 |
elena |
it's not
necesary for flood. |
| 20:30.40 |
elena |
but let's say
I find 10 models of a cup. |
| 20:30.58 |
brlcad |
okay |
| 20:31.14 |
elena |
I'd like to
get an idea of other though about them before I start downloading
them. |
| 20:31.47 |
brlcad |
no
comprendo |
| 20:31.49 |
elena |
i, myself,
I'd always start with the highest rated ones. |
| 20:32.15 |
starseeker |
oh, you're
talking about a user sorting site content |
| 20:32.32 |
elena |
yes. sorry,
was related to rating and flooding. |
| 20:33.33 |
brlcad |
rating is
simply a means to filter/sort site content -- with the right
browsing and searching mechanisms, those aren't necessarily that
important; moreover using filtering/searching on top of bad
browsing is still usually a horrible user experience |
| 20:34.07 |
brlcad |
the
unfiltered browsing needs to be well organized by itself regardless
of searching/filtering aids |
| 20:34.31 |
brlcad |
a really good
example site related to this is freshmeat.net |
| 20:34.42 |
starseeker |
sourceforge's
system of filters might also be worth mentioning here - you can
(for example) filter out all search results that don't match a
particular license |
| 20:35.10 |
elena |
I was
thinking more of http://extensions.services.openoffice.org/ |
| 20:35.28 |
brlcad |
freshmeat has
evolved into a rather feature-filled system, but it's core
browsability remains efficient even with tens of thousands of
projects |
| 20:36.18 |
starseeker |
elena: the
trick with rating systems like that is they tend to highlight the
"coolest" items |
| 20:36.23 |
brlcad |
yeah, that's
not bad -- pretty similar |
| 20:36.50 |
starseeker |
for technical
searching, my first order of business is to limit the search space
to the "must haves" - license being the obvious one |
| 20:36.53 |
elena |
yes. coolest
is not always the best. |
| 20:37.19 |
brlcad |
my point
earlier was scope though -- there's not nearly enough time to
"support import/export, then rating, then rendering, then easy to
use, metadata, etc" .. the point is (at least for this summer),
what to leave out |
| 20:37.34 |
elena |
btw, what
drupal version is on brl-cad.org? |
| 20:37.56 |
brlcad |
I'd say
rating/sorting is one to leave out .. searching and basic browsing
would come first |
| 20:38.06 |
brlcad |
elena: a
version that needs to be upgraded :) |
| 20:38.06 |
starseeker |
brlcad:
yeah |
| 20:38.25 |
starseeker |
agreed -
that's why I figured code dealing directly with the cad files was
first up |
| 20:38.51 |
starseeker |
which I guess
is import/export and metadata |
| 20:38.53 |
elena |
agree. |
| 20:39.28 |
brlcad |
import/export
for any geometry type or just .g files (for now)? |
| 20:39.39 |
starseeker |
would say .g files... |
| 20:40.09 |
elena |
how about
import for g, export multiple types? |
| 20:40.24 |
elena |
i played just
a little with the conversion tools. |
| 20:40.48 |
elena |
it looked to
me that I could used them to convert one to another. |
| 20:40.50 |
starseeker |
probably want
to go the other way, actually - ending up with the .g file, at
least BRL-CAD can read it :-) |
| 20:40.56 |
elena |
but you know
better. |
| 20:41.33 |
starseeker |
the
conversion tools can do a lot, but they have their
limitations |
| 20:41.45 |
elena |
yeah. it make
more sense that way :) |
| 20:41.51 |
brlcad |
elena: the
issue is that almost every time you convert geometry from format A
to format B, it's a lossy conversion (nearly universal to the
point of being universal to the CAD industry) |
| 20:42.19 |
brlcad |
our importers
often preserve everything or nearly everything, but our exporters
most certainly do not for many formats |
| 20:42.34 |
elena |
yes. I know.
but how lossy is it? |
| 20:42.35 |
brlcad |
and many
formats simply cannot represent various forms of
geometry |
| 20:42.40 |
brlcad |
night and
day |
| 20:42.51 |
brlcad |
fundamentally
different representation schemes |
| 20:42.58 |
brlcad |
not like jpg
vs png |
| 20:43.20 |
starseeker |
elena:
sometimes very lossy. that's why you want to always preserve the
original submitted format |
| 20:43.39 |
elena |
got
it. |
| 20:43.45 |
brlcad |
difference is
more like text file vs screenshot of text file |
| 20:44.02 |
starseeker |
even
something like Pro-E -> IGES is likely to lose information -
Pro-E -> dxf is guaranteed to since dxf can't hold a lot of what
Pro-E uses |
| 20:46.09 |
elena |
then, it's
export/import .g or export .g/import many+keep
original? |
| 20:46.23 |
elena |
what's your
oppinion? |
| 20:46.23 |
brlcad |
consider a
simple sphere -- we could represent that same sphere in at least
five different ways: 1) as a point+radius, 2) as a 2D outline of a
circle that is rotated about an axis, 3) as a collection of
polygons approximating the surface, 4) as one or more spline
surfaces, 5) as a volumetric data set, ... |
| 20:46.59 |
elena |
yes. you're
right. |
| 20:47.14 |
brlcad |
and brl-cad
actually supports all five of those particular representations...
:) |
| 20:47.23 |
elena |
and I've seen
this when created an .g object database and exported to
triangles. |
| 20:47.39 |
brlcad |
yet a given
export format usually does not -- many export formats only support
polygons or triangles for example |
| 20:47.42 |
brlcad |
exactly |
| 20:47.53 |
starseeker |
start with
export/import .g, imho. Once that's working, more formats can be
added |
| 20:49.03 |
starseeker |
the original
format of the model is an important fact to preserve in the
metadata (probably the second most important after
license) |
| 20:49.16 |
elena |
ok. |
| 20:49.35 |
starseeker |
but you
should preserve that information for .g files too ;-) |
| 20:49.41 |
starseeker |
so no harm
starting there |
| 20:50.31 |
brlcad |
and the users
can always install our tools and convert to .g if they really want
to :) |
| 20:50.44 |
brlcad |
but that does
bring up another point about the site interface |
| 20:51.06 |
brlcad |
I'd really
like it to talk about what format the geometry is or at least what
types of geometry are contained |
| 20:51.18 |
brlcad |
so that if
it's 100% triangles, the site will say so |
| 20:51.21 |
elena |
"users can
always install our tools and convert to .g if they really want to"
correct! |
| 20:51.51 |
brlcad |
likewise, a
special flag to note whether it's a solid model or not |
| 20:52.27 |
``Erik |
convert from,
rather? |
| 20:52.42 |
brlcad |
for .g, the
answers to that metadata is pretty simple (there's only 3 primitive
types we support that aren't solid) |
| 20:54.56 |
elena |
is there a
tools that gives this information? I don't recall one. |
| 20:55.09 |
elena |
like some
kind on statistics. |
| 20:55.16 |
brlcad |
mged
can |
| 20:57.55 |
brlcad |
another thing
I think will be critical is queueing -- uploaded geometry gets
queued for addition, views are queued for rendering, conversions
are queued, etc |
| 20:58.31 |
brlcad |
so that the
system can be taken down or manually prodded without interrupting
jobs or without locking up resources |
| 20:59.01 |
elena |
I think so,
too. |
| 20:59.30 |
``Erik |
if a tool
does not exist, it will shortly after notification that it should
:) |
| 20:59.37 |
brlcad |
geometry
uploads are going to be generally be very big (possibly hundreds of
megs), renderings and conversions are going to take potentially
minutes or hours |
| 21:00.03 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
| 21:00.05 |
brlcad |
yeah, we can
make tools as needed to in order to facilitate the site |
| 21:00.32 |
elena |
really?! I
didn't expect geometry files that big. :( |
| 21:00.55 |
brlcad |
they can be
anywhere from a few bytes to a GB or more, depending on the
model |
| 21:01.03 |
brlcad |
we'll just
have to manually limit the sizes |
| 21:01.05 |
elena |
probably that
says a lot of my experience :) |
| 21:01.12 |
``Erik |
we deal with
files that gobble mulpiple gigs on drive :( |
| 21:02.03 |
brlcad |
not that any
of *those* would ever be uploaded, but it's not inconceivable that
the system will grow to support large models (they are often the
most interesting after all) |
| 21:02.15 |
elena |
uploading
those might be a problem. |
| 21:02.20 |
elena |
for the
user. |
| 21:02.32 |
elena |
aha. |
| 21:02.34 |
brlcad |
hence the
need for a queue and (ideally), multiple upload methods |
| 21:02.41 |
``Erik |
gotta think
towards future-rpoofing, though |
| 21:02.47 |
starseeker |
nods |
| 21:03.44 |
brlcad |
e.g., could
easily support anonymous ftp uploads ala sf.net's former file
release system |
| 21:04.16 |
brlcad |
you upload
your model via anon ftp, then select your file from a
list |
| 21:04.35 |
brlcad |
could do
similar things with sftp/scp |
| 21:04.42 |
``Erik |
I mean,
starseeker is making tires that cork hard drives, yet he still
can't get my tread right :D |
| 21:04.44 |
starseeker |
have to be
careful about restricting that so it isn't abused, but yes that
could work |
| 21:05.03 |
starseeker |
``Erik:
whatda mean? my tires are tiiiiny |
| 21:05.12 |
starseeker |
27k for the
default with tread, iirc |
| 21:05.18 |
``Erik |
where's my
effin' tread? |
| 21:05.24 |
brlcad |
"sphflake
-d8" is enough to make a model that will fill most hard drives
:) |
| 21:05.47 |
brlcad |
tread's off
by default |
| 21:05.51 |
``Erik |
much less
brlcad's! |
| 21:06.01 |
starseeker |
waiting on a
fix for the major/minor axis assumptions in that weird dimensional
case, iirc |
| 21:06.29 |
starseeker |
yeah - I
regard tire -p 1 as the "default" treaded example |
| 21:06.32 |
``Erik |
I'm still not
sure if my fronts are being replaced by all seasons or
not |
| 21:07.00 |
starseeker |
elena: anyway
- is this helpful in narrowing your focus? |
| 21:07.16 |
elena |
yes.
very. |
| 21:07.30 |
``Erik |
well, damn,
I'm doing my best to UNnarrow here :D |
| 21:07.38 |
elena |
however, I'll
copy it and read it again tomorow to filter it out. |
| 21:07.50 |
elena |
:) |
| 21:07.54 |
starseeker |
heh |
| 21:08.15 |
elena |
is this chat
logged? |
| 21:08.16 |
``Erik |
mannies does
soem good lasagna |
| 21:08.20 |
``Erik |
yeah,
uh |
| 21:08.23 |
starseeker |
~log |
| 21:08.23 |
ibot |
methinks log
is as piece of wood, or a record, or the opposite of
exponentiation, or http://ibot.rikers.org/%23uphpu/ |
| 21:08.53 |
brlcad |
~logs |
| 21:08.53 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 21:08.58 |
starseeker |
showoff |
| 21:10.08 |
starseeker |
Ralith: heh -
speaking of native Haiku web browsing - looks like a gsoc project
will integrate webkit into the native Haiku browser. You might get
your updated browsing experience fairly soon :-) |
| 21:10.47 |
brlcad |
BeOS's old
web browser was pretty hilarious -- which is where 'Haiku' got its
name |
| 21:11.20 |
starseeker |
What was that
called. Netcrawler or something? |
| 21:11.39 |
brlcad |
if a page
wasn't there, it would give you a haiku |
| 21:11.41 |
brlcad |
netpositive |
| 21:11.46 |
starseeker |
ah
:-) |
| 21:11.50 |
starseeker |
oh yeah, I
remember that |
| 21:12.07 |
``Erik |
there is no
page here |
| 21:12.07 |
``Erik |
I tried real
hard to find one |
| 21:12.07 |
``Erik |
but there was
none here |
| 21:12.07 |
starseeker |
got a lot of those things - getting browsing up for a virtual
machine is still a trick for me |
| 21:12.08 |
brlcad |
http://8325.org/haiku/ |
| 21:13.11 |
starseeker |
wishes in some ways that Microsoft had bought BeOS after
Apple dropped it and turned it into the next version of
Windows |
| 21:13.23 |
brlcad |
<PROTECTED> |
| 21:13.26 |
starseeker |
would have
been a way to get a nice Windows |
| 21:13.33 |
``Erik |
some of thos
eare brilliant |
| 21:13.54 |
brlcad |
rewrote
low-level threading support so that it would cleanly support 10,000
threads multiplex seamlessly |
| 21:14.00 |
starseeker |
jeez |
| 21:14.19 |
starseeker |
does Haiku
manage any of that yet? |
| 21:14.20 |
brlcad |
hilarious dev
articles |
| 21:14.32 |
brlcad |
a few things,
but not much yet |
| 21:14.43 |
brlcad |
they've had a
mountain to climb just to reproduce the old api |
| 21:14.52 |
brlcad |
s/reproduce/reimplement/ |
| 21:14.56 |
starseeker |
nods |
| 21:14.59 |
brlcad |
without
optimizations |
| 21:15.09 |
starseeker |
who bought
the old BeOS code? |
| 21:15.13 |
starseeker |
Palm was
it? |
| 21:15.22 |
brlcad |
basically |
| 21:15.32 |
starseeker |
doesn't understand why they're still sitting on
it |
| 21:15.33 |
brlcad |
there were
some proprietary licensed portions too |
| 21:15.37 |
starseeker |
ah |
| 21:16.40 |
brlcad |
even if they
could give away some of the code, they'd be suceptible to
shareholder lawsuit |
| 21:16.52 |
starseeker |
mmm |
| 21:16.54 |
starseeker |
that
sucks |
| 21:17.03 |
brlcad |
long threads
about the be code |
| 21:17.12 |
brlcad |
lots of folks
wanted it |
| 21:17.24 |
starseeker |
remembers a few abortive attemps to buy it ala blender style,
but those never went anywhere either |
| 21:17.29 |
brlcad |
one even
tried (illegally apparently), which is where Zeta OS came
from |
| 21:18.35 |
starseeker |
oh, yeah. I
had forgotten them |
| 21:19.02 |
starseeker |
never made
any sense to me - it was clear if the OS was going to have any
chance at gaining mind share it would have to be as open
source |
| 21:20.22 |
starseeker |
brlcad: oh,
bty - know of any portable open source SIMD abstraction
layers? |
| 21:22.09 |
brlcad |
there are a
few projects related to abstraction, but it's pretty low level
effort |
| 21:22.43 |
starseeker |
ah. So, not
likely to be terribly useful? |
| 21:22.51 |
brlcad |
more work
designing the algorithms themselves and they're very closely tuned
to cache sizes, the algorithm at hand, and the capabilities of the
unit |
| 21:29.29 |
brlcad |
there's
projects like gcc's automatic vectorization and other more spansive
projects like OpenGL |
| 21:29.36 |
brlcad |
or the
variety of GPGPU libraries |
| 21:30.28 |
brlcad |
cuda, libsh,
brookgpu |
| 21:30.32 |
starseeker |
was just asking because these raytracing guys seem to like
SIMD if they want decent performance on
anything... |
| 21:31.33 |
brlcad |
guys? |
| 21:31.41 |
brlcad |
context? |
| 21:31.53 |
starseeker |
the Direct
raytracing of NURBS paper |
| 21:31.59 |
brlcad |
ah,
right |
| 21:32.08 |
brlcad |
very much
required to get the performance they were getting |
| 21:32.25 |
brlcad |
some of that
was stubbed in for sse2 |
| 21:32.53 |
brlcad |
include/vector*.h |
| 21:33.24 |
starseeker |
OK, so we
will need to do it ourselves then |
| 21:34.31 |
brlcad |
pretty
much |
| 21:34.38 |
starseeker |
needs to dig into this "create a tree of bounding boxes"
step |
| 21:34.53 |
starseeker |
not clear why
the performance was so bad on the openbook model |
| 21:34.56 |
brlcad |
the closest
you could probably get as a general system would be something like
opencl, but it's not clear what that would imply
dependencywise |
| 21:35.23 |
brlcad |
would think you'd need to understand that before making a
decision on how to improve it ;) |
| 21:35.34 |
starseeker |
exactly |
| 21:36.02 |
starseeker |
you're
referring to Khronos Group's OpenCL? |
| 21:36.42 |
brlcad |
yes |
| 21:36.53 |
CIA-28 |
BRL-CAD:
03brlcad * r34328 10/brlcad/trunk/include/raytrace.h: more
consistency cleanup |
| 21:37.04 |
``Erik |
hronos is
still around? |
| 21:37.35 |
brlcad |
very much
so |
| 21:37.37 |
starseeker |
well, at
least the license looks reasonable |
| 21:38.00 |
brlcad |
have a pretty
big presense at siggraph each year |
| 21:38.15 |
``Erik |
wow, I
thought they'd died off in the late 90's |
| 21:38.56 |
brlcad |
opencl is
also slated to be included in Mac OS X 10.6 so there are
expectations that library may take off in a big way |
| 21:40.02 |
brlcad |
starseeker:
dependencywise, I meant more what they take to be managed as a
dependency, like build issues, how well it actually works, whether
it's a special compilation pass or simply a library link, it's
longevity and portability, etc |
| 21:40.14 |
brlcad |
it'd
certainly require algorithm/code rewrites regardless |
| 21:40.16 |
starseeker |
ah |
| 21:51.29 |
elena |
i'll go now.
thank you all for your help. bye. |
| 21:51.48 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 21:55.03 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 22:29.53 |
brlcad |
was just the victim of a hit n' run |
| 22:30.21 |
madant |
brlcad:
seriously ? |
| 22:30.27 |
brlcad |
dammit,
really need to have video cameras installed |
| 22:30.29 |
brlcad |
madant:
yeah |
| 22:30.47 |
madant |
damn |
| 22:30.59 |
brlcad |
minor damage,
but seriously infuriating |
| 22:31.05 |
brlcad |
as I think it
was intentional |
| 22:31.15 |
madant |
you are ok
right ? |
| 22:31.28 |
brlcad |
yeah, it's to
the car, not me |
| 22:31.41 |
madant |
aah.
ok.. |
| 22:32.21 |
madant |
no way to
find out what happened or who did it ? |
| 22:32.24 |
brlcad |
I heard a
large truck backing up (the sort that beeps) and then take off
fast, which made me look out the window .. and I saw the
damage |
| 22:33.25 |
madant |
hmm. that
sucks .. insurance would cover the repairs etc. right ? |
| 22:33.31 |
brlcad |
yeah |
| 22:33.56 |
madant |
some people
are just evil :D |
| 22:34.25 |
madant |
just woke up all of a sudden at 4 am |
| 22:38.30 |
madant |
would the
police be able to track them ? you are filing a complaint right ? i
have no idea how the system works in US . |
| 22:42.43 |
Ralith |
starseeker:
that must have been what I read to lodge the idea in the first
place |
| 22:43.19 |
Ralith |
brlcad: I'm
kind of sad that that sort of error's mostly absent in the modern
world of software |
| 22:43.44 |
Ralith |
yeah, it's
only really practical when the user understands and can intuit
what's wrong anyway, but it just sounds fun. |
| 22:44.44 |
brlcad |
madant:
already filed and have the report, but nothing they can really do
about it given no eye witness |
| 22:45.24 |
Ralith |
brlcad: oh
damn :/ |
| 22:45.29 |
Ralith |
glad the
damage is minor. |
| 22:45.34 |
Ralith |
and
insured. |
| 22:53.33 |
madant |
hmm. yeah you
should implement the camera idea.. |
| 23:00.21 |
brlcad |
Ralith: what
sort of error? |
| 23:00.43 |
brlcad |
a little out
of context and not thinking clearly at the moment to follow that
response |
| 23:01.31 |
Ralith |
haiku
404s |
| 23:01.36 |
Ralith |
er, DNS
failures |
| 23:01.39 |
Ralith |
or whatever
that error was. |
| 23:01.52 |
Ralith |
netpositive's |
| 23:02.21 |
brlcad |
ahh |
| 23:02.28 |
brlcad |
okay, yeah,
that makes more sense now :) |
| 23:03.13 |
brlcad |
it was
generally an alternative (or in addition) to returning "Error: 404
Page not found" .. which is arguably just as cryptic :) |
| 23:06.51 |
Ralith |
yeah, but
familiar, and standard. |
| 23:07.00 |
Ralith |
in addition
would be cool. |
| 23:07.16 |
Ralith |
is of the opinion that the software world would be a nicer
place if humor abounded more freely in released
products |
| 23:41.10 |
starseeker |
Ralith: you
mean Windows isn't a joke? |
| 23:41.26 |
Ralith |
:P |
| 23:41.43 |
Ralith |
it is, but
sarcasm so extreme that it fools most of the world isn't my kind of
humor. |
| 23:41.51 |
starseeker |
brlcad: crap
- sorry to hear about the car :-( |
| 23:41.58 |
starseeker |
Ralith:
ah |
| 23:42.17 |
Ralith |
"Oh yeah,
*this* is a real OS! It's *exactly* what you need!" |
| 23:44.44 |
brlcad |
eep, /tmp:
out of inodes |
| 23:44.55 |
Ralith |
that sounds
bad |
| 23:48.19 |
brlcad |
yeah..
especially since I don't think it's 'actually' out of
inodes |
| 23:48.42 |
Ralith |
:| |
| 23:48.45 |
Ralith |
that sounds
*really* bad then |
| 23:49.47 |
brlcad |
hmm.. that's
not a root filesystem though.. might be able to fix that
one |
| 23:50.51 |
Ralith |
well, it is
/tmp; couldn't you just boot a livecd and nuke it? |
| 23:51.56 |
brlcad |
eh, this is a
dedicated server sitting down in florida |
| 23:52.01 |
brlcad |
maybe after a
20 hour drive :) |
| 23:52.13 |
madant |
heh
:P |
| 23:55.19 |
Ralith |
that does
indeed make things harder. |
| 23:55.38 |
Ralith |
perhaps some
cleverness with a temporary symlink to a dir on the root fs while
you unmount and nuke it? |
| 23:56.21 |
Ralith |
I can imagine
lots of things going wrong in the instant between deletion and
symlink creation, though |
| 23:56.33 |
Ralith |
then again,
they're probably going wrong anyway if the FS is
borked. |
| 00:11.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34358 10/brlcad/trunk/BUGS: good gravy nmgs render
absurdly slow. order of magnitude. seems to get worse the bigger
the smp too. included a lot of detail after
investigating. |
| 00:15.12 |
brlcad |
can't believe his eyes.. rt_nmg_shot() .. are you
serious? |
| 00:16.35 |
``Erik |
heh,
nmg_manifolds() ? |
| 00:17.10 |
brlcad |
no, look near
the end of shot.. |
| 00:17.14 |
``Erik |
or going
through and verifying that it's a valid NMG before bothering to
shoot? |
| 00:17.31 |
``Erik |
"build table
indicating"...? |
| 00:18.52 |
brlcad |
that's
prep |
| 00:19.59 |
``Erik |
oh heh :D
wrong func |
| 00:20.25 |
``Erik |
bu_calloc(),
nifty |
| 00:20.40 |
brlcad |
per
ray |
| 00:20.46 |
brlcad |
and the size
isn't even dynamic |
| 00:20.51 |
``Erik |
yeah, instead
of grabbing some off the stack |
| 00:21.10 |
brlcad |
it's crazy,
makes me think I have to be missing something |
| 00:22.01 |
``Erik |
hrm |
| 00:22.08 |
``Erik |
the size is
dynamic |
| 00:22.25 |
``Erik |
prep
calculates a maximum possible number of hits |
| 00:22.38 |
``Erik |
it should
probably be allocated at prep and retained in the soltab or
something |
| 00:22.40 |
brlcad |
per sho()
it's not |
| 00:22.43 |
brlcad |
shot() |
| 00:22.52 |
brlcad |
I mean, it's
not dynamic per ray |
| 00:22.56 |
``Erik |
right, but
it's not a compilable static |
| 00:22.57 |
brlcad |
it's fixed to
the model size |
| 00:23.09 |
brlcad |
right, yeah,
didn't mean that |
| 00:23.21 |
``Erik |
rt_nmg_ialloc() is probably where it
should be allocated (once) |
| 00:24.04 |
``Erik |
but that'll
run up the memory footprint :/ (shouldn't be an issue these days,
but that might've been the thinking a the time) |
| 00:25.42 |
brlcad |
I know nmgs
are second-class citizens, but it's really bad the way it
is |
| 00:25.52 |
brlcad |
not any worse
than it is now |
| 00:26.03 |
``Erik |
huh? |
| 00:26.13 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 00:26.17 |
brlcad |
it's calling
that malloc per shot() which is per thread |
| 00:26.26 |
brlcad |
8 threads, 8
callocs |
| 00:26.47 |
brlcad |
which
explains why it's a freaking order of magnitude slower than
bot |
| 00:26.48 |
``Erik |
right... you
kinda contradicted yourself there, though :D |
| 00:26.50 |
hippieindamakin8 |
hey
brlcad |
| 00:27.23 |
brlcad |
contradicted?
perhaps misunderstood or wires crossed.. |
| 00:27.53 |
``Erik |
oh, okie,
ordering issue |
| 00:27.53 |
brlcad |
you said
adding to rt_nmg_ialloc would run up the memory foot .. don't see
how any change will run up the foot print |
| 00:27.56 |
``Erik |
groks |
| 00:28.13 |
brlcad |
because it's
already about worst case |
| 00:28.56 |
brlcad |
now the only
question is whether that ray_data needs to have its own copy of the
hitmiss table |
| 00:29.00 |
``Erik |
if you have
100 nmgs in a scene, right now it allocates "big ugly" for each nmg
in order, so "push pop push pop", if each holds its own from prep,
it's push push pop pop |
| 00:29.24 |
``Erik |
no? |
| 00:30.45 |
brlcad |
not sure how
the rays interact with the model data exactly, but yeah that sounds
like that is a possibility |
| 00:31.00 |
``Erik |
and if ya
have 1000 nmg's, each gobbling up a meg for the hit table, taht's a
gig consumption *shrug* |
| 00:31.45 |
brlcad |
course right
now.. if you have 100 nmgs.. that's 100 * width * height
interleaved push/pops instead of just 100 |
| 00:32.48 |
``Erik |
*shrug* I
d'no what the common utilization is :) might be one of those things
where ya just have to try it and see if it breaks |
| 00:32.49 |
brlcad |
100 * width *
height being just average too .. could be much worse (overlapping
objects) |
| 00:33.14 |
brlcad |
either way,
performance is absolutely abysmal on a simple sphere |
| 00:33.18 |
``Erik |
is that mod a
'jr developer' task? |
| 00:33.24 |
brlcad |
make sph sph
; facetize -n sph.nmg sph |
| 00:35.19 |
``Erik |
wonders if he's screwing up by trying to find and save these
low hanging fruit tasks for new developers O.o |
| 00:39.57 |
CIA-28 |
BRL-CAD:
03brlcad * r34359 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
style consistency cleanup, ws, indent, comments. |
| 00:39.59 |
brlcad |
I wouldn't
think this was one regardless |
| 00:40.45 |
brlcad |
mucking about
in librt is rarely a simple task and should be "over tested" and
done so carefully regardless of the change |
| 00:41.46 |
CIA-28 |
BRL-CAD:
03brlcad * r34360 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
didn't mean to sneak in that ray_data. |
| 00:44.49 |
``Erik |
of course,
mucho testing, but the change should be quite simple
*shrug* |
| 00:47.38 |
brlcad |
i think your
experience is blinding you, or we have very different thoughts on
simple tasks |
| 00:49.02 |
``Erik |
hm, I'm
thinking folk who have a nontrivial background in C development but
are new to BRL-CAD |
| 00:49.20 |
brlcad |
requires
knowledge of optimization, profiling, testing, lots of librt (wtf
is a hitmiss, what's a ray_data) to know what to change and how
that will impact, to even know that shot() and prep() are and how
they interact, etc |
| 00:50.15 |
``Erik |
the poolios,
not the irix64s :D *duck* |
| 00:50.28 |
brlcad |
then yeah,
different level |
| 00:51.07 |
*** join/#brlcad piksi_ (i=piksi@pi-xi.net) |
| 00:51.08 |
brlcad |
I'm thinking
someone with just a couple years coding experience at most, after
intro C at a uni, maybe OO, maybe a couple projects |
| 00:51.42 |
``Erik |
http://www.freebsd.org/projects/ideas/
is my mental model here |
| 00:51.51 |
brlcad |
something
that doesn't generally require much planning or
research |
| 00:52.02 |
``Erik |
that's what
the "junior kernel hacker TODO list" grew into |
| 00:52.33 |
``Erik |
competency
expected, but a mentor is assigned to help ease one into the
twisted dark world of kernel development |
| 00:52.34 |
``Erik |
:D |
| 00:53.46 |
brlcad |
what they
mean by junior is something else entirely |
| 00:54.07 |
brlcad |
someone not
yet in the core, not yet proven, regardless of ability |
| 00:54.24 |
brlcad |
to me, the
delineation is more about ability |
| 00:54.36 |
brlcad |
we have
plenty of "simple" tasks |
| 00:54.40 |
``Erik |
well, someone
without a commit bit... core is more a guidance body than a
development team |
| 00:55.20 |
``Erik |
*shrug*
depends on the target audience, I suppose :) BRL-CAD is not exactly
a sophmore project |
| 00:56.13 |
brlcad |
it's not, but
the point is that there are plenty of tasks that don't require more
than freshman knowledge, tasks that would be immensely
helpful |
| 00:56.22 |
brlcad |
but are
time-consuming and low-priority |
| 00:57.07 |
``Erik |
yeah, we had
a list of tasks with both technical ability and effort required
rated at some point, is that still floating around? |
| 00:57.23 |
``Erik |
like a 1-5
scoring iirc |
| 00:57.33 |
brlcad |
yeah, it's in
doc iirc, but it wasn't well organized |
| 00:57.38 |
brlcad |
or at least
was |
| 00:57.51 |
``Erik |
mebbe that's
wiki meat |
| 00:58.03 |
brlcad |
probably
really just need to add complexity to our todo list and expand it
with more ideas |
| 00:58.11 |
``Erik |
doc/ seems to
elude a lot of people O:_) |
| 00:59.33 |
``Erik |
(I've seen
projects transpose characters in their URL to act as a screen, btu
I don't wanna be 'that' project... *shrug*) |
| 00:59.43 |
brlcad |
another
relevant project: http://janitor.kernelnewbies.org/ |
| 01:00.52 |
``Erik |
yeh, I d'no,
:) we might not have the pool of interested people to make an
effort like that time effective *shrug* I d'no |
| 01:01.11 |
brlcad |
more inline
with ability in mind .. checking for consistent return codes,
function name consistency, api completeness (if you have an alloc
routine, you should have a free routine, etc), static functions,
etc |
| 01:02.07 |
``Erik |
heh, -Wall
-Werror -W -ansi -pedantic |
| 01:02.13 |
``Erik |
and valgrind,
pheer |
| 01:02.28 |
brlcad |
yeah, see
that is stuff just about anyone can hit up |
| 01:02.36 |
brlcad |
and really is
a great way to get familiar and get started |
| 01:03.09 |
brlcad |
then tackling
a simple project is probably the next step up |
| 01:03.58 |
``Erik |
(if someone
has more than 4 gigs on a 64b system, I'd kinda like to see someone
stub a 4gb allocate in main() and fill the pages to verify we're
64b safe... I hav ea gut feeling that we use unsigned int when we
should use void * or size_t) |
| 01:05.20 |
``Erik |
I looked
around your car and didn't see any damage, didja get it repaired
already? |
| 01:06.13 |
brlcad |
nope, I just
cleaned it up well |
| 01:06.24 |
brlcad |
it's on the
front |
| 01:06.37 |
``Erik |
hm, I did
notice that wart growing out of your grill |
| 01:06.58 |
``Erik |
didja get a
30 day fixit ticket? |
| 01:09.16 |
``Erik |
2 more weeks
or so before I get mine back :( |
| 01:10.34 |
poolio |
``Erik: hey
now, hey now. |
| 01:10.48 |
``Erik |
hey then, hey
then O.o :D |
| 01:12.11 |
*** join/#brlcad LarsG
(n=lars@nusnet-228-5.dynip.nus.edu.sg) |
| 01:12.56 |
``Erik |
glares at doc/docbook/ some |
| 01:13.26 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 01:16.37 |
starseeker |
``Erik: now
what'd it do? |
| 01:17.11 |
``Erik |
too many
directories with a single operation |
| 01:17.18 |
starseeker |
yeah,
agreed |
| 01:17.37 |
starseeker |
needs to fix that... |
| 01:17.50 |
starseeker |
right after I
figure out what I did with tire... |
| 01:17.59 |
``Erik |
bought a dual core lappie, gets strusfrated when he's cpu
blocked without cooking them both :D |
| 01:18.18 |
starseeker |
:-) |
| 01:20.17 |
brlcad |
``Erik: no,
they don't give fixits just fines |
| 01:20.44 |
``Erik |
huh, lame, I
was told that they give a fixit and 30 days to show it was done
:/ |
| 01:21.00 |
brlcad |
testing it
out, not really happy with it |
| 01:21.10 |
``Erik |
half the cars
in my cul de sac don't have front plates |
| 01:21.34 |
``Erik |
given that a
sheriff and state trooper live here and there's no issue, I'm under
the impression that it's not a very enforced law |
| 01:21.41 |
brlcad |
said I was
going to wait until I was stopped at least four of five times, that
has already happened |
| 01:21.52 |
brlcad |
still putting
in for an exemption request |
| 01:22.13 |
brlcad |
gets too much
attention |
| 01:22.16 |
``Erik |
it is an
attention grabbing vehicle... |
| 01:22.31 |
``Erik |
I'm sure it's
just an excuse so they can look it over |
| 01:22.49 |
brlcad |
for most of
them, it was |
| 01:22.58 |
``Erik |
the sedate
appearance is one of the things that drew me to the m3 |
| 01:23.00 |
brlcad |
warnings,
wagging fingers, etc |
| 01:23.19 |
brlcad |
as they
rubbed the drool off |
| 01:24.10 |
brlcad |
anyways,
still trying to figure out a workable solution |
| 01:25.27 |
*** join/#brlcad samrose
(n=samrose@c-24-56-196-90.chrlmi.cablespeed.com) |
| 01:25.58 |
``Erik |
find a state
that doesn't require a front plate? :D |
| 01:27.14 |
brlcad |
PA |
| 01:27.18 |
brlcad |
WVa |
| 01:28.01 |
``Erik |
pa is doable,
wv is a bit of a commute :D plus ya went and bought a house
heh |
| 01:28.22 |
``Erik |
shoulda
bought a house up in pa with a garage, dude ;) *duck* |
| 01:29.02 |
``Erik |
just imagine,
you coulda started carpooling with ww when the rotational is
over! |
| 01:29.41 |
``Erik |
thinks he's getting his ass kicked
tomorrow |
| 01:30.36 |
brlcad |
hell, I
wouldn't move |
| 01:30.47 |
brlcad |
just get a
residence address, enough for a license |
| 01:31.03 |
brlcad |
PA would
drive me insane, not for me |
| 01:31.17 |
brlcad |
I'd take no
garage over that any day |
| 01:34.13 |
``Erik |
you don't
HAVE to become amish to live in pa, y'know... it helps, but it's
not mandatory... :D |
| 01:35.24 |
brlcad |
nope, I'm a
city bug |
| 01:35.50 |
``Erik |
philly isn't
a city? :D |
| 01:36.10 |
brlcad |
has a lot of
good rowing |
| 01:36.17 |
``Erik |
<-- likes
to be near a city, but at the edge of suburbia where it turns into
farmland |
| 01:37.07 |
brlcad |
I love
knowing I can bike or even walk to just about anything that I
need |
| 01:37.18 |
brlcad |
essentials,
recreation, whatever |
| 01:37.31 |
``Erik |
peaceful calm
slow home life, but can drive down into the city to hit a show or
whatever |
| 01:37.56 |
brlcad |
and dullards
not all going to bed at 9pm, finding something more than taco bell
open to eat at 3am |
| 01:38.23 |
``Erik |
is old, woke up at 5am the last few days wtih no alarm
:( |
| 01:38.34 |
brlcad |
so did I
:P |
| 01:38.40 |
``Erik |
can't be
arsed to drive to denny's, but ... |
| 01:38.54 |
``Erik |
I said am,
not pm :D |
| 01:38.58 |
brlcad |
to each their
own, it's just not what makes me happy |
| 01:39.05 |
``Erik |
*nod* |
| 01:39.34 |
``Erik |
I'm annoyed
enough at hearing my neighbors here, *shrug* |
| 01:41.01 |
yukonbob |
hello,
#brlcad |
| 01:42.17 |
brlcad |
howdy
yukonbob |
| 01:42.38 |
yukonbob |
saw a funny bumper sticker other day "Honk if you're
Amish" |
| 01:43.31 |
yukonbob |
contemplates reading 3-4 days of scrollback
:P |
| 01:44.08 |
``Erik |
there was a
large amish community near springfield mo, the stores right on the
road were ripoffs, but if you drive down the gravel roads for a
bit, there was a totally awesome bulk store, good stuff
:) |
| 01:46.44 |
brlcad |
tries a quick nmg hack |
| 01:46.58 |
``Erik |
the memory
thing? |
| 01:47.20 |
``Erik |
had to distclean and autoreconf, too much crap has changed
:/ |
| 01:47.27 |
brlcad |
damn, no
different |
| 01:47.35 |
``Erik |
starseeker:
http://paste.lisp.org/display/79377
try not to laugh too hard |
| 01:52.10 |
starseeker |
urm.
surprised there's no solution to the date thing already
implemented |
| 01:52.39 |
``Erik |
I looked
around, couldn't find one... I just posted it to #ucw, haven't
gotten my beatdown yet |
| 01:54.36 |
``Erik |
http://crit.brlcad.org:9090/dinreedit
is the result |
| 01:55.35 |
CIA-28 |
BRL-CAD:
03brlcad * r34361 10/brlcad/trunk/BUGS: problem narrowed down even
further. nmg hit/miss book keeping just sucks in a major way. quick
test showed a tangible 3x increase, but will require a fair bit of
restructuring. |
| 01:56.18 |
yukonbob |
notes "bookkeeping" is one word |
| 01:56.59 |
brlcad |
and book
keeping it two words, it's late but not that late ;) |
| 01:57.16 |
``Erik |
fight! fight!
fight! |
| 01:57.17 |
brlcad |
keeps his books away from yukonbob |
| 01:57.42 |
yukonbob |
heh |
| 01:57.57 |
yukonbob |
was trying to parse that sentence and had to do
double-take |
| 01:58.03 |
yukonbob |
(or is that
doubletake?) |
| 01:58.20 |
``Erik |
double::take; |
| 01:58.24 |
yukonbob |
heh |
| 01:58.36 |
yukonbob |
double
take; |
| 01:58.51 |
yukonbob |
take =
bookkeeping(); |
| 01:59.24 |
``Erik |
allyourbookkeepingarebelongtome |
| 01:59.29 |
``Erik |
Icanhasbookkeeping? |
| 01:59.40 |
yukonbob |
in soviet
russia, books keep YOU! |
| 02:00.19 |
``Erik |
y'know, he
ended up in branson |
| 02:00.35 |
``Erik |
about half an
hour drive from where I used to live :) |
| 02:01.29 |
``Erik |
someone
really didn't like the ucw link O.O |
| 02:01.46 |
``Erik |
(yet no one
is adding links, bummer) |
| 02:39.56 |
*** join/#brlcad kanzure
(i=bryan@66.112.232.233) |
| 02:58.44 |
starseeker |
``Erik: nice
work with the lisp site! |
| 02:59.03 |
starseeker |
is jealous - ``Erik has actually made lisp do something
useful |
| 03:08.45 |
``Erik |
ô´heh |
| 03:10.03 |
``Erik |
I'm an 80's
coder... I code to get shit done, not to code... |
| 03:16.33 |
Ralith |
I code to
cause jellied donuts to spontaneously appear. |
| 03:19.59 |
``Erik |
see, that's
the thing... back in THE DAY </reverb>, we didn't care of
jellied donuts appeared... it was nice when they did, but that
wasn't the goal |
| 03:22.51 |
Ralith |
if jellied
donuts weren't the goal you were doing something wrong |
| 03:23.38 |
``Erik |
heh |
| 03:23.44 |
``Erik |
don't make me
stab you. |
| 03:24.09 |
Ralith |
I've got
powdered sugar and I know how to use it! |
| 03:24.53 |
PrezKennedy |
heheh 80's
coder |
| 03:25.16 |
PrezKennedy |
gettin shit
done in FORTRAN :) |
| 03:28.02 |
``Erik |
bitch, I will
beat your ass down |
| 03:28.27 |
``Erik |
C is a 60's
language, LISP is a 50's language, scheme is a 70's language,
... |
| 03:28.52 |
``Erik |
smalltalk is
70's, objc and c++ are early 80's |
| 03:30.00 |
brlcad |
yawns |
| 03:32.36 |
``Erik |
tsa is old
news... I don't think there has been any real advancement since
around '85 or so :( |
| 03:51.19 |
starseeker |
stares at his ellipse equations and wonders why they heck
they are working... |
| 03:52.55 |
starseeker |
oh |
| 03:52.57 |
starseeker |
right |
| 03:55.55 |
PrezKennedy |
``Erik, you
should program with a 90's language... like Java! ;) |
| 04:29.58 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 04:55.11 |
starseeker |
hmm... these
are going to be big enough and elaborate enough to need more room
than I originally thought. |
| 05:18.07 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 05:24.58 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 05:43.56 |
*** join/#brlcad madant
(n=d@117.196.130.56) |
| 05:46.05 |
madant |
are things
all right in california ? declaration of emergency has pretty bad
connotations in india .. |
| 05:53.43 |
madant |
hope this
swine flu episode ends pretty soon.. flus are such a pain in
humanity's ass to control.. |
| 05:54.23 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 06:06.43 |
pacman87 |
starseeker:
what ellipse equations? |
| 06:13.23 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 06:13.24 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 06:16.49 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 06:38.22 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 07:14.51 |
*** part/#brlcad LarsG
(n=lars@nusnet-228-5.dynip.nus.edu.sg) |
| 07:19.41 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14CED9.dip.t-dialin.net) |
| 07:44.17 |
*** join/#brlcad piksi_ (i=piksi@pi-xi.net) |
| 08:04.32 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 08:37.12 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:38.19 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 10:05.11 |
madant |
how
mafm |
| 10:05.17 |
madant |
oops.. howdy
:) |
| 10:11.48 |
mafm |
hai |
| 10:35.53 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 11:48.44 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-67.sbndin.btas.verizon.net) |
| 12:07.13 |
starseeker |
pacman87: the
ones solved by the tire tool |
| 12:08.55 |
``Erik |
now make this
tread:
http://www.apothema.gr/files/productImages/pilot_sportPILOT%20SPORT.jpg |
| 12:08.56 |
``Erik |
:D |
| 12:10.50 |
alex_joni |
``Erik:
http://www.popsci.com/files/imagecache/article_image_large/files/articles/auto_tire485.jpg |
| 12:11.56 |
``Erik |
heh, the
twheel, those're neat |
| 12:12.07 |
alex_joni |
nice to model
;) |
| 12:12.16 |
``Erik |
tehre's a
video where they slapped those on a high perfomrance mb |
| 12:12.23 |
``Erik |
but they
never showed it actually running, just slowly driving |
| 12:13.34 |
alex_joni |
http://www.geek24.com/g/twheel-airless-wheel-technology-from-michelin
<- from 2006, it is kinda working I think |
| 12:13.48 |
``Erik |
http://www.youtube.com/watch?v=iOSAQjCbXZE |
| 12:15.05 |
``Erik |
wants to see what they do when put under extremes, like track
driving |
| 12:57.16 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:00.44 |
``Erik |
*sigh* I made
two collosal mistakes. 1) I read the comments on slashdot. 2) I
looked up this 'boxxy' mentioned in a comment and now I am ... dain
bramaged? |
| 13:01.36 |
``Erik |
I THINK it's
a parody, but it's ... |
| 13:20.02 |
*** join/#brlcad dreeves
(n=IceChat7@64.178.177.71) |
| 13:35.28 |
*** join/#brlcad madant
(n=d@117.196.130.38) |
| 13:57.00 |
``Erik |
the maddest
ant of the all :D |
| 14:08.50 |
madant |
:P |
| 14:10.06 |
``Erik |
them all,
even |
| 14:54.26 |
CIA-28 |
BRL-CAD:
03bob1961 * r34362 10/brlcad/trunk/src/libged/rotate_arb_face.c:
Handle special cases for arb4 and arb6. |
| 15:54.33 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:07.02 |
*** join/#brlcad ``Erik_
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:28.22 |
``Erik |
watches b5 |
| 16:31.51 |
``Erik |
this is...
actually... really bad... |
| 16:45.41 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:13.57 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 17:33.41 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 17:40.26 |
``Erik |
(alpha
(beta)) == <alpha><beta></beta></alpha>
... |
| 17:40.34 |
``Erik |
woops, wrong
winder |
| 17:50.59 |
brlcad |
hello
d_rossberg |
| 17:56.44 |
d_rossberg |
waves from home |
| 17:59.17 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:00.03 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:00.09 |
brlcad |
happy
Walpurgisnacht eve |
| 18:01.03 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:02.03 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:03.15 |
d_rossberg |
:) it's the
"Freinacht" in Bavaria |
| 18:04.01 |
CIA-28 |
BRL-CAD:
03bob1961 * r34363
10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Minor
cleanup. |
| 18:04.40 |
d_rossberg |
and tomorrow
our village gets a new maypole |
| 18:05.07 |
d_rossberg |
(sorry, i
mean on May 1st) |
| 18:05.27 |
CIA-28 |
BRL-CAD:
03bob1961 * r34364 10/brlcad/trunk/src/tclscripts/archer/ (5
files): Added code for prompting the user for a rotation point when
rotating an arb face. |
| 18:05.32 |
brlcad |
maypole? |
| 18:05.43 |
brlcad |
ahh |
| 18:05.48 |
brlcad |
interesting,
never seen one |
| 18:06.00 |
brlcad |
well, maybe I
have, but I certainly don't remember -- was too young |
| 18:07.41 |
d_rossberg |
they are very
commonly here |
| 19:14.33 |
pacman87 |
hi
d_rossberg |
| 19:33.00 |
d_rossberg |
hi
pacman87 |
| 19:34.51 |
d_rossberg |
i'm your
mentor again |
| 19:35.26 |
pacman87 |
so i've
noticed :) |
| 19:35.28 |
d_rossberg |
but i think
you know better than i what you have to do this GSoC |
| 19:35.40 |
d_rossberg |
;) |
| 19:36.03 |
pacman87 |
i'll try to
keep my dev log updated |
| 19:36.43 |
d_rossberg |
and maybe i
can give some advices on higher order geometry |
| 20:10.47 |
CIA-28 |
BRL-CAD:
03bob1961 * r34365
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Catch calls
to toggleTreePath to so that mRestoringTree gets set back to
0. |
| 20:17.37 |
CIA-28 |
BRL-CAD:
03bob1961 * r34366
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Override the kill
command in ArcherCore in order to remove any edit panels associated
with the object(s) being killed/deleted. Will need to look at other
commands that kill/delete objects from the database. |
| 20:48.04 |
CIA-28 |
BRL-CAD:
03starseeker * r34367
10/brlcad/trunk/src/libged/tire.c: |
| 20:48.04 |
CIA-28 |
BRL-CAD: Add
more detailed commentary on the precise nature of the constraints
imposed to |
| 20:48.04 |
CIA-28 |
BRL-CAD:
define the elliptical torus shapes in the tire tool. The equations
don't make |
| 20:48.04 |
CIA-28 |
BRL-CAD: some
of the sources of the constraints or the reasons they were used
immediately |
| 20:48.04 |
CIA-28 |
BRL-CAD:
apparent. |
| 20:56.53 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 21:31.49 |
starseeker |
``Erik: what
are your tire dimensions again? |
| 21:40.21 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 21:53.36 |
starseeker |
255-40R18? |
| 23:09.19 |
starseeker |
brlcad: did
something about rt_sketch_internal change? |
| 23:09.38 |
starseeker |
I'm betting a
bad pointer crash on sketch.c line 1868 |
| 23:09.43 |
starseeker |
er
getting |
| 23:34.55 |
``Erik |
255/40-18 |
| 23:35.13 |
``Erik |
on the back,
225/45-18 up front |
| 23:35.26 |
starseeker |
WOULD be testing that, if the friggin thing wasn't bombing
all of a sudden |
| 23:39.45 |
starseeker |
what
the... |
| 23:39.53 |
starseeker |
``Erik: do
you have a recent compile? |
| 23:43.20 |
starseeker |
reverts - no time for this now |
| 00:29.34 |
starseeker |
is afraid to ask |
| 00:30.15 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 00:32.32 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 01:31.47 |
CIA-28 |
BRL-CAD:
03starseeker * r34382 10/brlcad/trunk/configure.ac: (log message
trimmed) |
| 01:31.47 |
CIA-28 |
BRL-CAD: Need
src/conv/step in the list for Makefile generation. Attempts to
build as of |
| 01:31.47 |
CIA-28 |
BRL-CAD:
r34379 seems to suggest that there are missing files that need to
be checked in |
| 01:31.47 |
CIA-28 |
BRL-CAD: to
get a working src/conv/step build - ssince src/conv/step is
currently keying |
| 01:31.47 |
CIA-28 |
BRL-CAD: off
the BUILD_STEP variable (which bty it shouldn't do that forever -
in theory |
| 01:31.50 |
CIA-28 |
BRL-CAD: it
should check for a system install if BUILD_STEP is off) turn off
STEP |
| 01:31.52 |
CIA-28 |
BRL-CAD:
altogether until it the rest of the necessary files get checked in.
This is a |
| 01:35.10 |
CIA-28 |
BRL-CAD:
03starseeker * r34383 10/brlcad/trunk/src/libtclcad/ged_obj.c:
Another instance of fb_pgflush - change to fb_flush |
| 01:36.44 |
starseeker |
makes a note to mention the svn status command to
indianlarry... |
| 01:45.05 |
starseeker |
brlcad: Sean,
FB_WPIXEL in include.h seems to be using _fb_pgin and _fb_pgout -
I'm getting a linking error when I try to build libfb |
| 01:47.27 |
starseeker |
fb/fbgrid.c,
fbed/fbed.c and lgt/reflect.c are using FB_WPIXEL |
| 01:54.36 |
*** join/#brlcad madant_
(n=d@117.196.132.131) |
| 01:54.42 |
starseeker |
can we define
FB_WPIXEL in the fb_paged_io.c and export that? |
| 01:55.17 |
starseeker |
isn't sure how that works for inline versions of
things... |
| 02:00.16 |
brlcad |
hm,
looking |
| 02:03.48 |
starseeker |
er,
include/fb.h rather |
| 02:03.58 |
brlcad |
nods |
| 02:05.53 |
brlcad |
that's three
very obscure tools .. they can probably just use fb_wpixel
instead.. I really doubt the "inline" performance boost is
signficant any longer |
| 02:06.06 |
starseeker |
alrightie |
| 02:06.09 |
starseeker |
want me to
get it? |
| 02:06.17 |
starseeker |
q |
| 02:06.19 |
starseeker |
whoops |
| 02:07.05 |
brlcad |
you can if
you beat me to it, but it's my mess to clean up |
| 02:07.21 |
starseeker |
is stubbornly working towards a build ;-) |
| 02:16.47 |
CIA-28 |
BRL-CAD:
03starseeker * r34384 10/brlcad/trunk/ (4 files in 4 dirs): Remove
inline version of fb_wpixel, change calls to non-inline version -
speed change is likely not significant any longer and the inline
version requres exposure of fb_pgin and fb_pgout |
| 02:17.27 |
brlcad |
oof,
heh |
| 02:17.55 |
brlcad |
beat me to it
by mere seconds |
| 02:18.18 |
starseeker |
heh, sorry
:-) |
| 02:18.32 |
brlcad |
no matter,
trivial change |
| 02:18.36 |
brlcad |
but
thanks |
| 02:18.46 |
starseeker |
np
:-) |
| 02:19.21 |
*** join/#brlcad madant
(n=d@117.196.130.67) |
| 02:20.51 |
starseeker |
sighs in relief |
| 02:20.56 |
starseeker |
on the docs
now |
| 02:21.09 |
starseeker |
brlcad: is
that an ok hack for the step build until monday? |
| 02:21.20 |
starseeker |
either I'm
nuts or there's a bunch of files not committed yet |
| 02:21.38 |
starseeker |
(or
both) |
| 02:24.10 |
CIA-28 |
BRL-CAD:
03brlcad * r34385 10/brlcad/trunk/ (doc/deprecation.txt
include/fb.h): deprecate FB_WPIXEL since it's been around for such
a long time 'just in case'. |
| 02:25.54 |
brlcad |
starseeker:
good enough for now, sure |
| 02:26.01 |
CIA-28 |
BRL-CAD:
03starseeker * r34386 10/brlcad/trunk/src/other/step/src/
(exppp/Makefile.am express/Makefile.am): Whoops. Commit fixes for
src/other/step Makefile.am files so they will work with multiple
processor building. |
| 02:26.57 |
starseeker |
brlcad: OK,
we'll be nice about it ;-) |
| 02:27.44 |
starseeker |
waves broadsword wildly over his head with manical look in
his eyes - "Cut 'em out!" |
| 02:28.45 |
starseeker |
now, let's
see what happens with tire... |
| 02:30.31 |
starseeker |
ERROR: bad
pointer x9b474b0: s/b rt_sketch_internal(x736b6574), was
Unknown_Magic(x65787472), file
../../../brlcad/src/librt/primitives/sketch/sketch.c, line
1868 |
| 02:32.29 |
brlcad |
starseeker:
that's very interesting |
| 02:33.02 |
brlcad |
this is why
magic numbers are so useful :) |
| 02:34.14 |
brlcad |
if you look
up the unknown magic, it's very insightful |
| 02:34.53 |
brlcad |
and that line
number is telling, has to be related to the changes |
| 02:35.48 |
starseeker |
libbu/magic.c? |
| 02:38.17 |
starseeker |
ah, got a
bomb trace that means something |
| 02:38.27 |
starseeker |
rt_sketch_ifree |
| 02:38.42 |
starseeker |
called from
rt_extrude_ifree |
| 02:39.13 |
brlcad |
did you look
at the unknown magic? |
| 02:39.50 |
starseeker |
I looked at
the c file - doesn't that mean it can't tell what it
is? |
| 02:40.05 |
brlcad |
not the c
file |
| 02:41.04 |
brlcad |
whenever you
see a magic code, you should look it up |
| 02:41.06 |
starseeker |
oh - that
number matches RT_EXTRUDE_INTERNAL_MAGIC? |
| 02:41.12 |
brlcad |
there ya
go |
| 02:41.24 |
starseeker |
erm |
| 02:41.24 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 02:41.29 |
brlcad |
so sketch's
ifree was called, but seemingly passed an extrude
object |
| 02:41.59 |
starseeker |
checks rt_extrude_ifree |
| 02:42.32 |
hippieindamakin8 |
waves at everybody and wishes |
| 02:42.35 |
brlcad |
obviously
related to my recent change, but tbd whether it's an init problem
now that it's going through the functab or some other
issue |
| 02:45.10 |
starseeker |
extrude.c:2321 is where the call is coming
from |
| 02:45.17 |
brlcad |
do you see
the bug :) |
| 02:45.38 |
starseeker |
giving it ip
of extrude? |
| 02:45.39 |
brlcad |
has it fixed, fwiw |
| 02:45.43 |
brlcad |
yep |
| 02:45.52 |
starseeker |
cool |
| 02:46.02 |
CIA-28 |
BRL-CAD:
03brlcad * r34387
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: free the
sketch that the extrude was using, not the extrude itself. and good
gravy, don't pass the extrude to sketch's ifree. |
| 02:46.13 |
brlcad |
copy-paste
bug of a var that just happened to work in that scope |
| 02:46.15 |
starseeker |
thanks! |
| 02:46.39 |
starseeker |
thanks for
the magic number tutorial - that helps :-) |
| 02:47.12 |
starseeker |
won that one :-P |
| 02:47.20 |
starseeker |
er you won
that one |
| 02:47.51 |
starseeker |
tests |
| 02:49.38 |
brlcad |
reviews the other ifree() mods in case similar mistakes were
injected |
| 02:49.41 |
starseeker |
../../../brlcad/src/librt/primitives/extrude/extrude.c:
In function 'rt_extrude_ifree': |
| 02:49.44 |
starseeker |
../../../brlcad/src/librt/primitives/extrude/extrude.c:2321:
error: incompatible type for argument 1 of
'tmp_ip.idb_meth->ft_ifree' |
| 02:49.50 |
brlcad |
bah |
| 02:49.53 |
brlcad |
still
compiling :) |
| 02:51.10 |
CIA-28 |
BRL-CAD:
03brlcad * r34388
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c:
poinnnterrrrrr |
| 02:51.33 |
starseeker |
&tmp_ip
rather than tmp_ip? |
| 02:51.38 |
brlcad |
there's
another thing noteworthy about your bad pointer message |
| 02:51.39 |
brlcad |
yes |
| 02:51.50 |
brlcad |
Unknown_Magic |
| 02:51.57 |
brlcad |
it's clearly
not "unknown" |
| 02:52.03 |
starseeker |
yes |
| 02:52.06 |
brlcad |
which means
the table is out of sync (and should be syncd) |
| 02:52.21 |
brlcad |
doesn't like that table |
| 02:52.31 |
brlcad |
needs to be a
better way to register magic numbers |
| 02:52.36 |
starseeker |
aaah. I was
wondering a little why it didn't go ahead and say something
useful... |
| 02:52.39 |
brlcad |
but C does
make that a pain |
| 02:53.15 |
starseeker |
that's the
magic.c table? |
| 02:54.00 |
starseeker |
looks at the Primitives section and his jaw
drops |
| 02:54.13 |
starseeker |
no eto, no
hyp, no sketch, no extrude... |
| 02:54.37 |
starseeker |
ouch |
| 02:55.43 |
starseeker |
checks first this time - you working on it
already? |
| 02:57.30 |
brlcad |
nope |
| 02:57.39 |
starseeker |
hops to it |
| 02:57.46 |
starseeker |
here magic.h
magic.h magic.h... |
| 02:58.32 |
brlcad |
I spent a
good bit of time cleaning up magic.h many moons ago, left magic.c
as an exercise to the reader |
| 02:59.49 |
brlcad |
magic.c isn't
maintainable as-is .. and it was way too much of a diversion to
make it something better at the time |
| 03:00.03 |
starseeker |
nods |
| 03:00.07 |
brlcad |
looks like
extrude was isolated.. |
| 03:00.08 |
brlcad |
-rt_sketch_ifree(&tmp_ip); |
| 03:00.09 |
brlcad |
+tmp_ip.idb_meth->ft_ifree(ip,
resp); |
| 03:00.26 |
starseeker |
yep,
sneaky |
| 03:08.34 |
CIA-28 |
BRL-CAD:
03starseeker * r34389 10/brlcad/trunk/src/libbu/magic.c: Gah -
update the magic.c list of primitives so the error messages know
about more primitives |
| 03:08.58 |
starseeker |
still
unmaintainiable, but hopefully slightly more useful |
| 03:13.33 |
CIA-28 |
BRL-CAD:
03starseeker * r34390 10/brlcad/trunk/src/libbu/magic.c: update
libbu magic.c entries while we're at it. |
| 03:17.10 |
*** join/#brlcad madant_
(n=d@117.196.132.175) |
| 03:17.26 |
CIA-28 |
BRL-CAD:
03starseeker * r34391 10/brlcad/trunk/src/libbu/magic.c: update nmg
magic.c entries. |
| 03:34.35 |
CIA-28 |
BRL-CAD:
03starseeker * r34392 10/brlcad/trunk/src/libbu/magic.c: and update
the rest of magic.c's entries. RT_CNURB and RT_SNURB are apparently
duplicates of other magic value definitions - leave the
originals |
| 03:34.41 |
starseeker |
there we
go |
| 03:35.12 |
starseeker |
yep, tire is
working again too |
| 03:35.15 |
starseeker |
awesome |
| 03:44.39 |
starseeker |
calls it a night |
| 04:14.47 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 05:58.39 |
*** join/#brlcad dreeves
(n=dreeves@64.178.177.71) |
| 06:27.24 |
dreeves |
hey so I
notice that breplicator and brep_cube is generating errors and not
generating the test case and did anyone get a chance to work on any
more test cases? |
| 06:35.13 |
starseeker |
dreeves:
beyond what I've got up on bz? |
| 06:35.28 |
starseeker |
I can make
some more - the current ones are showing errors last time I
looked |
| 06:35.53 |
starseeker |
haven't tried
the test cubes lately - what's the failure? |
| 06:36.20 |
starseeker |
gah.
|
| 06:36.34 |
starseeker |
must sleep now - will answer once consciousness is
regained |
| 06:38.42 |
dreeves |
starseeker I
have been busy on something else lately so if you have created more
then I don't know about them. The only one I'm finding is
brep_pinch |
| 06:39.55 |
dreeves |
I will go
check out bz |
| 07:40.27 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 08:23.51 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-239-152.dclient.hispeed.ch) |
| 08:24.05 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E546.dip.t-dialin.net) |
| 08:37.20 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 10:19.29 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:13.41 |
*** join/#brlcad madant
(n=d@117.196.130.130) |
| 11:50.23 |
starseeker |
dreeves:
everything other than nurbs_tests.g in http://bzflag.bz/~starseeker/nurbs_tests/
is "new" |
| 11:50.41 |
starseeker |
I don't have
the sh script set up to raytrace the new ones,
unfortunately |
| 12:30.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 12:31.31 |
CIA-28 |
BRL-CAD:
03brlcad * r34393 10/brlcad/trunk/src/proc-db/breplicator.cpp: turn
off the new face as the new face doesn't have the right UV trimming
parameters (domain is wrong iirc), but is still a good example for
understanding how the trims work. |
| 12:31.48 |
brlcad |
dreeves: that
last commit makes breplicator.cpp work again -- the new face that
was added was a trimming example |
| 12:40.59 |
CIA-28 |
BRL-CAD:
03brlcad * r34394 10/brlcad/trunk/src/proc-db/brep_cube.cpp: this
wasn't broken, just quirky. you had to provide an(y) argument or it
wouldn't write out the geometry file. the subsequent db_lookup
would then get passed a null dbip, causing a bomb to go
off. |
| 12:41.08 |
brlcad |
and that
'fixes' the brep_cube example (it wasn't broken, just
dumb) |
| 13:03.53 |
dreeves |
ok
thanks |
| 13:11.42 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 14:45.09 |
*** join/#brlcad madant
(n=d@117.196.128.102) |
| 18:18.03 |
CIA-28 |
BRL-CAD:
03brlcad * r34395 10/brlcad/trunk/TODO: libfb needs to have
fb_open_existing/fb_close_existing pushed up into the fb functab
and the #ifdef sections eliminated. |
| 18:44.30 |
CIA-28 |
BRL-CAD:
03brlcad * r34396 10/brlcad/trunk/src/conv/step/Makefile.am: this
still needs a lot of work. the built sources aren't declared
portably. add a BUILT_SOURCES section, sort, and make the vars
specify one-per-line. the fedex sources should be a noinst
lib. |
| 18:46.19 |
CIA-28 |
BRL-CAD:
03brlcad * r34397 10/brlcad/trunk/src/libfb/getput.c: remove the
vax section. DEPRECATE all of these routines as they are exactly
what libbu provides. |
| 18:51.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) [NETSPLIT
VICTIM] |
| 18:51.23 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 18:51.23 |
*** join/#brlcad CIA-28 (n=CIA@208.69.182.149.simpli.biz)
[NETSPLIT VICTIM] |
| 18:52.12 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 18:52.12 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 18:52.16 |
*** join/#brlcad madant (n=d@117.196.128.102) [NETSPLIT
VICTIM] |
| 19:02.23 |
CIA-28 |
BRL-CAD:
03brlcad * r34398 10/brlcad/trunk/include/bu.h: meh |
| 19:02.41 |
starseeker |
heh - that's
a bob commit message ;-) |
| 19:02.47 |
brlcad |
:) |
| 19:02.53 |
``Erik |
nah, too many
syllables |
| 19:02.58 |
madant |
hah |
| 19:14.01 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 19:14.01 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 19:15.07 |
CIA-28 |
BRL-CAD:
03brlcad * r34399 10/brlcad/trunk/ (include/pkg.h
src/libpkg/pkg.c): pkg_2send's buffers aren't modified. declare
them const. |
| 19:27.48 |
brlcad |
yeah, looks
like the few references I can find indicate a 20-30% acceptance
rate roughly |
| 19:27.58 |
starseeker |
ndos |
| 19:28.01 |
starseeker |
er nods
even |
| 19:28.04 |
brlcad |
the paper
rate is 15-20% |
| 19:28.13 |
brlcad |
varies
year/year |
| 19:28.20 |
starseeker |
not too
surprising really |
| 19:32.14 |
brlcad |
looks like
rate was 18% in 2008 if this random guy's count is
correct |
| 19:36.50 |
CIA-28 |
BRL-CAD:
03brlcad * r34400 10/brlcad/trunk/src/libfb/if_remote.c: convert
all fbputshort/fbputlong/fbgetshort/fbgetlong calls to the
corresponding libbu xdr routine (bu_pshort and friends), using
unsigned char pointers were appropriate and casting as needed when
going through libpkg. |
| 19:41.43 |
CIA-28 |
BRL-CAD:
03brlcad * r34401 10/brlcad/trunk/src/libfb/if_remote.c: ws style
indent comment cleanup |
| 19:50.00 |
*** join/#brlcad JucaBlues
(n=felipe@189.79.78.26) |
| 19:50.08 |
brlcad |
hello
JucaBlues |
| 19:50.14 |
JucaBlues |
hi! |
| 19:50.30 |
brlcad |
inkscape
always welcome ;) |
| 19:50.37 |
JucaBlues |
:-) |
| 19:51.05 |
JucaBlues |
I've been
looking at libdwg |
| 19:51.11 |
JucaBlues |
it is written
in esperanto!!! |
| 19:51.15 |
brlcad |
sorry to hear
that ;) |
| 19:51.31 |
JucaBlues |
we gotta fork
that! |
| 19:51.32 |
brlcad |
ahh, yeah..
it's got a lot wrong with it :) |
| 19:51.33 |
JucaBlues |
:-P |
| 19:51.46 |
brlcad |
aside from
dwg being a horrible format |
| 19:52.13 |
JucaBlues |
yeah, I know,
but we need to build the "bridge", dont we? |
| 19:52.29 |
brlcad |
there's lots
of bridges possible ;) |
| 19:52.56 |
brlcad |
dxf is
generally better and nearly as pervasive as dwg |
| 19:53.11 |
brlcad |
btw, there is
'opendwg' from the creative alliance |
| 19:53.28 |
brlcad |
mired in
legal woes with autodesk, but they're further along
iirc |
| 19:53.37 |
JucaBlues |
does brlcad
deal with both file formats? |
| 19:53.48 |
brlcad |
s/creative
alliance/open design alliance/ |
| 19:53.53 |
brlcad |
we deal with
dxf |
| 19:53.58 |
JucaBlues |
but opendwg
libs are proprietary... |
| 19:54.21 |
JucaBlues |
the only good
thing I see in opendwg is their documentation of reverse
engineering efforts |
| 19:54.46 |
brlcad |
dwg would be
'nice' ... but not necessary or a priority frankly given it's a
proprietary format that autodesk is intent on defending |
| 19:55.39 |
brlcad |
our more
current efforts have been towards beefing up dxf support (all 3d
entities, and now nearly all 2d entities) |
| 19:55.50 |
brlcad |
and in
implementing a full STEP conversion capacity |
| 19:55.56 |
brlcad |
that's our
hot one atm |
| 19:56.01 |
brlcad |
big
project |
| 19:56.30 |
JucaBlues |
not having
dwg support would lead to less poeple adopting freesoftware CAD
tools such as brlcad ? (in your opinion) |
| 19:56.33 |
brlcad |
curious, what
do you need dwg for? |
| 19:57.00 |
JucaBlues |
I am not a
CAD user |
| 19:57.07 |
JucaBlues |
I am a
developer wishing to help |
| 19:57.25 |
JucaBlues |
so, I am not
totally aware of users needs |
| 19:57.26 |
brlcad |
there are so
many proprietary CAD formats, no I don't think not supporting dwg
would be a major deciding factor for anyone -- it's more about
usability and features of the CAD system |
| 19:57.58 |
JucaBlues |
but it seems
to me that support for proprietary file formats would be good in
order to lower the barrier to adoption of free software
tools |
| 19:58.25 |
brlcad |
just about
every major CAD vendor has a massively popular proprietary format
that they default to .. dwg is only as visible as it is because of
autocad's big (30% or so) market share |
| 19:59.29 |
brlcad |
JucaBlues:
I'd certainly agree with you there .. it's more a matter of time
and priorities, and the payoff (in terms of
adoption/users/visibility/etc) |
| 20:00.47 |
brlcad |
we could
spend a lot of time trying to reverse engineer any of the top five
proprietary formats, or implement one of several major open
interchange formats (that most of the major CAD vendors support)
like STEP, IGES, and DXF |
| 20:01.25 |
brlcad |
the payoff is
much greater .. so long as they can export their data from their
system and import |
| 20:01.53 |
JucaBlues |
I have been
in touch with free software since my first years at university
(2003). Then, since mid-2007 I've been helping Inkscape. In the
university I've been advocating alot about freesoftware |
| 20:02.07 |
brlcad |
starseeker:
were you doing a build on mac or linux yesterday when you were
fixing src/conv/step? |
| 20:02.11 |
JucaBlues |
only now, in
2009, we have successfully founded a study group here |
| 20:02.16 |
starseeker |
brlcad:
mac |
| 20:02.20 |
brlcad |
huh,
odd |
| 20:02.24 |
starseeker |
why, is it
busted still? |
| 20:02.27 |
brlcad |
i'm getting
failures on the built sources |
| 20:02.29 |
brlcad |
yeah, it
is |
| 20:02.30 |
JucaBlues |
and we are
now focusing on cad tools |
| 20:02.31 |
starseeker |
arrrgh |
| 20:02.32 |
brlcad |
I can fix it,
though |
| 20:02.38 |
brlcad |
JucaBlues:
what sort of focus? |
| 20:02.59 |
JucaBlues |
we are trying
to figure out a way of helping free software CAD tools |
| 20:03.04 |
brlcad |
JucaBlues:
and glad to hear about the advocacy, good stuff ;) |
| 20:03.41 |
JucaBlues |
we are a
group of half dozen people and we meet once a week to discuss
it |
| 20:03.52 |
JucaBlues |
some of us
are coders |
| 20:04.05 |
brlcad |
that's where
I would emphasize interoperability through the few open standards
(if you preserve everything exported, users really don't
care) |
| 20:04.10 |
JucaBlues |
others are
more interested in political aspects of the free software
movement |
| 20:04.21 |
CIA-28 |
BRL-CAD:
03starseeker * r34402 10/brlcad/trunk/src/libged/tire.c: Sigh. Try
another tread pattern tweak for tire. |
| 20:04.28 |
brlcad |
STEP is the
big one that just about every single major CAD vendor adopted in
early 2000's |
| 20:04.50 |
brlcad |
that was a
massive ISO collaboration to 'solve' the interoperability problems
and proprietaryness |
| 20:05.16 |
brlcad |
the only
problem for open source is that ISO spec is freaking expensive and
enormous (as it's sort of the combination of all CAD formats into
one) |
| 20:05.31 |
brlcad |
fortunately
for us, though, we have it ;) |
| 20:05.35 |
JucaBlues |
expensive?! |
| 20:05.40 |
brlcad |
ISO |
| 20:05.45 |
JucaBlues |
isnt it
freely distributed just like SVG? |
| 20:05.46 |
brlcad |
iso sells
their specs |
| 20:05.54 |
brlcad |
like ISO
C |
| 20:06.13 |
brlcad |
you won't
just find the C standard floating around the web, you have to buy
it |
| 20:07.11 |
JucaBlues |
sad... |
| 20:07.35 |
brlcad |
but like I
said, not so much an issue with anyone that works with us on step
since we have copies of the specification, provided via ARL for
BRL-CAD use |
| 20:07.59 |
brlcad |
yeah, CAD is
one of the biggest industries that have the least open source
penetration |
| 20:08.08 |
brlcad |
and massive
vendor lock-in through proprietary formats |
| 20:08.22 |
brlcad |
even ISO STEP
is a massive step forward, *ahem* |
| 20:08.42 |
brlcad |
much better
than the alternatives |
| 20:09.20 |
brlcad |
but it's not
all about the file formats.. that's only a small piece to the
puzzle, and one I'd argue that's not nearly as important as, say,
usability and features |
| 20:09.33 |
brlcad |
usability in
particular |
| 20:09.37 |
JucaBlues |
can brlcad be
easily used for 2d architecture work? or is it really a CAD tool
focused in engineering ? |
| 20:10.37 |
brlcad |
it can be
(and has been) used for 2d and architecture work, it's just not an
area of emphasis (read: an area the current core devs focus
on) |
| 20:10.53 |
JucaBlues |
ok,
cool |
| 20:11.08 |
brlcad |
here's a
broad brush-strokes overview of the main areas being worked:
http://brlcad.org/BRL-CAD_Priorities.png |
| 20:11.46 |
brlcad |
turning
brl-cad into a fully hybrid modeler, bolstering the open source
community, improved infrastructure, and a better gui |
| 20:12.12 |
brlcad |
we have a ton
of functionality (more than blender believe it or not), but you
wouldn't know it given our gui/usability |
| 20:12.41 |
JucaBlues |
but it has
fundamental differences if compared to blender, right? |
| 20:12.57 |
brlcad |
so a lot of
work is going into strapping up a new interface, making the
existing binaries be plugin functionality to that new
interface |
| 20:13.05 |
brlcad |
absolutely |
| 20:13.10 |
brlcad |
blender is a
content modeler |
| 20:13.23 |
brlcad |
content
modelers are horribly suited for CAD work, at a fundamental
level |
| 20:14.37 |
brlcad |
akin to the
fundamental difference between other commercial content modelers
like 3D Studio MAX or even Maya .. compared to the likes of
AutoCAD, Solidworks, NX, CATIA, Pro/E |
| 20:14.43 |
brlcad |
night and
day |
| 20:14.57 |
brlcad |
the
similarities sort of end at "they both deal with
modeling" |
| 20:16.00 |
JucaBlues |
I got
impressed by brlcad statistics (such as 20 years old development
history). Does it still have funding from US government? Is the
core dev team employed to develop it? |
| 20:16.06 |
brlcad |
JucaBlues: so
do you have a goal or just surveying what's out there or looking
for a niche to work on or ..? |
| 20:16.45 |
brlcad |
yeah, the
project was started circa 1979, first release in 1984, so more than
25 years now |
| 20:17.01 |
brlcad |
it is still
majorly funded by ARL |
| 20:17.53 |
brlcad |
many of the
devs have full-time jobs with ARL, but not all, and even many of
those that are employed invest even more time outside of work of
their own volition |
| 20:18.44 |
JucaBlues |
we are
committed to using free software on one of our university labs (we
are the guys who removed MSWindows from those PCs) and now we have
to figure out how to provide free software solutions to the needs
of the projects that are developed in this lab |
| 20:19.07 |
brlcad |
I estimated a
while back that the open source contributors will probably exceed
the funded contributors in two or three years if our rate of
development continues to increase and the open source community
continues to grow (which would be awesome) |
| 20:20.34 |
brlcad |
well we are
the *only* open source CAD system that's actually in production
use, of production quality, but we are certainly very far off from
most of the commercial codes (particularly wrt usability)
too |
| 20:20.39 |
brlcad |
;) |
| 20:20.47 |
brlcad |
nice to hear
that commitment, though |
| 20:21.19 |
JucaBlues |
we figured
out that most of the projects there will need CAD. So we started
this research initially focusing on CAD tools. We nedd to (1) tell
them which free software they should use. (2) set up the machines
(install/compile it) and (3) provide guidance
(tutorials/courses) |
| 20:22.58 |
JucaBlues |
and we think
that we should code stuff in case we figure out that the available
solutions are still not enough |
| 20:23.11 |
brlcad |
our biggest
issue in terms of replacing something like autocad is drafting
facilities (2d sketch support needs more work), constraints and
parametric support (a GSoC project now for the second year), and
gui usability (huge overhaul effort under way) |
| 20:24.04 |
JucaBlues |
are there
tutorials available regarding the 2d stuff? where can I read more
about it? |
| 20:24.06 |
brlcad |
well if you
all decide that you're interested in working with brl-cad, you're
more than welcome any time |
| 20:24.36 |
brlcad |
I don't think
our goals are separate, more just only so many clock ticks per day
and existing core devs are pulled in dozens of directions with
goals :) |
| 20:24.49 |
brlcad |
mmm.. 2d
tutorials |
| 20:25.07 |
brlcad |
yeah .. there
are, but it really is sucky |
| 20:25.18 |
brlcad |
easier to
script their use than it is to use the gui |
| 20:25.24 |
brlcad |
unfortunately |
| 20:25.57 |
brlcad |
not sure
where they're at though.. hm. |
| 20:30.30 |
brlcad |
for what it's
worth, another reason the 2D support is minimal is that most of the
industry has moved away from utilizing a 2D drafting approach as
the foundation, instead modeling directly in 3D with 3D techniques
and deriving 2D as needed |
| 20:31.12 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:31.14 |
brlcad |
plus we're a
solid modeler, so 2D entities are totally second-class citizens ..
you can't do anything with them without an extrusion/sweep/revolve
operation to define a volume :) |
| 20:31.35 |
brlcad |
similar to
how the big-boys treat them, just with a worse 2D sketcher
:) |
| 20:33.38 |
JucaBlues |
(sorry ... I
was on telephone here) |
| 20:34.14 |
JucaBlues |
so... it is
cool to hear that there is 2d support even though it seems to be
minimal and not very user friendly |
| 20:34.15 |
brlcad |
np |
| 20:34.21 |
brlcad |
I rant from
time to time ;) |
| 20:34.32 |
brlcad |
yeah, the
support is totally there engine-wise |
| 20:34.37 |
brlcad |
gui-wise,
it's teh suck |
| 20:35.02 |
JucaBlues |
I am
participating on GSoC again this year (in inkscape), so I cant get
committed to another project right now |
| 20:35.26 |
brlcad |
that's why we
can import a DXF nearly faithfully, most of their entities (2d and
3d) transcribes to one of our entities |
| 20:35.28 |
JucaBlues |
but I will
inform my colegues about it |
| 20:35.36 |
brlcad |
cool |
| 20:35.51 |
brlcad |
well if you
want to dabble, or if they want to dabble, welcome to |
| 20:36.05 |
brlcad |
commit access
is an easy deal for competent folks :) |
| 20:36.20 |
brlcad |
what's your
gsoc project? |
| 20:36.26 |
JucaBlues |
ok. is there
a subset of the coders who are most familiar with the 2d stuff (gui
and core) ? |
| 20:36.37 |
JucaBlues |
who sould I
contact? |
| 20:37.00 |
brlcad |
best to just
ask in here or on the brlcad-devel mailing list, someone will chime
in |
| 20:37.09 |
brlcad |
highly likely
I will answer if someone else doesn't :) |
| 20:37.34 |
JucaBlues |
ok. are you
sort of a project leader? |
| 20:37.35 |
brlcad |
notes that tendancy even with hundreds of folks on the list
:P |
| 20:38.04 |
brlcad |
yeah |
| 20:38.33 |
JucaBlues |
May I know
your name? Or do you preffer the anonimity? |
| 20:38.41 |
brlcad |
i'm
Sean |
| 20:38.58 |
JucaBlues |
pleased to
meet you, Sean. I am Felipe Sanches. |
| 20:39.20 |
madant |
:) anonymity
.. synonymity rather :D |
| 20:39.24 |
brlcad |
likewise,
pleasure :) |
| 20:39.46 |
brlcad |
Christopher
Sean Morrison in full absurdity longness ;) |
| 20:39.53 |
JucaBlues |
I think that
it is rare to have such a great/fast feedback on other projects irc
channels |
| 20:40.26 |
brlcad |
oh chatter
here comes and goes too .. just depends what's going on, I was
between commits and almost always available on irc |
| 20:40.27 |
JucaBlues |
Felipe
Corrêa da Silva Sanches in full (mine is longer :-P) |
| 20:40.32 |
brlcad |
haha |
| 20:41.36 |
JucaBlues |
ah! My SoC
project this year is user interface improvements for CMYK
colorspace and ICC color profiles handling in Inkscape |
| 20:42.22 |
JucaBlues |
Last year I
worked on initial implementation of SVG Fonts support in Inkscape
(which is one of the features defined in the SVG 1.1
spec) |
| 20:42.26 |
brlcad |
cool, like
preference selection and applying to the current
project? |
| 20:43.32 |
JucaBlues |
color
transforming palettes and color pickers using the currently
selected target device color profile |
| 20:43.36 |
brlcad |
thinks it would be awesome to have a brl-cad composite
renderer that output svg ... mmm |
| 20:52.45 |
CIA-28 |
BRL-CAD:
03brlcad * r34403 10/brlcad/trunk/TODO: vector renderer ala rtedge
but with vectors instead of raster and with support for filled
regions. |
| 20:53.03 |
starseeker |
brlcad: that
needs nurbs, doesn't it? |
| 20:55.39 |
brlcad |
to be done
"well", yeah probably, but depends |
| 20:56.10 |
brlcad |
i mean rtedge
could probably do a fantastic job as it is |
| 20:56.36 |
brlcad |
with just
region tracking and interpolating a spline between contiguous
regions |
| 20:57.49 |
CIA-28 |
BRL-CAD:
03brlcad * r34404 10/brlcad/trunk/ (5 files in 3 dirs): get gone
getput() |
| 21:44.51 |
CIA-28 |
BRL-CAD:
03brlcad * r34405 10/brlcad/trunk/configure.ac: use single tick
quotes to avoid escaping |
| 21:49.02 |
CIA-28 |
BRL-CAD:
03brlcad * r34406 10/brlcad/trunk/src/conv/step/ (Makefile.am
needFunc.cc needFunc.h): |
| 21:49.03 |
CIA-28 |
BRL-CAD: this
should at least restore the build to a working state for now. make
it an |
| 21:49.03 |
CIA-28 |
BRL-CAD:
EXTRA_PROGRAMS so we can traverse into here even though the fedex
stuff isn't |
| 21:49.03 |
CIA-28 |
BRL-CAD:
being generated. (STEP_FEDEX_PLUS, STEP, and STEP_AP203 are not
subst'd) few |
| 21:49.03 |
CIA-28 |
BRL-CAD:
other minor changes are keeping 'sources' and headers declared
separately for |
| 21:49.05 |
CIA-28 |
BRL-CAD:
consistency. |
| 21:50.05 |
CIA-28 |
BRL-CAD:
03brlcad * r34407 10/brlcad/trunk/configure.ac: can traverse into
src/conv/step again (though it won't do anything due to the
EXTRA_PROGRAMS declaration) |
| 22:08.33 |
Ralith |
brlcad: that
*would* be really cool |
| 22:23.34 |
CIA-28 |
BRL-CAD:
03brlcad * r34408 10/brlcad/trunk/src/conv/step/Makefile.am: don't
even make them a clean rule so dist doesn't try to clean
them |
| 22:53.18 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 23:26.46 |
brlcad |
Ralith: so
you're ready to take it on? :) |
| 23:26.52 |
brlcad |
would be a
fun little project for someone |
| 23:26.54 |
Ralith |
hehe |
| 23:27.00 |
brlcad |
not even that
hard really |
| 23:27.14 |
Ralith |
perhaps once
I know my way around librt. |
| 23:27.29 |
Ralith |
or, even
better, once nurbs is working. |
| 23:27.46 |
brlcad |
even as a
sampled approximation, it would look pretty superb |
| 23:27.51 |
Ralith |
indeed. |
| 23:28.12 |
brlcad |
with nurbs,
you'd still have to figure out the projected contours and those
aren't so easy |
| 23:28.15 |
Ralith |
but then,
rtedge's output would give pretty good results just tracing using
standard tools, no? |
| 23:30.00 |
brlcad |
what do you
mean? |
| 23:30.45 |
Ralith |
vector
auto-tracers |
| 23:30.52 |
Ralith |
dunno what
they're called |
| 23:31.02 |
Ralith |
but like in
inskcape, you can just tell it to trace a bitmap |
| 23:31.07 |
Ralith |
inkscape* |
| 23:31.36 |
brlcad |
right now
rtedge fires rays at the model in a grid and looks at each neighbor
to a ray to determine if it's on an "edge" |
| 23:31.45 |
brlcad |
if it is, it
renders a pixel for that grid cell |
| 23:31.59 |
Ralith |
yes. |
| 23:32.03 |
Ralith |
and then you
take that render as an image |
| 23:32.10 |
Ralith |
and feed it
to a vector tracing tool. |
| 23:32.20 |
Ralith |
tracing as in
following the lines, not raytracing |
| 23:32.27 |
brlcad |
instead of
rendering a pixel, it'd probably need to instead store a spline
control point on that edge |
| 23:34.16 |
brlcad |
walking over
the grid of results, you could build up the 2d connected spline
paths, output as svg |
| 23:34.32 |
Ralith |
yeah |
| 23:34.35 |
brlcad |
little more
detail than that, but it's the jist |
| 23:34.56 |
Ralith |
I'm just
commenting that output as a plain bitmap could probably be
converted into a svg for pretty good results too |
| 23:35.07 |
Ralith |
albeit not
*as* good |
| 23:35.10 |
brlcad |
and if you
threw in some adaptive refinement sampling, the result would
probably be pretty indistinguishable from a projected
brep |
| 23:35.16 |
brlcad |
ahh |
| 23:35.17 |
brlcad |
yeah |
| 23:35.22 |
brlcad |
I tried that
a few years ago |
| 23:35.31 |
brlcad |
it was pretty
bad |
| 23:35.59 |
brlcad |
reconstructing connectivity based on
raster image alone is starting with too much information
lost |
| 05:56.58 |
*** join/#brlcad madant_
(n=d@117.196.139.52) |
| 07:05.59 |
*** join/#brlcad elena (n=elena@92.86.0.28) |
| 07:07.55 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34416 10/brlcad/trunk/src/libged/CMakeLists.txt:
added scale_ell.c to stay in sync with Makefile.am |
| 07:18.44 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 08:08.54 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E442.dip.t-dialin.net) |
| 08:11.41 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128565123.dsl.bell.ca) |
| 08:13.06 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E442.dip.t-dialin.net) |
| 08:50.42 |
*** join/#brlcad _clock__
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 08:54.10 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:55.30 |
mafm |
hi |
| 08:56.11 |
brlcad |
hi! |
| 09:23.30 |
mafm |
brlcad: I was
talking with a friend yesterday and reminded me of our
discussions |
| 09:23.36 |
mafm |
he hates Ogre
with passion |
| 09:24.27 |
mafm |
it seems that
the holy wars about 3d engines are the new rage, after sysv vs bsd,
vi vs emacs and kde vs gnome :D |
| 09:32.52 |
``Erik |
hrm, yet a
new convert O.o I'm pimping BRL-CAD on WoW :( |
| 09:33.03 |
``Erik |
lemme guess,
crystal space? :D |
| 09:33.19 |
``Erik |
has yet to find a 3d engine that doesn't
suck |
| 09:33.54 |
mafm |
yep, he's a
crystal space partisan :D |
| 09:33.56 |
``Erik |
of course,
vim and emacs each suck in their own way... bsd and sysv each have
their issues... linux just sucks, plain and simple |
| 09:34.05 |
mafm |
and yes, I
don't like much any of them |
| 09:34.45 |
``Erik |
(and windows
makes black holes look like minor deflective entities) |
| 09:36.30 |
mafm |
lol |
| 09:43.58 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:21.41 |
d-lo |
Mernin all!
``Erik, you're up early! |
| 10:25.01 |
archivist |
sleep seg
faulted |
| 10:37.48 |
*** join/#brlcad Mouette
(n=chatzill@122-116-39-75.HINET-IP.hinet.net) |
| 10:44.48 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:26.58 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 11:49.09 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 12:43.49 |
archivist |
brlcad, been
seeing that type of spam on other lists |
| 13:01.22 |
brlcad |
archivist: I
know, I've read that it looks like viral social
networking |
| 13:01.52 |
brlcad |
that if you
sign up on yaari, it spams everyone in your contact list after you
import them (automatically and unknown to the user) |
| 13:02.24 |
archivist |
heh...not the
sort of thing I visit or sign up for :) |
| 13:04.24 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 13:08.16 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 13:33.25 |
starseeker |
``Erik: Linux
may suck, but we have drivers :-P |
| 13:34.03 |
starseeker |
looks forward to Haiku becoming usable so he can again adopt
a niche OS |
| 13:46.48 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 13:49.16 |
``Erik |
hm, I have no
gear that doesn't have bsd drivers, and scars from when linux did
lack drivers for common equipment |
| 13:49.32 |
starseeker |
raises eyebrows. |
| 13:49.39 |
starseeker |
do the nvidia
drivers work well now? |
| 13:49.40 |
``Erik |
d-lo:
late |
| 13:49.43 |
``Erik |
yes |
| 13:49.53 |
``Erik |
for the last
5 or so years |
| 13:50.23 |
starseeker |
``Erik: wow.
Guess it has been a while since I did comparative operating system
testing |
| 13:51.00 |
``Erik |
I think I did
manage to force a release a few years back to support a chipset...
the code was all their but the driver lagged with its listing, so
it refused to try to use an 'known' pci id |
| 13:51.23 |
archivist |
nvidia dont
work well with a realtime kernel though |
| 13:51.28 |
``Erik |
so I sent a
message that, uh, kinda insinuated need from my work address (at
the time, I was developing ogl code) |
| 13:51.55 |
``Erik |
careful,
archivist, someone will state that the NT series is a realtime
kernel :D |
| 13:52.10 |
starseeker |
heh
:-) |
| 13:53.29 |
``Erik |
starseeker: I
was happily running linux games (rtcw, ut) on my fbsd box with an
nvidia card before I moved to md in '03 |
| 13:54.37 |
``Erik |
I think the
drivers came out in '01 |
| 13:55.26 |
starseeker |
remembers the original fuss about subpar support on *BSD -
guess by the time things settled down I had stopped operating
system hopping |
| 13:55.39 |
``Erik |
it lags, but
it's there, kinda |
| 13:57.19 |
``Erik |
https://sourceforge.net/projects/fbsd-nvdriver/
<-- shortly after that, they had a driver for fbsd |
| 13:58.22 |
``Erik |
stupid effin'
linux |
| 13:59.44 |
``Erik |
ioctl(fd,code,...) hm,
ioctl(fd,in,out,len) geeeee, { out = in; } /* DONE! */ |
| 13:59.48 |
``Erik |
shakes fist |
| 14:05.52 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 14:21.19 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 14:44.16 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 15:44.30 |
*** join/#brlcad d-lo_
(n=claymore@bz.bzflag.bz) |
| 15:49.56 |
``Erik |
y'know, I
need to make smaller portions when I stir-fry... about half of what
I do (or invite a fool over) |
| 15:57.20 |
*** join/#brlcad Elrohir (n=kvirc@p5B14E442.dip.t-dialin.net)
[NETSPLIT VICTIM] |
| 16:02.44 |
d-lo |
so ``Erik ,
taking today off? |
| 16:03.27 |
``Erik |
yesterday was
al expecting dude to show up... today, dude called off again but I
felt like poop, so SL, hopefully tomorrow will be AL for house
repair |
| 16:03.49 |
``Erik |
check out
"polly scattergood" |
| 16:04.02 |
d-lo |
dude as in
Cable repair dude? |
| 16:04.04 |
``Erik |
I think she's
gonna make waves in the next year |
| 16:04.13 |
``Erik |
no, house
repair, the rotted out wood |
| 16:04.29 |
d-lo |
ah, the door
frame? |
| 16:04.36 |
``Erik |
he's gonna
disassemble my houses face to get all the rotten wood
out |
| 16:04.42 |
d-lo |
wow. |
| 16:04.51 |
d-lo |
good to do.
Not cheap? |
| 16:05.09 |
``Erik |
his initial
estimate is 375, he's retired and does this for fun |
| 16:05.18 |
``Erik |
eric edwards
hooked us up |
| 16:05.24 |
d-lo |
nice
:) |
| 16:05.26 |
``Erik |
eric knows
RRRVRONE |
| 16:05.37 |
d-lo |
que? |
| 16:05.51 |
``Erik |
for? |
| 16:06.27 |
d-lo |
RRRVRONE =
? |
| 16:06.30 |
``Erik |
the
'rrrvrone' is a family guy joke, 'cleaveland' style |
| 16:08.01 |
``Erik |
aaanyways, I
was talkin' about goldfrapp a couple years ago, they just recently
were spotting in commercials and stuff... good stuff... I think
this polly girl is the next one |
| 16:08.09 |
``Erik |
in spite of
her essex accent |
| 16:08.37 |
``Erik |
should so be a label recruiter : |
| 16:08.39 |
``Erik |
:) |
| 16:08.44 |
d-lo |
lol |
| 16:08.54 |
d-lo |
its your
calling. Goferit. |
| 16:09.24 |
``Erik |
well, check
out her youtubes |
| 16:10.04 |
d-lo |
Prolly when I
get home. Kinda involved in werk right now :/ |
| 16:10.13 |
``Erik |
a very
british face, but she does good tunes |
| 16:11.28 |
d-lo |
Ah, so she's
the kind of female vocalist where you look at her face and not
elsewhere? |
| 16:11.39 |
``Erik |
no, ... other
way 'round |
| 16:13.52 |
``Erik |
not uh, susan
boyle, but ... up that alley |
| 16:13.59 |
d-lo |
heh, you
weren't kidding about the british face. |
| 16:14.44 |
``Erik |
at least the
girl from goldfrapp was adolescent jack material |
| 16:15.05 |
``Erik |
I think this
polly girl will make a mark, *shrug* |
| 16:19.48 |
d-lo |
Well I will
check out her vids at home. Just hope she isn't a nother
mute-and-watch chickie. |
| 16:20.20 |
``Erik |
heh, if you
mute, just close the window |
| 16:20.30 |
``Erik |
honest, she
ain't pretty |
| 16:21.10 |
starseeker |
hmm, this
sounds like it might be interesting:
http://www-hagen.informatik.uni-kl.de/~hijazi/Publications/gpuimpcsg-tr.pdf |
| 16:21.20 |
CIA-28 |
BRL-CAD:
03bob1961 * r34417 10/brlcad/trunk/src/libged/concat.c: Modified
ged_concat to not require a suffix/prefix. If one is not provided,
it behaves as if / was specified. |
| 16:49.06 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 17:02.58 |
brlcad |
wow, kudos to
NX5 .. nice interface revamping |
| 17:04.18 |
starseeker |
googles NX5 |
| 17:04.47 |
starseeker |
ah |
| 17:04.52 |
brlcad |
unigraphics |
| 17:05.08 |
starseeker |
wow |
| 17:05.09 |
brlcad |
they
(stupidly) renamed to 'NX' a while back |
| 17:05.46 |
starseeker |
erm.
Throwing away a widely recognized brand name for "NX"?? that IS
stupid |
| 17:06.05 |
brlcad |
one that is
barely even searchable by itself |
| 17:06.36 |
starseeker |
agreed though
- nice UI |
| 17:06.44 |
``Erik |
thowing away
a widley recognized brand name for "AMCAC"??? that IS
stupid |
| 17:06.50 |
``Erik |
thowing away
a widley recognized brand name for "ARL"??? that IS
stupid |
| 17:07.06 |
starseeker |
``Erik: ARL
is the brand |
| 17:07.22 |
brlcad |
that's
actually not far from the look of the icons I had in
mind |
| 17:07.23 |
starseeker |
what do you
mean? |
| 17:07.28 |
brlcad |
he meant
BRL |
| 17:07.31 |
``Erik |
ok, you can
believe hat. I'll keep working on BRL |
| 17:07.32 |
brlcad |
was renamed
to ARL |
| 17:07.35 |
``Erik |
no, I meant
ARL |
| 17:07.45 |
starseeker |
Oh,
gotcha |
| 17:07.49 |
``Erik |
BRL was a
widely recognized name, we changed to ARL |
| 17:07.55 |
brlcad |
that's what I
meant |
| 17:08.03 |
brlcad |
go back to
your embibbing |
| 17:08.13 |
``Erik |
returns to lisp development |
| 17:08.59 |
starseeker |
those icons
look like they could be vector |
| 17:09.09 |
brlcad |
nice bright
high-resolution icons, clean theme, crisp tabbing |
| 17:09.40 |
brlcad |
still a
little dead space but some basic concepts to be noted |
| 17:10.12 |
starseeker |
is puzzled by the virtually empty bar below the two rows of
icons |
| 17:10.18 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 17:10.34 |
brlcad |
yeah,
selection-sensitive options |
| 17:10.41 |
starseeker |
ah |
| 17:10.48 |
brlcad |
not the best
organization for those |
| 17:11.11 |
brlcad |
photoshop
does the same thing but better because there aren't icons above,
but similar concept |
| 17:11.22 |
starseeker |
perhaps
appearing/disappearing transparent toolbars for selection sensitive
would be an option? |
| 17:11.32 |
starseeker |
s/toolbars/whatever |
| 17:13.14 |
brlcad |
who is to say
that theirs doesn't appear/disappear ;) |
| 17:13.22 |
brlcad |
still clunky
by the placement alone |
| 17:14.02 |
brlcad |
bigger issue
is the buffet of probably somewhat randomly used buttons above
it |
| 17:14.19 |
starseeker |
heh, true. I
was thinking along the lines of the toolbars on the edge in
stellarium |
| 17:14.26 |
brlcad |
the lesson to
take from it, though, is nice vibrant icons ;) |
| 17:14.42 |
Ralith |
takes notes |
| 17:14.43 |
starseeker |
nods - yes, those are striking and easily
viewed |
| 17:14.59 |
brlcad |
and fairly
unambiguous |
| 17:15.07 |
starseeker |
if I'm not
mistaken, those are all expressible as vector icons - great for
resolution independence :-) |
| 17:15.32 |
brlcad |
i highly
doubt they are vectors, but sure :) |
| 17:15.37 |
starseeker |
THINKS QT supports that, but isn't sure... |
| 17:16.01 |
``Erik |
dislikes qt |
| 17:16.03 |
starseeker |
I know KDE
was working towards it for their desktop icons at the very least,
and I think it was across the board |
| 17:16.04 |
Ralith |
I would be
surprised if it didn't |
| 17:19.25 |
starseeker |
ah, yeah - as
of QT 4.2 they support svg icons |
| 17:21.23 |
starseeker |
likes the idea of not having to shove lots of different
resolution .png files into the repository :-) |
| 17:29.29 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 17:59.03 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:27.42 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 19:31.21 |
brlcad |
aaalmost gets the new mirroring equations to
work |
| 19:32.44 |
brlcad |
starseeker:
true |
| 19:33.16 |
starseeker |
winces in sympath with brlcad - nothing as frustrating as
"almost" working |
| 19:33.18 |
brlcad |
though while
unclean, it's *very* trivial to maintain image resource
files |
| 19:33.29 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:33.37 |
starseeker |
true. We
will be doing it with Archer anyway, I guess |
| 19:33.49 |
starseeker |
or rather,
are doing |
| 19:33.52 |
brlcad |
vector is of
course better, but it 'can' be considerably more
complicated |
| 19:34.20 |
starseeker |
to store, or
to use? |
| 19:34.25 |
brlcad |
not that you
need to store multiple image files either, can always store just
one and downsample as needed |
| 19:34.28 |
brlcad |
yes |
| 19:34.33 |
starseeker |
heh |
| 19:34.40 |
starseeker |
was thinking they're harder to design... |
| 19:34.58 |
brlcad |
actually more
on use, storing it is just a matter of yet another resource
file |
| 19:35.18 |
brlcad |
storing in
memory can be more tricky, but that's akin to use |
| 19:35.25 |
starseeker |
ah. |
| 19:35.33 |
starseeker |
was hoping QT could take care of that... |
| 19:36.03 |
brlcad |
hopefully |
| 19:36.06 |
brlcad |
but if not,
meh |
| 19:36.11 |
starseeker |
nods |
| 19:36.20 |
starseeker |
if not,
simpler to go with images |
| 19:36.22 |
brlcad |
that's not
really a technical problem |
| 19:36.26 |
brlcad |
yeah |
| 19:37.01 |
starseeker |
can even
create them as svg, generate images if needed, then "someday"
convert to straight svg |
| 19:37.14 |
starseeker |
after all our
other problems go away |
| 19:37.40 |
brlcad |
another
potentially 'neat' idea would be for each 'icon' to be a tiny
little .g scene :) |
| 19:38.29 |
brlcad |
even better
over svg since most of what we need to display isn't vector 2d,
it's actually 3d.. so we could just make a 3d resource and display
that instead |
| 19:38.44 |
brlcad |
would need a
little backend work to make it flexible though |
| 19:38.53 |
starseeker |
that is an
interesting idea |
| 19:39.22 |
starseeker |
you're
thinking to raytrace the .g scenes to generate the
icons? |
| 19:39.27 |
brlcad |
no
no |
| 19:39.59 |
brlcad |
shaded
display geometry, just tiny to whatever size the icons
are |
| 19:40.03 |
starseeker |
ah |
| 19:40.11 |
brlcad |
i mean you
could render them, but no need really |
| 19:40.24 |
starseeker |
once we can
do shaded displays :-) |
| 19:40.27 |
brlcad |
what it would
require, though, is some good display support |
| 19:40.33 |
starseeker |
no
kidding |
| 19:40.40 |
brlcad |
and probably
annotations |
| 19:40.44 |
starseeker |
isn't sure if he has ever heard of such an approach to
icons |
| 19:40.49 |
brlcad |
since most of
the icons require some form of annotative overlay |
| 19:41.13 |
starseeker |
blender did
their whole interface on opengl IIRC, but I don't think their icons
are mini blender scenes.. |
| 19:41.32 |
starseeker |
probably made
in blender though, come to think of it... |
| 19:41.44 |
starseeker |
that is a
nifty idea |
| 19:43.00 |
starseeker |
probably
would be for "new interface mark 2" though - lot of things need to
be working really well to pull that off |
| 19:44.43 |
brlcad |
I wouldn't
put it in archer, but it's not that complicated at all
really |
| 19:45.19 |
starseeker |
is wondering about the performance implications of so many
tiny shaded scenes |
| 19:45.45 |
brlcad |
you're making
the scene, so it really can be just about anything -- e.g. bots so
shaded display works, geometry for whatever annotations you want to
display, etc .. text is the main stickler and something like ftgl
solves that |
| 19:46.42 |
starseeker |
true - I was
thinking more along the lines of how the display management would
cope with it |
| 19:46.47 |
brlcad |
they're
static scenes and don't even need to update each frame unless there
are antialiased/transparent items in the icon |
| 19:47.50 |
brlcad |
it wouldn't
be more than a few hundred polys per icon, likely less than 100
displayed at a time -- insignificant |
| 19:48.11 |
starseeker |
right, but
wouldn't each icon be its own opengl context? |
| 19:48.23 |
brlcad |
and even if
it were a problem, you grab it from the framebuffer and display
static image until resizes |
| 19:48.28 |
starseeker |
maybe that
isn't a problem... |
| 19:48.31 |
starseeker |
ah |
| 19:48.41 |
brlcad |
no, just the
one context |
| 19:49.00 |
starseeker |
oh, right -
full screen context with elements within it |
| 19:49.09 |
starseeker |
duh |
| 20:04.37 |
brlcad |
heh,
cool |
| 20:06.17 |
brlcad |
it's now
actually more efficient (space-wise) to store a sphere as a pnt
primitive |
| 20:06.31 |
starseeker |
heh
:-) |
| 20:06.36 |
starseeker |
neat! |
| 20:07.08 |
brlcad |
when I put
that optimization in for per-point radius values, that makes it
actually only store series of 3+1 instead of sph's usual
serialization which is same as tgc (12) |
| 20:07.39 |
brlcad |
even with the
pnt overhead (2 values), it's still less for a single sphere (6
values) |
| 20:07.52 |
starseeker |
is it worth
reworking sph? |
| 20:07.54 |
brlcad |
half the
storage :) |
| 20:08.00 |
starseeker |
cool! |
| 20:08.03 |
brlcad |
no, just
funny |
| 20:08.30 |
brlcad |
sph does it
that way so it's compatible and interchangeable with an ell (said
tgc earlier, meant ell) |
| 20:08.43 |
starseeker |
figured ;-) |
| 20:09.17 |
brlcad |
and changing
it would break db compatibility, so not really worth it |
| 20:09.33 |
starseeker |
nods |
| 20:09.38 |
brlcad |
would only
matter if you had a lot of spheres.. and if you do, then you
probably should be using a pnt anyways |
| 20:09.51 |
starseeker |
point
:-P |
| 20:10.27 |
brlcad |
shakes his fist at this dotproduct |
| 20:13.19 |
brlcad |
ahhh, it's
bug in the *current* mirror command too |
| 20:28.38 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.228.66) |
| 20:43.21 |
CIA-28 |
BRL-CAD:
03brlcad * r34418 10/brlcad/trunk/TODO: |
| 20:43.21 |
CIA-28 |
BRL-CAD: mged
inconsistently ignores signals. initially allows it to be
backgrounded, |
| 20:43.21 |
CIA-28 |
BRL-CAD: but
then later will ignore them. may be related to some issue
introduced with |
| 20:43.21 |
CIA-28 |
BRL-CAD:
bu_suspend_interrupts() and libged, but either way it's really
annoying and |
| 20:43.21 |
CIA-28 |
BRL-CAD:
should be changed (ideally to allow them) |
| 21:06.39 |
CIA-28 |
BRL-CAD:
03bob1961 * r34419 10/brlcad/trunk/src/libtclcad/ged_obj.c: Need to
convert/scale points to local units before calling routines that
expect local units. |
| 21:07.58 |
CIA-28 |
BRL-CAD:
03bob1961 * r34420 10/brlcad/trunk/src/libged/ (move_arb_edge.c
move_arb_face.c): Need to convert points from local to base units
before using. |
| 21:14.26 |
CIA-28 |
BRL-CAD:
03bob1961 * r34421 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl GeometryEditFrame.tcl): Provide better interaction when
editing in Archer (i.e. update value panel and change the edit mode
if the current edit class is not appropriate). |
| 21:50.46 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 22:09.03 |
CIA-28 |
BRL-CAD:
03brlcad * r34422 10/brlcad/trunk/include/vmath.h: |
| 22:09.03 |
CIA-28 |
BRL-CAD:
instead of referring to the 4th component of a plane_t as [3],
refer to it as |
| 22:09.03 |
CIA-28 |
BRL-CAD: [W]
given it's effectively a homogeneous component for the normalized
plane |
| 22:09.03 |
CIA-28 |
BRL-CAD:
equation vector. aside from that, code shouldn't be accessing the
element by a |
| 22:09.03 |
CIA-28 |
BRL-CAD:
magic number regardless in case we want to change the
implementation. |
| 22:19.49 |
starseeker |
will be wanting one of these if he has a yard someday:
http://www.friendlyrobotics.com/ |
| 22:21.06 |
starseeker |
with that and
roomba, life starts to get good :-) |
| 22:21.27 |
starseeker |
especially if
you're a cat, apparently: http://www.youtube.com/watch?v=LQ-jv8g1YVI |
| 22:38.38 |
brlcad |
starseeker:
back to our earlier work (which we should pick up again sometime
soon) since I just ran across it again, check out
src/libbn/plane.c |
| 22:38.51 |
brlcad |
should look
pretty familiar |
| 22:39.26 |
starseeker |
ah
yes |
| 22:39.35 |
starseeker |
excellent
:-) |
| 22:41.22 |
starseeker |
how robust
are those? |
| 22:42.00 |
brlcad |
most of them
do exactly what we'd want, doing a given test and taking tolerance
into account |
| 22:42.15 |
brlcad |
a lot of
line/point/plane tests, no curves |
| 22:42.20 |
starseeker |
excellent. |
| 22:42.26 |
starseeker |
yeah, I was
looking for curves ;-) |
| 22:42.58 |
brlcad |
so
specialized, like finding the intersection of three unique
planes |
| 22:43.01 |
brlcad |
s/so/some/ |
| 22:43.35 |
brlcad |
or given
three points, make a plane |
| 22:43.41 |
starseeker |
nods |
| 22:44.18 |
starseeker |
I've been
trying to figure out if there are any good reference books
containing algorithms for curve/* intersections |
| 22:50.42 |
starseeker |
hmmm.
http://www.siggraph.org/s2009/sessions/courses/details/?type=course&id=6 |
| 22:56.42 |
brlcad |
not exactly
what we were referring to earlier |
| 22:56.51 |
brlcad |
fully 3D user
interfaces are a different beast altogether |
| 22:57.13 |
brlcad |
where you
have windows and palletes and widgets floating around in space
potentially |
| 22:57.24 |
starseeker |
mmm |
| 22:57.33 |
Ralith |
that strikes
me as confusing. |
| 22:57.41 |
starseeker |
I was hoping
they might talk about interacting with 3D models |
| 22:58.13 |
starseeker |
nuts - yeah,
I'm not a big fan of 3D interfaces in that sense |
| 23:00.04 |
brlcad |
it still
applies -- just depends what we're talking about |
| 23:00.54 |
brlcad |
for example,
I've had in mind to use something like radial menus around objects
that are selected (or to at least have it as an option) .. that
becomes rather effective only if set in the 3d scene with the
object |
| 23:01.19 |
Ralith |
oo, that does
sound neat |
| 23:01.36 |
Ralith |
visually
anyway; dunno if it'd be more usable than standard radial menus
around the pointer. |
| 23:03.14 |
``Erik |
pie menus are
a nifty idea, but I imagine most users wouldn't follow them well
because they're so ingrained in the drop menu paradigm
:( |
| 23:03.16 |
brlcad |
yeah, there's
some work that has shown it 'can' be effective, but depends on a
lot of things |
| 23:03.53 |
Ralith |
the work I
saw depended on it being around the cursor, though |
| 23:04.31 |
Ralith |
'cuz then you
get the ability to select any item with a very small constant
amount of imprecise movement |
| 23:04.49 |
Ralith |
if it's not
centered on the pointer, then I think you lose most of that
advantage. |
| 23:05.06 |
``Erik |
you also need
to be away from a screen edge, and to break the users
mentality |
| 23:05.12 |
``Erik |
but it is a
really neat idea |
| 23:06.03 |
brlcad |
that's just a
matter of view-dependent scaling of the menu in the scene (which
you would have to have) |
| 23:06.10 |
brlcad |
so that you
don't end up with precision issues |
| 23:06.25 |
``Erik |
what, the
screen edge aspect? |
| 23:06.43 |
brlcad |
``Erik:
fortunately, we don't give them any such option at the moment .. so
no behavior that we're breaking on our part :) |
| 23:06.59 |
Ralith |
hehe |
| 23:07.10 |
``Erik |
if your user
invokes right at the edge of the screen, do you draw a hemisphere?
in a corner, just a quadrant? |
| 23:07.30 |
Ralith |
I'd just have
the thing appear a little bit offset. |
| 23:07.34 |
Ralith |
it's not got
*that* large a radius. |
| 23:07.36 |
``Erik |
well, effort
to add a feature that "doesn't feel right" to 99% of users is
probably ... wasted |
| 23:07.54 |
``Erik |
and if your
pie expansion is towards the corner? |
| 23:08.00 |
brlcad |
technically,
displaying the vertices in the 3D scene when an object being edited
is a form of a 3D gui, particularly when you then allow
vertices/objects/points to be selected and edited in the scene
directly |
| 23:08.09 |
Ralith |
then that's a
problem, I guess. You'd have to move everything. |
| 23:08.12 |
``Erik |
moving hte
menu out from under the user seems... almost criminal to
me |
| 23:08.23 |
Ralith |
indeed. |
| 23:08.41 |
Ralith |
although... |
| 23:08.58 |
Ralith |
it might not
be completely unreasonable to just swap the new menu in place of
the old one, in general |
| 23:09.10 |
``Erik |
technically,
we don't support 3d gui yet... every "3d" thing any of us deal with
are compressed into 2d for display.. :) (unless you do
stereoscopics or a cave or something) |
| 23:09.11 |
Ralith |
kind of like
GUI file browsers moved from new windowing all the time to just
changing dir in the current window |
| 23:09.48 |
``Erik |
ralith: most
make that selectable, some have a number of approaches |
| 23:09.55 |
Ralith |
I think the
effort of learning a CAD tool of any kind is enough that we're
justified in being creative with GUI work, and possibly doing
uncommon things. |
| 23:10.10 |
brlcad |
if the gui is
in the scene, it's in the scene and is a normal "out of view"
problem if an object is near the edge |
| 23:10.23 |
``Erik |
I think the
default mac 'finder' settings are abysmal, but still better than
the default winderz explorer |
| 23:10.24 |
Ralith |
since,
ultimately, any unfamiliarity induced by such will be less than the
challenge posed by learning the fundementals of the
system. |
| 23:10.46 |
brlcad |
i.e. the menu
is displayed and they can't see it all because of where the object
is, just like that control point they can't click because it's too
close to a menu or the edge of a context or whatever |
| 23:10.57 |
``Erik |
aint' sayin' it ain't a good idea, just playing devils
advocate and looking for corner cases |
| 23:11.04 |
brlcad |
it's also not
to say that it'd be the *only* method available |
| 23:11.28 |
brlcad |
there are a
couple really good 'proof of concepts' out there that are
remarkable |
| 23:11.45 |
``Erik |
yeah, but
they tend to be cotton candy examples, y'know? |
| 23:11.59 |
``Erik |
if they're
the couple that I was looking at around '00 or '01 |
| 23:12.05 |
``Erik |
when the
papers came out |
| 23:13.39 |
``Erik |
I was looking
at coding video game stuff at the time (so there's a lot of leeway
in breaking user convention), I d'no, it seemed like a paper idea
to me when talking serious production *shrug* |
| 23:13.52 |
brlcad |
these were
working prototypes, don't have the link atm though |
| 23:14.17 |
brlcad |
here's an
example that's not as impressive, but at least related and
functional:
http://image.com.com/gamespot/images/2007/225/942784_20070814_screen004.jpg |
| 23:14.28 |
``Erik |
but I'm old,
bitter and cynical... I like zui as a notion, but it'd take a
ground shaking 'killer app' to move it from a geek curiousity to a
real thing |
| 23:14.51 |
``Erik |
ah, I hadn't
seen that image before |
| 23:15.12 |
``Erik |
the examples
I saw made a bit point of concentric rings |
| 23:15.36 |
brlcad |
yeah,
something like
http://stevejbayer.com/files/images/2%20level%20Radial%20Menu.jpg |
| 23:16.05 |
``Erik |
yes |
| 23:16.23 |
``Erik |
the downside
is what does that picture MEAN? to a cold user, wtf? |
| 23:16.42 |
``Erik |
the video
game picture, I think I understand... two of those
images |
| 23:16.55 |
brlcad |
a variant of
the radial is simply two horizontal menus and two vertical
menus |
| 23:17.10 |
``Erik |
I assume the
wrench means "repair this unit" and the dollar sign means something
about expenses... the rest... I d'no |
| 23:17.25 |
brlcad |
like I said,
not as impressive -- the icons are not exactly intuitive outside
the domain |
| 23:17.36 |
brlcad |
but then so
are most of the icons in a CAD app to an outsider |
| 23:17.37 |
``Erik |
but video
games are lenient :) |
| 23:17.45 |
``Erik |
*ponder* |
| 23:17.51 |
``Erik |
brainfart
time |
| 23:17.58 |
``Erik |
imagine
instead of a full circle of images |
| 23:17.58 |
Ralith |
tooltips come
into their own here, too. |
| 23:18.08 |
Ralith |
or an
equivalent. |
| 23:18.21 |
``Erik |
ralith, if I
have to mouseover something to understand what it is, the hci guys
failed. |
| 23:18.33 |
Ralith |
you only have
to mouseover it *once* though |
| 23:18.51 |
``Erik |
ok, imagine
two quarter-circles, centered on each side, with the functional
text drifting off against it |
| 23:19.05 |
``Erik |
uh, ralith,
if I have to memorize from a mouseover, your hci has failed
:D |
| 23:19.09 |
Ralith |
:[ |
| 23:19.28 |
Ralith |
large menu
options w/ text instead of icons? |
| 23:19.32 |
Ralith |
which is what
you seem to be suggesting. |
| 23:19.50 |
Ralith |
as brlcad
says, I don't think you can do much about icons being
unintuitive. |
| 23:20.16 |
``Erik |
no, I suggest
an amber screen with a cable bundle to a server :D |
| 23:20.51 |
``Erik |
what's the
infamous usenet quote? the only intuitive interface is the
nipple? |
| 23:20.57 |
brlcad |
ideally,
there's as little menu, buttons, and widgets as possible, the less
the better is generally the case for usability (i.e., if it looks
like something you should be able to do, then you should be able to
do it.. lots of direct manipulation) |
| 23:21.31 |
``Erik |
so when you
design a gui, it's a balance between making things clean for a
knowledgable superuser and accessable to a newbie |
| 23:21.43 |
brlcad |
it's more a
matter of context management so that there's as little conflict of
options as possible, without resorting to all-out
modalities |
| 23:21.49 |
``Erik |
I hate to say
it, but the microsoft 'faded menu' approach appeals to the ugly
truth fairly well |
| 23:22.08 |
``Erik |
imho |
| 23:24.02 |
brlcad |
Ralith:
that's why a lot of what you're doing is more leaning towards the
work that's gone into IEO since that's a lot more about context
management |
| 23:24.43 |
``Erik |
aaaanyways,
coders tend to look for glitzy 'neat' solutions that just make the
mere mortal experience more difficult, I'm just trying to be 'that
guy' to pull folk back to ground :) |
| 23:24.44 |
brlcad |
and not so
much the 3D scene interaction |
| 23:26.00 |
Ralith |
but the
glitzy neat solutions are glitzy and neat! |
| 23:26.22 |
``Erik |
hehehehe
precisely! I'm glad you understand! |
| 23:26.24 |
``Erik |
:D |
| 23:28.00 |
``Erik |
my mother
works for a bank, she just recently got approval to work from
home... before that, she sat in an aeron chair, running XP...
filled her screen with putty and ran a curses(or equivelant)
program on a dusty as/400 |
| 23:28.01 |
brlcad |
would rather focus on trying to figure out how to make things
work or implementing prototypes rather than spending time trying to
navel gaze on all the possible ways that something might go wrong
or be implemented poorly :) |
| 23:28.22 |
``Erik |
there's
glitzy neat stuff, and then there's stuff people use to get the job
done :) |
| 23:28.44 |
``Erik |
*point* yes,
no glitz, get something working : |
| 23:28.45 |
``Erik |
:D |
| 23:29.09 |
brlcad |
"glitz" can
often tie in almost directly to usability |
| 23:29.11 |
``Erik |
wants the modelers to tell him what frustrates them the most
:( |
| 23:29.20 |
brlcad |
depends
entirely what you mean by glitz |
| 23:30.12 |
brlcad |
because very
often, what many call glitz in some interfaces is actually HCI
hinting, which can be very effective for shifting locus of
attention |
| 23:30.19 |
``Erik |
hm, yeah, I
don't think there's a hard definition, I think I consider it to be
eye candy that is not necessary to efficiently accomplish the
task |
| 23:30.43 |
``Erik |
when the gui
inhibits the use, then it's just glitz |
| 23:30.46 |
``Erik |
:) |
| 23:30.59 |
brlcad |
e.g., the
"genie minimize" or "scale minimize" in mac os x .. on the surface
is purely 'glitz', a shiny effect .. but it's not |
| 23:31.07 |
brlcad |
it actually
shows you where the window went |
| 23:31.09 |
brlcad |
very
effective |
| 23:31.12 |
brlcad |
and looks
cool to boot |
| 23:31.53 |
brlcad |
if you need
to restore that working context, you were told exactly where it
went, or at least the direction it went |
| 23:31.58 |
``Erik |
<-- uses
genie |
| 23:32.51 |
brlcad |
is it
"necessary", absolutely not -- is it useful, very much so in
combination with many other usability hints that are going on
simultaneously |
| 23:33.01 |
``Erik |
I've seen a
lot of instances where code was developed to look cool, but the
users felt it made things more difficult to use.. THAT is what I
want to cut off |
| 23:33.15 |
brlcad |
well complain
about that when you see it :) |
| 23:33.32 |
``Erik |
and it's the
user that matters, not the chapter about hinting in the hci book
:D |
| 23:33.48 |
brlcad |
otherwise,
it's just contemplating all the possible horrible ways things could
go fantastically wrong |
| 23:34.10 |
brlcad |
which isn't
productive :P |
| 23:34.15 |
``Erik |
I called in
sick today, I'm allowed to be the peanut gallery,
damnit |
| 23:34.17 |
``Erik |
:D |
| 23:34.35 |
Ralith |
hehe |
| 23:34.38 |
starseeker |
not to
mention I'll accidently stumble into at least 10 of the worst UI
mistakes anyway, regardless |
| 23:34.48 |
starseeker |
so don't
worry about it ;-) |
| 23:35.14 |
starseeker |
we'll just be
ready to correct mistakes |
| 23:35.37 |
``Erik |
pie menus are
neat, I bet if you cut off the top and bottom quarters and put text
next to the items (context based), it'd be more usable to a
newbie |
| 23:36.29 |
brlcad |
that's the
variant I mentioned that is basically two vertical and two
horizontal menus |
| 23:36.32 |
starseeker |
remembers when he was learning Tribes, there were interactive
tutorials that went through the uses and meanings of the various
options |
| 23:36.50 |
starseeker |
was actually
fairly effective |
| 23:37.12 |
``Erik |
brlcad:
ss? |
| 23:37.36 |
brlcad |
more radical
hierarchical example: http://farm1.static.flickr.com/39/76817786_0cbe787afa_o_d.png
(not a fan, but interesting nonetheless) |
| 23:37.47 |
brlcad |
ss? |
| 23:37.49 |
starseeker |
we could
convert the cup tutorial steps into an in-gui
step-by-step... |
| 23:37.57 |
brlcad |
the cup
sucks |
| 23:37.58 |
brlcad |
it's
boring |
| 23:37.59 |
``Erik |
starseeker:
yes, but video games are a special turf, like I mentioned
earlier... that ti's challenging to operate is often considered a
boon, unlike other apps |
| 23:38.05 |
``Erik |
ss ==
screenshot |
| 23:38.10 |
starseeker |
well,
something more interesting than the cup then |
| 23:38.11 |
brlcad |
ah, don't
have one |
| 23:38.28 |
brlcad |
at least not
on hand at the moment, there are some examples stashed away in my
data archive |
| 23:38.38 |
``Erik |
hm, that's an
interesting image, but not what I mean |
| 23:38.50 |
brlcad |
I know, it
was unrelated |
| 23:38.55 |
brlcad |
just another
example |
| 23:39.02 |
``Erik |
tell ya what,
on thursday or friday, I can draw on my whiteboard, or gimp one
up |
| 23:39.04 |
archivist |
that was
fugly |
| 23:39.04 |
starseeker |
that is
radical |
| 23:40.06 |
starseeker |
is a traditionalist in some ways - he likes what stellarium
does with the toolbars hidden at the edges |
| 23:40.27 |
``Erik |
tell ya what,
man, amber crt, vt102, ... |
| 23:40.42 |
starseeker |
isn't THAT much of a traditionalist... |
| 23:40.58 |
brlcad |
that's what
command-mode is for, part why it's first and fundamental
;) |
| 23:41.11 |
brlcad |
command mode
is pervasively available |
| 23:41.13 |
``Erik |
when the
library bought wyse terminals to place next to the card catalog,
that was hot shit |
| 23:41.38 |
``Erik |
uhmmmmmmmm,
lee had a question about the tcl command prompt in BRL-CAD on
friday, did he get to you on that? |
| 23:41.44 |
starseeker |
well sure -
if it's all you've got, vacuum tubes are the bomb |
| 23:42.00 |
starseeker |
to me? don't
think so |
| 23:42.01 |
starseeker |
what was
it? |
| 23:42.06 |
``Erik |
to
brlcad |
| 23:42.09 |
starseeker |
oh |
| 23:42.18 |
``Erik |
s/^/brlcad:
/ |
| 23:42.19 |
``Erik |
:) |
| 23:42.29 |
brlcad |
what's
interesting about a (well-designed) radial menu is that they're
measurably more efficient than a linear menu due to directionality,
spatial memorization, and distance travelled (fitts) so long as the
menu stays small (and isn't a decision tree) |
| 23:42.54 |
brlcad |
``Erik: think
he did .. at least I talked to him friday and solved some problem
for him |
| 23:43.02 |
brlcad |
don't
remember what it was atm though |
| 23:43.15 |
``Erik |
'k, he was
looking for some command to find something in a .g file and I didn'
have an answer for him |
| 23:43.16 |
brlcad |
ah, catching
a db get |
| 23:43.25 |
brlcad |
yeah |
| 23:43.33 |
``Erik |
<--
doesn't do the tcl side |
| 23:43.33 |
brlcad |
problem
solved |
| 23:43.37 |
``Erik |
aight,
good |
| 23:44.14 |
``Erik |
y'know, I'm
struck by differences in utilization of "world of warcraft" between
me and redvsblue |
| 23:45.12 |
``Erik |
I use addons
to place icons in the fitts positions and pack my keyboard full of
immediate commands, she likes to use the mouse for everything and
doesn't have any command object in any corner or edge |
| 23:45.47 |
starseeker |
``Erik:
spoken like a true vim user :-) |
| 23:45.47 |
``Erik |
(doesn't even
run the program full screen) |
| 23:46.02 |
brlcad |
it was pretty
simple -- if you do a "db get_type foo" in a db, it'll either tell
you "foo"'s type if it found that object or return an
error |
| 23:46.20 |
brlcad |
he was making
a new user command and wanted to supress that error |
| 23:46.30 |
``Erik |
I use both
vim and emacs these days... and netbeans on occasion :) I like to
imagine that I strive to be task oriented instead of tool
oriented |
| 23:46.33 |
brlcad |
which is done
by simply wrapping the command in a catch statement |
| 23:46.43 |
brlcad |
catch {db
get_type foo} |
| 23:46.53 |
brlcad |
will return 0
or 1 on success/failure |
| 23:46.57 |
``Erik |
ok, lee asked
me and I immediately threw my hands up and said "ain't my
turf" |
| 23:47.07 |
brlcad |
well now ya
know ;) |
| 23:47.11 |
brlcad |
can catch
most commands |
| 23:47.16 |
``Erik |
I've already
forgotten :D |
| 23:47.38 |
``Erik |
when we get
python and lisp wired in right, mebbe I'll pay more attention
O:-) |
| 23:48.06 |
brlcad |
has little to
do with tcl |
| 23:48.24 |
``Erik |
if I had to
write a mod for one of my eggdrop bots, I'd probably rewrite the
bot in C to avoid being in the neighborhood of tcl |
| 23:48.42 |
brlcad |
in any
arg-style command language it'd be nearly the same |
| 23:48.57 |
``Erik |
I assume the
tcl 'catch' is modelled after the 'error/catch' facility found in,
uhhhh, lisp, snobol, etc? |
| 23:49.09 |
brlcad |
pretty
much |
| 23:49.10 |
``Erik |
um, like an
exception? |
| 23:49.15 |
``Erik |
in
c++/jabba? |
| 23:49.18 |
brlcad |
sorta |
| 23:49.23 |
brlcad |
little more
basic than exceptions |
| 23:49.32 |
brlcad |
just captures
the result in a variable |
| 23:49.34 |
``Erik |
oh, so it
doesn't grok heirarchy |
| 23:49.42 |
``Erik |
just a
push/jmp/pop |
| 23:50.08 |
brlcad |
akin to
something like: foo="`cat asdf 2>&1`" ; echo $? |
| 23:50.17 |
brlcad |
if this were
posix shell interp |
| 23:50.24 |
``Erik |
*nod*
push/jmp/pop :) |
| 23:50.28 |
brlcad |
catch {cat
asdf} foo |
| 23:53.27 |
``Erik |
ralith ==
ben? |
| 23:54.10 |
``Erik |
is looking at gsoc crap |
| 23:54.20 |
madant_ |
:) |
| 23:55.02 |
``Erik |
ya'll with
your weirdassed handles |
| 23:55.18 |
``Erik |
Hi, my name
is Erik, my handle is Erik, if you want to connect the dots, it's
Erik. |
| 23:55.21 |
``Erik |
:D |
| 23:55.51 |
CIA-28 |
BRL-CAD:
03brlcad * r34423 10/brlcad/trunk/src/ (28 files in 17 dirs):
universally use [W] instead of directly accessing plane_t's
distance factor at index [3]. it's a homogeneous scaling
factor. |
| 23:58.08 |
``Erik |
w00t,
:g/\[3\]/[W]/g ftw |
| 23:58.16 |
brlcad |
heh, not
quite |
| 23:58.41 |
``Erik |
is 'w'
understandable in all those contexts, or commented if not?
:D |
| 00:02.09 |
*** join/#brlcad madant_
(n=d@117.196.130.205) |
| 02:37.46 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 03:15.34 |
brlcad |
starseeker:
hehe, cool |
| 03:42.22 |
CIA-28 |
BRL-CAD:
03brlcad * r34437 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
ws indent style cleanup plus consistently wrap all of the (*nh) to
be encased consistently in wraps. |
| 04:52.40 |
*** join/#brlcad madant
(n=d@117.196.134.144) |
| 05:12.29 |
*** join/#brlcad elena (n=elena@92.86.0.28) |
| 05:24.25 |
elena |
~log |
| 05:24.26 |
ibot |
methinks log
is http://ibot.rikers.org/%23wowhead/ |
| 05:55.53 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 06:04.19 |
*** join/#brlcad madant
(n=d@117.196.129.202) |
| 07:09.50 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 08:54.27 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.251.16) |
| 10:34.12 |
*** join/#brlcad madant_
(n=d@117.196.131.200) |
| 10:46.39 |
*** join/#brlcad Mouette
(n=chatzill@122-116-39-75.HINET-IP.hinet.net) |
| 10:51.38 |
*** join/#brlcad CIA-28
(n=CIA@208.69.182.149.simpli.biz) |
| 11:30.32 |
d-lo |
brlcad &
``Erik: something as small as that lotus, doing 0-120mph in 7
seconds, is frightening to say the least... |
| 11:31.25 |
d-lo |
Ralith:
FORTRAN is good, just make sure the GUI is scriptable with
VBA. |
| 11:40.51 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 11:40.59 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 11:48.55 |
CIA-28 |
BRL-CAD:
03indianlarry * r34438 10/brlcad/trunk/src/conv/step/Makefile.am:
fixing step-g build |
| 12:25.09 |
brlcad |
notes that apparently broke the build (possibly just
distcheck) |
| 12:30.05 |
d-lo |
brlcad: are
you talking about r34438? |
| 12:30.55 |
brlcad |
yep |
| 12:31.46 |
brlcad |
can you take
a look,
https://pawl.arl.army.mil/cruisecontrol/builds/brlcad-trunk/34438 |
| 12:32.30 |
brlcad |
should be
able to expand the log, get details at the bottom |
| 12:33.59 |
d-lo |
...the only
thing I see is a warning. No errors. Additionally, is it a bad
sign that it builds fine on my machine? ;) |
| 12:34.44 |
brlcad |
what's the
warning? |
| 12:35.01 |
d-lo |
"config.status: WARNING: Makefile.in seems
to ignore the --datarootdir setting " |
| 12:35.10 |
brlcad |
it's not a
bad sign, you're not testing nearly as much as the regression test
is |
| 12:35.58 |
brlcad |
could be a
cruisecontrol hiccup -- look at the latest log (take off /34438
from the url) |
| 12:36.15 |
brlcad |
looks like it
may have been interrupted and restarted as there is a
.1 |
| 12:37.46 |
brlcad |
build is fine
here too, so it could be a false positive .. the full tests take a
half hour though so won't know for a bit |
| 12:38.02 |
d-lo |
strange. I
am no expert (duh) but it lookes like once the ./configure is
complete, it fires off a distclean and then stops in the middle of
it. |
| 12:39.11 |
brlcad |
ehm, are you
looking at the full log? |
| 12:40.04 |
d-lo |
strangeness.
interweb hiccup. F5 for the win. |
| 12:41.38 |
d-lo |
is the
regression testing using Automake v1.10 on purpose? Seems a bit
old. |
| 12:42.48 |
brlcad |
no, it's just
using the system default |
| 12:42.50 |
brlcad |
1.10 is
fine |
| 12:43.06 |
brlcad |
in fact, ours
should even work all the way through 1.6 |
| 12:43.27 |
brlcad |
autogen has
version validation checks |
| 12:43.36 |
d-lo |
well this
machine has 1.9.6 installed and it seems to be working just
fine. |
| 12:44.13 |
brlcad |
eh |
| 12:44.15 |
brlcad |
missing
something |
| 12:44.20 |
brlcad |
what did the
cc log say? |
| 12:44.46 |
brlcad |
it's what's
saying it failed, that's all that really matters to
check |
| 12:45.17 |
brlcad |
repost it to
pastebin |
| 12:47.28 |
d-lo |
http://pastebin.bzflag.bz/m1ed56600 |
| 12:48.15 |
brlcad |
make[3]:
../../../src/other/step/src/fedex_plus/fedex_plus: Command not
found |
| 12:48.28 |
brlcad |
thats the
error |
| 12:48.35 |
d-lo |
right, I
figured :) |
| 12:50.33 |
brlcad |
trying to
build the fedex sources, yours probably skips that build rule on a
regular build, but those sources are needed for a
distcheck |
| 12:51.03 |
brlcad |
s/probably
skips/is skipping/ |
| 12:54.06 |
brlcad |
he needs to
try a distcheck |
| 12:54.39 |
d-lo |
to be clear:
make distcheck should recreate the same error that cc is
reporting? |
| 12:55.22 |
brlcad |
I believe so,
think the problem is just that built_sources is in
extra_dist |
| 12:56.18 |
brlcad |
ah, he added
them to SOURCES, so yeah that means they need to be in the
dist |
| 13:00.36 |
CIA-28 |
BRL-CAD:
03brlcad * r34439 10/brlcad/trunk/src/conv/step/Makefile.am:
annotate three FIXME's in this file that should help with the
distchecking and build cleanup |
| 13:12.09 |
*** join/#brlcad madant
(n=d@117.196.130.64) |
| 13:28.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 13:29.17 |
*** join/#brlcad phyTurtle
(n=turtle@pooh.korea.ac.kr) |
| 13:33.12 |
*** join/#brlcad Mouette
(n=chatzill@122-116-39-75.HINET-IP.hinet.net) [NETSPLIT
VICTIM] |
| 13:33.12 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) [NETSPLIT
VICTIM] |
| 13:45.13 |
CIA-28 |
BRL-CAD:
03starseeker * r34440
10/brlcad/branches/STABLE/src/librt/primitives/pipe/pipe.c: Add the
key pipe fix to stable - looks like trunk has some of the ifree
tweaks in it so wait for a proper merge to sync pipe.c with the
trunk pipe.c |
| 13:58.04 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:58.40 |
mafm |
hi |
| 14:17.05 |
phyTurtle |
Hi, I'm a
newcomer of using brlcad |
| 14:17.28 |
elena |
hi |
| 14:17.45 |
phyTurtle |
nowadays, I'm
learning using brlcad following tutorial. |
| 14:18.54 |
phyTurtle |
Also, I read
some source code to see what I can contribute to code. |
| 14:19.54 |
phyTurtle |
However, I
couldn't where I can start. |
| 14:20.21 |
elena |
you could try
to fix a small bug |
| 14:20.37 |
phyTurtle |
So, dose
anybody tell me a starring point? |
| 14:20.44 |
phyTurtle |
bugs? |
| 14:21.03 |
elena |
if you want
to contribute. |
| 14:21.22 |
elena |
if you want
to learn how to use it, the tutorial is a great place to
start. |
| 14:21.55 |
phyTurtle |
then how
about learing the mechanism of the program? |
| 14:22.18 |
phyTurtle |
is bug fixing
still good way to learing it? |
| 14:22.35 |
elena |
I can't
answer that. |
| 14:22.47 |
elena |
but I guess
it depends on you. |
| 14:23.12 |
elena |
do you feel
you're learning by tracking bugs. |
| 14:23.14 |
elena |
? |
| 14:23.53 |
phyTurtle |
well.... |
| 14:24.02 |
``Erik |
there're ~400
executables, many libraries... it's a big package, you'd have to
figure out which part you're interested in before really jumping
in... :) |
| 14:24.03 |
phyTurtle |
Yes.. Many
times.. |
| 14:24.31 |
phyTurtle |
Actually, I
am a physicist. |
| 14:24.43 |
elena |
waves ``Erik |
| 14:24.44 |
phyTurtle |
So, I'm not
good at programming.. |
| 14:24.50 |
starseeker |
howdy
elena |
| 14:24.51 |
``Erik |
*wave* |
| 14:24.57 |
elena |
hi
starseeker. |
| 14:25.15 |
``Erik |
c'mon,
starseeker, stand up and sit down, we're doing the wave here
:D |
| 14:25.25 |
elena |
than jumping
right to bugs might not be a good idea. |
| 14:25.31 |
elena |
than =>
then |
| 14:25.44 |
starseeker |
crushes chairs doing that |
| 14:25.46 |
phyTurtle |
hmm.. |
| 14:26.32 |
elena |
did you
managed to checkout and build brlcad? |
| 14:27.08 |
elena |
btw, fyi, i'm
a brlcad user, not programmer. |
| 14:27.54 |
phyTurtle |
sorry,
pardon? I can't follow you.. what is fyi? |
| 14:28.03 |
``Erik |
"for your
information" |
| 14:28.05 |
elena |
for your
information |
| 14:29.02 |
elena |
btw = by the
way. |
| 14:30.54 |
phyTurtle |
do you mean
that I installed on my system with source code? |
| 14:31.06 |
elena |
yes. |
| 14:31.09 |
phyTurtle |
yes |
| 14:31.20 |
elena |
what's your
system, btw. just curious. |
| 14:31.25 |
phyTurtle |
I used source
code and built on my linux system |
| 14:31.31 |
phyTurtle |
ubuntu
8.04 |
| 14:31.39 |
elena |
ok. that's a
good start. |
| 14:31.51 |
phyTurtle |
thanks |
| 14:32.03 |
starseeker |
phyTurtle:
what are your interests? CAD is a big field, do you have specific
subject areas in mind? |
| 14:32.09 |
phyTurtle |
yes |
| 14:32.23 |
phyTurtle |
I am
developing FDTD library |
| 14:32.39 |
brlcad |
howdy
phyTurtle |
| 14:32.45 |
brlcad |
and
welcome! |
| 14:32.54 |
phyTurtle |
Finite
Difference Time domain method which is a Electromagnetic simulation
algorithm |
| 14:32.55 |
d-lo |
hai
phyTurtle! |
| 14:33.03 |
phyTurtle |
hello. |
| 14:33.07 |
d-lo |
regular party
up in here. |
| 14:33.40 |
starseeker |
phyTurtle: Is
your interest to integrate that method with the physical geometry
abilities of a CAD system? |
| 14:33.51 |
phyTurtle |
In the FDTD
Library, inserting structure is horrible task. |
| 14:34.14 |
phyTurtle |
especially 3D
structure simulation. |
| 14:34.49 |
phyTurtle |
So I seek
some software which could modle solid structure |
| 14:35.07 |
phyTurtle |
modle->model |
| 14:35.09 |
starseeker |
what sort of
structural information do you need for a FDTD analysis? surfaces,
volumes, triangles... |
| 14:35.39 |
phyTurtle |
Just the info
of mesh point |
| 14:36.07 |
starseeker |
ok, so the
geometry problem is merging meshes? |
| 14:36.09 |
phyTurtle |
FDTD use
rectangular mesh to model electric field and magnetic
field |
| 14:36.13 |
phyTurtle |
yes |
| 14:36.16 |
brlcad |
phyTurtle:
are you at all interested in data processing (like wavelets, FFTs,
etc) or mostly modeling and/or geometry? |
| 14:36.27 |
phyTurtle |
mostly
geometry |
| 14:37.00 |
phyTurtle |
I need info
of points which intersect with solid objects |
| 14:37.03 |
brlcad |
cool, then a
great starting point (on the programming side) is our procedural
modeling facilities |
| 14:37.14 |
brlcad |
maybe
starting out with a little program that "makes
something" |
| 14:37.23 |
phyTurtle |
ok.. |
| 14:37.34 |
brlcad |
there are
lots of examples to get you started, but that's one area that's
pretty well defined and easy to get into |
| 14:37.56 |
phyTurtle |
well I have
found that 'NIRT' do the task I need |
| 14:38.16 |
brlcad |
are you
specifically interested in programming or are you looking for how
you can "get things done" for whatever your end goals
are? |
| 14:38.31 |
brlcad |
like the
difference between writing an app or writing a script that does the
same thing |
| 14:38.46 |
phyTurtle |
Well shot
goal is find the points which intersect the objedts.. |
| 14:39.12 |
brlcad |
scripting
nirt is a great way to sample geometry, get in/out hit points along
a given line as it intersects geometry |
| 14:39.20 |
phyTurtle |
and the great
goal is joining the brlcad programming.. |
| 14:39.26 |
brlcad |
:) |
| 14:39.41 |
brlcad |
but then to
shoot nirt .. you need to have geometry to shoot at |
| 14:39.44 |
brlcad |
what is your
data now? |
| 14:39.59 |
brlcad |
in your head?
design specs? models in other cad formats? |
| 14:39.59 |
starseeker |
wait... do
you have pre-existing meshes you need to intersect rays with, or do
you actually need to merge two distinct meshes into a single
mesh? |
| 14:41.29 |
phyTurtle |
my plan is
using brlcad, modelling simulation structure first |
| 14:42.11 |
phyTurtle |
second,
defining mesh (ray) which I want know intersection
points |
| 14:42.36 |
phyTurtle |
third, saving
intersecting points for each mesh grid. |
| 14:42.59 |
brlcad |
so you have
some running simulation code, then, and from that simulation you
already have geometry or you will need to derive
geometry? |
| 14:43.19 |
phyTurtle |
brfore the
simulation. |
| 14:43.49 |
phyTurtle |
I should
define the geometry. |
| 14:43.51 |
brlcad |
so you're
going to model something and put it into a simulation |
| 14:43.54 |
brlcad |
okay |
| 14:43.56 |
phyTurtle |
yes |
| 14:44.08 |
phyTurtle |
It is not
time running modeling. |
| 14:45.18 |
phyTurtle |
I just skimed
the nirt tutorial. |
| 14:45.19 |
brlcad |
so some sort
of way to represent an electric field and a magnetic
field |
| 14:45.43 |
phyTurtle |
well.. |
| 14:45.53 |
phyTurtle |
for
example. |
| 14:46.15 |
phyTurtle |
I put the
dielectric sphere ball in the space. |
| 14:46.46 |
phyTurtle |
and insert
incident wave(initial condition) |
| 14:47.14 |
phyTurtle |
later, by the
dielectric sphere, electric field and magnetic field is
changed. |
| 14:47.25 |
phyTurtle |
I need to
model the dielectric sphere. |
| 14:47.32 |
phyTurtle |
not the field
info. |
| 14:49.58 |
phyTurtle |
Some of FDTD
developer used AutoCad or ACIS to model the dielectric
sphere. |
| 14:50.24 |
phyTurtle |
So, I
searched similar library and I found brlcad. |
| 14:54.03 |
elena |
have to go.
bye |
| 14:54.09 |
d-lo |
bye! |
| 14:54.10 |
brlcad |
cya
elena! |
| 14:54.25 |
elena |
good luck,
phy. let me know how it goes. |
| 14:54.29 |
phyTurtle |
bye! |
| 14:54.31 |
phyTurtle |
yes |
| 14:54.51 |
brlcad |
phyTurtle:
ever worked with metaballs? |
| 14:55.05 |
phyTurtle |
no |
| 14:55.07 |
brlcad |
http://brlcad.org/gallery/s/renderings/primitives/niceballs.png.html |
| 14:55.29 |
brlcad |
promises that it's safe for work :) |
| 14:55.31 |
CIA-28 |
BRL-CAD:
03davidloman * r34441
10/brlcad/trunk/src/other/step/src/clstepcore/ (sdaiSelect.cc
sdaiSelect.h): Changed a return type from int to long in order to
support building on 64bit hardware. |
| 14:56.43 |
phyTurtle |
what is
metaball? |
| 14:57.20 |
phyTurtle |
now I'm
looking the image.. but I can't figure out what it is.. |
| 14:59.40 |
brlcad |
another
example:
http://www.math.sunysb.edu/%7Esorin/online-docs/blender/html/x2708.html |
| 15:00.08 |
brlcad |
basically
they are points with a 'weight' .. that then cause volumes and
field effects |
| 15:01.23 |
brlcad |
so that you
get blended volume between your field points |
| 15:02.02 |
brlcad |
ah, here we
go.. some nice examples: http://sayinghai.com/metaballs3d.html |
| 15:06.28 |
phyTurtle |
is metaball
using raytracing too? |
| 15:09.01 |
phyTurtle |
I need the
info that if a ray intersect a solid, what the intersection point
is, on rectangular coordinate. |
| 15:09.53 |
phyTurtle |
I think I
need to study elimentary computational geometry and ray
tracing. |
| 15:10.36 |
phyTurtle |
so, could you
recommand me some reference? book or paper..? |
| 15:25.05 |
brlcad |
yes, you can
shoot a nirt ray at a metaball too |
| 15:25.27 |
brlcad |
it does
represent a solid with defined inside/outside
characterization |
| 15:28.30 |
brlcad |
really don't
think studying computational geometry or ray tracing is going to
help you get up to speed, but there are lots of great books and
papers (thousands really) .. |
| 15:29.11 |
phyTurtle |
ok.
thanks^^ |
| 15:29.24 |
phyTurtle |
now I should
go. |
| 15:29.35 |
phyTurtle |
here is 24:30
now. |
| 15:29.57 |
phyTurtle |
see you later
. bye! |
| 15:29.58 |
brlcad |
okay, good
talking to you |
| 15:30.07 |
brlcad |
someone's
generally always here ;) |
| 15:30.08 |
brlcad |
cya |
| 15:30.20 |
phyTurtle |
thanks.
bye |
| 15:32.47 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:34.24 |
starseeker |
was thinking mesh intersections would be a good excuse to
integrate GTS |
| 15:35.50 |
starseeker |
It's not a
problem with the pipe solid data - it's a problem with how the
pipe code was handling one particular case in the shot results. If
you raytrace from a slightly different view you might avoid the
problematic case, but odds are equally good you'll still run into
it. |
| 15:35.54 |
starseeker |
I'll push the
fix into the STABLE branch this morning, but I don't think there's
anything you can do to the pipe itself to avoid the
bug. |
| 15:36.00 |
starseeker |
whoops |
| 15:36.01 |
starseeker |
sorry |
| 15:37.27 |
starseeker |
mutters under his breath about text selection integration on
Mac between X11 and normal apps... |
| 15:37.52 |
starseeker |
Anyway,
http://gts.sourceforge.net/gallery.html
shows some examples of mesh intersections, unions, subtractions,
etc |
| 15:46.37 |
CIA-28 |
BRL-CAD:
03bob1961 * r34442
10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added
scale_ell.c and scale_tor.c to the libged build file for
windows. |
| 15:51.33 |
CIA-28 |
BRL-CAD:
03bob1961 * r34443
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Modified the
windows build file for librt (i.e. mirror.c and table.c have
moved). |
| 17:07.37 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 17:23.22 |
CIA-28 |
BRL-CAD:
03bob1961 * r34444 10/brlcad/trunk/misc/win32-msvc8/ (19 files in
19 dirs): Mods to accommodate new files, moved files and deleted
files. |
| 17:29.26 |
CIA-28 |
BRL-CAD:
03bob1961 * r34445 10/brlcad/trunk/src/ (archer/archer.bat
mged/mged.bat util/rtwizard.bat): Update to 7.14.7 |
| 17:30.52 |
CIA-28 |
BRL-CAD:
03bob1961 * r34446 10/brlcad/trunk/ (7 files in 5 dirs): Added code
to edit torus attributes in Archer via the mouse. |
| 18:19.52 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-110.dclient.hispeed.ch) |
| 18:33.22 |
CIA-28 |
BRL-CAD:
03bob1961 * r34447
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Have
rt_metaball_point_value_metaball return something to make the
compiler happy. |
| 18:35.22 |
CIA-28 |
BRL-CAD:
03bob1961 * r34448 10/brlcad/trunk/include/raytrace.h: Put back
declarations for rt_pipept_print and
rt_metaballpt_print. |
| 18:37.48 |
CIA-28 |
BRL-CAD:
03bob1961 * r34449 10/brlcad/trunk/src/fb/fbfade.c: Do an #ifndef
drand48 before defining a drand48 function. |
| 19:06.45 |
CIA-28 |
BRL-CAD:
03bob1961 * r34450 10/brlcad/trunk/src/proc-db/ (terrain.c
vegitation.c): Do an #ifndef drand48 before defining a drand48
function. |
| 19:21.47 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 19:23.18 |
CIA-28 |
BRL-CAD:
03brlcad * r34451 10/brlcad/trunk/NEWS: |
| 19:23.18 |
CIA-28 |
BRL-CAD: this
one is borderline user-visible but does impact the style/appearance
of mged |
| 19:23.18 |
CIA-28 |
BRL-CAD: and
archer so go ahead and mention it. bob worked on converting
several/many of |
| 19:23.18 |
CIA-28 |
BRL-CAD: the
widgets in archer and a couple in mged over to using the new tk
'ttk' |
| 19:23.18 |
CIA-28 |
BRL-CAD:
widgets. ttk is a new modular themable widget system developed for
tcl/tk 8.5. |
| 19:23.20 |
CIA-28 |
BRL-CAD:
these new widgets even further make BLT unnecessary. |
| 20:15.58 |
CIA-28 |
BRL-CAD:
03brlcad * r34452 10/brlcad/trunk/src/fb/fbfade.c: consistency
cleanup, remove ancient irrelevant docs |
| 20:17.39 |
CIA-28 |
BRL-CAD:
03brlcad * r34453 10/brlcad/trunk/src/fb/fbfade.c: it's already
wrapped, kinda silly to double-wrap it |
| 20:18.21 |
CIA-28 |
BRL-CAD:
03brlcad * r34454 10/brlcad/trunk/include/config_win.h: it's
provided as a define for windows, so define HAVE_DRAND48 to
true |
| 20:19.17 |
CIA-28 |
BRL-CAD:
03bob1961 * r34455 10/brlcad/trunk/include/ (common.h
opennurbs_ext.h): Mods for building on Windows. |
| 20:33.17 |
CIA-28 |
BRL-CAD:
03brlcad * r34456 10/brlcad/trunk/src/proc-db/ (terrain.c
vegitation.c): ya killin' me bob. revert r34450. HAVE_DRAND48 is
now defined per config_win.h so shouldn't need all that hackery and
code duplication. if you need the same code in more than one place,
it's the wrong way. |
| 20:35.57 |
CIA-28 |
BRL-CAD:
03indianlarry * r34457 10/brlcad/trunk/src/conv/step/Makefile.am:
reverting back to revision 34408 to fix distcheck on cruisecontrol
will clean up monday |
| 20:36.12 |
CIA-28 |
BRL-CAD:
03brlcad * r34458 10/brlcad/trunk/src/proc-db/terrain.c: should be
the other way around. rand_s() is very windowsy. some minor ws
cleanup too. |
| 20:48.27 |
``Erik |
ah, dave
applied the fix to src/other/step that I was about to dig into (I
think it's treating it like a boolean, so the extra precision is
unnecessary) |
| 21:04.29 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 21:53.34 |
*** join/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 21:53.44 |
*** join/#brlcad BxCx
(n=BxCx@189.182.244.112) |
| 21:55.15 |
rincon |
does brl cad
has dimensioning facilities, distance measuring tools, and
precision enough to make engineering 2d drawings |
| 21:58.26 |
*** part/#brlcad BxCx
(n=BxCx@189.182.244.112) |
| 22:00.01 |
brlcad |
rincon: there
are very limited dimensioning facilities (at least for producing 2d
drawings), nothing automatic |
| 22:00.12 |
brlcad |
there are
various measuring tools, though, very good ones at that |
| 22:00.37 |
brlcad |
there's also
automatic drawing generation, just unannotated |
| 22:00.49 |
brlcad |
e.g.,
http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 22:01.24 |
brlcad |
if you wanted
to add annotations for dimensions, though, you'd have to calculate
them and add them to the image manually |
| 22:01.38 |
brlcad |
would be a
great addition for someone to make, but to date hasn't
happened |
| 22:01.50 |
rincon |
verical
horizontal and radial are enough dimensioning facilities for me,
does it has it? |
| 22:02.11 |
brlcad |
``Erik: you
should fix that better .. that pointer->int/long cast seems
wrong |
| 22:02.22 |
brlcad |
make it
return a bool if it's a bool |
| 22:02.52 |
brlcad |
rincon: yeah,
those are easy to calculate -- you can create a bounding box around
any arbitrary object and get the dimensions of that box |
| 22:03.27 |
brlcad |
could even
probably script them together so it's a one step operation if you
really needed to call it a lot |
| 22:03.42 |
rincon |
brlcad: what
i mean is to draw dimensioning symbols |
| 22:04.30 |
rincon |
like basic
dimensioning autocad facilities does? |--------|
...... |
| 22:05.29 |
brlcad |
starseeker:
for those particular cases, gts provides nothing that nmg doesn't
already do |
| 22:05.48 |
brlcad |
and even
better, our nmg routines should do much better to preserve solidity
(gts doesn't care) |
| 22:06.29 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FB10.dip.t-dialin.net) |
| 22:06.51 |
brlcad |
rincon: i
know what you mean -- that's what I was referring to with "you'd
have to calculate them and add them to the image
manually" |
| 22:07.13 |
brlcad |
calculating
the dimension is done fairly easily, but not automatic, and not
graphically |
| 22:07.36 |
brlcad |
you'd have to
add whatever dimensions you want to the image manually |
| 22:08.10 |
brlcad |
that's more a
drafting feature, so we just haven't had a lot of demand/priority
for it compared to other issues |
| 22:08.30 |
rincon |
does brl cad
has the capability of drawing a circle of radius 0.0000001
? |
| 22:08.38 |
brlcad |
sure |
| 22:09.41 |
brlcad |
have to keep
absolute units into account, though |
| 22:09.58 |
brlcad |
all values
are stored as mm, so you'd have to be working in a larger
scale |
| 22:10.49 |
rincon |
brlcad: can
you draw in m in brlcad? |
| 22:10.51 |
brlcad |
you can shift
the scale by setting a much larger working scale to the
model |
| 22:10.57 |
brlcad |
sure |
| 22:10.58 |
rincon |
meters? |
| 22:11.01 |
brlcad |
"units
m" |
| 22:11.13 |
brlcad |
you can
arbitrarily change your units as needed |
| 22:11.24 |
rincon |
that is
good |
| 22:12.16 |
brlcad |
it's common
that a modeler will have part data for one object in meters,
another in feet, yet another part in mm .. you just set units while
you work and everything is seamless |
| 22:12.44 |
rincon |
brlcad: in
that particular is better than autocad |
| 22:13.25 |
brlcad |
we're better
than autocad in *many* ways under the hood .. |
| 22:13.35 |
brlcad |
we're just a
lot worse with regards to GUI and usability :) |
| 22:13.49 |
rincon |
brlcad: the
dimensioning part needs more collaboration |
| 22:13.59 |
brlcad |
sure, you
going to work on it? :) |
| 22:14.34 |
rincon |
brlcad: i do
not have enough time, by now by i'd like to |
| 22:14.43 |
rincon |
by=but |
| 22:14.54 |
brlcad |
common
problem |
| 22:15.00 |
brlcad |
which is why
it's not implemented ;) |
| 22:15.25 |
rincon |
brlcad: yes i
will collaborate some of these days |
| 22:15.32 |
rincon |
give me
time |
| 22:19.04 |
rincon |
brlcad: does
brlcad use layers , and groups objects into compound block
entiities? |
| 22:19.59 |
brlcad |
layers can be
achieved through combinations, but they aren't specific/separate
entities |
| 22:20.07 |
brlcad |
they are
generalized object groupings |
| 22:20.43 |
brlcad |
so 'yes', but
not exactly the same way as autocad -- can achieve the exact same
end-result though |
| 22:21.44 |
rincon |
but can you
group automatically as you draw, or you have to add objects one by
one? |
| 22:23.17 |
brlcad |
latter,
nearly everything is explicit (intentionally) |
| 22:24.58 |
rincon |
brlcad: for
example to tell cad all things i will draw today will be on group
"A"? |
| 22:26.43 |
rincon |
is it
possible?, or you have to draw first and group
later...? |
| 22:27.04 |
brlcad |
like I said,
nothing is automatic |
| 22:27.16 |
brlcad |
so you'd have
to create the objects, then add them to groups |
| 22:27.40 |
brlcad |
if you had
three objects, a b c, and wanted to group them: g mygroup a b
c |
| 22:28.28 |
brlcad |
if you gave
them a consistent naming convention, a.r b.r c.r, you could use
globbing: g mygroup *.r |
| 22:28.50 |
rincon |
i will not
call that automatic, it is just to put a flag in the object that
identifies the group by default.....seems to be easy to
program |
| 22:29.31 |
brlcad |
it's not a
matter of difficulty |
| 22:29.40 |
brlcad |
hence the
(intentionally) comment |
| 22:30.13 |
brlcad |
it's
something that would be happening potentially unbeknownst to you,
and certainly not explicit at the minimum |
| 22:30.52 |
brlcad |
or if your
specific example, that'd be very stateful, something you'd have to
"turn on / turn off" .. and how do you introspect to know when that
behavior is on/off |
| 22:34.31 |
rincon |
i know it is
a matter of collaboration, but thinking about the solution is the
first step, objects are complex entities that has many aspects if
you set all of the aspects to a default value the group must be one
of them and a default group can be the group "0" for
exampl |
| 22:36.33 |
rincon |
and you can
set a enviroment variable with the current group |
| 22:38.19 |
brlcad |
therein is
one of the differences -- it does make sense for all objects to
exist on some 'layer' as an entity type, but not on a generalized
group |
| 22:38.34 |
brlcad |
there are
plenty of objects/models that exist without any group |
| 22:38.38 |
``Erik |
*readreadread* autocad is more of a
computer aided drafting program, BRL-CAD is more of a computer
aided engineering/analysis package |
| 22:39.33 |
brlcad |
I think it
would be useful to add a concept of layers as specific entities (as
they have very different behaviors and semantics from groups,
distinct subset) |
| 22:39.42 |
rincon |
Erik: you can
not analyze nothing if do not draw it first |
| 22:40.01 |
``Erik |
was looking into changing that method to bool, was
researching how it was used to make sure his assumption is
correct |
| 22:40.14 |
brlcad |
'draw' is
very much a drafting term.. you don't draw objects, you model them
:) |
| 22:40.29 |
brlcad |
2d vs 3d
terminology ;) |
| 22:40.59 |
``Erik |
BRL-CAD grew
up modeling existing objects to do things to/with them, so the
whole path to generate a blueprint really wasn't a factor
:D |
| 22:41.30 |
brlcad |
and brl-cad
has it's own terminology where 'draw' specifically means to display
the object up on the screen, not modify or create |
| 22:41.59 |
rincon |
brlcad:
drawing is basic, you have to start by basic to move
forward |
| 22:42.19 |
``Erik |
that depends
on how you define "draw" |
| 22:42.55 |
brlcad |
rincon:
*drafting* is basic, and no you don't have to start with
drafting |
| 22:42.55 |
rincon |
draw: is to
draw a building for example |
| 22:43.23 |
brlcad |
the act of
modeling may or may not be basic |
| 22:43.24 |
``Erik |
the only
thing you can define recursively is recursion. |
| 22:44.48 |
rincon |
Erik: is
brlcad the most close i can find to autocad in free
software? |
| 22:45.14 |
``Erik |
um, I think
things like 'qcad' might be fundamentally closer, but not nearly as
mature |
| 22:45.26 |
brlcad |
rincon: we're
by far the most feature complete, but qcad focuses on
2D |
| 22:46.05 |
``Erik |
I don't think
wings3d or ac3d are close to either, they're more like
3dmax |
| 22:46.35 |
brlcad |
rincon: not
to misunderstand -- I don't disagree entirely with what you're
saying, other than the specific meaning of those terms, or even
disagree that we shouldn't have some feature such as you
suggest |
| 22:46.43 |
``Erik |
I think steve
abandoned ppe |
| 22:47.14 |
``Erik |
d'no the scene 'nuff to say much, though |
| 22:47.20 |
brlcad |
rincon: it's
more a matter of there are 10000 things we can be working on, and
that's simply not a priority at the moment, but could be if you
were working on it ;) |
| 22:47.36 |
``Erik |
hehehehe
patches welcome! :D |
| 22:48.14 |
``Erik |
brlcad: what
was that trivial patch you guys were discussing
earlier? |
| 22:48.26 |
brlcad |
dunno |
| 22:48.34 |
rincon |
brlcad: is it
more practical draw engineering plans in qcad than doing it in
brlcad? |
| 22:48.44 |
``Erik |
also; what're
some good search keywords for that video you mentioned on the way
back from lunch? :D |
| 22:48.57 |
brlcad |
rincon: if
your end-goal is drafting diagrams and your okay not having a 3D
model, sure |
| 22:49.24 |
rincon |
i mean plans
of civil engineering for example |
| 22:49.29 |
brlcad |
they have a
lot more 2D drafting features than brl-cad has, we focus a LOT more
on 3D and solid modeling |
| 22:49.40 |
``Erik |
rincon: you
mean blueprints, yes? |
| 22:50.10 |
brlcad |
civil
engineering plans ARE drafting diagrams |
| 22:50.11 |
rincon |
i mean the
design of a concrete structure for example? |
| 22:50.31 |
brlcad |
just a
specific domain subset |
| 22:50.45 |
``Erik |
http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html
this is the closest we get atm |
| 22:51.13 |
brlcad |
rincon: I'm
getting the sense that you don't seem to understand the distinction
between the drafting and non-drafting approaches to modeling --
they are very very different |
| 22:51.36 |
brlcad |
autocad is
from the ground up predominantly a drafting system, but that's not
the only way by a long shot |
| 22:51.37 |
``Erik |
but we can do
things like photorealistic rendering, stress/strain analysis,
solving mass of structures, etc. that your drafting programs won't
do |
| 22:52.26 |
brlcad |
systems like
catia, unigraphics, and pro/engineer are not predominantly drafting
systems (yet still CAD), they're 3D solid modeling systems that
utilize a non-drafting approach at their core |
| 22:53.00 |
brlcad |
important to
understand that distinction as it affects the outputs that you're
talking about, your goals and products |
| 22:53.12 |
``Erik |
http://brlcad.org/gallery/s/diagrams/Industry_Diagram.png.html
might be good to consider and study :) |
| 22:56.26 |
rincon |
brlcad: do
you think is better to make a draw qcad? |
| 22:56.45 |
rincon |
brlcad: do
you think is better to make a 2D draw with qcad? |
| 22:56.46 |
brlcad |
rincon:
absolutely not, but then I'm very biased :) |
| 22:57.17 |
brlcad |
I think you
will find it a lot easier to generating 2D annotated drawings with
qcad, sure ;) |
| 22:57.31 |
brlcad |
but 'better',
hell no ;) |
| 22:58.43 |
``Erik |
if all you
want to do is make a blueprint and stop, qcad might be
sufficient... but once you want to go past that point, we can do
that where they cannot :) |
| 22:59.42 |
rincon |
Erik: qcad
needs a lot of collaboration.... |
| 23:00.17 |
``Erik |
http://www.qcad.org/qcad.html
if you read their pimp lit, they outright say they just do 2d line
(technical) drawings, we do 3d solid geometry :) |
| 23:00.55 |
brlcad |
rincon: it
does, we do a lot more by far, but we also need a lot of
'collaboration' as you put it |
| 23:01.39 |
brlcad |
so if you
want to help, just let someone know and they can help you get
familiarized with the source code or writing docs or isolating
bugs, etc |
| 23:02.00 |
brlcad |
otherwise, it
is what it is and we're working on making it better in the
meantime |
| 23:02.44 |
rincon |
Erik: brlcad:
isolating bugs sounds good to me but i am not sure if i like qcad
more than brlcad |
| 23:03.23 |
``Erik |
they're
different beasts with different purposes, dude... there's a bit of
overlap, but apples and oranges are both fruit *shrug* |
| 23:04.48 |
brlcad |
passive
contributions aren't nearly as useful as active contributions (i.e.
things that take time) .. we can all come up with 100 ways to make
brl-cad better, some new feature minor or major |
| 23:04.53 |
brlcad |
ideas are
cheap, time is not ;) |
| 23:04.53 |
``Erik |
if your
intent coincides with BRL-CAD, please, grab a bug or something off
the todo list, we'll help you where we can :) but we can't decide
which is more appropriate for you, you have to understand what your
goal is and make that choice yourself :) |
| 23:06.17 |
``Erik |
(I don't mean
to be rude, but *shrug* that's what it all boils down
to) |
| 23:06.38 |
rincon |
i think is
better to help brlcad because it is more advanced but , i think 2D
blueprints can improve more the humanity level than a deep
engineering capability |
| 23:07.52 |
rincon |
the monopoly
of autocad must be finished |
| 23:08.04 |
``Erik |
ok, I would
recommend that you play with the system a bit, make some models,
render then in various ways... then think of some ideas for how you
can make it better for you and talk to us then :) we can help steer
you towards the lower hanging fruit and where to dig in at that
time |
| 23:08.16 |
``Erik |
but that's
just my personal view here :) *shrug* |
| 23:09.34 |
``Erik |
there are
tutorials on the website that have been honed over a decade or two
of classes and use, that'd be a good approach to learning what
BRL-CAD is and is not at this time :) |
| 23:10.12 |
``Erik |
sound
good? |
| 23:11.14 |
CIA-28 |
BRL-CAD:
03brlcad * r34459 10/brlcad/trunk/src/proc-db/terrain.c: massive
cleanup and refactor of the nurbs terrain example. fix a memory
corruption and eliminate all globals. |
| 23:12.52 |
rincon |
Erik: brlcad
is not on the fedora repos, why? |
| 23:13.10 |
``Erik |
um, because
no one has taken the time to generate the binaries |
| 23:13.30 |
``Erik |
we have an
rpm spec file, but *shrug* I don't use linux myself |
| 23:13.43 |
``Erik |
(even though
I think I was the one who made the spec file... and the deb
directory) |
| 23:13.52 |
brlcad |
rincon:
perhaps a place you could help, work on getting it added to
fedora |
| 23:14.17 |
rincon |
Erik: i
prefer to isolate bugs |
| 23:14.22 |
``Erik |
has been remiss on support the FreeBSD port lately
:/ |
| 23:14.57 |
brlcad |
the answer is
99% of the time, because there are 100 other things we *are*
working on that were determined to be more important (out of the
10000 things we could be working on) |
| 23:15.55 |
brlcad |
just about
anyone could help get brl-cad into fedora -- I can probably count
on one hand how many people could add a new annotation primitive to
BRL-CAD :) |
| 23:17.05 |
rincon |
can brlcad be
installed in fedora? |
| 23:17.09 |
brlcad |
sure |
| 23:17.31 |
rincon |
let me see i
am going to install it first |
| 23:17.36 |
``Erik |
one of our
primary "paid for" targets is redhat enterprise, fedora isn't too
different |
| 23:18.01 |
brlcad |
someone was
working on it at one point, and supposedly had it done, but don't
know where it ended up |
| 23:23.42 |
``Erik |
*asplode*! |
| 23:23.51 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34460
10/brlcad/trunk/src/other/step/src/clstepcore/ (sdaiSelect.cc
sdaiSelect.h): |
| 23:23.51 |
CIA-28 |
BRL-CAD:
Change the exists() method to return a bool. This only seems to
be |
| 23:23.51 |
CIA-28 |
BRL-CAD: used
in that capacity and causes 32/64b issues by using the
address |
| 23:23.51 |
CIA-28 |
BRL-CAD: as
"true" and NULL as "false". |
| 23:24.27 |
``Erik |
indianlarry
can take it up with me on tuesday if I broke it |
| 23:24.32 |
``Erik |
:D |
| 23:24.58 |
rincon |
my processor
is an athlon which brlcad should i use |
| 23:25.16 |
brlcad |
notes NULL is not necessarily 0 ? :) |
| 23:25.17 |
``Erik |
the one you
build from source? |
| 23:25.35 |
``Erik |
no, but the
c++ makes that assumption |
| 23:25.36 |
brlcad |
athlon is
x86_64 |
| 23:25.56 |
``Erik |
it sets the
internal val to NULL, then acts like it's 0 when not set
elsewhere |
| 23:26.01 |
rincon |
http://sourceforge.net/project/showfiles.php?group_id=105292&package_id=113559 |
| 23:26.34 |
brlcad |
rincon:
yes? |
| 23:26.58 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34461
10/brlcad/trunk/src/other/step/src/clstepcore/sdaiSelect.cc: ok,
ok, NULL is not necessarily 0. |
| 23:27.00 |
``Erik |
now
stfu |
| 23:27.02 |
``Erik |
:D |
| 23:27.19 |
brlcad |
rincon: care
to redesign the website? :) |
| 23:27.26 |
brlcad |
wants a redesign badly for some reason |
| 23:28.06 |
rincon |
brlcad: i
just want to experiment the reality of brlcad |
| 23:28.21 |
``Erik |
redesign as
in heirarchal redesign, or a new css face? |
| 23:28.24 |
brlcad |
rincon: fair
enough |
| 23:28.28 |
brlcad |
new
facelift |
| 23:28.46 |
brlcad |
needs to have
a lot more of our information uploaded and organized too, but
that's a separate task altogether |
| 23:28.50 |
brlcad |
the
appearance |
| 23:29.02 |
brlcad |
actually have
a hierarchical organization all sorted out |
| 23:29.13 |
``Erik |
I don't quite
understand why people continue to build css by hand when there're
some quite nice css compilers out there |
| 23:29.14 |
brlcad |
worked on
that for hours a long time ago |
| 23:29.34 |
*** part/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 23:29.45 |
``Erik |
it's like
coding in assembly... yeah, it's good to learn how to do it, but
you simply don't do that in real life |
| 23:30.03 |
``Erik |
more than a
few hours to make it work on the various IE's iirc |
| 23:30.23 |
``Erik |
catch ya
later, rincon, nice meeting you O.o |
| 23:30.34 |
brlcad |
I mean I
worked for hours just on the hierarchical organization |
| 23:30.38 |
``Erik |
hopes he wasn't too dickish to the dude |
| 23:30.39 |
brlcad |
lot of
thought went in |
| 23:31.35 |
brlcad |
highly suspects that was an NNPP
conversation |
| 23:31.48 |
``Erik |
yeah, |
| 23:31.57 |
``Erik |
thus my
"here's what you do, now shut up and go do it" attitude |
| 23:32.31 |
``Erik |
(nnpp?) |
| 23:33.43 |
brlcad |
net negative
producing (person) .. conversation |
| 23:34.11 |
brlcad |
but it's
still good to say if only to have logged and reiterated |
| 23:34.20 |
``Erik |
*shrug*
everyone can bring a positive effect if steered and utilized
effectively |
| 23:34.27 |
``Erik |
there are
tasks for all levels of ability |
| 23:35.41 |
``Erik |
btw, that
other/step patch... that's totally "it compiles, ship it" :D
hopefully it's trivial enough that I didn't bung
something |
| 23:36.05 |
``Erik |
got his books today, huzzah, *read* |
| 23:37.00 |
``Erik |
"practical
common lisp" and "lisp in small pieces" |
| 23:37.35 |
brlcad |
sounds like a
hack'n'slash horror thriller |
| 23:37.55 |
brlcad |
small
pieces... bloody curlies everywhere! |
| 23:38.09 |
``Erik |
these... are
your fathers parenthesis |
| 23:38.15 |
``Erik |
from a more
civil time |
| 23:38.43 |
``Erik |
the ToC of
the small pieces book is... terrifyingly impressive |
| 23:39.19 |
``Erik |
chapter 2 has
greek in the name, chapter three is hitting
continuations |
| 23:39.36 |
``Erik |
chapter 1 is
how to write an evaluator and compiler for the language |
| 23:39.55 |
``Erik |
"macros:
their use & abuse" |
| 23:40.31 |
CIA-28 |
BRL-CAD:
03brlcad * r34462 10/brlcad/trunk/src/proc-db/vegitation.c:
cleanup |
| 23:40.35 |
``Erik |
an awfully
complete working of OO that stomps c++/java in 30 pages |
| 23:40.54 |
``Erik |
I think
there's a lot in this book, it's gonna hurt and take a while to
digest :) |
| 23:42.14 |
brlcad |
thinks ``Erik should work on a 'led' tool that binds lisp to
libged as an expression evaluator as he works his way through his
books |
| 23:42.34 |
``Erik |
supposedly,
it's the seminal text to move one from a basic 'hello world' grub
to a guru grade user |
| 23:42.38 |
brlcad |
cackles and evil laugh |
| 23:42.40 |
``Erik |
"led"? |
| 23:42.49 |
brlcad |
lisp geometry
editor, lge? :) |
| 23:42.54 |
``Erik |
heh |
| 23:43.06 |
``Erik |
cffi is
pretty clean |
| 23:43.10 |
``Erik |
so is
uffi |
| 23:43.18 |
``Erik |
both far less
painful than jni |
| 23:43.30 |
brlcad |
(opendb
'moss.g (make sph sph)) |
| 23:43.45 |
``Erik |
'cept that'd
get one flamed up one side and down the other |
| 23:43.58 |
``Erik |
(with-db
"moss.g" (make sph sph)) |
| 23:43.59 |
``Erik |
:) |
| 23:44.25 |
``Erik |
(make "sph"
'sph) perhaps? |
| 23:44.49 |
``Erik |
and
#P"moss.g" |
| 23:44.56 |
``Erik |
ack..
brain... exploding... |
| 23:44.57 |
brlcad |
probably
(make "sph" "sph"), all gets passed as literals to
libged |
| 23:45.22 |
brlcad |
could get
fancy, but really no need |
| 23:45.31 |
brlcad |
just need a
binding layer |
| 23:45.32 |
``Erik |
is it right
to refer to the data type as a string? that requires string
comparison and eliminates compile time error checking |
| 23:46.22 |
``Erik |
*shrug* these
books are pure lithp, interface would be using one of the ffi
layers, different scope |
| 23:46.25 |
brlcad |
there's not
yet any means for libged to declare expected args so that you could
do anything other than strings atm |
| 23:46.35 |
``Erik |
that's cuz
tcl sucks |
| 23:46.43 |
brlcad |
has nothing
to do with tcl |
| 23:46.44 |
``Erik |
I mean, tcl
thinks of everything a string |
| 23:46.47 |
brlcad |
talking about
libged |
| 23:47.11 |
brlcad |
they approach
it from an argc/argv command interface |
| 23:47.16 |
``Erik |
which is the
transport of mged C functions, which exist as the support cast to
the tcl layer |
| 23:47.27 |
brlcad |
which is
irrelevant :) |
| 23:47.37 |
``Erik |
the API in
mged shows its tcl heredity quite readily :) |
| 23:47.41 |
``Erik |
libged,
rather |
| 23:47.52 |
brlcad |
I don't see
it like that |
| 23:48.00 |
``Erik |
*shrug*
ok |
| 23:48.00 |
brlcad |
it's pretty
simple and clean as it is |
| 23:48.16 |
brlcad |
each one of
those commands could be trivially turned into it's own
program |
| 23:48.33 |
brlcad |
and probably
should at least for testing purposes |
| 23:48.38 |
``Erik |
ok, it shows
adaptation from a language that understand nothing other than
strings |
| 23:48.41 |
brlcad |
would be
kinda neat |
| 23:48.43 |
``Erik |
be it tcl,
shell, ... |
| 23:48.50 |
brlcad |
sure |
| 23:49.49 |
brlcad |
not that it'd
be different even outside that context, though -- it's meant to be
high-level like that so the api is untyped by design |
| 23:49.56 |
brlcad |
not just a
side effect |
| 23:50.52 |
brlcad |
could have
gone a vararg approach as well, but that was a later thought and
has a LOT of implications |
| 23:51.46 |
``Erik |
hm, is lowest
common denominator the best approach? opposed to explicit typing in
the weakly typed hooks? |
| 23:51.55 |
``Erik |
yeah, that'd
be a lot of weird custom parsing :/ lcd is probably
better |
| 23:52.07 |
brlcad |
plus
rewriting getopt parsing for 400+ commands/functions would really
suck :) |
| 23:52.09 |
``Erik |
shouldn't be
too terrible of a perforance hit |
| 23:52.24 |
brlcad |
I was
thinking of some hybrid |
| 23:52.39 |
brlcad |
as there are
some typed objects in the ged object that is passed to them
all |
| 23:52.55 |
brlcad |
for view(s)
and geometry object(s) |
| 23:53.12 |
``Erik |
but suppose
you flop the typing in your script |
| 23:53.24 |
``Erik |
instead of
handling in the "native" language format |
| 23:53.29 |
brlcad |
so if you
have a named object as an argv element, it's looked up against the
geometry object has that was passed in or looked up in the db
provided |
| 23:53.32 |
``Erik |
... O.o it'd
have to be explicitely handled? |
| 23:53.48 |
brlcad |
the commands
should handle their own type 'too' at least |
| 23:54.14 |
brlcad |
but I was
thinking of having something more like a registration interface for
each command where they could report their expected arglist
format/types |
| 23:54.18 |
``Erik |
so
(parse-integer x :junk-allowed t) all over the lisp? or whatever
ruby or python do to parse a string to an int? or float? or
symbol? |
| 23:54.42 |
``Erik |
ok, but
different languages have different types |
| 23:54.46 |
brlcad |
so if you had
a typed language, you could have your wrapper command pull the
information so it can do type checks |
| 23:54.48 |
``Erik |
how does swag
deal with that? |
| 23:55.02 |
``Erik |
wouldn't be surprised if they punted |
| 23:55.18 |
brlcad |
dunno |
| 23:55.29 |
``Erik |
this is all
brainpuke *shrug* I'm just thinkin' noisly |
| 23:55.30 |
brlcad |
packs it up |
| 23:55.32 |
``Erik |
noisily |
| 23:55.37 |
``Erik |
aight, drive
careful, dude |
| 23:55.39 |
brlcad |
code that
shtiff up |
| 23:56.06 |
brlcad |
could find a
way to bind typing up to libged -- that'd be cool |
| 23:57.21 |
``Erik |
has a few more pressing tasks first :( |
| 23:57.45 |
``Erik |
and only some
of them software development hhe |
| 00:00.32 |
brlcad |
damn |
| 00:02.37 |
``Erik |
? |
| 00:02.43 |
brlcad |
dreeves_:
finally got to cleaning up the patch and testing the extrude
enhancement .. bug it fails to render on my first attempt, will
check it more tomorrow to see if my merge wasn't clean but looks
like maybe some logic breakage (getting random behavior from 3/odd
hits to crashes to alloc failures) |
| 00:03.11 |
``Erik |
hm |
| 00:03.52 |
brlcad |
unfortunately, it's really hard to tell --
it's a bad patch with so many ws changes merged in at the same
time |
| 00:04.14 |
``Erik |
feh, ask him
to fix that and resubmit |
| 00:04.26 |
brlcad |
(for future
ref., should rarely ever change formatting/ws/style in a patch
unless *that* is the patch) |
| 00:04.30 |
``Erik |
:%s/[
\t]+$// |
| 00:04.34 |
brlcad |
that was the
fixed :) |
| 00:04.40 |
brlcad |
needs more
fixing |
| 00:05.17 |
``Erik |
both the
emacs and vi/ex fu is in the standard footer, it takes a bit of
work to screw up formatting |
| 00:05.51 |
brlcad |
indentation
was fine |
| 00:06.00 |
brlcad |
that's mostly
what the footer enforces |
| 00:06.44 |
brlcad |
spaces within
parens, one-liners vs breaking things up onto multiple lines, brace
placement, .. those were things changed (mostly for the better, but
still makes the patch unreadable) |
| 00:07.07 |
``Erik |
*shrug*
learning how to submit to a project "wrong" style is part of
maturing as a developer, learning to know what the diff is before
commit is another part |
| 00:07.13 |
``Erik |
bounce it on
him and let him learn :) |
| 00:07.19 |
brlcad |
i just
did |
| 00:07.22 |
brlcad |
:P |
| 00:08.34 |
brlcad |
mm, okay
really time now, seeing if that worked was last 'todo' for the
day |
| 00:51.29 |
``Erik |
I was wrong,
it's the command window that has the status bar, not the display
window |
| 01:22.23 |
brlcad |
ah
yeah |
| 01:22.52 |
brlcad |
it's status
is done through plot |
| 01:24.49 |
CIA-28 |
BRL-CAD:
03brlcad * r34463 10/brlcad/trunk/src/conv/Makefile.am: patch-g.1
and rpatch.1 are missing from the install and dist |
| 01:30.50 |
starseeker |
``Erik: you
got Lisp in Small Pieces???? |
| 01:30.54 |
starseeker |
is jealous |
| 01:31.23 |
``Erik |
heh,
yup |
| 01:31.29 |
``Erik |
$90 or so at
amazon |
| 01:31.55 |
``Erik |
I've talked
to peter enough that I'm sure I could get PCL signed, but getting
lisp in small pieces signed would be gnarley O.o |
| 01:32.28 |
``Erik |
(I actually
put the order in after getting fitshaced and talking to peter in
private for a bit heh) |
| 01:33.14 |
starseeker |
has PCL, but hasn't been able to face the $90 price tag of
Lisp in Small Pieces |
| 01:33.15 |
``Erik |
I made a
comment about lisp1 vs lisp2 on my "blog" and xach said that lisp
in small pieces would answer my queries |
| 01:33.52 |
``Erik |
amusingly,
the $50 book is hardback, the $90 is softback |
| 01:34.08 |
starseeker |
$50 for a
hardback???? where???? |
| 01:34.15 |
``Erik |
amazon,
pcl |
| 01:34.22 |
starseeker |
oh,
PCL |
| 01:34.44 |
``Erik |
I asked him
how I could get the most money in his pocket, he said amazon
*shrug* |
| 01:34.50 |
starseeker |
nods |
| 01:35.12 |
starseeker |
yeah, PCL is
in some ways the accumulated wisdom you would get by a LOT of
reading of the #lisp irc logs |
| 01:35.26 |
starseeker |
tends to make
it extremely useful |
| 01:35.48 |
``Erik |
it helped me
a lot reading it at gigamonkeys.net, I figured I should stand up
and help the community by 'donating' the $'s to buy it |
| 01:36.18 |
starseeker |
could you
bring in your Lisp in Small Pieces for a day? That's the closest
thing out there to a literate lisp implementation, and I've been
really curious to get a look at it |
| 01:36.39 |
``Erik |
sure |
| 01:36.44 |
``Erik |
the ToC is
jizzgasmic |
| 01:37.38 |
``Erik |
chapter 1 is
how to implement a basic interpreter |
| 01:37.43 |
brlcad |
you three
need a room for the night? :) |
| 01:38.02 |
``Erik |
chapter 2
goes into the lisp1/lisp2 debate, 3 is continuations |
| 01:38.21 |
``Erik |
brlcad: this
book is to programming what your car is to daily
drivers |
| 01:38.38 |
brlcad |
mmhmm |
| 01:38.54 |
starseeker |
brlcad:
sorry, didn't mean to wander offtopic |
| 01:39.03 |
brlcad |
heh |
| 01:39.16 |
brlcad |
smacks starseeker with the clue-by-four
jokestick |
| 01:39.21 |
starseeker |
ah
:-) |
| 01:39.32 |
starseeker |
was up at 4am, brain not functional
anymore |
| 01:39.34 |
``Erik |
I haven't dug
in, but this thing really seems to but the dragon book to
shame |
| 01:40.04 |
starseeker |
If I were to
actually start writing a literate lisp implementation, that book
would be purhase item #1 |
| 01:41.00 |
starseeker |
probably
followed by the ANSI Lisp spec in physical form, if I can get away
with the $$ (NOT cheap...) |
| 01:41.26 |
``Erik |
a lot of
recent rumblings about updating the ansi spec |
| 01:41.48 |
``Erik |
but some
greybeards are poopooing the id |
| 01:41.50 |
``Erik |
idea |
| 01:42.24 |
starseeker |
again?
where'd that pop up? |
| 01:42.43 |
``Erik |
some blogs
and irc convo, uh, does "pcos" ring a bell? |
| 01:42.54 |
starseeker |
irc
handle? |
| 01:43.47 |
``Erik |
no clue, it
was a reference to a uunet or blog post |
| 01:43.47 |
starseeker |
hmm |
| 01:43.47 |
starseeker |
will dig in a sec... |
| 01:43.55 |
``Erik |
I think I'm
remembering it right... was spoken in the same reverence as "rms"
"jkh" |
| 01:44.33 |
``Erik |
yet another
rumbling about updating the spec *shrug* |
| 01:46.57 |
starseeker |
I collected a
lot of info about spec issues some time ago: http://bzflag.bz/~starseeker/Project_FreeSpec |
| 01:47.13 |
starseeker |
was on the
alu.org wiki, but I think that's gone now |
| 01:48.14 |
starseeker |
oh, I'll bet
pcos = Pascal Costanza |
| 01:48.17 |
brlcad |
sips a recently acquired delightful
21-year |
| 01:49.27 |
``Erik |
holds his tumbler out and waits for brlcad to
share |
| 01:49.35 |
starseeker |
basically,
the objection to updating the ANSI spec is that the group who's job
it is to do that is below minimal strength to do anything, and
getting it up to strength would involve people coughing up $$ for
membership |
| 01:50.35 |
``Erik |
pascal sounds
familiar |
| 01:52.03 |
starseeker |
more
annoyingly, the copyright on the spec document itself is so
hopelessly muddled that there is no hope of an "unofficial" update
that would be invulnerable to copyright lawsuits |
| 01:52.13 |
``Erik |
if the
committee cannot get enough paying membership to make a decision,
maybe the committee should rethink the buy-in amount or their
charter |
| 01:52.25 |
starseeker |
and the
commercial vendors MIGHT have an interest in torpedoing such an
effort |
| 01:52.39 |
``Erik |
I mean, this
sounds lik ea classic "failboat" situation |
| 01:53.01 |
starseeker |
apparently
the original spec process was rather... intense, according to some
of the chatter I've heard from those who were there |
| 01:53.18 |
starseeker |
I don't think
they have the discretionary power to do that |
| 01:53.21 |
``Erik |
does the next
CL have to be ansi, even? |
| 01:53.39 |
starseeker |
not really -
sbcl is fast becoming a "de-facto" standard |
| 01:54.24 |
brlcad |
starseeker:
so join the group and help update the spec .. how much is that fee?
:) |
| 01:54.31 |
starseeker |
checks... |
| 01:54.55 |
``Erik |
just 2 years
salary? :D |
| 01:56.13 |
starseeker |
erm... the
J13 page is gone |
| 02:01.59 |
starseeker |
humph - moved
it http://www.incits.org/tc_home/Old%20TC%20Stuff/j13.htm |
| 02:04.03 |
starseeker |
ah ha
http://www.incits.org/membership/meminfo.htm |
| 02:05.11 |
starseeker |
so at least
$8k-$9.5k, unless I can get myself declared an academic
institution |
| 02:06.58 |
starseeker |
and convince
a few more people to pony up fees - I doubt any of them have
bothered to cough up now that nothing is happening |
| 02:12.11 |
brlcad |
could always
one-up it and start an ISO spec effort |
| 02:12.20 |
starseeker |
nods |
| 02:12.44 |
starseeker |
yeah, a
restart would have to be the way to go |
| 02:12.58 |
brlcad |
would
probably have even better adoption, and while more complicated and
longer process, much more likely to gain momentum |
| 02:16.20 |
starseeker |
Actually,
there IS an ISO Lisp of sorts... http://christian.jullien.free.fr/pd-islisp21.pdf.zip |
| 02:16.59 |
starseeker |
I remember
looking at this because they actually did explicitly public domain
their spec document - problem is, IIRC, it is a small subset of the
functionality of Common Lisp |
| 02:17.56 |
starseeker |
er, here
actually http://islisp.info/specification.html |
| 02:18.32 |
brlcad |
looks like
it's gone through several revisions though, could be a great place
to start |
| 02:20.49 |
starseeker |
it probably
would be - it is certainly worth starting with |
| 02:21.01 |
starseeker |
for creating
a new document |
| 02:21.27 |
starseeker |
I doubt they
want to match the functionality of common lisp though - many
consider that a rather... bloated spec |
| 02:21.31 |
brlcad |
always saw all the bickering over (relatively insignificant)
differences in the various lisp implementations to be one of its
biggest failings |
| 02:21.39 |
starseeker |
which is
rather more ironic when you consider they lack things like GUI and
threads |
| 02:21.43 |
brlcad |
smalltalk
had/has nearly the same problem |
| 02:21.57 |
starseeker |
nods |
| 02:22.16 |
starseeker |
yeah, it
tends to attract people for whom the language is an end, not a
means |
| 02:22.55 |
starseeker |
I still think
if they had successfully implemented a useful, universal GUI layer
early enough they would have become what Java is now |
| 02:23.11 |
brlcad |
like a linux
distro, it more just needs a champion that is willing to dedicate
to being a leader through sustained advocacy and significant
use |
| 02:23.33 |
madant |
runs scared at the mention of Java.. boogie
monster.. |
| 02:25.01 |
``Erik |
no |
| 02:25.23 |
``Erik |
java didn't
succeed from having a gui layer... it had an 8.5 ton marketing
guerilla behind it |
| 02:25.41 |
brlcad |
starseeker:
actually the same reason that you're stearing clear of islisp
assuming they wouldn't consider features included in common lisp
(and seeing it as a subset as being a problem in itself) means it's
probably already fairly doomed as a 'new' fork |
| 02:25.49 |
brlcad |
I meant
contributing to them to extend |
| 02:26.02 |
starseeker |
's approach would be to take the ISLISP spec and sbcl (plus
probably Sacla http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html)
and start crafting something as clean and elegent as possible from
the ground up.. |
| 02:26.22 |
brlcad |
forks almost
always fail, from scratch fails with a couple more significant
digits of certainty ;) |
| 02:26.25 |
starseeker |
brlcad: yeah,
that's true |
| 02:26.30 |
``Erik |
the common
subset of sbcl and clozure is probably a good starting
point |
| 02:27.16 |
starseeker |
brlcad: if I
were to tackle it, the idea would be to build off of something like
the VLISP research |
| 02:28.04 |
starseeker |
ftp://ftp.ccs.neu.edu/pub/people/wand/vlisp/ |
| 02:28.47 |
starseeker |
"just another
lisp" wouldn't work |
| 02:29.37 |
``Erik |
one of the
oft flaunted "advantages" of common lisp is that it's a stnadard,
not an implementation, though... |
| 02:29.57 |
starseeker |
yes - you
create a standard and an implementation together |
| 02:30.05 |
starseeker |
hence the
literate approach |
| 02:30.15 |
brlcad |
you'd
probably have better luck just trying to create an 'iso
scheme' |
| 02:30.45 |
``Erik |
python has
several implementations, but the only successful ones are very
niche oriented :( |
| 02:30.48 |
brlcad |
or extending
islisp |
| 02:31.25 |
starseeker |
brlcad: true.
The only way I would see a new effort as being better than
building off of sbcl as is though is to have a "verified"
lisp |
| 02:31.35 |
starseeker |
which would
have to be a ground up effort by definition |
| 02:31.37 |
``Erik |
other than
the primary one... which kinda says to me that doing an
implementation and standard together ... is no better than just
doing the implementation |
| 02:31.44 |
``Erik |
you surrender
the 'standard' aspect |
| 02:31.51 |
``Erik |
know what I
mean, vern? |
| 02:32.29 |
starseeker |
true - but
without at least one implementation, a spec is just
paper |
| 02:32.44 |
starseeker |
and for a
verified implementation, it would be a LOT of work to do even one
correctly |
| 02:33.19 |
``Erik |
well, C is a
standard that has implementations... java is an implementation that
claims a standard... |
| 02:33.34 |
brlcad |
starseeker:
heh, that would probably matter to .. a couple dozen people? :) ..
I just don't see that gaining momentum outside of being an academic
project |
| 02:33.48 |
``Erik |
the ebb and
flow of the two are pretty distinct |
| 02:33.54 |
starseeker |
brlcad:
agreed :-). It would matter in the mathematical field
only |
| 02:34.08 |
starseeker |
as a
foundation for a verified Computer Algebra System |
| 02:34.35 |
``Erik |
yeah, it's
too bad that computer algebra systems just don't matter :D *Duck*
*run* *flee* *hide* |
| 02:34.35 |
starseeker |
the CAS might
matter to more people, but you can't build a house with no
foundation |
| 02:34.36 |
brlcad |
so what's
"wrong" with CL? what's the actual problem being
solved? |
| 02:34.45 |
brlcad |
as that is an
ansi standard already |
| 02:35.00 |
``Erik |
modern
computing assumes things that CL doens't acknowledge |
| 02:35.03 |
starseeker |
no standard
thread support, and no standard ffi mechanism are the
biggies |
| 02:35.05 |
``Erik |
like network
programming |
| 02:35.08 |
``Erik |
threading,
etc |
| 02:35.19 |
``Erik |
it's state of
the art for '85.... |
| 02:35.53 |
brlcad |
as a
*language*, lots of languages don't have support for things like
threading and networking |
| 02:36.08 |
brlcad |
that has
little to do with the language itself |
| 02:36.38 |
brlcad |
c/c++
certainly seem to do just fine without 'em |
| 02:36.52 |
``Erik |
thinks it's dandy, but things like java, python, ruby, etc
all support new shtuff, so *shrug* |
| 02:37.29 |
``Erik |
ah, but C is
its own ffi, the bsd tcp/ip socket is pretty much de facto
standard, pthreads, ... |
| 02:37.48 |
``Erik |
it's not like
there're two dozen competing halfassed attemps for each technology
:) |
| 02:38.01 |
brlcad |
there's a big
diff between the language not supporting it and there being *no
practical way possible* to do networking and threading
too |
| 02:38.42 |
``Erik |
it's like
even basic threading has the same kinda mess that c/c++ sees with
gui widget toolkits |
| 02:39.24 |
brlcad |
c/c++ does
fine because there are plenty of libs that build up from
platform-specific intrinsics all the way up to generalized apis
(e.g. pthreads) .. so where is the 'standard lisp common library'
project? |
| 02:40.05 |
brlcad |
there were
two dozen competing halfassed attempts, and it still wasn't a (big)
problem |
| 02:41.15 |
brlcad |
how about the
dozen ways you can get two processes to talk to each other even on
modern systems .. still not standard |
| 02:42.04 |
brlcad |
sounds like
you'd probably get the most mileage if that is in fact the problem,
with developing something like APR for lisp |
| 02:42.53 |
brlcad |
or a libbu or
an stl or glib or stdc, etc |
| 02:43.54 |
brlcad |
and make it
cross-platform to CL and Scheme to boot for bigger adoption props
;) |
| 02:44.07 |
brlcad |
'platform' in
the loose sense of course :) |
| 02:44.27 |
``Erik |
*shurg*
mebbe, but when combined with a small user community and that most
people seem to have social skills in like wth de raadt or drepper,
it gets awful ugly awful fast |
| 03:01.04 |
starseeker |
raises eyebrows - Oracle will not be throwing out
SPARC |
| 03:03.11 |
``Erik |
that's not
too surprising, is it? oracle wants to build an end-to-end stack to
compete with the ibm solution... |
| 03:05.08 |
starseeker |
yes, but
including their own chips? will they really do better than using
x86? |
| 03:05.26 |
starseeker |
don't get me
wrong, anything that continues to enhance opensparc I'm all
for |
| 03:05.58 |
``Erik |
historically,
sun machines have been i/o superbeasts... and it might be more
product differentiation than technical capability
*shrug* |
| 03:09.25 |
starseeker |
dreams of the "open hardware desktop" and opensparc is the
obvious (only?) serious candidate for a CPU - continued support for
the open aspect I suppose isn't guaranteed but fingers
crossed... |
| 03:11.30 |
``Erik |
you assume
oracle will continue support of the open aspect... typically pointy
haired business sense says to lock it down as much as possible and
go proprietary |
| 03:12.12 |
starseeker |
not assume -
hope |
| 03:13.14 |
starseeker |
they have to
differentiate themselves from IBM somehow - if people study
opensparc processors in college before entering the "real world"
that may help Oracle, and probably won't hurt |
| 03:13.36 |
starseeker |
locking it
down makes sense only if they want exclusive use of it |
| 03:14.01 |
starseeker |
or license it
I suppose |
| 03:14.22 |
starseeker |
ARM seems to
have the "license our CPU IP" market sewn up... |
| 03:15.11 |
``Erik |
I d'no, I
have a feeling we'll see oracle producing sparc powered "database
appliances" |
| 03:15.26 |
starseeker |
thinks students using *BSD and Linux in college was a big
factor in those becoming more "accepted" once that generation got
into the workforce |
| 03:15.45 |
``Erik |
a few, mebbe
half a dozen different physical boxes, all to support a dedicated
database instance |
| 03:16.11 |
starseeker |
``Erik: sure.
that's what I'd expect. What's not clear is whether being
proprietary with sparc gets them anything in that
scenario |
| 03:16.40 |
``Erik |
it doesn't
have to, they just need to think it does |
| 03:17.06 |
starseeker |
If you're
coughing up the $$$$$ for Oracle in the first place, aren't you
likely to go with THE Oracle stack rather than mix and match what
would have to be unsupported 3rd party sparc hardware with Oracle
software? |
| 03:17.09 |
``Erik |
apples
openness with their architecture was incredibly short lived, I
can't see oracle thinking any different |
| 03:17.11 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 03:17.40 |
starseeker |
apple plays
in the desktop market |
| 03:17.54 |
``Erik |
and most
suits tend to think that openness == vulnerability |
| 03:17.57 |
starseeker |
most of their
users don't care if the CPU is a stick of bubble gum, as long as it
works |
| 03:18.20 |
starseeker |
``Erik: yeah,
I've seen that argument too |
| 03:18.53 |
starseeker |
debunking it
is hard work - usually because it involves getting them to listen
to unplesant truths in a way that doesn't get you fired |
| 03:19.25 |
starseeker |
but at least
some of Sun's management seems to be clued in on open source, so
perhaps Oracle will listen to them |
| 03:20.00 |
starseeker |
has seen speculation that Larry will keep OpenOffice going
just as a nose-thumbing to Bill Gates, but I
dunno... |
| 03:20.28 |
``Erik |
larry does
hate bill |
| 03:20.29 |
``Erik |
a
lot |
| 03:21.03 |
starseeker |
won't be sorry to see KOffice get serious help, in some
ways... it's a lot cleaner than the beast that is OO.org but its
import/export (all important for that set of apps) kinda
sucks |
| 03:24.33 |
starseeker |
but that
assumes serious dev resources would be committed by someone, and
the only logical candidate I can think of is probably Red
Hat... |
| 03:25.39 |
starseeker |
and they've
gone the way of Gnome... |
| 03:26.08 |
starseeker |
oh, well.
two to three years should tell the tale |
| 03:26.22 |
``Erik |
I feel like
such an outsider... vim, gnome, ... heh |
| 03:26.46 |
starseeker |
too, for that matter - vim, fluxbox +
gkrellm |
| 03:26.50 |
``Erik |
got into gnome with 0.10 |
| 03:27.06 |
starseeker |
wow |
| 03:27.08 |
``Erik |
never like
gkrellm, never really messed with fluxbox |
| 03:27.30 |
``Erik |
I think
sawfish was the X wm I grooved to the most |
| 03:27.47 |
starseeker |
migrated from blackbox - gkrellm is a lot of compact info and
functionality (mounting dvds, etc) in a very small
space |
| 03:27.53 |
``Erik |
fvwm, ice, e,
as, wm... |
| 03:28.05 |
starseeker |
tried 'em all |
| 03:28.15 |
starseeker |
the runner up
was probably windowmaker |
| 03:28.30 |
``Erik |
see, by the
time gkrellm existed, I'd learned 'nuff to be totally happy in an
xterm |
| 03:28.50 |
starseeker |
but as I got
past the point where having icons to click on to start apps was
important, windowmaker seemed less optimal than it did
initially |
| 03:28.59 |
starseeker |
``Erik: heh.
|
| 03:29.31 |
starseeker |
is a graph junkie - CPU graphs + hard disk activity graphs +
network traffic graphs |
| 03:29.36 |
poolio |
starseeker:
ever tried a tiled WM? |
| 03:29.58 |
``Erik |
I got into
sawfish with I think it was the 'crux' theme? a 2x2 workspace
setup, Xterm in top left, web in top right, email in bottom left,
"whatever else" in bottom right |
| 03:30.07 |
starseeker |
has never seen any visual presentation of systeim activity he
likes better - not even from Apple |
| 03:30.20 |
starseeker |
poolio: urm.
isn't fvwm tiled? |
| 03:31.34 |
``Erik |
got into centralized performance monitors with lightweight
daemons polling info off the local machines |
| 03:31.51 |
starseeker |
ah :-) yeah,
different situation. |
| 03:31.58 |
starseeker |
has never had more than one machine to keep track
of |
| 03:32.20 |
``Erik |
went from a few to a few hundred in '02 |
| 03:32.56 |
poolio |
starseeker:
hmm, i dont think it's considered tiled. Does it do automatic
window layout and stuff? |
| 03:33.11 |
starseeker |
oh, that kind
of tiled. no, haven't used one like that |
| 03:33.31 |
poolio |
I went from
Fluxbox -> xmonad, and love it :) |
| 03:33.51 |
starseeker |
``Erik: heh
yeah, that kind of monitoring is a whole 'nother animal |
| 03:34.12 |
starseeker |
googles xmonad - anything that can unseat fluxbox is worth a
look |
| 03:35.05 |
starseeker |
written in
Haskell?? how's the performance? |
| 03:37.14 |
starseeker |
hmm - almost
looks philosophically a sort of graphical screen |
| 03:44.42 |
starseeker |
poolio:
congrats - you've just successfully caused me to install a window
manager out of curiosity - hasn't happened in years |
| 04:02.00 |
*** join/#brlcad madant_
(n=d@117.196.136.172) |
| 04:03.25 |
starseeker |
poolio: this
is... actually pretty friggin cool |
| 04:04.19 |
starseeker |
it really
does feel in some ways a bit like what screen would be if it were a
graphical program... |
| 04:17.47 |
starseeker |
may just try this for a few days |
| 04:17.57 |
starseeker |
see what it
feels like |
| 04:18.24 |
starseeker |
may not miss
the graphical monitoring |
| 04:18.34 |
starseeker |
any favorite
tricks? |
| 04:18.42 |
poolio |
starseeker:
schweet :D It's all configurable in Haskell. I can give you my
stuff if you want, and you can hoook it up to a kinda graphical
monitor like dzen2 or xmobar |
| 04:19.10 |
poolio |
lemme take a
screenshot :P |
| 04:20.12 |
poolio |
http://poolio.org/xmonad.png |
| 04:20.47 |
poolio |
The main
thing I hated with fluxbox was that I would always have a billion
windows opened and stacked on top of each other, and then on some
desktops I'd want certain layouts for
coding/chat/etc... |
| 04:21.03 |
poolio |
It takes a
while to get used to, but now I could never see going back
:) |
| 04:22.03 |
starseeker |
can see that - I'll sometimes have five xterms open to the
same directory, only two of which have anything happening because
the other three are hidden |
| 04:22.13 |
starseeker |
then I get to
clean up the mess when everything is closed down |
| 04:22.22 |
starseeker |
yeah, that
monitor looks interesting |
| 04:22.28 |
starseeker |
an extension,
I take it? |
| 04:24.34 |
starseeker |
poolio: there
seems to always be one line at the bottom of a given terminal
window - is that deliberate to allow controll space? |
| 04:26.54 |
starseeker |
snorts - gimp looks rather ackward |
| 04:27.05 |
starseeker |
no surprises
there |
| 04:32.55 |
starseeker |
will have to check out dzen, but after
sleep |
| 04:36.00 |
poolio |
yeah so, you
can also 'float' applications, so you can have windows on top and
have the window manager ignore them, but it's not very good at
that... |
| 04:36.48 |
poolio |
err, I'm not
sure about the one line gap, I have that too but thought it was
related to the sizing of the window |
| 05:06.03 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 06:40.32 |
*** join/#brlcad pacman871
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 06:43.02 |
Ralith |
starseeker:
playing with xmonad? :D |
| 06:43.25 |
Ralith |
has it running on his two display machine |
| 06:43.28 |
Ralith |
handles it
beautifully. |
| 06:43.59 |
Ralith |
does not have any gaps on his terms |
| 06:48.20 |
*** join/#brlcad madant
(n=d@117.196.128.218) |
| 06:57.32 |
*** join/#brlcad cad21
(n=a31c4032@bz.bzflag.bz) |
| 07:15.10 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 07:35.57 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:46.15 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EC39.dip.t-dialin.net) |
| 08:54.33 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 09:01.30 |
Mike111 |
hi
all |
| 09:14.55 |
*** join/#brlcad madant
(n=d@117.196.133.163) |
| 09:29.26 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 09:38.25 |
Mike111 |
I am unable
to compile 7.14.6 on Debian Lenny, P6 |
| 09:38.31 |
Mike111 |
any
ideas? |
| 09:40.11 |
Mike111 |
here are the
final lines from make: |
| 09:40.25 |
Mike111 |
make[2]:
Entering directory
`/home/yoel/app/brl_cad/brlcad-7.14.6/src/bwish' |
| 09:40.26 |
Mike111 |
/bin/sh
../../libtool --silent --tag=CC --silent --mode=link gcc
-I../../src/other/incrTcl/itcl/generic
-I../../src/other/tcl/generic -I../../src/other/tcl/unix -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -O3
-L/usr/local/lib -pipe -fno-strict-aliasing -fno-common
-fexceptions -g -O3 -o btclsh btclsh-cmd.o btclsh-input.o
btclsh-main.o btclsh-tcl.o ../../src/libtclcad/libtclcad.la
../../src/libdm/libdm.la
../../src/other/incrTcl/libitk.la |
| 09:40.26 |
Mike111 |
../../src/other/incrTcl/libitcl.la
-L../../src/other/tk/unix -ltk8.5 -L../../src/other/tcl/unix
-ltcl8.5 -ldl -lm ../../src/libtermio/libtermio.la |
| 09:40.34 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `X24_close_existing' |
| 09:40.44 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `_X24_open_existing' |
| 09:41.01 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `X24_interface' |
| 09:41.09 |
Mike111 |
collect2: ld
returned 1 exit status |
| 09:41.19 |
Mike111 |
make[2]: ***
[btclsh] Error 1 |
| 09:42.07 |
Mike111 |
make[2]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/bwish' |
| 09:42.07 |
Mike111 |
make[1]: ***
[all-recursive] Error 1 |
| 09:42.07 |
Mike111 |
make[1]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src' |
| 09:42.07 |
Mike111 |
make: ***
[all-recursive] Error 1 |
| 09:44.38 |
*** join/#brlcad madant
(n=d@117.196.138.225) |
| 11:53.29 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 11:58.04 |
brlcad |
starseeker:
tis a good one to try out -- that wm has a lot of features that are
in IEO for the new gui |
| 11:58.15 |
brlcad |
xmonad and
wmii have a lot in common |
| 11:59.25 |
brlcad |
Mike111:
cool, so now that you're that far .. we can try some
things |
| 12:00.12 |
brlcad |
try this: cd
src/bwish && make
CFLAGS=../../src/libfb/libfb.la |
| 12:07.13 |
CIA-28 |
BRL-CAD:
03indianlarry * r34464 10/brlcad/trunk/src/conv/step/Makefile.am:
removed fedex_src dependency |
| 12:19.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 12:46.49 |
starseeker |
``Erik: here
you go, a common lisp window manager: http://www.nongnu.org/stumpwm/ |
| 12:48.30 |
``Erik |
hehehe isn't
that what sawfish is? :D |
| 12:49.08 |
``Erik |
my wm of
choice these days is the quartz/aqua dealie |
| 13:00.32 |
*** join/#brlcad madant_
(n=d@117.196.133.242) |
| 13:37.10 |
starseeker |
hrm - setting
up dzen isn't so simple, if you want to do it right |
| 13:39.17 |
starseeker |
ooo -
http://conky.sourceforge.net/ |
| 13:39.28 |
starseeker |
darn it, now
I'm gonna have to figure it out |
| 13:53.33 |
madant_ |
likes conky :) |
| 13:53.50 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 14:15.14 |
*** join/#brlcad alvaro
(n=alvaro@190.77.167.45) |
| 14:16.48 |
rincon |
does brlcad
has uninstall facilities, when you install it from the tar.gz
file? |
| 14:17.43 |
brlcad |
it fully
installs into one directory, so you can just remove that
directory |
| 14:17.53 |
brlcad |
for example:
rm -rf /usr/brlcad |
| 14:18.00 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34465 10/brlcad/trunk/src/ (libged/CMakeLists.txt
librt/CMakeLists.txt): stay in sync with Makefile.am |
| 14:18.22 |
brlcad |
wonders why the distcheck isn't catching the cmakelist
updates.. |
| 14:21.03 |
rincon |
brlcad: will
.tar.gz installation will add a menu? |
| 14:22.06 |
brlcad |
no |
| 14:22.18 |
CIA-28 |
BRL-CAD:
03brlcad * r34466 10/brlcad/trunk/Makefile.am: ah, so the
cmakecheck is running but just not halting (depending on the
version of make) when the script reports an error. make it stop so
that an out-of-sync CMakeLists.txt file will cause a distcheck
failure. |
| 14:22.21 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 14:22.35 |
brlcad |
the .tar.gz
is an install tree, you 'install' it by just copying it into
place |
| 14:22.56 |
brlcad |
e.g., it'll
unpack a usr/brlcad directory, and you copy that to
/usr/brlcad |
| 14:23.10 |
brlcad |
to uninstall,
you rm -rf /usr/brlcad |
| 14:23.20 |
*** join/#brlcad samrose
(n=samrose@99.147.180.206) |
| 14:23.21 |
brlcad |
doesn't get
much simpler |
| 14:24.01 |
rincon |
brlcad: no
need of using the ./configure or make ? |
| 14:24.20 |
brlcad |
rincon:
depends if you have a source tarball or a binary
distribution |
| 14:24.31 |
rincon |
good
question? |
| 14:24.34 |
brlcad |
that was all
presuming you had a binary |
| 14:24.44 |
rincon |
i do not know
that |
| 14:24.57 |
brlcad |
well I can't
tell you what you downloaded :) |
| 14:25.15 |
brlcad |
and if you
don't know, you have a lot bigger problems than uninstall
:) |
| 14:28.39 |
rincon |
i downloaded
this:
http://sourceforge.net/project/downloading.php?group_id=105292&filename=brlcad_7.10.4_ia32.tar.gz&a=96672383 |
| 14:29.15 |
brlcad |
well that's a
binary install |
| 14:29.19 |
brlcad |
hence the
ia32 |
| 14:29.49 |
rincon |
there was no
newer version for a 32 bit computer... |
| 14:29.56 |
brlcad |
you took some
link in order to get to that download link though, I'm sure that
told you it was a binary install too |
| 14:30.35 |
brlcad |
yeah,
binaries are only pushed out every so often for given platforms,
want people from the community to do that |
| 14:31.17 |
brlcad |
there's
enough development tasks to be messing with binary installers every
release, those installers can be prepared by anyone (even
you!) |
| 14:31.37 |
brlcad |
if you want
to help maintain the linux ia32 build, go for it |
| 14:32.38 |
rincon |
whre is the
newest version of brlcad sources? |
| 14:32.56 |
``Erik |
starseeker:
are you in today? |
| 14:36.02 |
brlcad |
~cadsvn |
| 14:36.02 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 14:37.51 |
rincon |
i copied
brlcad folder to /usr now how do i start it? |
| 14:46.20 |
starseeker |
``Erik: I'll
be in in an hour or so |
| 14:46.49 |
starseeker |
``Erik:
something urgent? |
| 14:47.09 |
``Erik |
aight, I
brought in that book if you want to thumb through it and see if
it's worth picking up a copy... I've only skimmed, but I plan on
getting deep into it this weekend O.o |
| 14:47.44 |
starseeker |
ah, cool
:-) |
| 14:48.04 |
starseeker |
that may be
the only book I've seen where a LIBRARY copy brings $99 |
| 14:48.33 |
starseeker |
rincon: type
mged |
| 15:00.37 |
rincon |
in
/usr/brlcad/bin/mged ? |
| 15:02.28 |
rincon |
command.
/usr/brlcad/bin/mged does not works |
| 15:02.58 |
rincon |
[root@alvaro-edicta-host bin]#
/usr/brlcad/bin/mged |
| 15:02.59 |
rincon |
/usr/brlcad/bin/mged: error while loading
shared libraries: libstdc++.so.5: cannot open shared object file:
No such file or directory |
| 15:02.59 |
rincon |
[root@alvaro-edicta-host bin]# |
| 15:04.16 |
*** part/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 15:24.42 |
starseeker |
starts distcheck going and heads out |
| 15:53.29 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EC39.dip.t-dialin.net) |
| 15:55.27 |
CIA-28 |
BRL-CAD:
03brlcad * r34467 10/brlcad/trunk/src/librt/primitives/mirror.c:
that 2.0 scaling factor was rather important so that the object is
translated across the mirror point far enough. fixes a bug
introduced with the r34263 elimination of the offset as a
separately tracked value. |
| 15:56.12 |
CIA-28 |
BRL-CAD:
03brlcad * r34468 10/brlcad/trunk/TODO: unbroked. last call for
commits. |
| 16:04.11 |
CIA-28 |
BRL-CAD:
03bob1961 * r34469 10/brlcad/trunk/ (5 files in 3 dirs):
Consolidate the necessity to provide a simulation of drand48() to
one place. |
| 16:05.36 |
brlcad |
~bob1961++ |
| 16:32.25 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 17:05.15 |
*** join/#brlcad madant
(n=d@117.196.137.163) |
| 17:08.37 |
``Erik |
huzzah, my
car is standing on all 4 again |
| 17:08.49 |
brlcad |
congrats |
| 17:09.08 |
``Erik |
still needs
body work and a new wheel though :( |
| 17:09.55 |
madant |
thinks 'them americans' love their cars too much
.. |
| 17:10.35 |
brlcad |
madant:
indeed! |
| 17:10.41 |
brlcad |
is sick of car commercials |
| 17:11.08 |
madant |
oh.. and
brlcad, what about the guy who bumped ur car ? any progress with
the police ? |
| 17:11.20 |
brlcad |
madant: nah,
they're not going to do anything |
| 17:11.28 |
madant |
brlcad,
except the "things just work" commercial of course .. |
| 17:11.29 |
brlcad |
will just get
fixed |
| 17:12.50 |
madant |
hmm.. my
cousin getting engaged tomorrow :P big deal in india i guess :D are
there engagement parties in US ? |
| 17:13.05 |
brlcad |
of
course |
| 17:14.03 |
madant |
hates being in family weddings etc. :P |
| 17:25.33 |
CIA-28 |
BRL-CAD:
03brlcad * r34470 10/brlcad/trunk/TODO: |
| 17:25.33 |
CIA-28 |
BRL-CAD: no
longer using the horrible old/former/obsoleted sf task tracker, so
don't |
| 17:25.33 |
CIA-28 |
BRL-CAD:
reference it. instead just point to the trackers and be more
succint on what |
| 17:25.33 |
CIA-28 |
BRL-CAD: the
purpose of this file is and how the devs use it. refer to the task
backlog |
| 17:25.33 |
CIA-28 |
BRL-CAD: as a
backlog. |
| 17:43.18 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 17:43.37 |
*** part/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 17:43.57 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34471 10/brlcad/trunk/src/adrt/
(libtienet/tienet_master.h master/master.c): announce when
listening |
| 17:44.20 |
``Erik |
opposed to
the old former obscoleted whiteboard in the hallway? :D |
| 17:45.48 |
brlcad |
no
particularly, no |
| 17:48.09 |
brlcad |
not everyone
has access to that, nor is it very effective at being persistent or
supporting a lot of items |
| 17:48.18 |
starseeker |
madant: the
cog commercial is just using the car as an excuse to do the cool
stuff ;-) |
| 17:48.41 |
``Erik |
it's very
persistant, I bet the old items are still sunbaked on it
somewhere |
| 17:48.54 |
starseeker |
and probably
still need doing :-/ |
| 17:49.41 |
brlcad |
starseeker:
actually, most of them are still active .. the only ones that were
remaining when the board was taken down are the oldest ones in the
sf tracker |
| 17:52.07 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-230-58.dclient.hispeed.ch) |
| 18:09.23 |
CIA-28 |
BRL-CAD:
03brlcad * r34472 10/brlcad/trunk/NEWS: |
| 18:09.23 |
CIA-28 |
BRL-CAD:
keith improved asc2g so that it will import even larger bots before
running out |
| 18:09.23 |
CIA-28 |
BRL-CAD: of
memory (and import faster). he made it chunk in input into
manageable sizes |
| 18:09.23 |
CIA-28 |
BRL-CAD: and
being more memory efficient. this was in response to sf feature
request |
| 18:09.23 |
CIA-28 |
BRL-CAD:
2750772 from dwaynelk (asc2g fails on large/complex
bots) |
| 18:15.19 |
CIA-28 |
BRL-CAD:
03brlcad * r34473 10/brlcad/trunk/NEWS: note that bob improved the
interactive editing support in archer adding support for
mouse-based editing of arb8's torii and ellipsoids |
| 18:16.01 |
brlcad |
I think
that's everything -- should check yourself to make sure your
user-visible changes are in there |
| 18:16.34 |
brlcad |
vaguely recalls a tire bug being fixed? |
| 18:16.52 |
brlcad |
dunno about
user-visible for adrt, didn't seem in commits |
| 18:17.10 |
``Erik |
nah, pieces
are still not public |
| 18:17.33 |
``Erik |
soon...
mwahaha |
| 18:21.55 |
brlcad |
updating TODO
-- anyone have something they think will be done by next
month? |
| 18:22.09 |
brlcad |
ideally at
least one item from anyone doing anything |
| 18:22.40 |
``Erik |
will get his car back, get his door fixed, and pick his nose.
:D |
| 18:23.04 |
brlcad |
yeah..
okay |
| 18:23.08 |
brlcad |
that's not
helpful |
| 18:24.13 |
``Erik |
d'no how
helpful "do more adrt stuff" would be O.o |
| 18:24.26 |
brlcad |
how about
that pnts as points to the dm mod? |
| 18:25.06 |
``Erik |
if I lose the
will and steam with adrt work, I may go back to that as a
distraction :/ |
| 18:25.07 |
brlcad |
well it is
helpful if you can specify 'stuff' |
| 18:25.58 |
``Erik |
would have to think on that *shrug* |
| 18:26.16 |
brlcad |
even if it's
minor, something measurable .. precursor to a much more involved
planning day coming up anyways |
| 18:26.45 |
``Erik |
regaining the
2 lost isst modes? O.o |
| 18:27.07 |
brlcad |
what's one of
them? |
| 18:27.18 |
``Erik |
cut and
shot |
| 18:27.29 |
brlcad |
what's
probably the easier of the two? :) |
| 18:27.38 |
``Erik |
d'no, but cut
is first :) |
| 18:28.12 |
brlcad |
what's
shot? |
| 18:28.24 |
brlcad |
things on the
shotline? |
| 18:28.37 |
brlcad |
assume cut is
the split-view cutting plane |
| 18:31.24 |
CIA-28 |
BRL-CAD:
03brlcad * r34474 10/brlcad/trunk/TODO: |
| 18:31.24 |
CIA-28 |
BRL-CAD: stub
out a preliminary guess on what's achievable by the end of this
release |
| 18:31.24 |
CIA-28 |
BRL-CAD:
iteration (3 weeks remaining) with coverage across at least 5 devs.
pnt |
| 18:31.24 |
CIA-28 |
BRL-CAD:
improvements, step-g progress, archer updates, functab refactoring,
and adrt |
| 18:31.24 |
CIA-28 |
BRL-CAD:
views. |
| 18:31.32 |
``Erik |
hrm, the
split view one is cut, yes, ... mebbe the oter one was
flos? |
| 18:32.35 |
``Erik |
*shrug* |
| 18:32.57 |
CIA-28 |
BRL-CAD:
03brlcad * r34475 10/brlcad/trunk/TODO: break up the adrt to-do's,
remove 'cleanup' as it's too vague |
| 18:38.09 |
CIA-28 |
BRL-CAD:
03brlcad * r34476 10/brlcad/trunk/TODO: |
| 18:38.09 |
CIA-28 |
BRL-CAD: the
polygonal NMG -> ON BREP is actually more important than old
bspline/nurbs |
| 18:38.09 |
CIA-28 |
BRL-CAD: NMG
-> ON BREP so just stub out the goal for both. 'not suck' is
too |
| 18:38.09 |
CIA-28 |
BRL-CAD:
nondescript for the tables command (don't remember what that meant,
and I wrote |
| 18:38.09 |
CIA-28 |
BRL-CAD: it).
erik exposed nmg_fix_normals so remove from list. |
| 18:42.13 |
``Erik |
0 |
| 18:42.14 |
``Erik |
|
| 18:43.09 |
CIA-28 |
BRL-CAD:
03brlcad * r34477 10/brlcad/trunk/TODO: |
| 18:43.10 |
CIA-28 |
BRL-CAD: had
it in mind for years now to record a matrix above all primitives
(akin to |
| 18:43.10 |
CIA-28 |
BRL-CAD:
putting each primitive into their own comb) so that all primitives
will retain a |
| 18:43.10 |
CIA-28 |
BRL-CAD:
local coordinate system by default (where their V stays at 0,0,0).
this will |
| 18:43.10 |
CIA-28 |
BRL-CAD: help
primitives like the torus support non-uniform scaling without
screwing with |
| 18:43.12 |
CIA-28 |
BRL-CAD: the
implicit form of a torus. |
| 18:44.17 |
CIA-28 |
BRL-CAD:
03brlcad * r34478 10/brlcad/trunk/TODO: screw it, c++ is requisite
given the BREP integration, GS and GE plans, and the new
modeler. |
| 18:46.15 |
CIA-28 |
BRL-CAD:
03brlcad * r34479 10/brlcad/trunk/TODO: the tops behaviors were
merged with the old form formally deprecated. in 7.14.4 |
| 18:48.42 |
CIA-28 |
BRL-CAD:
03brlcad * r34480 10/brlcad/trunk/TODO: expand on CSG optimize task
(probably should be multiple, but good enough for now) |
| 18:49.17 |
CIA-28 |
BRL-CAD:
03brlcad * r34481 10/brlcad/trunk/NEWS: looks like today will be
release day.. awaiting a few more distchecks to
complete. |
| 18:51.22 |
brlcad |
wonders if someone could go kick xon/xoff |
| 18:57.08 |
``Erik |
they should
be rebooting now |
| 19:03.13 |
``Erik |
aight,
thye'reup |
| 19:04.04 |
CIA-28 |
BRL-CAD:
03starseeker * r34482 10/brlcad/trunk/NEWS: Add NEWS note on tire
tread fix. |
| 19:06.27 |
starseeker |
brlcad: what
do you think - are we ready on the backend to have a go at
implementing exec for search? |
| 19:09.13 |
starseeker |
is currently trying to internalize what is needed to build
the "bounding box tree" needed for the NURBS raytracing
algorithm |
| 19:09.15 |
brlcad |
starseeker:
it's close, there's still a few api problems that should be sorted
out in the ged structure and to invoke a pass-through
callback |
| 19:09.34 |
brlcad |
that sounds
like a more pressing task actually :) |
| 19:09.59 |
brlcad |
nurbs
trumpeth all this summer as we pull into the final
stretch |
| 19:11.25 |
starseeker |
heh - well,
you asked for things that might get done within the
month... |
| 19:11.34 |
starseeker |
doesn't know about that one yet |
| 19:11.44 |
brlcad |
implementing
the bb routine for nurbs sounds like a good goal :) |
| 19:12.01 |
starseeker |
is also trying to figure out how that relates to our own
ideas about sub-bounding-boxes for e.g. pipe |
| 19:12.01 |
brlcad |
succint in
itself |
| 19:12.06 |
starseeker |
k |
| 19:12.21 |
starseeker |
pulls up TODO, unless it's frozen now? |
| 19:15.41 |
brlcad |
todo is never
really frozen |
| 19:15.58 |
brlcad |
only risky
code changes |
| 19:17.14 |
brlcad |
starseeker:
ws 'type' in that news commit |
| 19:17.19 |
brlcad |
er,
typo |
| 19:17.32 |
starseeker |
oops
sorry |
| 19:17.44 |
brlcad |
and is that
for specific use? |
| 19:17.48 |
brlcad |
thin tires,
thick ones? |
| 19:18.45 |
CIA-28 |
BRL-CAD:
03starseeker * r34483 10/brlcad/trunk/ (NEWS TODO): Fix NEWS ws
typo, add TODO item specifically identifying need for a NURBS
'bounding box tree' building routine |
| 19:18.57 |
starseeker |
um... I THINK
it showed up thicker treaded tires |
| 19:20.04 |
starseeker |
or, "wider"
actually |
| 19:20.47 |
CIA-28 |
BRL-CAD:
03starseeker * r34484 10/brlcad/trunk/NEWS: Tweak tire NEWS item
some more |
| 19:24.39 |
*** join/#brlcad madant_
(n=d@117.196.128.49) |
| 19:43.23 |
starseeker |
brlcad:
distcheck passes on linux x86_64 |
| 19:43.32 |
brlcad |
cool |
| 19:57.58 |
starseeker |
and Mac
OSX |
| 19:58.08 |
CIA-28 |
BRL-CAD:
03bob1961 * r34485 10/brlcad/trunk/ (12 files in 6 dirs): Added
ged_pscale() for scaling primitives.' attributes. |
| 19:58.39 |
starseeker |
hmm.
|
| 19:58.42 |
starseeker |
rebuilds |
| 20:01.02 |
brlcad |
huh, well
that was certainly a good refactoring |
| 20:01.27 |
brlcad |
eliminated a
couple hundred lines |
| 20:06.38 |
CIA-28 |
BRL-CAD:
03starseeker * r34486 10/brlcad/trunk/src/libged/CMakeLists.txt:
Add pscale.c to CMakeLists.txt |
| 20:13.24 |
brlcad |
starseeker:
did distcheck catch that? |
| 20:13.40 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:13.56 |
starseeker |
didn't hault,
but I saw your script report it |
| 20:14.03 |
brlcad |
damn |
| 20:14.42 |
brlcad |
that should
have worked |
| 20:27.33 |
*** join/#brlcad andax
(n=andax__@d213-102-41-113.cust.tele2.ch) |
| 20:30.38 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.236.57) |
| 20:39.35 |
starseeker |
ok, distcheck
passed again on x86_64 linux and Mac |
| 21:28.18 |
brlcad |
thanks |
| 22:16.54 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 22:53.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 23:06.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 23:27.09 |
starseeker |
and on gentoo
32 bit linux, fwiw |
| 01:21.37 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 02:18.25 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 02:58.55 |
*** join/#brlcad pacman87
(n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 06:56.37 |
starseeker |
``Erik:
sounds like that guy might have wanted digitizer: http://digitizer.sourceforge.net/ |
| 07:19.17 |
Mike111 |
. |
| 07:19.56 |
Mike111 |
. |
| 07:20.00 |
*** part/#brlcad Mike111
(n=mike@cadil21.kaist.ac.kr) |
| 07:20.06 |
*** join/#brlcad Mike111
(n=mike@cadil21.kaist.ac.kr) |
| 07:20.56 |
Mike111 |
hi
all |
| 07:20.56 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 07:22.44 |
Mike111 |
can anyone
help with building on Debian Lenny? |
| 07:40.42 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EA9B.dip.t-dialin.net) |
| 08:02.25 |
*** join/#brlcad dreeves__
(n=dreeves@64.178.177.71) |
| 08:11.58 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 08:47.48 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:53.19 |
*** join/#brlcad docelic
(n=docelic@78.134.195.15) |
| 10:19.31 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 10:35.36 |
Mike111 |
. |
| 10:38.19 |
Mike111 |
Please note I
was not logging the channel on the weekend so apologies if someone
had replied to my question, but please reply again. Thanks -
Mike. |
| 10:38.23 |
hippieindamakin8 |
Mike111,
hey |
| 10:38.32 |
Mike111 |
hi
hippie |
| 10:38.43 |
hippieindamakin8 |
Mike111, what
seems to be problem out there ? |
| 10:39.16 |
Mike111 |
unable to
compile 7.14.6 on Debian Lenny |
| 10:39.53 |
hippieindamakin8 |
ohh whats the
error ? |
| 10:40.18 |
Mike111 |
make[2]:
Entering directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/bwish' |
| 10:40.18 |
Mike111 |
/bin/sh
../../libtool --silent --tag=CC --silent --mode=link gcc
-I../../src/other/incrTcl/itcl/generic
-I../../src/other/tcl/generic -I../../src/other/tcl/unix -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -O3
-L/usr/local/lib -pipe -fno-strict-aliasing -fno-common
-fexceptions -g -O3 -o btclsh btclsh-cmd.o btclsh-input.o
btclsh-main.o btclsh-tcl.o ../../src/libtclcad/libtclcad.la
../../src/libdm/libdm.la
../../src/other/incrTcl/libitk.la |
| 10:40.18 |
Mike111 |
../../src/other/incrTcl/libitcl.la
-L../../src/other/tk/unix -ltk8.5 -L../../src/other/tcl/unix
-ltcl8.5 -ldl -lm ../../src/libtermio/libtermio.la |
| 10:40.18 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `X24_close_existing' |
| 10:40.20 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `_X24_open_existing' |
| 10:40.22 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `X24_interface' |
| 10:40.24 |
Mike111 |
collect2: ld
returned 1 exit status |
| 10:40.28 |
Mike111 |
make[2]: ***
[btclsh] Error 1 |
| 10:40.31 |
Mike111 |
make[2]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/bwish' |
| 10:40.33 |
Mike111 |
make[1]: ***
[all-recursive] Error 1 |
| 10:40.34 |
Mike111 |
make[1]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src' |
| 10:40.36 |
Mike111 |
make: ***
[all-recursive] Error 1 |
| 10:40.47 |
Mike111 |
these are the
last few lines from `make' just before it exists with an
error |
| 10:40.48 |
hippieindamakin8 |
Mike111, can
u dpaste it if u have more |
| 10:41.14 |
Mike111 |
what is
dpaste? |
| 11:09.42 |
hippieindamakin8 |
tcl
libs |
| 11:16.45 |
Mike111 |
brclad: I've
tried building 7.14.6 again. First removed configure, config.status
and config.cache* and ran autogen.sh, followed by ./configure and
naje |
| 11:16.49 |
Mike111 |
sorry
make |
| 11:17.07 |
Mike111 |
here is the
last few lines from make where it reports the error: |
| 11:17.38 |
Mike111 |
Making all in
brlman |
| 11:17.39 |
Mike111 |
make[2]:
Entering directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/brlman' |
| 11:17.39 |
Mike111 |
make[2]:
Nothing to be done for `all'. |
| 11:17.39 |
Mike111 |
make[2]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/brlman' |
| 11:17.39 |
Mike111 |
Making all in
burst |
| 11:17.39 |
Mike111 |
make[2]:
Entering directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/burst' |
| 11:17.41 |
Mike111 |
make[2]:
Nothing to be done for `all'. |
| 11:17.45 |
Mike111 |
make[2]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/burst' |
| 11:17.47 |
Mike111 |
Making all in
bwish |
| 11:17.49 |
Mike111 |
make[2]:
Entering directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/bwish' |
| 11:17.52 |
Mike111 |
/bin/sh
../../libtool --silent --tag=CC --silent --mode=link gcc
-I../../src/other/incrTcl/itcl/generic
-I../../src/other/tcl/generic -I../../src/other/tcl/unix -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -L/usr/local/lib
-pipe -fno-strict-aliasing -fno-common -fexceptions -g -o btclsh
btclsh-cmd.o btclsh-input.o btclsh-main.o btclsh-tcl.o
../../src/libtclcad/libtclcad.la ../../src/libdm/libdm.la
../../src/other/incrTcl/libitk.la ../../sr |
| 11:17.56 |
Mike111 |
c/other/incrTcl/libitcl.la
-L../../src/other/tk/unix -ltk8.5 -L../../src/other/tcl/unix
-ltcl8.5 -ldl -lm ../../src/libtermio/libtermio.la |
| 11:17.59 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `X24_close_existing' |
| 11:18.01 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `_X24_open_existing' |
| 11:18.03 |
Mike111 |
../../src/libtclcad/.libs/libtclcad.so:
undefined reference to `X24_interface' |
| 11:18.06 |
Mike111 |
collect2: ld
returned 1 exit status |
| 11:18.07 |
Mike111 |
make[2]: ***
[btclsh] Error 1 |
| 11:18.09 |
Mike111 |
make[2]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src/bwish' |
| 11:18.11 |
Mike111 |
make[1]: ***
[all-recursive] Error 1 |
| 11:18.15 |
Mike111 |
make[1]:
Leaving directory
`/home/mike/app/brl_cad/brlcad-7.14.6/src' |
| 11:18.17 |
Mike111 |
make: ***
[all-recursive] Error 1 |
| 11:18.19 |
Mike111 |
I'm logging
the channel now so you if you reply I'll your response when I
return. Thanks for your help. |
| 11:19.32 |
d-lo |
looks like
the linker can't find your X24 libs... |
| 11:21.05 |
Mike111 |
hi d-lo:
thanks for the prompt reply. I need to go now. if you have any
ideas please message me or the channel and I'll catch up on these
when I come up in the morning. Cheers |
| 11:22.37 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EA9B.dip.t-dialin.net) |
| 11:24.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 12:22.57 |
starseeker |
Mike111: if
you need to paste large content like that use http://pastebin.bzflag.bz |
| 13:18.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 13:27.44 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34487
10/rt^3/trunk/src/coreInterface/Ellipsoid.cpp: ws changes
only |
| 13:45.45 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34488 10/rt^3/trunk/ (11 files in 2 dirs): operator
new may throw a std::bad_alloc exception |
| 13:47.55 |
``Erik |
grar. |
| 13:48.06 |
``Erik |
interesting
to see the guts of the front of my house |
| 13:48.12 |
``Erik |
nothing
surprising, just... different |
| 13:49.23 |
d-lo |
quick... run
some cat5e/6 |
| 13:49.36 |
``Erik |
heh, up the
front? screw that |
| 13:50.06 |
``Erik |
I hate a
small bundle down in the back of the lowest floor, everythign else
is 802.11b/g atm |
| 13:50.17 |
``Erik |
unfortunately, that lone b turns every g
into a b |
| 13:51.00 |
d-lo |
whats the
offender? A nic? Bridge? Access point? |
| 13:51.15 |
``Erik |
I believe an
old ibook and the wap |
| 13:51.52 |
``Erik |
I might
decomission/hock the old laptop, but that'd leave the wap, which is
7 yrs old |
| 13:52.00 |
``Erik |
$50 for 7 yrs
isn't too bad |
| 13:52.28 |
``Erik |
Iwantmydamncarback. they're saying
thursday-ish |
| 13:52.35 |
``Erik |
fucking 2
months |
| 13:53.04 |
``Erik |
this fucking
rental floats, has no road feel, has no clutch, is all skunked up
from smokers, ... sucks |
| 13:53.14 |
d-lo |
ouch.
Prognosis on repairs? She'll be just like new or ? |
| 13:53.17 |
``Erik |
and the
additional culpability it brings, effin' a |
| 13:53.34 |
``Erik |
yeah, they're
worry points are tread depth if I get a new tire... |
| 13:53.40 |
``Erik |
half the car
is being repainted though |
| 13:53.52 |
``Erik |
their |
| 13:54.13 |
d-lo |
same color
right? =D |
| 13:54.23 |
``Erik |
I'll grill
them heavier after the new rim/tire is fitted and they put it all
together and align it |
| 13:54.25 |
``Erik |
yeah |
| 13:54.51 |
``Erik |
as fun as the
attention the laguna seca car brought, I've decided I don't want to
stand out that much |
| 13:54.57 |
``Erik |
less huffing
of ricer nos fumes |
| 13:55.18 |
``Erik |
I don't WANT
to race your little ford assprobe with "the kit", I just want to
get home and watch the simpsons, fucktard |
| 13:55.28 |
d-lo |
tee
hee. |
| 13:55.50 |
``Erik |
I think
brlcad gets off on it, I got tired of it |
| 13:56.02 |
d-lo |
Nothing as
awesome as a Neon with a killer muffler, huge spoiler and two
difference colored doors 'cause they can't afford the paint job
yet. :) |
| 13:56.21 |
``Erik |
hehhee |
| 13:56.26 |
``Erik |
the wing,
man |
| 13:56.28 |
``Erik |
it's all
about the wing |
| 13:56.52 |
d-lo |
yeah, add
downforce in the rear on a front wheel drive == pure
genious. |
| 13:56.53 |
``Erik |
yeah, the car
is front drive, so that downforce is technically air friction plus
increased rear tire friction, but... uhhhhh, it's all about the
wing |
| 13:57.22 |
``Erik |
I made you
look at the 'k-car' site, right? |
| 13:57.31 |
d-lo |
negative
ghost rider |
| 13:57.37 |
``Erik |
dude took an
80's dodge K frame car, uh |
| 13:57.43 |
``Erik |
has it
running 8 second quarters |
| 13:57.49 |
``Erik |
and it looks
like a grannymobile |
| 13:58.18 |
``Erik |
guys also
smoking camaros and mustangs with an 80's minivan |
| 13:58.25 |
``Erik |
http://www.thedodgegarage.com/
check out the reliant |
| 13:58.41 |
``Erik |
10, not 8
:( |
| 13:58.48 |
``Erik |
mebbe it was
one of his beasts that took to the 8's |
| 13:59.28 |
``Erik |
given that
any street car under 100k is in the 13's, a 10s car is
zomfg |
| 14:01.37 |
d-lo |
ahahahahhahaha. Checking out the bag of
ice bungeed to the intercooler in the suped up minivan.
AHAHAHAHAAHAHA |
| 14:02.08 |
``Erik |
:D |
| 14:02.17 |
``Erik |
dude is all
go and no show |
| 14:02.27 |
d-lo |
thats so
ghetto its awesome.... |
| 14:02.54 |
``Erik |
I'd sit next
to that dude before any ricer |
| 14:03.19 |
``Erik |
<-- fan of
the sleeper |
| 14:04.17 |
d-lo |
I saw a
reference to Cecil county.. they in MD? |
| 14:04.24 |
``Erik |
no, he's way
up north |
| 14:04.31 |
``Erik |
but he drives
down for the cecil county track |
| 14:04.44 |
``Erik |
boggled me at
first |
| 14:07.20 |
``Erik |
(way up like
cecil involves a hotel way up) |
| 14:08.30 |
``Erik |
loves the tech of it all |
| 14:17.26 |
d-lo |
ah ha! I
forgot its Free Redbox Movie day. Sweet. |
| 14:52.47 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EA9B.dip.t-dialin.net) |
| 15:14.26 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:18.10 |
CIA-28 |
BRL-CAD:
03bob1961 * r34489 10/brlcad/trunk/src/libged/ (ged_private.h
pscale.c scale_ell.c scale_tor.c): Included rtgeom.h in
ged_private.h, modified the signatures of ged_scale_ell() and
ged_scale_tor() (i.e. removed matp_t parameter). Also fixed pscale
(it wasn't working when matrices were found along the
path). |
| 15:45.48 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 15:46.00 |
d-lo |
Now there's a
shock. My highschool band teacher just won Mrs Arizona....
http://www.azcentral.com/news/articles/2009/04/24/20090424gl-dvbeauty0424-ON.html |
| 15:50.15 |
hippieindamakin8 |
d-lo, woah u
had hot teachers :) |
| 15:50.45 |
d-lo |
I always knew
she was pretty, nice and an awesome music teacher... but damn...
who knew... |
| 15:53.52 |
hippieindamakin8 |
when my
school had to do budget cuts the music teacher was one of the ones
fired and there was no music class in high school |
| 15:54.27 |
d-lo |
thats a
growing trend. Sad really. |
| 15:57.21 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 16:01.29 |
d-lo |
In fact, I
would say that music education had a significantly bigger impact on
shaping my life than sports did. |
| 16:33.16 |
brlcad |
is humorously reminded of office space with this pic:
http://farm4.static.flickr.com/3620/3434141027_6899d20fb7_b.jpg |
| 17:09.37 |
brlcad |
wow.. what a
tetris performance .. http://www.youtube.com/watch?v=jwC544Z37qo |
| 17:14.55 |
CIA-28 |
BRL-CAD:
03bob1961 * r34490
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Modify
ArcherCore::loadMenu to select snode. |
| 17:19.50 |
d-lo |
brlcad:
simply amazing. Although I do wonder howmany life opportunities
were missed out while he was practicing... heh. I'd imagine a few
of those opportunities had nice racks too ;) |
| 17:46.26 |
``Erik |
nice, dlo,
how can you avoid the "hot for teacher" cameo? |
| 18:23.36 |
d-lo |
who's
avoiding it? :) |
| 18:50.44 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-243-42.dclient.hispeed.ch) |
| 19:24.21 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 19:25.59 |
CIA-28 |
BRL-CAD:
03bob1961 * r34491 10/brlcad/trunk/src/ (5 files in 2 dirs): Add
code for editing EHY's in libged and Archer. |
| 19:54.33 |
CIA-28 |
BRL-CAD:
03brlcad * r34492 10/brlcad/trunk/configure.ac: need to force
compilation of step off if there are no parsers/lexers found since
there is a parser in libexpress. avoids compile-time failure on
minimal systems. |
| 20:03.35 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177679958.dsl.bell.ca) |
| 20:18.00 |
CIA-28 |
BRL-CAD:
03brlcad * r34493 10/brlcad/trunk/configure.ac: all -build options
should default to 'auto', including step. if the user specifically
requested step and parser/lexer aren't present, abort. |
| 20:18.21 |
``Erik |
*sigh* |
| 20:18.34 |
``Erik |
I hate when
that file is changed. |
| 20:19.11 |
brlcad |
cackles |
| 20:26.11 |
brlcad |
woot, PTC
sales fell 44% compared to Q2FY08 |
| 20:26.36 |
``Erik |
ptc? |
| 20:26.41 |
brlcad |
pro/e |
| 20:26.45 |
``Erik |
ah |
| 20:26.56 |
``Erik |
so... uh,
who's next? |
| 20:27.18 |
``Erik |
I think this
dude is listening to ... rush limbaugh? |
| 20:27.24 |
brlcad |
they're no
longer one of the "top 5" that are billion+ CAD
companies |
| 20:27.48 |
brlcad |
will drop
(just) under a billion this year if projection holds |
| 20:28.14 |
``Erik |
y'know, I'm
an awfully soft dude... but, uh, when the dude came to fix my
window and wanted to convert me... no sale... and now, the guy
fixing my front door... rush limbaugh? really? |
| 20:28.40 |
``Erik |
I'm gonna
effin' bitchslap ericE for this |
| 20:28.46 |
brlcad |
probably just
thought you had a purdy mouth |
| 20:33.38 |
``Erik |
yeh, I do
sure have a purdy mouth |
| 20:44.19 |
starseeker |
brlcad: so
who are the top five now? |
| 20:44.58 |
brlcad |
well they're
still probably #5 |
| 20:45.44 |
brlcad |
but the top
five were all billion+ so was considered a
'club'/mafia/elitism |
| 20:45.54 |
starseeker |
ah |
| 20:50.03 |
brlcad |
autodesk,
dassault, siemens, and ptc |
| 20:50.18 |
brlcad |
it was four,
not five .. unless I'm forgetting someone |
| 20:50.36 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 20:52.06 |
brlcad |
2.4b, 1.2b,
1.1b, and now .9b respectively if projection holds .. rough
estimates |
| 20:53.46 |
``Erik |
images us gov't has at least a b to its
name |
| 20:53.54 |
``Erik |
for a wee
bit, anyways |
| 20:54.25 |
brlcad |
eh, try
3.6t |
| 20:55.45 |
brlcad |
good grief
this rebuild is taking fooooreeeverrr |
| 20:58.20 |
CIA-28 |
BRL-CAD:
03brlcad * r34494 10/brlcad/trunk/src/librt/primitives/mirror.c:
odd ws snuckage |
| 20:59.40 |
brlcad |
anyone else
have a clean debian/ubuntu box handy? this one I'm using is really
slow -- trying to make sure Mike111's bug is fixed for this source
release |
| 21:01.22 |
CIA-28 |
BRL-CAD:
03brlcad * r34495 10/brlcad/trunk/NEWS: bob sneaks in support for
ehy interactive editing in archer along with that which was added
for arb8, tor, and ell. |
| 21:13.15 |
CIA-28 |
BRL-CAD:
03brlcad * r34496 10/brlcad/trunk/HACKING: update the version
before updating the changelog so the change is recorded |
| 21:17.03 |
CIA-28 |
BRL-CAD:
03brlcad * r34497 10/brlcad/trunk/ (5 files in 5 dirs): final
release steps, bump patch revision for the 7.14.8
release |
| 21:26.40 |
CIA-28 |
BRL-CAD:
03brlcad * r34498 10/brlcad/trunk/ChangeLog: changes since the last
release, through 2009-04-03 |
| 21:37.29 |
CIA-28 |
BRL-CAD:
03brlcad * r34499 10/brlcad/trunk/HACKING: collapse the distcheck
step with the build step to reduce the number of release steps back
down to 15. making the minimum regression tests
copypasteable. |
| 21:56.55 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EA9B.dip.t-dialin.net) |
| 22:02.27 |
starseeker |
hmm - gqa has
problems with grid specification |
| 22:03.03 |
starseeker |
g_qa -Ao
-g1-0.1 ktank.g tank |
| 22:03.54 |
CIA-28 |
BRL-CAD:
03brlcad * r34500 10/brlcad/trunk/configure.ac: bc_ vars are the
user's specification of the build. the build_brlcad_ vars are our
evaluated results of whether to build or not. config subdirs needs
to use the latter else dist problems enwrath |
| 22:04.05 |
starseeker |
I think the
issue is it's not getting to any of its termination cases, but I'm
not sure why yet |
| 22:09.19 |
brlcad |
g_qa needs to
identify itself and report what it's going to do before it does
it |
| 22:09.29 |
brlcad |
the output
now is pretty inpenetrable |
| 22:09.57 |
starseeker |
nods |
| 22:10.14 |
brlcad |
-v is mildly
useless |
| 22:10.36 |
brlcad |
the overlap
list is the only part that looks to be semiclean |
| 22:11.30 |
brlcad |
it terminated
with -g 1.0mm .. but took like 10x the default |
| 22:11.43 |
brlcad |
I suspect
making it .1 means it'll be 10-20 min |
| 22:13.58 |
brlcad |
actually, not
quite that bad: real 2m58.831s |
| 22:14.11 |
brlcad |
that was
with: g_qa -v -Ao -g 1.0mm-0.1mm ktank.g tank |
| 22:14.25 |
starseeker |
ah, so it did
eventually terminate |
| 22:14.45 |
brlcad |
seems about
right .. just kicked up the number of rays really fast |
| 22:14.53 |
starseeker |
ok,
nevermind |
| 22:14.54 |
brlcad |
remember
they're ^3 |
| 22:15.06 |
starseeker |
feedback
would be nice... |
| 22:15.29 |
brlcad |
so 10x on the
grid is .. 100x more per view, 300x overall |
| 22:17.27 |
starseeker |
yeah, I see
it now |
| 22:17.54 |
brlcad |
update TODO,
couple tasks |
| 22:18.10 |
brlcad |
feedback at a
minimum |
| 22:18.38 |
starseeker |
abort ability
would also be nice |
| 22:18.40 |
brlcad |
identification header to let you know it's
working |
| 22:18.55 |
brlcad |
hm? |
| 22:18.58 |
brlcad |
ctrl-c ?
:) |
| 22:19.01 |
starseeker |
yep |
| 22:19.01 |
brlcad |
oh you mean
in mged |
| 22:22.04 |
CIA-28 |
BRL-CAD:
03starseeker * r34501 10/brlcad/trunk/TODO: Add note on g_qa
usability improvements needed in TODO |
| 23:10.51 |
*** join/#brlcad alvaro1
(n=alvaro@190.77.167.45) |
| 23:24.26 |
alvaro1 |
configure:
error: *** compiler cannot create working executables, check
config.log *** |
| 23:24.43 |
brlcad |
did you check
config.log? :) |
| 23:25.44 |
alvaro1 |
can i pastre
it here? |
| 23:27.46 |
alvaro1 |
[root@alvaro-edicta-host brlcad-7.14.6]#
./configure --enable-optimized > a |
| 23:28.00 |
alvaro1 |
configure:
WARNING: X11 support is enabled but the Xi library was not
found. |
| 23:28.00 |
alvaro1 |
configure:
WARNING: This will likely result in a build failure. |
| 23:28.00 |
alvaro1 |
configure:
WARNING: See config.log for details why (look for this
comment) |
| 23:28.00 |
alvaro1 |
configure:
WARNING: The floating point implementation does not seem to be IEEE
754 |
| 23:28.00 |
alvaro1 |
configure:
WARNING: compliant. The behavior of htond and htonf may be
incorrect. |
| 23:28.01 |
alvaro1 |
configure:
error: *** compiler cannot create working executables, check
config.log *** |
| 23:28.03 |
alvaro1 |
[root@alvaro-edicta-host
brlcad-7.14.6]# |
| 23:29.04 |
brlcad |
eh |
| 23:29.18 |
brlcad |
you
misunderstand something |
| 23:29.30 |
brlcad |
that is not
the config.log |
| 23:29.44 |
brlcad |
you
redirected most of the configure output to a file named
'a' |
| 23:29.51 |
brlcad |
so you only
see what went to stderr |
| 23:30.19 |
brlcad |
which is all
hopefully informative but still irrelevant to towards "check
config.log" |
| 23:35.22 |
alvaro1 |
i am triying
to paste config.log but it is too big |
| 23:49.02 |
*** join/#brlcad alvaro1
(n=alvaro@190.77.167.45) |
| 23:49.50 |
alvaro1 |
brlcad can
you give you email ? |
| 00:11.43 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 00:16.56 |
brlcad |
alvaro1: read
the config.log file, scan to the end |
| 00:17.23 |
alvaro1 |
i am not that
good in programming |
| 00:17.30 |
brlcad |
it's not a
mysterious file, you just have to read what it says :) |
| 00:17.37 |
brlcad |
it has
nothing to do with programming |
| 00:17.44 |
brlcad |
it's just a
text log file |
| 00:18.22 |
alvaro1 |
configure:28165: gcc -o conftest
-I/usr/local/include -L/usr/local/lib conftest.c -lm
>&5 |
| 00:18.22 |
alvaro1 |
conftest.c:37: warning: conflicting types
for built-in function 'cos' |
| 00:18.33 |
brlcad |
keep
going |
| 00:19.14 |
alvaro1 |
configure:28116:
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} |
| 00:19.14 |
alvaro1 |
configure:28118: WARNING: X11 support is
enabled but the Xi library was not found. |
| 00:19.14 |
alvaro1 |
configure:28120: WARNING: This will likely
result in a build failure. |
| 00:19.14 |
alvaro1 |
configure:28122: WARNING: See config.log
for details why (look for this comment) |
| 00:19.14 |
alvaro1 |
configure:28124:
{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{ |
| 00:19.14 |
alvaro1 |
configure:28135: checking for cos in
-lm |
| 00:19.16 |
alvaro1 |
configure:28165: gcc -o conftest
-I/usr/local/include -L/usr/local/lib conftest.c -lm
>&5 |
| 00:19.18 |
alvaro1 |
conftest.c:37: warning: conflicting types
for built-in function 'cos' |
| 00:19.20 |
alvaro1 |
configure:28171: $? = 0 |
| 00:19.22 |
alvaro1 |
configure:28175: test -z |
| 00:19.24 |
alvaro1 |
<PROTECTED> |
| 00:19.26 |
alvaro1 |
configure:28178: $? = 0 |
| 00:19.27 |
brlcad |
stop pasting
:) |
| 00:19.28 |
alvaro1 |
configure:28181: test -s
conftest |
| 00:19.30 |
alvaro1 |
configure:28184: $? = 0 |
| 00:19.32 |
alvaro1 |
configure:28197: result: yes |
| 00:19.34 |
alvaro1 |
configure:28206: checking for regcomp in
-lc |
| 00:19.36 |
alvaro1 |
configure:28236: gcc -o conftest
-I/usr/local/include -L/usr/local/lib conftest.c -lc
>&5 |
| 00:19.38 |
alvaro1 |
configure:28242: $? = 0 |
| 00:19.40 |
alvaro1 |
configure:28246: test -z |
| 00:19.48 |
brlcad |
the file has
thousands of lines for tons of tests |
| 00:20.03 |
brlcad |
you need to
find where it stopped, it'll say why |
| 00:20.11 |
brlcad |
so scan down
towards the end |
| 00:20.29 |
brlcad |
look for
"compiler cannot create working executables" |
| 00:21.17 |
brlcad |
those other
WARNING lines are important too, but they're certainly not the ones
halting the build |
| 00:22.24 |
alvaro1 |
i found it
http://fpaste.org/paste/11705 |
| 00:22.41 |
brlcad |
great |
| 00:22.48 |
brlcad |
now look at
the lines that preceed it |
| 00:22.54 |
brlcad |
it ran some
test and it failed |
| 00:23.20 |
brlcad |
might be
immediately before, might be several dozen before |
| 00:25.35 |
alvaro1 |
http://fpaste.org/paste/11706 |
| 00:25.40 |
alvaro1 |
must be
here |
| 00:26.32 |
brlcad |
and you are
correct |
| 00:26.37 |
brlcad |
so what's the
problem? |
| 00:27.13 |
alvaro1 |
the heaader
is wrong |
| 00:27.17 |
brlcad |
nope |
| 00:27.32 |
alvaro1 |
/*
confdefs.h. */ |
| 00:27.36 |
brlcad |
what does
line 1 say it's doing |
| 00:28.54 |
alvaro1 |
checking g++
compiler and flags for sanity |
| 00:29.05 |
brlcad |
right |
| 00:29.14 |
brlcad |
so it's going
to make sure the compiler works |
| 00:29.33 |
brlcad |
line 2 is the
command it runs to test if the compiler works |
| 00:29.44 |
brlcad |
then what
happens? |
| 00:31.01 |
alvaro1 |
so the
problem is the compiler |
| 00:31.13 |
alvaro1 |
or
headers |
| 00:31.51 |
brlcad |
don't jump ..
what happened after it tried to run that command it showed on line
2 ? |
| 00:32.27 |
brlcad |
read line
3 |
| 00:33.44 |
alvaro1 |
i must
install g++ |
| 00:34.13 |
brlcad |
:) |
| 00:34.45 |
brlcad |
"compiler
cannot create working executables" .. because you don't even have
the compiler |
| 00:35.50 |
alvaro1 |
arm-gp2x-linux-gcc-c++.i386 : Cross
Compiling GNU G++ targeted at arm-gp2x-linux |
| 00:35.50 |
alvaro1 |
avr-gcc-c++.i386 : Cross Compiling GNU GCC
targeted at avr |
| 00:36.00 |
alvaro1 |
can i use any
of those? |
| 00:36.46 |
brlcad |
depends on
your hardware -- do you have arm or avr? |
| 00:37.00 |
alvaro1 |
do not have a
clue ... |
| 00:37.04 |
brlcad |
heh |
| 00:37.13 |
brlcad |
well then it
sounds like it's a no probably |
| 00:37.23 |
brlcad |
what's your
os? |
| 00:37.30 |
alvaro1 |
f10 |
| 00:37.42 |
alvaro1 |
fedora
10 |
| 00:37.44 |
brlcad |
how do you
normally install software? |
| 00:37.49 |
alvaro1 |
yum |
| 00:38.21 |
brlcad |
try just: yum
install gcc-c++ |
| 00:38.51 |
brlcad |
or yum
install g++ |
| 00:39.11 |
alvaro1 |
<PROTECTED> |
| 00:39.15 |
brlcad |
but I suspect
just yum install gcc-c++ |
| 00:39.19 |
brlcad |
that looks
like it |
| 00:39.50 |
alvaro1 |
brlcad:
thanks |
| 00:39.56 |
brlcad |
no
problem |
| 00:40.39 |
alvaro1 |
if it runs
can i upload it to the home page of brlcad |
| 00:41.03 |
brlcad |
only if you
go through all the steps to make a proper yum package
:) |
| 00:41.35 |
brlcad |
and/or a
proper rpm |
| 00:41.57 |
brlcad |
there are
dozens if not hundreds of tutorials on how to make an
rpm |
| 00:42.09 |
brlcad |
quick web
search is a wealth of knowledge |
| 00:42.21 |
brlcad |
you could
certainly become the rpm maintainer, though :) |
| 00:43.15 |
alvaro1 |
i thought
only as an "copy to /usr" version |
| 00:44.55 |
brlcad |
mm, that's
possible too, though you'll have to build with specific configure
options and create some symlinks |
| 00:45.07 |
brlcad |
and build
from a tagged version |
| 00:45.31 |
alvaro1 |
<PROTECTED> |
| 00:45.56 |
brlcad |
actually it's
not |
| 00:46.05 |
brlcad |
just sounds
easier because there are tutorials |
| 00:46.19 |
brlcad |
you'd still
have to go through the same steps, specific configure
options |
| 00:46.27 |
brlcad |
part of
release management |
| 00:46.44 |
brlcad |
so the
settings on distributions are consistent |
| 00:47.31 |
brlcad |
``Erik: heh,
now *this* build is going to take a long time.... on a Linksys
NSLU2 |
| 00:48.11 |
brlcad |
about 2/3rds
the speed of an old SGI O2, 32MB memory .. been compiling all day
and it's still in the middle of openNURBS :) |
| 00:50.14 |
alvaro1 |
http://fpaste.org/paste/11708
it seems to be built |
| 00:51.00 |
alvaro1 |
brlcad:
http://fpaste.org/paste/11708 |
| 00:53.02 |
brlcad |
curious, why
do you redirect output to 'a'? |
| 00:54.28 |
brlcad |
the most
important warning there is the first one, that the Xi library was
not found -- you need to install that |
| 00:54.39 |
alvaro1 |
http://fpaste.org/paste/11709
here is a |
| 00:54.50 |
brlcad |
I don't want
'a' |
| 00:54.56 |
brlcad |
I want to
know why you redirect to 'a' |
| 00:55.55 |
alvaro1 |
because the
terminal has not enough buffer capabilities, and in order to keep
it all i redirect it to a |
| 00:56.18 |
brlcad |
okay, fair
enough |
| 00:57.03 |
brlcad |
if you want
to capture all output together, you can do this: ./configure
--enable-optimized > a 2>&1 |
| 00:57.23 |
brlcad |
that
"2>&1" will put the stderr with the stdout like you see when
the command is run without a redirect |
| 00:57.27 |
brlcad |
that can be
done for any command |
| 00:57.35 |
brlcad |
just so you
know |
| 00:57.53 |
brlcad |
so install
libXi and you should hopefully be good to go |
| 00:58.04 |
brlcad |
(rerun
configure to verify that the warning goes away) |
| 00:58.49 |
alvaro1 |
i already
tiped "make" |
| 00:59.04 |
alvaro1 |
it is running
"make" |
| 00:59.43 |
alvaro1 |
is libXi
important ? |
| 01:03.01 |
Mike111 |
hi
brlcad |
| 01:03.47 |
Mike111 |
I've looked
at the channel log. any luck tracing the problem I've
got? |
| 01:07.12 |
*** join/#brlcad Mike111
(n=mike@cadil21.kaist.ac.kr) |
| 01:12.07 |
*** join/#brlcad Mike111
(n=mike@cadil21.kaist.ac.kr) |
| 01:12.30 |
brlcad |
Mike111: did
you try that 'make CFLAGS...' I suggested a couple days
ago? |
| 01:12.44 |
brlcad |
alvaro1: what
did the warning say? |
| 01:12.55 |
brlcad |
(don't paste
it, read it) :) |
| 01:13.14 |
Mike111 |
brlcad: you
mean the one with the burst? |
| 01:13.31 |
brlcad |
Mike111: I
don't recall exactly which directory |
| 01:13.56 |
brlcad |
but the
suggestion was to add a cflag that might have resolved the link
failure |
| 01:14.14 |
Mike111 |
in your email
you mentioned: "cd src/ |
| 01:14.15 |
Mike111 |
burst
&& make CFLAGS=../libfb/libfb.la" and see if that makes
any |
| 01:14.15 |
Mike111 |
difference. |
| 01:14.27 |
Mike111 |
I've tried
this but am getting the same error |
| 01:14.40 |
brlcad |
exact same
error? |
| 01:14.47 |
brlcad |
or just
failed in some other way? |
| 01:14.54 |
alvaro1 |
brcad: This
will likely result in a build failure. |
| 01:15.05 |
Mike111 |
same error:
those X_24 references |
| 01:15.10 |
brlcad |
alvaro1: so
you tell me, does libXi sound important? :) |
| 01:15.31 |
brlcad |
it's "likely"
that it's important, but feel free to ignore the warning
:) |
| 01:15.43 |
alvaro1 |
brlcad: i
must stop "make" |
| 01:15.52 |
brlcad |
alvaro1: or
wait for it to fail |
| 01:15.55 |
brlcad |
then install
it |
| 01:15.58 |
brlcad |
then run make
again |
| 01:16.08 |
brlcad |
Mike111:
okay, hm |
| 01:16.19 |
brlcad |
Mike111: it's
failing for you in src/burst, yes? |
| 01:16.37 |
alvaro1 |
brlcad: is
not a problem to interrupt make? |
| 01:16.51 |
brlcad |
alvaro1: no,
you could do that too -- doesn't matter |
| 01:17.35 |
Mike111 |
brlcad: I'll
paste the lines again |
| 01:17.47 |
brlcad |
Mike111: heh,
you're doing the same as alvaro1 :) |
| 01:18.01 |
brlcad |
the lines
say, you really don't need to paste them :) |
| 01:18.24 |
brlcad |
have to read
them .. just seems foreign at first but it's actually english
;) |
| 01:18.48 |
Mike111 |
Then how will
you know where exactly it fails? |
| 01:18.56 |
Mike111 |
if I don't
paste the error outputs? |
| 01:19.31 |
brlcad |
because it
halts where it fails, you read it, you tell me |
| 01:20.57 |
Mike111 |
the last
directory make entered was brlcad-7.14.6/src/bwish |
| 01:21.22 |
brlcad |
you're
welcome to *also* pastebin the output ... just really shouldn't get
the (bad/common) habit of pasting when something unexpected happens
_instead_ of reading the output ;) |
| 01:21.39 |
brlcad |
okay, good to
know |
| 01:21.50 |
Mike111 |
it then run
gcc with lots of files and options and then reports
./../src/libtclcad/.libs/libtclcad.so: undefined reference to
`X24_close_existing' |
| 01:22.01 |
brlcad |
nods |
| 01:22.33 |
brlcad |
I'm 70% sure
that's the fault of the debian devs .. messing with
libtool |
| 01:23.01 |
brlcad |
which leaves
a lot of room for uncertainty and still doesn't fix anything for
you :) |
| 01:23.32 |
brlcad |
so the issue
per that message is libtclcad |
| 01:24.01 |
brlcad |
that X24_...
symbol should be coming from our libfb library but for whatever
reason libtool isn't linking it in |
| 01:24.31 |
brlcad |
more than
likely it's just an ordering issue, but one fix should be to
verify/force libfb to link into libtclcad |
| 01:24.34 |
brlcad |
so try
this: |
| 01:24.39 |
brlcad |
cd
src/libtclcad |
| 01:25.16 |
Mike111 |
ok I'm
there |
| 01:27.10 |
brlcad |
what does
this report: grep TCLCAD Makefile | grep libfb | wc |
| 01:28.03 |
Mike111 |
1 218
3233 |
| 01:28.17 |
brlcad |
okay, and
this: grep dependency libtclcad.la |
| 01:28.37 |
brlcad |
should be a
long line |
| 01:29.21 |
Mike111 |
dependency_libs=' -L/usr/local/lib
-L/home/mike/app/brl_cad/brlcad-7.14.6/src/other/tcl/unix
/home/mike/app/brl_cad/brlcad-7.14.6/src/libdm/libdm.la
-L/home/mike/app/brl_cad/brlcad-7.14.6/src/other/tk/unix
-L/usr/include/xorg/lib
/home/mike/app/brl_cad/brlcad-7.14.6/src/libged/libged.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/libwdb/libwdb.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/librt/librt.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/libbn/libbn. |
| 01:29.21 |
Mike111 |
la
/home/mike/app/brl_cad/brlcad-7.14.6/src/other/libregex/libregex.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/libsysv/libsysv.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/other/openNURBS/libopenNURBS.la
-lstdc++ -lX11 -lXext -lXi
/home/mike/app/brl_cad/brlcad-7.14.6/src/libfb/libfb.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/libbu/libbu.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/other/libpng/libpng.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/other/l |
| 01:29.23 |
Mike111 |
ibz/libz.la
-lc -lpthread
/home/mike/app/brl_cad/brlcad-7.14.6/src/libpkg/libpkg.la -lnsl
/home/mike/app/brl_cad/brlcad-7.14.6/src/other/incrTcl/libitk.la
/home/mike/app/brl_cad/brlcad-7.14.6/src/other/incrTcl/libitcl.la
-ltk8.5 -ltclstub8.5 -ltcl8.5 -ldl -lm' |
| 01:30.09 |
brlcad |
hm, okay that
looks right |
| 01:30.39 |
Mike111 |
the
config.log file lists several errors: |
| 01:30.46 |
Mike111 |
conftest.c:12:28: error: ac_nonexistent.h:
No such file or directory |
| 01:30.55 |
brlcad |
that's
normal |
| 01:30.58 |
Mike111 |
configure:
failed program was: |
| 01:30.59 |
Mike111 |
| /*
confdefs.h. */ |
| 01:31.02 |
brlcad |
it runs
thousands of tests |
| 01:31.09 |
Mike111 |
ok |
| 01:31.12 |
brlcad |
some/many are
supposed to fail, some aren't |
| 01:31.31 |
brlcad |
it basically
probes your environment to figure out what it looks
like |
| 01:32.10 |
brlcad |
"does this
look like cygwin? .. no. does the compiler work? .. yes. ..
etc" |
| 01:32.29 |
brlcad |
hundreds/thousands of tests |
| 01:32.31 |
Mike111 |
It also lists
that will build the tcl, tk and itcl/itk libraries although I've
installed tcl8.4 and tcl8.5, tk8.4 and tk8.5 and itcl |
| 01:32.43 |
brlcad |
separate
issue, one at a time :) |
| 01:32.51 |
brlcad |
probably
because of itcl |
| 01:33.03 |
brlcad |
you can't
build itcl without also building tcl/tk |
| 01:33.17 |
brlcad |
as itcl uses
(uninstalled) private tcl/tk sources |
| 01:33.29 |
Mike111 |
these are the
packages I've installed: |
| 01:33.30 |
Mike111 |
autoconf |
| 01:33.30 |
Mike111 |
bison |
| 01:33.30 |
Mike111 |
byacc |
| 01:33.31 |
Mike111 |
flex |
| 01:33.31 |
Mike111 |
fop |
| 01:33.31 |
Mike111 |
freeglut3-dev |
| 01:33.33 |
Mike111 |
itcl3-dev |
| 01:33.35 |
Mike111 |
jamvm |
| 01:33.37 |
Mike111 |
libgl1-mesa-dev |
| 01:33.39 |
Mike111 |
libglu1-mesa-dev |
| 01:33.41 |
Mike111 |
libncurses5-dev |
| 01:33.43 |
Mike111 |
libpng-12 |
| 01:33.45 |
Mike111 |
libstdc++5 |
| 01:33.47 |
Mike111 |
libtnt-dev |
| 01:33.49 |
Mike111 |
libtool |
| 01:33.51 |
Mike111 |
libx11-dev |
| 01:33.55 |
Mike111 |
libxi-dev |
| 01:33.57 |
Mike111 |
libxslt1-dev |
| 01:33.59 |
Mike111 |
libxt-dev |
| 01:34.01 |
brlcad |
way too much
information |
| 01:34.01 |
Mike111 |
linux-headers-2.6.26-1-all-i386 |
| 01:34.03 |
Mike111 |
tcl8.4-dev |
| 01:34.05 |
Mike111 |
tcl8.5 |
| 01:34.07 |
Mike111 |
tcl8.5-dev |
| 01:34.09 |
Mike111 |
tk8.4-dev |
| 01:34.11 |
Mike111 |
tk8.5 |
| 01:34.13 |
Mike111 |
tk8.5-dev |
| 01:34.15 |
Mike111 |
xorg-dev |
| 01:34.17 |
Mike111 |
xserver-xorg-core |
| 01:34.35 |
brlcad |
and way too
much for a channel paste |
| 01:35.36 |
brlcad |
so next step
since everything looks right is to figure out what the *exact*
compile line looks like |
| 01:35.54 |
brlcad |
<PROTECTED> |
| 01:36.08 |
Mike111 |
ok |
| 01:36.09 |
brlcad |
run make and
make sure it fails with the symbol error |
| 01:36.31 |
Mike111 |
looks like
the same error |
| 01:37.02 |
Mike111 |
symbol error
you mean the undefined reference (like
`X24_close_existing')? |
| 01:37.29 |
brlcad |
yes |
| 01:37.43 |
brlcad |
make
LIBTOOL=../../libtool |
| 01:37.47 |
brlcad |
pastebin that
output |
| 01:38.47 |
Mike111 |
how do I
pastebin? |
| 01:39.31 |
brlcad |
pastebin.bzflag.bz |
| 01:39.57 |
brlcad |
~pastebin |
| 01:39.58 |
ibot |
[~pastebin] A
"pastebin" is a web-based service where you can paste anything over
3 lines without flooding the channel. Here are links to a few :
http://www.pastebin.com ,
http://pastebin.ca , http://channels.debian.net/paste
, http://paste.lisp.org ,
http://www.rafb.net/paste |
| 01:41.10 |
Mike111 |
so I just
paste the output into that empty box and you can then view it by
clicking my nickname on the left side pane? |
| 01:41.26 |
brlcad |
you put it
into the box, then provide the URL |
| 01:43.38 |
Mike111 |
http://pastebin.bzflag.bz/m5509c52f |
| 01:44.36 |
brlcad |
that was what
command? |
| 01:46.37 |
Mike111 |
make
LIBTOOL=../../libtool |
| 01:46.52 |
Mike111 |
in
src/bwish |
| 01:47.12 |
brlcad |
okay,
bah |
| 01:47.24 |
brlcad |
make
LIBTOOL=../../libtool LIBTOOLFLAGS= |
| 01:49.05 |
Mike111 |
http://pastebin.bzflag.bz/m7d54a75f |
| 01:50.44 |
CIA-28 |
BRL-CAD:
03brlcad * r34502 10/brlcad/branches/STABLE/ (495 files in 140
dirs): merge trunk to STABLE from r34151 through HEAD r34501 for
release 7.14.8 |
| 01:52.10 |
brlcad |
Mike111: nm
/home/mike/app/brl_cad/brlcad-7.14.6/src/libfb/.libs/libfb.so |
grep X24_open_existing |
| 01:53.45 |
Mike111 |
returns
nothing |
| 01:54.08 |
brlcad |
o.O
really |
| 01:54.14 |
CIA-28 |
BRL-CAD:
03brlcad * r34503 10/brlcad/tags/rel-7-14-8/: tagging release
7.14.8, now with more flavor. |
| 01:55.30 |
starseeker |
more taste,
less filling! |
| 01:55.33 |
brlcad |
pastebin
output: grep IF_ ../libfb/Makefile |
| 01:56.43 |
Mike111 |
http://pastebin.bzflag.bz/m364ef031 |
| 01:57.17 |
brlcad |
finds it exceptionally humorous that it's taking about 30
minutes per file to compile on this thing |
| 01:58.05 |
starseeker |
you're
building it on a router? |
| 01:58.25 |
brlcad |
pretty
much |
| 01:58.38 |
*** part/#brlcad alvaro1
(n=alvaro@190.77.167.45) |
| 01:58.40 |
brlcad |
Mike111: grep
open_existing ../libfb/*.c |
| 02:00.02 |
Mike111 |
http://pastebin.bzflag.bz/m63fe0734 |
| 02:00.11 |
brlcad |
starseeker:
on one of these: http://en.wikipedia.org/wiki/NSLU2 |
| 02:00.37 |
brlcad |
running
debian, was going to try to reproduce Mike111's problem.. but it'll
be a couple days before it gets to his error :) |
| 02:01.19 |
brlcad |
Mike111: huh,
that's really pretty odd |
| 02:01.29 |
brlcad |
the files are
all right, the routine is there, but it's not in the
lib |
| 02:01.32 |
brlcad |
cd
../libfb |
| 02:01.35 |
brlcad |
rm
libfb.la |
| 02:01.38 |
brlcad |
make |
| 02:01.41 |
brlcad |
pastebin the
output |
| 02:02.39 |
Mike111 |
http://pastebin.bzflag.bz/m3bfa7b63 |
| 02:03.49 |
brlcad |
grep -A8
'^libfb_la_CFLAGS' Makefile |
| 02:04.49 |
brlcad |
can just
paste it here |
| 02:05.20 |
Mike111 |
libfb_la_CFLAGS = \ |
| 02:05.20 |
Mike111 |
-DIF_REMOTE
\ |
| 02:05.20 |
Mike111 |
-DIF_AB
\ |
| 02:05.21 |
Mike111 |
${GL_CFLAGS}
\ |
| 02:05.21 |
Mike111 |
$(IF_X_CFLAGS) \ |
| 02:05.21 |
Mike111 |
$(IF_TK_CFLAGS) \ |
| 02:05.23 |
Mike111 |
$(IF_OGL_CFLAGS) \ |
| 02:05.25 |
Mike111 |
$(IF_WGL_CFLAGS) \ |
| 02:05.27 |
Mike111 |
${TCL_CPPFLAGS} |
| 02:05.34 |
brlcad |
cat
libfb_la-if_X24.lo |
| 02:06.17 |
Mike111 |
http://pastebin.bzflag.bz/m34ac6a09 |
| 02:06.29 |
brlcad |
nm
.libs/libfb_la-if_X24.o | grep open_existing |
| 02:07.14 |
Mike111 |
nothing |
| 02:08.30 |
brlcad |
pastebin your
if_X24.c file |
| 02:12.21 |
starseeker |
tries to figure out why all of a sudden the -S option on coil
is giving invalid pipes... |
| 02:12.23 |
brlcad |
going to have
to pick up on this later, out of time now |
| 02:12.41 |
brlcad |
starseeker:
dunno but .. BUGS! :) |
| 02:14.02 |
Mike111 |
http://pastebin.bzflag.bz/m27d9c9f2 |
| 02:14.02 |
brlcad |
is intently being more attentive about documenting issues and
ideas as they come up |
| 02:14.24 |
starseeker |
ok, looks
like I probably won't squash it tonight |
| 02:14.43 |
starseeker |
is more disturbed that it suddenly broke without (apparently)
anything in coil changing... |
| 02:15.21 |
brlcad |
Mike111:
yeah, that file looks fine .. so this is basically off in truely
bizzaro land without some more interactive time |
| 02:15.47 |
Mike111 |
that's good
news ;) |
| 02:15.49 |
brlcad |
Mike111: best
solution is to await the results of my build here to see if I can
at least reproduce it |
| 02:16.07 |
CIA-28 |
BRL-CAD:
03starseeker * r34504 10/brlcad/trunk/BUGS: Note apparent breakage
of coil -S option. |
| 02:16.19 |
brlcad |
try: rm
libfb_la-if_X24.lo && make && nm
.libs/libfb_la-if_X24.o | grep open_existing |
| 02:16.58 |
brlcad |
pastebin the
whole output |
| 02:18.26 |
Mike111 |
http://pastebin.bzflag.bz/m1f9caa5a |
| 02:18.47 |
brlcad |
! |
| 02:19.00 |
brlcad |
wtf .. okay,
so the first time through, they weren't there and now they
are.... |
| 02:19.29 |
brlcad |
looks like
this is not a clean build, like you first compiled through with
different configure options or make options |
| 02:19.36 |
brlcad |
either way,
it's there now |
| 02:19.39 |
brlcad |
cd
../bwish |
| 02:19.39 |
brlcad |
make |
| 02:19.43 |
brlcad |
should
link |
| 02:20.08 |
Mike111 |
no errors now
: |
| 02:20.10 |
Mike111 |
:) |
| 02:20.20 |
brlcad |
slaps Mike111 around a bit for unclean build
:) |
| 02:20.27 |
brlcad |
cd
../.. |
| 02:20.27 |
brlcad |
make |
| 02:20.33 |
brlcad |
see if it
complete |
| 02:21.03 |
brlcad |
if it does
not: make distclean && sh autogen.sh &&
./configure --enable-all && make |
| 02:21.12 |
Mike111 |
no sure what
you mean by an unclean build, but yesterday I've removed configure,
configure.stat and vonfigure.cache, ran autogen.sh and then
configure and make |
| 02:21.31 |
brlcad |
that sounds
probably unclean |
| 02:21.55 |
starseeker |
's first rule in situation like this - clean checkout
:-) |
| 02:21.57 |
brlcad |
you had
object files in there for a different build
configuration |
| 02:23.05 |
Mike111 |
wouldn't
removing configure, config.{stat,cache} and running autogen.sh sort
of start from scratch? |
| 02:23.32 |
brlcad |
nope |
| 02:24.16 |
brlcad |
"make
distclean" is "close" to starting from scratch but even that isn't
exactly the same |
| 02:24.23 |
Mike111 |
well, that
was an advice I got on the channel, but nevermind. |
| 02:24.40 |
brlcad |
it many
situations, that'll work, but it's just not the same and in this
case was the problem |
| 02:25.16 |
brlcad |
suspect you
ran configure earlier and you didn't have libX11 or libXi
? |
| 02:25.26 |
Mike111 |
is there
something more extensive than make distclean, that is make it an
absolute `clean' build? |
| 02:25.30 |
brlcad |
or at least
it didn't detect it |
| 02:25.57 |
brlcad |
sure, check
out the sources from the repository or unpack them from a source
distribution tarball |
| 02:26.05 |
brlcad |
that's about
as "clean" as it gets ;) |
| 02:26.24 |
brlcad |
from
repository is the cleanest |
| 02:26.38 |
brlcad |
from a source
tarball, after running make distclean |
| 02:26.51 |
brlcad |
depends where
in the build pipeline you want to end up |
| 02:27.10 |
Mike111 |
so basically
I need to remove the currently installed directories, download the
source again and install it? |
| 02:27.15 |
brlcad |
patiently waits for "sh autogen.sh && ./configure
--enable-all --enable-optimized --prefix=/usr/brlcad/rel-7.14.8
&& make distcheck && make && make install
&& make benchmark && make test" to
complete |
| 02:27.36 |
Mike111 |
I refer to
using a repository |
| 02:27.38 |
brlcad |
before
posting up a new source tarball |
| 02:27.53 |
brlcad |
then yeah,
just checking out again is the best way to go |
| 02:28.18 |
Mike111 |
ok, I'll try
building it now |
| 02:28.28 |
brlcad |
please do
post up a follow-up to your thread posting if it works so others
are aware |
| 02:28.42 |
brlcad |
if not, try
the distclean rebuild |
| 02:29.20 |
CIA-28 |
BRL-CAD:
03Grandia 07http://brlcad.org *
r1439 10/wiki/Main_Page: /* Third-party Projects */ |
| 02:29.29 |
Mike111 |
just
confirming, so now I need to run ./configure followed by
make? |
| 02:29.44 |
CIA-28 |
BRL-CAD:
03Grandia 07http://brlcad.org *
r1440 10/wiki/Main_Page: /* Third-party Projects */ |
| 02:31.16 |
starseeker |
Mike111:
yes |
| 02:32.26 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Grandia]] with an expiry
time of infinite (account creation disabled): Spamming links to
external sites |
| 02:33.34 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r1441
10/wiki/Main_Page: Reverted edits by
[[Special:Contributions/Grandia|Grandia]] ([[User
talk:Grandia|Talk]]); changed back to last version by
[[User:Sean|Sean]] |
| 02:36.14 |
Mike111 |
how long does
make run for? |
| 02:36.28 |
starseeker |
depends on
system |
| 02:36.42 |
starseeker |
20, 30
minutes or more sometimes |
| 02:37.20 |
Mike111 |
in the
meantime, maybe you could help me with another issue |
| 02:39.03 |
brlcad |
that's 20-30
minutes per file if you're compiling on an XScale ;) |
| 02:39.33 |
Mike111 |
how do I
create a solid which is made of smoothly connected cross sections,
where the cross sections are defined by polynomials (generated in
another application) |
| 02:39.34 |
brlcad |
fastest I've
seen is 2 minutes, average on modern desktop is around 10-20
min |
| 02:40.23 |
brlcad |
sounds like a
great question for starseeker |
| 02:40.31 |
brlcad |
alas, I'm
spent and gotta run, ttyl |
| 02:40.46 |
Mike111 |
tnx for your
help brlcad :) |
| 02:40.48 |
brlcad |
depending on
the polynomial, entirely doable |
| 02:40.52 |
brlcad |
sure,
np |
| 02:41.01 |
Mike111 |
I'll post a
followup on the make |
| 02:41.20 |
brlcad |
thx |
| 02:41.34 |
starseeker |
Mike111:
primitives in BRL-CAD are described as implicits |
| 02:41.47 |
starseeker |
so your
polynomials have to be expressible as a surface of a
primitive |
| 02:42.32 |
Mike111 |
the
polynomials define only a 2-D cross section (one poly. for upper
surface and one for lower surface) |
| 02:42.33 |
starseeker |
then you
constrain the intersection points of multiple primitives at the
intersection points to be "smooth" via forcing derivatives to be
the same at intersection points |
| 02:42.58 |
starseeker |
so... you
want to extrude the 2-D cross sections? |
| 02:43.33 |
Mike111 |
extrude, as I
understand it, is simply copying the same cross section along an
axis |
| 02:43.43 |
starseeker |
right |
| 02:43.55 |
Mike111 |
I want the
surface to smoothly blend from one cross section to
another |
| 02:43.55 |
starseeker |
the more
general case is sweep, but that's not a primitive we have
yet |
| 02:44.30 |
starseeker |
so you have a
series of 2D sketches, and you want a "smooth" surface that
connects one sketch to the next? |
| 02:44.37 |
Mike111 |
right |
| 02:44.55 |
starseeker |
erm. sounds
like an application of fillets or some such. |
| 02:45.17 |
starseeker |
I don't think
we have anything that can do what you're thinking right
now |
| 02:45.44 |
Mike111 |
:( |
| 02:46.02 |
starseeker |
is there an
example graphic online somewhere of a similar shape? |
| 02:46.08 |
starseeker |
easier to
tell from that |
| 02:47.07 |
Mike111 |
say for
example a wing, which has one cross section (airfoil) at the tip
and another airfoil at the root (where it connects to the
hull) |
| 02:47.10 |
starseeker |
wonders WHY the compile on the XScale but is sorta afraid to
ask... |
| 02:47.24 |
starseeker |
nods |
| 02:48.47 |
starseeker |
in that case,
I would use rpc or rhc primitives for sections of the leading edge
of the wing |
| 02:48.58 |
starseeker |
an epa or ehy
primitive to define the tip |
| 02:49.30 |
starseeker |
and more
shallow rpc primitives to define the middle surface of the wing,
aligning them with the edge primitives |
| 02:49.52 |
starseeker |
to ensure
smoothness, you'd have to do some derivative
constraints |
| 02:50.35 |
starseeker |
actually, for
a wing edge you might do better with a tec primitive, come to think
of it |
| 02:51.02 |
starseeker |
sees if he can make a quick mockup example |
| 02:59.46 |
starseeker |
Mike111: OK,
take a look at this: http://bzflag.bz/~starseeker/wingshape.png |
| 03:00.02 |
starseeker |
it's
obviously not a true wing, but it does suggest how you might get
started |
| 03:00.10 |
starseeker |
that uses two
primitives |
| 03:01.12 |
starseeker |
for a true
airfoil shape you'd want something more flexible (like NURBS, which
we're working on) but you could actually get a fairly decent
looking wing out of combinations of those primitives |
| 03:02.10 |
Mike111 |
are the cross
section ellipses? |
| 03:02.15 |
starseeker |
yes |
| 03:02.48 |
Mike111 |
I need to use
airfoil shapes |
| 03:03.13 |
starseeker |
can you show
me an example cross section? |
| 03:03.29 |
Mike111 |
sure, can you
hold for a moment? |
| 03:03.33 |
starseeker |
yes |
| 03:06.11 |
starseeker |
are you
thinking along these lines? http://en.wikipedia.org/wiki/File:PSU-90-125.PNG |
| 03:06.40 |
Mike111 |
I've got a
PNG file. how can I send it to you? |
| 03:06.56 |
starseeker |
um. can you
put it up on the brlcad wiki? |
| 03:07.21 |
starseeker |
http://brlcad.org/wiki/Main_Page |
| 03:07.58 |
Mike111 |
it looks
similiar to the wikipedia link |
| 03:08.01 |
starseeker |
Mike111: how
exact does your airfoil shape have to be? |
| 03:09.03 |
starseeker |
the airfoil
can be approximated with a boolean combination of tec and ehy
primitives, but it probably wouldn't be "exactly" the airfoil cross
section. |
| 03:09.09 |
Mike111 |
pretty
accurate. the whole purpose if to test some specific shapes so it's
not just for an illustration purpose |
| 03:09.34 |
starseeker |
ok. yeah,
that sounds like an application where nurbs surfaces would be
required |
| 03:10.14 |
starseeker |
ponders the possibility of a proc-db that does wing shapes
using tec/ehy... hmm... |
| 03:10.36 |
starseeker |
Mike111: for
exact, continuous and complex surfaces of that sort primitives
usually aren't what's needed |
| 03:11.12 |
starseeker |
(one of the
reasons the automobile has modeled with NURBS for so long, for
example - car body exteriors don't map well to geometric
primitives) |
| 03:11.44 |
Mike111 |
that makes
sense. what can we do? |
| 03:12.01 |
starseeker |
we're working
on getting raytracing of NURBS working in BRL-CAD now |
| 03:12.26 |
Mike111 |
I read in
volume III there a b/w extrude feature for arbitrary
shapes |
| 03:12.38 |
starseeker |
yes, but
that's just an extrusion |
| 03:13.04 |
starseeker |
the wing
shape is curved in all three dimensions |
| 03:13.47 |
Mike111 |
let say in a
simpler case, where I just want to extrude along a path (without
cross section changes) |
| 03:14.07 |
starseeker |
for that, you
can define a 2D sketch and extrude it |
| 03:14.43 |
Mike111 |
can I extrude
along a curved path? |
| 03:14.52 |
starseeker |
not
currently |
| 03:14.56 |
starseeker |
that would be
sweep |
| 03:15.40 |
Mike111 |
when do u
expect the nurbs feature to be available? |
| 03:16.00 |
starseeker |
hard to say.
editing support will follow raytracing |
| 03:17.38 |
Mike111 |
do u another
opensource application which can do this now? |
| 03:17.45 |
Mike111 |
do u know
another opensource application which can do this now? |
| 03:18.13 |
starseeker |
If you really
need to work with nurbs, you might take a look at Ayam: http://ayam.sourceforge.net/ -
they're not a CAD application though, so I don't think you get
things like solidity |
| 03:19.14 |
Mike111 |
I need to
export the wing as an IGES file (or DXF etc.) |
| 03:19.24 |
Mike111 |
can I use
ayam and import into brlcad? |
| 03:19.44 |
starseeker |
if you export
as dxf, we import dxf |
| 03:19.54 |
starseeker |
remember
though, that's not a format that supports nurbs |
| 03:20.09 |
Mike111 |
what about
IGES? |
| 03:20.41 |
starseeker |
I believe it
has some nurbs support, but our convertor uses our old nurbs
structures currently. (Plus, I doubt Ayam exports
IGES) |
| 03:21.03 |
Mike111 |
so what can I
do? |
| 03:21.38 |
Mike111 |
the ayam
webpage shows: File formats (r/w): RIB, DXF, 3DM, 3DMF, OBJ,
X3D. |
| 03:22.10 |
starseeker |
If you want
to help push NURBS in support in BRL-CAD, you could take a look at
the IGES convertor and see about getting it to export OpenNURBS
data structures instead of what it currently supplies. |
| 03:22.29 |
starseeker |
For
immediate, fully open source editing of NURBS as
NURBS... |
| 03:22.41 |
starseeker |
let me check
something... |
| 03:25.23 |
starseeker |
you might
want to take a look a gCAD3D, but it's not clear to me if they are
open source or not |
| 03:26.51 |
starseeker |
apparently
they can open the OpenMoko CAD files, but I can't say what other
abilities it may have |
| 03:29.17 |
Mike111 |
can I
smoothly connect cross sections in brlcad, for example by creating
many adjacent ones? |
| 03:29.57 |
starseeker |
yes, if you
force the derivatives at the intersecting points to be
equal |
| 03:30.11 |
Mike111 |
how do I do
that? |
| 03:30.15 |
starseeker |
it's not
easy |
| 03:30.18 |
starseeker |
currently |
| 03:30.41 |
starseeker |
work is going
on on a libpc constraint library that would help support things
like that, but it's (again) a feature in development |
| 03:31.00 |
starseeker |
if you really
want to have a go at it, you can see how the tire tool alligns
elliptical tori |
| 03:31.29 |
starseeker |
similar
problems would need to be solved for the primitives used to make up
the wing shapes |
| 03:31.55 |
starseeker |
it's an
interesting problem, but I'm dubious it could be good enough for
what you're after |
| 03:32.28 |
Mike111 |
I can't see a
tire command in the command reference (Vol. II) |
| 03:32.36 |
starseeker |
it's
new |
| 03:33.03 |
starseeker |
the source is
in brlcad/src/libged/tire.c |
| 03:36.10 |
Mike111 |
help tire
gives `no help found for tire' but that's on 7.10.4 |
| 03:38.53 |
starseeker |
ah,
yes |
| 03:38.57 |
starseeker |
It appeared
later |
| 03:39.56 |
starseeker |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/tire.c?revision=34402&view=markup |
| 03:41.51 |
starseeker |
the
difficulty with something like an airfoil is that the curvature
between each "maximum" point is quite subtle and it may very well
be that for your purposes our primitives currently just don't have
the expressive power |
| 03:42.35 |
starseeker |
I might be
able to get "close" to an airfoil shape with a LOT of work on a
proc-db, but I wouldn't presume to think it was actually
aerodynamically valid |
| 03:42.58 |
Mike111 |
well, I hope
brlcad will soon have the nurbs feature |
| 03:43.16 |
starseeker |
it's our top
development priority |
| 03:43.25 |
starseeker |
or one of
them |
| 03:43.49 |
starseeker |
keep an eye
on us :-) |
| 03:44.03 |
Mike111 |
I guess I
need to find another interim solution until this feature is
added |
| 03:44.05 |
Mike111 |
will do
:) |
| 03:47.30 |
starseeker |
makes a note to check coil behavior before and after the fix
to pipe.c incrementing... |
| 03:47.38 |
starseeker |
and heads
outta here |
| 03:47.48 |
Mike111 |
tnx for your
help starseeker |
| 03:48.30 |
CIA-28 |
BRL-CAD:
03starseeker * r34505 10/brlcad/trunk/TODO: Add a note to look into
a procedural geometry routine for CSG airfoil/wing
shapes. |
| 04:17.50 |
*** join/#brlcad Mike111 (n=mike@cadil21.kaist.ac.kr)
[NETSPLIT VICTIM] |
| 04:17.50 |
*** join/#brlcad jdoliner (n=jdoliner@98.227.157.38) [NETSPLIT
VICTIM] |
| 04:17.51 |
*** join/#brlcad dreeves__ (n=dreeves@64.178.177.71) [NETSPLIT
VICTIM] |
| 04:17.51 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 04:18.24 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 04:18.24 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 04:18.24 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 04:18.24 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 04:18.24 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 04:18.24 |
*** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT
VICTIM] |
| 04:18.24 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 04:18.24 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 04:23.20 |
yukonbob |
hello,
cadheads |
| 05:15.31 |
yukonbob |
win
3 |
| 06:49.04 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 06:54.14 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34506 10/brlcad/trunk/src/libged/CMakeLists.txt:
added scale_ehy.c to stay in sync with Makefile.am |
| 07:13.57 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 07:15.35 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EC8C.dip.t-dialin.net) |
| 07:19.52 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34507 10/rt^3/tags/rel-7-14-8/: a tag to match the
core interface with the corresponding BRL-CAD version |
| 08:52.04 |
*** part/#brlcad Mike111
(n=mike@cadil21.kaist.ac.kr) |
| 08:57.38 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:15.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 10:25.31 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:49.35 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 11:04.24 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 11:54.07 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 12:00.37 |
CIA-28 |
BRL-CAD:
03brlcad * r34508 10/brlcad/branches/STABLE/ (BUGS TODO
src/libged/CMakeLists.txt): merge trunk to STABLE from r34501
through HEAD r34507 for release 7.14.8 (again, wanted
CMakeLists.txt update and hadn't posted yet) |
| 12:01.03 |
CIA-28 |
BRL-CAD:
03brlcad * r34509 10/brlcad/tags/rel-7-14-8/ (BUGS TODO
src/libged/CMakeLists.txt): merge a missed CMakeLists.txt update
from head/stable through r34507, hadn't posted yet so update this
tag. |
| 12:08.00 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 12:21.33 |
*** join/#brlcad LarsG
(n=lars@nusnet-193-70.dynip.nus.edu.sg) |
| 12:21.42 |
*** part/#brlcad LarsG
(n=lars@nusnet-193-70.dynip.nus.edu.sg) |
| 12:24.52 |
*** join/#brlcad LarsG
(n=lars@nusnet-193-70.dynip.nus.edu.sg) |
| 12:24.58 |
*** part/#brlcad LarsG
(n=lars@nusnet-193-70.dynip.nus.edu.sg) |
| 12:38.20 |
*** join/#brlcad hippieindamakin_
(n=hippiein@202.3.77.38) |
| 14:04.20 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34510 10/rt^3/trunk/src/coreInterface/globals.cpp:
name-space prefix BRLCAD is needed |
| 14:07.24 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34511
10/rt^3/trunk/src/coreInterface/ConstDatabase.cpp: a null
miss-function hook my produce a crash during ray-trace |
| 14:12.31 |
archivist |
any sysops in
here? |
| 14:24.00 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34512 10/rt^3/tags/rel-7-14-8/src/coreInterface/
(ConstDatabase.cpp globals.cpp): |
| 14:24.00 |
CIA-28 |
BRL-CAD:
bug-fixes from the trunk: |
| 14:24.00 |
CIA-28 |
BRL-CAD: -
global function implementations need an explicit namespace
prefix |
| 14:24.00 |
CIA-28 |
BRL-CAD: -
explicit ray-trace miss-function hook |
| 14:39.52 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 14:45.28 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EC8C.dip.t-dialin.net) |
| 15:03.10 |
*** join/#brlcad minute_
(i=5207211c@gateway/web/ajax/mibbit.com/x-69928662c823c856) |
| 15:11.53 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:23.12 |
CIA-28 |
BRL-CAD:
03brlcad * r34513 10/brlcad/trunk/src/librt/ (bundle.c shoot.c
vshoot.c): allow null a_hit/a_miss callbacks in the application
structure so that the caller doesn't have to provide empty/stubbed
callback functions just to prevent a crash. |
| 15:45.38 |
CIA-28 |
BRL-CAD:
03brlcad * r34514 10/brlcad/trunk/ (NEWS README
include/conf/PATCH): we are tagged and distcheck passes so bump
version up to 7.14.9 in anticipation of the expected 7.14.10
release (possibly a 7.16, but not there quite yet) |
| 16:02.03 |
CIA-28 |
BRL-CAD:
03davidloman * r34515 10/rt^3/trunk/docs/ (5 files): Converted UML
diagrams over to argoUML (http://argouml.tigris.org/) and
removed grossly outdated Enterprise Architect files and
PNGs. |
| 16:33.00 |
CIA-28 |
BRL-CAD:
03davidloman * r34516 10/rt^3/trunk/include/GE/io/DataStream.h:
Replaced uLong with unsigned long. |
| 16:48.06 |
CIA-28 |
BRL-CAD:
03davidloman * r34517 10/rt^3/trunk/cmakemodules/: added directory
for future cmake modules |
| 16:49.50 |
CIA-28 |
BRL-CAD:
03davidloman * r34518 10/rt^3/trunk/ (include/iBME/AbstractGui.h
src/GUIs/): Removed references to GUI and AbstractGUI
objects. |
| 16:53.32 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 16:56.52 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 17:33.08 |
CIA-28 |
BRL-CAD:
03davidloman * r34519 10/rt^3/trunk/ (26 files in 4 dirs): Removed
references to davidloman's initial take on a OO representation of a
brlcad DB and the objects that it consists of. Making way for
d_rossberg's implementation. |
| 17:33.44 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 17:35.46 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 17:58.02 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 18:02.29 |
CIA-28 |
BRL-CAD:
03davidloman * r34520 10/rt^3/trunk/ (6 files in 3 dirs): Moving
Data Management and Data Sources related class/header files from GE
to GS. |
| 18:07.29 |
CIA-28 |
BRL-CAD:
03davidloman * r34521 10/rt^3/trunk/ (24 files in 4 dirs): Moving
Data Management and Data Sources related class/header files from GE
to GS. (2nd try) |
| 18:09.39 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-245-250.dclient.hispeed.ch) |
| 18:13.44 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 18:28.37 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 18:57.24 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 19:08.59 |
CIA-28 |
BRL-CAD:
03brlcad * r34522 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
remove the indirection and eliminate the static globals given
they're each only used once. |
| 19:22.12 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 19:53.46 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178014770.dsl.bell.ca) |
| 20:36.31 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 21:09.54 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EC8C.dip.t-dialin.net) |
| 21:41.17 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 21:42.10 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 21:42.18 |
brlcad |
finally |
| 21:42.35 |
archivist |
welcome
back |
| 21:42.40 |
brlcad |
thx |
| 22:17.06 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 22:18.34 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 22:19.20 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 22:20.24 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 22:21.05 |
starseeker |
there we
go |
| 22:21.09 |
starseeker |
it's good to
be back |
| 22:24.21 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 22:24.28 |
starseeker |
hmm, this is
interesting for airfoil (wing) information:
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19930090976_1993090976.pdf |
| 22:28.38 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 22:44.46 |
starseeker |
xfoil is GPL,
but might have some useful info on geometric inputs expected for
this sort of design |
| 22:55.59 |
pacman87 |
off to
dinner |
| 22:56.27 |
pacman87 |
took pics of
my 6811 tetris, will post soon |
| 23:02.03 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 23:21.05 |
Ralith |
pacman87:
cool! |
| 23:41.29 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
| 00:48.32 |
*** join/#brlcad Mike111
(n=mike@cadil21.kaist.ac.kr) |
| 00:48.38 |
Mike111 |
hi
all |
| 00:51.35 |
Mike111 |
I need to
generate a NURBS solid (which I understand brlcad currently doesn't
support) and export it in IGES format. Ayam can create does NURBS
but exports only RIB, DXF, 3DM, 3DMF, OBJ, X3D. Any ideas how
convert the Ayam solid into IGES?. |
| 00:59.24 |
``Erik |
um, if I
understand correctly, the SVN version of BRL-CAD does actaully
support creation, loading and saving of nurbs... there are issues
with raytracing at the moment |
| 00:59.53 |
``Erik |
but this
subject is more the turf of people who are online in the morning
GMT-5 |
| 01:00.53 |
Ralith |
does the IGES
exporter handle them? |
| 01:01.01 |
``Erik |
I doubt
it |
| 01:01.28 |
``Erik |
mmmm molten
boron |
| 01:01.32 |
``Erik |
futurama++ |
| 01:22.01 |
*** join/#brlcad LarsG
(n=lars@spnp206076.spnp.nus.edu.sg) |
| 01:22.07 |
*** part/#brlcad LarsG
(n=lars@spnp206076.spnp.nus.edu.sg) |
| 01:28.26 |
Mike111 |
hi
Erik. |
| 01:28.48 |
Mike111 |
can I create
a NURBS surface which smoothly blends between two 2D
cross-sections? |
| 01:46.47 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 01:47.11 |
starseeker |
~log |
| 01:47.11 |
ibot |
extra, extra,
read all about it, log is http://ibot.rikers.org/%23wowhead/ |
| 01:49.28 |
starseeker |
uh, shouldn't
that be http://ibot.rikers.org/%23brlcad/
? |
| 01:52.09 |
starseeker |
brlcad: I'm
wondering if we're going to have to set up a way to store the
bounding box trees for nurbs surfaces once generated - it may be
that creating them "on the fly" will be almost as bad as
tesselating before raytracing |
| 01:54.00 |
Mike111 |
hi
starseeker. |
| 01:54.23 |
Mike111 |
I think the
feature I'm looking for is the Ayam Birail2 object: http://ayam.sourceforge.net/features.html |
| 02:00.16 |
starseeker |
Mike111: heh,
brlcad was just mentioning birails for that application |
| 02:00.32 |
starseeker |
feel like
implementing a birails primitive? |
| 02:00.54 |
Mike111 |
not sure I
can ;) |
| 02:01.45 |
starseeker |
Well, the
ayam source code license is compatible with BRL-CAD's iirc, so you
could use some of the logic there |
| 02:02.07 |
starseeker |
src/librt/primitives/ holds our current
primitives |
| 02:02.13 |
``Erik |
I want a
birail prim :( |
| 02:02.14 |
starseeker |
hyp and
revolve are recent work |
| 02:05.33 |
``Erik |
tell ya what,
I can't afford the time to do it, but the birail is important
enough to me that I'll totally mentor/help anyone who does
that |
| 02:06.28 |
``Erik |
want my damn
car back. Want my house fixed. |
| 02:07.36 |
``Erik |
dane cook...
isn't actually funny... it's not good |
| 02:09.07 |
Mike111 |
I've noticed
that configure installs a NURBS library. what is it used for
then? |
| 02:12.01 |
``Erik |
that's
current development |
| 02:12.33 |
``Erik |
we hope to
have solid NURBS capabilties in the very near future, but we're ...
still working on it :) |
| 02:13.23 |
Mike111 |
that will be
good |
| 02:17.44 |
Mike111 |
in the
meantime, can brlcad import nurbs from Ayam? |
| 02:17.58 |
Mike111 |
I understand
the DXF format does not support nurbs |
| 02:18.33 |
``Erik |
I think the
only nurb import is STEP, and it's ... not 100% |
| 02:19.11 |
``Erik |
like I said
before, the people who know that aren't on right now, they'll
probably be around in about 10 hours |
| 02:20.12 |
starseeker |
IGES is the
only working nurbs import |
| 02:20.22 |
starseeker |
STEP is being
worked currently |
| 02:20.44 |
starseeker |
Or there's
the 3dm (Rhino) to g conversion if you happen to have
Rhino |
| 02:21.01 |
starseeker |
IGES produces
old (non openNURBS) nurbs right now |
| 02:21.21 |
starseeker |
the STEP
conversion will create openNURBS nurbs, as does the 3dm-g
convertor |
| 02:21.42 |
Mike111 |
is `3dm-g'
the application name> |
| 02:21.45 |
``Erik |
I thought the
iges importer require the tesseleation phase |
| 02:21.48 |
starseeker |
yes |
| 02:21.56 |
starseeker |
``Erik: I
don't think so... |
| 02:22.25 |
starseeker |
If you have
access to Rhino, you can model in that and then use 3dm-g to get a
.g file |
| 02:22.36 |
starseeker |
Doubt that
will help with Ayam though |
| 02:22.40 |
Mike111 |
is that an
opensource? |
| 02:22.46 |
starseeker |
Rhino?
nope |
| 02:23.02 |
Mike111 |
I prefer to
rely on opensource only |
| 02:23.12 |
``Erik |
rhino is only
$200, not $20,000 though :) |
| 02:23.39 |
starseeker |
the Rhino
guys are the ones who did openNURBS |
| 02:24.26 |
starseeker |
(so the 3dm-g
"conversion" doesn't have to do any hard work on the NURBS data
structures) ;-) |
| 02:27.31 |
starseeker |
has wondered if it might be possible to convince the
Rhino/openNURBS guys to add their *->openNURBS conversion logic
to the lib... |
| 02:27.44 |
starseeker |
probably not
though |
| 02:28.30 |
starseeker |
Mike111: the
basic truth is that there isn't a complete open source NURBS
solution that I know of right now. |
| 02:28.47 |
starseeker |
One thing
about Ayam - IIRC it uses Tk for its interface, just like
MGED/Archer |
| 02:29.09 |
starseeker |
so you could
take a look at their editing support and see how it maps to
openNURBS |
| 02:29.35 |
Mike111 |
Ayam probably
does all I need (plus supports scripting). The problem is getting
the IGES file. |
| 02:36.02 |
starseeker |
Ayam says it
supports 3dm export |
| 02:36.18 |
starseeker |
you MIGHT be
able to try exporting to 3dm and see if 3dm-g works |
| 02:36.38 |
Mike111 |
3dm-g is
rhino? |
| 02:36.45 |
starseeker |
3dm is
rhino |
| 02:37.27 |
starseeker |
remember
though, even if you get a .g file, we can't EXPORT openNURBS to
IGES any more than we can import them |
| 02:38.13 |
starseeker |
so at the
very least you'd have to update the IGES export routine to work
with the openNURBS data structures |
| 02:39.15 |
starseeker |
makes a note to see what 3dm-g does with Ayam 3dm
exports |
| 02:42.15 |
Mike111 |
what's the
difference between standard nurbs and opennurbs? |
| 03:40.23 |
yukonbob |
hello
cadheads |
| 03:40.28 |
brlcad |
starseeker:
cross that bridge when we're actually stepping on it, but not
unthinkable to store the bb's in some in-memory structure .. could
even possibly persist them but even tessellation needs to be
"interactive" |
| 03:41.24 |
brlcad |
Mike111: we
can import nurbs through our iges importer, or through our 3dm
importer, but you can't do much more than render them |
| 03:42.52 |
brlcad |
``Erik: iges
importer has 3 different import modes, one being nurbs, another
being 2D nmg, and another for 3d nmg |
| 03:44.27 |
brlcad |
Mike111: the
3dm file format is from the same guys that develop rhino, but 3dm-g
is *our* importer for the 3dm format (and doesn't require
rhino) |
| 03:45.33 |
Mike111 |
can I use
brlcad to convert 3dm to IGES? |
| 03:45.51 |
brlcad |
Mike111:
openNURBS is just the name of the library |
| 03:45.59 |
brlcad |
no you
cannot |
| 03:46.02 |
brlcad |
at least not
yet |
| 03:46.21 |
brlcad |
because 3dm
will import as 'new nurbs' objects, for which there is no iges
export support yet |
| 03:47.15 |
brlcad |
it really
wouldn't be too much work to get it working, but you'd have to work
on that code |
| 03:47.28 |
brlcad |
or someone
would have to, we're not hitting up the converters until a little
later |
| 03:47.35 |
Mike111 |
but there is
technically IGES supports NURBS, that is, it is just an issue of
adding the nurbs capability? |
| 03:47.49 |
Mike111 |
but
technically IGES supports NURBS, that is, it is just an issue of
adding the nurbs capability? |
| 03:47.51 |
brlcad |
right |
| 03:47.58 |
brlcad |
nurbs support
on export specifically |
| 03:48.23 |
brlcad |
would have to
add that logic to our iges exporter to export our nurbs geometry as
iges nurbs |
| 03:48.36 |
brlcad |
really
probably *very* simple |
| 03:48.45 |
brlcad |
probably a
1-1 mapping |
| 03:48.50 |
Mike111 |
so at the
moment there's Ayam which does nurbs but not IGES and brlcad does
IGES but not nurbs |
| 03:48.56 |
Mike111 |
:( |
| 03:48.58 |
brlcad |
:) |
| 03:49.02 |
Ralith |
:| |
| 03:49.03 |
brlcad |
something
like that |
| 03:49.23 |
brlcad |
we sort of do
nurbs, just no export support :) |
| 03:50.27 |
Mike111 |
can I create
a nurbs surface in brlcad? |
| 03:50.44 |
Mike111 |
I understand
it is work in progress |
| 03:51.03 |
brlcad |
not
interactively via the gui |
| 03:51.25 |
brlcad |
only via
import (iges/3dm) or programmatically via code |
| 03:51.32 |
Mike111 |
I plan to do
via a script |
| 03:52.43 |
brlcad |
someone would
have to add scripting support to our existing new nurbs
implementation (probably a days work) for that to work |
| 03:52.58 |
brlcad |
as the
programmatic access is presently only via C |
| 03:53.32 |
Mike111 |
I don't code
in C or C++ so I'm afraid I can't help you there |
| 03:54.01 |
brlcad |
nods |
| 03:54.21 |
brlcad |
it's really
not much to add the support, just have to catch a dev with a few
hours of free time |
| 03:54.25 |
brlcad |
<PROTECTED> |
| 03:55.16 |
Mike111 |
specifically,
I want to create a surface which smoothly blends 2-D
cross-sections. Is this viable in brlcad? |
| 03:55.24 |
Mike111 |
I understand
from starseeker it is not |
| 03:55.39 |
brlcad |
you need a
birail primitive for that, which is on our ideas page but not being
worked on yet |
| 03:56.11 |
brlcad |
or at a
minimum, you need sweep support, which is being worked on this
summer |
| 03:56.29 |
brlcad |
though that
will only do very specific/simple blends |
| 03:56.37 |
Mike111 |
so there are
two features missing (for what I need): script support for nurbs
and the birail |
| 03:56.46 |
brlcad |
another
possibility for you is to use our waterline primitive |
| 03:56.56 |
Mike111 |
how flexible
will the birail feature? |
| 03:56.58 |
brlcad |
you define
spline contours |
| 03:57.02 |
Mike111 |
what's that
waterline? |
| 03:57.03 |
brlcad |
those will
export to iges too |
| 03:58.22 |
brlcad |
what we call
an 'ars' primitive |
| 03:59.33 |
Mike111 |
will that
blend 2D cross-sections? |
| 03:59.59 |
brlcad |
yes |
| 04:00.02 |
brlcad |
slices |
| 04:00.11 |
brlcad |
the blends
will be polygonal though |
| 04:00.18 |
brlcad |
and depend on
your number of slices |
| 04:00.37 |
brlcad |
i'll see if i
can find some examples |
| 04:01.14 |
brlcad |
here's one,
http://brlcad.org/gallery/s/screenshots/t62_mged.jpg.html |
| 04:01.18 |
brlcad |
that turret
is an 'ars' |
| 04:01.42 |
brlcad |
see how it
tessellates them together, you can see each "layer" |
| 04:02.41 |
brlcad |
and
fortunately, there's a great page specifically on the ARS on the
wiki |
| 04:02.45 |
brlcad |
thanks to
Ges |
| 04:02.48 |
brlcad |
http://brlcad.org/wiki/BRL-CAD_Primitives |
| 04:03.00 |
Mike111 |
can you make
it smoother, that is, use smaller polygons? |
| 04:03.26 |
brlcad |
sure |
| 04:03.35 |
brlcad |
read the wiki
page, it explains |
| 04:03.46 |
brlcad |
number of
points per polyline will make it smoother |
| 04:04.13 |
Mike111 |
I'm trying to
model a wing, so having these polygons isn't practical |
| 04:04.25 |
Mike111 |
I need a
smooth surface |
| 04:04.44 |
brlcad |
it will
converge to smooth |
| 04:04.48 |
brlcad |
but I
understand |
| 04:04.55 |
brlcad |
just saying
what we have ;) |
| 04:06.20 |
Mike111 |
the 2D
sections (airfoils) are generated by another application and
available as coordinates |
| 04:06.26 |
Mike111 |
how can I
import them into brlcad? |
| 04:09.12 |
brlcad |
you mean as
an ars? |
| 04:11.00 |
brlcad |
if so, read
the wiki page -- it explains all and gives an example (and mged is
fully scriptable) |
| 04:11.12 |
Mike111 |
I have
several 2D cross-sections, defined by plain ascii files
(coordinates). how do I create in brlcad a smooth surface
connecting them? |
| 04:13.20 |
brlcad |
have you been
missing everything I've been saying? :) |
| 04:14.15 |
Mike111 |
the ars
webpage mentions I need to provide the coordinates of all points of
the interior polygons. |
| 04:15.36 |
brlcad |
you're either
using our ars (i.e. faceted and non-smooth), or our dsp (quantized,
but smoothable), or manually via polygons (also smoothable), or via
an extruded 2D sketch (smooth surface but only linear uniform
extrusions), or via nurbs (incomplete), or via birail
(non-existent) ;) |
| 04:16.05 |
Mike111 |
I'm referring
to the ars |
| 04:16.15 |
brlcad |
yes, the
"interior points" are basically the 2d coordinates |
| 04:16.38 |
Mike111 |
that's ok for
something like that twisted cube but seems impractical for
something like a wing |
| 04:16.40 |
brlcad |
"The
parameters to the above ars command can be dissected as"
... |
| 04:17.16 |
brlcad |
that's only
because it's using 4 points per waterline, the first
parameter |
| 04:17.37 |
brlcad |
you'd want
dozens or hundreds of points to smooth it out |
| 04:17.54 |
brlcad |
the tank
turret is around dozens |
| 04:18.06 |
Mike111 |
and I'll need
to provide the coordinates for each of these, right? |
| 04:18.24 |
brlcad |
I believe
so |
| 04:19.32 |
Mike111 |
I need to
check if that is practical with my application |
| 04:19.37 |
brlcad |
nods |
| 04:21.31 |
brlcad |
ttyl! |
| 04:23.14 |
Mike111 |
thanks for
your help brlcad, I'll look into ars later. need to go
now |
| 05:26.19 |
*** join/#brlcad Mouette
(n=chatzill@fw1.phys.sinica.edu.tw) |
| 05:56.52 |
starseeker |
winces at the memory of his own run-in with
ars |
| 05:58.18 |
starseeker |
Ayam seems to
export something 3dm-g recognizes as a 3dm file, but my initial
stab didn't get anything it felt like importing to the
.g |
| 05:58.22 |
starseeker |
probably did
it in Ayam wrong |
| 06:01.17 |
starseeker |
hadn't considered using dsp - boy would that be a strange use
of it |
| 06:54.34 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 06:56.08 |
Mike111 |
is there help
available on dsp? it's not in volume II (added lately?) |
| 07:08.57 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 07:19.33 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 07:28.01 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34523
10/rt^3/trunk/src/coreInterface/ConstDatabase.cpp: |
| 07:28.01 |
CIA-28 |
BRL-CAD:
revert changes from revision 34511 |
| 07:28.01 |
CIA-28 |
BRL-CAD: Sean
changed the code in librt so the miss-function hook may now be null
as well |
| 07:48.43 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34524 10/rt^3/trunk/ (4 files in 2 dirs): added the
cone (ID_TGC) primitive |
| 07:51.52 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34525
10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: included the
Cone from the core interface in the brlcad.dll |
| 08:54.35 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:20.51 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 09:25.28 |
*** join/#brlcad docelic
(n=docelic@78.134.194.113) |
| 09:26.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 10:48.48 |
*** join/#brlcad claymore
(n=claymore@bz.bzflag.bz) |
| 10:49.14 |
d-lo |
mernin
all! |
| 10:50.57 |
*** join/#brlcad LarsG
(n=lars@spnp206047.spnp.nus.edu.sg) |
| 10:51.04 |
*** part/#brlcad LarsG
(n=lars@spnp206047.spnp.nus.edu.sg) |
| 10:58.10 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F71A.dip.t-dialin.net) |
| 11:13.19 |
CIA-28 |
BRL-CAD:
03Rossberg 07http://brlcad.org *
r1442 10/wiki/CoreInterface_PrintTitle_Example:
BRLCAD::bad_alloc |
| 11:41.53 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 11:48.45 |
``Erik |
shush,
you |
| 11:52.05 |
``Erik |
heh, it's
been so long since I've updated the fbsd port of BRL-CAD that pedro
is lookin gto roll a copy |
| 11:52.28 |
brlcad |
so let 'em,
nice to share the workload ;) |
| 11:52.46 |
``Erik |
well, |
| 11:52.58 |
``Erik |
the tkhtml
issue really screws things over in a big way for that |
| 11:53.28 |
``Erik |
and he wasn't
in the loop, so this latest release is going to surprise
him |
| 11:54.09 |
``Erik |
will do it today |
| 11:54.14 |
``Erik |
oh, are you
in the office right now? |
| 11:54.30 |
``Erik |
brlcad? |
| 11:54.36 |
brlcad |
not
yet |
| 11:54.43 |
brlcad |
eta
hour |
| 11:55.01 |
``Erik |
ok, then I'll
call. the work is continuing on my front door area, some paint has
been laid down, but it's not done yet :/ |
| 11:55.12 |
``Erik |
I need to
find my usb/miniusb cable to get some pics off my camera
:/ |
| 11:55.45 |
``Erik |
heh, gonna be
out today for house work, and if mondays predictions are right, out
tomorrow to return the rental and get my car back... |
| 11:56.15 |
``Erik |
<--
wonders how much he's pissing off the bc with this 'other
crap' |
| 11:59.56 |
``Erik |
neat, my
phone locked up |
| 12:03.15 |
d-lo |
``Erik: I
asked her and she said "Who's Eric?" ;) |
| 12:03.31 |
d-lo |
and then I
said "Erik, not Eric" |
| 12:03.47 |
d-lo |
and she said
"oh him. Yeah, its cool." |
| 12:03.53 |
d-lo |
so no
worries. |
| 12:04.04 |
``Erik |
hah |
| 12:04.24 |
``Erik |
she doesn't
get in until 8:30, though? I just got off the phone with admin
assist |
| 12:05.26 |
d-lo |
TBH, if you
are using time you have earned... then don't think twice about
it. |
| 12:05.31 |
``Erik |
tell ya what,
though, this is pissing me off. it was supposed to be a one day
job, this is day #3 without completion and he's figuring on doing
some today, then wrapping it up saturday... |
| 12:05.46 |
d-lo |
What's he
charge an hour? |
| 12:05.54 |
``Erik |
he's
predicting time schedules as bad as... as... a software
developer |
| 12:05.59 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 12:06.03 |
d-lo |
HAH! |
| 12:06.05 |
``Erik |
he's charging
per project, not hour |
| 12:06.14 |
``Erik |
so he's
jacking himself more than anything |
| 12:06.14 |
d-lo |
well thats
good at least. |
| 12:07.17 |
``Erik |
I just need
to make sure I still have enough leave saved up to take two weeks
around early july O.o |
| 12:07.19 |
d-lo |
Lawn chair +
a few stiff drinks + wow on laptop + watching him work = Fun, if
nothing else. ;) |
| 12:08.09 |
``Erik |
heh, 'cept
I've been inside, trying to clean things up ... or outside giving
him an extra pair of hands :) no wow, no watching, ... but yeah, a
few stiff drinks ;> |
| 12:09.28 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 12:09.48 |
``Erik |
that and
learning new songs on my guitar O.o BOC - the reaper and buddy
holly - everyday |
| 12:10.37 |
d-lo |
LOL, every
time I hear the BOC - Reaper, I can't help but start thinking of
Cowbell. |
| 12:10.54 |
``Erik |
ayup
:D |
| 12:11.13 |
*** join/#brlcad MinuteEl1ctron
(n=MinuteEl@bz.bzflag.bz) |
| 12:11.20 |
``Erik |
that's
actually the reason I decided to pick it up |
| 12:12.02 |
d-lo |
hahahaha. |
| 12:12.16 |
d-lo |
I am reduced
to tears every time I watch that video. |
| 12:12.51 |
d-lo |
There is just
something about Walken.... "Let me tell you something. I gotta
feva, and the only cure is more Cowbell." |
| 12:13.04 |
``Erik |
indeed |
| 12:13.28 |
``Erik |
if I scrap
together another band and do a gig, I so want to say "I got a
feva!" right before playing that song :D |
| 12:50.15 |
*** join/#brlcad WorkCath
(n=d4db51b5@bz.bzflag.bz) |
| 12:50.42 |
*** join/#brlcad WorkCath
(n=d4db51b5@bz.bzflag.bz) |
| 14:42.55 |
*** join/#brlcad docelic
(n=docelic@78.134.201.71) |
| 15:00.10 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) |
| 15:18.48 |
brlcad |
howdy
roberthl |
| 16:01.14 |
roberthl |
hi |
| 16:01.26 |
roberthl |
I am
MinuteElectron, btw. |
| 16:01.35 |
d-lo |
I am Iron
Man |
| 16:04.26 |
d-lo |
Heh,
outstanding tutorial: http://www.wikihow.com/Escape-a-Minefield |
| 17:10.51 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 17:19.40 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 20:18.49 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 20:27.00 |
brlcad |
roberthl: I
figured :) |
| 20:27.11 |
brlcad |
hence the
howdy ;) |
| 20:28.51 |
roberthl |
ah
;) |
| 20:29.05 |
roberthl |
how are
things? |
| 20:29.13 |
brlcad |
going
well |
| 20:29.15 |
roberthl |
good |
| 20:29.29 |
brlcad |
what are you
up to? |
| 20:30.09 |
roberthl |
exams for the
next couple of months |
| 20:35.35 |
brlcad |
fun! |
| 20:35.37 |
brlcad |
(not)
:) |
| 20:35.51 |
roberthl |
hehe |
| 20:51.53 |
Ralith |
couple of
months? |
| 20:51.54 |
Ralith |
wow. |
| 20:52.03 |
Ralith |
just got done with the majority of his |
| 21:21.00 |
roberthl |
I'm in the
UK. |
| 22:31.29 |
brlcad |
feel free to
nominate us for best project,
https://sourceforge.net/community/cca09/nominate/?hash=fec98ebc83402b5dd32313ebe5b215d2
;) |
| 22:39.53 |
Ralith |
wow, sf's
been modernizing |
| 22:47.27 |
brlcad |
yeah, the
design and layout is vast improvement |
| 23:07.11 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 00:22.31 |
brlcad |
starseeker:
you happen to have a specific nirt/rt script handy that provokes a
root convergence error? |
| 00:23.15 |
brlcad |
if you get a
chance, would like to put that to rest and have a couple things I'd
like to check out but need a test case or three |
| 00:49.14 |
starseeker |
brlcad: do
you mean for the eto? |
| 00:49.35 |
brlcad |
for any that
fail to converge |
| 00:49.59 |
starseeker |
erm. I can
probably make one for the default tire - give me a sec |
| 00:55.59 |
starseeker |
brlcad: does
that error message output suppression you added for the nurbs
raytracing work for all of them? |
| 01:04.52 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 01:06.43 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 01:07.28 |
starseeker |
brlcad: this
rt script will kick up a healthy bunch on one of the ellipses you
get with the default tire command (no tread - just run tire
tire) |
| 01:07.31 |
starseeker |
http://pastebin.bzflag.bz/mb9f9cf3 |
| 01:07.40 |
starseeker |
you can see
the lines in the raytrace |
| 01:08.07 |
starseeker |
I'll be back
later if you want me to narrow it down further |
| 01:09.10 |
Mike111 |
hi
all |
| 01:09.53 |
Mike111 |
is there help
available on dsp (can't see it in Vol. II) |
| 01:25.38 |
*** join/#brlcad LarsG
(n=lars@spnp206029.spnp.nus.edu.sg) |
| 01:25.45 |
*** part/#brlcad LarsG
(n=lars@spnp206029.spnp.nus.edu.sg) |
| 01:34.44 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 01:50.17 |
brlcad |
Mike111: it's
an advanced primitive, best to ask specific questions on how to use
it |
| 01:50.43 |
brlcad |
you'll need a
raw binary data file with unsigned short height values |
| 01:51.00 |
Mike111 |
what does it
do? |
| 01:52.11 |
brlcad |
it's a height
field primitive |
| 01:52.29 |
brlcad |
a grid of
elevation values |
| 01:53.12 |
Mike111 |
something
like an landscape defined by elevations? |
| 01:53.23 |
Mike111 |
something
like a landscape defined by elevations? |
| 01:53.24 |
brlcad |
I'd use an
ARS before using a DSP for your air foil |
| 01:53.28 |
brlcad |
yes |
| 01:53.59 |
brlcad |
for an air
foil, you'd basically use two aligned dsp's unioned together with
smoothed values |
| 01:54.48 |
brlcad |
but again,
not what I'd recommend first |
| 01:54.48 |
brlcad |
here is a
massive data set dsp: http://brlcad.org/tmp/puget01.png |
| 01:56.11 |
Mike111 |
regarding the
ars, as I understand the waterlines all start from the same
point? |
| 01:58.11 |
brlcad |
? |
| 01:58.37 |
brlcad |
not
really |
| 01:59.16 |
brlcad |
there is a
starting reference point, but from there it's whatever you
input |
| 01:59.57 |
Mike111 |
The webpage
says:`In addition to the intermediate polygons a line will be
created that begins at the start point, goes through each polygon
at its vertex numbered 1, and terminates at the end point. This is
repeated for each polygon vertex 2 thru N. The start point,
polygons, and end point are each a "waterline"' |
| 02:00.45 |
Mike111 |
so with that
twisted cube, the start point is the center of the top face and the
endpoint if center of the bottom face, right? |
| 02:03.09 |
brlcad |
think of it
like this:
http://www.dans-hobbies.com/wp-content/uploads/2007/11/waterlines.jpg |
| 02:03.36 |
brlcad |
there are
"loops" at each waterline level -- those are the polygons it refers
to |
| 02:04.24 |
brlcad |
like if you
sliced an apple, http://www.mathcubed.com/images/sliced_apple.jpg |
| 02:04.40 |
brlcad |
each polygon
is the outline of the apple for that layer |
| 02:05.52 |
Mike111 |
so each
polygon is a 2D slice? |
| 02:06.21 |
brlcad |
yes |
| 02:07.10 |
Mike111 |
so if I want
to model a wing comprised of airfoil cross-sections, each `polygon'
is now an airfoil? |
| 02:07.28 |
brlcad |
so in
http://brlcad.org/wiki/BRL-CAD_Primitives
.. there are four simple slices (layers) |
| 02:07.43 |
brlcad |
each layer
simply has just four points so it's really boxy |
| 02:07.48 |
brlcad |
add more
points and it smooths out |
| 02:07.56 |
brlcad |
yes |
| 02:08.13 |
brlcad |
each
cross-section would be described by a simple 2d polygon |
| 02:08.39 |
Mike111 |
but for
accurate description of the airfoil I'll need tens of
points |
| 02:08.56 |
brlcad |
probably
hundreds |
| 02:09.15 |
brlcad |
if you have
the equations, that part can be automated |
| 02:09.33 |
Mike111 |
the airfoil
is defined by a polynomial, so yes |
| 02:10.09 |
Mike111 |
I have the
coordinates for the airfoil's upper and lower surface (above and
below its mean line) in a plain text file |
| 02:17.23 |
Mike111 |
for the wing
model, the start point will be in root airfoil section (say its
centre) and the end point is in the tip airfoil
section? |
| 02:18.22 |
starseeker |
brlcad: does
that script help any? |
| 02:20.10 |
brlcad |
trying to get
it to run |
| 02:21.24 |
brlcad |
got
it! |
| 02:21.25 |
brlcad |
thanks! |
| 02:24.12 |
starseeker |
np |
| 02:43.46 |
Mike111 |
is there a
tutorial for scripting brlcad (besides http://brlcad.org/wiki/SGI_Cube)? |
| 02:47.28 |
brlcad |
the mged
tutorial series covers most of the basic commands, the appendix
itemizes the majority of available commands, the quick reference
card summarizes the commands (and has another scripting
example) |
| 02:48.25 |
Mike111 |
brlcad uses
tcl programming syntax, right? |
| 02:48.28 |
brlcad |
the cube
example covers at least three ways to script mged -- if that's not
sufficient, then you're probably lacking something else |
| 02:48.46 |
brlcad |
no, mged has
a tcl interpreter |
| 02:48.59 |
brlcad |
but you can
script mged using almost any language |
| 02:49.05 |
brlcad |
as it's
command-driven |
| 02:49.26 |
brlcad |
that's
specifically what the SGI_Cube explains |
| 02:49.28 |
Mike111 |
there was an
example in Vol.II for writing a loop and it mentioned it's in tcl
format |
| 02:50.05 |
Mike111 |
p.107 |
| 02:50.10 |
brlcad |
it really
sounds like you're not understanding something fundamental -- what
do/don't you understand about the SGI_Cube tutorial |
| 02:50.27 |
brlcad |
yes,
and? |
| 02:51.10 |
Mike111 |
is there any
benefit in learning the tcl syntax, that is, will it help in
scripting for brlcad? |
| 02:51.13 |
brlcad |
mged's
internal interpreter is tcl, so that example is in tcl -- and the
SGI_Cube example is a simple posix shell script, not
Tcl |
| 02:51.18 |
Mike111 |
besides loop,
that is |
| 02:52.24 |
brlcad |
there's
benefits to learning most languages, depends what your goal
is |
| 02:52.34 |
brlcad |
is it
necessary, no |
| 02:52.37 |
brlcad |
it it useful,
sure |
| 02:53.16 |
brlcad |
what
language(s) do you know? |
| 02:53.22 |
Mike111 |
for the
airfoil, I can either generate all the coordinates in octave and
output a plain text file with commands for brlcad |
| 02:53.29 |
Mike111 |
octave |
| 02:54.02 |
brlcad |
eh, anything
else? |
| 02:55.43 |
Mike111 |
or I can
presumably write a function/procedure for brlcad which will cycles
over the airfoil points (instead of creating a text file with
hundreds of lines) |
| 02:56.24 |
brlcad |
it's a means
to an end -- it doesn't really matter |
| 02:56.30 |
Mike111 |
wondering
which is better |
| 02:56.34 |
brlcad |
hundreds/thousands of lines would work
just fine |
| 02:56.37 |
brlcad |
as would a
proc |
| 02:57.06 |
brlcad |
given your
background, writing out mged commands to a text file is probably
the easiest |
| 02:57.26 |
brlcad |
in ars ars
val1 val2 val3 val4 ....... |
| 02:57.42 |
Mike111 |
yep, I was
thinking something like that |
| 02:58.05 |
Mike111 |
it's
basically a loop which appends text lines to file with
printf |
| 02:58.27 |
Mike111 |
octave uses
the C printf syntax |
| 02:59.07 |
brlcad |
octave's
syntax is close to csh/tcsh shell scripting syntax |
| 02:59.20 |
brlcad |
you might do
well to learn/write a tcsh script |
| 02:59.37 |
Mike111 |
I've done a
bit of bash scripting |
| 03:00.12 |
brlcad |
okay, then
that |
| 03:00.44 |
brlcad |
sgi_cube is a
posix/bash/ksh/sh script |
| 03:01.00 |
Mike111 |
there's no
issue on mged side handling an ars with say 200 points per
polygon? |
| 03:01.06 |
brlcad |
you should
study/understand it -- it shows three specific ways to issue
commands |
| 03:01.13 |
brlcad |
nope |
| 03:04.45 |
Mike111 |
ok. thanks
for your help brlcad |
| 03:07.46 |
brlcad |
sure |
| 03:12.48 |
starseeker |
wonders how workable a tool to generate birail based wings
from NACA numbers + wing type (straight, tapered, delta,
etc) |
| 03:21.26 |
Mike111 |
starseeker:
NACA is only one of airfoil parameterization methods. common
current methods are PARSEC (11 design variables) and Hicks-Henne
(sum of basis functions) |
| 03:21.46 |
starseeker |
Is NACA a
subset, or different altogether? |
| 03:21.54 |
Mike111 |
different |
| 03:22.08 |
starseeker |
so, not
terribly useful for modern wings? |
| 03:22.18 |
Mike111 |
PARSEC are
Hicks-Henne are recent |
| 03:22.48 |
Mike111 |
Hard to say.
I haven't seen many recent studies where people directly used
NACA. |
| 03:22.59 |
starseeker |
hrm |
| 03:23.12 |
starseeker |
any
references available on PARSEC and Hicks-Henne online? |
| 03:23.29 |
Mike111 |
It will
probably be sufficient if brlcad can smoothly blend two arbitrary
cross-sections |
| 03:23.42 |
Mike111 |
the user will
need to provide the cross-sections (airfoils) |
| 03:24.19 |
starseeker |
oh, sure -
I'm more curious about the possibility of generating "standard"
wing shapes based on some standard specification - be it NACA
numbers, PARSEC, what have you |
| 03:25.38 |
starseeker |
procedural
wings, if you prefer |
| 03:26.12 |
Mike111 |
it can be an
issue since there are quite a few methods out there and they're all
different |
| 03:26.32 |
Mike111 |
also, people
are experimenting with new methods, like orthogonal
polynomials |
| 03:26.38 |
starseeker |
nods |
| 03:26.45 |
starseeker |
understood |
| 03:27.05 |
starseeker |
but for most
"standard" wing designs already in use, it's likely they're
characterized by some existing method |
| 03:27.24 |
starseeker |
I need some
XXXXXXX wings for commercial plane XXXXXX |
| 03:28.00 |
Mike111 |
what
engineers do is optimze the wing for a performance
profile |
| 03:28.19 |
Mike111 |
cruise speed,
altitude, take-off weight etc. |
| 03:28.25 |
Mike111 |
either
wind-tunnel or CFD |
| 03:28.48 |
starseeker |
once they've
optimized it, how do they tell someone else what to
build? |
| 03:29.24 |
Mike111 |
airfoil
cross-sections, sweep (backward tilt of the wing), twist of airfoil
sections etc. |
| 03:30.18 |
starseeker |
ok, so
airfoil cross sections, sweep (is that an angle, or something more
complex?), twist of sections (is that from one cross section to the
next?) |
| 03:30.57 |
Mike111 |
sweep=angle
of wing w.r.t to hull, twist=between airfoils |
| 03:31.42 |
Mike111 |
I hope brlcad
will have nurbs capabilities soon (including scripting support)
:) |
| 03:32.51 |
starseeker |
I realize no
one specification is going to encompass all the experimental wing
designs out there - what I'm after is some sort of "ISO or ANSI
wing specification" standard that outlines a way to geometrically
describe most standard wing shapes |
| 03:38.09 |
starseeker |
for example,
for tires it would be something like this:
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36320 |
| 03:47.22 |
Mike111 |
not sure if
this exists for wings |
| 03:58.02 |
Mike111 |
need to go
now. have a good one |
| 06:14.33 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 06:34.44 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 07:26.23 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FFA5.dip.t-dialin.net) |
| 08:26.38 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 10:36.47 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FFA5.dip.t-dialin.net) |
| 10:43.45 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:01.23 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 11:37.36 |
brlcad |
d-lo: so
they're already working on migration scripts for the
forums |
| 11:37.42 |
brlcad |
couple
weeks |
| 11:38.13 |
brlcad |
they'll be
getting rid of the old forums, the task manager, the doc manager,
and the diary/notes sections |
| 11:40.52 |
brlcad |
yay,
indianlarry is in |
| 12:15.17 |
*** join/#brlcad _clock__
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 12:21.26 |
*** join/#brlcad indianlarry
(n=indianla@bz.bzflag.bz) |
| 12:37.04 |
*** join/#brlcad _clock_
(n=_sushi_@zux221-122-143.adsl.green.ch) |
| 12:38.52 |
brlcad |
indianlarry:
heh welcome! |
| 12:38.58 |
brlcad |
see you
figured it out :) |
| 12:39.24 |
indianlarry |
partly |
| 12:40.09 |
brlcad |
cheers |
| 13:01.28 |
d-lo |
brlcad
excellent! |
| 13:01.36 |
d-lo |
waves @ indianlarry |
| 13:01.52 |
indianlarry |
hey
d |
| 13:46.07 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 13:47.01 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:47.17 |
*** join/#brlcad crabbie
(n=CoconutC@222.252.92.200) |
| 13:49.13 |
d_rossberg |
why is the
color in struct mater_info float? |
| 13:49.37 |
d_rossberg |
in struct
rt_comb_internal it is unsigned char |
| 15:24.15 |
brlcad |
d_rossberg:
libmultispectral and other portions of the code use floating point
values for color information |
| 15:24.57 |
brlcad |
for increased
color range/depth and to avoid quantization and aliasing
effects |
| 15:26.35 |
brlcad |
rt_comb_internal's are structures that
predate by quite a bit |
| 15:30.32 |
*** join/#brlcad Briggs
(n=chatzill@adsl-70-238-143-242.dsl.stlsmo.sbcglobal.net) |
| 15:30.43 |
Briggs |
does brlcade
use doubles or floats to represent positions
internally? |
| 15:31.44 |
brlcad |
Briggs:
compile-time toggleable, but doubles |
| 15:32.09 |
brlcad |
nobody has
tried a float compile in over a decade too.. so might not even be
possible to drop it down :) |
| 15:32.12 |
Briggs |
brlcad: thank
you. |
| 15:32.26 |
Briggs |
brlcad: just
curious what other packages are doing since I have been having some
precision problems with floats lately. |
| 15:32.37 |
brlcad |
ah
yeah |
| 15:33.03 |
Briggs |
especially at
extreme scales... |
| 15:33.07 |
brlcad |
we hit
precision problems a *long* time ago.. |
| 15:33.29 |
brlcad |
pre ieee
floating point was notoriously unstable |
| 15:33.52 |
Briggs |
sorting
7kmx7km of map data to find things like intersections and
collinear edges just wasnt behaving nice with floats in the
picture... |
| 15:34.52 |
brlcad |
:) |
| 15:36.04 |
brlcad |
we also use
tuned data structures for certain primitives, integer indexing
where it makes sense for example |
| 15:36.08 |
brlcad |
gridded
data |
| 15:36.13 |
ChiGai |
hello
everyone, my question seem to be a little bit stupid but I still
want to ask |
| 15:36.39 |
brlcad |
like our
height fields (dsps), their raw data is unsigned short integer
ranged data that is positioned in 3space |
| 15:36.45 |
brlcad |
ChiGai: ask
away |
| 15:37.07 |
Briggs |
brlcad:
right, I'm doing similar things. |
| 15:37.11 |
brlcad |
there are no
stupid questions, just stupid people ;) |
| 15:37.20 |
ChiGai |
I am a
mechanic student living in a third world country where a commerical
CAD program cost is several times larger than GDP |
| 15:37.41 |
ChiGai |
so I am
interested in finding a free CAD program, and found about
brl-cad |
| 15:37.53 |
brlcad |
okay,
cool |
| 15:37.54 |
ChiGai |
I don't know
if it is suited for education? |
| 15:38.17 |
ChiGai |
most people
here are using pirated version of Catia, SolidWork
etc... |
| 15:38.26 |
ChiGai |
and I want to
change that |
| 15:38.44 |
_clock_ |
use pirated
version of brl-cad! |
| 15:38.56 |
ChiGai |
_clock_: how
to pirate brl-cad anyway? :D |
| 15:39.01 |
_clock_ |
not possible
:) |
| 15:39.07 |
_clock_ |
function not
implemented :) |
| 15:39.16 |
ChiGai |
:P |
| 15:39.18 |
brlcad |
it involves
wearing a pirate hat and ending a lot of sentances with
arrrrrrrr.... |
| 15:39.52 |
brlcad |
there's a
parrot invovled too, but you don't want to know what you do with
it |
| 15:40.01 |
ChiGai |
:)) |
| 15:40.22 |
ChiGai |
I am building
brl-cad at the moment and eager to try it |
| 15:40.43 |
ChiGai |
oh, done
already |
| 15:41.12 |
brlcad |
ChiGai: we're
chocked full of features and in use in production environments, but
for very specific usage domains with a lot of experts |
| 15:41.27 |
brlcad |
so you'll
find there to be a pretty steep learning curve and lacking
usability |
| 15:41.40 |
brlcad |
things we're
working on improving of course, but it takes a lot of time and
effort |
| 15:42.15 |
brlcad |
particularly
if/when compared with the usability and features in the products of
multibillion dollar companies like those you mentioned
;) |
| 15:42.26 |
ChiGai |
hmm, I don't
intend to do anything advanced so it shouldn't be too
hard |
| 15:42.32 |
brlcad |
we still hold
our own very well though, and pretty much are the best out there
(as open source) |
| 15:42.37 |
brlcad |
if I do say
so myself |
| 15:42.52 |
ChiGai |
and beside I
like banging my head on the wall, doing hard thing |
| 15:43.13 |
brlcad |
there are
pretty extensive tutorials on the website |
| 15:43.58 |
ChiGai |
I
see |
| 15:44.17 |
ChiGai |
thank you for
your answer then :) |
| 15:44.30 |
brlcad |
np |
| 15:44.33 |
ChiGai |
I hope the
situation here will be improved soon |
| 15:44.43 |
brlcad |
and if you
have questions, someone is almost always on here or will eventually
answer |
| 15:44.45 |
ChiGai |
and thank
again for your work on brl-cad |
| 15:45.02 |
brlcad |
though the
answer is often "contributions welcome" ;) |
| 15:45.10 |
ChiGai |
:) |
| 15:45.18 |
brlcad |
we need
developers more than new users (unfortunately) ;) |
| 15:45.26 |
brlcad |
demand is
much greater than supply |
| 15:45.31 |
brlcad |
several
orders.. |
| 15:45.41 |
ChiGai |
I can
understand that |
| 15:46.30 |
ChiGai |
writing CAD
software is pretty hard and need a good, solid team, that also
explain why there aren't many oopen source cad software out there
:( |
| 15:47.02 |
CIA-28 |
BRL-CAD:
03brlcad * r34526 10/brlcad/trunk/src/tclscripts/mged/ (Makefile.am
bots.tcl tclIndex): |
| 15:47.03 |
CIA-28 |
BRL-CAD: add
the 'bots' command (along with 'per_line') to mged for finding
specific |
| 15:47.03 |
CIA-28 |
BRL-CAD:
kinds of bots in an open database as a short term replacement until
'search' can |
| 15:47.03 |
CIA-28 |
BRL-CAD: do
it better. make the commands already deprecated so they can be
removed at |
| 15:47.03 |
CIA-28 |
BRL-CAD: will
when search is enhanced. |
| 15:47.13 |
brlcad |
yep, that's
part of it |
| 15:50.33 |
brlcad |
the magnitude
of work involved to even have basic features is pretty
huge |
| 15:53.19 |
CIA-28 |
BRL-CAD:
03brlcad * r34527 10/brlcad/trunk/TODO: search needs some sort of
-param option to inquire about specific (internal) properties of
objects, like finding dsp with given dimensions, spheres of certain
sizes, bots with a given orientation, etc |
| 15:53.38 |
CIA-28 |
BRL-CAD:
03brlcad * r34528 10/brlcad/trunk/doc/deprecation.txt: bots and
per_line are new and already deprecated. |
| 16:06.04 |
d_rossberg |
brlcad: i'm
using floting point variables for color values in my programs
too |
| 16:06.26 |
d_rossberg |
but region
and rt_comb_internal are closely connected |
| 16:06.40 |
d_rossberg |
and have
diferent representations for color values |
| 16:07.24 |
d_rossberg |
therefore
there is somebody else who writes something into
mater_info? |
| 16:07.57 |
d_rossberg |
eg
libmultispectral |
| 16:13.44 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34529 10/rt^3/trunk/ (2 files in 2
dirs): |
| 16:13.44 |
CIA-28 |
BRL-CAD: a
ray-trace hit now gives you some extra data |
| 16:13.44 |
CIA-28 |
BRL-CAD:
...to be continued... |
| 17:44.23 |
brlcad |
iinteresting,
http://www.mail-archive.com/emc-users@lists.sourceforge.net/msg14339.html |
| 17:44.41 |
brlcad |
wonders if michael is on irc |
| 17:47.21 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FD5B.dip.t-dialin.net) |
| 18:02.14 |
starseeker |
brlcad: do we
need to up the version number to 7.14.9 now? |
| 18:02.35 |
starseeker |
oh,
nevermind |
| 18:02.37 |
starseeker |
I see it
now |
| 18:03.51 |
brlcad |
version
number should always be bumped immediately after tag (or at *least*
immediately after the upload |
| 18:04.17 |
starseeker |
nods. Yeah, I just missed it being updated in the commits -
my bad |
| 18:05.13 |
brlcad |
Elrohir: do
you know michael buesch? |
| 18:06.37 |
CIA-28 |
BRL-CAD:
03bob1961 * r34530 10/brlcad/trunk/ (11 files in 3 dirs): Add
editing for EPA and Particle to libged and Archer. |
| 18:16.57 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178014770.dsl.bell.ca) |
| 18:31.20 |
Elrohir |
brlcad: no
... never heard of that name |
| 18:37.05 |
brlcad |
okay, thanks
:) |
| 18:42.10 |
CIA-28 |
BRL-CAD:
03brlcad * r34531 10/brlcad/trunk/BUGS: |
| 18:42.10 |
CIA-28 |
BRL-CAD:
fastgen plate mode bots seem to be busted for shotlines. they
render just fine, |
| 18:42.10 |
CIA-28 |
BRL-CAD: but
are nirting and rtchecking wrong. have a good sample case with
attached |
| 18:42.10 |
CIA-28 |
BRL-CAD:
detail added as sf bug 2791866 (plate mode bots shotline
incorrectly) |
| 18:43.02 |
CIA-28 |
BRL-CAD:
03brlcad * r34532 10/brlcad/trunk/NEWS: bob continues to add
interactive editing support to archer, now for epa and part
objects. |
| 18:45.37 |
*** join/#brlcad piksi_ (i=piksi@pi-xi.net) |
| 19:01.28 |
CIA-28 |
BRL-CAD:
03brlcad * r34533 10/jbrlcad/trunk/src/org/brlcad/ (11 files in 7
dirs): |
| 19:01.28 |
CIA-28 |
BRL-CAD:
Accept and apply sf patch 2787632 from dave brosius ([patch] minor
cleanup in |
| 19:01.29 |
CIA-28 |
BRL-CAD:
jbrlcad) which applies a lot of lint-style cleanup throughout the
code to mark |
| 19:01.29 |
CIA-28 |
BRL-CAD:
things final, declare overrides, sort imports, cleanup casts, and
more. |
| 19:30.32 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-232-225.dclient.hispeed.ch) |
| 19:42.39 |
*** join/#brlcad test
(n=803f204a@www.intelligentcode.com) |
| 20:00.03 |
*** join/#brlcad andax
(n=andax__@d213-102-41-13.cust.tele2.ch) |
| 20:28.40 |
*** part/#brlcad indianlarry
(n=indianla@bz.bzflag.bz) |
| 21:48.31 |
pacman87 |
here's my
tetris pics: https://webspace.utexas.edu/trv82/www/6811%20Tetris/index.html |
| 21:54.22 |
brlcad |
hehe,
pacman87 how do you distinguish an M from an N ? :) |
| 21:54.48 |
pacman87 |
M only has
one dot in the middle, just above the center |
| 21:54.49 |
brlcad |
thinks maybe need 4x6 glyphs or 4x5 :) |
| 21:54.58 |
pacman87 |
H has the
center dot |
| 21:55.03 |
pacman87 |
W has the
lower dot |
| 21:55.05 |
brlcad |
funny
;) |
| 21:55.10 |
pacman87 |
and U has the
bottom dot |
| 21:56.30 |
pacman87 |
but the way
the LCD works, it's a lot easier to code for 4 px wide letters
(including spaces) |
| 21:57.54 |
pacman87 |
http://pastebin.bzflag.bz/m3a178dbb |
| 21:58.20 |
brlcad |
heh,
neat |
| 21:58.21 |
pacman87 |
that's the
font in 4x6 |
| 21:58.32 |
pacman87 |
including the
spacing top and right |
| 21:59.22 |
pacman87 |
i want to
write a quine with it, but haven't had time with finals |
| 01:01.43 |
*** join/#brlcad jdoliner2
(n=jdoliner@wireless-230-213.uchicago.edu) |
| 01:31.50 |
brlcad |
starseeker:
awesome progress :) |
| 01:35.31 |
brlcad |
~starseeker++ |
| 02:11.34 |
starseeker |
brlcad:
thanks! :-) |
| 02:11.42 |
starseeker |
next up,
trimming |
| 02:13.33 |
starseeker |
or more
specifically, trimming + bounding volume hierarchy |
| 03:26.00 |
*** join/#brlcad madant__
(n=madant@117.196.136.182) |
| 07:09.45 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 10:05.09 |
*** join/#brlcad indianlarry
(n=indianla@bz.bzflag.bz) |
| 10:07.08 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:08.26 |
indianlarry |
~/whois |
| 11:21.07 |
*** join/#brlcad madant_
(n=madant@117.196.130.253) |
| 11:34.38 |
brlcad |
yawns |
| 11:43.23 |
alex_joni |
O prostituata
merge la ginecolog... |
| 11:43.23 |
alex_joni |
Acesta o
intreaba: |
| 11:43.24 |
alex_joni |
- Domnisoara,
aveti pierderi mari in timpul menstruatiilor? |
| 11:43.34 |
alex_joni |
eek.. sorry,
wrong paste :/ |
| 11:43.41 |
brlcad |
heh |
| 11:43.57 |
brlcad |
what an odd
paste at that :) |
| 11:44.44 |
indianlarry |
flashes back to catholic school |
| 11:45.06 |
alex_joni |
brlcad:
that's part of a joke in my native language |
| 11:46.37 |
d-lo_ |
Hrm, I see
prostitue, gynocologist and menstration.... I probably don't wan't
to hear the actual joke based on that.... |
| 11:47.47 |
archivist |
clean safe
laugh
http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html |
| 11:59.12 |
d-lo_ |
hah, thats
pretty good :) |
| 12:06.10 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 12:15.58 |
madant |
hadn't heard of Scala :O |
| 12:41.07 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 13:07.11 |
``Erik |
heh,
archiviist: that was on hn a few days back :) |
| 13:11.27 |
``Erik |
hm,
starseeker, that java vuln I mentioned yesterday went up on /. this
morning |
| 13:12.05 |
starseeker |
``Erik: yeah,
saw that |
| 13:12.09 |
starseeker |
turned it off |
| 13:12.33 |
starseeker |
madant: Oh,
the lisp in lisp thing? Yeah, it doesn't get a lot of
press |
| 14:12.43 |
brlcad |
heh |
| 14:13.14 |
brlcad |
"Oh, * lisp
*? Yeah, it doesn't get a lot of press" :) |
| 14:13.37 |
brlcad |
loves lisp, but it's not exactly ever going to be
"mainstream" |
| 14:14.53 |
starseeker |
must concede that |
| 14:15.53 |
madant |
is checking out wattzon.com |
| 14:23.27 |
``Erik |
seems to have
had a resurgance the last few years, though |
| 14:25.26 |
_clock_ |
http://img522.imageshack.us/img522/599/yogadz6.jpg |
| 14:26.00 |
brlcad |
http://www.ohloh.net/languages/compare?measure=commits&percent=&l0=emacslisp&l1=lisp&l2=scheme&l3=-1&l4=-1&commit=Update |
| 14:26.04 |
brlcad |
that's pretty
"steady" |
| 14:26.18 |
``Erik |
wait, vodka
makes me do yoga? awesome, it's healthy for ya! :D |
| 14:26.35 |
_clock_ |
``Erik:
right |
| 14:27.10 |
``Erik |
the new lisps
aren't usually called lisp, though... they go with funny names like
clojure and arc |
| 14:27.53 |
``Erik |
(and it's
scattered and often using a variety of odd vcs's if any, so ohloh
won't pick it up well) |
| 14:27.55 |
``Erik |
*shrug* |
| 14:28.31 |
brlcad |
ohloh's
language parser would see them as lisp |
| 14:28.58 |
``Erik |
how does
ohloh find projects to add? |
| 14:29.03 |
brlcad |
and the fact
that it's scattered and obscure doesn't really help your point
:) |
| 14:29.04 |
madant |
what
percentage of the world's code base right now would be open source
;) |
| 14:29.22 |
starseeker |
madant: a
minute fraction |
| 14:29.38 |
brlcad |
at least,
perhaps we define "resurgance" quite differently :) |
| 14:29.54 |
CIA-28 |
BRL-CAD:
03bob1961 * r34568 10/brlcad/trunk/src/ (libged/scale_hyp.c
tclscripts/archer/HypEditFrame.tcl): Added scale H (move V) editing
capability for hyperboloid. This affects libged and
Archer. |
| 14:30.22 |
``Erik |
from the
forum/blog/newsgroup/irc/packagegrowth/etc perspective, it's grown
a huge amount over 5 years *shrug* |
| 14:30.56 |
``Erik |
but it's an
ugly nonunified world, MOST work is just "here's a tarball" on a
site and maybe a registry in cliki if you're lucky |
| 14:31.02 |
brlcad |
I think
that's probably just because it's what you're reading (because it's
interesting to you) |
| 14:31.28 |
``Erik |
if there is a
public vcs, it's darcs on this random machine, or git on that one,
or something else over there |
| 14:32.02 |
``Erik |
*shrug* but
I've been interested in it for 10 years now... :) |
| 14:33.09 |
brlcad |
fwiw to
answer your question -- if it has a public vcs, anyone can add it
to ohloh |
| 14:33.23 |
``Erik |
so it has to
be manually added? |
| 14:33.36 |
brlcad |
by someone
that cares, sure |
| 14:33.43 |
brlcad |
they don't go
scraping around for projects |
| 14:34.13 |
``Erik |
imagines 95+% of the lithp world doesn't care about ohloh :)
(most probably haven't even heard of it) |
| 14:34.20 |
``Erik |
but that's
pure conjecture |
| 14:35.03 |
brlcad |
conjects that 95% of the lisp world doesn't even amount to a
1% difference in those stats |
| 14:35.49 |
brlcad |
law of
averages, it's not like the ones on there do care |
| 14:35.58 |
``Erik |
might be
amusing to write a script to scrape all the lisp repo locations off
of few dozen 'central' locations and add them |
| 14:42.44 |
_clock_ |
Is BRL-CAD
Turing-complete? |
| 14:42.49 |
_clock_ |
I think it
should be. |
| 14:42.53 |
``Erik |
tcl
is |
| 14:55.20 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 14:56.30 |
CIA-28 |
BRL-CAD:
03brlcad * r34569 10/brlcad/trunk/src/librt/primitives/mirror.c:
stub in the new mirror calls for all of the rest of the primitives,
change indentation on the old sections |
| 15:10.07 |
``Erik |
wonders if brlcad is on the way in, or working from
home |
| 15:33.03 |
*** join/#brlcad madant_
(n=madant@117.196.130.253) |
| 15:44.10 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
| 15:44.21 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
| 15:44.52 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:45.07 |
elena |
hi. |
| 15:49.09 |
d-lo_ |
hai! |
| 15:49.32 |
elena |
hi
d-lo |
| 15:53.47 |
brlcad |
hola
elena |
| 15:54.00 |
elena |
hi
Sean. |
| 15:54.00 |
brlcad |
``Erik: in,
but no lunch |
| 15:54.22 |
elena |
bon
appetit! |
| 15:54.36 |
brlcad |
elena: how's
summer looking so far? :) |
| 15:54.47 |
elena |
interesting. |
| 15:54.58 |
elena |
challenging |
| 15:55.02 |
elena |
fun. |
| 15:55.06 |
brlcad |
well that's
good! |
| 15:55.16 |
elena |
yes. |
| 15:55.39 |
brlcad |
have to get
you set up soon |
| 15:56.14 |
elena |
anything I
can help with? |
| 15:57.34 |
brlcad |
probably |
| 15:57.49 |
elena |
just let me
know. |
| 15:58.08 |
*** join/#brlcad alvaro1
(n=alvaro@190.77.167.45) |
| 15:58.17 |
elena |
I'll also
catch up with Cliff. |
| 15:58.46 |
elena |
I was away
lately. |
| 15:58.56 |
brlcad |
nods |
| 15:58.56 |
elena |
in norway
:) |
| 15:59.06 |
brlcad |
sounds like
fun :) |
| 15:59.17 |
brlcad |
details in pm
for setup |
| 16:00.16 |
d-lo_ |
whereabouts
in Norway? |
| 16:03.25 |
alvaro1 |
[root@alvaro-edicta-host brlcad-7.14.6]#
./configure --enable-optimized |
| 16:03.25 |
alvaro1 |
configure:
error: cannot find install-sh or install.sh in misc
./misc |
| 16:03.43 |
brlcad |
alvaro1: you
ran autogen.sh ? |
| 16:03.48 |
alvaro1 |
no |
| 16:04.09 |
brlcad |
run
it |
| 16:05.17 |
alvaro1 |
sh autogen.sh
gives me this ERROR: Unable to locate GNU Autoconf. |
| 16:06.34 |
alvaro1 |
should i
install this?: autoconf.noarch : A GNU tool for automatically
configuring source code |
| 16:06.37 |
starseeker |
alvaro1:
well, step one is to install it :-) |
| 16:06.41 |
starseeker |
yep |
| 16:07.01 |
starseeker |
make sure
automake is in there too |
| 16:07.16 |
starseeker |
or rather, in
PATH |
| 16:07.39 |
alvaro1 |
there are two
choices: autoconf.noarch : A GNU tool for automatically configuring
source code , autoconf213.noarch : A GNU tool for automatically
configuring source code |
| 16:08.06 |
starseeker |
I'd go with
plain autoconf |
| 16:14.59 |
alvaro1 |
starseeker:
(libedit.i386 : The NetBSD Editline library) is equivalent to
libtoolize ? |
| 16:15.13 |
starseeker |
no, I don't
think so |
| 16:16.07 |
starseeker |
look for an
autotools package, if there is one |
| 16:16.36 |
alvaro1 |
http://fpaste.org/paste/12422 |
| 16:17.34 |
brlcad |
libedit is
equivalent to the gnu readline library .. nothing to do with
libtool |
| 16:17.36 |
starseeker |
which
OS/distro are you on? |
| 16:17.44 |
brlcad |
libedit is
cool, we should be using it |
| 16:17.49 |
starseeker |
:-) |
| 16:18.11 |
starseeker |
hasn't checked - do we get tab completion/history for free
using that? |
| 16:24.19 |
alvaro1 |
<PROTECTED> |
| 16:26.11 |
brlcad |
alvaro1: you
have to run autogen.sh successfully |
| 16:26.21 |
brlcad |
until that
happens, you cannot run configure |
| 16:26.23 |
brlcad |
so stop
trying :) |
| 16:27.08 |
alvaro1 |
http://fpaste.org/paste/12423 |
| 16:29.02 |
alvaro1 |
and libedit
is installed but autogen.sh keeps on reporting the error about
libtoolize |
| 16:29.47 |
brlcad |
alvaro1:
12:21 <@brlcad> libedit is equivalent to the gnu readline
library .. nothing to do with libtool |
| 16:29.52 |
brlcad |
did you miss
that? |
| 16:31.33 |
alvaro1 |
brlcad but
autogen.sh is asking for libtoolize and when i search on the repos
the only thing that appears is libedit |
| 16:32.02 |
brlcad |
sounds like
you need to do some searching then for your platform |
| 16:34.19 |
alvaro1 |
brlcad:
libedit.i386 is equivalent to libtoolized on fedora see this:
http://fpaste.org/paste/12426 |
| 16:35.41 |
elena |
hi
starseeker. brlcad just setup my account. |
| 16:39.07 |
alvaro1 |
libtool.i386
seems to be working |
| 16:43.02 |
brlcad |
alvaro1: you
are totally misunderstanding that description |
| 16:43.38 |
brlcad |
libedit IS
NOT libtool .. read the rest of the description, search online for
libtool and read it's description .. they are very different
projects |
| 16:44.17 |
brlcad |
elena: so ..
what's "step one"? |
| 16:46.10 |
elena |
i'll take a
look at the current setup. |
| 16:46.24 |
elena |
also you
mentioned problems with captcha. are they solved? |
| 16:46.36 |
brlcad |
nope |
| 16:46.59 |
elena |
maybe I could
take a shoot at that first... |
| 16:47.32 |
brlcad |
elena: your
project (the repository aspect) has a nice benefit that it can
somewhat start with a clean slate |
| 16:48.24 |
brlcad |
that would be
cool -- fixing the captcha problem on the contact form would
certainly take off one headache :) |
| 16:48.39 |
elena |
can you
rephrase "slate". I don't understand it. |
| 16:48.48 |
brlcad |
mm a "fresh"
start |
| 16:48.53 |
brlcad |
a blank piece
of paper |
| 16:48.54 |
elena |
aha. |
| 16:49.23 |
elena |
then next
step would be to find a theme. |
| 16:49.34 |
elena |
something in
tone with brlcad.org. |
| 16:49.48 |
brlcad |
brlcad.org's
theme is bound to change, don't worry about it |
| 16:50.07 |
elena |
ook. |
| 16:50.10 |
brlcad |
it just needs
to be clean and asthetically pleasing ;) |
| 16:50.15 |
brlcad |
"just"
:) |
| 16:51.18 |
d-lo_ |
yes. Eye
trauma == bad |
| 16:53.21 |
brlcad |
as for the
location, can either go with more.brlcad.org or .. |
| 16:53.26 |
brlcad |
I've also had
solidgeometry.org registered for a while after some discussions at
the ACM solid modeling conference a couple years ago, that could be
used |
| 16:53.43 |
brlcad |
or
[whatever].brlcad.org really |
| 17:01.38 |
brlcad |
my goal is to
end up at solidgeometry.org so that the repository can have its own
identity, community, policies, and such |
| 17:01.56 |
brlcad |
sort of a
separation of model/view and controller in MVC lingo :) |
| 17:02.16 |
brlcad |
also doesn't
mean we have to start there either though |
| 17:08.13 |
elena |
i'd go with
more. for now. |
| 17:08.24 |
elena |
maybe
solidgeometry could be more general. |
| 17:08.51 |
elena |
a next
step. |
| 17:10.04 |
brlcad |
okay, sounds
good |
| 17:10.11 |
elena |
great. |
| 17:25.41 |
brlcad |
elena: clean
slate: http://more.brlcad.org/ |
| 17:25.54 |
elena |
:)
thanks. |
| 17:26.41 |
brlcad |
cliff can
help out with logging in, navigating, transferring files,
etc |
| 17:27.12 |
elena |
i'll try to
do it myself first. |
| 18:00.25 |
alvaro1 |
it is
necessary run "make test" ? |
| 18:01.07 |
alvaro1 |
is it
necessary run "make test" ? |
| 18:03.05 |
elena |
maybe not,
but it is a good idea to do it. |
| 18:06.50 |
alvaro1 |
and "make
benchmark" ? |
| 18:11.37 |
starseeker |
only if you
want to test your system's performance |
| 18:15.09 |
alvaro1 |
what comes
after make , make test, and make benchmark ? |
| 18:15.47 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-2.sbndin.btas.verizon.net) |
| 18:17.11 |
alvaro1 |
what comes
after "make" , "make test", "make benchmark", and "make clean",
? |
| 18:17.31 |
starseeker |
uh - why did
you do make clean? |
| 18:17.55 |
starseeker |
if you're
trying to install BRL-CAD, it's make and then make
install |
| 18:17.55 |
elena |
I was going
to suggest not to make clean. |
| 18:18.21 |
alvaro1 |
what do i do
now ? i did make clean |
| 18:18.58 |
elena |
run again.
make and make install |
| 18:19.11 |
alvaro1 |
sure? |
| 18:19.24 |
starseeker |
that's
standard for GNU autotools builds |
| 18:19.25 |
elena |
starseeker? |
| 18:20.05 |
starseeker |
alvaro1: have
you read the INSTALL file? |
| 18:20.20 |
starseeker |
elena: hey
elena |
| 18:20.28 |
elena |
hi. |
| 18:20.34 |
starseeker |
how are
things going? |
| 18:20.39 |
alvaro1 |
starseeker:
yes but the command line is giving instructions too |
| 18:20.39 |
elena |
great. |
| 18:20.46 |
starseeker |
:-) |
| 18:20.51 |
elena |
i just got an
account on brlcad.org |
| 18:21.17 |
starseeker |
alvaro1: The
standard install procedure is ./configure && make and then
as root make install |
| 18:21.32 |
starseeker |
alvaro1: I
take it this is the first time you've compiled software on your
machine? |
| 18:21.37 |
elena |
i'll look
around for the setup and then bug you with any question I have
:) |
| 18:21.49 |
alvaro1 |
well i am
runing make install, first time |
| 18:21.53 |
starseeker |
elena: cool
:-) |
| 18:22.20 |
starseeker |
alvaro1: OK.
If you get any permissions errors on make install, it means you're
not in the root account |
| 18:22.37 |
alvaro1 |
i am logged
as root |
| 18:22.47 |
starseeker |
ok. It
should work then |
| 18:35.37 |
brlcad |
alvaro1: yet
you're also making up your own instructions |
| 18:36.47 |
brlcad |
make clean is
not mentioned anywhere in the INSTALL file or the instructions that
are prompted after each build step |
| 18:36.55 |
brlcad |
those
instructions match up, you're not following either of
them |
| 18:38.03 |
brlcad |
read the
INSTALL instructions and follow them -- the quick instructions are
particularly relevant |
| 18:39.03 |
alvaro1 |
well after
make install stops i will go back if necessary, do yo suggest to
interrupt "make install" ? |
| 18:39.54 |
brlcad |
no |
| 18:40.05 |
brlcad |
if make
install works, you should be done |
| 18:40.28 |
alvaro1 |
ok let's see
the result... |
| 18:40.46 |
brlcad |
look at the
instructions, follow after the "Once installed, ....."
section |
| 18:41.07 |
brlcad |
that should
help |
| 18:54.28 |
alvaro1 |
in the
INSTALL file ? |
| 18:55.39 |
brlcad |
that would be
the installation instructions |
| 19:29.08 |
alvaro1 |
how do i add
PATH=/usr/brlcad/bin:$PATH ; export PATH to the path permanently
? |
| 19:33.30 |
brlcad |
alvaro1: do
you have a .profile in your home directory? |
| 19:33.36 |
alvaro1 |
yes |
| 19:33.47 |
brlcad |
what's in
it? |
| 19:33.53 |
alvaro1 |
let me
see |
| 19:35.20 |
alvaro1 |
no i do not
have a .profile on my home directory |
| 19:40.25 |
brlcad |
ls -la
.profile that returns nothing? |
| 19:41.02 |
brlcad |
run this:
echo "" >> .profile && echo
"PATH=/usr/brlcad/bin:$PATH ; export PATH" >>
.profile |
| 19:41.19 |
brlcad |
then open a
new terminal -- the path should be set |
| 19:41.26 |
brlcad |
can check it
with "echo $PATH" |
| 19:43.18 |
alvaro1 |
if i open
gedit and paste "PATH=/usr/brlcad/bin:$PATH ; export PATH" and save
it as .profile in my home directory will work too? |
| 19:43.32 |
brlcad |
without the
quotes |
| 19:43.35 |
brlcad |
sure |
| 19:43.56 |
brlcad |
might need to
run: chmod 755 ~/.profile |
| 19:46.31 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 19:47.59 |
alvaro1 |
it is not
working for some reason please see: http://fpaste.org/paste/12447 |
| 19:50.14 |
brlcad |
assuming you
put it into the right place, that looks right |
| 19:50.32 |
alvaro1 |
yes it is at
home |
| 19:50.35 |
brlcad |
note that's a
root shell, you have to open a new user shell |
| 19:50.53 |
brlcad |
also check to
see if you have a .bash_profile |
| 19:52.20 |
alvaro1 |
i have a
.bash_profile http://fpaste.org/paste/12450 |
| 19:52.29 |
brlcad |
so put it in
there |
| 19:52.47 |
brlcad |
you already
have a path line in there even |
| 19:58.03 |
alvaro1 |
michael jhon
mush had a great smile! |
| 20:01.28 |
brlcad |
he did
:) |
| 20:08.42 |
alvaro1 |
brlcad:
thanks i'll try to upload binarys, but i am going to explore brlcad
first, it is running on fedora 10 |
| 20:33.58 |
CIA-28 |
BRL-CAD:
03brlcad * r34570
10/brlcad/trunk/src/librt/primitives/tor/tor_mirror.c: unused
var |
| 20:41.40 |
*** join/#brlcad elite01_
(n=omg@unaffiliated/elite01) |
| 20:42.57 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 21:06.47 |
``Erik |
heh |
| 21:07.09 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34571 10/brlcad/trunk/ (NEWS src/mged/mged.c):
Added -v to command line mged for version information. |
| 21:09.29 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34572 10/brlcad/trunk/
(doc/docbook/system/man1/en/mged.xml src/mged/mged.c): Document the
-v argument. |
| 21:31.56 |
CIA-28 |
BRL-CAD:
03brlcad * r34573 10/brlcad/trunk/src/librt/ (Makefile.am
primitives/tgc/tgc_mirror.c): separate out the tgc mirroring for
the guts to rt_tgc_mirror() |
| 21:33.47 |
CIA-28 |
BRL-CAD:
03brlcad * r34574 10/brlcad/trunk/src/librt/primitives/mirror.c:
turn on tor and tgc/rec mirroring through the new routines sans
debugging, remove the old. |
| 21:35.12 |
CIA-28 |
BRL-CAD:
03brlcad * r34575 10/brlcad/trunk/src/librt/primitives/mirror.c:
bah, fix the preprocessor logic. helps to compile
first. |
| 22:37.16 |
``Erik |
hehehe, I
wonder if I messed up the slushbox doing that :D |
| 23:26.37 |
*** join/#brlcad jdoliner
(n=jdoliner@wireless-194-193.uchicago.edu) |
| 23:37.16 |
brlcad |
howdy
jdoliner |
| 23:46.09 |
*** join/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 23:46.59 |
rincon |
what i see in
the help is the mged classic, where can see the help of the new
GUI |
| 23:53.50 |
brlcad |
rincon: what
do you mean? |
| 23:54.14 |
brlcad |
rincon:
there's extensive tutorials on the website |
| 23:54.18 |
brlcad |
under
documentation |
| 23:54.32 |
rincon |
the images on
the local manual seems so differrent than the gui |
| 23:55.14 |
brlcad |
latest docs
are the mged tutorial series, pdfs on the website |
| 23:55.23 |
brlcad |
the ones that
are locally installed are older |
| 23:55.33 |
brlcad |
still valid,
but yeah different |
| 23:56.20 |
rincon |
ok then it is
better to look at the website... |
| 00:17.32 |
rincon |
can i export
to dxf format from brlcad ? |
| 00:19.00 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 00:25.12 |
*** part/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 00:29.11 |
starseeker |
glowers at shape1 |
| 00:31.47 |
starseeker |
dreeves__: Do
you happen to know if face->Loop(0) returns a trimming curve or
the "outer" curve per the http://en.wiki.mcneel.com/default.aspx/McNeel/opennurbsfaq
Trimming loop entry? |
| 00:42.40 |
starseeker |
dreeves__:
You're probably aware of these, but just in case: http://www.uni-koblenz.de/~cg/Diplomarbeiten/DA_Oliver_Abert.pdf |
| 00:44.24 |
brlcad |
starseeker:
fwiw, that url is also src/other/openNURBS/faq.txt |
| 00:44.31 |
brlcad |
starseeker:
Loop() should be a trimming curve |
| 00:44.36 |
brlcad |
OuterLoop()
will return the outer |
| 00:44.37 |
starseeker |
brlcad: oh,
sorry |
| 00:44.43 |
starseeker |
brlcad: cool,
thanks |
| 00:45.16 |
starseeker |
thinks he is slowly getting a handle on what they want to do
to trim |
| 00:47.18 |
starseeker |
Ah, you're
referring to the mcneel faq |
| 00:47.25 |
starseeker |
thought you ment the thesis |
| 00:47.42 |
starseeker |
really should be updating the BRL-CAD bib file with all of
these nurbs papers |
| 00:48.02 |
starseeker |
might be time
to pause tomorrow and do that |
| 00:48.09 |
starseeker |
I think I'm
gonna need 'em |
| 00:49.42 |
starseeker |
dreeves__:
also, http://nis-lab.is.s.u-tokyo.ac.jp/nis/cdrom/sig90_nis.pdf |
| 00:50.48 |
starseeker |
dreeves__:
the DA_Oliver_Abert thesis addresses trimming in some detail in
section 5.4 |
| 00:59.26 |
``Erik |
brlcad: did
you even hear the revving? I was snickering all the way off post
:) |
| 01:06.06 |
brlcad |
was that what
that was? :) |
| 01:06.18 |
brlcad |
thought maybe
had a hole in the muffler |
| 01:13.18 |
brlcad |
starseeker:
since you mentioned nishita's paper, keep in mind that we're
intentionally not doing a surface decomposition to bezier surface
patches |
| 01:14.02 |
brlcad |
instead
evaluating the nurbs surface directly |
| 01:14.59 |
``Erik |
heh, no, I
slipped it in neutral in the intersection and tried to rev it a
couple times (very unresponsive throttle), then popped it back in
drive |
| 01:38.21 |
*** join/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 01:41.47 |
rincon |
how do you
draw a circle ? |
| 01:44.03 |
brlcad |
rincon: 3d
primitives |
| 01:44.26 |
brlcad |
something
circular is the base of a right-circular cylinder (rcc
primitive) |
| 01:44.36 |
brlcad |
or a tgc or
an rec |
| 01:44.47 |
brlcad |
examples in
the back of volume two |
| 01:45.34 |
rincon |
brlcad has
object snaping ? |
| 01:49.05 |
brlcad |
that's
related to one of the gsoc projects (constraint resolution), until
then you'll have to be explicit |
| 01:53.07 |
rincon |
i
understand |
| 02:45.50 |
starseeker |
brlcad:
right. The algorithm appears to be adapted to do the uv space
trimming (the trims being bezier curves) |
| 02:49.17 |
starseeker |
is currently trying to figure out how to get the uv space
control points out of the trim curve |
| 03:15.06 |
*** part/#brlcad rincon
(n=alvaro@190.77.167.45) |
| 03:15.13 |
dreeves__ |
starseeker it
is the outer curve |
| 03:15.52 |
dreeves__ |
all the loops
after 0 are holes or inner loops |
| 04:22.28 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 04:27.02 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
| 04:27.03 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 04:32.04 |
*** join/#brlcad starseek1r
(n=starseek@bz.bzflag.bz) |
| 07:12.07 |
*** join/#brlcad _sushi_
(n=_sushi_@80-219-41-21.dclient.hispeed.ch) |
| 07:44.17 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
| 08:49.07 |
*** join/#brlcad elena (n=opera@92.86.0.28) |
| 09:34.43 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:11.43 |
*** join/#brlcad indianlarry
(n=indianla@bz.bzflag.bz) |
| 10:15.41 |
*** join/#brlcad _sushi__
(n=_sushi_@77-58-225-59.dclient.hispeed.ch) |
| 11:04.44 |
*** join/#brlcad mafm_
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 12:04.16 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-2.sbndin.btas.verizon.net) |
| 12:36.21 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
| 12:57.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-2.sbndin.btas.verizon.net) |
| 13:18.01 |
CIA-28 |
BRL-CAD:
03bob1961 * r34576 10/brlcad/trunk/src/libged/pscale.c: Include the
command name in error messages. |
| 13:38.43 |
brlcad |
dreeves__:
really? |
| 13:38.48 |
brlcad |
re-reads |
| 13:44.07 |
brlcad |
ahh, I see
now, conventionally it is to be considered valid -- the structure
doesn't require it, nor does Loop() and OuterLoop() scans also not
caring .. but then IsValidFace() insists that [0] has m_type
outer |
| 14:23.39 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 15:02.16 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:44.19 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 17:27.09 |
CIA-28 |
BRL-CAD:
03bob1961 * r34577 10/brlcad/trunk/ (16 files in 6 dirs): Added the
ability to rotate primitive (i.e. eto, hyp and tgc for now)
parameters. |
| 17:28.55 |
*** join/#brlcad jdoliner
(n=jdoliner@98.227.157.38) |
| 17:33.22 |
jdoliner |
indian
larry? |
| 17:47.56 |
brlcad |
jdoliner:
howdy joe |
| 17:48.10 |
brlcad |
looks like
you two just may finally be able to sync up :) |
| 17:48.24 |
jdoliner |
we've been
emailing a bit... |
| 17:48.26 |
brlcad |
also,
highlighting works much better if you don't inject a space
;) |
| 17:48.41 |
jdoliner |
indianlarry |
| 17:48.43 |
indianlarry |
jdoliner: hey
joe how's it going |
| 17:48.51 |
jdoliner |
hi |
| 17:48.55 |
brlcad |
should be
chattering on the brlcad-devel list if it's related to the task so
others are aware of what's up/planned |
| 17:48.58 |
``Erik |
rolls around and pops |
| 17:49.04 |
brlcad |
but good to
hear regardless |
| 17:49.51 |
brlcad |
private
chatter should really only be for time-tracking or personal
issues |
| 17:49.52 |
jdoliner |
so I
mentioned in my application that I have a slightly unorthodox
school schedule |
| 17:50.16 |
indianlarry |
you plan on
starting later in june? |
| 17:50.27 |
jdoliner |
I did
originally |
| 17:50.48 |
brlcad |
what's your
schedule look like now? |
| 17:50.57 |
jdoliner |
but my course
load is such that I feel confident starting earlier |
| 17:51.09 |
indianlarry |
cool |
| 17:51.20 |
``Erik |
what's
unorthodox about scheduling the classes around the parties and
co-scheduling sleep and study/homework? :D |
| 17:51.21 |
jdoliner |
I just might
not be at quite full steam until early june |
| 17:52.03 |
jdoliner |
but I have a
few logistic questions |
| 17:52.03 |
``Erik |
neat, I made
indianlarry "lol" |
| 17:52.26 |
jdoliner |
first where
in the code base should my code go? |
| 17:54.45 |
``Erik |
what about
making it a command in src/libged/ ? |
| 17:55.05 |
jdoliner |
because all I
plan to interact with is the openNurbs library |
| 17:55.39 |
``Erik |
then how will
you call it? |
| 17:56.27 |
indianlarry |
Erik
mentioned that there is a facetize command that takes a CSG and
creates a bot/nmg object |
| 17:56.59 |
indianlarry |
something
like that for the csg evaluation would be a nice start |
| 17:58.05 |
``Erik |
r nurbs.r u
nurb1.s u nurb2.s; beval mynurb.r nurbs.r |
| 17:58.49 |
jdoliner |
well perhaps
it's unfeasible, but what I meant by that is it'd be nice if the
code was portable enough that other projects using openNurbs could
run it |
| 17:59.25 |
jdoliner |
of course
it'll interact by being called |
| 18:00.39 |
indianlarry |
brlcad: you
listening |
| 18:01.09 |
jdoliner |
libged seems
like the most obvious place to put this |
| 18:01.43 |
jdoliner |
since it
seems to me like it's obviously part of the editor |
| 18:03.51 |
``Erik |
*ponder*
src/other/libbrepeval/ ? src/libged/brepeval/ ?
src/libged/brep_eval_xxx.c (and lose coupling to the rest of
libged) ? *shrug* |
| 18:05.13 |
indianlarry |
jdoliner: so
you'll be finished by weeks end
;^)>>>>>> |
| 18:05.52 |
``Erik |
(I'd imagine
that the actual location of the code has little to do with the
coupling to other stuff in the directory and the pertinent files
could be easily pulled and used elsewhere?) |
| 18:06.01 |
jdoliner |
indianlarry:
of course :P |
| 18:06.27 |
jdoliner |
``Erik: true,
these are really two different issues |
| 18:09.35 |
starseeker |
OK, so the
trimming curves are nurbs curves, NOT bezier curves |
| 18:09.35 |
starseeker |
important to
know |
| 18:09.55 |
indianlarry |
starseeker:
in their own param space? |
| 18:11.00 |
starseeker |
In the param
space of the surface they are in, if I'm not mistaken |
| 18:21.02 |
brlcad |
indianlarry:
always, just not necessarily interactively ;) |
| 18:21.36 |
brlcad |
jdoliner: I'd
expect libged to just be a wrapper to some (non-libged, probably
librt) library routine |
| 18:21.54 |
indianlarry |
brlcad: i
think joe is okay putting it into libged |
| 18:22.33 |
brlcad |
right, but
that it doesn't really belong there |
| 18:22.49 |
brlcad |
libged ==>
command |
| 18:23.00 |
brlcad |
there does
need to be a command, but that routine is needed elsewhere
too |
| 18:23.04 |
indianlarry |
librt? |
| 18:23.16 |
indianlarry |
other? |
| 18:23.19 |
brlcad |
yeah, means
it belongs lower-level ala librt |
| 18:23.28 |
brlcad |
no, other is
only for 3rd party codes that we don't maintain |
| 18:25.19 |
brlcad |
also while it
will be nice to have it generalized for other packages, but that's
certainly not the priority |
| 18:25.29 |
brlcad |
would be
great to have but shouldn't hinder the goal |
| 18:25.34 |
brlcad |
integrating
it as a facility for librt routines to use it is the priority
focus |
| 18:25.50 |
brlcad |
so we can
tessellate implicits reliably (for shaded displays) |
| 18:33.33 |
*** join/#brlcad madant
(n=madant@117.196.131.101) |
| 18:39.41 |
brlcad |
jdoliner: the
biggest implementation issue is dependency management, and what
ends up being needed to make the evaluation work -- whether your
implementation only depends on openNURBS or libbu or libbn or librt
or some combination thereof |
| 18:40.53 |
brlcad |
a good
similar example of integration (wrt libged) is the bot_smooth
command, src/libged/bot_smooth.c which basically calls
rt_bot_smooth() from librt |
| 18:52.34 |
brlcad |
starseeker:
my stable here says .8 |
| 18:52.40 |
starseeker |
same
here |
| 18:53.13 |
brlcad |
howdy
madant |
| 19:00.21 |
CIA-28 |
BRL-CAD:
03starseeker * r34578
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Add code to
dump text summary of trimming curves - useful if there is interest
in the exact nature of a particular trimming curve. |
| 19:00.25 |
madant |
hi
brlcad |
| 19:01.16 |
madant |
seems like my
laptop is gonna take more time to get fixed up.. i will have to
think about installing debian on this p3 .. |
| 19:01.30 |
madant |
and so much
work to do .. |
| 19:01.38 |
madant |
is scared |
| 19:01.51 |
brlcad |
no
fun |
| 19:02.17 |
madant |
no fun at
all.. i remember 2.5 hour compile time of brl-cad during last
summer when i tried :( |
| 19:02.29 |
brlcad |
heh, that's
aweful |
| 19:02.39 |
brlcad |
you'd be
better on working remote on a fast server :) |
| 19:02.57 |
brlcad |
could probably arrange that |
| 19:03.15 |
madant |
that'd be
aaaaaaaaawesome |
| 19:03.25 |
brlcad |
not quite as
satisfying as hearing the laptop heat up, but certainly more
productive :) |
| 19:03.34 |
madant |
would a 512
kbps connection be enough ? |
| 19:04.11 |
brlcad |
don't see why
not |
| 19:04.27 |
madant |
great.. what
do i need to do :) |
| 19:04.50 |
brlcad |
mm, i'll see
if I can get an account created on something reasonably
fast |
| 19:04.57 |
brlcad |
might take a
day |
| 19:05.08 |
madant |
no problem..
i need to write much on the wiki before that .. |
| 19:05.54 |
madant |
how are my
co-gsocers :) |
| 19:06.00 |
CIA-28 |
BRL-CAD:
03brlcad * r34579 10/brlcad/trunk/src/librt/ (6 files in 5 dirs):
separate out and define rt_ell_mirror() |
| 19:08.11 |
brlcad |
haven't heard
much from pacman87 or Ralith lately, but the others seem to be
getting prepared |
| 19:08.26 |
Ralith |
waves |
| 19:08.42 |
brlcad |
heh, yeah him
:) |
| 19:08.55 |
Ralith |
school is
taking a little more time than I had expected, unfortunately. That
shouldn't be a problem for long though. |
| 19:09.06 |
brlcad |
when is the
semester over? |
| 19:09.20 |
Ralith |
in about
three weeks, but the workload will lighten before then. |
| 19:10.23 |
madant |
i wish
everyone had the same time table.. |
| 19:10.28 |
Ralith |
yeah. |
| 19:10.30 |
madant |
well on
second thoughts .. maybe not |
| 19:10.52 |
madant |
:) talk about
too crowded travel destinations, internships .. the whole
mess |
| 19:10.56 |
Ralith |
hehe |
| 19:11.16 |
Ralith |
actually, the
only immediate time sink I have right now is a linear algebra
take-home final. |
| 19:12.23 |
madant |
used to love matrices :) |
| 19:12.56 |
Ralith |
I've found
the course to be very fun. |
| 19:12.58 |
madant |
what's the
final topic in ur linear algebra course ? |
| 19:13.11 |
Ralith |
lots of neat
stuff even at the entry level |
| 19:13.13 |
Ralith |
final
topic? |
| 19:13.18 |
Ralith |
uhhhh |
| 19:13.32 |
Ralith |
the final
itself covers the whole course, but the last topic I studied
was... |
| 19:13.34 |
madant |
i meant the
last major section .. whatever you call it :) |
| 19:14.23 |
Ralith |
quadratic
forms |
| 19:15.48 |
Ralith |
ocrap, looks
like google still needs some paperwork from me. |
| 19:16.07 |
madant |
<PROTECTED> |
| 19:16.12 |
Ralith |
not
yet |
| 19:16.18 |
Ralith |
really needs to keep better track of his
email |
| 19:16.18 |
madant |
ah.. |
| 19:16.47 |
madant |
remembers his last lecture in Linear Algebra was on
SVD |
| 19:17.47 |
madant |
i guess we
all just got the acm mail just now |
| 19:17.53 |
madant |
i mean the
gsoc students |
| 19:43.28 |
brlcad |
the schedules
can be flexible, but we just have to make sure that the timelines
and goals match up or are shifted accordingly (especially if less
work earlier is going to be compensated with more work later),
otherwise reducing goals to match effort |
| 19:43.40 |
brlcad |
so when
midterm comes, we can make sure everyone is 100% ;) |
| 19:44.56 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) |
| 19:46.29 |
Ralith |
iirc, the
time intervals I allocated are pessimistic enough that that might
not be necessary (yet, anyway) |
| 19:46.55 |
Ralith |
'course,
we'll see how that stands when the code starts flowing. |
| 19:51.55 |
``Erik |
ralith: every
coder says that :D |
| 19:52.11 |
Ralith |
hehe |
| 19:52.14 |
Ralith |
thought that
might be the case. |
| 19:53.03 |
Ralith |
still, I have
a tendency to, given a solid block of free time, take a problem,
sit down, and grind my way through it in an allnighter or
two |
| 19:57.49 |
Ralith |
I love
LaTeX. |
| 19:58.44 |
``Erik |
whoa whoa
whoa, we don't need to know about your bedroom activities,
there! |
| 19:58.59 |
``Erik |
\documentclass{badjoke} |
| 19:59.15 |
Ralith |
:P |
| 19:59.55 |
``Erik |
(which is
probably why it's pronounced luh-TEK... UNIX embraced the jokes,
though...) |
| 20:00.22 |
Ralith |
I thought it
was lah-tek |
| 20:00.32 |
``Erik |
lah, luh,
whatever |
| 20:00.49 |
brlcad |
Ralith:
remember to leave ample time for discussion |
| 20:01.06 |
Ralith |
interestingly, I read that the author(s)
have no position on its pronounciation. |
| 20:01.32 |
brlcad |
that's often
not included in estimates, but particularly relevant for gsoc work
as the communication is argubly the primary product |
| 20:02.10 |
``Erik |
hm, of which,
LaTeX or TeX? there's some inherited pronounciation going
on |
| 20:02.25 |
Ralith |
brlcad:
point. There are times when discussion is of minimal necessity,
though; I doubt there's need to debate very much of, for example,
the how to hook Qt into OGRE, simply because there's probably only
a few ways. |
| 20:02.29 |
Ralith |
``Erik: the
former. |
| 20:02.36 |
Ralith |
TeX has a
well defined pronunciation. |
| 20:03.28 |
``Erik |
mebbe the
lah/luh/lay part is where no position comes in, and TeX's is
assumed for the latter part? *shrug* |
| 20:03.34 |
``Erik |
nerd
etymology, pheer |
| 20:03.40 |
Ralith |
hehe |
| 20:03.46 |
Ralith |
metanerdiness! |
| 20:04.30 |
``Erik |
yes, do
include things like communication, documentation, etc in the
estimations |
| 20:05.38 |
brlcad |
Ralith: true,
plus much of the discussion and design is already sorted out in
prototype form via IOE |
| 20:05.42 |
``Erik |
heh, what's
the (industry) heuristic? guess how long it'll take, double that
for the surprises, double it again for all the other crap?
O:-) |
| 20:06.06 |
brlcad |
but if there
are unclear points (e.g. on IOE or appearance/behavior), then those
should generally at least be commented on |
| 20:06.07 |
Ralith |
double it
until you get bored. |
| 20:06.10 |
Ralith |
well
sure |
| 20:06.25 |
Ralith |
that's what
IRC's here for ^^ |
| 20:07.49 |
``Erik |
irc's for
hashing stuff out or asking questions, but the answer should
probably be written up in a more useful fashion for searching or
getting an overview, no? |
| 20:07.53 |
brlcad |
i'll just be
happy if it's an empty shell that does absolutely nothing except
has all the framework hooks in for new command bindings, tabbed
contexts, the menu, and appearance/bindings working :) |
| 20:08.18 |
Ralith |
appearance/bindings? |
| 20:08.28 |
Ralith |
would be happy with that too. |
| 20:08.32 |
brlcad |
the custom
apperance overrides |
| 20:08.42 |
Ralith |
would then be even happier to hook it up to things after
SoC's over :D |
| 20:09.05 |
Ralith |
I don't
recall hearing/talking about that |
| 20:09.07 |
brlcad |
if you recall
in IOE, there are some universal keybindings (to bring up the
command-prompt overlay for example) and some context specific
bindings (e.g., go to end of line) |
| 20:09.13 |
Ralith |
yeah |
| 20:10.02 |
brlcad |
making it
"look" like IOE or similar to it will be work in itself (as default
Qt appearance is rather not useful) |
| 20:10.19 |
brlcad |
other than a
starting point |
| 20:11.40 |
brlcad |
inheriting
from their tabbed widget, for example, so it can be drawn cleanly
integrated with the opengl context |
| 20:12.09 |
brlcad |
(ala
stellarium's inherited widgets) |
| 20:13.03 |
Ralith |
hm, tabbing's
an interesting problem there |
| 20:13.28 |
Ralith |
oh
hey |
| 20:13.33 |
Ralith |
it supports
nested OpenGL contexts |
| 20:13.36 |
Ralith |
so that would
actually work fine |
| 20:13.51 |
Ralith |
(iirc; I
remember seeing an impressive demo of something of the
sort) |
| 20:16.32 |
Ralith |
afks for a couple hours |
| 20:16.59 |
Ralith |
hm, not sure
how that would work out with Ogre. |
| 20:17.04 |
Ralith |
probably
wouldn't. might need some fancy code there. |
| 20:17.11 |
brlcad |
I think the
most important pieces to the interface 'framework' are going to be
a command terminal, a debug output/logging console (perhaps one in
the same), then the command overlay, followed by switchable
(tabbed) contexts, the 3D context, then the menu ... but that's off
the cuff |
| 20:17.28 |
brlcad |
ogre is just
handed a graphics context and goes to town rendering in that
context |
| 20:17.37 |
brlcad |
you're not
using ogre to create the window or the graphics context |
| 20:17.49 |
brlcad |
one of it's
lower-level initialization paths iirc |
| 20:18.11 |
Ralith |
yeah, but I'm
not sure how that works out with the tabbed contexts |
| 20:18.27 |
Ralith |
will discuss
more later; I'm about to be late to a class. |
| 20:18.28 |
brlcad |
you're a qt
app with ogre embedded, not an ogre app with qt widgets
embedded |
| 20:18.34 |
brlcad |
okay, cya
;) |
| 20:20.57 |
brlcad |
as for tabbed
contexts, you'll probably need some sort of context+content manager
so when a given tab is activated, it simple tells ogre to render a
different scene graph (which may be nothing) and draws its overlay
for that tab widget directly to the ogl context |
| 20:21.30 |
brlcad |
(so there's
still just one ogl context ever, but you keep track of what gets
drawn to that context with some manager class) |
| 20:25.19 |
*** join/#brlcad Briggs
(n=chatzill@adsl-70-238-143-242.dsl.stlsmo.sbcglobal.net) |
| 20:29.19 |
indianlarry |
cd |
| 20:38.55 |
``Erik |
steps down from his screen soap box before indianlarry stomps
him |
| 20:39.37 |
brlcad |
heh |
| 20:51.29 |
starseeker |
well, chased
him out anyway ;-) |
| 20:56.34 |
``Erik |
nah, I just
told him the 3 commands he'll use when he starts using it and
suggested stealing someones hardstatus line |
| 20:56.48 |
``Erik |
did a little
d&p show |
| 21:16.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-2.sbndin.btas.verizon.net) |
| 21:32.17 |
``Erik |
<PROTECTED> |
| 21:32.21 |
``Erik |
heh |
| 22:13.03 |
Ralith |
returns! |
| 22:13.11 |
brlcad |
heh |
| 22:13.21 |
brlcad |
goes to see the new terminator |
| 22:14.12 |
Ralith |
enjoy |
| 22:14.25 |
brlcad |
hopefully not
teh suck |
| 22:14.45 |
starseeker |
crosses fingers |
| 23:06.28 |
madant |
crosses fingers and toes |
| 23:19.07 |
``Erik |
O.o |
| 23:19.19 |
``Erik |
guesses it's just a bunch of action, no
story |
| 23:26.05 |
madant |
thinks or worse little action and no story |
| 23:28.00 |
``Erik |
they showed a
5 minute clip of the movie during some show I was watching a few
days ago, seemed like they were pretty big on action from that
(naturally, they picked the most "action-packed" part,
though) |
| 23:34.42 |
madant |
trailers are
always misleading ;) |
| 23:35.02 |
madant |
oops..5
minute clip..not trailer.. |
| 23:35.21 |
madant |
ok must be
good for the eyes then .. |
| 23:46.13 |
``Erik |
some big
assault by the humans on a robot station, a10's and helicoptors all
over, made a big point about a terminator unit that got knocked
down being landed on by a helicoptor (skid crushing part of it) and
one of the guys that jumped out putting two rounds in its skulls so
its eyes go out |
| 23:46.43 |
``Erik |
I have no
context as to what part it is, but *shrug* I imagine it wouldn't
matter in that flick :D |
| 00:45.46 |
starseeker |
gets a definite no on the siggraph poster |
| 00:48.59 |
starseeker |
well, glad I
didn't spend any more time fussing with it |
| 01:10.56 |
brlcad |
starseeker:
ahh, darn -- sorry to hear that |
| 01:11.02 |
brlcad |
did they
provide any feedback? |
| 01:25.20 |
starseeker |
they
did |
| 01:25.41 |
starseeker |
generally,
seems like it was too specialized and "niche" for
siggraph |
| 01:29.19 |
brlcad |
starseeker:
nah, some posters are *way* more niche |
| 01:30.04 |
brlcad |
at least I
don't buy it, curious to see the actual verbage if they provided
anything |
| 01:30.17 |
brlcad |
more believe
it was just a matter of not making the N% cut line |
| 01:30.41 |
starseeker |
is working on getting a pdf of the review - one
sec |
| 01:32.55 |
starseeker |
there we
go |
| 01:34.56 |
brlcad |
looks |
| 01:39.18 |
starseeker |
Reviewer
#16720 wants a lot packed into a small abstract... |
| 01:39.38 |
brlcad |
wow, actually
looks like you almost had it |
| 01:40.57 |
starseeker |
basically one
yea, one "nothing novel", and two "too specialized" |
| 01:41.05 |
brlcad |
first two
were generality based while still impressive, third was a thumbs
up, four was 'almost' had he thought the poster was detailed
enough |
| 01:42.24 |
starseeker |
actually though tire spec -> primitive parameters was the
less novel part... |
| 01:44.29 |
brlcad |
what the
third read into was what I was talking about having you emphasize,
the procedural modeling aspect |
| 01:44.47 |
starseeker |
yeah,
probably |
| 01:45.32 |
starseeker |
wonders if he should finish the form1
anyway... |
| 01:47.06 |
starseeker |
I guess one
take-away is to include a graphic of the poster in the "extra"
materials |
| 01:48.06 |
brlcad |
oh, what gave
you that idea? |
| 01:48.29 |
brlcad |
that would
have been great, think if they'd actually seen the full poster over
the abstract |
| 01:48.34 |
starseeker |
the last
reviewer asking for so much detail |
| 01:48.41 |
brlcad |
ah
yeah |
| 01:48.54 |
starseeker |
packed the abstract to the limit as it
is... |
| 01:50.44 |
brlcad |
i'm sure
there's another forum that will be great for the poster, given how
close that was (and more importantly just how well put together it
is) |
| 01:50.59 |
starseeker |
cool
:-) |
| 01:52.08 |
starseeker |
the "well put
together" is due to your help - thanks for all the time/help you
put into it brlcad |
| 01:52.40 |
brlcad |
nah, you did
all the heavy lifting |
| 01:53.11 |
starseeker |
it's that
polish that makes all the difference though - I seem to lack the
"make good color choices" gene |
| 01:53.37 |
starseeker |
glances around to make sure better half didn't see me admit
that... |
| 01:53.49 |
brlcad |
hehe |
| 04:27.55 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 07:02.03 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 08:01.10 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 09:25.37 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:34.48 |
d-lo |
Mernin
all |
| 12:14.18 |
*** join/#brlcad suryajith
(n=suryajit@202.3.77.38) |
| 12:21.35 |
*** part/#brlcad hippieindamakin8
(n=suryajit@202.3.77.38) |
| 12:24.28 |
*** join/#brlcad n00b_in
(n=suryajit@202.3.77.38) |
| 12:24.40 |
*** part/#brlcad n00b_in
(n=suryajit@202.3.77.38) |
| 12:40.56 |
*** join/#brlcad docelic
(n=docelic@78.134.199.252) |
| 13:02.24 |
*** join/#brlcad docelic_
(n=docelic@78.134.198.23) |
| 13:35.03 |
*** join/#brlcad madant
(n=madant@117.196.133.164) |
| 14:56.07 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 14:56.48 |
brlcad |
howdy
d_rossberg, gl?cklicher Freitag zu Ihnen! |
| 14:57.00 |
brlcad |
doubts that is right :) |
| 14:58.34 |
archivist |
sees strange black background |
| 14:59.32 |
d_rossberg |
brlcad:
oje |
| 15:00.07 |
d_rossberg |
w"unscht einen sch"onen Freitag! |
| 15:01.20 |
d_rossberg |
and a happy
Whitsun |
| 15:03.30 |
archivist |
ö ü I dont
see the proper chars from you two |
| 15:03.50 |
archivist |
are they
correct from me |
| 15:05.30 |
d_rossberg |
"o and "u are
the LaTeX (Babel package) replacements for ö and ü |
| 15:06.29 |
archivist |
ah ok /me is
a latex free zone |
| 15:06.51 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34598 10/brlcad/trunk/misc/win32-msvc/Dll/
(BrlcadCore.rc CMakeLists.txt brlcad.rc): |
| 15:06.51 |
CIA-28 |
BRL-CAD:
renamed the file with the BRL-CAD version defines and copied it
into the rc^3/include/brlcad directory |
| 15:06.51 |
CIA-28 |
BRL-CAD: this
way an application is able to memorize the BRL-CAD version it was
compiled with at compile time |
| 15:06.51 |
CIA-28 |
BRL-CAD: i.e.
it can compare the BRL-CAd version of the DLL it is using with the
one it was compiled with |
| 15:09.58 |
CIA-28 |
BRL-CAD:
03d_rossberg * r34599 10/rt^3/trunk/ (include/brlcad/globals.h
src/coreInterface/globals.cpp): 3 functions to get the interface's
version information |
| 15:26.19 |
CIA-28 |
BRL-CAD:
03brlcad * r34600 10/brlcad/trunk/BUGS: found some bad light
behavior with infinite lights. seems like several bugs depending on
the light fraction and surface orientations and light
angles. |
| 15:42.51 |
CIA-28 |
BRL-CAD:
03Pacman87 07http://brlcad.org *
r1445 10/wiki/User:Pacman87: |
| 16:51.11 |
*** join/#brlcad jdoliner
(n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) |
| 16:52.52 |
pacman87_ |
waves to jdoliner |
| 17:49.02 |
brlcad |
waves to pacman87_ :) |
| 18:11.57 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-236-35.dclient.hispeed.ch) |
| 18:36.45 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light1.png]]":
Example of three colored light sources over a box. Scene rendered
with default (30%) ambient illumination. |
| 18:41.23 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light2.png]]":
Example of three colored light sources over a box. Scene rendered
with 0% ambient illumination. |
| 18:44.25 |
starseeker |
hmm -
apparently someone working on Cairo-in-OGRE3D rendering |
| 18:46.51 |
starseeker |
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=47237 |
| 18:48.10 |
brlcad |
heh,
neat |
| 18:49.21 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light3.png]]":
Example of three colored light sources over a box. Scene rendered
with 0% ambient illumination. Light fraction is 2.0 for double
intensity. |
| 18:49.32 |
starseeker |
brlcad: how
did it end up - are we doing Qt in OGRE or OGRE in Qt? |
| 18:50.55 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light4.png]]":
Example of three colored light sources over a box. Scene rendered
with 0% ambient illumination. Light fraction is 10.0 for blooming
intensity. |
| 18:51.14 |
brlcad |
it should be
'ogre in qt' |
| 18:51.30 |
starseeker |
OK |
| 18:51.46 |
starseeker |
wonders if this would help any?
http://www.qt-apps.org/content/show.php/QtOgre+Framework?content=92912 |
| 18:51.49 |
brlcad |
Qt is used to
create the context/window, that is passed to ogre's initialization
(a lower level one iirc) |
| 18:52.38 |
brlcad |
yeah, that
looks like someone did exactly that with that project |
| 18:53.07 |
Ralith |
ooh,
handy! |
| 18:53.20 |
starseeker |
zlib license
looks ok, I think... |
| 18:53.30 |
Ralith |
zlib is a
BSDalike, no? |
| 18:53.35 |
brlcad |
yeah |
| 18:53.40 |
starseeker |
http://www.gzip.org/zlib/zlib_license.html |
| 18:53.59 |
brlcad |
I'd be
surprised if that 'project' was more than a couple
files |
| 18:54.09 |
Ralith |
nevertheless,
it's a great place to start. |
| 18:54.14 |
brlcad |
yeah |
| 18:54.16 |
Ralith |
or looks like
one anyway |
| 18:54.21 |
brlcad |
save you a
few days |
| 18:54.45 |
brlcad |
or at least a
day :) |
| 18:54.54 |
Ralith |
some amount
of time, anyway |
| 18:54.57 |
starseeker |
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=45709 |
| 18:55.01 |
Ralith |
it's nonzero
so it's good |
| 18:55.42 |
Ralith |
looks
great! |
| 18:56.03 |
Ralith |
nice find
:) |
| 18:56.23 |
starseeker |
apparently
the original author (PolyVox) is still active in the forums -
perhaps he could answer questions |
| 18:56.29 |
Ralith |
grabs the code |
| 18:58.06 |
Ralith |
hmm... that
castle model looks familiar |
| 18:58.39 |
Ralith |
er, that's on
a different page. |
| 18:58.55 |
Ralith |
looks like
this guy's working on continuing some voxel work I was looking into
a while back as well; neat |
| 19:00.53 |
starseeker |
ooo,
destructible environments in games |
| 19:01.02 |
Ralith |
not properly,
yet |
| 19:01.23 |
Ralith |
it's just
voxels, and has the predictable horrible performance for worlds
large enough to be interesting |
| 19:02.20 |
Ralith |
but it looks
like he's considering various LoD approaches. |
| 19:04.09 |
Ralith |
isn't sure if voxels, even somehow optimized, are really the
way to go for large-scale destruction, but it's certainly
cool. |
| 19:05.03 |
starseeker |
Ralith: might
want to check that thread on the Qt+OGRE framework and make sure
there isn't more current code floating around somewhere |
| 19:05.29 |
Ralith |
Last edited
by PolyVox on Tue Apr 14, 2009 10:21 pm, edited 4 times in
total. |
| 19:05.36 |
Ralith |
seems like
he's been keeping the first post up to date. |
| 19:06.01 |
starseeker |
This one has
May 27th:
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=45709&p=342063#p342063 |
| 19:06.50 |
starseeker |
yeah, OGRE
forums seem to work like that - work centers around
threads |
| 19:07.01 |
starseeker |
seems a bit
haphazard, but if it works it works |
| 19:07.22 |
Ralith |
oh, it looks
like it's in ogreaddons |
| 19:07.33 |
Ralith |
syncs |
| 19:07.56 |
starseeker |
ah
https://ogreaddons.svn.sourceforge.net/svnroot/ogreaddons/trunk/QtOgreFramework/ |
| 19:08.01 |
Ralith |
yup |
| 19:08.01 |
starseeker |
oh, you win
:-) |
| 19:08.06 |
Ralith |
^^ |
| 19:08.11 |
Ralith |
do I get a
prise? |
| 19:08.13 |
Ralith |
prize* |
| 19:08.19 |
starseeker |
just free
source code |
| 19:08.23 |
Ralith |
yay! |
| 19:09.05 |
Ralith |
oh cool, it
uses cmake |
| 19:09.14 |
Ralith |
that answers
my worry about how well qt works with non-qmake |
| 19:09.54 |
Ralith |
(probably
still depends on qmake and/or related tools, but at least this
allows a consistent build system) |
| 19:11.52 |
starseeker |
nods |
| 19:11.55 |
Ralith |
hm, can't
*quite* get the demo to run. |
| 19:17.21 |
Ralith |
argh. |
| 19:17.36 |
starseeker |
hmm? |
| 19:17.53 |
Ralith |
found an
error log that confirms what I suspected was wrong, but doesn't
actually tell me anything useful re: solving it. |
| 19:18.15 |
Ralith |
ah here we
go. |
| 19:18.46 |
Ralith |
facepalms |
| 19:18.56 |
Ralith |
he hardcoded
the GL render system dynlib path. |
| 19:19.16 |
Ralith |
...or so it
appears? |
| 19:19.55 |
Ralith |
yup. |
| 19:20.13 |
starseeker |
oops |
| 19:20.20 |
starseeker |
code change
#1 |
| 19:20.32 |
Ralith |
indeed. |
| 19:20.48 |
Ralith |
pretty sure
there shouldn't even need to be a path, much less a hardcoded
one. |
| 19:20.57 |
Ralith |
that's what
ldd is for. |
| 19:22.49 |
Ralith |
hm, perhaps
there is need after all. |
| 19:23.11 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 19:27.45 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: |
| 19:27.45 |
CIA-28 |
BRL-CAD:
uploaded "[[Image:Phong.png]]": Example of Phong illumination,
pulled from the Wikipedia. |
| 19:27.45 |
CIA-28 |
BRL-CAD:
Provided under GFDL. |
| 19:34.00 |
Ralith |
gah! |
| 19:34.17 |
Ralith |
why do people
"support linux" but always forget case sensitivity?
>:| |
| 19:34.39 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light5.png]]":
Example of three colored light sources over a box. Scene rendered
with 0% ambient illumination. Light fraction is 10.0 for high
intensity. Specular is 0.7 and diffuse is 0.3
(default). |
| 19:35.19 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: |
| 19:35.19 |
CIA-28 |
BRL-CAD:
uploaded "[[Image:Light6.png]]": Example of three colored light
sources over a |
| 19:35.19 |
CIA-28 |
BRL-CAD: box.
Scene rendered with 0% ambient illumination. Light fraction is 10.0
for |
| 19:35.20 |
CIA-28 |
BRL-CAD: high
intensity. Specular is 0.5 and diffuse is 0.5 for more
'dulled' |
| 19:35.20 |
CIA-28 |
BRL-CAD:
reflectance. |
| 19:36.18 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: |
| 19:36.18 |
CIA-28 |
BRL-CAD:
uploaded "[[Image:Light7.png]]": Example of three colored light
sources over a |
| 19:36.18 |
CIA-28 |
BRL-CAD: box.
Scene rendered with 0% ambient illumination. Light fraction is 10.0
for |
| 19:36.18 |
CIA-28 |
BRL-CAD: high
intensity. Specular is 0 and diffuse is 1 for maximally
diffuse |
| 19:36.18 |
CIA-28 |
BRL-CAD:
reflectance. |
| 19:37.02 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: |
| 19:37.02 |
CIA-28 |
BRL-CAD:
uploaded "[[Image:Light8.png]]": Example of three colored light
sources over a |
| 19:37.02 |
CIA-28 |
BRL-CAD: box.
Scene rendered with 0% ambient illumination. Light fraction is 10.0
for |
| 19:37.02 |
CIA-28 |
BRL-CAD: high
intensity. Specular is 1 and diffuse is 0 for maximally
specular |
| 19:37.02 |
CIA-28 |
BRL-CAD:
reflectance. |
| 19:37.43 |
Ralith |
hm, that's
interesting; it doesn't seem to really handle a tiling wm
well. |
| 19:41.41 |
Ralith |
or perhaps
this is a deeper problem. One way or another, the windows that are
supposed to be within Ogre end up as separate windows, except for
the FPS counter, and that one ends up outside if I mess with the
window in a certain way. |
| 19:41.51 |
Ralith |
perhaps this
isn't such a good starting point. |
| 19:42.14 |
Ralith |
shall try to contact the author. |
| 19:44.04 |
starseeker |
sorry -
thought it might help :-/ |
| 19:44.15 |
starseeker |
didn't dig
too deep into it though |
| 19:44.27 |
Ralith |
it certainly
looked that way, and it may yet. |
| 19:44.31 |
Ralith |
we'll
se |
| 19:45.31 |
Ralith |
although the
way it states that it can only do transparent windows on systems
with compositing WMs makes me wonder if it's actually embedding the
Qt windows in OpenGL properly. |
| 19:48.40 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light brg.png]]":
Example of three colored light sources over a box looking down from
above. Scene rendered with 0% ambient illumination with a 1.0 light
fraction on all three lights. |
| 19:50.31 |
Ralith |
yeah, it does
kind of look like it's just drawing the Qt windows on top of,
rather than in, the context. |
| 19:51.51 |
starseeker |
ah,
poo |
| 19:52.39 |
starseeker |
https://www.ogre3d.org/forums/viewtopic.php?f=2&t=47381 |
| 19:53.49 |
starseeker |
Perhaps there
are some hints here: |
| 19:53.53 |
starseeker |
http://www.ogre3d.org/forums/viewtopic.php?p=258064 |
| 19:55.00 |
Ralith |
that's
ogre-in-qt rather than qt-in-ogre |
| 19:55.18 |
Ralith |
hm. |
| 19:55.37 |
Ralith |
brlcad: so,
wait, do we just want an Ogre context within a Qt
window? |
| 19:55.56 |
Ralith |
as opposed to
everything within an OpenGL context? |
| 19:56.26 |
Ralith |
it should be
relatively straightforward to simply create an Ogre
widget. |
| 19:56.38 |
Ralith |
that's not
what I thought we'd decided on, though |
| 19:57.02 |
starseeker |
thought we would be rendering the Qt widgets on the OGRE
context |
| 19:57.06 |
starseeker |
or
in |
| 19:57.11 |
Ralith |
thought so as well. |
| 19:57.33 |
starseeker |
so we
essentially need to do "right" what that code tried to
fake |
| 19:57.40 |
Ralith |
yeah |
| 19:57.58 |
Ralith |
brlcad:
confirm? |
| 19:59.56 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light brg10.png]]":
Example of three colored light sources over a box looking down from
above. Scene rendered with 0% ambient illumination with a 10.0
light fraction on all three lights. |
| 20:02.56 |
Ralith |
brbs for a couple hours |
| 20:04.12 |
starseeker |
Ralith: Hmm,
the comments of pmax here may be of interest:
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=42733&start=25 |
| 20:07.46 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Light brg20.png]]":
Example of three colored light sources over a box looking down from
above. Scene rendered with 0% ambient illumination with a 20.0
light fraction on all three lights. |
| 20:08.43 |
starseeker |
Ralith: If
I'm not mistaken, pmax was trying to do it the "right way" and
PolyVox thinks perhaps a new feature in 4.5 would make it
possible |
| 20:10.40 |
starseeker |
if I'm
understanding this correctly, it's 1. Qt gets going and then
creates either a window or a fullscreen context (if those are
actually different) |
| 20:11.05 |
starseeker |
2. In the QT
window/context, Qt asks for an instance of Ogre |
| 20:12.19 |
starseeker |
3. Qt then
takes that instance of Ogre, and uses it as the output for its
widget renders. Qt still manages things like I/O, passing things
specific to Ogre through the Qt system to the Ogre
system |
| 20:15.37 |
starseeker |
I suppose
other possibilities would be to have Qt request an opengl graphics
system and then shoehorn OGRE in between QT and its graphics
system, but that doesn't feel right |
| 20:16.37 |
starseeker |
would require
that whatever Qt wants from opengl is the same as what OGRE wants,
so that a Qt requested opengl context could serve as the "target"
for Ogre |
| 20:20.48 |
starseeker |
this probably
comes under the "check what stellarium does" heading |
| 20:21.27 |
starseeker |
don't think
they use OGRE, but what they do do might be helpful as a technique
illustration (they're GPL so no code grabbing) |
| 20:37.20 |
starseeker |
Ralith: also
possibly of interest (see comment from gunnar at 10/23/2008 6:39)
http://labs.trolltech.com/blogs/2008/10/22/so-long-and-thanks-for-the-blit/ |
| 20:39.10 |
starseeker |
may help as
well:
http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ |
| 20:39.35 |
starseeker |
hopes we won't have to try creating a whole Ogre rendering
system for Qt, but it might come to that... |
| 20:48.22 |
starseeker |
well, custom
QPaintDevice backends are possible apparently - need to create an
engine that derives from QPaintEngine |
| 20:51.19 |
starseeker |
don't know if
that works though, because QWidget is also a subclass of
QPaintDevice |
| 20:52.48 |
starseeker |
neat
stuff |
| 20:52.53 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r1458
10/wiki/Lighting: Initial (brief) overview of how BRL-CAD lighting
works with examples |
| 20:53.42 |
brlcad |
woot,
http://brlcad.org/wiki/Lighting
<-- proofreads welcome for clarity/typos/etc |
| 20:55.15 |
starseeker |
looks |
| 20:55.35 |
starseeker |
well, this
sounds hopeful for QWidget: Warning: If you are using a custom
paint engine without Qt's backingstore, Qt::WA_PaintOnScreen must
be set. Otherwise, QWidget::paintEngine() will never be called; the
backingstore will be used instead. |
| 20:55.45 |
starseeker |
implies a
custom paint engine can be used |
| 20:59.42 |
starseeker |
brlcad: first
line after Phone "Plastic" Shader - maybe say "Initially, you may
think..." ? |
| 20:59.46 |
starseeker |
just a
nitpick |
| 21:01.57 |
starseeker |
nice
job! |
| 21:49.20 |
poolio |
howdy
all! |
| 21:49.43 |
pacman87 |
hi
poolio |
| 21:50.39 |
poolio |
ahoy
pacman87, how's gsoc going? |
| 21:51.01 |
pacman87 |
bit of a slow
start, rereading code |
| 21:51.04 |
pacman87 |
picking up
now |
| 21:53.16 |
poolio |
cool cool. so
you're done classes and what not? |
| 21:53.49 |
pacman87 |
yeah,
graduation was last weekend |
| 21:54.18 |
pacman87 |
just found
out i got accepted to the EE program for grad school at UT Austin
today |
| 22:01.35 |
poolio |
congratulations! was that your top
choice? |
| 22:02.03 |
pacman87 |
yeah, i
didn't really apply to that many |
| 22:02.30 |
pacman87 |
i just
finished my undergrad in ME there |
| 22:07.58 |
Ralith |
starseeker:
actually, there are Qt demos doing in-OpenGL drawing using that new
4.5 feature. |
| 22:08.05 |
Ralith |
just none
that use Ogre too |
| 22:09.20 |
Ralith |
starseeker:
that last link is in fact what I'm referring to |
| 22:09.35 |
Ralith |
I guess it's
a 4.4 feature |
| 22:10.13 |
Ralith |
hm, so I
guess what would be needed would be override
QGraphicsScene::drawBackground to call Ogre's frame render
function |
| 22:10.39 |
Ralith |
the trick
being, as discussed, getting Ogre to do the render into the same
context. |
| 22:11.41 |
Ralith |
starseeker:
there's also this really cool demo someone wrote with Qt widgets
mapped into a 3D world in an OpenGL context, and one of the widgets
was an OpenGL context (or something?) that controlled a camera in
the world, so you could view it through itself to an arbitrary
level of recursion |
| 22:28.45 |
Ralith |
tries to build that. |
| 22:30.30 |
Ralith |
oh hey, qmake
generates a makefile despite the apparent absence of build
instructions. handy. |
| 22:31.02 |
Ralith |
works
perfectly out of the box! I think we have a starting point, if
it's licensed well. |
| 22:35.39 |
mafm |
don't worry
Ralith, USA's Army has good funding :P :) |
| 22:35.51 |
Ralith |
:P |
| 22:36.05 |
Ralith |
aw, it's
GPL'd |
| 22:36.44 |
Ralith |
well it's
simple enough |
| 22:37.17 |
mafm |
wasn't Qt
LGPL'd recently? |
| 22:37.26 |
Ralith |
this code in
particular is GPL |
| 22:37.33 |
Ralith |
it's not
actually Qt, just an example |
| 22:37.45 |
mafm |
oh |
| 23:42.08 |
brlcad |
kicks off a nifty Goliath render for the
weekend |
| 01:27.36 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 01:27.43 |
*** join/#brlcad docelic (n=docelic@78.134.203.126) [NETSPLIT
VICTIM] |
| 02:44.53 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) |
| 02:48.58 |
*** join/#brlcad mike
(n=mike@cadil21.kaist.ac.kr) |
| 02:49.34 |
Mike111 |
hi
all |
| 02:50.50 |
Ralith |
hullo |
| 02:51.01 |
Mike111 |
I want to
create an animation of a model. |
| 02:52.05 |
Mike111 |
for a smooth
animation it seems better to save the images (different views) and
then combine them into an animation file like a GIF |
| 02:52.23 |
Mike111 |
is it
possible to convert .pix to .png of .gif? |
| 02:52.59 |
``Erik |
yeah,
pix-png |
| 02:54.05 |
Mike111 |
that's good.
is it mentioned in the manuals? I've reat the rt, pix-fb and
anim_script but don't think it was there |
| 02:54.50 |
``Erik |
which
manuals? the man pages? tutorials? O.o |
| 02:55.01 |
Mike111 |
man
pages |
| 02:55.30 |
Mike111 |
are there
separate tutorial on animation? where? |
| 02:55.33 |
``Erik |
there's a
pix-png man page, yes |
| 02:55.59 |
``Erik |
um, there was
an outdated paper sitting somewhere, clock was able to make it
work, but it required a lot of change to the process |
| 02:56.56 |
Mike111 |
I don't think
it's mentioned in the rt or pix-fb man pages |
| 02:57.46 |
``Erik |
hm, those are
other programs O.o |
| 02:58.16 |
``Erik |
notes that perl is not mentioned in the ls
manpage |
| 02:58.34 |
``Erik |
:D |
| 02:59.16 |
Ralith |
Mike111: I
bet you could script an animation render |
| 02:59.22 |
Ralith |
but...
why? |
| 02:59.46 |
Mike111 |
other but
related. users may be interested in converting from pix. reading
these man pages gives an impression it is only processed by
mged |
| 03:00.20 |
Mike111 |
Ralith:
animating in real-time via mged may be slow. I want to rt first,
save the framebuffer output and them create a smooth
animaiton |
| 03:00.34 |
``Erik |
(hopefully in
the reasonably near future, rt will be able to output png
directly... rtedge already can) |
| 03:01.31 |
Ralith |
Mike111: why
do you want to animate directly from brlcad at all? |
| 03:02.39 |
Mike111 |
Ralith: I
don't. I want mged to create a rt frame and then save the
framebuffer image. I'll have a series of these figures, merge them
into one file and have a nice GIF animation |
| 03:03.09 |
Ralith |
Mike111: why
do you want to animate indirectly from brlcad at all? |
| 03:03.46 |
Mike111 |
for example:
circling around a model, that is, viewing it from a different angle
(0,45,90...360) |
| 03:05.30 |
Ralith |
yes, I know
what animating is |
| 03:05.32 |
Ralith |
but
*why*? |
| 03:05.59 |
Mike111 |
there is an
animation page on the brl-cad wiki. I'll look there too |
| 03:06.30 |
Ralith |
what is the
purpose of your endeavor? |
| 03:06.40 |
Mike111 |
Ralith:
viewing the model from different directions helps someone else to
understand what you are doing |
| 03:07.03 |
Ralith |
Mike111:
okay, so why not export it to something that has a rendering system
designed to do animations, and make a proper video of
it? |
| 03:07.59 |
Mike111 |
you mean
convert the .pix to .png and then combine all the .png files into a
30fps movie? |
| 03:08.03 |
Ralith |
no. |
| 03:08.21 |
Ralith |
I mean
exporting the model to something that has a rendering system
designed to do animations. |
| 03:09.06 |
Mike111 |
you mean like
saving it as IGES or whatever and then loading it in a movie-editor
application? |
| 03:09.29 |
Ralith |
I don't know
of any video editors that can render from IGES geometry |
| 03:09.52 |
Mike111 |
can you give
me a specific working example what you mean? |
| 03:10.27 |
Ralith |
if you can
get a passable tesselation of your model, blender would make a
simple animation like you describe trivial and fast. |
| 03:10.43 |
Ralith |
as would any
other visuals-oriented modeler |
| 03:10.48 |
Ralith |
s/modeler/3D
suite/ |
| 03:11.33 |
Mike111 |
what's a
`passable tesselation'? |
| 03:16.28 |
Ralith |
one that
looks mostly like your model |
| 03:21.01 |
Mike111 |
what is the I
need to export my model in? (to read it in blender) |
| 03:22.27 |
Ralith |
the only
format I know for sure would work is STL |
| 03:32.24 |
Mike111 |
what were the
other alternatives to blender? |
| 03:36.43 |
Ralith |
whatever
visually oriented 3D suite you're familiar with |
| 03:42.38 |
Mike111 |
haven't used
any. Blender seems to be well-supported. I wonder if there are
alternatives (simpler). |
| 03:45.20 |
``Erik |
lightwave3d,
3dstudio max, maya, ... |
| 03:47.33 |
Ralith |
there's no
such thing as a simple 3D suite. |
| 03:58.22 |
Mike111 |
looking for
GPL and linux-compatible |
| 04:00.01 |
Ralith |
GPL? That's
an awfully small scope. |
| 04:00.32 |
Ralith |
I'm pretty
sure blender is the only remotely decent free 3D suite for any
non-beer meaning of free, anyway. |
| 04:01.45 |
Mike111 |
http://en.wikipedia.org/wiki/Blender_(software)
gives a few at the bottom of the page |
| 04:02.09 |
Mike111 |
have you
tried K3D? |
| 04:03.58 |
Ralith |
like I
said |
| 04:04.03 |
Ralith |
I'm pretty
sure blender is the only remotely decent free 3D suite for any
non-beer meaning of free, anyway. |
| 04:08.20 |
``Erik |
"grand theft
mariokart" |
| 04:08.36 |
Ralith |
hehe |
| 04:08.51 |
``Erik |
robotchicken++ |
| 04:14.47 |
brlcad |
notes that getting a 'passable tessellation' of a model can
be a project in itself, more complicated than a simple rt animation
:) |
| 04:16.13 |
Ralith |
true,
true. |
| 04:16.20 |
Ralith |
not forever
though! |
| 04:16.36 |
brlcad |
Mike111: give
the wiki tutorial a try, it's pretty trivail enough as it is to
generate a series of frames for an animation |
| 04:17.21 |
Ralith |
heey |
| 04:17.29 |
Ralith |
I bet it
wouldn't be hard to extend procedurals to produce a simple
animation system |
| 04:17.30 |
Mike111 |
hi brlcad.
that's what I'm doing now. imagemagick's convert doesn't work for
the mpeg. |
| 04:17.35 |
brlcad |
note that
brl-cad doesn't render animations -- there are no tools to put
those frames together into a video stream, you'll need third party
tool for that |
| 04:17.54 |
brlcad |
convert works
fine if you have the video tools installed that they use
:) |
| 04:17.54 |
Ralith |
imagemagick
does images, not videos. |
| 04:18.01 |
brlcad |
Ralith:
actually it does |
| 04:18.05 |
Ralith |
oh
really? |
| 04:18.06 |
Ralith |
cool! |
| 04:18.08 |
Mike111 |
I'm trying to
use ffmpeg |
| 04:18.31 |
Ralith |
still, I'd
use mencoder for creating a video from stills |
| 04:19.19 |
brlcad |
IM doesn't do
it directly, it just parcels out to ffmpeg or mencoder |
| 04:19.50 |
brlcad |
but does
simplify frame compositing, "convert *.png myvideo.mpg" |
| 04:20.37 |
Ralith |
I do hope it
gives you some way to specify compression and framerate at the very
least. |
| 04:22.06 |
brlcad |
*shrug*, if
you really need that -- you probably shouldn't be using IM in the
first place |
| 04:22.13 |
brlcad |
but it's
great for simple animations |
| 04:22.55 |
Mike111 |
for a
rotating model it seems to be fine. even a GIF animation will
do |
| 04:24.09 |
brlcad |
Mike111: feel
free to add additional detail to the wiki if you have something
useful to add |
| 04:24.25 |
Ralith |
brlcad: I
think everybody needs to at the very least specify
framerate. |
| 04:24.38 |
Ralith |
considering
the use case, 30fps is *not* a reasonable default. |
| 04:24.41 |
brlcad |
Ralith:
'everybody'? why? |
| 04:24.55 |
Ralith |
well, most
users. |
| 04:25.23 |
brlcad |
I've made
dozens of perfectly acceptable videos without any care whatsoever
to the framerate because it was perfectly reasonable
default |
| 04:25.31 |
Ralith |
because a
series of images has no intrinsic framerate, and I think it's
pretty likely that most imagesets will not compose smooth video,
but rather something slower a la hand drawn animation. |
| 04:25.44 |
Ralith |
I guess not
in this case, then. |
| 04:27.59 |
brlcad |
it's like
saying a user must specify a jpeg compression factor when
converting images -- there's no intrinsic 'acceptible' compression
but sure enough it works just fine to set an arbitrary
default |
| 04:28.19 |
brlcad |
same holds
with videos, maybe just slower or faster than expected |
| 04:28.25 |
brlcad |
big
deal |
| 04:28.27 |
Ralith |
well, you
have to consider the common use case |
| 04:28.39 |
Ralith |
jpegs, you
can generally assume that it's going to be a photo or something
similar. |
| 04:28.40 |
brlcad |
exactly |
| 04:28.56 |
Ralith |
because it'd
be silly to use jpeg for most else. |
| 04:29.15 |
brlcad |
wow, that's a
lot of assumptions already :) |
| 04:29.22 |
Ralith |
and yet it
works! |
| 04:29.23 |
brlcad |
you know
that, plenty of people don't |
| 04:30.37 |
brlcad |
do they need
to know that? no, it's (from their perspective) an irrelevant
implementation detail |
| 04:30.58 |
Ralith |
hm. |
| 04:31.01 |
brlcad |
it's not an
issue of whether to provide the knob or not, it's whether they
should _have_ to specify it |
| 04:31.10 |
Ralith |
I guess I
started arguing in favor of default framerates without
noticing. |
| 04:31.13 |
Ralith |
wups. |
| 04:32.14 |
Ralith |
(that
explains why things got so confusing just now) |
| 04:33.26 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 04:37.17 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 04:57.52 |
CIA-28 |
BRL-CAD:
03brlcad * r34626 10/brlcad/trunk/ (242 files in 4
dirs): |
| 04:57.52 |
CIA-28 |
BRL-CAD:
Decouple ged return codes from bu. It was okay when it was just
OK/ERROR, but |
| 04:57.52 |
CIA-28 |
BRL-CAD: not
with the ged-specific 'MORE' concept and would have been even worse
with the |
| 04:57.52 |
CIA-28 |
BRL-CAD: new
QUIET option. Make the codes maskable for non-OK so multiple codes
can be |
| 04:57.53 |
CIA-28 |
BRL-CAD:
returned at the same time. |
| 05:28.38 |
Mike111 |
is it
possilbe to use the `inside command on an ARS
primitive? |
| 07:25.48 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:32.36 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 08:54.13 |
*** join/#brlcad ``Erik
(i=erik@c-76-111-12-116.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 08:55.44 |
brlcad |
Mike111:
nope, unimplemented for that primitive |
| 08:56.58 |
brlcad |
only nmg,
eto, ehy, epa, rhc, rpc, part, tor, ell, tgc, and
arb8's |
| 08:58.09 |
brlcad |
wouldn't be
too terribly difficult though |
| 09:11.17 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 09:45.07 |
CIA-28 |
BRL-CAD:
0377.120.80.206 07http://brlcad.org
* r1460 10/wiki/Main_Page: |
| 10:13.49 |
*** join/#brlcad indianlarry
(n=indianla@bz.bzflag.bz) |
| 10:39.18 |
d-lo |
Mornin
all! |
| 11:32.02 |
brlcad |
howyd |
| 11:38.52 |
CIA-28 |
BRL-CAD:
03brlcad * r34627 10/brlcad/trunk/TODO: inside support for the ARS
(requested by Mike111) |
| 11:52.01 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 11:58.08 |
CIA-28 |
BRL-CAD:
03brlcad * r34628 10/brlcad/trunk/include/ged.h: put the new
GED_QUIET to use. if caller requests QUIET, then the ged_result_str
should not be modified. |
| 12:02.30 |
CIA-28 |
BRL-CAD:
03brlcad * r34629 10/brlcad/trunk/include/ged.h: document the four
command failure return codes |
| 12:29.12 |
d-lo |
Ralith: How
do you plan on using QT? Make it a requirement to have it
installed and compiled seperately or are you planning on including
it in the rt^3 repo? |
| 12:36.43 |
CIA-28 |
BRL-CAD:
03brlcad * r34630 10/brlcad/trunk/src/libged/ (3ptarb.c adjust.c
analyze.c): collapse a handful of common code patterns with the
corresponding GED_ macro. on a quest to have no command directly
peek into the ged structure. |
| 12:39.11 |
brlcad |
premature to
include it as the existing codebase |
| 12:39.22 |
brlcad |
not enough
code yet to warrant the effort |
| 12:40.00 |
brlcad |
wasn't enough
to warrant ogre either but iirc, it required some modifications to
integrate cleanly |
| 12:41.27 |
d-lo |
Okay, I was
just curious. QT is a biggun, even if you strip it down to the
bare minimum needed. |
| 12:45.00 |
brlcad |
yep |
| 12:45.06 |
CIA-28 |
BRL-CAD:
03brlcad * r34631 10/brlcad/trunk/src/libged/arb.c: diradd +
put_internal pattern. |
| 12:47.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 12:48.40 |
brlcad |
general rule
of thumb I've seen (for projects that don't follow always/never
bundle) is to manage/include it if their codesize is not larger
than yours |
| 12:50.00 |
brlcad |
shades of
gray in-between but seems to be the cutoff in terms of sustainable
maintainability (as there is a cost to managing every
dep) |
| 12:50.15 |
brlcad |
(whether
bundled or not) |
| 12:58.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34632 10/brlcad/trunk/src/libged/ (arced.c attr.c
bev.c): more GED pattern collapsing |
| 13:07.08 |
CIA-28 |
BRL-CAD:
03brlcad * r34633 10/brlcad/trunk/src/libged/binary.c:
ged_check_exists pattern |
| 13:12.58 |
CIA-28 |
BRL-CAD:
03brlcad * r34634 10/brlcad/trunk/ (include/ged.h
src/libged/binary.c): rename ged_binary() to ged_bo() so it matches
the command name. |
| 13:13.57 |
CIA-28 |
BRL-CAD:
03brlcad * r34635 10/brlcad/trunk/ (6 files in 3 dirs): rename
binary.c to bo.c to match the command name |
| 13:29.48 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 13:41.30 |
``Erik |
hugs gtk+ |
| 13:42.07 |
``Erik |
thinks zlib and libpng shouldn't be bundled anymore, make 'em
deps :( |
| 13:44.27 |
``Erik |
(and when do
we axe jove?) |
| 13:56.46 |
*** join/#brlcad samrose_
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:26.34 |
*** join/#brlcad docelic
(n=docelic@78.134.197.15) |
| 14:53.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 15:52.23 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-236-197.dclient.hispeed.ch) |
| 16:28.52 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 16:59.52 |
``Erik |
src/mged/setup.c:71: error: 'ged_binary'
undeclared here (not in a function) |
| 17:06.39 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34636 10/brlcad/trunk/src/mged/setup.c:
ged_binary has been renamed to ged_bo. Reflect that in the cmd
table. |
| 17:07.30 |
brlcad |
hum, musta
not committed that file |
| 17:13.01 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34637 10/brlcad/trunk/src/libged/arb.c:
GED_DB_DIRADD now takes a "struct directory" as a
parameter. |
| 17:14.16 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34638 10/brlcad/trunk/src/libtclcad/ged_obj.c:
ged_binary has been renamed to ged_bo. Reflect that in the cmd
table. |
| 17:29.43 |
brlcad |
ahh, my
setup.c was conflicted |
| 17:32.33 |
``Erik |
clean build
now |
| 17:32.41 |
brlcad |
cool |
| 17:33.20 |
``Erik |
moving the
new brlcad.org to a more explicit release tag, btw |
| 17:33.40 |
``Erik |
no need to
catch the pre-release versions |
| 17:35.23 |
``Erik |
(now, I'm
saying I have a clean build, I do NOT know if these functions work
as advertised...) |
| 17:56.32 |
Ralith |
d-lo: I think
it's fair to expect most *nix users to have Qt already. Windows
poses a bit of an issue there, but decent documentation should sort
that out. |
| 18:00.50 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 18:12.27 |
``Erik |
would disagree, but *shrug* |
| 18:12.38 |
``Erik |
I tend to be
more in the gnome camp myself |
| 18:12.51 |
d-lo |
lolz @ gnomecamp. |
| 18:13.00 |
``Erik |
lolz @ dave |
| 18:13.03 |
``Erik |
O.o |
| 18:13.13 |
``Erik |
casts magic missile |
| 18:13.16 |
d-lo |
i get that a
lot. |
| 18:13.27 |
``Erik |
at the
DARKNESS! |
| 18:13.51 |
d-lo |
The Darkness
AOE Debuffs #BRLCAD |
| 18:13.54 |
d-lo |
oh
noes! |
| 18:14.05 |
``Erik |
aoe dot,
even |
| 18:14.19 |
``Erik |
</nerd> |
| 18:14.44 |
d-lo |
heh,
refrencing Damage over Time and IRC in same
sentence.... |
| 18:14.47 |
d-lo |
nice. |
| 18:15.06 |
``Erik |
yeah,
redundant |
| 18:15.25 |
``Erik |
wait, wait,
"-1 redundant" |
| 18:15.27 |
``Erik |
there we go
:D |
| 18:16.13 |
d-lo |
Ralith: QT
is a helluva compile on windows :/ |
| 18:16.23 |
d-lo |
time wise
that is. |
| 18:16.31 |
Ralith |
well, there's
always prebuilt binaries! |
| 18:16.35 |
starseeker |
d-lo: they
should have an installer |
| 18:16.40 |
``Erik |
qt is a hell
of a compile anywhere, g++ is still a pig :( |
| 18:18.13 |
d-lo |
starseeker:
They do, but it doesn't compile the libs :/ |
| 18:18.21 |
d-lo |
starseeker:
Did some dry runs this weekend. |
| 18:18.37 |
Ralith |
d-lo: well,
for practical purposes, binaries will do fine. |
| 18:19.10 |
d-lo |
Ralith: Good
deal. Otherwise, how are things going? |
| 18:19.32 |
Ralith |
still bogged
up with schoolness, but that will be resolved by
monday. |
| 18:19.50 |
Ralith |
I've dig up
that old Qt-in-GL demo again for reference |
| 18:19.59 |
Ralith |
build and
runs tidily. |
| 18:20.21 |
Ralith |
and I have a
good idea of how to get Ogre using a third-party context, so to
speak. |
| 18:20.41 |
Ralith |
thanks to a
SDL+Ogre tutorial starseeker found |
| 18:21.43 |
Ralith |
so
implementing a proof-of-concept Qt in Ogre, and probably even
slipping Qt underneath current g3d, should be straightforward
enough. |
| 18:22.58 |
Ralith |
so, slow but
very promising. |
| 18:23.37 |
d-lo |
outstanding! |
| 18:23.59 |
d-lo |
Now, lets
hope that the plan and the implementation don't deviate by TOO much
;? |
| 18:24.01 |
d-lo |
;? |
| 18:24.32 |
Ralith |
hehe |
| 18:24.34 |
Ralith |
let's
hope. |
| 18:24.46 |
``Erik |
no plan
survives contact with the enemy. |
| 19:38.13 |
starseeker |
wonders if LLVM can build BRL-CAD yet |
| 19:38.35 |
Ralith |
cling would
be interesting to try. |
| 19:44.40 |
Ralith |
er |
| 19:44.41 |
Ralith |
clang |
| 19:59.27 |
starseeker |
Ralith: cling
should be the name of a de-compiler ;-) |
| 19:59.39 |
Ralith |
afks for a while |
| 20:02.36 |
*** join/#brlcad andax
(n=andax__@d213-102-40-191.cust.tele2.ch) |
| 20:06.02 |
CIA-28 |
BRL-CAD:
03indianlarry * r34639 10/brlcad/trunk/ (4 files in 3 dirs):
initial bulk trimming work |
| 20:06.06 |
``Erik |
w00t |
| 20:10.44 |
*** join/#brlcad andax_
(n=andax__@d213-102-40-19.cust.tele2.ch) |
| 20:24.56 |
*** join/#brlcad madant
(n=madant@117.196.128.61) |
| 21:34.38 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 21:41.51 |
Ralith |
bulk
trimming? |
| 21:45.53 |
starseeker |
there are
stages to the trimming algorithm we are implementing |
| 21:46.15 |
starseeker |
the first
does the "easy" cases - the second (harder) stage does the fine
work and needs more logic we don't have in there yet |
| 21:47.38 |
Ralith |
trimming
algorithm? >_> |
| 21:48.03 |
starseeker |
NURBS
surfaces usually have trimming curves that "trim away" parts of
the surface |
| 21:48.39 |
starseeker |
makes for
more flexible geometry, but you need to be "aware" of the impact of
the curves on the surface you are working with |
| 21:48.50 |
Ralith |
ah, nurbs
work. |
| 21:49.00 |
starseeker |
right |
| 22:05.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E0CE.dip.t-dialin.net) |
| 22:29.58 |
madant |
howdy
Ralith |
| 22:30.41 |
Ralith |
hullo |
| 22:36.59 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E43B.dip.t-dialin.net) |
| 22:50.15 |
madant |
how is qt
tinkering coming along ? |
| 22:50.23 |
madant |
i haven't
started mine yet :( |
| 23:13.01 |
CIA-28 |
BRL-CAD:
03brlcad * r34640 10/brlcad/trunk/src/other/openNURBS/ (Makefile.am
opennurbs_curve.cpp): temporary tcl header lookup |
| 03:04.48 |
CIA-28 |
BRL-CAD:
03brlcad * r34641
10/brlcad/trunk/src/tclscripts/lib/Command.tcl: |
| 03:04.48 |
CIA-28 |
BRL-CAD:
protect the gets rename the same way mged/text.tcl does it by
making sure the |
| 03:04.48 |
CIA-28 |
BRL-CAD: proc
has a body/exists first. the s2 folks reported that they're getting
an |
| 03:04.48 |
CIA-28 |
BRL-CAD:
error about gets not existing which would be consistent with the
Command.tcl |
| 03:04.48 |
CIA-28 |
BRL-CAD:
constructor getting read multiple times. |
| 03:17.01 |
brlcad |
teh awesome,
http://brlcad.org/tmp/goliath.png |
| 03:18.41 |
brlcad |
took 60 cores
to crunch that image out in about 3 hours :) |
| 03:18.53 |
brlcad |
granted it
was running at less than half-speed with all the verbose overlap
logging |
| 03:19.01 |
Ralith |
top's a
little overexposed |
| 03:19.26 |
Ralith |
but yeah,
very nice |
| 03:19.35 |
brlcad |
and there are
something like 16 spotlight light sources, 128 shadow rays,
texturing, bump-mapping, .. lots of reflectivity |
| 03:19.53 |
brlcad |
pretty
"expensive" picture |
| 03:20.09 |
Ralith |
pretty subtle
bumpmapping/texturing. |
| 03:20.15 |
brlcad |
yep,
intentionally |
| 03:20.25 |
Ralith |
I dunno, it
might've been a bit underboard, so to speak |
| 03:20.41 |
Ralith |
I have a hard
time telling it apart from a flat gray untextured model without
looking very close |
| 03:20.42 |
brlcad |
it's closer
to what it actually looks like |
| 03:20.57 |
Ralith |
okay |
| 03:21.09 |
Ralith |
I guess it
actually looks like an untextured model :P |
| 03:21.47 |
brlcad |
untextured
looks much different |
| 03:21.52 |
brlcad |
way too
'perfect'/clean |
| 03:22.33 |
Ralith |
I guess it's
the lack of a comparison that dose it |
| 03:22.42 |
Ralith |
does* |
| 03:25.05 |
brlcad |
and to
'finish' it off, a 2x2 subsampling to eliminate the aliasing and
rendering edges cleanly .. |
| 03:25.08 |
brlcad |
http://brlcad.org/tmp/goliath2.png |
| 03:27.53 |
brlcad |
4x4 would be
better, but that would take all night and there are other scenes of
the goliath also worth rendering |
| 03:28.46 |
brlcad |
was nice if
only just to sort out how remrt/rtsrv work once again, been a
couple years |
| 03:29.30 |
brlcad |
calls it and heads out |
| 03:53.37 |
*** join/#brlcad jdoliner
(n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) |
| 04:30.25 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) |
| 04:59.49 |
brlcad |
howdy
jdoliner |
| 05:00.06 |
starseeker |
that is an
awesome goliath |
| 05:00.53 |
brlcad |
it finished
shortly after you left |
| 05:00.58 |
starseeker |
heh
figures |
| 05:01.07 |
starseeker |
scowls at cat |
| 05:01.42 |
brlcad |
s/sc/throws
b/ |
| 05:02.06 |
starseeker |
nah, enough
broken glass here for one night |
| 05:02.17 |
starseeker |
she's a good
enough cat most of the time |
| 05:02.23 |
brlcad |
glass?
:) |
| 05:02.40 |
brlcad |
was thinking more the stone or metal variety
;) |
| 05:02.49 |
starseeker |
she knocked
over a lamp with an old style neon light bulb in it (you know, the
big round ones) |
| 05:02.59 |
starseeker |
ah
:-) |
| 05:06.08 |
brlcad |
thinks these will make a nice set of renderings for the
museum |
| 05:09.24 |
starseeker |
indeed,
they'll love it |
| 05:10.34 |
starseeker |
still would prefer to be sure the texture images are
something we can include in the repository |
| 05:11.19 |
brlcad |
now that it's
clear how it'll turn out, should have remrt quell overlaps, quell
liboptical light overlap reporting, and render an 8k x 8k for a
poster print |
| 05:11.34 |
starseeker |
:-) |
| 05:12.53 |
brlcad |
that's about
48 hours at the same settings and cpus, could probably triple the
cpu horsepower to have it done overnight |
| 05:13.42 |
brlcad |
should do the
other 2k's of the other 3 or so scenes first though |
| 05:13.54 |
brlcad |
then pick one
to posterfy |
| 05:14.11 |
starseeker |
heh - museum
could sell copies |
| 05:18.25 |
CIA-28 |
BRL-CAD:
03brlcad * r34642 10/brlcad/trunk/src/liboptical/photonmap.c: quell
overlap reporting for the non-primary photonmapping
rays |
| 05:32.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34643 10/brlcad/trunk/src/liboptical/photonmap.c: ws
style consistency cleanup, fix crazy equal alignment |
| 05:34.08 |
starseeker |
brlcad: can
you leave irc messages for people? |
| 05:34.18 |
starseeker |
for when they
reappear? |
| 05:34.21 |
brlcad |
memoserv |
| 05:38.10 |
starseeker |
thanks |
| 05:38.24 |
starseeker |
's brain gives out |
| 05:40.54 |
CIA-28 |
BRL-CAD:
03brlcad * r34644 10/brlcad/trunk/src/liboptical/refract.c:
propagate the same overlap logging behavior on refracted rays as on
the originating ray |
| 05:43.56 |
CIA-28 |
BRL-CAD:
03brlcad * r34645 10/brlcad/trunk/src/liboptical/sh_air.c: utilize
the same overlap logging when shooting rays via the (incomplete)
'textured mist' shader. |
| 05:44.23 |
CIA-28 |
BRL-CAD:
03brlcad * r34646 10/brlcad/trunk/src/liboptical/photonmap.c: ws
indent |
| 05:55.43 |
CIA-28 |
BRL-CAD:
03brlcad * r34647 10/brlcad/trunk/src/liboptical/sh_toyota.c:
propagate the overlap reporting callback for reflected texture
rays |
| 05:56.04 |
CIA-28 |
BRL-CAD:
03brlcad * r34648 10/brlcad/trunk/src/liboptical/ (refract.c
sh_light.c): ws, style, indent, consistency cleanup |
| 05:59.32 |
CIA-28 |
BRL-CAD:
03brlcad * r34649 10/brlcad/trunk/src/liboptical/sh_light.c: the
biggest offenders of all when there are many light sources and/or
lots of shadow calsbs. shoot an abundance of shadow rays but now
utilizing the same overlap verbosity as the primary application
ray. |
| 06:01.31 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 06:03.42 |
CIA-28 |
BRL-CAD:
03brlcad * r34650 10/brlcad/trunk/NEWS: |
| 06:03.42 |
CIA-28 |
BRL-CAD: all
of the raytracers should now respect an application-defined overlap
callback |
| 06:03.42 |
CIA-28 |
BRL-CAD:
including (most importantly) the ability to have a lot of light
sources with |
| 06:03.42 |
CIA-28 |
BRL-CAD:
shadows and not have overlaps profusely reported particularly when
the ray |
| 06:03.42 |
CIA-28 |
BRL-CAD:
tracer is told to be quiet. |
| 07:24.11 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) |
| 07:56.23 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 08:55.30 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 09:03.26 |
*** part/#brlcad jdoliner
(n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) |
| 10:28.24 |
d-lo |
mernin
all! |
| 10:30.56 |
d-lo |
brlcad: Heh,
so what prompted the rt/light fix in r34650 ? =D |
| 10:38.49 |
d-lo |
brlcad: Kudos
on the lighting Wiki page! +1 Digg |
| 10:52.11 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DA3A.dip.t-dialin.net) |
| 11:43.07 |
starseeker |
staggers back to an awake state |
| 11:46.51 |
d-lo |
Staggers?
heh, have a good night then eh? |
| 11:51.42 |
starseeker |
nope. Cat
knocked over a lamp with an old style circular bulb in it (think
office celing light, just curved into a circle) so I got to get
home and spend time on glass cleanup and laundry |
| 11:52.07 |
starseeker |
tried hard to
get some NURBS work done but brain shut down just before
2am |
| 11:52.57 |
starseeker |
is surprised indianlarry isn't in yet |
| 11:53.31 |
d-lo |
I think he is
here.... |
| 11:53.46 |
d-lo |
here, as in
at work, if not on irc |
| 11:53.48 |
starseeker |
indianlarry:
online? |
| 11:55.03 |
indianlarry |
yes
sorry |
| 11:55.08 |
starseeker |
np -
morning! |
| 11:55.16 |
indianlarry |
how it
go |
| 11:55.43 |
starseeker |
's brain thinks it should still be in the OFF setting - I'm
convincing it otherwise |
| 11:55.57 |
starseeker |
had a couple
questions on the trimming code |
| 11:56.04 |
indianlarry |
sure |
| 11:56.31 |
starseeker |
if I've got
it right, the CurveTree is being built in the preprocess-trims
stage, and does not persist beyond that stage
currently? |
| 11:56.49 |
starseeker |
i.e., when we
get to the utah_isTrimmed stage the tree isn't present? |
| 11:57.14 |
indianlarry |
the curves
should be attached to each 3d subdivision |
| 11:57.27 |
starseeker |
ok - where
are they stored? |
| 11:59.16 |
starseeker |
knows that's embarassingly basic - sorry |
| 12:00.27 |
indianlarry |
in the top
surfacetree object there's an xsorted list of all curve segments
'm_sortedX' ad an y sorted list 'm_sortedY' |
| 12:00.41 |
indianlarry |
sorry
probably need to change to U,V references |
| 12:00.47 |
starseeker |
ah,
ok |
| 12:00.52 |
indianlarry |
then in each
subdivision |
| 12:01.50 |
indianlarry |
there is an
'm_trims_above' and an 'm_trims_right' list |
| 12:02.30 |
indianlarry |
so far it
looks like i can remove the right and ysorted list |
| 12:02.32 |
starseeker |
does it being
private mean we won't be able to get at it from
brep.cpp? |
| 12:03.02 |
starseeker |
indianlarry:
I'd leave them for the moment |
| 12:03.20 |
indianlarry |
just intend
to access through member functions like isTrimmed(u,v) |
| 12:03.22 |
starseeker |
at least,
until we hit it with some tougher geometry |
| 12:03.51 |
starseeker |
Oh, I
see |
| 12:04.01 |
indianlarry |
i'll put the
quick linear is in test should get us one step closer before
newton |
| 12:04.07 |
starseeker |
cool |
| 12:04.16 |
indianlarry |
you all stay
up too late |
| 12:04.27 |
starseeker |
heh |
| 12:04.52 |
indianlarry |
i'll get
crackin and try to clean it up a bit |
| 12:05.24 |
starseeker |
np - I saw
that TODO about finding multiple overlapping boxes and figured that
was needed for the more "detailed" trimming |
| 12:05.50 |
starseeker |
opennurbs_ext.h line 909
currently |
| 12:06.41 |
indianlarry |
yea should
only happen in special cases but can happen (sharp edge turned back
on self) |
| 12:07.19 |
starseeker |
thought we
were going to make a list of all overlapping trim segments and
store that for an isTrimmed test, but perhaps the above+right
method gives us a subset that contains that subset and is "close
enough" without doing the extra work of identifying the actually
overlapping line segments |
| 12:08.18 |
starseeker |
is the set of
above+right guaranteed to contain all possible intersecting trim
line segments? |
| 12:08.28 |
indianlarry |
actually just
the above should give us everything i'll probably remove the
right |
| 12:08.35 |
starseeker |
really |
| 12:08.42 |
starseeker |
huh |
| 12:09.08 |
indianlarry |
i think
so |
| 12:09.46 |
starseeker |
oh, right -
do the brain experiment of trying to construct a trim line that
intersects, has a line segment to the right, and NOT a line segment
in or above (both of which should show up as "above"?) |
| 12:10.04 |
indianlarry |
you got
it |
| 12:10.25 |
starseeker |
<Windows
NT booting noise> |
| 12:10.28 |
starseeker |
brain coming
up |
| 12:10.34 |
indianlarry |
heh |
| 12:11.15 |
indianlarry |
do you try
openbook? |
| 12:11.27 |
starseeker |
yeah - it
actually looks impressive! |
| 12:11.37 |
indianlarry |
how long in
prep |
| 12:11.49 |
starseeker |
because it
has so many small nurbs surfaces, it actually gets startlingly
close |
| 12:11.56 |
starseeker |
not too
long |
| 12:12.02 |
starseeker |
Sean wasn't
at all bothered |
| 12:12.09 |
indianlarry |
cool we're on
the way |
| 12:15.14 |
starseeker |
indianlarry:
so for the IsTrimmed test, you will take the list of above line
segments from the m_trims_above subdivision entry, check each
segment bounding box to see if it truly is above or inside, and if
inside find the box with the closest linear approximation based
closest point to the hit point? |
| 12:15.49 |
starseeker |
then if we
need to, inside that last box we can go from the linear approx.
based test to an actual closest point test? |
| 12:17.29 |
indianlarry |
yes |
| 12:17.48 |
starseeker |
ok, I get it
now :-) |
| 12:18.00 |
indianlarry |
i'm thinkang
about carrying the vdot to bound the iteration |
| 12:18.38 |
indianlarry |
and
precomputed slope |
| 12:18.39 |
starseeker |
might be a
good idea |
| 12:19.32 |
starseeker |
is glad he didn't muck with the code too much last night -
would have done waaaay more work for less
benefit |
| 12:19.56 |
starseeker |
was mentally
stuck on getting a list of JUST overlapping sections, not
overlapping plus above |
| 12:20.26 |
starseeker |
when the
correct answer is probably "meh, we can sort that out cheaply and
quickly at IsTrimmed" |
| 12:21.20 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DA3A.dip.t-dialin.net) |
| 12:21.31 |
indianlarry |
hopefully
i'll have something before you get in |
| 12:21.37 |
starseeker |
thinks some ascii-art uv space pictures might be in order for
code documentation of these structures... |
| 12:21.48 |
starseeker |
indianlarry:
probably - I've got to get it together here :-) |
| 12:21.55 |
starseeker |
indianlarry:
awesome, awesome work |
| 12:23.40 |
indianlarry |
starseeker:
your idea |
| 12:25.24 |
starseeker |
not so much
with how do deal with the trimming curves and boxes |
| 12:25.33 |
starseeker |
er to deal
with |
| 12:26.06 |
starseeker |
hunts for a way to ascii art output vector
drawings... |
| 12:29.07 |
starseeker |
maybe create
by hand, we'll see |
| 13:17.41 |
*** join/#brlcad madant
(n=madant@117.196.130.89) |
| 13:24.44 |
starseeker |
here are some
text versions of the uv parameter space: http://bzflag.bz/~starseeker/uvfig.txt |
| 13:24.52 |
madant |
brlcad: can i
have access to a decent computer somewhere :) something which has
lesser than 2 hour build time i mean |
| 13:49.58 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 13:55.39 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 14:16.04 |
brlcad |
starseeker:
what are the vertical lines? |
| 14:47.26 |
starseeker |
2D raytrace
paths |
| 14:58.43 |
``Erik |
why, is that
a metaball on that lighting page? :D |
| 15:00.16 |
brlcad |
because it's
what I snarfed from wikipedia |
| 15:00.27 |
``Erik |
doh |
| 15:02.37 |
``Erik |
then you
should probably do something to note where it came from or
something to comply with the gfdl |
| 15:06.36 |
brlcad |
i
did |
| 15:06.43 |
brlcad |
feel free to
make it better :P |
| 15:17.36 |
``Erik |
oh, click to
follow, okie |
| 15:17.46 |
``Erik |
you're not in
today? (at least, not in the next 13 minutes?) |
| 15:33.05 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:43.33 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:48.16 |
elena |
hi |
| 16:19.21 |
starseeker |
hey
elena |
| 16:19.33 |
elena |
hi
starseeker |
| 16:19.35 |
starseeker |
how's it
going? |
| 16:19.52 |
elena |
almost ready
with the theme. |
| 16:20.01 |
elena |
i've worked
locally until now |
| 16:20.09 |
elena |
and soon will
start to use svn. |
| 16:20.21 |
starseeker |
yeah, you
need to be using svn throughout |
| 16:20.30 |
starseeker |
need an intro
to it? |
| 16:20.33 |
elena |
brlcad said i
should use it and commit frequent. |
| 16:20.42 |
starseeker |
he's
right |
| 16:21.02 |
elena |
i read about
it and i checkout the more folder |
| 16:21.05 |
starseeker |
if you're not
set up for that, that's definitely the next thing to do |
| 16:21.08 |
elena |
which is
empty now. |
| 16:21.23 |
starseeker |
uh, I thought
it was web |
| 16:21.29 |
starseeker |
checks |
| 16:21.38 |
elena |
web/htdocs/more |
| 16:22.01 |
starseeker |
ok. you're
working in that directory? |
| 16:22.22 |
elena |
i guess so.
isn't that where I should? |
| 16:22.39 |
starseeker |
sure. just
need to commit |
| 16:22.54 |
elena |
aha. |
| 16:23.05 |
elena |
i was
expecting to find the drupal code in d folder. |
| 16:23.16 |
elena |
but only has
the site settings. |
| 16:23.33 |
elena |
in the more
may i commit the drupal code? |
| 16:23.41 |
elena |
or it goes in
some other place? |
| 16:24.37 |
starseeker |
go ahead and
commit - we can always undo |
| 16:24.46 |
starseeker |
put it where
it works, we can fix it if we need to |
| 16:24.46 |
elena |
ok. |
| 16:24.59 |
elena |
this is the
theme i started with http://drupal-5x.themebot.org/?theme=fireflystreamcom |
| 16:25.31 |
elena |
but i made
some changes to it. |
| 16:26.04 |
elena |
i liked the
colors. |
| 16:26.06 |
elena |
:) |
| 16:26.35 |
starseeker |
don't worry
about the theme much - first order of business is the core
functionality |
| 16:26.42 |
starseeker |
themes
later |
| 16:26.47 |
elena |
ok. |
| 16:27.21 |
elena |
i'll get an
preview version this week. |
| 16:28.10 |
starseeker |
sounds good
:-) |
| 16:28.19 |
elena |
can you check
is the svn tags are ok? |
| 16:28.21 |
starseeker |
you can check
in without being finished |
| 16:28.39 |
starseeker |
tags? |
| 16:28.40 |
elena |
brlcad said
you could make sure they are "set properly". |
| 16:28.51 |
elena |
i don't know
exactly how to do that. |
| 16:29.02 |
elena |
maybe he did
it when added more to the svn. |
| 16:30.09 |
starseeker |
OK, I'll
check with him and do what needs doing |
| 16:30.13 |
starseeker |
if
anything |
| 16:30.14 |
elena |
i believe
that is what he said "tags set properly". sorry, I don't remember
exactly :( |
| 16:30.25 |
elena |
thank
you. |
| 16:30.36 |
elena |
~log |
| 16:30.37 |
ibot |
well, log is
http://ibot.rikers.org/%23wowhead/ |
| 16:30.37 |
starseeker |
you can
commit? |
| 16:31.23 |
elena |
i didn't try
yet. i have the code in another folder. |
| 16:31.23 |
starseeker |
I think it's
actually http://ibot.rikers.org/%23brlcad/ |
| 16:31.45 |
starseeker |
might as well
give it a whirl and see :-) |
| 16:31.55 |
elena |
ok. i
will. |
| 16:32.09 |
starseeker |
Don't be shy
- we're here to help :-) |
| 16:32.18 |
elena |
:) |
| 16:32.34 |
starseeker |
I've
committed any number of embarassingly bad things |
| 16:33.47 |
starseeker |
and I can't
spell :-P |
| 16:35.11 |
elena |
i found it.
he said: "the basics are pretty simple, perhaps starseeker can help
walk you through setting up a new repository module with the
trunk/branches/tags set up properly" |
| 16:35.31 |
elena |
but then
asked for my sf username and maybe he did it. |
| 16:35.51 |
elena |
http://ibot.rikers.org/%23brlcad/20090601.html.gz |
| 16:36.16 |
starseeker |
kinda looks
like there are branches and tags directories, but I doubt we'll
need them yet |
| 16:36.26 |
elena |
ok. |
| 16:36.37 |
starseeker |
unless he's
got something specific in mind, I would expect you'd work in
trunk |
| 16:36.52 |
starseeker |
checks log |
| 16:37.47 |
starseeker |
well,
maybe... |
| 16:39.07 |
starseeker |
ah, yeah -
we're using the "web" module so we don't need to set up a new
one |
| 16:39.21 |
elena |
ok. |
| 16:39.30 |
elena |
module ==
folder ? |
| 16:39.56 |
starseeker |
kinda |
| 16:40.04 |
starseeker |
functionally
that's about it |
| 16:41.11 |
starseeker |
basically
work you do won't impact work in the iBME, brlcad or jbrlcad
efforts (which have their own build systems, etc.) |
| 16:41.30 |
elena |
aha. |
| 17:31.52 |
*** join/#brlcad jdoliner
(n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) |
| 17:50.32 |
elena |
i
get: |
| 17:50.38 |
elena |
svn: Commit
failed (details follow): |
| 17:50.45 |
elena |
Commit
blocked by pre-commit hook (exit code 1) with output: |
| 17:50.59 |
elena |
/var/local/mastertree/host/sfp-svn/hook-scripts/check-mime-type.pl: |
| 17:51.15 |
elena |
then for each
file says: svn:mime-type is not set |
| 17:51.48 |
elena |
in the end it
suggests to use svn propset svn:mime-type for each
file. |
| 17:53.02 |
elena |
or : You may
want to consider uncommenting the auto-props section in your
~/.subversion/config file. |
| 17:53.28 |
elena |
oh. obvious.
:) |
| 17:53.40 |
d-lo |
righto. If
you are trying to commit code, then use 'svn propset svn:mime-type
text/plain' |
| 17:53.49 |
d-lo |
or whatever
mime-type is needed. |
| 17:54.17 |
elena |
i'll
uncomment that line since there are too many files to do it
manually. |
| 17:54.42 |
elena |
i didn't
understand what it says until I pasted it. :) |
| 17:57.40 |
d-lo |
irc will
eventually solve the world's problems. :) |
| 17:59.21 |
``Erik |
by removing
humans from it? :D |
| 18:07.31 |
*** join/#brlcad indianlarry
(n=indianla@bz.bzflag.bz) |
| 18:11.21 |
d-lo |
``Erik: only
certain humans |
| 18:12.04 |
``Erik |
namely; those
that use irc? :D |
| 18:14.04 |
d-lo |
that cyclic
logic just made my nose bleed.... :/ |
| 18:14.23 |
brlcad |
madant: still
working on it, but you might have to just go with slow (and learn
how to only do subbuilds) .. |
| 18:14.35 |
brlcad |
haven't had
the time to get things set up |
| 18:16.35 |
``Erik |
"how not to
hummer your business" ow O.o |
| 18:17.50 |
brlcad |
elena: yeah,
by using the existing 'web' module, the trunk/branches/tags was
already set up, then I further cleaned up the checkout by putting
in the more pertinent config files |
| 18:18.26 |
elena |
ok. thank
you. |
| 18:20.40 |
brlcad |
elena: that's
your own box of sand to work in, though, you can put what you
want/need into there |
| 18:21.18 |
elena |
i'm about
to. |
| 18:21.26 |
elena |
still
fighting svn :) |
| 18:21.35 |
starseeker |
elena: this
is helpful http://brlcad.org/wiki/Mime-types |
| 18:21.39 |
elena |
i'll commit
drupal first. |
| 18:21.54 |
elena |
i think i got
it. |
| 18:22.00 |
elena |
commiting
now. |
| 18:22.02 |
elena |
thanks. |
| 18:22.18 |
starseeker |
the
subversion config there saves a LOT of the propset
stuff |
| 18:22.23 |
elena |
it doesn't
seem hard, it's just the first time. |
| 18:23.42 |
brlcad |
the example
config file on the wiki will auto-set props on a lot of file
types |
| 18:23.44 |
starseeker |
you will grow
to love svn, especially after your first major accidental
overwrite/save disaster ;-) |
| 18:23.56 |
brlcad |
because you
want mime types to be set as wel as eol-style |
| 18:24.44 |
starseeker |
for large
commits of lots of new files, that config file is all but
essential |
| 18:25.02 |
starseeker |
REALLY
suggest getting it set up |
| 18:25.31 |
elena |
ok. i got
it. |
| 18:25.41 |
elena |
i'll add
drupal specific files, too |
| 18:35.25 |
elena |
goes to get dinner |
| 18:41.43 |
brlcad |
happy
hunting |
| 18:43.46 |
brlcad |
elena: and
you really must commit before doing any more work :) |
| 18:44.28 |
brlcad |
same goes for
everyone really |
| 18:45.40 |
brlcad |
hardest new
dev behavior, antisocial, actually counterproductive in the long
run the longer time between/until commits |
| 18:56.44 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:59.20 |
louipc |
could they
set up a personal repo and merge their work in? |
| 19:01.19 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 19:01.46 |
brlcad |
louipc: only
if they're doing so several times a day |
| 19:02.16 |
brlcad |
the point
isn't so much the revision control as it is the communication of
how and why development occurs to others, throughout the whole
process |
| 19:02.26 |
brlcad |
not just some
checkpointed end-result |
| 19:02.42 |
brlcad |
it's a
communication mechanism |
| 19:02.47 |
louipc |
yeah |
| 19:03.23 |
louipc |
I was
thinking it could help wean new devs on the idea of frequent
commits. |
| 19:04.05 |
brlcad |
usually
happens best when they just dive in head first |
| 19:04.13 |
louipc |
haha good
stuff |
| 19:04.20 |
brlcad |
so the
benefits become evident more quickly |
| 19:04.21 |
brlcad |
seriously |
| 19:04.46 |
brlcad |
if it's only
partial, the opposite occurs -- they'll wean themselves into less
and less frequent commits eventually into isolation |
| 19:06.03 |
brlcad |
happens
nearly universal, particular when they're new or insecure or
(intentionally or unintentionally) subversive and generally
'afraid' of being open about their development process |
| 19:06.08 |
brlcad |
and
activities |
| 19:06.28 |
louipc |
I guess it
depends on the person really |
| 19:07.45 |
brlcad |
it does, but
the tendency is pretty universal particularly for new
developers |
| 19:07.52 |
starseeker |
typically the
fear is betray of inexperience/inability - everybody starts out
that way, but none of us like to admit it ;-) |
| 19:08.05 |
louipc |
yeah |
| 19:08.17 |
brlcad |
nobody wants
to show their mistakes |
| 19:08.23 |
starseeker |
the point
isn't don't make mistakes - the point is figure them out and fix
'em |
| 19:08.39 |
brlcad |
want
everything to be "just perfect" before they share it, like working
on a piece of art that is finally unveiled |
| 19:09.23 |
brlcad |
unfortunately, these are living works of
art that have to be worked on by others if they are to survive,
long after their contribution |
| 19:09.32 |
starseeker |
this trend
can be encouraged by environments that a) punish mistakes and b)
take a silly mistake as evidence of incompetence |
| 19:09.39 |
louipc |
that's why I
like the idea of patches and reviewing them with others, they don't
need to go into the working code until they're right |
| 19:09.55 |
louipc |
but you still
get the communication and everything |
| 19:10.17 |
starseeker |
good project
management has to be very constructive - work to solve problems and
improve people's skills |
| 19:10.26 |
brlcad |
code is
easily read 10 times more than it is written, communicating
intention and process throughout the development becomes critical,
otherwise it's actually 'cheaper' to throw their contribution out
the window and rewrite it from scratch |
| 19:11.09 |
brlcad |
(openly) |
| 19:11.27 |
louipc |
yep |
| 19:12.32 |
starseeker |
the only
times when there is justification for working long on code in
isolation is something like a mathematical algorithm in a CAS
system where it is easy to get code that produces AN answer and
it's (very) difficult to be sure it's the RIGHT answer just by
looking at the answer. In that case, releasing code that gives
"an" answer is an invitation to misuse. But such cases are
EXTREMELY rare |
| 19:13.46 |
starseeker |
I don't think
BRL-CAD really has any such cases - the closest is probably
analytical ray tracing for things like weight or surface area, but
even there the answer itself serves as a sanity check - it has
physical meaning |
| 19:16.09 |
``Erik |
of course,
releasing code that gives "an" answer may invite people to review
and possibly correct or ask useful questions |
| 19:16.55 |
starseeker |
my experience
with mathematical software suggests it's far more likely to be used
by people to solve pratical problems than to be reviewed with the
care necessary to detect subtle errors |
| 19:17.27 |
starseeker |
there is a
reason mathematical problems drive formal methods in coding
;-) |
| 19:17.45 |
louipc |
just make
sure you put a disclaimer |
| 19:17.51 |
``Erik |
heh, and
there's a reason that copy&paste coding is considered harmful
:D |
| 19:18.26 |
starseeker |
copy/paste in
what sense? |
| 19:18.36 |
louipc |
I copy
paste |
| 19:18.47 |
``Erik |
people who
grab code without understanding what it does and shove it
in |
| 19:19.34 |
starseeker |
ah. I was
thinking more along the lines of people solving engineering
problems and plugging their values into a "solver" for their
particular equation |
| 19:20.48 |
``Erik |
so like a
copy&paste coder who uses a library without knowing what it
does underneath and doesn't care to learn because it's already
there? :D |
| 19:21.30 |
``Erik |
we were
actually having a discussion about which sorting algorithm to use
for the nurb trimming this morning, heh :D |
| 19:22.16 |
louipc |
haha I was
taught the virtues of not knowing/caring what a library's function
was doing, only what you put in and got out |
| 19:22.32 |
starseeker |
``Erik: in
commercial coding, they probably won't LET you see the code behind
the library |
| 19:22.36 |
louipc |
kind of bad I
guess... |
| 19:22.58 |
``Erik |
well, I'm
thinking basic operations, like the set and sort stuff in
jabba |
| 19:23.16 |
``Erik |
*shrug* |
| 19:23.28 |
starseeker |
basic
operations are more likely to be correct, just statistically
speaking |
| 19:23.43 |
starseeker |
simpler, more
use cases that will shake out errors |
| 19:23.44 |
``Erik |
one of the
neat things about STL was that it explicitely defined the
asymptotic behavior |
| 20:06.11 |
*** join/#brlcad andax
(n=andax__@d213-102-41-16.cust.tele2.ch) |
| 20:18.34 |
CIA-28 |
BRL-CAD:
03indianlarry * r34651 10/brlcad/trunk/ (3 files in 3 dirs):
started second level of NURB trimming using linear
approximation |
| 20:38.19 |
CIA-28 |
BRL-CAD:
03ebautu * r34652 10/web/trunk/htdocs/more/ (327 files in 52 dirs):
Initial commit. Drupal 5.18 |
| 20:38.39 |
brlcad |
woot
:) |
| 20:38.44 |
brlcad |
~elena++ |
| 20:38.50 |
starseeker |
excellent |
| 20:39.55 |
brlcad |
starseeker:
even when working on a mathematical algorithm, you're not
necessarily releasing that effort into production -- committing
doesn't mean it has to be enabled for end-user use |
| 20:41.02 |
brlcad |
quite the
contrary, you can get some synergy where someone instantly
recognizes a flaw early that saves the would-be-isolationist from
going down the wrong path with bad assumptions/axioms for
hours/days/weeks on end |
| 20:41.19 |
brlcad |
or help with
testing the implementation or documenting right away,
etc |
| 20:42.28 |
elena |
hurray. it
finished. |
| 20:42.31 |
brlcad |
most of what
you refer to is a matter of making it user-visible and announced or
at least active for use |
| 20:42.39 |
brlcad |
elena:
hurrah! :) |
| 20:42.46 |
elena |
it turns out
i had to remove everything and svn add them again. |
| 20:42.58 |
brlcad |
yeah, props
will do that |
| 20:43.08 |
brlcad |
(wiki page
mentioned that) ;) |
| 20:43.27 |
elena |
:( |
| 20:43.28 |
starseeker |
brlcad: true
- I guess the problem with some of those projects is the line
between "user visible" and "commited to public repository" isn't
really there |
| 20:43.48 |
brlcad |
project
infrastructure |
| 20:43.56 |
starseeker |
elena: It
will get better - commiting large amounts of other code generally
causes the most trouble with props |
| 20:44.12 |
starseeker |
shudders at the memory of the docbook
commits... |
| 20:44.14 |
brlcad |
have to
provide some way for code to develop openly but distinguished from
vetted algorithms |
| 20:44.17 |
elena |
btw, you
should change the room title... |
| 20:45.12 |
elena |
now that
config is set, the following adds/commits should work
ok. |
| 20:46.04 |
elena |
now i'll
checkout on the server :) |
| 20:46.45 |
``Erik |
find . -name
.whatever -print0 | xargs -0 svn propset ... |
| 20:46.58 |
``Erik |
*.whatever,
even |
| 20:47.05 |
``Erik |
:D |
| 20:48.06 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code
code, type type, commit! commit frequently (multiple times daily)
while you work. update wiki daily on progress. |
| 20:54.44 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code
code, type type, commit frequently while you work! update wiki/blog
on daily progress. |
| 20:55.29 |
CIA-28 |
BRL-CAD:
03ebautu * r34653 10/web/trunk/htdocs/more/.htaccess: Initial
commit. Drupal 5.18 (cont) |
| 20:57.34 |
elena |
i forgot some
(hidden) files. |
| 20:57.54 |
CIA-28 |
BRL-CAD:
03ebautu * r34654 10/web/trunk/htdocs/more/profiles/default/ (.
default.profile): Initial commit. Drupal 5.18 (cont) |
| 21:00.26 |
elena |
may I create
a database/user? |
| 21:03.00 |
*** join/#brlcad andax
(n=andax__@d213-102-41-187.cust.tele2.ch) |
| 21:06.37 |
CIA-28 |
BRL-CAD:
03ebautu * r34655 10/web/trunk/htdocs/more/sites/: Added
more.brlcad.org but svn:ignored. |
| 21:11.51 |
CIA-28 |
BRL-CAD:
03ebautu * r34656 10/web/trunk/htdocs/more/sites/all/themes/ (33
files in 3 dirs): Added fireflystream theme (initial
commit) |
| 21:16.50 |
``Erik |
ahhh
hhhhaaaaaaaaaa |
| 21:22.20 |
brlcad |
elena:
sure |
| 21:22.26 |
brlcad |
let me know
if you need a hand |
| 21:22.31 |
elena |
thanks. |
| 21:22.47 |
brlcad |
just
shouldn't allow remote connections |
| 21:22.57 |
elena |
ok. |
| 21:24.45 |
brlcad |
elena: you
didn't have to use 5.x simply because the current site
is |
| 21:24.56 |
brlcad |
don't know if
that was why or just because it's more stable |
| 21:25.21 |
elena |
i like it
better than 6. |
| 21:25.32 |
brlcad |
PrezKennedy:
you there? |
| 21:30.19 |
elena |
brlcad I
can't create it. i don't have the rights. |
| 21:30.52 |
elena |
can you help
me? |
| 21:36.21 |
*** join/#brlcad _sushi_
(n=_sushi_@80-219-40-111.dclient.hispeed.ch) |
| 21:53.16 |
brlcad |
yup, send me
user/pass in pm |
| 22:22.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) |
| 23:18.29 |
*** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 23:19.31 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 23:20.22 |
Ralith |
anyone else
having lots of [near-]timeouts? |
| 23:44.11 |
brlcad |
Ralith: I
was, but not now |
| 23:48.32 |
CIA-28 |
BRL-CAD:
03starseeker * r34657 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): |
| 23:48.32 |
CIA-28 |
BRL-CAD:
closest NURBS trimming curve shouldn't ever be NULL - assign
closest to the |
| 23:48.32 |
CIA-28 |
BRL-CAD:
first curve in all cases, then check for anything better. Visual
artifacts now |
| 23:48.32 |
CIA-28 |
BRL-CAD: more
consistent with that expected for stage 2 trimming - activating
and |
| 23:48.32 |
CIA-28 |
BRL-CAD:
committing. |
| 00:23.47 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) |
| 00:51.04 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 01:03.13 |
``Erik |
heh, pheer ~{
~} |
| 01:10.55 |
Ralith |
? |
| 01:11.17 |
Ralith |
as in, the
lisp format thingies? |
| 01:25.20 |
``Erik |
yeah |
| 01:27.25 |
Ralith |
has been teaching himself lisp |
| 01:27.30 |
Ralith |
very fun
stuff. |
| 01:28.14 |
``Erik |
indeed |
| 01:28.20 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 01:57.18 |
brlcad |
howdy
pacman87 |
| 01:57.42 |
brlcad |
ready to code
yet? :) |
| 02:00.48 |
*** join/#brlcad mike
(n=mike@cadil21.kaist.ac.kr) |
| 02:00.56 |
Mike111 |
hi
all |
| 02:03.44 |
brlcad |
howdy
Mike111 |
| 02:04.19 |
Mike111 |
hi brlcad;
how are you? |
| 02:09.02 |
Mike111 |
I will have a
non-brlcad model supplied (maybe as IGES or DXF). I want to change
the model, that is, replace an original object (component in the
model) with my own. How do I do that? |
| 02:09.16 |
brlcad |
i'm great,
busy times but great |
| 02:09.26 |
brlcad |
can't wait to
see how these renders turn out... |
| 02:09.50 |
brlcad |
Mike111: it
totally depends on the supplied model and how it's
structured |
| 02:10.55 |
Mike111 |
they model
won't be a brl-cad format so there won't be a `tree' of
combinations or primitives |
| 02:10.56 |
brlcad |
many imports
come in as polygonal meshes, which suck to edit (in brl-cad) beyond
affine transforms (translation/rotation/scale) and
delete/duplicate/replace |
| 02:11.13 |
brlcad |
it may still
be a collection of 'parts' |
| 02:11.34 |
brlcad |
if your
editing intent is to replace a given part, you should be able to
delete the part and replace it with your own |
| 02:12.37 |
Mike111 |
is there a
way to automate this, if I need to do this repeatedly for the same
model (try several different components) |
| 02:14.45 |
``Erik |
you're asking
if BRL-CAD can automatically remove regions and replace them with
other (different) geometry? O.o |
| 02:15.36 |
Mike111 |
if I can
script this operation, that is, define which part I want to remove,
remove it and then attach the new part |
| 02:15.38 |
brlcad |
if what
you're doing is identically repetitive or repetitive in some
prescribed pattern, sure it could be automated |
| 02:15.51 |
brlcad |
heavily
scriptable system |
| 02:15.59 |
brlcad |
pick your
poison/language |
| 02:16.15 |
brlcad |
tcl inside
mged, anything outside |
| 02:16.27 |
``Erik |
plus the
clone and pattern tools |
| 02:16.53 |
brlcad |
example
scripting here: http://brlcad.org/wiki/SGI_Cube |
| 02:17.00 |
Mike111 |
so far I've
written script which I just piped in mged (a series of mged
commands) |
| 02:17.25 |
Mike111 |
the SGI
example is good. clear to follow. |
| 02:17.51 |
Mike111 |
Erik: what
are those? |
| 02:18.19 |
``Erik |
commands
inside of mged |
| 02:20.17 |
brlcad |
Mike111: lots
of commands categorized and listed in: http://brlcad.org/w/images/5/52/MGED_Quick_Reference_Card.pdf |
| 02:20.30 |
brlcad |
as well as
the appendix of the MGED Tutorial |
| 02:21.54 |
Mike111 |
Thanks. |
| 02:22.31 |
Mike111 |
still not
clear to me how exactly do I select a part of a DXF or IGES
model. |
| 02:24.14 |
``Erik |
depends on
how it converts |
| 02:24.40 |
Mike111 |
brl-cad can
import these formats directly, right? |
| 02:25.14 |
brlcad |
yes, there's
dxf-g and iges-g |
| 02:25.31 |
brlcad |
if they have
multiple objects, they will import as multiple objects |
| 02:25.38 |
brlcad |
give it a
try, see what it does :) |
| 02:26.31 |
Mike111 |
once I loaded
a DXF or IGES model, how do I check its `tree'? with
`ls'? |
| 02:27.33 |
``Erik |
sure, or fire
up the geometry viewer |
| 02:27.49 |
brlcad |
tops, l, ls
*, tree, ... |
| 02:28.08 |
brlcad |
lots of ways
-- Tools -> Geometry Browser will show you
graphically |
| 02:29.14 |
*** join/#brlcad feuerret
(n=841900d2@bz.bzflag.bz) |
| 02:30.41 |
Mike111 |
do you know a
good GPL meshing program? |
| 02:31.05 |
starseeker |
you mean mesh
editing or mesh conversion? |
| 02:32.45 |
Mike111 |
I mean
meshing a model (not conversion), that is, taking a 3d model and
creating a mesh (say unstructured) on the skin |
| 02:33.25 |
Mike111 |
Other
applications (such as structural analysis) need a mesh to analyze a
model |
| 02:33.28 |
starseeker |
um. it
depends on what input data you're starting with. point cloud? CSG
model? nurbs surface? |
| 02:34.42 |
Mike111 |
I will have a
CSG model which I generate in brl-cad. |
| 02:35.14 |
``Erik |
g-stl
? |
| 02:35.24 |
Mike111 |
Later on, I
may have a model which is imported (DXF or IGES) plus a component
made in brl-cad |
| 02:35.45 |
Mike111 |
Erik: you
mean exporting the brl-cad model into stl? |
| 02:36.29 |
brlcad |
many of our
exporters mesh on output |
| 02:36.36 |
brlcad |
g-dxf, g-stl,
g-obj, g-nff, g-x3d, etc |
| 02:36.41 |
``Erik |
plus there's
an mged command called "facetize" which converts the named region
to a triangle version |
| 02:37.05 |
brlcad |
those formats
don't support CSG or implicit geometry, so we have to convert to
their representation |
| 02:39.23 |
brlcad |
if you really
want to get fancy for FEA purposes, the recommended approach would
probably be to buy a Cubit license ($300 for 5-years) and use our
g-sat converter which hooks to Cubit |
| 02:39.33 |
brlcad |
their meshing
facilities are some of the best for FEA |
| 02:40.25 |
brlcad |
as for free,
there's not really a lot of good meshers for FEA purposes that are
open source, at least not that preserve solidity |
| 02:54.59 |
Mike111 |
the lab here
used a mesh generator running on CentOS linux. |
| 02:55.16 |
*** join/#brlcad Feuerret
(n=841900d2@bz.bzflag.bz) |
| 02:55.30 |
Mike111 |
as I
understand, it needs an IGES file which `only describes the skin'
(outer surface of the model) |
| 02:55.37 |
Mike111 |
that's what
the lab users just told me |
| 02:56.58 |
brlcad |
yeah, iges
supports a wide variety of geometry including skin-only
models |
| 02:57.25 |
brlcad |
we call them
"plate-mode bots", and such an iges should import as such
iirc |
| 02:57.31 |
Mike111 |
can I
directly export the model as `skin-only' from brl-cad or one its
exporters? |
| 02:57.42 |
brlcad |
"bots" ==
"bag of triangles" |
| 02:58.07 |
brlcad |
we only
export skin-only if it imported as skin-only |
| 02:58.41 |
Mike111 |
what is I
create the model in brl-cad from scratch? |
| 02:58.57 |
brlcad |
those are
solid models |
| 03:00.11 |
Mike111 |
so they
cannot be exported as `skin-only'? |
| 03:00.32 |
brlcad |
a solid model
that is tessellated to a bot is trivial to convert to a plate-mode
bot |
| 03:00.59 |
brlcad |
I'm not sure
I believe that you actually need skin models though, *especially*
if it's for a mesher designed for FEA |
| 03:01.19 |
brlcad |
a general
content mesher, sure |
| 03:01.26 |
brlcad |
but not one
for analytic purposes |
| 03:01.58 |
brlcad |
I'd bet your
lab is abusing some non-analytic mesher tool (simply because it was
free and did the job) |
| 03:02.41 |
brlcad |
hm, looks
like our iges exporter will not export plate-mode bots |
| 03:04.40 |
Mike111 |
what about
the option you mentioned on tesselating a bot and converting it to
a plate-mode bot? |
| 03:12.43 |
brlcad |
that's
possible but it wouldn't do anything useful for you |
| 03:12.56 |
brlcad |
before
guessing, you probably should just take a very simple test case and
see how it works |
| 03:13.03 |
brlcad |
make a
sphere |
| 03:13.11 |
brlcad |
export that
sphere as dxf, iges, and stl |
| 03:13.25 |
brlcad |
see how each
import into that mesh tool |
| 03:13.49 |
brlcad |
then try
importing something, export it as dxf, iges, and stl .. see how it
imports into the mesher |
| 03:14.23 |
brlcad |
that will
answer way more questions than speculating on what is possible, our
terminology, their terminology, your understanding, etc
;) |
| 03:23.43 |
Mike111 |
OK, I'll give
it a try and take it from there. |
| 03:24.39 |
brlcad |
cool, please
update on how it goes! |
| 03:25.41 |
CIA-28 |
BRL-CAD:
03brlcad * r34665 10/brlcad/trunk/ (BUGS TODO): the shaders.sh
regression test case is failing due to a change in view
initialization. needs to be fixed. |
| 03:26.01 |
Mike111 |
The Lighting
tutorial is clear. Howeverm, now the link is missing from the
brlcad wiki page. |
| 03:28.07 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:77.120.80.206]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 03:28.21 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r1461
10/wiki/Main_Page: Reverted edits by
[[Special:Contributions/77.120.80.206|77.120.80.206]] ([[User
talk:77.120.80.206|Talk]]); changed back to last version by
[[User:98.218.53.50|98.218.53.50]] |
| 03:28.27 |
brlcad |
fixed |
| 03:28.49 |
brlcad |
it's a wiki
.. you can fix it if it happens again ;) |
| 03:28.59 |
brlcad |
just select
History, see what happened |
| 03:29.14 |
Mike111 |
sure, thanks
for the info. |
| 03:29.37 |
brlcad |
if you
compare a revision to the previous, it'll show the changed lines.
you can see in that one that someone spammed a link this
morning |
| 03:30.31 |
Mike111 |
nasty |
| 03:31.11 |
brlcad |
happens |
| 03:31.17 |
Mike111 |
how do I
place light sources in specific locations, such as in the
tutorial? |
| 03:31.19 |
brlcad |
it's trivial
to revert |
| 03:31.31 |
brlcad |
you create
geometry, put it where you want |
| 03:31.52 |
brlcad |
e.g., there I
created little spheres |
| 03:32.18 |
brlcad |
you put them
in a region and mark the shader as a 'light' |
| 03:32.39 |
Mike111 |
so if a
primitive has only the `Light' shader enable they essentially act
only as light sources? |
| 03:33.06 |
Mike111 |
so if a
primitive has only the `Light' shader enable it essentially acts
only as a light source? |
| 03:33.07 |
brlcad |
'only' as
light sources? |
| 03:33.50 |
brlcad |
when you
apply the light shader, it's considered a light, which means it
illuminates the scene |
| 03:33.56 |
brlcad |
creating a
light disables the default lights |
| 03:34.14 |
brlcad |
rather,
rendering a scene with a light in it disables the
defaults |
| 03:34.25 |
brlcad |
not just
creating it, have to have it in your scene ;) |
| 03:34.35 |
Mike111 |
that's the
-A0 setting? |
| 03:34.46 |
brlcad |
no, that's
the ambient energy in the scene |
| 03:35.48 |
brlcad |
that page
isn't meant to explain everything about lighting -- there's too
much to cover for that short space -- it's meant to explain
lighting _after_ you already understand how to create a light
:) |
| 03:36.06 |
brlcad |
the tutorial
series covers lighting iirc |
| 03:36.22 |
Mike111 |
you mean
volume II? |
| 03:36.24 |
brlcad |
but basically
you create geometry, apply light shader, then render |
| 03:36.50 |
brlcad |
II or III --
that's the series |
| 03:41.11 |
Mike111 |
Vol. II,
p.124:"The light shader is technically complex and not discussed in
this tutorial". :( |
| 03:41.11 |
brlcad |
make sph sph
; r light.r u sph ; mater light.r light 255 0 0 0 |
| 03:41.23 |
brlcad |
that will
make a red spherical light |
| 03:41.34 |
brlcad |
so maybe it
was III |
| 03:42.46 |
brlcad |
or
not.. |
| 03:42.57 |
Mike111 |
I'll check
later in detail. |
| 03:43.01 |
brlcad |
don't see a
light ref |
| 03:44.45 |
brlcad |
http://brlcad.org/ugm2002/ShadingObjects.pdf
covers it a little bit |
| 03:45.20 |
brlcad |
but if you
run that line I gave you and then edit the object with the
combination editor (then select 'shader'), you'll see the
options |
| 03:45.53 |
Mike111 |
I was looking
at these options yesterday, after reading the lighting
tutorial |
| 03:47.59 |
Mike111 |
can you
clarify what are the `fraction' and `lumens'? settings for
intensity? |
| 03:55.32 |
*** join/#brlcad cad21
(n=841900d2@bz.bzflag.bz) |
| 03:55.55 |
*** join/#brlcad Feuerret
(n=841900d2@bz.bzflag.bz) |
| 03:56.51 |
*** join/#brlcad Feuerret
(n=841900d2@bz.bzflag.bz) |
| 03:57.11 |
brlcad |
ignore
lumens |
| 03:57.23 |
brlcad |
fraction is
the % contribution to the scene |
| 03:57.41 |
brlcad |
so if you
have just one light, it contributes 100% |
| 03:57.51 |
brlcad |
you can make
it twice as bright by making it 200% |
| 03:58.06 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 03:58.30 |
Mike111 |
so it's
basically the intensity? |
| 03:58.41 |
brlcad |
if you have
two lights with fractions 1 and 1, they'll both be contributing
100% respectively (resulting in the same 'intensity' as one light
at 200%) |
| 03:58.54 |
brlcad |
basically,
but it's balanced among all lights in your scene |
| 03:59.40 |
*** join/#brlcad Feuerret
(n=841900cf@bz.bzflag.bz) |
| 03:59.40 |
Mike111 |
ok. what are
`angle' and `target'? |
| 04:01.16 |
*** join/#brlcad Feuerret2
(n=841900cf@bz.bzflag.bz) |
| 04:01.19 |
brlcad |
angle is the
direction the light faces |
| 04:01.27 |
brlcad |
er, sorry,
target |
| 04:01.38 |
brlcad |
target is the
direction |
| 04:02.05 |
brlcad |
angle is the
angle of the light cone -- default is 180 degrees |
| 04:02.15 |
brlcad |
20 degrees
would make a sort of "spotlight" |
| 04:02.35 |
brlcad |
.1 degree
would be like a laser |
| 04:02.49 |
brlcad |
5 degrees
like a flashlight, etc |
| 04:03.00 |
Mike111 |
you mean how
much the light is `spread'? |
| 04:03.03 |
brlcad |
right |
| 04:03.37 |
brlcad |
they're
directional by default, not omnidirectional |
| 04:03.55 |
Mike111 |
would 360
give an omnidirectional source? |
| 04:04.06 |
brlcad |
you know, I
don't remember :) |
| 04:04.49 |
Mike111 |
180 means the
source only emits towards the `bottom'? |
| 04:05.39 |
Mike111 |
so that's why
you need a target? to specify a direction vector around which the
light `spreads'? |
| 04:12.15 |
Mike111 |
brlcad: sorry
but I need to go now. I'm logging the chat so if you reply I'll
view that later. Cheers |
| 04:14.21 |
brlcad |
right |
| 04:14.30 |
brlcad |
that's
direction and the spread/angle |
| 04:39.08 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 04:48.02 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 04:48.09 |
CIA-28 |
BRL-CAD:
03173.57.41.37 07http://brlcad.org
* r1462 10/wiki/User:Pacman87: /* About me */ |
| 04:49.45 |
CIA-28 |
BRL-CAD:
03173.57.41.37 07http://brlcad.org
* r1463 10/wiki/User:Pacman87: /* About me */ |
| 04:54.43 |
CIA-28 |
BRL-CAD:
03indianlarry * r34666 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): |
| 04:54.43 |
CIA-28 |
BRL-CAD:
linear approximation a lot closer, now need to get the final
newton |
| 04:54.44 |
CIA-28 |
BRL-CAD: step
working on the trims. I do see some artifacts from the tangent
sign |
| 04:54.44 |
CIA-28 |
BRL-CAD:
change in the UV horizontal(v) but as discussed that should be an
easy fix, |
| 04:54.44 |
CIA-28 |
BRL-CAD: The
hit checks (odd/even) are back on so you may see some background
specks |
| 04:54.45 |
CIA-28 |
BRL-CAD:
around edges - this seems to have cleaned up some of the odd
looking behavior |
| 04:54.47 |
CIA-28 |
BRL-CAD: in
the images BRLCAD generated (but didn't check all
models) |
| 05:02.47 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) |
| 07:27.01 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 07:59.23 |
*** join/#brlcad mafm
(n=mafm@126.Red-83-45-252.dynamicIP.rima-tde.net) |
| 09:04.50 |
brlcad |
indianlarry:
up late eh? :) |
| 09:22.39 |
Ralith |
aren't we
all? |
| 09:25.24 |
*** join/#brlcad mafm_
(n=mafm@126.Red-83-45-252.dynamicIP.rima-tde.net) |
| 09:33.51 |
Axman6 |
brlcad:
do/have you done any Ada programming? (i feel i've asked you this
before, so sorry if i have) |
| 10:07.19 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 10:21.32 |
Ralith |
sleeps |
| 11:32.25 |
d-lo |
Mernin
all! |
| 11:34.37 |
*** join/#brlcad d_rossberg
(n=rossberg@66.111.56.50) |
| 11:50.30 |
starseeker |
indianlarry:
awesome! |
| 11:51.48 |
starseeker |
thank
you! |
| 11:53.43 |
*** join/#brlcad BigAToo
(n=BigAToo@nmd.sbx10200.goshein.wayport.net) |
| 12:18.49 |
starseeker |
scowls at jove - where did "jove.h:431: error: conflicting
types 'getline'" come from? |
| 12:39.51 |
starseeker |
hmm - some
sort of getline definition in stdio.h... ugh |
| 13:01.01 |
starseeker |
disables jove building and moves on with
life |
| 13:02.32 |
``Erik |
svn rm ftw
O.o |
| 13:04.09 |
starseeker |
blinks at the number of format argument complaints he's
getting |
| 13:04.30 |
starseeker |
serves me
right for updating my system - now I'll bet my gcc/automake combo
is too new to work again... |
| 13:06.33 |
``Erik |
eh? |
| 13:07.06 |
starseeker |
runs gentoo unstable, so I tend to be uncomfortable close to
the "cutting edge" of gcc/autotools versions |
| 13:07.24 |
``Erik |
has a feeling that the actual problem is a more strict
automake and an inferior package management system that did not
update all the packages that installed (now old style) m4 files?
:D |
| 13:07.54 |
starseeker |
eh,
possibly |
| 13:08.07 |
starseeker |
not sure how
to spot that |
| 13:08.12 |
``Erik |
lots of
"underquoted" issues? |
| 13:08.35 |
starseeker |
no, more
complaints about "expects unsigned int, but given long int" or some
such |
| 13:08.45 |
``Erik |
ohhh, type
issues, n/m :) |
| 13:09.23 |
``Erik |
what are your
-W flags? |
| 13:09.32 |
starseeker |
should be
default |
| 13:09.49 |
``Erik |
doesn't remember default O:-) |
| 13:10.22 |
starseeker |
<PROTECTED> |
| 13:11.05 |
starseeker |
yeah, not
sure |
| 13:11.18 |
starseeker |
isn't too concerned right now - more important that install
works |
| 13:11.34 |
starseeker |
(me neeeeeds
moooore cooores......) |
| 13:11.46 |
starseeker |
40 minute
builds suck |
| 13:12.17 |
starseeker |
guesses when Qt/Ogre installs become part of the game the
time will have come to upgrade this sucker |
| 13:12.48 |
_clock_ |
Qt a part of
brlcad install? |
| 13:13.00 |
starseeker |
not
yet |
| 13:13.06 |
starseeker |
we might
never put it in |
| 13:13.30 |
starseeker |
but Ralith is
exploring combining the Qt toolkit with Ogre |
| 13:18.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-65.sbndin.btas.verizon.net) |
| 13:18.19 |
starseeker |
hmm:
http://www.newegg.com/Product/Product.aspx?Item=N82E16883107970 |
| 13:28.15 |
starseeker |
what on
earth: /usr/bin/install: will not overwrite just-created
`/usr/brlcad/share/man/man3/librle.3' with
`../../../../brlcad/src/other/libutahrle/librle.3' |
| 13:29.45 |
starseeker |
sees duplicate entry in Makefile... how did it get
there... |
| 13:33.21 |
CIA-28 |
BRL-CAD:
03starseeker * r34667
10/brlcad/trunk/src/other/libutahrle/Makefile.am: Remove duplicate
entry for librle.3 |
| 13:36.03 |
CIA-28 |
BRL-CAD:
03starseeker * r34668
10/brlcad/trunk/src/adrt/libtienet/Makefile.am: Remove duplicate
tienet_util.h entry |
| 13:39.24 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 13:39.51 |
``Erik |
ponders the breakage in opennurbs |
| 13:40.08 |
``Erik |
src/other/openNURBS/opennurbs_system.h:150:
error: expected identifier or '(' before '/' token |
| 13:40.12 |
``Erik |
line #'s must
be off |
| 13:40.55 |
CIA-28 |
BRL-CAD:
03starseeker * r34669
10/brlcad/trunk/src/tclscripts/archer/images/Themes/Windows/Makefile.am:
Remove duplicate entry for pane_collapse.png |
| 13:41.20 |
starseeker |
blinks |
| 13:42.44 |
starseeker |
``Erik: where
are you seeing that? |
| 13:42.52 |
``Erik |
amd64
fbsd7 |
| 13:42.53 |
starseeker |
what OS I
mean |
| 13:42.55 |
starseeker |
ah |
| 13:43.24 |
``Erik |
knew what ya meant :D |
| 13:44.24 |
starseeker |
gets the latest nurbs raytrace of shape1.s -
swwwweeeeet |
| 13:45.08 |
starseeker |
ok, so that
was it - my toolset is suddenly picky about duplicate file listings
in Makefile.am |
| 13:45.13 |
starseeker |
<snort> |
| 13:45.20 |
starseeker |
oh, well -
legit errors I suppose |
| 13:45.32 |
starseeker |
alrightie,
I'm on the road |
| 13:46.44 |
d_rossberg |
``Erik: //
=> /* */ |
| 13:46.54 |
``Erik |
yes,
compiling with that |
| 13:47.08 |
``Erik |
wanted the
compile to finish before I commited :) |
| 13:47.57 |
``Erik |
there're more
of those, I'll wait until I get them all and commit 'em all at
once |
| 13:48.10 |
d_rossberg |
isn't //
already legal in C code? |
| 13:49.34 |
``Erik |
it's
c99 |
| 13:50.26 |
``Erik |
I'm compiling
with "-W -Wall -ansi -pedantic" because I'm nuts |
| 13:54.03 |
``Erik |
meh, screw
it, we'll just say c99 is required for opennurbs :D |
| 13:54.49 |
d_rossberg |
opennurbs is
C++ :P |
| 13:54.59 |
``Erik |
it's mostly
c++, there're 2 C files in it |
| 13:55.27 |
``Erik |
which is how
I'm tripping that issue :) |
| 14:33.24 |
CIA-28 |
BRL-CAD:
03indianlarry * r34670
10/brlcad/trunk/include/opennurbs_ext.h: |
| 14:33.24 |
CIA-28 |
BRL-CAD:
added initial curve approximation to trims, still some fuzz,
haven't optimized |
| 14:33.24 |
CIA-28 |
BRL-CAD:
merely replaced linear check for now i'm sure its
slower |
| 15:29.00 |
CIA-28 |
BRL-CAD:
03starseeker * r34671 10/brlcad/trunk/include/opennurbs_ext.h: pass
in the full uv point in the curve iteration function (not sure I'll
need it but if I do this will minimize the effort to swap out
different curve solver attempts) - no functionality
change |
| 15:37.24 |
indianlarry |
starseeker:
probably should have passed it in for good measure, could also use
to stop iteration is v falls out of closeness (is that a
word?) |
| 15:37.49 |
starseeker |
not sure
:-) |
| 15:38.15 |
starseeker |
was just
going to take another stab at writing a newton iterator, looks like
it needs both but I'm not totally sure |
| 15:38.55 |
starseeker |
probably need
the test of within the triangle defined by the normals and the line
segment between the two end points too |
| 15:38.59 |
starseeker |
(ick) |
| 15:39.16 |
indianlarry |
sounds good
i'm looking at getting rid of the horz v problem and checking a
couple saw tooths |
| 15:39.40 |
starseeker |
cooool |
| 15:39.49 |
starseeker |
(lunch, back
in a bit) |
| 15:40.08 |
indianlarry |
okay |
| 15:40.33 |
indianlarry |
(cigar
break) |
| 16:07.14 |
*** join/#brlcad madant
(n=d@117.196.129.146) |
| 16:08.06 |
madant |
is finally all set (sort of) .. sleepless nights here i
come |
| 16:40.09 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 17:04.24 |
starseeker |
is back |
| 17:07.32 |
``Erik |
sticks his finger up his nose |
| 18:10.14 |
``Erik |
heh http://www.newtechusa.com/PPI/pressroom.asp#higher |
| 18:12.00 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.38) |
| 18:17.57 |
CIA-28 |
BRL-CAD:
03starseeker * r34672 10/brlcad/trunk/include/opennurbs_ext.h: Add
an attempt at a Newton iteration solver. Still waaay too many hard
coded values chosen arbitrarily - doesn't seem to be better than
Keith's initial curve approx. |
| 18:32.54 |
starseeker |
indianlarry:
is this the kind of effect you're seeing? http://bzflag.bz/~starseeker/edge_oddness.png |
| 18:34.05 |
starseeker |
I'm nirting
through those cracks, and I'm not seeing any failed to converge
errors... not sure what to make of it |
| 18:38.07 |
starseeker |
fwiw, a
specific example is Origin (x y z) = (28.64 19.53 23.17), Direction
(x y z) = (-0.7424 -0.5198 -0.4226) |
| 18:51.31 |
starseeker |
that ALMOST
looks like a sawtooth behavior - it doesn't seem to be a newton
convergence issue, although I could be wrong. |
| 19:06.16 |
indianlarry |
starseeker: i
found the saw tooths, looks to be my error tolerences on the bulk
BBoxes |
| 19:06.52 |
starseeker |
nice
work! |
| 19:07.58 |
indianlarry |
starseeker:
won't need to set error so high if i get the BBoxes breaking on the
Horz/Vert peaks |
| 19:08.07 |
starseeker |
nods |
| 19:08.28 |
indianlarry |
would make
curve lie on inside of BBox |
| 19:10.44 |
starseeker |
how did you
want to do that? Newton converge to find the max within the
bounding box? |
| 19:10.52 |
indianlarry |
for
sure |
| 19:12.22 |
starseeker |
ponders how to approach that... |
| 19:16.34 |
indianlarry |
not sure but
at least 2d problem and brute forcing an iterative approach is
doable especially in prep stage |
| 19:16.56 |
indianlarry |
starseeker:
sorry having connection problems |
| 19:17.32 |
indianlarry |
starseeker:
wow, now that's a saw tooth you posted |
| 19:17.50 |
indianlarry |
starseeker:
bur yes that's what i was seeing as well |
| 19:17.51 |
starseeker |
that's a
zoomed in sawtooth ;-) |
| 19:17.59 |
starseeker |
having connection problems too |
| 19:18.30 |
indianlarry |
starseeker:
in most places things seem pretty tight |
| 19:18.43 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-65.sbndin.btas.verizon.net) |
| 19:18.44 |
starseeker |
indianlarry:
what about checking the tangent vectors at the start and end
points? even if it is a special case, it might help |
| 19:19.18 |
indianlarry |
starseeker:
definitely, will start there |
| 19:19.45 |
indianlarry |
starseeker:
did brlcad try and raytrace that phone again? |
| 19:20.03 |
starseeker |
don't think
so - let me see if I can take a stab at it |
| 19:20.21 |
``Erik |
shouldn't you
be enjoying scotch and a cigar instead of wanking around on irc?
O.o :D *duck* |
| 19:21.10 |
indianlarry |
``Erik:
something sensual about working in the raw and nobody knowing...
oops |
| 19:21.31 |
``Erik |
wait, no one
knowing? |
| 19:21.35 |
``Erik |
looks for his pants O:-) |
| 19:22.55 |
indianlarry |
puts scitch back in cabinet |
| 19:23.11 |
indianlarry |
then puts scotch back in cabinet |
| 19:23.27 |
starseeker |
that how you
can tell you've had enough? ;-) |
| 19:23.52 |
indianlarry |
almost
;^{o>>>>>>>>>>>>> |
| 19:25.56 |
``Erik |
no, 'i' and
'o' are right next to eachother, that's the beginning of the
buzz |
| 19:26.11 |
``Erik |
when he
spells it "astjopch", ... |
| 19:26.40 |
starseeker |
actually doesn't see which one is the
phone... |
| 19:27.02 |
indianlarry |
starseeker:
didn'y see it either |
| 19:27.21 |
indianlarry |
it is a
laptop keyboard |
| 19:28.05 |
brlcad |
indianlarry:
haha |
| 19:29.09 |
CIA-28 |
BRL-CAD:
03bob1961 * r34673 10/brlcad/trunk/src/ (34 files in 3 dirs): Added
the p/parameter command to Archer. |
| 19:29.28 |
indianlarry |
brlcad:
where's the phone/pda dot.g |
| 19:29.42 |
brlcad |
looks |
| 19:30.46 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34674 10/brlcad/trunk/src/adrt/libtie/ (tie.c
tie_kdtree.c): Irrelevant type signing fixes. Remove unused
parameters. |
| 19:35.56 |
brlcad |
indianlarry:
hm, hm.. some good and bad news :) |
| 19:36.09 |
brlcad |
somethings
are rendering better, some not at all any more :) |
| 19:36.18 |
brlcad |
it's the
HTC-Magician |
| 19:36.44 |
brlcad |
...which
looks like wasn't uploaded! |
| 19:37.02 |
starseeker |
thought so |
| 19:37.34 |
brlcad |
going up
now |
| 19:37.47 |
starseeker |
brlcad: is
that piston.g file THE piston? |
| 19:38.03 |
brlcad |
nope |
| 19:38.06 |
starseeker |
didn't think
so |
| 19:38.32 |
brlcad |
that was
before I found it, hunted for and checked a bunch of other
pistons |
| 19:38.40 |
starseeker |
ah |
| 19:39.05 |
brlcad |
huh |
| 19:39.11 |
brlcad |
actually the
phone did upload |
| 19:39.19 |
brlcad |
just not
showing in the listing for some reason |
| 19:39.24 |
brlcad |
ah,
permissions |
| 19:39.34 |
indianlarry |
brlcad:
hopefully it's an odd hit issue, noticed some elements (Pumkin
text) were just single surfaces not solid |
| 19:40.41 |
brlcad |
indianlarry:
it lists now |
| 19:40.55 |
indianlarry |
brlcad:
thanks |
| 19:41.14 |
brlcad |
indianlarry:
yeah, the single surfaces weren't solid so that makes sense though
rendering them as a thin surface was useful/interesting |
| 19:41.27 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34675 10/brlcad/trunk/src/adrt/
(libtienet/load.c libtienet/load.h slave/slave.c): revert back to
magic void* for now |
| 19:41.27 |
brlcad |
implicit
plate-mode |
| 19:41.54 |
starseeker |
brlcad: some
of the geometry in this phone is failing isValid |
| 19:42.08 |
indianlarry |
brlcad: just
uncomment "//#define KODDHIT" in brep.cpp |
| 19:42.52 |
brlcad |
starseeker: I
know, that's some of them |
| 19:43.15 |
brlcad |
indianlarry:
k |
| 19:44.38 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34676 10/brlcad/trunk/src/libpkg/tpkg.c: I don't
think ports > 65535 make much sense... |
| 19:50.00 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34677 10/brlcad/trunk/src/adrt/ (16 files in 7
dirs): eliminate trailing whitespace |
| 19:50.45 |
starseeker |
brlcad: I
take it this sucker was valid geometry in Rhino? |
| 19:51.02 |
brlcad |
starseeker:
don't know, found model |
| 19:51.14 |
starseeker |
ah |
| 19:51.32 |
brlcad |
I'd be
surprised, though -- it wasn't a hobby job |
| 19:55.14 |
brlcad |
it's
interesting to note that the iges one renders semi better with the
old nurbs code |
| 19:55.21 |
brlcad |
sans
trims |
| 20:02.11 |
starseeker |
brlcad: I'm
wondering about our 3dm importer - this phone geometry doesn't look
so hot |
| 20:02.25 |
brlcad |
no doubt it
needs work |
| 20:02.36 |
brlcad |
half the
examples I found failed outright or aborted mid-stream |
| 20:02.44 |
brlcad |
that's why I
left both |
| 20:02.57 |
starseeker |
loaded it into Rhino and exported again - still bad
geometry |
| 20:03.06 |
brlcad |
displays in
rhino? |
| 20:03.12 |
starseeker |
yes |
| 20:03.52 |
brlcad |
so something
to trace, could be that IsValid() is wrong or being used as a check
incorrectly/unnecessarily |
| 20:04.13 |
brlcad |
didn't
investigate exactly the validity it's complaining about |
| 20:04.45 |
starseeker |
we're sure
this phone is supposed to be solid and not just a surface
model? |
| 20:05.14 |
brlcad |
eh |
| 20:05.18 |
brlcad |
that was
never claimed |
| 20:08.10 |
brlcad |
don't tell me
you're just thinking of that? :) i'll say it again, those are a
set of fairly *random* 3dm files. they are a random sampling of
real models found around the net, obviously provoking a random set
of issues across the board (import, validation, rendering,
etc) |
| 20:08.45 |
starseeker |
well, we've
been focused on correct trimming |
| 20:08.55 |
starseeker |
one thing at
a time |
| 20:09.04 |
brlcad |
of
course |
| 20:09.48 |
brlcad |
what did you
expect though? |
| 20:10.08 |
starseeker |
thought you
would reject anything not claiming to be solid ;-) |
| 20:11.34 |
brlcad |
well the
original intent was hunting for the piston model, as I remembered
it was readily available somewhere |
| 20:11.51 |
brlcad |
so it was
more a matter of find 3dm, see what happens |
| 20:11.54 |
starseeker |
ah |
| 20:11.58 |
starseeker |
got
it |
| 20:12.00 |
brlcad |
still a good
measure of where things are at overall |
| 20:12.25 |
brlcad |
as those
should all be well-*behaved* regardless of their
structure |
| 20:13.04 |
brlcad |
not saying
that's the priority now, or the focus, or something to worry about
right now even -- that was never the intention |
| 20:14.47 |
starseeker |
OK
:-) |
| 20:15.12 |
starseeker |
we (or I
anyway) thought they were examples of wacked trimming
behavior |
| 20:15.25 |
brlcad |
they very
well could be |
| 20:15.32 |
brlcad |
some of them
were clearly trimming poorly |
| 20:17.41 |
starseeker |
hmm:
http://www.mh-aerotools.de/airfoils/cox_cad_models.htm |
| 20:19.06 |
brlcad |
those are
pretty cool |
| 20:20.51 |
brlcad |
anyways, just
gotta multitask the info from earlier, not to disregard/ignore but
not to focus on to the point of ignoring the big picture -- just
some more test cases that should be investigated (for variety of
purposes) |
| 20:21.44 |
brlcad |
they're found
models -- some of the best ways towards making the tools robust and
well-behaved, e.g. has me looking through the 3dm importer to see
why (most)/many failed |
| 20:22.07 |
starseeker |
nods |
| 20:22.23 |
brlcad |
as I did
pretty much exactly what a user would have |
| 20:22.38 |
brlcad |
stashes those new 3dm's in and tests |
| 20:23.10 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34678 10/brlcad/trunk/src/adrt/Makefile.am:
update dependancy information. |
| 20:24.20 |
starseeker |
that PeeWee
piston is a monster |
| 20:24.25 |
starseeker |
300
regions |
| 20:24.40 |
starseeker |
adjusts drawing routine to have a hope of eing it
up |
| 20:26.02 |
brlcad |
awesome,
black widow isn't 'too' shabby |
| 20:26.35 |
brlcad |
massive
convergence failure reporting |
| 20:26.52 |
starseeker |
er, yeah -
sorry about that |
| 20:26.57 |
starseeker |
debugging
output |
| 20:27.14 |
brlcad |
takes a pic |
| 20:28.02 |
starseeker |
it very
probably shouldn't be attempting to converge in most of those cases
- the limit that restricts the newton converence to a domain where
it "should" work is stupid simple right now |
| 20:29.17 |
brlcad |
http://brlcad.org/tmp/nurbs5.png |
| 20:29.47 |
brlcad |
that top cap
is pretty interesting |
| 20:29.48 |
starseeker |
hah - not too
bad |
| 20:30.04 |
brlcad |
probably just
an even/odd count problem |
| 20:31.52 |
brlcad |
i'm really
happy to see the db encoding isn't a problem |
| 20:32.23 |
starseeker |
how long did
it take it to draw that wireframe? |
| 20:32.53 |
brlcad |
breaking up
the 3dm into per-object objects is minimal overhead, maybe
10% |
| 20:32.56 |
starseeker |
's wireframe draw was a lot slower than the raytrace - some
work to do there |
| 20:32.59 |
brlcad |
wireframe was
instant |
| 20:33.07 |
starseeker |
huh -
odd |
| 20:33.16 |
starseeker |
can you do me
a favor and try the PeeWee model? |
| 20:33.25 |
brlcad |
gettin'
there |
| 20:33.27 |
brlcad |
going down
the list |
| 20:33.47 |
starseeker |
ah
:-) |
| 20:34.39 |
brlcad |
oof, Cox
Olympic aborts rt :) |
| 20:35.03 |
brlcad |
opennurbs_curve.cpp:3172: failed assertion
`false' |
| 20:35.22 |
brlcad |
seemed to
import clean at least |
| 20:36.45 |
brlcad |
ah, same on
Cylinder 020 |
| 20:39.17 |
brlcad |
peewee
wireframe is also instant |
| 20:39.29 |
brlcad |
maybe you
have your surface plotter enabled |
| 20:41.17 |
brlcad |
peewee
crashes (not via assertion) |
| 20:41.44 |
brlcad |
ah, wait,
there is an assertion .. just delayed logging |
| 20:43.22 |
brlcad |
oh, shoot..
wrong mged -- screw those last results |
| 20:44.54 |
CIA-28 |
BRL-CAD:
03bob1961 * r34679
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Bringing up
the menu shouldn't toggle (i.e. expand/collapse) the
tree. |
| 20:51.20 |
brlcad |
http://brlcad.org/tmp/nurbs6.png
<- cox olympic |
| 20:52.00 |
brlcad |
http://brlcad.org/tmp/nurbs7.png
<- cylinder 020 (ouch) |
| 20:54.30 |
indianlarry |
looks to be
an GetNextDiscontinuity in the ON_Curve that will walk down and
give discontinuities for derivative,tangent and
curvature |
| 20:54.42 |
indianlarry |
could it be
that easy |
| 20:54.44 |
brlcad |
peewee
wireframe does suck now |
| 20:55.01 |
starseeker |
yeah, was
afraid of that |
| 20:55.17 |
starseeker |
indianlarry:
oo, that would be awesome |
| 20:55.39 |
starseeker |
just check if
it is in the bounding box - if it is, split the box at that y
value |
| 20:55.54 |
starseeker |
or domain
value rather |
| 20:56.21 |
indianlarry |
it will
actually give you the curve param point which is what i walk down
so break at each discont |
| 20:56.44 |
indianlarry |
hope it
works |
| 20:58.45 |
brlcad |
starseeker:
about 4min to e, fwiw |
| 20:58.52 |
brlcad |
render is
zippy |
| 20:59.08 |
``Erik |
heh, like,
cox .049 black widow? I have a couple of those at home
O.o |
| 20:59.20 |
``Erik |
and I think I
might have a cox peewee somewhere |
| 20:59.20 |
brlcad |
not many
warnings spewed either, but pretty wrong |
| 21:00.00 |
indianlarry |
i base the
trim error on the length of the curve in uv and the ends of
cylinder are a long linear trims |
| 21:00.07 |
brlcad |
http://brlcad.org/tmp/nurbs8.png
<- pee wee |
| 21:01.40 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34680 10/brlcad/trunk/ (22 files in 6 dirs):
Eliminate libtienet. |
| 21:03.19 |
brlcad |
http://brlcad.org/tmp/nurbs9.png
<- nice! |
| 21:04.04 |
CIA-28 |
BRL-CAD:
03starseeker * r34681 10/brlcad/trunk/include/opennurbs_ext.h: More
Newton iterator tweaking. |
| 21:08.39 |
starseeker |
brlcad: yeah,
that's my iterative wireframe routine crapping out |
| 21:09.19 |
starseeker |
almost wonder
if the way to go is to make an "edge tree" routine and use
that... |
| 21:09.43 |
brlcad |
last one, tee
dee, http://brlcad.org/tmp/nurbs10.png |
| 21:10.56 |
brlcad |
geometry with
.g's uploaded for convenience (regions fixed to not have spaces so
they e up) |
| 21:11.09 |
starseeker |
brlcad: cool,
thanks! |
| 21:11.17 |
brlcad |
starseeker:
curious, what's it iterating on? |
| 21:11.31 |
brlcad |
because it
didn't look any different than in .4 |
| 21:11.41 |
brlcad |
which was
instant |
| 21:11.43 |
starseeker |
yeah, it
wouldn't |
| 21:11.54 |
starseeker |
shape1 does
look different |
| 21:12.12 |
starseeker |
have you
tried that one in .4 vs trunk lately? |
| 21:13.23 |
starseeker |
it's making
sure the wireframe is "smooth" to within some multiple of the
tolerance |
| 21:13.31 |
starseeker |
I'm sure it's
not very intelligent about it |
| 21:14.08 |
brlcad |
I just did,
that was all the reporting about them failing to render |
| 21:15.08 |
brlcad |
the
difference in wireframes was probably there, but it certainly
wasn't drastic enough to notice (on any of them) |
| 21:15.34 |
starseeker |
yeah, shape
is kinda a worst case wireframe |
| 21:16.01 |
starseeker |
if it's a big
model compared to tolerance, the routine does a lotta work for
ziltch |
| 21:16.31 |
starseeker |
hmm, that
might be an option, base it on some fraction of the smallest
bounding box dimension... |
| 21:19.05 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34682 10/brlcad/trunk/src/adrt/ (4 files in 4
dirs): Eliminate libtienet. |
| 21:21.15 |
brlcad |
it's the same
problem the other primitives have |
| 21:22.00 |
brlcad |
they need to
be dynamic to model size and view size, levels of
detail |
| 21:22.46 |
brlcad |
which for the
most part can all be done with view size, but there are some
absolute model/computation limits that it should
enforce |
| 21:33.50 |
brlcad |
``Erik: looks
like that does a hell of a lot more that just eliminate
libtienet... |
| 21:35.15 |
``Erik |
there might
be a little more, but big chunks were moved out of libtienet into
their application dir |
| 21:35.19 |
brlcad |
and could ya
make the commit any bigger? jeez. |
| 21:35.24 |
``Erik |
hehehe |
| 21:35.26 |
``Erik |
svn mv,
dude |
| 21:35.29 |
brlcad |
bob's rubbing
off on you |
| 21:35.41 |
brlcad |
and yeah,
that sounds so wrong :) |
| 21:37.03 |
``Erik |
(and I'm just
getting warmed up on the horrors, mebbe I'll get to commit and run
like hell for my car) |
| 21:37.04 |
starseeker |
brlcad:
correct me if I'm wrong, but the primitive plotting routines don't
currently know anything about the view, do they? |
| 21:37.28 |
brlcad |
starseeker:
none at all, that's why it's not been simple to fix |
| 21:37.34 |
starseeker |
ah |
| 21:37.39 |
starseeker |
ok, very
good |
| 21:37.39 |
brlcad |
requires a
functab change which affects all prims |
| 21:37.55 |
brlcad |
I was going
to get to it *after* all of the functab refactoring |
| 21:38.14 |
brlcad |
still have a
bit of work under way to finish up there |
| 21:38.21 |
starseeker |
yeah, that's
what I thought - fairly intrusive change |
| 21:38.45 |
brlcad |
gsi had a
quick hack that we could adopt, but it really was a big ugly for my
taste |
| 21:39.03 |
starseeker |
nods |
| 21:39.08 |
brlcad |
they
implemented a hi/lo command that would toggle wireframe
detail |
| 21:39.19 |
starseeker |
That's worth
doing right, imho |
| 21:39.44 |
brlcad |
primitves
were modified to do what they do now and an even higher-res smooth
version |
| 21:39.51 |
starseeker |
might also
help with the "use arcs as well as lines" approach? |
| 21:40.10 |
brlcad |
the
primitives shouldn't be tessellating themselves |
| 21:40.17 |
starseeker |
nods |
| 21:40.24 |
``Erik |
hm, 3 arcs
instead of 48 lines, that'd be nifty |
| 21:40.40 |
brlcad |
instead of
returning render segments, they should return their
edges/contours/surfaces -- e.g. the brep form |
| 21:41.03 |
brlcad |
from the brep
form, tessellate as needed based on view size |
| 21:41.52 |
brlcad |
they could
still self plot, but even then they could return as ``Erik
mentioned -- arcs/curves lines points, etc |
| 21:42.07 |
brlcad |
basically a
crude brep form |
| 21:44.08 |
``Erik |
runs for his car |
| 21:44.26 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r34683 10/brlcad/trunk/ (13 files in 11 dirs):
flatten ADRT build. |
| 21:46.16 |
``Erik |
yeah, I spoze
that's 'nuff breakage for one afternoon :D |
| 21:53.47 |
CIA-28 |
BRL-CAD:
03starseeker * r34684
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Hack around a
performance issue with the adaptive sampling drawing for NURBS -
this isn't a final solution but should avoid the killer performance
zones. |
| 21:55.34 |
starseeker |
brlcad: does
that help any? |
| 21:58.18 |
brlcad |
yes |
| 21:58.30 |
brlcad |
about .5s on
peewee |
| 22:00.08 |
starseeker |
that
preserves the shape1 drawing and attempts to "recognize" when it
needs to be less fine |
| 22:00.25 |
starseeker |
will still
have bad areas of course, but might be a reasonable compromise for
now |
| 22:01.10 |
brlcad |
cool |
| 22:03.48 |
starseeker |
the trick is
essentially to recognize that if we have to subdivide beyond some
number N times, we have an edge describing a large length compared
to the tolerance and the better course is to hope that big steps
are "smooth" |
| 22:04.47 |
starseeker |
if
indianlarry's singularity trick could be applied to edges we might
look for derivative changes as another tool, but it can wait until
a "proper" solution is available |
| 22:04.58 |
starseeker |
(especially
given it's a universal primitive problem at the moment) |
| 22:09.32 |
starseeker |
indianlarry:
so far what I'm seeing suggests that the linear approximation is a
Really Good approximation for trimming - with that zoom in showing
sawtooth it may be that at default resolutions shape1 isn't
triggering a need for the exact curve solutions |
| 22:14.30 |
brlcad |
nod |
| 22:41.47 |
``Erik |
looks for his engines |
| 22:53.11 |
``Erik |
hm, can't
find 'em :/ must still be at my parents place |
| 23:25.28 |
*** join/#brlcad madant_
(n=d@117.196.129.227) |
| 00:01.41 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 02:18.51 |
starseeker |
indianlarry:
Idea on handling of the raytracing of NURBS. Expanding the boxes
is killing our performance by forcing more interative solutions of
intersected bounding boxes (which are not needed in most cases but
are in a few). What if, for each bounding box leaf we propose to
search for intersections in, we see if the xy coordinates of any of
the previously found intersection points are within the bounding uv
square of the leaf BB about to be consider |
| 02:21.43 |
starseeker |
taking that
one step further, when we build the surface tree we could actually
store two trees in parallel, one with the minimal bounding boxes
that give good raytrace performance, and one with the BB growth
factor turned on. Then we can raytrace using the default bounding
boxes, and for shots that return either an odd hit count or zero
intersection boxes we repeat the hierarchy test with that same ray,
only this time instructing it to use the grown bb |
| 02:23.29 |
starseeker |
compare the
list of leaves obtained from the grown hierarcy test to the
original list - any new boxes, test them for hits. If hits are
found that aren't already in the hit list, add them and resort the
list |
| 02:24.12 |
starseeker |
so in
essence, each BBnode in the surface tree would store two sets of
bounding box dimensions rather than one - otherwise, it's the same
tree build |
| 02:26.31 |
starseeker |
we don't even
have to walk the surface list twice |
| 02:27.32 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 04:39.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 05:49.46 |
Ralith |
hm, I sent in
my tax forms a couple days ago, still hasn't been confirmed as
received |
| 05:49.53 |
Ralith |
:/ |
| 05:50.56 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 05:57.39 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 09:01.51 |
*** join/#brlcad _clock_
(n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 12:02.39 |
*** join/#brlcad docelic_
(n=docelic@78.134.203.126) |
| 12:56.51 |
*** join/#brlcad madant_
(n=d@117.196.131.212) |
| 14:54.30 |
*** join/#brlcad samrose
(n=samrose@h134-215-226-37.lnngmi.dedicated.static.tds.net) |
| 15:38.10 |
starseeker |
indianlarry:
Question: If we allow uv hit points outside uv boxes, but when
performing the trimming test actually find (via a "2d"
IntersectHierarchy test, I suppose) the uv box that contains the
"out of box" hit point and use that to do the trimming test, would
we actually get rid of the jagged edges on the trims while still
allowing out of box hits? |
| 17:16.23 |
*** join/#brlcad ``Erik_
(n=erik@ftp.brlcad.org) |
| 17:18.50 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 18:54.57 |
CIA-28 |
BRL-CAD:
03bob1961 * r34722
10/brlcad/trunk/misc/win32-msvc8/opennurbs/opennurbs.vcproj: mods
to get things building again on windows |
| 18:55.38 |
*** join/#brlcad madant
(n=d@117.196.129.38) |
| 19:57.15 |
*** join/#brlcad ``Erik_
(n=erik@ftp.brlcad.org) |
| 20:32.14 |
*** join/#brlcad samrose
(n=samrose@h134-215-226-37.lnngmi.dedicated.static.tds.net) |
| 20:47.13 |
indianlarry |
starseeker:
You still workin |
| 20:47.53 |
indianlarry |
starseeker:
think i found an easy solution to our box growth issue |
| 20:49.33 |
indianlarry |
starseeker:
erik also mentioned his ideas about keeping neighbor links for his
work that may play into the out of box hits we get |
| 20:51.44 |
starseeker |
still
here |
| 20:52.00 |
starseeker |
sorry,
chatting with Bob about Archer stuff |
| 20:52.05 |
starseeker |
what's the
easy solution? |
| 20:52.13 |
``Erik |
foiled their productivity mwahahhaa |
| 20:53.02 |
indianlarry |
starseeker:
think i can grow only those boxes that need it just need to check
if the corner normal pass the x,y,z normals |
| 20:53.41 |
indianlarry |
starseeker:
since we bound be x,y,z min/max those are the only ones that would
stick out |
| 20:53.54 |
indianlarry |
starseeker:
that's why we were seeing patterns |
| 20:54.08 |
indianlarry |
starseeker:
should actually be easy |
| 20:54.26 |
``Erik |
famous last
words? :D |
| 20:54.28 |
starseeker |
so you're
saying check the normals at the corners in 3 space and see if they
indicate "bad" behavior somehow? |
| 20:54.51 |
indianlarry |
starseeker:
see id they change quadrants |
| 20:55.02 |
indianlarry |
starseeker:
octants |
| 20:55.12 |
starseeker |
oh,
hmm |
| 20:55.31 |
starseeker |
that might
work, actually |
| 20:55.46 |
indianlarry |
starseeker: i
think we can use the knots to ensure no more then two hits as
well |
| 20:55.54 |
starseeker |
cool |
| 20:56.19 |
starseeker |
that might
make my ideas overkill then... |
| 20:57.11 |
indianlarry |
starseeker:
if we use knots during initial subdivision may make flatness
resolve quicker |
| 20:57.46 |
starseeker |
ponders... yes, that might be true |
| 20:57.51 |
indianlarry |
starseeker:
then again i've had a few too many already |
| 20:57.59 |
starseeker |
are you
suggesting breaking into quadrants ON the knots? |
| 20:58.43 |
indianlarry |
starseeker:
check flatness if not flat find median knot closest to center u,v
and split there |
| 20:59.09 |
indianlarry |
starseeker:
looks like openNURBS has a closest knot index function |
| 20:59.21 |
starseeker |
hmm. sounds
promising |
| 21:00.18 |
indianlarry |
starseeker:
guit there today? |
| 21:00.31 |
starseeker |
quiet |
| 21:00.37 |
indianlarry |
starseeker:
yes aorry |
| 21:00.40 |
starseeker |
'cept Bob
says "get a life!" |
| 21:00.45 |
starseeker |
indianlarry:
for what? |
| 21:01.07 |
starseeker |
indianlarry:
you've been doing and continue to do awesome work! |
| 21:01.17 |
indianlarry |
starseeker:
for the typing |
| 21:01.26 |
starseeker |
pfft. I was
trained on slashdot |
| 21:04.06 |
indianlarry |
starseeker:
i'll try and hit it later but busy weekend (graduation parties to
attend) |
| 21:04.33 |
starseeker |
don't worry
about it - that's way more important! |
| 21:05.01 |
starseeker |
scowls at the single odd hit report still coming from
shape1.s at high res... |
| 21:06.02 |
indianlarry |
starseeker:
I'll try and put that fuzz check in there, also need to see how
they handle intersect closeness between surfaces problem could be
there |
| 21:06.25 |
starseeker |
nods - yeah, kinda looks like that |
| 21:06.29 |
starseeker |
who's
graduating? |
| 21:06.56 |
indianlarry |
starseeker:
mothers cousins kin way down the line |
| 21:07.14 |
starseeker |
heh - well,
it's a good drink excuse :-) |
| 21:07.31 |
indianlarry |
starseeker:
that's what i thought |
| 21:07.44 |
indianlarry |
have a good
weekend all |
| 21:08.05 |
indianlarry |
is brlcad in
the channel |
| 21:08.16 |
starseeker |
you
too |
| 21:08.20 |
starseeker |
haven't seen
him today |
| 21:08.39 |
indianlarry |
catch up with
him later |
| 21:10.20 |
indianlarry |
need to make
sue GSoC joeDee has commit access to SVN |
| 21:11.24 |
starseeker |
nods :-) |
| 21:11.28 |
starseeker |
yeah, that
helps |
| 21:11.53 |
*** join/#brlcad _sushi_
(n=_sushi_@80-218-234-36.dclient.hispeed.ch) |
| 21:12.14 |
starseeker |
just in case
this helps, xyz 4.315565 -2.942501 15.995774 dir -0.742404
-0.519837 -0.422618 with backout on is the shape1 test
case |
| 21:30.54 |
brlcad |
indianlarry:
I can set it but his commits will have to be watched carefully --
his patch indicated he needs more instruction on patches, commits,
svn, our HACKING guidelines, style/ws, etc |
| 21:31.47 |
brlcad |
might want to
have him simply start submitting patches (to the tracker for his
work) and iterate with him on the patches until they commit
unmodified |
| 21:32.21 |
brlcad |
shouldn't
take more than a day or two to get anyone up to speed |
| 21:33.09 |
indianlarry |
brlcad: i'll
touch base with him |
| 21:34.02 |
brlcad |
otherwise he
does need to get kicking really soon now or there's no way he'll
pass midterms |
| 21:35.32 |
indianlarry |
brlcad: looks
like he's beeen writing some test code for some simple brep
primitive so i think he's starting to get into it |
| 21:36.31 |
indianlarry |
brlcad: he
emailed me some code to look at and he was re-writing dot,cross
product macros and i pointed him at vmath.h |
| 21:37.15 |
indianlarry |
brlcad: i
know it can be a little hard finding things |
| 21:38.27 |
indianlarry |
brlcad: i
think he's also finding out that some of the opennurbs functions he
needs are limited and sometimes replaced with stubs |
| 21:38.34 |
brlcad |
indianlarry:
yeah, it's completely understandable -- just part of the process
for "commit access" |
| 21:38.46 |
indianlarry |
brlcad:
thanks |
| 21:41.54 |
brlcad |
he should
work on showing he understands the dev guidelines before getting
deep into the code regardless, which covers making patches,
frequent commits, not breaking things, what his responsibilities
are when he does break something, etc |
| 21:42.08 |
brlcad |
particularly
for the gsoc kids, it's part of their http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 21:43.20 |
brlcad |
indianlarry:
did he send you patch files or whole files or snippets? |
| 21:45.11 |
indianlarry |
brlcad: just
a single file snippet just to look at overall style |
| 21:45.13 |
brlcad |
either way,
that's the "tendancy to default to private conversations" I
mentioned months back -- you shouldn't allow that or at least
should respond to their message to the dev list (with a note to
keep dev chatter public) |
| 21:45.43 |
brlcad |
many students
do that, it's natural but really should be nipped in the bud
early |
| 21:45.55 |
indianlarry |
brlcad: i
mentioned that to him i think he need just a little
push |
| 21:46.16 |
indianlarry |
brlcad: i
think he tried to commit some stuff and couldn't |
| 21:46.50 |
indianlarry |
brlcad: i'll
try and work it out with him |
| 21:47.08 |
brlcad |
it's multiple
issues -- not being able to commit isn't an excuse |
| 21:47.10 |
brlcad |
he has to
communicate |
| 21:47.40 |
brlcad |
he's
certainly not said anything here yet has been joining, so it's even
worse |
| 21:48.36 |
indianlarry |
brlcad: he
was the one that had late finals so hopefully he'll start to get
involved |
| 21:48.42 |
brlcad |
nods |
| 21:49.02 |
brlcad |
~gsoctimeline |
| 21:49.03 |
ibot |
gsoctimeline
is, like,
http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline |
| 21:50.31 |
brlcad |
yeah, three
weeks to his midterm evaluation, two or three of the students are
going to have to seriously kick it in or they'll have to be
dropped |
| 21:50.58 |
brlcad |
will have to send a note this weekend, didn't realize that
much time had passed already |
| 21:50.58 |
indianlarry |
brlcad: i'll
mention it to him |
| 21:51.12 |
indianlarry |
tell me about
it |
| 21:51.39 |
*** join/#brlcad mafm
(n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) |
| 21:51.49 |
brlcad |
they're on a
tight schedule and it's supposed to be a full-time job -- that's
three weeks of no-show |
| 21:52.21 |
indianlarry |
brlcad: acts
like he has a gov't job ;^) |
| 21:52.29 |
brlcad |
heh |
| 21:53.23 |
indianlarry |
i'm out for a
while i'll try to push things along have a good weekend |
| 21:53.29 |
brlcad |
cya! |
| 21:54.07 |
mafm |
hi |
| 21:54.10 |
brlcad |
Ralith: nice
to see you getting started, lemme know if you have any
problems |
| 21:54.13 |
brlcad |
mafm:
howdy! |
| 21:54.19 |
brlcad |
pacman87:
how's it going?.... :) |
| 21:54.57 |
Ralith |
brlcad: I
shall. |
| 21:55.29 |
CIA-28 |
BRL-CAD:
03starseeker * r34723
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: When an odd
nurbs hit point shows up, print out the nirt commands that will
fire just that ray (make debugging 'em simpler) |
| 21:56.36 |
brlcad |
Ralith:
remember to keep a daily note for any days you work, a single brief
sentance suffices -- like a commit message -- to say what you got
done |
| 21:57.01 |
Ralith |
oh,
wups |
| 21:57.08 |
Ralith |
on my wiki
page? |
| 21:57.13 |
brlcad |
roberthl:
wow, no longer living in obscurity? :) |
| 21:57.19 |
brlcad |
er,
anonymity |
| 21:57.29 |
brlcad |
yeah, wiki
page work |
| 21:57.32 |
brlcad |
*works |
| 21:57.51 |
brlcad |
or blog or
tweets, just someplace convenient (and ideally
rss-able) |
| 21:58.22 |
brlcad |
pacman did a
pretty good job last year: http://brlcad.org/wiki/User:Pacman87 |
| 21:59.00 |
roberthl |
brlcad: Yeah,
I kind of gave up that when I started being payed to do stuff.
:) |
| 21:59.20 |
roberthl |
(development) |
| 21:59.28 |
brlcad |
nods |
| 21:59.50 |
mafm |
tweets are
the root of evil, just say no! :P |
| 22:04.05 |
*** join/#brlcad bz8z7
(n=543ebaea@bz.bzflag.bz) |
| 22:07.18 |
CIA-28 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1478 10/wiki/User:Ralith: Added first log entries |
| 22:15.12 |
``Erik |
hey, c'mon
now, indianlarry, some of us gov't foke are only no-show for 2
weeks :D |
| 22:22.43 |
pacman87 |
it's been
rather hectic at my house with relatives visiting for little
bro |
| 22:22.46 |
pacman87 |
's
graduation |
| 22:23.31 |
pacman87 |
and i got
recruited to move my brother in this week |
| 22:23.46 |
pacman87 |
so now
there's no more distractions |
| 22:24.28 |
pacman87 |
which
place? |
| 22:24.31 |
pacman87 |
the
speech? |
| 22:24.54 |
pacman87 |
ww |
| 22:25.24 |
pacman87 |
now
everything's back to normal |
| 22:25.29 |
pacman87 |
and i can get
back to coding full-time |
| 22:25.50 |
pacman87 |
speaking of
which, is there a good sample sketch i can use to test my
revolve? |
| 22:26.25 |
pacman87 |
just examples
of syntax for the two spline types, carcs, and lsegs |
| 22:36.23 |
brlcad |
could try the
sketch in http://brlcad.org/tmp/sketch.g |
| 22:36.43 |
brlcad |
includes each
entity type except the unimplemented nurbs type |
| 22:48.43 |
``Erik |
pacman87: if
you were to draw a half circle, then revolve around a line that
touch both ends of that arc like 30 degrees or so, would the
resultant geometry be something like an orange slice? am I gettin'
the purpose right? |
| 22:50.27 |
pacman87 |
yes |
| 22:50.42 |
pacman87 |
``Erik:
^^ |
| 22:51.41 |
*** join/#brlcad jdoliner
(n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) |
| 22:52.42 |
jdoliner |
sean, can you
explain to me how I should submit code? |
| 22:53.06 |
jdoliner |
brlcad? |
| 22:54.42 |
pacman87 |
jdoliner: are
you starting new files, or modifying existing ones? |
| 22:55.18 |
jdoliner |
I started a
new file in proc-db |
| 22:55.38 |
jdoliner |
and I've also
modified a file |
| 22:55.38 |
pacman87 |
do you have
commit access yet? |
| 22:55.44 |
jdoliner |
no I don't
believe so |
| 22:56.20 |
pacman87 |
go to the
brlcad sourceforge site |
| 22:56.27 |
pacman87 |
under
'tracker' click 'patches' |
| 22:56.48 |
pacman87 |
then click
'add new' |
| 22:56.59 |
pacman87 |
and there's
some instructions there |
| 22:57.50 |
jdoliner |
k
thanks |
| 22:58.09 |
``Erik |
yes, your
first few patches will be via the sourceforge patch submission page
so we can know that you understand the HACKING file and can produce
correct and consistent code :) |
| 23:01.38 |
``Erik |
hah, trying
to install cmake and accidently typed cake, got a rush of bad
memories off of that |
| 23:01.59 |
``Erik |
(cake was the
archaic fugly build system BRL-CAD used before I hacked it up for
automake :D ) |
| 23:14.50 |
jdoliner |
fair enough I
could use some criticism |
| 23:16.08 |
jdoliner |
would you
guys call brep on brep intersection geometry editing, or
modeling? |
| 23:19.35 |
brlcad |
probably
geometry editing, but that field isn't really important |
| 23:20.46 |
brlcad |
jdoliner:
yeah, the main issue with commit access is spelled out in the
HACKING file (which you've read right?) :) as well as http://brlcad.org/wiki/Google_Summer_of_Code/Checklist
(which you've read right?) :) just to make sure you understand your
responsibilities |
| 23:21.53 |
``Erik |
is rt^3
wanting dev or stable ogre3d? |
| 23:22.29 |
jdoliner |
yes of
course |
| 23:22.32 |
brlcad |
it shouldn't
take you more than a day really to get commit access sorted out, so
you can commit in good faith, but you aren't just given it before
showing some basic understanding (and your gsoc patch didn't show
that.. can talk about that if you like) |
| 23:22.55 |
jdoliner |
no that's
fine I just submitted my work up to this point |
| 23:23.12 |
brlcad |
keep in mind
that you absolutely should not be coding away quietly |
| 23:23.20 |
jdoliner |
it's now
using vmath macros instead |
| 23:23.32 |
``Erik |
you manually
reviewed your patch file, yes? :) I always do an svn diff before
commiting just to make sure |
| 23:23.32 |
jdoliner |
I swear I
haven't been |
| 23:23.33 |
brlcad |
getting
commit sorted out is priority #1, should have happened before gsoc
started really |
| 23:24.01 |
jdoliner |
k let's do
that immediately then |
| 23:24.13 |
brlcad |
also
shouldn't be communicating in private -- here or on mailing list if
it has anything to do with code/project/progress |
| 23:24.17 |
``Erik |
finds a pointy stick to jab brlcad with until he gets his
ogre question answered O:-) |
| 23:24.30 |
brlcad |
``Erik: ask
the Ralith guy, beats me! |
| 23:24.36 |
``Erik |
ok |
| 23:24.40 |
``Erik |
asks ralith and beats brlcad |
| 23:24.40 |
brlcad |
or
mafm |
| 23:24.45 |
brlcad |
heh |
| 23:24.57 |
mafm |
what about
Ogre? |
| 23:25.04 |
``Erik |
dev or
stable |
| 23:25.06 |
Ralith |
``Erik: g3d
you mean? |
| 23:25.08 |
mafm |
ralith
removed it yesterday with consent from starseeker |
| 23:25.10 |
Ralith |
Ogre stable
should work |
| 23:25.14 |
Ralith |
it's >=1.6
right? |
| 23:25.21 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1479 10/wiki/User:Jdoliner: |
| 23:25.25 |
mafm |
I noted that
I had put it there last year to have all dependencies
inside |
| 23:25.26 |
``Erik |
um, 1.6 is
stable |
| 23:25.32 |
Ralith |
then that'll
work |
| 23:25.43 |
Ralith |
mafm: iirc,
the reason it was there last year was because 1.6 wasn't stable yet
and we needed some 1.6 features |
| 23:25.45 |
``Erik |
I'll grab dev
anyways, there may be some future-proofing
opportunities |
| 23:25.55 |
``Erik |
(and damnit,
brlcad, you're supposed to know EVERYTHING) |
| 23:25.57 |
mafm |
but I don't
know which version Qt (or Ralith) needs |
| 23:26.15 |
mafm |
it only
needed a simple patch for RBGui |
| 23:26.20 |
Ralith |
well, the
Qt-in-Ogre-in-Qt thing I think I'm going with depends on a 1.6
feature |
| 23:26.29 |
mafm |
but now that
RBGui is gone, no problem for me |
| 23:26.31 |
brlcad |
reiterates http://brlcad.org/wiki/Google_Summer_of_Code/Expectations
for all students |
| 23:26.34 |
Ralith |
mafm: works
fine unpatched with RBGui, too. |
| 23:27.18 |
mafm |
probably
because they include the patch in newer versions -- it was only a
new function |
| 23:27.37 |
Ralith |
yeah, I think
I remember debugging that when I first tried a system ogre
actually |
| 23:27.51 |
mafm |
Frequent
communication with mentor -- ouch, I failed in that :P |
| 23:28.28 |
brlcad |
we'll
probably rebundle it later -- there's no problem either way until
we go to press a source release and have to consider dependency
management from non-developer compiling users |
| 23:34.43 |
mafm |
current
stable version is 1.6.2 (and recent, 2 months old), so if it's
enough, I'd go with it |
| 23:37.10 |
``Erik |
<-- did an
svn checkout of ogre3d's trunk |
| 23:42.17 |
``Erik |
yay,
dependancy hell :D |
| 23:46.15 |
mafm |
such a big
library (needing in turn other libraries) is indeed not
fun |
| 23:46.49 |
mafm |
isn't there
some concept in SVN about virtual repositories? |
| 23:47.26 |
mafm |
you have a
separate module (with ogre and the like) and then attach it to some
point in other directories (g3d and maybe others) |
| 23:47.43 |
mafm |
it could help
in maintenance if several parts depend on it |
| 23:48.16 |
mafm |
because OGRE
needs about a dozen other libraries... |
| 23:49.14 |
``Erik |
and zziplib
doesn't wanna build clean, neato |
| 00:36.07 |
CIA-32 |
BRL-CAD:
0389.136.118.141 07http://brlcad.org * r1482
10/wiki/More_Changelog: /* April, 20 ??? May, 23 - Bonding period
*/ |
| 00:38.02 |
``Erik |
effing broke
my wrist :( |
| 00:38.13 |
brlcad |
que?
como? |
| 00:39.15 |
brlcad |
hehe, I think
you're doing it wrong. *ahem* :) |
| 00:39.22 |
CIA-32 |
BRL-CAD:
0389.136.118.141 07http://brlcad.org * r1483
10/wiki/User:EBautu: |
| 00:39.29 |
``Erik |
heh |
| 00:40.23 |
``Erik |
was drunk
rough-housing, put the hand down to keep my an the kids skull from
smackng ground |
| 00:41.21 |
``Erik |
extended sick
leave in an unfun way :( |
| 00:42.08 |
``Erik |
unless I can
coerce daytona and bparker into carrying my |
| 00:42.08 |
``Erik |
me |
| 00:42.42 |
``Erik |
(which is an
unsubtle hint for you to chatter them) |
| 00:42.46 |
``Erik |
:D |
| 00:43.22 |
``Erik |
or anyone
else who can talk to 'em *shrug* |
| 00:45.03 |
brlcad |
you can't
drive with one arm? I manage it all the time ;) |
| 00:45.14 |
``Erik |
right arm is
out |
| 00:45.17 |
brlcad |
knee +
left-hand shift |
| 00:45.19 |
brlcad |
;) |
| 00:45.37 |
``Erik |
heh |
| 00:45.45 |
brlcad |
isn't kidding <cackle> |
| 00:46.32 |
``Erik |
clipped a
piece off the cup |
| 00:46.49 |
brlcad |
and there are
already plans for chinese buffet 'morrow :) |
| 00:47.10 |
``Erik |
which? |
| 00:47.25 |
``Erik |
lee's hunan
is one I can skip |
| 00:47.26 |
brlcad |
er, not
family |
| 00:47.38 |
brlcad |
ah, then you
won't miss anything :) |
| 00:48.09 |
``Erik |
I think that
spaghetti at grmpys had chicken |
| 00:48.18 |
brlcad |
man is this
ceviche awesome! |
| 00:48.31 |
``Erik |
heh, bring
some up! |
| 00:49.26 |
brlcad |
dont think
any will be left, only got a pound of orange roughy which will
probably be gone after tonight |
| 00:49.42 |
``Erik |
hey, what
kinda stuff does tidewater have? I really wanna go, ... but am not
100% |
| 00:49.50 |
brlcad |
have to make
a nother batch |
| 00:50.17 |
``Erik |
you should
bring some into work :) |
| 00:50.25 |
brlcad |
specialty is
seafood, but also have other stuff -- steak, salad, soups,
etc |
| 00:50.49 |
``Erik |
so a harbor
snob shop |
| 00:50.57 |
brlcad |
http://www.thetidewatergrille.com/menus/lunch-dinner-menu.html |
| 00:51.41 |
``Erik |
heh, the have
an extra e :) |
| 00:52.15 |
brlcad |
it's so they
can charge you more ;) |
| 00:52.33 |
brlcad |
mm.. that
ribeye sounds really good |
| 00:53.19 |
``Erik |
I'll keep the
page open an see how my hand is doing in a couple days |
| 00:53.35 |
``Erik |
I doubt steak
is in my near future :( |
| 01:06.59 |
starseeker |
``Erik:
broken broken or just hurt? |
| 02:56.52 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 02:57.48 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 04:18.49 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 07:15.15 |
*** join/#brlcad madant
(n=d@117.196.139.80) |
| 07:17.44 |
madant |
heh
http://www.flickr.com/photos/39304894@N05/3618699986/in/photostream/ |
| 07:19.30 |
*** join/#brlcad madant
(n=d@117.196.139.80) |
| 08:06.34 |
*** join/#brlcad madant
(n=d@117.196.133.218) |
| 08:56.32 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 09:00.38 |
*** join/#brlcad madant
(n=d@117.196.131.144) |
| 09:17.33 |
*** join/#brlcad _clock__
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 09:37.55 |
*** join/#brlcad madant
(n=d@117.196.130.166) |
| 09:46.47 |
CIA-32 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1484 10/wiki/User:Jdoliner: Updated with 3 days worth of
progress. |
| 11:14.46 |
*** join/#brlcad mafm
(n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) |
| 11:47.21 |
madant |
brlcad: where
exactly does mged search for the tab autocompletion ? |
| 11:49.06 |
archivist |
does it use
readline...wherever that stores its data |
| 11:50.10 |
``Erik |
um, there's a
list in tcl, daytona added it |
| 11:52.43 |
``Erik |
tab expansion
in src/tclscripts/mged |
| 11:56.49 |
madant |
``Erik: yay..
thanks :) |
| 12:03.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 12:21.17 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 12:36.47 |
brlcad |
~seen
elena |
| 12:36.48 |
ibot |
elena
<n=elena@89.136.118.141> was last seen on IRC in channel
#brlcad, 1d 19h 52m 37s ago, saying: 'ok. i will.'. |
| 12:37.16 |
brlcad |
madant: trust
you found it, yes? |
| 12:38.25 |
brlcad |
tab-completion needs to be refactored into
more of a C component at some point, or at least a tcl component
that is auto-loaded (you'll get an error presently if you run
classic-mode without installing) |
| 12:39.45 |
brlcad |
Ralith: fyi,
you're getting beyond danger zone at this point .. really gotta
kick up the activity in a massive way |
| 12:40.02 |
brlcad |
pacman87:
same for you too... |
| 12:41.13 |
brlcad |
it's easy to
get distracted with other priorities, but there's going to be no
possible way to recover if there are more days of
inactivity |
| 12:43.03 |
brlcad |
really don't
want to have to establish probationary failure criteria in order to
keep the activity going, but it might have to come to that given
folks aren't putting anywhere near full-time effort in
yet |
| 12:58.30 |
madant |
brlcad: hmm..
not really.. still figuring it out :) |
| 12:59.05 |
madant |
i was making
the first command in libged. lscon for listing constraint objects
in a databse |
| 12:59.52 |
madant |
it works in
mged now ( prints "Hi" that is) except for the
autocompletion |
| 13:16.00 |
mafm |
brlcad: slap
them with a large trout! |
| 13:34.46 |
mafm |
bah, nobody
likes my MIRC reference :'( |
| 13:35.07 |
madant |
cheers mafm :P |
| 13:35.40 |
mafm |
cries, only gets cheers for pitiness... |
| 13:35.53 |
madant |
has to go shopping with MOM |
| 13:36.19 |
madant |
has to go shopping wiht MOM RIGHT NOW :P talk about pity
:P |
| 13:37.39 |
mafm |
lol |
| 13:37.50 |
mafm |
I got a free
day from mom today |
| 13:38.03 |
mafm |
she went with
her ex-workmates :P |
| 13:38.08 |
_clock_ |
MOM RIGHT NOW
is it sume subspecies of MOM? |
| 13:39.01 |
mafm |
yep _clock_,
it's the most aggresive |
| 13:39.06 |
mafm |
worse than
polar bear mums |
| 13:46.47 |
brlcad |
mafm:
slapped |
| 13:46.56 |
*** join/#brlcad mafm_
(n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) |
| 13:47.42 |
brlcad |
hopefully
that message will convey the sheer urgency of the
situation |
| 13:52.31 |
brlcad |
as a
workaholic, I too-often tend to assume folks will simply work
more/harder/better when they miss time in order to get caught up,
but that's not been the case thusfar |
| 13:53.15 |
brlcad |
thankfully,
e-mail does not lend itself well to a blink tag ;) |
| 13:54.17 |
mafm_ |
IMPORTANT
SUBJECTS OMG would not help either, they to directly to spam
:P |
| 13:54.26 |
brlcad |
DEFEAT DOES
NOT EXIST IN THIS DOJO, DOES IT?! (NO SENSEI!) |
| 13:54.40 |
mafm_ |
:D |
| 13:55.51 |
mafm_ |
I've been a
bit sidetracked in the past weeks too |
| 13:56.20 |
mafm_ |
but I managed
to produce something regularly |
| 13:57.55 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 14:27.41 |
pacman87 |
is guilty as charged |
| 14:32.39 |
CIA-32 |
BRL-CAD:
03ebautu * r34728
10/web/trunk/htdocs/more/sites/all/modules/filefield/ (34 files in
7 dirs): filefield 2.4 (initial commit) |
| 14:49.51 |
madant |
anybody else
having all these Makefile.in and m4 scripts cropping up in the
other/step during svn status check. should i edit the svn:ignore
property ? |
| 14:50.33 |
madant |
same goes for
some htmls in docbook/lessons/mged |
| 14:51.39 |
starseeker |
the step
stuff yeah, I see it too - go for it on the property
changes |
| 14:51.58 |
starseeker |
dunno about
docbook/lessons/mged - thought I had all that - but if not go for
it |
| 14:55.54 |
madant |
starseeker:
for instance lessons/mged/mug_through_gui.html |
| 14:56.17 |
madant |
could i go
for svn:ignore *.html in lessons/mged ? :) |
| 14:56.42 |
starseeker |
sure |
| 14:58.10 |
madant |
kewl.. and
whats with all these m4 scripts m4/libtool.m4 .. creepy
.. |
| 15:01.08 |
``Erik |
urses |
| 15:01.09 |
``Erik |
curses,
even |
| 15:01.11 |
starseeker |
step is a
full fledged subconfigure |
| 15:01.31 |
starseeker |
it can
actually build as a standalone library |
| 15:01.54 |
``Erik |
all imports
can (src/other) |
| 15:04.13 |
starseeker |
I don't think
most of them do the whole autogen -> configure stage on their
own as a standalone checkout |
| 15:05.29 |
starseeker |
what I ment
was if you were to checkout just trunk/src/other/step from our svn
tree you don't need any of the top level autogen/configure scripts
- it's self contained |
| 15:06.00 |
starseeker |
I'm not sure
about that for all of the src/other libs |
| 15:06.05 |
starseeker |
particularly
opennurbs |
| 15:06.30 |
madant |
boost doesn't
even need building :) |
| 15:17.52 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34729 10/brlcad/trunk/ (13 files in 13 dirs):
svn:ignore set for various files |
| 15:18.50 |
CIA-32 |
BRL-CAD:
03ebautu * r34730
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Add option to filefield fields to select local files (required for
ftp model uploading) |
| 15:56.17 |
``Erik |
´no, many are
not aumomake |
| 15:57.23 |
CIA-32 |
BRL-CAD:
03ebautu * r34731
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Add handler to filefield fields to select local files (required for
ftp model uploading) |
| 16:00.54 |
mafm |
can see some relationship between brlcad's blackmailing and
the current surge in activity :D |
| 16:01.50 |
``Erik |
heh |
| 16:07.04 |
``Erik |
cept it aint
blackmail, it's step up or step off |
| 16:08.07 |
starseeker |
yep |
| 16:10.12 |
mafm |
he made them
an offer that they can't refuse |
| 16:10.19 |
mafm |
il
padrino |
| 16:11.17 |
madant |
:) |
| 16:11.40 |
madant |
il padrino
indeed :P |
| 16:13.44 |
madant |
oh wait my
commit didn't even have a single line change :P |
| 16:32.40 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E6CB.dip.t-dialin.net) |
| 16:33.19 |
CIA-32 |
BRL-CAD:
03ebautu * r34732
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Implement copy/move/link for local files in filefield fields (in
order to cope with huge 1GB+ files) |
| 16:35.34 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34733 10/brlcad/trunk/src/ (39 files in 39 dirs):
svn:ignore further directories and files - step, adrt,proc-db and
src/conv related |
| 16:53.23 |
madant |
brlcad: my
autogen.sh adds these files to the m4 in root as well as
src/other/step/m4 - libtool.m4, lt~obsolete.m4, ltsugar.m4
ltversion.m4 ltoptions.m4 should they be added to the svn:ignore
individually ? |
| 17:02.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 17:13.45 |
brlcad |
madant: it
adds files to m4?? what version of libtool do you have? |
| 17:16.49 |
brlcad |
otherwise,
yes -- you can/should individually (not globbed) add any files
generated during autogen.sh or configure |
| 17:23.40 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:24.13 |
brlcad |
jdoliner: hey
jd -- did you see indianlarry's message about the patch not
compiling? |
| 17:25.48 |
jdoliner |
yeah,
updating right now |
| 17:26.03 |
jdoliner |
although it
did still compile |
| 17:26.03 |
brlcad |
how'd it
compile for you? :) |
| 17:26.05 |
jdoliner |
atleast for
me |
| 17:27.04 |
brlcad |
hum |
| 17:28.05 |
jdoliner |
make
brepintersect |
| 17:28.16 |
jdoliner |
worked for
me |
| 17:29.31 |
jdoliner |
which in
retrospect is kinda weird I guess |
| 17:30.47 |
brlcad |
but that gave
you a brepintersect program that you could run? |
| 17:31.01 |
jdoliner |
yeah |
| 17:31.07 |
brlcad |
it should
fail outright during autogen.sh |
| 17:31.24 |
brlcad |
(which you
should run whenever you edit a Makefile.am or the configure.ac
file) |
| 17:31.42 |
jdoliner |
I see I
didn't know that |
| 17:31.54 |
jdoliner |
yeah "make
brepintersect" |
| 17:32.15 |
jdoliner |
was working
exactly how I wanted it to so I didn't think twice |
| 17:32.56 |
jdoliner |
okay just
uploaded the changes I made to the make file |
| 17:33.01 |
brlcad |
no
problem |
| 17:33.09 |
brlcad |
pretty minor
issue |
| 17:33.28 |
brlcad |
not exactly
within scope to become an expert on build systems and make
;) |
| 17:33.53 |
indianlarry |
jdoliner: i
take a look at now |
| 17:34.02 |
jdoliner |
thanks |
| 17:34.14 |
brlcad |
i'm just
surprised make is actually producing a product for which there
isn't a rule, using some default rules :) .. maybe a gnumake
feature, never seen that with bsdmake |
| 17:34.53 |
brlcad |
the patch is
still the old one or did you just upload something now? |
| 17:35.20 |
jdoliner |
I just
uploaded something new |
| 17:36.20 |
brlcad |
k |
| 17:38.10 |
indianlarry |
jdoliner:
where's your header file? |
| 17:38.21 |
indianlarry |
jdoliner: not
in patch |
| 17:38.35 |
jdoliner |
k |
| 17:38.40 |
jdoliner |
coming forth
with |
| 17:38.56 |
jdoliner |
forgot to svn
add that :? |
| 17:39.33 |
brlcad |
if you run
"svn status", it'll tell you the state of files including files it
doesn't know about annotated with ? |
| 17:39.33 |
indianlarry |
jdoliner: no
problem just let me know when it's up |
| 17:40.02 |
brlcad |
svn status
goes hand in hand with running svn diff when making a patch to make
sure you've included everything |
| 17:40.42 |
brlcad |
and that's
*not* just for patches .. you do the same for commits too ..
otherwise you're going to hose other developers and the
compilability of the code (especially for svn add's) |
| 17:43.27 |
madant |
brlcad
ltmain.sh (GNU libtool) 2.2.6 |
| 17:43.28 |
jdoliner |
k
uploaded |
| 17:43.36 |
indianlarry |
jdoliner: on
it |
| 17:44.00 |
brlcad |
madant:
libtoolize --version |
| 17:44.11 |
brlcad |
same
thing? |
| 17:44.28 |
madant |
yep |
| 17:44.35 |
brlcad |
okay,
interesting then |
| 17:44.44 |
brlcad |
that's the
newest libtool I've seen |
| 17:45.18 |
madant |
it basically
adds the same m4 scripts to the root m4 and the one in
step |
| 17:46.41 |
brlcad |
madant,
indianlarry, pacman87: you all should have tracker rights now to
update any tracker item data for any tracker item |
| 17:46.52 |
brlcad |
just
fyi |
| 17:47.08 |
madant |
yippeeee
:) |
| 17:47.22 |
pacman87 |
ok |
| 17:47.22 |
madant |
ok i should
start acting more matured around here |
| 17:47.51 |
brlcad |
just
shouldn't add/change any groups or categories (as they are
permanent and cannot be unchanged) |
| 17:47.59 |
brlcad |
at least
without discussion |
| 17:48.02 |
madant |
brlcad what
is the intaval at src/other ? |
| 17:48.37 |
brlcad |
intaval is a
geometry file format used in the UK -- it builds an importer
(tgf-g) |
| 17:49.20 |
brlcad |
madant: it's
no longer in src/other though... |
| 17:49.47 |
brlcad |
you probably
just have a stale directory (svn won't remove the dir if they have
files in them (like the generated Makefile)) |
| 17:49.55 |
madant |
yeah it has
an empty directory with a Makefile and Makefile.in :P |
| 17:50.09 |
indianlarry |
jdoliner: hey
all built okay, brlcad gave you commit access, make me proud
;^) |
| 17:51.11 |
jdoliner |
yippee |
| 17:51.12 |
madant |
jdoliner:
congrats :) |
| 17:51.31 |
madant |
i was very
thrilled when i got my commit access |
| 17:51.41 |
madant |
broke the
build within a week i think :P stupid boost |
| 17:51.45 |
brlcad |
jdoliner: go
ahead and commit your patch to make sure commit access is set up
okay, include useful commit message, etc |
| 17:51.49 |
brlcad |
hehe
madant |
| 17:51.51 |
madant |
i meant
boostlib |
| 17:53.03 |
brlcad |
yeah,
jdoliner -- don't expect you to get everything right, and
accidental breakage from time to time will occur, but do expect you
1) to try to not break it, 2) to fix it quickly when you do break
it and 3) to talk with the other devs, especially if you're unsure
or have questions ;) |
| 17:53.15 |
brlcad |
otherwise,
congrats! :) |
| 17:53.18 |
jdoliner |
thanks |
| 17:53.24 |
jdoliner |
password is
my sourceforge password? |
| 17:53.32 |
brlcad |
I sure hope
so |
| 17:53.33 |
madant |
jdoliner:
yep |
| 17:54.00 |
madant |
at some point
i want to shift my name from stupid homovulgaris to madant at
sourceforge |
| 17:54.03 |
brlcad |
one you set
it, it'll cache the password so you don't have to keep entering
it |
| 18:00.15 |
CIA-32 |
BRL-CAD:
03jdoliner * r34734 10/brlcad/trunk/src/proc-db/ (Makefile.am
brepintersect.cpp brepintersect.h): |
| 18:00.20 |
CIA-32 |
BRL-CAD:
Initial commit for breponbrep CSG support. Adds the functions
PointInTriangle, |
| 18:00.20 |
brlcad |
woo
hoo |
| 18:00.24 |
CIA-32 |
BRL-CAD:
SegmentSegmentIntersect, SegmentTriangleIntersect,
TriangleTriangleIntersect, |
| 18:00.26 |
CIA-32 |
BRL-CAD: and
stub for TriangleBrepIntersect in brepintersect.cpp. Also
adds |
| 18:00.28 |
CIA-32 |
BRL-CAD:
brepintersect.h, the header file for brepintersect.cpp. And
modifies the |
| 18:00.30 |
CIA-32 |
BRL-CAD:
Makefiles. |
| 18:00.35 |
brlcad |
nice |
| 18:00.40 |
jdoliner |
oh
baby |
| 18:00.49 |
indianlarry |
why to go
jdoliner |
| 18:01.03 |
jdoliner |
thanks
guys |
| 18:02.04 |
madant |
brlcad types
too fast didn't even give CIA time to finish :P |
| 18:02.25 |
``Erik |
effin
blankety blank |
| 18:02.27 |
brlcad |
CIA-32 is
slow |
| 18:02.57 |
pacman87 |
time to
upgrade to v33? |
| 18:04.03 |
brlcad |
heh |
| 18:14.45 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34735 10/brlcad/trunk/ (9 files in 5 dirs):
adding the framework for lscon (list constraints) command to
libged, associated tab-completion in mged |
| 18:15.11 |
madant |
mafm: step up
or step off always works :D |
| 18:18.10 |
madant |
brlcad,
elena: how do i access this more system ? i mean what do i do at
brlcad.org/more ? |
| 18:24.43 |
brlcad |
madant:
patience :) |
| 18:25.34 |
brlcad |
she's been
installing extension modules that are needed/useful |
| 18:25.56 |
brlcad |
then comes
configuration, then comes stubbing out a new module with
functionality |
| 18:38.41 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 18:44.54 |
madant |
brlcad: ok
:) |
| 18:58.24 |
mafm |
yay for
stepping up! |
| 19:09.31 |
madant |
mafm: moi ?
not sure if i did :) |
| 19:12.43 |
mafm |
only il
padrino knows |
| 19:19.20 |
``Erik |
woot, gratz
jdoliner |
| 19:19.55 |
jdoliner |
oh thanks
eric |
| 19:20.25 |
``Erik |
k... |
| 20:26.42 |
Ralith |
brlcad:
thanks for the notice |
| 20:27.23 |
*** join/#brlcad andax
(n=andax__@d213-102-41-56.cust.tele2.ch) |
| 20:34.11 |
Ralith |
today, if all
goes well, I should get RBGUI in Ogre in Qt to work |
| 20:34.39 |
Ralith |
then it's on
to the task of rendering Qt widgets within Ogre in Qt, which should
be easy. |
| 20:36.55 |
CIA-32 |
BRL-CAD:
03ebautu * r34736
10/web/trunk/htdocs/more/sites/all/modules/captcha/ (30 files in 5
dirs): captcha initial commit (3.2) |
| 20:39.13 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:39.34 |
Ralith |
mafm: you
around? |
| 20:45.17 |
CIA-32 |
BRL-CAD:
03ebautu * r34737
10/web/trunk/htdocs/more/sites/all/modules/fivestar/ (92 files in
15 dirs): fivestar initial commit (1.15) |
| 20:47.23 |
Ralith |
ffffff |
| 20:47.31 |
Ralith |
great time
for my wm to lose all semblance of stability >:| |
| 20:47.53 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 20:49.32 |
CIA-32 |
BRL-CAD:
03ebautu * r34738 10/web/trunk/htdocs/more/sites/all/modules/flag/
(21 files in 3 dirs): flag module initial commit (1.1) |
| 20:51.51 |
jdoliner |
ralith: my
window manager just detached one of the windows from its
shadows |
| 20:52.12 |
jdoliner |
it felt so
reminiscent of Peter Pan |
| 20:52.18 |
Ralith |
heh |
| 20:52.34 |
CIA-32 |
BRL-CAD:
03ebautu * r34739
10/web/trunk/htdocs/more/sites/all/modules/imageapi/ (13 files):
imageapi module initial commit (1.5) |
| 20:53.34 |
Ralith |
hokay,
functionality restored |
| 20:53.35 |
Ralith |
back to
work |
| 20:54.55 |
CIA-32 |
BRL-CAD:
03ebautu * r34740
10/web/trunk/htdocs/more/sites/all/modules/imagefield/ (12 files in
2 dirs): imagefield module initial commit (2.6) |
| 20:55.25 |
brlcad |
Ralith: sure,
and good to hear -- great info for your wiki log after today
;) |
| 20:55.55 |
Ralith |
yeah. I
think I need to buy this machine a new ramstick,
though. |
| 20:55.59 |
CIA-32 |
BRL-CAD:
03jdoliner * r34741 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
Added tests for SegmentTriangleIntersect. Fixed a bug in
SegmentTriangleIntersect |
| 20:56.06 |
Ralith |
if I don't
kill FF, just runninng g++ is going to drag me to a
halt |
| 20:56.19 |
pacman87 |
Ralith: what
are you running now? |
| 20:57.00 |
Ralith |
one 512MB
stick |
| 20:57.20 |
Ralith |
just loading
file menu to exit cleanly took a minute :| |
| 20:57.28 |
Ralith |
I did not
know building C++ took up this much RAM. |
| 20:59.09 |
Ralith |
firefox
annoyance #1: it doesn't exit when you think it's
exited |
| 20:59.15 |
Ralith |
breaks out the kill -9 |
| 20:59.39 |
Ralith |
watches half his memory free up :D |
| 21:01.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 21:02.30 |
CIA-32 |
BRL-CAD:
03ebautu * r34742
10/web/trunk/htdocs/more/sites/all/modules/mimedetect/ (9 files):
mimedetect module initial commit (1.3) |
| 21:27.51 |
CIA-32 |
BRL-CAD:
03ralith * r34743 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Added temporary accessors for Ogre-related
pointers to ease RBGui->Qt transition. |
| 21:28.22 |
Ralith |
argh. |
| 21:41.00 |
CIA-32 |
BRL-CAD:
0389.136.118.141 07http://brlcad.org * r1485
10/wiki/More_Changelog: |
| 21:41.03 |
Ralith |
...ahah! |
| 21:42.05 |
Ralith |
yay!
progress! |
| 21:42.24 |
CIA-32 |
BRL-CAD:
0389.136.118.141 07http://brlcad.org * r1486
10/wiki/More_Changelog: |
| 21:44.03 |
CIA-32 |
BRL-CAD:
03ralith * r34744 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Perform
OGRE initialization in constructor so that OGRE's various
singletons exist before the application formally
starts. |
| 22:08.54 |
Ralith |
argh. |
| 22:09.10 |
Ralith |
I'm going to
have to drag all the RBGui stuff into OgreGLWidget until RBGui is
completely purged >:| |
| 22:17.59 |
starseeker |
Ralith: well,
it's in a state of flux anyway :-) |
| 22:18.19 |
Ralith |
yeah, but
it's making my nice tidy widget implemenation all
messy. |
| 22:18.36 |
starseeker |
Ralith: Ah
:-) |
| 22:22.56 |
elena |
hi
Cliff. |
| 22:23.09 |
starseeker |
hey elena -
how goes it? |
| 22:23.32 |
elena |
fine. did you
had a change to look at the activity log? |
| 22:23.38 |
elena |
is it ok how
it is? |
| 22:24.40 |
starseeker |
yep, looks
goog |
| 22:24.42 |
starseeker |
er
good |
| 22:24.51 |
elena |
ok. thank
you. |
| 22:25.05 |
elena |
i'm working
now on the multiple upload methods. |
| 22:25.34 |
starseeker |
very good
:-) |
| 22:26.23 |
elena |
:) |
| 22:54.47 |
elena |
going to
bed. |
| 22:54.54 |
starseeker |
ok,
night! |
| 22:54.59 |
elena |
bye. have a
nice day. |
| 23:00.36 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EE79.dip.t-dialin.net) |
| 23:21.29 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 23:29.54 |
brlcad |
~ralith++ |
| 23:29.59 |
brlcad |
hooray for
progress :) |
| 23:33.41 |
starseeker |
brlcad: up
for a C++ question? |
| 23:33.48 |
brlcad |
always |
| 23:33.59 |
brlcad |
answer is
probably "don't do it!" |
| 23:34.10 |
brlcad |
s/it/whatever/ :) |
| 23:34.12 |
starseeker |
hehe |
| 23:35.05 |
starseeker |
OK, we
currently have BANodes and BVNodes defined for the curve and
surface trees. There are typedef statements that appear to be
linking each of those to ON_BoundingBox, e.g. typedef
BANode<ON_BoundingBox> BRNode; |
| 23:35.59 |
brlcad |
sorta, but
continue |
| 23:37.16 |
brlcad |
BANode<ON_BoundingBox> can be
thought of as a type of it's own, hence the typedef -- more
specifically, BANode is a template class, apparently a node
comprised of an ON_BoundingBox object |
| 23:38.29 |
starseeker |
OK, so that
node gets ON_BoundingBox + whatever was defined in
BANode? |
| 23:39.10 |
starseeker |
or is it JUST
a ON_BoundingBox that can be treated as also being of type
BANode? |
| 23:39.11 |
brlcad |
really all it
means is that BANodes use an ON_BoundingBox in some
fashion |
| 23:39.27 |
brlcad |
depends
entirely on how it was used |
| 23:39.33 |
starseeker |
OK. |
| 23:39.38 |
mafm |
Ralith:
intermittently :D |
| 23:39.51 |
brlcad |
the thing
between the <>'s is any type, used in some way by the
class |
| 23:40.33 |
brlcad |
for example,
BANode<int> could conceivably work, for example |
| 23:40.34 |
starseeker |
brlcad: The
functional consequence appears to be to allow the m_node.m_min
statements to actually return something, because m_min is defined
in ON_BoundingBox and is nowhere defined in opennurbs_ext.h that I
can see |
| 23:41.48 |
brlcad |
can sort of
think of the thing between the <>'s, e.g. <FOO> as a
#define FOO ON_BoundingBox .. and the BANode class uses FOO in
various places in its header |
| 23:41.49 |
starseeker |
and in the
class definition of BANode m_node is defined thusly: BA
m_node; |
| 23:42.06 |
brlcad |
so when you
say BANode<Whatever> it substitutes all the FOO's with
Whatever |
| 23:42.32 |
starseeker |
Ah,
OK |
| 23:43.50 |
brlcad |
templates
really are sorta similar to the preprocessor, just instead it's a
language intrinsic that the compiler knows about so it can actually
continue to perform proper type checking |
| 23:43.58 |
starseeker |
so that
definition means anything of class BA will satisfy the type
requirements and can be assigned to m_node? |
| 23:44.38 |
brlcad |
it means
m_node is of type <WHATEVER> |
| 23:45.34 |
brlcad |
so that
m_node.m_min is only valid for classes that have a m_min data
member, and trying to use a type like BANode<float> for
example, will result in a compile error |
| 23:46.10 |
brlcad |
because it's
like saying: float foo; foo.m_min = blah; |
| 23:46.21 |
starseeker |
ah.
OK |
| 23:46.31 |
brlcad |
instead it's
like: ON_BoundingBox foo; foo.m_min = blah; |
| 23:46.37 |
brlcad |
since that's
what was in the <>'s |
| 23:47.04 |
brlcad |
somewhere in
the definition you should see a line that says template <class
BA> |
| 23:47.08 |
starseeker |
erm. what is
the advantage of the typedef then over just using
ON_BoundingBox? |
| 23:47.10 |
starseeker |
yes |
| 23:48.31 |
starseeker |
is missing something... |
| 23:48.41 |
brlcad |
'class' is a
compiler hint saying it needs to be a class type, not some basic
type like int/float/etc; BA is the "#define BA ..."
symbol |
| 23:49.20 |
brlcad |
so then the
"BA m_node;" line can be thought of as being substituted by the
<> class type |
| 23:50.23 |
starseeker |
resulting on
ON_BoundingBox m_node; ? |
| 23:50.29 |
starseeker |
s/on/in |
| 23:50.32 |
brlcad |
yep |
| 23:51.19 |
starseeker |
now I REALLY
don't get why he didn't just use a straight up ON_BoundingBox
declaration |
| 23:51.49 |
brlcad |
templates are
quite powerful and can be very beautiful, allowing very flexible
and tuned performance |
| 23:52.02 |
brlcad |
template
errors are a spawn of the devil and cause premature
aging |
| 23:52.43 |
brlcad |
probably
because he wasn't sure he wanted to couple his class so strongly to
an ON class |
| 23:53.20 |
brlcad |
as a
template, he theoretically has to change very minimal to use his
own BB class, for example, or something highly optimized,
etc |
| 23:53.28 |
starseeker |
oh, so he
could just change that one line and avoid having to rewire all the
explicit ON_BoundingBox references? |
| 23:53.34 |
brlcad |
right |
| 23:53.54 |
mafm |
premature
aging, calculus is the kidneys, vomits and sometimes
diarrhea |
| 23:53.55 |
brlcad |
he would just
have to make a class that has a m_min data member and he would only
have to change one line |
| 23:53.58 |
brlcad |
that's pretty
cool |
| 23:55.40 |
starseeker |
proceeds to document that, no matter if it's overly basic and
only helpful for C++ ignoramuses... |
| 23:55.54 |
brlcad |
thinks starseeker will probably become a fan of boost for
their mathematical rigor once he gets the hang of
templates |
| 23:56.15 |
starseeker |
probably
:-) |
| 23:57.45 |
starseeker |
brlcad:
thanks for clearing that up - I was trying to see how all that
wired together and was having a bit of a time of i t |
| 23:58.50 |
mafm |
do you want
to learn the basics about templates? probably some of the functions
like std::max and the like are easy to grasp, and then some of the
classic data structures (lists, queues...) |
| 23:59.06 |
brlcad |
and yes,
fwiw, that's exceedingly basic c++ to be a persistent comment --
one intro course and that comment becomes the equivalent of
explaining "#define FOO bar" replaces all instances of FOO with
bar |
| 00:00.21 |
starseeker |
ok, fair
enough. |
| 00:01.45 |
brlcad |
now you could
document the requirement that it be a class that implements an
m_min data member and whatever particular API calls that are made
on that BA object, but then the compiler is going to fail on
anything that doesn't implement those anyways (yay,
typechecking) |
| 00:02.22 |
starseeker |
nods. It will only be an issue if we ever use something other
than ON_BoundingBox, which isn't terribly likely |
| 00:15.17 |
starseeker |
ah, there it
is |
| 00:15.28 |
starseeker |
indianlarry:
BASegment is used in intersectshierarchy |
| 00:15.41 |
starseeker |
er
intersectsHierarchy rather |
| 00:27.15 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 00:33.39 |
indianlarry |
starseeker:
will look into |
| 00:34.05 |
starseeker |
no rush -
it's not hurting anything :-) |
| 00:34.44 |
starseeker |
a preliminary
eval suggests it doesn't really need it, but not sure
yet |
| 00:35.24 |
indianlarry |
starseeker:
would be my guess but once we start delving into differences
between utah and other may come into play |
| 00:50.46 |
Ralith |
hm |
| 00:50.51 |
Ralith |
nobody around
here actually knows any Qt, right> |
| 00:50.52 |
Ralith |
? |
| 00:52.07 |
starseeker |
I
don't |
| 00:52.48 |
brlcad |
Ralith: its a
big api,have to be a lot more specific :) |
| 00:53.41 |
Ralith |
brlcad: just
digging around for a convenient way to run the OIS input state
update about every frame until RBGui is dead. |
| 00:53.49 |
brlcad |
but in
general, no api experts per se but certainly some
knowledge |
| 00:54.12 |
Ralith |
Qt provides
its own main loop so I can't just drop it in there as it's done
currently |
| 01:02.31 |
Ralith |
inspiration! |
| 01:05.07 |
brlcad |
Ralith: yes,
but you can create a QTimer that calls the OIS update |
| 01:05.36 |
Ralith |
yeah, I just
realized that I can tack this on to the draw function for the root
widget. |
| 01:05.38 |
brlcad |
can create
QTimers for pretty much anything that you want to exec for each
iteration of the main app llop |
| 01:06.00 |
Ralith |
which is
appropriate 'cuz it needs access to ogre internals
anyway |
| 01:06.11 |
brlcad |
you also can
override the main Qt event loop altogether (i.e., not call exec()),
but that's a lot more involved |
| 01:06.22 |
Ralith |
yeah, I
imagined so |
| 01:10.09 |
Ralith |
argh. |
| 01:11.14 |
starseeker |
indianlarry:
are the BANode and BVNode intersectedBy and intersectsHierarchy
codes pretty much the same? |
| 01:11.45 |
Ralith |
fffff mocha
>.< |
| 01:12.09 |
Ralith |
#ifndef
MOCHA_TIMER_H \ #define MOCHA_TIMER_H \ ... \ #endif \
} |
| 01:12.12 |
Ralith |
facepalms |
| 01:12.58 |
brlcad |
ah, here it
is .. something like: QTimer *input_timer = new QTimer(ois_handle);
connect(input_timer, SIGNAL(timeout()), ois_handle,
SLOT(update())); input_timer->start(0, TRUE); // execute
ois->update() repeatedly |
| 01:13.22 |
brlcad |
what's the
problem there? |
| 01:13.38 |
Ralith |
it closes a
block started inside the #ifndef outside of it. |
| 01:13.43 |
brlcad |
ah |
| 01:13.44 |
Ralith |
trivial fix
but geez. |
| 01:13.54 |
Ralith |
you'd think
they'd never used their own lib |
| 01:14.03 |
brlcad |
heh, yeah
kinda funny |
| 01:14.17 |
indianlarry |
starseeker:
yes wasn't sure if we needed at the time |
| 01:14.48 |
indianlarry |
starseeker:
not using for BANode |
| 01:14.57 |
starseeker |
nods |
| 01:15.10 |
starseeker |
ok, I didn't
think you were doing an explicit ray intersection |
| 01:22.13 |
CIA-32 |
BRL-CAD:
03ralith * r34745
10/rt^3/trunk/src/other/mocha/Include/Mocha/Timer.h: Fixed header
guard misalignment |
| 01:27.09 |
starseeker |
indianlarry:
I guess Ii'm being dense, but it looks like getClosestPointEstimate
is always going to throw new exception once it hits a leaf
node? |
| 01:29.16 |
starseeker |
Oh, I see -
that's just for non leaf nodes in general... |
| 01:30.05 |
starseeker |
or rather,
for BANode |
| 01:30.39 |
starseeker |
and it
iterates down until it does find a leaf node... got it |
| 01:31.27 |
Ralith |
hm. |
| 01:31.32 |
Ralith |
mafm: this
mean anything to you? |
| 01:32.15 |
Ralith |
http://codepad.org/CrBlBTsB |
| 01:32.18 |
Ralith |
goes to grab some food |
| 01:34.39 |
mafm |
Ralith: not
really |
| 01:35.22 |
mafm |
but I don't
know much about glsl and shaders |
| 01:35.36 |
mafm |
maybe it
needs some special library as Cg? |
| 01:36.02 |
Ralith |
nah, it was
working earlier |
| 01:36.05 |
Ralith |
it's
something I changed |
| 01:36.07 |
Ralith |
I'll fiddle
around after food. |
| 01:36.30 |
Ralith |
looks like
I'm pretty close to the milestone, though. |
| 01:38.13 |
mafm |
goody |
| 01:38.25 |
starseeker |
has OGRE compiled now :-) |
| 01:38.52 |
mafm |
you're still
using cmake? |
| 01:39.09 |
mafm |
maybe it's
something that you changed there? |
| 01:41.06 |
mafm |
anyway, I g2g
now |
| 01:41.10 |
mafm |
good
night |
| 01:41.17 |
brlcad |
cya
mafm |
| 01:56.58 |
starseeker |
heads out |
| 02:09.07 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 02:12.19 |
CIA-32 |
BRL-CAD:
03brlcad * r34746 10/brlcad/trunk/src/other/: careful with large
commits, don't ignore directories (blt) |
| 02:12.32 |
Ralith |
brlcad:
should I be avoiding committing code that doesn't currently
work? |
| 02:17.54 |
brlcad |
Ralith: you
should commit it, but you shouldn't enable it for
compilation |
| 02:18.23 |
brlcad |
#ifdef
work_in_progress or leave the file out of the compile,
etc |
| 02:18.42 |
Ralith |
wups, went
about this kinda wrong then. |
| 02:18.43 |
brlcad |
even if it
means a bit of temp minor scaffolding |
| 02:19.34 |
brlcad |
the eventual
goal is towards restructuring the way you approach a problem so
that you work on things in tiny incremental pieces |
| 02:19.54 |
Ralith |
nods |
| 02:20.05 |
brlcad |
so the code
is always "complete", functional even if you absolutely know it's
not how it'll need to be later |
| 02:21.47 |
Ralith |
hm, damn, the
ogre-in-Qt's-GL thing didn't Just Work. |
| 02:22.37 |
brlcad |
heh |
| 02:23.09 |
Ralith |
ooooh I
missed a step |
| 02:23.20 |
Ralith |
...wait, no I
didn't |
| 02:23.27 |
Ralith |
at least, not
according to the wiki page. |
| 02:38.45 |
Ralith |
uses break in gdb for the first time, and loves
it. |
| 02:39.13 |
Ralith |
interesting... the problem doesn't appear
to be in Ogre at all, but in RBGui. |
| 02:42.28 |
Ralith |
I don't
suppose anybody has an ogre.log lying around from a successful run
of old g3d? |
| 02:51.09 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 02:53.49 |
Ralith |
ahah. |
| 02:53.53 |
Ralith |
_renderWindow->getCustomAttribute("WINDOW",
&data); |
| 02:54.53 |
Ralith |
yyyup, that's
null. |
| 03:55.20 |
*** join/#brlcad madant_
(n=d@117.196.135.226) |
| 04:21.18 |
CIA-32 |
BRL-CAD:
03ralith * r34747 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Moved RBGui and OIS setup into OgreGLWidget until
they can be fully purged. |
| 04:22.55 |
Ralith |
damn, doesn't
look like I'll be able to get this entirely working
tonight. |
| 04:22.59 |
Ralith |
Very, very
close, though. |
| 04:24.42 |
Ralith |
brlcad: I'm
going to be mostly away from an internet connection tomorrow and a
large chunk of friday, but I will have the laptop with me and be
continuing work. Not sure how I'll keep the SVN commits small
under such circumstances, though, short of lots of manual
diffing. |
| 04:34.23 |
brlcad |
okay, don't
worry about the diffs, but do keep a log of all your changes for
the eventual commit message(s) .. try to sync when you can and/or
when you do get access, you can commit some parts piecewise for any
changes that aren't intertwined |
| 04:34.38 |
brlcad |
still update
the wiki log for each day |
| 04:35.19 |
Ralith |
yup |
| 04:35.24 |
Ralith |
ooh
:D |
| 04:35.49 |
Ralith |
I think the
messages I thought were fatal errors were actually harmless
warnings, meaning that the only visible issue is a missing material
file! |
| 04:39.20 |
CIA-32 |
BRL-CAD:
03pacman87 * r34748
10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: started
converting my math calculations into code to support the carc
segments in revolved sketches |
| 04:41.33 |
Ralith |
argh, that
one died and took my WM with it. |
| 04:45.36 |
Ralith |
okay,
something is wrong with the loading of the RBGui
shaders. |
| 05:12.28 |
louipc |
Ralith: git
ftw :P |
| 05:14.18 |
Ralith |
louipc: yeah,
I like distributed vc too, but svn's what we've got
here. |
| 05:15.08 |
louipc |
you can use
git-svn. I haven't really tested it out though |
| 05:17.15 |
Ralith |
yeah, I'd
rather just focus on the task at hand. |
| 05:18.07 |
louipc |
ah right you
have deadlines |
| 05:21.47 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1487 10/wiki/User:Ralith: Log update for 2009-06-17 |
| 05:22.30 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1488 10/wiki/User:Ralith: Fixed some external link
syntax |
| 05:23.06 |
Ralith |
...hmm, I
wonder if that error is actually related... |
| 05:25.39 |
Ralith |
builds latest ogre to find out |
| 08:15.52 |
CIA-32 |
BRL-CAD:
03jdoliner * r34749 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
added functionality in PointInTriangle so that planarity is no
longer assumed but actually checked |
| 09:02.06 |
madant_ |
brlcad:
similar to blt i think i had ignored src/mk as well |
| 10:08.51 |
*** join/#brlcad madant
(n=d@117.196.129.244) |
| 10:24.31 |
*** join/#brlcad madant_
(n=d@117.196.128.13) |
| 10:36.36 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB9F.dip.t-dialin.net) |
| 11:05.43 |
brlcad |
madant_: then
you should unignore those :) |
| 11:18.19 |
*** join/#brlcad mafm
(n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) |
| 11:26.43 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34750 10/brlcad/trunk/src/ (. proc-db/): unignore
src/mk , ignore brepintersect |
| 11:27.12 |
brlcad |
brepintersect
is a product no? |
| 11:28.10 |
brlcad |
it's okay to
ignore products, things normally generated during a
build |
| 11:28.48 |
brlcad |
the only ones
that shouldn't be ignored are special build products like the
plethora of testing files generated during "make test" |
| 11:31.23 |
madant_ |
k.. i didn't
understand the mk directory though |
| 11:32.17 |
brlcad |
it's a stale
directory -- exactly why it shouldn't be ignored, it lets you know
that it was removed and you have files in there that should be
deleted |
| 11:32.20 |
madant |
i mean it is
generated during the build process ? |
| 11:32.28 |
brlcad |
no |
| 11:32.37 |
brlcad |
no dirs are
created during build |
| 11:32.44 |
madant |
k |
| 11:33.07 |
brlcad |
it used to be
a dir with source files, part of the build |
| 11:33.11 |
brlcad |
in
svn |
| 11:33.26 |
brlcad |
when the
directory was removed, svn goes to remove your local
copy |
| 11:33.31 |
brlcad |
but you had
extra files in there |
| 11:34.04 |
madant |
ah.. ok.. got
it now.. still 18 ? in my svn status .. mainly those m4s i were
referring to yesterday.. starseeker has them too i think
? |
| 11:34.07 |
brlcad |
namely, old
build files (hence the Makefile Makefile.in and .o files but no
Makefile.am or *.c files) .. |
| 11:34.29 |
brlcad |
it removed
the svn entities but couldn't remove the dir because you had
unknown files in there |
| 11:34.55 |
brlcad |
it's not
going to just delete your files that it's not managing -- those
could be source files or something important |
| 11:39.12 |
madant |
brlcad: also
in src/other/step/src/express these three files are created every
build expscan.c expparse.c expparse.h |
| 11:39.46 |
brlcad |
yeah, I've
seen those |
| 11:40.02 |
brlcad |
I'd left them
simply because they're actually generated source, but could go
either way |
| 11:40.59 |
madant |
and the
scl_config.h.in, scl_config.h and stamp-h1 in step/include
? |
| 11:41.20 |
madant |
step building
seems complicated to my sorry ass :P |
| 11:41.42 |
brlcad |
it is
complicated, it's an exceptionally complicated file format
:) |
| 11:42.08 |
brlcad |
(bar none,
the most complex) |
| 11:43.32 |
brlcad |
you could
ignore those three -- they are the equivalent to our
include/brlcad_config.h.in include/brlcad_config.h and
include/stamp-h1 |
| 11:43.39 |
brlcad |
byproducts
from configure |
| 11:44.07 |
brlcad |
svn propget
svn:ignore include/. |
| 11:48.13 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34751 10/brlcad/trunk/src/other/step/include/:
ignoring configure byproducts in src/include |
| 11:48.30 |
madant |
that's it..
only m4 scripts and the generated files now.. onto some real work
now :P |
| 11:52.16 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 12:28.11 |
*** join/#brlcad madant_
(n=d@117.196.129.9) |
| 12:31.07 |
CIA-32 |
BRL-CAD:
03indianlarry * r34752 10/brlcad/trunk/ (3 files in 3
dirs): |
| 12:31.09 |
CIA-32 |
BRL-CAD:
corrected plotting of linear trim sections in debug code,
now |
| 12:31.11 |
CIA-32 |
BRL-CAD:
remove vertical trims from "above" list after initial bbox
intersect |
| 12:31.13 |
CIA-32 |
BRL-CAD:
test, fixed logical condition when closest trim bboxes
overlap |
| 13:25.02 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 13:33.05 |
*** join/#brlcad madant
(n=d@117.196.130.18) |
| 13:40.31 |
*** join/#brlcad mafm_
(n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) |
| 13:48.43 |
*** join/#brlcad madant_
(n=d@117.196.133.120) |
| 13:57.14 |
*** join/#brlcad madant__
(n=d@117.196.133.205) |
| 14:11.47 |
*** join/#brlcad madant
(n=d@117.196.133.17) |
| 14:15.44 |
CIA-32 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1489 10/wiki/User:Homovulgaris: log added, bio
updated |
| 14:29.40 |
*** join/#brlcad madant_
(n=d@117.196.132.245) |
| 14:53.14 |
*** join/#brlcad madant
(n=d@117.196.131.95) |
| 14:59.25 |
CIA-32 |
BRL-CAD:
03ebautu * r34753
10/web/trunk/htdocs/more/sites/all/modules/widgeditor/ (21 files in
4 dirs): widgeditor module initial commit (1.1) |
| 15:04.18 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 15:10.22 |
CIA-32 |
BRL-CAD:
03ebautu * r34754
10/web/trunk/htdocs/more/sites/all/modules/votingapi/ (6 files):
votingapi module initial commit (1.6) |
| 15:19.55 |
CIA-32 |
BRL-CAD:
03ebautu * r34755
10/web/trunk/htdocs/more/sites/all/modules/nodequeue/ (27 files in
3 dirs): nodequeue module initial commit (2.6) |
| 16:57.31 |
*** join/#brlcad docelic
(n=docelic@78.134.205.71) |
| 17:12.51 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:31.11 |
*** join/#brlcad madant_
(n=d@117.196.131.86) |
| 18:27.42 |
CIA-32 |
BRL-CAD:
03ebautu * r34756
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Allow local files to be copies, moved or linked during model
submission (move and link are useful for very large
files). |
| 18:29.29 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 18:33.53 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 18:53.01 |
CIA-32 |
BRL-CAD:
03ebautu * r34757
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Implement customizable local path for filefield. |
| 18:56.52 |
CIA-32 |
BRL-CAD:
03ebautu * r34758
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Default local file path to empty to prevent redundant
processing. |
| 19:20.57 |
CIA-32 |
BRL-CAD:
03jdoliner * r34759 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
SegmentTriangleIntersect now passes all tests in the basic
case |
| 19:23.37 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 19:25.14 |
CIA-32 |
BRL-CAD:
03ebautu * r34760
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Factor out local file processing code to
_filefield_process_local_file and add security
checking. |
| 19:27.03 |
CIA-32 |
BRL-CAD:
03ebautu * r34761
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Security checkings for local files. |
| 19:55.53 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DB9F.dip.t-dialin.net) |
| 20:30.08 |
CIA-32 |
BRL-CAD:
03ebautu * r34762
10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/page.tpl.php:
Theme bug fixed (display status messages) |
| 20:31.47 |
elena |
hi
starseeker. are you around? |
| 20:31.47 |
CIA-32 |
BRL-CAD:
03ebautu * r34763
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.module:
Implemented Ajax autocomplete for local files (includes filename,
size and created time). |
| 20:31.53 |
starseeker |
howdy |
| 20:31.55 |
starseeker |
what's
up? |
| 20:32.30 |
elena |
i just wanted
to let you know next week i'll go to another time to meet my PhD
advisor. |
| 20:32.54 |
elena |
I plan to
catch up for the lost days this saturday and following
weekends. |
| 20:32.56 |
starseeker |
time zone you
mean? |
| 20:33.06 |
starseeker |
ok |
| 20:33.12 |
elena |
sorry. time
=> town. |
| 20:33.15 |
starseeker |
ah |
| 20:33.16 |
elena |
a bit tired
:) |
| 20:33.25 |
starseeker |
np - good to
see the commits :-) |
| 20:33.34 |
elena |
it would be
cool to go to another time, too :D |
| 20:34.00 |
elena |
yes. it's
starting to shape up so i started to put it live, too. |
| 20:34.24 |
elena |
i almost
finished to implement local repository for files. |
| 20:35.10 |
elena |
so model
files could be uploaded (normal and ajax style) or they could be
send by ftp/scp and just selected when submitting the model
info. |
| 20:35.22 |
elena |
works really
nice :) |
| 20:35.28 |
elena |
says proudly |
| 20:35.36 |
starseeker |
excellent
:-) |
| 20:35.54 |
elena |
i'll go
update the wiki now |
| 20:36.00 |
starseeker |
nods |
| 20:36.10 |
elena |
and do some
more work after that. |
| 20:36.26 |
elena |
i'll start
uploading the db soon. |
| 20:36.34 |
starseeker |
sounds
good |
| 20:36.44 |
elena |
i'll try to
upload it so i don't have to redo all the settings
again. |
| 20:36.50 |
elena |
i hope it
works, |
| 20:37.34 |
elena |
how are
you? |
| 20:38.43 |
starseeker |
doing ok -
busy |
| 20:38.55 |
elena |
ok. then i
won't keep you. |
| 20:39.04 |
elena |
have a
wonderful day. |
| 20:39.05 |
starseeker |
nice work
elena :-) |
| 20:39.12 |
elena |
thank
you. |
| 20:47.42 |
CIA-32 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1490 10/wiki/More_Changelog: /* June, 17 - today */ |
| 20:49.48 |
CIA-32 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1491 10/wiki/More_Changelog: /* June, 17 - today */ |
| 20:54.52 |
CIA-32 |
BRL-CAD:
03ebautu * r34764
10/web/trunk/htdocs/more/sites/all/modules/filefield/filefield.info:
Tag info file with customization information. |
| 21:18.28 |
starseeker |
blinks |
| 21:19.48 |
starseeker |
indianlarry:
time without any bbox growth on shape1.s - 10.1s - time with 3D
bbox growth - 14.1s |
| 21:20.45 |
``Erik |
correctness,
though? |
| 21:20.55 |
starseeker |
no
errors |
| 21:20.56 |
``Erik |
a fast wrong
result is still wrong |
| 21:21.09 |
starseeker |
in the latter
case |
| 21:21.16 |
starseeker |
sure, no bbox
growth results in errors |
| 21:21.30 |
starseeker |
but when the
boxes were being expanded in uv space, the time was more like 23
sec |
| 21:22.16 |
``Erik |
not my scene,
just want ya'll asking the right questios |
| 21:22.32 |
starseeker |
sure, we know
we need it correct first |
| 21:22.55 |
``Erik |
busted wrist
-- |
| 21:23.17 |
starseeker |
actually
broken? owww |
| 21:23.48 |
``Erik |
yup |
| 21:23.49 |
starseeker |
that sucks -
sorry to hear that :-( |
| 21:25.05 |
``Erik |
took a chip
odd the ukna |
| 21:25.10 |
``Erik |
ulna |
| 21:28.30 |
starseeker |
winces |
| 21:28.36 |
starseeker |
how long to
fix it? |
| 21:28.57 |
``Erik |
d'no, been
doing phoe tag, ain't got a doc yet |
| 21:29.33 |
``Erik |
broke it
monday, er tuestday, still in the fuzz ... |
| 21:57.36 |
CIA-32 |
BRL-CAD:
0388.106.219.75 07http://brlcad.org
* r1492 10/wiki/Compiling: /* History */ |
| 22:14.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 22:38.04 |
CIA-32 |
BRL-CAD:
03jdoliner * r34765 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
fixed several bugs in SegmentTriangleIntersect. Function now works
with all degenerate cases. |
| 23:58.20 |
CIA-32 |
BRL-CAD:
03brlcad * r34766 10/brlcad/trunk/HACKING: move the build system up
so we can finish the section with style. expand on the style
examples separating indentation from interior ws. |
| 00:39.17 |
CIA-32 |
BRL-CAD:
03ralith * r34774 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Stripped references to RBGui from OgreGLWidget in
light of the incompatibilities between recent Ogre SVN and the
RBGui-Ogre interface. |
| 00:41.17 |
Ralith |
<3
shell |
| 00:41.22 |
Ralith |
grep -i rbgui
* |grep cxx |cut -d ':' -f 1 |uniq |
| 01:24.21 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:57.02 |
CIA-32 |
BRL-CAD:
03ralith * r34775 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Moved debug messages to Logger |
| 02:19.24 |
Ralith |
fixes ogre up to not prematurely kill Qt's
context |
| 02:19.50 |
Ralith |
brlcad: since
we need the dev version, and now a minor patch, shall I bring ogre
back into rt^3/src/other? |
| 02:20.50 |
brlcad |
probably a
good idea |
| 02:21.06 |
Ralith |
I'll throw
the patch upstream, and it will probably get accepted, but at least
in the meantime... |
| 02:21.07 |
brlcad |
it's nice for
it to be as simple as possible for others to try things
out |
| 02:21.13 |
Ralith |
yeah. |
| 02:21.23 |
brlcad |
even if it
means more headaches for the active devs |
| 02:21.59 |
brlcad |
unless adding
it in actually makes things worse because it's not integrated well
or there's some build system problem or it has other bugs/issues
etc :) |
| 02:22.05 |
Ralith |
okay,
OgreGLContext starts up and shuts down fine within a Qt app. Now I
need to get something rendered to see if it's actually doing
anything. |
| 02:25.37 |
brlcad |
awesome! |
| 02:25.44 |
brlcad |
pics when you
do! :) |
| 02:25.54 |
Ralith |
'kay |
| 02:26.25 |
Ralith |
hm |
| 02:26.33 |
Ralith |
can you
recommend a good, feature-complete but lightweight
browser? |
| 02:26.44 |
Ralith |
I need
something to use when I have firefox closed for memory
reasons |
| 02:26.56 |
Ralith |
currently I'm
making do with dillo, but that can't log in to sf.net 'cuz no https
or cookies. |
| 02:33.35 |
Ralith |
hm, arora
looks shinyful. |
| 02:38.23 |
brlcad |
not really,
not something I've had to work with lately |
| 02:44.04 |
Ralith |
arora does
the job nicely. |
| 02:44.13 |
Ralith |
okay, patch
submitted upstream. |
| 02:53.35 |
CIA-32 |
BRL-CAD:
03ralith * r34776 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx:
Simplified destructor |
| 03:23.56 |
starseeker |
hasn't heard of arora |
| 03:24.08 |
starseeker |
hmm, does
look interesting... |
| 03:24.59 |
starseeker |
Ralith: in a
worst case scenario might check out elinks, links and
links2 |
| 03:25.58 |
Ralith |
starseeker: I
guess those do do https+cookies iirc, but that's pretty worst
case. |
| 03:26.04 |
Ralith |
arora does
the trick nicely, thankfully. |
| 03:27.27 |
Ralith |
grargh! |
| 03:27.40 |
Ralith |
% svn ci
ogre |
| 03:27.43 |
Ralith |
...time
passes... |
| 03:27.46 |
Ralith |
...more time
passes... |
| 03:27.50 |
Ralith |
......... |
| 03:27.59 |
Ralith |
svn: PUT of
'/svnroot/brlcad/!svn/wrk/adfd0d86-e975-4225-90e5-9fe45f183f57/rt%5E3/trunk/src/other/ogre/Samples/Media/packs/OgreCore.zip':
could not connect to server (https://brlcad.svn.sourceforge.net |
| 03:28.06 |
starseeker |
may have seen a tornadic rotation today in Bel
Air |
| 03:28.52 |
Ralith |
tries again |
| 03:31.22 |
starseeker |
Ralith: if
you're uploading ogre to svn, that'll be a process |
| 03:31.29 |
Ralith |
a
process? |
| 03:31.42 |
starseeker |
I recommend
doing it a few directories at a time |
| 03:32.05 |
starseeker |
smaller
"bites" seem to work better with the sf servers, in my
experience |
| 03:32.23 |
Ralith |
okay, let's
try that. |
| 03:32.40 |
starseeker |
flashes back to getting the docbook support files in
there... |
| 03:36.22 |
Ralith |
gah |
| 03:36.29 |
Ralith |
how do I set
a global default svn:mime-type :| |
| 03:39.24 |
Ralith |
FFFF |
| 03:43.48 |
Ralith |
okay,
finally, one down. |
| 03:43.52 |
CIA-32 |
BRL-CAD:
03ralith * r34777 10/rt^3/trunk/src/other/ogre/ (28 files in 15
dirs): |
| 03:43.54 |
CIA-32 |
BRL-CAD:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Commit |
| 03:43.57 |
CIA-32 |
BRL-CAD: 1 of
? |
| 03:45.55 |
Ralith |
starseeker:
now I'm consistently getting 'connection reset by peer' trying to
commit a reasonably-sized directory. |
| 03:46.05 |
Ralith |
svn: PUT of
'/svnroot/brlcad/!svn/wrk/c15f0990-e0bc-4000-8927-761347c0a79c/rt%5E3/trunk/src/other/ogre/CMake/Packages/FindDirectX.cmake':
SSL negotiation failed: Connection reset by peer (https://brlcad.svn.sourceforge.net) |
| 03:46.26 |
Ralith |
not always
quite the same file |
| 03:48.39 |
Ralith |
autoprops is
broken >.< |
| 03:51.37 |
starseeker |
Ralith:
here's brlcad's mime-types wiki article if it helps: http://brlcad.org/wiki/Mime-types |
| 03:52.02 |
Ralith |
ah, that
looks helpful. |
| 03:55.17 |
Ralith |
gaaah. |
| 03:55.26 |
Ralith |
now svn's
somehow screwed up my term. |
| 03:56.13 |
Ralith |
I really
really hate svn sometimes :| |
| 03:56.24 |
Ralith |
grabs some food while he re-exports ogre |
| 03:57.57 |
Ralith |
wtf. |
| 03:58.14 |
Ralith |
ralith@monolith:~/dev/brlcad/rt^3/src/other%
svn add ogre |
| 03:58.17 |
Ralith |
svn: run 'svn
cleanup' to remove locks (type 'svn help cleanup' for
details) |
| 03:58.20 |
Ralith |
ralith@monolith:~/dev/brlcad/rt^3/src/other%
svn cleanup |
| 03:58.22 |
Ralith |
svn: 'ogre'
is not a working copy directory |
| 03:58.28 |
Ralith |
ralith@monolith:~/dev/brlcad/rt^3/src/other%
svn add ogre |
| 03:58.30 |
Ralith |
svn: run 'svn
cleanup' to remove locks (type 'svn help cleanup' for
details) |
| 03:58.56 |
Ralith |
okay, that
was easier than I expected to clear up. |
| 03:59.59 |
Ralith |
what the
hell |
| 04:00.06 |
Ralith |
am I going to
have to check out rt^3 from scratch or something |
| 04:00.17 |
Ralith |
why is it so
hard to delete something you added :| |
| 04:00.30 |
starseeker |
can you
revert the directory in question? |
| 04:00.47 |
Ralith |
ralith@monolith:~/dev/brlcad/rt^3/src/other%
svn revert ogre |
| 04:00.48 |
Ralith |
ralith@monolith:~/dev/brlcad/rt^3/src/other%
svn add ogre |
| 04:00.48 |
Ralith |
svn: warning:
'ogre' is already under version control |
| 04:01.18 |
starseeker |
you'll have
to individually add subdirectories |
| 04:01.24 |
starseeker |
svn add
ogre/foodir |
| 04:02.05 |
Ralith |
okay, wait,
finally got it. |
| 04:02.29 |
CIA-32 |
BRL-CAD:
03ralith * r34778 10/rt^3/trunk/src/other/ogre/: Undo previous
add |
| 04:07.59 |
CIA-32 |
BRL-CAD:
03ralith * r34779 10/rt^3/trunk/src/other/ogre/ (28 files in 15
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 04:08.17 |
Ralith |
makes a script do all the work |
| 04:08.18 |
Ralith |
:D |
| 04:08.21 |
CIA-32 |
BRL-CAD:
03ralith * r34780 10/rt^3/trunk/src/other/ogre/Samples/ (38 files
in 37 dirs): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 04:08.27 |
CIA-32 |
BRL-CAD:
03ralith * r34781 10/rt^3/trunk/src/other/ogre/Samples/Dot3Bump/
(CMakeLists.txt scripts/ src/): Added Ogre SVN (r8739, latest as of
this commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 04:08.40 |
CIA-32 |
BRL-CAD:
03ralith * r34782
10/rt^3/trunk/src/other/ogre/Samples/Dot3Bump/src/Dot3Bump.cpp:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 04:08.47 |
CIA-32 |
BRL-CAD:
03ralith * r34783 10/rt^3/trunk/src/other/ogre/Samples/DynTex/
(CMakeLists.txt include/ scripts/ src/): Added Ogre SVN (r8739,
latest as of this commit) due to serious bugs in features needed by
g3d in Ogre stable. Partial commit. |
| 04:09.01 |
CIA-32 |
BRL-CAD:
03ralith * r34784
10/rt^3/trunk/src/other/ogre/Samples/DynTex/src/DynTex.cpp: Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 04:09.08 |
Ralith |
...hmm, this
is too spammy, isn't it |
| 04:09.09 |
CIA-32 |
BRL-CAD:
03ralith * r34785 10/rt^3/trunk/src/other/ogre/Samples/Smoke/
(CMakeLists.txt include/ scripts/ src/): Added Ogre SVN (r8739,
latest as of this commit) due to serious bugs in features needed by
g3d in Ogre stable. Partial commit. |
| 04:09.16 |
CIA-32 |
BRL-CAD:
03ralith * r34786
10/rt^3/trunk/src/other/ogre/Samples/Smoke/include/Smoke.h: Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 04:09.20 |
Ralith |
my
bad. |
| 04:10.02 |
starseeker |
I'd suggest
not doing it file by file ;-) |
| 04:10.08 |
Ralith |
it was
directory-by-directory |
| 04:10.11 |
Ralith |
but that's
still quite a lot. |
| 04:10.33 |
starseeker |
limit depth
to (say) 2? |
| 04:11.23 |
Ralith |
I'm not sure
svn can do that, nor how to structure a find(1) query to get the
proper dirs. |
| 04:11.32 |
Ralith |
grah, now i
can't get autoprops to rerun again. |
| 04:11.39 |
Ralith |
this is
incredibly painful. |
| 04:12.23 |
Ralith |
I'm going to
go eat and try again after. |
| 04:27.10 |
Ralith |
okay,
idea |
| 04:27.19 |
Ralith |
no wait, that
will probably just make it harder. |
| 04:32.13 |
Ralith |
wonders how mafm managed to do this
originally |
| 04:34.33 |
Ralith |
why can't svn
just prompt for a default property setting ;_; |
| 04:34.55 |
CIA-32 |
BRL-CAD:
03ralith * r34787 10/rt^3/trunk/src/other/ogre/CMake/ (48 files in
4 dirs): |
| 04:34.57 |
CIA-32 |
BRL-CAD:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. |
| 04:35.00 |
CIA-32 |
BRL-CAD:
Partial commit. |
| 04:35.59 |
CIA-32 |
BRL-CAD:
03ralith * r34788 10/rt^3/trunk/src/other/ogre/Components/ (59
files in 10 dirs): |
| 04:36.00 |
CIA-32 |
BRL-CAD:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. |
| 04:36.03 |
CIA-32 |
BRL-CAD:
Partial commit. |
| 04:37.17 |
CIA-32 |
BRL-CAD:
03ralith * r34789
10/rt^3/trunk/src/other/ogre/Dependencies/OgreInstallDependencies.cmake: |
| 04:37.19 |
CIA-32 |
BRL-CAD:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. |
| 04:37.22 |
CIA-32 |
BRL-CAD:
Partial commit. |
| 04:44.12 |
Ralith |
why is zsh
echoing input and beeping instead of running my script
:| |
| 04:48.02 |
Ralith |
wtf! |
| 04:48.06 |
Ralith |
svn: warning:
'Docs' is not under version control |
| 04:48.14 |
Ralith |
svn: warning:
'ogre/Docs' is already under version control |
| 04:48.53 |
Ralith |
ooh. |
| 05:03.40 |
CIA-32 |
BRL-CAD:
03ralith * r34790 10/rt^3/trunk/src/other/ogre/Docs/ (205 files in
15 dirs): |
| 05:03.40 |
CIA-32 |
BRL-CAD:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. |
| 05:03.45 |
CIA-32 |
BRL-CAD:
Partial commit. |
| 05:11.06 |
CIA-32 |
BRL-CAD:
03ralith * r34791 10/rt^3/trunk/src/other/ogre/Mac/ (42 files in 21
dirs): |
| 05:11.06 |
CIA-32 |
BRL-CAD:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. |
| 05:11.08 |
CIA-32 |
BRL-CAD:
Partial commit. |
| 05:42.28 |
*** join/#brlcad cady
(n=marc_vre@195-240-188-51.ip.telfort.nl) |
| 06:00.47 |
Ralith |
ugh |
| 06:01.04 |
Ralith |
the sf svn
servers are unreliable :| |
| 06:17.22 |
louipc |
:O |
| 06:37.31 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1499 10/wiki/User:Ralith: Log for 2009-06-20 |
| 06:56.06 |
*** part/#brlcad cady
(n=marc_vre@195-240-188-51.ip.telfort.nl) |
| 07:53.20 |
*** join/#brlcad madant
(n=cb7baf0f@bz.bzflag.bz) |
| 07:54.30 |
madant |
has reached his univ and room which is going to be his abode
for 2 years |
| 07:55.22 |
madant |
hates it when there is no decent access to at least a socks
proxy even if not a completely open network |
| 08:23.46 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 08:27.39 |
madant |
sheesh. fried
my brains for an hour trying to figure out a build error only to
realize constraint was spelled constriant somewhere :( |
| 08:27.48 |
madant |
howdy
jdoliner |
| 08:29.29 |
jdoliner |
hi |
| 08:29.35 |
jdoliner |
you're up
awfully late |
| 08:29.52 |
jdoliner |
but maybe
you'd like to give me your opinion on something |
| 08:29.55 |
jdoliner |
? |
| 08:32.02 |
madant |
er. my
opinions are not very valuable. but sure :) |
| 08:32.34 |
madant |
and it is
14:03 here. though i haven't slept since yesterday . |
| 08:32.45 |
jdoliner |
I
see |
| 08:33.01 |
jdoliner |
I was
accidentally correct |
| 08:33.15 |
jdoliner |
so suppose I
have two meshes and I want to find their intersection |
| 08:33.38 |
jdoliner |
and so
basically I find the curve they intersect in |
| 08:33.47 |
jdoliner |
by just
intersecting them triangle by triangle |
| 08:33.53 |
jdoliner |
which is all
well and good |
| 08:34.04 |
jdoliner |
until two
triangle intersect in something that isn't a line |
| 08:35.09 |
jdoliner |
then what do
I do... |
| 08:35.20 |
jdoliner |
oh actually
you answered my question |
| 08:35.56 |
madant |
er.. huh
:P |
| 08:36.13 |
jdoliner |
yeah I think
I see the answer |
| 08:36.54 |
madant |
good
:) |
| 08:37.47 |
jdoliner |
the magic of
teamwork |
| 08:38.42 |
madant |
where are you
right now ? |
| 08:39.55 |
jdoliner |
chicago |
| 08:40.19 |
jdoliner |
you must be
pretty close to the opposite side of the world from me |
| 08:40.56 |
madant |
pretty much .
heh 3:40 there .. as brlcad says good.. a little bit of us dies
everytime we sleep |
| 08:41.01 |
madant |
~sleep |
| 08:41.01 |
ibot |
methinks
sleep is overrated, and a poor substitute for caffeine. |
| 08:45.39 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34792 10/brlcad/trunk/src/libged/cc.c: adding
code to cc command, adds dummy rt_constraint object to the
database |
| 08:47.51 |
CIA-32 |
BRL-CAD:
03Homovulgaris 07http://brlcad.org
* r1500 10/wiki/User:Homovulgaris: /* GSoC 2009 Log */ 19th June
update |
| 08:53.03 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34793 10/brlcad/trunk/misc/Doxyfile: Doxyfile
update |
| 11:48.39 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 12:53.15 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DFC8.dip.t-dialin.net) |
| 13:28.05 |
*** join/#brlcad madant1
(n=cb7baf0f@bz.bzflag.bz) |
| 13:28.47 |
madant1 |
brlcad: in
rt_constraint_internal struct i should use bu_vls for storing the
constraint expression , right ? |
| 15:07.28 |
*** join/#brlcad madant1
(n=cb7baf0f@bz.bzflag.bz) |
| 15:44.51 |
madant1 |
needs more caffeine it seems |
| 16:43.47 |
brlcad |
should
usually use vls in structs in leu of char*'s for
strings |
| 16:45.53 |
madant1 |
brlcad: also,
should rt_constraint_ifree function free up that vls ? |
| 16:47.32 |
brlcad |
yes,
usually |
| 16:49.09 |
madant1 |
ok |
| 16:52.38 |
madant1 |
brlcad: right
now i am just trying out writing an expression as a string and
storing it in the database, but it should be encoded right
? |
| 16:52.54 |
madant1 |
which
functions do i use for encoding the string ? or do i need to write
one ? |
| 17:06.13 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34794 10/brlcad/trunk/ (4 files in 4 dirs):
adding (bu_vls) expression variable to rt_constraint_internal,
testing writing hardcoded data to db using GED_DB_PUT |
| 17:33.13 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 17:42.42 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 19:45.49 |
*** join/#brlcad GordonT
(n=50cab1cc@bz.bzflag.bz) |
| 19:52.48 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 20:03.54 |
*** join/#brlcad andax
(n=andax__@d213-102-40-207.cust.tele2.ch) |
| 20:18.52 |
Ralith |
grr. |
| 20:18.54 |
Ralith |
I keep
getting: |
| 20:18.58 |
Ralith |
svn:
PROPPATCH of
'/svnroot/brlcad/!svn/wrk/f5f0c204-0510-4163-b487-ad75f0469a44/rt%5E3/trunk/src/other/ogre/OgreMain/include/OgreRenderQueueSortingGrouping.h':
SSL negotiation failed: Connection reset by peer (https://brlcad.svn.sourceforge.net) |
| 20:19.35 |
CIA-32 |
BRL-CAD:
03ralith * r34795
10/rt^3/trunk/src/other/ogre/OgreMain/CMakeLists.txt: Added Ogre
SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 20:19.58 |
Ralith |
wtf? |
| 20:20.13 |
Ralith |
that didn't
go through on my end O.o |
| 20:20.30 |
Ralith |
EG
ogre/OgreMain/CMakeLists.txt |
| 20:20.37 |
Ralith |
wonder what
that stands for. |
| 20:22.21 |
Ralith |
graah! |
| 20:22.24 |
Ralith |
I can't
commit anything! |
| 20:30.59 |
Ralith |
christ, how
did mafm pull this off originally :| |
| 20:31.49 |
Ralith |
my aplogies
in advance for the upcoming spam, but there doesn't seem to be any
other way to make commits work. |
| 20:33.11 |
CIA-32 |
BRL-CAD:
03ralith * r34796 10/rt^3/trunk/src/other/ogre/OgreMain/ (include/
obj/ scripts/ src/): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 20:33.45 |
CIA-32 |
BRL-CAD:
03ralith * r34797
10/rt^3/trunk/src/other/ogre/OgreMain/include/GLX/ (.
OgreConfigDialogImp.h OgreErrorDialogImp.h OgreTimerImp.h): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 20:33.55 |
CIA-32 |
BRL-CAD:
03ralith * r34798
10/rt^3/trunk/src/other/ogre/OgreMain/include/OSX/ (.
OgreConfigDialogImp.h OgreErrorDialogImp.h OgreTimerImp.h): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 20:37.39 |
Ralith |
okay, even
just ogre/OgreMain/include/*.h is too big to commit
cleanly. |
| 20:37.39 |
Ralith |
jesus. |
| 20:38.07 |
Ralith |
anyone have
any suggestions, short of committing progressively smaller
sub-blocks until it works? |
| 20:47.10 |
Ralith |
YES!
:D |
| 20:47.17 |
CIA-32 |
BRL-CAD:
03ralith * r34799 10/rt^3/trunk/src/other/ogre/OgreMain/include/
(242 files in 4 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 20:47.57 |
CIA-32 |
BRL-CAD:
03ralith * r34800 10/rt^3/trunk/src/other/ogre/OgreMain/include/ (7
files in 3 dirs): Added Ogre SVN (r8739, latest as of this commit)
due to serious bugs in features needed by g3d in Ogre stable.
Partial commit. |
| 20:52.41 |
louipc |
Ralith: ah
how come you have to commit them bits at a time? bad
connection? |
| 20:52.56 |
Ralith |
louipc: my
connection is fine, the sourceforge servers aren't. |
| 20:54.31 |
Ralith |
the size of a
commit that they accept seems to be completely random |
| 20:54.45 |
Ralith |
and generally
very small |
| 20:54.53 |
louipc |
hmm |
| 20:56.32 |
Ralith |
gives up and breaks it into small blocks, only to have
sourceforge reject a single file commit |
| 20:58.09 |
CIA-32 |
BRL-CAD:
03ralith * r34801 10/rt^3/trunk/src/other/ogre/OgreMain/src/ (32
files): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 20:59.15 |
louipc |
maybe it's
just a temporary problem they're having right now. You could ask
for tech support I guess heh |
| 20:59.26 |
Ralith |
it's been
like this since yesterday |
| 20:59.32 |
Ralith |
commits D through P |
| 20:59.46 |
Ralith |
and
starseeker mentioned he'd had similar issues, iirc |
| 21:01.05 |
CIA-32 |
BRL-CAD:
03ralith * r34802 10/rt^3/trunk/src/other/ogre/OgreMain/src/ (89
files): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 21:01.22 |
Ralith |
now Q through
Z. |
| 21:04.19 |
CIA-32 |
BRL-CAD:
03ralith * r34803 10/rt^3/trunk/src/other/ogre/OgreMain/src/ (70
files): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 21:04.38 |
Ralith |
now for
whatever's left. |
| 21:05.48 |
CIA-32 |
BRL-CAD:
03ralith * r34804 10/rt^3/trunk/src/other/ogre/OgreMain/src/ (32
files in 7 dirs): Added Ogre SVN (r8739, latest as of this commit)
due to serious bugs in features needed by g3d in Ogre stable.
Partial commit. |
| 21:06.36 |
CIA-32 |
BRL-CAD:
03ralith * r34805 10/rt^3/trunk/src/other/ogre/OgreMain/obj/
(Debug/ Debug/.keepme Release/ Release/.keepme): Added Ogre SVN
(r8739, latest as of this commit) due to serious bugs in features
needed by g3d in Ogre stable. Partial commit. |
| 21:06.46 |
CIA-32 |
BRL-CAD:
03ralith * r34806 10/rt^3/trunk/src/other/ogre/OgreMain/scripts/
(OgreMain.cbp OgreMain_linux.cbp OgreMain_stlp.cbp): Added Ogre SVN
(r8739, latest as of this commit) due to serious bugs in features
needed by g3d in Ogre stable. Partial commit. |
| 21:08.47 |
CIA-32 |
BRL-CAD:
03ralith * r34807 10/rt^3/trunk/src/other/ogre/Other/
(VC7_AppWizard.msi add_crlf.py rem_endspc.py tab2spc.py): Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 21:18.14 |
CIA-32 |
BRL-CAD:
03ralith * r34808 10/rt^3/trunk/src/other/ogre/PlugIns/ (228 files
in 34 dirs): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 21:25.33 |
CIA-32 |
BRL-CAD:
03ralith * r34809
10/rt^3/trunk/src/other/ogre/RenderSystems/CMakeLists.txt: Added
Ogre SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 21:28.48 |
CIA-32 |
BRL-CAD:
03ralith * r34810
10/rt^3/trunk/src/other/ogre/RenderSystems/Direct3D10/ (63 files in
4 dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 21:29.34 |
CIA-32 |
BRL-CAD:
03ralith * r34811
10/rt^3/trunk/src/other/ogre/RenderSystems/Direct3D9/ (59 files in
4 dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 21:41.40 |
CIA-32 |
BRL-CAD:
03ralith * r34812 10/rt^3/trunk/src/other/ogre/RenderSystems/GL/
(203 files in 21 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 21:43.39 |
CIA-32 |
BRL-CAD:
03ralith * r34813 10/rt^3/trunk/src/other/ogre/RenderSystems/GLES/
(82 files in 12 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 21:46.50 |
CIA-32 |
BRL-CAD:
03ralith * r34814 10/rt^3/trunk/src/other/ogre/SDK/ (42 files in 4
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 21:46.56 |
Ralith |
relaxes. |
| 21:53.53 |
``Erik |
o.O |
| 21:58.27 |
Ralith |
``Erik: I've
discovered that the probability of a commit going through is
something like inversely proportional to the square of its
size. |
| 21:58.55 |
louipc |
does it mean
I can unignore cia? |
| 21:58.58 |
louipc |
:D |
| 21:59.01 |
Ralith |
hehe |
| 21:59.02 |
Ralith |
not quite
yet |
| 21:59.15 |
Ralith |
I was just
relaxing because it was going smoothly for a little
while. |
| 21:59.18 |
louipc |
hehe
ok |
| 21:59.20 |
louipc |
nice |
| 21:59.32 |
Ralith |
Samples seems
to be going badly though, and if I can't get it to go in all at
once there'll probably be some more serious spam |
| 22:00.27 |
brlcad |
commit spam
is good |
| 22:01.11 |
Ralith |
brlcad: not
if it's all basically one commit. |
| 22:01.27 |
brlcad |
Ralith: more
than likely it's some intermediate router on your end resetting the
connection |
| 22:01.47 |
Ralith |
probably, but
it's nothing local enough for me to be able to address
it. |
| 22:01.54 |
brlcad |
have similar
issues from the arl network but not outside (ever to
date) |
| 22:02.28 |
Ralith |
the real
issue I guess is just how much of my time this single simple thing
is taking. |
| 22:02.46 |
Ralith |
tries sending in samples A through K |
| 22:03.01 |
Ralith |
(zsh's regex
wildcards are great for this) |
| 22:04.21 |
brlcad |
true, what's
the error when it fails? |
| 22:04.44 |
brlcad |
svn: Commit
failed (details follow): |
| 22:04.47 |
brlcad |
svn: PROPFIND
of '...' ? |
| 22:04.55 |
brlcad |
could not
connect to server |
| 22:05.03 |
Ralith |
no, it's
connection reset by peer |
| 22:05.09 |
Ralith |
and the
command (PROPFIND or w/e) varies |
| 22:06.56 |
Ralith |
I'll paste an
example next time it happens |
| 22:07.48 |
brlcad |
yeah, that
sounds like the same problem -- a router requests a reset, which
confuses svn (even though is valid tcp behavior) |
| 22:07.54 |
brlcad |
what version
of svn are you using? |
| 22:08.12 |
brlcad |
could try
updating to a newer release |
| 22:10.22 |
Ralith |
1.6.1
(r37116) |
| 22:10.44 |
CIA-32 |
BRL-CAD:
03ralith * r34815 10/rt^3/trunk/src/other/ogre/Samples/ (213 files
in 81 dirs): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 22:10.48 |
Ralith |
that was
A-K. |
| 22:12.29 |
brlcad |
hm, that's
pretty new .. what about openssl? |
| 22:14.35 |
Ralith |
0.9.8k 25 Mar
2009 |
| 22:29.21 |
Ralith |
watches the k-z commit lengthen
apprehensively. |
| 23:13.08 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EBE1.dip.t-dialin.net) |
| 00:31.58 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:09.05 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 01:59.10 |
CIA-32 |
BRL-CAD:
03indianlarry * r34816 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): added trim distance return to
isTrimmed() for determining when hit crack |
| 02:28.28 |
CIA-32 |
BRL-CAD:
03ralith * r34817 10/rt^3/trunk/src/other/ogre/Samples/Media/ (428
files in 21 dirs): Added Ogre SVN (r8739, latest as of this commit)
due to serious bugs in features needed by g3d in Ogre stable.
Partial commit. |
| 03:10.49 |
CIA-32 |
BRL-CAD:
03ralith * r34818 10/rt^3/trunk/src/other/ogre/Samples/Lighting/
(21 files in 11 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 03:11.56 |
CIA-32 |
BRL-CAD:
03ralith * r34819 10/rt^3/trunk/src/other/ogre/Samples/ (77 files
in 37 dirs): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 03:14.55 |
CIA-32 |
BRL-CAD:
03ralith * r34820 10/rt^3/trunk/src/other/ogre/Samples/ (95 files
in 49 dirs): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 03:16.12 |
CIA-32 |
BRL-CAD:
03ralith * r34821 10/rt^3/trunk/src/other/ogre/Samples/ (86 files
in 41 dirs): Added Ogre SVN (r8739, latest as of this commit) due
to serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 03:16.35 |
CIA-32 |
BRL-CAD:
03ralith * r34822 10/rt^3/trunk/src/other/ogre/Scripts/ (.keepme
m4/ m4/cppunit.m4 m4/sdl.m4 null.sh remove_debug.sh): Added Ogre
SVN (r8739, latest as of this commit) due to serious bugs in
features needed by g3d in Ogre stable. Partial commit. |
| 03:20.45 |
CIA-32 |
BRL-CAD:
03ralith * r34823 10/rt^3/trunk/src/other/ogre/Tests/ (97 files in
29 dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 03:58.51 |
Ralith |
wonders just how long a svn commit can
take |
| 04:12.46 |
Ralith |
okay, it's
locked up now. |
| 04:12.57 |
louipc |
wee! |
| 04:13.19 |
Ralith |
kill -9s and tries again |
| 04:13.34 |
louipc |
I feel your
pain man |
| 04:14.23 |
louipc |
maybe I can
help. let me know if there's anything |
| 04:14.50 |
Ralith |
thanks, I'll
do that |
| 04:15.00 |
Ralith |
pretty sure
it's just a matter of slogging through the heirarchy
though. |
| 04:15.25 |
Ralith |
(and stomping
the occasional bug) |
| 04:31.47 |
Ralith |
another
lockup >:| |
| 05:15.32 |
*** join/#brlcad madant
(n=cb7baf0f@bz.bzflag.bz) |
| 06:44.09 |
*** join/#brlcad stevegt_1
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 06:45.52 |
stevegt_1 |
wonders if there's any clean way to generate 2-D toolpaths to
laser cut panels from a BRL-CAD model |
| 06:46.25 |
stevegt_1 |
wonders if anyone else is awake right now |
| 06:46.46 |
stevegt_1 |
probably have
to poke in here tomorrow and ask again |
| 06:47.52 |
Ralith |
I'm
here |
| 06:47.56 |
Ralith |
it's
theoretically possible |
| 06:48.02 |
Ralith |
jonored wrote
the code to do most of the work |
| 06:48.17 |
Ralith |
but he hasn't
been around for a while and never published it |
| 06:48.50 |
Ralith |
the raytracer
gives you enough info to do it |
| 06:49.24 |
stevegt_1 |
I just spend
the weekend digging through g-xxx.c et al -- looks doable, but I'd
hate to make a fool of myself if it's already been done |
| 06:49.35 |
Ralith |
it
hasn't. |
| 06:49.41 |
Ralith |
it's
nontrivial though |
| 06:50.11 |
Ralith |
let us know
if you get it working |
| 06:50.20 |
Ralith |
it'd be a
very useful for lots of things |
| 06:50.29 |
stevegt_1 |
maybe i'm
thinking of it all wrong -- I'm seeing it as a 2-D dxf generation
problem... you think I need to be looking at the raytracing code
instead? |
| 06:51.04 |
Ralith |
well if you
want to just convert a sketch to a dxf that's not hard |
| 06:51.12 |
Ralith |
or at least I
imagine it's not, I don't know the relevant code |
| 06:51.29 |
Ralith |
but going
from a 3D model to 2D toolpaths is significantly more
involved. |
| 06:53.30 |
stevegt_1 |
well, what
i'd want to be able to do is put together a model, mark the
material attributes for the parts that are going to be laser-cut,
then, in something like 'g-epilog', filter out just those parts,
and generate a dxf or epilog (PCL) file for each one |
| 06:54.22 |
stevegt_1 |
i'm not sure
that would solve the general g-code generation problem, except for
driving CNC routers and lasers |
| 06:55.06 |
Ralith |
that's most
of it |
| 06:55.15 |
Ralith |
and once
you've solved that, any further uses could easily build on your
work |
| 06:55.26 |
stevegt_1 |
huh |
| 06:58.14 |
stevegt_1 |
do you know
if there's already a piece of code buried somewhere in the tree
that i could call or copy which would help me rotate a part so it's
normal to a reference plane, then get the resulting 2-D vertices?
I don't know if I'm making any sense or not... for instance, I
started looking at the "flatten" stuff in the NMG libs, not even
sure if that's related |
| 06:59.06 |
stevegt_1 |
s/rotate a
part so it's normal/rotate a part so the largest face is normal/
|
| 06:59.09 |
stevegt_1 |
or something
like that |
| 07:01.07 |
stevegt_1 |
i mean, if we
first assume that the shape is cut from a flat panel (extruded from
a sketch, probably, but not always), then that means that there
will always be exactly two flat faces which are identical, and we
can just pick one |
| 07:01.24 |
Ralith |
stevegt_1:
...BRL-CAD isn't mesh-based. |
| 07:01.25 |
Ralith |
it's
CSG. |
| 07:01.36 |
Ralith |
there's no
such thing as "the corresponding vertices" |
| 07:01.47 |
stevegt_1 |
right, which
means i'm probably confusing myself by looking at the g-xxx
code |
| 07:01.53 |
Ralith |
everything is
in terms of volumes |
| 07:02.02 |
Ralith |
extracting 2d
toolpaths is nontrivial. |
| 07:02.19 |
stevegt_1 |
which is why
you're mentioning the raytracer? |
| 07:02.48 |
Ralith |
that's how
you work with the evaluated form of a BRL-CAD model. |
| 07:02.54 |
Ralith |
through
raytracing. |
| 07:06.32 |
stevegt_1 |
looking at how the g-xxx triangulation code does it's
job |
| 07:06.32 |
Ralith |
you don't
want to do tesselation. |
| 07:06.32 |
Ralith |
that's a
waste of information |
| 07:06.32 |
Ralith |
considering
that gcode can do true arcs |
| 07:06.55 |
stevegt_1 |
that's what i
was afraid you'd say |
| 07:07.06 |
stevegt_1 |
or glad,
actually |
| 07:07.15 |
stevegt_1 |
'cause i was
ignoring it so far ;-) |
| 07:07.21 |
stevegt_1 |
the
tesellation code, i mean |
| 07:08.02 |
stevegt_1 |
was thinking
i didn't need it, but now i'm wondering how it does its job --
going to look |
| 07:13.55 |
stevegt_1 |
suddenly recalls that it's g-xxx_facets which does
tesselation, which he doesn't need, while g-xxx does not do
tesselation anyway -- it just iterates through the results of
rt_dirbuild |
| 07:14.31 |
stevegt_1 |
and printf's
what it finds |
| 07:17.15 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 07:21.59 |
stevegt_1 |
looking at
g2asc as well now... i'm confused -- if I have the record in hand
that i got from the db, then i have its parameters in
record.s.s_values -- why do i need to raytrace? to account for
booleans? |
| 07:22.13 |
stevegt_1 |
must be
that |
| 07:25.04 |
stevegt_1 |
i'm going to
take a guess and say that the reason why 2-D toolpath generation
has been considered to be a hard problem is that it's been
generally accepted that we needed to invoke the raytracer to
execute boolean operations first |
| 07:25.38 |
Ralith |
it's not
HARD |
| 07:25.41 |
Ralith |
just hasn't
been done yet |
| 07:25.58 |
Ralith |
there's lots
of other stuff to do. |
| 07:26.11 |
stevegt_1 |
okay,
deferred ;-) |
| 07:27.24 |
Ralith |
and yeah, the
only way to evaluate booleans is to raytrace |
| 07:27.41 |
Ralith |
only data you
can get without raytracing is the primitives |
| 07:31.11 |
stevegt_1 |
i'm thinking
of gershenfeld's cad.py -- he used python's numpy 3-D matrix
operations to do the booleans in very little code; part of my brain
must have been assuming i'd do that instead of calling the brl-cad
raytracer |
| 07:31.20 |
Ralith |
... |
| 07:31.58 |
Ralith |
the
raytracer's ability to evaluate booleans is one of BRL-CAD's major
high points |
| 07:32.00 |
stevegt_1 |
yeah, whacky
-- i should look at the raytracer first |
| 07:32.08 |
Ralith |
you'd
basically be using BRL-CAD for nothing but its
fileformat |
| 07:32.19 |
Ralith |
doing
booleans well is hard. |
| 07:32.28 |
Ralith |
the raytracer
will give you just about perfect precision. |
| 07:32.32 |
Ralith |
and reliably,
too. |
| 07:34.18 |
stevegt_1 |
Any
suggestion where I should start to get my head around it? I've
been going back and forth through the PDF tutorials, including the
Application_Develeopment slideshow -- am I missing some swath of
developer docs somewhere else? |
| 07:35.02 |
Ralith |
what kind of
docs do you want |
| 07:36.13 |
stevegt_1 |
I probably
don't know enough yet to ask. ;-) I'll have to go through that
slideshow again. I was ignoring the raytracing before, was just
llooking at the DB access bits. |
| 07:44.14 |
stevegt_1 |
hmm.
src/rt/viewarea.c looks like a real good place to start as
well |
| 07:45.43 |
stevegt_1 |
actually all
the view*.c stuff |
| 07:48.50 |
stevegt_1 |
expects to sit down someplace quiet tomorrow and grok view*.c
-- "only" 11,568 lines ;-) |
| 07:49.16 |
stevegt_1 |
Ralith: thank
you, very much -- I think you got me on the right track |
| 07:49.20 |
Ralith |
cool |
| 08:11.54 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 08:11.54 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 09:09.48 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C62F.dip.t-dialin.net) |
| 09:50.56 |
*** join/#brlcad CIA-32
(n=CIA@208.69.182.149) |
| 10:55.08 |
CIA-32 |
BRL-CAD:
03ralith * r34824 10/rt^3/trunk/src/other/ogre/Tools/3dsmaxExport/
(116 files in 26 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 10:55.17 |
CIA-32 |
BRL-CAD:
03ralith * r34825
10/rt^3/trunk/src/other/ogre/Tools/BitmapFontBuilderTool/ (.
main.cpp): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 10:56.03 |
CIA-32 |
BRL-CAD:
03ralith * r34826 10/rt^3/trunk/src/other/ogre/Tools/BlenderExport/
(24 files in 4 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 10:56.07 |
CIA-32 |
BRL-CAD:
03ralith * r34827
10/rt^3/trunk/src/other/ogre/Tools/CMakeLists.txt: Added Ogre SVN
(r8739, latest as of this commit) due to serious bugs in features
needed by g3d in Ogre stable. Partial commit. |
| 10:56.24 |
CIA-32 |
BRL-CAD:
03ralith * r34828
10/rt^3/trunk/src/other/ogre/Tools/CommandLineTools_Readme.txt:
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 10:57.25 |
CIA-32 |
BRL-CAD:
03ralith * r34829 10/rt^3/trunk/src/other/ogre/Tools/Common/ (11
files in 5 dirs): Added Ogre SVN (r8739, latest as of this commit)
due to serious bugs in features needed by g3d in Ogre stable.
Partial commit. |
| 10:57.52 |
CIA-32 |
BRL-CAD:
03ralith * r34830
10/rt^3/trunk/src/other/ogre/Tools/LightwaveConverter/ (28 files in
4 dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 11:36.12 |
CIA-32 |
BRL-CAD:
03ralith * r34831
10/rt^3/trunk/src/other/ogre/Tools/MaterialEditor/ (178 files in 18
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 11:37.32 |
CIA-32 |
BRL-CAD:
03ralith * r34832 10/rt^3/trunk/src/other/ogre/Tools/MayaExport/
(35 files in 6 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 11:37.41 |
CIA-32 |
BRL-CAD:
03ralith * r34833 10/rt^3/trunk/src/other/ogre/Tools/MeshUpgrader/
(7 files in 3 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 11:38.08 |
CIA-32 |
BRL-CAD:
03ralith * r34834
10/rt^3/trunk/src/other/ogre/Tools/MilkshapeExport/ (28 files in 9
dirs): Added Ogre SVN (r8739, latest as of this commit) due to
serious bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 11:38.32 |
CIA-32 |
BRL-CAD:
03ralith * r34835 10/rt^3/trunk/src/other/ogre/Tools/VRMLConverter/
(26 files in 7 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 11:38.36 |
*** join/#brlcad louipc
(n=louipc@69-196-134-147.dsl.teksavvy.com) |
| 11:38.44 |
CIA-32 |
BRL-CAD:
03ralith * r34836
10/rt^3/trunk/src/other/ogre/Tools/Wings3DExporter/ (11 files):
Added Ogre SVN (r8739, latest as of this commit) due to serious
bugs in features needed by g3d in Ogre stable. Partial
commit. |
| 11:41.03 |
CIA-32 |
BRL-CAD:
03ralith * r34837 10/rt^3/trunk/src/other/ogre/Tools/XMLConverter/
(22 files in 5 dirs): Added Ogre SVN (r8739, latest as of this
commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 11:42.24 |
CIA-32 |
BRL-CAD:
03ralith * r34838 10/rt^3/trunk/src/other/ogre/Tools/XSIExport/ (32
files in 6 dirs): Added Ogre SVN (r8739, latest as of this commit)
due to serious bugs in features needed by g3d in Ogre stable.
Partial commit. |
| 11:42.34 |
CIA-32 |
BRL-CAD:
03ralith * r34839
10/rt^3/trunk/src/other/ogre/Tools/dotXSIConverter/ (. include/
include/Exporter.h src/ src/Exporter.cpp): Added Ogre SVN (r8739,
latest as of this commit) due to serious bugs in features needed by
g3d in Ogre stable. Partial commit. |
| 11:42.44 |
CIA-32 |
BRL-CAD:
03ralith * r34840 10/rt^3/trunk/src/other/ogre/Tools/rcapsdump/ (.
scripts/ src/ src/main.cpp): Added Ogre SVN (r8739, latest as of
this commit) due to serious bugs in features needed by g3d in Ogre
stable. Partial commit. |
| 11:42.57 |
Ralith |
:D |
| 11:42.58 |
Ralith |
done! |
| 11:45.12 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1501 10/wiki/User:Ralith: Log for 2009-06-21 |
| 13:07.25 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 13:19.33 |
*** join/#brlcad mafm
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 13:36.28 |
brlcad |
Ralith: hehe,
well congrats on that .. ouch |
| 13:36.57 |
brlcad |
next time you
have something that big, maybe could tar it up for one of the other
devs to commit :) |
| 13:37.24 |
brlcad |
couldn't hurt
to put in an sf.net ticket if only to have them check it out too
just to make sure it's not something on their end |
| 13:38.09 |
brlcad |
stevegt_1:
there is an overview on the website that explains the rt view*.c
interface |
| 13:39.19 |
brlcad |
http://brlcad.org/w/images/3/3d/Application_Development.pdf
(found under http://brlcad.org/wiki/Developing_applications
) |
| 13:39.48 |
brlcad |
stevegt_1:
basically it amounts to about a half-dozen callbacks that you
define and register |
| 13:40.45 |
brlcad |
ahh, reading
more of the backlog, I see you found that pdf already |
| 13:42.38 |
brlcad |
so probably
just asking questions in here is your best bet if you don't quickly
make sense of the code -- each of those view*.c files is for a
separate application like rt, rtarea, rtweight, rtcheck, etc
.. |
| 13:43.01 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C62F.dip.t-dialin.net) |
| 13:43.55 |
brlcad |
those
half-dozen or so callbacks are all that is needed to define the
entire application as the rt user interface is exactly the same
across all of them for the front-end (argument processing, shooting
a grid of primary rays, aggregating results, running in parallel,
etc) |
| 13:56.28 |
brlcad |
case local
folks don't see the e-mail or if others are close by and want to
join up, we're looking to have dinner at Tidewater tonight in Havre
de Grace, Maryland around 6pm |
| 13:56.48 |
starseeker |
ah, thanks
:-) |
| 13:56.54 |
brlcad |
GMTA |
| 13:57.18 |
brlcad |
~seen
madant |
| 13:57.21 |
ibot |
madant
<n=cb7baf0f@bz.bzflag.bz> was last seen on IRC in channel
#brlcad, 1d 5h 16m 20s ago, saying: '~sleep'. |
| 14:30.56 |
CIA-32 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r1502 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: /* Application
Domain */ |
| 14:31.48 |
CIA-32 |
BRL-CAD:
03Tbrowder 07http://brlcad.org *
r1503 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: /* The interface
should be self-contained */ |
| 15:34.08 |
CIA-32 |
BRL-CAD:
03bob1961 * r34841 10/brlcad/trunk/src/libged/expand.c: Modify
ged_expand to return only database entries that match the
pattern(s). |
| 15:37.55 |
brlcad |
woot! |
| 15:38.05 |
brlcad |
go go gadget
tom |
| 15:42.29 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 15:43.36 |
jdoliner |
hey guys can
someone give me a hand with ON_SimpleArrays? |
| 15:44.00 |
jdoliner |
particularly
for somereason when I try to use them I get compile errors that
there's no match found for [] operators |
| 15:44.49 |
jdoliner |
ON_SimpleArray<ON_Line>
segments; |
| 15:45.48 |
jdoliner |
and
then |
| 15:45.48 |
jdoliner |
ON_Line
segment = segments[j]; |
| 15:45.52 |
jdoliner |
creates an
error |
| 16:40.50 |
CIA-32 |
BRL-CAD:
03jdoliner * r34842 10/brlcad/trunk/src/proc-db/ (brepintersect.cpp
brepintersect.h): Added function TriangleMeshIntersect which
intersects a triangle with a mesh and returns as a polyline their
intersection curve |
| 17:01.40 |
brlcad |
jdoliner: it
returns a reference |
| 17:02.01 |
brlcad |
type have a
type error |
| 17:03.35 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 17:03.51 |
jdoliner |
so segments
is of type ON_SimpleArray<ON_Line>&? |
| 17:04.04 |
jdoliner |
then how to I
get at its contents? |
| 17:04.37 |
brlcad |
no, see the
header, it returns a T& |
| 17:04.46 |
brlcad |
so needs to
be an ON_Line& |
| 17:05.15 |
brlcad |
assuming the
type problem isn't on the j |
| 17:05.16 |
jdoliner |
okay that
makes sense then |
| 17:06.46 |
jdoliner |
k cool I get
it now |
| 17:26.32 |
CIA-32 |
BRL-CAD:
03jdoliner * r34843 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
Modified TriangleMeshIntersect to be MeshMeshIntersect, now just
directly intersects two meshes and returns an array of Polylines
for their intersection |
| 17:49.06 |
CIA-32 |
BRL-CAD:
03bob1961 * r34844 10/brlcad/trunk/src/tclscripts/archer/ (33 files
in 4 dirs): Added the first installment of the undo functionality
(i.e. only handling mods to existing geometry) to Archer. More to
follow for create, destroy and rename. |
| 17:50.00 |
brlcad |
wonders how
much of the hackery that involved.. |
| 17:57.35 |
*** join/#brlcad _sushi_
(n=_sushi_@80-219-42-101.dclient.hispeed.ch) |
| 18:23.30 |
CIA-32 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1504 10/wiki/User:Jdoliner: |
| 18:53.53 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:45.15 |
brlcad |
jdoliner:
curious what your current goal/milestone is |
| 19:46.00 |
jdoliner |
my current
goal is to finish mesh on mesh intersections |
| 19:46.13 |
brlcad |
ON_Mesh
objects are all polygonal, yes? |
| 19:46.18 |
jdoliner |
yes |
| 19:46.52 |
brlcad |
they are all
untrimmed? |
| 19:47.08 |
brlcad |
or do they
allow/require trimming evaluation? |
| 19:47.16 |
jdoliner |
I believe
that they are untrimmed |
| 19:47.30 |
jdoliner |
at least
nowhere in the definition do I say any mention of
trimming |
| 19:47.38 |
brlcad |
okay cool --
there is a problem with one of your intersection routines if you
allow trims |
| 19:48.34 |
jdoliner |
I see,
actually I guess this is a good time for me to learn some things
about trims |
| 19:48.50 |
jdoliner |
so meshes
don't have trims which works well |
| 19:49.18 |
jdoliner |
so the way I
see it, is that I do an intersection |
| 19:49.20 |
brlcad |
one thing
that will be very interesting to test then once you have mesh on
mesh intersections working is having an nmg->ON_Mesh conversion
to perform the booleans using your routines instead of the
(extensively complex) NMG library |
| 19:50.07 |
jdoliner |
yeah
definitely |
| 19:50.26 |
jdoliner |
so then after
the intersection I get back the polyline |
| 19:51.09 |
jdoliner |
and then I
basically need to just make a new mesh where I trim off the parts
outside of the polyline |
| 19:52.41 |
jdoliner |
but when I do
stuff with nurbs, which support trimming curves I can just put them
in as trimming curves |
| 19:52.57 |
brlcad |
right |
| 19:52.58 |
jdoliner |
and then my
intersection algorithms need to take into account the trimming
curves |
| 19:53.13 |
brlcad |
plus you'll
have to deal with more generalized ON_Brep objects, not just
ON_Mesh objects |
| 19:53.16 |
brlcad |
in order to
get nurbs |
| 19:53.20 |
jdoliner |
yes |
| 19:53.36 |
jdoliner |
what does ON
do with the trimming curves |
| 19:53.45 |
jdoliner |
are they just
used in rendering |
| 19:54.06 |
brlcad |
a good test
case might be to take the cube that is produced by breplicator or
brep_test in src/proc-db, make a copy of it, translated slightly so
it overlaps corners, then evaluate a boolean |
| 19:54.48 |
brlcad |
the trimming
curves are part of the topological structure, they define the
actual edge to a given surface |
| 19:54.49 |
jdoliner |
or is there
some function which actually sort of freezes the nurbs in their
trimmed form |
| 19:55.04 |
brlcad |
there is not
(that I"m aware of) |
| 19:55.13 |
jdoliner |
k I'll poke
around |
| 19:55.36 |
brlcad |
it would be
useful to have a routine that took a given ON_Brep and evaluated
all trims to give a resulting object that is trim-free |
| 19:55.44 |
brlcad |
or at least
only outer trims |
| 19:56.24 |
brlcad |
so there is a
1-1 relationship with trims to edges, each edge corresponding to a
curve you can test against |
| 19:56.59 |
jdoliner |
okay, that
makes sense |
| 19:58.19 |
brlcad |
jdoliner:
also, if you've not read it yet, this may be of some assistance
organizationally |
| 19:58.23 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/TODO.BREP |
| 19:58.40 |
brlcad |
has all of
the various pairwise evaluation possibilities |
| 20:01.42 |
jdoliner |
I see, are
all those things unimplemented? |
| 20:03.36 |
brlcad |
oh no, much
is, much isn't .. some IS implemented (particularly for polygonal
types), but for different (non-opennurbs) data types |
| 20:04.24 |
brlcad |
some is very
robust to numerical issues, some isn't -- it's a very large body of
code that gets involved when you start talking about existing brep
work |
| 20:08.48 |
brlcad |
code of
relevance is src/librt/primitives/nmg (extensive polygonal mesh CSG
library, radial-edge data structure),
src/librt/primitives/bspline (old nurbs implementation, lacking
support for trimmed nurbs surfaces), src/librt/opennurbs_ext.cpp
and src/librt/primitives/brep (active new nurbs
development) |
| 20:09.37 |
brlcad |
suggest at
least taking a look at the nmg routines as they strongly relate to
what you're doing with ON_Mesh |
| 20:13.51 |
jdoliner |
yes will do
immediately |
| 20:17.14 |
brlcad |
nmg_evaluate_boolean() is particularly
relevant, starting in
src/librt/primitives/nmg/nmg_eval.c |
| 20:18.38 |
brlcad |
as you are
going to end up with some sort of similar routine hopefully to
evaluate two ON_Brep objects |
| 20:26.22 |
CIA-32 |
BRL-CAD:
03indianlarry * r34845 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): added NEAR_MISS points to
hitlist, hitlist logic being worked |
| 21:09.41 |
*** join/#brlcad stevegt_1
(n=stevegt@cislunar.TerraLuna.Org) |
| 21:22.21 |
CIA-32 |
BRL-CAD:
03starseeker * r34846
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 21:22.27 |
CIA-32 |
BRL-CAD: Try
to add a printout message that will detail the type of odd hit
count |
| 21:22.34 |
CIA-32 |
BRL-CAD:
behavior being observed - for reasons not quite clear, the
reporting isn't doing |
| 21:22.38 |
CIA-32 |
BRL-CAD: what
I expected it to - it's not reporting close points at all and
only |
| 21:22.44 |
CIA-32 |
BRL-CAD:
occasionally reporting entering/leaving status. |
| 21:36.02 |
starseeker |
indianlarry:
am I doing something wrong with printing out the hit
info? |
| 21:39.58 |
CIA-32 |
BRL-CAD:
03irpguardian * r34847 10/brlcad/trunk/TODO: Added human geometry
generator item |
| 21:56.23 |
*** join/#brlcad madant
(n=cb7baf0f@bz.bzflag.bz) |
| 22:07.25 |
madant |
what is the
bn or bu random number generating function which i could use as an
id |
| 22:23.14 |
Ralith |
brlcad:
thanksâhopefully it won't come up again. |
| 22:36.28 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14C62F.dip.t-dialin.net) |
| 22:43.22 |
*** join/#brlcad mafm_
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 23:05.48 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 23:06.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 23:09.38 |
*** join/#brlcad mafm_
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 00:43.35 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 01:01.58 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 01:02.38 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:46.50 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 01:54.17 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 01:57.36 |
CIA-32 |
BRL-CAD:
03indianlarry * r34848
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: added new
variables to brep_hit copy constructor |
| 02:24.51 |
*** join/#brlcad stevegt_1
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 03:46.55 |
stevegt_1 |
~seen
brlcad |
| 03:46.57 |
ibot |
brlcad is
currently on #bzflag (15d 13h 6m 36s) #brlcad (15d 13h 6m 36s). Has
said a total of 448 messages. Is idling for 7h 9m 47s, last said:
'cygal: I'd abort -- it shouldn't take that long'. |
| 03:47.09 |
stevegt_1 |
~ralith |
| 03:47.14 |
stevegt_1 |
~seen
ralith |
| 03:47.15 |
ibot |
ralith is
currently on #brlcad (1d 7h 54m 27s). Has said a total of 82
messages. Is idling for 5h 24m 1s, last said: 'brlcad:
thanksâhopefully it won't come up again.'. |
| 03:47.15 |
Ralith |
sup |
| 03:47.21 |
stevegt_1 |
whup --
hi |
| 03:48.37 |
stevegt_1 |
ralith: still
looking through src/rt/* -- i'm trying to figure out how to get a
vector toolpath during or after processing ray hits... |
| 03:49.12 |
stevegt_1 |
raster is
obvious, vector has me stumped so far |
| 03:50.44 |
Ralith |
stevegt_1:
what do you mean by raster and vector? |
| 03:50.55 |
Ralith |
those terms
don't really apply. |
| 03:51.24 |
stevegt_1 |
raster ==
e.g. .bw, .pix, .jpg etc. |
| 03:51.31 |
Ralith |
those aren't
toolpaths |
| 03:51.32 |
Ralith |
those are
images |
| 03:52.04 |
stevegt_1 |
vector ==
primitive edges |
| 03:52.12 |
Ralith |
primitive
edges? |
| 03:52.15 |
Ralith |
what do you
mean by that? |
| 03:52.43 |
stevegt_1 |
hm |
| 03:52.45 |
louipc |
~seen
louipc |
| 03:52.46 |
ibot |
louipc is
currently on #brlcad (2h 5m 56s). Has said a total of 1 messages.
Is idling for 1s, last said: '~seen louipc'. |
| 03:52.53 |
louipc |
laffs |
| 03:53.33 |
stevegt_1 |
vector as in
svg, dxf |
| 03:53.52 |
stevegt_1 |
g-code, laser
etc. need vectors |
| 03:56.08 |
Ralith |
stevegt_1:
what do you mean by 'vectors'? |
| 03:56.31 |
Ralith |
rt will quite
happily give you precise coordinates. |
| 03:57.13 |
stevegt_1 |
a vectorized
shape description -- like a sketch |
| 03:57.40 |
stevegt_1 |
or an
arb? |
| 03:57.47 |
Ralith |
that's a
circular definition... |
| 03:58.00 |
stevegt_1 |
im trying
here ;-) |
| 03:58.17 |
stevegt_1 |
okay, let's
look at it this way: |
| 03:58.19 |
Ralith |
perhaps you
mean you want to extract arcs? |
| 03:58.32 |
stevegt_1 |
ahh -- yes,
arcs |
| 03:58.34 |
Ralith |
all g-code
can represent is lines and arcs. |
| 03:58.38 |
stevegt_1 |
right |
| 03:59.09 |
Ralith |
that's
nontrivial, because lines and arcs cannot exactly represent many
possible region slices. |
| 04:00.19 |
stevegt_1 |
for a laser
or CNC router, we need exactly one slice, aligned with the plane of
the part we're cutting out |
| 04:00.30 |
Ralith |
you can use
arcs to more closely approximate curves than you could with lines,
but it's still an approximation unless you get lucky and the curve
happens to be precisely circular. |
| 04:00.59 |
Ralith |
the level of
the approximation is up to you. |
| 04:01.20 |
Ralith |
the raytracer
provides sufficient information to perform this approximation;
jonored implemented it, but I couldn't tell you how it's
done. |
| 04:01.28 |
stevegt_1 |
some sort of
successive approximation? |
| 04:01.42 |
stevegt_1 |
that's the
only thing i've been able to think of so far |
| 04:03.19 |
stevegt_1 |
googles for clues about what jonored was
doing |
| 04:04.54 |
Ralith |
~seen
jonored |
| 04:07.27 |
ibot |
jonored
<n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net> was last
seen on IRC in channel #brlcad, 63d 8h 33m 20s ago, saying:
'...er... wrong project. the brlcad database, not the reprap...
wrong project I want to work on.'. |
| 04:07.50 |
stevegt_1 |
heh |
| 04:16.04 |
Ralith |
that took a
while |
| 04:20.57 |
stevegt_1 |
i'm getting a
creeping feeling that the most direct route to what i want might be
to generate the shapes further upstream, probably in a python
script, handle constraints etc there, then use brl-cad for
rendering and interference checking, and finally generate the
toolpath from the upstream output, rather than from
brl-cad |
| 04:21.14 |
stevegt_1 |
which is
probably what others are doing |
| 04:21.39 |
stevegt_1 |
darnit |
| 04:22.38 |
stevegt_1 |
the closest
i'm seeing to what jonored was doing was his mention in the IRC
channel of not being able to work on his 2009 gsoc
proposal |
| 04:23.23 |
stevegt_1 |
those
proposals aren't online anywhere? (just the ideas and the accepted
ones? at least that's all i'm finding so far..) |
| 04:23.57 |
Ralith |
stevegt_1: I
suspect you vastly underestimate the difficulty of evaluating
CSG. |
| 04:24.34 |
Ralith |
reliably and
precisely, anyway |
| 04:25.00 |
stevegt_1 |
not
underestimating -- if i were to do things upstream, then i'd have
to manually say "okay, a hole needs to go here so this other rod
can pass through" |
| 04:25.08 |
stevegt_1 |
so not even
trying to evaluate in that case ;-) |
| 04:25.24 |
Ralith |
I don't
follow |
| 04:26.32 |
stevegt_1 |
like this: if
all you've got is 2-d tools, qcad, autocad, whatever, then you have
to manually do the booleans, calculate part fit, try to keep it all
in your head |
| 04:26.55 |
Ralith |
afaik there
are no 'others'; anybody currently generating toolpaths from brlcad
models is almost certainly doing so with third party tools after
exporting to another format (e.g. stl) |
| 04:29.42 |
stevegt_1 |
i figured
that too -- but that loses info on the way through of
course |
| 04:29.42 |
Ralith |
if all you've
got is 2d tools, I don't think there's yet any way to get
meaningful data from BRL-CAD to them anyway, short of writing your
own tool. |
| 04:29.44 |
stevegt_1 |
other way
around -- sketch in qcad, import into brl-cad, extrude,
repeat |
| 04:29.45 |
Ralith |
that should
be feasible; there appears to be a dxf importer. |
| 04:29.47 |
stevegt_1 |
then use
rtcheck for interference checking to find out where you screwed up
;-) |
| 04:31.18 |
Ralith |
rtcheck? |
| 04:31.24 |
stevegt_1 |
the dxf
importer seems to work -- the only thing i haven't been able to
figure out os the right way to use 'extrude' -- it's not shown in
the pdf tutorials, and the wiki seems to disagree with the code
and/or usage statement |
| 04:31.30 |
stevegt_1 |
s/os/is/ |
| 04:31.42 |
Ralith |
someone in
here probably knows |
| 04:31.44 |
stevegt_1 |
rtcheck --
checks for overlaps; it's great |
| 04:31.51 |
Ralith |
also check
the reference card, and the built-in help |
| 04:31.59 |
pacman87 |
stevegt_1: do
you already have the sketch? |
| 04:32.01 |
Ralith |
that's not
what my manpage says... |
| 04:32.02 |
pacman87 |
for the
extrude |
| 04:32.04 |
Ralith |
<PROTECTED> |
| 04:32.14 |
stevegt_1 |
pacman87!!!
someone else is awake! |
| 04:32.30 |
pacman87 |
hi |
| 04:32.36 |
pacman87 |
reads the backlog |
| 04:33.08 |
Ralith |
perhaps it's
used for something else in mged. |
| 04:33.35 |
pacman87 |
can you
summarize what you're trying to do? |
| 04:33.52 |
stevegt_1 |
goes to see if he's completely confused about the name of
that command |
| 04:34.12 |
pacman87 |
dxf ->
sketch -> extrude? |
| 04:37.06 |
stevegt_1 |
is not crazy |
| 04:37.24 |
stevegt_1 |
unless i'm
completely misinterpreting the results of mged's
rtcheck |
| 04:37.31 |
Ralith |
shrugs |
| 04:37.32 |
Ralith |
I've never
used it |
| 04:37.38 |
stevegt_1 |
pacman87:
yes, dxf -> sketch -> extrude |
| 04:37.53 |
pacman87 |
and where
does the problem start? |
| 04:38.08 |
stevegt_1 |
lemme go get
an error message... |
| 04:38.16 |
pacman87 |
(and the
command that caused it) |
| 04:43.30 |
stevegt_1 |
pacman87: i
think i'm probably having basic usage confusion as much as anything
else -- ' extrude sketch.1 5' errors out wanting the user to be in
SOL EDIT state, but if I say 'sed sketch.1', it pops up the gui
sketch editor... then if i say 'extrude sketch.1 5' again, it still
says i'm in VIEWING state |
| 04:44.06 |
stevegt_1 |
i obviously
haven't done enough of the tutorials, to begin with |
| 04:44.31 |
pacman87 |
oh, i'm using
classic mode |
| 04:44.35 |
stevegt_1 |
ah |
| 04:44.47 |
pacman87 |
so i just do
"in <name> extrude" |
| 04:44.51 |
pacman87 |
and it promps
for the fields |
| 04:45.08 |
stevegt_1 |
lemme try
that |
| 04:49.19 |
pacman87 |
the dxf-g
converter used to double the line segments (one going each
direction), but i think that's been fixed |
| 04:50.12 |
stevegt_1 |
notes that the 'extrude' command and the 'extrude' primitive
are completely different |
| 04:50.17 |
stevegt_1 |
i
think |
| 04:50.29 |
pacman87 |
i only know
of the primitive |
| 04:50.31 |
pacman87 |
what's the
command do? |
| 04:50.50 |
stevegt_1 |
the command
just wants 2 args: 'extrude {face} {distance}' |
| 04:50.59 |
stevegt_1 |
much simpler
;-) |
| 04:51.02 |
Ralith |
yeah, that
probably doesn't have anything to do with sketches. |
| 04:51.07 |
stevegt_1 |
if i could
get it to work ;-) |
| 04:51.19 |
Ralith |
considering
that sketches don't have faces. |
| 04:51.37 |
pacman87 |
what
primitive results from the extrude command? |
| 04:53.13 |
stevegt_1 |
pacman87:
the wiki says it 'modifies an ARB' -- ahh, yes, that won't work on
sketches |
| 04:53.23 |
stevegt_1 |
i
think |
| 04:53.56 |
pacman87 |
yeah, so it
take the edge points from and ARB, and uses that as the base for
(i'm guessing) another ARB |
| 04:54.04 |
pacman87 |
s/from
and/from an/ |
| 04:54.39 |
Ralith |
stevegt_1:
think about it; sketche don't have faces. |
| 04:54.44 |
Ralith |
sketches* |
| 04:56.01 |
stevegt_1 |
Ralith: i
seem to remember seeing the code accepting a sketch as one of its
args, but can't find it ATM... hang on, gotta put a 6-year-old to
bed... |
| 05:01.04 |
Ralith |
brb |
| 05:05.14 |
pacman87 |
bedtime for
me |
| 05:13.39 |
Ralith |
back |
| 05:31.32 |
stevegt_1 |
back -- nope,
the mged extrude doesn't take sketches, wants an arb face -- don't
know what code I was looking at the other day |
| 05:37.56 |
Ralith |
so see what
you can do with in |
| 05:43.58 |
stevegt_1 |
yep |
| 07:22.32 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 07:49.45 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 09:53.34 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F13C.dip.t-dialin.net) |
| 09:57.34 |
*** join/#brlcad mafm_
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 12:21.48 |
starseeker |
growls - rebuilding gentoo sucks... |
| 12:29.24 |
louipc |
hehe still on
that train eh? |
| 12:37.07 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 12:55.17 |
_clock_ |
starseeker: I
can understand this rebuilding my gentoo sucked so much that I
swapped to another distro |
| 13:06.41 |
louipc |
_clock_++ |
| 13:25.08 |
starseeker |
tried that |
| 13:25.14 |
starseeker |
sucked more
than rebuilding |
| 13:37.48 |
mafm_ |
debian
ftw! |
| 13:39.11 |
louipc |
starseeker:
what distros? |
| 13:39.25 |
louipc |
not ubuntu!
:D |
| 13:39.57 |
starseeker |
yeah,
ubuntu |
| 13:40.19 |
starseeker |
has finely tweaked his desktop settings over the years, and
ubuntu has its own ideas |
| 13:40.48 |
louipc |
yeah debian
is probably better |
| 13:41.20 |
louipc |
I would plug
arch linux though :P |
| 13:46.36 |
brlcad |
bsd ftw
;) |
| 14:02.08 |
CIA-32 |
BRL-CAD:
03irpguardian * r34849 10/brlcad/trunk/src/proc-db/human.c: (log
message trimmed) |
| 14:02.10 |
CIA-32 |
BRL-CAD: Made
significant updates to the human.c file which will eventually be a
complete human generator that |
| 14:02.13 |
CIA-32 |
BRL-CAD: uses
CSG to model a human. |
| 14:02.15 |
CIA-32 |
BRL-CAD:
human.c currently creates a 'stick' human to a desired height by
use of command line parameters and also |
| 14:02.18 |
CIA-32 |
BRL-CAD:
allows for the output of specifically named .g file when using the
-o command on input. |
| 14:02.22 |
CIA-32 |
BRL-CAD: Also
included are most of the bounding blocked for each part of the
generated body by using the -b command. |
| 14:02.25 |
CIA-32 |
BRL-CAD: So
if you wanted to make a 'human' right now, the command would
be... |
| 14:10.24 |
louipc |
crazy |
| 14:49.36 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 14:52.37 |
CIA-32 |
BRL-CAD:
03irpguardian * r34850 10/brlcad/trunk/src/proc-db/human.c: Added
bounding box support to each of the hands. |
| 14:59.47 |
CIA-32 |
BRL-CAD:
03bob1961 * r34851 10/brlcad/trunk/src/librt/db_open.c: Fixed a bug
in db_sync (i.e. it was possible to return without releasing a
semaphore). |
| 15:19.44 |
CIA-32 |
BRL-CAD:
03bob1961 * r34852 10/brlcad/trunk/src/libged/ged.c: Modify
ged_open() to create a dbip if a NULL one is passed in. |
| 15:25.59 |
CIA-32 |
BRL-CAD:
03bob1961 * r34853
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Now using inmem
database for the ledger. |
| 15:34.23 |
starseeker |
brlcad:
figuring out the bsd install would talk some time, and figuring out
the new config file locations would take more :-P |
| 15:34.28 |
starseeker |
is getting old... |
| 15:39.14 |
brlcad |
'scuses
'scuses |
| 15:40.38 |
starseeker |
was actually crazy enough to consider opensolaris for a
second... |
| 16:36.36 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 16:38.00 |
CIA-32 |
BRL-CAD:
03irpguardian * r34854
10/brlcad/trunk/src/proc-db/human.c: |
| 16:38.02 |
CIA-32 |
BRL-CAD:
Added section that creates regions out of all the body parts and
all the bounding boxes, aptly named |
| 16:38.05 |
CIA-32 |
BRL-CAD:
Body.r and Boxes.r |
| 16:53.15 |
*** join/#brlcad roberthl
(n=robert@cobalt.rhl.me.uk) |
| 17:03.45 |
CIA-32 |
BRL-CAD:
03brlcad * r34855 10/brlcad/trunk/TODO: binary installer for
windows is missing external dependency headers (specifically need
tcl and openNURBS headers) |
| 17:06.43 |
CIA-32 |
BRL-CAD:
03brlcad * r34856 10/brlcad/trunk/NEWS: bob implemented initial
undo support for archer using in-memory geometry and a ledger of
changes. |
| 17:15.30 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:41.21 |
brlcad |
hello
jdoliner, how goes the progress? make sense of nmg? |
| 17:54.29 |
jdoliner |
yeah I got
the basic idea of nmg |
| 17:55.26 |
jdoliner |
I have a
weird problem right now |
| 17:59.42 |
jdoliner |
so I've
written a test for my meshmeshintersection algorithm |
| 18:00.12 |
jdoliner |
and it seems
good |
| 18:01.18 |
jdoliner |
except when I
call it. control goes into ON_Mesh::ON_Mesh function and after it
completes that it just hangs |
| 18:01.37 |
jdoliner |
I feel like
there's something I'm not getting here |
| 18:28.03 |
stevegt_1 |
~seen
Ralith |
| 18:28.08 |
ibot |
ralith is
currently on #brlcad (1d 22h 35m 20s). Has said a total of 120
messages. Is idling for 12h 50m 13s, last said: 'so see what you
can do with in'. |
| 18:36.57 |
stevegt_1 |
needs a sanity check before he dives into writing something
called 'g-laser' |
| 18:37.31 |
stevegt_1 |
i think i
have an algorithm that will work for generating laser toolpaths,
but i'm new to brl-cad and might be missing something
important |
| 18:41.49 |
stevegt_1 |
i'm thinking:
since popular lasers (like the epilog) are 3dof machines, the beam
will always be perpendicular to the part being cut |
| 18:42.35 |
stevegt_1 |
that greatly
simplifies trying to figure out the profile of any edges created by
booleans |
| 18:43.50 |
stevegt_1 |
since these
lasers can only do vertical hole walls, that means the primitives
intersecting the part must have 'top' faces which are also normal
to the beam |
| 18:44.22 |
stevegt_1 |
which means
we can derive a clean toolpath directly from that 'top' face of the
intersecting primitive |
| 18:44.37 |
stevegt_1 |
without
tesselation or other approximation |
| 18:49.53 |
stevegt_1 |
this means
cones, toruses, spheres, etc. can't be used to make coles in
laser-cut parts, nor can complicated arbs (e.g. mushroom-shaped --
can brl-cad even do those?), but imho that's a reasonable
constraint |
| 18:50.05 |
stevegt_1 |
<crickets
chirping> ;-) |
| 18:50.53 |
stevegt_1 |
i'll probably
write this up on a web page somewhere and pop in here again later
-- i gotta unplug for an hour or so pretty soon |
| 18:51.06 |
jdoliner |
hi I don't
know enough about your project yet to really comment. But I am
working on CSG algorithms which is maybe related |
| 18:51.15 |
jdoliner |
so maybe if
you explain at a lower level I can help |
| 18:51.16 |
stevegt_1 |
hi
jdoliner |
| 18:52.22 |
stevegt_1 |
goes to look at what jdoliner's working on |
| 18:54.31 |
stevegt_1 |
(still
reading) |
| 18:57.03 |
stevegt_1 |
jdoliner:
okay, done reading/skimming your proposal -- the output of the
algorithm is a bezier curve? |
| 18:57.31 |
jdoliner |
yeah |
| 18:57.37 |
jdoliner |
basically |
| 18:57.45 |
jdoliner |
that bezier
curve becomes a trimming curve |
| 18:58.09 |
stevegt_1 |
as in
something that could be stated as a primitive in gcode or
dxf? |
| 18:58.39 |
stevegt_1 |
(as opposed
to tesselation) |
| 18:58.50 |
jdoliner |
yeah I
believe so |
| 18:59.16 |
jdoliner |
it can be
stated as an ON_NurbsSurface object |
| 18:59.16 |
stevegt_1 |
if that's
true, then halleluyah, or somesuch |
| 18:59.37 |
stevegt_1 |
s/tesselation/tessellation/
;-) |
| 19:01.46 |
stevegt_1 |
the need for
that algorithm is where i was hung up on the toolpath-generation
problem -- i could see that some thorny math would be required, but
the closest i'd be able to get is by trying to duplicate what librt
does in solving quadratics or something -- and i barely made it
through Calc II, 25 years ago ;-) |
| 19:03.28 |
stevegt_1 |
something
that algorithm will be needed to generate toolpaths for machines
which have more that 3 axes -- i.e. if the machine can tilt the
cutting tool, or otherwise do over/undercuts in holes and at the
sides of a part |
| 19:03.37 |
stevegt_1 |
s/something/something like/ |
| 19:06.14 |
stevegt_1 |
anyway, i
*think* i can cheat in the case of 3-axis machines like lasers,
since they can only do vertical-walled cuts -- just constrain the
intersecting primitives to have faces that are perpendicular to the
part being cut |
| 19:11.36 |
*** join/#brlcad stevegt``
(n=stevegt@cislunar.TerraLuna.Org) |
| 19:13.30 |
stevegt_1 |
jdoliner: i
gotta go get lunch; i'll try to write this up and be back
later |
| 19:14.06 |
jdoliner |
yeah,
particularly if you get hung up on thorny math I can try to give
you a hand with ti |
| 19:14.25 |
jdoliner |
it** |
| 19:14.31 |
stevegt_1 |
i'm pretty
sure you could ;-) |
| 19:25.33 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 19:42.35 |
CIA-32 |
BRL-CAD:
03bob1961 * r34857
10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added cc.c
and lscon.c to build. |
| 20:03.22 |
CIA-32 |
BRL-CAD:
03bob1961 * r34858 10/brlcad/trunk/misc/win32-msvc8/
(brlcad/brlcad.sln g2adrt/): Removed g-adrt from windows
build. |
| 20:13.43 |
CIA-32 |
BRL-CAD:
03bob1961 * r34859 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Removed a bit of leftovers from the
previous edit history hack. |
| 20:41.34 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 21:19.39 |
brlcad |
jdoliner: hm,
hard to say without walking the execution or knowing more info
about the ON_Mesh::ON_Mesh problem -- have you tried stepping
through with a debugger? |
| 21:20.47 |
jdoliner |
yeah gdb's
really been the flavor of the afternoon :) |
| 21:20.56 |
brlcad |
stevegt_:
mushroom-shaped arbs?? picture of one? |
| 21:21.08 |
brlcad |
jdoliner:
heh, awesome |
| 21:21.23 |
jdoliner |
it was
something weird with initializing ON_Meshes |
| 21:21.39 |
jdoliner |
but I switch
the function to use pointers instead |
| 21:21.42 |
jdoliner |
and that
cleared it up |
| 21:22.15 |
jdoliner |
which in all
honesty probably makes more sense because I imagine meshes can get
big |
| 21:25.32 |
brlcad |
they can get
huge, Gigs |
| 21:27.54 |
brlcad |
stevegt_:
sorry we keep failing to cross paths :) |
| 21:28.05 |
stevegt_ |
brlcad:
right here ;-) |
| 21:28.23 |
stevegt_ |
other than
the mushrooms, did the rest of what i was saying make
sense? |
| 21:33.13 |
stevegt_ |
overall, what
i'm trying to do is pick a cad package for designing and generating
toolpaths for making low-end machines that have a laser-cut acrylic
parts, and are otherwise built from bolt-together things off the
shelf -- motors, lead screws, fasteners, etc |
| 21:33.16 |
stevegt_ |
like http://fabathome.org/wiki/index.php?title=Main_Page |
| 21:33.39 |
brlcad |
Ralith:
rtcheck's primary purpose is interference (aka overlap) detection
with a side-effect of overlaying a plot of the overlaps if you run
it in mged (yes the help line is misleading) |
| 21:34.09 |
stevegt_ |
brlcad: good,
i wasn't insane that time ;-) |
| 21:36.04 |
brlcad |
stevegt_:
docs are pretty thin on extrude, but it's really pretty simple to
extrude a sketch -- run the 'in' command in mged and it'll
interactively prompt you |
| 21:37.11 |
brlcad |
ah, and yes,
there is an 'extrude' command which is different than creating an
extrude primitive -- you don't want the extrude command, you want
the 'in' command |
| 21:37.13 |
stevegt_ |
brlcad: so i
gathered; i haven't figured out what some of the prompts are asking
yet, but i'm sure that'll be obvious by the time i get used to the
way brl-cad does things |
| 21:38.41 |
stevegt_ |
s/low-end
machines that have a laser-cut acrylic parts/low-end machines that
have a lot of laser-cut acrylic parts/ |
| 21:38.49 |
brlcad |
ah, all
caught up with the log now :) |
| 21:39.03 |
brlcad |
yes, the rest
you said made sense (i think!) :) |
| 21:40.12 |
brlcad |
basically it
asks you what scaling factors do you want (you can skew/stretch the
sketch before extruding it) and then the distance |
| 21:40.35 |
brlcad |
usually best
to just use orthogonal unit vectors, 1 0 0 and 0 1 0 |
| 21:41.01 |
brlcad |
that aligns
the sketch normalized to an x/y plane like one would usually expect
be default |
| 21:42.11 |
brlcad |
that's a
pretty cool machine, hmm.. :) |
| 21:42.13 |
stevegt_ |
anyway, i
*think* i'm in a common use case for the newer crowd of maker
community, arduino controllers, fabbers, people who might have
access to a laser or CNC router, and are looking for something more
capable than qcad for modelling the machines -- so something like
'g-laser' seems like a good idea, just trying to figure out how
doable it is |
| 21:42.47 |
stevegt_ |
so 'in ...
extrude' wants a sketch? lemme go try it again... |
| 21:42.53 |
brlcad |
g-gcode is
something that's been on the "todo" for a while :) |
| 21:43.41 |
brlcad |
yeah, 'in' is
the interactive input tool for creating primitives .. you can feed
it the whole line or parts of a line and for any part remaining
it'll prompt you |
| 21:44.46 |
stevegt_ |
yeah, i'm
saying to myself "wow, brl-cad is great!!" and i'm going through
the tutorials, and then it hits me -- right now, it seems to be
optimized for importing and analyzing models, rather than making
them -- unless you are using STL e.g. 3-d printing? |
| 21:45.14 |
stevegt_ |
s/making
them/making things from them/ |
| 21:45.16 |
brlcad |
the real
solution to what you want is very much related to jdoliner's
project where you evaluate a given object (regardless of geometry
format, csg or non-csg) to a spline-surface boundary representation
that has no booleans, then project that to a given
plane |
| 21:45.46 |
brlcad |
gives you a
series of 2D spline curves and line segments that could them be
turned into arcs and polylines or what have you |
| 21:45.46 |
stevegt_ |
i agree --
for generic gcode for a 3 or more axis mill, you need jdoliner's
stuff |
| 21:47.23 |
brlcad |
what you
intuited about brl-cad is quite true -- it's presently heavily
geared around import and analysis requirements .. but also
visualization and creation (but a very different approach than most
commercial systems) |
| 21:48.00 |
stevegt_ |
the light
bulb this morning was that, since a lot of these potential users
(including me) are just using lasers, then i can just ensure via
raytracing that hole walls are vertical, and then directly derive
the dimensions of the hole by looking at the top face of the
intersecting shape -- i think ;-) |
| 21:49.30 |
jdoliner |
stevegt_:
whenever you need me I'm here to help |
| 21:49.36 |
stevegt_ |
i plan to
generate a lot of parts from scripts in the first place, so brl-cad
fits with that usage as well |
| 21:49.39 |
brlcad |
for nearly
two decades, brl-cad has been used (with the csg approach) to model
vehicles down to the nut bolt and wire using CSG boolean operations
and primitives -- many things are considerably more efficient that
way over BREP methods, but it's definitely a very different way of
thinking about things and a large body of experience that has to be
built up -- but once you do, the advanced brl-cad modelers are just
as effective in brl-cad as they are in other com |
| 21:50.54 |
brlcad |
stevegt_: you
know, if you're ray-tracing, it's not a whole lot extra logic to
make it derive that top-hole using ray-tracing to a given tolerance
using adaptive subdivision |
| 21:51.14 |
stevegt_ |
goes and looks up "adaptive subdivision"
;-) |
| 21:51.27 |
brlcad |
that would
let you extract a contour for any arbitrary view |
| 21:52.12 |
stevegt_ |
is that more
or less what the tessellation routines do? |
| 21:52.27 |
brlcad |
not at
all |
| 21:52.38 |
stevegt_ |
i see
'curves' in the description... |
| 21:52.51 |
brlcad |
it's basicaly
a sampling approach, you sample down to a specified level of
detail |
| 21:54.33 |
stevegt_ |
is that
related to the use of voxel spaces? |
| 21:54.40 |
brlcad |
think of it
this way.. you shoot a grid of rays and find the edges of an object
.. but instead of filling in pixels, you build up coefficients for
a set of polynomial curves |
| 21:54.53 |
stevegt_ |
ah |
| 21:55.34 |
brlcad |
sampled
sufficiently, you'll derive a spline that fits to the circular top
of a cylinder, for example |
| 21:56.06 |
stevegt_ |
is there code
anywhere in the brl-cad tree that does something like this right
now? |
| 21:56.21 |
brlcad |
I'm sure you
could *very* easily sample at a resolution much higher than the
resolution of your fabbers stepper motors :) |
| 21:58.26 |
brlcad |
hm, the
closest starting point is probably rtedge, which simply renders an
edge outline (raster) of an object based on neighboring hits --
you'd want to extend that to be calculate the curves |
| 21:58.44 |
brlcad |
example,
http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 21:58.47 |
stevegt_ |
ah ha --
'adaptive subdivision algorithm' is giving me some good hits in
google.... |
| 21:59.38 |
stevegt_ |
yeah, i
looked at rtedge and got worried that i'd be stuck with raster-like
limitations, then popped in last night to bug Ralith about it
;-) |
| 22:00.24 |
brlcad |
yeah, just
forget about the pix output -- you'd be outputting curves or
directly to gcode or whatever |
| 22:00.31 |
stevegt_ |
huh |
| 22:02.00 |
stevegt_ |
i'm wondering
if it would be easier to write the code such that it tries to read
the hole geometry directly off the top face of the intersecting
object, and *then* falls back to adaptive subdivision, or just uses
adaptive subdivision always... |
| 22:02.39 |
stevegt_ |
probably the
latter, assuming i can figure out how to do it |
| 22:03.31 |
stevegt_ |
the
raytracing hits sure are nice to be able to get at |
| 22:06.59 |
brlcad |
nice example:
http://www.museum.state.il.us/ismdepts/library/linuxguides/povray/image112.gif |
| 22:07.26 |
brlcad |
"adaptive
sampling" <- another useful term you can search on |
| 22:08.00 |
stevegt_ |
now has to go back and remember how polynomial curve fitting
works -- those brain cells died decades ago :-b |
| 22:09.14 |
Ralith |
it's not
hard |
| 22:09.27 |
brlcad |
so in that
image, where you have a hit neighbored to a miss, you know there's
an edge somewhere between those two rays, you adaptively sample to
more precisely find that edge -- if you recurse down all edges, you
can find a 'perfect' contour from which you can derive coefficients
for a representative set of splines |
| 22:10.01 |
stevegt_ |
hi Ralith!
|
| 22:10.04 |
Ralith |
hullo |
| 22:11.28 |
brlcad |
another
example, http://www.lamrug.org/resources/images/samples/samples.03d.jpg |
| 22:12.48 |
brlcad |
done well
enough, you end up with an rtvector .. from which you could output
svg or gcode or pdf or whatever format ;) |
| 22:13.15 |
stevegt_ |
brlcad: that
sounds like it might be successive approximation -- do you
ultimately compare the polynomial-generated curve with the original
edge, or is the algorithm open-loop? (if that makes
sense) |
| 22:14.06 |
stevegt_ |
(i'm still
skimming papers from citeseer) |
| 22:14.54 |
brlcad |
yes, it's a
way to get a successive approximation |
| 22:15.24 |
brlcad |
there is no
"original edge" to compare it to, you're deriving a representation
for that edge |
| 22:15.55 |
brlcad |
you just keep
refining until you're below a specified accuracy level (ideally
below your machine's capabilities) |
| 22:16.13 |
brlcad |
so even if
there is error, it's never realized |
| 22:17.32 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 22:17.55 |
stevegt_ |
the way
you're envesioning this working, is it iterative? or am i
missing some direct way to get from ray hits to
coefficients? |
| 22:18.34 |
stevegt_ |
s/envesioning/envisioning/ |
| 22:18.51 |
brlcad |
here we go,
even better |
| 22:19.29 |
brlcad |
it's
basically an implementation of marching cubes with adaptive
subsampling, but in 2D (i.e., marching squares with adaptive
subsampling) |
| 22:19.33 |
brlcad |
http://www.exaflop.org/docs/marchcubes/ |
| 22:19.53 |
stevegt_ |
funny --
march cubes was one of the links i saw a few minutes
ago |
| 22:19.55 |
brlcad |
and yes, it
is iterative |
| 22:19.56 |
stevegt_ |
goes to look |
| 22:20.48 |
brlcad |
that page
even speaks to the sampling issues, good stuff |
| 22:21.58 |
brlcad |
just when
reading, you're working in 2D so read it as s/cubes/squares/ and
s/polygons/line segments/ (for starters) |
| 22:22.03 |
stevegt_ |
ok, yes,
they're talking about voxel spaces... |
| 22:22.19 |
brlcad |
voxel spaces
are for 3D |
| 22:22.28 |
stevegt_ |
...and
they're using polygons instead of curves, but i'm grokking
it |
| 22:23.04 |
brlcad |
right, the
even mention that near the end -- that's basically applying
smoothing algorithm to derive a curve |
| 22:23.36 |
stevegt_ |
saw that --
and you're picturing polynomial curve segments instead of straight
line segments |
| 22:24.24 |
brlcad |
yeah, only
because I don't think many machines would be robust with millions
of sub-millimeter line segments that would be required to describe
a smooth curve |
| 22:24.48 |
brlcad |
would expect
aliasing artifacts |
| 22:25.36 |
brlcad |
interpolate a
curve and simplify (e.g., identify and make curves that are linear
actually just be line segmenets) |
| 22:25.48 |
stevegt_ |
okay, i think
i can do this -- the way my brain works, i'm probably going to wind
up re-deriving a lot of the algorithm, but to me it looks familiar
when i think of it in the class of successive approximation, binary
search, interpolation, etc. |
| 22:29.18 |
stevegt_ |
just don't
make me solve quadratics ;-) |
| 22:31.34 |
brlcad |
adaptive
marching squares, tis good stuff ;) |
| 22:41.00 |
CIA-32 |
BRL-CAD:
03brlcad * r34860 10/brlcad/trunk/src/libbu/parallel.c: ws indent
cleanup |
| 22:53.23 |
CIA-32 |
BRL-CAD:
03brlcad * r34861 10/brlcad/trunk/src/libbu/parallel.c: |
| 22:53.25 |
CIA-32 |
BRL-CAD: make
sure the file is actually world read/writable like we said it would
be, |
| 22:53.27 |
CIA-32 |
BRL-CAD: call
bu_fchmod(). that said, this is a horrible way to do this. mark
the |
| 22:53.35 |
CIA-32 |
BRL-CAD:
implementation as deprecated even if it's not likely anyone is
relying on the |
| 22:53.37 |
CIA-32 |
BRL-CAD: temp
files and rtsrv is the only brl-cad tool that can leverage
this. |
| 22:54.04 |
stevegt_ |
brlcad: while
i'm only going to write something like g-laser, g-toolpath2d, or
whatever ("marching squares"), it does strike me that the marching
cubes could be used to generate gcode suitable for N-axis
mills |
| 22:55.27 |
stevegt_ |
<lightbulb
on> and the raytracing lib could be used to fire rays at various
angles to test the approache angle of the tool itself, make sure it
doesn't hit anything |
| 22:55.37 |
stevegt_ |
s/approache/approach/ |
| 22:59.45 |
brlcad |
yep |
| 23:01.02 |
brlcad |
the exact
approach you're using it 2D extends very well to 3D -- hell, with
the 3D approach, that's a viable alternative for a variety of
purposes including visualization, tessellation, and
evaluation |
| 23:01.37 |
brlcad |
the problem
is that it's not nearly as robust for all uses (e.g. visualization)
where you can continue to "zoom in" and start to see the
artifacts |
| 23:01.46 |
brlcad |
works well
for hardware though |
| 23:02.12 |
stevegt_ |
that would
really go far in cleaning up the CNC tool chain -- where I sit
right now (middle of silly valley) there are about 900 CNC mills
with a 1-mile radius; we've gotten to know a few of them over the
last several years; they are all still very labor-intensive when it
comes to massaging the dxf they get from the customer and
generating the gcode |
| 23:03.03 |
brlcad |
to make sure
the tool doesn't hit anything, something ala rtcheck or g_qa would
work great by just having them represent the tool as geometry and
test for overlap |
| 23:03.42 |
brlcad |
cool that
you're interested in this, look forward to seeing what you make of
it |
| 23:03.51 |
brlcad |
the idea has
been around for a while, just nobody to work it |
| 23:04.35 |
brlcad |
lots of
squeaky wheels that require attention, like better modeling
interface, better interactive visualization, step conversion
support, full hybrid nurbs brep support, etc ;) |
| 23:05.41 |
stevegt_ |
i've been
interested in this ever since I was in the USAF in the early 80's,
and saw how far we (still) are from being able to "print metal" --
it really drives up the cost of everything |
| 23:07.50 |
stevegt_ |
whups --
s/early 80's/late 80's/ -- i'm not *that* far gone yet
;-) |
| 23:08.56 |
brlcad |
heh |
| 23:11.36 |
CIA-32 |
BRL-CAD:
03brlcad * r34862 10/brlcad/trunk/src/librt/ (primitives/table.c
wdb.c): ws indent consistency |
| 23:19.28 |
stevegt_ |
makes himself stop and go get (very late)
lunch |
| 23:24.04 |
CIA-32 |
BRL-CAD:
03brlcad * r34863 10/brlcad/trunk/src/librt/ (7 files in 6 dirs):
break out arb8 mirroring, modify all the mirror function signatures
to not take a pointer, instead just taking a plant_t |
| 23:25.33 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14F13C.dip.t-dialin.net) |
| 23:25.47 |
CIA-32 |
BRL-CAD:
03brlcad * r34864 10/brlcad/trunk/misc/ (2 files in 2 dirs): add
arb8_mirror.c to the other windows build files |
| 23:41.08 |
CIA-32 |
BRL-CAD:
03brlcad * r34865 10/brlcad/trunk/misc/win32-msvc9/: |
| 23:41.10 |
CIA-32 |
BRL-CAD:
remove the vc9 project files as they've gotten considerably out of
sync without |
| 23:41.12 |
CIA-32 |
BRL-CAD: a
maintainer. there are more than 163 differences with the vc8
project. |
| 23:41.14 |
CIA-32 |
BRL-CAD:
someone can revive and resync if they're willing to maintain it,
otherwise it's |
| 23:41.18 |
CIA-32 |
BRL-CAD: just
a costly maintenance burden and confusing to users. |
| 23:43.32 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 23:49.59 |
``Erik |
would it be
easy to generate vc9 files from the vc8 ones? |
| 23:50.33 |
``Erik |
(or mebbe
solicit the mailing list for a vc9 volunteer?) |
| 23:54.06 |
starseeker |
glares at gentoo - I might have known - a non-clean config
path upgrade |
| 23:54.30 |
starseeker |
first rule of
Xorg building - never,never,NEVER build a configuration that won't
work |
| 23:54.58 |
starseeker |
oh, well - I
was due for a scrub anyway, but GRRRRRRRR |
| 23:55.52 |
``Erik |
pkg_add
x11/Xorg on bsd, binary install of all the right stuff, then you
can portupgrade at your leisure with automatic failure recovery and
'last good state' saved just in case |
| 23:57.05 |
``Erik |
throw in the
normal bsd nerd approach of putting edited config files in cvs or
rcs and you have a system very very hard to fuck up for more than 2
minutes |
| 00:05.25 |
starseeker |
wow... it
looks like they're trying to lay the ground work for modernizing
how Xorg and hardware autodetection (hal) work together |
| 00:06.56 |
starseeker |
figures... I
upgrade, get power failure, reboot with bad config setup...
|
| 00:07.03 |
starseeker |
yeesh, one of
those weeks |
| 00:07.31 |
starseeker |
oh, well - I
guess on the bright side I didn't get killed by a tornado, so it's
all good... |
| 00:20.07 |
starseeker |
there we go -
ah, X feels good |
| 01:28.48 |
Ralith |
hm. |
| 01:29.01 |
Ralith |
I can't seem
to get a test mesh visible in Ogre-in-Qt :/ |
| 01:29.31 |
Ralith |
Ogre seems to
be working, though; at least, its background color is showing up
fine. |
| 01:30.56 |
Ralith |
mafm: you
around? |
| 01:44.00 |
mafm |
Ralith:
briefly, almost 4am here and I want to go to bed :) |
| 01:51.39 |
Ralith |
mafm: ah.
How'd you get that shape thingy to render in ogre? |
| 01:52.03 |
Ralith |
I've got ogre
at least apparently rendering, but nothing seems to be
visible |
| 01:52.36 |
mafm |
I had a shape
floating around, for testing purposes |
| 01:52.42 |
mafm |
aren't you
using it? |
| 01:52.55 |
Ralith |
no, I mean
how did you get it to actually RENDER? |
| 01:52.58 |
Ralith |
I'm loading a
mesh fine. |
| 01:53.22 |
mafm |
well, it's
been almost a year ago since I did that, I can't
remember |
| 01:53.29 |
Ralith |
'kay |
| 01:53.35 |
mafm |
probably you
have to put it in a point where you can see it |
| 01:53.51 |
Ralith |
I'm
using: |
| 01:53.52 |
Ralith |
_camera->lookAt(sphereNode->getPosition()); |
| 01:53.52 |
mafm |
I don't think
that you need anything special |
| 01:54.00 |
Ralith |
so I'm pretty
sure it's visible |
| 01:54.07 |
indianlarry |
starseeker:
back up and runnin I see |
| 01:54.08 |
mafm |
is the camera
far away? |
| 01:54.15 |
Ralith |
shouldn't
be |
| 01:54.20 |
Ralith |
camera's at
0,0,0 and the sphere's at 10,0,0 |
| 01:55.18 |
mafm |
I meant that
if it's inside the sphere (because the sphere has a large radius)
probably it's not painting the inside, so you can't see
it |
| 01:55.29 |
Ralith |
could
be |
| 01:55.30 |
mafm |
try to get
controls working, too |
| 01:55.32 |
Ralith |
s/10/50/ |
| 01:55.47 |
mafm |
I remember to
have problems with culling |
| 01:55.50 |
Ralith |
I'm hesitant
to do that until I have something to look at, cuz there'd be no way
to test |
| 01:56.03 |
Ralith |
I pretty much
copypasted the scene setup code from Application.cxx |
| 01:56.14 |
Ralith |
so any
solution you applied should be working here, too. |
| 01:56.30 |
mafm |
so in some
distances, for no obvious reasons, I couldn't see my tetrahedron in
action |
| 01:56.49 |
Ralith |
yeah, nothing
visible at 50,0,0 either |
| 01:56.50 |
mafm |
so I had
sometimes to zoom in or out, etc |
| 01:57.27 |
mafm |
mmm, check if
the node is visible, it should have a getter method for
that |
| 01:57.45 |
Ralith |
I already
force it to visibility |
| 01:58.47 |
Ralith |
I think maybe
I'll add the Qt overlay, get a widget up for displaying current
camera position/orientation, and then see about enabling
controls. |
| 02:03.24 |
mafm |
yep |
| 02:03.35 |
mafm |
aren't you
using my camera controls? |
| 02:03.51 |
mafm |
you can hook
it to Qt right away, I think |
| 02:04.00 |
mafm |
blender mode,
mged mode, etc |
| 02:04.21 |
Ralith |
since I had
to drop RBGui, right now I'm working with a very minimal setup that
just tests the Ogre/Qtness. |
| 02:04.30 |
mafm |
so you would
readily have zooming, rotating around the object and so
on |
| 02:04.54 |
Ralith |
I'll be
bringing your code back in once I get this working and can begin to
swap in Qt for the existing stuff. |
| 02:04.57 |
mafm |
well, I think
that you can use it even without Qt |
| 02:05.08 |
mafm |
probably the
input is still working |
| 02:05.21 |
mafm |
it only
requires OGRE and OIS, IIRC |
| 02:05.44 |
mafm |
so you don't
really need anything related with GUI to control the
camera |
| 02:05.54 |
Ralith |
I'm not
init'ing OIS currently, partly due to some weird singleton errors
it was causing |
| 02:06.03 |
mafm |
ops
:S |
| 02:06.13 |
Ralith |
and I think
Qt provides input, too, so it shouldn't be necessary
long-term |
| 02:06.29 |
Ralith |
I'll see if I
can wire up Qt's input to your existing camera control stuff,
though; good idea thre. |
| 02:06.40 |
Ralith |
after I get
Qt widgets rendering. |
| 02:12.18 |
mafm |
I think that
my input works directly with OIS, so it would be easier if you get
it working |
| 02:12.54 |
mafm |
also, I don't
know if you can pass the input Qt->OGRE, or you have to get the
input in Ogre and pass it over to Qt |
| 02:13.13 |
mafm |
since Qt
works with OpenGL probably you can |
| 02:17.07 |
Ralith |
ah, crap,
looks like I dropped the Ogre stuff in the wrong place |
| 02:19.02 |
Ralith |
well, thanks
for the input |
| 02:21.59 |
mafm |
ok |
| 02:22.02 |
mafm |
good
night! |
| 02:22.06 |
Ralith |
nite! |
| 02:39.12 |
starseeker |
indianlarry:
heh, yep |
| 02:58.36 |
CIA-32 |
BRL-CAD:
03ralith * r34866 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h OgreScene.cxx OgreScene.h): Moved code Ogre to a
subclass of QGraphicsScene, OgreScene, instead of a subclass of
QGLWidget, in preparation for drawing Qt GUI elements on
top. |
| 03:13.59 |
CIA-32 |
BRL-CAD:
03ralith * r34867 10/rt^3/trunk/src/g3d/ (OgreScene.cxx
OgreScene.h): Removed an unnecessary state-tracking bool and added
experimental resize handling. |
| 03:26.06 |
Ralith |
damn, Qt
stuff isn't working first try :/ |
| 03:27.17 |
louipc |
not too bad.
my shell script doesn't even work first try heheheh |
| 03:28.37 |
Ralith |
hm |
| 03:28.53 |
CIA-32 |
BRL-CAD:
03ralith * r34868 10/rt^3/trunk/src/g3d/OgreScene.cxx: Qt test
widgets (not yet working) |
| 03:28.56 |
Ralith |
maybe my
tiling wm is to blame. |
| 03:29.00 |
Ralith |
needs to go eat, though |
| 03:35.52 |
*** join/#brlcad b0ef
(n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 03:36.49 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 03:52.30 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 04:06.03 |
*** join/#brlcad stevegt_1
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 04:12.21 |
Ralith |
okay, the
widget shows up when Ogre doesn't render anything. |
| 04:24.00 |
Ralith |
it looks
like, somehow, Ogre is rendering on top of the Qt
stuff. |
| 04:24.05 |
Ralith |
anyone here
familiar with OpenGL? |
| 04:33.46 |
Ralith |
I need to
work out how to force Ogre's rendering to happen *underneath*
Qt's. |
| 04:44.27 |
starseeker |
is this
something Qt would need to manage? |
| 04:44.48 |
starseeker |
I would
suggest checking how Qt manages overlapping windows in OpenGL
without Ogre being involved |
| 04:48.23 |
Ralith |
starseeker:
I'm not sure I see what overlapping windows has to do with
it. |
| 04:48.36 |
Ralith |
Ogre's being
drawn in the 'background' of a GraphicsScene |
| 04:48.48 |
Ralith |
but somehow
it's also ending up on top of the widgets. |
| 04:48.49 |
starseeker |
hmm |
| 04:49.06 |
Ralith |
I thought
generally things drawn first ended up underneath things drawn
later? |
| 04:49.14 |
starseeker |
not
sure |
| 04:49.19 |
Ralith |
maybe I
should clear the depth buffer after drawing Ogre? |
| 04:49.54 |
starseeker |
what happens
with a "normal" background in Qt + opengl? |
| 04:50.04 |
starseeker |
if you change
the background I mean |
| 04:50.11 |
Ralith |
change? |
| 04:50.27 |
starseeker |
that's
essentially what Ogre is doing - continually updating the
background |
| 04:50.56 |
starseeker |
if you
painted a different color (or something) in the background of a
GraphicsScene, does something similar happen? |
| 04:51.06 |
starseeker |
doesn't know, just throwing out questions |
| 04:51.31 |
Ralith |
Ogre isn't
exactly doing anything continuously; it's doing it whenever Qt asks
it to draw. |
| 04:51.55 |
Ralith |
it's
Qt-in-Ogre-in-Qt, and the two Qts are actually one Qt, so in theory
it should know what's up. |
| 04:52.27 |
Ralith |
I'm doing
things very similar to the way they're done in a known-working
Qt-in-OpenGL-in-Qt example I have |
| 04:53.02 |
starseeker |
hmm. |
| 04:54.08 |
Ralith |
just instead
of calling OpenGL stuff directly in drawBackground, I call
ogreRoot->renderOneFrame(); |
| 04:54.57 |
starseeker |
and the
render is painting the OpenGL context and overwriting the dialog
views? |
| 04:55.13 |
Ralith |
or something
that looks that way. |
| 04:55.25 |
Ralith |
okay,
clearing depth buffer did no good |
| 04:56.07 |
starseeker |
what about
calling an explicit repaint (or something like that) for the dialog
widgets after the renderOneFrame? |
| 04:57.12 |
Ralith |
I'm pretty
sure that already happens. |
| 04:57.17 |
starseeker |
hmm |
| 04:57.24 |
stevegt_1 |
okay, for the
record, lurkers, and irc logs (after struggling with it and digging
through the code off and on all afternoon trying to figure out what
some of the parms mean), the 'in ... extrude' command to generate
extrude primitives can be used like this: |
| 04:57.24 |
Ralith |
okay, it's
def. something that Ogre does |
| 04:57.27 |
stevegt_1 |
in foo.e
extrude 0 0 0 0 0 5 1 0 0 0 1 0 sketch.1 |
| 04:58.12 |
Ralith |
starseeker:
if I comment out the Ogre render call and just do glClearColor(...)
and glClear(colorbuffer | depthbuffer) I get a white background
with my widget on top of it. |
| 04:58.26 |
stevegt_1 |
that's
assuming that you want a 5 mm thick extruded sheet in the shape of
sketch.1, which in my case was imported from qcad using
dxf-g |
| 05:00.07 |
Ralith |
(when white
is my clear color, that is |
| 05:00.33 |
starseeker |
Ralith:
probably means renderOneFrame is making some assumption it
shouldn't |
| 05:00.41 |
Ralith |
yeah |
| 05:00.43 |
Ralith |
but what
:/ |
| 05:00.44 |
stevegt_1 |
the '1 0 0 0
1 0' vectors (A and B in the mged prompts, uvec and vvec in the
code) are the part of that i haven't yet completely understood --
they control stretching and rotation, but i haven't figured out
exactly how yet, so i just used the vectors brlcad mentioned
earlier today |
| 05:01.09 |
stevegt_1 |
(we now
return you to our regular programming...) |
| 05:01.13 |
Ralith |
stevegt_1: if
you leave the params out it will prompt informatively for
them. |
| 05:01.37 |
stevegt_1 |
informatively?!? it wants "A" and
"B"... |
| 05:01.47 |
Ralith |
hm, maybe
not. |
| 05:01.50 |
stevegt_1 |
hee |
| 05:04.02 |
stevegt_1 |
the closest i
came to any enlightenment was in Unigraphics/ug-g.c, which makes me
think that looking at some Unigraphics docs might explain the
history of those two vectors |
| 05:04.54 |
Ralith |
or just
fiddle them and ratyrace and see what it looks like :P |
| 05:05.54 |
starseeker |
Ralith: you
probably don't want to hear this, but I would suggest looking at
the source of the glClear stuff and renderOneFrame to see what the
differences are in how they address the ogl window |
| 05:06.00 |
Ralith |
starseeker:
here's something interesting; if I render the Ogre stuff then
glClear everything, the widgets are *still* not
rendered. |
| 05:06.13 |
stevegt_1 |
did that,
didn't get a feel for what I was doing |
| 05:06.15 |
Ralith |
...the source
of glClear? I'm pretty sure that's in the drivers
>_> |
| 05:06.32 |
starseeker |
it's not a Qt
function? |
| 05:06.39 |
Ralith |
no, it's an
OpenGL function. |
| 05:06.42 |
starseeker |
ah |
| 05:06.55 |
Ralith |
that's why
its results as mentioned above are interesting |
| 05:07.16 |
starseeker |
if you render
Ogre, do a glClear, and then call some sort of Qt redraw event does
that restore the widgets? |
| 05:07.22 |
Ralith |
Ogre's
renderOneFrame does something that makes *all* GL stuff go on top,
at least until Qt resets it (it doesn't happen if I only call
renderOneFrame once) |
| 05:07.33 |
stevegt_1 |
would have to
play with it a while longer, probably while looking at the
code |
| 05:07.55 |
Ralith |
starseeker:
because glClear alone results in the widgets displaying, and based
on the aforementioned working example, I think a widget redraw
happens automatically. |
| 05:08.14 |
Ralith |
as I
mentioned above, if I render Ogre and then do a glClear, the
widgets do NOT display. |
| 05:08.20 |
Ralith |
so Ogre's
setting some OpenGL flag or something. |
| 05:08.53 |
Ralith |
wonders if there's some way to catch all OpenGL calls ogre
makes |
| 05:09.34 |
stevegt_1 |
hint to
future self: play with those 'in ... extrude' vectors in mged
while looking at src/librt/primitives/extrude/extrude.c; also see
how extrusions are handled in src/conv/* |
| 05:11.15 |
starseeker |
Ralith: is
this related?
http://www.ogre3d.org/forums/viewtopic.php?p=296902&highlight=&sid=ce193664e1d3d7c4af509e6f4e2718c6 |
| 05:13.38 |
Ralith |
starseeker:
hmm, looks like it might be; I don't know how Qt does its OpenGL,
but it could well be immediate mode. |
| 05:17.18 |
starseeker |
I'm wondering
about the last post here, if it's still true in Qt: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=33065 |
| 05:17.33 |
Ralith |
seems like
there must be some way to reenable whatever it is that Ogre
disables |
| 05:17.41 |
Ralith |
I mean, if I
render a single Ogre frame, Qt manages to recover. |
| 05:17.47 |
Ralith |
so obviously
it's reset somehow. |
| 05:20.19 |
starseeker |
are the Qt
widgets creating their own GL contexts? I thought it was one
shared context, but maybe I'm wrong... |
| 05:20.27 |
Ralith |
it is one
shared context. |
| 05:20.45 |
Ralith |
this thread
is from before Ogre supportes context sharing. |
| 05:23.13 |
Ralith |
it looks like
renderOneFrame is doing extra stuff, though; I'll try finding this
RenderTarget;:update thing and using that |
| 05:31.12 |
Ralith |
:/ |
| 05:32.04 |
starseeker |
no
dice? |
| 05:32.28 |
starseeker |
is wondering about the swapBuffers parameter on
RenderTarget::update... |
| 05:32.31 |
Ralith |
wait... |
| 05:32.33 |
Ralith |
yeah I'm
trying that |
| 05:33.35 |
Ralith |
yeah, doesn't
work |
| 05:33.50 |
Ralith |
that is, it
has the same results as renderOneFrame |
| 05:34.18 |
starseeker |
hmm. any
chance of asking the ogre forums what's going on? |
| 05:34.34 |
Ralith |
could give
that a try |
| 05:34.55 |
Ralith |
I think I'll
try the approach in that first thread you posted, if I can find
some way to manually call the widget update |
| 05:40.19 |
starseeker |
Ralith: is
QGLWidget::isSharing important? |
| 05:40.45 |
Ralith |
don't think
so |
| 05:41.01 |
Ralith |
that's to do
with display lists |
| 05:41.02 |
starseeker |
there's also
QGLWidget::paintGL and QGLWidget::paintOverlayGL... |
| 05:41.05 |
Ralith |
good go dthis
example code sucks. |
| 05:41.36 |
Ralith |
I'm not
actually touching QGLWidget here; the Ogre stuff is going on in
GraphicsScene::drawBackground |
| 05:41.44 |
Ralith |
well, a class
derived from GraphicsScene |
| 05:41.47 |
starseeker |
erm |
| 05:42.25 |
starseeker |
oh,
right |
| 05:43.10 |
Ralith |
this guy uses
variable and class names that take up almost the entire width of my
editor singlehandedly ;_; |
| 05:43.20 |
starseeker |
you're doing
what this is doing? http://doc.trolltech.com/qq/qq26-openglcanvas.html
? |
| 05:43.35 |
Ralith |
yup |
| 05:45.13 |
starseeker |
so the
widgets are QGraphicsItem objects? |
| 05:45.28 |
Ralith |
they get
wrapped in those at some point, I imagine |
| 05:45.39 |
Ralith |
the whole
point is that they can be any QWidget though. |
| 05:47.16 |
starseeker |
yeah, I'd
contact Samuel Rodal and/or ask in the ogre forums |
| 05:48.05 |
starseeker |
be right
back, must reboot |
| 06:03.01 |
starseeker |
phew - it
worked |
| 06:03.20 |
starseeker |
sets up large packages for overnight rebuild and turns off
brain... |
| 06:05.55 |
Ralith |
heh |
| 06:05.55 |
Ralith |
nite |
| 06:05.59 |
Ralith |
Ogre forum
post made. |
| 06:10.12 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1505 10/wiki/User:Ralith: Log for 2009-06-23 |
| 06:52.48 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1506 10/wiki/User:Ralith: Addendum to log for
2009-06-23 |
| 07:40.01 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 10:11.40 |
*** join/#brlcad mafm
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 10:45.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DAA2.dip.t-dialin.net) |
| 12:01.01 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 12:14.10 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 12:17.08 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 14:48.53 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 15:14.42 |
CIA-32 |
BRL-CAD:
03irpguardian * r34869 10/brlcad/trunk/src/proc-db/human.c: Fixed
some formatting, and added a hollow bounding box
representation |
| 16:28.14 |
CIA-32 |
BRL-CAD:
03irpguardian * r34870 10/brlcad/trunk/BUGS: Added bug in regards
to rtedge and perspective viewing |
| 16:34.41 |
CIA-32 |
BRL-CAD:
03bob1961 * r34871 10/brlcad/trunk/src/libged/typein.c: Fixed a few
cases where the return value should be GED_MORE instead of
GED_ERROR. |
| 16:39.20 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r34872 10/brlcad/trunk/misc/Makefile.am: msvc9
went byebye |
| 16:42.27 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:03.09 |
CIA-32 |
BRL-CAD:
03indianlarry * r34873 10/brlcad/trunk/configure.ac: more msvc9
removal |
| 17:08.04 |
brlcad |
oops |
| 17:19.11 |
CIA-32 |
BRL-CAD:
03irpguardian * r34874 10/brlcad/trunk/BUGS: |
| 17:19.11 |
CIA-32 |
BRL-CAD:
Added that rtedge works correctly in non-perspective mode, but
still incorrect in |
| 17:19.12 |
CIA-32 |
BRL-CAD:
low-res perspective modes |
| 17:31.06 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 17:39.50 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:55.50 |
jdoliner |
does anyone
know why this is segfaulting?: |
| 17:56.04 |
jdoliner |
ON_SimpleArray<ON_Polyline>
answer; |
| 17:56.27 |
jdoliner |
ON_Polyline
initial_segment = ON_Polyline(); |
| 17:56.27 |
jdoliner |
initial_segment.Append(segments.First()->from); |
| 17:56.27 |
jdoliner |
initial_segment.Append(segments.First()->to); |
| 17:56.27 |
jdoliner |
answer.Append(initial_segment); |
| 18:17.48 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 18:50.22 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 18:54.21 |
brlcad |
jdoliner: not
without a debugger |
| 18:54.51 |
jdoliner |
yeah I
figured it out |
| 18:57.00 |
jdoliner |
weird thing
during the initialization that was causing it to try to extend the
array |
| 20:09.25 |
CIA-32 |
BRL-CAD:
03indianlarry * r34875 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/primitives/brep/brep.cpp): |
| 20:09.25 |
CIA-32 |
BRL-CAD:
changed tolerance on vertical trim check; added near hit/miss logic
to shotline cleanup |
| 20:09.29 |
CIA-32 |
BRL-CAD: but
still WIP |
| 20:55.30 |
*** join/#brlcad stevegt_1
(n=stevegt@cislunar.TerraLuna.Org) |
| 20:57.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 21:27.58 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DAA2.dip.t-dialin.net) |
| 21:35.22 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:53.10 |
*** join/#brlcad m03sizlak
(n=x0100100@pool-98-117-160-192.bflony.fios.verizon.net) |
| 21:53.43 |
m03sizlak |
i need a high
quality 3d model of manhattan |
| 21:54.59 |
Ralith |
starseeker:
thanks for the participation in the thread |
| 22:39.48 |
starseeker |
Ralith: well,
I don't know if it accomplished anything :-/ |
| 22:40.05 |
starseeker |
figured if it
was active it might attract more attention |
| 22:40.08 |
Ralith |
starseeker:
at the very least, it held the attention of someone
knowledgable. |
| 22:40.12 |
Ralith |
yeah. |
| 22:40.31 |
Ralith |
and answered
an important question |
| 22:42.29 |
starseeker |
hmm, I can't
get the forums to come up - have there been more
replies? |
| 22:43.21 |
Ralith |
nothing of
interest, unless you count my own recent post explaining why I'd
rather like to make things work within the current
setup |
| 22:43.47 |
starseeker |
ah, there we
go. |
| 22:43.48 |
Ralith |
and
simplifying the question down to two simple queries |
| 22:44.32 |
Ralith |
if only there
was some simple way to log all OpenGL calls g3d as a whole
makes |
| 22:45.13 |
Ralith |
that way we
could see what Qt does to get the context back to a usable state
after an Ogre render call |
| 22:45.24 |
Ralith |
and isolate
Qt's own rendering for test purposes |
| 22:45.40 |
starseeker |
hmm: http://www.opengl.org/sdk/tools/GLIntercept/
? |
| 22:46.21 |
Ralith |
windows
only. |
| 22:46.32 |
Ralith |
I don't have
any windows devboxes |
| 22:46.43 |
Ralith |
perhaps I
could get someone to log it for me? |
| 22:47.38 |
Ralith |
brb |
| 22:47.47 |
starseeker |
http://www.hawksoft.com/gltrace/
claims to have preliminary Linux support |
| 22:48.21 |
Ralith |
worth a
try |
| 22:48.44 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D386.dip.t-dialin.net) |
| 22:49.04 |
starseeker |
http://graphics.stanford.edu/courses/cs448a-01-fall/glsim.html |
| 22:50.23 |
Ralith |
NOTE: trace
doesn't seem to work with Linux NVIDIA OpenGL drivers. If you need
to make a trace on Linux, use a Linux machine with Mesa
drivers. |
| 22:50.26 |
Ralith |
>:/ |
| 22:50.28 |
starseeker |
http://www.opengl.org/sdk/tools/BuGLe/ |
| 22:50.46 |
Ralith |
oh
nice |
| 22:51.20 |
starseeker |
GPL, but
usable as a tool I would think (brlcad?) |
| 22:51.26 |
Ralith |
certainly |
| 22:51.28 |
Ralith |
gcc is GPL,
after all |
| 22:51.46 |
starseeker |
nods - this is for debugging, not for inclusion
anyhow |
| 22:52.01 |
Ralith |
grabs some lunch |
| 22:54.54 |
starseeker |
old, but
maybe useful? http://spyglass.sourceforge.net/ |
| 22:55.52 |
brlcad |
m03sizlak:
and I need a high quality model of a lightcycle and a replicator
;) |
| 22:56.44 |
starseeker |
Ralith: yeah,
it's looking like most roads lead to BuGLe |
| 22:57.11 |
brlcad |
okay to use
during development, it's not being integrated |
| 22:57.23 |
brlcad |
there's also
a very powerful opengl debugger on the mac |
| 22:57.43 |
brlcad |
part of the
performance tools |
| 22:58.42 |
brlcad |
still, you
should be able to back down to basic qt tests first without having
to worry about opengl calls |
| 23:16.51 |
Ralith |
brlcad: basic
qt tests like what? |
| 23:17.10 |
Ralith |
I've already
confirmed that everything works, even rendering OpenGL stuff, when
Ogre isn't called. |
| 23:17.27 |
Ralith |
(including
rendering Qt widgets, if that wasn't clear) |
| 23:17.30 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 23:17.52 |
starseeker |
what about
setting up the "bad" condition (Ogre having futzed up the
rendering) and walk through the Qt cycle that restores
it? |
| 23:18.01 |
Ralith |
starseeker:
that's what I was planning to do. |
| 23:18.05 |
starseeker |
nods |
| 23:18.14 |
Ralith |
only, save a
lot of time by stripping it down to just the OpenGL
calls. |
| 23:18.23 |
Ralith |
I guess I
could grab a source checkout of Qt and do it the other way,
though |
| 23:18.34 |
Ralith |
might lead to
a tidier fix. |
| 23:18.41 |
starseeker |
would recommend that, actually |
| 23:18.54 |
starseeker |
awareness of
Qt source code will probably be a requirement sooner or
later... |
| 23:19.16 |
starseeker |
eyes the Tcl/Tk trees living in src/other |
| 23:20.14 |
Ralith |
let's not
intern Qt |
| 23:20.18 |
Ralith |
:P |
| 23:20.42 |
starseeker |
heh
:-) |
| 23:20.52 |
starseeker |
well, the
chips will fall where they need to |
| 23:22.40 |
Ralith |
I'm certainly
not checking it in myself after that Ogre mess. |
| 23:22.48 |
starseeker |
hehe |
| 23:23.14 |
starseeker |
if it has to
be checked in, I'll take a stab at it - only if we need to
though |
| 01:52.31 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 07:34.47 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 08:51.36 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1514 10/wiki/User:Ralith: Log for 2009-06-28 |
| 09:42.12 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1096600584.dsl.bell.ca) |
| 11:14.14 |
d-lo |
merinin
all! |
| 11:17.53 |
d-lo |
Ralith: How
goes the conflict resolution? |
| 11:30.30 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 11:37.41 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FD98.dip.t-dialin.net) |
| 13:11.28 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 13:13.31 |
CIA-32 |
BRL-CAD:
03ebautu * r34893
10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (. brlcad.info
brlcad.install brlcad.module): BRL-CAD integration module (initial
commit) |
| 13:44.22 |
brlcad |
hi
elena! |
| 13:44.27 |
brlcad |
welcome
back |
| 13:44.29 |
elena |
hi. |
| 13:44.32 |
elena |
thank
you. |
| 13:44.40 |
brlcad |
have a good
trip? |
| 13:44.44 |
elena |
yes. |
| 13:44.55 |
elena |
I was just
about to ask some help here :) |
| 13:45.02 |
elena |
but first,
how are you? |
| 13:52.05 |
brlcad |
i'm doing
great, had a fantastic weekend |
| 13:52.28 |
elena |
wonderfull.
I'm glad to hear that. |
| 13:52.45 |
brlcad |
wonderful
wine tasting event and dinner with friends on saturday, latino
festival on sunday :) |
| 13:53.03 |
elena |
that sounds
very nice. |
| 13:53.24 |
elena |
what kind of
festival? |
| 13:53.42 |
elena |
I mean:
dancing, food, etc? |
| 13:53.45 |
brlcad |
yeah |
| 13:53.56 |
elena |
ok. |
| 13:54.14 |
brlcad |
concerts
going, lots of great food, music, dancing |
| 13:54.40 |
brlcad |
the wine
tasting was aboslutely spectacular, a real highlight |
| 13:54.41 |
elena |
in your town
or traveling? |
| 13:54.54 |
brlcad |
in
baltimore |
| 13:56.27 |
elena |
do you have
time to give me some tips on raytraceing models? |
| 13:57.46 |
brlcad |
sure, is this
for generating pictures? |
| 13:58.02 |
elena |
yes. |
| 13:58.25 |
elena |
I'm not sure
if I should use mged and the rt command |
| 13:58.35 |
brlcad |
that's
probably the best way |
| 13:58.36 |
elena |
or only the
rt tool. |
| 13:58.48 |
elena |
ok. then I
know how to do it. |
| 13:58.55 |
brlcad |
running
through mged will make it a little easier to set up the
view |
| 13:59.03 |
elena |
yes.
exactly. |
| 13:59.09 |
elena |
another
problem. |
| 13:59.59 |
elena |
is there a
way to setup the view size so that it best fits the
model? |
| 14:00.09 |
brlcad |
heh |
| 14:00.14 |
brlcad |
was just going to comment on that |
| 14:00.16 |
brlcad |
yes and
no |
| 14:00.24 |
brlcad |
the
'autoview' command fits the model to the view |
| 14:00.33 |
brlcad |
but it does a
guarantee fit, not necessarily a best fit |
| 14:00.43 |
elena |
that's
ok. |
| 14:00.50 |
brlcad |
you'll
probably want to run "zoom 2" on everything being
rendered |
| 14:00.51 |
elena |
i didn't know
about autoview. |
| 14:01.05 |
elena |
ok. i'll do
some tests. |
| 14:01.17 |
brlcad |
if there is
nothing displayed, and you 'draw'/'e' something up, it'll autoview
automatically |
| 14:01.26 |
elena |
i tried some
hacks with grouping objects. not very successful. |
| 14:02.13 |
elena |
and I was
thinking to do something like: |
| 14:02.16 |
elena |
draw
* |
| 14:02.20 |
brlcad |
oh,
no |
| 14:02.23 |
elena |
rt -o
model.pix |
| 14:02.24 |
brlcad |
don't do that
:) |
| 14:02.28 |
elena |
why? |
| 14:02.37 |
brlcad |
"draw *" is
very bad |
| 14:02.39 |
elena |
and what's
the alternative. |
| 14:02.47 |
elena |
? |
| 14:03.08 |
brlcad |
that means
draw every single object and shape in the database |
| 14:03.09 |
elena |
because it
draws all objects? |
| 14:03.20 |
elena |
yes. |
| 14:03.29 |
elena |
what's the
alternative? |
| 14:03.52 |
elena |
so I have a
database that the user uploaded. |
| 14:04.09 |
elena |
and I want to
get the images from different angles. |
| 14:04.22 |
brlcad |
so if the
objects were text, and a word is a union of the letters, and a
phrase is a grouping of multiple words, like "Hello
world" |
| 14:04.31 |
elena |
I'll use ae
to set the angle, autoview to fit the object. |
| 14:05.06 |
elena |
go
on... |
| 14:05.28 |
brlcad |
saying "draw
*" is effectively, "draw H", "draw e", "draw l", "draw l", "draw
o", "draw ' '", "draw Hello", "draw world", "draw Hello
world" |
| 14:06.05 |
brlcad |
it's
everything including all uses and groupings .. not what you want,
you want just the last one "draw Hello world" |
| 14:07.00 |
brlcad |
moreover with
brl-cad geometries, our format supports an arbitrary number of
models per file, so there could be lots of 'main' objects, not
necessarily just one |
| 14:07.18 |
brlcad |
to find a
starting point, you run the "tops" command |
| 14:07.22 |
brlcad |
that lists
the top-level objects |
| 14:07.41 |
brlcad |
normally, one
or more of those is a primary |
| 14:07.57 |
elena |
and draw
that. |
| 14:08.01 |
elena |
ok. makes
sence. |
| 14:08.01 |
brlcad |
right |
| 14:08.22 |
elena |
can I do draw
and tops in one command? |
| 14:08.33 |
elena |
something
like draw `tops` ? |
| 14:08.40 |
brlcad |
you can, but
you also don't want that |
| 14:08.45 |
elena |
i think I
can. I'll look. |
| 14:08.49 |
brlcad |
that would
imply they had something to do with each other |
| 14:08.52 |
elena |
no?
why? |
| 14:09.02 |
brlcad |
they're
top-level because they are independent |
| 14:09.05 |
elena |
you're
reading my thoughts before I type :) |
| 14:09.21 |
brlcad |
.g files are
collections of trees of geometries. |
| 14:09.35 |
brlcad |
there may be
one tree, there may be twenty trees |
| 14:09.48 |
elena |
how would you
approach this? |
| 14:09.48 |
brlcad |
you've seen
the example .g files, yes? |
| 14:09.53 |
elena |
yes. |
| 14:10.17 |
brlcad |
I could very
trivially combine them all into one single .g file and it would be
perfectly valid |
| 14:10.34 |
brlcad |
there'd just
be a lot of top-level objects |
| 14:10.52 |
elena |
that will
alter the db, too, right? |
| 14:11.01 |
brlcad |
what do you
mean? |
| 14:12.01 |
brlcad |
i mean those
20+ separate files are only separated by convention, I could
combine them together and it's a valid .g |
| 14:12.13 |
elena |
in mged. if I
do a group. |
| 14:12.30 |
elena |
that group
will instantly be saved in the database. |
| 14:12.34 |
brlcad |
i mean
literally, you can "cat *.g > everything.g" .. bad thing to do,
but entirley valid |
| 14:12.51 |
elena |
I didn't know
that. |
| 14:13.05 |
brlcad |
creating a
group in mged is a different thing altogether -- that basically
creates a new top-level object |
| 14:13.13 |
brlcad |
and if the
things you're grouping were top-level, they no longer
are |
| 14:13.50 |
brlcad |
it's a set of
directed acyclic graphs, with named references |
| 14:14.04 |
elena |
but in our
case, the user will upload only one file. |
| 14:14.22 |
brlcad |
one _file_ ..
but that file could be anything |
| 14:14.34 |
elena |
cool. let me
play some more with what you told me and I'll get back. |
| 14:14.43 |
*** join/#brlcad mafm
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 14:14.44 |
brlcad |
so you're
going to have to either just import all top-level
objects |
| 14:14.52 |
elena |
i'll buzz you
or cliff some more if I don't manage it myself. |
| 14:14.54 |
brlcad |
or have the
user specify which object to import |
| 14:15.28 |
brlcad |
you
definitely should not be creating groups or geometry |
| 14:15.43 |
elena |
yes. I
imagine that. |
| 14:16.03 |
elena |
this is why I
was looking for the autoview-style solution also. |
| 14:16.19 |
brlcad |
for safety,
you may even want to store the files as read-only, 444 or
something |
| 14:16.43 |
elena |
i'll look
into that, too. |
| 14:17.18 |
elena |
i think i
lost some time trying to make a lot of customizations that proved
not that important. |
| 14:17.33 |
elena |
on the
processing queue part. |
| 14:17.57 |
elena |
but they led
to a simpler solution :) |
| 14:18.01 |
brlcad |
here's a good
example, if you look at the havoc.g example file .. and run
tops |
| 14:18.07 |
brlcad |
you'll see
there are three top-level objects |
| 14:18.16 |
brlcad |
BRL-GSI_EFFORT/ havoc/
sun/R |
| 14:18.45 |
brlcad |
you don't
know which of those is important without asking the
user |
| 14:19.03 |
brlcad |
so you either
import all three, or have the user prompt (in this case, havoc is
the important one) |
| 14:19.28 |
brlcad |
prompting is
probably best as the important object is often not even a
top-level |
| 14:19.48 |
elena |
but if i have
a different format |
| 14:19.51 |
brlcad |
the m35.g
file is another good example |
| 14:20.09 |
elena |
then that
might not have objects in it. |
| 14:20.14 |
brlcad |
8 top-level
objects: 2 assemblies, 2 primitives, 4 regions |
| 14:20.41 |
brlcad |
all formats
have at least one object in them :) |
| 14:21.02 |
brlcad |
it's just
many are actually contrained to exactly one object, |
| 14:21.16 |
elena |
what is
_GLOBAL? |
| 14:21.19 |
brlcad |
like the stl
file format, one object |
| 14:21.24 |
brlcad |
it's a
non-geometric object |
| 14:21.30 |
brlcad |
file
attributes |
| 14:21.40 |
elena |
aha. |
| 14:21.44 |
brlcad |
stores things
like title and the working units |
| 14:21.52 |
elena |
ok. thank you
for your help. |
| 14:23.21 |
brlcad |
no problemo,
keep the questions coming |
| 14:23.57 |
elena |
:) |
| 14:34.21 |
mafm |
hi |
| 14:34.54 |
elena |
hi |
| 14:36.35 |
brlcad |
hi |
| 14:47.14 |
*** join/#brlcad Ralith_
(n=ralith@216.162.199.202) |
| 14:47.24 |
starseeker |
hey
elena |
| 14:47.39 |
elena |
hi
starseeker. |
| 14:47.46 |
d-lo |
hi! |
| 14:47.52 |
starseeker |
welcome back
:-) |
| 14:47.57 |
elena |
thank you
:) |
| 14:48.13 |
elena |
how have you
been? |
| 14:48.26 |
elena |
hi
d-lo. |
| 14:51.48 |
d-lo |
WIth all this
greeting action happening, I just had to get in on it. |
| 14:51.58 |
starseeker |
would actually recommend requiring the user to specify at
least one named "primary" db object, or example, or something like
that |
| 14:52.02 |
elena |
:)) |
| 14:53.33 |
starseeker |
or, since
user laziness usually wins, grab the tops list, generate some
default raytraces, and present them a list of images asking them to
select the correct toplevel images |
| 14:53.40 |
elena |
will that
work with other formats, too? |
| 14:53.51 |
starseeker |
hard to
say |
| 14:54.28 |
brlcad |
that'll for
for most all formats simply because we're a superset
format |
| 14:54.30 |
starseeker |
logically
speaking, the first thing to check is whether there is a toplevel
object named <filename> if the file is called
filename.g |
| 14:54.44 |
elena |
what would be
the purpose of creating a top object if you don't use it in the
final render? |
| 14:54.46 |
starseeker |
(e.g. havoc
in havoc.g) |
| 14:55.06 |
starseeker |
sometimes you
want to quickly show different aspects of a design |
| 14:55.17 |
brlcad |
starseeker:
that's more the exception than the rule, depends which org/person
is modeling |
| 14:55.39 |
brlcad |
for a decade,
the convention was to group your primary into an "all.g"
object |
| 14:55.59 |
starseeker |
models can
get very complex, and if you want to show someone just "this part,
this part, and this part" multiple times in different situations
it's a quick and easy way to have it available |
| 14:56.16 |
starseeker |
brlcad:
that's unfortuante, really - it would be a very logical
convention |
| 14:57.18 |
starseeker |
elena: then
in that case I'd suggest presenting the user with visuals of the
top level objects and let them tell you which ones to pay attention
to :-/ |
| 14:57.56 |
elena |
ok. i'll try
to do that. |
| 14:58.20 |
elena |
then
submitting has to be a two step process. |
| 14:58.25 |
brlcad |
starseeker:
remember the filename can vary drastically (stryker_dlo_20040329.g)
too .. I wouldn't assume anything based on filename |
| 14:58.37 |
brlcad |
you can't
even really assume it's a top-level you want, but that's a good
starting point |
| 14:58.45 |
elena |
first submit
the file, then (next step) select the object names. |
| 14:58.47 |
brlcad |
elena: what
you could do is simply show them the hierarchy |
| 14:58.50 |
brlcad |
let them pick
the point |
| 14:59.03 |
brlcad |
for simple
formats, it's just an object, or list of objects |
| 14:59.06 |
d-lo |
will ignore the stryker comment... :P |
| 14:59.26 |
brlcad |
for
hierarchical formats, you display a collapsed tree |
| 14:59.54 |
elena |
maybe
multiple select? |
| 14:59.58 |
brlcad |
sure |
| 15:00.03 |
elena |
ok. |
| 15:00.07 |
brlcad |
but selecting
selects that entire subtree |
| 15:00.15 |
elena |
yes. |
| 15:00.46 |
brlcad |
hm, actually
there's no real need to impose that limitation .. it's just
whatever nodes they select |
| 15:01.22 |
elena |
yes. it's
more in tone with the hello world example :) |
| 15:03.23 |
brlcad |
chuckles that dlo is the name of an ipod/iphone accessory
manufacturer, particularly in the context of
stryker |
| 15:03.38 |
brlcad |
and then
there's the stryker sonoma winery ;) |
| 15:04.46 |
d-lo |
wha.... I'm
getting a lawyer! They stolededed my irc handle! |
| 15:18.44 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 15:34.34 |
starseeker |
d-lo: so with
a lawyer, you'll be both broke and annoyed rather than just
annoyed? ;-) |
| 15:35.26 |
d-lo |
lol nice.
unless... wait a minute.... a close relative ISA lawyer and owes me
a favor.... hrm..... |
| 15:36.30 |
d-lo |
visualizes himself standing ontop of a burning, ruined
building which use to be 'dlo HQ - makers of iPhone/iPod
accessories"... |
| 15:38.06 |
``Erik |
heh, 'cept
dlo.com is a subsidiary of phillips |
| 15:38.33 |
d-lo |
orly?
Phillips wants some too eh? |
| 15:38.38 |
``Erik |
imagines they might have a bit of legal flex :D plus going
back to '01 |
| 15:39.37 |
d-lo |
i can see it
now on /. : Philips Legal dept gets omgwtfpwnd by loudmouth
government employee.... |
| 15:39.44 |
d-lo |
=D |
| 15:40.42 |
``Erik |
given the
accuracy of /. headlines and summaries, that might be
posted |
| 15:41.12 |
``Erik |
that bug
totally owned that speeding car, look at that ugly greasemark on
the grill! PWN3d!#~@ |
| 15:41.38 |
louipc |
why not just
ask the user what object he/she wants to use for the preview
pic? |
| 15:42.13 |
starseeker |
still has not forgiven slashdot for that premature/wrong
announcement of the original Apollo 11 tapes turning
up |
| 15:42.22 |
starseeker |
talk about a
letdown... |
| 15:42.34 |
louipc |
hah |
| 15:43.26 |
starseeker |
bets they were erased and re-used - sounds just like "policy"
on such tapes... heck with history, it's the policy and we're
following it |
| 15:43.33 |
d-lo |
lol |
| 15:44.15 |
d-lo |
at the
viewing of those Apollo 11 tapes, somehow pron ends up on the
overhead screen....lol |
| 15:44.30 |
starseeker |
that really
does suck big time - one of the great events in the history of
human beings AS A SPECIES and they went missing |
| 15:44.31 |
``Erik |
was just thinking that o.O |
| 15:44.34 |
starseeker |
cries |
| 15:45.09 |
d-lo |
starseeker:
didn't you hear? thats tnhe main reason we are going back in
2020... gotta remake the tapes. |
| 15:45.13 |
``Erik |
"houston,
apogee attained, now firin*TSSHT* uhh uhhh uhhh oh yeah
uhhh" |
| 15:45.33 |
d-lo |
Apollo 11...
is that a funky saxaphone? |
| 15:45.53 |
louipc |
yeah you'd
think they'd save something like that |
| 15:46.33 |
starseeker |
still wants to figure out some way to spend a decade or two
with the Saturn V technical archives and a wide format scanner in
his retirement years... |
| 15:47.06 |
``Erik |
and then
model it down to the bolt threads? |
| 15:47.24 |
starseeker |
you got
it |
| 15:47.40 |
d-lo |
...for the
hallibut? |
| 15:48.00 |
``Erik |
biggest
cadpeen ever |
| 15:49.12 |
starseeker |
thinks such an accomplishment is worth documenting in
detail |
| 15:49.45 |
louipc |
well, it's on
paper :D |
| 15:49.57 |
starseeker |
louipc: my
point exactly :-/ |
| 15:50.32 |
``Erik |
paper isn't
what it used to be, 60's paper and ink are probably already in bad
shape :/ |
| 15:50.38 |
starseeker |
and
everything I've see suggests that the filing system used is
probably.... well... I guess we'll got with inadequate |
| 15:50.48 |
``Erik |
acidic paper
eats itself up |
| 15:50.52 |
``Erik |
ask tufte
O.o |
| 15:51.25 |
louipc |
so this is
something you probably want to do now, rather than wait for
retirement... |
| 15:52.39 |
starseeker |
louipc: I
have no clue how to get the funding it would take to do that, even
assuming they would let me... |
| 15:53.53 |
starseeker |
plus, I've
got a few things to do first :-) |
| 15:54.07 |
starseeker |
doesn't want to model a Saturn V with mged as a
modeler... |
| 15:54.24 |
louipc |
haha |
| 15:54.41 |
louipc |
yeah but the
scanning will be enough work |
| 15:54.51 |
starseeker |
that's for
sure |
| 15:55.02 |
d-lo |
modling it by
hand would be faster :) |
| 15:55.17 |
d-lo |
holey bad
speling dai batman... |
| 15:55.26 |
``Erik |
sure you do,
perfect way to isolate usability issues in the interface and fix
'em :D |
| 15:56.21 |
starseeker |
the stages
would be 1. high res scan every sheet of paper related 2. invent an
organizational scheme that would actually work and sort everything
into it 3. recruit the internet to make svg versions of the 2d
drawings so you can actually work with 'em 4. cad model that
baby |
| 15:56.26 |
brlcad |
starseeker:
more than likely, it's like our taps -- there's a bigass stack of a
couple hundred sitting off in some room, maybe a summer intern or
two worked on archiving, but mostly still gestating |
| 15:56.41 |
brlcad |
s/taps/tapes/ |
| 15:56.58 |
``Erik |
crowdsourcing, pheer |
| 15:57.00 |
starseeker |
brlcad:
fingers crossed - if that's the case they might yet be
found |
| 15:57.44 |
brlcad |
I doubt
they're actually "lost" .. there's probably just only two or three
people that know where they're at, just like ours :) |
| 15:57.58 |
``Erik |
heh |
| 15:57.59 |
starseeker |
``Erik:
inkscape + 2000 space nerds with no social life - that's a force to
be respected ;-) |
| 15:58.36 |
starseeker |
expensive
part is a wide format scanner plus the manhours of scanning
required |
| 15:59.04 |
starseeker |
wonders why he didn't think of trying to get that into the
stimulus bill... |
| 15:59.06 |
``Erik |
just a few
years ago, they found the french commission papers for the two
"english" ships captain kidd had taken, supposedly proof that he
was a legal privateer and not a pirate O.o misplaced media is a
bitch |
| 15:59.33 |
starseeker |
heh |
| 15:59.55 |
``Erik |
hung because
someone misfiled a paper |
| 15:59.59 |
louipc |
you have to
get into NASA before step 1 |
| 16:00.20 |
starseeker |
louipc:
actually, their records are part of the public archives now (at
least from that era) |
| 16:00.24 |
starseeker |
some of them,
anyway |
| 16:00.32 |
louipc |
oh
cool |
| 16:01.22 |
starseeker |
check out
this dude's site: http://www.ibiblio.org/apollo/ |
| 16:02.00 |
``Erik |
nasa doesn't
have the budget or impetus to be very secretive O.o they mostly use
russian agencies for lifting these days heh |
| 16:03.12 |
starseeker |
specifically,
http://www.ibiblio.org/apollo/QuestForInfo.html |
| 16:04.26 |
starseeker |
he's done
some Really Impressive Work digging up info |
| 16:05.06 |
starseeker |
the
government archives are beyond doubt repositories of lots of really
neat historical treasures that nobody knows how to find and nobody
cares enough to sort through |
| 16:10.59 |
``Erik |
shoulda brought in a tv dinner |
| 16:13.16 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:14.25 |
jdoliner |
sean slash
indianlarry, or anyone else who's interested. Would you be help me
with an algorithm here? |
| 16:14.35 |
jdoliner |
I'm kind of
stuck |
| 16:15.19 |
``Erik |
what
algo? |
| 16:15.59 |
jdoliner |
unfortunately
I don't have the name so I'll have to describe it |
| 16:16.12 |
``Erik |
psuedocode in
pastebin? |
| 16:16.26 |
jdoliner |
pastebin? |
| 16:16.51 |
jdoliner |
it's more I
need help devising the algorithm |
| 16:16.56 |
``Erik |
http://pastebin.bzflag.bz/ |
| 16:16.59 |
``Erik |
ah,
ok |
| 16:17.06 |
``Erik |
shuts up and listens |
| 16:18.15 |
jdoliner |
so I have my
code all setup to take two meshes, and return as polylines the
trimming curves between them |
| 16:19.06 |
jdoliner |
so that's
nice and all but know I need to talk that polyline and use it to
split each mesh into two meshes, the one inside the other mesh and
the one outside |
| 16:19.11 |
jdoliner |
and
I' |
| 16:19.14 |
jdoliner |
m not
sure |
| 16:19.21 |
jdoliner |
of the best
way to do that |
| 16:19.36 |
jdoliner |
do you think
it's a better idea to do it afterward using the
polyline |
| 16:20.10 |
``Erik |
by "mesh",
you don't mean a mesh, but a NURBS, right? |
| 16:21.22 |
jdoliner |
no I mean an
ON_Mesh |
| 16:21.52 |
jdoliner |
it's still
discrete geometry at this point and not parametric |
| 16:21.53 |
``Erik |
painkillers
have me fuzzy, here, I'll throw something at the back of
indianlarrys head |
| 16:22.33 |
``Erik |
if it's
triangles, any line cutting through a triangle will produce 2
triangles... I d'no ON_Mesh |
| 16:22.46 |
indianlarry |
hey
joe |
| 16:22.48 |
jdoliner |
it's
triangles or quads |
| 16:22.49 |
jdoliner |
hi |
| 16:23.02 |
indianlarry |
catchin
up... |
| 16:23.27 |
jdoliner |
but lines
don't necessarily cut all the way through on a triangle |
| 16:23.36 |
``Erik |
(wait, some
lines will produce a quad, but those can be broken into two
triangles) |
| 16:23.46 |
jdoliner |
yeah |
| 16:24.18 |
jdoliner |
but you could
also have a triangle broken up by not just one line but a whole
bunch of little lines |
| 16:24.37 |
jdoliner |
if for
example one mesh has much smaller details than the
other |
| 16:25.22 |
``Erik |
by casting
vertex to vertex, you can cut polygons into triangles |
| 16:26.32 |
``Erik |
do it
recursively and you have a fully triangulated mesh *shrug* but the
vicodin has me goofy, indianlarry will come up with something
brilliant here... |
| 16:26.33 |
jdoliner |
yes, on of my
ideas involves doing that |
| 16:27.24 |
indianlarry |
definitely
need resolution to capture the smallest details |
| 16:27.51 |
indianlarry |
we are
currently working similar issue with nurbs trims |
| 16:27.54 |
``Erik |
(mebbe an
aggressive splitting algo followed by a decimation
pass?) |
| 16:28.07 |
jdoliner |
no I'm
not |
| 16:28.30 |
jdoliner |
oh you are
sry |
| 16:28.48 |
jdoliner |
so here's my
one idea which I think could work |
| 16:29.19 |
jdoliner |
right now I
have it all setup to find every intersection line |
| 16:29.28 |
jdoliner |
load it into
an array |
| 16:29.45 |
jdoliner |
and then at
the end it goes through and reconstructs these into the
polylines |
| 16:30.05 |
jdoliner |
now instead
of doing exactly that |
| 16:30.39 |
jdoliner |
I can keep
track of which faces the lines came from |
| 16:31.09 |
jdoliner |
by loading
them into arrays for each face |
| 16:31.16 |
indianlarry |
i would think
you'd want to track which face it belongs too |
| 16:32.17 |
indianlarry |
need to
remember that trimming edges within a face have to show
direction/inner/outer |
| 16:32.18 |
jdoliner |
yeah then
when I run my algorithm on the lines from each seperate face. I get
a polyline that indicates exactly how each face should be split
up |
| 16:32.31 |
jdoliner |
yes that's my
question |
| 16:32.35 |
jdoliner |
how should I
do that |
| 16:32.37 |
jdoliner |
? |
| 16:33.04 |
indianlarry |
just thinking
out loud |
| 16:33.43 |
jdoliner |
well I can
test points for being inside or outside the meshes |
| 16:33.46 |
indianlarry |
if your
intersection coisides with an outer edge at any point the
intersection becomes an outer edge ? |
| 16:33.58 |
indianlarry |
sorry
coincides |
| 16:34.17 |
jdoliner |
sry I don't
follow |
| 16:34.23 |
jdoliner |
waht do you
mean by outer edge |
| 16:34.24 |
jdoliner |
? |
| 16:34.56 |
indianlarry |
guess your
working with simple faces which only have an outer
trim? |
| 16:35.05 |
jdoliner |
yeah |
| 16:36.10 |
indianlarry |
a corner
intersecting a face could still produce an inner loop? |
| 16:36.28 |
jdoliner |
yes |
| 16:38.10 |
jdoliner |
so one option
that I see |
| 16:38.31 |
jdoliner |
is that I can
pretty easily test a point for being inside our outside a
mesh |
| 16:38.52 |
jdoliner |
it just takes
linear time with the number of triangles |
| 16:39.07 |
jdoliner |
(which is
kinda big) |
| 16:39.14 |
jdoliner |
but once I
have that point |
| 16:39.20 |
jdoliner |
then anything
that's connected to it |
| 16:40.18 |
jdoliner |
is also on
the same side of the mesh |
| 16:41.45 |
jdoliner |
so we would
really only need to do one point per connected region which isn't
so unreasonable |
| 16:43.24 |
indianlarry |
do brep
meshes have trim loops or do they just get subdivided into smaller
meshes |
| 16:44.15 |
jdoliner |
they do not
have trim loops |
| 16:44.29 |
indianlarry |
okay |
| 16:47.58 |
indianlarry |
you'd thnk
there wold be a way to track edge direction to help out
here |
| 16:49.11 |
indianlarry |
ust keep
visualizing the corner into the center of a face
problem |
| 16:50.39 |
jdoliner |
k, will
do |
| 16:50.48 |
indianlarry |
each facet or
quad has defined outward pointing normal? |
| 16:51.08 |
jdoliner |
yes, by right
hand rule |
| 16:51.35 |
jdoliner |
hmm |
| 16:51.58 |
jdoliner |
I think I
need to look back at my lower level functions |
| 16:52.41 |
indianlarry |
each facet or
quad that is intersected could then be subdivided into inside
outside? |
| 16:52.48 |
jdoliner |
I bet that
they consistantly indicate something with the direction the
resultant edge points |
| 16:53.07 |
indianlarry |
thats how
they do it with the nurbs trims |
| 16:54.21 |
indianlarry |
you could
almost create your own polyline trimming loops |
| 16:56.00 |
jdoliner |
yeah I think
I can |
| 16:56.08 |
jdoliner |
I mean I
think that's what my code in the present state does |
| 16:56.26 |
indianlarry |
need to keep
the loops by face then inner/outter |
| 16:57.11 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 16:58.08 |
jdoliner |
oh here's an
interesting fact: |
| 16:58.51 |
jdoliner |
if we
intersect triangles abc and def |
| 16:59.37 |
jdoliner |
then the dot
product of (d-a) and the normal of abc is positive if d is on the
external side of abc |
| 17:03.06 |
indianlarry |
just tells
you which side d is on holds for any point |
| 17:05.29 |
jdoliner |
yeah, it only
indicates ternality if there's nothing intersecting def between the
line that abc leaves and d |
| 17:08.58 |
indianlarry |
if you store
the intersect polyline by face you should be able to use it with
right-hand-rule to subdivide you facets/mesh |
| 17:10.00 |
indianlarry |
if polyline
intersects face edge its an outer type loop otherwise an inner
loop |
| 18:01.30 |
CIA-32 |
BRL-CAD:
03irpguardian * r34894
10/brlcad/trunk/src/proc-db/human.c: |
| 18:01.30 |
CIA-32 |
BRL-CAD:
Added needed data to allow poseable left arm, with connected parts
and joints. |
| 18:01.33 |
CIA-32 |
BRL-CAD:
Bounding boxes for those limbs have been removed until a better
method is devised. |
| 18:05.56 |
*** join/#brlcad _sushi_
(n=_sushi_@80-218-237-16.dclient.hispeed.ch) |
| 18:26.11 |
CIA-32 |
BRL-CAD:
03homovulgaris * r34895 10/brlcad/trunk/src/libged/cc.c: cc : input
from commandline rather than hardcoded data |
| 19:00.25 |
CIA-32 |
BRL-CAD:
03brlcad * r34896 10/brlcad/trunk/src/mged/Makefile.am: we needed
the mged_LINK in order to override LDFLAGS when we had a custom tk,
but that's not the case any longer. problem came up where we needed
one of the globally set LDFLAGS. |
| 19:04.34 |
CIA-32 |
BRL-CAD:
03brlcad * r34897 10/brlcad/trunk/configure.ac: |
| 19:04.36 |
CIA-32 |
BRL-CAD:
apply a fugly workaround for the Mac OS X 10.5 linker problem
whereby it fails |
| 19:04.38 |
CIA-32 |
BRL-CAD:
saying 'ld: cycle in dylib re-exports with
/usr/X11/lib/libGL.dylib'. the |
| 19:04.42 |
CIA-32 |
BRL-CAD:
problem appears to be the glx internals making calls into the GL
framework, |
| 19:04.44 |
CIA-32 |
BRL-CAD:
which ends up finding the wrong (same) dylib during load. the 'fix'
is to tell |
| 19:04.49 |
CIA-32 |
BRL-CAD: it
exactly where the framework dylib lives, which is done via a
project-wide |
| 19:04.51 |
CIA-32 |
BRL-CAD:
LDFLAGS so we don't have to pollute all the places it would be
needed. |
| 19:44.04 |
CIA-32 |
BRL-CAD:
03brlcad * r34898 10/brlcad/trunk/BUGS: mged rotation halts after a
few events once a model is e'd up and you zoom in/out (at least
with mouse). seems to be specific to mac 10.5 |
| 19:45.25 |
CIA-32 |
BRL-CAD:
03brlcad * r34899 10/brlcad/trunk/BUGS: kill command (and probably
others) in archer is horked. |
| 20:07.56 |
CIA-32 |
BRL-CAD:
03brlcad * r34900 10/brlcad/trunk/BUGS: mged crashes inside
X_choose_visual() with default X11 libdm interface on mac os x 10.5
(fbserv seemed to be fine) |
| 20:56.41 |
CIA-32 |
BRL-CAD:
03irpguardian * r34901
10/brlcad/trunk/src/proc-db/human.c: |
| 20:56.42 |
CIA-32 |
BRL-CAD:
Created a new function for creating the entire left arm, allowing
for the arm to pivot |
| 20:56.44 |
CIA-32 |
BRL-CAD:
around the shoulder joint, and have all connected parts of the arm
point in the same |
| 20:56.46 |
CIA-32 |
BRL-CAD:
direction. |
| 21:33.33 |
elena |
how can I ran
multiple mged commands from the command line? |
| 21:33.56 |
elena |
something
like mged -cr something.g "tops;tops" |
| 21:37.31 |
elena |
I got
it. |
| 21:39.26 |
CIA-32 |
BRL-CAD:
03ebautu * r34902
10/web/trunk/htdocs/more/sites/all/modules/brlcad/brlcad.module:
Update BRL-CAD module (raytracing code is work in
progress). |
| 21:40.03 |
brlcad |
something
exactly like that |
| 21:40.43 |
elena |
i only got it
working with echo -e tops\\ntops | mged -cr something.g |
| 21:41.21 |
CIA-32 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1517 10/wiki/More_Changelog: /* June, 17 - today */ |
| 21:41.38 |
elena |
going to bed.
have a great afternoon. |
| 22:06.19 |
mafm |
uh |
| 22:06.34 |
mafm |
elena working
in raytracing code? |
| 22:07.02 |
louipc |
to generate
preview images for the model repository |
| 22:07.15 |
mafm |
oh |
| 22:07.30 |
mafm |
I was getting
worried about creating a raytracer in php or something
:P |
| 22:07.43 |
louipc |
bahhah |
| 22:08.05 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 22:08.14 |
mafm |
brl-cad web
on esteroids :P |
| 22:08.25 |
``Erik |
raytracer in
javascript, pheer |
| 22:10.57 |
mafm |
:D |
| 22:13.17 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FD98.dip.t-dialin.net) |
| 22:17.36 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 22:42.37 |
*** join/#brlcad CIA-30
(n=CIA@208.69.182.149) |
| 22:43.59 |
*** join/#brlcad alecs1
(i=alex@193.170.133.88) |
| 22:50.28 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 23:01.12 |
Ralith_ |
d-lo: I've
got several ideas, although my first hacks didn't pan
out. |
| 23:01.30 |
Ralith_ |
they're just
getting increasingly nontrivial and equally not guaranteed to
success |
| 23:03.38 |
``Erik |
anything
guaranteed to succeed is boring O.o d-lo probably won't see this
for another 12 hours or so, though |
| 23:10.09 |
Ralith |
true
enough |
| 23:11.16 |
louipc |
what is
guaranteed to success? |
| 23:15.28 |
``Erik |
bets he could write "hello world" and get it to compile the
very first time :D |
| 23:17.22 |
mafm |
``Erik: but
it will be buggy! http://www.ddj.com/hpc-high-performance-computing/217801225 |
| 23:18.03 |
``Erik |
that's too
much reading for me, I'm illiterate |
| 23:18.35 |
starseeker |
Ralith: have
you considered contacting the Qt folks to see if they can steer you
towards the parts working the reset magic? |
| 23:19.09 |
mafm |
(erm, page 2,
about errors of "hello world" programs in C) |
| 23:19.10 |
mafm |
:D |
| 23:19.28 |
starseeker |
might also be
a good opener if we need to propose some changes to include in the
next Qt |
| 23:19.39 |
mafm |
that's fine
``Erik, you just reminded me about the recently read
article |
| 23:19.52 |
Ralith |
starseeker: I
found lots of magic-looking code in QGraphicsView::render, but I'm
not sure I can use it without modifying Qt |
| 23:19.56 |
Ralith |
which seems
like a worst-case. |
| 23:20.05 |
``Erik |
who said C?
:D |
| 23:20.13 |
Ralith |
QGraphicsScene* |
| 23:20.43 |
Ralith |
then again,
perhaps I could simply introduce some redundancy... |
| 23:21.25 |
starseeker |
Ralith:
redundancy? |
| 23:21.50 |
Ralith |
starseeker:
the big block of setup code in the render function might be
practical to extract into the g3d code. |
| 23:21.58 |
starseeker |
ah |
| 23:22.06 |
starseeker |
might do for
a start, certainly |
| 23:22.12 |
starseeker |
especially if
it works ;-) |
| 23:22.13 |
Ralith |
my original
thought was to slightly rework Qt itself to do that without the
redundancy |
| 23:22.25 |
louipc |
haha
writeln |
| 23:22.27 |
Ralith |
but that'd
undesirable and I now realise perhaps unnecessary |
| 23:22.39 |
starseeker |
nods |
| 23:22.53 |
starseeker |
we've already
got Ogre back in svn, so that's the easier mod target to start
with |
| 23:23.19 |
Ralith |
and one of
the nice things about using Qt is that many already have it
installed; using a customized version negates that. |
| 23:24.00 |
starseeker |
I wouldn't be
afraid of redundancy at this stage - if it works we can try to work
with Qt/Ogre to find the "correct/pretty" way later |
| 23:24.31 |
Ralith |
yeah. |
| 23:24.47 |
starseeker |
drags self off to gym |
| 23:25.19 |
mafm |
``Erik:
probably the guy who wrote the article can find bugs in any other
languages, given the length of the "lecture" about errors in C
hello world programs :) |
| 23:29.43 |
``Erik |
O.o so, uh,
checking the return value of a function is... well... ALL of his
argument there? weak :) |
| 23:30.32 |
Ralith |
urgh. |
| 23:30.42 |
Ralith |
this init
code requires stuff only render knows about :/ |
| 23:54.08 |
``Erik |
yeesh, goblin
sharks are creepy |
| 00:25.54 |
alecs1 |
did I read Qt
here? an interface replacing mged written with Qt? |
| 00:26.24 |
alecs1 |
fabulous |
| 00:27.49 |
Ralith |
indeed |
| 00:27.53 |
Ralith |
if the
thing'll cooperate with ogre. |
| 00:30.14 |
alecs1 |
I wish you
best of luck then; found you brl wiki page with google |
| 00:30.20 |
alecs1 |
I'll keep an
eye on it |
| 00:30.28 |
alecs1 |
:) |
| 00:31.17 |
Ralith |
thanks |
| 00:50.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 01:40.21 |
*** join/#brlcad alecs1
(i=alex@193.170.135.37) |
| 02:09.30 |
*** part/#brlcad alecs1
(i=alex@193.170.135.37) |
| 02:35.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 04:12.44 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 05:27.03 |
*** join/#brlcad elena (n=elena@92.86.0.28) |
| 07:23.15 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 07:43.40 |
elena |
do you know
why mged outputs text to stderr when in console mode? |
| 07:43.46 |
elena |
i use
7.10.4 |
| 07:46.16 |
elena |
i ran mged
-cr something.g tops |
| 07:46.47 |
elena |
it displays:
Opened in READ ONLY mode and the top objects. |
| 07:46.58 |
elena |
but on
stderr. |
| 09:54.36 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DE16.dip.t-dialin.net) |
| 09:56.30 |
*** join/#brlcad mafm
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 10:07.14 |
*** join/#brlcad mafm_
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 11:06.13 |
d-lo |
Mornin all!
|
| 11:06.17 |
d-lo |
*READREADREAD* |
| 11:07.31 |
d-lo |
Ralith: Whats
the possibility of getting you to write up short blurbs about your
ideas/approaches and dropping them in your log on the
wiki? |
| 11:09.07 |
d-lo |
Ralith: I
haven't taken a look at your problem (in code) so I have no idea
how complex it would be to extend the Qt Class with the problem
with your own homebrew. |
| 11:11.11 |
d-lo |
starseeker:
Going to the gym nowadays? Rock on! |
| 11:13.05 |
d-lo |
``Erik:
Agreed. Goblinsharks are something straight out of a horror
flick. |
| 11:27.23 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 11:33.48 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 11:38.47 |
*** join/#brlcad magesing
(n=magesing@CPE002129b581fa-CM0011aec56242.cpe.net.cable.rogers.com) |
| 11:40.34 |
magesing |
Hi everyone,
Suppose I have modelled a part, and now I want to make a
manufacturing drawing so that I can machine it... How do I make the
drawing and apply GD&T in BRL-CAD? |
| 11:41.48 |
louipc |
magesing:
brl-cad doesn't have that capability |
| 11:42.16 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DE16.dip.t-dialin.net) |
| 11:43.09 |
magesing |
louipc:
hmm... that's a shame |
| 11:44.47 |
magesing |
Doesn't that
kindof limit the utility of brl-cad as a CAD/CAM package? What's
the use of designing a part if I have no way of transferring that
data to the shop-floor? |
| 11:44.50 |
louipc |
yeah I'd like
to see brl-cad more capable for drafting... but there needs to be
willing and able developers to do that |
| 11:45.49 |
magesing |
hmm... I
wonder what would be involved... Is it currently possible to render
views of parts with visible edges solid and hidden edges
dashed? |
| 11:45.50 |
louipc |
yeah it
totally limits brl-cad |
| 11:46.51 |
louipc |
i'm not too
sure about that one |
| 11:47.40 |
louipc |
you would
still need some kind of draft editor, I don't trust computer
generated drawings |
| 11:48.12 |
magesing |
if that is
possible, then it's just a matter of writing a script to generate
three orthographic views, then use some sort of external editor to
add annotations |
| 11:49.20 |
magesing |
probably
easiest to make a series of tools for inkscape or the gimp to add
the annotations to a monochrome drawing |
| 11:50.35 |
louipc |
brlcad
already has 2d sketch objects |
| 11:50.46 |
louipc |
something
from that could be used |
| 11:57.41 |
magesing |
louipc: "The
rtedge and rthide commands are used for hidden-line renderings
similarr to what you'd want for generating drafting documents."
--http://brlcad.org/wiki/FAQ |
| 11:57.54 |
*** join/#brlcad d_rossberg
(n=rossberg@66.111.56.50) |
| 11:58.38 |
magesing |
i.e. I can
generate images with rt-edge and rt-hide then use the image editor
of my choice to annotate the drawings |
| 12:10.21 |
louipc |
I'd opt for
different cad software if I had to do that for every drawing
though. heh |
| 13:03.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 13:51.38 |
CIA-30 |
BRL-CAD:
03irpguardian * r34903 10/brlcad/trunk/src/proc-db/human.c: Added
movement support for the right arm, and made a single function for
creating an arm, instead of one for left and right
sides. |
| 14:05.15 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 15:03.17 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:20.08 |
CIA-30 |
BRL-CAD:
03irpguardian * r34904 10/brlcad/trunk/src/proc-db/human.c: Added
poseable leg support, up to the thigh and calf, and made a makeleg
function to create them. |
| 15:23.41 |
CIA-30 |
BRL-CAD:
03bob1961 * r34905 10/brlcad/trunk/src/libged/killrefs.c: Update
comments. |
| 15:44.35 |
*** join/#brlcad cosurgi
(n=cosurgi@153.19.34.234) |
| 15:51.27 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-35-188.phnx.qwest.net) |
| 16:30.31 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-35-188.phnx.qwest.net) |
| 16:32.14 |
``Erik |
effin' made
me get a cast |
| 16:54.59 |
indianlarry |
/sb/ goto
-40 |
| 16:55.07 |
indianlarry |
oops |
| 17:09.15 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-35-188.phnx.qwest.net) |
| 17:19.21 |
*** join/#brlcad alecs1
(i=alex@193.170.134.90) |
| 17:24.46 |
alecs1 |
hi, archer
fails to start with the following error: ERROR: Unable to
initialize ArcherCore imagery |
| 17:25.03 |
alecs1 |
what could it
be? |
| 17:26.00 |
CIA-30 |
BRL-CAD:
03bob1961 * r34906 10/brlcad/trunk/src/ (4 files in 3 dirs): Mods
related to Archer's undo (i.e. override commands that are not yet
supported by undo). |
| 17:33.43 |
alecs1 |
ah, I looked
now in the archer script and there is no message like this
one |
| 17:34.09 |
louipc |
odd |
| 17:36.04 |
louipc |
alecs1: it's
in src/tclscripts/archer/LoadArcherLibs.tcl |
| 17:36.06 |
alecs1 |
I'm doing a
search in the source directory; google didn't find any message like
this |
| 17:36.32 |
alecs1 |
thanks, I'll
take a look |
| 17:40.07 |
alecs1 |
do you know
what it means? I have next to 0 brl-cad and tcl
experience |
| 17:41.05 |
``Erik |
archer is a
work in progress, not ready for consumption yet, last I heard...
you might want to use mged instead |
| 17:41.40 |
louipc |
looks like
it's looking for a tk add-on called 'tkimg' |
| 17:41.48 |
louipc |
if you're
missing that it won't work |
| 17:41.57 |
alecs1 |
thanks, I
didn't know; I'll stick to mged then |
| 17:42.27 |
alecs1 |
I'll for
tkimg then; maybe it helps |
| 17:54.37 |
CIA-30 |
BRL-CAD:
03irpguardian * r34907 10/brlcad/trunk/src/proc-db/human.c: Added
poseable support for all the leg now, including feet. |
| 18:39.44 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 18:41.00 |
jdoliner |
indianlarry
you here? |
| 18:50.35 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1096600584.dsl.bell.ca) |
| 18:53.55 |
CIA-30 |
BRL-CAD:
03bob1961 * r34908 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Modified archer to ask the user to
confirm save and revert requests. |
| 19:11.29 |
Ralith |
louipc: it
probably would be pretty easy to do something like rtedge with
hidden lines dashed |
| 19:22.06 |
*** join/#brlcad alecs1
(i=alex@193.170.134.90) |
| 19:42.43 |
*** part/#brlcad alecs1
(i=alex@193.170.134.90) |
| 20:06.39 |
CIA-30 |
BRL-CAD:
03homovulgaris * r34909 10/brlcad/trunk/src/libpc/pcMathGrammar.h:
FunctionGrammar added to the MathGrammar in preparation for
Constraint Grammar definition |
| 20:29.45 |
elena |
starseeker,
are you here? |
| 20:38.56 |
elena |
brlcad? |
| 20:48.01 |
``Erik |
I fed them to
the pet squirrel |
| 20:48.36 |
``Erik |
what's
up? |
| 20:48.40 |
elena |
hopes Erik is kidding |
| 20:48.48 |
``Erik |
it's a big
squirrel |
| 20:48.53 |
elena |
:) |
| 20:49.12 |
elena |
probably got
bigger after eating two mens. |
| 20:49.30 |
elena |
men (no
-s) |
| 20:49.52 |
``Erik |
boys, ya
mean |
| 20:50.00 |
``Erik |
sits around being horribly old |
| 20:50.26 |
``Erik |
technically,
I am a mentor (getting the t-shirt, anyways), is it something I may
be able to help with? |
| 20:50.40 |
Ralith |
solve my
ogre/qt problem :D |
| 20:50.48 |
elena |
i wanted to
ask them some suggestions about the metadata that I should/can get
from a model. |
| 20:51.01 |
``Erik |
ralith: stop
using that c++ crap, problem solved :D |
| 20:51.04 |
Ralith |
:[ |
| 20:51.40 |
``Erik |
metadata? hm,
title and units are probably the big ones, just be careful of .g
files with many models, I'd imagine |
| 20:51.40 |
elena |
ls -l
provides some information about the objects. |
| 20:51.49 |
elena |
tree about
the structure. |
| 20:52.19 |
elena |
ok. indeed, I
forgot about units. |
| 20:52.20 |
``Erik |
there're a
few different naming conventions that have different meanings, so
those might just need to be ignored |
| 20:53.01 |
elena |
and since
you're so kind, I have one curiosity |
| 20:53.28 |
elena |
i noticed
today, that when using the console mode in mged |
| 20:53.28 |
elena |
output goes
to stderr. |
| 20:53.40 |
``Erik |
um, once
thing ya see in real models that the army uses is there may be 4
seperate toplevel models of a single thing... depending on if it's
csg or triangles, and if it's low resolution or high resolution
modelling |
| 20:53.50 |
elena |
should it go
to stdout (errors and warnings to stderr) |
| 20:53.56 |
``Erik |
by console
mode, you mean classic? "mged -c" ? |
| 20:54.00 |
elena |
yes. |
| 20:54.51 |
elena |
this is in
7.14 |
| 20:54.52 |
``Erik |
output of
things like rt should go to stderr, I'd think... mged -c can be
used in scripts where you want just the right stuff to go to stdout
(sometimes to generate data to massage and feed back into
mged) |
| 20:55.10 |
elena |
i used
this |
| 20:55.19 |
elena |
mged -c
something.g tops |
| 20:55.30 |
elena |
that sent the
output to stderr. |
| 20:55.47 |
elena |
no big
problem. just curious about this decision. |
| 20:56.04 |
``Erik |
hrm, that
doesn't feel right to me, may've been accidently altered with all
the libged stuff :/ |
| 20:57.27 |
``Erik |
yeah, it all
goes to stderr for me, too hmmmmm |
| 20:58.09 |
Ralith |
shoud be easy
enough to fix, right? |
| 20:58.11 |
``Erik |
I think
that's one to ping brlcad for |
| 20:58.14 |
Ralith |
should* |
| 20:58.47 |
``Erik |
you'd think,
but display type stuff is abstracted in twisted ways to cope with
the tcl/C schism and stuff |
| 20:58.56 |
Ralith |
:/ |
| 20:59.23 |
``Erik |
and winderz
throws a monkeywrench into any simple/clean fd mgmt |
| 20:59.45 |
Ralith |
damnit
windows |
| 21:00.08 |
``Erik |
*shrug*
windows isn't unix... everything else is unix :) |
| 21:00.45 |
``Erik |
I imagine
haiku would have its own monkeywrench issues... BRL-CAD is
historically a very unix program, starting on 43BSD |
| 21:01.12 |
``Erik |
bought his macbook to have a nice unix laptop with a snazzy
gui |
| 21:01.57 |
Ralith |
yeah, but at
least haiku would be sane about it. |
| 21:02.11 |
Ralith |
installed stupmwm to get a snazzy gui |
| 21:02.18 |
``Erik |
I d'no, I
imagine it'd have, y'know, c++ involved... *duck* :D |
| 21:02.24 |
Ralith |
:P |
| 21:03.03 |
``Erik |
I used to be
a big c++ fan, but got away from it and into C in '96-'97, then I
got into things like smalltalk and now the c++ mockery of OO annoys
me :D |
| 21:03.24 |
``Erik |
and it's
easier to be negative and insulting than constructive
O:-) |
| 21:03.28 |
Ralith |
is taking quite a liking to common lisp, and thus can
sympathize |
| 21:03.32 |
Ralith |
heh |
| 21:03.42 |
``Erik |
yeah, but CL
has its own warts |
| 21:04.27 |
Ralith |
I'm
interested. What are they? |
| 21:04.30 |
``Erik |
is learning cl, web programming and emacs all at the same
time, is apparently mentally masochistic |
| 21:04.42 |
Ralith |
I have found
that emacs and CL go well together |
| 21:04.51 |
``Erik |
I dislike the
lisp1/lisp2 split, having to say #'func is annoying |
| 21:04.55 |
Ralith |
and there's a
good bit of evidence that CL and webprogramming go well together
too |
| 21:05.03 |
Ralith |
ah yeah,
that |
| 21:05.07 |
Ralith |
it |
| 21:05.19 |
Ralith |
it's a bit
weird and a little inconvenient, but at least it's logical and
consistent. |
| 21:05.43 |
Ralith |
and it
certainly is nice to have roomy namespaces. |
| 21:05.49 |
``Erik |
the
documentation is scattered and poorly formatted, and while the
third party stuff is insane in breadth and quality, it lacks a
decent centralized search/install mechanism and often lacks any
viable documentation |
| 21:06.06 |
Ralith |
er |
| 21:06.08 |
Ralith |
asdf-install |
| 21:06.14 |
*** join/#brlcad sander^
(n=sander@c-66-235-35-214.sea.wa.customer.broadstripe.net) |
| 21:06.27 |
``Erik |
I used that
for quite a bit, but then there're version knots |
| 21:06.35 |
Ralith |
and the
hyperspec seems pretty good doc-wise for me, wrt. cl
itself |
| 21:07.07 |
Ralith |
version
knots? |
| 21:07.09 |
``Erik |
for example,
ucw has many things that are ok from asdf, but some require the
cvs/svn/darcs/git version |
| 21:07.19 |
Ralith |
ah. |
| 21:07.34 |
Ralith |
that's just a
matter of the asdf repo being outdated |
| 21:07.39 |
``Erik |
thinks if someone took the clhs, unfuglyd it and allowed user
comments, a la php.net, that'd be awesome |
| 21:07.47 |
``Erik |
I might do
that when I get some free time, in fact |
| 21:07.51 |
Ralith |
it is ugly,
but it works. |
| 21:07.54 |
Ralith |
that'd be
neat! |
| 21:08.25 |
``Erik |
it's also not
the most newbie friendly community *shrug* |
| 21:08.37 |
Ralith |
it was
probably written near the beginning of html's popularity, and
considered 'good enough' as to need no updating since
then. |
| 21:08.45 |
``Erik |
yeah |
| 21:08.46 |
Ralith |
hm? I've
found #lisp to be a nice enough place. |
| 21:09.08 |
Ralith |
people are
happy to explain concepts and such |
| 21:09.12 |
sander^ |
Hi.. I saw on
sourceforge.net that this project needs developers |
| 21:09.34 |
Ralith |
sander^:
hullo. More dev-work is indeed always good. |
| 21:09.42 |
``Erik |
yeah, they're
usually decent if you don't ask stupid questions, but you start
reading the flame lists and stuff, or try to get a breadcrumb trail
started up, ... |
| 21:09.59 |
Ralith |
breadcrumb
trail? |
| 21:10.20 |
``Erik |
yeah, the
sequence of things to research to get to the next level, that kinda
thing |
| 21:10.42 |
Ralith |
I think CL's
main problem, and the main reason for its lack of popularity in
this age of python and ruby and such, is that it has no one central
community |
| 21:10.50 |
``Erik |
once you know
you want to go from a to b, they'll help you do that, but they
won't say what c is |
| 21:10.51 |
sander^ |
Ralith, Got
any easy tasks I could start doing.. need some help with getting
started tho. |
| 21:10.59 |
Ralith |
sander^:
what's your experience? |
| 21:11.46 |
Ralith |
``Erik: throw
together a prettified hyperspec and back that with a newsfeed and a
decent forum, and you might go a good ways towards fixing
that. |
| 21:11.46 |
``Erik |
sander^: and
interests... |
| 21:12.05 |
sander^ |
Ralith, I
know c,java very well.. abit c++.. Im intrested in learning more
c++ |
| 21:12.25 |
Ralith |
sander^:
yeah, it's inadvisable to put work in on code that you're not
personally invested in; you'll burn out quick. |
| 21:12.47 |
Ralith |
BRL-CAD is
mostly C. |
| 21:12.57 |
``Erik |
BRL-CAD is
mostly C, a little c++, a smidge of java... a wad of tcl... and
some other stuff |
| 21:13.29 |
sander^ |
I know tcl
very well |
| 21:13.40 |
``Erik |
oh, I'm so
sorry :( |
| 21:13.42 |
``Erik |
O:-) |
| 21:13.44 |
Ralith |
hehe |
| 21:13.55 |
Ralith |
sander^: so,
again, what're your interests? |
| 21:13.56 |
sander^ |
how much is a
wad :p? |
| 21:14.03 |
Ralith |
quite a
bit. |
| 21:14.14 |
``Erik |
it sounds
like you have the background to dig in whereever you want, you just
gotta let us know what your interest is :) |
| 21:14.31 |
``Erik |
almost all of
the MGED gui is tcl/tk with C backing the operations |
| 21:15.07 |
Ralith |
perhaps
archer? |
| 21:15.10 |
``Erik |
same with the
new archer gui... the ogre/qt experiment is the odd one (and a gsoc
project) |
| 21:15.58 |
sander^ |
I can go with
some c programming |
| 21:16.01 |
``Erik |
assumes sander^ has compiled and installed BRL-CAD, messed
around with it some, raytraced something, etc? |
| 21:16.13 |
sander^ |
No.. I should
do |
| 21:16.26 |
sander^ |
I just saw
the post on sourceforge |
| 21:17.17 |
Ralith |
but where do
your *interests* lie? |
| 21:17.57 |
``Erik |
hehehe, this
is open source, man, we're not going to TELL you what to do, we're
going to help you find what you want to do, then help you go about
doing it :D |
| 21:18.37 |
``Erik |
effin' A, sf
changed stuff around again |
| 21:19.00 |
Ralith |
it is
prettier, though, gotta give them that. |
| 21:20.00 |
sander^ |
I need to try
this program out.. before I can say what my interests
are |
| 21:20.08 |
Ralith |
do that
first, then :D |
| 21:20.11 |
``Erik |
sander^:
consider these 3 urls;
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/TODO
http://sourceforge.net/tracker/?group_id=105292
http://brlcad.org/~sean/ideas.html |
| 21:20.13 |
Ralith |
afks for a bit |
| 21:20.28 |
``Erik |
do the svn
co, then glance over them while it compiles or something
:) |
| 21:23.24 |
sander^ |
Where do I
find the source or whats the svn checkout url? |
| 21:24.27 |
sander^ |
Error
500 |
| 21:24.28 |
sander^ |
We're sorry
but we weren't able to process this request. |
| 21:24.35 |
sander^ |
When I push
"source" |
| 21:24.38 |
``Erik |
http://brlcad.org/wiki/SVN |
| 21:24.59 |
``Erik |
500? heh, sf
broke their server :( |
| 21:26.51 |
``Erik |
you will need
automake, libtool, and the X development stuff (as well as a c/c++
compiler). |
| 21:27.23 |
``Erik |
once it's
checked out, run the "autogen.sh" script, then the usual
./configure && make all install |
| 21:28.11 |
``Erik |
(and please,
if you see room for improvement on the wiki, ... :) |
| 21:47.43 |
sander^ |
Why does
autogen.sh take that long time? |
| 21:48.09 |
``Erik |
because it
runs aclocal, autoheader, automake and autoconf |
| 21:48.27 |
``Erik |
automake has
to find and parse every Makefile.am in the system and generate
Makefile.in files |
| 21:49.07 |
elena |
hei Erik, is
there an easy way to supply to commands to mged in command
line |
| 21:49.09 |
``Erik |
(that's
compiling 256 buildsystem files) |
| 21:49.23 |
elena |
like mged -c
something.g "tops; title" |
| 21:49.27 |
``Erik |
echo 'cmd 1;
cmd 2' | mged -c |
| 21:49.33 |
``Erik |
um, I think
that can work |
| 21:49.42 |
``Erik |
or put it in
a script and mged -c blah.g < myscript |
| 21:50.49 |
elena |
; didn't seem
to work. |
| 21:50.57 |
elena |
only the last
command is executed |
| 21:51.03 |
``Erik |
hm, might
need to be newlines then :/ |
| 21:51.06 |
elena |
i was able to
do it with echo -e "title\\ntops" | mged -c spheres.g |
| 21:51.31 |
elena |
it just
seemed a bit complicated |
| 21:52.28 |
``Erik |
yeah. I
thought semicolon was the seperator :/ |
| 21:53.56 |
elena |
thank
you. |
| 21:54.20 |
``Erik |
ohhhhhh,
wait, classic uses its own parser, not the tcl
interpreter |
| 21:54.41 |
elena |
and? |
| 21:55.16 |
``Erik |
; is the tcl
cmd seperator, I d'no if there's one built into the classic mode
mged parser |
| 21:55.54 |
``Erik |
if you don't
give it the -c, it should work, I think |
| 21:56.09 |
elena |
I need to run
it in a batch. |
| 21:56.27 |
elena |
if I don't
give it -c, it goes in bg |
| 21:56.53 |
``Erik |
how old is
your mged? |
| 21:56.59 |
elena |
7.14 |
| 21:57.03 |
elena |
x86 |
| 21:57.54 |
``Erik |
at some
point, the default behavior of mged went from going background to
staying in the fg, in support of various WM's |
| 21:57.58 |
elena |
hmm. same
happens in non-classical mode, too |
| 21:58.05 |
elena |
i start
mged |
| 21:58.06 |
``Erik |
yeah, feb of
'08 |
| 21:58.10 |
``Erik |
30246 |
| 21:58.25 |
elena |
in the
command win i type tops;title and only title is run |
| 21:58.35 |
``Erik |
huh,
weird |
| 21:59.01 |
``Erik |
yet another
thing to fix |
| 21:59.09 |
elena |
i guess i'm
moving from beginner to advanced level :) |
| 21:59.53 |
``Erik |
and kind
enough to observe/ask these little things instead of just shrugging
and moving on :) |
| 22:00.35 |
elena |
you're too
kind |
| 22:00.46 |
``Erik |
I know, and
I'm too modest, too O.o *duck* :D |
| 22:01.55 |
sander^ |
what do I
need to install to get x11 support? Whats.. X development
stuff? |
| 22:02.42 |
Ralith |
the
headers |
| 22:03.09 |
Ralith |
in a
debian-derived distro it'll be called x11-dev or
similar |
| 22:03.21 |
``Erik |
depends on
the OS, something like Xlib-dev and Xi-dev would do most rhat/deb
based leenewxes, I think |
| 22:03.53 |
sander^ |
libx11-dev
? |
| 22:04.00 |
``Erik |
sounds
right |
| 22:04.20 |
Ralith |
``Erik:
perhaps it would be advisable to replace the classic parser with
the tcl interp? |
| 22:04.23 |
sander^ |
Im on ubuntu
and debian |
| 22:04.37 |
Ralith |
libx11-dev is
almost certainly correct |
| 22:05.06 |
``Erik |
ralith: the
gui version gives the same results, I'm not sure what's going on
with it |
| 22:05.13 |
Ralith |
O.o |
| 22:05.19 |
Ralith |
that sounds
undesirable. |
| 22:05.22 |
``Erik |
and I'm not
going to dig into it while I'm sitting at home on sick leave
enjoying the vicodin |
| 22:05.34 |
``Erik |
which is just
about wearing off |
| 22:06.10 |
sander^ |
configure:
WARNING: X11 support is enabled but the Xi library was not
found. |
| 22:06.50 |
Ralith |
doesn't know what Xi is used for |
| 22:06.57 |
Ralith |
but you can
fix that by, you know, installing the Xi library. |
| 22:09.57 |
``Erik |
X
intrinsics |
| 22:10.11 |
elena |
erik, one
more help? |
| 22:10.20 |
``Erik |
hrm? |
| 22:10.43 |
elena |
i recall I
saw somewhere a way to get the output of a command and use it in
another |
| 22:10.58 |
elena |
i want to do
something like: tree `tops` |
| 22:11.01 |
``Erik |
inside of
mged? |
| 22:11.06 |
elena |
yes. |
| 22:11.14 |
``Erik |
uhmmm, sure
it wasn't tree [tops] ? |
| 22:11.19 |
elena |
maybe I'm
wrong and it wasn't mged. |
| 22:11.29 |
elena |
let me
test. |
| 22:11.41 |
``Erik |
it's a direct
tcl interpreter, so anything that works in tcl should work in
mged |
| 22:12.02 |
elena |
it says
db_lookup([tops]) failed: [tops] does not exist |
| 22:12.34 |
``Erik |
hm, yeah, I'm
dorking in tclsh |
| 22:12.37 |
``Erik |
<--
doesn't really know tcl |
| 22:13.55 |
elena |
:( |
| 22:15.21 |
``Erik |
tree [eval
tops] ? |
| 22:16.25 |
sander^ |
I cant find
the xi lib |
| 22:16.37 |
``Erik |
libXi-dev
? |
| 22:16.44 |
``Erik |
do you have
/usr/include/X11/Xi.h ? |
| 22:17.39 |
elena |
strange. it
shows an error, yet it displays some of the objects. |
| 22:17.51 |
sander^ |
Oh.. it
actually was libXi-dev |
| 22:18.29 |
elena |
mged> tree
[eval tops] |
| 22:18.30 |
elena |
db_lookup(tops]) failed: tops] does not
exist |
| 22:18.30 |
elena |
ellg |
| 22:18.30 |
elena |
axis/ |
| 22:21.06 |
``Erik |
*shrug* I
don't have the resources handy to figure that one out for ya, sorry
:( tomorrow, I'll have access to my books |
| 22:21.17 |
sander^ |
I dont have
/usr/include/X11/Xi.h still after installing libxi-dev |
| 22:21.43 |
sander^ |
And its also
still complaining about xi dev even after I installed
it |
| 22:27.43 |
elena |
no problem.
thank you. |
| 22:27.49 |
sander^ |
im just
compiling without x11 support |
| 22:27.55 |
elena |
i'm still
half way there :) |
| 22:28.48 |
sander^ |
What
downsides is it without x11 support? |
| 22:29.12 |
sander^ |
no grafical
interface? |
| 22:31.35 |
louipc |
no mged. You
probably want that. |
| 22:36.23 |
louipc |
sander^: hmm
I don't have Xi.h either |
| 22:36.34 |
louipc |
but I do have
libxi |
| 22:40.37 |
sander^ |
strange that
its complaining about it then |
| 22:41.14 |
louipc |
what was the
message you got complaining about xi? |
| 22:42.04 |
louipc |
"X11 support
is enabled but the Xi library was not found."? |
| 22:42.09 |
sander^ |
configure:
WARNING: X11 support is enabled but the Xi library was not
found. |
| 22:43.26 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 22:48.29 |
elena |
eval tree
[tops] seems to partially work. |
| 22:49.01 |
elena |
the problem
is that [tops] gets replaces with the string containing all the
tops (not with a list of objects) |
| 22:49.12 |
elena |
db_lookup
fails again. |
| 22:49.13 |
sander^ |
How long time
does it take to compile everything? |
| 22:49.24 |
Ralith |
depends
entirely on your hardware. |
| 22:51.10 |
sander^ |
From what to
what?.. Like.. Can it take half an hour? |
| 22:51.39 |
``Erik |
anywhere from
5 minutes to 5 hours... |
| 22:51.45 |
Ralith |
from the next
millenium to instantly. |
| 22:51.51 |
Ralith |
it depends
entirely on your hardware. |
| 22:52.00 |
sander^ |
okay |
| 22:52.07 |
Ralith |
I suggest not
attempting to use nothing but a pencil. |
| 22:52.36 |
``Erik |
damn, ralith,
still sore about that? we thought it was hilarious :D
*duck* |
| 22:53.16 |
louipc |
sander^: do
you have x11proto-input-dev installed? |
| 22:53.29 |
Ralith |
``Erik: at
least I know x86 hex now. |
| 22:53.37 |
louipc |
/usr/include/X11/extensions/XI.h |
| 22:53.42 |
``Erik |
x86? damnit,
boy, we said r2k! |
| 22:53.45 |
louipc |
is in that
package |
| 22:54.00 |
``Erik |
(r2k is sexy
assembly) |
| 22:54.01 |
Ralith |
yeah, but I
didn't have the test hardware and I was too lazy to find a
vm |
| 22:54.12 |
``Erik |
http://pages.cs.wisc.edu/~larus/spim.html
|
| 22:54.16 |
``Erik |
there,
there's your vm |
| 22:54.17 |
``Erik |
:D |
| 22:55.11 |
sander^ |
louipc, yes..
I got x11proto-input-dev installed |
| 22:58.57 |
CIA-30 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1520 10/wiki/More_Changelog: /* June, 17 - today */ |
| 23:16.16 |
louipc |
/usr/include/X11/extensions/XI.h: #define
XI_DATAGLOVE "DATAGLOVE" |
| 23:16.22 |
louipc |
bwhahahha |
| 23:21.39 |
sander^ |
/usr/bin/ld:
cannot find -ltk8.5 |
| 23:21.52 |
sander^ |
collect2: ld
returned 1 exit status |
| 23:22.59 |
sander^ |
it fails on
that when doing make |
| 23:23.46 |
louipc |
you have tk
8.5? |
| 23:23.50 |
``Erik |
did the
configure stuff say that it was building tk or not? |
| 23:29.48 |
sander^ |
now I
installed tk-dev |
| 23:30.25 |
louipc |
I'm glad I
don't use debian :P |
| 23:31.31 |
sander^ |
Well.. im
actually installing this on my ubuntu laptop without too many
programs |
| 23:31.44 |
Ralith |
tk-dev won't
help |
| 23:31.48 |
Ralith |
taht's the
headers; it's missing the library. |
| 23:32.05 |
Ralith |
(although
tk-dev undoubtedly depends on tk, so it might work
anyway) |
| 23:32.18 |
sander^ |
Build Tcl
............................: yes |
| 23:32.18 |
sander^ |
Build Tk
.............................: yes |
| 23:32.30 |
Ralith |
sounds like a
build system bug, then :/ |
| 23:32.44 |
louipc |
hm. if you
have them installed it should say no (using system) |
| 23:32.51 |
Ralith |
he
doesn't |
| 23:32.55 |
Ralith |
he's just now
installing them, I think |
| 23:34.49 |
louipc |
I'm surprised
no debianites have come along and spruced up the build
files |
| 23:35.36 |
``Erik |
made a debian/ build thingy a while back, but lost access to
his debian box *shrug* |
| 23:37.14 |
sander^ |
should it say
yes here?: Build Tk .............................: yes |
| 23:37.27 |
Ralith |
did it say
that after you had installed tk? |
| 23:37.29 |
sander^ |
I got tk
installed.. and did configure once more |
| 23:37.41 |
Ralith |
then it
shouldn't want to build its own. |
| 23:37.51 |
``Erik |
um |
| 23:37.54 |
louipc |
did you
install tcl too? |
| 23:38.06 |
``Erik |
try doing a
"make distclean", then do "./configure --enable-all" and see if it
works then |
| 23:38.14 |
sander^ |
I installed
both tcl and tk |
| 23:38.16 |
Ralith |
louipc:
pretty sure tk depends on tcl :P |
| 23:38.29 |
louipc |
yeah it
does |
| 23:42.35 |
sander^ |
I need to go
now.. |
| 23:43.05 |
louipc |
see you
later |
| 23:50.01 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FC4C.dip.t-dialin.net) |
| 23:58.26 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 00:46.30 |
*** join/#brlcad schwinn434_
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 00:51.49 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.202.25) |
| 01:58.21 |
*** join/#brlcad schwinn434_
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 02:04.53 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 02:42.36 |
*** join/#brlcad schwinn434
(n=schwinn4@cpe-75-81-202-25.we.res.rr.com) |
| 02:44.53 |
*** join/#brlcad schwinn434_
(n=schwinn4@75.81.202.25) |
| 02:52.30 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 04:07.09 |
CIA-30 |
BRL-CAD:
03brlcad * r34910 10/brlcad/trunk/BUGS: elena found an odd bug in
mged's command-mode parsing. semicolons are the separator but for
some reason output of mged commands is being suppressed for all but
the last command. |
| 04:07.55 |
*** join/#brlcad IriX64
(n=WarLock@bas2-sudbury98-1178015175.dsl.bell.ca) |
| 04:12.43 |
brlcad |
per elena's
questions earlier: mged -c whatever.g "tree \[string trim \[ tops
-n\] \]" |
| 04:13.16 |
brlcad |
have to quote
the globbing characters [], {}, & ? |
| 04:14.27 |
``Erik |
ahhhh, that's
right, forgot about that |
| 04:15.14 |
brlcad |
semicolon
should / does work .. but there's some sort of bug
there |
| 04:15.54 |
brlcad |
mged -c
test.g "puts hello ; puts world" <= works for
example |
| 04:16.19 |
brlcad |
even
interlaced with mged commands .. but for some reason mged commands
aren't printing unless they're last |
| 04:16.33 |
``Erik |
what about
the stdout/stderr issue? |
| 04:16.35 |
brlcad |
have to trace
it |
| 04:17.08 |
brlcad |
that's mostly
legacy, all textual logging goes through bu_log, which has always
written to stderr |
| 04:17.29 |
brlcad |
would be a
pretty significant change so it's not been attempted
yet |
| 04:19.37 |
brlcad |
that was
originally so the streamable tools could still log and send their
data to a stream (e.g. for piping input to output on things like
"pixhalve -s1024 some.pix | pix-png > file.png", and still
seeing logged output) |
| 04:19.55 |
brlcad |
everything
uses the same logging mechanism so it goes to stderr |
| 04:20.50 |
brlcad |
notes elena probably needs to read http://brlcad.org/wiki/SGI_Cube |
| 07:24.49 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 07:48.01 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178015175.dsl.bell.ca) |
| 08:02.24 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 08:09.14 |
CIA-30 |
BRL-CAD:
03d_rossberg * r34911 10/rt^3/trunk/ (4 files in 2
dirs): |
| 08:09.15 |
CIA-30 |
BRL-CAD:
change the data-type for color values from unsigned int to double
(0 <= r/g/b <= 1) |
| 08:09.17 |
CIA-30 |
BRL-CAD:
although color values are stored as unsigned int this
implementation detail should be hidden from the user |
| 08:18.38 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 08:47.52 |
CIA-30 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1525 10/wiki/User:Jdoliner: |
| 09:49.01 |
*** join/#brlcad mafm
(n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 10:25.35 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FC4C.dip.t-dialin.net) |
| 13:22.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 14:18.52 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 15:40.11 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:48.31 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 16:01.01 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:02.12 |
*** join/#brlcad alecs1
(n=alex@193.186.164.88) |
| 16:02.59 |
alecs1 |
hi, does
BRL-CAD support tolerancing? I couldn't find it in the
docs |
| 16:03.31 |
d-lo |
depends on
what you mean. To what are you wanting to apply a tolerance
to? |
| 16:03.33 |
alecs1 |
(tolerancing
as in gd&t, that's the more known buzzword) |
| 16:04.11 |
louipc |
make this
hole 1" dia +- .005" |
| 16:04.54 |
alecs1 |
well, to
components in the tree; but I'm no BRL-CAD expert either, just
evaluating and asking if it's not in the docs |
| 16:05.13 |
louipc |
brl-cad
doesn't have that feature as far as I know |
| 16:05.26 |
louipc |
but I'm no
authority on it :P |
| 16:06.03 |
d-lo |
I would say
no, it doesn't support GD&T. |
| 16:06.41 |
alecs1 |
thanks |
| 16:06.46 |
alecs1 |
do you know
of other open-source programs that support it |
| 16:12.03 |
CIA-30 |
BRL-CAD:
03starseeker * r34912 10/brlcad/trunk/ (11 files in 7 dirs): Add
bbsize command per user request - reports a quick summary of how
big the bounding box of an object is. |
| 16:12.34 |
louipc |
nope |
| 16:12.50 |
louipc |
qcad maybe...
that's 2d though |
| 16:18.16 |
alecs1 |
I see, thank
you :) |
| 16:23.23 |
CIA-30 |
BRL-CAD:
03starseeker * r34913 10/brlcad/trunk/src/tclscripts/lib/ (Db.tcl
Mged.tcl): Don't need the bbsize command support on obsolete tcl
code. |
| 17:02.38 |
brlcad |
definitely do
not support tolerancing |
| 17:06.00 |
brlcad |
starseeker:
unless I read the commit wrong, you missed the bbsize.c
file |
| 17:06.58 |
starseeker |
aaah,
nuts |
| 17:07.00 |
starseeker |
sorry |
| 17:07.40 |
CIA-30 |
BRL-CAD:
03starseeker * r34914 10/brlcad/trunk/src/libged/bbsize.c: Yeah, it
might help to add the key bbsize file. |
| 17:07.56 |
brlcad |
thx |
| 17:08.04 |
starseeker |
np
:-) |
| 17:38.13 |
CIA-30 |
BRL-CAD:
03brlcad * r34915 10/brlcad/trunk/NEWS: fixed compilation support
for mac os x 10.5, problem compiling with ogl support enabled (mac
ld issue with /usr/X11/lib/libGL.dylib cyclicly referring to
framework dylib) |
| 17:45.39 |
*** join/#brlcad alecs1
(n=alex@budweis.scch.at) |
| 17:54.31 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 17:56.03 |
*** join/#brlcad BigAToo1
(n=BigAToo@64.74.225.82) |
| 17:58.13 |
CIA-30 |
BRL-CAD:
03homovulgaris * r34916 10/brlcad/trunk/src/libpc/pcMathGrammar.h:
fleshing FunctionGrammar 1/2 |
| 18:03.28 |
jdoliner |
indianlarry
whenever you read this, I think I've worked out the kinks in my
algorithmic woos. But would love to talk about it with you, just to
do some sanity checks. |
| 18:08.23 |
``Erik |
sanity check:
you have none :D |
| 18:08.43 |
``Erik |
(which is why
ya fit in here) |
| 18:08.54 |
jdoliner |
:D |
| 18:09.09 |
jdoliner |
it certainly
feels that way these days |
| 18:09.22 |
indianlarry |
what you come
up with Joe |
| 18:09.23 |
jdoliner |
I close my
eyes and see triangles intersecting each other |
| 18:09.58 |
jdoliner |
k so we
wanted to have a convention for which way the edge we return should
point |
| 18:10.39 |
jdoliner |
and this
convention should depend on the normals of both of the triangles we
intersect |
| 18:11.01 |
indianlarry |
okay |
| 18:11.23 |
jdoliner |
so we decide
that the edge will be parallel to (norm1Xnorm2) |
| 18:11.56 |
CIA-30 |
BRL-CAD:
03irpguardian * r34917
10/brlcad/trunk/src/proc-db/human.c: |
| 18:11.56 |
CIA-30 |
BRL-CAD:
Added poseable support for the torso. Also made the arms and legs
now properly position themselves and attach to torso. |
| 18:12.01 |
CIA-30 |
BRL-CAD: Legs
and arms are still not properly positioned when the body is rotated
however. |
| 18:12.01 |
indianlarry |
follow so
far |
| 18:12.03 |
jdoliner |
so if we do
this |
| 18:12.22 |
jdoliner |
then when we
have an edge and the triangle it came from |
| 18:14.00 |
jdoliner |
then in
triangle1 the (edgeXNorm) points to the internal side, in triangle2
it points to the external side |
| 18:14.26 |
jdoliner |
just a fact
of life that this is going to be reversed |
| 18:14.41 |
jdoliner |
but the
important part is that it'll be consistent |
| 18:15.57 |
jdoliner |
so if we take
our corner jabbing into a triangle |
| 18:17.27 |
jdoliner |
we would get
a the trimming curve back with the lines s.t. the normal points the
opposite direction of the faces normal |
| 18:17.39 |
jdoliner |
which
signifies an internal face |
| 18:18.20 |
jdoliner |
oh forgot to
mention abut the output that we need to reverse the line for
mesh1 |
| 18:18.50 |
jdoliner |
but yeah I'm
confident in that case |
| 18:19.36 |
jdoliner |
now the
trickiness comes when it hits an edge |
| 18:20.23 |
jdoliner |
so it now
passes up which edge the intersection came from |
| 18:20.33 |
jdoliner |
so suppose we
get back the line pq |
| 18:21.06 |
jdoliner |
and we know
that point p came from line ab |
| 18:21.10 |
``Erik |
yuh oh, libpc
issue, no boost lazy.hpp |
| 18:21.40 |
jdoliner |
then we know
that the lines to include are: |
| 18:21.58 |
jdoliner |
ap and
bp |
| 18:22.37 |
jdoliner |
because those
are consistent with the direction of pq |
| 18:23.11 |
``Erik |
src/libpc/pcMathGrammar.h:42:41: error:
boost/spirit/dynamic/lazy.hpp: No such file or
directory |
| 18:23.37 |
jdoliner |
so really the
only tricky part is that ab might have more than 1 point on
it |
| 18:25.13 |
jdoliner |
so we
basically need to record where these points are in a slightly more
sophisticated way |
| 18:25.36 |
jdoliner |
which is just
going to be a polyline that keeps them all in order and then we
take the segments out of it at the end. |
| 18:26.39 |
indianlarry |
just thinkin
that basically any loop that contains an outside edge would in fact
be an an outside edge and be ordered as such |
| 18:27.50 |
indianlarry |
are you
making loops from your intersections yet |
| 18:28.11 |
indianlarry |
or just the
list of intersecting segments |
| 18:29.31 |
jdoliner |
sort of, I
have the could all ready to go to make loops, but I need to
implement the stuff I just mentioned to be able to pass it the
right segments |
| 18:30.40 |
jdoliner |
before this I
was just grabbing the segments however they came out and it worked
great on them |
| 18:33.02 |
indianlarry |
maybe not
visualizing correctly |
| 18:33.49 |
indianlarry |
but seems
like you could lose ap or pb depending on the boolean logic of your
combination |
| 18:35.15 |
jdoliner |
yeah one of
them won't be in the final result |
| 18:35.24 |
jdoliner |
one is
internal and the other is external |
| 18:36.07 |
indianlarry |
yeah okay, do
you keep seperate loop list for each face |
| 18:36.35 |
CIA-30 |
BRL-CAD:
03brlcad * r34918
10/brlcad/trunk/src/other/boost/spirit/dynamic/lazy.hpp: missing
lazy.hpp, now used by pcMathGrammer.h though might still be missing
some other files |
| 18:36.41 |
jdoliner |
yes |
| 18:37.10 |
jdoliner |
for each face
in the original mesh there's actually possible multiple face
loops |
| 18:37.52 |
indianlarry |
yeah and an
inner can probably turn into an outer after the
combination... |
| 18:38.18 |
jdoliner |
how do you
mean? |
| 18:39.07 |
jdoliner |
oh, well if
we do Mesh A - Mesh B then the inners of B will be an outer of the
result |
| 18:39.27 |
indianlarry |
is you cut a
face in falf and there was an inner loop -- yeah |
| 18:39.39 |
jdoliner |
k
yeah |
| 18:39.46 |
indianlarry |
sorrry slow
typer |
| 18:39.58 |
jdoliner |
:) young
nimble fingers |
| 18:40.13 |
indianlarry |
sounds
similar to the nurbs loops |
| 18:40.30 |
jdoliner |
yeah it's
actually really elegant after we have all the faces pointing the
right way |
| 18:40.37 |
indianlarry |
is the first
loop the outer and the rest inner loops |
| 18:41.01 |
jdoliner |
well couldn't
there be multiple outers? |
| 18:41.35 |
jdoliner |
an outer loop
is just one that intersects a triangle edge correct? |
| 18:41.51 |
indianlarry |
not sure how
the meshes are handles but for the nurbs there's only one
outer |
| 18:42.12 |
indianlarry |
i think
multiple outers would be treated as seperate faces |
| 18:43.39 |
jdoliner |
okay I think
I see what it means for nurbs |
| 18:44.17 |
jdoliner |
is it just
the curve along the outside of the defined surface? |
| 18:44.18 |
indianlarry |
are you
looking at bots or meshed faces |
| 18:44.50 |
indianlarry |
yes the outer
boundry of the face |
| 18:45.18 |
jdoliner |
I believe
bots |
| 18:45.46 |
jdoliner |
yeah it just
has an array of faces which could occur in any order |
| 18:46.26 |
jdoliner |
although
there can be quads in the bag as well |
| 18:47.13 |
CIA-30 |
BRL-CAD:
03brlcad * r34919 10/brlcad/trunk/src/other/boost/spirit/ (5 files
in 3 dirs): add a few more missing boost files to unbreak the build
after recent pcMathGrammer changes |
| 18:58.42 |
indianlarry |
if bots then
probably don't need to worry about loops and such right |
| 18:59.58 |
jdoliner |
yeah, I deal
with things on a triangle by triangle basis |
| 19:01.45 |
indianlarry |
sorry joe i
think i'm leading you astray |
| 19:03.05 |
indianlarry |
guess you
still need to maintain proper facet orientations |
| 19:03.51 |
jdoliner |
yes |
| 19:04.51 |
indianlarry |
i guess a
polyline accross a facet -> many facets |
| 19:05.32 |
jdoliner |
yes |
| 19:06.30 |
jdoliner |
I mean I
can't do any sort of geometry internal to my faces, any detail I
want to include has gotta be done with triangles |
| 19:07.48 |
indianlarry |
yep the
corner into a face of a triangle turns into a handfull of
facets |
| 19:08.41 |
indianlarry |
did the BOOLE
folks have walking algrithm for this already? |
| 19:15.59 |
indianlarry |
or were they
just doing bezier ? |
| 19:20.29 |
CIA-30 |
BRL-CAD:
03erikgreenwald * r34920 10/isst/ (24 files in 4 dirs): import of
ISST |
| 19:22.55 |
elena |
brlcad, are
you here? |
| 19:25.32 |
CIA-30 |
BRL-CAD:
03erikgreenwald * r34921 10/isst/trunk/src/gui.c:
acronymize |
| 19:32.04 |
elena |
``Erik, did
you feed the squirrel again? |
| 19:45.27 |
brlcad |
hi
elena |
| 19:45.35 |
elena |
hi. |
| 19:45.38 |
brlcad |
few comments
about your work yesterday |
| 19:46.07 |
elena |
did you see
the log of the chat with erik? |
| 19:46.13 |
brlcad |
semicolon is
the command separater -- what you were trying should have
worked |
| 19:46.16 |
brlcad |
yes |
| 19:46.23 |
elena |
:) |
| 19:46.25 |
elena |
ok |
| 19:46.38 |
brlcad |
never leaves IRC .. that's what 'screen'+'irssi' are for
:) |
| 19:46.52 |
elena |
:) |
| 19:47.13 |
brlcad |
you can see
the result with something like this: mged -c test.g "puts hello ;
puts world" |
| 19:47.38 |
brlcad |
there is some
odd issue causing output to be quieted (though I believe it does
run the commands still) |
| 19:47.58 |
brlcad |
haven't
confirmed yet though |
| 19:48.11 |
brlcad |
secondly, I
presume you've seen http://brlcad.org/wiki/SGI_Cube
? |
| 19:48.19 |
brlcad |
that shows
three specific ways to script mged |
| 19:48.21 |
elena |
but "tops ;
tops" doesn't work :( |
| 19:48.29 |
brlcad |
it does and
it doesn't |
| 19:48.37 |
brlcad |
I believe
it's just not printing the result |
| 19:48.38 |
elena |
i
haven't. |
| 19:48.42 |
elena |
thanks for
the tip. |
| 19:48.49 |
brlcad |
but actually
runs the commands |
| 19:49.05 |
elena |
i spent all
day reading about tcl :) |
| 19:49.19 |
elena |
ok. |
| 19:49.25 |
brlcad |
to do the
tree of tops that you suggested, it was simply a matter of escaping
the globbing characters |
| 19:49.27 |
elena |
and about the
stderr output? |
| 19:50.10 |
brlcad |
for example:
mged -c whatever.g "tree \[string trim \[ tops -n\] \]" |
| 19:51.17 |
CIA-30 |
BRL-CAD:
03erikgreenwald * r34922 10/isst/trunk/src/ (gui.c main.c sql.c):
fix headers |
| 19:51.32 |
brlcad |
by default,
mged has a globbing evaluation mode enabled so that glob characters
(*[],?{}.) are specially recognized so you can do pattern matching
on objects, e.g. "draw *" or "draw [a-f]*" |
| 19:52.04 |
brlcad |
so you either
have to turn globbing off (set glob_compat_mode 0) ... or ...
escape the glob characters ala \[ \] |
| 19:53.25 |
brlcad |
btw, if you
had multiple top-level objects, that example won't work -- you'd
need to iterate over each object and call tree |
| 19:53.55 |
elena |
i've noticed.
this is why i started to read more about tcl. |
| 19:54.16 |
elena |
it seems to
me that it will help with the drupal integration. |
| 19:54.24 |
brlcad |
something
like: foreach obj \{ \[ string trim \[ tops -n \] \] \} \{ tree
$obj \} |
| 19:54.57 |
brlcad |
since you're
in php land, it may very well be easier to just run one command at
a time and do your string parsing on the php side |
| 19:55.26 |
elena |
less
fun. |
| 19:55.32 |
elena |
maybe less
efficient, too. |
| 19:55.57 |
brlcad |
it should be
fairly insignificant compared to what all you're doing and how
often this is called |
| 19:56.09 |
brlcad |
but fun is a
good motivator |
| 19:56.10 |
elena |
ok. i'll
think about it. |
| 19:56.11 |
brlcad |
:) |
| 19:56.43 |
brlcad |
note that the
http://brlcad.org/wiki/SGI_Cube
example shows those three ways I mentioned, but is actually just a
posix shell script driving mged |
| 19:57.15 |
brlcad |
the cat
<<EOF section is one of the three I mentioned, where it pipes
multiple commands to mged |
| 19:57.53 |
elena |
i'll study
it. |
| 19:57.59 |
elena |
thank
you. |
| 19:58.28 |
brlcad |
if you want
to capture stderr more easily, you can feed stderr to stdout with
2>&1 |
| 19:58.42 |
elena |
i did
that. |
| 19:58.48 |
brlcad |
k |
| 19:58.52 |
``Erik |
wonders if turning off globbing in the .mgedrc would be good
for an account that just runs mged batch-mode |
| 19:59.27 |
elena |
@Erik:
doesn't matter, i could turn it off at the begining of the
script. |
| 19:59.29 |
brlcad |
possible, but
it really just saves a couple keystrokes, which are embedded in a
script anyways |
| 19:59.40 |
brlcad |
now if your
script gets big/unreadable ... |
| 20:00.07 |
``Erik |
or at the
beginning of the script, yes... escaping all the glob characters in
a nontrivial script can quickly become ugly |
| 20:13.33 |
*** join/#brlcad _sushi_
(n=_sushi_@80-219-43-170.dclient.hispeed.ch) |
| 20:39.32 |
*** join/#brlcad alecs1
(i=alex@193.170.134.247) |
| 20:51.54 |
CIA-30 |
BRL-CAD:
03indianlarry * r34923 10/brlcad/trunk/ (12 files in 5
dirs): |
| 20:51.56 |
CIA-30 |
BRL-CAD:
added near hit, near miss processing to shotline |
| 20:51.58 |
CIA-30 |
BRL-CAD: also
started to pull out debugging code and wrap into |
| 20:52.00 |
CIA-30 |
BRL-CAD:
'brep' utility command in libged |
| 21:16.46 |
*** join/#brlcad docelic
(n=docelic@78.134.203.84) |
| 21:20.05 |
CIA-30 |
BRL-CAD:
03irpguardian * r34924 10/brlcad/trunk/src/proc-db/human.c: Added
poseable support for the head and neck, so now the entire body has
poseable support. |
| 21:22.44 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-27-160.phnx.qwest.net) |
| 21:25.22 |
CIA-30 |
BRL-CAD:
03ebautu * r34925
10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/template.php:
Fixed error in theme comment wrapper |
| 21:26.26 |
CIA-30 |
BRL-CAD:
03ebautu * r34926
10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/ (. 7.14/
7.14/metadata.txt): Scripts for integration with Drupal |
| 21:27.45 |
CIA-30 |
BRL-CAD:
03ebautu * r34927
10/web/trunk/htdocs/more/sites/all/modules/brlcad/brlcad.module:
Added suport for multiple BRL-CAD versions (script not yet ready).
Multistep submission is incomplete, too. |
| 21:30.11 |
CIA-30 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1526 10/wiki/More_Changelog: /* June, 17 - today */ |
| 21:49.09 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FC4C.dip.t-dialin.net) |
| 22:09.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 00:35.51 |
*** part/#brlcad alecs1
(i=alex@193.170.134.154) |
| 02:40.54 |
starseeker |
Ralith: any
luck with QT/Ogre? |
| 02:42.08 |
Ralith |
starseeker:
not quite yet; there turned out to be more posisbly relevant
functions than I expected. |
| 02:42.11 |
Ralith |
working
through them now. |
| 02:43.25 |
Ralith |
isn't quite sure how qgraphicsscene and qgraphicsview
relate |
| 02:43.34 |
Ralith |
and I haven't
worked out how to use gdb reliably on C++ yet. |
| 02:46.19 |
``Erik |
gdb still
isn't c++ friendly? O.o |
| 02:47.13 |
Ralith |
I dunno, I
probably am just misusing it |
| 02:47.26 |
``Erik |
http://ccrma.stanford.edu/~jos/pasp/Dealing_C_gdb.html |
| 02:47.39 |
Ralith |
it demangles
names and basic stuff like that fine |
| 02:47.44 |
Ralith |
I just have
trouble getting it to break on class member functions |
| 02:47.59 |
``Erik |
line# breaks
don't do it? |
| 02:48.14 |
Ralith |
huh? |
| 02:48.16 |
Ralith |
oh |
| 02:48.19 |
Ralith |
didn't try
that >_> |
| 02:48.23 |
``Erik |
heh |
| 02:48.28 |
Ralith |
didn't know
gdb could do that, even. |
| 02:48.39 |
``Erik |
yeah, break
file.cxx:42 |
| 02:48.39 |
Ralith |
first,
though, food! |
| 02:48.42 |
Ralith |
cool,
thanks |
| 02:48.59 |
``Erik |
tends to use line # more than function
name |
| 02:49.06 |
Ralith |
probably will now that he knows it |
| 03:05.16 |
Ralith |
ugh, qt
builds slow. |
| 03:08.39 |
starseeker |
yeah, line #
breaking works better for me in c++ |
| 03:09.15 |
Ralith |
it's packages
like qt that I wish would use cmake |
| 03:09.19 |
Ralith |
so I'd have
some idea how far along it was |
| 03:11.26 |
louipc |
ls |
| 03:11.28 |
louipc |
bah |
| 03:23.28 |
*** join/#brlcad pacman871
(n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 03:54.23 |
Ralith |
reaids paradigms of artificial intelligence programming while
he waits. |
| 03:54.34 |
Ralith |
trace is a
really neat function :D |
| 04:18.37 |
Ralith |
starseeker:
line number breaking works within every instance of a class (for
non-static funcs), right? |
| 05:28.13 |
Ralith |
woo, qt
rebuilt! |
| 05:54.52 |
Ralith |
argh. |
| 05:56.04 |
Ralith |
it looks like
I'm going to have a very hard time building with a custom Qt
without uninstalling my system one |
| 05:58.32 |
Ralith |
tries a really dirty hack |
| 06:04.11 |
Ralith |
damn. |
| 06:13.22 |
Ralith |
hack seems to
work, but I'm not getting anywhere with g3d. |
| 06:30.17 |
*** join/#brlcad elena (n=elena@92.86.0.28) |
| 06:31.19 |
elena |
hi |
| 06:32.06 |
Ralith |
hullo |
| 06:34.08 |
Ralith |
well
crap |
| 06:34.16 |
Ralith |
that just
about exhausts my Qt modding ideas |
| 06:34.20 |
Ralith |
no luck there
either |
| 06:39.16 |
*** join/#brlcad Evgen
(n=NUser@62.33.59.254) |
| 07:43.41 |
*** join/#brlcad elena (n=elena@92.86.0.28) |
| 08:25.21 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 09:38.37 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 10:02.44 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 11:09.10 |
*** join/#brlcad cosurg1
(n=cosurgi@atak.bl.pg.gda.pl) |
| 11:35.27 |
d-lo |
Merning all.
*READREADREAD* |
| 11:42.39 |
d-lo |
Ralith /
madant: Was just annoyed that ogre had a dep to boost, thats all.
Personal preference. |
| 11:54.35 |
d-lo |
Ralith:
Thanks for dropping a few comments here and there in irc and the
wiki. Keep that wiki log going, so we/I can track whats going on.
It will also help people who want to chip in advice not tell you
something you already tried. I know that frustrates me when people
do that :/ |
| 12:15.50 |
``Erik |
d-lo: the
server side thingymajigger you were looking at was projectdorkstar?
(saw mention of someone looking to combine panda3d with
dorkstar) |
| 12:16.17 |
d-lo |
what
thingymajigger? |
| 12:16.23 |
``Erik |
server side
game mgmt |
| 12:17.16 |
d-lo |
Hrm, I am at
a loss. I don't remember looking at projectdorkstar... |
| 12:17.22 |
``Erik |
darkstar,
rather |
| 12:17.23 |
``Erik |
O:-) |
| 12:17.33 |
``Erik |
http://projectdarkstar.com/ |
| 12:17.42 |
d-lo |
ah, havne't
really looked at that in a while. |
| 12:20.03 |
``Erik |
*shrug* just
noticed it mentioned and went "huh, that looks real
familiar" |
| 12:20.25 |
d-lo |
kk, thanks!
I will book mark it and look for that panda3d
reference. |
| 12:26.09 |
``Erik |
does
shadowbane do mob ai on the server? |
| 12:26.34 |
``Erik |
or, did it,
rather O:-) |
| 12:26.52 |
d-lo |
Heh, calling
it AI would be rather generous. |
| 12:28.25 |
``Erik |
heh, well,
yeah, but you know what I mean |
| 12:28.56 |
d-lo |
a
bit. |
| 12:29.15 |
d-lo |
Its one of
the major issues we are looking to rectify with the
Emu. |
| 12:29.38 |
``Erik |
<-- was
pondering how to 'share the love' of ai computation time with
clients that could arbitrarily disconnect |
| 12:29.55 |
d-lo |
Oh, so kinda
like AI at home? |
| 12:30.00 |
d-lo |
err
AI@Home? |
| 12:30.28 |
``Erik |
if you have a
group of half a dozen people whacking on a baddy and someone
crashes or disconnects when they're housing the ai for it, it'd be
retarded for the mob to simply freeze up for the other
players |
| 12:31.45 |
``Erik |
game ai has
to respond fairly quickly and have some randomness, so I d'no if
packet bundling across multiple hosts like an @home is
pragmatic |
| 12:32.26 |
_clock_ |
I think
Artifical Intelligence is not a good approach to model human
behaviour |
| 12:32.29 |
``Erik |
but doing ai
for 10000 mobs, plus all the message management, plus state
persistence, don't wanna overload the server |
| 12:32.30 |
d-lo |
What about
redundant calcs? 2 or 3 of the same calc on machines. First one
to return a result is used. |
| 12:32.44 |
_clock_ |
I think we
won't move from place until we master AS - Artificial
Stupidity. |
| 12:33.10 |
``Erik |
if(random()
> .5) mob->special1(); else mob->special2(); <-- cuz
of that |
| 12:33.13 |
``Erik |
? |
| 12:33.28 |
``Erik |
sorry,
misread |
| 12:33.52 |
d-lo |
Yeah, I
mistyped a bit too. I ment several different machines performing
same calc for redundancy. |
| 12:34.25 |
``Erik |
hm, latency
issues, I guess... two machines calc and start doing their thang,
send to the server to redistribute, do you wait the .8 seconds on
all machines for the mob to hop to the appropriate
state? |
| 12:34.31 |
*** join/#brlcad docelic__
(n=docelic@78.134.207.99) |
| 12:35.37 |
``Erik |
_clock_ we're
not talking about making a single smart 'ai', we're talking about
scaling to a buttload of stupid videogame ai's :D mmorpg
style |
| 12:37.24 |
_clock_ |
``Erik: again
I contribute to a discussion I haven't read much about
:) |
| 12:38.43 |
d-lo |
I would
imagine there would have to be minimum Calculational ability and
network latency requirements in order for a 'node' to be accepted
on the AI Compute 'cloud' |
| 12:38.48 |
``Erik |
mebbe the
'repeatably random' notion from upstairs actually DOES have a
practical use |
| 12:39.42 |
``Erik |
custom random
function, each mob has its own seed/state for the
function... |
| 12:40.18 |
``Erik |
with an
occasional key packet to make sure everything is sync'd
up |
| 12:41.04 |
``Erik |
or mebbe it's
not the pig and I'm burning cycles thinking about the wrong thing
:D |
| 12:41.28 |
d-lo |
Server side
has final say on the sync for the simultaneous calcs,
correct? |
| 12:41.39 |
``Erik |
server is
never wrong |
| 12:41.54 |
``Erik |
to prevent
abuse |
| 12:42.59 |
d-lo |
Right, but
putting AI in the hands of the 'Enemy' still makes me
quesy. |
| 12:43.12 |
``Erik |
having the
clients periodically send "this is what I think is happening"
packets and having the server do a quick check might be an
effective way of rooting out cheaters |
| 12:43.50 |
``Erik |
"wow, you
sent a dozen bunk state packets in the last 60 seconds, why don't
you take a breather for an hour disconnect();" |
| 12:45.01 |
``Erik |
meh, an
amusing thought exercise, but optimizing vapor in the end
:/ |
| 12:45.27 |
``Erik |
didja get
time to work on your server component over the weekend? |
| 13:00.52 |
d-lo |
sorry, got
disctracted... 'server component' ? SBEmu or GS? |
| 13:06.37 |
``Erik |
sbemu |
| 13:06.46 |
``Erik |
it's my rdo,
soz I'm not thinking work O:-) |
| 13:06.54 |
d-lo |
Right
on. |
| 13:07.04 |
d-lo |
I am at work
and having trouble thinking work. :) |
| 13:07.09 |
d-lo |
A
bit. |
| 13:07.13 |
d-lo |
Mostly
infrastructure now. |
| 13:07.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 13:07.41 |
d-lo |
Seeing as I
have found myself in the Dev Team Lead, Design Team Lead and
overall PM..... |
| 13:08.05 |
d-lo |
annoying
since that means less time for code. |
| 13:08.05 |
``Erik |
yeah, been
there, done that heh |
| 13:08.38 |
d-lo |
I think the
4th weekend was poor timing for spinning up the SBEmu project, but
thats the way the cards fell. |
| 13:08.45 |
``Erik |
I started
working on a freebsd driver for nvidia cards long ago, other people
joined the cause and I ended up doing less and less code, more and
more dealing iwth people and with nvidia |
| 13:08.56 |
d-lo |
Working to
make the Design team as autonomous as possible. |
| 13:09.25 |
``Erik |
I assume all
the volunteers are code monkeys? |
| 13:10.09 |
d-lo |
Anyone who
doesn't have code skills but are seemingly mature enough to write
up a decent Application are being used on the design
team. |
| 13:10.21 |
d-lo |
They are the
ones who are going to formalize the existing SB game
processess. |
| 13:10.42 |
d-lo |
aka
Class.Race restriction tables, etc. |
| 13:10.53 |
d-lo |
all that junk
that us Devs don't really wanna do :) |
| 13:10.58 |
``Erik |
imagines that with an accessable vcs, irc channel and
skeleton to start from, it'll be fairly
self-organizing |
| 13:11.17 |
``Erik |
right, coders
aren't glorified data entry clerks O:-) |
| 13:11.45 |
d-lo |
Thats what I
am hoping. Now that the holiday weekend is over, I am hoping
things will get rolling. |
| 13:11.49 |
``Erik |
"make the
target modellers do it, not our problem" "butbutbut" *sigh*
:) |
| 13:12.23 |
``Erik |
too bad ya
picked c++ *duck* :D |
| 13:13.35 |
d-lo |
lol. We have
a good solid plan now. Your comment on Java got me thinking and
fired off a discussion on the boards. |
| 13:14.09 |
d-lo |
Java Crypto
doesn't play right with the SB Client, so we need to *at least*
have a C/C++/openSSL proxy running in the server suite. |
| 13:14.23 |
``Erik |
so that means
you're looking to do it in CL using iolib and cl-prevalence (or
elephant? or rucksack?) |
| 13:14.25 |
``Erik |
:D |
| 13:14.56 |
d-lo |
We've rounded
up a good team of Pascal 'grammers and are ready to have at it!
=D |
| 13:15.41 |
``Erik |
I thought I
was clever thinking up an image/event system for fast data storage
only to find a java implementation from a few years ago, and a
paper from '87 about the idea |
| 13:16.21 |
d-lo |
doh! |
| 13:16.27 |
``Erik |
heh, I've
seen people try to write quake style engines in a combination of
pascal and assembly... ahhh, the bad old days of efnet #opengl
:) |
| 13:16.28 |
d-lo |
so... did
they confirm it was a good idea? |
| 13:17.00 |
``Erik |
for a data
set that can stay in memory, it's a really nice solution
*shrug* |
| 13:17.20 |
``Erik |
when you
start looking for bigger data sets, replication, etc, it starts
falling apart |
| 13:17.58 |
``Erik |
but it's
sexier than the orm approach |
| 13:18.17 |
d-lo |
heh, true
:) |
| 13:19.44 |
``Erik |
http://www.prevayler.org/ |
| 13:26.09 |
d-lo |
good link.
thanks :) |
| 13:28.55 |
``Erik |
is somewhat amused that BRL-CAD does not compile on
brlcad.org :) |
| 13:29.26 |
``Erik |
(c++ template
fudgetry in libpc) |
| 13:40.45 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) |
| 14:51.08 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:29.05 |
elena |
starseeker? |
| 15:34.03 |
d-lo |
He's around,
what's up? |
| 15:44.41 |
elena |
hi. |
| 15:44.47 |
starseeker |
hey
elena |
| 15:44.52 |
elena |
just
requesting some help |
| 15:44.56 |
starseeker |
sure, what's
up? |
| 15:45.19 |
elena |
i need some
help with setting up brlcad on the server. |
| 15:45.33 |
elena |
Erik did it
for me yesterday |
| 15:45.53 |
starseeker |
OK... |
| 15:45.54 |
elena |
but there's
on more variable LD_LIBRARY_PATH that needs to be set. |
| 15:46.16 |
starseeker |
you mean in
the system LD_LIBRARY_PATH/ |
| 15:46.19 |
starseeker |
? |
| 15:46.34 |
elena |
yes. i
guess. |
| 15:46.52 |
elena |
in my
account, erik showed me to use export ..... |
| 15:46.53 |
starseeker |
depending on
how you're launching things, you should be able to set that
locally |
| 15:46.57 |
starseeker |
right |
| 15:47.05 |
elena |
but i need it
to work in apache's account, too. |
| 15:47.11 |
starseeker |
ah |
| 15:47.44 |
``Erik |
hrm, php
doesn't have a setenv() equivalent? |
| 15:48.06 |
``Erik |
(once the
migration happens, this problem disappears, btw) |
| 15:48.12 |
elena |
hi
Erik. |
| 15:48.19 |
elena |
maybe it
does. |
| 15:48.27 |
starseeker |
hands elena to the *BSD guru |
| 15:49.05 |
elena |
yes. it has
something. i just imagined it's better to have it set
properly. |
| 15:49.11 |
elena |
whatever that
means :) |
| 15:49.23 |
starseeker |
the quick fix
is probably to tack it onto the system LD_LIBRARY_PATH, but I'm not
sure where to do that on BSD and I probably don't have the admin
rights anyhow |
| 15:49.35 |
elena |
so, should I
implement it on my side? |
| 15:49.39 |
starseeker |
(at least, I
don't think so...) |
| 15:49.56 |
starseeker |
elena: If you
can set it yourself, that's more robust |
| 15:50.04 |
elena |
ok. |
| 15:51.01 |
elena |
thank
you. |
| 15:51.30 |
elena |
and, Erik,
thanks again for yesterday. |
| 15:52.51 |
``Erik |
np, elena,
that's what I'm here for O.o |
| 16:00.27 |
``Erik |
ok, I
regenerated the ld hints file, it SHOULD work without settig the
env variable, I think |
| 16:01.07 |
``Erik |
d'no why tcl
isn't sharing rpath info with libbu, though :/ |
| 16:01.18 |
elena |
testing |
| 16:01.29 |
elena |
yep. it
works. |
| 16:01.54 |
elena |
i'll revert
my changes. |
| 16:08.48 |
elena |
http://more.brlcad.org/ partially
working. |
| 16:08.59 |
elena |
bug: title is
not retrieved correctly. |
| 16:09.21 |
d-lo |
Gotta
admit... I like the layout and color scheme! |
| 16:09.31 |
elena |
bug: raytrace
images created in the wrong directory. |
| 16:10.26 |
elena |
local file
selection (ie. uploading through ftp/scp) works, but it's not
enabled. |
| 16:10.54 |
elena |
theme is open
source. i like it, too :) |
| 16:34.10 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:55.00 |
starseeker |
elena:
nifty! |
| 16:58.52 |
elena |
:) |
| 17:13.09 |
``Erik |
green and
beige, seems a bit... armyish *duck* :D |
| 17:13.32 |
starseeker |
neutral and
environmentally friendly ;-) |
| 17:13.50 |
starseeker |
has been watching too much HGTV |
| 17:14.16 |
``Erik |
what, the
color scheme, or the army? if it's the latter, I might have to
explain a few things to ya ;> |
| 17:14.30 |
starseeker |
heh |
| 17:14.42 |
``Erik |
got my bsd
hack box running, w00t |
| 17:23.15 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 17:34.56 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 17:47.26 |
CIA-32 |
BRL-CAD:
03jdoliner * r34975
10/brlcad/trunk/src/proc-db/brepintersect.cpp: |
| 17:47.28 |
CIA-32 |
BRL-CAD: The
first step in the long processes of implementing the methods for
keeping |
| 17:47.30 |
CIA-32 |
BRL-CAD:
track of intersection data we get out in order the reconstruct the
mesh later. |
| 17:47.32 |
CIA-32 |
BRL-CAD:
Implements a class with the specific responsibility of keeping
track of the |
| 17:47.34 |
CIA-32 |
BRL-CAD:
intersections in the triangles to later reconstruct the
faces. |
| 17:48.14 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 19:29.10 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 19:55.24 |
*** join/#brlcad alecs1
(i=alex@193.170.135.119) |
| 19:58.24 |
alecs1 |
hi, I would
like to add some tolerancing information to some brl-cad
structures |
| 19:58.53 |
alecs1 |
the first
idea is to just add a pointer to custom data to the
primitives |
| 19:59.20 |
alecs1 |
and then
create some data structures for the types of tolerances I might
need |
| 19:59.50 |
alecs1 |
but if
there's some plan of how to do it properly I would love to
integrate my work with that |
| 20:00.11 |
alecs1 |
how would you
suggest to go about it? |
| 20:01.49 |
jdoliner |
which
structure were you looking at? |
| 20:05.22 |
alecs1 |
first the
rcc |
| 20:06.02 |
*** join/#brlcad docelic
(n=docelic@78.134.207.99) |
| 20:06.45 |
alecs1 |
here's the
original thread where I asked long ago:
http://sourceforge.net/mailarchive/message.php?msg_id=15b5efbc0904270528tb2ebb13y8110236e67d65439%40mail.gmail.com |
| 20:25.56 |
``Erik |
*readreadread* hm, and brlcad answered
you... are attributes not sufficient? |
| 20:30.50 |
alecs1 |
I don't know;
variant c) from the reply looked like and attractive and easy way
to get accustomed to brl-cad code |
| 20:32.07 |
``Erik |
funny, it
looks like the least easy to me :D |
| 20:32.35 |
``Erik |
a looks like
the easiest and most simple to me *shrug* |
| 20:34.36 |
alecs1 |
look at it
from the pov of a guy that doesn't know too much about brl-cad; a
programmer's first idea is to just add one more data structure
:) |
| 20:34.46 |
CIA-32 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1539 10/wiki/More_Changelog: July 6 activity. |
| 20:35.23 |
``Erik |
'cept we have
to maintain backwards compatability for the saved files |
| 20:38.52 |
starseeker |
brlcad: I
think we found your next car: http://www.wired.com/reviews/product/pr_veyron_convertible |
| 20:41.04 |
elena |
i open a
database in read-only mode. I type title |
| 20:41.15 |
elena |
and I get
"Sorry, this database is READ-ONLY." |
| 20:41.20 |
elena |
why is
that? |
| 20:41.58 |
starseeker |
I'm guessing
bug |
| 20:42.14 |
elena |
that's in
7.14.9. |
| 20:42.24 |
elena |
in 7.10.4
works ok. |
| 20:43.07 |
starseeker |
Bob's on
it |
| 20:43.32 |
starseeker |
Bob's fixed
it |
| 20:43.56 |
elena |
:) |
| 20:44.24 |
elena |
bob's quick.
I should look for a meaner bug :) |
| 20:45.35 |
``Erik |
do not anger
the bob! |
| 20:47.06 |
CIA-32 |
BRL-CAD:
03bob1961 * r34976 10/brlcad/trunk/src/libged/title.c: Check if
read-only only if modifying the title. |
| 20:48.00 |
starseeker |
possibly the
fastest bug turnaround ever :-P |
| 20:48.32 |
elena |
thanks. now I
can go to bed happy. |
| 20:48.38 |
elena |
bye. |
| 20:50.21 |
*** join/#brlcad sander^
(n=sander@97.178.16.62.customer.cdi.no) |
| 21:22.54 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 21:55.20 |
Ralith |
d-lo: right;
just getting a bit discouraged with all the things not
working. |
| 21:55.36 |
Ralith |
Still got
some stuff left to test in the qt-hacking area before I move on to
the ogre-centric approach, though |
| 21:57.30 |
*** join/#brlcad _sushi_
(n=_sushi_@84-73-204-124.dclient.hispeed.ch) |
| 22:11.51 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 22:29.26 |
*** join/#brlcad tegtmeye
(n=tegtmeye@bz.bzflag.bz) |
| 22:29.46 |
tegtmeye |
ping
brlcad |
| 22:31.37 |
``Erik |
he hasn't
said anything all day, I think he was heading to some rowing thing
u p north for the weekend, he might be chumming or on his way back
(or recovering) |
| 22:32.33 |
tegtmeye |
ot an
interesting cad bug |
| 22:33.03 |
tegtmeye |
os x 10.5 seg
fault with two monitors connected |
| 22:33.06 |
tegtmeye |
works ok with
one |
| 22:33.57 |
tegtmeye |
hear that
there is no working version w/10.5 currently? |
| 22:33.59 |
``Erik |
funky, my
only 10.5 box is my laptop, so no dual head :/ |
| 22:34.02 |
tegtmeye |
is that
correct? |
| 22:34.09 |
tegtmeye |
jsut found
it |
| 22:34.09 |
``Erik |
but I thought
his desktop was on 10.5 |
| 22:34.22 |
tegtmeye |
brlcads? |
| 22:34.24 |
``Erik |
it works on
my laptop *shrug* |
| 22:34.25 |
``Erik |
yeah |
| 22:34.51 |
tegtmeye |
can't find
any bugreports for this but someone overthere says its a known
issue |
| 22:35.41 |
tegtmeye |
trying to get
it into ports over here |
| 22:37.08 |
tegtmeye |
I'll track
him down tomorrow, thanks |
| 00:00.11 |
mdavis |
no no!
Displacement maps |
| 00:00.17 |
mdavis |
(although
digital signal processors are very interesting too) |
| 00:00.47 |
``Erik |
I'm sure
there's some knowedge in the channel |
| 00:01.43 |
mdavis |
well...I am
using 7.14.8...whenever I try to evaluate a DSP, it says invalid
NMG |
| 00:02.05 |
mdavis |
or something
of that sort about NMGs..earlier, I even got a NULL pointer
something or another |
| 00:03.43 |
Ralith |
that sounds
serious :/ |
| 00:03.45 |
Ralith |
doing
anything weird? |
| 00:10.54 |
brlcad |
ah, mdavis --
you're trying to export to some polygonal format? |
| 00:10.56 |
mdavis |
well |
| 00:11.02 |
mdavis |
yes...i want
to export g-stl |
| 00:11.14 |
mdavis |
and I would
also like to do an ev -w |
| 00:11.15 |
mdavis |
or even just
an ev |
| 00:11.43 |
mdavis |
I spent 36
hours trying to generate an STL of a DSP just for it to go
kaput |
| 00:11.54 |
brlcad |
they all end
up calling the same nmg routines |
| 00:12.09 |
brlcad |
can you
provide the .g file with the dsp somewhere? |
| 00:12.17 |
mdavis |
certainly..give me a second |
| 00:12.24 |
brlcad |
sounds like a
bug of course |
| 00:12.52 |
brlcad |
anything
unusual about the dsp? |
| 00:13.28 |
mdavis |
well...the
one I was really working on was just a plump parabola...this test
file just has 6 points or so in it for testing |
| 00:13.29 |
*** join/#brlcad stevegt_1
(n=stevegt@cislunar.TerraLuna.Org) |
| 00:13.47 |
brlcad |
and
presumably it raytraces okay? |
| 00:13.55 |
mdavis |
Haven't tried
that..let me see.. |
| 00:14.27 |
brlcad |
either way,
can post up details and the .g here:
https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802 |
| 00:14.49 |
brlcad |
I can take a
look at it for a little bit tonight, but there others can also take
a peek at it |
| 00:15.33 |
mdavis |
Raytraces
fine |
| 00:15.42 |
mdavis |
visit
autolich.com/test.dsp and autolich.com/test.g |
| 00:15.43 |
brlcad |
good |
| 00:16.54 |
brlcad |
404 on
both |
| 00:16.58 |
mdavis |
This file
just has the values 12,15,17,14,11,25 |
| 00:17.01 |
mdavis |
please
retry |
| 00:18.33 |
``Erik |
facetize
works fine on it |
| 00:18.34 |
brlcad |
I can
reproduce the bug here, great! |
| 00:18.49 |
mdavis |
by the
way..although it goes without saying...despite the bug, BRL-CAD is
truly awesome and I am VERY appreciative |
| 00:18.57 |
stevegt_1 |
Hey all --
anyone know the total size of the svn repository (all changesets,
not just current)? I'm wondering how practical it is to replicate
it to a local hg repository for faster history searches etc.
Based on progress so far I'm guessing it's about a half
gig... |
| 00:19.02 |
brlcad |
ah, nice
catch ``Erik |
| 00:19.10 |
brlcad |
that's
probably a workable workaround |
| 00:19.32 |
brlcad |
mdavis: run
"facetize test.bot test.s", then g-stl test.bot instead of the
.s |
| 00:19.36 |
mdavis |
I'm afraid I
don't know facetize |
| 00:19.51 |
``Erik |
well, it
means the nmg routines are ok with it, g-stl must be retarded.
mebbe i doesn't load the .dsp file correctly |
| 00:19.52 |
mdavis |
ok..let's
se |
| 00:19.52 |
mdavis |
see |
| 00:20.12 |
``Erik |
mdavis: it's
a command in mged, creates a 'bot' object, a bunch of
triangles |
| 00:20.47 |
``Erik |
(Bag O'
Triangles, your usual triangle soup) |
| 00:21.38 |
``Erik |
yeah,
facetize and g-stl works fine, g-stl on the dsp fails |
| 00:22.10 |
``Erik |
mged -c
test.g facetize test.f test.s && g-stl -o test.stl test.g
test.f |
| 00:22.12 |
brlcad |
ev also fails
like he mentioned, so there is some mutual stupidity going
on |
| 00:24.12 |
mdavis |
my processor
is blazing up.... |
| 00:24.38 |
mdavis |
shoot..ran it
on the wrong file (the one with the big shape) and the computer
freaked out |
| 00:24.42 |
mdavis |
trying
again |
| 00:25.57 |
mdavis |
OK..I did it
and it likes it |
| 00:26.02 |
mdavis |
have a nice
test.bot |
| 00:26.19 |
stevegt_1 |
...speaking
of history, does anyone know what the a_rbeam member of the rt
application structure is all about? It's supposed to be ray beam
width, but it looks like it may have never been completely
implemented. I was hoping to use it to simulate a laser cut, but
rt_shootray returns the same results no matter what I set it
to. |
| 00:27.46 |
``Erik |
implementation of a non-zero diameter ray
has been discussed for many many years, you may've hit the nail on
the head, stevegt_1 :/ |
| 00:28.41 |
*** join/#brlcad docelic
(n=docelic@78.134.202.119) |
| 00:29.11 |
mdavis |
This thing is
working great now |
| 00:29.17 |
mdavis |
Thanks a
lot!! |
| 00:29.43 |
brlcad |
thanks for
reporting the problem |
| 00:30.05 |
brlcad |
feel free to
use that tracker if you've found other problems, possibly ones
you've since worked around even, or if something new comes
up |
| 00:30.10 |
``Erik |
yeah, I
imagine g-stl on a dsp is going to be working ok in the next few
days O.o |
| 00:30.51 |
stevegt_1 |
Erik: thanks
-- thought so. This line of code in prep.c is sooo tantalyzing:
rtip->rti_max_beam_radius = 175.0/2; /* Largest Army
bullet */ |
| 00:30.56 |
stevegt_1 |
;-) |
| 00:31.19 |
brlcad |
heh |
| 00:31.28 |
``Erik |
interest
comment |
| 00:31.41 |
``Erik |
s/
c/ing&/ |
| 00:34.28 |
*** join/#brlcad stevegt``
(n=stevegt@cislunar.TerraLuna.Org) |
| 00:35.14 |
stevegt_1 |
gotta unplug
-- back in a couple hours, i think |
| 00:38.40 |
brlcad |
cya
stevegt_1 |
| 01:46.54 |
brlcad |
``Erik: you
have 10.5 on your lappy? |
| 01:47.44 |
brlcad |
if you do,
you see a crash if you configure --with-ogl and "attach ogl" in
mged? |
| 02:06.13 |
*** join/#brlcad stevegt_
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 03:16.04 |
``Erik |
compiling |
| 03:19.27 |
yukonbob |
hello,
cadheads |
| 04:20.58 |
``Erik |
it eated my
X |
| 04:24.53 |
``Erik |
http://brlcad.org/~erik/Xcrash.txt |
| 04:27.24 |
Ralith |
nom |
| 06:27.21 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 06:29.46 |
CIA-32 |
BRL-CAD:
0395.133.217.16 07http://brlcad.org
* r1543 10/wiki/Main_Page: |
| 07:25.41 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 08:10.13 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:11.28 |
CIA-32 |
BRL-CAD:
03d_rossberg * r34993
10/brlcad/trunk/src/libged/make_pnts.c: |
| 08:11.28 |
CIA-32 |
BRL-CAD:
replaced c99 idioms with c89 compatible ones |
| 08:11.30 |
CIA-32 |
BRL-CAD: a
const specifier in ged_make_pnts still need some
consideration |
| 08:17.38 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 09:24.01 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1544 10/wiki/User:Ralith: Log for 2009-07-06 |
| 09:31.45 |
CIA-32 |
BRL-CAD:
03jdoliner * r34994 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
Added functions SegmentPolylineIntersect which is hopefully self
explanatory in nature and Triangulate which takes an array of
Polylines and renders the polygon as triangles, the later is
presently a work in progress |
| 09:53.59 |
*** join/#brlcad Don__
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 09:54.44 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
| 09:56.11 |
*** join/#brlcad pacman872
(n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 10:07.11 |
*** join/#brlcad mafm (n=mafm@83.42.152.74) |
| 10:26.39 |
d-lo |
Merinin
all |
| 10:27.17 |
d-lo |
Ralith: Hows
it goin? I see the log entries, but its not telling me much
:/ |
| 10:28.36 |
d-lo |
Since g3d
isn't directly in the build structure of rt^3 (and rt^3 isnt a
production module) is there any way I can get you to start checking
in your attempts? (Regardless of whether they work or
not) |
| 10:28.55 |
d-lo |
No one can
provide help/guidance if we can't see the code :/ |
| 11:07.30 |
CIA-32 |
BRL-CAD:
03brlcad * r34995
10/brlcad/trunk/src/librt/primitives/nmg/nmg_ck.c: |
| 11:07.32 |
CIA-32 |
BRL-CAD:
revert a change introduced in revision 8121, Mon Dec 27 22:46:05
1993, where the |
| 11:07.34 |
CIA-32 |
BRL-CAD:
min_pt/max_pt comparison was (inadvertently?) changed from > to
>= which is |
| 11:07.36 |
CIA-32 |
BRL-CAD:
causing facetization problems when the structure is empty. this in
turn causes |
| 11:07.38 |
CIA-32 |
BRL-CAD:
tools that use nmg_triangulate_model() to incorrectly fail (e.g.,
g-stl). |
| 11:08.50 |
d-lo |
Wow...
1993 |
| 11:09.09 |
d-lo |
i was... a
sophmore in HS.... wow. |
| 11:20.24 |
CIA-32 |
BRL-CAD:
03brlcad * r34996
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: fix geomtry
typo |
| 11:55.56 |
CIA-32 |
BRL-CAD:
03brlcad * r34997 10/brlcad/trunk/NEWS: |
| 11:55.58 |
CIA-32 |
BRL-CAD:
fixed Invalid NMG empty output bug in g-stl that was reported by
mdavis (irc) |
| 11:56.00 |
CIA-32 |
BRL-CAD: that
was causing the tool to exit early. the problem seems to be
two-fold, that |
| 11:56.02 |
CIA-32 |
BRL-CAD: the
nmg_vface() routine had a minor logic error thinking it needs to
abort and |
| 11:56.04 |
CIA-32 |
BRL-CAD: the
nmg coming out of the dsp's tess routine is possibly an
incomplete |
| 11:56.06 |
CIA-32 |
BRL-CAD:
structure. |
| 12:30.38 |
brlcad |
is still hunting for the dsp bug, but is losing
steam |
| 12:31.09 |
``Erik |
the commits
weren't for that? O.o |
| 12:32.13 |
brlcad |
it fixed half
the problem |
| 12:32.42 |
brlcad |
dsp's tess()
is doing something wrong in the construction of the nmg, that's
what triggered the validity failure |
| 12:33.08 |
``Erik |
shouldn't
that trigger on the facetize cmd? |
| 12:33.14 |
brlcad |
the validity
failure was weak, but arguably correct -- facetize happens to work
simply because it doesn't validate |
| 12:33.25 |
``Erik |
ahhh |
| 12:33.49 |
``Erik |
HrrrmmMMmmMMmmm |
| 12:34.44 |
``Erik |
non-validated
facetization would be far faster and throw less away if the
converter doesn't especially require a topologically closed
surface, yes? |
| 12:34.54 |
``Erik |
is thinking g-adrt shtuff |
| 12:35.09 |
*** join/#brlcad docelic_
(n=docelic@78.134.197.78) |
| 12:54.46 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 13:02.00 |
CIA-32 |
BRL-CAD:
03brlcad * r34998
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: mass
consistency/ws/style/comment cleanup while browsing |
| 13:02.03 |
brlcad |
this isn't
"non-solid" validation |
| 13:02.20 |
brlcad |
this is "is
the data structure being used and filled in the way it's supposed
to" |
| 13:02.51 |
brlcad |
validating
that there is geometry associated with an edge for every face, for
example |
| 13:07.07 |
CIA-32 |
BRL-CAD:
03brlcad * r34999
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: couple more
stragglers missed |
| 13:58.45 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35000 10/brlcad/trunk/src/adrt/ (Makefile.am
slave/load_g.c): begin the ability to load a .g database into
adrt |
| 13:58.56 |
brlcad |
woot |
| 14:04.18 |
``Erik |
:r
../../conv/g-egg.c and some cleanup heh, nothing to w00t about
:D |
| 14:04.38 |
``Erik |
(neat rev #,
tho) |
| 14:04.45 |
brlcad |
that was the
woot :) |
| 14:04.56 |
``Erik |
ah |
| 14:11.29 |
d-lo |
brlcad: You
in today? |
| 14:11.43 |
d-lo |
also, might
wanna get a hotel... they are going faaaaast. |
| 14:11.47 |
d-lo |
;) |
| 14:11.55 |
*** join/#brlcad BigAToo
(n=BigAToo@64.74.225.82) |
| 14:22.34 |
brlcad |
d-lo: soon as
I find this bug or give up, but I've got too much invested to go
just yet |
| 14:24.47 |
d-lo |
okay. Just
giving you a heads up. 2 hotels dropped off the available list
since I started this morning :/ |
| 14:53.36 |
brlcad |
woo hoo,
think I got it |
| 14:54.14 |
brlcad |
they come on
and go off repeatedly as rooms are released and rescheduled, you
can sometimes watch and get lucky even |
| 14:55.10 |
*** join/#brlcad alex_joni
(n=juve@emc/board-of-directors/alexjoni) |
| 15:02.49 |
CIA-32 |
BRL-CAD:
03brlcad * r35001
10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: |
| 15:02.51 |
CIA-32 |
BRL-CAD:
found the remaining bug that was provoking the dsp to not validate
(nmg_vface() |
| 15:02.56 |
CIA-32 |
BRL-CAD:
failure and 'nmg_unbreak_handler: no geometry for edge' failures).
the problem |
| 15:03.00 |
CIA-32 |
BRL-CAD: was
some final dsp region cleanup to mark the edges as real and compute
the |
| 15:03.02 |
CIA-32 |
BRL-CAD:
region/shell/edge-level geometry. |
| 15:03.06 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35002 10/isst/trunk/src/ (gui.c isst.h sql.c):
use bu_vls for database and host names. Trim whitespace around
names. |
| 15:06.35 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 15:07.50 |
brlcad |
might want to
s/strncpy/bu_strlcpy/ on those buffers |
| 15:08.57 |
``Erik |
iirc, strlcpy
isn't everywhere (and I thought I did s/strncpy/bu_vls/strcpy/
) |
| 15:09.15 |
brlcad |
bu_strlcpy |
| 15:09.20 |
brlcad |
we have a
wrapper |
| 15:09.52 |
brlcad |
implements it
if strlcpy isn't available, otherwise identical
signature |
| 15:10.19 |
brlcad |
bu_strlcat
too, but didn't see those in use |
| 15:12.23 |
elena |
interesting.
i never meet strlcpy before. |
| 15:12.31 |
elena |
learns new thing |
| 15:17.33 |
``Erik |
after lunch
:D |
| 15:27.06 |
*** join/#brlcad mafm (n=mafm@83.42.152.74) |
| 15:29.14 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 17:14.13 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:33.02 |
jdoliner |
indianlarry? |
| 17:33.10 |
jdoliner |
are you
around/ did you get my email? |
| 17:37.40 |
indianlarry |
hey
joe |
| 17:37.55 |
indianlarry |
yes i got
your email and will try and look into this evening |
| 17:39.20 |
jdoliner |
cool |
| 17:41.29 |
``Erik |
mmm, green
turtle |
| 17:45.59 |
``Erik |
fails to see what bu_strlcpy will buy over bu_strcpy in this
situation |
| 17:47.11 |
``Erik |
can't buffer
overflow and the gtk side guarantees the null terminator
O.o |
| 18:05.58 |
brlcad |
probably
nothing, I just noticed one unadorned strncpy from the original
code |
| 18:06.54 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35003 10/brlcad/trunk/src/adrt/slave/load.c: get
load working again. meh. |
| 18:10.48 |
``Erik |
original code
used char hostname[64]; and strncpy to avoid running
past |
| 18:11.37 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35004 10/isst/trunk/src/gui.c: attempt to fill
database and master hostnames using envirnment
variables |
| 18:11.37 |
``Erik |
there're
still a couple static string buffers left |
| 18:13.07 |
brlcad |
``Erik:
what's the diff between field strength and threshold |
| 18:13.32 |
``Erik |
field
strength is per point, threshold is throughout the entire
primitive |
| 18:14.10 |
brlcad |
how do they
play together? |
| 18:14.12 |
``Erik |
intends to make a wiki page (and eventually form 1
report) |
| 18:14.22 |
brlcad |
if I set a
non-zero field strength on all points, is threhold
ignored? |
| 18:14.29 |
``Erik |
no |
| 18:14.30 |
brlcad |
and
vice-versa |
| 18:15.24 |
``Erik |
they work
together, if you take a point of consideration, field strength and
distance are used to compute the points contribution, if the sum of
all points contribution is above the threshold, you are inside,
otherwise you're outside |
| 18:16.34 |
``Erik |
with a single
control point, strength 1 and threshold one... changing str to 2
and leaving threshold 1 will have the same effect as leaving str 1
and changing threshold to .5 |
| 18:16.46 |
brlcad |
so random
field strengths + zero threshold is a bunch of spheres no matter
how close |
| 18:17.07 |
``Erik |
0 threshold
means every point in existence is inside of the
metaball |
| 18:18.23 |
``Erik |
the formulae
are tuned so threshold=1 is "natural" |
| 18:18.37 |
brlcad |
then is
threshold distance-based (size/units-dependent?) |
| 18:18.46 |
brlcad |
what does
natural mean? :) |
| 18:19.05 |
``Erik |
threshold=1,
1 control point, fldstr=400 means a 400 unit radius
sphere |
| 18:19.43 |
``Erik |
(there's a
reason for that, in s2) |
| 18:20.00 |
brlcad |
okay, so not
distance |
| 18:20.01 |
``Erik |
but 99.999%
of outside usage will want threshold=1 |
| 18:20.48 |
brlcad |
what is
method? |
| 18:21.00 |
``Erik |
different
algorithms O.o |
| 18:21.11 |
``Erik |
crafting an
explanation email? heh |
| 18:21.20 |
brlcad |
writing
code |
| 18:21.25 |
``Erik |
ah |
| 18:21.59 |
jdoliner |
what do our
metaballs use as their falloff function? |
| 18:22.13 |
``Erik |
jdoliner:
that's what method defines... :D |
| 18:22.43 |
jdoliner |
I
see |
| 18:23.03 |
``Erik |
src/librt/primitives/metaball/metaball.c
starting at line 244 |
| 18:23.07 |
jdoliner |
so we provide
a number of different options |
| 18:23.11 |
jdoliner |
reading |
| 18:23.25 |
brlcad |
okay, more to
the point of this.. which 'method' should I use? don't see any API
defines/enums, so 0, 1, 42? |
| 18:24.05 |
``Erik |
'iso' is the
same formula used to compute gravity or point charge strenght, blob
is the '82 blinn blobby surface method, the unimplemented one is
the tokyo metaball approximation |
| 18:24.45 |
``Erik |
defines are
in metaball.c:67 (should move those to rtgeom.h or raytrace.h if
people want to muck with the programatically) |
| 18:24.50 |
``Erik |
here, lemme
do that |
| 18:25.07 |
brlcad |
found
em |
| 18:25.25 |
jdoliner |
so is is
inverse square |
| 18:25.38 |
brlcad |
an enum in
wdb.h would work well since it needs it for mk_metaball |
| 18:27.33 |
``Erik |
oh, I was
putting it in rtgeom heh |
| 18:29.10 |
``Erik |
contemplates rtgeomo.h vs wdb.h |
| 18:29.13 |
CIA-32 |
BRL-CAD:
03irpguardian * r35005
10/brlcad/trunk/src/proc-db/human.c: |
| 18:29.15 |
CIA-32 |
BRL-CAD: Made
all limbs join together smoothly with themselves. Also added a
feature to allow the creation |
| 18:29.17 |
CIA-32 |
BRL-CAD: of
many humans at once using the -N command. |
| 18:30.05 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35006 10/brlcad/trunk/ (include/rtgeom.h
src/librt/primitives/metaball/metaball.c): move metaball method
definitions to a public header |
| 18:50.50 |
brlcad |
heh |
| 18:50.59 |
brlcad |
``Erik: have
you actually used mk_metaball anywhere yet? :) |
| 18:51.18 |
``Erik |
hmmmm,
newp? |
| 18:51.33 |
brlcad |
k, didn't
think you had :) |
| 18:51.35 |
``Erik |
don't think
so |
| 18:52.59 |
brlcad |
the *verts[5]
is a bit of a pita to work with :) |
| 18:53.09 |
brlcad |
at least if
you have dynamic sets, having to allocate your points |
| 18:53.37 |
``Erik |
*shrug* so
make it a bu list |
| 18:53.59 |
``Erik |
I think I was
starting to put that together to support the proc-db |
| 18:54.04 |
``Erik |
and got
distracted |
| 18:54.11 |
``Erik |
or, rather,
redirected |
| 18:54.49 |
CIA-32 |
BRL-CAD:
03brlcad * r35007 10/brlcad/trunk/src/libwdb/wdb.c: fix an infinite
loop and add the points in the order the user specified (in case
it's significant for their usage, e.g. printing) |
| 18:55.19 |
``Erik |
last
halloween even heh, with the log of "stubbed out..." |
| 19:11.31 |
brlcad |
gah,
rt_metaball_point_value_metaball() No implemented |
| 19:12.29 |
brlcad |
of course
method "0" isn't implemented apparently.. |
| 19:17.07 |
CIA-32 |
BRL-CAD:
03brlcad * r35008
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: don't
bu_exit() inside the library as it cannot be caught like bu_bomb.
clean up indent on STEPBACK too with a semi |
| 19:20.20 |
CIA-32 |
BRL-CAD:
03brlcad * r35009
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: ws,
comment cleanup |
| 19:25.11 |
``Erik |
method 0 is
the tokyo metaball, was redirected |
| 19:26.50 |
brlcad |
http://brlcad.org/tmp/mbug/mbug.png |
| 19:27.18 |
brlcad |
tis
viewing-angle specific |
| 19:27.23 |
brlcad |
.g is up
there |
| 19:27.51 |
brlcad |
is that
right? |
| 19:30.29 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 19:42.34 |
CIA-32 |
BRL-CAD:
03brlcad * r35010
10/brlcad/trunk/src/proc-db/metaball.c: |
| 19:42.36 |
CIA-32 |
BRL-CAD:
hijack the stubbed metaballs example with something entirely
different. this |
| 19:42.38 |
CIA-32 |
BRL-CAD: one
creates a couple metaballs using the (now working) mk_metaball()
routine as |
| 19:42.40 |
CIA-32 |
BRL-CAD: a
means to show creation, and next manipulation. to be added is how
to read |
| 19:42.45 |
CIA-32 |
BRL-CAD: them
back in from the .g and combine them into one
megametaball. |
| 19:49.21 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 19:51.40 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35011 10/brlcad/trunk/src/adrt/slave/load_g.c:
eliminate verbose stuff. wire stuff together. |
| 19:53.02 |
``Erik |
that don't
look right O.O |
| 20:23.30 |
brlcad |
welp, I just
finished debugging a hellish bug early this morning, so that one is
up to you! |
| 20:41.47 |
Ralith |
hehe |
| 20:42.07 |
starseeker |
Ralith: any
more luck with Ogre+Qt? |
| 20:42.59 |
Ralith |
starseeker:
none yet, nope; if I can't find anything useful in the GL intercept
results I'll try the ogre centric approach |
| 20:43.28 |
Ralith |
it's getting
pretty frustrating :/ |
| 20:45.22 |
CIA-32 |
BRL-CAD:
03brlcad * r35012
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: minor
cleanup, implement rt_metaball_free() |
| 20:45.36 |
brlcad |
Ralith: did
you see d-lo's comments earlier today? |
| 20:46.05 |
Ralith |
brlcad: have
now. |
| 20:46.09 |
brlcad |
you gotta
commit something, else nobody can help -- even if it doesn't
work |
| 20:47.01 |
Ralith |
alright, I'll
try to. Haven't been doing so because it's been much more casting
around across a wide variety of ideas than focusing on a particular
approach. |
| 20:47.21 |
brlcad |
trying ideas
is fine, but should still be committing |
| 20:47.34 |
Ralith |
kk |
| 20:47.35 |
brlcad |
as often as
you save the file is fine -- i.e., if it compiles, commit
it |
| 20:47.42 |
Ralith |
heh, okay,
okay |
| 20:47.55 |
brlcad |
otherwise "it
doesn't exist" |
| 20:48.06 |
brlcad |
and we have
no idea what you've tried |
| 20:48.09 |
Ralith |
I'll tidy
things up so that the test can be built cleanly without interfering
with old g3d |
| 20:48.21 |
brlcad |
could be you
tried the right idea weeks ago and had a minor bug |
| 20:48.33 |
Ralith |
good
point. |
| 20:48.40 |
brlcad |
don't worry
about the old g3d, we can resurrect that from svn if
needed |
| 20:49.07 |
Ralith |
I'm hesitant
to replace it with nothing but a broken testcase :/ |
| 20:49.11 |
Ralith |
but
alright. |
| 20:50.49 |
brlcad |
if what you
have is a testcase, that could just as easily be added alongside as
well |
| 20:50.58 |
Ralith |
that's what I
was saying |
| 20:51.24 |
brlcad |
how's that
interfere? |
| 20:51.28 |
Ralith |
I mean, it's
a little more involved than that, but it doesn't *do* anything, and
interacts only minimally with the existing g3d
codebase. |
| 20:52.10 |
Ralith |
I'd rewritten
main.cxx to use the QT stuff w/ OgreScene as it would be used in
the working app |
| 20:52.26 |
Ralith |
it would not
be much work to just make all that ifdef'd |
| 20:52.53 |
brlcad |
don't ifdef
it, either replace it or copy the file and commit the "second
binary" |
| 20:52.59 |
Ralith |
at the time I
had expected that I'd have something interesting working with
OgreScene quickly, but seeing as that wasn't the
case... |
| 20:53.23 |
brlcad |
all the more
reason that you gotta be committing even more frequently from now
on, even if busted |
| 20:53.23 |
Ralith |
I'll split
it, then |
| 20:53.33 |
Ralith |
that should
be even easier, actually |
| 20:53.39 |
Ralith |
just a matter
of copy, revert, tweak cmakelists |
| 20:53.46 |
brlcad |
otherwise,
all we have is an ogre commit and irc logs, and I'm sure you've
done more than that |
| 20:55.23 |
starseeker |
Grrr - where
is the "distribute" command used in opennurbs_ext.cpp on line 789
defined?? |
| 20:57.45 |
brlcad |
http://brlcad.org/xref/ident?i=distribute |
| 20:59.05 |
brlcad |
or were you
using emacs, "make tags", then cursor over the word distribute on
that line and hit M-. then enter |
| 20:59.37 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35013 10/isst/trunk/src/gui.c: stub in .g
loading shtuff |
| 20:59.39 |
brlcad |
http://brlcad.org/xref/source/src/librt/opennurbs_ext.cpp
<-- starting poitn |
| 21:00.24 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35014 10/brlcad/trunk/src/adrt/slave/load_g.c:
parse string into filename/treename |
| 21:01.05 |
brlcad |
gives ``Erik cheesypoofs |
| 21:01.31 |
starseeker |
is surprised - i thought opennurbs_ext was compiled before
brep |
| 21:02.12 |
``Erik |
heh |
| 21:04.44 |
brlcad |
starseeker:
doesn't matter |
| 21:04.49 |
CIA-32 |
BRL-CAD:
03brlcad * r35015 10/brlcad/trunk/src/libbu/bomb.c: |
| 21:04.51 |
CIA-32 |
BRL-CAD:
annotate that bu_exit() should generally not be called by library
code. it's |
| 21:04.53 |
CIA-32 |
BRL-CAD:
intended use is by application codes for graceful exit. there are a
few |
| 21:04.55 |
CIA-32 |
BRL-CAD:
exceptions, but since the exit is not catchable, it's not very
polite to |
| 21:04.57 |
CIA-32 |
BRL-CAD:
applications and doesn't give them a chance to handle the situation
or perform |
| 21:04.59 |
CIA-32 |
BRL-CAD:
their own cleanup. |
| 21:05.05 |
``Erik |
gets ready to start screaming "commit" over and over until he
sees a msg from a certain user O:-) |
| 21:08.36 |
CIA-32 |
BRL-CAD:
03brlcad * r35016 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
minor ws/indent consistency cleanup, remove author from
headers |
| 21:12.21 |
CIA-32 |
BRL-CAD:
03r_weiss * r35017 10/brlcad/trunk/src/libged/make_pnts.c:
cleanup |
| 21:12.45 |
``Erik |
thinks he might have adrt sorta kinda loading .g
tomorrow |
| 21:12.58 |
starseeker |
awesome! |
| 21:12.59 |
CIA-32 |
BRL-CAD:
03starseeker * r35018 10/brlcad/trunk/ (4 files in 2 dirs): (log
message trimmed) |
| 21:13.05 |
CIA-32 |
BRL-CAD:
Start cleaning up the opennurbs tree building routines/logic. Would
prefer the |
| 21:13.07 |
CIA-32 |
BRL-CAD:
flatness test to be a per-node affair (like, say, isLeaf) but need
to hit my |
| 21:13.12 |
CIA-32 |
BRL-CAD: head
on it a bit more first. For the time being, since there is still
active |
| 21:13.16 |
CIA-32 |
BRL-CAD:
debugging going on with indianlarry and this approach is not yet
functional, |
| 21:13.20 |
CIA-32 |
BRL-CAD:
sticking it into two temporary files that are EXTRA_DISTed. Once
the trees are |
| 21:13.28 |
CIA-32 |
BRL-CAD:
building successfully in testing, see about rewiring brep.cpp to
use the |
| 21:14.37 |
Ralith |
adrt? |
| 21:14.49 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35019 10/brlcad/trunk/src/adrt/slave/load_g.c:
db_walk_tree wants char**, not char* |
| 21:14.57 |
``Erik |
interactive
distributed raytracer thingymajigger |
| 21:15.49 |
``Erik |
at the
moment, it needs specially prepared geometry in a mysql database...
.g loading would make it so people outside of my office and play
with it... (related to the isst stuff) |
| 21:15.50 |
Ralith |
the really
pretty one? |
| 21:16.09 |
``Erik |
yeah, it's
the engine that did the stryker in slat armor image for the
gallery |
| 21:16.22 |
Ralith |
cool! |
| 21:16.28 |
CIA-32 |
BRL-CAD:
03brlcad * r35020 10/brlcad/trunk/src/librt/ (opennurbs_ext.cpp
primitives/brep/brep.cpp): move the inline distribute() function
over to the only place it's actually used in opennurbs_ext.cpp
until it's actually needed elsewhere (in which case it probably
belongs in the header if it needs to be inline) |
| 21:17.08 |
``Erik |
now I'm going
to roll my old bones home O.o |
| 21:17.36 |
Ralith |
why's adrt
take so much power, btw? just 'cuz raytracing CSG is inherently a
lot of work? |
| 21:18.10 |
brlcad |
no, not
really |
| 21:18.26 |
brlcad |
it's because
it's performing a different style of rendering, global illumination
rendering |
| 21:18.40 |
Ralith |
oh, right,
plain old rt is pretty fast |
| 21:18.43 |
brlcad |
which
requires shooting several orders of magnitude more rays to fully
simulate light transport |
| 21:19.00 |
Ralith |
but I ask
because I've played with other (at least alleged) GI renderers
before that don't take nearly so long |
| 21:19.09 |
Ralith |
raytracers,
that is |
| 21:19.19 |
brlcad |
what are you
comparing to? |
| 21:19.40 |
brlcad |
the time the
stryker image took? |
| 21:19.45 |
Ralith |
yeah |
| 21:19.55 |
brlcad |
most GI
renderers couldn't have handled that scene |
| 21:20.12 |
Ralith |
ahh. why's
that? |
| 21:20.37 |
brlcad |
the level of
detail in there is a bit misleading fromt he picture
alone |
| 21:21.06 |
brlcad |
there aren't
textures in use, there is actually geometry for every single blade
of grass and leaf on tree |
| 21:21.20 |
Ralith |
pulls it up agin |
| 21:21.48 |
brlcad |
not to
mention incredible detail inside the vehicle, every nut bolt and
wire along with all of the internal components, not just a surface
model |
| 21:21.55 |
Ralith |
oh
damn. |
| 21:22.08 |
Ralith |
shame not
much of that is visible |
| 21:22.19 |
Ralith |
had forgotten just how ridiculously detailed that scene
was |
| 21:22.20 |
brlcad |
if it were,
you wouldn't have gotten to see the picture :) |
| 21:22.27 |
Ralith |
hehe |
| 21:22.39 |
Ralith |
what was that
modelled for, anyway? |
| 21:23.37 |
brlcad |
mostly just a
demo |
| 21:23.47 |
Ralith |
that seems
like an incredible amount of modeling work for a demo |
| 21:24.30 |
brlcad |
also notice
the number of rays fired.. 8 *trillion* rays is a lot of
rays |
| 21:24.44 |
Ralith |
enough that
it's hard to get a sense of scale. |
| 21:24.57 |
Ralith |
certainly
did't leave any visible artifacts. |
| 21:26.20 |
Ralith |
what
generated the trees? |
| 21:26.54 |
brlcad |
some plugin,
it was imported |
| 22:12.33 |
``Erik |
the trees and
grass came from blender, iirc |
| 22:13.31 |
``Erik |
adrt/tie
doesn't do CSG, it's straight triangle rendering, but every pixel
is something like 256 primary rays... in a path tracing system
O.o |
| 22:13.45 |
``Erik |
(antialiasing, depth of field,
etc) |
| 22:14.45 |
``Erik |
with a simple
phong shader, it renders a couple dozen 1024x768 frames a
second |
| 22:15.20 |
``Erik |
(it doesn't
require much power at all, that's why it can go above and beyond
like that styker image) |
| 22:35.39 |
CIA-32 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1545 10/wiki/More_Changelog: July 8 activity |
| 00:07.03 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:09.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 00:42.06 |
CIA-32 |
BRL-CAD:
03brlcad * r35021 10/brlcad/trunk/src/libwdb/wdb.c: missed a
commit.. have to initialize the ctrl head else bad things
happen |
| 00:46.30 |
CIA-32 |
BRL-CAD:
03brlcad * r35022 10/brlcad/trunk/ (4 files in 4 dirs): |
| 00:46.32 |
CIA-32 |
BRL-CAD:
deprecate the rather useless bu_fopen_uniq() .. would remove it
given it's only |
| 00:46.34 |
CIA-32 |
BRL-CAD: in
use in one place (dsp plot debug code), but don't know if anyone
has relied |
| 00:46.36 |
CIA-32 |
BRL-CAD: on
it. go ahead and schedule it for removal. update dsp to just use
fopen |
| 00:46.38 |
CIA-32 |
BRL-CAD:
instead. |
| 01:07.58 |
CIA-32 |
BRL-CAD:
03brlcad * r35023 10/brlcad/trunk/src/libbu/ (fopen_uniq.c image.c
rb_extreme.c rb_internals.h): remove all calls to bu_exit().
shouldn't be used by library code even for fatal situations. use
bu_bomb() instead or (better) cascade the failure up to the
application level. |
| 01:23.27 |
CIA-32 |
BRL-CAD:
03brlcad * r35024 10/brlcad/trunk/src/librt/prep.c: wow, not only
shouldn't librt be calling bu_exit, but prep should definitely not
be calling it. failing to prep can be quite normal under some
circumstances and the application needs to be able to
know. |
| 01:27.48 |
CIA-32 |
BRL-CAD:
03brlcad * r35025 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c:
remove the outdated test driver application. better to stash test
app in a separate file or proc-db or util or regress. |
| 01:28.27 |
``Erik |
all ur
bu_exit are belong to brlcad |
| 01:40.37 |
CIA-32 |
BRL-CAD:
03brlcad * r35026 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c:
mass consistency/ws/style/indent/comment cleanup |
| 01:53.55 |
``Erik |
prep.c:1322:
error: too many arguments to function 'bu_bomb' |
| 01:54.07 |
``Erik |
assumes brlcad forgot to commit
include/bu.h |
| 01:54.52 |
``Erik |
prep.c:1771:
error: incompatible types in assignment |
| 01:55.14 |
``Erik |
point_t x; x
= INFINITY; <-- ummm, no :) |
| 02:06.47 |
CIA-32 |
BRL-CAD:
03brlcad * r35027 10/brlcad/trunk/src/librt/prep.c: oops, unbreak
the build and do major consistency cleanup on prep while we're at
it. |
| 02:07.08 |
brlcad |
yeah, I
noticed right away .. just took a while with the rest of the
cleanup |
| 03:50.14 |
yukonbob |
hello,
cadheads |
| 03:50.35 |
``Erik |
ssshhhh |
| 03:55.56 |
CIA-32 |
BRL-CAD:
03brlcad * r35028 10/brlcad/trunk/src/proc-db/metaball.c:
restructure in preparation for re-reading from the .g we just
created so the metaballs can be combined together. |
| 03:57.18 |
``Erik |
O.o |
| 03:57.28 |
CIA-32 |
BRL-CAD:
03brlcad * r35029 10/brlcad/trunk/TODO: make db_open modes be
identical to fopen modes |
| 04:03.11 |
yukonbob |
minds ``Erik's scolding... |
| 04:03.41 |
yukonbob |
>.> |
| 04:03.46 |
yukonbob |
<.< |
| 04:04.56 |
``Erik |
what
scolding? heh |
| 04:15.59 |
yukonbob |
how's it
going :) |
| 04:22.17 |
yukonbob |
thrashes his disk doing full table scan on
/quereyy |
| 04:24.09 |
CIA-32 |
BRL-CAD:
03brlcad * r35030 10/brlcad/trunk/src/librt/db_lookup.c: save the
callers of db_lookup from *having* to call db_dirbuild. since
db_lookup is useless without building a directory, build it
automatically if there are no records. |
| 04:26.04 |
CIA-32 |
BRL-CAD:
03brlcad * r35031 10/brlcad/trunk/src/librt/db_lookup.c: shoot,
breaks the contract. db_lookup is const, db_dirbuild is not, so
we're back to manual |
| 04:35.25 |
yukonbob |
has no love for opennurbs atm. |
| 04:35.25 |
yukonbob |
fails to
build :P |
| 04:38.33 |
*** join/#brlcad pacman87
(n=pacman87@bz.bzflag.bz) |
| 04:38.39 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
| 05:50.59 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 05:55.25 |
CIA-32 |
BRL-CAD:
03brlcad * r35032 10/brlcad/trunk/src/proc-db/metaball.c: add the
logic to load up the metaballs we added, and combine them manually
into one megametaball via librt/libwdb routines. |
| 05:56.16 |
brlcad |
aaand that
does it |
| 06:50.44 |
Ralith |
yay! |
| 07:28.23 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 09:05.43 |
*** join/#brlcad madant
(i=cb7baf0f@gateway/web/freenode/x-f3cb7d0826618484) |
| 09:40.53 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1546
10/wiki/User:127_buy_nymphomax: |
| 09:42.22 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1547
10/wiki/User:323_buy_depo_medrol: |
| 09:42.57 |
_clock_ |
*LOL* |
| 09:43.10 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1548
10/wiki/User:765_buy_zyprexa: |
| 09:43.33 |
madant |
hates wiki spammers |
| 09:43.56 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1549
10/wiki/User:900_buy_levitra: |
| 09:46.02 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1550
10/wiki/User:552_buy_viagra: |
| 09:46.29 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1551
10/wiki/User:976_buy_cleocin: |
| 09:49.20 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1552
10/wiki/User:901_buy_5_htp: |
| 09:51.03 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1553
10/wiki/User:180_buy_flonase: |
| 09:51.47 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1554
10/wiki/User:391_buy_cialis: |
| 09:52.54 |
louipc |
woohoo |
| 09:53.26 |
CIA-32 |
BRL-CAD:
03Drlex 07http://brlcad.org * r1556
10/wiki/User_talk:526_buy_viagra: |
| 10:14.39 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 10:15.14 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 10:15.14 |
*** join/#brlcad CIA-32 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 10:15.14 |
*** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 10:15.14 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 10:15.43 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 10:15.43 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 10:15.43 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 10:29.45 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 10:29.45 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 10:29.45 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 10:50.18 |
d-lo |
Mernin
all! |
| 10:50.33 |
d-lo |
*readreadread* |
| 11:02.30 |
d-lo |
'Megametaball' That's got a nice ring to
it. |
| 11:17.10 |
*** join/#brlcad madant
(i=cb7baf0f@gateway/web/freenode/session) |
| 11:27.33 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 11:33.56 |
CIA-32 |
BRL-CAD:
03davidloman * r35033 10/rt^3/trunk/src/ (13 files in 13 dirs):
Adding more CMakeLists.txt files. Continuing cmake build system
integration. |
| 13:18.38 |
``Erik |
wow, g-stl on
sphflake is a monster |
| 13:24.44 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 13:57.46 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 15:12.14 |
CIA-32 |
BRL-CAD:
03brlcad * r35034 10/brlcad/trunk/src/proc-db/metaball.c: add a
slew of additional comments for the intended audience, make three
metaballs of differing sizes so the field strength differences can
be emphasized. clean up output formatting. |
| 16:02.01 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 16:37.36 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:39.08 |
CIA-32 |
BRL-CAD:
03bob1961 * r35035
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added a wrapper
for attr. Also added a checkpoint_olist method for creating
multiple ledger entries for an action. |
| 16:54.10 |
CIA-32 |
BRL-CAD:
03brlcad * r35036 10/brlcad/trunk/BUGS: metaballs aren't fully
rendering correctly. see the proc-db example to see the chewing
pattern on grazing edges. |
| 16:55.25 |
CIA-32 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Drlex]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
| 16:56.20 |
CIA-32 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[User talk:526 buy viagra]]":
content was: '' (and the only contributor was
'[[Special:Contributions/Drlex|Drlex]]') |
| 16:58.02 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-218.sbndin.btas.verizon.net) |
| 17:50.48 |
*** join/#brlcad docelic
(n=docelic@78.134.195.197) |
| 17:52.19 |
brlcad |
Ralith: any
progress today? |
| 17:52.29 |
brlcad |
still waiting
to see that commit ;) |
| 17:52.44 |
brlcad |
jdoliner:
how's it going on your end? |
| 17:53.16 |
jdoliner |
it's going,
although things are getting more complicated than I was
hoping |
| 17:53.22 |
jdoliner |
did you read
my wiki post? |
| 17:55.57 |
brlcad |
yep |
| 17:57.12 |
jdoliner |
it's kind of
a brute force solution |
| 17:57.46 |
jdoliner |
but it'll get
the job done |
| 17:59.02 |
``Erik |
does tk have
a zomfg fast canvas? |
| 17:59.11 |
brlcad |
from the big
picture perspective, what I'm most worried about is end result
being a set of routines that work on a subset of polygonal mesh
intersections .. as that is pretty much our nmg library (and
there's no way you'll finish all possible situations in a
summer) |
| 17:59.48 |
brlcad |
``Erik: not
really, but it's decent enough for most purposes -- depends on how
many canvas objects you have and what rendering goes into
it |
| 18:00.30 |
jdoliner |
what subset
do you think they won't work on? |
| 18:01.23 |
``Erik |
rgb
blits |
| 18:01.25 |
brlcad |
much of that
assumes clean numerics |
| 18:01.30 |
``Erik |
think tk
isst |
| 18:02.06 |
brlcad |
real world
meshes are absolutely riddled with "errors" that you have to
account for where there are floating point tolerance problems on
micro and macro scale |
| 18:02.38 |
brlcad |
our nmg
library does a phenomenal job and it only handles 99% or
so |
| 18:02.53 |
brlcad |
more to the
point of the project, though, is that polygonal meshes aren't the
focus :) |
| 18:02.59 |
brlcad |
spline
surface intersections are |
| 18:03.27 |
jdoliner |
so should I
be working on spline surface intersections instead? |
| 18:04.01 |
brlcad |
well I
presumed from what you've been saying that you've been approaching
the mesh side to get a better handle on just how the data
structures and logic works out |
| 18:04.05 |
brlcad |
yes? |
| 18:04.21 |
brlcad |
since
polygonal meshes are certainly "easier" in many regards |
| 18:04.32 |
jdoliner |
well yes
that's been part of it |
| 18:04.50 |
brlcad |
so that part
is good/great/useful |
| 18:05.00 |
jdoliner |
I was also
under the impression for a while though that we needed mesh mesh
intersection |
| 18:05.13 |
jdoliner |
(brlcad src
is a big place) |
| 18:05.15 |
brlcad |
just
shouldn't be the whole project given we already have a library that
does mesh/mesh intersections .. unless we're going to shift your
project to making it even more robust ;) |
| 18:05.58 |
brlcad |
that was the
nmg code I pointed you at in src/librt/primitives/nmg/nmg_*.c
(nmg_bool.c and nmg_eval.c come to mind) |
| 18:06.28 |
brlcad |
the main
difference there is that they use different data structures, a
radial edge data structure |
| 18:06.38 |
jdoliner |
yes |
| 18:06.53 |
jdoliner |
our code
diverges actually very quickly |
| 18:07.06 |
jdoliner |
can you tell
me more about why nmg fails? |
| 18:07.09 |
brlcad |
high-level,
though, they represent arbitrary polygons and will evaluate
intersections of those |
| 18:07.18 |
jdoliner |
well when
really |
| 18:07.59 |
brlcad |
nmg fails on
a small subset of geometry mostly due to numerics and tolerance
tracking problems |
| 18:08.29 |
brlcad |
consider
three points on a line, perhaps vertices to three polygons
o---o---o |
| 18:08.42 |
jdoliner |
k |
| 18:09.05 |
brlcad |
it's
numerically actually completely ambiguous other than there being
only one solution that results in topologically solid
geometry |
| 18:09.34 |
brlcad |
so in the
code, it attempts to determine if those vertices are the same or
not, for example |
| 18:09.55 |
brlcad |
so it knows
whether to collapse them (so we have solid geometry, critically
important) or not |
| 18:10.27 |
brlcad |
say all three
points are within some 'collapse' tolerance of each other, but not
the two farthest |
| 18:11.00 |
brlcad |
if it
collapses middle to left, it ends up with a dangling face; if it
collpases middle to right, it ends up with a dangling
face |
| 18:12.03 |
jdoliner |
i
see |
| 18:12.06 |
brlcad |
it could
collapse left to middle, but then if it collapses middle to right
then that original point has drifted drastically from the original
value (which can cascade problems) |
| 18:12.29 |
brlcad |
lifewise
right to middle, middle to left, same problem |
| 18:12.50 |
brlcad |
that "point
drift" problem happens all over the place in tiny tiny increments
(at a minimum it occurs at the floating point tolerance
level) |
| 18:13.52 |
jdoliner |
okay that
would be a problem |
| 18:14.11 |
jdoliner |
but I have
trouble imagining how their could be a real solution |
| 18:14.29 |
jdoliner |
like how
could a system ever avoid this? |
| 18:14.45 |
brlcad |
there are
lots of possible solutions, it just entails a fair bit of book
keeping |
| 18:15.43 |
brlcad |
you either
have to track your decisions and be able to back up (akin to a
decision tree graph, have to be able to find other solutions) or
you keep track of and accumulate error, not allowing error to grow
beyond a certain amount |
| 18:17.36 |
jdoliner |
okay, so
basically when we collapse we remember and then if we detect a
dangling face or a similar error, we go back and say whoops that
wasn't such a good idea afterall and undo it? |
| 18:27.40 |
``Erik |
hrmph |
| 18:29.36 |
jdoliner |
Probably the
most important questions is which does brlcad need more, a more
robust mesh intersection system, or spline intersection, my inkling
is that spline intersection is more needed. |
| 18:31.47 |
``Erik |
I'd be apt to
agree at this point |
| 18:32.41 |
``Erik |
so hop to,
boy, onward to spline evaluations :D |
| 18:33.36 |
jdoliner |
alright then,
spline evaluations it is |
| 18:33.54 |
indianlarry |
the loop/trim
logic should carry over to the spline work |
| 18:34.04 |
jdoliner |
yeah it
certainly will |
| 18:34.27 |
jdoliner |
my work over
the past 2 weeks has been with polylines |
| 18:34.30 |
indianlarry |
wait till you
see the tolerance errors in the u.v space trim
approximations |
| 18:34.41 |
indianlarry |
;^) |
| 18:34.58 |
jdoliner |
k what code
should I start reading? |
| 18:35.21 |
jdoliner |
ON_Nurbs
objects seems like an obvious place to start |
| 18:35.55 |
indianlarry |
ON_Brep->ON_Surface->ON_Face |
| 18:36.52 |
indianlarry |
you'll find
the trimming loops on the face's |
| 18:37.19 |
jdoliner |
alrighty |
| 18:43.18 |
brlcad |
both are
needed, people would be just as happy if you made the nmg code
tessellations more robust |
| 18:43.28 |
brlcad |
heck, some
would be absolutely ecstatic :) |
| 18:43.48 |
brlcad |
but that
wouldn't be best done by "starting over" .. you'd need to dig into
the nmg code and make it more robust |
| 18:44.28 |
brlcad |
otherwise,
original goal definitely is a hot need too, being able to evaluate
two NURBS objects and give a resulting object sans
booleans |
| 18:45.23 |
brlcad |
e.g. simple
test case is two overlapping boxes unioned together, provide a
resulting nurbs box (with or without trims) that is just one object
with no boolean |
| 18:45.43 |
brlcad |
then try to
get two spheres, similar situation, then sphere on box,
etc |
| 18:46.33 |
CIA-32 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:509 buy biaxin]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
| 18:46.49 |
jdoliner |
k I'll
reshift my focus to that |
| 18:47.07 |
CIA-32 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:900 buy glucotrol xl]]
with an expiry time of infinite (account creation disabled):
Spamming links to external sites |
| 18:47.07 |
jdoliner |
but I'll also
take a look at the nmg tesselation at some point |
| 18:47.30 |
CIA-32 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:494 buy lopressor]] with
an expiry time of infinite (account creation disabled): Spamming
links to external sites |
| 18:47.44 |
jdoliner |
ban
hammer!!! |
| 18:48.30 |
brlcad |
jdoliner: I'd
pick one or the other and run with it :) |
| 18:48.39 |
brlcad |
too much work
to dabble in both :) |
| 18:49.03 |
brlcad |
given all
your investment in mesh logic to date, you're probably just as well
poised for either |
| 18:49.07 |
brlcad |
both have a
major impact |
| 18:49.36 |
jdoliner |
k sounds
sage |
| 18:49.54 |
``Erik |
if topic
contains '%buy%' do exec ipfw ... |
| 18:50.15 |
jdoliner |
then we'll
just get spam to rent things ;P |
| 18:51.08 |
brlcad |
buy
brl-cad! |
| 18:51.20 |
``Erik |
if topic
contains '%your mom%' ... |
| 18:51.22 |
``Erik |
O:-) |
| 19:06.51 |
CIA-32 |
BRL-CAD:
03starseeker * r35037 10/brlcad/trunk/include/opennurbs_cleanup.h:
Add distribute to the cleanup opennurbs code too. |
| 19:25.55 |
brlcad |
jdoliner: so
you have an inclination as to which? |
| 19:27.16 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 19:31.37 |
``Erik |
ja, /20.0
-> /200.0 gives better display results :/ |
| 19:35.43 |
brlcad |
cool, that's
good actually |
| 19:35.51 |
jdoliner |
my
inclination right now is toward spline intersection |
| 19:36.11 |
brlcad |
just a matter
of making that tweak dynamic .. as opposed to an outright but that
takes a while to hunt/fix ;) |
| 19:36.30 |
brlcad |
jdoliner:
okay, then I'd say run down that way and don't look back
:) |
| 19:36.53 |
``Erik |
*hackhackhack* |
| 19:36.59 |
brlcad |
I would
suggest starting with a high-level goal like i mentioned instead of
low-level, just to have a simple test-driven goal |
| 19:37.07 |
``Erik |
have a
dynamic thing coded up, compiling now ot test |
| 19:37.32 |
brlcad |
like box/box
intersection, find the result .. write a test harness and work
towards getting that test harness working with all the
behind-the-scene detail |
| 19:37.32 |
``Erik |
all keepin'
me from .g loading in isst, bastage |
| 19:37.53 |
brlcad |
:) |
| 19:38.11 |
brlcad |
well I know
the sec dave or that dude try the sample code, they're going to see
the bug :) |
| 19:38.28 |
jdoliner |
k sounds good
boxes in brepcube are a good starting point |
| 19:38.32 |
brlcad |
already
anticipate having to explain why mk_metaball() is going to crash
for them :) |
| 19:38.36 |
jdoliner |
for wriiting
the test |
| 19:39.11 |
brlcad |
yeah, or even
starting with a .g that has two cubes already placed with an
operation |
| 19:39.19 |
brlcad |
then dealing
with them at the code level |
| 19:39.34 |
brlcad |
just so you
don't get caught up in all the nasty that is involved in manually
stitching together brep objects |
| 19:40.45 |
jdoliner |
k, what can I
read about the .g format, I'm a bit unfamiliar with how to put
operators in it |
| 20:09.47 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 20:16.13 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35038 10/brlcad/trunk/ (include/rtgeom.h
src/librt/primitives/metaball/metaball.c): fix "scalloping" bug by
making step size depend on the smallest control point as well as
the bounding sphere radius. Cache initial and final step sizes in
the internal representation. |
| 20:28.42 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-27-160.phnx.qwest.net) |
| 20:36.51 |
CIA-32 |
BRL-CAD:
03starseeker * r35039 10/brlcad/trunk/ (6 files in 3 dirs):
Plugging along with opennurbs_ext cleanup - compiles now but
trimming isn't working. |
| 21:45.46 |
brlcad |
hello
Patmcc19 |
| 21:58.22 |
CIA-32 |
BRL-CAD:
03r_weiss * r35040 10/brlcad/trunk/src/libged/make_pnts.c: added
deallocation of internal structure when exit on error for make_pnts
command |
| 22:18.19 |
CIA-32 |
BRL-CAD:
03brlcad * r35041 10/brlcad/trunk/TODO: add support to rt to have a
viewsize/scale/zoom option so you don't have to provide a -M view
script just to get a bigger zoom size |
| 22:19.33 |
brlcad |
hehe, ``Erik
.. you made it a lot worse :) |
| 22:21.38 |
``Erik |
ermmmm, it
looked fine on the 2 things you provided? |
| 22:22.14 |
brlcad |
try running
the metaballs tool and render meatballs.s |
| 22:22.37 |
``Erik |
might have to
tweak the formula or numbers for finding the 2 step
sizes |
| 22:22.51 |
``Erik |
ups and installs on his lappie |
| 22:23.07 |
brlcad |
yeah, there
are like no anamolies on the middle, but now misses a solid 30% of
the model |
| 22:23.25 |
``Erik |
hm |
| 22:23.25 |
brlcad |
oh, ya know
what.. I think I had a mod in there too |
| 22:23.30 |
brlcad |
hold on,
lemme make sure it's not me |
| 22:23.39 |
``Erik |
if anything,
it'd be missing stuff in the middle, not towards th
eedges |
| 22:24.38 |
brlcad |
hm, yeah, not
just my mod |
| 22:24.52 |
brlcad |
pretty
interesting pattern |
| 22:26.25 |
``Erik |
it rendered
the 'make' primitive as well as the two in the .g file you provided
just fine when I committed :/ |
| 22:26.37 |
``Erik |
*shrug*
compiling away, touched rtgeom.h heh |
| 22:26.44 |
brlcad |
http://brlcad.org/tmp/mbug/mbug2.png |
| 22:26.49 |
``Erik |
looks like
something common to mged got touched, too |
| 22:27.31 |
``Erik |
404 |
| 22:28.03 |
brlcad |
refresh |
| 22:28.25 |
``Erik |
neat |
| 22:46.23 |
*** join/#brlcad Witch_Doc
(n=me@69.196.64.50) |
| 22:46.28 |
Witch_Doc |
anyone here
use navisworks? |
| 22:54.26 |
``Erik |
ok, I see the
issue, I have to contemplate the interplay of the different values
to get the formula right |
| 22:54.40 |
``Erik |
forages |
| 23:14.21 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 23:17.05 |
stevegt_ |
hey all --
does anyone know of any python bindings for librt, SWIG or
otherwise? |
| 23:18.37 |
stevegt_ |
~seen
brlcad |
| 23:18.42 |
ibot |
brlcad is
currently on #bzflag (13h 2m 54s) #brlcad (13h 2m 54s). Has said a
total of 64 messages. Is idling for 50m 39s, last said:
'refresh'. |
| 23:20.08 |
``Erik |
there was
discussion about making a swig interface, but it never went
anywhere, and I haven't heard of any python bindings :/ |
| 23:24.32 |
stevegt_ |
thanks ``Erik
-- just wanted to check before I spend any time on it |
| 23:25.37 |
stevegt_ |
another
alternative would include patching nirt -- afaict, onehit is
hardcoded... |
| 23:25.54 |
stevegt_ |
or else i'm
crazy |
| 23:26.03 |
``Erik |
swig
interface to bu, bn, rt, ged, etc would probably be greatly
appreciated and get snarfed into the repo pretty
quickly |
| 23:26.12 |
stevegt_ |
i bet it
would ;-) |
| 23:26.25 |
``Erik |
nirt is a
fairly specialized rt shell |
| 23:27.38 |
stevegt_ |
i'm wanting
to be able to do batch python scripting of raytrace-based toolpath
generation jobs, nirt looks like it might almost work, except for
onehit... |
| 23:28.12 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35042
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: more
futzing with step sizes. This seems to render all the current test
cases reasonably. |
| 23:28.31 |
``Erik |
would like to do lisp coding around librt
:) |
| 23:28.40 |
``Erik |
mebbe ruby,
too |
| 23:29.14 |
stevegt_ |
welll... i
suppose if someone were to make a working .i for librt, then you
could use SWIG for lisp, python, perl, whatever... |
| 23:29.33 |
``Erik |
if you have
experience with swig, include/bu.h include/bn.h include/ged.h
include/raytrace.h to see how easy it would be to integrate?
*shrug* |
| 23:31.09 |
stevegt_ |
i did try the
simple thing, including raytrace.h in the SWIG .i file -- blows
chunks though; my first guess is that it's going to actually need
some wrapper functions |
| 23:32.22 |
``Erik |
hm, bu.h
might be the best first target, raytrace depends on libbn and
libbu, libbn depends on libbu, ... |
| 23:32.37 |
``Erik |
bu just
requires a sane system and tcl |
| 23:32.49 |
stevegt_ |
SWIG docs say
it doesn't run cpp, so I think that means all of brl-cad's macro
function names are going to be in the way... |
| 23:33.31 |
``Erik |
hrm, perhaps
convince make to run the headers through the preprocessor and sick
swig on the output of that? |
| 23:34.48 |
stevegt_ |
i ran cpp on
raytrace.h myself, of course that pulls in the whole world,
starting with stdio.h... at some point someone's either going to
have to massage cpp output, or just write a SWIGable library on top
of librt |
| 23:35.06 |
stevegt_ |
hmm. maybe
nirt might be a place to start with the latter |
| 23:35.43 |
stevegt_ |
start with
the nirt code, kill main()... |
| 23:35.45 |
``Erik |
I'm sure once
some code hits the disk, bikeshed discussions will start about how
it SHOULD have been done :) |
| 23:36.01 |
stevegt_ |
yep |
| 23:36.16 |
``Erik |
so *shrug*
release early, release often :) |
| 23:36.43 |
stevegt_ |
do you have
SVN commit access? |
| 23:36.46 |
``Erik |
yes |
| 23:37.31 |
stevegt_ |
about how big
is the local sandbox? (I'm still running checkout) |
| 23:37.47 |
``Erik |
if you have
something you'd like to contribute, upload it to the sourceforge
patches tracker and hollar, someone will respond pretty darn quick
:) |
| 23:37.54 |
``Erik |
um, "local
sandbox"? |
| 23:38.14 |
``Erik |
on my mac,
after everything is compiled, it all adds up to 730
megs |
| 23:38.40 |
stevegt_ |
okay -- then
i'm getting close |
| 23:39.11 |
``Erik |
I think it's
more like 80-100 megs before compiling? *shrug* |
| 23:40.13 |
stevegt_ |
uh oh -- i'm
at 430 and counting so far -- you must be talking about trunk only
or something |
| 23:40.20 |
``Erik |
yes, trunk
only |
| 23:40.33 |
``Erik |
um, if you
are getting every branch, that's many gigs :( |
| 23:41.04 |
``Erik |
svn co
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 23:41.22 |
stevegt_ |
kills his 'svn co' and starts over ;-) |
| 23:44.22 |
``Erik |
ok, here we
go, if you add up the tags and branches, there are 95. You were
checking out 95 copies of BRL-CAD :D |
| 23:44.44 |
stevegt_ |
nope |
| 23:45.04 |
stevegt_ |
i was
checking out 95 copies of brlcad, as well as jbrlcad, rt^3, etc...
;-) |
| 23:45.19 |
``Erik |
ah, those
arne't tagging or branching |
| 23:45.28 |
``Erik |
so 95
BRL-CAD's, plus the other five or 6 |
| 23:45.32 |
stevegt_ |
gee |
| 23:46.11 |
brlcad |
stevegt_:
hehe |
| 23:46.19 |
brlcad |
~cadsvn |
| 23:46.20 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 23:46.29 |
brlcad |
that there be
the main line |
| 23:47.14 |
brlcad |
hmm.. python
bindings. not directly, but you can certainly script mged from
python just fine and do nearly everything |
| 23:47.53 |
``Erik |
doublecheck
my metaball fix, brlcad, I think I have it 'ok' now. performance is
kinda wonky, but it seems to do ok on all the geometry I threw at
it |
| 23:48.03 |
brlcad |
it would be
very trivial to bind libged to python, just nobody has done so (or
needed to thusfar) |
| 23:48.14 |
brlcad |
yeah, saw the
commit, was just about to try |
| 23:48.39 |
brlcad |
will find some way to press the limits even further
:) |
| 23:48.50 |
``Erik |
asymptotic
performance of it is now noncontinuous :( |
| 23:48.52 |
brlcad |
that script
does make it trivial to make arbitrarily complex blobs |
| 23:49.24 |
``Erik |
mebbe some
day I'll build an acceleration structure into the guts of it
*sigh* |
| 23:49.35 |
brlcad |
riight
:) |
| 23:50.12 |
``Erik |
yeah, about 6
months after I retire and find an ancient todo file. |
| 23:50.32 |
brlcad |
stevegt_: I
wouldn't start with raytrace.h .. ged.h is a lot simpler interface,
a little higher level |
| 23:50.39 |
stevegt_ |
brlcad:
looking |
| 23:51.06 |
brlcad |
what did you
mean about nirt's onehit? |
| 23:51.16 |
brlcad |
nirt is
pretty configurable (and scriptable) too |
| 23:51.34 |
brlcad |
it has a
command-mode similar to mged |
| 23:53.05 |
brlcad |
stevegt_:
fyi, also very keen on handing out commit access to folks that are
actively interested in getting involved that are easy to work with,
regardless of their project/goals/interests |
| 23:55.55 |
brlcad |
HACKING has
some basic guidelines on top of that, but it mostly amounts to "do
no harm" and aims to keep the project cohesive (we're complex
enough as it is to be arguing over petty issues) |
| 23:58.55 |
stevegt_ |
brlcad:
<grin> re complex ;-) |
| 23:59.00 |
brlcad |
``Erik: fyi,
they're about to tag a final 3.4 itcl just so you know -- guys have
been bugging them so they can update the ports entry, there is a b1
posted now |
| 23:59.29 |
``Erik |
hm, I finally
got vidar back up and running, I still have to update cad/brlcad
:/ |
| 23:59.32 |
``Erik |
and a few
others heh |
| 23:59.39 |
``Erik |
bugle,
gauche, ... |
| 23:59.51 |
brlcad |
vidar? |
| 23:59.54 |
``Erik |
poor machine
went a year without updates |
| 00:00.00 |
``Erik |
yeah, my
-current box at home |
| 00:00.15 |
brlcad |
that sounds
pretty gaydar :) |
| 00:00.23 |
``Erik |
O.o |
| 00:00.32 |
brlcad |
now .. vigor
:) |
| 00:00.44 |
``Erik |
heh, pheer my
norse mythology machines. |
| 00:00.58 |
``Erik |
vidar == god
of vengence |
| 00:01.22 |
stevegt_ |
was confused: the line of code in nirt.c which i thought
turns on onehit is turning it off instead -- i must be doing
something else wrong though |
| 00:02.09 |
``Erik |
or onehit
doesn't quite do what you think it does :) |
| 00:03.12 |
brlcad |
assume you've
seen:
http://brlcad.org/w/images/f/fe/Interactive_Raytracing_-_The_nirt_Command.pdf |
| 00:03.44 |
stevegt_ |
wonders if he has to actually configure some 'fmt' commands
to get nirt to show anything past the first hit |
| 00:03.47 |
brlcad |
starseeker
wrote a pretty extensive guide to using and configuring
nirt |
| 00:05.11 |
stevegt_ |
brlcad: no, i
hadn't seen that PDF yet -- very cool |
| 00:05.26 |
brlcad |
linked from
http://brlcad.org/wiki/Documentation |
| 00:05.39 |
brlcad |
yeah.. not
well organized on the doc front still :) |
| 00:05.55 |
brlcad |
there's still
a lot more not even uploaded, but it'd just get even more
messy |
| 00:07.56 |
brlcad |
stevegt_: I
intentionally didn't add distribute() to the header since it was
basically being used as an implementation detail and not part of
the interface |
| 00:08.15 |
brlcad |
doesn't
matter much at this point, but worth noting |
| 00:17.51 |
stevegt_ |
brlcad: the
docs that aren't uploaded -- are they in svn? |
| 00:20.41 |
brlcad |
some are,
many aren't.. docs accumulated over the years |
| 00:21.09 |
brlcad |
figure a 1M
codebase, 25 or so years .. lot of docs, presentations, papers, etc
have been written |
| 00:22.04 |
stevegt_ |
yep -- and
i'm assuming some only exist on paper at this point |
| 00:22.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-218.sbndin.btas.verizon.net) |
| 00:23.29 |
stevegt_ |
i'm noticed
that google can't find some of the papers referred to in the bottom
of man pages |
| 00:23.35 |
stevegt_ |
s/i'm/i've/ |
| 00:24.46 |
stevegt_ |
now *there's*
a possible GSoC project -- organize, scan stuff in... |
| 00:25.44 |
brlcad |
heh, I wish..
gsoc has to be coding |
| 00:25.52 |
brlcad |
ghop
perhaps |
| 00:26.19 |
brlcad |
I try to get
new folks introduced by having them work on docs, but they tend to
get quickly absorbed into coding *ahem* |
| 00:27.28 |
brlcad |
still think
our greatest accelleration of activity could be gained by putting
(a LOT of) effort into well organized docs and sources, even
without new features or improved gui |
| 00:27.38 |
stevegt_ |
yes |
| 00:28.13 |
stevegt_ |
i've been
spending > 50% of my time reading code 'cause i can't find what
i'm looking for in docs |
| 00:28.26 |
stevegt_ |
that's gotta
be a hurdle ;-) |
| 00:28.40 |
brlcad |
tis a major
project, though .. and major organization feat, and not very
exciting work for most :) |
| 00:28.50 |
brlcad |
yeah |
| 00:29.03 |
brlcad |
getting the
new website up certainly helped a lot, but even that was just a
start |
| 00:37.47 |
yukonbob |
hello,
cadheadsw |
| 00:37.50 |
yukonbob |
*cadheads |
| 00:39.39 |
stevegt_ |
goes to get the kids -- bbl |
| 00:40.40 |
brlcad |
howdy
yukonbob! .. half hoped you might clean up all that wiki spam we
got :) |
| 00:40.44 |
brlcad |
cya
stevegt_ |
| 00:56.01 |
yukonbob |
brlcad: /me
hadn't seen spam |
| 00:56.25 |
yukonbob |
brlcad: how's
it going? Long time, no chat |
| 00:58.00 |
brlcad |
going pretty
good |
| 00:59.48 |
yukonbob |
doesn't see spam... |
| 01:01.01 |
dtidrow |
brlcad: i see
that Lee is doing some OpenSceneGraph work - is he back from his
'sabbatical'? |
| 01:09.08 |
brlcad |
dtidrow: yep,
he's back |
| 01:09.20 |
brlcad |
been back for
nearly a year now? |
| 01:09.41 |
dtidrow |
heh - that's
how far out of the loop I've been ;-) |
| 01:09.49 |
brlcad |
yeah, maybe
more than a year actually .. |
| 01:10.03 |
brlcad |
yukonbob: I
took care of it all already |
| 01:10.08 |
dtidrow |
so what's he
doing with OSG/ |
| 01:10.11 |
dtidrow |
? |
| 01:10.48 |
dtidrow |
(note to self
- get new keyboard to fix sticky shift key...) |
| 01:20.09 |
yukonbob |
is there
anybody else who isn't loving compiling opennurbs (i.e. isn't
successfull)? |
| 01:24.14 |
``Erik |
hasnt had issues with opennurbs, just libpc
:/ |
| 01:45.41 |
brlcad |
dtidrow:
interactive visualization, related to his research project back in
utah |
| 01:46.09 |
brlcad |
yukonbob:
yeah, no problems here nor have I heard of any |
| 01:51.07 |
yukonbob |
will pursue... |
| 02:07.15 |
brlcad |
``Erik: woo
hoo .. feels like it's an order of magnitude slower now, but no
problems observed thusfar |
| 02:12.13 |
starseeker |
indianlarry:
does the nurbs_sphere.s test case work for you with latest
svn? |
| 02:14.50 |
``Erik |
it is much
slower, the speed now is mostly dependent on the smallest field
strength |
| 02:15.20 |
``Erik |
irregardless
of the bounding sphere diameter |
| 02:15.37 |
``Erik |
so a small
control point in a big bounding sphere does a LOT more point
checks |
| 02:20.16 |
CIA-32 |
BRL-CAD:
03ralith * r35043 10/rt^3/trunk/src/g3d/ (CMakeLists.txt
OgreScene.cxx OgreScene.h): Split Ogre/Qt work off into a separate
target (make ogretest). |
| 02:20.20 |
Ralith |
can someone
build g3d to see if it's survived my hackery? My updated ogre
install here breaks RBGui so I can't easily test
myself. |
| 02:24.07 |
Ralith |
it *should*
be okay; the only error I'm getting is the one concerning
RBGui/Ogre unhappiness, but it would be nice to be
sure. |
| 02:39.12 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35044 10/rt^3/trunk/include/GE/io/DataStream.h:
include sys/types.h for definition of uint |
| 02:39.40 |
*** join/#brlcad stevegt_
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 03:41.02 |
Ralith |
ooh, I think
I've found a way to step Qt without reimplementing
QApplication! |
| 03:42.17 |
Ralith |
this should
make the ogre-centric approach much easier. |
| 03:48.08 |
Ralith |
wait,
what |
| 03:51.43 |
Ralith |
that's
funny... |
| 03:56.45 |
Ralith |
oh wow, I
think ogre's been flipping buffers this whole time after
all |
| 04:00.34 |
Ralith |
DAMN. |
| 04:00.36 |
Ralith |
that didn't
solve it. |
| 04:07.04 |
CIA-32 |
BRL-CAD:
03ralith * r35045 10/rt^3/trunk/src/g3d/ogretest.cxx: Added a file
forgotten from my previous commit. |
| 04:08.07 |
Ralith |
on the up
side... |
| 04:08.11 |
Ralith |
custom event
loop works |
| 04:08.16 |
Ralith |
mainloop* |
| 04:08.24 |
CIA-32 |
BRL-CAD:
03ralith * r35046 10/rt^3/trunk/src/g3d/OgreScene.cxx: |
| 04:08.31 |
CIA-32 |
BRL-CAD:
Removed a call that was causing Ogre to go through a full render
sequence (undesirable, as it involves buffer flipping and
possibly |
| 04:08.37 |
CIA-32 |
BRL-CAD:
other actions based on the assumption that Ogre is the only user of
the context), and disabled Ogre rendering altogether to test
Qt |
| 04:08.44 |
CIA-32 |
BRL-CAD:
operation with a custom event loop (successful). |
| 04:33.53 |
CIA-32 |
BRL-CAD:
03ralith * r35047 10/rt^3/trunk/src/g3d/QtRenderListener.h:
Beginnings of the QtRenderListener, which should eventually allow
Qt to render cleanly on Ogre's terms. |
| 04:34.01 |
Ralith |
grabs food |
| 05:22.35 |
Ralith |
returns and starts hacking on the impl |
| 06:02.11 |
*** join/#brlcad IriX64
(n=WarLock@bas2-sudbury98-1096600735.dsl.bell.ca) |
| 07:32.48 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 08:47.08 |
CIA-32 |
BRL-CAD:
03ralith * r35048 10/rt^3/trunk/src/g3d/ (QtRenderListener.cxx
QtRenderListener.h): First-try implementation of QtRenderListener,
which should allow Qt to be safely rendered without conflicting
with Ogre. |
| 08:48.42 |
Ralith |
hokay,
semi-ogre centric (managed to rely on Qt more than I had initially
expected) implementation put together; now to rewrite the test code
to find out if it works. |
| 08:51.43 |
CIA-32 |
BRL-CAD:
03ralith * r35049 10/rt^3/trunk/src/g3d/QtRenderListener.cxx: Added
a safety check to prevent any attempt to use the listener with a
non-OpenGL Ogre backend. |
| 09:23.11 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 09:30.52 |
CIA-32 |
BRL-CAD:
03d_rossberg * r35050
10/brlcad/trunk/src/librt/opennurbs_ext.cpp: |
| 09:30.53 |
CIA-32 |
BRL-CAD:
fixed crash on MS Windows with brlcad.dll |
| 09:30.57 |
CIA-32 |
BRL-CAD:
trim.m_ei = -1 => this trim lies on a portion of a singular
surface side |
| 09:30.59 |
CIA-32 |
BRL-CAD: (see
src\other\openNURBS\example_brep\example_brep.cpp) |
| 09:32.18 |
CIA-32 |
BRL-CAD:
03d_rossberg * r35051
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: fixed crash on
MS Windows with brlcad.dll and nurbs_test.g |
| 09:41.21 |
CIA-32 |
BRL-CAD:
03d_rossberg * r35052 10/brlcad/trunk/src/nirt/ (Makefile.am
nirt.dsp): MSVC 6.0 isn't supported any more |
| 10:14.28 |
CIA-32 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1557 10/wiki/User:Ralith: Logs for 2009-07-08 and
2009-07-09 |
| 10:41.35 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 11:23.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 11:31.53 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 11:42.56 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 12:09.35 |
*** join/#brlcad mafm_
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 12:32.01 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 12:35.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 12:35.56 |
*** join/#brlcad docelic_
(n=docelic@78.134.192.197) |
| 12:46.17 |
CIA-32 |
BRL-CAD:
03irpguardian * r35053 10/brlcad/trunk/BUGS: Fixed a couple
spelling errors |
| 13:02.49 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 13:05.26 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35054 10/brlcad/trunk/BUGS: metaball scalloping
was fixed last night (I hope) |
| 13:07.56 |
``Erik |
*mumble* |
| 13:18.10 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 13:38.17 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35055 10/rtcmp/trunk/tri.c: fix typo in
comment |
| 13:39.02 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 13:43.29 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:50.50 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 14:10.05 |
CIA-32 |
BRL-CAD:
03d_rossberg * r35056 10/brlcad/trunk/src/nirt/nirt.c: |
| 14:10.07 |
CIA-32 |
BRL-CAD: no
extra setmode for MS Windows |
| 14:10.09 |
CIA-32 |
BRL-CAD: we
need the O_TEXT mode here: it converts the CR-LF from the input
stream to a single LF (and vice versa for the output) |
| 14:16.58 |
CIA-32 |
BRL-CAD:
03d_rossberg * r35057 10/brlcad/trunk/ (4 files in 3 dirs): include
the nirt program in the MS Windows CMake build |
| 14:18.56 |
*** join/#brlcad samrose
(n=samrose@24.11.214.181) |
| 14:34.04 |
``Erik |
explains what sleep() does to his officemate.
*sigh*. |
| 14:34.56 |
brlcad |
heh |
| 14:35.33 |
brlcad |
better to
teach him what "man 3 sleep" does |
| 14:35.41 |
CIA-32 |
BRL-CAD:
03irpguardian * r35058 10/brlcad/trunk/src/proc-db/human.c: Cleanup
of some of the vector equations, and some reworking of the method
the human is generated. |
| 14:35.47 |
``Erik |
ah, theboy,
that, um, line wasn't in the history file |
| 14:36.00 |
``Erik |
if'n ya
noticed my sudo spaz earlier |
| 14:40.14 |
``Erik |
huh, no joy
:/ |
| 14:41.33 |
``Erik |
ahhhhhhh |
| 14:41.41 |
``Erik |
was using the
wrong username heh |
| 15:28.16 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 15:29.43 |
*** part/#brlcad Witch_Doc
(n=me@69.196.64.50) |
| 16:37.16 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 17:27.32 |
brlcad |
hello
elena |
| 17:28.27 |
elena |
hi. |
| 17:28.45 |
elena |
how are
you? |
| 17:28.56 |
brlcad |
great! |
| 17:29.26 |
brlcad |
playing with
the metaballs example tool at the moment |
| 17:30.41 |
brlcad |
was hoping
the recent fix worked ... and it almost does .. but not quite, has
lots of anamolies still |
| 17:30.51 |
elena |
bugs are not
funny. |
| 17:30.52 |
brlcad |
albeit on a
massive metaball dataset.. 10k points :) |
| 17:32.50 |
elena |
i don't know
what's that. |
| 17:36.35 |
brlcad |
they're
"blobby" shapes that are defined by points and threshold/weighting
factors |
| 17:36.42 |
brlcad |
example:
http://brlcad.org/tmp/metaball.png |
| 17:37.06 |
elena |
i've notice a
lot of talk around them lately. |
| 17:37.35 |
brlcad |
yeah, I was
putting together an example of using them in code |
| 17:37.48 |
brlcad |
found a
handfull of issues that we've been working on fixing |
| 17:40.26 |
brlcad |
http://brlcad.org/tmp/metaball2.png
even better example |
| 17:41.47 |
elena |
nice. |
| 17:42.05 |
elena |
the former
was the funnier :) |
| 17:42.56 |
brlcad |
hehe |
| 17:46.23 |
``Erik |
since it's a
sampling algo instead of a solver, there'll always be 'anomalies',
it's a tradeoff between how many and how fast :( |
| 17:46.56 |
elena |
nice. |
| 17:46.56 |
``Erik |
mebbe the
initial and final step sizes should be user
specifiable |
| 17:49.15 |
CIA-32 |
BRL-CAD:
03brlcad * r35059 10/brlcad/trunk/BUGS: the lingering ogl
framebuffer after an rt is consuming 100% cpu (sometimes?) until
the window is closed. needs to sleep/select instead of
spin. |
| 17:49.53 |
CIA-32 |
BRL-CAD:
03brlcad * r35060
10/brlcad/trunk/src/proc-db/metaball.c: |
| 17:49.55 |
CIA-32 |
BRL-CAD: add
the ability to be able to specify how many points you want instead
of just |
| 17:50.01 |
CIA-32 |
BRL-CAD: the
previous hard-coded value. uses 1/111, 10/111, and 100/111 for the
three |
| 17:50.03 |
CIA-32 |
BRL-CAD:
datasets it creates (with at least 1 per set) so that the final is
close to the |
| 17:50.07 |
CIA-32 |
BRL-CAD:
requested value (plus one or two more). |
| 17:55.01 |
brlcad |
``Erik:
http://brlcad.org/tmp/mbug/mbug3.png
.. it's pretty close, just a little chewing |
| 17:55.21 |
brlcad |
and it didn't
take as long as it seemed, maybe 5-10 min |
| 17:55.56 |
brlcad |
granted, with
some partitioning, that'd probably be down to less than a min
:) |
| 17:56.18 |
``Erik |
making the
initstep size smaller will alleviate that... feel free to come up
with a better formula, it's not computed per ray anymore, so
there's no need to make it simple and fast *shrug* |
| 17:56.35 |
``Erik |
it's now in
_prep |
| 17:56.36 |
``Erik |
:D |
| 17:57.28 |
``Erik |
figuring out
which formula is being used might be important O.o |
| 17:58.00 |
``Erik |
is guessing there is an "unreasonably small" point in your
cloud forcing it into t he bounding volume algo |
| 17:59.55 |
brlcad |
hehe, just
printed/sorted all balls |
| 18:00.03 |
brlcad |
smalles is
0.000574094 |
| 18:00.53 |
brlcad |
20 or so are
an order "bigger", then everything else is an order larger (0.01+)
still |
| 18:01.12 |
brlcad |
largest is
51.1789 |
| 18:01.31 |
``Erik |
and the
bounding volume radius? a couple thousand? heh |
| 18:05.32 |
CIA-32 |
BRL-CAD:
03starseeker * r35061 10/brlcad/trunk/ (3 files in 3 dirs):
Continue tweaking opennurbs cleanup files |
| 18:11.17 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) |
| 18:19.53 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) |
| 18:22.10 |
CIA-32 |
BRL-CAD:
03irpguardian * r35062
10/brlcad/trunk/src/proc-db/human.c: |
| 18:22.14 |
CIA-32 |
BRL-CAD: Made
arms, legs use human_data_t struct for limb positioning |
| 18:22.20 |
CIA-32 |
BRL-CAD: Made
arms get limb positioning externally of arm function. |
| 18:22.22 |
CIA-32 |
BRL-CAD:
Added command line attribute to make premade stances,
'-s#' |
| 18:22.24 |
CIA-32 |
BRL-CAD: -s0
= stand -s1 = sit, -s2 = drive |
| 18:30.50 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 18:38.38 |
CIA-32 |
BRL-CAD:
03bob1961 * r35063 10/brlcad/trunk/src/tclscripts/mged/text.tcl:
Update tab_expansion proc to work with the new expand behavior
(i.e. expand returns an empty string if nothing suitable is found
in the database). |
| 19:02.33 |
CIA-32 |
BRL-CAD:
03irpguardian * r35064
10/brlcad/trunk/src/proc-db/human.c: |
| 19:02.34 |
CIA-32 |
BRL-CAD:
Added roundness to shoulder area. |
| 19:02.36 |
CIA-32 |
BRL-CAD: Also
refined some poses, so there are now 4 programed- |
| 19:02.40 |
CIA-32 |
BRL-CAD:
stand, sit, drive, arms out, fancy sit |
| 19:07.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 19:54.59 |
CIA-32 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1558 10/wiki/More_Changelog: /* July 7 - Today */ |
| 20:08.21 |
CIA-32 |
BRL-CAD:
03starseeker * r35065 10/brlcad/trunk/ (3 files in 3 dirs): More
nurbs tweaks - getting visual artifacts in the sphere when I use
sane flatness settings that are due to intersection failures on the
hierarchy - so far haven't successfully tracked down the
problem. |
| 20:09.40 |
CIA-32 |
BRL-CAD:
03bob1961 * r35066
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Added
brep_debug to the librt build. |
| 20:12.56 |
starseeker |
growls in frustration |
| 20:13.51 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 20:20.07 |
*** join/#brlcad cosurgi
(n=cosurgi@chello089079134153.chello.pl) |
| 20:24.19 |
CIA-32 |
BRL-CAD:
03bob1961 * r35067 10/brlcad/trunk/src/libged/3ptarb.c: Free
memory. |
| 20:27.16 |
CIA-32 |
BRL-CAD:
03bob1961 * r35068 10/brlcad/trunk/ (56 files in 5
dirs): |
| 20:27.18 |
CIA-32 |
BRL-CAD:
These changes fix bug 2278126 (i.e. rt doesn't get geometry path
right). The |
| 20:27.20 |
CIA-32 |
BRL-CAD: tact
was to replace the solids list with a display list where each item
in the |
| 20:27.22 |
CIA-32 |
BRL-CAD: list
refers to what was asked to be drawn. Each of these display list
items has |
| 20:27.26 |
CIA-32 |
BRL-CAD: its
own solids list. |
| 20:30.55 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 20:39.42 |
jdoliner |
what tools
does brlcad already have for polynomial manipulation, solving
evaluating etc? |
| 20:41.40 |
jdoliner |
aha
libbn/poly.c |
| 20:45.43 |
jdoliner |
is there
support for multivariate polynomial anywhere? |
| 20:46.26 |
pacman87 |
jdoliner: not
that i found, and the solver is limited to 4th order |
| 21:14.34 |
jdoliner |
well I
definitely need those to proceed |
| 21:15.01 |
pacman87 |
what are you
trying to do with multivariable polynomials? |
| 21:15.05 |
pacman87 |
systems of
equations? |
| 21:15.11 |
jdoliner |
yes |
| 21:15.35 |
jdoliner |
nurbs surface
intersection |
| 21:15.39 |
jdoliner |
to be
precise |
| 21:16.00 |
pacman87 |
two
second-order two-variable equations can be combined to get a fourth
order single-variable equation for one variable |
| 21:17.15 |
pacman87 |
if you need
higher-order polynomials, you may have to use an iterative
solver |
| 21:18.00 |
jdoliner |
In the
literature they use the dixon resultant |
| 21:18.31 |
jdoliner |
we don't have
any such solvers already implemented do we? |
| 21:18.46 |
pacman87 |
i don't know
enough to answer that |
| 21:19.51 |
jdoliner |
k |
| 21:20.25 |
jdoliner |
brlcad impart
some wisdom? |
| 21:25.45 |
``Erik |
told him to look at irc |
| 21:26.17 |
jdoliner |
thanks |
| 21:44.43 |
CIA-32 |
BRL-CAD:
03irpguardian * r35069 10/brlcad/trunk/src/proc-db/human.c: Cleaned
up some code |
| 21:51.27 |
CIA-32 |
BRL-CAD:
03bob1961 * r35070 10/brlcad/trunk/ (5 files in 4 dirs): Changes to
get things building on MSVC8. |
| 21:59.48 |
CIA-32 |
BRL-CAD:
03r_weiss * r35071 10/brlcad/trunk/src/libged/make_pnts.c: improved
error messages, logic cleanup |
| 22:02.31 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 22:40.30 |
stevegt_ |
is pondering two alternatives: (1) write his 2d laser cutter
toolpath generation tool as a C executable (2) write it as a python
wrapper around nirt and mged |
| 22:42.01 |
stevegt_ |
given my
python currency and C rustiness, I'm favoring the latter, but don't
want to make people go "ooooh, yuck" |
| 22:42.20 |
stevegt_ |
s/the
latter/the python route/ |
| 22:45.45 |
stevegt_ |
seems like
brl-cad's history has favored special-purpose C executables in
./bin, rather than special-purpose scripting around fewer, more
general-purpose C cores |
| 22:46.50 |
Ralith |
stevegt_: a
wrapper around nirt and mged would be a very strange thing to do,
considering that you'll want to interact with rt
directly. |
| 22:47.18 |
Ralith |
what you
could do instead would be write a python API for rt and whatever
else you need, and then use that in python. |
| 22:47.38 |
stevegt_ |
Ralith: so
far it's looking like nirt's custom outputs can give me everything
i need |
| 22:47.42 |
stevegt_ |
other than
speed ;-) |
| 22:48.06 |
Ralith |
stevegt_:
still a very strange thing to do, and probably relatively slow at
that. |
| 22:48.06 |
Ralith |
using the API
directly would be immensely cleaner |
| 22:48.14 |
Ralith |
and probably
less prone to breakage |
| 22:49.55 |
stevegt_ |
i agree that
the "right" thing to have would be python bindings for librt and/or
libged etc. -- but that give me a much longer lead time to get the
machine design project done that i'm actually supposed to be
working on |
| 22:50.08 |
stevegt_ |
i'm already
getting pressure to "just use solidworks" ;-) |
| 22:50.14 |
Ralith |
actually,
wrapping a C API in your language of choice is usually
trivial |
| 22:50.20 |
stevegt_ |
s/give/gives/ |
| 22:50.43 |
Ralith |
I'm not
familiar with python's relevant facilities, but it's generally a
task so straightforward as to be easily automated :P |
| 22:50.48 |
Ralith |
in
fact... |
| 22:51.04 |
stevegt_ |
Ralith:
brl-cad's use of macros for function names makes SWIG less
straightforward to run |
| 22:51.19 |
stevegt_ |
afaict
anyway |
| 22:51.26 |
Ralith |
that would be
odd; it's a perfectly reasonable thing to do |
| 22:51.47 |
Ralith |
things like
POSIX actually explicitly state that macros can be used
interchangably with functions in many contexts |
| 22:51.53 |
stevegt_ |
SWIG doesn't
run cpp |
| 22:52.01 |
Ralith |
good thing
the API you'd be wrapping is C :P |
| 22:52.26 |
stevegt_ |
so it's
"easier" to just write a new .h, rather than use e.g. raytrace.h or
ged.h |
| 22:52.37 |
Ralith |
wat |
| 22:53.11 |
Ralith |
stevegt_:
like I said, the API is all C. |
| 22:53.16 |
Ralith |
there's no
C++. |
| 22:53.19 |
stevegt_ |
when i say
"cpp" i mean "the C preprocessor" |
| 22:53.27 |
Ralith |
oh
:P |
| 22:53.31 |
Ralith |
that's a
highly ambiguous term |
| 22:54.11 |
Ralith |
so run SWIG
on the functions and rewrite the macros in python? |
| 22:54.30 |
``Erik |
heh, only to
retards who fuck up terminology and think cpp means c++, instead of
using .c++, .C, .cxx, ... |
| 22:54.32 |
``Erik |
:D |
| 22:54.33 |
``Erik |
*duck* |
| 22:55.00 |
Ralith |
:[ |
| 22:55.19 |
Ralith |
.C is a bad
idea |
| 22:55.24 |
Ralith |
given the
existence of case insensitive filesystems |
| 22:55.26 |
stevegt_ |
deletes a line about "dinosaurs like me who think of C++ as a
new language" |
| 22:56.29 |
stevegt_ |
s/new/new and
unproven/ |
| 22:57.01 |
Ralith |
stevegt_: and
of course a pure C implementation would be cool too, simply because
of the drastically smaller overhead, but if you're not comfortable
in C and don't have the time to become so then it's not worth the
effort |
| 22:59.51 |
stevegt_ |
Ralith: I
think it's one of those things where I'd better go ahead and do it
the fastest way, lest it not get done at all ;-) |
| 23:00.01 |
Ralith |
reasonable. |
| 23:00.21 |
stevegt_ |
or at least
try -- the parsing of mged output might slow things down enough
that i'd have to go to pure C anyway |
| 23:00.56 |
Ralith |
what do you
need mged for? |
| 23:01.02 |
stevegt_ |
depends on
how many rays I wind up working with for a reasonably-complex
assembly |
| 23:01.38 |
stevegt_ |
I *think* I
need mged just to list the basic shapes, so I know I'm hitting all
of them while discovering holes and other booleans |
| 23:02.45 |
Ralith |
er |
| 23:02.51 |
Ralith |
all you
should need to know is the region you're targeting |
| 23:02.58 |
Ralith |
which the
user is supposed to provide |
| 23:06.08 |
stevegt_ |
i need to be
able to make sure that any grid or other pattern is fine-grained
enough to hit hairline features -- they are easy to machine with a
laser, and do get used |
| 23:06.46 |
Ralith |
the way you
do that is by shooting enough rays that your resultant toolpath is
guaranteed to be more precise than the machine can
produce |
| 23:09.12 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 23:11.39 |
``Erik |
you can
ignore mged and write a treewalk routine to collect all the region
names. |
| 23:12.15 |
stevegt_ |
Ralith: i
guess i'm (possibly prematurely) trying to optimize, was thinking
about adaptively sizing a tight grid around edges, ignoring the
rest -- if i just to a uniform grid, then we're looking at about a
half-billion rays for a 20" square |
| 23:12.18 |
``Erik |
db_walk_tree() or one of that
family |
| 23:12.23 |
stevegt_ |
the laser
precision is 50 um |
| 23:12.52 |
Ralith |
stevegt_: did
you expect you wouldn't be using a lot of rays? :P |
| 23:12.52 |
stevegt_ |
``Erik: in
python |
| 23:12.55 |
Ralith |
don't
optimize prematurely. |
| 23:13.04 |
Ralith |
make it work,
THEN make it fast. |
| 23:13.50 |
stevegt_ |
Ralith: i'm
going to have to do some performance proof of concepts up front --
maybe i don't need the adaptive grid |
| 23:14.42 |
Ralith |
stevegt_:
unless you're trying to shoot rays via calling an external tool one
ray at a time it should be fine. |
| 23:17.19 |
Ralith |
<PROTECTED> |
| 23:18.12 |
stevegt_ |
i'm thinking
to essentially drive nirt as a filter, control both stdin and
stdout/err from the python script, so it only needs to fork once,
keep it fed with a stream of rays |
| 23:19.52 |
stevegt_ |
i'll test the
speed of all this this weekend, see if it makes sense at
all |
| 23:22.39 |
stevegt_ |
anyway,
Ralith, ``Erik, thanks for being a sounding board -- i can see now
that i need to do the performance testing next, before i decide
anything else |
| 23:33.56 |
Ralith |
np |
| 23:33.58 |
Ralith |
best of
luck! |
| 02:15.03 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 02:50.12 |
CIA-32 |
BRL-CAD:
03indianlarry * r35080
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 02:50.12 |
CIA-32 |
BRL-CAD:
added adjacent face code to curve trims, also added cleanup of face
hitlist |
| 02:50.14 |
CIA-32 |
BRL-CAD: for
cases where multiple INs/OUTs of faces encountered |
| 02:53.22 |
CIA-32 |
BRL-CAD:
03indianlarry * r35081 10/brlcad/trunk/include/opennurbs_ext.h: add
adjacent face code to curve trims |
| 02:54.49 |
CIA-32 |
BRL-CAD:
03indianlarry * r35082 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
add adjacent face code to trim curves |
| 02:56.12 |
CIA-32 |
BRL-CAD:
03indianlarry * r35083 10/brlcad/trunk/src/ (libged/brep.c
librt/primitives/brep/brep_debug.cpp): added more debugging
code/options to mged brep command |
| 06:53.34 |
Ralith |
brlcad: I'd
like to discuss the possibility of just not rendering Qt into the
OpenGL context, at least for now; most of the rest of what I
proposed to work on can be completed with Qt simply sitting on
*top* of the context, although some parts might not be quite as
shiny as would otherwise be possible. |
| 06:54.43 |
Ralith |
and I don't
think it would take much rewriting to modify said work to operate
inside a GL context when a way is (hopefully) eventually
found. |
| 06:55.24 |
Ralith |
considering
how standard Qt widgets and even entire windows can be literally
dropped directly in with little or no special
consideration. |
| 06:56.25 |
Ralith |
I can produce
much more visible and interesting work this way, and continue
conversations with more Ogre- and Qt-knowledgable people to work
out the GL issue in the background. |
| 07:02.54 |
*** join/#brlcad LarsG
(n=lars@dial208-53.dialup.nus.edu.sg) |
| 07:03.01 |
*** part/#brlcad LarsG
(n=lars@dial208-53.dialup.nus.edu.sg) |
| 07:25.07 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 11:59.00 |
d-lo |
Mernin
all!! |
| 12:19.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) |
| 12:36.47 |
*** join/#brlcad docelic_
(n=docelic@78.134.200.170) |
| 13:01.37 |
``Erik |
*burp* |
| 13:03.04 |
``Erik |
any news on
the injector/server project, d-lo? |
| 13:36.17 |
CIA-32 |
BRL-CAD:
03brlcad * r35084
10/brlcad/trunk/src/other/step/src/cleditor/STEPfile.inline.cc: |
| 13:36.19 |
CIA-32 |
BRL-CAD:
apply a simple patch that should hopefully fix sf bug 2820579,
reported by Jeff |
| 13:36.21 |
CIA-32 |
BRL-CAD:
Meldrum (jspaces) regarding a const to non-const conversion.
according to a |
| 13:36.23 |
CIA-32 |
BRL-CAD:
handful of online sources, c++ apparently changes the signature of
strrchr from |
| 13:36.25 |
CIA-32 |
BRL-CAD: the
posix C decl with two overloaded possibilities, both input and
return are |
| 13:36.27 |
CIA-32 |
BRL-CAD:
either const or non-const. |
| 13:54.40 |
CIA-32 |
BRL-CAD:
03irpguardian * r35085 10/brlcad/trunk/src/proc-db/human.c: Changed
the torso parts to use a TGC instead of a RCC to make it less
bulkly looking, and more human shaped. |
| 14:26.55 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 14:30.19 |
d_rossberg |
d-lo: to have
a header file with defines for the version numbers appears to be an
issue of its own |
| 14:36.17 |
d_rossberg |
d-lo: because
of the common.h issue i need to have a look at my linux build at
home ... |
| 14:39.05 |
d-lo |
ah!
minimized the irc window. Sorry. |
| 14:39.36 |
d-lo |
fyi a simple
rename of common.h to cicommon.h worked like a champ. |
| 14:40.14 |
d-lo |
Looking
through things, I see that in order to generate
{RT3}/include/brlcad/brlcadversion.h, you have to have the source
from the BRLCAD module. |
| 14:41.00 |
d-lo |
One of the
assumptions I am making for the CMake build system in the rt^3
module is that, at a minimum, there is a BRLCAD install on the
machine. Not necessarily the source. |
| 14:41.24 |
d-lo |
so I suppose
I need to find out if there is a way to extract versioning
information from a BRLCAD install. |
| 14:41.28 |
d-lo |
.... anyone
know? |
| 14:42.02 |
d_rossberg |
this would
have been my next question :) |
| 14:42.23 |
*** join/#brlcad mafm (n=mafm@83.42.152.74) |
| 14:42.32 |
d-lo |
i remember
running across it somewheres.... just gotta find it :/ |
| 14:43.27 |
d-lo |
There is a
string reference to the package version on line 412 in
brlcad_config.h |
| 14:44.35 |
d-lo |
heh, I don't
even know if its possible to do string parsing with
CMake.... |
| 14:45.31 |
_clock_ |
d-lo: if it's
turing equivalent then definitely yes :) |
| 14:48.35 |
d_rossberg |
my philosophy
with the core Interface is something different from
yours: |
| 14:48.50 |
d_rossberg |
the core
interface is the interface for external programs |
| 14:49.13 |
d_rossberg |
there
shouldn't be any other include/brlcad |
| 14:50.07 |
d_rossberg |
and, to be
honest we don't have such a directory at the moment |
| 14:50.21 |
d-lo |
Hrm, then, I
suppose, the question is: Why are there coreInterface include
files in rt3? By that philosphy, shouldn't they be in the brlcad
module? |
| 14:50.40 |
d_rossberg |
the
include/brlcad from the installation has to be added explicitely (i
hink) to the inlude paths |
| 14:50.56 |
d_rossberg |
d-lo:
yes |
| 14:51.03 |
d-lo |
the
include/brlcad from the BRLCAD installation? |
| 14:51.10 |
d_rossberg |
however,
that's my opinion |
| 14:51.25 |
d_rossberg |
the one you
have the problem with |
| 14:52.59 |
d_rossberg |
now i
remember: i added only the include/brlcad directory from the
installation to the include paths |
| 14:53.08 |
d-lo |
Heh, well, if
its your opinion that they should be in the BRLCAD module... put em
there :) They're your babies, store them wherever you want :)
don't let that BRLCAD guy tell you otherwise :) |
| 14:53.29 |
d_rossberg |
i.e. not the
inlude directory alone |
| 14:54.22 |
d-lo |
ah, so
{BRLCAD_INSTALL_PATH}/include/brlcad/ and not
{BRLCAD_INSTALL_PATH}/include/ ? |
| 14:54.35 |
d_rossberg |
this way i
didn't get the confusion between the two common.h |
| 14:54.46 |
d_rossberg |
d-lo:
yes |
| 14:55.53 |
d-lo |
Another
question then: What is stopping you from moving the coreInterface
files into the brlcad module? |
| 14:57.44 |
d-lo |
doesn't want to sound offensive. Just trying to get rt^3
whipped into shape. |
| 14:58.07 |
d_rossberg |
there are
still some incompatibilities: e.g. which files should be copied
into the installation directory at include/brlcad ? :) |
| 14:59.38 |
d-lo |
why not put
all your headers into include/brlcad/ci/ ? |
| 14:59.46 |
d-lo |
resolves a
lot of problems... |
| 15:00.15 |
d_rossberg |
no, they are
intended for include/brlcad |
| 15:00.50 |
d_rossberg |
on the other
side, d-lo, you have a point ther with the common.h
issue |
| 15:01.15 |
d-lo |
heh, well I
am good at causing, er, finding problems. |
| 15:01.42 |
d_rossberg |
the core
interface should be usable in virtually every program |
| 15:02.20 |
d-lo |
Right, but
how does having the includes in include/brlcad/ci/ change that?
*confused* |
| 15:03.19 |
d_rossberg |
i.e. we may
solve the issue with our own includes, but it could be wise to have
a prefix for the BRL-CAd headers |
| 15:03.53 |
d_rossberg |
... i see the
ci as the only interface, so why should it be in a
subdirectory? |
| 15:04.32 |
d-lo |
Organizational reason only. |
| 15:05.03 |
d-lo |
As far as I
can tell, common.h is the only conflict. all the rest of the
coreInterface headers don't conflict. |
| 15:05.34 |
d-lo |
And for
organizational reasons, you are thinking that there should be
prefixes on headers? Did I understand that correctly? |
| 15:06.57 |
d_rossberg |
at the moment
it is only an idea, i thought brlcad/ is already prefix enough
... |
| 15:07.16 |
d-lo |
ah, okay. I
see what you mean. |
| 15:07.52 |
d-lo |
I haven't
looked at the difference in the files, but is there a way to merge
the two common.h's or should it be solved by a rename of one of
them? |
| 15:08.31 |
d_rossberg |
you could
rename it to brlcadcommon.h |
| 15:08.44 |
d_rossberg |
this name
would match with brlcadversion.h |
| 15:09.30 |
d-lo |
so
rt^3/include/brlcad/common.h ->
rt^3/include/brlcad/brlcadcommon.h ? |
| 15:09.39 |
d_rossberg |
yes |
| 15:10.10 |
d-lo |
and then once
that rename is done, would there be any other problems moving the
coreInterface files to the brlcad module? |
| 15:10.14 |
d_rossberg |
and maybe
rt^3/include/brlcad/globals.h -> |
| 15:10.28 |
d_rossberg |
rt^3/include/brlcad/brlcadglobals.h |
| 15:10.39 |
d-lo |
okay, the
globals makes sense also. |
| 15:11.01 |
d_rossberg |
the other
file names start with a capital letter |
| 15:11.07 |
d_rossberg |
i.e. are
unique |
| 15:11.42 |
d_rossberg |
(at least fot
*IX) |
| 15:12.10 |
d-lo |
right
on. |
| 15:13.03 |
d-lo |
If you would
like, I can move the coreInterface files over to the BRLCAD
module... or I can just leave them where they are and unwire them
from the CMake build system I am making. Your choice, whatever you
feel like. :) |
| 15:16.29 |
CIA-32 |
BRL-CAD:
03davidloman * r35086 10/rt^3/trunk/cmake/FindBRLCAD.cmake: Fixing
some bugs in FindBRLCAD.cmake |
| 15:21.38 |
d_rossberg |
how does this
go together with your plans with the "Geometry Engine"? |
| 15:22.34 |
d-lo |
I am working
on changing the whol rt3 module over to CMake, and since
coreInterface is in the rt3 module, I assumed I needed to work it
in to the build also. |
| 15:24.46 |
d_rossberg |
i meant you
wanted to make the coreInterface part of your GE |
| 15:26.35 |
d_rossberg |
has to go now |
| 15:51.00 |
brlcad |
~seen
madant |
| 15:51.01 |
ibot |
madant
<i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last
seen on IRC in channel #brlcad, 9d 19h 29m 7s ago, saying: 'nothing
more disastrous than non-cooperative softwares ;)'. |
| 15:51.30 |
d-lo |
wow... 9
days |
| 15:58.40 |
CIA-32 |
BRL-CAD:
03davidloman * r35087 10/rt^3/trunk/src/ (3 files in 3 dirs):
Unwiring coreInterface from CMake for now. There is a dependancy
that requires the brlcad source to be present on the computer
instead of just the installation. |
| 15:58.41 |
d-lo |
howdy brlcad
! |
| 16:08.45 |
d-lo |
hates having an ogre<->boost dep. |
| 16:08.49 |
d-lo |
bangs head on wall. |
| 16:18.15 |
d-lo |
Ralith:
based on what I have read, I think your current approach is the
best. You may have to modify your GSoC goals though. |
| 16:20.22 |
brlcad |
boost is an
easy dep, just a bunch of header files :) |
| 16:20.59 |
d-lo |
right, but
ogre isn't building without it. Even when i set OGRE_USE_BOOST to
OFF, it still tries to link against it :/ |
| 16:21.21 |
brlcad |
so? .. don't
turn it off.. |
| 16:21.46 |
d-lo |
not to
mention, when it IS properly linking, its claiming that
boost::thread::hardware_concurrency() doesn't exist... when it
does. grrr. |
| 16:22.01 |
brlcad |
or you mean
they don't provide it and our subset doesn't provide what they need
either? |
| 16:22.05 |
d-lo |
Right, I have
tried it both ways, both have compile problems. |
| 16:22.21 |
d-lo |
I have boost
installed in its entirety. |
| 16:22.27 |
brlcad |
boost
threading is in the core, which brlcad module provides |
| 16:22.47 |
d-lo |
Even with
that, ogre is failing |
| 16:23.00 |
brlcad |
then that's a
problem with ogre, not boost |
| 16:23.08 |
d-lo |
right. |
| 16:23.16 |
d-lo |
never said it
wasn't. :) |
| 16:23.50 |
brlcad |
well the
"hate" is still somewhat misplaced :) |
| 16:24.19 |
brlcad |
i mean you're
free to hate whatever you want, of course :) |
| 16:24.27 |
d-lo |
I was gonna
say... |
| 16:24.33 |
d-lo |
its MY hate
not yours. |
| 16:24.35 |
d-lo |
get your
own |
| 16:24.41 |
brlcad |
i hate
you! |
| 16:24.48 |
d-lo |
*GASP* |
| 16:24.59 |
d-lo |
Don't me
hatin |
| 16:25.14 |
brlcad |
hates d-lo's ogre<->boost hate |
| 16:25.41 |
d-lo |
I figure
since Ogre loves boost so much, I *MUST* hate boost. Seems
natural. |
| 16:27.18 |
brlcad |
aside: you do
know that most/many of the core (tr1) components of boost are going
to become part of the c++ standard, yes? |
| 16:27.18 |
d-lo |
when I build
BRLCAD and install it, does libboostcore get installed
also> |
| 16:27.20 |
d-lo |
? |
| 16:27.53 |
d-lo |
Yeah, you
mentioned that. I figure that will be a good time to become a pure
C Zealot. ;) |
| 16:28.09 |
brlcad |
heh |
| 16:29.26 |
brlcad |
libboostcore?? |
| 16:30.05 |
d-lo |
yes, boost's
core lib that you said is in the brlcad module. |
| 16:30.17 |
brlcad |
it's not a
lib, it's headers |
| 16:30.24 |
d-lo |
well,
whateveritsactuallycalled. |
| 16:30.53 |
d-lo |
so it gets
installed then? |
| 16:31.22 |
brlcad |
if you mean
do we install the headers, I don't believe so at the moment as
there was no need |
| 16:32.00 |
brlcad |
would be
trivial to install, but if we do that, we probably should bundle
more than we are bundling so it's a complete dependency |
| 16:32.06 |
brlcad |
not a subset
like it presently is |
| 16:32.15 |
d-lo |
Well hell.
How am I going to make Ogre behave then..... hrm |
| 16:32.23 |
brlcad |
or you make
rt^3's build require having a brlcad source tree as
well |
| 16:32.39 |
brlcad |
or you just
require folks install all of boost first, old school |
| 16:33.53 |
d-lo |
I was
wondering about that... what would be your opinion of 'best
practice'? Linking rt3 to a brlcad install or making rt3 dependant
on the brlcad source? |
| 16:38.21 |
brlcad |
plenty of
projects do both, the latter tends to suck more as it's just mostly
dev convenience |
| 16:38.36 |
brlcad |
rt3 already
requires a brlcad install, that's inevitable |
| 16:39.21 |
brlcad |
and our
project practice is towards dependency management, not
user-required actions (having them install boost would be a
user-required dependency action) |
| 16:39.44 |
brlcad |
short term,
though, doesn't really matter -- so, they have to install
qt+boost |
| 16:40.18 |
brlcad |
long term,
can probably upgrade the boost dep in brlcad module to a full copy
and have it fully managed like other deps |
| 16:41.44 |
d-lo |
alrighty
then. |
| 16:41.58 |
d-lo |
Have you read
up on what Dr Rossberg and I were yaking about? |
| 16:42.18 |
starseeker |
thinks cracking proper Qt/OGRE integration would be very
useful, even if it produces less visible
result... |
| 16:43.46 |
d-lo |
starseeker:
when I get install permission failures concerning tkhtml3, do i
need to --disable-documentation to bypass that? |
| 16:44.11 |
brlcad |
not yet,
working on evals |
| 16:44.11 |
starseeker |
no, that's a
mistake in the make file |
| 16:44.24 |
starseeker |
is that that
nroff thing? |
| 16:44.25 |
d-lo |
brlcad:
okie. |
| 16:44.30 |
starseeker |
huts |
| 16:44.34 |
starseeker |
er, hunts
even |
| 16:44.42 |
brlcad |
has
indianlarry done his eval yet? |
| 16:44.53 |
brlcad |
he hadn't as
of this morning |
| 16:45.00 |
brlcad |
only has an
hour or so before the deadline |
| 16:45.05 |
starseeker |
I'll
ask |
| 16:49.19 |
starseeker |
d-lo: what's
the specific failure on the permission? |
| 16:49.44 |
d-lo |
I don't have
access to /usr |
| 16:49.50 |
d-lo |
err write
access |
| 16:51.45 |
starseeker |
hmm. |
| 16:52.02 |
starseeker |
I remember
seeing that, and it had something to do with tkhtml.n |
| 17:05.21 |
CIA-32 |
BRL-CAD:
03starseeker * r35088
10/brlcad/trunk/src/other/tkhtml3/Makefile.in: Don't set DESTDIR to
empty in tkhtml3 Makefile.in |
| 17:05.28 |
starseeker |
d-lo: does
that help? |
| 17:05.43 |
d-lo |
lemme
check. |
| 17:09.42 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:09.53 |
d-lo |
*buildbuildbuild* |
| 17:13.04 |
d-lo |
starseeker:
Nope :( still getting: mkdir: cannot create directory
`/usr/lib/Tkhtml3.0': Permission denied when trying to install to
/home/dloman/ |
| 17:13.24 |
starseeker |
hmm |
| 17:16.55 |
starseeker |
grr |
| 17:21.58 |
brlcad |
could be some
DESTDIR problem if there are custom install rules (not that there
should be custom install rules) |
| 17:22.40 |
starseeker |
is wondering if the TEA extensions are getting into the
act |
| 17:22.50 |
brlcad |
hm, could
be |
| 17:22.57 |
brlcad |
loooks like
they do have DESTDIR properly |
| 17:23.20 |
starseeker |
that's why I
nuked the empty DESTDIR line - thought perhaps that was killing the
DESTDIR feed from configure |
| 17:23.42 |
starseeker |
wonder why it
doesn't happen on all platforms... |
| 17:24.19 |
starseeker |
ponders a pleading email to the TEA devs to integrate with
autoconf/automake out of the box... |
| 17:24.24 |
brlcad |
maybe it
does |
| 17:24.41 |
starseeker |
just did a make install on the mac - went to my local
directory |
| 17:24.52 |
brlcad |
have him send
you his Makefile that was generated, compare it to
yours |
| 17:25.45 |
d-lo |
starseeker:
do you have write permissions to /usr/lib/ ? |
| 17:25.54 |
starseeker |
I
shouldn't |
| 17:26.14 |
starseeker |
nope |
| 17:26.21 |
d-lo |
starseeker:
FYI, just got same error. |
| 17:27.01 |
d-lo |
where is the
brlcad.org pastbin again? |
| 17:27.19 |
starseeker |
~pastebin |
| 17:27.20 |
ibot |
[~pastebin] A
"pastebin" is a web-based service where you can paste anything over
3 lines without flooding the channel. Here are links to a few :
http://www.pastebin.com ,
http://pastebin.ca , http://channels.debian.net/paste
, http://paste.lisp.org ,
http://www.rafb.net/paste |
| 17:28.02 |
starseeker |
well, I don't
see ours there... |
| 17:29.00 |
d-lo |
ah ha:
http://pastebin.bzflag.bz/ |
| 17:30.29 |
d-lo |
starseeker:
http://pastebin.bzflag.bz/m94c45f1 |
| 17:33.18 |
``Erik |
*readreadread* |
| 17:33.54 |
brlcad |
d-lo: you can
tell rain that I made her some ceviche de camarones |
| 17:33.56 |
brlcad |
i'll bring
some in for everyone to try tomorrow |
| 17:34.07 |
d-lo |
kk |
| 17:34.08 |
``Erik |
that
sounds... so.. wrong... |
| 17:34.35 |
brlcad |
so
yummy! |
| 17:34.47 |
d-lo |
from Rain:
Spicy |
| 17:34.48 |
d-lo |
? |
| 17:35.04 |
d-lo |
'Rain's
Spicy' that is. |
| 17:43.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) |
| 17:52.19 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35089 10/isst/trunk/src/main.c: set database and
master hostnames in main() |
| 17:53.31 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35090 10/isst/trunk/src/gui.c: extract attach
code out of validation function |
| 17:57.38 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35091 10/isst/trunk/ (8 files in 2 dirs):
indent. |
| 18:02.07 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35092 10/isst/trunk/src/main.c: fix wrong
variable being set. woops. |
| 18:02.18 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35093 10/isst/trunk/src/gui.c: have .g loading
automatically attach to the master daemon. |
| 18:06.38 |
CIA-32 |
BRL-CAD:
03starseeker * r35094
10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Ooops - add in the
check to ensure bounding box dimensions are not degenerate in x, y
or z |
| 18:17.43 |
brlcad |
not so
spicy |
| 18:17.57 |
brlcad |
I made it
pretty mild |
| 18:18.21 |
brlcad |
she'll
probably still think it's hot, but it's not anywhere near what I
usually do |
| 18:18.39 |
brlcad |
only used a
few habaneros for nearly 2lbs of shrimp |
| 18:21.44 |
brlcad |
starseeker:
any reason to not just increment the amount you tested
against? |
| 18:22.13 |
brlcad |
pushing both
max and min will make it 2x that value, should be
enough |
| 18:22.22 |
brlcad |
and a lot
tighter |
| 18:23.34 |
starseeker |
brlcad:
That's an option - right now I'm just trying to reproduce the
bounding box behavior of the original code |
| 18:23.41 |
starseeker |
still not
there yet :-( |
| 18:24.46 |
starseeker |
Once I do, I
can go back and tighten it to the tolerance and see what that does
:-) |
| 18:25.00 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:29.45 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35095 10/brlcad/trunk/src/adrt/slave/load_g.c:
join slave_load_g() and some_intermediate_function() |
| 18:33.27 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) |
| 18:35.37 |
``Erik |
*snrkt* wells
fargo sueing itself, grand |
| 18:37.39 |
starseeker |
so when
lawyers run out of targets, they start suing
themselves? |
| 18:38.02 |
``Erik |
it's on
/. |
| 18:38.54 |
``Erik |
comments seem
to indicate the combination of wells fargo having two mortgages on
a house and florida law are forcing it to happen
*shrug* |
| 18:41.14 |
starseeker |
talk about
poetic justice... |
| 18:47.35 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 18:52.29 |
``Erik |
here's a
better one, deep purple is paying fines for playing their own
songs |
| 18:52.34 |
``Erik |
http://techdirt.com/articles/20090710/0340345512.shtml |
| 18:59.50 |
d-lo |
``Erik: heres
SimStapler http://www.freeverse.com/games/game/?id=7022 |
| 19:27.01 |
``Erik |
nice |
| 19:29.33 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-160.sbndin.btas.verizon.net) |
| 19:33.05 |
``Erik |
what're the
build instructions for the gs thingymajigger? |
| 19:35.41 |
d-lo |
1) cmake
. |
| 19:35.45 |
d-lo |
2)
make |
| 19:35.58 |
d-lo |
Qt needs to
be in your PATH |
| 19:35.58 |
``Erik |
ok, so I
gotta figure out how to get cmake installed |
| 19:36.01 |
``Erik |
and
qt |
| 19:36.19 |
d-lo |
automake is
still working btw. |
| 19:36.28 |
d-lo |
err autotools
build still works. |
| 19:36.54 |
``Erik |
hm, thought I
ran into issues with auto* |
| 19:47.15 |
``Erik |
hrm, are you
building 64b? |
| 19:47.42 |
d-lo |
yes. whats
up? |
| 19:48.06 |
``Erik |
GS/tests/streamSerialTests.cxx makes some
bad assumptions... "unsigned long" being 64b where it's 32 on a 32
bit system |
| 19:48.21 |
``Erik |
uint64_t
might be better for that |
| 19:48.57 |
d-lo |
righto, its
on the lists of things to fix. That was an ooooooold hack that I
never got around to working on yet. ;) |
| 19:49.41 |
d-lo |
Well, I out.
Peace. |
| 19:55.39 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35096
10/rt^3/trunk/src/tests/streamSerialTests.cxx: use types with
explicit widths. Change 'long' to 64b int. Change magic #s to hex
(should it be stdint.h INTX_MAX?). |
| 20:10.27 |
CIA-32 |
BRL-CAD:
03irpguardian * r35097
10/brlcad/trunk/src/proc-db/human.c: |
| 20:10.29 |
CIA-32 |
BRL-CAD:
Completly redone all functions to take human data structure, as
opposed to numerous variables. |
| 20:10.31 |
CIA-32 |
BRL-CAD:
However, currently does not build anything, as it bus-fails when
attempting to put information into |
| 20:10.33 |
CIA-32 |
BRL-CAD: the
human_data->torso->torsoLength location. |
| 20:38.57 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 20:50.25 |
Ralith |
d-lo: I don't
see anything particularly critical about rendering Qt *in* OpenGL.
I mean, it has nice parts and is certainly desirable, but it's
quite possible to get by without itâlook at the
competition. |
| 20:51.51 |
CIA-32 |
BRL-CAD:
03irpguardian * r35098 10/brlcad/trunk/src/proc-db/human.c: Fixed
it to where the human builds, but some parts are not in their
correct locations |
| 20:58.18 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 20:58.53 |
CIA-32 |
BRL-CAD:
03irpguardian * r35099
10/brlcad/trunk/src/proc-db/human.c: |
| 20:58.55 |
CIA-32 |
BRL-CAD:
Fixed everything, so now it's a human generator with all variables
stored in the human_data_t struct. |
| 20:58.58 |
CIA-32 |
BRL-CAD: Even
works with all poses. |
| 21:50.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-160.sbndin.btas.verizon.net) |
| 22:13.25 |
``Erik |
"fixed
everything" hehehe, if only |
| 22:23.26 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 22:48.03 |
``Erik |
nice, my alma
mater made collegehumor.com http://www.freeverse.com/games/game/?id=7022 |
| 22:48.07 |
``Erik |
woops |
| 22:48.36 |
``Erik |
http://www.collegehumor.com/picture:1916488 |
| 22:53.27 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 23:23.01 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 23:28.46 |
``Erik |
*omnomnom* mm
bourbon steak strips |
| 23:29.24 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 23:37.18 |
*** join/#brlcad BigAToo2
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 23:39.05 |
*** join/#brlcad BigAToo3
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 23:39.56 |
*** join/#brlcad BigAToo4
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 00:10.54 |
``Erik |
it was the
best of times, it was the blurst of times |
| 01:05.40 |
``Erik |
that should
make pedro happy, 7.14.8 port has been submitted for
fbsd |
| 01:38.55 |
*** join/#brlcad stevegt_
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 03:14.28 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 03:39.51 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 03:51.25 |
CIA-32 |
BRL-CAD:
03starseeker * r35100
10/brlcad/trunk/include/opennurbs_cleanup.h: |
| 03:51.27 |
CIA-32 |
BRL-CAD: Ah
HAH. Fix the flatness test to use corner and interior points the
way the old |
| 03:51.29 |
CIA-32 |
BRL-CAD:
setup did (even though the interior points are a bit different.)
Appears to fix |
| 03:51.31 |
CIA-32 |
BRL-CAD: the
visual flaws from the default rt view, but the strange symmetrical
dot lines |
| 03:51.33 |
CIA-32 |
BRL-CAD: in
the top down view (that disappear on zoom in) are still
there. |
| 03:55.34 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 04:41.09 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 05:52.29 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 05:55.26 |
*** join/#brlcad _sushi_
(n=_sushi_@84-73-206-47.dclient.hispeed.ch) |
| 08:37.07 |
*** join/#brlcad Patmcc19_
(n=chatzill@71-223-63-122.phnx.qwest.net) |
| 09:45.41 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 10:50.52 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 11:01.53 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 11:28.22 |
CIA-32 |
BRL-CAD:
03jdoliner * r35101 10/brlcad/trunk/ (6 files in 3 dirs): Initial
commit for bivariate polynomial support |
| 11:49.02 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-46-33.phnx.qwest.net) |
| 11:49.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 11:59.06 |
brlcad |
jdoliner:
fyi, several of your defines are provided in
include/vmath.h |
| 11:59.24 |
brlcad |
and should
use the std math macros for min/max like other parts of the code
(follow suit) |
| 12:02.00 |
brlcad |
also, make
sure you don't replicate functionality that is included in the
JAMA/TNT library in src/other, includes various numeric routines
(lu decomposition, eigenvectors, matrix manipulations,
etc) |
| 12:04.22 |
jdoliner |
how high
level do its routines get? |
| 12:08.18 |
jdoliner |
the types of
computations that we need to do are pretty high level, I don't
think we have anything right now capable of doing it |
| 12:08.28 |
jdoliner |
I guess we
already knew about that |
| 12:08.40 |
jdoliner |
otherwise it
wouldn't be much of a challange now would it |
| 12:10.09 |
jdoliner |
so I think at
least for some of the more nuts and boltsy polynomial algorithms it
would be smarter to link in another library |
| 12:10.16 |
jdoliner |
instead of
rewriting it all |
| 12:10.53 |
jdoliner |
because it's
some pretty technical stuff |
| 12:10.58 |
jdoliner |
what say
you? |
| 12:12.33 |
brlcad |
the closest
is probably the specialized evaluations used within the current
nurbs raytracing code (which is what indianlarry was mention
earlier about evaluations being highly related) |
| 12:14.22 |
brlcad |
take a look
at src/other/tnt first and see what you could leverage, there's
also the option to utilize stuff in boost as we already depend on
that, and then the specialized routines in
src/librt/primitives/brep/* and src/librt/opennurbs_* |
| 12:15.23 |
brlcad |
the biggest
concern is keeping the entropy low in order to improve
maintainability -- that means keeping depencencies low/simple but
not reinventing and leveraging what's already available as much as
possible |
| 12:16.41 |
brlcad |
can't
overlook simple things like sqrt(3) defines, even more important to
leverage existing infrastructure for higher-level routines that
don't exist |
| 12:30.47 |
jdoliner |
so it looks
like there's some stuff in src/libry/primitives/brep that I can
leverage for a marching implementation |
| 12:34.37 |
brlcad |
if you do,
try to generalize so both codes use the same routines, not just
copy and specialize, if at all possible |
| 12:35.03 |
brlcad |
otherwise
it's just as bad as writing it from scratch |
| 12:36.03 |
jdoliner |
k |
| 12:45.04 |
*** join/#brlcad Patmcc19_
(n=chatzill@71-223-43-80.phnx.qwest.net) |
| 12:50.23 |
starseeker |
Fair warning
- the opennurbs_ext.* and brep* codes are in a state of rather
massive flux at the moment |
| 12:54.33 |
*** join/#brlcad docelic_
(n=docelic@78.134.204.215) |
| 13:01.46 |
``Erik |
*nod*
converting adrt from its own homerolled stuff to vmath was a time
consuming process even with sed |
| 13:24.35 |
*** join/#brlcad Don_ (n=Don@71.238.51.148) |
| 13:27.32 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:28.01 |
jdoliner |
starseeker:
thanks I guess I'll just have to enter the fray :) |
| 13:30.11 |
*** join/#brlcad BigAToo
(n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 13:35.47 |
*** join/#brlcad mafm_
(n=mafm@83.42.152.74) |
| 13:36.19 |
*** join/#brlcad BigAToo
(n=BigAToo@69.95.46.65) |
| 13:39.43 |
``Erik |
oh
heh |
| 13:40.48 |
``Erik |
Herr Roßberg,
I just responded to your version email, did I understand you
correctly? |
| 13:43.00 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 13:43.07 |
d_rossberg |
``Erik:
brlcad_version.h is unfortunately not part of the installation
(make install) |
| 13:44.03 |
``Erik |
hm,
bu_version() in libbu isn't adequate? |
| 13:44.11 |
``Erik |
(or was it
bu_ident() hrm) |
| 13:44.32 |
d_rossberg |
i.e. the
information i need is of course in the BRL-CAD sources, but not in
the standard installation |
| 13:45.02 |
d_rossberg |
bu_version()
gives the version information on run-time but not on compile
time |
| 13:46.20 |
``Erik |
whistles innocently |
| 13:46.21 |
d_rossberg |
i.e. i want
to compare the version i used to compile/link my program with the
version of the BRL-CAD libraries i'm using on run-time |
| 13:46.33 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35102 10/brlcad/trunk/include/Makefile.am:
install brlcad_version.h for third party apps to use |
| 13:47.00 |
d_rossberg |
brlcad_version.h needs the conf directory
... |
| 13:47.03 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-53-118.phnx.qwest.net) |
| 13:47.11 |
``Erik |
ahhh,
yeahhhhhhh |
| 13:47.52 |
``Erik |
gimme a
minute, need a cup of coffee, then I'll do... something...
horrible |
| 13:50.00 |
``Erik |
what I'm
thinking probably won't groove well with msvc |
| 13:50.07 |
d_rossberg |
this looks
like a shot from the hip :| |
| 13:50.25 |
``Erik |
no, this is
more bull in chinashop :D |
| 13:50.46 |
d_rossberg |
maybe it
would work with CMake |
| 13:51.14 |
d_rossberg |
i'm using
CMake currently to generate my brlcadversion.h |
| 13:52.23 |
d_rossberg |
the
generation of COUNT/DATE/HOST etc works with CMake too |
| 14:04.42 |
``Erik |
effin' pain
to type with this cast, stupid broken wrist :( |
| 14:21.15 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35103 10/brlcad/trunk/include/ (Makefile.am
brlcad_version.h brlcad_version.h.in): remove brlcad_version.h
dependancy on conf. (still need to de-GNU the makefile a
bit.) |
| 14:23.37 |
CIA-32 |
BRL-CAD:
03irpguardian * r35104
10/brlcad/trunk/src/proc-db/human.c: |
| 14:23.39 |
CIA-32 |
BRL-CAD:
Added functionality to the custom position stance (-s999) which
takes |
| 14:23.41 |
CIA-32 |
BRL-CAD: in
XYZ for setting arm position in degrees. |
| 14:28.07 |
brlcad |
jdoliner:
nice work commenting on the tracker item, but don't forget the
other fields -- you should assign it to yourself and close it out
at a minimum, could also set low priority and a category of being a
compilation issue |
| 14:29.52 |
brlcad |
for auditing
purposes, your commit that fixes the bug can say the sf tracker
number that it refers to (e.g., this fixes sf tracker # 1234567
reported by blah (rt crash on exit)), then can tell the user which
commit that was in your closing comment so they can make sure they
have the right svn revision to test the fix |
| 14:33.13 |
brlcad |
d_rossberg:
that was done intentionally, whether good or bad, that the version
header files aren't installed |
| 14:33.16 |
d_rossberg |
``Erik: i
think i see where this will lead to ... i'll see how this can be
done with CMake ... |
| 14:34.07 |
d_rossberg |
i assumed
that thia was your intention |
| 14:34.19 |
brlcad |
with the
intent being that only run-time information is used with the libs
since the headers could conceivably be out of sync |
| 14:34.41 |
brlcad |
most
importantly, to avoid projects that might get into a habit of
relying on any defines in a bad way |
| 14:35.13 |
brlcad |
#if
BRLCAD_MAJOR == 7 && BRLCAD_MINOR == 10 ... do one thing ..
else do something worse |
| 14:35.30 |
brlcad |
aside from
header mismatches too |
| 14:36.15 |
brlcad |
there is the
brlcad-version configuration script, that is meant to provide
compile-time libs, linkage, and version information |
| 14:36.27 |
brlcad |
we could turn
that into a binary so that windows has it as well |
| 14:37.28 |
brlcad |
what is the
exact problem that needs solving? |
| 14:39.28 |
``Erik |
doesn't like this. :/ |
| 14:39.57 |
d_rossberg |
if the libs
and the headers are out of sync you are in trouble any way,
or? |
| 14:40.22 |
*** join/#brlcad BigAToo
(n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 14:40.28 |
brlcad |
not
necessarily, we rarely ever break ABI compat on the C
side |
| 14:41.30 |
brlcad |
it's happened
in isolated cases before too, nothing major but then we didn't give
them a means to rely on a behavior or conditionalize their code at
compile-time |
| 14:41.58 |
*** join/#brlcad BigAToo1
(n=BigAToo@69.95.46.65) |
| 14:43.03 |
*** join/#brlcad Patmcc19_
(n=chatzill@71-223-54-29.phnx.qwest.net) |
| 14:44.02 |
indianlarry |
jdoliner: Hey
Joe, you around? |
| 14:46.37 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35105 10/brlcad/trunk/include/ (Makefile.am
brlcad_version.h brlcad_version.h.in): revert changes with
brlcad_version.h |
| 14:48.01 |
``Erik |
tries to wake up O.o |
| 14:48.15 |
d_rossberg |
brlcad:
therefore you have/had projects with different versions of run-time
(libs) and interface descriptions (headers) where you want to
prevent trhe user to see this difference? |
| 14:49.06 |
d_rossberg |
... because
he could do something ugly with this information? |
| 14:49.45 |
*** join/#brlcad Patmcc19__
(n=chatzill@71-223-60-113.phnx.qwest.net) |
| 14:50.34 |
d_rossberg |
btw, where
can i find this brlcad-version script? |
| 14:51.00 |
``Erik |
$PREFIX/bin/brlcad-config |
| 14:51.26 |
``Erik |
there're also
pkg-config files (.pc) floating around |
| 14:55.23 |
brlcad |
d_rossberg:
no, I don't want to accommodate a bad install -- that wasn't the
point -- but I do want to try to prevent devs from using defines as
compile-time conditionals |
| 14:56.49 |
brlcad |
pkg-config is
a 'standard' application that uses our config descriptor files --
more portable, less custom. brlcad-config is our project-specific
version of that same interface |
| 14:57.07 |
brlcad |
"brlcad-config --version" for
example |
| 14:57.25 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 14:57.57 |
brlcad |
g'morning
elena |
| 14:58.06 |
elena |
hi
brlcad. |
| 14:58.26 |
elena |
do you have
time for one question? |
| 14:58.29 |
CIA-32 |
BRL-CAD:
03brlcad * r35106 10/brlcad/trunk/src/librt/ (opennurbs_cleanup.cpp
opennurbs_ext.cpp): |
| 14:58.31 |
CIA-32 |
BRL-CAD:
refactor the tolerances being used into TOL and TOL2 to make it
more apparent |
| 14:58.33 |
CIA-32 |
BRL-CAD: that
there are two numbers being used. should test and document the
effect of |
| 14:58.34 |
elena |
possible with
a long answer. |
| 14:58.35 |
CIA-32 |
BRL-CAD:
tightening/loosening these tolerances or make them functions if
they need to be |
| 14:58.37 |
CIA-32 |
BRL-CAD:
dynamic based on model parameters. |
| 14:58.42 |
``Erik |
no, he has
time for eleventy billion :D *duck* |
| 14:59.09 |
elena |
if he
doesn't, i'll get you ;) |
| 14:59.29 |
``Erik |
panics and bolts |
| 14:59.35 |
elena |
:) |
| 15:00.55 |
``Erik |
assumes brlcad is not planning on getting in early enough to
chuck his crevice or creviche or whatever in the fridge and join
the lunch crowd? O.o |
| 15:03.06 |
``Erik |
(elena: just
ask your question and lurk for best results, someone will
eventually answer your question even if everyone is busy at that
moment) |
| 15:03.54 |
elena |
when I
convert from other formats to brlcad, will I get different
objects? |
| 15:04.00 |
elena |
or a single
main object. |
| 15:04.06 |
``Erik |
depends on
the original format |
| 15:04.14 |
elena |
i suspect
different file formats will give diferent results. |
| 15:04.19 |
elena |
aha. |
| 15:04.53 |
elena |
next, is
there a comment somewhere, where i can find which format creates
different objects? |
| 15:04.54 |
``Erik |
if sane
'region' style information can be extracted from the original
source, the converters will generally try to build regions... if
it's just soup, then ya get soup |
| 15:05.12 |
elena |
aha. |
| 15:05.21 |
elena |
thanks,
erik. |
| 15:05.30 |
elena |
you're off
(for now) ;) |
| 15:05.33 |
``Erik |
um, I don't
believe there is a single document that gives that information? the
man pages and source files are all available... |
| 15:05.44 |
``Erik |
that might
make a good wiki page |
| 15:05.52 |
elena |
i think the
right expression is "off the hook" |
| 15:06.13 |
``Erik |
(who'm I
kidding, EVERYTHING makes a good wiki page... I'm gonna go make a
wiki page about what I'm going to have for lunch) |
| 15:06.22 |
d_rossberg |
brlcad: i'll
think about it ... tomorrow |
| 15:06.31 |
``Erik |
yes, off the
hook is a common american (possibly english) expression
:) |
| 15:06.32 |
brlcad |
``Erik: i
already have lunch plans |
| 15:06.34 |
elena |
send here the
link. |
| 15:06.35 |
brlcad |
d_rossberg:
ok |
| 15:06.57 |
brlcad |
d_rossberg:
likewise.. but what is the problem situation? or is that described
in the e-mail? |
| 15:07.03 |
brlcad |
i've not read
it all just yet |
| 15:07.17 |
d_rossberg |
it should be
in my e-mail |
| 15:07.21 |
brlcad |
okay |
| 15:07.36 |
brlcad |
then no need
to rehash, I'll reply if have questions |
| 15:08.19 |
brlcad |
elena:
different file formats can give vastly different results,
especially if it changes the format of the geometry |
| 15:09.22 |
brlcad |
at the
simplest level, you can just report the geometry format -- most all
formats fall into one of just a few categories of formats and
operations |
| 15:10.27 |
brlcad |
e.g.
regardless of the format, you can say whether a given _format_
supports boolean operations or not, and whether a given model uses
boolean operations |
| 15:12.12 |
brlcad |
three really
common geometry formats are implicit representation (which go
hand-in-hand with booleans operations) and explicit representation
(which generally don't use booleans but *can*) |
| 15:12.52 |
brlcad |
er, sorry --
I said three -- there are two primary explicit formats, polygonal
meshes and spline surfaces |
| 15:13.52 |
brlcad |
uploads his overview presentation |
| 15:15.52 |
elena |
would it make
sense to setup some experiments |
| 15:15.56 |
elena |
to convert
from brlcad to different formats and back |
| 15:15.58 |
elena |
or the
exporter may also destroy geometry? |
| 15:16.08 |
elena |
did you get
my previous question? (i got disconnected) |
| 15:16.32 |
elena |
would it make
sense to setup some experiments to convert from brlcad to different
formats and back or the exporter may also destroy
geometry? |
| 15:19.25 |
brlcad |
conversions
are rarely ever lossless |
| 15:20.03 |
elena |
ok. thank
you. |
| 15:20.27 |
elena |
have a great
lunch (both of you) |
| 15:20.49 |
brlcad |
so setting up
samples aren't really going to help -- all you can really speak to
is what you have format-wise and object-wise |
| 16:00.19 |
CIA-32 |
BRL-CAD:
03IRPGuardian 07http://brlcad.org *
r1567 10/wiki/Cutting_and_Pasting_PIX_files: /* Cutting and Pasting
Pix Files */ |
| 16:05.09 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 16:52.58 |
``Erik |
*burp* |
| 17:21.19 |
CIA-32 |
BRL-CAD:
03bob1961 * r35107 10/brlcad/trunk/ (include/ged.h
src/libged/copy.c src/libtclcad/ged_obj.c): |
| 17:21.21 |
CIA-32 |
BRL-CAD:
Added ged_dbcopy to libged for copying between databases. Added
go_copy to |
| 17:21.23 |
CIA-32 |
BRL-CAD:
libtclcad to use ged_dbcopy. The immediate need here is to have
Archer use this |
| 17:21.25 |
CIA-32 |
BRL-CAD: for
its undo ledger instead of "get" and "put" which is potentially
lossy. |
| 17:29.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 17:47.23 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 17:49.50 |
*** join/#brlcad BigAToo2
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 18:13.20 |
CIA-32 |
BRL-CAD:
03starseeker * r35108 10/brlcad/trunk/ (3 files in 3 dirs): Start
trying to figure out the trimming code and how to integrate trim
testing into the surface tree build (essential for correct bounding
box generation) |
| 18:17.27 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35109 10/brlcad/trunk/src/libged/ (49 files):
Some warning cleanup. Added missing headers, fixed varargs stuff
with too many or too few arguments provided. Minor type fixes.
Etc. |
| 18:32.54 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35110 10/brlcad/trunk/src/adrt/ (8 files in 4
dirs): reduce warnings. |
| 18:41.10 |
elena |
starseeker? |
| 18:41.55 |
elena |
``Erik? |
| 18:44.04 |
``Erik |
elena? |
| 18:44.28 |
elena |
did you used
starseeker's famous 1+ GB models? |
| 18:45.09 |
elena |
or any really
big database. |
| 18:45.38 |
elena |
does it take
long to start mged with it? |
| 18:46.02 |
elena |
i have to do
some scripts for mged. |
| 18:46.26 |
elena |
it would be
easier to do them in separate files and start mged multiple times
for each of them. |
| 18:47.07 |
elena |
but I'm
wondering if it would be more efficient to have one big script
(especially for big db) |
| 18:47.41 |
``Erik |
um, the prep
routine can take several minutes for large geometry |
| 18:47.57 |
``Erik |
and I'm using
an 8 core 3ghz machine with 16g ram, it's no slouch |
| 18:48.05 |
elena |
ok. so it
would make a big difference. |
| 18:48.17 |
elena |
then i'll try
to go with the all in one script. |
| 18:48.19 |
elena |
thank
you. |
| 18:48.24 |
``Erik |
prep can be
brutal... starseeker is in my office talking to
indianlarry |
| 18:48.31 |
``Erik |
I can throw
something at him if you'd like |
| 18:48.45 |
elena |
no. you're
answer is enough. |
| 18:48.54 |
``Erik |
<-- has
cans of soup, staplers, computers, etc... they'll get his attention
when on ballistic trajectories |
| 18:49.07 |
elena |
:) |
| 18:49.24 |
``Erik |
unix manuals,
those're nice and hefty |
| 18:50.33 |
elena |
did you have
lunch? |
| 18:52.18 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 18:52.47 |
``Erik |
ja, dol sot
bi bim bop at the korean restaurant |
| 18:53.54 |
elena |
delicious. i
must have had that, too, when in seoul, but i only remember "...
kim bap" |
| 18:54.29 |
``Erik |
sizzling hot
cast iron bowl, rice, mixed vegetables, some beef and a poached
egg |
| 18:54.33 |
``Erik |
good
stuff |
| 18:54.49 |
``Erik |
load it up
with pepper paste, stir it up, ... |
| 18:55.03 |
elena |
:( |
| 18:55.14 |
elena |
there is no
korean restaurant in romania. |
| 18:55.41 |
elena |
only
chinesse. |
| 18:56.10 |
``Erik |
unfortunate,
at least you can hop the train to other nations easily to enjoy
variety :) |
| 18:56.48 |
elena |
ya. |
| 18:57.00 |
``Erik |
(most the
food here in the US has been so "americanized", it'd be
unrecognizable to visitors) |
| 18:57.49 |
``Erik |
there was a
nice chinese place where I lived in missouri, but you had to
explicitely ask for it "chinese style" to get the good
stuff |
| 18:58.27 |
``Erik |
speaking a
little japanese helps a bit when I go to a teppan place, too
:) |
| 19:06.59 |
elena |
is there a
man page for mged commands? i need more info about tops than it's
in the Introduction_to_MGED.pdf |
| 19:07.16 |
elena |
i couldn't
find one. |
| 19:10.31 |
``Erik |
no, there's
an internal "help" command |
| 19:10.46 |
elena |
it's not very
verbose |
| 19:11.49 |
``Erik |
no, it's
no... I think d-lo was developing a command guide in some wiki
somewhere a while back |
| 19:21.13 |
CIA-32 |
BRL-CAD:
03ebautu * r35111
10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/7.14/raytrace.txt:
Fixed tops enumeration |
| 19:21.33 |
CIA-32 |
BRL-CAD:
03erikgreenwald * r35112
10/brlcad/trunk/src/adrt/master/dispatcher.c: redaeh gnissim
dda |
| 19:27.19 |
CIA-32 |
BRL-CAD:
03ebautu * r35113
10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/7.14/metadata.txt:
Moved to new script output format to support multiline
metadata |
| 19:30.19 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 19:36.29 |
jdoliner |
indianlarry
are you around? |
| 19:39.58 |
``Erik |
he is pretty
round, yes |
| 19:40.10 |
indianlarry |
hey
joe |
| 19:40.48 |
indianlarry |
jdoliner: you
mentioned having some questions? |
| 19:42.33 |
jdoliner |
yes |
| 19:43.04 |
jdoliner |
I spent
yesterday reading over a number of papers and following wandering
down citation rabit holes |
| 19:43.04 |
``Erik |
... |
| 19:43.34 |
jdoliner |
looking at
the different implementations options |
| 19:44.28 |
jdoliner |
1 option is a
purely algebraic solution |
| 19:44.29 |
indianlarry |
k |
| 19:44.39 |
jdoliner |
which would
be really powerful |
| 19:44.56 |
jdoliner |
but requires
a lot of tricky algorithmics to get right |
| 19:45.32 |
jdoliner |
so if I took
that option I think my best bet would be using some foreign
abstract algebra library as a base |
| 19:46.14 |
jdoliner |
the other
option which I'm leaning toward more and more is a marching
implementation |
| 19:46.15 |
indianlarry |
i thought
intersections between to order 3 surfaces could lead to an order
200 intersect curve? algebraically speaking |
| 19:46.39 |
jdoliner |
yeah
sometimes they can |
| 19:47.27 |
jdoliner |
the
literature suggest some methods to lose a bit of accuracy to
drastically reduce that number |
| 19:48.25 |
jdoliner |
but i'm not
sure exactly how good it is at this point |
| 19:48.25 |
indianlarry |
we have
definitely run into trims that have cracks due to the
error |
| 19:48.47 |
jdoliner |
however I
spoke with brlcad earlier and we both liked the idea of the
marching algorithm |
| 19:49.11 |
indianlarry |
would be nice
to quantify/control the error |
| 19:49.18 |
``Erik |
those can
lead to issues with the sampling gaps |
| 19:49.22 |
indianlarry |
yea, need to
control the error there as well |
| 19:49.26 |
``Erik |
the recent
metaball noise was trying to get that in check |
| 19:50.13 |
jdoliner |
in favor of
that idea is that it could conceivably be made to share code with
librt/primitves/brep |
| 19:50.27 |
indianlarry |
be
nice |
| 19:50.44 |
jdoliner |
yeah
agreed |
| 19:50.54 |
``Erik |
hoist common
stuff into libbn perhaps? |
| 19:51.17 |
indianlarry |
may need to
do some pullbacks on face trims to get better results |
| 19:51.24 |
indianlarry |
in brep that
is |
| 19:52.01 |
CIA-32 |
BRL-CAD:
03bob1961 * r35114 10/brlcad/trunk/ (4 files in 4 dirs): Added a -f
option to libtclcad's go_copy and libged's ged_dbcopy. Modified
archer to use "cp" instead of a "get" followed by a "put" or
"adjust" when copying between the ledger and the
database. |
| 19:52.30 |
indianlarry |
i don't have
a problem if it ends up in libbn but okay to keep in
librt/primitves/brep since considered work-in-progress |
| 19:52.49 |
indianlarry |
plus it's
getting cleaned up as starseeker mentioned |
| 19:52.51 |
jdoliner |
yeah, I'm not
sure if I could abstract it out to libbn without taking some of the
openNurbs with it |
| 19:54.18 |
indianlarry |
we currently
rely on the Ev functions in openNurbs |
| 19:54.19 |
jdoliner |
okay so it a
marching approach seems best at this point |
| 19:54.48 |
indianlarry |
if you have
any reference shoot them at me and i'll take a look |
| 19:55.14 |
jdoliner |
k I'll
forward you the papers I've compiled |
| 19:55.24 |
indianlarry |
thanks
joe |
| 20:11.48 |
``Erik |
damnit, is
all the creviche gone? O.o |
| 20:12.43 |
brlcad |
there's help
for mged commands on the wiki or in the mged-internal
help |
| 20:14.09 |
``Erik |
hm, no
sailboats in this 'bargainer', poop |
| 20:15.08 |
brlcad |
if pullbacks
on face trims are needed by the solver to give better results,
could make that some sort of "hinting callback" to the libbn solver
routine |
| 20:15.26 |
brlcad |
so it could
remain generalized, but allow customizations specific to different
uses |
| 20:16.00 |
brlcad |
``Erik: pfft,
jeez, yes gone :) |
| 20:16.11 |
brlcad |
you missed
the dozen people in the hallway for an hour? :) |
| 20:16.26 |
``Erik |
bastages. I'm
gonna barge into your domicile next time you make some to steal a
portion O.o |
| 20:16.30 |
``Erik |
yeah |
| 20:16.36 |
``Erik |
tucked back
in my corner here |
| 20:17.32 |
brlcad |
i'm already
craving some ceviche de corvina, have to hunt for more sea
bass |
| 20:18.08 |
``Erik |
specialty
grocery store? actual zomfg fishmonger? |
| 20:21.24 |
``Erik |
decides to hold off on the boat, trailer and truck in favor
of seeing how a bicycle works out for him |
| 20:21.58 |
Ralith |
hunts some brlcad |
| 20:23.20 |
brlcad |
there's a
whole foods near my house, they tend to carry top shelf |
| 20:37.56 |
CIA-32 |
BRL-CAD:
03n_reed * r35115 10/brlcad/trunk/ (13 files in 4 dirs): initial
work on a prototype ray tracing X11/OpenGL display manager
(dm-rtgl) |
| 20:39.44 |
brlcad |
tis teh
shizzle |
| 20:40.29 |
Ralith |
brlcad: hey
so |
| 20:40.32 |
Ralith |
got a
minute? |
| 20:40.40 |
brlcad |
never,
sup |
| 20:41.11 |
Ralith |
how bout I
backburner this whole Qt-embedded-in-OpenGL thing? |
| 20:41.15 |
``Erik |
ngnngnggg
stupid docbook crap |
| 20:41.16 |
Ralith |
I feel like
I'm getting nowhere |
| 20:41.28 |
Ralith |
and the
overall goals don't strictly depend on that |
| 20:41.30 |
brlcad |
Ralith:
what's your alternative goal then? |
| 20:41.37 |
Ralith |
move on with
the rest of what I planned to work on |
| 20:41.38 |
brlcad |
that's kinda
the most important part of the project :) |
| 20:41.48 |
Ralith |
it
is? |
| 20:41.53 |
Ralith |
I didn't
realise that at all |
| 20:42.04 |
brlcad |
it sets the
application framework |
| 20:42.14 |
Ralith |
was thinking
I'd bring the Qt UI back to where mafm had RBGui, then extend it
etc. as described in the original proposal |
| 20:42.47 |
Ralith |
I'm pretty
sure that that work can be easily shoved into OpenGL once that bit
gets worked out |
| 20:43.19 |
Ralith |
I'm not
suggesting abandoning it, but I suspect that I can make just as
much (generally minimal) progress on it while *also* making more
visible progress in the other areas. |
| 20:43.53 |
brlcad |
not
following, you mean implement customization of the UI widgets,
mimicking what rbgui is presently doing? |
| 20:44.17 |
Ralith |
I don't
imagine it will involve a great deal of customization of the
widgets themselves per se |
| 20:44.39 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 20:44.40 |
Ralith |
but putting
together an interface at least equivalent to the current RBGui
interface, yes |
| 20:45.37 |
brlcad |
sans the
opengl context? |
| 20:46.04 |
brlcad |
can't wire up
the controls without the 3d context working.. :) |
| 20:46.07 |
Ralith |
it's still
easy enough to drop in an OpenGL context containing Ogre, so not
exactly. |
| 20:46.15 |
Ralith |
just sans Qt
being actually rendered as OpenGL. |
| 20:46.57 |
Ralith |
which means
less nifty but not immediately functionality-relevant stuff like
transparency |
| 20:46.58 |
brlcad |
what about
rendering a qt widget on top of an opengl widget? |
| 20:47.04 |
Ralith |
yeah,
basically that |
| 20:47.10 |
brlcad |
have you
tried that? |
| 20:47.19 |
Ralith |
that's... not
what we were going for, is it? |
| 20:47.22 |
Ralith |
O.o |
| 20:47.30 |
Ralith |
'cuz *that*
should work perfectly fine. |
| 20:47.40 |
brlcad |
that's very
much related |
| 20:47.50 |
Ralith |
I can do
that, easy |
| 20:47.53 |
Ralith |
shall
I? |
| 20:47.56 |
brlcad |
sure |
| 20:47.59 |
Ralith |
yay
:D |
| 20:48.04 |
CIA-32 |
BRL-CAD:
03starseeker * r35116 10/brlcad/trunk/ (include/opennurbs_cleanup.h
src/librt/opennurbs_cleanup.cpp): More trimming tweaking, start
incorporating latest changes. |
| 20:48.13 |
brlcad |
does that
work with ogre rendering into the opengl context? |
| 20:48.18 |
Ralith |
oh
yeah |
| 20:48.19 |
brlcad |
if you can
show that, it's progress |
| 20:48.39 |
Ralith |
I got Ogre
embedded in Qt to work just about first try |
| 20:48.40 |
brlcad |
even if it's
a flat qt button painted directly over the 3d context |
| 20:48.44 |
Ralith |
the trick was
Qt in Ogre in Qt |
| 20:49.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 20:49.14 |
brlcad |
qt in ogre in
qt sounds .. way too complex |
| 20:49.16 |
Ralith |
if we're just
drawing *over* the context, then, while not as cool, there's really
no problem. |
| 20:49.25 |
Ralith |
brlcad:
actually, it *should* have been pretty simple. |
| 20:49.36 |
Ralith |
Qt has
support for Qt-in-OpenGL-in-Qt out of the box |
| 20:49.40 |
``Erik |
it's qt's all
the way down! |
| 20:49.48 |
brlcad |
the issue is
really whether you can override the drawing routine for a button,
for example, so that you can have a button alpha-blended against
the 3d |
| 20:49.56 |
Ralith |
that's what
that modelviewer demo did |
| 20:50.12 |
Ralith |
brlcad: don't
think that can be done without actually rendering *into* the
context |
| 20:50.14 |
starseeker |
I thought
drawing over the opengl window requires that the window manager/OS
cooperate |
| 20:50.17 |
Ralith |
(or a WM that
composits) |
| 20:50.38 |
Ralith |
starseeker:
start up a glxgears instance, drag a term over it. Works fine,
no? |
| 20:50.57 |
starseeker |
on X,
sure |
| 20:51.02 |
Ralith |
not
elsewhere? |
| 20:51.14 |
starseeker |
dunno - we're
looking to work on OSX and Windows too |
| 20:51.20 |
brlcad |
my
understanding for the snippets I saw was that you'd override the Qt
render method for a given widget, making it issue opengl draw
commands instead of whatever it usually does |
| 20:51.30 |
starseeker |
that was one
of the things that made the OpenGL integration so
promising |
| 20:51.30 |
brlcad |
even if just
to draw an alpha-blended texture |
| 20:51.35 |
Ralith |
brlcad: oh,
no, not at all |
| 20:51.39 |
Ralith |
Qt already
*has* the code to do that |
| 20:52.03 |
Ralith |
thought,
perhaps it could be rewritten in a more Ogre-friendly
way. |
| 20:52.05 |
brlcad |
then what's
the problem? :) |
| 20:52.12 |
Ralith |
it doesn't
work when Ogre's using the context. |
| 20:52.20 |
Ralith |
for some
reason. |
| 20:52.30 |
brlcad |
that sounds
incredibly vague :) |
| 20:52.36 |
Ralith |
now you know
how I feel :| |
| 20:52.44 |
brlcad |
I'm pretty
sure that's what I saw in the examples I reviewed :) |
| 20:52.55 |
Ralith |
not the
modelviewer, certainly |
| 20:53.06 |
brlcad |
don't know
that example, these were running apps |
| 20:53.13 |
Ralith |
so was
that |
| 20:53.16 |
Ralith |
very neat
demo |
| 20:53.26 |
Ralith |
big green
spinny Qt logo on a blue background |
| 20:53.34 |
Ralith |
transparent
Qt dialogs overlayed |
| 20:53.38 |
brlcad |
have you run
stellarium before? |
| 20:53.41 |
Ralith |
like I said,
Qt 4.5 comes out of the box with support for rendering widgets into
an OpenGL context, and doing so in a Qt window is the logical way
to do it. |
| 20:53.47 |
Ralith |
hm,
yeah |
| 20:53.55 |
Ralith |
I keep
forgetting to take a look at that. I'll do that. |
| 20:54.00 |
Ralith |
checks to see if he checked it out
previously |
| 20:54.23 |
brlcad |
their
approach should be nearly identical and iirc, it was a simple
override |
| 20:54.23 |
Ralith |
considering
that they've been doing it since long before 4.5 |
| 20:55.00 |
Ralith |
that'll take
a good bit more work than rendering *on* the widget, but I'll try
for it, then. |
| 20:55.39 |
brlcad |
you say you
got ogre rendering to a qt-created opengl context, yes? |
| 20:55.43 |
Ralith |
yup |
| 20:55.46 |
Ralith |
at least, I
think so. |
| 20:55.57 |
Ralith |
the
background color's rendered properly and Ogre's internally
consistent |
| 20:56.01 |
brlcad |
and did you
try just splatting a qt button right on top of that
context? |
| 20:56.07 |
Ralith |
splatting? |
| 20:56.15 |
starseeker |
and the issue
was that once Ogre DID render to that context, Qt
couldn't? |
| 20:56.21 |
Ralith |
starseeker:
yes, exactly. |
| 20:56.27 |
Ralith |
on a
frame-by-frame basis, no less |
| 20:56.32 |
brlcad |
one big
opengl window .. put a qt window in the middle of it |
| 20:56.34 |
Ralith |
if I disabled
Ogre for a frame, Qt would render happily. |
| 20:56.40 |
brlcad |
bah, s/qt
window/qt button/ |
| 20:56.54 |
Ralith |
brlcad: do
you mean in or out of the OpenGL context? |
| 20:57.07 |
brlcad |
neither and
both |
| 20:57.09 |
brlcad |
on top
of |
| 20:57.14 |
Ralith |
:| |
| 20:57.18 |
Ralith |
then you've
lost me |
| 20:57.36 |
Ralith |
logically
rendered as OpenGL or not>? |
| 20:58.46 |
brlcad |
I don't care
what it does on the backend, I'm talking about the end result --
one big window with ogre able to draw a 3d scene into it, and the
ability to have a button in that same window (drawn on top of the
3d context) |
| 20:59.00 |
brlcad |
not next to
it |
| 20:59.09 |
brlcad |
don't care
how qt draws its button |
| 20:59.19 |
brlcad |
can it show
them both at the same time is the issue |
| 20:59.52 |
Ralith |
then we're
back in easy territory |
| 21:00.01 |
Ralith |
I'm pretty
sure Qt can do that trivially |
| 21:00.05 |
Ralith |
bears
testing, of course |
| 21:00.09 |
brlcad |
show me
:) |
| 21:00.17 |
Ralith |
'kay |
| 21:00.31 |
Ralith |
this will
almost certainly *not* permit things like transparent
widgets/windows |
| 21:00.46 |
brlcad |
because if
that works, then it really should be a matter of overriding the
widget's draw routine |
| 21:00.52 |
Ralith |
and may or
may not give trouble if we want to display other 3D content in
windows, I'm not sure what multiple GL context hw support is
like |
| 21:00.57 |
Ralith |
er... |
| 21:01.01 |
Ralith |
I don't see
how the two approaches are related. |
| 21:01.11 |
brlcad |
it's a matter
of compositing |
| 21:01.15 |
brlcad |
whether qt is
doing it or not |
| 21:01.37 |
brlcad |
it has to
have some minimal sort-order compositing in order to draw a button
on top of a 3d context |
| 21:01.50 |
brlcad |
if it does,
then we're probably good |
| 21:02.35 |
Ralith |
is confused but can write the test |
| 21:03.04 |
brlcad |
I'm thinking
you're not getting what is meant by overriding the widget's draw
routine ? |
| 21:03.23 |
brlcad |
dno't worry
about that bit for now -- if you can show a button on an ogre
context, that'll be progress |
| 21:03.34 |
brlcad |
s/on/on top
of/ |
| 21:04.31 |
Ralith |
I assume you
mean overriding it such that it draws into OpenGL
directly |
| 21:05.08 |
brlcad |
sure, or
printf's to console, whatever you want -- that's the beauty of an
override :) |
| 21:05.36 |
Ralith |
I suspect
I'll end up reimplementing QGraphicsView only less
broken |
| 21:06.10 |
brlcad |
try the
simple demo first, then take a look at stellarium's approach (or
vice versa) |
| 21:39.04 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-11-1.dclient.hispeed.ch) |
| 21:57.09 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:58.52 |
starseeker |
desperately hopes this news of the Apollo 11 tapes is the
real deal |
| 21:59.17 |
starseeker |
if they post
high quality digital conversions online, I know I'll be grabbing
the lot of them |
| 22:24.40 |
CIA-32 |
BRL-CAD:
03r_weiss * r35117 10/brlcad/trunk/src/libged/make_pnts.c: more
cleanup, improved error checking and messages |
| 22:26.23 |
Ralith |
starseeker:
design data? |
| 22:26.24 |
Ralith |
or
what? |
| 22:27.01 |
starseeker |
the feeds
you've seen of the original moon landing are apparently of lower
quality than was originally recorded |
| 22:27.35 |
starseeker |
I.e., it was
downgraded by pointing a video camera at a monitor |
| 22:28.04 |
starseeker |
there are
indications they have found some of the original recordings that
didn't get routed through a TV camera :-) |
| 22:28.32 |
Ralith |
oo,
cool |
| 22:29.13 |
archivist |
getting the
old recorders working is the fun part |
| 22:29.23 |
starseeker |
considering
that it easily ranks as one of the greatest moments in the history
of humanity, I would think getting the highest recording quality
available preserved is important |
| 22:30.47 |
starseeker |
apparently
for a while the non-degraded tapes were lost |
| 22:31.00 |
starseeker |
incredible,
really |
| 22:32.03 |
archivist |
http://www.wired.com/wired/archive/15.01/nasa.html?pg=2 |
| 22:32.50 |
starseeker |
Of course,
they wanted to use the Messel Oil Shale Pit as a trash dump,
despite it containing what may be the highest quality fossils ever
discovered... |
| 22:32.55 |
archivist |
I saw pics of
the recorder some months ago |
| 22:34.13 |
``Erik |
huh, richard
committed without anyone harrassing him O.o (I imagine he's pissed
that I mucked in his code) |
| 22:34.21 |
``Erik |
or, rather,
without me harrassing him |
| 22:35.12 |
starseeker |
this fossil
still makes me stare in wonder:
http://en.wikipedia.org/wiki/File:Prachtkäfer_aus_der_Grube_Messel.JPG |
| 22:38.12 |
starseeker |
or this one:
http://www.paleontology.uni-bonn.de/wedmann%20english_version.htm |
| 22:39.33 |
starseeker |
50 million
years, and we get to see it. Incredible |
| 22:48.33 |
CIA-32 |
BRL-CAD:
03r_weiss * r35118 10/brlcad/trunk/src/libged/make_pnts.c: small
data type fix |
| 22:59.45 |
CIA-32 |
BRL-CAD:
03starseeker * r35119 10/brlcad/trunk/src/librt/
(opennurbs_cleanup.cpp primitives/brep/brep_cleanup.cpp): Inching
closer to behavior of original curve tree build - still have a ways
to go, probably. |
| 23:02.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 23:57.27 |
*** join/#brlcad CIA-30
(n=CIA@208.69.182.149) |
| 23:58.02 |
``Erik |
starts looking through IOKit docs |
| 00:29.24 |
*** join/#brlcad CIA-30
(n=CIA@208.69.182.149) |
| 00:37.23 |
CIA-30 |
BRL-CAD:
03starseeker * r35120 10/brlcad/trunk/ (include/opennurbs_cleanup.h
src/librt/opennurbs_cleanup.cpp): More CurveTree building
tweaks |
| 00:42.17 |
CIA-30 |
BRL-CAD:
03starseeker * r35121
10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Er - don't need
call to isLinear in the if condition that exists for the Linear
cases... |
| 00:54.49 |
``Erik |
awesome, an
accelerated emacs course:
xslt.2:${PORTSDIR}/textproc/libxslt |
| 00:54.52 |
``Erik |
grrr |
| 00:55.36 |
``Erik |
http://edward.oconnor.cx/2009/07/learn-emacs-in-ten-years |
| 00:55.37 |
``Erik |
http://edward.oconnor.cx/2009/07/learn-emacs-in-ten-years |
| 00:55.54 |
``Erik |
fuckin' A, my
X11.app isn't talking to the system clipboard quite right anymore
:// |
| 01:47.04 |
CIA-30 |
BRL-CAD:
03n_reed * r35122 10/brlcad/trunk/src/ (libdm/dm-rtgl.c
mged/Makefile.am): fixed mged dm-rtgl bus error on exit |
| 02:08.54 |
starseeker |
hmm - still
some difference in how the surface tree is being built |
| 02:08.57 |
starseeker |
arrrrgh |
| 02:25.36 |
CIA-30 |
BRL-CAD:
03starseeker * r35123 10/brlcad/trunk/ (include/opennurbs_cleanup.h
src/librt/opennurbs_cleanup.cpp): (log message trimmed) |
| 02:25.39 |
CIA-30 |
BRL-CAD: Ah.
Need to subdivide even flat nurbs surfaces in order to assign small
subsets |
| 02:25.41 |
CIA-30 |
BRL-CAD: of
the trimming curves to small areas of the nurbs surface for
evaluation |
| 02:25.43 |
CIA-30 |
BRL-CAD:
purposes. I wonder, would it be 'cleaner', in cases like this, to
do some sort |
| 02:25.47 |
CIA-30 |
BRL-CAD: of
test of points against the curve tree? i.e. for a uv point, if
inside the uv |
| 02:25.49 |
CIA-30 |
BRL-CAD:
bounds of a node, find subnodes that it is inside of, repeat until
leaf node(s) |
| 02:25.51 |
CIA-30 |
BRL-CAD: are
found, then work on the leaf nodes? Probably more expensive for a
trimming |
| 04:42.17 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-60-113.phnx.qwest.net) |
| 05:34.37 |
*** join/#brlcad stevegt_1
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 07:45.58 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 08:15.21 |
Ralith |
woo |
| 08:15.27 |
Ralith |
QDialog says
hello :D |
| 08:15.36 |
Ralith |
still have to
work out why ogre seems to be misaligned though |
| 08:15.51 |
Ralith |
er,
wait |
| 08:16.01 |
Ralith |
that's....
funny |
| 08:18.05 |
CIA-30 |
BRL-CAD:
03ralith * r35124 10/rt^3/trunk/src/g3d/ (6 files): "Naive"
approach to the Ogre/Qt conflict: Added the test widget as a child
of the OgreGLWidget. Test widget ends up as a separate
window. |
| 08:22.50 |
Ralith |
my
mistake: |
| 08:22.51 |
Ralith |
01:22:59 <
HuHa> Ralith: the docs explicity say: "QDialog... uses the
parent widget slightly differently from other classes in Qt. A
dialog is always a top-level widget, ..." |
| 08:25.09 |
CIA-30 |
BRL-CAD:
03ralith * r35125 10/rt^3/trunk/src/g3d/ogretest.cxx: Tested with a
QPushButton which, unlike QDialog, is *not* documented as "always a
top-level widget," and which allegedly should not need ->show()
to become visible. No luck yet. |
| 08:30.36 |
CIA-30 |
BRL-CAD:
03ralith * r35126 10/rt^3/trunk/src/g3d/ogretest.cxx: |
| 08:30.38 |
CIA-30 |
BRL-CAD:
Working pushbutton overlayed! Something about manually setting the
size of the OgreGLWidget with ->resize(1024, 768); threw it off;
my |
| 08:30.41 |
CIA-30 |
BRL-CAD:
guess is that my (tiling) wm's enforced resize produced a layout
that resulted in the widget being offscreen. It may be worth
testing |
| 08:30.44 |
CIA-30 |
BRL-CAD:
previously failed options with said resize call
removed. |
| 08:30.46 |
Ralith |
brlcad: we
have success! |
| 08:30.48 |
Ralith |
of a
sort. |
| 08:31.01 |
Ralith |
should work
well enough to move on, certainly |
| 08:34.42 |
Ralith |
I could
really do with some testing from others, btw |
| 08:34.53 |
Ralith |
I want to
find out whether this weird ogre misalignment is a side effect of
my tiling wm or what |
| 08:46.18 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 08:47.56 |
Ralith |
logs with excessively nested bullet points |
| 08:48.00 |
CIA-30 |
BRL-CAD:
03Ralith 07http://brlcad.org *
r1571 10/wiki/User:Ralith: Logs for 2008-07-12 and 2008-07-14. We
now have usable Qt widget overlaying! |
| 08:49.33 |
Ralith |
brlcad: let
me know if you want me to continue to play with alternative
approaches, especially considering the implications of discoveries
relating to QWidget::show(), or whether I should just dive ahead
into building a useful GUI. |
| 08:52.27 |
brlcad |
insane
timing, love it but have to read/respond later today :) |
| 08:52.43 |
Ralith |
'kay
:) |
| 08:52.45 |
Ralith |
night |
| 09:02.40 |
CIA-30 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1572 10/wiki/More_Changelog: July 13-14 |
| 09:43.45 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:45.19 |
*** join/#brlcad LarsG
(n=lars@137.132.207.11) |
| 09:45.22 |
*** part/#brlcad LarsG
(n=lars@137.132.207.11) |
| 10:11.52 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:13.36 |
d-lo |
Morning
all! |
| 10:14.12 |
d-lo |
Ralith:
Grats :) |
| 11:05.53 |
CIA-30 |
BRL-CAD:
03ebautu * r35127
10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.module
scripts/7.14/metadata.txt): Improved php-mged interface. Added
feature to retrieve file list. |
| 11:20.07 |
*** join/#brlcad mafm (n=mafm@83.42.152.74) |
| 11:38.50 |
CIA-30 |
BRL-CAD:
03jdoliner * r35128 10/brlcad/trunk/ (include/bn.h
src/libbn/multipoly.c): added some nuts and bolts bivariate
polynomial manipulation functiuons |
| 11:42.24 |
CIA-30 |
BRL-CAD:
03davidloman * r35129 10/rt^3/trunk/ (19 files in 17 dirs): CMake
build fixes, cleanup, WS removal and style consistancy
changes. |
| 11:45.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 11:48.49 |
starseeker |
Ralith: so
this is not using the shared OpenGL context, correct? |
| 12:11.27 |
*** join/#brlcad stevegt_1
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) [NETSPLIT
VICTIM] |
| 12:11.27 |
*** join/#brlcad Axman6 (n=Axman6@61.69.25.81) [NETSPLIT
VICTIM] |
| 12:11.32 |
CIA-30 |
BRL-CAD:
03d_rossberg * r35130 10/brlcad/trunk/src/libged/ (dg_obj.c
editit.c edmater.c rt.c rtcheck.c): |
| 12:11.35 |
CIA-30 |
BRL-CAD: MSVC
does not provide all POSIX headers |
| 12:11.37 |
CIA-30 |
BRL-CAD:
handled this with the HAVE_~_H macros |
| 12:20.59 |
*** join/#brlcad jdoliner
(n=jdoliner@68.51.75.169) |
| 12:37.15 |
brlcad |
g'morning
jdoliner |
| 12:37.44 |
brlcad |
Ralith: yeah,
agree -- we should get a couple people to test things
out |
| 12:37.50 |
brlcad |
screenshot? |
| 12:38.03 |
d-lo |
hah! Pics or
it never happened :) |
| 12:38.34 |
CIA-30 |
BRL-CAD:
03davidloman * r35131 10/rt^3/trunk/ (78 files in 14 dirs): More
WS, header and Style consistancy fixes |
| 12:46.28 |
brlcad |
d-lo: curious
commit there.. |
| 12:46.42 |
d-lo |
How
so? |
| 12:47.49 |
brlcad |
aside from
the subtle change to the standard header, dropping the file
identifier, we moved away from using rcs variables a long while
back because they cause hell on branching and merging (and is
information contained within the vcs anyways) |
| 12:48.54 |
d-lo |
So you
recommend not using svn;keywords at all? |
| 12:50.36 |
brlcad |
within the
file, yeah, with a few exceptions (like build system files that use
revision stamping) |
| 12:51.29 |
d-lo |
*confused*
How else can the rcs variables be used, if not 'with in the file'
? |
| 12:51.49 |
brlcad |
the two main
issues are the technical one with it causing more grief with
conflict than time-savings gain conveying information; and a social
impact of tending towards territorial code if files include
authorship |
| 12:52.24 |
brlcad |
within source
files, there are other files they work well in where the conflict
potential is very low |
| 12:53.22 |
d-lo |
ah, okay.
'Territorial code' ? is that really a problem within the brlcad dev
community? |
| 12:53.59 |
brlcad |
that's a
problem with most devs, left unchecked, but even more so for 'new'
devs, which is the main reason |
| 12:54.35 |
``Erik |
ralith:
pleased to be leaving breadcrumb trail in case anyone else picks up
your "good enough" to make it "great" :D |
| 12:54.55 |
d-lo |
Okay. I
honestly don't care what is in the headers, so long as its
consistant file to file. |
| 12:55.01 |
brlcad |
new
developers often won't touch a file that has an author associated
with it, kinda like a dog marking his territory for fear of
"changing their code" instead of treating it like project
code |
| 12:55.47 |
d-lo |
Except for
the F I L E N A M E at the top. that is a pita. |
| 12:55.56 |
brlcad |
there's a
great interview with brian fitzpatrick (subversion developer,
google dev, among other notabilities) and one of his cohorts on
this phenomenon |
| 12:56.12 |
brlcad |
pita
howso? |
| 12:56.19 |
brlcad |
should be
autogenerated |
| 12:56.29 |
brlcad |
that's what
the template script is for |
| 12:56.49 |
``Erik |
or some vim
or emacs fu if you want to copy and rework a file |
| 12:56.58 |
``Erik |
tends to do it by hand, though :/ |
| 12:57.15 |
d-lo |
going through
and retro fitting a bunch of various stuff from a bunch of
different devs. |
| 12:58.20 |
brlcad |
there's
actualy an intent legal motivation (however strong) to uniquely
identify each file before the project, in order to imply it is an
individual work that is part of a larger collective
work |
| 12:58.57 |
brlcad |
write-up from
the FSF and groklaw regarding that issue, iirc |
| 12:59.34 |
brlcad |
there was a
reason for each item in the template ;) |
| 13:00.02 |
d-lo |
And thats all
well and good. Still a pita ;) |
| 13:00.23 |
brlcad |
the header.sh
and footer.sh scripts can be run individually on single or groups
of files to correct them |
| 13:01.29 |
brlcad |
'find' is a
great command to master if you haven't already ;) |
| 13:01.56 |
d-lo |
yes, but
thats not the pita i am talking about |
| 13:02.07 |
brlcad |
and "perl -pi
-e 'EXPRESSION' ..." or variants using sed/awk |
| 13:03.33 |
brlcad |
should be a
trivial mod to the header script to detect an existing header and
'make it conform' like footer.sh does |
| 13:04.23 |
brlcad |
forget what
the current behavior is, whether to detect and abort, or detect and
prepend |
| 13:05.09 |
brlcad |
think it's a
detect and abort if it finds the legal clause, otherwise prepends
and treats as a comment header |
| 13:06.08 |
d-lo |
kk, thanks
for the heads up on the footer/header scripts. |
| 13:08.37 |
brlcad |
not at
concerned about that as the rcs vars, more because of their long
term impact |
| 13:08.49 |
brlcad |
because
they're pretty easy to fix |
| 13:12.22 |
d-lo |
the '@file'
part of the header... is that a DocBook thing? |
| 13:12.54 |
*** join/#brlcad docelic
(n=docelic@78.134.202.66) |
| 13:14.10 |
d-lo |
err, Doxygen
i mean. |
| 13:16.42 |
d-lo |
brlcad:
Network guys are looking at the Switch UPS. Anything you need me
to tell them? |
| 13:16.48 |
``Erik |
brlcad: have
you looked at the swiss cheese vrml issue? |
| 13:17.11 |
``Erik |
switch ups
hasn't been an issue for us so far |
| 13:17.28 |
``Erik |
all our
machines drop before the switch *shrug* |
| 13:17.55 |
d-lo |
Well, 'They
said 'Sean said''... maybe you can talk to them :) |
| 13:20.21 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 13:35.04 |
CIA-30 |
BRL-CAD:
03johnranderson * r35132
10/jbrlcad/trunk/src/org/brlcad/numerics/BoundingBox.java: Added
check for NaN in intersect method |
| 13:35.50 |
brlcad |
``Erik: the
switch for the networking shut off really quickly on the recent
outtages |
| 13:37.07 |
brlcad |
maybe some
anamoly, maybe surge, don't know -- either way it shut off faster
than any of the hosts and used to stay up for nearly an
hour |
| 13:37.38 |
brlcad |
and no, i've
not looked at the vrml issue, but suspect it's needing to tweak
tolerancing with those really small holes |
| 13:38.26 |
CIA-30 |
BRL-CAD:
03davidloman * r35133 10/rt^3/trunk/ (164 files in 33 dirs):
Standardizing headers. |
| 13:51.19 |
*** join/#brlcad mafm_
(n=mafm@83.42.152.74) |
| 13:51.28 |
*** join/#brlcad samrose
(n=samrose@24.11.214.181) |
| 13:59.21 |
CIA-30 |
BRL-CAD:
03starseeker * r35134
10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: OK, now that we're
breaking down flat surfaces too, just call GetBVChildren
directly. |
| 14:02.47 |
CIA-30 |
BRL-CAD:
03davidloman * r35135 10/rt^3/trunk/src/GE/ (14 files in 3 dirs):
Missed some headers. Fixed some mangling. |
| 14:04.42 |
CIA-30 |
BRL-CAD:
03davidloman * r35136 10/rt^3/trunk/ (5 files in 2 dirs):
refactored CommunicationsManager to
AbstractPortalManager. |
| 14:21.53 |
CIA-30 |
BRL-CAD:
03davidloman * r35137 10/rt^3/trunk/ (4 files in 2 dirs): Stubs for
NetSockPortalManager (subclass of
AbstractPortalManager). |
| 14:39.41 |
``Erik |
he |
| 14:41.11 |
brlcad |
she |
| 14:43.31 |
d-lo |
we |
| 14:47.31 |
archivist |
they |
| 14:47.36 |
``Erik |
woops, heh,
d'no what I was typing that accidently went here O.o |
| 14:47.41 |
``Erik |
(fuckers) |
| 14:48.26 |
d-lo |
play |
| 14:49.53 |
CIA-30 |
BRL-CAD:
03johnranderson * r35138 10/jbrlcad/trunk/ (4 files in 3
dirs): |
| 14:49.56 |
CIA-30 |
BRL-CAD:
Minor mod to RegionInfo class to handle null "region_id"
attribute. |
| 14:49.58 |
CIA-30 |
BRL-CAD:
Added a simple test for RegionInfo. |
| 15:39.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 15:40.09 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 15:46.54 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) |
| 17:33.22 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 17:45.27 |
CIA-30 |
BRL-CAD:
03davidloman * r35139 10/rt^3/trunk/ (11 files in 4 dirs): Basic
implementation of NetSockPortal and
NetSockPortalManager. |
| 18:19.02 |
CIA-30 |
BRL-CAD:
03starseeker * r35140 10/brlcad/trunk/ (include/opennurbs_cleanup.h
src/librt/opennurbs_cleanup.cpp): Alright. Start trying to
PRECISELY duplicate the curvetree building of the old code, just to
have a working baseline. |
| 18:37.51 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 18:47.32 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 19:05.21 |
CIA-30 |
BRL-CAD:
03irpguardian * r35141
10/brlcad/trunk/src/proc-db/human.c: |
| 19:05.23 |
CIA-30 |
BRL-CAD:
Added 2 new functions, boundingBox and
boundingRectangle. |
| 19:05.25 |
CIA-30 |
BRL-CAD:
Bounding box makes rectangles with 1 value for width/depth, and
bounding rectangle makes rectangles with 2 values, one for depth,
one for width. |
| 19:05.28 |
CIA-30 |
BRL-CAD: They
currently make boxes using -b, but are not rotated or positioned
correctly yet. |
| 19:24.55 |
CIA-30 |
BRL-CAD:
03starseeker * r35142
10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Ah, blast it - +
where a - should be. |
| 19:27.41 |
CIA-30 |
BRL-CAD:
03starseeker * r35143
10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Few more tweaks to
the curve tree build - still have some definite problems somewhere
but getting closer |
| 19:53.05 |
CIA-30 |
BRL-CAD:
03starseeker * r35144
10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Whoops, - or, not
and for breakdown conditions |
| 20:05.06 |
CIA-30 |
BRL-CAD:
03starseeker * r35145 10/brlcad/trunk/ (include/opennurbs_cleanup.h
src/librt/opennurbs_cleanup.cpp): Put the bounding box adjustment
back in the Children call. |
| 20:28.30 |
CIA-30 |
BRL-CAD:
03starseeker * r35146 10/brlcad/trunk/ (include/opennurbs_cleanup.h
src/librt/opennurbs_cleanup.cpp): |
| 20:28.33 |
CIA-30 |
BRL-CAD: Hmm
- looks like the memory demands of this approach are a bit too high
- bump |
| 20:28.35 |
CIA-30 |
BRL-CAD: up
the BREP_SURF_SUB_FACTOR a bit, but will need to think about
another approach |
| 20:28.37 |
CIA-30 |
BRL-CAD: to
passing values - I'm guessing the big ON_3dPoint and ON_3dVector
arrays in |
| 20:28.39 |
CIA-30 |
BRL-CAD: each
node are to blame. |
| 20:36.16 |
*** part/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 20:40.03 |
``Erik |
O.O |
| 20:54.46 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 21:11.32 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-60-113.phnx.qwest.net) |
| 21:26.53 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 21:45.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 21:45.44 |
Ralith |
starseeker:
correct; it's being drawn 'on top' of the context, although still
in the same top level window. Shared context may still be
perfectly feasible though; it looks like a few other calls which I
only just now twiddled accidentally and/or on a hunch were
unexpected dealbreakers. |
| 21:53.16 |
Ralith |
brlcad:
probably easier to build it yourself than to wait for a screenshot,
but okay |
| 22:13.05 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-60-113.phnx.qwest.net) |
| 22:28.20 |
``Erik |
hm |
| 22:40.40 |
Ralith |
I could
*really* do with someone else testing this, btw |
| 22:41.19 |
Ralith |
brlcad:
http://imgur.com/TSMHY.png |
| 22:41.37 |
Ralith |
don't mind
the outlined black box in the middle, that's from my wm |
| 22:52.10 |
brlcad |
so is the
entire black area an opengl context? |
| 22:53.02 |
brlcad |
ah, I see
your reply to starseeker .. cool |
| 22:53.16 |
brlcad |
then that's
progress! |
| 22:53.44 |
brlcad |
got to speak about brl-cad briefly during the FLOSS weekly
podcast interview |
| 22:53.55 |
``Erik |
neat |
| 22:54.19 |
brlcad |
not one of my
best talks, by far |
| 22:55.08 |
brlcad |
kinda
frustrating, ill-timed to prepare (had all of 30 minutes or so
including mic checking) |
| 22:55.29 |
brlcad |
but nice
plugs in there for brl-cad and bzflag, just didn't get to say much
of the cool stuff |
| 22:55.35 |
``Erik |
erm, why
didn't they give ya more notice and shit? |
| 22:55.52 |
brlcad |
there was
more notice, *I* was ill-prepared |
| 22:55.57 |
``Erik |
last minute
replacement type deal? |
| 22:55.58 |
``Erik |
ahhh |
| 22:56.00 |
``Erik |
hah |
| 22:56.02 |
``Erik |
you suck
:D |
| 22:56.10 |
brlcad |
timing was
conflicting to prepare |
| 22:56.45 |
``Erik |
but now it's
done and you can busy yourself migrating machines, right? :D
*duck* |
| 22:56.49 |
brlcad |
otherwise, it
was still just about a week's notice |
| 22:57.37 |
``Erik |
is very tempted to do some firewall fu, tweak the grant table
and see if he can get the old machines websites using the new
machines rdbms |
| 22:57.40 |
brlcad |
now I need
food and a nap .. all i've had today are two egg rolls and a glass
of scotch |
| 22:57.48 |
brlcad |
and 3 hours
sleep |
| 22:58.03 |
``Erik |
or mebbe
sneak an ssh tunnel across |
| 22:59.16 |
``Erik |
*shrug* |
| 23:00.33 |
Ralith |
brlcad: the
entire black area is indeed the GL context. I'm not sure why the
dark grey area (Ogre's configured background color) is only
partial; I'd like it if someone with a normal WM could build and
test it. |
| 23:01.10 |
``Erik |
how normal is
a normal wm? |
| 23:02.01 |
``Erik |
if you walk
me through it and promise you'll still respect me in the morning, I
can try it on my macbook |
| 23:04.57 |
Ralith |
heh |
| 23:05.00 |
Ralith |
I'm not sure
it'd work on OSX at all |
| 23:05.10 |
brlcad |
(Ralith: tell
him you will, use him, get your satisfaction, then leave him to the
curb) |
| 23:05.10 |
Ralith |
let alone how
to install Ogre and Qt there |
| 23:05.16 |
Ralith |
^^ |
| 23:05.26 |
brlcad |
it should
work just fine there |
| 23:05.26 |
Ralith |
worth a
try |
| 23:05.40 |
brlcad |
fully
supported OS for both those |
| 23:05.42 |
Ralith |
I'd hope so,
but I'm in no position to walk someone through |
| 23:05.47 |
Ralith |
goes googling |
| 23:05.59 |
brlcad |
sure you are,
"install this, install that, compile this .. " |
| 23:06.00 |
``Erik |
!!#!~@ |
| 23:06.02 |
Ralith |
``Erik: I
assume you've got all the usual dev tools? |
| 23:06.02 |
brlcad |
same you did
on linux |
| 23:06.03 |
``Erik |
I have
qt |
| 23:06.08 |
Ralith |
'kay |
| 23:06.09 |
``Erik |
in
/opt/local/ |
| 23:06.14 |
``Erik |
and yeah, a
full dev stack |
| 23:06.22 |
Ralith |
got
cmake? |
| 23:06.32 |
``Erik |
uhm, don't
think so, I have a DEV stack, not a wanker stack |
| 23:06.33 |
``Erik |
:D |
| 23:06.38 |
Ralith |
D: |
| 23:06.39 |
Ralith |
get
cmake |
| 23:06.56 |
``Erik |
yeah,
updating my ports |
| 23:07.44 |
``Erik |
oh, I did
install camke, my bad |
| 23:08.36 |
``Erik |
runs "cmake ." |
| 23:09.00 |
Ralith |
okay, which
bits broke? :D |
| 23:09.25 |
Ralith |
(there are no
sane defaults for OSX for almost any of the cmake package-finding
modules) |
| 23:09.31 |
Ralith |
(though if
your pkg-config is working that might not matter) |
| 23:11.36 |
``Erik |
http://pastebin.bzflag.bz/d7f9a4b6 |
| 23:12.50 |
Ralith |
hm, that's
odd |
| 23:13.03 |
Ralith |
that's the
one cmake module that I'm *not* in some way responsible
for. |
| 23:13.11 |
``Erik |
hehehe |
| 23:13.16 |
Ralith |
does
pkg-config find Qt? |
| 23:15.33 |
``Erik |
hm, my qt3
didn't seem to install the pc file |
| 23:15.59 |
``Erik |
rebuilds it |
| 23:16.38 |
``Erik |
oh, wait, no
it's, there heh, qt-mt |
| 23:17.13 |
Ralith |
qt3? |
| 23:17.13 |
Ralith |
O.o |
| 23:17.23 |
``Erik |
yeah, do you
require 4? |
| 23:17.47 |
``Erik |
(aqbanking
required qt3, ... *shrug*) |
| 23:18.40 |
Ralith |
er, I'm
pretty sure Qt4 is necessary, yeah |
| 23:18.44 |
``Erik |
<-- gtk
weenie |
| 23:18.55 |
``Erik |
does it
require a certain backend? I can do aqua or x11 |
| 23:19.02 |
Ralith |
I don't want
it to |
| 23:19.06 |
Ralith |
so let's try
aqua :D |
| 23:19.16 |
``Erik |
aight,
installing |
| 23:19.22 |
Ralith |
ty |
| 23:19.42 |
``Erik |
(source based
package management, this'll take a while) |
| 23:19.48 |
Ralith |
<3
binary |
| 23:20.14 |
``Erik |
I d'no, the
speed of installing isn't worth the versoin hell |
| 23:20.29 |
``Erik |
is in no hurry in his old age |
| 23:20.53 |
Ralith |
funnily
enough, last time I had version hell was on a source-based
system. |
| 23:21.28 |
``Erik |
when I did
debian systems, those went pretty well... yum/rpm based system are
crap |
| 23:21.49 |
``Erik |
on fbsd, you
get your choice, I always do source using portmanager |
| 23:21.56 |
Ralith |
well
sure |
| 23:22.00 |
Ralith |
rpm is
crap |
| 23:22.07 |
Ralith |
but that's
different from 'binaries are crap' :P |
| 23:23.35 |
``Erik |
hrm, I know I
put a debian/ in BRL-CAD, I think I was the one who put the rpm
spec file in, to |
| 23:23.46 |
``Erik |
don't really
remember and svn sucks :D |
| 23:28.22 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-60-113.phnx.qwest.net) |
| 23:36.19 |
CIA-30 |
BRL-CAD:
03ralith * r35147 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Let Ogre know when the Qt window
moves. |
| 00:17.40 |
starseeker |
brlcad: cool,
I hadn't heard of the FLOSS weekly |
| 00:17.52 |
Ralith |
plugging is
good. |
| 00:19.26 |
starseeker |
is curious if Ralith can write down his insights on what it
would take to do shared context Qt/Ogre |
| 00:19.35 |
starseeker |
still wants to do that, somehow or other |
| 00:19.39 |
Ralith |
starseeker:
did you already read the wiki entry? |
| 00:20.30 |
Ralith |
it wouldn't
be hard, really |
| 00:21.05 |
Ralith |
just take
things back to when the OgreScene approach was fully implemented,
and add hello->show(); after the rest of the widget test code,
and remove the resize call |
| 00:21.10 |
Ralith |
from
main |
| 00:21.21 |
Ralith |
and if that
doesn't work, try the same thing on the QtRenderListener
approach |
| 00:21.35 |
Ralith |
and if that
doesn't work, then I guess we're doing things this as best we can
right now. |
| 00:21.41 |
starseeker |
nods |
| 00:33.20 |
*** part/#brlcad jdoliner
(n=jdoliner@68.51.75.169) |
| 00:44.21 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 00:59.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 01:07.48 |
``Erik |
*pant* 80
pounds of empty boxes, paper bags, junkmail and newpapers prepped
for recycling day |
| 01:09.03 |
Ralith |
starseeker:
you gunna take a whack at it? |
| 01:57.42 |
*** join/#brlcad stevegt_
(n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 02:22.08 |
``Erik |
~seen
madant |
| 02:22.09 |
ibot |
madant
<i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last
seen on IRC in channel #brlcad, 12d 6h 15s ago, saying: 'nothing
more disastrous than non-cooperative softwares ;)'. |
| 02:22.26 |
``Erik |
~seen
homovulgaris |
| 02:22.27 |
ibot |
homovulgaris
<n=d@117.196.131.215> was last seen on IRC in channel
#brlcad, 338d 22h 29m 56s ago, saying: 'sean, on a scale of 1 to 10
how much trouble would one face when trying to make a .deb package
for brlcad ?'. |
| 02:22.37 |
``Erik |
hm. |
| 02:25.12 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 02:26.35 |
*** join/#brlcad LarsG
(n=lars@spnp207001.spnp.nus.edu.sg) |
| 02:26.44 |
*** part/#brlcad LarsG
(n=lars@spnp207001.spnp.nus.edu.sg) |
| 02:32.06 |
``Erik |
oscilloscope
spam, wow |
| 02:47.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 03:29.24 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 04:00.35 |
starseeker |
Ralith:
probably at some point |
| 04:10.34 |
Ralith |
cool
:) |
| 04:10.55 |
Ralith |
I'll try to
code everything else such that it'll be easy to transition if you
get it working |
| 05:44.42 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 07:17.16 |
*** join/#brlcad IriX64
(n=WarLock@70.52.228.154) |
| 08:38.29 |
CIA-30 |
BRL-CAD:
03d_rossberg * r35148
10/brlcad/trunk/src/libbn/multipoly.c: |
| 08:38.30 |
CIA-30 |
BRL-CAD:
replaced c99 idiom with c89 compatible one |
| 08:38.32 |
CIA-30 |
BRL-CAD: (all
declarations have to be on top of a block) |
| 09:21.26 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 09:53.51 |
*** join/#brlcad mafm (n=mafm@83.42.152.74) |
| 10:14.32 |
d-lo |
~seen
d-lo |
| 10:14.33 |
ibot |
d-lo
<n=claymore@bz.bzflag.bz> was last seen on IRC in channel
#brlcad, 1s ago, saying: '~seen d-lo'. |
| 10:14.40 |
d-lo |
muwahaha |
| 10:14.48 |
d-lo |
mernin
all! |
| 10:16.53 |
``Erik |
yaegh |
| 10:17.08 |
``Erik |
yargh,
even |
| 10:17.11 |
d-lo |
whoa. up
early or up late? |
| 10:17.42 |
``Erik |
earlyish |
| 10:18.08 |
``Erik |
been getting
up at five something the last few weeks |
| 10:18.51 |
d-lo |
nice. |
| 11:56.16 |
CIA-30 |
BRL-CAD:
03erikgreenwald * r35149 10/brlcad/trunk/src/rt/viewweight.c:
slightly more verbose logging if no density file is
handy. |
| 11:59.52 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 12:47.48 |
starseeker |
winces as he now begins to understand some of the design
considerations that may have driven the original design of
opennurbs_ext |
| 12:47.48 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 12:49.02 |
brlcad |
``Erik: you
have a pine session going nuts |
| 12:58.18 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:05.09 |
``Erik |
that machine
gets gimpy with locks :/ I can't even start mutt due to mail locks
going wonky |
| 13:07.30 |
``Erik |
lame,
sometimes we get .so.0 and sometimes .so.0.0 |
| 13:08.35 |
brlcad |
needs a
-version-info 19:1 LDFLAGS in the makeifle.amd |
| 13:10.43 |
``Erik |
hrm *shrug*
fbsd6 gives .so.0 and fbsd7+ gives .so.0.0 on our core libs,
supposedly |
| 13:11.12 |
``Erik |
ah, wait, no,
not our core |
| 13:11.15 |
brlcad |
hm, doesn't
sound right |
| 13:11.17 |
``Erik |
just the step
stuff |
| 13:11.21 |
brlcad |
yeah, the new
libs |
| 13:11.26 |
``Erik |
http://people.freebsd.org/~amdmi3/brlcad-7.14.8.log |
| 13:11.26 |
brlcad |
none of them
have -version-info |
| 13:12.53 |
brlcad |
with it, they
should list better and the packing list can be fixed |
| 13:13.39 |
``Erik |
yeah, editing
now |
| 13:13.54 |
``Erik |
but I blew
away my macports stuff, so I gotta get that up enough to
test |
| 13:15.43 |
brlcad |
probably
shouldn't be 19:1 |
| 13:16.18 |
brlcad |
don't know
what it "should" be without re-reading the libtool docs on
verison-info and checking up on step's version |
| 14:29.54 |
*** join/#brlcad BigAToo
(n=BigAToo@69.95.46.65) |
| 15:16.20 |
``Erik |
O.o http://www.alexa.com/siteinfo/brlcad.org |
| 15:18.47 |
louipc |
canada
wins |
| 15:18.58 |
louipc |
ok not
really |
| 15:20.42 |
starseeker |
brlcad: when
will they post your interview? |
| 15:39.12 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 15:43.46 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 15:51.13 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 15:51.13 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 15:51.13 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 15:56.44 |
*** join/#brlcad b0ef`
(n=b0ef@084202026157.customer.alfanett.no) |
| 15:58.39 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 15:58.39 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 16:22.00 |
CIA-30 |
BRL-CAD:
03starseeker * r35150 10/brlcad/trunk/include/opennurbs_ext.h:
BASegment isn't serving any purpose - remove it. |
| 16:33.38 |
CIA-30 |
BRL-CAD:
03starseeker * r35151 10/brlcad/trunk/include/opennurbs_ext.h:
Don't use intersectedBy for a SubcurveBANode |
| 16:44.51 |
CIA-30 |
BRL-CAD:
03starseeker * r35152 10/brlcad/trunk/include/opennurbs_ext.h: Add
a few comments, formatting. |
| 17:00.44 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 17:30.03 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 17:43.03 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:46.18 |
jdoliner |
indianlarry
you around? |
| 17:49.06 |
CIA-30 |
BRL-CAD:
03starseeker * r35153 10/brlcad/trunk/ (4 files in 3 dirs): Merge
BANode and SubcurveBANode classes into one BANode class |
| 18:00.03 |
``Erik |
jabs indianlarry with a pointy stick |
| 18:00.24 |
indianlarry |
hey joe
what's up |
| 18:04.10 |
CIA-30 |
BRL-CAD:
03starseeker * r35154 10/brlcad/trunk/include/opennurbs_ext.h: Move
CurveTree class before BVNode definitions |
| 18:06.26 |
jdoliner |
hi |
| 18:07.20 |
indianlarry |
hey
joe |
| 18:07.34 |
jdoliner |
and it seems
that even the numerical solutions use some algebraic
stuff |
| 18:08.57 |
jdoliner |
it seems
they're needed for finding basepoints |
| 18:09.17 |
indianlarry |
basepoints? |
| 18:09.30 |
jdoliner |
yeah what I
mean by that |
| 18:09.45 |
jdoliner |
is that if we
want to march along the intersection |
| 18:10.08 |
jdoliner |
we need a
place to start that's on the intersection |
| 18:10.11 |
jdoliner |
curve |
| 18:13.14 |
jdoliner |
So I've been
looking through a couple of CAS implementations to see how they
handle these sorts of things |
| 18:14.03 |
indianlarry |
what's in the
algebra, do they subdivide into near flat pieces like the
raytracing and then intersect planes for a starting
point? |
| 18:14.53 |
indianlarry |
could use
bounding box to see what parts of the surface a near |
| 18:15.01 |
indianlarry |
are
near |
| 18:15.56 |
jdoliner |
no they use
the high level stuff like Groebner bases to solve
things |
| 18:16.48 |
``Erik |
*yawn* |
| 18:17.12 |
CIA-30 |
BRL-CAD:
03erikgreenwald * r35155 10/brlcad/trunk/src/other/step/src/ (6
files in 6 dirs): chuck in some version info for installed
libraries. Mimick BRL-CAD lib version (for now). |
| 18:18.17 |
jdoliner |
describe to
me more how subdividing would work |
| 18:20.31 |
indianlarry |
for
raytracing we currently subdivide each surface (in UV) until it
is near flat |
| 18:22.21 |
indianlarry |
a 3D bounding
box is computed for each near flat surface and put into a surface
tree |
| 18:22.33 |
jdoliner |
okay |
| 18:22.52 |
indianlarry |
rays are
first cast against the bounding boxes |
| 18:23.53 |
indianlarry |
for bounding
boxes hit an iterative approach is used |
| 18:24.22 |
indianlarry |
two
intersecting/perp planes are used to represent the ray |
| 18:25.09 |
indianlarry |
and an
initial starting point in that sub-surfaces UV (possibly multiple
start points) |
| 18:28.49 |
indianlarry |
given two
bboxes from seperate surfaces overlap |
| 18:29.40 |
indianlarry |
use normals
of each subsurface to setup walking direction |
| 18:30.14 |
indianlarry |
adjust
normals as you walk |
| 18:33.09 |
jdoliner |
okay that
makes sense |
| 18:33.17 |
*** join/#brlcad docelic
(n=docelic@78.134.205.236) |
| 18:33.21 |
indianlarry |
walk on each
surface, plane of two normals along with the plane of from surface
normals and a perp plane along their average |
| 18:33.38 |
indianlarry |
just thinkin
out load |
| 18:33.41 |
indianlarry |
loud |
| 18:34.56 |
jdoliner |
so yeah if we
have two surface's and a point on their intersection curve, then
going iteratively from the point along the cross of the normals
will keep us on the curve? |
| 18:35.12 |
jdoliner |
provided we
take small steps |
| 18:35.32 |
jdoliner |
and our
geometry is "nice" |
| 18:36.28 |
indianlarry |
that can be a
problem |
| 18:37.02 |
indianlarry |
especially
with boundary trims where the UV extent is the
intersection |
| 18:37.42 |
indianlarry |
you will also
need to check in/out of trim |
| 18:38.02 |
indianlarry |
unless you
just start with untrimmed surfaces |
| 18:38.06 |
indianlarry |
your
call |
| 18:38.25 |
indianlarry |
i'd start
with the untrimmed surfaces ;^) |
| 18:39.39 |
indianlarry |
though wwe do
have trim in/out closeness checking |
| 18:40.06 |
jdoliner |
do you mean
by "the UV extent is the intersection" |
| 18:41.20 |
jdoliner |
what do you
mean by the above? |
| 18:41.21 |
jdoliner |
whoops |
| 18:43.14 |
jdoliner |
also have we
considered adding in some algebraic geometry functionality in
brlcad? |
| 18:45.21 |
CIA-30 |
BRL-CAD:
03erikgreenwald * r35156
10/brlcad/trunk/src/librt/primitives/nmg/nmg_manif.c: fix some sign
issues with the paint table? maybe? |
| 18:46.27 |
indianlarry |
the
intersection between to surfaces can lie along one of the surfaces
UV boundary |
| 18:47.19 |
indianlarry |
two |
| 18:48.03 |
indianlarry |
have to make
sure the iterator doesn't step out of UV that's all |
| 18:48.29 |
jdoliner |
yeah that
would be a problem |
| 18:49.37 |
indianlarry |
if your up to
it try out the algebraic solution and if it looks a bit much we'll
go back to iterative approach |
| 18:51.26 |
jdoliner |
k I like that
idea |
| 18:52.06 |
jdoliner |
groebner
bases and stuff can be really powerful |
| 18:52.46 |
indianlarry |
cool, look
forward to seeing what you come up with |
| 18:53.25 |
jdoliner |
does this go
in libbn you think? |
| 18:54.14 |
``Erik |
dang that
indianlarry is a slavedriver O.o |
| 18:55.22 |
indianlarry |
up to you, if
you'd like to keep it in procdb while your testing i'm okay with
it |
| 18:56.07 |
jdoliner |
also a
question on etiquette because I haven't really done this
before |
| 18:56.30 |
jdoliner |
I'm planning
to draw heavily from an opensource library called CoCoa in my
implementation |
| 18:56.39 |
indianlarry |
indianlarry looks for dictionary |
| 18:57.06 |
``Erik |
jdoliner is
out to confuse us mac weenies |
| 18:57.23 |
jdoliner |
I don't think
we want to just include their library as external code, because a
lot of it isn't going to be that useful |
| 18:58.12 |
jdoliner |
it's GPLed
and all so I think this is okay |
| 18:58.30 |
``Erik |
um, we're not
gpl |
| 18:58.46 |
``Erik |
we're bsd and
a little lgpl, some of our consumers cannot abide by
gpl |
| 18:58.58 |
jdoliner |
I
see |
| 18:59.05 |
``Erik |
(like,
consumers that let us have paychecks) :) |
| 18:59.24 |
jdoliner |
ah that kind
of consumer I see |
| 19:00.49 |
jdoliner |
so if we just
"stole" the code and put it in our project, we would need that code
to be gpled or our entire project. either way it doesn't seem like
we can do that |
| 19:02.47 |
indianlarry |
it's not
unheard of to get special author permission but that would have to
be formalized |
| 19:03.13 |
indianlarry |
probably more
trouble than worth |
| 19:04.07 |
jdoliner |
I
see |
| 19:04.46 |
indianlarry |
erik pointed
out that is especially hard with multiple authors as is typical in
an open source gpl environment |
| 19:04.46 |
jdoliner |
k 2 questions
then |
| 19:05.01 |
jdoliner |
yeah that
would become difficult |
| 19:05.17 |
jdoliner |
that license
would something have to be under for us not to have to worry at
all |
| 19:05.36 |
``Erik |
bsd, mit,
apache, ... even lgpl |
| 19:05.58 |
jdoliner |
okay then
that becomes and option, also how much borrowing will we get in
trouble for? |
| 19:07.18 |
``Erik |
if it's a
license that permits it, as much as ya want as long as you
abide |
| 19:07.55 |
``Erik |
for a bsd
style license, that just means you give credit where it's
due |
| 19:07.56 |
indianlarry |
we don't want
to borrow anything we shouldn't |
| 19:08.43 |
``Erik |
but we have
code that links to and are linked to by proprietary shtuff, so we
cannot snarf gpl stuff :( |
| 19:09.34 |
``Erik |
(we probably
have a couple small executables that may be gpl, but the libraries
and headers have to be clean) |
| 19:10.28 |
``Erik |
(billy
holiday to tool, my playlist is awesome) |
| 19:11.05 |
jdoliner |
okay sounds
good |
| 19:11.18 |
``Erik |
there's a
little discussion in the HACKING file about license
crap |
| 19:12.31 |
jdoliner |
I guess I
just have a good reference to look at for stuff |
| 19:12.53 |
jdoliner |
oh well their
code isn't actually such a good fit anyways :) |
| 19:13.44 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-9-142.dclient.hispeed.ch) |
| 19:15.10 |
``Erik |
hm, gotta
kinda be careful of doing that, the whole 'clean room'
issue |
| 19:15.41 |
``Erik |
(I wanna be a
coder, not a lawyer, waahhhhh) |
| 19:17.50 |
CIA-30 |
BRL-CAD:
03starseeker * r35157 10/brlcad/trunk/ (5 files in 3 dirs): Merge
BVNode and SubsurfaceBVNode classes into one BVNode
class |
| 19:21.14 |
jdoliner |
well along
those lines, this algorithm actually doesn't look all that though.
I think I can probably just do it from scratch. |
| 19:21.54 |
jdoliner |
Perhaps this
is Stallman's desired effect from the LGPL |
| 19:21.57 |
jdoliner |
and
GPL |
| 19:24.12 |
``Erik |
stallman is
pushing a religion *shrug* |
| 19:50.32 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:56.29 |
brlcad |
cheers as he gets the big endian to chatter over
serial |
| 19:56.58 |
brlcad |
starseeker:
in a couple days I believe |
| 19:57.43 |
brlcad |
``Erik: heh,
I saw that stats site .. most interesting is that it thinks we
could make about 8 bucks a day on ads, heh |
| 19:59.05 |
brlcad |
jdoliner: if
you look at CAS, you're going to find computational geometry
approaches, they kinda go hand in hand but aren't the only way to
approach the problem (and often suffer massively in terms of
performance) |
| 20:04.19 |
brlcad |
jdoliner: and
yeah, GPL code is certainly out -- we're clean-scrubbed to LGPL or
better so at best you can get someone to "explain to you" a
technique used in some GPL code, but the code itself cannot be
used |
| 20:05.31 |
brlcad |
but more to
the point of the approach, I'd personally prefer keeping your work
isolated in proc-db (could be a subdir for that matter) before
injecting a bunch of computational geometry/algebra routines into
libbn/librt until we know it works well, at least proof of
concept |
| 20:06.29 |
jdoliner |
k I've gotten
myself a nice Algebra folder setup in proc-db |
| 20:06.36 |
brlcad |
otherwise, to
add directly to libbn/librt before it's known to be viable, that'd
be worthy of a branch |
| 20:06.54 |
jdoliner |
do you think
Groebner bases are prohibitively inefficient |
| 20:06.55 |
jdoliner |
? |
| 20:07.06 |
brlcad |
I think they
probably will be :) |
| 20:07.18 |
jdoliner |
rats |
| 20:07.46 |
brlcad |
most of the
algebra-based approaches require stable numerics, with many/most
falling back to fixed- or infinite-precision numerics in order for
them to work |
| 20:08.09 |
brlcad |
which are
anywhere from two to four orders of magnitude slower than other
approaches |
| 20:08.16 |
jdoliner |
the numeric
algorithms I've found still use algebra at the starting point
though |
| 20:08.28 |
brlcad |
it's mostly
how do you solve |
| 20:10.26 |
brlcad |
I mean you're
more than welcome to give it a shot, but you should be rather
cautious that it might mean you end up with squat in terms of
useful code |
| 20:10.54 |
brlcad |
we need
surface surface intersections to be fast slightly more than we need
them to be exact :) |
| 20:11.18 |
*** join/#brlcad stevegt_
(n=stevegt@cislunar.TerraLuna.Org) |
| 20:11.43 |
jdoliner |
K |
| 20:12.01 |
jdoliner |
well as you
can see from my talk with IL |
| 20:12.19 |
jdoliner |
the simple
approach of just marching the normal's cross seems pretty
viable |
| 20:12.31 |
jdoliner |
it fails in
some boundary cases |
| 20:12.59 |
brlcad |
the primary
use is going to be for calculating booleans so we can go
CSG+primitives -> CSG+NURBS -> untrimmed evaluated NURBS
-> polygonal mesh -> triangle mesh |
| 20:13.34 |
jdoliner |
oh |
| 20:13.46 |
jdoliner |
okay so if a
bit of inaccuracy creeps in it might be okay |
| 20:14.01 |
brlcad |
as long as
it's controlled inaccuracy, sure |
| 20:14.13 |
brlcad |
it can't end
up with non-solid geometry |
| 20:14.40 |
jdoliner |
yeah that's
the apocalypse |
| 20:15.22 |
jdoliner |
okay well
using the normal marching is pretty well setup already seeing as ON
already has normal eval builtin. |
| 20:15.26 |
brlcad |
that's an
axiomatic requirement, and it has to keep the same topological
structure/manifolds (if was a 3-manifold when we started, it should
be a 3-manifold regardless of the transformation) |
| 20:28.35 |
CIA-30 |
BRL-CAD:
03starseeker * r35158 10/brlcad/trunk/ (3 files in 3 dirs): Start
preparing to move responsibility for Curve Tree generation and use
to the Surface Tree builder, rather than calling it from
brep.cpp. |
| 20:57.51 |
``Erik |
ho
hum |
| 22:48.34 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 23:02.27 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 23:26.59 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 23:53.19 |
*** join/#brlcad samrose
(n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 00:07.51 |
mafm |
Ralith: it's
warning worthy because you might try to use X as argument to Y, for
example |
| 00:08.16 |
Ralith |
okay, how do
I get it to stfu? :P |
| 00:13.52 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 00:26.57 |
mafm |
Ralith: if X
is first in .h before, it should be initialized before in the
constructor |
| 00:27.12 |
Ralith |
ah,
declaration order. |
| 00:27.26 |
mafm |
there's
probably a -Wno-something to quell it |
| 00:31.37 |
Ralith |
eh, I think
-Wall is good practice. |
| 00:32.27 |
mafm |
you can use
-Wall and -Wno* after that, to omit specific warnings |
| 00:32.51 |
mafm |
especially
useful if the "fault" is on the libraries you use, not on your
code |
| 00:33.46 |
mafm |
-Wall doesn't
include all warnings despite the appearance, it omits some really
low importance ones |
| 00:33.54 |
mafm |
such as
unused parameters in methods |
| 00:35.09 |
Ralith |
actually, it
includes that |
| 00:35.15 |
Ralith |
>_> |
| 00:38.18 |
CIA-38 |
BRL-CAD:
03starseeker * r35254 10/brlcad/trunk/ (3 files in 3 dirs): Add
some output options to bbsize, allow user to specify multiple
objects and build the composite bounding box for all of them, add a
man page |
| 00:42.59 |
Ralith |
pokes starseeker |
| 00:43.27 |
starseeker |
Ralith: saw
your message |
| 00:43.31 |
starseeker |
odd |
| 00:43.43 |
Ralith |
maybe
something changed between when you and I checked out
trunk? |
| 00:44.01 |
mafm |
well, then
there are others, enabled with -Wextra |
| 00:44.12 |
starseeker |
more likely
my box - I run gentoo unstable so there may be an argument between
versions or some such |
| 00:44.19 |
starseeker |
must run - gotta get home |
| 00:47.10 |
Ralith |
seeya |
| 00:47.16 |
Ralith |
<3
gentoo |
| 01:28.44 |
*** join/#brlcad mike111
(n=mike@cadil21.kaist.ac.kr) |
| 01:28.56 |
mike111 |
Hi
all |
| 01:31.44 |
mike111 |
I have a
region. How do I find the area of the projection on the region on a
plane, for example the x-y plane?. |
| 01:34.39 |
Ralith |
rtarea,
maybe? |
| 01:35.30 |
Ralith |
mike111:
yeah, I think rtarea is what you want. |
| 01:35.37 |
Ralith |
"
rtarea - Calculate exposed and presented surface areas |
| 01:35.57 |
mike111 |
Hi Ralith, I
can't see the command in Vol.II (MGED) |
| 01:36.03 |
Ralith |
it's not a
mged command |
| 01:36.24 |
mike111 |
a
raytracer? |
| 01:36.27 |
Ralith |
mged is the
modeler. |
| 01:36.48 |
Ralith |
things like
rt are available there mostly just as a convenience
measure |
| 01:37.03 |
Ralith |
there are
many, many BRL-CAD tools that are completely separate
programs. |
| 01:37.06 |
Ralith |
rtarea is one
of them. |
| 01:37.14 |
mike111 |
where is it
documented? as a manpage? |
| 01:37.28 |
Ralith |
that's the
docs I found, but there may be others |
| 01:37.33 |
Ralith |
I always
check for manpages first |
| 01:39.20 |
mike111 |
Doing man
area gives an `area' command in mged: Calculates an approximate
presented area of one region in the mged |
| 01:39.20 |
mike111 |
<PROTECTED> |
| 01:42.51 |
Ralith |
oh,
cool |
| 01:42.54 |
Ralith |
didn't know
about that |
| 01:43.07 |
mike111 |
for rtarea,
how do I specify which projection I want? |
| 01:43.13 |
Ralith |
dunno |
| 01:43.25 |
mike111 |
I think
`area' gives the surface area and not a projection. |
| 01:43.32 |
Ralith |
hang around,
someone else probably knows |
| 01:46.59 |
mike111 |
thanks for
the rtarea tip |
| 01:47.59 |
Ralith |
np |
| 02:21.04 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 02:21.30 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 02:23.19 |
starseeker |
Ralith: where
does g3d stash its temporary files? $HOME/.g3d? |
| 02:23.36 |
starseeker |
I'm thinking
of the Ogre config stuff |
| 02:25.48 |
Ralith |
/usr/local/share/g3d right now, as bad a
choice as that is |
| 02:26.42 |
starseeker |
nukes |
| 02:26.55 |
starseeker |
hmm - now I
get GLX backdrop image not found: Warning |
| 02:26.55 |
starseeker |
Warning:
Missing charsets in String to FontSet conversion |
| 02:26.56 |
starseeker |
Error: Shell
widget menu has zero width and/or height |
| 02:27.04 |
starseeker |
when trying
to pick a renderer |
| 02:27.30 |
Ralith |
uh, that may
be related to no freeimage |
| 02:27.34 |
Ralith |
lemme send
you my ogre.cfg |
| 02:27.37 |
Ralith |
that'll make
it skip the dialog |
| 02:28.08 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 02:28.10 |
starseeker |
may as well
put it on the wiki |
| 02:28.18 |
starseeker |
other folks
may want to give it a whirl |
| 02:28.56 |
Ralith |
http://isitloadedyet.com/~ralith/ogre.cfg |
| 02:29.09 |
Ralith |
I need to
modify things such that it picks a sane default instead of popping
that dialog up anyway |
| 02:29.28 |
Ralith |
it'd probably
break horribly if someone, say, set it to fullscreen or to use
directx |
| 02:30.14 |
Ralith |
stick that in
/usr/local/share/g3d |
| 02:31.59 |
Ralith |
any
luck? |
| 02:32.10 |
starseeker |
grr - now
it's back to |
| 02:32.11 |
starseeker |
Loading
library ./RenderSystem_GL |
| 02:32.11 |
starseeker |
terminate
called after throwing an instance of 'Ogre::InternalErrorException'
what(): OGRE EXCEPTION(7:InternalErrorException): Could not load
dynamic library ./RenderSystem_GL. System Error:
./RenderSystem_GL.so: cannot open shared object file: No such file
or directory in DynLib::load at
/home/cyapp/cadtoplevel/brlcad/ogre/OgreMain/src/OgreDynLib.cpp
(line 90) |
| 02:32.17 |
starseeker |
Aborted |
| 02:32.27 |
Ralith |
./? |
| 02:32.35 |
starseeker |
dunno |
| 02:32.51 |
Ralith |
is there an
ogreplugins.cfg in the g3d dir? |
| 02:33.10 |
starseeker |
yes |
| 02:33.18 |
Ralith |
what's in
it? |
| 02:33.28 |
starseeker |
# Defines
plugins to load |
| 02:33.28 |
starseeker |
PluginFolder= |
| 02:33.28 |
starseeker |
Plugin=RenderSystem_GL |
| 02:33.28 |
starseeker |
Plugin=Plugin_OctreeSceneManager |
| 02:33.28 |
Ralith |
PluginFolder
should be set to /usr/local/lib/OGRE |
| 02:33.30 |
Ralith |
ahah |
| 02:33.32 |
Ralith |
there's your
problem. |
| 02:34.29 |
starseeker |
gets further
now |
| 02:34.34 |
starseeker |
terminate
called after throwing an instance of 'Ogre::FileNotFoundException'
what(): OGRE EXCEPTION(6:FileNotFoundException): Cannot locate
resource sphere.mesh in resource group Autodetect or any other
group. in ResourceGroupManager::openResource at
/home/cyapp/cadtoplevel/brlcad/ogre/OgreMain/src/OgreResourceGroupManager.cpp
(line 738) |
| 02:35.03 |
Ralith |
that's one of
those 'make install not yet supported' issues. |
| 02:35.16 |
Ralith |
sphere.mesh
should be somewhere in your ogre checkout |
| 02:35.18 |
Ralith |
copy it into
the g3d dir |
| 02:37.06 |
starseeker |
/usr/local/share/g3d/sphere.mesh |
| 02:37.09 |
starseeker |
right? |
| 02:37.22 |
Ralith |
yup |
| 02:37.26 |
starseeker |
still can't
find it |
| 02:37.39 |
Ralith |
is there a
resources.cfg in there? |
| 02:37.44 |
starseeker |
Mesh: Loading
sphere.mesh. |
| 02:37.44 |
starseeker |
terminate
called after throwing an instance of 'Ogre::FileNotFoundException'
what(): OGRE EXCEPTION(6:FileNotFoundException): Cannot locate
resource sphere.mesh in resource group Autodetect or any other
group. in ResourceGroupManager::openResource at
/home/cyapp/cadtoplevel/brlcad/ogre/OgreMain/src/OgreResourceGroupManager.cpp
(line 738) |
| 02:37.48 |
Ralith |
it should
contain: |
| 02:37.49 |
starseeker |
Aborted |
| 02:37.54 |
Ralith |
[General] |
| 02:37.54 |
Ralith |
FileSystem=/usr/local/share/g3d/ |
| 02:38.08 |
starseeker |
hmm - it's
set to RBGui |
| 02:38.32 |
Ralith |
scrap it,
drop in what I pasted |
| 02:38.40 |
starseeker |
yep,
bing |
| 02:39.16 |
starseeker |
cool |
| 02:39.20 |
Ralith |
works? |
| 02:39.23 |
starseeker |
yep |
| 02:39.27 |
Ralith |
:D |
| 02:39.37 |
starseeker |
might want to
fix those defaults... |
| 02:39.49 |
Ralith |
yeah |
| 02:39.51 |
Ralith |
just fixed
two of them |
| 02:40.04 |
Ralith |
the plugindir
thing and the resourcesdir thing |
| 02:40.05 |
CIA-38 |
BRL-CAD:
03ralith * r35255 10/rt^3/trunk/src/g3d/CMakeLists.txt: More build
system improvements; installations should be somewhat less broken
now. |
| 02:40.16 |
Ralith |
was there
anything else that broke? |
| 02:40.34 |
starseeker |
don't think
so |
| 02:40.46 |
Ralith |
kk |
| 02:40.48 |
starseeker |
might add the
sphere.mesh to g3d install |
| 02:40.50 |
Ralith |
oh, the
config file thing |
| 02:40.54 |
starseeker |
since we need
it for now |
| 02:40.57 |
starseeker |
easy to get
rid of |
| 02:42.43 |
CIA-38 |
BRL-CAD:
03ralith * r35256 10/rt^3/trunk/src/g3d/CMakeLists.txt: More build
system cleanup, added autogenerate/install valid
ogre.cfg. |
| 02:43.07 |
mike111 |
Hi all: mged
hangs when I run `area' on a simple sphere region. any
ideas? |
| 02:44.31 |
starseeker |
hmm - it's
busted |
| 02:45.23 |
starseeker |
toss it in
here: http://sourceforge.net/tracker/?group_id=105292&atid=640802 |
| 02:49.15 |
mike111 |
starseeker:
is the SF link for me? |
| 02:49.42 |
Ralith |
starseeker:
okay, taken care of. |
| 02:49.51 |
Ralith |
also switched
to something prettier. |
| 02:49.55 |
CIA-38 |
BRL-CAD:
03ralith * r35257 10/rt^3/trunk/src/g3d/ (CMakeLists.txt
OgreGLWidget.cxx knot.mesh): Changed test mesh to something more
interesting, and added installation support for it. |
| 02:50.21 |
Ralith |
in *theory*
installation should be working now. |
| 02:51.08 |
CIA-38 |
BRL-CAD:
03ralith * r35258 10/rt^3/trunk/src/g3d/INSTALL: Updated
INSTALL. |
| 02:56.31 |
Ralith |
the
installation test didn't actually quite work for me, but I think
that was because I have a debug version of Ogre
installed? |
| 02:57.29 |
Ralith |
OGRE_PLUGIN_DIR_REL was set to NOTFOUND
for some reason. Will worry about that later. |
| 03:02.38 |
*** join/#brlcad KhadorMech
(n=Adder@cpe-72-224-148-98.maine.res.rr.com) |
| 03:04.05 |
KhadorMech |
Hi I'm trying
to get brl running on my leopard mac and I keep getting "bus
error". Anyone know a work-around? |
| 03:11.27 |
*** part/#brlcad KhadorMech
(n=Adder@cpe-72-224-148-98.maine.res.rr.com) |
| 03:36.04 |
starseeker |
Ralith: got
the same thing |
| 03:36.07 |
starseeker |
NOTFOUND |
| 03:36.15 |
Ralith |
hm,
weird. |
| 03:36.34 |
Ralith |
lemme try
updating the cmake module |
| 03:40.40 |
Ralith |
didn't do any
good :/ |
| 03:41.02 |
Ralith |
oh wel,
committing anyway 'cuz presumably ogre's improved it by
now |
| 03:41.53 |
CIA-38 |
BRL-CAD:
03ralith * r35259 10/rt^3/trunk/cmake/ (FindOGRE.cmake
FindPkgMacros.cmake): Updated OGRE's cmake module (and added some
stuff from OGRE's impl. of FindPkgMacros) in the hopes of improving
reliability across platforms. |
| 03:51.53 |
Ralith |
strictly this
is an OGRE-side bug |
| 03:52.16 |
Ralith |
since it's
their cmake module that's failing to find the stuff installed by
their build system. |
| 05:26.26 |
mike111 |
I'm trying to
run rtarea from the commandline using mged -c new.g "Z;E
s1.r;top;rtarea" |
| 05:27.16 |
mike111 |
but getting:
bu_log: write error |
| 05:50.28 |
Ralith |
wonders why he didn't just try running rtarea
itself |
| 06:23.27 |
*** join/#brlcad mike111
(n=mike@cadil21.kaist.ac.kr) |
| 07:26.56 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 10:13.52 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 12:02.31 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 12:11.40 |
brlcad |
Ralith: c++
initializes in the order declared, so when your initialization list
doesn't match, it warns since you might be making some assumption
about the order you listed |
| 12:11.58 |
brlcad |
doesn't
matter for simple types, but especially if they're objects, you can
get into bad juju |
| 12:13.06 |
brlcad |
the 'area'
command gives projected/presented area, but just a rough
approximation -- rtarea is the tool to use |
| 12:16.08 |
``Erik |
totally
awesome, I've gotten, like, NO mail at bz, but this morning, I get
spam there. yayyyy |
| 12:16.25 |
brlcad |
he gets the
bu_log write error because rtarea is async and mged terminates
before rtarea finishes, yet it can't display the results because
mged is gone |
| 12:18.06 |
``Erik |
personally thinks that mged -c needs some significant
attention... fixing async issues, choosing appropriate streams,
etc |
| 12:19.02 |
``Erik |
or; mged as a
pipe tool needs attention, rather |
| 12:53.13 |
``Erik |
the rotate
issues I've been seeing on osX.5 are not choppiness, they seem to
be that it's reading a mouse down and up and doing a zoom instead
of seeing a mouse down and move to rotate |
| 12:53.20 |
``Erik |
um, it zooms
on mouse down |
| 12:53.37 |
``Erik |
I imagine tk
and apple X11.app are not playing nice |
| 12:54.04 |
``Erik |
(this is on a
macbook from november) |
| 13:00.24 |
brlcad |
``Erik: my
quick lookings seemed that it was some initialization problem on
mged/libged's part |
| 13:00.53 |
brlcad |
as it works
just fine when you first e an object, you can spin it around freely
... then once you zoom in/out, it's hosed |
| 13:01.21 |
``Erik |
ok, what I
was seeing, I think is related, so I'm sharing what little info I
have so the people who will fix it are prepared |
| 13:01.42 |
brlcad |
thinks ``Erik is prepared to fix it ;) |
| 13:03.43 |
``Erik |
fuck that
shit, I called in sick today (stomach is bugging me) |
| 13:04.25 |
``Erik |
felt awful
green yesterday, went to a party on tuesday and wasn't used to the
drinking and being around cigarettes and stuff |
| 13:04.35 |
``Erik |
I got old.
*sob* |
| 13:05.02 |
d-lo |
Got used to
no poison and cleaner air eh? :) |
| 13:05.25 |
``Erik |
well,
different pollutions |
| 13:06.37 |
``Erik |
d-lo, if you
see the slavedriver or her minion, I wasn't able to get either by
phone, nor the mathematicion. I left a VM for the boss, but a "hey,
didja check your vmail?" shout would make me feel
better? |
| 13:07.05 |
d-lo |
righto. |
| 13:07.09 |
``Erik |
danke |
| 13:08.20 |
``Erik |
iokit is a
wreck :/ |
| 13:08.48 |
``Erik |
wants to write a little program with a similar interface to
batch that throw sigstop and sigcont signals based on cpu temp
and/or fan speed |
| 13:09.17 |
``Erik |
keep my lappy
from smoking up during a rebuild of BRL-CAD :D without burning my
knees |
| 13:11.29 |
``Erik |
has to figure out http://pastebin.bzflag.bz/d7958bdd
before he can even look at mouse events |
| 13:12.40 |
``Erik |
(interesting,
I put my name in as "``Erik" in the pastebin, and it reads it as
"Erik".... wonder what happens if my name is "`rm -rf /`"
O.o |
| 13:14.49 |
``Erik |
(and, uh, it
has a spam problem now.) |
| 13:15.57 |
d-lo |
why are tyou
trying to break the pastebin? |
| 13:17.09 |
``Erik |
because if I
break it, then we know it's breakable and we can fix it. If someone
else breaks it, it's a bad day |
| 13:17.46 |
``Erik |
spent too much time as a sysadmin, thinks that's why he was
pushed towards the "test developer" roll on "that
project" |
| 13:17.55 |
``Erik |
role |
| 13:18.15 |
d-lo |
Sure. Right.
I know you. Its pure Malice isn't it? |
| 13:19.12 |
``Erik |
hey, man, at
least I'm not so deviant that I'm cracking secured encyption keys
and hijacking data streams for man-in-the-middle attacks on
commercial proprietary software |
| 13:19.15 |
``Erik |
:D |
| 13:20.15 |
``Erik |
<--
stickin' to the clasic ethos, just had a "hm, thats... interesting"
moment, that's it :) |
| 13:20.40 |
d-lo |
riiiiiight. |
| 13:20.51 |
d-lo |
and its not
commercial anymore :) |
| 13:22.38 |
``Erik |
you'll either
have to find a group of artists willing to commit and obey a common
vision (EXTREMELY difficult if you don't have $'s), or run the risk
of being a rogue bandit skirting the grey areas of the law
:( |
| 13:23.31 |
``Erik |
<-- used
and was mortified by the whole bnetd situation, is
gunshy |
| 13:24.16 |
``Erik |
and the
history of strategus... |
| 13:32.42 |
brlcad |
thinks he meant http://pastebin.bzflag.bz/d7958fbdd |
| 13:52.21 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 13:52.25 |
ornitorrincos |
ho
louipc |
| 13:52.48 |
``Erik |
no, opengl
support is not going to give you shaded displays or anything that X
won't do.. and generally X will do it better |
| 13:53.05 |
*** join/#brlcad pro-rsoft
(n=prorsoft@unaffiliated/pro-rsoft) |
| 13:53.19 |
``Erik |
oh crap,
they're ALL coming here O.o :D *duck* |
| 13:53.28 |
pro-rsoft |
Hehe |
| 13:53.38 |
``Erik |
(srry, been
pimping) |
| 13:54.53 |
``Erik |
so, yeah, not
detecting opengl is not all that bad of a thing, we can figure out
how to make it work, but it's not a show stopper |
| 13:55.30 |
ornitorrincos |
just curious
if it was normal or I had something broken |
| 13:55.51 |
``Erik |
um, if you're
using linux, it SHOULD be detected |
| 13:56.07 |
``Erik |
do you have
the mesa dev stuff on? |
| 13:56.14 |
ornitorrincos |
then I
probably have something broken |
| 13:56.17 |
``Erik |
GL.h GLU.h
etc? |
| 13:56.40 |
pro-rsoft |
you mean
GL/gl.h |
| 13:56.49 |
``Erik |
er, yeah,
it's been a while |
| 13:57.09 |
``Erik |
we had ogl
support back to when it was irisgl and a propritary sgi
thang |
| 13:57.23 |
``Erik |
proprietary |
| 13:57.33 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 13:57.47 |
brlcad |
mornin'
elena |
| 13:57.54 |
elena |
hi. |
| 13:58.04 |
elena |
how are
you? |
| 13:58.09 |
brlcad |
great! |
| 13:58.17 |
elena |
I was hopping
to catch one of you around. |
| 13:58.30 |
``Erik |
is a square, sorry |
| 13:58.30 |
elena |
i'm working
on conversion. |
| 13:58.31 |
brlcad |
busy day and
slow start to it at that, but starting to get the juices
flowing |
| 13:59.03 |
elena |
:) |
| 13:59.06 |
ornitorrincos |
``Erik, yes
those headrs I ahve them, checked with louipc |
| 13:59.43 |
elena |
are then any
particular formats we want to support more than others. |
| 13:59.45 |
elena |
? |
| 14:00.09 |
``Erik |
ok, our ogl
check starts on configure.ac:1364 |
| 14:00.48 |
``Erik |
looking for
libGL.so libGL2.so and libGL.dylib |
| 14:01.18 |
brlcad |
elena: yeah,
.g :) |
| 14:01.23 |
``Erik |
with minor
hackery around the mac tardedness |
| 14:02.04 |
elena |
ok. but from
what to g? |
| 14:02.12 |
elena |
dxf for
example? |
| 14:02.32 |
brlcad |
followed by
the more complex formats, namely iges and dxf for
starters |
| 14:02.41 |
elena |
ok. |
| 14:02.42 |
elena |
thanks. |
| 14:02.46 |
``Erik |
are you
looking for a prioritized list of import formats? |
| 14:02.54 |
elena |
yes. |
| 14:02.57 |
brlcad |
if you want,
you could just support anything we have a g-* for |
| 14:03.18 |
``Erik |
*-g you
mean |
| 14:03.22 |
elena |
i did a list
for that. |
| 14:03.23 |
brlcad |
right |
| 14:03.24 |
elena |
yes. |
| 14:03.40 |
elena |
but for now,
only with *-g and g-* |
| 14:03.50 |
elena |
because i
need sample files to test. |
| 14:04.07 |
``Erik |
but I don't
think we have any document saying that "yes, we have alpha-g and
beta-g, but if you have both, we'd prefer beta-g to carry geometry
better" |
| 14:04.11 |
elena |
and I get
those samples by converting from g to that format
(offline) |
| 14:04.39 |
ornitorrincos |
libGL.so is
present |
| 14:05.02 |
``Erik |
um, I made a
csv in src/conv/ a while back, but it's not sorted... might be nice
if someone sorted it by preference? |
| 14:05.28 |
``Erik |
orn: can you
paste the ogl fail to a pastebin? we have pastebin.bzflag.bz
:) |
| 14:09.47 |
brlcad |
elena: you
can also find samples of most formats pretty easily by using google
with the file-type keyword |
| 14:09.58 |
elena |
ACAD and
EUCLID don't have a specific file extension? |
| 14:10.07 |
ornitorrincos |
umn |
| 14:10.12 |
elena |
i know about
filetype:pdf, doc and stuff. |
| 14:10.12 |
ornitorrincos |
ok, who has
telekinesis |
| 14:10.25 |
louipc |
heheh |
| 14:10.25 |
brlcad |
yea, like
"filetype:dxf sample" |
| 14:10.36 |
elena |
dxf is
simple. |
| 14:10.42 |
elena |
how about
euclid? |
| 14:11.08 |
ornitorrincos |
louipc, now
the damn opengl works |
| 14:11.11 |
brlcad |
lesse.. there
suffix doesn't match their name like the others iirc |
| 14:11.18 |
louipc |
ornitorrincos: haha! ok cool |
| 14:11.44 |
louipc |
I preferred
using openGL because X is too slow for me |
| 14:11.53 |
louipc |
ogl uses
hardware accel and stuff |
| 14:11.58 |
brlcad |
(modern
euclid that is) |
| 14:12.06 |
louipc |
but it seems
to have refresh problems or something now |
| 14:12.26 |
elena |
thank you.
for dxf, google search is a good idea. |
| 14:12.47 |
elena |
when i'm
finished, i could it those to test some real examples. |
| 14:12.52 |
ornitorrincos |
and the irc
log finished a few lines after I posted the error in
pastebin |
| 14:13.26 |
``Erik |
louipc:
really? gl lines are awful slow, usually X is a lot faster :/ the
whole bus transfer issue, y'know? do you have a smoking video card
on a craptacular cpu? |
| 14:14.19 |
elena |
e.g like
Erik's 8-core? |
| 14:14.29 |
elena |
;) |
| 14:14.36 |
louipc |
``Erik: kind
of |
| 14:14.43 |
``Erik |
I'm home
today, just a 2 core macbook here :) |
| 14:15.02 |
louipc |
I run a pIII
866 MHz |
| 14:15.57 |
``Erik |
that is a bit
behind the curve.. but *shrug* my first two machines were measured
in khz |
| 14:16.32 |
``Erik |
and one of
these days, I'll get around to making a vax 780 with 43bsd
available on a web interface so people can experience BRL-CAD 4.x
in its glory |
| 14:16.40 |
``Erik |
simh++ |
| 14:17.10 |
``Erik |
when things
like clear or ls take a few seconds, that's nutty stuff
:D |
| 14:17.20 |
louipc |
it's good to
run old hardware, you can catch performance issues more easily
;D |
| 14:17.40 |
ornitorrincos |
``Erik, for
that you can do ssh over a slow connection ;) |
| 14:18.07 |
``Erik |
heh, a few
jobs ago, I was doing java code in a small shop, my choice hardware
for development was a dual p133 with scsi's, the amd 450 was for
video games :) |
| 14:18.37 |
elena |
:-) |
| 14:19.16 |
``Erik |
DEC prioris,
made an awesome coffee table... and it showed two penguins on boot
O.o |
| 14:22.32 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35260 10/brlcad/trunk/src/conv/g-egg.c: make the
vertex id unique to the file. Eliminate trailing whitespace.
Etc. |
| 14:24.08 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35261
10/brlcad/trunk/src/adrt/libtie/tie_kdtree.c: panic mode for
silliness. |
| 14:24.37 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35262 10/brlcad/trunk/src/librt/prep.c:
irrelevent slot. |
| 15:03.27 |
d-lo |
is it brlcad
vs the servers again today? |
| 15:05.04 |
brlcad |
brlcad vs
monthly reports and other business mail matters |
| 15:05.21 |
d-lo |
ah... the fun
stuff :) |
| 15:09.39 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 15:10.18 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 15:16.30 |
``Erik |
if you don't
get the release out in time, I can push it while ya'll are out
throwing beads at the pretty girls, just make sure ya bring back
pics |
| 15:17.27 |
``Erik |
(ya knew
that, but I won't bitch any more than normal) |
| 16:27.14 |
*** join/#brlcad samrose
(n=samrose@ip-207-145-38-45.iad.megapath.net) |
| 17:00.14 |
CIA-38 |
BRL-CAD:
03bob1961 * r35263 10/brlcad/trunk/src/adrt/libtie/tie_kdtree.c:
Fixed typo. |
| 17:16.58 |
CIA-38 |
BRL-CAD:
03bob1961 * r35264
10/brlcad/trunk/doc/docbook/system/man1/en/bbsize.xml: This is only
a placeholder so that the build completes. The real file is
coming. |
| 17:28.43 |
CIA-38 |
BRL-CAD:
03n_reed * r35265 10/brlcad/trunk/src/ (libdm/Makefile.am
libdm/dm-rtgl.c tclscripts/mged/mview.tcl): turned z-clipping on by
default for dm-rtgl |
| 17:40.32 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E1B8.dip.t-dialin.net) |
| 17:48.42 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:50.28 |
*** join/#brlcad hippieindamakin8
(n=hippiein@210.212.55.3) |
| 18:19.03 |
CIA-38 |
BRL-CAD:
03jdoliner * r35266 10/brlcad/trunk/ (include/vmath.h
src/proc-db/surfaceintersect.cpp): |
| 18:19.05 |
CIA-38 |
BRL-CAD: adds
the Jiggle get approximate intersection points closer to each other
using |
| 18:19.07 |
CIA-38 |
BRL-CAD:
newtonesque methods also adds an additional macro in vmath.h
Project which |
| 18:19.13 |
CIA-38 |
BRL-CAD:
decomposes a vector into components parallel and perpendiculur to a
given vector |
| 18:33.18 |
CIA-38 |
BRL-CAD:
03bob1961 * r35267 10/brlcad/trunk/src/libged/erase.c: Removed a
few unused variables. |
| 18:38.48 |
CIA-38 |
BRL-CAD:
03bob1961 * r35268 10/brlcad/trunk/src/libged/draw.c: Mod
ged_addToDisplay to check if name is already in the list. If so,
return the associated gdlp. |
| 18:41.58 |
*** join/#brlcad hippieindamakin8
(n=hippiein@202.3.77.11) |
| 18:49.28 |
CIA-38 |
BRL-CAD:
03starseeker * r35269
10/brlcad/trunk/doc/docbook/system/man1/en/bbsize.xml: oops - add
the bbsize man page content. |
| 19:06.32 |
CIA-38 |
BRL-CAD:
03bob1961 * r35270 10/brlcad/trunk/ (3 files in 3 dirs): Added code
to redraw anything associated with the object being edited if it's
currently being drawn. |
| 19:55.20 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:18.40 |
CIA-38 |
BRL-CAD:
03ebautu * r35271
10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.inc
brlcad.module): Moved PHP-BRLCAD interface in separate file
(brlcad.inc) and implemented file conversions. |
| 21:28.10 |
CIA-38 |
BRL-CAD:
03n_reed * r35272 10/brlcad/trunk/ (include/dm-rtgl.h
src/libdm/dm-rtgl.c): coloring with region material
colors |
| 21:55.04 |
CIA-38 |
BRL-CAD:
03bob1961 * r35273 10/brlcad/trunk/src/libged/expand.c: This is a
follow-on from the previous commit (i.e. return only database
entries that match the pattern(s)). This handles the case where the
pattern has no wildcards. |
| 21:57.44 |
CIA-38 |
BRL-CAD:
03bob1961 * r35274 10/brlcad/trunk/src/tclscripts/lib/Command.tcl:
Added tab completion to the Command widget. |
| 22:17.05 |
*** join/#brlcad Patmcc19_
(n=chatzill@71-223-63-203.phnx.qwest.net) |
| 22:24.03 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E1B8.dip.t-dialin.net) |
| 23:35.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 23:35.43 |
*** join/#brlcad Patmcc19
(n=chatzill@71-223-38-122.phnx.qwest.net) |
| 01:01.31 |
mike111 |
hi
all |
| 01:02.12 |
Ralith |
hello |
| 01:02.21 |
mike111 |
hi
Ralith. |
| 01:02.36 |
Ralith |
05:17:14 <
brlcad> the 'area' command gives projected/presented area, but
just a rough approximation -- rtarea is the tool to use |
| 01:02.39 |
Ralith |
05:20:17 <
``Erik> totally awesome, I've gotten, like, NO mail at bz, but
this morning, I get spam there. yayyyy |
| 01:02.42 |
Ralith |
05:20:33 <
brlcad> he gets the bu_log write error because rtarea is async
and mged terminates before rtarea finishes, yet it can't display
the results because mged is gone |
| 01:03.00 |
Ralith |
mike111: see
above. |
| 01:03.02 |
mike111 |
Thanks, saw
that when I just checked the log. |
| 01:03.21 |
mike111 |
any solution?
I need to save the rtarea output into a file. |
| 01:04.06 |
Ralith |
solution to
what? |
| 01:04.39 |
mike111 |
I'm trying to
run rtarea from the commandline using mged -c new.g "Z;E
s1.r;top;rtarea" |
| 01:04.55 |
mike111 |
but getting
bu_log: write error |
| 01:05.03 |
mike111 |
that's the
async thing brlcad mentioned. |
| 01:05.15 |
Ralith |
mike111:
you're hitting the exact same problem he mentioned,
too. |
| 01:05.20 |
Ralith |
don't use
mged. |
| 01:05.21 |
Ralith |
use
rtarea. |
| 01:06.12 |
mike111 |
but how do I
set the correct view without mged? rtarea calculates the area of
`projected/presented area', that is, you need to set the direction
from which you view the object. |
| 01:06.40 |
Ralith |
play with it
and find out? |
| 01:06.59 |
Ralith |
wait for
someone who knows? |
| 01:07.00 |
mike111 |
man rtarea
doesn't say anything about setting the view angle. |
| 01:07.15 |
Ralith |
that's why I
said "play with it", rather than "read the manpage." |
| 01:07.21 |
mike111 |
that's why
I'm on the channel again today ;) |
| 01:07.35 |
Ralith |
I suggest
playing with it while waiting. |
| 01:08.49 |
mike111 |
do you know
what's the difference between arced and oed? |
| 01:09.01 |
Ralith |
nope |
| 01:09.05 |
Ralith |
mged's help
command might. |
| 01:09.17 |
mike111 |
Wasn't clear
to me from reading the manual. |
| 01:09.30 |
mike111 |
seems like I
can modify an object's attribute with either. |
| 01:09.37 |
starseeker |
mike111: you
might try saveview inside mged and editing the generated script to
call rtarea rather than rt |
| 01:10.16 |
Ralith |
perhaps
rtarea accepts the same options as rt? |
| 01:10.26 |
Ralith |
much in the
way that X apps tend to all accept the same X options? |
| 01:11.24 |
starseeker |
appears
to |
| 01:11.37 |
Ralith |
mike111:
then, see man rt for how to set the view. |
| 01:12.20 |
starseeker |
tried it, and it looks like it worked: set up the desired
view in mged, type saveview script.sh, edit script.sh to call
rtarea rather than rt (probably want to delete the -o line and the
redirect to a log, unless you want the rtarea output in a log
file) |
| 01:13.19 |
mike111 |
thanks Ralith
and starseeker :) will try that |
| 01:14.29 |
mike111 |
rtarea isn't
an mged command so it's not in vol.II. Is there a manual for all
such non-mged commands or at least a list of such
commands? |
| 01:15.16 |
Ralith |
ls
/path/to/brlcad/bin |
| 01:15.21 |
Ralith |
:P |
| 01:15.59 |
starseeker |
mike111: our
documentation is far from comprehensive - first thing to try is
brlman commandname |
| 01:18.07 |
starseeker |
Ralith:
probably adding a screenshot of the g3d window with the knot to
your log - the wiki does support images, IIRC |
| 01:18.38 |
Ralith |
starseeker:
you mean, I probably should? |
| 01:18.46 |
Ralith |
yeah, sounds
like a good idea |
| 01:18.53 |
Ralith |
needs to sit down for half an hour at some point and bring
his log up to date |
| 01:23.53 |
starseeker |
glares at g-vrml, g-stl, and friends |
| 01:24.03 |
starseeker |
or more
specifically, the tesselation routines behind them |
| 01:37.14 |
CIA-38 |
BRL-CAD:
03starseeker * r35275 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
Tweak the isFlat comments |
| 01:42.10 |
mike111 |
is there a
way to find the surface area of an object and not the area of a
projection? |
| 01:44.49 |
*** join/#brlcad LarsG
(n=lars@nusnet-191-70.dynip.nus.edu.sg) |
| 01:44.55 |
*** part/#brlcad LarsG
(n=lars@nusnet-191-70.dynip.nus.edu.sg) |
| 02:06.37 |
CIA-38 |
BRL-CAD:
03starseeker * r35276 10/brlcad/trunk/ (7 files in 3 dirs): OK,
enough of the benefits of the cleanup code are in the 'real' code
that the cleanup code can be removed - flesh out the comments for
subdivision and remove the cleanup files. |
| 02:06.37 |
brlcad |
mike111: no,
not presently, at least not a good way that doesn't involve heavy
scripting/coding |
| 02:07.25 |
mike111 |
the manual
(Vol.II) mentions `analyze' but it only applies to
arbs? |
| 02:07.34 |
brlcad |
right |
| 02:08.01 |
mike111 |
will
`analyze' work on an ars? |
| 02:09.06 |
brlcad |
mike111: to
run rtarea like you wanted, instead of running it inside mged,
instead run "saveview -e rtarea whatever.rt" in mged, and then run
./whatever.rt |
| 02:09.16 |
brlcad |
no, analyze
only works on arb8s |
| 02:10.19 |
mike111 |
thanks for
the rtarea tip. I'm now playing with a bash scripting to change a
`saveview' script. |
| 02:10.52 |
brlcad |
"help
saveview" has a few other options |
| 02:11.00 |
brlcad |
for logging
output, inputs, etc |
| 02:11.13 |
mike111 |
will check
that. |
| 02:11.15 |
mike111 |
what's the
difference between arced and oed? |
| 02:11.44 |
brlcad |
you want to
use oed and not arced ;) |
| 02:12.11 |
brlcad |
arced is an
old command intended for animation
manipulation/articulation |
| 02:12.20 |
mike111 |
I read the
manual about oed but Vol.II mentions arced which seems to do
same. |
| 02:12.40 |
mike111 |
OK. It's oed
then ;) |
| 02:12.44 |
brlcad |
huh, a bit
surprised vol II would mention it.. |
| 02:13.13 |
brlcad |
i mean it'll
do the trick, but oed is really the one to use -- whole tutorial on
the site dedicated to explaining just that command in detail with
lots of example |
| 02:13.47 |
mike111 |
arced is in
p.157-158 |
| 02:14.02 |
mike111 |
that's the
manual I read. easy to follow. |
| 02:27.02 |
starseeker |
oed doc is
here:
http://brlcad.org/w/images/3/36/Object_Editing_-_the_oed_Command.pdf |
| 02:29.49 |
mike111 |
starseeker:
thanks, that's the manual I mentioned above. |
| 02:30.58 |
starseeker |
makes a stab at playing with C++ list push_back options and
makes things worse... yech |
| 02:31.27 |
starseeker |
ok, better to
get some sleep and try with > 0.5 of brain tomorrow |
| 02:34.52 |
Ralith |
nite! |
| 02:39.47 |
brlcad |
Ralith:
starseeker: all the rt* apps accept the same options as 'rt' -- if
they have specialized options, they're '-c"set VAR=value"' options
(man rtedge for examples) |
| 02:40.00 |
Ralith |
cool,
suspected as much |
| 02:40.04 |
Ralith |
that explains
the sparse manpage |
| 02:40.30 |
brlcad |
also why
saveview has a -e option, to specify another rt to exec
instead |
| 02:42.12 |
Ralith |
cool! |
| 03:12.57 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 03:22.18 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 03:22.19 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 03:22.19 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 03:26.26 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 03:31.46 |
CIA-38 |
BRL-CAD:
03n_reed * r35277 10/brlcad/trunk/src/libdm/dm-rtgl.c: lighting
using open gl |
| 03:35.55 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 04:07.09 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 05:25.29 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 06:31.44 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 07:23.48 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 08:08.52 |
*** join/#brlcad d-lo_
(n=claymore@bz.bzflag.bz) |
| 10:27.58 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 10:52.04 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 10:59.37 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 11:20.14 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E33F.dip.t-dialin.net) |
| 12:31.48 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 12:34.41 |
*** join/#brlcad BigAToo
(n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 13:21.23 |
CIA-38 |
BRL-CAD:
03irpguardian * r35278 10/brlcad/trunk/src/proc-db/human.c: Added
command line function for centering human model, -l, by xyz
coordinate. |
| 13:21.59 |
*** join/#brlcad rnkv2
(n=rnkv2@adqp209.neoplus.adsl.tpnet.pl) |
| 13:22.06 |
rnkv2 |
hi |
| 13:35.42 |
*** join/#brlcad mafm_
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 13:37.11 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 13:44.29 |
*** join/#brlcad kanzure
(i=bryan@dhcp-84-36.me.utexas.edu) |
| 14:08.49 |
brlcad |
hello
rnkv2 |
| 14:08.52 |
rnkv2 |
could you
help me with this problem: http://pastebin.com/m6f3d1b53
(it is the end of my compilation log) |
| 14:09.07 |
brlcad |
can't get to
pastebin.com |
| 14:09.10 |
brlcad |
~bzpaste |
| 14:09.30 |
brlcad |
use, http://pastebin.bzflag.bz/ instead
please |
| 14:09.38 |
rnkv2 |
sure |
| 14:09.46 |
brlcad |
~bzpaste is
http://pastebin.bzflag.bz/ |
| 14:09.46 |
ibot |
brlcad:
okay |
| 14:10.32 |
louipc |
rnkv2: looks
like you need mesa |
| 14:11.12 |
rnkv2 |
brlcad, it
messed up, give me a moment please |
| 14:11.29 |
rnkv2 |
(checking if
i have mesa) |
| 14:12.15 |
rnkv2 |
mesa-7.3-r1
here |
| 14:12.23 |
louipc |
debian/ubuntu? |
| 14:13.28 |
louipc |
may need
mesa-dev then. Hmm I don't know what version is needed though. I
have 7.5 |
| 14:14.05 |
rnkv2 |
gentoo
here |
| 14:14.17 |
rnkv2 |
media-libs/mesa-7.3-r1 exactly |
| 14:14.37 |
rnkv2 |
ok, i will
check for newest |
| 14:15.05 |
louipc |
check if you
have those functions |
| 14:15.34 |
rnkv2 |
could you
provide ma hint how should i do that? |
| 14:16.00 |
louipc |
maybe `man
glDeleteLists` |
| 14:16.41 |
louipc |
that only
says if you have the man page though hehe |
| 14:16.54 |
rnkv2 |
the same here
:) |
| 14:21.08 |
louipc |
rnkv2: it's
there yeah? |
| 14:21.24 |
rnkv2 |
brlcad, here
you go: http://pastebin.bzflag.bz/m25df21 |
| 14:21.53 |
rnkv2 |
no, it says
that there is no such man page :( |
| 14:21.54 |
louipc |
yeah try
updating to latest version, post your full log |
| 14:22.16 |
louipc |
rnkv2: oh ok.
that might be a bad sign |
| 14:22.26 |
louipc |
rnkv2: you
don't have -docs USEFLAG do you? |
| 14:22.42 |
rnkv2 |
i think i
don't have |
| 14:22.59 |
louipc |
ok |
| 14:23.52 |
louipc |
hmm mesa 7.3
isn't that old |
| 14:24.13 |
rnkv2 |
i have 'doc'
flag in system and it's switched of globaly |
| 14:24.21 |
rnkv2 |
off* |
| 14:25.54 |
rnkv2 |
btw what is
the difference between http://pastebin.bzflag.bz/ and
http://pastebin.com ? |
| 14:26.36 |
louipc |
I guess
brlcad's company doesn't let him visit pastebin.com |
| 14:27.16 |
rnkv2 |
thanks for
explaining |
| 14:27.18 |
louipc |
pastebin.com
can get kind of slow though |
| 14:35.45 |
rnkv2 |
what about
libdrm? which version is needed? |
| 14:35.56 |
rnkv2 |
mine is
libdrm-2.4.5 |
| 14:36.46 |
louipc |
hmm no
idea |
| 14:37.26 |
rnkv2 |
ok,
installing media-libs/mesa-7.5-r2 |
| 14:37.55 |
rnkv2 |
and
libdrm-2.4.12 as dependency |
| 14:38.36 |
louipc |
hehe that's
what I have |
| 14:39.12 |
louipc |
do you have
libgl? |
| 14:41.57 |
rnkv2 |
still
checking... |
| 14:43.52 |
rnkv2 |
louipc, with
which ebuild it comes? |
| 14:45.23 |
rnkv2 |
mesa
compiled, trying to compile brl-cad |
| 14:46.45 |
louipc |
rnkv2: not
sure. `locate libGL.so` |
| 14:48.16 |
rnkv2 |
usr/lib/libGL.so |
| 14:48.18 |
rnkv2 |
/usr/lib/opengl/xorg-x11/lib/libGL.so |
| 14:48.19 |
rnkv2 |
/usr/lib/opengl/xorg-x11/lib/libGL.so.1 |
| 14:48.21 |
rnkv2 |
/usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 |
| 14:48.22 |
rnkv2 |
/usr/lib/opengl/nvidia/lib/libGL.so.96.43.11 |
| 14:48.24 |
rnkv2 |
/usr/lib/opengl/nvidia/lib/libGL.so |
| 14:48.25 |
rnkv2 |
/usr/lib/opengl/nvidia/lib/libGL.so.1 |
| 14:51.42 |
rnkv2 |
my brlcad
configuration: http://pastebin.bzflag.bz/d24c9bd9f |
| 15:09.15 |
*** join/#brlcad BigAToo1
(n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 15:20.44 |
rnkv2 |
with new mesa
and libdrm i got exactly the same error |
| 16:13.48 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:37.33 |
rnkv2 |
ok, next
approach - I recompiled xorg-server and nvidia-drivers |
| 16:38.04 |
rnkv2 |
compling
brlcad |
| 17:23.40 |
rnkv2 |
still the
same error |
| 17:28.34 |
jdoliner |
sry I missed
your original msg where you said what the error was |
| 17:28.38 |
jdoliner |
ming
repeating? |
| 17:29.00 |
rnkv2 |
sure, let me
paste it again |
| 17:29.17 |
rnkv2 |
here it is:
http://pastebin.bzflag.bz/m25df21 |
| 17:30.07 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-9-84.dclient.hispeed.ch) |
| 17:31.15 |
rnkv2 |
jdoliner, any
idea what is wrong? |
| 17:32.19 |
jdoliner |
did autogen
and configure work w/o a hitch? |
| 17:33.42 |
rnkv2 |
tail of my
brl-cad configuration: http://pastebin.bzflag.bz/d24c9bd9f |
| 17:33.58 |
rnkv2 |
what do you
mean by w/o ? |
| 17:34.03 |
jdoliner |
without |
| 17:34.27 |
rnkv2 |
there was
some warnings |
| 17:35.07 |
rnkv2 |
do you want
me to place it all on pastebin? |
| 17:35.40 |
jdoliner |
yeah if you
don't mind |
| 17:35.51 |
rnkv2 |
sure, please
wait |
| 17:38.28 |
jdoliner |
okay I think
you're missing a library |
| 17:38.32 |
jdoliner |
let me figure
out which one it is |
| 17:39.15 |
jdoliner |
what do you
have in the way of opengl? |
| 17:39.48 |
rnkv2 |
could you
rephrase it? |
| 17:41.51 |
jdoliner |
are you using
linux? |
| 17:42.08 |
rnkv2 |
jdoliner, i'm
not native english speaker and I don't get the 'in the way of'
phrase |
| 17:42.09 |
jdoliner |
that's not a
rephrasing |
| 17:42.16 |
rnkv2 |
yes, i'm
using gentoo |
| 17:42.38 |
jdoliner |
k |
| 17:43.41 |
jdoliner |
do the
command: `glxinfo' |
| 17:43.41 |
jdoliner |
and paste me
to output |
| 17:45.08 |
rnkv2 |
here you go:
http://pastebin.bzflag.bz/m6439682e\ |
| 17:45.15 |
rnkv2 |
http://pastebin.bzflag.bz/m6439682e |
| 17:47.37 |
rnkv2 |
and here is a
complete configuration log http://pastebin.bzflag.bz/m6a8a8c0f
(I added all warnings at the end) |
| 17:54.50 |
jdoliner |
okay it looks
like you're missing your gl C bindings |
| 17:55.55 |
jdoliner |
line
411: |
| 17:55.56 |
jdoliner |
checking for
OpenGL library availability... no |
| 17:56.32 |
rnkv2 |
any idea how
I make repair that? |
| 17:56.40 |
jdoliner |
yeah you need
to get mesa |
| 17:56.49 |
jdoliner |
is I think
the best solution |
| 17:57.07 |
jdoliner |
i'm just
checking exactly what it is I have here |
| 17:57.12 |
rnkv2 |
i updated
today to media-libs/mesa-7.5-r2 |
| 17:57.33 |
rnkv2 |
and still
there is a problem |
| 17:58.44 |
jdoliner |
hmm |
| 17:59.16 |
rnkv2 |
i recompiled
after that xorg-server and nvidia-drivers |
| 18:00.13 |
jdoliner |
well I'll
keep looking but let's get sean in here because he know more than
me |
| 18:00.20 |
jdoliner |
brlcad |
| 18:00.31 |
jdoliner |
are you
around someone could use your help |
| 18:13.08 |
rnkv2 |
brb |
| 18:13.16 |
rnkv2 |
reboot |
| 18:13.49 |
jdoliner |
k |
| 18:17.22 |
*** join/#brlcad rnkv2
(n=rnkv2@adqp209.neoplus.adsl.tpnet.pl) |
| 18:17.31 |
rnkv2 |
back |
| 18:19.41 |
jdoliner |
im kind of
out of ideas |
| 18:19.50 |
jdoliner |
sean will be
able to help you for sure |
| 18:21.23 |
rnkv2 |
thanks
jdoliner :) |
| 18:23.02 |
rnkv2 |
i rebooted
and now there is now problem about nvidia in glxinfo |
| 18:24.03 |
rnkv2 |
i cannot wait
to see how this software is working :) |
| 18:28.34 |
brlcad |
rnkv2: you
don't need opengl, what's the issue? |
| 18:28.58 |
brlcad |
it'll work
fine with just X11 bindings |
| 18:29.14 |
rnkv2 |
still the
same error, i cannot finish compilation |
| 18:29.57 |
brlcad |
what's the
error? |
| 18:30.44 |
brlcad |
the gl
errors? |
| 18:30.46 |
rnkv2 |
brlcad,
http://pastebin.bzflag.bz/m25df21 |
| 18:30.57 |
brlcad |
yeah, is this
an svn build? |
| 18:31.03 |
rnkv2 |
yes |
| 18:31.10 |
brlcad |
are you up to
date? |
| 18:31.28 |
brlcad |
svn
up |
| 18:31.29 |
rnkv2 |
i downloaded
it yesterday morning |
| 18:31.57 |
brlcad |
that doesn't
answer the question :) |
| 18:32.08 |
brlcad |
except hint
at "probably not" ;) |
| 18:32.47 |
rnkv2 |
brlcad, so
what are you suggesting? svn export https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
source ? |
| 18:33.09 |
brlcad |
did you
export the first time or checkout? |
| 18:33.16 |
rnkv2 |
export |
| 18:33.19 |
brlcad |
ah, you
shouldn't export |
| 18:33.24 |
brlcad |
not if you're
pulling trunk |
| 18:33.33 |
brlcad |
one of our
new display managers was left enabled for a few hours yesterday,
which uses opengl |
| 18:33.45 |
brlcad |
if you'd just
done a checkout, you could now "svn up" and it'd work |
| 18:33.52 |
brlcad |
now you can
checkout again, though |
| 18:34.15 |
rnkv2 |
ok, i will
checkout it |
| 18:53.35 |
rnkv2 |
now
configuring and compiling |
| 19:02.11 |
brlcad |
suggest
--enable-all |
| 19:02.15 |
brlcad |
but not
critical |
| 19:03.03 |
rnkv2 |
if current
compilation would not work then i will try it |
| 19:03.35 |
rnkv2 |
thank you for
helping :) |
| 19:07.54 |
brlcad |
np |
| 19:10.34 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 19:12.11 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 19:13.45 |
brlcad |
howdy
pacman87 |
| 19:13.54 |
brlcad |
how goes
school? settling in? |
| 19:36.01 |
rnkv2 |
brlcad, the
compilation was successful :) i've got only an error when i tried
to install- 'make install' wants to install some components at
/usr/lib/ (like for example /usr/lib/Tkhtml3.0) - is there a way
to install everything in user space (/home/brlcad) ? |
| 20:12.54 |
starseeker |
rnkv2:
tkhtml3 is a bit of a problem child in that respect |
| 20:13.33 |
starseeker |
on some
platforms it seems those makefiles insist on /usr/lib |
| 20:14.19 |
rnkv2 |
i set now
./configure --prefix=/home/brlcad/usr --exec-prefix=/home/brlcad so
we will see what it will bring |
| 20:14.42 |
brlcad |
did you set
prefix the first time? |
| 20:14.57 |
rnkv2 |
only
--prefix=/home/brlcad/usr |
| 20:15.39 |
brlcad |
then
shouldn't exec-prefix be /home/brlcad/bin already? :) |
| 20:15.55 |
brlcad |
you'll
probably have better luck just editing the Tkhtml
Makefile |
| 20:16.41 |
brlcad |
src/other/tkhtml3/Makefile and
src/other/tkhtml3/src/Makefile .. see if there's a /usr/ or
/usr/lib reference in there |
| 20:17.01 |
rnkv2 |
there was
created /home/brlcad/usr/bin, /home/brlcad/usr/lib etc with the
first configuration |
| 20:17.13 |
rnkv2 |
sure, thanks
for hints |
| 20:20.01 |
rnkv2 |
i run some
other projects in user spaces and it's really convenient when you
need to debug it or clear and try again, and it's also more secure
when the software is working online |
| 20:20.39 |
*** join/#brlcad CIA-37
(n=CIA@208.69.182.149) |
| 20:24.26 |
brlcad |
rnkv2: we
actually default install isolated into /usr/brlcad |
| 20:24.31 |
brlcad |
for that same
reason |
| 20:25.11 |
brlcad |
the /usr/lib
thing is just a tkhtml build file bug of some sort |
| 20:26.33 |
rnkv2 |
brlcad, but
how someone may easily uninstall brl-cad from /usr/brlcad (and
eventual other parts of system) ? |
| 20:39.44 |
CIA-37 |
BRL-CAD:
03n_reed * r35279 10/brlcad/trunk/ (include/vmath.h
src/libdm/dm-rtgl.c): adjusted z-clipping when using
z-buffer |
| 21:12.27 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:14.30 |
CIA-37 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1579 10/wiki/More_Changelog: July 24 |
| 21:15.32 |
CIA-37 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1580 10/wiki/More_Changelog: /* July 7 - Today */ |
| 21:21.34 |
rnkv2 |
brlcad, it
seams that './configure --prefix=/home/brlcad/usr
--exec-prefix=/home/brlcad' did the job. I haven't noticed problems
with tkhtml3 |
| 21:21.53 |
rnkv2 |
i was able to
lunch brl-cad |
| 21:21.56 |
rnkv2 |
:) |
| 21:23.53 |
rnkv2 |
thanks for
all the help you all :) |
| 22:42.51 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 23:11.18 |
*** part/#brlcad rnkv2
(n=rnkv2@adqp209.neoplus.adsl.tpnet.pl) |
| 00:32.06 |
CIA-37 |
BRL-CAD:
03n_reed * r35284 10/brlcad/trunk/src/libdm/dm-rtgl.c: scaling
normals to maintain accurate lighting |
| 01:44.19 |
*** join/#brlcad LarsG
(n=lars@dial208-99.dialup.nus.edu.sg) |
| 01:44.28 |
*** part/#brlcad LarsG
(n=lars@dial208-99.dialup.nus.edu.sg) |
| 02:17.46 |
*** join/#brlcad mike111
(n=mike@cadil21.kaist.ac.kr) |
| 02:18.08 |
mike111 |
hi
all |
| 03:09.08 |
brlcad |
hello |
| 03:15.39 |
mike111 |
hi brclad,
how r u? |
| 03:21.02 |
brlcad |
i'm doing
great |
| 03:21.20 |
brlcad |
at least
better than last week ;) |
| 03:21.30 |
mike111 |
that's good
:) . |
| 03:22.37 |
mike111 |
Does g-stl
accept any other units than mm or inches? |
| 03:22.51 |
Axman6 |
brlcad:
problems last week? |
| 03:36.53 |
brlcad |
mike111: no,
the intent there is really just to provide a metric or standard
file, not really unit support |
| 03:37.11 |
brlcad |
Axman6: no
matter, just issues |
| 03:37.29 |
Axman6 |
well, i hope
they're all sorted :) |
| 03:37.42 |
brlcad |
not yet, but
hopefully |
| 03:37.44 |
mike111 |
I thought so.
I've got a model in meters, but g-stl exports in mm so the model
becomes 1000 larger |
| 03:38.36 |
brlcad |
mike111: you
can set the units in mged before running g-stl and it'll fix
that |
| 03:38.50 |
brlcad |
then set it
back |
| 03:39.31 |
mike111 |
not sure what
you mean. I build the model in m units. |
| 03:39.44 |
brlcad |
I
know |
| 03:39.51 |
brlcad |
i mean if you
open the .g file, type |
| 03:40.15 |
brlcad |
'units mm',
run g-stl, then back to mged and run 'units m' .. it should work
fine |
| 03:41.33 |
mike111 |
if I built
the model in meters and then switch to mm mged doesn't scale the
model to keep the original size (before units changed)? |
| 03:42.15 |
brlcad |
nope |
| 03:42.38 |
brlcad |
the units
command just sets the working units, what you want to work
with |
| 03:43.00 |
mike111 |
but sometimes
it is easier to work with different units on the same
model. |
| 03:43.40 |
brlcad |
exactly why
you can work in mm for a while, switch to 'in' for a particular set
of parts, back to "m", put in in a scene being modeling in "ft",
etc... |
| 03:43.44 |
mike111 |
from what
you're saying I need to convert everything to the same units
otherwise mged will scale the entire model everytime I switch
units |
| 03:43.55 |
brlcad |
no no
no |
| 03:44.13 |
brlcad |
i'm saying
you need to run the "units" command |
| 03:44.14 |
brlcad |
run
it |
| 03:44.17 |
brlcad |
see what it
does |
| 03:44.21 |
brlcad |
it doesn't
scale |
| 03:44.28 |
brlcad |
it just sets
the working units |
| 03:45.24 |
brlcad |
so if you
made a 1000x1000x1000 box with "units mm" (the default) .. then
type "units m", it'll display as 1x1x1 |
| 03:45.50 |
mike111 |
then g-stl
would still convert an object of 1m length to 1000mm
example |
| 03:45.52 |
brlcad |
which is to
say that it didn't scale anything, just changed the working units
such that when asked to display that box (which already exists), it
displays using those working units |
| 03:46.07 |
brlcad |
smacks forehead |
| 03:46.13 |
brlcad |
you're still
not getting it :) |
| 03:46.20 |
brlcad |
set the units
to mm |
| 03:46.31 |
brlcad |
then what you
have is exactly what g-stl is assuming you have |
| 03:46.49 |
brlcad |
no
scaling |
| 03:46.55 |
brlcad |
just
different presentation of values |
| 03:47.33 |
brlcad |
re-read what
I suggested and try it: 'units mm', run g-stl, then back to mged
and run 'units m' |
| 03:47.45 |
mike111 |
sure. I'll
try that later. |
| 03:47.54 |
brlcad |
check the
value of your objects, you'll see they don't change |
| 03:47.59 |
brlcad |
they just
display with whatever units you set |
| 03:48.13 |
mike111 |
another
question: what's the difference between `sca' and
`oscale'? |
| 03:48.15 |
brlcad |
g-stl doesn't
really care about units, it just looks at the value |
| 03:49.30 |
brlcad |
history,
subtle differences -- no practical difference |
| 03:49.51 |
brlcad |
oscale is
intended to be used with object-edit mode, which only applies to
combinations |
| 03:51.56 |
mike111 |
I'm using
`sca' with oed, but the manual also mentions `oscale'. |
| 03:52.55 |
brlcad |
oscale should
go away |
| 03:53.23 |
mike111 |
thanks for
clarifying that. :) |
| 04:27.23 |
*** join/#brlcad MinstrlGypsy
(n=IriX64@bas2-sudbury98-1177593187.dsl.bell.ca) |
| 05:28.29 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 05:28.29 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 05:28.50 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 05:28.50 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 05:28.50 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 08:26.41 |
CIA-37 |
BRL-CAD:
03ralith * r35285 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Fixed
reception of keyboard input. |
| 08:40.49 |
CIA-37 |
BRL-CAD:
03ralith * r35286 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Less
emphatic keyboard focus; no longer breaks everything
else. |
| 08:45.27 |
CIA-37 |
BRL-CAD:
03ralith * r35287 10/rt^3/trunk/src/g3d/MainWindow.cxx: Focus
render area on application startup, making keyboard camera control
work immediately. |
| 08:52.30 |
CIA-37 |
BRL-CAD:
03ralith * r35288 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Reordered
constructor initializers and dropped an argument name to quell
warnings. |
| 08:55.10 |
CIA-37 |
BRL-CAD:
03ralith * r35289 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Dropped unnecessary cruft left over from past
attempts to get the Ogre GL context correctly resized. |
| 09:10.33 |
CIA-37 |
BRL-CAD:
03ralith * r35290 10/rt^3/trunk/src/g3d/ (CameraMode.cxx
CameraMode.h): Replaced broken vertical rotation limits with smooth
wraparound. |
| 09:16.01 |
CIA-37 |
BRL-CAD:
03ralith * r35291 10/rt^3/trunk/src/g3d/CameraModeBlender.cxx:
Added rotation limit fix to CameraModeBlender, including changes to
prevent horizontal rotation overflow. |
| 09:21.12 |
CIA-37 |
BRL-CAD:
03ralith * r35292 10/rt^3/trunk/src/g3d/ (4 files): Applied
rotation limit/overflow fix to CameraModeMGED and cleaned up
earlier tweaks. |
| 09:24.33 |
CIA-37 |
BRL-CAD:
03ralith * r35293 10/rt^3/trunk/src/g3d/CameraMode.cxx: Added a
forgotten but all-important negation that prevents
circularIncrement from becoming incredibly
overenthusiastic. |
| 09:26.31 |
CIA-37 |
BRL-CAD:
03ralith * r35294 10/rt^3/trunk/src/g3d/CameraMode.cxx: Doubled
correctional offsets in circularIncrement to prevent pervasive view
jumping. |
| 09:29.48 |
Ralith |
that's
weird. |
| 09:30.17 |
Ralith |
the view
jumps a ton when vertical rotation crosses Ï/2 |
| 09:39.10 |
Ralith |
+/- pi/2,
that is |
| 09:41.17 |
CIA-37 |
BRL-CAD:
03Briannew220 07http://brlcad.org *
r1583 10/wiki/Main_Page: /* BRL-CAD Wiki */ |
| 09:44.16 |
CIA-37 |
BRL-CAD:
03ralith * r35295 10/rt^3/trunk/src/g3d/CameraMode.cxx: Simplified
some code in the continuing effort to remove the viewjump at a
vertical rotation of +/-pi/2 |
| 09:59.47 |
Ralith |
hm |
| 10:26.09 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 10:26.09 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 10:26.09 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 10:37.58 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 10:37.58 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 11:18.04 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 11:28.58 |
CIA-37 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1584 10/wiki/Main_Page: Bloody spammers :/ |
| 11:31.06 |
d-lo_ |
Mernin
all. |
| 11:40.45 |
d-lo |
Spammer are
stupid. Does anyone really pay attention to spam
anyways? |
| 11:43.52 |
archivist |
yes all the
wiki cleaners |
| 11:44.25 |
archivist |
lock the main
page down |
| 11:45.43 |
archivist |
on my wiki I
protect any spammed pages,to stop the buggers from using the same
page again |
| 11:46.17 |
d-lo |
well, the
brlcad wiki isn't mine to admin :) |
| 11:48.49 |
Ralith |
sup
d-lo! |
| 11:48.53 |
Ralith |
I actually
caught you! |
| 11:48.55 |
Ralith |
:D |
| 11:50.03 |
d-lo |
hides. |
| 11:50.16 |
d-lo |
Thing are
going well I see :) |
| 11:50.29 |
Ralith |
reasonably. |
| 11:50.46 |
Ralith |
it's a shame
the OpenGL embedding thing didn't work out as well as
planned. |
| 11:50.55 |
Ralith |
but,
fortunately, it should be hard to tell the difference. |
| 11:51.09 |
Ralith |
and there is
yet hope for getting it working later on. |
| 11:51.27 |
d-lo |
Perhaps in
time, after a few iterations, you (or someone) will find the key to
making the embedded openGL approach work. |
| 11:51.44 |
Ralith |
I can't work
out what's going on with the camera angle such that it flips around
every time yaw hits +/- pi/2 though :/ |
| 11:52.05 |
Ralith |
cleaned up
mafm's camera code a good bit looking for it, but no luck
yet. |
| 11:52.21 |
d-lo |
I had a
thought this weekend: Since pictures speak a thousand words, why
don't you start dropping a medium-rez SS or two on your wiki status
log ;) |
| 11:52.41 |
Ralith |
yeah, I'll do
that |
| 11:53.00 |
Ralith |
about right
when I get around to catching up on the log messages themselves
>_> |
| 11:53.05 |
d-lo |
as for the
camera, how are you controlling it? |
| 11:53.15 |
Ralith |
I was able to
reuse all mafm's camera control code, fortunately |
| 11:53.28 |
Ralith |
just had to
swap out the OIS related code for its Qt equivalents |
| 11:54.03 |
Ralith |
and just
tonight I fixed keyboard input, so camera control works exactly the
same as in original g3d; three selectable modes which each
interpret kb/mouse input differently. |
| 11:54.04 |
d-lo |
good deal.
But even after that swap, there are still that eqn
problem? |
| 11:54.10 |
Ralith |
eqn? |
| 11:54.14 |
d-lo |
equation |
| 11:54.17 |
Ralith |
O.o |
| 11:54.18 |
Ralith |
wat? |
| 11:54.26 |
d-lo |
<PROTECTED> |
| 11:54.38 |
Ralith |
yeah |
| 11:54.46 |
Ralith |
that's
something that was always in mafm's code |
| 11:55.04 |
d-lo |
so are you
feeding the camera an angle? |
| 11:55.13 |
Ralith |
I thought I
knew what was causing it (there was some arbitrary limits and weird
math and special handling of yaw) but scrapping all that didn't
help. |
| 11:56.02 |
Ralith |
uh, lemme
check the code |
| 11:56.16 |
d-lo |
CameraManager
? |
| 11:56.54 |
Ralith |
no, not using
that |
| 11:56.55 |
Ralith |
CameraMode |
| 11:57.15 |
Ralith |
looks like
we're passing a SceneNode to OgreCamera::setPosition |
| 11:57.47 |
Ralith |
lemme see if
there's a less indirect approach to that. |
| 11:59.36 |
Ralith |
okay, got
something. |
| 11:59.55 |
d-lo |
Side note:
curious. There is a definition for a Vector in the CameraMode
class. Pretty sure thats been defined somewhere in the orge suite.
:) |
| 12:00.06 |
Ralith |
not to
mention in BRL-CAD. |
| 12:00.10 |
Ralith |
it's a low
priority cleanup issue. |
| 12:00.20 |
d-lo |
i figured
:) |
| 12:02.46 |
Ralith |
this is
weird |
| 12:03.05 |
Ralith |
it's like
mafm wasn't expecting the camera to track it's own
position/orientation O.o |
| 12:04.18 |
Ralith |
oh, I think I
see why; rotation *around* a point. |
| 12:04.48 |
d-lo |
are you
referring to the fields inside CameraMode? |
| 12:05.11 |
Ralith |
no, the
complexity of the code from L134-L168 |
| 12:05.45 |
Ralith |
still, I'm
pretty sure there's a cleaner way to do this... |
| 12:07.03 |
d-lo |
ah, okay.
Yeah, the code that is executed once _actionPan is checked against
SimpleVector(0,0,0). |
| 12:07.11 |
d-lo |
*agreed* |
| 12:07.40 |
d-lo |
I think a
breakout of that code into more logical internal functions would
pretty much solve the problem. |
| 12:08.38 |
d-lo |
outside of
the Camera pan issue, how else are things going? |
| 12:08.51 |
Ralith |
I dunno, it's
pretty tempting to rework a good chunk of the class from the
conceptual level |
| 12:09.05 |
Ralith |
get it proper
support for continuous/instantaneous forms of all
movements |
| 12:09.17 |
Ralith |
pretty good;
Qt's a pleasure to work with |
| 12:09.30 |
d-lo |
I say go for
it, depending on how long it will take. |
| 12:09.33 |
Ralith |
I'm pretty
close to strapping mafm's command system into the GUI |
| 12:09.37 |
d-lo |
Qt = goodness
:) |
| 12:09.39 |
Ralith |
shouldn't be
long, unless the math trips me up |
| 12:09.40 |
Ralith |
yeah |
| 12:09.46 |
Ralith |
I didn't have
that high expectations going in |
| 12:09.51 |
Ralith |
but DAMN it
makes things convenient. |
| 12:10.15 |
Ralith |
the UI
designer app's great, too, and cmake's solid support for the whole
stack tops things off nicely. |
| 12:10.37 |
Ralith |
being able to
go from the designer to code and then easily access that code from
the implementation is great. |
| 12:13.29 |
d-lo |
Now, are you
sucking in the UI file through cmake directly? |
| 12:13.33 |
Ralith |
yep |
| 12:13.39 |
d-lo |
nice. |
| 12:13.55 |
Ralith |
you edit the
UI file, cmake notes the edit time change and reruns uic before the
next build. |
| 12:14.03 |
d-lo |
I was messing
around with QT a while ago and the Designer used to have a
'generate code' function... I think they took that out
:/ |
| 12:14.04 |
Ralith |
metaobject
handling is the same. |
| 12:14.12 |
Ralith |
they moved it
into a separate tool |
| 12:14.19 |
Ralith |
now you just
run 'uic blah.ui' |
| 12:14.26 |
Ralith |
and get
ui_blah.h |
| 12:15.32 |
Ralith |
perhaps the
most encouraging part of working with Qt was how easy it seems to
be to create specialized widgets |
| 12:15.44 |
Ralith |
as you
might've noticed, I made the primitive console its own
widget |
| 12:15.53 |
Ralith |
*very*
straightforward |
| 12:16.02 |
Ralith |
and the doc's
are a dream, too. |
| 12:16.07 |
Ralith |
docs're* |
| 12:18.03 |
d-lo |
Good stuff
man. I gotta get workin now :/ Keep up the good work. You've got
good momentum, keep it up :) |
| 12:18.22 |
Ralith |
kk |
| 12:18.27 |
Ralith |
seeya next
time I'm up way too late ^^ |
| 12:18.48 |
d-lo |
hah, late ==
early :) |
| 12:26.52 |
CIA-37 |
BRL-CAD:
03ralith * r35296 10/rt^3/trunk/src/g3d/ (5 files): Initial attempt
at re-integrating command support. Uncertain success. |
| 13:22.46 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 13:49.28 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 14:05.23 |
mafm |
d-lo: the
Vector definition probably it's just a storage of x and y values,
not a full blown class with operations and stuff |
| 14:07.26 |
mafm |
about the
strangeness (180 degree turn) it happens when looking from zenithal
view or something |
| 14:07.52 |
mafm |
due to
something like the value of the function (cos, sin, whatever)
changing sign |
| 14:09.06 |
mafm |
you can add a
simple check to avoid that artifact if you want, but IIRC the
must-have camera modes (mged and blender) were working mostly as
expected |
| 14:09.29 |
mafm |
probably with
some advanced functionality missing |
| 14:09.43 |
mafm |
but well,
it's just a matter of extending it |
| 14:10.12 |
mafm |
other camera
modes (orbital/continuous) were a bonus |
| 14:15.38 |
CIA-37 |
BRL-CAD:
03bob1961 * r35297 10/brlcad/trunk/ (9 files in 4 dirs): These
changes get kill, killall, killtree and killrefs working with undo
in Archer. |
| 14:25.05 |
*** join/#brlcad BigAToo
(n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 14:55.28 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 14:59.14 |
d-lo |
mafm: I
figured that SimpleVector was a 'quick n dirty,' just was wondering
why it hadn't been replaced yet, thats all :) And its a full 3D
vector. |
| 15:02.37 |
CIA-37 |
BRL-CAD:
03irpguardian * r35298
10/brlcad/trunk/src/proc-db/human.c: |
| 15:02.38 |
CIA-37 |
BRL-CAD:
Corrected a problem with bounding boxes being placed on the wrong
side of the body |
| 15:02.40 |
CIA-37 |
BRL-CAD: when
being made. |
| 15:04.50 |
mafm |
d-lo: well
yes, it's 3d, but it's only storage with 1 operation:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/src/g3d/CameraMode.h?revision=35292&view=markup |
| 15:04.59 |
mafm |
not nearly as
complex as Ogre's |
| 15:05.28 |
d-lo |
right :) I
get that :) |
| 15:05.31 |
mafm |
maybe I
hadn't used brlcad includes by then |
| 15:07.01 |
d-lo |
no big deal.
I was just skimming over the code and noticed that. |
| 15:09.03 |
mafm |
what I mean
is that the idea is to have a lightweight way to pass 3 float
coordinates for panning and the like contained in one class
(parameter), instead of having to instantiate a full vector class
with all of the associated operations |
| 15:47.11 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 15:47.58 |
CIA-37 |
BRL-CAD:
03n_reed * r35299 10/brlcad/trunk/ (include/dm-rtgl.h
src/libdm/dm-rtgl.c): sorting points by color for faster OpenGL
drawing |
| 16:43.52 |
CIA-37 |
BRL-CAD:
03IRPGuardian 07http://brlcad.org *
r1585 10/wiki/Main_Page: |
| 16:57.00 |
CIA-37 |
BRL-CAD:
03IRPGuardian 07http://brlcad.org *
r1586 10/wiki/User:IRPGuardian: |
| 16:59.11 |
CIA-37 |
BRL-CAD:
03brlcad * r35300 10/brlcad/trunk/ (5 files in 5 dirs): |
| 16:59.13 |
CIA-37 |
BRL-CAD:
improve the opengl header tests (which were not working correctly
on Mac OS X |
| 16:59.15 |
CIA-37 |
BRL-CAD:
10.4) to go through AC_CHECK_HEADER instead of being custom
AC_COMPILE_IFELSE |
| 16:59.17 |
CIA-37 |
BRL-CAD:
tests. opengl functionality tests occur later on. set GL_CPPFLAGS
instead of |
| 16:59.19 |
CIA-37 |
BRL-CAD:
GL_CFLAGS for the header search paths to be
consistent/pedantic. |
| 17:04.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 17:52.50 |
CIA-37 |
BRL-CAD:
03jdoliner * r35301
10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: Added
functionality to find starting points for curve
intersections |
| 18:04.35 |
CIA-37 |
BRL-CAD:
03bob1961 * r35302 10/brlcad/trunk/src/libged/get_obj_bounds.c:
Fixed a small memory leak. |
| 18:58.59 |
CIA-37 |
BRL-CAD:
03brlcad * r35303 10/brlcad/trunk/TODO: unpush rears its head once
again, now with an sf tracker (2826720 from victor). additional
thought is to allow object creation as part of the unpush in order
to retain matrix-less parents. |
| 19:01.52 |
CIA-37 |
BRL-CAD:
03brlcad * r35304 10/brlcad/trunk/TODO: |
| 19:01.58 |
CIA-37 |
BRL-CAD:
another repeat offender, the ability to really easily
checkpoint/backup a .g |
| 19:02.06 |
CIA-37 |
BRL-CAD: file
while editing it via some sort of archive/backup command. something
near |
| 19:02.14 |
CIA-37 |
BRL-CAD:
equivalent to an external cp file.g
/path/to/backup/dir/file_20100427_021800.g |
| 19:02.18 |
CIA-37 |
BRL-CAD: with
automatic date and timestamping. |
| 19:04.27 |
CIA-37 |
BRL-CAD:
03brlcad * r35305 10/brlcad/trunk/TODO: consider option to
reid/remat/edcodes and potentially others to ignore negative
regions |
| 19:04.37 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 19:27.33 |
CIA-37 |
BRL-CAD:
03brlcad * r35306 10/brlcad/trunk/TODO: add file input support to
mv/mvall commands so you can feed them mapping files. this relates
to sf request 2827957 |
| 19:29.30 |
CIA-37 |
BRL-CAD:
03bob1961 * r35307 10/brlcad/trunk/src/librt/prep.c: The
rt_prep_parallel routine was returning without releasing
RT_SEM_RESULTS in a few places. This was causing a hang in Cliff's
bbsize. |
| 19:31.59 |
CIA-37 |
BRL-CAD:
03starseeker * r35308 10/brlcad/trunk/NEWS: Add Bob's
rt_prep_parallel fix to news file. |
| 19:34.52 |
brlcad |
that's not
exactly a user news line |
| 19:35.25 |
brlcad |
should be
worded from the user's perspective, not the code |
| 19:36.11 |
starseeker |
ok |
| 19:37.26 |
CIA-37 |
BRL-CAD:
03starseeker * r35309 10/brlcad/trunk/NEWS: Tweak news
file. |
| 19:39.20 |
brlcad |
ah, and that
clarifies even more.. :) not a news line |
| 19:39.28 |
brlcad |
pre-release
bug catch |
| 19:42.22 |
starseeker |
so, no news
item? |
| 19:42.33 |
starseeker |
make_bb would
also have triggered it |
| 19:42.57 |
brlcad |
yeah, then
it's a fix for make_bb |
| 19:43.11 |
brlcad |
remember the
last commit comment is the one that gets pulled for the
report |
| 19:43.51 |
CIA-37 |
BRL-CAD:
03starseeker * r35310 10/brlcad/trunk/NEWS: Tweak news file some
more. |
| 19:43.57 |
starseeker |
oh,
whoops |
| 19:43.59 |
brlcad |
ah yeah, the
"expand capabilities" line is another |
| 19:44.37 |
brlcad |
not user
visible until it's released, and that is encompassed by the first
line |
| 19:45.02 |
starseeker |
ok, I'll
clear it |
| 19:45.47 |
CIA-37 |
BRL-CAD:
03starseeker * r35311 10/brlcad/trunk/NEWS: bbsize is already
mentioned as a new command, don't need extra NEWS line. |
| 19:53.48 |
CIA-37 |
BRL-CAD:
03irpguardian * r35312
10/brlcad/trunk/src/proc-db/human.c: |
| 19:53.51 |
CIA-37 |
BRL-CAD:
Human model mostly fits into bounding boxes when in the standing
position now. |
| 19:53.53 |
CIA-37 |
BRL-CAD:
Rotation matrix is still throwing things off when limbs are moved,
causing bounding |
| 19:53.55 |
CIA-37 |
BRL-CAD:
boxes to be rotated around some other point other than the point
center. |
| 20:13.11 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 20:13.11 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 20:13.15 |
CIA-37 |
BRL-CAD:
03erikgreenwald * r35313 10/brlcad/trunk/src/libdm/Makefile.am:
move DM_RTGL_* into the WITH_OPENGL block. |
| 20:23.36 |
Ralith |
mafm: there's
no overhead to additional member functions. |
| 20:24.08 |
Ralith |
you could use
the most advanced linalg class available, and if its data was just
three coords it'd be just as lightweight :P |
| 20:24.38 |
Ralith |
mafm: and
yeah, all the camera modes basically work great; I just want to
have it *completely* working. |
| 20:27.03 |
Ralith |
mafm: and
yeah, it happens precisely on the zenith, or its reflection around
the horizontal plane. Any tips as to *where* the simple check
goes? I've fiddled around in several places to no
avail. |
| 20:59.08 |
CIA-37 |
BRL-CAD:
03n_reed * r35314 10/brlcad/trunk/ (include/dm-rtgl.h
src/libdm/dm-rtgl.c): starting to add support for point
heirarchy |
| 20:59.43 |
brlcad |
ack.. moved
DM_RTGL on me |
| 20:59.48 |
brlcad |
no
wunda |
| 20:59.50 |
``Erik |
mwahaha |
| 21:00.21 |
``Erik |
two of my
primary builders weren't seeing GL, so I was getting slews of
unresolved symbol glEnable() etc |
| 21:01.06 |
brlcad |
he
accidentally committed it enabled for about a day, probably stale
build |
| 21:01.35 |
brlcad |
i just
finished adding a proper --enable-rtgl option for it, was
mid-testing |
| 21:02.00 |
``Erik |
full autogen
cycle didn't pick it up *shrug* but coulda been
stale... |
| 21:02.18 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) |
| 21:02.38 |
``Erik |
has done so much nonproductive bs crap today, was itching to
get a build so he could code again O.o |
| 21:02.55 |
``Erik |
fix email
access, catch up on email, fill out paperwork and forms out the
wazoo, etc |
| 21:09.32 |
``Erik |
mmm, finally,
a good debugging stack. *sigh* |
| 21:12.12 |
Ralith |
brlcad: wait,
where's OpenGL come in on rtgl? |
| 21:12.17 |
Ralith |
I thought it
was just the raytracer? |
| 21:12.32 |
mafm |
Ralith: I
think that when you create an object of type Blah vs Vector3, the
amount of memory that you reserve is different, and things like
that |
| 21:12.44 |
brlcad |
Ralith: it's
both |
| 21:12.51 |
Ralith |
mafm: no, not
if it's just a matter of additional member functions. |
| 21:12.56 |
brlcad |
it uses
raytracing to find the surfaces, then uses opengl to display
them |
| 21:13.00 |
Ralith |
brlcad: oh,
cool! |
| 21:13.15 |
mafm |
in this case
maybe Ogre::Vector3 doesn't inherit from other classes and so on,
but still, you have to include the file and all of it's includes,
and you spend more time compiling every time |
| 21:13.50 |
Ralith |
mafm:
building an include file doesn't take much time, and chances are
it's already included somewhere else anyway. |
| 21:14.09 |
Ralith |
not to say
that you did badly there or anything |
| 21:14.12 |
Ralith |
but just
fyi. |
| 21:14.21 |
Ralith |
brlcad: how
far along is it? |
| 21:14.33 |
brlcad |
pretty far,
it looks awesome |
| 21:14.37 |
Ralith |
:D |
| 21:14.52 |
Ralith |
after SoC I'd
like to have a go at stapling it onto g3d |
| 21:15.08 |
Ralith |
not sure how
it'd be made to interact with ogre, though |
| 21:15.36 |
brlcad |
it'll be a
little tricky, but interesting idea |
| 21:15.47 |
brlcad |
it might be
easier to merely staple libdm into g3d |
| 21:15.54 |
brlcad |
as it is a dm
interface |
| 21:16.10 |
brlcad |
i.e. it'd be
a different 3d view renderer instead of ogre |
| 21:16.17 |
Ralith |
that would be
pretty easy. |
| 21:16.30 |
Ralith |
judging from
past experience wrt. adding new Qt widgets |
| 21:16.53 |
mafm |
well, I
decreased compiling times by more than 50% in many projects (not
mine) just by removing includes |
| 21:16.57 |
mafm |
your mileage
may vary |
| 21:17.29 |
Ralith |
I guess the
challenge would really be how to keep all the displays
sync'd |
| 21:17.41 |
mafm |
http://www.brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/src/g3d/CameraMode.cxx?revision=35295&view=markup
-> the camera thingy is here in vertical rotation,
IIRC |
| 21:17.41 |
Ralith |
such that you
can swap from one to another and still have all the same stuff
visible, same perspective, etc. |
| 21:17.56 |
Ralith |
mafm: yeah, I
know it's in there, but *where* in there? |
| 21:17.58 |
brlcad |
Ralith: you
wouldn't use ogre, you'd use libdm instead of ogre |
| 21:18.02 |
brlcad |
different
render manager |
| 21:18.03 |
mafm |
when passing
some limit pi/2, or 0, or something like that |
| 21:18.03 |
Ralith |
brlcad: yes,
I know |
| 21:18.24 |
Ralith |
wait |
| 21:18.39 |
Ralith |
brlcad: so to
get Ogre, I'd just write a libdm interface for Ogre? |
| 21:18.54 |
Ralith |
mafm: no, I
already scrapped all that with some code that handles overflow and
wraps properly. |
| 21:20.17 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:21.15 |
mafm |
c
(3.141592/2.0+0.01) |
| 21:21.17 |
mafm |
-.008 |
| 21:21.18 |
mafm |
c
(3.141592/2.0-0.01) |
| 21:21.20 |
mafm |
.011 |
| 21:21.31 |
Ralith |
? |
| 21:21.36 |
mafm |
I think that
when changes sign, the direction of the vector changes |
| 21:21.46 |
Ralith |
when what
changes sign? |
| 21:21.49 |
Ralith |
the direction
of what vector? |
| 21:21.51 |
mafm |
so it looks
backwards instead of forwar |
| 21:22.05 |
brlcad |
Ralith: you
still seem to be missing the "libdm instead of ogre" part
;) |
| 21:22.14 |
Ralith |
brlcad: so,
scrapping Ogre entirely? |
| 21:22.19 |
brlcad |
not
scrapping |
| 21:22.32 |
Ralith |
you were
regaling me the other day with how valuable Ogre's optimizations
would be O.o |
| 21:22.33 |
brlcad |
i'm saying
you could make it a build-time option to use libdm or use
ogre |
| 21:22.37 |
Ralith |
oh. |
| 21:22.39 |
Ralith |
that's no fun
:P |
| 21:22.41 |
brlcad |
if you use
libdm, you got classic mged displays |
| 21:22.48 |
Ralith |
rtgl's no
classic display |
| 21:22.49 |
brlcad |
if you use
ogre, you get the new stuff |
| 21:23.04 |
brlcad |
it is in the
sense that it's just another libdm interface |
| 21:23.09 |
brlcad |
you do one,
you have them all |
| 21:23.13 |
brlcad |
it's a pretty
simple interface |
| 21:23.20 |
mafm |
Ralith: do
you understand how the camera mode class works, in
general? |
| 21:23.28 |
Ralith |
brlcad: I
guess a compiletime option would be acceptable until the BREP-based
solution shows up, then? |
| 21:23.35 |
Ralith |
which could
be integrated with Ogre properly? |
| 21:23.41 |
Ralith |
mafm: I'm
pretty sure I do |
| 21:23.48 |
brlcad |
Ralith: you
could certainly integrate what's there with ogre |
| 21:23.55 |
brlcad |
it just is
kinda funky that way |
| 21:24.07 |
Ralith |
brlcad: I
could? Ogre doesn't seem to take well to manual OpenGL
calls. |
| 21:24.19 |
mafm |
the camera is
in some point in an sphere of variable radius around the
target |
| 21:24.25 |
brlcad |
so don't make
manual opengl calls .. and I think that was more something you were
doing wrong :) |
| 21:24.48 |
Ralith |
probably, but
the point stands that it's outside what Ogre's designed to
accept. |
| 21:25.09 |
mafm |
<PROTECTED> |
| 21:25.20 |
brlcad |
it's not,
ogre has point-cloud visualization -- just don't know if it'd
perform nearly as well as what it's doing by hand |
| 21:25.35 |
brlcad |
it basically
is just a massive point cloud getting generated |
| 21:25.46 |
Ralith |
it doesn't
wrap a surface around it? |
| 21:25.55 |
brlcad |
still, it'd
be way more useful to integrate libdm instead of ogre, even better
to have both run-time toggleable |
| 21:26.12 |
Ralith |
that's what I
was thinking of originally :P |
| 21:26.24 |
brlcad |
that's not
what you said |
| 21:26.27 |
Ralith |
it would
probably be pretty easy to do so, if, as I mentioned, the state
tracking could be worked out. |
| 21:26.32 |
brlcad |
that doesn't
involve putting libdm *into* ogre still |
| 21:26.47 |
brlcad |
it doesn't
involve ogre at all really, just swaps between one or the
other |
| 21:26.47 |
Ralith |
that's also
not what I said :P |
| 21:27.00 |
brlcad |
17:18 <
Ralith> brlcad: so to get Ogre, I'd just write a libdm interface
for Ogre? |
| 21:27.11 |
Ralith |
brlcad: as
in, have Ogre be a libdm *client* |
| 21:27.18 |
Ralith |
in the same
position as rtgl. |
| 21:27.32 |
Ralith |
but I was
actually referring to before that confusion. |
| 21:27.41 |
brlcad |
that would
defeat most of the benefits ogre brings to the table |
| 21:27.46 |
Ralith |
ah. |
| 21:28.26 |
brlcad |
it'd work
fine if you had some concept of an abstract graphics display class
with one specialization using ogre and another using
libdm |
| 21:28.40 |
*** join/#brlcad Patmcc19_
(n=chatzill@71-223-63-106.phnx.qwest.net) |
| 21:28.57 |
Ralith |
yeah |
| 21:29.00 |
Ralith |
thus that
being where the work lies. |
| 21:36.27 |
Ralith |
brlcad: how
far along is the brep stuff, anyway? |
| 21:41.50 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 21:44.26 |
Ralith |
pokes mafm |
| 21:45.10 |
Ralith |
mafm: calling
lookAt gives the camera a set of coordinates; negative values just
mean negative coords. |
| 21:45.13 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:45.32 |
Ralith |
mafm: the
place the camera's looking at shouldn't even modified by the
yaw. |
| 21:46.41 |
Ralith |
and if the
camera was looking backwards, it wouldn't be able to see the object
:P |
| 21:47.05 |
mafm |
I never
managed to grasp the meaning of yaw, etc |
| 21:47.13 |
mafm |
but imagine
that your head is the camera |
| 21:47.46 |
mafm |
when you're
behind an object almost at the zenith, and you cross the zenith,
your head would be heading downwards |
| 21:48.48 |
mafm |
what this
camera/head does is to rotate, so your head is always
up |
| 21:48.48 |
CIA-37 |
BRL-CAD:
03ralith * r35315 10/rt^3/trunk/src/g3d/ (CameraMode.cxx
Console.cxx Console.h): Another apparently effectless
simplification of CameraMode and failed attempt to enable console
signalling. |
| 21:48.48 |
Ralith |
mafm:
ahhhh. |
| 21:48.48 |
Ralith |
that makes
sense! |
| 21:48.48 |
Ralith |
thanks. |
| 21:48.48 |
Ralith |
it modifies
the roll. |
| 21:48.48 |
mafm |
when you pass
the zenith you rotate, so the head continues to be "upright"
instead of heading downwards |
| 21:48.58 |
Ralith |
I guess...
that's actually desired behavior then, isn't it O.o |
| 21:49.20 |
mafm |
it was,
yes |
| 21:49.28 |
Ralith |
not always,
though |
| 21:49.32 |
Ralith |
it's
certainly not how blender handles things |
| 21:49.36 |
mafm |
the orbital
mode was "invented" by me, didn't try to emulate any other
program |
| 21:49.44 |
Ralith |
this isn't
orbital mode |
| 21:49.46 |
Ralith |
this is *all*
modes |
| 21:50.04 |
Ralith |
(I do love
how smooth the view moves in orbital, though ^^) |
| 21:50.31 |
mafm |
well, let's
say that I started with orbital since it's the more
comprehensive |
| 21:50.39 |
Ralith |
nods |
| 21:50.45 |
Ralith |
I'll twiddle
things and see where it goes |
| 21:50.46 |
mafm |
I didn't care
of that weird thing at that point |
| 21:51.02 |
mafm |
but it turns
out that it's a bit strange when happens for the rest of the
modes |
| 21:51.06 |
Ralith |
now that I
understand *why* it's doing that, at least conceptually, I should
be able to ferret it out. |
| 21:51.28 |
mafm |
I mean, it's
not designed to be specifically at that way, just that I didn't
bothered changing it |
| 21:51.32 |
Ralith |
yeah |
| 21:52.56 |
mafm |
and IIRC was
in one of the parameters of rotation (horz or vert) in the
transition at the zenith |
| 21:53.10 |
Ralith |
parameters of
rotation? |
| 21:53.45 |
mafm |
horzRot,
vertRot |
| 21:54.09 |
mafm |
the variables
which hold the position of the camera, having center as
base |
| 21:54.36 |
Ralith |
those are
floats; they don't have parameters... |
| 21:55.31 |
mafm |
well, the
right word for you would be "orbital/spherical coordinates",
instead of parameters :D |
| 21:55.41 |
CIA-37 |
BRL-CAD:
03ralith * r35316 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h):
Working command input! :D |
| 21:55.52 |
Ralith |
mafm: oh, you
mean "it occurs when vertRot passes the zenith?" |
| 21:55.56 |
Ralith |
yeah, I
noticed that |
| 21:55.57 |
Ralith |
that
is |
| 21:56.01 |
Ralith |
I noticed the
magic value |
| 21:56.05 |
Ralith |
didn't
realize its significance |
| 21:56.46 |
mafm |
yes,
something like that |
| 21:57.22 |
mafm |
so the check
would be to detect the transition and modify the resulting
value |
| 21:57.59 |
mafm |
"when Blah
was almost at zenith in past frame and now is past zenith, do
whatever" |
| 21:58.55 |
Ralith |
well, that
would have to refer to M_PI |
| 21:59.08 |
mafm |
maybe you
don't have to save state between frames, just compare if the past
value of the variable plus delta is bigger than 2*pi, or
so |
| 21:59.24 |
Ralith |
and the only
remaining references to M_PI are ones I've already vetted
:/ |
| 22:08.19 |
mafm |
I think that
part of the problem is that some coordinate varies between 0 and
pi, another between -pi and pi |
| 22:08.22 |
mafm |
http://en.wikipedia.org/wiki/Spherical_coordinates#Definition |
| 22:08.23 |
CIA-37 |
BRL-CAD:
03irpguardian * r35317 10/brlcad/trunk/src/proc-db/human.c: Added
shoulder joints to bounding box list, giving a (nearly) fully boxed
model when standing. |
| 22:08.56 |
Ralith |
mafm: as far
as I can see, I've standardized everything to +/-pi |
| 22:10.13 |
mafm |
I can't
really remember the specifics |
| 22:10.26 |
Ralith |
no worries,
I'll work it out |
| 22:10.32 |
mafm |
:) |
| 22:10.38 |
Ralith |
while you're
hereâ |
| 22:10.59 |
CIA-37 |
BRL-CAD:
03ralith * r35318 10/rt^3/trunk/src/g3d/Console.cxx: Added history
to the console. |
| 22:11.14 |
Ralith |
where does
the text output used in the original console come from? |
| 22:11.20 |
Ralith |
it looks like
logger output |
| 22:12.13 |
Ralith |
hm. looks
like Logger::attach |
| 22:12.37 |
Ralith |
which is
ObserverSubject::attach? |
| 22:12.52 |
Ralith |
yep |
| 22:14.47 |
mafm |
the console
was observing the log, yep |
| 22:14.56 |
mafm |
so you can
see things in both places |
| 22:15.17 |
Ralith |
kk,
cool |
| 22:32.50 |
Ralith |
argh |
| 22:32.55 |
Ralith |
I hate
iterating over STL containers holding const values |
| 22:32.58 |
Ralith |
I can never
get it right :| |
| 22:46.32 |
CIA-37 |
BRL-CAD:
03brlcad * r35319 10/brlcad/trunk/ (configure.ac
src/libdm/Makefile.am src/mged/Makefile.am): (log message
trimmed) |
| 22:46.35 |
CIA-37 |
BRL-CAD: add
a proper --enable-rtgl flag to configure that will
enable/disable |
| 22:46.39 |
CIA-37 |
BRL-CAD:
compilation of the new rtgl dm interface. it's still tied to opengl
(which is |
| 22:46.41 |
CIA-37 |
BRL-CAD:
presently defaulted off), so you have to specify --with-opengl
too. |
| 22:46.45 |
CIA-37 |
BRL-CAD:
intentionally did not assign aliases or add to enable-all as a)
it's still under |
| 22:46.49 |
CIA-37 |
BRL-CAD:
development, b) it needs more work at least to not hang drawing,
and c) there |
| 22:46.53 |
CIA-37 |
BRL-CAD:
still needs to be a way to turn all the dm/fb's on/off consistently
with |
| 22:57.24 |
CIA-37 |
BRL-CAD:
03ralith * r35320 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h
OgreGLWidget.cxx): Working, but backwards, log messages in console
output. |
| 22:59.55 |
CIA-37 |
BRL-CAD:
03ralith * r35321 10/rt^3/trunk/src/g3d/Console.cxx: Flipped
console message ordering the right way around. |
| 23:02.07 |
Ralith |
woo |
| 23:02.11 |
Ralith |
fully
functional console :D |
| 23:16.44 |
``Erik |
surprisingly
easy, huh? |
| 23:21.24 |
CIA-37 |
BRL-CAD:
03ralith * r35322 10/rt^3/trunk/src/g3d/ (7 files): Dropped some
no-longer-relevant code held over from RBGui usage. |
| 23:22.22 |
Ralith |
``Erik: yep;
mafm's existing command/logging stuff was put together solidly, and
Qt is, too, so it was pretty straightforward to glue them
together. |
| 23:25.50 |
Ralith |
G3D has now
been completely uncrufted :D |
| 23:25.58 |
``Erik |
completely?
O.o |
| 23:26.00 |
Ralith |
oh
wait |
| 23:26.01 |
Ralith |
not
quite |
| 23:26.40 |
Ralith |
there we
go. |
| 23:26.48 |
Ralith |
NOW it's been
fully uncrufted. |
| 23:27.05 |
CIA-37 |
BRL-CAD:
03ralith * r35323 10/rt^3/trunk/src/g3d/ (14 files): Dropped
remaining RBGui code and cleaned out CMakeLists. |
| 23:27.07 |
Ralith |
^^ |
| 23:34.28 |
CIA-37 |
BRL-CAD:
03ralith * r35324 10/rt^3/trunk/src/g3d/Commands.h: Removed command
reliant on outdated code. |
| 23:45.25 |
CIA-37 |
BRL-CAD:
03ralith * r35325 10/rt^3/trunk/src/g3d/MainWindow.cxx: Wired the
dropdown setting change signal to the ogreView's setFocus slot so
the user doesn't have to keep clicking on the render
area. |
| 01:21.14 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 01:59.54 |
*** join/#brlcad keltor
(n=keltor@unaffiliated/keltor) |
| 02:00.23 |
keltor |
hello - are
there any good autocad->mged tutorials? |
| 02:06.59 |
brlcad |
keltor: there
is a pretty extensive mged tutorial series on the
website |
| 02:07.35 |
brlcad |
they start
from the ground up and demonstrate basic 3D creation and editing
techniques |
| 02:08.16 |
keltor |
yeah i've
been reading it - i think i'm probably just impatient since i'm an
autocad user since like 1988 |
| 02:10.05 |
brlcad |
keltor: as
autocad is fairly grounded in a 2D centric approach and drafting
operations at heart, you'll find a lot of differences |
| 02:10.56 |
brlcad |
we're more in
line with the likes of catia, unigraphics/nx, solidworks with a
fundamentally 3D-based approach |
| 02:11.28 |
brlcad |
brl-cad does
have 2D facilities, but nowhere near on par with autocad,
particularly for drafting purposes |
| 02:12.11 |
brlcad |
2D sketch
objects and drafting-style hidden line drawings/renderings are
about as close as we get to that domain |
| 02:12.17 |
keltor |
i'm very ok
with solidworks actually (as well as using inventor rather
often) |
| 02:12.31 |
keltor |
in college
that was the 3d cad of choice |
| 02:12.46 |
brlcad |
http://brlcad.org/w/images/4/44/Industry_Diagram.pdf
covers the gist of where we're at |
| 02:13.21 |
brlcad |
we're
actively working on expanding to the left, but that's major
long-term effort |
| 02:13.59 |
brlcad |
autocad is a
CADD system, fwiw, to get some bearings |
| 02:15.21 |
brlcad |
the three I
mentioned are more squarely in the larger CAD domain (catia in
particular), but that's still a huge domain and the focus is still
often CAID purposes |
| 02:15.33 |
keltor |
yes I'm
familar, i generally start with autocad for my base mechanicals
designs, then move on to orcad, then proengineer |
| 02:15.40 |
keltor |
then
pspice |
| 02:15.47 |
keltor |
work is never
done ... |
| 02:42.33 |
brlcad |
heh, quite a
fleet of licensing.. |
| 02:44.57 |
louipc |
hahah |
| 02:45.28 |
louipc |
yep small
shops can't compete, so they pirate :P |
| 02:54.41 |
keltor |
very
true |
| 02:54.59 |
keltor |
i'm fairly
sure we license it all legally |
| 02:55.02 |
keltor |
lol |
| 02:55.17 |
keltor |
in some of
the cases they are licensing patents from us so ... |
| 08:37.20 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 08:37.20 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code
code, type type, commit frequently while you work! update wiki/blog
on daily progress. |
| 08:38.14 |
CIA-79 |
BRL-CAD:
03ralith * r35359 10/rt^3/trunk/src/g3d/ (6 files): First attempt
at reinstalling the GUI. Not quite what we want yet, but awesome
nevertheless. |
| 08:41.44 |
Ralith |
hehe |
| 08:48.48 |
CIA-79 |
BRL-CAD:
03ralith * r35360 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Removed the last of the flickering. |
| 08:49.59 |
Ralith |
If anyone
wants to see something neat, how would be a great time to check out
g3d |
| 09:02.44 |
CIA-79 |
BRL-CAD:
03ralith * r35361 10/rt^3/trunk/src/g3d/ (MainWindow.cxx
MainWindow.h): Restored widget layout. |
| 09:06.18 |
CIA-79 |
BRL-CAD:
03ralith * r35362 10/rt^3/trunk/src/g3d/Console.cxx: Made event
filtering better behaved. |
| 09:48.19 |
CIA-79 |
BRL-CAD:
03ralith * r35363 10/rt^3/trunk/src/g3d/Console.cxx: Flipped the
event filters the right way around. Not sure how it managed to work
originally. |
| 09:52.35 |
CIA-79 |
BRL-CAD:
03ralith * r35364 10/rt^3/trunk/src/g3d/OgreGLWidget.h: Undefined
some dangerous stuff brought in from GLX. |
| 10:48.26 |
CIA-79 |
BRL-CAD:
03ralith * r35365 10/rt^3/trunk/src/g3d/ (6 files): Partially
restored camera controls. |
| 11:18.24 |
CIA-79 |
BRL-CAD:
03d_rossberg * r35366 10/rt^3/trunk/ (2 files in 2 dirs):
typing |
| 12:33.16 |
*** join/#brlcad mafm_
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 12:47.57 |
brlcad |
Ralith:
awesome, can't wait to see it |
| 12:48.30 |
Ralith |
brlcad:
actually, bad news |
| 12:48.37 |
Ralith |
it turns out
this approach massively rapes performance. |
| 12:49.11 |
Ralith |
relies on
glX/wglMakeCurrent which apparently sucks hugely. |
| 12:50.23 |
Ralith |
frustrating;
I just spent all day making it work >:| |
| 12:51.02 |
Ralith |
I'm presuming
that performance is going to matter on typically large models, so
I'm going to go back and try some other approaches |
| 12:51.15 |
Ralith |
I (finally!)
got in contact with some knowledgable qt guys and got some
suggestions. |
| 12:51.21 |
brlcad |
rapes
performance in what regard? |
| 12:52.03 |
Ralith |
the 70% CPU
on idle regard. |
| 12:52.21 |
brlcad |
one thing to
keep in mind with regards to performance, one thing that will
eventually have to be changed is a no-refresh idle loop |
| 12:52.34 |
brlcad |
so that you
only refresh the display when it's invalidated/changed |
| 12:52.42 |
brlcad |
not XX frames
per second all the time |
| 12:52.49 |
Ralith |
I'm told it
might actually copy the entire GPU memory into and out of system
memory each flip. |
| 12:52.57 |
Ralith |
brlcad: okay,
that's actually easy. |
| 12:53.00 |
Ralith |
that's Qt's
default >_> |
| 12:53.12 |
Ralith |
just gotta
wire up the camera controls so they let Qt know that it needs
redrawing |
| 12:53.49 |
Ralith |
will try to
get the OpenGL thing fixed properly before that,
though. |
| 12:53.56 |
brlcad |
k |
| 12:54.51 |
Ralith |
I'm correct
in considering this kind of performance unacceptable,
right? |
| 12:55.24 |
brlcad |
copying all
GPU memory on each frame, .. yeah :) |
| 12:55.32 |
Ralith |
heh |
| 12:55.35 |
Ralith |
kk |
| 12:55.46 |
Ralith |
you might
want to play around with the current revision anyway |
| 12:55.48 |
Ralith |
it's very
pretty |
| 12:56.01 |
Ralith |
although
somewhat impractical due to a bug I hadn't gotten around to
squashing before discovering the issue |
| 12:56.01 |
brlcad |
screenshot? |
| 12:56.04 |
Ralith |
okie |
| 12:56.47 |
brlcad |
if you can
have something stabilized before tuesday, I can give a demo or show
screenshots at siggraph |
| 12:57.06 |
Ralith |
ooo! |
| 12:57.19 |
Ralith |
I'll see what
I can do |
| 12:59.10 |
Ralith |
brlcad:
http://isitloadedyet.com/~ralith/pretty.png |
| 12:59.37 |
Ralith |
with a medium
gray background color that might actually be somewhat
practical. |
| 13:00.44 |
brlcad |
awesome!
:) |
| 13:00.49 |
brlcad |
that is
looking good |
| 13:00.58 |
Ralith |
^^ |
| 13:01.16 |
brlcad |
~Ralith++ |
| 13:01.37 |
Ralith |
when I
eventually get back to this point I'll put some background color on
the widgets for the sake of reliable text readability,
though |
| 13:02.03 |
Ralith |
as cool
looking as fully transparent backgrounds are, I can see it being a
real pain on, say, lit models with both dark and light
areas |
| 13:07.57 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 13:27.52 |
*** join/#brlcad docelic
(n=docelic@78.134.206.105) |
| 13:31.57 |
*** join/#brlcad BigAToo
(n=BigAToo@208.95.141.188) |
| 13:34.31 |
*** join/#brlcad BigAToo
(n=BigAToo@208.95.141.188) |
| 13:49.20 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 13:54.53 |
starseeker |
Ralith: yeah,
semi-transparent is usually the way to go |
| 13:55.36 |
louipc |
hmm!
neat |
| 14:00.04 |
starseeker |
Ralith: you
might jump into that thread and ask if those folks are seeing the
same performance hit |
| 14:00.23 |
starseeker |
Marseyeah
seems responsive |
| 14:01.08 |
elena |
hi
starseeker. |
| 14:01.13 |
starseeker |
hey
elena |
| 14:01.17 |
starseeker |
how goes
it? |
| 14:01.18 |
elena |
how are
you? |
| 14:01.23 |
elena |
very
good! |
| 14:01.41 |
elena |
except i'm
upset with g-vrml. |
| 14:01.46 |
elena |
it's very
slow. |
| 14:01.51 |
starseeker |
can't say he's surprised |
| 14:02.16 |
elena |
i try to
convert the havoc example and it's running for 45mins and hasn't
stop |
| 14:02.19 |
brlcad |
most of the
tessellating exporters are very slow, and may not even successfully
complete |
| 14:02.40 |
elena |
:( |
| 14:02.49 |
elena |
that takes
out one of the features. |
| 14:02.53 |
elena |
of the
site. |
| 14:02.58 |
brlcad |
hm, that's
pretty long, even for havoc |
| 14:03.04 |
elena |
i finished
rendering and conversion code. |
| 14:03.24 |
elena |
you can
upload a bunch of formats and they get converted to g |
| 14:03.27 |
brlcad |
i don't see a
g-vrml running on .bz, was this local? |
| 14:03.42 |
elena |
then they get
rendered and they you can convert to other formats too |
| 14:03.46 |
brlcad |
cool |
| 14:04.00 |
brlcad |
there does
need to be some sort of awareness of the underlying geometry
type |
| 14:04.03 |
elena |
so i enabled
vrml conversion. ppl with vrml plugins can see what they will
get |
| 14:04.12 |
elena |
before
downloading brlcad + model. |
| 14:04.18 |
brlcad |
so when you
convert, you can determine whether it was faithful or
lossy |
| 14:04.56 |
elena |
i'd say it's
almost always lossy. |
| 14:05.06 |
elena |
but the
original file is always available. |
| 14:05.07 |
brlcad |
e.g., g-vrml
of havoc is lossy because it's going from primitives with CSG
boolean operations to an evaluated polygonal mesh
format |
| 14:05.19 |
brlcad |
right, most
are lossy, but some aren't |
| 14:05.40 |
brlcad |
if havoc were
a polygonal mesh to start with, then g-vrml would have been
lossless |
| 14:05.54 |
elena |
btw, should i
put the code on the old server, or the new one? |
| 14:06.13 |
elena |
how can I
tell what type is it? |
| 14:06.42 |
brlcad |
that's a good
question |
| 14:06.48 |
elena |
oh, btw, I'm
thrilled about the raytracing stuff. |
| 14:07.13 |
brlcad |
some you know
what type it is simply by the file format, because some file
formats only support one type |
| 14:07.16 |
elena |
I create a
file with matrices and commands for rt for all the raytracings and
then with a single rt command i get all the images. |
| 14:07.30 |
elena |
so i don't
have to start it each time for each image. |
| 14:07.54 |
brlcad |
e.g., stl,
vrml, ply are all evaluated polygonal/triangle mesh explicit
boundary representation formats |
| 14:08.13 |
brlcad |
woot, way to
use rt scripting :) |
| 14:08.28 |
elena |
however, I
have one question. |
| 14:08.40 |
elena |
i've noticed
that I have to do units mm |
| 14:09.00 |
elena |
or the values
in saveview will not match the values from the view
command. |
| 14:09.12 |
elena |
but there is
still a small difference between them. |
| 14:09.19 |
elena |
if i say
saveview |
| 14:09.42 |
elena |
i'll get in
the file something like eye_pt 1000 1000 1000 let's
say. |
| 14:09.59 |
elena |
but if I do
view eye in mged i'll get something less |
| 14:10.04 |
elena |
like 950 950
950 |
| 14:10.10 |
brlcad |
hum |
| 14:10.17 |
elena |
i can provide
a real example if you want. |
| 14:10.19 |
brlcad |
sounds like
unexpected behavior to say the least |
| 14:10.24 |
brlcad |
possibly a
bug |
| 14:10.36 |
elena |
ah.
ok. |
| 14:11.15 |
elena |
it's not a
big difference, and the images look the same. I was just curios
where could the difference came from. |
| 14:11.20 |
CIA-79 |
BRL-CAD:
03bob1961 * r35367
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Tweak
dbExpand in ArcherCore. |
| 14:11.53 |
elena |
initially, i
had cm units and besides the value diference there was also a 10x
difference. |
| 14:12.19 |
elena |
g-vrml still
working on havoc. 53mins. |
| 14:12.37 |
elena |
and 13mb
written. :( |
| 14:16.37 |
CIA-79 |
BRL-CAD:
03bob1961 * r35368
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added a
createWrapper and modified "make" and "cp" to call it. Also brought
the "in" command into the undo framework. |
| 14:16.59 |
brlcad |
see if it
completes, it may |
| 14:17.05 |
elena |
at this poin,
user will probably want to download the much slower g file
:) |
| 14:17.11 |
elena |
slower =>
smaller. |
| 14:18.03 |
brlcad |
another thing
to consider given it takes that long is that you could queue up
conversions to happen idlely in the background when a geometry is
uploaded, so once you have the vrml, you don't have to convert it
again |
| 14:18.32 |
elena |
i did
this. |
| 14:18.50 |
elena |
all
convertions and raytracing is done in a queue. |
| 14:18.51 |
brlcad |
otherwise,
you just tell them "thanks for your request .. it's been queued for
processing .. eta [random] hours" :) |
| 14:19.12 |
elena |
the
submission process is not blocked. |
| 14:19.53 |
brlcad |
fwiw, havoc
is particularly expensive to convert because it's fully
CSG |
| 14:19.59 |
brlcad |
there's a lot
of booleans that have to be evaluated |
| 14:20.26 |
elena |
so i picked
the wrong one to mess with :D |
| 14:20.40 |
elena |
the truck.g
was quite fast. |
| 14:20.44 |
elena |
about
10s |
| 14:21.26 |
brlcad |
yeah, truck
is tiny in comparison |
| 14:21.38 |
brlcad |
even havoc is
pretty small compared to a full vehicle |
| 14:22.40 |
elena |
about the web
server? should I start uploading on the current server? |
| 14:29.48 |
brlcad |
wherever
you've been uploading, I'd just keep on there |
| 14:29.59 |
brlcad |
so old is
fine, or new if you already started |
| 14:30.26 |
elena |
ok. old it is
then. |
| 14:33.24 |
*** join/#brlcad BigAToo1
(n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 14:34.08 |
elena |
is there a
doc about the rt commands? |
| 14:34.24 |
elena |
i only know
the ones from the saveview file. |
| 14:35.37 |
brlcad |
mm.. |
| 14:35.39 |
*** join/#brlcad BigAToo2
(n=BigAToo@208.95.141.188) |
| 14:36.02 |
CIA-79 |
BRL-CAD:
03ebautu * r35369
10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/
(7.14.txt generic.txt): New tcl script output format (raytracing is
done outside the script in a separate run). |
| 14:36.30 |
brlcad |
i don't think
so |
| 14:37.32 |
brlcad |
but you can
see the list of commands in
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/rt/do.c?view=markup
around line 1009 |
| 14:37.48 |
elena |
thank
you. |
| 14:39.39 |
CIA-79 |
BRL-CAD:
03ebautu * r35370
10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.inc
brlcad.module): Updated code to raytrace all images with a rt
script (prevents PHP from crashing due to processes overlap).
Updated code for conversion. |
| 14:41.00 |
elena |
ok. then I
know almost half of them. ;) |
| 14:44.49 |
starseeker |
wonders if anyone has attempted to build BRL-CAD on minix
3 |
| 14:47.54 |
CIA-79 |
BRL-CAD:
03ebautu * r35371
10/web/trunk/htdocs/more/sites/all/modules/light_download_count/ (5
files): Lightweight download counter custom made module (works with
private and public downloads) |
| 15:04.59 |
brlcad |
heh, I have a
minix 3 disk sitting right in front of me |
| 15:05.35 |
brlcad |
one of the
minix devs was at the mentor summit and was pretty interested in
getting brl-cad working |
| 15:10.52 |
CIA-79 |
BRL-CAD:
03ebautu * r35372 10/web/trunk/htdocs/more/.htaccess: .htaccess
setup for tracking downloads |
| 15:14.26 |
CIA-79 |
BRL-CAD:
03ebautu * r35373
10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/
(node-model.tpl.php style.css template.php): Custom model
themeing |
| 15:28.16 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 15:33.02 |
CIA-79 |
BRL-CAD:
03brlcad * r35374 10/brlcad/trunk/TODO: |
| 15:33.04 |
CIA-79 |
BRL-CAD: new
tool that reports summary information about a given geometry file
such as |
| 15:33.06 |
CIA-79 |
BRL-CAD:
object types used, classes of geometry representations used, and
more. most |
| 15:33.08 |
CIA-79 |
BRL-CAD:
usefully for the web interface to be able to introspect on a
geometry file to be |
| 15:33.10 |
CIA-79 |
BRL-CAD: able
to classify and compare imported geometry. |
| 15:42.18 |
CIA-79 |
BRL-CAD:
03starseeker * r35375 10/brlcad/trunk/ (14 files in 8 dirs): Rename
bbsize to bb, add -c option to create bounding box, fix NEWS item
to refer to bb not bbsize |
| 16:11.09 |
CIA-79 |
BRL-CAD:
03ebautu * r35376
10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/style.css:
Fixed slogan theme bug. |
| 16:25.32 |
CIA-79 |
BRL-CAD:
03irpguardian * r35377
10/brlcad/trunk/src/proc-db/human.c: |
| 16:25.34 |
CIA-79 |
BRL-CAD:
Added support for individual person regions in the makeArmy
command. |
| 16:25.36 |
CIA-79 |
BRL-CAD: Each
human model's region is numbered in the same manor the parts are
numberd: |
| 16:25.38 |
CIA-79 |
BRL-CAD:
Body.r0.... Body.r12.... etc. |
| 16:32.44 |
CIA-79 |
BRL-CAD:
03starseeker * r35378 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: Print
out some more type identifications to get a better idea of what
exactly is contained in the 3dm m_object_table. |
| 16:47.22 |
CIA-79 |
BRL-CAD:
03jdoliner * r35379
10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: Implemented
surfacesurfaceintersect which facilitates finding starting points
of intersection, walking intersections and removing starting points
once they've been crossed. |
| 16:48.04 |
elena |
g-vrml took
about 4h on havoc |
| 16:50.57 |
starseeker |
how does the
result look? |
| 16:51.09 |
elena |
40mb
files. |
| 16:51.11 |
starseeker |
is actually a bit surprised it succeeded |
| 16:51.20 |
elena |
my browser
plugin hangs when loading it :) |
| 16:51.21 |
starseeker |
does it
visually resemble havoc? |
| 16:51.25 |
starseeker |
ah |
| 16:51.32 |
elena |
i 'll try
again. |
| 16:51.40 |
elena |
to load
it. |
| 16:51.45 |
louipc |
:O |
| 16:51.52 |
starseeker |
might try a
standalone viewer |
| 16:52.01 |
starseeker |
seeks edibles |
| 16:52.57 |
louipc |
why isn't a
screenshot enough? :P |
| 16:53.05 |
louipc |
err a small
render |
| 16:53.17 |
elena |
it is. i was
just curios how long it will take. |
| 16:53.19 |
louipc |
or a few
small renders |
| 16:53.21 |
louipc |
ah
ok |
| 16:53.43 |
louipc |
it bugs me
how every application is being thrown onto the web these days
:P |
| 16:54.23 |
starseeker |
is old school - don't want my apps in a
browser |
| 16:55.18 |
louipc |
especially
when it comes to flash haha |
| 16:56.09 |
louipc |
hopefully
that'll be disappear as html5 support improves though |
| 16:57.46 |
elena |
i have
freewrl. doesn't seem to handle havoc.vrml very well. |
| 16:58.17 |
CIA-79 |
BRL-CAD:
03irpguardian * r35380
10/brlcad/trunk/src/proc-db/human.c: |
| 16:58.21 |
CIA-79 |
BRL-CAD:
Added individual bounding boxes to makeArmy command. No hollow
region support yet. |
| 16:58.27 |
CIA-79 |
BRL-CAD:
Named as such: Box.r# |
| 17:02.16 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 17:03.43 |
*** join/#brlcad talcite
(n=matthew@206-248-128-129.dsl.teksavvy.com) |
| 17:05.48 |
CIA-79 |
BRL-CAD:
03starseeker * r35381 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: Few
more formatting tweaks in debug output of 3dm-g. Names such as
'(#101029) PIPE' are a problem for e * in MGED - maybe such things
should be 'cleaned up' a little? |
| 17:10.45 |
brlcad |
starseeker:
surprised there's not a polymorphic way to dump/print the types --
should just need a parent type |
| 17:11.11 |
brlcad |
i.e., there
should be a polymorphic way :) |
| 17:14.40 |
starseeker |
brlcad:
probably - I was just doing a quick extension of what Dave had
originally done |
| 17:14.54 |
starseeker |
in the end,
the whole thing will probably go away |
| 17:15.22 |
starseeker |
needs to figure out what to do with
InstanceRef |
| 17:15.38 |
brlcad |
dave was not
adept in c++, so caution |
| 17:15.53 |
starseeker |
ah,
k |
| 17:21.29 |
CIA-79 |
BRL-CAD:
03ebautu * r35382
10/web/trunk/htdocs/more/sites/all/modules/fivestar/ (89 files in
17 dirs): Fivestar update (1.16) - fixed average votes display
bug |
| 17:34.01 |
starseeker |
blinks in surprise as 3dm-g on the openmoko.3dm largely
succeeds this time... |
| 17:34.14 |
starseeker |
aaaaaaand
kills the raytrace by asking for too much memory |
| 17:39.36 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:45.42 |
talcite |
hey
starseeker |
| 17:45.56 |
elena |
hi
talcite |
| 17:46.03 |
talcite |
did you get
my message last night about the macros? |
| 17:46.14 |
talcite |
hi
elena |
| 17:49.02 |
brlcad |
talcite:
thanks for the RFE, think I have a working solution that should
help |
| 17:49.22 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 17:49.22 |
talcite |
brlcad: not a
problem. Thanks for fixing it quickly |
| 17:49.34 |
brlcad |
not
technically a bug, though, fwiw ;) |
| 17:49.52 |
talcite |
brlcad: I
think there might be an issue with fedora's compatibility with the
configure script |
| 17:50.15 |
brlcad |
how
so? |
| 17:50.31 |
talcite |
brlcad: the
macro enabling the include for Xutils.h doesn't get enabled by the
configure script |
| 17:50.51 |
brlcad |
I read a bit
of the log from many hours back -- there are a few options that
should help package configuration/integration |
| 17:51.01 |
talcite |
it's
searching in /usr/X11, but that doesn't exist in fedora |
| 17:51.10 |
brlcad |
the macro --
which macro? |
| 17:51.23 |
brlcad |
we don't do
much X11 testing directly, we rely on automake's tests |
| 17:51.29 |
talcite |
HAVE_X11_XLIB_H |
| 17:51.40 |
brlcad |
that's not a
macro :) |
| 17:51.54 |
talcite |
ahh,
precompiler directive? I never know the proper term for them
heh |
| 17:52.13 |
brlcad |
yeah, that's
a preprocessor define |
| 17:52.30 |
brlcad |
set by
configure when it finds a header |
| 17:53.01 |
talcite |
anyways, the
define doesn't get set by the configure script, and I do have the
header |
| 17:53.36 |
talcite |
it's in
/usr/include/X11, not /usr/X11 |
| 17:53.42 |
louipc |
I don't have
/usr/X11 either |
| 17:53.46 |
talcite |
hmm |
| 17:53.58 |
louipc |
seemed to
work alright for me |
| 17:54.14 |
talcite |
I wonder why
I'm failing this test then |
| 17:54.41 |
talcite |
my bash isn't
great. This configure script is really complex |
| 17:54.46 |
brlcad |
talcite: back
up some .. |
| 17:54.55 |
brlcad |
what is your
goal? |
| 17:55.11 |
talcite |
brlcad: to
compile it first, then to package it from source |
| 17:55.46 |
brlcad |
okay, so then
what is your configure line |
| 17:56.13 |
talcite |
./configure
--disable-jove --with-tclconfig=/usr/lib64/
--with-tkconfig=/usr/lib64/ |
| 17:56.38 |
brlcad |
oof, tcl/tk
overrides are a bear .. |
| 17:56.40 |
brlcad |
okay |
| 17:57.02 |
brlcad |
so that means
it's going to try to autodetect nearly everything else given you're
not using --enable-all or --disable-all |
| 17:57.22 |
talcite |
--enable-all?
hmm |
| 17:57.23 |
brlcad |
so configure
completes presumably, yes? then compile fails at some
point? |
| 17:57.30 |
talcite |
brlcad:
yes |
| 17:57.42 |
talcite |
the
XVisualInfo struct isn't defined |
| 17:57.49 |
talcite |
because
Xutils.h isn't being included |
| 17:58.05 |
brlcad |
so then can
you pastebin up your configure output? |
| 17:58.15 |
talcite |
sure |
| 17:59.12 |
talcite |
brlcad:
http://fpaste.org/paste/20290 |
| 18:07.32 |
brlcad |
hm, looks
like your version of AC_PATH_XTRA is not setting the have_x
variable |
| 18:07.41 |
brlcad |
what's your
version of autoconf? |
| 18:11.22 |
talcite |
brlcad:
2.63 |
| 18:12.08 |
talcite |
brlcad: sorry
I'm not very familiar with AC. I'm not running autoconf am I? I
just ran the configure script |
| 18:12.55 |
brlcad |
autoconf is
run during autoreconf or autogen.sh in order to generate the
configure script |
| 18:13.05 |
brlcad |
that's
probably why - you're using a very recent version |
| 18:13.13 |
brlcad |
they probably
changed the interface slightly |
| 18:13.47 |
talcite |
brlcad: but
I've never run autoreconf or autogen.sh. Should I have? |
| 18:13.49 |
brlcad |
edit
configure.ac and delete the three lines that are wrapped in
have_x |
| 18:13.56 |
brlcad |
oh! |
| 18:14.22 |
talcite |
I just ran
the configure script that was already present in the
tar.bz2 |
| 18:14.28 |
brlcad |
hold on
then.. that could be the issue -- AC_PATH_XTRA needs to be
regenerated for your newer system |
| 18:14.31 |
brlcad |
right |
| 18:14.33 |
talcite |
ahh |
| 18:14.58 |
brlcad |
basically an
autoconf 'bug' for loose definitions of bugs, but a problem
nonetheless |
| 18:15.48 |
brlcad |
the configure
script you generate on one system 'should' work on any other
system, but that's only true 99% of the time as there are bugs and
updates that are required for newer configurations |
| 18:16.00 |
brlcad |
try running
"sh autogen.sh" |
| 18:16.12 |
brlcad |
should take
just a couple minutes |
| 18:16.20 |
brlcad |
then re-run
configure |
| 18:16.40 |
brlcad |
then look for
HAVE_X11 in include/brlcad_config.h |
| 18:16.48 |
talcite |
sounds good.
I'll give that a shot |
| 18:17.02 |
talcite |
thanks for
the help |
| 18:20.32 |
brlcad |
I have a
change that might avoid the problem down the road |
| 18:20.44 |
brlcad |
but will
still be good to know if that fixes it |
| 18:20.59 |
talcite |
brlcad: k.
I'm running configure now |
| 18:22.49 |
CIA-79 |
BRL-CAD:
03brlcad * r35383 10/brlcad/trunk/configure.ac: don't use/assume
have_x will be defined. just do a header test right here. might
need more cppflags logic to search in the dirs we just found from
ac_path_xtra |
| 18:23.20 |
talcite |
brlcad: yup,
it works now |
| 18:23.36 |
brlcad |
cool |
| 18:23.37 |
louipc |
sweet |
| 18:23.41 |
talcite |
I'll try
compiling, but it should work |
| 18:23.53 |
talcite |
yeah, that
was quite the bug =S. I've never run into that before |
| 18:24.05 |
brlcad |
so there's
some magic that 2.63 added in for it to properly detect X11 and set
have_x for your system |
| 18:25.03 |
brlcad |
commit should
hopefully avoid the issue, but all we can do on our end is try to
be sure to use at least 2.63 when generating configure for our
source tarballs |
| 18:25.06 |
brlcad |
come release
time |
| 18:25.32 |
louipc |
when's the
next one planned for? |
| 18:25.36 |
talcite |
what system
do you do the compiling on? |
| 18:26.06 |
brlcad |
louipc: any
day, hopefully before friday |
| 18:26.12 |
louipc |
cool! |
| 18:26.26 |
talcite |
haha should I
wait to do the packaging then? |
| 18:26.30 |
brlcad |
we missed two
iterations unfortunately |
| 18:26.36 |
louipc |
talcite: good
idea :D |
| 18:27.04 |
talcite |
alright. Let
me get the hang of the ogl and optimize builds in the mean
time |
| 18:27.05 |
brlcad |
talcite: heh,
not really -- at best all that should change is the patch number in
your script |
| 18:27.27 |
brlcad |
you don't
really need ogl, don't recommend it for a release
configuration |
| 18:27.33 |
talcite |
ahh
ok |
| 18:27.54 |
brlcad |
it's good on
a per-system basis but there are some systems that have really bad
behavior |
| 18:28.19 |
brlcad |
doesn't limit
functionality or performance on our end, it's just the protocol we
talk in our display management system on the backend |
| 18:28.29 |
talcite |
oh
ok |
| 18:28.31 |
louipc |
I guess the
user should decide what to use then |
| 18:28.37 |
brlcad |
X11 is just
fine (and can actually out-perform in many cases) |
| 18:28.51 |
talcite |
haha well
then no reason to use ogl |
| 18:28.59 |
brlcad |
not
yet |
| 18:29.05 |
louipc |
heheh |
| 18:29.13 |
talcite |
yeah, I heard
Ralith just got Qt embeds working |
| 18:29.15 |
brlcad |
we've got a
dev working on a nice shaded display interface that is really
snazzy |
| 18:29.23 |
brlcad |
and it uses
ogl with ray-tracing |
| 18:29.28 |
talcite |
haha
sweet |
| 18:29.30 |
louipc |
I want to get
mged in the framebuffer :D |
| 18:30.32 |
brlcad |
talcite:
yeah, though that's for longer-term development effort -- new gui
interface that will likely supplant current in 4 years or so
(prototype much earlier than that though) |
| 18:30.59 |
brlcad |
prototype
hopefully before this year's end |
| 18:31.14 |
talcite |
whoa. no
kidding. You're not worried that Qt will deprecate the API
call? |
| 18:31.26 |
brlcad |
not at
all |
| 18:31.47 |
brlcad |
it's under
continuous development -- if they change things we'll be changing
right along |
| 18:32.08 |
talcite |
I
see |
| 18:32.12 |
brlcad |
it'll simply
take that long to bring the interface up to a capability level on
par with mged/archer |
| 18:32.33 |
brlcad |
plan is mged
-> archer -> new gui |
| 18:33.03 |
brlcad |
archer is
about ready to demo now, nearing alpha stage, and will carry the
gui for at least a couple years |
| 18:33.08 |
brlcad |
while the new
one gets worked on |
| 18:33.25 |
talcite |
when do you
think Archer will be released? |
| 18:33.27 |
brlcad |
rolling
updates, can't abandon existing userbase |
| 18:33.47 |
brlcad |
that one
should go full alpha before year's end |
| 18:33.47 |
talcite |
ahh |
| 18:34.06 |
brlcad |
beta later in
the year |
| 18:34.13 |
brlcad |
maybe final
by end of 2010 |
| 18:34.23 |
talcite |
heh you guys
seem to have a pretty strong development timeline |
| 18:34.34 |
brlcad |
around that
time, new gui should be about ready for alpha |
| 18:39.36 |
talcite |
blam. another
build error =D |
| 18:40.12 |
brlcad |
paste? |
| 18:40.28 |
talcite |
coming
up |
| 18:40.35 |
brlcad |
there are a
few known issues with the 7.14.8 build that have since been
fixed |
| 18:40.41 |
talcite |
http://fpaste.org/paste/20296 |
| 18:40.42 |
brlcad |
particularly
with regards to mixed system installs |
| 18:40.46 |
talcite |
it's a java
error |
| 18:41.10 |
brlcad |
wow, that's a
new one |
| 18:41.15 |
talcite |
I hope it's
not because I'm using openJDK instead of sunJava |
| 18:41.43 |
brlcad |
yeah, looks
like some bug in fop or java |
| 18:41.47 |
louipc |
java! |
| 18:41.55 |
louipc |
crazy |
| 18:41.59 |
brlcad |
the good news
is that the build succeeded |
| 18:42.06 |
brlcad |
that part of
the build is generating documentation |
| 18:42.10 |
talcite |
ahh it's just
documentation stuff |
| 18:42.33 |
louipc |
I have
openjdk too |
| 18:42.35 |
talcite |
well that's
minor, but I should probably fix it anyways |
| 18:42.37 |
brlcad |
can add
--disable-documentation to turn it off |
| 18:43.26 |
talcite |
hmm... is the
documentation useful though? |
| 18:43.45 |
louipc |
I didn't get
any pdfs though.. |
| 18:43.49 |
brlcad |
given
xsltproc processed the first xml file just fine, it may be a typo
in build_pattern.xml ( starseeker ) |
| 18:44.01 |
talcite |
haha |
| 18:44.17 |
louipc |
ah I don't
have 'fop' installed |
| 18:44.23 |
brlcad |
ah, my bad ..
it processed the xml fine to html, just not to .fo for
fop |
| 18:44.31 |
brlcad |
so probably
not |
| 18:44.50 |
brlcad |
talcite: does
fop work for you? |
| 18:45.15 |
brlcad |
and of course
the documentation is useful |
| 18:45.17 |
brlcad |
just not
necessary :) |
| 18:45.21 |
talcite |
brlcad: hmm
I've never used fop before |
| 18:45.35 |
talcite |
it seems to
work more or less |
| 18:45.38 |
brlcad |
there are
extensive docs on the website, and other docs that get installed
too |
| 18:46.10 |
brlcad |
dunno what to
say on that one -- looks like an fop issue |
| 18:46.15 |
louipc |
html docs are
good enough |
| 18:46.47 |
brlcad |
could try
running /usr/bin/fop build_pattern.fo -pdf build_pattern.pdf
manually |
| 18:46.58 |
talcite |
yup, that's
my plan so far |
| 18:47.05 |
talcite |
I need to
find it first though |
| 18:47.31 |
brlcad |
doc/docbook/articles/build_pattern/en |
| 18:47.42 |
talcite |
thanks |
| 18:49.16 |
talcite |
nope, same
problem |
| 18:49.54 |
talcite |
wait, there's
something weird |
| 18:50.05 |
talcite |
build_pattern.fo doesn't exist |
| 18:50.26 |
talcite |
[matthew@desktop en]$ pwd |
| 18:50.26 |
talcite |
/home/matthew/Download/brlcad-7.14.8/doc/docbook/articles/build_pattern/en |
| 18:50.26 |
talcite |
[matthew@desktop en]$ ls |
| 18:50.26 |
talcite |
build_pattern.html build_pattern.xml
Makefile Makefile.am Makefile.in |
| 18:51.12 |
talcite |
brlcad: and
I'm getting the same error as the build_pattern.fo
command |
| 18:52.01 |
CIA-79 |
BRL-CAD:
03irpguardian * r35384
10/brlcad/trunk/src/proc-db/human.c: |
| 18:52.03 |
CIA-79 |
BRL-CAD: Made
it where the makeArmy command now places all humans into Crowd.c
combination, for easy access to all |
| 18:52.06 |
CIA-79 |
BRL-CAD:
persons. |
| 18:52.34 |
brlcad |
right, the
.fo is what it generates |
| 18:52.55 |
brlcad |
er, rather --
hmm |
| 18:53.14 |
brlcad |
does this
generate the .fo?
XML_CATALOG_FILES=../../../../../doc/docbook/catalog.xml
/usr/bin/xsltproc -nonet -xinclude -o build_pattern.fo
../../../../../doc/docbook/resources/standard/xsl/fo/docbook.xsl
build_pattern.xml |
| 18:53.43 |
brlcad |
according to
the log, it did |
| 18:55.42 |
talcite |
hmm that's
strange. The file isn't there |
| 18:55.54 |
talcite |
maybe fop
removes the input file? |
| 18:57.40 |
talcite |
hmm no...
well anyways I've created the file, but it still NPEs |
| 18:59.06 |
brlcad |
yeah, sounds
like an fop bug if xsltproc generates it correctly |
| 18:59.16 |
brlcad |
or maybe a
version mismatch between the two |
| 18:59.30 |
brlcad |
or a problem
with java |
| 18:59.40 |
brlcad |
either way,
--disable-documentation :) |
| 19:00.05 |
talcite |
haha I guess
it works temporarily. I'll probably need to get it fixed before the
fedora repo maintainers will allow it for inclusion
though |
| 19:01.12 |
talcite |
lets see if
it's still an issue in the next release |
| 19:09.46 |
brlcad |
hm? you mean
hold up our inclusion because fop doesn't work? that's kinda
silly |
| 19:10.30 |
brlcad |
only thing we
can do on our end is default it to off so you don't need to specify
the disable |
| 19:12.32 |
talcite |
hmm. I guess
I could always just build the documentation package seperately when
fop works again |
| 19:14.52 |
talcite |
is there a
listing of configuration options? |
| 19:15.18 |
brlcad |
INSTALL
file |
| 19:15.29 |
talcite |
thanks |
| 19:15.41 |
louipc |
./configure
--help too |
| 19:18.35 |
talcite |
is there a
reason the debug symbols are enabled by default? |
| 19:20.19 |
brlcad |
yep, for
debuggability, stack traces |
| 19:20.38 |
brlcad |
we have
automatic crash reports that can get generated if something goes
horribly wrong |
| 19:20.43 |
talcite |
brlcad: Is
there a big hit on performance if it's enabled? |
| 19:20.52 |
brlcad |
nope, not at
all |
| 19:20.59 |
talcite |
ahh ok. So I
should leave them in for the package |
| 19:21.13 |
brlcad |
--enable-optimized will give a huge
performance difference |
| 19:21.19 |
brlcad |
nearly 2x on
rendering performance |
| 19:21.26 |
talcite |
yup. I just
set that configure flag |
| 19:21.48 |
brlcad |
it'll also
make compilation take 2x ;) |
| 19:21.55 |
talcite |
brlcad: you
mentioned there's a couple flags that make packaging
easier? |
| 19:21.57 |
talcite |
=/ |
| 19:22.05 |
talcite |
oh well. I'm
working from home today |
| 19:23.24 |
brlcad |
for packaging
systems --disable-almost-everything and then specifically enabling
anything you won't have |
| 19:23.37 |
brlcad |
(like tkhtml3
and tnt) |
| 19:23.43 |
talcite |
oh I
see |
| 19:24.20 |
talcite |
sounds good
to me |
| 19:24.44 |
CIA-79 |
BRL-CAD:
03bob1961 * r35385
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added mirror to
the undo framework. Tweaked killWrapper. |
| 19:25.13 |
brlcad |
wishes bob would push those wrappers down into libged
proper |
| 19:27.16 |
``Erik |
mebbe if you
jerked a couple out from under him, he'd get the idea? |
| 19:27.21 |
CIA-79 |
BRL-CAD:
03ebautu * r35386
10/web/trunk/htdocs/more/sites/all/modules/brlcad/brlcad.module:
Fix metadata editing bug (only editors can edit it now) |
| 19:29.01 |
``Erik |
grumbles a bit |
| 19:33.52 |
talcite |
brlcad: does
--disable-almost-everything also disable the --with-x11
etc? |
| 19:34.08 |
brlcad |
talcite:
no |
| 19:34.26 |
brlcad |
it only
disables the various --disable-*-build options, as listed in
INSTALL |
| 19:34.39 |
talcite |
ahh
ok |
| 19:34.47 |
brlcad |
the with
flags merely specify how/where to find system services |
| 19:35.17 |
louipc |
does it
automatically check for --disable* flags? |
| 19:37.19 |
louipc |
ah ok I see
:D |
| 19:38.19 |
louipc |
oh darn I did
add tkhtml3 in that switch hah |
| 19:43.04 |
talcite |
argh I forgot
to make -j2 =/ |
| 19:44.42 |
starseeker |
just Ctrl-c
and restart |
| 19:44.47 |
starseeker |
it will pick
up where it left off |
| 19:44.59 |
talcite |
ahh
cool |
| 19:45.25 |
talcite |
hmm that's
right. I forgot make can do that |
| 19:47.37 |
talcite |
whoa. I'm
getting 4x performance after --enable-optimized |
| 19:47.43 |
talcite |
cool |
| 19:48.19 |
louipc |
how long did
the build take? |
| 19:49.35 |
brlcad |
talcite: it's
interruptible |
| 19:50.06 |
talcite |
build took
about 30 mins, but only because I forgot to use make -j2
=D |
| 19:51.54 |
louipc |
pretty
quick |
| 19:53.23 |
talcite |
louipc: it's
a fairly powerful system by the standards a couple years ago. Core
2 duo, 2 gigs of ram, |
| 19:53.40 |
louipc |
nice |
| 19:53.49 |
louipc |
takes me 3hr
to build :( |
| 19:53.52 |
talcite |
=o |
| 19:54.11 |
talcite |
why not
upgrade? you can get a much more powerful system than mine for $500
these days |
| 19:55.36 |
louipc |
I'm cheap,
and I don't do that much compiling I guess |
| 19:55.49 |
louipc |
or I'm
waiting for usb3.0 hahh |
| 19:56.06 |
louipc |
it'll be out
soonish |
| 19:56.57 |
talcite |
louipc:
hmm... well you can probably put usb 3.0 on any system with a PCIE
4x slot |
| 19:57.16 |
louipc |
that's
cheating! |
| 19:57.39 |
talcite |
they'll
release add on cards. It'll be pretty expensive for you to buy a
usb 3.0 system right when they come out |
| 19:57.54 |
louipc |
hmm yeah
probably |
| 19:57.59 |
talcite |
and after
they've come out, it'll be at least 2 years till they're coming off
lease |
| 19:58.14 |
talcite |
oh, off lease
computers are the secret to getting a good deal |
| 19:58.26 |
louipc |
what are
those? |
| 19:58.42 |
talcite |
I got a
machine capable of a quad core processor, with 2 gigs of ram. for
under $300 last year for my work |
| 19:59.02 |
louipc |
I just bought
some parts and threw them in a box |
| 19:59.12 |
*** join/#brlcad _sushi_
(n=_sushi_@84-73-206-53.dclient.hispeed.ch) |
| 19:59.18 |
talcite |
louipc:
businesses and governments usually lease their computers. When the
leases expire, they get sold as second hand equipment |
| 19:59.26 |
louipc |
ohh
nice |
| 19:59.31 |
talcite |
but they're
usually in great shape, so it's really cheap |
| 20:00.30 |
talcite |
louipc: here:
http://www.itxchange.com/itxchange/product.asp?part_no=6073-AR4-B3-06&SEORewriteUrlSrc=Website |
| 20:00.50 |
talcite |
you should
check out that site. They're probably the largest supplier of
off-lease equipment in the world |
| 20:01.18 |
talcite |
if you look
around more, I'm sure you can find one that has a good chipset and
lots of room for upgrades. |
| 20:01.23 |
louipc |
damn that's
pretty cheap |
| 20:02.34 |
talcite |
yup |
| 20:02.46 |
talcite |
it's more
powerful than my current system if you don't count the graphics
card |
| 20:03.06 |
talcite |
plus they're
all fairly linux compatible since they're IBM/lenovo |
| 20:05.06 |
talcite |
my suggestion
is to find a tower model with a motherboard/chipset that takes the
quad core processors, like Q35. It gives you a good upgrade path in
the future. All of these boards also take up to 16 gb
usually |
| 20:05.26 |
talcite |
they'll also
have enough Sata ports to give you raid capability |
| 20:05.41 |
talcite |
used to do IT purchasing for an NGO |
| 20:05.59 |
talcite |
had no money,
but needed performance =P |
| 20:21.46 |
CIA-79 |
BRL-CAD:
03starseeker * r35387
10/brlcad/trunk/include/opennurbs_ext.h: |
| 20:21.48 |
CIA-79 |
BRL-CAD:
subdivision size factors can apparently be disabled without
impacting the |
| 20:21.50 |
CIA-79 |
BRL-CAD:
raytracing, and VASTLY speeding up prep and lowering memory used.
With these |
| 20:21.52 |
CIA-79 |
BRL-CAD:
changes, able to raytrace 900+ breps (some of which have in turn
hundreds of |
| 20:21.54 |
CIA-79 |
BRL-CAD:
surfaces) in a surprisingly reasonable time. |
| 20:30.39 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 20:32.21 |
CIA-79 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1590 10/wiki/More_Changelog: /* July 7 - Today */ |
| 20:32.37 |
*** join/#brlcad Patmcc19
(n=chatzill@174-17-160-123.phnx.qwest.net) |
| 20:41.28 |
brlcad |
~elena++ |
| 20:42.32 |
brlcad |
is curious what an arb8 comparison looks like for the various
forms it can exist as now |
| 20:44.11 |
brlcad |
arb8, nmg,
bot, brep (new nurbs), bspline (old nurbs), vol/dsp/ebm (1x1 cell)
... |
| 20:45.09 |
brlcad |
starseeker:
ran across my SPM08 notes .. some good tidbits I'd forgotten -- see
if I can post up something |
| 20:49.00 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 20:53.03 |
talcite |
crap... I'm
failing the make test now =P |
| 20:54.20 |
brlcad |
talcite:
that's not necessarily anything you're doing wrong |
| 20:54.32 |
brlcad |
our tests are
more meant for devs under controlled
environments/settings |
| 20:54.39 |
talcite |
oh
ok |
| 20:54.40 |
brlcad |
there are
plenty that will cause test failures |
| 20:54.56 |
brlcad |
"make
benchmark" is a good validation |
| 20:55.17 |
talcite |
I see. Well
there wasn't any problems with that |
| 20:55.21 |
talcite |
make install
didn't go well either though |
| 20:55.25 |
brlcad |
running
"mged" and having it start up a gui is a good
validation |
| 20:55.38 |
brlcad |
make install
didn't work? |
| 20:55.43 |
talcite |
nope |
| 20:55.50 |
brlcad |
need a lil
more info :) |
| 20:55.52 |
talcite |
something
about overwriting a file that it just created |
| 20:55.59 |
talcite |
just a
sec |
| 20:57.08 |
talcite |
/usr/bin/install: will not overwrite
just-created `/home/matthew/Download/temp/share/man/man3/librle.3'
with `librle.3' |
| 20:57.33 |
talcite |
http://fpaste.org/paste/20314 |
| 20:59.13 |
brlcad |
looks |
| 21:00.53 |
talcite |
ok, I'll brb.
I need a quick shower before I head out |
| 21:02.56 |
brlcad |
ahh, damn --
yeah that issue is fixed on head |
| 21:03.06 |
brlcad |
there's a
duplicate entry for librle.3 in 7.14.8 |
| 21:04.28 |
brlcad |
talcite: can
see starseeker's edit on 34667 at
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/libutahrle/Makefile.am?view=log
to see the 'fix' |
| 21:13.20 |
CIA-79 |
BRL-CAD:
03bob1961 * r35388 10/brlcad/trunk/src/libged/clone.c: Modified
ged_clone (v5 only) to return the name of the clone, as before, as
well as a list of all cloned objects. |
| 21:14.29 |
talcite |
argh. I
really need to learn how to use sourceforge better |
| 21:14.33 |
talcite |
I can't get a
diff from it |
| 21:15.07 |
talcite |
their link to
'patch' gives me some text, but then you can't download from that
URL |
| 21:16.11 |
CIA-79 |
BRL-CAD:
03bob1961 * r35389
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added clone to
Archer's undo framework. |
| 21:16.53 |
louipc |
seems to work
for me |
| 21:19.34 |
talcite |
=S |
| 21:19.46 |
talcite |
blah ok, I
need to try this later tonight. I've got to head out for a
dinner |
| 21:37.44 |
CIA-79 |
BRL-CAD:
03starseeker * r35390 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: All
red for all regions is getting boring - make it random until we
figure out if there is color info in there and how to extract
it. |
| 21:44.55 |
Ralith |
starseeker:
I'm told the performance issue is a direct result of makeCurrent,
and thus rather unavoidable |
| 21:45.12 |
Ralith |
I have an
idea for another approach that's just as good, though |
| 21:45.17 |
Ralith |
based on the
overlay context |
| 21:45.21 |
starseeker |
cool |
| 21:45.36 |
Ralith |
it requires
OpenGL impl. support but hopefully that's widespread |
| 21:50.14 |
starseeker |
ah, there we
go - much better when it isn't all red: http://bzflag.bz/~starseeker/openmoko_subset.png |
| 21:52.29 |
Ralith |
oooh
:D |
| 21:52.40 |
Ralith |
since when
was NURBS so far along? |
| 21:53.25 |
starseeker |
a while back
now - last major user visible enhancement was when I got the
bounding box building to respect trims |
| 21:53.51 |
Ralith |
pretty
nice |
| 21:54.02 |
Ralith |
what's with
that USB port on the bottom of the shot though? |
| 21:54.18 |
starseeker |
the model as
imported has a lot of overlaps |
| 21:54.32 |
starseeker |
not to
mention geometry that doesn't seem to make sense as part of the
phone |
| 21:54.48 |
Ralith |
so it's just
oddly positioned in the source files? |
| 21:54.50 |
starseeker |
all we're
doing right now in 3dm-g is sucking in each brep as a
region |
| 21:54.55 |
starseeker |
I think
so |
| 21:55.05 |
Ralith |
kk |
| 21:55.12 |
starseeker |
not totally
sure |
| 21:55.23 |
Ralith |
could always
break out whatever it is that uses 3dm natively |
| 21:55.38 |
starseeker |
Rhino |
| 21:55.54 |
brlcad |
starseeker:
holy fuck, awesome |
| 21:56.03 |
brlcad |
pardon my
language, that's freaking cool |
| 21:56.15 |
starseeker |
:-) |
| 21:56.23 |
starseeker |
here's the
wireframe underlay: http://bzflag.bz/~starseeker/openmoko_underlay.png |
| 21:56.49 |
starseeker |
looks a heck
of a lot better when it isn't all red |
| 21:57.06 |
brlcad |
great gallery
shot |
| 21:57.09 |
Ralith |
ooh |
| 21:57.09 |
Ralith |
pretty |
| 21:57.12 |
brlcad |
should add an
openmoko section |
| 21:57.22 |
Ralith |
yeah |
| 21:57.34 |
starseeker |
heh - start
with the historical iges wireframe, and up to the present
:-) |
| 21:57.38 |
Ralith |
so is the
NURBS stuff considered to be largely stable? |
| 21:57.49 |
brlcad |
getting
there |
| 21:58.07 |
Ralith |
looks very
solid |
| 21:58.17 |
brlcad |
still working
on improved import paths (3dm and step) |
| 21:58.24 |
brlcad |
but
ray-tracing is looking pretty good |
| 22:00.37 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 22:14.54 |
CIA-79 |
BRL-CAD:
03ebautu * r35391
10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.inc
scripts/7.14.txt scripts/generic.txt): Implement individual
raytracing of models. |
| 23:12.57 |
Ralith |
brlcad: hm,
none of my ideas are working out :/ |
| 23:13.14 |
Ralith |
I could just
get lazy redraw working, minimizing heavy CPU usage to when smooth
animation is taking place. |
| 23:13.15 |
*** join/#brlcad archivist_
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 23:14.43 |
Ralith |
maybe I
should just bite the bullet and wrap input |
| 23:17.46 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 23:57.14 |
Ralith |
what's the
easiest way to dig through past revisions' code? |
| 00:00.07 |
Ralith |
waaaaaaaait a
minute |
| 00:00.09 |
Ralith |
compares performance |
| 00:04.09 |
Ralith |
brlcad: I'm
not sure if this approach is actually so badly performing after
all; I'm getting less than twicethe CPU usage of the non-embedded
approach. |
| 00:04.36 |
Ralith |
I think
perhaps I'll just slap lazy redraw in there and call it good
^^ |
| 00:11.00 |
starseeker |
thinks that sounds like a good idea |
| 00:11.37 |
starseeker |
if animation
is taking place, you might be able to "special case"
things... |
| 00:20.17 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 00:23.47 |
Ralith |
ooh,
idea |
| 00:24.19 |
Ralith |
a further
optimization that could be made might be to only swap contexts when
it's known for sure that Qt is going to render
something |
| 00:31.04 |
louipc |
is this gonna
require a core 2 quad? :P |
| 00:31.29 |
Ralith |
louipc: no,
I'm running on an ancient single core athlon64 :P |
| 00:31.35 |
louipc |
awesoem |
| 00:33.05 |
``Erik |
erm |
| 00:33.26 |
Ralith |
erm? |
| 00:33.28 |
``Erik |
pets his 650mhz pIII, 850mhz athlon tbird and 1.2ghz
athlon |
| 00:33.33 |
Ralith |
:P |
| 00:33.48 |
``Erik |
I think one
of the machines I use at work is 187mhz |
| 00:33.54 |
Ralith |
what
for? |
| 00:33.56 |
``Erik |
(ok, I use it
as a bookend, but it's providing a useful service!) |
| 00:34.01 |
Ralith |
hehe. |
| 00:34.08 |
``Erik |
keeps mah
books from fallin' |
| 00:34.17 |
Ralith |
fortunately,
I don't think BRL-CAD was ever expected to run on
bookends. |
| 00:34.24 |
``Erik |
um |
| 00:35.16 |
``Erik |
BRL-CAD
works(ed) on vax11/780 |
| 00:35.35 |
``Erik |
I think it's
original development was on a pdp-11 running 43BSD |
| 00:36.00 |
Ralith |
those weren't
being used as bookends though ^^ |
| 00:36.26 |
``Erik |
no, more like
superginormous paperweights |
| 00:37.26 |
``Erik |
just pushed a new core duo 3ghz box under his desk and
dropped fbsd7.2 on it at work, was impressed with how fast that
little thing is |
| 00:44.50 |
Ralith |
could do with one of those |
| 00:45.05 |
Ralith |
I'm long
overdue for an upgrade |
| 00:49.25 |
CIA-79 |
BRL-CAD:
03ralith * r35392 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Minor
optimization |
| 00:56.13 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 02:30.21 |
starseeker |
Ralith: is
Ogre set up for lazy redraw? |
| 02:39.41 |
*** join/#brlcad mike111
(n=mike@cadil21.kaist.ac.kr) |
| 02:39.47 |
mike111 |
hi
all |
| 02:40.46 |
mike111 |
can brlcad
export in STEP format? |
| 02:43.32 |
Ralith |
starseeker:
not yet, working on that. |
| 02:44.08 |
Ralith |
hm |
| 02:51.15 |
CIA-79 |
BRL-CAD:
03ralith * r35393 10/rt^3/trunk/src/g3d/ (MainWindow.cxx
OgreGLWidget.cxx): First (broken) attempt at lazy Ogre
redraw. |
| 02:51.44 |
starseeker |
mike111: no,
not yet |
| 02:54.23 |
CIA-79 |
BRL-CAD:
03ralith * r35394 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Scrapped
unnecessary include |
| 02:56.23 |
mike111 |
starseeker:
is there a way to output an `ars' shape in STL such that it surface
(skin) is defined by a dense mesh?. |
| 02:56.49 |
starseeker |
try
facetizing with really tight tolerances is the only thing that
comes to mind |
| 02:57.10 |
Ralith |
starseeker:
did you see the screenie I uploaded for brlcad this
morning? |
| 02:57.20 |
starseeker |
yes -
awesome! |
| 02:57.27 |
mike111 |
star: how do
I do that |
| 02:57.39 |
Ralith |
^^ |
| 02:58.08 |
starseeker |
check and see
if the g-stl converter has options - brlman g-stl |
| 02:58.32 |
starseeker |
have to try a
few and see if one gets you what you want |
| 03:02.23 |
*** join/#brlcad talcite
(n=matthew@206-248-128-129.dsl.teksavvy.com) |
| 03:11.37 |
CIA-79 |
BRL-CAD:
03ralith * r35395 10/rt^3/trunk/src/g3d/ogre.cfg: Deleted the
no-longer-necessary ogre.cfg |
| 03:28.14 |
talcite |
brlcad: I'm
still having the same problem with librle being
duplicated |
| 03:28.20 |
talcite |
the
makefile.am only has 1 entry now though |
| 03:31.45 |
talcite |
err wait...
do I need to run autogen.sh again? |
| 03:37.08 |
CIA-79 |
BRL-CAD:
03ralith * r35396 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Working, but flickery, lazy redraw. |
| 04:00.11 |
talcite |
hmm. I may
have run into another make install bug. Even though I put the
prefix as /home/matt/Download/temp, the tkhtml3 lib still tries to
install in /usr/lib/tkhtml3 |
| 04:07.16 |
talcite |
that's kind
of funky. Why is there both an exec_prefix and a prefix in the
Makefile? |
| 04:07.45 |
starseeker |
talcite:
there's something funky about it - it doesn't do that on a Mac,
apparently |
| 04:08.03 |
talcite |
starseeker:
did you use a prefix to configure it? |
| 04:08.07 |
starseeker |
yes |
| 04:08.11 |
talcite |
hmm |
| 04:08.20 |
talcite |
starseeker:
http://fpaste.org/paste/20357 |
| 04:08.23 |
starseeker |
we need to
revisit the tkhtml3 build process |
| 04:08.41 |
starseeker |
yeah |
| 04:08.50 |
starseeker |
has seen and heard of that before |
| 04:09.16 |
talcite |
hmmm |
| 04:09.27 |
louipc |
well, you
just need to add something to auto detect tkhtml3 I
think |
| 04:09.42 |
starseeker |
I need to
discuss that with brlcad - there is a fundamental problem when
installing a new tcl/tk package on a system tcl/tk install without
permissions for that install's standard package
directories |
| 04:09.59 |
talcite |
well the
offending line is here: exec_prefix = /usr |
| 04:10.18 |
starseeker |
hmm |
| 04:10.22 |
louipc |
starseeker:
yeah I tried alpha16 vs CVS. CVS works while alpha16 doesn't
hehe |
| 04:10.23 |
starseeker |
pulls up the makefile |
| 04:10.36 |
talcite |
72 in
src/other/tkhtml3 |
| 04:10.46 |
starseeker |
yeah, tkhtml3
isn't what you'd call actively developed |
| 04:11.15 |
talcite |
starseeker:
so wait, what's the problem with tkhtml3 anyways? It's not already
included in this system |
| 04:11.22 |
louipc |
talcite: hah
permission denied! funky.. |
| 04:11.27 |
talcite |
yup |
| 04:11.31 |
louipc |
oooh I
see |
| 04:11.44 |
talcite |
louipc: and
it should be denied. I don't want it to put it in
/usr/lib |
| 04:11.47 |
starseeker |
talcite: what
do you mean? |
| 04:11.48 |
louipc |
right |
| 04:12.06 |
louipc |
hmm I hadn't
had troubles building it bundled before though |
| 04:12.15 |
talcite |
starseeker:
you mentioned earlier that there's a problem with using a new
tcl/tk package, but tkhtml3 isn't installed |
| 04:12.22 |
starseeker |
tkhtml3 is
attempting to use the TEA extensions to build like a "normal"
tcl/tk package |
| 04:12.28 |
talcite |
oh |
| 04:12.58 |
starseeker |
naturally, if
you're using a system tcl/tk it's going to try to install it where
it needs to to make "package require Tkhtml 3.0" work |
| 04:13.25 |
talcite |
oh I get
it |
| 04:13.37 |
talcite |
hmm. so
that's why the prefix didn't work |
| 04:13.57 |
talcite |
crap. How am
I supposed to test this out then? =/ |
| 04:14.05 |
starseeker |
so what needs
to happen, in theory, is to have a local additional directory where
we can install tcl/tk packages and then point the wish/bwish guys
to |
| 04:14.32 |
starseeker |
talcite: can
you install tkhtml3 separately from brlcad? |
| 04:14.51 |
starseeker |
and get it in
the system tcl/tk? |
| 04:14.55 |
talcite |
starseeker:
that's what I'm looking to do right now. I don't know if there's a
package that already exists though |
| 04:15.09 |
starseeker |
or,
alternately, just do --enable-all and use a local tcl/tk for
BRL-CAD |
| 04:15.34 |
starseeker |
has a system tcl/tk install but always uses --enable-all -
it's just easier |
| 04:16.17 |
starseeker |
originally had hacked it together to build like tkimg
currently does, but I got chased off of that
approach |
| 04:16.18 |
talcite |
starseeker:
hmm. It might be, but I think that would be basis for the repo
maintainers to block the package |
| 04:16.48 |
starseeker |
talcite: I
know. The gentoo guys went around and around and around with that
one |
| 04:16.57 |
talcite |
=/ |
| 04:17.08 |
starseeker |
can you make
a tkhtml3 package and get that accepted? |
| 04:17.33 |
Ralith |
talcite: for
the sake of the USB image you *could* just uninstall system TCL for
a bit :P |
| 04:17.47 |
louipc |
silly
policies |
| 04:17.54 |
talcite |
Ralith: yeah,
the usb image is no problem. I can blow away system
tcl/tk |
| 04:18.01 |
talcite |
Ralith:
repos, not so much unfortunately |
| 04:18.09 |
starseeker |
louipc: Oh, I
understand why they do it but the problem with them is it's an "all
or nothing" result |
| 04:18.28 |
talcite |
starseeker:
maybe. It looks like a tkhtml rpm existed at one point, but was
dropped though |
| 04:18.58 |
starseeker |
with
something like BRL-CAD, which has patches to tcl/tk that we KNOW we
need and that the main trunk hasn't incorporated yet (or even if
they have, the package on the system is two versions
behind)... |
| 04:19.09 |
starseeker |
talcite: mm,
figures |
| 04:19.29 |
louipc |
I think
talcite is fairly up to date |
| 04:19.41 |
louipc |
he's got gcc
4.4.0 after all |
| 04:19.47 |
starseeker |
louipc: I was
thinking system tcl/tk |
| 04:19.48 |
talcite |
well Fedora
isn't usually a problem for these kinds of things. F11 is pretty
recent |
| 04:20.12 |
talcite |
yeah, I'm on
tcl8.5, not 8.6 |
| 04:20.18 |
louipc |
OH |
| 04:20.21 |
louipc |
odd |
| 04:20.29 |
talcite |
it's the most
recent in the fedora repos |
| 04:20.42 |
starseeker |
they usually
run a version or so back |
| 04:20.57 |
starseeker |
has had tcl/tk upgrades bust things - usually they want to be
a bit careful |
| 04:21.16 |
starseeker |
which makes
sense, but leaves us high and dry if we NEED something in the
newest version |
| 04:21.35 |
louipc |
I guess 8.6
was a bit special, but it's been out for awhile
though... |
| 04:21.37 |
talcite |
yeah. I don't
think they make major upgrades unless the distro version is
changing, i.e. F11 to F12 |
| 04:21.46 |
starseeker |
and we do
tweak the default tcl/tk trees, it's an adventure every time we
upgrade and try to be sure we re-merge all the changes |
| 04:21.52 |
talcite |
you need
someone to sponsor the update afaik |
| 04:22.19 |
talcite |
=/ why do we
make all these custom changes? does the trunk not provide enough
functionality? |
| 04:23.05 |
louipc |
so looks like
you have to bundle everything |
| 04:23.05 |
starseeker |
checks the tcl/tk revision history... been a
while... |
| 04:23.23 |
starseeker |
well, you CAN
run system and it will usually work |
| 04:23.48 |
louipc |
or you could
go back in time and package an old brl-cad release... |
| 04:23.53 |
louipc |
which
sucks |
| 04:24.16 |
talcite |
I'd rather
not do that |
| 04:24.37 |
louipc |
heh that's
the nature of static release distros |
| 04:25.47 |
starseeker |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/tcl/?view=log |
| 04:27.45 |
starseeker |
so from 33769
to 33872 was the upgrade struggle, and tweaks have been needed
since |
| 04:28.15 |
louipc |
ack I was
thinking of 8.4 - 8.5 is good. sorry for the mix up |
| 04:29.59 |
talcite |
starseeker:
but that's already been released in 7.14.8 right? |
| 04:30.02 |
starseeker |
the next
round will probably be similar |
| 04:30.05 |
talcite |
wasn't it
released in may? |
| 04:30.13 |
starseeker |
talcite:
which, 8.5? yeah |
| 04:31.24 |
starseeker |
makes note to self - next time tcl/tk is upgraded, check in
the vanilla tree and apply the changes so one clean diff can be had
from our own svn archives... |
| 04:31.35 |
talcite |
haha |
| 04:31.44 |
louipc |
talcite: is
it ok if tkhtml3 is installed in /usr in a brl-cad
package? |
| 04:32.09 |
talcite |
louipc: yeah.
It shouldn't be a problem. tkhtml3 isn't currently in
fedora |
| 04:32.18 |
talcite |
louipc: wait,
you mean in /usr, or /usr/brlcad/? |
| 04:32.42 |
starseeker |
if we install
in /usr/brlcad/ we need to teach tcl/tk how to look in there
properly |
| 04:32.50 |
louipc |
/usr/lib/Tkhtml3.0 |
| 04:33.01 |
talcite |
maybe. Let me
ask the fedora devs |
| 04:33.08 |
starseeker |
is not sure how to do that, or he would have fixed it
already |
| 04:33.41 |
louipc |
because
that's how my package worked anyways, but it would conflict if I
wanted to do a separate tkhtml3 package |
| 04:34.42 |
talcite |
what's
tkhtml3 used for anyways? |
| 04:34.47 |
louipc |
all you
should need to do is ./configure --with-tcl=/usr/lib
--with-tk=/usr/lib |
| 04:34.53 |
starseeker |
must admit tkhtml3 seems like a less hot idea now... liked
the sound of potentially having css support, but not sure it's
worth this trouble |
| 04:35.09 |
starseeker |
talcite: the
new mged help system |
| 04:35.11 |
louipc |
talcite:
fancy man page browsing in mged |
| 04:35.28 |
talcite |
=S man page
browsing? I didn't even build the documentation because there's a
bug in fop |
| 04:35.39 |
talcite |
=/ |
| 04:35.40 |
louipc |
screw the
pdfs |
| 04:35.49 |
starseeker |
if you got
html output that's plenty |
| 04:35.52 |
louipc |
man page and
html are good enough |
| 04:36.04 |
talcite |
? oh the
documentation gets built anyways, even if --disable-documentation
is set? |
| 04:36.07 |
talcite |
just not
pdfs? |
| 04:36.37 |
starseeker |
not sure. I
originally intended to have an option to speifically disable pdf
building, but I don't know if it got in... |
| 04:36.59 |
louipc |
that'd be a
good idea |
| 04:37.10 |
starseeker |
it won't try
pdfs if it doesn't find fop... |
| 04:37.17 |
talcite |
hmm |
| 04:37.26 |
talcite |
it was a fop
NPE |
| 04:38.42 |
talcite |
oh well. Are
there any alternatives for tkhml3? |
| 04:38.52 |
talcite |
or would that
be a pretty long-term solution? |
| 04:39.18 |
louipc |
man is the
alternative hehe |
| 04:39.35 |
starseeker |
well, even if
we pull in another one it still comes down to the issue of wanting
to use TEA building of a package with a system tcl/tk and no system
install permissions |
| 04:39.47 |
starseeker |
it's a
fundamental issue, not specific to tkhtml3 |
| 04:39.55 |
starseeker |
that just
happens to be the first time we hit it |
| 04:39.56 |
talcite |
I
see |
| 04:40.19 |
talcite |
what about
louipc's solution with --with-tkhtml=blah |
| 04:40.22 |
starseeker |
there may be
a "clean" solution, but if so I haven't found it yet |
| 04:41.40 |
starseeker |
talcite: you
mean point to a pre-installed but non-system tkhtml3? |
| 04:41.53 |
talcite |
yeah |
| 04:42.20 |
talcite |
err, is there
a reason why you need write access to the tcl stuff anyways? how
does TEA work? |
| 04:42.39 |
starseeker |
that's a good
question |
| 04:42.48 |
starseeker |
has never been fully comfortable with it |
| 04:42.50 |
louipc |
is tea a
separate package from tcl or something? |
| 04:43.07 |
starseeker |
no, it's an
extension to makefile logic specifically for tcl |
| 04:43.18 |
talcite |
=_=
really? |
| 04:43.19 |
talcite |
oh
man |
| 04:43.24 |
starseeker |
http://www.tcl.tk/doc/tea/ |
| 04:43.28 |
louipc |
hmmm |
| 04:43.39 |
talcite |
we could
build TEA from the tcl sources for the distro |
| 04:43.45 |
talcite |
the srpms are
certainly available |
| 04:44.11 |
starseeker |
no, it's an
m4 file we include in our makefile logic, iirc |
| 04:44.14 |
starseeker |
it's not a
package |
| 04:44.20 |
louipc |
but the
config was --with-tcl, --with-tk, and I didn't have a problem
building a package then |
| 04:44.29 |
starseeker |
the point is
what using the TEA logic in our makefile forces us to
do |
| 04:44.53 |
starseeker |
doesn't know if some sort of "install locally here and notify
bwish how we want to start" is enough |
| 04:44.59 |
starseeker |
or possible
even |
| 04:45.16 |
starseeker |
must sleep, back later |
| 04:45.47 |
talcite |
ahh
ok |
| 04:45.47 |
starseeker |
louipc: you
mean with system tcl/tk? |
| 04:45.51 |
louipc |
yeah |
| 04:46.03 |
starseeker |
which package
were you building? |
| 04:46.10 |
louipc |
brl-cad |
| 04:46.11 |
talcite |
I just heard
back from the fedora devs. No go on packaging tkhtml3 unless we get
it included upstream |
| 04:46.25 |
talcite |
err well, not
no go, it's just unlikely |
| 04:46.29 |
louipc |
alright |
| 04:46.41 |
louipc |
so you need
to stick it in /usr/brlcad then eh |
| 04:46.50 |
louipc |
back to the
beginning of the debate :D |
| 04:47.03 |
starseeker |
how do other
packages handle it when they need to install program specific tcl
packages not part of the system install? |
| 04:47.06 |
talcite |
separately I
mean. Yeah. we'll need to have it somewhere within the brlcad stuff
if possible |
| 04:47.21 |
talcite |
starseeker:
that's a good question. Let me ask |
| 04:50.43 |
talcite |
starseeker:
their advice is to work upstream on it. There's no one there right
now who has had experience working on TEA |
| 04:50.56 |
louipc |
talcite: what
does `grep PATH /usr/lib/tclConfig.sh` say? |
| 04:50.57 |
talcite |
can we get
our patches ported into tcl/tkhtml3? |
| 04:51.51 |
talcite |
grep PATH
/usr/lib64/tclConfig.sh |
| 04:51.51 |
talcite |
TCL_PACKAGE_PATH='/usr/lib64/tcl8.5
/usr/lib64/tk8.5 /usr/lib/tcl8.5 /usr/lib/tk8.5 /usr/share/tcl8.5
' |
| 04:51.51 |
talcite |
TCL_BUILD_STUB_LIB_PATH='/usr/lib64/libtclstub8.5.a' |
| 04:51.51 |
talcite |
TCL_STUB_LIB_PATH='/usr/lib64/libtclstub8.5.a' |
| 04:52.02 |
louipc |
cool |
| 04:53.22 |
talcite |
so just to be
clear. We're applying patches to tcl, AND tkhtml3? or just
tcl? |
| 04:53.36 |
talcite |
and also, is
tkhtml3 still maintained? The page look very old |
| 04:59.42 |
louipc |
it's not
really maintained |
| 05:01.44 |
talcite |
darn |
| 05:23.23 |
talcite |
oh man. I
just read the fedora packaging guidelines |
| 05:24.00 |
talcite |
no static
libs without explicit permission from the fedora steering
committee. And they avoid it very much so |
| 05:25.07 |
talcite |
I'll need to
package the rest of the libs as well =S |
| 05:25.56 |
louipc |
even the
really obscure ones? hah |
| 05:26.43 |
talcite |
louipc: yeah.
It's a security thing |
| 05:27.01 |
louipc |
hmm |
| 05:27.03 |
talcite |
static linked
libs mean that the entire program needs to be recompiled if there's
a bug found in one of them |
| 05:27.27 |
louipc |
yeah |
| 05:27.36 |
talcite |
plus, you
need to stay current on the mailing lists for those static libs to
check for security releases |
| 05:27.42 |
louipc |
well they're
not statically linked I don't think |
| 05:27.46 |
louipc |
just
bundled |
| 05:28.13 |
talcite |
hmm... well I
think they pretty much mean any libs that aren't managed with a
package |
| 05:29.59 |
louipc |
hmm I guess
you should tack on -brlcad on the end of them to signify it's from
the brlcad tree |
| 05:30.14 |
louipc |
opennurbs is
heavily modified for example |
| 05:31.25 |
louipc |
yeah brlcad
is a packaging challenge if you want to do it 'right' |
| 05:31.40 |
talcite |
=/ maybe I
should have chosen an easier package for my first time
=/ |
| 05:31.51 |
louipc |
definitely |
| 05:31.57 |
talcite |
why is
opennurbs so heavily modified? |
| 05:32.13 |
talcite |
have the
patches been submitted back to the trunk? |
| 05:33.06 |
louipc |
I don't think
so, but they didn't seem very friendly to collaboration |
| 05:33.43 |
talcite |
louipc: not
even if it means they get packaged into a major distro? |
| 05:34.36 |
louipc |
maybe you
have a better way with people than me :D try sending a message to
the newsgroup |
| 05:36.36 |
louipc |
you have to
give them an email to download the zip file because it's password
protected, they don't host a cvs tree, they don't even have an
opt-out on the web site after you've put in your email |
| 05:37.52 |
louipc |
open my foot
:/ |
| 05:38.16 |
Ralith |
'open' is
good PR these days :P |
| 05:38.57 |
Ralith |
at least they
don't have misleading licensing, I guess? |
| 05:39.22 |
talcite |
wait really?
oh man |
| 05:39.22 |
talcite |
is it GPL
compatible licensed? |
| 05:40.16 |
louipc |
it's akin to
public domain licensed |
| 05:40.31 |
talcite |
I'd hope
not... It can't get included in fedora unless it has an approved
license |
| 05:41.18 |
louipc |
http://www.opennurbs.org/ |
| 05:42.37 |
louipc |
if you say
fedora is interested maybe they'll perk up heh |
| 05:44.48 |
*** join/#brlcad talcite_
(n=matthew@69-196-132-72.dsl.teksavvy.com) |
| 05:44.48 |
Ralith |
talcite_:
you're saying public domain isn't an "approved
license"? |
| 05:44.49 |
talcite_ |
Ralith: they
don't explicitly say public domain on their site I
think |
| 05:45.11 |
Ralith |
so? |
| 05:45.14 |
Ralith |
it's public
domain |
| 05:45.22 |
louipc |
wtfpl |
| 05:45.23 |
Ralith |
that's as
friendly as it gets |
| 05:45.35 |
louipc |
you can take
it and stick GPL on it pretty much |
| 05:45.38 |
louipc |
if you
want |
| 05:46.11 |
louipc |
I would
interpret opennurbs-brlcad as BSD |
| 05:46.29 |
talcite_ |
is it wtfpl
though? There needs to be a license file distributed with the
package |
| 05:47.05 |
louipc |
it says the
same thing in the source package that it does on the
site |
| 05:47.09 |
louipc |
'no
restrictions' |
| 05:48.03 |
talcite_ |
oh
ok |
| 05:56.14 |
talcite |
argh!
opennurbs uses their own zlib |
| 05:56.19 |
talcite |
this is
pretty ridiculous |
| 05:56.48 |
louipc |
use opennurbs
from brlcad |
| 05:57.04 |
louipc |
it's pretty
much required |
| 05:58.27 |
talcite |
hmm. I don't
know what the fedora maintainers will do about not having an active
upstream maintainer on opennurbs |
| 05:58.36 |
talcite |
unless...
would you guys want to fork opennurbs? |
| 05:58.40 |
louipc |
that will
probably need patching to be friendly for packaging
though |
| 05:58.57 |
louipc |
I think it's
effectively forked hah |
| 05:59.05 |
talcite |
haha so make
it official then |
| 05:59.17 |
louipc |
just not
maintained separately from brlcad itself |
| 06:00.42 |
talcite |
is it
possible to make it so? Just make it a new tracker and start from
there |
| 06:01.28 |
talcite |
I can create
a package from opennurbs no problem I think, but I'll have to
specify a project maintainer in the rpm spec and also for the
package maintainers |
| 06:05.55 |
louipc |
I don't think
a new tracker is necessary, maybe just a self contained build
system |
| 06:06.21 |
louipc |
like I hear
kde has for each of it's little apps |
| 06:06.31 |
louipc |
but they can
also all be built together |
| 06:10.38 |
talcite |
hmm. that's a
pretty cool option |
| 06:11.31 |
talcite |
well... we
kind of do have a self-contained build system already don't
we? |
| 06:15.31 |
louipc |
well, I
haven't really tried, but it's not a simple ./configure &&
make if you visit the opennurbs dir |
| 06:15.47 |
talcite |
hmm |
| 06:15.58 |
talcite |
there's an
autotools template there already |
| 06:20.56 |
talcite |
hmm this is a
problem. I don't know if it's actually possible to move openNurbs
outside of the package |
| 06:21.30 |
talcite |
there's a lot
of compile options that seem to be passed from the parent, meaning
we're going to have trouble if they're different between different
packages |
| 06:22.46 |
louipc |
yeah it would
need some work |
| 06:22.52 |
talcite |
sigh. Maybe
I'll just ask brlcad about it tomorrow. I'm also going to have to
see if I can convince the fedora devs to just let us put the
package in, as long as we use dynamic linked libs and keep them
local |
| 06:39.47 |
louipc |
yeah I think
this is something that hinders brl-cad from being adopted by any
distro. maybe if it could be packaged properly, then it would be
adopted and maybe get more attention overall. |
| 06:41.06 |
louipc |
someone's
gotta have a lot of gumption to get over all the
hurdles |
| 06:44.31 |
talcite |
alright, I'm
going to call it an early (heh) night. I want to be up early enough
to get in touch with brlcad and the fedora devs |
| 07:22.38 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 08:15.34 |
*** join/#brlcad LarsG
(n=lars@spnp207089.spnp.nus.edu.sg) |
| 08:15.55 |
*** part/#brlcad LarsG
(n=lars@spnp207089.spnp.nus.edu.sg) |
| 09:10.52 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 09:32.14 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 09:46.57 |
*** join/#brlcad mafm_
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 11:02.15 |
CIA-79 |
BRL-CAD:
03ebautu * r35397
10/web/trunk/htdocs/more/sites/all/modules/cianotify/ (.
cianotify.info cianotify.module): cianotify custom module initial
update (many more features than the proof of concept version sent
to Sean). |
| 11:02.55 |
CIA-79 |
BRL-CAD:
03ebautu * r35398
10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.info
brlcad.module): Add log message after model processing. |
| 14:28.11 |
CIA-79 |
BRL-CAD:
03irpguardian * r35399
10/brlcad/trunk/src/proc-db/human.c: |
| 14:28.12 |
CIA-79 |
BRL-CAD:
Added command line argument for manual data entry mode (-m) for
entering sizes/lengths for all |
| 14:28.14 |
CIA-79 |
BRL-CAD:
parts of the human. Also reworked auto mode to be compatable with
this. |
| 14:34.47 |
brlcad |
a little bit
of misinformation last night.. |
| 14:35.49 |
*** join/#brlcad pacman87
(n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 14:36.45 |
brlcad |
opennurbs has
fairly minor modifications that mostly amount to compilation
portability, there are some logic additions but we could probably
refactor them if the project ever took upon a life of its
own |
| 14:37.13 |
brlcad |
as it is, we
have provided back upstream the non-logic changes (and regularly do
so for tcl/tk as well, which also has build tweaks) |
| 14:38.26 |
brlcad |
tkhtml3 is
just a bit of a bitch in its own right -- we have to figure out how
to coerce it to install where we install |
| 14:38.56 |
brlcad |
but also
non-critical -- we can turn it off if we have to (especially if it
means a go or no-go on fedora integration) |
| 14:40.34 |
*** join/#brlcad talcite
(n=matthew@69-196-132-72.dsl.teksavvy.com) |
| 14:43.02 |
*** join/#brlcad _sushi_
(n=_sushi_@84-73-206-51.dclient.hispeed.ch) |
| 14:43.11 |
brlcad |
howdy
talcite |
| 14:47.38 |
talcite |
hey
brlcad |
| 14:48.35 |
talcite |
So there was
a lot of discussion going on last night, plus some potential
problems with make install again. Let me chat a bit with the fedora
devs to see if can get some exceptions for us |
| 14:49.33 |
talcite |
essentially,
the main problem right now is that the fedora policy is to not use
any static libs, eliminate all libtool archives, and avoid
packaging dynamic libs together as one package |
| 14:49.58 |
talcite |
I'll see what
I can do. I don't think they'll budge on static libs or the libtool
archives |
| 14:51.59 |
brlcad |
yeah, i saw
the backlog.. and just finished commenting a min before you entered
:) |
| 14:52.36 |
talcite |
ahh cool. Do
we have an irc log? |
| 14:52.50 |
brlcad |
we do, but it
gets posted daily |
| 14:53.01 |
talcite |
oh
ok |
| 14:53.06 |
brlcad |
we can
disable tkhtml if push comes to shove, it's not a critical
component |
| 14:53.14 |
talcite |
ahh
ok |
| 14:53.52 |
brlcad |
aware of the
out-of-dir install problem but it's not readily within our control
to change it without gutting tkhtml3's build system |
| 14:54.08 |
brlcad |
which is an
option too that we were talking about just yesterday |
| 14:54.41 |
brlcad |
since it's a
proper tcl extension, using TEA, I'd kinda like to avoid that, but
it requires some build system massaging |
| 14:54.53 |
talcite |
I've been
thinking about it as well. tkhtml3 doesn't modify any existing
packages does it? It just writes to existing directories to update
a registry or something? |
| 14:55.00 |
brlcad |
maybe as
simple as passing a few subconfigure flags |
| 14:55.21 |
talcite |
there's an
--exec-prefix flag that it follows |
| 14:55.54 |
brlcad |
yeah, nothing
so complex -- the issue is mainly that it gets all of its
installation preferences from whichever tcl it's building
against |
| 14:56.09 |
brlcad |
and since you
have it using a system tcl, it wants to install there so it's
auto-located |
| 14:56.14 |
talcite |
ahh.. |
| 14:56.26 |
brlcad |
not a
problem, just a bit messy to override potentially |
| 14:56.48 |
brlcad |
or as simple
as .. |
| 14:59.43 |
talcite |
brlcad: ok so
that sounds good. What about building each library as a separate
package? How entrenched are they right now? |
| 15:02.06 |
CIA-79 |
BRL-CAD:
03brlcad * r35400 10/brlcad/trunk/configure.ac: tell tkhtml3 to
install into our prefix. this may screw with users that want a
specific --exec-prefix separate from prefix (not that we support
that configuration). |
| 15:02.12 |
brlcad |
what do you
mean? |
| 15:03.04 |
brlcad |
talcite: have
you tried manually specifying --exec-prefix=prefix ? that should
propagate and apply to tkhtml3 |
| 15:03.38 |
brlcad |
presuming you
meant each of our libraries as a separate package, yes thought
about that a lot |
| 15:03.42 |
talcite |
brlcad: yup,
I tried specifying it, but it also breaks some other packages.
tkhtml3 isn't the only one that listens to --exec-prefix I
think |
| 15:03.51 |
talcite |
brlcad: yup,
that's what I meant |
| 15:04.03 |
brlcad |
we have about
two dozen libraries |
| 15:04.18 |
brlcad |
internal, not
counting our bundled external deps |
| 15:04.52 |
talcite |
brlcad: I
think internal libs are ok. If you're the maintainer for them, it
shouldn't be a problem |
| 15:04.57 |
brlcad |
we also have
about 400 binaries, many of which are similarly valuable as a
stand-alone distribution as well |
| 15:05.09 |
talcite |
whoa |
| 15:05.34 |
brlcad |
you realize
you picked a package about as complex as X11 to work on
integrating? :) |
| 15:05.57 |
talcite |
haha well
it's worth a shot I suppose. Good practice |
| 15:06.08 |
brlcad |
25 years
development, million+ lines of code .. lots of complexities
:) |
| 15:06.19 |
brlcad |
it's
certainly doable |
| 15:06.33 |
talcite |
I need to
package this in one way or another for the reprap project, but I'd
like to also have it carry over into fedora anyways |
| 15:06.37 |
brlcad |
we resolved
most of the major issues over the past few years while working
towards gentoo integration |
| 15:06.46 |
talcite |
ahh |
| 15:06.50 |
brlcad |
our portage
integration tracker item is like four years old |
| 15:07.27 |
brlcad |
we used to
have full-on modifications/extensions to tk years ago that made us
require our version .. fortunately no longer the case |
| 15:07.43 |
brlcad |
plus there
were many assumptions about installing into an isolated
root |
| 15:08.06 |
brlcad |
also taken
care of, even run-time relocation should work now |
| 15:08.26 |
talcite |
hmm. Yeah,
we'll definitely need to use the system libs whenever
possible |
| 15:09.00 |
brlcad |
understandably, hence --disable-all
:) |
| 15:09.22 |
brlcad |
they're only
bundled for convenience at that, to make the task a lot easier for
users |
| 15:09.29 |
brlcad |
auto-detecting nearly
everything |
| 15:10.00 |
talcite |
I see. Yeah
the build process is definitely really convenient if you don't mind
using the bundled libs |
| 15:10.16 |
brlcad |
talcite: so
one thing I'd suggest is flipping over to an SVN checkout, and
seeing if we can work through these issues one at a
time |
| 15:10.26 |
brlcad |
then we can
tag a release for you to use |
| 15:10.46 |
brlcad |
yeah,
especially given how some of the deps are common, others are
obscure |
| 15:10.55 |
talcite |
that sounds
good to me. |
| 15:10.56 |
brlcad |
openNURBS
being a classic example |
| 15:11.50 |
brlcad |
which is
under a trivial license as I see you noticed (commenting on last
night's discussion) |
| 15:12.05 |
talcite |
I don't know
if we actually need to abstract out openNURBS |
| 15:12.06 |
brlcad |
it's not
public domain, but about as liberal a license as I've ever
seen |
| 15:12.11 |
brlcad |
you
shouldn't |
| 15:12.17 |
brlcad |
it's very
obscure |
| 15:12.27 |
talcite |
yeah. And
we've made lots of changes to it I've heard |
| 15:12.32 |
talcite |
effectively
forking it |
| 15:12.42 |
brlcad |
actually only
minor changes, mostly build system portability fixes |
| 15:12.49 |
brlcad |
(which we do
continuously push upstream) |
| 15:12.49 |
talcite |
oh
ok |
| 15:13.34 |
brlcad |
we do
presently have some minor logic changes that we'd have to back out,
but nothing too drastic |
| 15:13.56 |
brlcad |
that said,
there's still not really a community supporting it -- just devs ad
mcneal and assoc. |
| 15:14.00 |
brlcad |
s/ad/at/ |
| 15:14.46 |
brlcad |
the logic
mods we need/want, they're very intentionally not interested in
supporting (as they have a commercial product they sell that does
exactly what we've implemented) |
| 15:15.03 |
talcite |
haha I
see |
| 15:15.29 |
brlcad |
so we have
those mods separated out "mostly" (99%) in our libs |
| 15:15.42 |
brlcad |
just a few
from when we first started were applied directy and never backed
out |
| 15:19.24 |
talcite |
so where does
that leave us right now? I'm checking out an SVN copy right now,
and we need to get everything to use system libs if they exist,
then I'll submit a request for review by the repo maintainers. How
does that sound? |
| 15:19.44 |
CIA-79 |
BRL-CAD:
03irpguardian * r35401 10/brlcad/trunk/src/proc-db/human.c:
Reworked the makearmy command to prevent person overlapping with
custom settings. |
| 15:20.11 |
brlcad |
that sounds
good to me -- of the list in src/other which are already in
fedora? |
| 15:20.24 |
talcite |
the request
will probably come back with a lot of comments on changes we need
to make, but it's probably the only good way forward. The fedora
devs are having trouble saying what we can and can't do without
seeing the actual code |
| 15:20.26 |
brlcad |
antoher
consideration is installation location |
| 15:20.43 |
talcite |
libpng,
libregex, tcl, tk |
| 15:20.54 |
brlcad |
for what it's
worth, one of the fedora devs was working on integration at one
point |
| 15:21.00 |
talcite |
yup, install
location I'm working on right now. It looks like the rpm specfile
has a bit of handling in that |
| 15:21.10 |
brlcad |
more than a
year ago, iirc |
| 15:21.12 |
talcite |
ahh |
| 15:21.37 |
brlcad |
just an FYI,
some of them should be aware of our specific situation |
| 15:21.52 |
brlcad |
the biggest
issue on installation location is naming conflicts and
isolatability |
| 15:22.17 |
brlcad |
we have
ancient libs that predate other folks, but conflict with other
high-profile libs |
| 15:22.19 |
talcite |
hmm I never
mentioned that I was working on brlcad to them. I'll mention it
next time I get a chance to talk to them I guess |
| 15:22.37 |
brlcad |
just those
four deps? I'm sure there are others :) |
| 15:22.46 |
talcite |
yup, I was
configuring to get the list =D |
| 15:23.08 |
talcite |
tcl, tk,
itcl/itk, iwidgets, libpng, libregex, zlib |
| 15:23.30 |
brlcad |
i would
expect: boost, libpng, libtermlib, libz, tk, incrtcl, libregex, and
tcl |
| 15:24.08 |
talcite |
boost?
hmm |
| 15:24.17 |
brlcad |
boost isn't
so important -- all header files |
| 15:24.26 |
talcite |
yeah |
| 15:25.29 |
talcite |
libtermlib
isn't in fedora for some reason |
| 15:27.26 |
brlcad |
it is, just
isn't called that :) |
| 15:27.33 |
brlcad |
termio/curses
work |
| 15:28.00 |
brlcad |
termcap |
| 15:28.17 |
talcite |
ahh |
| 15:28.17 |
brlcad |
terminfo |
| 15:28.19 |
brlcad |
tinfo |
| 15:28.25 |
brlcad |
the thing has
tons of names :) |
| 15:28.36 |
brlcad |
probably
standard system lib |
| 15:29.10 |
brlcad |
termlib is
just the original/old bsd name for it, and is a nice stable base
that lets us continue to support really old systems |
| 15:29.19 |
brlcad |
*really* old
systems :) |
| 15:31.02 |
talcite |
oh I
see |
| 15:31.14 |
talcite |
it's called
libtermcap in fedora |
| 15:57.55 |
CIA-79 |
BRL-CAD:
03bob1961 * r35402
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Update
combWrapper to call createWrapper or gedWrapper. Added comb, g and
r to Archer's undo framework. |
| 16:12.38 |
talcite |
argh. I've
run into the XVisualInfo bug again |
| 16:12.46 |
talcite |
and this time
autogen.sh didn't help |
| 16:26.50 |
talcite |
brlcad: can
we do something to fix this up this XVisualInfo bug? I'm pretty
sure it's still the same thing with autogen not running tests
properly |
| 16:27.04 |
talcite |
The weird
thing is that it worked on the 7.14.8, but doesn't work on trunk
now |
| 16:27.14 |
brlcad |
talcite:
there were two issues, needing to run autogen.sh and the cache not
being invalidated |
| 16:27.28 |
talcite |
brlcad: ahh
yes, the cache |
| 16:28.02 |
brlcad |
i'm still
working on the cache issue, but you can
--cache-file=/dev/null |
| 16:29.05 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:30.01 |
talcite |
brlcad: hmm.
I cleared the cache, but it didn't help |
| 16:30.13 |
brlcad |
pastebin? |
| 16:30.26 |
brlcad |
configure
output, config.log, make log |
| 16:30.42 |
talcite |
sure |
| 16:30.51 |
brlcad |
my change
yesterday might not have helped |
| 16:31.00 |
brlcad |
maybe made it
worse |
| 16:31.40 |
talcite |
make ->
http://fpaste.org/paste/20382 |
| 16:34.38 |
brlcad |
yeah, need
config.log |
| 16:34.48 |
brlcad |
it's the
HAVE_X11_XLIB_H check |
| 16:37.26 |
talcite |
brlcad:
http://fpaste.org/paste/20384 |
| 16:40.01 |
brlcad |
huh |
| 16:40.10 |
brlcad |
grep HAVE_X11
include/brlcad_config.h |
| 16:40.47 |
talcite |
brlcad:
nothing |
| 16:42.21 |
CIA-79 |
BRL-CAD:
03bob1961 * r35403
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added the "c"
command to Archer's undo framework. |
| 16:44.05 |
talcite |
heh the
entire #define for the HAVE_X11_XLIB_H is missing |
| 16:50.25 |
``Erik |
tries --with-x11=/path/to/X |
| 16:51.06 |
brlcad |
huh |
| 16:51.12 |
``Erik |
(looks like
all the X checks are now buried in a $bc_with_x11) |
| 16:51.29 |
brlcad |
``Erik: it's
doing the check, in his log |
| 16:51.40 |
brlcad |
just
AC_CHECK_HEADER isn't setting HAVE* for some reason |
| 16:51.49 |
``Erik |
oh, I'm
chasing down the issues myself, getting them on my
lappie |
| 16:51.59 |
``Erik |
haven't even
looked at the pastebin :) |
| 16:52.52 |
talcite |
brlcad: The
#define is missing within the autoconf template. Is that a change
that happened moving to svn trunk? |
| 16:53.05 |
CIA-79 |
BRL-CAD:
03brlcad * r35404 10/brlcad/trunk/configure.ac: try
AC_CHECK_HEADERS instead to get the HAVE define |
| 16:53.07 |
brlcad |
talcite: try
that |
| 16:53.12 |
brlcad |
(svn
up) |
| 16:53.22 |
talcite |
yup |
| 16:57.14 |
jdoliner |
i'm pretty
sure that worked for me brlcad |
| 16:58.34 |
talcite |
looks like it
works |
| 17:01.43 |
brlcad |
cool |
| 17:01.46 |
CIA-79 |
BRL-CAD:
03erikgreenwald * r35405
10/brlcad/trunk/src/librt/primitives/bot/bot.c: Throw some escapes
in so GCC will quit complaning that '???' is not a valid
trigraph. |
| 17:01.58 |
brlcad |
who would
have thought one 'S' was so important |
| 17:02.06 |
talcite |
heh |
| 17:02.50 |
jdoliner |
yup ran great
for me |
| 17:02.52 |
jdoliner |
commit
time |
| 17:04.37 |
``Erik |
ah heh, or
explicitely putting the defines in AC_CHECK_HEADER |
| 17:04.51 |
CIA-79 |
BRL-CAD:
03jdoliner * r35406
10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: Chased down a
couple of bugs, intersection now runs succussfully on two
intersecting nurbs surfaces |
| 17:05.31 |
brlcad |
cool jdoliner
:) |
| 17:05.38 |
brlcad |
so what's the
result? |
| 17:05.44 |
brlcad |
an evaluated
trimmed surface? |
| 17:05.49 |
brlcad |
untrimmed? |
| 17:05.53 |
brlcad |
just the
intersection curve? |
| 17:06.02 |
jdoliner |
right now
just the intersection curve |
| 17:07.14 |
jdoliner |
so that
commit message might make things seem a bit more exciting than they
are |
| 17:07.34 |
talcite |
include/dm-rtgl.h:63: error: expected
specifier-qualifier-list before âGLXContextâ |
| 17:07.47 |
jdoliner |
0:) |
| 17:07.49 |
talcite |
looks like
another failed include somewhere |
| 17:09.45 |
``Erik |
missing
GL/glx.h ? |
| 17:10.03 |
talcite |
maybe. Why is
it being built though? I'm not using ogl |
| 17:11.40 |
louipc |
all your
stuff is in /lib64 yeah? |
| 17:12.03 |
talcite |
ahh...
yes |
| 17:12.51 |
talcite |
it's strange.
I never ran into this build error on the 7.14.8 release. It just
wasn't being compiled I think |
| 17:14.20 |
talcite |
wait a
minute |
| 17:18.27 |
talcite |
so what
changed that we now need glx.h? |
| 17:18.41 |
talcite |
I didn't have
the libs before, that's probably what caused the
problem |
| 17:20.00 |
talcite |
looks like it
works again |
| 17:42.52 |
brlcad |
talcite: hm,
it shouldn't be compiling dm-frtgl |
| 17:43.34 |
talcite |
brlcad: not
sure what to say, it did for some reason |
| 17:48.35 |
talcite |
brlcad: if it
helps: http://pastebin.com/d2b63bbb3
config.log |
| 17:48.43 |
talcite |
fpaste.org
broke =P |
| 17:49.15 |
brlcad |
i can't get
to pastebin.com from here |
| 17:49.21 |
brlcad |
~bzpaste |
| 17:49.22 |
ibot |
from memory,
bzpaste is http://pastebin.bzflag.bz/ |
| 17:52.19 |
brlcad |
try this:
grep RTGL src/libdm/Makefile |
| 17:52.42 |
talcite |
DM_RTGL_CFLAGS = |
| 17:52.42 |
talcite |
#DM_RTGL_CFLAGS = -DDM_RTGL -DIF_RTGL
$(GL_CPPFLAGS) |
| 17:52.42 |
talcite |
DM_RTGL_LIBS
= |
| 17:52.42 |
talcite |
#DM_RTGL_LIBS
= ${LIBGL} |
| 17:52.42 |
talcite |
${DM_RTGL_CFLAGS} \ |
| 17:52.43 |
talcite |
${DM_RTGL_LIBS} |
| 17:52.53 |
talcite |
brlcad: I
can't get the bzflag one working. It says forbidden |
| 17:53.07 |
``Erik |
1/clear |
| 17:53.09 |
brlcad |
huh, okay
well that's even more odd .. rtgl is turned off |
| 17:53.29 |
brlcad |
show the make
output leading up to that include/dm-rtgl.h error? |
| 17:54.19 |
talcite |
err. it's
gone =/ |
| 17:54.26 |
brlcad |
heh |
| 17:54.33 |
talcite |
I could bring
it back, one sec |
| 17:54.36 |
brlcad |
lies! |
| 17:54.48 |
talcite |
I'll just yum
erase glx.h =P |
| 17:57.03 |
talcite |
damn firefox
keeps dying on me |
| 17:57.26 |
brlcad |
more than
likely that was either some stale build issue or is something minor
that will get caught during release testing |
| 17:57.38 |
brlcad |
seeing how
you're on unreleased trunk at the moment |
| 17:58.39 |
talcite |
probably.
I'll help you track it down though |
| 17:58.51 |
talcite |
I can't stay
for too much longer though. I really should go in to the lab
today |
| 17:59.29 |
brlcad |
dm-rtgl is an
experimental interface being worked on now, it shouldn't be
enabled |
| 18:01.20 |
talcite |
brlcad: here
you go: http://paste2.org/p/349572 |
| 18:02.12 |
brlcad |
yeah, that
says it's disabled |
| 18:02.24 |
talcite |
heh.
alright. |
| 18:02.35 |
talcite |
well my make
is chugging along. It should hit the glx.h thing soon |
| 18:03.00 |
talcite |
maybe time to
invest in more ram/cpu and a ssd =P |
| 18:05.32 |
brlcad |
:) |
| 18:06.25 |
brlcad |
shouldn't hit
a glx.h error either, opengl is disabled (and it should
be) |
| 18:14.05 |
talcite |
hmm.. it gave
a different error |
| 18:14.14 |
talcite |
guess it was
lies after all =P |
| 18:15.17 |
talcite |
alright. So
it builds, albeit with a couple funky packages. Not really a worry,
like you said, it'll get removed at release |
| 18:15.37 |
talcite |
I'll have it
compile and then give packaging a shot |
| 18:34.07 |
*** join/#brlcad docelic
(n=docelic@78.134.200.15) |
| 18:34.31 |
brlcad |
talcite: word
of caution, do not set prefix to /usr |
| 18:34.53 |
talcite |
haha yeah, I
saw that in the FAQ. I shall avoid it |
| 18:34.57 |
louipc |
hehe |
| 18:34.57 |
brlcad |
the conflicts
I spoke of earlier are potentially devastating |
| 18:35.42 |
talcite |
so how is
integration with a dynamic lib system going to work anyways? Do we
use libtool rpaths? |
| 18:35.57 |
brlcad |
hm? |
| 18:36.48 |
talcite |
well I'm
curious as to how we satisfy the dynamic libraries for
this |
| 18:37.20 |
talcite |
we use system
libs when possible, but what about the local libs? |
| 18:37.50 |
talcite |
they're
dynamically linked, but are they registered with
ldconfig? |
| 18:40.13 |
louipc |
you'll have
to add the directory to ld.so.conf |
| 18:40.19 |
louipc |
and run
ldconfig |
| 18:41.08 |
louipc |
talcite: I
guess you could ask fedora devs how they handle post-install
operations |
| 18:41.25 |
brlcad |
they are
found automatically |
| 18:41.35 |
brlcad |
libtool takes
care of all that |
| 18:41.37 |
louipc |
like
regenerating the font cache, info listing |
| 18:41.47 |
brlcad |
rpaths are
fixed into the binaries |
| 18:41.55 |
talcite |
ahh... ok I
see |
| 18:42.07 |
louipc |
oh
libtool |
| 18:42.07 |
brlcad |
and
libs |
| 18:42.25 |
brlcad |
ldconfig
would be to add to the system search paths, but that's not
necessary |
| 18:42.34 |
talcite |
heh. The
fedora package rules are to not use rpaths |
| 18:42.53 |
louipc |
probably not
to use libtool either :P |
| 18:43.22 |
talcite |
err, well you
can use libtool. you need to remove the archives it generates
though. |
| 18:43.30 |
talcite |
anyways, we
can deal with this stuff one at a time |
| 18:43.31 |
louipc |
yeah |
| 18:43.44 |
talcite |
anyways, I
really should head into the lab |
| 18:43.59 |
talcite |
I already
took yesterday off heh |
| 18:45.50 |
talcite |
I'll be back
tonight, but really late |
| 18:56.07 |
brlcad |
cya! |
| 18:56.22 |
brlcad |
I fly down
south tomorrow, so may or may not be up late :) |
| 19:23.33 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 19:41.40 |
CIA-79 |
BRL-CAD:
03bob1961 * r35407
10/brlcad/trunk/src/libged/copyeval.c: |
| 19:41.42 |
CIA-79 |
BRL-CAD:
Changed the order of the arguments (i.e. path_to_old_prim comes
before |
| 19:41.44 |
CIA-79 |
BRL-CAD:
new_prim). Removed the option to specify the path elements
individually (i.e. |
| 19:41.46 |
CIA-79 |
BRL-CAD:
"all.g box.r box.s" is no longer allowed. One must instead specify
it as |
| 19:41.48 |
CIA-79 |
BRL-CAD:
all.g/box.r/box.s). |
| 19:58.23 |
CIA-79 |
BRL-CAD:
03Ebautu 07http://brlcad.org *
r1591 10/wiki/More_Changelog: July 30 activity |
| 20:04.19 |
CIA-79 |
BRL-CAD:
03bob1961 * r35408 10/brlcad/trunk/src/ (3 files in 3 dirs): Added
copyeval and facetize to Archer's undo framework. |
| 20:32.24 |
``Erik |
odd |
| 21:04.17 |
CIA-79 |
BRL-CAD:
03n_reed * r35409 10/brlcad/trunk/src/libdm/dm-rtgl.c: using window
size for gridding; experimenting with shot patterns |
| 21:23.30 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 21:25.49 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 21:29.05 |
CIA-79 |
BRL-CAD:
03bob1961 * r35410 10/brlcad/trunk/src/libged/copyeval.c: The
copyeval command has been modified to do a regular copy if the
path_to_old_prim has a single path element (i.e. just a plain
object name). |
| 00:37.44 |
*** join/#brlcad talcite_
(n=matthew@75-119-228-20.dsl.teksavvy.com) |
| 02:01.13 |
*** join/#brlcad talcite__
(n=matthew@69-165-133-98.dsl.teksavvy.com) |
| 02:20.44 |
starseeker |
possibly the
most absurd vehicle I have ever seen:
http://cgi.ebay.com/ebaymotors/Hummer-H3-Limousine-2008-H3-PINK-HUMMER-LIMOUSINE-LIMO-LIMOSUITE_W0QQcmdZViewItemQQ_trksidZp3286Q2ec0Q2em14QQhashZitem35a28c1bacQQitemZ230360357804QQptZUSQ5fCarsQ5fTrucks |
| 02:23.51 |
``Erik |
smells like a
"daddy's rich" car |
| 02:24.17 |
starseeker |
that's up (or
down) there with the Oscar Myer hot dog car |
| 02:24.33 |
``Erik |
hey now, the
weinermobile is COOL |
| 02:25.57 |
``Erik |
how else do
you get disturbing scenarios like http://wizbangpop.com/images/2009/07/wienermobile%20crash.jpg
? :D |
| 02:26.38 |
starseeker |
oh
my |
| 02:26.57 |
starseeker |
doesn't see an ex-military Hummer on ebay...
hmm... |
| 02:27.17 |
starseeker |
thought they
sold a few in the early days before GM figured out there was a
civilian market... |
| 02:30.53 |
``Erik |
probably
collectors items now |
| 02:31.17 |
``Erik |
wonder how
many of those 'fall off the truck' O.o |
| 02:37.54 |
starseeker |
Hehe, well,
this might be a decent runner up:
http://www.govliquidation.com/auction/view?id=2552645&convertTo=USD |
| 02:38.37 |
starseeker |
Hmm, opening
bid $150... |
| 02:38.54 |
``Erik |
heh, looks
oddly familiar |
| 02:39.16 |
starseeker |
talk about an
awesome way to update our model... |
| 02:40.16 |
starseeker |
imagines pulling up to work in that
thing... |
| 02:40.25 |
starseeker |
"no, really,
it's my own truck!" |
| 02:41.07 |
starseeker |
wonders what the gas milage is |
| 02:41.18 |
starseeker |
I suppose if
you have to ask you can't afford to run it... |
| 02:42.09 |
starseeker |
maybe we can
convince Bob he needs it for something |
| 02:45.51 |
``Erik |
looks like
around 6mpg |
| 02:46.05 |
starseeker |
winces |
| 02:46.17 |
starseeker |
I know -
design the world's first hybrid m35 |
| 02:46.32 |
starseeker |
it can't be
any more pointless than the pink stretch hummer limo |
| 02:46.39 |
``Erik |
max highway
speed goes between 45 and 60 depending on grade and
shtuff |
| 02:47.04 |
starseeker |
grins at the idea of going to yard sales in that
thing... |
| 02:48.05 |
``Erik |
http://www.bunkerofdoom.com/mil/m35/mileage/mileage.html |
| 02:50.48 |
starseeker |
cool |
| 02:51.04 |
``Erik |
seems that's
the c^3 variant, has a hugeassed box on the back |
| 02:51.07 |
starseeker |
or, if that's
too fuel efficient...
http://www.govliquidation.com/auction/view?id=2565791&convertTo=USD |
| 02:51.44 |
starseeker |
nods - I think 55mph is low enough that it's up in the air
whether weight or wind resistance is the major
factor |
| 02:53.20 |
``Erik |
I d'no, a 10'
brick at 55mph is going to have a lot of force on it |
| 02:54.11 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 02:54.19 |
starseeker |
ah, yeah,
that tall you're probably right |
| 02:54.35 |
starseeker |
shouldn't have wandered onto this site - cool
stuff |
| 02:54.40 |
starseeker |
http://www.govliquidation.com/auction/view?auctionId=2550019 |
| 02:55.08 |
``Erik |
210hp and
tops at 60, even if it were engine rpm limited, it'd have to have a
lot of wind resistance to need that much hp |
| 02:56.17 |
starseeker |
must be for
hauling |
| 02:56.18 |
``Erik |
(hard finding
good info on the m35, apparently infiniti calls one of their cars
that) |
| 02:56.57 |
starseeker |
bemusedly wonders if gcam could be made to work with that
milling machine... |
| 02:57.36 |
``Erik |
how's this
for a sleek street machine.. imagine the awesome CD and such a
small front area..
http://www.bunkerofdoom.com/mil/m35/first/319commo_truck_large.jpg |
| 02:58.38 |
starseeker |
hehehe |
| 02:59.25 |
starseeker |
would be
worth renting one just to park it next to the BRLCADmobile for a
photo |
| 02:59.34 |
``Erik |
heh |
| 03:01.10 |
``Erik |
d'no why
you'd want a collection of slow vehicles in a single picture,
though O:-) |
| 03:03.43 |
starseeker |
was thinking - m35 truck == current GUI, Lotus == intended
new GUI |
| 03:04.21 |
starseeker |
ick - they
apparently sell office equipment by the pallet |
| 03:06.57 |
starseeker |
blinks at music CDs in one lot |
| 03:07.04 |
starseeker |
bet there's a
good story behind that one |
| 03:12.23 |
starseeker |
ooh,
heck-yeah
http://www.govliquidation.com/auction/view?id=2509637&convertTo=USD&tid=GLSPPR7932&cm_re=1-_-hotlots-_-row3col3 |
| 03:16.06 |
starseeker |
is still a physics nerd at heart |
| 03:43.48 |
*** join/#brlcad talcite_
(n=matthew@76-10-132-230.dsl.teksavvy.com) |
| 04:20.09 |
*** join/#brlcad mvm92
(n=marcos@adsl-065-013-047-014.sip.mia.bellsouth.net) |
| 04:20.35 |
mvm92 |
anyone know
any good beginner tutorials for brlcad? |
| 04:55.19 |
talcite |
hey guys. I
need a bit of help with the build process. Is there a part of the
program that's being built against libwdb? |
| 04:55.37 |
talcite |
I'm having
build errors after rpaths were removed |
| 05:04.14 |
*** join/#brlcad talcite_
(n=matthew@69-165-150-27.dsl.teksavvy.com) |
| 06:20.18 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 06:56.58 |
*** join/#brlcad talcite_
(n=matthew@206-248-186-226.dsl.teksavvy.com) |
| 08:04.29 |
*** join/#brlcad LarsG
(n=lars@nusnet-189-109.dynip.nus.edu.sg) |
| 08:06.23 |
*** part/#brlcad LarsG
(n=lars@nusnet-189-109.dynip.nus.edu.sg) |
| 09:10.16 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 09:29.01 |
*** join/#brlcad mafm_
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 09:39.41 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 09:45.01 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 11:42.21 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 11:59.19 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 13:03.25 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 13:28.29 |
CIA-38 |
BRL-CAD:
03davidloman * r35509 10/rt^3/trunk/src/adminpanel/ (7 files):
Added a threaded CommandParser and an interface to support
abstraction of the object CommandParser passes its commands to.
Additionally, added socket Connect and Disconnect commands into
AdminControlPanel. |
| 13:32.03 |
CIA-38 |
BRL-CAD:
03davidloman * r35510 10/rt^3/trunk/src/adminpanel/CommandParser.h:
reduced visibility of copy constructor and internal command
checking function |
| 13:37.25 |
*** join/#brlcad roberthl
(n=robert@rhl.me.uk) |
| 14:23.56 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35511 10/rt^3/trunk/src/ (10 files in 10 dirs):
support "out of dir" builds |
| 14:48.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-175.sbndin.btas.verizon.net) |
| 15:17.01 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 15:22.41 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 15:38.45 |
``Erik |
nice. in
rt^3, cmake claims qmake cannot be found, but there it is
O.o |
| 15:38.52 |
d-lo |
lawl |
| 15:39.15 |
d-lo |
the classic
helpful post: Works for me! |
| 15:39.42 |
d-lo |
what flava of
cmake? |
| 15:40.04 |
``Erik |
cmake version
2.6-patch 4 |
| 15:40.29 |
``Erik |
ah, it's
search for qmake 4, but doesn't announce it the
messages |
| 15:40.49 |
``Erik |
on bsd, ois
fails to find Xlib.h (it's /usr/local/include/X11/Xlib.h, which
confuses things) |
| 15:41.02 |
d-lo |
hrm. |
| 15:41.09 |
d-lo |
and ois is an
ogre dep? |
| 15:41.27 |
``Erik |
src/other/ois/ |
| 15:41.45 |
d-lo |
right. I
think the only reason its there is because of ogre.
methinks |
| 15:41.59 |
``Erik |
comments it out |
| 15:42.33 |
d-lo |
are you
builing src/g3d or src/other/ogre? |
| 15:42.44 |
d-lo |
s/builing/building/ |
| 15:43.18 |
``Erik |
toplevel |
| 15:44.03 |
``Erik |
will fight it some more O.o |
| 15:45.32 |
``Erik |
nutty, it
actually build |
| 15:45.35 |
``Erik |
built |
| 15:45.46 |
d-lo |
in the
toplevel CMakeLists.txt, add '/usr/local/include/' to the
'INCLUDE_SEARCH_PATHS thingy |
| 15:46.09 |
d-lo |
mebbe that
will help it find x11. |
| 15:46.25 |
d-lo |
or did it
build it with ois already? |
| 15:47.35 |
``Erik |
I commented
it out |
| 15:47.44 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35512 10/rt^3/trunk/src/other/CMakeLists.txt:
comment out ois. Not needed for GS, and fails where X is in
/usr/local/ |
| 15:47.48 |
``Erik |
it smells
very not unix friendly... it's all "linux" crud |
| 15:48.07 |
``Erik |
damnit, svn
is retarded, I ^c'd that at the very beginning and it still went
and did it |
| 15:48.21 |
``Erik |
heh, and it
claims that commit failed. |
| 15:48.35 |
d-lo |
awesome. |
| 15:51.41 |
``Erik |
heh, it saved
it remote but forgot to update the local notion of what exists
remotely... transaction fail... |
| 15:51.58 |
``Erik |
goes luddite and bunkers in the land of cvs and automake
O.o |
| 15:54.52 |
CIA-38 |
BRL-CAD:
03davidloman * r35513 10/rt^3/trunk/CMakeLists.txt: added some
search paths for lib/ and include/ detection. |
| 15:59.56 |
``Erik |
doesn't seem
to fix it O.o |
| 16:00.10 |
d-lo |
k |
| 16:00.30 |
d-lo |
wonders why it works here.... |
| 16:02.33 |
d-lo |
so your
Xlib.h is in /usr/local/include/X11 and not /usr/include/X11
? |
| 16:30.22 |
*** join/#brlcad docelic
(n=docelic@78.134.205.187) |
| 16:34.27 |
*** join/#brlcad mafm
(n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 17:01.14 |
``Erik |
yeah |
| 17:02.15 |
``Erik |
historically,
/usr/lib was only for system libs, X would go in like /opt/X/lib or
/usr/X11R6 or even /etc/X/ ... linux craps everything in the same
place :/ |
| 17:07.35 |
*** join/#brlcad talcite_
(n=matthew@206-248-186-226.dsl.teksavvy.com) |
| 17:16.41 |
louipc |
etc fir
libs! |
| 17:20.11 |
CIA-38 |
BRL-CAD:
03davidloman * r35514 10/rt^3/trunk/ (8 files in 4 dirs): Removal
of antiquated classes |
| 17:20.35 |
CIA-38 |
BRL-CAD:
03davidloman * r35515 10/rt^3/trunk/ (8 files in 4 dirs):
Implementation of netProto handshaking. |
| 17:21.54 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FB4F.dip.t-dialin.net) |
| 17:25.20 |
``Erik |
etc used to
be a misc dir, not a config dir... :) |
| 17:30.14 |
talcite_ |
brlcad:
ping? |
| 17:40.11 |
``Erik |
talcite_work:
libwdb? it's a part of BRL-CAD and used by many
things... |
| 17:42.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-175.sbndin.btas.verizon.net) |
| 18:18.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-175.sbndin.btas.verizon.net) |
| 18:38.21 |
*** join/#brlcad talcite
(n=talcite@134.117.108.108) |
| 18:41.44 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35516 10/brlcad/trunk/src/adrt/librender/cut.c:
fix lame bug, make cut work again. |
| 18:42.27 |
talcite |
do you guys
know when the next release is likely to come out? |
| 18:42.41 |
louipc |
'soon'
:D |
| 18:43.54 |
talcite |
haha alright.
No rush. I need to weed out all of these rpath problems |
| 18:44.24 |
louipc |
I guess your
packaging will be made slightly easier then eh? |
| 18:44.52 |
talcite |
well, it
looks better if I'm packaging a release than a SVN
revision |
| 18:45.05 |
talcite |
but it's not
a huge issue, you see SVN packages sometimes in the
repos |
| 18:45.24 |
talcite |
what's more
pressing though is that rttherm is using rpaths and won't compile
without them |
| 18:45.28 |
louipc |
I hear that
itcl/tk will it into mainline tcl/tk |
| 18:45.34 |
louipc |
that will be
great |
| 18:45.38 |
talcite |
cool.
Yeah |
| 18:45.54 |
louipc |
yea |
| 18:57.02 |
``Erik |
next release
should be "any day now", brlcad was trying to push it out before
siggraph, but didn't quite manage *shrug* and now I imagine he's in
a coma recouping |
| 18:57.17 |
``Erik |
isn't exactly sure what the stoppers are, or woulda done it
last week |
| 19:02.57 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 20:17.30 |
*** join/#brlcad mafm
(n=mafm@129.Red-83-49-86.dynamicIP.rima-tde.net) |
| 20:45.29 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 20:45.42 |
elena |
hi,
all. |
| 20:53.18 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35517 10/brlcad/trunk/src/adrt/librender/cut.c:
get visible line rendering again. |
| 20:58.02 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35518 10/brlcad/trunk/TODO: adrt split view
cutting plane is back. knock it off the list! |
| 21:29.52 |
CIA-38 |
BRL-CAD:
03ebautu 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (insert model: ) |
| 21:31.19 |
*** join/#brlcad elena1
(n=elena@89.136.118.141) |
| 21:31.32 |
CIA-38 |
BRL-CAD:
03ebautu 07http://more.brlcad.org * r24 10Model
repository/: Havoc (insert model: ) |
| 21:33.08 |
CIA-38 |
BRL-CAD:
03ebautu 07http://more.brlcad.org * r25 10Model
repository/: Tank car (insert model: ) |
| 22:01.13 |
CIA-38 |
BRL-CAD: 03
07http://more.brlcad.org * r23
10Model repository/: bldg391 (update model: BRLCAD processing
completed.) |
| 22:06.39 |
CIA-38 |
BRL-CAD: 03
07http://more.brlcad.org * r24
10Model repository/: Havoc (update model: BRLCAD processing
completed.) |
| 22:08.07 |
CIA-38 |
BRL-CAD: 03
07http://more.brlcad.org * r25
10Model repository/: Tank car (update model: BRLCAD processing
completed.) |
| 22:18.16 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 22:55.09 |
``Erik |
huh, a
seggie |
| 22:55.27 |
starseeker |
segway?
;-) |
| 22:56.55 |
``Erik |
heh, didja
see paul grahams essay about segways? and the ensuing
nerdrama? |
| 22:57.27 |
starseeker |
no - where's
that? |
| 22:57.49 |
starseeker |
oh, nice work
with the cuting plane |
| 22:58.07 |
``Erik |
um,
paulgraham.com/essays/ ? :) |
| 22:58.18 |
``Erik |
was on hn a
bit ago |
| 22:58.39 |
``Erik |
(all things
pg are on hn... irritating how much cocksucking goes on
there) |
| 22:58.55 |
``Erik |
yeah, heh..
the cutting plane... turns out that (a+b)*c != a+(b*c) |
| 22:58.57 |
``Erik |
O:-) |
| 22:59.58 |
starseeker |
ow |
| 23:00.08 |
starseeker |
when did that
sneak in? |
| 23:00.26 |
starseeker |
wants to see a demo :-)) |
| 23:01.29 |
``Erik |
um, there
were a bunch of a[0] += c*b[0]; etc, and I grabbed VADD2SCALE() not
paying attention to the parens |
| 23:01.35 |
``Erik |
file was
riddle with those, musta had an off day |
| 23:01.39 |
starseeker |
ah |
| 23:01.47 |
starseeker |
can I run it
yet? |
| 23:01.56 |
starseeker |
looks for binary... |
| 23:01.58 |
``Erik |
install the
latest brlcad, install isst, put ktank.g in /tmp/ and run
isst |
| 23:02.20 |
``Erik |
left click
zooms in and out, right click rotates, middle click
pans |
| 23:02.25 |
starseeker |
is isst in
its own tree? |
| 23:02.28 |
``Erik |
yeah |
| 23:02.31 |
``Erik |
requires
gtk+ |
| 23:02.52 |
starseeker |
ah |
| 23:03.19 |
``Erik |
also requires
/usr/brlcad/include and
/usr/brlcad/lib/librt.{so,dylib,dll} |
| 23:04.22 |
``Erik |
(if I recall
my winderz, it SHOULD compile just fine with msvc or mingw, but if
you happen to know the fu to try to make it go into distributed
mode, it'll fail due to WSAStartup() not being called) |
| 23:06.26 |
``Erik |
(given the
cracking of the hard outer shell, btw, I would like a chatter
session among the BRL-CAD cabal in the very near
future...) |
| 23:06.49 |
jdoliner |
hey can
anyone explain to me how to use user values in
opennurbs |
| 23:07.30 |
``Erik |
file:line
? |
| 23:08.08 |
``Erik |
<--
doesn't know, but is good at mindlessly jabbering, things he
managed to help indianlarry with a fugly c++ oddity in spite of
being anti-c++ :) |
| 23:09.26 |
jdoliner |
you can find
them in opennurbs_x.h line:338 |
| 23:09.36 |
jdoliner |
there are of
type ON_U |
| 23:09.43 |
jdoliner |
which I can't
find declared anywhere |
| 23:12.19 |
starseeker |
jdoliner:
what are you trying to do? |
| 23:12.27 |
starseeker |
is it
something not in opennurbs_userdata.h? |
| 23:13.13 |
starseeker |
perhaps
example_userdata/example_userdata.cpp has something
helpful? |
| 23:13.21 |
jdoliner |
thanks let me
check that |
| 23:15.55 |
jdoliner |
I could be
really wrong but I think user data is a different thing |
| 23:16.06 |
starseeker |
isn't sure |
| 23:16.25 |
jdoliner |
m_user is
supposed to be just a scratch field on some of their
classes |
| 23:16.31 |
``Erik |
um |
| 23:16.39 |
jdoliner |
all I'm doing
is setting it to a number and then checking which number I set it
to |
| 23:16.45 |
starseeker |
I see it used
only in brep.h and brep.cpp |
| 23:17.16 |
starseeker |
what are you
trying to achieve? |
| 23:18.40 |
jdoliner |
basically I
have an array of ON_X_EVENTS that record intersections between a
pair of 2dcurves and the respective trims in the faces they're
going to go into |
| 23:18.51 |
*** join/#brlcad docelic_
(n=docelic@78.134.195.74) |
| 23:18.55 |
jdoliner |
I use that
field to record which curve the intersection occurred
in |
| 23:19.04 |
jdoliner |
curve1 or
curve2 |
| 23:19.09 |
starseeker |
Hmm. I doubt
that's the right place... |
| 23:19.11 |
``Erik |
ok, it IS
compiled, must be a generated symbol |
| 23:20.05 |
jdoliner |
the error i'm
getting is when i do m_user == 0 |
| 23:20.05 |
starseeker |
jdoliner: any
reason you can't hang that info on the BRL-CAD primitive as an
attribute? |
| 23:20.43 |
``Erik |
ON_U is
cooked up as a union |
| 23:20.56 |
jdoliner |
oh |
| 23:21.02 |
jdoliner |
so if I do
m_user.int |
| 23:21.08 |
jdoliner |
then it will
cast it as an int |
| 23:21.15 |
``Erik |
opennurbs_define.h:204 |
| 23:22.07 |
jdoliner |
aha |
| 23:22.18 |
jdoliner |
that should
do it then |
| 23:22.23 |
``Erik |
doesn't
answer starseekers question, though |
| 23:22.26 |
jdoliner |
I'm not sure
how I managed to miss that with my search |
| 23:22.27 |
jdoliner |
yes |
| 23:22.37 |
``Erik |
that's how to
fix it, but ... is that REALLY what you want to do? |
| 23:22.44 |
jdoliner |
is there a
brl-cad ON_X_EVENT primitive? |
| 23:22.55 |
jdoliner |
i'm a little
foggy on what you meant by that |
| 23:23.44 |
``Erik |
is unfamiliar with "ON_X_EVENT" |
| 23:24.03 |
``Erik |
translate to
non-opennurbs, please? :) |
| 23:24.05 |
jdoliner |
ON_X_EVENT is
a record of an intersection between 2 curves |
| 23:24.14 |
jdoliner |
or between a
curve and a surface |
| 23:24.34 |
jdoliner |
it has all
the relevant information bundled up in it |
| 23:25.00 |
jdoliner |
being the
points of intersection themselves |
| 23:25.07 |
``Erik |
ok, so
literally "opennurbs cross event"? |
| 23:25.08 |
jdoliner |
the
paramaters they occurred at |
| 23:25.14 |
jdoliner |
yeah |
| 23:25.26 |
``Erik |
my initial
reading was "if something happens in X windows" :) |
| 23:25.48 |
``Erik |
(erm, X
windowing system, or X... don't flame me) |
| 23:25.50 |
jdoliner |
yeah, I
actually thought that to at fiest |
| 23:26.22 |
jdoliner |
so they also
have a field m_user |
| 23:26.36 |
``Erik |
well, there
ya is... it's a raw union... those're dangerous as they lack any
kinda magic to do checking on :/ |
| 23:26.37 |
jdoliner |
which is just
a scratch field for anything you might want to use it
for |
| 23:27.01 |
``Erik |
a common C
pattern is struct poo_s { int magic; union v { ... } }; |
| 23:27.33 |
``Erik |
then you can
switch(mypoo.magic){ case SOMETHING: mypoo.v.something = x; ...
} |
| 23:28.03 |
jdoliner |
yeah I agree
it's dangerous, here's why I think it will be okay |
| 23:28.58 |
``Erik |
*shrug* ya
don't have to defend yourself |
| 23:29.05 |
``Erik |
I'm just
pointing out the danger :) |
| 23:29.06 |
jdoliner |
these values
are all set within a class and then used read out by that same
class, the ON_X_EVENTS are never touched by outside
functions |
| 23:29.21 |
jdoliner |
oh but I like
to |
| 23:29.46 |
jdoliner |
I'd defend
myself to my goldfish or something if I didn't have real
people |
| 23:29.56 |
jdoliner |
I always wind
up noticing flaws that way |
| 23:30.47 |
``Erik |
if you grep
the BRL-CAD, you'll find quite a few instances of goto... *shrug*
personally, I'm reluctant to permit them in anything I touch, but
sometimes you gotta go use something that is generally considered
evil |
| 23:31.02 |
``Erik |
s/,/
src,/ |
| 23:31.55 |
``Erik |
(naked unions
stink to me, it's damn cheap to shove a union in a struct with a
type field) |
| 23:41.08 |
``Erik |
starseeker:
did you manage to get it up and running? |
| 23:43.15 |
starseeker |
nah, I'm on a
mac which (afaik) has no gtk install |
| 23:43.25 |
starseeker |
will try it at home |
| 23:46.19 |
``Erik |
ah,
bummer |
| 23:46.47 |
starseeker |
``Erik: so
now you're essentiall as robust as our tesselation? |
| 23:46.48 |
``Erik |
you're still
at the office? |
| 23:46.52 |
starseeker |
yep |
| 23:46.57 |
``Erik |
um, for the
most part, I think... |
| 23:47.07 |
``Erik |
there're
still modes which'll call bu_bomb |
| 23:47.09 |
starseeker |
just got here not too long ago - it's been a crazy
day |
| 23:47.20 |
``Erik |
use bobs
linux box? :) |
| 23:47.24 |
starseeker |
heh |
| 23:47.59 |
``Erik |
I want to
re-write teh gui to use tk and libfb, so I can put it right in
BRL-CAD :/ |
| 23:48.14 |
starseeker |
nods |
| 23:48.20 |
starseeker |
see if you
can integrate it with Archer |
| 23:48.30 |
``Erik |
and enable a
plugin system that sends the "mode specific" panel via tk across
the wire |
| 23:48.33 |
starseeker |
ttk widgets
Suck (slightly) Less (tm) |
| 23:50.25 |
``Erik |
(frankly,
it's neat and all, but I"d like to get it spooled where someone
else is dicking with it and I can go do other
things...) |
| 00:02.01 |
brlcad |
ah, so I
think I see how it's tied in yet .. don't think anything else is
using ged_reopen just yet so it very well could be
incomplete |
| 00:03.16 |
brlcad |
mged does
it's own thing (see f_opendb() in src/mged/mged.c) and archer goes
through the old display object interface
(src/libged/dg_obj.c) |
| 00:03.35 |
brlcad |
so might want
to reconcile what f_opendb() is doing with what ged_reopen() is
doing |
| 00:03.50 |
brlcad |
s/might
want/you need/ :) |
| 00:04.38 |
brlcad |
talcite:
pongish |
| 00:05.38 |
brlcad |
talcite: what
rpath "problem"? rpaths are set by libtool, which are managed
primarily by automake built-in macro expansions |
| 00:06.05 |
brlcad |
you shouldn't
be mucking with the rpaths else you will likely encounter
dragons |
| 00:07.50 |
brlcad |
``Erik: you
can register a bu_bomb handler to tell it to keep going (if you
haven't figured that out by now) |
| 00:08.02 |
``Erik |
hrm?
whu? |
| 00:08.06 |
brlcad |
(related to
earlier tessellation talkage) |
| 00:08.32 |
``Erik |
<--
doesn't recall which tessellation talkage |
| 00:08.59 |
brlcad |
tk+libfb
ftw |
| 00:09.06 |
``Erik |
heh |
| 00:10.03 |
``Erik |
tk is making
me a sad panda |
| 00:10.27 |
``Erik |
I can't
rotate objects in mged anymore, it executes on mouse down instead
of mouse up, so it reads it as a zoom in command |
| 00:16.13 |
brlcad |
wonders if jdoliner wins when he defends himself to his
goldfish |
| 00:16.37 |
``Erik |
obviously you
haven't talked to joe much ;> *duck* |
| 00:17.06 |
``Erik |
it is gettin'
to be wrapup time, though |
| 00:17.40 |
brlcad |
there aren't
any release stoppers that I know of, so we should be good to
release .. it has just been coma/sinus recouping .. *ship
it!* |
| 00:18.30 |
brlcad |
ughs at the automatic search paths being added for X content
instead of specifying or detecting |
| 00:19.05 |
brlcad |
finishes spewing from recent backlog |
| 00:19.26 |
brlcad |
``Erik:
you're on 10.5 right? |
| 00:19.36 |
``Erik |
yeah, but I'm
seeing the behavior on both .5 and .4 |
| 00:19.53 |
``Erik |
(if you're
asking about the mouse rotate issue) |
| 00:20.04 |
``Erik |
also; opendb
/path/to/castle.g ; E all.g |
| 00:20.07 |
``Erik |
:D |
| 00:20.10 |
brlcad |
nick found a
way to hit keys before/during the mouse events that lets him rotate
smooth |
| 00:20.13 |
brlcad |
tricking
it |
| 00:20.30 |
``Erik |
eh? |
| 00:20.35 |
brlcad |
or there's
hitting the xyzXYZ keys |
| 00:21.20 |
brlcad |
and yeah,
just a couple more days before pens down |
| 00:21.27 |
``Erik |
I don't fire
up mged often enough to worry, and almost never e anything up...
was just something I kinda noticed, not sure if it's due to
something funky on my stuff or an actual issue |
| 00:21.44 |
*** join/#brlcad Patmcc19_
(n=chatzill@174-17-172-168.phnx.qwest.net) |
| 00:21.53 |
brlcad |
yeah, I had a
regress test that took each of our example .g files and would
tessellate each one .. it was too painful to commit |
| 00:22.06 |
brlcad |
the crash is
new |
| 00:22.07 |
``Erik |
hehehe |
| 00:22.37 |
brlcad |
i think that
input problem is probably a release stopper for mac
binaries |
| 00:22.51 |
brlcad |
i fixed all
the other mac problems |
| 00:22.59 |
brlcad |
but hadn't
got to that one before siggraph |
| 00:23.12 |
brlcad |
not enough to
stop a source release though, nothing new |
| 00:24.16 |
``Erik |
hm, the null
hack for linux finally got on smacksnot |
| 00:29.10 |
``Erik |
huh, a
retrograde orbiting exoplanet (amazing how little we know about
exoplanets... we only know the orbit direction for a dozen or
so?) |
| 00:40.01 |
CIA-38 |
BRL-CAD:
03johnranderson * r35543 10/brlcad/trunk/src/libged/bigE.c: "E"
command was always failing because it was not adding solids to the
"ged_display_list". Now adds the solids. |
| 00:41.14 |
``Erik |
hah |
| 00:41.18 |
``Erik |
that'd be the
castle crash, I bet |
| 00:46.48 |
brlcad |
go go gadget
anderson |
| 01:07.10 |
``Erik |
they're
making a game... knocking off a movie... knocking off an 80's
cartoon... |
| 01:07.20 |
``Erik |
knocking off
a 50's toy |
| 01:07.47 |
``Erik |
60's,
sorry |
| 01:08.24 |
``Erik |
(knocking off
a 60's tv show I'd never heard of) |
| 01:17.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 03:24.22 |
``Erik |
ls |
| 03:24.25 |
``Erik |
doh |
| 04:24.42 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 06:31.09 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 06:37.01 |
*** join/#brlcad talcite_
(n=matthew@75-119-230-162.dsl.teksavvy.com) |
| 06:57.27 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 06:58.46 |
elena |
~log |
| 07:12.54 |
brlcad |
~logs |
| 07:12.55 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 07:52.31 |
*** join/#brlcad talcite__
(n=matthew@76-10-171-69.dsl.teksavvy.com) |
| 08:44.01 |
CIA-38 |
BRL-CAD:
03ebautu * r35544 10/web/trunk/htdocs/more/sites/all/ (30 files in
3 dirs): Implemented links for sharing services. |
| 09:08.29 |
*** join/#brlcad talcite_
(n=matthew@69-165-133-209.dsl.teksavvy.com) |
| 09:10.09 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r21 10Model
repository/: Axis example (update model: BRLCAD processing
completed.) |
| 09:10.21 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r22 10Model
repository/: Boolean operations (update model: BRLCAD processing
completed.) |
| 09:10.24 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (update model: BRLCAD processing
completed.) |
| 09:10.37 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r24 10Model
repository/: Havoc (update model: BRLCAD processing
completed.) |
| 09:10.44 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r25 10Model
repository/: Tank car (update model: BRLCAD processing
completed.) |
| 09:12.15 |
CIA-38 |
BRL-CAD:
03ebautu * r35545
10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/node-model.tpl.php:
Fix links themeing for anonymous users. |
| 09:13.24 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r25 10Model
repository/: Tank car (update model: ) |
| 09:14.09 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r24 10Model
repository/: Havoc (update model: ) |
| 09:14.18 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (update model: ) |
| 09:14.29 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r22 10Model
repository/: Boolean operations (update model: ) |
| 09:14.38 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r21 10Model
repository/: Axis example (update model: ) |
| 09:15.18 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r25 10Model
repository/: Tank car (update model: BRLCAD processing
completed.) |
| 09:15.53 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r21 10Model
repository/: Axis example (update model: BRLCAD processing
completed.) |
| 09:16.02 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r22 10Model
repository/: Boolean operations (update model: BRLCAD processing
completed.) |
| 09:16.11 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (update model: BRLCAD processing
completed.) |
| 09:16.21 |
CIA-38 |
BRL-CAD:
03admin 07http://more.brlcad.org * r24 10Model
repository/: Havoc (update model: BRLCAD processing
completed.) |
| 09:47.56 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 10:53.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 12:27.35 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 12:37.38 |
brlcad |
oh that's
cool |
| 13:11.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FACE.dip.t-dialin.net) |
| 13:13.04 |
``Erik |
? |
| 14:23.59 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 15:04.26 |
brlcad |
the model
notifications |
| 15:04.59 |
brlcad |
noficiations
when it's added and when processing is completed .. which looks
like was about 5 minues for those tiny models :) |
| 15:15.09 |
CIA-38 |
BRL-CAD:
03brlcad * r35546 10/brlcad/trunk/src/rt/viewedge.c: minor tweaks
for syncing antialias work |
| 15:26.08 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35547 10/isst/trunk/src/ (gui.c isst.h load_g.c
main.c): specify db/regions from command line. |
| 16:41.59 |
brlcad |
haha |
| 16:42.05 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:42.11 |
brlcad |
howdy
joe! |
| 16:42.16 |
jdoliner |
hi |
| 16:42.30 |
jdoliner |
I haven't
seen you in a while sean |
| 16:42.35 |
brlcad |
was just
going through some of your commits yesterday |
| 16:42.40 |
brlcad |
yeah, was
away on travel |
| 16:42.47 |
brlcad |
been a busy
couple weeks |
| 16:42.48 |
jdoliner |
yes, thoughts
plz |
| 16:42.58 |
brlcad |
seen the
chatter in here and commits, though |
| 16:43.25 |
brlcad |
well, how're
things going? |
| 16:43.39 |
brlcad |
i noticed you
were working on curve/face crossings for the face-face
intersections |
| 16:44.02 |
jdoliner |
yes |
| 16:44.22 |
jdoliner |
you mean in
the FindStartPoints_Internal? |
| 16:46.53 |
jdoliner |
sry that
function is actualy GetStartPointsInternal |
| 16:56.59 |
brlcad |
mm, i'd have
to dig back through the commits |
| 16:57.50 |
brlcad |
Curve_X_Profile() is what I had in
mind |
| 16:57.56 |
jdoliner |
don't
bother |
| 16:57.58 |
brlcad |
and
FaceFaceIntersect() |
| 16:59.07 |
jdoliner |
yeah,
Curve_X_Profile was actually an idea that I never wound up
using |
| 16:59.11 |
jdoliner |
I'll remove
that soon |
| 16:59.21 |
jdoliner |
but facface
intersect is the workhorse |
| 17:00.50 |
jdoliner |
FaceFaceIntersect does all the work of
creating the Face_X_Events |
| 17:01.07 |
brlcad |
cool |
| 17:01.15 |
jdoliner |
which are
basically ON_X_Events but for two faces |
| 17:01.22 |
brlcad |
that does
sound like the most important piece :) |
| 17:01.29 |
jdoliner |
yeah
:) |
| 17:01.44 |
jdoliner |
it uses the
numeric method of walking the intersection curve |
| 17:01.54 |
brlcad |
were talking
yesterday about evaluating a given CSG operation as just the
resulting surface intersections, finding those curves, attaching
them as trims, and just feeding the result to opengl for
visualization |
| 17:02.38 |
brlcad |
as a 'first
step' of sorts, for visualization of arbitrary objects via shaded
displays/opengl |
| 17:03.12 |
jdoliner |
I
see, |
| 17:03.37 |
jdoliner |
ultimately
would we like to just 'freeze' faces to have only 1 external
trim? |
| 17:09.58 |
brlcad |
what do you
mean? |
| 17:11.00 |
brlcad |
multiple
trimming curves are normal |
| 17:11.07 |
brlcad |
or do you
mean one trimming loop? |
| 17:11.09 |
jdoliner |
well at the
end we're going to end up with faces with a whole bunch of
trims |
| 17:11.22 |
jdoliner |
yeah i mean
loops |
| 17:11.58 |
brlcad |
yeah, ideally
minimal loops but even that shouldn't be a problem to have multiple
ones |
| 17:12.22 |
jdoliner |
k |
| 17:12.49 |
brlcad |
will probably
want some means to simplify, though -- if a loop is fully contained
within another, eliminate it; if it intersects, weave it in,
etc |
| 17:13.19 |
jdoliner |
yes, I
actually already have it setup to weave intersecting loops
in |
| 17:14.21 |
jdoliner |
also if it
has 2 distinct external loops that should be an easy
simplification |
| 17:14.22 |
brlcad |
awesome |
| 17:34.43 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35548 10/isst/trunk/src/ (Makefile.am gui.c
isst.h load_g.c main.c): break worker functions out into their own
files |
| 17:36.47 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35549 10/isst/trunk/src/test.c: rm dead
file |
| 17:38.01 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35550 10/isst/trunk/src/ (local_worker.c
net_worker.c): break worker functions out into their own
files |
| 17:38.28 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35551 10/isst/trunk/src/poo.g: rm dead
file |
| 17:39.36 |
*** join/#brlcad talcite_
(n=matthew@69-165-133-209.dsl.teksavvy.com) |
| 17:45.19 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35552 10/isst/trunk/src/net_worker.c:
bcopy->memcpy |
| 17:47.55 |
talcite_ |
hey brlcad,
can I get your help in changing the configure script from using
libtool runpaths to convenience libraries? |
| 17:54.21 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35553 10/isst/trunk/src/ (gui.c isst.h
local_worker.c net_worker.c): remove gtk requirement from
local_worker |
| 18:07.12 |
brlcad |
talcite_: not
sure what you mean by that exactly |
| 18:07.27 |
brlcad |
talcite_: the
convenience libraries aren't installed |
| 18:08.56 |
talcite_ |
brlcad: yeah.
I'm just trying to remove all of the libtool runpaths and create
partially linked executables so they're compliant with fedora
guidelines |
| 18:09.17 |
talcite_ |
brlcad: I'm
not sure what you mean by the convenience libraries aren't
installed |
| 18:10.12 |
brlcad |
libtool
"convenience libraries" are, by definition, not installed
:) |
| 18:10.21 |
brlcad |
http://sources.redhat.com/autobook/autobook/autobook_92.html |
| 18:10.31 |
brlcad |
note the
"noinst" |
| 18:12.52 |
brlcad |
can you give
a reference to those fedora guidelines? 'partially linked
executables' can mean a lot of things or nothing at all |
| 18:14.01 |
brlcad |
the default
build is shared libraries with dynamic linkage |
| 18:15.09 |
brlcad |
all i've ever
heard fedora guideline-wise was that they (rightfully) prefer
non-static compilation/linkage so dependencies can be properly
updated and managed |
| 18:17.11 |
talcite_ |
brlcad:
http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath |
| 18:17.16 |
brlcad |
yeah, just
found that |
| 18:17.49 |
talcite_ |
sorry for the
slow reply, I was just reading over the autotools book page you
sent me. I haven't seen that one before |
| 18:17.55 |
brlcad |
that's not
what I'd consider having much to do with "partially linked
executables" ;) |
| 18:18.13 |
talcite_ |
ahh, sorry
for the confusing terminology |
| 18:18.19 |
brlcad |
yeah, I think
you're just calling them the wrong thing |
| 18:18.36 |
brlcad |
I think you
just mean our installed libraries |
| 18:18.46 |
brlcad |
so did you
try --disable-rpath? |
| 18:18.56 |
talcite_ |
yup, it
didn't do anything |
| 18:19.19 |
brlcad |
did you
already have a libtool script generated? |
| 18:19.30 |
talcite_ |
also,
removing the hardcode_libdir_flag_spec didn't do
anything |
| 18:19.50 |
talcite_ |
brlcad:
libtool script generated? |
| 18:20.06 |
brlcad |
no used gnu
autotools much I take it? :) |
| 18:20.32 |
talcite_ |
I'm just
running everything from sh autogen.sh to make install in the spec
file |
| 18:20.40 |
talcite_ |
brlcad: no, I
haven't heh |
| 18:20.56 |
brlcad |
when you run
our configure, it spits out a script called 'libtool' |
| 18:21.23 |
brlcad |
that script
is wired into the Makefiles automatically by automake |
| 18:21.53 |
brlcad |
so during
make, the build invokes that libtool script for all
linkage |
| 18:22.01 |
*** join/#brlcad docelic
(n=docelic@78.134.200.109) |
| 18:22.20 |
talcite_ |
yeah, I've
seen that script being used |
| 18:22.36 |
talcite_ |
I haven't
done anything like generate my own though |
| 18:22.48 |
brlcad |
that script
encapsulates all logic on how to build libraries and link binaries
(static and dynamic), and is otherwise mostly a "black box" that
you just run .. minus a few knobs you can manually tweak to
override what the gnu folks think is best |
| 18:24.03 |
brlcad |
the "sh
autogen.sh" step turns the configure.ac file into the venerable
configure script and all the Makefile.am automake template files
into Makefile.in autoconf template files |
| 18:24.20 |
talcite_ |
yup |
| 18:24.44 |
brlcad |
when you run
"./configure --whatever..." that turns all the Makefile.in files
into Makefile files and generates the libtool script if it's a
libtool-enabled project (which we obviously are) |
| 18:25.06 |
brlcad |
okay, so back
to the problem at hand.. post up your libtool script
somewhere |
| 18:25.30 |
brlcad |
their
guideline are either out of date with the latest libtool, or ya did
something wrong |
| 18:26.22 |
talcite_ |
brlcad:
http://fpaste.org/NZS3/ |
| 18:27.27 |
talcite_ |
brlcad: well
going through the build logs shows the -rpath argument being passed
to libtool several times |
| 18:29.12 |
brlcad |
well the good
news is the libtool script doesn't force it |
| 18:31.16 |
talcite_ |
brlcad: would
the configure script help? |
| 18:31.26 |
brlcad |
note
yet |
| 18:32.59 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 18:33.49 |
brlcad |
did you
verify that it's actually generating installed binaries with an
rpath set? |
| 18:34.18 |
talcite_ |
brlcad: yeah.
Fedora has a check_rpaths tool built into rpmbuild |
| 18:34.51 |
brlcad |
I know, I'm
saying you've checked them explicitly since having ran those
regex's on the libtool script, not just noticed the --rpath cmdline
option |
| 18:35.00 |
brlcad |
more
specifically, noticed post-install |
| 18:35.10 |
brlcad |
libtool is a
multiphase interface, it knows the difference between compilation,
preinstall, and postinstall |
| 18:35.51 |
brlcad |
not saying
that'll do it, but worth checking before going further down the
rabbit hole |
| 18:35.52 |
talcite_ |
brlcad: yeah.
check-rpaths runs after the rpm is generated, then it goes over the
binaries |
| 18:43.31 |
brlcad |
talcite_:
grep -A1 "checking how to hardcode library paths into programs"
brlcad/config.log | grep result |
| 18:44.21 |
talcite_ |
configure:20803: result:
immediate |
| 18:44.21 |
talcite_ |
configure:24617: result:
immediate |
| 18:46.04 |
brlcad |
hm |
| 18:51.04 |
brlcad |
lets try some
more aggressive libtool mods.. |
| 18:51.14 |
brlcad |
try
this: |
| 18:51.46 |
brlcad |
sed -e
s/^hardcode_direct.*$/hardcode_direct=yes/g libtool || sed -e
s/^hardcode_minus_L.*$/hardcode_minus_L=yes/g || sed -e
s/^hardcode_shlibpath_var.*$/hardcode_shlibpath_var=no/g >
libtool.new |
| 18:52.04 |
brlcad |
mv libtool
libtool.old && mv libtool.new libtool |
| 18:52.23 |
brlcad |
diff libtool
libtool.old .. should see at least three lines changed |
| 18:53.54 |
brlcad |
can either
add that sed and mv to configure.ac after BC_PATCH_LIBTOOL (after
making sure it works manually first), or make it a step after
./configure |
| 18:54.36 |
talcite_ |
man that sed
was huge |
| 18:56.11 |
CIA-38 |
BRL-CAD:
03starseeker * r35554 10/brlcad/trunk/src/proc-db/ (Makefile.am
csgbrep.cpp): |
| 18:56.11 |
CIA-38 |
BRL-CAD: Add
the skeleton for a csgbrep proc-db - eventually this will be used
to do |
| 18:56.11 |
CIA-38 |
BRL-CAD:
examples of all of the primitives going from an implicit to a
NURBS |
| 18:56.11 |
CIA-38 |
BRL-CAD:
representation. At the moment it looks like the ability to do this
is not yet |
| 18:56.11 |
CIA-38 |
BRL-CAD: set
up, so need to wire in the rt_*_brep ability to some sort of public
API. |
| 18:56.25 |
talcite_ |
brlcad: your
i/o redirection isn't working |
| 18:56.31 |
brlcad |
oh, might
want to add one more, sed -e
's/(hardcode_into_libs)=.*$/\1=no/' |
| 18:56.58 |
brlcad |
that was
three seds |
| 18:57.04 |
brlcad |
so four with
the last one |
| 18:57.36 |
talcite_ |
brlcad: I'm
not really sure what you did with the || , but the sed stuff just
outputs to stdout |
| 18:57.39 |
brlcad |
and the ||'s
should be just |'s .. typo |
| 18:57.43 |
talcite_ |
it isn't
getting redirected to libtool.new |
| 18:57.47 |
talcite_ |
oh
ok |
| 18:58.07 |
brlcad |
they were
pre-escaped for m4 |
| 18:58.12 |
talcite_ |
oh... |
| 18:59.17 |
brlcad |
might just
make that last/fourth one be like the rest:
s/^hardcode_into_libs.*$/hardcode_into_libs=no/g |
| 19:01.04 |
talcite_ |
brlcad: lots
of changes |
| 19:01.18 |
talcite_ |
I can try
building now if you'd like |
| 19:01.26 |
brlcad |
no, paste the
diff |
| 19:01.30 |
talcite_ |
k |
| 19:01.31 |
brlcad |
diff
-u |
| 19:02.07 |
talcite_ |
http://fpaste.org/h4EL/ |
| 19:04.05 |
brlcad |
hm,
almost |
| 19:04.44 |
brlcad |
make the
first one, s/^hardcode_direct=.*$/hardcode_direct=yes/g |
| 19:04.50 |
brlcad |
repaste |
| 19:08.19 |
talcite_ |
http://fpaste.org/ENoS/ |
| 19:09.10 |
starseeker |
brlcad: I'm
slightly twisted up - the rt_sph_brep and rt_ell_brep functions
aren't accessible directly, and upon reflection should probably be
called through rt_functab like all the other primitive functions.
But what about situations like wdb where we have (say) the sphere
parameters and want to generate the resulting nurbs without
detouring through creating the implicit version of the primitive?
(We could, of course, but that would mean a write AND |
| 19:13.04 |
CIA-38 |
BRL-CAD:
03jdoliner * r35555
10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: BrepBrepIntersect
now cycles through all the pairings of faces and gets their
intersections accurately |
| 19:15.14 |
brlcad |
talcite_:
that looks great, give that a test |
| 19:15.19 |
brlcad |
with a clean
build |
| 19:15.31 |
talcite_ |
brlcad:
sure |
| 19:15.43 |
brlcad |
it'll still
pass --rpath on the command line, but it should think that it
doesn't need to do anything |
| 19:16.12 |
brlcad |
if that
doesn't work, we can probably just trick up the --rpath option in
the script |
| 19:17.02 |
brlcad |
starseeker:
they weren't added to the functab just because it's woefully
incomplete -- but they are directly accessible |
| 19:17.39 |
brlcad |
and your
message was too long, cut off after AND |
| 19:19.28 |
talcite_ |
brlcad:
sounds good. I've started the build process. It'll be 17 minutes or
something |
| 19:19.44 |
brlcad |
you can just
call rt_*_brep() for testing purposes to make sure things are
working .. once they're working or as they're working, can add them
to functab |
| 19:19.49 |
brlcad |
talcite_:
k |
| 19:21.21 |
brlcad |
starseeker: I
also wouldn't want to double-up the API just for a representation
type -- the idea would probably be to create an in-memory-only
object and then make the functab call on it for a given
representation type |
| 19:21.48 |
brlcad |
or they
create a nurbs object via opennurbs and write out using
mk_brep() |
| 19:23.56 |
talcite_ |
brlcad: looks
like we're getting somewhere. It's calling ld now |
| 19:24.04 |
talcite_ |
brlcad: but
we have a make error |
| 19:24.29 |
talcite_ |
brlcad:
http://fpaste.org/3jXm/ |
| 19:25.20 |
brlcad |
heh, well it
certainly seems to have worked :) |
| 19:26.52 |
brlcad |
cd
/home/matthew/rpmbuild/BUILD/brlcad-SVN_010809/src/other/URToolkit/cnv/rletoabA62 |
| 19:27.05 |
brlcad |
/bin/sh
../../../../../libtool --tag=CC --mode=link gcc
-I../../../../../src/other/libutahrle/include -O2 -g -pipe
-fno-strict-aliasing -fno-common -fexceptions -m64 -g -O3
-L/usr/local/lib64 -L/usr/local/lib -pipe -fno-strict-aliasing
-fno-common -fexceptions -m64 -g -O3 -o rletoabA62 rletoabA62-rle.o
rletoabA62-rletoabA62.o
../../../../../src/other/libutahrle/libutahrle.la |
| 19:27.11 |
brlcad |
(run
that) |
| 19:27.26 |
brlcad |
paste the
really long gcc line that it spits back |
| 19:27.39 |
talcite_ |
libtool:
link: LD_LIBRARY_PATH="../../../../../src/other/libutahrle/.libs:"
gcc -I../../../../../src/other/libutahrle/include -O2 -g -pipe
-fno-strict-aliasing -fno-common -fexceptions -m64 -g -O3 -pipe
-fno-strict-aliasing -fno-common -fexceptions -m64 -g -O3 -o
.libs/rletoabA62 rletoabA62-rle.o rletoabA62-rletoabA62.o
-L/usr/local/lib64 -L/usr/local/lib -lutahrle -lm -Wl,-rpath
-Wl,/usr/lib64/brlcad |
| 19:27.39 |
talcite_ |
/usr/bin/ld:
cannot find -lutahrle |
| 19:27.39 |
talcite_ |
collect2: ld
returned 1 exit status |
| 19:28.20 |
brlcad |
huh,
odd |
| 19:28.33 |
brlcad |
ls -la
../../../../../src/other/libutahrle/.libs/lib* |
| 19:29.17 |
talcite_ |
http://fpaste.org/61p6/ |
| 19:30.11 |
brlcad |
well that's
stumpworthy |
| 19:30.30 |
brlcad |
there's
libutahrle.so right there, and LD_LIBRARY_PATH points
there |
| 19:30.44 |
brlcad |
ah, but no -L
for it, hrm |
| 19:32.26 |
brlcad |
think we need
to remove one of the sed's |
| 19:32.46 |
brlcad |
the
hardcode_minus_L one |
| 19:35.27 |
starseeker |
brlcad: what
do I #include to get them in directly? |
| 19:36.21 |
brlcad |
starseeker:
they're not in a public header yet, you just have to declare
them |
| 19:36.28 |
starseeker |
ok |
| 19:36.36 |
brlcad |
see
table.c |
| 19:36.43 |
brlcad |
there is a
declaration macro there |
| 19:36.55 |
starseeker |
excellent,
thanks |
| 19:37.22 |
starseeker |
should the
rt_functab for tnurbs morph into the brep one? |
| 19:38.02 |
``Erik |
that'd wig
out import/export |
| 19:38.16 |
brlcad |
you don't
need to use the macro, but shows the basic form (or just declare
them simple) .. it's temporary either way |
| 19:38.25 |
starseeker |
nods |
| 19:39.19 |
starseeker |
is figuring the rt_functab stuff for brep should be handled
Sometime Soon Now... |
| 19:39.42 |
brlcad |
until it's
obsoleted, I wouldn't touch the functab entries -- the guts to
those functions need to change |
| 19:40.38 |
brlcad |
sure, you can
add them now if you like -- just have to be careful you don't blow
a loop somewhere |
| 19:41.04 |
brlcad |
i've been
working on hiding the functab |
| 19:41.12 |
starseeker |
oh,
OK |
| 19:41.17 |
starseeker |
that's
different |
| 19:41.22 |
brlcad |
right now
it's the only way in the api to get at primitives and their
callbacks |
| 19:41.31 |
starseeker |
nods |
| 19:41.53 |
brlcad |
without
calling the primitive-specific function directly, of
course |
| 19:42.23 |
brlcad |
i started
with mirror, and it just turned out to be a lot to chew on, still
at it |
| 19:42.47 |
starseeker |
am I right
that we're basically looking at needing most of the facetize type
logic for "nurbize" as well? |
| 19:43.27 |
brlcad |
idea will be
to have a corresponding rt_*() api call for each of the functab
entries -- the rt_*() calls into the functab |
| 19:43.53 |
brlcad |
que? |
| 19:43.53 |
brlcad |
not
necessarily |
| 19:43.53 |
starseeker |
given CSG
primitives, we can currently run facetize, big E, etc. to get
mesh |
| 19:44.04 |
starseeker |
don't we want
the same to "get" nurbs? |
| 19:44.42 |
*** join/#brlcad bobbens
(i=bobbens@saw4ever.de) |
| 19:45.34 |
brlcad |
ah, at the
command level .. yeah, probably |
| 19:45.47 |
brlcad |
probably an
option for some commands, default for others |
| 19:45.55 |
starseeker |
nods |
| 19:46.18 |
brlcad |
bigE/ev's
purpose is visualization, so they could just be updated to be
nurbs-only if ogl is available |
| 19:46.42 |
brlcad |
evaluated
visualization |
| 19:46.59 |
starseeker |
maybe - might
want to have a bot fallback if someone's ogl isn't up to NURBS
though |
| 19:47.09 |
brlcad |
nurbize is
kinda funky, don't see a direct need like there was for facetize
outside of debugging yet |
| 19:47.35 |
starseeker |
for that
matter, do we really need facetize? |
| 19:47.47 |
brlcad |
E/ev are
rarely used these days on real geometry because of the robustness
problems |
| 19:48.27 |
starseeker |
In the new
GUI I'm assuming it will be hidden behind view modes rather than
specific command line things like that? |
| 19:48.47 |
brlcad |
it
being? |
| 19:49.23 |
talcite_ |
brlcad: build
was successful, make install failed |
| 19:49.27 |
starseeker |
the
functionality of switching between wireframe, shaded,
etc |
| 19:49.44 |
brlcad |
yeah, those
are just viewing options in the gui |
| 19:50.14 |
talcite_ |
http://fpaste.org/ttBy/ |
| 19:50.22 |
brlcad |
lots of
potential viewing options that can be exposed through a panel or
buttons or keys or what-have-you |
| 19:52.42 |
starseeker |
brlcad:
what's the best way to create a bn_tol to toss into
rt_*_brep? |
| 19:53.00 |
brlcad |
cd
/home/matthew/rpmbuild/BUILD/brlcad-SVN_010809/src/libbn &&
/bin/sh ../../libtool --mode=install /usr/bin/install -c libbn.la
'/home/matthew/rpmbuild/BUILDROOT/brlcad-SVN_010809-0.fc11.x86_64/usr/lib64/brlcad' |
| 19:53.43 |
talcite_ |
brlcad:
http://fpaste.org/1RJZ/ |
| 19:54.05 |
brlcad |
starseeker:
er, create a tol struct and pass a ref to it? :) |
| 19:54.14 |
brlcad |
init it with
some values.. |
| 19:54.55 |
starseeker |
ok, so it
won't much care whether it's the same as the database being written
to? |
| 19:55.55 |
brlcad |
talcite_:
hrm, now we're fighting libtool .. |
| 19:56.19 |
brlcad |
starseeker:
databases don't have a tolerance |
| 19:56.52 |
starseeker |
oh,
OK |
| 19:56.55 |
brlcad |
they're
working tolerances |
| 19:57.18 |
brlcad |
you're
telling it what computation tolerances it needs to use .. which is
kinda odd for *brep() |
| 19:57.46 |
brlcad |
probably just
from being started as a copy of tess() or the old tnurb()
interface |
| 19:57.53 |
starseeker |
oh |
| 19:58.01 |
starseeker |
shall I clean
it up? |
| 19:58.05 |
brlcad |
not harmful,
though .. maybe important for some primitives where it will be some
sort of approximation |
| 19:58.49 |
brlcad |
could see tol
being important for dsp, ebm |
| 20:01.14 |
starseeker |
hmm, point.
ok |
| 20:04.25 |
talcite_ |
brlcad: I'm
going to switch locations. I'll be back in 20 minutes
ok? |
| 20:04.29 |
brlcad |
aha, talcite
.. one more sed |
| 20:04.33 |
talcite_ |
sure |
| 20:05.29 |
brlcad |
s/^hardcode_automatic=.*$/hardcode_automatic=yes/g |
| 20:05.52 |
brlcad |
that should
prevent that relink rule from kicking off |
| 20:07.45 |
brlcad |
i'll be
somewhat impressed if this actually works :) |
| 20:07.45 |
talcite_ |
alright,
rebuild started. I'm switching locations now |
| 20:07.54 |
brlcad |
kcya |
| 20:08.53 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 20:12.53 |
starseeker |
growls as he sees the brep.cpp files are all
extradisted.... |
| 20:14.25 |
starseeker |
brlcad: do I
link in just sph_brep.o or whatever to avoid depending on librt in
a procdb? |
| 20:14.53 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 20:17.38 |
starseeker |
grrrrowlll.
Oh, lovely - sph_brep.cpp doesn't build |
| 20:19.41 |
CIA-38 |
BRL-CAD:
03n_reed * r35556 10/brlcad/trunk/ (include/dm-rtgl.h
src/libdm/dm-rtgl.c): grouping jobs for decent job
shuffling |
| 20:27.04 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 20:29.59 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 20:37.06 |
talcite |
brlcad, argh.
It's still failing the check-rpaths test |
| 20:37.39 |
talcite |
brlcad, this
tool has been known to give false positives in some cases though.
Do you know of another method to check for rpaths? |
| 20:47.22 |
brlcad |
talcite: well
if you don't set rpaths and haven't added the path to /etc, the
binaries shouldn't work |
| 20:47.35 |
brlcad |
ldd
/usr/bin/rt |
| 20:51.20 |
talcite |
brlcad,
http://fpaste.org/Chsp/ |
| 20:56.30 |
brlcad |
that looks
like a lack of rpaths |
| 20:56.56 |
brlcad |
assuming that
is your installation prefix |
| 20:57.14 |
starseeker |
thanks ``Erik for noticing that rt_sph_brep is mangled and
decides linking can wait 'til Monday... |
| 20:57.16 |
brlcad |
if it's
chrooted, you'll have to try it again in the root |
| 20:57.58 |
talcite |
hmm it's just
an installation prefix |
| 20:58.06 |
talcite |
well maybe
seeing the check-rpaths output would help |
| 20:59.29 |
brlcad |
sure |
| 20:59.40 |
talcite |
http://fpaste.org/MoSZ/ |
| 21:03.24 |
CIA-38 |
BRL-CAD:
03brlcad * r35557
10/brlcad/trunk/src/librt/primitives/sph/sph_brep.cpp: unpooch
it |
| 21:04.58 |
brlcad |
talcite: ah,
so they do have an rpath, they have a preinstallation rpath so you
can run them without installing them |
| 21:05.22 |
brlcad |
which is
exactly why it tried to relink them earlier |
| 21:05.29 |
brlcad |
to get rid of
that path |
| 21:05.37 |
brlcad |
starseeker:
compiles now |
| 21:06.28 |
talcite |
brlcad, I
see. So what are our options? |
| 21:08.13 |
brlcad |
talcite: i'm
really liking the bail-out option :) |
| 21:08.25 |
CIA-38 |
BRL-CAD:
03brlcad * r35558 10/brlcad/trunk/ (3 files in 2 dirs): enable
sph_brep.cpp compilation |
| 21:08.28 |
talcite |
brlcad, bail
out? =S |
| 21:08.54 |
brlcad |
BuildRequires: chrpath |
| 21:09.36 |
talcite |
haha yeah, we
could do that. I'm not sure what it actually does though. If you
delete the files with rpaths in it, doesn't it break other
stuff? |
| 21:09.43 |
brlcad |
my feeling is
even if we get something hacking.. it's going to be fragile to
libtool updates |
| 21:10.14 |
brlcad |
talcite: that
tool simply strips out the rpath |
| 21:10.21 |
brlcad |
doesn't
delete files |
| 21:10.24 |
talcite |
oh I
see |
| 21:10.54 |
talcite |
sure, I
wouldn't mind doing that. the libtool stuff is really
finicky |
| 21:11.13 |
brlcad |
so you'd let
it build and install, then set up a massive chrpath --delete on all
400+ binaries |
| 21:11.42 |
talcite |
brlcad, and
after the rpaths are deleted, it would turn to ld to find the
libs? |
| 21:12.20 |
brlcad |
fwiw, the
claim that "the Linux dynamic linker is usually smarter than a
hardcoded path" is a boatload of crap :) |
| 21:12.36 |
brlcad |
they're both
flimsy |
| 21:12.56 |
talcite |
heh. Well I
think there was one specific reason that distros avoided rpaths. I
was reading about it on the debian mailing lists |
| 21:13.03 |
brlcad |
to insist on
one over the other is a bit silly, but hey their system their
rules |
| 21:13.18 |
talcite |
it was
massively breaking some upgrades I think |
| 21:13.34 |
brlcad |
that usually
indicates some other stupidity on someone's part |
| 21:13.51 |
brlcad |
debian and
fedora are similarly managed *ahem* |
| 21:13.55 |
talcite |
anyways,
debian also bans rpaths, so if the chrpaths method works, we can
probably push to package this into debian as well =D |
| 21:13.57 |
talcite |
heh |
| 21:15.27 |
brlcad |
ports, fink,
portage, and others all get along just fine not getting involved in
whether they're set or not |
| 21:16.42 |
brlcad |
I suspect it
just makes package management easier for the package management
*system* developers, pushing the work onto the porters to customize
most packages |
| 21:18.14 |
talcite |
oh...
=/ |
| 21:18.21 |
brlcad |
the debian
devs also insist of screwing with libtool directly to impose one of
their requirements, which actually outright breaks packages that
include public libraries with binaries |
| 21:18.49 |
brlcad |
that's the
BC_PATCH_LIBTOOL I mentioned earlier .. reverts damage they make to
the libtool script that causes failures |
| 21:21.52 |
talcite |
oh...yeah I
think fedora also has patches applied to libtool |
| 21:31.26 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35559 10/isst/trunk/src/gui.c: thread monkeying.
pass args to gtk_init() |
| 21:31.55 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35560 10/isst/trunk/src/ (isst.h load_g.c):
disable "fast" loading for now. |
| 21:38.39 |
talcite |
alright,
hopefully that build will work out. I need to head out for a bit. I
will be back later |
| 21:49.03 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35561 10/isst/trunk/src/gui.c: get shotline
working again. |
| 22:49.43 |
``Erik |
hm |
| 22:50.25 |
``Erik |
damn linux
weenies, screwing up build systems and thinking it's a good
thing |
| 22:50.28 |
``Erik |
:D |
| 22:59.25 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r35562 10/isst/trunk/src/ (local_worker.c
net_worker.c): updates for osX.5 |
| 23:04.19 |
brlcad |
talcite_:
thanks again for your efforts |
| 23:07.30 |
``Erik |
thinks he'll put in a loader dialog then try to cook a
winderz binary of isst O.o |
| 23:07.37 |
``Erik |
and chuck it
over the fence |
| 23:08.52 |
``Erik |
(btw,
facetize_all_regions or facetall.sh ... needs to be
unsucked.) |
| 00:01.24 |
CIA-38 |
BRL-CAD:
03starseeker * r35577 10/brlcad/trunk/src/proc-db/csgbrep.cpp: Er,
oops - how about providing some memory for the temporary
rt_db_internal. Can now generate both sphere and ellipsoid, modulo
problems with ellipsoid due to geometry errors. |
| 00:10.10 |
CIA-38 |
BRL-CAD:
03starseeker * r35578 10/brlcad/trunk/src/ (3 files in 3 dirs):
Enable torus brep output in csgbrep |
| 00:17.54 |
starseeker |
breaths a sigh of relief - now we can start getting down to
geometry |
| 00:26.37 |
starseeker |
opts to go home and start on geometry
tomorrow... |
| 02:38.07 |
*** join/#brlcad stevegt`
(n=stevegt@64.71.149.1) |
| 03:40.22 |
*** join/#brlcad stevegt`
(n=stevegt@cislunar.TerraLuna.Org) |
| 03:51.18 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 05:06.25 |
*** part/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 05:28.44 |
*** join/#brlcad talcite__
(n=matthew@76-10-134-159.dsl.teksavvy.com) |
| 05:39.23 |
*** join/#brlcad talcite_
(n=matthew@69-196-168-92.dsl.teksavvy.com) |
| 06:21.39 |
``Erik |
huh? |
| 06:48.47 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 06:56.10 |
*** join/#brlcad talcite__
(n=matthew@69-196-178-139.dsl.teksavvy.com) |
| 07:57.06 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 08:00.12 |
*** join/#brlcad poolio_
(n=poolio@bz.bzflag.bz) |
| 08:02.48 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 08:07.03 |
*** join/#brlcad talcite__
(n=matthew@69-196-178-139.dsl.teksavvy.com) [NETSPLIT
VICTIM] |
| 08:07.03 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 08:12.33 |
*** join/#brlcad d-lo_
(n=claymore@bz.bzflag.bz) |
| 08:12.34 |
*** join/#brlcad kanzure (i=bryan@146.6.84.36) [NETSPLIT
VICTIM] |
| 08:13.34 |
*** join/#brlcad CIA-31
(n=CIA@208.69.182.149) |
| 08:15.47 |
Ralith |
anyone got a
windows box set up for dev handy? |
| 08:15.52 |
Ralith |
I've got
experimental windows code |
| 08:16.32 |
Ralith |
if this
works, all that leaves is OSX support and the major windowing
systems are covered. |
| 08:16.42 |
CIA-31 |
BRL-CAD:
03ralith * r35579 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx
OgreGLWidget.h): Untested windows support for
OgreGLWidget. |
| 08:37.05 |
CIA-31 |
BRL-CAD:
03ralith * r35580 10/rt^3/trunk/src/g3d/ (GedCommand.cxx
GedCommand.h): Added a convenience function to convert a
QStringList into a char** for passing to libged. |
| 09:04.19 |
CIA-31 |
BRL-CAD:
03ralith * r35581 10/rt^3/trunk/src/g3d/ (GedCommand.cxx
GedCommand.h): Added convenience function for calling libged
functions, assuming they all share type signature. |
| 09:05.25 |
Ralith |
talk about
simplification. |
| 09:05.33 |
Ralith |
much DRYer,
too. |
| 09:11.03 |
CIA-31 |
BRL-CAD:
03ralith * r35582 10/rt^3/trunk/src/g3d/ (GedCommand.cxx
GedCommand.h): Added convenience function to obtain last libged
string command result. |
| 09:11.14 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 09:12.13 |
CIA-31 |
BRL-CAD:
03ralith * r35583 10/rt^3/trunk/src/g3d/ (GedCommand.cxx
GedCommand.h): Modified libged call convenience function to return
libged call return value. |
| 09:16.16 |
CIA-31 |
BRL-CAD:
03ralith * r35584 10/rt^3/trunk/src/g3d/GedCommands.h: Adapted
GedCommands.h to use new utility functions, drastically simplifying
the file and reducing repeated code. Usage messages are now
offloaded to libged. |
| 09:25.25 |
CIA-31 |
BRL-CAD:
03ralith * r35585 10/rt^3/trunk/src/g3d/ (GedCommand.cxx
GedCommand.h GedCommands.h): |
| 09:25.25 |
CIA-31 |
BRL-CAD:
Moved convenience functionality into GedCommand proper, replacing
the need for |
| 09:25.25 |
CIA-31 |
BRL-CAD:
duplicate execute reimplementations in each new GedCommand with a
simple |
| 09:25.25 |
CIA-31 |
BRL-CAD:
requirement for the GedFunc to be wrapped to be specified in the
constructor. |
| 09:27.10 |
CIA-31 |
BRL-CAD:
03ralith * r35586 10/rt^3/trunk/src/g3d/Command.cxx: Squashed
unsigned vs. signed comparison warning. |
| 09:28.38 |
CIA-31 |
BRL-CAD:
03ralith * r35587 10/rt^3/trunk/src/g3d/ (Command.h Commands.h
GedCommand.cxx GedCommand.h): Constified Command::execute's
argument. |
| 09:29.46 |
CIA-31 |
BRL-CAD:
03ralith * r35588 10/rt^3/trunk/src/g3d/ (Command.cxx Command.h):
Referenceified the return value of Command::getArgumentNames for
consistency. |
| 09:33.42 |
Ralith |
yay,
ged_reopen isn't bugging anymore |
| 09:33.52 |
Ralith |
and I've
finally managed to confirm interaction with a database file
:D |
| 09:50.28 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 09:54.04 |
CIA-31 |
BRL-CAD:
03ralith * r35589 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h
OgreGLWidget.cxx): First attempt to make Console output vertically
scrollable; simplifies code but results in invisible
output. |
| 09:58.06 |
CIA-31 |
BRL-CAD:
03ralith * r35590 10/rt^3/trunk/src/g3d/Console.cxx: Console output
restored and now scrollable. Some oddities remain. |
| 10:01.20 |
CIA-31 |
BRL-CAD:
03ralith * r35591 10/rt^3/trunk/src/g3d/Console.cxx: Set console
output text alignment to bottom-left. |
| 10:04.57 |
CIA-31 |
BRL-CAD:
03ralith * r35592 10/rt^3/trunk/src/g3d/Console.cxx: Restored
proper output line formatting to console. |
| 10:16.38 |
CIA-31 |
BRL-CAD:
03ralith * r35593 10/rt^3/trunk/src/g3d/Console.cxx: First attempt
to force scrollable console output to remain at the bottom; mostly
unsuccessful. |
| 10:36.48 |
CIA-31 |
BRL-CAD:
03ralith * r35594 10/rt^3/trunk/src/g3d/Console.cxx: Another
attempt to force scrolling to remain at maximum, now resulting in
correct scrolling alignment for the *last* command
output. |
| 10:38.41 |
d-lo_ |
Nice stuff
Ralith ;) |
| 10:38.48 |
Ralith |
thanks |
| 10:39.08 |
Ralith |
got a pair of
challenging (minorish) issues right now :/ |
| 10:39.39 |
d-lo_ |
which
are? |
| 10:39.41 |
Ralith |
in addition
to the above scrolling issues, for some reason the output scrollbar
is using the windows theme. |
| 10:39.49 |
Ralith |
which is
downright strange. |
| 10:40.49 |
d-lo_ |
Hrm, that is
strange. |
| 10:41.03 |
d-lo_ |
But, I agree,
Minorish :) |
| 10:41.37 |
Ralith |
the scrolling
thing seems to be expected behavior, but I'm still not sure how to
go at it: adding text to the output QLabel does not immediately
result in the QScrollArea adjusting itself, so the slider
adjustment just moves it to the position for whatever the last
known QLabel size was. |
| 10:42.04 |
Ralith |
most of the
obvious angles cannot be guaranteed to work reliably. |
| 10:42.20 |
Ralith |
because Qt's
slots are not guaranteed to be called in any particular
order |
| 10:44.54 |
Ralith |
none of the
'update right now dammit' functions seem to be
sufficient. |
| 10:47.43 |
d-lo_ |
Sorry, been
bringing up the .cxx/.h |
| 10:47.56 |
Ralith |
heh |
| 10:47.57 |
Ralith |
no
worries |
| 10:48.22 |
Ralith |
mostly
discussing it in the hopes of jostling an idea in my own head; it
probably requires more background than is worth the effort to
obtain from scratch. |
| 10:50.10 |
d-lo_ |
Are QLabel
objects designed to be multiline? |
| 10:51.00 |
Ralith |
yes, as far
as I can tell. |
| 10:51.08 |
Ralith |
that bit
certainly works fine. |
| 10:51.17 |
Ralith |
it resizes
itself to acommodate. |
| 10:51.22 |
Ralith |
or,
well |
| 10:51.32 |
Ralith |
widget size
management in Qt is fairly involved |
| 10:51.46 |
Ralith |
(for good
reason) |
| 10:52.08 |
Ralith |
but with the
current code, the widget be resized itself to however large it need
be on both axes to contain the text fed to it |
| 10:52.21 |
d-lo_ |
So, are you
just trying to get the slider to adjust to a specific position
based on an addition of text to the label? |
| 10:53.59 |
Ralith |
well |
| 10:54.13 |
Ralith |
right now,
I'm simply telling the slider to go to its maximum position
immediately after text is added. |
| 10:54.21 |
Ralith |
which is the
desired behavior. |
| 10:54.28 |
Ralith |
hm, I
wonder... |
| 10:54.45 |
Ralith |
no,
nvm. |
| 10:55.38 |
d-lo_ |
Well I guess
I don't understand the scrolling problem then, heh :) |
| 10:56.29 |
Ralith |
the problem
is that the QScrollArea doesn't seem to adjust itself for the
QLabel resize until it gets normally updated |
| 10:56.37 |
Ralith |
which occurs
*after* pushOutput returns |
| 10:57.35 |
Ralith |
which means
that any adjustment of the QScrollArea's scroll positioning is
applied to a QScrollArea having dimensions fitting the pre-append
output label. |
| 10:57.40 |
d-lo_ |
ah. i
c. |
| 10:58.53 |
Ralith |
at this point
I'm hoping there's some clever auto-alignment trick that will fix
everything. |
| 11:01.53 |
d-lo |
what about
extending the QLabel class to your own custom class, make a custom
'TextUpdated' signal that fires whenever you call ->setText()
? |
| 11:02.15 |
d-lo |
just wire
that textUpdated signal into the Scrollbar resize
logic. |
| 11:04.22 |
CIA-31 |
BRL-CAD:
03ralith * r35595 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h):
Const-ref-ified Console::pushOutput's argument. |
| 11:04.45 |
Ralith |
d-lo: such a
signal already exists. Lemme give that a try. |
| 11:05.56 |
d-lo |
really? I am
looking at the API::QLabel docs and see no signal thats usable
:/ |
| 11:06.13 |
Ralith |
oh, wait, I
was thinking of QLineEdit |
| 11:06.39 |
Ralith |
however... |
| 11:07.56 |
d-lo |
Hrm, thats
just dumb actually. having a TextUpdated signal seems only logical
for a QLabel... why isn't it in there? |
| 11:08.17 |
Ralith |
probably
because a QLabel's text can only be changed by the program
anyway |
| 11:08.24 |
Ralith |
also |
| 11:08.30 |
Ralith |
I *think* you
can connect a slot to another slot |
| 11:08.32 |
Ralith |
but I'm not
sure |
| 11:08.41 |
Ralith |
however,
quoth the docs: |
| 11:08.44 |
d-lo |
O.o |
| 11:08.51 |
Ralith |
When a signal
is emitted, the slots connected to it are usually executed
immediately |
| 11:09.12 |
Ralith |
meaning that
this would have the same ultimate effect as what I'm doing
already |
| 11:10.19 |
d-lo |
Hrm, again,
maybe I am missing the issue. I thought that the QLabel was
resizing properly, but the associated QScrollArea was
not? |
| 11:10.44 |
Ralith |
that is
correct. |
| 11:10.46 |
Ralith |
the problem
is timing |
| 11:10.51 |
Ralith |
or
well |
| 11:10.54 |
Ralith |
that is
approx. correct |
| 11:11.03 |
Ralith |
the
QScrollArea *is* resizing properly, but *after* pushOutput
returns. |
| 11:11.16 |
Ralith |
I believe
this is normal. |
| 11:11.28 |
d-lo |
So, if you
Subclass QLabel and override .setText() so that it calls
QLabel::setText() first, then emits the custom textUpdated()
signal, then returns. |
| 11:12.07 |
d-lo |
Okay, well, I
think I see what you are saying now. |
| 11:12.55 |
Ralith |
then that
would have the same effect as what I'm doing already |
| 11:13.18 |
d-lo |
have you
thought about making a dedicated GUI update thread/system? Seems
like this is a thread sequencing issue. |
| 11:14.29 |
Ralith |
ahah! |
| 11:14.30 |
Ralith |
solution! |
| 11:14.44 |
Ralith |
public slot
QAbstractSlider::rangeChanged |
| 11:15.35 |
d-lo |
Good deal..
but what's the signal? |
| 11:15.40 |
Ralith |
er |
| 11:15.42 |
Ralith |
that was a
signal |
| 11:15.48 |
d-lo |
kk |
| 11:15.49 |
Ralith |
it's 4AM
>_> |
| 11:15.56 |
d-lo |
NO
EXCUSES! |
| 11:16.00 |
d-lo |
;) |
| 11:17.05 |
Ralith |
wires it up |
| 11:18.03 |
d-lo |
I don't see
how that willhelp :/ Unless the rangeChanged fires before the
QSliderArea resizes itself... |
| 11:19.13 |
Ralith |
all I have to
do is connect outputArea->verticalScrollBar()'s rangeChanged to
a local slot that sets the scrollbar position to max |
| 11:20.47 |
d-lo |
Oh, all you
were trying to do was to get the scrollbar to go full the fully max
position? I thought 'resize' ment the QScrollBar was physically
changing size, lol |
| 11:21.10 |
Ralith |
nah, it's the
QScrollArea which resizes |
| 11:21.24 |
Ralith |
its virtual
area, anyway |
| 11:21.38 |
d-lo |
s/QScrollBar/QScrollArea/g |
| 11:22.03 |
Ralith |
yeah |
| 11:22.15 |
Ralith |
when it
resizes, the viewport position remains constant |
| 11:22.40 |
Ralith |
so the
additional QLabel content is off to the bottom and the scrollbar is
adjusted to match the larger range |
| 11:22.59 |
d-lo |
Well
QAbstractSlider has public setValue(int) slot that you could use...
or are ya? |
| 11:23.56 |
Ralith |
er |
| 11:23.57 |
Ralith |
it
does? |
| 11:23.58 |
Ralith |
where? |
| 11:24.13 |
Ralith |
oh
wait |
| 11:24.16 |
Ralith |
QAbstractSlider |
| 11:24.18 |
Ralith |
not
ScrollArea |
| 11:24.35 |
Ralith |
yeah, that's
basically equivalent to what I'm already doing |
| 11:24.49 |
Ralith |
it doesn't
map cleanly onto rangeChanged's data so I have to use a custom one
anyway |
| 11:25.02 |
d-lo |
right on.
just casually browsing the Qt Api. saw it, figured i'd mention it
:) |
| 11:25.58 |
Ralith |
nods |
| 11:26.16 |
Ralith |
now I just
have to work out exactly what syntax to use to make the connection
work :| |
| 11:26.29 |
Ralith |
it tends to
be picky and fail silently. |
| 11:28.31 |
Ralith |
got
it! |
| 11:28.34 |
Ralith |
:D |
| 11:28.36 |
Ralith |
works a
dream. |
| 11:28.42 |
d-lo |
applauds. |
| 11:31.17 |
CIA-31 |
BRL-CAD:
03ralith * r35596 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h):
Fully functional vertical console output scrolling. |
| 11:36.02 |
d-lo |
now how about
wrapping up that QLabel + QScrollArea functionality into a single,
new QWidget? ;) |
| 11:36.23 |
Ralith |
good
idea. |
| 11:37.01 |
Ralith |
I might wait
until I can fix/verify linewrapping |
| 11:38.36 |
Ralith |
or until
there is actually a need for such functionality elsewhere
>_> |
| 11:38.53 |
Ralith |
(this is how
HistoryLineEdit came about) |
| 11:39.08 |
d-lo |
kewl |
| 13:23.15 |
``Erik |
O.o |
| 13:49.04 |
starseeker |
is getting a funny behavior when he goes to MGED camera, then
does a Shift+left mouse click and hold to drag the
object |
| 13:49.14 |
starseeker |
it's spinning
around as I drag it |
| 13:50.19 |
starseeker |
Ralith: very
cool work! |
| 13:50.41 |
starseeker |
Is the
command dialog supposed to disappear when you click on the button
again and/or run a command? |
| 13:51.54 |
starseeker |
screenshot,
for those interested: http://bzflag.bz/~starseeker/g3d_latest.png |
| 14:01.14 |
``Erik |
that is most
definitely not an m35 deuce and a half on the screen. |
| 14:02.10 |
starseeker |
true |
| 14:02.24 |
starseeker |
that's just a
demonstration of the ability to run SOME command that queries the
database |
| 14:02.57 |
``Erik |
it's not the
24th yet :) |
| 14:03.52 |
``Erik |
libgcv is
probbably the best avenue to get triangles from .g files....
isst/src/load_g.c is one way to do it |
| 14:11.36 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 14:34.16 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 14:40.23 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D5ED.dip.t-dialin.net) |
| 14:42.47 |
*** join/#brlcad Patmcc19
(n=chatzill@174-17-193-105.phnx.qwest.net) |
| 14:43.41 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 15:21.23 |
starseeker |
can anybody
else play this video? http://bzflag.bz/~starseeker/g3d.avi |
| 15:21.59 |
starseeker |
lord that was
a job, but screenshots just don't do for this |
| 15:24.47 |
archivist |
plays on
ubuntu, some artifacts though |
| 15:26.14 |
starseeker |
what
sort? |
| 15:29.43 |
starseeker |
(for the
record, had to install https://devel.neopsis.com/projects/yukon/wiki/WikiStart,
record, run /tmp/yukon.seom through seom-filter to a file
(file.y4m), then mencoder file.y4m -ovc lavc -lavcopts
vcodec=mpeg4:vpvpass=1 -o g3d.avi |
| 15:29.58 |
starseeker |
(on gentoo
linux) |
| 15:30.21 |
starseeker |
er that's
vpass not vpvpass |
| 15:31.11 |
CIA-31 |
BRL-CAD:
03irpguardian * r35597
10/brlcad/trunk/src/archer/plugins/Wizards/humanwizard/HumanWizard.tcl:
Fixed humanwizard so it doesn't totally break archer. |
| 16:15.33 |
brlcad |
hehe, cool
starseeker |
| 16:15.40 |
brlcad |
plays fine in
MPlayer |
| 16:15.57 |
brlcad |
quicktime
doesn't have the codec |
| 16:23.09 |
CIA-31 |
BRL-CAD:
03irpguardian * r35598
10/brlcad/trunk/src/archer/plugins/Wizards/humanwizard.tcl: Changed
case so that way human wizard works more. |
| 16:26.35 |
CIA-31 |
BRL-CAD:
03brlcad * r35599 10/brlcad/trunk/src/other/ (tcl/Makefile.am
tk/Makefile.am): if we're going to install non-versioned
wish/tclsh, we need to uninstall them |
| 16:46.38 |
CIA-31 |
BRL-CAD:
03irpguardian * r35600
10/brlcad/trunk/src/archer/plugins/Wizards/humanwizard/HumanWizard.tcl: |
| 16:46.38 |
CIA-31 |
BRL-CAD:
Fixed lots of variable problems. Now actually loads dialog
box!! |
| 16:46.38 |
CIA-31 |
BRL-CAD:
Unfortunatly, does not create human... yet... |
| 18:07.23 |
*** join/#brlcad BigAToo
(n=BigAToo@208.95.141.189) |
| 18:17.30 |
CIA-31 |
BRL-CAD:
03bob1961 * r35601 10/brlcad/trunk/src/libged/draw.c: Update
ged_draw to process -A as in mged's edit_com. |
| 18:21.29 |
CIA-31 |
BRL-CAD:
03irpguardian * r35602 10/brlcad/trunk/src/libged/human.c: Added
human.c to libged to be used for archer plugin. |
| 18:27.50 |
CIA-31 |
BRL-CAD:
03brlcad * r35603 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
quell warnings. lots of missing return types and unimplemented
sections. |
| 18:34.17 |
CIA-31 |
BRL-CAD:
03irpguardian * r35604 10/brlcad/trunk/src/libged/Makefile.am:
Added human to makefile |
| 18:37.53 |
CIA-31 |
BRL-CAD:
03brlcad * r35605 10/brlcad/trunk/src/proc-db/brepintersect.cpp:
some minor style consistency cleanup and formatting, doxygenify and
repair. |
| 19:05.05 |
*** join/#brlcad talcite__
(n=matthew@69-196-178-139.dsl.teksavvy.com) |
| 19:22.16 |
CIA-31 |
BRL-CAD:
0385.175.214.221 07http://brlcad.org * r1601
10/wiki/Support: |
| 19:30.38 |
CIA-31 |
BRL-CAD:
03n_reed * r35606 10/brlcad/trunk/ (5 files in 4 dirs): using hash
table to bin colors for faster prep and drawing time |
| 19:59.28 |
CIA-31 |
BRL-CAD:
03bob1961 * r35607
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Use expand
instead of ls when clearing the target ledger (.i.e ls adds garnish
to regions/combinations). |
| 19:59.41 |
CIA-31 |
BRL-CAD:
03brlcad * r35608 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp:
more cleanup: inject some whitespace for readability, ws and style
cleanup. |
| 20:12.46 |
CIA-31 |
BRL-CAD:
03n_reed * r35609 10/brlcad/trunk/src/libdm/dm-rtgl.c: draw
function was skipping first table entry |
| 20:15.19 |
starseeker |
indianlarry:
Getting some raytrace artifacts with the boolean subtraction of a
torus from a sphere in nurbs: http://bzflag.bz/~starseeker/sph-tor.g |
| 20:19.32 |
CIA-31 |
BRL-CAD:
03irpguardian * r35610 10/brlcad/trunk/src/proc-db/ (Makefile.am
human.c): |
| 20:19.32 |
CIA-31 |
BRL-CAD:
Modified human.c to build humans using libged |
| 20:19.32 |
CIA-31 |
BRL-CAD:
Modified Makefile to allow this to happen |
| 20:21.27 |
CIA-31 |
BRL-CAD:
03brlcad * r35611 10/brlcad/trunk/src/proc-db/metaball.c: cast to
quell some constness warnings |
| 20:21.36 |
CIA-31 |
BRL-CAD:
03brlcad * r35612 10/brlcad/trunk/include/rtgeom.h: ws
reduction |
| 20:23.14 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D5ED.dip.t-dialin.net) |
| 20:23.22 |
brlcad |
howdy
talcite__ |
| 20:23.33 |
brlcad |
any news on
the rpm? |
| 20:25.40 |
CIA-31 |
BRL-CAD:
03brlcad * r35613 10/brlcad/trunk/src/mged/overlay.c: quell
constness warning |
| 20:26.26 |
CIA-31 |
BRL-CAD:
03irpguardian * r35614
10/brlcad/trunk/src/archer/plugins/Wizards/humanwizard/HumanWizard.tcl:
Modified Humanwizard to work better (but still broken) in
archer |
| 20:35.40 |
CIA-31 |
BRL-CAD:
03brlcad * r35615 10/brlcad/trunk/TODO: |
| 20:35.40 |
CIA-31 |
BRL-CAD:
since most of the build tree is warning clean now, plan to utilize
more strict |
| 20:35.40 |
CIA-31 |
BRL-CAD:
compilation options in those subdirs if the compiler supports it.
this should |
| 20:35.40 |
CIA-31 |
BRL-CAD: help
prevent new bad habits and lazinesses from getting
injected. |
| 20:46.01 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:06.39 |
CIA-31 |
BRL-CAD:
03irpguardian * r35616 10/brlcad/trunk/src/ (4 files in 2 dirs):
Moved human.c to shapes directory, and modified respective
makefiles to take this change. |
| 21:14.17 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 21:50.10 |
Ralith |
starseeker:
you got it working? :D |
| 21:50.52 |
Ralith |
good call on
the command dialog closing on execute, didn't think of that but
it's the obvious thing to do |
| 21:53.07 |
CIA-31 |
BRL-CAD:
03ralith * r35617 10/rt^3/trunk/src/g3d/ (CommandDialog.cxx
MainWindow.cxx): Cleaned up empty argument lists in calls to
QObject::connect and made the command dialog auto-hide when a
command is ran. |
| 21:56.07 |
brlcad |
Ralith: maybe
you can fix that translate bug |
| 21:56.16 |
Ralith |
tr-- oh
yeah |
| 21:56.16 |
brlcad |
then we can
remake the video |
| 21:56.28 |
brlcad |
and post it
up on the site |
| 21:56.33 |
Ralith |
the mged
camera mode shift-click-drag thing? |
| 21:56.54 |
brlcad |
yep |
| 21:56.58 |
Ralith |
yeah |
| 21:57.17 |
Ralith |
I may just
scrap mafm's camera management thing :/ |
| 21:57.25 |
Ralith |
oh,
btw |
| 21:57.35 |
Ralith |
what's
libged's relationship to the display supposed to be? |
| 21:57.41 |
Ralith |
I notice it
implements commands like 'zap' |
| 22:03.03 |
brlcad |
it's supposed
to provide display lists (or similar visualization representations)
that the application manages |
| 22:03.33 |
brlcad |
I wouldn't
think you should scrap his cameras .. probably some pretty minor
bug, uninitialized matrix or something |
| 22:04.30 |
Ralith |
it's the
second such minor bug with no obvious cause |
| 22:04.44 |
brlcad |
as for
libged, for example, if you "draw foo", it should load up 'foo'
from disk and obtain a visual representation (e.g. the wireframe or
polygons), and present that back to the caller |
| 22:05.12 |
brlcad |
right now it
effectively does that by loading up display lists for the
primitives and stashes them in the ged struct |
| 22:05.39 |
brlcad |
the calling
application can then iterate over those display lists and pump them
to ogre |
| 22:06.24 |
mafm |
meh, nothing
of my code is left :P |
| 22:06.57 |
brlcad |
mafm: hehe,
not true |
| 22:06.59 |
Ralith |
mafm: not at
all! |
| 22:07.06 |
Ralith |
your command
stuff is working quite nicely. |
| 22:07.21 |
Ralith |
logger,
too |
| 22:07.27 |
brlcad |
even aa bunch
of the main appliction framework is the same |
| 22:07.39 |
brlcad |
ya'll should
keep at it :) |
| 22:07.43 |
mafm |
but camera
code was so nice... :'( |
| 22:08.11 |
brlcad |
yeah, I don't
think the camera code should be removed, the bugs don't seem that
major |
| 22:08.19 |
brlcad |
and this one
was specific to translations |
| 22:08.22 |
brlcad |
mafm: did you
see the video? |
| 22:08.28 |
mafm |
nope |
| 22:08.53 |
brlcad |
http://bzflag.bz/~starseeker/g3d.avi |
| 22:09.10 |
Ralith |
will smack it a bit and see if he can't knock the issue
loose |
| 22:09.22 |
Ralith |
it's probably
using the same input for both translation *and* rotation or
something |
| 22:11.16 |
mafm |
nice video
:) |
| 22:11.36 |
mafm |
I was only
whining... no problem in removing any of my code, of
course |
| 22:13.13 |
Ralith |
hehe |
| 22:13.36 |
Ralith |
no need to do
so gratuitously, either |
| 22:29.58 |
Ralith |
mafm: can you
explain the purpose of the third parameter to void
CameraMode::pan(float x, float y, SimpleVector3
originalCenter) |
| 22:31.10 |
mafm |
I think that
there's some/several modes that zoom or move the object depending
on the distance of the mouse from the center of the screen, or the
originalCenter |
| 22:32.02 |
mafm |
so, when
mouse moves from x=500 to x=550, if the origcenter.x=300, it
calculates the base position subtracting x-origcenter.x |
| 22:32.08 |
mafm |
instead of
from last mouse position |
| 22:32.57 |
mafm |
base
position->current position |
| 22:33.33 |
Ralith |
but you
already handle the absolute->relative conversion |
| 22:33.43 |
Ralith |
ooh I know
the problem |
| 22:34.29 |
mafm |
mmm |
| 22:35.09 |
mafm |
I think that
I had introduced it later in the design due to some functionality
of MGED requiring it |
| 22:36.23 |
mafm |
but maybe it
can be avoided with a redesign, or at least simplified |
| 22:36.47 |
Ralith |
it
can |
| 22:46.27 |
Ralith |
okay, bug
squashed |
| 22:47.28 |
Ralith |
brlcad: where
can I find docs on the libged display list stuff? |
| 22:57.19 |
Ralith |
blarg |
| 22:57.21 |
Ralith |
smacks svn |
| 22:58.46 |
CIA-31 |
BRL-CAD:
03ralith * r35618 10/rt^3/trunk/src/g3d/ (CameraModeMGED.cxx
CameraModeMGED.h): Simplified and fixed MGED camera
panning. |
| 22:58.48 |
Ralith |
there we
go |
| 22:58.52 |
Ralith |
brlcad:
fixd! |
| 23:12.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
| 23:20.12 |
CIA-31 |
BRL-CAD:
03ralith * r35619 10/rt^3/trunk/src/g3d/ (4 files): Replaced
SimpleVector3 use with vmath.h vector types. |
| 23:35.44 |
``Erik |
hm |
| 23:48.39 |
CIA-31 |
BRL-CAD:
03johnranderson * r35620 10/brlcad/trunk/src/libged/bigE.c:
Corrected display list to show the name of what is
"E"'d |
| 23:48.56 |
Ralith |
anyone know
where I can find docs on libged's display lists? |
| 15:58.37 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 15:58.37 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code
code, type type, commit frequently while you work! update wiki/blog
on daily progress. |
| 16:11.45 |
CIA-28 |
BRL-CAD:
03starseeker * r35690 10/brlcad/trunk/src/
(librt/primitives/nmg/nmg_brep.cpp proc-db/csgbrep.cpp): Get an nmg
example into csgbrep for debugging purposes, even though nmg_brep
doesn't do anything yet. |
| 16:22.39 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 16:28.04 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:39.37 |
CIA-28 |
BRL-CAD:
03bob1961 * r35691
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Update
killWrapper to remove duplicates from the kill list and the
modified list. |
| 16:54.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 17:48.30 |
brlcad |
d-lo: you
aware that final eval deadline is today? |
| 17:48.44 |
d-lo |
yessir. Done
did it already :) |
| 17:48.49 |
brlcad |
awesome |
| 17:53.41 |
brlcad |
Ralith:
jdoliner: filled yours out too I hope? |
| 17:58.59 |
jdoliner |
i did
indeed |
| 18:02.07 |
``Erik |
and d'lo is
gone, saw him driving out as we got back from lunch (green
turtle) |
| 18:03.04 |
brlcad |
he
answered |
| 18:04.00 |
``Erik |
yeh, but he's
out now, 'sall I'm sayin' :) |
| 18:04.23 |
``Erik |
he was
probably surprised to see me driving a 4d car |
| 18:11.24 |
Yoshi47 |
what the bext
rendering technic i should use for my bearing, its
done! |
| 18:11.28 |
jdoliner |
it's a
uniquely depressing experience to discover a prototyped opennurbs
function isn't actually implemented |
| 18:16.07 |
brlcad |
Yoshi47:
great, congratulations! |
| 18:16.17 |
brlcad |
Yoshi47: you
might want to try running "rtwizard" |
| 18:16.26 |
brlcad |
it has
embedded help, various render styles |
| 18:16.27 |
Yoshi47 |
brlcad,
thanks, don't ask me how many hours so far! |
| 18:16.35 |
Yoshi47 |
brlcad, ok
i'll try that out |
| 18:16.40 |
brlcad |
otherwise, I
tend to like rt rendering with an rtedge overlay |
| 18:17.22 |
brlcad |
tweaking
shader properties, maybe adding textures and creating custom lights
give the best result |
| 18:17.48 |
Yoshi47 |
brlcad, i get
this ./rtwizard: line 26: exec: bwish: not found when trying exec
rtwizard |
| 18:18.19 |
starseeker |
brlcad: just
curious - is there any sort of "minimal" opengl scene graph setup
that's smaller and lighter weight than
Ogre/OpenSceneGraph? |
| 18:18.19 |
brlcad |
o.O |
| 18:18.30 |
brlcad |
Yoshi47: you
haven't installed brl-cad? |
| 18:18.46 |
brlcad |
nice example
rendering: http://brlcad.org/tmp/goliath2.png |
| 18:18.54 |
Yoshi47 |
yep, svn
install this morning, then autogen.sh -> ./configure -> make
-> make install |
| 18:19.07 |
brlcad |
then why's it
saying ./rtwizard |
| 18:19.10 |
starseeker |
is
/usr/brlcad/bin in your path? |
| 18:19.30 |
brlcad |
oh, hah, are
you actually cd'd into /usr/brlcad/bin? |
| 18:19.43 |
Yoshi47 |
brlcad, yeah
but i forgot to make symbolic links... |
| 18:19.45 |
Yoshi47 |
one
sec |
| 18:19.56 |
brlcad |
shouldn't
need to make any symbolic links :P |
| 18:20.01 |
Yoshi47 |
i installe
dinto /opt |
| 18:20.10 |
brlcad |
still
shouldn't need to make any symbolic links :P |
| 18:20.22 |
Yoshi47 |
umm well im
cd /opt/brlcad/bin/ |
| 18:20.30 |
Yoshi47 |
then tried
rtwizard. |
| 18:20.34 |
Yoshi47 |
bwish is
there |
| 18:20.35 |
brlcad |
yeah, that's
just a funny way to run things |
| 18:20.46 |
brlcad |
right, but
how's it supposed to know bwish is there |
| 18:20.57 |
brlcad |
it's not like
it knows it needs to run ./bwish because you ran ./rtwizard
:) |
| 18:21.10 |
Yoshi47 |
from my
path... |
| 18:21.14 |
brlcad |
it just runs
"bwish" |
| 18:21.28 |
Yoshi47 |
right |
| 18:21.39 |
brlcad |
what happens
if you just run "rtwizard" |
| 18:22.12 |
Yoshi47 |
same
thing |
| 18:23.02 |
brlcad |
if you run
"bwish", what happens? |
| 18:23.22 |
Yoshi47 |
bwish> |
| 18:23.37 |
Yoshi47 |
well i ran
./bwish |
| 18:23.41 |
brlcad |
heh |
| 18:23.42 |
brlcad |
dude |
| 18:23.58 |
brlcad |
"rtwizard" is
not "./rtwizard" |
| 18:24.18 |
brlcad |
nor is
"bwish" "./bwish" :) |
| 18:24.30 |
brlcad |
your path
isn't set |
| 18:24.42 |
Yoshi47 |
i guess i
don't folly understand the principle yet, kinda do but not all the
way |
| 18:24.52 |
brlcad |
you have to
set your path for binaries to be found |
| 18:24.56 |
Yoshi47 |
brlcad, thats
what i figured |
| 18:25.24 |
brlcad |
you're fine
when it's a stand-alone binary, but not when it's something that
relies on other resources |
| 18:25.37 |
brlcad |
that goes for
any application, not just brl-cad tools |
| 18:26.07 |
brlcad |
export
PATH=/opt/brlcad/bin:$PATH |
| 18:26.10 |
brlcad |
for bash at
least |
| 18:26.30 |
Yoshi47 |
got
it |
| 18:26.34 |
Yoshi47 |
thanks |
| 18:27.17 |
Yoshi47 |
how long
should it take to load |
| 18:30.31 |
brlcad |
depends on
how fast your system is, but there should be a progress
meter |
| 18:30.41 |
brlcad |
unless you
see it spit out an error |
| 18:31.42 |
Yoshi47 |
no it was a
seperate window 40% Megawidgets Packed |
| 18:31.47 |
Yoshi47 |
still can go
on though |
| 18:35.29 |
brlcad |
if it's not
moving, it's stalled on something |
| 18:37.15 |
brlcad |
~seen
Ralith |
| 18:37.18 |
ibot |
ralith is
currently on #brlcad, last said: ':P'. |
| 18:37.21 |
Yoshi47 |
no i just
close it and i can move on |
| 18:37.37 |
brlcad |
should have
prodded ralith over the weekend |
| 18:41.42 |
Yoshi47 |
what type of
file is outputted from the wizard? png or jpeg |
| 18:42.11 |
brlcad |
well
definitely not jpeg because we don't support any lossy
formats |
| 18:42.17 |
brlcad |
but either
pix or png |
| 18:42.18 |
Yoshi47 |
good |
| 18:42.32 |
Yoshi47 |
outputs a
corrupted file png |
| 18:42.35 |
Yoshi47 |
3MB
big |
| 18:42.48 |
starseeker |
hmm - this is
LGPL and looks like about 1M in size - wonder if it's any good?
http://plib.sourceforge.net/ssg/index.html |
| 18:42.49 |
brlcad |
are you sure
it's a png? |
| 18:42.58 |
brlcad |
i'm betting
it's a pix |
| 18:43.05 |
Yoshi47 |
how do you
specify i just ending the file name with png |
| 18:43.12 |
brlcad |
ah,
heh |
| 18:43.18 |
brlcad |
yeah, that
won't do it |
| 18:43.28 |
brlcad |
if it has no
options to say "png", then it's definitely a pix file |
| 18:43.40 |
brlcad |
pix are raw
first quadrant image files |
| 18:43.45 |
brlcad |
you can run
pix-png to convert it |
| 18:44.08 |
Yoshi47 |
ok i'll try
that |
| 18:44.08 |
brlcad |
(pix-png -n
1024 -w 768 < file.pix > file.png |
| 18:44.16 |
brlcad |
for a
1024x768 image of course |
| 18:44.32 |
brlcad |
it's a raw
image, so you have to tell it what the dimensions are |
| 18:45.31 |
starseeker |
hrm. maybe
not so small - needs some plib utility libraries |
| 18:45.32 |
starseeker |
nuts |
| 18:46.45 |
brlcad |
hm?
que? |
| 18:46.51 |
starseeker |
er,
sorry |
| 18:47.18 |
starseeker |
just looking
around to see if there is some kind of small scene graph library we
could use in archer without including all of
Ogre/OpenSceneGraph |
| 18:47.18 |
brlcad |
working in
*any* scene graph is going to be about the same amount of work,
regardless of how complex it is |
| 18:47.39 |
brlcad |
most of the
work is on the archer/mged/libdm side of things |
| 18:48.10 |
starseeker |
nods. Figured, but we probably can't justify pulling
everything needed for Ogre just to make archer's wireframe behave
better |
| 18:48.31 |
starseeker |
was hoping
there was something small that could be used just for Archer, prior
to the new GUI work |
| 18:49.17 |
brlcad |
sure we could
-- if it improves things, then it's progress -- an orge libdm
interface would be very useful |
| 18:49.56 |
starseeker |
but Ogre +
deps would be a great deal larger than even opennurbs or docbook -
wouldn't that be too much to pull in? |
| 18:50.18 |
starseeker |
at least,
without something new and spectacular in the UI
department? |
| 18:50.21 |
brlcad |
it is a lot
for a small gain, depends how well it worked |
| 18:50.47 |
brlcad |
if it was
perfectly seamless and fully integrated, I think it'd be worth it -
but that's a big 'if' |
| 18:50.53 |
starseeker |
nods |
| 18:51.26 |
starseeker |
I should
explore the libdm setup and the new rtgl work, might be a good
starting point |
| 18:51.55 |
brlcad |
could still
create an ogre libdm as a dev project, assume a system-installed
ogre with an interface that is all or nothing on/off |
| 18:52.05 |
brlcad |
yeah, was
going to say that |
| 18:52.19 |
brlcad |
the way rtgl
is now is far from ideal (and actually a bit of a
problem) |
| 18:52.52 |
brlcad |
libdm's api
was originally constructed around displaying polygonal line
segments |
| 18:53.06 |
starseeker |
winces |
| 18:53.23 |
starseeker |
and I'm
guessing we can't monkey with that API anytime soon? |
| 18:53.26 |
brlcad |
it needs to
be more scenegraphish where you either set up rendering callbacks
(probably ideal) or expand the api to more general
entities |
| 18:53.33 |
brlcad |
sure we
can |
| 18:53.53 |
starseeker |
wouldn't we
be breaking external code? Or does nobody use the dm
directly? |
| 18:54.04 |
brlcad |
libdm is fair
game to change, so long as the archer and tcl megawidgets continue
to "work" |
| 18:54.14 |
starseeker |
ah
:-) |
| 18:54.18 |
brlcad |
the tcl
megawidgets are used externally |
| 18:54.59 |
starseeker |
hates to expose his ignorance but had better - "rendering
callbacks" refers to ? |
| 18:55.12 |
brlcad |
the
src/tclscripts/lib entities in particular |
| 18:56.02 |
brlcad |
okay,
rendering callbacks are just like logging callbacks (if that
helps) |
| 18:56.11 |
Yoshi47 |
why is there
little tiny dots here and there on my images? |
| 18:56.23 |
brlcad |
but consider
if you had something you wanted to draw, like a bunch of line
segments that need to get sent to opengl |
| 18:56.35 |
brlcad |
Yoshi47:
screenshot? |
| 18:56.45 |
Yoshi47 |
one
sec. |
| 18:57.20 |
brlcad |
a direct
approach would be to have a place where your application code
compiles a list of line segments, and then sends those to libdm
saying "draw this" .. an immediate mode of sorts |
| 18:58.18 |
brlcad |
a callback
approach would be more like telling libdm, "call this function when
it's time to draw" and then that function dispatches the things to
be drawn in that callback function using a context libdm
provides |
| 18:58.48 |
Yoshi47 |
brlcad,
http://ej.nijenhuis.pixi.me/v/CAD/ |
| 18:59.31 |
brlcad |
doesn't
matter much for somethign simple like rendering line segments, but
can be a big deal if you want to support arbitrary rendering
methods (like ray-tracing or scene graphs) instead of just some
subset of geometric entities |
| 19:01.50 |
starseeker |
brlcad: OK.
Is there a pre-existing API you would like libdm to
emulate? |
| 19:06.09 |
brlcad |
I'd just
solve the problem as you go along -- it's pretty easy to tell
where/when things go wrong because you end up with #ifdef code
outside of libdm |
| 19:06.10 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460322.dsl.bell.ca) |
| 19:06.35 |
starseeker |
nods |
| 19:07.19 |
starseeker |
when the
rubber hits the road, what did you want to do about Ogre's build
system? do we assume cmake is available and trigger it with
autoconf? |
| 19:07.34 |
Yoshi47 |
is it how i
rendered it, it also happens when rendering inside
wged. |
| 19:07.51 |
starseeker |
(e.g. with
Ogre living in src/other/ogre ...) |
| 19:11.55 |
brlcad |
for the main
brlcad line, I'd assume ogre was system installed like X and leave
it at that for now -- you get another dm if you don't have
it |
| 19:12.07 |
brlcad |
we just make
sure we have it when it comes time to release |
| 19:12.24 |
starseeker |
OK |
| 19:13.53 |
Yoshi47 |
well since im
done with bearing for now, back to my imported dxf shape, how
should i extrude it? |
| 19:18.54 |
talcite |
ahaha the
review request has been posted! https://bugzilla.redhat.com/show_bug.cgi?id=518949 |
| 19:19.21 |
brlcad |
Ralith: wake
up dude :) |
| 19:26.48 |
``Erik |
Yoshi47: it'd
be neat to see render_balls done with perspective mode and some
scene around the object :) |
| 19:28.12 |
Yoshi47 |
``Erik, i
have to make the scene first, which leads back to my question 4
lines up... by the way how is my drawing? bad or not too bad for 3
days at it? |
| 19:28.43 |
``Erik |
drawing? |
| 19:29.58 |
Yoshi47 |
``Erik, what
would you like? sorry |
| 19:30.18 |
``Erik |
the model
looks cool, I tend to just make a 'half' with a checkerboard shader
and make the background color 'blue', so it comes out like
http://brlcad.org/gallery/s/renderings/primitives/niceballs.png.html |
| 19:30.26 |
``Erik |
but just cuz
it's really easy and quick *shrug* |
| 19:31.36 |
``Erik |
could always
concat it into like the bldg391.g or cornell.g just to get some
real surroundings :) |
| 19:31.43 |
Yoshi47 |
``Erik, what
degree perspective on it? |
| 19:32.08 |
``Erik |
play with it?
between 0 and 90, probably someting like 60ish would be
good? |
| 19:32.32 |
``Erik |
(er, 0 and
180) |
| 19:32.32 |
Yoshi47 |
``Erik, so
you have no answer my extruding? |
| 19:32.38 |
``Erik |
no, I don't
:( |
| 19:33.02 |
``Erik |
maybe brlcad
knows, but he's off napping or playing with his hello kitty dolls
again or something |
| 19:33.04 |
Yoshi47 |
``Erik, umm,
i would figure more people would be extruding stuff on a regular
basis. |
| 19:33.35 |
``Erik |
<-- tends
to stick to lower level stuff, doesn't know squat about modelling
:) |
| 19:34.03 |
Yoshi47 |
``Erik, well
someones got to do the lower stuff, i know i can't |
| 19:35.04 |
brlcad |
Yoshi47:
those dots are floating point tolerance bugs where two faces are
overlapping -- the boolean logic is ill-defined, a very old
issue |
| 19:35.15 |
``Erik |
has been thinking about replacing libbu's red/black tree with
a generalized tree interface (callbacks in a struct)
O.o |
| 19:35.32 |
Yoshi47 |
brlcad, umm
ok, i guess nothing we can do |
| 19:36.00 |
Yoshi47 |
brlcad, you
also don't have a answer about extruding? |
| 19:36.04 |
brlcad |
Yoshi47: you
can eliminate the artifacts by restructuring the booleans, but it's
usually easiest to just render larger and scale down |
| 19:36.21 |
brlcad |
the points
are hairline floating point so they won't scale up with the
image |
| 19:36.22 |
``Erik |
or
hypersample |
| 19:36.26 |
Yoshi47 |
brlcad, i'll
keep in mind for the next render |
| 19:36.55 |
brlcad |
yeah,
hypersampling should minimize it too -H4 or larger |
| 19:37.14 |
brlcad |
hasn't even read the question about extruding yet .. lots of
threads goin :) |
| 19:38.15 |
``Erik |
importing a
dxf 'shape' is an iffy thing, we only handle triangle meshes from
autocad, not anything like a 2d layout |
| 19:38.20 |
``Erik |
I
think |
| 19:38.27 |
brlcad |
as for 3 days
at it .. newbie time scale .. that shouldn't have taken more than
an hour or less |
| 19:38.46 |
brlcad |
i bet if you
did it again, it'd only take a day now |
| 19:38.57 |
brlcad |
and then do
it again, probably half a day |
| 19:39.07 |
brlcad |
fast
falloff |
| 19:39.19 |
brlcad |
talcite:
awesome! |
| 19:44.08 |
Yoshi47 |
brlcad, i bet
i could do it under and hour now... |
| 19:45.27 |
Yoshi47 |
``Erik, so
what your saying im better off redrawing, shouldn't be too hard but
a couple hours since i got like 4 extrusions to do... |
| 19:49.54 |
CIA-28 |
BRL-CAD:
03brlcad * r35692 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
note that the rotation values for clone's -b option are in degrees,
as suggested by Yoshi47 on IRC. |
| 19:51.09 |
brlcad |
talcite: the
floating point compliance problem is real, but I haven't yet seen
it be an actual problem anywhere yet -- several platforms report
that |
| 19:51.28 |
brlcad |
cross-compiling might have caused it
even |
| 19:51.36 |
talcite |
oh ok. It
just might be because I'm cross compiling in this case |
| 19:51.42 |
Yoshi47 |
brlcad, what
does the CIA-28 mean? that the help will be updated or has
been? |
| 19:51.44 |
talcite |
yeah. It
didn't show up in native compiles |
| 19:52.21 |
brlcad |
starseeker:
arbn is implicitly defined as the boundary enclosed by the surfaces
resulting from those intersecting planes .. so yeah, implicit
;) |
| 19:53.17 |
brlcad |
Yoshi47: that
it has been |
| 19:53.22 |
brlcad |
that's a live
source change notification |
| 19:59.51 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 20:03.03 |
Yoshi47 |
brlcad, cool,
i love Open Source |
| 20:04.05 |
brlcad |
open source
rocks ;) |
| 20:04.18 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 20:04.31 |
brlcad |
even better,
you keep finding reporting little things like that, could even set
it up so more changes could be made |
| 20:04.34 |
brlcad |
even by you!
;) |
| 20:04.37 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 20:05.15 |
Yoshi47 |
brlcad,
cool |
| 20:07.18 |
Yoshi47 |
brlcad, im
still having a hard time crasping the concept behind this, if i
desing my extrusion a foot long how easy is it later on to extrude
that to what ever lenght i would like? would OED work on it for
changing the length and then that would push down to the primitive
shapes? |
| 20:10.29 |
brlcad |
it should,
but not sure I've heard of anyone try |
| 20:11.09 |
brlcad |
would be
pretty simple to do an adjust or primitive edit to change the
length given it's a simple vector |
| 20:15.04 |
brlcad |
adjust
extrude1.s H {0 0 100} |
| 20:15.34 |
brlcad |
"get
extrude1.s" will show all of his parameters |
| 20:15.56 |
brlcad |
note that's a
low-level operation -- if you mess up, you're screwed |
| 20:16.27 |
brlcad |
it WILL let
you make invalid geometry and then never let you mess with that
object again (because it's invalid) .. so be careful, make a
backup, etc |
| 20:17.23 |
Yoshi47 |
so if my
extrusion is a region this should be possible too... |
| 20:17.32 |
Yoshi47 |
or even a
group? |
| 20:17.47 |
brlcad |
your
extrusion is not a region |
| 20:17.56 |
brlcad |
your region
may contain/reference an extrusion |
| 20:18.43 |
brlcad |
that
get/adjust example works on primitives |
| 20:19.06 |
brlcad |
the get on a
combination/region/group is going to simply show you the objects
they reference and any transformation matrices |
| 20:19.26 |
Yoshi47 |
ok but in
order for me to get me extrusion shape i need to make multiple
shapes and then put them in a region with -+u and then i have a
region, can i change to whole region and all its children at once
or just individual members |
| 20:20.08 |
Yoshi47 |
i think i'll
just make my extrusion a foot long and then try it when im done,
should be a good learning experience. |
| 20:20.54 |
brlcad |
using
get/adjust, that's specific to primitives and per-object -- I'd
suggest just trying an example of scaling down an extrusion in the
same direction as it's H vector and it *should* modify the H after
a push |
| 20:21.05 |
brlcad |
or leave it
unpushed, shouldn't matter |
| 20:21.36 |
Yoshi47 |
brlcad,
ok |
| 20:21.38 |
Yoshi47 |
thanks |
| 20:30.02 |
Yoshi47 |
cya for now,
be on later |
| 20:47.37 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 20:56.16 |
``Erik |
is running around making people look at yoshi's renderings
O:-) |
| 20:58.09 |
*** join/#brlcad matthewmpp
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
| 21:01.28 |
starseeker |
thinks a procdb that can generate bearings to spec is in
order :-) |
| 21:05.27 |
Yoshi47 |
starseeker,
me aggree |
| 21:06.20 |
Yoshi47 |
``Erik, how
are you running around making people look at my
renderings? |
| 21:08.33 |
Yoshi47 |
im going to
swear |
| 21:08.53 |
``Erik |
running
around saying "hey, ya got a web browser handy? check this
out" |
| 21:09.06 |
Yoshi47 |
oh at your
work, |
| 21:22.49 |
Yoshi47 |
does brl-cad
make backups of anykind? |
| 21:23.07 |
brlcad |
mged does
not |
| 21:23.10 |
brlcad |
archer
does |
| 21:23.14 |
Yoshi47 |
brlcad,
crap |
| 21:23.21 |
Yoshi47 |
you'll never
what i did |
| 21:23.23 |
brlcad |
otherwise,
very unforgiving of mistakes |
| 21:23.36 |
brlcad |
hence my
comment about being very careful earlier and making backups
:) |
| 21:23.38 |
Yoshi47 |
not brlcad
fault, my own stupidity |
| 21:24.03 |
Yoshi47 |
improper use
of rsync |
| 21:24.13 |
brlcad |
eek |
| 21:24.19 |
Yoshi47 |
yep |
| 21:24.23 |
Yoshi47 |
thats what i
did |
| 21:24.35 |
brlcad |
yeah, even
archer wouldn't have helped in that case :) |
| 21:24.45 |
Yoshi47 |
good thing i
can recreate it in under an hours, if only i had the bearing with
me, i left it at work |
| 21:25.00 |
Yoshi47 |
oh well,,
atleast i got renderings for now. |
| 21:26.29 |
Yoshi47 |
remember most
of the measurements but not all... |
| 21:47.37 |
brlcad |
so you lost
the whole thing?? |
| 21:47.43 |
Yoshi47 |
brlcad,
yep |
| 21:47.48 |
Yoshi47 |
i
sad |
| 21:47.49 |
brlcad |
way to put
that rework measurement to test :) |
| 21:47.59 |
brlcad |
you'd make a
great case study about the learning curve |
| 21:48.02 |
Yoshi47 |
brlcad, yep,
knock on wood |
| 21:48.28 |
Yoshi47 |
well i plan
on doing it tomorrow, |
| 21:48.28 |
brlcad |
if you do
recreate, please do share how long it takes... :) |
| 21:48.31 |
Yoshi47 |
so i'll time
myself |
| 21:48.34 |
brlcad |
cool |
| 21:48.57 |
brlcad |
what's your
fs? |
| 21:49.16 |
Yoshi47 |
i can't see
it taking that long, most of my time was playing around with
commands, especially that clone one... |
| 21:49.38 |
brlcad |
clone gave
you trouble? |
| 21:49.41 |
Yoshi47 |
one sec got
to ssh in i forget, |
| 21:49.44 |
brlcad |
(other than
the rads/degs) |
| 21:49.55 |
Yoshi47 |
brlcad, a
little had to figure that degrees thing out... |
| 21:50.02 |
Yoshi47 |
brl maybe
10mins on that |
| 21:50.38 |
Yoshi47 |
etx3 |
| 21:50.47 |
Yoshi47 |
i know there
is an undelete for that right? |
| 21:50.59 |
Yoshi47 |
but have no
clue how to work it or start using it |
| 21:51.03 |
Yoshi47 |
ext3* |
| 21:51.21 |
brlcad |
it's not
exactly an undelete, but there is a way you can try to
recover |
| 21:51.56 |
Yoshi47 |
well im
willing... |
| 21:56.53 |
CIA-28 |
BRL-CAD:
03starseeker * r35693
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Start
sketching out a way to get enough info for BREP surfaces out of NMG
faces. |
| 21:58.32 |
mafm |
Yoshi47:
http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html |
| 21:58.34 |
mafm |
good
luck |
| 21:58.37 |
mafm |
:) |
| 21:58.48 |
Yoshi47 |
mafm, ya im
reading it already |
| 21:58.49 |
brlcad |
yeah, it's
quite involved |
| 21:59.00 |
Yoshi47 |
brlcad, i
think it will be faster to redraw |
| 21:59.27 |
mafm |
thinks undeleted and on-line defrag would be ext4's flagship
features |
| 21:59.35 |
mafm |
yet none of
those are available yet :/ |
| 22:00.16 |
brlcad |
you could
probably find the .g file in a raw search of the drive -- our start
of file marker is pretty specific |
| 22:01.28 |
Yoshi47 |
brlcad, how
would one go about a raw search? |
| 22:02.31 |
brlcad |
something
like: grep -a -5 "Untitled BRL-CAD Database" /dev/hdawhatever >
output.bin |
| 22:02.46 |
brlcad |
might have to
unmount the drive |
| 22:02.52 |
mafm |
I think that
there are specific tools for that |
| 22:03.12 |
mafm |
searching for
files still present, matching a pattern |
| 22:03.50 |
brlcad |
the trick is
to find your title or some other easily findable content, then dump
enough context around that marker, then manually strip out the rest
with a hex edit |
| 22:04.42 |
brlcad |
that ext3grep
tool is basically doing something similar, but walking the inode
structure -- a raw grep or dd is much lower-level |
| 22:04.59 |
CIA-28 |
BRL-CAD:
03irpguardian * r35694 10/brlcad/trunk/src/libged/human.c: Fixed a
problem where name holder variables were not being properly
initialized. |
| 22:05.16 |
brlcad |
which should
help finding a match whether it was in the journal or on the fs or
memory cache or whatever |
| 22:07.17 |
brlcad |
should have
had you post your .g somewhere to check it out :) |
| 22:07.37 |
Yoshi47 |
brlcad,
yep |
| 22:08.06 |
brlcad |
and you're
sure you didn't just sync it to a remote host.. hehe |
| 22:08.30 |
Yoshi47 |
nope i was
going to sync from work to home but did the other way and with out
update on |
| 22:22.16 |
Yoshi47 |
well shes
searching... |
| 22:23.57 |
brlcad |
-5 probably
isn't going to be enough, but the trick first is to just *find* the
string, then expand the context until it matches the whole
file |
| 22:24.04 |
brlcad |
then hex
edit |
| 22:25.55 |
Yoshi47 |
i got freebsd
burning to a dvd for my notebook right now |
| 22:25.58 |
Yoshi47 |
going to give
it a shot |
| 22:26.12 |
Yoshi47 |
brlcad,
install better be easy! lol |
| 22:27.42 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 22:28.22 |
Yoshi47 |
i kinda don't
want to find it too, i want to give that redraw thing a timing
test. lol |
| 22:34.42 |
Yoshi47 |
brlcad, how
big do you think my db would of been? .5mb 1mb 10mb? |
| 22:35.10 |
brlcad |
less than 1mb
for sure |
| 22:35.31 |
brlcad |
probably not
more than 2-4kb actually, but hard to say what junk you had in
there ;) |
| 22:35.40 |
Yoshi47 |
i got a whole
bunch of txt files back |
| 22:35.47 |
Yoshi47 |
from
ralf |
| 22:35.59 |
brlcad |
did you set a
title? |
| 22:36.15 |
Yoshi47 |
yep |
| 22:36.17 |
Yoshi47 |
608Z |
| 22:36.19 |
brlcad |
you'll want
to search a unique identifier |
| 22:36.55 |
brlcad |
yeah, that's
not distinctive enough |
| 22:40.24 |
brlcad |
but... |
| 22:40.30 |
brlcad |
probably
could find it with.. |
| 22:40.34 |
brlcad |
what was your
grep? |
| 22:40.53 |
brlcad |
'title[^[:print:]]608Z' should be pretty
darn specific |
| 22:41.14 |
Yoshi47 |
i used
http://projects.izzysoft.de/trac/ext3undel/ |
| 22:41.30 |
Yoshi47 |
but it return
a dir i delete a while ago, i thinks it gone... |
| 22:41.44 |
Yoshi47 |
oh well, well
just have to test our time theory out i don't mind too
much |
| 22:41.55 |
Yoshi47 |
second time
is always a charm |
| 22:42.13 |
brlcad |
try the
/dev/hda grep in the background, just let it run overnight or
something :) |
| 22:42.49 |
brlcad |
grep -a
-10000 'title[^[:print:]]608Z' /dev/hda1 >
output.bin |
| 22:43.25 |
brlcad |
or whatever
you have that fs mounted as, ideally direct output to something not
on /dev/hda1 :) |
| 22:43.35 |
brlcad |
-10000 should
be plenty to capture the file |
| 22:44.31 |
Yoshi47 |
wouldn't that
also capture the current one or both? |
| 22:44.39 |
Yoshi47 |
i guess both
its grepping, duh |
| 22:45.03 |
brlcad |
yeah |
| 22:45.43 |
Yoshi47 |
here we go
with fbsd |
| 22:45.54 |
brlcad |
you can test
it with grep -a 'title[^[:print:]]608Z' yourfile.g |
less |
| 22:45.58 |
brlcad |
should see
the file ;) |
| 22:48.16 |
Yoshi47 |
88G to search
through |
| 22:49.23 |
brlcad |
yeah, that'll
take a while :) |
| 22:49.53 |
Yoshi47 |
fbsd install
kinda hard |
| 22:50.06 |
brlcad |
? |
| 22:50.20 |
Yoshi47 |
oh, got to
create a freebsd slice |
| 22:50.21 |
brlcad |
I didn't
suggest you install fbsd did I? :) |
| 22:50.45 |
Yoshi47 |
brlcad, yes,
im going to give it a try on my notebook since it needs a reload
anyways, got a newer one |
| 22:50.47 |
brlcad |
I mean, love
the OS, but one learning curve per week is pretty respectable
;) |
| 22:51.01 |
Yoshi47 |
brlcad, na i
take on lots |
| 22:51.02 |
brlcad |
ah,
fun |
| 22:51.51 |
brlcad |
fbsd desktop
is not my first choice, but the dev environment, stability, and
server features are top-notch |
| 22:52.31 |
brlcad |
course, last
time I had it on desktop was many years ago, so not fair to speak
to what their status is today |
| 22:53.03 |
Yoshi47 |
brlcad, what
you use for desktop? |
| 22:53.50 |
brlcad |
mostly macosx
these days, live in terminal windows and emacs most of the time
;) |
| 22:53.58 |
Yoshi47 |
ah |
| 22:54.43 |
brlcad |
gentoo and
ubuntu have had a fairly strong presense in the past |
| 22:55.08 |
brlcad |
I have a real
strong sweet spot in my heart for haiku as beos used to be a
primary for several years for me too |
| 22:55.57 |
brlcad |
i give that a
try a couple times a year it seems, report all the bugs I find and
return back to something that just works |
| 22:57.15 |
Yoshi47 |
well the
install sucks |
| 22:57.38 |
Yoshi47 |
maybe try
arch |
| 23:10.18 |
``Erik |
bah, things
that just work are no fun :D |
| 23:11.41 |
Yoshi47 |
``Erik,
nice |
| 23:11.52 |
Yoshi47 |
don't worry i
will most likely get fed up with it and return once again to
gentoo |
| 23:12.14 |
``Erik |
<-- is a
bit of the masochistic "everything at once" mentality... currently
doing common lisp, emacs, and web development all at
once |
| 23:12.25 |
``Erik |
being a
vim/c/systems guy 'n all |
| 23:17.40 |
Yoshi47 |
so whats for
supper |
| 23:19.24 |
brlcad |
oof, yeah..
haven't eaten today, damn |
| 23:19.37 |
brlcad |
hate it when
I forget that |
| 23:23.37 |
Ralith |
brlcad: oh,
thanks for the prod |
| 23:23.56 |
Ralith |
``Erik: yay
emacs! :D |
| 23:24.10 |
Ralith |
(yay CL too,
for that matter) |
| 23:25.28 |
Ralith |
opens email, gets intimidated by volume of spam, and just
goes to the site directly |
| 23:25.35 |
Yoshi47 |
umm whole
wheat bread and peanute butter and chocolate sprinkles |
| 23:27.50 |
brlcad |
Ralith: they
debated for a little while whether to fail the five students that
didn't fill out their own evals... :) |
| 23:27.57 |
Ralith |
wups. |
| 23:27.58 |
brlcad |
I was a
proponent of the "not fail" option |
| 23:28.00 |
brlcad |
:) |
| 23:28.03 |
Ralith |
thank you for
that. |
| 23:28.23 |
Yoshi47 |
lol |
| 23:28.23 |
Ralith |
probably should have jumped to it the moment he saw the email
subject line a couple days ago |
| 23:28.24 |
brlcad |
told them you
were up until 5am coding :) |
| 23:28.39 |
brlcad |
and coding
all weekend, so it sounded great ;) |
| 23:28.43 |
Ralith |
^^ |
| 23:28.57 |
brlcad |
I should have
nagged more too |
| 23:29.08 |
brlcad |
I didn't
exactly send out my own reminder mails to everyone |
| 23:29.09 |
Yoshi47 |
at least
someone happy ihave to go through time trials now! |
| 23:29.11 |
brlcad |
busy
summer |
| 23:29.22 |
brlcad |
Yoshi47:
hehe, cool |
| 23:29.33 |
brlcad |
but then that
definitely will be a good note to send out ;) |
| 23:30.03 |
brlcad |
I'm really
curious how long you'd take on redo now that "most" of the tool
learning is out of the way, and there's some basic memorization in
place |
| 23:30.58 |
brlcad |
for govt
folks, they generally go through a week or two of hands-on modeling
training and you can see (and measure) the rate increase pretty
directly |
| 23:31.10 |
Yoshi47 |
im guessing
under 2 hours,im going to setup a stop watch because i will get
annoyig user(like me) asking questions... |
| 23:31.41 |
brlcad |
it's
interesting to see that everyone is different, but most settle at
some base "rate" of comprehension and retention .. there's
definitely diminishing returns |
| 23:31.51 |
Ralith |
Yoshi47:
don't do yourself a disservice; you haven't been annoying, on an
absolute scale and certainly not compared to many of the people you
can find on IRC. |
| 23:32.13 |
brlcad |
haven't been
at all annoying, live for this stuff ;) |
| 23:32.16 |
Ralith |
if anything,
it's nice to have newbies around learning the ropes; gives the
place a feeling of activity. |
| 23:32.21 |
Ralith |
vivacity* |
| 23:32.31 |
Yoshi47 |
Ralith,
thanks, hey q for you, will you be working on gui over the school
year or not |
| 23:32.38 |
Ralith |
I certainly
hope to |
| 23:32.49 |
Yoshi47 |
cool |
| 23:32.52 |
brlcad |
that would be
awesome :) |
| 23:32.59 |
Ralith |
I've invested
enough effort in this project that it would be depressing to just
drop it. |
| 23:33.12 |
Ralith |
and I did,
after all, start in on it because it was something I wanted to
happen. |
| 23:33.13 |
brlcad |
and it's
actually starting to approach usable |
| 23:33.23 |
Ralith |
^^ |
| 23:33.34 |
brlcad |
it's
converging towards lots of the same things archer needs under the
hood libged-wise |
| 23:33.45 |
Yoshi47 |
good, well if
you need any help on gui design i have a little bit of experience
with that, i have helped with kiosk software, hey i should show you
guys a picture of my kiosk design. |
| 23:33.49 |
Ralith |
I'm really
looking forward to digging around the display list code and hooking
that up |
| 23:33.55 |
brlcad |
which happens
to be a lot of the same that search exec needs, and other
priorities |
| 23:34.25 |
Ralith |
Yoshi47: oh?
I'd certainly be very interested in any comments you have, even on
the current highly incomplete state. |
| 23:34.57 |
``Erik |
bah, I
shoulda sent an email as well... allz I did was hollar at
indianlarry :/ |
| 23:34.59 |
Yoshi47 |
Ralith, i
will have yo learn how to downlaod and compile it, since i don't
think its in svn |
| 23:35.06 |
Ralith |
Yoshi47: it's
in SVN. |
| 23:35.22 |
Yoshi47 |
so if i
compiled this morning it will be inthere? |
| 23:35.36 |
Ralith |
before I get
to the fun stuff I still need to fix that damned input handling bug
(the filter that sends input to camera control is for some reason
getting events from *everything*, leading to strange
behavior) |
| 23:35.45 |
Ralith |
Yoshi47: it's
not part of brl-cad proper. |
| 23:35.52 |
Ralith |
build system
isn't integrated |
| 23:35.58 |
Ralith |
different
tree |
| 23:36.01 |
Ralith |
but it's
still there. |
| 23:36.11 |
Ralith |
it's in
rt^3/src/g3d |
| 23:36.45 |
Yoshi47 |
oh ok, well
im busy right now but i will be sure to look at it soon
hopefully. |
| 23:36.56 |
Yoshi47 |
i started
learning qt4 this spring |
| 23:38.05 |
``Erik |
"well... a
certain kind of pirate, yes, we've been called that" "is there some
kind of preschool program?" hehehe good old family guy |
| 23:38.56 |
Ralith |
Yoshi47:
cool! Direct contributions are certainly welcome as
well. |
| 23:39.11 |
Ralith |
that input
bug, for example, is a qt-wrangling issue. |
| 23:39.38 |
Yoshi47 |
i don't know
if im there, since it takes me long enough to get a basic app
going, currently working FANO (food and nutrional
organizer) |
| 23:40.16 |
``Erik |
wait, did we
lose 2? I thought we had 5 at the beginning |
| 23:41.14 |
``Erik |
huh, only 4,
*think* |
| 23:41.22 |
``Erik |
wait, I
remember now heh :) |
| 23:42.06 |
CIA-28 |
BRL-CAD:
03brlcad * r35695 10/brlcad/trunk/TODO: annotate a couple of the
header tasks to make life easier |
| 23:42.29 |
brlcad |
~seen
madant |
| 23:42.31 |
ibot |
madant
<i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last
seen on IRC in channel #brlcad, 52d 3h 20m 37s ago, saying:
'nothing more disastrous than non-cooperative softwares
;)'. |
| 23:43.45 |
brlcad |
``Erik:
ralith was d-lo's not indianlarry's |
| 23:44.16 |
Ralith |
observes that it might be advisable in the future to
associate mentors based on timezone |
| 23:44.23 |
``Erik |
hrm? I
know... O.o |
| 23:44.32 |
Ralith |
not that this
was a real problem thanks to IRC, but still. |
| 23:45.00 |
``Erik |
a week or two
ago, when one of the 'almost time' emails came out, I let
indianlarry know it was approaching, so he could do his part... not
so he could probe his student :) |
| 23:45.05 |
brlcad |
ahh |
| 23:46.49 |
Yoshi47 |
heres a link
to my prototype Kiosk we call it the "Miniky" since the first one
was different and way bigger" i do have another prototype after
this one that has rounded corners, and a slide out filter tray and
a little different design on the back, enjoy! |
| 23:46.50 |
Yoshi47 |
http://ej.nijenhuis.pixi.me/v/kiosk/ |
| 23:47.08 |
brlcad |
someone
should take a look at what jra just implemented in jbrlcad to
convert it to librt... |
| 23:47.34 |
Yoshi47 |
is brlcad
using java libs? |
| 23:47.39 |
brlcad |
maybe a
src/conv tool that uses it .. arb6tobot |
| 23:47.40 |
Ralith |
no. |
| 23:47.47 |
brlcad |
yeah, no.
;) |
| 23:47.48 |
Ralith |
there was an
experimental thing |
| 23:47.52 |
Ralith |
but afaik
it's dead now |
| 23:47.57 |
brlcad |
it's not
dead |
| 23:47.57 |
Yoshi47 |
Ralith,
good |
| 23:48.00 |
Ralith |
inactive? |
| 23:48.04 |
``Erik |
well, there's
jbrlcad which is a tiny subset of librt written in java, but it's
seperate |
| 23:48.14 |
``Erik |
daytona pokes
at it on occasion |
| 23:48.14 |
brlcad |
it's actually
in production use.. it's just "done enough" for that purpose for
now |
| 23:48.21 |
Yoshi47 |
umm |
| 23:48.28 |
brlcad |
none of our
tools uses it |
| 23:48.41 |
Yoshi47 |
why would
they use java for just a tiny bit? |
| 23:48.51 |
``Erik |
and there's
src/librtserver/ which exposes some of the C librt to java via JNI,
but it requires java interface classes that are not publically
available |
| 23:49.08 |
brlcad |
librtserver
is closer to being dead |
| 23:49.27 |
``Erik |
and a notion
that we'd like to expose a lot of our shtuff via swig, which'd
allow a java target |
| 23:49.39 |
``Erik |
are they
giving up librtserver for the GS? |
| 23:49.39 |
brlcad |
jbrlcad lets
them access a .g and shoot rays at geometry without needing to
bridge across JNI |
| 23:50.14 |
*** join/#brlcad docelic
(n=docelic@78.134.202.224) |
| 23:50.49 |
Yoshi47 |
what does the
whole collaborative thing do? network helping? viewing? |
| 23:51.08 |
Ralith |
which
collaborative thing? |
| 23:51.29 |
Ralith |
the geometry
server project is at least in part targeted at allowing people to
work together on a single model, I believe. |
| 23:51.37 |
Ralith |
but I doubt
that's what you're talking about |
| 23:51.54 |
Yoshi47 |
the menu item
under modes |
| 23:52.02 |
Ralith |
oh, an mged
thing. |
| 23:52.15 |
Yoshi47 |
ya |
| 23:52.37 |
Yoshi47 |
thats all i
know right now, besides, g-dxf, dxf-g, pix-png |
| 23:53.00 |
Ralith |
huh. no
idea. |
| 23:53.01 |
Yoshi47 |
ive only
touch a bit |
| 23:53.23 |
Yoshi47 |
Ralith,
didni't you do through the whole old interface before designing the
new one? |
| 23:53.32 |
Ralith |
nope. |
| 23:53.54 |
Ralith |
I'm familiar
with its basics, but I fall far short of knowing the function of
every menu item :P |
| 23:54.08 |
brlcad |
when you turn
on collaborate, another mged can attach and you share the same
geometry view |
| 23:54.21 |
Ralith |
neat! |
| 23:54.26 |
Yoshi47 |
another mged
from another pc or same X |
| 23:54.28 |
mafm |
congratz,
gsoc folks |
| 23:55.26 |
Yoshi47 |
on behalf of
gsoc folks, thank you! lol |
| 23:55.45 |
mafm |
I mean Ralith
and the rest |
| 23:55.50 |
Yoshi47 |
im their
spokes person |
| 23:55.51 |
Yoshi47 |
i
know |
| 23:55.54 |
``Erik |
heh |
| 23:55.55 |
mafm |
though I
don't see the rest around much :P |
| 23:55.57 |
Yoshi47 |
no one was
answrring |
| 23:56.04 |
``Erik |
raises his beer to all the gsoc folk O.o |
| 23:56.14 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks
everyone! |
| 23:56.15 |
Yoshi47 |
i raised my
MUG(root beer) |
| 23:56.17 |
Ralith |
does think that the rest are missing out by not IRCing
harder. |
| 23:56.23 |
Ralith |
upload to
google? |
| 23:56.37 |
brlcad |
you have to
upload your code to google |
| 23:56.50 |
Ralith |
okie. |
| 23:56.52 |
brlcad |
it's
technically what they pay you for, you're "testing" their upload
service :) |
| 23:56.56 |
Ralith |
heh |
| 23:56.59 |
Ralith |
digs for menu item |
| 23:56.59 |
Yoshi47 |
lol |
| 23:57.01 |
louipc |
you have to
upload all your patches? |
| 23:57.07 |
brlcad |
yeah,
basically |
| 23:57.13 |
Ralith |
er, that
sounds complicated. |
| 23:57.13 |
louipc |
CRAZY |
| 23:57.17 |
Ralith |
can I just
send them a tarball of g3d? :P |
| 23:57.29 |
``Erik |
some mentors
can't irc from work and want to spent their home time with their
family *shrug* I know it sounds insane, but some people honestly
have better things to do than sit around on irc O:-) |
| 23:57.36 |
Yoshi47 |
zip then
encrypt it too! |
| 23:57.36 |
Ralith |
(yeah, I
know, I'll find their docs) |
| 23:57.38 |
``Erik |
does not. :( |
| 23:57.42 |
Ralith |
``Erik: I
mean the students |
| 23:57.47 |
louipc |
Ralith: send
them a diff from when you started ;) |
| 23:57.52 |
louipc |
hehehhhe |
| 23:57.56 |
brlcad |
I think they
just want the code you wrote/worked on, but an svn diff from when
you started to know might be sufficient too -- have to read the
requirement |
| 23:58.01 |
``Erik |
yeh, the
students benefit quite a bit from jabbering on irc I
think |
| 23:58.13 |
Ralith |
I know I
have |
| 23:58.19 |
Ralith |
not to
mention being easily accessible for brlcad to poke at
>_> |
| 23:58.31 |
brlcad |
:) |
| 23:58.35 |
brlcad |
pokes Ralith |
| 23:58.36 |
Yoshi47 |
me too, even
though im not part of it, but im a BRL-CAD studen, level
newbie |
| 23:58.39 |
Ralith |
jumps |
| 23:58.42 |
brlcad |
been a good
summer |
| 23:58.45 |
``Erik |
does svn have
fu to say "show me the differences between -rX and -rY that
<user> did"? (I'd be surprised) |
| 23:59.03 |
Ralith |
well, iirc
noone else has committed to g3d so I'm okay there |
| 23:59.07 |
Ralith |
just need to
dig up the right revision |
| 23:59.27 |
Yoshi47 |
should of
taken a snapshot when you started |
| 23:59.27 |
``Erik |
(heh, might
be an argument for darcs or git or bzr... :/ ) |
| 23:59.29 |
louipc |
wooo |
| 23:59.29 |
brlcad |
nope, no user
grepping that i'm aware of internally |
| 23:59.34 |
brlcad |
probably have
to log raw and search |
| 23:59.38 |
``Erik |
yoshi: that
doesn't help when other people touch the same code |
| 23:59.46 |
Yoshi47 |
``Erik,
true |
| 00:00.14 |
mafm |
Ralith: other
students sometimes post scripts for that |
| 00:00.15 |
Yoshi47 |
you should be
able to see just your if you used yoru username to snv |
| 00:00.22 |
mafm |
to get only
your commits in svn, for example |
| 00:01.14 |
louipc |
yeah you
could make a script to spit out a buttload of diffs you
committed |
| 00:01.20 |
``Erik |
if you're on
the commit mailing list, just grab all the emails with your patches
and aggregate them? *shrug* I'd hope most people have access to
email clients powerful enough to do that |
| 00:01.44 |
Ralith |
most people
have access to all sorts of fun stuff |
| 00:01.46 |
``Erik |
or write a
script to svn log . | grep <username> and dork with the
rev#'s |
| 00:01.50 |
Ralith |
but that
doesn't mean they can use it. |
| 00:02.08 |
mafm |
now off to
bed, night! |
| 00:02.12 |
Yoshi47 |
cya |
| 00:02.15 |
``Erik |
hasta |
| 00:02.27 |
louipc |
bye
mafm |
| 00:03.03 |
Yoshi47 |
way off the
rocker here but anyone seen a basic g code (CNC machine lang)
exported in brl? |
| 00:03.15 |
Ralith |
a few people
have tried |
| 00:03.19 |
Ralith |
jonored got
very close but dissapeared |
| 00:03.27 |
Yoshi47 |
umm |
| 00:03.32 |
Ralith |
someone else
was talking about writing one but I haven't seen him around for a
while |
| 00:03.51 |
Ralith |
bear in mind
it's a nontrivial task because g-code is toolpaths, not shape
data. |
| 00:03.55 |
``Erik |
isn't stl a
common format for cnc type folk? we have g-stl |
| 00:03.59 |
Yoshi47 |
well if i was
a good coders i'd try |
| 00:04.11 |
``Erik |
(and then
other tools generate the path/bit info from the shape?) |
| 00:04.37 |
``Erik |
Yoshi47:
check out http://gcam.js.cx/ |
| 00:04.40 |
Ralith |
``Erik:
that's correct |
| 00:04.41 |
Ralith |
but
lossy |
| 00:04.43 |
Yoshi47 |
<PROTECTED> |
| 00:04.46 |
Ralith |
very lossy in
fact |
| 00:05.03 |
louipc |
yeah stl
wouldn't be good for precision machining |
| 00:05.18 |
Yoshi47 |
maybe >
.01 |
| 00:05.24 |
Yoshi47 |
or not
even? |
| 00:05.42 |
``Erik |
lossy in the
g->stl, or the stl->gerber ? |
| 00:05.54 |
``Erik |
cuz if you
have time, you can crank the precision way up for
g->stl |
| 00:06.13 |
Yoshi47 |
well im back
to gentoo |
| 00:06.14 |
Yoshi47 |
lol |
| 00:06.26 |
``Erik |
one adventure
at a time? :) |
| 00:06.30 |
louipc |
fbsd's still
uninstallable? |
| 00:06.33 |
louipc |
:P |
| 00:07.01 |
``Erik |
fbsd has a
nice installer, but it has unix notions which are very alien to
linux people (who are more in sync with dos/windows
people) |
| 00:07.02 |
Ralith |
brlcad:
should I make an effort to include every single change I made, or
just the g3d stuff? The only real non-g3d commits I've made were
moving the cmake modules for finding Ogre, Qt, etc. into the rt^3
cmake dir. |
| 00:07.06 |
Yoshi47 |
louipc, yeah
to much to learn so little time, i need to get me temp joomla site
on my notebook for a meeting tomorrow |
| 00:07.08 |
louipc |
I got it
working before, but it just felt so primitive |
| 00:07.13 |
``Erik |
pcbsd is the
bsd that targets "noobs" |
| 00:07.15 |
Ralith |
``Erik: also
the installer's pretty much unmaintained >_> |
| 00:07.27 |
``Erik |
what're you
talking about? the installer gets loving every release |
| 00:07.38 |
Yoshi47 |
oh well, i
know gentoo half decent so i'll stick with it |
| 00:07.41 |
``Erik |
(but they
still don't deal with usb keyboards in the holoshell,
damnit) |
| 00:07.52 |
louipc |
linux feels
more modern for some reason |
| 00:08.03 |
Ralith |
really? When
I was a fbsd user, it was one of the pieces everyone couldn't wait
to replace |
| 00:08.22 |
louipc |
hah |
| 00:08.30 |
Yoshi47 |
hey when i
redo my bearing with a nice background will it get put on the
website or does it have to go throughthe critics board
first? |
| 00:08.39 |
``Erik |
a lot of
people wanted a gui installer, like mandrake, but those're awfully
wasteful for a little eye candy for newbies :/ |
| 00:08.49 |
louipc |
yeah those
are lame |
| 00:08.52 |
Ralith |
just a lessy
buggy one would do |
| 00:08.59 |
``Erik |
that argument
is kinda what spawned the pcbsd fork |
| 00:09.21 |
``Erik |
that and
making the fresh install fire up a gui by default |
| 00:09.30 |
louipc |
theres no
reason the console environment can't be noob friendly
though |
| 00:10.53 |
``Erik |
meh *shrug* I
just installed fbsd 7.2 a couple weeks ago, didn't have any issues,
see any bugs, or have any reason to complain... was able to go from
"I wanna install" to "booted up on a fresh and configured system"
in the span where a redhat install did like 20% of its package
install |
| 00:10.53 |
louipc |
Yoshi47:
more.brlcad.org? |
| 00:11.13 |
Yoshi47 |
i don't know
the gallery from the wiki |
| 00:12.09 |
louipc |
you could
actually post the .g file in the model repository |
| 00:12.35 |
``Erik |
yoshi:
looking at that bearing where the balls are exposed: are there
supposed to be one or two more bearings in there, or are they
actually supposed to be that loose? and are the gutters in the
runners supposed to be that deep? how would it be assembled? they
press them together and rely on elastic deformation of the metal,
right? |
| 00:12.58 |
``Erik |
heh, I said
"where the balls are exposd" hehehehehehe mmm
hehehehhehe |
| 00:13.04 |
``Erik |
</beavis> |
| 00:13.56 |
Yoshi47 |
no they
actually have a carriage in there that keeps the balls seperated,
the carriage a very wierd shape and looks to be very hard to draw.
everything else was measured |
| 00:14.11 |
``Erik |
ahh, a
plastic dealiemajigger? |
| 00:14.11 |
Yoshi47 |
accurate to
0.1 mm |
| 00:14.15 |
louipc |
they can be
loosish |
| 00:14.19 |
Yoshi47 |
nope actaully
to steel things |
| 00:14.23 |
louipc |
grease up the
slack |
| 00:14.24 |
``Erik |
ah,
neat |
| 00:14.26 |
Yoshi47 |
they
can |
| 00:14.38 |
Yoshi47 |
i will take
pics tomorrow |
| 00:14.48 |
``Erik |
how big is
the assembly? |
| 00:14.50 |
Yoshi47 |
of the
assembly and disassembly if your like |
| 00:14.56 |
Yoshi47 |
the
bearing |
| 00:14.56 |
``Erik |
is that the
2cm diameter one? |
| 00:15.07 |
Yoshi47 |
22mm OD and
8mm ID |
| 00:15.12 |
Yoshi47 |
7mm
wide |
| 00:15.22 |
Yoshi47 |
balls are 4mm
in dia |
| 00:15.46 |
Yoshi47 |
groove is a
tor with rad 1 = 7.5 and rad 2= 2 |
| 00:15.49 |
``Erik |
small, musta
been hard to measure :) micrometer time |
| 00:16.02 |
Yoshi47 |
vernier
actually |
| 00:16.07 |
Yoshi47 |
digital so
its easy |
| 00:16.09 |
Ralith |
who's
responsible for MoRe? |
| 00:16.09 |
``Erik |
ah |
| 00:16.25 |
Yoshi47 |
and i have
near sitted vision so i can see thing up close like a
microscope |
| 00:16.27 |
``Erik |
ralith: elena
developed it |
| 00:16.29 |
louipc |
ebautu |
| 00:16.30 |
louipc |
? |
| 00:17.07 |
``Erik |
cool beans,
yoshi, I don't have access to neat toys, I have a cheap plastic
caliper :) |
| 00:17.15 |
Yoshi47 |
i have they
day off tomorrow, i forgot, so i will have no distractions and i
can do a good time trial, yes! its on... |
| 00:17.35 |
Yoshi47 |
``Erik, $15
on sale a canadian tire, accurate to 1 thou |
| 00:18.08 |
``Erik |
is in md, the 51st state is a bit of a hike
O:-) |
| 00:18.16 |
Ralith |
hm |
| 00:18.25 |
Ralith |
where can I
find the code upload form? |
| 00:19.15 |
Yoshi47 |
``Erik, i
have 2 of them, lol |
| 00:19.43 |
Ralith |
found the
2008 google code project |
| 00:20.15 |
louipc |
Yoshi47:
where was it made? :P |
| 00:20.45 |
Ralith |
but that's,
well, 2008 |
| 00:20.48 |
Yoshi47 |
matercraft, i
don't know but for the price they are pretty good, can even be used
for maching |
| 00:21.15 |
Yoshi47 |
louipc, i was
suprised how tight the tolerences are on it, im pretty piky that
way. |
| 00:22.24 |
louipc |
yeah I guess
there's no point in being too picky with a caliper. |
| 00:23.01 |
``Erik |
http://groups.google.com/group/google-summer-of-code-announce/web/how-to-provide-google-with-sample-code |
| 00:23.14 |
Yoshi47 |
nope and
anything i draw it is good enough, maybe i'll give that ball
carriage a go tomorrow! next challenge, after my time trial to get
back my bearing |
| 00:23.31 |
louipc |
cool |
| 00:23.34 |
Yoshi47 |
will most
likely take double the time then the bearing |
| 00:23.47 |
``Erik |
that's for
08, but it might give ya hints for how to do it in 09?
*shrug* |
| 00:24.10 |
louipc |
maybe you can
be one of the usability guys :D |
| 00:24.23 |
Yoshi47 |
louipc, what
do you mean? |
| 00:24.46 |
louipc |
there's
something like gsoc, but focusing on usability |
| 00:25.02 |
Yoshi47 |
oh a
tester/ |
| 00:25.11 |
louipc |
I forgot what
the url is.. |
| 00:25.43 |
``Erik |
me too, I
vagually remember that project... we even talked about submitting
parts of BRL-CAD to it, iirc |
| 00:26.44 |
louipc |
http://www.openusability.org/
? |
| 00:28.09 |
Yoshi47 |
yep |
| 00:29.01 |
Ralith |
``Erik: hm,
seems like maybe I just need to wait |
| 00:31.06 |
``Erik |
openusability.org doesn't seem very...
alive... |
| 00:32.25 |
``Erik |
season
announcement in march, call for students in april... then
nothing... (the announcement says june-aug, nothing about wrapup,
selection, anything) |
| 00:33.49 |
Yoshi47 |
what should i
draw in brl tonight? |
| 00:34.08 |
louipc |
an
impeller |
| 00:34.13 |
Yoshi47 |
lol, your
funny |
| 00:34.22 |
Yoshi47 |
something i
can get done tonight |
| 00:34.26 |
Yoshi47 |
but yeah that
would be fun |
| 00:34.29 |
louipc |
a tiny
one |
| 00:34.41 |
Yoshi47 |
well i do
like a challenge |
| 00:34.52 |
Ralith |
louipc:
wouldn't that need NURBS? |
| 00:34.57 |
Yoshi47 |
do i have
impeller herE? |
| 00:34.59 |
Yoshi47 |
umm |
| 00:35.34 |
louipc |
Ralith: yeah
nurbs would help |
| 00:35.49 |
Yoshi47 |
louipc, what
one? http://en.wikipedia.org/wiki/File:Pump_Impellers-1.jpg |
| 00:35.59 |
Ralith |
considering
that that's alpha-quality at best, last I chcked, that's a bad
choice :P |
| 00:36.39 |
Ralith |
of course he
could just make a primitive one |
| 00:36.40 |
louipc |
how bout this
one? http://www.friotherm.com/impeller.jpg |
| 00:37.32 |
Yoshi47 |
you pushing
it |
| 00:37.37 |
Ralith |
lol |
| 00:37.53 |
Ralith |
good luck
with that |
| 00:38.23 |
louipc |
I still have
to figure out how to model properly shaped threads |
| 00:38.37 |
Yoshi47 |
specs? |
| 00:39.20 |
louipc |
dunno, just a
standard 60 deg thread |
| 00:39.41 |
Yoshi47 |
i was talking
about the impeller |
| 00:39.58 |
louipc |
oh sorry I
was just joshing you |
| 00:40.55 |
Yoshi47 |
not you too.
everyone does that too me |
| 00:41.10 |
Yoshi47 |
i pick a
little easier impeller |
| 00:41.23 |
Yoshi47 |
since you too
extranvagent |
| 00:41.24 |
``Erik |
yoshi: some
popular beginner exercises are a mug, a pinewood derby car, a pen,
a book case, ... |
| 00:42.00 |
Ralith |
ooh, found a
script |
| 00:42.17 |
Yoshi47 |
``Erik, i did
the mug |
| 00:42.30 |
``Erik |
look around
your desk for something simple? :) |
| 00:42.39 |
louipc |
you went
through vol II eh? |
| 00:42.47 |
Yoshi47 |
the
intro... |
| 00:43.19 |
``Erik |
ooh, model a
2002 bmw m3 down to the threads in the nuts, that'd be awesome
:D |
| 00:44.12 |
Yoshi47 |
``Erik, you
just as outrageuous as louipc, im looking for a nice
impeller/easy |
| 00:44.16 |
Yoshi47 |
then chrome
it! |
| 00:45.20 |
Ralith |
thinks BMW would object to such detailed designs for their
stuff being available |
| 00:45.36 |
``Erik |
hehehe |
| 00:45.41 |
Yoshi47 |
lol |
| 00:45.47 |
``Erik |
but when I do
rtweight, I want the result to come out real damn close to my car
:D |
| 00:46.01 |
``Erik |
hum, model
'bender' from futurama? |
| 00:46.10 |
Yoshi47 |
``Erik,
nah |
| 00:46.13 |
``Erik |
and then you
can raytrace his shiney metal ass? |
| 00:46.17 |
Yoshi47 |
``Erik,
lol |
| 00:47.33 |
``Erik |
hm, fishtank
would be too easy, even I can model one of those |
| 00:47.50 |
louipc |
model a
CD-ROM disc |
| 00:48.07 |
Ralith |
model a
CD-ROM drive. |
| 00:49.01 |
louipc |
that would
take a while |
| 00:49.09 |
Yoshi47 |
hey is there
a way to save the mged bash history |
| 01:00.53 |
Yoshi47 |
well i got a
good picture of and impeller, now to design the fins.! |
| 01:02.23 |
``Erik |
I see the
class defining the command history, but I don't see any methods for
saving it and don't see the invocation variable :/ |
| 01:02.30 |
``Erik |
<--
doesn't know tcl |
| 01:49.39 |
brlcad |
Ralith: I'd
say do whatever the docs say :) |
| 01:50.00 |
brlcad |
but yeah, I
don't think you should be uploading ogre/qt diffs |
| 01:50.11 |
brlcad |
they just
want the code you actually *write* |
| 01:50.34 |
Ralith |
yeah, I
remembered that that would be an issue when the shellscript started
printing timeouts |
| 01:50.49 |
Ralith |
I actually
wrote the cmake stuff but it'll be captured in the diffs of the
g3d/ stuff even though it's not present there now |
| 01:52.36 |
brlcad |
we had a good
chance to get accepted into openusability .. just have to try again
next year |
| 02:01.59 |
starseeker |
brlcad: does
this seem like a reasonable categorization of BRL-CAD's primitives?
http://bzflag.bz/~starseeker/geometric_primitives.txt |
| 02:31.18 |
``Erik |
nmg has a
brep variant, too, iirc |
| 02:31.24 |
``Erik |
and I don't
see metaballs!!#~!@!~ |
| 03:00.41 |
CIA-28 |
BRL-CAD:
03starseeker * r35696
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Fooling
around with vectors - this will need a bit more
thought. |
| 03:01.03 |
starseeker |
``Erik:
That's the old nurbs stuff - it will eventually go away in favor of
ON_Brep |
| 03:01.42 |
starseeker |
NMG will
still handle what it currently handles, but better to do it as two
different setups IMHO |
| 03:02.05 |
starseeker |
``Erik: good
point - what are metaballs? implicit or explicit? |
| 03:02.59 |
``Erik |
I was kinda
hoping you'd tell me |
| 03:05.50 |
starseeker |
aaaaand the
bounding points are NOT on the plane of the face |
| 03:05.56 |
starseeker |
groans |
| 03:06.14 |
starseeker |
``Erik: I'm
guessing implicit |
| 03:06.53 |
``Erik |
well, I kinda
think of it as a contour of a value in space |
| 03:07.05 |
``Erik |
sorta a 4d
notion, I guess |
| 03:07.51 |
``Erik |
the first
form was modelled after point charges from physics |
| 03:09.05 |
starseeker |
nods |
| 03:10.00 |
starseeker |
math question
- for a collection of coplanar points, will the point xmin, ymin,
zmin be coplaner with the other points where the mins are the
individual x, y and z mins of all the coplanar points? |
| 03:13.12 |
``Erik |
I don't think
so |
| 03:13.22 |
``Erik |
but that'd
involve more thinking than I care to commit at the
moment |
| 03:13.40 |
louipc |
hmm my
whiskey looks like it's infused with the glass |
| 03:13.44 |
louipc |
http://louipc.mine.nu/brlcad/shot-glass/shot-glass.png |
| 03:14.30 |
``Erik |
louipc, I
know you wanna make the american counter to goldschlagger, but
seriously, dude, glass shards in whiskey, not a good idea
:D |
| 03:15.20 |
louipc |
hahhha |
| 03:15.43 |
louipc |
I guess I
have to mess around with the mater to get it to render
properly |
| 03:15.58 |
``Erik |
hm |
| 03:16.16 |
starseeker |
has only one other idea at the moment - take all the
verticies, find their center point, find the maximum distance
between any of the vertices and the center point, and use that
vector + the plane normal to define the UV space for the NURBS
surface |
| 03:16.28 |
``Erik |
the whiskey
should have a refractive coefficient of like 1.30 or something,
1.33 mebbe... (somewhere between water and alcohol), the lgass I
think is more like 1.45 or 1.5 depending on the type |
| 03:16.41 |
starseeker |
that seems
expensive though |
| 03:16.58 |
``Erik |
1.485-1.755 |
| 03:23.45 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 03:39.21 |
CIA-28 |
BRL-CAD:
03starseeker * r35697
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: OK, bounding
points are not on the plane. Record next idea. |
| 04:34.28 |
Ralith |
starseeker: I
believe Erik is correct |
| 04:35.44 |
starseeker |
Ralith: yeah,
figured :-/ |
| 04:35.47 |
starseeker |
thanks
though |
| 04:36.11 |
starseeker |
Ralith:
question - can you import anything into Ogre directly? (dxf,
say? |
| 04:36.14 |
Ralith |
think about
the plane described by the triangle ((0 0 0)(2 0 0)(0 1
-1)) |
| 04:36.34 |
Ralith |
now take a
point from the middle of that triangle (thus on the
plane) |
| 04:36.56 |
Ralith |
and set x to
0 and z to -1 |
| 04:37.39 |
starseeker |
nods |
| 04:38.03 |
starseeker |
I think I
have an approach, it just feels a bit like overkill |
| 04:38.10 |
Ralith |
afaik Ogre
includes file loaders for nothing but its built-in file
format |
| 04:38.18 |
Ralith |
why would
that be desirable, anyway? We want to display stuff from
.g |
| 04:38.34 |
starseeker |
right, but
we've got to get our geometry into something that Ogre can
handle |
| 04:39.15 |
starseeker |
figures we'll have to do (at least internally) a g-ogremesh
conversion of some sort... |
| 04:39.19 |
Ralith |
writing it to
temporary files isn't a good way to do that O.o |
| 04:39.29 |
starseeker |
oh,
agreed |
| 04:39.30 |
Ralith |
I'm
reasonably sure that we can just feed Ogre a point
cloud. |
| 04:39.33 |
Ralith |
er |
| 04:39.34 |
Ralith |
a
mesh |
| 04:39.42 |
Ralith |
generated
manually from the .g |
| 04:39.56 |
starseeker |
that would be
the internal logic for g-ogremesh :-) |
| 04:40.14 |
Ralith |
isn't entirely sure how ogre internally represents
objects |
| 04:43.48 |
starseeker |
apparently
ManualObject might be helpful... |
| 04:44.21 |
Ralith |
yeah, that's
where I was going to start research |
| 04:44.58 |
Ralith |
first guess
being something that'd end up with a class derived from
ManualObject for each primitive for mged-style
rendering |
| 04:45.25 |
starseeker |
hmm...
http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/ |
| 04:45.30 |
Ralith |
then maybe a
generic 'Boolean' ManualObject descendent for when the brep stuff
lets us quickly tesselate arbitrary booleans |
| 04:47.17 |
starseeker |
Ralith: any
luck on the 3d rotate and translate bugs? |
| 04:47.34 |
starseeker |
could manually make an Ogre mesh with blender and import for
a nice video demo :-) |
| 04:47.57 |
Ralith |
not a bad
idea. |
| 04:48.11 |
Ralith |
been focusing
on trying to fix the input bug but I guess I can put that
off |
| 04:48.41 |
starseeker |
nods. I'm wondering if that's tangled up with the multiple
OpenGL context stuff |
| 04:48.43 |
Ralith |
I have a
fairly good idea why the translate bug is doing that, and I know
conceptually what the rotate bug is doing but I'm not yet sure
where/how. |
| 04:48.53 |
Ralith |
doubt
it. |
| 04:49.00 |
Ralith |
would be hell
if it was |
| 04:49.10 |
starseeker |
heh
:-) |
| 04:49.12 |
Ralith |
eventually I
want to replace all that with a proper Ogre backend for
Qt. |
| 04:49.20 |
Ralith |
just because
I think it'd save so much pain |
| 04:49.24 |
starseeker |
nods |
| 04:49.47 |
Ralith |
there's a
good bit of 'special behavior' for all the various systems Qt's
going through to do this, which weren't really meant to be used
this way |
| 04:49.56 |
Ralith |
which has to
be worked around often awkwardly |
| 04:50.10 |
starseeker |
well, if you
can nail the rotate and translate bugs I'll do my best to manually
convert a model and we can make an Awesome Video :-) |
| 04:50.31 |
Ralith |
cool, I'll
see what I can do :) |
| 04:50.53 |
starseeker |
mutters to himself that he'll get it to play on the Mac by
default this time... |
| 04:50.58 |
starseeker |
OK,
sleep |
| 04:51.05 |
Ralith |
nite |
| 04:51.12 |
Ralith |
you'll need
to specialize the opengl hacks for Carbon. |
| 04:51.56 |
Ralith |
or just use
X |
| 05:15.08 |
*** join/#brlcad SRabbelier1
(n=sverre@c-24-6-188-8.hsd1.ca.comcast.net) |
| 05:17.58 |
``Erik |
sleep is for
the weak |
| 05:18.03 |
``Erik |
*snore* |
| 05:21.31 |
*** part/#brlcad SRabbelier1
(n=sverre@c-24-6-188-8.hsd1.ca.comcast.net) |
| 07:46.26 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 09:05.03 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 10:19.04 |
*** join/#brlcad mafm_
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 11:28.06 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 11:47.11 |
CIA-28 |
BRL-CAD:
03johnranderson * r35698
10/jbrlcad/trunk/src/org/brlcad/geometry/BrlcadDb.java: |
| 11:47.11 |
CIA-28 |
BRL-CAD:
Added getDbFileName() method. |
| 11:47.11 |
CIA-28 |
BRL-CAD:
Added some java.util.logging |
| 11:47.55 |
CIA-28 |
BRL-CAD:
03johnranderson * r35699
10/jbrlcad/trunk/src/org/brlcad/spacePartition/PreppedDb.java: |
| 11:47.55 |
CIA-28 |
BRL-CAD:
Fixed some hosed formatting. |
| 11:47.55 |
CIA-28 |
BRL-CAD:
Added some java.util.logging |
| 11:53.27 |
CIA-28 |
BRL-CAD:
03johnranderson * r35700 10/jbrlcad/trunk/ (build.xml
test/logging.config): |
| 11:53.27 |
CIA-28 |
BRL-CAD:
Added logging.config for tests |
| 11:53.27 |
CIA-28 |
BRL-CAD:
Eliminated references to "jra" |
| 11:55.44 |
Yoshi47 |
can you edit
shapes vertice level, like in blender, where you can move the
vertices around where ever you want? |
| 12:16.23 |
brlcad |
if there's
actually a vertex, you usually can |
| 12:17.56 |
brlcad |
boolean
operations on implicit primitives, however, can cause the addition
of new vertices/edges/faces, though that are likewise _implicit_
and cannot be directly manipulated as such |
| 12:22.45 |
brlcad |
we're moving
more towards a hybrid representation system so that we can also
maintain an explicit representation, which allows for direct
manipulation, but that's a ways off |
| 12:23.11 |
Yoshi47 |
ah |
| 12:23.43 |
brlcad |
it gets at
the heart of the differences in the way geometry is represented,
ours being based on a strongly mathematical basis -- which is done
for analysis purposes, guarantees of correctness and
topology |
| 12:24.09 |
brlcad |
something
which isn't of any concern to a content modeling system |
| 12:25.55 |
Yoshi47 |
nope |
| 12:26.04 |
Yoshi47 |
so i know
have my turbine blade |
| 12:26.31 |
Yoshi47 |
which is a
region of shapes, can i take that region and clone it around the
center axis of the turbine |
| 12:32.36 |
Yoshi47 |
i guess i
can't take a object and rotate it hey? |
| 12:34.21 |
brlcad |
sure you
can |
| 12:34.21 |
Yoshi47 |
nevermind, i
did it, oed, dug |
| 12:34.43 |
Yoshi47 |
only 11 more
cp and rot, well im off for now, see ya guys later. |
| 12:35.46 |
CIA-28 |
BRL-CAD:
03starseeker * r35701
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Add ascii
art drawing of nmg_brep algorithm idea. |
| 13:07.04 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 13:14.25 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35702
10/brlcad/trunk/src/adrt/librender/camera.c: revert to single
threaded mode if pthreads fail for some reason |
| 14:04.29 |
CIA-28 |
BRL-CAD:
03bob1961 * r35703 10/brlcad/trunk/src/librt/db_lookup.c: Updated
db_lookup_by_attr to skip phony entries. |
| 14:35.01 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 14:53.46 |
CIA-28 |
BRL-CAD:
03irpguardian * r35704
10/brlcad/trunk/src/libged/human.c: |
| 14:53.46 |
CIA-28 |
BRL-CAD:
Added a new function which dumps out all measurements to a
textfile, Verbose.txt, for debugging purposes.
Automatically |
| 14:53.46 |
CIA-28 |
BRL-CAD: runs
for now. |
| 14:57.09 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35705
10/brlcad/trunk/src/other/step/src/express/ (25 files): |
| 14:57.09 |
CIA-28 |
BRL-CAD:
Twist up how package headers are included. Heimdall has a
"resolv.conf" that is |
| 14:57.09 |
CIA-28 |
BRL-CAD:
installed and sometimes is grabbed instead of
include/express/resolve.h, so pull |
| 14:57.09 |
CIA-28 |
BRL-CAD: the
express include directory up a level and refer to headers as,
say, |
| 14:57.10 |
CIA-28 |
BRL-CAD:
"express/resolve.conf". |
| 15:09.19 |
CIA-28 |
BRL-CAD:
03irpguardian * r35706 10/brlcad/trunk/src/libged/human.c:
Formatted verbose output to be more organized, and
aligned |
| 15:25.52 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 15:42.31 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 17:24.18 |
*** join/#brlcad h4r1 (n=dbs@115.240.58.70) |
| 17:34.21 |
h4r1 |
Hey |
| 18:19.55 |
brlcad |
starseeker:
several missing, but looks mostly good. would not characterize the
non-volumetric as such as it's not particularly meaningful -- half
is implicit, sketch is 2D explicit primitive, grip is a
non-geometric primitive |
| 18:21.00 |
brlcad |
the explicit
qualifier is redundant on polygonal/spline surface, and you have a
typo there (splice) |
| 18:21.54 |
brlcad |
ebm, hf, and
dsp really belong in their own class as volumetric
representations |
| 18:22.27 |
brlcad |
louipc: neat
shot glass! |
| 18:39.32 |
``Erik |
hm,
"bokode" |
| 18:57.58 |
Yoshi47 |
well who's
ready for time trials... |
| 18:58.11 |
brlcad |
hehe |
| 18:58.16 |
brlcad |
ready |
| 18:58.17 |
brlcad |
set |
| 18:58.18 |
brlcad |
go! |
| 18:58.25 |
Yoshi47 |
wait wait
wait |
| 18:58.45 |
Yoshi47 |
i have to
prep my work space |
| 18:59.08 |
Yoshi47 |
cold water:
check, |
| 18:59.13 |
Yoshi47 |
lock door,
check |
| 18:59.23 |
Yoshi47 |
tell everyone
not to bug me, check |
| 18:59.34 |
Yoshi47 |
migraine go
away, nope |
| 18:59.39 |
Yoshi47 |
oh
well.. |
| 19:01.20 |
Yoshi47 |
ok go
3:00 |
| 19:20.14 |
``Erik |
done yet,
yoshi? :D *duck* |
| 19:22.49 |
yukonbob |
hello,
cadheads |
| 19:23.36 |
brlcad |
hello
yukonbob |
| 19:24.18 |
yukonbob |
:D |
| 19:24.25 |
yukonbob |
how was
siggraph? |
| 19:24.29 |
Yoshi47 |
-5 minutes,
phone call from work |
| 19:24.37 |
Yoshi47 |
i got the
inner ring done. |
| 19:24.54 |
``Erik |
quit
chatting, ya might be able to beat an hour :D |
| 19:25.01 |
brlcad |
yukonbob:
fabulous |
| 19:25.06 |
Yoshi47 |
im closing
this |
| 19:25.11 |
yukonbob |
brlcad: very
nice... |
| 19:25.12 |
brlcad |
heh |
| 19:25.45 |
yukonbob |
brlcad: bring
back new ideas/inspirations? |
| 19:26.02 |
brlcad |
always |
| 19:26.20 |
yukonbob |
heh |
| 19:26.29 |
brlcad |
the ideas are
always in abundance, and helps to keep things in a big picture
perspective |
| 19:26.43 |
yukonbob |
nods |
| 19:26.48 |
yukonbob |
cool |
| 19:28.09 |
yukonbob |
was checking-out the siggraph website when you were there,
and noted a future (next year?) event is coming to
Vancouver |
| 19:28.33 |
brlcad |
possibly, at
least that's the current plan for the year after next |
| 19:28.44 |
brlcad |
there was
some dissention this year, though, that it might not
happen |
| 19:29.07 |
yukonbob |
ppl don't
want it out of America? |
| 19:29.28 |
brlcad |
moreover that
it was even a rumor to begin with according to one staffer (but I'm
not convinced he was in the know) |
| 19:29.45 |
brlcad |
in general,
no they don't |
| 19:30.17 |
yukonbob |
saw news published on a credible-looking
website. |
| 19:30.21 |
brlcad |
it's a very
big conference that makes and costs a lot of money .. even when
they simply leave Los Angeles, they usually lose money and
attendance is down |
| 19:30.24 |
``Erik |
imagines most attendees are from the US, and most of them
don't have passports |
| 19:47.30 |
CIA-28 |
BRL-CAD:
03irpguardian * r35707 10/brlcad/trunk/src/libged/human.c: Added
text input for all body measurements, by the file
Verbose.txt |
| 19:59.25 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 19:59.32 |
Yoshi47 |
well... |
| 19:59.37 |
Yoshi47 |
guess
what |
| 19:59.58 |
``Erik |
didn't finish
it? |
| 20:00.42 |
brlcad |
deleted it
again? |
| 20:00.42 |
Yoshi47 |
everything
done except the shield |
| 20:00.42 |
Yoshi47 |
lol
funny |
| 20:00.42 |
Yoshi47 |
i would be
pissed |
| 20:00.42 |
``Erik |
:D |
| 20:00.42 |
Yoshi47 |
who wants a
copy? |
| 20:00.42 |
brlcad |
hey, Yoshi47
.. why don't you post that up somewhere? :) |
| 20:00.42 |
Yoshi47 |
before i
delete it again |
| 20:00.44 |
brlcad |
hehe |
| 20:00.44 |
``Erik |
heh |
| 20:01.04 |
Yoshi47 |
i don't know
if i want other people to see my messy structure... |
| 20:01.05 |
Yoshi47 |
lol |
| 20:01.12 |
Yoshi47 |
where can i
post? |
| 20:01.31 |
``Erik |
also; ponder
using svn or something instead of rsync. a sorta manual 'undo'
capability, co where ya want it, easy semantics :) |
| 20:01.38 |
Yoshi47 |
or should i
just finish the shield and the textures first |
| 20:02.09 |
Yoshi47 |
one
sec... |
| 20:02.17 |
``Erik |
(just
something to think about *shrug* not saying it's a good
way) |
| 20:03.16 |
Yoshi47 |
http://ej.nijenhuis.pixi.me/v/bearing_g.html |
| 20:03.36 |
Yoshi47 |
``Erik, don't
worry i won't do that again. |
| 20:03.50 |
Yoshi47 |
someone try
and download it and tell me if it works... |
| 20:04.00 |
Yoshi47 |
B
complete.c |
| 20:05.04 |
Yoshi47 |
well someone
got it... who did it? |
| 20:05.17 |
``Erik |
just did |
| 20:05.22 |
Yoshi47 |
nice |
| 20:05.25 |
Yoshi47 |
does it
work? |
| 20:05.28 |
brlcad |
too |
| 20:05.33 |
Yoshi47 |
lol |
| 20:06.23 |
Yoshi47 |
i actually
added a couple more curved edges too... |
| 20:07.40 |
Yoshi47 |
i almost have
my turbine done too... just have to get the center shaft cut
out. |
| 20:11.48 |
brlcad |
so about 30
hours passive down to about an hour active |
| 20:18.38 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 20:18.54 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 20:26.00 |
``Erik |
hehehe glass
bearings :D |
| 20:26.47 |
``Erik |
looks awesome
in perspective mode |
| 20:33.08 |
CIA-28 |
BRL-CAD:
03irpguardian * r35708 10/brlcad/trunk/src/libged/human.c: Added
help on text input/output on the -? command |
| 20:39.27 |
Yoshi47 |
so you having
fun with my bearing |
| 20:48.40 |
``Erik |
http://brlcad.org/~erik/glassbearing.png |
| 20:49.36 |
Yoshi47 |
nice |
| 20:49.39 |
Yoshi47 |
little
dark... |
| 20:50.54 |
``Erik |
http://brlcad.org/~erik/glassbearing.rt
as an example of how to generate... |
| 20:51.09 |
``Erik |
it's glass
with a black background, of course it's dark :D |
| 20:51.19 |
Yoshi47 |
i wouldn't
even know how to use rt files yet |
| 20:51.25 |
``Erik |
it's a shell
script |
| 20:51.53 |
``Erik |
was generated
by using "saveview" in mged, then I tweaked it a bit :) |
| 20:52.38 |
starseeker |
sh
glassbearing.rt :-) |
| 20:52.45 |
Yoshi47 |
ah |
| 20:53.03 |
Yoshi47 |
so is whats
the diff between rtwizard and rendering in mged? |
| 20:53.15 |
``Erik |
different
ways to invoke rt |
| 20:53.30 |
Yoshi47 |
but same
background renderer |
| 20:53.41 |
``Erik |
for the most
part... |
| 20:54.02 |
``Erik |
the edge view
in rtwizard actually invokes rtedge instead of rt, then composites
the various images |
| 20:54.12 |
Yoshi47 |
oh |
| 20:54.21 |
Yoshi47 |
well who
wants a shity impeller? |
| 20:55.58 |
Yoshi47 |
most likely a
better way to draw but i don't know everything, and it takes
forever to render because of the code used to make, maybe once you
see you can offer suggestions for a better way... |
| 20:58.40 |
Yoshi47 |
heres the
link for the impeller http://ej.nijenhuis.pixi.me/v/CAD/impeller_g.html |
| 20:58.47 |
Yoshi47 |
louipc, your
impeller is done! |
| 20:58.58 |
Yoshi47 |
well if you
can call it an impeller |
| 21:08.19 |
``Erik |
yowza |
| 21:10.20 |
``Erik |
it renders
slow because it has to evaluate just about every primitive in the
screen for every ray, btw... imagine every plot (red wireframe of a
primitive) has a box around it, if the ray goes through that box,
it evaluates the primitive |
| 21:10.34 |
``Erik |
but it looks
neat |
| 21:17.46 |
brlcad |
wow, that is
slow.. :) |
| 21:17.52 |
brlcad |
good
optimization test case |
| 21:25.52 |
``Erik |
runs nice and
fast facetized, though O:-) |
| 21:30.47 |
brlcad |
heh |
| 21:30.50 |
brlcad |
cheater! |
| 21:31.45 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 21:36.08 |
*** join/#brlcad fenn
(n=fenn@cpe-72-177-121-73.austin.res.rr.com) |
| 21:36.23 |
fenn |
first rule of
computer graphics: glass always looks terrible on a black
background |
| 21:42.41 |
``Erik |
*snrkt*
http://news.ycombinator.com/item?id=785708 |
| 21:45.24 |
Yoshi47 |
brlcad, whos
a cheater? |
| 21:45.37 |
``Erik |
I am, for
facetizing it :D |
| 21:45.43 |
Yoshi47 |
oh |
| 21:46.11 |
``Erik |
(and, yeah,
glass on black isn't good, but I forgot to set a background color
and didn't want to make a surrounding scene) |
| 21:46.31 |
Yoshi47 |
i don't mind
white |
| 21:48.37 |
``Erik |
-C255/255/255 |
| 21:49.27 |
brlcad |
glass on
black can work, you just have to jack up the ambient a
bit |
| 21:49.34 |
brlcad |
http://brlcad.org/tmp/bearing/bearing.png |
| 21:50.03 |
Yoshi47 |
im just
trying to think why you would make a bearing out of
glass... |
| 21:50.06 |
``Erik |
giving the
glass a greenish hue might improve it, too... make it ...
glassier |
| 21:50.24 |
``Erik |
Yoshi47: cuz
glass stuff looks awesome raytraced? :D |
| 21:50.31 |
brlcad |
Yoshi47: no
reason :) |
| 21:50.36 |
brlcad |
or .. why
NOT?! |
| 21:50.41 |
brlcad |
ahem |
| 21:51.16 |
Yoshi47 |
it does look
cool, green tinge would be better |
| 21:51.18 |
``Erik |
in the
future, everything is made of glass |
| 21:51.22 |
Yoshi47 |
lol |
| 21:51.56 |
brlcad |
plus it's
quick n dirty .. creating lights, adding textures and bump
mappings, tweaking shaders.. that's all work :) |
| 21:52.10 |
brlcad |
likes the bearing |
| 21:52.29 |
Yoshi47 |
i just have
to finish the shield |
| 21:52.38 |
``Erik |
in a scene
with stuff around it and multiple lights, it'd look awesome, I
think |
| 21:52.39 |
Yoshi47 |
but at least
i have backups now! |
| 21:53.26 |
``Erik |
http://brlcad.org/~erik/glassbearing_white.png |
| 21:53.46 |
Yoshi47 |
ouch |
| 21:53.52 |
``Erik |
yeah |
| 21:54.45 |
CIA-28 |
BRL-CAD:
03starseeker * r35709
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Continue
crawling forward on nmg->brep |
| 21:55.11 |
Yoshi47 |
so any tips
for the impeller or bearing? |
| 21:57.55 |
fenn |
you should
have made it from diamond instead of glass :) |
| 21:58.30 |
fenn |
also i don't
suppose brlcad supports HDR environment maps |
| 22:00.48 |
brlcad |
nope |
| 22:00.54 |
brlcad |
patches
welcome ;) |
| 22:04.57 |
brlcad |
http://brlcad.org/tmp/bearing/bearing2.png |
| 22:05.35 |
Yoshi47 |
nice |
| 22:06.36 |
Yoshi47 |
i got my
other little bearing in 4mm wide and 10mm tall |
| 22:07.10 |
Yoshi47 |
so i have to
draw that up too soon, but im not going to do the inside, just the
outside cause it has shields on it and im not taking this one apart
cause i have to buy these. |
| 22:14.09 |
brlcad |
wee...
http://brlcad.org/tmp/bearing/bearing3.png
:) |
| 22:14.30 |
Yoshi47 |
i love
it! |
| 22:14.56 |
Yoshi47 |
just for your
info the bearing does have a little mirrow to it rough
mirror |
| 22:15.18 |
brlcad |
the impeller
is turning out fantastic too, but damn is it exercising the boolean
evaluator |
| 22:15.20 |
Yoshi47 |
but you need
surrondings then i think, that looks really good |
| 22:15.26 |
Yoshi47 |
lol |
| 22:15.45 |
brlcad |
especially as
glass, of course :) |
| 22:15.51 |
Yoshi47 |
anyway i
could of done it easier like a arb8 that can bend! |
| 22:16.04 |
starseeker |
Yoshi47:
patience :-) |
| 22:16.24 |
Yoshi47 |
starseeker,
im guessing its in the works! time line? |
| 22:16.26 |
brlcad |
glass is
particularly abusive, it's having to query almost the whole model
for every primary ray as well as every reflected and refracted
interior ray |
| 22:16.44 |
Yoshi47 |
i hope you
got a farm at your disposal |
| 22:16.58 |
brlcad |
not using
it |
| 22:17.02 |
starseeker |
Yoshi47: a
bit hard to say - editing is down the road |
| 22:17.13 |
starseeker |
You might
look at Ayam |
| 22:17.19 |
Yoshi47 |
Ayam? |
| 22:17.30 |
brlcad |
just an
8-core churning on it .. is looking very purty |
| 22:17.34 |
starseeker |
http://ayam.sourceforge.net/ |
| 22:17.49 |
starseeker |
they can
export 3dm nurbs, and in theory we can import them |
| 22:18.04 |
starseeker |
not in
practice thus far, but patches welcome :-) |
| 22:18.39 |
Yoshi47 |
umm |
| 22:19.31 |
CIA-28 |
BRL-CAD:
03starseeker * r35710 10/brlcad/trunk/src/
(librt/primitives/nmg/nmg_brep.cpp proc-db/csgbrep.cpp): More nmg
exploring... |
| 22:20.31 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 22:20.50 |
Yoshi47 |
can blender
export 3dm nurbs? |
| 22:21.11 |
starseeker |
to the best
of my knowledge Blender's NURBS support is incomplete |
| 22:21.34 |
Yoshi47 |
i think i
need more lesson on NURBS |
| 22:21.38 |
brlcad |
I love it
when I do a search for some obscure brep/nurbs topic and the top
results is a link to our svn or our irc log |
| 22:21.45 |
brlcad |
damnits |
| 22:22.15 |
Yoshi47 |
lol |
| 22:22.18 |
starseeker |
hehe - we may
not lead the field but we lead the google searches :-) |
| 22:22.45 |
Yoshi47 |
i don't like
that, well i do , but more support would be nice.. |
| 22:22.59 |
brlcad |
we apparently
lead the field that actually discusses it in the open
:) |
| 22:23.14 |
starseeker |
Yoshi47: it's
a Very Hard Problem |
| 22:23.17 |
Yoshi47 |
brlcad,
really, what does blender use then for their curves? |
| 22:23.48 |
brlcad |
Yoshi47: what
do you mean? they maintain their own geometry format
internally |
| 22:24.15 |
Yoshi47 |
oh, well im
reading more on NURBS right now to get more of an idea of the whole
thing. |
| 22:24.23 |
Yoshi47 |
sorry for my
incompetence |
| 22:24.30 |
brlcad |
NURBS is a
superset |
| 22:26.26 |
starseeker |
brlcad: I
hate to ask this, I think I've done so before - when creating a
vector with a starting point at x1, y1, z1 and end point at x2, y2,
z2 do I create a vector to P1 and a vector to P2 and add
them? |
| 22:28.37 |
brlcad |
er, depends
how you're using that vector |
| 22:29.19 |
Yoshi47 |
brlcad, how
the rendering coming on that impeller |
| 22:29.42 |
starseeker |
I have a
normal from plane_t, and a vector in space from P1 to P2 that I
want to cross with that normal |
| 22:30.09 |
starseeker |
or more
specifically, I want to center both the normal and the vector in
the plane on a particular point |
| 22:30.21 |
starseeker |
then cross
them |
| 22:30.22 |
brlcad |
Yoshi47: oh
it's really going to take a while :) i should have started a
distributed render at the quality level I picked |
| 22:30.41 |
Yoshi47 |
brlcad,
nice |
| 22:31.41 |
Yoshi47 |
so what state
is nurbs at? somewhat usable, in specing? |
| 22:38.32 |
brlcad |
mostly usable
on import |
| 22:38.37 |
brlcad |
you can't
create or edit them directly |
| 22:39.24 |
Yoshi47 |
umm, |
| 22:39.43 |
Yoshi47 |
i think the
math for that is pretty hard!' |
| 22:44.58 |
``Erik |
ok, barbie
O.o |
| 22:45.49 |
starseeker |
``Erik: last
time I checked, barbie can't cad model ;-) |
| 22:45.54 |
starseeker |
math or
no |
| 22:45.59 |
``Erik |
but barbie
says "math is hard" :D *duck* |
| 22:46.04 |
``Erik |
reads backlog, just got home |
| 23:42.01 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 00:11.58 |
``Erik |
ssshhhhh |
| 00:19.20 |
starseeker |
NNooooooo.
Jeez SCO, DIE already |
| 00:22.42 |
starseeker |
wonders who told them dead horse beating was an Olympic
sport... |
| 00:29.28 |
``Erik |
wasn't that
yesterday? or was that this morning |
| 00:49.00 |
Yoshi47 |
brlcad, how
the rendering coming on that impeller |
| 00:49.23 |
Yoshi47 |
or is it
going to take all night |
| 00:49.34 |
``Erik |
I imagine
he's not at his 'puter |
| 00:49.44 |
Yoshi47 |
whys
that |
| 00:50.10 |
yukonbob |
facepalms |
| 00:51.05 |
starseeker |
he's gone
home |
| 00:52.21 |
Yoshi47 |
oh |
| 01:47.41 |
CIA-28 |
BRL-CAD:
03starseeker * r35711
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: OK, might
actually be generating the right surface corner points
now. |
| 02:03.55 |
CIA-28 |
BRL-CAD:
03johnranderson * r35712 10/jbrlcad/trunk/ (6 files in 4
dirs): |
| 02:03.55 |
CIA-28 |
BRL-CAD: Ray,
Hit, and Partition are now Externalizable. |
| 02:03.55 |
CIA-28 |
BRL-CAD:
Added a test for Hit. |
| 02:37.17 |
CIA-28 |
BRL-CAD:
03starseeker * r35713
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Start to
rough out (and I stress the rough part) the remainder of the logic
for nmg->brep |
| 02:55.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 03:41.48 |
talcite |
ahh finally
figured out how to use Koji. We're going to get a ppc and SPARC
build if all goes well! =D |
| 04:52.11 |
*** part/#brlcad fenn
(n=fenn@cpe-72-177-121-73.austin.res.rr.com) |
| 06:53.23 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 07:32.56 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 07:37.37 |
talcite |
well, the
builds on ppc, ppc64, i386, x86_64 |
| 07:38.41 |
*** join/#brlcad Axman6_
(n=Axman6@pdpc/supporter/student/Axman6) |
| 07:40.47 |
talcite |
are
working* |
| 07:40.56 |
talcite |
=S I should
probably sleep now. I'm not making sense anymore |
| 08:56.24 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 09:00.32 |
*** join/#brlcad bobbens
(i=bobbens@saw4ever.de) |
| 09:16.02 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 10:21.52 |
*** join/#brlcad _sushi_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 11:13.14 |
*** join/#brlcad mafm_
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 11:15.20 |
*** join/#brlcad Yoshi47
(n=jan@firewall.walinga.com) |
| 11:21.40 |
*** join/#brlcad puddingpimp
(n=dave@118-93-244-155.dsl.dyn.ihug.co.nz) |
| 12:02.51 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) |
| 12:03.31 |
starseeker |
brlcad: would
volumetric representations be considered explicit
primitives? |
| 12:19.45 |
Yoshi47 |
is it always
this quiet when im not talking... |
| 12:22.16 |
Axman6 |
yes |
| 12:34.03 |
Yoshi47 |
lol |
| 12:54.03 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 12:58.19 |
CIA-28 |
BRL-CAD:
03jdoliner * r35714 10/brlcad/trunk/src/proc-db/
(surfaceintersect.cpp surfaceintersect.h): Added function
CurveCurveIntersect, which replaces the ON_Curve::IntersectCurve
function since it isn't actually implemented. |
| 13:07.27 |
CIA-28 |
BRL-CAD:
03Jdoliner 07http://brlcad.org *
r1607 10/wiki/User:Jdoliner: |
| 13:07.29 |
brlcad |
starseeker:
I've always thought of them as implicit/explicit
hybrids |
| 13:08.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 13:09.27 |
brlcad |
explicit
regular data but that implies some given volume -- the geometry
itself is implicit but it's distinct enough that the literature
generally considers it a separate case altogether |
| 13:09.39 |
brlcad |
Yoshi47: it
comes in waves |
| 13:09.49 |
Yoshi47 |
ah |
| 13:09.49 |
CIA-28 |
BRL-CAD:
03irpguardian * r35715 10/brlcad/trunk/src/libged/human.c: Various
changes to reflect new verbose setting |
| 13:10.03 |
Yoshi47 |
hows the
rendering coming |
| 13:10.21 |
brlcad |
non-stop
chatter for days, then really quiet, then tons of non-stop commit
messges, etc :) |
| 13:10.40 |
brlcad |
oh, I'm sure
it's finished .. but I'm not at that machine for another hour or
so |
| 13:11.07 |
brlcad |
i'm sure it's
done, it should have finished after about an hour |
| 13:12.36 |
brlcad |
jdoliner:
awesome :) |
| 13:13.15 |
brlcad |
except for
the overlap problem.. |
| 13:14.14 |
jdoliner |
yeah |
| 13:14.34 |
jdoliner |
I'm not sure
if I should spend time to do that now |
| 13:14.38 |
jdoliner |
or come back
to it a bit later |
| 13:26.10 |
``Erik |
hm, C or tcl,
C or tcl |
| 13:26.45 |
Yoshi47 |
C? |
| 13:27.30 |
``Erik |
might have to write the algo in psuedocode before deciding,
unless he can sucker brlcad into doing it "in a couple lines of
tcl" :D |
| 13:31.38 |
Axman6 |
Ada! |
| 13:38.05 |
``Erik |
"The GOTO is
like a chainsaw. yes, some folks can actually make good things, and
even make really nice carvings with a chainsaw. most just make a
big fucking mess." |
| 13:51.13 |
mafm |
lolcode
ftw |
| 13:53.08 |
CIA-28 |
BRL-CAD:
03starseeker * r35716
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: More
nmg->brep logic, still not functional... |
| 13:54.11 |
*** join/#brlcad docelic
(n=docelic@78.134.200.85) |
| 14:03.12 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 14:33.15 |
Yoshi47 |
Question: why
do i have to reset my color scheme everytime i open mged? why does
it save this preference? in the DB for the file your editing or
globaly like /home/josh/.brlcad/config? |
| 14:44.26 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 15:10.18 |
``Erik |
~/.mgedrc |
| 15:11.14 |
Yoshi47 |
umm |
| 15:11.23 |
indianlarry |
under GUI
File->Create/Update .mgedrc |
| 15:11.46 |
brlcad |
``Erik: which
algo? |
| 15:11.51 |
Yoshi47 |
indianlarry,
thanks |
| 15:11.58 |
indianlarry |
you
bet |
| 15:12.00 |
brlcad |
C ftw
;) |
| 15:13.22 |
``Erik |
wanna
recreate the tree, with name mangling. when I see a region bit, I
want to facetize into mangle;s/$/.bot/ and add that to the mangled
region, with all mater and attr shtuff duped |
| 15:14.46 |
``Erik |
recfacetize
's/$/_f/' all.g -> all.g_r { tor.r_f { tor.r_f.bot } +
cone.r_f { cone.r_f.bot } } |
| 15:14.51 |
``Erik |
'r
sumfin |
| 15:15.52 |
``Erik |
my current
approach is destructive... facetize all and some external prep to
kill/mv the bots in under the existing regions |
| 15:16.56 |
``Erik |
(and I
already feel like I've thought too much, this is a yak shaving
exercize to support something else) |
| 15:17.02 |
``Erik |
:D |
| 15:17.26 |
brlcad |
what's the _f
and _r above the region level mean? |
| 15:17.53 |
``Erik |
_f to denote
facetized |
| 15:18.29 |
``Erik |
I want to
create a second toplevel tree that mirrors the original except all
regions contain exactly one bot |
| 15:18.47 |
``Erik |
the name
mangling is arbitrary |
| 15:19.09 |
mafm |
how's gsoc,
did students pass? |
| 15:19.48 |
``Erik |
I think we
need to wait for wrapup to say, mafm? |
| 15:20.48 |
mafm |
aren't
evaluations finished yet? |
| 15:21.07 |
``Erik |
they're all
submitted now, but I think there's magic that has to happen on
googles end |
| 15:22.01 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 15:53.01 |
CIA-28 |
BRL-CAD:
03starseeker * r35717
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Start
checking validity of components. |
| 16:00.25 |
brlcad |
starseeker:
jdoliner: did either of you figure out if there's a conversion to
go from ON_Mesh to ON_Brep ? |
| 16:01.27 |
brlcad |
if there is,
nmgs may translate nearly 1-1 with an ON_Mesh |
| 16:06.53 |
mafm |
oh,
right |
| 16:09.17 |
Yoshi47 |
umm whats the
easiest way to make "608Z" in brlcad so i can groove that into the
shield |
| 16:29.03 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 16:29.31 |
FAMULUS |
hello! |
| 16:29.55 |
Yoshi47 |
hi |
| 16:29.58 |
FAMULUS |
I've produced
this beautiful part in BRL CAD |
| 16:30.14 |
FAMULUS |
but having
difficult getting it made from STL |
| 16:30.19 |
FAMULUS |
overlapping
trianges |
| 16:30.20 |
FAMULUS |
http://prometheusfusionperfection.com/2009/08/21/overlapping-triangles-in-stl/ |
| 16:30.40 |
FAMULUS |
looking for
direction |
| 16:30.41 |
FAMULUS |
http://prometheusfusionperfection.com/2009/08/23/new-stl-for-superconducting-magrid/ |
| 16:32.06 |
FAMULUS |
even at
higher resolution is still has overlapping triangles |
| 16:33.17 |
Yoshi47 |
sorry i don't
have enough knowledge to help you |
| 16:33.33 |
louipc |
that's cool.
what does it do? |
| 16:34.09 |
brlcad |
hi
FAMULUS |
| 16:34.12 |
FAMULUS |
hi |
| 16:34.14 |
louipc |
hmm bussard
reactor |
| 16:34.26 |
FAMULUS |
louipc: this
will be the core of a nuclear fusion reactor |
| 16:34.27 |
brlcad |
Yoshi47: the
easiest way is probably an EBM |
| 16:34.31 |
brlcad |
extruded
bitmap |
| 16:34.33 |
louipc |
OH
JEEZ |
| 16:34.42 |
louipc |
we have
fusion technology now? |
| 16:34.58 |
FAMULUS |
louipc: below
breakeven yes |
| 16:35.07 |
louipc |
aw |
| 16:35.12 |
Yoshi47 |
brlcad, thats
what i figured, guess i got to learn that process. |
| 16:35.34 |
brlcad |
get out your
favorite image editor, make a 1-bit image with 608Z in it to your
liking, save as png, convert to bw with png-bw, create an ebm using
that bw image |
| 16:35.46 |
brlcad |
'in' command
will prompt you |
| 16:35.53 |
brlcad |
i believe
there is an ebm tutorial on the wiki |
| 16:36.48 |
FAMULUS |
brlcad:
looking into it |
| 16:36.59 |
FAMULUS |
brlcad:
what's the deal with g-stl anyway |
| 16:37.43 |
Yoshi47 |
brlcad,
thanks |
| 16:37.51 |
brlcad |
other than it
being an NP-hard problem? :) |
| 16:38.10 |
FAMULUS |
brlcad: oh,
it's like that |
| 16:39.01 |
louipc |
iges
conversion isn't any better eh? |
| 16:39.47 |
brlcad |
FAMULUS: what
mike suggested was what I was thinking as well |
| 16:40.00 |
brlcad |
the fact that
they are overlapping is pretty surprising though |
| 16:40.10 |
brlcad |
does your
model validate overlap-wise? |
| 16:40.22 |
brlcad |
(rtcheck/gqa) |
| 16:40.35 |
brlcad |
if it
doesn't, it's a modeling error and you should fix that
first |
| 16:40.39 |
FAMULUS |
brlcad:
seeing I don't know what that means exactly, probably
not |
| 16:40.57 |
brlcad |
there are
tools/commands to check whether your model has overlaps |
| 16:41.12 |
brlcad |
to perform a
valid export with g-stl, there should be no overlaps |
| 16:41.20 |
brlcad |
*before* the
tessellation even begins |
| 16:41.38 |
FAMULUS |
brlcad: I
see, let me start here |
| 16:41.43 |
brlcad |
you can get a
quick idea by just running "rtcheck" |
| 16:41.45 |
brlcad |
in
mged |
| 16:41.49 |
FAMULUS |
ok |
| 16:42.21 |
brlcad |
the better
way is via the gqa command or g_qa command-line tool, but that'll
require a little setup first |
| 16:42.55 |
brlcad |
if rtcheck
reports no overlaps, try refining the grid (e.g., rtcheck
-s2000) |
| 16:43.02 |
FAMULUS |
_dirbuild(chassis) failure |
| 16:45.56 |
FAMULUS |
he process
has forked and you cannot use this CoreFoundation functionality
safely. You MUST exec(). |
| 16:45.56 |
FAMULUS |
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug. |
| 16:46.20 |
FAMULUS |
hmm, ive seen
this before |
| 16:46.23 |
brlcad |
yeah, that's
a known 10.5 issue |
| 16:46.29 |
brlcad |
fixed for
most things, but not others |
| 16:46.51 |
FAMULUS |
I think to
get around this I have to issue command from terminal |
| 16:49.08 |
brlcad |
yeah, that'll
work |
| 16:49.23 |
brlcad |
rtcheck
your.g someobject |
| 16:49.35 |
FAMULUS |
hmm, not this
time |
| 16:49.37 |
FAMULUS |
mged -c
decawell.g rtcheck torus1 |
| 16:49.47 |
FAMULUS |
same
error |
| 16:49.54 |
FAMULUS |
bummer |
| 16:49.57 |
brlcad |
right, don't
run mged |
| 16:50.12 |
brlcad |
it's one of
the other 399 commands |
| 16:50.21 |
brlcad |
rtcheck
decawell.g torus1 |
| 16:50.36 |
brlcad |
if torus1 is
a primitive, there will be no overlaps |
| 16:50.45 |
brlcad |
overlaps have
to do with defined region objects |
| 16:50.59 |
FAMULUS |
right, but
thats a sanity check |
| 16:51.09 |
FAMULUS |
just trying
to get the command to work |
| 16:51.36 |
FAMULUS |
I'm on
BRL-CAD Release 7.12.2 |
| 16:51.46 |
brlcad |
that's
probably why you get the FORKED error |
| 16:52.09 |
FAMULUS |
ok, I'll
upgrade to 7.12.6 |
| 16:52.13 |
brlcad |
"probably"
because I don't recall specifically testing rtcheck, but a bunch
were quelled |
| 16:52.23 |
brlcad |
you'll want
7.14.8 |
| 16:52.29 |
FAMULUS |
oh |
| 16:52.31 |
FAMULUS |
thanks |
| 16:52.57 |
FAMULUS |
good to see
BRL under active development |
| 16:53.11 |
brlcad |
or better,
latest svn and just compile it ;) |
| 16:53.19 |
brlcad |
you're on a
mac, so you have everything you need |
| 16:53.34 |
brlcad |
~cadsvn |
| 16:53.35 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 16:53.58 |
FAMULUS |
brlcad: ok,
I'll try. |
| 16:54.15 |
brlcad |
cd brlcad
&& sh autogen.sh && ./configure --enable-all
--enable-optimized --prefix=/usr/brlcad/dev-7.14.9 && make
&& sudo make install |
| 16:54.21 |
brlcad |
that should
do it |
| 16:54.27 |
FAMULUS |
brlcad:
trying.... |
| 16:54.58 |
*** join/#brlcad DarX
(n=DarX@0x535ca99c.rdnxx6.dynamic.dsl.tele.dk) |
| 16:55.13 |
brlcad |
Yoshi47: you
find the ebm overview? |
| 16:55.27 |
Yoshi47 |
havebn't had
time users nagging |
| 16:55.40 |
brlcad |
okay, it's
here: http://brlcad.org/wiki/EBM |
| 16:55.45 |
Yoshi47 |
ok
thanks |
| 16:56.22 |
brlcad |
you'll want
something bigger than 350x35 so there are minimized
jaggies |
| 17:00.17 |
FAMULUS |
brlcad:
what's a good example of overlap in the context of BRL
CAD |
| 17:00.42 |
brlcad |
what do you
mean? |
| 17:01.14 |
brlcad |
overlap means
you've defined two objects such that they're occupying the same
space |
| 17:01.54 |
FAMULUS |
brlcad: hmm,
but that's ok when they are u together |
| 17:02.13 |
brlcad |
two hammers
criss-crossed would be an overlap on the middle region where they
cross |
| 17:02.38 |
FAMULUS |
but if you
combined the 2 hammers into 1 comb object you would be
ok |
| 17:02.50 |
brlcad |
and that
would be because I defined the hammer, as an example, as having two
regions -- one for the steel head and one region for the wooden
handle |
| 17:03.12 |
brlcad |
creating a
region is the way that you denote an object physically occupies
space |
| 17:03.33 |
brlcad |
the
difference between the shape of a hammer handle and an actual
wooden hammer handle |
| 17:03.51 |
FAMULUS |
right |
| 17:03.56 |
brlcad |
and NO you
would not be okay if you combined the 2 hammers into 1 comb
object |
| 17:04.03 |
brlcad |
that's
exactly the problem |
| 17:04.07 |
FAMULUS |
ah |
| 17:04.08 |
FAMULUS |
comb chassis
u solid.c - negative_form.c |
| 17:04.20 |
FAMULUS |
I'm using
only comb |
| 17:04.32 |
brlcad |
now if you
combined the shape of the two handles together and unioned them
together *before* making a region .. you'd be okay |
| 17:05.09 |
brlcad |
have you
created any "regions" |
| 17:05.21 |
FAMULUS |
brlcad: funny
I stopped using regions because that was breaking STL
export |
| 17:05.43 |
FAMULUS |
http://prometheusfusionperfection.com/2009/05/30/brl-cad-stl-progress/ |
| 17:05.51 |
brlcad |
a region is
one "object" and the stl file format only supports one
object |
| 17:05.59 |
brlcad |
so if you
have multiple regions, you have multiple stl files or a
problem |
| 17:06.11 |
FAMULUS |
ok |
| 17:06.30 |
brlcad |
you could
combine it all together and make that combined thing be a
region |
| 17:06.46 |
FAMULUS |
ok |
| 17:08.54 |
FAMULUS |
checking
docs |
| 17:14.58 |
``Erik |
*burp* |
| 17:24.20 |
FAMULUS |
brlcad: we'll
I just successfully exported to STL with a region as the last
object standing |
| 17:33.01 |
FAMULUS |
brlcad: so
you can make a region out of a compination, and make a combination
out of a region? |
| 17:49.36 |
``Erik |
yes |
| 17:49.50 |
``Erik |
a region is
actually just a combination with a flag set |
| 17:50.47 |
``Erik |
above the
region level, things like "assembly" make it harder to shoot
yourself in the foot, though |
| 17:52.51 |
FAMULUS |
``Erik: is
there a difference between a region made up of combinations, and a
region made up of regions |
| 17:54.34 |
``Erik |
it...
depends, and having a region somewhere inside of a region kinda
breaks the notion... (a region refers to a single physical
homogenous material thing, something that exists irl) |
| 17:55.49 |
``Erik |
most things
will walk down the tree and once they see the region bit, assume
everything below is just 'the shape', so region information below
the first is ignored |
| 17:55.50 |
``Erik |
(I
think) |
| 18:02.51 |
starseeker |
brlcad: I
don't see any ON_Mesh to ON_Brep tools |
| 18:03.08 |
starseeker |
would have
been surprised given Rhino is a nurbs modeler :-) |
| 18:10.28 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 18:16.08 |
brlcad |
starseeker:
could be something as simple as a copy constructor |
| 18:16.37 |
brlcad |
i'd actually
be surprised if they don't support it within rhino |
| 18:16.49 |
brlcad |
easily one of
the things they could have removed though |
| 18:19.54 |
starseeker |
feels like he is getting close |
| 18:20.04 |
starseeker |
famous last
words, of course... |
| 18:21.20 |
Yoshi47 |
who wants a
bearing with a shield? although i can't figure out why my numbers
don't render nicely... |
| 18:23.24 |
``Erik |
hm, my new
bsd machine swings in just shy of 8k vgr's |
| 18:24.18 |
``Erik |
I'm sure my
crusty old mac still trounces that :/ *waits* |
| 18:25.10 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 18:28.02 |
``Erik |
oh yeah, the
bsd machine gets 7946, the mac gets 22733 |
| 18:28.26 |
``Erik |
too bad the
mach shandler crud makes the unix tools soooo ssssllllooooowwwwww,
can compile way faster on the bsd box |
| 18:33.52 |
*** join/#brlcad samrose
(n=samrose@c-24-56-194-141.customer.broadstripe.net) |
| 18:35.36 |
Yoshi47 |
http://ej.nijenhuis.pixi.me/v/CAD/bearing_g.html
here the finished bearing for now, unless i need to make changes,
like the 608Z |
| 18:49.04 |
CIA-28 |
BRL-CAD:
0387.206.145.226 07http://brlcad.org * r1608
10/wiki/User:526_buy_viagra: /* */ |
| 18:49.39 |
brlcad |
FAMULUS: what
erik said is spot on |
| 18:49.52 |
brlcad |
a region in a
region is a modeling error unless it's a region subtracted from a
region |
| 18:50.19 |
brlcad |
above the
region level, and you have what we call "groups" and others call
assemblies |
| 18:50.35 |
brlcad |
at the region
level, that's effectively a 'part' |
| 18:50.43 |
CIA-28 |
BRL-CAD:
0387.206.145.226 07http://brlcad.org * r1609
10/wiki/User:526_buy_viagra: /* */ |
| 18:50.45 |
brlcad |
below the
region level is just a shape |
| 18:51.42 |
CIA-28 |
BRL-CAD:
0387.206.145.226 07http://brlcad.org * r1610
10/wiki/User:526_buy_viagra: /* */ |
| 18:52.33 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:87.206.145.226]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
| 18:56.06 |
CIA-28 |
BRL-CAD:
0383.24.64.144 07http://brlcad.org
* r1611 10/wiki/User:526_buy_viagra: fix |
| 19:02.38 |
FAMULUS |
brlcad: so
far it seems to be working. maybe my problem was originally I had
regions in regions |
| 19:04.37 |
CIA-28 |
BRL-CAD:
03starseeker * r35718
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Checkpoint
nmg_brep.cpp work. |
| 19:40.16 |
``Erik |
laptop weighs
in at 6097 vgr's |
| 19:48.04 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35719
10/brlcad/trunk/src/librt/primitives/bot/bot.c: fix type in
casting |
| 19:53.53 |
Ralith |
``Erik: machs
handler? |
| 19:58.07 |
brlcad |
cool, nice to
hear things work right when you feed it valid geometry |
| 19:58.45 |
brlcad |
``Erik: what
is that? |
| 19:58.56 |
brlcad |
slightly
faster than this old MBP |
| 19:59.22 |
brlcad |
here's
yoshi's impeller render.. amazing. http://brlcad.org/tmp/impeller.png |
| 20:01.44 |
``Erik |
ralith: every
system call on osX goes through the mach event handler,
shandler() |
| 20:02.06 |
Ralith |
seems
odd |
| 20:02.23 |
Ralith |
might make it
really easy to implement a geordi though |
| 20:02.27 |
Ralith |
brlcad: ooh,
nice! |
| 20:02.36 |
brlcad |
laforge? |
| 20:02.46 |
Ralith |
brlcad:
geordi of ##c++ |
| 20:03.24 |
Ralith |
C++ compiler
IRC bot |
| 20:03.24 |
``Erik |
wow, look at
all that aliasing O.o *duck* |
| 20:03.24 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35720 10/brlcad/trunk/src/ (19 files in 19
dirs): update info for "make depends" |
| 20:03.26 |
louipc |
sweet
render |
| 20:03.33 |
brlcad |
that was H15
J3 .. but you have to downsample to get rid of all aliasing
properly |
| 20:03.56 |
Ralith |
it has to
intercept all system calls from the compiler and executable to be
able to function safely |
| 20:04.13 |
Ralith |
brlcad: might
be a bit easy to actually tell what's going on if it wasn't glass
though >_> |
| 20:04.18 |
``Erik |
huh, the
blades on the other side of it look like they have some pretty
heavy aliasing vs the background |
| 20:04.26 |
``Erik |
*shrug* |
| 20:04.57 |
brlcad |
yeah, edge
pixels are accented because they don't blend the background like
interior ones |
| 20:05.25 |
brlcad |
probably
should, dunno where that bit of code is |
| 20:06.10 |
Ralith |
how long has
yoshi been studying mged? |
| 20:06.11 |
``Erik |
ooh, I bet
it's "miss" short-circuiting instead of passing back the background
color |
| 20:06.57 |
``Erik |
so a black
half or arb8 would get good blending |
| 20:07.24 |
brlcad |
Ralith: that
was his third day iirc |
| 20:07.40 |
Ralith |
that's pretty
impressive |
| 20:07.52 |
brlcad |
did one model
in three days, that model in a couple hours, redid the model that
took him three days in an hour after he accidentally deleted it
:) |
| 20:07.56 |
Ralith |
shall keep this handy to wave at people who complain about
accessibility |
| 20:09.26 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 20:11.46 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 20:13.08 |
brlcad |
Yoshi47:
http://brlcad.org/tmp/impeller.png |
| 20:13.20 |
brlcad |
i'll see if i
can get a render later in metal :) |
| 20:13.26 |
brlcad |
which reminds
me.. |
| 20:16.09 |
CIA-28 |
BRL-CAD:
03brlcad * r35721 10/brlcad/trunk/TODO: how about adding a shiny
metal shader so one doesn't have to make up the values every
time. |
| 20:16.23 |
Ralith |
Yoshi47: if
you feel like it, I'd be pretty interested to read a walkthrough of
how you modeled that. |
| 20:16.43 |
Ralith |
observes that a variety of modeling walkthroughs might be a
good way to introduce new users to mged |
| 20:16.58 |
louipc |
it doesn't
look so nice in mged |
| 20:17.04 |
louipc |
it's just a
mess-o-lines |
| 20:17.57 |
louipc |
it'd be great
to get a wireframe of the actual part edges |
| 20:18.05 |
louipc |
Ralith: yeah
for sure |
| 20:20.17 |
brlcad |
louipc: yeah,
were talking about that yesterday |
| 20:20.31 |
brlcad |
the problem
is that there aren't "actual part edges" when you model with
implicits and CSG |
| 20:21.42 |
brlcad |
as we become
a fully hybrid representation system, we'll be able to
derive/evaluate those edges .. that requires the NURBS work being
complete (which is probably about 50% now after two
years) |
| 20:23.20 |
``Erik |
louipc:
facetize :D |
| 20:23.55 |
``Erik |
cribbing
povrays huge honkin' library of .inc files might be useful for the
'shiney metal shader' notion |
| 20:26.35 |
CIA-28 |
BRL-CAD:
03starseeker * r35722
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: well, at
least that's a different nmg->brep invalidity
error... |
| 20:26.56 |
louipc |
hmm
true |
| 20:35.04 |
*** join/#brlcad samrose
(n=samrose@c-24-56-194-141.customer.broadstripe.net) [NETSPLIT
VICTIM] |
| 20:38.08 |
*** join/#brlcad mafm_
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 21:00.12 |
CIA-28 |
BRL-CAD:
03irpguardian * r35723
10/brlcad/trunk/src/libged/human.c: |
| 21:00.12 |
CIA-28 |
BRL-CAD: Made
the make-army command generate an army with variance in
height. |
| 21:00.12 |
CIA-28 |
BRL-CAD:
Heights from 56 inches to 66 inches currently. Automatic with the
-N# command. |
| 22:06.29 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 22:07.10 |
CIA-28 |
BRL-CAD:
03irpguardian * r35724 10/brlcad/trunk/src/libged/human.c: More
tweaks to random army stuff. |
| 22:07.46 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 22:38.35 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 23:04.20 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 23:34.21 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 02:16.10 |
Yoshi47 |
<PROTECTED> |
| 02:16.22 |
Ralith |
Yoshi47:
step-by-step description of what you did |
| 02:17.01 |
Ralith |
basically, a
writeup such that a complete newbie could reproduce your model,
with enough explanation that one would learn a lot doing
so. |
| 02:17.04 |
Ralith |
brb |
| 02:17.40 |
Yoshi47 |
umm, that
would take a while to write up and who knows if it did it correct
and the best way |
| 02:18.19 |
Yoshi47 |
what would
would be an excellent tool for tutorials, the ability to extract
the command used to create each object! |
| 02:18.47 |
Ralith |
it would
indeed take some effort, but it would be very interesting to
read. |
| 02:19.04 |
Ralith |
and if it's
written up other people can suggest more 'correct' ways
:P |
| 02:19.09 |
Ralith |
that way you
get to learn too ^^ |
| 02:19.16 |
Yoshi47 |
true |
| 02:19.40 |
Ralith |
and writing
out what you did and why you did it for each step might in and of
itself help you. |
| 02:19.51 |
Yoshi47 |
well i think
about it and work at that slowy, you are talking about the impeller
right? it will take some time i got lots going on, but i'll give it
a shot... |
| 02:19.53 |
Ralith |
'course, lots
of work and probably not as helpful as just modeling more random
stuff. |
| 02:20.00 |
Ralith |
yeah, the
impeller |
| 02:20.03 |
Yoshi47 |
ok |
| 02:20.23 |
Yoshi47 |
well, i'' try
in my spare moments, good review for me thats for sure! |
| 02:20.33 |
Ralith |
no rush; just
an idea. |
| 02:20.54 |
Yoshi47 |
Ralith, nope,
but a good idea, i'll get her done, need more
tutorials. |
| 02:21.21 |
Ralith |
:) |
| 02:21.41 |
Yoshi47 |
i wish i had
a clone... |
| 02:22.29 |
Yoshi47 |
well im of to
bed, cya guys later! |
| 02:23.19 |
Yoshi47 |
man that
impeller looks nice in glass, i hope brlcad started a chrome
render |
| 02:24.06 |
Yoshi47 |
bye |
| 02:24.37 |
Ralith |
nite! |
| 02:31.46 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 03:32.29 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 03:47.45 |
starseeker |
hmm - I think
I found the perfect starting point for populating a default
material objects list :-) http://www.dlis.dla.mil/PDFs/fiigmat.pdf |
| 03:48.31 |
starseeker |
wonders if that sucker can be parsed
somehow... |
| 04:15.31 |
louipc |
sure why
not? |
| 05:09.57 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 06:56.53 |
*** join/#brlcad talcite_
(n=matthew@69-196-180-192.dsl.teksavvy.com) |
| 08:33.16 |
*** join/#brlcad cosurgi
(n=cosurgi@153.19.34.234) |
| 10:57.51 |
*** join/#brlcad Yoshi47
(n=jan@firewall.walinga.com) |
| 11:50.22 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 11:50.48 |
*** join/#brlcad docelic
(n=docelic@78.134.201.180) |
| 12:05.00 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 12:20.51 |
starseeker |
wonders how many man hours all of this represents: http://www.dlis.dla.mil/fiigdata/fiigs.htm |
| 12:21.49 |
d-lo |
lol |
| 12:21.54 |
d-lo |
probably
don't want to know. |
| 12:22.04 |
d-lo |
but here's my
favorite: A511W 02/01/2001 JUICE, GRAPE, SACRAMENTAL |
| 12:22.50 |
starseeker |
LOL |
| 12:29.45 |
louipc |
HAHHA |
| 12:36.20 |
Yoshi47 |
starseeker,
whats that web page for? |
| 12:40.05 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 12:43.44 |
``Erik |
heh |
| 12:44.27 |
``Erik |
looks like
item #'s and descriptions for military shipping&supply
logistics crud |
| 12:51.32 |
Yoshi47 |
yeah, i was
hoping for g DB of the parts! lol |
| 12:59.52 |
``Erik |
grouses at gtk+ |
| 13:05.02 |
Yoshi47 |
``Erik, whys
that |
| 13:05.42 |
CIA-28 |
BRL-CAD:
03irpguardian * r35725 10/brlcad/trunk/src/libged/human.c: Fixed
bug where '-n' command didn't properly rename toplevel
combination. |
| 13:10.57 |
Yoshi47 |
well i think
its time for this question, how does one go about creating a screw?
i there a nice tutorial available? |
| 13:12.31 |
louipc |
there are
some programs that do it |
| 13:13.44 |
louipc |
heh
bolt... |
| 13:14.17 |
Yoshi47 |
but brl not
capable directly? at least no iuntil NURBS done... |
| 13:15.24 |
louipc |
I think bolt
is broken... it froze on me |
| 13:15.49 |
louipc |
Yoshi47: you
mean via mged? |
| 13:15.58 |
Yoshi47 |
ya |
| 13:16.00 |
Yoshi47 |
sorry |
| 13:17.02 |
louipc |
I would
assume it's possible if the program could do it |
| 13:18.18 |
``Erik |
Yoshi47:
dialog box return code isn't being set, and I'm not sure
why |
| 13:19.00 |
Yoshi47 |
umm |
| 13:20.36 |
``Erik |
(isst uses
gtk+ at the moment) |
| 13:21.00 |
louipc |
hrm bolt is
tremendously broken for me :/ |
| 13:21.05 |
Yoshi47 |
wouldn't know
what isst is? |
| 13:21.56 |
``Erik |
side project
that mostly lives in brlcad (as libtie/adrt) with a gui component
outside of the main tree... interactive ray tracing, um, the
picture of the stryker in our gallery was done using it |
| 13:24.33 |
louipc |
Yoshi47:
anyways... the ronja guy made some. I'm not sure how he did
them |
| 13:24.36 |
louipc |
http://ronja.twibright.com/3d/hardware.php |
| 13:24.43 |
louipc |
you may want
to ask him |
| 13:25.43 |
``Erik |
lookhis .g
file is on that page |
| 13:27.09 |
louipc |
doesn't say
much about the method though :/ |
| 13:27.19 |
``Erik |
ehhhhh,
buttloads of tgc's |
| 13:30.09 |
Yoshi47 |
louipc, or i
just download the master.g and then analyze |
| 13:34.11 |
Yoshi47 |
i see how he
did it, man thats alot to figure out. |
| 13:35.30 |
``Erik |
how accurate
do ya want your bolts? :D |
| 13:37.29 |
Yoshi47 |
``Erik, i
don't think they have to be that accurate allthough it would be
nice, just a question. talking to my peer here and he say that in
PRo/e they just create on thread and then revolve it around an
axis. |
| 13:37.42 |
Yoshi47 |
is there
revolve command? |
| 13:37.44 |
starseeker |
did a threading test with pipe once actually - that worked
pretty well |
| 13:37.47 |
``Erik |
yeah, we had
a summer student working on that, it's not done |
| 13:38.12 |
Yoshi47 |
i thought
there was, umm |
| 13:38.19 |
Yoshi47 |
have to think
this one through... |
| 13:38.32 |
``Erik |
would probably make a little script with some kinda tor or
ell assembly to make a bolt *shrug* |
| 13:38.42 |
Yoshi47 |
maybe have to
use hex since most of my bolts will be metric |
| 13:39.08 |
louipc |
yeah properly
shaped threads would be mint |
| 13:39.14 |
``Erik |
(depending on
scale, I might just call 2 rcc's a bolt and move on) |
| 13:39.15 |
d-lo |
Cyl +
Starseekers Spring command for the threads + 2 arb8's. BAM!
Bolt. |
| 13:39.28 |
Yoshi47 |
``Erik, ya
might just have to for now, |
| 13:39.39 |
``Erik |
or an rcc and
2 arb8's |
| 13:39.46 |
CIA-28 |
BRL-CAD:
03starseeker * r35726
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Er, oops -
better refer to the actual surface index, not the
count... |
| 13:39.47 |
``Erik |
depending on
the head :) |
| 13:40.02 |
d-lo |
either way...
simple :) |
| 13:40.05 |
Yoshi47 |
some are flat
head with hex drive |
| 13:40.23 |
d-lo |
probably
spent more time on the irc channel than it would have taken to whip
up a bolt :) |
| 13:40.36 |
Yoshi47 |
not if you
don't know how to do it |
| 13:40.59 |
``Erik |
ya know how
to make rcc's and arb8's, right? :D (gotta choose your
fidelity) |
| 13:41.18 |
Yoshi47 |
wheres this
spring command? |
| 13:41.22 |
Yoshi47 |
ya |
| 13:41.50 |
``Erik |
(also; you
can make the bolt 'ghetto', then come back to it later when ya know
more or have time to commit to it) |
| 13:42.21 |
d-lo |
just make
each arb8 into a trapezoid and then glue the long faces together to
make the 6 sided bolt head. Glue in the rcc to the bottom and
subtract whatever you need to out of the head (Allen, Flat,
Philips, Star, etc) |
| 13:42.54 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 13:42.59 |
``Erik |
combinations
refer to names, not instances, so you can have a bolt used in
thousands of combinations, make your improved bolt, kill the old
bolt and move the new one in place and it automatically appears
everywhere |
| 13:43.11 |
``Erik |
so, y'know,
ain't no use sweating it just yet :D |
| 13:43.18 |
Yoshi47 |
true |
| 13:43.52 |
Yoshi47 |
but it is a
good lesson, sinc ei also need to make a acme screw, or ball screw
haven't decided yet |
| 13:44.55 |
louipc |
I don't think
acme is possible |
| 13:45.25 |
Yoshi47 |
should be not
any more complicated then a screw |
| 13:45.39 |
Yoshi47 |
maybe im
mistaken |
| 13:45.57 |
Yoshi47 |
this spring
comand that d-lo is taking about should be able to do
that |
| 13:46.30 |
Yoshi47 |
which brings
up the question that got lost, where is this spring
command? |
| 13:47.37 |
louipc |
hmm not
sure |
| 13:48.04 |
louipc |
I don't think
you can define the shape of the spring though.. |
| 13:48.18 |
louipc |
well in terms
of the spring wire itself |
| 13:49.18 |
Yoshi47 |
hmm |
| 13:51.42 |
Yoshi47 |
did the army
use another cad program back in the 70s to draw screws? how did
they do it? |
| 13:53.24 |
louipc |
oh right it's
renamed to coil |
| 13:54.11 |
louipc |
heh they
probably didn't |
| 13:54.25 |
louipc |
at least with
brl-cad :P |
| 13:55.17 |
Yoshi47 |
umm |
| 13:57.11 |
Yoshi47 |
that renders
nicely, no can we specify more options, time to look at the
docs... |
| 14:04.35 |
Yoshi47 |
starseeker,
you here? |
| 14:15.10 |
CIA-28 |
BRL-CAD:
03bob1961 * r35727
10/brlcad/trunk/src/external/ProEngineer/proe-brl.c: Update to
always create a Proe_Name attribute for each BRL-CAD object created
(except for top). |
| 14:18.20 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 14:22.01 |
brlcad |
hm, that is
an interesting idea about storing the actual command history
involved in manipulating an object |
| 14:22.25 |
louipc |
autocad does
that actually |
| 14:22.37 |
brlcad |
arguably
something that could be managed through libged, have to think about
that some |
| 14:23.11 |
louipc |
unlimited
undo :D |
| 14:26.25 |
brlcad |
revolve is
finished enough for that use, ray-tracing certainly works -- but
don't think tessellation was implemented yet (meaning you couldn't
export it to stl) |
| 14:27.59 |
brlcad |
Yoshi47: in
the 70's most everything was done by hand on paper |
| 14:28.23 |
Yoshi47 |
oh so
basically the army just didn't do screws in brlcad |
| 14:28.40 |
brlcad |
louipc: not
so much for undo purposes, but to be able to reconstruct or step
through the construction history |
| 14:28.54 |
brlcad |
but yeah, you
could then undo |
| 14:29.14 |
brlcad |
Yoshi47:
brl-cad started circa 1979, first "release" in 1984 |
| 14:29.35 |
brlcad |
you're
talking about very early days of computing and computer
graphics |
| 14:29.45 |
brlcad |
there were no
cad systems yet |
| 14:30.14 |
Yoshi47 |
ah miss read
the gallery picutre of Mike Muuss |
| 14:30.17 |
brlcad |
the
"computers" of the day had very limited input and display
capabilities |
| 14:30.35 |
Yoshi47 |
so revolve is
brl-cad command or mged |
| 14:31.18 |
Yoshi47 |
or not even
released yet? |
| 14:32.12 |
brlcad |
one of the
first uses for brl-cad was to visualize what eventually became the
M1 tank, mike was basically challenged that it wasn't possible, he
showed them in a couple days that it was |
| 14:32.34 |
brlcad |
that was
actually the *first* time anyone had ever seen the entire vehicle
"put together" |
| 14:32.48 |
Yoshi47 |
cool |
| 14:32.49 |
brlcad |
generals flew
in from the pentagon to see it |
| 14:33.10 |
brlcad |
revolve is a
primitive, like extrude |
| 14:33.24 |
brlcad |
takes a
sketch |
| 14:33.36 |
brlcad |
and a
rotation angle |
| 14:33.58 |
Yoshi47 |
any docs on
it? or is that it? |
| 14:34.17 |
brlcad |
so you could
fairly easily contour a threading in 2d, import as a sketch, then
revolve that around just like in proe |
| 14:34.40 |
Yoshi47 |
cool |
| 14:34.48 |
brlcad |
depending on
what you need it for, it's not going to be too useful to you if you
need to export the model |
| 14:34.51 |
Yoshi47 |
i think i
need to learn more about sketches |
| 14:35.01 |
brlcad |
because it
can't be tessellated yet (turned into polygons) |
| 14:35.02 |
Yoshi47 |
brlcad, don't
need to export |
| 14:36.00 |
brlcad |
this is the
only docs really, dev docs http://brlcad.org/wiki/Revolve_Primitive |
| 14:37.59 |
brlcad |
best start is
to probably create a sketch, then extrude it .. make sure you
understand that process -- revolving then is not really any
different than extruding |
| 14:38.26 |
brlcad |
creating/importing a scetch is the more
painful part as that's a 2d centric modeling approach, which is not
our forte |
| 14:38.33 |
brlcad |
and generally
discouraged.. |
| 14:38.50 |
brlcad |
starseeker's
coil tool is a better approach |
| 14:39.25 |
brlcad |
that will
give you a whole range of threading types as a subtraction
primitive |
| 14:39.58 |
Yoshi47 |
i need more
docs on coil |
| 14:40.34 |
brlcad |
more
docs? |
| 14:40.34 |
brlcad |
it has a
manual page |
| 14:40.34 |
Yoshi47 |
umm i
tried |
| 14:40.42 |
Yoshi47 |
didn't work,
i'll try again |
| 14:40.46 |
brlcad |
and the
developer for it sits in here, better than docs ;) |
| 14:40.56 |
Yoshi47 |
ya he not
answering |
| 14:41.05 |
brlcad |
patience
;) |
| 14:41.10 |
Yoshi47 |
yep |
| 14:42.00 |
Yoshi47 |
so where is
the best place to learn about sketches? |
| 14:48.32 |
brlcad |
like i said,
that part is thin (in all respects) because it's not our way
.. |
| 14:48.42 |
brlcad |
there are
docs somewhere, but I don't really remember where |
| 14:49.13 |
brlcad |
just because
that method isn't a priority/interest/concern, at all .. we mostly
deal with sketch objects on import, like from a dxf |
| 14:49.21 |
brlcad |
there is a
sketch editor |
| 14:49.39 |
brlcad |
if you create
a sketch through the gui, and edit that sketch, you'll be in the
sketch editor |
| 14:50.09 |
brlcad |
horrible
interface, but it gives you basic edit controls for adding line
segments, arcs, circles, whatever to your sketch |
| 14:50.55 |
brlcad |
there are
docs that teach one how to do what the coil does manually in Vol
III, advanced techniques |
| 14:51.17 |
brlcad |
there is a
coil antenna there that teaches how to use the pipe primitive that
is relevant |
| 14:51.59 |
brlcad |
the pipe
primitive is pretty powerful in itself, another example of a
semisteep learning curve but with a high(er) payoff compared to
other cad systems |
| 14:53.31 |
Yoshi47 |
cool, i'll
take a look at those today then, thanks |
| 14:55.58 |
Yoshi47 |
do you have a
link to Vol III, advanced techniques |
| 14:56.02 |
Yoshi47 |
can't seem to
find it |
| 15:06.56 |
brlcad |
vol II is the
massive mged tutorial series |
| 15:07.04 |
brlcad |
vol III is at
the same place |
| 15:07.21 |
brlcad |
should go
down that list and familiarize, they're good docs ;) |
| 15:09.15 |
Yoshi47 |
oh its called
Principles of Effective Modeling |
| 15:17.52 |
brlcad |
yeah, sorry,
that's our internal name for it |
| 15:18.20 |
brlcad |
well, not
"internal" .. it was the third "book" when we printed them
:) |
| 15:20.19 |
Yoshi47 |
oh, |
| 15:32.12 |
louipc |
starseeker:
is there a reason doc/book/VolumeIV.xml is separate from
doc/docbook/books |
| 15:46.33 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 16:00.24 |
*** join/#brlcad h4r1
(n=dbs@115.240.108.36) |
| 16:26.26 |
Yoshi47 |
when you
concat 2 dbs together if there is the same names in both, how does
that work? |
| 16:32.40 |
louipc |
The man page
says it will add computer generated prefixes |
| 16:33.14 |
louipc |
but won't
rename members of combinations... |
| 16:37.53 |
Yoshi47 |
umm so then
any combs will not work.. |
| 17:01.09 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) |
| 17:54.17 |
``Erik |
revolve works
now? |
| 17:54.56 |
``Erik |
*readreadread* |
| 17:58.13 |
brlcad |
yeah, it
works |
| 17:58.24 |
``Erik |
sans
_tess |
| 17:58.55 |
``Erik |
marching
cubes is gonna shake things up a bit, methinks |
| 17:59.00 |
brlcad |
yeah, and
maybe a few other callbacks that would be nice to have, but it is
enough to read/write them from the db, basic plot, and raytracing
works |
| 17:59.53 |
brlcad |
dbconcat has
options |
| 18:02.10 |
brlcad |
looks like
the manual page is a little out of date |
| 18:46.54 |
``Erik |
oi |
| 18:52.09 |
brlcad |
vey |
| 19:01.05 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) |
| 19:05.52 |
CIA-28 |
BRL-CAD:
03brlcad * r35728 10/brlcad/trunk/configure.ac: minor typo, missing
> |
| 19:13.54 |
CIA-28 |
BRL-CAD:
03irpguardian * r35729 10/brlcad/trunk/src/libged/human.c: Fixed a
problem when reading in a Verbose.txt file and not properly
updating some variables. |
| 19:28.42 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 19:50.46 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) [NETSPLIT
VICTIM] |
| 19:50.46 |
*** join/#brlcad pacman87 (n=pacman87@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 19:54.52 |
*** join/#brlcad pacman87
(n=pacman87@bz.bzflag.bz) |
| 20:29.24 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35730 10/isst/trunk/src/ (gui.c net_worker.c):
initial .g loader dialog box |
| 20:43.27 |
``Erik |
I need a test
mutant O.o |
| 20:50.16 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 21:19.18 |
``Erik |
aww, no one
wants to be a guinnea pig? |
| 21:21.00 |
louipc |
what
for? |
| 21:21.55 |
``Erik |
isst, to see
if it works on various other machines |
| 21:22.20 |
louipc |
sure |
| 21:23.00 |
``Erik |
make sure
your BRL-CAD is recent, then grab https://brlcad.svn.sourceforge.net/svnroot/brlcad/isst/trunk
and give it a while? :D |
| 21:23.44 |
louipc |
SVN rev 35355
ok? |
| 21:24.05 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35731 10/isst/trunk/src/gui.c: hide unwired
modes |
| 21:24.48 |
CIA-28 |
BRL-CAD:
03irpguardian * r35732 10/brlcad/trunk/src/libged/human.c: Various
tweaks, and added comments |
| 21:24.57 |
``Erik |
hm, cut won't
work right |
| 21:25.29 |
``Erik |
tho you can
update, go into src/adrt and do "make install" there, should work
without having to rebuild ALL of BRL-CAD |
| 21:30.51 |
louipc |
hmm |
| 21:32.07 |
louipc |
I don't have
a build or anything but I do have headers installed |
| 21:32.56 |
louipc |
selective
building doesn't seem to work. |
| 21:32.58 |
``Erik |
it should
compile and run, it's just the "cut" render method won't be
right |
| 21:33.02 |
louipc |
libtool:
link: cannot find the library `../../src/libbu/libbu.la' or
unhandled argument `../../src/libbu/libbu.la' |
| 21:33.19 |
louipc |
that's when
making adrt |
| 21:33.23 |
``Erik |
oh, heh, I
assumed you still had build stuff |
| 21:33.37 |
``Erik |
you can do
"make depends install-depends" in adrt and it should "do the right
thing" |
| 21:34.04 |
louipc |
yar! |
| 21:35.32 |
louipc |
I guess I
should leave it around |
| 21:35.52 |
louipc |
it will cut
down on build time :D |
| 21:36.08 |
``Erik |
*shrug* if
you're not doing development with it or don't want on the bleeding
edge, it's not terribly important :) |
| 21:42.32 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 21:50.07 |
``Erik |
headin' home,
bbi1h O.o |
| 22:36.56 |
``Erik |
home at
last |
| 22:37.16 |
louipc |
having
trouble pointing to the headers heh |
| 22:37.21 |
louipc |
http://louipc.mine.nu/brlcad/isst-build.log |
| 22:37.26 |
louipc |
welcome back
:D |
| 22:39.59 |
``Erik |
you don't
have /usr/brlcad/include/brlcad ? |
| 22:40.15 |
louipc |
no, it's in
opt instead |
| 22:41.00 |
``Erik |
ah, try
./configure CPPFLAGS="-I/opt/brlcad/include
-I/opt/brlcad/include/brlcad" LDFLAGS=-L/opt/brlcad/lib |
| 22:43.54 |
louipc |
do I still
need --with-adrt then? |
| 22:44.15 |
``Erik |
hrm? |
| 22:44.56 |
``Erik |
possibly, I
need to redo that bit of the configure file |
| 22:45.17 |
louipc |
hmm seems to
work |
| 22:45.41 |
louipc |
/home/louipc/devel/isst/src/gui.c:813:
undefined reference to `strnstr' |
| 22:45.49 |
louipc |
not in
Linux? |
| 22:46.39 |
``Erik |
strange,
doesn't come up when you man it? (it's just a bound limited version
of strstr(3)) |
| 22:46.54 |
louipc |
nope |
| 22:47.01 |
louipc |
strstr is
available |
| 22:47.08 |
louipc |
and
strcasestr |
| 22:47.10 |
``Erik |
it's ISO C90
O.o |
| 22:47.14 |
louipc |
o.O |
| 22:47.26 |
``Erik |
erm, mebbe
they just globbed extra crap into this manpage |
| 22:47.42 |
louipc |
dunno, but
it's not in gnu |
| 22:48.12 |
louipc |
well on my
system... hah |
| 22:48.13 |
``Erik |
hm, guess
not, seeing bug reports of linux being the odd one out for that
function |
| 22:48.24 |
louipc |
kewl |
| 22:54.25 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35733 10/isst/trunk/ (configure.ac src/gui.c):
cope with missing strnstr (linux lacks it) |
| 22:55.09 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35734 10/isst/trunk/ (Makefile.am TODO): add a
TODO list |
| 22:56.04 |
louipc |
hmm why not
use strstr throughout? |
| 22:56.37 |
``Erik |
buffer
overflow vulnerability |
| 23:03.53 |
starseeker |
woo
hoo! |
| 23:03.56 |
starseeker |
has house |
| 23:04.02 |
louipc |
whoa I got a
big window |
| 23:04.11 |
louipc |
starseeker:
nice congrats |
| 23:04.15 |
``Erik |
w00t, grats,
starseeker |
| 23:04.21 |
starseeker |
thanks
:-) |
| 23:04.39 |
``Erik |
louipc: try
opening '/path/to/ktank.g' with the region 'tank' |
| 23:05.31 |
louipc |
sweet |
| 23:06.04 |
``Erik |
left click
zooms in and out, middle click pans, right click
rotates |
| 23:08.01 |
louipc |
hmm doesn't
perform too well |
| 23:08.17 |
louipc |
kicks up cpu
usage 100% if I do anything |
| 23:08.22 |
``Erik |
yes |
| 23:08.24 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35735 10/isst/trunk/ (TODO configure.ac
src/Makefile.am): Cope with BRL-CAD being installed somewhere other
than /usr/brlcad via a --with-brlcad=/path/to/brlcad
flag. |
| 23:08.25 |
``Erik |
what kinda
framerate? |
| 23:08.29 |
``Erik |
and what
kinda mcahine? |
| 23:08.45 |
``Erik |
(every update
to the display is a raytraced scene...) |
| 23:08.47 |
louipc |
PIII
866MHz |
| 23:09.09 |
louipc |
how do I see
the framerate? |
| 23:09.14 |
``Erik |
ahhh, yeah,
not too many ponies to push it :) |
| 23:09.14 |
louipc |
oh I
see |
| 23:09.18 |
``Erik |
should be
printing to console |
| 23:10.15 |
louipc |
.4 FPS?
lol |
| 23:10.21 |
``Erik |
heh, not bad
at all |
| 23:10.37 |
``Erik |
compare it to
the time rt takes to render :D |
| 23:10.37 |
louipc |
that sounds
horrible |
| 23:10.46 |
``Erik |
(that's zomfg
raytraced, not opengl or anything) |
| 23:10.51 |
louipc |
ok
sure |
| 23:10.57 |
louipc |
oh no
hardware accel eh? |
| 23:11.00 |
``Erik |
right |
| 23:12.25 |
louipc |
ooh got up to
.59 FPS |
| 23:13.26 |
louipc |
ls |
| 23:13.29 |
louipc |
erp |
| 23:13.58 |
``Erik |
(that model
is actually one of the worst performing ones due to huge flat
surfaces, the KD-tree doesn't build nice... but it converts very
fast) |
| 23:15.02 |
louipc |
oh it
converts to BOTS |
| 23:15.28 |
``Erik |
yeah |
| 23:15.30 |
louipc |
why would
large flat surfaces be bad for that? o.O |
| 23:15.49 |
louipc |
two triangles
could make a football field :P |
| 23:15.50 |
``Erik |
can't
subdivide the scene very efficiently, and triangles get dup'd a
lot |
| 23:16.09 |
``Erik |
um, if you
turn on the 'depth' render mode, it paints a visualization of the
kd tree |
| 23:17.56 |
louipc |
wait a sec.
what's this mention of mysql? hahah |
| 23:18.24 |
``Erik |
um, that's
been removed |
| 23:18.50 |
``Erik |
it used to
require specially prepared geometry that was saved in a MySQL
database, now it load .g straight |
| 23:19.28 |
louipc |
ah
cool |
| 23:19.43 |
louipc |
was it faster
or something? |
| 23:24.02 |
``Erik |
hrm? whihc,
the mysql approach? it allowed a centralized place to load
geometry, and the conversion results were saved |
| 23:24.58 |
louipc |
ah. I guess
if that geometry server gets going, it'll solve that
problem |
| 23:24.58 |
``Erik |
when I make
it networked again, it'll transmit geometry from the client (so the
compute nodes don't need any special access), and I plan on having
a fast path through .g files that are set up right (each region
contains exactly 1 bot/nmg) |
| 23:25.08 |
``Erik |
or use the
geometry server if that comes soon 'nuff :D |
| 23:25.14 |
louipc |
nice |
| 23:26.45 |
``Erik |
aight, cool,
it runs on linux now (and someone out in the 'real world' has run
it, w00t) |
| 23:26.55 |
louipc |
highfive |
| 23:27.58 |
louipc |
what happened
to Maleoran? didn't he have a real-time raytracer? |
| 23:28.10 |
louipc |
oh yeah he
was running it on an 8-core machine though |
| 23:29.36 |
``Erik |
yeah, this
one runs multi-million triangle models at ~30fps on my 8 core
mac |
| 23:29.59 |
louipc |
:O |
| 23:30.02 |
``Erik |
what you just
ran was the impetus that got mal started on writing one |
| 23:30.10 |
louipc |
oh
haha |
| 23:30.45 |
``Erik |
runs at about
5 on my laptop |
| 23:32.11 |
brlcad |
congratulations starseeker |
| 23:32.31 |
starseeker |
brlcad:
thanks :-) |
| 23:33.13 |
starseeker |
eyes huge swath of mowed grass and appreciates why brlcad
picked the location he did... |
| 23:33.27 |
``Erik |
heh |
| 23:33.45 |
``Erik |
pays $45/qtr for lawn service :) |
| 23:34.01 |
louipc |
when's the
first bbq, hot tub, house party? |
| 23:34.31 |
starseeker |
heh -
probably right after we remodel the whole thing |
| 23:35.08 |
louipc |
wowz |
| 23:36.17 |
starseeker |
It's kinda a
70's palace AM |
| 23:36.18 |
``Erik |
didja buy the
70's one? |
| 23:36.20 |
``Erik |
hah |
| 23:36.23 |
starseeker |
a the
moment |
| 23:36.26 |
starseeker |
yep |
| 23:36.29 |
starseeker |
can't type |
| 23:36.38 |
``Erik |
just up the
road from me, heh O.o |
| 23:36.39 |
louipc |
shag
carpetting? |
| 23:36.51 |
louipc |
or is that
60s? |
| 23:37.34 |
starseeker |
not quite
that bad |
| 23:37.37 |
starseeker |
mirror wall
though |
| 23:37.41 |
louipc |
duuude |
| 23:41.26 |
starseeker |
``Erik: yeah,
that's at least three of us out that way now |
| 23:42.37 |
``Erik |
well, bob,
daytona, eric e, ... |
| 23:48.03 |
brlcad |
also the same
reason I didn't pick the huge 3 acre lotted house.. would have
spent every weekend working on that enormous yard and the
gardening |
| 23:51.30 |
starseeker |
will probably regret it, but it does look
nice |
| 23:52.00 |
starseeker |
must remember to beware of ceramic cat bird
feeders |
| 23:55.18 |
brlcad |
it's also
kinda related to your existing -above/-below options |
| 23:55.32 |
brlcad |
(thinking out
loud) |
| 23:56.20 |
starseeker |
yeah, or
maybe -path |
| 23:56.45 |
brlcad |
search .
-type region -above -op sub |
| 23:57.12 |
brlcad |
it's not even
necessarily the immediate parent |
| 23:57.22 |
brlcad |
it's if any
of the parents are negative, it's a negative region |
| 23:57.28 |
starseeker |
that's
true |
| 23:57.32 |
starseeker |
good
point |
| 23:57.40 |
starseeker |
that actually
solves a problem I hadn't thought of yet |
| 23:57.53 |
brlcad |
the harder
one is intersection to as that can be negative or
positive |
| 23:58.02 |
brlcad |
and there's
no way to tell really |
| 23:58.32 |
brlcad |
fortunately,
they're just rarely used, but we should figure something out to be
consistent |
| 23:58.41 |
starseeker |
Yeah - it
could look above for an intersect op and report it, but how to
interpret it would be a problem |
| 23:59.15 |
brlcad |
like based on
whether the bounding volumes overlap, or assume if there's an
intersection operator, that the intent was that they at least
intersect (in which case it's a positive region and a modeling
error) |
| 23:59.31 |
starseeker |
yeah, I was
thinking the latter |
| 00:00.12 |
starseeker |
unless I'm
missing something, the intent of an intersect is to have SOME solid
volume result |
| 00:00.18 |
brlcad |
well, with
our present solid modeling system, yes :) |
| 00:00.21 |
brlcad |
in a pure
one, no |
| 00:00.41 |
starseeker |
uh oh
:-) |
| 00:01.11 |
brlcad |
because you
could do somet complex combinations to do things like intersect to
get a null set, invert that set to get an infinite set, use that to
match otehr object, etc |
| 00:01.37 |
brlcad |
rather, in a
CSG system, yes; in a pure boolean system, no |
| 00:02.27 |
starseeker |
votes we assume a CSG system :-P |
| 00:03.58 |
brlcad |
you say that
now :) |
| 00:04.31 |
starseeker |
oh
dear |
| 00:04.36 |
brlcad |
with your
background and math tendancies, pure boolean will appeal to you --
it's just a slight superset |
| 00:04.48 |
brlcad |
i mean we
actually have/use all the components |
| 00:04.53 |
starseeker |
ah
:-) |
| 00:05.08 |
brlcad |
it more just
how you deal with things like infinite spaces (which we deal with
partially via halfspaces) |
| 00:05.16 |
brlcad |
and null
objects |
| 00:05.26 |
starseeker |
well, from
the standpoint of search, the -op operator would just look for and
report the existence of the op, yes? |
| 00:05.47 |
starseeker |
brlcad: erg,
halfspaces. everytime I think of those I think of nirt +
half |
| 00:06.09 |
brlcad |
that wasn't
an exact example .. how you search for an operator usefully is an
interesting thought |
| 00:06.26 |
brlcad |
knowing
"there exists" isn't very useful by itself |
| 00:06.48 |
brlcad |
right, and
nirt should report hitpoint -> infinity ideally |
| 00:07.18 |
starseeker |
ah |
| 00:07.40 |
starseeker |
thinks Ed will have fun with the concept of a hit at infinity
:-) |
| 00:08.22 |
starseeker |
brlcad: so we
need a combination of -op and -above with a "level above"
operator |
| 00:08.44 |
brlcad |
we go through
contortions now when modeling because we don't readily expose the
one operator that makes pure boolean possible |
| 00:08.49 |
starseeker |
search -type
region -above=1 -op=sub |
| 00:10.28 |
brlcad |
search .
-type region -above \( -maxdepth=1 -op=sub \) |
| 00:10.28 |
starseeker |
that's an
expansion on the power of above (and I suppose the below) ideas to
allow specific relative depth matching |
| 00:11.02 |
starseeker |
yes, that
might do |
| 00:11.13 |
brlcad |
can think of
the obve option as a sub-search |
| 00:11.21 |
brlcad |
above/below |
| 00:11.52 |
brlcad |
with above
being a reverse traversal of a "tree" that is just the parent to
parent traversal |
| 00:12.17 |
brlcad |
so you can
specify the same halting and depth params as boigoing
down |
| 00:12.27 |
starseeker |
I think
that's a conceptual change to above, but it does make
sense |
| 00:13.01 |
starseeker |
actually, no
it isn't |
| 00:13.16 |
brlcad |
it'll still
behave the same as it does now |
| 00:13.24 |
starseeker |
right |
| 00:13.40 |
starseeker |
I see
it |
| 00:13.45 |
starseeker |
nifty |
| 00:13.49 |
brlcad |
just have to
make sure it respects the expression |
| 00:14.00 |
starseeker |
yeah, that's
the trick |
| 00:14.21 |
brlcad |
is happier we're not breaking form |
| 00:14.37 |
starseeker |
might need
-above=\( -max-depth=1 -op sub \) or some such |
| 00:14.52 |
brlcad |
hm, why's
that? |
| 00:15.22 |
starseeker |
Oh, no wait
you're right |
| 00:15.31 |
starseeker |
was forgetting above always takes an expression as an
argument |
| 00:15.32 |
starseeker |
duh |
| 00:15.39 |
starseeker |
been too long
since I played with search |
| 00:16.40 |
starseeker |
doesn't think he's ever tried --max-depth inside an -above or
-below, wonder if it works |
| 00:18.32 |
brlcad |
doubts it :) |
| 00:19.15 |
brlcad |
because I
think above/below are constructs you added.. you would have to
maually make them respect the depth limiters in the rule set I'd
imagine |
| 00:19.21 |
starseeker |
would require
"rerooting" the depth count... hmm... |
| 00:19.49 |
starseeker |
I suppose in
that sense above and below already break with classic
find? |
| 00:26.42 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:30.20 |
brlcad |
-above sorta,
but if it behaves like a pure reverse traversal, it's not so
bad |
| 00:30.32 |
brlcad |
as then both
above/below are just sub-finds |
| 00:31.42 |
brlcad |
-below is
equivalent to: find . -type region -exec find {} -type comb
-maxdepth=5 \; |
| 00:35.31 |
brlcad |
above could
be achieved similarly with some sort of -uses option where it
traverses a different hierarchy, the result of walking dbfind
recursively |
| 00:35.55 |
brlcad |
the hard one
is -op .. not sure that's as simple as we made it seem |
| 00:36.32 |
CIA-28 |
BRL-CAD:
0324.151.165.78 07http://brlcad.org
* r1612 10/wiki/MGED_CMD_joint: /* See Also */ |
| 00:38.58 |
brlcad |
o.O |
| 01:10.01 |
*** join/#brlcad parolang
(n=user@keholmes.oregonrd-wifi-1261.amplex.net) |
| 01:20.02 |
``Erik |
"c'mon,
bender, you can push harder than that!" "no crap, my mom was a
bulldozer!" heh |
| 01:23.42 |
CIA-28 |
BRL-CAD:
03starseeker * r35736 10/brlcad/trunk/ (4 files in 3 dirs): This
should 'libgedify' the search command, and get it outputing its
results to a Tcl string |
| 01:24.22 |
starseeker |
seems to be
faster for some reason - maybe it's just me... |
| 01:26.26 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 01:44.40 |
``Erik |
"prepare to
launch universe to universe missile!" |
| 01:49.08 |
starseeker |
``Erik: heh,
what's that, the Futurama movie? |
| 02:02.46 |
``Erik |
yeah, ti's on
comedy central |
| 02:26.10 |
CIA-28 |
BRL-CAD:
03starseeker * r35737 10/brlcad/trunk/ (7 files in 7 dirs): Add
search command to Archer |
| 02:26.14 |
starseeker |
yes! |
| 04:48.57 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 05:09.31 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 10:10.27 |
*** join/#brlcad jdoliner
(n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net) |
| 10:45.10 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 12:06.47 |
*** join/#brlcad BigAToo
(n=BigAToo@96.230.124.58) |
| 13:10.14 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 13:43.41 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 13:59.49 |
CIA-28 |
BRL-CAD:
03brlcad * r35738 10/brlcad/trunk/TODO: old notes and thoughts on a
highly increasing need for an annotation primitive. comments and
additions welcome. not to be confused with a plot primitive, though
highly related. |
| 14:07.12 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14E3F2.dip.t-dialin.net) |
| 14:44.59 |
*** join/#brlcad talcite
(n=Matthew@bas1-toronto21-1242460497.dsl.bell.ca) |
| 15:43.37 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 15:50.01 |
*** part/#brlcad jdoliner
(n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net) |
| 16:08.06 |
*** join/#brlcad jdoliner
(n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net) |
| 16:19.29 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 17:29.07 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 17:40.16 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 17:42.05 |
*** join/#brlcad FAMULUS
(n=mark@32.139.175.39) |
| 17:45.43 |
*** join/#brlcad BigAToo1
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 17:58.21 |
starseeker |
Holy Cow.
http://www.newscientist.com/article/dn17699-microscopes-zoom-in-on-molecules-at-last.html |
| 17:58.49 |
starseeker |
that's the
kind of photo I can see framing and sticking on a wall |
| 18:17.24 |
brlcad |
now if it was
just in focus! |
| 18:17.27 |
brlcad |
that is
pretty awesome |
| 18:19.01 |
``Erik |
grouses at c++ some more |
| 18:21.24 |
``Erik |
ld: Undefined
symbols: |
| 18:21.24 |
``Erik |
__Unwind_Resume |
| 18:22.56 |
``Erik |
src/librt/primitives/nmg/nmg_brep.cpp: In
function `void rt_nmg_brep(ON_Brep**, const rt_db_internal*, const
bn_tol*)': |
| 18:22.59 |
``Erik |
src/librt/primitives/nmg/nmg_brep.cpp:263:
error: ISO C++ says that these are ambiguous, even though the worst
conversion for the first is better than the worst conversion for
the second: |
| 18:27.34 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 18:36.31 |
starseeker |
``Erik:
sorry! |
| 18:37.21 |
``Erik |
(only seeing
the librt one on linux machines, the unwind_resume issue is only on
osX.4 it'd seem) |
| 18:37.32 |
``Erik |
fbsd compiles
it all ok heh |
| 18:42.43 |
``Erik |
hm, unwind
resume issue is from trying to linke with --tag=CC gcc instead of
--tag=CXX g++ to cope with the c++ bits |
| 18:43.50 |
brlcad |
it's missing
FEXCEPTIONS |
| 18:43.55 |
brlcad |
configure
already deals with that |
| 18:44.20 |
``Erik |
apparently
not very well :D (g++ or -fexceptions, yes) |
| 18:44.52 |
brlcad |
configure
deals with it just fine, the define isn't being used |
| 18:45.00 |
brlcad |
either due to
staleness or it's just missing from the cflags |
| 18:45.32 |
``Erik |
hm, this was
a fresh purge and autogen.sh, so I don't think
staleness |
| 18:47.54 |
brlcad |
librt_nil_CFLAGS has FEXCEPTIONS and there
are a half dozen other _brep.cpp files being compiled |
| 18:48.22 |
``Erik |
(there're two
different and seperate issues I pasted) |
| 18:49.24 |
``Erik |
seeing the
g++/fexception one all over the place on my mac, the nmg_brep one
was just that one file and just on amd64 rhel |
| 18:55.31 |
brlcad |
is the
compile line actually using -Wc,-fexceptions ? |
| 18:55.43 |
brlcad |
or
-fexceptions directly if expanded |
| 18:57.56 |
brlcad |
the nmg_brep
error is less interesting, easier to fix :) |
| 18:57.58 |
``Erik |
did another
purge and rebuilding now... |
| 18:58.45 |
brlcad |
purge with
manual killage of the .deps? |
| 19:03.37 |
CIA-28 |
BRL-CAD:
03brlcad * r35739 10/brlcad/trunk/ (5 files in 4 dirs): |
| 19:03.37 |
CIA-28 |
BRL-CAD:
break out half mirroring next, though not convinced the existing
logic is |
| 19:03.37 |
CIA-28 |
BRL-CAD:
actually correct. needs testing of course, but for now it's just
the previous |
| 19:03.37 |
CIA-28 |
BRL-CAD:
logic as it was in mirror.c as there are several dozen others to
break out |
| 19:03.37 |
CIA-28 |
BRL-CAD:
still. |
| 19:08.09 |
``Erik |
adds LDFLAGS |
| 19:11.02 |
brlcad |
which binary
is it actually compiling that gives the error?
brep_test? |
| 19:11.07 |
brlcad |
comb? |
| 19:14.15 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35740 10/brlcad/trunk/src/ (5 files in 5 dirs):
add FEXCEPTIONS to makefiles that seem to need it. |
| 19:14.49 |
brlcad |
see, that's
not right |
| 19:14.57 |
brlcad |
that sounds
like there's something exposed in a header that shouldn't
be |
| 19:15.24 |
brlcad |
which is a
bigger problem |
| 19:15.29 |
``Erik |
probably, was
kinda my initial guess, but *shrug* I'm tired and my brain is
already on weekend |
| 19:15.51 |
brlcad |
aw, cmon,
you're the one that can actually test it |
| 19:16.04 |
brlcad |
i don't get
the error here |
| 19:16.37 |
``Erik |
hm |
| 19:16.51 |
``Erik |
brep.h
includes opennurbs_ext.h which has throws clauses in i
t |
| 19:17.48 |
brlcad |
that's only
with __cplusplus, so it shouldn't find its way in during
c-compilation |
| 19:18.03 |
``Erik |
his is a link
error, though, not a compilation error |
| 19:18.04 |
brlcad |
supposed to
get a dummy strut |
| 19:18.32 |
brlcad |
it only
manifest during link that you missed -fexceptions during
compile |
| 19:20.19 |
CIA-28 |
BRL-CAD:
03starseeker * r35741
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Add some
different debugging to nmg_brep, try some tweaks. |
| 19:20.35 |
``Erik |
wonders if this box got another botched upgrade from radmind,
as it's the only one that exhibits |
| 19:21.22 |
brlcad |
i doubt it,
that exceptions error is very specific |
| 19:21.49 |
*** join/#brlcad talcite__
(n=Matthew@bas2-toronto21-1242350656.dsl.bell.ca) |
| 19:21.50 |
brlcad |
more likely
someone(tm) exposed some c++ logic somewhere via header inclusion
that is causing it |
| 19:22.02 |
``Erik |
all those
libs gave me errors for unwind_resume missing |
| 19:22.11 |
CIA-28 |
BRL-CAD:
03brlcad * r35742 10/brlcad/trunk/include/brep.h: ws |
| 19:22.23 |
brlcad |
maybe having
the _brep.cpp files enabled, I think that was relatively
recent |
| 19:22.40 |
``Erik |
librt
compiles with the -f flag, though |
| 19:22.49 |
``Erik |
hrm |
| 19:22.50 |
brlcad |
can you
nm/grep the lib to see the symbols that have it? |
| 19:23.13 |
brlcad |
to see if
it's just all of them (i.e. header problem) or just a specific
file? |
| 19:23.28 |
``Erik |
all the brep
ones |
| 19:23.36 |
brlcad |
so linking
the *lib* gives the error or some bin in that same dir? |
| 19:23.59 |
``Erik |
the
lib |
| 19:24.21 |
``Erik |
librt links
fine, libs that USE librt fail, like libged, liboptical,
... |
| 19:24.49 |
brlcad |
that's gotta
be cascade unresolved lookup failure trying to resolve the lib,
yeah, that's odd |
| 19:25.07 |
brlcad |
librt.so have
unwindresume unresolved in it? |
| 19:25.10 |
``Erik |
src/librt$
grep Unwind *.o | cut -d \ -f 3 | xargs |
| 19:25.10 |
``Erik |
arb8_brep.o
brep.o brep_debug.o eto_brep.o nmg_brep.o opennurbs_ext.o
sph_brep.o tor_brep.o |
| 19:25.23 |
brlcad |
aha |
| 19:25.31 |
brlcad |
i bet i know
what it is.. |
| 19:25.33 |
``Erik |
yes |
| 19:25.37 |
``Erik |
<PROTECTED> |
| 19:25.59 |
brlcad |
er, maybe
not |
| 19:27.02 |
brlcad |
ah,
yes |
| 19:27.28 |
``Erik |
<PROTECTED> |
| 19:27.28 |
``Erik |
<PROTECTED> |
| 19:27.28 |
``Erik |
<PROTECTED> |
| 19:27.28 |
``Erik |
<PROTECTED> |
| 19:27.35 |
``Erik |
right at the
beginning of the opennurbs stuff |
| 19:28.30 |
brlcad |
can you show
the actual compile line for one of the _brep.cpp files? |
| 19:28.38 |
brlcad |
strip out the
--silents |
| 19:28.52 |
brlcad |
rm
arb8_brep.lo or something |
| 19:29.46 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 19:29.57 |
brlcad |
or more
simple I guess, grep CXXFLAGS src/librt/Makefile |
| 19:30.12 |
Yoshi47 |
Hellloooo,
whats going on today |
| 19:30.13 |
brlcad |
er maybe
"CXXFLAGS =" |
| 19:30.24 |
brlcad |
hello
Yoshi47 |
| 19:30.29 |
brlcad |
coding
day |
| 19:30.34 |
``Erik |
http://pastebin.bzflag.bz/d53a90b2 |
| 19:30.46 |
Yoshi47 |
umm fun, i
just finished putting in my patio, and spreading shit on my
lawn |
| 19:31.32 |
``Erik |
CXXFLAGS =
-pipe -fno-strict-aliasing -fno-common -fexceptions -g
-O3 |
| 19:31.51 |
brlcad |
yeah, huh,
well blew that theory |
| 19:34.40 |
``Erik |
hrm, your
desktop isn't up (stupid power outages) |
| 19:37.55 |
brlcad |
looks like
some progress, though -- I do see unresolved _Unwind_Resumes in my
.o files here |
| 19:38.06 |
brlcad |
7 of
them |
| 19:38.42 |
``Erik |
librt links
fine with those missing definitions, but the 5 or so I committed
changes to fail due to unresolved symbol |
| 19:38.46 |
brlcad |
oddly,
opennurbs_ext isn't new |
| 19:39.04 |
starseeker |
am I breaking
stuff with the *_brep.cpp files? |
| 19:39.11 |
starseeker |
can disable them in the tree if need be |
| 19:39.35 |
``Erik |
(that it
works peachy keen on linux and fbsd is the confounding
part) |
| 19:40.25 |
brlcad |
10.6
? |
| 19:41.21 |
``Erik |
? |
| 19:41.51 |
brlcad |
er, 10.5 or
10.4? |
| 19:42.09 |
``Erik |
the issue
ison .4, I tried compiling on .5 and didn't see any
issue |
| 19:42.22 |
``Erik |
copying src
to starseekers machine to see if it breaks there |
| 19:42.25 |
brlcad |
huh, even
more reason I should be seeing it here |
| 20:37.07 |
CIA-28 |
BRL-CAD:
03starseeker * r35743
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: OK, the 2d
curve generation in UV space is disconnected from the 3d edges in
some form. The general case needs pullback from 3d into 2d space
but in theory the planar case should be simpler - just need to
figure it out. |
| 20:37.25 |
``Erik |
hm, seeing it
on starseekers machine, too O.o lemme try an autogen.sh on another
box |
| 20:53.53 |
CIA-28 |
BRL-CAD:
03brlcad * r35744 10/brlcad/trunk/ (4 files in 3 dirs): split out
grip object mirroring. seems to have a similar issue computing an
angle, but just leave it as is with a note. |
| 20:54.31 |
CIA-28 |
BRL-CAD:
03starseeker * r35745
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: whoops, no
duplicate vertices please |
| 21:45.09 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 22:29.58 |
``Erik |
ho
hum |
| 22:36.14 |
``Erik |
snickers at ralith |
| 22:39.32 |
Ralith |
thwaps ``Erik |
| 22:43.43 |
``Erik |
hehehe |
| 22:44.10 |
``Erik |
quit trying
to treat lisp like C :D the compiler does some skeery awesome
stuff |
| 22:45.34 |
``Erik |
(also; clos
is chock full of awesomeness) |
| 23:29.36 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 23:41.09 |
Ralith |
``Erik: just
tryin' to port C faithfully. |
| 23:41.37 |
Ralith |
EQUALP seems
to do the job nicely and lispily, anyway. |
| 23:45.25 |
starseeker |
Ralith,
``Erik: do I want to know? |
| 23:45.47 |
starseeker |
suspects ``Erik is training Ralith in the ways of True
Power |
| 23:46.10 |
Ralith |
actually ended up there before ``Erik, iirc
>_> |
| 23:51.38 |
``Erik |
no, ralith
was getting strusfrated in #lisp |
| 23:52.00 |
Ralith |
not
frustrated so much as zerged by extremely helpful people who were
consistently misunderstanding what I wanted to do :P |
| 23:52.00 |
``Erik |
and I was
snickering cuz he was trying to pose a question from a C frame of
mind and they were all ... not... quit... getting it |
| 23:52.18 |
Ralith |
which is
admittedly among the more frustrating things one might encounter on
the internet |
| 23:52.34 |
``Erik |
I know, those
damn snobby elitist lisp people |
| 23:52.38 |
Ralith |
hehe |
| 23:52.48 |
Ralith |
is surprised more lispers aren't familiar with
C |
| 23:53.08 |
``Erik |
most probably
are somewhat, but ya really tend to shift gears |
| 23:54.05 |
``Erik |
has bounced between the two quite often over the last decade,
is used to shifting gears like that :) |
| 23:54.19 |
``Erik |
(though
scheme from '00-07, not CL) |
| 23:57.16 |
``Erik |
still waiting
for a BRL-CAD CFFI though |
| 00:42.02 |
CIA-28 |
BRL-CAD:
03brlcad * r35781 10/brlcad/trunk/src/librt/binary_obj.c: per the
problem encountered by Alex Vlasse, make sure the database
directory is initialized when someone calls rt_mk_binunif()
otherwise it will always result in failure due to db_write() seeing
a -1 eof offset. |
| 01:06.16 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) |
| 01:31.31 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) |
| 01:54.22 |
*** join/#brlcad talcite
(n=Matthew@bas2-toronto21-1242350945.dsl.bell.ca) |
| 01:57.17 |
CIA-28 |
BRL-CAD:
03brlcad * r35782 10/brlcad/trunk/src/librt/CMakeLists.txt: add
arb8_brep.ccp and nmg_brep.cpp to the cmake build |
| 02:34.03 |
yukonbob |
is cmake a
viable option to try building brl-cad, or is it a WIP? |
| 02:34.24 |
yukonbob |
(or perhaps
it's both?) |
| 02:59.23 |
*** join/#brlcad matthewmpp
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
| 03:48.28 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 03:49.24 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 06:34.48 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 08:01.15 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 08:20.29 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:24.43 |
d-lo |
Mernin
all! |
| 10:40.34 |
``Erik |
yargh |
| 11:22.02 |
*** join/#brlcad Yoshi47
(n=jan@firewall.walinga.com) |
| 11:46.27 |
*** join/#brlcad ert976
(n=ertan@88.240.173.5) |
| 11:48.34 |
brlcad |
hola |
| 11:48.40 |
brlcad |
yukonbob:
both |
| 11:48.49 |
brlcad |
it won't
build everything |
| 11:57.34 |
*** join/#brlcad jdoliner
(n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net) |
| 12:14.03 |
*** part/#brlcad ert976
(n=ertan@88.240.173.5) |
| 12:16.10 |
jdoliner |
anyone
around? |
| 12:17.02 |
brlcad |
nope |
| 12:19.14 |
jdoliner |
:p |
| 12:19.24 |
jdoliner |
i have an
annoying problem |
| 12:19.35 |
jdoliner |
well there's
some aspect of the opennurbs api I'm missing |
| 12:20.21 |
jdoliner |
basically one
of the bezier curve constructor functions is
ON_BezierCurve(PointArray) |
| 12:20.43 |
jdoliner |
so I use
that, but then whenever I try to do something with the curve it
segfaults immediately |
| 12:21.29 |
jdoliner |
as far as I
can see there isn't even a subroutine it's segfaulting
in |
| 12:22.34 |
brlcad |
you mean when
the application starts, or when you first use the object or when
the object is constructed? |
| 12:22.46 |
jdoliner |
when I first
use the object |
| 12:22.50 |
jdoliner |
by use I mean
call a method |
| 12:22.55 |
brlcad |
so it
constructs cleanly |
| 12:23.01 |
jdoliner |
yeah |
| 12:23.02 |
brlcad |
as far as you
know.. |
| 12:23.11 |
jdoliner |
and
inspecting it in the debugger |
| 12:23.24 |
jdoliner |
it seems
pretty much the same as curves that don't segfault |
| 12:23.39 |
jdoliner |
although
there's a lot going on in curve instances |
| 12:23.56 |
brlcad |
well if
you're in the debugger, how/where is it faulting? |
| 12:24.04 |
brlcad |
does the
stack disappear on you? |
| 12:24.38 |
jdoliner |
yes... |
| 12:24.43 |
jdoliner |
I think it
does |
| 12:24.46 |
jdoliner |
the line
is: |
| 12:24.49 |
jdoliner |
curve1->GetTightBoundingBox(bbox1); |
| 12:24.52 |
jdoliner |
that's where
gdb reports it |
| 12:25.09 |
jdoliner |
so maybe it
just doesn't see the source for the actually seg fault? |
| 12:25.53 |
jdoliner |
why would the
stack disappear on me. I've never had that happen to me |
| 12:27.01 |
jdoliner |
btw that's:
src/proc-db/surfaceintersect.cpp:390 |
| 12:27.04 |
``Erik |
smashed |
| 12:27.14 |
jdoliner |
you or the
stack? |
| 12:27.48 |
``Erik |
the
stack |
| 12:27.50 |
``Erik |
heh |
| 12:28.29 |
jdoliner |
:p |
| 12:28.46 |
``Erik |
if'n ya write
up past heap and into the stack, or if you do "scary" stuff using
pointers into the stack, bad things happen and gdb doesn't try to
print the cooked stack out |
| 12:29.01 |
jdoliner |
k |
| 12:29.07 |
jdoliner |
that makes
sense to me |
| 12:29.42 |
jdoliner |
but something
doesn't feel right about that |
| 12:29.48 |
indianlarry |
it does
expect the PointArray to be order big |
| 12:30.11 |
brlcad |
looking at
the On_BezierCurve class, it looks like the
m__GetBezierCurveTightBoundingBox is something you have to
implement |
| 12:30.14 |
jdoliner |
indianlarry:
explain order big |
| 12:30.23 |
brlcad |
which is what
GetTightBoundingBox() uses |
| 12:30.28 |
jdoliner |
oh |
| 12:30.37 |
jdoliner |
what line is
the empty function on? |
| 12:30.51 |
brlcad |
it should
just be returning false if it's not implemented, but maybe you're
relying on it being something non-false |
| 12:31.35 |
brlcad |
look at
On_BezierCurve::GetTightBoundingBox() |
| 12:32.14 |
brlcad |
you'll see it
just calls m__GetBezierCurveTightBoundingBox() .. which is never
set anywhere, probably something removed from the lib for
openNURBS |
| 12:32.51 |
jdoliner |
k I see
that |
| 12:32.56 |
brlcad |
those are
public functions though, meant to be easily stubbed in |
| 12:33.00 |
brlcad |
there are
like 5 of them |
| 12:33.20 |
brlcad |
<PROTECTED> |
| 12:33.24 |
brlcad |
<PROTECTED> |
| 12:33.27 |
brlcad |
<PROTECTED> |
| 12:33.30 |
brlcad |
<PROTECTED> |
| 12:33.33 |
brlcad |
4 to be more
precise |
| 12:34.11 |
jdoliner |
hmm,
okay |
| 12:34.37 |
jdoliner |
it still
kinda bugs me that that's causing a segfault |
| 12:35.01 |
brlcad |
yeah, from
the look of the code, that's not exactly what's causing a segfault,
at least I don't see a problem |
| 12:35.14 |
brlcad |
it would be
some other assumption |
| 12:35.34 |
brlcad |
unless
static ON__m__GetLocalClosestPointOnBezierCurve
m__GetLocalClosestPointOnBezierCurve; static
ON__m__GetLocalBezierCurveSurfaceIntersection
m__GetLocalBezierCurveSurfaceIntersection; static
ON__m__GetLocalBezierCurveCurveIntersection
m__GetLocalBezierCurveCurveIntersection; static
ON__m__GetBezierCurveTightBoundingBox
m__GetBezierCurveTightBoundingBox; |
| 12:35.39 |
brlcad |
oops |
| 12:35.54 |
brlcad |
unless
m__GetBezierCurveTightBoundingBox() was never initialized and was
just some random memory address |
| 12:36.23 |
brlcad |
but I see it
initialized in opennurbs_basic.cpp |
| 12:36.38 |
brlcad |
(to
0) |
| 12:37.33 |
brlcad |
ah, there's
the 5th,
ON_BezierSurface::m__GetClosestPointOnBezierSurface() |
| 12:37.44 |
brlcad |
the others
are ON_BezierCurve callbacks |
| 12:38.17 |
jdoliner |
yeah |
| 12:38.36 |
jdoliner |
well
initializing it to 0 wouldn't explain a segfault would
it? |
| 12:38.46 |
brlcad |
no, that
should prevent it |
| 12:38.58 |
brlcad |
not
initializing it to zero would explain it |
| 12:39.07 |
jdoliner |
yeah |
| 12:39.28 |
brlcad |
step through
one line at a time, should be clear when things go
wonky |
| 12:39.49 |
brlcad |
break on
GetTightBoundingBox and step into it |
| 12:40.04 |
brlcad |
suspect it's
a problem either right before or shortly after |
| 12:41.33 |
jdoliner |
maybe I'm
doing it wrong but it's not letting me step in |
| 12:41.48 |
brlcad |
how's
that? |
| 12:41.51 |
jdoliner |
i give it
step command and it segfaults immediately |
| 12:42.02 |
jdoliner |
on the
GetTight... call |
| 12:42.07 |
brlcad |
"i"? |
| 12:42.23 |
brlcad |
or
"n"? |
| 12:43.15 |
jdoliner |
umm, I'm
confused |
| 12:43.17 |
brlcad |
"p
BezierCurve::GetTightBoundingBox" should be a valid
address |
| 12:43.38 |
brlcad |
p
yourobject->GetTightBoundingBox" should also be
valid |
| 12:44.41 |
jdoliner |
yeah they
both are |
| 12:45.14 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) |
| 12:47.20 |
brlcad |
"i" is the
you compiled opennurbs with optimization turned off? |
| 12:47.30 |
brlcad |
s/"i" is
the// |
| 12:48.09 |
brlcad |
what happens
if you put a break on BezierCurve::GetTightBoundingBox |
| 12:49.36 |
jdoliner |
it still hits
that segfault :/ |
| 12:50.10 |
brlcad |
implies that
the address isn't right |
| 12:50.23 |
brlcad |
which means
you got memory corrupted somewhere before you get there |
| 12:51.26 |
brlcad |
you can put a
printf in the routine and break on it to make sure, but you
probably have some null deref going on somewhere |
| 12:52.16 |
jdoliner |
hmm, actually
calling any method of the curve |
| 12:52.21 |
jdoliner |
gets me a
segfault |
| 12:52.28 |
jdoliner |
even one's
that are implemented |
| 13:09.48 |
jdoliner |
well here's
something interesting: |
| 13:10.03 |
brlcad |
sounds like
it's not constructed |
| 13:10.27 |
jdoliner |
if I do
everything the same but instead of declaring it as an ON_Curve I
call it an ON_BezierCurve, then there's no segfaults |
| 13:11.25 |
brlcad |
er, que? how
were you declaring it as an ON_Curve and using it as an
ON_BezierCurve? |
| 13:11.35 |
brlcad |
you would
have needed a dynamic cast |
| 13:13.43 |
jdoliner |
eureka |
| 13:13.49 |
jdoliner |
well atleast
I think so |
| 13:13.59 |
jdoliner |
yes that's
the question I needed to hear |
| 13:14.44 |
jdoliner |
I'm declaring
it fine as a BezierCurve but things are getting screwy because I'm
trying to then abstract it up to just a Curve |
| 13:14.58 |
jdoliner |
and I'm doing
that in a wrong way |
| 13:15.05 |
jdoliner |
let's see if
this theory holds any water |
| 13:27.56 |
brlcad |
you can cast
up and down just fine, but you should be explicit about
it |
| 13:28.36 |
brlcad |
still doesn't
explain the crash, but I'm guessing still an invalid
dereference |
| 13:29.02 |
jdoliner |
well so it
turns out BezierCurves aren't actually an extension of
ON_Curve |
| 13:29.16 |
jdoliner |
I just kinda
missed that until now |
| 13:29.25 |
jdoliner |
since
everything else with Curve in the name is |
| 13:29.40 |
brlcad |
ahhh |
| 13:29.45 |
jdoliner |
there's our
problem |
| 13:30.22 |
jdoliner |
and a long
time ago when I got the compile error on that assignment, I just
coerced it |
| 13:30.26 |
jdoliner |
which was
silly of me |
| 13:30.54 |
jdoliner |
but now that
we know this it turns out nurbscurves are extensions of
ON_Curves |
| 13:32.14 |
brlcad |
ahhh, hehe,
yeah *that*'ll do it |
| 13:32.37 |
brlcad |
hence a
pointer with a value, but not a valid pointer to a class
function |
| 13:32.44 |
jdoliner |
yup |
| 13:34.01 |
jdoliner |
ah but
fortunately, this won't be too hard to fix at all |
| 13:35.20 |
Yoshi47 |
i think i
know the aswer to this, but is there a way to view the geomtery of
just the part you are making and not the cutting shapes and other
stuff like the render view put in line view |
| 13:55.52 |
brlcad |
Yoshi47:
running 'rt' without any options will give you a quick
rendering |
| 13:56.14 |
brlcad |
(in a
window) |
| 13:57.35 |
Yoshi47 |
im talking
more about in mged when im editing and creating parts to see how
they look without doing a render, kinda like what other CAD
programs do, they show you the outline of the part. |
| 13:58.42 |
Yoshi47 |
its still
very hard for me to use brlcad over varicad for drawing up parts,
but i'll try and stick with it. |
| 13:59.55 |
Yoshi47 |
also takes
alot of brain power to type the commands out and learn them, i
guess archer will fix some of this with a more interactive gui when
creating shapes |
| 14:01.02 |
brlcad |
Yoshi47: I
know what you mean, and the current way to get that "shaded view"
is via rt |
| 14:01.11 |
brlcad |
it gets at
the heart of how geometry is represented |
| 14:01.14 |
Yoshi47 |
ha |
| 14:01.24 |
brlcad |
and very much
related to the BREP/NURBS effort |
| 14:01.40 |
Yoshi47 |
so i would
just have another window rt and then i have to update it manauly
everytime i chagne something right |
| 14:01.46 |
brlcad |
it can't show
you edges because there are no edges, at least no explicit
ones |
| 14:01.53 |
Yoshi47 |
yep i get
it |
| 14:02.12 |
brlcad |
archer is
indeed a lot more interactive |
| 14:02.17 |
Yoshi47 |
be nice to
have rt render reatime on a second screen |
| 14:02.29 |
Yoshi47 |
*realtime |
| 14:02.32 |
brlcad |
but there
will always be a strong command-line component for numerical
precision purposes |
| 14:02.52 |
brlcad |
yeah, there's
actually a new display interface that does almost exactly that in
the works |
| 14:03.07 |
Yoshi47 |
oh i get that
part and i like that part over other cad programs its just i have
to relate back to the intro Appendix for the points |
| 14:03.08 |
louipc |
I'd like to
improve the cli first heh |
| 14:03.13 |
brlcad |
runs
wonderfully actually .. and is something you can try but you'll
have to compile from source |
| 14:03.26 |
Yoshi47 |
whats it
called? |
| 14:03.29 |
louipc |
make it more
intuitive, discoverable |
| 14:03.39 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 14:04.04 |
brlcad |
we have a
display manager library (libdm) .. right now you're using either
our "xgl" (i.e., glx) |
| 14:04.32 |
Yoshi47 |
ah, i guess
there is no docs on it or how to setup it up |
| 14:04.33 |
brlcad |
er, "ogl"
(i.e., glx) display manager for X11 or our "X" display
manager |
| 14:04.41 |
brlcad |
it's not a
setup issue |
| 14:04.47 |
brlcad |
it's not an
end-user feature yet |
| 14:05.16 |
Yoshi47 |
umm |
| 14:05.16 |
brlcad |
it's a new
display manager called "rtgl" that renders objects via raytracing
and then feeds point clouds to opengl |
| 14:05.36 |
brlcad |
very
impressive, actually -- working on merging that into mged/archer as
a display mode |
| 14:05.37 |
Yoshi47 |
and it does
that realtime |
| 14:05.41 |
brlcad |
yep |
| 14:05.45 |
Yoshi47 |
cool |
| 14:05.53 |
Yoshi47 |
now i want to
use it! |
| 14:05.55 |
brlcad |
almost
instantly gives you the perception of a solid view |
| 14:06.06 |
Yoshi47 |
ive got goose
bumps |
| 14:06.08 |
brlcad |
and can be
rotated around interactive |
| 14:06.09 |
louipc |
haha yeah how
do we enable it |
| 14:06.14 |
Yoshi47 |
lol |
| 14:06.15 |
brlcad |
--enable-rtgl |
| 14:06.41 |
brlcad |
the issue is
right now it's all or nothing, you replace the x11 wireframe with
that display manager |
| 14:06.55 |
Yoshi47 |
that is a
problem |
| 14:07.03 |
brlcad |
and it's not
well suited to some of the dm tasks yet, like hilighting objects or
interactive editing |
| 14:07.23 |
brlcad |
which is why
it's not turned on, that's a really new feature |
| 14:07.32 |
brlcad |
worked on by
a summer student just this summer |
| 14:07.54 |
brlcad |
i'll see if I
can put up one of his videos later today |
| 14:08.06 |
louipc |
sweet |
| 14:08.30 |
brlcad |
runs off late |
| 14:08.47 |
Yoshi47 |
can you start
up 2 mged and then make both look at the same db |
| 14:09.04 |
Yoshi47 |
i wonder what
hes late for |
| 15:04.54 |
*** join/#brlcad erik____
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 15:07.29 |
brlcad |
Yoshi47: you
can actually start up just one mged and get multiple display
maangers, just type "attach X" in mged and see |
| 15:09.37 |
Yoshi47 |
cool |
| 15:20.19 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DBEF.dip.t-dialin.net) |
| 15:21.10 |
``Erik_ |
´/clear |
| 15:21.14 |
``Erik_ |
heh |
| 15:31.48 |
CIA-28 |
BRL-CAD:
03brlcad * r35783 10/brlcad/trunk/configure.ac: ACLOCAL_AMFLAGS
belongs in Makefile.am, which we already had there. having it here
was invalid shell syntax (make ACLOCAL_AMFLAGS look like a
command). keep the AC_CONFIG_AUX_DIR() though. |
| 15:38.09 |
``Erik |
heh, my bad,
guess I saw a bad example |
| 15:38.27 |
``Erik |
(thought we
had it, couldn't find it in the .ac *shrug* ah well) |
| 15:41.17 |
CIA-28 |
BRL-CAD:
03starseeker * r35784
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: grr. Still
trying to get the nmg->brep stuff to line up. |
| 15:49.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) |
| 16:44.54 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 16:48.32 |
PrezKennedy |
hey brlcad,
ill be working at a big geometric building soon |
| 17:13.25 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 17:41.45 |
brlcad |
PrezKennedy:
what does that mean? |
| 17:42.23 |
Yoshi47 |
im lost
too |
| 17:42.33 |
PrezKennedy |
pentagon |
| 17:42.38 |
brlcad |
ah,
heh |
| 17:43.15 |
brlcad |
I hear you're
going to turn it into a hexagon |
| 17:46.03 |
CIA-28 |
BRL-CAD:
03brlcad * r35785 10/brlcad/trunk/include/conf/ (MINOR PATCH): next
release makes more sense as 7.16 after all. bump revision to 7.15.0
and begin release testing. |
| 17:47.42 |
Yoshi47 |
PrezKennedy,
what you goin to be doing there or is that secret? |
| 17:48.03 |
brlcad |
selling hot
dogs from the back of his trunk |
| 17:48.05 |
PrezKennedy |
...programming |
| 17:48.16 |
PrezKennedy |
hmmm i like
the hot dog idea |
| 17:48.23 |
PrezKennedy |
i can sell
water at the halfway point from the parking lot |
| 17:48.26 |
PrezKennedy |
$5 a
bottle |
| 17:48.30 |
louipc |
hahhah |
| 17:59.11 |
``Erik |
heh, conan
the librarian |
| 18:17.26 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 18:19.34 |
Yoshi47 |
fun |
| 18:34.23 |
*** join/#brlcad talcite
(n=Matthew@206-223-179-178.beanfield.net) |
| 19:13.27 |
CIA-28 |
BRL-CAD:
03brlcad * r35786 10/brlcad/trunk/src/conv/iges/n_iges.cpp:
initialize against the c-string so it's copied. fixes a failure to
parse/find the start header. |
| 19:23.54 |
CIA-28 |
BRL-CAD:
03brlcad * r35787 10/brlcad/trunk/src/conv/iges/ (brlcad.hpp
brlcad_brep.cpp): add standard header/footers. |
| 19:26.24 |
CIA-28 |
BRL-CAD:
03brlcad * r35788 10/brlcad/trunk/src/conv/iges/nmain.cpp: add
standard header/footer. |
| 19:27.36 |
CIA-28 |
BRL-CAD:
03brlcad * r35789 10/brlcad/trunk/src/conv/iges/ (5 files): rename
brlcad.hpp to brlcad_brep.hpp to be consistent with cpp file and
slightly less ambiguous. |
| 19:28.21 |
CIA-28 |
BRL-CAD:
03brlcad * r35790 10/brlcad/trunk/src/conv/iges/ (brlcad_brep.cpp
brlcad_brep.hpp): ws indent cleanup |
| 19:38.21 |
CIA-28 |
BRL-CAD:
03brlcad * r35791 10/brlcad/trunk/src/conv/iges/brlcad_brep.cpp:
prevent crashes when there is no brep to write. |
| 19:47.17 |
CIA-28 |
BRL-CAD:
03brlcad * r35792 10/brlcad/trunk/src/conv/iges/ (Makefile.am
n_iges.hpp n_main.cpp nmain.cpp): rename nmain.cpp to n_main.cpp to
be consistent with the other 'new' iges convert files in
here |
| 19:50.40 |
CIA-28 |
BRL-CAD:
03bob1961 * r35793 10/brlcad/trunk/src/libtclcad/ (Makefile.am
ged_obj.c): Added a png command to suck the images from openGL and
create a png file. The older png has been renamed to pngwf (i.e. it
creates a wireframe image only). Also got rid of most warnings
about unused variables. |
| 19:53.10 |
CIA-28 |
BRL-CAD:
03brlcad * r35794 10/brlcad/trunk/src/conv/iges/ (n_iges.cpp
n_iges.hpp): ws style indent consistency cleanup |
| 19:54.49 |
CIA-28 |
BRL-CAD:
03starseeker * r35795
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Try
reworking some bizarre referencing. |
| 20:08.56 |
CIA-28 |
BRL-CAD:
03starseeker * r35796
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Hmm, u and v
were reversed - swap, and now (at least on OSX) a valid nmg (arb8)
is generated and can be raytraced. |
| 20:37.11 |
CIA-28 |
BRL-CAD:
03starseeker * r35797
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: No time to
figure out the Linux build problems this is causing right now -
comment out guts of function for release, will uncomment again and
fix after tagging. |
| 20:44.01 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) |
| 20:49.56 |
CIA-28 |
BRL-CAD:
03brlcad * r35798 10/brlcad/trunk/src/conv/iges/ (BrepHandler.cpp
brlcad_brep.cpp n_iges.cpp): fix a few crashes trying to read in
RationalBSplineSurface entities, undo some comment
braimage |
| 21:06.44 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14DBEF.dip.t-dialin.net) |
| 21:13.17 |
CIA-28 |
BRL-CAD:
03starseeker * r35799 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
Start roughing out the test csg->brep routines for the other
arbs. |
| 21:20.27 |
CIA-28 |
BRL-CAD:
03brlcad * r35800
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: quell the
warnings and ambiguous conversion errors. the intent is to call it
up as an index, so do that. re-enable for compilation. |
| 21:23.15 |
brlcad |
leaves it as an exercise to the reader to determine whether
that needs to be a long int |
| 21:23.28 |
starseeker |
brlcad:
thanks :-) |
| 21:25.01 |
CIA-28 |
BRL-CAD:
03starseeker * r35801
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Call
SetTrimIsoFlags. ARB4 test case now succeeds. |
| 21:29.17 |
brlcad |
if you read
through the error it gave, and ignore the pointless bitching, you
see that it's ambiguous [] operator, one is a class member that
takes an int, the other is a built-in that takes a long |
| 21:29.39 |
brlcad |
I think the
bitching is the gcc devs saying "we're required to halt on this,
even though it's stupid" |
| 21:30.37 |
brlcad |
related to
the template instantiation, it instantiated a long somewhere, which
probably implies the int-sized one defined by opennurbs is
insufficiently indexed |
| 21:31.24 |
brlcad |
the fix is
trivial, just feed it the int they're expecting |
| 21:33.46 |
CIA-28 |
BRL-CAD:
03brlcad * r35802 10/brlcad/trunk/TODO: refactor tclcad commands
(e.g., png) to libged |
| 21:36.02 |
CIA-28 |
BRL-CAD:
03brlcad * r35803 10/brlcad/trunk/src/conv/iges/BrepHandler.cpp:
add missing header/footer and clean up style/indent. |
| 21:37.25 |
CIA-28 |
BRL-CAD:
03bob1961 * r35804 10/brlcad/trunk/src/libged/human.c: Move
variable declarations to the tops of their respective code blocks
(i.e. make it compile as a C file). |
| 22:10.03 |
*** join/#brlcad Yoshi477
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 03:04.19 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 03:04.19 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks
everyone! |
| 03:46.40 |
*** join/#brlcad talcite
(n=Matthew@bas2-toronto21-1242309983.dsl.bell.ca) |
| 04:43.50 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 04:43.50 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 04:43.50 |
*** join/#brlcad dli (n=dli@69.172.102.119) [NETSPLIT
VICTIM] |
| 04:43.50 |
*** join/#brlcad talcite_
(n=matthew@76-10-171-135.dsl.teksavvy.com) [NETSPLIT
VICTIM] |
| 04:43.50 |
*** join/#brlcad puddingpimp
(n=dave@118-93-244-155.dsl.dyn.ihug.co.nz) [NETSPLIT
VICTIM] |
| 04:43.50 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT
VICTIM] |
| 04:43.50 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 04:43.50 |
*** join/#brlcad bobbens
(i=bobbens@saw4ever.de) |
| 04:43.51 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
| 04:43.51 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 04:44.25 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 04:44.25 |
*** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 04:44.25 |
*** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 04:44.27 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 04:44.27 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 04:44.28 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad talcite
(n=Matthew@bas2-toronto21-1242309983.dsl.bell.ca) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad Yoshi477
(n=jan@d72-39-56-44.home1.cgocable.net) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad kanzure (i=bryan@146.6.84.36) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad CIA-28 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 04:44.30 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 04:45.19 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 04:45.19 |
*** join/#brlcad pacman87_ (n=pacman87@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 04:46.45 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 04:46.45 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 04:46.45 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 04:46.45 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 04:50.00 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 05:52.33 |
*** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 05:52.33 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 05:52.33 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 05:52.33 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 05:52.33 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 05:52.33 |
*** join/#brlcad pacman87_ (n=pacman87@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 05:52.33 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 05:52.33 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 05:52.34 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 05:52.34 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 06:25.39 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 06:25.39 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 06:25.39 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 06:25.39 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 06:26.14 |
*** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 06:26.15 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 06:26.15 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 06:26.15 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 06:26.15 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 06:26.15 |
*** join/#brlcad pacman87_ (n=pacman87@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 06:39.32 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 06:39.32 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 06:39.32 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 06:39.32 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 06:39.32 |
*** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 06:39.32 |
*** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 06:39.32 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 06:39.32 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 06:39.33 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 06:39.33 |
*** join/#brlcad pacman87_ (n=pacman87@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 07:15.13 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 07:23.18 |
*** join/#brlcad FlossLikeYouMean
(n=on_Chatz@ip72-198-41-52.ok.ok.cox.net) |
| 08:49.44 |
*** join/#brlcad talcite
(n=Matthew@bas2-toronto21-1279331838.dsl.bell.ca) |
| 09:46.35 |
*** join/#brlcad talcite__
(n=Matthew@bas2-toronto21-1279331466.dsl.bell.ca) |
| 10:23.51 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 10:27.37 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 10:27.37 |
*** join/#brlcad Yoshi477
(n=jan@d72-39-56-44.home1.cgocable.net) [NETSPLIT
VICTIM] |
| 10:28.06 |
*** join/#brlcad starseeker (n=starseek@bz.bzflag.bz)
[NETSPLIT VICTIM] |
| 10:28.35 |
*** join/#brlcad CIA-28 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 10:28.35 |
*** join/#brlcad kanzure (i=bryan@146.6.84.36) [NETSPLIT
VICTIM] |
| 10:46.39 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 11:30.29 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 12:32.51 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 12:58.51 |
``Erik |
<PROTECTED> |
| 13:00.13 |
Yoshi47 |
cool |
| 13:03.16 |
Yoshi47 |
``Erik, can i
specify this as a x y z on point 3 for an arb6 "0 (.5+(tan19.9x.5))
1.3125" |
| 13:11.32 |
brlcad |
not with that
syntax, but yeah you can |
| 13:14.24 |
``Erik |
if you say "0
[expr .5+tan(19.9)*.5] 1.3125" I think |
| 13:15.13 |
Yoshi47 |
cool got to
remember that |
| 13:15.28 |
``Erik |
(the square
brackets mean "execute this command", expr means "compute this
mathematical expression") |
| 13:16.12 |
Yoshi47 |
ah |
| 13:16.14 |
Yoshi47 |
thanks |
| 13:16.25 |
Yoshi47 |
i'll try it
on my next shape at break time |
| 13:18.22 |
``Erik |
and if you
find yourself doing a series of commands frequently, you can make
them into a single command using "proc {args}
{body}"... |
| 13:18.59 |
Yoshi47 |
i'll have to
figure that one out |
| 13:19.39 |
``Erik |
*shrug* it's
a possible next step for when ya feel ready |
| 13:19.54 |
Yoshi47 |
ya, when i
get bored! lol |
| 14:01.40 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 15:17.24 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 15:56.16 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EBC8.dip.t-dialin.net) |
| 16:36.23 |
brlcad |
also, by
default you'll have to escape the square brackets unless you turn
off tcl eval mode (it's on the menu, or via "set glob_compat_mode
0") |
| 16:37.03 |
brlcad |
and i think
tan takes radians, no? :) |
| 16:40.33 |
``Erik |
hrm, probably
too late for lunch |
| 17:14.21 |
*** join/#brlcad talcite__
(n=Matthew@76.65.12.138) |
| 17:19.30 |
*** join/#brlcad dli (n=dli@69.172.102.119) |
| 17:29.48 |
CIA-28 |
BRL-CAD:
03Banger 07http://brlcad.org *
r1613 10/wiki/User:466_buy_cialis: |
| 17:36.40 |
brlcad |
never too
late for lunch |
| 17:39.48 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:466 buy cialis]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
| 17:39.54 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Banger]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
| 17:45.36 |
CIA-28 |
BRL-CAD:
03bob1961 * r35837 10/brlcad/trunk/src/tclscripts/archer/
(AttrGroupsDisplayUtility.tcl Makefile.am tclIndex): Added a bare
bones utility for grouping and displaying objects by
attribute. |
| 19:15.26 |
CIA-28 |
BRL-CAD:
03bob1961 * r35838 10/brlcad/trunk/src/libfb/fb_generic.c: Changed
IF_RTGL to IF_OGL to expose ogl_interface. |
| 19:19.08 |
CIA-28 |
BRL-CAD:
03bob1961 * r35839 10/brlcad/trunk/src/ (archer/archer.bat
mged/mged.bat util/rtwizard.bat): Update to version
7.15.0 |
| 19:44.13 |
Yoshi47 |
is there a
way to turn off in wire frame mode the color specified in shader, i
have a spacer that is white and it is hidden against my white
background |
| 19:45.49 |
brlcad |
common
problem, there is always some color that won't show up against a
given background color |
| 19:47.32 |
Yoshi47 |
why does the
wireframe take the color from the shader? can we turn that off and
make the wireframe a generic color? or i guess thats not
preferrrable |
| 19:49.05 |
brlcad |
there is a
way to e/draw things up with a specified color, e -C
#/#/# |
| 19:50.25 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 19:51.42 |
brlcad |
in general,
the wireframe color matches because users found it helps identify
and segregate geometry |
| 19:51.50 |
brlcad |
especially as
the model gets more and more complex with hundreds/thousands of
objects |
| 19:51.51 |
Yoshi47 |
ya i
agree |
| 19:52.13 |
Yoshi47 |
just have to
use another color while editing |
| 19:52.16 |
brlcad |
as there are
conventioned color schemes used on some teams to make given systems
a given color for easy identification |
| 19:52.36 |
brlcad |
fuel systems
are always green, engine componenets are always red,
etc |
| 19:52.45 |
Yoshi47 |
ah |
| 19:57.30 |
*** join/#brlcad b0ef
(n=b0ef@084202026157.customer.alfanett.no) |
| 20:05.13 |
CIA-28 |
BRL-CAD:
03brlcad * r35840 10/brlcad/trunk/src/librt/CMakeLists.txt: typo,
should be arbn not arb8 |
| 20:26.16 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 20:38.08 |
CIA-28 |
BRL-CAD:
03bob1961 * r35841 10/brlcad/trunk/src/ (3 files in 3 dirs): Expose
bot_flip and bot_sync to Archer. |
| 21:09.12 |
CIA-28 |
BRL-CAD:
03starseeker * r35842 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
Whooops - free the NMG model explicitly created in csgbrep. Also,
get set up for rhc testing. |
| 21:39.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 22:13.23 |
``Erik |
ahhh |
| 22:27.49 |
``Erik |
I'm... to
sexy for my shirt... to sexy for my shirt... |
| 22:28.04 |
Yoshi477 |
are you
watching that... |
| 22:28.13 |
``Erik |
no, just got
the urge to say that |
| 22:28.21 |
Yoshi477 |
lol |
| 22:28.32 |
``Erik |
<-- is all
sorts of messed up in the head |
| 22:32.00 |
``Erik |
my dance was
too sexy for him |
| 22:32.02 |
``Erik |
on the
catwalk |
| 22:33.27 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 22:53.58 |
``Erik |
hates doing gui work |
| 22:55.23 |
``Erik |
hum, xcode
has cocoa stuff for python and ruby now O.o I don't recall adding
any packages to support those... neat |
| 23:00.22 |
``Erik |
somewhat
annoying, the brown book is good for xcode 2.x, the websites are
all about xcode3.x, and they're fairly different |
| 23:04.09 |
Yoshi477 |
Warning:
region unioned into region at '/xslide.c/xslide_holddown_2.r',
lower region info ignored |
| 23:04.10 |
Yoshi477 |
Warning:
region unioned into region at
'/xslide.c/xslide_holddown_2.r/washer_M8_.8.r', lower region info
ignored |
| 23:04.19 |
Yoshi477 |
why am i
getting that? |
| 23:09.49 |
Yoshi477 |
is that cuase
i should add a region to a region but instead use comb |
| 23:11.31 |
``Erik |
a region
represents a physical object, if you follow the path down the tree,
you should only ever see one region flag |
| 23:11.46 |
``Erik |
below the
region is abstract shape data, so use combinations |
| 23:11.58 |
``Erik |
above the
region is a group of physical objects, so use assembly or
part |
| 23:12.01 |
Yoshi477 |
i thought so,
ok i guess i got to redo my tree structure |
| 23:12.40 |
``Erik |
the warnings
are "you're doing something bad... we'll let you do it, but
understand, it's bad." |
| 23:13.33 |
``Erik |
if, say, I
have a big complex model with all the right materials and shaders,
but I wanted to just turn it all glass or something to see through
it, I could add it to a region with the glass shader to over-ride
all the material information below, but that's... cheating the
system :D |
| 23:14.00 |
``Erik |
"Here's a
shotgun. We recommend you do not shoot it at your foot, but won't
stop you." |
| 23:14.33 |
Yoshi477 |
i like
it |
| 23:14.41 |
Yoshi477 |
but i'll obey
the rules Sir |
| 23:14.54 |
``Erik |
shooting
shotguns at your feet? *shrug* whatever makes ya happy, I spoze
:D |
| 23:15.29 |
Yoshi477 |
what if i
didn't have feet would you feel bad? |
| 23:15.46 |
``Erik |
not really,
no |
| 23:15.55 |
``Erik |
:D |
| 23:15.59 |
Yoshi477 |
lol |
| 23:16.11 |
``Erik |
probably just
means that someone had entrusted you with a shotgun at some point
in the past |
| 23:16.14 |
``Erik |
:> |
| 23:16.54 |
``Erik |
(fairly sure
there're pics of you standing in your gallery, so'z I'm guessing no
one has felt the urge to hand you a firearm) |
| 23:16.57 |
``Erik |
;0 |
| 23:17.00 |
``Erik |
:) |
| 23:19.19 |
Yoshi477 |
could have
fakies |
| 23:19.35 |
Yoshi477 |
so you looked
through my gallery did ya |
| 23:20.57 |
``Erik |
a
little |
| 23:21.52 |
Yoshi477 |
so no
comments you would like to spill out? |
| 23:22.35 |
``Erik |
nope, busy
getting my dinner here |
| 23:23.12 |
``Erik |
ah, you have
uploaded to 'more', cool |
| 23:23.58 |
Yoshi477 |
huh? |
| 23:24.13 |
``Erik |
http://more.brlcad.org has a
bearing.g |
| 23:24.28 |
Yoshi477 |
oh ya my tiny
bearing |
| 23:24.33 |
``Erik |
yuh oh,
bldg391 is most definitely not bldg391, unless 391 is the "big blue
room" |
| 23:25.54 |
``Erik |
looks in a mirror and says "brlcad" 3 times in a row to make
him appear and fix this |
| 23:25.59 |
brlcad |
heh |
| 23:26.13 |
``Erik |
damn |
| 23:26.21 |
``Erik |
"biggie
smalls... biggie smalls... bi... uh..." |
| 23:26.32 |
louipc |
yeah how do
you render the view from inside the sphere? |
| 23:26.53 |
``Erik |
ah, wait,
that might actually be bldg391, but rendered outside,
yes |
| 23:27.00 |
brlcad |
it
is |
| 23:27.04 |
Yoshi477 |
im
lost |
| 23:27.12 |
louipc |
maybe you
just need to cut away the half you don't want? |
| 23:27.13 |
``Erik |
thought it
was the planet we have |
| 23:27.38 |
brlcad |
bldg391 has
19 top-level objects, the one rendered on the site looks like all.g
which includes a sky sphere |
| 23:28.04 |
``Erik |
annotate the
skysphere, and have the raytracer see that annotation and make sure
the viewpoint is inside of the skysphere? |
| 23:28.16 |
``Erik |
does asc
support attributes? |
| 23:28.49 |
brlcad |
just have to
make sure the eye is inside |
| 23:28.53 |
brlcad |
it's already
a "shell" |
| 23:28.57 |
brlcad |
not a solid
sphere |
| 23:29.31 |
brlcad |
v5 asc
definitely supports attributes, don't recall if that was added to
v4 asc |
| 23:30.01 |
``Erik |
given that v4
was deprecated over a decade ago and we're close to v6, ... I
frankly don't care :D |
| 23:31.01 |
``Erik |
I wouldn't
mind if _export5() was renamed to export() and the old v4 loader
was all moved into dbupgrade, myself O:-) |
| 23:31.32 |
``Erik |
doesn't see any v3 loader code *shrug* |
| 23:34.06 |
brlcad |
go for it
:) |
| 23:34.22 |
brlcad |
all the *5()
stuff should be s/5// |
| 23:35.25 |
Yoshi477 |
can someone
take a look at this and tell me im doing it wrong cause my head is
fried, http://ej.nijenhuis.pixi.me/v/CAD/xslide_g.html |
| 23:35.50 |
Yoshi477 |
B
xslide.c |
| 23:36.24 |
``Erik |
pasting a url
to a wrapper page instead of directly to the .g file == wrong
:D |
| 23:36.36 |
Yoshi477 |
you want the
direct link |
| 23:36.47 |
Yoshi477 |
http://ej.nijenhuis.pixi.me/d/2439-1/xslide_g?g2_GALLERYSID=8d870d26847034d67e6a9b58f984d434 |
| 23:37.03 |
Yoshi477 |
there fixed
one of my mistakes |
| 23:37.05 |
``Erik |
not so great
to 'fetch' or 'wget' :) |
| 23:37.23 |
Yoshi477 |
oh right i'll
keep it in mind for the next time |
| 23:38.16 |
brlcad |
xslide.c
shouldn't be a region |
| 23:38.26 |
Yoshi477 |
isn't it a
comb |
| 23:38.32 |
brlcad |
regions are
combinations |
| 23:38.38 |
brlcad |
but
combinations are not necessarily regions |
| 23:39.06 |
Yoshi477 |
oh
analyze |
| 23:39.16 |
brlcad |
think of a
region as a homogenous "part" like you'd have in other cad
systems |
| 23:39.25 |
brlcad |
you don't put
parts into parts, that's what assemblies are for |
| 23:40.12 |
Yoshi477 |
and comb is
used to make an assembly right? |
| 23:40.14 |
``Erik |
'comb' is the
most general form |
| 23:40.18 |
brlcad |
you have the
right idea that naming-convention-wise, it's good to name your
regions .r and your non-regions .c |
| 23:40.32 |
Yoshi477 |
so all i have
to do is change xslide.c into a comb |
| 23:40.37 |
``Erik |
should parts
and assemblies be .c ? |
| 23:40.45 |
brlcad |
right, you
want to unset the region bit on it |
| 23:40.47 |
Yoshi477 |
comb is the
most general form? there more? |
| 23:40.58 |
Yoshi477 |
and how may i
pretell do that? |
| 23:41.24 |
brlcad |
adjust
xslide.c region no |
| 23:41.43 |
``Erik |
(the
combination editor has a checkbox for that) |
| 23:41.46 |
``Erik |
iirc |
| 23:41.59 |
Yoshi477 |
oh
there |
| 23:42.02 |
Yoshi477 |
lol |
| 23:42.16 |
Yoshi477 |
so about the
advance assemblies? |
| 23:42.35 |
brlcad |
so if you
"tree xslide.c", you'll see a /R after all the objects that are
regions |
| 23:43.02 |
brlcad |
and at a
glance, it looks like the rest are okay |
| 23:43.16 |
Yoshi477 |
ya i analyzed
them and it looks good to me |
| 23:43.35 |
brlcad |
looks like
you might have a few paths that have no regions |
| 23:43.35 |
Yoshi477 |
im starting
to like brlcad, lol |
| 23:43.48 |
``Erik |
might wanna
beat it with g_qa and g_lint |
| 23:43.59 |
Yoshi477 |
``Erik, you
lost me |
| 23:44.07 |
Yoshi477 |
brlcad,
paths? |
| 23:44.13 |
``Erik |
they're
programs, they look over your geometry to see if things are
reasonably sane |
| 23:44.22 |
brlcad |
Yoshi477: run
"rtcheck" and wait a few seconds |
| 23:44.32 |
``Erik |
automated
tools to do what you're asking us to do for you :D |
| 23:45.01 |
brlcad |
then spin the
model a little, you'll see yellow lines where you have
overlaps |
| 23:45.12 |
brlcad |
looks like
you have bolts overlapping bolts |
| 23:45.14 |
Yoshi477 |
ah |
| 23:45.18 |
Yoshi477 |
really |
| 23:45.21 |
Yoshi477 |
were? |
| 23:45.26 |
Yoshi477 |
i'll
look |
| 23:46.01 |
brlcad |
17 unique
overlapping objects detected |
| 23:46.07 |
``Erik |
thinks he will do the 4/5 brutality tomorrow
morning |
| 23:46.26 |
Yoshi477 |
0h i think i
got a couple extra parts in there, i'll go through the tree and
correct |
| 23:46.30 |
Yoshi477 |
thanks for
your help |
| 23:46.38 |
``Erik |
and bring in
my brown book so I have a reason to disappear when the pitchforks
and torches are handed out O.o |
| 23:46.40 |
Yoshi477 |
whats 4/5
brutality? |
| 23:47.00 |
``Erik |
yoshi: ugly
internal stuff that you should never notice as a 'mere mortal'
user |
| 23:47.17 |
Yoshi477 |
ok
good |
| 23:47.35 |
``Erik |
(if anyone
other than a low level developer realizes something changed, then I
screwed up) :D |
| 23:48.00 |
brlcad |
it's where he
gets brutally sodomized by only 4 out of 5 |
| 23:48.19 |
``Erik |
4 out of 5
sodomizers agree that ... |
| 23:50.26 |
``Erik |
http://www.youtube.com/watch?v=BTW9aHf--co
hehehe |
| 23:50.36 |
brlcad |
wow, gqa's
overlap reporting sucks compared to rtcheck |
| 23:50.49 |
``Erik |
g_qa has many
deficiencies |
| 23:51.11 |
``Erik |
:/ |
| 23:51.14 |
brlcad |
has the same
duplicate reporting bug I fixed in rtcheck like 6 years
ago |
| 23:51.27 |
``Erik |
heh |
| 23:51.47 |
brlcad |
uselessly
reports about 1000 overlaps on those 17 unique objects |
| 23:52.39 |
``Erik |
I'll hold him
down while ya punch the crap out of him for that? :D |
| 23:53.32 |
Yoshi477 |
im only a
newbie, lol |
| 23:54.08 |
``Erik |
yoshi: I
meant the author of g_qa, he works a couple buildings over from
brlcad and me :) |
| 23:54.43 |
CIA-28 |
BRL-CAD:
03brlcad * r35843 10/brlcad/trunk/TODO: make gqa overlap reporting
suck less. |
| 23:54.52 |
Yoshi477 |
oh |
| 23:55.03 |
brlcad |
Yoshi477:
yeah, the overlaps are pretty much expected from newbie
modelers |
| 23:55.10 |
Yoshi477 |
well i do
deserver a beating for screwing up, |
| 23:55.22 |
``Erik |
nah, part of
the learning curve |
| 23:55.30 |
Yoshi477 |
overlaps most
likely in my case means i multiple parts in the same area
right? |
| 23:55.36 |
``Erik |
yes |
| 23:55.37 |
brlcad |
there's a
"new" tool that does a better job at reporting them.. but it's teh
suck in terms of how it reports them out |
| 23:55.50 |
Yoshi477 |
ah |
| 23:55.58 |
``Erik |
two regions
occupying the same physical space, it doesn't make sense
physically |
| 23:57.08 |
``Erik |
but it's a
common modelling error, either from bad or careless definition of
geometry, from slop in tesselation, or *shrug* whatever
else... |
| 23:58.22 |
``Erik |
(for example,
I have an imported model from actual production, a removable item
actually physically occupies the same space as the clip designed to
hold it... and this is from the gurus... it happens, don't sweat
it, just understand what it is :) |
| 23:59.35 |
brlcad |
Yoshi477: it
might help to work with objects by themselves at the region level,
resolve any problems there, then go to the parent combination and
resolve issues there and so on |
| 23:59.42 |
Yoshi477 |
ah, man would
it be a field trip to spend a day watching you guys. |
| 23:59.57 |
``Erik |
yes, my
webcomic reading is legendary. |
| 23:59.58 |
Yoshi477 |
brlcad,
currently doing that |
| 00:00.12 |
Yoshi477 |
xkcd? |
| 00:00.12 |
``Erik |
on the
list |
| 00:00.12 |
Yoshi477 |
nice |
| 00:00.13 |
brlcad |
for example,
if I walk down your object hierarchy, I see xslide_main.r in
xslide.c |
| 00:00.19 |
Yoshi477 |
pretty bad
one wednesday though |
| 00:00.22 |
``Erik |
http://brlcad.org/~erik/comics/comic.php?nsfw=2 |
| 00:00.32 |
``Erik |
the 'tgi
fridays' one? |
| 00:00.33 |
brlcad |
in
xslide_main.r, I see an unexpected duplicately listed object
name |
| 00:00.40 |
Yoshi477 |
yeah |
| 00:00.45 |
``Erik |
I wasn't
amused by it :/ |
| 00:00.51 |
brlcad |
whether
intentional or not depends on your intent, but I'm betting it's a
modeling mistake |
| 00:00.52 |
``Erik |
I'm guessing
I didn't get the joke |
| 00:01.16 |
Yoshi477 |
hover mouse
over graphic? you know of? |
| 00:01.19 |
``Erik |
randall
doesn't bomb often at all |
| 00:03.58 |
Yoshi477 |
brlcad, in
xslide_holddown_1.c i have to - the flathead_M8x50.c in order to
get rid of the overlaps? |
| 00:04.09 |
Yoshi477 |
makes sense i
guess |
| 00:04.17 |
Yoshi477 |
i have to
drill holes... |
| 00:04.39 |
Yoshi477 |
thats what i
didn't do is drill holes so the bolts are causing the
overlaps |
| 00:05.15 |
``Erik |
when you
actually seat a bolt in new metal, you have to drill it out...
either to the outer diameter, or to the inner diameter and tap
it... |
| 00:05.37 |
Yoshi477 |
yep that did
it |
| 00:05.48 |
Yoshi477 |
funny
mistake |
| 00:06.55 |
CIA-28 |
BRL-CAD:
03brlcad * r35844 10/brlcad/trunk/BUGS: aha, isolated yet another
text-widget bug in the command window. mac specific
binding. |
| 00:09.40 |
brlcad |
Yoshi477: so
now if you think about paths to regions, note that your bolt is not
actually a region |
| 00:09.44 |
Yoshi477 |
if i added
this u xslide_main.s |
| 00:09.44 |
Yoshi477 |
<PROTECTED> |
| 00:09.44 |
Yoshi477 |
<PROTECTED> |
| 00:09.44 |
Yoshi477 |
<PROTECTED> |
| 00:09.44 |
Yoshi477 |
<PROTECTED> |
| 00:09.45 |
Yoshi477 |
<PROTECTED> |
| 00:09.47 |
Yoshi477 |
<PROTECTED> |
| 00:09.49 |
Yoshi477 |
<PROTECTED> |
| 00:09.51 |
Yoshi477 |
<PROTECTED> |
| 00:09.53 |
Yoshi477 |
<PROTECTED> |
| 00:09.58 |
Yoshi477 |
the last 4
lines |
| 00:10.09 |
Yoshi477 |
that would
tap them |
| 00:10.50 |
brlcad |
normally you
only want to subtract the *shapes* and not entire regions or
combinations |
| 00:10.57 |
brlcad |
er,
assemblies |
| 00:11.10 |
brlcad |
subtract the
*shapes" and not entire regions or assemblies |
| 00:11.31 |
brlcad |
so before
jumping off, go back to your xslide_holddown_1.c
combination |
| 00:11.47 |
Yoshi477 |
then i have
to copy the bolt and reposition it in all places? |
| 00:12.11 |
Yoshi477 |
yep im
back |
| 00:13.51 |
brlcad |
so in that
object, the first one referenced is xslide_holddown.r, which looks
good to me .. it's just a bunch of primitives under it |
| 00:13.59 |
Yoshi477 |
yep |
| 00:14.06 |
brlcad |
and that
object is a region, seems okay so far |
| 00:14.32 |
Yoshi477 |
i changed the
slide_holddown.r to have a - that bolt |
| 00:14.32 |
brlcad |
next object
is flathead_M8x50.c |
| 00:14.50 |
brlcad |
so -
flathead? |
| 00:14.53 |
Yoshi477 |
yep |
| 00:15.24 |
brlcad |
okay, that's
all good, then the next issue there then is that flathead_M8x50.c
is a non-region combination |
| 00:15.30 |
brlcad |
which is
perfect for subtraction |
| 00:15.40 |
brlcad |
but you want
a region to actually instantiate a bolt |
| 00:16.01 |
Yoshi477 |
change the
bolt to a region? |
| 00:16.02 |
brlcad |
so you should
make a flathead region that just has one union for
flathead_M8x50.c |
| 00:16.05 |
Yoshi477 |
becuase its a
part? |
| 00:16.08 |
brlcad |
no |
| 00:16.13 |
brlcad |
yes and
no |
| 00:16.20 |
brlcad |
no because
you're subtracting it somewhere as a shape |
| 00:16.25 |
brlcad |
and you
should avoid subtracting regions |
| 00:16.39 |
Yoshi477 |
ah |
| 00:16.41 |
brlcad |
so just make
a new region combination that just has that one .c
combination |
| 00:17.12 |
brlcad |
use that
instead of the .c in xslide_holddown_1.c |
| 00:17.48 |
brlcad |
your last
object (the bearings) look fine |
| 00:17.53 |
Yoshi477 |
so r
flathead_M8x50.r u flathead_M8x50.c |
| 00:17.59 |
brlcad |
yeah |
| 00:18.14 |
Yoshi477 |
ok
down |
| 00:18.15 |
brlcad |
then change
xslide_holddown_1.c to refer to the .r instead of the
.c |
| 00:18.19 |
Yoshi477 |
done* |
| 00:18.42 |
brlcad |
that way, the
"shape" is used in the subtraction (good) and the region is used in
the assembly (great) |
| 00:18.50 |
Yoshi477 |
ah |
| 00:19.02 |
Yoshi477 |
so what about
the holddownbearingasm |
| 00:19.05 |
brlcad |
not having it
be a region is technically a modeling error |
| 00:19.40 |
brlcad |
if you had
INSTEAD made it a region and just renamed it to .r, that would have
also worked and been fine for the assembly, but really bad practice
for the subraction |
| 00:19.59 |
Yoshi477 |
ok that makes
sense kinda |
| 00:20.57 |
brlcad |
holddownbearingasm_1.c is apparently an
assembly/group that refers to two objects -- another assembly/group
(bearing_*.c) and a region (spacer*.r) |
| 00:21.07 |
Yoshi477 |
yep |
| 00:21.07 |
brlcad |
that
bearing*.c has two regions in it, so you're good |
| 00:21.10 |
Yoshi477 |
and a bolt to
come |
| 00:21.15 |
brlcad |
positive
regions all the way down |
| 00:21.29 |
brlcad |
no
overlaps |
| 00:21.32 |
Yoshi477 |
nope |
| 00:21.38 |
Yoshi477 |
rtcheck came
out 0 |
| 00:22.13 |
brlcad |
and there you
can really see, if you run "tree" |
| 00:22.23 |
brlcad |
there is just
one region for any walk down that hierarchy |
| 00:22.53 |
brlcad |
no
subtractions happening ABOVE the regions, also good |
| 00:23.22 |
Yoshi477 |
ok |
| 00:25.31 |
Yoshi477 |
whats the
best way to subtract the flat bolts from xslide_main.r do i have to
duplicate the flat*.c where i want the holes? |
| 00:27.34 |
Yoshi477 |
i also had an
extra xslide_main.s in there |
| 00:28.32 |
brlcad |
yep, saw the
extra |
| 00:28.55 |
brlcad |
you don't
have to duplicate flat*.c |
| 00:29.01 |
Yoshi477 |
when i get
rid of it the hex bolts aren't overlapping with the main
now? |
| 00:29.02 |
brlcad |
it's a
shape |
| 00:29.21 |
brlcad |
so you can
just keep subtracting that same shape where you want |
| 00:29.31 |
brlcad |
you'll just
apply a translation on each one being subtracted to put them into
place |
| 00:29.52 |
Yoshi477 |
ok i got to
think for a sec |
| 00:30.47 |
Yoshi477 |
so since i
have to do that i mine as well create a rcc since that won't be
tapped any ways and then make 2 rcc and sub them from
main |
| 00:31.09 |
brlcad |
you can make
combs for each subtraction that just has one u flat*.c and then
move each comb into place, or use clone to make all N of them at
once |
| 00:31.34 |
brlcad |
what you said
should work too |
| 00:31.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 00:31.52 |
brlcad |
subtracted
shapes that are simpler are better anyways |
| 00:31.53 |
Yoshi477 |
i mine as
well drill them out since thats what im going to do in real
life |
| 00:32.06 |
Yoshi477 |
yep less
code |
| 00:32.27 |
brlcad |
have it
exactly subtracted would be a "tight fit" and generally make
serious hell to the tessellator on export |
| 00:32.47 |
Yoshi477 |
i'll make it
a thou bigger |
| 00:33.12 |
Yoshi477 |
im not going
to export anyways |
| 00:33.18 |
Yoshi477 |
but its good
to know |
| 00:34.01 |
brlcad |
"perfect"
fits can also cause rendering problems for some obscure cases like
the subtle dots on your bearing |
| 00:34.12 |
Yoshi477 |
ah |
| 00:34.14 |
Yoshi477 |
ok |
| 00:34.33 |
brlcad |
as the
hardware can't calculate perfectly, and it's not physically
accurate regardless |
| 00:34.55 |
brlcad |
even two
sheets of paper on top of each other have a little bit of "air"
between them |
| 00:35.52 |
Yoshi477 |
yep |
| 00:36.08 |
brlcad |
unless it's
something chemically bonded or welded, there's a gap, so good to
capture that with a minute tolerance |
| 00:36.29 |
brlcad |
our default
calculation tolerance is 0.0005mm |
| 00:36.39 |
brlcad |
which is
practical only to about 1/1000th of a mm |
| 00:36.54 |
brlcad |
closer to
1/100 of a mm for some operations |
| 00:37.05 |
Yoshi477 |
cool |
| 00:45.38 |
Yoshi477 |
so i can just
subtract this thread_8_30_1.25_0.67625_24.c from xslide_main.r for
my taps? |
| 00:49.39 |
Yoshi477 |
can i say
this in the comb editor - thread_8_30_1.25_0.67625_24.c rot 90 0 0
tra .5 1 3 ? |
| 00:49.49 |
Yoshi477 |
or how does
that work |
| 01:22.57 |
Yoshi477 |
off to bed
cya |
| 01:30.15 |
brlcad |
a good
practice would be to make something like: g thread_hole_0.c
thread_8_30_1.25_0.67625_24.c |
| 01:31.08 |
brlcad |
then subtract
the thread_hole_0.c from xslide_main.r, comb xslide_main.r -
thread_hole0.c |
| 01:31.39 |
brlcad |
apply a
matrix edit: oed /xslide_main.r
thread_hole0.c/path/to/primitive |
| 01:31.45 |
brlcad |
rot 90 0
0 |
| 01:31.49 |
brlcad |
tra .5 1
3 |
| 01:31.51 |
brlcad |
accept |
| 01:32.03 |
brlcad |
cp
thread_hole0.c thread_hole1.c |
| 01:32.24 |
brlcad |
comb
xslide_main.r - thread_hole1.c |
| 01:32.38 |
brlcad |
oed
/xslide_main.r thread_hole1.c/path/to/prim |
| 01:32.42 |
brlcad |
..
etc |
| 01:33.07 |
brlcad |
or make the
pattern with clone, put them into a comb, subtract that
comb |
| 01:40.25 |
CIA-28 |
BRL-CAD:
03brlcad * r35845 10/brlcad/trunk/src/liboptical/shade.c: sanity
check for non-null shadework structure |
| 01:44.21 |
CIA-28 |
BRL-CAD:
03brlcad * r35846 10/brlcad/trunk/src/liboptical/shade.c: minor
style ws consistency cleanup |
| 01:44.22 |
starseeker |
growls in frustration... why isn't csgbrep happy on
gentoo???? |
| 01:44.52 |
starseeker |
Writing an
ARB4 (via NMG) brep... |
| 01:44.52 |
starseeker |
m_object_table[0].m_object->IsValid() =
false. |
| 01:44.52 |
starseeker |
<PROTECTED> |
| 01:44.52 |
starseeker |
<PROTECTED> |
| 01:44.59 |
starseeker |
fails
immediately |
| 01:45.12 |
starseeker |
must still have some stuff not being freed
correctly... |
| 01:47.34 |
CIA-28 |
BRL-CAD:
03brlcad * r35847 10/brlcad/trunk/src/liboptical/shade.c: odd func
escaped de-k&nrification |
| 01:57.14 |
``Erik |
*readreadread* is there any preference for
a single big unioned cutter vs a bunch of simple cutters? mebbe
with nmg conversion? |
| 02:06.25 |
CIA-28 |
BRL-CAD:
03brlcad * r35848 10/brlcad/trunk/include/raytrace.h: make sure the
functab methods are non-null before calling them. ran into ft_uv
nullity during rt -k shot. |
| 02:18.50 |
starseeker |
hrm. even a
single arb4 fails... |
| 02:33.57 |
*** join/#brlcad talcite
(n=Matthew@d24-141-28-249.home.cgocable.net) |
| 02:37.13 |
talcite |
hey guys.
What's the tool to use for signal processing? |
| 02:57.53 |
*** join/#brlcad dli (n=dli@69.172.102.119) |
| 03:24.28 |
*** join/#brlcad dli (n=dli@69.172.102.119) |
| 08:55.37 |
brlcad |
talcite_:
depends what you need, there are lots of them that do different
things |
| 10:46.01 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 10:46.01 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 10:46.01 |
*** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT
VICTIM] |
| 10:54.05 |
d-lo |
brlcad: I
dunno which building to go to this morning! |
| 11:11.24 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 11:24.04 |
*** join/#brlcad Yoshi477
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 11:32.44 |
d-lo |
lol. Quote
from the interwebs: Today, I decided that I want to be a ninja
when I grow up. I Googled "Ninja School" to see where I can be
professionally trained in the art. I followed a link that said
Ninja School, and the page could not be found. Well played Ninja
School. You really are a professional. |
| 11:43.29 |
Yoshi47 |
lol |
| 13:24.15 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 13:30.10 |
*** join/#brlcad BigAToo
(n=BigAToo@208.95.141.189) |
| 14:39.36 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 14:59.22 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 15:14.41 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 15:15.35 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 15:22.59 |
*** join/#brlcad _clock_
(n=_sushi_@80.218.244.105) |
| 15:48.10 |
CIA-28 |
BRL-CAD:
03bob1961 * r35849 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c):
No longer enabling two sided lighting. |
| 16:18.57 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 17:15.47 |
``Erik |
*nap* |
| 17:51.01 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 18:12.44 |
*** join/#brlcad dli (n=dli@69.172.102.119) |
| 18:13.23 |
*** join/#brlcad pombreda
(n=pombreda@h-68-165-170-102.snvacaid.dynamic.covad.net) |
| 18:14.09 |
pombreda |
howdy
:-) |
| 18:14.09 |
pombreda |
is there some
way to convert SLDASM and SLDPRT SolidWorks files to
BRL-CAD? |
| 18:21.50 |
pombreda |
http://brlcad.org/w/images/6/66/Converting_Geometry.pdf
seems to provide some clue and http://brlcad.org/~sean/ideas.html
lets me think that there is no support yet. |
| 18:21.57 |
pombreda |
correct? |
| 18:24.57 |
pombreda |
well I'll
come back later... need to run away like a bandit. shoot, the
channel does not seemed logged |
| 18:25.04 |
pombreda |
is there a
log? |
| 18:27.20 |
pombreda |
bbl
:) |
| 19:31.24 |
*** join/#brlcad pombreda
(n=pombreda@dev.nexb.us) |
| 19:31.34 |
kanzure |
Does anyone
know of an open source assembly planner? |
| 19:32.20 |
pombreda |
back :-) ...
any answer to "(11:14:03) pombreda: is there some way to convert
SLDASM and SLDPRT SolidWorks files to BRL-CAD?" ? |
| 19:33.20 |
kanzure |
use
solidworks to export to a reasonable format |
| 19:42.10 |
pombreda |
kanzure: thx
:-) I am such a noob ! |
| 19:45.27 |
kanzure |
are
you? |
| 19:46.33 |
pombreda |
kanzure: I
sure am :- |
| 19:46.56 |
pombreda |
kanzure: at
least when it comes to cad and 3d modelling ;-) |
| 19:47.20 |
pombreda |
kanzure: what
would that reasonable format be? |
| 19:51.07 |
kanzure |
step,
iges |
| 19:52.53 |
pombreda |
curtsies to kanzure |
| 19:52.57 |
pombreda |
much
thx |
| 19:53.36 |
brlcad |
hello
pombreda and yes, you are correct that there is not yet support for
native solidworks files |
| 19:53.44 |
brlcad |
but there is
support for various formats that solidworks exports |
| 19:54.00 |
brlcad |
~logs |
| 19:54.01 |
ibot |
All
conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
| 19:54.29 |
pombreda |
brlcad:
awesome |
| 19:56.54 |
louipc |
<PROTECTED> |
| 20:10.27 |
pombreda |
brlcad: it
would be good to have publi info about the log: http://ibot.rikers.org/#brlcad |
| 20:10.59 |
pombreda |
first some
people do not like being loggedd, so it is usually cool to put a
chanserv msg about the logging when someone enters |
| 20:11.14 |
pombreda |
and second
this is mighty useful :-) |
| 20:12.34 |
*** topic/#brlcad by pombreda -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks everyone! || log at
http://ibot.rikers.org/#brlcad |
| 20:13.00 |
pombreda |
brlcad: done
in the topic, if that works for you: that shoud be good enough
:-) |
| 21:07.44 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 21:26.14 |
CIA-28 |
BRL-CAD:
03starseeker * r35850
10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Update
comments. |
| 21:38.02 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 21:39.23 |
CIA-28 |
BRL-CAD:
03starseeker * r35851 10/brlcad/trunk/ (5 files in 4 dirs): Add
initial work on rhc->brep |
| 21:42.33 |
Yoshi477 |
what the
status on BREP in brlcad, how much of it is there? |
| 21:43.01 |
brlcad |
64.7% |
| 21:43.13 |
Yoshi477 |
nice |
| 21:43.35 |
Yoshi477 |
is that a
real number? |
| 21:44.32 |
brlcad |
pombreda:
it's in the topic from time to time, and I'm not at all really
concerned about folks that don't like being logged |
| 21:44.40 |
``Erik |
yes, it's
even rational |
| 21:44.49 |
pombreda |
brlcad:
:-) |
| 21:45.10 |
brlcad |
people need
to get over it, anyone in a channel could be logging you at any
time and posting their log somewhere with/without your
permission |
| 21:45.15 |
brlcad |
it's
effectively a public space |
| 21:45.44 |
brlcad |
fails the
reasonable expectation of privacy test |
| 21:46.46 |
brlcad |
Yoshi477: of
course it is a real number. cuarytoteen would be a fake
number. |
| 21:47.23 |
Yoshi477 |
ok is that a
number you pulled from you project planner? |
| 21:48.48 |
``Erik |
had no idea that brlcad's ass was the project planner O.o
suddenly want on a different project :D *duck* |
| 21:50.00 |
brlcad |
Yoshi477:
easiest to say that raytracing is pretty much complete (which was
the hardest problem), leaving tessellation, format conversion, and
import/export |
| 21:50.17 |
brlcad |
ah, and
editing eventually, but that's not even being considered at the
moment |
| 21:51.01 |
brlcad |
all three of
those (tess, conversion, and import/export via step) are being
worked actively now |
| 21:51.24 |
Yoshi477 |
i guess i
don't know the full meaning of brep then, am i using it right now?
i thought i was only using CSG |
| 21:54.49 |
louipc |
brlcad: so
you wouldn't be annoyed if you found out that a conversation you
had in a park was secretly taped? |
| 21:55.38 |
brlcad |
technically,
the wireframe representation is a form of unevaluated brep, just
not a very useful one |
| 21:55.49 |
brlcad |
but no,
you're not using it |
| 21:55.54 |
Yoshi477 |
ah |
| 21:56.05 |
Yoshi477 |
so, next
release? |
| 21:56.10 |
Yoshi477 |
example? |
| 21:56.52 |
brlcad |
louipc: not
particularly |
| 21:58.00 |
brlcad |
not to say
I'd be happy about it, but I have little to no basis to assume I'm
not being taped |
| 21:58.16 |
brlcad |
(by an
individual, I'd be furious if it was a government agency at any
level) |
| 21:58.27 |
louipc |
heheh |
| 21:58.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-133.sbndin.btas.verizon.net) |
| 21:59.48 |
louipc |
hah the gov
will eavesdrop on private spaces |
| 21:59.50 |
brlcad |
it's just
like having one's picture taken in public .. you don't have to like
it but you also have no claim to not be photographed |
| 22:02.03 |
brlcad |
that's pretty
universal at least under US law and at least for non-exploitative
use, even extending to photography of children for example (there's
a photography "bill of rights" that covers most of these points
regarding imagery at least) |
| 22:03.28 |
louipc |
doesn't mean
you'll enjoy being followed around by cameras |
| 22:04.51 |
brlcad |
sure, just
nothing you can do about it (when you're in public) |
| 22:05.46 |
brlcad |
to the point
here, though, I always laugh when I hear someone say they're
concerned about logging on *IRC* of all things .. where most people
are logging whether they know it or not |
| 22:06.21 |
brlcad |
i have almost
every message logged that I've ever written or seen on irc covering
like a decade or more of chatter |
| 22:07.55 |
brlcad |
insecure
network with untrustable clients with automatic logging for most of
them on what are generally considered public channels, and they
have a problem being logged .. hilarious :) |
| 22:08.48 |
``Erik |
(probably
more the public posting than the actual logging...) |
| 22:09.05 |
louipc |
yea in case
they say something stupid |
| 22:09.23 |
louipc |
or personal
hah |
| 22:10.01 |
brlcad |
point still
stands .. insecure net, untrustable clients. they're walking
around downtown holding up a sign that says "don't take my
picture" |
| 22:11.59 |
louipc |
how about
those guys with cameras in their shoes? |
| 22:12.16 |
``Erik |
what, japan?
:D *duck* |
| 22:12.23 |
louipc |
hahah
what? |
| 22:15.24 |
brlcad |
yeah, that
actually went to the court in the US, and the guy got off
not-guilty for taking pics up girl's skirts at a local
fairground |
| 22:16.04 |
brlcad |
because they
were outside in a public place, ruled that they had no expectation
of privacy |
| 22:16.52 |
brlcad |
(not saying
that one is "right", but it certainly reinforces the expectation of
privacy test) |
| 22:48.39 |
*** join/#brlcad pombreda
(n=pombreda@dev.nexb.us) |
| 23:59.14 |
Yoshi477 |
is there an
ls command to show only the objects currently drawn |
| 00:02.46 |
``Erik |
probably |
| 00:03.00 |
``Erik |
pulls up source and kinda hopes someone who knows more than
he does answers before he gets too far into it...
:D |
| 00:07.11 |
``Erik |
(CTJ .. is
that... paladin?) |
| 00:08.24 |
*** join/#brlcad matthewmpp
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
| 00:08.49 |
``Erik |
hrm, too much
name overlap, makes grep tricky :( |
| 00:13.13 |
Yoshi477 |
does rtcheck
make shapes? |
| 00:13.31 |
Yoshi477 |
soemthing
keeps making copies of shapes with _01 |
| 00:14.13 |
Yoshi477 |
or does oed
cause that? |
| 00:15.12 |
``Erik |
rtcheck
shouldn't alter anything, oed shouldn't generate anything new if
you don't ask it to, I think? |
| 00:15.16 |
``Erik |
<--
doesn't know the gui... :D |
| 00:15.31 |
Yoshi477 |
this is
command line stuff |
| 00:15.50 |
``Erik |
I see where
the display list is held, now to see if there's something to walk
it and return it as a string... O.o heh |
| 00:16.10 |
``Erik |
um, I don't
know much about mged.... if you wanna talk rt or something, or
library stuff, I'm there... :D |
| 00:16.22 |
Yoshi477 |
ah
ok |
| 00:16.53 |
Yoshi477 |
backend
coder, i wish sometimes i could be one, and others not so
much |
| 00:18.10 |
``Erik |
I suppose
'backend' is one way to refer to what I do... I kinda think of
myself as more of a system developer... :D closer to the hardware
than the user interface... I get my jollies when I get to poke at
operating system kernel code :D |
| 00:19.13 |
``Erik |
I'm not
seeing anything that looks like a command to print the display list
:/ but I might just be missing it |
| 00:20.20 |
``Erik |
ah, wait,
looks like there's a duplicate list held in tcl |
| 00:21.07 |
``Erik |
hrmph. mged
isn't working on my laptop here :( |
| 00:21.20 |
Yoshi477 |
what! |
| 00:21.26 |
Yoshi477 |
you should be
ashamed! |
| 00:21.32 |
``Erik |
but the
'Display' tcl class has a method called "contents" that might be
what you're looking for |
| 00:21.40 |
Yoshi477 |
ok i'll
try |
| 00:21.48 |
Yoshi477 |
invalid |
| 00:21.56 |
Yoshi477 |
or is it ls
contents |
| 00:21.59 |
``Erik |
you have to
refer to the instance of display |
| 00:22.20 |
Yoshi477 |
and how my i
pretell do that? |
| 00:23.08 |
``Erik |
still
looking |
| 00:23.21 |
``Erik |
jabs brlcad or starseeker with something pointy to see if
they know |
| 00:24.28 |
``Erik |
meh, there're
like 3 definitions of 'display list' that confuse things heh
:( |
| 00:24.44 |
brlcad |
'who' shows
what is currently drawn |
| 00:24.47 |
Yoshi477 |
well i cause
patience plays in here |
| 00:24.54 |
Yoshi477 |
oh |
| 00:25.22 |
Yoshi477 |
what about
the individual prims? |
| 00:25.53 |
``Erik |
those'd be
the things in the display lists |
| 00:28.45 |
brlcad |
Yoshi477:
curious that you'd want or need to know the individual
prims |
| 00:28.50 |
brlcad |
but you can
find those with search |
| 00:28.56 |
Yoshi477 |
is there a
command to like where used? so enter prim and you get what
assemblies it is used in? |
| 00:28.57 |
brlcad |
search
whatever -not -type c |
| 00:29.11 |
``Erik |
brlcad: ones
in the active display list? |
| 00:29.40 |
brlcad |
dbfind
locates uses |
| 00:30.54 |
``Erik |
(I see where
src/tclscripts/lib/Display.tcl defines a "contents" method in the
Display class, how do you invoke that from inside of
mged?) |
| 00:31.05 |
Yoshi477 |
likes dbfind |
| 00:37.14 |
brlcad |
``Erik:
tclscripts/lib/* is archer guts |
| 00:37.35 |
``Erik |
ohhhhhh,
ok |
| 00:37.36 |
brlcad |
or at least
old archer guts, some might not be active any longer |
| 00:37.46 |
``Erik |
I saw some in
libged and some in tclscripts |
| 00:37.48 |
brlcad |
tclscripts/mged is mged
guttage |
| 00:38.18 |
``Erik |
(dead code
culling might be a good offsite, too) |
| 00:38.48 |
brlcad |
it's not used
by us, but is used by s2 |
| 00:39.05 |
brlcad |
or at least
*might* not be by us, but definitely by them |
| 00:39.05 |
Yoshi477 |
s2? |
| 00:39.23 |
brlcad |
Yoshi477: one
of various software projects that links against brl-cad
libs |
| 00:39.36 |
Yoshi477 |
opensource? |
| 00:39.40 |
brlcad |
nope |
| 00:39.43 |
Yoshi477 |
ah |
| 00:39.47 |
brlcad |
there are
lots of analysis codes that use br-cad |
| 00:39.50 |
Yoshi477 |
can i ask
what it does |
| 00:40.07 |
Yoshi477 |
mainly? |
| 00:40.25 |
``Erik |
chews up cpu
and keeps button mashers employed |
| 00:40.41 |
brlcad |
it calculates
vulnerability and lethality by performing high-energy ballistic
penetration simulations |
| 00:40.51 |
Yoshi477 |
cool |
| 00:41.10 |
Yoshi477 |
so how many
hours a day do you code for brlcad? |
| 00:41.17 |
brlcad |
24?
:) |
| 00:41.25 |
brlcad |
okay,
18 |
| 00:41.30 |
Yoshi477 |
really? |
| 00:41.35 |
brlcad |
gotta eat n'
sleep some to sustain |
| 00:41.45 |
Yoshi477 |
18? |
| 00:41.50 |
Yoshi477 |
you get paid
18 too! |
| 00:42.09 |
``Erik |
bullshit, you
code bzflag, too |
| 00:42.11 |
``Erik |
:D |
| 00:42.11 |
brlcad |
it
fluctuates |
| 00:42.28 |
brlcad |
yeah, not
just brl-cad, a few other open source projects too |
| 00:42.34 |
``Erik |
is libirc
dead? heh |
| 00:42.36 |
Yoshi477 |
i played
bzflag for about a week 2 years ago |
| 00:42.44 |
brlcad |
``Erik: nope,
it's just "done" for now |
| 00:43.03 |
``Erik |
aight,
haven't heard of it being used and commits seem very
infrequent |
| 00:43.04 |
Yoshi477 |
so the army
pays you for every hour you put in? |
| 00:43.15 |
brlcad |
heck
no |
| 00:43.26 |
Yoshi477 |
anything? |
| 00:43.36 |
``Erik |
the paperwork
to bill more than 80 hours a fortnight would be insane |
| 00:43.38 |
``Erik |
:D |
| 00:46.04 |
``Erik |
never
underestimate the insanity of gov't bureaucracy O.o |
| 00:46.27 |
``Erik |
the trick is
to do what you wanna do and figure out how to get someone to pay
you for it |
| 00:46.38 |
brlcad |
Yoshi477:
when one enjoys what they do, it doesn't really matter
much |
| 00:46.50 |
Yoshi477 |
true |
| 00:47.48 |
``Erik |
(have I
mentioned that I hate gui coding lately?) |
| 00:47.54 |
Yoshi477 |
nope |
| 00:48.20 |
Yoshi477 |
i love gui
coding, if i can do it? need lots of training for my small
mind |
| 00:48.32 |
``Erik |
heh, sure, do
ya do mac stuff? |
| 00:48.40 |
``Erik |
I have a side
project that I think needs a gui |
| 00:48.47 |
``Erik |
:D |
| 00:48.51 |
Yoshi477 |
nope don't
have a mac just linux |
| 00:48.53 |
``Erik |
hrm |
| 00:49.02 |
Yoshi477 |
know some qt
stuff but not much |
| 00:49.10 |
Yoshi477 |
some xul
stuff |
| 00:49.12 |
``Erik |
I happen to
have qt installed on my mac |
| 00:49.41 |
Yoshi477 |
whats the
side pro? |
| 00:50.04 |
``Erik |
um, ya
familiar with internet radio? shoutcast/icecast stuff? |
| 00:50.18 |
Yoshi477 |
not much but
i know what it is |
| 00:50.24 |
Yoshi477 |
never use
it |
| 00:50.36 |
``Erik |
I want a
decent source client that I can modify |
| 00:50.45 |
Yoshi477 |
ah |
| 00:50.54 |
``Erik |
'muse' is a
piece of shit (linux app with a halfassed carbon addon), nicecast
is closed source |
| 00:51.11 |
``Erik |
and those're
pretty much the only two that work on the mac :/ |
| 00:51.16 |
Yoshi477 |
ah |
| 00:51.29 |
Yoshi477 |
so you need
to find a qt one |
| 00:51.43 |
``Erik |
well, I'd
prefer cocoa, but *shrug* |
| 00:51.58 |
``Erik |
I was running
around the office looking for a cocoa book yesterday
heh |
| 00:53.07 |
``Erik |
but qt has a
native osX port, iirc, so I can't hate on it too much, even if it's
c++ |
| 00:53.15 |
``Erik |
gtk+ requires
X :( |
| 00:53.31 |
Yoshi477 |
you like gtk
better then qt? |
| 00:53.38 |
``Erik |
code wise,
yes |
| 00:53.44 |
Yoshi477 |
main
reason... |
| 00:53.52 |
``Erik |
I went from
loving c++ to hating it in '96 or so |
| 00:54.10 |
Yoshi477 |
what did you
replace it with? |
| 00:54.11 |
``Erik |
it's ugly,
excessively verbose, ambiguous, ... (or was in 96 or
so...) |
| 00:54.12 |
``Erik |
C |
| 00:54.27 |
Yoshi477 |
oh even more
low level |
| 00:54.45 |
``Erik |
I can cope
with things like function pointers and "advanced" cpp
macros... |
| 00:54.50 |
``Erik |
hm, I'd
disagree |
| 00:55.01 |
Yoshi477 |
oh
ok |
| 00:55.15 |
Yoshi477 |
i wouldn't
know just had basic tutorials on both of them |
| 00:55.43 |
``Erik |
c++ was dandy
if you have to deal with mediocre developers on the team... java
takes that role now... if you have a group of competent folk, c++
and java just get in the way, imnsho :) |
| 00:55.50 |
Yoshi477 |
got my level
1 c++ in college thats about it |
| 00:56.11 |
``Erik |
*sing*
anything you can do, I can do better... :D |
| 00:56.33 |
``Erik |
(early c++
was actually a macro package for C, iirc) |
| 00:56.42 |
``Erik |
called "c
with classes" or something |
| 00:56.56 |
``Erik |
alan kay has
an interesting rant on the subject :) |
| 00:57.26 |
Yoshi477 |
ya i knew
that, |
| 00:57.28 |
``Erik |
(he
'invented' object oriented... his observation is that bjarne missed
the point) |
| 00:57.46 |
Yoshi477 |
oh well i
don't get that stuff that much anyways my head hurts anytime i go
into it deep |
| 00:57.48 |
``Erik |
objc is sexy
is a strange way, though |
| 00:58.06 |
``Erik |
I'm annoyed
at the inability to collapse messages, though |
| 00:58.25 |
Yoshi477 |
see i don't
even get that! |
| 00:58.51 |
``Erik |
-(void)alpha;
-(void)beta:(int)i; ... I should be able to [obj alph beta:10] in
my mind, but I have to [obj alpha]; [obj beta:10]; |
| 00:59.03 |
``Erik |
know whut ah
mean, vern? |
| 00:59.06 |
Yoshi477 |
ya you lost
me |
| 00:59.20 |
Yoshi477 |
way beyond my
comprehension |
| 00:59.26 |
``Erik |
um, message
based OO systems .. :) smalltalk ftw |
| 00:59.56 |
``Erik |
[obj method];
is the objC version of obj.method(); |
| 01:00.30 |
``Erik |
(vs the CLOS
"(method obj)") |
| 01:01.21 |
``Erik |
yes, I'm a
language nerd... this is the stuff that interests me, gui's are
unfun :D *duck* |
| 01:01.26 |
Yoshi477 |
see you lost
me since i haven't use c++ qt since the spring and 2 years before
that, i goes out of my mind fast, but im fine with that, got to
learn brlcad and then when im done designing my CNC i can continue
with FANO |
| 01:01.47 |
Yoshi477 |
FaNO |
| 01:02.26 |
``Erik |
fano? |
| 01:02.43 |
``Erik |
an overloaded
word according to the almighty g00g |
| 01:03.07 |
``Erik |
a guitar
company, a town in italy, a district in austria, ... |
| 01:03.15 |
Yoshi477 |
Food and
Nutritional Organizer |
| 01:03.36 |
Yoshi477 |
something
like fitday |
| 01:03.45 |
Yoshi477 |
but cross
platform |
| 01:03.53 |
Yoshi477 |
and ability
to export stuff! |
| 01:04.28 |
``Erik |
hum |
| 01:04.41 |
``Erik |
similar to
http://nut.sf.net ? |
| 01:05.24 |
``Erik |
cli, but
works on *nix and dos |
| 01:06.09 |
``Erik |
has been learning common lisp and 'ucw' (and ajax,
javascript, css, etc) with the intent of making a web
variant |
| 01:06.14 |
Yoshi477 |
ya, but mine
has recipe manager built in |
| 01:06.28 |
``Erik |
heh |
| 01:06.30 |
``Erik |
amusing |
| 01:06.33 |
Yoshi477 |
and mine a
GUI(qt) |
| 01:06.52 |
``Erik |
<-- thinks
he had pretty much the same idea, but decided web was better as a
user interface layer |
| 01:07.01 |
Yoshi477 |
mainly going
to have recipe first(doesn't suit name at first but it
will) |
| 01:07.20 |
``Erik |
they say
great minds think alike, I guess the correlary is that feeble ones
do, as well ;) |
| 01:08.15 |
``Erik |
I did a fair
bit of whiteboard work to come up with ways to come up with
targetted recipe recommendation lists based on what ingredients you
have available, what your nutritional requirements are, and what
your personal preferences are |
| 01:08.44 |
``Erik |
(and trying
to figure out how to maintain a 'pantry' database without being
invasive or difficult) |
| 01:09.13 |
``Erik |
oohhhhhhh, I
saw this on hn a bit ago... http://recipepuppy.com/ neat stuff
:) |
| 01:09.31 |
``Erik |
a bit meta,
but neat |
| 01:10.07 |
Yoshi477 |
oh watch it
google's going to buy that site |
| 01:10.22 |
``Erik |
heh, that'd
be cool, the dude would get his payout |
| 01:10.31 |
Yoshi477 |
yep |
| 01:11.12 |
``Erik |
d'no if
google has any interest in the cooking world... |
| 01:12.09 |
``Erik |
when I
visited, I got an impression of a culture that viewed food as a
'below them' aspect, the free cafeterias, "snack stations", and
interest in going out to eat |
| 01:13.24 |
Yoshi477 |
free cafe?
they have it too good |
| 01:14.15 |
``Erik |
(mebbe the
cafeterias were free for the gsoc mentors as a special deal... but
when I visited nvidia, the cafeteria/catering was free) |
| 01:14.50 |
Yoshi477 |
nvidia is own
by google? |
| 01:14.58 |
``Erik |
no |
| 01:16.05 |
``Erik |
I visited
nvidia in '01, google in '08 |
| 01:16.40 |
Yoshi477 |
oh |
| 01:17.06 |
``Erik |
when I worked
at fedex, we had free tea, coffee, popcorn, etc... and vending
machines where tv dinners were like a buck |
| 01:23.16 |
Yoshi477 |
cool |
| 01:23.26 |
Yoshi477 |
i would be
even fatter! |
| 01:24.02 |
``Erik |
heh, I gained
like 50 pounds |
| 01:24.09 |
Yoshi477 |
ouch |
| 01:24.15 |
``Erik |
and I'm a
little dude |
| 01:24.24 |
Yoshi477 |
ya i have no
will power when it comes to food |
| 01:25.56 |
``Erik |
graduated
college at ~135 (~60kg), boomed up to 180(~80kg) pretty quick,
drifting around 150-160(~69-72kg) now |
| 01:26.27 |
``Erik |
and I'm only
5'8(147cm) |
| 01:26.37 |
``Erik |
:D |
| 01:27.54 |
louipc |
I gained like
10lbs when I was in taiwan for a month haha |
| 01:28.04 |
Yoshi477 |
grad 150lbs
college 1 year later 180, college 2year after grad 190, greenhouse
work for .5 year 185 IT Support/Systems Support Analyst Job 3.5
year after grad 210, now 195 hovering |
| 01:28.11 |
Yoshi477 |
lowest in 3
years was 184 |
| 01:28.13 |
louipc |
everybody
kept shoving food in my face |
| 01:28.29 |
``Erik |
I think
quitting soda was a big win for me |
| 01:28.34 |
Yoshi477 |
yep me
too |
| 01:28.51 |
Yoshi477 |
quiting most
sugars helps, and also six pack abs challenge! |
| 01:29.04 |
louipc |
:O |
| 01:29.52 |
``Erik |
heh |
| 01:30.38 |
``Erik |
see, I quit
drinking soda, but I drink a fair amount of beer, and like my big
greaseburger and fries at lunch... and a major aversion to physical
exertion, so I'm not exactly.... 'fit' :D |
| 01:31.25 |
``Erik |
monitoring
intake using 'nut' has changed my choices in food a fair bit,
though... *shrug* mortifying looking at what ya actually shovel
into your body |
| 01:33.00 |
Yoshi477 |
i know what
you mean |
| 01:38.13 |
Yoshi477 |
yeah finally
got all my overlaps delt with! |
| 01:39.43 |
brlcad |
woo
hoo |
| 01:40.32 |
Yoshi477 |
hey brlcad if
i had 6 of those hex bolts in my window wireframe would that slow
down the rotation and zoom in and out, or is it just a problem on
my machine? |
| 01:42.04 |
Yoshi477 |
maybe i need
a quadro? |
| 01:42.11 |
Yoshi477 |
5400 |
| 01:42.14 |
Yoshi477 |
lol |
| 01:42.34 |
brlcad |
depends just
how complicated the geometry is, how many objects, how many
segments, your video card, whether it's x11 or ogl, etc |
| 01:42.45 |
brlcad |
in general,
no it shouldn't really, but certainly could |
| 01:43.00 |
brlcad |
especially
with a lot of deep copies (from clone) instead of
references |
| 01:43.37 |
Yoshi477 |
one
sec |
| 01:45.01 |
Yoshi477 |
here try it
out
http://ej.nijenhuis.pixi.me/d/2441-1/sweetspot_g?g2_GALLERYSID=8d870d26847034d67e6a9b58f984d434 |
| 01:45.04 |
Yoshi477 |
B
sweetspot.c |
| 01:45.10 |
``Erik |
quatro will
not help you |
| 01:45.19 |
Yoshi477 |
really? |
| 01:45.35 |
Yoshi477 |
a gaming card
better |
| 01:45.45 |
``Erik |
glLine is not
really any faster on even a good GL card than a simple svga
card |
| 01:46.04 |
Yoshi477 |
i guess i
don't know |
| 01:46.06 |
``Erik |
openGL does
not really buy BRL-CAD any speed at the moment |
| 01:46.19 |
brlcad |
getting a few
fps here |
| 01:46.39 |
Yoshi477 |
im at
.82 |
| 01:46.40 |
``Erik |
%
delta? |
| 01:47.20 |
Yoshi477 |
.74 when
zooming |
| 01:47.46 |
``Erik |
crap, it's
september, isn't it |
| 01:47.48 |
Yoshi477 |
GeForce 8500
GT |
| 01:47.50 |
Yoshi477 |
yep it
is |
| 01:47.58 |
``Erik |
2 months of
paperwork :( |
| 01:48.25 |
Yoshi477 |
paperwork for
what? two month to go? |
| 01:48.47 |
``Erik |
gotta write
up reports on what I have done and what I intend to do |
| 01:49.06 |
Yoshi477 |
for the two
summer months or it will take you two months |
| 01:49.56 |
Yoshi477 |
don't you
keep svn with ci -m" everytime you can just concat those and your
done! |
| 01:50.11 |
``Erik |
probably
about ten hours of real work, but the annoyance kills time like a
mofo, so 2 months of dev is blown |
| 01:50.37 |
Yoshi477 |
ah |
| 01:50.44 |
``Erik |
yes, the svn
logs are an important part, extracting pertinant data from it is a
hassle |
| 01:51.16 |
``Erik |
I can't say
"svn log -user erikgreenwald -dates
200810010000:200909312359" |
| 01:51.26 |
``Erik |
the 'user'
part is the bitch |
| 01:51.27 |
Yoshi477 |
why
not |
| 01:51.48 |
``Erik |
it's not an
option in svn |
| 01:52.01 |
``Erik |
(unless I'm
missing it) |
| 01:52.02 |
Yoshi477 |
when you add
a cooment you should put erik:your comment then you can
easily |
| 01:52.33 |
``Erik |
but when I
leave a comment, I comment on what I did, not who I
am... |
| 01:52.42 |
Yoshi477 |
you can do
both |
| 01:53.01 |
Yoshi477 |
that way you
get it out of svn |
| 01:53.10 |
``Erik |
gimmea time
machine so I can go back a year and inform myself to encode user
information superfluously in the log message. |
| 01:53.13 |
``Erik |
:D |
| 01:53.15 |
Yoshi477 |
thats what i
do at work for my task logs |
| 01:53.36 |
Yoshi477 |
time machine
only work for future |
| 01:53.39 |
``Erik |
I got data,
it ain't got that encoding, I gotta generate info... |
| 01:53.50 |
``Erik |
so,
y'kow, |
| 01:53.53 |
``Erik |
know |
| 01:53.58 |
Yoshi477 |
gives shotgun to ``Erik |
| 01:54.25 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 01:56.26 |
Yoshi477 |
wait a
minute |
| 01:56.36 |
Yoshi477 |
don't you svn
commit under your username |
| 01:56.59 |
``Erik |
yes, I
do |
| 01:57.01 |
``Erik |
that's my
issue |
| 01:57.11 |
Yoshi477 |
why is that
your issue? |
| 01:57.42 |
``Erik |
I don't
believe that svn log has any username filter |
| 01:58.19 |
Yoshi477 |
well we use
redmine at work and when i use the svn cli after that i go to the
svn section in redmine and it has what user did what
commit! |
| 01:58.21 |
``Erik |
dorks with it, sees a 'username' global option and may soon
have egg on his fcea |
| 01:59.03 |
``Erik |
no, even
specifying the username, it gives me all deltas |
| 01:59.03 |
Yoshi477 |
so ya found
it? |
| 01:59.16 |
Yoshi477 |
deltas? |
| 01:59.55 |
``Erik |
yeah,
--username seems to be ignored in log O.o |
| 01:59.59 |
``Erik |
effin'
r-tarded |
| 02:00.10 |
Yoshi477 |
umm i wonder
how redmine does it |
| 02:01.43 |
Yoshi477 |
yep i am
looking at it right now under repository in redmine i can see who
the author is of the latest revision |
| 02:03.14 |
starseeker |
``Erik: does
this help? http://svn.haxx.se/users/archive-2005-02/0738.shtml |
| 02:04.14 |
Yoshi477 |
well im off
for the nite, cya later |
| 02:04.27 |
``Erik |
hasta,
yoshi |
| 02:04.38 |
``Erik |
starseeker:
why can't svn do this by itself? |
| 02:04.59 |
``Erik |
it has a
fucking --username argument, why the fuck doens't it fucking work?
goddamn piece of sit |
| 02:05.02 |
``Erik |
shit |
| 02:05.26 |
``Erik |
"lets do cvs,
but better! oh, wait, lets take all the fuckups of cvs and MAKE
THEM WORSE! YES! TEH WINZ!" |
| 02:05.32 |
``Erik |
:D |
| 02:06.00 |
``Erik |
eyeballs darcs some |
| 02:06.08 |
brlcad |
that's the
username to use to log in |
| 02:06.25 |
brlcad |
for rev in
`svn log configure.ac | grep erik | awk '{print $1}'` ; do svn log
-$rev configure.ac ; done |
| 02:06.29 |
``Erik |
damnit, don't
de-rail my drunken rant |
| 02:07.34 |
Yoshi477 |
lol |
| 02:07.38 |
Yoshi477 |
ok im gone
now |
| 02:08.02 |
``Erik |
hasta |
| 02:08.13 |
louipc |
erm
--username is meant for authentication, not filtering |
| 02:33.49 |
starseeker |
``Erik: could
you import our repository into git? would that help? |
| 02:34.08 |
starseeker |
http://www.metaskills.net/2009/2/1/git-subversion-user-commit-reports |
| 02:39.21 |
louipc |
heehee
:D |
| 02:40.08 |
louipc |
I would have
said that, but brlcad would accuse me of preaching. |
| 02:50.57 |
``Erik |
starseeker:
ur m0m |
| 03:30.56 |
starseeker |
``Erik:
eh? |
| 06:28.11 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
| 06:31.35 |
*** part/#brlcad elena
(n=elena@89.136.118.141) |
| 06:57.45 |
*** join/#brlcad talcite__
(n=matthew@69-165-162-202.dsl.teksavvy.com) |
| 09:04.55 |
*** join/#brlcad dli_
(n=dli@69.172.102.119) |
| 09:18.58 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D46C.dip.t-dialin.net) |
| 09:22.12 |
*** join/#brlcad _sushi_
(n=_sushi_@84.72.9.151) |
| 11:58.56 |
*** join/#brlcad Thingymebob
(n=thingyme@static-87-243-197-20.adsl.hotchilli.net) |
| 11:59.16 |
Thingymebob |
Make fails,
can anyone help http://pastebin.com/d58247d7f |
| 12:02.06 |
``Erik |
the actual
failure seems to be omitted |
| 12:02.10 |
``Erik |
? |
| 12:03.18 |
Thingymebob |
``Erik: My
error, It just hung at that point, back to life now |
| 12:04.08 |
``Erik |
if there is a
failure in there, ya might try re-running configure with
"--enable-all" |
| 12:04.39 |
``Erik |
the tcl/tk
check probably needs some lovin' to make sure the system variant is
recent enough :/ |
| 12:43.57 |
CIA-28 |
BRL-CAD:
03jdoliner * r35852
10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: |
| 12:43.57 |
CIA-28 |
BRL-CAD:
Fixed illegal coersions of ON_BezierCurves * into ON_Curve * which
was causing |
| 12:43.57 |
CIA-28 |
BRL-CAD:
segfaults. WalkIntersection now returns its result as an
ON_NurbsCurve cast as |
| 12:43.57 |
CIA-28 |
BRL-CAD: an
ON_Curve instead of as ON_BezierCurves, the curves are still
identical |
| 14:46.03 |
``Erik |
teh fux? a
billy mays commercial? heh |
| 15:07.10 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 15:47.24 |
*** join/#brlcad Patmcc19
(n=chatzill@174-17-202-71.phnx.qwest.net) |
| 16:28.16 |
kanzure |
hi
all |
| 16:28.26 |
kanzure |
anyone know
of any open source assembly planner? |
| 16:38.17 |
``Erik |
that
sounds... awfully specialized? |
| 16:45.01 |
``Erik |
huh, this tv
show thinks the bismark was scuttled |
| 17:09.05 |
*** join/#brlcad samrose
(n=samrose@99.147.180.206) |
| 17:26.16 |
kanzure |
is there a
way to figure out the regions in a dot g file? is there a shell
utility that will list them for me? |
| 17:27.16 |
brlcad |
mged -c
test.g search / -type r |
| 17:27.53 |
kanzure |
invalid
command name "search" |
| 17:28.10 |
brlcad |
your version
is too old |
| 17:28.22 |
kanzure |
7.8
? |
| 17:28.42 |
brlcad |
wow, that is
ancient |
| 17:28.55 |
kanzure |
that's what's
on the download page |
| 17:29.05 |
kanzure |
gets the svn version |
| 17:29.12 |
brlcad |
binary
platforms aren't updated very frequently (you |
| 17:29.20 |
brlcad |
(you're more
than welcome to provide an update) |
| 17:29.53 |
kanzure |
okay |
| 17:30.36 |
kanzure |
maybe I
should just ask before I bother, but, |
| 17:30.46 |
kanzure |
I'm trying to
convert from DXF to STEP or IGES. is this going to
happen? |
| 17:31.04 |
kanzure |
HeeksCAD
doesn't seem to do it at all, so I'm trying brlcad |
| 17:35.32 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 17:43.00 |
Yoshi477 |
kanzure, you
can get a 30day trial from varicad |
| 17:45.53 |
brlcad |
depends on
what is in the dxf file, but you should be able to run dxf-g and
g-iges to convert |
| 17:45.53 |
brlcad |
we don't have
a step exporter yet |
| 17:46.33 |
Yoshi477 |
kanzure, or
you can upload and someone here might offer to do it for
you |
| 17:47.39 |
kanzure |
http://adl.serveftp.org/belt-clamp.3d.DXF
that would be awesome :) |
| 17:47.47 |
Yoshi477 |
i'll give it
a shot |
| 17:49.03 |
kanzure |
thank you
:) |
| 17:50.18 |
brlcad |
what is in
that dxf? |
| 17:50.28 |
Yoshi477 |
i only got a
2d profile of something |
| 17:51.08 |
kanzure |
it's
supposedly a 3d model |
| 17:51.16 |
brlcad |
yeah, export
of non-solid entities isn't going to fly |
| 17:51.21 |
kanzure |
when I open
it up in HeeksCAD, it's a "3d sketch" whatever the hell that
is |
| 17:51.24 |
kanzure |
hrm |
| 17:51.32 |
kanzure |
well the
other option here is for me to extrude an svg file |
| 17:51.37 |
kanzure |
heekscad
crashes when attempting to do that, however |
| 17:51.40 |
Yoshi477 |
one
sec |
| 17:51.43 |
kanzure |
(there's a
common theme) |
| 17:51.45 |
Yoshi477 |
my varicad
might not be expired |
| 17:52.04 |
kanzure |
the svg is
located here:
http://contraptor.svn.sourceforge.net/viewvc/contraptor/tags/contraptor-1.5.0/components/belt-clamp/ |
| 17:52.25 |
brlcad |
yeah, it is a
3d sketch .. that's just a planar object |
| 17:52.35 |
kanzure |
grr |
| 17:52.41 |
kanzure |
the author
made it originally in google sketchup |
| 17:52.47 |
kanzure |
which is
completely useless as far as I'm concerned |
| 17:53.47 |
Yoshi477 |
varicad
imported it as a 2d just like brlcad did, are you sure its a 3d
file? |
| 17:54.01 |
kanzure |
no not at
all |
| 17:54.01 |
brlcad |
it's not a
valid extrusion sketch |
| 17:54.03 |
kanzure |
can it be
extruded? |
| 17:54.07 |
kanzure |
hm |
| 17:54.10 |
Yoshi477 |
yeah |
| 17:54.25 |
brlcad |
i extruded it
in brl-cad, but it's got non-closed loops |
| 17:54.26 |
Yoshi477 |
but it look
like there is a gear on the one side |
| 17:54.39 |
kanzure |
hmph. |
| 17:54.45 |
kanzure |
maybe this
isn't worth our time |
| 17:54.48 |
kanzure |
sorry to bug
you guys |
| 17:54.55 |
Yoshi477 |
np |
| 17:55.06 |
Yoshi477 |
kinda was
curious to see the 3d |
| 17:55.09 |
kanzure |
"contraptor"
is an "open hardware" project that has dimensions/specs for various
components like beams and angled brackets |
| 17:55.19 |
Yoshi477 |
ah |
| 17:55.20 |
kanzure |
but since it
doesn't provide any usable CAD models, screw it |
| 17:55.29 |
kanzure |
what's the
point? |
| 17:55.34 |
kanzure |
why would you
put effort into something completely unusable |
| 17:55.42 |
kanzure |
am I missing
something? |
| 17:56.09 |
kanzure |
anyway, I was
asking earlier today about writing an assembly planner |
| 17:56.13 |
kanzure |
was wondering
if anyone in here has experience with those |
| 17:57.17 |
Yoshi477 |
nope |
| 17:57.27 |
Yoshi477 |
but i work
with people who use pro/e |
| 17:57.34 |
kanzure |
does pro/e do
that? |
| 17:57.56 |
kanzure |
assembly
planners are used to generate instructions and sequences of
operations for physically moving around parts to a CAD model to
make it happen in the shop |
| 17:58.08 |
kanzure |
sometimes
spitting out human readable instructions |
| 17:58.12 |
kanzure |
sometimes
spitting out robot crap |
| 17:58.40 |
Yoshi477 |
oh, i think
it does that but they don |
| 17:58.42 |
Yoshi477 |
t use
it |
| 17:58.47 |
kanzure |
the trick
though is somehow avoiding order n**2 collision detection between
all of the parts |
| 17:59.17 |
kanzure |
(to check for
collision-free insertion motions) |
| 18:00.47 |
Yoshi477 |
what would
boost the usage of brlcad would be integrated g-code
exporter |
| 18:01.13 |
kanzure |
yeah I can't
read g-code much heh |
| 18:01.40 |
Yoshi477 |
wel anyways
im off for the afternoon, cya guy tonight maybe |
| 18:10.19 |
``Erik |
´/clear |
| 18:31.01 |
*** join/#brlcad yukonbob_
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 18:49.32 |
``Erik |
hm |
| 18:50.48 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 19:08.57 |
*** join/#brlcad samrose
(n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 19:26.46 |
starseeker |
kanzure: at a
guess, the contraptor project looks like it's not mature
yet |
| 19:27.05 |
starseeker |
their web
page appears to be a default sourceforge page, for the most
part |
| 19:27.48 |
starseeker |
generally
speaking, open source CAD tools have a ways to go |
| 19:41.21 |
starseeker |
wonders how he can justify buying an
N900... |
| 19:52.44 |
kanzure |
starseeker:
nah the real web page is somewhere else apparently |
| 19:52.53 |
kanzure |
goes back to hating everything and
everyone |
| 19:53.33 |
starseeker |
these guys?
http://www.garagefab.cc/contraptor/what-is-it |
| 20:46.05 |
*** join/#brlcad Patmcc19
(n=chatzill@174-17-202-71.phnx.qwest.net) |
| 22:21.51 |
kanzure |
yes |
| 23:46.44 |
*** join/#brlcad dli_
(n=dli@69.172.102.119) |
| 01:45.21 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 02:17.54 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 06:10.56 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 06:11.55 |
*** join/#brlcad puddingpimp
(n=dave@118-93-244-155.dsl.dyn.ihug.co.nz) |
| 07:15.24 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 08:11.41 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 08:59.17 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 09:31.49 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 10:25.14 |
*** join/#brlcad _clock__
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 12:53.59 |
brlcad |
yawns and soaks up some caffeine |
| 12:56.21 |
Yoshi47 |
thats a good idea |
| 13:06.26 |
*** join/#brlcad talcite__
(n=matthew@69-196-180-86.dsl.teksavvy.com) |
| 13:06.33 |
Yoshi47 |
thats hits the spot |
| 13:07.57 |
``Erik |
would recommend against putting hot coffee on your
"spot"... |
| 13:08.19 |
Yoshi47 |
thanks for
that |
| 13:09.04 |
Yoshi47 |
in this
boolean what specifies the rotation? u hexbolt_M8x55.c1 0 0 -25.4
0 6.123031769112e-17 -1 60.325 0 1 6.123031769112e-17 12.7 0 0 0
1 |
| 13:12.34 |
brlcad |
it's a 4x4
homogeneous matrix |
| 13:12.52 |
Yoshi47 |
nice you just
blew over my head |
| 13:13.17 |
Yoshi47 |
do i have
read more? |
| 13:14.05 |
brlcad |
basically
it's one mathematical matrix that specifies translations,
rotations, and scaling all in one |
| 13:14.33 |
Yoshi47 |
ya, im
reading up on it. |
| 13:14.35 |
Yoshi47 |
give me a
sec |
| 13:14.40 |
Yoshi47 |
and i'll be
back |
| 13:14.40 |
brlcad |
http://en.wikipedia.org/wiki/Transformation_matrix |
| 13:14.43 |
Yoshi47 |
thanks |
| 13:15.09 |
brlcad |
it's easy to
derive the translation as it's just a column, but once you apply a
rotation, it gets a little tricky |
| 13:15.22 |
brlcad |
scaling is
similarly trivial, down the diagonal |
| 13:16.38 |
brlcad |
e.g., if you
saw 1 0 100 0 0 1 0 0 0 0 1 0 0 0 0 1 that would be a
translation 100 units down the X axis |
| 13:17.10 |
Yoshi47 |
ah |
| 13:17.19 |
brlcad |
and if you
saw 2 0 0 0 0 2 0 0 0 0 2 0 0 0 0 1 that would be an
object scaled 2x |
| 13:17.25 |
Yoshi47 |
ah |
| 13:17.33 |
``Erik |
row major
representation |
| 13:17.57 |
``Erik |
imagines that screwed with folk back when fortran was really
common |
| 13:18.27 |
Yoshi47 |
so my next
question is when ihave that part comb inside another comb can i
edit the with oed the hexbolt.c just for the one comb or will it
affect all combs that it is in? |
| 13:18.57 |
``Erik |
it'll only
twist the matrix of the comb you specified |
| 13:19.26 |
``Erik |
if you want
things to modify stuff down the line, 'push' and 'xpush' do that
after you've oed'd it |
| 13:20.13 |
brlcad |
when you use
oed, you specify a "right hand" and "left hand" side of a path ..
where you split left and right sides is where the matrix
goes |
| 13:20.15 |
Yoshi47 |
so how do i
only edit the hexbolt for this assmebly?
xslide_yslackadjasm_1.c/hexbolt_M8x55.c/ |
| 13:20.39 |
Yoshi47 |
so oed
/xslide_yslackadjasm_1.c/hexbolt_M8x55.c/
xslide_yslackadjasm_1.c/hexbolt_M8x55.c/ |
| 13:20.45 |
brlcad |
no |
| 13:20.59 |
brlcad |
it's just
one, like a filesystem path |
| 13:21.12 |
brlcad |
/xslide_yslackadjasm_1.c/hexbolt_M8x55.c/path/all/the/way/to/some/primitive |
| 13:21.26 |
brlcad |
then you
*split* that somewhere |
| 13:21.30 |
brlcad |
like |
| 13:21.40 |
brlcad |
<PROTECTED> |
| 13:21.44 |
Yoshi47 |
but that
edits the whole comb, or can i specify just to move the
hexbolt? |
| 13:21.50 |
Yoshi47 |
ah |
| 13:21.54 |
Yoshi47 |
i think im
getting it |
| 13:22.15 |
brlcad |
that means
i'm intending to apply a matrix to the hexbolt_M8x55.c referenced
in xslide_yslackadjasm_1.c |
| 13:22.37 |
brlcad |
not all
hexbolt_M8x55.c's, just the one |
| 13:22.53 |
Yoshi47 |
cool |
| 13:22.56 |
Yoshi47 |
i think i get
it now, |
| 13:23.05 |
brlcad |
if I wanted
all of them, I'd either do /xslide_yslackadjasm_1.c/hexbolt_M8x55.c
path/all/the/way/to/some/primitive |
| 13:23.08 |
brlcad |
or
just |
| 13:23.28 |
brlcad |
<PROTECTED> |
| 13:23.47 |
Yoshi47 |
ok |
| 13:23.51 |
Yoshi47 |
that helps,
thanks |
| 13:23.54 |
brlcad |
"/" as the
left hand side is effectively a special case |
| 13:24.14 |
brlcad |
the oed
tutorial covers in a lot more detail |
| 13:24.31 |
Yoshi47 |
ya, im bad i
only skimmed over it, i should go through it again |
| 13:24.35 |
brlcad |
including why
the (hell) you have to specify the path to a primitive |
| 13:24.53 |
Yoshi47 |
reference
point, no? |
| 13:25.01 |
brlcad |
yeah ..
implementation detail, it's the anchor point |
| 13:25.09 |
brlcad |
rotation
point |
| 13:25.11 |
Yoshi47 |
yep figured
that one out |
| 13:25.17 |
Yoshi47 |
makes
sense |
| 13:25.29 |
brlcad |
combinations
have no natural reference point as they're implicit |
| 13:26.16 |
brlcad |
in the
future, we might make it the center of their bounding box or
something similar |
| 13:28.22 |
Yoshi47 |
that would be
a handy thing! lots of people would like that |
| 13:30.18 |
brlcad |
sounds simple
enough, but there's actually a surprising bit under the hood that
would need to change to support that |
| 13:36.25 |
``Erik |
cuts away a very slight curve from a cube by subtractive a
huge sphere... then wonders why the center of the bounding box is
far far away from the final geometry O:-) |
| 13:43.27 |
Yoshi47 |
just ignore
any subtractions |
| 13:52.51 |
``Erik |
except if you
subtract a combination that has a subtraction in it, that double
negative makes it an adder |
| 13:52.52 |
brlcad |
the same
holds for intersections |
| 13:54.42 |
brlcad |
it'll still
result in unintuitive keypoints until boolean evaluation, which is
part why it's non-trivial .. but even using bounding boxes it's
still a bit of work |
| 13:57.00 |
brlcad |
consider a
(0,0,0)->(100,100,100) cube that is shifted slightly in the
x-dir and subtracted (leaving a thin plate) -- whether you ignore
the subtraction or not, it'll result in a keypoint at roughly
(50,50,50) |
| 13:57.13 |
brlcad |
no where near
the evaluated geometry |
| 13:57.19 |
Yoshi47 |
ah |
| 13:57.22 |
Yoshi47 |
so
true |
| 13:58.34 |
brlcad |
you really
want the bounding box of the evaluated result, but evaluating
implicit booleans isn't quick or easy or directly possible (but
becomes possible with a hybrid system) |
| 13:59.07 |
brlcad |
even better,
the center of mass, but that's even more expensive to
evaluate |
| 14:01.07 |
brlcad |
``Erik: and
that only happens in a pure boolean system, not with csg
(subtracting something with a negative doesn't invert that negative
space) |
| 14:10.15 |
``Erik |
there is that
complication, but it's not clean like a pure boolean
*shrug* |
| 14:10.27 |
``Erik |
(anyways,
it's not as simple as "just ignore subtractions") |
| 14:10.41 |
Yoshi47 |
got
it |
| 14:49.14 |
``Erik |
ghostriding
an mrap.. wow... I didn't think people that r-tarded could enlist
anymore |
| 14:50.56 |
starseeker |
starts in shock - the Ayam dude has implemented the
Subdivision NURBS stuff from SIGGRAPH |
| 14:51.19 |
starseeker |
we really
need to get him to merge his stuff with BRL-CAD :-) |
| 14:52.41 |
starseeker |
holy
cow |
| 14:53.17 |
Yoshi47 |
where? |
| 14:53.45 |
``Erik |
plenty of
holy cow's in india, I believe |
| 14:53.52 |
Yoshi47 |
lol |
| 14:54.09 |
``Erik |
or were ya
asking about http://ayam.sf.net
? |
| 14:54.24 |
Yoshi47 |
nope
expecting your reply, lol |
| 14:54.29 |
Yoshi47 |
i already
looked that up |
| 14:55.04 |
``Erik |
mmmm delux
dietyburger with cheese |
| 14:55.06 |
``Erik |
*drool* |
| 14:55.12 |
starseeker |
http://ayam.sourceforge.net/news.html |
| 14:55.28 |
``Erik |
is going to be reincarnated as a jock strap at this
rate |
| 15:04.22 |
d-lo |
thats a
dismal fate if I've ever heard one.... |
| 15:04.47 |
starseeker |
oh, I see -
he's actually linking to the GPL code for the snurbs
part |
| 15:04.54 |
starseeker |
poop |
| 15:06.30 |
starseeker |
still neat,
but not something we can use directly |
| 15:06.46 |
starseeker |
oh well - we
would have had to implement snurbs as a primitive
anyhow |
| 15:16.02 |
Yoshi47 |
is there
autocomplete feature in mged CLI? |
| 15:17.42 |
starseeker |
you mean tab
completion? I think that's just in MGED Tcl/Tk
currently |
| 15:24.57 |
Yoshi47 |
yes, wheres
that? |
| 15:39.55 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 15:46.21 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D492.dip.t-dialin.net) |
| 15:48.52 |
louipc |
there's tab
completion in classic mode |
| 15:52.23 |
brlcad |
there is, but
there are some issues with it in classic (either works or it
doesn't of course) |
| 16:17.56 |
*** join/#brlcad KingofCSU
(n=king@222.247.155.229) |
| 16:43.59 |
*** join/#brlcad Ralith
(n=ralith@d142-058-086-103.wireless.sfu.ca) |
| 16:45.06 |
*** join/#brlcad KingofCSU
(n=king@222.247.155.229) |
| 16:57.48 |
``Erik |
*burp* good
old korean |
| 16:58.50 |
KingofCSU |
Hello
everyone I am new to BrlCAD. How to learn it? |
| 16:59.11 |
brlcad |
KingofCSU:
hello, start with the "Introduction to MGED" on the
website |
| 16:59.22 |
brlcad |
and it's
"BRL-CAD", not BrlCAD ;) |
| 17:00.13 |
KingofCSU |
I have see it
and I think it is hard to make complex things |
| 17:00.26 |
KingofCSU |
by using
CSG |
| 17:05.10 |
KingofCSU |
it is said
there is Brep in BRL-CAD . where is it? |
| 17:05.30 |
brlcad |
it's
currently under development |
| 17:05.39 |
KingofCSU |
oh |
| 17:05.50 |
brlcad |
CSG isn't
harder, it's just very different |
| 17:06.04 |
Ralith |
KingofCSU:
there are some very impressive proofs of this, if you'd like
^^ |
| 17:06.24 |
KingofCSU |
?
so |
| 17:06.34 |
brlcad |
a good csg
modeler is generally just as productive as a modeler using brep
approaches |
| 17:06.58 |
brlcad |
there are
tradeoffs to both and shapes that lend themselves strongly to
both |
| 17:07.03 |
KingofCSU |
I am trying
to learn the CSG |
| 17:07.28 |
Ralith |
brlcad: did
you ever render that impeller with the metal shader? |
| 17:07.32 |
brlcad |
the tutorial
series is the place to start, the learning curve is steep at first,
but it gets a lot easier |
| 17:07.34 |
Yoshi47 |
? |
| 17:07.43 |
Yoshi47 |
chrome! |
| 17:07.54 |
brlcad |
Ralith: heh,
I did but don't have it on hand at the moment |
| 17:07.58 |
Ralith |
kk |
| 17:08.04 |
Yoshi47 |
i
do! |
| 17:08.07 |
Ralith |
:D |
| 17:08.18 |
brlcad |
but you
remind me that I had another going over the weekend |
| 17:08.25 |
Yoshi47 |
lol |
| 17:08.27 |
Ralith |
Yoshi47:
incidentally, did you ever write that walkthrough? |
| 17:08.51 |
Yoshi47 |
going to be
doing that soon, i have a couple of projects that need to get done
first this week |
| 17:09.08 |
Yoshi47 |
i will redo
it from scratch and write the how to as i go along |
| 17:09.17 |
Ralith |
cool
:D |
| 17:09.20 |
KingofCSU |
I am Chinese
. poor English . lol |
| 17:09.21 |
Ralith |
that'll be
fun to read |
| 17:09.22 |
Yoshi47 |
there is a
couple areas i can improve on since i learnt more over the last few
weeks |
| 17:09.40 |
Ralith |
thinks it wouldn't hurt to be more familiar with mged as he
plays with g3d |
| 17:10.30 |
Yoshi47 |
fun to
read? |
| 17:10.38 |
KingofCSU |
brlcad: What
should i do when i finish the the tutorial series? |
| 17:10.47 |
Yoshi47 |
go over them
again |
| 17:10.48 |
Ralith |
Yoshi47: fun
to read and model |
| 17:11.23 |
Yoshi47 |
ya, should be
fun to writw |
| 17:11.25 |
KingofCSU |
Ok I will go
over them . did them cover all things? |
| 17:11.26 |
Yoshi47 |
*write |
| 17:11.51 |
Ralith |
KingofCSU: it
covers enough to start with, certainly. |
| 17:12.06 |
KingofCSU |
any other
thing to improve? |
| 17:12.36 |
Yoshi47 |
practice
making stuff on your desk |
| 17:12.41 |
Yoshi47 |
and
assemblies |
| 17:13.00 |
Yoshi47 |
choose
something simple cause it will be hard at first |
| 17:13.22 |
KingofCSU |
Yoshi47: That
is a good idea. I will try and thanks a lot for answer my
Q? |
| 17:14.26 |
Yoshi47 |
yep, no
problem, im a newbie just like you, only been doing it for month,
and if you look on more.brlcad.org you can see my bearing i
did |
| 17:14.43 |
Yoshi47 |
although not
render nicely yet |
| 17:15.27 |
KingofCSU |
One more Q.
how to snap to something. It is hard to put something to a place
exactly without the "p" comment? |
| 17:15.49 |
Yoshi47 |
i haven't
tried snapping yet |
| 17:15.56 |
Yoshi47 |
but there is
snap to grid |
| 17:16.47 |
KingofCSU |
I see. I
mean just like the 'blender' to snap a solid to a point or a midle
of a solid just like that |
| 17:17.34 |
Yoshi47 |
nope not that
i have found and im pretty sure it doesn't exist right
now |
| 17:19.04 |
KingofCSU |
I follow the
tutorial to make a goblet. and it is hard to put the sph exactly to
the top of another. lol |
| 17:19.40 |
Yoshi47 |
yep, i
basically figure it out and use translate |
| 17:19.59 |
Yoshi47 |
but you want
a little overlap, as it does say that in the tutorial |
| 17:20.38 |
Yoshi47 |
since in real
life if your goblet balls only were connected by a thou of material
it would break easily |
| 17:21.17 |
KingofCSU |
by the way. I
am a Chinese. sometime I have to use the dic to translate English
to Chinese. make me slowly |
| 17:22.45 |
Yoshi47 |
ah, you live
in China too? |
| 17:22.53 |
KingofCSU |
yep . you are
right. so did the Brl-CAD have the "merge" command ? |
| 17:22.58 |
KingofCSU |
yes I live in
China |
| 17:23.38 |
KingofCSU |
I mean the
"union" is not same as "merge" |
| 17:23.38 |
Yoshi47 |
merge? like
you want to merge 2 parts together? |
| 17:24.12 |
Yoshi47 |
keep
following the tutorial it will get there. |
| 17:24.44 |
KingofCSU |
I
will. |
| 17:26.38 |
KingofCSU |
how many
BRL-CAD Tutorial Series there are? four? or more |
| 17:28.04 |
Yoshi47 |
some more
tutorial also i don't know if they are part of the series. here is
an impeller i did while learning BRL-CAD http://ej.nijenhuis.pixi.me/v/CAD/impeller.png.html |
| 17:28.17 |
Yoshi47 |
and brlcad
rendered it for me |
| 17:28.31 |
KingofCSU |
Thanks I will
check it. |
| 17:28.42 |
Yoshi47 |
took me at
least 8 hours to do that |
| 17:29.00 |
KingofCSU |
beautiful |
| 17:29.42 |
Yoshi47 |
and this took
me a week the first time while learning the program, and then i
lost the database so i had to redo and i redid the whoel thing in
under 1.5hours http://ej.nijenhuis.pixi.me/v/CAD/render_balls.png.html |
| 17:29.56 |
brlcad |
KingofCSU:
the tutorial series should take a day at least to go through
without skimming (it's useless to skim it), should ask again after
that or have something in mind to model of your own then work on
that after the tutorials |
| 17:30.50 |
Yoshi47 |
yep i
agree! |
| 17:31.07 |
KingofCSU |
thanks for
your advice |
| 17:31.40 |
Yoshi47 |
and don't
give up! |
| 17:32.06 |
Yoshi47 |
Ralith, i
think i need another 22" for at home when i do the tutorial on the
impeller! |
| 17:32.47 |
KingofCSU |
I must to go
bed now it is 01:32a.m. here . |
| 17:32.57 |
Yoshi47 |
cya |
| 17:33.08 |
KingofCSU |
cya |
| 17:39.16 |
brlcad |
fwiw, our
union is a 'merge' operation, with no interior surfaces preserved
.. |
| 17:40.24 |
``Erik |
practices his evil laugh a bit before hitting
commit |
| 17:40.36 |
brlcad |
the idea of
"union" preserving interior surfaces is a brep-bastardization
implementation detail of only having boundaries and a "union"
meaning to union the boundaries instead of the volumes |
| 17:48.17 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35858 10/brlcad/trunk/ (39 files in 36 dirs):
Append v4 import/export functions with a '4'. |
| 17:49.15 |
brlcad |
er |
| 17:49.39 |
``Erik |
O.o |
| 17:49.52 |
brlcad |
waits for the diff |
| 17:50.48 |
``Erik |
now v4
doesn't have the good names, they're just as ugly as v5
:D |
| 17:51.59 |
brlcad |
heh, those
aren't the ones exactly that I had in mind |
| 17:52.08 |
brlcad |
but actually
good to be consistent there |
| 17:52.16 |
brlcad |
and none of
those I'd consider "public", so all good |
| 17:52.28 |
``Erik |
those're the
ones I was talking about moving into dbupgrade
eventually |
| 17:52.49 |
brlcad |
there's a lot
more than those needed to support v4 |
| 17:53.09 |
brlcad |
it's the
others that are problematic |
| 17:54.16 |
``Erik |
heh, like
which? (I was just looking for a bit of distraction before diving
into more adrt/isst shtuff or metaball shtuff or marching cubes or
anything) |
| 17:54.32 |
brlcad |
about half of
the funcs in src/librt/db_*.c |
| 17:54.51 |
brlcad |
those are the
ones that are public api and can't/shouldn't change |
| 17:55.09 |
``Erik |
ah, I didn't
want to touch those just yet, that'd be more v6 offsite
fodder |
| 17:56.13 |
brlcad |
maybe, but
librt could use some other refactoring love before getting to
that |
| 17:56.30 |
``Erik |
ayup |
| 17:56.48 |
brlcad |
like
encapsulating the other db objects from the core lib (attributes,
binary objects, combinations, ..) |
| 17:56.56 |
brlcad |
like the
primitives |
| 17:57.39 |
brlcad |
refactoring
rt_functab away into a set of api routines (rt_import(),
rt_export(), rt_shot(), rt_tess(), etc) |
| 17:58.23 |
``Erik |
inside of a
'primitive_s' struct? or *shudder* c++? (objC?) |
| 17:58.48 |
brlcad |
migrating
timing facilities to libbu, root solving to libbn |
| 17:59.06 |
brlcad |
hm??
no |
| 17:59.16 |
brlcad |
same
signature for the most part |
| 17:59.25 |
``Erik |
<-- is
taking his afternoon nap, btw O.o :D |
| 17:59.55 |
brlcad |
instead of
rt_sph_export(...), it'd be more like rt_export(sph,
...) |
| 18:00.22 |
brlcad |
using either
the ID like it is now or (better) using an rt_db_internal
handle |
| 18:00.29 |
``Erik |
hm |
| 18:01.06 |
brlcad |
that's what
all the mirror migration has been about, first one to go through
the motions but from start to finish |
| 18:01.07 |
``Erik |
and
rt_export() would do...? |
| 18:01.15 |
``Erik |
ah |
| 18:01.29 |
brlcad |
rt_tess() is
probably a better example |
| 18:01.41 |
CIA-28 |
BRL-CAD:
03starseeker * r35859
10/brlcad/trunk/src/librt/primitives/rhc/rhc_brep.cpp: |
| 18:01.41 |
CIA-28 |
BRL-CAD: It's
always something stupid. Needed to flip the straight line around.
This |
| 18:01.41 |
CIA-28 |
BRL-CAD:
isn't a true rhc in the sense that the curved edge isn't yet mapped
to the |
| 18:01.41 |
CIA-28 |
BRL-CAD:
'correct' hyberbolic curve per the inputs, but the basic idea of
the shape is |
| 18:01.42 |
CIA-28 |
BRL-CAD: now
working. |
| 18:02.01 |
``Erik |
rt_tess()
would be a nice jump point for something like marching cubes, I'd
imagine |
| 18:02.31 |
brlcad |
instead of
rt_sph_tess(...), becomes rt_tess(sph, ...) where you pass in the
object to tessellate (even if all it does internally is use the
functab and call rt_sph_tess() under the hood) |
| 18:03.20 |
brlcad |
right, then
the functab calls become part of the API and you don't need to know
object types -- you just pass in the database internal
pointer |
| 18:03.59 |
brlcad |
gets back to writing |
| 18:05.06 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 18:13.12 |
Yoshi47 |
i love not
having to save! |
| 18:14.07 |
d-lo |
brlcad:
writing what? if ya don't mind me askin. |
| 18:14.31 |
Yoshi47 |
my wole db
for sweetspot is only 323kB! well that is only the x slide
design. |
| 18:15.19 |
starseeker |
Yoshi47: just
out of curiosity - try running g-asc and then asc-g and see if that
gives you a smaller file (back up the original first
though!) |
| 18:15.36 |
Yoshi47 |
ok |
| 18:16.37 |
Yoshi47 |
starseeker,
you mean g2asc |
| 18:16.43 |
starseeker |
er,
yeah |
| 18:18.02 |
Yoshi47 |
699.0kB in
asc format |
| 18:18.22 |
starseeker |
now convert
that asc back to a .g |
| 18:18.26 |
starseeker |
asc2g |
| 18:18.53 |
Yoshi47 |
323.6kB
orginal and now its 312.4kB |
| 18:19.04 |
starseeker |
hmm, ok
:-) |
| 18:19.08 |
starseeker |
a little, not
much |
| 18:20.34 |
Yoshi47 |
how does it
minimize that? |
| 18:20.46 |
Yoshi47 |
what does it
get rid of? |
| 18:21.38 |
Yoshi47 |
i think i
need a faster computer! |
| 18:30.46 |
brlcad |
d-lo:
abstracts |
| 18:32.44 |
brlcad |
Yoshi47: when
objects are deleted/killed, their space is released but only reused
when something of similar/smaller size will fit, kind of like disk
fragmentation |
| 18:33.12 |
Yoshi47 |
ah |
| 18:33.29 |
brlcad |
there is a
garbage_collect command that does something similar, but
g2asc+asc2g is another "double-blind" way |
| 18:45.42 |
CIA-28 |
BRL-CAD:
03starseeker * r35860 10/brlcad/trunk/src/librt/primitives/
(bot/bot_brep.cpp ebm/ebm_brep.cpp poly/poly_brep.cpp): |
| 18:45.42 |
CIA-28 |
BRL-CAD: Get
some of the 'easy' csg-brep added - these primitives will just
convert to |
| 18:45.42 |
CIA-28 |
BRL-CAD: nmg
and use that routine. ars has some longer term interesting
possibilities, |
| 18:45.42 |
CIA-28 |
BRL-CAD: but
for replicating existing surfaces this should do OK. ebm,
which |
| 18:45.44 |
CIA-28 |
BRL-CAD:
fundamentally uses pixels and has square edges (however small)
should also be a |
| 18:45.46 |
CIA-28 |
BRL-CAD:
fairly clean if fairly massive workable nmg conversion. |
| 18:46.03 |
CIA-28 |
BRL-CAD:
03starseeker * r35861 10/brlcad/trunk/src/librt/Makefile.am: Oh
yeah, add the Makefile.am entries. |
| 18:46.16 |
brlcad |
and misc and
cmake |
| 18:46.26 |
starseeker |
ah,
right |
| 18:47.22 |
brlcad |
keep a
continuous distcheck going somewhere (wopr's good for that), should
keep things clean |
| 18:49.51 |
Yoshi47 |
is there any
way to speed up my wireframe rotating and panning? |
| 18:49.56 |
CIA-28 |
BRL-CAD:
03starseeker * r35862 10/brlcad/trunk/
(misc/win32-msvc8/librt/librt.vcproj src/librt/CMakeLists.txt): Add
other build file updates. |
| 18:50.17 |
Yoshi47 |
without
getting rid of the bolts |
| 18:51.02 |
starseeker |
Yoshi47: are
you using an opengl or an X display manager? |
| 18:51.17 |
Yoshi47 |
pretty sure
opengl |
| 18:51.17 |
starseeker |
on some
platforms ogl will be a bit faster |
| 18:51.22 |
starseeker |
hrm |
| 18:51.34 |
Yoshi47 |
running
xfce4 |
| 18:53.34 |
Yoshi47 |
is there a
way to see draw this but only show details up to a certain
measurement |
| 18:53.47 |
starseeker |
not currently
that I know of |
| 18:54.00 |
starseeker |
level of
detail is something we've been wanting to have for a while
now |
| 18:55.20 |
Yoshi47 |
guess im
going to have to find a way to hide a certain part |
| 18:58.19 |
brlcad |
Yoshi47: run
"mged -c", what does it say after attach? |
| 18:59.25 |
Yoshi47 |
(nu|X)[nu]? |
| 19:00.21 |
brlcad |
Yoshi47: part
surrogation is generally done manually pretty easily with "cp part
expensive_part ; kill part ; cp cheap_part part" .. just take care
to back up your work |
| 19:00.43 |
brlcad |
then to
restore, just the reverse to put expensive_part back in place as
that part |
| 19:00.56 |
Yoshi47 |
ya i guess
that would work |
| 19:01.39 |
brlcad |
only a
problem if you have a ton of parts like that which you need to
surrogate |
| 19:01.44 |
Yoshi47 |
and i could
just replace the threads on the bolt with a rcc for now |
| 19:01.51 |
brlcad |
right |
| 19:02.09 |
Yoshi47 |
and when i do
the rendering i can change it back |
| 19:02.32 |
brlcad |
another way
is to have a high-res and a low-res copy of the higher-level
assembly/part |
| 19:02.41 |
brlcad |
so you have
two top-levels |
| 19:02.46 |
Yoshi47 |
im waiting
for a chunk of 3x1" ALM to fall in the cut off bin
here! |
| 19:03.03 |
Yoshi47 |
ah |
| 19:03.08 |
Yoshi47 |
now you got
me thinking |
| 19:03.39 |
brlcad |
you use all
the same objects except for the few expensive ones, so it's pretty
compact and will get most changes |
| 19:04.20 |
brlcad |
that attach
prompt means your using X11 protocol to display the wireframe
presently, so you probably would get a speed boost by compiling
brl-cad with opengl support enabled |
| 19:04.45 |
Yoshi47 |
how much
boost? |
| 19:04.56 |
brlcad |
too many
factors to say |
| 19:05.44 |
Yoshi47 |
ok |
| 19:05.46 |
brlcad |
at worse, it
won't work at all or will be about the same performance-wise; at
best, could be 10x faster |
| 19:05.58 |
Yoshi47 |
umm |
| 19:06.25 |
Yoshi47 |
or i stick
the Quadro card in my computer thats in the closet? but you said
before that would really help? |
| 19:06.56 |
brlcad |
and by "won't
work at all", I mean it can conceivably crash X and your kernel if
you have really crappy drivers and a buggy version of
X11 |
| 19:07.37 |
brlcad |
you're
probably draw-limited at the moment |
| 19:08.01 |
brlcad |
so many
overlapping lines, so the quadro will only help some if it can do
2d blits faster |
| 19:08.03 |
d-lo |
brlcad:
more spam on the mailing list :/ |
| 19:08.20 |
brlcad |
d-lo: er,
which list? |
| 19:08.31 |
brlcad |
I see no spam
here |
| 19:09.09 |
brlcad |
nor did I
receive the one you replied to .. someone could be spoofing our
list as a return address to you specifically |
| 19:09.25 |
d-lo |
brlcad-commits |
| 19:09.47 |
Yoshi47 |
well im going
to try that card right now, see you on the up side |
| 19:09.49 |
Yoshi47 |
bye |
| 19:09.50 |
Yoshi47 |
exit |
| 19:10.22 |
brlcad |
forward it to
me directly |
| 19:10.28 |
brlcad |
cause I
didn't get anything |
| 19:11.41 |
d-lo |
kk
done. |
| 19:12.26 |
brlcad |
huh, I see
one that made it into the archive yesterday |
| 19:12.30 |
brlcad |
place where
we can chat |
| 19:14.14 |
brlcad |
wow, there
have been several .. yet I haven't received any of them |
| 19:14.15 |
d-lo |
bummer
:/ |
| 19:14.30 |
*** join/#brlcad Yoshi47
(n=jan@firewall.walinga.com) |
| 19:14.54 |
brlcad |
starseeker:
have you been getting them? |
| 19:14.56 |
brlcad |
or anyone
else? |
| 19:16.41 |
Yoshi47 |
yep card only
sped up it 2x maybe |
| 19:16.59 |
Yoshi47 |
now it will
help to go opengl |
| 19:19.04 |
starseeker |
brlcad: I
think I saw one |
| 19:19.17 |
louipc |
opengl makes
mged way faster for me |
| 19:19.33 |
louipc |
and with my
recent build it works perfectly :D |
| 19:20.04 |
Yoshi47 |
you want to
try and swing my xslide.c around |
| 19:20.18 |
louipc |
hmm
ok |
| 19:20.55 |
louipc |
what's
that? |
| 19:21.11 |
Yoshi47 |
http://ej.nijenhuis.pixi.me/d/2445-1/sweetspot_g?g2_GALLERYSID=955f3394427280e58ccda866d6750dec |
| 19:21.17 |
Yoshi47 |
B
xslide.c |
| 19:22.26 |
louipc |
woo |
| 19:22.40 |
Yoshi47 |
woo or
ooww |
| 19:22.51 |
louipc |
both |
| 19:22.53 |
Yoshi47 |
ouch? |
| 19:22.57 |
louipc |
my computer
is slow anyways hahh |
| 19:22.59 |
Yoshi47 |
does it
lag? |
| 19:23.04 |
louipc |
yeah |
| 19:23.07 |
Yoshi47 |
lol |
| 19:23.13 |
Yoshi47 |
those bolts
are nasty |
| 19:24.19 |
louipc |
how'd you do
the threads? |
| 19:25.09 |
brlcad |
starseeker:
just one? |
| 19:25.19 |
brlcad |
it says there
were about 15 in the last month |
| 19:25.43 |
brlcad |
pretty steady
at a rate of about one every other day going back several months ..
oddly haven't seen any that I can recall |
| 19:26.33 |
brlcad |
something
must be filtering them before I even see them .. wonder if it's
something sf.net is doing, or on my end |
| 19:26.34 |
Yoshi47 |
got it of
brlcad.org |
| 19:26.50 |
Yoshi47 |
hex
database |
| 19:27.38 |
louipc |
oh |
| 19:29.09 |
brlcad |
starseeker:
looks like you're set up for digest .. do you see any in your
previous digests? |
| 19:31.22 |
starseeker |
brlcad: can't
tell from here - they get copied to my home machine |
| 19:31.23 |
Yoshi47 |
louipc, now
can you give my file back so you don't rip my design
off? |
| 19:31.47 |
louipc |
uh where do I
put it? |
| 19:31.50 |
brlcad |
i see how
they're sending .. there's presently an exemption for any
sourceforge.net addresses, so they're folks that go through the
effort to create an account and post |
| 19:32.32 |
Yoshi47 |
just run it
throug dd |
| 19:32.49 |
Yoshi47 |
and then
delete it and write zeros there instead |
| 19:33.00 |
Yoshi47 |
and then put
it through the file shredder |
| 19:33.14 |
louipc |
shouldn't the
zeros be enough? |
| 19:33.16 |
d-lo |
wow, spammers
are having to work now eh? thats funny. |
| 19:33.40 |
Yoshi47 |
ya i
guess |
| 19:33.48 |
louipc |
ok |
| 19:33.50 |
Yoshi47 |
anyways im
going home |
| 19:33.56 |
Yoshi47 |
cya guys
tonight maybe |
| 19:33.59 |
louipc |
there are too
many top elements in this model :P |
| 19:34.21 |
louipc |
cheers |
| 19:34.29 |
Yoshi47 |
top
elements? |
| 19:34.41 |
louipc |
`tops` |
| 19:35.18 |
louipc |
there should
just be one called 'machine' hahh |
| 19:35.26 |
louipc |
or
something |
| 19:36.30 |
Yoshi47 |
B
sweetspot.c |
| 19:36.41 |
Yoshi47 |
i call my
machine sweetspot |
| 19:36.56 |
louipc |
ah why's
that? |
| 19:37.34 |
Yoshi47 |
well its
going to be a CNC gauntry router so i would like to get the
tolerence tight enough to hit the sweetspot! |
| 19:38.12 |
louipc |
what's the
sweetspot? |
| 19:38.19 |
*** join/#brlcad samrose_
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 19:38.19 |
Yoshi47 |
half
thou |
| 19:38.41 |
Yoshi47 |
anyways
cya! |
| 19:38.47 |
louipc |
bye |
| 19:42.24 |
brlcad |
d-lo: let me
know if you see any others .. I think that config change should
help |
| 19:43.57 |
d-lo |
kk, will
do. |
| 19:48.47 |
CIA-28 |
BRL-CAD:
03brlcad * r35863 10/brlcad/trunk/TODO: test commit, archer has
interactive editing support |
| 19:49.12 |
brlcad |
well looks
like I didn't kill commits altogether |
| 19:49.30 |
brlcad |
did you get
spam on any of the other lists? |
| 19:49.49 |
d-lo |
dunno. I
will start paying more attention now. |
| 19:49.58 |
brlcad |
i suspect not
because most of the rest only allow subscribed to send to them, if
at all |
| 19:51.02 |
brlcad |
commits
doesn't work that way as everything arrives as the subscribed
address doesn't match the sender's address (commits come from
sfuser@users.sourceforge.net) |
| 20:00.20 |
``Erik |
the more I
muddle with objc and cocoa, the more I kinda dig it |
| 20:02.22 |
brlcad |
it really is
pretty swank |
| 20:03.06 |
brlcad |
the biggest
detractor (at least for open source) is just the platform
tie-in |
| 20:04.36 |
``Erik |
hum, wonder
what the state of gnustep is these days |
| 20:04.43 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D492.dip.t-dialin.net) |
| 20:06.19 |
``Erik |
the
smalltalkiness makes me happy, but the inability to do
multimessages (even though the multiple parameter method definition
LOOKS like an attempt at multimessages) makes me sad |
| 20:19.27 |
brlcad |
still major
props to apple for adding blocks to obj-c with the new
rev |
| 20:21.36 |
brlcad |
meh on
multimessages though, minor syntax boost to not just say the object
name N times and instead just say semicolon or whatever |
| 20:23.02 |
brlcad |
multiple
params isn't an attempt, no diff than smalltalks multiparams. the
message is just the concat param1:param2:param3: |
| 20:33.07 |
``Erik |
ah, closures,
yeah... need to get my work box on leopard (or snow leopard) so'z I
can get those here |
| 20:51.15 |
starseeker |
brlcad:
what's a cline? |
| 21:05.11 |
CIA-28 |
BRL-CAD:
03starseeker * r35864 10/brlcad/trunk/ (4 files in 3 dirs): Add in
vol-nmg-brep. |
| 21:38.38 |
brlcad |
starseeker:
an old-school "pipe" description |
| 21:38.53 |
brlcad |
connected
line segments |
| 21:39.32 |
brlcad |
with an
inner/outer diameter like pipe has but just one bend radius
(spherical joints connect them) |
| 21:39.35 |
*** join/#brlcad talcite_
(n=matthew@69-196-174-79.dsl.teksavvy.com) |
| 21:42.47 |
brlcad |
the fast4-g
importer is the only thing I know of that creates them |
| 21:43.06 |
brlcad |
CLINE is one
of the FASTGEN entities |
| 21:43.44 |
brlcad |
would make
sense to convert them all over to pipes, of course, and
deprecate/remove the old cline primitive, but the effort=>payoff
is really minimal |
| 23:48.34 |
``Erik |
heh "forth:
all the power of assembly with all the ease of use of assembly"
hehehe |
| 00:21.08 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 00:24.59 |
*** join/#brlcad talcite_
(n=matthew@69-196-174-79.dsl.teksavvy.com) |
| 00:34.01 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 00:45.34 |
*** join/#brlcad talcite
(n=Matthew@69-196-174-79.dsl.teksavvy.com) |
| 00:58.31 |
Yoshi477 |
so i redid my
impeller, with all the steps laid out, now to tidy up the tutorial
and then rerun all the commands and see if i get the same
thing! |
| 00:58.37 |
Yoshi477 |
Ralith, im
close! |
| 00:58.48 |
brlcad |
awesome! |
| 00:59.30 |
Yoshi477 |
oh and i
figured soemthing out, clone -b 12 0 0 390 blade.r |
| 00:59.41 |
Yoshi477 |
you have to
add the degrees to 360 and then you get the spacing
right! |
| 00:59.48 |
Yoshi477 |
unless im
doing it wrong |
| 01:05.12 |
brlcad |
mm, sounds
like you were either doing something wrong or expecting something
wrong.. could be the starting position/orientation of
blade.r |
| 01:05.27 |
Ralith |
Yoshi477:
yay! |
| 01:05.50 |
Yoshi477 |
Tribute for
my son! |
| 01:06.28 |
Yoshi477 |
He went to
Heaven 1 year ago! |
| 01:08.30 |
brlcad |
my
condolences, presuming his departure was tragic |
| 01:09.54 |
brlcad |
sounds like a
noble tribute |
| 01:09.54 |
Yoshi477 |
He had HLH a
rare blood disease and after a year of treatments and fighting it
he passed away, considering he had this, we had lots of fun
together and there were a lot of good days, got tons of video and
he was one of the most happy kids out side the
hospital. |
| 01:10.14 |
Yoshi477 |
and then 2
months after he dies his sister got the same
thing(genetic) |
| 01:10.19 |
brlcad |
long live the
best of memories |
| 01:10.42 |
Yoshi477 |
and then she
did a different course of treatment, she got a bonemarrow
transplant in Feb, and is recovering very well! |
| 01:10.53 |
brlcad |
wow,
outstanding |
| 01:11.01 |
Yoshi477 |
she is happy
most of the time(she on steriods, kinda makes them
grumpy!) |
| 01:12.05 |
Yoshi477 |
shes a
miracle child, she was in the ICL with 4 failed organs and on the
oscillator ventilator and was the 4th kid in the 40 year history of
the hospital to come off of it and recover, so we are very thankful
for that! |
| 01:12.45 |
Yoshi477 |
anyways, if
you want to know more you can ask, other wise i will get back to
work and try to finish more of my Tribute to Hendrik! |
| 01:13.10 |
brlcad |
yeah, talk
about beating odds, fantastic to hear she's recovering |
| 01:13.26 |
Yoshi477 |
maybe i'll
post a video of last summer when he was kinda normal then you will
see he had somewhat of a happy life! |
| 01:18.23 |
Yoshi477 |
its uploading
hopefully it works! |
| 01:33.12 |
Yoshi477 |
wel lmy
cloned failed, it put an extra one in there! guess i start over and
see with 11 |
| 01:43.34 |
Yoshi477 |
brlcad, can
you render my new impeller in glass and chrome? |
| 01:45.27 |
Yoshi477 |
oh does this
movie work for anyone? http://ej.nijenhuis.pixi.me/v/Movies/00025.mpg.html |
| 01:47.31 |
Yoshi477 |
i think i
might have to resize it |
| 01:50.27 |
Yoshi477 |
brlcad, heres
a text file with all the steps needed to recreate the impeller,
http://ej.nijenhuis.pixi.me/d/2452-1/impeller.txt?g2_GALLERYSID=8d870d26847034d67e6a9b58f984d434 |
| 01:50.50 |
Yoshi477 |
if you have a
chance please render, im off for now, |
| 01:52.09 |
brlcad |
looks |
| 01:52.38 |
brlcad |
that's a dead
movie link, empty gallery |
| 01:53.33 |
Yoshi477 |
yep, i just
delete convert the huge mpg into a smaller ogg for easier inbrowser
viewing, or anotherformat if you have a suggestion? |
| 01:54.17 |
brlcad |
ogg is only
easier on linux :) |
| 01:54.55 |
Yoshi477 |
what video
format is fully support by firefox 3.5 now? |
| 01:55.35 |
brlcad |
depends on
the codecs you install |
| 01:55.55 |
brlcad |
mpg (2 or 4)
should work I'd hope |
| 01:56.13 |
Yoshi477 |
nope ogg, is
the only fully support video format for firefox 3.5 with out any
other stuff |
| 01:56.17 |
Yoshi477 |
HTML 5
standard |
| 01:57.17 |
brlcad |
it was
removed from html5 |
| 01:57.32 |
brlcad |
couple years
ago.. |
| 01:58.00 |
brlcad |
yeah, here we
go: http://en.wikipedia.org/wiki/Ogg_controversy |
| 01:58.33 |
Yoshi477 |
https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox |
| 01:58.40 |
brlcad |
ff 3.5 is
actually the only browser to support it :) |
| 01:58.53 |
Yoshi477 |
yes! |
| 01:58.58 |
Yoshi477 |
im goign to
convert and upload |
| 01:59.03 |
brlcad |
don't get me
wrong, I love ogg |
| 01:59.11 |
Yoshi477 |
are you going
to try the impeller steps? |
| 01:59.27 |
brlcad |
just not yet
very practical video format for most still yet |
| 01:59.31 |
brlcad |
already
tried |
| 01:59.41 |
brlcad |
you have some
globbing in there so I couldn't just source it |
| 02:02.30 |
Yoshi477 |
really, i
tried it and it worked |
| 02:02.33 |
Yoshi477 |
umm what
lines? |
| 02:02.59 |
CIA-28 |
BRL-CAD:
03brlcad * r35865 10/brlcad/trunk/TODO: a db_glob expression that
doesn't match anything should not return the
expression. |
| 02:03.39 |
brlcad |
you can type
it |
| 02:03.41 |
brlcad |
you can't
source it |
| 02:03.58 |
brlcad |
globbing is
not available via source command |
| 02:04.07 |
Yoshi477 |
globbing? |
| 02:04.08 |
brlcad |
well it is,
but not the same way |
| 02:04.10 |
Yoshi477 |
im
lost |
| 02:04.15 |
brlcad |
don't worry
about it :) |
| 02:04.25 |
Yoshi477 |
oh |
| 02:04.31 |
brlcad |
I got it to
work with a one-line tweak |
| 02:04.36 |
Yoshi477 |
lol |
| 02:04.40 |
Yoshi477 |
i figured you
would |
| 02:05.12 |
Yoshi477 |
how detail
should i make the tutorial, for total newbies or someone who know
how to use the interface? |
| 02:06.50 |
brlcad |
there is a
typo somewhere in your script though |
| 02:06.52 |
brlcad |
the clone
line |
| 02:07.01 |
brlcad |
there's a
kill embedded |
| 02:08.08 |
Yoshi477 |
yep got it,
thanks |
| 02:09.19 |
*** join/#brlcad KingofCSU
(n=king@222.247.155.229) |
| 02:10.49 |
brlcad |
also it
doesn't make an impeller for me :) |
| 02:10.59 |
brlcad |
the booleans
don't seem right |
| 02:11.00 |
Yoshi477 |
huh? |
| 02:11.08 |
Yoshi477 |
i tried it 2
times on this side |
| 02:14.11 |
Yoshi477 |
the clone
should also be 13! |
| 02:14.34 |
brlcad |
try this,
comment out the kill line, then run: |
| 02:14.40 |
brlcad |
mged -c
impeller.g "source impeller.mged ; e impeller.c ; rt" |
| 02:14.50 |
brlcad |
where
impeller.mged is your script |
| 02:15.02 |
brlcad |
and
impeller.g doesn't exist yet |
| 02:15.35 |
Yoshi477 |
if i changed
clone to 13 |
| 02:15.44 |
Yoshi477 |
or not i have
a impeller |
| 02:16.53 |
Yoshi477 |
can i just
leave my text file as is and rename to impeller.mged |
| 02:17.18 |
brlcad |
you an just
put the name of your test file |
| 02:17.43 |
brlcad |
mged -c
blah.g "source whatever ; e impeller.c ; rt" |
| 02:18.09 |
Yoshi477 |
ouch |
| 02:18.28 |
Yoshi477 |
your right,
but if i do it line by line it works? |
| 02:18.29 |
Yoshi477 |
wierd |
| 02:19.12 |
Yoshi477 |
does it
follow the script in order and line by line? |
| 02:19.24 |
brlcad |
yeah |
| 02:19.54 |
brlcad |
g_diff your.g
blah.g |
| 02:20.01 |
brlcad |
will compare
to .g files and report the differences |
| 02:21.35 |
Yoshi477 |
why does kill
*1300 work in mged and not in the script? |
| 02:22.03 |
Yoshi477 |
Segmentation
fault |
| 02:22.06 |
Yoshi477 |
when
g_diff |
| 02:22.56 |
brlcad |
via the
source command, it has to do with globbing |
| 02:23.23 |
Yoshi477 |
ah, ok well i
got to get to bed, |
| 02:23.23 |
brlcad |
huh, would be
interested in seeing the stack trace for the segfault |
| 02:23.32 |
Yoshi477 |
command? |
| 02:23.45 |
brlcad |
globbing is a
detail you probably don't really want to think about just yet
:) |
| 02:23.55 |
Yoshi477 |
at least not
tonight |
| 02:23.58 |
brlcad |
right |
| 02:24.16 |
Yoshi477 |
so how do i
get the stack trace? strace? |
| 02:24.21 |
brlcad |
no |
| 02:24.33 |
brlcad |
gdb --args
g_diff your.g blah.g |
| 02:24.35 |
brlcad |
run |
| 02:24.37 |
brlcad |
bt |
| 02:24.43 |
Yoshi477 |
bt? |
| 02:24.51 |
brlcad |
you type
those two into gdb |
| 02:24.55 |
brlcad |
run |
| 02:24.56 |
brlcad |
bt |
| 02:25.12 |
brlcad |
it's the
short-hand for backtrace |
| 02:25.26 |
Yoshi477 |
This GDB was
configured as "x86_64-pc-linux-gnu"... |
| 02:25.26 |
Yoshi477 |
run: No such
file or directory. |
| 02:25.26 |
Yoshi477 |
/opt/brlcad/bin/bt: No such file or
directory. |
| 02:25.26 |
Yoshi477 |
(gdb) |
| 02:25.32 |
brlcad |
no |
| 02:25.43 |
brlcad |
you didn't
run the gdb --args line |
| 02:25.51 |
brlcad |
gdb --args
g_diff fileA fileB |
| 02:26.20 |
brlcad |
whatever
command you ran that segfaulted, just put "gdb --args" in front of
it |
| 02:26.27 |
Yoshi477 |
(gdb)
run |
| 02:26.27 |
Yoshi477 |
Starting
program: /opt/brlcad/bin/g_diff
/data/media/documents/CAD/Impeller/impeller_tutorial.g
/home/josiah/impeller.g |
| 02:26.27 |
Yoshi477 |
[Thread
debugging using libthread_db enabled] |
| 02:26.27 |
Yoshi477 |
[New Thread
0x7f14dd084700 (LWP 22822)] |
| 02:26.27 |
Yoshi477 |
Program
received signal SIGSEGV, Segmentation fault. |
| 02:26.28 |
Yoshi477 |
[Switching to
Thread 0x7f14dd084700 (LWP 22822)] |
| 02:26.30 |
Yoshi477 |
bu_argv0_full_path () at
brlcad_path.c:163 |
| 02:26.32 |
Yoshi477 |
163brlcad_path.c: No such file or
directory. |
| 02:26.34 |
Yoshi477 |
in
brlcad_path.c |
| 02:26.39 |
Yoshi477 |
(gdb)
bt |
| 02:26.40 |
Yoshi477 |
#0
bu_argv0_full_path () at brlcad_path.c:163 |
| 02:26.42 |
Yoshi477 |
#1
0x00007f14cdeddba1 in tclcad_auto_path (interp=0x60a7f0) at
tclcadAutoPath.c:249 |
| 02:26.44 |
Yoshi477 |
#2
0x0000000000403d7f in main (argc=<value optimized out>,
argv=0x7fffe50c7f20) at g_diff.c:974 |
| 02:26.52 |
brlcad |
thanks |
| 02:26.56 |
Yoshi477 |
np |
| 02:27.00 |
Yoshi477 |
thanks for
the patience! |
| 02:27.21 |
Yoshi477 |
well i'll cya
tomorrow, |
| 02:27.24 |
brlcad |
cya! |
| 03:10.51 |
starseeker |
snorts. Yeah, a default video codec in all browsers is
currently impossible. |
| 03:11.21 |
starseeker |
The
commercial guys want something where they can buy rights to
patents/license codecs so they know they're in the clear, and the
open source guys won't touch anything like that |
| 03:12.50 |
starseeker |
two opinions
on that topic - one is that only something untaintable by patents
is workable (ogg crowd) and the school that says such a beast is
legally impossible under the current system (commercial folk,
afraid a patent will appear of of nowhere to make
trouble) |
| 03:20.33 |
starseeker |
wonders if a container format could be tweaked to query the
player for a list of supported codecs and then submit a load
request to the server for a supported format... |
| 03:37.01 |
starseeker |
brlcad: so
what do you want to do about converting clines to brep? |
| 03:37.21 |
starseeker |
can go
cline->pipe->brep or implement two brep routines |
| 03:44.19 |
brlcad |
cline is a
lot like old bspline/nurbs |
| 03:44.55 |
brlcad |
it should be
easy enough to write a cline_to_pipe routine that goes from one
internal to the other, so you can call the pipe
routines |
| 03:45.18 |
brlcad |
wouldn't
implement it twice, not worth it |
| 03:46.39 |
brlcad |
should be
officially gutted for v6 and put on the chopping block, make
fast4-g bring in pipes instead and make cline go away when v5
disappears (having it call pipe routines in the
meantime) |
| 03:47.41 |
brlcad |
an entire day
to write one fncking paragraph.. this is so bass
ackwards |
| 04:06.00 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 04:07.43 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 04:19.34 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 04:43.14 |
*** join/#brlcad talcite
(n=Matthew@69-196-174-79.dsl.teksavvy.com) |
| 05:54.40 |
*** join/#brlcad IriX64
(n=WarLock@bas2-sudbury98-1178015333.dsl.bell.ca) |
| 07:32.47 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 10:50.37 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 10:50.37 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 10:50.37 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 10:59.32 |
*** join/#brlcad cosurg1
(n=cosurgi@atak.bl.pg.gda.pl) |
| 11:02.15 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
| 12:35.29 |
d-lo |
anyone: Are
there ss's of g3d on brlcad.org anywhere? |
| 12:49.17 |
brlcad |
yeah, there
are a few |
| 12:49.56 |
brlcad |
mafm's shots
are at http://brlcad.org/~mafm/g3d-screenshots/ |
| 12:51.57 |
brlcad |
there's at
least one at http://brlcad.org/wiki/User:Ralith
of the qt-integration |
| 12:54.09 |
starseeker |
http://bzflag.bz/~starseeker/g3d_latest.png |
| 12:58.38 |
Yoshi47 |
whats
G3D? |
| 12:59.08 |
``Erik |
experimental
gui replacement for MGED |
| 12:59.29 |
Yoshi47 |
but not being
worked on anymore, cause of archer? |
| 12:59.41 |
``Erik |
well, it's
kinda the follow-on to archer... |
| 12:59.49 |
Yoshi47 |
ah? |
| 13:00.18 |
Yoshi47 |
should i be
using it? can i? |
| 13:00.26 |
``Erik |
it's mostly
being worked on in the summers by students (usually under the GSoC
banner) |
| 13:01.18 |
``Erik |
nah, you
should just be happy that some day, there'll be a more 'modern' and
'user friendly' gui :) |
| 13:01.43 |
Yoshi47 |
ok |
| 13:01.50 |
Yoshi47 |
i'll wiat
patiently |
| 13:02.16 |
d-lo |
thanks for
the linkage! |
| 13:03.45 |
Yoshi47 |
brlcad, get
anywhere with those errors? |
| 13:13.52 |
brlcad |
Yoshi47: not
yet, I had to z too eventually :) |
| 13:14.00 |
brlcad |
hopefully
some progress later today/tonight |
| 13:14.05 |
Yoshi47 |
ah |
| 13:14.12 |
brlcad |
you can still
manually compare the two |
| 13:14.13 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 13:14.15 |
brlcad |
s/can/should/ |
| 13:14.18 |
brlcad |
speak of th
edevil |
| 13:14.21 |
brlcad |
hi
Ralith |
| 13:14.42 |
Yoshi47 |
what is he
responsible for this! |
| 13:15.04 |
brlcad |
Yoshi47: and
no, you shouldn't/can't try out the new gui just .. a bit premature
for at least a few more months until something can be
posted |
| 13:15.22 |
Yoshi47 |
sob |
| 13:18.36 |
brlcad |
user feedback
is always good, but don't really want to get side-tracked with
demos until we can do something in response, which won't be for a
while |
| 13:18.57 |
brlcad |
archer needs
to be shored up and an alpha pushed out first, get feedback from
that, iterate |
| 13:20.57 |
Yoshi47 |
yep i
understand |
| 13:24.30 |
``Erik |
huh, wsj
thinks nukes might make a comeback |
| 13:27.24 |
d-lo |
wsj? |
| 13:28.37 |
d-lo |
wall street
journal? |
| 13:28.40 |
``Erik |
wall street
journal |
| 13:28.43 |
``Erik |
there's a
link on /. |
| 13:29.20 |
Yoshi47 |
comeback?
they were never gone, they just hid them really well |
| 13:29.56 |
d-lo |
Well we
haven't built a new one in decades. meanwhile France's electrical
power is nearly all nuclear :/ |
| 13:31.24 |
d-lo |
Nuclear power
-> Electric cars/trains -> significantly less petrol
dependency. |
| 13:31.29 |
d-lo |
makes sense
to me :) |
| 13:31.40 |
Yoshi47 |
yep me
too |
| 13:32.31 |
louipc |
more solar
and wind would be nice though |
| 13:33.24 |
d-lo |
Agreed. Much
more research needs to be put into thermovoltaic and photovoltaic
techs. |
| 13:33.53 |
``Erik |
the issue
with nuke+electriccar is how to quickly recharge it I think... X
hours to recharge is unacceptable for anything but local commute,
and the batteries are wayyyy too heavy to swap out for fresh
ones |
| 13:34.12 |
d-lo |
righto.
Battery tech needs some love. |
| 13:34.42 |
d-lo |
But the only
real hurdles are battery tech and electrical generation
capacity. |
| 13:34.45 |
``Erik |
or figure out
a better way to hold the energy, fuel cells tend to have expensive
and fragile membranes last I heard |
| 13:35.32 |
``Erik |
honda has a
fuel cell electric they're putting to general market, I think? but
limited areas, hydrogen pumps aren't the most common :D |
| 13:35.53 |
``Erik |
"fcx
clarity" |
| 13:36.14 |
d-lo |
Right.
Didn't they preview that on Top Gear? I think the initial market
is California only. |
| 13:36.19 |
``Erik |
yeah |
| 13:36.36 |
``Erik |
(knew it from
top gear, googled around for the name :D ) |
| 13:38.02 |
d-lo |
tidal energy
shows promise, but again, more research needed. |
| 13:41.15 |
d-lo |
ohshi, didn't
know that Toshiba is in the Nuclear bidness. Huh... i see awesome
laptop potental here. |
| 13:41.55 |
louipc |
hehehe |
| 13:43.05 |
``Erik |
yeah, but,
uh, when the laptop 'battery' explodes... |
| 13:43.44 |
``Erik |
(seems most
japanese companies we know about have their fingers in everything,
we just hear about their cars or electronics division) |
| 13:44.56 |
d-lo |
but imagine
the uptime...... |
| 13:44.57 |
d-lo |
;) |
| 13:48.25 |
Yoshi47 |
didn't
philips or panasonic develope a methane battery for notebook, and
you could just recharge with a pressurized can! |
| 13:49.08 |
d-lo |
heh, cow fart
powered.... awesome. |
| 13:49.34 |
``Erik |
has never thought of 'uptime' as the time between explosive
launch and stuff hitting the ground before O.o |
| 13:50.33 |
Yoshi47 |
lol |
| 13:50.46 |
Yoshi47 |
cow burb!
more lethal i think |
| 13:51.11 |
``Erik |
"hold up,
need to charge my laptop" *plunkt" "mooOOOO????" |
| 13:51.56 |
Yoshi47 |
Prof "why
does it stink like manure in here!) |
| 13:54.57 |
d-lo |
Mr Fusion
> Cow Battery imho |
| 13:55.47 |
d-lo |
oh and
Nuclear reactors don't explode :P |
| 13:56.45 |
Yoshi47 |
d-lo, only if
you have homer working for you! |
| 13:57.46 |
``Erik |
but, wait,
isn't the sun a reactor? and it's exploding as speak (oohssss
nnnoooeesssss) :D |
| 13:59.17 |
d-lo |
no, its a
continous, uncontrolled reaction, not a reactor. Plus, its fusion,
and our 'tractors are fission :P |
| 14:07.27 |
Yoshi47 |
yep all we
have to do is figure out fusion and were good to go |
| 14:10.00 |
d-lo |
right.
Now... where to start... |
| 14:11.14 |
starseeker |
has always thought the concept of "desktop fusion" via very
small pockets of very high pressure was
interesting |
| 14:12.04 |
starseeker |
sorta like
how they do super-powered lasers that use as much power as the
whole USA for a femptosecond... |
| 14:12.54 |
starseeker |
so far as I
know no system has convincingly produce such a multiplier system,
but the idea is interesting |
| 14:13.17 |
_clock_ |
that would be
good for free space optics |
| 14:13.27 |
_clock_ |
big range
:) |
| 14:13.53 |
``Erik |
just happens
to vaporize the receiver? :D |
| 14:14.16 |
_clock_ |
the receiver
has to have suitable dynamic range |
| 14:15.36 |
d-lo |
is thinking something along the lines of Star
Wars! |
| 14:20.17 |
Yoshi47 |
Chain Reaction |
| 14:22.22 |
``Erik |
http://farm3.static.flickr.com/2442/3769270225_7e4aee9082.jpg |
| 14:22.55 |
brlcad |
looks like
the view from my upstairs |
| 14:23.19 |
starseeker |
that's not
how I remember Endor |
| 14:23.51 |
starseeker |
talk about
deforestatino |
| 14:23.57 |
starseeker |
deforestation
rather |
| 14:24.09 |
_clock_ |
deforestatio |
| 14:24.13 |
_clock_ |
sounds like
some sexual practice |
| 14:24.18 |
starseeker |
can't type today, fingers sore after hammering on laminate
flooring |
| 14:24.20 |
``Erik |
http://www.vimeo.com/2587071
heh |
| 14:24.47 |
d-lo |
starseeker:
did you get the snap-fit stuff? |
| 14:25.00 |
starseeker |
d-lo:
yeah |
| 14:25.07 |
starseeker |
even that's
taken some time we dont' have to spare |
| 14:26.04 |
d-lo |
Suckage. Are
you done? |
| 14:26.45 |
starseeker |
close |
| 14:26.53 |
starseeker |
have to cut
some holes for floor vents |
| 14:26.59 |
_clock_ |
with
megalaser |
| 14:27.04 |
starseeker |
then do the
closet |
| 14:27.17 |
starseeker |
so lot of
square footage down, but the hard parts remain |
| 14:28.10 |
starseeker |
what we do
have in looks really nice, expecially after the sucky blue
carpet |
| 14:31.35 |
``Erik |
(shoulda had
a housewarming party before ya started, so we could get the
before/after impression :) |
| 14:32.01 |
Yoshi47 |
took video before any renos |
| 14:32.32 |
d-lo |
``Erik: nice
video link. :) |
| 14:33.07 |
d-lo |
Yeah, I love
how new wood flooring looks :) |
| 14:33.40 |
_clock_ |
``Erik: you
know you could save some heating cost with housewarming
parties? |
| 14:35.06 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D0CA.dip.t-dialin.net) |
| 14:47.00 |
d-lo |
starseeker:
You taking before/after pictures? |
| 14:50.14 |
starseeker |
not so far -
no time :-/ |
| 14:50.22 |
starseeker |
we have saved
the listing photos |
| 14:50.30 |
starseeker |
they give a
rough idea |
| 15:07.54 |
CIA-28 |
BRL-CAD:
03starseeker * r35866 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: Add
verbosity options to 3dm-g to get Dump statements for various types
of geometry, add -r option to optionally randomize
colors. |
| 15:09.50 |
CIA-28 |
BRL-CAD:
03starseeker * r35867 10/brlcad/trunk/NEWS: Whoops, update
NEWS |
| 15:16.01 |
CIA-28 |
BRL-CAD:
03starseeker * r35868
10/brlcad/trunk/src/librt/primitives/rhc/rhc_brep.cpp: Clean up
rhc_brep.cpp a bit. |
| 15:45.32 |
CIA-28 |
BRL-CAD:
03starseeker * r35869 10/brlcad/trunk/ (5 files in 4 dirs): Add a
tempate for rpc_brep - not freeing something correctly, rhc and rpc
are incompatible in csgbrep and kill everything trying to run
it. |
| 15:52.36 |
CIA-28 |
BRL-CAD:
03starseeker * r35870
10/brlcad/trunk/src/librt/primitives/rhc/rhc_brep.cpp: This is not
the right way to do it apparently, but will need to be setting
weights for this case. |
| 16:08.45 |
*** join/#brlcad Ralith
(n=ralith@d142-058-091-141.wireless.sfu.ca) |
| 16:52.25 |
CIA-28 |
BRL-CAD:
03starseeker * r35871
10/brlcad/trunk/src/librt/primitives/rpc/rpc_brep.cpp: No idea if
this solution is general but first correct nurbs rpc
representation. |
| 16:57.44 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 17:02.53 |
*** join/#brlcad samrose_
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 17:17.48 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 19:52.02 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D0CA.dip.t-dialin.net) |
| 20:17.01 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 21:19.16 |
CIA-28 |
BRL-CAD:
03122.49.210.50 07http://brlcad.org
* r1616 10/wiki/Main_Page: /* Third-party Projects */ |
| 21:35.06 |
CIA-28 |
BRL-CAD:
03bob1961 * r35872 10/brlcad/trunk/ (5 files in 3
dirs): |
| 21:35.06 |
CIA-28 |
BRL-CAD:
Added code to split up a display list if part of the list is no
longer being |
| 21:35.06 |
CIA-28 |
BRL-CAD:
displayed. That is, if "all.g" which contains "tor.r", "box.r",
"platform.r", |
| 21:35.06 |
CIA-28 |
BRL-CAD:
"cone.r", "ellipse.r" and "light.r" was originally being display
and "all/tor.r" |
| 21:35.06 |
CIA-28 |
BRL-CAD: was
removed from the display then the display list for "all" would be
split up |
| 21:35.09 |
CIA-28 |
BRL-CAD: into
the following new lists: "all.g/box.r", "all.g/platform.r",
"all.g/cone.r", |
| 21:35.11 |
CIA-28 |
BRL-CAD:
"all.g/ellipse.r" and "all.g/light.r". |
| 22:42.37 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r1617
10/wiki/Main_Page: Undo revision 1616 by
[[Special:Contributions/122.49.210.50|122.49.210.50]] ([[User
talk:122.49.210.50|Talk]]) |
| 22:42.56 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:122.49.210.50]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
| 22:45.05 |
*** join/#brlcad puddingpimp
(n=dave@gateway.quickcircuit.co.nz) |
| 23:27.46 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35873 10/brlcad/trunk/src/adrt/ (18 files in 2
dirs): begin normalizing mode interface |
| 23:28.29 |
``Erik |
oh nifty,
automake 1.11 installs all the headers with a single ginstall call
instead of one per each |
| 01:52.29 |
*** join/#brlcad talcite__
(n=matthew@69-165-139-251.dsl.teksavvy.com) |
| 01:55.20 |
*** join/#brlcad Yoshi477
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 02:05.35 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:05.35 |
*** join/#brlcad roberthl (n=robert@rhl.me.uk) [NETSPLIT
VICTIM] |
| 02:05.39 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 02:34.50 |
*** join/#brlcad matthewmpp
(n=chatzill@66-17-80-42.sparkplugbb.net) |
| 03:05.15 |
*** join/#brlcad talcite_
(n=matthew@69-196-132-97.dsl.teksavvy.com) |
| 03:36.33 |
*** join/#brlcad matthewmpp
(n=chatzill@66-17-80-42.sparkplugbb.net) |
| 04:29.03 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 04:53.09 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 05:35.01 |
starseeker |
makes sure he has valgrind and vim+cscope working on his box
in prep for the move |
| 05:56.08 |
starseeker |
hmm -
interesting. Is there any reason BU_GETSTRUCT would be messed up
by being in a cpp file? |
| 07:15.51 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 09:16.51 |
CIA-28 |
BRL-CAD:
03d_rossberg * r35879
10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 09:16.51 |
CIA-28 |
BRL-CAD:
extended rt_pipe_ck() by a check of inner_diameter <
outer_diameter and used this to do the check of a pipe's
correctness in rt_pipe_adjust() at the end of the
function |
| 09:16.51 |
CIA-28 |
BRL-CAD: this
way an only temporary invalid pipe segment will not be considered
as an error any more |
| 11:00.29 |
CIA-28 |
BRL-CAD:
03d_rossberg * r35880 10/brlcad/trunk/NEWS: |
| 11:00.29 |
CIA-28 |
BRL-CAD: in
rt_pipe_adjust() an only temporary invalid pipe segment will not be
considered as an error any more |
| 11:00.29 |
CIA-28 |
BRL-CAD:
(revision 35879) |
| 11:03.03 |
*** join/#brlcad d_rossberg
(n=rossberg@66.111.56.50) |
| 12:01.07 |
*** join/#brlcad talcite_
(n=matthew@69-196-132-97.dsl.teksavvy.com) |
| 12:01.50 |
brlcad |
starseeker:
good luck with the move and valgrinding :) |
| 12:02.18 |
brlcad |
and no,
shouldn't be a problem, it's just a malloc call |
| 12:02.42 |
brlcad |
d_rossberg:
awesome :) |
| 12:05.40 |
``Erik |
heh http://www.collegehumor.com/video:1811646 |
| 12:19.38 |
Yoshi47 |
now thats
funny, you see the phone fight |
| 12:30.31 |
``Erik |
hrm? |
| 12:31.09 |
Yoshi47 |
same
website, |
| 12:31.29 |
``Erik |
I'm sure I've
seen it, not quite recalling which it is |
| 12:31.57 |
Yoshi47 |
man do
threads take a long time to render! |
| 12:32.35 |
``Erik |
depends on
how they're defined |
| 12:32.49 |
Yoshi47 |
really
accurate! |
| 12:32.56 |
Yoshi47 |
from the hex
database |
| 12:33.03 |
``Erik |
"hex
database"? |
| 12:33.13 |
``Erik |
the thing
clock came up with? with all the tgc's? |
| 12:33.14 |
Yoshi47 |
off of
brlcad.org |
| 12:33.38 |
Yoshi47 |
i think
so |
| 12:34.20 |
``Erik |
that's a
brutal overlap case, try hitting it with facetize and a pretty good
tolerance, see if it's still "good enough" and faster |
| 12:34.45 |
``Erik |
(or if you
can think of a better way to define them until 'rotate' and 'sweep'
are fully online...) |
| 12:34.47 |
Yoshi47 |
you lost
me! |
| 12:35.09 |
Yoshi47 |
i know
nothign of facetize |
| 12:35.18 |
``Erik |
the
"facetize" command converts geometry to "BoTs", calculated triangle
soup |
| 12:36.33 |
Yoshi47 |
hrm... |
| 12:36.38 |
``Erik |
instead of
computing a bajillion tgc's and doing all the bool weave stuff to
get your end bolt, you could facetize it and just have a bunch of
triangles to test, instead... should be less computationally
expensive to raytrace |
| 12:36.59 |
Yoshi47 |
im
scared |
| 12:37.08 |
``Erik |
the trick is
balancing accuracy vs performance, since it's an
approximation |
| 12:37.12 |
Yoshi47 |
wondering
whats going to happen |
| 12:37.15 |
``Erik |
it's ok,
baby, it only hurts at first |
| 12:37.18 |
``Erik |
O;-) |
| 12:37.21 |
Yoshi47 |
lol |
| 12:37.55 |
``Erik |
make some
scrap geometry like a sphere and try 'facetize' on it, it
tesselates the geometry into a new primitive for ya |
| 12:38.00 |
``Erik |
(when it
works) |
| 12:38.13 |
Yoshi47 |
so if i have
4 bolts that i subtract from a block to make inner threads, i would
facetize the 4 bolts and it would still work, but the 4 bolts that
are going in the threaded hole i would have to facetize too so
there is no overlaps? |
| 12:39.06 |
``Erik |
you'd have,
say, a region made up of some complex geometry, thousands of
primitives |
| 12:39.13 |
``Erik |
then you'd
facetize, say, the region |
| 12:39.21 |
``Erik |
and get a
single 'bot' primitive with roughly the same geometry |
| 12:39.57 |
``Erik |
it does not
alter existing geometry, it creates new geometry, it's pretty safe
:) |
| 12:40.45 |
Yoshi47 |
oh so i would
do it to my whole combination that contains the threads and bolts
and bearings? |
| 12:41.05 |
Yoshi47 |
i'll do a
backup first |
| 12:41.13 |
``Erik |
whatever you
want to become a new single primitive |
| 12:41.21 |
Yoshi47 |
cool |
| 12:41.24 |
Yoshi47 |
im going to
try |
| 12:41.54 |
``Erik |
for the
bearing, I'd probably facetize the inner runner, outer runner, each
bearing, etc... so each bot is independent |
| 12:42.26 |
``Erik |
slaps an outboard motor on his car and sees if it stays
floating all the way to work |
| 12:43.36 |
Yoshi47 |
so facetize
newpart old part, or should i use the options, i read them but
don't know if i need to use them or not |
| 12:49.55 |
Yoshi47 |
i think it
froze? it was going through all the lines of parts but now its not
moving and then menus in mged aren't doing anything
either |
| 13:02.06 |
brlcad |
http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/09-10-2009/0005091867&EDATE= |
| 13:03.58 |
brlcad |
Yoshi47:
facetizing one of those bolts is going to take a very long
time |
| 13:04.07 |
brlcad |
check your
cpu, it's probably burning |
| 13:04.19 |
Yoshi47 |
ok, then i'll
let it go for the day or weekend! |
| 13:04.21 |
brlcad |
by "long
time", possibly several hours |
| 13:04.41 |
Yoshi47 |
shes only
using one cpu, that leaves the other for me to use for other stuff
so i can still work |
| 13:04.58 |
brlcad |
I think when
I last ran it on his bolts, there were a handful of bolts in the
model and it took 26 hours |
| 13:05.19 |
brlcad |
yeah, it's
only a single-cpu process .. part why it's slow |
| 13:30.21 |
brlcad |
``Erik: heh,
you'll probably appreciate this if you haven't seen it yet:
http://www.youtube.com/watch?v=Sqz5dbs5zmo&feature=channel_page |
| 13:46.16 |
``Erik |
ok, will
farrel as neil diamond... that's... just... wrong... |
| 13:48.54 |
``Erik |
recognized
sandberg, had to dig a bit to figure out why heh |
| 14:04.36 |
CIA-28 |
BRL-CAD:
0362.80.184.178 07http://brlcad.org
* r1619 10/wiki/Main_Page: /* Third-party Projects */ |
| 14:07.04 |
CIA-28 |
BRL-CAD:
03Sean 07http://brlcad.org * r1620
10/wiki/Main_Page: Undo revision 1619 by
[[Special:Contributions/62.80.184.178|62.80.184.178]] ([[User
talk:62.80.184.178|Talk]]) |
| 14:09.05 |
``Erik |
spam spam
spam and egg salad |
| 14:09.17 |
brlcad |
it wasn't
really spam, just pointless |
| 14:09.30 |
brlcad |
someone added
a link to wikipedia |
| 14:09.33 |
``Erik |
most wiki
updates seem to be spam or antispam lately |
| 14:09.54 |
brlcad |
because
nobody is editing the wiki, sure :) |
| 14:10.07 |
``Erik |
that
alienware laptop is impressive, but I think would be a bad thing
for 'selling' the software |
| 14:10.21 |
``Erik |
still recent
wounds from 'awe'... :) |
| 14:10.35 |
brlcad |
awe? |
| 14:10.54 |
brlcad |
oooh |
| 14:10.54 |
``Erik |
:) |
| 14:11.12 |
brlcad |
how so
though? |
| 14:11.20 |
brlcad |
it should be
faster than the go cart |
| 14:11.36 |
``Erik |
yeah, but
"speed" is secondary to "usability" at this point, I
think... |
| 14:11.36 |
brlcad |
at 15 lbs
iirc? |
| 14:12.10 |
brlcad |
true, but in
terms of a portable demo .. if that's to start |
| 14:12.17 |
brlcad |
or you're
saying it's not time to start yet |
| 14:12.37 |
brlcad |
remember how
long it might take to get said lappy :) .. |
| 14:12.42 |
``Erik |
I think
there's a feeling that you need special hardware and an expert to
use the software, one of the things I've busted ass to do is make
it so it "just works", more along the apple thinking than the linux
thinking, y'know? |
| 14:13.40 |
brlcad |
the laptop
should actually hope dispell the special hardware need |
| 14:13.54 |
brlcad |
i mean i
thought a new mbp would work fine too and it's time
anyways |
| 14:14.41 |
``Erik |
yeah *shrug*
that laptop "looks different", though, *shrug* mebbe I'm being
oversensitive to the perception thing :) |
| 14:15.22 |
``Erik |
is there an
extra copy of msvc or something floating around? I want a winderz
build and I can't coerce tcl to build sanely with
--no-cygwin |
| 14:15.46 |
brlcad |
if nobody
calls attention to it, it'll just be a black box |
| 14:16.06 |
brlcad |
hm, there
is |
| 14:17.01 |
``Erik |
drawing
attention to "and look, you probably have one of these on your
desk!" might be enough to snap any lingering
misperceptions |
| 14:17.46 |
brlcad |
or better
yet, "hey and the mac sitting on your desk is more than twice as
fast" |
| 14:18.40 |
brlcad |
mm..
/dev/cocoa libdm interface :) |
| 14:19.04 |
``Erik |
*shrug* I
have other things to worry about before a big demo |
| 14:19.06 |
brlcad |
you'd think I
would have thought about that earlier given I have the code we'd
need sitting in bz |
| 14:19.09 |
``Erik |
mostly how to
shame the team upstairs :> |
| 14:19.33 |
brlcad |
i think the
idea was for starseeker to make some rounds |
| 14:19.53 |
brlcad |
as part of a
follow-up "here's a set of cool things", adrt being one of
them |
| 14:19.59 |
``Erik |
ponders using an "icanhascheezburger" image with "UR DOIN IT
RONG" O:-) |
| 14:20.27 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FE7A.dip.t-dialin.net) |
| 14:21.01 |
*** join/#brlcad KingofCSU
(n=king@222.247.155.229) |
| 14:21.52 |
brlcad |
sent http://bzflag.bz/tmp/wrong.jpg
to his rower buddies |
| 14:21.53 |
``Erik |
(ya in today?
I'm thinkin' about lunch already heh) |
| 14:22.33 |
brlcad |
nah, day off
working from home .. so I can actually get this release out and
some announcements sent |
| 14:22.41 |
``Erik |
aight |
| 14:22.46 |
``Erik |
meditates on plugin architectures |
| 14:25.41 |
``Erik |
hehehe,
"another shotline selection tool" :D |
| 14:25.56 |
``Erik |
(or "apple
shotline selection tool"? my cocoa experiment :D) |
| 14:28.06 |
brlcad |
the "ASS
Tool" does have a certain ring to it |
| 14:31.09 |
Yoshi47 |
brlcad,
release? |
| 14:31.19 |
brlcad |
Yoshi47:
yes? |
| 14:31.28 |
Yoshi47 |
1.4.? |
| 14:31.35 |
Yoshi47 |
7.14.? |
| 14:31.36 |
Yoshi47 |
i
mean |
| 14:32.19 |
brlcad |
7.16.0 |
| 14:32.26 |
Yoshi47 |
what is the
status on rotate and sweep? |
| 14:32.32 |
brlcad |
unchanged |
| 14:32.40 |
Yoshi47 |
usable? |
| 14:32.57 |
brlcad |
rotate is
almost complete, sweep isn't started |
| 14:33.09 |
Yoshi47 |
ok |
| 14:33.11 |
Yoshi47 |
thanks |
| 14:33.37 |
Yoshi47 |
looking into
xdmx right now so i can run brlcad ontwo monitors |
| 14:33.38 |
brlcad |
pacman87_ is
unfortunately off smelling graduate roses and such :) |
| 14:33.53 |
brlcad |
otherwise
sweep would be teh awesome by now :) |
| 14:34.49 |
Yoshi47 |
would be the
awesome? like done or usable? |
| 14:35.51 |
Yoshi47 |
so what can i
expect in 7.16 for functionality as a newbie, or am i an
ammie |
| 14:36.06 |
Yoshi47 |
when do i
become a non-newbie |
| 14:38.15 |
Yoshi47 |
peopleofwalmart.com |
| 14:38.18 |
``Erik |
"teh
awesome", not "the awesome" |
| 14:38.31 |
``Erik |
teh intarwebz
is SRS BSNES!!@~ |
| 14:38.33 |
Yoshi47 |
teh? |
| 14:38.38 |
Yoshi47 |
yes im
stupid |
| 14:38.53 |
``Erik |
no, the
anticulture that came up with "teh" is stupid :D |
| 14:39.01 |
_clock_ |
agriculture? |
| 14:39.16 |
``Erik |
sends Yoshi47 to http://icanhascheezburger.com/
for "re-education" O:-) |
| 14:40.09 |
``Erik |
clock: your
bolts are brutal, but a fairly clever way to represent them
O.o |
| 14:40.56 |
_clock_ |
``Erik: hehe
thanks |
| 14:40.59 |
_clock_ |
feels proud |
| 14:45.52 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35881 10/brlcad/trunk/src/adrt/ (11 files in 3
dirs): remove obsolete shtuff (the repo remembers.) |
| 14:46.47 |
``Erik |
damnit |
| 14:47.45 |
``Erik |
"svn commit"
"ok, let me get rea" oh, wait, noooo C^^C^C^C^C^C" "fuck you, I'm
gonna lock the term and send it ANYWAYS! PTBTBTBT" |
| 14:48.13 |
``Erik |
and now my
tree is full of conflicts. *sigh* |
| 14:48.58 |
brlcad |
Yoshi47: you
can see the list of user-visible changes for each release at
http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/NEWS |
| 14:49.27 |
brlcad |
investigates libdispatch |
| 14:49.42 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35882 10/brlcad/trunk/src/adrt/Makefile.am:
remove obsolete shtuff (the repo remembers.) |
| 14:51.26 |
``Erik |
oh, the
'magic' parallel computation for osX? |
| 14:55.52 |
brlcad |
yeah, they
open sourced it |
| 14:56.57 |
``Erik |
distchecks to see what he broke |
| 14:57.11 |
brlcad |
removing
subproject authors and readme? |
| 14:57.26 |
``Erik |
among other
things |
| 14:57.55 |
brlcad |
the other
things aren't interesting :) |
| 14:57.58 |
``Erik |
working
towards more integration, less 'subproject'ness |
| 14:59.51 |
brlcad |
hm,
okay |
| 14:59.55 |
``Erik |
was thinking about merging the ChangeLog into the toplevel
one, but *shrug* |
| 15:00.00 |
brlcad |
those two
aren't necessarily orthogonal, though :) |
| 15:00.35 |
brlcad |
e.g.,
thinking of making several of the libs more proper
sub-projecty |
| 15:00.45 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r35883 10/brlcad/trunk/src/adrt/ (bench/
scripts/): remove obsolete shtuff (the repo remembers.) |
| 15:01.24 |
brlcad |
libbu as a
stand-alone project, libpkg, benchmark, etc |
| 15:02.56 |
``Erik |
Xorg
style? |
| 15:03.04 |
brlcad |
yeah, sort
of |
| 15:03.19 |
``Erik |
hm |
| 15:03.24 |
brlcad |
still
unified, but a way to make them be stand-alone
distributable |
| 15:03.27 |
``Erik |
"libbu? why
not just use glib2?" |
| 15:03.34 |
*** join/#brlcad KingofCSU
(n=king@222.247.155.229) |
| 15:03.47 |
brlcad |
because libbu
is better, of course |
| 15:03.54 |
brlcad |
(and it's
closer to APR) |
| 15:04.02 |
``Erik |
*shrug* note
the double quotes there ;) |
| 15:05.20 |
brlcad |
making them
work well alone will help manage our growth complexity |
| 15:06.03 |
brlcad |
with a
formalized concept of a subproject, new devs can get involved with
a portion that is "well defined" |
| 15:06.19 |
brlcad |
without
needing to know the complexities and code creep |
| 15:06.36 |
``Erik |
amusingly, I
argued long and hard on that for the upstairs project, but I'm not
entirely sold on the approach for BRL-CAD :D |
| 15:06.47 |
brlcad |
e.g.,
liboptical would make for a horrible subproject right now as it's
horribly intermixed with librt |
| 15:07.26 |
``Erik |
yeah, ... the
"DEPENDS" tag can be used to figure out the dependancy graph (if
all targets were apropriately set) |
| 15:07.48 |
``Erik |
(adding that
was as much for me to understand how things link together as the
actual rule...) |
| 15:07.50 |
brlcad |
I also think
we'll get more exposure for folks just looking for a simple library
that does something well, for whatever their application
is |
| 15:08.45 |
``Erik |
heh, it'd
really screw with the brains of the people who think BRL-CAD and
their projects *MUST* be released at the same time
:> |
| 15:08.53 |
brlcad |
plus making a
few of the core pieces stand-alone with reinforce keeping the API
lines clean .. making sure DEPENDS stays clean |
| 15:09.35 |
brlcad |
libbu, libbn,
and libpkg are really easy ones to clean up (pkg is practically
done) |
| 15:10.35 |
brlcad |
it's not to
say separate tarballs would be required, there's still be the
brlcad.tar.gz source bundle |
| 15:11.05 |
brlcad |
but perhaps
binary distros for sub-projects that are stand-alone |
| 15:11.26 |
``Erik |
hm |
| 15:12.00 |
brlcad |
where
./configure --enable-only-benchmark ends up with a binary dist
tarball of just that stuff |
| 15:12.50 |
brlcad |
along with
sections for those projects on the website |
| 15:13.06 |
brlcad |
brlcad.org/project or similar |
| 16:46.08 |
Yoshi47 |
brlcad, i
know your busy with the release but did you ever run the impeller
render? |
| 17:08.26 |
brlcad |
Yoshi47: I
did, but I don't have it on hand at the moment |
| 17:08.41 |
Yoshi47 |
oh
ok |
| 17:08.51 |
brlcad |
you're in the
queue for a mailing announcment though :) |
| 17:08.52 |
Yoshi47 |
both chrome
and glass? or just one? |
| 17:09.10 |
Yoshi47 |
ok |
| 17:09.10 |
brlcad |
you saw the
glass one right? |
| 17:09.12 |
brlcad |
http://brlcad.org/tmp/impeller.png |
| 17:09.27 |
Yoshi47 |
the first one
yes, but i redid the impeller from scratch for the
tutorial |
| 17:09.38 |
Yoshi47 |
didi you do
my new impeller or the old one |
| 17:10.02 |
brlcad |
erm, the only
one I had so it should have been the new one |
| 17:10.04 |
Yoshi47 |
looks like
the old one, the new one has a keyway |
| 17:10.12 |
brlcad |
otherwise I
would have been able to give you the .g |
| 17:10.29 |
brlcad |
o.O |
| 17:11.20 |
brlcad |
can check the date/logs :) |
| 17:11.59 |
``Erik |
*burp* |
| 17:12.06 |
Yoshi47 |
i uploaded
the txt file and you could recreate it line by line... but you
decided to be lazy and try it in one command but that didn't
work |
| 17:12.52 |
Yoshi47 |
i never gave
you the g code, i can if you want? but i figured you could just
test out my tutorial lines like someone who would be learning it
would |
| 17:13.05 |
CIA-28 |
BRL-CAD:
03bob1961 * r35884
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: Fixed a
bug that was causing left-hand rule bots to raytrace
incorrectly. |
| 17:14.38 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-141.wireless.sfu.ca) |
| 17:16.09 |
brlcad |
heh, not just
lazy .. that should work as part of normal behavior .. something is
wrong somewhere |
| 17:16.30 |
brlcad |
either a bug
in the sourcing command, or a bug in the script |
| 17:17.19 |
Yoshi47 |
ah |
| 17:17.39 |
Yoshi47 |
i tried it
line by line in mged and it worked, and i did it 3
times |
| 17:20.17 |
brlcad |
things to try
turning off glob compat and trying line by line that way, or
sourcing more and more of the file until it doesn't match, or
simply reviewing the two outputs (manually and sourced) to see what
is different |
| 18:22.34 |
*** join/#brlcad surje
(n=surje@202.3.77.11) |
| 18:33.50 |
CIA-28 |
BRL-CAD:
03brlcad * r35885 10/brlcad/trunk/NEWS: |
| 18:33.50 |
CIA-28 |
BRL-CAD: bob
fixed a bug with BoT ray tracing where it wasn't correctly
identifying the |
| 18:33.50 |
CIA-28 |
BRL-CAD:
bot_orientation for left-handed BoTs, which made them render wrong.
Swapped |
| 18:33.50 |
CIA-28 |
BRL-CAD:
bot_mode with bot_orientation and the problem is fixed. (those
should be |
| 18:33.50 |
CIA-28 |
BRL-CAD:
typedefs so we could have gotten a type error). |
| 18:55.09 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 18:59.03 |
indianlarry |
starseeker:
Can you convert the 'shape1' geom to step and put out under your
'bz' directory? |
| 18:59.15 |
indianlarry |
Left my copy
there... |
| 19:03.34 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FE7A.dip.t-dialin.net) |
| 19:05.32 |
starseeker |
indianlarry:
sorry, moving today :-( |
| 19:08.26 |
indianlarry |
starseeker:
No biggy just playin... |
| 19:10.00 |
brlcad |
indianlarry:
pm |
| 19:11.47 |
indianlarry |
brlcad:
pm? |
| 19:11.54 |
brlcad |
~pm |
| 19:11.55 |
ibot |
well, pm is
project manager, or private message, or perl mongers, or pathetic
moron: when you see someone say pm, they're asking if you think
that they're a pathetic moron, or something you don't do without
asking permission |
| 19:12.03 |
brlcad |
heh |
| 19:12.05 |
brlcad |
privmsg |
| 19:13.20 |
brlcad |
ctrl-n
:) |
| 19:19.03 |
*** join/#brlcad talcite
(n=Matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 19:23.37 |
louipc |
prime
minister |
| 19:26.49 |
brlcad |
post
meridian |
| 19:27.06 |
indianlarry |
phat
man |
| 19:27.26 |
brlcad |
punny
monkey |
| 19:28.03 |
CIA-28 |
BRL-CAD:
03bob1961 * r35886
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Mods to
accomodate the move of arbn_brep.cpp |
| 19:33.29 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FE7A.dip.t-dialin.net) |
| 19:35.19 |
alex_joni |
pm =
picometer |
| 19:35.25 |
CIA-28 |
BRL-CAD:
03brlcad * r35887 10/brlcad/trunk/NEWS: |
| 19:35.25 |
CIA-28 |
BRL-CAD: in
rt_pipe_adjust() an only temporary invalid pipe segment will not
be |
| 19:35.25 |
CIA-28 |
BRL-CAD:
considered as an error any more (reword for brevity, release prep,
revision |
| 19:35.25 |
CIA-28 |
BRL-CAD:
35879). this addresses a problem reported by randerson303 on
discussion forum |
| 19:35.25 |
CIA-28 |
BRL-CAD:
where a g2asc+asc2g would fail with a bot outer diameter must be
larger than |
| 19:35.28 |
CIA-28 |
BRL-CAD:
inner diameter error. |
| 19:35.33 |
CIA-28 |
BRL-CAD:
03bob1961 * r35888
10/brlcad/trunk/src/external/ProEngineer/proe-brl.c: |
| 19:35.33 |
CIA-28 |
BRL-CAD: Even
though proe spits out left-hand rule triangles, set things back to
have |
| 19:35.34 |
CIA-28 |
BRL-CAD: "no"
orientation in case proe ever spits out a mixed bag of left and
right hand |
| 19:35.36 |
CIA-28 |
BRL-CAD:
triangles. While we're at it, since proe seems to be spitting out
left-hand rule |
| 19:35.40 |
CIA-28 |
BRL-CAD:
triangles (i.e. clockwise), reverse this to be right-hand rule
(i.e. |
| 19:35.42 |
CIA-28 |
BRL-CAD:
counter-clockwise) so that shaded-mode works properly without
having to run |
| 19:35.44 |
CIA-28 |
BRL-CAD:
bot_flip. |
| 19:57.46 |
CIA-28 |
BRL-CAD:
03brlcad * r35889 10/brlcad/trunk/NEWS: bob changed the pro/e
exporter to output bots with a right-hand ordering, but the bot is
labeled as unoriented just in case there are mixed-orientations
being output for some objects. |
| 20:06.17 |
CIA-28 |
BRL-CAD:
03brlcad * r35890 10/brlcad/trunk/TODO: |
| 20:06.17 |
CIA-28 |
BRL-CAD: need
something like a 'select' command for libged so that there can be
stateful |
| 20:06.17 |
CIA-28 |
BRL-CAD:
namable temporary selections/groupings of objects. this allows a
command-line |
| 20:06.17 |
CIA-28 |
BRL-CAD:
mechanism for common gui selection operations (band select, clicked
selections, |
| 20:06.17 |
CIA-28 |
BRL-CAD:
volumetric selections). |
| 20:10.30 |
CIA-28 |
BRL-CAD:
03brlcad * r35891 10/brlcad/trunk/TODO: oh yeah, can replace
sphgroup with select. |
| 20:16.40 |
brlcad |
indianlarry:
ping |
| 20:16.47 |
CIA-28 |
BRL-CAD:
03brlcad * r35892 10/brlcad/trunk/NEWS: |
| 20:16.47 |
CIA-28 |
BRL-CAD: this
is cool. bob implemented support for sub-object erasures where you
can |
| 20:16.47 |
CIA-28 |
BRL-CAD:
d/erase an object within a currently displayed object. it will
expand the |
| 20:16.47 |
CIA-28 |
BRL-CAD:
display list to the list of sub-objects still currently displayed
(e.g. e all.g; |
| 20:16.47 |
CIA-28 |
BRL-CAD: d
all.g/platform.r; who; and it'll report all.g/cone.r all.g/light.r,
etc). |
| 20:29.24 |
``Erik |
http://www.techcrunch.com/2009/09/10/yeah-ok-so-facebook-punkd-us/
nice |
| 20:31.42 |
CIA-28 |
BRL-CAD:
03brlcad * r35893 10/brlcad/trunk/NEWS: bob added bot_flip and
bot_sync commands to archer (which should be nearly all or all of
them now). |
| 20:36.12 |
CIA-28 |
BRL-CAD:
03brlcad * r35894 10/brlcad/trunk/NEWS: |
| 20:36.12 |
CIA-28 |
BRL-CAD:
stephen 'el magnifico' kennedy wrote a procedural human geometry
generator |
| 20:36.12 |
CIA-28 |
BRL-CAD:
(called 'human') that was added to mged and archer. in addition to
a |
| 20:36.12 |
CIA-28 |
BRL-CAD:
command-line command, there's an initial (possibly non-functioning)
archer |
| 20:36.12 |
CIA-28 |
BRL-CAD:
plugin gui too. |
| 20:37.53 |
CIA-28 |
BRL-CAD:
03brlcad * r35895 10/brlcad/trunk/NEWS: |
| 20:37.53 |
CIA-28 |
BRL-CAD:
reword as it wasn't added to mged... stephen 'el magnifico' kennedy
wrote a |
| 20:37.53 |
CIA-28 |
BRL-CAD:
procedural human geometry generator (called 'human') that was added
to archer. |
| 20:37.53 |
CIA-28 |
BRL-CAD: in
addition to a command-line command, there's an initial
(possibly |
| 20:37.53 |
CIA-28 |
BRL-CAD:
non-functioning) archer plugin gui too. implemented with bob's help
of course. |
| 20:38.34 |
*** join/#brlcad Ralith
(n=ralith@d142-058-081-105.wireless.sfu.ca) |
| 20:40.47 |
*** join/#brlcad talcite
(n=Matthew@134.117.143.147) |
| 20:41.48 |
brlcad |
wonders what the heck erase -o is supposed to
mean |
| 20:43.27 |
brlcad |
god, bob ..
hope you didn't use 'o' for 'only' non-unique |
| 20:44.19 |
``Erik |
want me to go
slap him? :D |
| 20:46.25 |
brlcad |
could ask him
what it means .. I see it makes it add all attribute matches .. but
I don't see why you'd not want to always do that |
| 20:46.52 |
brlcad |
trying to
pull together the release notes, that one make no sense |
| 20:48.20 |
``Erik |
he's in the
other building doing some compiles |
| 20:48.36 |
brlcad |
darn |
| 20:48.44 |
brlcad |
okay, I'll
just leave it out |
| 20:48.59 |
``Erik |
(ed said he
should be back pretty soon) |
| 20:49.47 |
CIA-28 |
BRL-CAD:
03brlcad * r35896 10/brlcad/trunk/NEWS: bob added a -A option to
the d/erase command that will erase objects that contain a
specified attribute name=val match. not documenting the odd -o
option just yet. |
| 20:52.36 |
CIA-28 |
BRL-CAD:
03brlcad * r35897 10/brlcad/trunk/NEWS: meester anderson fixed the
bigE command which wasn't reporting the display list name post
libged migration. |
| 20:53.21 |
brlcad |
gah, draw has
a -A/-o too |
| 20:55.56 |
CIA-28 |
BRL-CAD:
03brlcad * r35898 10/brlcad/trunk/NEWS: bob added a -A option to
the d/erase and e/draw commands that will erase/draw objects that
contain a specified attribute name=val match. not documenting the
odd -o option just yet. |
| 21:06.31 |
CIA-28 |
BRL-CAD:
03brlcad * r35899 10/brlcad/trunk/src/libdm/dm-rtgl.c: style ws
indent consistency cleanup |
| 21:15.19 |
*** join/#brlcad Ralith
(n=ralith@d142-058-081-105.wireless.sfu.ca) |
| 21:26.28 |
CIA-28 |
BRL-CAD:
03brlcad * r35900 10/brlcad/trunk/src/adrt/slave/g-adrt.c: remove
dead file |
| 21:32.29 |
*** join/#brlcad Ralith_
(n=ralith@d142-058-088-074.wireless.sfu.ca) |
| 21:37.58 |
*** join/#brlcad Yoshi477
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 22:22.58 |
``Erik |
brlcad:
talked to bob |
| 22:23.26 |
``Erik |
he saw the -o
and was just replicating, he didn't put any kinda focused thought
into it |
| 22:25.31 |
*** join/#brlcad talcite_
(n=matthew@69-196-132-97.dsl.teksavvy.com) |
| 00:03.10 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-74.sbndin.btas.verizon.net) |
| 00:14.41 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 00:58.37 |
*** join/#brlcad ``Erik
(i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 01:01.22 |
yukonbob |
brlcad:
online? |
| 01:01.29 |
brlcad |
nope |
| 01:01.33 |
yukonbob |
damn |
| 01:01.37 |
yukonbob |
I'll check
back later. |
| 01:01.38 |
yukonbob |
:P |
| 01:01.53 |
yukonbob |
I've got a
question, and I bet you have the answer |
| 01:02.02 |
yukonbob |
now that I
think of it, I've got lots of questions... |
| 01:02.09 |
yukonbob |
but perhaps 2
you can answer... |
| 01:02.11 |
yukonbob |
re:
dsp |
| 01:03.13 |
yukonbob |
1 -- DEM
co-ords signify the "space between" grid elems (i.e. the
intersection points of a grid, not the squares) -- is this how dsp
behaves as well? |
| 01:03.59 |
yukonbob |
2 -- can I /
how-feasible-is-it to try to skin a DSP accurately (i.e. using a
geotiff). Of course, accuracy is key. |
| 01:05.07 |
yukonbob |
geotiff ==
tiff image, but with geo-specific meta data -- so one can place
them accurately on a map, for example... |
| 01:14.42 |
brlcad |
1: yes. 2:
not sure what you mean by skin it |
| 01:14.58 |
brlcad |
never worked
with a geotiff |
| 01:17.00 |
yukonbob |
what I want
is to be able to lay the tiff down on the dsp, and if they're
representing the same square land-region, have the blue lines of
the rivers match up in the gulleys of the dsp, etc, distorting as
one would expect mapping a 2D tiff -> 3D dsp, but otherwise
"fitting properly". |
| 01:17.20 |
``Erik |
so basically
just texture it with specified uv coords? |
| 01:17.48 |
yukonbob |
right. |
| 01:18.34 |
yukonbob |
are there
diff't model for how one can apply a texture map like that, or
would it work buy default, or ?? |
| 01:18.57 |
yukonbob |
i.e. if I
have an 8x8 table, and an 8x8 table cloth, I can lay the cloth to
cover the table. |
| 01:19.33 |
yukonbob |
but if I put
a candlestick on top of the table (without the cloth), and then try
to lay the cloth, it won't cover edge-to-edge... |
| 01:19.44 |
yukonbob |
how does the
mapping work in brlcad? |
| 01:20.28 |
yukonbob |
is there a
way to have a "magic" table cloth that, because it is 8x8, will
cover the 8x8 surface... |
| 01:21.32 |
yukonbob |
, or would
one sample the tiff and then use mater to adjust the "grid"s of
the dsp? |
| 01:24.04 |
brlcad |
yukonbob:
there is a separation of the geometric shapes and rendering
properties such as texturing |
| 01:24.34 |
brlcad |
the tiff data
can be converted to a height field directly |
| 01:24.57 |
yukonbob |
tell me
more |
| 01:25.08 |
brlcad |
the tiff can
also be applied as a texture pretty easily as well with a
shader |
| 01:27.24 |
yukonbob |
researches height fields. Looks like what I need. Thx brlcad,
``Erik |
| 01:27.50 |
brlcad |
"dsp" is our
name for a height field |
| 01:27.51 |
brlcad |
dsp ==
"displacement map" |
| 01:27.52 |
yukonbob |
right --
displacement map. |
| 01:28.17 |
yukonbob |
and that can
have a (say) 800x800 TIFF, and generate an 800x800 heightfield
then? |
| 01:28.22 |
brlcad |
yes |
| 01:28.28 |
yukonbob |
awesomenessus |
| 01:28.43 |
yukonbob |
I've only
generated grey blobs so far, myself. |
| 01:28.45 |
brlcad |
though to
create a dsp, all it cares about is the raw binary
values |
| 01:28.53 |
brlcad |
so you'll
have to convert the tiff |
| 01:29.05 |
brlcad |
nothing
tricky, but a couple of data conversion steps |
| 01:29.22 |
brlcad |
probably tiff
-> png -> bw |
| 01:29.41 |
yukonbob |
brlcad: don't
know if you remember, but playing w/ dsp/DEMs was one of my first
exercises; at the time, I tickled a nasty memory leak -- was that
ever corrected? |
| 01:29.52 |
brlcad |
yeah, I
remember |
| 01:29.55 |
brlcad |
it wasn't a
leak |
| 01:30.00 |
brlcad |
it was an
inefficiency |
| 01:30.06 |
brlcad |
using more
than expected |
| 01:30.16 |
yukonbob |
nods. |
| 01:30.24 |
brlcad |
taking up 160
bytes per cell iirc |
| 01:30.27 |
yukonbob |
tuned up, or
as was? |
| 01:30.54 |
brlcad |
~(160 * 800 *
800) / 1024 / 1024 |
| 01:30.55 |
ibot |
97.65625 |
| 01:31.14 |
brlcad |
97MB
shouldn't be a problem :) |
| 01:31.38 |
yukonbob |
when I threw
800x800 out, that was only for sake of argument ;) |
| 01:31.47 |
``Erik |
~1/0 |
| 01:31.50 |
``Erik |
O:-) |
| 01:31.53 |
yukonbob |
hehe. |
| 01:32.12 |
yukonbob |
<PROTECTED> |
| 01:32.13 |
ibot |
it has been
said that 2^2 is a bad question. You want 2**2. |
| 01:32.15 |
``Erik |
(it still
pings, musta ignored that) |
| 01:32.42 |
yukonbob |
~ lart
self |
| 01:32.42 |
ibot |
acting on orders from an unspecified client drags self into
court suing for $200 million |
| 01:33.23 |
yukonbob |
brlcad: so is
still consuming same amt. memory as previous, or was there
re-coding in that inefficiency? |
| 01:34.02 |
``Erik |
~1<<5 |
| 01:34.29 |
yukonbob |
remembers sections of Pugeot Sound were un-renderable for
self at the time... |
| 01:34.56 |
``Erik |
mebbe it's
cuz the puget sound is just too cool for ya |
| 01:34.57 |
``Erik |
:D |
| 01:35.09 |
yukonbob |
actually, now
that I think of it, brlcad, you had nice huge dsp's that were of
larger grid, built from older brl-cad. |
| 01:35.11 |
``Erik |
(my old
stompin' ground, grew up on whidbey island) |
| 01:35.45 |
yukonbob |
courtney love
tells me Olympia sucks |
| 01:35.59 |
``Erik |
yeah, olympia
sucks, but courtney sucks more |
| 01:36.02 |
``Erik |
:D |
| 01:36.25 |
``Erik |
(shit,
courtney has probably sucked most of olympia *cough*) |
| 01:37.21 |
brlcad |
yukonbob: i
don't think it's changed, but your best bet is to just give it a go
and see how it behaves for your data |
| 01:37.45 |
brlcad |
it's been
used several times over since then for various projects with
complete success |
| 01:38.35 |
yukonbob |
brlcad:
sounds good. thx. |
| 01:39.36 |
``Erik |
if it's a
memory related issue, make sure swap is enabled and reasonably
large if you use linux. Last I checked, the OOM murder code in
linux is... odd. :) |
| 01:39.39 |
yukonbob |
one more q:
re: png -> height field -- will the various heights map to a
single index so all "0" heights == a certain shade of blue, all
"30" height map to same shade of green? |
| 01:39.57 |
``Erik |
->bw,
greyscale image |
| 01:40.13 |
yukonbob |
``Erik: good
point. I'm personally running BSD, but I'd hate to run in on
another machine and have it killed after hours of
chugging... |
| 01:40.19 |
starseeker |
I think he
wants to use the image data to "shade" a dsp? |
| 01:41.08 |
brlcad |
yukonbob: the
intensity values of the grayscale image will correspond to height
values (you set scaling parameters on creation) |
| 01:41.12 |
yukonbob |
right -- i.e.
Imagine an image with a river, a block that is supposed to be a
forrest, a road, etc. |
| 01:41.23 |
brlcad |
you'll then
apply whatever colors as a texture |
| 01:41.32 |
``Erik |
then there'll
be two image files I think, one for the heightmap in bw greyscale,
the other in pix for the texture |
| 01:41.54 |
brlcad |
the
projection shader will make the colors map directly onto the
surface giving whatever colors for each cell as you
want |
| 01:42.24 |
yukonbob |
will have to experiment and get experience; it's not making
sense to me, but it appears to me (by you guy's comments) it's
possible... I just need to play, wrap my head around the
process. |
| 01:42.50 |
yukonbob |
thanks again,
gentlemen :) |
| 01:42.57 |
``Erik |
good luck
O.o |
| 01:43.11 |
yukonbob |
cheers |
| 01:43.55 |
brlcad |
yukonbob: a
related tutorial is the ebm (extruded bitmap) |
| 01:43.56 |
brlcad |
http://brlcad.org/wiki/EBM |
| 01:44.09 |
yukonbob |
nice. thx
:D |
| 01:44.56 |
brlcad |
you'll want a
dsp instead of an ebm, but it covers basic file
conversion |
| 05:34.11 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 05:41.24 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 06:36.12 |
*** join/#brlcad FlossLikeYouMean
(n=on_Chatz@ip72-198-41-52.ok.ok.cox.net) |
| 08:03.27 |
*** join/#brlcad Yoshi47
(n=jan@firewall.walinga.com) |
| 10:21.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-74.sbndin.btas.verizon.net) |
| 11:18.17 |
CIA-28 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1626 10/wiki/EBM: Quick typo fix. |
| 11:19.19 |
``Erik |
excessive
bowel movement? O.o |
| 11:23.24 |
d-lo |
Yes, ``Erik,
we have a turd primitive in BRL-CAD. |
| 11:24.35 |
``Erik |
damn, there
goes that brilliant new use for metaballs |
| 11:26.55 |
d-lo |
'brilliant'
was quite the word I was going to use lol |
| 11:28.15 |
d-lo |
s/was/wasn't/ |
| 11:44.20 |
``Erik |
freudian
slip? :D |
| 11:44.45 |
d-lo |
yeah...
that's it! Right! |
| 11:44.47 |
d-lo |
:P |
| 11:46.34 |
``Erik |
blah, 7:45
already |
| 11:46.42 |
``Erik |
puts pants on and starts driving |
| 11:47.21 |
d-lo |
thats a good
order to do things :) |
| 12:41.04 |
``Erik |
oh, wait, I
listed those as an unordered set, there's supposed to be an
order? |
| 12:46.53 |
*** join/#brlcad BigAToo
(n=BigAToo@64.255.115.3) |
| 13:06.41 |
``Erik |
http://www.subblue.com/blog/2009/9/20/quaternion_julia |
| 13:07.28 |
starseeker |
standard
English language convention generally implies temporal coherence in
left to right ordering barring specific notation of other
organization |
| 13:14.53 |
*** join/#brlcad BigAToo
(n=BigAToo@64.255.115.3) |
| 13:31.07 |
*** join/#brlcad BigAToo
(n=BigAToo@64.255.115.3) |
| 13:45.23 |
*** join/#brlcad samrose
(n=samrose@mi-beaco-rtr-16-59.synergydsl.com) |
| 13:48.20 |
CIA-28 |
BRL-CAD:
03starseeker * r35972 10/brlcad/trunk/ (5 files in 4 dirs): Start
to stub out what is needed for testing a sketch brep
conversion. |
| 13:51.31 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 14:01.01 |
*** join/#brlcad BigAToo
(n=BigAToo@64.255.115.3) |
| 14:02.10 |
CIA-28 |
BRL-CAD:
03starseeker * r35973 10/brlcad/trunk/src/proc-db/csgbrep.cpp: Erm,
uncomment some of the other stuff besides sketch... |
| 14:32.02 |
CIA-28 |
BRL-CAD:
03starseeker * r35974 10/brlcad/trunk/src/proc-db/csgbrep.cpp: few
tweaks so a normal sketch is also generated for
comparison. |
| 14:33.28 |
CIA-28 |
BRL-CAD:
03starseeker * r35975
10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Start
working through the early phases of the sketch generation logic -
will need to have the correct 'environment' set up before it's even
worth looking for loops. |
| 14:34.36 |
CIA-28 |
BRL-CAD:
03bob1961 * r35976 10/brlcad/trunk/src/libdm/color.c: dm_copy_cmap
has been changed to _X_copy_cmap. |
| 15:25.19 |
brlcad |
hehe, he's
probably gonna regret that |
| 15:25.31 |
brlcad |
(victor
subscribed to commits) |
| 15:32.26 |
``Erik |
mwahahahaha
</evillaugh> |
| 15:32.36 |
``Erik |
or is it
(evillaugh "Mwahahhahaha") |
| 15:43.44 |
d-lo |
So in the
next commit message, someone should put "hi victor!" ? |
| 15:46.36 |
brlcad |
heh |
| 15:46.42 |
CIA-28 |
BRL-CAD:
03brlcad * r35977 10/brlcad/trunk/src/mged/attach.c: minor cleanup,
remove dead code |
| 15:58.12 |
CIA-28 |
BRL-CAD:
03brlcad * r35978 10/brlcad/trunk/src/mged/mged.c: more consistency
cleanup while reviewing attach. (hi victor!) |
| 15:58.59 |
d-lo |
ha! |
| 16:13.26 |
*** join/#brlcad BigAToo
(n=BigAToo@208.95.141.189) |
| 16:54.29 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 17:01.43 |
*** join/#brlcad samrose
(n=samrose@adsl-99-131-31-41.dsl.sfldmi.sbcglobal.net) |
| 17:02.18 |
``Erik |
now EVERY
commit message needs " (hi victor!)" at the end |
| 17:11.46 |
starseeker |
``Erik:
technically, it's <laugh
mode='evil'>Mwahahahahaha</laugh> |
| 17:20.02 |
``Erik |
or
<laugh><evil>Mwwahhahahaha</evil></laugh> |
| 17:20.59 |
starseeker |
of course,
the truly proper language for an evil laugh has to be Microsoft
Visual Basic |
| 17:21.05 |
``Erik |
(defclass
evil (alignment) ()) (defgeneric laugh ((self evil))
"Mwahahahaha!") |
| 17:21.08 |
``Erik |
((())(()(((()(())(()))) |
| 17:21.12 |
starseeker |
heh |
| 17:21.13 |
``Erik |
(*Y*) |
| 17:21.33 |
``Erik |
fires up vim before he hurts himself or someone
else |
| 17:22.01 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 17:22.02 |
``Erik |
(s/generic/method/) |
| 17:47.03 |
CIA-28 |
BRL-CAD:
03starseeker * r35979 10/brlcad/trunk/include/brep.h: Tighten up
the edge miss tolerance some more - really need to do something
adaptive to model scale here. |
| 17:47.18 |
``Erik |
hum http://www.dadhacker.com/blog/?p=1132 |
| 18:35.19 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 18:48.05 |
brlcad |
huh, i swear
i've read that before |
| 18:48.13 |
brlcad |
yet says it
posted today |
| 18:49.23 |
d-lo |
copy paste
job perhaps? |
| 18:57.10 |
brlcad |
dunno, don't
see other refs to it |
| 18:57.28 |
brlcad |
maybe just a
really similar posting -- those are very common
sentiments |
| 18:57.45 |
brlcad |
*very* common
:) |
| 19:15.12 |
Ralith |
? |
| 19:16.15 |
starseeker |
old school
guys not caring for newer paradigms that hide many of the
details |
| 19:16.38 |
starseeker |
(and/or don't
deliver what they promised to deliver) |
| 19:17.01 |
Ralith |
ah. |
| 19:17.22 |
``Erik |
ì |
| 19:22.51 |
CIA-28 |
BRL-CAD:
03brlcad * r35980 10/brlcad/trunk/ (4 files in 3 dirs): (log
message trimmed) |
| 19:22.51 |
CIA-28 |
BRL-CAD: add
a '-a' option to mged that allows users to specify a display
manager to |
| 19:22.51 |
CIA-28 |
BRL-CAD:
attach to. this avoids the attach prompting seen in interactive
mode that |
| 19:22.51 |
CIA-28 |
BRL-CAD:
should help systems that prompt for an attach device even when
non-interactive. |
| 19:22.51 |
CIA-28 |
BRL-CAD:
expand the docs with examples including filling in details on the
-d display |
| 19:22.52 |
CIA-28 |
BRL-CAD:
option as well. note that you cannot (presently) invoke multiple
attachments |
| 19:22.54 |
CIA-28 |
BRL-CAD: due
to the way display manager creation is presently deferred without a
little |
| 19:25.29 |
CIA-28 |
BRL-CAD:
03starseeker * r35981
10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Hmm.
How about using the plane to convert the 2 space coordinates to 3
space coordinates... |
| 19:32.44 |
CIA-28 |
BRL-CAD:
03brlcad * r35982 10/brlcad/trunk/include/brep.h: this header file
is included by rtgeom.h for C compiles as well, so no-go on the
//isms |
| 19:33.15 |
``Erik |
"I tell you
what, if I find out I'm having a baby, I'm coming after you" O.O ya
overhear the damndest things around here |
| 19:34.24 |
starseeker |
is afraid to ask... |
| 19:35.03 |
d-lo |
lol |
| 19:35.11 |
brlcad |
starseeker:
that option is actually kinda odd .. don't know if someone was
planning on adding it at some point, but the docs had -c [nu|ogl|X]
documented (which afaik has never been valid) |
| 19:35.26 |
starseeker |
hmm, that is
od |
| 19:35.29 |
starseeker |
er
odd |
| 19:35.55 |
brlcad |
single char
args with an optional param aren't common convention
either |
| 19:36.19 |
brlcad |
makes me
think someone was just thinking of adding it |
| 19:37.07 |
starseeker |
I always did
wonder why there wasn't some way to specify that without the extra
step... |
| 19:37.23 |
brlcad |
would be cool
to expand the deferred startup to accept multiple attachings, even
with different display settings |
| 19:37.49 |
brlcad |
mged -c -a
ogl -d secondhost:0 -a X -d third:1 -a ogl |
| 19:38.10 |
brlcad |
but would
have to make a container that stashes the attach type and current
display value |
| 19:38.26 |
brlcad |
so when
they're later undeferred, they all create appropriately |
| 19:40.52 |
brlcad |
anyone have
python on windows with a brl-cad install handy? |
| 19:42.33 |
starseeker |
brlcad:
whoops, sorry about the comment |
| 19:43.14 |
starseeker |
reminds himself to be nice to the C side of the
street |
| 19:47.43 |
*** join/#brlcad archivist_emc
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 20:25.39 |
CIA-28 |
BRL-CAD:
03starseeker * r35983
10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: OK,
first baby step - create straight line edges from the line
segments. They line up, so checkpoint. |
| 20:41.53 |
CIA-28 |
BRL-CAD:
03starseeker * r35984
10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Add
edges from full circles. |
| 20:48.32 |
CIA-28 |
BRL-CAD:
03brlcad * r35985 10/brlcad/trunk/src/mged/mged.c: allow a display
manager to be attached even if we're running the tk gui -- make
sure we attach if the user requested it. |
| 20:49.03 |
CIA-28 |
BRL-CAD:
03brlcad * r35986
10/brlcad/trunk/doc/docbook/system/man1/en/mged.xml: pedantic blank
line was added (so error messages don't overlap the
prompt) |
| 21:00.25 |
CIA-28 |
BRL-CAD:
03starseeker * r35987
10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Punt
on arcs for the moment - logic is surprisingly complex to extract
what is needed to get a 3rd point for the opennurbs arc routine.
reference where in sketch.c to look for later. |
| 21:01.03 |
CIA-28 |
BRL-CAD:
03brlcad * r35988 10/brlcad/trunk/src/mged/ (attach.c cmd.c cmd.h
mged.c mged.h): refactor los tres amigos into one function to
remove code duplication. propagate a const as
consequence. |
| 21:02.35 |
CIA-28 |
BRL-CAD:
03brlcad * r35989 10/brlcad/trunk/src/mged/ (cmd.c cmd.h): more
const propagation |
| 21:03.53 |
CIA-28 |
BRL-CAD:
03brlcad * r35990 10/brlcad/trunk/BUGS: if you attach a display
manager in tk-mged, kill the window, then quit, mged crashes on
exit. pretty likely that mged is trying to destroy the already
destroyed window, of course. observed on osx 10.4 |
| 21:08.20 |
CIA-28 |
BRL-CAD:
03brlcad * r35991 10/brlcad/trunk/include/ (dm-X.h dm-ogl.h
dm-rtgl.h dm-tk.h dm-wgl.h): dm_color.h is obsolete (albeit marked
deprecated), don't include it. |
| 21:15.22 |
CIA-28 |
BRL-CAD:
03starseeker * r35992
10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Woot.
Get the bezier stuff working - can now draw all the lines of the
default sketch object. Now for the hard part - building trims and
loops. |
| 21:20.42 |
CIA-28 |
BRL-CAD:
03brlcad * r35993 10/brlcad/trunk/src/mged/mged.c: quell all
pedantic compilation warnings (sans long-long and
format) |
| 21:24.10 |
CIA-28 |
BRL-CAD:
03brlcad * r35994 10/brlcad/trunk/src/mged/mged.c: lotta dead code
elimination. |
| 21:52.47 |
*** join/#brlcad samrose
(n=samrose@173-110-143-189.pools.spcsdns.net) |
| 21:52.54 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-74.sbndin.btas.verizon.net) |
| 22:10.08 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.127) |
| 23:02.27 |
*** join/#brlcad ``Erik
(i=Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 23:07.27 |
*** join/#brlcad ``Erik
(i=Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 00:16.36 |
CIA-28 |
BRL-CAD:
03brlcad * r36091
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: |
| 00:16.36 |
CIA-28 |
BRL-CAD:
expand the zero-thickness loop and make it use the
application-specified |
| 00:16.36 |
CIA-28 |
BRL-CAD:
distance tolerance instead of hard-coded magic values. this should
tighten the |
| 00:16.36 |
CIA-28 |
BRL-CAD:
bounding box while still keeping the bot visible for space
partitioning. |
| 00:23.17 |
CIA-28 |
BRL-CAD:
03brlcad * r36092
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: style ws
indent comment consistency cleanup |
| 00:24.44 |
CIA-28 |
BRL-CAD:
03brlcad * r36093
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c:
accidental double-line |
| 00:25.51 |
CIA-28 |
BRL-CAD:
03brlcad * r36094
10/brlcad/trunk/src/librt/primitives/bspline/bspline.c: apply the
same non-zero thickness test that BoT uses so that we don't miss
planar spline surfaces during space partition
traversal. |
| 00:33.25 |
CIA-28 |
BRL-CAD:
03brlcad * r36095
10/brlcad/trunk/src/librt/primitives/bspline/bspline.c: no need to
have the zero-length test inside the surface loop. just do a sanity
test after visiting all surfaces. |
| 00:33.30 |
brlcad |
starseeker:
on that note .. any specific reason brep bounding boxes are
expanded 1mm instead of tol->dist in brep_prep()? |
| 00:33.33 |
brlcad |
fg |
| 00:35.53 |
starseeker |
brlcad: not
sure offhand |
| 00:49.53 |
brlcad |
remember that
.bz is possibly going down in as early as 10 minutes from now (or
any time now really) |
| 00:50.21 |
brlcad |
so you might
want to have a local irc client handy since screens will all get
shut down |
| 00:51.40 |
starseeker |
doesn't have home internet yet anyhow |
| 00:52.50 |
starseeker |
is not at all sure if the amount of data in a dsp makes sense
to represent as a NURBS surface |
| 00:54.10 |
brlcad |
if you want
to visualize it via opengl, it does |
| 00:54.26 |
brlcad |
remember
that's one piece of what those routines are for |
| 00:55.11 |
starseeker |
might be
better to just tesselate it and use the bots |
| 00:55.41 |
starseeker |
I'm not even
sure we can hand a surface like this |
| 00:58.36 |
starseeker |
er handle
even |
| 00:59.03 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-33.sbndin.btas.verizon.net) |
| 01:01.01 |
CIA-28 |
BRL-CAD:
03brlcad * r36096
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: tighten up the
bounding box check considerably from 1mm to the distance tolerance.
history indicates this was arbitrarily 0.02mm then 1.0mm during
testing. this is actually still not quite as tight as the other
prims. |
| 01:01.37 |
brlcad |
will see if
that busts things soon enough.. |
| 01:01.48 |
brlcad |
shouldn't
though, unless there are other bad assumptions at play |
| 01:01.48 |
starseeker |
brlcad: It
may have been expanded for a reason... |
| 01:02.42 |
starseeker |
brlcad: was
it causing problems with the old NURBS -> new NURBS
conversion? |
| 01:02.42 |
brlcad |
speculation,
wasn't documented in comments or commit -- hinted at it just being
part of testing bb in commit message |
| 01:03.14 |
starseeker |
nods - yeah, a lot of that stuff was and still is a tad
fuzzy |
| 01:03.16 |
brlcad |
either way,
should find out rather trivially and can document it if it needs to
be something else |
| 01:03.53 |
brlcad |
should at
least be a comment if there's going to be a magic number that isn't
using the tolerance system, otherwise it's just asking for obscure
cascading bugs down the road |
| 01:04.04 |
starseeker |
Keith and I
both intend to go back over the whole kit and kaboddle thoroughly
once the sprint is done |
| 01:04.56 |
starseeker |
suggests brlcad not look too hard if magic numbers bother him
- there are a fair few that will need to be delt
with |
| 01:05.07 |
brlcad |
oh, I
know |
| 01:05.33 |
starseeker |
bty, congrats
on the release tagging! |
| 01:05.38 |
starseeker |
well
done |
| 01:05.44 |
brlcad |
that one was
just blatent and screws with the space partitioning |
| 01:06.02 |
brlcad |
st_min/max
aren't used during shot(), they're used higher up during SP
traversal |
| 01:06.24 |
brlcad |
if it's not
right, then GetBBox() is wrong |
| 01:07.27 |
brlcad |
we can't get
that far off schedule between releases -- makes for way too much
work |
| 01:08.56 |
brlcad |
and it really
shouldn't be a one-man job every month, doesn't serve the project
regardless of ongoing activity as issues back up and bugs get more
costly and release even more intense |
| 01:09.43 |
starseeker |
apologizes |
| 01:10.38 |
brlcad |
not harping
on anyone in particular -- should be everyone pressing for it and
helping push it each end of month |
| 01:11.57 |
brlcad |
sad to say
it, but feeling is our quality is "down" due to bugs introduced
that simply aren't on anyone's radar .. feels like a class ".0"
release unfortunately |
| 01:12.30 |
starseeker |
nods |
| 01:12.41 |
brlcad |
*classic |
| 01:13.22 |
starseeker |
will try not to move again for a few months
;-) |
| 01:15.48 |
brlcad |
there are
several active folks that could have helped things along..
:) |
| 01:16.05 |
brlcad |
most
distressing is *FOUR* releases were missed :/ |
| 01:16.19 |
starseeker |
ow |
| 01:16.36 |
brlcad |
we had four
in row right on time |
| 01:16.51 |
brlcad |
then four
missed, now (hopefully) back on schedule |
| 01:18.32 |
starseeker |
Did we
introduce the stability issues, or is that the OSX 10.5
stuff? |
| 01:18.45 |
brlcad |
read my clock
wrong, still 1.5 hours till 11pm |
| 01:18.56 |
brlcad |
it's not just
osx |
| 01:20.03 |
brlcad |
it's several
things in general -- tcl changes, rt changes, mged command changes
.. just bug creep |
| 01:20.03 |
brlcad |
regression
tests being ignored |
| 01:20.03 |
brlcad |
several are
failing |
| 01:21.31 |
starseeker |
winces |
| 01:21.39 |
brlcad |
happens
naturally, just has to be kept in check -- can't just keep heaping
in new code and code changes for months on end without keeping
things clean along the way |
| 01:23.04 |
brlcad |
almost let a
bug slip in with my mged argv parsing change from the weekend that
I just caught on monday |
| 01:23.20 |
brlcad |
that would
have been bad :) |
| 01:24.00 |
starseeker |
heh |
| 01:24.05 |
starseeker |
just a
bit |
| 01:28.27 |
brlcad |
if I had my
druthers and unlimited time/budget, I'd halt all new work so we can
focus on just bugs for at least three months solid to fix and
refactor anything and everything we know of and can easily expose
through automation, across the entire codebase |
| 01:28.55 |
starseeker |
nods |
| 01:29.20 |
starseeker |
too bad about
the time/budget bit :-( |
| 01:30.17 |
brlcad |
the payoff
from that would escalate our usability and code maintainability
faster than anything else by removing *all* potential crashes,
failed input processing, 32/64-bit conversions, bad assumptions,
bad docs, etc |
| 01:30.30 |
starseeker |
yep |
| 01:30.45 |
starseeker |
agrees, just not sure how to /who to make the case
to |
| 01:31.14 |
brlcad |
couldn't be
made for that length of time unless we make it some massive
community effort |
| 01:31.40 |
brlcad |
and then you
have to attract bug fixers and get them up to speed |
| 01:31.59 |
brlcad |
we had a
gsocer like that for bz this year .. was fantastic .. fixed dozens
of really hard bugs |
| 01:34.48 |
starseeker |
sweeet |
| 01:44.34 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 01:52.29 |
yukonbob |
reads scrollback with interest... |
| 01:55.08 |
*** join/#brlcad learner
(n=sean@c-68-48-70-217.hsd1.md.comcast.net) |
| 02:00.43 |
brlcad |
thinks he may need to add a plate mode to
breps |
| 02:09.23 |
brlcad |
starseeker:
you ever looked into stay's trimming code? |
| 02:09.48 |
brlcad |
thinking to
kill it if you have, if there's no value to be derived any
more |
| 02:11.37 |
starseeker |
can't say I
have, really - I didn't know there was working trimming
code |
| 02:11.49 |
brlcad |
never implied
it was working or not |
| 02:12.03 |
brlcad |
code is
code |
| 02:12.22 |
starseeker |
I'd go ahead
- it's in the revision history if we need it, and on the whole our
trimming seems to be in decent shape now |
| 02:13.23 |
brlcad |
nobody will
need to look at it as a matter of need, it wasn't used |
| 02:13.43 |
brlcad |
it would be
to see if there's some aspect to what he's doing that is actually
useful that could improve what we're doing |
| 02:14.19 |
starseeker |
I suppose I
could take a look, but it might not be for a while |
| 02:14.29 |
brlcad |
not very
complex code, might be worth all of five min to review
it |
| 02:14.59 |
starseeker |
what file is
it in? |
| 02:15.02 |
brlcad |
looks like
that was the only code to actually start to use nurbs nmg
structure |
| 02:15.22 |
brlcad |
src/librt/primitives/bspline/nurb_trim.c |
| 02:15.38 |
starseeker |
looks |
| 02:18.18 |
starseeker |
hmm, he's
breaking up the curves into bezier sub-curves |
| 02:18.20 |
starseeker |
I
think |
| 02:18.33 |
starseeker |
quadrant
based reasoning... |
| 02:18.53 |
brlcad |
wouldn't be
surprising, that was the approach for surface decomposition,
turning nurbs into bspline patches |
| 02:19.37 |
brlcad |
hm.. more
coffee or quick nap |
| 02:19.50 |
brlcad |
gets coffee |
| 02:20.25 |
starseeker |
yeah, that's
not what we're doing now (at least practically) so I don't think we
need it - I don't think we have a working openNURBS routine for the
bspline patch thing, and we aren't doing that anyhow |
| 02:23.09 |
CIA-28 |
BRL-CAD:
03starseeker * r36097
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: Ugly, ugly,
ugly. Wireframe looks halfway reasonable but hardly raytraces at
all. Performance is horrible. |
| 02:28.13 |
starseeker |
grinds teeth |
| 02:29.06 |
starseeker |
now what..
do per-cell surfaces? ugh. what's a reasonable breakdown I
wonder... |
| 02:29.54 |
starseeker |
this thing
might be the super-density control point case that we need to add
to the surface tree build logic checking... even then though I
doubt it would help much |
| 02:45.41 |
starseeker |
exit |
| 02:45.45 |
starseeker |
whoops |
| 02:48.08 |
yukonbob |
fail |
| 02:58.11 |
CIA-28 |
BRL-CAD:
03brlcad * r36098 10/brlcad/trunk/include/nurb.h: make the header
safe to include with c++ files as-is with a little wrapping
love. |
| 02:58.47 |
CIA-28 |
BRL-CAD:
03brlcad * r36099 10/brlcad/trunk/ (4 files in 3 dirs): initial
stub in for old nurbs to new nurbs conversion. right now it just
stubs a bounding sphere in place while some more thought is put
into how to support the old structureless nurbs as freestanding
surfaces. |
| 03:16.10 |
poolio |
starseeker:
how goes brep? :) |
| 03:19.25 |
learner |
he has most
of the primitives working now |
| 03:19.38 |
learner |
pretty
cool |
| 03:21.01 |
poolio |
awesome! |
| 03:21.43 |
learner |
just a couple
of the more complex ones remaining (like dsp (terrain), sketches,
revolve, pipes, etc) |
| 03:31.38 |
poolio |
ruh roh,
looks like bzflag is about to go down. see y'all on the other
side |
| 03:41.45 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-56.sbndin.btas.verizon.net) |
| 03:46.46 |
learner |
poolio: yeah,
supposedly any minute (for the past 45) |
| 03:48.10 |
learner |
yeah, I just
saw the console messages .. here it goes |
| 03:56.59 |
learner |
dns is
updated, just waiting for the physical swap now |
| 04:00.40 |
CIA-28 |
BRL-CAD:
03brlcad * r36100
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: brep_build_bvh
doesn't use the rt_brep_internal |
| 04:20.01 |
learner |
cmon
sago |
| 04:22.25 |
*** join/#brlcad brlcad
(n=sean@63.246.136.16) |
| 04:22.35 |
brlcad |
woot |
| 05:03.18 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 05:56.55 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 06:24.08 |
CIA-28 |
BRL-CAD:
03brlcad * r36101 10/brlcad/trunk/ (5 files in 3 dirs): rename
bspline.c to bspline.cpp in preparation for new nurbs
integration/conversion. |
| 06:26.26 |
CIA-28 |
BRL-CAD:
03brlcad * r36102
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: initial
conversion for ray-tracing purposes, add a compile-time switch to
convert prep() to use brep prep() with stashage into the
nurb_internal. |
| 06:27.47 |
CIA-28 |
BRL-CAD:
03brlcad * r36103
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: reflect
filename change |
| 06:28.44 |
brlcad |
not too
shabby for one day. tagged release, orchestrated server migration,
fixed nurbs bb partitioning, and stubbed out prep. |
| 06:29.11 |
brlcad |
goes to get cookies |
| 06:32.32 |
CIA-28 |
BRL-CAD:
03brlcad * r36104 10/brlcad/trunk/include/rtgeom.h: consider
stashing the ON_Brep in here, not ideal though |
| 08:02.54 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 08:25.41 |
*** join/#brlcad KingofCSU
(n=king@118.249.212.228) |
| 08:28.52 |
KingofCSU |
Hello there
I can not make a cone anyone can tell me how to make a cone
I mean not the trc the cone with top R is 0 |
| 08:33.06 |
KingofCSU |
Hello How
to make a cone by BRL-CAD? I had tried the solid trc , but i can
not make the radius of top to 0, the Error is "all dimensions must
be greater than zero! then how can I make a cone ? |
| 08:33.44 |
_clock_ |
KingofCSU:
make some small number as the top radius |
| 08:33.59 |
_clock_ |
like
0.0000000000000000000000001 |
| 08:34.16 |
KingofCSU |
It is the
only way? |
| 08:34.22 |
_clock_ |
as far as I
know yes |
| 08:34.59 |
KingofCSU |
thank you, I
will try it . |
| 08:35.01 |
_clock_ |
KingofCSU:
put the smallest number representable in floating point there. I
wonder if the engine is going to collapse from that :) |
| 08:35.44 |
KingofCSU |
I think 0.1
is ok |
| 08:35.51 |
_clock_ |
KingofCSU:
or, by binary search, find the smallest number the program accepts
without producing the "all dimensions must be greater than zero!"
message :) |
| 08:36.32 |
KingofCSU |
0.1 is enough
to do such a cone |
| 08:36.33 |
_clock_ |
wht are you
modelling? |
| 08:36.58 |
KingofCSU |
something
simple I borrowed a book of CAD. and try to make the samples
. |
| 08:38.03 |
KingofCSU |
the book is
about auto CAD . I try to make the examples by
BRL-CAD. |
| 08:38.46 |
KingofCSU |
Do you have
any other idea to practice the BRL-CAD? |
| 08:38.48 |
_clock_ |
oh autocad
was initial release 1982 |
| 08:38.54 |
_clock_ |
and BRL-CAD
1984 according to Wikipedia |
| 08:39.05 |
_clock_ |
What a shame
for BRL-CAD! |
| 08:39.10 |
_clock_ |
And I thought
it was 1979 |
| 08:39.57 |
_clock_ |
aha! But
Autocad was initially 2D only! |
| 08:39.58 |
KingofCSU |
Whatever.
How do you improve your kill of BRL-CAD? |
| 08:40.24 |
KingofCSU |
I dont think
so . autocad can do 3D too |
| 08:40.26 |
_clock_ |
KingofCSU: I
want to model something and then struggle to model it |
| 08:40.40 |
_clock_ |
through all
the badly documented functions :) |
| 08:41.52 |
KingofCSU |
it is hard to
put the things the the right place in BRL-CAD. it can not catch
some point like middle or end |
| 08:42.15 |
_clock_ |
Yes I find
this useless unless for technological design |
| 08:42.28 |
_clock_ |
I always type
the coordinates in numerically in the matrix editor |
| 08:42.54 |
KingofCSU |
you have to
calculate the point |
| 08:43.15 |
_clock_ |
I don't have
to calculate any point |
| 08:43.16 |
_clock_ |
Mostly |
| 08:43.21 |
KingofCSU |
still now I
can not understand the matrix editor |
| 08:43.39 |
_clock_ |
If I need
some complex shape I design it in QCAD let it print the coordinates
and then type them in |
| 08:44.04 |
_clock_ |
KingofCSU: I
don't even remember the command to invoke it anymore :) |
| 08:44.25 |
KingofCSU |
Oh that is a
good idea , to do something in QCAD then .... |
| 08:44.30 |
_clock_ |
there is red
sed and ted |
| 08:44.58 |
_clock_ |
some of them
have horrible complicated parameters like you have to type in
exactly the directory tree |
| 08:45.04 |
_clock_ |
some don't
work in some situations |
| 08:45.14 |
_clock_ |
and all do
basically the same IIRC |
| 08:45.14 |
KingofCSU |
I can find
anything about the red and ted, |
| 08:45.21 |
_clock_ |
I find
BRL-CAD very confusing to use :) |
| 08:46.06 |
KingofCSU |
I can not
find any documents about the red and ted . |
| 08:46.12 |
_clock_ |
Sometimes it
doesn't 'like' some geometry and is 210x slower in
rendering |
| 08:46.25 |
_clock_ |
For which
some good soul wrote me some exceptional feature to solve exactly
my situation |
| 08:46.39 |
_clock_ |
However this
help doesn't fit into my system of scripts and won't work for other
situations of course |
| 08:46.59 |
_clock_ |
KingofCSU: I
am not surprised, I couldn't find them either |
| 08:47.34 |
KingofCSU |
sometimes i
find it is hard to use the pix-png tool . |
| 08:48.05 |
KingofCSU |
_clock_: then
How do you learn the red and ted? |
| 08:48.06 |
_clock_ |
KingofCSU: I
can't find any reference manual on teh net |
| 08:48.19 |
KingofCSU |
same to
you |
| 08:48.19 |
_clock_ |
KingofCSU: I
don't remember how I learned them, but I already forgot it anyway
:) |
| 08:48.34 |
KingofCSU |
:-D |
| 08:49.04 |
_clock_ |
Oh here is
some reference on the Wiki |
| 08:49.06 |
_clock_ |
http://brlcad.org/wiki/MGED_Commands |
| 08:49.10 |
_clock_ |
But: |
| 08:49.15 |
KingofCSU |
there are
only four BRL-CAD Tutorial Series to reference |
| 08:49.43 |
_clock_ |
1) how should
a user determine from "I want to know about red" whether he should
search in Documentation or Wiki? Anyway, isn't Wiki a documentation
too so shouldn't it be under the Documentation chapter? |
| 08:50.00 |
_clock_ |
2) Is the
Wiki official or unofficial documentation? How much can we trust
what is written there? |
| 08:50.16 |
KingofCSU |
I see. but I
am a Chinese. It is hard to understand the English in so special
way |
| 08:51.06 |
KingofCSU |
the English
in a specialized field or subject is hard to learn |
| 08:52.33 |
KingofCSU |
just
finishing the 4 BRL-CAD Tutorial Series is not enough to model
complex things. |
| 08:53.02 |
_clock_ |
Basically red
is for combinations |
| 08:53.07 |
_clock_ |
and sed+ted
is for primitives |
| 08:53.28 |
_clock_ |
And the
BRL-CAD web is slow. |
| 08:53.37 |
KingofCSU |
:) |
| 11:37.32 |
brlcad |
which further
reinforces the need for better organized/searchable/integrated
documentation |
| 11:46.25 |
*** join/#brlcad d-lo
(n=claymore@63.246.136.16) |
| 11:46.52 |
d-lo |
mornin! |
| 12:01.08 |
brlcad |
mernin |
| 12:01.35 |
brlcad |
woot, RDNS is
fixed |
| 12:02.10 |
Yoshi47 |
morning |
| 12:02.35 |
Yoshi47 |
Remote
Distraction NURBS System |
| 12:06.24 |
brlcad |
yeah has been
a distraction .. reverse DNS ;) |
| 12:14.46 |
*** join/#brlcad KingofCSU
(n=king@118.249.212.228) |
| 12:24.37 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 12:25.07 |
Yoshi47 |
oh that
stuff, haven't even touch the reverse stuff, cause i don't think i
need it |
| 12:26.34 |
brlcad |
having
reverse dns on servers with a fixed ip can be pretty
useful |
| 12:26.57 |
brlcad |
many tools do
reverse lookups to validate origination |
| 12:27.46 |
brlcad |
e.g., irc
.. |
| 12:37.41 |
CIA-28 |
BRL-CAD:
03brlcad * r36105
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: where to
pick up |
| 12:45.40 |
CIA-28 |
BRL-CAD:
03brlcad * r36106 10/brlcad/trunk/src/proc-db/spltest.c: make the
surface non-planar for testing now that planar is fixed |
| 12:52.51 |
CIA-28 |
BRL-CAD:
03brlcad * r36107 10/brlcad/trunk/src/libfb/ (if_X24.c
if_ogl.c): |
| 12:52.51 |
CIA-28 |
BRL-CAD:
consistency. if you're going to cast to unsigned long long
pointers, then scan |
| 12:52.51 |
CIA-28 |
BRL-CAD:
that. and do the same for X24 else obscure bugs are
introduced. |
| 12:52.51 |
CIA-28 |
BRL-CAD:
*_open_existing really is a hack that needs to be refactored
away/into the libfb |
| 12:52.51 |
CIA-28 |
BRL-CAD:
callback table better. |
| 13:31.23 |
``Erik |
now just to
migrate services *cough* |
| 13:39.35 |
*** join/#brlcad parigaudi
(n=quassel@217.91.127.94) |
| 13:44.55 |
brlcad |
yep |
| 14:11.44 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-56.sbndin.btas.verizon.net) |
| 14:16.56 |
*** join/#brlcad starseeker
(n=starseek@63.246.136.16) |
| 14:17.31 |
starseeker |
returns |
| 14:20.32 |
d-lo |
*dun dun
dunnnnnnnn* |
| 14:21.54 |
d-lo |
thinks it is mildly amusing that someone in Sri Lanka got
their GSoc Tshirt before someone in PA. :) |
| 14:26.15 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 14:34.43 |
``Erik |
got his a while ago |
| 14:35.20 |
``Erik |
like, 2 days
after they said they were sending them out (actually saw the fedex
tracking # before the email about them sending them out
O.O) |
| 14:36.08 |
``Erik |
mebbe you
live in an area that they didn't believe to be accessable or
inhabited? they had to procure pontoons for the cessna?
:D |
| 14:42.11 |
d-lo |
ohh! ``Erik
made a funny! |
| 14:42.35 |
``Erik |
(do I get a
doggie biscuit? do I? do I? do I? huh? huh? do I?) |
| 14:45.34 |
d-lo |
Nope, but you
can have 179 mins off work today. Just tell'em Dave Said
so. |
| 14:47.06 |
d-lo |
Nice:
Texting while driving in MD will get you a $500 fine. Finalyl,
some sense. |
| 14:52.52 |
Yoshi47 |
soon to be in
Ontario too! even if on phone! or any device that isn't dash
mounted |
| 14:53.05 |
Yoshi47 |
going to have
to find a nice BT headset |
| 14:53.22 |
Yoshi47 |
maybe one
that can work with my notebook too! |
| 15:57.26 |
CIA-28 |
BRL-CAD:
03starseeker * r36108
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: More dsp
tweaking - still doesn't raytrace. |
| 16:04.40 |
CIA-28 |
BRL-CAD:
03starseeker * r36109
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: Hmm - flip
bottom face. Raytrace now at least gives something. |
| 16:28.26 |
*** join/#brlcad poolio
(n=poolio@BZ.BZFLAG.BZ) |
| 16:29.16 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 16:35.21 |
CIA-28 |
BRL-CAD:
03starseeker * r36110
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: Change a
couple more face flips - apparently getting a raytrace now, but
prep and raytrace times are both still very long. |
| 17:10.04 |
*** join/#brlcad parigaudi
(n=quassel@217.91.127.94) |
| 17:58.37 |
CIA-28 |
BRL-CAD:
03bob1961 * r36111 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): A few minor tweaks. |
| 18:17.02 |
``Erik |
holy owwow,
SOMEONE's about to get a major beatdown http://chicago.craigslist.org/chc/sad/1399709773.html |
| 18:44.03 |
*** join/#brlcad BigAToo1
(n=BigAToo@96.230.124.102) |
| 18:45.01 |
d-lo |
``Erik: lol,
that is awesome. |
| 19:02.24 |
*** join/#brlcad samrose
(n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 20:22.19 |
CIA-28 |
BRL-CAD:
03brlcad * r36112
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: implement
more breep conversion support callbackage |
| 20:25.25 |
CIA-28 |
BRL-CAD:
03brlcad * r36113
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: reorder
to remove the forward declarations on implementation-specific
helper functions. |
| 20:31.13 |
CIA-28 |
BRL-CAD:
03brlcad * r36114
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: plot
needs a brep db internal |
| 20:33.10 |
starseeker |
``Erik: yeah,
that's some of the best lawyer bait I've seen for a
while |
| 20:35.23 |
CIA-28 |
BRL-CAD:
03brlcad * r36115
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: pass the
new brep db internal, not the old bspline one |
| 20:45.55 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-102.sbndin.btas.verizon.net) |
| 21:25.47 |
CIA-28 |
BRL-CAD:
03brlcad * r36116
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: display
both the old and new wireframes for now |
| 21:51.50 |
CIA-28 |
BRL-CAD:
03brlcad * r36117 10/brlcad/trunk/TODO: mged needs to better deal
with kicking off an editor. really need to kick off our own
terminal and invoke whatever editor from there. |
| 22:14.45 |
brlcad |
hm, a new
.deb for ubuntu.. http://tecnicoslinux.com.ar/ |
| 22:16.03 |
brlcad |
nice if
someone could test it out to see if it's worth hosting
up |
| 22:18.02 |
brlcad |
and for those
that can't read spanish, the link in there is http://www.tecnicoslinux.com.ar/livecd/brlcad_7.10_i386.deb |
| 22:34.11 |
louipc |
sounds
old |
| 22:44.40 |
brlcad |
7.10 is old,
but I think the .deb is new :) |
| 22:45.03 |
brlcad |
certainly
newer than the last .deb posted (7.8.4) |
| 22:46.47 |
CIA-28 |
BRL-CAD:
03brlcad * r36118
10/brlcad/trunk/src/librt/primitives/bspline/nurb_brep.cpp:
accumulate the bounding volume across the whole model |
| 23:07.44 |
``Erik |
is the
misc/debian unusable? I lost access to debian quite a while back
:( |
| 23:07.55 |
brlcad |
should be
usable |
| 23:08.04 |
brlcad |
more someone
actually compiling the deb |
| 23:09.13 |
``Erik |
and probably
no 'customer' we could use as leverage to get a debian machine at
the office |
| 23:09.52 |
brlcad |
I have access
to a couple someone, but that really should be done by someone in
the community (imnsho) |
| 23:10.02 |
brlcad |
s/someone/somewhere/ |
| 23:11.00 |
``Erik |
*shrug* I
wasn't all that sad when I deleted my debian partition to make more
space for fbsd |
| 23:11.03 |
``Erik |
:) |
| 23:11.47 |
``Erik |
(actually, I
still have a debian machine... has, um, 120mhz cyrix processor with
a dead fan, 48m ram, and I think a 1.6g hdd |
| 23:11.50 |
``Erik |
) |
| 23:12.50 |
brlcad |
I'd rather
see us hit every monthly source release with solid docs, stable
tools, clean builds, then focus on community infrastructure
(website, wiki, forums, docs) |
| 23:13.01 |
brlcad |
if we're
doing that, the community support will follow |
| 23:13.07 |
``Erik |
spoze |
| 23:13.24 |
``Erik |
I think I
need to cook up some test cases for metaballs, there suddenly seem
to be a slew of issues cropping up :/ |
| 23:13.33 |
``Erik |
stupid ray
marching crap |
| 23:14.17 |
``Erik |
check this
one out, I got a "test geometry" |
| 23:14.28 |
brlcad |
that procdb I
hijacked is great for testing :) |
| 23:14.32 |
``Erik |
33 individual
metaballs, each containing exactly one control point, unioned
together |
| 23:14.41 |
``Erik |
<--
doesn't think they ... get it |
| 23:15.03 |
brlcad |
I gave a
snippet that showed how to merge them with code |
| 23:15.15 |
``Erik |
ah, in the
last hour or two? |
| 23:15.25 |
brlcad |
no, couple
months bad |
| 23:15.28 |
brlcad |
back |
| 23:15.30 |
``Erik |
oh
heh |
| 23:15.42 |
brlcad |
I suspect
it's because they don't like how they merge weight-wise --
non-intuitiv |
| 23:15.49 |
``Erik |
I did some
c&p/vim/c&p today and got a nice generated mb with no
issues |
| 23:16.01 |
``Erik |
the blob
method is far better for what they want |
| 23:16.03 |
brlcad |
they want the
weight/power/whatever to be a distance |
| 23:16.06 |
brlcad |
then
blend |
| 23:16.13 |
``Erik |
effectively
what blob does |
| 23:16.27 |
``Erik |
iso is the
'weird' one :/ |
| 23:17.15 |
``Erik |
if'n I woulda
seen these earlier, I would've seen about preparing materials to
steal 10 minutes of this upcoming release meeting in the
library |
| 23:23.22 |
``Erik |
overclocks his stove O.o |
| 23:41.37 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 00:00.49 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177871686.dsl.bell.ca) |
| 00:03.59 |
*** join/#brlcad mafm
(n=mafm@2.Red-83-63-197.staticIP.rima-tde.net) |
| 00:16.32 |
Ralith |
``Erik: not
atm |
| 00:16.37 |
Ralith |
the latter,
probably |
| 00:16.42 |
Ralith |
I can rememdy
that though |
| 00:16.43 |
Ralith |
why? |
| 00:17.40 |
``Erik |
in case you
wanted to see isst in action |
| 00:20.10 |
louipc |
heheh IriX64
just told me that he has brl-cad working on vista 64, with the
obligatory screen shot |
| 00:24.02 |
starseeker |
woooot! |
| 00:24.05 |
starseeker |
is online once more |
| 00:24.12 |
``Erik |
damnit |
| 00:24.14 |
``Erik |
there goes
the neighborhood |
| 00:24.20 |
``Erik |
70's boy is
back online |
| 00:24.35 |
starseeker |
70's?? more
like 40's |
| 00:24.46 |
``Erik |
mirror walls,
shag carpet |
| 00:24.52 |
starseeker |
ah, yes
:-) |
| 00:24.57 |
``Erik |
are your
appliance alvacado, or goldenrod? :D |
| 00:25.02 |
starseeker |
mirror wall
check, shag carpet (thankfully) no |
| 00:25.03 |
``Erik |
appliances |
| 00:25.10 |
starseeker |
off-white |
| 00:25.22 |
louipc |
all of that
sounds awesome to me |
| 00:25.27 |
``Erik |
really off
white? like alvacado? ;) |
| 00:25.51 |
``Erik |
(so gettin'
my arse kicked tomorrow) |
| 00:26.02 |
starseeker |
nah, still
too tired |
| 00:26.10 |
starseeker |
although
brlcad has got to be even more shot |
| 00:26.22 |
brlcad |
nah |
| 00:26.59 |
``Erik |
something
about a bigassed needle full of adrenaline through the rib cage and
straight into the heart, he's wired so bad his eyes are as messed
up as uma's |
| 00:27.04 |
``Erik |
:D
*duck* |
| 00:27.16 |
brlcad |
ah, heh,
welcome back to the addiction starseeker |
| 00:27.28 |
brlcad |
mm..
uma |
| 00:27.41 |
brlcad |
could be a
good kill biller time |
| 00:28.03 |
brlcad |
or I could
catch the two heroes i've not seen yet |
| 00:28.06 |
``Erik |
(was actually
a pulp fiction crack, but *shrug* whatever's good) |
| 00:28.28 |
brlcad |
*snort*
"damn, I said god damn!" |
| 00:28.49 |
brlcad |
one of my fav
quotes/scenes in pulp |
| 00:29.19 |
brlcad |
just finished making some of the best spaghetti
evar |
| 00:29.27 |
``Erik |
finishes up his lasagna |
| 00:30.59 |
starseeker |
wonders just how many updates he has waiting to
compile... |
| 00:32.05 |
``Erik |
heh "if I'm
gay, then freddy mercury was gay!" |
| 00:40.36 |
starseeker |
winces - 111 packages |
| 00:40.49 |
starseeker |
oh, well...
time to stress the local power grid |
| 00:42.12 |
louipc |
laffs |
| 00:42.40 |
starseeker |
sees subversion related items in the list and updates BRL-CAD
before starting the process |
| 00:43.01 |
``Erik |
wow, I'm glad
I use freebsd and macports so I don't have to deal with all that
O.o |
| 00:43.25 |
louipc |
wouldn't you
if you wanted to update all your apps? |
| 00:43.42 |
``Erik |
</sarcasm> |
| 00:43.51 |
starseeker |
``Erik: oh,
it SHOULD work - the last time I updated it and it broke, it was
upstreams fault |
| 00:44.00 |
starseeker |
tends to run on the cutting edge |
| 00:44.38 |
starseeker |
too many cool
changes recently for me to want to get stuck on the old code for
any longer |
| 00:44.39 |
louipc |
I'm on the
bleeding edge too, but I don't have to build 95% of it
heh |
| 00:45.18 |
starseeker |
actually prefers it that way - there's a sort of purity in
knowing your system can build itself from source
code |
| 00:45.47 |
louipc |
winks |
| 00:46.16 |
``Erik |
psst,
starseeker, I think he's hittin' on ya |
| 00:47.05 |
starseeker |
nah, he just
wants my mirror wall |
| 00:47.19 |
starseeker |
oh, I need to
check out Haiku again |
| 01:58.22 |
brlcad |
``Erik: may
be reading it wrong, but that obj-g memset is
sizeof(pointer) |
| 01:58.44 |
brlcad |
just
bu_calloc instead and should be "sure" |
| 01:59.52 |
brlcad |
otherwise,
needs to be sizeof(struct whatever) |
| 02:00.54 |
brlcad |
yay, looks
like tcl folks are finally looking into our command length
patch |
| 02:01.37 |
yukonbob |
waves in |
| 02:01.40 |
yukonbob |
which
patch? |
| 02:11.26 |
``Erik |
brlcad: I
think I made that fix but didn't commit it? O.o dun remmeber, have
to look at the src at work |
| 02:11.36 |
``Erik |
it's in mid
thrash :D |
| 02:12.46 |
``Erik |
the original
was banged out on a saturday and committed wtihout testing, gotta
make things, y'know, work now |
| 02:34.55 |
brlcad |
you made some
commits, that's only reason I noticed the snippet |
| 02:53.13 |
brlcad |
yeah, you
took out the sizeof() |
| 03:13.11 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 03:13.12 |
*** join/#brlcad Ralith (n=ralith@69.90.49.189) [NETSPLIT
VICTIM] |
| 03:13.12 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 03:13.12 |
*** join/#brlcad archivist_emc
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 03:13.12 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 03:13.12 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 03:13.12 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 03:13.12 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 03:13.12 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 03:13.12 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 03:17.31 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 04:48.51 |
CIA-28 |
BRL-CAD:
03brlcad * r36139 10/brlcad/trunk/src/conv/obj-g.c:
callocified |
| 05:36.39 |
*** join/#brlcad IriX64
(n=mario_du@bas2-sudbury98-1177871686.dsl.bell.ca) |
| 05:38.28 |
*** part/#brlcad IriX64
(n=mario_du@bas2-sudbury98-1177871686.dsl.bell.ca) |
| 06:47.21 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 06:47.21 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks everyone! || Logs at
http://ibot.rikers.org/%23brlcad/ |
| 07:14.49 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 07:30.10 |
*** join/#brlcad roberthl_
(n=robert@rhl.me.uk) |
| 10:00.23 |
*** join/#brlcad roberthl
(n=robert@rhl.me.uk) |
| 12:05.30 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36140 10/brlcad/trunk/src/conv/obj-g.c: use
bu_fgets. update facemax. |
| 12:21.37 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36141 10/brlcad/trunk/src/conv/obj-g.c: fix
multiple group parsing |
| 13:05.00 |
*** join/#brlcad BigAToo
(n=BigAToo@208.95.141.189) |
| 14:43.20 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36142 10/brlcad/trunk/src/conv/obj-g.c: stubs
for more commands |
| 17:27.25 |
``Erik |
whoa, screw
that, I'm just gonna do a small subset of obj |
| 17:31.11 |
*** join/#brlcad mafm
(n=mafm@193.153.52.102) |
| 17:40.57 |
*** join/#brlcad parigaudi
(n=quassel@217.91.127.94) |
| 18:19.33 |
starseeker |
brlcad: hmm,
pastbin.bzflag.bz seems to be having some issues |
| 18:19.49 |
starseeker |
well, in the
meantime I'll use another one |
| 18:20.04 |
brlcad |
starseeker:
yeah, fs was full |
| 18:20.17 |
starseeker |
brlcad:
anyway - I have a debugging backtrace on the failure of ogl to
attach on OSX: |
| 18:20.24 |
starseeker |
http://paste.lisp.org/display/88073 |
| 18:29.04 |
brlcad |
starseeker:
yeah, that trace looks familiar |
| 18:30.03 |
starseeker |
not helpful,
eh? |
| 18:38.08 |
brlcad |
not really
unfortunately -- the display pointer looks alright, and you can't
get any data info for functions lower than
Tk_InternAtom() |
| 18:38.29 |
starseeker |
hmm. How do
we attack this then? |
| 18:38.47 |
brlcad |
i mean, it
feels like the x11 incompat from a while back |
| 18:39.03 |
brlcad |
remember that
debian bug? |
| 18:39.33 |
starseeker |
ick |
| 18:39.34 |
brlcad |
there was a
hack we could apply to tk to fix it, and there was a fix to x11 as
well |
| 18:39.53 |
starseeker |
so it's not
something at our level you think? |
| 18:40.24 |
brlcad |
I'm sure
we're provoking it *somehow* .. but yeah, not clear if it's
actually something wrong on our end |
| 18:40.44 |
brlcad |
does this
result in the BadAtom abort? |
| 18:41.04 |
brlcad |
or just
crashes? |
| 18:41.14 |
starseeker |
just
crashes |
| 18:41.27 |
brlcad |
what's the
setup? running local on mac 10.5 to local mac x11 ? |
| 18:41.35 |
starseeker |
yep |
| 18:41.48 |
brlcad |
is this an
enable-all ? |
| 18:42.19 |
starseeker |
yep |
| 18:42.34 |
brlcad |
what does
otool -L look like on the binary? |
| 18:43.39 |
starseeker |
want
pastebin? |
| 18:44.02 |
brlcad |
it's highly
suspicious that it crashes in Tk_InternalAtom .. and there are
other reports of a Linux x11 client to mac server failing out
(cleanly) with an X11 BadAtom failure |
| 18:44.13 |
brlcad |
sure |
| 18:46.17 |
starseeker |
http://paste.lisp.org/display/88075 |
| 18:47.21 |
brlcad |
hm, that
looks good |
| 18:48.27 |
brlcad |
oh ,sweet! ..
http://www.sealiesoftware.com/valgrind/ |
| 18:50.01 |
starseeker |
hah! |
| 19:06.17 |
starseeker |
diffing
running the same debugging steps on both dm_X and dm_ogl, these are
the only differences that occur prior to the X atom stuff: http://paste.lisp.org/display/88073#1 |
| 19:06.39 |
starseeker |
nothing null
in there I can see |
| 19:07.03 |
brlcad |
that's not
null |
| 19:07.08 |
starseeker |
unless it's
the missing "T" in private13 |
| 19:07.23 |
brlcad |
it's 0xc i.e.
12 |
| 19:20.43 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 19:20.44 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 19:20.44 |
*** join/#brlcad archivist_emc
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 19:20.44 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 19:20.44 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 19:20.44 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 19:29.27 |
*** join/#brlcad jdoliner
(n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net) |
| 19:33.01 |
*** join/#brlcad Ralith
(n=ralith@d142-058-091-230.wireless.sfu.ca) |
| 19:42.33 |
brlcad |
is having major net issues for some reason .. can't load web
pages |
| 19:43.10 |
starseeker |
growls at X11 + ogl + OSX... |
| 19:52.51 |
*** join/#brlcad Ralith
(n=ralith@d142-058-091-230.wireless.sfu.ca) |
| 20:11.15 |
starseeker |
brlcad: I
don't suppose the Togl widget would help us any? |
| 20:12.23 |
brlcad |
how
so? |
| 20:12.59 |
starseeker |
perhaps it
has a different way of managing Tk/ogl interactions? |
| 20:13.17 |
brlcad |
there is
already the start of a tk dm |
| 20:14.15 |
starseeker |
apparently
all of our display managers incorporate Tk? |
| 20:15.50 |
brlcad |
no |
| 20:16.28 |
brlcad |
mged's tk
sets up a window, our dm draws into it using whatever
protocol |
| 20:16.52 |
brlcad |
so there's an
interaction there |
| 20:17.26 |
starseeker |
hmm |
| 20:17.49 |
starseeker |
so setting up
a non-tk window would require a fair bit of libdm code? |
| 20:19.46 |
brlcad |
you can't
without making all of mged's gui non-tk |
| 20:20.01 |
brlcad |
libdm knows
nothing of tk |
| 20:21.19 |
brlcad |
this is
unbearable .. can barely use the network |
| 20:21.27 |
starseeker |
But (for
example) dm_ogl.c uses Tk_Window types (sorry if I'm being
dense) |
| 20:23.29 |
brlcad |
ah, yeah --
sorry didn't know that's what you meant |
| 20:24.38 |
brlcad |
"libdm knows
nothing of tk" should have been "libdm knows nothing of
tk-mged" |
| 20:24.44 |
starseeker |
nods |
| 20:24.57 |
brlcad |
it still
chats tk to either create the window or embed into a
window |
| 20:25.12 |
starseeker |
will that
need to change for the new GUI? |
| 20:25.26 |
brlcad |
if we want to
use libdm, yes |
| 20:25.42 |
brlcad |
otherwise, if
it does it's own thing, won't matter |
| 20:26.26 |
starseeker |
ah |
| 20:27.44 |
brlcad |
the original
purpose of libdm is no longer relevant, I wouldn't mind it going
away |
| 20:27.53 |
brlcad |
it's purpose
was abstracting away *hardware* differences |
| 20:28.16 |
starseeker |
oh, OK
:-) |
| 20:29.01 |
brlcad |
it's still
relevant for supporting entirely different output formats, like
graphical display vs network display vs plot files vs image
buffers, etc |
| 20:29.23 |
brlcad |
but not
necessarily for the myriad of graphical displays for
wgl/ogl/tk/x11/whatever |
| 20:30.04 |
brlcad |
there are
projects that do a better job abstracting that than we do (namely
sdl, tk, ogre, clanlib, etc) |
| 20:30.43 |
``Erik |
heh, clanlib,
that's one I haven't heard in a long time |
| 20:31.06 |
brlcad |
it's ripe for
major refactoring, because there is a lot of useful logic
there |
| 20:31.06 |
brlcad |
especially
with something radically different like rtgl |
| 20:31.47 |
starseeker |
sounds like a
candidate for a 2 hour "educate the clueless new programmer" design
discussion ;-0 |
| 20:31.54 |
starseeker |
;-)
even |
| 20:32.16 |
brlcad |
the way tk
was shoe-horned in for window creation is unfortunately messy,
shouldn't be any direct tk in libdm except for the tk
dm |
| 20:34.21 |
brlcad |
with bob
working on an ogre dm, that makes for a convenient bridging path
from old to new |
| 20:36.36 |
brlcad |
``Erik:
what's surprising is how well those guys keep at it over this many
years .. :) |
| 20:36.46 |
brlcad |
they've
picked up activity massively this past year |
| 20:37.01 |
``Erik |
back in
college, a buddy of mine (ken) and I were trying to make a worms2
clone with it |
| 20:37.08 |
``Erik |
it was...
really... crappy :D |
| 20:37.44 |
brlcad |
they were
handicapped for years because of no 3dd support |
| 20:37.57 |
``Erik |
yeh, and we
were probably using the blit routines wrong |
| 20:38.03 |
``Erik |
was hard to
make it ok on a 166mhz pentium |
| 20:38.11 |
brlcad |
heh, that'd
do it |
| 20:38.22 |
``Erik |
yet worms2
ran swank on that machine, with no 3d accelerator in it |
| 20:38.54 |
``Erik |
(BUT, the
pentium had... ooh, MMX!) |
| 20:39.01 |
brlcad |
plus back
then, the clanlib guys were in college too :) |
| 20:39.09 |
``Erik |
yeh |
| 20:39.22 |
``Erik |
looking at
the history, it musta been really fresh back then |
| 20:39.45 |
brlcad |
they've been
working on a new GUI system for it, which if they can get fleshed
out might give them a really nice niche to carve out for
themselves |
| 20:39.48 |
``Erik |
first public
release '99, this was probably in late '99 or '00 |
| 20:40.31 |
``Erik |
personally,
lispbuilder is what's making me put the throwpillow on my lap at
this point |
| 20:41.43 |
*** join/#brlcad poolio
(n=poolio@BZ.BZFLAG.BZ) |
| 20:41.57 |
``Erik |
dynamic
redefinition in a live environment + heavy MVC configuration... :)
^C^C and the 'draw' function changes in the running program, no
need to reload data or nothin' |
| 20:42.03 |
``Erik |
*doingggngngnng* |
| 20:43.34 |
*** join/#brlcad d-lo
(n=claymore@BZ.BZFLAG.BZ) |
| 20:45.16 |
starseeker |
well, that
was weird |
| 20:45.39 |
starseeker |
xterm froze,
closed it, reopened, logged back in, and still had to detatch and
reattach screen |
| 20:46.31 |
``Erik |
that happens
once in a while |
| 20:47.00 |
``Erik |
the sighup
doesn't make it to all the xterms child processes, so bash thinks
it's still connected, so screen thinks its' still
attached |
| 20:47.52 |
starseeker |
humph |
| 20:48.16 |
starseeker |
wonders if there has been any more progress in the state of
the art Qt+Ogre |
| 20:48.38 |
starseeker |
Ogre forums
suck for this kind of thing... |
| 20:49.08 |
``Erik |
what kind of
thing, finding information? :D *duck* |
| 20:49.16 |
starseeker |
yep |
| 20:49.46 |
``Erik |
starseeker:
seen okra? |
| 20:50.11 |
starseeker |
no - what is
it? |
| 20:50.13 |
``Erik |
okra+buclet
might be nifty |
| 20:50.16 |
``Erik |
cl
ogre |
| 20:50.25 |
``Erik |
buclet is cl
bullet |
| 20:50.33 |
starseeker |
heh -
cool |
| 20:57.51 |
brlcad |
starseeker:
their folks work (i.e., have discussions) via their forums like how
we work on irc |
| 20:58.17 |
brlcad |
if you want
to know something, best to ask there instead if searching doesn't
come up |
| 20:59.02 |
``Erik |
has noticed that panda looks that way on the outside (and
newbies are directed to the forums), but there's an awful lot that
happens on irc in spats if you wait long enough |
| 21:02.51 |
brlcad |
there is some
that happens on irc, but most of their core devs aren't |
| 21:03.15 |
brlcad |
so you can
get some info, but mostly anecdotal unless that particular dev is
here |
| 21:13.05 |
``Erik |
yowza, that
takes me back heh |
| 21:13.46 |
``Erik |
crank up the
main loop, update the code while running, bug causes the main loop
to crash... just like kernal hacking on the c64 with a monitor
:D |
| 21:14.16 |
starseeker |
posted a question - we'll see what happens |
| 21:14.47 |
``Erik |
assumes lithpth exception system could be convinced to allow
the program to throw an error and continue, but doesn't know it yet
:D |
| 21:15.17 |
``Erik |
brlcad: set
your dvr for 'stargate universe' tonight? |
| 21:24.29 |
brlcad |
don't have
dvr any more, mostly all on-line |
| 21:24.43 |
brlcad |
but I'll
probably try to watch that one live unless I forget |
| 21:32.25 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 21:32.25 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload
your code to google, wait for shirt ;) thanks everyone! || Logs at
http://ibot.rikers.org/%23brlcad/ |
| 21:33.23 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 21:33.23 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 21:33.23 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 21:33.23 |
*** join/#brlcad archivist_emc
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 21:33.23 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad ``Erik
(i=Here@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad mafm (n=mafm@193.153.52.102) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 21:33.23 |
*** join/#brlcad starseeker (n=starseek@63.246.136.16)
[NETSPLIT VICTIM] |
| 21:33.23 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 21:33.23 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 21:33.23 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad CIA-28 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 21:33.23 |
*** join/#brlcad kanzure (i=bryan@146.6.84.36) [NETSPLIT
VICTIM] |
| 21:33.31 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 21:33.31 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 21:37.22 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 22:48.43 |
*** join/#brlcad mafm_
(n=mafm@193.153.198.190) |
| 23:08.06 |
*** join/#brlcad mafm
(n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) |
| 00:06.33 |
CIA-33 |
BRL-CAD:
03starseeker * r36171 10/brlcad/trunk/src/libdm/dm-ogl.c: Ooops,
typos. |
| 00:09.25 |
starseeker |
man this ogl
bug is subtle |
| 00:10.37 |
louipc |
``Erik: but
did the taliban lose 100 or 7? |
| 00:23.50 |
starseeker |
helllllp... |
| 00:29.58 |
starseeker |
how do I
debug this thing??? |
| 00:32.45 |
starseeker |
can't believe it's UpdateTitle that results in sudden
death... |
| 00:37.57 |
starseeker |
contemplates making a Tk window before calling ogl_open and
"faking" a gui startup sequence |
| 00:38.15 |
starseeker |
q |
| 00:38.18 |
starseeker |
whoops |
| 03:58.06 |
CIA-33 |
BRL-CAD:
03brlcad * r36172 10/brlcad/trunk/ (include/bu.h
src/libbu/globals.c): move the doxy docs for the globals declared
extern in bu.h to bu.h |
| 11:51.23 |
CIA-33 |
BRL-CAD:
03davidloman * r36173 10/brlcad/trunk/src/proc-db/ (4 files in 2
dirs): initial work for a building/structure proc-db |
| 11:53.53 |
d-lo |
brlcad or
anyone else: is there any existing functionality for tracking
'used' object names inside a database? (so as to prevent
duplication) |
| 11:58.30 |
brlcad |
you do a
db_lookup on the name |
| 11:58.39 |
brlcad |
LOOKUP_QUIET |
| 11:59.07 |
d-lo |
good deal,
thanks. |
| 11:59.22 |
brlcad |
that is also
a librt routine, not a write-only operation |
| 11:59.49 |
d-lo |
Also, is
there any dire reason (beyong preference) to use C over
C++? |
| 12:00.07 |
brlcad |
no such
assertion |
| 12:01.04 |
brlcad |
tools can be
c/c++, it's the libs and existing c apps that shouldn't
mix |
| 12:01.25 |
d-lo |
okay. I only
ask because I keep running into 'great things' that could be done
with a pinch of OO. |
| 12:01.49 |
d-lo |
Que ``Erik
with some snide "lisp rulz!!1!" comment :) |
| 12:01.52 |
brlcad |
turning a
tool into a library routine would be problematic as c++ down the
road if portaions are generalizable to a library, like
libged |
| 12:03.29 |
brlcad |
you can do
most OO constructs in c, at least most of the ones that are not
just syntax shortcuts |
| 12:04.05 |
d-lo |
I was really
looking at function overloading... its a pain not having it
:) |
| 12:12.52 |
brlcad |
ah, you can
get yourself polymorphism, but you have to do a little
setup |
| 12:13.25 |
d-lo |
but how much
is gained by 'doing a little setup' versus just using
cpp? |
| 12:14.03 |
brlcad |
depends on
the use |
| 12:14.24 |
brlcad |
it keeping it
as a set of C routines that you can pull into a library is
important, then might be worthwhile |
| 12:14.34 |
brlcad |
otherwise,
just use c++ |
| 12:15.01 |
d-lo |
and the only
reason why a cpp lib is bad is simply because all the others are c
libs? |
| 12:15.16 |
brlcad |
notes "cpp" is rather confusing/misleading as it's the name
of the "c pre processor" that expands #includes and
such |
| 12:15.52 |
brlcad |
a cpp lib
isn't bad |
| 12:16.07 |
brlcad |
mixing c++
into a C api is generally bad |
| 12:17.10 |
d-lo |
right, so if
this make building thing turns into a lib (down the road), then
wiring it into libged would prove difficult if libBuilding (or
whatever) is c++ ? |
| 12:17.32 |
brlcad |
there are ABI
portability issues with the libraries, linkage incompatibilities,
other issues |
| 12:17.42 |
brlcad |
if it is
fully contained as such, then not so bad |
| 12:18.22 |
brlcad |
it's more
that you cannot expose it (at all) symbol-wise and public
API |
| 12:19.28 |
brlcad |
e.g.,
openNURBS in librt -- not exposed, just an implementation detail
under the hood so linkage still doesn't expose any c++ |
| 12:19.57 |
d-lo |
Hrm, so it it
were all 'under the hood' and operated on a provided db_i only,
then it would be safe? |
| 12:20.13 |
brlcad |
doable |
| 12:20.53 |
brlcad |
be more
concerned that you've learned how to use one shiney hammer, so
everything looks like it needs to be beaten with that hammer
:) |
| 12:21.28 |
brlcad |
they're
different mindsets with tradeoffs on both ends, good to be
proficient in both :) |
| 12:21.36 |
d-lo |
huh? I am
talking about how to best implement an idea. |
| 12:21.44 |
brlcad |
likewise |
| 12:21.59 |
brlcad |
the language
has little to do with that |
| 12:23.17 |
brlcad |
it's more a
procedural data-driven approach vs an object-oriented approach vs a
functional approach, etc |
| 12:24.05 |
brlcad |
you can take
most problems and implement them with any one of those three and
there are lots of tradeoffs, rare that one is superbly dominating
"better" |
| 12:24.11 |
brlcad |
usually more
just one is more "familiar" |
| 12:24.35 |
brlcad |
just saying
it's good to hone skills at least on the other two at some point as
well |
| 12:25.26 |
brlcad |
otherwise
everything starts looking like an OO problem and you miss the big
picture, acquire bad habits, tend to over-architect, over-abstract,
obfuscate, ... it's a balance |
| 12:34.22 |
*** join/#brlcad Yoshi47
(n=jan@firewall.walinga.com) |
| 13:18.21 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
| 13:21.05 |
``Erik |
*readreadread* |
| 13:22.53 |
``Erik |
exposing c++
shtuff in libraries gets into issues with different name mangling
(there is no standard). G++ isn't (or wasn't) even self-consistent,
so a library providing c++ entry points compiled with, say, gcc 4.1
couldn't be correctly linked to with gcc 4.2, it'd get missing
symbols, iirc |
| 13:24.22 |
``Erik |
heh, yes,
people new to oo become "architect astronauts" and start designing
things like... upstairs... :D *duck* |
| 13:44.07 |
d-lo |
tee
hee. |
| 14:50.50 |
*** join/#brlcad mafm
(n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) |
| 15:22.56 |
brlcad |
howdy mafm
m |
| 15:23.50 |
mafm |
hi
there |
| 16:34.11 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14D686.dip.t-dialin.net) |
| 16:47.31 |
*** join/#brlcad Ralith
(n=ralith@d142-058-080-147.wireless.sfu.ca) |
| 17:05.46 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 18:07.09 |
*** join/#brlcad Ralith
(n=ralith@d142-058-091-146.wireless.sfu.ca) |
| 18:38.17 |
``Erik |
hm, a darcs
library was listed as a 'todo' back in june |
| 18:38.18 |
CIA-33 |
BRL-CAD:
03davidloman * r36174 10/brlcad/trunk/src/proc-db/
(makebuilding/makebuilding.c mkbuilding.h): Coninuting work on
Makebuilding. Added mkbuilding.h |
| 18:44.48 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 19:15.33 |
CIA-33 |
BRL-CAD:
03brlcad * r36175 10/brlcad/trunk/src/util/pl-dm.c: vls strings use
%V now instead of %S |
| 19:34.09 |
CIA-33 |
BRL-CAD:
03brlcad * r36176 10/brlcad/trunk/src/util/pl-dm.c: reorder
function definitions so forward declarations are not
necessary. |
| 20:02.10 |
CIA-33 |
BRL-CAD:
03starseeker * r36177
10/brlcad/trunk/src/libdm/dm-ogl.c: |
| 20:02.10 |
CIA-33 |
BRL-CAD: OK,
temporarily comment out some of the dm-ogl code - this allows
things to come |
| 20:02.11 |
CIA-33 |
BRL-CAD: up
on the Mac, but (obviously) messes with the initialization of the
gl context |
| 20:02.11 |
CIA-33 |
BRL-CAD:
something fierce. Try to work out why these commands are upsetting
things. |
| 20:25.46 |
CIA-33 |
BRL-CAD:
03brlcad * r36178 10/brlcad/trunk/src/util/pl-dm.c: more cleanup,
quell slew of warnings, remove unused vars. |
| 20:39.13 |
CIA-33 |
BRL-CAD:
03brlcad * r36179 10/brlcad/trunk/src/util/pl-dm.c: enable the '-t
o' option to open up an ogl display manager. sure enough, it
crashes. |
| 20:40.12 |
brlcad |
what's
interesting there is that there are no calls to
make_current |
| 20:42.31 |
``Erik |
hum, "reverse
debugging" in the new gdb |
| 22:32.32 |
Maloeran |
Reverse
debugging? Walking instructions backwards? |
| 22:32.37 |
``Erik |
ayup |
| 22:32.48 |
Maloeran |
That would
require an awful lot of memory, and be very slow |
| 22:33.48 |
Maloeran |
I guess that
works to walk a couple instructions back, but you could never get
very far anyway. You can't undo system calls and such |
| 22:33.51 |
``Erik |
um, there's
some lib that does it in a not totally sucky way (mebbe it saves
state delta on nondeterministic ops) |
| 22:35.36 |
``Erik |
http://news.ycombinator.com/item?id=868769 |
| 22:35.44 |
Maloeran |
gnome-terminal is pretty bad as a
terminal. You flood it on stdout and it freezes or dies |
| 22:36.12 |
``Erik |
yeah, it does
checkpointing |
| 22:36.17 |
Maloeran |
Multi-inferior? What is that? |
| 22:36.43 |
``Erik |
gnome-terminal and kterm are ass, xterm is
ok, rxvt-devel was what I really used before hopping over to
mac |
| 22:37.08 |
``Erik |
"multi-inferior" sounds like some damn
emacs weenie was allowed in the club, I d'no O.o :D |
| 22:37.41 |
Maloeran |
Yes, I'm
always using rxvt. I put Ubuntu on the laptop and I sometimes use
gnome-terminal for some reason, but it's pretty bad |
| 22:38.56 |
``Erik |
screen
eliminates all the pro's that gnome-terminal and kterm have for
anyone who can operate a basic text editor... :) |
| 22:39.25 |
``Erik |
and if you
can't figure out "pico" or "nano", you don't belong opening a
terminal emulator :D |
| 22:40.35 |
``Erik |
http://dmtcp.sourceforge.net/ |
| 22:40.37 |
Maloeran |
This is quite
bad when doing printf() debugging, and the terminal freezes or
dies. When it freezes, it also freezes the program trying to write
on the stdout pipe |
| 22:41.05 |
Maloeran |
And when it
dies... You lose all programs launching from that terminal, that's
just lovely |
| 22:41.10 |
Maloeran |
launched* |
| 22:41.36 |
``Erik |
I don't
remember the app crashing, but I do remember getting annoyed that
the kernel compiles on linux took much longer on my 120mhz
machine... |
| 22:42.27 |
Maloeran |
And it's
slow, yes. Now imagine the terminal freezing or dying meaning the
compilation stops trying to write on stdout |
| 22:42.46 |
Maloeran |
punches gnome-terminal some more |
| 22:46.04 |
``Erik |
rxvt and be
happy O.o |
| 22:47.03 |
Maloeran |
I know, I'm
just amazed that some mainstream and common software can be so
buggy, and it's just a terminal |
| 22:47.40 |
``Erik |
probably one
of those "good enough for the plebes, but all the REAL power-users
know better" |
| 22:47.43 |
``Erik |
:/ |
| 22:50.00 |
``Erik |
(though
having written a color terminal emulator using a gtk+ text widget
before, it's trivial to make it sorta work and a real pain to make
it fast) |
| 22:51.02 |
Maloeran |
Seems rather
easy to make it fast... but I wouldn't use gtk+ for the rendering,
I would play with X directly |
| 22:51.40 |
``Erik |
scanning and
handling control codes was the big stinker on mine, I
think |
| 22:52.11 |
Maloeran |
Yes, that
part sounds rather messy |
| 22:52.33 |
``Erik |
and looking
at my code, I've learned quite a few tricks in the last decade
heh |
| 22:52.49 |
Maloeran |
Oh, you too?
:) |
| 22:53.05 |
Maloeran |
Sometimes I'm
almost glad I lost most of my >5 years old code |
| 22:53.57 |
``Erik |
<-- has
learned quite a coding few tricks in the last 26 years, intends to
learn quite a few more coding tricks in the next 26 :) |
| 22:54.19 |
Maloeran |
Even updating
the old Rayforce just a month ago... I rewrote all the
multithreading, threw away a bunch of pthreads stuff to use
x86/amd64 atomic instructions |
| 22:54.30 |
Maloeran |
Eheh |
| 22:54.50 |
``Erik |
heh, I found
a simd library for sbcl last week O.O |
| 22:55.12 |
louipc |
haha I'm a
power user for using rxvt? |
| 22:55.13 |
Maloeran |
Pthreads
still annoy me on many aspects, I'm so tempted to just use clone(),
futex() and my atomic instructions |
| 22:55.17 |
``Erik |
<--
grouses some more that rayforce isn't in BRL-CAD |
| 22:56.30 |
Maloeran |
The wake up
process of pthreads, for threads blocked on condition variables
doesn't allow any decent prioritization mechanism |
| 22:56.44 |
``Erik |
louipc: more
that a "power-user" wouldn't use gnome-terminal... |
| 22:56.46 |
Maloeran |
And the
underlying futex() stuff is so much more flexible |
| 22:56.57 |
``Erik |
upside down
A's and backwards E's, man |
| 22:57.32 |
``Erik |
mal: that's
great until you want it to work on something other than linux, or
the linux internals change (again) |
| 22:58.21 |
Maloeran |
You can't
define scheduling priorities for different threads with pthreads,
seriously how retarded is that? |
| 22:58.21 |
``Erik |
the solaris
libthread.so package was effin' INSANELY awesome, but coding to it
means you don't leave solaris and hope they don't jerk the rug out
from under you... |
| 22:58.52 |
Maloeran |
Mmhm :), I
never played with it I'm afraid |
| 22:59.27 |
Maloeran |
I did some
home-made threading on Linux, using the system calls, to see how
flexible the underlying interface is... and that just made me more
frustrated with Posix threads |
| 22:59.58 |
``Erik |
the bsd
thread mapping capability is awesome, too... ya get to choose if a
thread is a userland thing, an OS 1:1 mapping, or an OS many:many
mapping... without recompiling! :) |
| 23:00.43 |
``Erik |
the linux
kobj thingie was designed to do processes, then threading was
bolted into it, and it was shaken around to do anything
inbetween... *shrug* |
| 23:00.54 |
Maloeran |
Being able to
wake up any thread *you* choose when signaling a condition variable
or releasing a mutex, how come you can't do that with Posix
threads? |
| 23:01.07 |
``Erik |
when pthreads
were new, the notion of threading was in its infancy and every
vendor had tis own horrible attempt |
| 23:01.14 |
Maloeran |
Or definiting
the "niceness" or scheduling priority of any thread, gez, that
should be simple enough |
| 23:01.36 |
``Erik |
what if the
OS only supports userland threads? or doesn't have the notion of
process priority? |
| 23:01.54 |
Maloeran |
Then disable
the feature, or make it do nothing! But at least make it
*possible*! |
| 23:02.06 |
Maloeran |
You can't
have different scheduling priorities with Posix threads, you just
can't |
| 23:02.06 |
``Erik |
nt4 was made
posix compatible, and it only had retarded round robin scheduling
iirc |
| 23:02.38 |
Maloeran |
I don't mind
if some features are not available on some platforms, but at least
make them available on the platforms that do support
them |
| 23:02.42 |
louipc |
in unix worse
is better |
| 23:02.44 |
louipc |
that's
why! |
| 23:03.38 |
Maloeran |
Erik, I'm
seriously very close to just switch over to my own Linux-only
threading stuff, with a pthread fallback for other OSes |
| 23:03.53 |
``Erik |
srry, dude,
their crystal ball was in the shop when pthreads were spec'd, I
mean, the notion that a student could write a semi-usable *nix-like
os and people would help him for shits and giggles woulda gotten
you laughed out of the room |
| 23:04.23 |
``Erik |
so predicting
how linux does its nth generation threading... yknow.. |
| 23:05.20 |
Maloeran |
Erik, I'm
just saying that pthreads do not expose a bunch of very fundamental
features for threading. I know some OSes may not support
them |
| 23:05.40 |
``Erik |
yeah, I hear
ya, dude... I'm saying that pthreads predates those fundamental
features :D |
| 23:06.02 |
Maloeran |
Well if they
aren't going to update the library, then we need something
new |
| 23:06.20 |
louipc |
yep |
| 23:06.29 |
Maloeran |
I think I'll
just switch over to my Linux threading stuff, with a pthread
fallback |
| 23:08.10 |
``Erik |
would rather have cpu affinity control than priority control
for threads *shrug* :) |
| 23:08.14 |
Maloeran |
How could not
imagine that someone may want to define different scheduling
priorities for different threads. No, they had to enforce that
*all* threads *MUST* share the same scheduling priority. Why?
Why?... |
| 23:08.33 |
``Erik |
hm |
| 23:08.44 |
``Erik |
what if I
renice a multithreaded program to 20 |
| 23:08.45 |
Maloeran |
There's cpu
affinity stuff, although it's a different library |
| 23:09.04 |
Maloeran |
All the
threads share the same niceness, says the specification |
| 23:09.05 |
``Erik |
and I really
fucking mean make every thread go to 20, I don't want the program
to decide if it's going to listen |
| 23:09.08 |
``Erik |
? |
| 23:09.20 |
``Erik |
ok, so posix
does that for me, what about futex? |
| 23:09.26 |
Maloeran |
What if the
program has some low priority and high priority
threads? |
| 23:09.55 |
louipc |
well there
should be a signal for it, non? |
| 23:10.08 |
Maloeran |
futex() is
the kernel-level thing for mutexes and condition variables, but if
you write your own threading stuff, you can define the scheduling
of threads any way you want it |
| 23:10.14 |
``Erik |
sleep(0);
forces a yield, essentually giving you a low priority thread (in a
semi-cooperative fashion) |
| 23:10.38 |
``Erik |
um |
| 23:10.49 |
``Erik |
I have a book
somewhere that talks about the low level threading crap |
| 23:10.50 |
Maloeran |
What if you
have a bunch of threads and you wake to wake up a specific one,
which must run right *now*? |
| 23:10.52 |
``Erik |
wonder where
I put it |
| 23:11.11 |
Maloeran |
Signaling it
and sleep(0) may or may not make it actually run |
| 23:11.22 |
``Erik |
mal: then
your program is written really poorly :D *duck* |
| 23:11.23 |
louipc |
sounds like
fun problems |
| 23:11.42 |
Maloeran |
Erik, that's
a very common case of feeder/consumer threads |
| 23:12.47 |
``Erik |
doesn't remember needing to wake it up "right now" doing
those things, putting them back into the run queue was sufficient
O.o |
| 23:13.50 |
Maloeran |
Typical
example : on a 8 cores machine, with 8 consumer threads, you
predict the threads will begin to starve soon and the feeder thread
must absolutely run very soon |
| 23:14.12 |
``Erik |
"add job; inc
jobs available;" | "Icanhasawurkunit? tkae; dec jobs
avail" |
| 23:14.20 |
Maloeran |
And posix
threads just won't you do that, you can merely try to wake it up
and sleep() a few threads in the hope that it will get to
run |
| 23:14.29 |
``Erik |
heh |
| 23:14.37 |
Maloeran |
won't let*
you do that |
| 23:15.00 |
``Erik |
8
threads/procs on 8 cores tends to cause OTHER ugly problems, like
resource lockstepping |
| 23:15.27 |
``Erik |
<-- likes
to do 2n-1 for things that touch single interface resources like
disk drives |
| 23:15.47 |
Maloeran |
That thread
prioritization problem should not exist, because it doesn't exist
when you use a decent low-level threading interface ( like futex()
) |
| 23:16.22 |
``Erik |
<-- more
apt to think that the problem doesn't... actually... exist... :D
*duck* |
| 23:16.43 |
Maloeran |
Especially
since kernels sometimes try to keep the same threads on the same
core, and the kernel may have decided that your very important
feeder thread must run on core 5, so it's just not going to wake up
for a while |
| 23:16.48 |
Maloeran |
And threads
end up starving |
| 23:18.01 |
Maloeran |
I don't know,
it's a matter of flexibility and control... and pthreads don't give
you much in both areas |
| 23:18.50 |
``Erik |
*shrug* I've
never had issue cooking all 8 cores (or 256) until something using
an ugly slow resource (disks, network, etc) come into
play |
| 23:19.51 |
``Erik |
take, for
example, BRL-CAD's rt, it can smoke up 1024 cpu's n/p even writing
to disk if it buffers right, but it uses maybe one worth in mged
due to network silliness with giantlock and shtuff |
| 23:21.07 |
Maloeran |
Sure sure,
but I'm not tempted to assume the design is optimal, in comparison
to what could be achieved with more control and
flexibility |
| 23:22.26 |
``Erik |
I d'no, dude,
I have a feeling that you might be wayyyy down the path of
diminishing returns |
| 23:23.01 |
Maloeran |
For one
thing, atomic instructions instead of mutexes or spin locks make a
huge difference |
| 23:23.20 |
Maloeran |
( Okay, it's
not portable, but when you got them... ) |
| 23:23.22 |
``Erik |
yeah, I can
see that one easily |
| 23:23.37 |
``Erik |
far less
cycles and eliminates branches |
| 23:24.10 |
``Erik |
but inventing
a threading system to keep a producer hot? O.o |
| 23:24.11 |
Maloeran |
More than
that, you avoid the constant read and write to shared memory
lines |
| 23:24.49 |
Maloeran |
It's not just
for that, I was pointing out one example but pthreads are limited
on many aspects |
| 23:25.09 |
``Erik |
sure, but how
much do those aspects really matter? :D just throwin' it out
there |
| 23:25.43 |
Maloeran |
Meh :), you
add them all up and I think it matters |
| 23:26.13 |
``Erik |
I'd be
curious as to your post mortem analysis :) |
| 23:26.19 |
Maloeran |
Atomic
instructions, thread scheduling from mutexes or condition
variables, CPU affinity, per-thread niceness/priority,
etc. |
| 23:28.34 |
Maloeran |
The feeder
thing actually was a problem in Rayforce when rendering something
simple, it goes up to 100-500 frames per second and the kernel too
often tries to maintain the "feeder" thread on the same CPU core
instead of waking it up right now when needed |
| 23:28.39 |
``Erik |
pthread_attr_setschedparam()
? |
| 23:28.50 |
Maloeran |
So unless you
buffer up a lot of work ahead, I mean several frames, threads can
starve |
| 23:29.13 |
Maloeran |
Keep on
reading to see if you can actually do anything with
that |
| 23:29.47 |
Maloeran |
You can set
FIFO or round-robbing scheduling, but you can't define a thread
priority for normal thread scheduling |
| 23:31.08 |
``Erik |
that's not
what the man page says O>o |
| 23:32.52 |
Maloeran |
You should
try it out, to have a nice surprise on sched_priority... It
requires root to be modified! |
| 23:33.50 |
Maloeran |
And it
doesn't work for SCHED_OTHER, which is the normal out-of-order
threading |
| 23:34.01 |
``Erik |
sounds like
you attempted to increase the priority... that's against the
fundamental security model, only root can increase priority, users
can only reduce priority (increase nice) |
| 23:34.45 |
Maloeran |
Niceness is
shared by all Posix threads |
| 23:35.02 |
Maloeran |
And
sched_priority has no effect for SCHED_OTHER scheduling |
| 23:35.44 |
Maloeran |
( While
SCHED_RR and such requires root ) |
| 23:40.36 |
``Erik |
*shrug* |
| 23:42.33 |
Maloeran |
Anyway... as
you said, it was designed too long ago, and it needs an urgent
update or rewrite |
| 23:43.18 |
``Erik |
(I'd find it
amusing if you end up re-inventing fork() ) |
| 23:44.29 |
Maloeran |
It's not
quite fork(), threads use the clone() system call, so does fork()
of course |
| 23:44.35 |
louipc |
that would be
cool |
| 23:44.45 |
Maloeran |
clone() is a
very flexible little system call |
| 23:45.15 |
louipc |
I heard it
was stolen from plan9 or something |
| 00:38.27 |
*** join/#brlcad schwinn434
(n=schwinn4@75.81.202.25) |
| 03:25.21 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 06:08.22 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 07:03.37 |
CIA-22 |
BRL-CAD:
03brlcad * r36282 10/brlcad/trunk/src/mged/chgtree.c: cleanup,
remove unused 'really_delete' static and unused extern
decls |
| 07:05.51 |
CIA-22 |
BRL-CAD:
03brlcad * r36283 10/brlcad/trunk/configure.ac: define HAVE_TK if
we have Tk facilities available instead of relying on just the tk.h
header or assuming X11 means Tk. for now, check if x11 is off,
opengl is off, wgl is off, and we're not building tk. |
| 07:06.42 |
CIA-22 |
BRL-CAD:
03brlcad * r36284 10/brlcad/trunk/src/mged/ (attach.c cmd.c
mged.h): utilize the new HAVE_TK to turn off the Tk portions of
mged at compile-time |
| 07:07.28 |
*** join/#brlcad ``Erik
(i=Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 07:10.41 |
CIA-22 |
BRL-CAD:
03brlcad * r36285 10/brlcad/trunk/src/mged/ (mged_dm.h update.c):
check for HAVE_TK |
| 07:11.16 |
CIA-22 |
BRL-CAD:
03brlcad * r36286 10/brlcad/trunk/src/libtclcad/ (tclcad.c
tclcadAutoPath.c tkImgFmtPIX.c): check for HAVE_TK instead of
HAVE_TK_H |
| 07:18.10 |
CIA-22 |
BRL-CAD:
03brlcad * r36287 10/brlcad/trunk/src/mged/ (mged.h update.c):
minor cleanup and reformatting |
| 07:32.08 |
CIA-22 |
BRL-CAD:
03brlcad * r36288 10/brlcad/trunk/include/config_win.h: windows
always has Tk support |
| 07:32.47 |
CIA-22 |
BRL-CAD:
03brlcad * r36289 10/brlcad/trunk/include/dm_xvars.h: a little more
tight typedeffage to not double def the chip. |
| 07:33.13 |
CIA-22 |
BRL-CAD:
03brlcad * r36290 10/brlcad/trunk/src/mged/ (9 files): check the
other tk.h headers prior to inclusion |
| 07:38.35 |
CIA-22 |
BRL-CAD:
03brlcad * r36291 10/brlcad/trunk/src/mged/dm-X.c: restructure to
avoid unnecessary forward decls even with the screwy
dependencies |
| 07:55.58 |
CIA-22 |
BRL-CAD:
03brlcad * r36292 10/brlcad/trunk/src/libdm/dm-X.c: compile-time
disassociation from Tk, untested but compiles clean. |
| 07:58.48 |
CIA-22 |
BRL-CAD:
03brlcad * r36293 10/brlcad/trunk/src/libdm/dm-X.c: cleanup,
formatting, stuff |
| 08:03.06 |
CIA-22 |
BRL-CAD:
03brlcad * r36294 10/brlcad/trunk/src/mged/dm-X.c: oops, multichar
constants are bad |
| 08:06.28 |
CIA-22 |
BRL-CAD:
03brlcad * r36295 10/brlcad/trunk/include/dm_xvars.h: provide
something for Display and Window, even if horribly wrong, just to
have the struct elements |
| 08:08.09 |
CIA-22 |
BRL-CAD:
03brlcad * r36296 10/brlcad/trunk/include/dm_xvars.h: ah, Colormap
wants to be tricked out too |
| 08:16.22 |
CIA-22 |
BRL-CAD:
03brlcad * r36297 10/brlcad/trunk/src/mged/doevent.c: hide the X11
bits from sight and de-K&Rify the buttonknob funcs |
| 08:21.21 |
CIA-22 |
BRL-CAD:
03brlcad * r36298 10/brlcad/trunk/src/mged/update.c: stub in unused
Tk callback funcs if we're not compiling for X11 |
| 08:23.47 |
CIA-22 |
BRL-CAD:
03brlcad * r36299 10/brlcad/trunk/src/mged/Makefile.am: need to
conditionally link against tk/itk in case we're not compiling
against those |
| 08:25.09 |
CIA-22 |
BRL-CAD:
03brlcad * r36300 10/brlcad/trunk/src/mged/attach.c: missed a Tk
call that needs protection |
| 08:35.30 |
CIA-22 |
BRL-CAD:
03brlcad * r36301 10/brlcad/trunk/src/rttherm/Makefile.am:
ssampview is a Tk-toting shooter. protect accordingly. |
| 08:49.53 |
CIA-22 |
BRL-CAD:
03brlcad * r36302 10/brlcad/trunk/src/rttherm/Makefile.am: be sure
to still include ssampview sources in the dist |
| 08:50.47 |
CIA-22 |
BRL-CAD:
03brlcad * r36303 10/brlcad/trunk/src/util/Makefile.am: even though
bombardier only uses Tk, couple it to X11 for the time being until
there's a more specific configure subst for WITH_TK (not the dm/fb
one) |
| 08:52.19 |
CIA-22 |
BRL-CAD:
03brlcad * r36304 10/brlcad/trunk/src/util/Makefile.am: note the
FIXME for bombardier |
| 09:07.28 |
yukonbob |
notices brlcad's voracious coding, bids
goodnight. |
| 09:09.21 |
CIA-22 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Hexbolt.png]]":
Example hex bolt screenshot |
| 09:14.31 |
CIA-22 |
BRL-CAD:
03Sean 07http://brlcad.org * r1639
10/wiki/Hex: add a screenshot |
| 09:15.50 |
CIA-22 |
BRL-CAD:
0369.10.33.218 07http://brlcad.org
* r1640 10/wiki/Help:Navigation: |
| 09:24.26 |
CIA-22 |
BRL-CAD:
03brlcad * r36305 10/brlcad/trunk/src/util/ttcp.c: totally punt and
make ttcp treat haiku as a SYSV system since getrusage() isn't
implemented yet. |
| 09:25.20 |
CIA-22 |
BRL-CAD:
03brlcad * r36306 10/brlcad/trunk/src/util/Makefile.am: ttcp needs
the network lib |
| 09:26.37 |
CIA-22 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:69.10.33.218]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
| 09:26.47 |
CIA-22 |
BRL-CAD:
03Sean 07http://brlcad.org * r1641
10/wiki/Help:Navigation: Undo revision 1640 by
[[Special:Contributions/69.10.33.218|69.10.33.218]] ([[User
talk:69.10.33.218|Talk]]) |
| 09:26.48 |
d-lo |
wonders if brlcad is awake.... :) |
| 09:35.11 |
CIA-22 |
BRL-CAD:
03brlcad * r36307 10/brlcad/trunk/src/libtclcad/ged_obj.c: more
protectage of the tk.hage; yes, I'm actually awake d-lo
:) |
| 09:36.46 |
d-lo |
MWAHAHA! |
| 09:36.59 |
CIA-22 |
BRL-CAD:
03brlcad * r36308 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c:
quell warnings on string calls. annotate TclGetLibraryPath() as
being a bastard internal that we're abusively using. or, maybe I'm
not really awake and just happened to time this *just*
right.. |
| 11:02.45 |
*** join/#brlcad mafm
(n=mafm@42.Red-83-40-127.dynamicIP.rima-tde.net) |
| 11:22.17 |
CIA-22 |
BRL-CAD:
03brlcad * r36309 10/brlcad/trunk/src/libged/clone.c: push the
result string into print_usage since it's peeking in
regardless. |
| 11:24.13 |
CIA-22 |
BRL-CAD:
03brlcad * r36310 10/brlcad/trunk/src/libged/annotate.c: tweak up
usage, include header |
| 11:24.29 |
CIA-22 |
BRL-CAD:
03brlcad * r36311 10/brlcad/trunk/src/libged/Makefile.am: enable
annotate.c compilation. |
| 11:30.15 |
CIA-22 |
BRL-CAD:
03brlcad * r36312 10/brlcad/trunk/src/libged/nmg_fix_normals.c:
quell constness warning |
| 11:30.47 |
CIA-22 |
BRL-CAD:
03brlcad * r36313 10/brlcad/trunk/include/ged.h: declare
ged_annotate() |
| 11:33.13 |
CIA-22 |
BRL-CAD:
03brlcad * r36314 10/brlcad/trunk/src/libged/annotate.c: don't need
the db open to give help |
| 11:34.19 |
CIA-22 |
BRL-CAD:
03brlcad * r36315 10/brlcad/trunk/src/libged/make_bb.c:
cleanup |
| 11:36.02 |
CIA-22 |
BRL-CAD:
03brlcad * r36316 10/brlcad/trunk/src/libged/make_bb.c: also
doesn't need the db open to display help (this is probably a bigger
refactoring todo) |
| 12:35.44 |
CIA-22 |
BRL-CAD:
03brlcad * r36317 10/brlcad/trunk/src/libbu/vls.c: automatically
calling system() if we find a '\!' shell escape char in a vls is,
like, a BAD idea. why rt_split_cmd() ever did this is moot as
nothing sets HAVE_SHELL_ESCAPE anyways. |
| 13:14.07 |
CIA-22 |
BRL-CAD:
03starseeker * r36318 10/brlcad/trunk/doc/docbook/Makefile.am: Erm,
only one nirt_fig24, not two. |
| 13:14.54 |
starseeker |
wonders who fed brlcad the nuclear fuel, and hits the
road... |
| 13:53.53 |
CIA-22 |
BRL-CAD:
03bob1961 * r36319
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added the
following methods to give more flexibility to subclasses when
reading/writing preferences: readPreferencesInit,
writePreferencesHeader and writePreferencesBody. |
| 13:56.19 |
CIA-22 |
BRL-CAD:
03bob1961 * r36320
10/brlcad/trunk/src/tclscripts/archer/AttrGroupsDisplayUtility.tcl:
A little cleanup. |
| 14:12.12 |
CIA-22 |
BRL-CAD:
03bob1961 * r36321 10/brlcad/trunk/ (6 files in 3 dirs): Added the
AttrGroupsDisplayUtility plugin. |
| 14:32.16 |
``Erik |
hm, 31,200
vgr's, not too shabby |
| 14:50.57 |
CIA-22 |
BRL-CAD:
03bob1961 * r36322 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added
refresh_on command to get/set refresh_on state. |
| 15:05.25 |
CIA-22 |
BRL-CAD:
03bob1961 * r36323
10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: |
| 15:05.25 |
CIA-22 |
BRL-CAD:
Added the following methods: ged_get_color, refresh_on,
refresh_off, |
| 15:05.25 |
CIA-22 |
BRL-CAD:
add_mouse_ray_callback, delete_mouse_ray_callback, center_ray
and |
| 15:05.25 |
CIA-22 |
BRL-CAD:
pane_mouse_ray. Converted ged_vdraw_color and ged_rgb_color to
class methods as |
| 15:05.25 |
CIA-22 |
BRL-CAD:
opposed to instance methods. |
| 15:05.56 |
CIA-22 |
BRL-CAD:
03bob1961 * r36324 10/brlcad/trunk/src/tclscripts/lib/pkgIndex.tcl:
Added a line for cadwidgets::Ged |
| 15:11.39 |
CIA-22 |
BRL-CAD:
03bob1961 * r36325 10/brlcad/trunk/include/tclcad.h: Added
go_refresh_on member to struct ged_obj. |
| 17:04.44 |
CIA-22 |
BRL-CAD:
03indianlarry * r36326 10/brlcad/trunk/src/ (4 files in 2
dirs): |
| 17:04.44 |
CIA-22 |
BRL-CAD:
Added option(-n) to bot_dump to include surface normals in
the |
| 17:04.44 |
CIA-22 |
BRL-CAD:
generation of an "obj" file. Includes mods to "obj-g" to
parse |
| 17:04.44 |
CIA-22 |
BRL-CAD: over
normals on input. Also happened to bring up a memory |
| 17:04.44 |
CIA-22 |
BRL-CAD:
freeing error in "obj-g". |
| 17:25.47 |
*** join/#brlcad parigaudi
(n=quassel@217.91.127.94) |
| 17:33.10 |
CIA-22 |
BRL-CAD:
03starseeker * r36327 10/brlcad/trunk/src/libdm/dm-rtgl.c: Well,
now the draw commands don't trigger a redraw, but multiple items in
the drawing list don't loop. |
| 18:06.42 |
*** join/#brlcad AirBender
(n=AirBende@pc-188-190-46-190.cm.vtr.net) |
| 18:10.45 |
AirBender |
Hello, a
friend discovered brlcad yesterday, and looks like a great piece of
Software! I got the current svn revision, and tried to compile it
on ubuntu 9.10 using gcc 4.4.1, but there's an error regarding a
redefinition of getline. |
| 18:12.22 |
AirBender |
have you
compiled it with this GCC version? I know that it's more stricter
than previous versions... |
| 18:17.55 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EB90.dip.t-dialin.net) |
| 18:47.38 |
AirBender |
excellent, is
compiling now. The problem was related to jove, and apparently it
isn't necessary |
| 19:14.18 |
starseeker |
oh, yeah - I
have to disable jove too on gentoo |
| 19:16.49 |
starseeker |
and it really
isn't needed - it's an old editor |
| 19:32.48 |
brlcad |
http://createuniverses.blogspot.com/2009/09/qtcsg-constructive-solid-geometry.html |
| 19:38.06 |
CIA-22 |
BRL-CAD:
03brlcad * r36328 10/brlcad/trunk/src/other/jove/ (jove.h
jove_io.c): rename getline/putline to get_line/put_line so as not
to conflict with the gnu getline() extension. |
| 19:39.11 |
starseeker |
brlcad:
that's pretty cool |
| 19:41.04 |
brlcad |
and the
related former project:
http://createuniverses.blogspot.com/2008/09/constructive-solid-geometry-program.html |
| 19:41.25 |
brlcad |
which started
off of http://unbboolean.sourceforge.net/ |
| 19:41.44 |
brlcad |
no idea if
there meshing is any good at all, but interesting
nonetheless |
| 19:42.22 |
brlcad |
especially
whether they provide any sort of topological guarantees like our
libnmg |
| 19:42.41 |
brlcad |
or whether
they even attempt to address numerical floating point
issues |
| 19:42.54 |
starseeker |
ah yes, the
hard questions :-) |
| 19:43.14 |
starseeker |
likes the lisp scripting they snuck in |
| 20:18.55 |
brlcad |
thought you would |
| 20:52.21 |
CIA-22 |
BRL-CAD:
03brlcad * r36329 10/brlcad/trunk/src/libged/annotate.c: midstream,
but commit progress regardless. stash object(s) into a string while
parsing args. |
| 20:52.40 |
CIA-22 |
BRL-CAD:
03brlcad * r36330 10/brlcad/trunk/src/tclscripts/mged/help.tcl:
document the y/n option on opendb |
| 21:01.39 |
CIA-22 |
BRL-CAD:
03brlcad * r36331 10/brlcad/trunk/src/other/jove/ (jove_delete.c
jove_insert.c jove_io.c jove_misc.c): have to rename all the
getline() calls |
| 21:03.30 |
CIA-22 |
BRL-CAD:
03brlcad * r36332 10/brlcad/trunk/src/other/jove/ (jove_delete.c
jove_insert.c jove_io.c jove_misc.c): and rename the matching
put_line() calls. that should do it. |
| 21:05.18 |
starseeker |
brlcad: heh,
thanks brlcad - beat me to it |
| 21:06.51 |
``Erik |
svn rm
src/other/jove O.o |
| 21:07.07 |
starseeker |
I think it's
scheduled, but we can't do it yet :-( |
| 21:08.12 |
brlcad |
deprecated in
7.14, so 7.20 it can die |
| 21:10.23 |
CIA-22 |
BRL-CAD:
03starseeker * r36333 10/brlcad/trunk/src/ (libged/CMakeLists.txt
proc-db/Makefile.am): Oops, couple missing items in make
files. |
| 21:10.45 |
brlcad |
starseeker:
np, my bad regardless -- and no problem being called on it to fix
bustage, but telling me/you/anyone shouldn't take longer than the
fix or we both fail ;) |
| 21:11.07 |
starseeker |
heh - quite
true |
| 21:11.08 |
brlcad |
like that
one, thx |
| 21:12.08 |
starseeker |
just wasn't sure if the coding juices had resulted in a
massive whitespace and tweakage fix of jove or not
;-) |
| 21:14.11 |
CIA-22 |
BRL-CAD:
03starseeker * r36334 10/brlcad/trunk/doc/docbook/Makefile.am: Erm,
yeah - probably want to bring more than just articles along for the
EXTRA_DIST ride... |
| 21:38.13 |
*** join/#brlcad Mkop
(i=a57bcb2d@gateway/web/freenode/x-hwovuotspzcgkcfz) |
| 21:38.48 |
brlcad |
jove would
get no such attention |
| 21:38.53 |
brlcad |
especially
once deprecated |
| 21:38.56 |
Mkop |
I realize
this is off topic, but do any of you know of a CAD package that can
handle mirror surfaces and angles of reflection of a
laser? |
| 21:39.27 |
brlcad |
Mkop: er,
brl-cad does that with basic phong shading |
| 21:39.40 |
Mkop |
what does
that mean? |
| 21:39.55 |
brlcad |
that other
jove fix was just because it was trivial and causing a build
failure |
| 21:40.05 |
starseeker |
nods |
| 21:40.44 |
brlcad |
Mkop: we have
a ray-tracing engine in brl-cad that is used for shooting rays,
which can be and are used to simulate lots of things |
| 21:40.52 |
brlcad |
such as
lasers |
| 21:41.02 |
brlcad |
our optics
library handles basic material interactions |
| 21:41.22 |
brlcad |
computing
surface normals and reflection rays is pretty trivial |
| 21:41.58 |
brlcad |
you'd have to
write a driver application or set up some custom scripts, but
depends on what exactly you need |
| 21:42.07 |
brlcad |
otherwies,
no, can't help you with other packages ;) |
| 21:42.55 |
Mkop |
I'm designing
a laser galvo system |
| 21:43.18 |
Mkop |
i.e. we have
out-of-box galvos, and want to create drawings showing what will
happen to the beam when the mirrors are rotated |
| 21:46.31 |
CIA-22 |
BRL-CAD:
03brlcad * r36335 10/brlcad/trunk/include/common.h: |
| 21:46.31 |
CIA-22 |
BRL-CAD: wow,
HIDDEN has been non-static all this time... 'lint' is apparently no
longer |
| 21:46.31 |
CIA-22 |
BRL-CAD:
being defined so couple the static setting to whether or not we're
compiling in |
| 21:46.31 |
CIA-22 |
BRL-CAD:
debug mode or not (so by default, debug mode has non-static for
traceability). |
| 21:46.31 |
CIA-22 |
BRL-CAD: this
means applications will have to take care to not clobber library
symbols. |
| 21:46.57 |
``Erik |
drawings like
what? |
| 21:48.44 |
``Erik |
you could
model your 'world' box, mirror and laser in BRL-CAD, then render a
bunch of images with the mirror oriented differently and glue the
results into either a single image with the line the laser draws,
or show an animation of it... |
| 21:48.55 |
CIA-22 |
BRL-CAD:
03bob1961 * r36336 10/brlcad/trunk/src/bwish/ (cmd.c input.c):
Changed history_record to history_record_priv to avoid a name
collision with libbu. |
| 21:49.19 |
brlcad |
~seen
clock_ |
| 21:49.22 |
ibot |
clock_
<n=clock@84-72-91-240.dclient.hispeed.ch> was last seen on
IRC in channel #brlcad, 293d 7h 17m 19s ago, saying: 'did it want
you to take it for a hitchhike?'. |
| 21:49.29 |
brlcad |
what's his
new name? |
| 21:49.34 |
``Erik |
sushi I
think |
| 21:49.42 |
brlcad |
~seen
_clock_ |
| 21:49.43 |
ibot |
_clock_
<n=_sushi_@80-218-244-105.dclient.hispeed.ch> was last seen
on IRC in channel #brlcad, 16d 8h 56m 11s ago, saying: 'who has
worked on PDP-1?'. |
| 21:49.48 |
brlcad |
~seen
sushi |
| 21:49.48 |
ibot |
i haven't
seen 'sushi', brlcad |
| 21:50.01 |
brlcad |
~seen
_sushi_ |
| 21:50.02 |
ibot |
_sushi_
<n=_sushi_@84-72-9-254.dclient.hispeed.ch> was last seen on
IRC in channel #brlcad, 18d 2h 33m 2s ago, saying: '``Erik:
stupidity=1/IQ ?'. |
| 21:50.03 |
``Erik |
~seen
_clock_ |
| 21:50.03 |
ibot |
_clock_
<n=_sushi_@80-218-244-105.dclient.hispeed.ch> was last seen
on IRC in channel #brlcad, 16d 8h 56m 31s ago, saying: 'who has
worked on PDP-1?'. |
| 21:50.17 |
brlcad |
probably
about right |
| 21:50.48 |
starseeker |
brlcad: what
was the name of that really nice font? |
| 21:51.21 |
``Erik |
http://pastebin.bzflag.bz/d6a804868 |
| 21:51.23 |
starseeker |
oh,
profont |
| 21:52.06 |
brlcad |
yeah |
| 21:52.23 |
brlcad |
notice how
the super-scaled down version on wikipedia actually shows up pretty
clearly |
| 21:52.27 |
brlcad |
and that's
like pt 4 :) |
| 21:52.34 |
brlcad |
most fonts
are gibbrish by that size |
| 21:52.58 |
starseeker |
nice |
| 21:57.02 |
brlcad |
Mkop: you
might want to take a look at the Ronja project -- that's a project
with *very* similar needs to yours, and is one that used brl-cad
for modeling, diagrams, animations, and more |
| 21:57.21 |
brlcad |
http://en.wikipedia.org/wiki/RONJA
and http://ronja.twibright.com/ |
| 21:57.36 |
starseeker |
winces - yeah, licensing doesn't look at all promising for
profont |
| 21:57.44 |
brlcad |
some
visualizations: http://ronja.twibright.com/3d/ |
| 21:58.04 |
starseeker |
he says he
can neither grant or deny licenses - that bad |
| 21:58.15 |
brlcad |
starseeker: I
mentioned that we looked at it extensively .. was just giving the
highlight summary |
| 21:58.28 |
brlcad |
wasn't just a
passing thing |
| 21:58.34 |
starseeker |
nods |
| 21:58.37 |
starseeker |
ouch |
| 21:58.47 |
Mkop |
sorry I'm not
responding to all of what you're saying, I'm just busy with
something else. I will be taking a look in a few
minutes. |
| 21:58.48 |
brlcad |
we attempted
for weeks to find the origins, the original author, etc -- as we
wanted it to be the main font |
| 21:59.00 |
brlcad |
Mkop: no
expectation of replies on irc ;) |
| 21:59.15 |
Mkop |
(I just know
there's nothing more annoying than some n00b coming into IRC,
asking a question, and ignoring answers, so I wanted to reasssure
you that's not the case) |
| 21:59.17 |
brlcad |
especially
timely ones, answers can come hours/days later ;) |
| 21:59.58 |
brlcad |
be forewarned
that brl-cad has a very steep learning curve, but lots of power and
capabilities under the hood |
| 22:00.07 |
brlcad |
the learning
curve cannot be overstated, though ;) |
| 22:02.26 |
yukonbob |
chimes in: Rewards are worth the effort. |
| 22:02.42 |
CIA-22 |
BRL-CAD:
03brlcad * r36337 10/brlcad/trunk/src/mged/setup.c: add the
annotate command to mged, as basic as it is at this
point |
| 22:03.36 |
CIA-22 |
BRL-CAD:
03brlcad * r36338 10/brlcad/trunk/include/bu.h: document the
(not-yet-committed) changes to bu_vls_from_argv() |
| 22:10.03 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 22:10.03 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 22:10.03 |
*** join/#brlcad Mkop
(i=a57bcb2d@gateway/web/freenode/x-hwovuotspzcgkcfz) [NETSPLIT
VICTIM] |
| 22:10.03 |
*** join/#brlcad Elrohir (n=kvirc@p5B14EB90.dip.t-dialin.net)
[NETSPLIT VICTIM] |
| 22:10.03 |
*** join/#brlcad ``Erik
(i=Here@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 22:10.03 |
*** join/#brlcad Ralith (n=ralith@69.90.49.189) [NETSPLIT
VICTIM] |
| 22:10.04 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 22:10.04 |
*** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com)
[NETSPLIT VICTIM] |
| 22:10.04 |
*** join/#brlcad poolio_ (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 22:10.04 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 22:10.04 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 22:10.04 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 22:10.04 |
*** join/#brlcad kanzure (i=bryan@dhcp-84-36.me.utexas.edu)
[NETSPLIT VICTIM] |
| 22:10.04 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 22:55.56 |
``Erik |
dang
n00b |
| 22:56.21 |
``Erik |
yeah,
learning curve, like the emacs or vim of modelers O.O
:D |
| 23:45.30 |
*** join/#brlcad matthewmpp
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
| 00:15.31 |
``Erik |
hm |
| 00:34.38 |
brlcad |
how was
dinner with la chica loca? |
| 00:36.03 |
starseeker |
raises eyebrow |
| 00:38.03 |
``Erik |
la what
now? |
| 00:38.57 |
``Erik |
oh |
| 00:39.13 |
``Erik |
heh, I didn't
get out of there until too late, so I called them and let them know
I wouldn't make it |
| 00:46.24 |
starseeker |
is bemused - the stix fonts are still not released, but at
least they finally settled on the SIL Open Font
License |
| 00:46.52 |
starseeker |
also, they
have "discovered many missing glyphs in the non-Unicode
fonts" |
| 00:47.01 |
starseeker |
wonders how that happened... |
| 00:50.17 |
AirBender |
what is bwish
in brlcad sources? |
| 00:51.36 |
AirBender |
uhmm
something like a customized tcl/tk ? |
| 00:51.50 |
AirBender |
is it needed?
can I use just Tcl/Tk? |
| 00:53.25 |
starseeker |
you can build
with a system Tcl/Tk if it's the right version, but IIRC bwish is
still built as a wrapper? I'd have to check |
| 00:53.41 |
AirBender |
ok |
| 00:53.42 |
starseeker |
is bwish
causing a problem? |
| 00:53.51 |
starseeker |
can usually treat it like wish |
| 00:53.55 |
AirBender |
I'm having
undefined references with bwish |
| 00:54.05 |
starseeker |
blinks |
| 00:54.09 |
starseeker |
starting
MGED? |
| 00:54.17 |
AirBender |
tkImgFmtPIX |
| 00:54.29 |
starseeker |
which program
are you running? |
| 00:54.30 |
AirBender |
when
compiling brlcad |
| 00:54.33 |
starseeker |
oh |
| 00:54.36 |
AirBender |
from
svn |
| 00:54.56 |
starseeker |
um - you
might try updating - there've been a lot of commits
today... |
| 00:55.05 |
starseeker |
dunno if any
of theim hit that part |
| 00:55.06 |
AirBender |
ok |
| 00:55.12 |
starseeker |
which
directory is it failing in? |
| 00:55.24 |
AirBender |
the symbol is
required in cmd.c from bwish |
| 00:55.39 |
AirBender |
src/bwish/cmd.c |
| 00:55.44 |
AirBender |
lne
76 |
| 00:55.48 |
AirBender |
line* |
| 00:56.05 |
starseeker |
erm |
| 00:56.26 |
starseeker |
yeah, try an
svn up first and see if that pulls any fixes |
| 00:56.35 |
AirBender |
yeap, doing
that |
| 00:56.49 |
AirBender |
36338 |
| 00:56.58 |
AirBender |
let's
see |
| 01:03.24 |
AirBender |
lots of
warning huh... |
| 01:06.32 |
AirBender |
by far the
most warning-full compilation I've ever done... =D |
| 01:06.46 |
starseeker |
hmm, font
article: http://mihmo.livejournal.com/45152.html |
| 01:06.57 |
starseeker |
AirBender:
yeah, it's a bit noisy in some areas |
| 01:07.06 |
starseeker |
particularly
on the newest gcc compilers |
| 01:08.00 |
AirBender |
yeap |
| 01:08.34 |
CIA-22 |
BRL-CAD:
03starseeker * r36339 10/brlcad/trunk/configure.ac: If we aren't
ready to build step yet, can't have the Makefile in configure.ac
without breaking distcheck. |
| 01:13.05 |
*** join/#brlcad matthewmpp_
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
| 01:13.54 |
brlcad |
AirBender:
what are your configure flags? |
| 01:13.55 |
*** part/#brlcad matthewmpp
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
| 01:15.12 |
brlcad |
a couple dirs
are chatty, but you really shouldn't be getting a lot of warnings
unless you enabled additional warnings |
| 01:15.13 |
AirBender |
mmm |
| 01:15.32 |
brlcad |
more than a
dozen of the core are even completely warning-free |
| 01:15.34 |
AirBender |
--enable-optimized --widh-ogl
--prefix=/usr/local/brlcad |
| 01:15.47 |
brlcad |
huh,
interesting |
| 01:16.13 |
AirBender |
may be the
reason is I'm using Gcc 4.x.x |
| 01:16.32 |
AirBender |
may be the
reason is I'm using Gcc 4.4.1 |
| 01:16.45 |
brlcad |
nah, I've run
many a build on 4.4 already |
| 01:16.50 |
AirBender |
ok |
| 01:17.29 |
brlcad |
also, fwiw,
the bwish issue is something pretty recent from one of the 100+
commits today |
| 01:17.46 |
AirBender |
I think it's
ok now |
| 01:17.46 |
brlcad |
if you want a
stable build, can grab the stable branch instead |
| 01:18.13 |
AirBender |
I want to be
synced with svn |
| 01:18.22 |
AirBender |
there's no
problem |
| 01:18.25 |
brlcad |
so you were
just out of sync? |
| 01:18.31 |
AirBender |
it's building
ok now |
| 01:18.40 |
brlcad |
or did you
edit something? |
| 01:18.53 |
AirBender |
and the
warning were on the first 10 minutes of compiling... |
| 01:19.04 |
brlcad |
oh,
heh |
| 01:19.05 |
brlcad |
yeah |
| 01:19.16 |
brlcad |
everything in
src/other is not our code, so it's chocked full of
warnings |
| 01:19.24 |
brlcad |
that compiles
fire |
| 01:19.26 |
brlcad |
*first |
| 01:19.33 |
AirBender |
I
see... |
| 01:19.41 |
AirBender |
well it's my
first time with brlcad |
| 01:19.58 |
brlcad |
src/other are
our external dependencies, they compile when it doesn't detect a
suitable system-installed version of that dependency |
| 01:20.09 |
brlcad |
e.g., libpng,
libz, tcl/tk, etc |
| 01:20.20 |
AirBender |
yes, I've
read it some minutes ago... |
| 01:21.03 |
AirBender |
interesting
approach... instead of installing every dependency on avery
error |
| 01:22.46 |
brlcad |
*nod*, mostly
download/distribution convenience but also for controlled
compilation testing |
| 01:22.58 |
AirBender |
ok |
| 01:23.00 |
brlcad |
lets us turn
everything on or everything off or individually, etc |
| 01:24.22 |
AirBender |
by the way,
do you see brlcad as a replacing for CATIA? |
| 01:25.07 |
AirBender |
replacement* |
| 01:25.11 |
AirBender |
sorry for my
english |
| 01:25.33 |
brlcad |
that's
certainly a desirable achievement and a package that covers a
similar domain |
| 01:25.34 |
CIA-22 |
BRL-CAD:
03starseeker * r36340 10/brlcad/trunk/src/libdm/dm-rtgl.c: Well,
can now refresh with B - but doing a draw of a second item when the
first one is working without either letting the first one finish or
clearing causes a crash. |
| 01:26.07 |
brlcad |
but I more
see ourselves as just doing the best at whatever our users need,
more niche requirements, more flexible customization |
| 01:27.03 |
brlcad |
CATIA employs
more than 1000 developers -- we have quite a ways to reach that
scale to be considered an outright replacement for all their
features |
| 01:27.16 |
AirBender |
I know, and I
understand that... |
| 01:27.39 |
AirBender |
I just wanted
to read an opinion of the current state |
| 01:28.04 |
``Erik |
seen the
'industry diagram' on the web site? |
| 01:28.24 |
AirBender |
uhmm in the
screenshots? |
| 01:29.11 |
``Erik |
in the
'diagrams' chunk of the gallery, yes |
| 01:29.22 |
``Erik |
http://brlcad.org/gallery/s/diagrams/Industry_Diagram.png.html |
| 01:30.23 |
``Erik |
that kinda
helps explain our... niche :) |
| 01:30.23 |
AirBender |
interesting... |
| 01:31.15 |
starseeker |
hmm, caps
only, but looks OK small (not clearly licensed though :-() http://www.kottke.org/plus/type/silkscreen/ |
| 01:31.28 |
brlcad |
we're slowly
expanging towards the left |
| 01:32.54 |
AirBender |
excellent |
| 01:33.05 |
brlcad |
starseeker:
not bad.. not as good as profont though :) |
| 01:33.17 |
brlcad |
plus the
all-caps is rather annoying |
| 01:33.26 |
starseeker |
nods |
| 01:33.55 |
starseeker |
downloads profont to see if he can dig the author's name out
of the font file... |
| 01:35.35 |
AirBender |
cool just
finished the build process... installing now |
| 01:35.56 |
AirBender |
Many thanks
for the help |
| 01:36.37 |
starseeker |
thanks for
trying it out! |
| 01:36.41 |
AirBender |
hope brlcad
meets my partner's requirements... |
| 01:36.47 |
AirBender |
in fact they
will be the users... |
| 01:36.57 |
starseeker |
run
/usr/local/brlcad/bin/mged to get going |
| 01:37.10 |
AirBender |
I'm just
building it |
| 01:37.17 |
AirBender |
ok |
| 01:37.29 |
starseeker |
you saw the
docs page? |
| 01:37.53 |
AirBender |
not too
much |
| 01:37.56 |
starseeker |
http://brlcad.org/wiki/Documentation |
| 01:38.14 |
starseeker |
specifically,
Introduction to MGED and the MGED Quick Reference Card |
| 01:39.10 |
AirBender |
ok |
| 01:39.23 |
brlcad |
AirBender:
yeah, that tutorial book is required reading -- just like any CAD
system, it's very complex with a lot to learn for new
users |
| 01:40.18 |
brlcad |
if you want
to try something fun, can run the "/usr/local/brlcad/bin/benchmark"
command to test your system performance |
| 01:40.20 |
AirBender |
I know... but
that's for my partners... I have enough to do with my
part(communications/electronics) |
| 01:40.47 |
AirBender |
will try
that |
| 01:42.13 |
AirBender |
Wow, nice to
see good documentation |
| 01:43.57 |
AirBender |
seems like
your specialty is in the cmputer graphics/rendering
area... |
| 01:44.30 |
AirBender |
well it's the
most atractive info to publish anyway =D |
| 01:47.37 |
starseeker |
brlcad: I
take it most of the profont bzflag discussion took place on
irc? |
| 01:47.46 |
brlcad |
starseeker:
mostly |
| 01:47.59 |
brlcad |
starseeker:
try emailing the profont addrs |
| 01:48.09 |
brlcad |
there should
be a couple in the license file |
| 01:48.36 |
brlcad |
the problem
is the license file is mostly just poorly worded |
| 01:48.54 |
starseeker |
nods - ooooold ones - figured those had been tried already,
but I suppose it can't hurt |
| 01:48.56 |
brlcad |
I remember it
having a couple serious problems |
| 01:50.13 |
starseeker |
hopes his gmail addy won't be spam
flagged... |
| 01:50.14 |
brlcad |
the terms
"maybe" added an additional restriction and didn't explicitly allow
derivative works |
| 01:50.30 |
brlcad |
both those
being lgpl/gpl incompatibilities |
| 01:50.40 |
starseeker |
nods |
| 01:51.01 |
brlcad |
otherwise the
terms are almost cc-by or cc-by-nc (the latter of which would be a
problem) |
| 01:51.25 |
brlcad |
looks up the name |
| 01:51.32 |
starseeker |
what do you
make of the SIL open font license? |
| 01:51.52 |
brlcad |
so yeah, Carl
Osterwald or Steve Gilardi would probably suffice |
| 01:53.13 |
AirBender |
is the
benchmark usable for the developers? |
| 01:53.19 |
AirBender |
or just for
my interest? |
| 01:53.27 |
AirBender |
it
finished |
| 01:53.52 |
AirBender |
6651 times
faster than reference |
| 01:54.42 |
brlcad |
AirBender: it
explains what the number means, but yeah it's useful to
know |
| 01:55.11 |
starseeker |
raises his eyebrow - never seen a one letter prefix to a
mac.com email address |
| 01:55.19 |
brlcad |
plus it gives
you a metric you can run system to system, compilation to
compilation, etc .. and gives you a directly comparable
metric |
| 01:56.30 |
brlcad |
starseeker:
er, don't think they're valid.. three is the min |
| 01:59.24 |
starseeker |
brlcad: hmm.
must be a red herring |
| 01:59.48 |
AirBender |
well, hope to
be able to cooperate with this great project in the near
future |
| 02:00.02 |
brlcad |
AirBender:
likewise! |
| 02:00.02 |
starseeker |
"Carl R.
Osterwald" <i.DeleteThis@mac.com> wrote... |
| 02:00.20 |
AirBender |
now we will
install it on the other computers |
| 02:00.47 |
brlcad |
we're always
looking for new devs |
| 02:00.51 |
brlcad |
if you're a
developer |
| 02:01.01 |
AirBender |
I've read
that there's a C++ abstraction layer in development? |
| 02:01.15 |
brlcad |
yeah,
geometry engine akin to the ACIS engine |
| 02:01.27 |
AirBender |
ok |
| 02:01.53 |
brlcad |
we have a C
API over geometry services right now |
| 02:02.19 |
brlcad |
http://brlcad.org/BRL-CAD_Priorities.png |
| 02:02.39 |
brlcad |
high-level
marketing priority talk |
| 02:03.16 |
brlcad |
starseeker:
can't hurt to e-mail/cc every address you find :) |
| 02:04.33 |
brlcad |
or contacting
folks they used to know |
| 02:04.39 |
brlcad |
we didn't go
that far last time |
| 02:04.48 |
brlcad |
(e.g.,
http://bishop.mc.duke.edu/bolo/guides/mapedit.html
) |
| 02:05.56 |
starseeker |
suspects anything short of sending out paid detectives would
be easier than finding brlcad a satisfactory replacement font
:-) |
| 02:09.02 |
*** join/#brlcad maes
(n=maes@190.163.31.17) |
| 02:10.58 |
*** part/#brlcad maes
(n=maes@190.163.31.17) |
| 02:12.28 |
*** join/#brlcad maes
(n=maes@190.163.31.17) |
| 02:12.50 |
brlcad |
one e-mail to
a dozen addresses is pretty easy :P |
| 02:12.59 |
starseeker |
hehe |
| 02:13.16 |
brlcad |
they'll
either come back failures or get ignored |
| 02:13.22 |
starseeker |
it doesn't
get serious until we pick up the phone and start calling
people |
| 02:15.05 |
brlcad |
would totally
be worth it for that font |
| 02:15.19 |
brlcad |
tens of
thousands of geeks would rejoice |
| 02:16.40 |
starseeker |
well,
distcheck now passes again on the Mac |
| 02:16.57 |
starseeker |
sans step-g,
sadly :-( |
| 02:17.22 |
starseeker |
really doesn't get that, what it is saying is undefined IS
defined in an included header, and Linux can find
it... |
| 02:20.38 |
starseeker |
should probably head home now |
| 02:21.30 |
starseeker |
saddles up and moves out |
| 02:38.46 |
CIA-22 |
BRL-CAD:
03brlcad * r36341 10/brlcad/trunk/src/bwish/cmd.c: |
| 02:38.46 |
CIA-22 |
BRL-CAD:
document the Tk_PhotoImageFormat tkImgFmtPIX structure, that it
comes from |
| 02:38.46 |
CIA-22 |
BRL-CAD:
libtclcad and providing PIX image processing support to Tk's image
subsystem |
| 02:38.46 |
CIA-22 |
BRL-CAD:
(even though it only seems to be used by bwish and not mged oddly
enough). |
| 02:38.46 |
CIA-22 |
BRL-CAD:
restructure to avoid decls while we're at it. |
| 03:07.04 |
*** part/#brlcad maes
(n=maes@190.163.31.17) |
| 04:18.39 |
CIA-22 |
BRL-CAD:
03brlcad * r36342
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: our nurbs
headers have to come after the step/sdai headers because we also
define DEBUG_OFF |
| 04:19.37 |
CIA-22 |
BRL-CAD:
03brlcad * r36343
10/brlcad/trunk/src/conv/step/RepresentationItem.h: missing sdai.h
for the SCLP23wahtever wrappage. |
| 04:20.51 |
CIA-22 |
BRL-CAD:
03brlcad * r36344 10/brlcad/trunk/configure.ac: readd step to
build, it should generate the makefile regardless of
compilability |
| 04:24.01 |
CIA-22 |
BRL-CAD:
03brlcad * r36345 10/brlcad/trunk/src/conv/Makefile.am: re-enable
traversal into the step dir. critical piece seems to be missing
here that you have to define DIST_SUBDIRS so we traverse all dist
dirs regardless of SUBDIRS (which isn't the same as EXTRA_DIST'ing
a subtree) |
| 04:24.48 |
CIA-22 |
BRL-CAD:
03brlcad * r36346 10/brlcad/trunk/src/conv/step/Makefile.am: minor
cleanup, one-per-line, shouldn't tab empty lines, declare built
sources. |
| 04:25.42 |
PrezKennedy |
brlcad, guess
what my current title at the pentagon is |
| 04:26.06 |
starseeker |
grins evilly... must resist temptation... |
| 04:26.24 |
starseeker |
brlcad:
thanks alot for looking at that step stuff |
| 04:26.32 |
starseeker |
is grateful |
| 04:26.44 |
brlcad |
there are
compilation failures/assumptions galore that still have to get
fixed |
| 04:27.03 |
brlcad |
PrezKennedy:
Monkey Butler? |
| 04:27.21 |
PrezKennedy |
close...
computer programmer |
| 04:27.30 |
brlcad |
cool |
| 04:39.53 |
CIA-22 |
BRL-CAD:
03brlcad * r36347 10/brlcad/trunk/include/ (dvec.h vector.h):
rename vector.h to dvec.h so we can avoid a name clash with the old
stl compatibility header of same name |
| 04:39.53 |
CIA-22 |
BRL-CAD:
03brlcad * r36348 10/brlcad/trunk/include/dvec.h: rename to dvec.h;
need raytrace.h for fastf_t |
| 04:39.53 |
CIA-22 |
BRL-CAD:
03brlcad * r36349 10/brlcad/trunk/src/conv/step/PullbackCurve.cpp:
include dvec.h instead of vector.h so we get the right
header |
| 04:39.53 |
brlcad |
so that gets
it to compile for me (untested runtime) |
| 04:39.53 |
brlcad |
check
distcheck and see if it still fails |
| 04:39.55 |
PrezKennedy |
its all good,
contract will be over long before we ever have the tools we need to
code :) |
| 04:40.12 |
brlcad |
excellent |
| 04:46.28 |
brlcad |
starseeker:
mini todo list for the mess in there... 1) copyright headers to all
files (sh/header.sh, you or indianlarry since it was proxy should
be fine), 2) standard footers, 3) no using namespace std;, 4)
headers are a mess (see HACKING) but at least need common.h first,
then system, then whatever else everywhere for portability, 5)
svn:ignore dir products (docs need that too), 6) indentation
(sh/indent.sh) |
| 04:50.05 |
starseeker |
brlcad:
sounds good - I'll hit it first thing tomorrow morning (will sleep
momentarily) |
| 04:50.38 |
starseeker |
sorry about
docs - been building out of dir too much and forgot the reorg wiped
out the old settings |
| 04:51.22 |
starseeker |
muchas
gracias :-) |
| 04:53.58 |
*** join/#brlcad Ralith_
(n=ralith@69.90.49.189) |
| 04:54.24 |
*** join/#brlcad kanzure
(i=bryan@dhcp-84-36.me.utexas.edu) |
| 06:39.57 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
| 06:40.48 |
*** join/#brlcad kanzure (i=bryan@dhcp-84-36.me.utexas.edu)
[NETSPLIT VICTIM] |
| 07:04.28 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 07:52.45 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
| 08:53.26 |
CIA-22 |
BRL-CAD:
03brlcad * r36350 10/brlcad/trunk/include/Makefile.am: vector.h was
renamed to dvec.h |
| 09:48.40 |
CIA-22 |
BRL-CAD:
03d_rossberg * r36351 10/brlcad/trunk/src/librt/ (4 files in 2
dirs): vector.h was renamed to dvec.h because of possible a
conflict with a STL header file name |
| 10:13.16 |
CIA-22 |
BRL-CAD:
03d_rossberg * r36352 10/brlcad/trunk/src/conv/obj-g.c: because of
MSVC compiler error: replaced c99 idiom with c89 compatible one
(all declarations have to be on top of a block) |
| 12:05.14 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 12:11.32 |
CIA-22 |
BRL-CAD:
03brlcad * r36353 10/brlcad/trunk/src/librt/brep_test.cpp: another
vector.h to dvec.h conversion |
| 13:32.11 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:44.40 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EE36.dip.t-dialin.net) |
| 13:50.23 |
CIA-22 |
BRL-CAD:
03brlcad * r36354 10/brlcad/trunk/src/util/Makefile.am: need to put
the source in extra dist manually if it's not compiled, just like
the others |
| 13:51.39 |
CIA-22 |
BRL-CAD:
03brlcad * r36355 10/brlcad/trunk/doc/docbook/Makefile.am: handful
of other files and one dir missing from the dist. nirt fig20,
authors xml, mged05 image, spec image dir, and manpage readme
missing. |
| 13:53.36 |
starseeker |
brlcad: ah,
thanks |
| 13:55.21 |
brlcad |
do you get a
slew of warnings in the step dir about "warning: ignoring old
commands for target"? |
| 13:55.33 |
starseeker |
yes |
| 13:55.44 |
starseeker |
on
Mac |
| 13:55.44 |
brlcad |
is that from
a clean checkout? |
| 13:55.46 |
starseeker |
not sure
about Linux |
| 13:55.50 |
starseeker |
I believe
so |
| 13:56.00 |
brlcad |
not one that
"upgraded" to having it enabled |
| 13:56.48 |
starseeker |
oh,
wait |
| 13:57.12 |
brlcad |
i think it's
the two variable rules causing it, but needs to be tested clean
first in case it's red herring |
| 13:57.14 |
starseeker |
I think I saw
those warnings only when conv/step was enabled |
| 13:58.04 |
starseeker |
does a quick svn status |
| 13:58.46 |
brlcad |
it's not how
it is now -- it's whether you had a plain checkout/build with it
already on, or if you reran autogen.sh at some point |
| 13:59.20 |
brlcad |
only way to
test clean is: sh autogen.sh && ./configure && make
distclean && sh autogen.sh && ./configure
--whatevers.... |
| 13:59.28 |
brlcad |
or just check
out clean again |
| 13:59.54 |
brlcad |
hits the road |
| 14:00.05 |
starseeker |
brlcad: I've
been doing part of that cleaning process, but not full - I was just
getting set up for a distcheck build so I'll give it a
go |
| 14:00.49 |
brlcad |
you only need
the double autogen/configure when you suspect its automake being
pissy .. which those double-rules could be |
| 14:01.03 |
brlcad |
course, that
${}: rule is screwy too |
| 14:01.49 |
brlcad |
that probably
needs to be changed, plus the other change, and hopefully we're
good to go with a few doc updates |
| 14:02.10 |
brlcad |
need to get
larry to document his change in TODO |
| 14:02.13 |
brlcad |
er
NEWS |
| 14:02.28 |
starseeker |
freudian slip
;-) |
| 14:02.47 |
brlcad |
not really,
TODO needs to be updated too :) |
| 14:03.26 |
starseeker |
wishes indianlarry had committed his recent work - merging in
any changes after I get done with indents and header/footers will
be hell |
| 14:03.44 |
starseeker |
oh, well -
burnt hand teaches best :-P |
| 14:05.32 |
*** join/#brlcad KingofCSU
(n=king@222.247.247.227) |
| 14:11.00 |
brlcad |
word of
caution that indent.sh results need to be visually
inspected |
| 14:11.10 |
brlcad |
particularly
if there are #ifdefs or namespaces |
| 14:11.44 |
brlcad |
easier if
there are headers/footers first as the footer will end up being
indented indicating there are extra braces |
| 14:37.11 |
starseeker |
hrm make[2]:
*** No rule to make target `html/specifications/en/images', needed
by `distdir' |
| 14:37.14 |
starseeker |
checks |
| 14:38.37 |
starseeker |
oh - brlcad,
the reason spec images weren't there yet is that there aren't any
(yet) |
| 14:43.04 |
starseeker |
the empty
directory was causing problems, iirc |
| 14:45.05 |
starseeker |
doesn't remember which ones |
| 14:56.54 |
starseeker |
deletes the spec images directory until
needed |
| 14:59.51 |
CIA-22 |
BRL-CAD:
03starseeker * r36356 10/brlcad/trunk/doc/docbook/ (Makefile.am
specifications/en/images/): Don't put an empty directory in the svn
repository - will re-enable this logic once there are actual
specification images. |
| 15:08.08 |
starseeker |
yeah, it's
overriding commands in step dir on a clean build |
| 15:13.08 |
CIA-22 |
BRL-CAD:
03starseeker * r36357 10/brlcad/trunk/src/conv/step/ (344 files):
Add footers to all step conv files that don't appear to be static
copies of NIST files - need to discuss what has to happen with the
NIST code with indianlarry in order to use the step libs in
src/otheer/step |
| 15:17.45 |
CIA-22 |
BRL-CAD:
03starseeker * r36358 10/brlcad/trunk/src/conv/step/
(STEPEntity.cpp STEPEntity.h STEPWrapper.cpp STEPWrapper.h): Get a
few more files that aren't NIST copies. |
| 15:57.10 |
starseeker |
hmm,
interesting: http://pastebin.bzflag.bz/m3e5e2b63 |
| 16:10.00 |
starseeker |
does Mac have
emmintrin.h I wonder... |
| 16:10.38 |
starseeker |
ok it
does... |
| 16:14.21 |
starseeker |
const double
*, that looks ok... |
| 16:39.48 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 17:23.48 |
``Erik |
ppc mac?
didja try building a universal binary? |
| 18:26.46 |
``Erik |
"The greeks
invented sex. Later, the italians invented it with
women." |
| 18:32.52 |
starseeker |
brlcad: yep,
you called it - the fpu implementation works |
| 18:39.54 |
brlcad |
you should
compmile on linux with fpu, then compare sse vs fpu |
| 18:40.22 |
starseeker |
wouldn't fpu
pretty much always be slower? |
| 18:40.31 |
starseeker |
shudders to think about raytracing |
| 18:42.00 |
CIA-22 |
BRL-CAD:
03starseeker * r36359 10/brlcad/trunk/src/conv/step/
(PullbackCurve.cpp PullbackCurve.h): Put headers on PullBackCurve
files |
| 18:51.27 |
CIA-22 |
BRL-CAD:
03starseeker * r36360 10/brlcad/trunk/src/conv/step/ (6 files):
Switch from using std namespace to explicitly prefixing with std::
(per brlcad's advice) |
| 18:59.28 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-093.wireless.sfu.ca) |
| 18:59.38 |
starseeker |
hey Ralith
:-) |
| 19:00.01 |
Ralith |
hullo |
| 19:00.07 |
starseeker |
how goes
it? |
| 19:00.28 |
Ralith |
much to my
dismay, univ involves work ;_; |
| 19:00.35 |
starseeker |
heh |
| 19:00.53 |
starseeker |
yeah, they do
like that |
| 19:01.17 |
Ralith |
at least it's
friday |
| 19:02.47 |
starseeker |
Ralith: do
you recall if we're using quaterniuns for rotation in ogre or is it
the yaw, pitch, etc. stuff? |
| 19:07.13 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-093.wireless.sfu.ca) |
| 19:08.31 |
Ralith |
and the wifi
sucks, to boot. |
| 19:14.07 |
starseeker |
distcheck
passes on Linux |
| 19:17.51 |
starseeker |
looks at the TODO file for items to do before next release
and winces |
| 19:25.48 |
Maloeran |
starseeker,
fpu can be faster if you are doing a lot of cos(), sin(), pow() and
other stuff that the SSE instructions won't do |
| 19:26.13 |
Maloeran |
Besides
that... stick to SSE of course :) |
| 19:40.14 |
``Erik |
I thought amd
had trig 'n shtuff built into theirs? just intel was r-tarded?
:) |
| 19:40.25 |
``Erik |
(mebbe needs
explicit 3dnow stuff) |
| 19:53.35 |
Maloeran |
There was no
trigonometry stuff in 3dnow either |
| 19:54.08 |
Maloeran |
But it had
horizontal instructions, the fun stuff that Intel took 7 years to
think about and they managed not to get it quite right
either |
| 19:56.07 |
Maloeran |
Go USD, a
recovery of 5% in just a week! |
| 19:56.19 |
Maloeran |
It's amazing
for such a major currency to be so unstable... |
| 20:07.33 |
*** join/#brlcad Ralith_
(n=ralith@d142-058-090-093.wireless.sfu.ca) |
| 20:13.58 |
brlcad |
starseeker:
no, the fpu is very often faster -- it depends on a lot of
factors |
| 20:14.07 |
brlcad |
how much work
you can keep feeding the pipeline |
| 20:14.48 |
brlcad |
there's a
cost to transfer data into and out of the simd
registers |
| 20:15.11 |
brlcad |
so that
cummulative overhead has to be recovered with enough computation
and minimal/no interruptions as much possible |
| 20:15.36 |
``Erik |
mal: what're
you talking about? CAD fluxes like mad, sure, but I'd hardly call
it a major ... :> *duck* |
| 20:35.32 |
starseeker |
makes notes on personal todo... email profont guys, benchmark
fpu vs sse, check out ttkdraw... |
| 20:37.11 |
Maloeran |
``Erik,
that's a good point! You can see it both ways... Either the USD is
fluctuating wildly, or it is stable but every other currency in the
world is! ;) |
| 20:38.10 |
Maloeran |
brlcad, cost
to puttign stuff in and out of the simd registers is about the same
as for the fpu |
| 20:38.50 |
Maloeran |
Technically,
older archs like Athlon64 were faster with fpu stuff ( a movss from
memory requires zeroing out the remaining 96 bits, so it was slower
), but recent chips like Core 2 crunch the SSE stuff
better |
| 20:39.40 |
Maloeran |
FPU requieres
the code to fxchg all the time to bring any value you want to work
on at the top of the stack, SSE lets you access any register
directly in a sane way |
| 20:40.28 |
brlcad |
not just the
load |
| 20:40.36 |
brlcad |
you still
have to wait for the pipeline to flush to get your
result |
| 20:40.46 |
brlcad |
that's part
of the "load" overhead if you can't fill it |
| 20:40.59 |
Maloeran |
The latency
and throughoutput of the SSE stuff is better for all recent chips,
as far as I know |
| 20:41.14 |
Maloeran |
If you
benchmark an Athlon64 or a Pentium 4, then it's a very different
story |
| 20:41.55 |
brlcad |
we tested
just two years ago and took a pretty big hit for incorrent
work |
| 20:42.32 |
brlcad |
thinks it was two, a xeon either way |
| 20:42.35 |
Maloeran |
Besides all
the "basic" instructions, you can do stuff like fmin(), fmax(),
fabs() without branching on SSE, it's a single
instruction |
| 20:42.52 |
Maloeran |
I guess it
was a Xeon based on the Pentium 4 arch |
| 20:43.57 |
brlcad |
well we have
a perfect way to test that theory on most chips with our vmath
interface |
| 20:44.22 |
Maloeran |
You can
eliminate a lot of branches if you begin doing bitwise stuff with
SSE, but that'll take some use of SSE intrinsics |
| 20:44.59 |
brlcad |
those are
pretty specific cases from what I'm talking about |
| 20:45.16 |
brlcad |
there are
lots of things sse/simd does way better |
| 20:45.19 |
brlcad |
otherwise
what'd be the point |
| 20:45.31 |
Maloeran |
*nods* Right,
I'm not too sure what your benchmark was doing of
course |
| 20:45.43 |
brlcad |
the general
commpute case though, isn't beneficial generally speaking
though |
| 20:46.25 |
Maloeran |
Well I would
be very surprised, I thought that was only right for chips of the
P4 or Athlon64 generation |
| 20:46.41 |
brlcad |
otherwise the
compiler could just do it for all math ops and we'd be good to go
-- some compilers can do it for sections of code where there is a
loop of ops that translate well, but still not for general
case |
| 20:47.04 |
Maloeran |
nods |
| 20:48.06 |
brlcad |
if you're
writing the algorithm fresh and can keep the pipeline filled, great
:) |
| 20:49.02 |
Maloeran |
I guess I'm a
bit biased, I write the code with a good idea in mind of what GCC
will output... when I'm not just using SSE intrinsics
directly |
| 20:49.03 |
brlcad |
the test case
we were using was a surface solver iirc |
| 20:51.10 |
brlcad |
the only
point I was making was that you can't just take something like a
simple single vector multiply, feed it to the simd unit, and expect
it to speed up |
| 20:52.25 |
Maloeran |
Right,
although the throughoutput should be higher with SSE on some very
recent chips |
| 20:52.42 |
Maloeran |
x87 is
getting rather deprecated |
| 20:52.44 |
``Erik |
be amusing to
twist vmath up with sse stuff to see what the difference is there,
though |
| 20:52.56 |
brlcad |
throughput
should be higher even on older ones |
| 20:53.20 |
brlcad |
if you have
more than random food for the pipeline, you can keep it busy and
get some gain |
| 20:53.38 |
brlcad |
that's just
not the general case unless you design for it |
| 20:53.54 |
brlcad |
``Erik: yeah,
jason actually did that with those vector headers in
include/ |
| 20:53.56 |
Maloeran |
You can keep
the x87 busy as well, the Athlon FX and Athlon 64 were doing very
intense register renaming under the hood from sequences of
fxchg |
| 20:54.06 |
brlcad |
not vmath
directly, but several of the same routines are
implemented |
| 20:54.12 |
brlcad |
which is what
he's using in the solver |
| 20:54.50 |
brlcad |
yeah, l1/l2
cache on the chip is just as important, but likewise you have to
plan for it |
| 20:55.03 |
brlcad |
keeping data
coherent and fit in cachelines doesn't just happen |
| 20:55.36 |
Maloeran |
I never wrote
any x87 assembly, tracking where your stuff is on the fpu stack
looks painful |
| 20:55.38 |
brlcad |
if you're
already coherent and fit, then yeah sure .. you'll translate pretty
simply to simd and can g et even more gains |
| 20:55.45 |
Maloeran |
nods |
| 20:56.43 |
brlcad |
totally would
love to see all our CSG prims have a coheret shot() routine with a
coherent boolean eval to leverage the same techniques that are used
for triangle tracing |
| 20:57.00 |
brlcad |
at least an
order of magnitude to be harvested there |
| 20:57.29 |
brlcad |
even with
lots of data validation branches remaining sprinkled
throughout |
| 20:57.42 |
Maloeran |
Sounds like
there are other things to worry about before getting into fpu
versus SSE :) |
| 20:58.11 |
brlcad |
everyone
likes faster tracing ;) |
| 20:58.18 |
brlcad |
that'd make a
great paper too |
| 20:58.39 |
Maloeran |
shivers at the mention of writing papers |
| 20:58.45 |
brlcad |
heh |
| 20:58.59 |
brlcad |
you shoulda
written one on rayforce at the time :) |
| 20:59.13 |
Maloeran |
It looks most
uninteresting to me, really |
| 20:59.19 |
brlcad |
think most
have caught up by now though too |
| 20:59.36 |
brlcad |
"most" being
ill-defined of course |
| 20:59.46 |
brlcad |
the top five
tracer impls |
| 20:59.51 |
Maloeran |
Perhaps, not
too sure if they are still stuck in their BSP ages, or other
tree-based techniques |
| 21:00.50 |
Maloeran |
I code for
fun really, I just hate the thought of reading or writing
papers |
| 21:06.13 |
Maloeran |
Such as this
rather fast "tricubic weighted b-splines" image filtering I just
wrote today for the CFD visualization... I tend to think it would
have been rather boring to just implement what some paper might
have said |
| 21:09.25 |
Maloeran |
( although if
the algorithm has an official name, I don't have a clue what it is
) |
| 21:10.42 |
``Erik |
damn you,
emacs |
| 21:17.33 |
brlcad |
you might get
joy/satisfaction just out of solving the problem, but I hate to
spend time solving a problem that has already been
solved |
| 21:17.47 |
brlcad |
there are
plenty of unsolved problems to resolve every problem that is simply
'new' to me |
| 21:17.59 |
brlcad |
to each their
own :) |
| 21:20.51 |
``Erik |
nice http://jalemanyf.files.wordpress.com/2008/05/microsoft-fail.jpg |
| 21:21.29 |
``Erik |
(look at the
laptop they're driving with) |
| 21:28.47 |
yukonbob |
heh |
| 21:38.33 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 22:28.10 |
starseeker |
``Erik: is
that legit or a photoshop job? |
| 22:28.43 |
``Erik |
dunno, had
the same thought myself |
| 22:34.22 |
Maloeran |
True brlcad,
I guess sometimes it just takes as long to understand what someone
else did and re-create it, than just create something yourself
:) |
| 22:34.59 |
Maloeran |
Eheh Erik,
nice one |
| 22:45.51 |
*** join/#brlcad IriX64
(n=Warlock@bas2-sudbury98-1177726213.dsl.bell.ca) |
| 22:46.05 |
brlcad |
Maloeran:
that's often true, but even if it's faster to figure it out myself,
to me that is still wasted effort as it builds on nothing but my
own experiences (which as impressive as they may be will never be
as much as everyone else currently and previously
alive) |
| 22:50.00 |
brlcad |
plus in my
fatalistic view, I'll be dead soon enough and everything I've
learned is moot, so there's value in knowing the things I've done
are actually 'improvements' in some regard as they build on those
before; for whatever qualification of 'better' (faster, easier,
more maintainable, foss-style free, innovative, new,
whatever) |
| 22:51.57 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 22:52.23 |
``Erik |
just like
exercise, you'll be dead soon enough, and any muscle you have will
just rot away, and there're other people with more muscle :D so
exercise would be pointless |
| 22:52.26 |
``Erik |
*duck* |
| 22:52.48 |
brlcad |
if muscle
were the goal, that would be completely true :) |
| 22:53.08 |
``Erik |
is getting ready to code up something overdone and useless
just to get the brain exercise from it :) |
| 22:53.48 |
``Erik |
provided, of
course, she decides to let me O.o cats seem to know that their
proper place is on the laptops keyboard. |
| 22:53.49 |
brlcad |
I do it for
the "drugs" .. the endorphin rushes, the runner's highs, the 'feel
good' and 'feel fantastic' times |
| 22:54.24 |
``Erik |
endorphines
trigger the opiate receptors, there're other ways to trigger those
:D not nearly as healthy, but easier and quicker |
| 22:54.26 |
brlcad |
makes me
happy, might as well enjoy my limited time here |
| 22:54.39 |
brlcad |
right |
| 22:54.56 |
``Erik |
or; bind to,
rather |
| 22:55.11 |
``Erik |
brain
chemistry is nutty stuff |
| 22:56.19 |
brlcad |
my way
doesn't actually endanger others (generally speaking), shorten my
lifespan (generally speaking), require interacting with nefarious
individuals, or make an impact on my ability to buy toys (which
also just make me happy) |
| 22:56.46 |
``Erik |
whoa, I don't
need to know about your "toys" there, dude |
| 22:57.05 |
brlcad |
my toys
rock |
| 22:57.12 |
brlcad |
:) |
| 22:57.48 |
``Erik |
speaking of,
I've been thinking about picking up the sheevaplugs bigger
brother |
| 22:58.11 |
yukonbob |
laughs about ``Erik going on about "toys" and
"plugs" |
| 22:58.39 |
brlcad |
sheep plugs?
ew |
| 22:58.56 |
``Erik |
sshoot, had
the url the other day |
| 22:59.17 |
``Erik |
yukonbob: I
thought you liked debian? O.o |
| 22:59.31 |
brlcad |
this thing?
http://www.treehugger.com/files/2009/02/marvell-sheevaplug-plug-pc-computer-wall-wart.php |
| 23:00.14 |
``Erik |
that's the
$100 wall wart version, there's a $250 one with loads more to
it |
| 23:00.25 |
yukonbob |
``Erik: /me
-used- to be a debian person, before I evolved to *BSD. |
| 23:00.58 |
``Erik |
ahhh, you saw
the light, hehehe |
| 23:00.58 |
``Erik |
the sheeva
stuff all comes with debian, I'm hoping to get fbsd going on
one |
| 23:01.22 |
louipc |
wow that's
awesome |
| 23:03.48 |
yukonbob |
as far a
Linux goes, debian seems sane to me. I'm inclinded to say same
about slack, but these days I only _read_ about it (infrequently).
Been ~14 years since I've _run_ it. |
| 23:06.34 |
``Erik |
http://www.globalscaletechnologies.com/p-24-openrd-client-openrd-client-board-with-enclosure.aspx |
| 23:06.37 |
``Erik |
there we
go |
| 23:06.52 |
``Erik |
hah, yowza,
that's quite a while :) |
| 23:06.57 |
``Erik |
I went to bsd
about 10 years ago |
| 23:09.06 |
yukonbob |
<- FreeBSD dabbling ~10 years ago, NetBSD permanently
since NetBSD 1.6 |
| 23:09.51 |
``Erik |
never tried
netbsd. fbsd is my bread&butter, done some obsd, and I've even
dug up old 43bsd and 44bsdlite for simh |
| 23:10.05 |
``Erik |
(I think the
43 used the 'tahoe' set) |
| 23:10.30 |
``Erik |
on a vax
780... was working on installing BRL-CAD 4.4 on it...
:D |
| 23:23.45 |
``Erik |
*snrkt*
http://www.collegehumor.com/picture:1923263
nice |
| 23:56.11 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
| 00:35.34 |
brlcad |
starseeker:
ah, msi .. those aren't installshield |
| 00:37.24 |
brlcad |
it'd have to
be a pretty fledged installer to surpass our nsis one, though ..
it's pretty swank with it's options, graphics, optional sections,
etc .. |
| 00:39.45 |
brlcad |
think the
issue is more bob ran into a bug and instead of figuring out the
problem, he'd rather play with something new |
| 00:41.06 |
brlcad |
the problem
just needs to have some earnest investigation put into it to see if
it's something wrong in our nsis file, an nsis bug, or a network
filesystem problem |
| 00:41.57 |
brlcad |
i took a
quick look at the nsis source code and the error he's getting is a
generic "file i/o" problem (which stupidly just assumingly reports
as disk full) |
| 00:43.15 |
brlcad |
would be
trivial to add some better debug statements in, recompile, see what
the real error is; or do the nsis on a diff (non-net-fs)
system |
| 00:44.57 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 01:35.58 |
starseeker |
brlcad: in
fairness to Bob, he never mentioned wix - I'm the one who went
looking |
| 01:36.10 |
starseeker |
Bob never
asked me to - I'm the guilty one |
| 01:37.23 |
starseeker |
:-P |
| 01:49.16 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 03:31.28 |
*** join/#brlcad schwinn434_
(n=schwinn4@75.81.202.25) |
| 03:31.28 |
*** join/#brlcad mafm
(n=mafm@217.Red-83-38-34.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 03:31.28 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 03:31.28 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 03:31.28 |
*** join/#brlcad yukonbob (i=1000@142.179.54.198) [NETSPLIT
VICTIM] |
| 03:31.31 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 03:31.31 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 03:31.32 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 03:31.32 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 03:56.08 |
starseeker |
wonders if virtualbox will finish compiling before Haiku
finishes downloading |
| 04:08.34 |
brlcad |
for those
that haven't seen fitz' and sussman's latest tech talk, it's pretty
good:
http://code.google.com/events/io/2009/sessions/MythGeniusProgrammer.html |
| 04:08.58 |
brlcad |
starseeker:
aha .. hm. |
| 04:25.14 |
starseeker |
compile
finished first :-) |
| 04:31.46 |
starseeker |
brlcad:
hadn't looked at installer development on Windows since last
InnoSetup vs. NSIS discussions - was curious if anything new had
appeared |
| 04:34.24 |
brlcad |
http://wix.sourceforge.net/ is
probably the other at a mature enough level, but with a steeper
learning curve |
| 04:52.09 |
starseeker |
installs Haiku into a virtualbox image |
| 04:52.17 |
brlcad |
woot |
| 04:52.50 |
brlcad |
starseeker:
you'll need to change the default network adapter in virtualbox for
haiku to use it |
| 04:53.10 |
brlcad |
there's a
page on their wiki about it, but basically the first intel one
iirc |
| 04:53.39 |
starseeker |
cool
:-) |
| 04:55.27 |
starseeker |
(install is
taking a little while on my now lame machine) |
| 04:59.32 |
starseeker |
tries to think if there have ever been any true genius
programmers... hmm... Knuth maybe? |
| 05:05.13 |
starseeker |
well, the
mouse moves ssssllllooww but I guess really I can't kick for full
virtualization on something this old |
| 05:08.37 |
starseeker |
hello from
Haiku! :-) |
| 05:09.15 |
starseeker |
that is
easily the easiest experience I have ever had getting networking
working in a virtual machine |
| 05:09.37 |
starseeker |
winces, remembering when bochs was all the
rage... |
| 05:10.39 |
starseeker |
that was
coool :-) |
| 05:11.02 |
starseeker |
must try out ReactOS... |
| 05:18.14 |
starseeker |
has an idea born of true and pure evil... use ReactOS +
msys/mingw to build a Windows install of BRL-CAD that never touched
Windows :-) |
| 05:18.45 |
starseeker |
Fortunately,
the toolchain almost certainly isn't up to anything so bats**t
insane |
| 05:20.13 |
brlcad |
slow mouse?
interesting.. mine was too fast default |
| 05:20.31 |
brlcad |
they don't
yet have accelleration dampening working well |
| 05:21.42 |
starseeker |
feels like
CPU cranking |
| 05:21.58 |
starseeker |
has an old dual P4 - may not be up to this kind of
action |
| 05:33.48 |
starseeker |
blinks - internet in ReactOS?? |
| 05:33.57 |
starseeker |
holy
smoke |
| 05:40.06 |
starseeker |
wonders how this sucker would respond to a movitz
image... |
| 05:44.26 |
brlcad |
don't forget
the mosix disc from the summit too ;) |
| 05:45.22 |
starseeker |
minix you
mean? ;-) |
| 05:45.28 |
brlcad |
er
yeah |
| 05:45.33 |
starseeker |
hasn't heard of mosix for a while now :-) |
| 05:46.21 |
starseeker |
downloads mingw and msys into ReactOS |
| 05:46.29 |
starseeker |
unreal... |
| 05:47.34 |
brlcad |
unreal
tournament? :) |
| 05:49.11 |
starseeker |
heh - could
try that too |
| 05:50.33 |
starseeker |
ah, phew -
msys isn't working right |
| 05:50.52 |
starseeker |
was afraid for a minute there he might actually have to
attempt a BRL-CAD compile |
| 05:54.25 |
brlcad |
heh |
| 06:01.46 |
starseeker |
hehe - it
will take the movitz floppy image |
| 06:10.56 |
starseeker |
ooo, how
could I forget AROS: http://aros.sourceforge.net/ |
| 06:12.45 |
starseeker |
pity about
their custom license |
| 06:24.25 |
starseeker |
mmm, freedos
- ah, the good old (or old anyway) 386 days |
| 06:35.40 |
CIA-37 |
BRL-CAD:
03brlcad * r36408 10/brlcad/trunk/src/libbu/vls.c: checkpoint.
further progress on encoding/decoding from string to argv and
back.. though there is still some wonkyness with quoted/escaped
words. continued work in progress. |
| 10:54.48 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 10:55.25 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14CDA8.dip.t-dialin.net) |
| 11:26.29 |
d-lo |
``Erik: lol,
I'm cryin here. It's like they quoted my dad's best sayings.
hahahahaha |
| 11:26.38 |
d-lo |
bah, now
that's strange. |
| 11:26.41 |
d-lo |
Mernin
all! |
| 12:12.35 |
brlcad |
mernin |
| 12:24.59 |
CIA-37 |
BRL-CAD:
03brlcad * r36409 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c):
revert back to 36317 removing the new encode/decode so raytracing
is unbroken and release prep can continue. the issues with
encode/decode can get sorted out post-release. |
| 12:25.43 |
CIA-37 |
BRL-CAD:
03brlcad * r36410 10/brlcad/trunk/TODO: test it, ship
it |
| 12:27.59 |
d-lo |
brlcad: You
been playing with Haiku recently eh? opinions? |
| 12:30.10 |
brlcad |
d-lo: been
following haiku since before they were called haiku |
| 12:30.58 |
brlcad |
i'm pretty
excited, actually -- they've had a surge of rapid progress ever
since they finally got self-hosting earlier this year |
| 12:31.59 |
brlcad |
a far ways
off from holding a stick to any modern distro, but Haiku's clean
heritage and architecture design is one of the best
imnshho |
| 12:33.35 |
brlcad |
starseeker:
at a glance, I'm not sure indianlarry's recent multiplicity change
is right.. that might be related to the eval problems |
| 12:37.06 |
brlcad |
opennurbs
doesn't store the repeat the start/end knots for surfaces/curves
for a given order, duplicating them internally implicitly during
eval -- it's not clear to me what r36364 is doing in that
regard |
| 13:16.03 |
CIA-37 |
BRL-CAD:
03brlcad * r36411 10/brlcad/trunk/src/mged/mged.c: apply a heavily
modified version of Jack Devanney's ( djw1 ) sf patch 2889987
(improvement to f_opendb) that should make mged not prompt for new
file creation if opendb is called with a y/n tail
argument. |
| 13:19.20 |
CIA-37 |
BRL-CAD:
03brlcad * r36412 10/brlcad/trunk/AUTHORS: special thanks to Jack
Devanney for his mged opendb patch, even if it didn't survive on
apply. he pinpointed the issue and provided a working patch
regardless. |
| 13:38.39 |
CIA-37 |
BRL-CAD:
03brlcad * r36413 10/brlcad/trunk/NEWS: |
| 13:38.41 |
CIA-37 |
BRL-CAD:
prompted by Jack Devanney's problem of adding 'opendb file y' to
.mgedrc and |
| 13:38.43 |
CIA-37 |
BRL-CAD:
having it still prompt, his patch and my refactoring have made
things better |
| 13:38.45 |
CIA-37 |
BRL-CAD:
where it should obey the [y/n] opendb tail regardless of which mode
mged is |
| 13:38.47 |
CIA-37 |
BRL-CAD:
running. |
| 13:56.58 |
CIA-37 |
BRL-CAD:
03brlcad * r36414 10/brlcad/trunk/NEWS: keith added a -n option to
the bot_dump command where it'll write out surface normals
(untested) |
| 14:01.06 |
CIA-37 |
BRL-CAD:
03brlcad * r36415 10/brlcad/trunk/NEWS: keith also made some
improvements to obj-g making it handle files that have texture and
surface normal data (by ignoring that data) |
| 14:04.13 |
CIA-37 |
BRL-CAD:
03brlcad * r36416 10/brlcad/trunk/NEWS: |
| 14:04.17 |
CIA-37 |
BRL-CAD: bob
implemented a new plugin in archer for displaying groups of
attributes and |
| 14:04.19 |
CIA-37 |
BRL-CAD:
showing/hiding objects associated with those attributes. shows up
an a graphical |
| 14:04.21 |
CIA-37 |
BRL-CAD:
panel with list boxes, object selection, and key bindings that
drive the |
| 14:04.23 |
CIA-37 |
BRL-CAD:
graphical window. |
| 14:05.36 |
brlcad |
that
completes my review items |
| 14:05.58 |
brlcad |
good for
someone(tm) to do cross-platform compile testing and sync to
STABLE |
| 14:10.14 |
someone |
heh |
| 14:14.24 |
brlcad |
hehe |
| 14:15.30 |
starseeker |
attempts to get his voice to sound a little less like a dying
frog... |
| 14:15.40 |
*** topic/#brlcad by louipc -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| Release 7.16.0 posted (20091006) || Logs at http://ibot.rikers.org/%23brlcad/ |
| 14:16.02 |
louipc |
7.16.0
:D |
| 14:16.20 |
louipc |
starseeker:
you got the flu? |
| 14:16.31 |
starseeker |
nah, just a
headcold |
| 14:16.43 |
louipc |
ah
alright |
| 14:17.00 |
starseeker |
running the
standard head, tonsils, body ache, coughing up crap
cycle |
| 14:17.12 |
louipc |
people are
going nuts over the flu and vaccinations here |
| 14:17.23 |
starseeker |
sometimes I
can ride 'em out, but this one was a bit of a doozie |
| 14:17.42 |
louipc |
new and
improved virus eh |
| 14:17.46 |
starseeker |
yea, I keep
getting asked if I've got the flu |
| 14:18.10 |
starseeker |
standard
response: shhh! digestion is the one thing I HAVEN'T had a problem
with yet! |
| 14:18.30 |
louipc |
hehe |
| 14:19.32 |
starseeker |
brlcad: did
indianlarry ever get a Windows build environment set
up? |
| 14:20.09 |
starseeker |
'twould be
nice if the Windows build stuff could be swatted |
| 14:20.48 |
starseeker |
iirc some of
'em had to do with recent changes to opennurbs_ext |
| 14:23.37 |
starseeker |
notes with some bemusement that the FreeDOS install takes
just as long as he remembers it taking years ago |
| 14:24.51 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 14:25.39 |
starseeker |
heh - watcom
c/c++ compiler - I'll bet that's one BRL-CAD has never
encountered |
| 14:26.57 |
brlcad |
not in at
least two decades probably |
| 14:31.30 |
``Erik |
headcold must
be going around, kept me out of the office yesterday, still
coughing and snotting a bit O.o |
| 14:34.11 |
starseeker |
yeah, Sarah
had it last week and folks at her place were down sick
too |
| 14:34.14 |
starseeker |
tiz the
season |
| 14:34.53 |
``Erik |
annoying,
anytime anyone coughs or sneezes, everyone goes "??? H1N1??
AAAHHHHH |
| 14:35.07 |
starseeker |
heh,
yep |
| 14:35.13 |
starseeker |
gets that too |
| 14:35.37 |
starseeker |
it's like
"No, but maybe I can find you some if you want it..." |
| 14:36.06 |
louipc |
this cold
going around must be the 'test' |
| 14:36.07 |
starseeker |
isn't this
the so called "swine flu" that we were all up in arms about last
goaround? |
| 14:36.29 |
starseeker |
thought H1N1 was the "official" name for that, but could be
wrong... |
| 14:36.33 |
``Erik |
yeah |
| 14:36.35 |
``Erik |
it
is |
| 14:36.57 |
``Erik |
(actually, if
I understand correctly, h1n1 is a family of flu virii, which 'swine
flu' belongs to?) |
| 14:37.02 |
*** join/#brlcad cosurg1
(n=cosurgi@atak.bl.pg.gda.pl) |
| 14:37.03 |
starseeker |
hmm, so we've
had world ending due to bird flu, world ending due to swine
flu... |
| 14:37.11 |
``Erik |
don't forget
sar |
| 14:37.13 |
``Erik |
sars |
| 14:37.25 |
starseeker |
was that
different from the bird flu? |
| 14:37.28 |
``Erik |
oh, and the
world ended from the swine flu in the 70's, so *shrug* it's all
good, right? |
| 14:37.39 |
``Erik |
I thought so?
*shrug* |
| 14:37.48 |
starseeker |
but nobody
expects... the Hampster Flu! |
| 14:38.14 |
``Erik |
shitloads of
media fearmongering for a story... 5000 people int he world have
died of swine flue this year, the "regular" flu kills
200,000-500,000 a year |
| 14:38.30 |
``Erik |
the spanish
flu killed many millions less than a century ago |
| 14:38.37 |
louipc |
yeah what the
hell is sars |
| 14:38.45 |
starseeker |
that's the
1918 one, right? |
| 14:38.51 |
``Erik |
yeh |
| 14:38.58 |
starseeker |
that WAS
scary. |
| 14:39.08 |
louipc |
haha sars is
a cold |
| 14:39.20 |
starseeker |
airborne,
most dangerous to healthy people, struck fast and hard |
| 14:40.13 |
starseeker |
'course,
sanitation practices in 1918 still left something to be desired,
and the world WAS recovering from a very bloody war. |
| 14:40.15 |
louipc |
it's less
dangerous to sick people? |
| 14:40.23 |
louipc |
o.O |
| 14:41.01 |
starseeker |
iirc, the
theory about the spanish flu was that the immune response it
provoked in healthy people was so strong as to be dangerous,
whereas those with weakened immune systems couldn't damage
themselves as much |
| 14:41.26 |
starseeker |
something
about an immune system "storm", but it's been a while since I saw
anything about it and I'm no expert <shurg> |
| 14:42.47 |
starseeker |
oh: cytokine
storm (overreaction of the body's immune system) |
| 14:44.22 |
louipc |
oh kinda like
playing an old video game on a faster machine |
| 14:49.22 |
*** join/#brlcad mafm
(n=mafm@217.Red-83-38-34.dynamicIP.rima-tde.net) |
| 15:01.03 |
starseeker |
hmm. I'll
bet if any OS does well with VirtualBox it would be
opensolaris.... |
| 15:44.51 |
*** join/#brlcad mafm
(n=mafm@217.Red-83-38-34.dynamicIP.rima-tde.net) |
| 17:04.04 |
starseeker |
decides his head isn't going to fall off and heads
in... |
| 17:58.03 |
``Erik |
gonna have to
leave my laptop in a room with a closed door O.o one of the cats
closed it. |
| 18:39.59 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 18:48.01 |
starseeker |
``Erik: the
cats are stealing your laptop? O.o |
| 18:49.22 |
starseeker |
ours would
probably consider it a warm place to sleep... |
| 18:54.53 |
``Erik |
well, I
closed the lid down so there was like 2 inches between the top and
base, so it'd stay running... was ssh'd in and compiling BRL-CAD on
it and it stopped pinging. I assume that means the noise and heat
got someones interest and it became a seat |
| 18:55.08 |
starseeker |
hehe |
| 19:04.49 |
starseeker |
ooo, glad I'm
not in Montgomery County |
| 19:05.05 |
starseeker |
traffic
control computer crashes, nothing moves... |
| 19:09.50 |
yukonbob |
``Erik: you
need a USB electric fence for it. |
| 19:10.13 |
yukonbob |
Universal
Shock Bus? |
| 19:14.38 |
starseeker |
hey, this is
kinda cool: http://sumo.sourceforge.net/ |
| 19:16.31 |
starseeker |
http://elib.dlr.de/21012/2/dkrajzew_TRAF9_AgentbasedTLS.pdf |
| 19:17.57 |
yukonbob |
3/win
3 |
| 19:18.14 |
starseeker |
yukonbob:
hmm? |
| 19:18.32 |
yukonbob |
<--- fail. ww. |
| 19:19.32 |
starseeker |
is now going to be compelled to play with this traffic
simulation program and waste more brain cells
:-) |
| 19:19.54 |
starseeker |
real fun -
integrate openstreetmap data into simulations |
| 19:20.18 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 19:22.16 |
``Erik |
actually,
been tempted to get some motion detectors and wiring them into
spritzers as deterrents, just concerned about water+electronics
:/ |
| 19:23.13 |
``Erik |
was looking
at air freshners and saw some that claimed to be motion activated,
hrmmmmm |
| 19:23.49 |
``Erik |
wiggles his toes and continues to wait for http://www.stargateworlds.com/ |
| 19:36.32 |
starseeker |
hmm - open
source Air Traffic Controller environment:
http://www.albatross.aero/projects/projects-list/project-details.php?p=NA==&s=TGVhcm5Nb3Jl |
| 19:41.18 |
starseeker |
ah, phooy -
project members only |
| 20:13.06 |
*** join/#brlcad b0ef
(n=b0ef@157.26.202.84.customer.cdi.no) |
| 21:07.24 |
CIA-37 |
BRL-CAD:
03erikgreenwald * r36417
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: crude
timing test for metaball tesselation. |
| 21:07.35 |
``Erik |
takes a moment to laugh evilly. |
| 21:07.40 |
brlcad |
heh |
| 21:10.58 |
``Erik |
(feel free to
comment on the tolerance bit) |
| 21:11.10 |
``Erik |
(as for the
rest; shove it. :D ) |
| 21:14.15 |
``Erik |
subversion
applied to become an apache foundation project |
| 21:14.27 |
brlcad |
neat |
| 21:14.41 |
brlcad |
is the
tolerance dynamic? |
| 21:14.57 |
``Erik |
it's whatever
is passed in |
| 21:14.59 |
brlcad |
then it sucks
;) |
| 21:15.11 |
``Erik |
looks for the
max of the two rt tols' and the bn tol dist |
| 21:15.40 |
``Erik |
and uses that
value as the grid size |
| 21:22.31 |
CIA-37 |
BRL-CAD:
03indianlarry * r36418
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 21:22.31 |
CIA-37 |
BRL-CAD:
Added buffer around UV pushback for loose fitting edges may not
need if we can |
| 21:22.32 |
CIA-37 |
BRL-CAD:
tighten the 3D edge to shared surface. |
| 21:24.36 |
CIA-37 |
BRL-CAD:
03indianlarry * r36419 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/opennurbs_ext.cpp): (log message trimmed) |
| 21:24.39 |
CIA-37 |
BRL-CAD:
Added tolerance argument to getSurfacePoint(), added quick return
if |
| 21:24.41 |
CIA-37 |
BRL-CAD:
point found within BREP_SAME_POINT_TOLERANCE, else now
iterates |
| 21:24.45 |
CIA-37 |
BRL-CAD:
through looking for closest point within tolerance argument.
Also |
| 21:24.47 |
CIA-37 |
BRL-CAD:
added BREP_EDGE_MISS_TOLERANCE buffer around 3D bounding box to
make |
| 21:24.52 |
CIA-37 |
BRL-CAD: sure
3D edges fall within bounding boxes (needed when
generating |
| 21:24.58 |
CIA-37 |
BRL-CAD:
pullbacks on loose edges).Also moved BREP_EDGE_MISS_TOLERANCE
and |
| 21:25.33 |
CIA-37 |
BRL-CAD:
03indianlarry * r36420 10/brlcad/trunk/include/brep.h: |
| 21:25.37 |
CIA-37 |
BRL-CAD:
Moved BREP_EDGE_MISS_TOLERANCE and BREP_SAME_POINT_TOLERANCE
definitions |
| 21:25.39 |
CIA-37 |
BRL-CAD: to
opennurbs_ext.h |
| 21:27.16 |
brlcad |
``Erik: ahh..
pretty sure you just broke the build on windows |
| 21:27.34 |
brlcad |
instead of
calling gettimeofday/clock directly.. how about just
rt_get_timer? |
| 21:27.48 |
brlcad |
wraps those
some routines portably |
| 21:41.41 |
CIA-37 |
BRL-CAD:
03erikgreenwald * r36421
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: use
rt_{prep,get}_timer() instead of gettimeofday for
portability |
| 21:41.45 |
``Erik |
"for those
users of lesser os's" |
| 22:04.03 |
CIA-37 |
BRL-CAD:
03erikgreenwald * r36422
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: attempt
to do something almost kinda sane with relative
tolerance? |
| 22:13.25 |
CIA-37 |
BRL-CAD:
03indianlarry * r36423 10/brlcad/trunk/src/conv/step/ (9
files): |
| 22:13.29 |
CIA-37 |
BRL-CAD:
Cleaned up and removed some debugging/dead code from pullback
routines, added |
| 22:13.33 |
CIA-37 |
BRL-CAD: some
developmental routines as initial start to edge
tightening |
| 23:21.20 |
Ralith |
hm |
| 23:21.21 |
Ralith |
hey
guys |
| 23:21.39 |
Ralith |
there was
someone here a while back that I talked into tutorialifying an
impeller he modelled to learn mged |
| 23:21.45 |
Ralith |
did that ever
get finished? |
| 00:23.37 |
*** join/#brlcad Cazax
(n=Cazax@unaffiliated/cazax) |
| 00:39.25 |
*** part/#brlcad Cazax
(n=Cazax@unaffiliated/cazax) |
| 01:14.50 |
R0b0t1 |
Hey, anyone
there? |
| 01:15.02 |
R0b0t1 |
I'm having
problems compiling brlcad from source on my ubuntu |
| 01:15.14 |
R0b0t1 |
It says
libz.la doesn't exist... |
| 01:15.24 |
R0b0t1 |
But it should
be in the archived directory I unzipped. |
| 01:26.06 |
``Erik |
when you ran
./configure, did it say it was going to use the system zlib, or try
to build it? |
| 01:29.06 |
R0b0t1 |
``Erik: It
says "no: Using system" |
| 01:29.18 |
R0b0t1 |
Although, it
says a surprising number of things I have installed are
missing |
| 01:29.25 |
R0b0t1 |
For extra
features, hm |
| 01:35.58 |
``Erik |
then libz.la
shouldn't be looked for at all, it should do -lz to pick up the .so
file O.o where does it break? |
| 01:36.33 |
``Erik |
http://pastebin.bzflag.bz/ if you
want to paste teh chunk leading up to the error? |
| 01:37.33 |
R0b0t1 |
http://pastebin.com/m5f5e4afd |
| 01:37.44 |
R0b0t1 |
loves bzflag, but already had a pastebin window
open |
| 01:41.53 |
``Erik |
bzflag.bz ==
brlcad.org :) |
| 01:42.18 |
``Erik |
just haven't
coerced brlcad into making the paste.brlcad.org work yet...
O.o |
| 01:43.17 |
``Erik |
hm, so the
output at the end of configure said it was going to compile tcl and
tk, but use the system libz and libpng? |
| 01:43.42 |
``Erik |
(and...
7.8.4? where did you get that?) |
| 01:44.08 |
``Erik |
and 7.12.2?
something's seriously screwed up there heh |
| 01:44.43 |
``Erik |
it'd be best
to grab 7.16.0 from sourceforge |
| 01:46.41 |
R0b0t1 |
Hmm |
| 01:46.49 |
R0b0t1 |
I thought I
was getting the newest one, :P |
| 01:49.24 |
``Erik |
http://sf.net/projects/brlcad/files/BRL-CAD%20Source/7.16.0/ |
| 02:00.24 |
R0b0t1 |
Damn. That's
a lot of warnings. |
| 02:01.22 |
``Erik |
? |
| 02:01.22 |
Maloeran |
Building
stuff on Ubuntu is rather annoying, you have to install all these
little "dev" packages just to get header files and static
libraries |
| 02:01.35 |
brlcad |
where is it
in the compile? some portions arent ours to quell |
| 02:01.44 |
``Erik |
src/other
specifically |
| 02:03.06 |
Maloeran |
I really
don't understand why the package maintainer felt they should
provide separate "-dev" packages to allow actual compilation of
software using the libraries |
| 02:03.18 |
Maloeran |
The 5kb .h
file was just too heavy? Ah gez |
| 02:03.28 |
Maloeran |
package
maintainers* |
| 02:03.29 |
``Erik |
heh |
| 02:03.32 |
``Erik |
pets fbsd O:-) |
| 02:03.37 |
R0b0t1 |
Ewww |
| 02:03.39 |
R0b0t1 |
Go
gentoo. |
| 02:03.49 |
R0b0t1 |
Oh, nothing
is fatal yet. Just... lots of warnings... :P |
| 02:05.20 |
Maloeran |
Gentoo is
great, just don't ever try to do a major update once it's installed
and running :) |
| 02:05.47 |
``Erik |
pets his fbsd boxen that do major updates without sweating it
:) |
| 02:07.08 |
Maloeran |
Yes, the
Gentoo crowd kind of messed up the convenience of a software
packaging system |
| 02:07.54 |
``Erik |
they made a
halfassed attempt to copy the bsd one and ended up with typical
linux quality... :> *duck* |
| 02:07.57 |
Maloeran |
I don't want
to have to modify obscure symlinks to update my "profile", or
modify some files to force the system to install a package it
decided I didn't want |
| 02:08.52 |
``Erik |
(no one
fighting? darn.) |
| 02:09.11 |
Maloeran |
"This package
is masked!" .... "Now go figure out what that means and how to
bypass my database, because I'm a stubborn packaging system and I
don't care about what you think you need." |
| 02:09.40 |
R0b0t1 |
Ello, new
error: http://pastebin.com/m2a2e5ac3 |
| 02:10.04 |
R0b0t1 |
wat |
| 02:10.16 |
R0b0t1 |
how is emerge
--keep-going world obscure |
| 02:10.26 |
Maloeran |
Sorry, 4
years of Gentoo have taken their toll on me |
| 02:10.53 |
Maloeran |
--keep-going
will not install a masked package |
| 02:11.06 |
R0b0t1 |
Oh, well
yeah. |
| 02:11.10 |
``Erik |
that error
says that your xslt/libxml2 stuff is broken |
| 02:11.41 |
``Erik |
looks like a
64 vs 32 bit issue? |
| 02:11.46 |
R0b0t1 |
Perhaps |
| 02:11.48 |
R0b0t1 |
I am on
64bit |
| 02:12.06 |
R0b0t1 |
And I borked
my synaptic because someone turned my comp of while
upgrading. |
| 02:12.15 |
R0b0t1 |
Dunno if
that's it, though. |
| 02:12.20 |
R0b0t1 |
Anything you
could think of I could try? |
| 02:12.29 |
``Erik |
http://ubuntuforums.org/showthread.php?t=610789 |
| 02:12.55 |
R0b0t1 |
Wait,
what |
| 02:13.09 |
``Erik |
https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/151045 |
| 02:14.23 |
``Erik |
http://www.mail-archive.com/sage-devel@googlegroups.com/msg10281.html |
| 02:14.30 |
``Erik |
(amusingly, I
went to school with jason grout) |
| 02:15.08 |
Maloeran |
Apparently
you got to remove some /usr/local/lib/libz* and
reinstall |
| 02:15.18 |
R0b0t1 |
has no /usr/local/lib |
| 02:15.31 |
R0b0t1 |
Well,
hmm |
| 02:15.36 |
``Erik |
it's a "your
libz and libxml2 don't match up right" issue |
| 02:15.36 |
R0b0t1 |
It says to
remove older versions |
| 02:15.53 |
Maloeran |
As it should
be, Ubuntu doesn't install anything in /usr/local, some people may
manually install stuff there and it generates library
conflicts... |
| 02:16.55 |
Maloeran |
Check what
you got in LD_LIBRARY_PATH, for any strange path |
| 02:17.15 |
R0b0t1 |
Looks
normal |
| 02:17.16 |
Maloeran |
Software
installed from different sources may modify that path and install
libraries in other locations |
| 02:17.41 |
``Erik |
mebbe try
reinstalling libz and libxml2? *shrug* |
| 02:17.43 |
R0b0t1 |
Ah, hm, I see
a way to continue my upgrade from where it was terminated. I'll
finish that and perhaps come back, I would assume that would fix
it. |
| 02:18.15 |
R0b0t1 |
Thanks for
your help :). I think it's some deeper-level error though, not
really easily fixable at all. |
| 02:18.34 |
``Erik |
really? on
fbsd, it'd just be "portmanager -u -bu -l" and go have
cookies |
| 02:18.37 |
``Erik |
:D
*duck* |
| 02:18.44 |
R0b0t1 |
Ta, off to
install gentoo on my slimclient (with only usb ports and svideo...
had to plug the SATA into another comp) |
| 02:18.45 |
Maloeran |
Eh, doesn't
sound like such a big error to me... |
| 02:18.55 |
R0b0t1 |
Well, big as
in, weird. |
| 02:19.30 |
``Erik |
isn't ther
ean "emerge --do-everything-that-was-supposed-to-happen-but-didnt"?
:) |
| 02:19.39 |
R0b0t1 |
Yeah, or
something like it. |
| 02:19.49 |
R0b0t1 |
Well, but I
mean, it doesn't really break anything completely. |
| 02:20.00 |
``Erik |
looks at the gentoo manpage at http://funroll-loops.info/ |
| 02:20.02 |
R0b0t1 |
But something
you linked me to, ``Erik, gave me the solution. |
| 02:20.18 |
``Erik |
O:-) |
| 02:21.12 |
Maloeran |
Gentoo is
weird really. It tries to be very user-friendly in preventing you
of doing "bad" stuff like installing packages it decided you didn't
need... but it requires one to modify obscure symlinks and files at
random occasions |
| 02:21.56 |
Maloeran |
As if they
only managed to get the bad part at trying to be
user-friendly |
| 02:22.54 |
R0b0t1 |
Meh |
| 02:23.05 |
R0b0t1 |
There's times
where everything needs a "shut up and listen" button. |
| 02:23.20 |
R0b0t1 |
I've
personally gotten REALLY tired of some software not listening
:p |
| 02:24.04 |
Maloeran |
Yes, I have
developed a... special and strangely emotional relationship with
Gentoo's emerge |
| 02:24.09 |
Maloeran |
And it isn't
going too well |
| 02:29.22 |
starseeker |
brlcad: do I
need to update the ChangeLog again? |
| 02:29.45 |
R0b0t1 |
Haha! |
| 02:29.47 |
R0b0t1 |
That fixed
it. |
| 02:29.57 |
R0b0t1 |
It was a
relic causing trouble from my interrupted upgrade. |
| 02:35.16 |
R0b0t1 |
Really quick
question. |
| 02:35.19 |
R0b0t1 |
How do I run
brlcad. |
| 02:35.59 |
``Erik |
um, there're
over 400 programs |
| 02:36.05 |
``Erik |
the one most
people are looking for is "mged" |
| 02:36.33 |
``Erik |
http://brlcad.org/wiki/Documentation |
| 02:38.01 |
R0b0t1 |
Hmm |
| 02:38.39 |
R0b0t1 |
Bummer,
thought it'd have a GUI :p |
| 02:38.42 |
R0b0t1 |
reads the docs |
| 02:38.58 |
``Erik |
mged is the
"gui" |
| 02:40.16 |
R0b0t1 |
I'd be
calling it more of a CLI. |
| 02:40.44 |
R0b0t1 |
Ruh-roh,
unable to initialize gui |
| 02:44.06 |
R0b0t1 |
``Erik: Heh,
got a few more minutes? |
| 02:44.09 |
``Erik |
? |
| 02:45.55 |
R0b0t1 |
mged starts
with |
| 02:45.55 |
R0b0t1 |
MGED unable
to initialize gui, reverting to classic mode. |
| 02:45.55 |
R0b0t1 |
attach
(nu|X|ogl)[nu]? |
| 02:46.17 |
R0b0t1 |
:-\, and no
matter which option I choose, only provides a CLI |
| 02:47.11 |
``Erik |
hrm, classic
mode is a command line interface with a display window (X would be
the one you want) |
| 02:47.19 |
``Erik |
if it's doing
that, it means your tk isn't quite right |
| 02:47.41 |
``Erik |
perhaps try
rebuilding BRL-CAD, this time using ./configure --enable-all
--enable-optimized |
| 02:47.43 |
R0b0t1 |
tk? |
| 02:47.52 |
``Erik |
yeah, tcl/tk
is how the gui is done |
| 02:47.53 |
R0b0t1 |
ok, then
:) |
| 02:48.44 |
starseeker |
Maloeran: I
find once I get /etc/make.conf, /etc/package.mask,
/etc/package.unmask, and /etc/package.use set properly it helps a
lot |
| 02:49.05 |
starseeker |
usually
tossing something in one of those 4 files handles
things |
| 02:50.31 |
brlcad |
starseeker:
nah, it's close enough |
| 02:50.37 |
R0b0t1 |
http://pastebin.com/m51a51776 |
| 02:50.40 |
R0b0t1 |
Another error
:0 |
| 02:50.57 |
brlcad |
hm, that'd be
an interesting system to debug.. enough tk to link, but not
configured properly to initialize |
| 02:51.01 |
R0b0t1 |
But it's in
other, I think I remember something about ignoring those
:) |
| 02:51.18 |
brlcad |
yeah, add
--disable-jove |
| 02:51.23 |
brlcad |
you don't
want it anyways |
| 02:51.37 |
R0b0t1 |
Hm,
really? |
| 02:51.42 |
brlcad |
that build
issue is fixed in svn head |
| 02:51.47 |
R0b0t1 |
Oh, I
see. |
| 02:52.22 |
R0b0t1 |
wonders what jove did anyway |
| 02:52.29 |
``Erik |
a really
shitty old emacs clone |
| 02:53.12 |
``Erik |
I mean, uh,
"jonathons own version of emacs" |
| 02:54.55 |
R0b0t1 |
(XD) |
| 02:55.09 |
R0b0t1 |
I ran the new
./config line, but I still have problems. |
| 02:56.01 |
``Erik |
bites his tongue O:-) |
| 02:56.11 |
R0b0t1 |
... the same
problem |
| 02:56.12 |
R0b0t1 |
:p |
| 02:56.20 |
R0b0t1 |
I added
disable-joves though |
| 02:56.53 |
``Erik |
--disable-jove, not --disable-joves...
O.o |
| 02:56.56 |
R0b0t1 |
It provides
me no GUI |
| 02:57.13 |
``Erik |
ah, you mean
it installed with --enable-all and still has the 'unable to
initialize tk' error? |
| 02:57.20 |
R0b0t1 |
I did it
right on my ./configure, whooops. |
| 02:57.27 |
brlcad |
you have to
"make clean" after reconfiguring |
| 02:57.29 |
R0b0t1 |
``Erik:
Yeah... |
| 02:57.30 |
R0b0t1 |
Oh |
| 02:57.31 |
R0b0t1 |
Heh |
| 02:57.33 |
brlcad |
and then
rebuild |
| 02:57.56 |
starseeker |
glares at 3Dconnexion - how the heck can you "license" a
device for professional use? |
| 02:58.26 |
``Erik |
sips the beer he licensed O.o |
| 02:59.04 |
``Erik |
(it's all
good, I'll be done with it in a couple hours and delete my, uh,
copy O.o) |
| 02:59.22 |
starseeker |
SpaceNavigator is awesome, but that makes
me very wary of them |
| 02:59.45 |
``Erik |
hrm, you
weren't wary when you saw "a logitech company"? O:-) |
| 03:00.10 |
starseeker |
I mean,
increased support sure, but do they claim that you CAN'T use the
device, even unsupported, for commercial activities? |
| 03:00.27 |
R0b0t1 |
It's only
cheating if you get caught. |
| 03:00.43 |
``Erik |
imagines it would be a very short court
case |
| 03:00.51 |
starseeker |
no
kidding |
| 03:01.15 |
starseeker |
I thought the
rule with hardware was still "I bought it, it's mine
now" |
| 03:01.35 |
starseeker |
unless
3Dconnexion thinks they're "renting" the things... |
| 03:02.00 |
starseeker |
https://3dconnexionstore.com/itemDetail.asp?itmNo=77826423N |
| 03:02.12 |
starseeker |
"allows for
commercial use..." WTF? |
| 03:02.13 |
``Erik |
they're a
corporation, they're gonna keep pushing the limits until they get
smacked down... I mean, just look at
http://news.slashdot.org/story/09/11/06/1639252/Cable-Exec-Suggests-Changing-Consumer-Behavior-Not-Business-Model?art_pos=9&art_pos=9 |
| 03:02.47 |
starseeker |
wonders if they mean "allows" in the sense of "makes possible
due to having proper support" |
| 03:02.49 |
R0b0t1 |
The
fuck |
| 03:02.51 |
R0b0t1 |
That is
weird. |
| 03:03.22 |
``Erik |
be amusing to
throw that link on hn or something to see the geek riot |
| 03:03.51 |
R0b0t1 |
The world
needs more extremists... Because they're the only people who seem
to get things done. |
| 03:04.06 |
``Erik |
heh |
| 03:04.09 |
starseeker |
if they mean
that in the "thou shalt not do anything commercial with this
hardware without a proper license" my motivation to write up
BRL-CAD support for it goes byebye |
| 03:04.28 |
``Erik |
send it to
rms, he'll show up at logitech hq, steal the food off their plates
and emit body odors :D *duck* |
| 03:07.09 |
starseeker |
considers emailing 3D for clarification... wonder if they'd
respond or not |
| 03:07.49 |
starseeker |
yay, a
working merge |
| 03:07.54 |
starseeker |
now, one
final distcheck |
| 03:09.53 |
``Erik |
http://www.motivatedphotos.com/?id=14566
heh |
| 03:11.19 |
``Erik |
zomfg O.O
http://tinyurl.com/6d7xo4 I
need one |
| 03:11.50 |
starseeker |
``Erik: heh -
that first one could be a Despair poster |
| 03:12.04 |
brlcad |
more than
likely, commercial use just invalidates support, software driver
updates, liability, .. you're on your own |
| 03:12.17 |
``Erik |
notes that starseeker hasn't poked around motivatedphotso
much |
| 03:12.43 |
starseeker |
brlcad: yeah,
that's what I figured - they word it very badly though |
| 03:13.00 |
brlcad |
more likely,
just a way to milk a little more money because businesses will have
to get the more expensive one |
| 03:13.27 |
``Erik |
still seems
low trying to constrain use like that |
| 03:20.23 |
starseeker |
brlcad: hmm -
I doubt their SDK license is compatible - does that mean we're
looking at reverse engineering it? |
| 03:20.43 |
starseeker |
http://www.3dconnexion.com/support/4h.php |
| 03:23.13 |
R0b0t1 |
*sigh* |
| 03:23.30 |
R0b0t1 |
I still get
"MGED unable to initialize gui, reverting to classic
mode." |
| 03:23.34 |
R0b0t1 |
Anything else
I could try? |
| 03:23.50 |
brlcad |
?ot |
| 03:24.01 |
brlcad |
starseeker:
it's not unlike the pro/e and unigraphics plugins |
| 03:24.23 |
brlcad |
we're not
redistributing the sdk |
| 03:24.58 |
starseeker |
ah - so we
don't have to have it present in BRL-CAD to make use of the
device? |
| 03:26.15 |
starseeker |
(since this
device is available for <$100 even in the worst case, it would
be nice to have everything needed to use it with BRL-CAD already in
BRL-CAD...) |
| 03:26.19 |
brlcad |
those terms
would apply to the dev compiling and their use of the sdk -- our
code remains ours |
| 03:26.34 |
brlcad |
everything is
pretty much already in brl-cad |
| 03:27.02 |
brlcad |
there are
bindings for those 6-dof already, at least event-wise |
| 03:27.28 |
brlcad |
could even
pass them through as key-bindings and use their simple gui control
panel to emulate key stokes |
| 03:28.57 |
brlcad |
R0b0t1:
really? that's an a clean installed enable-all build?? find that
hard to believe |
| 03:29.14 |
brlcad |
unless you
dont' have X running or something |
| 03:29.25 |
R0b0t1 |
Hmm |
| 03:29.27 |
R0b0t1 |
YEah. |
| 03:29.34 |
R0b0t1 |
Pretty sure I
have X running. :p |
| 03:30.02 |
R0b0t1 |
brlcad: Yeah,
it's all of what you said. |
| 03:30.02 |
R0b0t1 |
:S |
| 03:31.23 |
brlcad |
if you run
fbhelp, what does it output? |
| 03:31.32 |
brlcad |
and does it
flash a window |
| 03:31.53 |
brlcad |
er, display a
window |
| 03:32.13 |
brlcad |
pastebin the
fbhelp output |
| 03:32.21 |
brlcad |
~bzpaste |
| 03:32.22 |
ibot |
hmm...
bzpaste is http://pastebin.bzflag.bz/ |
| 03:32.25 |
brlcad |
there |
| 03:32.32 |
brlcad |
(the .com
sucks) |
| 03:33.18 |
``Erik |
*cough* make
paste.brlcad.org work *cough* O:-) |
| 03:33.42 |
brlcad |
somebody hear
something? |
| 03:33.48 |
brlcad |
hm, must have
been the wind |
| 03:33.50 |
``Erik |
wonders if bwish would be a good trial |
| 03:34.22 |
``Erik |
ponders saving wind up all weekend for brlcad's office O.o
nahhh, coudln't do that to d-lo |
| 03:34.35 |
brlcad |
bwish was
next .. wanted to see what was compiled first, and verify that X is
working first |
| 03:34.53 |
brlcad |
right, you
totally could/would do that to d-lo |
| 03:35.22 |
``Erik |
ok, I
couldn't do that to my hiney. O.o |
| 03:35.53 |
R0b0t1 |
brlcad:
Sorry |
| 03:35.57 |
R0b0t1 |
And yes, a
window appears. |
| 03:36.29 |
R0b0t1 |
brlcad:
http://pastebin.com/m4cbd8971 |
| 03:37.40 |
starseeker |
RObOt1: use
pastebin.bzflag.bz |
| 03:39.07 |
R0b0t1 |
http://pastebin.bzflag.bz/m50e8a7f |
| 03:40.24 |
brlcad |
hm, you
enabled ogl |
| 03:40.32 |
brlcad |
so next up,
run bwish |
| 03:40.48 |
``Erik |
ogl shouldn't
interfer with tk, though |
| 03:40.52 |
brlcad |
does it
display a window? |
| 03:41.20 |
brlcad |
the embedded
dm-ogl might be having trouble initializing if he's got a crap
card/config/combo |
| 03:43.18 |
R0b0t1 |
Aha |
| 03:43.22 |
R0b0t1 |
I might have
to install tcl |
| 03:43.39 |
brlcad |
heh, I asked
if you installed :) |
| 03:43.48 |
R0b0t1 |
Hmm |
| 03:43.52 |
R0b0t1 |
It is
installed, as I thought. |
| 03:44.18 |
brlcad |
are you
running the installed binary or the in-dir compiled
binary? |
| 03:44.27 |
R0b0t1 |
Says
something about not finding ./tcl8.5.1/library/init.tcl |
| 03:44.32 |
R0b0t1 |
installed |
| 03:45.20 |
starseeker |
that's not
the version we have in any recent tarball |
| 03:45.50 |
brlcad |
yeah, that's
not ours |
| 03:45.51 |
R0b0t1 |
Eh |
| 03:45.55 |
starseeker |
maybe a
distclean + ./configure --enable-all ? |
| 03:46.40 |
brlcad |
or even
starting over with a fresh checkout/download and
build/install |
| 03:46.44 |
R0b0t1 |
No rule to
make distclean? |
| 03:46.50 |
brlcad |
sounds like
you got something stale |
| 03:47.06 |
starseeker |
R0b0t1:
unless brlcad tells you different, give this a go from your top
level brlcad directory: make distclean && ./autogen.sh
&& ./configure --enable-all && make |
| 03:47.30 |
starseeker |
then (as root
unless you have other permissions set up for /usr/brlcad) make
install |
| 03:48.07 |
R0b0t1 |
make[1]: ***
No rule to make target distclean. stop. |
| 03:48.13 |
starseeker |
blinks |
| 03:48.19 |
starseeker |
what
directory are you in? |
| 03:48.32 |
R0b0t1 |
brlcad-7.16.0, where I unziped the
tarball. |
| 03:49.15 |
starseeker |
um. ok, just
blow away the old directory and re-unzip the tarball |
| 03:49.16 |
brlcad |
is that where
you compiled? |
| 03:49.48 |
brlcad |
you did
something wrong or you're in the wrong dir or you already ran a
partial/full distclean before |
| 03:56.08 |
R0b0t1 |
Well, I
re-untar'd, doing everything but the make distclean |
| 03:59.21 |
starseeker |
how's it
going? |
| 04:02.12 |
*** join/#brlcad Patmcc19
(n=chatzill@174-17-176-182.phnx.qwest.net) |
| 04:02.25 |
R0b0t1 |
starseeker:
Chugging along... |
| 04:06.23 |
R0b0t1 |
Oh, docbooks,
almost done |
| 04:08.53 |
R0b0t1 |
starseeker:
brlcad: Still the same error. |
| 04:10.37 |
R0b0t1 |
I mean, no
GUI. |
| 04:10.42 |
starseeker |
after a make
install |
| 04:10.45 |
R0b0t1 |
yes |
| 04:10.54 |
starseeker |
/usr/brlcad/bin/mged ? |
| 04:11.17 |
R0b0t1 |
... |
| 04:11.19 |
R0b0t1 |
Hmm |
| 04:11.26 |
R0b0t1 |
That's really
odd. Because that works. |
| 04:11.40 |
starseeker |
do "which
mged" |
| 04:11.52 |
starseeker |
without the
quotes |
| 04:12.05 |
R0b0t1 |
/bin/mget |
| 04:12.07 |
R0b0t1 |
aha |
| 04:12.15 |
starseeker |
bingo |
| 04:12.49 |
R0b0t1 |
I put the
brlcad before the others. |
| 04:12.51 |
R0b0t1 |
Now it works
:) |
| 04:13.06 |
starseeker |
cool - have
fun :-) |
| 04:14.11 |
R0b0t1 |
One quick
thing -- how do I make a database? |
| 04:14.18 |
R0b0t1 |
Swear that's
my last question. |
| 04:15.10 |
starseeker |
File->New... in mged will
work |
| 04:15.34 |
R0b0t1 |
Yeah, I was
doing that, but it fails with "no database is currently
opened |
| 04:15.45 |
starseeker |
or if you
supply a nonexisting name to mged as a command line argument, it
will ask if you want to create it |
| 04:15.49 |
starseeker |
e.g. mged
test.g |
| 04:16.13 |
starseeker |
oh, was it
now... |
| 04:16.20 |
starseeker |
checks |
| 04:16.51 |
starseeker |
hmm, works in
latest svn |
| 04:17.09 |
R0b0t1 |
Oh, there we
go. |
| 04:17.11 |
R0b0t1 |
Now it
works. |
| 04:17.14 |
R0b0t1 |
Ok, thanks
:) |
| 04:17.23 |
R0b0t1 |
starts playing with his brlcad and goes
lurking |
| 04:18.34 |
CIA-37 |
BRL-CAD:
03brlcad * r36451 10/brlcad/trunk/ (NEWS TODO src/util/Makefile.am
src/util/pix-ppm.1): added a man page for the pix-ppm
command |
| 04:19.47 |
starseeker |
wonders if anyone has ever used a SpaceNavigator to play
quake ;-) |
| 04:24.07 |
yukonbob |
R0b0t1:
enjoy!!!!!1 |
| 04:31.39 |
CIA-37 |
BRL-CAD:
03starseeker * r36452 10/brlcad/branches/STABLE/ (1295 files in 115
dirs): merge trunk to STABLE from r36077 to HEAD r36450 |
| 04:31.51 |
brlcad |
hah, down to
the wire.. nice! |
| 04:32.01 |
brlcad |
~starseeker++ |
| 04:32.12 |
yukonbob |
this going to
be a point-release? |
| 04:32.51 |
brlcad |
they're all
point-something :) |
| 04:32.57 |
starseeker |
retreats for some sleep (die evil cold germs,
die...) |
| 04:33.04 |
yukonbob |
:P
pbfffffft |
| 04:33.16 |
brlcad |
starseeker:
catch some rest this weekend finally/hopefully :) |
| 04:33.19 |
brlcad |
nice
work |
| 04:33.29 |
starseeker |
thanks - you
too! |
| 04:33.31 |
brlcad |
merge went a
lot easier with those instructions? |
| 04:33.36 |
starseeker |
FAR
easier |
| 04:33.41 |
brlcad |
great |
| 04:34.07 |
starseeker |
should send
that to the subversion guys to add into their standard
docs |
| 04:34.12 |
brlcad |
heh |
| 04:34.26 |
starseeker |
will probably reappear in ~20 hours or so |
| 04:34.36 |
brlcad |
the bad part
is needing to manually keep track of your last merge
point |
| 04:34.43 |
brlcad |
it should
figure that part out |
| 04:35.23 |
brlcad |
understandable why it works the way it
does, but from a usability standpoint, it can definitely be
improved without breaking the philosophy |
| 04:36.32 |
yukonbob |
was shocked other day when somebody mentioned Tcl 8.5.0 came
out ~2 years ago... which is ~ when I lost a grip on building
brlcad on my machine -- now I only relive the glory days of
spinning wireframes in my memory... |
| 04:36.58 |
yukonbob |
soon, I'll
get it up/running again. |
| 12:04.02 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14CFD7.dip.t-dialin.net) |
| 13:35.40 |
*** join/#brlcad KingofCSU
(n=king@222.247.93.92) |
| 14:40.49 |
*** join/#brlcad mafm (n=mafm@83.38.34.217) |
| 22:13.01 |
*** join/#brlcad talcite
(n=Matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 23:27.03 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 23:37.02 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EDC4.dip.t-dialin.net) |
| 00:00.36 |
CIA-61 |
BRL-CAD:
03brlcad * r36514 10/brlcad/trunk/src/libbn/fortran.c: remove the
ifdopn/IFDOPN fortran wrapper as it uses fdopen() which supposedly
isn't in c99 (yet is c89). old unpublished interface, see if anyone
is affected. |
| 00:33.24 |
CIA-61 |
BRL-CAD:
03brlcad * r36515 10/brlcad/trunk/src/libbu/ (backtrace.c
brlcad_path.c crashreport.c): quell a variety of compliance
warnings. popen, kill, and fileno are annoyingly not in
c99. |
| 00:44.31 |
CIA-61 |
BRL-CAD:
03brlcad * r36516 10/brlcad/trunk/src/libbu/malloc.c: in more than
15 years, i've not derived any useful value knowing sbrk(0) on an
out-of-memory state. bye. |
| 00:47.58 |
CIA-61 |
BRL-CAD:
03brlcad * r36517 10/brlcad/trunk/src/libbu/parse.c: there's no
point in limiting parsing to chars < 127, testing if it's a
space is sufficient |
| 00:48.44 |
CIA-61 |
BRL-CAD:
03brlcad * r36518 10/brlcad/trunk/src/libbu/parse.c: another
isascii() |
| 00:58.15 |
CIA-61 |
BRL-CAD:
03brlcad * r36519 10/brlcad/trunk/src/libbu/ (9 files): |
| 00:58.19 |
CIA-61 |
BRL-CAD:
quell a slew of additional warnings for strict mode compilation. we
still use |
| 00:58.21 |
CIA-61 |
BRL-CAD:
non-c99 functions, but have to declare them ourselves if it's a
strict |
| 00:58.25 |
CIA-61 |
BRL-CAD:
compliance compile (configure takes care of when they're not
available at all |
| 00:58.34 |
CIA-61 |
BRL-CAD: for
some symbols). re-enable STRICT_FLAGS. |
| 01:03.27 |
CIA-61 |
BRL-CAD:
03brlcad * r36520 10/brlcad/trunk/configure.ac: test for popen,
used by libbu in a few places |
| 01:37.33 |
Emton |
hello |
| 01:37.35 |
Emton |
? |
| 01:37.58 |
Emton |
anybody know
the rate tabinterp directive well?? |
| 01:38.42 |
Emton |
I put in a
step value of -15 and it's dropping me by 3.5 |
| 01:38.44 |
Emton |
weird |
| 01:39.02 |
Emton |
$ cat
tabinterpcmds |
| 01:39.03 |
Emton |
file
chans.vsize -; |
| 01:39.03 |
Emton |
file
chans.eyept - - 3; |
| 01:39.03 |
Emton |
file
chans.orient 4 5 6 7; |
| 01:39.03 |
Emton |
times 0 12
4; |
| 01:39.03 |
Emton |
rate 0 439.42
0; |
| 01:39.04 |
Emton |
rate 1 76.2
0; |
| 01:39.06 |
Emton |
rate 2 52.07
-14; |
| 01:39.08 |
Emton |
interp
cspline 3 4 5 6 7; |
| 01:40.26 |
Emton |
channel 2,
first val = 52.07 |
| 01:40.44 |
Emton |
channel 2,
second val = 38.9845 |
| 01:40.44 |
Emton |
whoops |
| 01:41.10 |
Emton |
channel 2,
second val = 48.57 |
| 01:41.42 |
Emton |
** read from
the sentinel file ** |
| 03:17.07 |
starseeker |
installs llvm and clang |
| 03:17.35 |
starseeker |
can't do much
in the way of c++, otherwise it would be fun to try a BRL-CAD
compile |
| 03:17.46 |
starseeker |
suppose
llvm-gcc might work |
| 03:41.33 |
*** join/#brlcad CIA-13
(n=CIA@208.69.182.149) |
| 03:49.37 |
Emton |
ok, in
tabinterp.c->rate_interpolate() |
| 03:49.37 |
Emton |
chp->c_oval[t] = ival + rate *
times[t]; |
| 03:49.37 |
Emton |
should
probably be: chp->c_oval[t] = ival + rate * t; |
| 03:49.37 |
Emton |
i'm backing
up and will try to compile and see if it works |
| 03:58.36 |
*** join/#brlcad CIA-28
(n=CIA@208.69.182.149) |
| 04:02.33 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 04:03.12 |
starseeker |
heh |
| 04:03.15 |
starseeker |
../../../brlcad/src/libbu/crashreport.c:75:21:
error: format string is not a string literal |
| 04:03.18 |
starseeker |
<PROTECTED> |
| 04:03.21 |
starseeker |
<PROTECTED> |
| 04:03.23 |
starseeker |
<PROTECTED> |
| 04:03.41 |
starseeker |
must say he like's clang's approach to error reporting at
least |
| 04:06.48 |
*** join/#brlcad Notme
(n=yas@47.18.28.72.cpe.echoes.net) |
| 04:07.17 |
Notme |
niven went
down, but i did compile and it appears to work correclty now
=) |
| 04:09.50 |
Notme |
if i had SVN
access, i would post but the change is in
src/tab/tabinterp.c->rate_interpolate() |
| 04:10.21 |
Notme |
last line
before end of FOR loop should read: chp->c_oval[t] = ival + rate
* t; |
| 04:10.52 |
starseeker |
Notme: make a
patch and submit it to sf |
| 04:11.04 |
Notme |
huh? |
| 04:11.35 |
Notme |
not familiar
w/the process of open source dev |
| 04:11.46 |
Notme |
I got SVN but
no privileges |
| 04:12.04 |
starseeker |
yeah - you do
an svn diff to see what changes were made |
| 04:12.31 |
Notme |
what do you
mean, i'm giving the change |
| 04:12.39 |
starseeker |
cd
src/tab |
| 04:12.41 |
starseeker |
svn
diff |
| 04:12.51 |
Notme |
ok hang
on |
| 04:13.01 |
starseeker |
let me check
if brlcad has a preferred way to make a patch |
| 04:13.28 |
Notme |
lol, i use
tortoise really not cmdline |
| 04:13.36 |
starseeker |
erm |
| 04:13.46 |
Notme |
is not my
copy there, where i compiled |
| 04:13.59 |
starseeker |
ok, well svn
diff > tabinterp.c.patch would work |
| 04:14.27 |
starseeker |
Notme: check
the file HACKING in the toplevel |
| 04:15.00 |
Notme |
alright, i
think i need privs tho to do any updates |
| 04:15.17 |
Notme |
i'm not
pulling from the https trunk |
| 04:15.51 |
starseeker |
yeah, first
you submit a patch here: http://sourceforge.net/tracker/?group_id=105292&atid=640804 |
| 04:15.55 |
Notme |
btw, it's me
Emton in case u didnt realize |
| 04:16.00 |
starseeker |
figured
:-) |
| 04:16.05 |
Notme |
heh |
| 04:16.17 |
starseeker |
then it gets
reviewed by a dev and incorporated |
| 04:16.25 |
starseeker |
takes a
little while to get commit access |
| 04:16.42 |
Notme |
yea, that
makes sense |
| 04:17.49 |
Notme |
i remember
when i gen'd the html pages from man was a process,
hmm.. |
| 04:20.41 |
Notme |
ok, i got the
diff |
| 04:21.11 |
Notme |
line 782,
tabinterp.c |
| 04:40.07 |
Notme |
i dunno,
sourceforge signup email not showing up |
| 04:40.25 |
Notme |
starseeker if
u got an account u can post it up |
| 04:40.41 |
Notme |
*if u don't
mind* =) |
| 05:31.22 |
Notme |
alright is
put up in the patches |
| 07:25.50 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
| 07:41.42 |
CIA-28 |
BRL-CAD:
03d_rossberg * r36521 10/brlcad/trunk/src/libbu/fchmod.c: there is
no mode_t in MSVC |
| 08:00.26 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 10:01.21 |
*** join/#brlcad mafm
(n=mafm@cpc2-bexl3-0-0-cust843.bmly.cable.ntl.com) |
| 12:23.04 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:27.37 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1802
10/wiki/Talk:BRL-CAD_Commands: |
| 13:30.03 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1803
10/wiki/MGED_CMD_cp: |
| 13:30.12 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1804
10/wiki/MGED_CMD_cpi: |
| 13:31.11 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1805
10/wiki/MGED_CMD_db: |
| 13:31.11 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1806
10/wiki/MGED_CMD_db_glob: |
| 13:31.12 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1807
10/wiki/MGED_CMD_dbbinary: |
| 13:31.12 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1808
10/wiki/MGED_CMD_dbconcat: |
| 13:33.43 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1809
10/wiki/MGED_CMD_dbfind: |
| 13:34.00 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1810
10/wiki/MGED_CMD_dbfindtree: |
| 13:34.08 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1811
10/wiki/MGED_CMD_debugbu: |
| 13:34.18 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1812
10/wiki/MGED_CMD_status: |
| 13:34.27 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1813
10/wiki/MGED_CMD_sph-part: |
| 13:34.47 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1814
10/wiki/MGED_CMD_solids_on_ray: |
| 13:35.00 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1815
10/wiki/MGED_CMD_solids: |
| 13:35.04 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1816
10/wiki/MGED_CMD_size: |
| 13:35.14 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1817
10/wiki/MGED_CMD_showmats: |
| 13:35.23 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1818
10/wiki/MGED_CMD_shells: |
| 13:35.27 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1819
10/wiki/MGED_CMD_share: |
| 13:35.35 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1820
10/wiki/MGED_CMD_set_more_default: |
| 13:35.41 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1821
10/wiki/MGED_CMD_sed: |
| 13:35.48 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1822
10/wiki/MGED_CMD_sca: |
| 13:35.58 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1823
10/wiki/MGED_CMD_ls: |
| 13:36.04 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1824
10/wiki/MGED_CMD_lookat: |
| 13:36.20 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1825
10/wiki/MGED_CMD_loadtk: |
| 13:36.37 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1826
10/wiki/MGED_CMD_l_muves: |
| 13:44.26 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1827
10/wiki/MGED_CMD_aip: |
| 13:45.24 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1828
10/wiki/MGED_CMD_cmd_win: |
| 13:45.47 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1829
10/wiki/Category:MGED_developer_commands: New page:
[[category:MGED]] |
| 13:49.21 |
CIA-28 |
BRL-CAD:
03starseeker * r36522 10/brlcad/trunk/src/libbu/ (10 files): Take a
stab at cleaning up some warnings in libbu with
llvm-gcc. |
| 13:57.03 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1830
10/wiki/MGED_CMD_collaborate: |
| 13:57.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1831
10/wiki/MGED_CMD_get_edit_solid: |
| 13:57.28 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1832
10/wiki/MGED_CMD_get_more_default: |
| 13:57.39 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1833
10/wiki/MGED_CMD_grid2model_lu: |
| 13:57.47 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1834
10/wiki/MGED_CMD_grid2view_lu: |
| 13:58.01 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1835
10/wiki/MGED_CMD_get_comb: |
| 13:58.02 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1836
10/wiki/MGED_CMD_get_dm_list: |
| 13:58.08 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1837
10/wiki/MGED_CMD_gui_destroy: |
| 13:58.14 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1838
10/wiki/MGED_CMD_hist: |
| 13:58.22 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1839
10/wiki/MGED_CMD_model2grid_lu: |
| 13:58.26 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1840
10/wiki/MGED_CMD_model2view: |
| 13:58.33 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1841
10/wiki/MGED_CMD_model2view_lu: |
| 13:58.36 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1842
10/wiki/MGED_CMD_make_name: |
| 13:58.41 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1843
10/wiki/MGED_CMD_mged_update: |
| 13:58.49 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1844
10/wiki/MGED_CMD_mmenu_get: |
| 13:58.56 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1845
10/wiki/MGED_CMD_mmenu_set: |
| 13:59.03 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1846
10/wiki/MGED_CMD_output_hook: |
| 13:59.15 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1847
10/wiki/MGED_CMD_put_comb: |
| 13:59.30 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1848
10/wiki/MGED_CMD_stuff_str: |
| 13:59.37 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1849
10/wiki/MGED_CMD_svb: |
| 13:59.44 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1850
10/wiki/MGED_CMD_tie: |
| 13:59.48 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1851
10/wiki/MGED_CMD_view2model_lu: |
| 14:01.32 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1852
10/wiki/MGED_CMD_reset_edit_solid: |
| 14:01.35 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1853
10/wiki/MGED_CMD_put_edit_solid: |
| 14:01.45 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1854
10/wiki/MGED_CMD_rset: |
| 14:01.57 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1855
10/wiki/MGED_CMD_set_more_default: |
| 14:02.16 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1856
10/wiki/MGED_CMD_share: |
| 14:02.27 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1857
10/wiki/MGED_CMD_solids_on_ray: |
| 14:02.36 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1858
10/wiki/MGED_CMD_view2model_vec: |
| 14:02.49 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1859
10/wiki/MGED_CMD_view_ring: |
| 14:02.58 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1860
10/wiki/MGED_CMD_viewget: |
| 14:03.08 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1861
10/wiki/MGED_CMD_viewset: |
| 14:03.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1862
10/wiki/MGED_CMD_winset: |
| 14:07.04 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1863
10/wiki/Category:MGED_developer_commands: |
| 14:10.14 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1864
10/wiki/MGED_CMD_hist_add: |
| 14:35.31 |
*** join/#brlcad d-lo
(n=claymore@BZ.BZFLAG.BZ) |
| 15:04.55 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36524 10/brlcad/trunk/src/libbu/ (backtrace.c
fchmod.c): wrap the extern fileno to avoid explosions where fileno
is defined as a macro (freebsd). |
| 15:53.10 |
CIA-28 |
BRL-CAD:
03starseeker * r36525 10/brlcad/trunk/src/libbu/parse.c: Put the %V
back for now - apparently there's some sort of custom BRL-CAD
specific logic at work here? |
| 17:13.04 |
CIA-28 |
BRL-CAD:
03indianlarry * r36526
10/brlcad/trunk/src/conv/step/TrimmedCurve.cpp: Added unit
converions to Trim_Curve entity when trimming by
cartesian_point. |
| 17:33.44 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1177879483.dsl.bell.ca) |
| 18:12.50 |
CIA-28 |
BRL-CAD:
03starseeker * r36527 10/brlcad/trunk/src/libbu/parallel.c: Sigh.
Put parallel.c back as well - casting is size_t, which appears to
complicate things. |
| 18:23.43 |
CIA-28 |
BRL-CAD:
03starseeker * r36528 10/brlcad/trunk/src/libbu/ (9 files): Sigh.
Size differences on different archs are causing trouble - revert
for now. |
| 18:42.37 |
CIA-28 |
BRL-CAD:
03starseeker * r36529 10/brlcad/trunk/src/libbn/ (plane.c sphmap.c
tabdata.c): Revert the libbn stuff too - need a plan on how to
approach this. |
| 18:44.44 |
starseeker |
``Erik: does
this look to be of any interest? http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/ |
| 18:54.39 |
starseeker |
hmm - looks
like we might have to ask permission to use code on that
page |
| 18:55.19 |
starseeker |
this one
looks like it might be public domain though:
http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/table2.txt |
| 18:55.56 |
starseeker |
oh, so is
this:
http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/marchingsource.cpp |
| 18:59.24 |
starseeker |
Looks like
GTS has some marching stuff as well |
| 18:59.43 |
brlcad |
cracks open an editor, finally able to get started with his
day |
| 18:59.51 |
starseeker |
morning
;-) |
| 18:59.55 |
starseeker |
sorry for the
mess |
| 19:00.05 |
brlcad |
what
mess? |
| 19:00.24 |
starseeker |
attempted to quell some warnings and ended up causing other
problems |
| 19:00.27 |
starseeker |
reverted
now |
| 19:00.31 |
brlcad |
ah |
| 19:00.42 |
brlcad |
yeah, I
suspect there will be a bit of backlash with Werror |
| 19:00.57 |
CIA-28 |
BRL-CAD:
03indianlarry * r36530
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: |
| 19:00.57 |
CIA-28 |
BRL-CAD:
Cleaned up ellipse code to directly build ellipse from
bezier(similar to the |
| 19:00.57 |
CIA-28 |
BRL-CAD:
hyperbola) versus using openNURBS ellipse routine allowing for
better control |
| 19:00.57 |
CIA-28 |
BRL-CAD: of
the curve parameterization. Also removed unit conversion of curve
endpoints |
| 19:00.57 |
CIA-28 |
BRL-CAD: for
trimmed curves now done in one place the trimmed_curve
parent. |
| 19:00.59 |
brlcad |
only quelled
a mac and linux box |
| 19:01.07 |
starseeker |
is on board with getting it cleaned up, but it looks like it
will take some work |
| 19:01.45 |
brlcad |
yep, trying
to force the hand so we don't keep having new issues slip
in |
| 19:02.03 |
starseeker |
apparently
format hates us |
| 19:03.14 |
starseeker |
jfmi - does
quelling mean "fixing" or just "turn off complaining
about"? |
| 19:03.17 |
brlcad |
yeah, right
now it's only protected against by checking for
__STRICT_ANSI__ |
| 19:03.41 |
brlcad |
both, depends
on the warning |
| 19:04.07 |
brlcad |
95% of our
warnings are benign so it's just shutting up the compiler by making
something explicit that wasn't |
| 19:04.15 |
starseeker |
do we
eventually want to fix to the point where we don't have to turn off
any of the complaints? |
| 19:04.46 |
starseeker |
nods - unfortunately anything involving size_t seems to be
trouble |
| 19:04.59 |
brlcad |
ideally, but
that probably won't happen if only for external deps |
| 19:05.16 |
brlcad |
size_t? |
| 19:05.53 |
starseeker |
one of the
format statements was casting something as (size_t) - apparently
printf doesn't deal properly with that until C99 (via
%zu) |
| 19:06.23 |
brlcad |
fyi, our
printf-style functions will all fail on %V because we do add that
one and the compiler hinting mechanism doesn't have a means (i'm
aware of) for informing it of new character format
specifiers |
| 19:06.56 |
brlcad |
so the 'fix'
for that warning is to just turn off the hint we add to tell the
compiler it's a printf-style function (it doesn't figure it out
automatically) |
| 19:06.58 |
starseeker |
could we get
around that by defining bu_format and doing any new things like %V
there? |
| 19:08.10 |
brlcad |
hm, in that
size_t case .. sounds like the cast is wrong |
| 19:08.31 |
starseeker |
parallel.c
line 1067 |
| 19:08.34 |
starseeker |
libbu |
| 19:09.55 |
starseeker |
what does %V
do - allow printing vls strings? |
| 19:10.31 |
brlcad |
yes |
| 19:11.15 |
brlcad |
a bu_format
wouldn't get around it -- you'd still have the %V
somewhere |
| 19:11.25 |
brlcad |
so long as it
was printf-style |
| 19:11.46 |
brlcad |
again, we're
the ones telling the compiler to treat it as printf-style and
validate it as such |
| 19:11.46 |
starseeker |
ah. couldn't
we just do bu_vls_addr(*vlsstring) and use %s? |
| 19:12.06 |
brlcad |
so the easy
fix is just turn off that hint if Werror is in effect |
| 19:12.09 |
starseeker |
nods |
| 19:12.25 |
brlcad |
you could do
that, lots of places that actually call fprintf/printf/snprintf/etc
do that |
| 19:12.33 |
brlcad |
but it
defeats the purpose |
| 19:13.01 |
brlcad |
and is
actually more expensive if it was something that mattered
performance-wise (not likely) |
| 19:13.35 |
starseeker |
where do we
hint? |
| 19:14.08 |
brlcad |
bu.h |
| 19:14.59 |
brlcad |
look for
__STRICT_ANSI__ .. that's where I "turn it off" presently, but
__STRICT_ANSI__ will only get set if -std= is set, which we can't
enable |
| 19:15.10 |
starseeker |
hrm |
| 19:15.17 |
brlcad |
need a better
toggle |
| 19:15.36 |
brlcad |
like maybe an
AC_DEFINE from configure |
| 19:16.15 |
brlcad |
i still need
to add a configure toggle too, so we can turn Werror off on the fly
if needed without needing an edit |
| 19:16.24 |
brlcad |
(for
third-party users) |
| 19:16.36 |
CIA-28 |
BRL-CAD:
03bob1961 * r36531 10/brlcad/trunk/src/libged/nirt.c: |
| 19:16.36 |
CIA-28 |
BRL-CAD: Mods
to accommodate an earlier change to the nirt application (.i.e.
the |
| 19:16.36 |
CIA-28 |
BRL-CAD:
application is no longer setting the file modes to O_BINARY). Here
we, likewise, |
| 19:16.36 |
CIA-28 |
BRL-CAD: no
longer set the file modes to O_BINARY and strip of any CRLF's we
find. |
| 19:17.03 |
brlcad |
o.O |
| 19:17.18 |
CIA-28 |
BRL-CAD:
03brlcad * r36532 10/brlcad/trunk/src/libbu/parallel.c: quell
warning, print the pointer as a pointer instead of a
size_t |
| 19:18.09 |
starseeker |
ah, that does
make more sense |
| 19:20.08 |
CIA-28 |
BRL-CAD:
03indianlarry * r36533
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: cleaned up
original ellipse function stubs and some reordering |
| 19:21.17 |
starseeker |
brlcad: the
one ``Erik and I really aren't sure what to do with is
bu_rb_summarize_tree in rb_diag.c |
| 19:21.59 |
brlcad |
what about
it? |
| 19:22.40 |
starseeker |
hang on, let
me regenerate the exact error |
| 19:23.08 |
brlcad |
more than
likely, just not passing a voi* |
| 19:24.09 |
starseeker |
yeah, except
one of them (I think the one on line 111) won't take that
cast |
| 19:24.18 |
starseeker |
it's some
kind of violation of ISO C |
| 19:24.23 |
brlcad |
saw those _WIN32's that bob slipped in! |
| 19:25.03 |
starseeker |
did a lot of (void *) casting in his reverted changes - if
that's what's needed I can turn it back on |
| 19:25.14 |
brlcad |
ah, yeah, you
can't cast a function to a void* |
| 19:25.23 |
brlcad |
people do it
all the time and expect it |
| 19:25.38 |
brlcad |
but the
standard says no pretty clearly |
| 19:26.18 |
brlcad |
probably just
not passing the address |
| 19:27.56 |
brlcad |
looks |
| 19:28.54 |
brlcad |
the bigger
issue is what value is there to printing a red-black tree
comparison function address |
| 19:28.55 |
Emton |
probably a
novelty but rttherm isn't in the windows distro |
| 19:29.21 |
brlcad |
Emton: there
are about 150 of 400 binaries missing from windows,
iirc |
| 19:29.31 |
Emton |
ok |
| 19:29.34 |
brlcad |
er, sorry,
flip that |
| 19:29.49 |
brlcad |
there are
about 250 missing, 150 existing of 400 |
| 19:30.09 |
Emton |
wow, alright
is that because they dev work? |
| 19:30.24 |
brlcad |
yeah, just
nobody working on that |
| 19:30.35 |
brlcad |
nothing hard
.. just very tedious |
| 19:30.37 |
Emton |
yea, i would
but i don't have VS |
| 19:30.50 |
brlcad |
could try
express ;) |
| 19:30.52 |
brlcad |
tis
free |
| 19:31.11 |
Emton |
heh, i'll
take a look at it |
| 19:31.16 |
brlcad |
I think
someone even reported that it worked with our multi-project build
setup |
| 19:31.23 |
Emton |
i'm still
banging away on my cygwin |
| 19:31.49 |
Emton |
btw, i put
the patch in under icbml for tabinterp.c |
| 19:31.51 |
brlcad |
if you get
the hankering, misc/win32-msvc8 is the dir -- brlcad
solution |
| 19:32.01 |
brlcad |
icbml? |
| 19:32.04 |
Emton |
ok |
| 19:32.09 |
brlcad |
~icbml |
| 19:32.10 |
Emton |
yea, that's
my old handle |
| 19:32.14 |
brlcad |
ahh |
| 19:32.14 |
brlcad |
k |
| 19:32.35 |
brlcad |
:) |
| 19:32.44 |
Emton |
heheh |
| 19:33.24 |
brlcad |
tsk tsk ..
someone had you post a tracker for a one-liner.. good to know the
usual process though :) |
| 19:33.37 |
Emton |
!!starseeker |
| 19:33.41 |
Emton |
ugh |
| 19:33.44 |
Emton |
yea |
| 19:33.50 |
Emton |
but at least
now I know the process |
| 19:35.07 |
brlcad |
that said..
on the surface, not sure I believe that fix.. |
| 19:35.26 |
brlcad |
that times[]
array is what it's supposed to use for rate interpolation
iirc |
| 19:35.43 |
brlcad |
really old
chunk of code, but otherwise the table wouldn't be used (or
needed) |
| 19:36.12 |
brlcad |
maybe you
have bad times[t] values |
| 19:36.13 |
Emton |
not sure, but
the rate part itself is a simple step val generator |
| 19:36.33 |
Emton |
i compiled
that and it worked as expectd |
| 19:36.53 |
starseeker |
brlcad: had
him post to (a) learn the process and (b) cause I wasn't sure and
wanted someone else to check it |
| 19:37.02 |
Emton |
it should
just iterate for every row and times the row (i) by a constant (the
rate) |
| 19:37.39 |
Emton |
i ripped the
blurb in the tracker from the tabinterp man page |
| 19:37.42 |
brlcad |
starseeker: I
know, just giving you some grief ;) |
| 19:37.53 |
starseeker |
loves grief :-) |
| 19:38.02 |
brlcad |
I know how
"fun" it is to post tracker items |
| 19:38.09 |
Emton |
hehe |
| 19:39.42 |
brlcad |
hm |
| 19:40.40 |
brlcad |
yeah, this
really feels like it only works because it's using linear
interpolation and the t param matches |
| 19:40.59 |
brlcad |
there are
different interpoliation modes where t isn't what you'd
want |
| 19:41.10 |
Emton |
yea, it's
really not even an interp it's a val generator |
| 19:41.30 |
Emton |
before it
would step by 3.5 for me no matter what |
| 19:41.59 |
brlcad |
nods |
| 19:43.08 |
brlcad |
well, frankly
you're the first to but the interpolater to use in a few years, so
taking it at face value ;) |
| 19:43.19 |
Emton |
hehe, i was
trying to use it so I could be lazy and not take keyframe saveviews
for my anims |
| 19:43.44 |
Emton |
btw, i pushed
everything into a shell script and it works pretty well |
| 19:44.18 |
Emton |
not sure if
anyone, is interested but i could post if ppl are doing
animations |
| 19:45.39 |
starseeker |
I'm sure some
folks would be interested |
| 19:46.27 |
Emton |
hmm.. well i
will clean it up and post to?? tracker? |
| 19:46.35 |
CIA-28 |
BRL-CAD:
03brlcad * r36534 10/brlcad/trunk/src/tab/tabinterp.c: |
| 19:46.35 |
CIA-28 |
BRL-CAD:
apply imcbml/Emton's sf patch 2899596 (TABINTERP RATE INTERP) where
the rate |
| 19:46.36 |
CIA-28 |
BRL-CAD:
interpolation function was taking the (fixed) times table value
instead of |
| 19:46.36 |
CIA-28 |
BRL-CAD:
directly using the simple interpolation t value. this should
hopefully fix a |
| 19:46.36 |
CIA-28 |
BRL-CAD:
tabinterp bug with rate-based table interpolation, but
untested. |
| 19:47.27 |
starseeker |
Emton: sounds
like a good candidate for the wiki |
| 19:47.31 |
starseeker |
brlcad.org |
| 19:47.55 |
Emton |
alright, just
edit and post there |
| 19:48.26 |
starseeker |
yep |
| 19:48.34 |
starseeker |
is looking for good example |
| 19:48.59 |
starseeker |
might even
add to this: http://brlcad.org/wiki/Animation |
| 19:49.04 |
Emton |
yea |
| 19:49.12 |
Emton |
that's where
i was looking |
| 19:50.22 |
CIA-28 |
BRL-CAD:
03brlcad * r36535 10/brlcad/trunk/src/tab/tabinterp.c: ws indent
style formatting cleanup |
| 19:50.51 |
Emton |
although this
is not a tutorial, this just a shell script to automate what goes
on in most of those tutorials |
| 19:51.24 |
starseeker |
no problem
:-) |
| 19:51.52 |
Emton |
hehe, ok well
i'll put it up there after i clean it up (the
non-generic) |
| 19:54.12 |
CIA-28 |
BRL-CAD:
03starseeker * r36536 10/brlcad/trunk/ (configure.ac
src/libbu/parse.c): Add a configure option to disable strict
compiler flags at need (-disable-strict) - they're enabled by
default but this provides a convenient way to turn them
off. |
| 19:55.59 |
CIA-28 |
BRL-CAD:
03starseeker * r36537 10/brlcad/trunk/src/libbu/parse.c: Blast it,
sucked in change by mistake. |
| 20:10.24 |
CIA-28 |
BRL-CAD:
03starseeker * r36538 10/brlcad/trunk/ (configure.ac include/bu.h):
Add an configure based flag for the format hitting toggle - this
should be more robust for turning on/off format
checking. |
| 20:10.27 |
starseeker |
brlcad: see
if that looks OK... |
| 20:13.37 |
brlcad |
Emton: and
keep the patches coming ;) |
| 20:13.47 |
brlcad |
don't have to
be bug fixes |
| 20:18.43 |
brlcad |
starseeker:
looks good |
| 20:19.07 |
brlcad |
just maybe
not in the summary, prime realestate |
| 20:20.39 |
CIA-28 |
BRL-CAD:
03brlcad * r36539 10/brlcad/trunk/src/tab/tabinterp.c: restructure
so forward declarations are not needed |
| 20:21.55 |
Emton |
heh, alright
well looks like i'm getting closer to a fix on my cygwin env
problems - seems my AntiVir soft was hooking opened files and
holding onto the pointers - latest SVN pull of BRLCAD has been
compiling for the last .5hr without real hiccups =) |
| 20:22.23 |
starseeker |
brlcad: yeah,
I was torn - I'll go ahead and nuke |
| 20:22.39 |
starseeker |
eventually it
shouldn't be an issue anyhow |
| 20:23.21 |
brlcad |
when in
doubt, yank |
| 20:23.58 |
CIA-28 |
BRL-CAD:
03starseeker * r36540 10/brlcad/trunk/configure.ac: Take strict
building out of summary |
| 20:24.01 |
starseeker |
yanked |
| 20:24.12 |
brlcad |
rather have
it short, 50% informative, and used 90% of the time than long, 90%
informative, and used 50% of the time.. ;) |
| 20:25.09 |
brlcad |
few other
items in there could probably get nuked at some point |
| 20:27.21 |
starseeker |
winces - opennurbs_ext.cpp + mmintrin.h is now the breakage
point |
| 20:27.22 |
starseeker |
ouch |
| 20:27.41 |
starseeker |
brlcad: can I
nuke jove from that summary? (next best thing to nuking
jove...) |
| 20:29.14 |
starseeker |
what the
bleepitty bleeepity bleep... it's complaining about conversions in
the header files |
| 20:31.40 |
CIA-28 |
BRL-CAD:
03brlcad * r36541 10/brlcad/trunk/src/tab/tabinterp.c: quell
warnings, couples bugs |
| 20:31.49 |
brlcad |
starseeker:
yeah, that'd be a good one |
| 20:32.10 |
starseeker |
http://pastebin.bzflag.bz/m68eefb84 |
| 20:32.14 |
brlcad |
what plat are
you on? |
| 20:32.50 |
starseeker |
OSX
10.4 |
| 20:33.12 |
starseeker |
pastebin is
the full error |
| 20:33.19 |
brlcad |
this isn't
something new is it? |
| 20:33.36 |
starseeker |
just when I
got past libbu and libbn with strict on |
| 20:33.37 |
brlcad |
doesn't recall modding librt |
| 20:33.48 |
brlcad |
only bu/bn
have strict enabled |
| 20:33.53 |
starseeker |
erm |
| 20:34.16 |
brlcad |
as seen in
your compile line .. no warning flags ;) |
| 20:34.38 |
starseeker |
ok... |
| 20:34.51 |
brlcad |
isn't that
the fpu/gpu issue? |
| 20:34.52 |
starseeker |
what'd I
break now... |
| 20:35.01 |
starseeker |
oh, could
be |
| 20:35.19 |
starseeker |
that's right,
the insufficient test |
| 20:35.45 |
brlcad |
though the
other was an illegal instruction |
| 20:35.56 |
starseeker |
that one
puzzled me (nothing new) - we seem to be doing sse testing in that
include conditional... |
| 20:36.44 |
starseeker |
growls |
| 20:38.13 |
starseeker |
the other
instance was a step-g conv triggered thing, iirc |
| 20:38.22 |
brlcad |
ah,
yes |
| 20:45.47 |
brlcad |
starseeker:
you still have that opennurbs_ext.cpp error? |
| 20:46.07 |
starseeker |
I started
over without strict enabled and got by it |
| 20:46.11 |
brlcad |
just noticed
your compile line is missing sse directives |
| 20:46.23 |
starseeker |
hmm |
| 20:46.25 |
brlcad |
turning
strict off got by it? |
| 20:46.29 |
starseeker |
yep |
| 20:46.31 |
brlcad |
o.O |
| 20:47.00 |
brlcad |
ahhh |
| 20:47.06 |
starseeker |
let me
capture the compile line from this one... |
| 20:47.25 |
starseeker |
/bin/sh
../../libtool --silent --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../../brlcad/src/librt -I../../include
-I../../../brlcad/src/other/libregex
-I../../../brlcad/src/other/tcl/generic
-I../../../brlcad/src/other/tcl/unix -DOBJ_BREP=1
-I../../../brlcad/src/other/tnt
-I../../../brlcad/src/other/openNURBS
-I../../../brlcad/src/other/libz -DBRLCADBUILD=1
-I../../../brlcad/include -I../../../brlcad/src/other/openNURBS
-I../../../brlcad/src/other/li |
| 20:47.26 |
brlcad |
I wonder if
it's leaving a flag set during configure |
| 20:47.41 |
brlcad |
that looks
normal |
| 20:47.45 |
brlcad |
no warning
flags |
| 20:47.57 |
brlcad |
so the only
diff should be brlcad_config.h detections |
| 20:48.18 |
brlcad |
and that is
missing -msse to enable sse support |
| 20:48.23 |
brlcad |
hence the
failure |
| 20:49.24 |
starseeker |
sees an sse section commented out in
configure.ac |
| 20:49.52 |
brlcad |
needs msse or
msse2 or msse3 |
| 20:50.15 |
starseeker |
how is strict
vs. non-strict impacting anything? |
| 20:50.32 |
brlcad |
it really
shouldn't |
| 20:51.15 |
brlcad |
only thing
that comes to mind is a flag is getting left set .. and further
function/lib/header checks then fail |
| 20:52.45 |
starseeker |
unless it's
something done by BC_COMPILER_AND_LINKER_RECOGNIZES I'm at a
loss |
| 20:54.12 |
brlcad |
yeah, dunno
.. the [no] at the end specifically means don't leave the flags
set |
| 20:54.32 |
brlcad |
compare your
config outputs |
| 20:54.52 |
brlcad |
for the same
flags, they shouldn't be diff other than the strict
define |
| 20:58.24 |
brlcad |
hm |
| 21:00.41 |
starseeker |
maybe this is
one of those weird "tree not clean things..." |
| 21:01.04 |
starseeker |
is generating configure logs for both
options |
| 21:02.03 |
CIA-28 |
BRL-CAD:
03bob1961 * r36542
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added a
public putString method. |
| 21:05.28 |
brlcad |
hm, could be
that too |
| 21:06.49 |
brlcad |
but oddness
is why it would work *without* strict .. |
| 21:06.58 |
starseeker |
ah |
| 21:07.22 |
brlcad |
it HAS to be
determining SSE is unavailable somehow |
| 21:07.27 |
brlcad |
yet with
strict on, it tries it |
| 21:07.42 |
brlcad |
maybe two
problems :) |
| 21:07.58 |
starseeker |
it thinks it
is available - remember the step-g problem |
| 21:08.15 |
brlcad |
since the
whole sse section in configure.ac is disabled, it's likely just the
emmintrin.h header test or something |
| 21:08.53 |
brlcad |
since you're
working on it, could add a --enable-vector-build option (that's why
it's commented out) |
| 21:09.13 |
starseeker |
hmm - that's
a thought |
| 21:09.37 |
starseeker |
let me figure
out why this is busted before I throw in another variable, but that
sounds like a good idea |
| 21:13.15 |
starseeker |
nothing
convincing in conf.log diffs |
| 21:15.25 |
brlcad |
what about
config.h themselves? |
| 21:15.30 |
CIA-28 |
BRL-CAD:
03brlcad * r36543 10/brlcad/trunk/ (AUTHORS NEWS): credit Emton
(irc) aka icmbml (sf) with special thanks for his 1-liner patch to
tabinterp. should fix a rate interpolation bug where interpolation
was at fixed (incorrectly large) increments. |
| 21:15.45 |
starseeker |
only diff is
the line where HAVE_STRICT is comment out vs. defined |
| 21:16.06 |
brlcad |
that's
exactly what I would have expected ... so ..... |
| 21:16.10 |
brlcad |
something
else is going on |
| 21:16.15 |
starseeker |
doing a clean
build now |
| 21:17.04 |
starseeker |
I take it
there should be no issue merging libraries built with the flags (bu
and bn ) with libraries built without them? |
| 21:17.54 |
brlcad |
nope |
| 21:18.27 |
starseeker |
shoot - it
repeated itself |
| 21:18.35 |
brlcad |
not even
different object code output, just tells the compiler 1) to report
most warnings, and 2) stop if it finds any |
| 21:19.18 |
brlcad |
trace through
just compiling that one file |
| 21:19.46 |
brlcad |
see if it's
getting to the fpu or gpu vector header for both (tossing in
#error's can help) |
| 21:20.40 |
starseeker |
wait - let me
see what happens if I go back, recompile libbu and bn without the
flags, and do this again |
| 21:21.46 |
starseeker |
brlcad: are
you on a Mac? |
| 21:23.16 |
starseeker |
phew - OK,
that still fails |
| 21:23.28 |
starseeker |
ok, what'd I
mess up in configure.ac... |
| 21:33.26 |
starseeker |
god this is
strange |
| 21:33.40 |
starseeker |
I have teh
g++ commands for both and they're identical |
| 21:39.45 |
starseeker |
brlcad: OK,
confirmed now - switching the line from /* #undef HAVE_STRICT_FLAGS
*/ to #define HAVE_STRICT_FLAGS 1 in brlcad_config.h is what causes
the failure |
| 21:42.38 |
starseeker |
I just have
no idea why |
| 21:43.03 |
Emton |
fyi,
compiling on Cygwin I had to cp src/other/tk/win/*.h
../unix |
| 21:44.53 |
Emton |
perhaps we
can put a README_CYGWIN file in? |
| 21:46.18 |
Emton |
I'd be happy
to write a quick blurb from my pains on it.. heh |
| 21:46.26 |
starseeker |
go for it
:-) |
| 21:46.48 |
Emton |
alright,
done |
| 21:52.45 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 21:55.53 |
starseeker |
hheeeellllpppp |
| 21:56.01 |
louipc |
wasup |
| 21:57.03 |
starseeker |
autoconf/automake bizarreness |
| 21:57.06 |
starseeker |
I
think |
| 21:57.31 |
louipc |
heheh |
| 21:58.41 |
Emton |
.Tpo -c -o
brlcad_path.lo brlcad_path.c |
| 21:58.41 |
Emton |
In file
included from ../../include/brlcad_version.h:84, |
| 21:58.41 |
Emton |
<PROTECTED> |
| 21:58.41 |
Emton |
../../include/conf/COUNT:1:1: invalid
suffix "n" on integer constant |
| 21:58.41 |
Emton |
../../include/conf/COUNT:1:3: no newline
at end of file |
| 21:59.05 |
Emton |
in the
include/conf/COUNT file is 1n |
| 21:59.16 |
Emton |
anybody know
if this does anything important? |
| 22:03.08 |
Emton |
heh, seems
like all those generated files popped an n on the end wherever they
came from |
| 22:03.29 |
Emton |
cat DATE:
"Wed, 18 Nov 2009 15:18:59 -0500"n |
| 22:03.59 |
Emton |
cat HOST:
"nada_lada"n |
| 22:04.22 |
Emton |
MAJOR and
MINOR don't have it |
| 22:07.23 |
Emton |
so, DATE HOST
COUNT TS PATH USER have what looks like a linefeed that never
happened |
| 22:08.33 |
starseeker |
those are
autogenerated, iirc - so yeah, probably linefeed/end of line
fun |
| 22:08.49 |
starseeker |
(sucks) |
| 22:09.47 |
Emton |
yea |
| 22:10.28 |
Emton |
they keep
getting gen'd on the fly hehe |
| 22:14.08 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 22:15.10 |
Emton |
ok, is fixed
include/conf/Makefile:110 from >>> ECHO = printf
%s\n |
| 22:15.26 |
Emton |
to
<<< ECHO = printf %s |
| 22:17.02 |
Emton |
hehe.. hang
on - it *likes* to have line feeds |
| 22:17.16 |
Emton |
not n's but
real line feeds, hehe hang on |
| 22:17.31 |
starseeker |
Emton: the
trick will be a solution that works in cygwin and other
platforms |
| 22:17.44 |
Emton |
yea |
| 22:18.17 |
brlcad |
starseeker:
if you take the one that works (i.e. doesn't define
HAVE_STRICT_FLAGS) and run: make
CPPFLAGS=-DHAVE_STRICT_FLAGS=1 |
| 22:19.34 |
Emton |
ok,
include/conf/Makefile: 110 ECHO = printf "%s\n" |
| 22:19.35 |
Emton |
works |
| 22:20.50 |
Emton |
starseeker
could you test it on real unix/linux? |
| 22:21.05 |
brlcad |
Emton:
include/conf/Makefile is autogenerated |
| 22:21.10 |
brlcad |
ECHO is set
during configure |
| 22:21.20 |
Emton |
ok |
| 22:21.36 |
brlcad |
that would be
an autoconf/automake bug |
| 22:21.40 |
Emton |
on Cygwin
looks like the open air format bombs |
| 22:21.45 |
brlcad |
something
that could probably be tested for in configure.ac
though |
| 22:22.24 |
Emton |
yea |
| 22:22.43 |
brlcad |
if you look
in there now, there's a section that makes sure ECHO is at least
set (to accommodate an older autoconf bug where it wouldn't even
set it) |
| 22:22.59 |
brlcad |
could test if
it's that printf string, and remap it to be quoted |
| 22:24.44 |
brlcad |
kind of odd
they's miss something like that with \n .. might find something
insightful if you read through the raw configure script to see how
it gets to that point |
| 22:25.03 |
Emton |
yea, seems
basic |
| 22:25.21 |
Emton |
also weird
that they have a ECHO_N but use plain ECHO for the
linefeed |
| 22:31.26 |
starseeker |
brlcad: Ah
HA! got it |
| 22:31.45 |
starseeker |
vector_x86.h
and vector_fpu.h both have __attribute__ in them |
| 22:31.59 |
starseeker |
which is
being undefed by bu.h |
| 22:32.47 |
Emton |
another
problem src/libbu/malloc.c:505 needs count to be cast as
(long) |
| 22:32.51 |
*** join/#brlcad Ralith
(n=ralith@d142-058-084-202.wireless.sfu.ca) |
| 22:34.57 |
brlcad |
AAHHHHHhhhh... |
| 22:35.00 |
brlcad |
that makes
sense starseeker |
| 22:35.17 |
starseeker |
let me see if
I can narrow the undef |
| 22:35.34 |
brlcad |
probably
shouldn't undef __attribute__ .. maybe just our BU_
attributes |
| 22:39.00 |
Emton |
problem at
src/libbu/parse.c:2187 %V format val not recognized |
| 22:39.07 |
brlcad |
times like
this I love emacs .. figured out what I needed, gotta love
introspection |
| 22:39.12 |
starseeker |
Emton: we're
working that now |
| 22:39.20 |
Emton |
heh, oh
ok |
| 22:39.27 |
starseeker |
brlcad:
hmm? |
| 22:39.46 |
Emton |
yea, i get a
bunch more errors after I changed those |
| 22:39.55 |
brlcad |
starseeker:
nothing important .. just wanted to sort a range of lines quickly,
based on a field (not just lexicographic) |
| 22:40.01 |
Emton |
resorted to
make -i heh |
| 22:40.13 |
starseeker |
ah |
| 22:40.23 |
brlcad |
Emton: if you
make CFLAGS=-w it should work |
| 22:40.36 |
Emton |
what's that
-w for? |
| 22:40.52 |
brlcad |
tells it to
not report warnings |
| 22:40.57 |
Emton |
heh
ok |
| 22:41.12 |
brlcad |
just added
strict compilation settings to libbu and libbn
yesterday |
| 22:41.23 |
brlcad |
any warnings
cause a failure |
| 22:41.30 |
Emton |
thanks, the
-i i think is ig'ing the errors |
| 22:41.37 |
Emton |
ok
yea |
| 22:41.40 |
brlcad |
the -w will
make them not be errors |
| 22:41.50 |
brlcad |
otherwise
it'll still fail to link |
| 22:42.17 |
Emton |
it's going
good now |
| 22:42.19 |
Emton |
=) |
| 22:42.34 |
starseeker |
brlcad: hrm.
How do I selectively undef just the format, printf, etc.
stuff? |
| 22:42.46 |
starseeker |
undef
__attribute__ ((__format__)) doesn't seem to work |
| 22:42.49 |
brlcad |
that's the BU
attrs |
| 22:43.23 |
starseeker |
oh, like
BU_ATTR_FORMAT12? |
| 22:43.30 |
brlcad |
__BU_ATTR...
make those be conditional instead of __attribute__
itself |
| 22:43.57 |
brlcad |
alternative,
make the __attribute__ in the dvec code be a __BE define too, set
before it's undefd |
| 22:45.13 |
Emton |
btw, before i
mention malloc.c:110 cast as long but perhaps should just change
the format to %i? shouldn't be able to hold long infos
anywayz |
| 22:45.57 |
brlcad |
110? |
| 22:46.04 |
brlcad |
that's a
blank line for me |
| 22:46.08 |
Emton |
whoops,
malloc.c:505 in src/libbu |
| 22:46.19 |
Emton |
my
bad |
| 22:47.46 |
CIA-28 |
BRL-CAD:
03brlcad * r36544 10/brlcad/trunk/src/libbu/malloc.c: cast away the
size_t to the size we're printing (thx emton) |
| 22:47.58 |
Emton |
=) |
| 22:48.07 |
brlcad |
you could end
up with long entries |
| 22:49.28 |
Emton |
ok, (long) is
better then |
| 22:49.59 |
brlcad |
unsigned
;) |
| 22:50.23 |
Emton |
hehe
yea |
| 22:50.23 |
CIA-28 |
BRL-CAD:
03brlcad * r36545 10/brlcad/trunk/src/libbu/malloc.c: dead
ws |
| 22:55.55 |
starseeker |
so far, it
looks like the compiler is complaining unless __attribute__(ignore)
is defined |
| 22:56.23 |
starseeker |
hmmm |
| 22:58.51 |
starseeker |
there we
go |
| 23:01.58 |
CIA-28 |
BRL-CAD:
03starseeker * r36546 10/brlcad/trunk/include/bu.h: Don't want to
totally undef __attributes__ - causes problems with the
vector_x86.h and probably vector_fpu.h files. |
| 23:06.45 |
starseeker |
phew -
nbuilding now |
| 23:07.20 |
brlcad |
yay |
| 23:07.29 |
starseeker |
that was
fun |
| 23:09.29 |
``Erik |
clean on 32
and 64, leenewx bsd and mac? |
| 23:09.36 |
``Erik |
msvc? |
| 23:09.58 |
starseeker |
hmm? |
| 23:10.10 |
starseeker |
I'm building
on Mac |
| 23:10.58 |
``Erik |
likes to leave his src on nfs and build in /usr/tmp/ dirs
simultaniously on multiple platforms to verify
portability |
| 23:11.21 |
starseeker |
gets confused enough doing one at at time |
| 23:11.28 |
``Erik |
hehehe |
| 23:11.42 |
``Erik |
yeah, ya
seemed confused when I started bouncing around in screens to start
my spread |
| 23:12.20 |
starseeker |
<snort>
you had some problem with not picking up the configure.ac
change |
| 23:12.48 |
``Erik |
no, I had the
configure.ac change just fine, it was one of the .c files, my mods
were preventing svn from updating it |
| 23:18.03 |
starseeker |
ah |
| 23:18.29 |
starseeker |
sighs in relief - no other issues, build finished on
Mac |
| 23:18.48 |
starseeker |
``Erik:
anyway, this isn't one of the toying with casting
issues |
| 23:19.02 |
starseeker |
just the
build logic nuking too much stuff |
| 23:20.17 |
starseeker |
I can't
recall - did someone find a clean solution to that rb_diag.c
problem with the function pointer casting? |
| 23:41.00 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 23:41.26 |
brlcad |
fg |
| 23:41.35 |
brlcad |
didn't look
into it |
| 23:41.52 |
brlcad |
quick thought
would be to just not print the address |
| 23:41.57 |
brlcad |
nonissue |
| 00:00.49 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 01:01.13 |
CIA-28 |
BRL-CAD:
03starseeker * r36566 10/brlcad/trunk/ (10 files in 4 dirs): Start
roughing out a callback approach to supplying bn_vlists to libdm.
Not getting rid of drawVList yet, but adding draw and doing some
basic tests. |
| 01:09.43 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36567 10/isst/trunk/ (configure.ac
src/Makefile.am): minor simplification of GTK+2 search |
| 01:30.35 |
CIA-28 |
BRL-CAD:
03starseeker * r36568 10/brlcad/trunk/ (11 files in 4 dirs):
Convert entirely to draw from drawVList. |
| 02:17.38 |
starseeker |
starts following the winding threads of the rtgl job
system |
| 02:21.30 |
``Erik |
careful, you
may be eaten by a grue. |
| 02:21.38 |
starseeker |
no
kidding |
| 02:21.55 |
starseeker |
or more
probably glGrue() |
| 02:25.32 |
``Erik |
glEnable(GLX_ARB_grue_object_enable); |
| 02:25.45 |
``Erik |
glQuake3(); |
| 02:25.46 |
``Erik |
:D |
| 02:25.51 |
starseeker |
hehe |
| 02:26.18 |
starseeker |
ah, quake - a
million ways to die, with the lava being the most
probable... |
| 02:26.27 |
``Erik |
no |
| 02:26.31 |
``Erik |
my rocket is
the most possible. |
| 02:26.33 |
``Erik |
even for
me. |
| 02:26.33 |
``Erik |
:> |
| 02:26.52 |
starseeker |
yeah, rocket
jumping was a kind of... dangerous art |
| 02:26.54 |
``Erik |
Br0X gibbed
himself! |
| 02:27.12 |
``Erik |
I used to be
pretty good at quakeworld |
| 02:28.02 |
``Erik |
with my
badass 120mhz cyrix machine, 48 megs of ram, and a 4m voodooG card
crankin' that glide-gl bridge |
| 02:28.10 |
``Erik |
<-- does
gansta geek handsigns |
| 02:28.50 |
starseeker |
was slightly less imposing with his ascii quake on an
i386... |
| 02:28.59 |
starseeker |
wonder if
that still exists... |
| 02:29.17 |
``Erik |
hehehe |
| 02:29.30 |
``Erik |
never did an
actual 386, went from commodore 64/128 to 486 |
| 02:29.55 |
``Erik |
I'd USED
286's and 386's... y'know, playing scorched earth and mechwarrior
at school |
| 02:29.58 |
starseeker |
ah, yes...
http://www.jfedor.org/aaquake2/ |
| 02:30.25 |
``Erik |
(because
scorched earth was a damn good use of class time in
highschool.) |
| 02:30.35 |
starseeker |
come to think
of it, IIRC my monitor sucked so bad I couldn't display enough
ascii characters to pull it off |
| 02:30.38 |
starseeker |
hehe |
| 02:30.46 |
``Erik |
hehehe |
| 02:31.06 |
``Erik |
<-- shows
off his tatung 14" b&w vga monitor (yes, vga, not svga... max
resolution of 640x400) |
| 02:32.18 |
``Erik |
at one point,
I'd opened it up, turned the yoke 90 degrees and unwired some of
the control circuitry, if you have a source voltage peaking in teh
45-90 range, it was an effective ghetto oscilloscope :) |
| 02:32.25 |
``Erik |
and I didn't
even electrocute myself |
| 02:32.36 |
``Erik |
:D |
| 02:32.51 |
starseeker |
hehe |
| 02:33.01 |
starseeker |
well, there
goes that logical explanation... |
| 02:33.18 |
``Erik |
oh, I got
through with electrocuting myself after building a strobe
light |
| 02:33.20 |
starseeker |
must try ascii quake 2 again sometime |
| 02:33.29 |
``Erik |
4kv trigger
pin, wee |
| 02:33.35 |
starseeker |
ow ow
ow |
| 02:33.54 |
``Erik |
and being as
brilliant as I am, I started soldering on it at the beginning of
second year electronics |
| 02:34.35 |
``Erik |
first and
second year shared a classroom/teacher, the first year was lecture
for the first half of the year, lab for the second half, then the
second year was lab the first half, lecture the second |
| 02:34.58 |
``Erik |
so the day
the teacher is giving his safety speech, talking about making sure
to wear safety glasses while soldering, making sure everything is
unplugged and discharged |
| 02:35.11 |
``Erik |
I put the
soldering iron to the pcb with the strobe light still plugged
in |
| 02:35.19 |
starseeker |
how'd that
go? |
| 02:35.43 |
``Erik |
kinda
exploded in my face, but made an excellent supporting point for the
safety lecture |
| 02:36.01 |
starseeker |
"if you doubt
me, ask ``Erik..." |
| 02:36.15 |
``Erik |
loud pop,
bright flash, sparks flying everywhere |
| 02:36.50 |
``Erik |
and *THAT* is
the logical explanation... |
| 02:37.22 |
starseeker |
hehe |
| 02:39.43 |
starseeker |
hhmm, even
more pointless: http://www.meow.org.uk/stan/xserver/ |
| 02:40.04 |
starseeker |
at least with
quake it might (possibly) be the only way to get decent framerates
on old hardware... |
| 02:42.45 |
``Erik |
quake did
some nifty stuff with dirty tricks and raw hw access to do what was
thought to be impossible |
| 02:42.49 |
``Erik |
"sliver"
rendering and all |
| 02:42.55 |
``Erik |
funky
LUT's |
| 03:28.14 |
``Erik |
"they took my
roommates tv and my laptop, my zune, dvd player, stereo, watch, all
my dvd's,all my checks, my credit cards, my friends xbox 360, my
moms digital camera, and my beard trimmer. They left the guitars
and the signed footballs. What I can tell is they are musically
hopeless, not sports fans, and have beards. I'm turning the
evidence over to the police." |
| 03:28.19 |
``Erik |
"..you got
robbed by nickelback?" |
| 03:39.40 |
starseeker |
hrm:
../../../brlcad/src/libbu/backtrace.c:131: error: ignoring return
value of âdupâ, declared with attribute
warn_unused_result |
| 03:41.11 |
``Erik |
sooooooo,
if(dup(x)){perror("dup"); return EXIT_FAILURE;} ? |
| 03:41.46 |
``Erik |
or
somethin' |
| 03:42.02 |
``Erik |
if stdin and
stdout are closed, those dups will fail |
| 03:43.43 |
starseeker |
why is this
just now warning? |
| 03:45.06 |
``Erik |
d'no?
different CPPFLAGS? updates to the headers or gcc or something?
code got fixed enough to get to that test? |
| 03:45.31 |
``Erik |
(if'n ya want
hurt, try hitting those files with splint) |
| 03:45.39 |
starseeker |
winces |
| 03:45.51 |
starseeker |
I'll
bet |
| 03:46.05 |
starseeker |
(sshhh, don't
give brlcad ideas...) |
| 03:46.15 |
``Erik |
:D |
| 03:46.27 |
``Erik |
I like to put
something like this in my Makefile.am's for personal
projects... |
| 03:46.28 |
``Erik |
lint: for
a in ${rand_SOURCES} ${noinst_HEADERS} ; do splint $(CFLAGS)
+posixstrictlib $$a > $$a.lint ; done |
| 03:46.59 |
``Erik |
should be on
two lines, d'no why it glued 'em together heh |
| 03:47.45 |
``Erik |
then I can do
"make lint", look at the .lint files and weep profusely |
| 03:47.46 |
``Erik |
:D |
| 03:48.48 |
starseeker |
``Erik: what
the hey, integrate it into the build as an optional
target |
| 03:48.54 |
starseeker |
might inspire
someone |
| 03:49.03 |
starseeker |
or tramatize
them... |
| 03:49.16 |
``Erik |
wonder how
easy it would be to abstract it out a bit to shove in
Makefile.defs |
| 03:49.47 |
``Erik |
-Werror -Wall
-W -ansi -pedantic causes 'nuff pain in BRL-CAD, I use those as
general working flags on some of my personal projects, so
*shrug* |
| 03:50.05 |
``Erik |
we have a
ways to go before going that far |
| 03:50.15 |
starseeker |
I'm sure the
long term goal would be to get there - might as well have it
around |
| 03:50.19 |
``Erik |
it's easy to
be excessive on a toy project :D |
| 03:50.23 |
starseeker |
heh |
| 03:50.56 |
``Erik |
I think my
thing uses some bashisms, though :/ |
| 03:51.52 |
starseeker |
auuuuuugh - I
think I just killed my comparison benchmark results |
| 03:52.01 |
starseeker |
and when the
update busted the build, too |
| 03:52.03 |
starseeker |
grr |
| 03:52.34 |
``Erik |
thinks he needs to cook a metaball regression test
:/ |
| 03:52.43 |
starseeker |
might be a
good idea... |
| 03:52.58 |
``Erik |
been thinking
it for a while, just didn't want to admit it |
| 03:53.55 |
``Erik |
run it in
retarded accurate mode and cook a fast machine for a few days to
generate reference pix files, then tune it to the right balance or
something |
| 03:54.18 |
starseeker |
nods |
| 03:54.32 |
starseeker |
sounds like a
job for the new solaris box |
| 03:54.46 |
``Erik |
hm, the 64
core one? |
| 03:54.52 |
starseeker |
grins evilly |
| 03:55.00 |
``Erik |
I'm not sure
if it'd be any faster than one of the 6 new xeon boxes |
| 03:55.06 |
``Erik |
be
interesting to compare |
| 03:55.24 |
``Erik |
as soon as
brlcad gets off his lazy ass and gets the solaris boxes ready for
general consumption :> |
| 03:55.37 |
starseeker |
I thought at
least one of them was there |
| 03:55.50 |
``Erik |
um, the
opteron one is almost there I think? |
| 03:57.18 |
``Erik |
that'd be an
amusing thing for an aspiring contribute to glue together... a
semi-automated VGR collector, mebbe with some php gd stuff for
purdee graphs |
| 03:57.38 |
``Erik |
make
bench-upload |
| 03:57.40 |
``Erik |
O.o |
| 04:04.16 |
starseeker |
erm - the
if(dup) thing didn't work, but assigning the result of dup to some
useless integer does |
| 04:05.12 |
``Erik |
funky |
| 04:05.24 |
``Erik |
I wonder if
if(dup()!=0) would work |
| 04:06.30 |
starseeker |
does disable strict because he wants is
benchmark... |
| 04:07.32 |
``Erik |
I think it
doesn't make sense to attempt to attach like that if any of those
dups fail, that's catastrophic failure turf I'd imagine |
| 04:07.56 |
starseeker |
if ignoring
return values is a cardnial sin, we're gonna have some fun with the
other libs |
| 04:08.56 |
``Erik |
I'd have to
check some things, but in this certain case, those dups failing may
mean the os is busy exploding *shrug* |
| 04:09.40 |
``Erik |
gcc and
splint have no way of groking those cases :) |
| 04:15.41 |
starseeker |
sigh:
http://imgs.xkcd.com/comics/academia_vs_business.png |
| 04:25.24 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 05:40.54 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1866
10/wiki/MGED_CMD_orientation: |
| 05:41.04 |
brlcad |
woot |
| 05:43.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1867
10/wiki/MGED_CMD_ae: |
| 05:43.50 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1868
10/wiki/Category:MGED_view_manipulation: New page:
[[category:MGED|View manipulation]] |
| 05:56.48 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1869
10/wiki/MGED_CMD_aproposdevel: |
| 05:57.27 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1870
10/wiki/MGED_CMD_aproposlib: |
| 05:58.54 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1871
10/wiki/Category:MGED_help: New page: MGED commands that search or
view internal documentation. [[category:MGED]] |
| 05:59.19 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1872
10/wiki/MGED_CMD_QuestionMark: |
| 05:59.28 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1873
10/wiki/MGED_CMD_QuestionMarkDevel: |
| 05:59.39 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1874
10/wiki/MGED_CMD_QuestionMarkLib: |
| 06:01.03 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1875
10/wiki/MGED_CMD_help: |
| 06:01.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1876
10/wiki/MGED_CMD_helpdevel: |
| 06:01.38 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1877
10/wiki/MGED_CMD_helplib: |
| 06:05.32 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1878
10/wiki/MGED_CMD_Z: |
| 06:07.31 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1879
10/wiki/MGED_CMD_zoom: |
| 06:11.31 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1880
10/wiki/Saveview: redirecting article to much better written and
titled version |
| 06:11.43 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1881
10/wiki/MGED_CMD_saveview: |
| 06:13.28 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1882
10/wiki/MGED_CMD_3ptarb: |
| 06:15.26 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1883
10/wiki/MGED_CMD_erase_all: |
| 06:16.58 |
starseeker |
well, it
looks initially like llvm-gcc is a bit slower - re-running llvm-gcc
with identical code and compile settings just to be
sure |
| 06:17.47 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1884
10/wiki/MGED_CMD_arb: |
| 06:18.16 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1885
10/wiki/MGED_CMD_comb: |
| 06:19.23 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1886
10/wiki/Category:MGED_object_creation: New page:
[[category:MGED]] |
| 06:19.54 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1887
10/wiki/MGED_CMD_center: |
| 06:20.01 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1888
10/wiki/MGED_CMD_erase: |
| 06:20.13 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1889
10/wiki/MGED_CMD_dall: |
| 06:20.24 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1890
10/wiki/MGED_CMD_d: |
| 06:20.32 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1891
10/wiki/MGED_CMD_draw: |
| 06:24.00 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1892
10/wiki/MGED_CMD_eye_pt: |
| 06:26.36 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1893
10/wiki/MGED_CMD_B: |
| 06:27.06 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1894
10/wiki/MGED_CMD_e_lower: |
| 06:27.32 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1895
10/wiki/MGED_CMD_E_upper: |
| 06:41.18 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1896
10/wiki/MGED_CMD_in: |
| 06:42.52 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1897
10/wiki/MGED_CMD_autoview: |
| 06:43.41 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1898
10/wiki/MGED_CMD_lookat: |
| 09:06.40 |
*** join/#brlcad Don__
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 09:08.03 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 09:15.43 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 10:48.26 |
CIA-28 |
BRL-CAD:
03Aanc 07http://brlcad.org * r1899
10/wiki/Talk:MGED_Commands: Command-scheme: purpose
first? |
| 12:38.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1900
10/wiki/MGED_CMD_view: |
| 12:39.52 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1901
10/wiki/MGED_CMD_viewsize: |
| 12:42.49 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1902
10/wiki/MGED_CMD_tops: |
| 12:43.28 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1903
10/wiki/MGED_CMD_r: |
| 12:46.24 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1904
10/wiki/MGED_CMD_tops: merge from weaker description |
| 12:46.55 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1905
10/wiki/Tops: Redirecting to [[MGED CMD tops]] |
| 12:52.29 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1906
10/wiki/MGED_CMD_viewset: |
| 12:54.26 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1907
10/wiki/MGED_CMD_setview: |
| 12:54.30 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1908
10/wiki/MGED_CMD_view_ring: |
| 12:54.34 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1909
10/wiki/MGED_CMD_viewget: |
| 12:54.36 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1910
10/wiki/MGED_CMD_vrot: |
| 12:59.53 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1911
10/wiki/Animation: |
| 13:02.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1912
10/wiki/MGED_CMD_animmate: |
| 13:02.31 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1913
10/wiki/MGED_CMD_arced: |
| 13:02.40 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1914
10/wiki/MGED_CMD_joint: |
| 13:02.48 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1915
10/wiki/MGED_CMD_preview: |
| 13:02.55 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1916
10/wiki/MGED_CMD_savekey: |
| 13:03.30 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1917
10/wiki/MGED_CMD_saveview: |
| 13:03.51 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1918
10/wiki/Category:Animation: New page:
[[category:documentation]] |
| 13:08.45 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1919
10/wiki/Talk:MGED_Commands: |
| 13:22.02 |
starseeker |
blinks |
| 13:22.09 |
starseeker |
ok... |
| 13:22.31 |
starseeker |
must conclude that llvm-gcc vs gcc is a wash - looks like the
differences were in the noise |
| 13:36.43 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1920
10/wiki/MGED_CMD_apropos: |
| 13:37.09 |
brlcad |
still going
at it, nice |
| 13:43.56 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1921
10/wiki/MGED_CMD_view2model: |
| 13:44.22 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1922
10/wiki/MGED_CMD_view2grid_lu: |
| 13:45.50 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1923
10/wiki/Category:Animation: |
| 13:51.47 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1924
10/wiki/MGED_CMD_arced: |
| 13:51.59 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1925
10/wiki/MGED_CMD_copyeval: |
| 13:52.32 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1926
10/wiki/MGED_CMD_copymat: |
| 13:52.48 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1927
10/wiki/MGED_CMD_listeval: |
| 13:53.06 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1928
10/wiki/MGED_CMD_matpick: |
| 13:53.14 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1929
10/wiki/MGED_CMD_oed: |
| 13:53.24 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1930
10/wiki/MGED_CMD_orot: |
| 13:53.56 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1931
10/wiki/MGED_CMD_oscale: |
| 13:54.03 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1932
10/wiki/MGED_CMD_putmat: |
| 13:54.17 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1933
10/wiki/MGED_CMD_rotobj: |
| 13:54.30 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1934
10/wiki/MGED_CMD_showmats: |
| 13:54.34 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1935
10/wiki/MGED_CMD_translate: |
| 13:55.46 |
CIA-28 |
BRL-CAD:
03Ssd 07http://brlcad.org * r1936
10/wiki/Loadview: |
| 14:05.29 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 14:15.03 |
starseeker |
bastardizes the Makefiles into calling clang instead of
llvm-gcc and builds again to see what breaks :-) |
| 14:20.57 |
*** join/#brlcad mafm
(n=mafm@cpc2-bexl3-0-0-cust843.bmly.cable.ntl.com) |
| 14:29.44 |
``Erik |
heh,
microsoft trying to patent tufte's sparklines |
| 14:40.20 |
starseeker |
saw
that |
| 14:40.52 |
starseeker |
actually, I
owe them one - I went to amazon to check out Tufte's books and
spotted a $40 copy of Lisp in Small Pieces :-) |
| 14:51.20 |
starseeker |
wow, clang
actually got all the way to liboptical |
| 14:51.41 |
starseeker |
not sure if
this is legit: |
| 14:51.42 |
starseeker |
../../../brlcad/src/liboptical/sh_billboard.c:117:41:
error: initializer element is not a compile-time |
| 14:51.45 |
starseeker |
<PROTECTED> |
| 14:51.48 |
starseeker |
struct
bu_structparse bbd_parse_tab[] = { |
| 14:51.50 |
starseeker |
<PROTECTED> |
| 14:51.59 |
brlcad |
it
lies |
| 14:52.42 |
starseeker |
figured |
| 14:52.49 |
brlcad |
curious
though |
| 14:53.04 |
brlcad |
it should
have hit other bu_structparse tables initialized the same
way |
| 14:53.12 |
brlcad |
e.g., the
huge one in librt |
| 14:53.27 |
brlcad |
looks |
| 14:53.42 |
starseeker |
well,
considering clang is still in development... |
| 14:54.41 |
brlcad |
nah, there's
something to it |
| 14:54.56 |
brlcad |
there's a
parsetab right before it that it didn't stop on |
| 14:55.05 |
starseeker |
hmm |
| 14:55.43 |
brlcad |
interesting,
maybe because the second one indexes the first one |
| 14:55.45 |
brlcad |
bbd_print_tab[0] |
| 14:56.01 |
brlcad |
it's still
constant though |
| 14:56.37 |
brlcad |
if you
comment out that line, does it succeed? |
| 14:56.53 |
brlcad |
not the
bbd_parse_tab line, but the first entry |
| 14:57.01 |
brlcad |
so it's just
a null tab |
| 14:57.09 |
starseeker |
yeah, it
succeeds |
| 14:58.24 |
starseeker |
same deal in
sh_fire.c |
| 14:58.42 |
starseeker |
clang
bug? |
| 14:59.24 |
starseeker |
well, gotta
hit the road - be in in a bit |
| 14:59.26 |
brlcad |
looks like it
to me |
| 14:59.46 |
starseeker |
should report it, I suppose... |
| 14:59.55 |
brlcad |
though the
dual structparse tabs is kinda funky to me .. looks like one is the
main options with names spelled out |
| 15:00.04 |
brlcad |
then the
second is shorthand option names |
| 15:00.08 |
brlcad |
so it prints
clean |
| 15:00.12 |
brlcad |
yeah |
| 15:00.30 |
brlcad |
that's
probably because it's [] defined, the compiler doesn't know it's
size yet |
| 15:00.49 |
brlcad |
ooh.. you
know what |
| 15:00.58 |
brlcad |
have to look
at bu_byteoffset() ... |
| 15:01.07 |
brlcad |
it may be
getting to a non-const section |
| 15:01.33 |
brlcad |
that's a
low-level bu macro |
| 15:01.45 |
starseeker |
oooo -
debugging hell |
| 15:02.23 |
brlcad |
it probably
just requires a little bit a of magic |
| 15:02.35 |
brlcad |
bu.h has a
section for all the compilers we know about |
| 15:02.42 |
starseeker |
oooooh |
| 15:02.51 |
brlcad |
I'm betting
it just needs a diff decl |
| 15:02.57 |
starseeker |
nods |
| 15:03.58 |
brlcad |
still
probably a bug, they are all constant .. but it's low-level pointer
trickery to get the memory byte offset address of a
struct |
| 15:19.21 |
brlcad |
yeah, that
looks like it's it |
| 15:19.55 |
brlcad |
it's not
smart enough yet to realize the "address - 0" is actually constant,
probably needs to jump into the __INTEL_COMPILER
section |
| 15:20.34 |
brlcad |
gets moving |
| 15:33.41 |
CIA-28 |
BRL-CAD:
03d_rossberg * r36569
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added
bu_process_id for showshot program |
| 15:50.09 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36570 10/brlcad/trunk/src/adrt/Makefile.am: make
librender depend on libgcv (thus librt, libbu, libbn,
etc) |
| 15:50.51 |
CIA-28 |
BRL-CAD:
03d_rossberg * r36571
10/brlcad/trunk/src/nirt/showshot.c: |
| 15:50.51 |
CIA-28 |
BRL-CAD:
replaced index() by strchr() as recommended by POSIX.1-2008 and
MSVC |
| 15:50.51 |
CIA-28 |
BRL-CAD:
however, i can't see the reason to determine the location of
newline at all, it won't be used in the code below |
| 15:55.28 |
``Erik |
hm, the
tightened up tolerances drive the tesselation routines up the
wall |
| 16:27.36 |
brlcad |
``Erik: yeah,
I'm going to go back and relax them .. rendering problems
too |
| 16:27.42 |
brlcad |
shame
really |
| 16:27.55 |
brlcad |
that's
substantially above floating point |
| 16:28.47 |
brlcad |
going to add
a tol param to them, but that'd be a 7.18 change and we're too far
into this month for that |
| 17:01.43 |
brlcad |
missed the call |
| 17:58.20 |
CIA-28 |
BRL-CAD:
03Aanc 07http://brlcad.org * r1937
10/wiki/Talk:MGED_CMD_comb_color: New page: Argument(s)
combination_name Name of the New combination Description The
"comb_color" command assigns the color rgb (0-255) to the existing
combination named combination_name. "New" com... |
| 17:59.07 |
``Erik |
was a lunch
query, we hit greene turtle |
| 17:59.40 |
``Erik |
was some nice
scenery there today O.o |
| 18:08.40 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36572
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: jot down a
rough idea of a plan for implementing marching cubes |
| 18:22.09 |
CIA-28 |
BRL-CAD:
03erikgreenwald * r36573 10/brlcad/trunk/src/libbu/rb_diag.c:
rbt_debug is a bitfield, not a pointer. Use %X instead of
%p |
| 18:41.33 |
starseeker |
brlcad: hmm -
kinda looks like aeVect and friends in dm-rtgl might be candidates
for libbn |
| 18:42.41 |
``Erik |
brlcad might
get a kick out of http://www.technologyreview.com/blog/arxiv/24437/?a=f
O.o |
| 18:43.17 |
``Erik |
(solving the
rowing "wiggle" problem) |
| 18:44.59 |
starseeker |
heh - he will
like that |
| 18:45.21 |
``Erik |
don't think
it's the same rowing her does, but *shrug* |
| 18:45.27 |
``Erik |
s/her/he/ |
| 18:46.33 |
``Erik |
(they're
talking 8 man coxless rowing, I think... but reducing wiggle might
help efficiency *shurg*) |
| 18:52.17 |
starseeker |
hates to rework the vector calculation stuff but knows he
must to clean this up - here we go into vector
land... |
| 19:05.59 |
*** join/#brlcad talcite
(n=Matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 19:11.14 |
CIA-28 |
BRL-CAD:
03starseeker * r36574 10/brlcad/trunk/src/libdm/dm-rtgl.c: Doesn't
look as if aeUniformVect is being used anywhere. |
| 19:28.20 |
brlcad |
``Erik: heh,
that's awesome |
| 19:29.31 |
brlcad |
starseeker:
they do look prime for libbn .. just maybe make sure there aren't
libbn facilities already for tose too |
| 19:30.13 |
starseeker |
the Uniform
one just goes away - I don't see anything quite like the vector
from ae + distance one |
| 19:31.26 |
starseeker |
added it in test as bn_vec_ae |
| 19:41.53 |
brlcad |
nods |
| 19:51.46 |
CIA-28 |
BRL-CAD:
03starseeker * r36575 10/brlcad/trunk/ (include/bn.h
src/libbn/mat.c): Add libbn routines for getting a vector from
azimuth and elevation information. |
| 20:00.30 |
brlcad |
how are vec
ae and vec aed different? |
| 20:00.42 |
brlcad |
and what
happens the first time someone asks for twist |
| 20:00.59 |
starseeker |
um - twist
wouldn't change anything... |
| 20:01.20 |
starseeker |
ae doesn't
need a distance and just returns a unit vector |
| 20:01.25 |
starseeker |
aed accepts a
distance |
| 20:02.44 |
starseeker |
aed is the
only one I'll likely need - I just thought as long as I was there I
would define the logical counterpart for the "no distance
available" case |
| 20:03.10 |
brlcad |
not a
generalized way to combine the two, though? |
| 20:03.28 |
brlcad |
zero-dist for
example gives ae behavior |
| 20:03.33 |
brlcad |
or 1 or
negative |
| 20:03.44 |
brlcad |
hm, not
negative |
| 20:04.02 |
starseeker |
well, maybe -
I was going along with the bn_aet_vec and bn_ae_vec
thing... |
| 20:04.46 |
brlcad |
it could be a
scaling factor instead of a dist |
| 20:04.50 |
brlcad |
yeah, there
is that |
| 20:05.15 |
brlcad |
so bn_vec_ae
will reverse a bn_ae_vec call? |
| 20:05.27 |
brlcad |
that's reason
alone to have that one |
| 20:05.35 |
starseeker |
um, I guess
in theory... |
| 20:05.43 |
starseeker |
is getting set up to test |
| 20:05.55 |
brlcad |
if it
doesn't, somethings wrong :) |
| 20:06.05 |
starseeker |
agrees :-) |
| 20:06.05 |
brlcad |
or it's the
wrong name |
| 20:06.21 |
starseeker |
it should -
just saying I haven't put 'em into rtgl yet |
| 20:06.53 |
starseeker |
had hacked up the files moving stuff around before he
realized he should move that logic, so having to reset without
losing things... |
| 20:07.20 |
brlcad |
are you aware
of the vmath routines? |
| 20:07.46 |
starseeker |
I'm aware of
vmath, didn't know there was something specific for this in
there |
| 20:07.48 |
brlcad |
V3DIR_FROM_AZEL() and
AZEL_FROM_V3DIR() |
| 20:08.01 |
starseeker |
ah |
| 20:08.22 |
starseeker |
er... then
why does bn_ae_vec exist? |
| 20:08.25 |
brlcad |
so need to
clean up our API ;) |
| 20:08.31 |
brlcad |
we can't even
find our own shit :) |
| 20:08.55 |
starseeker |
hangs head |
| 20:09.01 |
starseeker |
so which one
do I go with? |
| 20:09.14 |
brlcad |
I think
someone needed vec from ae, so the bn_ae_vec wasn't
useful |
| 20:09.32 |
brlcad |
then someone
saw V3DIR_FROM_AZEL and made the counterpart |
| 20:09.47 |
starseeker |
ah, just like
I did for bn_ae_vec |
| 20:09.49 |
brlcad |
yep |
| 20:09.58 |
brlcad |
go ahead and
add it, you're already there |
| 20:10.08 |
starseeker |
alrightie...
so who gets it, vmath or libbn? |
| 20:11.17 |
brlcad |
libbn is the
one lacking at the moment |
| 20:11.36 |
starseeker |
notes the mere existence of aeVect is evidence of lack of API
usage - first place to look for that stuff should have been
existing libs, particcularly if V3DIR_FROM_AZEL already
existed |
| 20:11.59 |
brlcad |
having azel
in vmath is kind of out of place for that file |
| 20:12.31 |
starseeker |
wonder where
we're using em... |
| 20:12.37 |
brlcad |
mged
is |
| 20:12.38 |
starseeker |
here grep
grep grep... |
| 20:12.55 |
brlcad |
er, libged
now |
| 20:13.01 |
brlcad |
dir2ae and
ae2dir commands |
| 20:14.02 |
starseeker |
sooo... point
those a the libbn routines and clear out the vmath stuff? or I
suppose deprecate since it impacts api? |
| 20:15.12 |
starseeker |
yep, just
those two |
| 20:15.29 |
brlcad |
I'd actually
probably just use the vmath ones in the function's
implementation |
| 20:15.49 |
brlcad |
keeping both
in the API for now |
| 20:15.59 |
brlcad |
till libbn's
docs are cleaned up and it's more clear which is best |
| 20:16.09 |
starseeker |
nods |
| 20:16.18 |
brlcad |
vmath's
approach is way faster as a macro |
| 20:16.45 |
brlcad |
but then can
have side-effects and is typeless |
| 20:18.16 |
starseeker |
KNEW he should have just backed the logic of aeVec down into
the rtgl functions ;-P |
| 20:19.11 |
brlcad |
but then
things wouldn't actually improve.. going down the rabbit hole,
wherever it leads, is how things get better ;) |
| 20:19.15 |
brlcad |
cleaning up
along the way |
| 20:20.09 |
starseeker |
true. I
suppose I knew this would come up dealing with this part of the
code |
| 20:20.58 |
brlcad |
ahh.. feels
so good watching libbu/libbn compile cleanly |
| 20:21.00 |
brlcad |
like a clean
car ready to be driven |
| 20:21.26 |
starseeker |
are you
getting that dup return value thing? |
| 20:21.37 |
brlcad |
hm? |
| 20:22.36 |
starseeker |
../../../brlcad/src/libbu/backtrace.c:131:
error: ignoring return value of 'dup', declared with attribute
warn_unused_result |
| 20:22.52 |
starseeker |
was getting
that on my gentoo box last night |
| 20:23.10 |
CIA-28 |
BRL-CAD:
03brlcad * r36576 10/brlcad/trunk/src/libsysv/tcl.c: quell unused
warning |
| 20:23.37 |
CIA-28 |
BRL-CAD:
03brlcad * r36577 10/brlcad/trunk/src/libsysv/Makefile.am: enable
strict compilation of libsysv. |
| 20:24.16 |
brlcad |
yeah, I don't
get that warning, probably a newer glibc |
| 20:24.56 |
starseeker |
mmm |
| 20:25.17 |
starseeker |
is about to pay the price of running cutting
edge |
| 20:25.58 |
starseeker |
not really
sure what to do with it - apparently we don't actually care about
the return value |
| 20:26.24 |
starseeker |
just defining
a value and point the result to it worked but seemed rather
crude |
| 20:26.26 |
CIA-28 |
BRL-CAD:
03brlcad * r36578 10/brlcad/trunk/src/libbu/backtrace.c: add sanity
check on the return value from dup to make sure it succeeded.
quellage. |
| 20:26.49 |
starseeker |
oh
:-) |
| 20:26.49 |
brlcad |
the warning
is just "dup might fail, you're not checking" |
| 20:26.56 |
brlcad |
so we can
check |
| 20:27.21 |
brlcad |
a good thing
to do regardless |
| 20:28.33 |
starseeker |
nods thanks :-) |
| 20:31.53 |
starseeker |
well, rtgl
seem to be behaving using bn_vec_aed |
| 20:33.34 |
starseeker |
brlcad: I'd
like to try, when I get there, switching the openGL lighting to the
default raytrace lighting |
| 20:33.45 |
starseeker |
whatever it
is now doesn't seem to behave well unniversally |
| 20:34.48 |
CIA-28 |
BRL-CAD:
03brlcad * r36579 10/brlcad/trunk/TODO: |
| 20:34.48 |
CIA-28 |
BRL-CAD:
update todo for the next release, 64-bit windows port under way,
annotation |
| 20:34.48 |
CIA-28 |
BRL-CAD:
primitive under way, obj-g postponed. add a new entry for adding a
tolerance |
| 20:34.48 |
CIA-28 |
BRL-CAD:
parameter to some of the bn_ functions that have near-zero tests
(but have to |
| 20:34.48 |
CIA-28 |
BRL-CAD: wait
for a minor release). |
| 20:35.18 |
brlcad |
starseeker:
when you get where? what? hm? |
| 20:35.55 |
starseeker |
doing an rtgl
visualization |
| 20:36.07 |
CIA-28 |
BRL-CAD:
03starseeker * r36580 10/brlcad/trunk/src/libdm/dm-rtgl.c: OK, use
the libbn routine and nix aeVec. |
| 20:36.22 |
starseeker |
nick put the
lighting front and center, iirc - that washes out on some
platforms |
| 20:36.50 |
starseeker |
assuming it's
not some other issue, of course |
| 20:37.12 |
brlcad |
ahhh |
| 20:37.15 |
brlcad |
yeah, that's
nfg |
| 20:38.15 |
starseeker |
it's a ways
off, but once I'm there it seems like the "correct" thing to do is
to use the raytracer settings insofar as they make
sense |
| 20:39.43 |
brlcad |
yeah, should
match |
| 20:39.53 |
brlcad |
that's an
oldie... hm |
| 20:40.00 |
CIA-28 |
BRL-CAD:
03brlcad * r36581 10/brlcad/trunk/src/libsysv/Makefile.am:
reconcile the libsysv target CFLAGS customization. apply the flags
to the whole dir. |
| 20:40.04 |
brlcad |
worked on
changing rt's default lighting many many years ago |
| 20:40.36 |
brlcad |
there are
hooks in there now for 1 light, 3 lights, .. it was tricky to get
everything validating regression and still be useful defaults
iirc |
| 20:41.06 |
starseeker |
couldn't the
regression call out the older lights specifically? |
| 20:51.17 |
brlcad |
it
could |
| 20:51.38 |
brlcad |
but there was
some issue that couldn't quickly be resolved |
| 20:51.51 |
brlcad |
and I was
less adept at running down the rabbit hole that long
ago |
| 20:52.11 |
starseeker |
ahh. VERY
oldie :-) |
| 20:52.33 |
brlcad |
yeah, decade
ago |
| 20:52.47 |
brlcad |
at least with
the brl-cad codebase |
| 20:53.00 |
brlcad |
wasn't as
comfortable knowing what would be impacted |
| 21:12.00 |
starseeker |
brlcad:
should I be doing checkings in an "keep rtgl working"
manner? |
| 21:12.50 |
starseeker |
at some point
here there's going to be some fairly radical surgery |
| 21:16.39 |
CIA-28 |
BRL-CAD:
03brlcad * r36582 10/brlcad/trunk/src/libpc/ (pcVariable.cpp
pcVariable.h pc_constraints.c): quell a variety of warnings and
problems. floating point comparisons and virtual
destruction |
| 21:17.57 |
brlcad |
starseeker:
it's a good exercise to the reader to learn to code that way even
through radical changes |
| 21:20.06 |
brlcad |
"harder" if
you're not used to it and can seem like more work, but it's not
usually in terms of the full cost of the changes (shared knowledge
among developers, documented changes, reduced risk, incremental
refactoring, etc) |
| 21:20.16 |
brlcad |
part of the
concept of coding complete |
| 21:20.31 |
*** join/#brlcad roberthl
(n=robert@rhl.me.uk) |
| 21:20.56 |
brlcad |
but that
said, if you break it, no big deal at this point .. but just might
be making life even harder for yourself later (short term gain for
a later pain) |
| 21:21.16 |
starseeker |
nods - I'll try to keep it clean |
| 21:21.34 |
starseeker |
in some sense
though (job robustness to draw events) it's already
broken |
| 21:22.37 |
brlcad |
if that were
really true, there wouldn't have been a question ;) |
| 21:23.38 |
starseeker |
I know, I
know - it does something |
| 21:24.21 |
brlcad |
wow, libpc is
going to take some heavier lifting than I have time to
invest |
| 21:24.34 |
brlcad |
at least with
respect to warnings |
| 21:25.12 |
brlcad |
and it's not
even the boost stuff |
| 21:25.14 |
brlcad |
the classes
need some cleanup work |
| 21:26.47 |
brlcad |
our headers
still need work before they're fed through to a c++ compiler
cleanly |
| 21:58.16 |
CIA-28 |
BRL-CAD:
03brlcad * r36583 10/brlcad/trunk/src/liboptical/sh_toyota.c:
remove lots of dead code, replace PI with M_PI |
| 22:39.18 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
| 22:57.19 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 23:00.30 |
CIA-28 |
BRL-CAD:
03brlcad * r36584 10/brlcad/trunk/src/librt/ (bezier_2d_isect.c
bool.c cmd.c constraint.c): quell a variety of warnings: unused
vars, floating point comparisons, missing initializers, and more.
most curious were the floating point equality comparisons happening
in rt_bool_final() .. need to validate regresion. |
| 23:10.53 |
*** join/#brlcad roberthl
(n=robert@rhl.me.uk) |
| 23:12.27 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 23:13.23 |
CIA-28 |
BRL-CAD:
03brlcad * r36585 10/brlcad/trunk/src/librt/ (constraint.c cut.c):
indent, ws, comment cleanup |
| 00:51.41 |
CIA-14 |
BRL-CAD:
03brlcad * r36627 10/brlcad/trunk/src/conv/ (bot_shell-vtk.c
dxf/g-dxf.c iges/main.c): wth, de-knrify main() |
| 00:53.02 |
``Erik |
bleh, I just
wrote some java |
| 00:53.07 |
``Erik |
looks for a drink O.o |
| 00:56.18 |
brlcad |
you dirty
ditry person |
| 00:56.28 |
CIA-14 |
BRL-CAD:
03brlcad * r36628 10/brlcad/trunk/src/ (5 files in 4
dirs): |
| 00:56.28 |
CIA-14 |
BRL-CAD: make
the gcv_region_end callback take a dummy struct for passing back
the |
| 00:56.30 |
CIA-14 |
BRL-CAD:
callback writer function instead of casting that function
unportably through a |
| 00:56.34 |
CIA-14 |
BRL-CAD:
void*. this is dumb quellage but allows libgcv to go strict too.
(TODO: |
| 00:56.36 |
CIA-14 |
BRL-CAD:
refactor the gcv callback) |
| 00:56.47 |
brlcad |
and shame on
you for copy-pasting a k&r function signature :) |
| 00:56.57 |
brlcad |
(g-stl ->
g-egg) |
| 00:58.52 |
``Erik |
try { return
true; } finally { return false; } |
| 00:58.56 |
``Erik |
heh,
doh |
| 00:59.11 |
``Erik |
'cept it was
a file copy and some :%s///g stuff |
| 01:00.30 |
brlcad |
d-lo: body
count is 1100 now ... hehe, he is legend |
| 01:00.49 |
``Erik |
<-- needs
to pick up that book |
| 01:01.56 |
``Erik |
watches V |
| 01:30.26 |
starseeker |
realizes it's been a while since the last v8 branch
sync... |
| 01:55.11 |
CIA-14 |
BRL-CAD:
03starseeker * r36629 10/brlcad/branches/rel8/ (574 files in 42
dirs): Sync rel8 tree to trunk r36628 |
| 02:18.31 |
CIA-14 |
BRL-CAD:
03starseeker * r36630 10/brlcad/trunk/src/archer/TODO: Start
putting together a comparison list of MGED and Archer
functionality. |
| 02:19.22 |
*** join/#brlcad talcite
(n=matthew@69.165.141.234) |
| 02:25.14 |
talcite |
is there a
bug in our build script? |
| 02:25.30 |
talcite |
I'm getting a
compile error with mock, on a configuration that had worked
previously |
| 02:25.47 |
talcite |
mkdir -p
`dirname articles/en/images/tire_fig14.png` |
| 02:25.47 |
talcite |
XML_CATALOG_FILES=../../doc/docbook/catalog.xml
-nonet -xinclude -o articles/en |
| 02:25.47 |
talcite |
sl
articles/en/build_pattern.xml |
| 02:25.47 |
talcite |
/bin/sh:
-nonet: command not found |
| 02:26.08 |
talcite |
and then it
just goes downhill from there. The line doesn't seem to be valid
anyways |
| 02:26.14 |
``Erik |
I imagine
that means fop isn't being found, but it's trying to use it
anyways |
| 02:26.19 |
starseeker |
talcite: do
you have xsltproc? |
| 02:26.27 |
starseeker |
no that's the
xsltproc line |
| 02:26.27 |
``Erik |
beat
starseeker with a blunt instrument until it works again
:D |
| 02:26.42 |
starseeker |
you can
disable the extra documentation |
| 02:26.49 |
starseeker |
avoid all
that |
| 02:27.08 |
talcite |
starseeker: I
do have xslt |
| 02:27.16 |
talcite |
well libxslt
atleast |
| 02:27.41 |
starseeker |
you need the
command xsltproc |
| 02:27.47 |
``Erik |
it needs the
xsltproc binary |
| 02:27.53 |
talcite |
I just double
checked, I have the binary as well |
| 02:28.00 |
starseeker |
erm |
| 02:28.09 |
talcite |
hmm wait. I'm
building in a chroot jail |
| 02:28.14 |
starseeker |
check your
configure |
| 02:28.29 |
talcite |
yeah. Let me
see what's going on here. I didn't get any configure errors as far
as I know though |
| 02:29.11 |
talcite |
aww crap I
left my specfile on campus |
| 02:29.19 |
starseeker |
you may see a
warning about xsltproc not being found |
| 02:29.42 |
talcite |
hmm. give me
a sec |
| 02:30.08 |
starseeker |
that SHOULD
have turned off the docbook building, but it's even money the new
Makefile messed it up somehow... |
| 02:30.23 |
starseeker |
better than
even, actually |
| 02:30.42 |
talcite |
I'm not sure
the configure is actually testing for xsltproc |
| 02:30.55 |
talcite |
a grep on the
output log turns up nothing |
| 02:31.37 |
talcite |
besides,
shouldn't that line be better formed? It's not actually calling
xslt, it's calling -nonet, which shouldn't be valid |
| 02:32.01 |
starseeker |
the makefile
is triggering with the XSLTPROC variable empty |
| 02:32.08 |
talcite |
oh... |
| 02:32.17 |
talcite |
hmm, well the
configure output didn't say anything |
| 02:32.17 |
starseeker |
that's why
it's trying to execute that line - it's substituting "" for
XSLTPROC |
| 02:32.27 |
starseeker |
weird |
| 02:32.52 |
starseeker |
try
explicitly disabling the extra docs and see if that
works |
| 02:33.07 |
talcite |
can't. Left
the specfile on my laptop X) |
| 02:33.36 |
starseeker |
--disable-documentation to
configure |
| 02:33.42 |
starseeker |
oh |
| 02:33.48 |
starseeker |
ok, well when
you get a chance :-) |
| 02:34.13 |
starseeker |
can't imagine why it's not finding xsltproc if its in your
path... |
| 02:34.30 |
talcite |
it may be the
whole chroot building |
| 02:34.44 |
talcite |
I'm using
mock and I don't think I have libxslt in my
buildrequires |
| 02:34.52 |
starseeker |
ah |
| 02:34.58 |
talcite |
the previous
version built fine without it though. is this xml stuff
new? |
| 02:35.04 |
starseeker |
yeah, that
might be good to add if you want the extra docs :-) |
| 02:35.13 |
starseeker |
when's the
last time you built? |
| 02:35.27 |
talcite |
7.14 svn
head |
| 02:35.30 |
talcite |
sometime in
august |
| 02:35.32 |
starseeker |
erm |
| 02:35.49 |
starseeker |
there've been
extensive changes to the docbook build logic |
| 02:36.20 |
starseeker |
dunno how it
would have reacted before to your environment - might be worth a
test with the older version to see |
| 02:36.31 |
talcite |
well the
older ver works, that I'm sure of |
| 02:36.49 |
starseeker |
then the
older version saw xsltproc |
| 02:36.53 |
starseeker |
or quietly
ignored the docbook xml build |
| 02:37.15 |
talcite |
I see. Well
lets see what happens tomorrow. |
| 02:37.27 |
talcite |
I should
really set up an SVN repo or something for this |
| 02:37.28 |
starseeker |
nods |
| 02:37.45 |
talcite |
always
forgetting to sync my work |
| 02:39.20 |
starseeker |
best of luck
- if you run into a problem again tomorrow let us know and we'll
see if we can figure it out |
| 02:39.31 |
starseeker |
should get outta here... |
| 02:39.59 |
starseeker |
does - later all |
| 03:19.39 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 03:19.39 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 03:19.39 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 04:12.17 |
CIA-14 |
BRL-CAD:
03starseeker * r36631 10/brlcad/branches/dmtogl/ (configure.ac
doc/docbook/): Hrm, merging updates won't be so simple here. Take
the incremental approach. |
| 04:16.59 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 04:44.45 |
CIA-14 |
BRL-CAD:
03starseeker * r36632 10/brlcad/branches/dmtogl/: Ugh. Much faster
to just remove and merge in the togl specific stuff
again. |
| 04:45.57 |
CIA-14 |
BRL-CAD:
03starseeker * r36633 10/brlcad/branches/dmtogl/: Recreate the
dmtogl branch with latest trunk as a start |
| 05:09.45 |
CIA-14 |
BRL-CAD:
03starseeker * r36634 10/brlcad/branches/dmtogl/ (56 files in 6
dirs): Add back in initial togl related code. |
| 06:20.34 |
*** join/#brlcad Gabe_G23
(n=gabe@unaffiliated/GabeG23/x-028472) |
| 06:20.58 |
*** part/#brlcad Gabe_G23
(n=gabe@unaffiliated/GabeG23/x-028472) |
| 06:27.56 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 06:27.56 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 06:27.56 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 06:44.55 |
*** join/#brlcad talcite
(n=matthew@69-165-155-209.dsl.teksavvy.com) |
| 07:32.01 |
*** join/#brlcad talcite
(n=matthew@69-165-155-209.dsl.teksavvy.com) |
| 07:32.38 |
*** join/#brlcad talcite
(n=matthew@69-165-155-209.dsl.teksavvy.com) |
| 08:09.12 |
*** join/#brlcad talcite
(n=matthew@69-165-155-209.dsl.teksavvy.com) |
| 08:24.31 |
*** join/#brlcad talcite
(n=matthew@69-165-155-209.dsl.teksavvy.com) |
| 11:11.43 |
*** join/#brlcad mafm
(n=mafm@cpc2-bexl3-0-0-cust843.bmly.cable.ntl.com) |
| 11:58.32 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:27.31 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1962 10/wiki/NetMsgTypes: /* Common Header Byte Format
*/ |
| 14:03.26 |
``Erik |
starseeker:
rtgl seems to compile on fbsd7 |
| 14:04.38 |
starseeker |
``Erik:
cool |
| 14:04.42 |
starseeker |
does it
run? |
| 14:05.04 |
``Erik |
dunno |
| 15:47.18 |
``Erik |
hehehe "Linux
is for people who like to install stuff" |
| 16:35.46 |
CIA-14 |
BRL-CAD:
03davidloman * r36635 10/rt^3/trunk/ (15 files in 6 dirs): Mods to
netMsg inheritance. Added more a comprehensive tester. |
| 16:40.16 |
CIA-14 |
BRL-CAD:
03davidloman * r36636 10/rt^3/trunk/ (include/Utility/Utils.h
src/utility/ src/utility/Utils.cxx): Added Utils class. |
| 16:48.55 |
CIA-14 |
BRL-CAD:
03davidloman * r36637 10/rt^3/trunk/ (14 files in 2 dirs): Add
Generic*Msg classes for extensibility |
| 17:11.04 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1963 10/wiki/Failure: New page: {{DesignDocument}} ==Description==
[[IBME_GeometryService#NetMsg_Class|NetMsg]] that is a response to
a previously sent [[IBME_GeometryService#NetMsg_Class|NetMsg]]
subclass to inform the... |
| 17:11.12 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1964 10/wiki/NetMsgTypes: |
| 17:18.43 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1965 10/wiki/NetMsgTypes: /* NetMsg MsgTypes */ |
| 17:22.22 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1966 10/wiki/Success: Testing the Summary field for
CIA |
| 17:24.10 |
d-lo |
brlcad: I got
a policeman hold up in a building, offing zombies like its going
out of style. Me thinkgs I might make, or even break, your 77
zombies per cop ratio! |
| 17:35.25 |
d-lo |
Woot! 103.75
zpc average :) |
| 17:43.40 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1967 10/wiki/NetMsgTypes: Added Generic*Msg Template
linkage |
| 17:56.50 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1968 10/wiki/GenericOneByteMsg: Added Description |
| 17:56.52 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1969 10/wiki/GenericTwoBytesMsg: Added Description |
| 17:56.55 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1970 10/wiki/GenericFourBytesMsg: Added Description |
| 17:56.59 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1971 10/wiki/GenericOneStringMsg: Added Description |
| 17:57.06 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1972 10/wiki/GenericMultiByteMsg: Added Description |
| 18:04.25 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1973 10/wiki/NetMsgTypes: Added links to
IBME_NETWORKPROTO_STRING |
| 18:05.17 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1974 10/wiki/GenericOneStringMsg: Added links to
IBME_NETWORKPROTO_STRING |
| 18:08.30 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1975 10/wiki/IBME_NETWORKPROTO_STRING: Added page for
'String' |
| 18:22.06 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1976 10/wiki/RemHostNameSET: Fixed Typo and added link to
IBME_NETWORKPROTO_STRING |
| 18:25.39 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1977 10/wiki/NewHostOnNetINFO: Modifed Byte Format |
| 18:31.22 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1978 10/wiki/GeometryREQ: Added link to Generic |
| 18:35.05 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1979 10/wiki/GeometryCHUNK: Added links to Generics |
| 18:37.40 |
d-lo |
Nice 136.00
zpc. |
| 18:38.46 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1980 10/wiki/NewHostOnNetINFO: Added links to Generics |
| 18:40.46 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1981 10/wiki/NewSession: Added new page for
NewSessionMsg |
| 18:43.42 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1982 10/wiki/FullHostListREQ: Added page for
FullHostListREQMsg |
| 18:48.49 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1983 10/wiki/FullHostList: Added page for
FullHostListMsg |
| 18:50.29 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1984 10/wiki/NetMsgTypes: Drop INFO from name. |
| 18:52.18 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1985 10/wiki/NewHostOnNet: Added new Page for
NewHostOnNetMsg |
| 18:52.41 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[NewHostOnNetINFO]]": Renamed
to NewHostOnNet |
| 18:55.40 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1986 10/wiki/Failure: Added references to Generics. |
| 18:56.24 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1987 10/wiki/Success: Added references to Generics |
| 18:56.30 |
d-lo |
go go gadget
wiki editing! |
| 18:58.22 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1988 10/wiki/RemHostNameSET: Added references to
Generics |
| 18:59.54 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1989 10/wiki/NewHostOnNet: Clarified field usage. |
| 19:01.11 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1990 10/wiki/NewSession: Clarified field usage. |
| 19:02.26 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1991 10/wiki/GeometryREQ: Clarified field usage. |
| 19:02.54 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1992 10/wiki/GeometryCHUNK: Clarified field usage. |
| 19:05.24 |
CIA-14 |
BRL-CAD:
03davidloman * r36638 10/rt^3/trunk/src/tests/java/: Removing old
Java classes. Antiquated and unused. |
| 19:05.58 |
CIA-14 |
BRL-CAD:
03davidloman * r36639
10/rt^3/trunk/include/GS/netMsg/RemHostNameSetFailMsg.h: Missed
this remnant of latest refactor. |
| 19:14.07 |
CIA-14 |
BRL-CAD:
03davidloman * r36640 10/rt^3/trunk/ (4 files in 4 dirs): Implement
SuccessMsg |
| 19:14.33 |
``Erik |
zpc? |
| 19:16.06 |
CIA-14 |
BRL-CAD:
03Dloman 07http://brlcad.org *
r1993 10/wiki/NetMsgTypes: |
| 19:16.12 |
d-lo |
Zombies Per
Cop |
| 19:16.15 |
d-lo |
kill
ratio |
| 19:16.17 |
d-lo |
:) |
| 19:16.21 |
``Erik |
ah |
| 19:16.34 |
CIA-14 |
BRL-CAD:
03starseeker * r36641 10/brlcad/trunk/ (12 files in 12 dirs):
Update svn:ignore in a variety of places |
| 19:16.48 |
d-lo |
I've got
rambo goihnng right now. 1 cop vs 15.5k zombies. |
| 19:19.35 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 19:19.54 |
CIA-14 |
BRL-CAD:
03starseeker * r36642 10/brlcad/trunk/doc/docbook/system/man1/en/:
Oh yeah, .1 man pages too. |
| 19:22.39 |
CIA-14 |
BRL-CAD:
03starseeker * r36643 10/brlcad/branches/dmtogl/ (12 files in 12
dirs): Update ignore settings in dmtogl branch |
| 19:31.17 |
d-lo |
lol 234.375
zpc. Rambo finally died a horrible death. |
| 19:31.52 |
``Erik |
url
again? |
| 19:32.58 |
d-lo |
http://www.class3outbreak.com/zombie-outbreak-simulator/ |
| 19:34.44 |
``Erik |
exception id
2134 name: error message: error #2134 function
onApplicationComplete Step: j ... :/ |
| 19:35.35 |
d-lo |
bummer
:/ |
| 19:35.46 |
d-lo |
Have a happy
t-day all! |
| 20:06.38 |
*** join/#brlcad mafm_
(n=mafm@cpc2-bexl3-0-0-cust843.bmly.cable.ntl.com) |
| 20:11.51 |
``Erik |
starseeker:
http://www.the-blueprints.com/blueprints/ |
| 20:36.31 |
starseeker |
``Erik: heh,
cool. yeah, the problem with that site is it doesn't have a clear
licensing policy that I can see |
| 20:43.28 |
``Erik |
*shrug* saw
it on hn, figured I'd share |
| 20:58.30 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.227.125) |
| 21:32.47 |
brlcad |
hah, that is
fantastic .. d-lo .. zombies starting: 2000 civilians: 1000 ..
all converted (because none could shoot).. |
| 21:33.07 |
brlcad |
zombies
remaining: 64 .. 1 cop kill count: 2937 :) |
| 21:33.55 |
brlcad |
er, 63
:) |
| 21:53.02 |
CIA-14 |
BRL-CAD:
03starseeker * r36644 10/brlcad/branches/dmtogl/ (4 files in 2
dirs): More dmtogl tweaking and setup. |
| 21:56.56 |
CIA-14 |
BRL-CAD:
03brlcad * r36645 10/brlcad/trunk/src/libfft/ (Makefile.am
ditsplit.c): ws indent cleanup, increased precision on sqrt
defines |
| 21:58.14 |
CIA-14 |
BRL-CAD:
03brlcad * r36646 10/brlcad/trunk/src/libfft/ditsplit.c: get rid of
globals |
| 22:01.53 |
CIA-14 |
BRL-CAD:
03brlcad * r36647 10/brlcad/trunk/src/libfft/ (ditsplit.c
ditsplitc.c): sync up similar ws changes |
| 22:31.08 |
CIA-14 |
BRL-CAD:
03brlcad * r36648 10/brlcad/trunk/src/libfft/fftfast.c: use M_PI
instead of PI and clean up ws/indent in the process. |
| 22:32.08 |
CIA-14 |
BRL-CAD:
03brlcad * r36649 10/brlcad/trunk/src/libfft/ditsplitc.c: these
globals are referenced by the application front-end for printing a
summary status, so they have to be global or passed in. |
| 22:34.33 |
CIA-14 |
BRL-CAD:
03brlcad * r36650 10/brlcad/trunk/src/libfft/fft.h: provide math.h
and M_PI for everyone |
| 22:35.26 |
*** join/#brlcad Ralith
(n=ralith@d142-058-085-103.wireless.sfu.ca) |
| 22:35.26 |
CIA-14 |
BRL-CAD:
03brlcad * r36651 10/brlcad/trunk/src/libfft/fftfast.c: moved M_PI
to fft.h |
| 22:35.38 |
*** join/#brlcad R0b0t1
(n=Enigma@64.136.216.213) |
| 22:36.37 |
CIA-14 |
BRL-CAD:
03brlcad * r36652 10/brlcad/trunk/src/libfft/ (fftc.c fftest.c
ifftc.c splitditc.c): oops, looks like strict flags were already
committed enabled. quell strict compilation warnings. |
| 22:40.19 |
CIA-14 |
BRL-CAD:
03brlcad * r36653 10/brlcad/trunk/src/libfft/ (ditsplit.c
ditsplitc.c fft.h splitdit.c splitditc.c): use fft.h for INVSQ2 and
SQRT2 too |
| 22:42.40 |
CIA-14 |
BRL-CAD:
03brlcad * r36654 10/brlcad/trunk/src/libfft/ (ditsplit.c
ditsplitc.c fft.h splitdit.c splitditc.c): use the standard defines
M_SQRT1_2 and M_SQRT2 instead of previous |
| 22:45.07 |
brlcad |
woo hoo,
another strict lib |
| 22:45.17 |
CIA-14 |
BRL-CAD:
03brlcad * r36655 10/brlcad/trunk/src/libfft/ (ditsplitc.c
splitditc.c): use fft.h instead of hard-wiring the
value |
| 22:47.54 |
CIA-14 |
BRL-CAD:
03brlcad * r36656 10/brlcad/trunk/src/libfft/fftest.c: remove
embedded pi value |
| 22:49.58 |
CIA-14 |
BRL-CAD:
03starseeker * r36657 10/brlcad/trunk/ (7 files in 2
dirs): |
| 22:49.58 |
CIA-14 |
BRL-CAD: Wrap
up all the boilerplate for the dm template declarations into a
macro, |
| 22:49.58 |
CIA-14 |
BRL-CAD:
except in the case of Windows where the type signatures are
different - is this |
| 22:49.58 |
CIA-14 |
BRL-CAD: a
requirement of the Visual Studio compiler? Anyway, simplify the
process of |
| 22:49.58 |
CIA-14 |
BRL-CAD:
syncing this across multiple dms. |
| 23:00.34 |
CIA-14 |
BRL-CAD:
03brlcad * r36658 10/brlcad/trunk/src/liborle/rle.c: ws indent
style cleanup |
| 23:03.51 |
CIA-14 |
BRL-CAD:
03starseeker * r36659 10/brlcad/branches/dmtogl/src/other/togl/ (.
configure): Minor cleaups of togl within svn tree. |
| 23:04.37 |
CIA-14 |
BRL-CAD:
03brlcad * r36660 10/brlcad/trunk/src/liborle/ (Makefile.am rle.c):
quell single verbose warning about unreached code (due to constant
and macro expansion), enable strict compilation |
| 23:05.10 |
CIA-14 |
BRL-CAD:
03starseeker * r36661 10/brlcad/branches/dmtogl/src/other/togl/:
More svn:ignore togl tweaks. |
| 23:07.12 |
CIA-14 |
BRL-CAD:
03brlcad * r36662 10/brlcad/trunk/src/libpkg/ (Makefile.am tcl.c):
quell unused var warning, enable strict compilation. clean compile
at least mac. |
| 23:10.04 |
CIA-14 |
BRL-CAD:
03starseeker * r36663 10/brlcad/branches/dmtogl/ (21 files in 5
dirs): Grab the libdm changes from trunk, pull other updates as
long as we're doing it. |
| 23:11.06 |
brlcad |
mmmm.palindrome.emordnilap.mmmm |
| 23:11.24 |
starseeker |
hehe |
| 23:13.54 |
``Erik |
dang
bastages, makin' a mess of the code |
| 23:16.32 |
CIA-14 |
BRL-CAD:
03brlcad * r36664 10/brlcad/trunk/src/libpkg/pkg.c: |
| 23:16.32 |
CIA-14 |
BRL-CAD:
quell a handful of verbose/c99-strict compilation warnings
including avoiding |
| 23:16.32 |
CIA-14 |
BRL-CAD:
fileno(), skipping the superset isascii() test used with isprint(),
and avoiding |
| 23:16.32 |
CIA-14 |
BRL-CAD:
using caddr_t (tested on linux and mac to just cast to void*
instead) |
| 23:17.12 |
brlcad |
cool, 7 lib
dirs now compile strict c99 with full warnings |
| 23:17.19 |
starseeker |
sweeet |
| 23:18.10 |
starseeker |
``Erik: you
could always bring your two experts into play and have them walk on
the keyboard ;-) |
| 23:18.20 |
``Erik |
hah |
| 23:18.23 |
``Erik |
nah |
| 23:18.39 |
``Erik |
don't wanna
give you competition ;> *duck* |
| 23:19.26 |
CIA-14 |
BRL-CAD:
03brlcad * r36665 10/brlcad/trunk/src/libtermio/ (Makefile.am
termio.c): quell all verbose compilation warnings, enable strict
flags |
| 23:19.33 |
starseeker |
looks active but is mostly cleaning up svn:ignore and syncing
branches before the holiday - brlcad's the one doing real
damage |
| 23:20.11 |
starseeker |
took your
macro idea for a test spin |
| 23:20.23 |
``Erik |
hm, I imagine
there'll be like 3 people in the building on friday, so'z probably
not going to lunch that day *does finances* |
| 23:23.29 |
CIA-14 |
BRL-CAD:
03brlcad * r36666 10/brlcad/trunk/src/libtermio/termio.c: ws,
indent, style cleanup |
| 23:25.19 |
CIA-14 |
BRL-CAD:
03starseeker * r36667 10/brlcad/branches/rel8/ (36 files in 18
dirs): Sync rel8 to latest trunk, mostly to get the svn:ignore
stuff. |
| 23:44.00 |
CIA-14 |
BRL-CAD:
03brlcad * r36668 10/brlcad/trunk/src/libdm/dm-ogl.c: restructure
to avoid all forward declarations as an example for the other
DMs |
| 23:48.28 |
CIA-14 |
BRL-CAD:
03brlcad * r36669 10/brlcad/trunk/src/libdm/dm-ogl.c: more
restructuring to remove a couple other forward decls, clean up
comments/indent/ws |
| 23:50.12 |
CIA-14 |
BRL-CAD:
03brlcad * r36670 10/brlcad/trunk/src/libdm/dm-ogl.c: egads,
shouldn't set vars to HIDDEN .. that static keyword means something
else... |
| 23:50.55 |
CIA-14 |
BRL-CAD:
03brlcad * r36671 10/brlcad/trunk/include/dm.h: quell
warning |
| 23:56.36 |
``Erik |
still get
compile errors(warnings) in libgcv O.o |
| 23:58.04 |
CIA-14 |
BRL-CAD:
03brlcad * r36672 10/brlcad/trunk/src/libdm/dm-wgl.c: those are
wrong! .. bad HIDDEN, need to be static. |
| 00:00.06 |
brlcad |
still calls it carbon :) |
| 00:00.23 |
jack2 |
hehe,
np |
| 00:00.44 |
jack2 |
wonder if i
should do an x11 variant too maybe |
| 00:00.53 |
brlcad |
variant? |
| 00:01.03 |
jack2 |
yeah, 2
packages |
| 00:01.10 |
jack2 |
brlcad and
brlcad-x11 |
| 00:01.11 |
brlcad |
what's the
non-x11 variant? |
| 00:01.31 |
jack2 |
trying to use
as little of x11 as possible ;) |
| 00:02.06 |
brlcad |
brlcad
without x11 is interesting and should certainly be possible (I had
a clean non-x11 build verified a couple months back) but you get
little/no GUI then |
| 00:02.20 |
jack2 |
mmh |
| 00:02.25 |
jack2 |
mged,
right? |
| 00:02.33 |
brlcad |
right, you'd
get a console-only mged |
| 00:02.48 |
brlcad |
you'd still
get mged, just command-line only |
| 00:02.49 |
jack2 |
ok, that's
pointless indeed |
| 00:02.58 |
jack2 |
almost
pointless at least |
| 00:03.17 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 00:03.26 |
brlcad |
if you're
already familiar with brl-cad, it's not pointless, but that's less
than 1% of our usual users :) |
| 00:03.34 |
jack2 |
exactly |
| 00:03.35 |
brlcad |
most are
new |
| 00:03.56 |
brlcad |
otherwise,
there's a helluvalot you can do with the other 400
tools |
| 00:04.11 |
jack2 |
sure
:) |
| 00:04.31 |
jack2 |
wonder if i
should hide all the stuff in a private bindir... |
| 00:04.47 |
jack2 |
people might
hate me for spamming %p/bin ;) |
| 00:05.34 |
brlcad |
probably a
good idea ;) |
| 00:05.34 |
brlcad |
better yet,
install the entire root to a private dir |
| 00:05.51 |
jack2 |
what's wrong
with macosx' zlib? (why does it build an own one?) |
| 00:06.30 |
brlcad |
nothing
should be wrong with it |
| 00:07.17 |
``Erik |
for fbsd, I
use system provided zlib. libpng, tk and tcl |
| 00:07.17 |
brlcad |
if you added
--disable-all, it should force everything off |
| 00:07.30 |
``Erik |
um, and jama
and uhhh |
| 00:07.32 |
``Erik |
other stuff
:D |
| 00:07.32 |
jack2 |
libpng
works |
| 00:07.43 |
jack2 |
but it builds
an own zlib and tcl+tk |
| 00:08.16 |
``Erik |
hm,
/usr/lib/libz.dylib might be a little fruity, might need finks
zlib |
| 00:08.28 |
brlcad |
tcl/tk make
sense, os x doesn't ship an incrTcl so it has to use ours and ours
requires 8.5 which is newer than the os x default |
| 00:08.31 |
jack2 |
we don't
provide zlib anymore |
| 00:08.41 |
jack2 |
system one is
good enough :) |
| 00:08.51 |
jack2 |
(normally,
that is) |
| 00:09.08 |
``Erik |
investigate
the config.log and stuff to see why zlib fails to
autodetect? |
| 00:09.24 |
``Erik |
our check
might be too aggressive |
| 00:09.28 |
jack2 |
brlcad: yup,
i don't mind getting a fresh tcltk8.5 with itcl/itk of
course |
| 00:09.35 |
jack2 |
only zlib is
odd |
| 00:09.36 |
brlcad |
but that's
still assuming you're letting it auto-detect -- you shouldn't be
getting autodetection behavior if you used
--disable-almost-everything |
| 00:09.48 |
jack2 |
ok...will
check |
| 00:10.05 |
brlcad |
or
--disable-all or whatever aliases |
| 00:10.15 |
jack2 |
brlcad: nope,
i did --enable-a-e and --disable-jove-build |
| 00:10.18 |
brlcad |
should say
'no' down the summary list |
| 00:10.22 |
brlcad |
a-e
? |
| 00:10.27 |
brlcad |
all |
| 00:10.29 |
jack2 |
almost
everything |
| 00:10.40 |
``Erik |
hm, "Linux
OpenRD 2.6.22.18-dirty #1 Sat Aug 29 15:18:06 IST 2009 armv5tejl
armv5tejl armv5tejl GNU/Linux" |
| 00:10.42 |
brlcad |
enable-almost-everything forces everything
to build |
| 00:10.49 |
brlcad |
all external
dependencies |
| 00:11.08 |
brlcad |
you want the
opposite for fink, disable everything |
| 00:11.17 |
jack2 |
d'oh, but why
does it like my external libpng then... :) |
| 00:11.23 |
brlcad |
"disable our
compilation of [whatever]" |
| 00:11.46 |
brlcad |
yeah, that's
not right.. |
| 00:11.55 |
jack2 |
just
odd |
| 00:12.16 |
brlcad |
sounds like a
build system bug, but would need to see your config.log |
| 00:12.18 |
brlcad |
can you post
it? |
| 00:12.23 |
jack2 |
i don't
really mind, zlib is really small |
| 00:12.26 |
jack2 |
but
funny |
| 00:12.40 |
jack2 |
brlcad: ok,
hold on a sec |
| 00:13.01 |
brlcad |
well zlib
makes more sense given you used --enable-all |
| 00:13.05 |
brlcad |
it's
enabled |
| 00:13.11 |
brlcad |
they mystery
is libpng |
| 00:13.26 |
brlcad |
or anything
else that was a 'no' in the summary |
| 00:14.12 |
``Erik |
the blue
power ld is bright as hell, I might need to stick a piece of
masking tape over it or solder a resister in there |
| 00:14.47 |
jack2 |
brlcad:
http://85.180.98.251/config.log |
| 00:15.52 |
jack2 |
the CPPFLAGS
are nonsense of course, ignore that -framework OpenGL |
| 00:16.57 |
brlcad |
404 |
| 00:17.41 |
jack2 |
indeed...wtf |
| 00:17.45 |
jack2 |
one
sec |
| 00:18.26 |
``Erik |
heh, / on
that site is 404, too |
| 00:19.38 |
jack2 |
ok, now it
works |
| 00:19.41 |
jack2 |
sorry |
| 00:21.53 |
brlcad |
don't
understand something, your config.log says libpng will be
built |
| 00:22.05 |
brlcad |
everything
will be built, except jove |
| 00:22.09 |
brlcad |
which is
right |
| 00:23.23 |
jack2 |
hrm |
| 00:25.02 |
brlcad |
--enable-aquatk-build shouldn't do
anything useful, and you shouldn't --enable-rtgl just yet unless
you plan on coding :) |
| 00:25.25 |
brlcad |
it works
great, but not something to spring on the fink masses just yet, few
issues to work out |
| 00:27.03 |
jack2 |
hehe
ok |
| 00:29.52 |
jack2 |
woop,
failure |
| 00:30.04 |
brlcad |
orly? |
| 00:30.07 |
jack2 |
linking
.libs/libstepeditor.19.dylib is missing some symbols |
| 00:30.18 |
brlcad |
o.O |
| 00:30.31 |
jack2 |
ld: Undefined
symbols: |
| 00:30.31 |
jack2 |
__ZN18SDAI_DAObject_SDAIC2Ev |
| 00:30.31 |
jack2 |
__ZN18SDAI_DAObject_SDAID2Ev |
| 00:30.31 |
jack2 |
__ZTI18SDAI_DAObject_SDAI |
| 00:31.47 |
brlcad |
where was it
in the build? |
| 00:32.07 |
brlcad |
in
src/other/step or in src/conv/step ? |
| 00:32.37 |
jack2 |
other/step |
| 00:32.54 |
brlcad |
those
SDAI_DAObject_SDAI symbols are in a diff lib |
| 00:33.31 |
brlcad |
so the
question is, what was it linking that it'd care and was that other
lib on the link line |
| 00:34.48 |
jack2 |
other lib?
hold on, i'll lisppaste the whole link line |
| 00:35.35 |
brlcad |
ah.. hm,
found a problem I think |
| 00:35.58 |
brlcad |
looks like
some vars were renamed, bizarre that it wasn't caught on other mac
systems |
| 00:36.23 |
jack2 |
http://paste.lisp.org/+1YL5 |
| 00:38.15 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 00:38.48 |
CIA-41 |
BRL-CAD:
03brlcad * r36778
10/brlcad/trunk/src/other/step/src/cleditor/Makefile.am: curiously,
still using the CL* vars instead of what configure.ac is providing.
link failure generating resolved dylib. |
| 00:38.55 |
brlcad |
ahhhh....
hrm |
| 00:39.02 |
brlcad |
step has it's
own configure.ac |
| 00:39.04 |
``Erik |
heh, a lisp
weenie |
| 00:39.05 |
brlcad |
oops |
| 00:39.16 |
jack2 |
brlcad: maybe
that stupid libtool default sneaked in on other macs? |
| 00:39.39 |
jack2 |
(-Wl,-undefined,dynamic_lookup or
suppress) |
| 00:40.46 |
CIA-41 |
BRL-CAD:
03brlcad * r36779
10/brlcad/trunk/src/other/step/src/cleditor/Makefile.am: oops, SCL
has its own configure.ac, use the CL-prefixed vars (most
importantly adding/keeping libdai) |
| 00:41.51 |
brlcad |
these other
systems are stock, we re-repair the libtool script if it detects
badness but the error in this case is warranted for fully resolved
libs.. but I bet there will be other issues |
| 00:42.35 |
brlcad |
was the
-all_load dumbness in the libtool script |
| 00:43.02 |
jack2 |
yeah, i'm
glad you remove that crap yourself meanwhile :) |
| 00:44.09 |
brlcad |
hm, but you
know I bet that's the issue.. SCL has it's own configure, it's own
libtool script |
| 00:45.16 |
jack2 |
something not
propagating right? |
| 00:45.42 |
brlcad |
maybe |
| 00:45.48 |
jack2 |
modularity
isn't bad...as long as the parts know how to talk to each other
;) |
| 00:47.33 |
brlcad |
if you diff
libtool src/other/step/libtool, what do you see? |
| 00:47.45 |
brlcad |
just a
generated and temp_rpath line or more? |
| 00:48.41 |
brlcad |
regardless,
the fix "should" be to edit src/other/step/Makefile.am and add
${CLDAI} \ to the LIBADD section |
| 00:49.13 |
brlcad |
er,
src/other/step/cleditor/Makefile.am |
| 00:49.57 |
brlcad |
cd
src/other/step/cleditor && make LIBS='${CLDAI}' might
work.. :) |
| 00:50.03 |
brlcad |
as an
alternative |
| 00:52.52 |
CIA-41 |
BRL-CAD:
03brlcad * r36780 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
more quellage via data validation |
| 00:58.02 |
``Erik |
looks for a serial cable O.o |
| 01:07.42 |
CIA-41 |
BRL-CAD:
03brlcad * r36781 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
quell the rest of the ARS warnings. log shadow and unused parameter
validation. |
| 01:09.24 |
CIA-41 |
BRL-CAD:
03brlcad * r36782 10/brlcad/trunk/include/raytrace.h: quell
unreachable code warnings for callers of RT_HIT_NORMAL() when
either the normal is NULL or the flip flag is a constant. we squash
the warnage by setting to a locally scoped temp var. |
| 01:12.48 |
jack- |
brlcad: ok,
thx |
| 01:13.51 |
brlcad |
hits the road for a bit |
| 07:45.54 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
| 08:24.08 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 08:24.59 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 08:48.35 |
d_rossberg |
i had the
following problem: |
| 08:48.50 |
d_rossberg |
- created a
(empty) group |
| 08:49.15 |
d_rossberg |
- selected
this group (rt_gettree) |
| 08:49.47 |
d_rossberg |
- created a
region with a solid and put it into the group |
| 08:50.49 |
d_rossberg |
- now
rt_shootray won't find anything |
| 08:52.08 |
d_rossberg |
ist this
behavior intended? (i.e. rt_gettree has to be called after all has
been created) |
| 10:14.14 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149CAF.dip.t-dialin.net) |
| 11:17.28 |
d-lo |
Mornin
all! |
| 11:52.35 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 11:52.35 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 11:52.35 |
*** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 11:52.35 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 11:52.35 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 11:52.35 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 11:52.35 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 11:52.35 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 11:54.27 |
*** join/#brlcad d_rossberg (n=rossberg@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 11:54.42 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 11:58.50 |
*** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 12:00.31 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 12:03.16 |
*** join/#brlcad erik__
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 12:34.30 |
d-lo |
Mornin
``Erik |
| 12:34.39 |
d-lo |
get your lil
puter last night? |
| 13:30.00 |
CIA-41 |
BRL-CAD:
03davidloman * r36783 10/rt^3/trunk/geoserve.config: Add basic
configuration file. |
| 13:30.14 |
CIA-41 |
BRL-CAD:
03davidloman * r36784 10/rt^3/trunk/ (include/GS/GeometryService.h
src/GS/GeometryService.cxx): Override ::exec() from
QCoreApplication to allow object level init prior to entering main
event loop. |
| 13:33.49 |
``Erik |
yup |
| 13:33.59 |
``Erik |
pasted uname,
even |
| 13:34.18 |
d-lo |
'pasted
uname' ? |
| 13:34.50 |
``Erik |
yeah, scroll
up... I lost it due to a poweroutage overnight :/ |
| 13:37.09 |
d-lo |
Suckage.
When I got up at 0400, the wind was howling and power was
flickering... but it stayed on. How long was yours out
for? |
| 13:38.49 |
``Erik |
long enough
to sap the UPS, but I had 3 machiens on it |
| 13:39.20 |
``Erik |
fortunately,
I wake up at the same time every day, alarm or not :) |
| 13:40.33 |
d-lo |
Ditto about
the alarm. Sucks on weekends though. I don't think I have slept
in since High School. |
| 13:40.54 |
d-lo |
Now when the
power went out, did the OpenRD machine get messed up? |
| 13:43.08 |
``Erik |
nah, it was
messed up before :D |
| 13:43.21 |
d-lo |
lol |
| 13:43.49 |
d-lo |
Messed up
upon arrival, or did it get messed up by operator? ;) |
| 13:43.49 |
``Erik |
rendered it
unbootable before I went to sleep, uses a fruity uboot thing that
isn't geared to do anything but boot linux off of the flash NAND
memory |
| 13:44.18 |
``Erik |
so I was
trying to coerce it with a different boot command to attempt to
bring up the USB subsystem and try passing control off to a
drive |
| 13:44.29 |
``Erik |
have to do it
all via serial console to boot, fun stuff |
| 13:44.45 |
d-lo |
Ah, hence the
serial cable search. |
| 13:44.48 |
d-lo |
didja find
one? |
| 13:44.55 |
``Erik |
might take a
week or two before I coerce it into booting bsd |
| 13:45.03 |
``Erik |
um, usb to
the jtag faking it |
| 13:45.45 |
d-lo |
I have a box
full o junk and I am sure I have a handful of subd-9's in there if
you need one. |
| 13:46.43 |
``Erik |
the usb
solution works pretty well, just have to remember to force to
program to go to 115200 baud, 8 bit, 1 stop bit and no flow
control |
| 13:46.46 |
``Erik |
dang
settings |
| 13:47.19 |
``Erik |
at the
moment, it spools around, starts the usb subsystem, scans, looks
for usb storage devices, complains about bad magic and
reboots |
| 13:47.51 |
d-lo |
did it come
with some 'software' to 'flash' it back to normal via
serial? |
| 13:48.00 |
``Erik |
<-- half
wondering if he could stomach using linux in that role |
| 13:48.19 |
``Erik |
um, there's a
recovery image on the dvd, not sure what exactly it
does |
| 13:49.06 |
d-lo |
I was just
thinking that establishing the ability to restore it to 100%
bootable again would be a good backup plan to have. |
| 13:49.10 |
``Erik |
or how to use
it o.O it's slightly bigger than I estimated, too, but still quite
small |
| 13:49.22 |
``Erik |
where's the
adventure in that??? |
| 13:49.32 |
d-lo |
isnt it like
6x8x1 inches? |
| 13:49.50 |
``Erik |
porbably
about, I was thinking it was more like 4x6x1 for some
reason |
| 13:50.04 |
``Erik |
from looking
at the end panel and trying to guess... shoulda looked at the
numbers :) |
| 13:50.12 |
d-lo |
Heh, well if
adventure gives me a soildstate paperwieght, I'll take safe and
sound anyday :) But then again, I pinch pennies. |
| 13:51.35 |
``Erik |
I haven't
tried writing a new uboot image yet, trying to do this with
adjusting settings, and I'm writing down the old settings as I go
*shrug* |
| 13:52.51 |
d-lo |
how much Ram
does it have 512? |
| 13:53.18 |
``Erik |
yup, 512 ram,
4g NAND flash, 1.2ghz sheeva (roughly like an 800mhz p3), no
fpu |
| 13:53.41 |
d-lo |
whoa, 4GB of
NAND flash? neato. |
| 13:54.23 |
``Erik |
and the dvd
has all sorts of neat shit... schematics, PCB layout diagrams,
... |
| 13:54.32 |
``Erik |
this ain't no
dell :D |
| 13:54.54 |
d-lo |
I wonder if
you could get windows to boot off it, lol |
| 13:55.23 |
``Erik |
given that
windows only supports x86 (used to support alpha, but tha went away
with nt4), I'd say...... no? :) |
| 13:55.54 |
d-lo |
You killjoy
you. |
| 13:56.15 |
d-lo |
What about
MacOS X? Could you make a mini-mini? |
| 13:56.28 |
``Erik |
nope, osX
only rusn on ppc and intel |
| 13:56.31 |
``Erik |
http://en.wikipedia.org/wiki/ARM_architecture |
| 13:57.29 |
d-lo |
didnt some of
the older flavors of Mac OS support RISC procs? |
| 13:57.38 |
``Erik |
ppc is a
risc |
| 13:58.06 |
``Erik |
68k was
cisc |
| 13:58.42 |
``Erik |
<-- keeps
entertaining the notion of buying a 68040 and building a small
machine out of it, then writing an oldschool *nix os on
it |
| 13:59.03 |
d-lo |
...but....
why? |
| 13:59.07 |
d-lo |
=D |
| 13:59.19 |
``Erik |
fun... and to
jog my memory of the fun old days |
| 14:00.46 |
d-lo |
Oh, did you
find any docs on power consumption? |
| 14:01.05 |
``Erik |
um, didn't
erally look |
| 14:01.32 |
d-lo |
Just curious
as to what Idle->Full load power ramp up looks like. |
| 14:01.51 |
``Erik |
Average power
consumption is around 7.2W. Maximum power consumption measured with
all 7 USB |
| 14:01.54 |
``Erik |
ports, HDD
and Ethernet operational is 29.9W. In idle state system draws power
of |
| 14:01.57 |
``Erik |
around
4.8W. |
| 14:02.34 |
d-lo |
30W on 12Vdc
= ~ 2.5 amps. Notbad. |
| 14:02.53 |
``Erik |
I imagine a
significant portion of that is the hard drive |
| 14:03.15 |
d-lo |
There is a HD
in the lil box too??? |
| 14:03.16 |
d-lo |
wow |
| 14:03.27 |
``Erik |
or perhaps
the usb devices being used... my thumbdrive draws 200mw, where the
external drive has a power supply ad draws 2mw |
| 14:03.35 |
``Erik |
well, not in
i t, just the flash, but it has esata |
| 14:03.57 |
``Erik |
I haven't
taken it apart yet, supposedly there's not enough space to fit a
2.5" drive |
| 14:04.16 |
d-lo |
not too
familiar with eSata, actually. I take it eSata cables also provide
power to the device, akin to USB? |
| 14:04.24 |
``Erik |
no
clue |
| 14:05.32 |
d-lo |
Great. Some
contractors outside my window are putting in ear plugs... this
can't be a good sign. :/ |
| 14:05.41 |
``Erik |
looks out O.o |
| 14:05.55 |
``Erik |
they have a
circular saw of some kind |
| 14:06.08 |
d-lo |
...and a
score to settle... |
| 14:37.23 |
brlcad |
d_rossberg:
that sounds like expected behavior |
| 14:37.35 |
brlcad |
you probably
just need to call rt_gettree again |
| 14:37.50 |
brlcad |
you should be
able to call it repeatedly |
| 14:38.37 |
brlcad |
(man librt
for some additional details) |
| 14:39.00 |
brlcad |
gettree loads
the geometry, so if it's modified, it needs to be
reloaded |
| 15:02.37 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 15:12.40 |
d_rossberg |
brlcad: ok,
i've already changed my code, i only wanted to be sure that it's
ok |
| 15:13.04 |
brlcad |
okay |
| 15:14.15 |
jack- |
``Erik: you
could even buy an old amiga3000 and put an 68060 card
in |
| 15:14.28 |
jack- |
those were
pretty fast back then ;) |
| 15:14.29 |
brlcad |
depending on
how you created/added the new prim/region, it's probably possible
to avoid the rt_gettrees again |
| 15:15.07 |
brlcad |
but at some
point the data has to be read (whether from disk or inmem).. and
that's presently gettrees job |
| 15:15.49 |
d_rossberg |
i used my c++
interface from rt^3 |
| 15:16.23 |
d_rossberg |
it is very
low-level internally |
| 15:16.30 |
brlcad |
really
wanting to get bu, bn, pkg, and rt fully cleaned up as stand-alone
APIs with cleanly generating doxygen reports, so questions like
this are answered more clearly |
| 15:16.35 |
brlcad |
yeah, I
figured |
| 15:17.01 |
brlcad |
which is
great, keeps things honest |
| 15:17.22 |
brlcad |
plan on
hitting that section of code up next, for the GE |
| 15:17.26 |
brlcad |
after all
this cleanup |
| 15:18.16 |
brlcad |
and
annotations, which I'm heartily behind on :/ |
| 15:18.38 |
d_rossberg |
yeah, and
solving the brlcadversion.h-question ;) |
| 15:18.47 |
brlcad |
yep! |
| 15:19.00 |
brlcad |
200 message
in my mailbox that *require* a response.. that's one of them
:) |
| 15:19.30 |
brlcad |
(not all
brl-cad related, of course) :) |
| 15:19.58 |
brlcad |
oh, right, I
got through a bunch.. down to just 87 today |
| 15:22.32 |
d_rossberg |
i have 5 more
primitives half-finished ... since April |
| 15:25.58 |
brlcad |
which
five? |
| 15:28.00 |
brlcad |
and what does
"half-finished" mean? they load but don't ray-trace or the API is
missing or ...? |
| 15:29.17 |
d_rossberg |
EllipticalTorus, HyperbolicCylinder,
Hyperboloid, ParabolicCylinder and Paraboloid |
| 15:29.26 |
d_rossberg |
i.e. the easy
ones |
| 15:30.37 |
d_rossberg |
"half-finished" means they are programed
by an intern and i hadn't time to look at them |
| 15:31.38 |
d_rossberg |
it is usually
not so much work, however i've other preferences at the
moment |
| 16:59.07 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 17:03.00 |
CIA-41 |
BRL-CAD:
03davidloman * r36785 10/rt^3/trunk/ (include/GS/Config.h
src/GS/CMakeLists.txt src/GS/Config.cxx): Beginings of
Configuration loading system. |
| 17:05.36 |
CIA-41 |
BRL-CAD:
03davidloman * r36786 10/rt^3/trunk/geoserve.config: Add
address/port to config file. |
| 17:44.33 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149CAF.dip.t-dialin.net) |
| 18:48.27 |
CIA-41 |
BRL-CAD:
03indianlarry * r36787 10/brlcad/trunk/src/conv/step/
(FaceBound.cpp FaceBound.h): Added function to test if FaceBound is
oriented. |
| 18:59.39 |
CIA-41 |
BRL-CAD:
03indianlarry * r36788 10/brlcad/trunk/src/conv/step/
(PullbackCurve.cpp PullbackCurve.h): Added PBC_SEAM_TOL definition
to explicitly test trim point sample closeness to surface seam.
Also using BREP_EDGE_MISS_TOLERANCE as tolerance input to
SurfaceTree::getSurfacePoint(). |
| 20:05.43 |
*** join/#brlcad IriX64
(n=IriX64@bas2-sudbury98-1178014899.dsl.bell.ca) |
| 20:42.24 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 21:18.23 |
CIA-41 |
BRL-CAD:
03indianlarry * r36789
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: |
| 21:18.23 |
CIA-41 |
BRL-CAD: Use
the cues from FaceBound "Orientation" setting to determine loop
direction consistency instead of openNURBS BREP LoopDirection()
function. |
| 21:18.23 |
CIA-41 |
BRL-CAD:
Unitized ON_Line::Direction() used in intersectLines() function,
large line magnitudes were causing some tolerence problems with
bn_isect_line3_line3(). |
| 21:18.25 |
CIA-41 |
BRL-CAD:
Gutted Circle::LoadONBrep(), now subdivides arc based on angular
extents and builds NURB directly. (Will need to do the same for
Ellipse) |
| 21:18.28 |
CIA-41 |
BRL-CAD:
Cleanup start/end point code in all the Conic curve
loading. |
| 21:45.13 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 23:12.52 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 00:28.36 |
``Erik |
heh http://www.collegehumor.com/video:1924624 |
| 00:53.03 |
brlcad |
heh |
| 00:53.14 |
brlcad |
"wellll... we
gotta get rid of the body" |
| 01:01.40 |
``Erik |
these days,
cellphones are KNOWN to have health risks |
| 01:02.10 |
starseeker |
? |
| 01:02.57 |
starseeker |
getting beat
up if talking loud on one in a diner? |
| 01:03.08 |
``Erik |
watch the
collegehumor video... :D |
| 01:03.13 |
starseeker |
ah |
| 01:08.30 |
``Erik |
"Yeah, well,
when I was in prison, we used to sneak stuff in by hiding it up our
ass." "I've got some fudge hidden up my ass, you want
some?" |
| 01:09.10 |
starseeker |
"there's an
app for that" taken to new heights (or lows) |
| 01:19.19 |
starseeker |
``Erik: is
there a reason to keep mysql.txt in the repository? |
| 01:19.26 |
starseeker |
(isst) |
| 01:20.19 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 01:38.46 |
starseeker |
``Erik: isst
doesn't work for mouse movement on my home box either |
| 01:38.56 |
starseeker |
(gentoo) |
| 01:39.04 |
starseeker |
gtk 2.18.3 I
believe |
| 02:17.06 |
starseeker |
eyes libsdl... |
| 02:26.50 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36790 10/isst/trunk/mysql.txt: dead
file |
| 02:27.00 |
``Erik |
thought I"d
killed it a long time ago, seeing it in your dir is why I thought
you had an old checkout |
| 02:27.26 |
starseeker |
ah
:-) |
| 02:27.31 |
starseeker |
nope, just
checked it out |
| 02:27.51 |
starseeker |
am I right
that a lot of isst.c gets reused when using a different
toolkit? |
| 02:28.11 |
``Erik |
there should
be no isst.c |
| 02:28.25 |
starseeker |
er
isst-gtk.c |
| 02:28.59 |
``Erik |
uhhhh,
there's no isst-gtk.c either |
| 02:29.18 |
starseeker |
fine gui.c
:-) |
| 02:29.20 |
``Erik |
none of it
should be re-used, but look at local_worker.c for the
interface |
| 02:29.33 |
starseeker |
k |
| 02:29.37 |
``Erik |
gui.c is the
gtk+ mess |
| 02:30.36 |
``Erik |
the big
switch statement will eventually be a single function with a name
passed to support a plugin system |
| 02:31.21 |
starseeker |
nods |
| 02:40.52 |
starseeker |
growl... |
| 02:53.30 |
``Erik |
? |
| 02:54.36 |
starseeker |
looking for a
good toolkit option |
| 02:54.57 |
starseeker |
agar looks
like the winner from the libsdl side, but it has a custom build
system and the svn version doesn't compile |
| 02:55.10 |
starseeker |
Tk has a
bunch of... funky options |
| 02:57.08 |
starseeker |
Qt might be
an option... wonder how fast Qpixmap is |
| 02:58.28 |
starseeker |
we're going
to use Qt someday anyhow |
| 03:09.40 |
starseeker |
HMMM.
http://labs.trolltech.com/blogs/2009/11/10/qt3d-features-in-qt-46/ |
| 03:12.42 |
``Erik |
um,
qpainter2d |
| 03:12.55 |
starseeker |
ah |
| 03:13.01 |
starseeker |
you looked
into it already? |
| 03:13.04 |
``Erik |
jabba has a
fast paint buffer for 2d games |
| 03:13.05 |
``Erik |
yeah |
| 03:13.15 |
starseeker |
is it
viable? |
| 03:13.21 |
``Erik |
which? |
| 03:13.25 |
starseeker |
Qt |
| 03:13.35 |
``Erik |
the qpainter
stuff might be adequate, I dunno |
| 03:13.44 |
``Erik |
the java
stuff is used in 2d games, so it's up to snuff |
| 03:14.09 |
``Erik |
2d game stuff
seems like the richest source for this kinda info |
| 03:15.18 |
``Erik |
glTexSubImage2D might be the shizzle for
portability on 3d gpu equiped machiens |
| 03:15.30 |
starseeker |
nods |
| 03:17.06 |
starseeker |
hmm. what's
OpenVG I wonder... |
| 03:17.34 |
``Erik |
vector
graphics out of khronos? |
| 03:17.53 |
starseeker |
who's
khronos? |
| 03:18.14 |
starseeker |
oh |
| 03:18.18 |
starseeker |
open
standards group |
| 03:18.21 |
``Erik |
um, iirc, a
consortium glued together to make an ogl replacement that
failed? |
| 03:19.07 |
``Erik |
farenheit or
something? |
| 03:19.52 |
starseeker |
opengl
es? |
| 03:21.57 |
starseeker |
heh - cool
agar dev responded on irc |
| 03:22.11 |
starseeker |
compiles again... |
| 03:26.44 |
starseeker |
ouch - that
make doesn't take a -j option... |
| 03:28.32 |
``Erik |
not sounding
so incredibly awesome... |
| 03:28.42 |
starseeker |
yeah |
| 03:29.01 |
starseeker |
dunno why he
doesn't just use autotools or some such... |
| 03:30.15 |
starseeker |
I'll say this
for him - I didn't see much in the way of warnings during the
compile |
| 03:31.09 |
``Erik |
-Wnone ?
:D |
| 03:31.14 |
starseeker |
hehe |
| 03:31.32 |
starseeker |
could
be |
| 03:31.46 |
``Erik |
wonders where he put the widget toolkit he wrote ontop of sdl
O.o |
| 03:32.02 |
starseeker |
ah, here are
some errors |
| 03:32.09 |
starseeker |
just early in
the build when I wasn't watching |
| 03:32.10 |
starseeker |
k |
| 03:32.46 |
starseeker |
hang on, may
have fed it a malformed -j option... |
| 03:36.43 |
starseeker |
hmm,
weird |
| 03:39.06 |
starseeker |
almost works
- only fails on first attempt after a clean svn
checkout |
| 03:39.19 |
starseeker |
pastebins for the devs |
| 03:39.37 |
starseeker |
ah, well -
not much chance we'd use it anyway, but I'm curious |
| 03:46.36 |
Ralith |
er |
| 03:46.47 |
Ralith |
isn't the
khronos group responsible for OGL itself? |
| 03:47.32 |
Ralith |
(also, OpenGL
ES is a portable complement to OpenGL which, afaik, is active and
successful) |
| 03:47.55 |
starseeker |
yeah, I guess
that's true enough |
| 03:48.12 |
starseeker |
thought ES was intended to be the next OGL, but got shot down
(for now at least) |
| 03:48.45 |
Ralith |
nope |
| 03:48.48 |
Ralith |
just a
trimmed down version |
| 03:49.13 |
Ralith |
you're
probably thinking of OpenGL 3, which had lots of exciting new
features that got scrapped right before the spec was
finalized |
| 03:49.28 |
Ralith |
(although I'm
told most of them made it back into the 3.2 spec, which is out, so
that's not so bad) |
| 03:49.48 |
starseeker |
heh |
| 03:49.54 |
starseeker |
Ralith: how
goes school? |
| 03:50.54 |
``Erik |
yeh, looks
like khronos does ogl now, guess to fill the void sgi left... es is
'embedded' |
| 03:51.01 |
Ralith |
pretty good;
just yesterday finished my last major assignment |
| 03:51.07 |
starseeker |
sweet |
| 03:51.11 |
``Erik |
grats |
| 03:51.14 |
Ralith |
intro CS
course was predictably blarg |
| 03:51.18 |
starseeker |
heh |
| 03:51.24 |
Ralith |
the prof
didn't even really know what he was talking about
>.< |
| 03:51.33 |
starseeker |
yeah, that
sucks |
| 03:51.56 |
Ralith |
but I remain
hopeful, as my discrete math and logic & computer design
courses were both very good. |
| 03:54.59 |
starseeker |
excellent |
| 03:55.13 |
starseeker |
so you feel
like some Ogre+Qt hacking? ;-) |
| 03:57.44 |
starseeker |
feels a trifle guilty about spending time on Agar... darn
curiosity... |
| 11:45.53 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:19.53 |
``Erik |
"are there
any open source tools to deal with access .mdb files?"
"rm" |
| 13:20.10 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14BF38.dip.t-dialin.net) |
| 13:21.42 |
archivist |
rm -rf as its
a windows box /me ducks |
| 14:10.07 |
``Erik |
frikkin'
tkhtml3 (AGAIN) |
| 14:11.23 |
starseeker |
now what is
it doing (or not doing) |
| 14:11.36 |
``Erik |
ignoring
CPPFLAGS |
| 14:11.55 |
starseeker |
kinda regrets not just doing the tkimg style hack build -
that at least worked most of the time... |
| 14:12.42 |
starseeker |
``Erik: that
might be a Makefile.in issue? |
| 14:13.11 |
``Erik |
it happens
during ./configure |
| 14:13.28 |
starseeker |
never did get the hang of merging TEA building and automake's
Makefile.am, although I suppose I should try it
again... |
| 14:13.31 |
starseeker |
ah |
| 14:13.49 |
``Erik |
./configure
CPPFLAGS=-I/some/path/include/tk8.5/ and tkhtml3's subconfigur
bitches about not finding tk.h |
| 14:14.48 |
``Erik |
doesn't remember if it ever worked right
O.o |
| 14:14.50 |
starseeker |
try
--with-tkinclude |
| 14:16.11 |
starseeker |
gets cadtools running... and watches the widgets behave
funky |
| 14:16.18 |
starseeker |
yep, not
ready for prime time |
| 14:17.00 |
``Erik |
heh |
| 14:17.26 |
``Erik |
tries to act surprised O:-) |
| 14:18.06 |
starseeker |
<snort>
- it's not like I am |
| 14:18.33 |
starseeker |
just worth
checking - it confirms that an SDL solution means writing our own
local widgets as well |
| 14:19.14 |
``Erik |
or figuring
out how to hijack the sdl's SDL_Display shtuffz |
| 14:19.25 |
``Erik |
sam's a
pretty laid back guy, he might be cool with taking a
patch |
| 14:19.46 |
starseeker |
what'd you
have in mind? |
| 14:20.08 |
``Erik |
no
clue |
| 14:20.44 |
``Erik |
iirc, when
you set up a window or context in SDL, it's very oriented towards
having a single window, SDL_InitVideo() or something bangs on
globals and stuf |
| 14:20.48 |
starseeker |
kinda sounds
like using another toolkit with it would entail similar issues to
Ogre + Qt |
| 14:21.39 |
``Erik |
oh,
SDL_SetVideoMode() |
| 14:22.10 |
``Erik |
hrm,
SDL_SwapBuffers(); uses the global surface |
| 14:22.15 |
starseeker |
yeah, seeing
similar stuff - the tcl-demo code shows tcl/tk controlling sdl,
which is OK, simple and might work, but it's not immediately clear
if it would also allow 3D manipulation controls and ray firing in
SDL |
| 14:22.38 |
``Erik |
didja look at
local_worker.c ? |
| 14:22.48 |
starseeker |
glanced at
it |
| 14:23.17 |
starseeker |
was more
trying to figure out what container to put around the adrt stuff
before digging into adrt |
| 14:23.38 |
starseeker |
s/adrt/isst |
| 14:23.42 |
``Erik |
well, digging
through that tiny file tells you what kinda container you're
looking for :D |
| 14:23.50 |
starseeker |
heh |
| 14:23.59 |
starseeker |
fair
enough |
| 14:24.11 |
starseeker |
also got
sidtracked into reading about NURBS till about 1am |
| 14:24.14 |
starseeker |
(brain
hurts) |
| 14:24.32 |
``Erik |
ponders digging up old svgalib code and figuring out how to
do an isst that way :> |
| 14:24.42 |
starseeker |
ew ew
ew |
| 14:25.05 |
starseeker |
doesn't think he's heard of svgalib for
years |
| 14:25.34 |
``Erik |
http://brlcad.org/~erik/files/warp.c
heh |
| 14:26.04 |
starseeker |
hehe |
| 14:27.43 |
``Erik |
(how the hell
did that even work?) |
| 14:27.56 |
starseeker |
black
magic |
| 14:28.13 |
starseeker |
heads in - see ya in a bit |
| 14:28.18 |
``Erik |
it's gotta be
setaling shit off the stack |
| 14:28.18 |
starseeker |
(if you're
in) |
| 14:28.26 |
``Erik |
linux musta
REALLY sucked to make that work |
| 14:29.16 |
starseeker |
makes a note to study this code and see if sdl window
interactions are compatible with it... http://www.libsdl.org/projects/tcl-demo/ |
| 14:29.55 |
starseeker |
if so, might
have some fun with mged, libsdl and adrt... |
| 15:08.56 |
``Erik |
cooks up a bench run on this fpu-less ARM thingy
:> |
| 16:48.53 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 16:51.34 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14BF38.dip.t-dialin.net) |
| 17:40.06 |
``Erik |
AWESOME,
negative infinity logarithmic vgr's! |
| 17:40.26 |
``Erik |
Benchmark
results indicate an approximate VGR performance metric of
0 |
| 17:40.26 |
``Erik |
Logarithmic
VGR metric is -inf (natural logarithm is -inf) |
| 17:40.32 |
``Erik |
Abs OpenRD
11386.64 6382.36 6583.38 5773.79 6654.10 7956.48 Thu Dec
4 12:38:24 EST 2031 |
| 17:45.24 |
``Erik |
ah |
| 17:45.25 |
``Erik |
erik@OpenRD
~/src/brlcad/bench$ bc |
| 17:45.25 |
``Erik |
bash: bc:
command not found |
| 17:49.18 |
starseeker |
supposes sanity checks are in order... |
| 17:49.32 |
starseeker |
bc, time,
other things available on any SANE system... |
| 17:50.39 |
``Erik |
yeah, need to
get linux off of that thing and bring up freebsd... |
| 18:41.27 |
*** join/#brlcad johnson_dm_
(n=johnson_@mail.piasecki.com) |
| 18:41.58 |
starseeker |
looks like
this might have some hints for metaball->NURBS conversion:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.9803 |
| 18:48.40 |
``Erik |
interesting |
| 18:49.31 |
``Erik |
I'd have to
read it more carefully to see if the representations line up the
same for the initial data... their approach looks like a good fit
for the blinn style surface, but mebbe not the iso one I
have |
| 18:49.54 |
``Erik |
spheres and
saddles as the patches, wasn't even thinking of cutting the surface
up like that heh |
| 18:51.46 |
starseeker |
might not be
stricly necessary - another possible approach might be to generate
control points based on the isopotential gradients... if some
mapping can be found that makes sense... |
| 18:52.05 |
starseeker |
might be a
legitimate paper in there somewhere |
| 18:52.13 |
``Erik |
well, given
that code now exists to find the surface between two points, ...
*shrug* |
| 18:52.47 |
starseeker |
yeah, but
when defining the NURBS curve you want to (as much as possible)
match the surface curvature, not just smoothly intersect a subset
of points |
| 18:52.51 |
starseeker |
that might be
trickier |
| 18:52.53 |
starseeker |
not
sure |
| 18:53.45 |
``Erik |
approximating
curvature should be reasonably straightforward with a set of nearby
intersections |
| 18:53.49 |
starseeker |
obviously a
surface tree approach and some sort of "flat isopotential within
box" approach would let us get very close... |
| 18:54.42 |
starseeker |
yeah, there's
probably some sort of mathy "combinations of radial potentials
result in surface curvature of yada..." math that could/should be
done... |
| 19:00.18 |
*** join/#brlcad juantelez
(n=juan@unaffiliated/juantelez) |
| 19:00.22 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 19:00.39 |
juantelez |
hi
all |
| 19:01.00 |
*** join/#brlcad Nohla
(n=jesica@201.255.245.8) |
| 19:01.11 |
juantelez |
I have a
friend that want to translate the documentation to spanish, here
she is |
| 19:01.22 |
juantelez |
hola Nohla
:) |
| 19:01.34 |
juantelez |
esperemos a
ver que dicen, jeje |
| 19:02.04 |
starseeker |
howdy
:-) |
| 19:02.16 |
juantelez |
hi
starseeker |
| 19:02.41 |
starseeker |
Nohla: hola
:-) |
| 19:03.16 |
starseeker |
unfortunately
I don't speak much spanish - I think brlcad speaks some
though |
| 19:03.21 |
Nohla |
starseeker,
hola, sabes español? |
| 19:03.34 |
Nohla |
ah
ok |
| 19:03.35 |
starseeker |
Nohla: no
:-( |
| 19:03.42 |
juantelez |
i have very
little experince whit wiki, and, and I'm affraid that if i edit the
documentation the english documentation will be lost and all of you
will came to my house and kill me |
| 19:03.44 |
juantelez |
jaja |
| 19:03.51 |
starseeker |
hehe |
| 19:04.18 |
starseeker |
actually,
what I would suggest is working with the docbook documentation in
our tree |
| 19:04.29 |
juantelez |
starseeker:
do you know how we can edit the doc to translate it whitout erase
anything? |
| 19:04.40 |
juantelez |
let me
see |
| 19:04.40 |
starseeker |
we eventually
want to get to the point where that is integrated into the wiki,
but we aren't there yet |
| 19:04.53 |
starseeker |
juantelez: do
you have a copy of the brlcad source code? |
| 19:05.01 |
juantelez |
starseeker:
no |
| 19:05.02 |
starseeker |
er BRL-CAD
(sorry brlcad) |
| 19:05.07 |
starseeker |
juantelez:
ah |
| 19:05.10 |
starseeker |
ok, that's
step one |
| 19:05.32 |
juantelez |
but we want
to translate the doc not the program itself |
| 19:05.38 |
starseeker |
right |
| 19:05.41 |
juantelez |
ok |
| 19:05.45 |
starseeker |
the docs are
in the source tree |
| 19:05.48 |
juantelez |
ok |
| 19:06.00 |
juantelez |
let me see if
I could find it and download |
| 19:06.00 |
starseeker |
we create a
docbook file, then build html, pdf and man pages from that one
source file |
| 19:06.09 |
juantelez |
ok |
| 19:06.09 |
starseeker |
simplifies
maintaining things no end |
| 19:06.18 |
juantelez |
ok |
| 19:06.41 |
starseeker |
what platform
are you on? (Windows, Linux, ...) |
| 19:06.57 |
juantelez |
GNU/Linux |
| 19:07.04 |
starseeker |
http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.16.2/brlcad-7.16.2.tar.gz/download |
| 19:07.08 |
starseeker |
latest
release |
| 19:07.12 |
juantelez |
thanks
starseeker !! |
| 19:07.15 |
juantelez |
Nohla: bajate
eso |
| 19:07.27 |
Nohla |
juantelez, ya
juan, lo estoy siguiendo |
| 19:07.28 |
juantelez |
Nohla: que el
laburo heavy lo vas a hacer vos! yo soy solo el rrpp!
jaja |
| 19:07.36 |
Nohla |
jajaja |
| 19:07.44 |
juantelez |
Nohla: no me
cancheres porque te dejo sola, jaja |
| 19:08.01 |
Nohla |
juantelez,
sola es cuando mas aprendo |
| 19:08.20 |
starseeker |
if you're not
familiar with Docbook, it's an xml markup language (feels a little
like html, but is much more abstract) |
| 19:09.53 |
juantelez |
starseeker:
thanks a lot! |
| 19:09.57 |
starseeker |
when you
expand the tarball, you will see inside the brlcad-7.16.2 directory
a doc directory, and within that directory a docbook
directory |
| 19:10.08 |
juantelez |
starseeker: i
guess we will here bodering a lot! |
| 19:10.10 |
juantelez |
jaj |
| 19:10.54 |
starseeker |
the README
file outlines the toplevel directories |
| 19:10.54 |
Nohla |
mmm, i
thought it was easier |
| 19:11.21 |
starseeker |
the directory
structure is laid out such that we can create es subdirectories
just as we currently have en subdirectories |
| 19:11.21 |
Nohla |
juantelez,
esa parte la hace vos? yo lo traduzco |
| 19:11.51 |
starseeker |
juantelez: if
docbook is too much, you're welcome to start on whatever you care
to |
| 19:11.56 |
starseeker |
all efforts
are welcome |
| 19:12.16 |
juantelez |
:) |
| 19:12.26 |
starseeker |
if you're
willing to work on the docbook level though, it will save
converting the results to docbook later |
| 19:12.32 |
juantelez |
Nohla: bueno,
dame ssh a tu maquina y te digo que traducir, jaja |
| 19:12.55 |
starseeker |
I recommend
starting in the system/man1 directory |
| 19:13.04 |
starseeker |
those are
manual pages, which are small and self contained |
| 19:13.14 |
juantelez |
starseeker:
don't worry, Nohla just love to learn, so, she'll work with
Docbook |
| 19:13.16 |
juantelez |
jaja |
| 19:13.38 |
Nohla |
starseeker,
please, step by step |
| 19:14.00 |
Nohla |
and
slower |
| 19:14.09 |
starseeker |
Nohla: you
have brlcad-7.16.2.tar.gz? |
| 19:14.12 |
Nohla |
yes |
| 19:14.25 |
starseeker |
ok. run the
following command: |
| 19:14.38 |
starseeker |
tar -xvzf
brlcad-7.16.2.tar.gz |
| 19:15.06 |
Nohla |
done |
| 19:15.24 |
starseeker |
cd
brlcad-7.16.2 |
| 19:15.37 |
starseeker |
cd
doc/docbook |
| 19:15.51 |
starseeker |
cd
system/man1 |
| 19:16.19 |
starseeker |
you should
see a README file, a file called mged_cmd_template.xml, and a
directory en |
| 19:17.30 |
starseeker |
for spanish
documentation, we will create a directory at this
level: |
| 19:17.33 |
starseeker |
mkdir
es |
| 19:17.50 |
starseeker |
OK so
far? |
| 19:18.40 |
Nohla |
ok |
| 19:19.09 |
starseeker |
ok. now, if
you list the contents of the en directory, you will see many xml
files: |
| 19:19.12 |
starseeker |
ls
en/ |
| 19:20.00 |
starseeker |
these files
are docbook files |
| 19:20.10 |
starseeker |
what editor
do you prefer? (emacs, vi, etc.) |
| 19:20.53 |
Nohla |
vim |
| 19:21.00 |
starseeker |
ah
:-) |
| 19:21.41 |
starseeker |
ok, vim will
work fine. If you care to investigate it later, there is an emacs
tool called nxml that is useful for docbook files, but for now we
will use vim |
| 19:21.58 |
starseeker |
so, open the
first file: |
| 19:22.05 |
starseeker |
vim
en/3ptarb.xml |
| 19:22.11 |
Nohla |
i have emacs,
but ive neer usd it |
| 19:22.18 |
Nohla |
i can try if
you help me |
| 19:22.24 |
starseeker |
no need for
now |
| 19:22.43 |
starseeker |
it helps when
doing docbook markup, but for a while you will simply be
translating |
| 19:22.48 |
starseeker |
no markup
change needed |
| 19:23.25 |
Nohla |
ok |
| 19:23.33 |
starseeker |
you have
3ptarb.xml open? |
| 19:23.45 |
Nohla |
yes |
| 19:24.26 |
starseeker |
OK. You see
english sentences and paragraphs? |
| 19:24.32 |
Nohla |
ahá |
| 19:24.57 |
starseeker |
first
sentence to translate is "Build an ARB8 shape by extruding a
quadrilateral through a given thickness." |
| 19:25.24 |
starseeker |
the xml tangs
inside <> brackets (like <refentrytitle>) do NOT get
translated |
| 19:25.28 |
starseeker |
only
content |
| 19:25.39 |
Nohla |
yes |
| 19:25.48 |
starseeker |
also, command
and program names (3ptarb, MGED) must stay the same |
| 19:25.49 |
Nohla |
i saw that
content |
| 19:25.55 |
starseeker |
good
:-) |
| 19:26.12 |
starseeker |
so, now we
quit vim and prepare to translate the file |
| 19:26.31 |
starseeker |
you made
directory es earlier? |
| 19:26.32 |
Nohla |
so i should
copy all de directory and trasleate just de
explanations |
| 19:26.40 |
starseeker |
yes |
| 19:26.54 |
Nohla |
and let them
in a diferent directory |
| 19:26.54 |
starseeker |
cp
en/3ptarb.xml es/3ptarb.xml |
| 19:27.05 |
starseeker |
then edit
es/3ptarb.xml |
| 19:27.12 |
Nohla |
wow |
| 19:27.20 |
Nohla |
it was
easy |
| 19:27.52 |
Nohla |
i was near to
do a lot of stupid things on wikibooks :) |
| 19:28.26 |
starseeker |
we would like
to edit via wiki, but we must write new code for wiki engine to
enable that - not done yet |
| 19:28.51 |
starseeker |
so, if
acceptable, better to do it this way :-) |
| 19:29.03 |
*** part/#brlcad johnson_dm_
(n=johnson_@mail.piasecki.com) |
| 19:29.20 |
Nohla |
but i would
like to put yhis on the web, where everyone can acces |
| 19:29.24 |
Nohla |
s |
| 19:29.49 |
juantelez |
thats the
better part |
| 19:29.49 |
starseeker |
once you
translate some files, we will build html output |
| 19:29.49 |
starseeker |
html can be
uploaded to the wiki |
| 19:29.59 |
Nohla |
that was the
problem that begin this idea |
| 19:30.08 |
starseeker |
nods |
| 19:30.28 |
juantelez |
the work that
you are doing Nohla, doesn't work only with
trnaslation, |
| 19:31.58 |
Nohla |
so, i`ll do
the first tranlations |
| 19:32.18 |
Nohla |
the, how i
give them to your proyect? |
| 19:32.31 |
Nohla |
to be offered
with the download |
| 19:32.46 |
juantelez |
Nohla: que
queres preguntar? |
| 19:32.51 |
starseeker |
once you have
the first few done, we will check them over and add them to our
source code repository |
| 19:32.52 |
juantelez |
Nohla: me
parece que te hiciste quilobmo |
| 19:33.15 |
Nohla |
juantelez, el
me entendio |
| 19:33.15 |
starseeker |
if they look
good, brlcad may decide to allow you to commit directly to the
sourceforge subversion repository |
| 19:33.29 |
Nohla |
juantelez,
aprende spanglish y despues decime :) |
| 19:33.31 |
juantelez |
Nohla:
entendes lo que estas haciendo? estas modificando el codigo de la
fuente, despues compilas eso en html para que quede en la
pagina |
| 19:33.52 |
starseeker |
initially,
you can email them to the BRL-CAD email list |
| 19:33.53 |
juantelez |
Nohla:
enntendes? |
| 19:34.00 |
Nohla |
juantelez,
que si |
| 19:34.13 |
Nohla |
pero no esta
en los repositorios si yo no lo mando |
| 19:34.16 |
Nohla |
solo en mi
maquina |
| 19:34.24 |
starseeker |
http://sourceforge.net/mail/?group_id=105292 |
| 19:34.46 |
starseeker |
brlcad-devel
would be appropriate here, I believe |
| 19:35.10 |
juantelez |
Nohla: pero
te esta diciendo, que lo mandes a la lista para que ellos lo subam
o despues lo de brlcad_ y por ahi te autoriza para que hagas el
commint vos directamente |
| 19:35.33 |
juantelez |
Nohla: fijate
que tienen un par de listas de correo y foros |
| 19:35.44 |
Nohla |
que es el
commint |
| 19:36.48 |
starseeker |
We manage our
developent tree using subversion version control system: http://subversion.tigris.org/ |
| 19:37.48 |
juantelez |
Nohla: el
proceso de subir lo que modificaste |
| 19:38.26 |
Nohla |
starseeker,
stop again, step by step |
| 19:38.42 |
Nohla |
ill do the
first, and then y return here for the following |
| 19:38.50 |
starseeker |
Nohla: ok.
|
| 19:39.07 |
Nohla |
starseeker,
if i do too much, ill leave it soon |
| 19:39.24 |
Nohla |
actually, i
should be studing right now |
| 19:39.29 |
starseeker |
no hurry -
work at your own pace |
| 19:39.29 |
juantelez |
jaja |
| 19:39.42 |
juantelez |
starseeker:
where are you from? |
| 19:39.49 |
starseeker |
Maryland |
| 19:39.54 |
starseeker |
USA |
| 19:40.15 |
juantelez |
we are from
Buenos Aires, Argentina |
| 19:40.25 |
starseeker |
very nice
:-) |
| 19:40.44 |
starseeker |
thank you for
your interest in BRL-CAD |
| 19:41.14 |
Nohla |
starseeker,
thank to all you for bring BRLCAD |
| 19:41.39 |
starseeker |
Nohla: if you
like doing translations, I will take you through next stages step
by step - they are not needed yet |
| 19:41.41 |
juantelez |
jeje |
| 19:42.10 |
juantelez |
starseeker:
in fact, her idea of transalate this came up as a need |
| 19:42.36 |
Nohla |
starseeker,
ive never done translations before this |
| 19:42.40 |
Nohla |
:) |
| 19:42.57 |
juantelez |
starseeker:
Nohla contributes a lot with the LUG of her Universty |
| 19:43.06 |
starseeker |
excellent
:-) |
| 19:43.14 |
juantelez |
(former my
university jaja) |
| 19:43.24 |
Nohla |
jajajja |
| 19:44.33 |
juantelez |
and a student
from another area tell her that he want to learn to use brl-cad but
the language barrer was stoping him |
| 19:45.08 |
Nohla |
starseeker,
BRL is one (not the first) of the available software in raplace of
autocad |
| 19:45.48 |
Nohla |
ive never
seen a person who use it, and i never used it :) |
| 19:46.16 |
Nohla |
but a student
came to an event with this problem |
| 19:46.22 |
starseeker |
nods |
| 19:46.32 |
starseeker |
yes, to use
BRL-CAD you need to read the documentation |
| 19:46.41 |
Nohla |
he wanted to
change completed to FS but he dont speak english |
| 19:47.40 |
Nohla |
so i offered
him this work |
| 19:47.54 |
starseeker |
Nohla: thank
you! |
| 19:47.55 |
Nohla |
for him and
other people in his situation |
| 19:48.56 |
Nohla |
starseeker,
there some apps or functions that autocad offer, but brl dont
? |
| 19:49.09 |
starseeker |
Once you are
comfortable with docbook and translating, for beginners the files
in doc/docbook/lessons are most important |
| 19:49.15 |
Nohla |
(sorry if it
hard to understand me) |
| 19:49.19 |
starseeker |
Nohla: yes,
autocad has features we do not |
| 19:49.23 |
starseeker |
no problem
:-) |
| 19:49.36 |
Nohla |
starseeker,
wich are them? |
| 19:49.54 |
starseeker |
we do not
have much ability to do 2D blueprints/sketches |
| 19:50.03 |
starseeker |
QCAD is
better for that |
| 19:50.08 |
starseeker |
BRL-CAD does
solid modeling |
| 19:50.31 |
starseeker |
AutoCAD is
more "polished", more user friendly |
| 19:51.48 |
Nohla |
so i will
translate qcad :D |
| 19:52.25 |
Nohla |
we do not
have much ability to do 2D blueprints/sketches:: starseeker, you
will? |
| 19:53.03 |
starseeker |
someday, but
it is not yet a priority |
| 19:53.18 |
``Erik |
much work to
be done and very few of us doing it |
| 19:53.21 |
Nohla |
why
not? |
| 19:53.44 |
starseeker |
BRL-CAD is
used to model three dimensional objects (like vehicles) for
analysis |
| 19:54.02 |
starseeker |
blueprints
are used more in manufacturing |
| 19:54.16 |
Nohla |
if you
develop that skills i promise to do a good work on
difussion |
| 19:54.22 |
``Erik |
right now,
the big pushes are for NURBS support (like Pro/E, unigraphics,
rhino3d) and for an updated and modernized user
interface |
| 19:54.37 |
Nohla |
but to the
university it is necesary |
| 19:55.35 |
``Erik |
have you seen
http://brlcad.org/w/images/4/44/Industry_Diagram.pdf
? |
| 19:56.54 |
starseeker |
Nohla: we
would love for someone in the BRL-CAD open source community to
develop support for blueprint outputs, but until we have the
available resources to devote to it we can't do them well
yet |
| 19:57.09 |
starseeker |
Nohla: there
IS rtedge, though: |
| 19:58.09 |
starseeker |
http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 19:59.21 |
Nohla |
wow |
| 20:00.43 |
starseeker |
we don't have
all of the standard "blueprint" boxes and labels, but those can be
created with (say) inkscape using an rtedge render as a starting
point |
| 20:01.43 |
starseeker |
so 1. create
3D model in BRL-CAD 2. render hidden line wireframe with rtedge 3.
import into inkscape and add necessary blueprint
additions |
| 20:02.33 |
Nohla |
starseeker,
you should now that i dont kwon how to use brl, and even the think
its good to now for beginners |
| 20:03.02 |
Nohla |
there will be
a lot of thing you will say that ill lose in the middle
:) |
| 20:03.08 |
starseeker |
It's
OK |
| 20:03.35 |
starseeker |
short version
- you can do blueprint-like outputs, but not simple or
feature-rich |
| 20:04.05 |
Nohla |
the one i
know is that the FS have a piece of software on demand |
| 20:04.29 |
Nohla |
and im trying
to do something to make one option more knowed |
| 20:04.33 |
Nohla |
just
that |
| 20:04.42 |
starseeker |
thank you
:-) |
| 20:05.38 |
starseeker |
Once you have
translated a couple of files, please send them to brlcad-devel
email list |
| 20:05.52 |
starseeker |
very
exciting |
| 20:07.00 |
starseeker |
``Erik: by
the way, how does gettext play with Windows? |
| 20:07.36 |
``Erik |
uhhhh, I
d'no? I imagine it exists in cygwin? |
| 20:07.42 |
starseeker |
winces |
| 20:07.46 |
``Erik |
windows are
those things I look through when I want to see outside,
dude |
| 20:07.52 |
starseeker |
hehe |
| 20:08.42 |
juantelez |
haha |
| 20:09.22 |
starseeker |
notes that his Mac doesn't have ANY of the posix locale
variables set... |
| 20:09.51 |
``Erik |
LC_ALL=en_BEAVIS_AND_BUTTHEAD |
| 20:10.38 |
starseeker |
``Erik: hmm,
some rather interesting possibilities there (and by interesting I
mean disturbing) |
| 20:10.47 |
brlcad |
wooh, lotsa
backlog |
| 20:10.50 |
``Erik |
(amusingly,
all the programs I've gettextized only managed to get a handful of
en_ ones and pt_BR) |
| 20:11.19 |
starseeker |
juantelez,
Nohla: I believe brlcad speaks some Spanish |
| 20:12.06 |
Nohla |
:) |
| 20:12.07 |
``Erik |
starseeker:
I've written beavis&butthead and redneck po files ... after
seeing some sysadmin utility that had a flag to turn on b&b
style messages... :) |
| 20:12.37 |
``Erik |
(as for
backlog, that'll teach brlcad to sleep.) |
| 20:12.49 |
brlcad |
``Erik:
presume that's like the old windows starfield
screensaver? |
| 20:13.01 |
``Erik |
brlcad:
warp.c is, yes |
| 20:14.32 |
brlcad |
starseeker:
heh, isst used to be hooked up to agar |
| 20:14.40 |
brlcad |
clanlib
ftw! |
| 20:14.55 |
Nohla |
starseeker,
what is on wikipedia brl is the same that is in /es ? |
| 20:15.01 |
``Erik |
tried to write a worms armageddon clone with clanlib, didn't
like it |
| 20:15.06 |
Nohla |
with
different format |
| 20:15.26 |
starseeker |
Nohla: er, en
you mean? |
| 20:15.32 |
Nohla |
or on the
wiki, the explanation is clearer? |
| 20:15.40 |
starseeker |
BRL-CAD wiki
content is probably older |
| 20:16.01 |
starseeker |
but more
complete |
| 20:16.13 |
starseeker |
(docbook
conversion is not complete in english either) |
| 20:16.45 |
starseeker |
but once you
are comfortable with translating, definitely suggest working on
lessons |
| 20:17.01 |
starseeker |
hundreds of
pages of content there, most useful for beginners |
| 20:17.02 |
Nohla |
because, i
was thinking that maybe, you souhld tell wich contents are
completed and actualized |
| 20:17.09 |
Nohla |
to beginr
with them |
| 20:17.38 |
starseeker |
doc/docbook/lessons is essentially
complete |
| 20:18.30 |
starseeker |
content of
lessons is from this document: http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf |
| 20:18.35 |
brlcad |
and
interesting about the bench.. it has checks in there for making
sure it exists first |
| 20:18.49 |
brlcad |
should fall
back to dc or other methods |
| 20:19.01 |
starseeker |
Nohla: that
pdf is always first place for new users who speak english to
go |
| 20:19.28 |
starseeker |
so its
contents in doc/docbook/lessons are logical first translation, if
not overwhelming |
| 20:19.32 |
``Erik |
dc isn't on
the box, either... silly embedded systems, not installing all those
fancy tools |
| 20:20.02 |
``Erik |
btclsh? expr
? :D |
| 20:20.20 |
brlcad |
hola Nohla y
juantelez |
| 20:20.45 |
Nohla |
holas |
| 20:21.01 |
Nohla |
starseeker,
this are the same pdf on wiki? |
| 20:21.22 |
starseeker |
same content
as pdf on wiki, yes |
| 20:21.34 |
Nohla |
(sorry, i
dont want to lose to much time looking for the best to transleate
than translating) |
| 20:22.36 |
starseeker |
you want
documentation for a new BRL-CAD user, correct? |
| 20:22.44 |
brlcad |
is still backlogging |
| 20:23.33 |
Nohla |
starseeker,
give two things: 1) the best content to translate firs. 2) one
advice about translating that |
| 20:24.16 |
Nohla |
so if i leave
the proyect at tha first step, at least ive done something usefull
:) |
| 20:24.21 |
starseeker |
Nohla: if
there is no concern about amount of content, the lessons are best
for new users |
| 20:24.30 |
Nohla |
every day i
find new interesting things to do :) |
| 20:24.39 |
starseeker |
Nohla: any
translation is useful |
| 20:25.16 |
starseeker |
for the
request you had, lessons would help him the most |
| 20:25.52 |
Nohla |
http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf
this is for beginers? |
| 20:26.04 |
starseeker |
yes |
| 20:27.34 |
Nohla |
but imagine
that you are a spanish speaking person and start reading that
tuto |
| 20:28.03 |
Nohla |
read the firs
you found and then you realise that there no more contents on
spanish |
| 20:28.12 |
Nohla |
thats sad
:( |
| 20:29.33 |
Nohla |
or worst,
dont read anything because you saw that theres no all the content
in your langage |
| 20:30.01 |
Nohla |
starseeker,
question: the firs you gave me is the source code,
really? |
| 20:30.29 |
Nohla |
that means
that if you tipe for spanish help on console, you will read
that? |
| 20:30.57 |
Nohla |
or if youre
using brl and an advice is shown, that can be available on
spanish? |
| 20:31.07 |
Nohla |
(sorry if the
question is too stupid) |
| 20:33.52 |
Nohla |
(wow if i can
translate 287 pages, i would be pride of myself!
jejeje) |
| 20:35.55 |
starseeker |
Nohla: the
various documentation and help systems in BRL-CAD do not have a
unified design |
| 20:36.09 |
starseeker |
we are
working on correcting that, and docbook will be the eventual
solution |
| 20:37.02 |
starseeker |
but a FULL
translation of all help strings in BRL-CAD would involve many
changes in many places |
| 20:37.33 |
Nohla |
starseeker, i
want to give you my mail for you to send me some information that
you belive its usefull to translate |
| 20:37.56 |
Nohla |
im getting
confused about wichi path to take because there is a lot of
options |
| 20:38.13 |
starseeker |
my suggestion
is doc/docbook/lessons |
| 20:38.21 |
Nohla |
and i dont
know enough to choose correctly |
| 20:38.39 |
Nohla |
and what
about pdf you sent me? |
| 20:38.42 |
starseeker |
without
those, it is hard to use BRL-CAD at all and other translations are
much less useful |
| 20:38.47 |
starseeker |
pdf has same
content |
| 20:39.19 |
Nohla |
so if i do
lesson, then you can drop that content on pdf |
| 20:39.20 |
starseeker |
doc/docbook/lessons contains the contents
of that pdf |
| 20:39.24 |
starseeker |
yes |
| 20:39.35 |
starseeker |
we build the
lessons as individual files |
| 20:39.58 |
starseeker |
so if you
translate mged01_creating_primitive_shapes.xml we can make a pdf
from that |
| 20:40.02 |
starseeker |
and
html |
| 20:40.55 |
brlcad |
Nohla:
podemos darte permiso a hacer 'commits' al repository si estas
"active" con los traducciones |
| 20:41.08 |
Nohla |
but, at the
same kind of thinking, if i translate the pdf, you can take what
you need to drop that on lesson XD |
| 20:41.15 |
Nohla |
this is
funny |
| 20:41.36 |
starseeker |
brlcad:
help |
| 20:41.43 |
starseeker |
I'm not
making myself clear |
| 20:41.44 |
Nohla |
brlcad, ive
never translate anything before |
| 20:42.07 |
brlcad |
juantelez:
thanks for helping be the intermediate translator :) |
| 20:42.14 |
Nohla |
starseeker,
nono, im joking :) |
| 20:42.25 |
starseeker |
ah
:-) |
| 20:43.29 |
Nohla |
starseeker,
anyway, my email is giudicejesica@gnutn.org.ar in case you want to
guide this work in the foreward step :) |
| 20:43.38 |
starseeker |
thank you
:-) |
| 20:43.59 |
starseeker |
I suggest
doing a spanish translation of
mged01_creating_primitive_shapes.xml |
| 20:44.25 |
starseeker |
email that to
brlcad-devel, and from there we will take the next
steps |
| 20:45.55 |
Nohla |
so i should
translate all te words in white ;) |
| 20:48.31 |
starseeker |
depends on
what vim syntax highlighting you have on ;-) |
| 20:48.48 |
juantelez |
brlcad: :D,
my pleassure |
| 20:59.02 |
``Erik |
dons his dunce cap. *sigh* |
| 20:59.08 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36791 10/isst/trunk/src/gui.c: set project id on
local load (fixes ignored motion events) |
| 21:09.39 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36792 10/isst/trunk/src/gui.c: restore
perspective rendering when leaving shotline mode |
| 21:31.42 |
CIA-41 |
BRL-CAD:
03brlcad * r36793
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c:
shelling |
| 21:59.31 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36794 10/isst/trunk/src/gui.c: save a
shotline |
| 22:14.12 |
brlcad |
okay, all
caught up with the backlog... |
| 22:15.21 |
brlcad |
Nohla: si te
puedes quedar en IRC, me gustaria ayudarte a empezar |
| 22:16.16 |
Nohla |
brlcad,
estoy |
| 22:16.24 |
Nohla |
pero la
verdad que vengo mas o menos bien |
| 22:16.34 |
Nohla |
perdon |
| 22:16.45 |
Nohla |
actually, im
doing right |
| 22:17.50 |
Nohla |
but i need
time because i have to study |
| 22:18.25 |
Nohla |
i pay an exam
on monday |
| 22:21.33 |
Nohla |
i like
translate this more than study :P |
| 22:29.14 |
brlcad |
Nohla: jeje,
que bien |
| 22:31.15 |
brlcad |
pues, lo que
starseeker dijo eåaa cierto .. empezando con los lecciones ayuda
mucho, tambien puedes empezar con el introduccion aqui http://brlcad.org/d/about |
| 22:31.28 |
brlcad |
yeesh, my
unicode isn't working right.. |
| 22:42.25 |
Nohla |
starseeker,
send me an email to keep in touch |
| 22:43.08 |
Nohla |
anyway, at
the end of the first translate ill send the file by your
list |
| 22:43.29 |
Nohla |
if you have
restriction about that, please moderate my message |
| 22:43.57 |
brlcad |
restriction? |
| 22:45.14 |
Nohla |
about de size
of the file |
| 22:45.34 |
Nohla |
i have a list
with that restriction |
| 22:45.47 |
brlcad |
no hay
restriction, pero si tienes que ser suscrito a la lista para enviar
un mensaje |
| 22:46.23 |
brlcad |
https://sourceforge.net/projects/brlcad/lists |
| 22:46.44 |
Nohla |
well, in this
list, if you are not subscripted and send a message, me or
juantelez have to accep it before |
| 22:47.06 |
brlcad |
ah, pues ours
will just reject it ;) |
| 22:47.22 |
brlcad |
con
instrucciones a subscribe |
| 22:47.35 |
brlcad |
(automaticamente) |
| 22:47.40 |
Nohla |
noo |
| 22:47.45 |
Nohla |
thats
bad |
| 22:47.49 |
Nohla |
:P |
| 22:48.58 |
Nohla |
i was talking
about a email list, not a sourceforge list ;) |
| 22:49.21 |
brlcad |
subscribing
is pretty easy, if people aren't willing to do that to engage in a
discussion, it's not usually a productive discussion |
| 22:49.32 |
brlcad |
sourceforge
lists are email lists |
| 22:49.37 |
brlcad |
mailman |
| 22:50.10 |
Nohla |
aha, i
see |
| 22:51.24 |
Nohla |
I dont know
to much of all resources on internet |
| 22:51.41 |
brlcad |
our lists
used to be moderated, but 99% of the moderations were spam and a
waste of time to have to reject/ignore daily |
| 22:51.45 |
Nohla |
well, i dont
know too much of anything :) |
| 22:51.52 |
Nohla |
even english
:D |
| 22:51.53 |
brlcad |
Nohla: you're
english is pretty good :) |
| 22:52.17 |
brlcad |
more than
good enough to communicate usefully |
| 22:52.24 |
Nohla |
well,
thanks |
| 22:53.08 |
Nohla |
im leaving, i
have to live my life sometimes :P |
| 22:53.14 |
brlcad |
``Erik: the
shelling bug is pretty blatent :) |
| 22:53.36 |
Nohla |
from time to
time, I remember I have a family |
| 22:53.51 |
brlcad |
``Erik:
setting the in/out hit distances wrong .. you're making a 1mm
shell |
| 22:54.03 |
brlcad |
Nohla:
jaja |
| 22:54.11 |
brlcad |
pues esta
bien |
| 22:54.13 |
brlcad |
gracies |
| 22:54.17 |
brlcad |
er,
gracias! |
| 22:54.20 |
Nohla |
:) |
| 22:54.36 |
Nohla |
saludos! y
buen fin de semana para todos |
| 22:54.40 |
brlcad |
siempre
estamos aqui |
| 22:54.46 |
brlcad |
ciao |
| 22:55.00 |
brlcad |
igualmente |
| 23:09.34 |
``Erik |
brlcad;
pretty sure something in my stepping function si getting flipped
somewhere to cause that... |
| 23:09.46 |
``Erik |
probably that
stat variable |
| 23:11.42 |
brlcad |
regardless of
the stepping, you're setting in to out+1 |
| 23:11.52 |
brlcad |
or out to
in+1 |
| 23:11.54 |
brlcad |
which can't
be right |
| 23:11.57 |
``Erik |
oh,
hrm |
| 23:12.14 |
``Erik |
um, thought I
set something like that to get off the surface to start the walk
again |
| 23:12.31 |
brlcad |
you don't set
in/outs anywhere else |
| 23:12.43 |
brlcad |
so you end up
with 1mm shells being reported back |
| 23:13.27 |
``Erik |
will have to look into it... next week O.o |
| 23:13.40 |
brlcad |
should back
out the ray outside the metaball bounding box too, count all
surface hits, then clamp to the ray origin |
| 23:13.58 |
brlcad |
that should
take care of it |
| 23:27.36 |
CIA-41 |
BRL-CAD:
03brlcad * r36795 10/brlcad/trunk/TODO: iteration task fail. 64-bit
and annotation are incomplete. move them down. also add deprecation
of the dbfind command. |
| 23:32.25 |
CIA-41 |
BRL-CAD:
03brlcad * r36796 10/brlcad/trunk/NEWS: new configure option for
strict build compilation. this flag, enabled by default, causes the
core libraries to consider all compilation warnings as errors and
can report C standard compliance failures. |
| 23:53.22 |
CIA-41 |
BRL-CAD:
03brlcad * r36797 10/brlcad/trunk/BUGS: vdeck command truncates the
region names in the 'regions' file |
| 00:33.22 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 00:45.32 |
CIA-41 |
BRL-CAD:
03brlcad * r36798 10/brlcad/trunk/ (BUGS TODO): okay, one item to
hit before the release.. the dang EDITOR bug needs to get fixed
where mged invokes the editor without a controlling
terminal. |
| 01:16.13 |
CIA-41 |
BRL-CAD:
03brlcad * r36799 10/brlcad/trunk/BUGS: |
| 01:16.13 |
CIA-41 |
BRL-CAD:
dwayne reports an mged bug where it crashes if you attempt a
pick-edit primitive |
| 01:16.13 |
CIA-41 |
BRL-CAD:
after drawing an object and doing a killall on one of the contained
primitives. |
| 01:16.13 |
CIA-41 |
BRL-CAD:
confirmed problem and got a backtrace. null pointer deref in
db_dirhash(). |
| 01:16.13 |
CIA-41 |
BRL-CAD:
looking further. |
| 01:48.02 |
CIA-41 |
BRL-CAD:
03brlcad * r36800 10/brlcad/trunk/src/librt/db_lookup.c: ws indent
style comment consistency cleanup |
| 01:54.11 |
CIA-41 |
BRL-CAD:
03brlcad * r36801 10/brlcad/trunk/src/librt/db_lookup.c:
encountered a crash in db_dirhash() with a NULL str string, make
sure it's not null before attempting to dereference. |
| 02:04.53 |
CIA-41 |
BRL-CAD:
03brlcad * r36802 10/brlcad/trunk/src/librt/tree.c: reorder
functions to eliminate forward declarations, prefix the hidden
static functions with _rt_ to not confuse them with public
api. |
| 02:12.41 |
CIA-41 |
BRL-CAD:
03brlcad * r36803 10/brlcad/trunk/src/librt/tree.c: quell verbose
compilation warnings, unused params, param checks, dead
code |
| 02:56.48 |
CIA-41 |
BRL-CAD:
03brlcad * r36804 10/brlcad/trunk/src/librt/tree.c: only all
db_dirhash() if name is non-null just to be safe. (cascading up
from an rt_free_rti() crash in mged during pick-edit
prim) |
| 02:57.55 |
CIA-41 |
BRL-CAD:
03brlcad * r36805 10/brlcad/trunk/src/librt/db_tree.c: ws style
comment indent cleanup, prefix hidden static funcs as _db_ to not
confuse them with public API. |
| 03:03.37 |
CIA-41 |
BRL-CAD:
03brlcad * r36806 10/brlcad/trunk/src/librt/db_tree.c: more comment
cleanup, eliminate dead code |
| 03:17.01 |
CIA-41 |
BRL-CAD:
03brlcad * r36807 10/brlcad/trunk/ (7 files in 5 dirs): let the
compiler do it's job. remove the register keyword (public api
declarations being the more important to remove) |
| 04:09.50 |
*** join/#brlcad guillermina
(n=guillerm@189-104-16-190.fibertel.com.ar) |
| 04:15.31 |
CIA-41 |
BRL-CAD:
03brlcad * r36808 10/brlcad/trunk/ (BUGS NEWS): (log message
trimmed) |
| 04:15.31 |
CIA-41 |
BRL-CAD: the
changes applied to more carefully call db_dirhash()
during |
| 04:15.31 |
CIA-41 |
BRL-CAD:
rt_free_rti/rt_clean/db_free_tree/rt_free_soltab fix the crash
reported by |
| 04:15.31 |
CIA-41 |
BRL-CAD:
dwayne kregel whereby mged would fault on a null pointer
dereference after doing |
| 04:15.32 |
CIA-41 |
BRL-CAD: a
killall on some primitive and then attempting a Pick Edit-Primitive
operation. |
| 04:15.34 |
CIA-41 |
BRL-CAD: not
convinced the rtip region reference (and the subsequent soltab
entry it was |
| 04:15.36 |
CIA-41 |
BRL-CAD:
crashing on) doesn't have some other book-keeping problem given the
ordinary |
| 04:39.44 |
CIA-41 |
BRL-CAD:
03brlcad * r36809 10/brlcad/trunk/src/libbu/mappedfile.c: oops,
r36519 removed the if(debug) covering this bu_log(). restore so we
don't keep seeing bu_open_mapped_file() spammage. |
| 04:55.04 |
brlcad |
AHA ... Bob
caused the EDITOR bug! |
| 04:55.53 |
brlcad |
libged
refactoring, he ripped out the DM tests that were being used to
check whether to invoke within an xterm or now |
| 04:55.57 |
brlcad |
*not |
| 04:56.45 |
brlcad |
apparently
broke back in may 2008 |
| 04:57.12 |
brlcad |
attempts to conjure up a fix that doesn't tie libged to
libdm |
| 04:57.23 |
brlcad |
*must* |
| 05:02.53 |
CIA-41 |
BRL-CAD:
03brlcad * r36810 10/brlcad/trunk/BUGS: |
| 05:02.53 |
CIA-41 |
BRL-CAD:
found the cause of the EDITOR bug. libged refactoring removed the
libdm logic, |
| 05:02.53 |
CIA-41 |
BRL-CAD:
which ripped out the code needed to invoke editors from within an
xterm. have |
| 05:02.53 |
CIA-41 |
BRL-CAD: to
rethink how to do this since we obviously shouldn't tie libged to
libdm but |
| 05:02.53 |
CIA-41 |
BRL-CAD: need
to propagate a 'need to invoke from within xterm'
somehow |
| 05:28.10 |
starseeker |
wondered if that might be libged related |
| 06:03.14 |
*** join/#brlcad talcite
(n=matthew@134.117.254.248) |
| 08:20.50 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 10:40.10 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14ABE5.dip.t-dialin.net) |
| 10:54.10 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 14:01.12 |
``Erik |
thinks he has enough to tftp boot arm fbsd on this
thingie |
| 15:10.59 |
Ralith |
this
thingie? |
| 15:53.24 |
``Erik |
openrd-client, an arm based low power
embedded system |
| 15:56.38 |
``Erik |
throwin'
snowballs at my cats, I'm so horrible |
| 15:58.08 |
starseeker |
yeah, snowing
here too |
| 15:58.12 |
``Erik |
um |
| 15:58.13 |
``Erik |
dude |
| 15:58.19 |
``Erik |
you're like a
5 minute drive away from me |
| 15:58.20 |
``Erik |
... |
| 15:58.25 |
starseeker |
ah, that's
right |
| 15:58.51 |
starseeker |
recoveres trash can before it fills up... |
| 15:58.53 |
``Erik |
<-- was
all nervous driving back from the frrst hill vet, on the corne rby
the post office |
| 15:59.15 |
starseeker |
are the cats
attacking the snowballs? |
| 15:59.16 |
``Erik |
btw, you
drive by both a vet and a fancy petstore |
| 15:59.23 |
``Erik |
I scooped
some snow off my back deck |
| 15:59.26 |
starseeker |
ah,
excellent |
| 15:59.48 |
``Erik |
um, 24 and
23, if you drive north one block, turn left onto jarretsville road,
the very first right (on the corner) is the vet |
| 16:00.17 |
``Erik |
off of 23,
just before the 1 junction, behind the wendies, is a fancy pet
supply store, lots of like organic catfood and shit |
| 16:01.03 |
starseeker |
cool |
| 16:01.17 |
starseeker |
yeah, ours
has one particular brand that she eats and nothing else |
| 16:01.18 |
``Erik |
http://local.google.com/?ie=UTF8&ll=39.585266,-76.388688&spn=0.001089,0.003275&z=19
is th evet, dr saad |
| 16:01.52 |
``Erik |
http://local.google.com/?ie=UTF8&ll=39.56895,-76.356206&spn=0.00109,0.003275&z=19
catfood store, entrance on granary, it's tricky |
| 16:02.03 |
``Erik |
if'n ya'll
want, I'll show ya some day |
| 16:02.15 |
starseeker |
cool, thanks
- that might be useful |
| 16:02.38 |
``Erik |
doubts he woulda mentioned if it he didn't think it would
be... |
| 16:02.54 |
``Erik |
and in my old
age, I have a sharp eye for useful vs useless... thus the dismissal
of agar... :D |
| 16:03.01 |
starseeker |
hehe |
| 16:03.06 |
starseeker |
yeah, yeah -
rub it in |
| 16:03.26 |
``Erik |
well,
shit |
| 16:03.29 |
starseeker |
just woke up, not up to speed yet |
| 16:03.37 |
``Erik |
"yeah, uh,
right... doub thtat's going anywhere" ... a week later "uh, it
iddn't go anywhere" |
| 16:03.46 |
``Erik |
<-- looks
for his "I told you so" coupon book |
| 16:04.06 |
``Erik |
O:-) srry,
I'll behave |
| 16:04.17 |
starseeker |
it COULD go
somewhere, but effort vs. need just doesn't cut it for
us |
| 16:04.46 |
``Erik |
this is
fucktarded, this crt has the signal light lit, but isn't displaying
anything... if something sleeps on it, it's gone... have to reboot
for a resync signal |
| 16:04.50 |
``Erik |
need to buy
an lcd I guess :/ |
| 16:05.10 |
starseeker |
poor
you |
| 16:05.30 |
``Erik |
well, I have
to reboot this archaic machine with this halfassed windows 2000
disk image |
| 16:05.38 |
starseeker |
oh, that
one |
| 16:05.38 |
``Erik |
so I can get
'putty' running in serial mode |
| 16:05.43 |
``Erik |
so I can get
a console on my new arm machine |
| 16:05.44 |
``Erik |
:/ |
| 16:05.52 |
starseeker |
so it's kinda
a pearls/swine sorta thing? |
| 16:05.58 |
``Erik |
if I leave it
long enough to sleep the display, I have to start all
over |
| 16:06.11 |
``Erik |
and it's a
long twisty ugly path |
| 16:06.11 |
starseeker |
yeah, that's
suckage |
| 16:06.14 |
``Erik |
full of
grues. |
| 16:06.27 |
``Erik |
WTFF |
| 16:06.50 |
starseeker |
doesn't recall - does your kitten get eaten by the grue too?
'cause it's getting spooky if it does |
| 16:06.52 |
``Erik |
reboot didn't
click the display |
| 16:07.20 |
``Erik |
lamest wyse
term evar. |
| 16:07.43 |
``Erik |
effin' fbsd
doesn't seem to click on cu or tip... :/ says it does, btu no
noist |
| 16:07.45 |
``Erik |
nosie |
| 16:07.49 |
``Erik |
bah! |
| 16:08.26 |
``Erik |
and that r/c
car battery has been charing for an hour on a 10 minute charger,
glad it didn't turn into a fireball while I was gone |
| 16:09.02 |
``Erik |
the bottom is
quite hot |
| 16:09.55 |
``Erik |
I've decided
that these team losi micro thingies are good cat toys |
| 16:14.07 |
starseeker |
hehe |
| 16:14.19 |
starseeker |
(sorry, I'll
be in and out her) |
| 16:14.21 |
starseeker |
here |
| 16:14.42 |
starseeker |
do your cats
have a preference for fuzzy, shiny, or loud toys? |
| 16:14.50 |
starseeker |
(ours goes
shiny every time) |
| 16:21.19 |
starseeker |
hmm... there
could be a problem here with christmas decorations and a cat who
likes shiny... |
| 16:23.11 |
``Erik |
shiny is a
bonus, fuzzy is ok |
| 16:23.35 |
``Erik |
part of the
foil wrapper from some guitar strings is an awesome toy, a dried
out energizer battery is good fun downstairs |
| 16:23.55 |
``Erik |
the boy
carries the fuzzy fishing pole around all the time |
| 16:23.57 |
``Erik |
when I play
guitar, the girl goes psycho over my computer chair |
| 16:26.28 |
``Erik |
rubs hsi face |
| 16:28.47 |
``Erik |
bwahahhaa, I
just sprinted down the hall, kitten was at the base of the stairs,
ran back and into the bathroom, scared teh snot out of her
O:-) |
| 16:28.50 |
``Erik |
poor
cats |
| 16:35.55 |
starseeker |
whoops |
| 16:36.08 |
starseeker |
I think it's
on page 3 of the cat manual - don't run over |
| 16:36.46 |
starseeker |
have yours
discovered the joy of batting pens around? |
| 16:39.41 |
``Erik |
yes |
| 16:39.54 |
``Erik |
but they've
also felt the brutal defeat of my computer chair |
| 16:40.07 |
``Erik |
clockwise
clockwise clockwise clockwise counterclockwise. |
| 16:40.10 |
``Erik |
freaked out
cat |
| 16:40.18 |
Nohla |
starseeker:
such a sweet nickname! :) |
| 16:41.24 |
``Erik |
home teacup
ride for cats |
| 16:41.25 |
``Erik |
O:-) |
| 16:45.00 |
``Erik |
mails nohla some snow O.o |
| 16:57.40 |
``Erik |
I htink the
cats are more scared of the tiny r/c car than anything
else |
| 16:58.55 |
starseeker |
hehe -
robocat |
| 16:59.23 |
starseeker |
``Erik: make
sure you're nice to them some time or you'll have two seriously
messed up cats ;-) |
| 17:00.27 |
starseeker |
updates and compiles BRL-CAD... this machine feels slower all
the time... |
| 17:00.44 |
starseeker |
oh, forgot to
sync stable |
| 17:00.50 |
starseeker |
does that... |
| 17:01.05 |
``Erik |
I'm nice to
them lots |
| 17:01.46 |
starseeker |
do you think
either of them are potential roomba cowboys (or girls, as the case
may be)? |
| 17:02.06 |
``Erik |
no, they
seemed terrified of the car |
| 17:02.31 |
``Erik |
horrible
decision of "do I flee or attack" |
| 17:05.24 |
starseeker |
``Erik:
what's the fastest computer they can pack into a wrist watch these
days? |
| 17:05.53 |
starseeker |
figures when a watch PC gets more powerful than this machine,
it's time to think about upgrading |
| 17:19.27 |
starseeker |
ummm |
| 17:19.44 |
starseeker |
svn merge
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk@$PREV
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk@HEAD
. |
| 17:19.48 |
starseeker |
svn:
'https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/STABLE'
isn't in the same repository as 'https://brlcad.svn.sourceforge.net/svnroot/brlcad' |
| 17:20.57 |
starseeker |
cute -
apparently svn doesn't cue in on sf and sourceforge being
identical |
| 17:30.03 |
CIA-41 |
BRL-CAD:
03starseeker * r36811 10/brlcad/trunk/HACKING: Stick a note into
HACKING about needing to watch sf vs sourceforge in merging
situations. |
| 18:36.48 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 19:33.53 |
CIA-41 |
BRL-CAD:
03starseeker * r36812 10/brlcad/branches/dmtogl/ (232 files in 66
dirs): sync with trunk to r36810 |
| 19:38.32 |
CIA-41 |
BRL-CAD:
03starseeker * r36813 10/brlcad/branches/STABLE/ (376 files in 92
dirs): sync STABLE to trunk r36810 |
| 20:10.08 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 20:20.26 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 20:21.19 |
``Erik |
ghah |
| 20:26.33 |
*** join/#brlcad __monty__
(n=toon@91.182.157.13) |
| 20:27.18 |
__monty__ |
Is this the
right place to ask about getting BRL-CAD to work? |
| 20:27.37 |
``Erik |
possibly |
| 20:27.42 |
``Erik |
what's the
issue? |
| 20:28.57 |
__monty__ |
When I try
running mged I get an error: bash:
/usr/brlcad/rel-7.12.2/bin/mged: Bad CPU type in
executable |
| 20:29.16 |
``Erik |
so you
downloaded a binar package instead of compiling it? |
| 20:29.26 |
__monty__ |
yes |
| 20:29.37 |
``Erik |
that tells me
that you downloaded the package for a machine you do not
have |
| 20:30.03 |
``Erik |
like trying
to use the PPC mac version on an intel mac |
| 20:30.22 |
__monty__ |
Do you know
where I can find the right ppc mac version(g5) then? |
| 20:30.37 |
``Erik |
ah, g5
mac? |
| 20:30.41 |
__monty__ |
yes. |
| 20:30.41 |
``Erik |
do you have
xcode? |
| 20:30.45 |
__monty__ |
fes |
| 20:30.50 |
__monty__ |
*yes |
| 20:30.58 |
``Erik |
if you care
to spend 20 minutes, I would recommend getting the source and
compiling it |
| 20:31.11 |
``Erik |
(most of the
mac using devs have gone to the intel series...) |
| 20:31.21 |
``Erik |
<-- pets
his core duo macbook O:-) |
| 20:31.46 |
__monty__ |
I'm not very
proficient with compiling though. |
| 20:31.49 |
``Erik |
you need
X11.app to run BRL-CAD, too |
| 20:31.56 |
``Erik |
um, it's
"./configure && make instal" |
| 20:32.03 |
``Erik |
u"./configure
&& make install" |
| 20:32.20 |
__monty__ |
with
xcode? |
| 20:32.31 |
``Erik |
no, using a
terminal.app windo |
| 20:32.50 |
__monty__ |
Then why did
you ask if I had xcode? |
| 20:33.06 |
``Erik |
just make
sure you have both X11.app and Xcode installed, crank up an xterm
or terminal.app and do the configure&&make
cycle |
| 20:33.14 |
``Erik |
because xcode
installs gcc, you need gcc |
| 20:33.57 |
__monty__ |
So gcc isn't
installed by default? |
| 20:34.00 |
``Erik |
the gui for
xcode is irrelevant, it's the other stuff it installs |
| 20:34.00 |
``Erik |
no |
| 20:34.07 |
``Erik |
a mac out of
the box does not have gcc |
| 20:34.20 |
``Erik |
part of the
'xcode' package :/ |
| 20:34.46 |
__monty__ |
Is the
xquartz 2.4.0 version of x11 good? |
| 20:34.52 |
``Erik |
sure |
| 20:34.55 |
``Erik |
should
be |
| 20:35.32 |
``Erik |
<-- using
an xquartz himself, doesn't know which version |
| 20:35.53 |
__monty__ |
Should I just
get the latest source? |
| 20:35.59 |
``Erik |
I'd say
so |
| 20:36.25 |
``Erik |
after you run
./configure, look at the options to mkae sure it looks
ok |
| 20:36.35 |
__monty__ |
From
sourceforge or via some kind of version control? |
| 20:36.47 |
``Erik |
you want the
X11 capability enabled, you don't care about opengl, um, tcl/tk
should be built |
| 20:36.53 |
``Erik |
just the
tarball from sf |
| 20:37.01 |
``Erik |
occasionally
the svn version gets broken |
| 20:37.38 |
``Erik |
if you're not
comfortable with gcc and all that, the release source tarball is
safest |
| 20:38.03 |
__monty__ |
Ok, thanks
for helping me by the way. |
| 20:38.09 |
``Erik |
is assuming you "Just want it to work" |
| 20:38.37 |
``Erik |
and I'm a
unix guy,not a mac guy, so'z that's the path to 'success' I'm
trying to drag ya down... :) |
| 20:38.48 |
``Erik |
no problem,
sorry for making ya install shit ya might not wanna
O:-) |
| 20:39.14 |
__monty__ |
likes all kinds of shit. |
| 20:39.55 |
``Erik |
well, shoot,
before I went to the vet, I shoulda used a fedex box insteado fthe
toilet then O:-) *duck* :D |
| 20:41.39 |
__monty__ |
Btw I'm a
supporter of UNIX, mac os is just my favorite gateway to
it. |
| 20:45.56 |
``Erik |
okie, welcome
to the club :D |
| 20:46.46 |
``Erik |
yeh, osX out
of the box lacks X11 support and a compiler... X11.app gives you
the X11 support plus all the headers, Xcode gives you a compiler
and a slew of other dev tools |
| 20:47.24 |
``Erik |
joe shmoe who
buys a mac doesn't have a clue what an 'X11' or a compiler are, so
the default install isn't "burdened" |
| 20:48.04 |
``Erik |
we're compile
friendly on a stock mac with X11 and gcc, we're even autoreconf
friendly there... |
| 20:48.18 |
``Erik |
expect a late
80's unix style gui... :D |
| 20:48.37 |
``Erik |
but ~400 cmd
line tools |
| 20:49.22 |
__monty__ |
Have you even
used everyone of em? |
| 20:49.39 |
``Erik |
does not
parse... huh? |
| 20:49.44 |
*** join/#brlcad talcite
(n=matthew@134.117.254.248) |
| 20:50.13 |
__monty__ |
? |
| 20:50.32 |
``Erik |
"everyone of
em"? whu? |
| 20:50.52 |
__monty__ |
Every one of
those ~400. |
| 20:51.05 |
``Erik |
ahhh, oh hell
no |
| 20:51.09 |
``Erik |
but a couple
dozen, tons |
| 20:51.15 |
``Erik |
I almost
never fire up the gui |
| 20:52.01 |
``Erik |
and the other
paid guys hear me bitching up a storm every time I have to run the
gui |
| 20:52.15 |
__monty__ |
Who needs a
GUI anyway, right? |
| 20:53.10 |
``Erik |
indeed :)
once you get things installed, if you feel masochistic... my avenue
is to run "mged -c" instead of "mged" |
| 20:53.49 |
``Erik |
but I'm odd,
my big adventure this weekend is getting a new arm machine to boot
freebsd when the only usable interface to uboot is via
serial |
| 20:53.57 |
``Erik |
this'll be a
fun weekend :D |
| 20:54.25 |
``Erik |
(openrd-client if you're curious, got it
in fedex shipment a fewd ays ago) |
| 20:55.51 |
__monty__ |
I don't
really have a clue of what a herculian task that will be, the only
thing I know about freeBSD is that I couldn't even get it to run in
a virtual machine. |
| 20:57.45 |
``Erik |
:) fbsd is my
home turf, but this device is not a normal x86 machien... it's an
ARM computer, the bootloader is "uboot" (it has nothing comparable
to a bios), vga does nto start on boot it's all serial,
... |
| 20:58.24 |
``Erik |
the notion of
dumping my old p3 for a fanless micro-machine is just too
hot |
| 20:58.45 |
``Erik |
no FPU, the
BRL-CAD benchmark is pathetic, it's only like 10 vax11/790's or
so |
| 20:59.02 |
``Erik |
but it should
run things like irssi, finch, natd, tinyproxy, etc just
fine |
| 20:59.25 |
``Erik |
my brianfuck
interpreter is 30% faster on this fpu-less thingie than my normal
server |
| 20:59.55 |
__monty__ |
Cool,
brianfuck have to try that out some time. |
| 21:01.04 |
``Erik |
nah, nah ya
don't... I wrote a brainfuck compiler because it's 2 opcodes more
than the proven minimal turing machine, I did it to facilitate
fundamental optization research |
| 21:01.16 |
``Erik |
it's not a
user friendly language :) |
| 21:02.10 |
__monty__ |
I was joking
about your misspelling of the name, you got that right? |
| 21:02.28 |
``Erik |
oh, sorry,
missed that :) |
| 21:03.04 |
``Erik |
if'n yall
wanna fuck brian, that's all ya'lls biz |
| 21:03.49 |
``Erik |
grok, folk
come here who use mac or windows and don't have an inkling of what
a command line might possibly be... |
| 21:03.52 |
``Erik |
:) |
| 21:04.15 |
``Erik |
so'z we have
to take a minimal understanding approach when we start talkin' to
people |
| 21:05.26 |
__monty__ |
G*ddamned I
hate being stuck with leopard, just waited half an hour for a
download, started the installer got the message: 'A version of Mac
OS X 10.6 was not found' |
| 21:05.41 |
``Erik |
hah |
| 21:05.46 |
``Erik |
I'm using
leopard myself |
| 21:05.54 |
``Erik |
they still
support g5 with 10.5? |
| 21:06.06 |
__monty__ |
yeah
=) |
| 21:06.30 |
``Erik |
I'm sad taht
they went intel... the g5 is a beastly chip |
| 21:06.56 |
``Erik |
gcc just
produced shit code for it, so people thought it was slow
:( |
| 21:07.20 |
__monty__ |
It's like you
can read my mind. |
| 21:07.20 |
``Erik |
a decent asm
coder could demolish even the quad core x86 crap, I'd
imagine |
| 21:07.49 |
``Erik |
dude, you're
tlaking to a dude trying to push an ARM fpu-less embedded machine
in as a home server... |
| 21:08.08 |
``Erik |
if you don't
jibe, crank the geek knob to 11, then you'll be here :D |
| 21:09.47 |
``Erik |
if I werne't
so disgusted by how shoddy the guts of linux are, this'd already be
my server |
| 21:12.30 |
__monty__ |
What's your
day to day job? |
| 21:12.51 |
``Erik |
mine? working
on BRL-CAD, actually |
| 21:13.19 |
``Erik |
more time
spent making things "just work" for folk, sysadmin et |
| 21:13.55 |
brlcad |
waves |
| 21:13.56 |
__monty__ |
... Of
course, man I'm thick skulled today. |
| 21:14.02 |
``Erik |
yargh,
brlcad, 'sup? |
| 21:14.11 |
brlcad |
starseeker:
cool, thanks! |
| 21:14.32 |
``Erik |
nah, this is
one of the ... uh... probably, the only modelling software that's
open source and funded |
| 21:14.35 |
brlcad |
``Erik:
*burp* not much |
| 21:15.18 |
``Erik |
brlcad: monty
is trying to get a reasonable version working on his G5,
... |
| 21:15.34 |
brlcad |
and actually
production-quality, in use, heavy featured, .. |
| 21:15.35 |
``Erik |
I'm gonna go
jam out some toons on my gitfiddle, picked up "daytripper" this
morning |
| 21:16.09 |
brlcad |
howdy
__monty__ |
| 21:16.21 |
__monty__ |
yarrrrrr
matey |
| 21:16.29 |
``Erik |
HEY! |
| 21:16.37 |
``Erik |
it's not
september anymore |
| 21:16.53 |
``Erik |
as awesome as
talk like a pirate MONTH is (cuz the 19th ain't 'nuff), it's not
sept |
| 21:16.59 |
``Erik |
ewnch |
| 21:17.21 |
__monty__ |
No way! It's
oktober allready? |
| 21:17.31 |
__monty__ |
Damn I should
get some sleep. |
| 21:17.32 |
``Erik |
almost! |
| 21:18.17 |
``Erik |
bets that if he brought his small amp, crap boxes and old
guitar to work, mumbles eds would shit bricks |
| 21:23.52 |
__monty__ |
M is trying
in A well |
| 21:23.59 |
__monty__ |
Ignore
that. |
| 21:24.51 |
__monty__ |
is trying inkwell |
| 21:26.30 |
``Erik |
I lost a
wheel clip :/ |
| 21:27.55 |
starseeker |
brlcad:
welcome :-) trying to update rel8 but I messed up
somehow |
| 21:28.54 |
__monty__ |
only had to try three times to get that last sentence
right. |
| 21:30.30 |
__monty__ |
Do any of you
know inkwell? |
| 21:32.36 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 21:33.56 |
__monty__ |
Does the
configure & & make cycle take long? |
| 21:34.31 |
__monty__ |
I wrote that
in one GO :-) |
| 21:37.52 |
__monty__ |
Am I getting
too annoying ? |
| 21:39.40 |
__monty__ |
Or are you
guys just not following? |
| 21:39.58 |
starseeker |
irc is
intermittent - we'll be off and on |
| 21:40.06 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 21:40.17 |
``Erik |
not annoying,
just not responsive... is there supposed to be something we react
to? |
| 21:40.24 |
``Erik |
I can't find
the right hot glue gun :/ |
| 21:40.31 |
starseeker |
configure and
make can take a while |
| 21:40.38 |
``Erik |
found one
without ammo and shit I didn't know I had |
| 21:40.40 |
starseeker |
especially on
a slower machine |
| 21:41.07 |
``Erik |
configure&&make can take anywheere
between 3 minutes and an hour... more on slow hw |
| 21:50.53 |
*** join/#brlcad __monty___
(n=toon@163.156-247-81.adsl-dyn.isp.belgacom.be) |
| 21:51.22 |
CIA-41 |
BRL-CAD:
03starseeker * r36814 10/brlcad/branches/rel8/ (232 files in 66
dirs): Sync to trunk r36811 (I think) |
| 21:55.30 |
starseeker |
brlcad: can
we delete src/other/jove in rel8? |
| 21:57.05 |
*** join/#brlcad __monty___
(n=toon@163.156-247-81.adsl-dyn.isp.belgacom.be) |
| 22:01.53 |
starseeker |
ok, diff
checks out we're synced |
| 22:06.31 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 22:30.09 |
*** join/#brlcad __monty___
(n=toon@195.137-247-81.adsl-dyn.isp.belgacom.be) |
| 22:49.06 |
``Erik |
dang
kitties... he's grooming her... its too damn cute |
| 22:51.14 |
__monty__ |
M d kC is
busy. =) |
| 22:51.35 |
__monty__ |
Make is
busy |
| 22:58.10 |
starseeker |
``Erik: hey,
it beats having them fight |
| 23:00.30 |
``Erik |
heh,
true |
| 23:00.42 |
``Erik |
they're
sleeping now, which scares me, cuz they'll be up all
night |
| 23:03.11 |
brlcad |
starseeker:
sure |
| 23:10.47 |
CIA-41 |
BRL-CAD:
03brlcad * r36815 10/brlcad/trunk/src/liboptical/sh_light.c:
quellage |
| 23:11.03 |
__monty__ |
God how
much longer is this going to take... |
| 23:12.31 |
``Erik |
heh |
| 23:12.46 |
``Erik |
the
compile? |
| 23:12.51 |
__monty__ |
make |
| 23:13.06 |
``Erik |
that's it on
now? |
| 23:13.17 |
__monty__ |
Yes. |
| 23:13.24 |
``Erik |
er, what's it
on now? |
| 23:13.45 |
__monty__ |
?
Make. |
| 23:13.58 |
``Erik |
yeh, but
which dir? |
| 23:14.00 |
``Erik |
what
files? |
| 23:14.18 |
``Erik |
src/other is
like half of it... |
| 23:16.00 |
__monty__ |
open N UR BS
primarily. |
| 23:16.26 |
__monty__ |
also bib
tool |
| 23:16.44 |
__monty__ |
lib
tool |
| 23:16.58 |
``Erik |
<-- argued
to NOT include openNURBS mandetorily *shrug* |
| 23:17.24 |
``Erik |
anything c++,
actually... the compile times for c++ ... rapes baby kittens for no
real benefit. |
| 23:17.28 |
``Erik |
:D |
| 23:19.34 |
__monty__ |
Sorry for
my slow æsponIs, this handwriting & recognition cisnt
always equally accurate. |
| 23:21.47 |
__monty__ |
It is fun
to play with though. |
| 23:24.39 |
brlcad |
heh |
| 23:25.02 |
brlcad |
yeah,
__monty__ .. it's not even a third done if it's still in
openNURBS |
| 23:26.05 |
__monty__ |
Is FreeBSD a
server system to you or do you also Use it as a desktop
system. ? |
| 23:27.22 |
brlcad |
once
openNURBS is done it'll be a little over a third to half complete
with the compile |
| 23:27.49 |
__monty__ |
Make is at
src/other/test |
| 23:29.15 |
__monty__ |
./src/other/step/src/test. |
| 23:30.19 |
__monty__ |
Make is the
longest step right? |
| 23:30.20 |
brlcad |
okay, it's
past it then |
| 23:30.23 |
CIA-41 |
BRL-CAD:
03starseeker * r36816 10/brlcad/branches/rel8/ (configure.ac
src/other/Makefile.am src/other/jove/): Won't be needing jove in
Release 8 |
| 23:30.31 |
brlcad |
heh
yes |
| 23:30.44 |
brlcad |
make is
almost the entire time |
| 23:31.00 |
brlcad |
last step is
to install, which just takes a couple minutes |
| 23:31.19 |
__monty__ |
ffeeewwww....... |
| 23:31.59 |
starseeker |
MWAHAHAHA die
jove die |
| 23:33.55 |
__monty__ |
You do know
that jove is the latin name for Zeus, right? |
| 23:33.58 |
``Erik |
__monty__: I
tend to use fbsd as a server all over and a mac running X11.app as
my 'desktop' |
| 23:34.58 |
``Erik |
most of my
computer usage is via ssh into a fbsd system |
| 23:35.25 |
brlcad |
didn't know
that about jove, but it also stands for "Jonathans Own Version of
Emacs" in this context.. an old streamlined emacs fork |
| 23:35.52 |
__monty__ |
X11 as
desktop, on a Mac, sacrilige !!! |
| 23:37.45 |
``Erik |
99% of what I
do is via ssh/screen |
| 23:40.35 |
__monty__ |
brlcad in
latin is actually Iovis , but the i sounds as j and -e is a
termination. |
| 23:41.44 |
__monty__ |
Damn
openNURBS just poped back up. |
| 23:43.54 |
__monty__ |
lets fire
up itUnes and listen some blues to relax. |
| 23:46.24 |
__monty__ |
Ah Sonny
Boy... |
| 23:47.14 |
__monty__ |
Aha
Juke |
| 23:51.44 |
__monty__ |
I'm off to
bed, had enough off watchìng terminal not do anything i'll
check for errors in the morning. Good night all. |
| 02:17.38 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 02:17.38 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 05:42.29 |
*** join/#brlcad ibot
(i=ibot@slc133.modem.xmission.com) |
| 05:42.29 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 07:36.34 |
*** join/#brlcad ibot_
(i=ibot@slc156.modem.xmission.com) |
| 07:36.34 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 07:49.14 |
*** join/#brlcad ibot
(i=ibot@slc156.modem.xmission.com) |
| 07:49.14 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 09:25.16 |
*** join/#brlcad __monty__
(n=toon@195.137-247-81.adsl-dyn.isp.belgacom.be) |
| 10:08.25 |
__monty__ |
Anyone
on? |
| 10:15.00 |
__monty__ |
I get Bus
error When trying to run mged. |
| 11:18.31 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 11:18.31 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 12:23.01 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 13:06.00 |
__monty__ |
Any help on
Bus error when starting mged? |
| 13:11.20 |
``Erik |
can ya run it
in gdb? |
| 13:40.22 |
*** join/#brlcad jesica_
(n=jesica@201.255.230.172) |
| 14:23.44 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 14:23.44 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 14:23.44 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 14:23.44 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 14:23.44 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 14:23.44 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 14:23.44 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 14:23.44 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 14:23.44 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 14:23.48 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 14:23.49 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 15:16.07 |
__monty__ |
Are you still
on? |
| 18:10.35 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14A7FD.dip.t-dialin.net) |
| 18:22.07 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 20:06.38 |
starseeker |
winces as all his ram and swap are eaten by a step-g attempt
and he is forced to reboot... |
| 20:07.46 |
starseeker |
wonder how I
can reserve some ram just for X11 and related "basic" desktop stuff
so no app ever grabs all the memory... |
| 20:08.07 |
starseeker |
or I suppose
I could reinstall and up the swap... |
| 20:10.13 |
``Erik |
O.O |
| 20:10.19 |
``Erik |
um |
| 20:10.24 |
``Erik |
use a
slightly less retarded os? :D |
| 20:10.48 |
``Erik |
last time I
oom'd linux much, its termination criteria were... very...
retarded |
| 20:11.35 |
``Erik |
I had some
small utilities I coded up to try to control swap vs ram stuff,
simply never needed 'em after moving to fbsd... :) |
| 20:11.43 |
``Erik |
"soil" was
the one I tended to use the most I think |
| 20:12.00 |
``Erik |
it pissed all
over memory, forcing idle procs down into swap |
| 20:12.44 |
``Erik |
has managed to break the serial console on his new toy, but
it still boots and is ssh-able :/ |
| 20:26.16 |
jesica_ |
starseeker,
are you there? |
| 20:26.39 |
jesica_ |
there
something not cery clear for me in the manual |
| 20:26.45 |
jesica_ |
cery/very |
| 20:30.24 |
``Erik |
he may be
busy trying to figure out how to make linux not suck, throw your
query out and idle until someone can answer it? :D |
| 20:31.52 |
jesica_ |
"If you type
a z and your cursor is still in the Graphics Window, you will send
your design spinning." that means it will rotate? |
| 20:33.06 |
jesica_ |
the only
place where i heard the spin word was in chemistry: P |
| 20:35.05 |
brlcad |
starseeker:
hehe, how much memory do you have? |
| 20:36.42 |
brlcad |
jesica_: yes,
it means it will begin rotating |
| 20:36.54 |
jesica_ |
brlcad,
thanks |
| 20:37.03 |
brlcad |
rotating
about the z axis if you press z |
| 20:37.18 |
brlcad |
and reverse
direction if you press Z |
| 20:37.34 |
brlcad |
and about the
other two axes for x and y, 0 to stop |
| 20:38.02 |
jesica_ |
brlcad, im
not in that page yet :) |
| 20:38.09 |
jesica_ |
but thank
you |
| 20:38.36 |
jesica_ |
remain im
just doing the translating, not using brlcad |
| 20:39.07 |
jesica_ |
brlcad, why
you have a nickname so important for this chanel? |
| 20:39.59 |
jesica_ |
ate "do", mmm |
| 20:40.38 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 20:43.04 |
starseeker |
jesica_: he
is the project lead for the BRL-CAD open source project |
| 20:43.42 |
starseeker |
brlcad: 1.5
gig ram, waaaay to little swap (500 meg) |
| 20:43.47 |
jesica_ |
starseeker,
:) hi |
| 20:43.52 |
starseeker |
howdy
:-) |
| 20:44.27 |
starseeker |
installed before he had an external hard drive - begrudged
handing over several gigs for a proper swap
partition |
| 20:48.27 |
starseeker |
really doesn't want to reinstall again until he gets a new
machine - this configuration has had all the major gotchas ironed
out (event got virtualbox working) |
| 20:54.07 |
starseeker |
``Erik: I
might be convinced to take a run at FreeBSD the next go-around, or
maybe opensolaris - hate to give up all the OS specific knowledge,
but would be an interesting experience |
| 20:54.27 |
starseeker |
(as long as
sbcl runs well, of course ;-) |
| 20:56.11 |
*** join/#brlcad __monty__
(n=toon@d51A543C3.access.telenet.be) |
| 20:56.52 |
__monty__ |
Anyone know
anything about a Bus error when trying to launch
brlcad? |
| 20:57.06 |
``Erik |
sbcl works
quite nicely on fbsd, just make sure to enable threading when you
run the 'make configure' step (uh, I think gentoo forces you to
edit a file to set those? fbsd gives you a 'dialog' driven
configurator) |
| 20:57.44 |
``Erik |
there should
be no bus error, have you tried running it in gdb to see what
actually fails? can you give us info on version, how you got it,
operating system, hw, etc? |
| 20:59.26 |
``Erik |
rubs his chin and contemplates wasting energy to regret
knocking the fuzz of |
| 20:59.29 |
``Erik |
off |
| 21:00.42 |
__monty__ |
I don't know
how to run it in gdb, I'm trying to run latest version of the
source from SF on an intel mac this time. |
| 21:01.40 |
``Erik |
ok, from the
command line (xterm or Terminal.app... you need X11.app running),
run "gdb /usr/brlcad/bin/mged" and it'll give you a prompt, type in
"run" and hit enter |
| 21:02.33 |
``Erik |
if it's bus
faulting, it'll say so in that window, say where it crashed, and
give you a prompt again, you need to run "backtrace" and paste the
results to http://paste.bzflag.bz/ or http://paste.lisp.org |
| 21:03.00 |
``Erik |
(latest
version being the tar.gz file, not the subversion
checkout?) |
| 21:03.25 |
``Erik |
7.16.2 or
something? heh |
| 21:04.08 |
__monty__ |
yes
tar.gz |
| 21:05.14 |
``Erik |
intel mac is
a 1st tier platform for BRL-CAD, it really should work... was
/Applications/Utilities/X11.app running when you tried to start
mged? |
| 21:05.34 |
__monty__ |
no but it did
launch |
| 21:05.34 |
``Erik |
(or xquartz,
which is what I use on my home mac) |
| 21:05.49 |
``Erik |
ok, then the
gdb backtrace output is the next step |
| 21:06.46 |
__monty__ |
from where to
where do I copy? |
| 21:07.04 |
``Erik |
starseeker: I
imagine that if you give go at another OS, you'll learn even more
about the one you're leaving... I know I learned a LOT about linux
by going to bsd, and a lot about x86 by using sparc and
mips |
| 21:07.13 |
``Erik |
gdb should be
installed if you have xcode |
| 21:07.24 |
``Erik |
as
/usr/bin/gdb |
| 21:07.28 |
``Erik |
run it in a
terminal window :) |
| 21:08.10 |
__monty__ |
I have the
output, I just don't know which part I should copy =S |
| 21:08.50 |
``Erik |
um, from
backtrace? should be a full printout of the call stack... paste
every from the command to the next prompt to one of those websites
I mentioned |
| 21:09.36 |
__monty__ |
starting from
run or backtrace? |
| 21:09.43 |
``Erik |
um, all of it
*shrug* |
| 21:09.55 |
``Erik |
(thus the
site, instead of irc...) :) |
| 21:12.24 |
``Erik |
waits for the link on http://pastebin.bzflag.bz/ |
| 21:15.09 |
CIA-41 |
BRL-CAD:
03brlcad * r36817 10/brlcad/trunk/NEWS: back-annotate the step-g
work from Keith Bowman. still need to add in the summary
paragraphs, but annotate all of the 7.16 releases with the
continued improvements. |
| 21:20.48 |
__monty__ |
sorry that it
took so long, I was trying to paste too much. |
| 21:20.56 |
__monty__ |
Here's the
link http://pastebin.bzflag.bz/m59a77916 |
| 21:30.42 |
jesica_ |
starseeker,
firs file done :) |
| 21:31.11 |
jesica_ |
ill send it
to a friend for a review before to send it to you |
| 21:33.31 |
``Erik |
X_open_dm()
interesting |
| 21:35.40 |
``Erik |
I d'no what's
up there, looks like a sig11, but you compiled with debugging
disabled and it seems to work on other machines :/ willing to
re-compile with optimization turned off and debugging stuff
enabled? |
| 21:36.32 |
__monty__ |
sure how do I
set the flags? |
| 21:37.32 |
``Erik |
when you run
configure, add --disable-optimized --enable-debug |
| 21:37.45 |
``Erik |
make clean,
configure, build... |
| 21:40.35 |
starseeker |
jesica_:
excellent! :-) |
| 21:41.28 |
jesica_ |
now, to
study! I wana kill myself :P |
| 21:44.24 |
``Erik |
O.o |
| 21:45.29 |
starseeker |
jesica_: hang
in there, that studying pays off |
| 21:46.57 |
``Erik |
just a bit
loca? O.o |
| 21:49.20 |
jesica_ |
``Erik, not
afraid of crazy women? careful what you say :) |
| 21:49.45 |
``Erik |
afraid? no...
seem to have a history |
| 21:50.14 |
``Erik |
studying
what? schoolwork? or something about BRL-CAD? |
| 21:54.07 |
``Erik |
curses up a storm because he cooked some stew for lunch that
he'd intended for making a breadbowl :/ |
| 21:55.46 |
jesica_ |
studying
algorithm |
| 21:56.48 |
``Erik |
ah, graph
theory, trees, etc? good luck with that... I love the subject, but
when I took courses, the teacher was very much focused on the math,
not the theory |
| 21:57.29 |
``Erik |
I bought a
school targetted text book because it had a section over a certain
data structure I was interested in O.o (trie's) |
| 21:57.50 |
jesica_ |
ive studied
all this thingf in discrete math? |
| 21:57.59 |
``Erik |
zapp hack on
a trie gives you fast easy completion |
| 21:58.47 |
``Erik |
hm, perhaps a
language barrier, the discrete mathematics courses I took had very
little relation to the fundamental algorithm courses.... mebbe I
just don't understand the correlation |
| 22:00.09 |
``Erik |
either way,
crazy woman, enjoy your study :) if you're horribly stuck on a
subject, there're folk in this channel with much experience and
knowledge, may be of use.. if you try to cheat, don't be surprised
when someone says "do your own damn homework" :) |
| 22:01.07 |
jesica_ |
im not
studying yet |
| 22:01.28 |
jesica_ |
im looking
for someone to do a second review of the tranlation |
| 22:01.31 |
jesica_ |
:P |
| 22:02.19 |
``Erik |
<-- can
help on english, some japanese, and a tiny german... definitely not
anything in the es_ directory... perhaps when brlcad wakes, he can
assist? he lived in panama for a while and picked up some
language |
| 22:02.49 |
*** join/#brlcad talcite
(n=matthew@69-196-189-208.dsl.teksavvy.com) |
| 22:03.17 |
``Erik |
if we put
your work out publically, perhaps someone will notice and
comment... open source, yay |
| 22:04.35 |
jesica_ |
thats
true |
| 22:04.45 |
jesica_ |
but i prefere
to do it the best i can |
| 22:04.56 |
__monty__ |
Gn
everyone. |
| 22:04.59 |
``Erik |
a common
deficiency |
| 22:05.17 |
``Erik |
how's the
fresh build going, monty? going to have another bt for us soon?
:) |
| 22:06.12 |
__monty__ |
I don't know,
openNURBS (grinds teeth while saying that) is still popping up all
over the place. |
| 22:07.13 |
``Erik |
jesica: if
you spend all your time trying to polish your work, you avoid the
true advantage of the open source scheme... even if it's crap,
throw it out! soon! often! the downfall of keeping it private is
referred to as a "polished turd" in some US subcultures, ya spend
all your time focused on making it perfect when there's a
fundamental flaw |
| 22:08.01 |
``Erik |
monty:
openNURBS is mebbe 50% or so of the compile time... once it hits
libbu, it'll cruise alone quick |
| 22:09.08 |
__monty__ |
XML_CATALOG_FILES is the most popular line
right now |
| 22:09.43 |
starseeker |
uh - you're
in the docs then |
| 22:09.45 |
starseeker |
almost
done |
| 22:10.27 |
starseeker |
heads to store |
| 22:10.41 |
``Erik |
dang xslt
crap |
| 22:10.46 |
__monty__ |
tails to store |
| 22:11.00 |
``Erik |
if I figure
out who did that... and the tkhtml3... there'll be some
whuppin' |
| 22:11.08 |
``Erik |
car
cdr? |
| 22:11.36 |
__monty__ |
cheers, we need more whuppin' up in here! |
| 22:12.11 |
__monty__ |
just entered 'make install' |
| 22:12.44 |
``Erik |
(starseeker
imported the tkhtml3 stuff, did all the xsltproc crap, ...
) |
| 22:13.09 |
``Erik |
makes my
crimes of automake/autoconf seem trivial :D |
| 22:14.34 |
__monty__ |
Ok, still
getting Bus error. |
| 22:14.53 |
``Erik |
and does the
backtrace now include function, file, line number, etc? |
| 22:15.49 |
__monty__ |
It looks very
similar to the previous one. |
| 22:16.18 |
``Erik |
just
X_open_dm(), not X_open_dm():4123 ? |
| 22:16.48 |
__monty__ |
#0
0x0012f90b in X_open_dm (interp=0xb6cc08, argc=6, argv=0xbfffcdd4)
at dm-X.c:376 |
| 22:17.06 |
``Erik |
376, ok,
that's important |
| 22:17.58 |
__monty__ |
Maybe this
part is helpful: Program received signal EXC_BAD_ACCESS, Could not
access memory. |
| 22:17.58 |
__monty__ |
Reason:
KERN_PROTECTION_FAILURE... |
| 22:18.32 |
``Erik |
nah, tha'ts
just a sig11 |
| 22:18.43 |
__monty__ |
okie |
| 22:19.35 |
``Erik |
if I were to
try to talk about changing source to get ot this, would you be
comfortable altering the source and trying? |
| 22:20.06 |
__monty__ |
sure. If it's
a small alteration. |
| 22:20.10 |
``Erik |
yuh oh,
starseeker has been all over this file lately, no wonder it's all
busted |
| 22:20.48 |
``Erik |
(he is so
gonna kick my arse on tuesday) |
| 22:21.18 |
__monty__ |
hopes you get that on camera. |
| 22:26.03 |
``Erik |
yuh oh, we
don't have version tags/branches |
| 22:26.53 |
``Erik |
'k, looks
like dmp isn't being set right |
| 22:27.56 |
``Erik |
which
probably means BU_GETSTRUCT fails, whihc means out of
memory |
| 22:29.14 |
__monty__ |
which tells
us... |
| 22:29.53 |
``Erik |
not sure,
lack of system memory? *shrug* |
| 22:30.20 |
``Erik |
if you have
subversion, mebbe the latest version will work? |
| 22:30.25 |
__monty__ |
RAM or other
kind |
| 22:30.40 |
``Erik |
ram and swap,
I"d imagine, I dunno |
| 22:31.14 |
``Erik |
to be honest,
I was kinda hoping brlcad would step in and take over so'z I could
go nap O:-) |
| 22:31.59 |
__monty__ |
Ok than, I'll
give up for today, Bus error you may have won the battle but the
war isn't over yet. |
| 22:32.26 |
``Erik |
:) sorry I
couldn't be more helpful, this delves into pieces I
avoid |
| 22:32.49 |
__monty__ |
No problem,
I'm happy you tried. |
| 22:33.05 |
``Erik |
starseeker
and brlcad probably know a LOT more about that piece than I
do |
| 22:33.15 |
``Erik |
they might be
on tomorrow morning |
| 22:33.35 |
__monty__ |
I do find all
this quite strange since I know I ran mged some time. |
| 22:33.52 |
``Erik |
yeh, I don't
understand why it'd crash like that |
| 22:34.01 |
__monty__ |
Morning gmt?
I'm in the CET zone. |
| 22:34.15 |
``Erik |
daytime
GMT-5, morning GMT |
| 22:34.33 |
``Erik |
most of the
developers are on the US |
| 22:35.09 |
``Erik |
in ~15-20
hours? |
| 22:35.38 |
``Erik |
starseeker
keeps normal hours, brlcad is all over the map *shrug* lurk and
read backlog :) |
| 22:35.46 |
``Erik |
it'll get
figured out eventually |
| 22:36.26 |
__monty__ |
Ok that's CET
- 6, morning is ~8-10 o' clock so that's from 14-16, I'll try
catching them. |
| 22:36.41 |
__monty__ |
Good night to
you sir. |
| 22:37.15 |
``Erik |
we all read
backlog, so just leave your irc client attached and catch up
*shrug* :) catch ya later, dude |
| 22:37.54 |
__monty__ |
Can't,
running on a laptop, have to shut down. |
| 22:38.15 |
``Erik |
ok, hopefully
we'll have a solution for you when you're back next :) |
| 22:38.37 |
__monty__ |
Thanks for
all the help by the way. |
| 22:40.29 |
__monty__ |
left the building. |
| 23:03.42 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14AA5E.dip.t-dialin.net) |
| 23:10.09 |
brlcad |
Nohla: cool,
so you're done with one of the exercises? |
| 23:10.16 |
brlcad |
can you
upload it somewhere? |
| 23:11.05 |
Nohla |
i have
starseeker parsonal email, maybe there? |
| 23:11.17 |
Nohla |
but ive done
just one review |
| 23:11.58 |
Nohla |
nobody else
can read it right now |
| 23:12.19 |
Nohla |
and i cant
correct myself |
| 23:12.36 |
brlcad |
ideally, can
you upload it here:
https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804 |
| 23:13.08 |
brlcad |
if you upload
it there as an attachment, then we can all get to it |
| 23:13.38 |
Nohla |
ok |
| 23:13.57 |
Nohla |
let me see if
i can convince another friend to correct it |
| 23:14.26 |
brlcad |
okay |
| 23:14.51 |
brlcad |
when you
upload it as an attachment, you can continue to upload improved
versions too |
| 23:14.56 |
brlcad |
doesn't have
to be final |
| 23:16.19 |
brlcad |
hmm..
__monty__'s backtrace is a bit dated |
| 23:17.07 |
brlcad |
can't be a
BU_GETSTRUCT failure.. that'd be a bomb |
| 23:17.35 |
brlcad |
not a bad
access |
| 23:20.58 |
brlcad |
ah yes, so
376 for the .2 release was: |
| 23:21.21 |
brlcad |
dmp->dm_width =
DisplayWidth(pubvars->dpy, DefaultScreen(pubvars->dpy)) -
30; |
| 23:23.00 |
brlcad |
so dmp or
pubvars are nfg |
| 23:24.16 |
brlcad |
~botmail for
__monty__: if you still have that gdb session, try running "p dmp"
and "p pubvars" after it stops at dm-X.c:376 |
| 23:38.57 |
CIA-41 |
BRL-CAD:
03brlcad * r36818 10/brlcad/trunk/src/libdm/dm-X.c: |
| 23:38.57 |
CIA-41 |
BRL-CAD: make
X11 function calls instead of using the macros so that we can
hopefully get |
| 23:38.57 |
CIA-41 |
BRL-CAD: some
better data validation and stack trace information if/when
something goes |
| 23:38.57 |
CIA-41 |
BRL-CAD:
horribly wrong. crash reported while getting DisplayWidth of the
default |
| 23:38.57 |
CIA-41 |
BRL-CAD:
screen. |
| 23:45.27 |
CIA-41 |
BRL-CAD:
03brlcad * r36819 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-rtgl.c):
make the two other X windowing interfaces match dm-X, using X11
funcs instead of macros for better debugging, seeing if we
encounter a negative screen number. |
| 23:46.37 |
brlcad |
~botmail for
__monty__: I made some minor changes that should help debugging,
test appreciated for you to checkout latest svn (not the tarball)
and then try getting the crash backtrace again in gdb |
| 23:47.39 |
*** mode/#brlcad [+o brlcad] by ChanServ |
| 00:57.31 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 01:25.49 |
*** join/#brlcad jesica__
(n=jesica@201.255.230.172) |
| 01:39.32 |
brlcad |
jesica__:
nice work on the translation |
| 01:39.33 |
brlcad |
se ve
bien |
| 01:40.24 |
jesica__ |
brlcad, im
doing the lastest correction |
| 01:40.38 |
jesica__ |
definitly the
last, i swear |
| 01:41.10 |
jesica__ |
there are
various thing i note in pdf |
| 01:42.36 |
jesica__ |
there are two
things i cant change |
| 01:43.00 |
jesica__ |
the advertise
<caution> and <note> :( |
| 01:47.33 |
brlcad |
the english
can be changed too :) |
| 01:49.21 |
brlcad |
oh and when I
mentioned submitting a patch, I didn't mean an entire new
sourceforge project :) |
| 01:52.23 |
jesica__ |
i didnt do
that, my subcription is still on process :P |
| 01:52.46 |
brlcad |
there's no
subscription required.... |
| 01:52.49 |
jesica__ |
a friend have
done it for me |
| 01:53.01 |
brlcad |
you just
create an account, submit the patch |
| 01:53.23 |
jesica__ |
well, the
account in sourgeforce ned confirmation |
| 01:53.31 |
jesica__ |
ned/need |
| 01:53.45 |
brlcad |
ah, and that
takes time? :) |
| 01:53.54 |
brlcad |
should have
sent an instant confirmation |
| 01:55.29 |
mafm |
brlcad: the
Google IO 2009 video is a bit... below par :P |
| 01:55.57 |
brlcad |
mafm: which
video?? |
| 01:56.05 |
jesica__ |
brlcad, ive
tried to do it again but said that i was registered |
| 01:56.07 |
mafm |
at least the
one from Mr Linus was more... fun |
| 01:56.23 |
mafm |
brlcad: the
video about "the myth of the genius programmer" that you posted to
the ml a while ago |
| 01:56.25 |
jesica__ |
but when
entrying, it said i need confirmation |
| 01:56.29 |
jesica__ |
:( |
| 01:59.50 |
brlcad |
mafm: not
sure what you mean by "below par", wasn't meant to be earth
shattering, more just lots of interesting points |
| 02:00.02 |
brlcad |
particularly
with regards to egos and hidden development practices |
| 02:03.02 |
mafm |
I actually
expected to give more examples, or actual examples |
| 02:03.21 |
brlcad |
*shrug* |
| 02:03.25 |
brlcad |
expectations
amiss ;) |
| 02:03.27 |
mafm |
in the "sweet
spot" thing about when to involve ppl, there are no examples at all
:) |
| 02:03.56 |
mafm |
just like...
"don't get ppl involved too early, also not too late!" |
| 02:04.33 |
brlcad |
jesica__:
what's your username? |
| 02:04.41 |
mafm |
the topic
looked very promising for me, though |
| 02:05.05 |
jesica__ |
mmm i forgot
jajaja |
| 02:05.16 |
mafm |
I guess that
you were trying to make the same point, directed at some devels
:P |
| 02:05.29 |
jesica__ |
but it should
be giudicejesica |
| 02:05.48 |
brlcad |
there's not a
formula you apply, more a set of guidelines to consider and apply,
case by case basis |
| 02:07.30 |
brlcad |
jesica__:
sent you a test message |
| 02:08.20 |
brlcad |
jesica__:
https://sourceforge.net/account/registration/recover.php |
| 02:08.39 |
brlcad |
escoje email
recovery |
| 02:08.58 |
brlcad |
ponga tu
email |
| 02:09.49 |
brlcad |
if that
doesn't work, you either have a spam filter that thought the
account registration was spam or you had a typo in you email
address when you registered |
| 02:10.06 |
mafm |
elige, pon
:) |
| 02:10.31 |
jesica__ |
brlcad, so i
can change <note> by <nota> without a
trouble? |
| 02:10.54 |
brlcad |
jesica__: no,
everything within <> should not be translated, they're
tags |
| 02:11.22 |
brlcad |
like html,
<html><head></head>... you don't translate
those, only what is between them |
| 02:12.02 |
brlcad |
ahh, is it
writing "Note:" in the output somewhere? |
| 02:12.17 |
brlcad |
if so, that's
not something in the xml file .. we can fix that |
| 02:14.29 |
jesica__ |
mmm, so i
leave it and you fix it? |
| 02:14.37 |
brlcad |
yeah |
| 02:15.13 |
brlcad |
a "note" to
starseeker to do something about that when he integrates your
change ;) |
| 02:15.27 |
brlcad |
needs a .es
stylesheet customization |
| 02:15.48 |
brlcad |
or better
yet, get the english one out |
| 02:16.11 |
brlcad |
or gettext
the stylesheet if it's more pervasive |
| 02:17.13 |
brlcad |
jesica__:
https://sourceforge.net/apps/trac/sourceforge/wiki/Support |
| 02:17.50 |
brlcad |
maybe
tomorrow you can get ahold of someone on irc, to tell them your
account registration e-mail never arrived |
| 02:17.52 |
jesica__ |
brlcad, the
firs image is too large, you should fix that too |
| 02:18.18 |
brlcad |
jesica__:
definitely :) |
| 02:18.54 |
brlcad |
jesica__: so
if you're going to be doing more translations, we can get you set
up with svn as soon as you have a sourceforge account
:) |
| 02:19.56 |
jesica__ |
in one line,
say that both DELETE and BACKSPACE erase the character on the
lefth, thats true? |
| 02:21.12 |
brlcad |
yes |
| 02:21.21 |
CIA-41 |
BRL-CAD:
03brlcad * r36830 10/brlcad/trunk/doc/docbook/lessons/es/: initial
stub for the spanish translations that jesica has been working
on |
| 02:22.54 |
jesica__ |
and just one
thing before to finish |
| 02:23.17 |
brlcad |
it's never
really finished :) |
| 02:23.18 |
jesica__ |
rename a
sphere, f.e., is to create one |
| 02:23.42 |
starseeker |
brlcad: not
really sure how to do language specific stylesheets |
| 02:23.52 |
starseeker |
will have to
look into it when my headache goes away |
| 02:23.56 |
brlcad |
starseeker:
we really shouldn't |
| 02:24.01 |
brlcad |
ideally
should be language agnostic |
| 02:24.30 |
brlcad |
if we have
to, can let gettext do the substitutions on the fly |
| 02:26.20 |
jesica__ |
mmm, ive done
silly thing on mi laptop :P, could you send me the link to download
the source code again? |
| 02:26.30 |
starseeker |
oh:
http://oreilly.com/catalog/docbook/chapter/book/ch04.html#AEN5446 |
| 02:26.31 |
brlcad |
~cadsvn |
| 02:26.32 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 02:26.51 |
starseeker |
jesica__: you
can install subversion? |
| 02:27.22 |
brlcad |
starseeker:
ah, nice find.. there ya go |
| 02:27.24 |
starseeker |
we need a
"language driver" |
| 02:27.42 |
starseeker |
yay, one more
thing to mess up the docbook build with ;-) |
| 02:28.29 |
starseeker |
will need to
generate the driver file from a .in file |
| 02:28.54 |
starseeker |
doggone it,
hate to mess with that level of docbook but I guess no
choice |
| 02:29.02 |
starseeker |
would
probably have had to anyhow... |
| 02:29.46 |
brlcad |
the
stylesheets needed to be ripped a new one regardless |
| 02:30.03 |
starseeker |
heh - not
liking the defaults, eh? |
| 02:30.29 |
brlcad |
noep |
| 02:30.43 |
jesica__ |
"To recall
the sphere, type the command on the Command Line as
follows:" |
| 02:30.43 |
starseeker |
remembers all the fun in the firebird docs.. time to look at
that again, I guess |
| 02:31.08 |
jesica__ |
draw ==
recall? |
| 02:31.32 |
starseeker |
er - redraw
probably |
| 02:31.35 |
brlcad |
basically,
yes |
| 02:31.37 |
brlcad |
to draw it
again |
| 02:31.44 |
brlcad |
to draw the
sphere again, ... |
| 02:31.47 |
jesica__ |
oh
ok |
| 02:31.49 |
jesica__ |
thanks |
| 02:33.47 |
starseeker |
brlcad: the
other major problem I am aware of with translations is if we make
the file list variable based on $LANG or some such, won't the build
crap out if the es or whatever directories don't have all the xml
files the en directories do? |
| 02:33.49 |
jesica__ |
brlcad, now
your are wrong, it finally finished |
| 02:34.02 |
brlcad |
what
finished? |
| 02:34.09 |
starseeker |
translating I
think :-) |
| 02:34.13 |
brlcad |
oh YOU are
finished.. heh |
| 02:34.15 |
jesica__ |
starseeker,
yes |
| 02:34.19 |
brlcad |
the document
itself is never finished :) |
| 02:34.20 |
jesica__ |
jajjaja |
| 02:34.23 |
brlcad |
jej |
| 02:34.33 |
jesica__ |
yes, since
yesterday |
| 02:34.57 |
brlcad |
even the
english isn't "finished".. it's just where it is now |
| 02:37.44 |
brlcad |
starseeker:
absolutely, once you add in l10n it really needs a
driver |
| 02:38.10 |
brlcad |
you need more
complex logic to build the docs |
| 02:38.10 |
starseeker |
um -
driver? |
| 02:38.12 |
brlcad |
a
script |
| 02:38.19 |
brlcad |
or
program |
| 02:38.26 |
starseeker |
nnnooooooo.... (trails off
pathetically) |
| 02:38.28 |
brlcad |
something
where you can embed the logic it needs |
| 02:38.56 |
brlcad |
could still
keep it simple and continue to itemize |
| 02:39.12 |
starseeker |
no, we need
scalable |
| 02:39.29 |
brlcad |
separate
Makefile.am into a Makefile.en and Makefile.es .. include them in
the Makefile.am |
| 02:39.41 |
starseeker |
I just can't
believe we finally got a nice (almost) working parallel docbook
build using automake and now we get to blow it to hell |
| 02:40.02 |
brlcad |
that way you
could even keep the Makefiles down with the XML files, and
recursively include them up |
| 02:40.35 |
starseeker |
well...
maybe |
| 02:40.52 |
brlcad |
so the es
build file would only be as complex as the quantity of files that
have been converted |
| 02:41.21 |
starseeker |
can includes
be conditionalized? |
| 02:41.43 |
starseeker |
or I suppose
it doesn't matter if they live inthe files |
| 02:42.50 |
brlcad |
i believe so,
but shouldn't matter |
| 02:43.59 |
starseeker |
oh, while I'm
thinking about it - I have a hunch that parallel build failure is
in some way shape or form the falt of xsltproc |
| 02:47.42 |
starseeker |
unfortunately, the alternatives all seem
to be java based |
| 03:02.20 |
starseeker |
emails xslt list |
| 03:11.05 |
*** join/#brlcad dli (n=dli@69.172.97.211) |
| 04:20.35 |
*** join/#brlcad talcite
(n=matthew@69-165-156-198.dsl.teksavvy.com) |
| 05:11.42 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.241) |
| 05:32.26 |
*** join/#brlcad talcite
(n=matthew@69-196-132-106.dsl.teksavvy.com) |
| 06:30.29 |
*** join/#brlcad talcite_
(n=matthew@69-165-151-93.dsl.teksavvy.com) |
| 11:19.28 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 11:19.28 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 11:19.28 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 11:26.04 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 11:26.04 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 11:59.29 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 11:59.29 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 11:59.29 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 12:07.04 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 12:07.04 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 12:07.04 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 12:13.44 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 12:13.44 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 12:13.44 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 12:16.36 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 12:16.36 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 12:21.24 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 12:21.24 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 12:21.24 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 12:21.24 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 12:21.24 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 12:21.25 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 12:33.15 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 12:33.15 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 12:56.25 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
| 13:45.17 |
brlcad |
http://www.junauza.com/2009/12/free-and-open-source-cad-software-for.html |
| 13:49.02 |
alex_joni |
another nice
(although really young one) is HeeksCad (also OpenCascade
based) |
| 13:49.12 |
alex_joni |
http://code.google.com/p/heekscad/ |
| 14:31.13 |
``Erik |
wait, what?
O.o damn, I musta been confused |
| 14:51.16 |
``Erik |
that whole
voodoo needs to be redone :/ |
| 14:52.05 |
brlcad |
the
metavoodoo? |
| 14:52.26 |
``Erik |
heh, yeah,
walking meatball voodoo |
| 14:52.59 |
``Erik |
the find
intersection function will be core to the next ...
implementation |
| 14:53.25 |
``Erik |
will probably
cost performance, but *shrug* |
| 15:04.13 |
starseeker |
brlcad:
FreeCAD looks great, but I have yet to successfully compile it even
on gentoo |
| 15:04.39 |
starseeker |
heh - nifty,
they used my dxf probe model screenshot |
| 15:06.11 |
starseeker |
varkon I've
got working but haven't put the time into actually figuring out -
it's GPL so we can't use it anyhow... |
| 15:08.00 |
starseeker |
that's easily
one of the niftier varkon screenshots I've seen |
| 15:09.38 |
starseeker |
one
interesting thing about varkon is they apparently do parametric
stuff |
| 15:12.43 |
brlcad |
hates paperwork |
| 15:13.19 |
brlcad |
thinks it's funny they used the tux render |
| 15:13.30 |
brlcad |
but we did
get top billing, good times ;) |
| 15:14.12 |
starseeker |
yes, that's
interesting - particularly since FreeCAD is kicking our butts in
the "modern CAD GUI with drawing generation and stuff..."
department |
| 15:14.37 |
starseeker |
suggests an
intelligent reviewer :-) |
| 15:14.46 |
brlcad |
they lack
most of the nuts and bolts, actual usefulness |
| 15:15.01 |
brlcad |
but yeah, gui
is not too shabby |
| 15:15.09 |
brlcad |
wouldn't take
much to one-up them though |
| 15:15.14 |
starseeker |
hehe |
| 15:16.13 |
starseeker |
if they're
for real about that STEP part to svg drawing extraction, that's not
too shabby |
| 15:16.40 |
brlcad |
opencascade
does that for them |
| 15:16.46 |
starseeker |
ah |
| 15:17.33 |
starseeker |
wonders if a step export capabilitiy would let us get some
good out of opencascade... |
| 15:17.39 |
``Erik |
'larrabee is
dead' http://www.pcmag.com/article2/0,2817,2356725,00.asp |
| 15:18.08 |
brlcad |
there was a
/. earlier in the week |
| 15:18.17 |
brlcad |
"dead for
consumer, but not as a dev platform" |
| 15:18.20 |
brlcad |
something to
that effect |
| 15:20.15 |
starseeker |
snorts in bemusement - they must be rather red faced after
all that promotion this summer |
| 15:21.27 |
starseeker |
hopes freecad does well - good for open source if they can
expose opencascade's abilities in a usable
interface |
| 15:24.42 |
brlcad |
hopes freecad does well, despite using
opencascade |
| 15:25.45 |
brlcad |
opencascade
isn't a healthy project to utilizing, particularly for
collaboration |
| 15:26.10 |
starseeker |
do they still
have that funny license? |
| 15:26.29 |
brlcad |
as our
Geometry Engine API comes to fruition, hopefully projects will have
more options for CAD frameworks to build upon |
| 15:27.41 |
starseeker |
nods |
| 15:28.57 |
starseeker |
3d shaded
displays, parametric modeling, and the whole drawings thing...
guess I'd better get busy :-P |
| 15:29.54 |
brlcad |
and that's
just noting the features that we don't support |
| 15:30.08 |
brlcad |
we actually
do a lot more than opencascade |
| 15:30.12 |
brlcad |
just not in a
clean API |
| 15:30.34 |
starseeker |
nods |
| 15:31.10 |
brlcad |
we really
need major refactoring to leverage and better present what we have
too |
| 15:31.10 |
brlcad |
get the core
libs cleaned up as stand-alone projects |
| 15:31.10 |
brlcad |
get the
converts into a library of their own |
| 15:31.10 |
starseeker |
yep - I was
surprised to hear the framebuffer stuff supported imagemagick style
maniulations |
| 15:31.10 |
brlcad |
same for the
data processing tools |
| 15:31.22 |
starseeker |
and I work on
this sucker full time :-P |
| 15:31.23 |
brlcad |
get that all
wrapped up into one unified API |
| 15:32.54 |
brlcad |
yeah, the fb
stuff is kind of funny .. you could almost implement a mini
photoshop/gimp clone if you put all our tools into one gui .. and
have it be fully scriptable via commands |
| 15:33.18 |
brlcad |
granted,
maybe "photoshop 3", but not too shabby for something entirely not
our focus, just core needs |
| 15:33.51 |
brlcad |
the image
processing stuff isn't as interesting, though, as our geometry
conversion capability and data/signal processing tools |
| 15:34.05 |
brlcad |
image
processing has come a long way since then |
| 15:35.09 |
starseeker |
oh, speaking
of conversion - do you know of a good list of "object types in cad
formats" anywhere? sort of a "dxf supports..., 3dm supports..."
sorta comparison? |
| 15:35.27 |
brlcad |
heck, if we
had a solid geometry conversion capability alone, that would kick
up our community usage substantially (everyone needs
geometry) |
| 15:35.47 |
brlcad |
no, not
really |
| 15:35.58 |
starseeker |
shucks |
| 15:36.01 |
brlcad |
would make a
nice chart |
| 15:36.07 |
brlcad |
features
list |
| 15:36.12 |
starseeker |
was thinking about making one |
| 15:36.16 |
starseeker |
for converter
status |
| 15:36.35 |
brlcad |
i've seen
some informal one on a site somewhere a long while back |
| 15:36.42 |
starseeker |
sorta a way
to represent "yes we do obj, but not NURBS - please add
that" |
| 15:37.06 |
starseeker |
or "we do 3dm
nurbs, but not meshes" |
| 15:37.39 |
starseeker |
supposes he could just grab all the object types in step and
assume that would conver everything... |
| 15:38.50 |
starseeker |
also, such a
list would be helpful for "pivoting" between formats |
| 15:39.08 |
brlcad |
nice lil
start,
http://reference.wolfram.com/mathematica/guide/3DGeometryAndModelingFormats.html |
| 15:41.17 |
starseeker |
reflects he could always go the mathematical categorization
route, has the advantage of being format
agnostic |
| 15:42.13 |
brlcad |
yeah, there
are various "features" encompassed by a given format, and it's
capabilities |
| 15:42.18 |
brlcad |
numeric
capabilities |
| 15:42.21 |
brlcad |
geometric |
| 15:42.32 |
brlcad |
representation types |
| 15:43.14 |
brlcad |
categorizations (object counts, groupings,
layerings, hierarchies) |
| 15:43.43 |
brlcad |
connectivity
and associations |
| 15:43.55 |
brlcad |
construction
history, revisions |
| 15:44.15 |
starseeker |
yeah, the
more I think about it that's the way to go - the internal libgcv
representation shouldn't be any particular CAD file format (even
.g) since that would by definition limit what the conversion
routines could handle to what the format could handle |
| 15:44.36 |
brlcad |
parametric
support, annotations, non-geometric entities, animation entities,
kinematic controls, ... |
| 15:45.54 |
brlcad |
that's nice
to say, but probably not practical -- depends where/how you draw
the line |
| 15:46.07 |
starseeker |
sure |
| 15:46.12 |
brlcad |
something has
to process the data, and in libgcv's case, that'd be libgcv and
librt |
| 15:46.46 |
brlcad |
and if librt
is processing the data, it's basically .g, but just in an in-memory
form |
| 15:47.03 |
starseeker |
dunno - I'd
have to think about it some |
| 15:47.32 |
brlcad |
there's only
one format I know of that was designed to try and capture
anything/everything, that being STEP |
| 15:47.43 |
brlcad |
it's
basically union of all CAD formats |
| 15:47.54 |
brlcad |
even where it
makes no sense whatsoever |
| 15:48.20 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 15:48.42 |
brlcad |
our format is
the next closest, though only "supporting" unsupported features
through opaque binary storage |
| 15:48.58 |
starseeker |
which isn't
very helpful for conversion |
| 15:49.03 |
brlcad |
STEPs not
exactly an in-memory format either |
| 15:49.19 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14AF53.dip.t-dialin.net) |
| 15:49.43 |
brlcad |
it can be,
but pita to use that way |
| 15:49.54 |
starseeker |
nods |
| 15:50.27 |
brlcad |
structurally,
we're one of the most flexible by far, given we started on the CSG
side of the spectrum with implicits |
| 15:51.25 |
brlcad |
try stashing
a hyperboloid of one sheet in implicit form into STEP (maybe
possible, but I'm sure we have a few that aren't) |
| 15:52.00 |
brlcad |
a table would
be interesting |
| 15:52.10 |
starseeker |
But I was
under the impression that you didn't want to have support for
non-3d objects in BRL-CAD except as subsets of sketch, which would
seem rather convoluted from the standpoint of conversion (most
systems seem to be fine with storing loose curves, for
example) |
| 15:52.24 |
brlcad |
it's be a
freaking huge table, hundreds of features to consider |
| 15:52.34 |
starseeker |
yep |
| 15:53.00 |
starseeker |
accurate
representation of the complexity of the task though |
| 15:54.03 |
brlcad |
that's not
been an intentional impression -- annotations are non-3d, image
objects, material objects, shader objects, wireframe
objects.. |
| 15:55.00 |
brlcad |
that
said |
| 15:55.05 |
brlcad |
I don't
believe we should focus on our weakest points |
| 15:55.22 |
brlcad |
our focus is
solid modeling |
| 15:55.40 |
brlcad |
the other
entity types would be fine to have, but we have very limited
resources |
| 15:56.05 |
brlcad |
rather do
what we do very well than do a lot half-assed |
| 15:56.36 |
starseeker |
sure - I'm
not saying we focus on doing anything with them, just know enough
about them to convert them in the libraries so other apps will be
inclined to use our converters |
| 15:56.41 |
``Erik |
"BRL-CAD -
the whole ass." |
| 15:56.45 |
starseeker |
(and enhance
them) |
| 15:56.49 |
brlcad |
``Erik:
:) |
| 15:58.07 |
brlcad |
i'd have no
problem with basic I/O support so things are preserved.. never been
an issue |
| 15:58.16 |
brlcad |
just a matter
of how |
| 15:58.24 |
brlcad |
and
what |
| 16:00.04 |
brlcad |
especially
for things that can be generalized in a useful manner, and
seamlessly integrated, not as one-offs |
| 16:00.27 |
starseeker |
right |
| 16:01.40 |
starseeker |
I just think
it deserves some careful planning and thought up front, so the
converters can expand as needed to encompass what needs to be
encompassed to successfully perform high quality geometry
conversions |
| 16:02.10 |
starseeker |
if that needs
.g changes rel8 seems the logical time :-) |
| 16:05.17 |
*** join/#brlcad jesica__
(n=jesica@201.255.230.172) |
| 16:05.29 |
starseeker |
hey jesica__
:-) |
| 16:05.40 |
jesica__ |
good morning
:P |
| 16:06.52 |
jesica__ |
today is
holiday! excellent! |
| 16:14.07 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36831 10/isst/trunk/src/gui.c: Collapse
duplicate functionality. Allow multiple regions in the local load
callback. Use librt's timing routines. |
| 16:22.00 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36832 10/isst/trunk/src/ (gui.c net_worker.c):
move load_frame_attribute() into net_worker.c |
| 16:29.09 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36833 10/isst/trunk/src/gui.c: default to PNG
and flip image for screeshot. |
| 16:29.48 |
jesica__ |
starseeker,
have you ever drink mate? |
| 16:35.20 |
starseeker |
jesica__: uh,
what? |
| 16:37.11 |
jesica__ |
mate is a
warm drink like the coffe, but itve a special procedure to
prepare |
| 16:39.04 |
starseeker |
ah, no I get
my caffine from soda |
| 16:40.25 |
brlcad |
starseeker:
sure, but that is also exactly the balance that has to be struck..
the "careful planning and thought up front" all take valuable time
and energy from other potential tasks, so also have to be careful
to not overinvest effort for something that isn't a strong
suit |
| 16:40.45 |
brlcad |
getting our
existing converters cleaned up and turned into an API for *exactly*
what they do now, would be a huge win |
| 16:41.12 |
brlcad |
and that's a
crapload of work in itself |
| 16:41.36 |
brlcad |
jesica__:
happy holiday! :) |
| 16:41.46 |
jesica__ |
idem
:) |
| 16:42.47 |
jesica__ |
im trying to
convert the xml to pdf by myself |
| 16:42.55 |
jesica__ |
starseeker,
its not so easy |
| 16:43.12 |
brlcad |
jesica__: did
you get an svn checkout? |
| 16:43.24 |
jesica__ |
and i can
drive emacs, god! i cant even read it wel |
| 16:43.31 |
jesica__ |
mmm
no |
| 16:43.44 |
brlcad |
do you have
svn installed? |
| 16:43.55 |
jesica__ |
mmm
no |
| 16:44.07 |
brlcad |
heh, can you
install it? :) |
| 16:44.35 |
jesica__ |
i think
so |
| 16:45.54 |
brlcad |
if you
install it, you can get a copy of the sources that will stay
synchronized with the rest of us |
| 16:46.28 |
jesica__ |
something
similar to starseeker send me yesterday? |
| 16:48.47 |
jesica__ |
well, the
thing is that starseeker told me some days ago that he`ve done the
conversion with emacs and i thougt it is a good oportunity to learn
to use emacs |
| 16:50.46 |
jesica__ |
I have
limited knowledge in regard to computing in general, but im trying
to change that it the tidiest way :) |
| 16:51.52 |
jesica__ |
learning
separate things without an order, so then unit them all togheter
and see what happen between them |
| 16:52.19 |
jesica__ |
rarest things
can happen, i swear |
| 16:52.54 |
brlcad |
learn |
| 16:52.59 |
brlcad |
er,
sorry |
| 16:53.06 |
CIA-41 |
BRL-CAD:
03brlcad * r36834
10/brlcad/trunk/doc/docbook/lessons/es/mged01_creating_primitive_shapes.xml:
an initial revision of the spanish translation work being done by
Jesica Giudice (with some support from Federico Calvo) |
| 16:53.06 |
brlcad |
learning
emacs is a great thing :) |
| 16:54.29 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 16:54.38 |
brlcad |
this was very
helpful for me when I was learning: http://brlcad.org/~sean/emacs_22_reference_card.pdf |
| 16:55.06 |
brlcad |
lo siento que
no lo tengo en espa?ol |
| 16:56.04 |
jesica__ |
shoul i
translate this too, jajja |
| 16:56.04 |
jesica__ |
wow, such a
large cheatsheet! |
| 16:57.03 |
CIA-41 |
BRL-CAD:
03brlcad * r36835 10/brlcad/trunk/doc/docbook/Makefile.am: add the
.es lesson to the dist |
| 17:04.06 |
jesica__ |
i saw emacs
uses a particularly nerd? way to explain its function |
| 17:08.14 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 17:08.14 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 17:08.14 |
*** join/#brlcad jesica__ (n=jesica@201.255.230.172) [NETSPLIT
VICTIM] |
| 17:08.14 |
*** join/#brlcad Elrohir (n=kvirc@p5B14AF53.dip.t-dialin.net)
[NETSPLIT VICTIM] |
| 17:08.14 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 17:08.23 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 17:08.23 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 17:08.23 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:08.23 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 17:08.23 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 17:08.23 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 17:08.24 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 17:08.24 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:08.24 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 17:08.24 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 17:08.24 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** join/#brlcad CIA-41 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 17:08.24 |
*** mode/#brlcad [+oo ChanServ brlcad] by
irc.freenode.net |
| 17:08.53 |
jesica__ |
brlcad,
somebody told my that it uses to delay :P |
| 17:08.53 |
jesica__ |
oh no, more
irc on english!!! |
| 17:08.56 |
brlcad |
they're good
people, easy to talk to |
| 17:08.57 |
brlcad |
it's not that
much of a delay |
| 17:08.57 |
brlcad |
not for
account creation |
| 17:09.03 |
brlcad |
creating new
projects has a delay |
| 17:09.11 |
brlcad |
they are
manually reviewed and approved |
| 17:09.18 |
brlcad |
but not new
accounts |
| 17:17.16 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 17:17.16 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 17:17.16 |
*** join/#brlcad jesica__ (n=jesica@201.255.230.172) [NETSPLIT
VICTIM] |
| 17:17.16 |
*** join/#brlcad Elrohir (n=kvirc@p5B14AF53.dip.t-dialin.net)
[NETSPLIT VICTIM] |
| 17:17.16 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 17:17.16 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 17:17.16 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 17:17.16 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:17.16 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 17:17.17 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 17:17.17 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:17.17 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 17:17.17 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 17:17.17 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad CIA-41 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 17:17.17 |
*** mode/#brlcad [+oo ChanServ brlcad] by
irc.freenode.net |
| 17:18.14 |
CIA-41 |
BRL-CAD:
03brlcad * r36836 10/brlcad/trunk/AUTHORS: Credit Jesica Guidice
for her work translating our documentation to Spanish. Met via irc
channel, her first contribution was on Vol IIs tutorial lessons.
Thanks! |
| 17:18.21 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 17:18.24 |
brlcad |
jesica__:
hopefully spelled your name right? :) |
| 17:18.47 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 17:19.02 |
jesica__ |
what did i
now, ugh! |
| 17:19.27 |
brlcad |
nothing bad,
I just credited you in our authorship file |
| 17:23.44 |
jesica__ |
which
parametres SF verifies to calculate the percentage of
activity? |
| 17:24.07 |
brlcad |
which
activity? |
| 17:24.15 |
jesica__ |
yours is
realy high |
| 17:24.45 |
jesica__ |
the activity
of the project |
| 17:26.20 |
brlcad |
takes in
download statistics, sourcecode commits, forum postings, webpage
views, iirc |
| 17:27.08 |
jesica__ |
aaaah irc :)
jejjeje |
| 17:27.11 |
brlcad |
tracker mods
too |
| 17:27.16 |
brlcad |
not irc
:) |
| 17:27.29 |
brlcad |
iirc == if i
recall correctly |
| 17:27.34 |
brlcad |
se recuerdo
bien |
| 17:27.38 |
brlcad |
si* |
| 17:27.56 |
jesica__ |
ops |
| 17:29.28 |
CIA-41 |
BRL-CAD:
03starseeker * r36837
10/brlcad/branches/STABLE/doc/docbook/fop.xconf.in: Hmm, somehow
fop.xconf.in didn't make it into STABLE. |
| 17:39.41 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 17:39.41 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
| 17:39.41 |
*** join/#brlcad jesica__ (n=jesica@201.255.230.172) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad Elrohir (n=kvirc@p5B14AF53.dip.t-dialin.net)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 17:39.41 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 17:39.41 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad CIA-41 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 17:39.41 |
*** mode/#brlcad [+oo ChanServ brlcad] by
irc.freenode.net |
| 17:41.26 |
mafm |
heh
:) |
| 17:41.37 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36838 10/isst/trunk/src/gui.c: use CLAMP from
vmath |
| 17:43.28 |
jesica__ |
starseeker,
you used fop on emacs? |
| 17:43.55 |
jesica__ |
i used it on
vim, but not succefully |
| 17:44.13 |
starseeker |
fop is a
command line tool |
| 17:44.44 |
starseeker |
jesica__: let
me start from the beginning |
| 17:44.48 |
starseeker |
(one
second) |
| 17:45.00 |
jesica__ |
well, so fop
do the job, not emacs! |
| 17:45.43 |
*** join/#brlcad louipc
(n=louipc@69-165-135-165.dsl.teksavvy.com) |
| 17:49.15 |
starseeker |
the process
of converting from docbook to pdf: |
| 17:49.27 |
starseeker |
use xsltproc
to generate a .fo file |
| 17:49.39 |
starseeker |
use fop to
convert the fo file to a pdf file |
| 17:50.14 |
starseeker |
look in
doc/docbook |
| 17:50.52 |
starseeker |
what
Operating System are you using? |
| 17:52.22 |
starseeker |
here is what
I did to convert your file to an html file: |
| 17:52.36 |
starseeker |
mkdir
doc/docbook/lessons/es |
| 17:53.14 |
starseeker |
cp
mged01_creating_primitive_shapes.xml
doc/docbook/lessons/es/ |
| 17:53.52 |
starseeker |
cd
doc/docbook/lessons/es |
| 17:53.53 |
jesica__ |
OS:
debian |
| 17:54.22 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 17:54.29 |
starseeker |
ok |
| 17:54.49 |
starseeker |
once in
doc/docbook/lessons/es with your file in that directory, run this
command to create html: |
| 17:56.02 |
starseeker |
XML_CATALOG_FILES=../../catalog.xml
/usr/bin/xsltproc -nonet -xinclude -o
mged01_creating_primitive_shapes.html
../../resources/standard/xsl/xhtml-1_1/docbook.xsl
mged01_creating_primitive_shapes.xml |
| 17:56.08 |
starseeker |
(one
line) |
| 17:57.56 |
starseeker |
to create pdf
file, first do this line: |
| 17:57.57 |
starseeker |
XML_CATALOG_FILES=../../catalog.xml
/usr/bin/xsltproc -nonet -xinclude -o
mged01_creating_primitive_shapes.fo
../../resources/standard/xsl/fo/docbook.xsl
mged01_creating_primitive_shapes.xml |
| 17:58.02 |
starseeker |
then do this
one: |
| 17:58.19 |
starseeker |
fop
mged01_creating_primitive_shapes.fo -pdf
mged01_creating_primitive_shapes.pdf |
| 17:58.23 |
``Erik |
('cept
xsltproc might not be in /usr/bin/, location should be set as a
variable from configure) |
| 17:58.38 |
starseeker |
``Erik: I'm
assuming she's doing it manually |
| 17:58.51 |
starseeker |
so yes,
wherever xsltproc is on your system |
| 17:59.25 |
``Erik |
okie, figured
that stuff'd go into a Makefile.am awfully soon :) |
| 18:00.07 |
*** join/#brlcad dli (n=dli@69.172.97.211) [NETSPLIT
VICTIM] |
| 18:01.18 |
starseeker |
``Erik: will
take a little time to get a feel for the LANG variables and such -
also, need to have per-lang makefiles that are included at the top
level |
| 18:02.03 |
starseeker |
jesica__: did
that work for you? |
| 18:02.53 |
jesica__ |
starseeker,
wait a moment please, ill try in a few minutes |
| 18:32.57 |
CIA-41 |
BRL-CAD:
03starseeker * r36839 10/brlcad/trunk/doc/docbook/ (6 files in 6
dirs): Start splitting up and including Makefile components for
docbook |
| 20:07.56 |
*** join/#brlcad Nohla
(n=jesica@201.255.217.181) |
| 20:49.23 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 21:04.06 |
CIA-41 |
BRL-CAD:
03indianlarry * r36840 10/brlcad/trunk/src/adrt/Makefile.am: Added
${GCV_LIBS} to librender, wasn't building on MAC 10.4 due to
missing tcl dependencies. |
| 21:26.10 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 21:29.07 |
*** join/#brlcad jesica__
(n=jesica@201.255.217.181) |
| 21:48.54 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 22:50.51 |
*** join/#brlcad jesica__
(n=jesica@201.255.217.181) |
| 22:51.40 |
jesica__ |
starseeker,
are you there? |
| 23:03.39 |
starseeker |
yes |
| 23:03.47 |
starseeker |
what's
up? |
| 23:04.07 |
jesica__ |
well, i just
change my debian lenny for debian sid |
| 23:04.18 |
jesica__ |
and installed
xsltproc |
| 23:04.25 |
jesica__ |
i was reading
the man |
| 23:04.41 |
jesica__ |
(i couldn do
this with lenny :P) |
| 23:06.00 |
jesica__ |
(ah, ive sent
the file by brlcad-devel list) |
| 23:08.22 |
starseeker |
jesica__:
excellent, thanks :-) |
| 23:09.03 |
starseeker |
is reading up on how to localize docbook output for various
languages |
| 23:10.44 |
jesica__ |
you showed me
how to make the conversion from html, but my file is a
xml |
| 23:12.05 |
jesica__ |
mmm... no, i
thing im confused |
| 23:12.34 |
starseeker |
I showed you
how to do it from xml |
| 23:12.39 |
jesica__ |
guide me if
you can |
| 23:12.46 |
starseeker |
ok |
| 23:13.15 |
starseeker |
first, did
you check out the subversion copy of BRL-CAD? |
| 23:13.30 |
jesica__ |
no |
| 23:13.36 |
starseeker |
ok, do that
first |
| 23:13.42 |
starseeker |
~cadsvn |
| 23:13.43 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
| 23:20.34 |
jesica__ |
done |
| 23:20.41 |
starseeker |
ok. |
| 23:21.08 |
starseeker |
now copy the
latest copy of your xml file to doc/docbook/lessons/es/ |
| 23:23.16 |
starseeker |
ok? |
| 23:24.50 |
jesica__ |
mmm no, svn
check... bring me the hole source code? i didnt understand what it
did |
| 23:24.59 |
starseeker |
yes |
| 23:25.08 |
starseeker |
you have a
brlcad directory? |
| 23:25.23 |
starseeker |
if so,
do: |
| 23:25.32 |
starseeker |
cd
brlcad/ |
| 23:25.44 |
starseeker |
ls |
| 23:25.51 |
starseeker |
you should
see a doc directory |
| 23:26.42 |
jesica__ |
yes
:) |
| 23:26.56 |
starseeker |
ok, now do cd
doc/docbook/ |
| 23:27.04 |
starseeker |
you will see
lessons directory |
| 23:27.28 |
starseeker |
then cd
lessons/es |
| 23:27.33 |
jesica__ |
yes |
| 23:27.45 |
starseeker |
remove the
xml document there and replace it with your current version of the
file |
| 23:27.50 |
jesica__ |
done |
| 23:27.58 |
starseeker |
now, do
this: |
| 23:28.11 |
starseeker |
XML_CATALOG_FILES=../../catalog.xml
/usr/bin/xsltproc -nonet -xinclude -o
mged01_creating_primitive_shapes.html
../../resources/standard/xsl/xhtml-1_1/docbook.xsl
mged01_creating_primitive_shapes.xml |
| 23:28.38 |
starseeker |
that should
generate an html file |
| 23:28.44 |
jesica__ |
stand on the
same directory? or that doesnt mather? |
| 23:28.55 |
starseeker |
in the same
directory as the xml file |
| 23:30.09 |
jesica__ |
done |
| 23:30.20 |
starseeker |
did you get
an html file? |
| 23:30.30 |
jesica__ |
yes |
| 23:30.39 |
starseeker |
ok, open it
:-) |
| 23:31.00 |
jesica__ |
ah? |
| 23:31.20 |
starseeker |
web
browser |
| 23:31.20 |
jesica__ |
ah? |
| 23:31.32 |
starseeker |
firefox
mged01_creating_primitive_shapes.html |
| 23:31.44 |
``Erik |
that html
file is the end product |
| 23:32.50 |
jesica__ |
starseeker,
so now with fop i can convers it to pdf? |
| 23:33.01 |
starseeker |
ok, for pdf
do this: |
| 23:33.15 |
starseeker |
XML_CATALOG_FILES=../../catalog.xml
/usr/bin/xsltproc -nonet -xinclude -o
mged01_creating_primitive_shapes.fo
../../resources/standard/xsl/fo/docbook.xsl
mged01_creating_primitive_shapes.xml |
| 23:33.29 |
starseeker |
then,
this: |
| 23:33.37 |
starseeker |
fop
mged01_creating_primitive_shapes.fo -pdf
mged01_creating_primitive_shapes.pdf |
| 23:34.00 |
jesica__ |
to use fop i
alwais have to give it a .fo? |
| 23:34.12 |
starseeker |
that is how
our build system works |
| 23:34.13 |
jesica__ |
cant i jump
this step? |
| 23:34.18 |
jesica__ |
ok |
| 23:34.37 |
starseeker |
just save
those commands in a script if you want to re-run them a
lot |
| 23:34.44 |
starseeker |
for editing
work, I recommend html output |
| 23:35.16 |
starseeker |
once I update
our build system to be multi-language, you will be able to use the
build logic to do this for you |
| 23:35.37 |
starseeker |
(working on
that now, will probably be a couple days) |
| 23:35.58 |
``Erik |
starseeker:
examined the fbsd version for generating the handbook? |
| 23:36.19 |
starseeker |
hmm? FreeBSD
uses docbook too? |
| 23:36.28 |
``Erik |
docbook/jade,
yes |
| 23:36.33 |
starseeker |
had looked at the firebird manual, not
FreeBSD |
| 23:37.03 |
starseeker |
we seem to be
doing this much more "automake-ish" than most projects |
| 23:37.06 |
jesica__ |
the images
are not displayed :-/ |
| 23:37.10 |
starseeker |
jesica__:
that's OK |
| 23:37.14 |
jesica__ |
in
pdf |
| 23:37.26 |
jesica__ |
you think?
:) |
| 23:37.40 |
starseeker |
if you need
them, we need to do this: |
| 23:37.49 |
starseeker |
cd
../../ |
| 23:38.00 |
starseeker |
(you should
be in the doc/docbook directory) |
| 23:38.13 |
jesica__ |
aha |
| 23:38.15 |
starseeker |
then, run
this command: |
| 23:38.22 |
jesica__ |
aaah |
| 23:38.44 |
jesica__ |
becouse the
imagen are in that directory? |
| 23:39.01 |
starseeker |
XML_CATALOG_FILES=./catalog.xml
/usr/bin/xsltproc -nonet -xinclude -o
mged01_creating_primitive_shapes.fo
./resources/standard/xsl/fo/docbook.xsl
mged01_creating_primitive_shapes.xml |
| 23:39.13 |
starseeker |
yes, the xml
file links to the images |
| 23:39.44 |
starseeker |
there is a
very specific hierarchy to the docbook directories and the way
images are linked - reasons are a bit complex |
| 23:39.53 |
starseeker |
did you
create new fo file? |
| 23:40.14 |
starseeker |
once you
have, do again fop mged01_creating_primitive_shapes.fo -pdf
mged01_creating_primitive_shapes.pdf |
| 23:40.24 |
starseeker |
that pdf
should have images |
| 23:40.31 |
jesica__ |
ok |
| 23:41.23 |
starseeker |
jesica__: to
do parallel make (many files at once) we controll all build logic
from the doc/docbook directory |
| 23:41.56 |
starseeker |
jesica__: did
that work? |
| 23:41.59 |
jesica__ |
starseeker,
you did this program? |
| 23:42.04 |
starseeker |
mostly |
| 23:42.09 |
starseeker |
the build
logic anyway |
| 23:42.18 |
starseeker |
the docbook
tools are by others (many others) |
| 23:42.47 |
starseeker |
``Erik did
the original source code build logic, I am just doing
doc/docbook |
| 23:44.34 |
jesica__ |
starseeker,
maybe for that i only found information of this program in
sourceforge and in a log of brlcad :) |
| 23:45.25 |
starseeker |
docbook
building is a bit specialized |
| 23:46.50 |
jesica__ |
starseeker,
thank for helping, its a great pleasure work with all
you |
| 23:48.12 |
starseeker |
no problem -
thanks for your work! |
| 23:48.20 |
starseeker |
what would
you like to work on next? |
| 23:48.22 |
jesica__ |
i feel
confortable in this chanel and glad to do something usefull for
your effort |
| 23:48.51 |
jesica__ |
now? i began
the second file |
| 23:49.00 |
starseeker |
excellent
:-) |
| 23:49.15 |
starseeker |
the same
commands will work, just change the file names |
| 23:49.21 |
``Erik |
doesn't think he's touched the doc/ dir in over five years,
don't blame him for that mess O.O :D *duck* |
| 23:49.45 |
jesica__ |
starseeker, i
understood enought to do it again correctly :) |
| 23:52.12 |
jesica__ |
Ill do the
following slower because I have to study for the test i didnt
doyesterday :P |
| 23:52.25 |
starseeker |
no rush
:-) |
| 23:52.33 |
jesica__ |
but ill do
it, i promise |
| 23:54.19 |
jesica__ |
I'll use '
since now, despite not being so confortable |
| 23:54.29 |
starseeker |
``Erik: I'd
argue it SHOWS that nobody had really touched the doc directory in
a few years <snort> |
| 23:54.45 |
starseeker |
jesica__:
take your time |
| 23:59.12 |
jesica__ |
starseeker,
the following error happened when fop runing |
| 23:59.15 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 23:59.29 |
jesica__ |
<PROTECTED> |
| 23:59.41 |
starseeker |
jesica__:
that can be ignored, I see that for english docs too |
| 00:00.00 |
jesica__ |
Line 1 of a
paragraph overflows the available area. (fo:block,
location |
| 00:00.00 |
starseeker |
fop is not
perfect, but it's the only free tool for this job |
| 00:00.11 |
starseeker |
jesica__:
does the pdf look OK? |
| 00:01.10 |
jesica__ |
papparently |
| 00:02.15 |
jesica__ |
apparently
:P |
| 00:02.19 |
starseeker |
jesica__:
you're fine then |
| 00:02.26 |
starseeker |
I see those
errors too |
| 00:02.57 |
jesica__ |
but what it
means? maybe is better to chage it |
| 00:03.07 |
starseeker |
jesica__: I
haven't checked into it yet |
| 00:03.18 |
starseeker |
jesica__:
would have to read the fop documentation |
| 00:03.32 |
starseeker |
configuring
fop is no picnic |
| 00:03.41 |
jesica__ |
:) |
| 00:04.33 |
jesica__ |
at least,
I'didnt use emacs :( |
| 00:05.16 |
starseeker |
you're doing
find |
| 00:05.17 |
starseeker |
er
fine |
| 00:05.35 |
starseeker |
nxml + emacs
is useful, but since you are translating it is not
critical |
| 00:05.40 |
starseeker |
more
important for new files |
| 00:06.24 |
jesica__ |
there will be
oportunity I guess |
| 00:07.13 |
starseeker |
sure
:-) |
| 00:07.35 |
starseeker |
right now
though, more important to get sourceforge account and learn to use
subversion |
| 00:07.52 |
starseeker |
did you send
an email to the sourceforge help system? |
| 00:10.31 |
jesica__ |
mmm...
no |
| 00:10.35 |
jesica__ |
why |
| 00:10.42 |
starseeker |
you still
can't log in, correct? |
| 00:10.52 |
``Erik |
vim has an
XML syntax package that might be useful |
| 00:10.55 |
jesica__ |
no, I can
now |
| 00:11.07 |
starseeker |
oh,
excellent |
| 00:11.19 |
starseeker |
then let's
try something |
| 00:11.22 |
``Erik |
folding,
highlighting, matching, linting, ... |
| 00:11.31 |
starseeker |
cd into your
brlcad checkout |
| 00:11.41 |
starseeker |
cd
brlcad/doc/docbook/lessons/es |
| 00:11.42 |
jesica__ |
but I'd
create with my hotmail :P |
| 00:11.48 |
starseeker |
run the
command svn diff |
| 00:12.04 |
jesica__ |
that bothers
me |
| 00:12.46 |
starseeker |
does svn diff
show anything? |
| 00:13.26 |
jesica__ |
no |
| 00:13.45 |
jesica__ |
that sounds
fine? |
| 00:14.07 |
jesica__ |
fine/good |
| 00:15.44 |
starseeker |
um - you
copied your newest copy of the xml file to that
directory? |
| 00:16.18 |
jesica__ |
starseeker,
ah? |
| 00:16.29 |
starseeker |
if not, do so
and try again |
| 00:16.39 |
starseeker |
should
replace the xml file already there |
| 00:17.38 |
jesica__ |
replace? |
| 00:21.03 |
starseeker |
brlcad
uploaded a verion of your translation to that directory
already |
| 00:21.27 |
starseeker |
unless you
didn't make any changes, if you remove the old one and put your new
one in svn diff should show those changes |
| 00:21.51 |
starseeker |
so: |
| 00:22.02 |
starseeker |
cd
brlcad/doc/docbook/lessons/es |
| 00:22.21 |
starseeker |
rm
mged01_creating_primitive_shapes.xml |
| 00:22.39 |
starseeker |
copy in your
latest mged01_creating_primitive_shapes.xml |
| 00:22.43 |
starseeker |
then run svn
diff |
| 00:22.46 |
jesica__ |
starseeker,
first, remember I've changed the name of the file |
| 00:22.52 |
jesica__ |
it's in
spanish |
| 00:22.52 |
starseeker |
to? |
| 00:22.57 |
starseeker |
erm |
| 00:22.58 |
jesica__ |
yes |
| 00:23.00 |
starseeker |
oh,
OK |
| 00:23.16 |
starseeker |
do do
this: |
| 00:23.26 |
starseeker |
svn del
mged01_creating_primitive_shapes.xml |
| 00:23.34 |
jesica__ |
but it was
which I've sent to brlcad-devel |
| 00:23.42 |
starseeker |
svn add
*your_new_filename* |
| 00:24.27 |
starseeker |
then try svn
diff again |
| 00:26.26 |
jesica__ |
starseeker,
could you explain to me what that do? because I'll forget
everything tomorrow if I can't understand |
| 00:30.15 |
jesica__ |
I'm sick
:P |
| 00:30.33 |
starseeker |
the idea is
for you to be able to upload your files and changes to them
directly into the main source code tree |
| 00:30.45 |
starseeker |
to do this,
you will need a working sourceforge account |
| 00:30.58 |
starseeker |
when brlcad
comes back, he can enable your account to send changes to the
tree |
| 00:31.15 |
starseeker |
the svn
commands I am showing you are steps in that process |
| 00:31.30 |
jesica__ |
wow, that
sounds good, but hard |
| 00:31.49 |
jesica__ |
juantelez was
right when said I'll learn a lot of thing with this |
| 00:32.22 |
starseeker |
not so hard,
just a few commands to learn |
| 00:32.35 |
starseeker |
once it is
set up and you have done it a few times, it will be easy
:-) |
| 00:32.40 |
jesica__ |
but a lot of
thing to understand |
| 00:32.59 |
starseeker |
when it is
all new, it is a lot to understand :-) |
| 00:33.04 |
jesica__ |
don't wanna
copy withno understanding |
| 00:35.00 |
starseeker |
don't worry -
you will understand |
| 00:35.17 |
starseeker |
subversion
(svn) manages our source code and documentation |
| 00:35.40 |
starseeker |
it retains
history, so earlier versions can be viewed and changes between
versions can be found |
| 00:36.15 |
starseeker |
when making
changes, developers send changes to the central server
(sourceforge) to be saved |
| 00:36.49 |
starseeker |
so when you
did "svn checkout" you were asking subversion to send you a copy of
the source code and documentation with all the latest
changes |
| 00:36.51 |
jesica__ |
the
XML_CATAL.. comand call some binary of xsltproc and read
destination file first and origin second? |
| 00:37.14 |
jesica__ |
i ask myself
why the comand is so large |
| 00:37.33 |
starseeker |
it is being
supplied many arguments - paths to files not in its local
directory |
| 00:37.44 |
starseeker |
this is
normally handled by our build system |
| 00:37.59 |
starseeker |
you can just
type "make" and get html and pdf output (pdf only when fop is
installed) |
| 00:38.16 |
starseeker |
up until now,
only english documentation was available |
| 00:38.20 |
starseeker |
so build
system assumed this |
| 00:38.26 |
starseeker |
now that
assumption is not true |
| 00:38.33 |
starseeker |
so I am
making the system more flexible |
| 00:38.50 |
starseeker |
once I am
done, you will be able to tell the make process to build spanish
documentation |
| 00:39.00 |
starseeker |
and you will
just type "make" to get latest html/pdf |
| 00:39.17 |
starseeker |
commands are
long still, but generated automatically |
| 00:42.26 |
jesica__ |
...and reads
destination file first and origin second? |
| 00:50.18 |
``Erik |
grabs a serial line and heads back into the pit to fight the
ARM thingie |
| 00:51.02 |
starseeker |
yes, although
there is an additional argument between them |
| 00:51.19 |
starseeker |
run man
xsltproc to see details |
| 00:58.33 |
jesica__ |
yes I
see |
| 01:06.55 |
*** join/#brlcad cosurg1
(n=cosurgi@atak.bl.pg.gda.pl) |
| 01:12.50 |
jesica__ |
starseeker,
good night, thanks again |
| 01:12.59 |
starseeker |
you're
welcome! |
| 01:47.13 |
CIA-41 |
BRL-CAD:
03starseeker * r36841 10/brlcad/trunk/ (14 files in 9
dirs): |
| 01:47.13 |
CIA-41 |
BRL-CAD: OK,
this is very crude and has no awareness of posix locale stuff, but
add the |
| 01:47.13 |
CIA-41 |
BRL-CAD:
ability to toggle doc building using --with-lang compile option.
Currently, |
| 01:47.13 |
CIA-41 |
BRL-CAD: only
--with-lang=es will do anything, but it will switch off english
doc |
| 01:47.14 |
CIA-41 |
BRL-CAD:
building and build whatever spanish docs are available (currently
lesson one). |
| 01:47.16 |
CIA-41 |
BRL-CAD:
Needs much more work, but this will get it off the
ground. |
| 01:47.54 |
starseeker |
phew |
| 01:50.12 |
louipc |
what if you
just want to build everything? |
| 02:21.04 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 02:30.29 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 02:30.29 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 02:34.25 |
``Erik |
O.O |
| 02:37.06 |
*** join/#brlcad Ralith
(n=ralith@d142-058-088-232.wireless.sfu.ca) |
| 02:42.03 |
``Erik |
FreeBSD
8.0-STABLE FreeBSD 8.0-STABLE #0: Sat Dec 5 08:24:01 EST 2009
erik@fenris:/usr/obj/arm/usr/src/sys/DB-88F6XXX arm |
| 02:47.59 |
starseeker |
``Erik: you
got it? |
| 02:48.32 |
starseeker |
louipc:
that's one of the reasons it's crude ;-) |
| 02:48.57 |
starseeker |
a "lang=all"
option could turn on everything, I just have to set that
up |
| 02:49.11 |
starseeker |
I just
tonight got it doing any sort of conditional anything |
| 02:51.02 |
*** join/#brlcad Ralith
(n=ralith@d142-058-088-232.wireless.sfu.ca) |
| 03:01.03 |
``Erik |
it's running,
but via tftp/nfs... it's not liking the big honkin' usb disk very
much and I haven't gotten around to making the bootloader
understand ufs/ffs yet |
| 03:01.50 |
``Erik |
had to fix a
power supply to get the serial client working again to attach to
the debug port O.o |
| 03:09.08 |
starseeker |
ow |
| 03:09.36 |
starseeker |
is awed by the lengths you are willing to go to to attain
minimal computing power ;-) |
| 03:10.07 |
starseeker |
(he says as
he glances at his hard disk full of things like original CADR lisp
machine schematics...) |
| 03:11.18 |
starseeker |
grrrr - why
does it not like the src/other Makefile.am setups... |
| 03:12.20 |
``Erik |
given that
you drive a civic, I find your awe at my selecting "adequate
performance with superior efficiency" odd O.o :D *duck* |
| 03:15.00 |
``Erik |
the only
moving part in this beastie will be the hard drive O.o that's
awesome right there |
| 03:16.26 |
``Erik |
low power,
tiny machine, nifty blue LED, unusual architecture... it's all
awesome :D |
| 03:28.17 |
starseeker |
``Erik:
you're a cad weenie. There's no such thing as "adequate", there's
only least inadquate :-P |
| 03:28.25 |
starseeker |
but yes, I
concede the awesomeness |
| 03:28.43 |
starseeker |
especially
when you hack it to have a solid state drive |
| 03:31.00 |
``Erik |
heh, still
consider myself more of a systems weenie than a cad weenie...
:) |
| 03:31.16 |
``Erik |
and it
already has a 4G NAND flash drive in it |
| 03:31.32 |
``Erik |
but I want to
use the 1.5tb usb dealie |
| 03:31.43 |
``Erik |
at least for
bulk storage |
| 03:41.35 |
*** join/#brlcad Ralith
(n=ralith@d142-058-088-232.wireless.sfu.ca) |
| 04:02.22 |
``Erik |
<--
watches the snow come down O.o |
| 04:37.39 |
*** join/#brlcad Nohla
(n=jesica@201.255.230.172) |
| 05:06.23 |
*** join/#brlcad Ralith
(n=ralith@d142-058-088-232.wireless.sfu.ca) |
| 06:35.33 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 07:12.19 |
*** join/#brlcad superlinux
(n=imad@85.195.142.183.satgate.net) |
| 07:12.24 |
superlinux |
hi
all |
| 07:14.41 |
superlinux |
well this is
my 2nd day in brlcad and I want to know how can i keep the drawing
display running as ogl if I just typed on the terminal
"mged"? |
| 08:47.50 |
*** join/#brlcad dli (n=dli@69.172.97.211) |
| 09:02.40 |
superlinux |
dli,
? |
| 09:02.50 |
superlinux |
hi dli are
you ther? |
| 09:19.24 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 09:21.04 |
*** join/#brlcad imad_
(n=imad@85.195.142.183.satgate.net) |
| 10:45.20 |
*** join/#brlcad imad_
(n=imad@85.195.142.183.satgate.net) |
| 12:20.53 |
dli |
superlinux,
hi |
| 12:24.25 |
*** join/#brlcad __monty__
(n=toon@d51A5402A.access.telenet.be) |
| 12:39.04 |
superlinux |
dli,
hi |
| 12:39.14 |
superlinux |
you were
lucky to find me |
| 12:39.21 |
superlinux |
well this is
my 2nd day in brlcad and I want to know how can i keep the drawing
display running as ogl if I just typed on the terminal
"mged"? |
| 12:40.27 |
superlinux |
and I have
another problem. the drawing display does not really keep
refreshed |
| 12:40.44 |
superlinux |
__monty__,
can you please help |
| 12:41.20 |
__monty__ |
I'm sorry I
can't help you, I can't even get brlcad to run yet. |
| 12:41.28 |
__monty__ |
*mged |
| 12:41.47 |
superlinux |
I have to
minimize then maximize the program to see it correctly |
| 12:41.57 |
superlinux |
__monty__,
what are you using? |
| 12:42.03 |
superlinux |
i can help
you |
| 12:42.20 |
superlinux |
Linux? |
| 12:42.23 |
__monty__ |
mac os X, if
that's what you mean |
| 12:42.29 |
superlinux |
mmm |
| 12:42.40 |
superlinux |
I used Linux
Ubuntu |
| 12:42.49 |
superlinux |
it ran off
the box |
| 12:43.09 |
__monty__ |
It used to
for me too, but now I get a Bus error. |
| 12:43.12 |
superlinux |
I mean out of
the box |
| 12:43.51 |
*** join/#brlcad __monty__
(n=toon@d51A5402A.access.telenet.be) |
| 12:44.12 |
__monty__ |
Sorry, my
laptop battery just ran out. |
| 12:44.48 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 12:57.53 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
| 12:58.04 |
superlinux |
__monty__,
the Linux version ran directly with me |
| 12:59.06 |
__monty__ |
Yeah, the mac
version used to aswell, but now it doesn't. Or do you mean you're
using the linux version on a mac? |
| 13:00.35 |
superlinux |
no |
| 13:01.05 |
superlinux |
I am using
Ubuntu intel over a tochiba Laptop |
| 13:01.17 |
superlinux |
__monty__, |
| 13:01.28 |
__monty__ |
Ok. |
| 13:01.46 |
superlinux |
which BrlCAD
version? |
| 13:02.01 |
superlinux |
i am using
the x.10 |
| 13:02.16 |
superlinux |
i am using
the 7.10 |
| 13:02.25 |
__monty__ |
Latest binary
from brlcad.org, latest tarball, latest svn. |
| 13:02.30 |
superlinux |
th 7.12 not
yet |
| 13:02.48 |
superlinux |
let me try
compiling the 12 |
| 13:03.19 |
__monty__ |
Ok, your help
is much appreciated. |
| 13:08.52 |
superlinux |
__monty__, it
will take me some time to download it. I am in Lebanon and we have
a basic DSL |
| 13:09.11 |
__monty__ |
That's
ok. |
| 13:09.44 |
__monty__ |
Who could I
complain when you're trying to help. |
| 13:13.57 |
starseeker |
erm |
| 13:13.59 |
starseeker |
cc1: warnings
being treated as errors |
| 13:13.59 |
starseeker |
../../../brlcad/src/libbu/crashreport.c:
In function âbu_crashreportâ: |
| 13:13.59 |
starseeker |
../../../brlcad/src/libbu/crashreport.c:75:
error: format not a string literal and no format
arguments |
| 13:34.43 |
*** join/#brlcad superlinux
(n=imad@94.187.111.66) |
| 13:40.26 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
| 14:02.13 |
``Erik |
opengl will
not do 'shaded' displays nor will it give a significant performance
increase, it's probably safer to use X |
| 14:02.50 |
``Erik |
7.10 and 7.12
are pretty old, should be on 7.16.2 these days |
| 14:03.55 |
dli |
superlinux,
I'm dont know about opengl support. :( I guess you mean
opengl |
| 14:07.33 |
dli |
superlinux, I
checked ./configure, opengl support seems to be auto
detected |
| 14:08.30 |
dli |
superlinux,
or to specify, ./configure --with-ogl |
| 14:11.01 |
starseeker |
must not have synced stable right |
| 14:12.13 |
superlinux |
dli,
ok |
| 14:12.55 |
superlinux |
dli, what i
notcied is that the window where the drawing appears does not stay
on |
| 14:13.30 |
dli |
superlinux,
as <``Erik> says, maybe, you can play with and without
opengl |
| 14:13.31 |
superlinux |
like i must
minimize and maximize to make it clear |
| 14:15.05 |
``Erik |
superlinux:
the ogl display manager has a known issue where redraw events are
not being sent correctly all the time... seriously, dude, use the X
display, it's visually identical :) |
| 14:15.09 |
superlinux |
every time i
move a window over it then i move it out of it that display turns
grey |
| 14:15.35 |
superlinux |
so ``Erik how
can i use the X display? |
| 14:15.44 |
superlinux |
i am still
very new to this |
| 14:16.03 |
dli |
superlinux,
try: ./configure --without-ogl |
| 14:16.13 |
superlinux |
the aims of
using BRL is to migrate from Autocad on linux |
| 14:16.17 |
``Erik |
um, should be
the default, might try to do "detach" and "attach X" in the mged
window? |
| 14:16.39 |
superlinux |
i have an
already built binary |
| 14:16.46 |
``Erik |
or set the
FB_FILE or something, *shrug* I try not to touch a gui if possible,
so'z I dunno |
| 14:16.47 |
dli |
``Erik, I
tried, minimizing, moving the display window, opengl is not causing
any trouble here |
| 14:16.49 |
superlinux |
so is there
an option? |
| 14:17.07 |
``Erik |
dli: it's a
tricky one to track, that's why it's not fixed yet... |
| 14:17.36 |
``Erik |
I think
someone (maybe starseeker) is going to re-write the OGL dm,
which'll hopefully 'just work right' |
| 14:18.03 |
``Erik |
a lot of the
ogl stuff is slightly updated irisGL from the 80's :/ |
| 14:18.27 |
superlinux |
ok .. so the
command is 'detach' then do 'attach X'? |
| 14:19.03 |
dli |
``Erik, I
see, but when it happens, good to try without ogl |
| 14:19.05 |
starseeker |
is THIS close to nuking stable and copying in trunk...
dingnabbit I thought I had this synced! |
| 14:19.53 |
``Erik |
starseeker:
src/libbu$ svn diff -r36452:36077 vls.c <-- yeh... |
| 14:20.20 |
``Erik |
superlinux: I
think so.. starseeker would know better than me :D |
| 14:20.59 |
starseeker |
superlinux:
what version of BRL-CAD are you using? |
| 14:21.22 |
starseeker |
``Erik: can
you tell what I messed up on the sync? |
| 14:21.27 |
superlinux |
7.10 |
| 14:21.32 |
starseeker |
eeeep |
| 14:21.36 |
superlinux |
starseeker, |
| 14:21.47 |
starseeker |
are you able
to compile a newer version? |
| 14:21.54 |
superlinux |
maybe |
| 14:22.07 |
superlinux |
cos it will
take time downloading stuff |
| 14:22.16 |
starseeker |
ah |
| 14:22.27 |
starseeker |
superlinux:
well, first try this |
| 14:22.28 |
superlinux |
what about
the 7.10? |
| 14:22.29 |
starseeker |
mged
-c |
| 14:22.33 |
superlinux |
ok |
| 14:22.54 |
starseeker |
when it asks
what to attach, pick X |
| 14:23.04 |
superlinux |
ok |
| 14:23.18 |
starseeker |
that's the
quick way to test |
| 14:23.33 |
superlinux |
all
fine |
| 14:23.37 |
superlinux |
no problems
yet |
| 14:23.44 |
starseeker |
ok |
| 14:23.45 |
superlinux |
brb 1 min
max |
| 14:24.12 |
starseeker |
grrrr,
sourceforge don't tell me you can't connect.... |
| 14:24.20 |
starseeker |
that's
it |
| 14:25.03 |
``Erik |
starseeker:
never merged with subversion before, only CVS... looks like you
may've merged 36452 to 36452? *shrug* |
| 14:25.36 |
superlinux |
ok
back |
| 14:25.39 |
superlinux |
that was my
mom |
| 14:26.07 |
starseeker |
``Erik: could
be - well, I can't get a steady enough connection to try the
traditional route anyway... |
| 14:26.09 |
superlinux |
so what
now? |
| 14:26.18 |
superlinux |
lemme
see |
| 14:26.35 |
starseeker |
now I try to
remember how to set the display manager in 7.10 in the Tk
gui |
| 14:26.59 |
starseeker |
(bty, I'd
start downloading the 7.16.2 source if you think you can build it -
many new features in that release) |
| 14:27.05 |
starseeker |
btw
rather |
| 14:28.19 |
superlinux |
starseeker, |
| 14:28.30 |
superlinux |
if i just
typed mged |
| 14:28.31 |
starseeker |
superlinux:
ok, you need to create a .mgedrc file (do this by starting up mged
without the -c option, then under File there's a Create/update
.mgedrc file |
| 14:28.44 |
superlinux |
ok |
| 14:28.51 |
``Erik |
if starseeker
hadn't screwed up the stable branch, I'd say check it out via svn
so'z you can save the bandwidth during upgrades... *cough*
O:-) |
| 14:29.10 |
superlinux |
ok |
| 14:29.17 |
superlinux |
i'll see the
rc file |
| 14:29.34 |
starseeker |
there should
be a line like set mged_default(dm_type) X |
| 14:29.42 |
starseeker |
or maybe set
mged_default(dm_type) ogl |
| 14:29.45 |
starseeker |
you want the
X one |
| 14:30.14 |
starseeker |
(edit the
.mgedrc file with a text editor) |
| 14:31.05 |
superlinux |
ok
sure |
| 14:31.12 |
superlinux |
just a
moment |
| 14:32.20 |
superlinux |
done. restart
mged? |
| 14:32.27 |
superlinux |
i feal
so |
| 14:32.30 |
superlinux |
i feel
so |
| 14:32.41 |
CIA-41 |
BRL-CAD:
03starseeker * r36842 10/brlcad/branches/STABLE/: OK, stable sync
got royally messed up somehow. Clear it out - next commit will
recreate STABLE from trunk. |
| 14:33.01 |
superlinux |
starseeker,
ok all nice and great |
| 14:33.30 |
superlinux |
so this way
means that thru X the openGL will work? |
| 14:34.30 |
CIA-41 |
BRL-CAD:
03starseeker * r36843 10/brlcad/branches/STABLE/: Re-create STABLE
from trunk |
| 14:34.36 |
starseeker |
no, you
aren't using opengl |
| 14:34.44 |
superlinux |
ok |
| 14:34.48 |
superlinux |
no
problem |
| 14:34.56 |
starseeker |
we aren't to
the point yet where it's critical |
| 14:35.11 |
superlinux |
now i tried
opening a database file |
| 14:35.31 |
superlinux |
one of the
sample files |
| 14:35.50 |
superlinux |
nothing yet..
or i have to wait more from you? |
| 14:37.16 |
d_rossberg |
how can i
connect a proxy to the docbook build to get the draft
image? |
| 14:37.37 |
d_rossberg |
superlinux:
type "tops" |
| 14:37.43 |
starseeker |
um, what's a
draft image? |
| 14:38.03 |
d_rossberg |
http://docbook.sourceforge.net/release/images/draft.png |
| 14:38.37 |
starseeker |
superlinux:
what database did you open? |
| 14:38.48 |
starseeker |
d_rossberg:
good question - haven't tried using that |
| 14:40.00 |
d_rossberg |
this wasn't a
question: type the word "tops" into the mged terminal |
| 14:41.22 |
starseeker |
superlinux:
did that work? |
| 14:41.39 |
d_rossberg |
superlinux:
what do you get returned from this command? |
| 14:42.00 |
starseeker |
d_rossberg:
my guess is you need to define a customization xslt stylesheet,
like what we're going to need to do for the translations - we
aren't (quite) there yet but we're getting pretty close |
| 14:44.45 |
starseeker |
if it's a bit
more "built in" you might be able to modify catalog.xml |
| 14:45.34 |
d_rossberg |
starseeker:
google says (tm) i have to set the proxy in java because docbook
uses java |
| 14:46.06 |
starseeker |
um |
| 14:46.21 |
d_rossberg |
but i don't
know how to set the proxy in java either |
| 14:46.24 |
starseeker |
some of the
docbook tools use java (specifically fop) but unless you're doing
pdf it's not an issue |
| 14:46.57 |
starseeker |
d_rossberg: I
must admit I'm not a genius with Docbook - I barely got fop doing
out of directory pdf generation :-( |
| 14:47.37 |
starseeker |
we intend to
get more sophisticated, but right now we're pretty basic
:-( |
| 14:49.11 |
starseeker |
I'm seeing
this: <xsl:param
name="draft.mode">yes</xsl:param> |
| 14:49.23 |
starseeker |
but we don't
have anywhere to put such settings yet |
| 14:50.38 |
``Erik |
http://failblog.files.wordpress.com/2009/11/epic-fail-christmas-lights-fail.jpg |
| 14:51.41 |
starseeker |
``Erik:
that's sure to have some parents doing a lot of unwanted explaining
to some children |
| 14:52.52 |
*** join/#brlcad imad_
(n=imad@85.195.142.183.satgate.net) |
| 14:53.06 |
imad_ |
d_rossberg, i
have typed tops |
| 14:53.15 |
imad_ |
then what
should i do? |
| 14:59.17 |
d_rossberg |
imad_: look
at the return you got, what is it? |
| 14:59.44 |
imad_ |
d_rossberg,
then? i just see a listing of maybe tables or files |
| 15:01.09 |
d_rossberg |
this is fine,
is there an all or all.g (for example) |
| 15:02.05 |
d_rossberg |
what you see
there is a list of the top elements in your BRL-CAD
database |
| 15:03.51 |
imad_ |
d_rossberg,
_GLOBAL all/ |
| 15:03.51 |
imad_ |
that's the
cray.g of the samples distributed |
| 15:04.28 |
d_rossberg |
imad_: now
type "e all" |
| 15:06.45 |
imad_ |
ok |
| 15:07.33 |
d_rossberg |
now you
should see something in the black window |
| 15:07.40 |
imad_ |
ok |
| 15:10.42 |
imad_ |
d_rossberg,
now i tried with the other objects |
| 15:10.44 |
d_rossberg |
now you could
type "rt" to see a nice picture and click on the help entry in the
menu of the mged window to get the tutotial etc. |
| 15:10.58 |
imad_ |
I understood
that "e" is to view one of the listings |
| 15:11.07 |
imad_ |
ok |
| 15:17.23 |
imad_ |
d_rossberg,
whenever i type rt, i get a black screen |
| 15:17.30 |
imad_ |
so? |
| 15:17.53 |
imad_ |
it's a full
black screen |
| 15:18.15 |
imad_ |
or a full
screen in black |
| 15:23.19 |
starseeker |
try this: rt
-F/dev/X |
| 15:23.35 |
superlinux |
ok |
| 15:24.36 |
superlinux |
starseeker,
you are its man! |
| 15:25.11 |
starseeker |
the first
raytrace tried to use opengl - thats one of our opengl
bugs |
| 15:25.14 |
superlinux |
it
worked |
| 15:25.14 |
superlinux |
awesome! and
cool |
| 15:25.58 |
superlinux |
starseeker,
but i just want for example to draw basic stuff, like a line or
whatever if very basic geometry |
| 15:26.20 |
starseeker |
superlinux:
we do 3D geometry (spheres, etc.) |
| 15:26.33 |
starseeker |
superlinux:
sounds like you are ready for this: |
| 15:26.51 |
starseeker |
http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf |
| 15:27.41 |
superlinux |
what i want
is to let people to easily convert to Linux. there is LinuxCAD
though it's not free. Quick CAD as far as i heard is has a problem
with huge DXF files |
| 15:28.32 |
superlinux |
starseeker,
got the point? |
| 15:30.02 |
superlinux |
and the rc
file is not as far as i see easily editable. I am a programmer. i
understand that i should be participating in such nice project, and
i understand that i am using an older version. |
| 15:30.40 |
superlinux |
however my
aims is migration |
| 15:30.52 |
superlinux |
migration to
linux |
| 15:30.55 |
starseeker |
superlinux:
we know our usability is weak - we're working on a next generation
GUI (you can see the prototype by typing archer) |
| 15:31.14 |
superlinux |
i did.. it
did not run |
| 15:31.32 |
superlinux |
starseeker,
the gui is not as important as the commands them selves |
| 15:31.46 |
starseeker |
if you want
to import a dxf file, try dxf-g |
| 15:32.06 |
superlinux |
they seem to
be much like the cisco router commands or a C++ language in the way
they are a standard |
| 15:32.30 |
starseeker |
actually, we
use tcl for our command line |
| 15:32.53 |
superlinux |
i meant
people find that the Autocad commands are now a standard with
time |
| 15:33.19 |
starseeker |
I doubt a lot
of AutoCAD commands would map directly to BRL-CAD |
| 15:33.30 |
superlinux |
can't you
wrap the TCL under the Autocad commands? |
| 15:33.57 |
starseeker |
superlinux:
what you should do is read the Introduction, see how BRL-CAD works,
and then see if AutoCAD commands can map to BRL-CAD |
| 15:34.08 |
superlinux |
mmm |
| 15:34.12 |
starseeker |
my guess is
the systems' underlying assumptions are often too
different |
| 15:34.22 |
starseeker |
BRL-CAD is a
solid 3D CSG modeler |
| 15:34.29 |
superlinux |
true |
| 15:34.38 |
starseeker |
AutoCAD has
some 3D stuff, but they focus on 2D quite a lot as I understand
it |
| 15:34.41 |
starseeker |
we don't do
much 2D |
| 15:34.49 |
superlinux |
what i know
is that autocad deos 3D too |
| 15:35.10 |
superlinux |
so you need
someone to write the 2d? don't you? |
| 15:35.32 |
starseeker |
if someone
wants to volunteer that would be great :-) |
| 15:35.39 |
superlinux |
ok
good |
| 15:35.51 |
starseeker |
but don't
underestimate the amount of work involved |
| 15:35.58 |
superlinux |
i'll see how
to integrate some of the commands |
| 15:36.03 |
superlinux |
i
know |
| 15:36.10 |
superlinux |
i'll see
how |
| 15:36.26 |
starseeker |
you will
likely find you have to create the functionality to support the
commands, and that has to be done in such a way as to integrate
into BRL-CAD proper |
| 15:36.47 |
starseeker |
if you see
brlcad in the channel, talk to him - he's the lead
designer/developer |
| 15:37.00 |
superlinux |
starseeker,
what if for example i set a cylinder to be a line? |
| 15:37.05 |
superlinux |
is that
ok? |
| 15:37.21 |
starseeker |
um - it may
work in some applications |
| 15:37.41 |
starseeker |
it heavily
depends on what you're trying to accomplish |
| 15:37.42 |
superlinux |
llike make
miniature the 3D objects to 2D |
| 15:38.22 |
superlinux |
all i want is
the architechtural plans you see for building houses and such and
such |
| 15:38.35 |
starseeker |
ah
:-) |
| 15:38.41 |
starseeker |
take a look
at rtedge |
| 15:38.46 |
superlinux |
thats what
makes true money! |
| 15:38.58 |
superlinux |
ok |
| 15:39.18 |
starseeker |
there is also
some work currently going on on an annotation primitive that will
help with blueprints |
| 15:40.16 |
superlinux |
ah~! you call
them blue prints such maps? |
| 15:40.26 |
superlinux |
then be
it |
| 15:40.31 |
starseeker |
that's
usually what people want ;-) |
| 15:40.37 |
superlinux |
yes |
| 15:40.54 |
starseeker |
it's a
frequent request, but not the focus of our full time
developers |
| 15:41.01 |
starseeker |
http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 15:41.05 |
starseeker |
that's
rtedge |
| 15:41.09 |
superlinux |
like the 1st
thing i thought i can do is type line on mged |
| 15:41.17 |
starseeker |
nope
:-) |
| 15:41.32 |
starseeker |
superlinux: I
REALLY suggest reading that tutorial |
| 15:41.41 |
superlinux |
ok |
| 15:41.44 |
superlinux |
i'll
check |
| 15:41.51 |
starseeker |
you will need
to understand BRL-CAD to understand how to do the job
correctly |
| 15:41.57 |
superlinux |
maybe i can
get some funding for the part |
| 15:44.11 |
superlinux |
starseeker,
how can i save the "-F/dev/X" part in the rt* commands? |
| 15:44.33 |
superlinux |
can i alias
the commands rt and rtedge? |
| 15:46.17 |
starseeker |
you can
create alias commands in .mgedrc |
| 15:46.37 |
superlinux |
how? |
| 15:47.05 |
superlinux |
e.g. alias
rt='rt -F/dev/X'? |
| 15:47.12 |
superlinux |
is'n't? |
| 15:51.04 |
superlinux |
starseeker,
sorry if i bugged you with so many questions. please, look at this
picture with blue background. this is a blueprint of course. such
things i want to be able to do |
| 15:51.12 |
superlinux |
http://www.aviationshoppe.com/AT-6-Texan.html |
| 15:53.14 |
starseeker |
superlinux:
irc is an "in and out" communication method - not always
realtime |
| 16:07.22 |
*** join/#brlcad Ralith
(n=ralith@d142-058-088-232.wireless.sfu.ca) |
| 16:07.52 |
starseeker |
superlinux:
there's a file mgedrc.html in the distribution, I
believe |
| 16:08.38 |
starseeker |
you basically
use proc |
| 16:14.16 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 16:14.16 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 16:14.16 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 16:14.16 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
| 16:14.16 |
starseeker |
growl - make
dmg requires root |
| 16:15.37 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 16:15.37 |
*** join/#brlcad Ralith
(n=ralith@d142-058-088-232.wireless.sfu.ca) [NETSPLIT
VICTIM] |
| 16:15.37 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 16:15.37 |
*** mode/#brlcad [+o brlcad] by
irc.freenode.net |
| 16:21.02 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149C24.dip.t-dialin.net) |
| 17:41.25 |
brlcad |
starseeker:
yeah, it has to go admin to mount/demount disk images with proper
access |
| 17:42.06 |
__monty__ |
brlcad, Did
you receive my memo's? |
| 17:45.09 |
brlcad |
yes, just
read them :) |
| 17:45.34 |
brlcad |
that's pretty
informative backtrace, thanks |
| 17:45.45 |
__monty__ |
No
problem. |
| 17:46.49 |
__monty__ |
About the 'p
dmp' and 'p pubvars' , did I enter them right? I just entered them
on the gdb prompt after the backtrace. |
| 17:47.04 |
brlcad |
you did, I
forgot those are #defines |
| 17:47.10 |
brlcad |
you still
have that session? |
| 17:47.54 |
brlcad |
hm, actually
dmp should have worked |
| 17:48.07 |
__monty__ |
Yeah I have
the session open still. |
| 17:48.25 |
brlcad |
but since I
make one of the X11 calls a function instead of a macro, you need
to go up the stack |
| 17:48.29 |
brlcad |
type
"up" |
| 17:48.32 |
brlcad |
then p
dmp |
| 17:49.05 |
brlcad |
p
screen |
| 17:49.21 |
__monty__ |
Should I
paste the output directly into irc? Or go via pastebin? |
| 17:49.53 |
brlcad |
pastebin if
it's more than like 5 lines |
| 17:50.04 |
brlcad |
otherwise
here is fine |
| 17:50.15 |
__monty__ |
Ok. |
| 17:50.54 |
__monty__ |
http://paste.bzflag.bz/d51d71b45 |
| 17:51.36 |
brlcad |
p
*dmp |
| 17:51.41 |
brlcad |
p
screen |
| 17:51.41 |
brlcad |
p screenp
*screen |
| 17:51.47 |
brlcad |
p
pubvars |
| 17:51.49 |
brlcad |
p
*pubvars |
| 17:53.18 |
__monty__ |
http://paste.bzflag.bz/m37757de
here you go. |
| 17:55.07 |
__monty__ |
I hope it's
helpful =) |
| 17:56.26 |
brlcad |
too |
| 18:03.54 |
brlcad |
very
helpful! |
| 18:04.13 |
__monty__ |
cheers. |
| 18:04.15 |
brlcad |
.... looks
like XDefaultScreenOfDisplay() is returning the screen number, not
the screen pointer |
| 18:04.57 |
brlcad |
which isn't
right! |
| 18:05.22 |
__monty__ |
The
bastard! |
| 18:06.02 |
``Erik |
(screen
number, or NULL?) |
| 18:06.31 |
``Erik |
hm, 0x50?
O.o |
| 18:09.14 |
brlcad |
yeah, that's
gotta be some error code |
| 18:10.09 |
brlcad |
i should
probably just rewrite libdm-X |
| 18:10.22 |
``Erik |
libdm-SDL
ftw |
| 18:10.23 |
brlcad |
the X11 code
there is a really old method |
| 18:11.17 |
brlcad |
that's a
possibility, probably even easier, but begrudging adding a new
dep |
| 18:11.33 |
brlcad |
specially
since tk should work just fine and with no added
complexity |
| 18:11.50 |
``Erik |
yeh, came up
in a discussion with starseeker at one point |
| 18:12.21 |
brlcad |
that's just
what I should do, finish off the one there, but got other code to
finish up first before going down that rabbit hole |
| 18:13.08 |
__monty__ |
tries to drag brlcad down the rabbit hole. |
| 18:14.11 |
``Erik |
oh
my |
| 18:40.43 |
CIA-41 |
BRL-CAD:
03brlcad * r36844 10/brlcad/trunk/src/libdm/dm-X.c: untested. try
to avoid the X11 calls entirely during initialization, only making
the corresponding Tk calls. XDefaultScreenOfDisplay() is return
0x50 on __monty__'s system for some unknown reason. |
| 18:40.45 |
brlcad |
__monty__:
give that a try (unfortunately can't test it myself at the
moment) |
| 18:42.03 |
__monty__ |
How do I give
it a try? |
| 19:09.16 |
CIA-41 |
BRL-CAD:
03brlcad * r36845 10/brlcad/trunk/src/libdm/dm-X.c: wrap the new tk
calls in HAVE_TK so we can compile clean |
| 19:09.32 |
CIA-41 |
BRL-CAD:
03brlcad * r36846 10/brlcad/trunk/include/dm.h: ws indent
cleanup |
| 19:09.54 |
brlcad |
__monty__:
run "svn up", then rebuild/reinstall |
| 19:19.22 |
brlcad |
don't have to
rebuild everything, just "make && make install" |
| 19:19.33 |
brlcad |
it'll just
rebuild the pieces that got updated |
| 19:21.30 |
starseeker |
is considering going down the dm-tk rabbit
hole |
| 19:21.49 |
starseeker |
if it works
and works well, would it get rid of all the other non-opengl
dms? |
| 19:22.50 |
brlcad |
many of
them |
| 19:22.54 |
brlcad |
not all of
them |
| 19:23.11 |
starseeker |
well, I
suppose plot and ps |
| 19:23.47 |
brlcad |
yeah |
| 19:43.02 |
CIA-41 |
BRL-CAD:
03brlcad * r36847 10/brlcad/trunk/src/libgcv/region_end.c: ws
indent comment cleanup |
| 19:43.25 |
__monty__ |
Sorry for the
late reply, I was studying. I took the 'run svn up' literaly, the
terminal outputted: Skipped '.' |
| 19:43.42 |
__monty__ |
Should I now
just run make and then make install? |
| 19:45.44 |
__monty__ |
I probably
should have cd'ed to the source directory first, shouldn't
I? |
| 19:47.08 |
starseeker |
that might
help _) |
| 19:47.09 |
starseeker |
:-) |
| 19:47.46 |
__monty__ |
Am I the only
mac user with problems running brlcad? |
| 19:48.09 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 19:48.22 |
starseeker |
__monty__:
there are some glitches we know about |
| 19:51.49 |
__monty__ |
Ok I did the
svn up, make && make install. Now when I try launching mged
I get the following output: WARNING: screen number is [0] \n
Bus error |
| 19:52.10 |
starseeker |
um -
__monty__ can you run in gdb again? |
| 19:52.18 |
__monty__ |
I sure
can |
| 19:53.09 |
__monty__ |
Up to
backtrace or all the other ones, like p dmp too? |
| 19:53.21 |
starseeker |
let's see
where it's dying first |
| 19:53.25 |
starseeker |
is it the
same place? |
| 19:53.54 |
starseeker |
er, yeah, up
to backtrace first |
| 19:54.13 |
__monty__ |
#0 blablba in
X_open_dm blabalbal :399 |
| 19:54.34 |
__monty__ |
I'll paste it
to pastebin if you want. |
| 19:55.03 |
starseeker |
__monty__:
let me check that dm-X line |
| 19:55.48 |
__monty__ |
http://paste.bzflag.bz/m54705f56 |
| 19:57.27 |
starseeker |
__monty__:
hmm. can you do: print privars->pix ? |
| 19:58.06 |
brlcad |
p
*dmp |
| 19:58.13 |
starseeker |
er, yeah
:-) |
| 19:58.21 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36848 10/isst/trunk/src/local_worker.c: make cut
ray fire the right direction |
| 19:58.21 |
brlcad |
and p
*privars :) |
| 19:58.32 |
__monty__ |
'print
privars->pix' gives me $1 = 0 |
| 19:58.35 |
brlcad |
curious if it
got the right width/height |
| 19:58.47 |
starseeker |
yeah, sorry -
I always get that wrong the first time I debug anything |
| 19:59.01 |
brlcad |
oooh,
DefaultRootWindow.. another X11 call |
| 19:59.06 |
brlcad |
that's the
crasher |
| 19:59.56 |
starseeker |
flips up dm-tk.c and eyes it... |
| 19:59.59 |
brlcad |
looks like if
you start with Tk windows, you have to stik with them .. maybe
something in 8.5 not playing nicely with the Mac X11
hearsheaders |
| 20:00.02 |
__monty__ |
http://paste.bzflag.bz/m1ae647d5 |
| 20:00.48 |
brlcad |
because it's
the Display* and Visual* that one gets from Tk_Display() .. that
isn't working with any X11 call |
| 20:01.14 |
brlcad |
bah, it
didn't get width/height, thx __monty__ |
| 20:01.25 |
__monty__ |
No
problem. |
| 20:01.38 |
starseeker |
__monty__:
you can run xterm and other X11 apps OK, right? |
| 20:01.55 |
__monty__ |
yep xterm,
inkscape, gimp |
| 20:02.01 |
starseeker |
hmm |
| 20:02.19 |
__monty__ |
I don't run
x11 often by the way. |
| 20:03.39 |
brlcad |
ahhh,
starting to get a handle on this |
| 20:03.52 |
brlcad |
Tk_CreateWindowFromPath() is very
informative |
| 20:08.10 |
starseeker |
arrgh |
| 20:08.17 |
starseeker |
gets badness |
| 20:09.44 |
starseeker |
X Error of
failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap) Serial number
of failed request: 343 Current serial number in output stream:
344 |
| 20:15.57 |
__monty__ |
Good night
all, if you need me to test something send me a memo. |
| 20:27.21 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
| 20:30.53 |
brlcad |
starseeker:
yeah, I busted it a couple days ago I think |
| 20:31.04 |
brlcad |
working on
it |
| 20:31.12 |
starseeker |
np |
| 20:31.27 |
brlcad |
curious, why
didn't you use HIDDEN in that HIDDEN_DM_... define? |
| 20:31.38 |
brlcad |
instead of
duplicating the two cases |
| 20:32.08 |
starseeker |
um |
| 20:32.26 |
brlcad |
intentional?
oversight? |
| 20:32.39 |
starseeker |
oversight |
| 20:32.54 |
starseeker |
think I hit a
build error and just did something to get it going |
| 20:33.27 |
CIA-41 |
BRL-CAD:
03brlcad * r36849 10/brlcad/trunk/src/libdm/dm-X.c: ws, more
verbose quellage |
| 20:34.26 |
brlcad |
o.O hm,
okay |
| 20:35.19 |
CIA-41 |
BRL-CAD:
03brlcad * r36850 10/brlcad/trunk/include/dm.h: collapse into just
one HIDDEN_DM_FUNCTION_PROTOTYPES(), use HIDDEN |
| 20:35.38 |
starseeker |
did I do
something stupid again? |
| 20:37.52 |
starseeker |
is sure he has done a lot of dumb stuff on the dm side of
things |
| 20:46.57 |
CIA-41 |
BRL-CAD:
03starseeker * r36851 10/brlcad/trunk/src/libdm/dm-tk.c: Stub out
the new functions needed after the libdm struct changes |
| 20:56.17 |
starseeker |
brlcad: is
there a quick way to enable the dm-tk build? |
| 21:02.21 |
``Erik |
hack the
gibso^Wmakefile |
| 21:03.12 |
starseeker |
``Erik: it
looks like it's set up to conditionally build, but I'm not sure
what makes DM_TK "true" |
| 21:03.35 |
starseeker |
(apparently
"WITH_TK" is not set to true for the default
enable-all?) |
| 21:04.47 |
``Erik |
it's forced
to off in configure.ac |
| 21:04.54 |
``Erik |
3685 |
| 21:05.00 |
starseeker |
ah,
thanks |
| 21:05.35 |
``Erik |
easiest would
be to muck with the values of WITH_TK_TRUE and WITH_TK_FALSE in the
Makefile itself |
| 21:07.09 |
starseeker |
well, I need
all this to propigate through so I can use dmtype set to try
switching to tk |
| 21:07.18 |
starseeker |
so it's
probably not just one Makefile |
| 21:07.54 |
``Erik |
hm, hack
configure.ac, change [ "xno" = "xyes" ] to [ "xyes" = "xyes" ] or
something? |
| 21:08.18 |
starseeker |
yeah, there's
actually a valid but commented out test right below it |
| 21:08.24 |
starseeker |
re-enabled and is testing now |
| 21:08.51 |
starseeker |
doubt I have
the chops to actually make it work but I'll take a poke and see
where it's at |
| 21:11.35 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149C24.dip.t-dialin.net) |
| 21:27.08 |
brlcad |
starseeker:
all the DM_* are from configure |
| 21:27.24 |
brlcad |
rather,
toggled high up, then conditionalized in the
Makefile.am |
| 21:28.29 |
brlcad |
which right
now looks like it toggled via --with-tk |
| 21:30.48 |
starseeker |
``Erik
spotted it - it was forced off |
| 21:33.43 |
starseeker |
urk |
| 21:33.51 |
starseeker |
turns off WITH_TK in libfb |
| 21:34.27 |
starseeker |
one problem
child at a time |
| 21:44.15 |
brlcad |
you're
working on libdm or libfb? |
| 21:59.15 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 21:59.15 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 22:15.59 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36852 10/brlcad/trunk/src/adrt/librender/
(camera.c render_internal.h): stash a copy of the tie struct in
render for use in init() functions |
| 22:20.19 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36853 10/isst/trunk/src/local_worker.c: remove
debugging printf |
| 22:20.39 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36854 10/brlcad/trunk/src/adrt/librender/cut.c:
color intersected regions |
| 22:32.23 |
starseeker |
brlcad:
libdm |
| 22:32.23 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 22:32.44 |
starseeker |
although
"workign on" is probably a bit strong - more like
"exploring" |
| 22:50.05 |
starseeker |
blinks - aside from a rather odd notion of what the center of
the screen is, this tk dm isn't doing bad at all |
| 22:52.11 |
starseeker |
(he says as
he tries to switch to rtgl and mged crashes...) |
| 22:53.09 |
starseeker |
in fact, it
already moves the havoc wireframe around more easily than X
does |
| 22:53.47 |
starseeker |
nifty |
| 23:13.33 |
starseeker |
gives --enable-aqua-tk a try and is surprised to see libdm
complain about undefined Tk symbols... hmm |
| 23:25.01 |
starseeker |
ooooo |
| 23:25.05 |
starseeker |
that makes
sense... |
| 23:25.28 |
starseeker |
DM_LIBS
doesn't HAVE tk if building without X11... |
| 23:26.28 |
``Erik |
http://www.ebaumsworld.com/video/watch/728/
an oldie but a goodie |
| 23:40.00 |
*** join/#brlcad dli (n=dli@69.172.97.211) |
| 00:08.05 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 00:40.31 |
``Erik |
nifty
http://www.collegehumor.com/video:1925317 |
| 01:23.03 |
CIA-41 |
BRL-CAD:
03brlcad * r36875 10/rt^3/trunk/src/tests/GeometryServiceTest.cxx:
stub out getDirectory and addObject, expanding the calls
throughout |
| 01:25.07 |
CIA-41 |
BRL-CAD:
03brlcad * r36876 10/rt^3/trunk/src/tests/GeometryServiceTest.cxx:
do the dir comparison assert |
| 01:40.30 |
brlcad |
``Erik:
src/libwdb/wdb.c |
| 01:40.56 |
brlcad |
you'd stubbed
something in there earlier (which was busted), I made it unbusted a
few months back but mostly left the signature you
stubbed |
| 01:45.54 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 01:55.21 |
``Erik |
noticed a bit
ago, fergot I'd done anything at all heh |
| 01:55.44 |
``Erik |
needs to be
wired to 'put' or something, I guess |
| 02:00.02 |
brlcad |
src/proc-db/metaball.c calls that
mk_metaball() now |
| 02:00.22 |
``Erik |
musta had a total context dump or something
O.o |
| 02:00.27 |
``Erik |
lipreading is
awesome http://www.collegehumor.com/video:1925762 |
| 02:01.20 |
``Erik |
asc2g, if I
understand it correctly, merely calls the tcl 'db put' command,
which hits libged's put.c, calling the mk_ routine? |
| 02:03.19 |
brlcad |
doesn't sound
right |
| 02:07.42 |
brlcad |
hm, but you
may be right! |
| 02:09.55 |
brlcad |
looks like
it's creating a wdb db object |
| 02:10.09 |
brlcad |
which means
it's not going through put.c just yet (though it
should) |
| 02:10.21 |
``Erik |
hum |
| 02:10.22 |
brlcad |
going through
the wdb_obj command table |
| 02:10.58 |
brlcad |
which calls
wdb_put_tcl -> wdb_put_cmd -> does the deed via functab's
ft_make() callback |
| 02:11.21 |
``Erik |
<--
noticed the 'put' and tcl crud in the asc2g step, dorked with the
'put' command, couldn't quite find the breadtrail between tcl and
mk_* before the retards rebooted the server 90 minutes befoer they
said they would |
| 02:11.38 |
``Erik |
so'z I asked
bob on my way out, and he thought my guess was right
*shrug* |
| 02:11.53 |
brlcad |
wdb_obj
replicates most of the commands, just with a tcl interp tossed in
to mess things up |
| 02:11.55 |
``Erik |
but he
couldn't verify, since the fileserver was rebooted an hour and a
half before they said they'd start rebooting servers |
| 02:12.11 |
``Erik |
did I mention
that they took the server down way before they said? |
| 02:12.37 |
``Erik |
waits for a fat sun diskpack to become available
O:-) |
| 02:24.10 |
CIA-41 |
BRL-CAD:
03brlcad * r36877 10/brlcad/trunk/configure.ac: |
| 02:24.11 |
CIA-41 |
BRL-CAD: if
the WITH_X11 is going to get disabled in the Makefile.am, then the
logic has |
| 02:24.11 |
CIA-41 |
BRL-CAD: to
be improved in here for determining whether to traverse into the
tk/itk dirs. |
| 02:24.11 |
CIA-41 |
BRL-CAD: if
neither x11 is detected as usable nor aquatk capabilities enabled,
then tk is |
| 02:24.11 |
CIA-41 |
BRL-CAD: off.
if tk is off or x11 is off, itk is also off. |
| 02:27.42 |
starseeker |
brlcad:
nicely done |
| 02:46.05 |
brlcad |
untested, but
should make non-x11 work again |
| 03:03.12 |
CIA-41 |
BRL-CAD:
03starseeker * r36878 10/brlcad/trunk/src/archer/TODO: Add more to
the Archer TODO file. |
| 03:13.12 |
CIA-41 |
BRL-CAD:
03starseeker * r36879 10/brlcad/trunk/src/archer/TODO: Archer TODO
items. |
| 03:25.46 |
CIA-41 |
BRL-CAD:
03brlcad * r36880 10/brlcad/trunk/src/vdeck/vdeck.1: include the
brief example from cary mann on how to use the vdeck tool. clean up
some of the language and formatting while we're here. |
| 03:26.53 |
brlcad |
mm, where
possible, those TODO entries shouldn't be vague |
| 03:27.24 |
CIA-41 |
BRL-CAD:
03brlcad * r36881 10/brlcad/trunk/AUTHORS: probably not quite
significant enough for a NEWS line, but credit Cary Mann with
special thanks for providing an example on how to use
vdeck. |
| 03:28.05 |
brlcad |
the undo line
jumped out at me as very vague, should mean something to someone
that doesn't know what the current status is -- what is (at least
one of) the next step(s) |
| 03:30.20 |
CIA-41 |
BRL-CAD:
03brlcad * r36882 10/brlcad/trunk/src/adrt/librender/cut.c: convert
undocumented floating point magic to the lowest epsilon possible.
should document it if that's insufficient (noting the
sensitivity/range/caveats) instead of leaving a magic
tolerance. |
| 03:36.16 |
starseeker |
brlcad:
that's what I'll flesh out when I talk to Bob tomorrow |
| 03:36.28 |
starseeker |
this isn't
intended to be "final" yet |
| 03:36.42 |
starseeker |
just making
sure I don't forget to discuss points |
| 03:36.43 |
CIA-41 |
BRL-CAD:
03brlcad * r36883 10/brlcad/trunk/src/libged/human.c: include
documentation provided by rain weaver on where the articulation
points should be for the various joints. |
| 03:37.17 |
brlcad |
isn't
expected to be final, but should still always be in a complete
state |
| 03:37.50 |
starseeker |
brlcad: OK,
I'll nuke the undo line until I can get specifics from
Bob |
| 03:38.41 |
brlcad |
well you
meant something by it |
| 03:38.46 |
brlcad |
what'd you
mean? |
| 03:39.36 |
starseeker |
The last time
we discussed undo (which was some time ago) Bob had a couple
specific situations he wanted to handle, but I don't remember the
details |
| 03:39.46 |
brlcad |
there is
undoubtedly a task there regardless of talking to bob |
| 03:39.49 |
brlcad |
ahh |
| 03:39.55 |
starseeker |
also we don't
do anything sane in the "run out of memory" case |
| 03:39.59 |
brlcad |
well one of
them is being able to undo transaction sets |
| 03:40.14 |
brlcad |
that's
another, disaster recovery |
| 03:40.43 |
brlcad |
if I recall,
you can't undo selections too, that would be useful |
| 03:41.04 |
brlcad |
if you're
building up a selection using the mouse of command line, then
select one too many .. can't just undo it, have to start
over |
| 03:41.16 |
brlcad |
every action
should be undoable |
| 03:41.37 |
starseeker |
mmm. That's
a problem - the assumption to date was that only actions that
change geometry are undoable |
| 03:42.02 |
brlcad |
those fall
into a separate section of "todo" classification .. that's a new
feature |
| 03:42.26 |
brlcad |
that's
reasonable, but just not what I'd expect |
| 03:43.28 |
brlcad |
I don't know
as a user which operations do and don't affect the db, especially
if I go into an edit mode |
| 03:44.05 |
starseeker |
It's doable,
but I image it involves some reworking of how selection lists are
handled |
| 03:44.06 |
brlcad |
wouldn't be
unreasonable to presume that just entering that edit mode affects
the db (writing a log, opening a transaction, whatever), and that I
should be able to undo it |
| 03:44.19 |
brlcad |
it involves
reworking a fair bit |
| 03:44.29 |
brlcad |
but it's
things that libged should be handling better anyways |
| 03:44.50 |
brlcad |
bob has all
that undo logic up in archer, it should be lower-level |
| 03:44.55 |
brlcad |
libged
commands should be transactional |
| 03:45.50 |
brlcad |
with ged_exec
style options, so you could perform any command in a
"no-action-but-tell-me-what-you-would-have-done" mode, silent
modes, verbose modes, forced/unforced, etc |
| 03:46.18 |
brlcad |
each command
returning one or more transactions that you could apply to the db
(or not) |
| 03:46.46 |
brlcad |
immediate
undo is then simply throw away the unapplied
transaction |
| 03:47.21 |
brlcad |
infinite undo
is unrolling the stack of transactions that have been
applied |
| 03:47.21 |
starseeker |
nods |
| 03:47.42 |
starseeker |
sounds
database-ish |
| 03:48.08 |
brlcad |
it
is |
| 03:48.21 |
brlcad |
not called a
"geometry database" for no reason :) |
| 03:48.32 |
brlcad |
it's
transactional now, just at a very low-level granular
level |
| 03:48.50 |
brlcad |
these are
high-level multi-object/multi-change transactions |
| 03:48.58 |
starseeker |
heh - just
wondering if we can rip some subset of code out of one of the sql
codebases to help, or if it's something we have to integrate/build
in ourselves |
| 03:49.24 |
brlcad |
this is all
pretty highly specific |
| 03:49.51 |
starseeker |
yeah, kinda
figured |
| 03:49.52 |
brlcad |
to our API,
our format, the types of transactions |
| 03:50.30 |
brlcad |
it's not much
code and not anything tricky |
| 03:50.31 |
CIA-41 |
BRL-CAD:
03starseeker * r36884 10/brlcad/trunk/src/archer/TODO: Expand on
Archer undo related items |
| 03:51.16 |
brlcad |
it's just
instead of making all the various commands do various database
changes, they instead just record what they wanted to do, and
return that |
| 03:51.26 |
brlcad |
then
something else applies the set of things they wanted to
do |
| 03:51.27 |
starseeker |
brlcad: OK.
When I heard "transactions" I started wondering what happens if
multiple people happen to be working on the same .g, like an sql
database ;-) |
| 03:51.51 |
starseeker |
that makes
sense |
| 03:52.41 |
starseeker |
might help
fit things to a libsvn based geometry server :-) |
| 03:53.15 |
brlcad |
to deal with
multiple simultaneous users, there should be locking at some level
-- the "something else that applies the set of things they wanted
to do" could have that locking logic |
| 03:53.41 |
starseeker |
nods |
| 03:53.51 |
brlcad |
right now,
it's transactionless but fragmented |
| 03:53.58 |
brlcad |
an xpush that
fails half-way leaves your db hosed |
| 03:54.06 |
brlcad |
it souldn't
do that |
| 03:54.17 |
starseeker |
good
point |
| 03:55.23 |
starseeker |
catches up on email |
| 03:57.07 |
brlcad |
goes home |
| 03:57.35 |
starseeker |
brlcad: I
imagine there'll be some chatting about Archer/MGED tomorrow at
some point if you want to join the brawl ;-) |
| 03:58.38 |
brlcad |
maybe, but
you all are already doing great on that front |
| 03:58.46 |
brlcad |
I'd like to
get a release tagged if I can |
| 03:58.46 |
starseeker |
winces |
| 03:58.51 |
starseeker |
ok, cool
:-) |
| 03:59.19 |
starseeker |
can't wait to
watch myself explain to Bob what we've got to do to libged
;-) |
| 03:59.26 |
brlcad |
our
anniversary is coming up, want to get caught up with the
pipeline |
| 03:59.31 |
brlcad |
down to 44
items (from 200+) |
| 03:59.32 |
starseeker |
ooo
:-) |
| 03:59.47 |
brlcad |
libged needs
the other refactorings first |
| 03:59.57 |
brlcad |
that was part
of refactoring the pattern into private / public funcs |
| 04:00.39 |
brlcad |
once all the
writes are wrapped up in a private _ged_write_object() and friends,
you simply change those to "record object change"
instead" |
| 04:00.58 |
brlcad |
same for
additions, deletions, selections, view changes, .. |
| 04:01.09 |
brlcad |
and it works
itself out |
| 04:01.25 |
brlcad |
becomes just
a more complex event-based setup |
| 04:01.33 |
brlcad |
with commands
generating events |
| 04:01.40 |
brlcad |
sets of
events |
| 04:02.26 |
starseeker |
nods |
| 04:02.39 |
starseeker |
wonder how
rtgl works into that... |
| 04:02.51 |
starseeker |
lots and lots
of view changing "events" :_) |
| 04:03.18 |
starseeker |
actually,
guess it shouldn't matter |
| 04:03.57 |
starseeker |
that drawing
is independent of the "normal" changes since it's not something you
want to undo partway through |
| 04:08.57 |
CIA-41 |
BRL-CAD:
03starseeker * r36885 10/brlcad/trunk/include/rtgeom.h: Add Erik's
comments on the meaning of metaball parameters. |
| 04:10.01 |
brlcad |
they don't
persist, so multiple view changes all collapse together until
there's a non-view change |
| 04:10.28 |
starseeker |
ah,
right |
| 04:10.59 |
brlcad |
doing that,
we should be able to invert most commands |
| 04:16.19 |
CIA-41 |
BRL-CAD:
03brlcad * r36886 10/rt^3/trunk/src/tests/GeometryServiceTest.cxx:
(log message trimmed) |
| 04:16.19 |
CIA-41 |
BRL-CAD: add
two more 'would be nice' features (that we won't likely get to for
a while, |
| 04:16.19 |
CIA-41 |
BRL-CAD: but
within scope regardless) of being able to extract a polygonal or
even |
| 04:16.20 |
CIA-41 |
BRL-CAD:
point-cloud representation for geometry. polygonal is
straight-forward, similar |
| 04:16.20 |
CIA-41 |
BRL-CAD: to
wireframe, but point-cloud adds in that interesting concept of
non-blocking |
| 04:16.22 |
CIA-41 |
BRL-CAD:
streaming event results (getting the points flowing across the wire
as they are |
| 04:16.24 |
CIA-41 |
BRL-CAD:
calculated). Most of the rest of the GS calls are blocking calls
that get their |
| 04:16.50 |
brlcad |
ahh, thanks
for taking care of the metaball doc |
| 04:17.03 |
starseeker |
np
:-) |
| 04:17.29 |
starseeker |
needs to flesh out the other primitive structures in there
with some doxygen goodness... |
| 04:17.44 |
brlcad |
like the
embedded latex, heh |
| 04:18.12 |
starseeker |
I think that
was actually in his original email :-) |
| 04:21.16 |
b0ef |
7.16.2 fails
to build on me |
| 04:21.21 |
b0ef |
libtool:
link: `nurb_plot.lo' is not a valid libtool object |
| 04:21.21 |
b0ef |
make[2]: ***
[librt_nil.la] Error 1 |
| 04:23.35 |
``Erik |
probably a
stale object file or something, remove the .lo file and try
again? |
| 04:24.57 |
b0ef |
hmm, yeah,
seems to be going ahead; thanks |
| 04:25.01 |
b0ef |
it doesn't
like to be built with "make -j8"? |
| 04:29.52 |
``Erik |
should be
fine with it, that's what I usually do *shrug* |
| 04:57.19 |
CIA-41 |
BRL-CAD:
03brlcad * r36887 10/rt^3/trunk/src/tests/GeometryServiceTest.cxx:
clean up the report format adding a header for each test section so
the results are easier to review. simplify the summary line
too. |
| 04:58.45 |
brlcad |
arf, really
leaving now |
| 04:58.51 |
brlcad |
korean
tomorrow! |
| 04:58.55 |
brlcad |
mm. |
| 04:58.59 |
brlcad |
wanders |
| 05:17.27 |
*** join/#brlcad dli (n=dli@69.172.97.211) |
| 09:46.31 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14B13E.dip.t-dialin.net) |
| 10:08.14 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 14:26.10 |
starseeker |
hits the road (hopefully not face first) |
| 14:35.05 |
*** join/#brlcad docelic
(n=docelic@78-2-115-20.adsl.net.t-com.hr) |
| 15:12.15 |
*** join/#brlcad Elrohir
(n=kvirc@91.20.177.62) |
| 15:18.32 |
``Erik |
highways were
good, but plenty of ice on the side roads O.o |
| 15:23.07 |
starseeker |
yep, cold one
today |
| 15:24.11 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 16:33.52 |
*** join/#brlcad superlinux
(n=imad@85.195.142.183.satgate.net) |
| 16:38.17 |
superlinux |
hi
all |
| 16:38.23 |
superlinux |
starseeker, I
hope you are at your desk. I want to know which book should I read
to write for brl cad? |
| 16:38.25 |
superlinux |
starseeker, I
hope you are at your desk. I want to know which book should I read
to write code for brl cad? |
| 16:44.11 |
*** join/#brlcad imad_
(n=imad@63.216.121.5) |
| 16:47.13 |
superlinux |
starseeker, I
hope you are at your desk. I want to know which book should I read
to write code for brl cad? |
| 16:47.37 |
superlinux |
allo?1 |
| 16:54.45 |
starseeker |
superlinux:
patience is a virtue |
| 16:55.01 |
superlinux |
al right
sorry |
| 16:55.05 |
starseeker |
there isn't
really a "programming BRL-CAD" book |
| 16:55.10 |
superlinux |
i
know |
| 16:55.45 |
superlinux |
i meant the
docs and stuf the like that enlightens me to start writing and
developing |
| 16:56.09 |
superlinux |
i am a
programmer by trade i tell you |
| 16:57.40 |
superlinux |
I saw archer
on linux. seems good by now |
| 17:00.36 |
starseeker |
take a look
at the stuff here: http://brlcad.org/wiki/Documentation |
| 17:00.51 |
starseeker |
http://brlcad.org/wiki/Developing_applications |
| 17:01.25 |
superlinux |
ok |
| 17:04.33 |
superlinux |
starseeker, i
want to make it simpler. i think you still remember discussing
writing for 2D. and also you use tcl. so can i write tcl for the
sake of BRL? |
| 17:04.54 |
superlinux |
starseeker, i
want to make it simpler. i think you still remember discussing
writing for 2D. and also you use tcl. so how can i write tcl for
the sake of BRL? |
| 17:07.11 |
starseeker |
sure |
| 17:07.16 |
starseeker |
archer is
mostly tcl |
| 17:07.45 |
starseeker |
if you want
to work on 2D tcl stuff, take a look at the sketch
editor |
| 17:07.56 |
starseeker |
it could
stand (a lot of) improvement |
| 17:08.06 |
starseeker |
and it's what
we currently have for creating 2D sketch objects |
| 17:08.49 |
superlinux |
let me see.
how and where is the sketch editor? |
| 17:09.04 |
starseeker |
/src/tclscripts/mged/skt_ed.tcl |
| 17:09.08 |
superlinux |
ok |
| 17:09.10 |
starseeker |
in the brlcad
tree |
| 17:09.19 |
starseeker |
to see it in
action, do the following in MGED |
| 17:09.34 |
superlinux |
i am
watching |
| 17:10.12 |
starseeker |
make skt.s
sketch |
| 17:10.16 |
starseeker |
e
skt.s |
| 17:10.20 |
starseeker |
sed
skt.s |
| 17:10.27 |
superlinux |
ok |
| 17:10.41 |
starseeker |
(you'll need
to create a .g file - sketch.g or some such) |
| 17:12.01 |
starseeker |
that
interface lacks usability on any number of fronts |
| 17:12.11 |
superlinux |
ok |
| 17:12.19 |
superlinux |
i'll try my
best |
| 17:12.33 |
starseeker |
so if you
want to start improving it as a 2D sketch editor, that might be a
good starting point |
| 17:13.19 |
superlinux |
nA! |
| 17:13.26 |
superlinux |
that's really
bad! |
| 17:13.34 |
starseeker |
yep |
| 17:13.53 |
superlinux |
i was
thinking thru the normal mged |
| 17:14.25 |
superlinux |
i type "line"
and directly i get the prompts similar to autocad's |
| 17:15.01 |
starseeker |
in BRL-CAD,
2D lines exist only inside individual "sketch" objects |
| 17:15.04 |
superlinux |
maybe i can
read the code of sketch and apply them in mged |
| 17:15.29 |
starseeker |
you could add
a terminal to the sketch editor that supported such
commands |
| 17:16.54 |
starseeker |
eventually we
might be able to merge a sophisticated edit mode triggered by a
make sketch into MGED proper, but for now it's better to work in
the specific 2D editor to experiment |
| 17:17.24 |
superlinux |
ok |
| 17:17.47 |
superlinux |
cos what you
said last i want to achieve |
| 17:18.08 |
starseeker |
superlinux:
we'd have to take that up with brlcad |
| 17:18.18 |
starseeker |
but proof of
concept would help |
| 17:18.33 |
superlinux |
however in
Quick CAD it has the problem of not loading huge files |
| 17:19.11 |
superlinux |
and cos I
find scripting languages easy, i wanted to do it in brl
cad |
| 17:23.34 |
starseeker |
erm... now
tkhtml3 is working... |
| 17:23.37 |
starseeker |
blinks |
| 17:44.03 |
louipc |
yeah
dagnabit. a good sketch editor is #1 on my wishlist. No time to
really look into it though :( |
| 18:03.08 |
*** join/#brlcad docelic
(n=docelic@78-2-72-254.adsl.net.t-com.hr) |
| 18:14.15 |
*** join/#brlcad imad_
(n=imad@85.195.142.183.satgate.net) |
| 19:03.34 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 19:03.34 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 19:54.45 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 20:03.43 |
*** join/#brlcad dli (n=dli@69.172.97.211) |
| 20:24.02 |
*** join/#brlcad starseeker
(n=starseek@BZ.BZFLAG.BZ) |
| 20:56.35 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 20:56.35 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 20:56.35 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 21:04.47 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 21:28.43 |
*** join/#brlcad Nohla
(n=jesica@201.255.247.166) |
| 21:28.52 |
brlcad |
hola Nohla
! |
| 21:29.13 |
Nohla |
brlcad muy
buenas tardes! |
| 21:39.54 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 21:53.50 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 21:53.50 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 21:53.50 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 21:53.50 |
brlcad |
whatcha doing
crashing pine ``Erik :) |
| 21:53.51 |
``Erik |
I've no
idea |
| 21:53.51 |
``Erik |
I was trying
to send a mail |
| 21:53.51 |
``Erik |
and it
asploded |
| 21:53.51 |
brlcad |
bustage |
| 21:53.51 |
``Erik |
froze up for
a while, then popped to cmd |
| 21:53.51 |
``Erik |
may've subconsciously threw a fat vi sequence at
it |
| 21:53.51 |
``Erik |
waht're you
doing not migrating machines, brlcad :) |
| 21:53.51 |
brlcad |
trying to get
my box empty of urgencies |
| 21:54.14 |
brlcad |
mailbox |
| 21:54.14 |
brlcad |
down to
42! |
| 21:54.47 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 21:58.29 |
``Erik |
quick,
explode the earth before word gets out |
| 21:58.59 |
starseeker |
pulls up Earth model... |
| 21:59.27 |
``Erik |
in
intergalactic_highway.s ... |
| 22:01.39 |
``Erik |
nice. brlcad,
that machine is "host down" :D I ain't walkin' over there to look
at it, I did my walk for the day |
| 22:03.19 |
brlcad |
ahh, probably
the power outage |
| 22:03.25 |
brlcad |
never brought
back up |
| 22:07.20 |
*** join/#brlcad imad_
(n=imad@85.195.142.183.satgate.net) |
| 22:15.53 |
``Erik |
Problem
detected: "Received abort signal(sig=?)". |
| 22:15.53 |
``Erik |
Pine
Exiting. |
| 22:16.12 |
``Erik |
I'm so
badass, you can't even hope to grok my signal #'s |
| 22:17.55 |
brlcad |
exited on
signal 6 (core dumped) |
| 22:18.23 |
brlcad |
sounds like
pine manually called abort() |
| 22:18.51 |
``Erik |
mebbe,
backtrace of the core indicates a socket op going screwy in a
thread |
| 22:19.34 |
``Erik |
<-- looks
at the shiney fbsd8 box with both pine and mutt O:-) |
| 22:35.44 |
yukonbob |
is funny to
see "shiny" and "pine" in the same sentence. |
| 22:47.23 |
CIA-41 |
BRL-CAD:
03starseeker * r36888 10/brlcad/trunk/src/archer/TODO: Add more
detailed notes on some items in Archer TODO - more to
come. |
| 22:54.26 |
CIA-41 |
BRL-CAD:
03starseeker * r36889 10/brlcad/trunk/configure.ac: Another stab at
itk build logic |
| 23:00.04 |
brlcad |
your else
clause is flawed there.. :) |
| 23:00.16 |
brlcad |
and should
move the result out |
| 23:01.42 |
starseeker |
how is the
else clause flawed? |
| 23:02.05 |
starseeker |
moves result... |
| 23:03.16 |
starseeker |
oh, you mean
I don't need to check aquatk at that level? |
| 23:04.17 |
starseeker |
really,
shouldn't it just be the build agatinst tk? |
| 23:07.02 |
*** join/#brlcad docelic
(n=docelic@78-2-64-60.adsl.net.t-com.hr) |
| 23:09.53 |
docelic |
Hey
folks |
| 23:10.01 |
starseeker |
howdy |
| 23:11.08 |
docelic |
When's a new
release being planned? |
| 23:11.33 |
starseeker |
should be
pretty soon |
| 23:12.49 |
CIA-41 |
BRL-CAD:
03starseeker * r36890 10/brlcad/trunk/configure.ac: Move MSG_RESULT
out of logic |
| 23:14.13 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 23:19.28 |
CIA-41 |
BRL-CAD:
03starseeker * r36891 10/brlcad/trunk/configure.ac: Whoops - move
one more MSG_RESULT out of logic |
| 00:44.58 |
CIA-41 |
BRL-CAD:
03brlcad * r36892 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
prevent bombing if you end up working with an empty bot. don't try
to alloc 0 vertices/faces. let the user know, though. |
| 01:10.22 |
brlcad |
docelic:
trying to get to testing all day today, hopefully
tomorrow |
| 01:11.05 |
docelic |
Ah nice, I
didn't actually know the release time was nearing, I asked
accidentaly :) |
| 01:11.29 |
brlcad |
our usual
schedule is the first week of every month |
| 01:11.32 |
brlcad |
we're a few
days late |
| 01:25.10 |
CIA-41 |
BRL-CAD:
03brlcad * r36893 10/brlcad/trunk/TODO: analyze command output
formatting needs some TLC. column formatting is screwy and
customization would be nice. |
| 01:28.30 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 01:29.03 |
brlcad |
tests bot prep optimization with dubidity |
| 01:36.20 |
CIA-41 |
BRL-CAD:
03brlcad * r36894 10/brlcad/trunk/TODO: not sure EDITOR will make
this iteration given we're no longer down to the wire but late. add
note about vls name wrapping before it's forgotten too (for
annotations and then some) |
| 01:46.03 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36895 10/brlcad/trunk/TODO: honest. |
| 01:46.30 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 01:46.46 |
brlcad |
:) |
| 01:48.27 |
``Erik |
"see,
motorcyclists do it all the time. But human beings do not"
hah |
| 01:48.29 |
``Erik |
topgear++ |
| 01:49.36 |
brlcad |
creates a 2.7M test case |
| 01:49.57 |
``Erik |
of? |
| 01:50.28 |
brlcad |
bot prep
mod |
| 01:50.38 |
``Erik |
ah |
| 01:50.46 |
``Erik |
um, I have a
big one |
| 01:50.57 |
``Erik |
more than
2.7m... around 7m triangles... |
| 01:51.05 |
brlcad |
not sure I
believe what rt is reporting for PREP |
| 01:51.27 |
brlcad |
2.7 should be
good, order bigger than what I was testing |
| 01:51.51 |
``Erik |
(the
facetize_all/allbots script pairing is NOT a good solution for what
I need, btw... the failed conversions remain as they were and cause
very long fail episodes in my load) |
| 01:51.52 |
brlcad |
just four
sqrts, but might be insignificant |
| 01:52.23 |
``Erik |
unfortunately, I wasn't able to get a
clean facetization of any nontrivial model in our
set... |
| 01:52.35 |
``Erik |
m35, toyjeep,
tankcar, ... even pinewood fail something :( |
| 01:52.41 |
brlcad |
yep |
| 01:52.59 |
brlcad |
I ran through
all of db a couple years ago and saw that the majority
fail |
| 01:53.13 |
``Erik |
kinda renewed
my marching cubes effort a little :/ |
| 01:53.16 |
brlcad |
that'd be a
great project, at least make those all succeed! |
| 01:53.40 |
``Erik |
oh, even
managed straight up crashes in the nmg routines with most of
those |
| 01:53.44 |
brlcad |
I've seen it
fail on some pretty simple stuff, has to be bugs |
| 01:53.52 |
``Erik |
the, um, roll
bar on the toyjeep I think, null pointer |
| 01:53.54 |
brlcad |
bu_bombs are
normal |
| 01:54.07 |
brlcad |
there's an
error handler set, it's how nmg was written to work |
| 01:54.22 |
brlcad |
exception-style |
| 01:54.27 |
``Erik |
heh |
| 01:54.30 |
brlcad |
yeah |
| 01:54.36 |
``Erik |
I have a
strong feeling I know the 3 assclowns responsible :/ |
| 01:54.38 |
brlcad |
teh
SUCK |
| 01:55.28 |
``Erik |
(should
libgcv surrender longjmp as an error handler?) |
| 01:55.37 |
brlcad |
well fuck ..
this optimization didn't do a damn thing. boo. |
| 01:55.59 |
brlcad |
it has to at
that level |
| 01:56.06 |
brlcad |
otherwise
it'll crash |
| 01:56.09 |
brlcad |
s/crash/abort/ |
| 01:56.25 |
brlcad |
at least
until you mod the nmg code to not throw a bomb |
| 01:56.32 |
brlcad |
that's what
needs to happen |
| 01:56.38 |
``Erik |
heh |
| 01:56.44 |
brlcad |
propagate
error up or set error state or whatever |
| 01:56.54 |
``Erik |
yeh, return
codes are how I'd like to go |
| 01:57.30 |
brlcad |
I really do
think the nmg code could be shored up more solid |
| 01:58.14 |
brlcad |
it's not had
a dev work on it that focuses on robust input checking and
condition testing |
| 01:59.12 |
brlcad |
it's got a
good bit of testing, but just not comprehensive |
| 02:00.21 |
brlcad |
it kind of
needs hooks like what indianlarry did for nurbs, effectively yes,
no, and "maybe" tolerancing so it knows whether it's really stuck
or not |
| 02:01.12 |
``Erik |
bugstomp in
that would be a shweet task for a code wizard looking to start on
BRL-CAD development, I'd imagine |
| 02:01.36 |
``Erik |
re-arch might
need more experience iwth the tangle |
| 02:02.37 |
brlcad |
an
experienced coder, yeah |
| 02:02.52 |
brlcad |
doesn't need
rearch |
| 02:03.01 |
brlcad |
at least I
don't see things like bomb elim as rearch |
| 02:03.20 |
brlcad |
it implements
radial edge with euler, pretty textbook |
| 02:03.40 |
``Erik |
isn't very familiar with the code *shrug* so it viewing a
public header change as a possible rearch grade thing
:) |
| 02:05.07 |
brlcad |
moving back
into libnmg would probably make that a much more tractable
task |
| 02:05.20 |
``Erik |
hrm, $1k for
a roll cage, $500 for a roll bar |
| 02:06.17 |
brlcad |
aha! |
| 02:06.27 |
``Erik |
? |
| 02:06.30 |
brlcad |
there's a
damn malloc in the routine I was optimizing that
dominates |
| 02:06.34 |
``Erik |
heh |
| 02:06.38 |
``Erik |
finally used
a profiler? :> |
| 02:06.44 |
brlcad |
shut
it |
| 02:06.58 |
``Erik |
wonders if we should have mempool stuff in
libbu |
| 02:07.10 |
``Erik |
mebbe
threadpool, too |
| 02:08.33 |
``Erik |
sonofabitch,
docbook screwed the port update |
| 02:08.46 |
``Erik |
http://people.freebsd.org/~amdmi3/brlcad-7.16.2.log
:( (worked fine on xeon and core duo) |
| 02:11.47 |
brlcad |
looks like
out-of-srcdir issue |
| 02:11.59 |
``Erik |
hm, APACHEFOP
not being set, but FOP crap still being built, I think |
| 02:12.32 |
brlcad |
it's set to
":" |
| 02:12.40 |
``Erik |
no, that's in
srcdir, it's an invalid call to fop |
| 02:12.55 |
brlcad |
hrm? |
| 02:12.59 |
``Erik |
I'll msg him
and ask if he has java installed |
| 02:13.01 |
brlcad |
it's
complaining about that manpage rename |
| 02:13.07 |
brlcad |
manpages are
xsltproc |
| 02:13.10 |
brlcad |
pdf is
fop |
| 02:13.13 |
``Erik |
yeh |
| 02:13.45 |
``Erik |
'cept that
file it's trying to move it to should exist in src? O.o |
| 02:14.01 |
brlcad |
it did
correctly set XSLTPROC to : .. but probably shouldn't have run
through those build rules in doc/docbook regardless |
| 02:14.08 |
brlcad |
that stuff
changed a couple weeks ago |
| 02:14.11 |
brlcad |
might not be
an issue any more |
| 02:14.21 |
``Erik |
it's a
tinderbox |
| 02:14.22 |
``Erik |
hrm |
| 02:14.44 |
``Erik |
knows that there were several things he had to patch in the
port to make it compile :/ |
| 02:15.01 |
brlcad |
right, it ran
the rule with : so it did nothing.. yet then still wants the file
(which is bogus) .. shouldn't have ran the amn rule but the files
are probably listed as install files |
| 02:15.18 |
brlcad |
so the _MAN
need to be conditionalized too |
| 02:15.34 |
brlcad |
always
putting the man down |
| 02:15.46 |
``Erik |
shoulda used
TeX instead of docbook *cough* O:-) |
| 02:15.47 |
brlcad |
another fix
could be to just make xsltproc a dependency |
| 02:16.03 |
brlcad |
yeah, tex as
a dep is better than xsltproc....right |
| 02:16.47 |
brlcad |
should
probably make it a dep anyways so the manpages are
built/installed |
| 02:16.50 |
``Erik |
latex
actually works, xsltproc has a bit of a rep for being flakey from
'the day', and bunches of docbook stuff wants java
around |
| 02:16.52 |
brlcad |
the fix will
just make it skip em |
| 02:17.17 |
``Erik |
roff,
mwahaha |
| 02:17.18 |
brlcad |
java is just
for the pdf stuff (because of fop) |
| 02:17.31 |
``Erik |
every
xsltproc alternative is written in java, though |
| 02:17.35 |
brlcad |
xsltproc
itself hasn't really caused any headaches |
| 02:17.50 |
brlcad |
who cares,
we're not using the alternatives :) |
| 02:18.34 |
brlcad |
apply
favorite car analogy, that makes no relevant sense :) |
| 02:18.41 |
``Erik |
svn co
https://brlcad.svn.sourceforge.net/svnroot/brlcad/docs/trunk
brlcad-docs |
| 02:18.43 |
``Erik |
O:-) |
| 02:19.37 |
``Erik |
will dork with crap tomorrie, is in relax
mode |
| 02:19.39 |
brlcad |
that doesn't
fix this problem, just punts it to the port for
brlcad-docs |
| 02:21.25 |
``Erik |
grabs a beer, his guitar and jams out 'daytripper'
O.o |
| 02:31.47 |
brlcad |
OMFG |
| 02:32.14 |
brlcad |
tri_specific,
why dear ghod, oh why .. do you allocate 9 f'ing values on the
heap |
| 02:33.16 |
brlcad |
seriously,
even for "optional normals", that's a bit nutty
spensive |
| 02:39.00 |
starseeker |
``Erik: I'll
go over that configure logic on Monday and see if I can't make it
more robust as far as disabling things |
| 02:39.21 |
starseeker |
isn't REALLY trying to make ``Erik
miserable... |
| 02:41.32 |
brlcad |
starseeker:
the kicker test is to try without fop and with xsltproc, then
without fop and without xsltproc, then with fop and without
xsltproc |
| 02:41.54 |
starseeker |
nods |
| 02:41.59 |
brlcad |
if you mv the
binary to go through the four setups, should week out the
problems |
| 02:42.36 |
starseeker |
I was kinda
feeling my way when I did most of that - not that I'm fluent now
but I think I stand a somewhat better chance of getting things
right now |
| 02:44.56 |
starseeker |
will try that |
| 02:53.15 |
``Erik |
:D |
| 02:54.08 |
``Erik |
tunes that func to allocate one value 9 times for
brlcad |
| 02:54.50 |
``Erik |
<--
installing a base system on a thumbdrive for his arm machine to see
if usb boot is reasonably doable |
| 02:57.09 |
brlcad |
interesting
doc info on the list starseeker |
| 02:57.51 |
brlcad |
worth a quick
peek but the copy and translate would probably still be my naive
pick |
| 02:58.23 |
brlcad |
i presume
gabriel isn't here incognito? |
| 02:58.29 |
brlcad |
~seen
gabriel |
| 02:58.32 |
ibot |
gabriel
<n=gabriel@d24-141-18-191.home.cgocable.net> was last seen on
IRC in channel #storm, 18d 18h 13m 6s ago, saying: 'the info i
added is in the property constructor parameters
section'. |
| 02:58.35 |
``Erik |
ponders saying "gettextize" and running like
hell |
| 02:59.03 |
brlcad |
yeah, each
paragraph becomes a gettext phrase |
| 02:59.20 |
brlcad |
tens of
thousands of gettext lines... |
| 02:59.21 |
``Erik |
every C
string |
| 02:59.35 |
``Erik |
many needing
to be redone some |
| 02:59.42 |
brlcad |
taking 100x
longer to compile all the docs than it takes the
sources! |
| 02:59.51 |
``Erik |
well |
| 02:59.56 |
brlcad |
ah yeah, the
C strings would be cool |
| 02:59.57 |
``Erik |
I was
thinking the sources, not the docs... |
| 03:00.08 |
brlcad |
yeah, I was
(jokingly) talking about the docs |
| 03:00.21 |
``Erik |
how would the
tcl strings interface? |
| 03:02.01 |
brlcad |
tcl has it's
own l10n and i18n features |
| 03:02.17 |
brlcad |
particularly,
message catalogs for translations iirc |
| 03:02.47 |
``Erik |
3 months to
make all the source work it, then 2 months for each translation
*shudder* |
| 03:03.42 |
``Erik |
1979:
<dude1> dude, what if someone wants this in a language other
than english? <dude2> uh... whu? BWAHAHAHAHA |
| 03:03.45 |
``Erik |
O:-) |
| 03:04.39 |
brlcad |
basically
feed it inputs files like gettext, then after you load a locale:
replace 'puts "hello"' with 'puts [::msgcat::mc
"hello"]' |
| 03:04.40 |
``Erik |
even in a toy
app, gettext is a royal pain |
| 03:04.41 |
brlcad |
tcl doesn't
use gettext, they do their own thing |
| 03:04.56 |
brlcad |
all build in
that msgcat package |
| 03:05.15 |
brlcad |
tcl would
probably be easier than the C side actually |
| 03:05.59 |
``Erik |
one of my
kittens is attempting to climb up my pants leg O.o if it weren't
for the pointy bits, it'd be cut (until the knee, then it'd be
weird) |
| 03:06.02 |
``Erik |
cute |
| 03:07.07 |
brlcad |
until it's a
little higher still, then no longer cute or weird |
| 03:07.43 |
``Erik |
nah, at the
knee. O:-) |
| 03:09.07 |
``Erik |
makes a bot, g2asc's it, then gdb breaks the asc2g to figure
out the effin' call path |
| 03:09.09 |
starseeker |
brlcad: yeah,
saw that email - I'm thinking copy and translate too |
| 03:09.44 |
brlcad |
should
respond to him on the downsides of the other options |
| 03:10.16 |
``Erik |
well, eff, I
broke things |
| 03:10.21 |
starseeker |
brlcad:
probably, but they all boil down (to me) of "not enough of an issue
yet to justify more machinery " |
| 03:10.46 |
starseeker |
we're still
shaking down the stuipd-simple method, nevermind adding more tools
into the mix |
| 03:10.57 |
starseeker |
flips up the email again |
| 03:14.29 |
brlcad |
that's a fair
response :) |
| 03:14.58 |
brlcad |
unless he
wants to help work on something more robuse ;) |
| 03:15.33 |
starseeker |
I'm also a
bit dubious as to why poxml is easier for translaters than straight
up xml... |
| 03:15.54 |
starseeker |
Nohla seems
to have done just fine working within the existing xml tags
:-) |
| 03:17.06 |
brlcad |
yep |
| 03:17.16 |
brlcad |
i think his
argument was more about maintenance |
| 03:17.34 |
brlcad |
say we need
to update/fix the english tutorial .. what to do about 20
translations |
| 03:17.49 |
brlcad |
becomes
rather free-for-all |
| 03:18.09 |
starseeker |
true, but the
translations still have to happen regardless of what the
surrounding markup is |
| 03:19.13 |
brlcad |
right, but I
gathered the other tools implicitly involve some sort of awareness
of the other languages, so the differences are more
evident |
| 03:19.20 |
starseeker |
wonders why a script checking svn status on changes since
last release tag for english doc files couldn't be used to flag the
other language versions as "need work" |
| 03:19.40 |
brlcad |
that's
basically his second option, no? :) |
| 03:19.51 |
brlcad |
the CON isn't
a biggie |
| 03:20.21 |
starseeker |
yes, except
we don't introduce any markup - just a "tell me which english xml
files changed over this interval" report |
| 03:22.09 |
starseeker |
only think I
can see MAYBE getting fancy with is something that adds a warning
to the translated output that it's out of date if there is a change
to the english version and no corresponding change to the
translated file |
| 03:29.58 |
CIA-41 |
BRL-CAD:
03brlcad * r36896
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: |
| 03:29.58 |
CIA-41 |
BRL-CAD:
well, screw me. no savings on eliminating four sqrt() calls due to
an egregious |
| 03:29.58 |
CIA-41 |
BRL-CAD:
number of malloc calls (two per bot face) to allocate a
tri_specific and space |
| 03:29.58 |
CIA-41 |
BRL-CAD: for
normals. holy flying bat crap. tri_specific's interface needs to
be |
| 03:29.59 |
CIA-41 |
BRL-CAD:
improved. made prep use the caller's tolerance instead of magic
numbers. |
| 03:31.24 |
brlcad |
I could see
there be some value to doing something like gettext style
substitutions as a prep step so some translated phrases are
consistently managed |
| 03:31.45 |
brlcad |
like "Shift
Grips" |
| 03:32.00 |
brlcad |
instead of
the variety of ways that could get translated in one file
alone |
| 03:32.12 |
starseeker |
yeah, it has
some merits |
| 03:32.23 |
starseeker |
is reading up on xliff... |
| 03:33.12 |
starseeker |
arrrgh - what
is it with xml folks and java... |
| 03:33.17 |
``Erik |
tries to figure out a good VCS for a windows using
non-programmer :/ |
| 03:33.34 |
``Erik |
xml is for
java, java does xml... no SANE person would use xml...
:D |
| 03:34.07 |
``Erik |
ponder;
<alpha><beta
gamma=0></beta></alpha> |
| 03:34.08 |
``Erik |
really? |
| 03:34.15 |
``Erik |
(alpha (beta
(gamma 0)) |
| 03:34.16 |
``Erik |
) |
| 03:34.38 |
``Erik |
'(alpha (beta
(gamma 0))) and ya don't even need to write code to deal
O:-) |
| 03:37.21 |
``Erik |
notes that the network protocol for isst has been mostly
ascii-ized and seems to be immediately readable scheme/lisp *cough*
O:-) |
| 03:38.21 |
brlcad |
runs some quick calculations |
| 03:39.34 |
``Erik |
we should get
a decently ugly bot only model so I can do an rt vs libtie
comparison and see if it's worth pursuing. |
| 03:40.21 |
brlcad |
heh,
nice |
| 03:40.38 |
``Erik |
? how much
did you beef up bot? |
| 03:40.39 |
brlcad |
we presently
have 204k lines of documentation in svn |
| 03:40.44 |
``Erik |
ah |
| 03:41.31 |
brlcad |
I have a
couple bot-only models |
| 03:41.57 |
brlcad |
run anything
through g-stl and you can too! |
| 03:42.17 |
``Erik |
heh |
| 03:42.26 |
brlcad |
1.2M words of
docs (includes m4 markup and xml tags) |
| 03:42.28 |
``Erik |
provided
g-stl happens to work *cough* |
| 03:44.10 |
``Erik |
more
interested in a 'worst case' difference type set |
| 03:44.17 |
``Erik |
correctness
#'s |
| 03:44.43 |
brlcad |
that's
roughly 4000 to 6000 *pages* of documentation |
| 03:44.55 |
brlcad |
wow |
| 03:46.04 |
brlcad |
assuming
markup is substantial, which I can't imagine being even 50%, that's
still 2000-3000 pages |
| 03:46.35 |
brlcad |
Nohla: you
got about 4 pages done, right? :) |
| 03:47.49 |
CIA-41 |
BRL-CAD:
03brlcad * r36897 10/brlcad/trunk/TODO: tri_specific suck. make
better. |
| 03:48.06 |
Nohla |
on pdf are
9,1 pages |
| 03:49.00 |
Nohla |
counting
images |
| 03:49.03 |
brlcad |
:) |
| 03:49.14 |
brlcad |
so yeah,
about 4 pages of text :) |
| 03:50.26 |
Nohla |
5, but 5 is
about 4 pages too :) |
| 03:51.46 |
brlcad |
therein lies
the importance of working on the documentation subsystem.. it's not
that we don't have documentation, we have lots of documentation but
it's inconsistently managed, inaccessible to new users, not readily
searchable, not online, and not organized/categorized |
| 03:52.00 |
brlcad |
just to name
a few faults :) |
| 03:52.19 |
brlcad |
damn I didn't
realize there was that much documentation checked in |
| 03:52.30 |
brlcad |
mm.. lemme
eliminate the old mail and recount |
| 03:54.26 |
Nohla |
program has
no a searching tool for helping? |
| 03:54.28 |
brlcad |
drops about
500-700 off the count |
| 03:54.49 |
brlcad |
Nohla: not
entirely true, there are some search facilities |
| 03:54.53 |
Nohla |
brlcad sorry,
I've never display it yet :( |
| 03:54.55 |
brlcad |
they're just
not "great", they're okay |
| 03:55.29 |
brlcad |
there's the
built-in search facilities of 'man' and apropos for the manual
pages |
| 03:55.58 |
brlcad |
there is pdf
and html searching capabilities for the web content, but they're
not presently synchronized with the website |
| 03:56.10 |
brlcad |
(but should
be soon) |
| 04:01.53 |
brlcad |
starseeker,
make clean fails in doc/docbook :) |
| 04:01.56 |
brlcad |
tee
hee |
| 04:03.33 |
Nohla |
starseeker
reminds me to "The little prince" :) |
| 04:04.31 |
Nohla |
oh how
Scandinavian of you XD |
| 04:11.20 |
Nohla |
good night
people, as you see, I need a snap at least :) |
| 04:11.51 |
starseeker |
brlcad:
auuugh |
| 04:12.14 |
starseeker |
Nohla: night
- when you have time I need to explain how to build spanish
docs |
| 04:12.15 |
brlcad |
Nohla: haha,
kinda acts like him sometimes too |
| 04:12.35 |
starseeker |
probably doesn't want to know... |
| 04:12.46 |
brlcad |
you've not
read the little prince? |
| 04:12.54 |
starseeker |
shakes head |
| 04:12.56 |
brlcad |
great
book |
| 04:12.56 |
starseeker |
nope |
| 04:13.07 |
brlcad |
Nohla: buenas
noches! |
| 04:13.23 |
brlcad |
it's a kids
book for adults |
| 04:13.36 |
starseeker |
checks with the all-knowing google... |
| 04:13.45 |
``Erik |
heh |
| 04:13.53 |
``Erik |
brlcad won't
quit jabbering about it |
| 04:14.06 |
brlcad |
what you
talking about? |
| 04:14.13 |
brlcad |
haven't said
anything about that in years |
| 04:14.15 |
``Erik |
frankly, I'd
rather grab a copy of 'the prince' than 'the little
prince' |
| 04:14.22 |
``Erik |
yeah, you
jabbered about it just a few years ago! |
| 04:14.26 |
``Erik |
constant, I
tell ya! |
| 04:14.34 |
brlcad |
heh |
| 04:14.38 |
``Erik |
you were
talking loads about it to rain I think |
| 04:14.42 |
``Erik |
saying it
needs to be read in spanish |
| 04:15.06 |
Nohla |
starseeker
you couldn't be so sweet as little prince!, I hope you not to use
that nick for a technical reason as a telescope, Isn't
it? |
| 04:16.48 |
``Erik |
nohla:
starseeker delved deep into the land of car and cdr, begun to see
the fundamental fabric of the universe, but couldn't become one...
so he started seeking to become once with the essense
O:-) |
| 04:17.14 |
brlcad |
you even lost
me on that one |
| 04:17.35 |
``Erik |
http://xkcd.com/224/ |
| 04:17.54 |
``Erik |
(he commits a
.pl tomorrow...) |
| 04:17.57 |
starseeker |
you know, I
think I may have read that when I was very very
young... |
| 04:18.58 |
Nohla |
starseeker,
before to learn reading? XD |
| 04:19.08 |
starseeker |
probably |
| 04:19.25 |
starseeker |
the picture
of the kid on a small rock rings some kind of bell |
| 04:20.07 |
starseeker |
Nohla: want
to build your html and pdf documentation using BRL-CAD's make
system instead of the long commands? |
| 04:21.48 |
Nohla |
starseeker
I'm too tired to do it succesfully right now, but I'll be glad you
help me tomorrow, maybe |
| 04:22.06 |
starseeker |
Nohla: sounds
good :-) Hopefully it will make things easier for you |
| 04:22.09 |
``Erik |
is this next
release going to be an internal distribution? |
| 04:22.31 |
Nohla |
anyway, good
is to learn differents way to the same place :) |
| 04:22.33 |
starseeker |
``Erik: I
don't think so |
| 04:22.38 |
``Erik |
fekc |
| 04:23.06 |
starseeker |
Nohla: you
have seen the "by hand" way - make will do that for you
automatically, but you will understand what it is doing |
| 04:23.13 |
starseeker |
which is a
good thing :-) |
| 04:24.24 |
brlcad |
starseeker:
where are the Vol II apendices in the repo? |
| 04:24.38 |
starseeker |
they
aren't |
| 04:24.46 |
starseeker |
that's what
janine was turning into individual docbook files |
| 04:24.50 |
starseeker |
for man
pages |
| 04:25.08 |
brlcad |
``Erik: more
time to fix shelling :) |
| 04:25.14 |
brlcad |
ah,
k |
| 04:25.37 |
``Erik |
shelling is a
lesser concern for me atm |
| 04:26.33 |
``Erik |
huzzah,
7.16.2 got the local herpes treatment, I can pass out gtk
binaries |
| 04:27.26 |
starseeker |
doesn't understand that but feels vaguely
insulted |
| 04:27.42 |
starseeker |
``Erik:
awesome xkcd cartoon :-) |
| 04:29.08 |
Nohla |
:) |
| 04:29.38 |
``Erik |
starseeker:
14 months of "yeah, we're past deadline, but next release,
honest!", flak left and right, september or so it went from being
fixing stuff to waiting for distributino... |
| 04:29.54 |
starseeker |
ah |
| 04:29.57 |
``Erik |
so on monday,
I can FINALLY redeem myself |
| 04:30.00 |
starseeker |
heeh |
| 04:30.26 |
``Erik |
this is the
shit, uh, |
| 04:32.25 |
``Erik |
needs to learn to not blink *sigh* |
| 04:32.40 |
``Erik |
or mebbe
figure out how to get on the mailing list for distro |
| 04:38.24 |
brlcad |
sends out the summary stats to the list |
| 04:39.17 |
``Erik |
bwahahahaha,
a little fast running and the cats wig out :D |
| 04:42.26 |
starseeker |
is dissapointed - xkcd has no poster version of the lotr
chart |
| 04:44.34 |
``Erik |
I thought
they had an svg |
| 04:44.41 |
``Erik |
email
him |
| 04:48.22 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36898 10/brlcad/trunk/src/adrt/load.c: quell
silly warnings. |
| 04:48.30 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36899 10/brlcad/trunk/src/adrt/adrt_struct.h:
fake a size |
| 04:48.53 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r36900
10/brlcad/trunk/src/adrt/librender/render_internal.h: prepare to
make this an assoc! |
| 04:52.28 |
starseeker |
lol:
https://graphics.stanford.edu/wikis/cs448b-09-fall/FP-OgievetskyVadim |
| 04:52.55 |
starseeker |
doesn't have
the orc dwindling ability, but that's still awesome... |
| 04:54.31 |
starseeker |
yeah, more I
look he's got only a couple of the dimensions |
| 04:54.58 |
starseeker |
still, a
class project based off of an xkcd cartoon... |
| 04:55.25 |
brlcad |
that's
fantastic |
| 04:55.33 |
brlcad |
sends his summary to the mailing list |
| 04:55.42 |
brlcad |
iiiinteresting stats on the
docs |
| 04:55.48 |
brlcad |
puts things
into perspective even more |
| 04:56.14 |
starseeker |
waits for gmail to get the word... |
| 04:57.52 |
brlcad |
so need to
get that organized.. so much effort underutilized, and that's not
even counting the papers, reports, symposium papers, posters,
diagrams, cards, and presentations that aren't even checked
in |
| 04:59.27 |
brlcad |
gotta get
round-trip web editing with the docbook backend working so we can
make it all searchable, organized, and accessible |
| 05:01.48 |
brlcad |
thinks erik should make adrt compile
strict |
| 05:02.09 |
``Erik |
heh,
tried |
| 05:02.12 |
``Erik |
varargs
macros |
| 05:02.20 |
``Erik |
the tie0 vs
tie1 hack |
| 05:04.30 |
``Erik |
outside of
that, it's actually fiarly close |
| 05:05.15 |
``Erik |
<-- sets
-W -Wall -Werror -ansi -pedantic on his personal projects up front,
has a lint line he typically uses as well, creeped into a couple
bits of BRL-CAD |
| 05:05.58 |
``Erik |
adrt, even
:D |
| 05:07.07 |
brlcad |
found out
that -ansi and -std=c99 actually conflict in some instances, that
can't really quell both without testing compliance
version |
| 05:07.22 |
starseeker |
oh, that's
fun |
| 05:09.25 |
``Erik |
src/adrt/Makefile.am line 119.. learn the
hurt. |
| 05:12.48 |
``Erik |
looks like I
got that certain hair up my ass in november of 2000 |
| 05:13.17 |
``Erik |
(what were
YOU doing in nov 07, 2000?) |
| 05:16.36 |
brlcad |
I could
probably figure that out |
| 05:17.29 |
``Erik |
it's trivial,
but carried |
| 05:18.38 |
``Erik |
part of my
religion over 9 yrs ago :( |
| 05:19.23 |
``Erik |
based off of
annotate... iirc, it was called clint before splint |
| 05:22.28 |
brlcad |
lint used to
give so many false positives |
| 05:22.41 |
brlcad |
gcc at least
performs most of the lintisms (and then some) now |
| 05:22.45 |
``Erik |
used to? it
doesn't anymore? |
| 05:22.49 |
brlcad |
heh |
| 05:23.07 |
brlcad |
i'm looking
forward to seeing our coverity report |
| 05:23.32 |
``Erik |
be
interesting.. I used lint heavily and expected many false hits...
but did it anyways |
| 05:23.44 |
brlcad |
especially
now that several core dirs are "clean" .. should make the reports
be minimized to actual bugs and not just quellage making things
explicit |
| 05:23.44 |
``Erik |
don't think I
ever made a single project fully lint clean |
| 05:24.06 |
``Erik |
but it opened
my eyes to a lot of possibilities |
| 05:24.12 |
``Erik |
made me think
before saying aye or nay |
| 05:24.15 |
brlcad |
I almost made
hello world clean once |
| 05:24.32 |
brlcad |
hits the road |
| 05:24.48 |
``Erik |
the value is
in making you think, imho |
| 11:46.18 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 15:43.52 |
``Erik |
oohhhh,
todays cyanide and happiness is harsh http://www.explosm.net//comics |
| 15:52.23 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149E8D.dip.t-dialin.net) |
| 16:37.38 |
*** join/#brlcad docelic
(n=docelic@78-2-64-60.adsl.net.t-com.hr) [NETSPLIT
VICTIM] |
| 18:23.08 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 18:34.42 |
*** join/#brlcad R0b0t1
(n=Enigma@64-136-216-213.dyn.everestkc.net) |
| 18:57.26 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 18:57.38 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 19:22.43 |
*** join/#brlcad superlinux
(n=oracle@94.187.67.217) |
| 19:22.56 |
superlinux |
hello
guys |
| 19:25.37 |
superlinux |
starseeker, i
started reading the sketch script. the code is not really well
commented. and the lines of code count is over the 2200 lines. so
it's huge! |
| 19:44.56 |
*** join/#brlcad Ralith_
(n=ralith@69.90.48.97) |
| 20:59.43 |
*** join/#brlcad docelic_
(n=docelic@78-2-122-189.adsl.net.t-com.hr) |
| 23:08.50 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 23:57.11 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 23:57.22 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 00:01.12 |
CIA-41 |
BRL-CAD:
03starseeker * r36906 10/brlcad/trunk/src/libfb/ (6 files): Get rid
of forward declarations |
| 00:01.55 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 00:01.55 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 00:01.55 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 00:01.55 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 00:01.55 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 00:01.55 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 00:01.59 |
starseeker |
``Erik: any
idea why the X and X24 framebuffers are both present? |
| 00:02.38 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 00:07.22 |
starseeker |
from what I
can see, if_X24 supercedes if_X |
| 00:31.38 |
``Erik |
has no idea |
| 00:33.03 |
Nohla |
hola
:) |
| 00:40.18 |
starseeker |
hola
:-) |
| 00:40.46 |
starseeker |
Nohla: ready
to build spanish documentation with make? |
| 00:49.02 |
Nohla |
just if your
patient is ready too :) |
| 00:49.13 |
starseeker |
Nohla: it's
easy |
| 00:49.22 |
starseeker |
you have your
svn checkout of brlcad? |
| 00:49.29 |
Nohla |
yes |
| 00:49.39 |
starseeker |
ok. cd into
the top level |
| 00:49.45 |
CIA-41 |
BRL-CAD:
03starseeker * r36907 10/brlcad/trunk/doc/docbook/ (8 files in 5
dirs): First man3 man page in docbook - add man3 to the system
directory and make a new rule to generate .3 man pages. |
| 00:49.52 |
starseeker |
Nohla: then
run svn update |
| 00:50.37 |
Nohla |
wow!
easy... |
| 00:50.54 |
starseeker |
Nohla: are
you seeing things downloading? |
| 00:51.18 |
Nohla |
starseeker
no, I wanted to say: slower :) |
| 00:51.39 |
starseeker |
Nohla: you
are in your brlcad directory? |
| 00:51.43 |
Nohla |
<PROTECTED> |
| 00:51.55 |
starseeker |
Nohla: that's
a commit message |
| 00:52.01 |
starseeker |
Nohla: not an
instruction |
| 00:52.14 |
Nohla |
I
know |
| 00:52.18 |
starseeker |
If you see a
message from CIA-41, it is announcing a change to the source
code |
| 00:52.24 |
Nohla |
just I didn't
undarstand |
| 00:52.38 |
starseeker |
Nohla: type
"svn update" in your brlcad directory |
| 00:53.29 |
Nohla |
wait, I
shouldn't do that |
| 00:53.37 |
starseeker |
why? |
| 00:53.59 |
Nohla |
look, the
other day, by error, I changed the second tutorial but in /en
dir |
| 00:54.19 |
Nohla |
The begining
is in spanish there too |
| 00:54.37 |
starseeker |
Nohla: oh.
OK. just in case, copy those files to your home
directory |
| 00:56.31 |
Nohla |
starseeker
can you explain me what I did with svn update? |
| 00:56.41 |
Nohla |
just to be
shure :P |
| 00:56.54 |
starseeker |
you will be
updating your source code tree to include the latest
changes |
| 00:57.15 |
starseeker |
I have
altered the build system to allow for building Spanish
documentation - you need those changes |
| 00:58.49 |
starseeker |
Nohla: have
you copied important files to your home directory? |
| 00:59.46 |
Nohla |
starseeker
could you wait for me about 10 minutes? |
| 00:59.50 |
starseeker |
sure |
| 00:59.59 |
Nohla |
thanks
:) |
| 01:03.30 |
``Erik |
svn update
shouldn't stomp local changes, svn revert is how you do
that |
| 01:41.49 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 01:41.49 |
*** join/#brlcad b0ef
(n=b0ef@157.26.202.84.customer.cdi.no) |
| 01:41.49 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 01:41.49 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 01:41.49 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
| 01:41.49 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 01:41.49 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 01:41.49 |
*** join/#brlcad starseeker
(n=starseek@BZ.BZFLAG.BZ) |
| 01:41.49 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 01:41.49 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 01:41.50 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 01:41.50 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 01:41.50 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.183) |
| 01:41.50 |
*** join/#brlcad d-lo
(n=claymore@BZ.BZFLAG.BZ) |
| 01:41.50 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 01:41.50 |
*** join/#brlcad archivist
(n=archivis@81.149.119.172) |
| 01:41.50 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
| 01:41.50 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 01:41.50 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 01:41.50 |
*** join/#brlcad juantelez
(n=juantele@unaffiliated/juantelez) |
| 01:41.50 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 02:01.19 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:01.20 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 02:01.20 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 02:02.10 |
starseeker |
./autogen.sh |
| 02:02.10 |
starseeker |
./configure
--with-lang=ess |
| 02:02.10 |
starseeker |
cd
doc/docbook |
| 02:02.11 |
starseeker |
make |
| 02:02.11 |
starseeker |
sorry -
that's ./configure --with-lang=es |
| 02:02.11 |
starseeker |
(one
s) |
| 02:02.11 |
Nohla |
and
then |
| 02:02.21 |
starseeker |
Nohla: once
that works, look at the file doc/docbook/lessons/es/Makefile.am and
see where the xml file is listed |
| 02:02.41 |
starseeker |
you will have
built lesson1 as html and pdf |
| 02:02.51 |
starseeker |
the next step
is to add your new file |
| 02:03.09 |
starseeker |
for an
example look at doc/docbook/lessons/en/Makefile.am |
| 02:15.48 |
*** join/#brlcad CIA-38
(n=CIA@208.69.182.149) |
| 02:15.48 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:15.48 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 02:15.48 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 02:16.34 |
Nohla |
:) in the
hipoteticall case it exists |
| 02:16.34 |
starseeker |
Nohla: right
:-) |
| 02:16.34 |
Nohla |
starseeker
thanks again |
| 02:16.34 |
starseeker |
Nohla: once
you are comfortable with this method, it will be MUCH easier than
running conversions manually |
| 02:16.34 |
starseeker |
de nada
:-) |
| 02:16.34 |
starseeker |
thank
you! |
| 02:16.34 |
Nohla |
what means
"running conversions manually"? |
| 02:16.34 |
Nohla |
the
expression |
| 02:16.34 |
starseeker |
Nohla: the
long commands for creating html |
| 02:16.34 |
starseeker |
and
pdf |
| 02:17.23 |
starseeker |
the way you
made html and pdf the first time :-) |
| 02:17.23 |
Nohla |
XML_CATALOG_FILES= blablabla ? |
| 02:17.34 |
starseeker |
yes |
| 02:17.59 |
Nohla |
well, It was
a more graphical way :) |
| 02:38.39 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 02:38.39 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 02:38.39 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 02:38.39 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 02:38.39 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 02:38.39 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 02:38.40 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 02:38.40 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 02:38.40 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 02:38.40 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 02:38.40 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:38.41 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 02:38.41 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 02:54.24 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:54.24 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 02:54.24 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 02:54.24 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 02:54.37 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 02:54.37 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 02:54.37 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 02:54.37 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 02:54.37 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 02:54.37 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 02:54.37 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 02:54.37 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 02:59.34 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 03:03.23 |
*** join/#brlcad ``Erik_
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 03:03.23 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 03:04.21 |
*** join/#brlcad Ralith_
(n=ralith@69.90.48.97) |
| 03:04.21 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 03:04.21 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 03:04.21 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 03:04.21 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 03:04.38 |
*** join/#brlcad Computer (n=Computer@209.16.114.100)
[NETSPLIT VICTIM] |
| 03:04.40 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 03:04.40 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 03:04.40 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 03:04.40 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 03:04.40 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 03:04.45 |
*** join/#brlcad juantelez
(n=juantele@190.55.93.20) |
| 03:06.55 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 03:22.01 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 03:22.01 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 03:22.01 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 03:22.01 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 03:22.55 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.183) |
| 03:23.21 |
*** join/#brlcad juantelez
(n=juantele@unaffiliated/juantelez) |
| 03:26.28 |
*** join/#brlcad d-lo
(n=claymore@BZ.BZFLAG.BZ) |
| 04:02.56 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad Ralith_ (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 04:02.56 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 04:02.56 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 04:02.56 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 04:03.39 |
Nohla |
The BRL-CAD
build system is now prepared. To build here, run: |
| 04:03.39 |
Nohla |
<PROTECTED> |
| 04:03.39 |
Nohla |
<PROTECTED> |
| 04:03.39 |
brlcad |
that's a yes
:) .. though the Makefile.am error is probably a mistake in
something starseeker did recently |
| 04:27.17 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 04:27.17 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 04:27.17 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 04:27.17 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 04:27.17 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 04:27.17 |
*** join/#brlcad Ralith_ (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 04:27.17 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 04:27.17 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 04:27.18 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 04:27.18 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 04:27.18 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 04:27.18 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 04:27.19 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 04:27.19 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 04:28.19 |
starseeker |
license even
works |
| 04:28.19 |
brlcad |
actually,
they sound like a tiny dependency -- if it gives full fb services,
just as good as tk if not better |
| 04:28.19 |
brlcad |
if their code
and interface is actually clean and useful, could be a good
leverage, just depends |
| 04:28.19 |
starseeker |
nods |
| 04:28.19 |
starseeker |
hey
``Errrriikkk, more C++ code... :-P |
| 04:28.19 |
brlcad |
"sounds good"
.. but it's easy to write something that sounds good |
| 04:28.19 |
starseeker |
nods |
| 04:28.19 |
Nohla |
uff tell that
to pastebin :) |
| 04:28.19 |
brlcad |
could try
writing an fb interface with that behind it |
| 04:28.19 |
starseeker |
apparently
they're using it for some commercial screen capture
app... |
| 04:28.19 |
brlcad |
oooooh, Nohla
is it saying it's too much? |
| 04:28.19 |
brlcad |
config.log is
super-long |
| 04:28.28 |
brlcad |
ftp it to
brlcad.org/pub/incoming |
| 04:29.14 |
Nohla |
brlcad
? |
| 04:29.37 |
Nohla |
sorry if I
was unpolite, that was not the intention |
| 04:30.05 |
starseeker |
Nohla: you're
fine - he is suggesting to use an ftp client to send the file to
ftp://brlcad.org/pub/incoming |
| 04:30.05 |
Nohla |
everithing is
working ban with my notebook tonight |
| 04:30.20 |
Nohla |
s/ban/bad |
| 04:30.32 |
starseeker |
brlcad: Ah,
ScreenJot: http://www.liquidthought.com/ |
| 04:30.45 |
brlcad |
er, just
/incoming, not /pub/incoming |
| 04:31.11 |
brlcad |
ftp://brlcad.org/incoming |
| 04:31.28 |
starseeker |
don't think
they explicitly say they use pxcore, but this context suggests it:
http://www.liquidthought.com/blog/2009/07/pxcore-13-released.html |
| 04:31.43 |
brlcad |
yeah, I saw
that |
| 04:32.43 |
starseeker |
will poke at it once he gets a better feel for libfb as it
currently exists |
| 04:33.13 |
brlcad |
tk would
still probably be easier given the code is 80% done already
;) |
| 04:33.25 |
starseeker |
nods - yes, that's the plan |
| 04:33.50 |
starseeker |
(once I can
get it to do something without having mged crash on initialization
when I enable it...) |
| 04:34.17 |
brlcad |
assuming it's
not just because I left mged in a busted state dm-wise |
| 04:34.33 |
starseeker |
pxcore might
give performance beyond Tk, if it matters, but performance is
secondary to "Work without X on OSX" atm ;-) |
| 04:34.55 |
starseeker |
brlcad: I
don't think so - at least, when I disable the tk framebuffer things
seem OK |
| 04:35.12 |
brlcad |
ah, with the
tk dm, sure |
| 04:35.16 |
brlcad |
I mean the X
dm |
| 04:35.20 |
starseeker |
oh
:-) |
| 04:36.07 |
brlcad |
working on
that tonight/tomorrow |
| 04:36.46 |
Nohla |
brlcad sorry,
log is too long |
| 04:36.55 |
Nohla |
do you need
it yet? |
| 04:37.06 |
brlcad |
of course
:) |
| 04:37.15 |
brlcad |
Nohla: it's
not too long for ftp |
| 04:38.29 |
brlcad |
mozilla/firefox creates read-only
connections by default -- use command-line: ftp
brlcad.org |
| 04:38.32 |
brlcad |
cd
incoming |
| 04:38.35 |
brlcad |
put
config.log |
| 04:38.44 |
brlcad |
quit |
| 04:38.44 |
brlcad |
:) |
| 04:41.25 |
Nohla |
first it say
only anonymous ftp are allowed, but after that ask me to login with
user and pass |
| 04:42.08 |
brlcad |
never used
ftp before I see..just put anything in for password, user is
anonymous |
| 04:42.31 |
brlcad |
even nothing
for password |
| 04:43.28 |
Nohla |
aaaah It's
kidding me :) |
| 04:56.05 |
*** join/#brlcad talcite
(n=matthew@76-10-167-150.dsl.teksavvy.com) |
| 04:56.05 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 04:56.05 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 04:56.05 |
*** join/#brlcad juantelez (n=juantele@unaffiliated/juantelez)
[NETSPLIT VICTIM] |
| 04:56.05 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad Ralith_ (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 04:56.06 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 04:56.06 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 04:56.47 |
Nohla |
just wait for
me a moment |
| 04:56.47 |
brlcad |
waits patiently |
| 04:56.47 |
juantelez |
jaja |
| 04:56.47 |
Nohla |
juantelez sos
un idiota |
| 04:56.47 |
brlcad |
jeje |
| 05:07.01 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 05:09.39 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 05:09.39 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 05:15.40 |
Nohla |
brlcad can
you see it? |
| 05:20.29 |
Nohla |
starseeker
brlcad are you there? |
| 05:22.44 |
starseeker |
here |
| 05:22.51 |
starseeker |
I see
it |
| 05:24.50 |
starseeker |
hmm -
odd |
| 05:25.10 |
starseeker |
what's the
last message you got from configure on the terminal before it
exited? |
| 05:26.47 |
Nohla |
starseeker
I've sent it by email too |
| 05:30.53 |
brlcad |
Nohla: yep!
you got it |
| 05:30.58 |
brlcad |
what was the
problem? |
| 05:31.22 |
Nohla |
brlcad where,
by ftp? |
| 05:31.42 |
Nohla |
#
/incoming/config.log?? |
| 05:32.16 |
brlcad |
by
ftp |
| 05:32.26 |
starseeker |
apparently
there is no Makefile in doc/docbook |
| 05:32.42 |
brlcad |
Nohla: what
changed that it finally worked? |
| 05:32.45 |
brlcad |
(ftp) |
| 05:32.52 |
starseeker |
hrm... |
| 05:33.59 |
Nohla |
brlcad
me? |
| 05:34.15 |
brlcad |
Nohla: yes,
you :) |
| 05:34.51 |
brlcad |
Nohla: cuando
hiciste el ftp las primera veces, no funciono' .. que
cambio? |
| 05:35.13 |
Nohla |
instale
gftp |
| 05:35.31 |
Nohla |
y me quit? el
enojo :P |
| 05:35.35 |
brlcad |
heh,
okay |
| 05:45.51 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 05:45.51 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 05:47.20 |
brlcad |
ahh,
interesting.. her configure failure is due to the recent change
trying to get aquatk working better |
| 05:47.35 |
brlcad |
no longer
just 'yes', it did the test for X11 and AquaTk.. and came up with
nothing for her so instead of a compile-time failure, it fell
through into the "use system tk" case and failed |
| 05:47.45 |
brlcad |
ahh, system
tk case needs more logic now (in case it's a non-x11/non-tk
build) |
| 05:48.52 |
Nohla |
brlcad are
you talking with me? |
| 05:50.14 |
Nohla |
I'm fixing my
friendship with juantelez yet :P |
| 06:05.08 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 06:05.08 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad Nohla (n=jesica@168.226.178.183) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 06:05.08 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 06:05.08 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 06:05.08 |
*** join/#brlcad Ralith_ (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 06:05.08 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 06:05.08 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 06:05.08 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 06:07.58 |
CIA-38 |
BRL-CAD:
03brlcad * r36909 10/brlcad/trunk/doc/docbook/system/README:
document what the various manual page sections actually
mean |
| 06:08.09 |
brlcad |
Nohla: no,
just commenting about your configure failure |
| 06:09.17 |
Nohla |
brlcad did
you find the problem? |
| 06:10.07 |
brlcad |
yeah, the
problem is you're missing some pieces that are expected in order to
compile |
| 06:10.25 |
brlcad |
developer
header files |
| 06:11.17 |
Nohla |
... |
| 06:11.41 |
brlcad |
basically,
what starseeker mentioned you should install -- xorg-dev, bison,
and flex for starters |
| 06:11.47 |
Nohla |
too late to
tray to guess |
| 06:12.09 |
Nohla |
I've done
when he said that |
| 06:12.27 |
brlcad |
then you
should be able to run ./configure again |
| 06:12.32 |
brlcad |
see if it
succeeds |
| 06:12.48 |
brlcad |
rm
*cache* |
| 06:12.58 |
brlcad |
(before
configure) |
| 06:13.14 |
Nohla |
<PROTECTED> |
| 06:13.30 |
brlcad |
that removes
a temporary cache file that configure generates |
| 06:14.20 |
brlcad |
it uses the
cache file instead of retrying a test when it can |
| 06:15.07 |
brlcad |
since you
installed new things, it's a good idea to delete the cache file and
run configure cleanly |
| 06:16.02 |
brlcad |
alternative
is to just run sh autogen.sh again (and it will delete the cache
too) |
| 06:19.13 |
Nohla |
working as
you expected |
| 06:23.17 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 06:31.26 |
Nohla |
brlcad: wow,
and working a lot |
| 06:33.05 |
Nohla |
well, leave
it working, good night or whatever :) |
| 06:44.43 |
brlcad |
hasta
luego! |
| 06:49.33 |
Nohla |
brlcad I'll
let you working too |
| 06:49.34 |
Nohla |
make[2]: ***
[fbserv] Error 1 |
| 06:49.35 |
Nohla |
make[2]: se
sale del directorio
`/home/jesica/Desktop/brlcad/src/fbserv' |
| 06:49.35 |
Nohla |
make[1]: ***
[all-recursive] Error 1 |
| 06:49.35 |
Nohla |
make[1]: se
sale del directorio `/home/jesica/Desktop/brlcad/src' |
| 06:49.35 |
Nohla |
make: ***
[all-recursive] Error 1 |
| 06:50.26 |
Nohla |
before: |
| 06:50.26 |
Nohla |
make[3]: se
sale del directorio
`/home/jesica/Desktop/brlcad/src/conv' |
| 06:50.27 |
Nohla |
make[2]: se
sale del directorio
`/home/jesica/Desktop/brlcad/src/conv' |
| 06:50.27 |
Nohla |
Making all in
fbserv |
| 06:53.16 |
brlcad |
need what
preceeded that |
| 06:53.25 |
brlcad |
before the
Error 1 |
| 06:53.57 |
Nohla |
you won't let
me sleep, no? :) |
| 06:54.21 |
brlcad |
heh,
:) |
| 06:54.40 |
brlcad |
you can
sleep, we can continue later today/tomorrow/whenever :) |
| 06:55.37 |
Nohla |
deps/walk_example.Tpo -c -o walk_example.o
walk_example.c |
| 06:55.37 |
Nohla |
mv -f
.deps/walk_example.Tpo .deps/walk_example.Po |
| 06:55.37 |
Nohla |
/bin/sh
../../libtool --silent --tag=CC --silent --mode=link gcc -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -L/usr/local/lib
-pipe -fno-strict-aliasing -fno-common -fexceptions -g -o
walk_example walk_example.o ../../src/librt/librt.la |
| 06:55.37 |
Nohla |
make[3]: se
sale del directorio
`/home/jesica/Desktop/brlcad/src/conv' |
| 06:55.37 |
Nohla |
make[2]: se
sale del directorio
`/home/jesica/Desktop/brlcad/src/conv' |
| 06:55.39 |
Nohla |
Making all in
fbserv |
| 06:55.41 |
Nohla |
make[2]: se
ingresa al directorio
`/home/jesica/Desktop/brlcad/src/fbserv' |
| 06:55.43 |
Nohla |
gcc
-DHAVE_CONFIG_H -I. -I../../include -I../../src/other/tcl/generic
-I../../src/other/tcl/unix -I/usr/local/include -DBRLCADBUILD=1
-I../../include -I../../src/other/openNURBS -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -MT fbserv.o -MD
-MP -MF .deps/fbserv.Tpo -c -o fbserv.o fbserv.c |
| 06:55.47 |
Nohla |
mv -f
.deps/fbserv.Tpo .deps/fbserv.Po |
| 06:55.49 |
Nohla |
gcc
-DHAVE_CONFIG_H -I. -I../../include -I../../src/other/tcl/generic
-I../../src/other/tcl/unix -I/usr/local/include -DBRLCADBUILD=1
-I../../include -I../../src/other/openNURBS -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -MT server.o -MD
-MP -MF .deps/server.Tpo -c -o server.o server.c |
| 06:55.53 |
Nohla |
mv -f
.deps/server.Tpo .deps/server.Po |
| 06:55.55 |
Nohla |
/bin/sh
../../libtool --silent --tag=CC --silent --mode=link gcc -pipe
-fno-strict-aliasing -fno-common -fexceptions -g -L/usr/local/lib
-pipe -fno-strict-aliasing -fno-common -fexceptions -g -o fbserv
fbserv.o server.o ../../src/libfb/libfb.la |
| 06:55.59 |
Nohla |
../../src/libfb/.libs/libfb.so: undefined
reference to `yIMG2SCR' |
| 06:56.03 |
Nohla |
../../src/libfb/.libs/libfb.so: undefined
reference to `xIMG2SCR' |
| 06:56.05 |
Nohla |
collect2: ld
returned 1 exit status |
| 06:56.07 |
Nohla |
make[2]: ***
[fbserv] Error 1 |
| 06:56.09 |
Nohla |
make[2]: se
sale del directorio
`/home/jesica/Desktop/brlcad/src/fbserv' |
| 06:56.11 |
Nohla |
make[1]: ***
[all-recursive] Error 1 |
| 06:56.13 |
Nohla |
make[1]: se
sale del directorio `/home/jesica/Desktop/brlcad/src' |
| 06:56.15 |
Nohla |
make: ***
[all-recursive] Error 1 |
| 06:56.17 |
Nohla |
if it isn't
enought, se continue another day |
| 06:56.21 |
brlcad |
huh, that
looks like starseeker's doing :) |
| 06:56.23 |
Nohla |
s/se/we |
| 06:56.41 |
Nohla |
wake him up
:) |
| 06:56.49 |
brlcad |
he apparently
broke the compile earlier today :) |
| 06:57.05 |
brlcad |
that is
enough |
| 06:57.35 |
Nohla |
well, good
morning :( |
| 06:57.44 |
Nohla |
s/:(/:) |
| 06:57.53 |
Nohla |
o sea:
:) |
| 06:58.10 |
brlcad |
that fixes
it |
| 06:58.15 |
Nohla |
gracias de
nuevo, contribu?s a mi buen humor |
| 06:58.18 |
CIA-38 |
BRL-CAD:
03brlcad * r36910 10/brlcad/trunk/src/libfb/if_X.c: the defines
must come before the usages or there will be undefined references
in the resultant library. |
| 06:58.20 |
brlcad |
:) |
| 06:58.28 |
brlcad |
svn up
src/libfb |
| 06:58.33 |
brlcad |
make |
| 06:59.56 |
brlcad |
Nohla:
gracias por vos paciencia ;) |
| 07:00.25 |
Nohla |
mmm, me falt?
la paciencia por un momento hoy, por eso precis? mas de la de
ustedes :) |
| 07:02.39 |
brlcad |
si no
entendiste, el CIA-38 "commit" alli se arreglo' el compile, ya va
continuar mas |
| 07:03.25 |
brlcad |
has tenido
mucha paciencia |
| 07:03.34 |
brlcad |
goes both
ways, thanks |
| 07:12.21 |
CIA-38 |
BRL-CAD:
03brlcad * r36911 10/brlcad/trunk/configure.ac: |
| 07:12.21 |
CIA-38 |
BRL-CAD:
refactor the Tk compilation testing to allow Tk to auto-disable if
there isn't a |
| 07:12.21 |
CIA-38 |
BRL-CAD:
suitable X11/AquaTk or other subsystem available to build tk
ourselves and there |
| 07:12.21 |
CIA-38 |
BRL-CAD:
isn't a suitable system library that seems to work right. this
should let Tk be |
| 07:12.21 |
CIA-38 |
BRL-CAD:
optional at least during configure time (compile may still have
some |
| 07:12.22 |
CIA-38 |
BRL-CAD:
assumptions) and will make it blather a strong message with delay
if MGED's Tk |
| 07:12.24 |
CIA-38 |
BRL-CAD: GUI
is getting turned off. |
| 07:17.04 |
*** join/#brlcad jesica__
(n=jesica@168.226.179.224) |
| 10:50.19 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 12:26.39 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 12:42.44 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 12:42.44 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 12:42.44 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 12:42.44 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 12:42.44 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 12:42.44 |
*** join/#brlcad Ralith_ (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 12:42.44 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 12:42.44 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 12:42.45 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 12:42.45 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 12:42.45 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 12:42.45 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 12:42.45 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 12:57.22 |
starseeker |
brlcad:
ooops, sorry about that |
| 12:59.49 |
starseeker |
musta had some stale files hanging around |
| 13:04.28 |
starseeker |
really, all
Nohla needed for translation was to build
doc/docbook... |
| 13:04.28 |
starseeker |
ah well, good
experience |
| 13:04.51 |
louipc |
docbook
toolchain not playing nice? |
| 13:05.06 |
starseeker |
louipc:
actually that's behaving reasonably well |
| 13:05.34 |
starseeker |
our Spanish
translater is being tutored in setting up a svn BRL-CAD
build |
| 13:06.21 |
starseeker |
lot to take
in from a cold standing start, and some stuff I've been doing
elsewhere didn't build out of box on her setup (my
fault) |
| 13:06.30 |
louipc |
cool |
| 13:07.09 |
starseeker |
the minimum
for what she is doing is to be able to run make in doc/docbook, but
of course it's better for her to have the full setup |
| 13:07.21 |
louipc |
I need to get
dockbook sgml working properly on my system |
| 13:07.23 |
starseeker |
particularly
if any screenshots need to be localized |
| 13:07.38 |
starseeker |
actually
we're using xml, not sgml :-) |
| 13:07.55 |
louipc |
I know, but
there's some other projects that use sgml |
| 13:08.02 |
starseeker |
ah,
true |
| 13:08.51 |
starseeker |
'nother few
years, I'm hoping a solid Docbook toolchain will be standard on
most Linux distros, but it doesn't quite seem to be there
yet |
| 13:09.13 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 13:09.13 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 13:09.13 |
louipc |
yeah |
| 13:09.20 |
louipc |
it seems too
fragmented |
| 13:24.52 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 13:24.53 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
| 13:24.53 |
*** join/#brlcad archivist
(n=archivis@81.149.119.172) |
| 13:24.53 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** join/#brlcad Ralith_ (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 13:24.53 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 13:24.53 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 14:05.26 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 14:29.12 |
starseeker |
hmm:
http://blog.ostp.gov/2009/12/09/ostp-to-launch-public-forum-on-how-best-to-make-federally-funded-research-available-for-free/ |
| 14:44.52 |
*** join/#brlcad talcite
(n=matthew@76-10-167-150.dsl.teksavvy.com) |
| 14:52.42 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 14:55.15 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 14:59.52 |
*** join/#brlcad talcite
(n=matthew@76-10-167-150.dsl.teksavvy.com) [NETSPLIT
VICTIM] |
| 15:46.25 |
CIA-38 |
BRL-CAD:
03johnranderson * r36912
10/brlcad/trunk/src/librtserver/rtserver.c: Added region id and air
code to the output buffer |
| 15:53.24 |
brlcad |
http://johnmacphail.com/2009/12/send-in-the-autocad-clone/ |
| 15:56.31 |
starseeker |
brlcad: heh,
cool |
| 15:56.48 |
starseeker |
not sure I'd
agree "very little" has happened with BRL-CAD though
;-) |
| 16:00.29 |
brlcad |
quite
true |
| 16:00.49 |
brlcad |
I don't think
he means to brl-cad directly, more the commmunity adopting
it |
| 16:01.34 |
louipc |
depends on
your perspective too |
| 16:01.59 |
louipc |
there's tons
of development, but little that would seem to attract most CAD
users |
| 16:03.08 |
brlcad |
right |
| 16:03.18 |
louipc |
or what has
been developed isn't pushed to the forefront |
| 16:03.20 |
brlcad |
and that's
what I'd call the "expectation chasm" |
| 16:03.27 |
louipc |
g3d,
archer |
| 16:04.13 |
brlcad |
there's a
disjoint understanding between wanting a particular feature and
realizing what has to happen within the system to make that happen,
the level of effort and fundamental capabilities that are
required |
| 16:05.15 |
brlcad |
and not just
on the order of "oh that should take a few months" and being wrong
a few months .. it's features that generally take several years of
effort, taken for granted because of the magnitude of effort that
goes into the big commercial systems |
| 16:06.45 |
brlcad |
not to
mention not having a solid understanding (pun intended) on the
differences between drafting features, boundary representations,
CADD vs CAD, solid modeling, explicit vs implicit representations,
etc |
| 16:07.13 |
brlcad |
they just
want a button that generates their hidden line annotated drafting
diagrams in pdf format |
| 16:07.54 |
brlcad |
with input
coming from a myrid of formats and modeling approaches with various
representation types |
| 16:16.03 |
starseeker |
which
hopefully will be what FreeCAD will be good for until we get
there |
| 16:18.52 |
brlcad |
nah, I still
think we'll get there first |
| 16:19.06 |
brlcad |
it's not just
raw output of a diagram, it's the whole workflow |
| 16:19.22 |
brlcad |
it has to be
a system that will read their format (whatever it is)
faithfully |
| 16:19.37 |
brlcad |
it has to
represent it fully, process it and repair their mistakes
automatically |
| 16:20.15 |
brlcad |
it has to
often anticipate what the modeler wants through conventions made
pervasive by other systems |
| 16:20.50 |
brlcad |
it has to be
even easier to use than what they already know because they don't
want to invest the time and effort to learn something
different |
| 16:21.01 |
brlcad |
at least
those are some of the expectations |
| 16:21.18 |
brlcad |
freecad is
way farther from most of that than we are |
| 16:24.01 |
starseeker |
nods |
| 16:24.54 |
starseeker |
bemusedly dreams of the day BRL-CAD will be easier to use
than other CAD systems ;-) |
| 16:25.41 |
starseeker |
although I
suppose the lack of a $5000+ cover fee counts for a lot of
usability |
| 16:26.29 |
louipc |
5k is the
upgrade fee |
| 16:27.15 |
louipc |
well...
that's for like a 3rd tier CAD/CAM system |
| 16:28.03 |
starseeker |
erm...
ow... |
| 17:00.09 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 17:04.12 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 17:09.40 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 17:09.40 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:09.41 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 17:24.28 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 17:24.28 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 17:24.30 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 17:55.19 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 17:55.19 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) |
| 17:55.19 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
| 17:55.19 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 17:55.19 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 17:55.19 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:55.19 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 17:55.19 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 17:55.19 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 17:55.19 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 17:55.20 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 17:55.20 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 17:55.20 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 17:55.20 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 17:55.20 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 17:55.20 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 17:55.20 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 17:55.20 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 17:55.20 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 17:57.04 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 17:57.04 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 17:57.04 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 18:38.16 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 18:38.16 |
*** join/#brlcad roberthl_
(n=robert@rhl.me.uk) |
| 18:38.16 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 18:38.17 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 18:38.17 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 19:02.02 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 19:02.02 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 19:02.02 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
| 19:02.02 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) |
| 19:02.02 |
*** join/#brlcad roberthl_ (n=robert@rhl.me.uk) [NETSPLIT
VICTIM] |
| 19:02.02 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
| 19:02.02 |
*** join/#brlcad archivist
(n=archivis@81.149.119.172) |
| 19:02.02 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 19:02.02 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 19:02.03 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 19:02.03 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 19:02.03 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 19:02.03 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 19:02.03 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 19:02.03 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 19:02.03 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 19:02.03 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 19:02.03 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 19:02.03 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 19:02.03 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 19:05.24 |
starseeker |
hrm - bwish
isn't installed?? |
| 19:05.52 |
starseeker |
oh |
| 19:22.24 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 19:22.24 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad roberthl_ (n=robert@rhl.me.uk) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 19:22.24 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 19:22.24 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 19:22.24 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 19:22.24 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 19:22.24 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 19:22.24 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 19:22.24 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 19:22.25 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 19:22.25 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 19:23.53 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 19:23.53 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 19:23.53 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 19:46.15 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 19:46.16 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 19:46.16 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 19:49.14 |
starseeker |
hmm, that's
worth noting - Tk 8.6 is using Cocoa, not carbon |
| 19:49.30 |
starseeker |
should make
for some entertaining testing... |
| 19:51.35 |
CIA-38 |
BRL-CAD:
03starseeker * r36916 10/brlcad/trunk/src/ (4 files in 4 dirs):
Switch some WITH_X11 toggles to WITH_TK toggles |
| 20:12.57 |
*** join/#brlcad Ralith
(n=ralith@d142-058-089-169.wireless.sfu.ca) |
| 20:16.52 |
*** join/#brlcad roberthl
(n=robert@rhl.me.uk) |
| 20:26.52 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) |
| 20:59.49 |
CIA-38 |
BRL-CAD:
03starseeker * r36917 10/brlcad/trunk/src/tclscripts/mouse.tcl: Ah
HAH - move windows out from under the top level toolbar on OSX when
place_near_mouse is being called. |
| 21:35.16 |
CIA-38 |
BRL-CAD:
03starseeker * r36918 10/brlcad/trunk/src/archer/archer: Make sure
Archer doesn't start up under the OSX menubar - need to figure out
best behavior on startup generally for window placement, but this
will keep Archer out of trouble on OSX for now. |
| 21:37.59 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 22:06.41 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
| 22:06.41 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Release 7.16.2 posted (20091106) .. full binary
release! |
| 22:16.05 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
| 22:16.21 |
*** join/#brlcad Ralith_
(n=ralith@69.90.48.97) |
| 22:29.28 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 22:48.57 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 22:48.57 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 22:48.57 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:03.59 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 23:04.45 |
*** join/#brlcad archivist (n=archivis@81.149.119.172)
[NETSPLIT VICTIM] |
| 23:04.45 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 23:05.25 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 23:18.36 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 23:18.36 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 23:18.36 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:19.50 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 23:19.50 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 23:19.50 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:22.06 |
*** join/#brlcad akafubu
(n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT
VICTIM] |
| 23:22.06 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 23:22.06 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:29.58 |
starseeker |
makes a note to figure out why png icons suck in
Aqua... |
| 23:47.41 |
``Erik |
icons in what
sense, and suck how? |
| 23:49.47 |
starseeker |
archer's icon
toolbar, and the transparency rendering is messed up |
| 23:49.55 |
starseeker |
http://bzflag.bz/~starseeker/archer_aquatk_aquatheme.png |
| 23:49.55 |
``Erik |
ah
*shrug* |
| 23:50.10 |
starseeker |
tries an experiment... if this works Bob will hate
me... |
| 23:55.17 |
``Erik |
tkimg?
heh |
| 23:58.11 |
starseeker |
not sure if
we want to do that... but worth a try to see if it fixes
something |
| 00:07.51 |
starseeker |
is agast at the full size of tkimg... |
| 00:10.08 |
starseeker |
aaaand,
that's moderately worse |
| 00:10.13 |
starseeker |
alrightie
then |
| 01:05.21 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.224) |
| 01:05.32 |
starseeker |
hey Nohla
:-) |
| 01:05.42 |
Nohla |
starseeker
hi |
| 01:06.25 |
Nohla |
I was working
with eyes closed today :P |
| 01:08.24 |
starseeker |
heh |
| 01:08.39 |
starseeker |
did your
build succeed? |
| 01:12.14 |
Nohla |
I think
so |
| 01:12.18 |
Nohla |
brlcad helped
me |
| 01:12.25 |
starseeker |
excellent |
| 01:12.35 |
starseeker |
you saw how
it built the spanish html and pdf? |
| 01:15.17 |
Nohla |
starseeker
are you always so active at this hour of the night? :) |
| 01:16.16 |
Nohla |
(I'm cooking
at the same time I aswer you) |
| 01:17.40 |
starseeker |
usually |
| 01:19.27 |
starseeker |
I will need
to leave for a while, so if you have questions now is the
time |
| 01:20.22 |
Nohla |
:) It's ok
for today |
| 01:20.30 |
Nohla |
I'm hungry
:) |
| 01:20.43 |
starseeker |
ok
:) |
| 01:20.45 |
Nohla |
but
thanks |
| 02:39.28 |
brlcad |
yawns |
| 02:44.17 |
Nohla |
brlcad
hi |
| 02:45.09 |
brlcad |
hola
Nohla |
| 02:48.36 |
Nohla |
recordando el
español de nuevo? :) |
| 03:14.33 |
brlcad |
solo regresa
con uso |
| 03:15.58 |
starseeker |
brlcad: I
wonder how Bob would react if I yank out the dll/so loader function
and do traditional package require in Archer :-) |
| 03:42.13 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 04:04.24 |
*** join/#brlcad talcite
(n=matthew@69-196-191-166.dsl.teksavvy.com) |
| 04:28.59 |
brlcad |
starseeker:
if it works, doesn't matter |
| 04:29.11 |
brlcad |
not sure
they're proper packages |
| 04:29.40 |
brlcad |
don't recall
there being a pkgIndex.tcl for tkimg, could be wrong |
| 04:38.02 |
brlcad |
yeah, don't
see one -- would have to probably create an init func and the index
file at a minimum; basic packaging |
| 04:55.31 |
*** join/#brlcad d-lo_
(n=claymore@BZ.BZFLAG.BZ) |
| 04:58.07 |
CIA-38 |
BRL-CAD:
03brlcad * r36919 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c
g_bot_include.c): quell a slew of verbose compilation warnings
about unused params. add sanity checks and unused declarations as
needed. |
| 04:59.19 |
CIA-38 |
BRL-CAD:
03brlcad * r36920 10/brlcad/trunk/src/librt/primitives/brep/
(brep.cpp brep_debug.cpp brep_debug.h): consolidate the three plot
debugging sections into just one. remove bunch of unused code,
unbust header, quell warnings. |
| 05:04.05 |
CIA-38 |
BRL-CAD:
03brlcad * r36921 10/brlcad/trunk/src/librt/primitives/bspline/
(nurb_bound.c nurb_knot.c nurb_util.c): quell verbose compilation
warnings, sanity check the resource pointer |
| 05:18.16 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 05:18.16 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad talcite
(n=matthew@69-196-191-166.dsl.teksavvy.com) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad Nohla (n=jesica@168.226.179.224) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 05:18.16 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 05:18.16 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 05:18.16 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 05:18.16 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 05:18.16 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 05:18.16 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 05:18.17 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 05:18.17 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 05:18.17 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 05:18.17 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 05:19.31 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 05:19.31 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 05:19.32 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 05:19.32 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 05:44.59 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad jesica__
(n=jesica@168.226.178.188) |
| 05:44.59 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad talcite
(n=matthew@69-196-191-166.dsl.teksavvy.com) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 05:44.59 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 05:44.59 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 05:44.59 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 05:44.59 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 05:44.59 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 05:45.00 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 05:45.00 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 05:45.00 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 05:45.00 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 05:47.12 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 05:47.12 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 06:05.18 |
*** join/#brlcad Don_
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad jesica__ (n=jesica@168.226.178.188) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net)
[NETSPLIT VICTIM] |
| 06:05.18 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 06:05.18 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 06:05.18 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 06:05.19 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 06:05.19 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 06:05.19 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 06:05.19 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 06:05.19 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 06:05.19 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 06:05.19 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 06:17.52 |
starseeker |
brlcad: not
sure how it would work on Windows |
| 06:18.20 |
starseeker |
or rather, if
our Windows build can do the subconfigure stuff
correctly |
| 06:19.27 |
starseeker |
tkhtml3 seems
to be the first real attempt to do a "proper" install of a package
require library to the in-tree tcl/tk - since that's not working on
Windows yet it's kinda unexplored turf |
| 06:36.56 |
*** join/#brlcad talcite
(n=matthew@69-196-191-166.dsl.teksavvy.com) |
| 06:45.53 |
talcite |
have any of
you guys gotten a chance to take a look at the fedora bugzilla?
I've run into snags with tkhtml3 and tkImg integration (one bundles
licenses, the other static libs) . Is there any chance that we can
get around it from this end? |
| 09:43.04 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 11:55.53 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 11:55.53 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 12:51.22 |
*** join/#brlcad mafm
(n=mafm@88.11.185.249) |
| 13:50.59 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 13:50.59 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 13:51.44 |
starseeker |
blinks - static libs in tkhtml3? |
| 13:51.55 |
starseeker |
is he talking
about how it builds itself? |
| 14:00.12 |
CIA-38 |
BRL-CAD:
03Pt6wub5boj19mxd 07http://brlcad.org * r2052
10/wiki/User:Pt6wub5boj19mxd: New page: Say good-by " she said. He
frowned slightly. "All right " he said. She made another speech.
"I'm not sorry we kissed " she said. "That was sweet. We should
have kissed. [http://cialis-... |
| 15:10.47 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 15:10.47 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 15:10.47 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad mafm (n=mafm@88.11.185.249) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 15:10.47 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 15:10.47 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 15:10.47 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 15:10.47 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 15:10.47 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 15:10.47 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 15:10.48 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 15:48.30 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 15:48.30 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 15:48.30 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 15:48.31 |
*** join/#brlcad mafm (n=mafm@88.11.185.249) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 15:48.31 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 15:48.31 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 15:48.31 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 15:48.31 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 15:48.31 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 15:48.31 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 15:55.13 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 15:57.00 |
CIA-38 |
BRL-CAD:
03brlcad * r36922
10/brlcad/trunk/src/librt/primitives/cline/cline.c: quell all
verbose extra compilation warnings, mostly about unused params. add
data validation on those params or mark as unused where
appropriate. |
| 15:58.44 |
CIA-38 |
BRL-CAD:
03brlcad * r36923 10/brlcad/trunk/src/librt/primitives/
(metaball/metaball.c superell/superell.c table.c): remove the
stubbed in tnurb functions, as they're all about to go away. these
can go away even sooner, though, given the unused parameter
warnings they cause. |
| 16:00.32 |
CIA-38 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: |
| 16:00.32 |
CIA-38 |
BRL-CAD:
deleted "[[User:Pt6wub5boj19mxd]]": content was: 'Say good-by " she
said. He |
| 16:00.32 |
CIA-38 |
BRL-CAD:
frowned slightly. "All right " he said. She made another speech.
"I'm not |
| 16:00.32 |
CIA-38 |
BRL-CAD:
sorry we kissed " she said. "That was sweet. ...' (and the only
contributor was |
| 16:00.32 |
CIA-38 |
BRL-CAD:
'[[Special:Contributions/Pt6wub5boj19mxd|Pt6wub5boj19mxd]]') |
| 16:00.44 |
CIA-38 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Pt6wub5boj19mxd]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
| 16:01.08 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 16:01.08 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 16:01.31 |
``Erik |
uhm |
| 16:05.55 |
``Erik |
odd |
| 16:20.27 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 16:20.27 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 16:20.27 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 16:20.27 |
*** join/#brlcad mafm
(n=mafm@249.Red-88-11-185.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
| 16:20.27 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 16:20.28 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 16:20.28 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 16:20.28 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 16:20.28 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 16:20.28 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 16:20.28 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 16:20.28 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 16:21.36 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 16:23.36 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 16:36.15 |
*** join/#brlcad talcite
(n=matthew@69-196-191-166.dsl.teksavvy.com) |
| 16:38.41 |
talcite |
huh. Got a
reply from Toshio at the fedora project. |
| 16:40.16 |
talcite |
Essentially I
need to fix both tkImg and tkHTML before we can get inclusion. So
either I rewrite them to use dynamic libs or we remove the
dependencies from brlcad |
| 16:43.53 |
starseeker |
removing them
is a problem |
| 16:44.05 |
starseeker |
what's the
trouble with tkhtml3? |
| 16:44.19 |
starseeker |
hadn't noticed we were building it
static... |
| 16:47.09 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 16:47.09 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 16:56.41 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 16:59.56 |
talcite |
starseeker:
oops. sorry, didn't see the message. Yes, tkhtml3 includes static
libs afaik |
| 17:00.10 |
talcite |
atleast,
their website claims to... |
| 17:01.12 |
starseeker |
talcite:
check src/other/tkhtml3 |
| 17:01.35 |
starseeker |
they have a
static binary of hv3... |
| 17:01.45 |
starseeker |
I didn't see
any separate build of tkhtml3 at all |
| 17:02.44 |
talcite |
hmm. I'll
need to look into it more. Maybe they just meant it doesn't have
external dependencies |
| 17:04.07 |
starseeker |
talcite: were
are you getting the tkhtml3 you intend to add to
fedora? |
| 17:04.16 |
talcite |
starseeker:
off the website |
| 17:04.23 |
talcite |
brlcad said
that there weren't any source changes to it |
| 17:04.48 |
starseeker |
ok, but
you're doing JUST tkhtml3 and not hv3 right? |
| 17:04.53 |
starseeker |
hv3 is more
than just tkhtml3 |
| 17:04.58 |
talcite |
so I was just
planning on using native sources instead of abstracting it out of
our program |
| 17:04.59 |
talcite |
yes |
| 17:05.17 |
starseeker |
ok... we
might have a few build system changes in our tree, I'm not
sure |
| 17:05.40 |
talcite |
we can do a
diff on them. shouldn't be too tough |
| 17:05.43 |
starseeker |
so when you
build tkhtml3, you're getting static results? |
| 17:06.26 |
starseeker |
'cause here I
get libTkhtml3.0.dylib (Mac) |
| 17:06.29 |
talcite |
starseeker:
no, the website says it's static. I haven't built and checked for
it yet |
| 17:06.56 |
starseeker |
talcite: ok,
build it and check :-) |
| 17:06.57 |
talcite |
starseeker: I
don't mean that tkhtml3 is static itself, it contains static libs
within it |
| 17:07.15 |
starseeker |
I don't know
that tkhtml3 contains any libs, just it's own code |
| 17:07.21 |
starseeker |
tkimg is a
different matter |
| 17:09.10 |
talcite |
hmm. Well the
website could be out of date or inaccurate. Maybe it was talking
about hv3 |
| 17:09.54 |
talcite |
I'm sure that
tkimg contains libs within it though. The release notes have a
detailed section about them |
| 17:11.03 |
starseeker |
yes |
| 17:11.04 |
talcite |
tkimg is the
crucial package isnt' it? |
| 17:11.04 |
starseeker |
I'd bet hv3
is what they're talking about on the website |
| 17:11.05 |
talcite |
I thought
tkhtml could be removed in the past |
| 17:12.32 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:15.04 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:18.39 |
starseeker |
talcite: it
can be, but you lose html display of man pages in MGED |
| 17:18.52 |
talcite |
I
see |
| 17:19.05 |
starseeker |
talcite: as
for tkimg, I'm working on switching us to tkpng |
| 17:19.30 |
talcite |
well tkhtml
looks like it doesn't have any static libs right now |
| 17:19.40 |
talcite |
I need to
inspect the makefile, but it looks pretty clean |
| 17:19.44 |
starseeker |
we only use a
tiny subset of tkimg, so we'll go the smaller, cleaner route (tk
8.6 should actually incorporate tkpng's abilities into the core, so
it will go away altogether) |
| 17:19.57 |
talcite |
ahh I
see |
| 17:20.24 |
starseeker |
if you look
at our src/other/tkimg it's actually a small subset of the full
tkimg |
| 17:21.57 |
talcite |
tkpng looks
pretty cool |
| 17:22.02 |
CIA-38 |
BRL-CAD:
03starseeker * r36924 10/brlcad/trunk/src/archer/archer: If we're
doing aqua rendering, go aqua rather than clam for the
theme. |
| 17:22.34 |
talcite |
starseeker:
any idea on when tkpng will be integrated? |
| 17:23.28 |
brlcad |
talcite:
tkhtml3 doesn't include any 3rd party libs nor does it have any
external dependencies except tcl and tk |
| 17:23.45 |
starseeker |
talcite:
should be before the January src release - I've got a test build
working but I need to get it to function with a local
libz |
| 17:23.48 |
brlcad |
not sure what
gave you that impression, the sources are pretty simple
.. |
| 17:23.58 |
talcite |
brlcad: I
see. crazy website =/ |
| 17:24.07 |
talcite |
yeah. I just
looked through the sources |
| 17:24.33 |
brlcad |
we didn't
make any source changes, but there were a few (minor) build system
tweaks for portability |
| 17:24.48 |
starseeker |
brlcad: they
talk up hv3 (their big mega-browser-thingy) and have big static
builds of that as the main download on the project website
(sucks) |
| 17:25.05 |
starseeker |
they really
need to split that sucker into multiple downloads |
| 17:25.14 |
brlcad |
and so it'd
integrate cleanly with the default automake build rules (e.g.,
fixing distcheck, distclean, etc) |
| 17:26.21 |
talcite |
starseeker:
alright. I'll hold off on rebuilding the package till after the
january release. tkhtml, Utah, and TNT should keep me busy in the
meanwhile |
| 17:27.30 |
brlcad |
what was the
issue with tkimg? |
| 17:28.25 |
brlcad |
our inclusion
of tkimg is pretty minimal with no bundled libs, don't recall if we
modified it to be that way or if it was originally that
way |
| 17:29.00 |
starseeker |
brlcad: he
would have to make an external tkimg rpm for Fedora |
| 17:29.29 |
starseeker |
that would
either involve doing tkimg "right" using the main repository, or
forking our little subset and making an rpm of IT (which I doubt
they would accept) |
| 17:29.59 |
brlcad |
he would have
to make an external tkpng rpm for Fedora too.. just want to make
sure it's not a wash :) |
| 17:30.14 |
brlcad |
is ours a
subset? |
| 17:30.30 |
starseeker |
That would be
easier - I gather tkimg stomps all over the Fedora guidelines for
included libs |
| 17:30.31 |
brlcad |
i vaguely
recall tkimg having separate libs for each format |
| 17:30.58 |
brlcad |
again, ours
has no included libs |
| 17:31.04 |
brlcad |
did we do
that or is that how it came? |
| 17:31.13 |
starseeker |
dunno |
| 17:31.30 |
starseeker |
all I can say
is when I checked out the tkimg repository it looked almost nothign
like ours |
| 17:31.33 |
brlcad |
or is it a
simple matter like our src/other in that they bundle and it's just
there for release control and download convenience for stand-alone
compiles |
| 17:32.08 |
brlcad |
having the
sources shouldn't be a problem, it's whether it uses them during
compile or not, and that can be controlled by the rpm |
| 17:32.32 |
brlcad |
it looks like
we gutted their build system |
| 17:33.03 |
starseeker |
nods - if they allow external libs during build it could work
- I just don't know if they do - when I ran the default configure
here it looked like it walked into all the lib directories (took a
while) |
| 17:34.04 |
brlcad |
yeah, I don't
think an rpm would be that hard at all, the deps shouldn't be a
problem |
| 17:34.34 |
brlcad |
tkpng could
be even simpler still, but I don't see tkimg as a problem if we
have to in the meantime |
| 17:35.32 |
starseeker |
talcite:
um... - is this of interest?
http://www.rpmfind.net/linux/RPM/fedora/devel/x86_64/tkimg-1.4-0.6.20091129svn.fc13.x86_64.html |
| 17:36.11 |
brlcad |
whether they
do or don't "allow" external libs is a really *trivial build matter
that wouldn't be hard to change, not an reason to discount it by
itself |
| 17:36.11 |
talcite |
starseeker: :
what the heck? That definitely wasn't there before.... |
| 17:36.19 |
brlcad |
haha |
| 17:36.21 |
talcite |
well 1129.. I
guess it saves some work =) |
| 17:37.10 |
starseeker |
first rule of
solving a problem in open source - make sure someone else hasn't
solved it already ;-P |
| 17:37.32 |
starseeker |
http://www.rpmfind.net/linux/rpm2html/search.php?query=tkimg |
| 17:37.32 |
brlcad |
http://rpmfind.net/linux/rpm2html/search.php?query=tkimg&submit=Search |
| 17:37.44 |
starseeker |
hehe |
| 17:37.44 |
brlcad |
looks like
since fed 9 |
| 17:37.47 |
talcite |
yeah. I
checked both in the existing packages and also in the packages
being developed |
| 17:38.06 |
talcite |
really?
that's strange. |
| 17:38.21 |
talcite |
... it's
there |
| 17:38.21 |
brlcad |
http://rpmfind.net/linux/rpm2html/search.php?query=tkhtml |
| 17:38.28 |
talcite |
arghhh |
| 17:38.44 |
brlcad |
ahh, that's
not tkhtml3 |
| 17:38.50 |
starseeker |
will still be switching to tkpng, but it DEFINITELY looks
like the rpm need not wait on that |
| 17:39.25 |
brlcad |
http://rpmfind.net/linux/rpm2html/search.php?query=tkhtml3
<-- heh, but that is |
| 17:39.28 |
starseeker |
Yeah, looks
like only Mandriva has tkhtml3 |
| 17:39.46 |
talcite |
brlcad: yeah,
but tkimg was also one of the ones that I had us statically compile
because I thought it wasn't in fedora |
| 17:39.46 |
brlcad |
interesting
that "tkhtml" doesn't match the "tkhtml3" search |
| 17:39.49 |
talcite |
I have no
idea how I missed that |
| 17:40.12 |
brlcad |
looks like
your job is done! |
| 17:40.17 |
talcite |
err not
statically compile, but have us compile from within the
project |
| 17:40.22 |
talcite |
yeah
=S |
| 17:40.26 |
starseeker |
checks Utah and TNT... |
| 17:40.41 |
talcite |
hmm tkpng is
already in fedora. convenient |
| 17:40.54 |
brlcad |
TNT doesn't
make a whole lot of sense to me as an RPM .. it's just a set of
headers |
| 17:41.08 |
talcite |
no, utah and
tnt aren't there. I just checked again |
| 17:41.10 |
brlcad |
nothing to
compile |
| 17:41.23 |
talcite |
hmm. that's
true |
| 17:41.26 |
brlcad |
no resulting
"library" |
| 17:41.38 |
talcite |
I was
actually thinking about that the other day. It could possibly only
exist as a dev package? |
| 17:41.50 |
brlcad |
are there
separate -dev packages? |
| 17:41.55 |
talcite |
yes |
| 17:42.01 |
talcite |
devel to be
more precise |
| 17:42.02 |
brlcad |
ah, then yeah
.. that's all it'd be |
| 17:42.23 |
*** join/#brlcad __monty__
(n=toon@151.143-247-81.adsl-dyn.isp.belgacom.be) |
| 17:42.25 |
talcite |
I'm actually
curious about how they managed to build tkImg in fedora |
| 17:42.41 |
starseeker |
talcite: if I
were you I'd not dig in too deep |
| 17:42.44 |
brlcad |
with the
install amounting to something like "for i in *.h ; do cp $i
$INSTROOOOT ; done" |
| 17:42.57 |
talcite |
starseeker:
haha shooting myself in the foot? =) |
| 17:42.58 |
starseeker |
if the notice
it's doing something "against policy" you might get elected to fix
it :-P |
| 17:43.34 |
brlcad |
http://rpmfind.net/linux/rpm2html/search.php?query=RLE&submit=Search+...&system=&arch= |
| 17:44.08 |
talcite |
wait. They're
using tkimg v1.4 |
| 17:44.10 |
talcite |
is that even
out? |
| 17:44.31 |
starseeker |
talcite: it
shouldn't matter |
| 17:44.44 |
starseeker |
we don't
exactly strain tkimg... |
| 17:44.50 |
talcite |
well, the
thing is that they may have changed the lib inclusion
format |
| 17:44.59 |
talcite |
between 1.3
and 1.4 I mean |
| 17:45.16 |
talcite |
I just
checked, the website has 1.3 . What's going on? |
| 17:45.35 |
starseeker |
they're
tracking subversion (or cvs) |
| 17:45.52 |
talcite |
they should
put that in the version info if they were |
| 17:46.06 |
talcite |
oh wait, they
put it in the release stuff. ok |
| 17:46.37 |
brlcad |
notes that we're probably the maintainers of URT at this
point |
| 17:46.50 |
talcite |
really? I
thought you guys didn't change it |
| 17:47.05 |
starseeker |
he means the
original team isn't actively working on it anymore |
| 17:47.37 |
starseeker |
hadn't looked at utah rle much... |
| 17:47.40 |
starseeker |
googles... |
| 17:47.42 |
brlcad |
URT was part
of the "Alpha 1" project, which BRL funded back in the
day |
| 17:48.18 |
brlcad |
Alpha 1 was a
larger umbrella project aim at (*drumroll*) developing a NURBS ray
tracing capability |
| 17:49.27 |
starseeker |
winces |
| 17:49.53 |
starseeker |
I don't even
see where to download it... |
| 17:50.02 |
brlcad |
they got it
working, one of the first |
| 17:50.14 |
brlcad |
but the
project was a bit of a fiasco, though |
| 17:50.25 |
brlcad |
got mired in
legal problems |
| 17:50.31 |
starseeker |
yuck |
| 17:50.43 |
talcite |
=/ |
| 17:50.44 |
starseeker |
leave it to
the lawyers... |
| 17:52.05 |
talcite |
Utah is clean
though right? |
| 17:52.12 |
starseeker |
ah, yes...
http://www.cs.utah.edu/gdc/projects/alpha1/ |
| 17:52.27 |
brlcad |
as I
understand it (purely anecdotal), BRL threw several million at
UofUtah to write the code, they did, then UofUtah told BRL they
didn't have rights use ite |
| 17:52.48 |
brlcad |
legal battle
ensued |
| 17:53.23 |
starseeker |
and evidently
Utah hung onto it |
| 17:53.30 |
talcite |
huh. well
that's something |
| 17:54.15 |
brlcad |
in the end, I
think both sides walked away, UoUtah got a bunch of papers (and
money) out of the deal |
| 17:54.47 |
brlcad |
utah saw
dollar signs when they got it working, wanted to sell
it |
| 17:55.14 |
brlcad |
apparently
licensed it to at least one group, FeatureCAM |
| 17:55.32 |
starseeker |
bah.
Whatever happened to the idea of universities doing research for
the betterment of humanity, not commercial gain? |
| 17:56.10 |
brlcad |
that was long
before my time, 15-20 years iirc |
| 17:56.54 |
starseeker |
and we end up
with libutahrle, which I gather is used for format
conversion? |
| 17:57.15 |
brlcad |
URT was at
least released, way back in late 80's |
| 17:57.47 |
brlcad |
libutahrle is
like libpng, we have a bunch of image processing tools that use
it |
| 17:58.14 |
brlcad |
looks like 58
tools |
| 17:59.23 |
brlcad |
provides
fast, simple, and lossless .pix/.bw compression |
| 18:00.19 |
brlcad |
worth noting
that probably 30-40 of the rle tools are from URT, the rest are
ours using libutahrle |
| 18:00.35 |
starseeker |
hrm |
| 18:00.58 |
brlcad |
useful
processing plugins when we get that all working |
| 18:01.55 |
starseeker |
where does
that leave talcite for making an rpm? Are we now the canonical
source? |
| 18:02.21 |
``Erik |
shudders recalling his pcx loader for quake
shtuff |
| 18:04.49 |
brlcad |
doesn't
really affect talcite making an rpm |
| 18:05.31 |
talcite |
so no source
changes? |
| 18:06.01 |
brlcad |
nothing major
that should affect integration |
| 18:07.44 |
brlcad |
if you really
want to cleanest set of sources, that would be ours |
| 18:08.42 |
brlcad |
but we
already break out librle from the tools |
| 18:09.18 |
brlcad |
we're
basically 3.1b + minor build tweaks with URT and librle
separated |
| 18:10.02 |
brlcad |
talcite: the
existing RPM is no good? |
| 18:10.33 |
brlcad |
http://rpmfind.net/linux/rpm2html/search.php?query=RLE |
| 18:11.28 |
talcite |
brlcad:
haven't tried yet. I probably need to work from native sources
though. The package reviewers would have a fit if they
weren't |
| 18:11.54 |
brlcad |
that's my
point, we could certainly become the native sources |
| 18:12.17 |
brlcad |
could set up
a proper project for URT, push out a new release |
| 18:12.25 |
talcite |
ohhh that's
what you mean |
| 18:12.39 |
brlcad |
there is no
upstream |
| 18:13.05 |
talcite |
it'd make
things much simpler if we could. At the current situation, I'd be
forced to become upstream myself |
| 18:13.55 |
talcite |
could we push
out a project for utah, nurbs, and STEP? |
| 18:14.05 |
brlcad |
spencer isn't
at uofutah any longer, there is no upstream |
| 18:15.14 |
brlcad |
nurbs I
wouldn't want to usurp personally, we're already pushing mcneal's
generosity given how we use their toolkit |
| 18:15.22 |
brlcad |
STEP we
certainly could |
| 18:16.26 |
brlcad |
also has no
interested/viable upstream, already gave us the go-ahead for
takeover a couple years ago |
| 18:16.45 |
talcite |
hmm. Alright,
I'll talk to the fedora devs about nurbs. Once utah and step are
re-released, I'll go ahead and package them |
| 18:17.29 |
brlcad |
setting up
utah and step projects will probably take a couple
weeks |
| 18:18.03 |
brlcad |
(given the
time of year and all) |
| 18:19.29 |
starseeker |
talcite: what
do you need for "separate project?" tarball that can build on its
own? |
| 18:20.56 |
talcite |
preferably
its own tracker. Something I can point to when people are looking
for sources and bug reports |
| 18:22.06 |
starseeker |
uh.. that
might as well be our current stuff for BRL-CAD - what would be
wrong with tarballs for those two and pointers to our current
support channels? |
| 18:23.21 |
talcite |
probably not
an issue |
| 18:23.36 |
talcite |
I'll double
check with the fedora devs though |
| 18:23.41 |
starseeker |
k |
| 18:24.25 |
starseeker |
step already
has its own subconfigure - utahrle does not, currently |
| 18:26.12 |
starseeker |
gonna have to
update the detection logic for step building (or more probably
create it, I doubt I did it right the first time) |
| 18:35.40 |
brlcad |
step will be
pretty easy, urt will need some cleanup to warrant a 3.2 or 4.0
release |
| 18:36.51 |
brlcad |
i'll submit a
project request to give them a tracker home |
| 18:37.51 |
brlcad |
then can link
through some subdomains, get basic services set up |
| 18:37.56 |
starseeker |
utahrle.sf.net? |
| 20:02.28 |
*** join/#brlcad tofu (n=sean@BZ.BZFLAG.BZ) |
| 20:16.19 |
starseeker |
heh - brlcad
got killed by tofu |
| 20:17.21 |
tofu |
huh |
| 20:20.50 |
starseeker |
just the way
the nicks came and went |
| 20:20.55 |
starseeker |
is easily amused |
| 20:21.21 |
tofu |
fails to locate a valid e-mail for nathan
o'brien |
| 20:27.34 |
CIA-38 |
BRL-CAD:
03starseeker * r36925 10/brlcad/trunk/ (25 files in 8
dirs): |
| 20:27.34 |
CIA-38 |
BRL-CAD: Swap
in tkpng for the small subset of tkimg we were previously using -
also try |
| 20:27.34 |
CIA-38 |
BRL-CAD: to
set up tkpng to support 'proper' package require use. Archer
appears to be |
| 20:27.34 |
CIA-38 |
BRL-CAD: the
only app using it at the moment, so remove tkimg loading code and
package |
| 20:27.34 |
CIA-38 |
BRL-CAD:
require tkpng instead. As of this checking tkpng won't build out of
box in all |
| 20:27.34 |
CIA-38 |
BRL-CAD:
cases - the current src/other/tkpng is a pristine 0.9 tarball. Next
checking |
| 20:27.36 |
CIA-38 |
BRL-CAD: will
add specific changes to build logic for BRL-CAD. |
| 20:28.34 |
starseeker |
er, whooops -
OK not quite pristine |
| 20:31.41 |
CIA-38 |
BRL-CAD:
03starseeker * r36926 10/brlcad/trunk/src/other/tkpng/Makefile.in:
Whoops, looks like svn helpfully ignored the original
Makefile.in |
| 20:32.00 |
tofu |
passes
distcheck? |
| 20:33.40 |
starseeker |
tofu: not
yet, working on it |
| 20:34.19 |
CIA-38 |
BRL-CAD:
03starseeker * r36927 10/brlcad/trunk/src/other/tkpng/ (Makefile.in
configure configure.in): OK, add the tweaks to Makefile.in and
configure.in. Shouldn't need the original configure file. This
extension should disappear altogether if Tk8.6 brings native
support for png. |
| 20:34.58 |
starseeker |
tofu: if you
want we can revert it until after the release |
| 20:37.37 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 20:37.52 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 20:44.09 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 20:45.29 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 21:08.55 |
starseeker |
starts distcheck and goes for food |
| 21:19.25 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r36928 10/brlcad/trunk/src/libfb/if_X.c: add
prototype for genmap |
| 21:22.40 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r36929 10/brlcad/trunk/src/librt/primitives/
(metaball/metaball.c table.c): fix metaball_adjust
prototype |
| 21:27.59 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r36930
10/brlcad/trunk/src/libtclcad/tkImgFmtPIX.c: match type with
fb.h |
| 21:43.15 |
``Erik |
hm, seems to
be some libtool vs not libtool confusion in tkpng |
| 21:45.29 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 21:46.11 |
``Erik |
http://paste.bzflag.bz/d49811205 |
| 21:56.59 |
``Erik |
huh, xcb
requires python? O.o |
| 22:06.45 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
| 22:10.33 |
CIA-38 |
BRL-CAD:
03starseeker * r36931 10/brlcad/trunk/src/other/Makefile.am: tkimg
dir is no more. |
| 22:12.49 |
talcite |
heh
yay |
| 22:12.51 |
tofu |
starseeker:
per erik's paste, need to make the install rule manually run make
all before make install, then install without libtool |
| 22:14.10 |
starseeker |
er... |
| 22:14.45 |
``Erik |
this is
pleasant, fbsd has a tkpng port |
| 22:15.36 |
talcite |
tkpng is
already packaged into fedora as well |
| 22:15.54 |
tofu |
excellend |
| 22:15.56 |
tofu |
t* |
| 22:15.57 |
``Erik |
so if the
configure.ac is smart enough to use the system one, less in
/usr/local/brlcad/ :) |
| 22:16.12 |
starseeker |
don't y'all
get too happy too fast, I haven't got it working right
yet |
| 22:16.20 |
starseeker |
<- autotools dummy :-( |
| 22:16.31 |
talcite |
I'm sure
brlcad can get things working for you |
| 22:16.49 |
starseeker |
talcite:
he'll let me flounder a while - good learning experience
:-/ |
| 22:16.54 |
talcite |
there's also
a channel here that helps with autotools... #toolchain or
something? |
| 22:16.57 |
talcite |
heh |
| 22:18.10 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 22:18.10 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 22:18.17 |
``Erik |
learning
experience, entertainment, something |
| 22:18.42 |
talcite |
##workingset
That was it |
| 22:18.49 |
talcite |
these guys
are really good |
| 22:19.44 |
starseeker |
talcite: part
of the issue is we have a rather advanced autotools setup compared
to what a lot of projects have, and are doing a lot of custom
things (the db directory is a good example) |
| 22:19.53 |
brlcad |
sees a couple bzflag devs in there |
| 22:20.59 |
starseeker |
brlcad: do
you mean doing something like tkpng-install: tkpng-all in
src/other/Makefile.am? |
| 22:21.29 |
brlcad |
no, i mean
one line to run all |
| 22:21.31 |
brlcad |
another to
run install |
| 22:21.34 |
brlcad |
for the
install rule |
| 22:21.37 |
starseeker |
oh |
| 22:32.10 |
``Erik |
wow, 33 megs
in src/other/boost/ O.O |
| 22:35.28 |
CIA-38 |
BRL-CAD:
03starseeker * r36932 10/brlcad/trunk/src/other/Makefile.am: If
someone runs the install rule, make sure make all is run
first. |
| 22:35.29 |
starseeker |
takes a stab at it... |
| 22:45.51 |
starseeker |
``Erik: did
that help any? |
| 23:04.57 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 23:14.30 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:15.47 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.188) |
| 23:17.48 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:21.32 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 23:32.04 |
*** join/#brlcad dtidrow (n=Don@71.238.51.148) [NETSPLIT
VICTIM] |
| 23:48.50 |
yukonbob |
brlcad:
what's the "kde/hyrdrogen/linux" .po discussion that's been going
on about? |
| 00:47.04 |
CIA-38 |
BRL-CAD:
03brlcad * r36959 10/brlcad/trunk/src/librt/vshoot.c: |
| 00:47.04 |
CIA-38 |
BRL-CAD:
bring vshoot up-to-date with the current API, eliminating a lot of
old cruft |
| 00:47.04 |
CIA-38 |
BRL-CAD: that
has changed. eliminated the duplication with non-vector helper
functions |
| 00:47.04 |
CIA-38 |
BRL-CAD:
(they're in shoot.c). updated to bitvs and ptbls except didn't make
the |
| 00:47.05 |
CIA-38 |
BRL-CAD:
necessary bookkeeping mods needed for rt_boolfinal() to keep track
of finished |
| 00:47.07 |
CIA-38 |
BRL-CAD: and
waiting segments. that means this will NOT actually work, but
should at |
| 00:47.09 |
CIA-38 |
BRL-CAD:
least compile cleanly once again. |
| 00:48.53 |
CIA-38 |
BRL-CAD:
03brlcad * r36960 10/brlcad/trunk/src/librt/Makefile.am: activate
vshoot.c so that the file can stay in sync and possibly be worked
on again now that it's back to a compiling state. |
| 01:04.47 |
CIA-38 |
BRL-CAD:
03brlcad * r36961
10/brlcad/trunk/src/librt/primitives/tgc/tgc.c: |
| 01:04.47 |
CIA-38 |
BRL-CAD:
these must be FIXED, not hacked around. can't have DM_* toggles in
librt just |
| 01:04.47 |
CIA-38 |
BRL-CAD: to
quell root solver failures. root solver failures are higher
priority than |
| 01:04.47 |
CIA-38 |
BRL-CAD: the
display feature (they indicate a low-level solidity
failure). |
| 01:06.35 |
CIA-38 |
BRL-CAD:
03brlcad * r36962 10/brlcad/trunk/src/librt/Makefile.am: more rtgl
turd cleanup. librt shall not depend on libdm. |
| 01:09.06 |
brlcad |
woot, more
than 50% of librt |
| 01:14.03 |
starseeker |
erm - what
happened with the tgc? |
| 01:27.31 |
CIA-38 |
BRL-CAD:
03brlcad * r36963 10/brlcad/trunk/src/librt/ (shoot.c vshoot.c):
move the rt_vstub() function into vshoot.c and make it HIDDEN.
rename it to vshot_stub() in the process, calling it if a primitive
has a null vshot callback. |
| 01:30.23 |
brlcad |
starseeker:
hm? |
| 01:31.24 |
brlcad |
nothing
happened to tgc, just people ignoring the root solver failures when
it mattered instead of investigating the problem. |
| 01:32.24 |
brlcad |
presumably,
the printing evaluation failure statements slow down rtgl rendering
or were just annoying |
| 01:33.16 |
brlcad |
so someone
commented them out, which is a prioritization failure imho ..
that's not something that should get pushed off for
"later" |
| 01:33.22 |
brlcad |
if it's a
problem, fix the problem |
| 01:34.28 |
brlcad |
probably
something nick tossed in while working on rtgl, just caught it
now |
| 01:35.34 |
CIA-38 |
BRL-CAD:
03brlcad * r36964 10/brlcad/trunk/src/librt/primitives/ (27 files
in 27 dirs): |
| 01:35.34 |
CIA-38 |
BRL-CAD:
eliminate the empty vshot() callbacks. now only primitives that
actually do |
| 01:35.34 |
CIA-38 |
BRL-CAD:
something have a non-null callback (which is presently arb8, ell,
half, rec, |
| 01:35.34 |
CIA-38 |
BRL-CAD: sph,
tgc, and tor). the rt_vshootray() caller tests for whether it's
null and |
| 01:35.34 |
CIA-38 |
BRL-CAD:
calls a shot stub if needed. |
| 01:35.41 |
starseeker |
ah |
| 01:35.53 |
starseeker |
``Erik: heh,
this looks like it's up your alley: http://dwim.hu |
| 01:44.06 |
Ralith |
woah |
| 01:44.09 |
Ralith |
fancy |
| 01:44.12 |
Ralith |
slow,
though |
| 01:44.33 |
starseeker |
oh, COOL -
someone is looking at an llvm backend for sbcl |
| 01:45.22 |
Ralith |
I saw
that |
| 01:45.32 |
Ralith |
I'm not
entirely sure what benefits it would confer |
| 01:46.14 |
Ralith |
(other than
the generally neat idea of collaborating with users of other
languages on a single Sufficiently Smart Compiler) |
| 01:47.28 |
starseeker |
Well, Stephen
Wilson is working on a language called Comma, which targets llvm:
http://savannah.nongnu.org/projects/comma |
| 01:48.02 |
starseeker |
He's
developing it with Aldor, SPAD and Ada in mind - should be
appropriate for mathematical uses |
| 01:48.14 |
starseeker |
would like it to be usable with Lisp |
| 01:48.18 |
Ralith |
I mean, why
is it a Good Thing to have a LLVM backend in SBCL? |
| 01:48.20 |
Ralith |
oh, easy
FFI? |
| 01:48.23 |
starseeker |
bingo |
| 01:48.36 |
Ralith |
hm,
interesting |
| 01:49.00 |
starseeker |
hopefully, a
function call to a Comma function in Lisp (or vice versa) could be
handled semi-intelligently at the LLVM level |
| 01:49.08 |
Ralith |
I wonder if
clang would allow that to be extended to C++ support |
| 01:49.17 |
starseeker |
dunno |
| 01:49.30 |
starseeker |
it might
require designing the compiler(s) with that specific use in
mind |
| 01:49.45 |
starseeker |
but since
Stephen is writing Comma from the ground up... :-) |
| 01:50.28 |
starseeker |
he was part
of the Axiom mailing list a couple years ago, had an interest in
the language used to describe mathematics in Axiom |
| 01:51.11 |
Ralith |
surely there
are benefits other than easy FFI to specially designed
llvm-targeting languages, though |
| 01:51.14 |
starseeker |
Aldor was the
"successor" to SPAD, the original version of the language in Axiom
- it's license never became compatible though |
| 01:51.26 |
starseeker |
Ralith: oh,
sure - lots of potential performance goodies |
| 01:51.41 |
Ralith |
performance
<3 |
| 01:52.09 |
Ralith |
just 'cuz
LLVM has lots of shiny optimization magics that native SBCL
lacks? |
| 01:52.11 |
starseeker |
Aldor
actually showed the way on how to approach such things - it was
able to generate Lisp code for compiling into a Lisp target, or
compile directly through gcc |
| 01:52.15 |
starseeker |
(I
think) |
| 01:52.21 |
starseeker |
maybe had
it's own compiler |
| 01:52.34 |
starseeker |
Ralith:
actually, not sure if LLVM will outperform sbcl's own
compiler |
| 01:52.51 |
starseeker |
but it's
probably a fair bet llvm will get ported to a lot of
platforms |
| 01:52.58 |
Ralith |
good
point |
| 01:53.09 |
Ralith |
and it's
nearly always beneficial to pool effort |
| 01:53.11 |
starseeker |
kindaaa like
targeting the Java virtual machine, but with modern llvm
goodness |
| 01:53.37 |
Ralith |
has always been kind of fuzzy on exactly what modern llvm
goodness entails |
| 01:54.08 |
starseeker |
Apparently a
lot of compiler research has taken place since the basic gcc
framework was laid out |
| 01:54.28 |
starseeker |
plus most
descriptions of gcc's codebase I've heard are... well...
colorful |
| 01:55.14 |
Ralith |
okay, cleaner
and better-designed code is certainly desirable |
| 01:55.21 |
Ralith |
but where's
the "vm" come in? |
| 01:55.33 |
starseeker |
virtual
machine, I believe... |
| 01:55.35 |
starseeker |
checks |
| 01:55.54 |
starseeker |
license is
another one |
| 01:56.13 |
starseeker |
the *BSD
folks and a lot of commercial folk would LOVE for there to be a
Modified BSD licensed compiler chain |
| 01:56.39 |
starseeker |
yeah - LLVM =
Low Level Virtual Machine |
| 01:57.21 |
starseeker |
I think the
virtual machine part allows for certain types of optimizations that
would be difficult otherwise, but it's not my specialty |
| 01:57.53 |
Ralith |
I mean, I
knew what VM refers to |
| 01:58.19 |
Ralith |
but I'm not
clear on what the VM portion of llvm is [for]. |
| 01:58.28 |
Ralith |
sounds like
I'm not entirely alone there, though |
| 01:58.55 |
starseeker |
yeah, that's
beyond my knowledge depth |
| 02:02.35 |
Ralith |
well,
whatever the details, it'll be cool if this gets picked
up. |
| 02:18.57 |
``Erik |
*readreadread* gcc is in it's third
incarnation since I started watching... 2.7.x was there... then
egcs kinda threw it all to the wind, then 4.0 was a total rewrite
for new optimizations |
| 02:19.45 |
``Erik |
llvm kinda
smells like a jvm that no one cares about :( |
| 02:22.39 |
``Erik |
dwim is what,
an instance of an everyday software stack? :D I fail to see
anything new and impressive :( |
| 02:31.58 |
Ralith |
could not easily determine what dwim *is* |
| 02:32.09 |
Ralith |
my best guess
is some sort of web toolkit. |
| 02:32.30 |
Ralith |
``Erik: "a
jvm that no one cares about?" Everyone I've talked to seems to
think that it's a Good Thing. |
| 02:32.53 |
Ralith |
accross
several language communities, no less. |
| 02:35.14 |
``Erik |
:D |
| 02:35.48 |
``Erik |
it seems to
be doing what sun already did... and a few language weenies went
"ooh", ... |
| 02:52.57 |
starseeker |
``Erik: just
thought lisp + web might interest you (dwim) |
| 02:54.38 |
starseeker |
if nothing
else, BSD licensed compiler stack will make a lot of people
happy |
| 02:58.34 |
Ralith |
oh, there's
plenty of lisp+web stuff out there, and tbh most of it is a bit
less ill-defined than dwim >_> |
| 03:03.17 |
``Erik |
lisp is
nifty, web seems inevitable... ucw is damn sexy, hunchentoot is
kinda ok |
| 03:03.55 |
``Erik |
faking
stateful operation over a stateless protocol using continuations,
that's drop dead sexy |
| 03:08.33 |
``Erik |
ralith: check
out ucw if you get some time, it makes list+web awesome |
| 03:08.40 |
``Erik |
lisp+web
even |
| 03:14.44 |
Ralith |
not the
sexiest of homepages for a web framework |
| 03:14.46 |
Ralith |
but it sounds
interesting |
| 03:14.48 |
CIA-38 |
BRL-CAD:
03brlcad * r36965 10/brlcad/trunk/src/librt/primitives/ (eto/eto.c
extrude/extrude.c table.c xxx/xxx.c): more quellage. add more
extesive parameter testing to the xxx template for the
primitive-specific structure, add more data validation. |
| 03:14.52 |
Ralith |
foods |
| 03:36.38 |
*** join/#brlcad talcite__
(n=matthew@69-196-132-129.dsl.teksavvy.com) |
| 03:37.39 |
brlcad |
shakes fist at the binunif turds that ripple
throughout |
| 03:47.05 |
CIA-38 |
BRL-CAD:
03brlcad * r36966 10/brlcad/trunk/TODO: |
| 03:47.05 |
CIA-38 |
BRL-CAD:
binary objects need to write out their minor type during export so
that the data |
| 03:47.05 |
CIA-38 |
BRL-CAD: can
be properly imported without munging the API for everyone else.
this |
| 03:47.05 |
CIA-38 |
BRL-CAD:
unfortunately (probably) cannot be accomplished without breaking
protocol, so |
| 03:47.05 |
CIA-38 |
BRL-CAD:
hacking around it for now. |
| 04:14.52 |
CIA-38 |
BRL-CAD:
03brlcad * r36967 10/brlcad/trunk/ (10 files in 6 dirs): (log
message trimmed) |
| 04:14.52 |
CIA-38 |
BRL-CAD:
remove minor_type from the functab interface for import5/export5.
this was |
| 04:14.52 |
CIA-38 |
BRL-CAD:
apparently only added for binary objects, which needs to know which
minor type |
| 04:14.52 |
CIA-38 |
BRL-CAD: they
are during import. instead of the object writing out it's minor
type |
| 04:14.52 |
CIA-38 |
BRL-CAD:
during export, it munged the api to have the minor type passed from
the |
| 04:14.54 |
CIA-38 |
BRL-CAD:
raw_external instead. this moves towards undoing that by removing
minor_type |
| 04:14.56 |
CIA-38 |
BRL-CAD: from
all other objects and making binunif's a special case in db5_io.
once |
| 05:21.00 |
CIA-38 |
BRL-CAD:
03brlcad * r36968 10/brlcad/trunk/src/libged/put.c: ft_make no
longer takes a diameter value |
| 05:23.17 |
CIA-38 |
BRL-CAD:
03brlcad * r36969 10/brlcad/trunk/src/libged/wdb_obj.c: bah,
another ft_make with diagonal/diamter value that needs removing.
also start the killage on expm. |
| 05:25.30 |
CIA-38 |
BRL-CAD:
03brlcad * r36970 10/brlcad/trunk/src/conv/asc/asc2g.c: ft_import5
no longer takes the minor type. fix this outlier. |
| 05:29.18 |
CIA-38 |
BRL-CAD:
03brlcad * r36971 10/brlcad/trunk/ (8 files in 4 dirs): |
| 05:29.18 |
CIA-38 |
BRL-CAD:
remove the 'experimental' binary object type. this was never
implemented beyond |
| 05:29.18 |
CIA-38 |
BRL-CAD: a
few stubs and has a horrible vague name, so kill it. we have to
leave the ID |
| 05:29.18 |
CIA-38 |
BRL-CAD: and
functab entry stubbed so that indices offset correctly but mark it
as unused |
| 05:29.18 |
CIA-38 |
BRL-CAD: so
some future new object could conceivably reclaim the
ID. |
| 06:08.31 |
starseeker |
hmm...
xprocess looks kinda neat but man compiling it... |
| 08:47.45 |
CIA-38 |
BRL-CAD:
03d_rossberg * r36972 10/brlcad/trunk/src/librt/CMakeLists.txt:
updated CMake file to be consistent with Makefile.am (activated
vshoot.c) |
| 09:28.44 |
*** join/#brlcad docelic__
(n=docelic@78-2-80-138.adsl.net.t-com.hr) |
| 09:41.05 |
*** join/#brlcad ultralazer
(n=user3@97-119-214-177.hlna.qwest.net) |
| 09:46.40 |
*** join/#brlcad docelic_
(n=docelic@78-2-110-236.adsl.net.t-com.hr) |
| 11:19.24 |
CIA-38 |
BRL-CAD:
03indianlarry * r36973 10/brlcad/trunk/src/libbu/ (bomb.c
cmdhist_obj.c): Wrapped debug variable declaration with DEBUG
definition. Removed bu_cmdtab struct array 'ch_cmds[]' and
'cho_hist()', look to be un-used copies of existing definitions
'cho_cmds[]' and 'cho_cmd()'. |
| 11:42.27 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 13:21.07 |
*** join/#brlcad talcite
(n=matthew@69-196-132-129.dsl.teksavvy.com) |
| 13:33.33 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
| 13:50.45 |
CIA-38 |
BRL-CAD:
03brlcad * r36974 10/brlcad/trunk/src/libged/nirt.c: ws
cleanup |
| 13:57.19 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 13:57.30 |
CIA-38 |
BRL-CAD:
03brlcad * r36975 10/brlcad/trunk/src/libged/nirt.c: init
vars |
| 14:20.25 |
CIA-38 |
BRL-CAD:
03brlcad * r36976 10/brlcad/trunk/src/libged/nirt.c: |
| 14:20.25 |
CIA-38 |
BRL-CAD:
there probably be little dragons here. replace the strip_crlf()
win32-specific |
| 14:20.25 |
CIA-38 |
BRL-CAD: hack
with a more generalized solution that just trims space on the line
parsed |
| 14:20.25 |
CIA-38 |
BRL-CAD: in.
it's not clear why they even matter with bu_fgets() reading in
lines |
| 14:20.27 |
CIA-38 |
BRL-CAD:
portably other than it printing \n\r's into the result string
(which then also |
| 14:20.29 |
CIA-38 |
BRL-CAD: just
begs for space trimming). untested. |
| 14:46.02 |
``Erik |
hm, \r\n is
ansi, unix kinda cheats |
| 15:05.12 |
brlcad |
doesn't
change anything |
| 15:05.37 |
brlcad |
good grief,
the step converter code is a headache :) |
| 15:06.58 |
brlcad |
going through
some basic mods and cleanup, and .. d-d-d-damn are the
headers/decls in disarray |
| 15:07.17 |
brlcad |
cascade
failures |
| 15:08.50 |
brlcad |
headers not
including what they need, interfaces not coming first, replication
of inclusions, ... this is going to take some work .. especially
SCL stupidly naming a class BOOL of all things |
| 15:27.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14B923.dip.t-dialin.net) |
| 15:33.39 |
starseeker |
note to self
- check this out later: http://users.iit.demokritos.gr/~petasis/Tcl/toolbar.tcl |
| 15:36.51 |
CIA-38 |
BRL-CAD:
03brlcad * r36977 10/brlcad/trunk/src/other/step/src/ (13 files in
3 dirs): |
| 15:36.51 |
CIA-38 |
BRL-CAD:
rename the BOOL and BOOLS classes to BOOLEAN and BOOLEANS
respectively so as not |
| 15:36.51 |
CIA-38 |
BRL-CAD: to
conflict with openNURBS (and other codes that commonly use BOOL as
a simple |
| 15:36.51 |
CIA-38 |
BRL-CAD:
boolean type). this also conveniently makes the class name lengths
match the |
| 15:36.51 |
CIA-38 |
BRL-CAD:
corresponding LOGICAL and LOGICALS classes. unsure about the
Bool->Boolean |
| 15:36.53 |
CIA-38 |
BRL-CAD:
declarations and how they come into play, alas, so have to see if
those need to |
| 15:36.55 |
CIA-38 |
BRL-CAD: be
unrolled for the actual step parsing. |
| 15:42.03 |
brlcad |
that commit
likely breaks compile when coupled with the previous,
fixing |
| 15:42.06 |
CIA-38 |
BRL-CAD:
03brlcad * r36978 10/brlcad/trunk/src/conv/step/ (13
files): |
| 15:42.06 |
CIA-38 |
BRL-CAD:
beginning of massive header and type inclusion cleanup. header
inclusion |
| 15:42.06 |
CIA-38 |
BRL-CAD:
ordering of c++ needs to be cleaned up. avoiding inclusion of std
namespace. |
| 15:42.06 |
CIA-38 |
BRL-CAD:
formatting/ws/indent cleanup. opening braces. work in progress with
more on |
| 15:42.06 |
CIA-38 |
BRL-CAD: the
way. |
| 15:48.21 |
brlcad |
wonders how much of this will be for moot |
| 15:48.23 |
CIA-38 |
BRL-CAD:
03brlcad * r36979 10/brlcad/trunk/src/conv/step/ (19 files): use
the updated (Boolean) and (BOOLEAN) instead of (Bool) and (BOOL),
so as to avoid a conflict with other codes. |
| 15:50.08 |
brlcad |
mm, looks
like that at least got closer to compile |
| 15:55.24 |
CIA-38 |
BRL-CAD:
03brlcad * r36980 10/brlcad/trunk/src/conv/step/ (Factory.cpp
Factory.h): cleanup, declare interface headers, reorder
accordingly; consistent formatting |
| 16:03.18 |
CIA-38 |
BRL-CAD:
03brlcad * r36981 10/brlcad/trunk/src/conv/step/ (Factory.cpp
Factory.h): oops, already had forward decl on STEPEntity. only
needed for the implementation. |
| 16:07.21 |
CIA-38 |
BRL-CAD:
03brlcad * r36982
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: SurfaceTree
is in the brlcad namespace |
| 16:11.26 |
*** join/#brlcad indianlarry
(n=indianla@BZ.BZFLAG.BZ) |
| 16:17.56 |
*** join/#brlcad Computer_
(n=Computer@209-16-114-100.net.bhntampa.com) |
| 16:34.35 |
CIA-38 |
BRL-CAD:
03brlcad * r36983 10/brlcad/trunk/src/conv/step/ (PullbackCurve.cpp
PullbackCurve.h): more brlcad namespace qualifications, cleanup ws
indent and brace formatting |
| 16:58.01 |
starseeker |
is rather puzzled... if I uncomment the line *fbp =
tk_interface in dm-tk.c, mged initialization failes with a bad
alloc without ever hitting that line... |
| 16:58.32 |
starseeker |
oh,
wait... |
| 16:58.36 |
starseeker |
it's
something else |
| 16:58.50 |
starseeker |
hmm... |
| 17:35.51 |
CIA-38 |
BRL-CAD:
03brlcad * r36984 10/brlcad/trunk/src/conv/step/step-g.cpp: ws
indent cleanup, remove using, comments, etc |
| 17:45.34 |
starseeker |
o.O |
| 17:45.43 |
starseeker |
../src/conv/asc2g
../../brlcad/db/terra.asc terra.g |
| 17:45.43 |
starseeker |
ERROR: bad
pointer x106efb00: s/b rt_db_internal(xdbbd867), was
Unknown_Magic(x5625), file
../../../brlcad/src/librt/primitives/dsp/dsp.c, line
256 |
| 17:45.46 |
starseeker |
ERROR: bad
pointer x106efb00: s/b rt_db_internal(xdbbd867), was
Unknown_Magic(x5625), file
../../../brlcad/src/librt/primitives/dsp/dsp.c, line
256 |
| 17:54.56 |
starseeker |
did something
with that binary minor type change impact how dsp does its
thing? |
| 17:55.07 |
starseeker |
hunts... |
| 17:57.49 |
brlcad |
starseeker:
very likely |
| 17:58.14 |
brlcad |
or one of the
checks I added is for the wrong object type |
| 18:32.10 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 18:32.10 |
*** join/#brlcad Computer_
(n=Computer@209-16-114-100.net.bhntampa.com) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad indianlarry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 18:32.10 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 18:32.10 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 18:42.07 |
CIA-38 |
BRL-CAD:
03brlcad * r36986 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp:
compare pointer to NULL, not char |
| 19:22.47 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 19:22.47 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 19:22.47 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
| 19:22.47 |
*** join/#brlcad indianlarry
(n=indianla@BZ.BZFLAG.BZ) |
| 19:22.47 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 19:22.48 |
*** join/#brlcad cosurg1
(n=cosurgi@atak.bl.pg.gda.pl) |
| 19:22.48 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 19:22.48 |
*** join/#brlcad b0ef
(n=b0ef@157.26.202.84.customer.cdi.no) |
| 19:22.48 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) |
| 19:22.48 |
*** join/#brlcad dtidrow
(n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 19:22.48 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 19:22.48 |
*** join/#brlcad poolio
(n=poolio@63.246.136.16) |
| 19:22.48 |
*** join/#brlcad starseeker
(n=starseek@BZ.BZFLAG.BZ) |
| 19:22.48 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 19:22.48 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
| 19:22.48 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
| 19:22.48 |
*** join/#brlcad d-lo_
(n=claymore@BZ.BZFLAG.BZ) |
| 19:22.48 |
*** join/#brlcad SWPadnos
(n=Me@emc/developer/SWPadnos) |
| 19:22.48 |
*** join/#brlcad CIA-38
(n=CIA@208.69.182.149) |
| 19:22.48 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 19:22.48 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
| 19:22.48 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 19:29.43 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 19:45.20 |
CIA-38 |
BRL-CAD:
03brlcad * r36990
10/brlcad/trunk/doc/docbook/Makefile.am: |
| 19:45.20 |
CIA-38 |
BRL-CAD:
create the directory before running xsltproc in order to avoid a
race condition |
| 19:45.20 |
CIA-38 |
BRL-CAD: that
causes xsltproc to bail. also make the clean rule not fail on
in-dir |
| 19:45.20 |
CIA-38 |
BRL-CAD:
builds (can't just remove the dir, especially if there are still
(source) files |
| 19:45.20 |
CIA-38 |
BRL-CAD: in
there) |
| 19:46.50 |
starseeker |
brlcad:
except that doesn't work when we're building the spanish
documentation |
| 19:47.54 |
starseeker |
at least, not
for man1 and man3 |
| 19:48.07 |
starseeker |
would dirname
work there too? |
| 19:48.23 |
starseeker |
no, guess
not |
| 19:48.25 |
starseeker |
hrm |
| 19:49.54 |
starseeker |
maybe move
the xml.1 and xml.3 rules to the system/man/$LANG directory
makefiles? |
| 19:50.38 |
brlcad |
hm? |
| 19:51.01 |
starseeker |
we have
system/man1/en hardcoded into the build rules for .xml.1 and
.xml.3 |
| 19:51.19 |
brlcad |
I didn't
modify the ones that are already hard-coded |
| 19:51.27 |
starseeker |
ah,
k |
| 19:51.40 |
starseeker |
so it's my
fault :-) |
| 19:51.42 |
brlcad |
they're still
hard-coded, but presumably a similar trick will work |
| 19:52.36 |
starseeker |
yes, except I
think xsltproc drops the .1 files in the current working directory
of xsltproc, rather than a targeted output |
| 19:52.49 |
starseeker |
kinda
sucks |
| 19:53.19 |
starseeker |
actually
though... |
| 19:53.38 |
starseeker |
the build
rule should know where the thing is supposed to go, even if
xsltproc doesn't do it |
| 19:53.50 |
starseeker |
tries it |
| 19:59.59 |
*** join/#brlcad kristian-aalborg
(n=kristian@2505ds5-abc.0.fullrate.dk) |
| 20:00.05 |
kristian-aalborg |
hi
all |
| 20:00.30 |
kristian-aalborg |
is there
software available that will render a 3d model from a series of 2d
pics? |
| 20:01.00 |
brlcad |
depends what
kind of 2d pics and the desired 3d model |
| 20:01.05 |
brlcad |
in general,
no |
| 20:02.30 |
brlcad |
starseeker:
at a glance, looks like you're only conditionally building the .es
fiels |
| 20:02.38 |
brlcad |
suggest
always building all languages |
| 20:05.30 |
kristian-aalborg |
I'm thinking
if I can take some pics of a thing like a cofee cup and have it
made into 3d |
| 20:05.34 |
CIA-38 |
BRL-CAD:
03brlcad * r36991 10/brlcad/trunk/doc/docbook/Makefile.am: try
generalizing the dir creation |
| 20:05.52 |
brlcad |
kristian-aalborg: heh, done much 3d
modeling before? |
| 20:06.00 |
kristian-aalborg |
none
;) |
| 20:06.27 |
kristian-aalborg |
but I've seen
a bunch of sci-fi movies ;) |
| 20:07.42 |
brlcad |
yeah, it
doesn't quite work like that |
| 20:08.18 |
starseeker |
brlcad: yeah,
I was thinking unless a user explicitly asked for all languages
they wouldn't want the overhead of doing all the building for all
the languagues |
| 20:09.19 |
starseeker |
heh - beat me
to it |
| 20:09.39 |
starseeker |
well, that's
better anyway :-) |
| 20:11.12 |
starseeker |
brlcad: oh,
how do I do a "this OR this" if case in a makefile? I haven't been
able to track down an example yet |
| 20:15.03 |
starseeker |
confirmed -
generalizing logic appears to work |
| 20:15.11 |
starseeker |
that's
SWEET |
| 20:17.16 |
``Erik |
sits around yelling "enhance" at his computer screen O.o
:D |
| 20:17.35 |
starseeker |
``Erik: do I
get yelled at if I always build all docbook all the
time? |
| 20:17.54 |
starseeker |
is willing to do it if ``Erik promises not to hurt
him |
| 20:18.11 |
``Erik |
heh, but the
dependancy chain is fugly |
| 20:18.21 |
``Erik |
xsltproc and
java for fop? |
| 20:18.41 |
starseeker |
no, no -
turning on Spanish and English for all docs always |
| 20:19.11 |
starseeker |
so not only
would you be building English, you'd be building the Spanish
versions, and the Russian versions, and the Esperanto versions...
;-P |
| 20:19.45 |
``Erik |
I imagine
klingon would be on that list before russian or esperanto ...
:D |
| 20:19.55 |
starseeker |
probably,
given our user audience |
| 20:20.40 |
``Erik |
*shrug* I
complain about dependancy sets, not product ;) |
| 20:20.59 |
starseeker |
has observed ``Erik complainin about build time here and
there |
| 20:21.29 |
``Erik |
noting
significant increases, not complaining about |
| 20:21.30 |
``Erik |
:) |
| 20:21.39 |
starseeker |
alrightie |
| 20:21.59 |
starseeker |
goes for broke |
| 20:34.23 |
brlcad |
not that big
a deal time-wise until there are more than a couple languages,
completely translated |
| 20:34.38 |
brlcad |
and by the
time that happens, I doubt compilation time will be the
issue |
| 20:34.42 |
starseeker |
true
:-) |
| 20:34.59 |
starseeker |
I ripped out
the lang flags, testing now before committing |
| 20:38.58 |
brlcad |
hm, the .es
conversion I got from the first lesson doesn't render so
hot |
| 20:38.59 |
brlcad |
as
html |
| 20:39.21 |
starseeker |
font
issue? |
| 20:43.10 |
CIA-38 |
BRL-CAD:
03starseeker * r36992 10/brlcad/trunk/ (8 files in 8 dirs): Purge
the language configuration option and build all languages all the
time, per Sean's suggestion |
| 20:44.08 |
starseeker |
well, between
that and tkpng I now feel rather uselss :-/ |
| 20:44.51 |
starseeker |
back to
framebuffer diving |
| 20:45.10 |
brlcad |
encoding
issue |
| 20:45.18 |
brlcad |
all accents
are junked up |
| 20:45.29 |
brlcad |
http://brlcad.org/~sean/tmp/mged01_crear_figuras_primitivas.html |
| 20:45.51 |
starseeker |
ah, that
thing |
| 20:46.40 |
starseeker |
I think
that's the htaccess file for Apache - needs AddDefaultCharset
UTF-8 |
| 20:47.14 |
starseeker |
see
doc/docbook/README |
| 21:40.23 |
brlcad |
make[3]: ***
No rule to make target `system/man3/en/libfb.html', needed by
`all'. Stop. |
| 21:40.38 |
starseeker |
confound
it |
| 21:42.03 |
starseeker |
ummm.... for
me it succeeded |
| 21:42.15 |
starseeker |
brlcad: what
platform are you on? |
| 21:45.49 |
brlcad |
did you
distcheck? |
| 21:46.31 |
starseeker |
ah |
| 21:46.34 |
starseeker |
distchecks |
| 21:59.22 |
starseeker |
hah, cool:
http://www.bootchart.org/images/bootchart.png |
| 22:19.04 |
starseeker |
brlcad: I can
reproduce the failure, trying to figure out what's causing
it... |
| 22:21.12 |
starseeker |
oh,
der |
| 22:22.13 |
CIA-38 |
BRL-CAD:
03starseeker * r36993 10/brlcad/trunk/doc/docbook/Makefile.am:
Whoops. Add MAN3 sources to EXTRA_DIST so distcheck brings them
along for the ride. |
| 22:22.58 |
starseeker |
hey, cool:
http://code.google.com/p/tufte-latex/ |
| 22:23.12 |
starseeker |
wonders how long before someone tries
tufte-docbook |
| 22:43.24 |
brlcad |
heh, http://people.ucsc.edu/~weissman/MathClubTalk2009.pdf |
| 22:44.46 |
brlcad |
thinks starseeker should work up a tufte
stylesheet |
| 22:45.22 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.2) |
| 22:46.51 |
starseeker |
brlcad: I
suppose that would kinda be the ultimate "non-default" look
wouldn't it? :-) |
| 22:47.57 |
brlcad |
ultimate? |
| 22:48.19 |
brlcad |
certainly
different, but of a good kind |
| 22:48.23 |
starseeker |
crappy
default vs. Tufte polished :-) |
| 22:48.36 |
brlcad |
ultimate
would be a lot more glossified |
| 22:49.43 |
starseeker |
wonders what we would put in the side columns of a layout
like that... |
| 22:51.22 |
starseeker |
also wonders why the best looking gantt chart he's seen from
an open source tool is a special purpose java tool for boot process
illustration... arrgh |
| 23:05.54 |
Nohla |
holas |
| 23:05.59 |
starseeker |
hola
:-) |
| 23:06.07 |
starseeker |
how goes
it? |
| 23:10.16 |
Nohla |
tired
:P |
| 23:10.46 |
starseeker |
heh -
school? |
| 23:10.59 |
Nohla |
no, life
:) |
| 23:11.15 |
starseeker |
did you find
a projector that would work? |
| 23:11.58 |
Nohla |
I think so,
a friend bought one two months ago |
| 23:12.16 |
Nohla |
maybe I'll
buy the same in the same place |
| 23:12.55 |
Nohla |
It's a good
one and cost the price I can pay |
| 23:15.07 |
starseeker |
crosses his fingers that Microvision actually delivers this:
http://www.microvision.com/showwx/index.html |
| 23:35.53 |
Nohla |
starseeker
thought I thought maybe translate the menu of the program would be
more effective |
| 23:36.07 |
Nohla |
what do you
think? |
| 23:36.46 |
starseeker |
Nohla: that
would be helpful, but you really do need to read the docs to use
BRL-CAD |
| 23:36.50 |
starseeker |
even in
English :-) |
| 23:37.03 |
starseeker |
plus, we
aren't set up to use gettext |
| 23:37.49 |
Nohla |
the most of
people try until learn before to read anything |
| 23:38.10 |
starseeker |
yes, which is
why we don't have more users |
| 23:38.21 |
starseeker |
that doesn't
work with our current interface |
| 23:39.30 |
Nohla |
ok |
| 23:40.07 |
Nohla |
I'll try to
finish the second before next week |
| 23:40.53 |
Nohla |
and third
before my birthday, but I cant promise :P |
| 23:41.16 |
starseeker |
no problem
:-) |
| 23:41.17 |
starseeker |
no
rush |
| 23:42.34 |
Nohla |
fuck, I hate
children, they cry all day!! |
| 23:43.46 |
Nohla |
sorry, you
never expected that from women a woman |
| 23:44.10 |
Nohla |
sorry, you
never expected that from a woman |
| 23:44.59 |
starseeker |
no problem -
stuck with a loud child? |
| 23:45.55 |
Nohla |
my neighbour
:P |
| 23:46.29 |
brlcad |
Nohla:
jaja |
| 23:46.30 |
Nohla |
and his fuckn
backyard |
| 23:47.20 |
Nohla |
starseeker
did you see that PDF has no images again? |
| 23:47.56 |
starseeker |
hmm? which
one? |
| 23:48.15 |
Nohla |
the one in
/lessons/es |
| 23:48.21 |
starseeker |
erm. |
| 23:48.31 |
Nohla |
html is
ok |
| 23:48.44 |
starseeker |
I haven't
checked lately - perhaps I messed it up somehow |
| 23:49.05 |
starseeker |
Nohla: you
are abile to build successfully? |
| 23:49.09 |
starseeker |
able
even |
| 23:49.42 |
Nohla |
yes, brlcad
helped me |
| 23:49.48 |
starseeker |
ah,
excellent |
| 23:49.58 |
starseeker |
I will check
when I get home - this machine doesn't have fop |
| 23:50.29 |
brlcad |
you helped
yourself, I just pointed |
| 23:51.25 |
Nohla |
brlcad that
was a difficul day :P when I ask for some minutes is because I
really need them :P |
| 23:51.45 |
brlcad |
you did
great |
| 23:52.04 |
starseeker |
brlcad: ah,
finally - distcheck passed on my Mac :-) |
| 23:52.23 |
brlcad |
gets the invoice filled out |
| 23:52.36 |
brlcad |
starseeker:
oh, could have told you that mine passed ;) |
| 23:52.37 |
starseeker |
invoice? |
| 23:52.47 |
starseeker |
ah -
hehe |
| 23:52.49 |
brlcad |
gsoc invoice,
finally got the purchase order |
| 23:53.00 |
starseeker |
nods |
| 23:53.14 |
brlcad |
they got
things mixed up the first time around |
| 23:53.20 |
starseeker |
oh,
lovely |
| 23:53.51 |
brlcad |
nothing bad,
just delayed things |
| 23:54.54 |
starseeker |
well, if my
distcheck passes and yours does too, I'm going home :-P |
| 23:55.19 |
starseeker |
maybe next
year I'll manage to do something I won't have to back out within a
week :-/ |
| 23:56.37 |
starseeker |
the problem
of passing local library locations to subconfigure systems I think
remains very real though - the only "correct" solution I can see is
to get TEA and automake to make nice and then send out a bunch of
patches to our favorite src/other libraries |
| 23:57.33 |
Nohla |
starseeker
for the xml there is a maximum character length per
line |
| 23:57.35 |
Nohla |
? |
| 23:57.52 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 23:57.54 |
starseeker |
Nohla: build
system issues |
| 23:58.00 |
starseeker |
Nohla: not
related to docbook |
| 23:58.13 |
starseeker |
oh, you're
asking? |
| 23:58.20 |
Nohla |
yes |
| 23:58.26 |
Nohla |
sorry: is
there |
| 23:59.01 |
starseeker |
not really a
maximum limit, but try to stay around 80 - readable formatting is
more important than max character length |
| 23:59.35 |
starseeker |
drives home, back on later |
| 00:56.19 |
``Erik |
new breakage
in opennurbs, huzzah |
| 01:01.22 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37011
10/brlcad/trunk/src/other/openNURBS/opennurbs_memory.c: try not to
reference things that don't exist |
| 02:19.00 |
starseeker |
blinks - wonder how that compiled on my Mac
then... |
| 02:22.15 |
``Erik |
got me, mebbe
a timestamp issue left the old object file? |
| 02:22.44 |
starseeker |
looks like
that should be p != p, rather than memblock... wonder why they
renamed it |
| 02:22.47 |
starseeker |
ah
well |
| 02:23.06 |
``Erik |
either way,
it's a punt |
| 02:23.34 |
starseeker |
hmm? I
thought Sean threw that into the old code base |
| 02:23.42 |
``Erik |
probably an
'unused variable' hack |
| 02:24.00 |
starseeker |
will it cause
you breakage either way? |
| 02:24.12 |
starseeker |
yeah, it was
warning quellage |
| 02:25.09 |
``Erik |
if it were
return p != p; it woulda been fine... did you upgade the existing
code with a patch? |
| 02:25.30 |
starseeker |
nah, just
didn't check carefully enough whether that variable name had
changed |
| 02:25.35 |
starseeker |
my
bad |
| 02:26.15 |
``Erik |
okie, allz I
saw was an error about an undefined variable, didn't turn on strict
flags |
| 02:26.18 |
CIA-38 |
BRL-CAD:
03starseeker * r37012 10/brlcad/trunk/src/other/openNURBS/
(BRL-CAD_changes.txt opennurbs_memory.c): Er, whoops - thanks Erik.
p != p might work better when the variable name changed to
p... |
| 02:26.38 |
``Erik |
kinda care
more about mged getting the BadAlloc... rt -F/dev/Xl works
fine |
| 02:26.41 |
starseeker |
``Erik:
actually a lot of our changes disappeared |
| 02:27.00 |
starseeker |
was more
concerned about minimizing our changes to openNURBS without
breaking the raytracer |
| 02:27.06 |
starseeker |
yeah |
| 02:27.20 |
starseeker |
pulls the libdm logs for the last few
weeks... |
| 02:27.35 |
starseeker |
mged is kinda
foobared at the moment |
| 02:28.12 |
``Erik |
actually, at
the moment, I care more about reading a webcomic and being a cat
matress, but *shrug* :) |
| 02:28.19 |
starseeker |
heh |
| 02:28.31 |
starseeker |
hopes like hell it wasn't his libdm
changes |
| 02:29.04 |
``Erik |
it's been
doing it for a bit, I figured one of ya'll messing with that tsuff
woulda noticed it, all my work has been lower level |
| 02:29.08 |
starseeker |
oh, it might
be r36844 |
| 02:29.23 |
``Erik |
g2asc/asc2g,
adrt, and librt crud |
| 02:29.27 |
starseeker |
come to think
of it I remember something about that |
| 02:29.49 |
``Erik |
which is
about as close to mged as I care to mess... still have flashbacks
about edsol.c |
| 03:01.09 |
CIA-38 |
BRL-CAD:
03starseeker * r37013 10/brlcad/trunk/src/libdm/dm-X.c: Back out
some dm-X changes causing breakage on Mac and Linux platforms -
trying to preserve some of the more recent changes to drawLine3d
functions. |
| 03:12.05 |
``Erik |
whuddya know,
mged starts up now :D |
| 03:31.00 |
CIA-38 |
BRL-CAD:
03starseeker * r37014 10/brlcad/trunk/src/librt/ (3 files in 3
dirs): |
| 03:31.00 |
CIA-38 |
BRL-CAD:
Compile gotchas on gentoo - FALSE returning as not defined in a
couple files - |
| 03:31.00 |
CIA-38 |
BRL-CAD:
looks like this was coming in from opennurbs and is gone with the
latest update |
| 03:31.00 |
CIA-38 |
BRL-CAD: -
just go with 0; also include assert.h in brep.cpp since it's not
getting |
| 03:31.00 |
CIA-38 |
BRL-CAD:
pulled in through opennurbs any more. |
| 03:58.59 |
CIA-38 |
BRL-CAD:
03starseeker * r37015 10/brlcad/trunk/src/proc-db/ (5 files): FALSE
and assert.h tweaks for proc-db |
| 04:04.46 |
*** join/#brlcad talcite
(n=matthew@69-196-132-129.dsl.teksavvy.com) |
| 04:27.37 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 04:58.53 |
*** join/#brlcad Nohla
(n=jesica@201.255.220.253) |
| 05:25.43 |
*** join/#brlcad talcite_
(n=matthew@69-196-180-185.dsl.teksavvy.com) |
| 06:08.22 |
starseeker |
blinks - well, rtgl -> ogl -> rtgl and rtgl -> X
-> rtgl both just succeeded on gentoo |
| 06:11.07 |
starseeker |
and we've got
a nurbs raytrace |
| 06:11.30 |
starseeker |
aaaand
csgbrep barfs |
| 10:06.12 |
*** join/#brlcad docelic
(n=docelic@78-2-80-119.adsl.net.t-com.hr) |
| 11:24.09 |
*** join/#brlcad csanyipal
(n=csanyipa@132-142-85-95.dynamic.stcable.net) |
| 11:24.15 |
csanyipal |
Hi, |
| 11:25.19 |
csanyipal |
When I
install brlcad from SVN must I delete first the /usr/brlcad
directory? |
| 11:25.31 |
csanyipal |
the system is
Debian GNU/Linux Lenny. |
| 11:42.43 |
csanyipal |
When run
'make' after './configure --enable-optimized', |
| 11:42.50 |
csanyipal |
I get error
messages: |
| 11:43.01 |
csanyipal |
make[2]: ***
[region_end.lo] Error 1 |
| 11:43.01 |
csanyipal |
make[2]:
Leaving directory
`/debian-adatok-1/CAD/BRL-CAD/SVN/brlcad/src/libgcv' |
| 11:43.01 |
csanyipal |
make[1]: ***
[all-recursive] Error 1 |
| 11:43.01 |
csanyipal |
make[1]:
Leaving directory
`/debian-adatok-1/CAD/BRL-CAD/SVN/brlcad/src' |
| 11:43.02 |
csanyipal |
make: ***
[all-recursive] Error 1 |
| 11:43.11 |
csanyipal |
Any
solutions? |
| 11:44.30 |
docelic |
csanyipal,
you didn't paste the actuall errors |
| 11:44.48 |
csanyipal |
docelic:
? |
| 11:45.07 |
csanyipal |
region_end.c:
In function âgcv_region_endâ: |
| 11:45.07 |
csanyipal |
region_end.c:38: error: argument
âcurtreeâ might be clobbered by âlongjmpâ or
âvforkâ |
| 11:45.28 |
docelic |
that is the
real error. |
| 11:45.52 |
csanyipal |
docelic:
thanks. How can I resolve it? |
| 11:47.54 |
docelic |
don't know
about this one, see Google for "might be clobbered by". Also, (my
guess), I think this is usually a warning, which is an error here
because of some compile options which say to treat all warnings as
errors. So if you can't solve it, maybe you can tell ./configure to
not treat warnings as errors, and it'll go forwarsd |
| 11:48.29 |
csanyipal |
docelic:
thanks! :) |
| 11:48.31 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
| 13:15.18 |
*** join/#brlcad docelic_
(n=docelic@78-2-80-2.adsl.net.t-com.hr) |
| 14:22.35 |
``Erik |
that's from
strict flags, turn'em off and it'll compile |
| 14:38.40 |
csanyipal |
``Erik: how
can I turn'em off? |
| 14:41.38 |
csanyipal |
Can I do this
with --disable-warnings ? |
| 14:41.45 |
starseeker |
I think it's
--disable-strict |
| 14:41.58 |
starseeker |
although
brlcad might have changed it - give that a try |
| 14:42.13 |
csanyipal |
starseeker:
ok. |
| 14:47.08 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37016 10/brlcad/trunk/src/libgcv/Makefile.am:
forcibly disable strict flags until the jump clobber issue can be
sorted out. |
| 14:50.11 |
csanyipal |
CIA-38: does
this line: 'r37016...' mean that I can checkout again SVN and try
to compile?? |
| 14:51.11 |
starseeker |
yes |
| 14:51.12 |
``Erik |
CIA is a bot
that reports commits |
| 14:51.24 |
csanyipal |
ok |
| 15:30.45 |
csanyipal |
I run make
successfully, now I run make benchmark. |
| 15:32.25 |
csanyipal |
make
benchmark is comlpete now. |
| 15:32.59 |
csanyipal |
I'm send now
the benchmakr results to benchmark@brlcad.org. |
| 15:33.58 |
``Erik |
you did use
--enable-optimized on yoru configure, correct? |
| 15:34.35 |
csanyipal |
I did the
following: |
| 15:34.37 |
csanyipal |
./configure
--enable-optimized |
| 15:34.42 |
csanyipal |
make
-j2 |
| 15:34.48 |
csanyipal |
make
benchmark |
| 15:34.52 |
csanyipal |
so
far. |
| 15:34.55 |
``Erik |
ok, good,
then you have good numbers |
| 15:35.15 |
csanyipal |
yes:
Benchmark results indicate an approximate VGR performance metric of
4614 |
| 15:35.24 |
csanyipal |
Logarithmic
VGR metric is 3,66 (natural logarithm is 8,44) |
| 15:37.33 |
csanyipal |
I have send
the benchmark results to benchmark@brlcad.org. |
| 15:38.21 |
csanyipal |
Before sudo
make install should I delete the /usr/brlcad directory? |
| 15:39.43 |
csanyipal |
or it will be
overwritten during installation? |
| 15:40.00 |
csanyipal |
I have an old
brlcad installation here. |
| 15:40.43 |
csanyipal |
I think it's
better to delete this directory, isn't? |
| 15:51.31 |
csanyipal |
I have
installed now brlcad. Just to find out how to setup PATH so I can
run on xterm (urxvt) the 'mged' command. |
| 15:52.02 |
csanyipal |
I'm using
Window Maker window manager with gdm. |
| 15:52.24 |
csanyipal |
thank you for
help! |
| 15:53.14 |
*** join/#brlcad talcite_
(n=matthew@69-196-180-185.dsl.teksavvy.com) |
| 16:20.26 |
*** join/#brlcad csanyipal
(n=csanyipa@132-142-85-95.dynamic.stcable.net) |
| 16:27.42 |
*** join/#brlcad csanyipal
(n=csanyipa@132-142-85-95.dynamic.stcable.net) |
| 17:41.31 |
brlcad |
volks, can
disable strict with: make STRICT_FLAGS= |
| 17:41.39 |
brlcad |
don't have to
reconfigure |
| 17:41.57 |
brlcad |
otehrwise,
reconfigure with --disable-strict should shut it off
too |
| 17:42.27 |
csanyipal |
oh |
| 17:43.59 |
brlcad |
csanyipal: no
worries for you, you have a build :) |
| 17:44.14 |
brlcad |
turning it
off in the Makefile.am works too, which is what that commit
did |
| 17:44.14 |
csanyipal |
of course..
:) |
| 17:44.52 |
brlcad |
you don't
have to set path if you don't want to, just have to write the whole
path: /usr/brlcad/bin/mged |
| 17:45.15 |
brlcad |
otherwise for
bash: export PATH=/usr/brlcad/bin:$PATH |
| 17:45.24 |
csanyipal |
i have set ip
up now in .bashrc |
| 17:45.30 |
brlcad |
nods |
| 17:45.33 |
csanyipal |
set it
up |
| 17:45.53 |
brlcad |
merry
christmas and thanks :) |
| 17:46.05 |
csanyipal |
ok
:) |
| 17:46.52 |
csanyipal |
merry
christmas for all of you here too! |
| 19:28.24 |
*** join/#brlcad csanyipal
(n=csanyipa@132-142-85-95.dynamic.stcable.net) |
| 20:13.05 |
starseeker |
hmm. csgbrep
works on the mac |
| 20:13.29 |
starseeker |
boy gentoo is
unforgiving when it comes to this stuff... |
| 20:13.34 |
starseeker |
which is a
good thing I guess |
| 20:16.11 |
*** join/#brlcad csanyipal
(n=csanyipa@132-142-85-95.dynamic.stcable.net) |
| 20:27.50 |
yukonbob |
Merry
[almost] Christmas, #brlcad. |
| 20:30.19 |
starseeker |
brlcad:
wonder if it would be worth checking if Archer works with the itcl
4.0b3 code? looks like that version of itcl has been crafted to
play nice with the new TclOO stuff |
| 20:35.04 |
yukonbob |
starseeker:
iirc, itcl-ng (i.e. 4.x) is _not_ really ready. I'd have to surf
around to find reference... |
| 20:35.32 |
starseeker |
http://wiki.tcl.tk/19873 is what I
was looking at... |
| 20:36.42 |
yukonbob |
I'm reviewing
same, atm... |
| 20:40.12 |
yukonbob |
I forget
where I saw it (avoid itcl-ng), but it stuck in my mind. The choice
of BRL-CAD to dig into Tcl8.5b, and the itcl-ng, etc., caused a lot
of churn on my system, which I still haven't actually recovered
from. Picking proper itcl was on my List of Things, and like I
said, iirc (I should have kept better notes) itcl-ng is -not- the
way to go (atm). |
| 20:41.26 |
starseeker |
what churn
did it cause? |
| 20:42.15 |
starseeker |
we're going
to want tcl/tk 8.6 - among other things, their Aqua support on the
mac will be targeting Cocoa itself |
| 20:42.31 |
starseeker |
dunno if itcl
3.x can work on 8.6 |
| 20:51.47 |
yukonbob |
starseeker:
at the time (a while ago), brl-cad required a beta tcl/tk; on
NetBSD, I had setup the brl-cad distribution to build only the
minimal requirements and use pre-installed pkgs for
rest... |
| 20:52.08 |
yukonbob |
(i.e. use
pre-existing tcl, tk, utah, etc., etc) |
| 20:52.35 |
yukonbob |
not having
the beta tcl/tk threw that into a tailspin, until I got everything
working w/ 8.4 again... |
| 20:53.13 |
yukonbob |
anyway, long
story short, I didn't stay caught-up, and now don't have a working
brl-cad using in-system pkgs, which is the way I'm trying to pursue
the install... |
| 20:53.38 |
yukonbob |
I haven't had
time to dedicate to sovling as I did in past either :P |
| 20:54.02 |
yukonbob |
8.6 is still
a way out, from my understanding talking w/ coreteam. |
| 20:57.10 |
starseeker |
ah, yes -
on-system packaging is a problem |
| 20:57.40 |
yukonbob |
I had it
solved, but that was some time ago. |
| 20:57.50 |
starseeker |
or can be
rather |
| 20:57.57 |
yukonbob |
It's my holy
grail to reattain that |
| 20:58.04 |
yukonbob |
then try to
maintain. |
| 20:58.32 |
starseeker |
archer is now
using the new ttk widgets, so the minimum system tk will need to
support those |
| 20:58.59 |
yukonbob |
8.5 == ttk,
and indeed, I believe 8.4 has ttk as a package.... |
| 20:59.10 |
yukonbob |
"tile" |
| 20:59.29 |
starseeker |
yes, but I
can't remember if tile uses the ttk prefix |
| 20:59.39 |
yukonbob |
neither |
| 21:00.08 |
starseeker |
the ttk
widgets are a considerable improvement in the visual appearance
department |
| 21:00.09 |
yukonbob |
tcl/tk == the
stuff I'm pretty familiar with -- indeed, it was the vector that
led me to brl-cad ;) |
| 21:00.17 |
yukonbob |
starseeker:
yup |
| 21:00.44 |
yukonbob |
and native OS
X will be really nice, too. 8.6 is certainly going to bring even
more goodness to tcl |
| 21:00.49 |
starseeker |
must become familiar - the time has come for a working Tk
display manager and frame buffer |
| 21:01.15 |
starseeker |
yukonbob: do
you happen to be familiar with togl? |
| 21:02.32 |
yukonbob |
starseeker:
short answer: no |
| 21:02.55 |
starseeker |
bemusedly watches the tk display manager crash in X11 Tk on
the mac where it (sort) worked under Aqua |
| 21:04.20 |
starseeker |
yukonbob: I
have a tendency to wander down the "ooo this is an interesting
Tcl/Tk library" path |
| 21:05.04 |
yukonbob |
starseeker:
there are a fscking tonne of them out there... |
| 21:05.18 |
starseeker |
yukonbob: my
current "ooo shiny" fixations are on togl and
RamDebugger |
| 21:05.19 |
yukonbob |
it's an
interesting path, and I can relate to you in that regard
;) |
| 21:05.36 |
yukonbob |
?ramdebugger |
| 21:05.51 |
starseeker |
http://www.compassis.com/ramdebugger |
| 21:07.16 |
yukonbob |
http://wiki.tcl.tk/17771 |
| 21:08.01 |
starseeker |
I've yet to
get and BRL-CAD running successfully in the same bwish session, but
friendly Tcl debugging would be nice... |
| 21:08.12 |
starseeker |
ah yes, tcl3d
:-) |
| 21:08.23 |
starseeker |
they even
have an osg binding, iirc |
| 21:08.39 |
yukonbob |
ramdebugger
looks neat. |
| 21:09.09 |
starseeker |
main concern
I had with tcl3d is how portable it is |
| 21:09.12 |
yukonbob |
usually uses some kind of introspection, [puts], and gdb, all
in XEmacs |
| 21:09.28 |
starseeker |
I think it
tcl3d sucks in togl, actually... |
| 21:09.43 |
yukonbob |
re:
portability: /me nods -- no idea. |
| 21:10.14 |
starseeker |
yukonbob: my
ideal would be to have RamDebugger fire up on an Archer Tcl/Tk
error, politely pointing me to the offending source code line
:-0 |
| 21:10.41 |
starseeker |
dunno if it's
any good, but non-commercial solutions in that space seem to be
rather thin on the ground |
| 21:12.17 |
starseeker |
hmm - tcl3d
sucks in gl2ps as well |
| 21:12.21 |
starseeker |
interesting |
| 21:12.37 |
yukonbob |
I guess it
depends on what kind of errors are tripping you up, but my
experience has led me to [puts], gdb, xemacs |
| 21:13.03 |
yukonbob |
that, and
familiarity w/ Tcl and good practices, which only come w/
use. |
| 21:13.18 |
starseeker |
ah, that's
what made me wary of tcl3d - their swig files |
| 21:13.30 |
yukonbob |
you don't
like swig? |
| 21:13.55 |
starseeker |
wary of
depending on it for key functionality - adds a core dependency on a
translation tool |
| 21:14.28 |
starseeker |
might be the
best/only way to do some things though |
| 21:15.03 |
starseeker |
yukonbob:
with mged though, we have the option of talking directly to C apis
insteadl of tcl scripting |
| 21:15.44 |
starseeker |
Archer is tcl
scripting at the moment on top of wish, classic Tcl/Tk app - we're
planning to make it run on top of its own C core the way mged
does |
| 21:15.54 |
yukonbob |
nods |
| 21:16.58 |
yukonbob |
I'll try to
make another push to get brl-cad running on my system (7.16.2) and
start helping out again. |
| 21:17.05 |
starseeker |
obviously you
can do tcl scripts in MGED as well - there are many examples - but
it lets us build the core levels at the C level (see libdm and
libfb :-) |
| 21:17.20 |
starseeker |
yukonbob:
cool! sounds great |
| 21:17.30 |
yukonbob |
used tcl extensively with mged. |
| 21:17.31 |
starseeker |
is the stable
Tcl/Tk up to 8.5 now? |
| 21:17.36 |
yukonbob |
yup |
| 21:17.47 |
starseeker |
that should
make life simpler |
| 21:18.31 |
yukonbob |
8.6 Real Soon
Now, but like I said, the understanding is it's a way in the future
still... for a while, they were hoping to have it out of beta
before Tcl Conference in Oregon in Sept; obviously didn't happen,
and it's being pushed further and further out... |
| 21:18.36 |
yukonbob |
which I
actually don't mind too much. |
| 21:19.14 |
starseeker |
as far as I
know there are no "must have today!" features in 8.6 for BRL-CAD
the way there were for 8.5 with ttk |
| 21:19.35 |
yukonbob |
starseeker:
re: simple life --- indeed. incr tcl/tk on my NetBSD were (are) an
issue that I need to solve, and then push through the ./configure
and getting brl-cad to recognize that stuff I'm offering to it so
it doesn't build own utah, tcl, tk, etc., etc. |
| 21:20.39 |
yukonbob |
starseeker:
nice -- that'll help me push if I know it's results will last a
while before having to rework for 8.6 ;) |
| 21:21.46 |
yukonbob |
I'll see what
i can muster, and start bugging #brlcad for issues I run into to
get this up/running. |
| 21:21.53 |
yukonbob |
misses modelling :P |
| 21:22.14 |
starseeker |
<snort>
given how long it looks to be before 8.6 is out, we'd better hope
there are no necessary features... |
| 21:22.35 |
yukonbob |
"necessary"
is a state of mind |
| 21:22.40 |
yukonbob |
there are
some neat things. |
| 21:23.05 |
yukonbob |
in-core OO,
in-core database abstraction, NRE (non-recursive
engine) |
| 21:23.12 |
yukonbob |
co-routines, |
| 21:23.24 |
yukonbob |
it's getting
more lisp-y all the time. |
| 21:23.43 |
starseeker |
yukonbob: if
8.6 lets us run MGED and Archer in Aqua mode on the Mac and 8.5
doesn't (for whatever reason) I'd call that "necessary", but we
could probably conditionalize for an Aqua build to demand 8.6 in
that case |
| 21:24.32 |
starseeker |
in core OO
would be nice, but that would require reworking our EXTENSIVE use
of incrTcl throughout Archer to target TclOO |
| 21:24.40 |
starseeker |
I believe the
word for that is "eek" |
| 21:25.38 |
yukonbob |
starseeker:
I'm not clear on the implications of Tk rendering on OS X;
look/feel, I guess, and not having to hack together look-alikes,
because instead one simply uses native will reduce work on Tcl core
team, and maybe(?) enhance end-users' experience, but otherwise,
tcl/tk still work on OS X... |
| 21:26.01 |
yukonbob |
re: in-core
OO |
| 21:26.18 |
yukonbob |
<PROTECTED> |
| 21:26.38 |
yukonbob |
they are more
low-level primitives that a user-facing OO system can
use. |
| 21:26.50 |
starseeker |
Tk rendering
on OSX let's us run MGED and friends without needing an X11 server.
X11 on the Mac has been a little tempremental |
| 21:27.13 |
yukonbob |
and they'll
be common and standardized, so incr tcl can use, as well as snit,
or any of other myriad OO systems can take advantage
of. |
| 21:27.40 |
starseeker |
if we can get
native libdm and libfb code in Tk, we can ditch X11 on the Mac
completely and sidestep all the bugs :-) |
| 21:27.42 |
yukonbob |
does one
currently need X11 to get a Tk window up on a mac? |
| 21:27.49 |
starseeker |
yes |
| 21:27.53 |
yukonbob |
hrm. |
| 21:28.14 |
yukonbob |
well, that's
be a very nice side effect. |
| 21:28.26 |
yukonbob |
(getting rid
of X11 on Mac) |
| 21:28.31 |
starseeker |
at least, if
you want properly working display manager and any sort of
raytracing ;-) |
| 21:28.39 |
yukonbob |
anyway -- I
should get back to my own coding. |
| 21:28.59 |
starseeker |
8.5 does
indeed build aqua, only questions are stability, performance,
etc. |
| 21:29.01 |
starseeker |
cool |
| 21:29.02 |
yukonbob |
...and I'll
take another stab at brl-cad on my system and see if I can get it
up/running agin. |
| 21:29.15 |
starseeker |
Merry
Christmas, and good luck! |
| 21:29.28 |
starseeker |
needs to get outta here... |
| 21:29.32 |
yukonbob |
thx :) Merry
Christmas to you too. |
| 21:29.42 |
yukonbob |
ttyl
starseeker |
| 21:33.56 |
starseeker |
ah yes,
tkpath... http://tclbitprint.sourceforge.net/tkpath/quartz/index.html
:-) |
| 21:34.06 |
starseeker |
gotta be some
fun to be had there... |
| 21:37.54 |
starseeker |
or
tkzinc |
| 21:38.14 |
starseeker |
stops himself and runs |
| 22:09.30 |
*** join/#brlcad talcite
(n=matthew@CPE00131078af68-CM001225ddf578.cpe.net.cable.rogers.com) |
| 22:11.47 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 22:40.15 |
talcite |
brlcad: do we
have a mailing list? |
| 22:49.03 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
| 00:01.03 |
brlcad |
I'm actually
supposed to be driving off to see family for the next couple days,
driving for 8 hours tomorrow, so I probably won't be online
much |
| 00:01.17 |
brlcad |
but you can
certainly post here and ask, someone is bound to answer
:) |
| 00:01.41 |
brlcad |
i'll be on
early morning and probably later in the night after I arrive at my
destination |
| 00:02.06 |
Nohla |
well I'll try
harder :) |
| 00:07.58 |
``Erik |
heh, not
gonna pull the iphone ssh while driving r-tardedness?
:) |
| 00:59.36 |
*** join/#brlcad talcite
(n=matthew@76-10-132-196.dsl.teksavvy.com) |
| 01:21.43 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 01:27.36 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 02:23.30 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad Nohla (n=jesica@168.226.176.17) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad stevegt` (n=stevegt@cislunar.TerraLuna.Org)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad indianlarry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 02:23.30 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 02:23.30 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 02:23.31 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 03:48.53 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1242310321.dsl.bell.ca) |
| 04:24.03 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1242310321.dsl.bell.ca) |
| 04:32.22 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 05:18.30 |
*** join/#brlcad jesica__
(n=jesica@168.226.179.243) |
| 05:48.59 |
brlcad |
nay |
| 06:52.52 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331819.dsl.bell.ca) |
| 08:05.44 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.50) |
| 08:06.19 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1242309791.dsl.bell.ca) |
| 14:28.03 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 15:22.35 |
Nohla |
Is anybody
out there? starseeker? ``Erik? |
| 15:24.26 |
Nohla |
wanted to
know if it still exists:"You can also zoom in or out on your design
by going to the View menu and selecting Zoom In or Zoom Out. A
drawback to this method is that you can only zoom in or out one
time because the drop-down menu closes once you make a
selection." |
| 15:24.49 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 15:26.28 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 15:37.36 |
``Erik |
hm, it should
still be there... gimme a minute to look |
| 15:38.22 |
``Erik |
ayup, it
is... do you have mged installed? |
| 15:39.07 |
Nohla |
nop
:( |
| 15:39.17 |
Nohla |
sorry, always
say the same |
| 15:39.29 |
``Erik |
(sorry, ayup
= yes. That functionality still exists) |
| 15:40.36 |
Nohla |
I'm asking
for the drawback, not for the function |
| 15:41.13 |
``Erik |
oh, yes, it
does close the dropdown menu when it takes effect. There is no way
to change that behavior, it's part of being a dropdown
menu |
| 15:41.42 |
Nohla |
but with a
shortcut, maye |
| 15:41.47 |
Nohla |
maybe |
| 15:41.49 |
``Erik |
you can zoom
out, then click view again and choose it again and it'll work, but
you have to keep clicking 'view' between each zoom |
| 15:43.05 |
Nohla |
shift grips
is the same as chortcut and kaystrokes? |
| 15:43.40 |
``Erik |
I don't know
O.o I'm not a GUI person :) |
| 15:44.44 |
``Erik |
http://brlcad.org/wiki/Image:Shift_Grips_Quick_Reference_Guide.pdf
looks like shift-grips are mouse motion events with a modifier key
pressed |
| 15:44.52 |
``Erik |
like holding
shift or control while you click and drag |
| 15:45.55 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 15:47.20 |
Nohla |
``Erik
thanks |
| 15:48.25 |
``Erik |
np, glad I
was able to help (my focus is lower level stuff, not user
interfaces) |
| 15:49.02 |
Nohla |
it's perfect
if you understand the matrix :) |
| 15:49.22 |
``Erik |
installing
BRL-CAD to try things out may help in the translation process...
being able to try it to see if your reading is correct before
re-expressing it? :) just a thought |
| 15:50.40 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 16:01.32 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.50) |
| 16:02.02 |
Nohla |
sorry, I fell
down |
| 16:02.31 |
Nohla |
to install it
I need to free up disk space before |
| 16:03.08 |
``Erik |
ah, I have
similar issues on my 'server' |
| 16:03.25 |
``Erik |
it's about
265 megabytes on my mac |
| 16:04.13 |
``Erik |
hm, one of my
bsd machines has a 115m dir |
| 16:06.44 |
``Erik |
do you have
perhaps a school server you could install it to, and then use
remote X to run it? |
| 16:09.33 |
``Erik |
grumbles because some eggshell broke into his
food |
| 16:10.48 |
Nohla |
``Erik that's
possible, but I'll ask for it in February |
| 16:11.15 |
Nohla |
We're on
vacation :) |
| 16:12.30 |
``Erik |
*shrug* I was
thinking that perhaps you had an account that could do it and could
just ssh in :) the other options are getting a new hard drive (or
thumb drive) which is expensive money wise, or doing hard drive
housecleaning (removing unused packages, deleting unused files,
etc) which is time consuming |
| 16:13.19 |
``Erik |
I don't have
a server to offer, but brlcad may *shrug* |
| 16:14.21 |
Nohla |
I have no
problem because I have a lot of music that I can burn on
dvd |
| 16:14.55 |
Nohla |
I like the
idea for the others students |
| 16:15.21 |
``Erik |
remote X is
sensitive to latency |
| 16:16.14 |
Nohla |
mmm... and it
means... ? |
| 16:16.20 |
``Erik |
dial-up makes
it very difficult to use |
| 16:16.45 |
``Erik |
when I did
remote-X stuff on dialup, I would move the mouse, and half a second
later, the cursor would move...very difficult to use |
| 16:17.19 |
Nohla |
mmm, will see
the best way of make it popular :) |
| 16:17.39 |
``Erik |
local of fast
network is best |
| 16:17.49 |
``Erik |
local or fast
network is best |
| 16:18.20 |
Nohla |
at the end of
the translation of the tutorials and menus, the idea was to make a
seminar |
| 16:18.54 |
``Erik |
does the
classroom have 100baseT to all the machines? that makes it
acceptable to do remote, provided the server can handle the
load |
| 16:19.14 |
``Erik |
imagine 30
people running a raytrace at the same time on a machine :) that'd
not be fun |
| 16:19.29 |
Nohla |
let me see
the reality of the laboratory material before |
| 16:20.11 |
``Erik |
of course,
I'm just rambling to explore possibilities |
| 16:20.12 |
Nohla |
I trust that
with time we can do a nice job with this |
| 16:20.44 |
Nohla |
you are
always one step further:) |
| 16:20.51 |
``Erik |
"the plan is
useless; it's the planning that is important"
-Eisenhower |
| 16:21.34 |
Nohla |
we do
:) |
| 16:22.30 |
Nohla |
the planning
stage is always very short |
| 16:22.49 |
Nohla |
we just need
to seek that stage :) |
| 16:23.33 |
Nohla |
but I told
brlcad yesterday, I'm in |
| 16:23.55 |
``Erik |
excellent
:) |
| 16:24.44 |
Nohla |
I know very
little, but I do my best |
| 16:25.02 |
``Erik |
<-- been
thinking about modelling his house in BRL-CAD to experiment with
furniture placement and using photon mapping (or converting to bots
and using adrt's path tracing) to get a good idea of appearance
before buying furniture and stuff |
| 16:25.19 |
``Erik |
'sok, I know
very little, I just make a good act of it |
| 16:26.03 |
Nohla |
:) |
| 16:26.55 |
*** part/#brlcad Nohla
(n=jesica@168.226.179.50) |
| 16:27.03 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.50) |
| 16:28.09 |
``Erik |
you seem to
be falling off the internet a lot, too many cerveza? :D |
| 16:28.20 |
``Erik |
nohla: did
you get my private message? |
| 17:21.14 |
*** join/#brlcad __monty__
(n=toon@153.60-65-87.adsl-dyn.isp.belgacom.be) |
| 18:34.43 |
CIA-38 |
BRL-CAD:
03brlcad * r37019 10/brlcad/trunk/bench/run.sh: |
| 18:34.43 |
CIA-38 |
BRL-CAD:
include sysctl hardware information in the output log after uname,
collapsing |
| 18:34.43 |
CIA-38 |
BRL-CAD: all
lines into just one. also add additional tests to make sure the
scripts and |
| 18:34.43 |
CIA-38 |
BRL-CAD:
binaries we're about to use actually work before putting them to
use. |
| 18:36.25 |
CIA-38 |
BRL-CAD:
03brlcad * r37020 10/brlcad/trunk/NEWS: |
| 18:36.25 |
CIA-38 |
BRL-CAD: the
benchmark suite now includes sysctl hardware information in the log
output. |
| 18:36.25 |
CIA-38 |
BRL-CAD: I
was manually asking everyone for this information anyways, so it's
good to |
| 18:36.25 |
CIA-38 |
BRL-CAD: just
have it automatically included in the log. still would be nice to
get a |
| 18:36.25 |
CIA-38 |
BRL-CAD: copy
of /proc/cpuinfo if it's a linux system, though. |
| 18:38.53 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1242309791.dsl.bell.ca) |
| 18:41.47 |
``Erik |
sysctl is a
very system specific thing, I had to write significantly different
sysctl thingies for fbsd vs netbsd vs obsd vs solaris vs what
little linux supports |
| 18:41.56 |
``Erik |
there's no
universal OID heirarchy :( |
| 18:43.01 |
``Erik |
oh, hah,
you're grabbing the entire hw tree |
| 18:45.09 |
brlcad |
which is nfg
on linux |
| 18:45.44 |
``Erik |
I should put
my old perfmon crap out under a bsd or lgpl license so it can be
nom'd |
| 18:46.02 |
``Erik |
how was the
drive? |
| 18:46.27 |
``Erik |
get to open
ellie up a bit on the no-mans-land bits? |
| 18:48.14 |
``Erik |
(solaris and
osX are of the BSD world, which is migrating its own way... sysctl
heavy... linux is off in the corner drooling on itself and wearing
a cone hat, not surprised it's not even close to
'normal') |
| 19:05.45 |
CIA-38 |
BRL-CAD:
03brlcad * r37021 10/brlcad/trunk/bench/run.sh: |
| 19:05.45 |
CIA-38 |
BRL-CAD:
restructure the output so that system configuration information is
included at |
| 19:05.45 |
CIA-38 |
BRL-CAD: the
end of the log instead of the beginning. that also lets us preserve
the |
| 19:05.45 |
CIA-38 |
BRL-CAD:
sysctl formatting and include the verbose /proc/cpuinfo details if
they are |
| 19:05.45 |
CIA-38 |
BRL-CAD:
available. we do this quietly only because it's so much output, but
still let |
| 19:05.47 |
CIA-38 |
BRL-CAD: the
user know that additional information was added to the
log. |
| 19:08.27 |
CIA-38 |
BRL-CAD:
03brlcad * r37022 10/brlcad/trunk/bench/run.sh: oops, CMP not
PIXCMP |
| 19:37.08 |
CIA-38 |
BRL-CAD:
03brlcad * r37023 10/brlcad/trunk/bench/run.sh: emphasize
submitting results, include an approx VGR result on a 16 core xeon
instead of the 8 cpu aix that had a 9k vgr. |
| 20:06.32 |
*** join/#brlcad csanyipal
(n=csanyipa@76-142-85-95.dynamic.stcable.net) |
| 20:06.40 |
csanyipal |
Hi, |
| 20:08.25 |
csanyipal |
brlcad: I
just sent in e-mail the outputs of 'sysctl -a' and 'cat
/proc/cpuinfo' commands. |
| 20:20.09 |
brlcad |
cool,
thanks |
| 20:21.50 |
csanyipal |
brlcad: you
are welcome! |
| 20:36.23 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14BC23.dip.t-dialin.net) |
| 20:59.09 |
brlcad |
perfect |
| 20:59.45 |
csanyipal |
:) |
| 21:16.06 |
csanyipal |
I have a
build fom SVN and when I try to open in Archer an existing geometry
file, Archer crash and disappeare. |
| 21:17.24 |
csanyipal |
Segmentation
fault.. |
| 21:18.22 |
brlcad |
csanyipal:
hm, do you have a stack trace |
| 21:18.26 |
brlcad |
or rather,
can you get one? |
| 21:18.40 |
csanyipal |
how can I get
one? |
| 21:18.44 |
brlcad |
hm |
| 21:19.20 |
brlcad |
run archer ..
then before opening the file, attach to the process with
gdb |
| 21:19.47 |
brlcad |
should be
able to get the process id via "ps auxwww|grep bwish" |
| 21:19.48 |
csanyipal |
I never did
this before.. |
| 21:19.53 |
brlcad |
no
problem |
| 21:20.07 |
brlcad |
first step:
run archer ;) |
| 21:20.18 |
csanyipal |
ok |
| 21:20.29 |
csanyipal |
done. |
| 21:20.41 |
brlcad |
then run "ps
auxwww|grep bwish" in a terminal |
| 21:20.49 |
brlcad |
what does it
report? |
| 21:21.01 |
csanyipal |
1000
10154 4.4 0.9 268196 19408 ? Ss 22:20 0:01
/usr/brlcad/bin/../bin/bwish /usr/brlcad/bin/archer |
| 21:21.01 |
csanyipal |
1000
10161 0.0 0.0 4856 780 pts/0 S+ 22:20 0:00 grep
bwish |
| 21:21.18 |
brlcad |
greap, so
10154 is the process id for archer |
| 21:21.23 |
brlcad |
great* |
| 21:21.25 |
csanyipal |
o |
| 21:21.27 |
csanyipal |
ok |
| 21:21.32 |
brlcad |
now run
"gdb" |
| 21:21.40 |
csanyipal |
done |
| 21:21.41 |
brlcad |
then in gdb
run "attach 10154" |
| 21:21.54 |
csanyipal |
done |
| 21:22.00 |
brlcad |
then
"continue" |
| 21:22.13 |
brlcad |
then go back
to archer, and make it crash |
| 21:22.18 |
csanyipal |
Continuing. |
| 21:22.51 |
brlcad |
once it
crashes, go back to gdb and run "backtrace" |
| 21:22.52 |
csanyipal |
done |
| 21:22.58 |
csanyipal |
Program
received signal SIGSEGV, Segmentation fault. |
| 21:22.58 |
csanyipal |
[Switching to
Thread 0xa893a6c0 (LWP 10154)] |
| 21:22.58 |
csanyipal |
0xb7f35f00 in
bu_calloc@plt () from /usr/brlcad/lib/libtclcad.so.19 |
| 21:22.58 |
csanyipal |
Current
language: auto; currently asm |
| 21:23.25 |
csanyipal |
Archer are
hanging now.. |
| 21:23.32 |
csanyipal |
is.. |
| 21:23.45 |
brlcad |
right, from
here on archer is dead |
| 21:23.56 |
brlcad |
until you
tell gdb to detach, it's just frozen |
| 21:24.03 |
brlcad |
"backtrace"
? |
| 21:24.49 |
brlcad |
run that
command in gdb |
| 21:24.55 |
csanyipal |
done
backtrace, but get many messages. |
| 21:25.03 |
brlcad |
right, that's
what I need :) |
| 21:25.06 |
brlcad |
~bapaste |
| 21:25.16 |
brlcad |
~bzpaste |
| 21:25.17 |
ibot |
it has been
said that bzpaste is http://pastebin.bzflag.bz/ |
| 21:25.17 |
brlcad |
hm |
| 21:25.23 |
brlcad |
there |
| 21:27.59 |
csanyipal |
I think it's
there: http://pastebin.bzflag.bz/m6bdd531a |
| 21:29.31 |
brlcad |
perfect,
thanks .. hold on |
| 21:29.44 |
csanyipal |
ok |
| 21:40.34 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1242309791.dsl.bell.ca) |
| 22:29.54 |
csanyipal |
I shall come
back tomorrow. Go to sleep now. :) |
| 22:34.46 |
brlcad |
boohyaw |
| 22:34.56 |
CIA-38 |
BRL-CAD:
03brlcad * r37024 10/brlcad/trunk/bench/run.sh: |
| 22:34.56 |
CIA-38 |
BRL-CAD: less
emphasis on the statement to submit results, instead call attention
to the |
| 22:34.56 |
CIA-38 |
BRL-CAD:
email address. improve the output reporting of sysctl (don't need
vm) and the |
| 22:34.56 |
CIA-38 |
BRL-CAD: way
results are formatted. include prtdiag for solaris. use look_for to
search |
| 22:34.56 |
CIA-38 |
BRL-CAD: the
PATH to keep failures quiet (and avoid having to run the binary
additional |
| 22:34.58 |
CIA-38 |
BRL-CAD:
times) |
| 22:40.10 |
CIA-38 |
BRL-CAD:
03brlcad * r37025 10/brlcad/trunk/bench/run.sh: prevent calculating
a negative or zero logarithm and printing -inf's if vgr fails to be
calculated correctly |
| 22:44.32 |
CIA-38 |
BRL-CAD:
03brlcad * r37026 10/brlcad/trunk/bench/run.sh: report the summary
to the log file too. no sense in it just being output to the
screen. remove old comment about solaris. |
| 22:45.00 |
brlcad |
that puppy is
about due a gui.. |
| 22:55.26 |
brlcad |
csanyipal's
crash log is very bizarre.. smells like a smashed stack |
| 22:57.26 |
brlcad |
hard to say
without peeking inside _bu_alloc() .. need a debug
build |
| 22:58.14 |
``Erik |
dunno, could
be... I kinda smell lib order mixing with malloc hacketetry,
myself |
| 22:59.42 |
``Erik |
like tcl
malloc executing, then backing up to find its mud, but finding
BRL-CAD's mud instead |
| 22:59.47 |
``Erik |
*shrug* |
| 23:02.11 |
brlcad |
tcl malloc
should work too |
| 23:02.20 |
brlcad |
not that i've
ever seen that happen |
| 23:03.07 |
brlcad |
i'd expect
that mixup to cause a problem maybe during a free |
| 23:03.40 |
``Erik |
<---
working off of smell :) not thinking |
| 23:04.40 |
CIA-38 |
BRL-CAD:
03brlcad * r37027 10/brlcad/trunk/src/libtclcad/ged_obj.c: if
ged_open() fails, note the failure and stop so we don't allocate a
ged_obj. |
| 23:05.53 |
brlcad |
alas useless
without more debug info .. something for him to try later I
suppose, maybe a manual command-line opendb or go_open |
| 23:07.38 |
``Erik |
ayup |
| 23:15.41 |
CIA-38 |
BRL-CAD:
03brlcad * r37028 10/brlcad/trunk/bench/run.sh: aix ain't got no
prtdiag or cpuinfo satisfaction but does reportedly have a prtconf
command. use it. |
| 23:17.01 |
brlcad |
fg |
| 00:41.52 |
Nohla |
brlcad you're
back :) |
| 00:46.34 |
brlcad |
Nohla: I
am! |
| 01:00.51 |
Nohla |
brlcad the
last time, the conversion to pdf was done simultaneously with the
makefile, doesn't it?? |
| 01:03.43 |
*** join/#brlcad docelic
(n=docelic@78-2-111-81.adsl.net.t-com.hr) |
| 01:53.12 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 02:41.46 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 03:00.01 |
Nohla |
run make
comand into dockbook but an error happened while
running |
| 03:00.17 |
Nohla |
lessons/en/images/mged02_coordsys.png
\ |
| 03:00.17 |
Nohla |
lessons/en/images/mged02_defaultradio.png
\ |
| 03:00.17 |
Nohla |
lessons/en/images/mged02_flower_zooomin.png
\ |
| 03:00.17 |
Nohla |
lessons/en/images/mged02_flower_zooomout.png
\ |
| 03:00.17 |
Nohla |
lessons/en/images/mged02_multipane.png
\ |
| 03:00.18 |
Nohla |
lessons/en/images/mged02_radio_35_25.png
\ |
| 03:00.20 |
Nohla |
lessons/en/images/mged02_radio_front.png
\ |
| 03:00.22 |
Nohla |
lessons/en/images/mged02_radio_right.png
\ |
| 03:00.24 |
Nohla |
lessons/en/images/mged02_radio_top.png
\ |
| 03:00.26 |
Nohla |
lessons/en/images/mged02_truck_0_0_14.png
\ |
| 03:00.28 |
Nohla |
lessons/en/images/mged02_truck_270_-90.png
\ |
| 03:00.30 |
Nohla |
lessons/en/images/mged02_truck_270_90.png
\ |
| 03:00.32 |
Nohla |
lessons/en/images/mged02_truck_35_0.png
\ |
| 03:00.34 |
Nohla |
lessons/en/images/mged02_truck_35_25.png
\ |
| 03:00.36 |
Nohla |
lessons/en/images/mged02_truck_35_60.png
\ |
| 03:00.38 |
Nohla |
lessons/en/images/mged02_truck_35_90.png
\ |
| 03:00.40 |
Nohla |
lessons/en/images/mged02_truck_front.png
\ |
| 03:00.42 |
Nohla |
lessons/en/images/mged02_truck_left.png
\ |
| 03:00.46 |
Nohla |
lessons/en/images/mged02_truck_rear.png
\ |
| 03:00.48 |
Nohla |
lessons/en/images/mged02_truck_right.png
\ |
| 03:00.50 |
Nohla |
sorry |
| 03:00.59 |
Nohla |
this is:
make[1]: *** [Makefile.in] Error 1 |
| 03:01.00 |
Nohla |
make[1]: se
sale del directorio `/home/jesica/Desktop/brlcad' |
| 03:01.00 |
Nohla |
make: ***
[../../aclocal.m4] Error 2 |
| 03:43.07 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 04:31.32 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1242309791.dsl.bell.ca) |
| 06:04.45 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1242309791.dsl.bell.ca) |
| 06:04.51 |
*** join/#brlcad jesica__
(n=jesica@168.226.178.59) |
| 06:24.33 |
talcite |
brlcad: is
there any way that we can get one of the upstreams set up before
new year's? My amount of free time right now is pretty big and will
drop off for the first couple weeks of January |
| 06:36.57 |
brlcad |
talcite:
before new years eh? quite possible .. I'll see what we can
do |
| 06:37.17 |
talcite |
brlcad:
great. Thanks! I can also start packaging one if you'd
like |
| 06:37.28 |
talcite |
which one is
least likely to change when we take over upstream? |
| 06:38.40 |
brlcad |
the one's
we're talking about are URToolkit/libutahrle, step/SCL, and
possibly tkhtml3 yes? |
| 06:39.09 |
brlcad |
step is least
likely to change |
| 06:39.20 |
brlcad |
it's already
got a self-contained build system for the most part |
| 06:39.34 |
brlcad |
docs and
reasonable organization |
| 06:39.56 |
brlcad |
so it'll
probably have get imported mostly as-is for starters |
| 06:44.15 |
talcite |
alright. I'll
start working on step |
| 06:44.31 |
talcite |
yeah, tkhtml3
will probably need to be taken over. The upstream is really
dead |
| 06:44.58 |
talcite |
It would also
be really nice if we could remove the lemon external library which
gets built with it and also hv3 |
| 06:45.26 |
talcite |
I don't
actually understand how we build tkhtml3 without including lemon.
Did we use bison instead? |
| 07:25.29 |
brlcad |
i'm not
familiar with 'lemon' |
| 07:26.04 |
brlcad |
talcite: I
also don't see lexer/parser files |
| 07:26.26 |
talcite |
brlcad: It's
in the original tkhtml3 sources. Lemon is the parser they
use |
| 07:26.27 |
brlcad |
we removed
hv3 and the test suite in our integration |
| 07:26.36 |
brlcad |
part of hv3
or tkhtml3? |
| 07:26.51 |
brlcad |
i'm not
particularly interested in hv3 |
| 07:26.57 |
brlcad |
should be a
separate package |
| 07:27.39 |
talcite |
tkhtml3
sources I believe |
| 07:28.06 |
brlcad |
jesica__: the
error occurs *before* the "Error 1" line .. look for the first
place it says error then probably the line before *that* line is
the one that caused the error |
| 07:29.05 |
brlcad |
talcite:
sources for hv3 and tkhtml3 are together iirc |
| 07:29.29 |
talcite |
brlcad: yes,
the src folder is for tkhtml3 and hv is separate I
believe |
| 07:29.35 |
brlcad |
right |
| 07:29.51 |
talcite |
brlcad:
there's references to lemon in the tkhtml3 src folder |
| 07:30.57 |
brlcad |
where? |
| 07:31.20 |
brlcad |
looking at
the repo, there used to be a .y/.lem parser file, but no
longer |
| 07:31.59 |
brlcad |
last commit
says: "Switch from lemon to a hand-coded CSS parser. This makes it
possible to handle parse errors in a standards compliant
manner." |
| 07:32.14 |
brlcad |
so probably
just some stale comment |
| 07:42.28 |
talcite |
brlcad: oh
wait, you're doing a cvs pull? |
| 07:42.34 |
talcite |
I was looking
at alpha16 release |
| 07:43.02 |
brlcad |
I believe we
did |
| 07:43.10 |
brlcad |
don't know
what is in alpha16 |
| 07:43.19 |
brlcad |
cvs hasn't
changed in about 2 years |
| 07:43.31 |
brlcad |
alpha16 is at
least 22 months old |
| 07:46.06 |
talcite |
Ahh. that
makes more sense now |
| 07:46.20 |
talcite |
Can we do a
CVS pull for our upstream in tkhtml3? It would greatly simplify
things |
| 07:47.05 |
brlcad |
what do you
mean? |
| 07:47.23 |
brlcad |
I certainly
wouldn't be starting with a16 if we took over as
upstream |
| 07:47.51 |
talcite |
ah ok.
Alright, then everything is fine |
| 07:47.56 |
brlcad |
i've already
contacted dan to see where he stands with
maintainership |
| 07:48.04 |
brlcad |
so that one
is tbd |
| 07:49.17 |
talcite |
oh really? I
sent an email to dan and he said the project is not
active |
| 07:49.37 |
brlcad |
I wasn't
asking if it's active |
| 07:58.35 |
brlcad |
utah folks
notified |
| 07:58.42 |
talcite |
brlcad: ah
ok. Dan was pretty quick on email when I last contacted
him. |
| 07:58.54 |
talcite |
brlcad: any
thoughts on what we'll do with NURBS? |
| 07:59.04 |
brlcad |
what do you
mean? |
| 07:59.29 |
brlcad |
it's got an
"active" albeit very private and slow upstream |
| 07:59.47 |
talcite |
but they
didn't want our source modifications right? |
| 08:00.36 |
brlcad |
heh, nice ..
both utah contact emails came back immediately rejected |
| 08:01.06 |
talcite |
brlcad:
proposal rejected or routing rejected? |
| 08:01.13 |
brlcad |
dead
address |
| 08:02.30 |
talcite |
ahh well. Is
it safe to assume we can take upstream? |
| 08:04.26 |
brlcad |
oh, I already
knew we could |
| 08:04.32 |
brlcad |
i just didn't
know the mails were dead :) |
| 08:04.46 |
brlcad |
I was just
sending a cordial notification of the intention |
| 08:05.27 |
brlcad |
the last
version, 3.1b, was released more than a decade ago |
| 08:05.32 |
brlcad |
1996
iirc |
| 08:05.55 |
talcite |
ah. Heh I was
just starting to use computers back then |
| 08:06.18 |
brlcad |
it's long
overdue a 4.0 release ;0 |
| 08:06.48 |
brlcad |
then I can
finally quell all those damn compilation warnings |
| 08:07.11 |
brlcad |
and get rid
of some of the crap |
| 08:07.48 |
talcite |
heh. Sounds
good. |
| 08:12.28 |
CIA-38 |
BRL-CAD:
03brlcad * r37029 10/brlcad/trunk/doc/deprecation.txt: the hf
primitive was deprecated with release 6.0 .. should remove it at
release 8 |
| 08:20.39 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) |
| 08:21.10 |
*** join/#brlcad csanyipal
(n=csanyipa@150-142-85-95.dynamic.stcable.net) |
| 08:21.17 |
csanyipal |
Hi, |
| 08:21.23 |
brlcad |
howdy |
| 08:21.27 |
csanyipal |
:) |
| 08:21.53 |
csanyipal |
I'm ready for
testing Archer. |
| 08:22.19 |
brlcad |
the trace you
provided earlier is very odd .. need more information |
| 08:22.26 |
csanyipal |
ok |
| 08:22.37 |
brlcad |
need a debug
build |
| 08:22.42 |
csanyipal |
ok |
| 08:22.47 |
brlcad |
that looks
like it was an optimized compile? |
| 08:22.54 |
csanyipal |
yes, it
is. |
| 08:23.22 |
brlcad |
if you can
recompile without optimization enabled, that should give a more
informative backtrace |
| 08:23.36 |
brlcad |
in the
meantime, you can try running archer in a couple other
ways |
| 08:23.46 |
brlcad |
like
providing the .g on the command line "archer file.g" |
| 08:23.48 |
csanyipal |
I can, of
course. |
| 08:24.23 |
brlcad |
or within
archer on archer's command line "opendb file.g" or "gop
file.g" |
| 08:24.30 |
brlcad |
fantastic,
thanks |
| 08:24.41 |
csanyipal |
you are
wellcome! :) |
| 08:32.18 |
csanyipal |
when I run:
'archer radio.g' I get Segmentation fault. |
| 08:32.42 |
brlcad |
does it
happen with other .g files too? |
| 08:32.44 |
brlcad |
or just
radio.g? |
| 08:33.41 |
csanyipal |
it does
happen with other .g files too. |
| 08:37.01 |
brlcad |
okay, good to
know .. and you're running from an svn compile, yes? |
| 08:37.48 |
csanyipal |
Yes. When in
the Archer's command line run the command 'gop radio.g' I get error
message: Archer> gop radio.g |
| 08:37.48 |
csanyipal |
Error:
invalid command name "gop" |
| 08:38.05 |
csanyipal |
Yes, I'm
running brlcad builded from SVN. |
| 08:38.22 |
brlcad |
did opendb
work? |
| 08:38.35 |
csanyipal |
no, I get the
same error message. |
| 08:38.47 |
csanyipal |
invalid
command name. |
| 08:38.49 |
brlcad |
ah,
go_open |
| 08:39.23 |
brlcad |
go_open foo
file.g |
| 08:39.58 |
csanyipal |
go_open
radio.g give to me: Error: invalid command name
"go_open" |
| 08:40.31 |
csanyipal |
gives |
| 08:46.59 |
csanyipal |
Must I delete
/usr/brlcad/ directory before the new installation of debug
build? |
| 08:47.19 |
brlcad |
csanyipal:
it's a good idea |
| 08:47.41 |
csanyipal |
ok |
| 08:47.52 |
brlcad |
not strictly
necessary, but a good idea regarless |
| 08:48.05 |
csanyipal |
ok |
| 08:51.01 |
csanyipal |
I have
installed now the debug build. I'm going to reproduce Segmentation
fault and bzpaste the backtrace again. :) |
| 08:53.47 |
CIA-38 |
BRL-CAD:
03brlcad * r37030 10/brlcad/trunk/src/librt/primitives/ (8 files in
6 dirs): quell a slew of strict compilation warnings/errors adding
in extra parameter validation and denoting unused
attributes |
| 08:56.29 |
CIA-38 |
BRL-CAD:
03brlcad * r37031 10/brlcad/trunk/src/librt/primitives/mirror.c:
quellage. and that brings us to nmgs! .. progress of
sorts |
| 09:01.11 |
csanyipal |
when I get in
gdb on terminal the message: Continuing. after the command '(gdb)
continue' |
| 09:02.53 |
csanyipal |
and when in
Archer trying to open a .g file, I get a dialog with message: Error
Unsupported display manager type - ogl |
| 09:03.01 |
csanyipal |
and the
buttons Exit and OK |
| 09:04.22 |
csanyipal |
so when I hit
OK Archer won't crash. |
| 09:07.04 |
csanyipal |
but I have in
Archer a strange behavior of the mouse pointer: the poiner shows
that there is a process.. |
| 09:07.17 |
csanyipal |
hanging.. |
| 09:07.26 |
csanyipal |
but I can to
open menus.. |
| 09:07.51 |
csanyipal |
and change
say the background color. |
| 09:09.07 |
jesica__ |
brlcad, are
you a bot? |
| 09:09.28 |
jesica__ |
please, sleep
a little from time to time |
| 09:09.51 |
csanyipal |
:) |
| 09:17.59 |
jesica__ |
well done
:) |
| 09:21.29 |
csanyipal |
so I think
I'm going to compile brlcad --without-ogl |
| 09:22.46 |
CIA-38 |
BRL-CAD:
03brlcad * r37032 10/brlcad/trunk/ (4 files in 4 dirs): remove the
unused resource pointer from the adjust() callback. |
| 09:23.06 |
brlcad |
heh |
| 09:23.31 |
brlcad |
csanyipal:
hm.. archer won't work without ogl |
| 09:23.41 |
csanyipal |
brlcad:
uh! |
| 09:23.55 |
brlcad |
at least, I
don't think it will |
| 09:23.56 |
brlcad |
can try
it |
| 09:24.07 |
csanyipal |
ok, I will
try it. |
| 09:24.20 |
csanyipal |
but if you
have another solution? |
| 09:24.52 |
csanyipal |
what can I do
to solve this problem? |
| 09:30.05 |
csanyipal |
Good, so I'm
still trying to use Archer and brlcad with OpenGL. |
| 09:31.28 |
brlcad |
are you
up-to-date? |
| 09:31.33 |
brlcad |
"svn
update" |
| 09:32.44 |
csanyipal |
svn
update |
| 09:32.44 |
csanyipal |
Skipped
'.' |
| 09:35.59 |
csanyipal |
when I run
'svn update' inside of brlcad directory, I get: ... Updated to
revision 37032. |
| 09:43.22 |
brlcad |
okay
good |
| 09:43.34 |
csanyipal |
:) |
| 09:43.59 |
CIA-38 |
BRL-CAD:
03brlcad * r37033 10/brlcad/trunk/ (36 files in 36 dirs): remove
the unused resource pointer from the ifree() callback. |
| 09:47.13 |
CIA-38 |
BRL-CAD:
03brlcad * r37034 10/brlcad/trunk/src/librt/ (constraint.c
db5_bin.c db_comb.c dir.c): few more ifree() callers |
| 09:47.39 |
brlcad |
enough play
time for tonight.. bbiab |
| 09:49.10 |
CIA-38 |
BRL-CAD:
03brlcad * r37035 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
few peculiar ifree() calls |
| 09:49.15 |
csanyipal |
bye. |
| 10:04.24 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 10:13.06 |
*** join/#brlcad Tesl0r644
(n=Tesl0r@p5B22ACB9.dip.t-dialin.net) |
| 10:13.22 |
*** join/#brlcad Tesl0r722
(n=Tesl0r@p5B22ACB9.dip.t-dialin.net) |
| 10:13.26 |
Tesl0r722 |
hi |
| 10:15.30 |
Tesl0r722 |
you all
workin with blr or did somebody work with catia? |
| 10:19.24 |
csanyipal |
Well, after I
updated my local svn with 'svn update' and compile brlcad with:
'./configure' and with 'make -j2' I get Error message: |
| 10:19.41 |
csanyipal |
adjust.c: In
function âged_adjustâ: |
| 10:19.41 |
csanyipal |
adjust.c:80:
error: too many arguments to function
âintern.idb_meth->ft_adjustâ |
| 10:19.41 |
csanyipal |
make[2]: ***
[adjust.lo] Error 1 |
| 10:19.41 |
csanyipal |
make[2]: ***
Waiting for unfinished jobs.... |
| 10:19.41 |
csanyipal |
mv -f
.deps/ae2dir.Tpo .deps/ae2dir.Plo |
| 10:19.41 |
csanyipal |
make[2]:
Leaving directory
`/debian-adatok-1/CAD/BRL-CAD/SVN/brlcad/src/libged' |
| 10:19.43 |
csanyipal |
make[1]: ***
[all-recursive] Error 1 |
| 10:19.46 |
csanyipal |
make[1]:
Leaving directory
`/debian-adatok-1/CAD/BRL-CAD/SVN/brlcad/src' |
| 10:19.49 |
csanyipal |
make: ***
[all-recursive] Error 1 |
| 14:28.21 |
CIA-38 |
BRL-CAD:
03brlcad * r37036 10/brlcad/trunk/src/libged/ (9 files): unbreak
build, fix a slew of calls to the ifree() and adjust() functabs
where the resource pointer parameter was removed. all amazingly and
uselessly used the rt_uniresource. |
| 14:32.15 |
brlcad |
looks like
we're taking over tkhtml3 upstream |
| 14:41.35 |
``Erik |
hm |
| 14:43.22 |
``Erik |
is it using
tcl.tk's trac for project management? |
| 14:52.30 |
brlcad |
not for much
longer! |
| 14:52.46 |
CIA-38 |
BRL-CAD:
03brlcad * r37037 10/brlcad/trunk/src/librt/ (10 files in 10 dirs):
s/log/logstr/g where it's a bu_vls string for quellage
purposes. |
| 15:07.13 |
``Erik |
heh, we
should add http://penn.emaxcess.com/digital_reality_with_cad_015.htm
to db/ for jra :) |
| 15:08.01 |
``Erik |
is tkhtml3
going to have it's own sf project, or fall under the brlcad
umbrella like rtcmp, isst, jbrlcad, ...? |
| 15:15.20 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37038 10/brlcad/trunk/ (configure.ac
src/other/openNURBS/opennurbs_system.h): check for functional
malloc.h (being #error'd on some new systems) |
| 15:16.30 |
brlcad |
screw
malloc.h |
| 15:16.36 |
brlcad |
just include
stdlib.h |
| 15:16.49 |
brlcad |
less
cruft |
| 15:16.57 |
``Erik |
that header
includes stdlib.h, then does some #ifdef for windows and includes
malloc.h as the fallthrough |
| 15:17.23 |
brlcad |
so it's not
needed then.. |
| 15:17.50 |
``Erik |
*shrug*
unless you have an archaic system |
| 15:19.02 |
brlcad |
it's never
been needed that I know of, just provided the malloc subset of
stdlib so some folks got used to using it |
| 15:19.33 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37039 10/brlcad/trunk/ (configure.ac
src/other/openNURBS/opennurbs_system.h): eliminate references to
malloc.h |
| 15:20.45 |
brlcad |
tkhtml3 isn't
going under the umbrella |
| 15:21.14 |
brlcad |
one of the
current maintainers wants to move it to fossil |
| 15:21.17 |
``Erik |
that'll make
packaging it easier |
| 15:21.22 |
indianlarry |
brlcad:
rt_comb_adjust() in librt/tcl.c tries to free 'resp' the recently
removed resource pointer; trickles down through
db_tree_parse() |
| 15:21.39 |
``Erik |
fossil? O.o
sounds disturbingly apropos for tcl projects *cough*
O:-) |
| 15:21.50 |
brlcad |
not played
with fossil myself, but looking into it |
| 15:21.54 |
brlcad |
heh |
| 15:21.56 |
brlcad |
fossil-scm |
| 15:22.10 |
brlcad |
git/mercurial
hosting provider |
| 15:22.17 |
``Erik |
yes,
.org |
| 15:22.27 |
brlcad |
indianlarry:
okay |
| 15:25.49 |
``Erik |
does svn
allow tagging of subtrees? wondering if we should tag imports with
their imported version, so we can do a diff against the tag when
updating to hit all the mods |
| 15:27.02 |
brlcad |
svn has no
concept of tagging, it's just a lightweight copy into a 'tag' dir
-- we could tag imports if we were disciplined enough, but I
suspect .. we're not |
| 15:28.02 |
CIA-38 |
BRL-CAD:
03brlcad * r37040 10/brlcad/trunk/src/librt/tcl.c: make sure it's
not a null resource pointer, and more log/logstr
quellage |
| 15:29.18 |
``Erik |
stares at todays xkcd for a few hours O.o
:D |
| 15:32.15 |
``Erik |
that is one
awesome representation |
| 15:33.23 |
brlcad |
http://www.siggraph.org/s2010/for_submitters/game_papers |
| 15:37.38 |
brlcad |
fails to see how db_tcl_tree_parse() is
called |
| 15:38.23 |
``Erik |
so break and
bt |
| 15:38.45 |
brlcad |
I don't think
it's actually called |
| 15:38.51 |
brlcad |
was just
following the wrong func |
| 15:49.17 |
brlcad |
indianlarry:
that should fix it |
| 15:49.31 |
CIA-38 |
BRL-CAD:
03brlcad * r37041 10/brlcad/trunk/src/librt/ (db_tree.c
tcl.c): |
| 15:49.31 |
CIA-38 |
BRL-CAD: more
resource fallout. rt_comb_adjust() needs a resource pointer to pass
to |
| 15:49.31 |
CIA-38 |
BRL-CAD:
db_free_tree() and db_tree_parse() so provide the uniresource. add
a slew of |
| 15:49.31 |
CIA-38 |
BRL-CAD:
nullity/resource parameter validations to public api (should never
be required |
| 15:49.31 |
brlcad |
my build is
still going before I can be sure they're all squished |
| 15:49.31 |
CIA-38 |
BRL-CAD: to
pass a non-null resource) while we're at it. |
| 15:50.00 |
``Erik |
is seeing stuff busted left and right O.o svn up &&
gmake |
| 15:52.52 |
CIA-38 |
BRL-CAD:
03brlcad * r37042 10/brlcad/trunk/include/raytrace.h: remove
resource pointer from rt_hf_to_dsp() decl. |
| 15:53.06 |
``Erik |
heh, doh, I
was just build testing that :) |
| 15:56.18 |
brlcad |
got a faster
build going now |
| 16:01.08 |
``Erik |
asc2g is
busted |
| 16:02.08 |
indianlarry |
i've got all
the ifree updated in src/conv i'll checkin |
| 16:03.19 |
``Erik |
mged/utility1.c is busted |
| 16:03.43 |
CIA-38 |
BRL-CAD:
03indianlarry * r37043 10/brlcad/trunk/src/conv/ (7 files in 2
dirs): unused resource fixes for ifree and rt_hf_to_dsp |
| 16:03.58 |
``Erik |
that looks
like it |
| 16:06.31 |
CIA-38 |
BRL-CAD:
03indianlarry * r37044 10/brlcad/trunk/src/mged/utility1.c: unused
resource fixes for ifree |
| 16:07.21 |
``Erik |
w00t, full
build |
| 16:15.11 |
*** join/#brlcad csanyipal
(n=csanyipa@150-142-85-95.dynamic.stcable.net) |
| 16:15.20 |
csanyipal |
Hi, |
| 16:41.52 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) |
| 16:44.23 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 16:46.55 |
CIA-38 |
BRL-CAD:
03brlcad * r37045 10/brlcad/trunk/doc/deprecation.txt: include a
section for sed-scriptable 'minimally impacting' changes, provide
an actual regex that performs the change. note the intention to
change rt_db_free_internal(). |
| 16:51.56 |
CIA-38 |
BRL-CAD:
03brlcad * r37046 10/brlcad/trunk/ (113 files in 19 dirs): remove
the rt_uniresource parameter from rt_db_free_internal(). it's no
longer needed now that ifree() doesn't need one and was only used
by combs anyways and was almost always the
rt_uniresource. |
| 16:52.45 |
``Erik |
ffffffeck |
| 16:56.01 |
``Erik |
rebuilds and re-reads the diff and hopes there're no
conflicts O.o |
| 16:56.12 |
brlcad |
muahaha |
| 16:56.32 |
``Erik |
(at least I
rebuild before commiting and breaking the tree *cough*) |
| 16:56.46 |
brlcad |
this one was
actually a proper recursive query replace, so should be better
:) |
| 16:58.15 |
``Erik |
well, no, you
broke it :) |
| 16:58.17 |
``Erik |
src/conv/intaval/write_brl.cpp: In
function 'void smoothBot(rt_wdb*, char*)': |
| 16:58.17 |
``Erik |
include/raytrace.h:3257: error: too many
arguments to function 'void
rt_db_free_internal(rt_db_internal*)' |
| 16:58.20 |
``Erik |
src/conv/intaval/write_brl.cpp:119: error:
at this point in file |
| 16:58.38 |
brlcad |
"better" |
| 16:59.21 |
brlcad |
ahh yes, c++
file |
| 16:59.59 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37047
10/brlcad/trunk/src/conv/intaval/write_brl.cpp: uniresource is
gone |
| 17:02.47 |
CIA-38 |
BRL-CAD:
03brlcad * r37048 10/brlcad/trunk/src/librt/cmd.c: the intention of
isascii() here is unclear given our lacking support of non-ascii
i/o, remove it since it's a non-posix call. |
| 17:04.11 |
``Erik |
whistles and walks away from the computer
O:-) |
| 17:12.46 |
CIA-38 |
BRL-CAD:
03brlcad * r37049 10/brlcad/trunk/ (include/raytrace.h
src/librt/binary_obj.c): use size_t for the object sizes instead of
long long. quell unreachable code warning where binunifs were
arbitrarily being clamped to __LONG_MAX__. |
| 17:13.28 |
``Erik |
hm, I wonder
if that's going to break my 10 minute commit here |
| 17:13.48 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 17:17.22 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37050 10/brlcad/trunk/ (450 files in 37 dirs):
remove register keyword |
| 17:17.42 |
brlcad |
woah |
| 17:17.50 |
``Erik |
nothing in
the rt path |
| 17:19.28 |
brlcad |
*nod*, lotta
files ;) |
| 17:19.36 |
``Erik |
yes, thus the
'fffeck' earlier : ) |
| 17:19.42 |
brlcad |
haha |
| 17:19.48 |
``Erik |
the diff was
22k lines |
| 17:24.00 |
brlcad |
nice |
| 17:24.41 |
brlcad |
jeeeeeeebus!
not even halfway done with librt quellage.. |
| 17:25.35 |
brlcad |
and that's
just for one plat.. which is probably only 75% of the overall
effort |
| 17:26.02 |
brlcad |
~.75 *
.5 |
| 17:26.03 |
ibot |
0.375 |
| 17:26.06 |
``Erik |
aren't you
supposed to be hanging out with family or something? |
| 17:26.10 |
brlcad |
wee |
| 17:26.24 |
brlcad |
changed the
plan |
| 17:26.47 |
brlcad |
now it just
involves a shovel and a back yard |
| 17:27.07 |
brlcad |
neither of
which I have |
| 17:27.31 |
``Erik |
you have a
back yard? |
| 17:29.22 |
brlcad |
"neither of
which I have" |
| 17:29.45 |
brlcad |
yes, yes I
don't |
| 17:29.46 |
``Erik |
oh, missed
that line |
| 17:29.51 |
CIA-38 |
BRL-CAD:
03brlcad * r37051 10/brlcad/trunk/src/librt/db_open.c: fsync()
isn't posix, so don't try it if we're compiling strict |
| 17:30.20 |
``Erik |
ohhhhhhh |
| 17:30.46 |
brlcad |
src/conv/step
.. is really really really warning noisy :) |
| 17:30.59 |
``Erik |
yes, much
string/char* spew |
| 17:31.04 |
brlcad |
I think that
directory alone is 90% of my warning log |
| 17:31.09 |
``Erik |
from
ExpDict.h |
| 17:31.21 |
``Erik |
want me to
smack indianlarry upside the head for ya? |
| 17:31.40 |
brlcad |
warning:
"__O3DB__" is not defined |
| 17:31.47 |
brlcad |
seems to be a
big culprit |
| 17:31.53 |
``Erik |
can I smack
indianlarry anyways? |
| 17:31.55 |
indianlarry |
funny i was
compiling pedantic ? |
| 17:31.58 |
brlcad |
he's bigger
than you |
| 17:32.06 |
brlcad |
he's bigger
than me |
| 17:32.13 |
brlcad |
i'm not sure
smacking him is a viable approach |
| 17:32.14 |
indianlarry |
combined |
| 17:32.30 |
indianlarry |
i'll 6take a
look at it |
| 17:32.40 |
``Erik |
'sok, I lived
in missoura, I have solutions |
| 17:32.46 |
``Erik |
hey,
indianlarry, can I borrow your truck for a minute? |
| 17:32.52 |
brlcad |
indianlarry:
try on linux with --enable-warnings |
| 17:33.03 |
brlcad |
that won't
make them strict, but will make them report |
| 17:33.15 |
``Erik |
I get blabber
without strict about deprecated casting on fbsd |
| 17:33.51 |
brlcad |
rather,
--enable-warnings won't make them errors |
| 17:38.12 |
brlcad |
fwiw,
pedantic just means check for for a specific set of non-posix
(non-c89) semantics and calls -- those are somewhat orthogonal
issues to what the various warning flags (-W -Wall -Wshadow, etc)
indicate |
| 17:42.49 |
CIA-38 |
BRL-CAD:
03brlcad * r37052 10/brlcad/trunk/src/librt/db_open.c: sync() is
also a no-go, just rely on fflush() |
| 17:52.48 |
indianlarry |
I'm not
getting any warning on my linux box (-Wall and/or
--enable-warning) using gcc 4.1.2-46 |
| 17:53.03 |
brlcad |
o.O |
| 17:53.22 |
indianlarry |
Erik showed
me some of the string/char 8 cast warnings coming out of the STEP
lib |
| 17:53.41 |
indianlarry |
I'll builkd
on my mac and see what I get |
| 17:54.04 |
brlcad |
what does one
of your compile lines look like |
| 17:54.15 |
brlcad |
like for
SdaiAll.cc |
| 17:54.49 |
brlcad |
mine: if
/bin/sh ../../../libtool --silent --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I. -I../../../include
-I../../../src/other/step/include
-I../../../src/other/step/src/cleditor
-I../../../src/other/step/src/clstepcore
-I../../../src/other/step/src/clutils
-I../../../src/other/step/src/cldai
-I../../../src/other/step/src/test -I../../../src/other/tcl/generic
-I../../../src/other/tcl/unix -I../../../src/other/tnt
-I../../../src/other/openNURBS -I../.. |
| 17:57.48 |
indianlarry |
from
eclipse: |
| 17:57.51 |
indianlarry |
g++
-DSCLBUILD=1 -DHAVE_CONFIG_H -I"/home/wbowman/Desktop/STEP/step-g"
-I"/home/wbowman/Desktop/STEP/step-g/src"
-I/home/wbowman/Desktop/brlcad/include
-I/home/wbowman/Desktop/brlcad/include/brlcad
-I/home/wbowman/Desktop/brlcad/include/openNURBS
-I/home/wbowman/Desktop/brlcad_src/src/other/step/include
-I/home/wbowman/Desktop/brlcad_src/src/other/step/src/cleditor
-I/home/wbowman/Desktop/brlcad_src/src/other/step/src/clstepcore
-I/home/wbowman/Desktop |
| 17:58.08 |
brlcad |
that's
without any warning flags :0 |
| 17:58.33 |
indianlarry |
-Wall
? |
| 17:58.38 |
brlcad |
not even
wall |
| 17:58.45 |
brlcad |
you have an
eclipse project set up? |
| 17:58.59 |
indianlarry |
just for the
step converter |
| 17:59.07 |
brlcad |
presume you
set CFLAGS .. you have to also set CXXFLAGS |
| 17:59.22 |
``Erik |
CPPFLAGS
ftw |
| 17:59.38 |
indianlarry |
here is the
brlcad build line: |
| 17:59.41 |
indianlarry |
if /bin/sh
../../../libtool --silent --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I../../../../brlcad_src/src/conv/step
-I../../../include -I../../../../brlcad_src/src/other/step/include
-I../../../../brlcad_src/src/other/step/src/cleditor
-I../../../../brlcad_src/src/other/step/src/clstepcore
-I../../../../brlcad_src/src/other/step/src/clutils
-I../../../../brlcad_src/src/other/step/src/cldai
-I../../../../brlcad_src/src/other/step/src/test -I.. |
| 17:59.47 |
brlcad |
the verbose
flags that configure sets is: -W -Wall -Wundef -Wfloat-equal
-Wshadow -Wunreachable-code -Winline |
| 18:00.09 |
brlcad |
yeah, that is
just default .. no warning flags |
| 18:00.51 |
brlcad |
or a
truncated paste ... |
| 18:01.00 |
brlcad |
I just
see: |
| 18:01.00 |
brlcad |
if /bin/sh
../../../libtool --silent --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I../../../../brlcad_src/src/conv/step
-I../../../include
-I../../../../brlcad_src/src/other/step/include |
| 18:01.04 |
brlcad |
<PROTECTED> |
| 18:01.47 |
indianlarry |
i'll go back
and get those turned on |
| 18:02.23 |
``Erik |
goes to amazon.com and searches for "an idiots guide to
making NMG's" :D or mebbe I'll just keep looking at arb8 and try to
kick some braincells into action |
| 18:02.34 |
brlcad |
heh |
| 18:03.03 |
``Erik |
(printout,
highlighter and pen... wee) |
| 18:08.00 |
brlcad |
src/proc-db/tea_nmg.c is decent
starter |
| 18:08.14 |
brlcad |
but iirc, one
of the source files has some good bits in comment |
| 18:08.16 |
brlcad |
*.ooks |
| 18:08.35 |
brlcad |
ah yeah:
src/librt/primitives/nmg/nmg_mk.c .... |
| 18:08.53 |
``Erik |
yeh, digging
in those, tracing how the arb8 uses 'em |
| 18:09.08 |
brlcad |
a couple
comment blocks in there really are the start of explaining the
whole nmg api |
| 18:09.16 |
brlcad |
the cryptic
function names, etc |
| 18:10.02 |
``Erik |
*nod* |
| 18:12.30 |
``Erik |
hm, teapot
uses nurb type nmg's, not bot type :/ |
| 18:12.41 |
brlcad |
ah, my
bad |
| 18:13.12 |
brlcad |
there is
nmgmodel.c in there, but seems kinda messy to me |
| 18:14.14 |
brlcad |
aaaand, it
crashes if I run it .. heh |
| 18:21.15 |
yukonbob |
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00812.html |
| 18:21.26 |
yukonbob |
hello,
#brlcad |
| 18:22.32 |
``Erik |
hm,
asc-nmg.c |
| 18:23.14 |
brlcad |
wonders if they preserved their history |
| 18:24.04 |
``Erik |
is that the
cvs->bazaar switch? |
| 18:24.11 |
brlcad |
yeah |
| 18:24.25 |
``Erik |
<--
thought about pasting it this morning, but figured everyone reasons
slashdot |
| 18:24.34 |
brlcad |
talk about a
quadruple bypass culture shock :) |
| 18:25.40 |
``Erik |
heh, g-nmg
doh |
| 18:31.01 |
``Erik |
that's teh
recursive thingymajigger I've been wanting :D |
| 18:43.05 |
``Erik |
Cut_unimontone is in an infinite
loop |
| 19:10.30 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) |
| 19:15.22 |
CIA-38 |
BRL-CAD:
03brlcad * r37053 10/brlcad/trunk/src/proc-db/nmgmodel.c: plot the
model before we call mk_nmg() because mk_nmg() releases the model
passed to it during export/ifree. prevent crashy. |
| 19:18.52 |
CIA-38 |
BRL-CAD:
03brlcad * r37054 10/brlcad/trunk/TODO: |
| 19:18.52 |
CIA-38 |
BRL-CAD: a
few libwdb routines need to be modified to not free user-allocated
structures. |
| 19:18.52 |
CIA-38 |
BRL-CAD:
export ends up calling free/ifree releasing the passed parameter,
which can lead |
| 19:18.52 |
CIA-38 |
BRL-CAD: to
bad unexpected things happening to the caller. should make a copy
of the |
| 19:18.52 |
CIA-38 |
BRL-CAD:
struct like other wdb routines do. |
| 19:26.35 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 20:56.16 |
``Erik |
AWESOME |
| 20:56.33 |
``Erik |
nmgmodel
&& rt nmgmodel.g r.NMG == segfault |
| 20:56.37 |
``Erik |
halfway up
the rt |
| 20:58.28 |
``Erik |
looks like it
catches an error and crashes trying to report it |
| 20:59.29 |
``Erik |
yeh, exit
without entry, |
| 20:59.59 |
``Erik |
and a smashed
stack to boot |
| 21:04.02 |
yukonbob |
maybe rt is
now sentient, and is trying to h4x0r your computer for fun and
profit? |
| 21:08.09 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37055 10/isst/trunk/src/gui.c: remove handling
of non-existant GTK+ signal |
| 21:08.26 |
``Erik |
nah, it's a
fruity non-solid manifold, methinks, confuses boolweave or
something |
| 21:10.02 |
``Erik |
the crash on
error reporting is weird, though |
| 22:40.25 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.239) |
| 22:41.17 |
starseeker |
hasn't heard of fossil before, unless you count dead animals
turned to stone... |
| 22:42.50 |
starseeker |
oh http://www.fossil-scm.org |
| 22:45.12 |
starseeker |
another
one-off scm... hmm... |
| 22:58.57 |
brlcad |
starseeker:
yeah, my thoughts too |
| 23:00.26 |
yukonbob |
fossil ==
nice |
| 23:01.07 |
yukonbob |
drh writes
good software. |
| 23:01.36 |
brlcad |
the
connection: drh is one of the tkhtml3 devs |
| 23:01.56 |
yukonbob |
and of sqlite
fame, as well. |
| 23:02.08 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) |
| 23:02.11 |
brlcad |
dunno if he
or dlk did most |
| 23:02.23 |
brlcad |
yeah, same
dude |
| 23:03.07 |
yukonbob |
has been using fossil for quite a while hisself, after
switching from mercurial. |
| 23:03.25 |
``Erik |
vcs of the
week? |
| 23:04.28 |
yukonbob |
git was (is?)
a bit of a mess wrt all the binaries it requires, and also I've
used fossil in BSD, MacOS, and Windows successfully, where git was
not (I heard this has changed) a Windows-friendly
program |
| 23:05.37 |
``Erik |
psshhhh,
everyone knows darcs is the one true way |
| 23:06.31 |
brlcad |
visual source
safe ftw!!!!11! |
| 23:07.05 |
yukonbob |
reads wikipeida re: VSS |
| 23:08.27 |
``Erik |
heh |
| 23:08.37 |
yukonbob |
nice:
Although "eating their own dog food" is often said to be part of
Microsoft's culture, VSS appears to be an exception |
| 23:45.16 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 01:25.57 |
*** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 01:33.06 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 01:34.39 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 01:42.19 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) |
| 01:48.41 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 01:51.17 |
starseeker |
yukonbob:
I've heard git is getting baround in the usability
department |
| 01:51.49 |
starseeker |
doesn't want to maintain a version control system too
;-) |
| 01:52.46 |
starseeker |
er better all
around even |
| 01:53.51 |
starseeker |
``Erik: main
complaint I hear about darcs is that it doesn't scale
well |
| 01:55.56 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) [NETSPLIT
VICTIM] |
| 01:55.56 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 01:56.15 |
starseeker |
yukonbob:
looks like these guys are handling git on windows: http://code.google.com/p/msysgit |
| 01:56.45 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) |
| 02:00.18 |
starseeker |
ponders... hv3 very likely has some good stuff buried in it
that could live as separate, smaller tcl/tk
packages... |
| 02:01.28 |
starseeker |
the most
obvious one that comes to mind is pulling out the image display
stuff and making tkhtml3img or some such a package |
| 02:02.19 |
starseeker |
sorta enable
building up html viewers between our man page viewer and
hv3 |
| 02:05.42 |
starseeker |
blinks - tkhtml.sf.net is already
registered |
| 02:06.47 |
starseeker |
back in
August |
| 02:08.46 |
starseeker |
kdulcimer...
not a nick I immediately recognize |
| 02:10.14 |
starseeker |
hmm Unless
he was forking under GPL, he's got the wrong license up |
| 02:10.49 |
starseeker |
grins evilly - well, we could always register
tkhtml3.sf.net |
| 02:11.23 |
starseeker |
net |
| 02:11.52 |
starseeker |
hmm - doing
screen from a Windows terminal seems to have it's share of
quirks |
| 02:11.54 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 02:17.38 |
``Erik |
O.o
cygwin? |
| 02:23.23 |
starseeker |
msys |
| 02:30.39 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 02:37.51 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 02:39.03 |
``Erik |
tkhtml.sf.net
seems to have nothing of note in the svn repo and no files...
perhaps they were unaware of the existing tkhtml and are trying to
create one form scratch? or are just placeholding (with a damn
donation link) |
| 02:39.24 |
``Erik |
they might be
willing to relinquish if ya talked to them/him? *shrug* |
| 02:41.07 |
``Erik |
hm, but they
reference hv3 |
| 02:43.37 |
talcite |
tkhtml3.sf.net might end up being useless
if we ever go to tkhtml4 =) |
| 02:45.50 |
``Erik |
therealtkhtml.sf.net heh |
| 02:45.59 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 02:45.59 |
``Erik |
*shrug* they
may be willing to surrender the project if they're not actively
pursuing it and just want it to work (and think you'd actually keep
up on it) |
| 02:45.59 |
*** join/#brlcad cosurgi (n=cosurgi@153.19.34.234) [NETSPLIT
VICTIM] |
| 02:47.25 |
``Erik |
(notice how I
distance myself from responsibility there... I've been in the
corporate world too damn long :D ) |
| 02:47.25 |
*** join/#brlcad stevegt` (n=stevegt@cislunar.TerraLuna.Org)
[NETSPLIT VICTIM] |
| 02:48.35 |
*** join/#brlcad cosurg1
(n=cosurgi@atak.bl.pg.gda.pl) |
| 02:48.36 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
| 02:48.36 |
*** join/#brlcad Yoshi47
(n=jan@d72-39-56-44.home1.cgocable.net) [NETSPLIT
VICTIM] |
| 02:48.36 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 03:05.49 |
brlcad |
starseeker:
actually want to ditch the 3 suffix .. |
| 03:06.00 |
brlcad |
versioned
project names that don't have a recognizable trademark are pretty
rediculous |
| 03:10.31 |
brlcad |
i noticed the
sf project a couple months ago |
| 03:11.02 |
brlcad |
looks like a
placeholder effort, someone was going to fork (or did in private
and isn't used to public repos) |
| 03:11.48 |
brlcad |
can always
ask, or attempt a sf takeover, or change the name ;) |
| 03:14.13 |
brlcad |
if drh is
willing to set up fossil and be a support line, I'm willing to give
it a try -- that in itself provides a tracker system and an
integrated wiki |
| 03:15.09 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1242309950.dsl.bell.ca) |
| 03:23.34 |
``Erik |
plus the
legitimacy of having the previous maintainer 'bless' it |
| 03:28.54 |
starseeker |
votes for also asking about the sf site, just in
case |
| 03:29.13 |
brlcad |
already
asked |
| 03:29.17 |
starseeker |
ah
:-) |
| 03:29.47 |
starseeker |
should have known ;-) |
| 03:30.17 |
``Erik |
ah, but when
you asked it was just a random cold-call... this drh feller has
agreed to pass the torch now, so that might carry more
weight |
| 03:30.32 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1279331833.dsl.bell.ca) [NETSPLIT
VICTIM] |
| 03:30.32 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 03:30.35 |
``Erik |
could also be
that back when brlcad asked, they were full of vim and vigor (and
maybe some emacs), and now they've gone cold on the
idea |
| 03:31.06 |
starseeker |
could
be |
| 03:31.32 |
brlcad |
no, I mean I
*just* asked |
| 03:31.50 |
brlcad |
didn't matter
before today, and still kinda don't care much |
| 03:32.49 |
brlcad |
also drh is
just one of two devs, current maintainer is listed as
dlk |
| 03:32.56 |
brlcad |
unclear how
they interact |
| 03:33.28 |
brlcad |
dlk was cool
with the takeover, drh said then he'd set up fossil |
| 03:34.03 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 03:34.12 |
``Erik |
ah,
'k |
| 03:34.34 |
starseeker |
shrugs - well, I'm game to give fossil a go on something
minor like tkhtml |
| 03:35.22 |
starseeker |
ponders trying to reverse his earlier humiliation trying to
get TEA and autotools to play nice... |
| 03:36.03 |
``Erik |
if fossil
isn't up to snuff, can we migrate off of it while retaining the
history |
| 03:36.07 |
``Erik |
? |
| 03:36.18 |
starseeker |
not
sure |
| 03:36.24 |
brlcad |
dont' see why
not |
| 03:37.35 |
starseeker |
if all else
fails there's always pulling diffs and patching to recreate the
history via scripting |
| 03:38.00 |
brlcad |
yep |
| 03:38.36 |
starseeker |
not really
sure how much tkhtml will change - probably depends on whether the
tcl/tk community starts contirbuting patches |
| 03:38.58 |
``Erik |
<--
doesn't know anything about fossil, feels the need to ask the
obvious questions (be surprised how often there're missed obvious
things) |
| 03:39.45 |
starseeker |
``Erik: plus,
we'll be syncing the things we care about into our subversion copy
anyway |
| 03:48.13 |
``Erik |
ugliest mfc
ever? :) |
| 03:49.44 |
starseeker |
mmm? |
| 03:50.32 |
``Erik |
merge from
current |
| 03:50.39 |
starseeker |
ah |
| 03:50.51 |
``Erik |
(from fbsd's
cvs shtuff) |
| 03:50.59 |
starseeker |
thought you were talking about a windows
api |
| 03:51.04 |
``Erik |
ehhhh |
| 03:51.26 |
``Erik |
microsoft
foundation classes was just nasty... a halfassed class wrapping
around win16, then win32 |
| 03:51.40 |
``Erik |
actually got money for coding in it :( |
| 03:51.48 |
``Erik |
in, uh,
'96 |
| 03:52.03 |
``Erik |
I'm such a
whore :~( heheheh |
| 03:52.13 |
starseeker |
kinda like
boxing with handcuffs on? |
| 03:52.30 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 03:52.41 |
``Erik |
well, after
doing mfc and borland owl |
| 03:53.12 |
``Erik |
and
attempting to do ANY gui programming on leenewx (amulet, xaw, even
motif), java's awt was ... nice |
| 03:53.15 |
``Erik |
:/ |
| 03:53.31 |
``Erik |
then I did
qt, which sucked but had an awesome tutorial, then gtk which was
just ... the least painful |
| 03:53.59 |
starseeker |
heh |
| 03:54.01 |
``Erik |
but bear in
mind, c++ on gcc 2.7 with a 120mhz cyrix was a sssslllloooowwwww
painful compile |
| 03:54.16 |
starseeker |
plus, that
was some ancient Qt... |
| 03:54.24 |
``Erik |
I spent a
nontrivial amount of time reorganizing and tweaking headers to make
my game engine at the time compile fast |
| 03:55.02 |
``Erik |
like, 10s
fast when the c++ engines my peers were writing did the same
functionality but took like half an hour a pop |
| 03:55.16 |
``Erik |
I learned
dirty dark cpp secrets in those days :) |
| 03:55.38 |
``Erik |
these days, I
don't abuse cpp at all, it's all clean and simple and easy to read
O:-) |
| 03:55.58 |
starseeker |
reads yahoo mail and sees he is behind the
times |
| 03:56.23 |
starseeker |
``Erik: heh.
Yeah, c++ abuse was a common crime in the early days |
| 03:56.36 |
``Erik |
I wanna say
qt1.2? gtk/gnome was around .010 |
| 03:56.39 |
``Erik |
no, cpp, not
c++... |
| 03:56.45 |
``Erik |
the
preprocessor |
| 03:56.48 |
starseeker |
ah |
| 03:56.55 |
starseeker |
(stupid
naming conventions...) |
| 03:57.17 |
``Erik |
cpp is the
preprocessor... c++ is .c++, .cxx, .C or .cc |
| 03:57.27 |
``Erik |
:D |
| 03:59.15 |
brlcad |
yeah, that's
msvc's suffix bastardization |
| 03:59.31 |
brlcad |
.cxx or .c++
ftw |
| 03:59.39 |
``Erik |
ms products
flip on .c++ |
| 03:59.56 |
``Erik |
I tend to use
.cxx and .hxx when I'm forced to touch that language |
| 04:00.59 |
``Erik |
(the template
approach to the partial evaluation problem is interesting... ugly
but functional... gotta say that for the lang) |
| 04:02.35 |
``Erik |
bah, the brep
stuff all has .cpp in our librt and conv dirs |
| 04:02.45 |
``Erik |
and
proc-db |
| 04:03.01 |
``Erik |
ponders a bit of time to do a bunch of svn mv's
tomorrow |
| 04:04.05 |
``Erik |
(screwdrivers
ftw.) |
| 04:04.47 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 04:07.06 |
starseeker |
``Erik: works
for me |
| 04:07.14 |
starseeker |
what
convention does opennurbs use? |
| 04:10.42 |
``Erik |
windows
style |
| 04:10.46 |
``Erik |
it's a
windows program |
| 04:10.58 |
``Erik |
*nix is an
afterthought |
| 04:11.45 |
starseeker |
waits to see ``Erik attempt to convince the Rhino folk to
change all their file suffixes |
| 04:13.53 |
``Erik |
heh,
no |
| 04:18.24 |
``Erik |
my tenure as
a winderz user was feb '96 to oct '96, somewhere I have a printout
of the rhino3d manual from that era O.o they've been at it a
while |
| 04:18.39 |
``Erik |
that they
released what they did under a reasonable license is
boggling |
| 04:21.31 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 04:22.37 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 04:25.36 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 04:26.57 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1279332335.dsl.bell.ca) |
| 04:30.59 |
yukonbob |
starseeker:
re: git -- not surprised. |
| 04:31.54 |
starseeker |
``Erik: how
is it boggling? |
| 04:32.13 |
yukonbob |
and while I
love Unix, and thinks it's nearly infinately superior to Windows,
the distinct lack of respect for Windows as a platform that seemed
to be the culture of git was... baffling. |
| 04:32.17 |
``Erik |
proprietary
windows software giving away part of their core? |
| 04:32.25 |
brlcad |
kdulcimer is
amenable to granting admin on the sf.net project |
| 04:32.33 |
``Erik |
under an lgpl
friendly license? |
| 04:32.35 |
starseeker |
brlcad:
sweet |
| 04:32.56 |
brlcad |
he's not a
coder, was just setting up a place to host an svn repo for it, but
couldn't figure it out |
| 04:33.07 |
``Erik |
he and monkey
will want to continue to be involved/admin? |
| 04:33.14 |
starseeker |
yukonbob: not
too surprising - original concept by head Linux guy for Linux
kernel |
| 04:33.41 |
starseeker |
``Erik: as I
understand it, they gave away that part 'cause it's the part needed
to convert things to/from 3dm files |
| 04:33.47 |
yukonbob |
starseeker:
of course, but how many years does it take to make something
portable... it's _only_ a lightweight scm (ffs) |
| 04:33.49 |
brlcad |
he runs a
linux distro called tinyme, probably someone needed tkhtml for some
package |
| 04:34.10 |
starseeker |
yukonbob:
true |
| 04:34.15 |
``Erik |
saw the tinyme, assumed that was the reason, thus the 'just
wants it to work' comment way earlier, srry if'n ah waren't
clear |
| 04:35.03 |
brlcad |
so it's an
option if fossil flops |
| 04:35.34 |
``Erik |
is it worth
adopting and pointing to fossil, to avoid any
confusion? |
| 04:35.45 |
yukonbob |
anyway -- *I*
like fossil (back to original discussion) and I bet you would too
if you took a deeper look at it, and perhaps had a chat w/ drh --
no question git is cool too, and my previous notes (portablity,
diffcult interface, tonnes of binaries) may not even apply now --
it's been a while since I've taken a close look at
it... |
| 04:36.20 |
brlcad |
not too
worried about it, its just a minor dependency distraction at
best |
| 04:36.26 |
yukonbob |
I'm sure git
is "winning" on the installation-front (i.e. more projects hosted
by git) as far as dscm's go... |
| 04:36.47 |
``Erik |
git has
annoyed me every time I've used it (as an anonymous co/up)...
darcs, cvs and svn are all less... annoying |
| 04:37.16 |
``Erik |
I don't see
mercurial in my 'make this sane' scripts |
| 04:37.43 |
brlcad |
fossil as
documented sounds just fine -- my main concern for something major
are the same as I had with SVN |
| 04:37.44 |
yukonbob |
^--- what
does this mean? It's already sane, or too insane to bother putting
in your scripts? |
| 04:37.52 |
brlcad |
just that
it's relatively new and unproven |
| 04:38.05 |
brlcad |
every code
has bugs, and having one in your scm can be deadly |
| 04:38.11 |
``Erik |
no, none of
my mirrors use hg |
| 04:38.42 |
yukonbob |
brlcad: drh
has subjected it to quite a bit of rigour wrt design, and I'll bet
tests... to which he's certainly not a stranger... the strength of
sqlite is it's _massive_ test sutie. |
| 04:38.46 |
yukonbob |
*suite |
| 04:38.59 |
brlcad |
that can be
said of most codes |
| 04:39.13 |
``Erik |
I have a slew
of lisp 'libraries' that I pull straight from vcs, with scripts and
makefiles to automate as much as possible.. I do a "make
update-all" at the toplevel and it goes |
| 04:39.18 |
brlcad |
not quite the
same as having orders of magnitude of additional eyes and projects
stressing every corner case |
| 04:39.19 |
yukonbob |
brlcad: I
believe it's actually also driven by a client request, though I'm
not sure details; might be interesting. |
| 04:40.08 |
brlcad |
it's not like
adopting an editor and it being okay if it crashes only one out of
a thousand times |
| 04:40.16 |
brlcad |
or even one
out of a million |
| 04:40.17 |
yukonbob |
brlcad: no,
it's different, to be sure, but drh still writes tonnes of tests,
and has some interesting talked avail online about methods for
writing such tests, including coding consideration, etc. He's a
confidence inspiring guy. |
| 04:40.51 |
yukonbob |
he figures
the repos are intrinsicly uncorruptable. |
| 04:40.51 |
brlcad |
that's
faith-based confidence, which has little value with me
;) |
| 04:41.01 |
yukonbob |
it
is. |
| 04:41.05 |
``Erik |
heh |
| 04:41.07 |
``Erik |
jobs
aura? |
| 04:41.09 |
yukonbob |
you'd have to
review the code yourself |
| 04:41.26 |
brlcad |
code reviews
are mildly useless |
| 04:41.37 |
yukonbob |
quits advocating. |
| 04:41.39 |
brlcad |
for the level
of obscure bugs I'm referring to |
| 04:41.58 |
starseeker |
yukonbob:
we're probably going to go with the fossil repo to
start |
| 04:42.24 |
brlcad |
3rd party
independent testing getting hundreds of varied projects using it
without flaw, seeing reported defects slow/disappear |
| 04:42.25 |
``Erik |
personally, I
still think cvs is the shizzle forizzle :) sucks for binary
objects, but is more than ready for text material, provided your
developers have a mediocum of self control |
| 04:42.29 |
brlcad |
yeah, I don't
care about tkhtml :) .. we can use it for that :) |
| 04:42.44 |
brlcad |
cvs is one of
the most hardened scm's for all it's problems |
| 04:43.28 |
``Erik |
if you
commit, rm, add, commit with msg of to/from... it's all
good |
| 04:44.15 |
``Erik |
has not been above mv'ing files in the repo itself at all
times, though :( |
| 04:44.50 |
brlcad |
when you only
have 1000 users, a 1-in-a-million unrecoverable bug is practically
undetectable; when you have ten million users, a 1-in-a-million bug
is probably going to get identified |
| 04:44.53 |
``Erik |
or committing
acts of admin -o |
| 04:45.13 |
starseeker |
yukonbob: the
idea is to have tkhtml be a tcl/tk community project, not a BRL-CAD
project - we just need to get the pump primed again ;-) |
| 04:45.30 |
yukonbob |
ah... |
| 04:45.37 |
starseeker |
so if the
tcl/tk community is good with it, no problem |
| 04:45.47 |
``Erik |
how enamored
is the tcl/tk community with fossil? |
| 04:45.51 |
starseeker |
we maintain
our own copy in svn anyway :-) |
| 04:46.03 |
starseeker |
yeah, that's
my question too |
| 04:46.09 |
starseeker |
if they're ok
with it, it's good |
| 04:46.14 |
brlcad |
doesn't
really matter |
| 04:46.29 |
brlcad |
if it works,
and is easy enough to use.. |
| 04:46.42 |
brlcad |
it's one less
step to revive the project |
| 04:46.46 |
``Erik |
brlcad:
that's a functional attitude, not a social one |
| 04:47.01 |
yukonbob |
tkhtml is not
a stranger to it, and that drh is part of the tcl/tk community
(he's former tct, and sqlite was built originally as tcl extension)
some may be more likely to use it, some certainly do, but the
"community" are not zealots about it |
| 04:47.17 |
starseeker |
``Erik: I
think he means people probably won't worry about it too
much |
| 04:47.23 |
brlcad |
absolutely |
| 04:47.30 |
starseeker |
lord knows I
pull lisp code from all sorts of repos |
| 04:47.41 |
``Erik |
yeh, lisp
sucks like that |
| 04:47.48 |
starseeker |
(I have a
script system similar to yours, from the sound of it - kinda cool
:-) |
| 04:47.49 |
``Erik |
everything
but fossil (and mercurial) |
| 04:47.54 |
brlcad |
actually I
mean I'm not going to worry about it too much .. this isn't a major
problem being solved :) |
| 04:48.46 |
brlcad |
if it works
without hassle, great .. it'll have one of the previous
maintainer's blessing and continued involvement while still
providing a public infrastructure where development can
continue |
| 04:49.09 |
starseeker |
yukonbob: if
we get people merging back their tkhtml3 fixes into the new "main
tree" we'll call it a success |
| 04:49.16 |
brlcad |
the docs
looked like it's pretty simple enough to use, and if I don't have
to set it up, even better |
| 04:50.06 |
yukonbob |
the build
generates a single binary, which acts as client/server, including
http interface for webbrowser. |
| 04:50.26 |
starseeker |
um - which
build? you mean hv3? |
| 04:50.42 |
starseeker |
or
fossil? |
| 04:50.45 |
yukonbob |
oh -- I
thought was talking still about fossil. |
| 04:50.48 |
brlcad |
most
concerned about 1) getting access so we can grant other people
access that are interested, 2) getting existing patches integrated,
3) getting a separation of hv3 and tkhtml3, 4) getting public
infrastructure set up for easy patch/bug reporting, 5) getting a
new releae posted |
| 04:50.49 |
starseeker |
ah
:-) |
| 04:51.15 |
``Erik |
fossil has a
tarball download feature, right? (asking with my port maintainer
hat on) |
| 04:51.29 |
yukonbob |
.zip |
| 04:51.38 |
starseeker |
``Erik:
wouldn't a release tarball do fine? |
| 04:52.06 |
brlcad |
thinks this is a dead horse and gets back to doing something
productive ;) |
| 04:52.08 |
starseeker |
talcite will
probably need one for Fedora |
| 04:52.10 |
``Erik |
yes, the
fossil website provides for a static link of SOME kinda
archive? |
| 04:52.25 |
``Erik |
not
vcs-only? |
| 04:52.27 |
starseeker |
brlcad: heh,
sorry :-) |
| 04:52.35 |
talcite |
hmm? |
| 04:52.50 |
yukonbob |
``Erik:
.zip |
| 04:52.52 |
starseeker |
you'll want a
release tarball of tkhtml for Fedora integration, yes? |
| 04:53.04 |
yukonbob |
heads to Real Problems too. |
| 04:53.08 |
``Erik |
screw fedora,
freebsd :) |
| 04:53.17 |
starseeker |
hehe |
| 04:53.22 |
starseeker |
anyway, we
should be good |
| 04:53.29 |
starseeker |
is on vacation, heads to non-problems |
| 04:53.34 |
``Erik |
if'n there's
a static url that I can get a .tar.gz .tar.bz2 or .zip, it's all
good |
| 04:53.58 |
``Erik |
if not, I'll
be a whiney bitch |
| 04:54.14 |
starseeker |
resists comments that would get his ass kicked next
year... |
| 04:54.24 |
brlcad |
you'll just
find some other reason to be a whiney bitch |
| 04:54.37 |
``Erik |
:D |
| 04:55.10 |
``Erik |
I'd LIKE to
split tkhtml3 out of the fbsd port build and make it it's own
port... |
| 04:55.46 |
``Erik |
that anything
in src/other/ has to compile irks me |
| 04:56.09 |
starseeker |
you and every
other distro in existence... |
| 04:57.07 |
starseeker |
has flashbacks to the Great Gentoo Ebuild
Debate... |
| 04:57.46 |
brlcad |
wants to rename the Utah Raster Toolkit |
| 04:58.00 |
starseeker |
what'd you
have in mind? |
| 04:58.08 |
brlcad |
nothing as
yet |
| 04:58.22 |
brlcad |
there's the
URT toolset and librle/libutahrle |
| 04:58.32 |
``Erik |
starseeker:
I'm from the fbsd camp... we do things RIGHT, y'all can follow
along ;> |
| 04:58.34 |
talcite |
zip is fine.
I can package that |
| 04:58.37 |
starseeker |
thinks renaming is a good idea |
| 04:58.39 |
brlcad |
librle works
well for that portion |
| 04:58.50 |
brlcad |
URT is the
harder part |
| 04:59.42 |
brlcad |
rletools |
| 04:59.58 |
starseeker |
gonna break
it out into two separate trees? |
| 05:00.14 |
brlcad |
we needed to
do that for our own purposes |
| 05:00.23 |
brlcad |
some repos
also did similar |
| 05:00.23 |
starseeker |
ah,
k |
| 05:26.03 |
talcite |
are we using
only SCL or also EXPRESS, EXPRESS pretty printer, etc? |
| 05:28.25 |
talcite |
also, same
question about InterViews, ObjectStore as well |
| 05:29.38 |
brlcad |
we use
libexpress |
| 05:29.49 |
brlcad |
portions of
SCL too iirc |
| 05:31.18 |
talcite |
so build SCL
+ express, but not IV/OS? |
| 05:35.35 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 05:49.45 |
talcite |
man. SCL is a
complete mess |
| 05:49.54 |
talcite |
calling
configure compiles the program! |
| 05:51.34 |
brlcad |
oh are you
working with their original tarball? |
| 05:51.52 |
brlcad |
there are a
slew of build system tweaks it really needed |
| 05:58.38 |
talcite |
brlcad: ack.
Really? Will these be made before release? |
| 05:58.51 |
talcite |
our
release* |
| 05:59.13 |
talcite |
It's
currently blowing up because of compiler name I think |
| 06:02.53 |
talcite |
blah. I'll
look at this tomorrow. Head to sleep now. |
| 07:57.54 |
CIA-38 |
BRL-CAD:
03brlcad * r37056 10/brlcad/trunk/src/librt/db5_io.c:
quellage |
| 08:12.54 |
*** join/#brlcad indianla1ry
(n=indianla@BZ.BZFLAG.BZ) |
| 10:17.19 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 12:26.45 |
CIA-38 |
BRL-CAD:
03indianlarry * r37057 10/brlcad/trunk/src/conv/step/ (128
files): |
| 12:26.45 |
CIA-38 |
BRL-CAD:
Start of updates to cleanup compile warnings including cleaned up
of some |
| 12:26.45 |
CIA-38 |
BRL-CAD:
variable shadowing, namespace path additions to standard IO items,
cleaned up of |
| 12:26.45 |
CIA-38 |
BRL-CAD: some
CPP defs in the STEP generated code(will need to address in
'fedex') |
| 12:29.20 |
CIA-38 |
BRL-CAD:
03indianlarry * r37058 10/brlcad/trunk/src/conv/step/ (34
files): |
| 12:29.20 |
CIA-38 |
BRL-CAD:
Start of updates to cleanup compile warnings including cleaned up
of some |
| 12:29.20 |
CIA-38 |
BRL-CAD:
variable shadowing, namespace path additions to standard IO items,
cleaned up of |
| 12:29.20 |
CIA-38 |
BRL-CAD: some
CPP defs in the STEP generated code(will need to address in
'fedex') |
| 12:31.50 |
CIA-38 |
BRL-CAD:
03indianlarry * r37059 10/brlcad/trunk/src/conv/step/ (55
files): |
| 12:31.50 |
CIA-38 |
BRL-CAD:
Start of updates to cleanup compile warnings including cleaned up
of some |
| 12:31.50 |
CIA-38 |
BRL-CAD:
variable shadowing, namespace path additions to standard IO items,
cleaned up of |
| 12:31.50 |
CIA-38 |
BRL-CAD: some
CPP defs in the STEP generated code(will need to address in
'fedex') |
| 12:36.15 |
CIA-38 |
BRL-CAD:
03indianlarry * r37060 10/brlcad/trunk/src/conv/step/ (127
files): |
| 12:36.15 |
CIA-38 |
BRL-CAD:
Start of updates to cleanup compile warnings including cleaned up
of some |
| 12:36.15 |
CIA-38 |
BRL-CAD:
variable shadowing, namespace path additions to standard IO items,
cleaned up of |
| 12:36.15 |
CIA-38 |
BRL-CAD: some
CPP defs in the STEP generated code(will need to address in
'fedex') |
| 12:38.36 |
CIA-38 |
BRL-CAD:
03indianlarry * r37061
10/brlcad/trunk/src/conv/step/SdaiCONFIG_CONTROL_DESIGN.cc: |
| 12:38.36 |
CIA-38 |
BRL-CAD:
Start of updates to cleanup compile warnings including cleaned up
of some |
| 12:38.36 |
CIA-38 |
BRL-CAD:
variable shadowing, namespace path additions to standard IO items,
cleaned up of |
| 12:38.36 |
CIA-38 |
BRL-CAD: some
CPP defs in the STEP generated code(will need to address in
'fedex') |
| 12:42.32 |
CIA-38 |
BRL-CAD:
03indianlarry * r37062
10/brlcad/trunk/src/other/step/src/clstepcore/ExpDict.h: Cleaned up
CPP defs to quell compiler warning. |
| 13:25.27 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 13:28.14 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 13:32.22 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 13:49.54 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 14:53.50 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 15:32.58 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37063
10/brlcad/trunk/src/other/step/src/clstepcore/ExpDict.h: quell some
cast warnings... (probably should have a "const char *" method,
instead) |
| 15:34.31 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37064
10/brlcad/trunk/src/conv/step/MassUnit.cpp: add missing
semicolon |
| 15:55.28 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1279332335.dsl.bell.ca) |
| 16:31.39 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 16:45.09 |
``Erik |
<PROTECTED> |
| 16:46.49 |
``Erik |
15 second
load time, nifty |
| 16:47.25 |
``Erik |
13 that time,
must be a nfs vs memory cached thing |
| 17:08.22 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:08.30 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
| 17:24.06 |
*** join/#brlcad __monty__
(n=toon@83.129-247-81.adsl-dyn.isp.belgacom.be) |
| 17:24.42 |
__monty__ |
A bit late,
but Happy Anniversary! |
| 17:25.19 |
brlcad |
:) |
| 17:25.26 |
brlcad |
thanks
__ |
| 17:25.37 |
brlcad |
er, thanks
__monty__ |
| 17:26.03 |
__monty__ |
Say, are you
still working on the brl cad not working on mac thing? |
| 17:26.19 |
brlcad |
among other
things, yes |
| 17:26.39 |
__monty__ |
Any
progress? |
| 17:27.20 |
brlcad |
some but not
ready for an updated test just yet |
| 17:27.41 |
__monty__ |
Ok. |
| 17:27.59 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 17:29.16 |
CIA-38 |
BRL-CAD:
03brlcad * r37065 10/brlcad/trunk/src/proc-db/nmgmodel.c: quellage
and cleanup |
| 17:47.48 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 19:08.36 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-9-20.dclient.hispeed.ch) |
| 19:14.29 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 19:27.29 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
| 20:33.23 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 21:08.56 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
| 21:46.01 |
CIA-38 |
BRL-CAD:
03brlcad * r37066 10/brlcad/trunk/src/conv/step/ (4 files): update
a few more overlooked iostreamers to be std:: namespace
scoped. |
| 22:21.22 |
brlcad |
fixes the license on the tkhtml sf.net
project |
| 23:03.34 |
``Erik |
ah, so ya got
r00tage |
| 23:17.34 |
``Erik |
brlcad:
indianlarry got a call and I didn't have an answer, if someone
kills a tree, is there any chance to recoup the data from that
file? (it was closed, but nothing else was changed after the
kill) |
| 23:26.14 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 23:31.22 |
brlcad |
yeah, I was
talking to him about that |
| 23:32.33 |
``Erik |
what's the
situation at the moment? |
| 23:35.54 |
brlcad |
well what I'd
told him and what I looked up are different |
| 23:36.37 |
brlcad |
or at least,
clarified |
| 23:37.25 |
brlcad |
so short
summary is that some of the data can be recouped, but probably not
worth it |
| 23:37.43 |
``Erik |
so they added
you to the project, but are still listed as admins? was their
interest clarified? |
| 23:37.58 |
brlcad |
you'd have to
reconstruct the object type |
| 23:38.04 |
``Erik |
wait, what
you'd told who? did indianlarry get you about the data
loss? |
| 23:38.08 |
brlcad |
and if it's a
small object, it's gone, gets wiped out |
| 23:38.24 |
brlcad |
yeah,
indianlarry and I talked briefly |
| 23:38.36 |
``Erik |
ah, I figured
that the objects would still be alive, but the names would be
gone... it'd be like a lost+found full of inode # files |
| 23:38.37 |
brlcad |
I thought it
was just a flag, but I'm seeing that it's not |
| 23:38.39 |
``Erik |
where each
file is a primitive |
| 23:38.58 |
brlcad |
we wipe out
the object wrapper, replacing it with a deleted object
stub |
| 23:39.18 |
brlcad |
which is
basically like lost+found |
| 23:39.31 |
brlcad |
but the
unfortunate trick is that's only for "large" objects |
| 23:39.37 |
brlcad |
bigger than a
block |
| 23:39.51 |
brlcad |
so combs are
gone gone, most implicit prims are gone |
| 23:40.28 |
brlcad |
you'd be able
to extract binunifs, some BoTs, NMGs, etc |
| 23:40.34 |
``Erik |
ah, I didn't
think anything was really wiped other than name, it just went into
an unused list for reallocation |
| 23:40.48 |
``Erik |
fragmentation
is a beeyotch |
| 23:41.20 |
``Erik |
bob says
we'll have undo in a few months, keith thought it was a solid
argument for using a geometry server |
| 23:41.37 |
brlcad |
the "small"
objects are small enough that they get wiped to save making extra
I/O calls |
| 23:42.06 |
brlcad |
large are
just stubbed similarly, to minimize the I/O with just two small
calls instead of an arbitrary large call |
| 23:43.05 |
``Erik |
hm, we should
probably sort out undo before pushing hard on a new file format,
carrying history between sessions could be handy |
| 23:52.05 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
| 23:53.07 |
brlcad |
we probably
could do deletions better, in a semi-recoverable
fashion |
| 23:53.13 |
brlcad |
without
breaking format even |
| 23:54.01 |
``Erik |
yeh, but I
think I like the notion of having a full undelete tree (not list)
on opening a file |
| 23:54.04 |
``Erik |
space be
damned |
| 23:54.20 |
``Erik |
mebbe a
function or utility to purge history if desired |
| 23:54.27 |
``Erik |
so folk can
save space, or hide their shame |
| 23:54.39 |
``Erik |
does emacs
support undo trees? |
| 23:55.03 |
``Erik |
vim has a
feature where you can undelete a few times, do more edits, then go
back down the history and choose which branch to follow for
redos |
| 23:55.06 |
brlcad |
because
deleted objects ultimately are just marked with a bit
flag |
| 23:55.10 |
brlcad |
DB5HDR_HFLAGS_DLI_FREE_STORAGE |
| 23:55.21 |
brlcad |
that already
exists |
| 23:55.25 |
brlcad |
garbage_collect |
| 23:55.50 |
brlcad |
that will
collapse all free space, reclaim space |
| 23:55.54 |
``Erik |
garbage
collect compacts, but if we retain zomfg undo history in the file,
that's an orthogenal issue I think |
| 23:56.03 |
brlcad |
ahh |
| 23:56.07 |
brlcad |
that sort of
history |
| 23:56.58 |
``Erik |
yeh, unless
there's any valid concern, I'd advote being able to do a series of
edits, quit mged, start mged and open the file and be able to undo
down that history set |
| 23:57.33 |
brlcad |
emacs does a
sort of circular linked list undo, where undos themselves are just
added to the list so you can undo your undos and fully
unwind/rewind |
| 23:57.47 |
``Erik |
I would argue
that file size isn't an issue until it becomes one, worrying about
it now would be wasteful |
| 23:58.06 |
``Erik |
yeh, so it
doesn't grok branching |
| 23:58.37 |
``Erik |
edit a, edit
b, edit c, undo, undo, edit d, undo, redo a.... that's possible in
vim as of 6.0 |
| 23:58.40 |
``Erik |
I think it
was 6.0 |
| 00:00.09 |
brlcad |
I can't say
I've really had an issue with emacs undo, it's pretty
nifty |
| 00:00.37 |
brlcad |
your example
didn't make much since, you never undid a to redo a |
| 00:00.57 |
``Erik |
oh, well, vim
records undo trees, not undo lists |
| 00:01.06 |
``Erik |
even if my
example missed an undo |
| 00:01.46 |
``Erik |
"redo
b" |
| 00:01.47 |
``Erik |
there |
| 00:01.58 |
brlcad |
not clear to
me what that really means in the context of editing
files |
| 00:02.41 |
``Erik |
if you undo
and change something else, either you throw away the 'redo'
capability, or you require a tree of changes... vim changed to hold
the tree |
| 00:02.53 |
brlcad |
that exact
same list of actions is what emacs would do too |
| 00:04.25 |
brlcad |
again the
trick being that an undo really just adds a new edit event which
can itself still be undone |
| 00:04.59 |
brlcad |
basically
lets you play back any/every action all the way back to the last
save |
| 00:05.20 |
brlcad |
including
undos and undos of undos and whatever intermediate
actions |
| 00:05.24 |
``Erik |
hm, I'm not
good enough with emacs to have figured out how to use undo
well |
| 00:05.44 |
``Erik |
^xu is what I
used, I think |
| 00:05.44 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 00:05.45 |
brlcad |
ctrl+shift+_ |
| 00:05.56 |
``Erik |
or, uh, C-x
u |
| 00:06.22 |
brlcad |
that's
redo |
| 00:07.32 |
brlcad |
will play the
actions back forward again (so say you undid every single action,
you could redo everything to get back to where you were regardless
of intermediate steps) |
| 00:08.05 |
brlcad |
pretty darn
nifty |
| 00:09.08 |
brlcad |
sounds maybe
like vim caught up with the same feature (but perhaps via diff
implementation mechanism) |
| 00:10.07 |
``Erik |
hrm, d'no
*shrug* not versed enough in emacs to honestly compare 'em, even
though I spent most of the day in emacs |
| 00:10.51 |
``Erik |
my rough
guess would be that understanding undo as a queued event is one
thing, but still a lot more linear than going tree
based |
| 00:11.57 |
brlcad |
wow, GSL is
about a quarter million lines of code |
| 00:12.32 |
``Erik |
http://www.gnu.org/software/gsl/
? |
| 00:13.41 |
brlcad |
yep |
| 00:14.29 |
brlcad |
using their
root solving to validate a change to our root solver |
| 00:15.04 |
brlcad |
last I
compared, we get the same results as expected |
| 00:15.18 |
brlcad |
we were just
a solid order of magnitude faster |
| 00:15.41 |
``Erik |
what about
mathematica or maple or something? |
| 00:15.54 |
``Erik |
or writing
one up in an absolute system, like scheme or haskell? |
| 00:16.03 |
brlcad |
what? |
| 00:16.05 |
brlcad |
what
for? |
| 00:16.06 |
brlcad |
:) |
| 00:16.14 |
brlcad |
go for
it |
| 00:16.18 |
``Erik |
to see how
bad the floating point fuzz hurts us |
| 00:16.33 |
brlcad |
i can't
imagine mathematica being faster on basic root solving |
| 00:16.39 |
``Erik |
no, not
faster |
| 00:16.50 |
``Erik |
but "more
correct", perhaps |
| 00:17.07 |
brlcad |
though this
is at a raw API level I was comparing -- how long to get roots for
polynomial of various degree |
| 00:17.41 |
brlcad |
that was the
diff, gsl would do arbitrary degree -- we were compile-time limited
to a fixed degree |
| 00:17.53 |
``Erik |
ah, aight
:) |
| 00:18.07 |
``Erik |
I might have
some old code from college for root solving via various
techniques |
| 00:18.10 |
brlcad |
i compared
about a half-dozen solvers I found around the net |
| 00:18.20 |
brlcad |
some
academic, few packages like gsl |
| 00:18.26 |
``Erik |
I vagually
recall writing a newtonian one in haskell that was ass slow, the
scheme version was a few orders of magnitude faster |
| 00:18.35 |
``Erik |
like,
finished in minutes instead of not having an answer over the
weekend |
| 00:18.48 |
brlcad |
I thought we
were really slow, which is why I was looking |
| 00:18.50 |
``Erik |
but single
root solver, not general |
| 00:18.59 |
brlcad |
but turned
out that we beat everything I could find and tested
against |
| 00:19.19 |
brlcad |
one other
implementation had about the same performance, within a couple
percent |
| 00:19.34 |
``Erik |
see, that's
why I'm asking about correctness... it's easy to generate fast
wrong answers... :D |
| 00:19.56 |
brlcad |
they were all
correct answers |
| 00:20.08 |
``Erik |
um, like the
xkcd commit about random number generators... /* proven correct */
int random() { return 4; } |
| 00:20.09 |
brlcad |
or at least
everyone produced the same results :P |
| 00:20.11 |
``Erik |
:) |
| 00:20.15 |
``Erik |
within? |
| 00:20.28 |
brlcad |
within
floating point tol |
| 00:20.30 |
brlcad |
double
tol |
| 00:20.35 |
``Erik |
okie |
| 00:20.38 |
``Erik |
cool
beans |
| 00:20.40 |
brlcad |
close
enough |
| 00:21.13 |
brlcad |
I'm sure
there's still plenty of edge case or more extreme polynomials that
our simple one can't solve |
| 00:21.53 |
``Erik |
I did g-nmg
on a file that produces a .g which crashes on dirbuild, any
insight? |
| 00:22.13 |
brlcad |
insight #1:
fix it |
| 00:22.20 |
brlcad |
insight #2:
don't do that |
| 00:22.24 |
``Erik |
hehehe |
| 00:22.53 |
``Erik |
g-nmg -o
file-nmg.g file.g toplevel <-- gives a fruity .g file!
:D |
| 00:22.54 |
brlcad |
is full of insightful comments |
| 00:23.25 |
brlcad |
did g-nmg say
it went to completion? |
| 00:23.29 |
``Erik |
yup |
| 00:23.35 |
``Erik |
it was a big
file |
| 00:23.56 |
``Erik |
was to come
up with a faster loading demo for isst, so you know the
file |
| 00:24.19 |
``Erik |
I did manage
up a 200k face m35 for demoing |
| 00:24.24 |
brlcad |
my guess
would be that some intermediate object failed, but is still
referenced -- and dirbuild has some bad juju that assumes the
missing object should be there and bites the dust |
| 00:24.54 |
brlcad |
definitely
something to fix in dirbuild |
| 00:25.27 |
``Erik |
still at the
office? I can tell ya where the criminal .g file is |
| 00:25.45 |
``Erik |
can also
point you to a .g file that flips out because every effin' matrix
is all 0's heh |
| 00:25.58 |
brlcad |
don't wanna
look at it at the moment, or i'll be here till midnight |
| 00:26.07 |
``Erik |
or I can
bitch at ya for those sun machines |
| 00:26.18 |
brlcad |
matrix of 0's
is probably endian |
| 00:26.30 |
brlcad |
dirbuild
succeeds, but all the floats are hozerd |
| 00:26.31 |
``Erik |
v5
db |
| 00:26.46 |
brlcad |
a v5 from an
upgraded v4, upgraded on the wrong plat |
| 00:27.03 |
``Erik |
*shrug*
perhaps |
| 00:27.13 |
``Erik |
trying to
remember where I pulled it up last |
| 00:27.39 |
``Erik |
it's a simple
r/c plane, small model |
| 00:29.50 |
brlcad |
a good bit of
cleanup on the step code.. cut the warnings at least in half I
think |
| 00:30.02 |
``Erik |
depends on
the compiler |
| 00:30.05 |
brlcad |
wonders what all the "will never be executed" warnings are
all about |
| 00:30.18 |
``Erik |
ExpDir.h was
the majority of warnings for my bsd build |
| 00:31.38 |
brlcad |
looks like
most of those execution warnings are on object
constructors.. |
| 00:33.32 |
brlcad |
tries a sick test |
| 00:34.43 |
brlcad |
wow, he
already did |
| 00:35.51 |
brlcad |
~seen
madant |
| 00:35.52 |
ibot |
madant
<i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last
seen on IRC in channel #brlcad, 179d 4h 13m 58s ago, saying:
'nothing more disastrous than non-cooperative softwares
;)'. |
| 00:35.59 |
brlcad |
~seen
homovulgaris |
| 00:36.00 |
ibot |
homovulgaris
<n=d@117.196.131.215> was last seen on IRC in channel
#brlcad, 505d 20h 43m 29s ago, saying: 'sean, on a scale of 1 to 10
how much trouble would one face when trying to make a .deb package
for brlcad ?'. |
| 00:36.05 |
brlcad |
hrmph |
| 00:36.33 |
brlcad |
he really did
a nice piece of work fixing our root solver parameters |
| 00:36.44 |
brlcad |
they were all
in reverse order, he flipped them right |
| 00:37.02 |
brlcad |
and he wrote
a little test harness that compares to gsl results |
| 00:37.08 |
brlcad |
showing the
diff |
| 00:38.36 |
``Erik |
and lets home
gsl isn't flawed O.o :D |
| 00:38.39 |
brlcad |
http://paste.bzflag.bz/m4050e32c |
| 01:19.23 |
brlcad |
looks like
gsl has improved, only about 5% slower now (very
consistently) |
| 01:20.19 |
``Erik |
<PROTECTED> |
| 01:21.08 |
``Erik |
heheheheheheheh http://www.youtube.com/watch?v=6bs_Lk5iQzc
:D always makes me smile |
| 01:53.58 |
starseeker |
brlcad: that
mean the patch with coefficient changes is good to go
in? |
| 01:54.24 |
brlcad |
starseeker:
it looks like it, still testing |
| 01:54.30 |
starseeker |
sweeet |
| 01:54.32 |
brlcad |
i'll commit,
it needed a few minor tweaks |
| 01:54.38 |
starseeker |
cool |
| 01:54.40 |
brlcad |
but in all,
nice work |
| 01:54.53 |
starseeker |
is stuck in windoze land anyhow til next
year... |
| 01:55.15 |
brlcad |
the gsl
comparison is the best part, but alas .. :) |
| 01:55.21 |
brlcad |
maybe keep
the test harness code as example |
| 01:55.53 |
starseeker |
nods - maybe have it as an optional part of the regression
testing? |
| 01:56.15 |
brlcad |
the testing
to link against gsl is too peripheral |
| 01:56.19 |
starseeker |
or even some
special "make rootcompare" test? |
| 01:56.21 |
starseeker |
ah |
| 01:57.13 |
brlcad |
unless... |
| 01:57.29 |
brlcad |
i make it an
option in our solver itself to use gsl as an alternative
impl |
| 01:57.37 |
brlcad |
could be
interesting |
| 01:57.41 |
starseeker |
hmm - that
could be cool |
| 01:57.48 |
``Erik |
compile time?
or? |
| 01:57.59 |
brlcad |
yep |
| 01:58.09 |
``Erik |
'k, branches
are insanely expensive on modern x86 |
| 01:58.33 |
``Erik |
we're at
what, twenty something deep on the pipeline? |
| 01:59.09 |
brlcad |
starseeker:
did you have a good tgc failure test case handy? |
| 01:59.24 |
brlcad |
i know
there's tire's eto's, they could be tested |
| 02:00.06 |
brlcad |
lots of
complete episodes .. :) |
| 02:00.56 |
``Erik |
do we have an
m35 with 'good' tires on it? I did a g-nmg on it with 200k
triangles in the output, loads up fast in isst and looks pretty
decent, but the tires look odd |
| 02:01.39 |
``Erik |
and tires
should give me lots of triangles in a cheap kd-tree :D |
| 02:02.25 |
starseeker |
brlcad: havoc
has that tgc that's giving rtgl fits, but I didn't isolate it
yet |
| 02:03.10 |
starseeker |
``Erik: you
probably don't want to tesselate one with tire tool tires - iirc
the last time we tesselated those it was... um...
interesting |
| 02:03.54 |
``Erik |
interesting
how? I'd imagine it'd be brutal on the nmg csg shtuff, but the
results should be clean |
| 02:03.58 |
starseeker |
brlcad
eventually got one when we turned the tread off |
| 02:04.16 |
starseeker |
took quite a
while |
| 02:04.22 |
``Erik |
ah,
hrm |
| 02:04.56 |
starseeker |
it's a
torture test for the tesselatorer |
| 02:05.19 |
``Erik |
damn |
| 02:05.28 |
``Erik |
:/ I might
have to spend time on tha tmarching cubes crap |
| 02:06.33 |
starseeker |
extruded
sketches interesected with combinations based on
etos... |
| 02:07.39 |
``Erik |
sounds like a
great test case for bug fixing |
| 02:07.52 |
``Erik |
is still waiting for brlcad to give him obj files to test
obj-g and make that work |
| 02:08.08 |
starseeker |
can blender
generate them? |
| 02:08.30 |
starseeker |
or
wings3d? |
| 02:09.16 |
``Erik |
obj files?
I'd imagine so... I have a test set, but I'm only going to finish
up a subset, brlcad made it sound like he had 'real world' models
he wanted converted, so I was hoping to see what subset of
functionality from that |
| 02:10.58 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
| 02:13.07 |
starseeker |
should fix that geometry duplication in the tire tool output
- that might be making the tesselation unduly
difficult |
| 02:16.33 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
| 02:33.12 |
starseeker |
wishes he had that graphviz visualization of the tire
tree... |
| 02:35.55 |
starseeker |
``Erik: how
come the tire command on the bz install of BRL-CAD can't find
libtcl? |
| 02:40.53 |
``Erik |
hte old bz,
or the new bz? |
| 02:40.57 |
starseeker |
old |
| 02:41.07 |
starseeker |
``Erik: how
does one get to the new bz? |
| 02:41.12 |
``Erik |
cuz it's an
ancient piece of shit that needs to be killed? |
| 02:41.23 |
starseeker |
``Erik:
ah |
| 02:41.42 |
``Erik |
no,
seriously, it was out of date over 5 years ago |
| 02:44.49 |
Nohla |
starseeker
hello, little prince :) |
| 02:44.56 |
starseeker |
hola! |
| 02:45.52 |
starseeker |
note to self
- REALLY need to make a smaller version of the tire
poster... |
| 02:46.02 |
starseeker |
redo in
inkscape if I have to... |
| 02:46.59 |
starseeker |
or see if the
version of ghostscript on my gentoo box has learned any new
tricks... |
| 02:48.44 |
``Erik |
you have the
photoshop version? it can be saved as a pdf in
'preview' |
| 02:49.00 |
starseeker |
oh, have
pdf |
| 02:49.19 |
starseeker |
Apple's
desktop publishing software was the original generator |
| 02:49.55 |
``Erik |
pdf is pretty
squished... |
| 02:50.04 |
starseeker |
probably had
images too big |
| 02:57.01 |
``Erik |
"save as
png"? |
| 02:58.22 |
``Erik |
grumbles as his lisp markov 'disassociated text' has some
funky issues with new nodes not being created quite
right |
| 02:59.43 |
``Erik |
it was all
disgustingly easy until the recursive call to generate the
dictionary ate a wrong type, and now it's hard figure out why
*grumble* is assoc not doing what the docs say? |
| 03:00.46 |
starseeker |
who's fault
is it? sbcl? |
| 03:00.53 |
``Erik |
well |
| 03:01.40 |
``Erik |
(setf (cadr
d) (acons (pair l) '(()()) (cadr d))) |
| 03:02.22 |
``Erik |
(add-dictionary-word (assoc (pair l) (cadr
d)) l 0) |
| 03:02.35 |
``Erik |
that assoc
keeps coming up with nil, when it shoulda just been
defined |
| 03:03.28 |
``Erik |
using sbcl,
yes... but assoc should just work, I'm not sure if I'm feeding it
wrong |
| 03:04.18 |
``Erik |
I'm sure I'm
making a stupid mistake, but I've thrashed all over :/ |
| 03:04.43 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
| 03:05.32 |
starseeker |
``Erik: I
take it #lisp would just be insulting? |
| 03:06.22 |
``Erik |
I'm not
feeling up to snuff to defend myself at the moment... I don't think
I've put enough time/thought to it |
| 03:06.42 |
``Erik |
<-- notes
that he's grumbling here, not asking for help :D |
| 03:07.56 |
``Erik |
there's a
lisp weirdness where something like '(() ()) comes up as '() in
some cases |
| 03:08.07 |
``Erik |
I might just
need to use a dummy symbol to expand teh lists |
| 03:09.07 |
starseeker |
ah |
| 03:09.12 |
``Erik |
<-- is
fighting emacs as much as lisp... gave up on gui emacs and started
using -nw this afternoon, coudln't get a nice black
background |
| 03:09.50 |
``Erik |
y'know, when
I wasn't reading webcomics or yelling at indianlarry for breaking
teh build :) |
| 03:10.45 |
``Erik |
(it's on my
idp, damnit.) |
| 03:11.12 |
starseeker |
problem lives
somewhere around tire.c:1371 |
| 03:11.21 |
starseeker |
tire-upper-sides definitions |
| 03:14.43 |
``Erik |
with the
duplicated geometry? |
| 03:15.04 |
starseeker |
yes |
| 03:15.36 |
starseeker |
getting three
instances of EllClip when there appear to be only two mk_addmember
calls |
| 03:15.41 |
``Erik |
starseeker:
do any of your cats have an object they're obsessed with dragging
around? |
| 03:17.40 |
starseeker |
she likes her
blue sparkly ball, but she's not terribly obsessed with
it |
| 03:17.55 |
starseeker |
usually
doesn't carry anything with her |
| 03:18.29 |
``Erik |
ah, I have a
furry cat fishing pole, the boy needs to drag his 'kill' all over
the place |
| 03:18.31 |
starseeker |
``Erik:
when's the last update to BRL-CAD on the new server? |
| 03:18.58 |
starseeker |
can't gdb this sucker very well... |
| 03:19.04 |
``Erik |
um,
/usr/brlcad is an svn from a week or two ago, /usr/local/brlcad is
like 7.14.smomething |
| 03:19.13 |
starseeker |
hmm |
| 03:19.14 |
starseeker |
ok |
| 03:19.38 |
``Erik |
feel free to
build your own :) |
| 03:19.51 |
starseeker |
``Erik: yeah,
she'll "kill" her catnip pillow sometimes |
| 03:20.26 |
``Erik |
I keep
putting this thing in the living room downstairs, it keeps ending
up in my bed O.o |
| 03:20.33 |
starseeker |
hehe |
| 03:21.17 |
``Erik |
updating
/usr/brlcad/HEAD with a fresh checkout now |
| 03:21.32 |
starseeker |
will have to step through this to figure out why the frap the
boolean logic is odd... |
| 03:22.39 |
starseeker |
may have to
wait til I have better setup (sorry ``Erik :/) |
| 03:23.14 |
``Erik |
*shrug* ain't
no skin off my nose |
| 03:23.15 |
starseeker |
I'm not real
sure why the standard m35 tires are hozed |
| 03:23.21 |
starseeker |
they
shouldn't be |
| 03:23.22 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
| 03:23.24 |
``Erik |
hozed? |
| 03:23.34 |
``Erik |
the m35 tires
convert just fine, they're just ... boring |
| 03:23.41 |
starseeker |
when Nick did
his rtgl stuff, one side of the m35 tires didn't raytrace
right |
| 03:23.51 |
starseeker |
might not
actually be the fault of the tires though |
| 03:23.57 |
starseeker |
oh, OK
;-) |
| 03:24.33 |
starseeker |
did do an m35 with fancy tires, but I think the "correct"
size looked kinda puny |
| 03:24.40 |
``Erik |
I was
figuring that procdb tires would look a lot better and provide a
lot mroe triangles without any signicant deepening of the
kd-tree |
| 03:24.49 |
starseeker |
bigger ones
overlaped, which I could ignore for screenshots but isst would
kinda care |
| 03:25.07 |
``Erik |
and I'd
recalled seeing and m35 with 2 tires replaces, so'z I was wondering
if there was one with all 11 or whatever redone |
| 03:25.23 |
starseeker |
true,
although the tires have some tree depth (4 or 5 levels, forget
offhand) |
| 03:25.34 |
``Erik |
(2+8+1,
right?) |
| 03:25.51 |
starseeker |
yeah, I had
done it once, but I don't know if I ever got it "right" in the
overlap free sense |
| 03:25.53 |
``Erik |
I doubt we're
talking the same trees |
| 03:26.03 |
starseeker |
probably
not |
| 03:26.12 |
starseeker |
is talkin csg tree |
| 03:26.22 |
``Erik |
libtie
kdtree's would fluff maybe a dozen or two in the tire
areas |
| 03:26.33 |
starseeker |
sh |
| 03:26.35 |
starseeker |
er
ah |
| 03:26.47 |
``Erik |
kd-tree's are
axis aligned binary splitting plane trees |
| 03:27.23 |
starseeker |
I think the
"right" way to do that is to generate tires without wheels and then
sub in for just the "rubber" part - should be able to
minimize/avoid overlaps that way |
| 03:27.39 |
starseeker |
the m35 wheel
is rather different from the tire tool's default wheel |
| 03:27.46 |
``Erik |
the wheels
you defined are very not military style |
| 03:28.06 |
starseeker |
yeah, was
just doing something "quick and dirty" |
| 03:28.27 |
``Erik |
heh, too much
"pretty", not enough "quick and dirty" :D |
| 03:28.39 |
starseeker |
lots of fun
that could be had with that tool, given time |
| 03:29.04 |
``Erik |
I can give
you a pretty correct rim for a stryker or hummer, they're utterly
boring |
| 03:29.17 |
``Erik |
the most
excitement is hidden by the rubber on 'em |
| 03:29.27 |
starseeker |
``Erik:
<snort> the whole thing was an exercise in "doing a proc-db",
just like the pen model was "learning mged" - establishing early on
my obsession with unnecessary detail ;-) |
| 03:29.36 |
``Erik |
y'know |
| 03:29.47 |
``Erik |
one of these
days, I'll do something like the pen exercise O.o |
| 03:30.04 |
starseeker |
``Erik: yeah,
for most real applications tire without wheel is probably how that
will get used - most people have purty wheels of their
own |
| 03:30.25 |
``Erik |
<-- came
in and was sat down with a machine, an os disc and a source disc...
told "port this to fbsd 5.1, then convert it to
autotools" |
| 03:30.41 |
starseeker |
``Erik: what,
you learn mged? Let me know when you do so I can pre-book skating
tickets for hell |
| 03:30.45 |
``Erik |
never had a
"learn how to model" phase |
| 03:30.58 |
starseeker |
or you could
wait til MGED 2.0 I suppose... |
| 03:31.16 |
``Erik |
no,
seriously, I wasn't allowed on the network, so I got a throw-away
machine, os disc and a cd with the source on it... |
| 03:31.23 |
``Erik |
and parked in
a room |
| 03:31.29 |
starseeker |
ah
:-) |
| 03:31.29 |
``Erik |
next to
mike |
| 03:32.03 |
``Erik |
first day,
"here's a mchine, here's an OS disc, here's the source... port
it." |
| 03:32.13 |
starseeker |
hehe |
| 03:32.23 |
starseeker |
yeah, I came
in a lot dumber :-P |
| 03:32.30 |
starseeker |
had to get up
to speed |
| 03:33.01 |
``Erik |
I had bsd
chops and auto* chops, but I did an awful lot of asking people to
test what I'd done to see if I'd done it right... |
| 03:33.09 |
``Erik |
e.e. was one
of my primary victems |
| 03:33.25 |
``Erik |
"bubba" |
| 03:33.49 |
``Erik |
and you came
in knowing a lot more about BRL-CAD than I did |
| 03:34.16 |
``Erik |
they were
nice to you :D |
| 03:34.17 |
starseeker |
well, the
coding/automake chops let you start doing "useful work"
pronto |
| 03:34.29 |
starseeker |
heh |
| 03:35.18 |
``Erik |
auto* was a
"possible way to go" at the time, not a guaranteed thing, it was
very much cake |
| 03:35.44 |
starseeker |
well, it sure
worked out in the end :-) |
| 03:37.46 |
``Erik |
I put a lot
of work into it, then brlcad went and did horrible horrible things
to my baby |
| 03:37.57 |
brlcad |
heh |
| 03:37.59 |
``Erik |
and now it's
a frankenstein monster :D |
| 03:38.05 |
brlcad |
now it's
complete |
| 03:38.29 |
starseeker |
so the
docbook stuff is just the icing on the cake in frankensteinian
terms? :-P |
| 03:38.36 |
``Erik |
um, I think
the tag exists in svn, something liek AUTOCONF_200311XX |
| 03:39.15 |
``Erik |
so when's the
old crud on brlcad.org migrating to crit, brlcad? :) |
| 03:40.30 |
starseeker |
brlcad: I
haven't had a chance to test it - did adding the mkdir commands to
the docbook build rules avoid that issue on highly parallel docbook
builds? |
| 03:41.20 |
brlcad |
starseeker:
dunno |
| 03:41.33 |
starseeker |
ah, k - have
to check when I get back in |
| 03:41.50 |
``Erik |
20031203 |
| 03:42.02 |
``Erik |
wow,w as much
simpler back then, configure.in was 225 lines |
| 03:42.02 |
starseeker |
also needs to check if the 3dm-g tool got busted by the
opennurbs upgrade... |
| 03:44.41 |
starseeker |
also need to
figure out how to enable the tk framebuffer without killing mged...
still not sure why that's happening |
| 03:45.10 |
starseeker |
kinda hard to
figure out how complete it is when it takes out the whole gui
:-( |
| 03:45.46 |
starseeker |
notes more SIGGRAPH spam has arrived... |
| 04:12.05 |
starseeker |
hrm - build
fails |
| 04:13.27 |
starseeker |
GlobalUnitAssignedContext.cpp:27 in
SdaiCONFIG_CONTROL_DESIGN.h:2534 error expected "," or "..." before
'&' token |
| 04:14.06 |
starseeker |
calls it a night |
| 04:18.36 |
*** join/#brlcad alex_jon1
(n=alex_jon@81.196.65.201) |
| 04:50.51 |
brlcad |
no /me
doesn't get that error |
| 07:22.27 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
| 11:04.01 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
| 11:21.06 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
| 11:24.41 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 11:42.30 |
``Erik |
dang, yet
more tkhtml3 breakage |
| 12:22.01 |
``Erik |
(apparently,
tclsh isn't always named tclsh, sometimes it's tclsh85) |
| 13:07.15 |
``Erik |
ßs hrm
http://www.collegehumor.com/video:1926917 |
| 14:41.41 |
d-lo_ |
``Erik: Sent
you an email at your gmail and bzflag.bz accounts. |
| 14:42.18 |
``Erik |
thanks |
| 15:01.38 |
CIA-38 |
BRL-CAD:
03brlcad * r37067 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c
g_bot_include.c): make RT_BOT_UNORIENTED_NORM() macro take the
in/out 'param' as a bool for indicating exit instead of toggling on
positive/negative. also nix the RT_ prefix as this is not public
api. |
| 15:41.35 |
brlcad |
haha...
http://www.collegehumor.com/video:1735402
(nsfw, but just because of language) |
| 15:42.03 |
brlcad |
that's
classic b'more |
| 16:12.10 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
| 16:13.56 |
``Erik |
oh, the car
commercial, yeh :D |
| 16:18.54 |
*** join/#brlcad mafm_
(n=mafm@63.Red-83-45-252.dynamicIP.rima-tde.net) |
| 16:21.46 |
CIA-38 |
BRL-CAD:
03indianlarry * r37068 10/brlcad/trunk/src/ (7 files in 2 dirs):
more warning quellage, also pushed back mods to fedex_plus
generated code |
| 16:47.15 |
d-lo_ |
that whole
FEDEX thing in the step code throws me off every time I see it.
lol |
| 17:10.08 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 18:18.15 |
CIA-38 |
BRL-CAD:
03brlcad * r37069 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
quell verbose warnings. there were two exact floating point
comparisons in here, so potential behavior change (i.e., hopefully
more robust/consistent). |
| 18:52.46 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 19:02.33 |
``Erik |
heh, I used
to work at FedEx, so imagine what it does to me :D |
| 19:07.31 |
CIA-38 |
BRL-CAD:
03brlcad * r37070 10/brlcad/trunk/src/librt/primitives/ (6 files in
3 dirs): more slews of quellage and cleanup, dead code elimination,
exact floating point comparisons, and param checking |
| 19:24.15 |
brlcad |
mm, the
problem was exactly what bob and I speculated last
night |
| 19:24.29 |
brlcad |
looks like
windows is being harsh on the tclIndx generation, at least more
strict |
| 19:24.36 |
brlcad |
and not
indexing some files |
| 19:25.21 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37071 10/brlcad/trunk/misc/win32-msvc8/
(adrt/adrt.vcproj brlcad/brlcad.sln): add adrt to brlcad
project |
| 19:31.03 |
``Erik |
Yes. I broke
it. Real bad. |
| 19:32.34 |
``Erik |
and msvc has
been 'not responding' for like fifteen minutes, so
*shrug* |
| 19:59.39 |
CIA-38 |
BRL-CAD:
03brlcad * r37072 10/brlcad/trunk/BUGS: too vague a bug, msvc build
files have changed drastically since then anyways |
| 20:02.58 |
CIA-38 |
BRL-CAD:
03brlcad * r37073 10/brlcad/trunk/BUGS: |
| 20:02.58 |
CIA-38 |
BRL-CAD: mged
on windows is not generating the tclindex files correctly. could be
a |
| 20:02.58 |
CIA-38 |
BRL-CAD:
simple parsing error or some other problem in the code bug a
variety of files |
| 20:02.58 |
CIA-38 |
BRL-CAD:
aren't getting indexed (notably the pattern tool and sketch editor
but also some |
| 20:02.58 |
CIA-38 |
BRL-CAD:
simple commands like bot and per_line. |
| 20:16.16 |
CIA-38 |
BRL-CAD:
03brlcad * r37074 10/brlcad/trunk/src/librt/primitives/bspline/ (10
files): quell all of the old nurbs code verbse warnings safe for
one bogus unreachable code warning on a goto label. lots and lots
of exact floating point comparisons.. should be more robust now
even if it is going away rsn. |
| 20:17.45 |
CIA-38 |
BRL-CAD:
03brlcad * r37075 10/brlcad/trunk/BUGS: reported that fbclear is
not working on windows build of mged. |
| 20:31.11 |
``Erik |
òò/cl |
| 20:32.34 |
CIA-38 |
BRL-CAD:
03brlcad * r37076 10/brlcad/trunk/include/opennurbs_ext.h: unused
quellage |
| 20:34.04 |
CIA-38 |
BRL-CAD:
03brlcad * r37077 10/brlcad/trunk/ (3 files in 2 dirs): add a
bu_list parameter so we can make rt_nurb_intersect get called
recursively when surfaces are split. this is an alternative to the
former goto method and quells an unreachable warning. |
| 20:34.33 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
| 20:44.15 |
CIA-38 |
BRL-CAD:
03brlcad * r37078 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c:
quell verbose dsp warnings. lots and lots of exact floating point
comparisons to zero and one changed to within tol
tests. |
| 20:44.49 |
CIA-38 |
BRL-CAD:
03brlcad * r37079 10/brlcad/trunk/src/librt/primitives/
(cline/cline.c dsp/dsp_brep.cpp): more param and unused var
quelling, s/log/logstr/ too |
| 20:46.36 |
``Erik |
hehehe
http://video.google.com/videoplay?docid=36099539665548298 |
| 20:55.08 |
brlcad |
that's an
oldie |
| 21:08.22 |
``Erik |
src/librt/primitives/nmg/nmg_rt_isect.c:1936:
error: too few arguments to function
'rt_nurb_intersect' |
| 21:08.36 |
``Erik |
forget to
commit something? |
| 21:18.51 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 21:26.03 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
| 21:29.20 |
CIA-38 |
BRL-CAD:
03brlcad * r37080
10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: blechk!
nmg cross-pollution with the old nurbs code.. rt_nurb_intersect()
had another param added. |
| 21:29.33 |
brlcad |
not reading
your commit diffs, eh? |
| 21:29.51 |
``Erik |
mine?
huh? |
| 21:30.42 |
brlcad |
nvr
mind |
| 21:40.40 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37081 10/brlcad/trunk/src/conv/iges/trimsurf.c:
add missing parameter |
| 21:41.55 |
brlcad |
wow |
| 21:41.56 |
brlcad |
that's just
wrong |
| 21:42.10 |
``Erik |
what, did I
break something horrible? |
| 21:42.12 |
brlcad |
iges
converter is actually shooting rays at nurbs |
| 21:42.23 |
``Erik |
oh,
heh |
| 21:42.40 |
brlcad |
what you did
is fine |
| 21:42.45 |
``Erik |
<-- just
did a monkey mimic of your patch to that file, didn't bother,
y'know, looking |
| 21:42.47 |
brlcad |
the fact that
the iges converter is doing that.... |
| 21:43.02 |
brlcad |
that any code
is calling that nurb internal routine |
| 21:43.07 |
``Erik |
so wasn't
sure if I screwed that up :) |
| 21:43.12 |
brlcad |
nah |
| 21:43.51 |
brlcad |
i'm still on
strict build, so can't build through to get to any latent
callers |
| 21:44.27 |
``Erik |
so build out
of dir and have two builds, one strict and one not :D |
| 21:48.15 |
brlcad |
this is
already so utterly painfully tedious as it is to make it twice as
painful |
| 21:48.41 |
brlcad |
all to
prevent the 1/100 chance that there's some triviality later in the
build |
| 21:50.59 |
brlcad |
it's also not
like anyone else is jumping in to help get these all taken care of
more quickly either :P |
| 22:00.40 |
``Erik |
yeah, damn
shame about that :D |
| 22:03.49 |
``Erik |
rt_bot_tess()
*sigh* why didn't I think of that earlier? |
| 22:06.57 |
CIA-38 |
BRL-CAD:
03brlcad * r37082 10/brlcad/trunk/src/librt/primitives/ (8 files in
6 dirs): mas quellerismos, floating point comparisons, unused
vars/params |
| 22:09.51 |
CIA-38 |
BRL-CAD:
03brlcad * r37083 10/brlcad/trunk/src/librt/primitives/
(extrude/extrude.c half/half.c table.c): s/free/release/ to avoid
shadowing the function |
| 22:53.44 |
*** join/#brlcad Nohla
(n=jesica@201.255.221.182) |
| 23:39.00 |
brlcad |
mm.. this
should be interesting |
| 23:39.06 |
brlcad |
floating
point comparisons in nmg |
| 23:39.28 |
``Erik |
heh, um, have
fun with that :D *duck* |
| 23:39.45 |
``Erik |
nmg's already
raytrace arse slow |
| 23:40.05 |
brlcad |
there are in
boolean evaluation, should help |
| 23:40.37 |
``Erik |
y'know, I"ve
seen geometry errors thrown on nmg tesselation... |
| 23:40.45 |
``Erik |
starting with
facet type nmg's... |
| 23:41.16 |
``Erik |
I'm not sure
if I'm willing to commit the time to chase that just yet, I have
other pressing issues to worry about |
| 23:41.38 |
``Erik |
but, ...
yeah, wtfage :) |
| 23:41.51 |
brlcad |
geometry
errors on nmg tess are normal |
| 23:42.02 |
brlcad |
part of it
guessing which paths to take |
| 23:42.22 |
``Erik |
soooo,
nmg->nmg is expected to fail? |
| 23:42.24 |
brlcad |
non-facet
nmgs are no longer relevant |
| 23:42.36 |
``Erik |
right, but
still listed as a flag |
| 23:42.41 |
``Erik |
and used in
some bits |
| 23:42.42 |
brlcad |
nmg->nmg
could fail depending how the original nmg was created |
| 23:42.47 |
``Erik |
g-nmg |
| 23:42.50 |
brlcad |
if it wasn't
validated |
| 23:43.17 |
brlcad |
that's so
high level as to be non-sensical to ask .. |
| 23:43.29 |
brlcad |
too many
variables |
| 23:43.32 |
brlcad |
above
regions, below regions |
| 23:43.34 |
brlcad |
combs,
prims |
| 23:43.56 |
brlcad |
is it
combining regions or leaving them as separate shels |
| 23:44.00 |
``Erik |
g-nmg likes
to convert a region to a single nmg and attach that as a single
object under the region |
| 23:44.25 |
``Erik |
(EXACTLY what
my 'recursive facetizer' card does... can kill that from Ed's
wall) |
| 23:44.40 |
brlcad |
right, but
how you were running it changes things too -- you feed it something
under a region, for example, or something with a mixed hierarchy
where there are paths that are regionless, etc |
| 23:45.06 |
``Erik |
hm, saw it on
m35 |
| 23:45.21 |
brlcad |
just saying
it's way to vague a notion to say anything meaningful, way too many
variables unaccounted for |
| 23:45.30 |
brlcad |
can't even
say it's clean input |
| 23:45.39 |
``Erik |
I'll look
into it a bit when I'm in the office tomorrie |
| 23:45.53 |
brlcad |
m35 has
problems |
| 23:45.59 |
brlcad |
whether they
matter or not.. dunno |
| 23:46.11 |
brlcad |
it's gone
both ways in the past |
| 23:46.36 |
``Erik |
either way,
there are issues to be addressed wrt... |
| 23:47.15 |
``Erik |
if our
reference geometry is screwed up, that's bad... if our tools
produce bad output... that's bad :) |
| 23:47.52 |
brlcad |
I think the
problem has to be brought back down to basic test cases, make sure
primitives all tessellate (which they won't) .. then 0-level
combinations |
| 23:48.36 |
``Erik |
I have a well
tesselated m35 (10x better than default tolerance), if it's
useful... had one going where the side mirrors gave 200k triangles,
killed it :/ |
| 23:49.05 |
``Erik |
on the up
side, these issues are giving me impetus to do the marching cubes
thang |
| 23:49.24 |
``Erik |
"cuz lee
said" kinda deflated me |
| 23:49.31 |
brlcad |
g-nmg
producing a bad nmg just isn't a good measure of anything -- if it
did something wrong, could be a simple bug isolated to that
specific tool or the tess approach it uses |
| 23:50.10 |
``Erik |
the tool
itself is too trivial to break |
| 23:50.19 |
brlcad |
the approach
most of those use isn't so hot |
| 23:50.24 |
``Erik |
too small to
fail :D |
| 23:50.26 |
brlcad |
I opted for a
slightly diff approach for the ef work |
| 23:50.31 |
``Erik |
ef? |
| 23:50.31 |
brlcad |
more
robust |
| 23:50.57 |
brlcad |
endgame |
| 23:51.03 |
``Erik |
ah |
| 23:51.30 |
``Erik |
I thought our
contribution to their federation was more "give us a geometry name
and ray, we give you a prtition list"? |
| 23:51.41 |
brlcad |
nothing
reusable code-wise, but just a note that the approach they use now
isn't consistent across the exporters |
| 23:51.47 |
``Erik |
well, no,
they do ogl visualization, ya had to gie them triangels |
| 23:51.54 |
``Erik |
had to give
them triangles |
| 23:52.04 |
CIA-38 |
BRL-CAD:
0367.232.178.197 07http://brlcad.org * r2055
10/wiki/MGED_CMD_eac: |
| 23:52.13 |
brlcad |
not at all,
did a geometry exporter -- basically .g to their format |
| 23:52.13 |
CIA-38 |
BRL-CAD:
0367.232.178.197 07http://brlcad.org * r2056
10/wiki/MGED_CMD_whichair: |
| 23:52.17 |
brlcad |
which was
poly |
| 23:52.31 |
``Erik |
ok, so an
exporter, not a federation entity |
| 23:59.46 |
brlcad |
oh
wow |
| 23:59.50 |
brlcad |
the code is
still in there... |
| 00:00.11 |
brlcad |
there's debug
code in nmg that supposedly will animate the boolean evaluation as
it proceeds... |
| 00:01.14 |
brlcad |
i'd seen a
mid-90's video of it in action, but didn't realize it wasn't a temp
hack |
| 00:01.32 |
brlcad |
huh |
| 00:01.40 |
brlcad |
something to
poke at later |
| 00:02.11 |
brlcad |
rt_g.NMG_debug => DEBUG_PL_ANIM
flag |
| 00:30.57 |
``Erik |
O.o |
| 02:22.34 |
CIA-38 |
BRL-CAD:
03brlcad * r37084
10/brlcad/trunk/src/librt/primitives/nmg/nmg_fcut.c: fix a bug in
nmg_insert_vu_if_on_edge() where the new edgeuse wasn't getting
set/returned to the caller. additionally quellage cleanup for exact
floating point comparisons and unused params |
| 02:27.32 |
CIA-38 |
BRL-CAD:
03brlcad * r37085 10/brlcad/trunk/src/librt/primitives/ (14 files
in 8 dirs): major quellage, dead code elimination, unused
params/vars, exact floating point comparisons. |
| 02:58.53 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1279332335.dsl.bell.ca) |
| 03:24.04 |
Ralith |
``Erik:
[considering] building a marching cubes tesselator? |
| 03:45.20 |
CIA-38 |
BRL-CAD:
03brlcad * r37086 10/brlcad/trunk/src/librt/primitives/nmg/
(nmg_ck.c nmg_fuse.c nmg_mod.c): |
| 03:45.20 |
CIA-38 |
BRL-CAD:
remove nmg_eu_radial_check() since it was commented out and the
uncommented |
| 03:45.20 |
CIA-38 |
BRL-CAD:
version had not easily resolvable constness problems (it needed a
non-const copy |
| 03:45.20 |
CIA-38 |
BRL-CAD: of
it's edgeuse to pass to nmg_radial_build_list() yet that list then
becomes |
| 03:45.20 |
CIA-38 |
BRL-CAD:
disassociated with its eu if it is copied). also a few exact
floating point |
| 03:45.23 |
CIA-38 |
BRL-CAD:
comparisons changed. |
| 03:50.49 |
``Erik |
ralith:
funded and working on it. |
| 03:53.26 |
Ralith |
awesome! |
| 03:53.57 |
Ralith |
<PROTECTED> |
| 03:54.11 |
Ralith |
proportional
to grid size, of course |
| 04:05.48 |
``Erik |
yes, very
grid sized impacted |
| 04:06.18 |
``Erik |
exploratory
experiments indicate taking up to a millenia for a vehicle sized
object at bn tolerance |
| 04:08.08 |
``Erik |
aaaanyways,
it's gonna work in metaballs as a primitive tesselator, first... so
if you're seriously interested, watch there :) |
| 04:31.03 |
*** join/#brlcad IriX64
(n=Warlock@bas2-sudbury98-1177593190.dsl.bell.ca) |
| 04:43.54 |
CIA-38 |
BRL-CAD:
0367.232.178.197 07http://brlcad.org * r2057
10/wiki/MGED_CMD_loadtk: |
| 05:44.06 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 06:26.36 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331981.dsl.bell.ca) |
| 07:12.25 |
CIA-38 |
BRL-CAD:
03brlcad * r37087 10/brlcad/trunk/src/librt/primitives/nmg/
(nmg_info.c nmg_inter.c): more quelling. marking unused params,
fixing integer conversion types, unreachable code, shadowing, and
exact floating point comparisons. |
| 07:21.20 |
CIA-38 |
BRL-CAD:
03brlcad * r37088
10/brlcad/trunk/src/librt/primitives/nmg/nmg_manif.c: it's
unsigned, can't be negative |
| 07:21.42 |
CIA-38 |
BRL-CAD:
03brlcad * r37089
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: stray quote
and wrong dist fixed |
| 07:40.09 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1279332188.dsl.bell.ca) |
| 08:41.35 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2058
10/wiki/BRL-CAD_Primitives: |
| 08:52.04 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 09:32.30 |
CIA-38 |
BRL-CAD:
03brlcad * r37090
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: a bit more
complicated quellification. lots of mixed shadowing going on, but
no more. also exact floating point compares. mark unused
params. |
| 09:51.32 |
CIA-38 |
BRL-CAD:
03brlcad * r37091
10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: |
| 09:51.32 |
CIA-38 |
BRL-CAD:
getting a handle on this one took some unexpected concentration.
reworked the |
| 09:51.32 |
CIA-38 |
BRL-CAD:
logic slightly to avoid the goto jump that was being used to
restart the edge |
| 09:51.32 |
CIA-38 |
BRL-CAD:
testing. it's actually simple enough to let it fall through if we
just make |
| 09:51.33 |
CIA-38 |
BRL-CAD: sure
we let it keep track of the edge table correctly (removing our edge
before |
| 09:51.35 |
CIA-38 |
BRL-CAD:
testing verts, not after). add comments as to what's going
on. |
| 10:09.34 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2059
10/wiki/BRL-CAD_Primitives: |
| 10:15.02 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2060
10/wiki/BRL-CAD_Primitives: /* ellg */ |
| 10:18.27 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2061
10/wiki/BRL-CAD_Primitives: /* Ellipsoids */ |
| 10:27.40 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2062
10/wiki/BRL-CAD_Primitives: /* Other */ |
| 10:29.03 |
CIA-38 |
BRL-CAD:
03brlcad * r37092
10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: another goto
rewrite, this one a bit simpler. plus a few floating point
comparison tests. |
| 10:29.06 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2063
10/wiki/BRL-CAD_Primitives: /* pipe */ |
| 10:37.20 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2064
10/wiki/BRL-CAD_Primitives: /* Other solids */ |
| 10:39.54 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2065
10/wiki/Talk:Main_Page: New section: [[Talk:Main Page#BRL-CAD
Primitives|BRL-CAD Primitives]] |
| 10:41.00 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2066
10/wiki/User:Ssd: New page: I'm just a brl-cad user with a lot of
mediawiki experience. Projects I'm currently working on: *
[[:Category:MGED]] * [[BRL-CAD Primitives]] |
| 10:42.36 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2067
10/wiki/Talk:Main_Page: /* BRL-CAD Primitives */ |
| 10:43.21 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2068
10/wiki/BRL-CAD_Primitives: /* Sketch */ |
| 10:45.09 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2069
10/wiki/MGED_CMD_make: /* Description */ |
| 10:47.03 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2070
10/wiki/BRL-CAD_Primitives: /* grip */ |
| 10:48.41 |
CIA-38 |
BRL-CAD:
03brlcad * r37093 10/brlcad/trunk/ (11 files in 2
dirs): |
| 10:48.41 |
CIA-38 |
BRL-CAD: and
with this WHOOOSH.. the remainder of nmg is quellified. quieted
sign |
| 10:48.41 |
CIA-38 |
BRL-CAD:
warnings, unused params, shadow vars, and floating point
comparisons (which now |
| 10:48.41 |
CIA-38 |
BRL-CAD: test
via computation tolerance). go ahead and change some of the
signatures for |
| 10:48.41 |
CIA-38 |
BRL-CAD:
funcs that had unused params that provided little stubbed
benefit. |
| 10:50.48 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2071
10/wiki/BRL-CAD_Primitives: /* metaball */ |
| 10:52.42 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2072
10/wiki/BRL-CAD_Primitives: |
| 11:47.37 |
*** join/#brlcad mafm_
(n=mafm@63.Red-83-45-252.dynamicIP.rima-tde.net) |
| 12:16.11 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 12:16.11 |
*** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1)
[NETSPLIT VICTIM] |
| 12:16.11 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad alex_jon1 (n=alex_jon@81.196.65.201)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad stevegt` (n=stevegt@cislunar.TerraLuna.Org)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 12:16.12 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 12:16.12 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 12:16.35 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 12:17.13 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
| 14:17.23 |
``Erik |
stupid
snow |
| 14:25.00 |
brlcad |
heh |
| 14:36.46 |
``Erik |
no plow here
and the snow is up on the rims of the cars outside |
| 14:36.55 |
``Erik |
so'z I'm
immobilized |
| 16:15.28 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1279332188.dsl.bell.ca) |
| 16:39.02 |
brlcad |
starting to
melt here, I think I can make it about now |
| 16:39.25 |
brlcad |
is happy that more than half of librt is clean
now |
| 16:40.26 |
brlcad |
those nmg
changes should be interesting.. either made things a little better
or a little worse, but either way they're now more well-defined
:) |
| 16:40.46 |
brlcad |
few places I
was pretty sure I saw bugs, but needed more careful attention
.. |
| 16:41.03 |
brlcad |
we really
could probably hammer down that whole api and make it work without
too much effort |
| 16:41.11 |
brlcad |
via test
driven development |
| 16:41.40 |
brlcad |
that api
already breaks things down into neatly isolated routines that
generally are written to perform one function |
| 16:44.02 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2073
10/wiki/BRL-CAD_Primitives: /* dsp */ |
| 16:46.55 |
``Erik |
<-- lives
up in hills, it's a good 5 degrees cooler here than work :/ damn
weird, driing out on ice, then driving in water for 95 % of the
trip |
| 16:48.13 |
``Erik |
bobby and
daytona have trucks, I imagine starseeker will start seein some
"work from home" days soon |
| 16:50.13 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2074
10/wiki/BRL-CAD_Primitives: /* half */ |
| 16:50.24 |
brlcad |
go go gadget
ssd |
| 16:55.01 |
``Erik |
heh |
| 16:57.00 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2075
10/wiki/BRL-CAD_Primitives: /* tgc */ |
| 16:59.37 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2076
10/wiki/BRL-CAD_Primitives: /* trc */ |
| 17:00.05 |
starseeker |
thought it was supposed to be rain, not
snow... |
| 17:00.10 |
starseeker |
grumble... |
| 17:00.25 |
``Erik |
yeh |
| 17:00.54 |
``Erik |
hey, tkhtml
expecting tclsh instead of tclsh85... is there a clean
solution? |
| 17:01.08 |
starseeker |
not
sure |
| 17:01.20 |
``Erik |
hm |
| 17:01.38 |
``Erik |
a 'virgin'
bsd system freaks out on that |
| 17:01.40 |
starseeker |
since we're
going to be maintaining tkhtml3, we could always have its configure
script look for tclsh85 if tclsh isn't found |
| 17:01.51 |
``Erik |
84 85 86...
or take a parameter |
| 17:02.11 |
starseeker |
TEA really
needs to be made to play with autotools |
| 17:02.22 |
starseeker |
we need a
configure.ac/Makefile.am solution |
| 17:02.38 |
starseeker |
once I get
back I'll take a look at the work apache did along those
lines |
| 17:02.46 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2077
10/wiki/BRL-CAD_Primitives: /* nmg */ |
| 17:03.09 |
starseeker |
if I get
something actually clean/useful put together, I'll email the TEA
folks and see what there take on things is... |
| 17:03.19 |
brlcad |
starseeker:
ssd had a question about all the primitives (see
/wiki/Talk:Main_Page) |
| 17:03.29 |
brlcad |
didn't you
have something started there too? |
| 17:05.05 |
starseeker |
I did, but it
looks like he's ahead of me |
| 17:05.26 |
starseeker |
except
probably for the categorization of primitives |
| 17:05.54 |
starseeker |
http://bzflag.bz/~starseeker/geometric_primitives.txt |
| 17:07.57 |
brlcad |
ah, good
stuff -- you should share that with him |
| 17:08.05 |
brlcad |
he's all
about categorization |
| 17:08.39 |
brlcad |
couple of his
prims aren't prims, but input methods |
| 17:08.45 |
brlcad |
like
'box' |
| 17:09.00 |
starseeker |
nods |
| 17:09.14 |
brlcad |
and a few
partially implemented ones missing |
| 17:09.17 |
starseeker |
doing the
password reset thing for my website account |
| 17:10.01 |
starseeker |
maybe... |
| 17:10.07 |
starseeker |
hello
email... |
| 17:12.09 |
starseeker |
is impressed - he actually got the ars primitive to do
something |
| 17:13.22 |
brlcad |
I did that
one |
| 17:13.58 |
starseeker |
ah
:-) |
| 17:14.00 |
``Erik |
heh |
| 17:14.03 |
starseeker |
is still impressed |
| 17:14.15 |
starseeker |
that ANYONE
got the ars primitive to do something :-P |
| 17:15.04 |
brlcad |
it's a pretty
simple waterline primitive |
| 17:15.06 |
brlcad |
just not
"recently" documented |
| 17:15.07 |
``Erik |
ponders trying to develop a quip regarding brlcad's ars...
decides not to |
| 17:15.50 |
brlcad |
it's one of
those goodies in the rel 4 docs that should be posted up on the
set |
| 17:16.24 |
``Erik |
rt_bot_tess
really does look like the best example :/ |
| 17:16.40 |
``Erik |
damn that
daytona for being smarter than all of us :/ |
| 17:18.44 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 17:23.44 |
CIA-38 |
BRL-CAD:
0396.234.232.166 07http://brlcad.org * r2078
10/wiki/Talk:Main_Page: Add note about geometric primitives
categorization |
| 17:25.21 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2079
10/wiki/BRL-CAD_Primitives: /* dsp */ |
| 17:33.32 |
CIA-38 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2080 10/wiki/Talk:Main_Page: note there are still a couple "work
in progress" primitives uncategorized |
| 17:34.55 |
starseeker |
hunts lunch |
| 17:40.39 |
``Erik |
<-- did
spaghetti noodles and egg with apple sauce O.o |
| 17:41.26 |
brlcad |
you put apple
sauce on spaghetti? nasty. |
| 17:41.53 |
brlcad |
freak |
| 17:45.08 |
``Erik |
heh |
| 17:45.22 |
``Erik |
it's not like
italian spaghetti, it's very german :D eggs fried with butter, then
egg scrambled into them, covered with apple sauce... |
| 17:45.25 |
``Erik |
it's
good |
| 17:45.54 |
``Erik |
er, spaghetti
noodles fried with butter |
| 17:46.17 |
``Erik |
when ya eat
it, you cut it and scoop witht eh fork instead of
swirling |
| 17:46.45 |
``Erik |
you put
shrimp or white fish in lemon juice? freak. |
| 17:48.18 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2081
10/wiki/BRL-CAD_Primitives: /* ebm */ |
| 17:48.21 |
brlcad |
do you salt
the apple sauce? |
| 17:48.44 |
brlcad |
because that
just sounds nasty if it's sweet |
| 17:48.57 |
brlcad |
seafood in
lemon juice is salted :) |
| 17:50.47 |
``Erik |
<PROTECTED> |
| 17:51.03 |
``Erik |
the apple
suace is there to add contrast, as a topping |
| 17:51.22 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2082
10/wiki/BRL-CAD_Primitives: /* vol */ |
| 17:51.54 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2083
10/wiki/BRL-CAD_Primitives: /* part */ |
| 17:53.34 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2084
10/wiki/BRL-CAD_Primitives: /* Other */ |
| 17:53.54 |
``Erik |
(and quite a
bit of german cuisine is "ew gross" until you try it) |
| 17:55.42 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2085
10/wiki/BRL-CAD_Primitives: /* ebm */ |
| 18:08.06 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2086
10/wiki/BRL-CAD_Primitives: /* bot */ |
| 18:41.19 |
brlcad |
would rather code his way into the new year but is going to
get sucked into festivities |
| 18:45.36 |
CIA-38 |
BRL-CAD:
03brlcad * r37094 10/brlcad/trunk/src/librt/primitives/part/part.c:
mas quellage. usual suspects. |
| 19:05.01 |
``Erik |
heh |
| 20:00.29 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2087
10/wiki/BRL-CAD_Primitives: /* bot */ |
| 20:05.58 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2088
10/wiki/BRL-CAD_Primitives: /* rpp */ |
| 20:53.48 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
| 20:53.48 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad stevegt` (n=stevegt@cislunar.TerraLuna.Org)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad d-lo_ (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
| 20:53.48 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
| 20:53.48 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
| 21:18.04 |
starseeker |
./.libs/librt.so: undefined reference to
`RT_CK_HITP' |
| 21:18.06 |
starseeker |
hrm |
| 21:18.52 |
starseeker |
greps... |
| 21:27.55 |
starseeker |
ah,
sketch.c |
| 21:28.28 |
starseeker |
is RT_CK_HITP
something someone forgot to check in or does that need to go
bybye? |
| 21:54.41 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2089
10/wiki/BRL-CAD_Primitives: /* box */ |
| 22:01.12 |
starseeker |
ooo |
| 22:01.23 |
starseeker |
discovers http://common-lisp.net/~loliveira/ediware/
and updates his lisp updating script |
| 22:01.27 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2090
10/wiki/BRL-CAD_Primitives: /* extrude */ |
| 22:05.22 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2091
10/wiki/BRL-CAD_Primitives: /* grip */ |
| 22:08.24 |
*** join/#brlcad guillermina
(n=guillerm@124-133-231-201.fibertel.com.ar) |
| 22:09.18 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2092
10/wiki/Talk:Main_Page: /* BRL-CAD Primitives */ |
| 22:10.42 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2093
10/wiki/Talk:Main_Page: /* BRL-CAD Primitives */ |
| 22:12.49 |
Nohla |
holas |
| 22:13.14 |
Nohla |
congratulations for the summer of
code!!! |
| 22:13.53 |
Nohla |
brlcad: this
summer seems to be warmer |
| 22:14.39 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1279332188.dsl.bell.ca) |
| 22:19.34 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2094
10/wiki/Talk:BRL-CAD_Primitives: New page: Other sources for
information: *
http://brlcad.org/wiki/A_Survey_of_Implicit_Constraints_in_Primitives
* http://bzflag.bz/~starseeker/geometric_primitives.txt
* scattered through all brl-c... |
| 22:22.33 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2095
10/wiki/Talk:BRL-CAD_Primitives: |
| 22:23.17 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2096
10/wiki/Talk:BRL-CAD_Primitives: |
| 22:28.54 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2097
10/wiki/BRL-CAD_Primitives: /* Other solids */ add 2d derived
category |
| 22:29.55 |
``Erik |
heh, (incl
edi) |
| 22:31.33 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2098
10/wiki/BRL-CAD_Primitives: /* dsp */ |
| 22:31.46 |
starseeker |
ooo,
cl-base64, uffi and a few others here: http://www.b9.com/blog/index.html |
| 22:32.29 |
``Erik |
uffi vs cffi
keeps confusing me :/ |
| 22:32.54 |
``Erik |
I'm under the
impression that for a ne wproject, cffi is a better approach... but
I'm not sure |
| 22:33.10 |
``Erik |
and I wanna
do a lisp hook over say, libtie/adrt |
| 22:34.03 |
``Erik |
how dead is
dead, which is the front runner, etc |
| 22:35.10 |
Nohla |
starseeker:
hi |
| 22:35.10 |
starseeker |
Nohla: howdy
:-) |
| 22:35.10 |
starseeker |
``Erik: yeah,
I think uffi is the way to go |
| 22:35.10 |
starseeker |
er
cffi |
| 22:35.10 |
starseeker |
NOT
uffi |
| 22:35.22 |
starseeker |
uffi is still
needed by some libraries that haven't been updated in a
while |
| 22:35.38 |
``Erik |
see? see?
thus the confusion |
| 22:35.42 |
starseeker |
thinks linedit may be tha main culprit... |
| 22:35.44 |
Nohla |
starseeker: a
lot of time has passed since the last time :P |
| 22:35.51 |
starseeker |
Nohla: last
time? |
| 22:36.17 |
Nohla |
we see each
other :)+ |
| 22:36.45 |
Nohla |
i've bought
the projector today :) |
| 22:37.03 |
Nohla |
and... |
| 22:37.10 |
Nohla |
it's my
birthday |
| 22:37.19 |
starseeker |
ah
congratulations! |
| 22:37.26 |
``Erik |
happy bday,
nohla! |
| 22:37.40 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2099
10/wiki/BRL-CAD_Primitives: /* ebm */ |
| 22:38.21 |
Nohla |
starseeker:
the second tutorial is done :) |
| 22:38.36 |
starseeker |
Nohla:
excellent!! |
| 22:39.01 |
``Erik |
do you have
people without any english knowlege trying your tutorials as a test
case? |
| 22:39.05 |
Nohla |
but "make"
was difficult to run because the battery is going to wave hands
with God |
| 22:39.32 |
``Erik |
(are there
people without english knowlege down there?) |
| 22:41.32 |
Nohla |
the next
sunday will be a party at home |
| 22:42.18 |
starseeker |
Nohla: you
can run "make" just in the directory doc/docbook/ |
| 22:42.26 |
Nohla |
hope that
day, the student who asked for this tutorials appear |
| 22:43.00 |
Nohla |
starseeker:
I'm not with my notebook right now |
| 22:43.42 |
starseeker |
Nohla: ah. k,
no problem :) |
| 22:43.45 |
starseeker |
just so you
know |
| 22:44.18 |
Nohla |
``Erik: 3
people read the 1st tutorial |
| 22:44.40 |
Nohla |
you convince
me and I'll install brlcad this weekend :P |
| 22:46.21 |
Nohla |
and promised
the third for this weekend too... |
| 22:46.43 |
Nohla |
mmm... I'll
do my best |
| 22:46.55 |
``Erik |
is gonna go deaf fromt he purring O.o |
| 22:47.01 |
Nohla |
alcohol is
not the best friend of translating |
| 22:47.12 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
| 22:47.27 |
``Erik |
perhaps not,
but it makes the code flow :D |
| 22:47.47 |
``Erik |
if I werent'
covered in cats, I'd go get a drink in response |
| 22:48.52 |
Nohla |
``Erik: what
kind of cats? XD |
| 22:49.29 |
``Erik |
domestic, a
pair, from the same litter, from the local 'rescue'
association |
| 22:49.43 |
``Erik |
http://brlcad.org/~erik/20091025/ |
| 22:51.50 |
Nohla |
mine came
from a similar place :) |
| 22:53.00 |
``Erik |
<-- hopes
his cats are happy, thinks they're better off than being in the
wild or in a cage |
| 22:54.28 |
Nohla |
hi's
something in his skin, needs vitamin |
| 22:55.04 |
``Erik |
ah, the food
doesn't provide? |
| 22:55.05 |
Nohla |
"Te hacen
falta vitaminas... vitaminas" (National Rock from down
here) |
| 22:55.55 |
Nohla |
seems needs
more |
| 22:55.56 |
``Erik |
needs to go to the store and get more food in the next week
or two :/ |
| 22:57.35 |
Nohla |
guys, good
night. I'll take a nap :) |
| 22:58.06 |
``Erik |
hasta
manana |
| 22:58.08 |
Nohla |
years do not
go alone |
| 22:58.16 |
``Erik |
happy new
years :) |
| 22:58.21 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
| 22:58.51 |
Nohla |
for me and
for this decade |
| 22:59.42 |
Nohla |
starseeker:
we should talk more, as the very beginning |
| 23:13.01 |
*** join/#brlcad csanyipal
(n=csanyipa@110-142-85-95.dynamic.stcable.net) |
| 23:13.09 |
csanyipal |
Hi, |
| 23:13.22 |
csanyipal |
just to say:
Happy new year!! :D |
| 23:13.59 |
``Erik |
happy new
years, csanyipal :) |
| 23:14.06 |
csanyipal |
:) |
| 23:43.14 |
*** join/#brlcad mafm_
(n=mafm@63.Red-83-45-252.dynamicIP.rima-tde.net) |
| 23:43.58 |
starseeker |
Nohla: you
are doing well :-) |
| 23:44.18 |
starseeker |
just need to
get you committing ;-) |
