| 00:26.05 | kanzure | hrmm wdb_fopen not being in wdb.h is really problematic for these bindings |
| 00:26.23 | kanzure | maths22: that's silly; you can just dump the database directly. |
| 03:06.43 | brlcad | ``Erik: have you created your GCI profile? |
| 03:13.13 | kanzure | can i have some test subjects? |
| 03:13.14 | kanzure | https://github.com/kanzure/python-brlcad |
| 03:17.03 | kanzure | in particular, i am looking for a /willing/ subject to run "pip-2.7 install brlcad" and then "git clone git@github.com:kanzure/python-brlcad.git" and then "cd python-brlcad/examples/; python2.7 wdb_example.py output.g" |
| 03:35.49 | brlcad | maths22: the spam is very minimal, almost certainly actual humans making it through all the barriers |
| 03:36.15 | brlcad | kanzure: we should just fix the wdb calls that should be in wdb.h |
| 03:36.38 | brlcad | never seen that freetype message |
| 03:36.41 | kanzure | the comments around wdb_fopen in raytrace.h make sense though- ideally it shouldn't need to know about the underlying database format or whatever |
| 03:37.22 | kanzure | i have fixed python-brlcad to generate a binding for librt so that it can grab a pointer to wdb_fopen |
| 03:38.00 | kanzure | i am interested in hearing bug reports regarding the python-brlcad install process |
| 03:38.32 | kanzure | once it's able to be used by at least n>0 humans other than myself i plan to spam the mailing list |
| 03:39.20 | maths22 | brlcad: i know; I just hadn't seen any in months |
| 03:39.28 | brlcad | nods, sounds like a solid plan :) |
| 03:41.55 | kanzure | and then i have to figure out a pythonic wrapper around this.. most python programmers aren't expecting this much "check what the function signature says". |
| 03:41.58 | brlcad | kanzure: I'll give the python bridge a try tomorrow afternoon |
| 03:42.03 | kanzure | cool, thank you |
| 03:42.39 | kanzure | the python/opencascade people wrote a bunch of SWIG bindings to opencascade, and then they wrote an additional layer on top of that. maybe i'll just go use those idioms.. |
| 03:44.27 | kanzure | ideally i would like things like "from brlcad import (svg, box, sphere); base = svg('gearface.svg'); structure = base.intersect(sphere())" etc. |
| 03:44.46 | kanzure | oh wait, i should have extruded somewhere |
| 04:14.10 | Notify | 03BRL-CAD Wiki:Sean * 6273 /wiki/Deuces: fix the tables |
| 04:38.40 | brlcad | kanzure: that would be awesome |
| 04:38.54 | brlcad | basically ways to perform actions even simpler than our existing GED library |
| 04:39.45 | brlcad | kind of see this becoming a place to sort out advanced/improved usability, ways to do things even simpler, meta-modeling |
| 04:51.54 | kanzure | one of the problems with ctypesgen at the moment is that it sucks at parsing many of the brlcad macros |
| 04:52.00 | kanzure | and a good chunk of brlcad seems to be implemented as macros.. |
| 07:44.13 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 09:06.49 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 09:31.49 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 10:22.32 | Notify | 03BRL-CAD:tbrowder2 * 58325 brlcad/trunk/doc/docbook/specifications/en/BRL_CAD_g_format_V5.xml: various format cleanups including table centering; more corrections; add info on proposed object time stamps |
| 10:59.48 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 11:19.08 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 12:06.17 | ``Erik | brlcad: yes, "erikg" |
| 12:25.14 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 12:50.13 | ``Erik | kanzure: is the python bridge build using the provided swig2 .i file, or something else? and is 2.7 necessary? no 3.3? |
| 14:28.07 | Notify | 03BRL-CAD:starseeker * 58326 brlcad/trunk/src/libbn/obr.c: keep working at obr code - will need careful testing. |
| 14:48.27 | *** join/#brlcad Ch3ck_ (c318d114@gateway/web/freenode/ip.195.24.209.20) |
| 15:04.30 | kanzure | ``Erik: it is not using swig |
| 15:04.39 | kanzure | ``Erik: it's using something called ctypes and ctypesgen |
| 15:04.47 | kanzure | ``Erik: https://github.com/kanzure/python-brlcad |
| 15:05.21 | kanzure | ``Erik: i haven't tested with python 3.3 yet but it might work.. my biggest concern is that ctypesgen might not be py3k-compatible. |
| 15:22.42 | kanzure | was libbrep in brlcad 7.18.4? a gentoo user is trying python-brlcad and for some reason libbrep.so is not built by default: http://sprunge.us/VbhT |
| 15:31.46 | Notify | 03BRL-CAD:starseeker * 58327 brlcad/trunk/src/libbn/obr.c: Make sure incrementing and decrementing is doing what we expect here... |
| 15:34.38 | starseeker | kanzure: that's pretty old... I'd have to check, but I'd be surprised |
| 15:34.59 | kanzure | ah, i have no sense for how old certain packages are |
| 15:35.09 | kanzure | 7.18 *sounds* close to whatever i downloaded, haha |
| 15:35.15 | starseeker | heh |
| 15:35.28 | kanzure | "something from this century" |
| 15:37.38 | kanzure | starseeker: can i convince you to try python-brlcad today? |
| 15:54.12 | brlcad | ``Erik: thanks, got it, app is in |
| 15:55.51 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 16:33.23 | maths22 | kanzure: I meant for the deuces page for GCI |
| 16:35.36 | maths22 | should I clean up deuces by removing stuff done in GCI 2012? |
| 16:40.40 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 16:44.48 | maths22 | Also, will cl-cia need any modifications for this year, or do we not yet know |
| 16:52.58 | starseeker | kanzure: sorry, I probably won't have time today |
| 16:53.32 | kanzure | okay |
| 16:53.57 | starseeker | I'm not all that hot at python, actually... |
| 16:54.24 | starseeker | kanzure: is there a small, embeddable implementation that might be integratable into BRL-CAD? |
| 16:54.39 | kanzure | even if there is, i strongly recommend NOT doing that |
| 16:54.52 | kanzure | extremely strongly |
| 16:54.55 | starseeker | how come? |
| 16:55.02 | kanzure | IMHO that's what's wrong with blender, freecad, heekscad, all these terrible packages |
| 16:55.12 | kanzure | they all embed python and then you can't use your standard library |
| 16:55.24 | kanzure | like, your runtime suddenly has to become "load up the entirety of blender" |
| 16:55.33 | kanzure | libraries should never ever do that to you :) |
| 16:55.49 | starseeker | I didn't say anything about *forcing* the use of an embedded python - merely a way to guarantee it's availability in the event there is no system version available |
| 16:56.03 | starseeker | see how we handle tcl, for example |
| 16:56.09 | kanzure | i don't know how you handle tcl |
| 16:56.51 | starseeker | by default, we auto-detect for a system install |
| 16:56.58 | starseeker | if none is found, we build our own copy |
| 16:57.35 | kanzure | so you have a vendorized copy of tcl in the source repository osmewhere? |
| 16:57.37 | starseeker | you can also force either the bundled version or a system version (the latter resulting in failure rather than enabling the internal copy) |
| 16:57.44 | starseeker | src/other/tcl |
| 16:57.56 | brlcad | maths22: please do (update deuces page) |
| 16:58.34 | kanzure | so is src/other/tcl a brlcad variant of tcl, or just a dump of tcl from upstream? |
| 16:58.43 | brlcad | maths22: basically, closed tasks need to be removed, then new tasks from http://brlcad.org/wiki/GCI_Tasks need to be integrated |
| 16:58.44 | maths22 | ok |
| 16:59.04 | brlcad | (we're not using wiki/GCI_Tasks, it should be Deuces) |
| 16:59.56 | maths22 | Do you remember why I made GCI_Tasks last year? |
| 17:00.03 | brlcad | maths22: and don't yet know about cl-cia, but ``Erik might be able to define some tasks (and I can put scheme on our list of languages) |
| 17:00.34 | starseeker | kanzure: it's sorta vanilla, but not entirely - that's where this paper came from, actually: http://www.tclcommunityassociation.org/wub/proceedings/Proceedings-2011/CliffordYapp/tcltk_cmake_paper.pdf |
| 17:01.22 | starseeker | ideally we would like those srcs to be just "dumps from upstream" as you put it, but the only one that we can really get away without changing currently is libpng |
| 17:01.48 | kanzure | starseeker: so is the entirety of brlcad usable from non-brlcad tcl as a thirdparty module? |
| 17:01.56 | kanzure | *from inside non-brlcad tcl |
| 17:02.04 | brlcad | kanzure: it basically an upstream dump, we apply build system patches so we can turn it off/on portably |
| 17:02.40 | brlcad | and "patches" is more like "cliff throttled their build", but it is build and not any actual tcl/tk changes |
| 17:03.09 | kanzure | so, there's a way to do that with python, but there's also a separate concept in python that goes by the name 'embeddable', much like lua and other scripting languages, where you import cpython headers and make an interpreter that is "owned" by a process inside a brlcad library |
| 17:03.11 | starseeker | kanzure: not really - we use tcl in the old-school manner as an embeddable language |
| 17:04.31 | ``Erik | as far as I can tell, python can have serious portability issues with python (pypy, cython, jython, etc might not run code 'right'), there is no standard, just "guidos implementation" |
| 17:04.35 | brlcad | eh, it's usable from a non-brlcad tcl .. just not in the ideal way you want if you were a tcl package developer |
| 17:04.41 | kanzure | my only complaint here is that i don't want brlcad to end up like blender or heekscad or freecad with an embedded python, and then the python runtime being subservient to that other runtime. e.g., it means that any downstream app that i make that uses python-brlcad has to suddenly be running in brlcad itself.. so if i make a web server that has a task queue worker, suddenly everything has to be running inside brlcad, etc. |
| 17:04.55 | brlcad | you load the library, bind your symbols, just like python |
| 17:05.03 | ``Erik | so integrating a python and trying to use a system one could bring up some crazy issues |
| 17:05.29 | starseeker | jimtcl is actually a better conceptual match for how we *want* to use tcl, in some ways, but the Tcl/Tk feature set we currently make use of is so extensive that we end up with the full Tcl/Tk + lots of packages in src/other :-/ |
| 17:06.15 | ``Erik | if google sends the same format of email as last year, the cl-cia stuff should 'just work', but there're plenty of improvements that could be made all throughout that code |
| 17:06.15 | starseeker | ``Erik: how so? Just turn off the embedded one if the system one is available/selected |
| 17:06.48 | ``Erik | starseeker: I mean nontrivial python code doesn't always do the same thing on different implementations |
| 17:06.54 | starseeker | ah |
| 17:07.01 | kanzure | i think you guys are thinking of a situation like "provide a python interpreter with brlcad" whereas i'm thinking in terms of "hey there's a pile of shared libraries here and i want to call those functions with my bytes and my bits" |
| 17:07.59 | brlcad | kanzure: interesting complaint regarding their embedded python .. will have to think about that some, but the notion was that it should work outside of our environment just fine |
| 17:08.00 | starseeker | kanzure: as long as the lower level libraries you're wanting to bind to don't have python mixed in, wouldn't that avoid any issues? |
| 17:08.39 | kanzure | starseeker: i'm not sure i follow, sorry. have you used blender + python before, for example? |
| 17:09.12 | starseeker | kanzure: no, sorry. I was going of of your generating swig bindings for the lower level libraries like librt and libwdb |
| 17:09.41 | starseeker | whatever is or isn't embedded, those libraries shouldn't know squat about python |
| 17:09.48 | kanzure | brlcad: there are a lot of technical options for execution. there's another method of providing python bindings where libbu.so can be imported directly into python if the source code provides some functions using some cpython types. and then "import libwdb" just magically works in python. |
| 17:10.09 | starseeker | we're actually pushing tcl out of them too (into libtclcad) although that's a slow process due to the early development history |
| 17:10.11 | brlcad | kanzure: I get what you're talking about .. you're complaint of them is effectively how we have tcl embedded (and is something we passively work to change) |
| 17:10.35 | kanzure | oh interesting, tcl is polluting some of the core libraries? |
| 17:10.44 | ``Erik | kanzure: all the way to libbu :( |
| 17:10.45 | kanzure | i did notice some weird tcl.h includes in bu/wdb |
| 17:10.53 | kanzure | yes that was actually impacting python-brlcad |
| 17:11.02 | starseeker | it used to be worse - brlcad did a lot of work on that a while back |
| 17:11.05 | brlcad | have to be careful with terminology |
| 17:11.08 | kanzure | i worked around it (had to add osme extra library paths, whatever) |
| 17:11.16 | brlcad | Tcl is both a C API and a Tcl API |
| 17:11.21 | brlcad | we use both |
| 17:12.19 | brlcad | we use the C API in a few places, and those are slowly being weeded out, but don't really affect runtime binding |
| 17:13.19 | kanzure | i guess this means i don't have to tell you guys how tcl.h shouldn't be included in bu.h, then ;) |
| 17:13.21 | brlcad | the Tcl API is what we overload and muck up to heck and back, so you have to run your scripts in OUR version of the tcl interpreter if you want to do some real work using our Tcl command API |
| 17:13.25 | kanzure | marks that off the list |
| 17:13.41 | kanzure | aha, yes i would consider that bad |
| 17:14.34 | brlcad | that's similar to what blender does with their py interp |
| 17:14.55 | kanzure | i was so disappointed when i learned that my .py files had to be run inside *blender* |
| 17:15.02 | brlcad | nods |
| 17:15.18 | brlcad | there's undoubtedly "a way" .. but you'd have to do all the init that they do |
| 17:15.29 | kanzure | on the other hand, this sort of embedding is very useful, especially in the context of games where you want to run scripts instead of C for every conceivable object in the game |
| 17:15.33 | brlcad | and it almost certainly wouldn't be pretty |
| 17:15.46 | kanzure | actually, i think the way to do blender bindings would be very similar to what i've done in python-brlcad |
| 17:16.03 | kanzure | python-brlcad is using a package called ctypesgen that scans header files and then generates the python bindings from that |
| 17:16.05 | brlcad | that's actually why I started down a path of creating a command API *library* .. |
| 17:16.57 | kanzure | ctypesgen has a lot of trouble parsing the macros in these header files btw.. it's definitely something i am going to be nagging you about. |
| 17:16.58 | brlcad | in theory, you can bind to that command library (libged) and have nearly all mged commands without mged (without tcl, without "brl-cad") |
| 17:17.18 | brlcad | need more info about that |
| 17:17.20 | brlcad | not surprising |
| 17:17.31 | brlcad | we use a lot of cpp features |
| 17:17.52 | kanzure | i didn't write ctypesgen so i'll have to create an actual bug report at some point in the future. i'm 90% sure it's just bad code in ctypesgen but the other option is to just not implement half of brlcad as a macro.. |
| 17:18.11 | brlcad | it really depends on the macros in question |
| 17:18.18 | brlcad | some are intentionally macros, some are not |
| 17:18.22 | kanzure | so far it's been some critters in bu.h |
| 17:18.36 | kanzure | ctypesgen will complain loudly when you test python-brlcad later today |
| 17:18.52 | starseeker | kanzure: don't let ``Erik hear you dissing macros too loud ;-) |
| 17:18.52 | brlcad | it's basically a throwback to the days where you used macros as a form of forced inlining |
| 17:18.57 | ``Erik | kanzure: I believe the blender guys are on freenode and pretty open to talking, it may be beneficial to chat with them a bit about how they use python and what they feel the pros and cons of their path were, instead of trying to guess? :) |
| 17:19.26 | kanzure | okay. |
| 17:20.05 | starseeker | nods - it may just not have occurred to them to think about non-blender external uses of their python functionality - most Blender work I know of *does* go in within the Blender framework... |
| 17:20.09 | kanzure | i mean, one reason they did it is so that their ui could be written in python |
| 17:20.26 | kanzure | a lot of their scripts are in python, which is fine, but asking end-users to run all python scripts inside blender is, imho, bad |
| 17:20.29 | brlcad | kanzure: there are some bu constructs that you cannot implement in C without macros or without drastically changing the API, it just depends on which ones need to be called |
| 17:20.35 | ``Erik | heh, certain aspects of our macro heavy vmath stuff is preventing quick&dirty sse3 for us :) macros are a tool, blindly assuming you should never/use macros would be bad form :) |
| 17:20.41 | brlcad | more than likely, if you need to bind them in python, they can be functions |
| 17:20.46 | kanzure | "just not have occurred to them to think about non-blender external uses of their python functionality" is probably correct |
| 17:21.13 | ``Erik | s,never/user,never/always use, |
| 17:21.16 | kanzure | brlcad: yeah, i nmost cases it looks like it can be done with a small wrapper function that just has the macro mentioned inside it. not a big deal. but sorta sucky. |
| 17:22.16 | brlcad | and if you're going to go that far, why have the macro |
| 17:22.26 | brlcad | again, just depends which ones |
| 17:22.45 | kanzure | i would say the small wrapper is an acceptable first step to refactoring without having to invest in actually doing the work |
| 17:23.07 | starseeker | kanzure: do you have a list? |
| 17:23.18 | kanzure | starseeker: no, but python-brlcad will spit one out. one moment. |
| 17:23.42 | kanzure | ERROR: /usr/brlcad/include/brlcad/bu.h:5102: Syntax error at 'va_list' |
| 17:24.28 | kanzure | ERROR: /usr/brlcad/include/brlcad/raytrace.h:4517: Syntax error at '\n' |
| 17:24.34 | kanzure | actually that seems to be it; i might have disabled the other macros. |
| 17:25.17 | kanzure | 4517 is #define db_ident(a, b, c) +++error+++ |
| 17:25.40 | kanzure | 5102 is the last line of BU_EXPORT extern void bu_vls_vprintf |
| 17:26.02 | starseeker | va_list isn't one of our internal types - that comes from C, iirc |
| 17:26.29 | starseeker | kanzure: which version are you working with? |
| 17:26.35 | brlcad | kanzure: 5102 is probably a failure parsing va_list .. which is almost certainly a macro type from a stdc header |
| 17:26.47 | ``Erik | (va is varargs, fwiw, a posix dealie) |
| 17:26.59 | kanzure | this is a legitimate ctypesgen bug, then |
| 17:27.09 | brlcad | probably |
| 17:27.22 | starseeker | that one is probably worth reporting back as a bug worth fixing, since you'll see it in a lot more than just our code |
| 17:27.29 | brlcad | not sure we can even do anything about that one |
| 17:27.30 | kanzure | ah.... ERROR: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h:40: Syntax error at '__gnuc_va_list' |
| 17:27.33 | Notify | 03BRL-CAD:carlmoore * 58328 brlcad/trunk/src/proc-db/masonry.c: remove 'Bad or help flag specified'; remove degtorad because DEG2RAD is already available |
| 17:27.41 | kanzure | unfortunately it seems that i am the person maintaining ctypesgen at the moment |
| 17:27.48 | brlcad | heh |
| 17:28.03 | brlcad | so fix it, ya lazy or soemthing ;) |
| 17:28.10 | kanzure | yes |
| 17:28.13 | brlcad | :) |
| 17:28.29 | ``Erik | damn ctypesgen maintainers, can't even keep their varargs handling working *cough* O:-) |
| 17:29.03 | brlcad | you could probably trick it by adding a #define va_list void* .. but technically not proper or something to keep |
| 17:29.23 | brlcad | it'd just redefine stdarg's type |
| 17:29.24 | kanzure | so does all the tcl includes mean that brlcad can't compile without X? |
| 17:29.28 | kanzure | or does tcl deal with no-X on its own? |
| 17:29.34 | brlcad | another possibility is that some other header is required |
| 17:29.37 | starseeker | Tk is the part of tcl that needs X |
| 17:29.43 | kanzure | oh. |
| 17:29.46 | starseeker | (or some graphics system, anyway) |
| 17:29.48 | brlcad | like sys/types.h .. and you might not be getting that header |
| 17:29.58 | brlcad | which would cause a syntax error using va_list |
| 17:30.07 | ``Erik | http://pubs.opengroup.org/onlinepubs/7908799/xsh/varargs.h.html |
| 17:30.16 | ``Erik | http://msdn.microsoft.com/en-us/library/kb57fad8.aspx |
| 17:30.21 | starseeker | it's a bit difficult to test (generally have to set up a non-X virtual machine) but we should build properly without any graphics at all |
| 17:30.22 | kanzure | brlcad: your ability to debug things is really neat, that sounds quite likely |
| 17:30.38 | brlcad | Tcl uses no X, actually has practically no external dependencies beyond maybe zlib and regex |
| 17:32.13 | ``Erik | tcl builds it's own regex engine, a really neat parallel dfa opposed to the normal nfa |
| 17:32.54 | starseeker | must try fiddling with tinypy some day... |
| 17:32.55 | brlcad | kanzure: easy to test, what do your man pages say are the required headers for va_start and/or vprintf? unconditinoally add them before 5102 and see if it makes a difference to ctypesgen |
| 17:33.19 | kanzure | man pages says va_start needs stdarg.h |
| 17:33.32 | kanzure | ERROR: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdarg.h:40: Syntax error at '__gnuc_va_list' |
| 17:33.38 | kanzure | so it looks like stdarg.h is being parsed |
| 17:34.42 | ``Erik | kanzure: it might be worth looking at the wrapping ifdef stuff and comparing it to the flags passed in to the compiler |
| 17:35.07 | Notify | 03BRL-CAD:brlcad * 58329 brlcad/trunk/include/bu.h: we use va_list and friends for some ... functions, so include this as a requisite header |
| 17:35.26 | brlcad | kanzure: that very well may have been the problem, 58329 |
| 17:35.28 | kanzure | bbl |
| 17:35.35 | ``Erik | (or perhaps header ordering requires stdarg to come after something like stdlib) |
| 17:36.14 | brlcad | almost certainly |
| 17:36.26 | brlcad | we never included stdarg explicitly |
| 17:38.03 | zero_level | hi all. |
| 17:38.27 | Notify | 03BRL-CAD:starseeker * 58330 brlcad/trunk/src/libbn/obr.c: We want the results to survive, so pass this properly... |
| 17:38.44 | zero_level | after few other commitments. Back again with brlcad. |
| 17:39.01 | zero_level | How are the preparations for GCI ? |
| 17:39.32 | zero_level | CAn I still contribute as a mentor ? |
| 17:45.20 | ``Erik | zero_level: I think brlcad was just able to submit the org application a few hours ago |
| 17:46.08 | zero_level | ``Erik : ok |
| 17:46.21 | zero_level | ``Erik : In the mail regarding icv work. |
| 17:46.45 | brlcad | hello zero_level |
| 17:47.01 | zero_level | brlcad mentoined about making things more modular. |
| 17:47.07 | brlcad | I got the org application initially submitted about 14 hours ago |
| 17:47.23 | brlcad | still working on polishing up the text, but working on the task list is priority now |
| 17:47.40 | zero_level | By that he meant, putting ppm formats in a subdir and .. |
| 17:48.26 | brlcad | zero_level: for GCI, tasks have to be VERY well defined and VERY small |
| 17:48.31 | zero_level | .. similarly for other formats. |
| 17:48.31 | zero_level | hii brlcad! |
| 17:48.39 | ``Erik | I... don't personally think any 2d raster file image format would be complicated enough to warrant a subdirectory... vector stuff, sure... where it needs multiple C files |
| 17:48.50 | brlcad | putting ppm in a subdir is conceptually small and taskwise should take less than 2 hours (which is the goal) |
| 17:49.05 | brlcad | but is very complicated in terms of what all might have to be explained |
| 17:49.24 | brlcad | how to do that correctly is not something easily spelled out as a recipe |
| 17:49.26 | ``Erik | but any raster image file should be able to contain a save and load image trivially in one file (with a library linked for complicated ones like jpeg or png) |
| 17:50.09 | zero_level | brlcad :Right. I am just taking pointers on continuation of my GSOC work. |
| 17:50.49 | zero_level | ``Erik : I feel the same. |
| 17:50.50 | ``Erik | zero_level: GCI grade icv work would be like "implement 1 filter" |
| 17:50.58 | zero_level | Therefore I suggest we make subdir for brlcad-primitive formats like bw,pix and dpix |
| 17:50.58 | zero_level | and all others |
| 17:50.58 | zero_level | ? |
| 17:51.43 | brlcad | ``Erik: it's not whether it warrants a subdir, but to conceptually ensure that each format is isolated .. that's easier to ensure if it's physically removed |
| 17:52.17 | zero_level | ``Erik : I am not sure. never thought about icv being a potent gci task. But If you suggest I can find such small tasks ! |
| 17:52.25 | brlcad | and would be helpful if we wanted a considerably more complex format like tiff or exr where we don't think about the extension owning the format, but just binding to it |
| 17:52.57 | ``Erik | aight, I'd think a file called "ppm.c" or "bw.c" would be adequate :) that ability to move from a file to multiple files is a bit of an art |
| 17:53.17 | brlcad | even if it's just one file in a subdir |
| 17:53.31 | brlcad | it's that ppm.c doesn't actually use some other header, type, function that it shouldn't be |
| 17:53.46 | brlcad | basically that we could copile it as a dynamic module and load it |
| 17:54.20 | brlcad | so all the formats basically become proper plugins and we're set up to receive plugins from 3rd party developers we have no control over |
| 17:54.25 | zero_level | ``Erik that is the current situation. |
| 17:54.28 | ``Erik | *shrug* directories are cheap, subdirs in a build system are expensive, I'd just ask that single file subdirs are managed by an upper level makefile |
| 17:54.32 | brlcad | they drop their plugin in a directory, and it loads and is an option |
| 17:54.43 | zero_level | bw.c, ppm.c, pix.c dpix.c |
| 17:54.51 | zero_level | and they all use encoding.c |
| 17:55.22 | zero_level | and all this files are placed in icv.h |
| 17:55.22 | zero_level | oops. |
| 17:55.22 | zero_level | src/libicv |
| 17:56.03 | zero_level | brlcad : One suggestion that comes to my mind. Lets keep all the raw formats (bw,pix,dpix,ppm) in a folder called raw. |
| 17:56.04 | brlcad | our formats, where they reside and how they are compiled, are mostly irrelevant |
| 17:56.33 | zero_level | ok. |
| 17:56.40 | brlcad | it's more about the library being design for extensibility so we can encourage/support other developers |
| 17:56.46 | ``Erik | brlcad: until you try building over nfs, or wors(e|t), an arl image windows machine... |
| 17:56.50 | brlcad | we don't want to own every type |
| 17:57.12 | brlcad | meh, not even a drop in the bucket |
| 17:57.28 | brlcad | premature optimization and all that |
| 17:57.43 | brlcad | care more about the API design |
| 17:58.00 | brlcad | and that 3rd party is part of that design, that our own types exemplify how to extend the library |
| 17:58.34 | brlcad | if we have to add a line to icv.h in order to support a new format, we've failed |
| 17:58.40 | ``Erik | I'd disagree... there is a huge disincentive to build on windows because it's sooo ddaaammmnnn sslllooowww... so we don't care about windows, but if we built fast there, it'd be less of a third class citizen |
| 17:59.11 | brlcad | omg, that is such a non-sequitor ... I agree and 100% don't care about that issue :) |
| 17:59.22 | brlcad | it's not the problem |
| 17:59.44 | ``Erik | I agree that api is paramount, but dir placement of source files isn't api, and is even further removed from build system layout |
| 18:00.35 | brlcad | sure, it's not API .. that's why I'm saying it's not the issue |
| 18:00.58 | brlcad | they COULD live in the same dir, that's not the concern at all |
| 18:01.26 | brlcad | the point of moving them is academic/instructive to ensure that they are not in any way intertwined and that they serve as a good example to others |
| 18:01.37 | brlcad | that point could be served by a single file somewhere, or a subdir |
| 18:01.41 | brlcad | it doesn't matter |
| 18:02.25 | ``Erik | a single file is necessary, a subdir is cool, a seperate build in a subdir starts hurting |
| 18:02.31 | brlcad | however, having it just be a single file does greatly increase the chance that it's intertwined just due to proximity/access .. all it takes is #including some private header that a 3rd party wouldn't have access to |
| 18:02.56 | brlcad | i mean mixed with icv sources |
| 18:03.30 | ``Erik | <-- has an interest in minimizing build time, so having src/libicv/Makefile is better than src/libicv/Makefile src/libicv/ppm/Makefile src/libicv/bw/Makefile src/libicv/pix/Makefile ... |
| 18:04.20 | ``Erik | *shrug* if src/libicv/Makefile refers to src/libicv/ppm/ppm.c, that's cool, but that second makefile... and third, and 37th, ... |
| 18:04.37 | zero_level | ``Erik I get your concern. |
| 18:05.01 | zero_level | but I believe what brlcad wants is : |
| 18:05.31 | zero_level | a) The library should be usable by other projects. |
| 18:05.37 | zero_level | b) It should be modular. |
| 18:06.05 | brlcad | and extensible by others (without them having to do a code-drop into libicv) |
| 18:06.44 | brlcad | how that's achieved w.r.t. the build system, couldn't care less until it all works :) |
| 18:06.50 | ``Erik | *shrug* I don't think I'm argueing against the points, merely an aspect of the implementation |
| 18:07.49 | ``Erik | and the point that the more painful and time consuming a build is, the less often it'll be done, reducing the chances to spot other build issues, no? :) |
| 18:07.55 | zero_level | ok. so ``Erik and brlcad can you suggest me the best I should proceed with ? |
| 18:08.39 | brlcad | zero_level: I don't think any suggestion has changed, has it? the library formats are still far from being modular |
| 18:08.43 | ``Erik | but, yeah, honeslty, I'm 95% considering the package maintainer view, not the developers right now.. take it for what it's worth, I just wanted to voice an opinion :) I live to be the devils advocate |
| 18:09.43 | zero_level | ``Erik what do you suggest ? |
| 18:10.04 | zero_level | what should be the fate of the icv library we started together? |
| 18:10.21 | ``Erik | I suggest writing code, files can be shuffled in and out of directories trivially |
| 18:10.27 | ``Erik | this is bikeshedding, dude :) |
| 18:11.28 | brlcad | I'm thinking of it more like "here's a cool image processing library I want to use" .. and I know/care nothing of BRL-CAD ... and it's missing a format/filter/feature I want to add .. how easily can I do that? |
| 18:11.37 | brlcad | remove all barriers, as few steps as possible |
| 18:12.55 | zero_level | brlcad :What should be the outline or procedure ? |
| 18:13.14 | ``Erik | I fail to understand how "update the makefile, add a subdirectory, add the file, add a new makefile" is easier than "update the makefile, add the file"... I'd imagine most contributors are NOT cmake familiar |
| 18:13.52 | brlcad | that's already like two steps more than necessary |
| 18:14.04 | brlcad | I don't care about brl-cad .. or cmake .. have my own tools |
| 18:14.47 | brlcad | I whip out a text editor, write a few lines of code, compile/link, drop the module in a dir, bam done |
| 18:15.26 | zero_level | ``Erik : I accept bikeshedding. (but the only way out is by performing the minials and moving to the much required (exr here) ) |
| 18:15.28 | brlcad | i'm not (yet) committed to submitting this extension back |
| 18:15.48 | brlcad | I own it, gtfoml |
| 18:15.58 | zero_level | but brlcad : Are we CAD supplier or library suppliers ? |
| 18:16.23 | brlcad | uhm, "yes" |
| 18:16.57 | brlcad | I see libicv becoming it's own product |
| 18:17.05 | zero_level | ok. |
| 18:17.07 | brlcad | just like libgcv |
| 18:17.10 | ``Erik | is going out of our way to support people who don't want to contribute back a good stance? stallman would sentence you to execution by his body odor for stating such... |
| 18:17.32 | brlcad | I don't think anything suggested is going out of our way, it's just modular |
| 18:17.46 | brlcad | I think it's actually less work than the mess that usually results otherwise |
| 18:18.06 | brlcad | just not modular for self, it's modular for others |
| 18:18.21 | brlcad | anti-self-centered view |
| 18:18.21 | zero_level | you havent still elaborated on a procedure. (owing to my poor background with cmake) |
| 18:18.30 | brlcad | we self-navel-gaze WAY too much |
| 18:18.59 | brlcad | zero_level: but your question is so incredibly open-ended |
| 18:19.21 | brlcad | and literally unlimited possibilities on how to get the lib modular |
| 18:19.28 | brlcad | that IS the procedure |
| 18:19.33 | brlcad | figuring out how |
| 18:19.38 | zero_level | hahah. |
| 18:19.42 | zero_level | any pointers ? |
| 18:20.12 | brlcad | well, that's why I suggested subdirs for you, so you can physically see the files from an external perspective |
| 18:20.23 | ``Erik | at the moment, the 'internal' format is public, so it can be extended... non-public extension is just ld -o libwanker.so -licv myformat.o |
| 18:20.25 | zero_level | brlcad : you were't serious abt this 14:15 < brlcad> I own it, gtfoml |
| 18:20.50 | brlcad | ``Erik: that is entirely not possible in any useful manner right now |
| 18:21.00 | ``Erik | woops, sorry, ld -o libwanker.so -licv gtfoml.o |
| 18:21.03 | ``Erik | :D |
| 18:22.04 | brlcad | nothing loads libwanker.so, there's no definition of a plugin api where the lib's capabilities are extensible |
| 18:22.52 | brlcad | even if there was something that looked in a dir and loaded all the .so's, there's no api, no registration ... it's just more functions that nothing calls |
| 18:23.18 | ``Erik | that's an extensible plugin framework you're talking about, not how to place files in a public library |
| 18:23.49 | brlcad | say we have an "icv" tool that converts image formats and it has usage "icv [fmt:]inputfile [fmt:]outputfile" |
| 18:24.31 | brlcad | ``Erik: exactly why I said the directory layout has absolutely no bearing, so why are we even talking about it (still) |
| 18:25.01 | brlcad | the only relevance was to possibly help ensure that sources are not intertwined (physically) |
| 18:25.25 | brlcad | that was the ONLY reason ... my god this is not that complicated :) |
| 18:26.31 | zero_level | brlcad, ``Erik can you point me to something in src code that has similar subdir. |
| 18:26.44 | zero_level | I think this will help me mirror. |
| 18:27.07 | ``Erik | zero_level: src/conv/ is probably the closest we have in existance right now |
| 18:28.28 | zero_level | ``Erik : A general question. Is svn the best cvs tool ? |
| 18:28.32 | brlcad | I would have said something like src/librt/primitives/table.c and src/librt/primitives/SUBDIR |
| 18:29.34 | ``Erik | zero_level: vcs tool, and it all depends on your needs... I typically use git now, even though I think darcs is better... svn is decent, but I still find uses for RCS *shrug* it all depends on your needs :) |
| 18:30.17 | brlcad | zero_level: grep PNG include/icv.h |
| 18:30.20 | brlcad | make that go away |
| 18:31.14 | brlcad | think about how to either eliminate or auto-register the information in ICV_IMAGE_FORMAT |
| 18:31.43 | ``Erik | brlcad, starseeker: I might be hungry for chinese or korean on wednesday or friday :) |
| 18:32.11 | brlcad | zero_level: then do the same for the PNG references in src/libicv/fileformat.c |
| 18:32.21 | brlcad | start with something literally that simple |
| 18:32.37 | brlcad | ``Erik: wednesday sounds doable |
| 18:32.41 | zero_level | brlcad : Is izak around |
| 18:33.00 | brlcad | I've not seen him around, Izak_: are you around? |
| 18:33.05 | zero_level | can you direct him regarding this http://pastebin.kde.org/pu2smarc9 ? |
| 18:33.24 | zero_level | brlcad : I get your point. |
| 18:33.55 | zero_level | you will see substantial change towards "modularity" in near future. |
| 18:35.21 | brlcad | zero_level: if you're still lost on the "how to do that" ... perhaps something for you to read is how others do plugins |
| 18:35.25 | brlcad | http://developer.gimp.org/writing-a-plug-in/1/ for example |
| 18:36.33 | zero_level | brlcad : I found great work have been done during doc sprint. |
| 18:36.37 | brlcad | basically, you define a set of functions |
| 18:36.41 | brlcad | you put those functions into a struct |
| 18:36.49 | brlcad | you register that struct |
| 18:36.52 | zero_level | any news regarding the available soft copy ? |
| 18:37.10 | brlcad | the library looks over the registrations when doing work |
| 18:37.15 | brlcad | calls those functions as needed |
| 18:37.43 | brlcad | there will be an announcement in a week or so about obtaining copies |
| 18:38.04 | brlcad | the doc sprint was pretty awesome, we have a few books available but we have more work to do |
| 18:41.31 | ``Erik | isst has a trivial plugin capability in the sdl package |
| 18:48.03 | Notify | 03BRL-CAD:mendesr * 58331 jbrlcad/trunk/src/main/java/org/brlcad/info/RegionInfo.java: Fixed bug in JBrlcad not closing the file input stream for BrlcadDb. |
| 18:48.55 | zero_level | ``Erik : sdl packae ? |
| 18:50.09 | brlcad | stops tweaking the GCI appliation with 6 minutes to go |
| 18:57.13 | brlcad | lies and keeps tweaking the text up to the last minute |
| 18:57.44 | kanzure | just don't forget clock drift |
| 18:57.45 | Notify | 03BRL-CAD:carlmoore * 58332 brlcad/trunk/src/proc-db/masonry.c: rearrange logic; notice that if 'usage' is invoked, we leave the program |
| 19:14.40 | Notify | 03BRL-CAD:starseeker * 58333 brlcad/trunk/src/libbn/obr.c: Start figuring out how to calculate the actual bounding rectangle from the caliper points. |
| 19:31.55 | Notify | 03BRL-CAD:starseeker * 58334 brlcad/trunk/src/libbn/obr.c: Something still wrong with calculations, but start activating full algorithm |
| 19:32.39 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 19:49.27 | Notify | 03BRL-CAD:carlmoore * 58335 brlcad/trunk/src/proc-db/masonry.c: default units = mm |
| 19:51.25 | starseeker | brlcad: if we want to do comments on a document maybe something like this would work? https://lite.co-ment.com/ |
| 19:51.45 | starseeker | grew out of the original commenting period for the GPLv3 |
| 19:52.04 | starseeker | http://www.co-ment.org/ actually... |
| 19:53.30 | starseeker | might be more flexible/community-oriented than comments in a Word doc... |
| 20:45.52 | *** join/#brlcad merzo (~merzo@150-20-132-95.pool.ukrtel.net) |
| 21:04.40 | Notify | 03BRL-CAD:carlmoore * 58336 brlcad/trunk/src/proc-db/masonry.c: put in a set of brackets in Usage; carry out some calculations; remove redundant h from options |
| 21:23.20 | brlcad | kanzure: ironically was just noticing how our server's clock is drifted by several minutes at the moment |
| 21:23.51 | brlcad | my tweaking was nit picking, nothing critical, and completed well in advance ... it's all good |
| 21:24.38 | kanzure | nitpicking is perhaps the only thing keeping me rolling every day |
| 21:27.08 | brlcad | starseeker: maybe but that seems awefully clumsy ... I don't have a good solution, just a lot of terrible ones :) |
| 21:27.44 | brlcad | starseeker: have you ever run pandoc? might be interesting to see what happens if we convert something like the db5 spec from docbook to markdown and back .. see what is lost |
| 21:27.48 | brlcad | http://johnmacfarlane.net/pandoc/demos.html |
| 21:29.08 | brlcad | if it preserves most, it'd be compatible with mediawiki (with a plugin) |
| 21:36.34 | brlcad | is reminded of http://www.methods.co.nz/asciidoc/ ... they've apparently come a long way |
| 21:46.43 | kanzure | brlcad: *poke* python-brlcad testing? |
| 21:51.58 | brlcad | kanzure: on my list, not there just yet |
| 21:52.09 | brlcad | two more things to take care of first |
| 22:06.00 | Notify | 03BRL-CAD Wiki:Maths22 * 6274 /wiki/Deuces: Removed last year's code tasks |
| 22:10.06 | Notify | 03BRL-CAD Wiki:Maths22 * 6275 /wiki/Deuces: Removed last year's UI tasks |
| 22:16.02 | Notify | 03BRL-CAD Wiki:Maths22 * 6276 /wiki/Deuces: Removed last year's documentation tasks |
| 22:21.07 | Notify | 03BRL-CAD Wiki:Maths22 * 6277 /wiki/Deuces: Removed last year's outreach tasks |
| 22:29.13 | Notify | 03BRL-CAD Wiki:Maths22 * 6278 /wiki/Deuces: Removed last year's QA tasks |
| 22:30.37 | maths22 | I have removed all of last year's completed tasks from the Deuces page |
| 23:19.52 | kanzure | brlcad: the packaged version of brlcad for gentoo apparently doesn't build or doesn't provide libbrep.so by default. what should i do about this in python-brlcad? |
| 23:38.05 | brlcad | maths22: fantastic, thank you |
| 23:38.43 | brlcad | kanzure: is there something that needs to be done? |
| 23:40.09 | brlcad | 7.18.4 was almost 3 years ago |
| 23:41.20 | brlcad | that's hundreds of differences, and libbrep isn't central to our api just yet |