00:16.01 |
starseeker |
kanzure: yeah, boole isn't the way for us to
go these days |
00:31.15 |
kanzure |
esolid compiles and the visualizer works.
yikes |
00:31.33 |
kanzure |
does anyone know about esolid's licensing? i
can't find a license or copyright file anywhere |
01:04.26 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177871751.dsl.bell.ca) |
02:29.50 |
*** join/#brlcad crazy_imp
(~mj@a89-182-207-95.net-htp.de) |
03:21.24 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
06:41.04 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
06:46.22 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
07:35.56 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
08:17.25 |
*** join/#brlcad mafm
(~mafm@36.Red-81-35-69.dynamicIP.rima-tde.net) |
10:00.13 |
CIA-105 |
BRL-CAD: 03davidloman * r44494
10/geomcore/trunk/include/ (GeometryManifestMsg.h NetMsg.h
PingMsg.h PongMsg.h): Clean up some unused includes. |
10:02.02 |
CIA-105 |
BRL-CAD: 03davidloman * r44495
10/geomcore/trunk/src/libNet/netMsg/ (PingMsg.cxx
RemoteNodenameSetMsg.cxx): Clean up a few more unused
includes. |
10:29.29 |
*** join/#brlcad csanyipal
(~csanyipal@226-170-85-95.dynamic.stcable.net) |
10:29.37 |
csanyipal |
Hi, |
10:32.44 |
csanyipal |
I'm reading SVN/brlcad/doc/legal/bdl.txt,
bsd.txt, lgpl.txt and want to know, whether can I use the html
documents in a Moodle course of BRL-CAD? |
11:07.19 |
CIA-105 |
BRL-CAD: 03davidloman * r44496
10/geomcore/trunk/tests/unit/utility/ (ByteBufferUTest.cxx
ByteBufferUTest.h): Clean up extra newlines |
11:18.51 |
*** join/#brlcad mafm_
(~mafm@36.Red-81-35-69.dynamicIP.rima-tde.net) |
11:20.13 |
CIA-105 |
BRL-CAD: 03davidloman * r44497
10/geomcore/trunk/tests/unit/libnet/ (4 files): Drop the 's' from
Msgs |
11:22.29 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
11:57.16 |
brlcad |
csanyipal: you sure can -- most of the docs
are either bsd-licensed or public domain |
11:57.37 |
csanyipal |
brlcad: thanks! :) |
12:08.58 |
brlcad |
kunigami, bhinesley congratulations and thanks
:) |
12:09.26 |
brlcad |
you guys were the clear choices |
12:10.24 |
brlcad |
as for mentors, keep in mind that you can and
SHOULD utilize the mentoring resources of any brl-cad
developer |
12:11.00 |
brlcad |
the one assigned is merely the one that will
likely be tracking your progress and filling out your evals, but
technical assistance is from all |
12:30.42 |
starseeker |
kanzure: I'd try the contact emails:
http://research.cs.tamu.edu/keyser/geom/esolid/releases/version_0.3/README.htm
see if they'd be OK with LGPL or BSD license |
12:31.43 |
starseeker |
kanzure: bear in mind esolid is sssslllooowww,
if what I remember about it is accurate. It's not a method we'd
want to rely on except perhaps as a last-ditch fallback |
13:09.46 |
CIA-105 |
BRL-CAD: 03davidloman * r44498
10/geomcore/trunk/ (4 files in 3 dirs): No reason for GSUUID to
take a pointer to a string. |
13:14.49 |
starseeker |
asc2g isn't processing the attr command using
ged_attr |
13:37.46 |
CIA-105 |
BRL-CAD: 03davidloman * r44499
10/geomcore/trunk/src/utility/ByteBuffer.cxx: Make
ByteBuffer::toHexString() format the hex string properly. |
13:51.33 |
CIA-105 |
BRL-CAD: 03davidloman * r44500
10/geomcore/trunk/ (6 files in 5 dirs): Make GSUUID::toString
return a string, not a pointer. All uses of this call were simply
dereferencing the pointer anyway, and most weren't releasing the
memory. Keeping it simpler this way. |
13:54.17 |
CIA-105 |
BRL-CAD: 03davidloman * r44501
10/geomcore/trunk/tests/func/ (3 files in 3 dirs): More
GSUUID::toString() pointer dereferencing. |
13:56.52 |
CIA-105 |
BRL-CAD: 03starseeker * r44502
10/brlcad/trunk/src/libged/attr.c: Standardize the avs used by attr
set - this still isn't fixing asc2g, which uses an older style API
of some sort. |
14:05.18 |
CIA-105 |
BRL-CAD: 03davidloman * r44503
10/geomcore/trunk/tests/unit/ (5 files in 2 dirs): Rename
NetMsgUTest to TypeOnlyMsgUTest for clarity. Finished implementing
TypeOnlyMsgUTest. Will serve as the baseline test for all netmsg
subclasses. |
14:05.35 |
``Erik |
hm, if I understand correctly, passing a class
by value creates a copy on the stack (with a constructor call) and
destructor on return, that's why I was going pointer happy
(defining pass by reference is a different way to invoke pointer
shtuff, iirc... been a long time) |
14:07.20 |
dloman_ |
understood, however the more pointers there
are, the much higher chance there is of a leak. So i simplified a
bit. If its a perf hit, then someone can optimize later
:) |
14:10.19 |
``Erik |
*shrug* *pats the lithp version, with
generational compacting garbage collection* |
14:10.53 |
dloman_ |
oh how i wish i could have used a language
with memory management :) |
14:11.03 |
``Erik |
java's gc is pretty good if you remember to
set the turds to null when you're done with them... d'no about
recently, but it USED to get confused and leave them |
14:11.49 |
dloman_ |
ya. it will still gs them, but it takes a
significant amount of additional checks to figger out if the
pointer isn't being used anymore |
14:11.50 |
``Erik |
cyclic references with no top level heap walk,
etc |
14:12.29 |
``Erik |
hm, probably using ref counting for the first
few generations, then a heap walker of some kind in the older
generations, or 'on occasion' |
14:12.38 |
dloman_ |
exactly |
14:12.54 |
dloman_ |
which is why the young gneneration gc is
wicked fast. |
14:13.51 |
dloman_ |
been looking at C# a lot recently. rather
interesting langauge |
14:13.54 |
CIA-105 |
BRL-CAD: 03davidloman * r44504
10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Ooops.
Forgot to update the header include! |
14:14.01 |
``Erik |
btw, why are ya shuffling a 128 bit number
around as a hex string? (uuids) |
14:14.38 |
dloman_ |
cause i haven't gotten around to just writing
the bytes to the ByteBuffer yet. keeps the debugging of the proto
easier too. |
14:15.28 |
``Erik |
kinda likes the notion fo
starting out as a pure ascii format, then having a command to
switch to a tight binary |
14:15.41 |
``Erik |
so you can get the protocol sorted using
telnet :) |
14:15.45 |
CIA-105 |
BRL-CAD: 03davidloman * r44505
10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Again...
wrong header. |
14:16.17 |
dloman_ |
well, i have a severe lack of experience with
this, hence the severe lateness. :/ |
14:26.22 |
*** join/#brlcad WhiteCalf
(MK@whitecalf.net) |
14:27.40 |
CIA-105 |
BRL-CAD: 03davidloman * r44506
10/geomcore/trunk/tests/unit/ (4 files in 2 dirs): Compact test
classes down to single files instead of class impl and header
pairs. |
14:30.51 |
CIA-105 |
BRL-CAD: 03davidloman * r44507
10/geomcore/trunk/tests/unit/ (libnet/TypeOnlyMsgUTest.cxx
utility/ByteBufferUTest.cxx): CPPUNIT_TEST_CUITE_REGISTRATION()
calls are supposed to be *after* class declaration. |
14:42.38 |
CIA-105 |
BRL-CAD: 03davidloman * r44508
10/geomcore/trunk/ (3 files in 3 dirs): Pull two unused methods
out. |
15:10.12 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
15:42.46 |
CIA-105 |
BRL-CAD: 03Erik 07http://brlcad.org * r2857
10/wiki/NetMsgTypes: Add ls message req/res. Add multistring
msg. |
15:44.47 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44509
10/geomcore/trunk/include/NetMsgTypes.h: add bot request and list
request/result. |
15:47.37 |
dloman_ |
``Erik: whats the difference between
GeometryBotReq and GeometryReq? |
15:48.22 |
CIA-105 |
BRL-CAD: 03Erik 07http://brlcad.org * r2858
10/wiki/GenericMultiStringMsg: multistring message |
15:48.42 |
``Erik |
GeometryBoTReq returns BoT's, one per region
(no CSG) for use in OGL, vsl, isst, etc |
15:49.15 |
dloman_ |
so its a request for geometry + request for
conversion to bot ? |
15:49.46 |
``Erik |
yeh, sorta... hopefully we can cache the BoT
variants of the regions, and will have fast robust tesselation
soon |
15:51.11 |
dloman_ |
ideally, a 'convert to BoT' would be a bit set
on a normal geometry request msg. we can do that, now, if it would
be easier for you? (it'd be better in the long run too) |
15:52.03 |
``Erik |
it already is a bit :D GEOMETRYREQ |
0x1 |
15:52.53 |
``Erik |
if you want to shuffle the interface a bit,
doesn't bother me... it's just one of the things that'll be needed,
"gimme something I can trivially shove in opengl" |
15:53.47 |
dloman_ |
no worries, just looking to keep things from
getting jumbled up. |
15:53.59 |
dloman_ |
whats the ListReq and ListRes for? |
15:54.28 |
``Erik |
looking around the server side geometry from a
client, to find what you want to request |
15:54.56 |
dloman_ |
as in 'directory listing' type
stuff? |
15:55.03 |
``Erik |
yeah |
15:55.06 |
dloman_ |
kewl |
15:55.19 |
``Erik |
"ls /" -> "havoc.g" "ktank.g"
"m35.g" |
15:55.36 |
``Erik |
"ls /havok/all.g/" -> "light" "component"
"plane" |
15:55.59 |
dloman_ |
gotcha |
15:56.14 |
``Erik |
er, well, you get what I mean... to make like
a geometry viewer type thing work over the protocol |
15:57.16 |
``Erik |
the 'list request' may eventually turn into
some kind of query language, ah surpose |
16:00.06 |
dloman_ |
EQL |
16:08.16 |
bhinesley |
brlcad: 10-4, thank you |
16:08.57 |
CIA-105 |
BRL-CAD: 03Erik 07http://brlcad.org * r2859
10/wiki/NetMsgTypes: call the manifest a genericmultistring instead
of a 'special' |
16:10.03 |
CIA-105 |
BRL-CAD: 03Erik 07http://brlcad.org * r2860
10/wiki/GenericMultiStringMsg: Update to mirror the manifest
format |
16:12.05 |
dloman_ |
hey, i like things being special :P |
16:17.56 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44510
10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp
gsserver.lisp): implement ls/lsr |
16:17.58 |
``Erik |
the pattern repeated, that's when ya abstract
it :) |
16:23.47 |
*** join/#brlcad ibot
(~ibot@rikers.org) |
16:23.47 |
*** topic/#brlcad is BRL-CAD
Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.18.4 is posted! (20110412) |
17:18.08 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44511
10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: fix message
types |
17:18.18 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44512
10/geomcore/trunk/src/interfaces/cl/ (gsserver.lisp gvm.lisp):
throw an exception when gvm-open doesn't work |
17:19.08 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44513
10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: handle a failmsg
in response to a geometry request |
17:26.04 |
CIA-105 |
BRL-CAD: 03davidloman * r44514
10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx:
Formatting |
17:27.10 |
CIA-105 |
BRL-CAD: 03davidloman * r44515
10/geomcore/trunk/tests/unit/libnet/GeometryReqMsgUTest.cxx:
Implement the GeometryReqMsg unit test |
18:04.42 |
*** join/#brlcad crazy_im1
(~mj@a89-182-207-95.net-htp.de) |
18:48.49 |
kanzure |
starseeker: how slow is too slow? |
18:49.05 |
kanzure |
i've been testing out esolid and the entire
program itself runs in 700msec, but i don't think that's the
algorithm's time itself |
18:49.10 |
kanzure |
that's also file reading/loading, allocation,
etc. |
18:49.24 |
kanzure |
(700msec for various
union/difference/intersection tests i've tried) |
18:50.24 |
kanzure |
i might just drive over to college station and
show up at keyser's office and ask him about esolid.. he's
relatively local to me (2h drive) |
18:54.24 |
kanzure |
there's some brlcad constants defined in
esolid in a few places |
18:56.40 |
*** part/#brlcad csanyipal
(~csanyipal@226-170-85-95.dynamic.stcable.net) |
19:27.45 |
``Erik |
what kind of complexity is the 700ms case?
(and yeah, that's probably mostly file i/o, parsing, etc) |
19:28.29 |
CIA-105 |
BRL-CAD: 03bob1961 * r44516 10/brlcad/trunk/
(5 files in 4 dirs): Modify asc2g to use libtclcad. |
19:33.07 |
``Erik |
"esolid assumes that all solids are in general
position" <-- could that be the 0.1 +z issue? |
22:17.16 |
CIA-105 |
BRL-CAD: 03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:212.92.142.160]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
23:58.19 |
*** join/#brlcad bhinesley
(~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net) |