Hey @Sean , I'm assuming this (https://pastebin.com/RKkKSzFV) is the exhaustive list of primitives that need to be wrapped. I've got a little confusion about some of the names here, (e.g., Does hlf mean half?).
I've written a 'd' beside the primitives that been wrapped and added a bracket () around the one's that I have a doubt.
I'm writing the core of the proposal (the timeline) and wanted to just narrow down on the list of things I'd need to do.
The one's without a 'd' by them have not been wrapped. This is an extract from the 'table.cpp' file in the primitives folder.
Also, regarding the patch. Would you recommend a dummy wrapper around one of the primitives or solving some other task from the to-do list?
@Shubham Rathore Any insights here? :)
if you look in src/librt/primitives/* you will find sources to all of them, and descriptions for what the shorthand names (like hlf) means in the top comment of the main file
note also that a few primitives are deprecated/obsolete (see CHANGES)
Great!
Oh alright
e.g., don't care about pg, nurb, hf, and cline
Alright! Just out of curiosity, what is the librt/primitives/xxx directory?
template for creating a new primitive
Ah, sweet
for a patch, I would suggest doing something productively useful that demonstrates your abilities
@Sean , I'm trying to setup python BRL-CAD on my system (OS-X) but I keep running into this issue constantly : https://pastebin.com/PqKQ2Sfm
Would you have any solution to this?
Uh-huh. I'll figure out a patch task and get back to you soon
I don't have a solution for that -- haven't worked with that code in years so it'd take some time to refamiliarize
Ah okay! I'll figure something out
but at a glance, looks like something is wrong in the search logic it's using
Uh, it requires me to : export BRLCAD_PATH=/usr/brlcad
And when it tries to look for BRL-CAD there, it doesn't find a valid installation
also, just changed the subject @Jaipal Singh .. try not to hijack other people's discussions ;)
Oh crap! Sorry :P
no biggie
So, the BRL_CAD path should redirect to the source code?
*BRLCAD_PATH
like I said, something is wrong in the search logic (or testing) that it's using ... or your setting is wrong
don't know, would have to read the source code just like you can ;)
On it!
One last thing, would you know how I could get in touch with https://github.com/ncsaba ?
AFAIK, he started the initial work on python BRLCAD
you could try asking on the brlcad-devel mailing list
or e-mailing him
raj reddy also worked on it (under gsoc)
Yea!
bryan definitely had a hand too
I think he did most of it actually iirc, at least most of the initial setup
could be mis-remembering though .. that was about 5 years ago
Haha! Nah, the commit history says the same, Bryan was a major contributor along with ncsaba.
if you can get ahold of one of them, ask them if they're willing to mentor you on the project too ...
Including that in the email rn
@Sean Bryan responded to the mail, I'm going to bounce off all my doubts regarding the project and the GSoC proposal and submit a draft in the next couple of hours.
Regarding the mentorship, he said he wasn't sure about it, but I'll try and see if he can do like a co-mentor thing of sorts.
@Sean Regarding the tasks to be done during SoC, I was thinking something on the lines of (chronologically)
Fixing the current project : Proper installation scripts, support for python3.x (Probably during community bonding)
Wrapping the primitives : Wrapping the remaining primitives and writing tests for the same.
Extending support to OS-X : This could be post SoC task as well, I'm still not sure about this.
Documentation : I think this is really crucial and this would span across the entire length of the project.
What do you think?
Also, I'm not sure how much time each primitive is going to take, so would it make sense to build the timeline in the proposal at a coarse-grained (maybe weekly or fortnightly) level?
@Jaipal Singh Hey, I too was wishing to work on the same project and considering that the project is very large, how about we divide the work, that is you handle extending the support for OS-X and fixing the current project, while I would start wrapping rest of the primitives. And along with that the documentation can go on simultaneously. And by the end of the project, say last 2 weeks we can write tests for the same. @Sean What do you think, would something like this be feasible?
Hi @Jaipal Singh , one can only be sure about the time after you are done with everything. A rough tentative is good enough, and its better to divide the tasks into small time periods so that the progress can be monitored rather than keeping the windows too large and ending up with nothing :)
Hey @Aditya Gulati. I would love to collaborate but I think I'll be able to do justice to the project and complete most of it (probably all of it) in the given time frame. :)
You could always be an active contributor to the python BRL-CAD though, it's great to have people working on a project they're interested in.
@Jaipal Singh Thanks. Would look some other project this year.
@Jaipal Singh sounds like a reasonable approach, good work
proposals should at least try to account for each week of gsoc
@Aditya Gulati it's possible, so long as the tasks don't depend on each other
Hey @Sean , what does $BRLCAD_PREFIX play a role in?
@Jaipal Singh in what context?
I think it's a CMAKE variable.
Found this on CMake file, I think it will be helpful for you @Jaipal Singh
# (Note: CMAKE_INSTALL_PREFIX must be checked in the case where someone # sets it on the command line prior to CMake being run. BRLCAD_PREFIX # preserves the CMAKE_INSTALL_PREFIX setting from the previous CMake run. # CMAKE_INSTALL_PREFIX does not seem to be immediately set in this context # when CMake is re-run unless specified explicitly on the command line. # To ensure the previous (and internally set) CMAKE_INSTALL_PREFIX value # is available, BRLCAD_PREFIX is used to store the value in the cache.)
@Jaipal Singh you found the docs that explain it right there... I'm not sure what you're wanting to know beyond that (or more importantly why you would even care). It's not a variable you should need to know about or use.
Thanks @Naseef !
@Sean , I am working on a patch to fix python BRL-CAD and getting it to smoothly install on OS-X and the code there uses $BRLCAD_PREFIX,, hence wanted to know about it.
Turning out to be a little challenging, I'm still trying to figure out the existing code base and there's no documentation to go with it
Hey @Sean, I'm working on the patch and have asked Kanzure and nmz787 for help on their IRC.Fixing the installation process for pyBRLCAD might take a little while. The post_install script there might be broken (nmz787 tried to set it up from the source code and it keeps breaking). While I'm working on it, I'll also start working on a parallel patch (maybe something from the ToDo list).
So, I've narrowed it down to implementing the centroid function for one of the primitives. Now, from what I'm gathering it's not possible to have a centroid for every primitive.
@Shubham Rathore @Sean Would you recommend any particular primitive that is in priority for having a centroid function implemented?
Also, this is what kanzure and nmz787 had to say about the issues with current python BRLCAD : https://pastebin.com/2hAvmF2B
Hey, python brlcad requires libbu.so or libbu.dll to work with. I've found the libbu folder in the src but am not able to find these files.
Are they to be compiled separately or am I missing out something here?
I'm working on OSX.
that's a shared library, which is built when you compile brlcad. you can find it in your build folder, inside lib
My build/lib doesn't have libbu
I mean, not a .dll or a .so
It has : libbu.20.0.1.dylib libbu.20.dylib libbu.a libbu.dylib
on macos, that's libbu.dylib
assuming you're using kanzure/python-brlcad, it seems like it doesn't support macos (yet), so to begin getting it to work, you will have to make it use .dylibs besides .dlls and .sos
that's what's generating your error, and the message you're getting is about libbu because that's the first library it's looking for
you could try adding .dylib
to the list on line 226 and see what breaks then, and try to fix the new errors
uh, it's a bit messy, but i got it to run examples/hilbert_2d.py
on mac
Screen-Shot-2018-04-13-at-17.21.14.png
cool! anything tricky in the setup?
not really, running the setup shows a lot of errors from the c preprocessor, for things like not finding the definition for FILE, but compilation finishes correctly
other than that, rtgeom.h
was changed to rt/*.h
and *_annotation_*
was shortened to *_annot_*
, and this needs to be reflected in the bindings, but these were small changes
i actually wanted to submit a pull request, but i forget why i didn't do it. i could send it if you want me to
can't hurt if you already did the work
will save the next guy some time
:)
i submitted a pull request. until it's merged, my changes are available here https://github.com/cezarelnazli/python-brlcad
Thanks @Cezar ! BRLCAD python, now installs for OSX. There still seem to be some issues though. The path readers and splitters are a little cranky here so just fixing them now. :) (Ive hardcoded certain paths to get it to install for now)
Also, when I run the examples, none of them run :p_button:
This is the error that pop up on running : /examples/wdb_example.py
https://pastebin.com/SY4wzJrH
Now, I tried looking for OP_UNION in librt but couldn't find it anywhere. Is the function deprecated or am I again missing out on something I dont know :/
regarding your error, i think you're still using the old code (i.e., not the one with my changes)
Oh shoot! I didn't see your latest commit! I'm sorry!
I'll work with them now. I had just changed the libraries to be read as .dylib.
Thanks and sorry :P
ahh, it's fine
@Cezar , does this install right out the box for you or have you made some changes to the setup.py too (uncommited)?
it should work out of the bo
box*
are you having difficulties?
if it starts printing a lot of errors about C code, you can ignore them for now
the installation should still work
Nah, it's not C code errors : It's
File "/Users/Troller/Documents/GSoC/18/OSX/python-brlcad/brlcad/install/options.py", line 352, in load_ctypesgen_options
raise SetupException("Couldn't find a matching brlcad installation !")
SetupException: Couldn't find a matching brlcad installation !
uh, that's because you're not pointing it to a valid installation
i run it as BRLCAD_PREFIX=path_to_build python setup.py install
Yea, so I had manually fixed it then by :
# (HACKFIX : TEMP) Application Directory seems to be manually included when working with OSX
if(sys.platform == "darwin"):
valid_paths.append("/Applications/BRL-CAD : MGED 7.24.0.app/Contents/Resources/brlcad/src")
you're pointing it at the source directory, but it needs the installation directory
i think it should be safe if you're removing "/src" from the path you're appending
Nah, still same error even if I remove /src
Let me try your way of installing.
i don't know what's inside the app, i build brlcad from source
let me download it and look for the path in there
I've build from the source too,
When I run : sudo BRLCAD_PREFIX=/Users/Troller/Documents/GSoC/18/brlcad-svn-trunk/build python setup.py install
Error :
File "/Users/Troller/Documents/GSoC/18/OSX/python-brlcad/brlcad/install/options.py", line 322, in match_brlcad_version
for brlcad_info in brlcad_installations:
TypeError: 'NoneType' object is not iterable
*built
Could it have something to do with version description of python-config.cfg?
Sorry, python-brlcad.cfg
no, the path there needs to be CMAKE_PREFIX set when you ran CMake
To be fair, I'm really confused about the path vars, I don't know what mean what yet :(
in other words, it needs the path where the files are going after running make install
did you run make install?
Yup, I did
did you modify the prefix when running cmake?
if not, look for a brlcad installation inside /usr/local or so
regarding running it against the downloaded binary, it seems the binaries still have the rtgeom.h
header
you could try using the old version of python-brlcad.cfg
Nah, I didn't. I've found /usr/local/brlcad
ok, then use that as the BRLCAD_PREFIX
2018-04-14 13:11:50,557 - brlcad_post_install - DEBUG - Failed running brlcad-config: '/usr/local/brlcad/dev-7.27.0/bin/brlcad-config'
try running that command manually on your cmd line, see if it works, and what errors come up
Doesn't give an error
is there anything else after that line?
that should just be informative, doesn't really mean that the installation failed
Nah, it does fail, but that's where I think the issue is
options.py isn't able to find a valid installation.
ye, but we should figure out why
I modified the python-brlcad.cfg to :
min-brlcad-version: 7.27.0
max-brlcad-version: 7.27.0
does it work now, or did you do that before the errors?
Did that before the errors :/
anyway, i would say try running BRLCAD_PREFIX=/usr/local/brlcad/dev-7.27.0 python setup.py install
i think it's trying to figure out paths itself, but failing
That's what I've been running.
So, if you look at line 348 : brlcad_installations = find_brlcad_installations(config, logger)
brlcad_installation = none
def check_brlcad_installation(brlcad_prefix, bin_subdir, logger):
is unable to find a valid installation..
i know that, but to get it to work, we need to figure out why
Yea, i'm working on it as we speak
in options.py
, inside get_brlcad_param
, try to print the list in the check_output
call
[brlcad_config, "--" + param_name]
this one
That's weird.. , result is : "/usr/brlcad/dev-7.27.0"
printing the list? or the result of the call to brlcad-config
?
hmm... you talked earlier about getting around the SIP on mac
did you just move the folder from /usr/brlcad to /usr/local/brlcad?
or did you rerun cmake a second time, with /usr/locla/brlcad?
I ran a cmake again
Running all the brlcad-config commands manually doesn't seem to be giving any error
but what output do they give?
if you run it using brlcad-config --includedir
Ok, I think I figured the error
So running brlcad-config --include dir gives : /usr/brlcad/dev-7.27.0/include
option.py : line66
elif param_name in ["libdir", "includedir", "prefix"]:
# these are dirs: check if they exist, raise exception if not
if not os.access(result, os.R_OK):
raise SetupException("Directory for <{0}> not found: {1}".format(param_name, result))
This is where the issue is coming: if not os.access(result, os.R_OK):
Ran this interactively :
os.access("/usr/brlcad/dev-7.27.0/include", os.R_OK)
False
does /usr/brlcad/dev-7.27.0
even exist?
AAHHH!! :(
anyway, that brlcad-config
is not sane
it should give the path it's running from, not the /usr/brlcad one
it should be /use/local/brlcad
yep
i looked at the binary distribution, and i see that it still has the old rtgeom.h
header
so maybe try replacing python-brlcad.cfg
with the old version (not mine), and rerunning python setup.py install
I still don't understand one thing
Macbook:python-brlcad $ /usr/local/brlcad/dev-7.27.0/bin/brlcad-config --prefix
/usr/brlcad/dev-7.27.0
shouldn't it return /usr/local/brlcad/dev-7.27.0 ?
Or did I mess up somewhere in the installation and setting my prefix there?
ye, you probably messed the setup
Aw man! :/
you could nuke the build dir and rerun it
Yea, I think that's the best thing to do right now?
Also, why were you recommending using the old python-brlcad.cfg?
To reinstall I'll have to delete : /usr/local/brlcad and the build folder?
the old one was using the rtgeom.h
header instead of rt/*.h
. the newer versions, such as the ones built from svn, use rt/*.h
, which is why i made the changes. but the one you have in /Applications/ uses the old rtgeom.h
Ah! I see
as for reinstallation, yes, those are the folders you'll want to delete
i do cmake .. -DCMAKE_INSTALL_PREFIX=path_to_build -DBRLCAD_EXTRADOCS=OFF
Cool! I'll do that
Right away :P
CMAKE_INSTALL_PREFIX
is set to the directory you're in when building, because i don't like to clutter my path with dev stuff
additionally, if you have ninja (or if you don't, and you have homebrew, you can brew install ninja
), you can add a -G Ninja
, it seems to build stuff faster
and properly displays errors when building on multiple threads, as opposed to make
Wait, CMAKE_INSTALL_PREFIX shouldn't be /usr/local ?
if you want brlcad to be installed to /usr/local/
, then you can set it to /usr/local
. like i said, i don't want it there for myself, but you can put it there if you want to
shouldn't matter
Uh-huh. Yea yea. Makes sense.
It's doing it's magic and installing now. I hope nothing breaks!
I've got class now for 90 minutes so will be AFK for a while.
Thanks a ton @Cezar today cleared up a lot of things for me!
Also, I'm building in the build folder itself
camke failed, errors! Ugh, I'll fix these in ASAP
Compile libpng ........................: OFF
Compile libregex ......................: OFF
Compile zlib ..........................: OFF
Compile termlib .......................: OFF
how is that an error?
Sorry, was sharing something else. Was rushing to class and ended up posting this
I installed again with : cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/
Yet, the output for :
Macbook:build $ /usr/local/brlcad/dev-7.27.0/bin/brlcad-config --prefix
/usr/brlcad/dev-7.27.0
how about /usr/local/bin/brlcad-config --prefix
?
Nah, there's nothing there
Just give me a couple of minutes, I'm going to try something :P
Hey @Cezar the installation works now! I'm getting a ton of C errors but I'm not sure if they're going to impact in any way
The errors are on the lines of : https://pastebin.com/HZ8xKvXH
it's fine
those errors are generated by the C preprocessor because it's processing header files "alone" and some definitions are not found. for example, if you do #include <stdio.h> #include "rt.h"
, and use the FILE
type inside rt.h
, it's fine. but if you don't include stdio.h
inside rt.h
, when you're running the preprocessor on rt.h
alone, it won't have stdio.h
and complain and throw all those errors. but compilation in pyhton-brlcad works
sorry if what i said is badly written and doesn't make a lot of sense
by the way, how did you solve the previous problem?
Ah! Yea that makes sense
So essentially, I reinstalled BRLCAD.
Commented out some parts of this function : https://pastebin.com/XML8jqfq
And cleaned the string returned from : result = subprocess.check_output([brlcad_config, "--" + param_name]). It was having trailing newline characters for some reason
hmm... i think you had messed with it in your previous experimentations
the clean version has a .strip()
at the end, which strips any whitespace (including newline)
Yea I suppose so
:/
Though I'm really glad this finally worked!
@Cezar I'm planning to take up this project and work with it during this summer as a part of GSoC. As of for now, I'm required to submit a patch of any sorts improving the current project. What would recommend would be a good patch? Any ideas off the top of your head.
i'm a student as well, and i don't know anything about this project, sorry
Aye! Thanks a ton for all the help though :)
Hey @Sean , I've sent you an email with the patch. I've managed to get python BRLCAD working on OSX and am working on building a primitive right now.
I had messed up the initial installation and that's why there was a lag.
thanks @Jaipal Singh - please submit it to the patch tracker or pull request for feedback
Sure thing @Sean :)
Hey @Shubham Rathore , I've updated my project details on http://brlcad.org/wiki/Google_Summer_of_Code/2018
Hey @Sean, what part of http://brlcad.org/wiki/Summer_of_Code/Acceptance do we need to submit in writing?
You need to submit an email saying whether or not you accept the participation requirements in full.
Ah okay!
Hey @Shubham Rathore , a quick update on the project. I'm going through nmz787's python bindings for primitives. I personally feel that they are a great alternative to the initial project by kanzure and seem to be rather simple and straight forward to use. What're your views for the same?
How it works is, It creates a tcl file, then sends it to mged which then creates and populates a .g file database, the .g file is then converted with g-stl to produce an STL file.
I'm going through the code to have a clearer picture of how it works (shouldn't take very long though).
https://github.com/nmz787/python-brlcad-tcl
Hi, Jaipal. First of all, can I get the link to your local repo where you've done the work mentioned previously. Or did you get it committed to the original kanzure repo. In that case I'd suggest to make a local copy and work on it. Plus updation on the readme for the macOs support should be a must.
That's close to what we are trying to accomplish. I'll give you a formal definition of what need to do. First of all, just focus on binding the relevant primitives( not all primitives are required) . This shouldn't take much time. Once this is done, what we were thinking was of having a script primitive itself where you can implement the primitive in python. Kindly read about the Procedural geometry objects (line 1823) in TODO. This will give you an overview.
Last updated: Nov 15 2024 at 00:49 UTC