| 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: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: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: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: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.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.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: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) |
