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