MCAD

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

MCAD

Tim Schmidt
It's been suggested to me that the MCAD OpenSCAD library
(http://reprap.org/wiki/MCAD) seek to include itself in the OpenSCAD
distribution, as a standard library of functions available from the
/usr/local/share/openscad/libraries folder or it's platform
equivalent.

I'm willing to work toward that end.

With that in mind, I have some questions:

- is this even desirable?  I feel that the case for including more
complex 2D and 3D shapes is strong, but what about stepper motor
models, the gridbeam library?  If there are to be limits, where?

- MCAD currently has a (partially) functional python testing
framework, thoughts?

--tim

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

kintel
Administrator
On Jan 17, 2011, at 14:37 PM, Tim Schmidt wrote:

> - is this even desirable?

Yes!

A long time ago I started on preparing Catarina's shapes library for inclusion in OpenSCAD, but realized that we should make it more structured, have standardized module parameter convensions, and more primitives, so it lost momentum.
Also, it would be cool if the libraries could be updated without updating OpenSCAD from some library distribution server with a up-to-date check in OpenSCAD.

In addition, I would like to clarify and make explicit that use of these libraries won't make people's OpenSCAD models GPL, but that changes to library code itself is considered GPL.

> - MCAD currently has a (partially) functional python testing
> framework, thoughts?
>
This is good. I'm working on a test framework for OpenSCAD itself, primarily for catching regressions. I've got some cmd-line utilities which do parsing, CSG evaluation  and partially working CSG rendering to bitmaps (all of these will run a lot faster than just a cmd-line OpenSCAD), which might be useful for light-weight testing to catch compile errors and the like.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Giles Bathgate-2
On 17 January 2011 14:12, Marius Kintel <[hidden email]> wrote:

> A long time ago I started on preparing Catarina's shapes library for inclusion in OpenSCAD, but realized that we should make it more structured, have standardized module parameter convensions, and more primitives, so it lost momentum.

Ironically MCAD dropped my regular_shapes.scad
(http://www.gilesbathgate.com/openscad/regular_shapes-0.1.scad) in
favour or Catarina's shapes despite mine being a bit more structured
and having standardised module parameter conventions. The reason for
this is because I don't want to licence anything under LGPL unless
absolutely necessary.  I did mention to Tim that I would dual licence
the library, but I never got round to it. Of course I would prefer if
MCAD went the GPL route, its not like there is an existing propriety
library that MCAD is or would be in competition with. (as pointed out
the main reason why gnu Libc is licensed under LGPL
http://www.gnu.org/licenses/why-not-lgpl.html)

Anyway. Rant over. Tim if you want me to dual licence
regular_shapes.scad nag me about it. ;)

Regards

Giles

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Tim Schmidt
On Mon, Jan 17, 2011 at 9:26 AM, Giles Bathgate
<[hidden email]> wrote:
> Anyway. Rant over. Tim if you want me to dual licence
> regular_shapes.scad nag me about it. ;)

I'd definitely like to include regular_shapes.scad, and your
metric_fasteners.scad.  If you're willing to dual-license both, I'd
greatly appreciate it.

--tim

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Tim Schmidt
In reply to this post by kintel
On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:
> Yes!

OK.

> A long time ago I started on preparing Catarina's shapes library for inclusion in OpenSCAD, but realized that we should make it more structured, have standardized module parameter convensions, and more primitives, so it lost momentum.

Right.  Any complaints with the current state of MCAD?  There's much
that needs doing, but now is the time to get large reordering done.

> Also, it would be cool if the libraries could be updated without updating OpenSCAD from some library distribution server with a up-to-date check in OpenSCAD.

Agreed.  Would you prefer to transition MCAD into the existing
OpenSCAD version control repo, or that MCAD be maintained on github as
it is currently?

> In addition, I would like to clarify and make explicit that use of these libraries won't make people's OpenSCAD models GPL, but that changes to library code itself is considered GPL.

MCAD is currently licensed under the LGPL v2.1.  I would expect this
to remain the situation even while shipping alongside OpenSCAD.  No?

>> - MCAD currently has a (partially) functional python testing
>> framework, thoughts?
>>
> This is good. I'm working on a test framework for OpenSCAD itself, primarily for catching regressions. I've got some cmd-line utilities which do parsing, CSG evaluation  and partially working CSG rendering to bitmaps (all of these will run a lot faster than just a cmd-line OpenSCAD), which might be useful for light-weight testing to catch compile errors and the like.

Excellent.  I'm very interested in seeing what you have working.

--tim

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Giles Bathgate-2
In reply to this post by Tim Schmidt
On 17 January 2011 14:36, Tim Schmidt <[hidden email]> wrote:
> I'd definitely like to include regular_shapes.scad, and your
> metric_fasteners.scad.  If you're willing to dual-license both, I'd
> greatly appreciate it.

These are now available at:
http://gilesbathgate.com/openscad/regular_shapes-0.2.scad
and:
http://gilesbathgate.com/openscad/metric_fastners-0.2.scad

Regards

Giles

Reply | Threaded
Open this post in threaded view
|

Import Library UI (was Re: MCAD)

clothbot
In reply to this post by Tim Schmidt
W.r.t. implementing on the UI side, I'd like to see something similar to the Arduino Sketch - Import Library approach.

- Have a library search path defined in OpenSCAD Preferences.
- Scan the library search path for .scad files and list them in a Libraries menu.
- When selected from the pulldown, insert a "use </path/to/library/file.scad>" at the cursor location.

...or to get even fancier, make a simple dockable tree widget, scan for and populate with library branches, then scan libraries for "function" and "module" declarations to build sub-branches in the widget.  Allow the (ab)user to select from the tree to instantiate directly in the code.

Thoughts?

Andrew.

On 2011-01-17, at 10:05 AM, Tim Schmidt wrote:

On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:
Yes!

OK.

A long time ago I started on preparing Catarina's shapes library for inclusion in OpenSCAD, but realized that we should make it more structured, have standardized module parameter convensions, and more primitives, so it lost momentum.

Right.  Any complaints with the current state of MCAD?  There's much
that needs doing, but now is the time to get large reordering done.

Also, it would be cool if the libraries could be updated without updating OpenSCAD from some library distribution server with a up-to-date check in OpenSCAD.

Agreed.  Would you prefer to transition MCAD into the existing
OpenSCAD version control repo, or that MCAD be maintained on github as
it is currently?

In addition, I would like to clarify and make explicit that use of these libraries won't make people's OpenSCAD models GPL, but that changes to library code itself is considered GPL.

MCAD is currently licensed under the LGPL v2.1.  I would expect this
to remain the situation even while shipping alongside OpenSCAD.  No?

- MCAD currently has a (partially) functional python testing
framework, thoughts?

This is good. I'm working on a test framework for OpenSCAD itself, primarily for catching regressions. I've got some cmd-line utilities which do parsing, CSG evaluation  and partially working CSG rendering to bitmaps (all of these will run a lot faster than just a cmd-line OpenSCAD), which might be useful for light-weight testing to catch compile errors and the like.

Excellent.  I'm very interested in seeing what you have working.

--tim
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

--

Makerbot Number Nine... #9... 0x09... 0o11... 0b1001... 
http://clothbot.com/wiki/MakerBotNumberNine



Reply | Threaded
Open this post in threaded view
|

Re: MCAD

kintel
Administrator
In reply to this post by Tim Schmidt
On Jan 17, 2011, at 16:05 PM, Tim Schmidt wrote:

> Right.  Any complaints with the current state of MCAD?  There's much
> that needs doing, but now is the time to get large reordering done.

I haven't looked at it in detail.
My primary concern would be to maintain compatibility once it officially ships with OpenSCAD, so people can trust their models to keep working.

> MCAD is currently licensed under the LGPL v2.1.  I would expect this
> to remain the situation even while shipping alongside OpenSCAD.  No?

Good. I didn't follow this in detail - I've seen misc. various licenses used for misc. forks of MCAD and was confused.
I think LGPL is good for OpenSCAD.

> Agreed.  Would you prefer to transition MCAD into the existing
> OpenSCAD version control repo, or that MCAD be maintained on github as
> it is currently?

I don't have any strong preferences.
We need a distribution server, someone responsible for updating MCAD and to ship the MCAD library and URL to the server with OpenSCAD.
The distribution server could be under the OpenSCAD domain with write access given the MCAD maintainer.

> Excellent.  I'm very interested in seeing what you have working.
>
For the time being, check out the visitor branch on github: https://github.com/openscad/openscad

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Import Library UI (was Re: MCAD)

andy@kirbyand.co.uk
In reply to this post by clothbot
I guess it would be nice to have something like sweep and revolve
functions too, to complement the extrude function.

If you sweep a circle over a helical path you get a spring.

If you revolve a circle you get a torus or doughnut.

I guess this is where someone tells me it is already done and I am blind.

Grin


On 17/01/11 15:23, Andrew Plumb wrote:

> W.r.t. implementing on the UI side, I'd like to see something similar to the Arduino Sketch - Import Library approach.
>
> - Have a library search path defined in OpenSCAD Preferences.
> - Scan the library search path for .scad files and list them in a Libraries menu.
> - When selected from the pulldown, insert a "use </path/to/library/file.scad>" at the cursor location.
>
> ...or to get even fancier, make a simple dockable tree widget, scan for and populate with library branches, then scan libraries for "function" and "module" declarations to build sub-branches in the widget.  Allow the (ab)user to select from the tree to instantiate directly in the code.
>
> Thoughts?
>
> Andrew.
>
> On 2011-01-17, at 10:05 AM, Tim Schmidt wrote:
>
>> On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:
>>> Yes!
>>
>> OK.
>>
>>> A long time ago I started on preparing Catarina's shapes library for inclusion in OpenSCAD, but realized that we should make it more structured, have standardized module parameter convensions, and more primitives, so it lost momentum.
>>
>> Right.  Any complaints with the current state of MCAD?  There's much
>> that needs doing, but now is the time to get large reordering done.
>>
>>> Also, it would be cool if the libraries could be updated without updating OpenSCAD from some library distribution server with a up-to-date check in OpenSCAD.
>>
>> Agreed.  Would you prefer to transition MCAD into the existing
>> OpenSCAD version control repo, or that MCAD be maintained on github as
>> it is currently?
>>
>>> In addition, I would like to clarify and make explicit that use of these libraries won't make people's OpenSCAD models GPL, but that changes to library code itself is considered GPL.
>>
>> MCAD is currently licensed under the LGPL v2.1.  I would expect this
>> to remain the situation even while shipping alongside OpenSCAD.  No?
>>
>>>> - MCAD currently has a (partially) functional python testing
>>>> framework, thoughts?
>>>>
>>> This is good. I'm working on a test framework for OpenSCAD itself, primarily for catching regressions. I've got some cmd-line utilities which do parsing, CSG evaluation  and partially working CSG rendering to bitmaps (all of these will run a lot faster than just a cmd-line OpenSCAD), which might be useful for light-weight testing to catch compile errors and the like.
>>
>> Excellent.  I'm very interested in seeing what you have working.
>>
>> --tim
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>
> --
>
> Makerbot Number Nine... #9... 0x09... 0o11... 0b1001...
> http://clothbot.com/wiki/MakerBotNumberNine
>
>
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Import Library UI (was Re: MCAD)

kintel
Administrator
In reply to this post by clothbot
On Jan 17, 2011, at 16:23 PM, Andrew Plumb wrote:

> ...or to get even fancier, make a simple dockable tree widget, scan for and populate with library branches, then scan libraries for "function" and "module" declarations to build sub-branches in the widget.  Allow the (ab)user to select from the tree to instantiate directly in the code.
>
I've been thinking about smth. similar also for built-in modules and functions.
Combine this with some simple docs for module parameters and it would be a significant improvement over today.
I find myself looking up the online docs or source code to remember the exact parameters for modules. I assume I'm not the only one :/

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Giles Bathgate-2
In reply to this post by kintel
On 17 January 2011 15:28, Marius Kintel <[hidden email]> wrote:
> On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:
>> Also, it would be cool if the libraries could be updated without updating OpenSCAD from some library distribution server with a up-to-date check in OpenSCAD.
> I don't have any strong preferences.
> We need a distribution server, someone responsible for updating MCAD and to ship the MCAD library and URL to the server with OpenSCAD.
> The distribution server could be under the OpenSCAD domain with write access given the MCAD maintainer.

Its all a very nice idea, but that will take some time to implement.
What I would rather see is a nightly builds of openscad to produce
windows linux and macosx binaries, you can then bundle MCAD into your
nightly builds (zip deb whatever), and keep it up to date that way.

Regards

Giles

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

kintel
Administrator
On Jan 17, 2011, at 16:43 PM, Giles Bathgate wrote:

> What I would rather see is a nightly builds of openscad to produce
> windows linux and macosx binaries, you can then bundle MCAD into your
> nightly builds (zip deb whatever), and keep it up to date that way.
>
That's a good short-term workaround.

I plan to do a 2011.01 release which represents the current state.
This could be a good time to include the MCAD library.
I would in case suggest that we include MCAD as a convenience, without guarantees for future compatibility apart from what Tim (and other contributors) decide to deal with.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Import Library UI (was Re: MCAD)

Whosawhatsis
In reply to this post by andy@kirbyand.co.uk

On Monday, January 17, 2011 at 7:30 AM, [hidden email] wrote:

...
If you revolve a circle you get a torus or doughnut.

I guess this is where someone tells me it is already done and I am blind
...
 
Rotate_extrude().

Last I checked, the sweep functionality was missing, though. It would be a nice addition. You can kinda fake it by using linear_extrude with the twist parameter, and you can get pretty close to a circular cross-section by using 2d projection to get an angled cross-section of a torus, but the way it tessellates is pretty ugly.
Reply | Threaded
Open this post in threaded view
|

Re: MCAD

tbuser
In reply to this post by kintel
On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:
This is good. I'm working on a test framework for OpenSCAD itself, primarily for catching regressions. I've got some cmd-line utilities which do parsing, CSG evaluation  and partially working CSG rendering to bitmaps (all of these will run a lot faster than just a cmd-line OpenSCAD), which might be useful for light-weight testing to catch compile errors and the like.

This makes me really happy by the way.  :)  If you need help testing anything let me know.  I've been swamped and had to put CloudSCAD on the back burner for a while, but hopefully as soon as I finish a few other projects I'm going to get back into it.

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Giles Bathgate-2
> On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:
> This is good. I'm working on a test framework for OpenSCAD itself,
> primarily for catching regressions. I've got some cmd-line utilities which
> do parsing, CSG evaluation  and partially working CSG rendering to bitmaps
> (all of these will run a lot faster than just a cmd-line OpenSCAD), which
> might be useful for light-weight testing to catch compile errors and the
> like.

BTW Marius, here are some tests I wrote for RapCAD.

http://git.rapcad.org/cgit.cgi/rapcad/tree/test

Most of them should be useful for testing OpenSCAD as well.

Regards

Giles.

Reply | Threaded
Open this post in threaded view
|

Re: MCAD (and updates)

Jonathan Marsden
In reply to this post by Tim Schmidt
On 01/17/2011 07:05 AM, Tim Schmidt wrote:

> On Mon, Jan 17, 2011 at 9:12 AM, Marius Kintel <[hidden email]> wrote:

>> Also, it would be cool if the libraries could be updated without
>> updating OpenSCAD from some library distribution server with a
>> up-to-date check in OpenSCAD.

> Agreed.  

Really?  Why design, implement, document and maintain a
unique-to-OpenSCAD update process?  Existing packaging systems for (for
example) Debian and Ubuntu will automatically update packages with a
worldwide set of package repositories already in existence, and PPAs
(and other similar mechanisms) exist for those who "need" the latest
bleeding edge packages and can't wait for the next official update.

I'd suggest that, at least in the package-based Linux distribution
world, MCAD be packaged as a separate package with independent version
numbers from OpenSCAD itself, and use the existing very robust and
well-tested automatic update mechanisms that such distributions already
have in place for packaged software.  Mechanisms which are already
familiar to Linux distribution users, so OpenCAD/MCAD do not need to
document them or teach people how to use them, or troubleshoot them!

If desired, the OpenSCAD packages for these distributions could be set
to "recommend" MCAD, so most package managers would automatically
install MCAD when OpenSCAD was installed.

As someone who does a moderate amount of software packaging, I think
you'll find this approach far more appropriate, easy and automatic than
any "special" update mechanism you build in to OpenSCAD itself (which,
unless great care is taken, may well then have to be disabled for
packaged software, to avoid conflicting with packaging rules anyway!).

If what we are talking about here is bundling MCAD with OpenSCAD in
downloadable installer packages for Windows, OK, that's simply a
convenience for Windows users, whose OS lacks a consistent software
packaging infrastructure (you can't get your own apps and libraries into
"Windows Update"!).  But when making things easier for Windows users,
please take care not to inconvenience Linux users, who already have (and
expect to use) a packaging system for software distribution, and should
not be expected to have to deal with another one just for OpenSCAD.

SUMMARY: Collaboration between MCAD and OpenSCAD sounds very positive,
but the specific update mechanism being proposed here seems less useful
to me, at least in the Linux world.

Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: MCAD

Tim Schmidt
In reply to this post by kintel
On Mon, Jan 17, 2011 at 11:10 AM, Marius Kintel <[hidden email]> wrote:
> I plan to do a 2011.01 release which represents the current state.
> This could be a good time to include the MCAD library.
> I would in case suggest that we include MCAD as a convenience, without guarantees for future compatibility apart from what Tim (and other contributors) decide to deal with.

Sounds good to me.  I'm organizing a small hackathon for MCAD
tomorrow, centered in #openscad on freenode.  I think after that we'll
be in OK shape for inclusion with an API I won't be embarrassed to
keep stable.

--tim

Reply | Threaded
Open this post in threaded view
|

Re: MCAD (and updates)

Tim Schmidt
In reply to this post by Jonathan Marsden
On Mon, Jan 17, 2011 at 3:26 PM, Jonathan Marsden <[hidden email]> wrote:
>>> Also, it would be cool if the libraries could be updated without
>>> updating OpenSCAD from some library distribution server with a
>>> up-to-date check in OpenSCAD.
>
>> Agreed.
>
> Really?  Why design, implement, document and maintain a
> unique-to-OpenSCAD update process?

In my mind this meant "MCAD ships with OpenSCAD - and should be
packaged as such, but it'd be nice if one could 'git pull' the latest
version easily."

That's all.

No big deal.

--tim

Reply | Threaded
Open this post in threaded view
|

Re: MCAD (and updates)

Stuart Young
On 18 January 2011 09:19, Tim Schmidt <[hidden email]> wrote:
On Mon, Jan 17, 2011 at 3:26 PM, Jonathan Marsden <[hidden email]> wrote:
>>> Also, it would be cool if the libraries could be updated without
>>> updating OpenSCAD from some library distribution server with a
>>> up-to-date check in OpenSCAD.
>
>> Agreed.
>
> Really?  Why design, implement, document and maintain a
> unique-to-OpenSCAD update process?

In my mind this meant "MCAD ships with OpenSCAD - and should be
packaged as such, but it'd be nice if one could 'git pull' the latest
version easily."

That's all.

No big deal.

Q: Is there a way for OpenSCAD to query a library as to it's version?

If there was a simple "assumed" function (or even a fixed format comment, that would need to be specced) in a lib that holds the version number, then you could make sure that a specific version (or greater) of a library is in use. It could also allow OpenSCAD itself to tell you "which versions" of libraries are installed.

This in combination with the stuff Andrew Plumb suggested would be great! Immediately when you go to insert a library you'd know which version of the library you had installed. if you 'know' you need a different version, you'd be immediately aware you need to change it. Having versions available also would help others when debugging a users .scad file that they can't get working or that causes an OpenSCAD bug (exactly replicating their environment).

Quoted for reference:

> W.r.t. implementing on the UI side, I'd like to see something similar to the Arduino Sketch - Import Library approach.
> - Have a library search path defined in OpenSCAD Preferences.
> - Scan the library search path for .scad files and list them in a Libraries menu.
> - When selected from the pulldown, insert a "use </path/to/library/file.scad>" at the cursor location.
>
>...or to get even fancier, make a simple dockable tree widget, scan for and populate with library branches, then scan
> libraries for "function" and "module" declarations to build sub-branches in the widget.  Allow the (ab)user to select
> from the tree to instantiate directly in the code.

Also, if there was a simple way to have multiple versions of the same library installed, and you could 'pick' the version you want to use (latest by default), then this could handle all sorts of incompatibilities in versions of libraries being used. Of course, only one VERSION of a library should be in use in any one project at a time. It would also make finding out which version needs to be used (when unknown) a matter of user selection in a UI prompt and testing.

Note: Adding multiple versions would be an exercise for the USER to perform, and should in no way be packaged. Latest 'released' version of any packaged lib should be the only one included in a package at package time. There should however be a tool (or even just a documented procedure) so that the user gets it right when pulling old versions down from somewhere (eg: github), to get multiple versions working, without clobbering existing stuff (ie: the packaged version).

--
Stuart Young (aka Cefiar)
Reply | Threaded
Open this post in threaded view
|

Re: MCAD (and updates)

Tim Schmidt
On Mon, Jan 17, 2011 at 6:39 PM, Stuart Young <[hidden email]> wrote:
> Q: Is there a way for OpenSCAD to query a library as to it's version?

I think we could manage to stuff a version number into a variable, and
increment on API changes.

--tim

12