| 00:08.26 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 00:26.51 | yukonbob | hello, cadheads |
| 00:34.02 | brlcad | howdy yukonbob |
| 00:34.49 | yukonbob | how'd your day turn out? |
| 00:40.12 | starseeker | goes into convulsions as sourceforge svn goes offline... |
| 00:43.43 | starseeker | decides to do some Gentoo upgrading... |
| 00:45.06 | brlcad | yukonbob: alright, sort of a day of exhausted relaxation before the storm |
| 00:50.33 | starseeker | proposes a study of brlcad to learn how to make a human body function without sleep |
| 01:03.14 | *** join/#brlcad iday (n=iday@c-68-55-215-195.hsd1.md.comcast.net) | |
| 01:04.42 | brlcad | practice makes perfect! |
| 01:13.08 | starseeker | sees slashdot article on virtualbox and checks it out |
| 01:27.50 | stustev | good evening - is anyone up for another question? Here goes. Is there a way to run a script and have the script history in the command window? |
| 01:29.55 | brlcad | howdy stustev .. hmm |
| 01:30.09 | stustev | good evening |
| 01:30.10 | brlcad | I think the short answer is no |
| 01:30.18 | stustev | that's too short |
| 01:31.33 | stustev | that would be very nice for me. Write a script, load the script without running it and step through it to make it work |
| 01:32.32 | brlcad | I can see the utility in that, but it'd probably require a new command or an option to an existing command |
| 01:33.04 | brlcad | actually, could probably write a little tcl script that does exactly that for you |
| 01:33.31 | stustev | just give me an idea how to do it and I will try to do it |
| 01:33.42 | brlcad | does fopen on specified file, loops over lines in the file, runs each line interactively asking if it's okay or to skip |
| 01:34.15 | brlcad | proc hello {args} { |
| 01:34.23 | brlcad | <PROTECTED> |
| 01:34.24 | brlcad | } |
| 01:34.30 | brlcad | hello |
| 01:34.52 | stustev | I am here - just talking to my daughter |
| 01:35.02 | brlcad | from there, just find a tutorial on-line for reading the lines from a file |
| 01:35.21 | brlcad | (using Tcl) |
| 01:35.35 | brlcad | should be all of about 20 lines of code probably |
| 01:35.57 | stustev | I will look at it - thanks |
| 01:36.18 | brlcad | if you get stuck, let me know |
| 01:42.11 | stustev | I am already stuck - but I want to try anyway - It will take more time to help me do it than if you did it yourself but then I would learn anything. :) |
| 01:43.16 | stustev | I have been scripting models today. It is a LOT like APT programming. I am an APT programmer. |
| 01:44.42 | ``Erik | my condolances |
| 01:44.56 | stustev | :) |
| 01:47.15 | stustev | here is not a way to read the whole script into the command window and then be able to move forward and back in the file using the keyboard? Just like what you would have if you typed the script into the command window? |
| 01:47.21 | stustev | there |
| 01:53.19 | stustev | Can I put a command in the script to over write the existing database with the created database when the script runs? Even better would be a question when I load the script "Do you want to erase the existing database: Y/N". |
| 01:57.35 | brlcad | almost made it off post, only to turn right back around |
| 01:57.51 | stustev | welcome back |
| 02:01.20 | *** join/#brlcad ibot_ (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) | |
| 02:01.20 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || BRL-CAD is participating in the 2008 Google Summer of Code! || Release 7.12.4 is posted (source-only release) | |
| 02:01.23 | brlcad | a litl bit of tcl scripting |
| 02:02.32 | stustev | The command to load the file? Is it possible to load the entire file instead of one line at a time. Your suggestion seemed to me to load one line at a time. |
| 02:05.34 | brlcad | it's a full language, you can make it do whatever you want |
| 02:05.46 | brlcad | read the whole file if you like, ask line by line |
| 02:06.08 | stustev | Maybe I am thinking the command history is a file but it isn't. Is it the command history like the 'history' command in a terminal window. |
| 02:07.15 | brlcad | there are various command histories in mged -- the one you see when you up/down arrow are always actions that have *happened* .. so if you want a command to show up there, it has to have run |
| 02:07.31 | brlcad | but that doesn't prevent you from stepping through a transcript for the user |
| 02:07.47 | stustev | that is what I am just understanding |
| 02:10.48 | stustev | In APT we have what we call a source file. It is all the APT commands to create geometry if we need to and then move the cutter around the geometry. We load the whole file and then run through the file how we need to (sometimes - one line at a time). It doesn't sound as if brlcad is structured the same. |
| 02:11.43 | brlcad | sounds more like an interactive debugger |
| 02:12.11 | brlcad | different tool, different purposes |
| 02:12.11 | stustev | exactly - that is how it functions |
| 02:12.18 | brlcad | your point? :) |
| 02:13.11 | stustev | It seems more intuitive and functional to me. That is probably because that is what I am used to. |
| 02:15.36 | brlcad | that's a pretty grandiose statement to make on one simple interaction data point (regardless of it being true or false) |
| 02:16.07 | brlcad | there are plenty of ways mged can be improved, working on usability is one of our top (long-term) priorities |
| 02:16.38 | jonored | stustev: It doesn't seem like it's even impractical to do things that way in brlcad... I've mostly been editing files and running them. Haven't written up a line-by-line execute command, but that should only be a few lines to write... |
| 02:17.03 | stustev | my process now - write the script, run the script, look at the error messages to decipher why it didn't work, edit the script, erase the database, repeat until I get no errors, check the model to see if it looks like what I expected, edit the script , erase the database, repeat until the model looks like what I want. :) |
| 02:17.40 | stustev | not too bad just different than what I am used to |
| 02:18.11 | brlcad | stustev: i.e., you'd like an interactive script debugger |
| 02:18.44 | jonored | I find myself wondering if this is actually a procedural-stuff-stored-in-database thing... |
| 02:18.49 | brlcad | it's not ground-shaking insightful, it's just not a feature we presently provide even if it would just take a few lines of code to implement |
| 02:19.00 | stustev | I had never thought of the APT process as debugging before but that is exactly what it is |
| 02:19.02 | brlcad | in fact you're the first person to (ever) suggest such a feature |
| 02:19.27 | brlcad | (for mged) |
| 02:20.03 | brlcad | it really would amount to just one routine, probably less than 50 lines tops including interactivity unless you slap a gui in there too |
| 02:28.44 | Ralith | what would be really neat would be a way to step forward and back (via a not-yet-present undo system) through a script to see what each line does (good for learning *and* debugging!) in an integrated editor, next to a nice pretty shaded view of the model |
| 02:28.45 | yukonbob | stustev: [source] is your friend... and if you're using [X]Emacs as your editor, inferior-tcl-mode is also your friend. |
| 02:28.52 | Ralith | of course, this has nothing to do with mged |
| 02:29.14 | Ralith | other than using mged commands |
| 02:30.01 | stustev | Ralith: now you are talking |
| 02:30.18 | Ralith | I don't think it would be very hard to do |
| 02:30.20 | jonored | Ralith: Defining a variant on 'in' that kills the solid first seems like it'd get closer to that... |
| 02:30.22 | Ralith | even as a completely unique system |
| 02:30.33 | Ralith | jonored: I don't follow |
| 02:30.53 | jonored | Unless I'm mistaken, that makes those commands repeat by themselves... |
| 02:31.33 | Ralith | still lost |
| 02:31.43 | jonored | or I might just be being a noob... checking. |
| 02:33.25 | jonored | ...no, it doesn't seem like it. Make it so that if you go up in the history/external program and rerun the command it essentially updates the object. Or is it not based on name in the db? |
| 02:34.00 | Ralith | I really have no idea what you're suggesing |
| 02:34.11 | Ralith | other than that it sounds like some kind of undo system to implement what I described |
| 02:35.21 | stustev | jonored: yes that would be the ticket - move up to rerun the command - the model is updated to the just run command - using the same entity name as before |
| 02:35.37 | Ralith | that's exactly what I said :P |
| 02:35.44 | jonored | I've been finding myself (as I play with scripting) putting a "kill" statement immediately before every statement that creates something. Although that doesn't work for combinations easily, nevermind - they need to not get killed sometimes and killed other times. |
| 02:36.32 | brlcad | jonored: there's the more dangerous killtree for combinations |
| 02:36.35 | stustev | Ralith: not exactly - the undo system I have seen will erase the entities when the undo command is issued |
| 02:36.46 | Ralith | jonored: there are all sorts of things that can't be undone with a kill, though |
| 02:36.56 | Ralith | stustev: what |
| 02:37.03 | Ralith | that sounds more like a delete button than an undo system |
| 02:37.30 | stustev | isn't undo - the same as delete? |
| 02:37.59 | Ralith | uh no? |
| 02:38.03 | Ralith | not remotely |
| 02:38.09 | Ralith | where did you get that idea |
| 02:38.10 | jonored | It's close. It's more like a "Rerun and replace" button for this... or "edit definition". |
| 02:38.20 | Ralith | what if you want to undo moving something |
| 02:38.24 | Ralith | or undo changing its color |
| 02:38.24 | jonored | (to a delete) |
| 02:39.02 | stustev | if you undo the last command (whatever it is) isn't that like deleting the last command - not just entities |
| 02:39.26 | Ralith | hell, what if you want to undo deleting an object? |
| 02:39.45 | Ralith | databases don't store commands >.< |
| 02:39.46 | stustev | I see - you are thinking ahead of me |
| 02:39.55 | stustev | :) |
| 02:39.55 | Ralith | they store primitives and their relationships |
| 02:40.07 | Ralith | deleting a command from your text editor has no bearing on anything |
| 02:41.18 | jonored | I think this is really getting to the part where some people just really, really want to have procedurally-generated stuff that they can edit the definition for, rather than manually rerun the generating program... |
| 02:41.35 | brlcad | there are plenty of commands that are not reversible or have no corresponding reverse action -- from a data storage perspective, 'undo' merely restores previous revisions (and that's all it needs to do really) |
| 02:41.54 | Ralith | thank you :] |
| 02:41.56 | brlcad | regardless of what reverse action it might correspond to |
| 02:42.01 | brlcad | it doesn't need to know really |
| 02:42.18 | Ralith | so at the barest level |
| 02:42.21 | brlcad | if complete construction history is preserved (infinite undo) |
| 02:42.27 | Ralith | all we need is a binary diff of the db state every time an action is made, right? |
| 02:42.32 | brlcad | basically |
| 02:42.39 | Ralith | that sounds very simple to implement |
| 02:42.43 | brlcad | tis |
| 02:42.49 | brlcad | there is even a lib that already does it |
| 02:42.56 | Ralith | *blinkblink* |
| 02:42.59 | brlcad | part of the geometry service design |
| 02:43.00 | Ralith | then why isn't mged hooked up? |
| 02:43.35 | brlcad | because that's active development, pretty big collaborative development effort with lots of simultaneous development threads |
| 02:43.58 | Ralith | ...so the API's likely to change under your feet? |
| 02:44.09 | brlcad | the new features like that one will probably only go into the new gui, especially complete versioning |
| 02:44.32 | jonored | But would that let you change something ten steps back without having to redo everything in between? |
| 02:44.33 | Ralith | unless mged is being completely abandoned, I'd think it would benefit from it |
| 02:44.38 | brlcad | the API is still being *written*, just getting started actually -- just one piece of a bigger effort |
| 02:44.56 | Ralith | jonored: that might require a bit more than a binary diff :/ |
| 02:44.58 | brlcad | there's the libged refactoring effort, that alone is moving and restructuring nearly 100k lines of code |
| 02:45.14 | Ralith | you'd have to have the logic to modify the future actions to acomodiate for any effect missing the past action would have |
| 02:45.36 | Ralith | ah, so there's only a lib that does it in the sense of their being a project. |
| 02:45.58 | brlcad | no, there are libs that already do the diffing |
| 02:46.22 | Ralith | you know what |
| 02:46.28 | Ralith | I have no doubt that you're doing things the Right Way |
| 02:46.32 | Ralith | so I'm going to go get breakfast/lunch/dinner |
| 02:47.02 | Ralith | (my schedule is that messed up. I am accordingly hungry.) |
| 02:47.51 | brlcad | like I said, there are several pieces to this puzzle -- the new geometry service is a fairly big effort that involves the new gui, a new OO geometry engine, a major mged/libged code refactoring, hooking into revisioning libraries, development of a service protocol, and binding that all together in phases |
| 02:48.31 | Ralith | oh, the undo bits depend on the geometry service as a whole which is itself incomplete? |
| 02:48.35 | Ralith | (or something like that) |
| 02:48.37 | jonored | Ralith: or store "how to get this shape" on the level of abstraction that the user types as well as on the level of straight CSG trees and matrices, and let it be edited and rerun easily. |
| 02:49.24 | Ralith | jonored: that would be pretty awesome, but it sounds pretty challenging to keep those in sync |
| 02:50.39 | Ralith | anyway. |
| 02:50.40 | Ralith | HUNGRY. |
| 02:50.43 | Ralith | -> food |
| 02:50.43 | stustev | jonored: I do not want just another point and click CAD program. If I wanted that I would go with Solidworks or some such like. I like brlcad because it can be so flexible. If I need to work in the brlcad manner I can learn that. I started this by suggesting a few things I thought I would like to see. I have CADKEY, Solidworks, Catia, Unigraphics, ProE and VX. I know how to use VX and I don't want to learn any of the others. They are very |
| 02:51.00 | brlcad | the "undo" functionality (which doesn't exist because the geometry service itself is far from complete) leverages a revision control layer (that already exists completed, but is a generic data versioning system) |
| 02:51.16 | Ralith | neat. |
| 02:51.23 | Ralith | shame it's not edible. |
| 02:53.24 | *** join/#brlcad iday (n=jlowens@c-68-55-215-195.hsd1.md.comcast.net) | |
| 02:53.40 | brlcad | the whole project is estimated around 6 staff years of effort in whole to achieve base production quality (not including new gui work), with around that many people presently contributing from 20% to 100% of their time |
| 02:54.29 | brlcad | stustev: irc has message limits, you were cut off ;) |
| 02:54.41 | brlcad | try breaking at the sentance level ;) |
| 02:54.49 | jonored | stustev: I'm not trying to say that the way brlcad works now is bad - but I was in here a few days ago asking about what I think is the same thing, and it's done somewhat, but isn't quite comfortable to me. I've been prodding at a line-by-line batch while we're talking because I'd use it too. |
| 02:55.16 | stustev | will do |
| 02:55.31 | brlcad | seriously, line-by-line command parsing is really pretty simple to implement |
| 02:56.05 | jonored | and I've been (distractedly; i have classes) prodding at stashing the TCL definitions of things in attributes and having a command to open it in an editor and rerun it when done... or just vim integration... stuff like that. |
| 02:56.06 | brlcad | wham, bam, could be done in less than an hour if you knew the scripting syntax |
| 02:56.23 | brlcad | jonored: neat |
| 02:56.30 | stustev | the whole thing shows up on my screen - where were you cut off? |
| 02:56.52 | brlcad | They are very |
| 02:57.44 | stustev | expensive and continue to get more expensive. The continue to box you into the capability programmed into the point and click interface. |
| 02:58.06 | jonored | is trying to find either stdin or a get-line-from-user in tcl.. five lines, I think, to go through it line-by-line, but with no backwards. |
| 02:58.49 | jonored | is wrong, that breaks for multi-line commands. |
| 02:59.48 | jonored | misses (read). |
| 03:00.33 | brlcad | thinks he set a record this week for too many hours.. |
| 03:00.48 | stustev | it is only Wednesday |
| 03:01.19 | brlcad | but end of month |
| 03:01.59 | stustev | it is that |
| 03:03.57 | stustev | bbl |
| 03:04.26 | brlcad | puts "next? [y/n]" |
| 03:04.38 | brlcad | catch {gets stdin answer} |
| 03:05.14 | brlcad | if {$answer == "y"} { ..process line.. rinse and repeat |
| 03:05.42 | jonored | Out of curiosity, how much of the graphical display stuff will libged be able to do? Would I be able to tell it to use a window like mged does now, or does the program using it need to do that? |
| 03:05.58 | brlcad | maybe write a "prompt user" command (I sent an example to one of the mailing lists many months back) |
| 03:06.26 | brlcad | "tell it to use a window like mged does now"? no entiendo |
| 03:06.45 | brlcad | libged has nothing to do with gui -- it's a geometry editing library |
| 03:07.28 | brlcad | it's moving a ton of editing, querying, analysis, and other command functionality (i.e. pretty much *all* commands in mged) into a library so that it can be reused |
| 03:07.41 | brlcad | and cleaned up at the same time |
| 03:07.54 | brlcad | refactoring is giving us the chance to remove some of the cobwebs |
| 03:08.23 | brlcad | performs his "take 2" homeward bounding |
| 03:11.21 | yukonbob | finishes reading scrollbck |
| 03:11.23 | yukonbob | *back |
| 03:15.48 | jonored | *Nod*. I'm asking if libdm is in libged, aren't I. I should look at these things before asking and confusing people... |
| 03:32.09 | starseeker | wishes he knew enough to contribute something useful to the Geometry Engine email... his only suggestion might be that a brief summary of the potential pros/cons of the various approaches available might be educational, although orthogonal to the purpose of the email... |
| 03:39.17 | brlcad | starseeker: you are contributing something *vital* |
| 03:40.00 | brlcad | feature requests, bug fixes, releases .. those *have* to keep happening, so if you're not doing them then that just falls back on others (me!) |
| 03:40.13 | brlcad | jonored: libdm is definitely not in libged |
| 03:40.56 | brlcad | libged does provide generic display lists though .. which libdm uses .. which opengl can use .. and others because they're .. generic ;) |
| 06:20.21 | *** join/#brlcad clock_ (n=clock@217-162-110-91.dclient.hispeed.ch) | |
| 07:08.01 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 07:12.13 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 07:28.45 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) [NETSPLIT VICTIM] | |
| 08:30.46 | *** join/#brlcad Elperion (n=Bary@p5B14DFE6.dip.t-dialin.net) | |
| 08:44.30 | brlcad | hrm |
| 08:44.35 | brlcad | decides to call it a day |
| 08:48.44 | d_rossberg | brlcad: who is davidloman? |
| 09:15.59 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 09:20.24 | mafm | hi |
| 09:41.35 | CIA-23 | BRL-CAD: 03homovulgaris * r32155 10/brlcad/trunk/src/libpc/ (pcVariable.cpp pcVariable.h): Adding type information to Variable classes so as to avoid RTTI during construction/destrcution |
| 09:43.08 | CIA-23 | BRL-CAD: 03homovulgaris * r32156 10/brlcad/trunk/src/libpc/ (pcPCSet.cpp pcPCSet.h): addVariable() and addConstraint() functions for the operation of PCSet object: argument list to be changed to non pointer type |
| 10:51.53 | CIA-23 | BRL-CAD: 03bob1961 * r32157 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added light and zclip commands to ged_obj. |
| 10:54.22 | CIA-23 | BRL-CAD: 03d_rossberg * r32158 10/brlcad/trunk/src/libged/CMakeLists.txt: some modifications to be consistent with Makefile.am |
| 11:07.44 | d_rossberg | mafm: is rt^3 for gui development only or is it a more general C++ developmend sandbox? |
| 11:12.09 | mafm | d_rossberg: I don't know, it was created before me |
| 11:12.25 | mafm | Sean suggested me to put my new interface there |
| 11:12.51 | mafm | AFAIK it was not really used, the rest of code around are placeholders/sketches |
| 11:13.28 | mafm | and it was devised as a place to put things like 3D interfaces, thus the name rt^3 |
| 11:16.53 | d_rossberg | same to me: Sean suggested me to put my C++ interface there |
| 11:17.29 | d_rossberg | so don't be surprised |
| 11:17.55 | mafm | all right |
| 11:18.07 | mafm | it was you who was creating directories yesterday? |
| 11:18.34 | d_rossberg | no, it was David Loman |
| 11:19.27 | d_rossberg | he works probable at the ARL, but i don't know his intention in creating these directories |
| 11:23.10 | *** join/#brlcad saltan (n=lievensa@d51530284.access.telenet.be) | |
| 11:27.21 | *** join/#brlcad thing0 (n=ric@58.171.251.214) | |
| 11:28.04 | mafm | OK |
| 11:28.20 | mafm | so well, at the moment I've only put stuff in src/other, src/g3d and data/g3d |
| 11:28.52 | mafm | I don't know much about the rest |
| 11:29.48 | mafm | if we're going to use same code, like patterns and so on, we could move our code to libUtility or similar dirs |
| 11:36.16 | CIA-23 | BRL-CAD: 03bob1961 * r32159 10/brlcad/trunk/src/libtclcad/ged_obj.c: Removed a bit of temporary/test code. |
| 11:39.34 | CIA-23 | BRL-CAD: 03d_rossberg * r32160 10/brlcad/trunk/src/other/intaval/ (Makefile.am tgf2g.dsp): |
| 11:39.34 | CIA-23 | BRL-CAD: removed MSVS 6.0 project file |
| 11:39.34 | CIA-23 | BRL-CAD: BRL-CAD doesn't support this VS version any more |
| 11:45.57 | CIA-23 | BRL-CAD: 03d_rossberg * r32161 10/brlcad/trunk/src/other/intaval/ (8 files): made the copyright and license notice compatible with the rest of BRL-CAD |
| 12:10.42 | *** join/#brlcad louipc_ (n=louipc@69-196-131-241.dsl.teksavvy.com) | |
| 13:23.48 | starseeker | brlcad: Thank you :-). I was referring more to the issues you had asked for comment on in the email "BRL-CAD C++ Geometry Engine" - things like run-time typing and single object hierarchies are a bit beyond my expertice level as yet ;-) |
| 13:25.03 | brlcad | nods |
| 13:25.50 | brlcad | ah, missed daniel |
| 13:30.01 | poolio | brlcad: I'm leaving now :) |
| 13:53.34 | starseeker | there we go, much better: http://brlcad.org/wiki/ARL_Technical_Reports |
| 13:54.00 | starseeker | needs to docbook those suckers once 7.12.6 is out... |
| 13:54.44 | brlcad | the OLD subdir should get merged in |
| 13:55.08 | brlcad | it was just a place to put the previous site mirror |
| 14:03.03 | starseeker | I know |
| 14:03.12 | starseeker | but at least there is SOME active link now |
| 14:03.30 | starseeker | merging it in will take longer, especially if we docbook/wikify it |
| 14:04.11 | starseeker | I could pull it out and make a "reports" directory to hold them in the main site, if that's preferable |
| 14:05.51 | starseeker | just let me know - if you don't want any link until they're ready I can revert it, too |
| 14:07.13 | brlcad | nah, it's better |
| 14:07.26 | brlcad | just saing it's not where it should be |
| 14:11.26 | CIA-23 | BRL-CAD: 03mafm * r32162 10/rt^3/trunk/src/g3d/ (GuiWidgetRotation.cxx GuiWidgetRotation.h): Adding custom Widget based in RBGui::Widget intending to represent and control rotations |
| 14:15.43 | CIA-23 | BRL-CAD: 03mafm * r32163 10/rt^3/trunk/src/g3d/ (GuiCamera.cxx GuiCamera.h): Adding window to control camera and display different properties |
| 14:37.15 | CIA-23 | BRL-CAD: 03mafm * r32164 10/rt^3/trunk/src/g3d/ (GuiBaseWindow.cxx GuiWindowManager.cxx): Whitespace and debug logging messages |
| 14:38.25 | CIA-23 | BRL-CAD: 03mafm * r32165 10/rt^3/trunk/src/g3d/ (Application.cxx Application.h): Adding new window and widget, and commenting out test code |
| 14:39.16 | *** join/#brlcad thing0 (n=ric@58.171.163.20) | |
| 15:00.06 | brlcad | mafm: it is a general c++ development sandbox if the question comes up again ;) |
| 15:01.42 | mafm | :| |
| 15:01.55 | mafm | so people can deposit cat droppings in there... not good! |
| 15:15.03 | mafm | nice, I try to draw lines and I got back characters being rendered |
| 15:16.25 | brlcad | cool |
| 15:16.34 | brlcad | so maybe you should draw characters, see if you get lines |
| 15:25.45 | mafm | text leads to text |
| 15:32.19 | mafm | huh, that's strange |
| 15:32.55 | mafm | it seems that the font manager decodes something in every widget and thus the characters get rendered |
| 16:34.53 | brlcad | mafm: how are you rendering fonts? (what font manager? one in ogre?) |
| 16:35.32 | brlcad | notes he also works with ftgl .. so would be highly inclined to use that where we need ofnt rendering -- it's good stuff |
| 16:42.11 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) | |
| 16:44.47 | mafm | brlcad: freetype, I think |
| 16:46.50 | brlcad | eh, that might be what's under the hood, sure |
| 16:46.57 | brlcad | but what are you interfacing through? |
| 16:47.03 | brlcad | something ogre provides? |
| 16:48.18 | mafm | RBGui |
| 16:48.42 | mafm | I don't know if in turn in uses some OGRE thing -- might be |
| 16:50.58 | mafm | #include <ft2build.h> |
| 16:50.59 | mafm | #include FT_FREETYPE_H |
| 16:51.09 | mafm | (in RBGui::FontManager.cpp) |
| 16:51.15 | mafm | so they use that directly, I guess |
| 16:59.00 | starseeker | brlcad: Know anything about Growl for Mac OSX? |
| 16:59.10 | starseeker | http://growl.info |
| 17:00.11 | mafm | I have to go now |
| 17:00.13 | mafm | take care :) |
| 17:02.49 | brlcad | starseeker: I do now |
| 17:10.31 | starseeker | heh - those scripts that get subversion to use FileMerge seem to want to use it |
| 17:11.05 | starseeker | Growls in frustration |
| 17:15.46 | brlcad | really? that's odd |
| 17:15.52 | brlcad | change the scripts |
| 17:21.17 | starseeker | they'll work without it, but there seems to be some feature it provides that they benefit from |
| 17:21.37 | starseeker | maybe you don't have to manually quit FileMerge if you have it around |
| 17:23.39 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 18:16.40 | CIA-23 | BRL-CAD: 03pacman87 * r32166 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: don't need to check the angle for hits on start/end planes, replaced with a check for rev->ang > M_PI |
| 18:40.27 | CIA-23 | BRL-CAD: 03starseeker * r32167 10/brlcad/branches/pre-7-12-6/current_successful_compile_rev.txt: upload notes on progressive compile issues identified so far |
| 18:53.50 | *** join/#brlcad andrecastelo (n=chatzill@189.71.78.186) | |
| 20:18.32 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 20:33.00 | Ralith | What sort of OS do most devs here run on? |
| 20:33.14 | pacman87 | i run slackware |
| 20:33.35 | Ralith | linuxes, then? |
| 20:33.36 | pacman87 | occasionally boot winXP on weekends |
| 20:33.42 | pacman87 | but not for dev work |
| 20:49.48 | PrezKennedy | vista! |
| 20:50.09 | PrezKennedy | except im not a dev... just an innocent bystander |
| 20:50.23 | pacman87 | if you run vista, you're not innocent... |
| 20:52.46 | PrezKennedy | at least im not fingering people and mounting drives like you sickos :P |
| 20:53.23 | pacman87 | hey, i never said we were innocent either |
| 20:53.37 | Ralith | at least we're experienced :> |
| 20:55.20 | PrezKennedy | "hey baby, i know how to mount a drive" ;) |
| 20:58.20 | *** join/#brlcad louipc (n=louipc@206-248-159-211.dsl.teksavvy.com) | |
| 21:05.57 | CIA-23 | BRL-CAD: 03homovulgaris * r32168 10/brlcad/trunk/src/libpc/ (pcConstraint.cpp pcConstraint.h): forward declaration of PCSet for usage of PCSet methods |
| 21:07.45 | CIA-23 | BRL-CAD: 03homovulgaris * r32169 10/brlcad/trunk/src/libpc/pcVariable.cpp: correcting inherited protected variable access name |
| 21:07.51 | *** join/#brlcad Elperion (n=Bary@p5B14DFE6.dip.t-dialin.net) | |
| 21:11.13 | CIA-23 | BRL-CAD: 03homovulgaris * r32170 10/brlcad/trunk/src/libpc/ (pcPCSet.cpp pcPCSet.h solver_test.cpp): Variable addition methods for the PCSet object |
| 21:11.14 | *** join/#brlcad louipc_ (n=louipc@76-10-182-238.dsl.teksavvy.com) | |
| 21:17.19 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 22:13.24 | *** join/#brlcad geocalc (n=geocalc@91-171-209-117.rev.libertysurf.net) | |
| 22:24.25 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 22:45.25 | CIA-23 | BRL-CAD: 03starseeker * r32171 10/brlcad/branches/pre-7-12-6/ (69 files in 35 dirs): OK, take a step back. Reverting to 32083. |
| 22:54.13 | CIA-23 | BRL-CAD: 03starseeker * r32172 10/brlcad/branches/pre-7-12-6/src/rt/rt_simple.c: Opps, add rt_simple back in to get to 32083 state. |
| 23:02.27 | brlcad | Ralith: Mac, BSD, and Linux for most of the devs |
| 23:03.16 | starseeker | keeps waiting for someone to port BRL-CAD to HaikuOS ;-) |
| 23:03.37 | brlcad | that would be fun |
| 23:03.43 | Ralith | so an acceptable form of binary release for g3d would be a binary tarball for extraction into an installation root? |
| 23:04.34 | brlcad | ah, for g3d, sure -- it can be pretty much anything |
| 23:05.04 | brlcad | it's more just getting it into some dev users hands for easy testing, getting a feedback loop started |
| 23:05.22 | brlcad | there the OS doesn't matter, could pretty much pick anything |
| 23:05.25 | starseeker | needs to check if it's still doing the screwed up font thing on his Gentoo box... |
| 23:06.34 | Ralith | finds the idea of a binary release for devs to be somewhat odd |
| 23:08.01 | brlcad | it's not just for devs -- its for anyone really |
| 23:08.28 | starseeker | Does it still need all the libs installed as root? |
| 23:08.37 | starseeker | or did it ever, for that matter? |
| 23:09.00 | CIA-23 | BRL-CAD: 03homovulgaris * r32173 10/brlcad/trunk/src/libpc/TODO: list of minor tasks/ plan in libpc |
| 23:17.38 | CIA-23 | BRL-CAD: 03starseeker * r32174 10/brlcad/branches/pre-7-12-6/ (4 files in 3 dirs): |
| 23:17.38 | CIA-23 | BRL-CAD: Merge in changes to get the tree back into a working state, circa 32083 as far |
| 23:17.38 | CIA-23 | BRL-CAD: as merging in of trunk changes. Testing indicates there be dragons in the 32085 |
| 23:17.38 | CIA-23 | BRL-CAD: and 32086 changes, so prepare working base and re-attempt the subsequent merges |
| 23:17.38 | CIA-23 | BRL-CAD: from trunk from there. |
| 23:18.11 | brlcad | if he's making a binary release, he has the opportunity to sort that out |
| 23:18.20 | starseeker | ah. |
| 23:19.14 | starseeker | goes to get dinner before attempting to get over the next merge barrior |
| 23:23.53 | Ralith | I don't know many libs that do need to be installed as root |
| 23:30.15 | brlcad | think he meant that need to be installed beforehand/separately |
| 23:32.06 | brlcad | in which case the installer for the dependency (e.g. on Mac) might be set up to require perms to go where the installer wants to put it |
| 23:33.02 | brlcad | there's never been a release of it yet, so it's a mostly moot point though -- he could make the whole thing one big stand-alone static binary if he wanted |
| 23:40.23 | CIA-23 | BRL-CAD: 03homovulgaris * r32175 10/brlcad/trunk/src/libpc/ (pcParser.cpp pcVariable.cpp): cleanup / debug removal |
| 23:40.42 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 23:42.59 | CIA-23 | BRL-CAD: 03homovulgaris * r32176 10/brlcad/trunk/src/libpc/pcVariable.h: intersectInterval modified to take into account empty Domain; display function modified to show Variable type |
| 23:45.44 | CIA-23 | BRL-CAD: 03homovulgaris * r32177 10/brlcad/trunk/src/libpc/ (pcPCSet.cpp pcPCSet.h solver_test.cpp): modification to addVariable() and pushVar() functions of PCSet. small *hack* in pushVar() since default specialized constructors are not being used |