| 00:44.56 | brlcad | starseeker: there definitely is too much "public" redblack api in libbu terms |
| 00:45.35 | brlcad | frankly none of it should probably be public, instead providing higher level containers like hash, list, vector, map, with redblack under the hood (stl operates exactly that way) |
| 00:46.55 | brlcad | starseeker: before merging in the latest github sources, how many regression tests do we have? |
| 00:47.43 | brlcad | we need at least one test that exercises a variety of entities and hierarchy with mixed attributes (the cause of the last regression failure when we tried to update) |
| 00:48.26 | brlcad | if the nist samples do that, then by all means |
| 01:18.49 | starseeker | shakes his head - I doubt we have a test case like that to hand |
| 01:19.30 | starseeker | the NIST files (except for the 7-10 aggregation) are all single objects, and the 7-10 aggregation I had to do as a 3DM both for multi-color support and speed |
| 01:19.45 | starseeker | agrees we should build several test cases |
| 01:31.08 | starseeker | agrees - the log(n) behavior of the STL containers is one of my main drivers for using C++ - if we had set,map,etc. in C there'd be a lot less incentive |
| 01:37.49 | Stragus | I think I have written a bunch of such code... |
| 01:41.54 | starseeker | brlcad: can the bu_badmagic change be considered minimally impacting, or does it need deprecation? |
| 01:42.01 | starseeker | Stragus: not surprised :-) |
| 01:42.14 | Stragus | Besides, the C++ containers are terrible (unusable) for high performance multithreaded code |
| 01:42.58 | Stragus | If I'm not mistaken, you can't have 64 threads hammering the same C++ map, it would all have to be serialized on a single lock |
| 01:43.13 | starseeker | nods |
| 01:44.08 | Stragus | I think an early version of my hash table with concurrent multithreaded access is in the mesh decimation code |
| 01:44.36 | starseeker | might be worth pulling into libbu |
| 01:46.21 | Stragus | Just in case you are interested - http://www.rayforce.net/mmhash.c http://www.rayforce.net/mmhash.h http://www.rayforce.net/mmhashinternal.h http://www.rayforce.net/mmhashinline.h |
| 01:47.00 | starseeker | Stragus: cool! that's the latest version? |
| 01:47.52 | Stragus | Should be, it's meant to use atomics (pthread fallback) so there are minor dependencies on some other headers you probably have somewhere |
| 01:48.38 | starseeker | what's the state of atomics these days |
| 01:49.38 | starseeker | remembers discussing some of that with brlcad a while back, but I don't recall the details |
| 01:49.42 | Stragus | Frankly, no idea, always using my own inline assembly, but I'm sure you'll frown on that. I always include some slower pthread-based fallback... http://www.rayforce.net/mmatomic.h |
| 01:50.36 | starseeker | Stragus: that hasn't been too difficult to keep portable? |
| 01:51.10 | Stragus | The pthread fallback is portable, the problem is the big performance drop you get when not running on x86/amd64 with a GCC compatible compiler :) |
| 01:51.24 | Stragus | C11 is supposed to have atomics, but I have no idea what platforms are supported. And it's not exactly "complete" |
| 01:51.52 | starseeker | nor is it (or will it be) portable to MSVC unless C++ incorporates the C version |
| 01:51.55 | starseeker | grr... |
| 01:52.36 | starseeker | Stragus: do you set build flags manually, or are there a set of configure-time tests you've built up to detect ssystem capabilities? |
| 01:53.14 | starseeker | sees a lot of ifdefs in the atomics file, which is probably inevitable, but winces a little at the system introspection tests needed to drive it properly... |
| 01:53.37 | Stragus | I have never personally worried much about portability (I know that's a big problem for you guys...) |
| 01:53.45 | starseeker | heh |
| 01:54.04 | starseeker | at one point we actually built (non-graphically) on Haiku-OS |
| 01:54.19 | starseeker | should fix that, actually... |
| 01:55.22 | starseeker | can see atomics being a bit like openblas - high performance may require system specific tweaking... |
| 01:55.33 | brlcad | latest c11 and c++11 standards both have complete atomics support |
| 01:55.33 | Stragus | It bothers me when the inline assembly atomic version provides perfect scalability on a 64 cores machine (and beyond, probably), but some portable pthread-based solution just doesn't scale |
| 01:55.57 | brlcad | http://en.cppreference.com/w/c/atomic |
| 01:56.23 | starseeker | Stragus: oh, that reminds me - did you decide if you were going to release your high-performance OpenGL GUI element drawing library as a stand-alone? |
| 01:56.57 | Stragus | C11 atomics are missing a few important details... Let's say I have threads waiting in a spin loop for some variable to change, I really need to "rep nop" to tell a hyperthreading CPU core: "I'm a spin loop, try to run another concurrent thread" |
| 01:57.18 | Stragus | Without that, spin loops are a problem on hyperthreading processors |
| 01:58.27 | Stragus | starseeker: I would like to... Do you think you guys would perhaps use it? I would say that makes a difference on the grade of motivation :) |
| 02:00.24 | starseeker | Stragus: fair enough. for me, the biggest driver for Qt is the availability of things like html rendering widgets and tree widgets that are "pre-packaged" - I'm not sure if it's practical to code stuff like that up for a custom OpenGL interface |
| 02:00.26 | brlcad | Stragus: I'm not sure I'd agree that's a critical detail missing -- it's more a threading issue than anything to do with atomics, and there are so many ways to code around that |
| 02:00.52 | Stragus | Well brlcad, atomics are all about threads, this kind of stuff is very closely related |
| 02:01.22 | Stragus | starseeker: HTML rendering would be monstrous task, for sure |
| 02:01.47 | brlcad | that smacks of self-justification |
| 02:02.11 | brlcad | sure atomics are heavily used by threads and used for thread synching (among man other uses), but that's not their sole purpose |
| 02:02.24 | starseeker | Stragus: yeah, I think the most practical solutions I've seen for OpenGL have been those that render the html to an image |
| 02:02.42 | brlcad | thread api could just as well yield or be architected to not sit there spinning idle in the first place |
| 02:03.11 | Stragus | brlcad: Have you used atomics in a different context? While writing to device mapped memory I guess?... That's not very common |
| 02:03.25 | starseeker | ironically enough, tkhtml3 would probably be the most logical starting point for a "native OpenGL" html rendering widget, but small as it is compared to webkit there's still quite a lot of logic there :-/ |
| 02:04.11 | Stragus | I'm not fond enough of HTML to ever consider using it unless I'm forced to |
| 02:04.28 | brlcad | actually, yeah used it as an initialization construct to implement lock-free data structures |
| 02:05.59 | starseeker | Stragus: heh. Don't blame you - I use tkhtml3, but the few times I've tried digging into its guts I ended up backing away slowly... |
| 02:06.06 | Stragus | And an "yield" is totally different, that goes back to the OS which is something you never want in a spin lock, the "rep nop" just makes a hyperthreading processor switch to other threads resident on the CPU core |
| 02:09.25 | starseeker | ah, here's the library I was thinking of - the "C Container Library": https://github.com/starseeker/ccl - thought I'd stashed a copy before the google project vanished. |
| 02:11.03 | starseeker | over 300 pages of docs - don't know how good the library itself is implementation wise, but Jacob Navia clearly put a lot of work into it... |
| 02:11.27 | Stragus | Not thread safe, but there's quite a bit of work into that |
| 02:11.36 | Stragus | nods |
| 02:15.33 | Stragus | The self-balanced RB tree wasn't written to be as efficient as possible |
| 02:15.57 | starseeker | Stragus: yeah, it's probably not the solution I thought it might be when I first found it |
| 02:18.18 | starseeker | there are several RB implementations floating around online (one of the "nicer" looking ones, looking casually, is in sudo: https://github.com/millert/sudo/blob/master/plugins/sudoers/redblack.c) |
| 02:18.58 | starseeker | to my eye it looks well organized and readable, but I'm not sure if it's efficient |
| 02:22.40 | Stragus | It's less messy... but I still don't like this idea of having a "compare" callback find where to insert the node, among other things. The calling code can traverse the tree and find the insertion point in one function, without the overhead of 15 tiny function calls |
| 02:23.02 | starseeker | there's this: http://www.25thandclement.com/~william/projects/llrb.h.html |
| 02:25.16 | starseeker | not sure how the preprocessor-only approach works from a usability standpoint, but has the plus of duplicating the BSD api |
| 02:26.50 | Stragus | Doesn't seem to make sense if you get any "compare" and "key/value/whatever" out of the core tree code itself |
| 02:27.11 | Stragus | Headers with preprocessor abuse makes more sense when some critical callback has to be inlined, like sort functions |
| 02:29.13 | starseeker | suppose we'll end up implementing the public APIs we want and trying several rb backends to see what works best |
| 02:30.08 | starseeker | does confess that the combo of liberal license plus single small header appeals |
| 02:32.30 | Stragus | I tend to write everything from scratch and I'll probably stick to that :) |
| 02:33.07 | starseeker | chuckles - to each their own. I'm not smart enough to get away with that - I like having other people shake out the bugs before I add my own |
| 02:33.34 | Notify | 03BRL-CAD:brlcad * 68659 (brlcad/trunk/include/dm.h brlcad/trunk/src/libdm/dm-Null.c and 8 others): make the remainder of the dm device callback signatures all consistently return int |
| 02:35.22 | Stragus | Eh, I don't think it's a matter of smartness. I like writing my own reusable chunks because once I made them as optimized as possible, I never have to worry about it again |
| 02:35.38 | starseeker | until the hardware changes ;-) |
| 02:36.08 | Stragus | Yup. :) Mostly, mmatomic.h would have to be expanded with new architectures... |
| 02:36.32 | Stragus | As well as the SSE/AVX abuse |
| 02:37.35 | Stragus | It's hard to trust other people's code when performance matters. You would think qsort() with an inlined comparison function would be fast enough? But it's 30% slower than it should be! |
| 02:41.03 | Stragus | Sorry, 38% slower |
| 02:52.18 | starseeker | brlcad: do you know if anyone has ever looked into the possibility of using libpkg instead of Tcl channels for communication on Windows? I have very vague memories of trying it when I first arrived and finding out the hard way that libpkg didn't work on Windows, but I don't recall if I ever followed up further. It's an issue of more interest now, since that's one of the major pieces keeping a Tcl |
| 02:52.24 | starseeker | dependency in libged |
| 07:41.26 | *** join/#brlcad tandoorichick (b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
| 08:10.57 | *** join/#brlcad merzo (~merzo@188.173.16.122) |
| 09:15.32 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 09:35.34 | *** join/#brlcad Caterpillar2 (~caterpill@unaffiliated/caterpillar) |
| 09:35.53 | Caterpillar2 | hi, in next daya I will start working on including brl-cad into Fedora repositories |
| 12:08.31 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 12:49.17 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 13:33.19 | *** join/#brlcad Mandeep_Singh (~mandeep@117.220.151.253) |
| 13:36.20 | Caterpillar2 | :-) |
| 13:36.30 | starseeker | Caterpillar2: nice! |
| 13:37.05 | starseeker | it's been a while since anyone had a run at that - last effort I recall was the Redhat packaging effort, and that got hung up in the src/other stuf |
| 13:37.09 | starseeker | s/stuf/stuff |
| 13:38.27 | starseeker | ah yes https://bugzilla.redhat.com/show_bug.cgi?id=518949 |
| 13:39.10 | starseeker | so tnt/jama is no longer an issue |
| 13:39.18 | starseeker | openNURBS is still the same situation |
| 13:39.43 | starseeker | someone would need to package STEPcode, but in principle we should be able to work with them externally... |
| 13:41.06 | starseeker | there's been no change on the tkhtml3 and utah raster toolkit fronts - if someone needs those projects set up we could put a bit more effort into it |
| 13:42.44 | Caterpillar2 | starseeker: ah I did not know about that ticket. The libraries you just mentioned, are them included in brlcad? |
| 13:42.54 | starseeker | yes |
| 13:43.00 | starseeker | src/other subdirectory |
| 13:43.17 | Caterpillar2 | starseeker: ok, I will have to package them separately |
| 13:43.34 | starseeker | most of what's in src/other has packages already |
| 13:43.45 | starseeker | the ones I called out are the problem children |
| 13:44.02 | Caterpillar2 | children problem? |
| 13:44.34 | starseeker | er, sorry - libraries for which we expect difficulty with the Redhat/Fedora upstream |
| 13:44.39 | *** join/#brlcad tandoorichick (b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
| 13:44.48 | starseeker | libraries for which there are not already packages |
| 13:45.25 | Caterpillar2 | that is not a problem, we can package them. It will only require more time |
| 13:45.35 | starseeker | nods |
| 13:46.27 | Caterpillar2 | brlcad will be a good thing to push Fedora usage among engineers, etc |
| 13:47.41 | starseeker | fyi - I'm not sure the current CMake logic for RPM generation is correct |
| 13:47.46 | starseeker | in BRL-CAD |
| 13:50.49 | Caterpillar2 | starseeker: why? |
| 13:51.21 | Notify | 03BRL-CAD:starseeker * 68660 (brlcad/trunk/src/libpkg/example/client.c brlcad/trunk/src/libpkg/example/server.c brlcad/trunk/src/libpkg/tpkg.c): libpkg appears to be excluded from the normal repository regression tests, but I'm not seeing any reason to keep the stdio includes when bio.h is included... go ahead and remove for now. |
| 13:51.23 | starseeker | when I tried to generate an RPM for 7.26.0, it was a lot smaller than the tarballs |
| 13:51.45 | starseeker | I need to figure out why |
| 13:55.47 | Caterpillar2 | starseeker: so you have a quite working spec file? This will be a great help to start with |
| 13:56.07 | starseeker | not really - we use CMake's CPack mechanisms to create a package |
| 13:56.16 | starseeker | it generates a spec file, I believe |
| 13:56.51 | Caterpillar2 | starseeker: I don't know |
| 13:57.53 | starseeker | Caterpillar2: our logic for this starts in the top level CMakeLists.txt around line 2873 |
| 13:58.23 | Caterpillar2 | this is the list of packages that I (co)maintain in Fedora https://admin.fedoraproject.org/pkgdb/packager/germano/ |
| 13:58.53 | starseeker | nice! |
| 13:59.45 | Caterpillar2 | in my experience, everytime we add a package into Fedora repositories, we always have some nice exchange of ideas with upstream developers, so for sure something good will pop-up |
| 14:00.25 | starseeker | nods - I recommend reading over the older Redhat ticket - a couple of the issues are obsolete, but many still remain to be resolved |
| 14:00.35 | Caterpillar2 | my skill in making new packages of software writte in C is not high (I have taken orphaned packages), but I have very high skilled people that can suggest me |
| 14:00.56 | Caterpillar2 | yep I just subscribed to that ticket |
| 14:01.28 | starseeker | you'll probably want to start with stepcode, utahrle and perhaps openNURBS |
| 14:01.54 | starseeker | the primary difficulty with openNURBS is that we do patch it and so far our patches have not been accepted upstream |
| 14:02.40 | Caterpillar2 | starseeker: oh, why openNURBS upstream developers did not accept them? |
| 14:02.53 | starseeker | uh... it's a long story |
| 14:03.12 | starseeker | in one case there's a disagreement about what the "right" code is |
| 14:04.01 | Caterpillar2 | mmh... but we can take your patches and appy them to the corrispective Fedora package :-) |
| 14:04.21 | starseeker | that would be workable |
| 14:04.43 | starseeker | you may also want our build system for openNURBS ;-) |
| 14:05.35 | Caterpillar2 | what is made of? |
| 14:05.42 | starseeker | CMake |
| 14:05.50 | Caterpillar2 | ah ok |
| 14:06.09 | starseeker | fyi - there was apparently some interest in an openNURBS package back in 2011: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/JP2RTIBREMZ5SIFMJ35AHXXQDJHQPQLX/ |
| 14:06.35 | Caterpillar2 | I added a comment, so that if any of other Fedora contributors wants to help me, he can contact me https://bugzilla.redhat.com/show_bug.cgi?id=518949#c29 |
| 14:08.04 | Caterpillar2 | starseeker: I can contact the guy who wanted to package openNURBS |
| 14:08.22 | starseeker | I don't know if he made any progress - just something to be aware of |
| 14:10.53 | Caterpillar2 | starseeker: I have just made a query to find his name among Fedora contributors, but he seems to not be present. For your info, to do such queries, you have to query zodbot (that is present in all #fedora-* channels) and enter command fas name surname or fas nickname. Then you will get some results, and when you get his Fedora-Account-System name, you do: fasinfo foo |
| 14:11.13 | starseeker | ndos |
| 14:11.18 | starseeker | nods rather |
| 14:12.14 | starseeker | Caterpillar2: the stepcode upstream site is here: http://stepcode.org/ |
| 14:12.46 | starseeker | Caterpillar2: the openNURBS site is here: https://www.rhino3d.com/opennurbs |
| 14:12.58 | Caterpillar2 | ok |
| 14:13.17 | starseeker | I don't think we've synced our own sources to the latest openNURBS yet, so there may be a bit of work to do there |
| 14:13.57 | starseeker | this is the upstream project we started to establish for utahrle: https://sourceforge.net/projects/utahrle/ |
| 14:14.03 | Caterpillar2 | ok I will save this chat log, make a list of libraries that have to be packaged, and starting sorting my ideas |
| 14:14.29 | Caterpillar2 | I am going to add #brlcad to my autojoin channels list |
| 14:14.50 | starseeker | cool - good luck! |
| 14:15.07 | Caterpillar2 | ;-) |
| 14:15.34 | starseeker | another point - I know definitely at the moment that some parts of our code will not work with the new Itcl/Itk 4 packages |
| 14:15.48 | starseeker | if Fedora is on Tcl/Tk 8.6, that may be an issue |
| 14:16.02 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 14:17.24 | Caterpillar2 | you can find my email address at https://fedoraproject.org/wiki/User:Germano#Contact |
| 14:17.38 | Caterpillar2 | starseeker: is tcl/tk -->> tcl-tkpng.x86_64 : Tcl/Tk support for PNG ? |
| 14:18.13 | Caterpillar2 | mmh no it seems not |
| 14:25.37 | *** join/#brlcad tandoorichick (3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
| 14:26.07 | Notify | 03BRL-CAD:starseeker * 68661 brlcad/trunk/regress/repository.cmake: Add a mechanism to exclude files in the build directory, should it be located in the source directory. Can't do anything about the in-src-dir case (yet) but this is a start... |
| 14:26.09 | Notify | 03BRL-CAD:starseeker * 68662 brlcad/trunk/misc/CMake/test_srcs/sleep.c: another unistd include when we have bio |
| 14:50.50 | Notify | 03BRL-CAD:starseeker * 68663 brlcad/trunk/include/pkg.h: Add common.h to pkg.h, unless/until we find out there's a reason not to... |
| 14:56.22 | Notify | 03BRL-CAD:starseeker * 68664 brlcad/trunk/regress/repository.cmake: list a few more files and patterns we don't want to examine |
| 15:03.40 | Notify | 03BRL-CAD:starseeker * 68665 brlcad/trunk/regress/repository.cmake: There are a few 'public' headers that do have one or both of bio and bnetwork in them - excempt them from this check, since it hasn't been a regress-repository breaker... |
| 15:04.14 | Notify | 03BRL-CAD:starseeker * 68666 brlcad/trunk/src/burst/paint.c: Only include common.h once |
| 15:05.15 | Notify | 03BRL-CAD:starseeker * 68667 brlcad/trunk/src/libged/simulate/interface.cpp: common.h and ged.h get included regardless |
| 15:06.04 | Notify | 03BRL-CAD:starseeker * 68668 brlcad/trunk/src/libged/simulate/physics_world.hpp: add common.h |
| 15:36.02 | starseeker | brlcad: I notice that repository.sh doesn't report WIN32 et. al. instances in any of the include header files. Is this intentional? |
| 16:03.26 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 17:03.07 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:22.23 | *** join/#brlcad amarjeet (~Amarjeet@101.208.5.88) |
| 17:58.24 | *** join/#brlcad amarjeet (~Amarjeet@101.208.5.88) |
| 18:20.50 | *** join/#brlcad amarjeet (~Amarjeet@101.208.5.88) |
| 18:31.02 | *** join/#brlcad amarjeet (~Amarjeet@101.208.5.88) |
| 18:35.20 | *** join/#brlcad amarjeet (~Amarjeet@101.208.5.88) |
| 18:35.33 | *** join/#brlcad tandoorichick (b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
| 18:36.54 | *** join/#brlcad amarjeet (~Amarjeet@101.208.5.88) |
| 18:42.09 | *** join/#brlcad amarjeet_ (~Amarjeet@101.211.235.40) |
| 18:47.45 | *** join/#brlcad amarjeet (~Amarjeet@101.211.235.40) |
| 18:56.26 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 18:58.11 | brlcad | starseeker: pkg instead of tcl channels has been discussed before, but nobody has looked or tried |
| 19:02.35 | *** join/#brlcad amarjeet (~Amarjeet@101.211.228.237) |
| 19:03.14 | *** join/#brlcad amarjeet (~Amarjeet@101.211.228.237) |
| 19:04.29 | brlcad | starseeker: what do you mean it doesn't report headers? it does, was, or at least should be (see line 268) |
| 19:07.46 | brlcad | starseeker: also regarding pkg .. I think you tried before anyone had gotten libpkg compiling (nothing tricky, we just needed the winsock2 init bits and types) |
| 19:10.10 | *** join/#brlcad amarjeet_ (~Amarjeet@101.211.237.160) |
| 19:11.39 | brlcad | Caterpillar2: shall I set you as a maintainer for fedora, to receive release notifications? |
| 19:27.55 | *** join/#brlcad amarjeet (~Amarjeet@101.211.237.160) |
| 19:31.06 | starseeker | brlcad: my cmake scripts are reporting WIN32 instances in bu/defines.h, common.h and a few other headers - I'm not seeing these listed in the repository.sh report, unless I'm missing something |
| 19:31.28 | starseeker | trying to make the CMake script a full replacement for the .sh script, which means matching its results... |
| 19:33.23 | starseeker | I'm getting close to being ready to set up individual tests to do in parallel, but I don't want to do that until I've first achieved functional parity |
| 19:35.58 | Notify | 03BRL-CAD:starseeker * 68669 brlcad/trunk/regress/repository.cmake: Do less expensive matching tests before we go for the all-upregex match, although we have to be careful with this - common.h test, for example, looks for either system includes or common.h so we can't rely on a simple qualification test there. If this works as well as it seems to now, cuts execution time from about 70 seconds to a little over 30. |
| 19:36.00 | Notify | repository.sh is about 21, so if we can execute individual tests in parallel we should get a significant speed up overall. |
| 19:36.02 | Notify | ... |
| 19:40.35 | Notify | 03BRL-CAD:brlcad * 68670 brlcad/trunk/HACKING: add Caterpillar2 as a maintainer for fedora |
| 19:42.09 | brlcad | starseeker: they are printed in sections, headers first then sources then build files |
| 19:42.22 | brlcad | so maybe in a different section/earlier in the output? |
| 19:47.36 | Caterpillar2 | brlcad: ok |
| 19:48.48 | brlcad | Caterpillar2: cool, great! thank you |
| 19:49.21 | brlcad | you can pass the torch on at any time, it just means you'll get an e-mail notification whenever we push out a new release, so you can decide whether to update fedora |
| 19:56.12 | Notify | 03BRL-CAD:brlcad * 68671 (brlcad/trunk/include/ged/defines.h brlcad/trunk/src/libged/rt.c and 2 others): eliminate exposing tcl types and symbols in ged's public header, cast accordingly |
| 19:56.58 | Caterpillar2 | brlcad: ok |
| 19:59.12 | Caterpillar2 | brlcad: the process of bringing brlcad into Fedora repositories will take some months, because of various libraries that have to be included into Fedora repositories |
| 20:05.48 | brlcad | Caterpillar2: yes, I understand .. it's a lot of work and greatly appreciated! |
| 20:06.27 | Caterpillar2 | ;-) |
| 20:08.07 | Caterpillar2 | starseeker: brlcad: I have forgotten to also say that brlcad will be included in Fedora EPEL repositories too, that means that it will be available for RHEL, CentOS, ScientificLinux, Oracle Linux too |
| 20:09.21 | brlcad | that's great to hear |
| 20:09.48 | Caterpillar2 | https://fedoraproject.org/wiki/EPEL/ |
| 20:10.40 | brlcad | yeah, was just reading up on it |
| 20:11.16 | Caterpillar2 | :-) |
| 20:11.21 | brlcad | we manually pull together rpm's for RHEL currently |
| 20:12.03 | Caterpillar2 | brlcad: I have heard from starseeker that you use a particular way to make RPM packages |
| 20:12.09 | brlcad | oh, for what it's worth -- we have a variety of build materials in misc/ that may be of interest/relevance to you |
| 20:13.10 | brlcad | misc/archlinux, misc/brlcad.spec,.in and misc/debian in particular |
| 20:13.23 | Caterpillar2 | ah ok |
| 20:13.49 | brlcad | if it's helpful for you to store files or make changes, let me know and I'll get you set up so you can commit as needed |
| 20:15.30 | Caterpillar2 | brlcad: on which distro did you test the spec file? |
| 20:17.35 | brlcad | Caterpillar2: it was last used 4 years ago and just as a spec file for our manually prepared rpm installer, but maybe has some relevant/useful bits |
| 20:19.52 | brlcad | several distro managers (e.g., gentoo's ebuild) choose to maintain their build logic in their repo system, others stash their files into our repo for convenience |
| 20:20.56 | Caterpillar2 | brlcad: I am forced to use Fedora infrastructure. If I do not use it, I cannot update packages in official Fedora repositories |
| 20:21.21 | brlcad | that's fine, just giving you options ;) |
| 20:22.18 | brlcad | Caterpillar2: this may also be of interest, manual build instructions for linux lists some expected deps (should be fairly up-to-date): http://brlcad.org/wiki/Compiling |
| 20:22.59 | brlcad | I notice that list is not consistent with http://diyhpl.us/~bryan/irc/brlcad/doc/README.Linux ... |
| 20:25.32 | Caterpillar2 | brlcad: ah, I think that the http://diyhpl.us/~bryan/irc/brlcad/doc/README.Linux should be updated soon |
| 20:32.18 | brlcad | let me know what updates, or send a diff/patch ... that's in our repo |
| 20:32.50 | brlcad | it's in doc/README.Linux in a checkout if that wasn't obvious :) |
| 20:34.31 | Caterpillar2 | brlcad: I haven't seen it yet, but I said that after you wrote that there is a unconsistence between http://brlcad.org/wiki/Compiling and http://diyhpl.us/~bryan/irc/brlcad/doc/README.Linux |
| 20:40.04 | Caterpillar2 | which distro do you use usually? |
| 20:40.07 | brlcad | starseeker: only reason I can recall for disallowing bio/bnetwork/etc in public headers is because, like common.h, we don't yet define who owns them |
| 20:41.05 | brlcad | Caterpillar2: I hop all around, but most often on mac and freebsd |
| 20:41.26 | brlcad | main professional platform is rhel |
| 20:41.33 | brlcad | (and windows) |
| 20:44.29 | brlcad | while mostly mac and bsd, I also play/help a bit with haiku, rtems, and minix development |
| 20:45.46 | brlcad | starseeker: should just skip all of misc/ for repository testing, just like src/other |
| 20:47.39 | Caterpillar2 | brlcad: what is the homepage of upstream gct library? ( brlcad-7.26.0/src/other/gct/ ) |
| 20:48.34 | brlcad | it probably shouldn't be in src/other .. there is no upstream location |
| 20:50.29 | Caterpillar2 | brlcad: is it a library developed by brlcad developers? |
| 20:52.05 | brlcad | Caterpillar2: it's in src/other simply because it was written by a dev that doesn't usually write code for brl-cad (directly, at least), but as far as I know, we're the only public presence it has as that was code developed under contract for public release inclusion in brl-cad |
| 20:53.56 | brlcad | Stragus: care to comment on GCT? does it exist anywhere else such that fedora would point to it as a stand-alone thing that we depend on? |
| 20:56.29 | brlcad | Caterpillar2: it was primarily written by that guy there, so you can ask him.. ;) he has a habit of writing useful code and then not packaging it up |
| 20:56.34 | Caterpillar2 | brlcad: I asked because https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries and https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries so I started reading stuff in /others and searching of ach item, if there is already a package into Fedora repositories. GCT was the first occurrence of a /others library that is not present into Fedora |
| 20:56.36 | Caterpillar2 | repositories |
| 20:58.58 | brlcad | of i'm the opinion that it doesn't belong in src/other, that we should move it under one of our processing libs as a backend detail (not a stand-alone lib) |
| 20:59.53 | brlcad | so unless Stragus has some fundamental objection or plans to turn it into a project, give it a home, then we'll treat it as our code |
| 21:00.06 | brlcad | we kind of already did with a slew of widespread changes for portability |
| 21:01.04 | brlcad | we may even end up ripping it out if we can't eaily fix a few issues already encountered in the decimation logic |
| 21:01.11 | Caterpillar2 | how many stable developers are involved in brlcad? |
| 21:02.20 | brlcad | about a dozen depending on who you count |
| 21:02.49 | brlcad | ohloh says 6 in the last 30 days, 12 over past year, 84 committers over lifetime |
| 21:03.25 | brlcad | few more if you count the github repos which cover various web services |
| 21:05.47 | Caterpillar2 | does USA's army still spend money for its development or is it entirely in community hands? |
| 21:06.25 | brlcad | still spending quite a bit annually |
| 21:07.20 | brlcad | BRL-CAD is tightly integrated into a complex DoD analysis workflow so it's used by several agencies, Army in particular |
| 21:07.54 | Caterpillar2 | good to hear that money is spent for a product freely available for everybody |
| 21:08.17 | brlcad | it would probably cost $50.M USD minimum to uncouple BRL-CAD and do something different |
| 21:09.40 | Caterpillar2 | brlcad: what DoD stands for? |
| 21:09.46 | brlcad | ~dod |
| 21:09.46 | infobot | it has been said that dod is Dial on Demand, a way of making the modem dial whenever you try and send info to the inet |
| 21:09.50 | brlcad | heh, not that |
| 21:10.06 | brlcad | ~dod is also the U.S. Department of Defense |
| 21:10.06 | infobot | okay, brlcad |
| 21:10.10 | Caterpillar2 | ok |
| 21:12.26 | brlcad | open source has been catching up, though |
| 21:12.55 | brlcad | before this year's burnout lull, open source activity surpassed funded activity a number of times last year and the year before |
| 21:13.34 | brlcad | I'd like to see that grow even more, all the more reason we need better integration with repos, more devs working projects, scrape off our usability warts |
| 21:14.33 | Caterpillar2 | I will start asking some mechanical engineer professors at University of Rome Tor Vergata, to try using brlcad for their work, in order to get some nice feedbacks, etc. |
| 21:15.16 | brlcad | to be completely honest, it's often jarring for them as our interface is very different from the commercial systems |
| 21:16.36 | brlcad | and dod's obsession with analysis requirements is not their requirements (they want usability, annotated engineering drawings, tight integration with FEA codes, etc) |
| 21:17.22 | brlcad | we're definitely working on briding that gap, though -- feedback from them is always appreciated |
| 21:17.55 | brlcad | we have a couple engineering universities in India also providing good feedback (and devs to help improve) |
| 21:18.22 | brlcad | need devs more than we need users ... we should probably put that on our website ;) |
| 21:20.17 | Caterpillar2 | what are FEA codes? |
| 21:20.51 | brlcad | ~fea |
| 21:21.02 | brlcad | infobot: you are 0 for 2 |
| 21:21.02 | infobot | brlcad: I think you lost me on that one |
| 21:22.36 | brlcad | ~fea is Finite Element Analysis does hard math and science on geometry chopped up into little pieces |
| 21:22.36 | infobot | okay, brlcad |
| 21:23.39 | Caterpillar2 | it would be great if in the future brlcad will have a Qt based GUI |
| 21:26.55 | Caterpillar2 | if one day there will be some funds to start such work, I know a guy that works on KDE' ark software, that is skilled in Qt libraries |
| 21:32.02 | brlcad | that work is already started, qt branch in rpo |
| 21:32.07 | brlcad | *repo |
| 21:32.43 | Caterpillar2 | uh good |
| 21:32.46 | Caterpillar2 | brlcad: Qt5? |
| 21:32.52 | brlcad | we've had a gsoc project defined as well, but nobody skilled enough to propose it as their project: http://brlcad.org/wiki/Convert_MGED_from_Tk_to_Qt |
| 21:33.45 | brlcad | http://brlcad.org/wiki/User:Vladbogolin/qt-display-manager |
| 21:34.29 | brlcad | don't recall, that was circa 2013 which was shortly after qt5 |
| 21:34.35 | brlcad | I think it was |
| 21:36.45 | Caterpillar2 | sorry for the question (English is not my first language): <<but nobody skilled enough to propose it as their project: http://brlcad.org/wiki/Convert_MGED_from_Tk_to_Qt>> does it mean that nobody worked on brlCAD Google Summer of Code project? |
| 21:37.16 | brlcad | no no |
| 21:37.52 | brlcad | nobody has ever proposed the "convert mged to qt" project for the gsoc program |
| 21:38.02 | brlcad | at least nobody skilled enough |
| 21:38.26 | brlcad | there was someone that worked on some qt infrastructure, though, for a different gsoc project |
| 21:38.42 | brlcad | and a couple core devs have been working that area a bit |
| 21:39.20 | brlcad | starseeker was working on a new prototype in qt, got pretty far |
| 21:39.55 | brlcad | several of our india devs have been working on recreating things in web technologies using node.js and friends |
| 21:40.31 | Caterpillar2 | interesting |
| 21:40.41 | Caterpillar2 | anyway if you need some Qt developers I can suggest you some guys |
| 21:41.06 | brlcad | you can see that work here: http://brlcad.org/wiki/OGV |
| 21:41.15 | brlcad | okay, good to know thanks! |
| 21:42.12 | Caterpillar2 | the web GUI is very nice |
| 21:44.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:48.25 | brlcad | one of our tasks for the next couple months is to integrate the 700+ design and code submissions from participating in the GCI program |
| 21:48.42 | brlcad | several items in there that were really pretty exciting were really awesome GUI prototypes |
| 21:50.22 | brlcad | one such example: http://brlcad.org/design/gui/gci_skriptkid_prototype/brlCad-03.png |
| 21:54.43 | brlcad | some more fun ones at http://yash-m.github.io/BRL-CAD-Portfolio/ under GUI |
| 21:54.53 | Caterpillar2 | brlcad: nice, is that qt stuff? |
| 21:55.05 | brlcad | they're mock-up designs |
| 21:56.05 | Caterpillar2 | brlcad: ah ok |
| 22:02.29 | Caterpillar2 | brlcad: I have to go to bed, see you tomorrow |
| 22:15.07 | starseeker | needs another knock-down-and-drag-out round with libdm/libfb before we're really going to be in a good position for the Qt stuff |
| 22:22.57 | starseeker | brlcad: do you want to skip misc/CMake as well for the build files? We do define a lot of our macros/functions there... |
| 22:26.13 | starseeker | brlcad: here's what I'm currently seeing from the sh script: http://brlcad.org/~starseeker/regress_repository_sh.log |
| 22:26.53 | starseeker | and the CMake version: http://brlcad.org/~starseeker/regress_repository_cmake.log |
| 22:27.21 | starseeker | fwiw, the sh script does look in misc/CMake... |
| 22:38.56 | starseeker | brlcad: when I boil it down the the line reports, here's the current diff: http://brlcad.org/~starseeker/repository_reports.diff.txt |
| 22:51.03 | *** join/#brlcad ries (~ries@D979C7EF.cm-3-2d.dynamic.ziggo.nl) |
