IRC log for #brlcad on 20090301

00:14.00 brlcad PrezKennedy: what happened to osgaming.net?
00:14.18 brlcad if you need a new home, could use one of my servers
00:15.38 PrezKennedy if i recall, the moved the data somewhere else and i just never bothered to setup the site again
00:15.52 PrezKennedy i really should since it was by far the most successful thing ive worked on online
00:16.15 PrezKennedy brlcad, did you ever come up with a name for the second server?
00:22.49 brlcad nope
01:31.36 *** join/#brlcad ibot (i=ibot@rikers.org)
01:31.36 *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207)
02:34.22 Ralith osgaming.net?
02:34.25 Ralith that sounds interesting
02:45.26 Axman6 read that as orgasming.net
03:43.45 yukonbob evening, cadheads :)
03:44.27 yukonbob ?is there a brlcad entry for gsoc2009?
05:44.08 PrezKennedy haha nice one Axman6
05:44.30 Axman6 heh, i love #brl-cad lag XD
06:49.15 brlcad yukonbob: not yet, applications haven't opened yet
06:49.42 yukonbob hey brlcad
06:49.47 brlcad hey
06:50.10 yukonbob thought they closed in start of March (but I haven't been following closely :P)
06:50.26 yukonbob brlcad: is there an "idea sheet" for BRLCAD submission-possibilities?
06:51.55 yukonbob brlcad: also, see my note earlier re: itcl/tcl8.6? Full intergration of itcl w/ 8.6 release!
06:52.09 yukonbob (dunno if you already knew; I just found out yesterday)
06:58.44 brlcad yukonbob: http://brlcad.org/~sean/ideas.html is always a good staring point
06:59.07 brlcad the best ideas come from the students directly often
06:59.08 yukonbob also sees applications == Mar 9-13
06:59.28 brlcad yes
06:59.42 yukonbob brlcad: Are there plans for participation this year, plans to not participate, or simply no plans (yet)?
06:59.59 brlcad the 2008 list is still relevant if we participate
07:01.10 brlcad still not time to decide but probably applying at least, just maybe fewer slots
07:01.21 brlcad not that it's relevant to the program
07:03.08 yukonbob right s/participate/apply/
09:32.51 *** join/#brlcad _sushi_ (n=_sushi_@77-58-236-47.dclient.hispeed.ch)
10:03.49 alex_joni brlcad: I notice you have Adobe 3D PDF exporte on the list
10:04.13 alex_joni basicly the things in the 3D PDF are U3D's (which are further down the list)
10:05.13 alex_joni I managed to create U3D's with meshlab, and embed them into a pdf from latex + Movie15 package
10:06.18 alex_joni the conversion Meshlab does is using the sample IDTF converter provided with the sample U3D library (http://sourceforge.net/projects/u3d)
10:11.49 *** join/#brlcad ibot (i=ibot@rikers.org)
10:11.49 *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207)
10:57.19 *** join/#brlcad elite01 (n=omg@cl-213.dus-01.de.sixxs.net)
14:23.54 *** join/#brlcad Elrohir (n=kvirc@p5B14DC61.dip.t-dialin.net)
14:29.39 *** join/#brlcad ibot (i=ibot@rikers.org)
14:29.39 *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207)
15:08.02 brlcad alex_joni: *nod*
15:08.08 brlcad sounds like two birds with one stone :)
15:14.29 brlcad from our toolchain perspective, there are a lot of integration issues that would have to be sorted out
15:28.35 brlcad having a g-u3d and/or a g-pdf exporter, a u3d-g importer .. the g-pdf in particular would be tricky given the current 'path' involves latex+movie15 and how that could be achieved programmatically
16:30.24 *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net)
16:45.35 brlcad hi samrose
16:46.24 samrose hey brlcad
16:47.08 samrose opensourceecology is interested in learning brlcad. ultimately, interested in extending it and making easy to use
16:47.27 samrose any suggestions for learning brlcad?
16:47.42 samrose some of the non-programmers are finding it extremely tough
16:52.12 *** join/#brlcad bitminer (n=bitminer@h96-60-82-113.vrnawi.dsl.dynamic.tds.net)
16:52.24 samrose we are going to also document our learning
16:52.25 samrose as we go
16:52.29 samrose on brlcad
17:13.37 brlcad samrose: *nod*
17:13.57 brlcad one of our biggest (specific) long-term goals is making brl-cad a lot easier to use
17:14.07 samrose maybe I'll also make some screencasts
17:15.14 brlcad there are lots of ways folks can help make brl-cad easier to use
17:15.24 samrose I am trying to convince http://openfarmtech.org/index.php?title=Main_Page (open source ecology) that despite difficulty, that learning brl-cad will be worth the investment. I am creating a foundation in march, and interested in investing in developing brl-cad
17:15.26 brlcad there is a massive documentation project under way that you could help out with
17:15.48 brlcad that sounds fantastic
17:15.57 samrose we will see if we can figure out a way to combine that with existing workflows
17:16.09 samrose where id documentation project happening at?
17:16.18 brlcad here
17:16.36 samrose this one http://brlcad.org/
17:16.37 samrose ?
17:16.38 brlcad starseeker is the lead on that effort, there are various tasks and pieces involved
17:16.49 samrose here on IRC channel too, eh?
17:17.43 samrose also, many emerging fablab projects could participate, if we could find a way to help them do so while they are working on what they are working on
17:17.48 brlcad samrose: yeah, that's our main website -- the documentation I refer to is organizing and presenting existing docs better, converting docs to a revision-controllable format, and making them easier to work with in our tools and via the website
17:18.01 samrose ah, ok
17:18.43 samrose getting all of this stuff from pdf to wiki pages or into revision control, eh? http://brlcad.org/wiki/Documentation
17:18.45 brlcad most of our discussions happen here on the channel or via our brlcad-devel mailing list
17:18.53 brlcad yes
17:18.55 brlcad and more
17:19.01 brlcad there's a lot more documentation than that
17:19.08 brlcad but that's more than enough to start with
17:19.08 samrose huh
17:19.54 brlcad the first steps are converting the docs to docbook format (an xml-based markup format for technical docs), then generating the output formats we need (web, pdf, doc, html, etc)
17:20.19 samrose seems like a programming task, if you ask me. writing some scripts that can get data from x and put it into y with as many changes/conversions needed done during the process as possible
17:20.37 samrose I am familari with docbook
17:20.43 samrose familiar that is :)
17:20.47 brlcad :)
17:20.58 brlcad yeah, that part of it is more a programming task
17:21.11 brlcad though the input docs are in a wide variety of formats and quantities
17:21.52 samrose what kind of revision control are you going to put them into, if I may ask?
17:21.55 brlcad hundreds of pages in msword-only, pdf-only, html, latex, and manual page come to mind
17:22.05 brlcad our svn repo
17:22.17 samrose ok
17:22.37 brlcad much of it already is there and done
17:22.48 samrose even though there are pages in msword, pdf, etc, there are some tools out there that can help with this
17:22.48 brlcad it's been a project under way for quite a while
17:23.01 brlcad yeah, and they tend to do a horrific job :)
17:23.06 samrose hehe
17:23.11 *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198)
17:23.36 samrose well, where do you need help these days?
17:23.44 brlcad in any regard, that's the work -- using tools, some manual, some automated, some scripting, etc -- hundreds of pages of docs
17:24.12 *** join/#brlcad ibot (i=ibot@rikers.org)
17:24.12 *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207)
17:24.12 brlcad there's also a variety of docs that still need to be written/rewritten
17:24.27 samrose you should put those in your wiki, maybe?
17:24.35 brlcad oh, absolutely
17:24.39 samrose then again, what do I know...
17:25.00 samrose but, I think media wiki export to docbook will be easy for you
17:25.22 brlcad one of the things I'm trying to get working is complete bidirectional editing of the docs through the website (ideally through the wiki) and to revision control docbook on the backend
17:26.22 brlcad unfortunately, wiki markup by itself isn't sufficient for all except the most basic layout needs
17:26.28 samrose so, that the wiki will export saved revisions as docbook to repo, eh?
17:26.54 brlcad yeah, that'd be the goal, so really anyone could edit a document either via checkout or via the website
17:27.21 brlcad and not have manual sync'ing, or manual export/import/merge steps
17:27.28 samrose hmmm... this is related to another project that I was working on, where we were trying to find ways to push wiki pages into print quality pages (ConTexT in that case)
17:27.48 brlcad hopefully avoiding unidirectional editing
17:28.15 samrose so, you could check an edit in to revision control, or edit a wiki page, basically
17:30.14 brlcad basically
17:30.41 brlcad first step was thinking to make either a drupal or mediawiki plugin that could simply display the docbook for a given page/document that would correspond to a given file
17:31.00 samrose mediawiki plugin would probably work
17:31.19 samrose you could write php that would sync with svn
17:31.27 samrose and back the other way
17:32.12 brlcad and when an edit was made, it'd go through a validation step, and get committed or scheduled for commit
17:32.15 samrose but, you were saying that MW markup is missing formatting you need for docbook
17:32.41 brlcad right, that's why it'd just display the docbook straight up as a first step
17:32.55 samrose it could actually run a command line command, if everything you needed existed as commands that could be run from shell :)
17:33.06 brlcad e.g. have one section/page that has the editable docbook, and another (read-only) that would be the rendered result
17:33.25 samrose like a "release" page
17:33.40 samrose so, you might use branches in svn to track that
17:33.44 samrose or tags
17:33.47 brlcad so hourly/nightly/manually/automatically/whatever, it would update from svn sources and rerender as needed
17:33.58 brlcad yeah, something like that
17:34.14 samrose the docbook idea is cool, because you could build a book as needed from pages
17:34.24 brlcad yeah, that's part of the goal
17:34.29 brlcad we have several books as is
17:35.21 samrose I am working on something similar with decentalized revision control right now as package management for digital design. I know it won't work for you, but I could also
17:35.32 samrose think about ways to sync with documentation
17:35.52 louipc this sounds pretty awesome
17:36.11 samrose so, we would pull brl-cad book, and could push changes in ways that you need, so that you can review and commit
17:36.44 samrose this is built in mercurial, python, bugseverywhere, exelearning, possibly more (a small wiki engine called hatta wiki)
17:36.57 samrose everything syncs with mercurial repo
17:36.58 brlcad samrose: distributed vs centralized revision control wouldn't/shouldn't really affect this -- most of the work is in how to display on the site, how it's integrated as a plugin, etc
17:37.30 samrose yeah, so anyone could edit, and there could be a plugin that would send you edits as commits in a form that you can use
17:37.49 brlcad ideally, one could make a much more complex mediawiki plugin that uses docbook as the entire format, renders the page using docbook as an alternate wiki markup
17:38.10 brlcad along with commit hooks on changes, of course
17:38.43 samrose well, i think there is already a docbook conversion for MW
17:38.52 brlcad export only
17:38.54 brlcad one-way
17:38.57 samrose ah
17:39.28 brlcad and if I put docbook into an edit page, it certainly won't render it ;)
17:39.56 brlcad barely deals with the html it supports
17:40.00 MinuteElectron is docbook latex?
17:40.19 brlcad MinuteElectron: no, docbook is an xml or sgml-based markup
17:40.31 samrose I am thinking that in addition to what you suggest above, that if there is a specification for what you are looking for in commits/edits, that this could also be built into other systems
17:40.35 MinuteElectron ok
17:40.50 brlcad one of the toolchains effectively converts docbook into a latex format and uses latex tools to render it (for pdf, rtf, etc)
17:42.54 samrose http://wiki.blender.org/index.php/Meta:Guides/Wiki_conversions/DocBook_to_Wiki
17:43.00 samrose perl!
17:43.02 samrose hahaha
17:43.06 brlcad samrose: yeah, it really should be generalizable to any project and most revision-control backends
17:44.00 samrose so, basically you can say: "this is what we need from you in the form of edit commits" I think you are saying it needs to be docbook
17:44.06 brlcad yeah, I've seen what they did -- sort of a similar idea, but I think that's a flop on execution
17:44.23 samrose heh, that was just a quick google search
17:44.28 brlcad it shouldn't just dumb down docbook to mediawiki markup if you want bidirectional
17:44.37 samrose I see
17:46.17 brlcad requiring editors to understand basic docbook is a reasonable first-step compromise
17:46.32 brlcad even our non-technically inclined editors have been able to use it
17:46.40 samrose yeah. or it may be worth making a really good conversion system
17:46.53 samrose well, that is true
17:47.11 brlcad just requires a simple tutorial, existing examples
17:47.29 brlcad not really any more complicated than wikitext markup, just more verbose
17:47.35 brlcad and more expressive/formalized
17:47.42 samrose yeah, I think most could handle it
17:48.06 brlcad there's even a wiki based on docbook, but I think mediawiki does a much better job really
17:48.57 samrose yeah. hmmm... I wonder how quickly the DTD of docbook could be programmatically mapped.
17:49.18 samrose (just thinking out loud)
17:50.39 samrose like this python script could work, it just needs to be more complete: http://wiki.blender.org/index.php/Meta:Guides/Wiki_conversions/DocBook_to_Wiki
17:53.09 samrose I am just thinking about how to get people who are already doing flex fab projects to 1. use brlcad 2. be able to quickly jump into documentation as they go
17:53.46 samrose I think we can do it over the next year or so
17:53.53 brlcad what are the needs?
17:53.58 samrose over time, get more people doing 1, and 2
17:54.00 brlcad what do you need a CAD system to do?
17:54.41 samrose people need solid geo modeling to document designs, so that others can collaborate on designs with them
17:54.44 samrose for one thing
17:55.07 brlcad to document the design in what manner?
17:55.24 samrose geometric dimensions
17:55.59 samrose many designs that are intended to be executed by cnc machinery
17:56.39 samrose perhaps CAD is not needed in every case, but there is clearly a demand
17:56.52 brlcad the latter is closer to doable now than the prior with where things currently stand
17:57.22 samrose you mean with brlcad in general?
17:57.33 brlcad there's a lot of work that has to go into our toolset before we can have automatic dimensioning for things like generating drawings and other drafting docs
17:57.39 brlcad yeah, in general
17:58.00 samrose Well, automatic dimensioning is actually not a requisite
17:58.14 samrose just *some* usuable 3D FLOSS CAD software
17:58.16 samrose :)
17:58.25 samrose and, the knowledge of how to use it
17:58.26 bitminer Is meida wiki being used currently? If so where is the search bar? Online wiki editor for Doc Book http://code.google.com/p/owed/
17:58.41 samrose OSE uses media wiki
17:58.47 brlcad well we're by far the best and most developed 3d f/oss cad software :)
17:58.59 samrose yeah, that is the conclusion I came to
17:59.18 brlcad bitminer: interesting, i've not seen that project
17:59.31 bitminer Just using some google foo
17:59.57 brlcad samrose: our biggest failing atm is gui usability -- the learning curve on mged (our main editor) is very steep
18:00.13 bitminer Sorry to return to doc book in this conversation, but thought you could use the info
18:00.43 brlcad "This project is abandoned"
18:01.04 samrose could be worth doing an autopsy on, though
18:01.17 samrose mged was the objection that lots of people raised to me
18:01.24 samrose so I am trying to convince them to learn it
18:01.57 samrose but, then, I am also thinking about how users could drive evolution at the same time.
18:02.32 bitminer I have needed (docbook) wiki in the past, never obatained it though. Likey a project in and of itself.
18:02.42 samrose I think I could get funds to hel towards gui interface design, but I want to work both with brlcad and people in the field
18:02.44 brlcad bitminer: more I read it, looks like they never finished and it's not a mediawiki plugin but a new wiki?
18:03.06 bitminer As for using mged and UI. Yes it is steep, but so too was learning Unigraphics.
18:03.19 bitminer With all the gui bells and whistles
18:03.30 samrose anyway, I think I can convince people to use mged now
18:04.06 samrose I did not realize that your existing documents are in svn so that alone really helps
18:04.35 bitminer I though I saw doc book in trunk? Yes ... checking...
18:05.01 samrose thanks brlcad bitminer. I'll talk to you later
18:05.42 brlcad samrose: if it's any consolation, the expert brl-cad modelers are usually more efficient in mged than they are in other commercial cad systems
18:05.51 brlcad it just took a while for them to get to that level of proficiency
18:06.36 brlcad bitminer: yes, doc/docbook has most of the docs that have already been converted
18:06.56 bitminer What I thought from snooping arround. Just getting started though.
18:07.16 brlcad there are still hundreds of 'pages' of docs, and hundreds of files, that still have to be converted
18:07.48 brlcad e.g., there are more than 400 tools in brl-cad -- there is a manual page for nearly all of them that needs to be converted
18:07.57 brlcad fortunately, that's a good one for automatic conversion
18:08.05 bitminer I know that doing this progrmatically, being programmers is encticing, but how hard would it be to do it ... mmm... huh... manually.
18:08.39 brlcad similarly, though, there are 300+ different mged commands which is all over the place
18:09.00 brlcad bitminer: a lot of it is being done manually
18:09.08 brlcad it's just really tedious too :)
18:09.30 bitminer So what would be target for auto convert and what would need to be done manualy?
18:11.25 brlcad bitminer: target is having docbook files instead of troff manpage format files :)
18:14.01 brlcad the html docs and msword docs tend to require a lot more manual effort
19:12.20 yukonbob morning, cadheads
19:28.34 *** join/#brlcad PrezKennedy (n=Matthew@whitecalf.net)
20:28.19 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-39.sbndin.btas.verizon.net)
20:30.28 *** join/#brlcad Ralith (n=ralith@216.162.199.202)
21:06.16 starseeker about autoconverting docs - the existing man pages have been run through an autoconversion process that produces "close" to correct output. The MGED commands, which are the current focus due to their being "user visible" in the MGED environment itself, typically do not have man pages to start with. Those are being hand converted, using the Volume II appendix as a starting point and a docbook template into which the information is inserted
21:06.58 starseeker However, just getting the documentation into docbook is only the first step, although probably the most tedious one
21:07.51 starseeker virtually all the documentation we have besides the chapters in the Volume II and III books needs to be carefully checked to make sure they are still current, correct and clear
21:12.20 *** join/#brlcad _sushi_ (n=_sushi_@77-58-230-60.dclient.hispeed.ch)
21:15.30 *** join/#brlcad Ralith (n=ralith@216.162.199.202)
21:47.16 CIA-40 BRL-CAD: 03brlcad * r33923 10/brlcad/trunk/ (TODO src/mged/cmd.c): make sure all of the view commands have the view to work with. this should remove the 'A view does not exist' messages from the GED view check.
23:12.17 CIA-40 BRL-CAD: 03brlcad * r33924 10/brlcad/trunk/include/vmath.h: drop the signbit on zeros during INTCLAMP so we don't print '-0'. achieve this via simple (double)(long) cast. should be just a minor cosmetic change.
23:14.38 brlcad starseeker: another thought came to mind about the tcl upgrade -- did you apply bob's 2x command length patch?
23:19.20 starseeker I believe I did
23:19.38 starseeker I think that was one of two I had applied at the outset - it should say in the commit message
23:23.45 brlcad okay, cool
23:24.15 starseeker still hasn't had time to work on blt yet - the one naive attempt to put latest cvs blt into the brlcad tree resulted in a compile error
23:24.31 brlcad they were working on our patch reviewing it
23:24.44 starseeker hmm. when was that?
23:24.51 brlcad couple days ago
23:24.58 starseeker ah, cool :-)
23:25.27 starseeker half agrees with Bob that we might want to revert Tcl/Tk upgrade til after the release - Archer will at least work on some platforms that way
23:25.45 starseeker is probably the only one with the X/Tk conflict
23:27.18 CIA-40 BRL-CAD: 03brlcad * r33925 10/brlcad/trunk/autogen.sh: another tweak from sebastian pipping, adds support for the old automake libtool macro, AM_PROG_LIBTOOL.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.