| 01:10.50 | *** join/#brlcad crazy_imp (~mj@a89-182-194-151.net-htp.de) |
| 01:38.13 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) |
| 03:20.51 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 03:26.31 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 03:57.24 | dloman | getting a failure in libged/list.c |
| 03:57.36 | dloman | ../../../brlcad-trunk/src/libged/list.c: In function ?_ged_do_list?: |
| 03:57.36 | dloman | ../../../brlcad-trunk/src/libged/list.c:146: error: the address of ?avs? will always evaluate as ?true? |
| 03:57.49 | dloman | replace ? with ' |
| 03:58.31 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 04:02.55 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 04:05.30 | brlcad | looking |
| 04:09.25 | brlcad | dloman: try that |
| 04:09.37 | CIA-52 | BRL-CAD: 03brlcad * r44104 10/brlcad/trunk/include/bu.h: attempt to quell warning about stack avs reference address always evaluating as true. |
| 04:10.12 | dloman | kk |
| 04:12.01 | dloman | compile has gotten farther than i did last time, so itink u got it. |
| 04:12.39 | brlcad | lil ridiculous |
| 04:25.14 | CIA-52 | BRL-CAD: 03brlcad * r44105 10/brlcad/trunk/include/bu.h: add parens |
| 04:37.54 | sachinjain | hey brlcad |
| 04:38.28 | sachinjain | I am trying to do one of the "quickies" to understand BRL-CAD |
| 04:40.10 | sachinjain | there is this project "Fix 'analyze' command output formatting" |
| 04:40.33 | sachinjain | I have made some changes in the file "src/libged/analyze.c" |
| 04:40.58 | sachinjain | bt when I am compiling, I am not able to see those changes |
| 04:41.19 | sachinjain | I think...there is problem with compiling part |
| 04:41.42 | sachinjain | can you tell me what are all the files that I need to recompile |
| 04:41.43 | sachinjain | ? |
| 04:43.01 | sachinjain | please help me |
| 04:43.23 | sachinjain | I have already run the "makefile" of "libged" directory |
| 04:47.56 | dloman | from the root of the project, all you should have to do is type 'make' |
| 04:48.13 | dloman | and any changes to source should recompile and link autojmaticaly |
| 04:50.04 | sachinjain | bt that is taking so much time |
| 04:50.33 | dloman | do yo uhave a multi core computer? |
| 04:51.12 | sachinjain | core 2 duo |
| 04:51.19 | dloman | okay then |
| 04:51.33 | dloman | try using the command: 'make -j2' or 'make -j3' |
| 04:51.53 | dloman | that will start 2 or 3 compiling jobs simultaneously. |
| 04:51.54 | dloman | things go a lot faster that way |
| 04:51.59 | sachinjain | ok |
| 04:52.07 | dloman | many things in brlcad rely on others being compiled. |
| 04:52.17 | sachinjain | hmmm.... |
| 04:52.22 | dloman | take the time and do a full compile and things will work better. |
| 04:52.30 | sachinjain | I thought of recompiling the whole thing earlier |
| 04:52.44 | dloman | have you compiled the entire suite yet? |
| 04:52.48 | sachinjain | yup |
| 04:52.52 | dloman | kk |
| 04:52.54 | dloman | so 'make |
| 04:53.06 | dloman | from the root of the checkout dir shouldn't take too long |
| 04:53.45 | sachinjain | gonna ask one question.... |
| 04:53.54 | sachinjain | if I would do this project.... |
| 04:54.12 | sachinjain | then...your requirement of "making a patch" will be fulfilled |
| 04:54.24 | sachinjain | or do I need to do something more? |
| 04:55.19 | dloman | I'll defer that question to brlcad himself, he's the GSoC Admin for us. |
| 04:55.34 | sachinjain | yeah...I am asking to him only |
| 04:55.39 | sachinjain | no offence to you dloman |
| 04:55.40 | sachinjain | :) |
| 04:55.44 | dloman | non taken |
| 05:28.49 | brlcad | poor sachin |
| 05:32.01 | bhinesley | lol |
| 05:36.13 | CIA-52 | BRL-CAD: 03davidloman * r44106 10/rt^3/trunk/ (5 files in 2 dirs): |
| 05:36.13 | CIA-52 | BRL-CAD: Stub in MinimalDatabase and MinimalObject. After some thought, reading and |
| 05:36.13 | CIA-52 | BRL-CAD: notes, a cleaner/simpler way to interface GS and CoreInterface with eachother is |
| 05:36.13 | CIA-52 | BRL-CAD: needed. These two classes will form the bulk of this new approach. |
| 06:18.24 | brlcad | calls it a night |
| 06:24.59 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) |
| 06:24.59 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 06:52.26 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) |
| 07:39.42 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 07:47.24 | sachinjain | hey brlcad |
| 07:51.11 | sachinjain | brlcad : are you there? |
| 08:05.55 | sachinjain | hey...is there a way to decrease the compiling time? |
| 08:06.33 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 08:19.19 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 08:24.48 | CIA-52 | BRL-CAD: 03davidloman * r44107 10/rt^3/trunk/ (4 files in 2 dirs): Match up cstr and dstr signatures with superclass. |
| 08:29.51 | sachinjain | hey...dloman |
| 08:29.58 | sachinjain | that recompiling is taking so much time |
| 08:47.49 | sachinjain | dloman : I am getting some error while recompiling |
| 10:33.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 10:49.34 | dloman | sachinjain: .....and the error is? |
| 11:10.25 | sachinjain | "libtool: link: `../../src/libwdb/libwdb.la' is not a valid libtool archive |
| 11:10.25 | sachinjain | make: *** [libged.la] Error 1" |
| 11:10.30 | sachinjain | this is the error |
| 11:17.51 | sachinjain | dloman : are you there? |
| 11:18.38 | CIA-52 | BRL-CAD: 03davidloman * r44108 10/rt^3/trunk/ (6 files in 4 dirs): Add tests into build. Clean up remnants of old cmake system. Add libge tests. |
| 11:21.47 | dloman | sachinjain: did you do a clean prior to the rebuild? |
| 11:24.43 | sachinjain | no |
| 11:25.10 | dloman | try a 'make clean' |
| 11:25.17 | dloman | then a 'make -j3' |
| 11:25.24 | dloman | actually |
| 11:25.29 | dloman | 'make clean' |
| 11:25.32 | dloman | 'svn up' |
| 11:25.38 | dloman | then 'make -j3' |
| 11:27.56 | sachinjain | why am I not able to see those changes which I had made in a file? |
| 11:28.19 | dloman | what file? |
| 11:28.38 | sachinjain | /src/libged/analyze.c |
| 11:30.22 | sachinjain | do I have to recompile the whole thing.... |
| 11:30.51 | sachinjain | or can I run just the "makefile" in /src/libged directory |
| 11:37.00 | CIA-52 | BRL-CAD: 03davidloman * r44109 10/rt^3/trunk/ (include/MinimalDatabase.h src/libge/MinimalDatabase.cxx): Stub in desired functions for MinimalDatabase |
| 11:38.18 | dloman | all you should have to do is type 'make' form the top level directory for any changes. |
| 11:38.26 | ``Erik | you can do it in just the libged directory, but you'll need to make sure the dependancies for libged are built first... we usually do a big "make" after configure, then just keep running make when we update things. Make won't rebuild files it doesn't have to (my old mac takes about 14 seconds over nfs) |
| 11:43.31 | CIA-52 | BRL-CAD: 03davidloman * r44110 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Fill out MinimalObject fields and associated Getters. |
| 11:46.59 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 11:49.56 | CIA-52 | BRL-CAD: 03davidloman * r44111 10/rt^3/trunk/include/MinimalObject.h: Protect MinimalObject cstr, should not be public. |
| 11:54.56 | CIA-52 | BRL-CAD: 03davidloman * r44112 10/rt^3/trunk/tests/libge/ (CMakeLists.txt GeometryEngineTest.cxx): Add libge to cmake link list. Flesh out GE Test a bit more. Make fn for standard db generation for testing. |
| 11:55.43 | CIA-52 | BRL-CAD: 03davidloman * r44113 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Add a temporary debug fn for printing MinimalObject's internal state. |
| 11:57.30 | CIA-52 | BRL-CAD: 03davidloman * r44114 10/rt^3/trunk/src/libge/MinimalDatabase.cxx: Stub in NULL returns in all functions till implemented. |
| 12:12.24 | brlcad | sachinjain: you can rebuild in just the subdir, but you may have to run make depends first |
| 12:12.38 | brlcad | ``Erik: all sorts of tinyproxy errors |
| 12:22.20 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 12:25.32 | sachinjain | dloman : did you get my messages? |
| 12:26.02 | dloman | nope. /msg here or email or.... ? |
| 12:26.23 | sachinjain | I have made some changes to the file "/src/libged/analyze.c" |
| 12:26.30 | sachinjain | and then rebuild the whole thing |
| 12:26.38 | sachinjain | bt now...when I am running "analyze" command through mged terminal... |
| 12:26.46 | sachinjain | I am not able to see those changes |
| 12:27.04 | starseeker | sachinjain: are you running from the build directory or the install directory? |
| 12:27.08 | starseeker | e.g. did you run make install? |
| 12:27.30 | sachinjain | from the root directory? |
| 12:27.42 | starseeker | how are you running mged? |
| 12:27.46 | starseeker | just typing mged? |
| 12:27.59 | sachinjain | yeah |
| 12:28.14 | starseeker | type "which mged" (no quotes) |
| 12:28.19 | starseeker | what does it report? |
| 12:29.38 | sachinjain | /usr/brlcad/bin/mged |
| 12:30.04 | starseeker | that's why your not seeing changes - when you type mged you're getting the installed version |
| 12:30.12 | sachinjain | so? |
| 12:30.28 | starseeker | you either have to run make install so your altered version is installed, or specifically run the version in the build directory |
| 12:30.29 | sachinjain | what do I do now? |
| 12:31.19 | starseeker | just typing "make" does not put mged in /usr/brlcad/bin/mged |
| 12:31.41 | sachinjain | okie... |
| 12:31.44 | sachinjain | I got you |
| 12:31.46 | sachinjain | let me try now |
| 12:35.55 | sachinjain | starseeker : thanks a lot....it worked |
| 12:55.28 | ``Erik | brlcad: errors? there was a bit of a fit getting it installed and configured right (used to use crit for that... how's the user migration, btw?) |
| 13:01.41 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 13:04.43 | brlcad | d_rossberg: you raise a lot of good points, I'm responding to the them now -- some conceptual, some more short-term work-in-progress mes |
| 13:15.48 | sachinjain | brlcad : I am working on one of the quickies "Fix 'analyze' command output formatting".... |
| 13:16.25 | sachinjain | will that complete your requirement of "making a patch" |
| 13:16.27 | sachinjain | ?? |
| 13:20.04 | brlcad | sachinjain: it's not our requirement, it's you showing us how well you code |
| 13:20.32 | brlcad | when you're satisfied that you've shown your ability, submit it |
| 13:21.05 | sachinjain | okie |
| 13:32.20 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 13:33.26 | d_rossberg | brlcad: i've a lot of ideas for if you plan to support a new API, e.g. a NetDatabase which implements the client side and provides an application the same interface as the other Databases in coreInterface |
| 13:34.09 | d_rossberg | this makes it easy to write client programs for stand-alone and network applications |
| 14:07.31 | dloman | d_rossberg: Didn't mean to cause you alarm. I'm simply trying to find a way to leverage your coreInterface work for what we need the GeometryService to do. Cleanup to follow shortly. |
| 14:34.29 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 14:39.56 | CIA-52 | BRL-CAD: 03davidloman * r44115 10/rt^3/trunk/ (8 files in 4 dirs): |
| 14:39.56 | CIA-52 | BRL-CAD: New approach on getting bu_externals out of coreinterface. last idea broke the |
| 14:39.56 | CIA-52 | BRL-CAD: API and encapsulation. Using private methods this time around in a |
| 14:39.56 | CIA-52 | BRL-CAD: non-intrusive manner. CoreInterface should be returned to its previous state. |
| 14:45.48 | d_rossberg | dloman: i just got an idea on how to solve all your problems with the coreInterface but the page margin is to small to write it down here ;) |
| 14:46.31 | dloman | the approach I just committed involved extending MemoryDatabase with my own class, outside of coreInterface |
| 14:46.52 | d_rossberg | that's why i will write it in a reply to Sean's mail |
| 14:50.09 | d_rossberg | the core of the idea was to get the memory out of the memory database, this would be analogous to getten a file from the FileDatabase |
| 14:50.34 | dloman | righto, i just want the bytes |
| 14:51.27 | d_rossberg | sending this data over a network and reloading it into a MemoryDatabase would give you the database (or a single element in it) back |
| 14:52.36 | dloman | correct. The only stipulation is that we are not enforcing the need to use a MemoryDatabase object on the other end. client could be written in another language. |
| 14:53.29 | d_rossberg | but then you need a specific data format (not black box) |
| 14:54.20 | dloman | correct. We have a protocol defined to transport the data across the network. |
| 14:54.53 | dloman | in the case of transporting the geometry, the protocol equates to a header + geometrydata. |
| 14:55.12 | d_rossberg | it is not about the protocol, it is the data the client must be able to decipher |
| 14:56.01 | dloman | okay then. Is there something incomplete about the data contained in a bu_external? (something i missed?) |
| 14:57.10 | d_rossberg | you need BRL-CAD core's C API to decipher bu_external |
| 14:57.39 | dloman | nods, that makes sense :) |
| 14:58.08 | d_rossberg | i.e. at least a part of the client has to be written in C |
| 14:58.41 | starseeker | d_rossberg: unless you want to use asc2g, I don't think we have anything suitable that isn't bu_external for this kind of thing... |
| 14:59.13 | dloman | I believe there is some java code that can decipher an external, but for the most part yes, use the brlcad libs or implement their own version of them in the language of choice |
| 15:00.32 | d_rossberg | and then you are not far away from reinventing the wheel (now in Java, not C++) |
| 15:00.35 | starseeker | we could update our database format definition document... |
| 15:01.01 | starseeker | then there's a spec people can code deserializers to |
| 15:01.27 | CIA-52 | BRL-CAD: 03davidloman * r44116 10/rt^3/trunk/tests/CMakeLists.txt: Cmake file for the libGE tests needed to include the BRLCAD include dirs |
| 15:02.13 | CIA-52 | BRL-CAD: 03davidloman * r44117 10/rt^3/trunk/tests/libge/CMakeLists.txt: Cmake file for the libGE tests needed to include the BRLCAD include dirs (Missed a file) |
| 15:04.07 | d_rossberg | my approach would be to have a high level interface to the database in C++ to the programmers with the other languages |
| 15:04.40 | starseeker | then they still need one or more of our libraries to decode it though |
| 15:04.49 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 15:05.42 | d_rossberg | for a good Java programmer it isn't easy to understand all the rt_~ and bu_~ but it is easy to wrap coreInterface with some Java classes |
| 15:06.16 | d_rossberg | it is simply straight forfard |
| 15:07.53 | starseeker | that might make it simpler for people to wrap functionality in other languages, but isn't that orthogonal to the question of how to do a language agnostic wire protocol? |
| 15:08.24 | CIA-52 | BRL-CAD: 03davidloman * r44118 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Drop filename as its redundant with filePath. |
| 15:08.29 | d_rossberg | or look at my .net example: it requires some typing to write the wrapper but not much thinking |
| 15:09.36 | d_rossberg | i wouldn't call bu_extern language agnostic, it is quit C |
| 15:10.17 | d_rossberg | on the other side, simply reading the messages isn't very useful |
| 15:10.31 | CIA-52 | BRL-CAD: 03starseeker * r44119 10/geomcore/trunk/tests/svntest/main.c: grr. Try a different approach to svn changes. |
| 15:10.47 | dloman | starseeker: if the network stuff was in the CoreInterface and a 'bunch of other languages' could then use it... in theory at least ;) |
| 15:10.55 | d_rossberg | you had to reimplement all the knowledge about the elements and their behavior |
| 15:11.45 | d_rossberg | and all this to come out with something veri similar to coreInterface |
| 15:12.13 | starseeker | that's true for anyone wanting to do a client that doesn't use our libraries though - are you saying bu_external is worse than some other encoding for transporting that information? |
| 15:14.45 | d_rossberg | the problem is that i have to go now ;} and the yort answer to your question is: yes and no; i'll try to clarify it tomorrow |
| 15:15.10 | dloman | bah, i *hate* cliff hangers |
| 15:15.15 | dloman | ba-doom ching |
| 15:15.27 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) |
| 15:28.19 | CIA-52 | BRL-CAD: 03starseeker * r44120 10/geomcore/trunk/tests/svntest/main.c: Get set up to test application of diffs - early results promising |
| 15:37.39 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) |
| 15:43.22 | CIA-52 | BRL-CAD: 03davidloman * r44121 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Fill out protected constructor properly. This cstr is the one that the MinimalDatabase will use to instantiate MinimalObjects |
| 15:48.42 | CIA-52 | BRL-CAD: 03davidloman * r44122 10/rt^3/trunk/ (include/MinimalDatabase.h src/libge/MinimalDatabase.cxx): |
| 15:48.42 | CIA-52 | BRL-CAD: Add/override Load() and Save() as well as make loading and non loading |
| 15:48.42 | CIA-52 | BRL-CAD: constructors. This must be done in order to preserve filename + path in the |
| 15:48.42 | CIA-52 | BRL-CAD: MinimalDatabase object. filename and path is required to have so that |
| 15:48.42 | CIA-52 | BRL-CAD: MinimalObjects generatedd by this MinimalDatabase have all they required |
| 15:48.42 | CIA-52 | BRL-CAD: information to be transmitted across a network |
| 16:16.23 | CIA-52 | BRL-CAD: 03davidloman * r44123 10/rt^3/trunk/ (TODO src/libge/MinimalDatabase.cxx): Implement getAllTopObjects(). Inefficient, but quick. Time is of the essence. Added TODO item for tracking purposes. |
| 16:42.37 | *** join/#brlcad Stattrav (~Stattrav@117.202.21.195) |
| 16:42.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 17:11.09 | CIA-52 | BRL-CAD: 03davidloman * r44124 10/rt^3/trunk/ (3 files in 3 dirs): Implemented getAllObjects(), getAllTopObjects, getAllObjectsBelow(). Updated test to reflect. |
| 17:13.47 | CIA-52 | BRL-CAD: 03davidloman * r44125 10/rt^3/trunk/tests/CMakeLists.txt: Remove some debug console printing that accidently made it in. |
| 17:33.07 | CIA-52 | BRL-CAD: 03starseeker * r44126 10/geomcore/trunk/tests/svntest/main.c: move things around a bit so we can test whether changes to a .g are actually applied. |
| 17:33.10 | CIA-52 | BRL-CAD: 03davidloman * r44127 10/geomcore/trunk/src/GS/ (CMakeLists.txt GeometryProcessor.cxx GeometryProcessor.h): Drop GeometryProcessor. We have the GeometryEngine for this. |
| 17:37.50 | starseeker | wooot! |
| 17:38.11 | dloman | starseeker > svn ? |
| 17:40.52 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.254) |
| 17:40.58 | starseeker | kinda |
| 17:42.02 | starseeker | I still can't get svn to do it's diff logic, but as long as individual objects aren't crazy huge it doesn't matter too much - I'm just checking to see whether the in-repository binary contents match the incoming binary contents, and if they don't overwrite the old with the new |
| 17:42.43 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) |
| 17:43.08 | starseeker | still need a refinement in that each object diff is currently its own commit (bad if you just changed 3000 objects) but the proof-of-concept is there |
| 17:43.51 | starseeker | if you take ktank, edit a couple objects and combs and save that as ktank2.g (e.g. keep the original ktank.g too, just edit the copy) |
| 17:44.32 | starseeker | you can do ./svnTest ktank.g ktank2.g |
| 17:44.40 | starseeker | it will 1. check in all of ktank.g |
| 17:45.02 | starseeker | 2. iterate through ktank2.g comparing objects found there to those in the repository |
| 17:45.19 | starseeker | 3. apply any modifications |
| 17:45.39 | starseeker | 4. re-assemble the repository into GS_staging/ktank.g |
| 17:46.45 | starseeker | still haven't handled globals yet |
| 17:50.43 | CIA-52 | BRL-CAD: 03davidloman * r44128 10/rt^3/trunk/src/libge/CMakeLists.txt: Change where some libge headers get installed to. brlcad/include instead of brlcad/include/brlcad |
| 17:56.27 | *** join/#brlcad Stattrav (~Stattrav@117.192.145.2) |
| 17:56.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:01.40 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 18:06.22 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) |
| 18:09.23 | CIA-52 | BRL-CAD: 03davidloman * r44129 10/geomcore/trunk/ (8 files in 2 dirs): Add a recursion flag to IDataSource::getObjs() and make the cascading changes. |
| 18:12.16 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.129.35) |
| 18:12.26 | CIA-52 | BRL-CAD: 03davidloman * r44130 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Implement helper method: MinimalObject::getFullRepoPath(). This fn combines the path to the .g file, the .g file name and the object's name. |
| 18:13.56 | kunigami | hi, one of my proposals will be on the project "consolidate image processing". the idea is rectoring the code so all individual tools on src/util will be part of a library? if yes, should them be part of image.c or libicv? |
| 18:14.21 | CIA-52 | BRL-CAD: 03davidloman * r44131 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Consolidate code by using helper function. |
| 18:18.45 | kunigami | *refactoring |
| 18:24.52 | CIA-52 | BRL-CAD: 03davidloman * r44132 10/rt^3/trunk/include/MinimalObject.h: MinimalObject cstr need not be protected any longer. GeometryService classes will need to instantiate MinimalObjects. |
| 18:25.20 | CIA-52 | BRL-CAD: 0346.251.64.228 07http://brlcad.org * r2787 10/wiki/User:391_buy_cialis: |
| 18:45.20 | CIA-52 | BRL-CAD: 03starseeker * r44133 10/geomcore/trunk/tests/svntest/main.c: refactor logic that gets bu_external from svn file into its own function. |
| 18:53.15 | starseeker | huh - https://github.com/tpaviot/oce |
| 19:02.53 | CIA-52 | BRL-CAD: 03davidloman * r44134 10/geomcore/trunk/ (2 files in 2 dirs): Rename chunk<->ext converters to chunk<->obj converters. Updated implementation for new data types. |
| 19:20.17 | CIA-52 | BRL-CAD: 03davidloman * r44135 10/geomcore/trunk/CMake/FindLIBGE.cmake: Forgot to update the libGE search logic. |
| 19:36.32 | CIA-52 | BRL-CAD: 03erikgreenwald * r44136 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: Fix readuint64. Return t instead of type for automagically handled packets. Handle disconnect requests. Fix method mapping. |
| 19:39.58 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 19:54.13 | CIA-52 | BRL-CAD: 03davidloman * r44137 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Worked out a silly allocation bug in GeometryChunkMsg::chunkToObj() |
| 19:56.41 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:46.251.64.228]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 20:07.59 | CIA-52 | BRL-CAD: 03erikgreenwald * r44138 10/geomcore/trunk/src/interfaces/cl/ (gsserver.asd gsserver.lisp): basic server |
| 20:11.04 | CIA-52 | BRL-CAD: 03davidloman * r44139 10/geomcore/trunk/tests/ (GS/CMakeLists.txt libNet/CMakeLists.txt): Fix libs linked. |
| 20:13.35 | CIA-52 | BRL-CAD: 03davidloman * r44140 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Start wiring up FileDataSource to GeometryEngine |
| 20:16.19 | CIA-52 | BRL-CAD: 03davidloman * r44141 10/geomcore/trunk/src/GS/DataManager.cxx: Add a list of strings to use to build a manifest. |
| 20:17.09 | CIA-52 | BRL-CAD: 03davidloman * r44142 10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Update test with all recent changes |
| 20:17.31 | kunigami | #2 question: I suppose libicv stands for image conversion. I saw there's already a rotation implementation there, so, it the objective provide all sort of transformations such as filter, scaling, threshold? |
| 20:18.30 | kunigami | #3 question: will it contain conversion between different types of image (such as bw and pix)? |
| 20:23.08 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2793 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */ Updated progress |
| 20:26.04 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2794 10/wiki/User:Bhinesley: /* Who I am / Experience */ Reworded |
| 20:33.34 | CIA-52 | BRL-CAD: 03starseeker * r44143 10/geomcore/trunk/tests/svntest/main.c: No clue if this is correct, but it compiles so checkpoint |
| 20:37.53 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) |