| 00:06.22 | ``Erik | destroys every rj45 jack in brlcads possession to make it so all the issues get fixed before he can compile :D |
| 00:06.55 | pacman87 | ``Erik: don't forget to warp his wireless antenna in a faraday cage |
| 00:08.04 | ``Erik | I'm fairly certain his intarweb uplink requirs an rj45 :D though he might be low enough to try to steal a neighbors 802.11[bg] |
| 00:08.47 | ``Erik | someone in the same apt complex as him was whining because they couldn't steal wifi access, so I d'no if he has that opportunity without going "above and beyond" the casual bandwidth thiefs ability... |
| 00:09.22 | ``Erik | mah finners hurt |
| 00:10.04 | ``Erik | jamming out cream, hendrix, metallica, ac/dc, pantera, and some random thrash/speedmetal... rough on ya if you haven't kept your callouses up |
| 00:10.33 | ``Erik | I think I'm running 10's on that gitfiddle, to boot |
| 00:16.29 | brlcad | yup, there are like 15 competing wireless nets |
| 00:17.02 | brlcad | last I checked, two were wide open, I use them from time to time just for kicks (when I have .. "stuff" .. to download) |
| 00:30.02 | ``Erik | deletes the last two lines |
| 00:31.36 | ``Erik | my face hurts from pissing off punker on webcam O.o |
| 00:31.56 | ``Erik | she's freaking out about my face fuzz, so I keep pulling it out to exaggerate it |
| 00:32.27 | ``Erik | (it's not like I have that much, sheesh) |
| 00:33.10 | ``Erik | invests in moustache wax |
| 00:56.16 | brlcad | heh |
| 00:57.07 | brlcad | kinda misses when the goatee could be gripped entirely in hand and still have a bit more to go |
| 01:14.47 | ``Erik | heh |
| 01:15.33 | *** join/#brlcad madant (n=homovulg@202.63.233.61) |
| 01:16.01 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 01:17.09 | brlcad | howdy madant |
| 01:17.44 | brlcad | great name, btw |
| 01:19.49 | brlcad | pacman87: nice update :) |
| 01:19.57 | brlcad | loves getting feed updates |
| 01:21.10 | pacman87 | brlcad: yeah, i kind of forgot about it last week; too busy wrestling with tess() :) |
| 01:26.25 | brlcad | pacman87: actually coding and commiting is a perfect excuse and alternative for updating the log :) |
| 02:24.34 | yukonbob | hello, cadheads |
| 02:30.02 | PrezKennedy | howdy brlcad |
| 02:52.34 | brlcad | howdy howdy |
| 04:00.40 | punkrockgirl | um, erik has more than face fuzz |
| 04:00.45 | punkrockgirl | fyi :) |
| 04:01.08 | punkrockgirl | he has more hair on his face than on his head |
| 04:01.20 | punkrockgirl | and its not neatly kept |
| 04:01.42 | punkrockgirl | :P |
| 07:05.11 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 08:10.20 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 09:02.53 | d_rossberg | i don't like the idea of using a reference to a sketch in other primitives |
| 09:03.07 | d_rossberg | even the extrude isn't suitable for an example of this |
| 09:03.46 | d_rossberg | correct me if i'm wrong but i think this primitive will crash after removing the sketch |
| 09:04.13 | d_rossberg | furthermore the implementation of nurb curves is missing |
| 09:04.43 | d_rossberg | and the method for bezier works for straight line paths only |
| 09:05.49 | d_rossberg | therefore i'm not convinced that this would be the right start point for revolves and sweeps |
| 09:24.55 | brlcad | using the existing nurb curve struct was just a thought |
| 09:24.59 | brlcad | or some similar structure |
| 09:25.16 | brlcad | there are just about five different 3d spline path structures throughout the code |
| 09:25.31 | brlcad | because every keeps implementing their own for their little bit |
| 09:25.41 | brlcad | instead of refactoring that into something proper in librt |
| 09:26.35 | brlcad | the intent is just to either find something existing that will work perfect or make it something proper in librt (and perhaps get the others using it) |
| 09:28.06 | brlcad | as for the named reference, it certainly shouldn't crash -- it's no different than how combinations and regions work, or textures, or dsp height fields, or bump maps, or extrudes, etc |
| 09:31.34 | brlcad | to change from named references would certainly be a pretty big shift from convention |
| 09:52.14 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-040-112.pools.arcor-ip.net) |
| 10:06.34 | *** join/#brlcad Elperion (n=Bary@p5B14FA2E.dip.t-dialin.net) |
| 10:22.20 | d_rossberg | it's only on the disk a named reference |
| 10:22.57 | d_rossberg | the internal structure of an extrusion refers to the internal structure of the sketch |
| 10:32.43 | d_rossberg | as for the convention: there is a big difference between the extrusion and your other examples |
| 10:33.46 | d_rossberg | you can't create an extrusion from an arbitrary sketch |
| 10:34.03 | brlcad | it's actually only the on-disk structure that I was referring to |
| 10:34.22 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 10:34.31 | brlcad | it can do whatever it needs to for the internal structure (what is used by prep) |
| 10:35.01 | brlcad | I took what you said of not using a reference to mean that the on-disk shouldn't use a named reference |
| 10:35.44 | brlcad | the extrusion still isn't so different, I can't create combinations from arbitrary database objects either |
| 10:36.22 | d_rossberg | but it's limited my their types only? |
| 10:36.51 | brlcad | they need to be solid 3D primitives or other combinations |
| 10:37.08 | d_rossberg | or sketches |
| 10:37.09 | brlcad | so not even any primitive |
| 10:37.46 | brlcad | hm? |
| 10:38.09 | d_rossberg | only a question: can a combination contain a sketch? |
| 10:38.58 | brlcad | it could by name, but it would not be a valid combination |
| 10:39.09 | brlcad | e.g. if you 'e' it up, it's going to complain |
| 10:39.42 | d_rossberg | my statement wasn't "every primitive" but "if it can refer an arb (e.g.) then any arb" |
| 10:41.03 | d_rossberg | with this you can test at creation time for correctness |
| 10:41.26 | brlcad | i'm still not sure what you're trying to say overall :) |
| 10:42.24 | d_rossberg | ok, i see some potential preblems there: |
| 10:42.26 | brlcad | my original notes were merely to 1) decrease entropy when picking a spline path and 2) have on-disk be a named reference .. no more, no less :) |
| 10:42.56 | brlcad | if you're not talking about on-disk, then I don't see a problem |
| 10:43.44 | d_rossberg | 1) the test for the referenced sketch is done on creation only |
| 10:43.46 | brlcad | as for usability, there are all sorts of things that can be done to test for correctness at time of creation or db import loading or ray-trace prep |
| 10:44.52 | d_rossberg | i.e. if you create an extrusion and remove the sketch the program will crash next time it accesses the extrusion primitive |
| 10:45.59 | d_rossberg | 2) the extrusion primitive has some special requirements to the sketch |
| 10:46.02 | brlcad | it "shouldn't" crash no matter what is done, *any* crash is a hard bug imho that can be prevented :) |
| 10:47.18 | d_rossberg | because there is no explicit conversion these requirements are hidden |
| 10:47.35 | d_rossberg | and changing the sketch can destroy the extrusion |
| 10:48.06 | d_rossberg | (that's the "not arbitrary" point) |
| 10:49.41 | brlcad | apologies, but I'm still not clear on what you're trying to say -- are your 1)/2) points potential problems or things that we should do or not do? |
| 10:50.35 | brlcad | and similarly, are you talking about what it should do, shouldn't do, or currently does |
| 10:51.01 | brlcad | as even extrude does a few things currently that it really shouldn't (wrt robustness) |
| 10:52.46 | brlcad | otherwise I quite agree that if you screw up or remove a sketch, you implicitly invalidate the extrude .. and that fact should be evident the next time the extrude is used (because it's invalid) |
| 10:55.37 | d_rossberg | only invalid wouldn't be a problem for me, e.g. if you have a reference to a texture bitmap and somebody removed this bitmap you won't see it |
| 10:56.53 | d_rossberg | but if you are using a pointer to an internal structure and you use this pointer without test if the refered object still exits you have a problem |
| 10:58.18 | d_rossberg | therefore the point is: if you are working with references you have to care for them |
| 10:59.16 | brlcad | quite true |
| 10:59.43 | d_rossberg | sometimes it is woth doing this: combinations, textures, etc. |
| 11:00.00 | brlcad | right, you might remove something merely to update it with something new |
| 11:01.10 | brlcad | I've done something similar with extrudes in the past, removing/updating a sketch to test different extrude shapes -- and it wasn't robust, had bugs that had to be fixed |
| 11:02.04 | brlcad | it used to crash if you created an empty sketch, for example, which is a "valid" sketch, but invalid for extrusion purposes just as if I'd given a curve instead of a closed path contour |
| 11:02.17 | d_rossberg | in the case of an extrusion it would be worth doin it, if there would be a real reference relationship |
| 11:02.19 | brlcad | no longer crashes, that was a bug |
| 11:04.23 | brlcad | i don't see sweep and revolve as being different, they're just different types of sweep paths with extrude being a simple linear and rotationally invariant sweep |
| 11:04.29 | d_rossberg | but in fact the extrusion primitive has its own type of "sketch" which can be memorized in the BRL-CAD sketch primitive |
| 11:05.09 | brlcad | you mean the fact that it has to form a non-empty closed loop? |
| 11:05.19 | brlcad | that being the type? |
| 11:05.32 | d_rossberg | yest, and the nurb thing |
| 11:05.59 | d_rossberg | (i mean "yes") |
| 11:06.43 | d_rossberg | logically it's an other type |
| 11:06.49 | brlcad | yeah, I think that's the same type that sweep needs, but not necessarily the type that revolve needs (since it needs to only be closed on a given axis) |
| 11:07.34 | d_rossberg | and the sweep type would have problems with the Beziers |
| 11:08.49 | d_rossberg | the common thing is that all these primitives could use rt_sketch_internal |
| 11:09.07 | brlcad | yeah, they should |
| 11:09.13 | brlcad | they just need to validate differently |
| 11:09.21 | brlcad | what's the problem with the bezier curves? |
| 11:09.21 | d_rossberg | but does this mean the same as having a reference to aan arbitrary sketch? |
| 11:09.43 | d_rossberg | Bezier: finding the roots |
| 11:11.42 | brlcad | which roots? roots are used in plotting the curve as well as during ray-tracing (in the case of extrude) to evaluate where the surface is |
| 11:12.53 | d_rossberg | e.g. during the ray-trace |
| 11:15.58 | d_rossberg | to be clear: these are problems which should be solved before the implementation starts |
| 11:16.10 | d_rossberg | the solution could be to use a reference to a sketch and make tests during the ray-trace |
| 11:16.21 | d_rossberg | or to use an internal structure for the sketch and e.g. use the BRL-CAD sketch for creation (and make the tests there) |
| 11:19.41 | d_rossberg | maybe pacman87 should think about it and give us a well-founded proposal |
| 11:20.09 | brlcad | iirc, the way extrude deals with it is that it loads the sketch during import (stores it in rt_extrude_internal) and then during ray-trace, it converts the sketch into extrude-specific information (i.e. struct extrude_specific, no longer using rt_sketch_internal) by projecting the sketch onto a plane creating a connected set of curves (struct curve) and vertices (point_t's) |
| 11:21.31 | brlcad | yeah, I think pacman87 should think about and document what it needs to do :) |
| 11:23.42 | d_rossberg | i've looked into extrude.c: in the prep function there is a test if the pointer to the sketch is still valid (RT_SKETCH_CK_MAGIC) |
| 11:24.06 | d_rossberg | this probable solves some problems |
| 11:24.14 | d_rossberg | <PROTECTED> |
| 11:25.18 | brlcad | nods |
| 12:37.35 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 12:38.45 | *** join/#brlcad thing0 (n=ric@123.208.43.139) |
| 12:50.15 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 12:50.44 | mafm | heyo |
| 13:49.41 | CIA-22 | BRL-CAD: 03mafm * r31426 10/rt^3/trunk/src/g3d/ (CMakeLists.txt cmake/UsePkgConfig.cmake): CMake now compiles the binary; but more work is needed to get to install the package in the system, and furthermore -- doing it properly. |
| 14:09.51 | brlcad | howdy mafm |
| 14:13.18 | mafm | hey |
| 14:13.23 | starseeker | puts on his football gear and takes another headlong rush at the firebird manual setup |
| 14:13.56 | mafm | so continuing with yesterday's conversation, is the rt³ module only for the new GUI? |
| 14:14.58 | mafm | this CMake thing is pretty funny! |
| 14:17.26 | brlcad | hah |
| 14:17.41 | brlcad | likes the appropos use of unicode |
| 14:18.25 | mafm | Unicode? |
| 14:18.35 | mafm | it's regular ascii I think |
| 14:18.36 | brlcad | rt³ |
| 14:18.39 | brlcad | is it? |
| 14:18.43 | brlcad | neat |
| 14:18.58 | mafm | well, when you press caret ^ plus 2 or 3, it adds that character |
| 14:19.13 | mafm | I did it unintentionally, trying to write rt^3 :) |
| 14:19.39 | mafm | the key strokes are: r t shift+caret space 3 |
| 14:19.50 | brlcad | rt^ 3 |
| 14:19.52 | mafm | if you don't press the space, caret is applied as an accent |
| 14:19.52 | brlcad | :) |
| 14:20.14 | mafm | as for â é |
| 14:20.29 | brlcad | which OS? |
| 14:21.03 | *** part/#brlcad louipc (n=louipc@76-10-146-181.dsl.teksavvy.com) |
| 14:21.38 | mafm | Debian Linuz |
| 14:22.32 | mafm | (0)¹ n² c³ ... r^4 doesn't work |
| 14:23.19 | mafm | probably your keyboard is not set up to have carect acting as an accent, so you can't do it like this |
| 14:23.45 | brlcad | doesn't see superscript in the ascii table |
| 14:24.23 | mafm | http://www.pemberley.com/janeinfo/latin1.html |
| 14:24.26 | mafm | this one has |
| 14:24.33 | mafm | not ascii though :D |
| 14:25.04 | brlcad | ah, yeah |
| 14:25.19 | brlcad | 8859-1 != ascii ;) |
| 14:26.33 | brlcad | nice, http://en.wikipedia.org/wiki/Code_page_850 shows the overlap |
| 14:28.22 | brlcad |  |
| 14:28.48 | mafm | I see a "blank space" (with rectangle around) |
| 14:29.04 | mafm | that CP is for windows |
| 14:29.21 | brlcad | figured, it's a mac-specific charcode |
| 14:29.26 | mafm | equivalent of latin1 I think |
| 14:30.18 | brlcad | i know that's what the table is for, but it still shows where ascii and latin1 coincide |
| 14:30.35 | brlcad | and (more interestingly) where they don't |
| 14:33.20 | brlcad | ââ¦ây ⥠â BRL-CAD â» |
| 14:33.30 | brlcad | woo, irssi didn't like that :) |
| 14:33.53 | brlcad | course I'm set to utf-8 atm |
| 14:34.20 | mafm | you look like a orkut teenager :P |
| 14:37.48 | brlcad | meh, if I could feel like one too, I'd be a great shape ;) |
| 14:38.25 | mafm | heh :) |
| 14:39.10 | mafm | so well... the module is mainly for g3d or not? would I create a general CMakefile instead? |
| 14:39.58 | CIA-22 | BRL-CAD: 03mafm * r31427 10/rt^3/trunk/src/g3d/ (CMakeLists.txt cmake/UsePkgConfig.cmake): Sanitizing the helper pkg-config module for CMake |
| 14:45.01 | PrezKennedy | brlcad, is my brother on a windoze machine? |
| 14:46.24 | brlcad | PrezKennedy: nope |
| 14:46.51 | PrezKennedy | any machine at all? i know its the Fed... it took em two weeks to get me connected |
| 14:47.08 | brlcad | mafm: mainly, yes -- that's where it's all going to come together for the geometry service, the OO engine API, and the new gui (i.e. g3d) |
| 14:48.55 | PrezKennedy | first day at FGS i had to set up my own computer :P |
| 14:50.05 | mafm | oki |
| 14:54.18 | brlcad | and they all need to work together :) |
| 14:55.15 | brlcad | which includes organizationally putting things together than can be reused, but also keeping an eye on the library functionality in our existing core libraries (libbu, libbn, librt, libged) |
| 14:55.46 | brlcad | bob said last night that libged is almost ready for you to use for testing |
| 14:56.41 | mafm | good |
| 14:56.50 | brlcad | there's only two pieces of functionality that should be needed, opendb and draw |
| 14:57.02 | brlcad | that gives you a display list for rendering 3d wireframes |
| 14:57.42 | brlcad | the focus should still be more on the gui itself, though, getting the major portions worked on (like non-overlapping windows, command overlay, etc) |
| 14:58.44 | mafm | yep |
| 14:59.10 | mafm | and I think that I'll need all this week for getting all this building thing complete, with the external libraries and so on |
| 14:59.42 | brlcad | oh, what's the complicated part? |
| 15:00.45 | mafm | the external libs, devise an automatic system to compile all that, applying patches and so on |
| 15:05.39 | brlcad | ok, sounds good |
| 15:05.47 | brlcad | let bob know :) |
| 15:05.52 | brlcad | and/or wiki note |
| 15:09.04 | mafm | should I write bob especially? he never comments anything |
| 15:13.11 | brlcad | updating the wiki should be fine |
| 15:13.15 | brlcad | he reads it |
| 15:13.29 | brlcad | he's just a guy of (very) few words |
| 15:13.57 | brlcad | he cares more about end-result and/or if you directly ask him a specific technical question |
| 15:16.14 | starseeker | begins to like XInclude |
| 15:26.12 | ``Erik | brlcad: on site today? lunch? |
| 15:26.25 | brlcad | dunno |
| 15:27.33 | brlcad | lemme know where you decide to go |
| 15:27.36 | mafm | oki |
| 15:29.00 | brlcad | likes how the CMake universal deals with relocatable Mac installs |
| 15:39.29 | mafm | brlcad: can you please put this in a CMakeLists.txt and give me the SYSTEM output? |
| 15:39.29 | mafm | include(CMakePrintSystemInformation) |
| 15:47.31 | brlcad | http://paste.bzflag.bz/m1f49d99d |
| 15:53.39 | mafm | holy cow |
| 15:53.46 | mafm | the system name is Darwin? |
| 15:54.30 | mafm | I thought that it would be MacOSX or so |
| 15:54.57 | mafm | if creationists discover this internal name for Mac, they might set Stevie on fire |
| 16:08.41 | CIA-22 | BRL-CAD: 03mafm * r31428 10/rt^3/trunk/src/g3d/ (Application.cxx CMakeLists.txt): Auto-detecting system when building, intead of hardcoding POSIX, and some other misc enhancements |
| 16:10.24 | CIA-22 | BRL-CAD: 03mafm * r31429 10/rt^3/trunk/ (data/ src/data/): Moving data out of src/, for some reason I had created it in there... |
| 16:21.02 | brlcad | mafm: the kernel and underlying BSD OS has always been called Darwin |
| 16:21.34 | brlcad | "Mac OS X" is a suite of applications and frameworks that sit on top of Darwin |
| 16:22.25 | brlcad | just like with the autotools, though, you really shouldn't be associating functionality with the system type, it should be tied to features |
| 16:24.29 | mafm | testing for features separately? |
| 16:24.30 | brlcad | at least if/when you can at all avoid it, just not a good approach for long-term maintainability |
| 16:25.03 | brlcad | absolutely |
| 16:25.23 | brlcad | if you need to know if X is available, you don't assume POSIX means there's X, you test for X |
| 16:25.30 | brlcad | that sort of thing |
| 16:26.38 | brlcad | or better example, say you had a bit of code that needed to use posix threads .. you wouldn't test for POSIX, you'd test for posix threads specifically as that could be available on APPLE, WIN32, etc, |
| 16:29.57 | mafm | I see |
| 16:33.11 | brlcad | it's a little more work, but it's the maintainable approach |
| 16:33.31 | brlcad | actually ends up making the logic somewhat simpler overall |
| 16:33.55 | brlcad | otherwise you end up needing to add version checks per platform that quickly can get messy |
| 16:35.13 | brlcad | good catch on the src/data move .. I swear I'd checked to make sure it wasn't in src when you originally committed :) |
| 16:35.22 | mafm | but I guess that it can be cascated with the libraries? |
| 16:35.40 | brlcad | ~dict cascate |
| 16:35.48 | mafm | cascade* |
| 16:35.56 | mafm | i.e. my program doesn't include any X file at all |
| 16:36.08 | brlcad | that's a good thing! :) |
| 16:36.17 | brlcad | hopefully never will |
| 16:37.55 | brlcad | not sure what you mean by cascaded though, data resources are generally not tied to libraries |
| 16:39.02 | mafm | that I don't need to test for X in specifically in my program, that's up to OGRE |
| 16:39.33 | mafm | if OGRE builds fine or there's OGRE installed in the system, I don't have to care |
| 16:42.50 | brlcad | oh |
| 16:42.58 | brlcad | eh, that was just an example, like the posix threads |
| 16:43.08 | brlcad | it could be any bit of functionality |
| 16:43.48 | brlcad | the point being to test for the functionality at configure time, not some concept of a system that is supposed to have that functionality |
| 16:45.33 | brlcad | so in the case of ogre creating platform-specific windows, the "feature" is the windowing system they're requiring |
| 16:51.54 | mafm | well, but I mean that OGRE does that by itself |
| 16:52.10 | mafm | so I don't have to do it again for the program, I hope? |
| 16:59.46 | brlcad | if ogre does it by itself, then you don't need to do any checks at all theoretically |
| 17:00.18 | brlcad | I'm saying in the code *you* write and the checks you find you need to perform, there shouldn't be system tests |
| 17:06.16 | mafm | but in example for RBGui they want in general the platform |
| 17:06.47 | mafm | so they abstract some operations (directory listing, mouse cursos, etc) all together |
| 17:07.21 | mafm | so in principle that has to be treated as a whole |
| 17:08.35 | ``Erik | (bowling alley, ya didn't miss much) |
| 17:09.48 | ``Erik | one of the big benefits from moving to cake to autotools was the ability to reference feature instead of OS, suddenly a lot of '#ifdef IRIX_6" went away and suddenly a bunch of new platforms could be built on O.o |
| 17:13.18 | brlcad | mafm: understood and expected, lots of projects still perform platform assumptions -- we don't |
| 17:13.32 | brlcad | unless absolutely necessary, or some other really good justification |
| 17:13.48 | brlcad | I guess I'd have to see an example where you think it's needed |
| 17:13.59 | clock_ | unless relatively necessary? |
| 17:14.17 | brlcad | as it almost never really is, even when you're using 3rd party libs that make the assumptions |
| 17:14.24 | clock_ | I just found one thing in my code which doesn't work properly because it wasn't implemented |
| 17:14.33 | clock_ | Things seem to work somewhat better when they are implemented |
| 17:14.33 | mafm | well, the one that I explained is |
| 17:14.43 | mafm | RBGui does those assumptions |
| 17:14.54 | clock_ | brlcad: do you know Spanish? |
| 17:15.30 | mafm | clock_: it depends on the programmer, though |
| 17:15.37 | clock_ | brlcad: I have to finish the BRL-CAD film, not because I should, but because it gives me a nice famililar feeling, unlike say, going wakeboarding |
| 17:18.20 | *** join/#brlcad prasad1 (n=psilva@static-70-108-244-218.res.east.verizon.net) |
| 17:23.23 | brlcad | mafm: yes, I understand that rbgui makes those assumptions but that has nothing to do with your use and an actual problem encountered codewise |
| 17:23.41 | brlcad | clock_: si |
| 17:24.09 | clock_ | brlcad: is spanish complicate language to learn? |
| 17:24.29 | brlcad | not really, very nicely structured language, not too many irregular rules |
| 17:24.40 | clock_ | brlcad: does it have flexion like german? |
| 17:25.10 | *** join/#brlcad andrecastelo (n=chatzill@189.71.51.90) |
| 17:25.34 | mafm | well, the only thing that I need at the moment about platforms is that |
| 17:25.41 | andrecastelo | hi guys |
| 17:25.45 | mafm | the rest of my code doesn't need anything special |
| 17:25.47 | mafm | hi andrecastelo |
| 17:26.22 | brlcad | mafm: then let me be more specific, because we're not getting to the point it seems |
| 17:26.30 | brlcad | what makes you say you need it? |
| 17:26.33 | brlcad | specifically |
| 17:28.13 | mafm | brlcad: http://rafb.net/p/1EsPdG86.html -- this piece of code |
| 17:30.17 | brlcad | okay, that's more concrete, so rbgui has broken out some level of interface by platform (and cursor (input?) control) into headers and those in turn imply some set of functionality7 |
| 17:30.45 | brlcad | what does posix actually mean to them? |
| 17:31.16 | brlcad | as macs are posix compliant as are some portions of windows even with the right settings |
| 17:31.25 | mafm | the cursor bit is to disable the regular cursor when you're inside the GL window |
| 17:31.44 | brlcad | okay, why does only WIN32 do that? |
| 17:32.47 | mafm | I'm not sure of the details yet |
| 17:32.53 | brlcad | k |
| 17:32.59 | brlcad | so back to the example |
| 17:33.02 | mafm | in example the POSIX thing is mostly empty |
| 17:33.19 | mafm | that's why the auto-repeat with keyboard wasn't working, in example |
| 17:33.55 | brlcad | in that particular case with those headers, the usual way would be to break out the interface per platform per file, so you can push the platform type up into the build system |
| 17:34.13 | clock_ | erbbut cygwin isn't posix compliant even in places where they claim to |
| 17:34.15 | brlcad | so on windows, you build the windows sources |
| 17:34.36 | brlcad | and the file would be limited to exactly just what is needed to encapsulate rbgui's concept of a platform |
| 17:34.58 | brlcad | otherwise it's going to cascade a need for platform types throughout the app |
| 17:37.50 | brlcad | if that snippet is from a file that is supposed to be that encapsulating wrapper and the intent is to keep it simple with just one or two files, it should still be tied to what a platform means to rbgui -- which is likely some ui featureset that could be captured with platform-centric ui tests |
| 17:38.44 | brlcad | e.g. instead of testing sytem==apple, you'd test for the IOKit framework or some other Mac framework that they require |
| 17:39.17 | brlcad | as that implicitly is tied to the platform, but is a test for the feature rbgui is assuming as part of the platform |
| 17:39.50 | mafm | sheesh |
| 17:40.22 | mafm | can I defer this for a bit later? :) |
| 17:41.43 | brlcad | except later will never come, I'd bet on it :) |
| 17:42.04 | brlcad | this is the kind of feature creep that becomes a maintenance nightmare in five to ten years |
| 17:42.49 | mafm | well yes, but RBGui looks fine and all that, but I'd like to test it more because it still can have some hard edges that prevent us from using it |
| 17:42.54 | brlcad | in the process of undoing years of that sort of propagation on the main codebase, very time-consuming and costly now -- moreso than it would have been to do it right up front |
| 17:43.31 | mafm | apart from that I want to get this running soon so everybody can test |
| 17:43.36 | brlcad | that's fair enough, though it should be decided by the midpoint if it's to be used |
| 17:43.56 | brlcad | then make a TODO entry with that at the top |
| 17:44.08 | brlcad | it needs to be done (during gsoc) if rbgui is going to stay |
| 17:47.04 | mafm | oki |
| 17:59.20 | mafm | can I pass some variable (data directory) when compiling? kind of g++ -DDATA_DIR=path... |
| 17:59.49 | mafm | or only the symbol can be defined (DATA_DIR) but no content, as is usually the case with DEBUG and the like? |
| 18:00.02 | mafm | I can't get examples with google :S |
| 18:14.53 | CIA-22 | BRL-CAD: 03starseeker * r31430 10/brlcad/trunk/doc/docbook/oed/oed.xml: Add some tweaks suggested by Paul tanenbaum, add acknowledgements. |
| 18:21.08 | brlcad | mafm: use bu_brlcad_data("data", 0); |
| 18:22.01 | brlcad | that'll give you a configure-time, compile-time, and run-time hook that can be overridden for finding resources |
| 18:22.47 | brlcad | by default, it'll find data in the current directory, if you want compile-time path, you'd define BRLCAD_DATA to your install path |
| 18:24.09 | brlcad | and to do that, it's just what you showed, a CPPFLAG of -DVAR to just "set" it and -DVAR="VALUE" to set it to a specific value |
| 18:24.58 | brlcad | e.g. -DBRLCAD_DATA=/usr/local/share/rt^3/data |
| 18:41.45 | mafm | sigh |
| 18:41.45 | CIA-22 | BRL-CAD: 03starseeker * r31431 10/brlcad/trunk/ (23 files in 5 dirs): Shift oed to tutorials subdirectory |
| 18:41.58 | mafm | OGRE is segfaulting now and I don't know why |
| 18:52.00 | mafm | yay, now it works \o/ |
| 19:00.30 | CIA-22 | BRL-CAD: 03starseeker * r31432 10/brlcad/trunk/doc/docbook/ (book/ book/README book/book.xml catalog.xml): Add test book file which demonstrates method of combining documents to make a new document - technique testing ONLY at this point |
| 19:01.27 | brlcad | woot! |
| 19:09.15 | mafm | brlcad: what's the mime type for ttf? they don't have an own type |
| 19:09.27 | mafm | application/x-font is for others |
| 19:09.35 | mafm | application/x-font pfa pfb gsf pcf pcf.Z |
| 19:13.09 | brlcad | mm, checking |
| 19:13.40 | *** join/#brlcad Elperion (n=Bary@p5B14FA2E.dip.t-dialin.net) |
| 19:15.37 | brlcad | looks like it's just application/octet-stream |
| 19:15.49 | brlcad | there is nothing official registered from what I can see |
| 19:17.46 | mafm | yep |
| 19:18.00 | CIA-22 | BRL-CAD: 03mafm * r31433 10/rt^3/trunk/data/g3d/RBGui/ (59 files in 7 dirs): Submitting data for RBGui (fonts, decorations, shaders...) |
| 19:18.05 | brlcad | adds .ttf to the sample |
| 19:20.39 | mafm | good |
| 19:21.14 | brlcad | andrecastelo: finally testing rtarea, nice work on the surface :) |
| 19:21.22 | brlcad | now to just figure out why it doesn't actually work :) |
| 19:26.14 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177871429.dsl.bell.ca) |
| 19:27.26 | IriX64 | http://rafb.net/p/jZlpIy41.html |
| 19:27.43 | IriX64 | cheers :) |
| 19:27.46 | *** part/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177871429.dsl.bell.ca) |
| 19:30.55 | brlcad | one of only a handful of people that really make me wish there was a way I could reach through their monitors to slap them |
| 19:32.17 | starseeker | heh |
| 19:37.10 | starseeker | wonders why subversion doesn't check mime types BEFORE uploading all the file data (and then throwing it out when it doesn't like something) |
| 19:41.58 | CIA-22 | BRL-CAD: 03mafm * r31434 10/rt^3/trunk/src/g3d/ (Application.cxx CMakeLists.txt): Making it work with CMake in a relatively clean fashion. |
| 19:48.35 | mafm | brlcad: do you happen to have the rest of the libraries working (OGRE, RBGui...)? |
| 19:48.43 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177871429.dsl.bell.ca) |
| 19:48.54 | *** part/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177871429.dsl.bell.ca) |
| 20:01.35 | brlcad | starseeker: put in a feature request :) |
| 20:02.04 | brlcad | course the answer is probably because it's a post-commit-hook instead of a pre-commit-hook |
| 20:02.12 | brlcad | and we have no (easy) control over that |
| 20:02.30 | brlcad | mafm: nope |
| 20:02.40 | mafm | I see |
| 20:02.43 | brlcad | was waiting for you to give the thumbs up :) |
| 20:02.50 | brlcad | when it's integrated cleanly |
| 20:03.22 | mafm | cleanly it is -- but you have to have them installed :D |
| 20:03.23 | brlcad | I'm itching to try it |
| 20:20.01 | starseeker | whips out his Quake railgun and starts blasting away at mime types |
| 20:22.00 | CIA-22 | BRL-CAD: 03starseeker * r31435 10/brlcad/trunk/doc/docbook/resources/ (37 files in 4 dirs): Add docbook dtd files |
| 20:29.54 | mafm | I go now |
| 20:29.57 | mafm | bye |
| 20:41.13 | *** join/#brlcad thing0 (n=ric@58.171.232.19) |
| 20:54.07 | *** join/#brlcad andrecastelo (n=chatzill@189.71.51.90) |
| 20:54.28 | andrecastelo | hi again |
| 20:54.55 | andrecastelo | brlcad: sorry, had to leave earlier.. rtarea is outputting wrong info ? |
| 20:57.17 | brlcad | al zeros |
| 20:57.58 | brlcad | should also probably be a separate section for formatting compatibility |
| 20:58.20 | brlcad | rtarea could use some formatting love like starseeker added to nirt |
| 21:02.20 | CIA-22 | BRL-CAD: 03starseeker * r31436 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (. VERSION): Add xsl directory - do this piecemeal so it actually works. |
| 21:04.03 | CIA-22 | BRL-CAD: 03starseeker * r31437 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (13 files): Add rest of top level xsl files |
| 21:05.55 | CIA-22 | BRL-CAD: 03starseeker * r31438 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (101 files in 3 dirs): Add rest common, docsrc, eclipse |
| 21:13.53 | CIA-22 | BRL-CAD: 03starseeker * r31439 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (425 files in 20 dirs): Add epub, extensions, fo |
| 21:16.00 | CIA-22 | BRL-CAD: 03starseeker * r31440 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (76 files in 3 dirs): Add highlighting, html, htmlhelp |
| 21:17.38 | CIA-22 | BRL-CAD: 03starseeker * r31441 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (126 files in 5 dirs): Add images javahelp lib manpages |
| 21:23.05 | CIA-22 | BRL-CAD: 03starseeker * r31442 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (784 files in 16 dirs): Add params profiling roundtrip slides |
| 21:26.59 | CIA-22 | BRL-CAD: 03starseeker * r31443 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (140 files in 5 dirs): add template tests website xhtml xhtml-1_1 |
| 22:14.12 | CIA-22 | BRL-CAD: 03andrecastelo * r31444 10/brlcad/trunk/src/rt/viewmlt.c: Added more headers and removed some extern declarations. Added file writing in view_pixel(), based on rt's view_pixel() as suggested by ``Erik. |
| 22:15.45 | CIA-22 | BRL-CAD: 03pacman87 * r31445 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c: general efficiency improvements; remove unnecessary debug logging code |
| 22:16.57 | pacman87 | rt is ~6% faster now |
| 23:29.50 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) |