| 01:30.01 | *** join/#brlcad Elrohir (~kvirc@p5B14BB8B.dip.t-dialin.net) | |
| 01:47.35 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 02:50.55 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:51.06 | CIA-77 | BRL-CAD: 03brlcad * r43478 10/brlcad/trunk/src/libfb/if_remote.c: convert libfb's remote framebuffer from using libbu's xdr routines to using the posix.1 byteorder functions, using hton*/ntoh* |
| 05:10.56 | CIA-77 | BRL-CAD: 03brlcad * r43479 10/brlcad/trunk/src/conv/ (asc/asc2g.c asc/g2asc.c poly-bot.c stl/g-stl.c stl/stl-g.c): convert converters using the libbu xdr routines to using the posix.1 byteorder functions, using hton*/ntoh* |
| 05:20.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:21.00 | CIA-77 | BRL-CAD: 03brlcad * r43480 10/brlcad/trunk/src/rt/viewray.c: call NEAR_EQUAL() instead of rt_fdiff() |
| 05:21.35 | *** join/#brlcad Stattrav_ (~Stattrav@122.172.159.245) | |
| 05:24.06 | CIA-77 | BRL-CAD: 03brlcad * r43481 10/brlcad/trunk/src/librtserver/rtserver.c: more xdr to posix.1 byteorder function conversions, bu_plong to htonl |
| 05:32.04 | CIA-77 | BRL-CAD: 03brlcad * r43482 10/brlcad/trunk/src/ (gtools/g_transfer.c remrt/rtsrv.c): since ext_buf buffers are now uint8_t*'s we need to cast them to char*'s for libpkg (until libpkg is upgraded). |
| 05:49.32 | CIA-77 | BRL-CAD: 03brlcad * r43483 10/brlcad/trunk/src/libged/bot_dump.c: convert from xdr bu_plong() to byteorder htonl() |
| 05:51.29 | CIA-77 | BRL-CAD: 03brlcad * r43484 10/brlcad/trunk/include/raytrace.h: |
| 05:51.29 | CIA-77 | BRL-CAD: now that all usages should be weeded out, formally deprecate rt_fdiff() and |
| 05:51.29 | CIA-77 | BRL-CAD: rt_reldiff() in the header. not 100% equivalent, so use with caution, but |
| 05:51.29 | CIA-77 | BRL-CAD: recommend most conversions change to NEAR_EQUAL(a,b,0.001) and EQUAL(a,b) |
| 05:51.29 | CIA-77 | BRL-CAD: respectively. |
| 05:55.23 | CIA-77 | BRL-CAD: 03brlcad * r43485 10/brlcad/trunk/ (include/bu.h src/librt/db5_io.c): |
| 05:55.24 | CIA-77 | BRL-CAD: formally deprecate the old eXternal Data Representation (XDR) functions via API |
| 05:55.24 | CIA-77 | BRL-CAD: markers. all of the bu_p(long|short|etc) and bu_g(long|short|etc) functions |
| 05:55.24 | CIA-77 | BRL-CAD: have comparable byteorder functions provided standard via posix.1 as hton(l|s) |
| 05:55.24 | CIA-77 | BRL-CAD: and ntoh(l|s). the one exception is support for converting 64-bit long long |
| 05:55.24 | CIA-77 | BRL-CAD: types, so use the recently added configure.ac tests and define htonll() and |
| 05:55.25 | CIA-77 | BRL-CAD: ntohll() respectively as macros supporting big and little endian platforms. |
| 06:04.19 | CIA-77 | BRL-CAD: 03brlcad * r43486 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: convert from xdr to standard byteorder functions casting accordingly. |
| 06:05.26 | CIA-77 | BRL-CAD: 03brlcad * r43487 10/brlcad/trunk/doc/deprecation.txt: minimally impacting change, renaming V2APPROXEQUAL() to V2NEAR_EQUAL() in order to match the other *NEAR_EQUAL() macros. |
| 06:10.49 | CIA-77 | BRL-CAD: 03brlcad * r43488 10/brlcad/trunk/ (include/vmath.h src/proc-db/surfaceintersect.cpp): minimally impacting API change, rename V2APPROXEQUAL to V2NEAR_EQUAL so the api is more self-consistent. |
| 10:12.29 | starseeker | brlcad: you're referring to the C JSON library jansson? |
| 10:16.18 | dloman-a1k | Mernin all |
| 10:16.49 | starseeker | dloman-a1k: morning! |
| 10:20.16 | dloman | ugh, lots to read, heh |
| 10:20.33 | starseeker | hehe |
| 10:20.47 | dloman | so, in my interwebz wandering, i found a QT wrapper for the svn libs :) |
| 10:20.56 | dloman | bookmarked it, didnt have time to look at it. |
| 10:21.18 | dloman | just thought it was funny since erik is mostly done with the ripout |
| 10:22.55 | dloman | starseeker: what version of cmake are you using? |
| 10:23.04 | starseeker | 2.8.3 |
| 10:23.11 | dloman | just got a 'new' used laptop and am re-installing *everything* |
| 10:23.18 | starseeker | I think 2.8.4 is out |
| 10:23.43 | dloman | kk, so 2.8.2 won't cause the world to end then. |
| 10:24.03 | starseeker | *probably* not, but there do tend to be legitimate bug fixes/improvements in each release |
| 10:24.10 | starseeker | particularly with respect to VS2010 |
| 10:24.12 | dloman | right on |
| 10:24.33 | starseeker | If 2.8.2 is the easy install, go for it |
| 10:24.41 | dloman | exactly :) |
| 10:24.48 | dloman | one click == my kinda install |
| 10:24.54 | starseeker | the only thing I know that has issues with 2.8.2 is the Windows visual studio stuff |
| 10:25.16 | starseeker | there may be others though - I'd have to check |
| 10:25.54 | dloman | that fine by me. I dont have any plans on doing anything with VS2xxx |
| 10:26.01 | dloman | in the immediate future that is.. |
| 10:26.09 | dloman | eventually, I'll have to deal with it |
| 10:26.10 | starseeker | If possible, I tend to prefer fixing CMake as opposed to ugly workarounds in our logic, and we do do some fairly funky stuff in a few cases, so let me know if you see any issues |
| 10:26.22 | dloman | kk |
| 10:26.33 | starseeker | CMake is pretty easy to install if it comes to that |
| 10:26.35 | dloman | verizon dsl sucks, so the checkout will take time :/ |
| 10:26.41 | starseeker | nods |
| 10:27.17 | starseeker | dloman: of course, if you're just doing geomcore and not all of BRL-CAD that should be simpler |
| 10:27.42 | dloman | I am soooooo going with xfinity or fios when they hit my area... |
| 10:27.53 | starseeker | mmmm, fiber |
| 10:27.53 | dloman | I think I will get and try cmake on both of those. |
| 10:28.18 | dloman | I have resigned myself to the fact that a bulk of today will be spent downloading/config-ing/t-shooting |
| 10:28.24 | starseeker | heh |
| 10:28.35 | starseeker | has a week of email to read |
| 10:28.49 | dloman | you take last week off as well? |
| 10:28.54 | starseeker | honeymoon |
| 10:29.23 | starseeker | that's why I'm awake right now |
| 10:29.33 | dloman | right on! |
| 10:29.35 | dloman | have fun? |
| 10:29.36 | starseeker | time zones are still messed up |
| 10:29.47 | dloman | oh, you are currently ON your honeymoon? |
| 10:29.56 | starseeker | it was awesome, aside from me being an idiot and losing my ticket for one event |
| 10:30.01 | starseeker | nope, got back last night |
| 10:30.06 | dloman | nice. |
| 10:30.12 | dloman | mind if I ask where u went? |
| 10:30.19 | starseeker | got yelled at by the cats... oh boy |
| 10:30.22 | starseeker | Spain |
| 10:30.32 | dloman | sweet! |
| 10:30.41 | dloman | fun then? |
| 10:30.45 | starseeker | yep |
| 10:30.49 | starseeker | did a lot of tours |
| 10:30.53 | dloman | nice :) |
| 10:31.25 | starseeker | getting put back together - will have to hit the store on the way home tonight |
| 10:32.26 | dloman | watch the weather. somehow a big nasty t-storm snuck up on me/PA/MD without me noticing it on the weather map :) |
| 10:32.30 | starseeker | dloman: was this the binding you found? |
| 10:32.32 | starseeker | http://kdesvn.alwins-world.de/ |
| 10:32.39 | starseeker | ow |
| 10:33.12 | dloman | no, i don';t think that was it. |
| 10:33.38 | dloman | let me dig really quick |
| 10:34.50 | dloman | libsvnqt4 |
| 10:34.54 | dloman | me thinks it was |
| 10:35.06 | dloman | like i said. I saw it, bookmarked it... and that's it. |
| 10:35.08 | starseeker | that sounds like debian packaging of a subset of kdesvn |
| 10:35.11 | dloman | didn't take a look. |
| 10:36.38 | starseeker | we'll probably be talking directly to the C api of the various subversion sub-libraries |
| 10:37.26 | starseeker | I'm pondering whether the best approach would be to actually "port" both the svn fs-fs backend and the checkout logic itself to work inside of a .g instead of files |
| 10:38.16 | starseeker | that's probably one *bleeping* lot of work, particularly the checkout (which I expect makes lots of assumptions about files on a filesystem being the intended checkout output) |
| 10:38.50 | dloman | might be the best, but def not the fastest. |
| 10:39.07 | starseeker | doesn't matter too much right now, since most of the work needed for the break it down to regions and make files approach is still needed for other approaches |
| 10:39.16 | dloman | right on. |
| 10:39.26 | dloman | I plan on diving headlong into that very aspect asap |
| 10:39.48 | starseeker | dloman: I need to get search to behave as proper db functions first |
| 10:40.07 | starseeker | that'll be the best/only(?) way to get a list of assemblies (combinations above regions) |
| 10:40.08 | dloman | first... meaning before what? |
| 10:40.37 | starseeker | once I have that list, and a list of regions, I can keep each into its own file |
| 10:40.39 | dloman | def not the only. a tree/dag walk would be one. |
| 10:40.58 | starseeker | shakes head - we need to write out the assemblies as their own files |
| 10:41.09 | dloman | ya |
| 10:41.20 | starseeker | they aren't below regions (in a proper .g anyway) and won't be kept by a "save the regions" approach |
| 10:41.40 | starseeker | we need to identify the subset of combs that aren't below any regions and save those |
| 10:41.42 | dloman | okay, i think I am missing something then. |
| 10:41.48 | starseeker | hmm? |
| 10:42.18 | dloman | if we do a depth first search, everything in the path leading up to the region *must* be a combination..... yes? |
| 10:42.27 | dloman | s/search/walk/ |
| 10:42.51 | starseeker | oh, you mean take the tops list and work with that as the starting point? |
| 10:42.56 | dloman | ya |
| 10:43.14 | starseeker | ponders... |
| 10:43.19 | dloman | since this is sometihng that will only be run once per file, speed shouldn't be a major concern |
| 10:44.17 | starseeker | yeah, that would probably work, but the search approach is still worthwhile because it can also be used to spot problems |
| 10:44.31 | starseeker | (regions under regions, non-union operations in assemblies) |
| 10:44.43 | dloman | sure. Im thinking timeline wise though, since end of march is our target |
| 10:45.15 | starseeker | dloman: I actually got search working as a C function just before I left, but I didn't do it "right" from an API standpoint |
| 10:45.45 | starseeker | and since we're supposed to be "done" at end of march, I want search's ability to identify near-arbitrary subsets of things |
| 10:45.56 | starseeker | that power may be necessary for robustness |
| 10:46.20 | dloman | oh it will :) |
| 10:46.37 | dloman | but robustness isn't on the list of things needed for the deliverable :P |
| 10:46.41 | dloman | (that was a joke btw) |
| 10:46.45 | starseeker | hehe |
| 10:47.14 | dloman | go go gadget timesheet :/ |
| 10:48.24 | starseeker | dloman: one thing that would help quite a lot is if you and brlcad could summarize the "finalize" approach you two cooked up |
| 10:48.44 | dloman | heh, well, we have to sit down and powwow again. |
| 10:48.45 | starseeker | the functionality needed for that is essentially the TODO lsit |
| 10:48.50 | starseeker | s/lsit/list/ |
| 10:49.16 | dloman | what I have the notes for and what was 'understood' by both parties is not in sync. |
| 10:49.31 | starseeker | nods |
| 10:49.33 | dloman | i think maybe brlcad ``Erik you and i should all sit in |
| 10:49.51 | dloman | perhaps later this week if our schedules align |
| 10:51.05 | starseeker | sure - I'd mainly be listening, because it sounds like most of the major problems were conceptually resolved - what we need now is a "do this to librt to support namespaces, hook this up to svn, do this to combine invidual .g region files into an assembly .g object to satisfy a geomclient request, etc |
| 10:52.20 | starseeker | we also need to decide what has to be in GE (if anything) to achieve basic functionality |
| 10:52.23 | dloman | exactly. task breakdown! |
| 10:52.55 | dloman | heh, I don't know why I ever said yes to the gs project... it was waaaay over my head for a newbie :/ |
| 10:53.05 | starseeker | hehe |
| 10:53.10 | starseeker | trial by fire |
| 10:53.40 | starseeker | probably would have been less tramatizing to do it the way I did - spend a month making tires :-P |
| 10:53.54 | dloman | nice |
| 10:54.08 | dloman | i still want to make the proc-db for making houses. |
| 10:54.14 | dloman | that'd be fuuuun |
| 10:54.53 | dloman | curses at the vpn |
| 10:55.23 | starseeker | puts stuff together and heads out... the rumble you will hear soon will be me being buried under email |
| 11:16.56 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 11:16.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:34.16 | dloman | so... offsite is posponed? |
| 11:55.13 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 11:55.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:12.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:12.46 | CIA-77 | BRL-CAD: 03davidloman * r43489 10/jbrlcad/trunk/: Modify svn:ignore to ignore .settings directory (generated by eclipse) |
| 12:14.59 | CIA-77 | BRL-CAD: 03davidloman * r43490 10/geomcore/trunk/src/interfaces/java/: Modify svn:ignore to ignore .classpath and .project files (generated by eclipse) |
| 12:24.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:25.09 | dloman | Xi is the x lib's input lib, right? |
| 12:29.05 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 12:29.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:42.36 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:54.06 | dloman | Noob question: brlcad's config can't seem to find libXi, but i know its installed and where its at. How do i tell brlcad's config where it is? |
| 13:12.35 | starseeker | --with-x and the X11 location may work |
| 13:13.01 | starseeker | also, if you just installed libXi-dev you may need to clear cache and reconfigure |
| 13:15.50 | dloman | awesome, tanks! |
| 13:19.47 | starseeker | Does anyone remember if gecode (http://www.gecode.org/) was discussed back when the parametric constraint Google Summer of Code project was being worked? |
| 13:21.11 | starseeker | also, http://www.g12.cs.mu.oz.au/minizinc/ |
| 13:23.42 | dloman | is there a standard lex that we should use for brlcad? |
| 13:24.11 | starseeker | uh... not really, but I'd be very surprised if you've got anything except flex |
| 13:25.43 | dloman | thanks, you answered my quetion indirectly =D |
| 13:39.40 | starseeker | confesses he is not up on the constraint stuff, but geocode and friends sound at first glance like they are quite relevant and interesting |
| 13:50.06 | CIA-77 | BRL-CAD: 03starseeker * r43491 10/brlcad/branches/cmake/ (114 files in 60 dirs): MFC r43490 |
| 13:54.32 | dloman | starseeker: the TERMLIB cmake flag.... is it looking for libterm? |
| 13:55.26 | starseeker | dloman: not just libterm - it's supposed to look for a whole bunch of possible suppliers for the subset of termlib we need, and if it's not found enable our local copy |
| 13:55.31 | starseeker | what's the error? |
| 13:56.00 | dloman | config is saying 'Could NOT find TERMLIB' |
| 13:56.10 | starseeker | autotools? |
| 13:56.12 | dloman | just trying to figure out what i should install. |
| 13:56.14 | dloman | cmake |
| 13:56.28 | starseeker | that's surprising |
| 13:56.38 | starseeker | if it's not found it should just fall back on src/other |
| 13:57.02 | dloman | its not erroring out, im just trying to fill out as many libs as possible. |
| 13:57.05 | starseeker | just install the ncurses dev package if you want something on the system |
| 13:57.08 | dloman | this is a brandy new install of ubuntu |
| 14:05.49 | CIA-77 | BRL-CAD: 03starseeker * r43492 10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Clear out txyz-pl from src/tab CMakeLists.txt file |
| 14:30.22 | CIA-77 | BRL-CAD: 03starseeker * r43493 10/brlcad/branches/cmake/misc/enigma/CMakeLists.txt: enigma is not, properly speaking, a BRL-CAD program - don't use BRLCAD_ADDEXEC macro (we don't want to hit it with the strict flags, same as src/other |
| 14:33.38 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 14:33.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:37.40 | CIA-77 | BRL-CAD: 03starseeker * r43494 10/brlcad/branches/cmake/src/tclscripts/ (archer/CMakeLists.txt lib/CMakeLists.txt): cursor.tcl moved |
| 14:48.45 | starseeker | hmm... http://www.cs.washington.edu/research/constraints/cassowary/ |
| 14:49.51 | starseeker | needs this http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/brandenburg/projekte/gtl/GTL-1.2.4-lgpl.tar.gz |
| 14:51.27 | starseeker | geocode sounds more modern and supported, if the domains overlap properly |
| 15:53.04 | CIA-77 | BRL-CAD: 03starseeker * r43495 10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Problem - the lex generated output is triggering warnings. Gonna have to go with -Wno-error until we get a flex/byacc solution in place we can rely on/tweak to generate error free code. |
| 15:56.24 | brlcad | starseeker: what were the warnings? during my cleanup a couple weeks ago, several of the lex-generated output warnings were controlled by settings in the lex/yacc files |
| 15:56.32 | brlcad | i.e., they were easily quellable |
| 15:56.40 | brlcad | welcome back too :) |
| 15:58.44 | starseeker | brlcad: thanks :-) |
| 15:58.46 | starseeker | script.c:34:5: warning: "__STDC_VERSION__" is not defined |
| 15:59.01 | starseeker | script.c:1020: warning: label âfind_ruleâ defined but not used |
| 15:59.14 | starseeker | script.c:1439: warning: comparison between signed and unsigned |
| 15:59.23 | starseeker | script.c:2138: warning: âyy_flex_strlenâ defined but not used |
| 16:01.21 | CIA-77 | BRL-CAD: 03starseeker * r43496 10/brlcad/trunk/src/ (canon/canonize.c librtserver/rtserver.c rt/view.c sig/fhor.c): Various quellage |
| 16:04.13 | CIA-77 | BRL-CAD: 03d_rossberg * r43497 10/brlcad/trunk/src/ (conv/CMakeLists.txt conv/stl/stl-g.c librt/CMakeLists.txt): ntohl(): missing includes and libraries for the MSVC CMake build (needs WinSock 2) |
| 16:04.21 | CIA-77 | BRL-CAD: 03starseeker * r43498 10/brlcad/branches/cmake/ (32 files in 31 dirs): There we go - strict compile flags are now the default throughout the BRL-CAD src directories, with the exception of src/other |
| 16:09.07 | brlcad | thanks, interesting diff set of warnings |
| 16:10.47 | starseeker | brlcad: do you recall if gecode was ever mentioned in the parametric constraint lib discussions? |
| 16:11.43 | dloman | starseeker: the cmake command to find x was: cmake --with-x <pathToSrc> ?? |
| 16:11.44 | brlcad | nah, I don't really recall |
| 16:11.49 | brlcad | starseeker: what's the gain? |
| 16:12.36 | starseeker | i'm thinking it might actually have a working constraint solver on top of which we would define our constraints |
| 16:12.49 | brlcad | isn't keen on bio.h having networking, that expands the scope a bit.. |
| 16:12.53 | starseeker | (i.e. it sounds kind of like what the gsoc project was trying to develop) |
| 16:13.04 | dloman | tryin to fix a linker error: cannot find -lXss (-lXft and -lXrender) |
| 16:13.42 | starseeker | um. Ubuntu might break those out into separate packages... |
| 16:14.03 | dloman | did a find and I have them... so how do I supply paths to cmake? |
| 16:14.08 | brlcad | starseeker: it's definitely related -- there are dozens of constraint solver libraries out there |
| 16:14.21 | brlcad | each with their merits and deficiencies.. |
| 16:15.15 | starseeker | brlcad: that's what I was wondering - presumably there must have been a review of those before we went for writing our own... |
| 16:16.04 | brlcad | possibly, but that would have been pre-submission |
| 16:16.05 | starseeker | dloman: it's rather disturbing they aren't being found |
| 16:16.16 | starseeker | nuts |
| 16:16.51 | starseeker | dloman: can you post the results of make VERBOSE=1 that are related to the failure? |
| 16:16.57 | dloman | starseeker: if it helps, all the libs are in /usr/lib and /usr/lib32 |
| 16:17.00 | dloman | kk, will do |
| 16:17.39 | brlcad | starseeker: it's kinda the same situation as writing a solver for nurbs surface evaluation -- "surely there was a review of existing root solvers before we went for writing our own" |
| 16:17.50 | brlcad | the answer is "yes and no" |
| 16:18.14 | brlcad | the solver is fairly tied to the data structures, same with constraints |
| 16:19.48 | starseeker | ah |
| 16:20.02 | brlcad | fwiw, much of libpc isn't the actual constraint solving but the data structures for representing a constraint, the bridge for librt to use |
| 16:20.14 | brlcad | so you could conceivably hook in any constraint solver under the hood |
| 16:20.25 | starseeker | nods - that might be interesting to look at |
| 16:20.47 | brlcad | as would determining where the current implementation is actually at |
| 16:21.05 | starseeker | was doing some reading of SICP, and their description of what a constraint system does/is good for kind of set off a light bulb |
| 16:21.06 | brlcad | for all we know, it could be done and working perfectly for our needs |
| 16:21.48 | starseeker | not that I have time to fool with it now of course, but it sounds quite interesting |
| 16:22.15 | brlcad | when I reviewed his work back during gsoc, it actually seemed to be working very well |
| 16:22.48 | brlcad | the problems he was working on were problems we were not yet faced with, solving multiple constraints simultaneously |
| 16:23.06 | brlcad | there are sample test driver programs in the tree that show it working |
| 16:23.45 | starseeker | nods. I'm just wondering how hard it would be to shake out bugs and demonstrate robustness there vs. using something like gecode under the hood for the actual solving part... |
| 16:23.57 | starseeker | but the only way to know that is to dig into it |
| 16:24.34 | brlcad | you won't know whether gecode is better or worse without writing a test driver that evaluates the current state of affairs regardless |
| 16:24.42 | starseeker | right |
| 16:25.20 | brlcad | given there are already some simple test drivers, it would be an intersting comparison |
| 16:25.30 | brlcad | useful too, it's a current year task |
| 16:25.50 | starseeker | nods - maybe I can dive in after the geometry service gets beaten into submission |
| 16:25.50 | brlcad | someone will have to investigate and evaluate before the year's up |
| 16:26.03 | brlcad | has the same deadline as the GS iirc :) |
| 16:26.12 | starseeker | O.o |
| 16:26.12 | brlcad | much smaller task, though |
| 16:26.34 | starseeker | crawls under his desk and hides... |
| 16:26.46 | starseeker | and then realizes that's a bad place to code from |
| 16:26.51 | brlcad | frack.. end of month |
| 16:26.54 | brlcad | time to release! |
| 16:27.01 | brlcad | damn short month |
| 16:27.12 | starseeker | winces |
| 16:28.02 | brlcad | gsoc org submissions opens up today too |
| 16:28.23 | brlcad | if we're going to participate, someone is going to have to get started on writing up a new task list on the wiki |
| 16:28.24 | starseeker | do you want me to do the librt search port in CMake to avoid messing with trunk? |
| 16:28.35 | brlcad | heck no :) |
| 16:28.59 | brlcad | search port? |
| 16:29.07 | brlcad | sounds rather un-cmakeing |
| 16:29.20 | starseeker | sure, but it's a nasty thing to do during a release cycle |
| 16:29.29 | starseeker | whoops, bbl |
| 16:29.55 | brlcad | just have to be more careful to not break build or functionality during commits, just talking a day or two to test and tag |
| 16:37.13 | CIA-77 | BRL-CAD: 03brlcad * r43499 10/brlcad/trunk/TODO: |
| 16:37.13 | CIA-77 | BRL-CAD: release tasks were not completed by the end of the month, so push to the next |
| 16:37.13 | CIA-77 | BRL-CAD: iteration. only remaining task that comes to mind is removing the network dep |
| 16:37.13 | CIA-77 | BRL-CAD: from bio.h (need a separate header since it's just for standard i/o) |
| 17:04.38 | CIA-77 | BRL-CAD: 03brlcad * r43500 10/brlcad/trunk/src/libged/CMakeLists.txt: add fb2pix.c and pix2fb.c |
| 17:18.41 | CIA-77 | BRL-CAD: 03jordisayol * r43501 10/brlcad/trunk/misc/debian/changelog: update debian changelog |
| 18:11.41 | CIA-77 | BRL-CAD: 03brlcad * r43502 10/brlcad/trunk/include/ (Makefile.am bin.h): |
| 18:11.41 | CIA-77 | BRL-CAD: add an initial corrollary header file similar to bio.h but for internet |
| 18:11.41 | CIA-77 | BRL-CAD: networking instead of input/output. it's similarly a 'private' self-contained |
| 18:11.41 | CIA-77 | BRL-CAD: header (so no HAVE_* defines), but should help consolidate the header |
| 18:11.41 | CIA-77 | BRL-CAD: preprocessor logic into one place. this header is effectively treated as a |
| 18:11.42 | CIA-77 | BRL-CAD: system header coming before inclusions of brl-cad public/private headers. |
| 18:14.23 | CIA-77 | BRL-CAD: 03brlcad * r43503 10/brlcad/trunk/src/librt/Makefile.am: missing the tieprivate.h header |
| 18:16.50 | CIA-77 | BRL-CAD: 03brlcad * r43504 10/brlcad/trunk/src/librtserver/rtserver.c: include headers for htonl |
| 18:20.17 | CIA-77 | BRL-CAD: 03brlcad * r43505 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: include bin.h instead of bio.h for htonl and friends |
| 18:22.32 | CIA-77 | BRL-CAD: 03brlcad * r43506 10/brlcad/trunk/include/bio.h: |
| 18:22.32 | CIA-77 | BRL-CAD: remove inclusion of arpa/inet.h from bio.h since it's not desirable to bundle |
| 18:22.32 | CIA-77 | BRL-CAD: networking routines in with the input/output routines. this is in part due to |
| 18:22.32 | CIA-77 | BRL-CAD: the implied dependency on the windows socket library on the windows platform, |
| 18:22.32 | CIA-77 | BRL-CAD: which isn't necessarily true for inclusions only needing standard i/o. the new |
| 18:22.33 | CIA-77 | BRL-CAD: bin.h internet networking header now covers networking. |
| 18:28.16 | CIA-77 | BRL-CAD: 03brlcad * r43507 10/brlcad/trunk/src/librt/db5_io.c: need bin.h instead of bio.h |
| 18:29.24 | CIA-77 | BRL-CAD: 03brlcad * r43508 10/brlcad/trunk/src/librt/db_scan.c: ditto, bio.h -> bin.h for networking |
| 18:34.20 | CIA-77 | BRL-CAD: 03brlcad * r43509 10/brlcad/trunk/src/libged/bot_dump.c: need networking and i/o functions here, so also include bin.h |
| 18:34.30 | CIA-77 | BRL-CAD: 03brlcad * r43510 10/brlcad/trunk/src/librt/ (11 files in 11 dirs): promulgation continues, switch from bio.h to bin.h where byteorder functions are being used. |
| 18:34.34 | ``Erik | the arpa inet header in bio.h was for htonl/ntohl |
| 18:35.00 | ``Erik | *readreadread* |
| 18:36.11 | ``Erik | hm, *update;compile* O.o |
| 18:36.42 | CIA-77 | BRL-CAD: 03brlcad * r43511 10/brlcad/trunk/src/conv/ (asc/asc2g.c asc/g2asc.c poly-bot.c stl/g-stl.c): and maybe the last batch of bin.h inclusions needed. |
| 18:36.51 | brlcad | I know - but that made the header pull in more than just i/o |
| 18:37.06 | brlcad | the wrapper header was needed, just made a new file |
| 18:37.19 | brlcad | one for just networking |
| 18:37.41 | brlcad | so anything that includes that file is implicitly requiring ws2_32.lib |
| 18:38.56 | brlcad | sucks that byteorder is in winsock on windows .. the bu xdr funcs provided a nice encapsulation from that perspective, but still probably better unwrapped |
| 18:40.18 | CIA-77 | BRL-CAD: 03starseeker * r43512 10/brlcad/branches/cmake/CMakeLists.txt: Try InstallRequiredSystemLibraries on Windows MSVC |
| 18:41.14 | CIA-77 | BRL-CAD: 03brlcad * r43513 10/brlcad/trunk/src/conv/stl/stl-g.c: nope, missed one |
| 18:46.58 | *** join/#brlcad Ralith (~ralith@d142-058-095-076.wireless.sfu.ca) | |
| 19:00.17 | CIA-77 | BRL-CAD: 03starseeker * r43514 10/brlcad/branches/cmake/ (36 files in 24 dirs): MFC r43513, update CMakeLists.txt files to include winsock in more places (untested) |
| 19:04.13 | starseeker | ah, homovulgaris mentioned gecode back in 2008 |
| 19:16.03 | CIA-77 | BRL-CAD: 03erikgreenwald * r43515 10/brlcad/trunk/include/bin.h: need sys/types.h for netinet/tcp.h |
| 19:21.41 | ``Erik | probably should be wrapping some #ifdef HAVE_SOME_H in there *shrug* |
| 19:24.30 | CIA-77 | BRL-CAD: 03erikgreenwald * r43516 10/brlcad/trunk/include/bin.h: #define <winsock2.h> doesn't quite work |
| 19:25.21 | brlcad | heh |
| 19:26.14 | brlcad | ``Erik: bio.h and bin.h intentionally do not have HAVE_* defines since they're not supposed to be tied to configure -- more like system header replacements |
| 19:27.10 | brlcad | they could be converted / coupled with configure feature testing, but it would change a few things |
| 19:41.18 | CIA-77 | BRL-CAD: 03davidloman * r43517 10/brlcad/branches/cmake/: Modify svn:ignore to ignore .classpath and .project files (generated by eclipse) |
| 19:59.10 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:59.10 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 20:29.05 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 20:53.07 | CIA-77 | BRL-CAD: 03brlcad * r43518 10/brlcad/trunk/src/mged/attach.c: include bin.h instead of including winsock2.h directly |
| 20:55.25 | CIA-77 | BRL-CAD: 03brlcad * r43519 10/brlcad/trunk/configure.ac: |
| 20:55.25 | CIA-77 | BRL-CAD: there's no reason to leave out the gnu extensions other than to try and avoid |
| 20:55.25 | CIA-77 | BRL-CAD: non-standard functions. in practice, however, c99 compliance means we also |
| 20:55.25 | CIA-77 | BRL-CAD: don't get the posix functions, which is somewhat problematic. change the |
| 20:55.25 | CIA-77 | BRL-CAD: compliance from std99 to gnu99. |
| 21:13.11 | CIA-77 | BRL-CAD: 03brlcad * r43520 10/brlcad/trunk/src/util/dunncomm.c: wrong comment |
| 21:21.30 | CIA-77 | BRL-CAD: 03brlcad * r43521 10/brlcad/trunk/src/libfb/if_ogl.c: no longer need the __BSD_VISIBLE/__USE_XOPEN/__USE_BSD hacking to get the extension decls with configure using gnu99. |
| 21:35.36 | CIA-77 | BRL-CAD: 03brlcad * r43522 10/brlcad/trunk/src/tab/script.l: overcome flex stupidities, define undefined to false in order to appease preprocessor logic. |
| 21:48.56 | CIA-77 | BRL-CAD: 03brlcad * r43523 10/brlcad/trunk/src/ (16 files in 16 dirs): |
| 21:48.56 | CIA-77 | BRL-CAD: enable the remainder of strict flags now that the build is verified across mac |
| 21:48.56 | CIA-77 | BRL-CAD: and linux. now all of brl-cad's source code builds strict-clean for improved |
| 21:48.56 | CIA-77 | BRL-CAD: security, maintainability, conformance compliance, stability, reliability, and |
| 21:48.56 | CIA-77 | BRL-CAD: more. |
| 21:54.40 | CIA-77 | BRL-CAD: 03brlcad * r43524 10/brlcad/trunk/src/remrt/ihost.c: replace the net headers with bin.h |
| 22:31.23 | *** join/#brlcad guest_tttt (~rm@123.136.11.66) | |
| 22:31.45 | guest_tttt | ..... |
| 22:33.48 | *** part/#brlcad guest_tttt (~rm@123.136.11.66) | |
| 22:37.11 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:02.16 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 23:02.17 | CIA-77 | BRL-CAD: 03brlcad * r43525 10/brlcad/trunk/src/conv/Makefile.am: missing the shapefil.h header |
| 23:09.15 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 23:13.59 | CIA-77 | BRL-CAD: 03starseeker * r43526 10/brlcad/trunk/include/raytrace.h: search will need regex.h once it is moved to librt |
| 23:16.52 | CIA-77 | BRL-CAD: 03starseeker * r43527 10/brlcad/trunk/src/librt/ (Makefile.am search.c search.h): Add work done so far on search move to librt - not being added to the compile until after the release. |
| 23:28.54 | CIA-77 | BRL-CAD: 03starseeker * r43528 10/geomcore/trunk/tests/svntest/CMakeLists.txt: fix install target for svnTest |
| 23:38.27 | CIA-77 | BRL-CAD: 03starseeker * r43529 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/CMakeLists.txt): Move the TERMLIB option to src/other - we need this set in advance of the third party logic. |