00:30.13 |
starseeker |
Woot! |
00:30.20 |
starseeker |
now has 3 Neo1973
phones |
01:11.30 |
*** join/#brlcad crazy_imp
(~mj@a89-182-208-247.net-htp.de) |
02:03.50 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
02:27.04 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
02:46.18 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) |
03:22.50 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
03:58.55 |
brlcad |
starseeker: haha |
04:49.44 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
04:50.07 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
05:57.41 |
*** join/#brlcad sachinjain
(~sachin@117.211.88.150) |
06:04.45 |
*** join/#brlcad KimK
(~Kim__@ip174-71-95-176.om.om.cox.net) |
06:39.26 |
*** join/#brlcad Stattrav
(~Stattrav@111.93.134.142) |
06:39.26 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
08:10.42 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
09:00.22 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
10:03.59 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
10:29.15 |
dloman |
Mernin all |
10:36.32 |
kunigami |
good morning |
10:38.54 |
``Erik |
yargh |
10:49.23 |
dloman |
so hows the lisp thing going =D |
10:58.01 |
``Erik |
awesome, files are moving back and forth,
etc |
10:58.54 |
``Erik |
the next trick is tesselating geometry to send
out on the fly, which is the brlcad.lisp shtuff (which'll also do
images, wireframes, parts of files, etc) |
10:59.25 |
dloman |
are there svn libs for lisp? |
10:59.57 |
``Erik |
probably, but cffi is quick and easy to write,
way nicer than jni |
11:00.55 |
dloman |
kewl |
11:02.15 |
``Erik |
librt is very macro and struct heavy, so it's
tricky to interface it :/ almost temped to write getter/setter type
funcs for some of the librt stuff :D |
11:02.36 |
dloman |
...write it in what language? |
11:02.56 |
``Erik |
C, in raytrace.h |
11:03.12 |
dloman |
i'd say go for it :) |
11:03.28 |
``Erik |
rt_set_ray(point_t origin, vect_t dir);
etc |
11:03.40 |
``Erik |
er, with an application sturct somewhere in
there |
11:12.56 |
CIA-105 |
BRL-CAD: 03davidloman * r44199
10/geomcore/trunk/ (2 files in 2 dirs): Add in an optional replyMsg
arg to the objToChunk converter |
11:22.39 |
CIA-105 |
BRL-CAD: 03davidloman * r44200
10/geomcore/trunk/src/GS/FileDataSource.cxx: Oops, forgot to commit
FileDataSource::getObjs() ! It's implemented. |
11:23.31 |
CIA-105 |
BRL-CAD: 03davidloman * r44201
10/geomcore/trunk/src/GS/DataManager.cxx: Cleanup/fixup
DataManager::handleGeometryReqMsg. Now uses the shiney, new, and
improved FileDataSource. |
11:29.27 |
CIA-105 |
BRL-CAD: 03davidloman * r44202
10/geomcore/trunk/src/GS/GeometryService.cxx: Make GeometryService
objects route GEOMETRYMANIFEST NetMsg's to the
Datamanager |
11:41.25 |
CIA-105 |
BRL-CAD: 03davidloman * r44203
10/geomcore/trunk/ (3 files in 3 dirs): Stub in GetCmd (client cmd)
for getting geometry from server. |
12:16.25 |
dloman |
``Erik: whats with the GeometryBotReqMsg
? |
12:17.04 |
dloman |
look identicle to GeometryReqMsg |
12:17.18 |
``Erik |
so far, eventually it should tesselate the
geometry into an inmem db and send that |
12:17.41 |
``Erik |
to feed ogl, isst, vsl, etc |
12:18.23 |
dloman |
why is a *Msg doing any work other than
serialization and deserialization? tesselation is the job of the
GE... isn't it? |
12:19.19 |
``Erik |
I d'no how ya have things wired up, I was just
mimicking what I saw :D I imagine the msg would have to ask ge for
a facetized version, no? |
12:20.12 |
dloman |
perhaps, but that's not the way the gs is
architected. |
12:21.11 |
``Erik |
okie, it's hard to read through all that
inheritance, d'no where exactly it should fit... I just figured I'd
put SOMETHING there so you could fix it up later :D |
12:21.14 |
dloman |
some function being executed by some thread
would 1) get the geometry from the DataManager, 2) use the GE to
tesselate it and 3) make a GeometryManifest/Chunk to send the
results to the requestor. |
12:21.22 |
dloman |
kk |
12:21.40 |
dloman |
there isn't that much inheritance :) Nothing
compared to stuff like QT and Boost. heh. |
12:21.47 |
dloman |
those make me cry |
12:21.58 |
``Erik |
at least they're documented :> |
12:22.16 |
dloman |
:P They're also stable and released |
12:23.41 |
dloman |
..weren't created by one person, weren't
created by someone doing their first soft dev project, etc,
etc. |
12:23.46 |
dloman |
the list is long. |
12:24.05 |
``Erik |
(and the only machine I have with doxygen
can't configure geomcore :/ ) |
12:24.21 |
dloman |
cmake fails? |
12:24.36 |
``Erik |
FindBRLCAD.cmake can't see the (system)
tcl |
12:25.14 |
dloman |
bummer |
12:25.15 |
starseeker |
``Erik: if that's using our custom FindTCL
there should be a way to expand the search paths |
12:26.08 |
``Erik |
is that pushed into rt^3, too? |
12:26.24 |
starseeker |
uh, dunno |
12:26.44 |
starseeker |
I was waiting until the ge/gs/gui reshuffle to
go through all that |
12:29.56 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
13:10.36 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
13:34.36 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44204
10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: bind libgcv. do
RT_APPLICATION_INIT stuff. use &key to fill some of the
struct. |
13:35.05 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44205
10/geomcore/trunk/src/interfaces/cl/ (gsnet.lisp gsserver.lisp):
clean up conditional stuff |
13:57.34 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
14:18.29 |
CIA-105 |
BRL-CAD: 03davidloman * r44206
10/geomcore/trunk/src/libNet/netMsg/GenericMultiByteMsg.cxx:
Removed some stray debugging lines. |
14:19.44 |
brlcad |
so my joking rant was apparently taken much
more to heart than was intended |
14:20.16 |
brlcad |
if anyone in here had a part in conveying how
'upset' I was, I really wasn't |
14:21.34 |
brlcad |
the initial crap coding comment was totally
meant to be tongue-in-cheek playful, the rest was simple
matter-of-fact |
14:21.42 |
CIA-105 |
BRL-CAD: 03davidloman * r44207
10/geomcore/trunk/ (include/GetCmd.h src/GS/cmds/GetCmd.cxx):
Implement GetCmd for the test client. |
14:22.13 |
brlcad |
particularly with release preparations under
way |
14:23.11 |
dloman |
Well, if you want honesty, i was working
remotely yesterday and only had IRC to go by, but you came across
as genuinely upset. Just how I read it. |
14:23.32 |
dloman |
based on your above comments I assume others
read it incorrectly also eh? |
14:23.38 |
brlcad |
apparently |
14:23.56 |
brlcad |
dislikes conflict, generally
very happy-go-lucky |
14:24.47 |
brlcad |
I was annoyed by the timing, and that probably
made some of my remarks more cynical than usual |
14:24.55 |
CIA-105 |
BRL-CAD: 03davidloman * r44208
10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Typo
fix. |
14:25.48 |
dloman |
eh, it happens. As adults we all (should)
have thick enough skin to weather someone's irritation, be it
misinterpreted or not. |
14:25.51 |
brlcad |
either way, the internet sucks at conveying
emotion and intent -- I should (and do) know better and should have
known better yesterday |
14:26.35 |
brlcad |
also don't know if this played any
part |
14:26.44 |
brlcad |
but for the record |
14:26.46 |
brlcad |
reverts should have NO NEGATIVE
CONNOTATION |
14:27.17 |
brlcad |
particularly for open source software
projects, something I was taught long ago that is different from
closed development |
14:27.37 |
brlcad |
When there is dispute or need, it's supposed
to encourage communication without any negative
connotation. |
14:27.46 |
brlcad |
You have just as much right to revert
something I've done if a need arises. |
14:27.53 |
brlcad |
If you un-revert something I've reverted, then
we both stop and discuss since that implies there are conflicting
needs. |
14:28.05 |
brlcad |
just an FYI for everyone :) |
14:28.59 |
dloman |
did i miss a revert war? |
14:29.05 |
brlcad |
nope |
14:29.25 |
brlcad |
but I did revert something yesterday and don't
know if that played any part in people "interpreting" my
upsetness |
14:29.49 |
dloman |
kk. I've been trying to pay atention to the
commit emails and thought I'd missed yet another important bit of
info |
14:30.29 |
dloman |
"SO i heard brlcad was so mad that he punched
three old ladies in the face." |
14:30.40 |
brlcad |
it was four dammit! |
14:30.43 |
dloman |
nice |
14:32.08 |
CIA-105 |
BRL-CAD: 03davidloman * r44209
10/geomcore/trunk/src/GS/GeometryService.cxx: Make sure the
DataManager point is initialized to something other than 0x0 prior
to attempting to use it. |
14:34.19 |
CIA-105 |
BRL-CAD: 03davidloman * r44210
10/geomcore/trunk/src/GS/DataManager.cxx: Add some error logging so
that DataManager won't handle a GeometryReqMsg silently
anymore. |
14:43.18 |
CIA-105 |
BRL-CAD: 03davidloman * r44211
10/geomcore/trunk/src/ (3 files in 2 dirs): Make test client handle
geometry data sent by server. |
14:45.48 |
dloman |
woot, back to where i was before the qt rip
out :) |
14:46.24 |
``Erik |
starts looking for something
else to break O:-) |
14:46.35 |
dloman |
lol |
14:46.45 |
dloman |
no need, i'm already too good at breaking
things. |
14:47.01 |
``Erik |
so ya found the segfault? |
14:47.08 |
dloman |
oh, and take that damned halo off your head.
you're not fooling anyone :P |
14:47.10 |
dloman |
yeah |
14:47.31 |
dloman |
keith was right on with the pointer pointing
at garbage |
14:59.52 |
CIA-105 |
BRL-CAD: 03Markhobley 07http://brlcad.org * r2818
10/wiki/MGED_Commands: /* E */ |
15:11.55 |
CIA-105 |
BRL-CAD: 03davidloman * r44212
10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Make NetMsgFactory
log an error when an unknown MsgType is encountered. (Rather than
just returning NULL) |
15:16.00 |
CIA-105 |
BRL-CAD: 03davidloman * r44213
10/geomcore/trunk/src/GS/DataManager.cxx: Fix DataManager's error
reporting to the client. Was sending back error codes as MsgTypes.
Now sends MsgTypes as MsgTypes! |
15:20.04 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
15:20.36 |
``Erik |
now there's a cab: http://www.youtube.com/watch?v=OiKFCzMxJik |
15:21.37 |
dloman |
nice |
15:23.50 |
dloman |
question: int bu_file_readable(const char
*path) |
15:24.05 |
dloman |
the int that is returned.... is it 0 ==
readable ? |
15:39.30 |
``Erik |
nonzero is readable, src/libbu/stat.c ...
if(bu_file_readable(file)) { do stuff to it; } else { bu_log("u y
no has read?"); } |
15:41.13 |
dloman |
kk, that's what I was thinkging, just got
confused. |
15:41.14 |
dloman |
danke! |
15:53.49 |
CIA-105 |
BRL-CAD: 03davidloman * r44214
10/geomcore/trunk/include/FileDataSource.h: Add in a util function
that determines if the supplied path exists and if it does, whether
or not its a file or dir. |
15:54.18 |
CIA-105 |
BRL-CAD: 03davidloman * r44215
10/geomcore/trunk/src/GS/FileDataSource.cxx: Woops, forgot a file
on the last commit. |
16:03.00 |
CIA-105 |
BRL-CAD: 03davidloman * r44216
10/geomcore/trunk/src/GS/FileDataSource.cxx: Make FileDataSource
filter out all paths except paths ending in files. |
16:12.01 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
16:12.37 |
CIA-105 |
BRL-CAD: 03davidloman * r44217
10/geomcore/trunk/src/GS/cmds/GetCmd.cxx: Update the
GetCmd::getHelp() method to display correct help |
16:22.33 |
*** join/#brlcad adityag1
(~ADITYA@182.237.144.88) |
16:30.54 |
brlcad |
dloman: there is no guarantee that <0 means
files doesn't exist |
16:31.27 |
brlcad |
header documents 0 (i.e., false) if doesn't
exist, and >0 for exists .. <0 is undefined |
16:31.43 |
dloman |
didn't see that in the header :/ |
16:31.52 |
*** join/#brlcad hyarion_
(c05ben@peppar.cs.umu.se) |
16:32.05 |
dloman |
just saw one sentence, so i read the code and
asked to confirm. =D |
16:32.21 |
brlcad |
they're meant to be simple if
(bu_file_exists(file)) then do something else don't |
16:32.23 |
*** join/#brlcad bhinesley_
(~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) |
16:32.51 |
brlcad |
complex return values usually indicate API
weaknesses |
16:32.58 |
brlcad |
so it's just a simple boolean |
16:33.02 |
dloman |
kk |
16:34.07 |
*** join/#brlcad roberthl_
(~robert@v1.rhl.me.uk) |
16:35.49 |
*** join/#brlcad roberthl
(~robert@v1.rhl.me.uk) |
16:35.49 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
16:37.15 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
16:37.58 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
16:39.19 |
brlcad |
dloman: fwiw, things like
FileDataSource::existsFileOrDir() really belong up in libbu (at
least the implementation of it does) |
16:39.32 |
brlcad |
so we're portably consistent and we get
reuse |
16:39.40 |
dloman |
right on. |
16:40.03 |
dloman |
i'm pushing getting functionally complete and
debugged to stable. Then I plan on doing a ****ton of clean up
=D |
16:40.15 |
brlcad |
if the API is lacking, then it's just as much
work to make things fit cleanly into libbu as they do somewhere
else |
16:41.47 |
*** join/#brlcad roberthl
(~robert@v1.rhl.me.uk) |
16:41.47 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
16:43.14 |
brlcad |
yeah, with the current code, I think we just
hadn't had a need yet to distinguish dirs beyond bu_file_exists()
and bu_count_path() |
16:43.49 |
brlcad |
if that need is there, then it's trivial to
extend another call like bu_dir_exists() or
bu_is_directory() |
16:43.57 |
dloman |
well if the esistsFileOrDir(char*) is usefull
then i can push it down there. |
16:44.14 |
brlcad |
there's a whole class of posix file node
matches like that |
16:44.38 |
brlcad |
I wouldn't push it as it -- right now you only
care if it's a file or a dir, but there are other types |
16:44.41 |
brlcad |
could be a link |
16:44.43 |
brlcad |
a pipe |
16:44.44 |
brlcad |
a socket |
16:45.04 |
brlcad |
existsFileOrDirOrSymbolicLinkOrPipeOr
... |
16:45.19 |
brlcad |
each having useful purpose |
16:46.47 |
brlcad |
that's why the current just followed the posix
class ("man bash", jump down to CONDITIONAL EXPRESSIONS to see a
list) |
16:47.11 |
dloman |
kk |
16:48.52 |
brlcad |
you could get a nearly identical result to
your function with something like bu_file_type() that returns an
enum type for regular file, dir, link, named pipe, etc |
16:49.39 |
dloman |
bu_file_type(), got it. |
16:49.51 |
brlcad |
that way you're still only implementing
support for the types you need now but have the API in place that
will extend to future node types |
16:49.54 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
16:55.56 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44218
10/brlcad/trunk/src/conv/g-egg.c: eliminate as many globals as
possible. pack the rest in the global struct. |
16:57.11 |
brlcad |
pretty awesome:
http://www.youtube.com/watch?v=xFrMl_5T0Rc&feature=player_embedded |
16:59.04 |
brlcad |
open source cars |
17:01.39 |
starseeker |
is that anything like these guys? http://www.40fires.org/ |
17:02.09 |
starseeker |
or the commerical side: http://www.riversimple.com/ |
17:05.16 |
starseeker |
huh - http://www.onawi.org/ |
17:05.27 |
starseeker |
that could be kinda cool |
17:05.40 |
dloman |
am i reading g_transfer.c:server_geom()
correctly? wdb_export_external() doesn't write to disk
there? |
17:05.58 |
dloman |
brlcad: Nice video, that guys a good speaker
:) |
17:13.23 |
brlcad |
dloman: wdb_export_external() writes to the
"database instance", whatever that is |
17:13.34 |
brlcad |
in g_transfer's case, it's an in-memory-only
database |
17:13.49 |
dloman |
yeah, figgered that out just now,
heh. |
17:13.56 |
brlcad |
so it doesn't write to disk, but only because
it's in-mem |
17:14.29 |
dloman |
if i instantiate a different type of db, then
wdb_export_external to that, then that will get me writing to
disk...... correct? |
17:14.56 |
brlcad |
depends what kind of dbip you make, but if
it's a file-based dbip, then yes -- it'll write out to
disk |
17:19.29 |
dloman |
db_open() with a RT_WDB_TYPE_DB_DISK
flag? |
17:27.47 |
brlcad |
sounds about right |
17:27.56 |
dloman |
right on |
17:28.14 |
CIA-105 |
BRL-CAD: 03starseeker * r44219
10/geomcore/trunk/src/ (6 files in 2 dirs): Get some renaming done,
get a couple files building. |
17:37.57 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44220
10/brlcad/trunk/ (configure.ac src/Makefile.am src/java/): no
implementation, abandoned 8 years ago, unused, gone. |
17:39.00 |
dloman |
http://www.local-motors.com/checkup.php?c=6998 |
17:39.01 |
dloman |
awesome. |
17:41.53 |
``Erik |
http://ecoroamer.com/drupal/CAD-files
dwg for the thing |
17:42.13 |
dloman |
....do i smell a new addition to the db
library? |
17:42.44 |
``Erik |
dwg is all engineering line drawings, no solid
geometry, right? |
17:42.55 |
starseeker |
right |
17:43.10 |
starseeker |
good material for modeling, but not a solid
model itself |
17:44.24 |
starseeker |
license statement is... less than
clear |
17:44.39 |
starseeker |
someone should suggest one of the creative
commons licenses to him |
17:44.53 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44221
10/brlcad/trunk/src/conv/g-egg.c: quell warning that showed up on
fbsd but not mac |
17:46.34 |
CIA-105 |
BRL-CAD: 03starseeker * r44222
10/geomcore/trunk/src/libgvm/ (gvm_svn.h mem.c): Ah, right - we'll
be using memory pools for the internals. |
17:48.00 |
``Erik |
looks like it's just a stretched f650 with a
camper O.o |
17:49.00 |
starseeker |
probably |
17:49.12 |
dloman |
yeah *JUST* a streched f650 |
17:50.10 |
``Erik |
they started with a 2007 f650 with a c7 diesel
engine, stretched it, slapped a custom built camper on, run the
camper on solar cells and heat captured off the exhaust
O.o |
17:52.34 |
CIA-105 |
BRL-CAD: 03starseeker * r44223
10/geomcore/trunk/src/libgvm/ (breakout.c gvm.h): move header
entrys around, remove breakout.c (deal with that later) |
17:52.59 |
``Erik |
any news on red testing for release? |
17:53.29 |
CIA-105 |
BRL-CAD: 03brlcad * r44224
10/brlcad/trunk/src/libged/wdb_obj.c: if ged_title() is wrong, then
this one is probably wrong too since it's the daddy. make title not
clobber units. |
18:00.13 |
starseeker |
we've also got a report rtwizard isn't
working... let me check... |
18:00.46 |
starseeker |
crud |
18:03.14 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.142.251) |
18:03.14 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
18:05.06 |
CIA-105 |
BRL-CAD: 03brlcad * r44225
10/brlcad/trunk/NEWS: |
18:05.06 |
CIA-105 |
BRL-CAD: bob found/fixed a bug with the title
command. presumably, this would convert |
18:05.06 |
CIA-105 |
BRL-CAD: the working units to mm if you tried
to set the title via the units command. |
18:09.50 |
CIA-105 |
BRL-CAD: 03brlcad * r44226
10/brlcad/trunk/TODO: libged encapsulation issue reverted for
release, schedule backlog task to restore with libdm/libfb
decoupling addressed. similar decouple needed for screengrab
command (though that command may just end up migrating?). |
18:11.42 |
*** join/#brlcad adityag
(~ADITYA@182.237.144.88) |
18:19.40 |
CIA-105 |
BRL-CAD: 03davidloman * r44227
10/geomcore/trunk/include/FileDataSource.h: Add a //TODO about
swapping out existsFileOrDir with bu_file_type() |
18:31.40 |
CIA-105 |
BRL-CAD: 03davidloman * r44228
10/geomcore/trunk/src/GS/DataManager.cxx: Add server side logging
for geometry requests |
18:38.56 |
CIA-105 |
BRL-CAD: 03davidloman * r44229
10/geomcore/trunk/src/GS/FileDataSource.cxx: Make note about the
Logger failing after the call to BRLCAD::MinimalDatabase
cstr. |
18:42.00 |
CIA-105 |
BRL-CAD: 03davidloman * r44230
10/geomcore/trunk/src/GS/GSClient.cxx: Display the name of the
GeometryChunk as it comes in from the server |
18:44.26 |
CIA-105 |
BRL-CAD: 03brlcad * r44231
10/brlcad/trunk/TODO: file node entity type support to
libbu |
19:21.22 |
CIA-105 |
BRL-CAD: 03brlcad * r44232
10/brlcad/trunk/TODO: red matrix edit works! |
19:26.59 |
CIA-105 |
BRL-CAD: 03brlcad * r44233
10/brlcad/trunk/TODO: red is looking better, doesn't seem to list
rgb/color attributes multiple times any more, but now seems to be
wiping out the shader and region_id at least when set to plastic
and -1 respectively. |
19:42.57 |
*** part/#brlcad adityag
(~ADITYA@182.237.144.88) |
20:38.54 |
*** join/#brlcad Wildstar
(42bd9f25@gateway/web/freenode/ip.66.189.159.37) |
20:39.05 |
Wildstar |
Hello |
20:39.35 |
Wildstar |
Is there a PDP-11 source code for
BRL-CAD? |
20:41.13 |
Wildstar |
BBL |
20:44.13 |
CIA-105 |
BRL-CAD: 03starseeker * r44234
10/geomcore/trunk/src/libgvm/ (CMakeLists.txt mem.c objects.c): Add
preliminary stab at repository_object conversion routine. |
20:45.44 |
dli |
PDP-11 is 16bit, amazing request for brl-cad
:( |
20:50.48 |
CIA-105 |
BRL-CAD: 03erikgreenwald * r44235
10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp
gsserver.lisp): macros! |