Contributions to OpenSCAD's bundled MCAD?

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

Contributions to OpenSCAD's bundled MCAD?

Taahir Ahmed
(I apologize if I have sent this twice --- I just switched my email that is
subscribed to this list)

I was wondering if there is an established way to contribute to MCAD.  There
are several forks of MCAD on github, including elmom's original and OpenSCAD's
bundled version.

Should pull requests for MCAD be directed to elmom's repo, OpenSCAD's repo, or
perhaps posted to this list as pull requests / am patches?

Thanks,

Taahir Ahmed
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

kintel
Administrator
On Aug 24, 2014, at 22:34 PM, Taahir Ahmed <[hidden email]> wrote:
>
> I was wondering if there is an established way to contribute to MCAD.

MCAD really needs a maintainer. Multiple people have wanted to chip in lately but I haven’t really seen any commitment to take maintainership.
There are some open issues to discuss:
1) We need to maintain backwards compatibility. This can be separated from future development
2) We could need a clean start on (parts of) the API
3) We want to create a new, official, user-space library. This will be more low-level than MCAD
4) We want to add support for namespaces, making library separation better
5) We want to create some sort of package management system with versioning for better handling library compatibility

In terms of MCAD maintainership, the 2 first ones are the most important ones for now.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
On Sun, Aug 24, 2014 at 10:47:47PM -0400, Marius Kintel wrote:
> On Aug 24, 2014, at 22:34 PM, Taahir Ahmed <[hidden email]> wrote:
> >
> > I was wondering if there is an established way to contribute to MCAD.
>
> MCAD really needs a maintainer. Multiple people have wanted to chip in lately
> but I haven’t really seen any commitment to take maintainership.

I volunteered to do this on IRC, but hadn't gotten around to posting on the
mailing list. I've been continuing McNeight's work on
https://github.com/hyperair/MCAD, but haven't really figured out a direction to
proceed in.

For now, I've been fixing up some of the bad merges done by McNeight (they look
like they were done in a hurry, but kudos to him for sourcing all of the extra
stuff. MCAD is finally looking more featureful), and working on fixing up
MCAD/gears/involute_gears.scad as well as
MCAD/fasteners/{threads,nuts_and_bolts}.scad.

> There are some open issues to discuss:
> 1) We need to maintain backwards compatibility. This can be separated from
> future development
> 2) We could need a clean start on (parts of) the API

I spent some time fixing some of the code, and I think that a clean start on the
API is definitely needed. At the very least, the circular_pitch parameter of
gear() really needs to be fixed. I've added convertcp() as a shim function for
converting circular pitch from mm to (180 / pi) mm, but this really shouldn't be
necessary.

Also, some mathematical functions are duplicated with different names among
general/*.scad. In fact, some of these things look like they should be in the
official library mentioned in #3.

And then there's the issue of inconsistent naming of symbols. Some are
camel-case, some are underscored, and there are spelling errors everywhere.
linear_exturde_flat_option(), woohoo!

If backward compatibility is required, how aboutn adding a compat/ subdirectory
that supports the old API?

> 3) We want to create a new, official, user-space library. This will be more
> low-level than MCAD

I recall you mentionins scad-utils as a potential good candidate for this.

> 4) We want to add support for namespaces, making library separation better

Yes please. C++-like namespaces would be ideal imo.

> 5) We want to create some sort of package management system with versioning
> for better handling library compatibility

Proper versioning comes first.

6) We want documentation on each public symbol, explaining what each parameter
is, and what types/units are expected. For now, it's mostly "Use the source,
Luke", with inconsistent units, meanings of variables, and even naming
convention.

> In terms of MCAD maintainership, the 2 first ones are the most important ones
> for now.

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Taahir Ahmed
In reply to this post by kintel
MCAD is not great on points 1 and 2.  I agree that a library with a more
unified direction and limited scope is needed (a C++-style standard library,
rather than a python-style standard library).

I'm not sure that point 5 is the right way to go (if you are talking about npm
or CPAN-style package management).  It might be better to just allow distro
package managers to put libraries in a system wide search path, and provide an
-L flag (like gcc) to allow specifying more search paths.

Then, the user has total control over what specific versions of packages are
in use, without a huge infrastructure investment that clashes with
distribution package managers.

> 3) We want to create a new, official, user-space library. This will be more
> low-level than MCAD

Things that might be in scope for such a standard library:

  a) Unit handling (cleaner than a file full of mult constants).
  b) Mathematical constants (including a standard epsilon value).
  c) Basic shapes (2D and 3D).
  d) Parametric chamfers.
  e) Different types of fits (press, slip).
  f) (Perhaps... ISO/ANSI/SAE bolt and nut holes)

My proposed contribution to MCAD lays the groundwork for point a.


Taahir Ahmed
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
On Sun, Aug 24, 2014 at 10:31:42PM -0500, Taahir Ahmed wrote:
> MCAD is not great on points 1 and 2.  I agree that a library with a more
> unified direction and limited scope is needed (a C++-style standard library,
> rather than a python-style standard library).
>
> I'm not sure that point 5 is the right way to go (if you are talking about npm
> or CPAN-style package management).  It might be better to just allow distro
> package managers to put libraries in a system wide search path, and provide an
> -L flag (like gcc) to allow specifying more search paths.

It's currently -I (like cpp/gcc/g++). OPENSCADPATH as an environment variable is
also honoured. MCAD itself is currently installed into
/usr/share/openscad/libraries/, at least in Debian. User-specific libraries can
be installed in ~/.local/share/OpenSCAD/libraries.

> Then, the user has total control over what specific versions of packages are
> in use, without a huge infrastructure investment that clashes with
> distribution package managers.

I agree with this, but not all distros have sane package managers. Windows seems
like a big culprit here.

> > 3) We want to create a new, official, user-space library. This will be more
> > low-level than MCAD
>
> Things that might be in scope for such a standard library:
>
>   a) Unit handling (cleaner than a file full of mult constants).

That sounds interesting. How does it compare with
https://github.com/hyperair/MCAD/blob/master/units/metric.scad? I noticed that
McNeight added some functions you could wrap your units around if you didn't
want to use the mult constants. I still find the mult constants easier to use
though.

>   b) Mathematical constants (including a standard epsilon value).

elmom seems to have added this in MCAD/constants.scad, which was then expanded
in MCAD/general/constants.scad by McNeight. epsilon on the other hand appears to
be in MCAD/units/metric.scad.

>   c) Basic shapes (2D and 3D).



>   d) Parametric chamfers.

There's one in MCAD/fasteners/metric_fastners.scad. I'm not sure if the spelling
of the file name is intentional, but like all other things in McNeight's and my
MCAD trees right now, it requires a lot of cleanup.

>   e) Different types of fits (press, slip).

This sounds awesome.

>   f) (Perhaps... ISO/ANSI/SAE bolt and nut holes)

This is also included in MCAD/fasteners/nuts_and_bolts.scad. McNeight's copy is
a bit broken since he wrongly merged in a change that used AC widths instead of
AF widths with a hexagon() module, resulting in oversized nut holes. I've
reverted that in my tree.

> [...]

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Taahir Ahmed
I will just include the body of it here, since it's quite small.

As you can see, it's pretty much exactly the same, except that it also
includes a knob called MCAD_BASE_UNIT, which is a scaling factor so that the
use can choose what the underlying "OpenSCAD internal units" mean.

I used shorter names for the unit functions, since the idea is that they will
be typed a lot.  Additionally, I included inches and mils, since those are
very common on datasheets.

By default, the base unit is mm, but that can be changed:

include <units.scad>
MCAD_BASE_UNIT = MCAD_BASE_UNIT_MIL;
// now mils(100) == 100;

Taahir Ahmed

-------- units.scad --------
//
// Internally, OpenSCAD uses arbitrary units, and the mapping from OpenSCAD
// units to real units is determined by the output pipeline.  No amount of
// code we write is going to change that.
//
// However, when building a design against external objects, it is useful to
// ensure that relative sizing is correct.  units.scad contains functions and
// constants for interoperation between measurement systems.
//

//
// Different choices for MCAD_BASE_UNIT.
//
MCAD_BASE_UNIT_MM = 1;
MCAD_BASE_UNIT_CM = 1 / 10;
MCAD_BASE_UNIT_DM = 1 / 100;
MCAD_BASE_UNIT_M  = 1 / 1000;
MCAD_BASE_UNIT_INCH = 1 / 25.4;
MCAD_BASE_UNIT_MIL  = 1000 * MCAD_BASE_UNIT_INCH;

//
// By default, we assume that we are working in millimeters.  However, users
// may override this choice by assigning MCAD_BASE_UNIT to the appropriate
// scaling factor
//
MCAD_BASE_UNIT = MCAD_BASE_UNIT_MM;

//
// Scale functions.
//
// Functions that map from a given scale to OpenSCAD's internal scale.  These
// should be the main means of expression units on quantities.
//
// Internally, they boil the given quantity down to its equivalent in
// millimeters, then use MCAD_BASE_UNIT to convert to OpenSCAD internal units.
//
// Parameters:
//
//  q: The quantity to associate with the named unit.
//
// Examples:
//
//   mm(12) + mil(100)  // 12 millimeters and 100 mils.
//

function mm(q) = MCAD_BASE_UNIT * q;

function cm(q) = mm(10 * q);
function dm(q) = mm(100 * q);
function  m(q) = mm(1000 * q);

function inch(q) =   mm(25.4 * q);
function  mil(q) = inch(q / 1000);
function foot(q) = inch(12 * q);
function yard(q) = inch(36 * q);

//
// Unit constants (deprecated).
//
// Multiplicative constants used to scale between the given units and OpenSCAD
// internal units.  Consider using the equivalent scale functions.
//

mm = mm(1);
cm = mm(10);
dm = mm(100);
 m = mm(1000);

inch = inch(1);

M3 = mm(3);
M4 = mm(4);
M5 = mm(5);
M6 = mm(6);
M8 = mm(8);

//
// MCAD's internal epsilon setting.
//
// Used by the MCAD library whenever a small distance is needed to overlap
// shapes for boolean cutting, etc.  The user may override it.
//
MCAD_EPSILON = mm(0.01);

-------- units.scad --------
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
On Sun, Aug 24, 2014 at 11:18:06PM -0500, Taahir Ahmed wrote:
> I will just include the body of it here, since it's quite small.
>
> As you can see, it's pretty much exactly the same, except that it also
> includes a knob called MCAD_BASE_UNIT, which is a scaling factor so that the
> use can choose what the underlying "OpenSCAD internal units" mean.
>
> I used shorter names for the unit functions, since the idea is that they will
> be typed a lot.

I like the shorter names, but I think McNeight expanded them to longer names in
an effort to namespace them in the absence of proper OpenSCAD namespaces.

> Additionally, I included inches and mils, since those are
> very common on datasheets.

That's included in <MCAD/units/us.scad>

> By default, the base unit is mm, but that can be changed:
>
> include <units.scad>
> MCAD_BASE_UNIT = MCAD_BASE_UNIT_MIL;
> // now mils(100) == 100;

FWIW, the same can be achieved with McNeight's <MCAD/units/metric.scad> by
setting length_mm = 1 / 25.4.

Rather than this approach, I was thinking of having <MCAD/units/metric.scad>
import a <MCAD/units/default.scad>, which sets the base unit. This can then be
overridden per-user or per-project by adding a <MCAD/units/default.scad> file in
your search path.

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

MichaelAtOz
Administrator




-----
Unless specifically shown otherwise above, this is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :)
.s. The `´ key on my keyboard is soradically roblematic when I ress it, reciitating erceived missellings

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Contributions-to-OpenSCAD-s-bundled-MCAD-tp9445p9452.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Taahir Ahmed
In reply to this post by Chow Loong Jin

> I like the shorter names, but I think McNeight expanded them to longer names
> in an effort to namespace them in the absence of proper OpenSCAD namespaces.

For them to be namespaced, they should be named something like mcad_mm,
mcad_in, etc.  People might go around adding length_mm functions to their
projects, but they're very unlikely to create a mcad_mm function.

If these were part of a truly standard library, then we could get away with
short names, since people will already know those names are taken.

> Rather than this approach, I was thinking of having <MCAD/units/metric.scad>
> import a <MCAD/units/default.scad>, which sets the base unit. This can then
> be overridden per-user or per-project by adding a <MCAD/units/default.scad>
> file in your search path.

Then the user has to incorporate knowledge of the units into their build
system, or worse, as a site-local setup.  That's not so great for having
projects be portable.

Either way works, though.

-----------------------------------------------------------------------------

All in all, your fork appears to be in a much better state than the others I
have looked at.  Is it going to be the next official bundled MCAD?

-----------------------------------------------------------------------------

Part of my pull request to the official MCAD repo also included a basic
testing setup.  Is that something you would be interested in?

Basically, it provides a non-recursive Makefile that lets you run 'make test'
in the top level directory.  Right now, there are only two tests (for my unit
functionality).  It will become a lot more useful when OpenSCAD gains an
assert statement or library function.

Taahir Ahmed
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

MichaelAtOz
Administrator
In reply to this post by Chow Loong Jin
Chow Loong Jin wrote
Rather than this approach, I was thinking of having <MCAD/units/metric.scad>
import a <MCAD/units/default.scad>, which sets the base unit. This can then be
overridden per-user or per-project by adding a <MCAD/units/default.scad> file in
your search path.
Unfortunately it checks the home directory of the included file first, so the default in MCAD/units will be matched first.

I mapped out the include/library behavioursin the wiki here. And it is worse for a use<>
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
On Sun, Aug 24, 2014 at 10:24:52PM -0700, MichaelAtOz wrote:

> Chow Loong Jin wrote
> > Rather than this approach, I was thinking of having
> > &lt;MCAD/units/metric.scad&gt;
> > import a &lt;MCAD/units/default.scad&gt;, which sets the base unit. This
> > can then be
> > overridden per-user or per-project by adding a
> > &lt;MCAD/units/default.scad&gt; file in
> > your search path.
>
> Unfortunately it checks the home directory of the included file first, so
> the default in MCAD/units will be matched first.
You mean the current directory?

> I mapped out the include/library behaviours in the wiki here.
> <http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Libraries>   And it is
> worse for a use<>

No, it seems to work, but you need to set OPENSCADPATH=. for per-project
settings. The trick is:

MCAD/units/metric.scad:
include <MCAD/units/default.scad>

The lookup to current directory will fail because it looks for
"MCAD/units/default.scad" rather than "default.scad".

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
In reply to this post by Taahir Ahmed
On Mon, Aug 25, 2014 at 12:23:03AM -0500, Taahir Ahmed wrote:
>
> > I like the shorter names, but I think McNeight expanded them to longer names
> > in an effort to namespace them in the absence of proper OpenSCAD namespaces.
>
> For them to be namespaced, they should be named something like mcad_mm,
> mcad_in, etc.  People might go around adding length_mm functions to their
> projects, but they're very unlikely to create a mcad_mm function.

You're right. That sounds like a good idea, but that results in quite a bit of
typing.

> If these were part of a truly standard library, then we could get away with
> short names, since people will already know those names are taken.
>
> > Rather than this approach, I was thinking of having <MCAD/units/metric.scad>
> > import a <MCAD/units/default.scad>, which sets the base unit. This can then
> > be overridden per-user or per-project by adding a <MCAD/units/default.scad>
> > file in your search path.
>
> Then the user has to incorporate knowledge of the units into their build
> system, or worse, as a site-local setup.  That's not so great for having
> projects be portable.
>
> Either way works, though.
My method would allow projects to be portable if all lengths are
fully-qualified. Bare numbers will cause discrepancies though.

> -----------------------------------------------------------------------------
>
> All in all, your fork appears to be in a much better state than the others I
> have looked at.  Is it going to be the next official bundled MCAD?

That depends on when the next OpenSCAD release is. It currently isn't in a state
where I'd like it to be official just yet. There were a lot of bad merges and
I'm still fixing the introduced bugs. Also, considering the .scad file
reorganization, this is effectively an API break.

I don't want to have more than one of that in such a short time frame, so we
absolutely need to nail down the basic API before releasing. This also places me
in a bit of a dilemma as I don't know when namespace support for OpenSCAD will
arrive. Is anyone actively working on this?

> -----------------------------------------------------------------------------
>
> Part of my pull request to the official MCAD repo also included a basic
> testing setup.  Is that something you would be interested in?
>
> Basically, it provides a non-recursive Makefile that lets you run 'make test'
> in the top level directory.  Right now, there are only two tests (for my unit
> functionality).  It will become a lot more useful when OpenSCAD gains an
> assert statement or library function.

Hmm, I'm not sure. McNeight has also left behind a Python-based testing
framework that looks like it parses module names matching "test*" from all the
.scad files present and runs it. It's just a basic compilation check rather than
anything sophisticated.

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Johannes Reinhardt
In reply to this post by Chow Loong Jin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 25 Aug 2014 12:02:40 +0800
Chow Loong Jin <[hidden email]> wrote:

Hi,

> >   f) (Perhaps... ISO/ANSI/SAE bolt and nut holes)
>
> This is also included in MCAD/fasteners/nuts_and_bolts.scad.
> McNeight's copy is a bit broken since he wrongly merged in a change
> that used AC widths instead of AF widths with a hexagon() module,
> resulting in oversized nut holes. I've reverted that in my tree.

there is also BOLTS (http://jreinhardt.github.io/BOLTS/doc/index.html),
which (in my biased opinion) covers nuts and bolts quite well. I am very
open for contributions of any kind or suggestions on how to improve
BOLTS for OpenSCAD.

Sorry for the shameless plug.

Greetings

Johannes


- --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT+uvsAAoJED3c2393ksVE5o4QAL7VvipT7Rj5b6p1ylQz2UgX
JLVkidBdAjqQeoNoF73J5iDqxWOM3I0LNw8wpm9swfdw+ekXRSHEISYYEEFzUTYD
OK7tKrPqTMrgMGSW+J/wl044PPOSKRZwSKJEL+N9mZ7RnHXYXHeB+8RKgXD5Lz0b
25xZgTxOmAcEYLnYxL5t3eolU7QgJujrQz6qKGQG1jXi4CnKxtZ7NJepz6KIPTun
CM7Th/HHjXcRGafKeVUWPiA9U0TCXvJRjT0mTS2btsPkeZ10E4A0k8G/CaPNAWVE
ig2IhwlZtrENJ3PMaTYhEycq0A48a9WzYnYuRV1pzKclcI9cMD2dswP7vC6iOu+b
f6qzFJLQTSwbnBojRQwlZegPvUQA3/Hy5WhQlpMUCbYrMX1HIvlbWEx3OQDIkC9t
FSTJ8hCY5kSGz96uzcGt1vvhzVD1/PKWdCnAd3u1LC9CN1cMrsxj9N/Vtt2UzGtg
gZfTgLuWjnxHlpBiWxnIKEUtlgygEPAZW0yTGP/8kSXfjI1U4qtJxz3vQnZsG8Kq
/M6UcZo0to7RR99L7I3zrJh5pQrVv0Q8qDNGz8ORUg51lXpbdvxLKVAu1BmwIMVZ
q02y6PNEXc3LPy9+3AgoCNv0zgZ8gWWRs0F4TlUGBkTNdNTqhUrK/yZW30yGbWsK
GkgiQG6ILwyArZU4HbeR
=WZqw
-----END PGP SIGNATURE-----
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
On Mon, Aug 25, 2014 at 09:55:24AM +0200, Johannes Reinhardt wrote:

> On Mon, 25 Aug 2014 12:02:40 +0800
> Chow Loong Jin <[hidden email]> wrote:
>
> Hi,
>
> > >   f) (Perhaps... ISO/ANSI/SAE bolt and nut holes)
> >
> > This is also included in MCAD/fasteners/nuts_and_bolts.scad.
> > McNeight's copy is a bit broken since he wrongly merged in a change
> > that used AC widths instead of AF widths with a hexagon() module,
> > resulting in oversized nut holes. I've reverted that in my tree.
>
> there is also BOLTS (http://jreinhardt.github.io/BOLTS/doc/index.html),
> which (in my biased opinion) covers nuts and bolts quite well.
Oh, this looks very nice. Seems to be on a free license too. I might get around
to packaging this for Debian sometime.

> I am very open for contributions of any kind or suggestions on how to improve
> BOLTS for OpenSCAD.

Looks like BOLTS doesn't have thread rendering. I'm not sure it's in the
intended featureset for BOLTS, but you might be interested in
https://github.com/hyperair/MCAD/blob/master/fasteners/threads.scad which I
recently reimplemented using a twisted linear_extrude(). It doesn't generate
tapered threads, but it should be able to generate untapered screw threads with
a trapezoidal profile. This includes metric threads, acme threads, and buttressn
threads.

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

kintel
Administrator
In reply to this post by Chow Loong Jin
On Aug 25, 2014, at 02:44 AM, Chow Loong Jin <[hidden email]> wrote:
>
> That depends on when the next OpenSCAD release is. […] Also, considering the .scad file
> reorganization, this is effectively an API break.
>
As I mentioned earlier, I’d like to see existing designs continuing to work without having to adapt to a new MCAD, as a lot of users of existing designs aren’t really familiar with the code.
Next release is a bit uncertain, but we’re starting to wind down development to give it some time to breathe. I’d say a few months from now.

> […]  I don't know when namespace support for OpenSCAD will
> arrive. Is anyone actively working on this?
>
That won’t happen in the next release, but probably in the release after that. With ca. 2 releases per year that puts us a bit into the future.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

runsun
Have been writing OpenSCAD code using namespace for a while. This is how I do it:

http://forum.openscad.org/parameterized-models-tp8303p8306.html
$ Runsun Pan, PhD
$ libs: scadx, doctest, faces(git), offline doc(git), runscad.py(2,git), editor of choice: CudaText ( OpenSCAD lexer); $ Tips; $ Snippets
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
In reply to this post by kintel
On Mon, Aug 25, 2014 at 09:16:29AM -0400, Marius Kintel wrote:
> On Aug 25, 2014, at 02:44 AM, Chow Loong Jin <[hidden email]> wrote:
> >
> > That depends on when the next OpenSCAD release is. […] Also, considering the .scad file
> > reorganization, this is effectively an API break.
> >
> As I mentioned earlier, I’d like to see existing designs continuing to work
> without having to adapt to a new MCAD, as a lot of users of existing designs
> aren’t really familiar with the code.

I agree, but the current API is in a bit too much of a sorry state to keep as
is. For now, my setup on my machine is that openscad-mcad 2014.03 is installed
to the global directory (/usr/share/openscad/libraries), while
~/.local/share/OpenSCAD/libraries/MCAD is symlinked to ~/src/MCAD.

This appears to have worked pretty well with designs using both the new and old
API, so perhaps leaving shims around in the root MCAD/ folder with a deprecation
warning ought to work.

> Next release is a bit uncertain, but we’re starting to wind down development
> to give it some time to breathe. I’d say a few months from now.

Hmm, I'm not sure we'll make it by then. See how it goes. I'd appreciate any
help I can get, so pull requests welcome!

> > […]  I don't know when namespace support for OpenSCAD will
> > arrive. Is anyone actively working on this?
> >
> That won’t happen in the next release, but probably in the release after that.
> With ca. 2 releases per year that puts us a bit into the future.

Yeah, I guess we won't wait for that then. :\

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

kintel
Administrator
On Aug 25, 2014, at 11:03 AM, Chow Loong Jin <[hidden email]> wrote:
>
> This appears to have worked pretty well with designs using both the new and old
> API, so perhaps leaving shims around in the root MCAD/ folder with a deprecation
> warning ought to work.
>
Yep, that’s an acceptable solution.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Taahir Ahmed
In reply to this post by kintel
Last night I wrote most of the code to add an assert statement, which should
also be useful for library testing. (Particularly regression testing).

Taahir
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributions to OpenSCAD's bundled MCAD?

Chow Loong Jin
On Mon, Aug 25, 2014 at 11:32:37AM -0500, Taahir Ahmed wrote:
> Last night I wrote most of the code to add an assert statement, which should
> also be useful for library testing. (Particularly regression testing).

That would be nice. I didn't really see a way to implement this properly. Are
you just using echo() statements and grepping the output?

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (836 bytes) Download Attachment
12