Yes, PIP is what I’ve done both times I’ve set up the GC dev environment. What I was saying is that the hard part is not installing python components but programming NSIS, via scripts, to do it for you automatically. And for that, there is also plenty of online resources. Its just prioritizing the time, as you know well, is the real bottleneck (The last two weeks I’ve gotten sucked into a bit of inspiration designing lamps for the Maslow to cut instead of learning NSIS )
I documented the install process pretty well so I think I will polish that and post it while I figure out how to fool proof the install.
a question about the merge of this into the main trunk, was that done for just
the firmware or for GC as well (specifically, did the GC changes to compare
config file with firmeware values get merged?)
To be specific, the main trunk was merged into Joshua’s fork, for now (I think that is what you meant to say but just wanted to clarify for the record )
ok, that is the opposite of what I understood him to say recently.
I understood him to say that his changes had been merged into the main trunk, in
which case, we just need to make a release to get holey calibration available to
everyone.
If that has not happened, then we still need someone to do the work of preparing
the PRs to merge this work into the main trunk before it will be available.
I don’t think so. I kindly suggest to reread the previous posts.
For sure both fw and GC of “main trunk” were merged with Joshua’s fork. I put main trunk in quotes because I’m not good with GitHub terminology. To clear up any semantics issues, can you take a look at Joshua’s repository history?
GitHub fork PR history:
What does “ MaslowCNC/Firmware” and “MaslowCNC: Master” mean? I’m confused if this includes the latest commits that are shown as, yet to be released, “v1.27”?
I just noticed that this v1.27 was released before v1.26? @bar I’m confused here.
I did test this latest holey calibration fork this afternoon to verify the latest merges are okay and it went well; it’s pretty slick, actually. I haven’t reported because I might have a left motor gear issue that I’d like to verify. I started the latest forked GC before loading the accompanying fw and was correctly greeted with a message about the fw being v1.25 and GC being 1.26 (since February I’ve been running an older version of Joshua’s fork, which was based on v1.25).
I had a weak moment. I created a pull-request to merge the schmittjoshc/GroundControl and schmittjoshc/Firmware changes into the MaslowCNC/GroundControl and MaslowCNC/Firmware main forks.
While this is a development that is much anticipated, maybe a PR that makes so many changes should wait until after the pending release. That would separate these changes from others and make testing and rollback easier.
It would help in testing if more information about setting up and running the process could be added to the PR.
As you can see from my comment above, I’m trying understand how this works. You can see that Joshua merged the “master” (both fw and GC) into his fork. I have tested the changes he made and it works wonderfully.
Can you help me understand what you meant by “others” (changes) in your above comment?
GC and Firmware presently sit with changes since the last release. Those changes are under test, and the release is likely to be soon.
I’m suggesting that those changes be captured in a release before the Holey PR is merged, so that testing and troubleshooting by users can isolate the changes brought by the Holey PR. Because the CommunityGarden robot runs on a 48-hour cycle that doesn’t consider pending releases, I’d suggest closing the Holey PR and re-opening it after the release.
I too have a PR for Firmware that I’ve been holding for ‘after the next release’, but it should fit with the Holey PR without conflict.
Supporting the community through changes brought by a release is a consideration. The instructions could use some combing-through and clarification. How about adding them to the PR comments and perhaps a Wiki page?
Those are the changes that I mean. The “master” branch incorporates all the changes brought by PRs (requests to pull changes into the master branch), and a “release” captures the state of the master at the moment in its history when it is created.
The version number, e.g. “V1.27” in the Firmware or GC is a manually-maintained method of matching the files between GC and Firmware. In principle, it gets bumped up as the first new PR after a release, to set the number for the next release.
When the trigger gets pulled, the current “master” will become release v1.27, and the PRs will be submitted to bump up the version numbers in GC and Firmware to v1.28.
@Joshua, I would feel comfortable with the PR if I had the custom installer done. If we are going to make this an official Maslow GC and firmware, the installation needs to be bulletproof for all users. As you saw previously, several people had issues with getting it installed on a Windows machine, while they were successful with linux. I’m not sure why there were so many issues installing it on Windows (I’ve done it twice now, on two different Windows machines, its not that hard) but packaging everything in a custom installer is the only way to get around this.
Last night, I spent several hours reading, watching videos and playing with script samples from NSIS. Its definitely doable, just completely new territory for me; I’ll get it done.
EDIT 1: Actually, speaking of “all users”, I’m pretty sure the NSIS installer will only work for Windows. I could be wrong on that but I’d hate to put Maslow GC and Firmware down a road that is harder for some OS’s than others. Am I correct in saying that, as it stands now, “portable” GC can run on any OS without special requirements for any of them?
I think that makes sense. This can wait until after v1.27, particularly as WoodCutter4 is actively doing work.
I’ll have to quote some of the content from this forum. All the information is here. I like to think it is somewhat straight forward; maybe I am just being optimistic. No mother thinks her own baby is ugly.
@WoodCutter4, there is this huge software/science called revision control, which nobody knows about, except those who are in certain technically oriented professions. In order to really wrap your head around it, you need to think about changes, rather than the states of the files through history. Also, merges need to happen both ways. Even though I merged changes into my fork, there are still changes which I have made which need to go back the other way.
Each repo (in git) has branches. Think about it like a tree. The tree has a trunk and branches. “master” is like the trunk of the tree.
You’re a champ!
Not me.
I am a little fuzzy on what the current “official” release of GC does. It is my understanding that there is a *.exe that is downloaded for Windows machines. The *.exe is an installer. Someone has to have created it. Who? It seems like we should be talking with that guy.
Maybe a better question is, why do we need to install the python development environment to run holey calibration (“regular” GC does a lot of wiz-bang stuff without the need to install python etc)?
EDIT: @Joshua, I know there is a technical answer, I guess my question is more along the lines of, is there a way to implement holey calibration without the need for users to install python (for example: moving holey code into the firmware, instead of GC?)?
)
No mother thinks her own baby is ugly.