@Jaipal Singh welcome -- you'll need to look through the previous GSoC projects on our wiki, find the ones related to python, and check out the reference links on the idea page
Hey @Sean ! Sure, I'll go ahead and do that.
please do ask questions if you have them, the more specific the better
@Sean , from what I have collected, the last work on python-brlcad was done in 2014, by Kanzure (https://github.com/kanzure/python-brlcad)>
((Please correct me if I'm wrong here))
There's not much documentation available for this on the github page, would it be present in the brl-cad docs somewhere?
If not, I could spend a while fidgeting around and figure out what does what.
@Jaipal Singh Hello, hope you got familiar with the basics of BRL-CAD. As you may have figured out by now, that we have numerous primitives out of which only a portion of which has been implemented in python. (http://brlcad.org/wiki/Python_Geometry)
You may find useful to have a look at code for the converted primitives- > https://github.com/kanzure/python-brlcad/tree/master/brlcad/primitives . Here you can find the implementations for the converted primitives (arb8.py, ebm.py etc.)
After having a look at them you may be able to figure out the set of functions required :
- update_params()
- copy()
- has_same_data()
- from_wdb () etc.
Having a look at these primitives will give you an insight into wrapping the remaining primitives i.e. ARS, BINUNIF, BOT, BREP, CLINE, DSP etc.
I hope this helps.
Do ask questions if you get stuck somewhere. Cheers !
Hey @Shubham Rathore Thanks a ton for the insights! I'll surely go ahead and work on these. Shall keep you posted! Cheers!
Hey @Shubham Rathore , I'm done with the mged tutorials chapter 1 and 2 (because I thought those were the ones that were most relevant for this project). Would you suggest going through any other particular topics?
I've also gone through the code for some of the primitives in python (ars, base, etc) and I won't say I understood a lot. Could you point me to where I might have a look at their C-code?
Also, how are the python primitives brought to life? I mean, where can one see them working or test them out in development?
I'm going to have a go at explaining the different functions that you mentioned.
update_params() : essentially populates the points for a given primitive. Every primitive takes 8, 3 dimensional points that are then used to plot the primitive
copy() : maybe attributes the points matrix to a given primitive name
has_same_data() : probably as the name suggests, compares the point matrices for two given primitives?
Hey @Shubham Rathore , I'm done with the mged tutorials chapter 1 and 2 (because I thought those were the ones that were most relevant for this project). Would you suggest going through any other particular topics?
The basic motive is to get familiar with the working of BRL-CAD. Tutorials are indeed the best way to get familiar :)
I've also gone through the code for some of the primitives in python (ars, base, etc) and I won't say I understood a lot. Could you point me to where I might have a look at their C-code?
BRL-CAD code resides on sourceforge. Please do have a look !
Sure! Thanks!
Also, how are the python primitives brought to life? I mean, where can one see them working or test them out in development?
Refer this: https://github.com/kanzure/python-brlcad/blob/master/README.md
Hey @Shubham Rathore , I'm done with the mged tutorials chapter 1 and 2 (because I thought those were the ones that were most relevant for this project). Would you suggest going through any other particular topics?
@Jaipal Singh that's good though for something like the python project, it might actually help for you to go through even more tutorials, maybe all of them since the heart of wrapping geometry in python would be the ability to do all 16 tutorials with python eventually
also, take a look at the appendix at the end of the tutorials for a listing of many primitives. in code, they are all in src/librt/primitives
Greetings,
This is Deepak Sharma, final year master's student from Canada. I would like to work on OGV for this GSoC. As OGV has been reached almost at final stage of it's release I would also like to add my shots in it so that we can release it by the end of this GSoC.
Happy to be the part of the BRL-CAD family and looking forward to contribute to the organization with the guidance of esteemed mentors and other great minds already working.
Hey @Sean Sure! I'll go ahead and complete all the tutorials in a couple of days. Also, I've been reading up on the source for the primitives in src/librt/primitives and drawing a rough comparison between the c-code and the python-wrappings for individual primitives. I'm trying to figure out what sort of functionality is given to different primitives. From what I've collected all of them seem to have a basic definition of their parameters and certain constant functions (__init__, copy, has_same_data, update_params) in the python code along with some other wrapping having additional functions not present in the others.
Thanks @Shubham Rathore for your feedback on the doc, I'll go through them and revert back to yo if I have some doubts! :)
Hey DK,
How are you? It's your second GSoC participation, is it?
Anyway, welcome back dude! Nice to see you back here again. Please take a look at github issues and the project. Try to do as many low hanging PRs as possible and please keep me involved while drafting the proposal. We want to cater to tougher and important things this time so we gotta make sure that only most important things are done.
Hello @pooh (inder)
How are you? Hope everything is going well.
Yes, it's my second GSoC. I have gone through project idea page and it seems this time there is a lot of work to do.
I have updated it to meteor's latest version and submitted PR for the same. Please have a look at it (https://github.com/BRL-CAD/OGV-meteor/pull/76).
Moreover, I have found many problems in development branch version. I have something to ask and something to share.
What says let's have a group talk about this stuff.
@Sean @pooh (inder) let's set tables and discuss more thing on this. I too want to share some plans/ideas of mine regarding OGV.
@Jaipal Singh keep a particular eye out for the "wdb" interface, which is the API for creating geometry (see include/wdb.h and src/libwdb)
@Tejas Ajay Zodage thanks for the intro -- you'll want to also introduce yourself on the freecad forums or IRC channel (neither of which is here). also, big bonus points if you can find a way to make some part of your project general or reusable by other projects as well as for freecad
Welcome @Fatema , this channel is for asking questions, so no need to ask for asking :wink:
simply ask your stuff and wait for response
and take care to use appropriate stream and topic for your questions, like this one
Hey @Sean! I've been looking going through libwdb and will share a couple of doubts that I have soon. Also, sorry for being rather inactive in the past week, I was caught up with my mid-term exams at university.
Ok then I was enquiring about task "Material and Shader Objects" if it is taken yet.
As I am familiar with C and have previously worked with Shaders and OpenGL.
If I could have some pointers to tackle in the task to be more familiar. xD thank you
@Fatema
Every idea is still available ;)
To become familiar with this topic you should download the sources from our subversion repository (see https://brlcad.org/wiki/SVN, you want the brlcad module there), compile the programs (see https://brlcad.org/wiki/Compiling, which OS do you work with?), and go through our tutorial series (https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf) to learn how materials and shaders are currently handled.
Feel free to ask questions here if you get stuck, sourceforge (where our source code repository is hosted) and the compilation process are currently a little bit bumpy.
Thank you for responding, I followed the process but stumbled in compilation. I had an error linking some libraries.
Linking C executable ../../bin/g-nff
../../lib/librt.so.20.0.1: undefined reference to `_tthread_timespec_get'
collect2: error: ld returned 1 exit status
src/conv/CMakeFiles/g-nff.dir/build.make:110: recipe for target 'bin/g-nff' failed
make[2]: [bin/g-nff] Error 1
CMakeFiles/Makefile2:21550: recipe for target 'src/conv/CMakeFiles/g-nff.dir/all' failed
make[1]: [src/conv/CMakeFiles/g-nff.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
@Fatema you're also encouraged to check out openscad -- i don't think they have enough interest from gsoc candidates. your brl-cad quild error is from a recent change -- try Release build type instead of the default.
[DOUBT : Python BRLCAD]
Hey folks, I'm working on setting up python brlcad (https://github.com/kanzure/python-brlcad). I'm trying to follow the step wise procedure to set it up.
When I run the setup.py, I get the error : "SetupException: Couldn't find a matching brlcad installation ! "
I have brlcad up and running on my system but it seems like python is unable to pick it up. I'm on OSX(10.12.6). Any suggestions on how to overcome this?
Dump from the last installation failure : https://pastebin.com/GaJgRRUL
I'll try building it from the source and see if that can solve the problem
Also, it seems like python brlcad is designed to run only with python2.7. Do you think we should extend support for 3.x versions as well?
@Sean From what I understand about libwdb, it helps in writing to the database by acting as an interface and librt would help in reading from the same.
Also, it seems like python brlcad is designed to run only with python2.7. Do you think we should extend support for 3.x versions as well?
That seems like a bit of a silly question, don't you think?
I'd agree it's a silly one, was just wondering if this were a priority. I figure it would be
I found a few primitives like "cone" https://github.com/kanzure/python-brlcad/blob/c1efe9e0823ebe30e3a2a01ac021b2c080c8ebf2/brlcad/wdb.py#L179 ), that were being created by wdb but they didn't have a corresponding wrapper in the primitives folder. How does that work?
Are we somehow trying to use solids like RCC to create cones (certain parameters can result in a cone)? If so, what is the use of other primitives like TGC? Is it common (or even allow) to use one solid to create a different shape?
[DOUBT : Python BRLCAD]
Hey folks, I'm working on setting up python brlcad (https://github.com/kanzure/python-brlcad). I'm trying to follow the step wise procedure to set it up.When I run the setup.py, I get the error : "SetupException: Couldn't find a matching brlcad installation ! "
I have brlcad up and running on my system but it seems like python is unable to pick it up. I'm on OSX(10.12.6). Any suggestions on how to overcome this?
Hi @Jaipal Singh , we dont have support for OSX currently. Perhaps you could work on it ! Your first priority should be to wrap the remaining primitives, then work on the tests. First make sure that things work on linux itself (virtual env may be a good option in case you dont own a linux machine). Extending support for other OSes doesnt sound a big task and can be done with quite ease. (python 3 is obviously a priority :P )
VMBox sounds like a good idea to test and break things.
@Shubham Rathore How do I decide what primitives are remaining to be wrapped? Would I be following the list given here : https://brlcad.org/wiki/BRL-CAD_Primitives ?
I found a few primitives like "cone" https://github.com/kanzure/python-brlcad/blob/c1efe9e0823ebe30e3a2a01ac021b2c080c8ebf2/brlcad/wdb.py#L179 ), that were being created by wdb but they didn't have a corresponding wrapper in the primitives folder. How does that work?
I would assume it doesn't. Remember that the last work on the python wrapper was several years ago, so it's also likely that some calls will have changed or been renamed or added, etc.
Are we somehow trying to use solids like RCC to create cones (certain parameters can result in a cone)? If so, what is the use of other primitives like TGC? Is it common (or even allow) to use one solid to create a different shape?
some primitives are simply special cases of another. sphere is a special case ellipsoid where the three orthogonal vectors are equal length. similarly, rcc is a special case tgc.
VMBox sounds like a good idea to test and break things.
@Shubham Rathore How do I decide what primitives are remaining to be wrapped? Would I be following the list given here : https://brlcad.org/wiki/BRL-CAD_Primitives ?
I would suggest looking at the source code, not just whatever happened to be documented on the wiki...
VMBox sounds like a good idea to test and break things.
@Shubham Rathore How do I decide what primitives are remaining to be wrapped? Would I be following the list given here : https://brlcad.org/wiki/BRL-CAD_Primitives ?I would suggest looking at the source code, not just whatever happened to be documented on the wiki...
So, would this mean, all the primitives defined in librt only?
VMBox sounds like a good idea to test and break things.
@Shubham Rathore How do I decide what primitives are remaining to be wrapped? Would I be following the list given here : https://brlcad.org/wiki/BRL-CAD_Primitives ?I would suggest looking at the source code, not just whatever happened to be documented on the wiki...
So, would this mean, all the primitives defined in librt only?
Hi @Jaipal Singh ! librt comprises of all the primitives that we have. So its a yes !
Great! Thanks @Shubham Rathore
if i want to submit a draft, should i do so in the gsoc interface, or on the wiki?
also, there will be some things that i'll need to look into more after submitting the proposal (e.g., how the code for the ray tracer works, how libbu is used in other places), and i was wondering if this is okay. and if so, should i put this in the "community bonding" section, or in the first phases of the coding section?
oh, and i'm also curious what happens during community bonding
@Cezar : Hey! I'm not a mentor for BRLCAD but as someone who's done GSoC before, I think I can answer your questions.
Your proposal is not very hard and fast. Deadlines and objectives can vary based on the progress of your project.
The community bonding period on the other hand gives you an opportunity to get well versed with the code-base you'll be working with and gather all the pre-requisite information required to meet your deadlines in the next 3 months. This is the phase where you can work with your mentor to finalize the fine grained nuances of your project and more or less finalize everything in your proposal.
Hey! I'm Peter and I'd like to apply as a student for GSoC. I know C and some C++ (and lots of Lua and some Python (and lots of etc)) and I think I could do one of the easy projects. The Lua scripting support is very tempting, so is the general tree walker because I like refactoring things. The STEP exporter and the exec option also seem interesting.
What I'd like to know is which one is most urgent and what are the difficulties? (also, the STEP reference links aren't working, they need authentication)
if i want to submit a draft, should i do so in the gsoc interface, or on the wiki?
gsoc interface will be fine for feedback, that way you at least have your account set up and a rough draft submitted
also, there will be some things that i'll need to look into more after submitting the proposal (e.g., how the code for the ray tracer works, how libbu is used in other places), and i was wondering if this is okay. and if so, should i put this in the "community bonding" section, or in the first phases of the coding section?
it's okay not knowing everything there is to know, but you should keep doing research, work on a patch or three in related code, reading code, discussing your project all the way to the submission deadline (and after if you like). community bodying period is for doing any additional research needed, so that really shouldn't go into the coding section. community bonding is also typically where gsocers get familiarized with code, get fully set up to code, and continue working on code related to their project (maybe even directly supporting their project).
Hey! I'm Peter and I'd like to apply as a student for GSoC. I know C and some C++ (and lots of Lua and some Python (and lots of etc)) and I think I could do one of the easy projects. The Lua scripting support is very tempting, so is the general tree walker because I like refactoring things. The STEP exporter and the exec option also seem interesting.
What I'd like to know is which one is most urgent and what are the difficulties? (also, the STEP reference links aren't working, they need authentication)
welcome @Peter Pronai and thanks for the intro! of the topics you mentioned, step export would be the most beneficial but by far the hardest, too, so don't consider it unless you have significant geometry experience. between lua and exec -- exec is far more pressing as it would result in an immediate end-user feature.
i've uploaded a link to my draft on the gsoc website. i expect there to be things you want me to add or modify, but i submitted it to see where exactly i should make the changes.
@Sean thanks for the warm welcome! I only have experience with Blender, which is (nearly) entirely polygonal, so I don't think I have the "significant geometry experience" that would be required for STEP, so that leaves --exec
. I'll take a closer look at it today.
@Peter Pronai the search command is HEAVILY based on the unix "find" command, so you should read up on that as well (particularly find's -exec option). lots of tutorials all around the web
@Sean I checked man find
to brush up. I admit I didn't know about the alternative form. Would BRL-CAD need any of those?
@Peter Pronai what do you mean by "alternative form"?
@Sean there is apparently a find -exec command {} +
form, at least in my version of GNU coreutils. I am honestly not sure what its use case is.
@Peter Pronai yes there is a find -exec command {} + form, so what is the "other" form? like I said, you'll need to become experienced in how the find command works including the -exec flag (do some tutorials).. if you don't know it's use case, then you don't know what to do for your project
@Sean The one I've used and seen everywhere is find -exec command {} ;
, the same that is given as an example in the project description. I have never needed the +
form before and I have never seen anyone use it.
It is not even present in every version of find, such as UNIX v8: http://man.cat-v.org/unix_8th/1/find
So, my question is, should a GNU extension even be considered?
ahh, didn't realize you were referring specifically to the substitution form
do you understand the difference of ; vs + ?
I would think it's trivial to support it, but don't get distracted. the focus should very much on getting -exec to work properly. you should definitely understand the difference between the two and where that comes in handy, understand what xargs does, etc.
It looks like it adds all(?) files as arguments to command
. I guess it's useful for when you want to run a single command over them? To be honest I would just use the output of find, using that weird option is IMHO too cryptic.
@Sean (but there is probably some weird edge cases with weird file names that would be hard to handle from the shell)
I think I understand xargs
although I haven't had to use it so far. It builds argument lists and sends them to commands and there are some extra modes for handling different input formats and limiting arguments.
figuring out edge cases is a problem with {} substitution regardless of ; or + .. and that's an essential issue you would have to make sure works as part of any development plan and unit testing (which should be part of your proposal).
you should definitely go through tutorials on xargs as it's relevant, related. kinda important and a powerful fundamental command.
It looks like it adds all(?) files as arguments to
command
. I guess it's useful for when you want to run a single command over them? To be honest I would just use the output of find, using that weird option is IMHO too cryptic.
it's certainly not a priority, but you should fully understand what it does as it is part of the find interface (per posix) it was adopted quite some time ago: https://collaboration.opengroup.org/external/pasc.org/interpretations/unofficial/db/p1003.2/pasc-1003.2-210.html
i added a weekly schedule to my proposal :D
@Sean @Shubham Rathore Submitted the draft! Please let me know what I could do to improve it :)
@Sean as I understand it, the crux of the problem is that Tcl commands (at least in this version of the language) only take strings as arguments, so there is no function passing or lambda expressions (I'm not even sure it has closures), so search
has to call-by-name, but all the command names live currently live in MGED alongside the global Tcl interpreter. Commands are not simply C functions, they are also assigned a ClientData
, which gets passed to them.
As for the Tcl side:
Curly braces probably can't be used unquoted because they are syntactically significant in Tcl? (although a different character (pair) could also be used instead, this is probably the smallest issue)
I think eval
could be used for running the command
but since paths can have funny characters in them, they must be safely quoted. I'll have to look more at Tcl but I've solved similar problems in Lua so I think I can find a bulletproof way. If all else fails, there is base64: Instead of constructing the eval string by placing paths in it, encode the path in base64 and place a [base64dec <path-in-base64>]
inside.
The bigger problem is not on the Tcl side but on the C side, right?
@Sean The name resolution part is trickier and I don't entirely understand how it would ideally look......
I'll write my thought process here:
So, cmd_search
is in mged/cmd.c
, it has no associated libged
function in the command table, instead it uses ged_search
internally.
And GED in turn wraps the raytracer search.
So. db_seach is what ultimately does the searching, right? libged seems to just do a lot of very complicated and deeply nested processing on the search results.
Note: there are a lot of unnamed constants, eg.: search_type != 1
, I think it would be better to give the search types an enum.
@Peter Pronai this is an in-depth topic but search -exec should be completely independent from Tcl -- that's what makes this a project. you need to be able to invoke commands and pass arguments along to other commands, which means there needs to be a dictionary or registration of commands somewhere and the ged state will need to get passed from ged_search() to the other ged_*() commands some how
doing that, names/paths are merely lookup keys which could refer to object already looked up and stored in the ged struct
but that's for later. starting with strings is fine. the trick is how ged search can call another ged command without it explicitly knowing about them all directly (hence a registry of some sort)
So. db_seach is what ultimately does the searching, right? libged seems to just do a lot of very complicated and deeply nested processing on the search results.
Note: there are a lot of unnamed constants, eg.:search_type != 1
, I think it would be better to give the search types an enum.
Yes, librt does the low-level lookups, libged does the formatting/printing of the output (and should manage ged state)
the search constants could be converted, but I'd save that for later -- the code was directly forked from BSD 'find' command code and adapted for our use
@Sean
there needs to be a dictionary or registration of commands somewhere
Isn't the Tcl interpreter enough? It has full access to its namespace (which, afaik, is dynamic, so there is no guarantee that eg. analyze
will still be called analyze
when we run search
), so it should be able to inspect them and see if they are from C or if they are defined in Tcl.
that's certainly possible @Peter Pronai but it wasn't what I originally had in mind ... let's talk it through.
from an API perspective there will eventually be something like ged_exec() that is called by some shell environment
right now, that environment is a Tcl one, so it's easy enough to pass the Tcl_Interpreter down through (i..e., keep it stashed in the ged struct) and then ged_search() could use it to invoke subcommands
however, it could just as well use ged_exec() to invoke subcommands too, and be fully agnostic of Tcl
so the implication, I suppose is whether / how we can get at built-in commands that possibly wouldn't be registered with libged (e.g., pwd), and being able to invoke them via search -exec
@Sean What if we pass function pointers in db_search
? The prototype would include the database and the current path as parameters, return type would be bool
and it should probably have a void *userdata
parameter too.
That way the calling environment can decide what to do, eg. MGED could send a pointer to a function that wraps a Tcl procedure. It can also do a simple parse of the search
parameters and translate -exec
s into function pointers. If it's a Tcl function, the interpreter can be passed along in the userdata. This is a bit ugly but avoids librt
having to know about Tcl.
possibly, we definitely don't want librt to know about Tcl directly
I don't recall exactly, but I think the exec logic from 'find' would also be down in db_search() since that's the original code
we probably should remain as aligned as possible with 'find' in case we ever need to re-do our implementation
so then the question is whether libged is doing the exec parsing/invoking or whether librt is doing it
I think libged should do it, librt should get an "AST" as a parameter. (not exactly an AST because it wouldn't necessarily just contain strings)
conceptually, libged is supposed to be the "command strings to result strings" layer and librt is supposed to be the "object name to object layer"
the difficulty is that most of the processing that search/find does is in object-space (i.e., librt) while most of the work done by -exec is in string-space (i.e., libged)
the command-line parsing of find/search is quite intricate, so separating them is not exactly easy or desirable
Is parsing dependent on any context? Couldn't it be cut out into an external routine?
find's syntax is stateful based on previous arguments and expressions
But AFAIK not on anything external, so it won't treat something differently if eg. there is a file with the same name.
so you can do things like: find . -type f -exec chmod 664 {} \; -type d -exec chmod 775 \; -o -not ( -type d -o -type f ) -exec echo oh no \;
Sooo, is cutting out parsing a bad idea?
what I think needs to happen is that ged_search() needs to pass a callback (e.g., ged_exec) and data parameter (e.g., struct ged) to db_search() where the -exec logic lives, that way db_search() can invoke the callback, pass the data, and the args as a simple argc/argv while maintaining a context (the struct ged)
then it can be ged_exec's problem to utilize the Tcl interpreter or not
I think that sounds good. Can't really think of anything better.
still won't mean it's easy, but that's why this is a gsoc project ;)
that's why it's fun too :D
should we talk milestones then?
you'll have to think through milestones and objectives hand in hand -- considering the proposed implementation approach, how it'll be tested/verified, documentation, etc
(I guess I was thinking of deliverables then? anyways)
Can I use TTD? Should I commit failing tests?
TDD is great
s/TTD/TDD/ doh
As for passing callbacks, I think an easy way to do it would be passing them together in an array? The plan string could encode which exec refers to which callback.
not following, what do you mean?
typewise, there needs to be a pointer to a function and a pointer to an object/data ... technically, you can put the function pointer into the object/data pointer, so that is the bare minimum
whether that minimum makes sense or not, wouldn't know without seeing a specific api proposed
or examples how it gets used like some test cases
in db_search, the plan_str roughly equals a program right? that is the thing that encodes what tests to run on each node and what logical operations to combine the tests with. -exec
is just a node in that, but it needs to refer to a callback, so what I was thinking:
add a callback_t callbacks[]
parameter in db_search
and make plan_str
index into that. would need some bounds checks but that's it.
Ohhhhhh. Wait. Nevermind. The callback is per-db_search call, not per-exec-option. Yeah, that makes more sense.
So the translation happens inside the callback.
NOT inside ged_search or cmd_search
doh #2
that sounds right. You may want to look at some original find.c bsd source code to see how they implement -exec since that's essentially what needs to be added back.
I finished a draft proposal, could you (or someone) take a look at it?
http://brlcad.org/wiki/User:Paddedto10#GSoC_proposal_:_Adding_support_for_the_-exec_option_in_the_search_command
looks really good @Peter Pronai -- the only thing that would make it better is demonstrating your ability to code by submitting a code patch, either related to search exec or libged ... there's a whole TODO in src/libged as well as some items in the top level TODO and BUGS files
Hey @Sean ! I've submitted the draft, let me know what you think? :)
Thanks for the feedback @Sean ! I'll look into the bugs in a sec.
I didn't have energy for it yesterday, but I added a sample patch in the last hour. I've updated my wiki page and the proposal.
ah, nvm, gotta fix a few build errors first
@all There is time in the Application Review Period to provide patches. We'll probable ask you to make some improvements to your proposals, schedule time for testing and documentation, providing a patch, etc.. Don't panic.
Thanks, I wasn't sure if that also had the same deadline. I guess I'll take it slower then.
Hey @Sean ! I've submitted the draft, let me know what you think? :)
That's great. If we could have a piece of code from your side demonstrating your coding abilities, it'll be good. Cheers !
Sure thing @Shubham Rathore I'll submit a couple of patches soon :)
Last updated: Nov 16 2024 at 00:47 UTC