IRC log for #brlcad on 20100223

00:50.46*** join/#brlcad ibot (ibot@rikers.org)
00:50.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/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.6 tagged today (20100205)
00:54.11``Erikyeh, seems busted
00:54.24``Erikptrdiff_t not being defined before it's used to define ssize_t
00:56.20``Erikhttp://paste.lisp.org/display/95452
00:56.57``Erikgets his recycling together
01:05.56CIA-41BRL-CAD: 03starseeker * r37706 10/brlcad/trunk/configure.ac: Have the AC_CHECK_TYPE for ssize_t define HAVE_SSIZE_T if found, so the conditional in common.h will work (not defined on gentoo amd64 in testing - not sure if this is needed universally).
01:06.23*** join/#brlcad Nohla (~jesica@201.255.236.19)
01:38.06*** join/#brlcad Nohla (~jesica@201.255.236.19)
02:56.11starseekergrr
02:56.26starseekerrtgl doesn't seem to like my new machine - Z clears it but B doesn't
02:56.50starseekermust work up a more robust jobs manager
02:58.22``Erikhrm
02:59.10``Erikthinks rob is going to email starseeker real soon now
03:02.41starseeker``Erik: what'd I break?
03:03.36``Erikthird party apps trying to build against BRL-CAD flip over the ssize_t dealio
03:06.15starseekerall I did was define HAVE_SSIZE_T if it's actually there
03:06.31starseekerlooking at common.h, we're expecting that (apparently)
03:07.04starseekerthe ssize_t stuff other than the HAVE_SSIZE_T definition was already there
03:07.16``Erikyeh, I d'no, I'm getting osX build breakage on ISST now, I'll look into tomorrie
03:07.28starseekerchecks out isst
03:07.41``Erikneeds gtk+2 and pango
03:09.24``Erikwell... ok, I'll look into it day after tomorrow, I think I'm busy all day :/
03:12.15``Erik(and if ISST doesn't "just work", what makes ya think some xmkmf/imake monstrosity will? :D )
03:16.15starseekertries defining HAVE_SSIZE_T in isst's configure.ac, but it doesn't seem to "take"
03:17.20``Erikyeh, I tried that
03:17.53``Erikwait, lemme try something
03:18.43``Erikwhistles innocently
03:19.16CIA-41BRL-CAD: 03erikgreenwald * r37707 10/isst/trunk/ (configure.ac src/local_worker.c src/main.c src/net_worker.c): include isst_config.h...
03:22.27``Erikeither way, might need to give them a heads up about the change, they tend to freak out easily
03:24.05``Erik(and you're the poor schlub that gets thrown under the train either direction :D )
03:28.11starseekerheh, beat me to it
03:31.32starseeker``Erik: did that define in configure.ac fix your build as well?
03:31.38starseekerin BRL-CAD I mean?
03:31.58starseekerO.o tessellating pinewood sucks on this machine
03:32.22``Erikyeh
03:33.07starseekercool
03:38.03starseekerwell, ktank loads fast...
03:38.47``Erikthe controls suck, don't they? :D *duck*
03:38.55starseekersure do
03:40.46``Erikyou attending that 'thing' tomorrow morning?
03:40.56starseekerhuh?
03:41.24``Erikwith the presentations?
03:41.33starseekeroh, that thing
03:41.40starseekerdunno
03:43.48starseekeryay, crash
03:43.59starseekerERROR: bad pointer x1f13b40: s/b region(x23232323), was model(x12121212), file ../../../brlcad/src/adrt/load_g.c, line 80
03:44.46``Erikheh, with fill #'s, it was sent a badly formed NMG, huzzah
03:45.02starseeker``Erik: if you get a chance, try g-nmg on pinewood and see if isst can view the results
03:45.18``Erikum, I think I have a converted version at the office
03:45.41``Erikif you have an older version laying around... something was horribly broken in NMG's recently which causes failures out the wazoo
03:46.01starseekerno, latest checkout
03:46.37``Erikyes... something in our NMG code broke in the last month or so, we can no longer convert like we used to...
03:46.53``Erikso if you have an older version handy, use that to convert...
03:46.54``Erik:D
03:47.30starseekerso despite a fully successful conversion, the result is invalid?
03:48.06``Erikthe, uh, big model I showed this morning was done on 7.16.2, the most recent version bombed with a similar error which kept me from using that model at the airfield
03:48.40starseekergrr
03:48.44starseekerk
03:49.49``Erikis that from g-nmg -b generated shtuff, or running isst_gtk on an 'unprepped' geometry?
03:50.33``Erikassumes it was not set up for fast loading, since that code shouldn't be hit
03:50.42``Erik(yes, it needs the -b flag right now)
03:50.58``Erikhitting it with rt or mged would be the ultimate test, I surpose
03:51.34``Erikhehehe, good old southpark :D
03:52.29starseekerooops
03:52.32starseekerforgot the -b flag
03:52.35starseekertires again
03:54.57``Erikdoesn't remember why he has the NMG codepath disabled
03:55.49``Erikhrm, mebbe it IS enabled in the svn version heh O.o
03:57.27``Erikohhhh
03:57.30``Erikheh
03:57.59``Erikn/m, that's right, I disabled the NMG fast-loading BECAUSE it tickeld that error
03:59.31``Erik(there is something screwed up with the NMG code, though... I'll have to look into that more later)
04:00.36CIA-41BRL-CAD: 03erikgreenwald * r37708 10/brlcad/trunk/src/adrt/load_g.c: disable NMG fastloading for now
04:04.02*** join/#brlcad talcite (~matthew@206-248-130-132.dsl.teksavvy.com)
04:06.50*** join/#brlcad dtidrow (~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net)
04:45.47*** join/#brlcad talcite_ (~matthew@69-165-146-198.dsl.teksavvy.com)
05:05.32*** join/#brlcad Hirvinen (pahirvin@melkki.cs.helsinki.fi)
05:16.34brlcadstarseeker: unistd.h doesn't/shouldn't define any HAVE_* .. system headers really shouldn't ever
05:16.46brlcadthe typo is AC_CHECK_TYPE vs AC_CHECK_TYPES
05:23.59*** join/#brlcad Hirvinen (pahirvin@melkki.cs.helsinki.fi)
05:25.13starseekerah
05:31.18CIA-41BRL-CAD: 03brlcad * r37709 10/brlcad/trunk/include/common.h: need to include the header that provides ptrdiff_t if we're going to typedef it, otherwise needs to turn into a #define instead.
05:32.30CIA-41BRL-CAD: 03starseeker * r37710 10/isst/trunk/configure.ac: Don't need to manually define - use AC_CHECK_TYPES (thanks Sean)
05:33.48CIA-41BRL-CAD: 03starseeker * r37711 10/brlcad/trunk/configure.ac: Use AC_CHECK_TYPES to look for ssize_t
05:35.52brlcadyeah, that should do it
05:36.49brlcadaww, AC_TYPE_INT32_T and friends are new
05:38.51*** join/#brlcad Ralith (~ralith@216.162.199.202)
05:40.39CIA-41BRL-CAD: 03brlcad * r37712 10/brlcad/trunk/configure.ac: AC_TYPE_INT32_T and friends were added in 2.59 so can't use them. our minimum is 2.52
06:10.25CIA-41BRL-CAD: 03brlcad * r37713 10/brlcad/trunk/autogen.sh: merge in changes from upstream repo to check for new macros
06:12.38*** join/#brlcad jack- (~jack@unaffiliated/jack)
06:12.56jack-brlcad: woot, you're coding for bzflag as well?
06:15.41Jonimusjack-: thats how I found out about bzflag, I was looking at him on CIA.vc
06:16.06jack-:)
06:16.40jack-i just noticed it in #commits
06:16.48jack-(cia.vc as well)
06:23.21brlcadjack-: happen to be one of the bzflag project admins too
06:24.38brlcadhearts bzflag
06:25.28jack-cool :)
06:25.36jack-it rocks, i love it
06:25.48JonimusI suck at it but its pretty damn fun anyway
06:26.36CIA-41BRL-CAD: 03brlcad * r37714 10/brlcad/trunk/include/common.h: still not perfect but this should help things along for 3rd party codes that don't have a HAVE_SSIZE_T define. only provide the typedef if we can't find hint of SSIZE_MAX. (untested)
06:29.13brlcad``Erik: perhaps you can test that - you should definitely NOT have to create a AC_CHECK_TYPE macro in isst/trunk/configure.ac in order to use the API .. nor should other folks
06:31.42CIA-41BRL-CAD: 03brlcad * r37715 10/isst/trunk/configure.ac: this type check should not be required for 3rd party codes (codes that link off an installed brl-cad).
07:04.51CIA-41BRL-CAD: 03brlcad * r37716 10/brlcad/trunk/src/libged/ (ged_private.h rt.c): move the struct into the only file that actually uses it.
08:54.11*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:03.22CIA-41BRL-CAD: 03d_rossberg * r37717 10/brlcad/trunk/ (18 files in 7 dirs):
09:03.22CIA-41BRL-CAD: another iteration step in forcing back ssize_t: removed all references from the headers (exept for the declaration)
09:03.22CIA-41BRL-CAD: poorly tested
10:27.01jack-another bzflag man
10:27.07jack-cool :)
11:49.00``Erikyeh, I have pinewood both as nmg and bot here, starseeker
12:25.27starseekerhmm k
13:51.17brlcadjack-: not another bzflag person -- many cad and bz people all connect from the same server (bz.bzflag.bz)
13:52.13brlcadawesome: http://www.ornl.gov/sci/radiation_transport_criticality/BekarPubs/MCNP_BRL_A_Linkage.pdf
13:55.32starseekerbrlcad: cool
13:55.36starseekeris that a new paper?
13:56.26brlcadI'm familiar with the effort, we helped them with that about 5 years ago
13:56.33brlcadbut yeah, new paper, at least new to me
13:57.16brlcadlooks like it was published in end of 2009
13:57.45brlcadK. Bekar and T. M. Evans, "MCNP-BRL: A Linkage between MCNP and CAD Geometry," Trans. Am. Nucl. Soc. 101, 623-626 (2009).
14:08.51CIA-41BRL-CAD: 03starseeker * r37718 10/brlcad/trunk/doc/BRL-CAD.bib: Add reference to Bekar paper.
14:10.45brlcadack beat me to it
14:10.57brlcadhehe
14:14.39CIA-41BRL-CAD: 03brlcad * r37719 10/brlcad/trunk/doc/BRL-CAD.bib: expand volume
14:15.01``Erikhm, graph of pubs per year might be a telling visualization
14:15.47starseekerdepressing you mean...
14:15.56brlcadhere's another, but BRL-CAD only gets a light mention as it was starting: http://www.ornl.gov/sci/radiation_transport_criticality/Blakeman_Pubs/PWR_Facility_Modeling_TM_2007_133.pdf  
14:16.01``Eriknever said good telling :D
14:16.51brlcadanother new one to me: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.5775&rep=rep1&type=pdf
14:17.07starseekerwill leave that one for BRL-CAD if he wants (Blakeman)
14:17.56brlcadthe first one isn't worth adding
14:17.59brlcadthe second one is though
14:18.59brlcadthere's apparently another paper referenced, "MCNP-BRL: An External Geometry-Driven Version of MCNP" but I can't find it
14:20.07``Eriksounds like a task to keep our local library busy
14:32.39CIA-41BRL-CAD: 03starseeker * r37720 10/brlcad/trunk/doc/BRL-CAD.bib: Toss in references to recent tech reports.
14:34.58CIA-41BRL-CAD: 03starseeker * r37721 10/brlcad/trunk/doc/BRL-CAD.bib: Add link to online scan of Deitz paper untl we find a better one.
14:38.38CIA-41BRL-CAD: 03bob1961 * r37722 10/brlcad/trunk/src/librt/primitives/poly/poly.c: Changed the %d directive to %lu to accomodate size_t.
14:40.45CIA-41BRL-CAD: 03brlcad * r37723 10/brlcad/trunk/doc/BRL-CAD.bib: add another tabary reference. this one for Coupling photon Monte Carlo simulation and CAD Software. Application to X-ray nondestructive evaluation.
14:42.06CIA-41BRL-CAD: 03erikgreenwald * r37724 10/brlcad/trunk/src/conv/g-egg.c: Fix vertex pool display. Add polygon information to output. Fix various flaws in output.
14:42.12``Erikwill test that when he gets home O.o
14:43.34``Erikand mebbe do an nmg->bot conversion to get more efficient data packing
14:43.55``Erik(currently storing 36 vertices for a cube)
14:50.04CIA-41BRL-CAD: 03erikgreenwald * r37726 10/brlcad/trunk/src/librt/primitives/poly/poly.c: quell %lu vs size_t warning
14:59.25CIA-41BRL-CAD: 03bob1961 * r37727 10/brlcad/trunk/misc/win32-msvc8/ (164 files in 164 dirs): Turn the Detect64BitPortabilityProblems option on for x64.
15:09.03*** join/#brlcad CIA-91 (cia@208.69.182.149)
15:13.18*** join/#brlcad Maloeran (~maloeran@glvortex.net)
15:13.33starseekerbrlcad: could you refresh my memory - what is the argument against going to C99?
15:15.35d_rossbergstarseeker: MS Visual Studio, e.g.
15:17.02starseekerd_rossberg: btw, on the conversion from ssize_t to size_t - did you check if any of the code is returning error values that are negative?
15:18.59d_rossbergyes, this special value is (and was) RT_DIR_PHONY_ADDR
15:20.59starseekerHow much of C99 does Visual Studio support?  The do support some I believe, and they might support the parts we really want (like printf and zu, for example...)
15:22.57starseekersupposes we could snarf an advanced printf code from somewhere and roll it into libbu...
15:27.13d_rossbergI'm not familar with what is already C99 and what is not, maybe you can give me an example of what you plan to do
15:27.59d_rossberghowever, i'll have a look at it tomorrow because i've to hurry
15:28.05starseekerWell, with size_t being variable size depending on platform, things like printf kinda have issues
15:28.17d_rossbergprefers c++ streams :)
15:28.43starseekerapparently, the C99 answer to this is to define %zu for printf, but that doesn't help C90 coders
15:29.51starseekerunless we make a "smart" bu_printf that handles C99 style things...
15:40.49brlcadvc6 support was initially one of a handful of issues, but I don't think vc8+ will have any trouble with c99
15:41.16brlcadstarseeker: the biggest issue was simply becoming c89 compliant first
15:41.21starseekernods
15:41.43starseekerwith the size_t conversions starting in earnest, it'd be really nice to have the z options in printf
15:41.58starseekergawks at the FreeBSD printf code...
15:42.21brlcadwe only recently became strict c89 compliant with the warning quellings
15:42.49brlcadI least I vaguely recall that being one of my compilation tests a few weeks back -- would have to reverify
15:42.50starseekerhehe - comment at the top of the file:  Actual printf innards. This code is large and complicated...
15:44.12brlcad"smart bu_printf" is bu_log
15:44.55brlcadcould expand that with zu, but it's not a big deal (and there's not many that aren't already taken care of)
15:45.05brlcadcasting on print to the print type
15:46.01brlcaddoesn't see anything horrible with: size_t i = 123; printf("%lu", (long unsigned)i);
15:48.34starseekerBob's saying that truncates the size_t in half on windows
15:49.43starseekerapparenty unsigned long is 32 bit on Windows and size_t is 64 bit...
16:00.30brlcadsure, so %llu
16:01.53brlcadthere's only a few places we should be printing things that big
16:06.18*** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de)
16:09.26starseekerbut will llu work in the 32 bit case?
16:13.41brlcadyou'll still need to print conversion cast, but yeah it should work just fine
16:14.45brlcadsize_t i = 123; printf("%llu", (unsigned long long)i); or printf("%llu", (uint64_t)i); if we need to play well on c89
16:15.04brlcadlong long is a c99ism though many c89 compilers provided it
16:15.20``Erikwonders how unpalatable %p is
16:15.42``Erik(or mebbe bu_flog() )
16:16.36``Erikbu_flog(FILE *, const char *, ...);
16:17.01``Erikbu_snlog() ? :D
16:19.34brlcadwe're using %p already all over
16:21.14brlcadif we had to, there's macro foo we could use to specialize for platforms (e.g., %Id on windows, %zd for c99, %ld for 32-bit, etc) but that'd be a PITA
16:22.25brlcadprintf("This is " SIZE_T_FMT " times more annoying than %%llu with a cast.", i);
16:23.44brlcadif windows has %zd then great, but last I looked they didn't: http://msdn.microsoft.com/en-us/library/tcxf1dw6(VS.100).aspx
16:24.17brlcadcourse, that doesn't list %p and we use that, so who knows
16:24.43*** join/#brlcad parigaudi_ (~quassel@pd95b7f5e.dip0.t-ipconnect.de)
16:57.08*** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de)
17:36.03*** join/#brlcad parigaudi_ (~quassel@pd95b7f5e.dip0.t-ipconnect.de)
18:34.42CIA-91BRL-CAD: 03Sean 07http://brlcad.org * r2203 10/wiki/Mime-types: show how to manually set props
19:58.38*** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de)
20:42.01starseekerhmm, cool:  http://www.itl.nist.gov/div897/sqg/dads/
20:52.29starseekerthinks this might be how we're doing n-ary trees: http://www.itl.nist.gov/div897/sqg/dads/HTML/binaryTreeRepofTree.html
20:53.24*** join/#brlcad mac- (~mac@sunrise.pi.net.pl)
20:53.26mac-hello
20:56.55mac-any one know if there is any GNU equivalent to MSC Nastran ?
20:58.41*** join/#brlcad Nohla (~jesica@201.255.236.19)
21:02.53brlcadmac-: haha
21:03.19mac-Salome maybe ?
21:03.25mac-anyone works on it ?
21:05.21mac-I mean if it is possible to create element / whole model under BRL-CAD and then open it in i.e. Salome for proceed with simualtions ?
21:05.56mac-like it is on MSC Nastran, where I can create model in i.e. Catia and then open it in Nastran to make simulations
21:09.55brlcadmac-: best I can suggest is to give it a try on a simple model
21:10.10brlcadyou certainly can model something with BRL-CAD and import that into Salome
21:10.11mac-heh
21:10.12mac-:>
21:10.43brlcadwhether it's sufficiently "equivalent" depends on WAY too many factors
21:11.55louipcmac-: why GNU specifically?
21:12.07*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
21:13.13mac-main target is to run under Linux, and to not pay half bilion of dollars for it :/
21:13.53brlcadGNU has little to do with that target, you just want something open source
21:14.48mac-not exactly
21:14.53mac-I`m not a programmer
21:15.03mac-I do not want to change code i.e.
22:02.06*** join/#brlcad ibot (ibot@rikers.org)
22:02.06*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.6 tagged today (20100205)
22:12.14``Erikahh, home at last
22:17.28``Erikthinks mac- wants "(free||cheap)&&worksonlinux", not necessarily open source O.o
22:18.43``Erikthinks jack doesn't understand a lot about the various licenses O.o *duck* :)
22:39.07*** join/#brlcad ibot (ibot@rikers.org)
22:39.07*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.6 tagged today (20100205)
22:41.10CIA-85BRL-CAD: 03erikgreenwald * r37731 10/brlcad/trunk/src/conv/g-egg.c: fix reported # of triangles
22:44.19CIA-85BRL-CAD: 03brlcad * r37732 10/brlcad/trunk/NEWS: erik fixed bugs in the g-egg exporter. Z is up! .. and fixed polygon format decl with correct num of reported triangles.
22:49.07CIA-85BRL-CAD: 03brlcad * r37733 10/brlcad/trunk/include/bu.h: clean up example structparse code (several typos).
23:10.20``Erikyeh, it actually works now, opposed to producing busted geometry heh
23:10.52``Erik(at least, I think it works, the panda conversion tools seem to like it, able to do funky round robin shit, like g-egg, egg2dxf, dxf-g and get a valid cube back
23:10.55``Erik)
23:49.09``Erik\/cl

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.