00:40.17 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
01:06.32 |
Notify |
03BRL-CAD:starseeker * 60437 NIL: Create a
branch for Qt experimentation |
01:26.55 |
*** join/#brlcad Zhao_Anqing
(~clouddrif@2001:da8:e000:1a08:6d34:9345:fc98:266b) |
01:50.07 |
*** join/#brlcad hoiji
(671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
02:59.35 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
04:35.22 |
*** join/#brlcad stirk
(~charlie@c-71-56-216-45.hsd1.co.comcast.net) |
04:45.23 |
*** join/#brlcad hcurtis
(b82d2a0d@gateway/web/freenode/ip.184.45.42.13) |
06:13.58 |
*** join/#brlcad hcurtis_
(b82d2a0d@gateway/web/freenode/ip.184.45.42.13) |
06:14.48 |
*** part/#brlcad hcurtis_
(b82d2a0d@gateway/web/freenode/ip.184.45.42.13) |
06:17.26 |
*** join/#brlcad hcurtis
(b82d2a0d@gateway/web/freenode/ip.184.45.42.13) |
09:18.48 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
09:39.00 |
*** join/#brlcad javampire
(~ncsaba@p4FF70AFC.dip0.t-ipconnect.de) |
10:40.57 |
*** join/#brlcad javampire
(~ncsaba@p4FF70AFC.dip0.t-ipconnect.de) |
11:53.15 |
javampire |
teepee: I've generated a graph of the header
dependencies of openscad, if there's of any interest for you, see
here: https://github.com/ncsaba/headerdeps/tree/master/examples |
11:56.16 |
javampire |
the openscad_1.pdf is a version where I
excluded some common headers which are only distracting |
11:56.29 |
teepee |
uh, that's quite a mess :) |
11:56.39 |
teepee |
lodepng.h includes itself? :D |
11:58.08 |
javampire |
teepee: nope, that's due to the simplicity of
the tool I used, which doesn't recognize that the include is in a
comment :-) |
11:58.36 |
teepee |
ahh, ok |
11:59.00 |
javampire |
it's a code example, and I hope there are not
too many of those which would break the picture :-) |
11:59.02 |
teepee |
strange tool :) |
11:59.36 |
javampire |
it's a simple python file I wrote myself, so
it's as good :-) |
12:00.04 |
javampire |
but the main structure becomes visible, that's
my goal |
12:00.06 |
teepee |
i thought gcc can just output
dependencies |
12:00.51 |
javampire |
possible, but I don't think it can exclude
headers and still work |
12:01.13 |
teepee |
that you could do in your script
then |
12:01.50 |
javampire |
well the thing is that for gcc to work you
need full setup of the code base, with correct includes and
all |
12:02.03 |
javampire |
so it works if it is done integrated in the
build system |
12:02.17 |
teepee |
hmm, parsing anything else will not produce
useful output anyway, right? |
12:03.22 |
javampire |
yes, in principle you're right, but in
practice I wrote my python thing faster than figuring out
gcc |
12:03.59 |
javampire |
the result is likely not 100% right, but
serves my purpose |
12:04.44 |
teepee |
yeah, for some quick info that might be
ok |
12:05.37 |
javampire |
well I would actually like to use gcc to do
the dependency graph, but I lack the skills to do it |
12:05.53 |
teepee |
but in most cases it's not true that figuring
out the "right" way to do it does take more time |
12:06.17 |
teepee |
http://stackoverflow.com/questions/1981563/generate-all-project-dependencies-in-a-single-file-using-gcc-mm-flag |
12:07.53 |
teepee |
or maybe "man makedepend" :) |
12:09.06 |
javampire |
teepee: well the problem with that is that it
needs to be part of the build setup of a project |
12:09.19 |
javampire |
so if I get a new project I want to explore,
that's not likely to be the case |
12:09.50 |
teepee |
I don't think that's needed |
12:11.06 |
*** join/#brlcad hoiji
(671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
12:11.40 |
javampire |
ok, makedepend is not installed on my box, and
it is part of the xutils-dev package, which doesn't seem
appropriate to me |
12:11.57 |
teepee |
why? it's written by the xorg guys |
12:13.08 |
javampire |
ok, let me see what's about it... |
12:16.01 |
teepee |
wow, that really needs some time to chew
though the openscad code :) |
12:16.24 |
*** join/#brlcad ejno
(~ejno@unaffiliated/kazaik) |
12:16.42 |
javampire |
ok, I had a look at the man page, and it
doesn't really seem the same as I do |
12:17.40 |
javampire |
how would you invoke it for brlcad ? |
12:18.00 |
javampire |
for openscad is fairly easy, you have most
sources in one flat directory |
12:18.19 |
teepee |
i just fired it up like "makedepend $(find .
-name \*.cc)" |
12:18.42 |
javampire |
aha, ok |
12:19.12 |
teepee |
so it's missing lots of includes from
non-default dirs, but I just wondered how the result will look like
:) |
12:20.58 |
javampire |
well that result needs to be transformed into
a graph, which is doable, but I wonder what happens if you run it
only on *.h files |
12:27.09 |
javampire |
ok, so I get some entries where *.o files are
depending on *.h -> I'm not sure if this is something I can
use |
12:27.20 |
javampire |
I want *.h -> *.h dependencies |
12:27.48 |
javampire |
it is likely that the *.o is just by replacing
h with o, in that case it could be usable |
12:29.25 |
javampire |
ok, it gives me class -> header
dependencies |
12:30.12 |
javampire |
if I want to process class dependencies, then
I want class -> class, not class -> header |
12:30.32 |
javampire |
but what I actually wanted is header ->
header |
12:34.54 |
*** join/#brlcad ries
(~ries@190.9.171.121) |
13:04.25 |
javampire |
just for the record, I found this tool
interesting (though totally off topic for BRL-CAD): http://code.google.com/p/ply/source/browse/trunk/ply/cpp.py |
13:27.58 |
javampire |
teepee: if I understand correctly, openscad
doesn't have any native/binary geometry file format, instead of
that the program/code which generates the geometry is used as
standard format ? |
13:53.24 |
teepee |
javampire: it does have a native format, sort
of |
13:53.46 |
javampire |
it's the DXF ? |
13:53.52 |
teepee |
javampire: but it's not really well
defined. |
13:53.58 |
teepee |
nope, it's named .CSG |
13:54.08 |
javampire |
in the example directory I see lots of
DXF |
13:54.11 |
teepee |
that's pretty much a dump of the geometry tree
with the CSG operations |
13:54.11 |
javampire |
aha |
13:54.32 |
teepee |
DXF can be imported and exported, but
currently only 2D |
13:54.52 |
teepee |
also the parser is quite limited, which is why
we want to use some better lib |
13:55.00 |
javampire |
does openscad keep the geometry in memory, or
it is only parsed when rendered ? |
13:55.16 |
teepee |
(that was one of the gsoc topics) |
13:56.00 |
teepee |
it's always generated when parsing but uses a
cache for unchanged parts |
13:57.14 |
javampire |
so there's no such thing as loading an object,
and then applying modifications on it ? |
13:57.22 |
javampire |
it's all procedural |
13:57.41 |
teepee |
it's all functional :) |
13:57.51 |
javampire |
ok :-) |
13:58.39 |
teepee |
you can do something like "scale([1, 1.1,
1.2]) linear_extrude(height = 10) import("shape.dxf");" |
13:58.51 |
teepee |
so you import a 2d shape, extrude to 3d and
scale the 3d mesh |
13:58.54 |
javampire |
is there any way to query object properties ?
Like: get me the lower-left corner of this previously created
box |
13:59.16 |
javampire |
that's a bad example, just for the
idea |
13:59.16 |
teepee |
nope, with a specific hakish exception for dxf
import |
14:00.15 |
teepee |
there is an idea how to fit some kind of
queries into the existing logic, but I don't know if that will make
it into the application |
14:00.21 |
javampire |
I think the killer feature for CAD is to make
expressing constraints easy... and the hardest of all goals
:-) |
14:01.31 |
teepee |
I'm not sure that applies to openscad the same
as for gui based tools |
14:03.13 |
javampire |
well it applies for anything - instead of
calculating the parameters of 2 boxes which should be aligned and
touching, there should be an easy way to express this constraint
and let the computer do the calculations |
14:03.46 |
teepee |
which is easy with the OpenSCAD scripting
lanugage |
14:04.18 |
teepee |
e.g. "cube([l, w, h]); translate([l + 1, w +
1, 0]) cube([l, w, lh]);" |
14:04.23 |
javampire |
well give me a pointer into the docs, cause I
missed it :-) |
14:04.49 |
javampire |
oh no, I want to explicitly see that
constraint |
14:05.22 |
teepee |
why? I can see that in the script (when
written carefully) |
14:05.33 |
teepee |
there is no constraint solver in
openscad |
14:05.39 |
javampire |
well this is one of the simpler
constraints |
14:06.39 |
javampire |
I know, and there's none in BRL-CAD
either |
14:07.08 |
javampire |
the problem is that it's hard to even express
those constraints that it is cleaner than manual calculations
:-) |
14:07.29 |
teepee |
do you have an example where it would make
sense? |
14:07.29 |
javampire |
but it must be possible... |
14:07.41 |
teepee |
e.g. simple example model I did yesterday:
http://www.fabfabbers.com/models/id/225/raspi-vesa-mount-by-t-paul |
14:07.58 |
javampire |
OK, have seen that already, cool thing
:-) |
14:08.10 |
teepee |
it's not the prettiest code possible for the
model, but not too complex to understand I guess |
14:09.10 |
teepee |
how could that benefit from automatic
constraint solving? |
14:09.48 |
javampire |
this one probably not much |
14:10.34 |
teepee |
hmm, why? from what I remember when I've used
constraints in freecad it might be possible to define
some |
14:10.55 |
teepee |
e.g. for the 4 * x screw holes for the vesa
mount |
14:11.18 |
teepee |
which are positioned in a square 75mmx75mm,
100mmx100mm, ... |
15:27.23 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
16:15.22 |
brlcad |
teepee: awesome lil mount |
16:15.50 |
*** join/#brlcad javampire
(~ncsaba@p4FF70036.dip0.t-ipconnect.de) |
16:17.11 |
teepee |
brlcad: thanks :) just found this nice little
12" monitor. I now have to find a way to fit the other computer
too |
16:23.02 |
*** join/#brlcad hoiji
(671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
17:01.15 |
*** join/#brlcad gaganjyot
(~gagan@27.255.253.16) |
20:15.24 |
*** join/#brlcad hcurtis
(b82d2a0d@gateway/web/freenode/ip.184.45.42.13) |
20:33.24 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |