| 00:20.23 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 00:30.44 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 00:31.43 | *** join/#brlcad andre|away (n=chatzill@189.71.51.90) |
| 02:21.19 | yukonbob | hello, cadhead |
| 02:21.21 | yukonbob | *s |
| 02:21.32 | pacman87 | hi yukonbob |
| 02:21.41 | yukonbob | hey pacman87, how're tricks? |
| 02:21.51 | pacman87 | tricks? |
| 02:22.19 | yukonbob | *How're things going? |
| 02:23.04 | pacman87 | pretty good, hyp is just about finished, and i'm starting to research for rev/sweep |
| 02:23.16 | pacman87 | you? |
| 02:24.07 | yukonbob | oh... I'm tuckered out. Long hours... no time to geek out w/ BRL-CAD, unfortunately... and I _need_ to so I can get the latest revs building/running nicely... |
| 02:24.20 | yukonbob | but I'm alive, so that's good. |
| 02:24.31 | yukonbob | (some might disagree) |
| 02:30.42 | dtidrow | heh |
| 02:33.58 | *** join/#brlcad Tony__ (n=chatzill@ppp035.cri.centurytel.net) |
| 05:49.40 | *** join/#brlcad clock_ (n=clock@217-162-109-217.dclient.hispeed.ch) |
| 06:58.46 | homovulgaris | wakes up after 9 hours of sleep |
| 06:58.56 | homovulgaris | that was a long nap :P |
| 06:59.20 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 07:03.26 | brlcad | heh |
| 07:15.04 | homovulgaris | hi sean, didnt see rossberg |
| 07:15.21 | brlcad | ~seen rossberg |
| 07:15.24 | ibot | rossberg <n=rossberg@bz.bzflag.bz> was last seen on IRC in channel #brlcad, 448d 16h 32m 32s ago, saying: 'brlcad: sorry, "fmax" is missing on ftp.brlcad.org'. |
| 07:15.29 | brlcad | ~seen drossberg |
| 07:15.30 | ibot | brlcad: i haven't seen 'drossberg' |
| 07:15.33 | brlcad | gr |
| 07:15.40 | homovulgaris | :D |
| 07:15.48 | brlcad | ah |
| 07:15.52 | brlcad | ~seen d_rossberg |
| 07:15.53 | ibot | d_rossberg <n=rossberg@bz.bzflag.bz> was last seen on IRC in channel #brlcad, 1d 19h 51m 39s ago, saying: ' (but not all ;-)'. |
| 07:16.28 | brlcad | homovulgaris: it was more when you get the chance to ask him |
| 07:17.14 | homovulgaris | :) btw, i was planning on using this for the graph representation : http://www.boost.org/doc/libs/1_35_0/libs/graph/doc/adjacency_list.html |
| 07:17.31 | homovulgaris | but i have to check about defining graph traversal system |
| 07:18.55 | homovulgaris | i hope to be able to make a simple constraint solution search system in the next few days: brute force with simple backtracking |
| 07:19.26 | brlcad | hm, you'd think we'd have a graph structure already |
| 07:19.38 | brlcad | given the CSG hierarchy is a directed acylcic graph |
| 07:20.42 | homovulgaris | hmm.. should check that out then .. would the structure definition be in bu ? |
| 07:20.42 | brlcad | you just might be "in luck" though, I'm not seeing or remembering a specific structure that would help other than our red-black trees (and that's a stretch) |
| 07:21.09 | brlcad | bu, bn, or rt |
| 07:21.15 | brlcad | maybe to a quick search |
| 07:21.22 | brlcad | but I'm not remembering |
| 07:21.28 | brlcad | good question for daytona if you see him |
| 07:21.45 | brlcad | though I think the answer is still no |
| 07:21.53 | homovulgaris | k. i'll mail him , update wiki |
| 07:22.15 | brlcad | good idea, copy the devel list |
| 07:22.24 | brlcad | (if you mail him) |
| 07:22.43 | homovulgaris | and the idea of rt_params was to just get the set of parameters.. constraint return would be via pc_constraint_import |
| 07:23.21 | brlcad | I meant implicit constraints that all primitives have |
| 07:23.36 | brlcad | like how a sphere has implicit constraints that a==b==c |
| 07:23.39 | homovulgaris | to set the parameters i was thinking of adding another function.. but that seems unnecessary.. i should integrate it to params itself ? |
| 07:23.43 | brlcad | where a,b,c are the params |
| 07:23.49 | homovulgaris | yeah implicit constraints ofcourse |
| 07:24.06 | brlcad | hm? |
| 07:24.07 | homovulgaris | i mean implicit constraints would be returned by rt_*_params |
| 07:24.13 | brlcad | ah, okay |
| 07:24.21 | brlcad | so some way to delineate between the two |
| 07:25.33 | homovulgaris | two ? u mean set / return ? |
| 07:25.49 | brlcad | yeah, the set being returned |
| 07:26.24 | homovulgaris | hey sean, what is the convention .. right now i have all the method definitions for the classes inside .h files .. should i shift them to .cpps ? |
| 07:26.30 | homovulgaris | with one file for each class ? |
| 07:26.35 | brlcad | i mean you're either making two functions, one for parameters and one for the primitive constraints, or one func that returns both with a means to distinguish which is a parameter and which is a constraint |
| 07:27.43 | homovulgaris | the idea of params() right now is to return both parameters and constraints while distinguishing between both.. |
| 07:27.44 | brlcad | homovulgaris: that's not so much a matter of convention as it is intent -- if you don't intend them to be inlined, they should probably go into a cpp |
| 07:28.04 | brlcad | and the .h then just describes and documents the class/methds |
| 07:28.18 | brlcad | okay, that's what I though |
| 07:28.19 | homovulgaris | k |
| 07:28.31 | brlcad | params() might not be the best name, but I don't have another suggestion :) |
| 07:28.55 | homovulgaris | that can always be changed :) i suck at naming.. even pc sounds crappy ;) |
| 07:29.14 | brlcad | you should try to keep it to one class per file, unless they're a bunch of really small related classes |
| 07:29.43 | brlcad | pc works surprisingly well |
| 07:30.02 | homovulgaris | hmm. right now that .h is around 350 lines without comments.. so i was thinking split it into 2 |
| 07:30.05 | brlcad | and the namespace conflicts on libpc are similarly conveniently very minimal |
| 07:30.22 | brlcad | "that .h"? |
| 07:30.29 | homovulgaris | pc_solver.h |
| 07:31.18 | homovulgaris | will be back after lunch :) |
| 07:31.22 | brlcad | I'd imagine it would necessarily break up |
| 07:31.35 | brlcad | e.g. the generic interval class kinda belongs by itself |
| 07:31.48 | homovulgaris | yeah.. that was my plan |
| 07:31.58 | brlcad | same for domain, etc |
| 07:32.05 | brlcad | you've got a lot of classes in there |
| 07:32.11 | homovulgaris | probably Interval in one.. and Domain and variable together or 3 separate.. |
| 07:32.23 | homovulgaris | some of them have to be removed / upgraded :D |
| 07:32.29 | homovulgaris | i mean the empty ones :) |
| 07:32.42 | brlcad | try to keep it to one unless they really are so tightly coupled to each other that they don't make sense without the other |
| 07:32.59 | brlcad | or if one is effectively just a private class that another class uses |
| 07:33.14 | brlcad | (akin to a static struct) |
| 07:33.31 | homovulgaris | hmm not exactly i think in the near future we will have inheritances from Interval for example |
| 07:34.01 | brlcad | the inherited classes become domain-specific |
| 07:34.03 | homovulgaris | for discrete intervals or something like that or from Variable for different types |
| 07:34.08 | brlcad | that alone is a good reason to separate |
| 07:34.16 | homovulgaris | yeah |
| 07:34.19 | brlcad | if these were broken into sub-libs, Interval is a generic concept |
| 07:34.51 | brlcad | it'd be in some base common library because it's application/domain agnostic |
| 07:34.59 | homovulgaris | I was thinking of adding some more functionality into interval later.. it is a pretty useful concept.. |
| 07:35.01 | brlcad | you only have one lib, so it just gets its own file |
| 07:35.11 | homovulgaris | ok |
| 07:35.39 | homovulgaris | after the minimal implementation of constraint solution search i will work on the stack system for handling constraint representation |
| 07:35.59 | brlcad | if you want to extend something like a BoundingBoxInterval class or something, he'd get his own implementation/header files |
| 07:36.28 | homovulgaris | and when i am stuck with C++ i can add stuff to each of the params/ expand the pc_import etc. |
| 07:36.42 | homovulgaris | ok. |
| 07:37.24 | homovulgaris | and sean, regarding the regression testing on the roots change .. i was confused.. am i supposed to do the testing :) ? |
| 07:37.25 | brlcad | yeah, hooking into a given primitive to use params() and your solver in import or prep would be a really good test of the system |
| 07:38.05 | brlcad | homovulgaris: no, don't worry about that -- focus on libpc |
| 07:38.23 | brlcad | i was going to do the testing |
| 07:38.27 | homovulgaris | i just want to make sure that the whole architecture works for the simple case and then add on features |
| 07:38.36 | homovulgaris | that was about lipbc |
| 07:38.43 | brlcad | you're wouldn't necessarily know exactly what to look for anyways |
| 07:39.01 | brlcad | since it's the portions that relate to ray-trace behaviors that are of concern |
| 07:39.21 | homovulgaris | yeah.. i was thinking about it.. i mean i have 0 knowledge about regression testing.. :) will definitely need to check it out over the year though |
| 07:42.36 | homovulgaris | also presently the Interval class doesnt have sorting depending on optimal nature.. It just sorts according to < operator definition. So if i need to change it in a derived class i can redefine the < operator or write a sort function. |
| 07:43.53 | homovulgaris | which i we will need when we do the solution search selectively over more preferred intervals or to represent preferred solutions |
| 07:44.09 | brlcad | nods |
| 07:44.13 | brlcad | sounds reasonable |
| 07:44.48 | homovulgaris | ok... i'd be back after lunch |
| 07:44.57 | brlcad | happy chowda |
| 07:49.56 | *** join/#brlcad shazbot (i=6152a301@gateway/web/ajax/mibbit.com/x-f3e19621aa163273) |
| 07:50.44 | shazbot | Hi, just heard about the google summer of code.. good luck. Can anyone tell me what the lgpl-ed parts of BRL-cad are? |
| 07:54.34 | brlcad | shazbot: almost the entire source code is lgpl |
| 07:55.11 | brlcad | COPYING has the details |
| 07:55.57 | brlcad | source code is lgpl unless it's not ours to license; build system, documentation, and data files are mostly bsd licensed |
| 08:09.01 | *** join/#brlcad vector_crazy (i=6152a301@gateway/web/ajax/mibbit.com/x-ec5797b3af2023dc) |
| 08:36.59 | homovulgaris | is back :) |
| 08:37.17 | homovulgaris | loves chicken |
| 08:39.46 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 08:54.15 | *** join/#brlcad andrecastelo (n=chatzill@189.71.51.90) |
| 09:22.53 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 09:24.05 | mafm | allo |
| 09:38.08 | CIA-22 | BRL-CAD: 03andrecastelo * r31465 10/brlcad/trunk/src/rt/viewmlt.c: |
| 09:38.08 | CIA-22 | BRL-CAD: Added default lights and scanline initializations in view_2init(). Added |
| 09:38.08 | CIA-22 | BRL-CAD: scanline freeing in view_end(). Added view_cleanup() function. These functions |
| 09:38.08 | CIA-22 | BRL-CAD: are pretty similar to rt's, the big differences will come in rayhit() and in |
| 09:38.08 | CIA-22 | BRL-CAD: view_pixel(). |
| 12:18.22 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-045-101.pools.arcor-ip.net) |
| 12:39.15 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 12:39.40 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) |
| 13:13.19 | *** join/#brlcad thing0 (n=ric@58.171.188.128) |
| 13:17.15 | CIA-22 | BRL-CAD: 03bob1961 * r31466 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am): Add more commands. |
| 13:24.35 | CIA-22 | BRL-CAD: 03bob1961 * r31467 10/brlcad/trunk/src/libged/ (11 files): Initial check-in. |
| 13:27.53 | CIA-22 | BRL-CAD: 03bob1961 * r31468 10/brlcad/trunk/src/libged/ (erase.c erase_all.c illum.c): Initial check-in. |
| 13:34.45 | CIA-22 | BRL-CAD: 03bob1961 * r31469 10/brlcad/trunk/src/libged/globals.c: Added FreeSolid. |
| 14:03.08 | CIA-22 | BRL-CAD: 03bob1961 * r31470 10/brlcad/trunk/src/libged/bigE.c: Converted to use struct ged. |
| 14:04.27 | CIA-22 | BRL-CAD: 03bob1961 * r31471 10/brlcad/trunk/src/libged/ged_private.h: Added more function declarations and a few struct definitions. |
| 14:10.31 | CIA-22 | BRL-CAD: 03bob1961 * r31472 10/brlcad/trunk/src/libged/draw.c: Added ged_draw_guts() and ged_ev(). |
| 14:11.46 | CIA-22 | BRL-CAD: 03bob1961 * r31473 10/brlcad/trunk/src/libged/dg_obj.c: Temporarily disable the E command. |
| 14:14.45 | CIA-22 | BRL-CAD: 03bob1961 * r31474 10/brlcad/trunk/include/ged.h: Added declarations for several functions. |
| 14:15.39 | CIA-22 | BRL-CAD: 03bob1961 * r31475 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added several source files. |
| 14:18.00 | CIA-22 | BRL-CAD: 03brlcad * r31476 10/brlcad/trunk/HACKING: update how to make the ChangeLog |
| 14:19.09 | CIA-22 | BRL-CAD: 03bob1961 * r31477 10/brlcad/trunk/src/libged/ged_private.h: Added include for time.h |
| 14:21.43 | CIA-22 | BRL-CAD: 03brlcad * r31478 10/brlcad/trunk/src/libged/ged_private.h: common before system header consistency |
| 14:24.04 | pacman87 | morning, all |
| 14:24.05 | *** join/#brlcad Elperion (n=Bary@p5B14E854.dip.t-dialin.net) |
| 14:40.34 | *** join/#brlcad madant (n=homovulg@202.63.233.61) |
| 14:43.23 | starseeker | go bob go! |
| 15:13.16 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) |
| 15:38.25 | *** join/#brlcad homovulgaris (n=homovulg@202.63.233.61) |
| 15:43.29 | CIA-22 | BRL-CAD: 03starseeker * r31479 10/brlcad/trunk/doc/docbook/ (5 files in 3 dirs): (log message trimmed) |
| 15:43.30 | CIA-22 | BRL-CAD: Proof of concept - the new mged_commands.xml contains a little of the extensive |
| 15:43.30 | CIA-22 | BRL-CAD: command appendix in Volume II as a valid stand-alone article, and the |
| 15:43.30 | CIA-22 | BRL-CAD: VolumeII.xml here references inside that file to grab the content for inclusion |
| 15:43.31 | CIA-22 | BRL-CAD: in its own appendix using XInclude and xpointer. If this technique scales, it |
| 15:43.33 | CIA-22 | BRL-CAD: will be possible to break down the volumes into individual valid files that can |
| 15:43.35 | CIA-22 | BRL-CAD: be assembled by VolumeII.xml to reproduce (more or less) the original VolumeII |
| 15:53.09 | CIA-22 | BRL-CAD: 03bob1961 * r31480 10/brlcad/trunk/ (include/bu.h src/libbu/argv.c): Added bu_argv_from_path. bu_copy_argv and bu_copyinsert_argv changed to bu_dup_argv and bu_dupinsert_argv, respectively. |
| 15:54.04 | CIA-22 | BRL-CAD: 03bob1961 * r31481 10/brlcad/trunk/src/mged/rtif.c: bu_copyinsert_argv changed to bu_dupinsert_argv |
| 15:54.59 | CIA-22 | BRL-CAD: 03bob1961 * r31482 10/brlcad/trunk/src/tclscripts/helplib.tcl: Changed help for dgo_E. |
| 16:42.58 | CIA-22 | BRL-CAD: 03starseeker * r31483 10/brlcad/trunk/doc/docbook/system/mged/mged_commands.xml: 2 command explanations and examples added, using glossary docbook markup |
| 16:59.14 | CIA-22 | BRL-CAD: 03starseeker * r31484 10/brlcad/trunk/doc/docbook/system/mged/mged_commands.xml: More prep work for glossary, another example |
| 17:06.40 | *** join/#brlcad louipc (n=louipc@76-10-146-181.dsl.teksavvy.com) |
| 17:10.32 | poolio | brlcad: Does it make sense that arb8s are rt_arb and not arb8? |
| 17:34.51 | CIA-22 | BRL-CAD: 03mafm * r31485 10/rt^3/trunk/src/g3d/History.h: Adding header with copyright and so on; and added missing #endif preventing the program from compiling successfully. |
| 17:42.14 | brlcad | poolio: probably not |
| 17:42.55 | brlcad | arb8 used to be g_arb.c -- but for consistency they were all made to match their functab name |
| 17:43.20 | brlcad | for which arb8 actually handles arb8, arb7, arb6, arb5, and arb4 |
| 17:49.33 | poolio | ah oh well. I've decided to work on arb8 instead of arbn :) |
| 17:49.57 | poolio | You've already done most the arb8 work...just need to adjust for equivalent vertices |
| 17:55.15 | brlcad | yeah, the arb8 nmg routine is already in brep form |
| 17:55.28 | brlcad | notes a distinct lack of commits if progress is being made :) |
| 17:56.50 | poolio | brlcad: so calling rt_arb_tess() is probably a good idea here? |
| 17:57.13 | brlcad | up to you :) |
| 17:57.26 | poolio | Also, there are a few places where primites are mentioned as say, "g_arb.c" ... should those be changed to arb8.c? |
| 17:57.26 | brlcad | if you just end up with nearly the same logic, probably |
| 17:57.35 | brlcad | sure |
| 17:58.00 | poolio | Ah k, I will commit when it compiles :) |
| 17:58.31 | brlcad | even better would be to have one "structure" routine for brep/nurb/tess if they're basically the same |
| 17:59.37 | poolio | as in something that went from NMG -> brep? |
| 18:00.47 | poolio | Ah, the one big question I still haven't resolved is how to properly iterate over elements of the NMG. It looks like repeatedly calling the GET routines does it? |
| 18:01.29 | brlcad | something like that -- basically just so there's not two or three copies of logic that do effectively the same thing |
| 18:01.56 | brlcad | mm, I forget how to deal with nmgs |
| 18:02.04 | brlcad | it involves loops |
| 18:02.08 | brlcad | lots of loops |
| 18:02.44 | poolio | ah hmm, I couldn't find anywhere in the code where they repeatedly called GET, but I didn't see any other way to really access them |
| 18:03.31 | brlcad | almost all the converters iterate over nmgs, could check their code out in src/conv |
| 18:03.37 | poolio | ah, thanks |
| 18:04.06 | brlcad | the E and ev commands too |
| 18:04.45 | poolio | Ah hey, I see...it's all fun linked list goodness :) |
| 18:06.00 | brlcad | yep |
| 18:11.31 | mafm | brlcad: so should I commit all the code of my libraries to src/other of my module, right? |
| 18:12.00 | brlcad | mafm: you mean the three dependencies? |
| 18:12.09 | mafm | 4 |
| 18:12.19 | brlcad | oh? who's number 4? |
| 18:12.19 | mafm | ogre, ois, mocha, rbgui |
| 18:12.28 | brlcad | ah, ois isn't part of ogre? |
| 18:12.49 | brlcad | but yeah, to answer your question |
| 18:12.49 | mafm | they decided to remove input support from OGRE about 2 years ago |
| 18:13.10 | brlcad | the first commit should be a clean upstream |
| 18:13.15 | brlcad | i.e. no patches/mods |
| 18:13.19 | brlcad | then commit the mods |
| 18:13.35 | brlcad | so it'll be easier to extract/reapply later if needed as well as to see what changes there are |
| 18:14.08 | mafm | I got a tarball for OIS, but for OGRE has to be some specific revision of the trunk that happened to work a while ago -- today's isn't even compiling :D |
| 18:17.20 | brlcad | awesome |
| 18:17.32 | brlcad | any upstream revision, even from svn/cvs/git/whatever is fine |
| 18:17.55 | brlcad | just annotate their revision in the commit message (e.g. from upstream ogre svn repository, r12345) |
| 18:28.15 | CIA-22 | BRL-CAD: 03mafm * r31486 10/rt^3/trunk/src/other/ (. Makefile): Commiting other/ subdir and the Makefile |
| 18:29.09 | CIA-22 | BRL-CAD: 03brlcad * r31487 10/brlcad/trunk/TODO: |
| 18:29.09 | CIA-22 | BRL-CAD: next release is still a fair bit away given the libged instability, but go ahead |
| 18:29.09 | CIA-22 | BRL-CAD: and annotate some of the most pressing issues for the next release as testing |
| 18:29.09 | CIA-22 | BRL-CAD: mged, verifying fast4-g for ajem, and fixing the bug tom browder just reported |
| 18:29.09 | CIA-22 | BRL-CAD: about the windows installer |
| 18:32.40 | CIA-22 | BRL-CAD: 03brlcad * r31488 10/brlcad/trunk/NEWS: note that dawn added a -c option to the loop command so you can now iterate over characters as well as numbers. makes loop even more similar to the old bsd 'jot' command, but with a better name. |
| 18:36.47 | brlcad | homovulgaris: fyi, your r31454 commit blew away my changes |
| 18:37.12 | mafm | sigh, propsets... |
| 18:37.26 | brlcad | mafm: sup? |
| 18:42.59 | mafm | it's missing like 30 propsets only in ois/ :) |
| 18:46.02 | mafm | hmm, scripts are text/plain, right? xml have to be text/xml or can be text/plain too? |
| 18:46.52 | starseeker | feels mafm's pain |
| 18:47.02 | starseeker | xml should probably be text/xml |
| 18:48.09 | mafm | in my case they don't even name the file .xml |
| 18:48.26 | mafm | it's some random msvc/mac stuff :P |
| 18:55.12 | brlcad | heh |
| 18:55.45 | brlcad | text/plain or test/xml is fine for their stuff |
| 18:55.51 | brlcad | they don't matter as much as our stuff |
| 18:56.41 | mafm | hmmm, and OGRE now doesn't want to build with the old version either, great >:| |
| 18:57.30 | mafm | svn propset svn:eol-style native ois/src/linux/LinuxKeyboard.cpp |
| 18:57.30 | mafm | svn: File 'ois/src/linux/LinuxKeyboard.cpp' has inconsistent newlines |
| 18:57.30 | mafm | svn: Inconsistent line ending style |
| 18:57.56 | alex_joni | run dos2unix on it |
| 18:58.25 | mafm | it seems so, now works :) |
| 19:03.10 | CIA-22 | BRL-CAD: 03mafm * r31489 10/rt^3/trunk/src/other/ois/ (155 files in 29 dirs): Commiting OIS (Object-Oriented Input System) from tarball v1.2.0, no patches needed |
| 19:03.27 | mafm | yay, at last |
| 19:19.48 | mafm | now for OGRE it'll need a few iterations and many minutes of transmissions, I go to watch the football match to the public square |
| 19:19.52 | mafm | :D |
| 19:20.25 | mafm | maybe I won't come back if it's too late, so see you tomorrow then |
| 19:23.53 | *** join/#brlcad clock_ (n=clock@77-56-94-137.dclient.hispeed.ch) |
| 19:25.23 | poolio | brlcad: Is there a way to get a list of all vertices in an NMG model? The only way I can think of doing it is going through all the vertexuses |
| 19:25.58 | *** join/#brlcad Elperion (n=Bary@p5B14E854.dip.t-dialin.net) |
| 19:26.30 | CIA-22 | BRL-CAD: 03bob1961 * r31490 10/brlcad/trunk/src/libged/ (ged.c how.c set_transparency.c tree.c): Initial check-in. |
| 19:28.35 | CIA-22 | BRL-CAD: 03bob1961 * r31491 10/brlcad/trunk/ (include/ged.h src/libged/qray.c): Changed signature of ged_init_qray(). Added declaration of ged_free_qray. |
| 19:29.53 | CIA-22 | BRL-CAD: 03bob1961 * r31492 10/brlcad/trunk/src/libged/nirt.c: Mods related to signature change of ged_qray_data_to_vlist. |
| 19:31.52 | CIA-22 | BRL-CAD: 03brlcad * r31493 10/brlcad/trunk/doc/ (mged.sh mged.tr): renamed to .sh since it's a shell script archive |
| 19:31.58 | CIA-22 | BRL-CAD: 03bob1961 * r31494 10/brlcad/trunk/src/libged/nirt.c: Oops! Forgot to change the usage :-). |
| 19:47.42 | CIA-22 | BRL-CAD: 03bob1961 * r31495 10/brlcad/trunk/src/libged/ged.c: Fix miscellaneous descrepancies. Note - this has still not been tested. |
| 19:51.25 | *** join/#brlcad madant (n=homovulg@202.63.233.61) |
| 19:53.36 | CIA-22 | BRL-CAD: 03bob1961 * r31496 10/brlcad/trunk/src/libged/ (nirt.c qray.c): After actually compiling and noticing the need for ged_wdbp->dbip the ged_qray_data_to_vlist function has been changed back to using a struct ged. |
| 19:55.55 | CIA-22 | BRL-CAD: 03brlcad * r31497 10/brlcad/trunk/doc/Makefile.am: mged.tr was renamed to mged.sh |
| 20:18.38 | brlcad | madant: fyi, your r31454 commit blew away my changes .. (if you missed the earlier note) |
| 20:22.48 | PrezKennedy | why arent you partying?? |
| 20:23.49 | *** join/#brlcad homovulgaris (n=homovulg@202.63.233.61) |
| 20:23.58 | CIA-22 | BRL-CAD: 03bob1961 * r31498 10/brlcad/trunk/ (4 files in 3 dirs): added wdb_init() |
| 20:27.31 | homovulgaris | brlcad: sorry.. u mean the ones in solver_test.c ? |
| 20:28.22 | *** part/#brlcad louipc (n=louipc@76-10-146-181.dsl.teksavvy.com) |
| 20:29.06 | homovulgaris | the code indentation right ? hmm.. wait or was it pc_test.. yikes sorry there was a conflict i guess i resolved it wrongly |
| 20:29.55 | homovulgaris | but i didnt commit that in 31454 .. argh.. am confused .. |
| 21:30.58 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-045-101.pools.arcor-ip.net) |
| 21:49.04 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 22:57.04 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 23:12.26 | *** join/#brlcad madant (n=homovulg@202.63.233.61) |