Are you looking for a maintainer?
capveg opened this issue · comments
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.
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.. :-)
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:
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.
Sorry, tpaul.
I was reading the discussion group on the package maintainer, it's encouraging.
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 ))
use http://www.public.server.com/path/some-good-stuff.scad
Alternatively
- trigger a dynamic install.
- make that the default behaviour from user configurable repos.
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 dev branch merged into master while maintaining backward compatibility with users of master. A long time ago, someone moved stuff around and completely broke backward compatibility with anything using the master branch, so we can't just directly merge it in or many existing designs will break.
Ultimately, what we want is to be able to use the namespace that's in the dev branch while not breaking existing designs. The work needs to be done, and it doesn't necessarily have to be the maintainer who does it. If you have the time and are willing to spend the effort on it, then do that and either:
- Submit incremental PRs to the
devbranch that bring it closer to the mergeable stat; or - Finish the refactoring job and submit a single PR bringing all the changes for
devintomasterwithout breaking existing designs.
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.
At the moment, there is this "flat" file structure without any sub-directory right now on master. I understand it correctly, you don't want this in future? The future should look like the dev branch with directories?
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?
Currently I'm willing to make it work that strings.scad is alive again.
At the moment, there is this "flat" file structure without any sub-directory right now on master. I understand it correctly, you don't want this in future? The future should look like the dev branch with directories?
Yeah.
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?
This is the case, yes, but we'll end up with a lot of duplicated code, and anything that hits master becomes something that designs will come to depend upon, so we won't be able to change the names of modules in the future.
The naming convention of modules in MCAD are quite messy in Flat-MCAD, and I'd like to get it to be more consistent and namespaced, in a similar fashion to roundedBox becoming mcad_rounded_box (see https://github.com/openscad/MCAD/blob/dev/boxes.scad)
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?
Kind of. Basically something like https://github.com/openscad/MCAD/blob/dev/nuts_and_bolts.scad, but for all the modules in master.
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?
I've been periodically merging master into dev, see 2985eb8 for instance. PRs merged into master can be imported into dev via that method.
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" ...
Old designs using Flat-MCAD will be importing constants.scad via include <MCAD/constants.scad>. They would have had the following variables available to them: TAU, PI, and mm_per_inch. These should remain available to them, with potentially updated/more accurate values, depending on what dev has. This means that /constants.scad on the dev branch should have the following content:
include <MCAD/general/constants.scad>
TAU = const_tau;
PI = const_pi;
mm_per_inch = 25.4;Do you keep a list what already has been done? Do you have a job list?
There isn't an actively collated list, but we're ready when dev reaches feature parity with master without introducing new unwanted symbols (e.g. we want <MCAD/shapes/3Dshapes.scad> to export symbols like mcad_rounded_box, not roundedBox).
Ok, i got it now. Thanks for the clarification.
I must say, I slight disagreement exists. Cough, cough..:
If a user downloads in future MCAD. There will always be a constants file in root??!!?? Forever??? Ok, at most till the AI's get self-aware, but this is also a long time, I think.
No punishment for using the MCAD/constants.scad file?
Proposal for constants.scad:
include <MCAD/general/constants.scad>
echo("Hello, you are a nice guy. Unfortunately someone did not a nice thing to the MCAD library.
It's not your fault, don't worry. Could you please reference MCAD/general/constants.scad in your script?
This is the correct file location nowadays. After the year 2025 there will no longer be a
MCAD/constants.scad file and your script will break! And while you are at it, please use only constants
beginning with mcad_const_...Thank you very very much! ");
Then in MCAD/general/constants.scad:
mcad_const_pi
mcad_const_tau
mcad_const_...3
mcad_const_mm_per_inch = 25.4
// at the very bottom, so nobody finds them :
// Warning! do not use them. These constants are depreciated! Use the ones above!
TAU = const_tau;
PI = const_pi;
mm_per_inch = 25.4;
No punishment for using the MCAD/constants.scad file?
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...
Have been there any discussions about UPPERCASE constants? Many programming languages use this concept. Openscad has no const type (as far i know) so it is possible to overwrite them in code. May be useful, but uppercase would be an indicator to not do that.
I'll do as you want it. Just a thought.
I'm not sure about discussions, but there has been precedent within MCAD for uppercase constants, e.g. in nuts_and_bolts.scad.
Sigh...
My MCAD repository on GitHub is cloned from yours https://github.com/hyperair/MCAD and I have my own changes in it. Should I drop this repository? I need help with this github stuff.
we have:
https://github.com/SolidCode/MCAD ==> https://github.com/openscad/MCAD
and
https://github.com/D1plo1d/MCAD ==> https://github.com/elmom/MCAD ==> https://github.com/hyperair/MCAD
You don't have to drop your repo. Just push your changes to a specific branch (one branch per PR) and head to https://github.com/openscad/MCAD/compare/${target_branch}...indazoo:${your_branch}, e.g. dev...indazoo:dev to submit a PR.
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.
Do you keep a list what already has been done? Do you have a job list?
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:
- Create tests for every single module currently on
master. - Decide a coding style guide for use in the MCAD library.
- Implement agreed coding style on
dev. - Implement all pending code breaking changes in
dev. - Implement wrappers and deprecation warnings around all "old" modules in
dev. - Prove the same results can be obtained in
masterand indevwith the tests written on step 1. - Merge
devintomasterand release as 1.2.0. - After a safe time, all deprecated modules can be deleted and 2.0.0 can be released.
Hi rockstorm101,
It's a good idea to have a plan. Good you brought that up. Sometimes I rush too fast into things.
I think it is difficult to say if there are more people angry because of broken scripts if we continue with the flat version vs the structured version. I'm a long time OpenScad user and don't like the flat version but what do I know about others thinking?
Pre-Info about MCAD release versioning:
I think it is necessary to have an openscad independent release version numbering because OpenScad releases are not that often. It is good that the user can see which OpenScad to use with the release though. And an MCAD version might run with multiple OpenScad version.
rockstorm101, here is a problem with your plan: A lot of work probably nobody will do.
I have a simpler approach, what about the following approach?
- Create a release for the "flat file" version as
"openscad-201x.xx depreceated flat file structure"
Adjust the matching year but should be smaller than current releases to indicate old code.
- Branch/release the "last known good non-flat file" version as
"openscad-2014.05 classic file structure" .
Again adjust the matching year.
- Merge "dev" into "master" create release "openscad-2019.06" so people start using the "non flat" version and will have less compatibilty problems in future.
- From there move to higher version with all the improvements of the "flat-file" version.
- rockstorm101 implements all tests.... ;-)
- Make clear comments in ReadMe, telling the people to use "releases" not the master branch.
I'm out.