| 02:14.04 | *** join/#brlcad ishwerdas (~ishwerdas@59.91.115.9) | |
| 03:30.03 | brlcad | starseeker: what's the legal concern? |
| 03:30.15 | brlcad | n_reed: saw that :) |
| 03:36.06 | brlcad | kanzure: that's defining an ON_Brep type so C-only programs that don't use/need/want anything C++ will succeed; it also lets us use the ON_Brep type in C headers without turning them into C++ headers (by needing to include the C++ openNURBS headers that would otherwise be needed to resolve that type) |
| 03:39.00 | kanzure | hrm. any chance we could convince the rhino people to produce a C-only version. |
| 03:40.52 | brlcad | starseeker: it's not ideal, but freetype should be okay if we 1) do not allow any code to migrate from their src/other dir to our sources (i.e., don't mingle sources), 2) do not modify their sources (i.e., don't create a deriative work), and 3) do properly credit them as required by their license |
| 03:41.20 | brlcad | kanzure: zero chance |
| 03:42.00 | kanzure | well, knowing is half the battle |
| 03:42.05 | kanzure | thanks |
| 03:42.15 | brlcad | we're already using openNURBS in a way that they explicitly publicly state that they do not want or support |
| 03:42.37 | kanzure | ah i wasn't aware they made statements about that |
| 03:42.41 | kanzure | makes sense of course |
| 03:43.25 | brlcad | they wholesale remove large portions from openNURBS (but leave in their RhinoSDK product that they sell) that we now implement (e.g., surface intersections, ray tracing, tessellation, ...) |
| 03:44.01 | kanzure | right |
| 04:27.41 | Notify | 03BRL-CAD:brlcad * 61472 brlcad/trunk/include/bu/cmd.h: need sys/select.h for timeval |
| 05:29.57 | *** join/#brlcad pandrei (~pandrei@86.127.147.243) | |
| 06:46.06 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 07:22.00 | *** join/#brlcad alisha (~alisha@202.164.53.117) | |
| 08:29.16 | *** join/#brlcad backom (caa43575@gateway/web/freenode/ip.202.164.53.117) | |
| 08:29.18 | Notify | 03BRL-CAD Wiki:Azharuddin46 * 0 /wiki/User:Azharuddin46: |
| 08:44.52 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 08:54.46 | *** join/#brlcad javampire (~ncsaba@p4FF71D8D.dip0.t-ipconnect.de) | |
| 09:36.06 | javampire | kanzure: Hi Bryan, I just read over the IRC logs of the past few weeks (had not much time lately to stay around here), and I also like the ideas in cad-query |
| 09:36.30 | javampire | kanzure: in fact I was aiming for something similar, but wanted to get there step by step... |
| 09:36.46 | javampire | but if it's already done, why not use it... |
| 09:38.10 | javampire | kanzure: regarding the brlcad_new - it's needed because some of the BRL-CAD primitives can only be created using the C internal struct, and there's no BRL-CAD function exposed to create such a struct |
| 09:38.39 | javampire | and if you simply create the structure in straight ctypes code, it will use python's internal memory allocation methods |
| 09:38.56 | javampire | and BRL-CAD has the bad habit of freeing the passed in struct |
| 09:39.22 | javampire | so you get segmentation faults - was real hard to figure out why when I started the wrappings |
| 09:41.07 | javampire | the solution is to use BRL-CAD memory allocation functions to allocate those structs - and the problem Raj was facing is that apparently BRL-CAD uses multiple ways of allocating memory, and the brlcad_new function was using malloc only, while the struct wrapped by Raj was using the calloc flavor |
| 09:44.16 | javampire | kanzure: if you don't like the brlcad_new name, please by all means refactor it and give it a better name, same for all code - I take mostly random decisions on such things as I want to progress and not to write perfect code (I tend to get stuck on such decisions) |
| 09:45.29 | javampire | kanzure: I didn't spend much effort on the B-Rep code to wrap it, but Raj's GSOC project's second part is entirely dedicated to that subject |
| 09:46.38 | javampire | kanzure: it will be likely a challange to figure out how to wrap the C++ code which is stubbed out by that _on_brep_placeholder when using C compiler, but I'm sure we'll figure out a way to do it |
| 09:54.52 | javampire | kanzure: again, related to the memory management problems - I agree it is suboptimal, but it can only be fixed inside core BRL-CAD, which I avoided to touch for the moment |
| 09:56.52 | javampire | pushing through a core BRL-CAD change is orders of magnitudes harder than working it around in python-brlcad, and I'm probably known around here for my lack of patience ;-) |
| 11:43.21 | ``Erik | "want to hear a tcp joke?" https://twitter.com/stevewerby/status/482515112906215424/photo/1 |
| 11:45.06 | archivist | groan...at least it was not a udp joke with packets dropped |
| 13:11.01 | ``Erik | <-- big fan of horrible jokes and tearable puns ( http://koster.typepad.com/.a/6a00d834207ee653ef017d41bff30a970c-800wi ) |
| 14:31.30 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 14:58.44 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:02.09 | *** join/#brlcad alisha (~alisha@106.192.176.214) | |
| 15:22.53 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 15:29.41 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 15:49.05 | *** join/#brlcad hcurtis (b82d34a8@gateway/web/freenode/ip.184.45.52.168) | |
| 16:17.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:32.56 | starseeker | brlcad: my concern is whether or not the crediting requirement propagates beyond just us to any of our downstream users (that appears to be the GPL compatibility issue (with v2 anyway) and I suspect it might be incompatible with LGPLv2 as well.) |
| 16:33.26 | *** join/#brlcad piyushparkash (~piyushpar@117.205.72.210) | |
| 16:35.16 | starseeker | we can't use the GPL license for freetype, so it's got to be the other one |
| 16:39.48 | starseeker | is actually tempted to see if stb_truetype.h and http://clb.demon.fi/files/RectangleBinPack might serve as a viable fall-back if freetype isn't available - they would be a heck of a lot smaller and easier to maintain in src/other than freetype itself |
| 16:42.39 | starseeker | even fblabel + vfont look a lot better than the no-font-available openscenegraph default - perhaps the better approach would be to study what fblabel does and do that more generally... |
| 16:44.55 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 17:18.12 | Notify | 03BRL-CAD:brlcad * 61473 brlcad/trunk/sh/enumerate.sh: almost done, major restructuring of the output to be serially printed instead of hierarchically. mid-progress reducing the duplication. |
| 17:27.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 17:53.46 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 18:12.18 | *** join/#brlcad jasleen14 (~jasleen14@117.255.242.103) | |
| 18:55.06 | starseeker | Ah hah. Mikko Mononen's fontstash may be what I was looking for - it seems to pull together all the individual pieces that were looking interesting into a working whole |
| 18:57.11 | starseeker | (github fork of the memononen repo with CMake build here: https://github.com/starseeker/fontstash) |
| 18:59.00 | starseeker | Not bad for 133k in 3 header files and 7.3k of example.c (not counting glfw) |
| 18:59.30 | starseeker | heck of a lot lighter than freetype... |
| 18:59.54 | starseeker | need to try it with the fonts that are of interest to us, of course... |
| 19:25.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 20:31.15 | *** join/#brlcad piyushparkash (~piyushpar@117.205.72.210) | |
| 20:31.48 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7431 /wiki/User:Vladbogolin/GSoC2014/Logs: /* Week 6 */ |
| 21:37.49 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 21:57.21 | *** join/#brlcad piyushparkash (~piyushpar@117.205.72.210) | |
| 22:01.37 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |