It might be wise to have the Maslow_4 FluidNC in an independent fork repo and have the rest in for instance Maslow4 repo. It looks to me it’s easier to keep the fork in sync (if that is a goal of course). The ‘firmware’ folder already is a major difference, feels like a pita to me (but I don’t know the code).
The FluidNC repo is required to be GNU GPL. The other repo can then be MIT.
If the goal is to generate a site from the markdown files, have a structured folder build up from the root of the repo. For instance /assets/images/[area]/[subject]/[filename].
Having a link problem I wanted to make a link in the readme to this file: (changes and suggestions welcome on that too)
I have copied the link on my browser, I have copied the link from inside git, I have copied the structure of the other links in the readme but none of them seem to work. I renamed it with no spaces. I keep getting 404. Feeling dumb, how does one link to a file in the repo?
We may need to consider large file storage. I was playing with copilot asking it to move pictures from documents into an asset library and it said we couldn’t load pictures bigger thank 3.75MB. I have been pulling photos from the maslow website and those are what overloaded it. I will try by hand as I just burned through all of my copilot requests for the month and see what works. This could just be copilot limitations.
Images should not be so big (for web). Currently there are 7 images bigger than 1 MB in the docs (which can shrink a lot). Github file size is about 100Mb without LFS. The largest .STEP file is 5 MB in the maslow4 repo.
Images should not be so big (for web). Currently there are 7 images bigger
than 1 MB in the docs (which can shrink a lot). Github file size is about
100Mb without LFS. The largest .STEP file is 5 MB in the maslow4 repo.
but we are talking about adding a lot of pictures and CAD files to the repo as
we move things from stand-alone web sites to be part of the repo.
From what I’m reading there is not absolute limit to a repo size, but github asks for them to be kept under 5GB. I don’t think it’s a big concern. They just don’t want people using Github to back up big files as free storage (which isn’t what we’re doing)
From what I’m reading there is not absolute limit to a repo size, but github
asks for them to be kept under 5GB. I don’t think it’s a big concern. They
just don’t want people using Github to back up big files as free storage
(which isn’t what we’re doing)
There is an absolute limit on some aspects of git, it uses 32 bit numbers
internally. Initially this meant that a pack file was limited to 2G, but I think
they changed it to 4G (unsigned vs signed numbers)
a total repo can exceed this slightly, but things get wierd when you do so.
So on the user experience end of making the maslow world work better I’ve finished making a series of library documents with intro text aimed at helping new users understand the basics. The documents may not be perfectly structured but I think they give us a place to start gathering wisdom from the forums in an organized way.
There are library documents for routers. Materials, bits, frames, and software.
Next step is to gather some data in them. My time comes and goes but I’ll start collecting entries in them as I can. If anyone has bits of time where you can add something that helped you get started with Maslow it will be cool to learn more about what people use and their experience. If you see ways to improve the intro texts please do. I know I have been missing typos (no spell check) But I figure even imperfect might help some people get started.
I am new to Github but I also tried to write a document to help people start adding to the user documents, It could probably be made better by people with more experience. I wrote it for the web interface first as that is universally accessible. We could add sections for the Apps and for terminal.
All of the library documents are currently in the docs directory in the maslow github.
This is looking fantastic! Thank you for taking that on.
I will work on removing the now duplicate pages from the website and pointing folks to the pages on GitHub to make sure everyone sees the versions which are editable
This is looking fantastic! Thank you for taking that on.
I will work on removing the now duplicate pages from the website and pointing folks to the pages on GitHub to make sure everyone sees the versions which are editable
I really hate having links start to fail. Is there any way that we can setup a
script that will publish the pages from git to the website?
This is looking fantastic! Thank you for taking that on.
I will work on removing the now duplicate pages from the website and
pointing folks to the pages on GitHub to make sure everyone sees the
versions which are editable
I really hate having links start to fail. Is there any way that we can setup
a script that will publish the pages from git to the website?