Sean (Jan 11 2020 at 17:30): Sean (Jan 11 2020 at 17:30):@Daniel Rossberg What are the next steps for MOOSE?
Sean (Jan 11 2020 at 17:31):I still can't believe I forgot the name we'd settled on. I love it.
Daniel Rossberg (Jan 11 2020 at 17:52):Well, I don't know. The C++ interface is my standard API for doing something with BR-CAD. But, it looks like I'm the only one using it. Its features are sufficient for my current needs. Maybe, they have to be enlarged if i can really realize my ideas for a new GUI.
There is however more behind MOOSE as only "doing things in C++". It's a behavior description of the BRL-CAD kernel and a reference for how to use the standard C API. AND, with the brlcad.dll, a demonstration of how the BRL-CAD kernel can be included as a module in other applications, https://univemo.iabg.de/Download/BrlCadViewer30_setup.exe for example. I mentioned this here in the Appleseed thread too.
Sean (Jan 11 2020 at 19:17):Maybe, they have to be enlarged if i can really realize my ideas for a new GUI.
That's what I'm getting at. I think it can/should be the foundation for the new GUI (not direct linkage into librt). Towards that end, though, I do think it needs some things. I'm not 100% on what that TODO looks like yet, though.
I think my next step will be to take the IBRT interface (which directly calls librt) and see how well it converts over. Right now, it and the Qt bits we have would make a pretty decent GUI.
It's a behavior description of the BRL-CAD kernel and a reference for how to use the standard C API. AND, with the brlcad.dll, a demonstration of how the BRL-CAD kernel can be included as a module in other applications,[snip]
To me MOOSE becomes the kernel and the lower level C libraries are implementation encapsulation/layering/grouping details.
Sean (Jan 11 2020 at 19:28):Towards that end, this is still the roadmap I have in mind: Unknown.png
Begs some discussion on how libged is going to become exposed to applications, but one possibility is that appleseed and ospray move up into the application layer and the purple layerC++ sits over all the C libs including icv, gcv, ged, rt, & analyze.
Sean (Jan 14 2020 at 16:55):@Daniel Rossberg how do you feel about adding something like BRLCAD:Database.execute() ?
Sean (Jan 14 2020 at 16:58):as a means to expose the entirety of the libged API, assuming a corresponding ged_exec() that it would call into for running any ged command on the given database. this would probably entail storing a struct ged alongside the struct wdb (or instead of it since you can extract a wdb from a ged).
Sean (Jan 14 2020 at 17:34):@Himanshu Sekhar Nayak what task are you working on now?
Himanshu (Jan 14 2020 at 17:35):Himanshu Sekhar Nayak what task are you working on now?
currently working on BRL-CAD Lua binding: Test BRLCAD.database:Title() (part #1 of 2)
Sean (Jan 14 2020 at 17:36):ah cool, unit test for the Title interface? what's part 2?
Himanshu (Jan 14 2020 at 17:36):didn't see part 2 yet
Himanshu (Jan 14 2020 at 17:37):yeah Unit test for Title interface
Sean (Jan 14 2020 at 17:38):ah, I see part 2 is not uploaded/enabled yet
Himanshu (Jan 14 2020 at 17:39):btw there are still some binding left
Sean (Jan 14 2020 at 17:39):yeah, I just noticed, 5 remaining
Daniel Rossberg (Jan 14 2020 at 19:48):Daniel Rossberg how do you feel about adding something like BRLCAD:Database.execute() ?
Not so good.
libged is command language interface (namely TCL). (int argc, const char *argv[]) looks like a riddle. The return value is a string, its evaluation is the hell, unless you work with a language like TCL. And, libged is closely linked to the graphics library.
The C++ interface is a non-libged. Behavior oriented, methods with parameters, easy to work with in the language it’s written, no assumptions regarding the environment at all. It hasn’t even simple vector functions, because they are likely already present in the application where the BRL-CAD core is linked to. Instead, the Vector2D etc. structures are designed for easy casting to “usual” vector classes.
However, the M in MOOSE stands for modular. I see the core interface only as one component. There are more parts of the BRL-CAD libraries, which may be worth to export via the new API. The command language interface from libged is one of them, even a problematic one, because of its strong dependency to the current mged and Archer architecture.
In any case, libged is not a functionality of the database. It has some commands which operate on the database, but that’s all. It’s rather the central command interface of the current BRL-CAD program infrastructure.
Sean (Jan 15 2020 at 05:59):Not so good.
@Daniel Rossberg Appreciate the honesty.
libged is command language interface (namely TCL). (int argc, const char *argv[]) looks like a riddle. The return value is a string, its evaluation is the hell, unless you work with a language like TCL. And, libged is closely linked to the graphics library.
return value is currently a string, but that is not the intended end state. I'm not sure of your tcl references, though, as the library is almost entirely stripped of it's former tcl association. the command pattern it uses was intentionally designed to be abstracted from the evaluation layer above it, which could be tcl, perl, shell, lisp, lua, etc. , as simple commands followed by arguments which translates to nearly all interactive scripting environments.
The C++ interface is a non-libged. Behavior oriented, methods with parameters, ...[snip]
This I totally get and would reject myself as muddying the object-oriented behavior model. What I guess I'm hoping to find is a way to make them play together effectively (and not kludged) to benefit applications. I believe you phrased it better in the next point...
...[snip]... even a problematic one, because of it's strong dependency to the current mged and Archer architecture.
I'm not sure I'd agree with this characterization. If anything, we now have such clean separation that you can invoke any ged command without mged or archer architecture. You merely need a database handle. See src/libged/tests/test_tops.c for example.
Now where I do agree there remains a problem is that currently commands either acts on the database and returns a dumb string. These are all side effects and that's not ideal or desired long-term.
In any case, libged is not a functionality of the database. It has some commands which operate on the database, but that's all. It's rather the central command interface of the current BRL-CAD program infrastructure.
From a pure object-oriented design standpoint, I would counter that this has been framed in library terms which is not entirely relevant to the conceptual model. Conceptually, a Database certainly could/does have a notion of operations it can perform. Whether this is presented as a db->tops() or db->invoke("tops") is a not a divergent distinction. That's not to say I think only the prior or the latter should exist, just that it's not inconsistent for a database (class or object) to have some intrinsic ability to perform supported operations.
While it's undeniably the clI to the current infrastructure, I have no desire to abandon it going forward. To the contrary, I think the issues (some you have noted) are simply items to be worked as we develop new GUIs and expand new use cases as a means to leverage existing functionality while also enabling and creating new apps that rid themselves of mged/archer baggage.
Daniel Rossberg (Jan 15 2020 at 19:09):I‘m aware of the fact that the direct TCL calls were removed from libged, but it is still a command language with flags and variable parameters. This is usual for shell scripts and scripting languages which imitate their behavior. For other languages, this is a problem.
I’m also aware, that we don’t need a fully featured mged or Archer to use libged. For example, if we use mged with nu atached. Nevertheless, we shouldn’t ignore the many graphics functions in libged which are closely related to the current display manager logic.
The solution which I recommend is to access libged through an own MOOSE module. This way, MOOSE based application can use libged functionality if they can profit from them, without disturbing the other parts.
Daniel Rossberg (Apr 16 2020 at 17:42):I created a first draft of a BRL-CAD MOOSE implementation: https://github.com/drossberg/MOOSE
This shouldn't be considered in no sense as complete, but I want to share it because I don't want to put much effort in something we won't agree on.
At least, it compiles on Linux.
Daniel Rossberg (May 07 2020 at 12:24):@Himanshu Sekhar Nayak MOOSE usually denotes the BRL-CAD core C++ interface. Its code can be found in the rt^3 branch of the main repository. Look at the include/brlcad and src/coreInterface directories there.
To start, you can check the sources for consistency. E.g., does Database.cpp support all available object types?
A prototype/demonstrator of a BRL-CAD library with MOOSE API can be found here: https://github.com/drossberg/MOOSE
A demonstration of how to write programs on top of BRL-CAD MOOSE: https://github.com/drossberg/BrlCadGUI
I made both CMake set-ups for Linux. They are demonstrators only.
Himanshu (May 23 2020 at 16:20):@Daniel Rossberg yeah just starting today. First I am cleaning my workspace so that I can work again into it and I forked your repo too. I will start looking into it today onwards
Daniel Rossberg (May 23 2020 at 16:28):You may want to look at BrlCadGUI too, as this is an example for how to use MOOSE. You have to install MOOSE and give the BrlCadGUI CMake the installation directory, such that it'll find the lib and headers there. The GUI itself is Qt based.
Daniel Rossberg (May 27 2020 at 06:35):Is there a good example for a tree-walk to create a wire-frame view from a subtree? I.e., a db_walk_tree() which calls ft_plot() for the leafs. I wouls especially like to know how to include the transformations from the combinations. libged/draw.c gave me no idea.
Sean (Jun 02 2020 at 07:28):@Daniel Rossberg I wouldn't call it a "good" example, but the submodel code is probably the most concise example in librt/primitives/submodel/submodel.c in rt_submodel_plot() where it make a db_walk_tree to plot separate database models.
Daniel Rossberg (Jun 02 2020 at 11:44):Yeah, a saw this too.
It looks like the tree walking code can be rather short. This is what I made of it: https://github.com/drossberg/MOOSE/blob/master/src/Database/ConstDatabase.cpp#L459
However, creating the application to test it needs a bit more time...
Sean (Jun 02 2020 at 19:11):That looks right. Looks nice and clean too. I like the integration with VectorList, though it highlights the expansion of vlist to more than vectors...
Himanshu (Jun 12 2020 at 03:24):sorry, @Daniel Rossberg as I am unable to contribute due to some keyboard problems in my laptop as most of the keys are in bad shape and since my pc is outdated. So I bought new laptop today. I will start working on moose in a few days
Daniel Rossberg (Jun 12 2020 at 07:16):I added the Lua bindings to the lib. It can now be loaded in Lua as a module.
Himanshu (Jun 14 2020 at 00:22):btw @Daniel Rossberg I am getting Could not find BRL-CAD root directory - please set BRLCAD_BASE_DIR in CMake. Should it find the BrlCadGUI or the /usr/brlcad/dev-7.31.0/
?
Sean (Jun 15 2020 at 14:53):@Himanshu Sekhar Nayak BRLCAD_BASE_DIR should point to wherever the main libs like libbu and librt are installed, typically /usr/brlcad/dev-7.31.0 or similar.
Himanshu (Jun 17 2020 at 13:50):btw I am getting this
Himanshu (Jun 17 2020 at 13:50):CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
BRLCAD_LZ4_STATIC_LIBRARY
linked by target "brlcad" in directory /home/h1manshu/brlcad/MOOSE/src
Himanshu (Jun 17 2020 at 13:51):I have done exporting but I am not if I am giving correct PATH or something
Himanshu (Jun 17 2020 at 13:51):export PATH="/usr/brlcad/dev-7.31.0/bin:$PATH"
starseeker (Jun 17 2020 at 16:57):You may need to clear the CMakeCache.txt file
Daniel Rossberg (Jun 17 2020 at 17:02):Another possibility: This can happen if there is a lz4 development package installed. In this case, BRL-CAD won't build an own one. setting BRLCAD_LZ4_STATIC_LIBRARY to the place of the installed lib (e.g. /usr/lib/liblz4.a) should help.
The CMake logic in MOOSE isn't very intelligent yet.
Daniel Rossberg (Jun 20 2020 at 17:10):lz4 is now embedded with librt. I.e., there is no separate lz4 library any more. I adapted the MOOSE CMake file accordingly.
Himanshu (Jun 23 2020 at 04:34):yeah build passed
Himanshu (Jun 23 2020 at 04:52):Daniel Rossberg said:
Himanshu Sekhar Nayak MOOSE usually denotes the BRL-CAD core C++ interface. Its code can be found in the rt^3 branch of the main repository. Look at the include/brlcad and src/coreInterface directories there.
To start, you can check the sources for consistency. E.g., does Database.cpp support all available object types?
A prototype/demonstrator of a BRL-CAD library with MOOSE API can be found here: https://github.com/drossberg/MOOSE
A demonstration of how to write programs on top of BRL-CAD MOOSE: https://github.com/drossberg/BrlCadGUI
I made both CMake set-ups for Linux. They are demonstrators only.
btw I saw, you had included all the objects types that are supported to Database.cpp. So can I know how to look further in this regard?
Daniel Rossberg (Jun 23 2020 at 07:05):Did you had a look at the Lua interface, which is part of MOOSE? It's interesting to see how it's used.
Daniel Rossberg (Oct 10 2022 at 17:40):I did a step towards a MOOSE interface for libged, but got an odd issue on Linux: When linking the resulting libbrlcad.so (the MOOSE library) to an executable, I get three undefined references: bu_cmd, bu_terminate, and quat_mat2quat. However, how can quat_mat2quat be so different from quat_quat2mat? Any idea what could cause the undefined references? On Windows, it's fine.
Daniel Rossberg (Oct 10 2022 at 17:51):It seems to be connected with the order of the libraries in target_link_libraries(). Moving libged above libnbu but below libbn removes the undefined bu_ references. But moving libged above libbn gives link errors in MOOSE: multiple definition of 'XXH_versionNumber', etc..
starseeker (Oct 11 2022 at 02:55):I might not be including the xxhash.h header quite right - that's presumably where the XXH_* complaints are coming from.
starseeker (Oct 11 2022 at 02:57):For bu_cmd, does it help if you move bu_cmdtab inside the __BEGIN_DECLS block in bu/cmd.h?
Daniel Rossberg (Oct 11 2022 at 06:58):starseeker said:
For bu_cmd, does it help if you move bu_cmdtab inside the __BEGIN_DECLS block in bu/cmd.h?
For bu_cmd and bu_terminate it helps to move libged before libbu. I.e., I consider these as solved :)
Daniel Rossberg (Oct 11 2022 at 07:01):It's a bit surprising that the linking order is so important. I think that I had this kind of issue already before, but forgot it.
Daniel Rossberg (Oct 13 2022 at 17:23):starseeker said:
I might not be including the xxhash.h header quite right - that's presumably where the XXH_* complaints are coming from.
https://github.com/BRL-CAD/brlcad/pull/60 fixes it. At least for the moment.
Daniel Rossberg (Feb 13 2024 at 09:19):I'm seeing linker errors when trying to build the brlcad library from MOOSE:
/bin/ld: /home/rossberg/bin/brlcad/lib/libbv.a(vlist.c.o): in function `pd_3':
/home/rossberg/Devel/BRL-CAD/brlcad/src/libbv/vlist.c:310: multiple definition of `pd_3'; /home/rossberg/bin/brlcad/lib/libbg.a(polygon.c.o):/home/rossberg/Devel/BRL-CAD/brlcad/include/bv/plot3.h:310: first defined here
There are similar errors with Visual Studio on Windows.
I assume that these errors are related to https://github.com/BRL-CAD/brlcad/commit/717eaf57ef5c9bb7dfdab3196f00efc4e8ca6aab. Any idea, how this can be fixed? In MOOSE, the brlcad library is build from the static librt, libbu, etc..
Daniel Rossberg (Feb 15 2024 at 10:15)::+1: Looks like https://github.com/BRL-CAD/brlcad/commit/f5f1e19d376b2acdbc142cf16665eb1e5ab94aa5 fixed the issu. Thanks @starseeker!
Daniel Rossberg (Feb 15 2024 at 10:19):However, after fixing an issue is before discovering a new one: I'm seeing two undefined references when linking arbalest:
bu_vls_incrbg_distsq_lseg3_ptI just try to find out what's special with them. Any idea?
Daniel Rossberg (Feb 15 2024 at 10:36):looks like it is connected to the linking order in MOOSE...
Daniel Rossberg (Feb 15 2024 at 10:48):Fixed.
starseeker (Feb 17 2024 at 16:20):@Daniel Rossberg Any chance you could put together a Github Actions test that checks this for us on a regular basis? It's not a build mode I normally test so it'd be a good candidate for automated checking.
Daniel Rossberg (Feb 17 2024 at 21:43):I never looked at Github Actions before, but it sounds like a good idea. I'll give it a try. (I may need some time and support.)
starseeker (Feb 19 2024 at 03:54):@Daniel Rossberg If I get a chance I'll try to rough something in place, but I'll need you to verify it's actually building what we need to build the way we need to build it to act as a good test.
Daniel Rossberg (Feb 19 2024 at 09:46):Okay, let's see, if I understood it right (Linux only, for the start):
.github/workflows/check.yml-DCMAKE_INSTALL_PREFIX=$ENV{GITHUB_WORKSPACE}/install to the cmake commandcmake --build build --config Release --target install to the Build - name: Checkout MOOSE
uses: actions/checkout@v4
with:
repository: brlcad/MOOSE
(I'm not sure about the @4 here.)
-DBRLCAD_BASE_DIR=$ENV{GITHUB_WORKSPACE}/install starseeker (Feb 19 2024 at 18:47):I'd suggest adding a separate moose.yml file for this specific case, but it can work either way.
starseeker (Feb 19 2024 at 18:47):Sounds like you've got the right idea.
Daniel Rossberg (Feb 21 2024 at 09:53):starseeker said:
I'd suggest adding a separate moose.yml file for this specific case, but it can work either way.
Yes, for developing and testing the action, and it could be hooked to MOOSE commits. But, for hooking it to brlcad commits, it has the disadvantage of building brlcad twice in this case.
However, first it needs to work. I'll take a look at it.
Daniel Rossberg (Feb 21 2024 at 15:40):There is an issue with the static brlcad libraries on Windows with Visual Studio: The rt_tgc_tess() and rt_tgc_tnurb() functions are missing. I think, this is because of a Visual Studio individuality, where the linker thinks that these functions are unused. I created a pull request with a proposed solution: https://github.com/BRL-CAD/brlcad/pull/115
starseeker (Feb 23 2024 at 21:41):@Daniel Rossberg Interesting that those two functions have a problem, but rt_tgc_mirror does not. I think it's probably my fault for missing something when I moved them...
starseeker (Feb 23 2024 at 21:44):OK, I guess we can merge them back in for now... I'd like to understand why that didn't work, but in the meantime we can get up and running again.
Daniel Rossberg (Feb 23 2024 at 22:15):starseeker said:
Daniel Rossberg Interesting that those two functions have a problem, but rt_tgc_mirror does not. I think it's probably my fault for missing something when I moved them...
rt_tgc_mirror() is used in src/librt/primitives/mirror.c
Daniel Rossberg (Feb 23 2024 at 22:15):starseeker said:
OK, I guess we can merge them back in for now... I'd like to understand why that didn't work, but in the meantime we can get up and running again.
Maybe there is even a difference between MSVS 2019 and 2022...
Daniel Rossberg (Jan 02 2025 at 12:17):When running my examples with the ged version of MOOSE, I'm seeing
free(): double free detected in tcache 2
Aborted (core dumped)
The gdb back-trace is
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
at ./nptl/pthread_kill.c:44
#1 0x00007ffff46a9f1f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007ffff465afb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff4645472 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00007ffff469e430 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff47b8459 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#5 0x00007ffff46b383a in malloc_printerr (str=str@entry=0x7ffff47bb098 "free(): double free detected in tcache 2")
at ./malloc/malloc.c:5660
#6 0x00007ffff46b5ac6 in _int_free (av=0x7ffff47f1c60 <main_arena>, p=0x555555649560, have_lock=have_lock@entry=0)
at ./malloc/malloc.c:4469
#7 0x00007ffff46b7f1f in __GI___libc_free (mem=<optimized out>) at ./malloc/malloc.c:3385
#8 0x00007ffff532bb19 in onrealloc () from /home/rossberg/bin/BrlcadMoose/lib/libbrlcad.so
#9 0x00007ffff4f7df92 in ON_HatchPattern::~ON_HatchPattern() ()
from /home/rossberg/bin/BrlcadMoose/lib/libbrlcad.so
#10 0x00007ffff465cff7 in __cxa_finalize (d=0x7ffff12b4600) at ./stdlib/cxa_finalize.c:83
#11 0x00007ffff0c78d27 in __do_global_dtors_aux () from /home/rossberg/bin/brlcad/lib/libOpenNURBS.so
#12 0x0000555555580830 in ?? ()
#13 0x00007ffff7fcc12a in _dl_call_fini (closure_map=0x7fffffffd7f0, closure_map@entry=0x555555580830)
at ./elf/dl-call_fini.c:43
#14 0x00007ffff7fcf81e in _dl_fini () at ./elf/dl-fini.c:114
#15 0x00007ffff465d55d in __run_exit_handlers (status=1, listp=0x7ffff47f1820 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:116
#16 0x00007ffff465d69a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:146
#17 0x00007ffff4646251 in __libc_start_call_main (main=main@entry=0x5555555551b9 <main>, argc=argc@entry=1,
argv=argv@entry=0x7fffffffe318) at ../sysdeps/nptl/libc_start_call_main.h:74
#18 0x00007ffff4646305 in __libc_start_main_impl (main=0x5555555551b9 <main>, argc=1, argv=0x7fffffffe318,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe308)
at ../csu/libc-start.c:360
#19 0x00005555555550f1 in _start ()
This happens even without calling any BRL-CAD function. Just linking to MOOSE triggers it, and it has to be the ged version. It looks like one of the static ON_HatchPattern objects is double-freed :thinking:
starseeker (Jan 03 2025 at 00:59):ON_HatchPattern is coming from OpenNURBS
starseeker (Jan 03 2025 at 01:01):I'm almost afraid to ask, but what if you back up before commit 3a68e61
starseeker (Jan 03 2025 at 01:02):You'll need to replace rt_vlfree with RTG.rtg_vlfree in the MOOSE code
starseeker (Jan 03 2025 at 01:03):(3a68e61 is in BRL-CAD proper: https://github.com/BRL-CAD/brlcad/commit/3a68e6180abd6ac5190500ed67bf305671cca71f)
Daniel Rossberg (Jan 03 2025 at 16:14):I'll try it, no problem, thanks for your help :smile:
My last guess was an issue with libged_init(), because the error arises whenever I have a ged_ function in the MOOSE code, the function doesn't need to be called (it makes no difference). However, I'll do some more tests, including replacing rt_vlfree with RTG.rtg_vlfree, as you recommended.
starseeker (Jan 03 2025 at 18:34):It could be - I don't know when the last integration tests were made, so it could very well be something with that.
starseeker (Jan 03 2025 at 18:36):I'm a little nervous about that backtrace - I'm hoping we're not looking at another issue like https://github.com/BRL-CAD/brlcad/commit/9af0c3356c2bac728990a5c1f6d3e4bbd6116ee3
starseeker (Jan 03 2025 at 18:38):We need those initialization routines, so if OpenNURBS is cranky about them I'm not quite sure what the path forward would be.
Last updated: Jan 09 2025 at 00:46 UTC