| 00:08.50 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 00:24.33 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
| 02:46.58 | Notify | 03BRL-CAD Wiki:Harman052 * 6409 /wiki/Online_Geometry: |
| 03:09.21 | Notify | 03BRL-CAD Wiki:Harman052 * 6410 /wiki/Online_Geometry/TODO: Content added |
| 03:21.47 | Notify | 03BRL-CAD Wiki:Harman052 * 6411 /wiki/Online_Geometry/TODO: Formatting improved |
| 03:22.23 | Notify | 03BRL-CAD Wiki:Harman052 * 6412 /wiki/Online_Geometry/TODO: /* New Features */ |
| 03:22.45 | Notify | 03BRL-CAD Wiki:Harman052 * 6413 /wiki/Online_Geometry/TODO: /* New Features */ |
| 03:40.21 | Notify | 03BRL-CAD Wiki:Harman052 * 6414 /wiki/Online_Geometry/TODO: |
| 03:42.29 | Notify | 03BRL-CAD Wiki:Harman052 * 6415 /wiki/Online_Geometry/TODO: /* Enhancements */ |
| 03:47.06 | Notify | 03BRL-CAD Wiki:Harman052 * 6416 /wiki/Online_Geometry/TODO: |
| 03:48.27 | Notify | 03BRL-CAD Wiki:Harman052 * 6417 /wiki/Online_Geometry/TODO: |
| 03:49.33 | Notify | 03BRL-CAD Wiki:Harman052 * 6418 /wiki/Online_Geometry/TODO: |
| 04:01.59 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
| 05:24.07 | *** join/#brlcad werebutt (~buttbutt@46.165.251.66) |
| 05:24.07 | *** part/#brlcad werebutt (~buttbutt@46.165.251.66) |
| 05:24.42 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
| 05:34.47 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) |
| 05:50.43 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) |
| 09:46.13 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 10:44.41 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 10:53.36 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) |
| 10:59.20 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 11:45.33 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 12:30.43 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 12:41.11 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 13:52.17 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 14:01.28 | Notify | 03BRL-CAD:starseeker * 59531 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Set description to blank string as well to avoid step-g complaining about incomplete expressions |
| 14:34.22 | Notify | 03BRL-CAD Wiki:Harman052 * 6419 /wiki/Online_Geometry/TODO: |
| 14:36.33 | Notify | 03BRL-CAD Wiki:Harman052 * 6420 /wiki/Online_Geometry/TODO: /* Research work */ |
| 14:46.48 | Notify | 03BRL-CAD Wiki:Harman052 * 6421 /wiki/Online_Geometry/TODO: /* Enhancements */ |
| 14:49.49 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 14:58.16 | Notify | 03BRL-CAD:starseeker * 59532 brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: We do want to duplicate trims here - avoids a crash in g-step |
| 15:31.46 | ``Erik | starseeker: "yalo" https://github.com/whily/yalo lithp on bare metal x86-64 |
| 15:33.45 | Notify | 03BRL-CAD:starseeker * 59533 brlcad/trunk/src/librt/primitives/eto/eto_brep.cpp: If eip->eto_C is parallel to eip->eto_N, the brep conversion routine has problems. Try the x and y vectors if eto_C is parallel - one of them should work... |
| 16:48.46 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 16:48.59 | Notify | 03BRL-CAD:starseeker * 59534 brlcad/trunk/CMakeLists.txt: Add a test for lrint - not sure yet what to do when we haven't found it... |
| 16:49.27 | Notify | 03BRL-CAD:starseeker * 59535 brlcad/trunk/CMakeLists.txt: ws |
| 16:56.09 | brlcad | starseeker: ah, you beat me to it |
| 16:56.42 | brlcad | that was on my to-do for today, so thanks |
| 16:57.00 | brlcad | I need to figure out an approach for all of them since this pattern is recurring |
| 16:57.16 | starseeker | brlcad: that's just the detection - I'm not sure what to do to actually make it work |
| 16:57.45 | brlcad | what do you mean? |
| 16:58.06 | starseeker | I mean that test tells me when we don't have lrint, but I don't know what to do about it in libbu and friends |
| 16:58.27 | starseeker | if I do the define trick we have for Windows, won't it give me casting complaints? |
| 16:58.35 | brlcad | we always "have it" afaik |
| 16:58.44 | brlcad | we just don't always get it declared |
| 16:59.02 | starseeker | uh... |
| 16:59.04 | brlcad | that's in a category of functions that are compiliance-related |
| 16:59.26 | brlcad | just a pedantic detail, windows is the only that doesn't actually have it iirc |
| 16:59.41 | starseeker | so, what do we do to make libbu think we have it? |
| 16:59.48 | starseeker | or aware we have it, I guess |
| 16:59.57 | brlcad | that's what I'm working through now |
| 17:00.07 | starseeker | ah. |
| 17:00.11 | brlcad | that's the general approach I was referring to |
| 17:00.21 | brlcad | because there's at least a dozen symbols like this |
| 17:00.25 | starseeker | oh, I thought you were talking about the compile-source tests in CMake :-) |
| 17:01.25 | brlcad | certainly related, because we need to know 1) if it's actually available (i.e., it's a function in libc), 2) whether it's declared (i.e., a header announces it) to do anything about either failing |
| 17:02.37 | brlcad | the solution that should work is to just do those two tests, then make a source change to handle the case where it exists but is not declared (and if we need to, the case where it's not available) |
| 17:06.25 | starseeker | brlcad: is it worth all that vs just defining bu_lrint and whatever other functions of that type we would need and calling it a day? |
| 17:08.01 | starseeker | presumably if a header doesn't announce it, the intent of the system is that it not be used? |
| 17:08.09 | brlcad | it if were just one, perhaps |
| 17:08.13 | brlcad | but there are at least a dozen |
| 17:08.40 | starseeker | how many would go away once we bump to C99? |
| 17:08.47 | brlcad | and, no, there's no intention .. it's not announced because we requested a particular mode of compilation |
| 17:08.52 | brlcad | all |
| 17:09.07 | brlcad | nearly all at least |
| 17:09.29 | brlcad | it would have maybe been an issue 15 years ago |
| 17:09.34 | starseeker | in that case, the wrapper functions would only be present for a short while - just until we get to C89 strict |
| 17:09.55 | brlcad | then we would have needed to handle the actually-doesn't-exist case |
| 17:10.40 | starseeker | is dubious - it sounds to me like we're sort of breaking the C89 paradigm we're requesting to get the functions we need... |
| 17:10.49 | starseeker | if we do that, what's the point of C89? |
| 17:10.54 | brlcad | you mean the 6-60 months it takes to actually deprecate it, rescrub sources, update calling code that might have relied on it |
| 17:11.33 | brlcad | I'm not looking for strict academic compliance, that does very little for us to obsess on the past too much |
| 17:11.49 | brlcad | we just need some assurance that we'll work, a baseline that is good enough |
| 17:12.11 | brlcad | some of the symbols are dangerous and easily won't exist, most of which we already have wrapped |
| 17:12.17 | brlcad | others like lrint, not so much |
| 17:13.13 | brlcad | one line in cmake and three or four in a header is not so bad |
| 17:13.24 | starseeker | OK - I always lose these arguments anyhow, so I'll just go with it |
| 17:13.47 | brlcad | but what's wrong with the alternative? |
| 17:14.22 | starseeker | we'll see how it ends up looking - I don't know what you're going to have to do, so I can't visualize it |
| 17:14.23 | brlcad | rather aim for simplicity in our code, this gets that |
| 17:15.03 | starseeker | we'll see |
| 17:15.20 | brlcad | always the optimist ;) |
| 17:15.40 | starseeker | thinks this feels like jumping through hoops to avoid going straight for C99 |
| 17:16.26 | starseeker | however, you're the expert :-) |
| 17:16.38 | brlcad | this was started a LONG time ago |
| 17:17.37 | brlcad | if we were this close with c99, it'd feel like jumping through hoops instead of just jumping to C11 |
| 17:18.24 | starseeker | except C11 isn't 14 years old ;-) |
| 17:18.53 | brlcad | it very well could be if we address it at the same rate that we've addressed c89 |
| 17:18.55 | brlcad | (that's the point) |
| 17:19.32 | brlcad | s/could/will/ |
| 17:22.21 | brlcad | it this all works out they way it should, our source changes will just be a few lines in a header file that won't need to change when we go to c99 or c11 |
| 17:23.15 | brlcad | only work will be for functions that go from not missing to missing, then we have to decide whether to change our code or implement what went away |
| 17:23.54 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 17:23.57 | starseeker | nods |
| 17:31.49 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 17:40.54 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 17:41.06 | mpictor | I'm looking for a cross-platform way to recursively delete directory contents from c/c++ |
| 17:42.13 | mpictor | looks like I need to use nftw() on linux and osx, and SHFileOperation() on windows. or is there something simpler that will work on all 3? |
| 17:52.35 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 18:06.34 | brlcad | mpictor: man remove |
| 18:07.38 | brlcad | rather, are you looking for cross-platform traversal or cross-platform deleting? |
| 18:11.58 | brlcad | for traversal, what you found should work but ... deleting recursively is rather dangerous |
| 18:15.42 | brlcad | I suggest keeping a manifest, and just delete your manifest .. safe, robust, and if remove() fails on a directory after you remove all your files+dirs, the user put files+dirs there |
| 18:16.01 | brlcad | otherwise, remove() will also remove files and dirs |
| 18:30.01 | mpictor | brlcad: now that I think about it, it won't hurt anything if extra files accumulate in subdirectories of the build dir |
| 18:30.18 | mpictor | so I don't need recursive delete |
| 18:34.14 | mpictor | a manifest is a good idea though, I'll keep it in mind |
| 20:06.56 | Notify | 03BRL-CAD:carlmoore * 59536 brlcad/trunk/src/lgt/do_options.c: despite its use for the now-deprecated lgt, I have implemented h and ?, using bu_optopt because '?' is the default for c |
| 20:09.50 | *** join/#brlcad luca79 (~luca@13.113.227.87.static.ld.siw.siwnet.net) |
| 20:18.33 | Notify | 03BRL-CAD:starseeker * 59537 brlcad/trunk/src/conv/step/g-ap214/CMakeLists.txt: Try adding the /bigobj to the AP214 generated C++ file |
| 20:39.41 | *** join/#brlcad ncsaba__ (~ncsaba@p4FF75894.dip0.t-ipconnect.de) |
| 20:40.47 | ncsaba__ | kanzure: Hi Bryan, I just created another pull request for python-brlcad :-) |
| 20:42.35 | brlcad | cool |
| 20:42.36 | ncsaba__ | this time it is actually useful stuff I think - some python syntax sugar around libwdb |
| 20:42.41 | kanzure | howdy |
| 20:42.44 | kanzure | okay |
| 20:42.54 | kanzure | btw i haven't merged your other work yet (well, some of it) |
| 20:43.03 | ncsaba__ | no prob, it's independent |
| 20:43.05 | kanzure | because i am having trouble determining if there are any regressions in functionality |
| 20:43.27 | ncsaba__ | yes, I understand, it's a complex change... |
| 20:43.37 | ncsaba__ | I wanted it in smaller pieces but couldn't manage |
| 20:43.38 | kanzure | "For the windows port - for now I gave up on making it work well, librt doesn't want to work either with cygwin nor with mingw. The path problems are solved, but there is some fundamental problem somewhere in ctypesgencore which I just don't have the motivation to debug to it's end." |
| 20:43.51 | kanzure | if you can collect some details about the ctypesgencore issues i can take a look. i have spent some time poking around in there. |
| 20:43.52 | ncsaba__ | yes, but that was not better before :-) |
| 20:44.13 | ncsaba__ | I added myself librt, and it seems to only work on linux |
| 20:44.27 | kanzure | did you have any trouble with macros? |
| 20:44.31 | kanzure | i am looking at https://github.com/kanzure/python-brlcad/pull/13 |
| 20:44.38 | ncsaba__ | if you scracht librt then windows installs too |
| 20:45.05 | ncsaba__ | the windows error was something with a long long type |
| 20:45.21 | ncsaba__ | it is not supported by ctypes, and it is supposed to be skipped by ctypesgen |
| 20:45.27 | kanzure | in general i am against 'from ctypes_adaptors import *' and prefer 'from ctypes_adaptors import (\n thing1,\n thing2,\n)' but it is a minor nitpick |
| 20:45.28 | ncsaba__ | but somehow it manages to not skip it |
| 20:46.10 | kanzure | i am not really sure what a long long is at the moment (i am in python mode..) |
| 20:46.15 | ncsaba__ | well just fix it then, it was just quicker to develop this way |
| 20:46.30 | kanzure | brlcad: approximately how many crippling changes are you willing to make to brlcad to make it play nice with python/ctypesgencore? :) |
| 20:46.32 | ncsaba__ | I don't mind, if it works :-) |
| 20:47.02 | kanzure | "class WDB:" btw i highly recommend always at least subclassing object, so "class WDB(object):" |
| 20:47.04 | ncsaba__ | well have a look at the test I wrote |
| 20:47.25 | ncsaba__ | well again: do it, I'm a python beginner still |
| 20:47.48 | kanzure | yep, anyway i'm fine with these changes, i'm merging |
| 20:48.19 | ncsaba__ | the current wrapper is already allowing you to easily build the most useful geometry elements |
| 20:48.19 | kanzure | merged |
| 20:48.28 | ncsaba__ | and all with python "duck typing" |
| 20:48.49 | ncsaba__ | that was my first goal for now |
| 20:49.12 | ncsaba__ | I can now easily script some objects, with the power of python instead of fighting with tcl |
| 20:49.44 | ncsaba__ | I will post some real objects later, just to demonstrate what I mean... |
| 20:49.46 | kanzure | it's too bad that WDB.cone doesn't return the physical cone that was constructed. hrm. |
| 20:49.50 | kanzure | okay cool |
| 20:49.52 | kanzure | i like examples |
| 20:50.17 | ncsaba__ | what do you mean by the cone ? |
| 20:50.33 | kanzure | well, if i construct a cone, presumably i can have a reference to the cone that was just made |
| 20:50.36 | ncsaba__ | in fact all objects show up well in my tests, except the hyperboloid |
| 20:50.52 | kanzure | like, cone = wdb.cone(settings, whatever); cone.x = 5; cone.some_other_attribute = 5114 |
| 20:51.00 | ncsaba__ | ok, it doesn't work that way, sorry |
| 20:51.07 | ncsaba__ | wdb is write only |
| 20:51.08 | kanzure | (i don't know if x would be a realistic attribute of a cone) |
| 20:51.24 | kanzure | oh, the actual wdb methods don't return a pointer to the objects? i didn't consider that |
| 20:51.44 | ncsaba__ | librt will help do that |
| 20:51.50 | kanzure | oh it's direct write to a database file? |
| 20:51.51 | ncsaba__ | if we go that way |
| 20:51.53 | ncsaba__ | yes |
| 20:52.21 | ncsaba__ | but that's all you need to script some geometry ! |
| 20:52.55 | ncsaba__ | I will use high level python wrappers, they are much more flexible then the internal BRLCAD structures for actually _building_ the geometry |
| 20:53.17 | ncsaba__ | then serialize the result to a .g file, then raytrace |
| 20:53.35 | kanzure | i tried to make a simple python function to generate a png of the geometry, but i didn't come up with anything useful |
| 20:53.42 | kanzure | perhaps you will find a good way of doing that |
| 20:53.47 | ncsaba__ | will do |
| 20:53.51 | kanzure | (displaying a png is of course, much easier) |
| 20:54.17 | ncsaba__ | in fact I would settle for calling a brlcad executable and display the result :-) |
| 20:54.35 | ncsaba__ | if there's no library call which can directly do that |
| 20:55.15 | ncsaba__ | the best would be to be able to process the internal brlcad structures directly from python, but that's a real long road |
| 20:55.28 | ncsaba__ | the rt library is too tied to tcl |
| 20:56.10 | ncsaba__ | it has many features, and in this case that means lots of work till we could get any result in python with working directly with internal structures via the rt lib |
| 20:56.29 | ncsaba__ | I had a cursory look and it's not trivial |
| 20:56.34 | ncsaba__ | wdb was trivial |
| 20:56.57 | ncsaba__ | except figuring out why it dumps core on "mk_arbn" :-) |
| 20:57.22 | ncsaba__ | which in contrary to it's header, it does free the array it gets passed in |
| 20:57.47 | ncsaba__ | then python dumps core when it tries to free that again |
| 20:58.48 | ncsaba__ | OK, I will leave now - not sure when I'll have time again to work on this, but I'm definitely satisfied with what I got so far... |
| 21:00.14 | kanzure | hm, so yeah we should be able to represent the same internal structures, but i would posit that python would never have a database parser that isn't just pass-through to brlcad libs |
| 21:01.04 | ncsaba__ | well that's the whole point of having those libs :-) |
| 21:01.29 | ncsaba__ | but they are unfortunately off track a little bit because of the TCL stuff |
| 21:02.15 | ncsaba__ | for python I wouldn't embed python in brlcad though, as it is done with TCL, but the other way around |
| 21:03.06 | ncsaba__ | but for the moment I'm happy with only serializing things to BRLCAD from python high level objects, because that's exactly what I need anyway |
| 21:03.34 | ncsaba__ | I was not much using the GUI editing features before either, but scripting with TCL - and that's a real pain |
| 21:04.05 | ncsaba__ | I can show you some TCL scripts, they are simply unmaintainable |
| 21:04.47 | ncsaba__ | I discovered in the meantime python for myself - and like it more and more |
| 21:05.21 | ncsaba__ | anyway Bryan, please fix all the points you mentioned about inheriting object, imports, etc, it is definitely something I need to check out and remember for the next time :-) |
| 21:06.25 | ncsaba__ | OK, see you later, not sure when, I'll have some busy weeks next... |
| 21:07.12 | *** join/#brlcad FreezingAlt (~FreezingC@135.0.41.14) |
| 21:08.48 | *** part/#brlcad ncsaba__ (~ncsaba@p4FF75894.dip0.t-ipconnect.de) |
| 21:12.31 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 21:21.33 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 21:26.09 | Notify | 03BRL-CAD:carlmoore * 59538 brlcad/trunk/src/lgt/prnt.c: noticed a duplication of G option, so I kept the 4-argument occurrence and deleted the other one |
| 21:32.51 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 21:40.53 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 22:00.30 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 23:42.57 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) |
| 23:46.28 | *** join/#brlcad maths22_ (~gcimaths@66-118-151-70.static.sagonet.net) |