| 00:49.48 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 03:47.15 | starseeker | hah - SISL modernized their build with CMake |
| 03:47.24 | starseeker | and doxygen |
| 03:47.27 | starseeker | cool |
| 03:49.47 | starseeker | still GPL though |
| 03:51.08 | dli | starseeker, I try to clean up the strict-build problems, seems to be caused by tcl |
| 03:51.34 | starseeker | dli: uh... we shouldn't be trying to build Tcl with strict flags |
| 03:52.18 | dli | starseeker, or, should we clean up the code, and let tcl to handle the 32bit/64bit problem |
| 03:53.09 | starseeker | dli: you can try making patches to Tcl/Tk if you're finding problems and send them back to them... |
| 03:53.21 | starseeker | or try the 8.6 branch of the code |
| 03:54.24 | dli | starseeker, I need tcl-8.6 first then |
| 03:54.58 | dli | starseeker, 8.5.9 is what in gentoo |
| 03:55.04 | starseeker | right |
| 03:55.19 | dli | starseeker, the same 8.5.9 in archlinux |
| 03:55.39 | starseeker | yeah, 8.6 is still in development - has been for quite a while |
| 03:55.49 | starseeker | has to run... |
| 03:56.28 | dli | :) |
| 04:49.49 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) |
| 06:40.48 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) |
| 08:03.17 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) |
| 10:45.20 | *** join/#brlcad piksi (~piksi@pi-xi.net) |
| 14:46.55 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) |
| 16:17.30 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.236) |
| 16:17.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 16:26.36 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) |
| 16:27.32 | dli | from trunk: I got ditsplitc.c:(.text+0x301): undefined reference to `sincos' |
| 16:27.37 | dli | -lm ? |
| 16:36.39 | dli | Makefile:LIBM = |
| 16:36.42 | dli | that's why |
| 16:54.51 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.140.54) |
| 19:07.39 | CIA-14 | BRL-CAD: 03starseeker * r43856 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c): It's a bit confusing. Trying to send the simplest thing possible to the server, and it's getting SOMETHING, but doesn't recognize it. |
| 20:19.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.54) |
| 20:19.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 20:31.57 | CIA-14 | BRL-CAD: 03starseeker * r43857 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Ah, progress - need to pack the message using pkg_pshort |
| 20:32.34 | starseeker | why do I need to supply the port as the first element of pkg_send?? |
| 20:43.33 | dli | starseeker, my first try to get strict build: basically, try to use intptr_t instead of int. but I don't understand tcl/tk enough to be sure I'm not break anything |
| 20:43.37 | dli | starseeker, http://paste.pocoo.org/show/353112/ |
| 20:43.52 | dli | starseeker, it compiles at least |
| 20:44.16 | starseeker | dli: I'm still not clear, why are you trying to build Tcl/Tk strict? |
| 20:44.44 | dli | starseeker, no, just want to enable -Werror generally |
| 20:45.09 | dli | starseeker, the problem seems to be within tkTable part |
| 20:45.28 | starseeker | dli: src/other shouldn't be built with -Werror on |
| 20:45.32 | starseeker | it is expected that it would fail |
| 20:46.30 | dli | starseeker, then, better to set that in autotools/cmake, so, users don't have to be worried |
| 20:46.52 | starseeker | CMake build should work correctly - it does in my testing here |
| 20:47.03 | starseeker | If autotools is feeding -Werror to src/other it's a bug |
| 20:47.50 | starseeker | dli: you can try the CMake branch, if you like: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake brlcad-cmake |
| 20:48.18 | dli | starseeker, just noticed the archlinux maintainer failed to update package version, because of -Werror |
| 20:49.15 | dli | starseeker, I can submit a cmake ebuild to gentoo for brlcad-svn |
| 20:49.23 | starseeker | dli: what are you trying to do - enable -Werror or disable it? |
| 20:49.59 | dli | starseeker, I want users never get the -Werror trouble :( |
| 20:50.06 | starseeker | supplying --disable-strict to the autotools build should do that |
| 20:50.13 | starseeker | ./configure --disable-strict |
| 20:50.43 | dli | starseeker, I knew the solution, because I had to investigate and find out. |
| 20:52.12 | starseeker | that should be documented in the INSTALL file |
| 20:53.00 | dli | starseeker, also, I feel if -Werror should be enabled by correcting the code itself, if possible |
| 20:54.58 | starseeker | for src/other that's a VERY large task |
| 20:55.18 | starseeker | we don't maintain those codebases (with a couple exceptions) so you'd have to get the patches accepted upstream |
| 20:56.06 | dli | starseeker, if so, probably, upstream will address the problem, just have to wait |
| 20:56.15 | starseeker | the BRL-CAD code itself is very clean (thanks mostly to brlcad) but the src/other code is another story |
| 20:56.40 | starseeker | dli: it's pretty rare, in my experience, to have code bases that build well using strict flags |
| 20:57.38 | starseeker | admittedly things are slowly getting better, both in the compiler world and overall open source community, but it takes time - if it works, it's usually not a high priority to clean up all those pesky warnings |
| 20:58.30 | dli | starseeker, the tktable part keeps casting int to a pointer, it may be undefined behavior eventually :( |
| 20:58.49 | starseeker | yeah, tktable code I remember as being a tad noisy |
| 20:59.04 | starseeker | they're actively developed though, IIRC - you might try talking to them direct |
| 20:59.10 | dli | starseeker, as far as the pointer has to go beyond 32bit |
| 20:59.38 | starseeker | yeah, I think this is it: http://tktable.sourceforge.net/ |
| 21:00.05 | starseeker | http://sourceforge.net/projects/tktable/ |
| 21:00.41 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) |
| 21:01.31 | starseeker | if they don't want to take patches that are genuine bug fixes, we can patch our tree - but better to try upstream first |
| 21:02.07 | dli | starseeker, I will try cmake tree first |
| 21:02.34 | starseeker | dli: that doesn't have any different code in src/other |
| 21:02.49 | starseeker | it quiets the warnings, but the code that prompted them is still there |
| 21:03.21 | dli | starseeker, as far as the -Werror trouble is shielded from users, it's good enough for me |
| 21:04.12 | starseeker | feedng disable-strict to configure will also achieve that goal |
| 21:04.25 | starseeker | and not require using an experimental branch ;-) |
| 21:05.44 | dli | starseeker, it works, but if I still don't like to see it in building scripts, even better, user can even enable strict build, but -Werror will be auto off for src/other/ |
| 21:07.53 | starseeker | well, you can give the CMake branch a whirl and see if it does what you want, but remember it's an experimental development branch |
| 21:09.38 | dli | starseeker, I want to work on something of relevant openNURBS, to help me understand the code base, so I can get to the intersection part |
| 21:10.18 | dli | starseeker, any suggestion within an area relevant to oN for me to work on? |
| 21:10.26 | louipc | is disable-strict for the top configure script really needed anymore? |
| 21:10.38 | louipc | I thought all the warnings were cleaned up recently |
| 21:10.50 | dli | louipc, needed:( |
| 21:11.17 | dli | louipc, but it works for 7.18.2 and -svn |
| 21:11.35 | dli | louipc, I mean --disable-strict-build works |
| 21:12.02 | starseeker | louipc: from what dli is saying, it sounds like -Werror is leaking down into src/other somehow |
| 21:12.14 | louipc | hmm ok |
| 21:12.27 | starseeker | dli: do you want to start coding right away? |
| 21:12.42 | dli | starseeker, I thought I already started :( |
| 21:12.54 | starseeker | I mean, writing openNURBS related C code |
| 21:12.58 | louipc | :D |
| 21:13.10 | dli | starseeker, yes |
| 21:14.07 | dli | starseeker, have been reading oN wiki, still need more exercises to understand more |
| 21:15.10 | starseeker | dli: brlcad is the better one to ask - I'm a little biased when it comes to openNURBS. I'm trying to make a standalone NURBS library based on it with the intersection and tessellation functionality added on |
| 21:15.22 | louipc | starseeker++ |
| 21:15.35 | louipc | fork opennurbs? |
| 21:15.52 | starseeker | not really a fork, except insofar as is necessary to cleanly add functionality |
| 21:15.52 | dli | starseeker, forking oN sounds too much :( |
| 21:15.55 | starseeker | more like build on |
| 21:16.06 | louipc | ah |
| 21:16.28 | starseeker | dli: For BRL-CAD, I'd suggest looking into taking a NURBS surface and generating BoTs from it |
| 21:16.45 | starseeker | dli: that would be a relatively straightforward, high impact task |
| 21:17.17 | louipc | dli: the problem I find with opennurbs is that the development actually seems quite closed |
| 21:17.45 | dli | starseeker, I will try that first, then |
| 21:18.17 | starseeker | dli: we can generate surface trees from NURBS already (we need that for raytracing) so they may help you |
| 21:18.26 | starseeker | where's that tessellation paper... |
| 21:18.54 | starseeker | http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.142.3042 |
| 21:20.10 | starseeker | I'd suggest not trying for closed volumes in the first attempt - just get a non-closed BoT representation of a brep primitive by generating triangles from all of its surfaces |
| 21:20.29 | starseeker | if you do that, that's enough for basic shaded display |
| 21:21.00 | dli | starseeker, I will try :) |
| 21:21.03 | starseeker | louipc: the openNURBS model for development is indeed closed - they aren't really running an open source project in the classic sense |
| 21:21.23 | starseeker | they're just making it (much) easier for people to deal with 3dm files |
| 21:23.19 | starseeker | louipc: if you're curious, my preliminary efforts are here: http://libnurbs.git.sourceforge.net/git/gitweb.cgi?p=libnurbs/libnurbs;a=summary |
| 21:24.33 | louipc | oh nice |
| 21:25.10 | starseeker | that's just a "starseeker's experimental project" thing, not related to BRL-CAD |
| 21:25.35 | starseeker | hopefully it'll someday be good enough to replace src/other/openNURBS, but we'll see :-) |
| 21:27.06 | starseeker | louipc: I summarized the overall goals in this post: |
| 21:27.09 | starseeker | http://groups.google.com/group/openmanufacturing/browse_thread/thread/1895cc2eb4d98b6f/a2f3d29238dbcb08#a2f3d29238dbcb08 |
| 22:58.57 | starseeker | grr |
| 22:59.18 | starseeker | anybody know anything about libpkg? how does a client get a message back from a server? |
| 23:00.56 | starseeker | is dubious that the geometry service can successfully talk over pkg... there's some test code that throws stuff from a client to a server, but I see no printout of responses FROM the server and the test works only with its own internal server setup |
| 23:13.37 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) |