IRC log for #brlcad on 20100107

00:02.39 ``Erik O.o
00:02.50 ``Erik I muffed up the commit a bit
00:02.58 ``Erik only 'solved' half the problem
00:03.34 brlcad knowing is half the battle
00:10.11 CIA-38 BRL-CAD: 03starseeker * r37152 10/brlcad/trunk/src/libfb/if_tk.c: Add a few notes on what's currently know and what needs to come next for tk framebuffer.
00:17.41 CIA-38 BRL-CAD: 03brlcad * r37153 10/brlcad/trunk/src/libbu/bitv.c: MORE warnings to quell with optimization enabled. unreachable code warnings on sizeof()-related portions that are written to accommodate different compile-time bitv_t sizes. making the size volatile keeps things quiet.
01:14.27 *** join/#brlcad Nohla (n=jesica@168.226.176.193)
01:29.16 CIA-38 BRL-CAD: 03brlcad * r37154 10/brlcad/trunk/src/libbu/ (brlcad_path.c cmdhist.c convert.c dirent.c dirname.c): quell a variety of unreachable code warnings produced during optimized compilation
01:32.07 CIA-38 BRL-CAD: 03brlcad * r37155 10/brlcad/trunk/include/brlcad_version.h: quell warnings about brlcad_ident's unreachable code by getting rid of the temporary label copy. expand printing calls and test the title parameter directly.
01:33.28 CIA-38 BRL-CAD: 03brlcad * r37156 10/brlcad/trunk/include/brlcad_version.h: bah, need string.h for strlen().
01:34.27 CIA-38 BRL-CAD: 03brlcad * r37157 10/brlcad/trunk/include/ (brlcad.h brlcad_version.h): why is my name still in these files?
01:51.39 CIA-38 BRL-CAD: 03brlcad * r37158 10/brlcad/trunk/include/ (10 files in 2 dirs): (log message trimmed)
01:51.39 CIA-38 BRL-CAD: authors should not be listed in source files. to reiterate why, the reason is
01:51.39 CIA-38 BRL-CAD: NOT to diminish or hide the noteworthy contributions of those authors but,
01:51.39 CIA-38 BRL-CAD: rather, to manage authorship information in the project documentation (e.g., the
01:51.40 CIA-38 BRL-CAD: AUTHORS file) and revision control system. it's also been shown among various
01:51.42 CIA-38 BRL-CAD: open source projects that files with notable authors or significant legacy are
01:51.44 CIA-38 BRL-CAD: often edited with great hestiation or outright avoided, particularly by new
01:59.09 CIA-38 BRL-CAD: 03brlcad * r37159 10/brlcad/trunk/src/libbn/ (axis.c list.c marker.c qmath.c sphmap.c vers.c): (log message trimmed)
01:59.09 CIA-38 BRL-CAD: OOF.. even hard for me to edit a file with a 1978 start date (damn), so keep
01:59.09 CIA-38 BRL-CAD: that note but still remove authorship. that's a case in point why it's a
01:59.09 CIA-38 BRL-CAD: problem, though. again, the reason is NOT to diminish or hide the noteworthy
01:59.09 CIA-38 BRL-CAD: contributions of those authors but, rather, to manage authorship information in
01:59.13 CIA-38 BRL-CAD: the project documentation (e.g., the AUTHORS file) and revision control system.
01:59.15 CIA-38 BRL-CAD: it's also been shown among various open source projects that files with notable
02:01.39 CIA-38 BRL-CAD: 03brlcad * r37160 10/brlcad/trunk/configure.ac: give up on unreachable-code. while it does report some useful warnings about dead code, it also produces FAR too many false positives, many in system macros that cannot be easily quelled.
02:23.49 starseeker interesting - the mged_default(geom) and mged_default(ggeom) are interperted differently by Aqua Tk than X11 Tk
02:27.50 starseeker Aqua Tk is using the upper left corner of my center monitor as the starting point (presumably the left upper corner of the Apple menubar)
02:30.22 starseeker X11 is using the upper value of the Apple menubar and the extreme left edge of my left monitor - I guess the maximum extents of the screen space
02:31.36 starseeker ponders what to do... conditionalize screen coordinate interpertation maybe...
02:32.40 starseeker if that's what's causing the other odd behaviors in dm and fb, this could get interesting
02:32.56 *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
02:33.25 starseeker (in a hair pulling sort of way...)
02:48.01 starseeker Need to investigate this - may be necessary: http://wiki.tcl.tk/17454
02:49.32 CIA-38 BRL-CAD: 03brlcad * r37161 10/brlcad/trunk/AUTHORS: paul stay apparently also made contributions from the CS department for the University of Utah in 1983 accordingly to src/librt/nurb_solve.c
02:54.02 CIA-38 BRL-CAD: 03brlcad * r37162 10/brlcad/trunk/configure.ac: leave a note for -Wunreachable-code as also being of interest
03:01.59 brlcad both aqua and X11 have mechanisms to get the list of available contexts and screens (as opposed to the available displays) so you can get the primary context and display there
03:02.18 brlcad xcalc does this, for example, iirc, not using the root window, but the main window
03:02.50 brlcad aquatk merely defaults to the main display iirc
03:06.30 brlcad that link for mac seems reasonable to account for arbitrary arrangements too
03:06.49 brlcad hack, but if it works, keep it isolated, woot, and move on
03:07.06 CIA-38 BRL-CAD: 03brlcad * r37163 10/brlcad/trunk/src/ (67 files in 14 dirs):
03:07.06 CIA-38 BRL-CAD: more authorship removal. the reason is NOT to diminish or hide the noteworthy
03:07.07 CIA-38 BRL-CAD: contributions of those authors but, rather, to manage authorship information in
03:07.07 CIA-38 BRL-CAD: the project documentation (e.g., the AUTHORS file) and revision control system.
03:07.07 CIA-38 BRL-CAD: See recent commit revision comments for more details (e.g., 37158).
03:14.05 CIA-38 BRL-CAD: 03brlcad * r37164 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c: revert 37149 .. if bu_vls_struct_print() is wrong then so are ALL of the volumetric primitives (dsp, hf, vol, ..). more likely, some change to struct parsing was fux0r3d elsewhere (plus, this used to work as-is)
03:18.11 CIA-38 BRL-CAD: 03brlcad * r37165 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c: missing semi on MAT_COPY. minor ws
05:34.52 ``Erik (yes, _bu_parse_double() is the culprit now, was gonna revert that tomorrie)
07:41.32 CIA-38 BRL-CAD: 03brlcad * r37166 10/brlcad/trunk/src/libbu/parse.c:
07:41.32 CIA-38 BRL-CAD: erik pinpointed the routine, so looking through recent logs it's clear that vls
07:41.32 CIA-38 BRL-CAD: printing was damaged by automatic comma formatting where a space was injected.
07:41.32 CIA-38 BRL-CAD: undo the space injection (even though struct parsing shouldn't be significant or
07:41.32 CIA-38 BRL-CAD: so sensitive to a whitespace change like that). this should hopefully fix some
07:41.35 CIA-38 BRL-CAD: of the volumetric objects (like ebm in solids.sh in regression suite).
09:45.44 *** join/#brlcad Computer (n=Computer@unaffiliated/computer)
11:38.17 *** join/#brlcad Ralith (n=ralith@69.90.48.97)
11:39.55 d-lo mernin all.
11:58.01 *** join/#brlcad Ralith (n=ralith@69.90.48.97)
12:18.57 *** join/#brlcad mafm_ (n=mafm@94.Red-83-45-253.dynamicIP.rima-tde.net)
12:45.19 *** join/#brlcad mafm (n=mafm@130.Red-81-36-112.dynamicIP.rima-tde.net)
13:33.48 *** join/#brlcad Ralith (n=ralith@69.90.48.97)
14:20.10 *** join/#brlcad docelic (n=docelic@78-2-127-241.adsl.net.t-com.hr)
14:36.57 ``Erik a dangit, all fixin' the bug I spent all that time tracking and was planning to fix this morning *shakes fist*
14:53.57 brlcad that fixed it?
14:54.02 brlcad it fix both?
14:54.07 d-lo brlcad: you in today?
15:00.26 ``Erik dunno yet
15:00.40 ``Erik been fighting changes to the email server and just started a build
15:08.52 d-lo I have noticed that bzflag.bz has been kinda sluggish. Is that all you ``Erik ? =D
15:10.11 brlcad mysql is being a pig, restarting it
15:10.25 d-lo oink oink
15:20.28 ``Erik I haven't been doing anything other than pine on that machine, I spend a lot more time bugging brlcad to migrate :)
15:20.51 ``Erik the phpbb has some brutally horrible queries that cork the machine pretty heavily, not uncommon to see load around 4
15:21.12 d-lo ouch.
15:21.31 ``Erik wouldn't be a problem if it was a 4 core machine... but it's a single core :)
15:21.42 d-lo heh
15:21.44 CIA-38 BRL-CAD: 03brlcad * r37167 10/brlcad/trunk/src/libbu/parse.c:
15:21.44 CIA-38 BRL-CAD: break out the comma that was being printed from the string literal so we don't
15:21.44 CIA-38 BRL-CAD: run into the same problem down the road with automatic formatting. making it a
15:21.44 CIA-38 BRL-CAD: simple char literal so compilation will halt with an error if ',' is changed to
15:21.45 CIA-38 BRL-CAD: ', '
15:22.10 d-lo quad Phenom II's are down around $150 now..... contemplating an upgrade soon.
15:22.21 ``Erik was going to completely rewrite that to be more robust
15:23.22 ``Erik like; I'd argue that " 1" should parse as a valid float if desired... eat whitespace, then parse similar to C's rules
15:23.33 ``Erik (with automatic coercion)
15:24.44 brlcad I couldn't find where it was actually using comma as a separator
15:24.52 ``Erik it doesn't
15:25.10 ``Erik it uses "a cahracter", at the end it has a *str++; /* skip over seperator */ or something
15:27.30 brlcad ahh, I see
15:31.32 ``Erik <-- woulda started with something more like while(*str&&!ispartofafloat(*str))str++; if(!*str)return something; endstr=str; while(*endstr&&ispartofafloat(*endstri))endstr++; val=strtod(str,endstr); str=endstr+1;
15:31.59 ``Erik this whole "scan for a decimal point, but call it a mantissa, then scan for an 'e' or 'E', then ..." O.o
15:49.51 CIA-38 BRL-CAD: 03brlcad * r37168 10/brlcad/trunk/src/libbu/parse.c:
15:49.51 CIA-38 BRL-CAD: make things a little more robust on the number parsing. don't just assume a
15:49.51 CIA-38 BRL-CAD: one-character separator and then the start of another number. skip any trailing
15:49.51 CIA-38 BRL-CAD: whitespace before and after a separator taking care to allow space itself to
15:49.52 CIA-38 BRL-CAD: simply be a separator so these should work: '12,23,34', '12, 23, 34', '12 ,23 ,
15:49.54 CIA-38 BRL-CAD: 34', '12 23 34', '12/23/34', etc.
15:50.59 brlcad so make it better, just note that it's allowing quite a lot of stuff with that 'skip one char blindly' trick ..
15:52.19 brlcad the scan for a decimal ... is the "ispartofafloat()" you speak of inlined
16:05.06 brlcad someone(tm) should see if that separator change works .. seeing if ebm is still busted, then adding the space back in after the commas, then seeing if it's still busted
16:05.20 ``Erik compilers tend to do that if you don't tell it not to optimize, yes
16:05.45 brlcad is probably someone(tm) since he busted it, hm
16:06.01 ``Erik sorry, was in a branch meeting, tons of talk about 'open source lessons learned' and stuff
16:06.07 brlcad ``Erik: i just mean it's not much more diff than the current logic
16:06.29 brlcad stayed too late last night
16:07.28 starseeker growls
16:07.51 starseeker OK Tk, how do I reset your origin point...
16:14.46 *** join/#brlcad mafm_ (n=mafm@213.Red-81-37-118.dynamicIP.rima-tde.net)
16:18.01 starseeker this is annoying - in an mgedrc file, whether or not the default geometry placement was saved in aqua or X11 Tk will make a difference in how to handle it
16:18.51 starseeker I'm not terribly sure there is a clean way to handle this with Tk as it currently stands...
16:26.29 brlcad starseeker: that snippet you showed last night probably sets an origin point
16:29.24 starseeker brlcad: I'm not sure - the more I look at it, it appears that routine is to ensure that part of a particular window in question is always visible on some display
16:30.11 starseeker which isn't what we need - we need to know where the origin point is against the global screen size, and then (ideally) move the origin to some consistent point
16:30.49 starseeker 'course, people could just move the windows back and resave their prefs...
16:31.26 brlcad ideally, we should identify the "primary" display and start up our window(s) there only
16:31.43 brlcad the routine you showed isn't a solution, but the means it uses might help
16:32.02 starseeker apparently X11 Tk (at least on the Mac) considers the whole set of monitors as one big screen
16:32.08 brlcad to make sure a window is always visible on a display entails some knowledge of where the displays are
16:32.21 starseeker nods
16:32.46 brlcad not unexpected, it's probably just using the root window
16:32.51 brlcad which is the whole set
16:33.01 starseeker yes, but if you have preferences saved with X11 (which assumes one huge screen for coordinates) and then start up with Aqua, the default coordinate system assumptions have changed
16:33.08 starseeker and there isn't really a way to detect that
16:33.10 brlcad also why rt kicks off a window in the top-most left
16:33.15 brlcad libfb does the same thing
16:34.28 brlcad so coordinates are tied to display type, detct if it's the same as the one loaded, if not then disregard the read coordinates
16:34.58 starseeker we'd have to stash the current display type in the .mgedrc file
16:35.17 brlcad at the lowest level, though, X11 does know -- we can add a proc to mged that will give the "primary display" or coordinates that get us there, etc
16:36.29 brlcad does archer start up on primary? or spread across root?
16:36.50 brlcad or just some window centered on root
16:37.34 starseeker Archer X11 appears (currently on my Mac) in the uppper left of the extreme left monitor
16:38.02 starseeker Archer aqua appears just under the apple menu
16:39.25 starseeker what about stashing different saved geoms based on windowing system? mged_default(aqua_ggeom)
16:40.02 starseeker won't
16:40.06 starseeker do the translation
16:40.16 starseeker but would avoid using "wrong" settings
16:40.48 brlcad could do that, but I just can't imagine that being a common use case outside of development
16:41.28 starseeker true... I suppose once Aqua is available it's not too likely users would be gung-ho to switch back to X11
16:41.59 brlcad or even that the "wrong" settings aren't "good enough" even if there is a .mgedrc lying around
16:42.08 brlcad as long as they can get ahold of the window to move it
16:42.17 starseeker nods
16:42.24 starseeker fairly minor point, really
16:42.27 brlcad which is an issue .. that patch is useful for the reasons it mentioned
16:42.35 starseeker true
16:43.27 starseeker sanity checking, as it were
17:15.08 Phurl ok brlcad http://mail.python.org/pipermail/pythoncad/2010-January/000974.html it looks like other cad tools are interesting in producing a test suite
17:37.36 Phurl <PROTECTED>
17:38.38 *** join/#brlcad Ralith (n=ralith@69.90.48.97)
17:46.09 *** join/#brlcad Ralith (n=ralith@69.90.48.97)
18:18.09 *** join/#brlcad mafm (n=mafm@155.Red-83-37-155.dynamicIP.rima-tde.net)
18:27.22 *** join/#brlcad mafm2 (n=mafm@88.Red-83-58-21.dynamicIP.rima-tde.net)
18:44.14 brlcad Phurl: there are lots of folks interested in DWG (it's what they know), not at all surprising
18:44.42 brlcad that doesn't change any of the comments from earlier, the legal issues, the problematic format, the misdirection of limited resources
18:45.31 brlcad more power to the libredwg folks if they get it all working, can keep in maintained, and don't get sued
18:45.35 brlcad i'll be happy for them
18:50.36 *** join/#brlcad mafm2 (n=mafm@63.Red-83-63-197.staticIP.rima-tde.net)
18:53.07 louipc Would autodesk be suing? Shouldn't they have already taken down opendwg?
18:54.32 ``Erik if they haven't noticed it or decide it's not worth the cost of a c&d yet, ... *shrug*
18:55.20 brlcad they already castrated opendwg
18:55.37 brlcad they "settled" their suit against the open design alliance
18:55.42 Phurl brlcad, well, i am going to collect test suites
18:55.50 louipc ah hehe
18:55.51 Phurl and they have not sued stallman yet
18:55.57 brlcad Phurl: have fun :)
18:56.00 Phurl so that is going to be very fun to watch
18:56.05 Phurl autocad vs fsf
18:56.31 louipc better base devel somewhere without software patents
18:57.32 Phurl yeah
18:57.36 Phurl well, we will see
18:57.53 louipc but really it shouldn't be illegal to read dwg
18:58.03 brlcad they have a pretty good chance, but the same reason ODA failed is going to be an issue
18:58.12 louipc a case could be made against autodesk for holding data hostage
18:58.26 Phurl yeah
18:58.38 brlcad it's not illegal .. the issue is that to be a fully 'valid' DWG file, there are binary markers that go into the file
18:58.42 Phurl look when goverments spend tax dollars to produce dwg files
18:58.42 brlcad one of those markers involves writing the word "AutoCAD" to the file
18:58.45 louipc if you can read, then you can migrate out
18:58.46 Phurl we are going to read them
18:58.54 louipc hahaha copyright?
18:58.55 brlcad that then becomes an issue of trademark use
18:58.57 Phurl and if i have to use sed to remove autocad
18:59.01 louipc oh trademark right
18:59.07 Phurl before i process teh file
18:59.07 brlcad then it's no longer validatable
18:59.12 Phurl that is ok
18:59.14 brlcad within autocad
18:59.20 Phurl i just want to read the file into openstreetmap
18:59.22 Phurl that is all
18:59.27 louipc nice format
18:59.29 Phurl we are getting more and more city maps in dwg
18:59.36 Phurl from governments
18:59.42 brlcad basically it means that while you can read/write the dwg format, you can't create a useful exchange library that will play with autocad
18:59.47 Phurl that is ok!
18:59.55 Phurl i dont want to exchange with autocad
18:59.57 brlcad and it's still a constant chase against their binary format
18:59.58 Phurl i want to take from them
19:00.01 Phurl yes
19:00.09 Phurl that is why we need a test suite
19:00.15 louipc eh
19:00.22 Phurl so that we can convert them all to the new format with the new version
19:00.29 Phurl and then decode the format based on the files
19:00.41 Phurl at least that is my idea
19:00.47 brlcad I get it, you're good because you just need a reader
19:00.47 louipc convert it to step or something?
19:00.54 Phurl step?
19:00.54 brlcad that's not the point
19:01.38 louipc that's the latest iso standard format for CAD
19:01.44 Phurl ahhh
19:02.03 Phurl if i could read them, then i could conver them to step
19:02.23 brlcad the point is about libredwg in general and the future of supporting that entire path of development, as being one doomed to failure in terms of an exchange format at least
19:02.50 brlcad wasted effort, you're still chasing the binary format which has to be reverse engineered in a clean way with each and every release
19:02.55 louipc fsf should promote development of free/open step libraries more than hacking dwg
19:03.01 brlcad well not "you", but the libredwg devs
19:03.04 louipc it would be MUCH more useful
19:03.29 brlcad louipc: yeah, I started having that discussion with them just recently
19:03.39 brlcad they don't have a lot of expertise with CAD
19:03.52 louipc cool
19:04.19 brlcad one of their lead guys for the high priority projects and I were talking about how that should probably get changed
19:04.28 brlcad or at least generalized/expanded
19:04.48 brlcad it's not about DWG, it's about the open exchange of geometry in a prevalent and convenient format
19:05.05 brlcad which STEP pretty much fulfills aside from the ISO fee
19:05.06 louipc yeah you can still get dwg data via dxf
19:05.34 Phurl brlcad, yes
19:05.43 Phurl i understand it is a waste of effort
19:06.15 Phurl but i think it is an effort that I can help with
19:06.19 brlcad which is exactly what that format is for even, the obsession with the binary format is usually just incompetence or apathy
19:06.22 Phurl even if it goes nowhere
19:06.30 brlcad Phurl: http://www.google.com/search?q=filetype%3Adwg
19:06.34 brlcad that might help get you started
19:06.46 Phurl I will be able to rescue some files
19:06.49 Phurl thanks brlcad good idea
19:06.59 brlcad there are 10k files that list there, you can get specific subsets with additional keywords
19:07.40 brlcad Phurl: I'm all for empowering people to spend their time however they see fit -- it's no concern of mine so long as you don't try to recruit my time and effort as well ;)
19:08.05 Phurl brlcad, its ok. I have serious doubts about this myself
19:08.26 brlcad heck, as I mentioned yesterday, I wouldn't mind a dwg-g importer for BRL-CAD
19:08.32 Phurl yes
19:08.33 brlcad but then we can't even use libreDWG
19:08.37 Phurl i remember
19:08.47 Phurl well you can, but you cannot include it
19:08.53 Phurl in your binary
19:08.59 Phurl just keep it as a plug in
19:09.13 brlcad which means we can't use it from a practical standpoint
19:09.19 brlcad that maintenance burden is too much
19:09.34 brlcad we can't distribute it or integrate it
19:09.58 brlcad only passively link against it in an isolated tool, which is paramount to a separate mini-project in itself
19:09.58 Phurl ok
19:10.13 brlcad I'd much rather focus on comprehensive STEP support or even DXF support
19:10.29 Phurl well, i can imagine a webservice
19:10.38 Phurl that you can just convert your files on
19:10.41 Phurl or whatever
19:10.57 brlcad the industry won't move itself, to get people to stop using DWG .. you have to stop supporting DWG
19:11.23 brlcad only writing importers is a good way (a really common way)
19:11.40 brlcad but requiring their own tools to export in new formats is even better
19:11.49 Phurl yes
19:11.57 brlcad that way if AutoCAD's STEP export sucks, Autodesk can be pressured to improve it
19:12.08 brlcad (which it doesn't, it's pretty "decent")
19:12.28 Phurl yeah.... i can imagine they are very allergic to anything that would reduce in their control
19:12.44 brlcad leaving the native format is always less than ideal, but leaving a closed proprietary format is the best excuse of any
19:13.00 Phurl well there are alot of different open source cad tools
19:13.08 brlcad not really
19:13.10 Phurl and there should be a way to collaborate
19:13.11 Phurl no?
19:13.13 louipc not worth talking about
19:13.14 brlcad there are a handul of pet projects
19:13.31 Phurl well as an outsider
19:13.38 Phurl it is hard to gauge them
19:13.40 brlcad some making interesting progress, but it's still a very tiny grain of sand when you look at the requirements of a CAD system
19:14.02 Phurl yes
19:16.06 brlcad consider that BRL-CAD has more manpower development effort invested than every other open source CAD project *combined*, yet we're a ways off from being a replacement for general CAD use ourselves
19:16.18 Phurl hmmm.
19:16.26 brlcad and we've got more than 500 staff-years of developer effort invested
19:16.34 Phurl i just know about qcad as well
19:16.39 Phurl and pycad
19:16.40 Phurl etc
19:17.06 brlcad yeah, there are a few others
19:17.11 brlcad notable others
19:17.17 louipc brl-cad is the only one worth spending time on
19:17.32 brlcad qcad is the only other one remotely production ready, they focus on 2D
19:17.32 Phurl ok
19:18.00 louipc brl-cad is the most advanced with truely open development
19:18.06 Phurl well I looked into cad stuff a while back, including brlcad for working on making 3d models of streets
19:18.13 Phurl i used blender in the end
19:18.18 brlcad we have converters that took more effort than qcad took to implement :)
19:18.26 louipc qcad, opencascade are pseudo-open
19:18.42 Phurl i see
19:18.46 brlcad opencascade isn't a CAD system, it's a set of libraries
19:18.51 Phurl ok, well what about a debian package?
19:18.57 louipc oh hahh
19:19.00 brlcad there are a couple front-ends that use it under the hood
19:19.17 brlcad freecad is one, iirc
19:20.02 Phurl ok guzs
19:20.09 Phurl i will have to look into this more
19:20.11 brlcad Phurl: if you don't have an engineering need, a content modeling system like blender does make plenty sense
19:20.11 Phurl thanks!
19:24.43 Phurl yes
19:25.06 Phurl i understand that!
19:39.31 brlcad finally finishes his report and hits the road
19:40.20 ``Erik doesn't that hurt your knuckles?
19:40.32 brlcad not if you hit it hard enough
19:40.50 ``Erik hard enough to destroy all the nerves?
19:41.17 brlcad exactly
19:47.08 ``Erik double parse bug fix makes ebm work again
19:48.10 ``Erik http://brlcad.org/~erik/regress/newsolidsdiff.png
20:44.09 *** join/#brlcad Phurl (n=mdupont@ip-81-210-245-60.unitymediagroup.de)
21:28.22 ``Erik bah, openNURBS blows up on sparc, lameness
21:30.58 *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
21:44.43 ``Erik and now it doesn't blow up :D
21:44.49 CIA-38 BRL-CAD: 03erikgreenwald * r37169 10/brlcad/trunk/src/other/openNURBS/ (opennurbs_point.cpp opennurbs_quaternion.cpp): include ieeefp.h when finite() is needed
21:46.39 ``Erik raid + easp O.o (expensive array of slow processors)
22:11.13 ``Erik tons of link errors with the libXX.la vs libXX_nil.la :/
22:18.41 yukonbob ``Erik: that image looks like it was shot in the middle of the black forest at midnight
22:37.22 ``Erik welcome to the wonderful world of pixdiff
22:37.47 ``Erik correct results are a very dark hint of the geometry, to help place the broken pixels (the white/magenta/yellow stuff)
22:51.13 *** join/#brlcad docelic (n=docelic@78-2-71-58.adsl.net.t-com.hr)
23:00.50 yukonbob ahhhhh. Now it's cool.
23:00.51 yukonbob ;)
23:14.03 *** join/#brlcad Nohla (n=jesica@168.226.178.17)
23:23.33 *** join/#brlcad jesica__ (n=jesica@168.226.178.17)

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