Managing libraries and modules in complex projects

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Managing libraries and modules in complex projects

alexgibson

Hi all,

 

Does anyone have a killer file structure for keeping track of OpenSCAD files in a complex project with multiple component parts, sub-assemblies, imported libraries of vitamins and input parameters?

 

I build 3D printers, and have now built up many libraries of component parts.

 

Each of my printers is fully parametric – there’s no arbitrary measurement anywhere.

 

Each can be heavily customised, from a ‘global parameters’ openscad file.

 

I have tended to have a single OpenSCAD file for each major sub-assembly of the machine – say the case, the X carriage, etc.  Within each of these files may be many modules, and there may be some includes for ‘generic components’ such as bearings, etc, that I keep in a central folder separate from my own modules.  

 

However file sizes are often over 3000 lines, and version control is getting to be a pain, as I have many different versions of the same file, but with only one component amended.

 

What I want to do is make the customisations I’ve made for each customer available as a growing library of optional files.

 

I am considering breaking out each individual part as its own OpenSCAD file, and having the sub-assemblies and final assembly all as separate OpenSCAD files.

 

I am generally using the OpenSCAD text editor but happy to consider other (Windows) editors especially if capable of diff functions.

 

Well thought through ideas very welcome!

 

Cheers

 

 

Alex Gibson

 

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

 

admg consulting

 

edumaker limited

 

·         Project management

·         Operations & Process improvement

·         3D Printing

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

lostapathy
I've been wrestling with this as well, and I think there's actually a few separate issues wrapped up here.

1)  We need a package manager to simplify/encourage reuse of not only one's own code, but to allow community library to arise and evolve in a decentralized way.  Versioning is a key factor in this, so that we can make break backwards compatibility without breaking older code.

2)  We need more published information on best-practices.  In a perfect world, we'd build linters and other QA tools, similar to Rubocop, to help a user identify anti-patterns and improve their code.  At a modeling level, we need guidelines on how to orient and place parts generated by library code - getting that right can make a world of difference in how reusable a library is.  Having all this in place will help libraries "grow up" and become more useful to the ecosystem.

3)  We need to publish more information on designing complex assemblies in terms of file organization, module composition, and tricks to manage rendering complexity.  It seems like everyone doing complex things with OpenSCAD is doing it their own way, and had to figure it out on their own, and it's a shame we don't share that better.

I've been working on a package manager and a couple initial libraries to release with it.  It's all working great, but I need to finish up the documentation so I can publish it all.  Coming soon!

That exercise has me working on some guidelines for #2 as well, but it's certainly not comprehensive nor do I claim to be an expert.  I'll make sure to publish that once I get the package manager out.

As far as #3 goes, the only thing I've seen published is https://github.com/swindonmakers/snhack.github.io/wiki/OpenSCAD-for-Machine-Design Some of what they do there (and similarly, what nophead does with his automation around 3d printer design) is super cool.  At the same time, I think there is a lot of potential for making the actual modeling experience in OpenSCAD easier to manage.  I guess that's a 3rd blog post I owe.

I think there's an awful lot of untapped potential here just begging to be unlocked.

Joe

On 02/08/2018 03:38 PM, Alex Gibson wrote:

Hi all,

 

Does anyone have a killer file structure for keeping track of OpenSCAD files in a complex project with multiple component parts, sub-assemblies, imported libraries of vitamins and input parameters?

 

I build 3D printers, and have now built up many libraries of component parts.

 

Each of my printers is fully parametric – there’s no arbitrary measurement anywhere.

 

Each can be heavily customised, from a ‘global parameters’ openscad file.

 

I have tended to have a single OpenSCAD file for each major sub-assembly of the machine – say the case, the X carriage, etc.  Within each of these files may be many modules, and there may be some includes for ‘generic components’ such as bearings, etc, that I keep in a central folder separate from my own modules.  

 

However file sizes are often over 3000 lines, and version control is getting to be a pain, as I have many different versions of the same file, but with only one component amended.

 

What I want to do is make the customisations I’ve made for each customer available as a growing library of optional files.

 

I am considering breaking out each individual part as its own OpenSCAD file, and having the sub-assemblies and final assembly all as separate OpenSCAD files.

 

I am generally using the OpenSCAD text editor but happy to consider other (Windows) editors especially if capable of diff functions.

 

Well thought through ideas very welcome!

 

Cheers

 

 

Alex Gibson

 

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

 

admg consulting

 

edumaker limited

 

·         Project management

·         Operations & Process improvement

·         3D Printing

 



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

DanS
In reply to this post by alexgibson
I don't understand "killer file structure".  If you are doing multiple versions a version control system would seem the most logical bet.

There are primitive ones RCS
And sophisticated ones GIT
and ones in between CVS, SVN

If you don't want to use version control probably logically splitting things up makes sense... but if you've got thousands of lines of code, and different clients have different versions I think you are begging for version control.

I'm not using version control for OpenScad because my files are all small in comparison and don't really interact with each other...

On Thu, Feb 8, 2018 at 4:38 PM, Alex Gibson <[hidden email]> wrote:

Hi all,

 

Does anyone have a killer file structure for keeping track of OpenSCAD files in a complex project with multiple component parts, sub-assemblies, imported libraries of vitamins and input parameters?

 

I build 3D printers, and have now built up many libraries of component parts.

 

Each of my printers is fully parametric – there’s no arbitrary measurement anywhere.

 

Each can be heavily customised, from a ‘global parameters’ openscad file.

 

I have tended to have a single OpenSCAD file for each major sub-assembly of the machine – say the case, the X carriage, etc.  Within each of these files may be many modules, and there may be some includes for ‘generic components’ such as bearings, etc, that I keep in a central folder separate from my own modules.  

 

However file sizes are often over 3000 lines, and version control is getting to be a pain, as I have many different versions of the same file, but with only one component amended.

 

What I want to do is make the customisations I’ve made for each customer available as a growing library of optional files.

 

I am considering breaking out each individual part as its own OpenSCAD file, and having the sub-assemblies and final assembly all as separate OpenSCAD files.

 

I am generally using the OpenSCAD text editor but happy to consider other (Windows) editors especially if capable of diff functions.

 

Well thought through ideas very welcome!

 

Cheers

 

 

Alex Gibson

 

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

 

admg consulting

 

edumaker limited

 

·         Project management

·         Operations & Process improvement

·         3D Printing

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

shadowwynd
In reply to this post by alexgibson
Here is what I use (Not an elegant system)....

*
Goal 1:  I should be able to pick up the project folder and install it on a
new machine and have everything work OK.*  
In my case, I do a lot of work between office and home, so being able to
stuff it in dropbox and it be the same in any arena is good.

1) Any file besides the MCAD libraries are always included in the project
directory or subfolder therein.
This means that I can move the master directory and know that all the
attendant files come along.

so under NameOfProject folder I might have folders named Include,
Components, Assemblies, Resources, Reference, Build Photos.

a) Include - OpenSCAD helper functions, math functions, libraries, etc.
Screw, Sweep, etc.
    Components - Nuts, bolts, screws, washers, etc.
    Assemblies - Small Assemblies of components
    Resources - fonts, bitmaps, png files, dxf files
    References - schematic diagrams, reference photos, manuals, etc.
    Build Photos - always take pictures of actual builds  
   

b)  If you are using text(), this includes making sure the .TTF is in the
folder too (say, under "Resources").  If you have to wipe the drive for some
reason odd fonts are hard to find again.

c)  Yes, this chews up disk space;  I will have a separate copy of the
assemblies and include files for each project.   Yes, disk space is
essentially free.
 This means I *know* where the libraries are located.
 This also prevents updates to master libraries from knackering a part
(depreciated feature, etc.) and prevents dependency issues.

d) Having everything in one folder tree  makes forking very easy - just
copy+paste the tree with a different name.

*Goal 2:  Ability to backtrack*

2)  The current, most recent version of a file has the plain descriptive
name (e.g. WidgetPart.scad).  Every time I work on a file, I "Save As" the
date and the name of part before doing any work.  I thus have "2017-02-03 -
WidgetPart.scad",   "2018-01-30 - WidgetPart.scad", & "WidgetPart.scad") in
the same folder.  Some days I am not as brilliant as I imagine myself to
be.... and change a working part until it doesn't work anymore.

a)  In each file I make,  I have a /*   */   Multiline comment.
/*

        Purpose:     Blah Blah Blah (one line only)

        Author:       John Doe

        Revision Log  (one line only:  
           2018-02-03 - Adjusted the microfleems by two subradiants
           2018-01-30 - Fixed bug in sprocket  (was +2, changed to *2)
           2017-02-03 - First Functional Version  

       Documention (as needed):

       Sample Usage (very brief):

*/

b) I also try to modularize code if I have to use it more than three times,
I comment all my variables, I clearly designate modules vs. main code, I
drop comments every few lines on what a piece is doing, etc. - basic stuff.




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

alexgibson
In reply to this post by lostapathy

Thanks Joe, I think we’re on the same wavelength and I will check out the Swindon Makers method.  They are near me!

 

Cheers

 

Alex Gibson

 

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

 

admg consulting

 

edumaker limited

 

·         Project management

·         Operations & Process improvement

·         3D Printing

 

From: Discuss [mailto:[hidden email]] On Behalf Of Joe Francis
Sent: 08 February 2018 23:03
To: [hidden email]
Subject: Re: [OpenSCAD] Managing libraries and modules in complex projects

 

I've been wrestling with this as well, and I think there's actually a few separate issues wrapped up here.

1)  We need a package manager to simplify/encourage reuse of not only one's own code, but to allow community library to arise and evolve in a decentralized way.  Versioning is a key factor in this, so that we can make break backwards compatibility without breaking older code.

2)  We need more published information on best-practices.  In a perfect world, we'd build linters and other QA tools, similar to Rubocop, to help a user identify anti-patterns and improve their code.  At a modeling level, we need guidelines on how to orient and place parts generated by library code - getting that right can make a world of difference in how reusable a library is.  Having all this in place will help libraries "grow up" and become more useful to the ecosystem.

3)  We need to publish more information on designing complex assemblies in terms of file organization, module composition, and tricks to manage rendering complexity.  It seems like everyone doing complex things with OpenSCAD is doing it their own way, and had to figure it out on their own, and it's a shame we don't share that better.

I've been working on a package manager and a couple initial libraries to release with it.  It's all working great, but I need to finish up the documentation so I can publish it all.  Coming soon!

That exercise has me working on some guidelines for #2 as well, but it's certainly not comprehensive nor do I claim to be an expert.  I'll make sure to publish that once I get the package manager out.

As far as #3 goes, the only thing I've seen published is https://github.com/swindonmakers/snhack.github.io/wiki/OpenSCAD-for-Machine-Design Some of what they do there (and similarly, what nophead does with his automation around 3d printer design) is super cool.  At the same time, I think there is a lot of potential for making the actual modeling experience in OpenSCAD easier to manage.  I guess that's a 3rd blog post I owe.

I think there's an awful lot of untapped potential here just begging to be unlocked.

Joe

On 02/08/2018 03:38 PM, Alex Gibson wrote:

Hi all,

 

Does anyone have a killer file structure for keeping track of OpenSCAD files in a complex project with multiple component parts, sub-assemblies, imported libraries of vitamins and input parameters?

 

I build 3D printers, and have now built up many libraries of component parts.

 

Each of my printers is fully parametric – there’s no arbitrary measurement anywhere.

 

Each can be heavily customised, from a ‘global parameters’ openscad file.

 

I have tended to have a single OpenSCAD file for each major sub-assembly of the machine – say the case, the X carriage, etc.  Within each of these files may be many modules, and there may be some includes for ‘generic components’ such as bearings, etc, that I keep in a central folder separate from my own modules.  

 

However file sizes are often over 3000 lines, and version control is getting to be a pain, as I have many different versions of the same file, but with only one component amended.

 

What I want to do is make the customisations I’ve made for each customer available as a growing library of optional files.

 

I am considering breaking out each individual part as its own OpenSCAD file, and having the sub-assemblies and final assembly all as separate OpenSCAD files.

 

I am generally using the OpenSCAD text editor but happy to consider other (Windows) editors especially if capable of diff functions.

 

Well thought through ideas very welcome!

 

Cheers

 

 

Alex Gibson

 

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

 

admg consulting

 

edumaker limited

 

·         Project management

·         Operations & Process improvement

·         3D Printing

 




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

 


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

Troberg
In reply to this post by alexgibson
I have no real solution, but as far as version control goes, it really helps
a lot to have one version only, the current version. If a change breaks old
implementations, I refactor the old implementations, och provide two
different versions (usuallt only most recent version, and an simple module
that calls the recent version, but makes some backwards compatibility fix).

It's a little bit more work, but, on the other hand, a fix fixes alla
projects. For example, I found a bug in my code for generating a chain,
fixed it, and suddenly, all old projects looked better as well.

Apart from that, group by part type/function type.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

lostapathy
Troberg wrote

> I have no real solution, but as far as version control goes, it really
> helps
> a lot to have one version only, the current version. If a change breaks
> old
> implementations, I refactor the old implementations, och provide two
> different versions (usuallt only most recent version, and an simple module
> that calls the recent version, but makes some backwards compatibility
> fix).
>
> It's a little bit more work, but, on the other hand, a fix fixes alla
> projects. For example, I found a bug in my code for generating a chain,
> fixed it, and suddenly, all old projects looked better as well.

This works ok when you have a few projects, or small projects, but I'm not
sure it scales well when you have big projects, or lots of projects.  It
very quickly becomes problematic to go back and update every project in your
"back catalog" to reconcile it with every breaking change, especially when
you don't expect to need to work on the project again.

The trouble comes after two or three years when you need to print a
replacement part with a small tweak, so then you have to update that
long-shelved code to all the library changes that happened along the way.
That's why I am building a versioning package manager - so you can declare
what version of a library your project was built against, and when you come
back it'll automatically build the exact same way.  And when you're ready to
upgrade that dependency, you can make that upgrade in steps (or just go part
way) to minimize the impact at each step.  

The "easy answer" to that problem is just to store the library code with
your own code for every project, but that doesn't really help you perform
that gradual upgrade either.  There's a reason programming ecosystems like
ruby, python, node, etc all have version-managed package managers.  OpenSCAD
needs one as well.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

Troberg
> This works ok when you have a few projects, or small projects, but I'm not
sure it scales well when you have big projects, or lots of projects.  It
very quickly becomes problematic to go back and update every project in your
"back catalog" to reconcile it with every breaking change, especially when
you don't expect to need to work on the project again.

Well, I have large projects (typically around 2-4000 lines, with several
parts files and helper files of similar size), and, to date, maybe 50
projects.

The trick, just in ordinary software development, is not never break
backwards compatibility if it can be avoided. I fix bugs. I add detail, for
example, adding mounting screws to my slide lock component. I add features
that don't break behaviour, for example, each component adds echoes to a
part list (with price, part number and weight) and a work task list when
added, transparently from the client module. However, I seldom change how
things work. If I do, I either add a parameter controlling the behaviour
(which makes it easy to write a small script which refactors old code), or
create a wrapper function, so old stuff can keep the old behaviour. I almost
always refactor using scripts, so I can bulk update with little or no manual
work.

The trick is to design like this from the start. I'm a developer, and I
developed a single system for many customers, and I did it by having a
stable core where I avoided interface changes at all costs, and then built
and adapted on that, but always had a single code base for all customers, I
just unlocked different bits.

It's more of a mindset than a methology. You need to think in platforms,
frameworks and components first, before you do something.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

jessaskey
In reply to this post by shadowwynd
This is very similar to what I use.... then I get a static snapshot of dependent libraries for each project.... I don't need to worry about breaking changes etc. However, if a library needs updated on one or more project, you have to just work through it... update the project library and deal with issues from the update. Since I keep all my projects in both Dropbox and SVN (SVN only via one computer - main computer), then I can start refactoring there... if things get too deep or I run into a deal breaker on the update, then I simply revert my library back to the previous project version and Im back to where I was.

I feel that while this may seem archaic in comparison to packages, it is certainly flexible, allows minimal work stoppage and supports a workflow to upgrade libraries in a planned manner.

Shadowwynd.... thanks for typing all of that out, I don't think it is that inelegant personally. 😊

-----Original Message-----
From: Discuss [mailto:[hidden email]] On Behalf Of shadowwynd
Sent: Thursday, February 8, 2018 8:56 PM
To: [hidden email]
Subject: Re: [OpenSCAD] Managing libraries and modules in complex projects

Here is what I use (Not an elegant system)....

*
Goal 1:  I should be able to pick up the project folder and install it on a new machine and have everything work OK.* In my case, I do a lot of work between office and home, so being able to stuff it in dropbox and it be the same in any arena is good.

1) Any file besides the MCAD libraries are always included in the project directory or subfolder therein.
This means that I can move the master directory and know that all the attendant files come along.

so under NameOfProject folder I might have folders named Include, Components, Assemblies, Resources, Reference, Build Photos.

a) Include - OpenSCAD helper functions, math functions, libraries, etc.
Screw, Sweep, etc.
    Components - Nuts, bolts, screws, washers, etc.
    Assemblies - Small Assemblies of components
    Resources - fonts, bitmaps, png files, dxf files
    References - schematic diagrams, reference photos, manuals, etc.
    Build Photos - always take pictures of actual builds  
   

b)  If you are using text(), this includes making sure the .TTF is in the folder too (say, under "Resources").  If you have to wipe the drive for some reason odd fonts are hard to find again.

c)  Yes, this chews up disk space;  I will have a separate copy of the
assemblies and include files for each project.   Yes, disk space is
essentially free.
 This means I *know* where the libraries are located.
 This also prevents updates to master libraries from knackering a part (depreciated feature, etc.) and prevents dependency issues.

d) Having everything in one folder tree  makes forking very easy - just
copy+paste the tree with a different name.

*Goal 2:  Ability to backtrack*

2)  The current, most recent version of a file has the plain descriptive name (e.g. WidgetPart.scad).  Every time I work on a file, I "Save As" the date and the name of part before doing any work.  I thus have "2017-02-03 -
WidgetPart.scad",   "2018-01-30 - WidgetPart.scad", & "WidgetPart.scad") in
the same folder.  Some days I am not as brilliant as I imagine myself to be.... and change a working part until it doesn't work anymore.

a)  In each file I make,  I have a /*   */   Multiline comment.
/*

        Purpose:     Blah Blah Blah (one line only)

        Author:       John Doe

        Revision Log  (one line only:  
           2018-02-03 - Adjusted the microfleems by two subradiants
           2018-01-30 - Fixed bug in sprocket  (was +2, changed to *2)
           2017-02-03 - First Functional Version  

       Documention (as needed):

       Sample Usage (very brief):

*/

b) I also try to modularize code if I have to use it more than three times, I comment all my variables, I clearly designate modules vs. main code, I drop comments every few lines on what a piece is doing, etc. - basic stuff.




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

nophead
I use a source control system I wrote myself in 2001 for the company I used to work for. It stores a reference to the library version used in each version of each project. If I build a project it also generates the version of the library it was checked in with. If I check it out I can chose to update to a later library version if I want or stick with the old version. I try not to make any breaking changes but if I do then nothing breaks unless I choose to update its library version. That way I can have a single library shared between all my OpenSCAD projects without have them rot as I develop it.

All versions of anything are only two clicks away because every revision of every file is stored in an XML database that I also wrote from scratch. That was designed to live on a company server but I now stick it on my Google drive so I can use it anywhere.

No use for anybody else but the methodology is applicable. Not sure if Git submodules do the same sort of thing.

On 9 February 2018 at 18:13, Jess Askey <[hidden email]> wrote:
This is very similar to what I use.... then I get a static snapshot of dependent libraries for each project.... I don't need to worry about breaking changes etc. However, if a library needs updated on one or more project, you have to just work through it... update the project library and deal with issues from the update. Since I keep all my projects in both Dropbox and SVN (SVN only via one computer - main computer), then I can start refactoring there... if things get too deep or I run into a deal breaker on the update, then I simply revert my library back to the previous project version and Im back to where I was.

I feel that while this may seem archaic in comparison to packages, it is certainly flexible, allows minimal work stoppage and supports a workflow to upgrade libraries in a planned manner.

Shadowwynd.... thanks for typing all of that out, I don't think it is that inelegant personally. 😊

-----Original Message-----
From: Discuss [mailto:[hidden email]] On Behalf Of shadowwynd
Sent: Thursday, February 8, 2018 8:56 PM
To: [hidden email]
Subject: Re: [OpenSCAD] Managing libraries and modules in complex projects

Here is what I use (Not an elegant system)....

*
Goal 1:  I should be able to pick up the project folder and install it on a new machine and have everything work OK.* In my case, I do a lot of work between office and home, so being able to stuff it in dropbox and it be the same in any arena is good.

1) Any file besides the MCAD libraries are always included in the project directory or subfolder therein.
This means that I can move the master directory and know that all the attendant files come along.

so under NameOfProject folder I might have folders named Include, Components, Assemblies, Resources, Reference, Build Photos.

a) Include - OpenSCAD helper functions, math functions, libraries, etc.
Screw, Sweep, etc.
    Components - Nuts, bolts, screws, washers, etc.
    Assemblies - Small Assemblies of components
    Resources - fonts, bitmaps, png files, dxf files
    References - schematic diagrams, reference photos, manuals, etc.
    Build Photos - always take pictures of actual builds


b)  If you are using text(), this includes making sure the .TTF is in the folder too (say, under "Resources").  If you have to wipe the drive for some reason odd fonts are hard to find again.

c)  Yes, this chews up disk space;  I will have a separate copy of the
assemblies and include files for each project.   Yes, disk space is
essentially free.
 This means I *know* where the libraries are located.
 This also prevents updates to master libraries from knackering a part (depreciated feature, etc.) and prevents dependency issues.

d) Having everything in one folder tree  makes forking very easy - just
copy+paste the tree with a different name.

*Goal 2:  Ability to backtrack*

2)  The current, most recent version of a file has the plain descriptive name (e.g. WidgetPart.scad).  Every time I work on a file, I "Save As" the date and the name of part before doing any work.  I thus have "2017-02-03 -
WidgetPart.scad",   "2018-01-30 - WidgetPart.scad", & "WidgetPart.scad") in
the same folder.  Some days I am not as brilliant as I imagine myself to be.... and change a working part until it doesn't work anymore.

a)  In each file I make,  I have a /*   */   Multiline comment.
/*

        Purpose:     Blah Blah Blah (one line only)

        Author:       John Doe

        Revision Log  (one line only:
           2018-02-03 - Adjusted the microfleems by two subradiants
           2018-01-30 - Fixed bug in sprocket  (was +2, changed to *2)
           2017-02-03 - First Functional Version

       Documention (as needed):

       Sample Usage (very brief):

*/

b) I also try to modularize code if I have to use it more than three times, I comment all my variables, I clearly designate modules vs. main code, I drop comments every few lines on what a piece is doing, etc. - basic stuff.




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Managing libraries and modules in complex projects

Chow Loong Jin
In reply to this post by alexgibson
Hi,

I've recently adopted a sort of nested dictionary data model descending from a
single global object for my printer:
https://github.com/hyperair/deltabob/blob/vslot-upgrade/configuration/delta.scad

It sort of works and ends up cleaner in some ways in that modules no longer
depend on global variables and do not need to have super-long argument lists,
e.g. https://github.com/hyperair/deltabob/blob/vslot-upgrade/effector.scad#L224

But it also ends up with massive amounts of boilerplate to handle option
extraction:
https://github.com/hyperair/deltabob/blob/vslot-upgrade/lib/effector.scad

Perhaps I could write a script to autogenerate the boilerplate bits.

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

signature.asc (817 bytes) Download Attachment