| 00:39.04 | yukonbob | CIA-4: up-and-running? |
| 00:40.13 | yukonbob | starseeker: we're going to have to talk (maybe w/ brlcad) how we want to organize images. |
| 00:51.40 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 01:07.00 | brlcad | yukonbob: nice! |
| 01:07.28 | brlcad | seems to be getting stuck a lot today |
| 01:12.09 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 01:19.49 | yukonbob | brlcad: thx -- I'm pretty happy w/ it -- now i need to clean references (ie: remove "hard notes" and make a proper bibliograpy) and cleanup the title page/authors/dedications, etc... otherwise, I bet (and hope) it's only minor issues that we'll want to fix. |
| 01:21.04 | yukonbob | ...and fix images. |
| 01:21.46 | yukonbob | but I've got references in all the right places to grab what's necessary once I have copies of the proper images. |
| 01:24.13 | yukonbob | brlcad: how do you build docbook XML -> pdf? I use openjade/jadetex/dvipdf -- if you run a diff't setup, I'd be curious to see the resultant pdf. (test_img.ps is a random 236x200 img) |
| 01:24.52 | starseeker | brlcad - very nice!! |
| 01:24.56 | starseeker | er yukonbob |
| 01:25.39 | yukonbob | :) |
| 01:26.33 | yukonbob | regarding images -- I guess we could just create an "img" directory and pull from that? Unless it's going to be too problematic pulling all the images from a single dir... but I doubt it will be... comments? |
| 01:28.03 | starseeker | I think that makes sense - I would like to have some kind of sensible naming convention for images, but that's probably not possible until the final organization is done |
| 01:28.20 | starseeker | brlcad had some ideas about how he wanted to re-org things, but we're a ways from that |
| 01:36.23 | brlcad | yeah, dealing with images is always a stickler, no matter the format |
| 01:37.17 | brlcad | inclination would be a global 'images' directory, though per-dir images or just putting images in the dir with their respective xml could work too |
| 01:37.59 | brlcad | it gets trickier when you want to reuse images in multiple places, assuming some sort of hierarchical organization to the documentation, with data in multiple places |
| 01:39.01 | brlcad | thinking of them as source files helps, you often just end up with a data resources directory where the images and other "loaded" resources are kept that the source files refer to (which are docbook files in this case, global entity refs) |
| 01:42.26 | yukonbob | ...or just a single global img dir, as I think about it... |
| 01:42.51 | brlcad | hm, I'd rather shove the non-production stuff into the website -- the holy grail would be to get mediawiki to docbook working as well as docbook to mediawiki so files could be edited either on the wiki or directly, and have the changes tracked and propagated |
| 01:43.21 | brlcad | other files will grow the source tarballs exceptionally fast, as well as the revision root files |
| 01:43.44 | yukonbob | makes sense -- in that case, everything in the repos. will be "production". |
| 01:44.00 | brlcad | we used to have the pdfs in cvs before going open source, with many revisions of each.. well over a gb of relatively "useless" data |
| 01:44.19 | starseeker | ouch |
| 01:44.52 | brlcad | starseeker: I think at least for now, wiki spam woes aren't really a concern |
| 01:45.04 | starseeker | OK :-) |
| 01:45.31 | brlcad | the measures we have in place in bz have worked exceptionally well (like one incident a month at best), and that gets massive exposure |
| 01:45.41 | starseeker | Very nice! |
| 01:46.02 | starseeker | we should probably look at that - the measures Bill ultimately put in place on Axiom have proved rather unfriendly |
| 01:46.05 | brlcad | we used to have major major problems, but after trying a dozen different things, we seem to have it sorted out |
| 01:46.14 | starseeker | cool |
| 01:46.21 | brlcad | we even were able to retain anonymous edits |
| 01:46.33 | yukonbob | ! |
| 01:47.25 | brlcad | recaptcha alone did wonders to thwart almost all of the automated stuff, though there's also a blacklisting in place as well as a few other measures |
| 01:47.44 | yukonbob | good to know... |
| 01:48.26 | brlcad | we'd gone through about 5 captcha systems before it, all useless |
| 01:48.57 | brlcad | even having people answer questions while helpful, didn't mitigate everything |
| 01:49.22 | brlcad | yukonbob: sure .. the difference is about 2 billion dollars a year ;-) |
| 01:49.43 | starseeker | Cool! I saw the recaptcha thing go by on slashdot, and it sounded like a really good idea |
| 01:50.11 | brlcad | not only is the idea good, the captcha itself that they use is pretty much one of the best so far |
| 01:50.28 | brlcad | could just be a matter of time for someone to reliably "crack it" |
| 01:51.06 | starseeker | Well, at the very least it will force someone to invent some really good OCR algorithms ;-) |
| 01:52.40 | yukonbob | brlcad: re: solidworks -- is that about it? /me sees buzzwords like "parametric feature-based" -- is it basically that they handle edits a bit different? |
| 01:57.17 | yukonbob | I guess that's another difference between solidworks and brlcad |
| 01:59.33 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096600612.dsl.bell.ca) |
| 02:00.15 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/xsystem.png :) |
| 02:00.16 | brlcad | solidworks is one of the "big four" (unigraphics/nx, catia, solidworks, and pro/engineer) solid modeling systems, all 1bn+ gross revenue businesses |
| 02:00.16 | starseeker | Humph - correct me if I'm wrong, but did they just patent sub-component searching of data objects? http://www.google.com/patents?id=L6B6AAAAEBAJ&dq=Solidworks |
| 02:00.46 | IriX64 | sorry |
| 02:00.49 | brlcad | cumulatively, those four are about the domain of autodesk/autocad |
| 02:01.04 | brlcad | just focusing in the drafting and 2d design sectors |
| 02:01.44 | yukonbob | IriX64: show us the models _you_ make :) |
| 02:01.47 | brlcad | yukonbob: there are plenty of other differences, the biggest is probably the support for parametric surfaces and feature edits |
| 02:02.21 | IriX64 | yukonbob: you would cower in fear at the sight ;) |
| 02:02.49 | yukonbob | brlcad: /me doesn't even know defintion of parametric, but any kinds of edits are w/i the realm of brl-cad... |
| 02:03.05 | brlcad | parametric surfaces very closely relate to having brep spline surface support, something we're just now getting added -- with several manyears of effort invested, there's still a LOT to do |
| 02:03.48 | yukonbob | ?tough science (ie: seperate from implementing in code) |
| 02:03.52 | brlcad | right now, i'm just talking about fundamental representation support, what that turns into with respect to a GUI and generalized editing user interface is yet another level of work and complexity on top of the representation |
| 02:04.25 | brlcad | some of it is exceptionally hard (mathematically and algorithmic), some of it is grunt coding ;) |
| 02:04.42 | starseeker | ooo - math :-) |
| 02:05.26 | starseeker | Trimmed NURBs? |
| 02:05.50 | brlcad | even with some of the best education and experience, some of the implementation details are simply trade secrets that aren't readily published or available in quality formats, so you are basically doing computer graphics research just to get things working |
| 02:06.10 | starseeker | Indeed. |
| 02:07.07 | starseeker | brlcad; Is this a reasonable introduction to some of the surface representation ideas? http://iit-iti.nrc-cnrc.gc.ca/iit-publications-iti/docs/NRC-45828.pdf |
| 02:08.35 | brlcad | the other "difference" that largely stems from the size and complexity of the domain is that you can mean so many things when you say CAD (from 2D to 3D to 4D to parametric to implicit to explicit to drafting, machining, manufacturing, analysis, designing, and then some) .. the needs are so vast that the tools generally are written to be this massive bag of tricks with relatively complex interfaces that take a while to learn |
| 02:09.04 | brlcad | mged's really no more complex to learn, it just beats you up during the process on top of all you're trying to learn :) |
| 02:09.50 | starseeker | separates the men from the boys ;-) |
| 02:10.02 | starseeker | (or women from the girls as the case may be...) |
| 02:10.12 | brlcad | yukonbob: I don't mind it either, but then it generally only beats you once .. once you know, you know and it's efficient ;) |
| 02:10.58 | brlcad | i do mind that it's hard for some folks that really do try to learn it, but then fail to find the information they need -- you have to really look at the source code or find an existing expert |
| 02:11.09 | yukonbob | brlcad: indeed -- it does what's necessary (reads a line of input) and gets out of the way ;) |
| 02:11.48 | brlcad | starseeker: not really, that's just a paper on tessellating nurbs surfaces -- a good one, but not as an overview of surface representations |
| 02:12.03 | yukonbob | well, this documentation rewrite will hopefully get the docs "out there" more, and the new website might spawn a new community, faq, wiki, etc. |
| 02:12.29 | starseeker | brlcad: Ah. Are there good "standard" introductory papers on the topic? |
| 02:12.32 | brlcad | I've got some really great pictures that show some of the basic differences that I've prepared for various presentations that work pretty well for explaining it -- I'll see if I have release authority on them next week |
| 02:12.40 | starseeker | cool :-) |
| 02:13.30 | brlcad | that tessellation of nurbs surfaces is actually one of the critical steps needed for fully multi-rep systems ... :) |
| 02:14.16 | brlcad | now that we have the structure working with ray-tracing (minus some acne issues), the next step is tessellation, CSG evaluation of NURBS, and then implicit to BREP conversions |
| 02:14.32 | yukonbob | starseeker: brlcad and I were discussing shooting rays and how alien lasers could be modelled on earth equip to see strength/weaknesses |
| 02:15.21 | brlcad | to give you an idea of what that translates to in code, that paper basically boils down to the guts implementation of src/librt/g_brep.cpp's rt_brep_tess() function |
| 02:15.37 | brlcad | which presently just returns -1 ;) |
| 02:15.42 | starseeker | LOL |
| 02:15.51 | yukonbob | ?not 42 |
| 02:16.19 | IriX64 | thats only half the answer the whole answer is 84 |
| 02:16.24 | IriX64 | :) |
| 02:16.49 | starseeker | (digest-paper 'NRC-45828) -> -1 Error: paper contains nothing useful ;-) |
| 02:16.54 | yukonbob | IriX64: show us some models!! |
| 02:16.57 | brlcad | there are actually a handful of instances of 42 in the sources ;) |
| 02:17.45 | brlcad | IriX64: did you ever get Jamie to attach the brl-cad headers to that hex.c program? |
| 02:18.40 | starseeker | yukonbob: I'd have to say lasers are cool, but in atmosphere I'd vote for the mini-railgun on a tank :-) |
| 02:18.50 | brlcad | if you're working on something here and run across a paper that isn't free that you need, just lemme know |
| 02:19.04 | starseeker | brlcad: Thanks! |
| 02:19.22 | starseeker | Is there a "global CAD bibliography" in the brlcad tree somewhere? |
| 02:20.43 | brlcad | i've started one offline, but no not really |
| 02:21.11 | brlcad | that was one of the things for the new website, I've got a few dozen publications that refer to, use, or relate to BRL-CAD that are relevant |
| 02:21.21 | starseeker | Ah :-) |
| 02:23.50 | brlcad | there's a mini bibliography in the AUTHORS file .. that really doesn't belong there, but has a few items |
| 02:24.00 | brlcad | at the end |
| 02:25.47 | starseeker | OK :-) |
| 02:27.41 | starseeker | brlcad: Has anyone in the BRL-CAD project ever looked at the VTK toolkit? |
| 02:28.26 | brlcad | oh yeah |
| 02:28.41 | brlcad | pretty heavily for a while |
| 02:29.11 | brlcad | http://ogigi.polsl.pl/biuletyny/zeszyt_14/z14cz3_6.pdf isn't too shabby, it at least mentions many of the formats and issues albeit a bit biased |
| 02:29.17 | starseeker | How bad is the impedance mismatch between the API of the toolkit and what brl-cad needs? |
| 02:29.33 | brlcad | volumetric, parametric, implicit, explicit, brep, and nurbs at a glance |
| 02:30.09 | starseeker | Cool - thanks! |
| 02:32.33 | brlcad | ah, almost forgot about mike's old writeup -- http://ftp.arl.army.mil/~mike/papers/90nmg/joined.html |
| 02:33.03 | starseeker | excellent! |
| 02:33.18 | brlcad | starseeker: yeah, the question of interface and environments has been long-discussed and worked on |
| 02:33.32 | brlcad | particularly for building a new interactive modeler |
| 02:34.15 | brlcad | the brief summary is that all the non-commercial options we're stuck with pretty much are all inadequate or outright suck to various degrees of suckage :) |
| 02:34.16 | starseeker | Did a consensus emerge? |
| 02:34.22 | starseeker | ah :-) |
| 02:34.31 | starseeker | even VTK? nuts |
| 02:34.42 | brlcad | there are some workable options, a handful really |
| 02:35.34 | brlcad | VTK has some very nice aspects, and several downsides |
| 02:36.23 | brlcad | part of it (and not to their faulting) is that the biggest issue/debate is really that of the user interface itself, for which VTK doesn't really directly address |
| 02:37.08 | starseeker | Ah |
| 02:39.10 | starseeker | No wonder Paraview isn't much help then - it is solving a different UI problem (or maybe a small subset of it, depending) |
| 02:39.32 | brlcad | there's your windowing environment (think difference between windowed and full-screen), the graphics context (think opengl and quartz and framebuffers), the GUI elements (think gtk/qt, wxwidgets, cegui, blenderui, etc), and the UI methodologies (think modalities, MDI, custom behaviors, etc) |
| 02:39.56 | starseeker | Ah yes. |
| 02:40.23 | brlcad | VTK is fairly situated around the graphics context layer only |
| 02:40.28 | starseeker | right |
| 02:40.58 | starseeker | the GUI elements are probably the biggest issue, particularly given the portability ambitions of BRL-CAD... |
| 02:41.13 | brlcad | something like SDL does windowing, context, and some minor UI methodology |
| 02:41.47 | starseeker | The only library I've ever seen that attempted to paper over ALL GUI element environments was the Lisp CLIM project, which isn't mature and is in the wrong language anyway... |
| 02:42.26 | brlcad | it's not that you want something that does them all, but it's good to recognize what pieces are still missing and what problems are being solved |
| 02:42.44 | brlcad | the first two are fairly easy to get set up and are rarely a bottleneck unless you mess something up big |
| 02:43.03 | brlcad | VTK becomes a pressing need when the context is the bottleneck |
| 02:43.19 | brlcad | or something like it, as it deals with the data management aspects well |
| 02:43.25 | starseeker | OK. |
| 02:43.26 | brlcad | as does something like OpenSceneGraph |
| 02:44.05 | brlcad | OGRE is in a similar boat but then of course being a render engine has nothing to do with GUI so you still need a GUI toolkit |
| 02:45.18 | starseeker | IIRC Blender sidestepped the UI kit by writing their own in GL or some such? |
| 02:45.24 | brlcad | deciding on your UI methodologies is a tricky (religious) topic but is at least something we can probably pin down in our domain |
| 02:45.40 | brlcad | yes, they wrote their own UI toolkit |
| 02:45.45 | starseeker | ouch |
| 02:45.47 | brlcad | which has been both a major blessing and major curse :) |
| 02:46.37 | starseeker | As for MDI related issues - isn't that something that can ultimately be user configurable if the right design decisions are made? (The Gimp non-withstanding...) |
| 02:46.40 | brlcad | it kept them really agile in the early days, and made for a nice scalable opengl interface that looks the same everywhere |
| 02:47.03 | brlcad | sometimes it can, sometimes it's pretty fundamental |
| 02:47.12 | starseeker | Hmm. |
| 02:47.33 | brlcad | e.g. mged is pretty heavily multi-windowed .. some of the major windows can be combined but there are still a slew of independent dialogs and tool panels |
| 02:47.50 | starseeker | True |
| 02:47.53 | brlcad | that was a design decision for better or worse that impacts the usability, feel, and appeal |
| 02:48.25 | brlcad | solidworks is pretty much a one-window interface with most of the content interlayed into the 3D scene |
| 02:49.14 | starseeker | Sounds like something a workflow analysis would be good for |
| 02:49.20 | brlcad | unigraphics is totally different (and probably one of the best at being modeless) |
| 02:50.36 | starseeker | Wow. |
| 02:51.21 | brlcad | In designing the new interface for our modeler, I've always had a particular vision of configurable usability that I think is a good blend of some of the best ideas out there, taking a key from probably the most successful interface makers in the industry |
| 02:52.45 | brlcad | WWAGD .. "what would a game do" .. the gaming industry has by far put the most research and iteration redesign into effective interfaces over the last decade |
| 02:53.06 | starseeker | that's a point, definitely |
| 02:53.13 | brlcad | they have to grab the users attention, teach them sometimes utterly complex interfaces and do so quickly and make them actually enjoy it |
| 02:54.42 | brlcad | that single approach alone drives a lot of the decisions of what I've had in mind, something that makes CAD appealing, that is straightforward to code with regards to design decisions, and is outright enjoyable |
| 02:54.54 | brlcad | without actually making it a game of course :) |
| 02:55.16 | starseeker | hehe |
| 02:55.17 | yukonbob | no flight-sim easter egg? |
| 02:55.22 | brlcad | mebbie :) |
| 02:55.37 | brlcad | a tank sim would be more apropriate given our history :) |
| 02:55.54 | starseeker | when the newbie crashes, BRL-CAD would take them through a crash simulation in full detail ;-) |
| 02:56.22 | starseeker | BZflag - now with solid model damage simulation |
| 02:56.49 | brlcad | that's not far from what we do already in the analysis domain ;) |
| 02:57.08 | yukonbob | embed bzflag... |
| 02:57.17 | brlcad | (with the analysis codes hooking into brl-cad for geometry interrogation and representation) |
| 02:57.39 | starseeker | neat |
| 03:01.55 | yukonbob | chat later, starseeker |
| 03:05.55 | brlcad | cya |
| 03:29.41 | *** part/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096600612.dsl.bell.ca) |
| 05:55.28 | yukonbob | brlcad: re: coverity -- do I talk to you to talk to coverity for access to their analysis? |
| 07:16.59 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) |
| 07:49.14 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-097-151.pools.arcor-ip.net) |
| 09:03.09 | *** join/#brlcad Elperion (n=Bary@p5487560B.dip.t-dialin.net) |
| 09:10.17 | *** join/#brlcad AchiestDragon (n=david@whipy.demon.co.uk) |
| 11:07.07 | *** join/#brlcad AchiestDragon (n=david@whipy.demon.co.uk) |
| 11:45.36 | *** join/#brlcad elite01 (n=elite01@p5489C945.dip.t-dialin.net) |
| 13:25.46 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-097-151.pools.arcor-ip.net) |
| 14:00.32 | *** join/#brlcad elite01_ (n=elite01@dslb-088-070-113-255.pools.arcor-ip.net) |
| 14:51.35 | *** join/#brlcad Elperion (n=Bary@p5487560B.dip.t-dialin.net) |
| 15:36.49 | ``Erik | <PROTECTED> |
| 15:37.41 | ``Erik | heh, 3.5 years ago, a modified version of bzflag using BRL-CAD models and real vulnerability code was seriously discussed O.o |
| 15:44.08 | santorum | bzflag is a game somehow connected to BRL-CAD? |
| 15:46.40 | minute | In a very convoluted way, yes. |
| 15:49.33 | ``Erik | brlcad is a major developer on both |
| 15:50.11 | ``Erik | and BRL-CAD was/is primarily developed (on tax dollars, anyways) for doing simulations on army armored vehicles... :) like, y'know, tanks, 'n stuff |
| 15:50.49 | santorum | and to make models of Ronja |
| 15:51.01 | santorum | at least the tax money are used in a partially useful way |
| 15:53.30 | ``Erik | meh, the funding avenue that BRL-CAD is part of saves metric assloads of money, and I think BRL-CAD is one of the most useful bits of the pipeline... *shrug* one of the least fucked up, anyways :D I mean, c'mon, free to the world! |
| 15:54.09 | ``Erik | probably the second most used thing I have a commit bit for (OpenAL is probably more used) |
| 15:54.44 | ``Erik | <-- still hasn't gotten a fbsd bit :D |
| 15:56.48 | santorum | we're still waiting for open source nukes... |
| 15:57.38 | santorum | he, surfers! Why read all those weather charts? Download our open source nuke manual, put together couple of them in your garage, dump them into the sea, shoot and you'll have great waves! |
| 16:01.08 | santorum | How programming works: |
| 16:01.10 | Maloeran | Ouch. Perhaps if you want to surf with a whole aircraft carrier |
| 16:01.12 | santorum | 1) start with empty program |
| 16:01.22 | santorum | 2) debug until you have desired functionality properly working |
| 16:01.48 | santorum | but the tubes must be impressive |
| 16:04.30 | archivist | going to need a tsunami for that |
| 16:05.06 | santorum | actually have you heard about solitons? |
| 16:05.30 | Maloeran | Some kind of stable wave? |
| 16:05.34 | santorum | yes |
| 16:05.49 | santorum | they found it when a large boat abruptly stopped in a narrow canal in England |
| 16:05.58 | santorum | and that created a wave that smoothly ran along the canal |
| 16:06.11 | santorum | wihtout actually undulating, falling apart or anything like that |
| 16:06.17 | santorum | diminishing only very slowly |
| 16:06.34 | Maloeran | There must still be some serious loss of energy due to viscosity |
| 16:06.42 | santorum | Do you think these solitons could be made easily surfable? |
| 16:06.43 | archivist | traveling behind a ship on a canal is fun |
| 16:07.09 | santorum | cause one could take some old railway tunnel, fill it with water and send solitons down the tunnel |
| 16:07.14 | santorum | it would be like a winter surf park :) |
| 16:07.24 | Maloeran | By the dynamics involved in a surf wave, I would say there's a big loss of kinetic energy there, I don't think it could be very stable |
| 16:07.50 | santorum | what about making it high but just before it starts making whitewater? |
| 16:07.53 | archivist | surfer takes the energy out |
| 16:07.54 | santorum | So it runs smoothly |
| 16:08.05 | santorum | sure |
| 16:09.06 | ``Erik | them crew boys are odd http://www.collegehumor.com/picture:14316 |
| 16:11.33 | ``Erik | almost as odd as canucks http://www.collegehumor.com/picture:15608 |
| 16:11.34 | ``Erik | :D |
| 16:12.21 | santorum | http://www.vcharkarn.com/vphysics/pictures/A273p1x1.jpg |
| 16:12.24 | archivist | http://www.nickscipio.com/funstuff/archive10/2005-09-06_motorcycleass.html |
| 16:25.53 | *** join/#brlcad thing0 (n=ric@203-59-92-48.dyn.iinet.net.au) |
| 16:28.16 | brlcad | yukonbob: yes, I've talked to the coverity folks |
| 16:28.45 | brlcad | they actually set us up with a free scan a few months ago.. the scan was only partial though as something in their setup failed -- it's not been updated/changed since |
| 16:28.57 | brlcad | I pinged them on the status a few weeks ago, but have yet to hear a response yet |
| 16:31.04 | brlcad | santorum: working on bzflag is one of my other passions, I'm one of the core devs, leading contributor, project admin, yada yada .. good stuff. it's a nice diversion and different style of coding environment (with exceptionally different user base of course) |
| 16:49.16 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/librt/Makefile.am: use RT_LIBS since we need libbu and other libs that are missing. hopefully helps with unresolved symbols on ubuntu, but there's probably more cases like this that need fixing. |
| 16:55.03 | yukonbob | brlcad: cool -- I'd be interested in reviewing the brl-cad code as marked by coverity once you hear back from them... |
| 16:58.18 | ``Erik | heh, join the club :) until then, use shtuff like 'flawfinder' |
| 16:58.59 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-113-255.pools.arcor-ip.net) |
| 16:59.42 | minute | brlcad: The pdfs, are they all going to be transfered to some over format then archived somewhere other than the wiki (i.e. deleted from the wiki) or will they always remain on the wiki and the other format offered by default? |
| 17:13.44 | *** part/#brlcad thing0 (n=ric@203-59-92-48.dyn.iinet.net.au) |
| 18:24.58 | brlcad | yukonbob: yeah, I'm really curious to see what they find as well |
| 18:25.37 | brlcad | alas the partial they did do didn't even get to brl-cad sources, aborted early on in tcl/tk sources (they weren't ignoring src/other yet) |
| 18:26.25 | yukonbob | :P |
| 18:26.36 | brlcad | minute: good question, not sure I'd remove them from the wiki anytime soon |
| 18:26.58 | brlcad | if they were autogenerated nightly or something, then the wiki might be eventually updated to just point to the file instead of it actually being stored "in" the wiki |
| 18:27.15 | brlcad | like a standard brlcad.org/docs/ path or something |
| 18:33.48 | minute | brlcad: yeah |
| 18:34.11 | minute | sounds good |
| 18:48.29 | brlcad | we can cross that bridge when the docs are actually fully integrated into the build system and being auto-generated |
| 18:48.48 | brlcad | starseeker: with regards to toolchain, I think if you have a toolchain that works, then that's the one to start with |
| 18:48.59 | brlcad | jade seemed to be the best choice regardless |
| 18:52.48 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1096600612.dsl.bell.ca) |
| 18:54.18 | IriX64 | http://rafb.net/p/9N81gB57.html <--- this happening to anybody else? |
| 18:56.05 | IriX64 | rerunning with verbose |
| 19:06.04 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libfb/if_ogl.c: don't assume that stdout isn't being used, bu_log will likely someday be changed to log to out instead of err |
| 19:07.28 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libfb/if_wgl.c: do the same on windows, don't close our output channels |
| 19:12.25 | brlcad | IriX64: did you ever get Jamie to attach the brl-cad headers to that hex.c program? |
| 19:12.44 | *** join/#brlcad Z80-Boy (i=clock@77-56-90-137.dclient.hispeed.ch) |
| 19:12.45 | IriX64 | I was never asked |
| 19:12.56 | IriX64 | but ill pass that on |
| 19:13.12 | IriX64 | he says you do it. |
| 19:13.35 | brlcad | I can't, it's a legality matter |
| 19:13.48 | IriX64 | what should he put in |
| 19:14.01 | IriX64 | he's listening |
| 19:14.35 | IriX64 | is it in read.me? |
| 19:21.24 | IriX64 | shot myself in the foot, mea culpa :( |
| 19:37.48 | brlcad | sorry, someone stopped by |
| 19:37.53 | brlcad | see the header on any of the existing files |
| 19:38.07 | IriX64 | sure |
| 19:38.13 | brlcad | or run the sh/header.sh script |
| 19:38.20 | brlcad | that'll attach the header automatically |
| 19:38.24 | IriX64 | even better |
| 19:38.41 | IriX64 | when he does it ill post it |
| 19:38.46 | brlcad | cool |
| 19:39.02 | brlcad | please be sure to have him put his full name in there as the Author |
| 19:39.10 | IriX64 | right |
| 19:39.13 | brlcad | so he can be attributed correctly |
| 19:40.50 | brlcad | typing this on the fly, but this should be an example: http://brlcad.cvs.sourceforge.net/cvsroot/brlcad/brlcad/src/libpkg/tpkg.c |
| 19:42.10 | brlcad | ah, here we go: http://brlcad.cvs.sourceforge.net/*checkout*/brlcad/brlcad/src/libpkg/tpkg.c |
| 19:50.07 | *** join/#brlcad Elperion (n=Bary@p5487560B.dip.t-dialin.net) |
| 19:52.32 | IriX64 | thanks |
| 20:47.05 | starseeker | brlcad: OK, sounds good - yukonbob I think has had some success with the jade route |
| 20:53.04 | yukonbob | starseeker: indeed I have -- use that Makefile I sent you as a template... what kind of system are you trying to build on (ie: FreeBSD, Debian, Red Hat, Windows, MacOS X)... |
| 20:53.42 | starseeker | I'm not yet - I'm stubbornly trying to finish the markup to a valid state first ;-) Gentoo is my primary platform, so I already have jade installed |
| 20:55.26 | yukonbob | starseeker: you should consider incremental builds, so you can check to see if errors are cropping up along the way. If you need a hand retro-fitting the Makefile, or with managing the .xml file, drop a note... |
| 20:55.43 | starseeker | It's a good idea. |
| 20:56.17 | starseeker | I've just been "on a roll" and also trying to make it go faster by doing "type specific" formatting - e.g. getting all the informal tables at once |
| 20:56.49 | yukonbob | well, you know where to reach me if I can help :) |
| 20:57.18 | starseeker | Yep :-) Thanks! |
| 21:02.41 | starseeker | yukonbob: I can't recall offhand - does openjade require a TeX install? |
| 21:04.14 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libfb/Makefile.am: use FB_LIBS instead, pick up the other dependencies that are needed |
| 21:10.10 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libfb/ (if_4d.c if_X.c if_X24.c if_ogl.c if_sun.c if_wgl.c): |
| 21:10.10 | CIA-4 | BRL-CAD: BAM! .. lingering windows is now the default. it only took hundreds of |
| 21:10.10 | CIA-4 | BRL-CAD: complaints and 20 years of development. this change makes it the default for |
| 21:10.10 | CIA-4 | BRL-CAD: most of the existing active framebuffer interface types, also adding a \\t\ |
| 21:10.10 | CIA-4 | BRL-CAD: option to complement the existing \\l\ option to allow folks to obtain the |
| 21:10.13 | CIA-4 | BRL-CAD: previous behavior if needed. all this mode code really should be consolidated |
| 21:10.15 | CIA-4 | BRL-CAD: and made consistent, but that is a chore for another day. |
| 21:18.57 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: termio apparently needs TERMLIB (need to verify), and don't include the optional FB_LIBS since the Makefile.am takes care of it. optical does use/need librt; tclcad needs libfb |
| 21:19.14 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/NEWS: lingering framebuffer windows are now the default |
| 21:24.25 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/other/blt/library/.cvsignore: ignore generated pkgIndex.tcl |
| 21:24.54 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/ (10 files in 10 dirs): |
| 21:24.54 | CIA-4 | BRL-CAD: the libraries really need to libadd all of their requisite dependencies or there |
| 21:24.54 | CIA-4 | BRL-CAD: will be unresolved symbols on platforms; this isn't just a libtool issue |
| 21:24.54 | CIA-4 | BRL-CAD: (libtool needs this info). this change will hopefully help the build on a few |
| 21:24.54 | CIA-4 | BRL-CAD: other platforms, though I suspect there are still a few obscure cases (with |
| 21:24.57 | CIA-4 | BRL-CAD: buggy libtool) where unresolved symbols might be encountered with dynamic/shared |
| 21:24.59 | CIA-4 | BRL-CAD: libadd libraries not getting carried through to the linker line for binaries. |
| 21:38.19 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1096600612.dsl.bell.ca) |
| 21:46.34 | louipc | This SF.net email is sponsored by: Microsoft |
| 21:46.35 | louipc | lol |
| 21:59.56 | brlcad | heh, nice catch |
| 21:59.59 | brlcad | i didn't see that |
| 22:11.56 | archivist | the cheeky buggers managed a sqlserver google add on mysql's site once |
| 22:17.45 | brlcad | heh |
| 22:28.19 | Maloeran | I'm a bit surprised by all the advertisement from Microsoft on SF, I thought they would be a bit more picky about the ads they accept |
| 22:36.25 | CIA-4 | BRL-CAD: 03starseeker * 10brlcad/doc/book/VolumeII.xml: Markup through Lesson 10. |
| 22:39.00 | starseeker | Maloeran: Hey, if they want to fund the opposition who are we to object? ;-) |
| 22:39.41 | louipc | it's like trying to sell wheelchairs to able bodied people |
| 22:40.00 | starseeker | Pretty much ;-) |
| 22:40.29 | starseeker | I was a bit surprised to see Microsoft advertising there though |
| 22:41.06 | louipc | yeap |
| 22:41.51 | starseeker | crud, shopping list |
| 22:42.16 | starseeker | back into the maelstrom... |
| 23:22.15 | *** join/#brlcad CIA-4 (n=CIA@208.69.182.149) |
