| 07:55.46 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 09:14.19 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 10:59.03 | *** join/#brlcad chick (~chick@195.24.220.16) |
| 11:16.55 | *** join/#brlcad chick (~chick@195.24.220.16) |
| 13:38.18 | brlcad | ries: a variety of ways, heavily analytic being the dominant |
| 14:04.58 | *** join/#brlcad chick (~chick@195.24.220.16) |
| 14:06.34 | Notify | 03BRL-CAD:tbrowder2 * 59641 brlcad/trunk/src/libbu/bitv.c: correct comments; tweak formatting |
| 14:10.14 | Notify | 03BRL-CAD:tbrowder2 * 59642 brlcad/trunk/src/libbu/bitv.c: bu_binary_to_bitv is just a specialized case of bu_binary_to_bitv2 |
| 14:52.07 | Notify | 03BRL-CAD:tbrowder2 * 59643 brlcad/trunk/src/libbu/bitv.c: beef up error checking; use same var names for similar routines |
| 15:00.20 | Notify | 03BRL-CAD:tbrowder2 * 59644 brlcad/trunk/src/libbu/bitv.c: use a literal constant to clarify use in bit fiddling |
| 15:28.47 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 15:33.19 | Notify | 03BRL-CAD:tbrowder2 * 59645 (brlcad/trunk/src/libbu/tests/bitv-tests.txt brlcad/trunk/src/libbu/tests/bu_bitv.c and 2 others): bitv-tests.txtbu_bitv.c+ incorporate all bitv tests into bu_bitv.c+ change test input accordinglytest_internals.hbu_vls.c+ changing PASS/FAIL to CTEST_PASS/CTEST_FAILbu_bitv_and.cbu_bitv_or.cbu_bitv_shift.cbu_bitv_to_hex.cbu_bitv_vls.cbu_hex_to_bitv.c+ removed since their tests are now |
| 15:33.21 | Notify | incorporated into bu_bitv.c |
| 15:36.31 | Notify | 03BRL-CAD:tbrowder2 * 59646 brlcad/trunk/src/libbu/tests/bitv-tests.txt: add comment about efficacy of hex_to_bitv tests |
| 16:43.13 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 16:45.08 | *** join/#brlcad chick (~chick@195.24.220.16) |
| 18:52.56 | *** join/#brlcad merzo (~merzo@51-132-132-95.pool.ukrtel.net) |
| 19:01.47 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 19:32.00 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 19:32.00 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Ask us about Google Doc Sprint 2013 || GCI has ended. Stay tunned for announcement of Grand Prize Winners. |
| 20:10.44 | *** join/#brlcad chick (~chick@195.24.220.16) |
| 20:17.52 | *** join/#brlcad ncsaba__ (~ncsaba@p4FF7338C.dip0.t-ipconnect.de) |
| 20:26.23 | ncsaba__ | hi all, anybody around who knows how to write using libwdb a combination |
| 20:26.23 | gcibot | ncsaba__, hey! |
| 20:27.15 | ncsaba__ | sorry, enter hit too early - a combination which has parenthesis to override the default precedence of +,-,u ? |
| 20:27.40 | ncsaba__ | I just can't figure it out |
| 20:28.31 | *** join/#brlcad chick (~chick@195.24.220.16) |
| 20:49.36 | kanzure | ncsaba__: wasn't there a comb command? |
| 20:50.20 | ncsaba__ | kanzure: yes, there is one, but I can't figure out from it's parameters how to group the elements (if it is possible at all) |
| 20:51.15 | ncsaba__ | currently in the python code I pass a linked list of elements to be combined, but I would like to group them for overriding the precedence of the operators |
| 20:51.34 | ncsaba__ | that is definitely possible e.g. via mged's "c" command |
| 20:52.11 | ncsaba__ | I'm still reading code, I will surely figure it out sooner or later, but if there's a shortcut I would be glad to take it :-) |
| 21:00.09 | ncsaba__ | kanzure: BTW, what do you think about using numpy as vmath replacement in python ? |
| 21:00.46 | kanzure | i like numpy/scipy my only worry is that it's a large dependency |
| 21:01.04 | kanzure | perhaps it would be nice if it is an optional dependency |
| 21:01.16 | kanzure | but if it must be a required dependency then i wouldn't have a fit anyway :) |
| 21:06.06 | ncsaba__ | hmm |
| 21:07.04 | ncsaba__ | well the high level python code could go in a separate package perhaps, so people can code directly to ctypes if they wanted to without the numpy dependency |
| 21:07.41 | kanzure | shrug, brlcad is a large dependency too, and numpy isn't really a bad thing to have around |
| 21:08.19 | ncsaba__ | but if you want to do any coding/calculation using vectors in python, then numpy is almost surely the better choice |
| 21:08.33 | kanzure | yeah, i say let's put numpy in |
| 21:08.38 | kanzure | and then we can remove it later if it's problematic.. i doubt it will be. |
| 21:08.45 | ncsaba__ | ok, cool |
| 21:09.56 | ncsaba__ | thing is that I'm not necessarily after having the best code around, but to script my geometry models as fast as possible :-) |
| 21:10.36 | ncsaba__ | currently I have some TCL code which does the job, but I can't read it myself after 2 days |
| 21:11.13 | ncsaba__ | I translated part of it to python using BRL-CAD, and it is definitely a huge improvement |
| 21:11.30 | ncsaba__ | I mean python-brlcad |
| 21:11.36 | kanzure | yeah, simple scriptable geometry is really hugely important |
| 21:11.40 | kanzure | openscad ain't got nothing on this :) |
| 21:12.47 | ncsaba__ | but I got stuck on this operator precedence/grouping issue, I have a few fairly complex combinations which won't work with the current code |
| 21:13.26 | ncsaba__ | I guess I will be forced finally to work on the internal representation of a combination and use librt instead of libwdb |
| 21:13.56 | ncsaba__ | for now I avoided that to have fast results |
| 21:14.47 | ncsaba__ | the internal representation is for sure more complex to work with than simply providing some primitive parameters and have the geometry created that way |
| 21:16.26 | ncsaba__ | in the long term it is necessary to wrap the primitives in python objects, but for now it was faster to just pass numbers to libwdb |
| 21:17.43 | ncsaba__ | do you have any experience writing C code to create a combination/region ? |
| 21:18.54 | ncsaba__ | or perhaps a hint where I could find example code creating more complex combinations than ones with 2 objects unioned/intersected/extracted ? |
| 22:10.47 | ncsaba__ | ok, I got to the conclusion that it is not possible to do the grouping via libwdb's mk_comb |
| 22:13.39 | brlcad | ncsaba__: GIFT is an old geometry interchange format that predates BRL-CAD |
| 22:14.02 | brlcad | basically an ancestor representation format that included definitions of standard fields which were adopted |
| 22:14.17 | brlcad | you can otherwise ignore that in names (we'll eventually remove them) |
| 22:14.18 | ncsaba__ | brlcad: Hi, thanks for the info ! |
| 22:14.30 | brlcad | hi :) |
| 22:14.57 | brlcad | so I'm looking into ways to make binding to brl-cad not such a huge dependency |
| 22:15.21 | brlcad | if you have thoughts on what would work well for you, I'd appreciate the feedback |
| 22:15.52 | ncsaba__ | well it's a lot of code to read through, that's a problem indeed |
| 22:15.57 | brlcad | structurally, the issue is we have about 7 libraries "underneath" libwdb and librt |
| 22:16.33 | brlcad | we could make the "core" a separate download or installable module |
| 22:16.50 | ncsaba__ | the size of the download is not the problem, at least not for me |
| 22:16.58 | brlcad | having to read through a lot of code is being addressed by organizing the headers |
| 22:17.03 | brlcad | so you don't have to go rummaging around src/ |
| 22:17.13 | brlcad | you'd just read the docs and decls in the include/ hierarchy |
| 22:17.38 | brlcad | what about a separate of libraries from applications? |
| 22:17.44 | brlcad | s/separate/separation/ |
| 22:17.48 | ncsaba__ | on what criteria ? |
| 22:18.02 | brlcad | yours ;) |
| 22:18.03 | ncsaba__ | the problem is that you don't know what to separate until somebody wants to use it |
| 22:18.21 | brlcad | well that's why I said libs vs non-libs |
| 22:18.24 | ncsaba__ | well for starters libwdb is perfect :-) |
| 22:18.40 | brlcad | wdb is almost our smallest lib |
| 22:18.46 | ncsaba__ | except it has a few edge cases |
| 22:18.54 | brlcad | I fixed the bug you found, thanks |
| 22:18.54 | ncsaba__ | yes, that's why I started at it :-) |
| 22:19.02 | ncsaba__ | which bug ? |
| 22:19.35 | brlcad | arbn releasing the caller's memorg |
| 22:19.37 | brlcad | memory |
| 22:19.54 | ncsaba__ | aha, so it will not do it anymore ? |
| 22:20.12 | brlcad | it will leave the caller's memory alone (it makes a copy) |
| 22:20.18 | ncsaba__ | then I will also need to get the extra allocation out of the python wrapper :-) |
| 22:20.42 | brlcad | also makes it possible to use stack-allocated memory |
| 22:20.51 | ncsaba__ | ok, sounds good |
| 22:21.09 | brlcad | if you have a list of issues like that, they can be easily fixed |
| 22:21.46 | ncsaba__ | if you're around, do you have any idea if libwdb's mk_comb can create combinations where the operations are grouped like in a parenthesized "c" command in libged ? |
| 22:21.50 | ncsaba__ | I mean mged |
| 22:22.38 | ncsaba__ | I have a few complex combinations where I want to extract the result of other diffs without extra intermediary combinations |
| 22:23.12 | ncsaba__ | I can always do it with intermediary results, but there's no point if I don't actually need them and poses a problem in naming them... |
| 22:23.57 | ncsaba__ | the mk_comb function accepts a list of combination members, whereas I need to specify a tree I guess |
| 22:26.35 | ncsaba__ | I got to the conclusion it's likely only possible via wdb_put_internal or wdb_export |
| 22:27.30 | ncsaba__ | meaning I will need to create the internal representation, after I figure out how to build the combination's tree :-) |
| 22:29.04 | brlcad | ncsaba__: if you can create it with parentheses, you can create it with one mk_comb call |
| 22:29.25 | brlcad | that expands into a single-declaration stack form without need for intermediates |
| 22:29.28 | ncsaba__ | hmm, I'm reading and searching for 2-3 days by now, and couldn't figure it out |
| 22:29.42 | brlcad | i'll see if I can work up an example |
| 22:30.08 | ncsaba__ | example: a - (b - c) |
| 22:33.02 | ncsaba__ | anyway, I guess I will go for interfacing with librt and allow read/write/modify of geometry files |
| 22:35.32 | ncsaba__ | then after that works too, I wonder how hard would it be to extract all TCL dependencies and invert the control, to have the shell call in brlcad, then python can do that the same as TCL ? |
| 22:36.11 | ncsaba__ | I haven't checked extensively, but is it possible that the TK interface is just as well usable from python ? |
| 22:36.24 | ncsaba__ | so a kind of mged but with python instead of TCL |
| 22:37.38 | ncsaba__ | I have to say I don't use the UI that much, and TCL is terrible compared to python for any script which needs to be readable after a week |
| 22:39.15 | ncsaba__ | so in terms of brl-cad internal work, I would go for extracting the dependencies on TCL in some "shell" library which can be interfaced from other scripting shells too |
| 22:39.21 | kanzure | ncsaba__: yes i wrote mk_comb code in examples/ in python-brlcad btw, take a look there |
| 22:40.59 | kanzure | brlcad can easily have a python shell, but it's a tough choice about how to do the integration (embed the python interpreter? etc.) |
| 22:41.23 | ncsaba__ | yes, but that's just plain union, that works already fine |
| 22:41.47 | ncsaba__ | well I would go for interfacing via an API |
| 22:41.49 | ncsaba__ | no embedding |
| 22:42.30 | ncsaba__ | If TCL would not be embedded, it would be much easier now to interface from python too |
| 22:44.57 | ncsaba__ | in fact if it would be possible, I would like to only interface to libged and to the display manager (not sure if it is called like that), that would allow to have a python mged with the least effort |
| 22:45.43 | ncsaba__ | from brief code reading it seems at least theoretically possible to reuse almost the whole infrastructure, if the TCL dependencies are separated |
| 22:46.15 | ncsaba__ | but I might be mistaken, there's lots of code there too |
| 22:47.22 | ncsaba__ | kanzure: there are some examples with '-' indeed, but how would you code a combination which has this: shape1 - (shape2 - shape3) ? |
| 22:48.53 | ncsaba__ | that's my biggest problem case, but for others where I used parenthesis I'm also not very sure how to get it in a flat list... |
| 22:49.05 | kanzure | i haven't done that yet, and also i don't have an answer |
| 22:49.25 | ncsaba__ | well, I just guess it is not possible with mk_comb |
| 22:49.47 | ncsaba__ | will need to read more code to be sure |
| 22:50.41 | kanzure | yeah, i agree that an api is preferable, although that means that brlcad would have to bundle python-brlcad if it was to distribute a python interface or something |
| 22:50.48 | kanzure | or, maybe it would just mean a less monolithic release |
| 22:51.03 | ncsaba__ | less monolithic, that's my vote |
| 22:51.04 | kanzure | e.g. a release for core components, and then a release for gui components that are compatible with (at the very least) the recent core library release |
| 22:51.43 | ncsaba__ | python-brlcad can surely be backwards compatible to all known releases, python is fairly flexible to allow that |
| 22:53.39 | ncsaba__ | I'm pretty sure the TCL shell would also profit from a well defined shell interface |
| 22:54.58 | ncsaba__ | if nothing else, in the process of implementing a python shell, the interface will get better documented ;-) |
| 22:55.20 | ncsaba__ | some of mged's commands really need some more documentation |
| 22:55.47 | ncsaba__ | and if I touch any of that, first thing will be to document it |
| 22:58.04 | ncsaba__ | in fact I think when I start wrapping primitives in python, I will add code to display all parameters visually and write some code to display all primitives annotated with parameters |
| 22:58.46 | ncsaba__ | so whoever wants to see what parameters a primitive takes, just run and check |
| 22:59.09 | ncsaba__ | no need to print it, if you can check it visually online |
| 22:59.17 | ncsaba__ | that would also be always up to date |
| 23:00.13 | ncsaba__ | that's also one of the problems of BRL-CAD, it changes rapidly and documentation get's out-dated |
| 23:00.27 | ncsaba__ | and it's so big that it is almost impossible to keep it up to date |
| 23:01.21 | ncsaba__ | so I would say make it possible to get the same documentation on-line as you have embedded in the code, and make it mandatory to document code very well |
| 23:03.48 | ncsaba__ | OK, so instead of lots of talking, I will go now to sleep (late here) and continue tomorrow to work on the combination saving, then next on open/modify/write cycle of internal structures from python |
| 23:04.09 | ncsaba__ | once that's ready, we can discuss again what comes next |
| 23:04.39 | ncsaba__ | see you guys :-) |
| 23:39.08 | kanzure | i am glad he is around |