-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are you looking for a maintainer? #32
Comments
On Wed, Jul 05, 2017 at 12:41:17AM +0000, Rob Sherwood wrote:
I just threw up a trivial pull request
(#31) only to realize that there's 4
years of outstanding pull requests against this repo. At least the ones I
looked at look reasonable. Is someone maintaining this code? If not, I'm happy
to volunteer to do so...
I'm supposed to be maintaining it, but haven't gotten much done recently. Some
help reviewing the PRs would be great, but ultimately I'd like the dev branch
polished and merged back to master, so these PRs need to be merged to both.
…--
Kind regards,
Loong Jin
|
Any sort of guidance or concerns about the diffs? I'm still working my way through the testing to understand how it works... |
I've gone through the files to see what was available and ended up writing a test framework. There is some good stuff here but I don't know haw anyone can use it without some way of determining what is there. I spent a day on it with the goal of creating an index from test files. The low hanging fruit comprises 17 test files that I have produced manifest images, some complete and some not. I was cataloguing the Deprecation warnings but you can just grep these functions in the files, I stopped doing that. DEPRECATED: child(), polyhedron(triangles=[]), assign() I have a function/module manifest, I have a test edit framework, and I have 17 catalogue images that, for the most part, provide a picture of what the capabilities are. i.e. Is there interest in developing this library? I'm gonna use it. |
@tsingi, I know that there are those on Thingiverse (www.thingiverse.com) that would love to have your library. There are some other gear libraries already, but the more the better. If you were to post it there with an OpenSCAD tag, I know that it would be picked up and used. Kevin |
Hi Kevin, appreciate for your prompt reply. I'm excited, up to my elbows in code and printer parts and too tired to continue. I'd like to brainstorm with you a bit if that's OK, after I've rested up. Is this an appropriate place for me emit brain farts? I have a lot of them. Here's my last test case, cubic_array() and transform(xlate,rot,scale) The code is remarkably simple. So satisfying. |
@tsingi I would think if you want to bounce ideas off me, it would be better to email me directly. I think this thread we are in is more about tracking issues / problems with the code, as compared to brainstorming about it's use. My email is kdtop3 {at} gmail {dot} com But if you want to post here, it's OK with me. I'm not a moderator or anything, so my word means nothing.. :-) |
fwiw, I wouldn't mind being involved in the conversation. Not sure if it's
feasible, but still interested in trying to help out.
…On Wed, Apr 11, 2018 at 5:46 PM, Kevin Toppenberg ***@***.***> wrote:
@tsingi <https://github.com/tsingi> I would think if you want to bounce
ideas off me, it would be better to email me directly. I think this thread
we are in is more about tracking issues / problems with the code, as
compared to brainstorming about it's use. My email is kdtop3 {at} gmail
{dot} com But if you want to post here, it's OK with me. I'm not a
moderator or anything, so my word means nothing.. :-)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#32 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGqwEO36aCuYMCZa4xuybUQWuGgBPPHks5tnqP5gaJpZM4ONwUb>
.
|
Great! Thank you guys. I'm looking for input and this seems a good place. I'll try to be more precise. To clarify, I wasn't offering gear scripting, I'm just learning scad, I was offering to test and catalogue the library to make it more useful. I don't much like writing test suites, prerequisite to cataloguing, but it's a great way to learn, so I've done a bit of that work for MCAD. That is what the gear image was meant to illustrate. It was a good day's work, but I'm not specifically offering to catalogue MCAD any more, my goals have elevated. That is what the cubic array image was meant to illustrate. I found this library in my early research, Kevin pointed out that there were a lot more libraries. I thought I had searched for them but I didn't really know what I was looking for. Fortunately there are a lot of libraries listed in this repo. I've cloned or downloaded the ~80% of them that look broadly useful and found others on the net. About 25 in all. So the resources available for openscad are pretty awesome, but I look at it and it doesn't seem to be all that easy to use. You need to be at least a moderate hacker, if I can re-appropriate the term, and wade through scattered resources of varied quality. This probably explains why I don't see as many scad designs at places like thingiverse as I'd like, open designs that can be easily modified. There seems to be a bottleneck. Making scad libraries easier to use would be beneficial, regardless of your hacking ability, hacking is work. I think scad needs to evolve. Not the language, it seems appropriately straightforward, but how it's used. Are there initiatives for this? I'll just leave that there for the moment and ask for ideas on how that might be approached. I have some, it seems obvious to me, but, I'm purely a Linux based life form and they are specific to my talents. I'd like to hear other opinions. I often get ahead of myself. |
I'm not aware of any efforts across different libraries. It would be awesome to have some better way to both discover and use various libraries. MCAD is a bit special as it is usually included in OpenSCAD distribution. I guess it started as collection of random but useful scripts so the documentation is also lacking. There were two different suggestions for how to do package management for OpenSCAD on the forum lately. Both are using existing package managers which is the way to go I think as we probably will not have the ressources to develop our own anytime soon. Based on NPM: Based on Ruby Gems: I think I'd prefer the NPM based solution as Ruby seems to be quite a huge dependency. But also NPM is not included in latest Debian/Testing, so I guess both cases are not exactly perfect :-). What's missing right now (from my perspective) to get things going
Of cause there's still the risk people don't like it and just ignore the effort. But without some initial effort to make it useful, I don't think anyone will start even looking at it. |
Hi Kevin.
Package manager, I hadn't thought of that, the concept has changed my
thinking considerably. Other than Linux I don't use them much but
Javascript and Python have them and they do work nicely. I don't know
Ruby. I cloned the other one, I'll take a look at it when I get a chance.
Thanks!
…On Thu, Apr 12, 2018 at 10:52 AM, Torsten Paul ***@***.***> wrote:
I'm not aware of any efforts across different libraries. It would be
awesome to have some better way to both discover and use various libraries.
MCAD is a bit special as it is usually included in OpenSCAD distribution. I
guess it started as collection of random but useful scripts so the
documentation is also lacking.
There were two different suggestions for how to do package management for
OpenSCAD on the forum lately. Both are using existing package managers
which is the way to go I think as we probably will not have the ressources
to develop our own anytime soon.
Based on NPM:
http://forum.openscad.org/A-Package-Manager-for-OpenSCAD-td23465.html
Based on Ruby Gems:
http://forum.openscad.org/scad-bundler-Another-package-
manager-for-OpenSCAD-td23572.html
I think I'd prefer the NPM based solution as Ruby seems to be quite a huge
dependency. But also NPM is not included in latest Debian/Testing, so I
guess both cases are not exactly perfect :-).
What's missing right now (from my perspective) to get things going
- Polish the calls to the package manager to look like OpenSCAD (maybe
just a simple wrapper script or so)
- Get a couple of libs prepared and registered
Of cause there's still the risk people don't like it and just ignore the
effort. But without some initial effort to make it useful, I don't think
anyone will start even looking at it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA_xTHRNiB7nVqwj53-WFLoL3s86056zks5tn2o-gaJpZM4ONwUb>
.
--
"Rumors of my death have been greatly exaggerated."
-- Jesus Christ
|
Regarding getting users, I'm the number one user, I'll be taking a dogfood
approach once I get this printer settled. If I can't use it, it's not
ready for anyone else.
…On Thu, Apr 12, 2018 at 10:09 PM, Rick ***@***.***> wrote:
Hi Kevin.
Package manager, I hadn't thought of that, the concept has changed my
thinking considerably. Other than Linux I don't use them much but
Javascript and Python have them and they do work nicely. I don't know
Ruby. I cloned the other one, I'll take a look at it when I get a chance.
Thanks!
On Thu, Apr 12, 2018 at 10:52 AM, Torsten Paul ***@***.***>
wrote:
> I'm not aware of any efforts across different libraries. It would be
> awesome to have some better way to both discover and use various libraries.
> MCAD is a bit special as it is usually included in OpenSCAD distribution. I
> guess it started as collection of random but useful scripts so the
> documentation is also lacking.
>
> There were two different suggestions for how to do package management for
> OpenSCAD on the forum lately. Both are using existing package managers
> which is the way to go I think as we probably will not have the ressources
> to develop our own anytime soon.
>
> Based on NPM:
> http://forum.openscad.org/A-Package-Manager-for-OpenSCAD-td23465.html
>
> Based on Ruby Gems:
> http://forum.openscad.org/scad-bundler-Another-package-manag
> er-for-OpenSCAD-td23572.html
>
> I think I'd prefer the NPM based solution as Ruby seems to be quite a
> huge dependency. But also NPM is not included in latest Debian/Testing, so
> I guess both cases are not exactly perfect :-).
>
> What's missing right now (from my perspective) to get things going
>
> - Polish the calls to the package manager to look like OpenSCAD
> (maybe just a simple wrapper script or so)
> - Get a couple of libs prepared and registered
>
> Of cause there's still the risk people don't like it and just ignore the
> effort. But without some initial effort to make it useful, I don't think
> anyone will start even looking at it.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#32 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AA_xTHRNiB7nVqwj53-WFLoL3s86056zks5tn2o-gaJpZM4ONwUb>
> .
>
--
"Rumors of my death have been greatly exaggerated."
-- Jesus Christ
--
"Rumors of my death have been greatly exaggerated."
-- Jesus Christ
|
Sorry, tpaul. I was reading the discussion group on the package maintainer, it's encouraging. |
Love the interest and the enthusiasm.
Re: package manager - what do folks think about a "dynamic"/inline package
manager, something like:
…----
$ cat foo.scad
# my awesome scad file
# normal, local import
use <MCAD/gears.scad>
# proposed dynamic import
use <http://www.public.server.com/path/tocool_file_v3.scad>
new_gear(...); # as imported from cool_file.scad
----
This could be as simple as a HTTP GET along with a simple local file system
cache (for offline work).
Thoughts? That could certainly simplify package management and makes no
assumptions
about the underlying system. For example, I run OpenSCAD on MacOS and
installing a special package
manager there would be a PITA.
Thoughts?
- Rob
.
On Thu, Apr 12, 2018 at 7:09 PM, Rick ***@***.***> wrote:
Hi Kevin.
Package manager, I hadn't thought of that, the concept has changed my
thinking considerably. Other than Linux I don't use them much but
Javascript and Python have them and they do work nicely. I don't know
Ruby. I cloned the other one, I'll take a look at it when I get a chance.
Thanks!
On Thu, Apr 12, 2018 at 10:52 AM, Torsten Paul ***@***.***>
wrote:
> I'm not aware of any efforts across different libraries. It would be
> awesome to have some better way to both discover and use various
libraries.
> MCAD is a bit special as it is usually included in OpenSCAD
distribution. I
> guess it started as collection of random but useful scripts so the
> documentation is also lacking.
>
> There were two different suggestions for how to do package management for
> OpenSCAD on the forum lately. Both are using existing package managers
> which is the way to go I think as we probably will not have the
ressources
> to develop our own anytime soon.
>
> Based on NPM:
> http://forum.openscad.org/A-Package-Manager-for-OpenSCAD-td23465.html
>
> Based on Ruby Gems:
> http://forum.openscad.org/scad-bundler-Another-package-
> manager-for-OpenSCAD-td23572.html
>
> I think I'd prefer the NPM based solution as Ruby seems to be quite a
huge
> dependency. But also NPM is not included in latest Debian/Testing, so I
> guess both cases are not exactly perfect :-).
>
> What's missing right now (from my perspective) to get things going
>
> - Polish the calls to the package manager to look like OpenSCAD (maybe
> just a simple wrapper script or so)
> - Get a couple of libs prepared and registered
>
> Of cause there's still the risk people don't like it and just ignore the
> effort. But without some initial effort to make it useful, I don't think
> anyone will start even looking at it.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#32 (comment)>, or
mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AA_xTHRNiB7nVqwj53-
WFLoL3s86056zks5tn2o-gaJpZM4ONwUb>
> .
>
--
"Rumors of my death have been greatly exaggerated."
-- Jesus Christ
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#32 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGqwJ9jUsYWeFbZjq0FIL2Zn69C3G5mks5toAjcgaJpZM4ONwUb>
.
|
Dynamic access might be an additional option, but I don't think it should be the default. Not every system should have the need for internet access just to build a model. E.g. some services like OBS (where we build the OpenSCAD nightlies) does not have that. |
Dynamic access would be cool but t-paul makes a good point. It's probably a rare setup for the design box to not have connectivity but it should be supported. Just to kick it around, would it be possible to trigger on a load fail in a script and try a dynamic download if the script is missing? use <some-good-stuff.scad> if( failed_to_load( some_good_stuff )) Alternatively There might be security issues there. I don't know, |
There has been discussion re security in the past, about automatically loading external content, that ended with 'not a good idea'. |
@hyperair Give yourself a push. Its 2019 now and various pull requests from 2014 are still lagging. You have an offer of somebody mainting it. Give him a chance. I just reinvented the (OpenScad) wheel only to realize the functionality I didn't found in MCAD was in a pull request which I missed when lokking in the MCAD library. |
@indazoo 🤷♂️ Start by getting the stuff in the Ultimately, what we want is to be able to use the namespace that's in the
When someone gets around to doing all of that, the rest of the PRs will be unblocked and can be merged in without too much fuss. |
@hyperair Thanks for your response. I don't see a problem including all directories from dev to master because master has only the "bitmap" directory. That should not break anything for the "Flat-MCAD" users...wrong thinking? Should the "flat" files still exist with a "depreciated" comment/echo() in them but instead of code just including a fully compatible file from the dev structure so it still works for the Flat_MCAD users? Any improvements done in Flat-MCAD since the "horrible decision" should be in dev by incremental or a monumental PR to dev before merging dev into master? Lets' look at a simple sample : constants.scad . It is much "richer" in dev (the numbers are more exact) but it lacks the "mm_per_inch" variable and all constants are renamed. So, how do you decide such a case? I mean I don't want to be a "someone who completely broke something" ... Do you keep a list what already has been done? Do you have a job list? |
Yeah.
This is the case, yes, but we'll end up with a lot of duplicated code, and anything that hits The naming convention of modules in MCAD are quite messy in
Kind of. Basically something like https://github.com/openscad/MCAD/blob/dev/nuts_and_bolts.scad, but for all the modules in
I've been periodically merging
Old designs using Flat-MCAD will be importing include <MCAD/general/constants.scad>
TAU = const_tau;
PI = const_pi;
mm_per_inch = 25.4;
There isn't an actively collated list, but we're ready when |
Ok, i got it now. Thanks for the clarification.
Then in MCAD/general/constants.scad:
|
Yeah go ahead and put a deprecation notice, but I wouldn't word it as someone doing a bad thing to MCAD -- ultimately we'll end up with a cleaner library that doesn't litter the global namespace with overly generic names. |
OK. I know, I'm a difficult character... |
I'm not sure about discussions, but there has been precedent within MCAD for uppercase constants, e.g. in |
Sigh... |
You don't have to drop your repo. Just push your changes to a specific branch (one branch per PR) and head to |
I found a solution for Github problems and made a PR about constants.scad |
Thanks @indazoo for insisting in here. MCAD definitely needs some love.
Well, we cannot maintain backwards compatibility forever. If we used semantic versioning [1] I guess the library would now be somewhere on version 1.x.x. The proper way to release an API-breaking version is clearly explained [2]. So a possible roadmap could be:
|
Hi rockstorm101, Pre-Info about MCAD release versioning: rockstorm101, here is a problem with your plan: A lot of work probably nobody will do.
"openscad-201x.xx depreceated flat file structure" Adjust the matching year but should be smaller than current releases to indicate old code.
"openscad-2014.05 classic file structure" . Again adjust the matching year.
|
I'm out. |
I just threw up a trivial pull request (#31) only to realize that there's 4 years of outstanding pull requests against this repo. At least the ones I looked at look reasonable. Is someone maintaining this code? If not, I'm happy to volunteer to do so...
Just let me know and thanks.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: