Sean (Mar 02 2018 at 14:07): Sean (Mar 02 2018 at 14:07):@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
Jaipal Singh (Mar 02 2018 at 16:15):Hey @Sean ! Sure, I'll go ahead and do that.
Sean (Mar 02 2018 at 19:28):please do ask questions if you have them, the more specific the better
Jaipal Singh (Mar 03 2018 at 10:38):@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))
Jaipal Singh (Mar 03 2018 at 10:40):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.
Shubham Rathore (Mar 04 2018 at 17:36):@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 !
Jaipal Singh (Mar 04 2018 at 18:00):Hey @Shubham Rathore Thanks a ton for the insights! I'll surely go ahead and work on these. Shall keep you posted! Cheers!
Jaipal Singh (Mar 05 2018 at 16:40):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 (Mar 05 2018 at 16:42):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?
Jaipal Singh (Mar 05 2018 at 16:43):Also, how are the python primitives brought to life? I mean, where can one see them working or test them out in development?
Jaipal Singh (Mar 05 2018 at 16:53):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?
Shubham Rathore (Mar 06 2018 at 05:18):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?
Shubham Rathore (Mar 06 2018 at 05:19):The basic motive is to get familiar with the working of BRL-CAD. Tutorials are indeed the best way to get familiar :)
Shubham Rathore (Mar 06 2018 at 05:20):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 !
Jaipal Singh (Mar 06 2018 at 07:35):Sure! Thanks!
Shubham Rathore (Mar 06 2018 at 16:11):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
Sean (Mar 09 2018 at 17:16):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
Sean (Mar 09 2018 at 17:17):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
ih8sum3r (Mar 10 2018 at 05:09):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.
Jaipal Singh (Mar 10 2018 at 05:27):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.
Jaipal Singh (Mar 10 2018 at 06:29):Thanks @Shubham Rathore for your feedback on the doc, I'll go through them and revert back to yo if I have some doubts! :)
Inder Singh (Mar 10 2018 at 10:41):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.
ih8sum3r (Mar 11 2018 at 04:01):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.
Sean (Mar 12 2018 at 01:34):@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)
Sean (Mar 15 2018 at 02:04):@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
Armin (LordOfBikes) (Mar 18 2018 at 09:22):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
Jaipal Singh (Mar 18 2018 at 13:05):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.
Fatema (Mar 18 2018 at 21:46):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
Daniel Rossberg (Mar 19 2018 at 16:14):@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.
Fatema (Mar 19 2018 at 21:26):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
Sean (Mar 20 2018 at 05:46):@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.
Jaipal Singh (Mar 21 2018 at 17:41):[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?
Jaipal Singh (Mar 21 2018 at 17:44):Dump from the last installation failure : https://pastebin.com/GaJgRRUL
Jaipal Singh (Mar 21 2018 at 17:54):I'll try building it from the source and see if that can solve the problem
Jaipal Singh (Mar 21 2018 at 18:04):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?
Jaipal Singh (Mar 21 2018 at 18:18):@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.
Sean (Mar 22 2018 at 04:53):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?
Jaipal Singh (Mar 22 2018 at 06:40):I'd agree it's a silly one, was just wondering if this were a priority. I figure it would be
Jaipal Singh (Mar 22 2018 at 06:42):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?
Jaipal Singh (Mar 22 2018 at 06:47):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?
Shubham Rathore (Mar 22 2018 at 10:01):[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 )
Jaipal Singh (Mar 22 2018 at 11:29):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 ?
Sean (Mar 22 2018 at 14:03):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.
Sean (Mar 22 2018 at 14:05):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.
Sean (Mar 22 2018 at 14:16):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...
Jaipal Singh (Mar 23 2018 at 05:39):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?
Shubham Rathore (Mar 23 2018 at 05:54):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 !
Jaipal Singh (Mar 23 2018 at 06:02):Great! Thanks @Shubham Rathore
Cezar (Mar 23 2018 at 11:05):if i want to submit a draft, should i do so in the gsoc interface, or on the wiki?
Cezar (Mar 23 2018 at 12:10):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?
Cezar (Mar 23 2018 at 12:11):oh, and i'm also curious what happens during community bonding
Jaipal Singh (Mar 23 2018 at 12:26):@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.
Jaipal Singh (Mar 23 2018 at 12:27):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.
Peter Pronai (Mar 23 2018 at 22:48):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)
Sean (Mar 24 2018 at 01:54):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
Sean (Mar 24 2018 at 02:32):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).
Sean (Mar 24 2018 at 03:05):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.
Cezar (Mar 24 2018 at 12:36):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.
Peter Pronai (Mar 24 2018 at 16:55):@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.
Sean (Mar 24 2018 at 22:02):@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
Peter Pronai (Mar 25 2018 at 01:27):@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?
Sean (Mar 25 2018 at 05:01):@Peter Pronai what do you mean by "alternative form"?
Peter Pronai (Mar 25 2018 at 16:10):@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.
Sean (Mar 25 2018 at 18:07):@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
Peter Pronai (Mar 25 2018 at 18:12):@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?
Sean (Mar 25 2018 at 18:18):ahh, didn't realize you were referring specifically to the substitution form
Sean (Mar 25 2018 at 18:19):do you understand the difference of ; vs + ?
Sean (Mar 25 2018 at 18:22):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.
Peter Pronai (Mar 25 2018 at 18:29):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.
Peter Pronai (Mar 25 2018 at 18:32):@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.
Sean (Mar 26 2018 at 05:37):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).
Sean (Mar 26 2018 at 05:37):you should definitely go through tutorials on xargs as it's relevant, related. kinda important and a powerful fundamental command.
Sean (Mar 26 2018 at 05:43):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
Cezar (Mar 26 2018 at 08:38):i added a weekly schedule to my proposal :D
Jaipal Singh (Mar 26 2018 at 09:00):@Sean @Shubham Rathore Submitted the draft! Please let me know what I could do to improve it :)
Peter Pronai (Mar 26 2018 at 15:59):@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?
Peter Pronai (Mar 26 2018 at 16:07):@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.
Peter Pronai (Mar 26 2018 at 16:10):And GED in turn wraps the raytracer search.
Peter Pronai (Mar 26 2018 at 16:30):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.
Sean (Mar 26 2018 at 17:25):@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
Sean (Mar 26 2018 at 17:25):doing that, names/paths are merely lookup keys which could refer to object already looked up and stored in the ged struct
Sean (Mar 26 2018 at 17:26):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)
Sean (Mar 26 2018 at 17:37):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)
Sean (Mar 26 2018 at 17:37):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
Peter Pronai (Mar 26 2018 at 18:24):@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.
Sean (Mar 26 2018 at 18:38):that's certainly possible @Peter Pronai but it wasn't what I originally had in mind ... let's talk it through.
Sean (Mar 26 2018 at 18:39):from an API perspective there will eventually be something like ged_exec() that is called by some shell environment
Sean (Mar 26 2018 at 18:40):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
Sean (Mar 26 2018 at 18:41):however, it could just as well use ged_exec() to invoke subcommands too, and be fully agnostic of Tcl
Sean (Mar 26 2018 at 18:43):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
Peter Pronai (Mar 26 2018 at 18:51):@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 -execs 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.
Sean (Mar 26 2018 at 18:53):possibly, we definitely don't want librt to know about Tcl directly
Sean (Mar 26 2018 at 18:53):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
Sean (Mar 26 2018 at 18:54):we probably should remain as aligned as possible with 'find' in case we ever need to re-do our implementation
Sean (Mar 26 2018 at 18:55):so then the question is whether libged is doing the exec parsing/invoking or whether librt is doing it
Peter Pronai (Mar 26 2018 at 18:58):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)
Sean (Mar 26 2018 at 18:59):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"
Sean (Mar 26 2018 at 19:00):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)
Sean (Mar 26 2018 at 19:01):the command-line parsing of find/search is quite intricate, so separating them is not exactly easy or desirable
Peter Pronai (Mar 26 2018 at 19:05):Is parsing dependent on any context? Couldn't it be cut out into an external routine?
Sean (Mar 26 2018 at 19:06):find's syntax is stateful based on previous arguments and expressions
Peter Pronai (Mar 26 2018 at 19:07):But AFAIK not on anything external, so it won't treat something differently if eg. there is a file with the same name.
Sean (Mar 26 2018 at 19:07):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 \;
Peter Pronai (Mar 26 2018 at 19:09):Sooo, is cutting out parsing a bad idea?
Sean (Mar 26 2018 at 19:10):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)
Sean (Mar 26 2018 at 19:11):then it can be ged_exec's problem to utilize the Tcl interpreter or not
Peter Pronai (Mar 26 2018 at 19:17):I think that sounds good. Can't really think of anything better.
Sean (Mar 26 2018 at 19:17):still won't mean it's easy, but that's why this is a gsoc project ;)
Peter Pronai (Mar 26 2018 at 19:18):that's why it's fun too :D
should we talk milestones then?
Sean (Mar 26 2018 at 19:21):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
Peter Pronai (Mar 26 2018 at 19:24):(I guess I was thinking of deliverables then? anyways)
Can I use TTD? Should I commit failing tests?
Sean (Mar 26 2018 at 19:25):TDD is great
Peter Pronai (Mar 26 2018 at 19:25):s/TTD/TDD/ doh
Peter Pronai (Mar 26 2018 at 19:32):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.
Sean (Mar 26 2018 at 19:33):not following, what do you mean?
Sean (Mar 26 2018 at 19:34):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
Sean (Mar 26 2018 at 19:35):whether that minimum makes sense or not, wouldn't know without seeing a specific api proposed
Sean (Mar 26 2018 at 19:35):or examples how it gets used like some test cases
Peter Pronai (Mar 26 2018 at 19:38):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.
Peter Pronai (Mar 26 2018 at 19:54):Ohhhhhh. Wait. Nevermind. The callback is per-db_search call, not per-exec-option. Yeah, that makes more sense.
Peter Pronai (Mar 26 2018 at 19:55):So the translation happens inside the callback.
Peter Pronai (Mar 26 2018 at 19:55):NOT inside ged_search or cmd_search
Peter Pronai (Mar 26 2018 at 19:57):doh #2
Sean (Mar 26 2018 at 20:48):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.
Peter Pronai (Mar 26 2018 at 23:49):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
Sean (Mar 27 2018 at 01:46):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
Jaipal Singh (Mar 27 2018 at 01:47):Hey @Sean ! I've submitted the draft, let me know what you think? :)
Peter Pronai (Mar 27 2018 at 01:49):Thanks for the feedback @Sean ! I'll look into the bugs in a sec.
Peter Pronai (Mar 27 2018 at 15:09):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.
Peter Pronai (Mar 27 2018 at 15:12):ah, nvm, gotta fix a few build errors first
Daniel Rossberg (Mar 27 2018 at 15:24):@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.
Peter Pronai (Mar 27 2018 at 15:25):Thanks, I wasn't sure if that also had the same deadline. I guess I'll take it slower then.
Shubham Rathore (Mar 27 2018 at 17:54):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 !
Jaipal Singh (Mar 27 2018 at 18:15):Sure thing @Shubham Rathore I'll submit a couple of patches soon :)
Last updated: Oct 09 2024 at 00:44 UTC