Re: [OpenSCAD] OpenSCAD / Google Summer of Code Update
On Apr 24, 2016 12:49 AM, "Marius Kintel" marius@kintel.net wrote:
Torsten and I will both participate in mentoring. We’re both in different
timezones (I’m EST/EDT, Torsten is CET), so hopefully this will be helpful
in finding each other online.
and mine is IST.
In terms of your proposal, it’s a bit ambitious. It would be wise to
spend the time before full-time coding starts to create a real project plan
based on the proposal.
This plan should be much more clear what should be done, how to break
down work into components, as well as what kind of support or work you need
from others.
okay, I will try to do that.
This is probably best to discuss in real-time on IRC.
We will help you with the plan, but exactly how this is done really
depends on your skill level and comfort with both C++, Qt and OpenSCAD.
Could give us a general outline of what you think your work schedule will
look like in the coming weeks (e.g. morning vs. evening), so we have an
idea when you’ll be on IRC.
Just for these three days I will be busy in MSTs( Still will be available
to reply ) and for rest of time I will be free preparing for final exams
and so, I will be always available on email (as I mainly check for new
mails hourly ) and you can also message on openscad irc channel as I also
check for discussion there minimum 1 time a day and I will also be
available on IRC regularly from 27 april from period between 8pm to 11pm
IST. You can also contact me on hangout and WhatsApp.
Feel free to reach out, both here and on IRC.
I’m sure other people will engage in discussions as well :)
Thanks and Please evaluate me regularly even in bonding period and provide
feedback.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
" There are things and there are pointers to the things. "
Dear mentors, before proceeding further with much enthusiasm and
regulated ambition, I would like to put something to rest, once and
for all (pardon the dramatic touch to my words, its nothing but
excitement in disguise). It has been bugging me a bit. Earlier it was
a little odd but now it is starting to fringe onto the mystical. So I
am asking again, the below mentioned pull requests have neither been
accepted (which is perfectly fine) nor have they been rejected. My
earlier queries about this were also met with silence of sorts. I
would really like if you could offer some reasoning for this.
https://github.com/openscad/openscad/pull/1618
https://github.com/openscad/openscad/pull/1613
I would also like to discuss the order of our discussions i.e. should
they be milestone oriented(weekly) or based on each feature I proposed
as we go along? And I will start studying accordingly.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"Words are our most inexhaustible source of magic.
Capable of both inflicting injury and remedying it."
On Apr 25, 2016, at 08:42 AM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
[…]the below mentioned pull requests have neither been
accepted (which is perfectly fine) nor have they been rejected.
https://github.com/openscad/openscad/pull/1618
https://github.com/openscad/openscad/pull/1613
I don’t have much to say about those PRs. I belive they’re implemented cleanly enough, so the question is what problem they really solve and what issues they introduce. Perhaps some of the more heavy users of these features (animation and export to various file formats) could chip in?
In any case, let’s move the details into discussions per issue.
I would also like to discuss the order of our discussions i.e. should
they be milestone oriented(weekly) or based on each feature I proposed
as we go along? And I will start studying accordingly.
I think we should split the proposal into much smaller parts, to avoid starting on something big and never finishing it. This has more to do with workflow than with the proposal though, but it’s good to keep in mind.
The overall project should be milestone oriented, and I expect there to be only a few milestones, but each milestone should ideally consist of a large number of small features which could be committed or merged separately.
Earlier, students have attempted to write a project plan for the summer, specifying what should be done each week. While this is a good exercise, it will always be wrong, often by 200% or more. Such estimates are just an indicator of complexity. The main guide should be a more or less prioritized list of what should be done, and dependencies between tasks.
Keep in mind that every time you issue a pull request, there is a lot of work that needs to be done on our side to validate use-cases, think about corner cases, looking for broken workflows, multi-platform testing, documentation, testing, asking for community input etc. The better we can structure this process, the easier it will be to accept pull requests rapidly.
Also, having multiple pull requests open at the same time is normal. This can be a bit stressful in terms of how to manage source code, but it’s a very common workflow.
Kind Regards,
-Marius
I have started with process of converting my proposal into plan and
started with first milestone in my project i.e. related to "Option to
Specify input widget" .
I have made this doc for writing everything related to what will be
decided related to project plan. At present, It contain what I have
thought of first milestone. Please, review and suggest.
https://docs.google.com/document/d/1aApCk8EhMfRhIVowKLpZG1hpHHiQJxtYKwW_K5h4H4A/edit?usp=sharing
On 25 April 2016 at 20:53, Marius Kintel marius@kintel.net wrote:
On Apr 25, 2016, at 08:42 AM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
[…]the below mentioned pull requests have neither been
accepted (which is perfectly fine) nor have they been rejected.
https://github.com/openscad/openscad/pull/1618
https://github.com/openscad/openscad/pull/1613
I don’t have much to say about those PRs. I belive they’re implemented cleanly enough, so the question is what problem they really solve and what issues they introduce. Perhaps some of the more heavy users of these features (animation and export to various file formats) could chip in?
In any case, let’s move the details into discussions per issue.
I would also like to discuss the order of our discussions i.e. should
they be milestone oriented(weekly) or based on each feature I proposed
as we go along? And I will start studying accordingly.
I think we should split the proposal into much smaller parts, to avoid starting on something big and never finishing it. This has more to do with workflow than with the proposal though, but it’s good to keep in mind.
The overall project should be milestone oriented, and I expect there to be only a few milestones, but each milestone should ideally consist of a large number of small features which could be committed or merged separately.
Earlier, students have attempted to write a project plan for the summer, specifying what should be done each week. While this is a good exercise, it will always be wrong, often by 200% or more. Such estimates are just an indicator of complexity. The main guide should be a more or less prioritized list of what should be done, and dependencies between tasks.
Keep in mind that every time you issue a pull request, there is a lot of work that needs to be done on our side to validate use-cases, think about corner cases, looking for broken workflows, multi-platform testing, documentation, testing, asking for community input etc. The better we can structure this process, the easier it will be to accept pull requests rapidly.
Also, having multiple pull requests open at the same time is normal. This can be a bit stressful in terms of how to manage source code, but it’s a very common workflow.
Kind Regards,
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
After discussion regarding project plan. I have given allot of thought
to it and made following flow chart given in the doc.
https://docs.google.com/document/d/1aApCk8EhMfRhIVowKLpZG1hpHHiQJxtYKwW_K5h4H4A/edit?usp=sharing
I have thought of making back end for parameterization completely
separate from the parser (or code) for the original openscad language
(i.e separate parser for the parameterization ) unlike as in
meta-model branch. By making separate parser, we can have more than
one backend parser for parsing the parameter (basically as plug-in).
The parser could populate the parameter data structure with all the
necessary details and we can use that to GUI.
To start with data structure to store the information regarding the
parameters, I would like to know is their anything like scope of
variable in openscad language and If yes then what are the different
scope that a variable can be under.
Hey,
Thanks for the diagram - it makes it more clear what you’re thinking.
I think it’s a bit of a mistake to separate the parameter parsing from the main parser. Mostly because this may be a lot of work which would later have to be redone as they would share a lot of logic.
I quickly drew a diagram showing my understanding of what we talked about (see attachment).
Note that I would suggest starting with the parameter description C++ data structure and UI renderer. This means that you can discover challenges and opportunities related to the UI end of things before committing to a particular syntax for parsing.
This are just suggestions for input.
On May 1, 2016, at 05:23 AM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
To start with data structure to store the information regarding the
parameters, I would like to know is their anything like scope of
variable in openscad language and If yes then what are the different
scope that a variable can be under.
There are multiple different scopes for variables (global scope, local scope, module scope, file scope). It should be the responsibility of the parser to extract the info about scopes, making the parameter extraction a simple AST traversal operation.
-Marius
On May 2, 2016 3:42 AM, "Marius Kintel" marius@kintel.net wrote:
Hey,
Thanks for the diagram - it makes it more clear what you’re thinking.
I think it’s a bit of a mistake to separate the parameter parsing from
the main parser. Mostly because this may be a lot of work which would later
have to be redone as they would share a lot of logic.
I thought of making separate parser for parsing parameters because nodes
related to parameters would not be of any use in AST of FileModule. and we
can keep the two separate
as FileModule is futher evaluted for making the geometric model and
parameter related nodes will be used in making input widgets. As, there
functionality differ so, I thought it would be better to keep both logic
and data for both ( parameter related data and data related to construction
of geometric model ) seperate.
Yes, It would increase compilation time of scad program a little and some
work have to be redone but I would decrease time for extracting parameters
as AST constructed for parameter will be small one.
This was all in mind for thinking to make separate parser for parameter
I quickly drew a diagram showing my understanding of what we talked about
(see attachment).
Note that I would suggest starting with the parameter description C++
data structure and UI renderer. This means that you can discover challenges
and opportunities related to the UI end of things before committing to a
particular syntax for parsing.
This are just suggestions for input.
Yes, it's good and would be helpful for setting milestones and making
design plan
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
" There are things and there are pointers to the things. "
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
" There are things and there are pointers to the things. "
On May 2, 2016, at 07:47 AM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
I thought of making separate parser for parsing parameters because nodes related to parameters would not be of any use in AST of FileModule. and we can keep the two separate
as FileModule is futher evaluted for making the geometric model and parameter related nodes will be used in making input widgets. As, there functionality differ so, I thought it would be better to keep both logic and data for both ( parameter related data and data related to construction of geometric model ) seperate.
OK, ldLet’s keep that discussion open.
This is also a good indicator that the parser work belongs to the 3rd milestone, when we will know a lot more about what we’re building.
-Marius
Hey, I just want to ask you have added evaluator as the part of the project
(milestone 2) in the flowchart. What need to be done regarding that?
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
" There are things and there are pointers to the things. "
On May 2, 2016, at 13:54 PM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
Hey, I just want to ask you have added evaluator as the part of the project (milestone 2) in the flowchart. What need to be done regarding that?
We need a way of making the values from the customizer available for rendering. I’m not sure how teepee solved that in his prototype branch, but this could be part of the evaluator (the component which transforms the AST to a CSG Tree).
Alternatively, we could modify the AST directly, by injecting the values back into the AST. I’m not sure what the best solution would be. It might be beneficial to app design to keep the AST read-only for subsequent processes, and thus merge customizer values during evaluation, but it’s a bit early to say.
FYI: MakerBot Customizer, simply re-runs the entire application with the values appended to the end of the .scad code. That could be an extreme quick&dirty solution which I wouldn’t recommend.
-Marius