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. |