IRC log for #brlcad on 20140419

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)

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