| 01:20.11 | starseeker | brlcad: If it's r33993, that's just headers and changes to c files |
| 01:33.54 | starseeker | prepares to shift the headers back into their individual directories |
| 01:43.32 | CIA-40 | BRL-CAD: 03starseeker * r34000 10/brlcad/trunk/src/other/step/ (21 files in 2 dirs): Put cldai headers back where they came from |
| 01:46.49 | *** join/#brlcad dtidrow (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT VICTIM] |
| 01:46.49 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) [NETSPLIT VICTIM] |
| 01:49.42 | CIA-40 | BRL-CAD: 03starseeker * r34001 10/brlcad/trunk/src/other/step/ (22 files in 2 dirs): Put cleditor headers back where they came from |
| 01:50.28 | *** join/#brlcad dtidrow (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT VICTIM] |
| 02:00.24 | CIA-40 | BRL-CAD: 03starseeker * r34002 10/brlcad/trunk/src/other/step/ (40 files in 2 dirs): Put clstepcore headers back where they came from |
| 02:04.30 | CIA-40 | BRL-CAD: 03starseeker * r34003 10/brlcad/trunk/src/other/step/ (24 files in 2 dirs): Put clutils headers back where they came from |
| 02:10.48 | *** join/#brlcad muale (n=n3wm0nk@pool-71-172-120-145.nwrknj.east.verizon.net) |
| 02:12.30 | brlcad | starseeker: yeah, I see that now going back through my commit log mails .. maybe just more headers than I expected or all the 'c's in the names |
| 02:14.55 | brlcad | which is odd.. I swear my svn update said a slew of .cc/.c files |
| 02:15.12 | brlcad | only reason it caught my attention |
| 02:15.19 | brlcad | oh well |
| 02:15.30 | starseeker | brlcad: Now I remember what the issue was - a lot of files assume the .h files ARE all in the same directory |
| 02:15.41 | brlcad | wonders why cruisecontrol still says distcheck is failing |
| 02:15.42 | starseeker | or at least included |
| 02:15.58 | brlcad | how so? |
| 02:16.14 | brlcad | #include "somefilenotinthisdir.h"? |
| 02:16.44 | brlcad | that'd mean their build system was setting the cppflags |
| 02:16.49 | starseeker | mostly #include <somefile.h> |
| 02:17.02 | brlcad | yeah, same thing |
| 02:17.06 | brlcad | just bad style |
| 02:17.37 | starseeker | the build (originally) takes place in a directory called editorCore |
| 02:17.51 | starseeker | looks like they copied a bunch of stuff somewhere to build it |
| 02:17.52 | starseeker | ick |
| 02:18.05 | starseeker | what's the correct solution? |
| 02:18.27 | starseeker | at -I../src/clwhatever to the Makefile.am s? |
| 02:18.32 | starseeker | er s/at/add |
| 02:19.01 | starseeker | or I can change the references to "../clwhatever/file.h" |
| 02:19.07 | brlcad | either to the Makefile.am's or to the configure.ac if it makes sense to be project-wide |
| 02:19.25 | brlcad | nah, I wouldn't recommend that -- ties to the dir structure, which could change |
| 02:20.02 | brlcad | only "clwhatever/file.h" if you wanted to leave everything in include/ and have include/clwhatever |
| 02:20.05 | starseeker | is leary of doing it at the configure.ac level, so am files it is - just libwhatever_la_CXXFLAGS = -I... |
| 02:20.38 | brlcad | given how it looks like scl is organized, Makefile.am sounds like the right approach |
| 02:20.42 | starseeker | brlcad: that might make sense once I figure out which headers are actually intended as "API" headers |
| 02:21.04 | starseeker | takes a stab at it |
| 02:21.14 | brlcad | could 'maybe' have the lower-level C libs be "global" cppflags (ala include/) but wouldnt' matter much |
| 02:21.27 | brlcad | that'd be useful |
| 02:21.52 | brlcad | if you can discern the difference, then the local includes should be identified via #include "./file.h" |
| 02:22.12 | brlcad | so you can distinguish private from public headers on use |
| 02:22.32 | starseeker | nods |
| 02:22.38 | brlcad | and get rid of the <>'s |
| 02:23.20 | brlcad | that should be for finding system headers or nominally for system-"installed" headers |
| 02:24.00 | starseeker | that's what I thought |
| 02:25.29 | CIA-40 | BRL-CAD: 03starseeker * r34004 10/brlcad/trunk/src/other/step/src/clstepcore/Makefile.am: Add includes needed for original header locations in clstepcore |
| 02:26.00 | starseeker | thinks commit 40000 should be a new modeler for BRL-CAD :-) |
| 02:26.09 | brlcad | heh |
| 02:28.44 | CIA-40 | BRL-CAD: 03starseeker * r34005 10/brlcad/trunk/src/other/step/src/cleditor/Makefile.am: Add includes needed for original header locations in cleditor |
| 02:31.54 | starseeker | OK, that may do it |
| 02:31.57 | CIA-40 | BRL-CAD: 03starseeker * r34006 10/brlcad/trunk/src/other/step/src/cldai/Makefile.am: Add includes needed for original header locations in cldai |
| 02:41.18 | CIA-40 | BRL-CAD: 03starseeker * r34007 10/brlcad/trunk/src/other/step/src/exppp/Makefile.am: Whoops - fix noinst_HEADERS in exppp |
| 02:50.02 | CIA-40 | BRL-CAD: 03starseeker * r34008 10/brlcad/trunk/src/other/step/src/clstepcore/Makefile.am: Add the clstepcore headers to Makefile.am as noinst for now. |
| 03:21.54 | yukonbob | hello, cadheads |
| 03:25.30 | bjorkintosh | ah it's the 'hello, cadheads' bot. |
| 03:34.07 | yukonbob | ah, it's the "ah it's the 'hello, cadheads' bot." bot |
| 03:36.10 | bjorkintosh | it is none other but i. |
| 03:36.12 | bjorkintosh | bows. |
| 03:37.23 | brlcad | waves |
| 03:37.51 | yukonbob | evening bjorkintosh, brlcad |
| 03:37.52 | bjorkintosh | i'm now setting up a 4th machine to gui -d host:0 on :D |
| 03:37.58 | brlcad | heh |
| 03:38.05 | yukonbob | checks in from Airport -- free wifi, yay!!1 |
| 03:38.13 | yukonbob | *airport |
| 03:38.14 | bjorkintosh | it's teh AW3S0M3! |
| 03:42.38 | yukonbob | what's new, brlcad ? |
| 03:43.25 | brlcad | documented brep planning, new dev making awesomeness happen, new release |
| 03:43.45 | brlcad | contentedly wanders off for a bit |
| 03:44.55 | yukonbob | checks page for release details... |
| 03:47.26 | yukonbob | updates svn |
| 05:22.13 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 05:45.54 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 06:08.38 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 07:56.30 | *** join/#brlcad madant (n=madant@117.196.146.10) [NETSPLIT VICTIM] |
| 08:10.50 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:29.50 | *** join/#brlcad _sushi__ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:42.13 | *** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 08:43.16 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 08:56.19 | brlcad | morning d_rossberg |
| 08:56.51 | d_rossberg | morning brlcad |
| 09:52.44 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 10:00.24 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:28.46 | d-lo | mornin all! |
| 11:18.33 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-91.sbndin.btas.verizon.net) |
| 11:29.34 | brlcad | howdy d-lo |
| 11:30.10 | *** join/#brlcad madant (n=madant@117.196.139.36) |
| 11:30.43 | d-lo | is reading up on the use of /dev/poll for IO multiplexing. Purty neat akshually. |
| 11:34.03 | brlcad | creative, but very non-portable |
| 11:34.11 | d-lo | yeah I know :/ |
| 11:34.14 | d-lo | still neat :) |
| 11:34.18 | d-lo | good brain food. |
| 11:34.26 | brlcad | nods |
| 11:34.46 | d-lo | besides, who needs windows support. pffft. |
| 11:34.48 | brlcad | old sysvism |
| 11:34.50 | d-lo | =D |
| 11:34.52 | brlcad | not just windows |
| 11:34.58 | brlcad | that's not even portable across various unices |
| 11:35.44 | brlcad | it's a relatively new/old sysv construct |
| 11:36.14 | brlcad | old sysv systems are like old at&t unix (which I don't think had a /dev/poll, but was sysv nonetheless) |
| 11:36.39 | brlcad | linux adopted some sysv, most distros probably include it |
| 11:36.41 | brlcad | and solaris |
| 11:37.00 | brlcad | but no bsds, no mac, no hp, maybe aix, etc |
| 11:37.29 | brlcad | and flaky across various versions of those that do support it |
| 11:38.21 | d-lo | heh, 'flaky'... is that a technical term? :) |
| 11:38.33 | brlcad | yep |
| 11:38.56 | brlcad | there are lots of flakey interfaces when it comes to communication |
| 11:41.16 | brlcad | that's what makes interfaces like libpkg that are well tested and robust to environments/platforms/events/conditions very useful |
| 11:41.46 | d-lo | question on libpkg: how well does it handle multiple connections? |
| 11:42.42 | brlcad | handles them just fine |
| 11:42.45 | brlcad | it's point to point client-server based, so you do what you want with the descriptor |
| 11:43.37 | brlcad | it pushes most of the logic up into the application layer |
| 11:43.43 | d-lo | poorly worded question :) I ment to ask: Is there any utility in libpkg for managing multiple connections at once? |
| 11:45.28 | brlcad | what do you mean by managing them? it doesn't really manage the connection, that's the app's job -- it just establishes a point to point and you do with that as you please |
| 11:45.39 | brlcad | from there you can build up pretty much any network infrastructure |
| 11:46.04 | d-lo | kk, thats what I thought. Just wanted to make sure I wasn't missing anything obvious.... |
| 11:46.05 | brlcad | be that a token-ring, simple client-server, peer to peer shared, whatever |
| 11:48.26 | *** join/#brlcad d_rossbe1g (n=rossberg@bz.bzflag.bz) |
| 11:48.36 | d-lo | cool. subject change: I would like to revisit our discussion about how the .g data in the svn is going to be stored |
| 11:49.36 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) |
| 11:50.33 | d-lo | I cannot remember what we desided was the best amount of geometry to include in a single .g file: A comb, A region, or a single Prim.... |
| 11:51.13 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 11:52.23 | brlcad | per object |
| 11:53.00 | d-lo | okay, 1 .g contains a single db object. And the actual file names were going to be the UUID ? |
| 11:54.16 | brlcad | a single db object sans _GLOBAL even |
| 11:54.53 | brlcad | which might take a few minor back-end changes to make sure it doesn't stub them in |
| 11:56.55 | brlcad | what names become an effective mapping will be probably need to be heavily tied to a given backend storage manager that decides how to map a request to a storage mechanism |
| 11:59.59 | d-lo | hrm, I had no idea that subversion REQUIRES Apache Portable Runtime... I was under the assumption that it could be built without it. |
| 12:00.02 | d-lo | :/ |
| 12:00.23 | brlcad | using uuid is maybe what it'll end up needing to be, but the danger there will be ending up needing to perform some O(n) lookup for every object name, table of content inconsistency problems, etc |
| 12:00.51 | brlcad | lots of codes use apr, sort of like our libbu |
| 12:01.07 | d-lo | could you explain '0(n)' ...i don't understand that. |
| 12:01.22 | brlcad | basically a linear lookup cost |
| 12:01.33 | brlcad | the complexity of a given action |
| 12:01.46 | brlcad | ideally you want O(1), constant cost |
| 12:01.58 | d-lo | ah, i c. |
| 12:01.59 | d-lo | thanks |
| 12:02.13 | brlcad | i.e., if i ask for X, it takes you exactly "one step" to give me X |
| 12:03.14 | brlcad | if you have to even look down a list for X, that becomes O(n) linear time, or possibly O(logn) or O(nlogn) if you use some hierarchical container or hashes |
| 12:03.55 | brlcad | the easiest first step is to probably just directly map a .g to a scoped context, i.e. a directory |
| 12:04.25 | brlcad | with each object in the .g mapping to a file in that dir with the name being the name of that object from the .g |
| 12:04.35 | brlcad | that would maintain O(1) |
| 12:05.22 | d-lo | so.... one 'master' .g that knows the location of all other data? |
| 12:06.20 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 12:07.05 | brlcad | not exactly, it amounts to how many problems are you trying to solve next |
| 12:07.30 | d-lo | you've got me 99% confused now. |
| 12:07.39 | brlcad | first step was deliver a .g when someone asks for a .g, right? |
| 12:08.04 | brlcad | i'm saying next step would be to deliver a sub portion of a .g when someone asks for it |
| 12:08.06 | d-lo | correct |
| 12:08.29 | d-lo | so then they would supply a filename and an objectname or would filename be assumed? |
| 12:08.56 | brlcad | i'd turn it into a path request right away since that's already implied |
| 12:09.24 | brlcad | first allowed was whatever://localhost/file.g |
| 12:09.33 | brlcad | now you'd be allowing whatever://localhost/file.g/object |
| 12:10.20 | d-lo | feck, now i have to get and build openSSL for APR :/ |
| 12:10.26 | d-lo | okay I understand now. |
| 12:11.03 | brlcad | you wouldn't even have to break up the .g files yet to make that work if you didn't want to, and have the storage manager do the object lookup with a folder filled with .g files |
| 12:11.39 | brlcad | then next step might be to have a storage manager that turns the .g files into dirs and has a .g per object in each of the various .g subdirs |
| 12:11.46 | d-lo | Question: If no other data bout 'object' is known except the path to it, how will the GS get a handle on it without walking the tree? (aka, deviating from linear time?) |
| 12:12.55 | brlcad | that last step I mentioned returns it to linear time |
| 12:13.04 | brlcad | er sorry, constant time |
| 12:13.19 | brlcad | as path would map to file/data |
| 12:15.22 | brlcad | note that an object-scoped request, like //localhost/file.g/path/to/object is still constant -- it just means load three objects (path, object, and to) in the file.g context |
| 12:16.13 | brlcad | that'd be interesting actually |
| 12:17.42 | brlcad | broken out per file like that into dirs, it could conceivably outperform current single-file accessat least the asymptotic complexity is less on paper |
| 12:18.36 | brlcad | just bigger constants (multiple file and operating system overhead) |
| 12:19.12 | d-lo | so are you saying have less .g files that are 'higher' in the heirarchy or more .g files 'lower' in the heirarchy? *confused* |
| 12:20.21 | starseeker | d-lo: heck with subversion, build on top of git ;-) |
| 12:20.22 | brlcad | that turning a dir filled with .g's into a dir of dirs filled with per-object-g's could conceivably outperform |
| 12:20.34 | brlcad | git doesn't have libs |
| 12:20.41 | brlcad | and isn't portable |
| 12:20.48 | starseeker | reflects that a power outage is a great way to interrupt a hacking session |
| 12:21.56 | d-lo | Okay, so, instead of a single dir with a bajillion .g's in it, organize it into a heirarchy of dirs with the .g's sitting at the 'bottom' of the heirarchy? |
| 12:22.09 | starseeker | brlcad: very true |
| 12:22.13 | starseeker | blegh |
| 12:22.42 | starseeker | checks on openssl's license - thought it was weird |
| 12:23.40 | d-lo | just read it... don't think it will be a problem. |
| 12:24.11 | starseeker | yeah, looks OK |
| 12:24.18 | starseeker | checks APR |
| 12:24.59 | d-lo | besides, svn requires libserf which requires openSSL.... so, if anything in this stupid req tree precludes us from using it, we might have a problem :/ |
| 12:25.13 | brlcad | d-lo: I wouldn't start with a hierarchy of dirs, just a single scope |
| 12:25.58 | starseeker | d-lo: Right. I just thought we should check since my original understanding was that the long term goal is to have a geometry server in every install of BRL-CAD |
| 12:26.38 | brlcad | having a hierarchy adds additional complexity not yet needed -- not clear that's what we'd want to end up with down the road |
| 12:27.08 | brlcad | maybe it is, but hard to say until that feature is being addressed because it gets nasty when things are no longer at a fixed depth in the hierarchy |
| 12:27.12 | starseeker | hmm - APR is Apache License 2.0 |
| 12:28.07 | brlcad | apache license is fine |
| 12:28.23 | brlcad | it's basically a more verbose bsd license |
| 12:28.33 | d-lo | LGPL = Library General Public License? |
| 12:28.51 | starseeker | Ah. Is this the one that was GPL incompatible because of the patent thing? |
| 12:28.55 | brlcad | ~lgpl |
| 12:28.56 | ibot | hmm... lgpl is the Lesser General Public License, see http://www.gnu.org/copyleft/lesser.txt or http://www.fsf.org/licenses/lgpl.txt |
| 12:29.15 | brlcad | used to be library, but fsf changed it to be lesser to try to get more folks to use gpl |
| 12:29.47 | d-lo | ah, okay. Then the license for 'neon' is okay. |
| 12:30.22 | brlcad | is that what they use? |
| 12:30.51 | brlcad | when I surveyed them a couple years ago, everything in svn and needed by svn was fine license-wise |
| 12:31.40 | d-lo | yeah, neon = Library GPL |
| 12:32.20 | brlcad | note that's just what they call it :) |
| 12:32.31 | brlcad | lots of folks were pissed by fsf trying that |
| 12:32.33 | d-lo | well, I am going to double check since the dependancy chain is getting bigger than I expected :/ |
| 12:32.45 | CIA-40 | BRL-CAD: 03starseeker * r34009 10/brlcad/trunk/src/other/step/conf/ (. MAJOR MINOR PATCH): Ahem - as I was trying to do before the power went out, add in conf so step configure has some version numbers to work with. |
| 12:33.03 | brlcad | it's just manipulative, trying to coerce based on the name implications |
| 12:33.17 | starseeker | FSF is famous for being manipulative |
| 12:33.29 | d-lo | right :) I learned quickly to not trust the names, but, rather, read the fine print. |
| 12:33.32 | starseeker | to be fair, they are open about having a political agenda to push |
| 12:33.52 | brlcad | d-lo: question earlier, perhaps lost during the irc reconnect -- curious why you asked whether pkg managed connections? |
| 12:34.09 | starseeker | still steers clear of the GNU Free Documentation License - that was a real let-down |
| 12:34.11 | d-lo | I will need someone to sit down and show me more about the build system, aka subbuilds and the NODIST stuff. |
| 12:35.06 | d-lo | brlcad: I asked that because i couldn't remember if libpkg did the managing or not. Wanted to make sure I wasn't missing something important and running off to re-invent the wheel. |
| 12:38.44 | brlcad | d-lo: brlcad/src/fbserv/fbserv.c is an example how the framebuffer server handles multiple requests |
| 12:38.49 | brlcad | just keeps the clients in an array |
| 12:38.54 | brlcad | simple easy to grok |
| 12:39.42 | brlcad | support interleaved requests and updates |
| 12:39.42 | brlcad | just a few lines of code |
| 12:40.51 | brlcad | follow the "clients" keyword and it should be relatively obviously |
| 12:45.21 | d-lo | pretty sexy. |
| 12:46.11 | CIA-40 | BRL-CAD: 03starseeker * r34010 10/brlcad/trunk/src/other/step/ (3 files in 3 dirs): Add in some more headers to scl Makefile.ams |
| 12:48.14 | brlcad | starseeker: when you get the chance, maybe try a distcheck on a fresh checkout -- still getting failure notices since the addition |
| 12:49.25 | brlcad | and yeah, I know -- I don't know why either, should be okay .. but it's not at least accordingly to cruisecontrol |
| 12:49.36 | brlcad | and can't get to log just yet |
| 12:54.30 | brlcad | hah, cute: http://www.compasslearningodyssey.com/sample_act/math3_4/MA3CA05a-package_preloader.swf |
| 12:54.44 | brlcad | could do something similar for the brl-cad primitives! |
| 12:55.29 | starseeker | brlcad: OK, will do |
| 13:01.39 | CIA-40 | BRL-CAD: 03starseeker * r34011 10/brlcad/trunk/src/other/step/src/ (3 files in 3 dirs): Oh, yeah - those include links shouldn't assume in-source build |
| 13:02.17 | starseeker | starts distcheck running and starts prepping for the road... |
| 13:06.03 | ``Erik_ | *readreadread* |
| 13:06.39 | d-lo | eh? |
| 13:07.36 | brlcad | means he's reading the backlog |
| 13:08.37 | d-lo | guess I am not as fluent in l33tsp34k as I thought :/ |
| 13:10.30 | ``Erik_ | z0mfglolf34d|ngl0gz0rz |
| 13:10.53 | ``Erik_ | sorry, fit of geek tourettes there O:-) |
| 13:10.54 | brlcad | lolomfgponies! |
| 13:11.08 | ``Erik_ | l0llerk0pt0r |
| 13:11.59 | ``Erik_ | um, direct link to a file doesn't guarantee O(1), some fs's are not constant in resolving the file name to the initial inode |
| 13:12.07 | d-lo | l0ll3rsk8t3s |
| 13:12.30 | brlcad | ``Erik_: O(1) to the app's logic, that's all we control |
| 13:12.35 | ``Erik_ | (they tend to be damn fast, but I had a directory with ~17k files and getting the file handle took several seconds) |
| 13:13.09 | brlcad | just not from a global view, sure |
| 13:13.43 | d-lo | question: Does a linker error of: lib/libz.a(crc32.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC |
| 13:13.53 | d-lo | tell me that its a 32 bit lib? |
| 13:13.55 | ``Erik_ | *shrug* I argue that it's important to understand and consider the limits of the OS and hw, too, but *shrug* :) |
| 13:14.30 | brlcad | d-lo: not necessarily |
| 13:14.50 | brlcad | ``Erik_: uhm, I'd generally think that goes without saying? |
| 13:14.51 | ``Erik_ | -fPIC instructs it to make position independant code, required for a shared object |
| 13:15.26 | brlcad | mostly because it ends up with a lot of navel gazing and speculative jabber that isn't productive |
| 13:16.08 | ``Erik_ | heh, 'cept I've seen it come back to bite projects that worry about squeezing performance |
| 13:16.19 | brlcad | so? |
| 13:16.32 | brlcad | "bad things can happen" |
| 13:16.39 | brlcad | i don't find that surprising |
| 13:16.53 | d-lo | -fPIC is a compiler flag? |
| 13:16.57 | brlcad | yes |
| 13:17.06 | d-lo | kk danke |
| 13:17.31 | brlcad | you shouldn't have to add it on your code, though -- libtool handles that |
| 13:17.42 | ``Erik_ | *shrug* just admitting that is taking it into consideration, knowing how to cope with it is understanding those limits, otherwise you have stupid code and people blaming the wrong things |
| 13:17.58 | d-lo | hrm, well I am following the install directions to the letter and its giving me that error |
| 13:18.35 | brlcad | ``Erik_: this is exactly the kind of speculative jabber that I mean, though -- it's not solving an actual problem |
| 13:18.37 | ``Erik_ | all those #include "../something" lines in teh step stuff, hope that doesn't mess up too much |
| 13:19.13 | brlcad | if we implemented ours via a given O(1) approach, and found an OS problem, that would be an actual then that could be looked into |
| 13:19.29 | ``Erik_ | <-- just trying to get his brain back into gear :) |
| 13:22.13 | d-lo | and stay out! |
| 13:22.19 | d-lo | =D |
| 13:23.08 | ``Erik | heh |
| 13:41.57 | starseeker | forgot how long a distcheck takes on this machine :/ |
| 13:44.46 | brlcad | distcheck -j# will work |
| 13:48.57 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) [NETSPLIT VICTIM] |
| 13:48.57 | *** join/#brlcad dtidrow (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT VICTIM] |
| 13:50.21 | starseeker | only has 2 cpus and they both seem to be working :-( |
| 13:50.47 | starseeker | will probably upgrade in a year or two... |
| 13:50.54 | starseeker | tis getting slow |
| 13:51.20 | brlcad | my trusty old box takes a couple hours to distcheck now |
| 13:51.29 | brlcad | used to be about an hour before opennurbs :) |
| 13:52.43 | starseeker | heh |
| 13:53.06 | starseeker | yeah, the two sure ways to crush my box into performance hell are compiling KDE and compiling Openoffice |
| 13:53.57 | starseeker | blinks |
| 13:54.10 | starseeker | distcheck just passed on my machine: brlcad-7.14.5 archives ready for distribution |
| 13:59.04 | starseeker | will try again when he gets in |
| 14:05.34 | brlcad | starseeker: huh |
| 14:06.24 | brlcad | starseeker: then maybe it's something wrong with the cruisecontrol script that needs to get fixed |
| 14:07.11 | brlcad | maybe just needs another configure.ac update or something to make it reautogen |
| 14:15.14 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) [NETSPLIT VICTIM] |
| 14:15.14 | *** join/#brlcad dtidrow (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT VICTIM] |
| 14:26.29 | d-lo | I just priced a Quad 3GHz AMD with 4GB 1033MHz ram on a MB with onboard nVidia 9600 and 8 channel audio machine (no case) for about $350 if you DIY |
| 14:32.09 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 14:42.34 | CIA-40 | BRL-CAD: 03indianlarry * r34012 10/brlcad/trunk/src/ (libged/clone.c tclscripts/mged/help.tcl): Added 'clone' to mged_help_data table and added print_usage() when to few args |
| 14:56.03 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:01.12 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 15:26.13 | madant | hates namespaces |
| 15:26.43 | namespaces | hates madant. |
| 15:26.49 | madant | :P |
| 15:26.53 | d-lo | =D |
| 15:27.11 | *** join/#brlcad ``Erik__ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:50.34 | *** join/#brlcad ``Erik___ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:52.58 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 15:54.42 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-91.sbndin.btas.verizon.net) |
| 16:05.06 | CIA-40 | BRL-CAD: 03homovulgaris * r34013 10/brlcad/trunk/src/other/boost/ (8 files in 4 dirs): another boost update: spirit and phoenix related |
| 16:10.17 | CIA-40 | BRL-CAD: 03homovulgaris * r34014 10/brlcad/trunk/src/libpc/ (7 files): |
| 16:10.17 | CIA-40 | BRL-CAD: modifications for the usage of boost::spirit namespace instead of |
| 16:10.17 | CIA-40 | BRL-CAD: boost::spirit::classic, generic includes added to be replaced with the specific |
| 16:10.19 | CIA-40 | BRL-CAD: header files for the pertinent spirit and phoenix functions; also code syntax |
| 16:10.21 | CIA-40 | BRL-CAD: corrections in pcMathGrammar, pcMathLF and pcMathVM |
| 16:35.07 | CIA-40 | BRL-CAD: 03starseeker * r34015 10/brlcad/trunk/src/other/step/m4/prefix.m4: Whoops - put the right prefix.m4 back |
| 16:42.25 | *** join/#brlcad hippieindamakin8 (n=hippiein@59.92.168.117) |
| 17:05.36 | CIA-40 | BRL-CAD: 03starseeker * r34016 10/brlcad/trunk/src/other/step/ (11 files in 5 dirs): More step build tweaks. |
| 17:06.19 | *** join/#brlcad _``Erik__ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:16.12 | CIA-40 | BRL-CAD: 03starseeker * r34017 10/brlcad/trunk/src/other/step/ (configure.ac include/Makefile.am include/conf/Makefile.am): Few more fixes for step build system |
| 17:16.43 | *** join/#brlcad __``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:37.43 | CIA-40 | BRL-CAD: 03starseeker * r34018 10/brlcad/trunk/src/other/step/include/conf/Makefile.am: One more misc Makefile.am cleanup |
| 17:38.00 | *** join/#brlcad ___``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 17:42.17 | CIA-40 | BRL-CAD: 03starseeker * r34019 10/brlcad/trunk/src/other/step/ (8 files in 3 dirs): Clean up old config stuff in step |
| 18:00.50 | *** join/#brlcad madant (n=madant@117.196.138.140) |
| 18:05.04 | *** join/#brlcad rahul_cool (i=3b5bc963@gateway/web/ajax/mibbit.com/x-d7cc2a6d35286a1e) |
| 18:05.32 | rahul_cool | hiiiii all |
| 18:06.17 | rahul_cool | i wanna take part in gsoc 2009 on the project "CSG ray-trace optimizations".... |
| 18:06.25 | rahul_cool | can any one help me...... |
| 18:07.02 | *** join/#brlcad ___``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 18:13.44 | brlcad | rahul_cool: if you have to ask for help, then maybe not -- that's not an easy task :) |
| 18:14.04 | brlcad | also, note that the suggested list for 2009 hasn't been uploaded yet |
| 18:16.21 | brlcad | if you have a more specific question, go ahead an ask |
| 18:21.32 | starseeker | ``Erik: Yeah, you called it |
| 18:22.34 | starseeker | hmm... |
| 18:22.38 | starseeker | actua..y... |
| 18:43.08 | starseeker | grr the express.h include references most of the other express.h files |
| 18:43.14 | starseeker | er express . files |
| 18:43.24 | starseeker | express .h files come on bz |
| 18:43.38 | starseeker | this thing is so interrelated it's amazing |
| 18:47.30 | brlcad | it's common to have an interface file like that referencing other header files |
| 18:48.02 | brlcad | that's the same for the opennurbs headers if you recall, started with opennurbs.h, that just basically includes every other non-private api header |
| 18:48.12 | starseeker | right |
| 18:48.32 | starseeker | now will move a bunch of headers AGAIN to include, but this time in express, exppp, etc directories |
| 18:48.40 | brlcad | kinda what I'd like to do with bu/bn/rt too, one bu.h header that isn't 10k lines long |
| 18:48.59 | brlcad | instead breaks up the api into logical sections and bu.h just includes those various section headers |
| 18:49.12 | starseeker | do you want express.h as a "toplevel" including all the other "express/*.h" headers? |
| 18:49.20 | brlcad | how'd they do it? |
| 18:49.41 | starseeker | <snort> they stuffed all of them in express with the source files |
| 18:49.48 | brlcad | sometimes there's a good reason to not include *.h (especially if some are private, but even for non-private) |
| 18:50.13 | starseeker | Oh, I'm only going to move the ones either needed by express.h or explicitly included by (e.g.) fedex_plus |
| 18:50.45 | brlcad | ah, for the ones that you already determine are public |
| 18:50.49 | starseeker | right |
| 18:51.00 | starseeker | only putting them in include or include/express if forced to |
| 18:51.01 | brlcad | then yeah, could just include include/express/*.h |
| 18:51.11 | brlcad | though that might be redundant |
| 18:51.20 | brlcad | if it's hierarchical and not just two-level |
| 18:51.42 | starseeker | right now its flat |
| 18:52.34 | starseeker | I was thinking to stick all of 'em that are needed in include/express for now, change the includes to "express/file.h", and sort it out later if we want more structure |
| 18:55.07 | brlcad | why bother changing the includes? |
| 18:55.14 | brlcad | just add include/express to the cppflags |
| 18:55.39 | starseeker | Yeah, I guess that will work |
| 18:55.54 | starseeker | doesn't like trusting flags, but supposes he should |
| 19:12.02 | starseeker | brlcad: step has a memory.h and so does /usr/include - which one wins if I inclulde include/express ? |
| 19:17.46 | brlcad | as "memory.h" it should select a -I directed path first before default system include dirs |
| 19:18.52 | brlcad | as <memory.h> it could be unreliable -- forget gcc's rules on that |
| 19:19.09 | brlcad | think it still means try system first |
| 19:19.18 | starseeker | k |
| 19:36.47 | starseeker | gah - the yylineno issue is still there |
| 19:37.12 | starseeker | considers tearing hair out |
| 19:38.32 | starseeker | bison < 2 doesn't create it automatically, bison > 2 does |
| 19:38.49 | starseeker | can't find a way to conditionally create it (so far) |
| 19:40.06 | *** join/#brlcad madant_ (n=madant@117.196.128.161) |
| 19:40.10 | CIA-40 | BRL-CAD: 03starseeker * r34020 10/brlcad/trunk/src/other/step/ (60 files in 7 dirs): OK, one more time with the step include files. |
| 19:43.09 | starseeker | decides against tearing hair out and opts for researching |
| 19:45.57 | d-lo | the girls love bald..... |
| 19:47.37 | starseeker | mine doesn't |
| 19:51.22 | CIA-40 | BRL-CAD: 03starseeker * r34021 10/brlcad/trunk/src/other/step/src/express/Makefile.am: OK, looks like a flag may be needed for flex |
| 19:51.57 | starseeker | if that works, I can undo the scary hack and slash renaming I did in express |
| 20:07.39 | ``Erik | comcast is awesome! |
| 20:49.04 | PrezKennedyJR | snap out of it man! |
| 21:02.30 | starseeker | brlcad: Ah, nuts. when running distcheck it claims the step directory is already configured |
| 21:04.54 | starseeker | must have gotten too cute with the configure.ac |
| 21:11.19 | brlcad | really should probably start with enigma's more simple configure.ac :) |
| 21:11.37 | brlcad | ours has all sorts of automatic caching and various overrides |
| 21:11.58 | brlcad | some that don't work without previous tests |
| 21:15.39 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-91.sbndin.btas.verizon.net) |
| 21:20.53 | *** join/#brlcad cad14 (n=d41b3c30@bz.bzflag.bz) |
| 21:22.51 | CIA-40 | BRL-CAD: 03brlcad * r34022 10/brlcad/tags/rel-7-14-4/src/other/tk/unix/Makefile.in: temp remove to replace with SHLIB_SUFFIX patched version |
| 21:23.18 | CIA-40 | BRL-CAD: 03brlcad * r34023 10/brlcad/tags/rel-7-14-4/src/other/tk/unix/Makefile.in: apply the SHLIB_SUFFIX fix that lets it make the symlink/copy for m3 folks |
| 21:48.21 | CIA-40 | BRL-CAD: 03brlcad * r34024 10/brlcad/trunk/BUGS: dwayne reports that rtwizard won't display line drawings for objects that are inside other objects, like a vehicle with crew inside. select vehicle as ghost, crew as solid, and crew as line. |
| 22:00.55 | CIA-40 | BRL-CAD: 03brlcad * r34025 10/brlcad/trunk/configure.ac: make a nop mod to hopefully unstick cruisecontrol failures |
| 22:08.58 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 22:15.01 | brlcad | === configuring in src/other/step (/Volumes/wsbh/CI/projects/brlcad-trunk/work/src/other/step) |
| 22:15.05 | brlcad | configure: running /bin/sh ./configure '--prefix=/usr/brlcad' '--enable-symbols' --cache-file=../../../config.cache.darwin9.6.0.pawl.arl.army.mil --srcdir=. |
| 22:15.08 | brlcad | configuring SCL 3.1.0 |
| 22:15.10 | brlcad | No architecture info specified... specify the architecture directory using --with-arch=specify-arch-directory-here |
| 22:15.14 | brlcad | configure: error: ./configure failed for src/other/step |
| 22:16.17 | brlcad | that's what it's presently erroring out on even after that last poke (and it's disabled, so something is apparently wrong) |
| 22:16.30 | brlcad | (with the cruisecontrol config) |
| 22:16.46 | brlcad | probably just need to re-enable it and see if it'll work |
| 22:20.38 | *** join/#brlcad cad99 (n=42ead11b@bz.bzflag.bz) |
| 22:24.52 | *** join/#brlcad cad99 (n=42ead11b@bz.bzflag.bz) |
| 22:37.56 | ``Erik | oh, starseeker, check out "brlman rtarea", i'ts cool |