Advith Shetty (Dec 23 2017 at 08:35): Advith Shetty (Dec 23 2017 at 08:35):when i open mged of brl-cad, it asks me to open a database, how to open it ? pls any mentor of brl -cad tasks tell me about this
Siddharth (Dec 23 2017 at 08:45):Hey @Advith Shetty I'm not a mentor but I think I could help you out, go to file and then open, then choose the database, it will be a .g file.
Jeff Sieu (Dec 23 2017 at 09:06):Actually, I believe it can be any file extension though, if you save it without a file extension. But yeah, generally it will be in a .g file format.
Naseef (Dec 23 2017 at 12:42):Well, I think you actually have to create a database first.
Daniel Rossberg (Dec 23 2017 at 15:54):Or you use one from <BRL-CAD installation>/share/db/.
Nwankwo Ifeanyichukwu (Dec 31 2017 at 21:05):What are we really required to do in this task its too confusing
Jeff Sieu (Jan 01 2018 at 03:20):@Nwankwo Ifeanyichukwu Which task are you on?
Divyanshu Mehrotra (Jan 02 2018 at 11:16):I am Divyanshu participating in GCI.The brl cad task of creating chess models are very interesting
Sean (Jan 02 2018 at 14:46):@Divyanshu Mehrotra glad to hear it! I hope you'll consider some of the other modeling tasks too as they can be challenging but really fun too
Neha Krishna Dasari (May 16 2019 at 13:50):Hello. This is Neha Krishna and I am participating in GSoD. BRL CAD seems really interesting and as I am getting familiar with it, I hope I can contribute something significant to its documentation. It is great to be able to connect this way. :)
Daniel Rossberg (May 16 2019 at 15:12):@Neha Krishna Dasari thank you for considering BRL-CAD as your GSoD project. Could you please tell something more about yourself, especially your skills in documentation? Can you provide us with examples of documentations you have written?
Neha Krishna Dasari (May 27 2019 at 10:22):Hello @Daniel Rossberg . Sorry I haven't given a prompt reply. I have been occupied due to personal reasons. I am a student pursuing a degree in Computer Science from IIIT Bangalore, India. To be honest I don't really have much experience with respect to documentation but I do write reports and have a knack for technical writing. I am planning on learning some principles as far as technical documentation is concerned.
Daniel Rossberg (May 27 2019 at 18:07):@Neha Krishna Dasari Without much experience in technical writing your chance to get chosen for GSoD is rather low. However, engaging in open source projects as BRL-CAD can help you to gain experience in many IT areas as system programming, web design, documentation, social media, etc.. This experience can be helpful when you search a job as well.
If you like, we could together look for some tasks you can do for BRL-CAD, maybe in accord with your course contents.
Daniel Rossberg (Feb 23 2021 at 18:38):Is there an easy way known to clear an inmem database, i.e.removing everything from it?
Daniel Rossberg (Feb 23 2021 at 18:41):via the C API
starseeker (Feb 23 2021 at 19:13):Um. Not off the top of my head. Any reason not to just delete it and create a new one?
Sean (Feb 23 2021 at 20:01):@Daniel Rossberg db_close()
Sean (Feb 23 2021 at 20:03):that of course also decrements the usage count, releases all entries, purges memory, syncs to disk, and closes the instance...
Sean (Feb 23 2021 at 20:05):the block in there that releases the all the directory entries could be extracted into a db_clear() or similar, make db_close() call it, and make it available to others where you don't necessarily want to release everything
Daniel Rossberg (Feb 24 2021 at 18:31):Yep, db_close() kills the database. And, because a db_clear() requires a bit more than just copy-n-paste from db_close(), I decided to delete and recreate the database, like it's done in the file case.
starseeker (Feb 24 2021 at 19:17):@Daniel Rossberg You can start working with the rt3 repository on Github now, actually - that migration was completed successfully.
Daniel Rossberg (Feb 25 2021 at 17:33):Ups, indeed. Now, that you mention it, there was something.
Did I already mention that I don't like git? (Or is it Github?)
Erik (Feb 25 2021 at 17:34):sure ain't darcs :D
Sean (Feb 25 2021 at 18:39):Daniel Rossberg said:
Ups, indeed. Now, that you mention it, there was something.
Did I already mention that I don't like git? (Or is it Github?)
We're long overdue getting off of SourceForge... they've not been good hosts to/for us for years now. That said, svnhub.com is a thing... ;)
Sean (Feb 25 2021 at 18:41):They even differentiate the client so it's the same https URL for checkout, if I read it right. They handle the rest transparently, which is pretty cool.
Erik (Feb 27 2021 at 00:51):public svn repo, mailing list, file server (https)... what else did we actually use from sf.net? they had a compile farm long ago, but it was a bit of a pita iirc
Sean (Feb 27 2021 at 05:16):repos (svn), mailling lists (mailman), mailing list archiving, large file hosting, trackers (bugs, patches, support requests, feature requests, geometry), discussion forums, user auth, and news/blog/announcements.
Daniel Rossberg (Mar 22 2021 at 18:47):Hmm, mged is broken:
mged: error while loading shared libraries: libitk3.4.so: cannot open shared object file: No such file or directory
(Debian buster)
It looks like the new separated build sets a wrong install (r)path, i.e. it is installed at the usual place, but the executables can't find it there(?)
starseeker (Mar 22 2021 at 20:20):@Daniel Rossberg Hmm, interesting. That's in the final install location, not in the build directory?
starseeker (Mar 22 2021 at 20:26):What do the following report?
readelf -d bin/mged | grep RUNPATH
readelf -d lib/itk3.4/libitk3.4.so | grep RUNPATH
starseeker (Mar 22 2021 at 20:26):(deleted)
starseeker (Mar 22 2021 at 20:27):Oh, I see - you're right, itk's not getting the correct word for it's final install.
starseeker (Mar 22 2021 at 20:27):Curious...
starseeker (Mar 22 2021 at 20:36):Well, I tested branch merging, now this is a good excuse to test commit reverting in git...
starseeker (Mar 22 2021 at 20:39):@Daniel Rossberg I think I have it backed out of main - let me know if you still see any issues. I'll have to dig a bit to figure out where my missing wire is on the rpath assignments.
starseeker (Mar 23 2021 at 01:53):@Daniel Rossberg Could you do me a favor and try buliding the extbuild branch? I think I've addressed the issues you hit, but it needs much more extensive testing. I'm fairly sure I got caught by an "accidental" success with Itcl/Itk earlier, so more stress testing would be welcome. (Plus, my brain isn't at full capacity today...)
Daniel Rossberg (Mar 23 2021 at 07:42):CMake fails:
CMake Error at misc/tools/Third_Party_Exec.cmake:157 (include):
include could not find load file:
/usr/share/cmake-3.13/Modules/FindCHRPATH.cmake
Call Stack (most recent call first):
misc/tools/CMakeLists.txt:118 (THIRD_PARTY_EXECUTABLE)
BRLCAD_CHRPATH is set to BUNDLED (AUTO).
Daniel Rossberg (Mar 23 2021 at 08:23):As far as I know, if the build of, for example, itk is separated from BRL-CAD's main build, you need to import itk in BRL-CAD, which should be something like
add_library(itk SHARED IMPORTED GLOBAL)
set(ITK_LIB_FILE "${CMAKE_CURRENT_BINARY_DIR}/ITK-BUILD/libitk.so")
set_property(TARGET itk PROPERTY IMPORTED LOCATION ${ITK_LIB_FILE})
install(FILES ${ITK_LIB_FILE} DESTINATION lib)
or?
BTW, the installation path of the itk library was indeed unusual: It was in lib/itk3.4, but the old path was in lib (without the subdirectory).
starseeker (Mar 23 2021 at 11:28):Ah, right - the cached value in my build masked the missing FindCHRPATH.cmake file...
starseeker (Mar 23 2021 at 11:34):Yes, the Tcl/Tk package libs are in subdirs in lib - in the original CMakeified build, I flattened everything into the lib directory, but this time around I wanted to try and do things the "normal" way for the Itcl/Itk packages.
starseeker (Mar 23 2021 at 13:12):@Daniel Rossberg I'm trying to do something which (to the best of my knowledge) is unique in the CMake world - I'm incorporating 3rd party build outputs into BRL-CAD's main build in such a way that they can be managed as if they were all produced as direct build outputs of the primary CMake build.
Daniel Rossberg (Mar 23 2021 at 13:18):This is what I thought. I did once something similar. There, I "imported" the result of the external build. (BTW, the external build was a BRL-CAD library.)
Daniel Rossberg (Mar 23 2021 at 13:20):I.e., "itk" gets all the attributes of a BRL-CAD product, but doesn't contain an own build, instead it references to the products of an external build.
starseeker (Mar 23 2021 at 13:46):@Daniel Rossberg I've made some adjustments to extbuild. If you build now, this is what you should get (assuming it's working for you the way it is for me):
$ readelf -d /usr/brlcad/dev-7.32.3/lib/libpng_brl.so|grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/usr/brlcad/dev-7.32.3/lib:$ORIGIN/../lib]
$ readelf -d /usr/brlcad/dev-7.32.3/lib/itcl3.4/libitcl3.4.so|grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/usr/brlcad/dev-7.32.3/lib/itcl3.4:$ORIGIN/../../lib/itcl3.4]
$ readelf -d /usr/brlcad/dev-7.32.3/lib/itk3.4/libitk3.4.so|grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/usr/brlcad/dev-7.32.3/lib/itk3.4:$ORIGIN/../../lib/itk3.4]
/me nods. Yes, the imported targets are key. What I'm doing is taking them beyond their normal usage, which (as I understand it) is to be able to reference installed libraries from the OS as if they were CMake build targets. I'm doing that, but rather than just referencing them I'm also defining custom rules for those imported targets that install them the "normal" CMake way. So a "make install", "make package", etc. will incorporate not only the BRL-CAD build outputs but also the files from the imported targets. That part's not too tricky, but setting the RPATH correctly per the main build's CMake settings is.
starseeker (Mar 23 2021 at 13:56):The other gotcha is that CMake's main build doesn't know anything about the guts of the ExternalProject_Add builds, so it doesn't know when it needs to hold off building the object files for BRL-CAD sources until the external projects are complete. Normally this has to be addressed with the Superbuild pattern, but when I tried that it was a really bad fit with all our other CMake logic. In the end I defined a second layer of custom target above the ExternalProject_Add targets, which explicitly list the build outputs we care about and allow the main CMake build to correctly set file level dependencies.
starseeker (Mar 23 2021 at 13:57):The core magic is in https://github.com/BRL-CAD/brlcad/blob/extbuild/src/other/ext/CMake/ExternalProject_Target.cmake
Daniel Rossberg (Mar 23 2021 at 15:42):Something is still wrong. I started everything from scratch, the CMake configuration worked now, but readelf gives me still the wrong path:
readelf -d /home/rossberg/bin/brlcad/lib/itk3.4/libitk3.4.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/home/rossberg/lib/brlcad/lib/itk3.4:$ORIGIN/../../lib/itk3.4]
CMAKE_INSTALL_PATH is /home/rossberg/bin/brlcad.
starseeker (Mar 23 2021 at 15:59):Did you set CMAKE_INSTALL_PREFIX to /home/rossberg ? If so, that's correct.
Daniel Rossberg (Mar 23 2021 at 16:02):No: /home/rossberg/bin/brlcad
starseeker (Mar 23 2021 at 16:08):Er, sorry - that's what I meant to type. Then yes, that looks correct.
starseeker (Mar 23 2021 at 16:08):Is it not working?
starseeker (Mar 23 2021 at 16:09):Oh, wait - you mean bin/brlcad is in the CMAKE_INSTALL_PREFIX var itself?
starseeker (Mar 23 2021 at 16:09):I.e. cmake -DCMAKE_INSTALL_PREFIX=/home/rossberg/bin/brlcad ?
starseeker (Mar 23 2021 at 16:09):OK, I know what's substituting lib for bin. Give me a minute while I think about how best to handle it...
starseeker (Mar 23 2021 at 16:10):(Sorry, I've never encountered "/bin/" in an install path before, so I misparsed it...
starseeker (Mar 23 2021 at 16:21):@Daniel Rossberg OK, I got it working for a similar path:
$ readelf -d /usr/brlcad/bin/brlcad/lib/libpng_brl.so|grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/usr/brlcad/bin/brlcad/lib:$ORIGIN/../lib]
Yeah, /home/rossberg/bin is my standard personal binary path. There I install the programs in subdirectories (e.g. BRL-CAD in brlcad). This way, I don't need to become root when installing stuff.
starseeker (Mar 23 2021 at 17:26):/me nods. I think I've got it handled now. 4a03f3b50309 uses a regex to tighten the replacement to the end of the path, so it should leave the root intact.
Daniel Rossberg (Mar 23 2021 at 18:15):The readelf output looks good now(?):
readelf -d /home/rossberg/bin/brlcad/lib/itk3.4/libitk3.4.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/home/rossberg/bin/brlcad/lib/itk3.4:$ORIGIN/../../lib/itk3.4]
but, I'm still getting
mged: error while loading shared libraries: libitk3.4.so: cannot open shared object file: No such file or directory
It is not in the search path:
10015: find library=libitk3.4.so [0]; searching
10015: search path=/home/rossberg/bin/brlcad/lib:/home/rossberg/bin/brlcad/bin/../lib/tls/haswell/x86_64:/home/rossberg/bin/brlcad/bin/../lib/tls/haswell:/home/rossberg/bin/brlcad/bin/../lib/tls/x86_64:/home/rossberg/bin/brlcad/bin/../lib/tls:/home/rossberg/bin/brlcad/bin/../lib/haswell/x86_64:/home/rossberg/bin/brlcad/bin/../lib/haswell:/home/rossberg/bin/brlcad/bin/../lib/x86_64:/home/rossberg/bin/brlcad/bin/../lib (RUNPATH from file mged)
10015: trying file=/home/rossberg/bin/brlcad/lib/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/tls/haswell/x86_64/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/tls/haswell/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/tls/x86_64/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/tls/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/haswell/x86_64/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/haswell/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/x86_64/libitk3.4.so
10015: trying file=/home/rossberg/bin/brlcad/bin/../lib/libitk3.4.so
10015: search cache=/etc/ld.so.cache
10015: search path=/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib (system search path)
10015: trying file=/lib/x86_64-linux-gnu/tls/haswell/x86_64/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/tls/haswell/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/tls/x86_64/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/tls/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/haswell/x86_64/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/haswell/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/x86_64/libitk3.4.so
10015: trying file=/lib/x86_64-linux-gnu/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/tls/haswell/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/tls/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/haswell/x86_64/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/haswell/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/x86_64/libitk3.4.so
10015: trying file=/usr/lib/x86_64-linux-gnu/libitk3.4.so
10015: trying file=/lib/tls/haswell/x86_64/libitk3.4.so
10015: trying file=/lib/tls/haswell/libitk3.4.so
10015: trying file=/lib/tls/x86_64/libitk3.4.so
10015: trying file=/lib/tls/libitk3.4.so
10015: trying file=/lib/haswell/x86_64/libitk3.4.so
10015: trying file=/lib/haswell/libitk3.4.so
10015: trying file=/lib/x86_64/libitk3.4.so
10015: trying file=/lib/libitk3.4.so
10015: trying file=/usr/lib/tls/haswell/x86_64/libitk3.4.so
10015: trying file=/usr/lib/tls/haswell/libitk3.4.so
10015: trying file=/usr/lib/tls/x86_64/libitk3.4.so
10015: trying file=/usr/lib/tls/libitk3.4.so
10015: trying file=/usr/lib/haswell/x86_64/libitk3.4.so
10015: trying file=/usr/lib/haswell/libitk3.4.so
10015: trying file=/usr/lib/x86_64/libitk3.4.so
10015: trying file=/usr/lib/libitk3.4.so
10015:
mged: error while loading shared libraries: libitk3.4.so: cannot open shared object file: No such file or directory
@Daniel Rossberg If you add /home/rossberg/bin/brlcad/lib/itk3.4/ to LD_LIBRARY_PATH does it then work?
Daniel Rossberg (Mar 23 2021 at 18:38):Yes, with LD_LIBRARY_PATH=/home/rossberg/bin/brlcad/lib/itk3.4 mged mged starts.
starseeker (Mar 23 2021 at 18:39):Huh. When I do ldd I get:
$ ldd /usr/brlcad/dev-7.32.3/bin/mged
linux-vdso.so.1 (0x00007fff21955000)
libtclcad.so.20 => /usr/brlcad/dev-7.32.3/lib/libtclcad.so.20 (0x00007f733b84f000)
libged.so.20 => /usr/brlcad/dev-7.32.3/lib/libged.so.20 (0x00007f733b7da000)
libwdb.so.20 => /usr/brlcad/dev-7.32.3/lib/libwdb.so.20 (0x00007f733b7c8000)
libdm.so.20 => /usr/brlcad/dev-7.32.3/lib/libdm.so.20 (0x00007f733b776000)
libtermio.so.20 => /usr/brlcad/dev-7.32.3/lib/libtermio.so.20 (0x00007f733b770000)
librt.so.20 => /usr/brlcad/dev-7.32.3/lib/librt.so.20 (0x00007f733b0cd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f733aeac000)
libpkg.so.20 => /usr/brlcad/dev-7.32.3/lib/libpkg.so.20 (0x00007f733aea1000)
libnmg.so => /usr/brlcad/dev-7.32.3/lib/libnmg.so (0x00007f733ad2e000)
libbn.so.20 => /usr/brlcad/dev-7.32.3/lib/libbn.so.20 (0x00007f733ac0b000)
libtcl8.6.so => /lib/x86_64-linux-gnu/libtcl8.6.so (0x00007f733aa4f000)
libtk8.6.so => /lib/x86_64-linux-gnu/libtk8.6.so (0x00007f733a8df000)
libbu.so.20 => /usr/brlcad/dev-7.32.3/lib/libbu.so.20 (0x00007f73380f7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7337fa8000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f7337f20000)
libicv.so.20 => /usr/brlcad/dev-7.32.3/lib/libicv.so.20 (0x00007f7337f0d000)
libbg.so.20 => /usr/brlcad/dev-7.32.3/lib/libbg.so.20 (0x00007f7337d49000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f7337d11000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7337b2e000)
libanalyze.so.20 => /usr/brlcad/dev-7.32.3/lib/libanalyze.so.20 (0x00007f73379c3000)
libopenNURBS.so.2012.10.245 => /usr/brlcad/dev-7.32.3/lib/libopenNURBS.so.2012.10.245 (0x00007f73374ee000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f73374d3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f73374b0000)
libbrep.so.20 => /usr/brlcad/dev-7.32.3/lib/libbrep.so.20 (0x00007f73371bf000)
/lib64/ld-linux-x86-64.so.2 (0x00007f733ba37000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f73371b9000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f733719d000)
libXft.so.2 => /lib/x86_64-linux-gnu/libXft.so.2 (0x00007f7337184000)
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f733713d000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f7336ffe000)
libXss.so.1 => /lib/x86_64-linux-gnu/libXss.so.1 (0x00007f7336ff9000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f7336ff0000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f7336f38000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f7336f04000)
libnetpbm.so => /usr/brlcad/dev-7.32.3/lib/libnetpbm.so (0x00007f7336ec8000)
libpoly2tri.so => /usr/brlcad/dev-7.32.3/lib/libpoly2tri.so (0x00007f7336e96000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f7336dd7000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f7336bcd000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f7336b9f000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f7336b73000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f7336b5e000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f7336b58000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f7336b50000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f7336b36000)
No entry for libitk3.4.so?
starseeker (Mar 23 2021 at 18:43):No, nor for itcl
starseeker (Mar 23 2021 at 20:17):@Daniel Rossberg I'm very curious that you're getting library linkage between Itcl/Itk and MGED... that should have been changed.
starseeker (Mar 23 2021 at 20:17):The Itcl/Itk users should be doing "package require" now to load them...
starseeker (Mar 23 2021 at 20:18):I'll see if I can set up a Debian buster VM...
starseeker (Mar 23 2021 at 23:54):@Daniel Rossberg I found where ITK_LIBRARY was still being listed as an MGED linkage. My current guess is Ubuntu's gcc 9.3 figured out not to list it as a link dependency, and the older gcc 8 in Debian may not have (or maybe some other component of the respective tool chains.) The VM install of Debian is taking a while - I went ahead and committed a removal of the ITK linkage, so that may address the problem you were seeing.
Daniel Rossberg (Mar 24 2021 at 08:15):The build with the current extbuild branch created a mged, which I could start, do a rt, etc.. Promising :)
starseeker (Mar 24 2021 at 13:08):Excellent! I'll try the current extbuild on OpenBSD - if that works I'll go ahead and re-merge.
starseeker (Mar 24 2021 at 17:49):There we go. Got success on OpenBSD.
Erik (Mar 24 2021 at 23:28):well, shoot, you one-upped my fbsd for esoteric, I'm gonna have to dredge up something weird to compete...
starseeker (Mar 25 2021 at 00:13):Heh. If you try Haiku you get to fix it.
Erik (Mar 25 2021 at 13:17):is haiku still around? :D maybe mezzano... or movitz if it's still around... :D
starseeker (Mar 25 2021 at 13:25):/me checks mezzano's website...
starseeker (Mar 25 2021 at 13:26):<snort> Trust you to think of that one. Now all you need is a C++ to lisp compiler....
starseeker (Mar 25 2021 at 13:27):We're close(ish) to building on Haiku, but last time I tried there were some rather thorny issues I didn't have time to try and sort out
Erik (Mar 25 2021 at 13:30):my life is way hpc these days, with linux and windows being the two I care about :/ (although this place has used fbsd before and digs it.. buncha academic doctorate types, all our docs are written in 'latex')
Sean (Mar 25 2021 at 21:09):Erik said:
is haiku still around? :D maybe mezzano... or movitz if it's still around... :D
Yep, they're still around and doing pretty well.
Daniel Rossberg (Aug 27 2021 at 14:32):Is there a simple explanation why eccentered_cube.g has negative moments of inertia? (computed with gqa -g 1 eccentered_cube.g all.g)
Sean (Sep 01 2021 at 02:43):Hm, no idea comes immediately to mind as being reasonable. It crashed on a quick test I did, so there may be a bug. Recompiling a debug build to check -- that crash was on a very old binary, not a controlled testing setup.
Sean (Sep 29 2021 at 18:25):@starseeker the libnmg commit is rather concerning given we have bupkis testing there... biggest red flags in extrude.c, inter.c, mod.c, pt_fu.c, and tri.c.. I see how most of those instances are unused, but at least a couple seemed to be likely bugs and with the lines of code gone, that's no longer apparent. I get it made clang happy, but it looks even harder to debug.
Sean (Sep 29 2021 at 18:29):I know you already try to avoid debugging nmg ... so this feels a little self-fulfilling prophecy, by making it even harder. heh.
Sean (Sep 29 2021 at 18:32):I mean, take a look at extrude.c .. the section commented out is identical to the block above it. Conceptually I think I get that it's looking at splitting an edge between two points, and the second block is just looking at the points in reverse order. So I'm not sure why clang would complain about the second but not the first... and the intent seems to be to pick/set the first point, and that's apparently not happening right.
starseeker (Sep 29 2021 at 23:35):@Sean If you want to restore the ones you think indicate possible bugs I'm fine with that.
Sean (Sep 30 2021 at 06:32):A couple probably, but that will certainly break the clang linting now that it's strict (or are you suggesting that get relaxed back too?) at least until a unit test or other test case is set up that pokes that code specifically.
Sean (Sep 30 2021 at 06:32):Would be super interesting to see a code coverage map on libnmg after a conversion is run...
starseeker (Sep 30 2021 at 12:31):Yes, we'll flip the libnmg back to being a failing test until the problems are addressed satisfactorily. A lib is "cleantest" if it's expected to pass, but libnmg won't be once we revert.
Thusal Ranawaka (Oct 30 2021 at 02:11):Hey @Sean Is this normal? image.png
Thusal Ranawaka (Oct 30 2021 at 02:11):I just tried to install MGED from the setup in Sourceforge, but shows this.
Thusal Ranawaka (Oct 30 2021 at 02:16):Now it worked when I tried from the .msi setup.
Sean (Oct 30 2021 at 17:51):I’m guessing security settings prevented you from running an app downloaded
Sean (Oct 30 2021 at 17:52):We need to figure out how to sign our binaries for Mac and Windows
Thusal Ranawaka (Oct 31 2021 at 00:32):Yes
Roshan Swain (Nov 23 2021 at 12:13):Hi, my name is Roshan Swain. I am interested in contributing to BRL-CAD and learn more about high performance computing and graphics. Can someone help me to get started with BRL-CAD? Also, it will be very helpful if you could point to some good first issues to get started with BRL-CAD.
Himanshu (Nov 23 2021 at 16:18):Roshan Swain said:
Hi, my name is Roshan Swain. I am interested in contributing to BRL-CAD and learn more about high performance computing and graphics. Can someone help me to get started with BRL-CAD? Also, it will be very helpful if you could point to some good first issues to get started with BRL-CAD.
Hello @Roshan Swain Head towards https://github.com/BRL-CAD/brlcad and build it. You can hover around MGED https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf.
Last updated: Jan 09 2025 at 00:46 UTC