| 00:17.48 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 00:42.04 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 00:49.25 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 01:21.31 | *** join/#brlcad LordOfBikes (~armin@dslb-092-074-236-053.092.074.pools.vodafone-ip.de) | |
| 01:50.35 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 03:23.55 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 07:04.57 | brlcad | teepee: apologies on the delay responding but it looked great to me |
| 07:05.12 | brlcad | I think we should run with it if we can |
| 07:10.10 | brlcad | tbrowder: I'm a bit behind on e-mail, so no I haven't just yet but I did see your name in my upcoming queue of mails |
| 09:31.12 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 09:36.21 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 09:42.45 | *** join/#brlcad merzo (~merzo@195.20.130.10) | |
| 10:03.41 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 11:30.08 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 11:39.02 | tbrowder | brlcad: i fugured you are swamped, but then i just started worrying about you, but nothing urgent here |
| 12:16.38 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 13:02.10 | *** join/#brlcad yorik (~yorik@2804:431:f721:f1ce:290:f5ff:fedc:3bb2) | |
| 14:49.19 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 15:52.48 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 16:25.37 | teepee | brlcad: sent out a couple of invitations to the github org - just as member, I'll leave status promotion to you :) |
| 16:28.05 | teepee | I did ask Gina from octoprint if she would be interrested, I guess we can talk after the org publication again |
| 16:29.06 | teepee | I wonder if it would make sense to also ask klipper (new 3d printer firmware project) |
| 17:06.53 | starseek1r | brlcad: I'm getting ready to tag - anything you know of that is a show-stopper? |
| 17:07.52 | brlcad | starseeker: not show-stoppers, no |
| 17:08.13 | starseeker | anything pending that's worth holding off a day or two? |
| 17:08.30 | brlcad | littany of bugs being worked |
| 17:08.45 | starseeker | um. eta? |
| 17:08.59 | brlcad | I think the most important is probably the gqa issue, but still not a release blockr |
| 17:09.51 | starseeker | k - I'll roll then, and we can follow on with a patch if we need to |
| 17:13.46 | brlcad | unrelated, I think I've settled on a workable solution for primitive descriptions, to replace the ad hoc tcl listings, and perhaps be the serialization backend for commands too |
| 17:14.08 | brlcad | will write it up after I get through these bugs/issues |
| 17:14.57 | brlcad | related to release, the metaball bug might be the only worth holding on since it affects |
| 17:18.19 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 17:18.43 | starseeker | brlcad: ah, right, the metaball issue. |
| 17:18.57 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 17:19.47 | starseeker | brlcad: if we can swat that one quickly that's a point, but I think it's also present in older releases? (i.e. we aren't introducing a regression?) |
| 17:20.05 | brlcad | I did not check that |
| 17:21.45 | brlcad | just tested, it's at least present in 7.24 |
| 17:22.09 | brlcad | 7.24.0 |
| 17:22.19 | brlcad | so yeah, not news |
| 17:22.23 | starseeker | ok |
| 17:22.24 | brlcad | *new |
| 17:22.42 | brlcad | almost certainly related to the overlapping bounding boxes |
| 17:23.02 | starseeker | I'm not familiar with that code - how thorny is it looking? |
| 17:24.34 | brlcad | I don't know that yet |
| 17:25.04 | starseeker | k. I'll go ahead and get most of the grunt work out of the way - the merges are large this go around with the date updates in all files |
| 17:31.20 | brlcad | do we really have no good routine for pretty-printing a matrix? I find that hard to believe but am coming up wanting. |
| 17:41.20 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 17:45.48 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 18:00.52 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 18:55.49 | starseeker | um... bn_mat_print? |
| 18:56.28 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 19:07.24 | brlcad | starseeker: it sucks |
| 19:08.00 | starseeker | ah. yeah, that's the only one I'm aware of |
| 19:09.20 | brlcad | it does a straight up lossy %8.3f |
| 19:09.40 | brlcad | opennurbs has one and it kind of sucks too |
| 19:09.52 | brlcad | Matrix (4 rows 4 columns) |
| 19:09.52 | brlcad | <PROTECTED> |
| 19:09.52 | brlcad | <PROTECTED> |
| 19:09.52 | brlcad | <PROTECTED> |
| 19:09.52 | brlcad | <PROTECTED> |
| 19:09.54 | brlcad | MATRIX my label: |
| 19:09.57 | brlcad | <PROTECTED> |
| 19:09.59 | brlcad | <PROTECTED> |
| 19:10.02 | brlcad | <PROTECTED> |
| 19:10.04 | brlcad | <PROTECTED> |
| 19:10.13 | brlcad | first is OpenNURBS, second is bn_mat_print() |
| 19:11.40 | starseeker | hmm. you'd prefer the ability for the caller to specify numerical precision when printing out? |
| 19:12.50 | brlcad | optionally, but no -- by default just printing full precision without printing fuzz/noise |
| 19:13.17 | brlcad | like all those 1's and 0's should just be 0.0 and 1.0 |
| 19:13.45 | brlcad | columns should be lined up, not like this (which is what the other libbn mat print func does): |
| 19:13.50 | brlcad | 1.123123123 0 0 0 |
| 19:13.50 | brlcad | 0 1 0 0 |
| 19:13.50 | brlcad | 0 0 1 0 |
| 19:13.50 | brlcad | 0 0 0 1 |
| 19:14.32 | starseeker | ah |
| 19:14.40 | brlcad | I'm just a little surprised given how much we do this |
| 19:15.06 | starseeker | must confess it's only been during very specific debugging scenarios he's actually dumped the numerics of a matrix |
| 19:15.07 | brlcad | but I see lots of places in the code even just do a straight up iteration over 16 and %g the values 4 per line |
| 19:15.24 | brlcad | red/ted need it |
| 19:15.36 | brlcad | I think that was one of the many custom ones |
| 19:16.22 | starseeker | nods - I think the thinking there was that hand-editing a matrix in red/ted isn't likely to be practical (too much chance of an invalid matrix getting specified by accident) so there wasn't any point in making them pretty |
| 19:18.40 | brlcad | useful though if only to read it (oh, that's a scale ... oh that's a translation, etc) |
| 19:19.04 | brlcad | it simply does a newlineless version of the 3rd form: 1.123123123123e+00 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 |
| 19:19.12 | brlcad | with a space between rows |
| 19:19.50 | starseeker | actually, in that scenario, it would probably be more useful to present it in exactly that fashion (translate, scale, rot components) |
| 19:19.51 | brlcad | starseeker: did you have a function that would report the number of precision digits? |
| 19:19.58 | brlcad | that you were using for nirt? |
| 19:20.23 | starseeker | you mean when parsing it? I don't think so - I think I was using the C++ streams |
| 19:20.26 | starseeker | one sec... |
| 19:21.00 | starseeker | _nirt_str_to_dbl in libanalyze/nirt.cxx |
| 19:21.24 | brlcad | I can write something up for this, but still looking to not waste time if someone already has done this well enough |
| 19:21.27 | brlcad | looks |
| 19:22.42 | starseeker | don't have any pretty-printing though - nirt's bits are stricly for getting the floating point numbers in and out, while trying to be able to reproduce the in-mem number precisely for debugging purposes at need... |
| 19:23.39 | brlcad | hm, so actually need the reverse -- dbl_to_str |
| 19:24.00 | starseeker | that's the one above it, iirc |
| 19:24.00 | brlcad | how are you testing it? |
| 19:24.07 | brlcad | ah, looking again |
| 19:25.18 | starseeker | um. I don't know that I've actually got a proper reproducibility unit test set up - the key for me when when I could precisely replicate shots from nirt outputs reading them back in as strings |
| 19:26.12 | starseeker | it felt like those bits probably belong as wrapped logic down in libbn somewhere, but at the time I was focused on other stuff and the C++11 way was the 'easy' way to get what I was looking for in terms of precision control and parsing |
| 19:28.50 | starseeker | the dbl_to_str logic isn't actually active yet - I was setting up for ray partition diffing and reporting, but ran out of time/steam before that part got up and running |
| 19:30.47 | brlcad | hm, so nirt's form is interesting, full representation precision |
| 19:31.06 | starseeker | yeah, that was newly introduced in the libanalyze refactor |
| 19:31.57 | brlcad | it's not quite right for printing, at least not what was specified, but I'd have to do some homework to figure out how the other forms are getting it right |
| 19:32.49 | brlcad | and the undesirable repetition still for useful printing: |
| 19:32.50 | brlcad | 1.12312312312299989 0.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 1.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 1.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 1.00000000000000000 |
| 19:33.18 | starseeker | yeah, readability wasn't/isn't the goal in that particular case |
| 19:33.50 | brlcad | interestingly, only one of the four methods correctly prints what the code specified |
| 19:34.27 | brlcad | (i.e., double vals[16] = {1.123123123123,0,0,0 ... -> 1.123123123123e+00) |
| 19:35.03 | brlcad | that's ged's pretty-printer |
| 19:35.14 | starseeker | not sure I'm following - you're saying I've got a bug in the nirt string<->dbl code? |
| 19:35.22 | brlcad | looks like it just got lucky |
| 19:35.52 | brlcad | no, not a "bug" per se |
| 19:36.14 | brlcad | code is 1.123123123123, so naturally one would like to see that printed |
| 19:36.25 | brlcad | without resorting to fixed point or other hoops |
| 19:36.39 | brlcad | ged's printer got it right, but it was just by luck |
| 19:36.57 | brlcad | 1.123123123123 cannot be exactly represented, but is the ideal output |
| 19:37.44 | starseeker | ah. I'd probably check the C++ string features to see if they've got something for that, myself... |
| 19:37.46 | brlcad | printing full precision (i.e., what you're doing in nirt, i.e., 1.12312312312299989) is the next best output |
| 19:38.34 | brlcad | there's no way to know, I was just surprised one of them got it right .. turns out it used %.12e so it printed 12 precision .. |
| 19:39.03 | starseeker | what does %g do? |
| 19:39.20 | brlcad | %g is crap for pretty-printing |
| 19:40.34 | brlcad | it prints 1.12312 in this case, default .5 precision |
| 19:40.43 | starseeker | ah |
| 19:41.01 | brlcad | it however does a much better job on integral printing: |
| 19:41.07 | brlcad | 1.12312, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 |
| 19:41.52 | brlcad | debatable whether 0 0 0 1 or 0.0 0.0 0.0 1.0 make for a better default |
| 19:42.25 | starseeker | would vote the former, for easier reading... |
| 19:42.29 | brlcad | probably sans decimal |
| 19:43.19 | brlcad | and I'm back to a fully custom pretty-printer that scans all values for lengths before and after the decimal |
| 19:43.28 | brlcad | which really seems like something we should have implemented somewhere already |
| 19:43.57 | starseeker | brlcad: what about %.15g - does that do anything interesting? |
| 19:44.06 | brlcad | I'll probably implement it and in the process of updating the 1000 places that do matrix printing find one doing it the way I wanted |
| 19:44.16 | starseeker | heh |
| 19:44.37 | brlcad | that's just 15 digits of precision, not exponential form |
| 19:45.01 | starseeker | won't it give you the 1.123123123123 output? |
| 19:45.51 | brlcad | it does in this instance |
| 19:49.12 | brlcad | we're getting sort of lucky that there is only one digit of precision on the lhs |
| 19:51.13 | starseeker | ah, k |
| 20:09.03 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 21:46.30 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 21:51.05 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 22:04.00 | starseeker | finally. |
| 22:04.05 | brlcad | indeed |
| 22:04.40 | starseeker | loves those first-after-year-update merges, always a blast... |
| 22:05.05 | brlcad | hh |
| 22:05.21 | starseeker | brlcad: if you want to fire off a distcheck-full on the Mac it would be helpful... |
| 22:06.20 | starseeker | I'll re-confirm we're good on Windows |
| 22:06.27 | brlcad | sure, can do |
| 22:07.48 | starseeker | I usually just check make check on BSD, since afaik we still can't reliably complete due to the threading exhaustion issue |
| 22:22.04 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 23:18.43 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 23:29.04 | *** join/#brlcad kintel (~textual@unaffiliated/kintel) | |
| 23:36.20 | *** join/#brlcad merzo (~merzo@2-38-133-95.pool.ukrtel.net) | |