Release Printrun 2.0.0

[rockstorm101]

Now that #928, #1171 have been dealt with and Windows side has been revamped (many thanks @DivingDuck) I believe we are in shape for finally releasing 2.0.0. Up for debate of course, please speak up if you know any show-stoppers.

Two things I can think of that'd be nice to do before releasing:

• Test and confirm macOS binaries work as expected
• Revisit Windows installation instructions and update (if required)

--
Fixes #1305
Fixes #1296
Fixes #1295
Fixes #1252

[hroncok]

I guess now is better than never.

[DivingDuck]

The Windows instruction need some correction.

Python 3.10 instead of 3.6,
We have now a batch file called release_windows.bat (includes as well the instruction how to use the batch) that can be used via CMD or PowerShell to automatically generate the virtual environment and compile / build Pronterface.exe and the command line version Pronsole.exe in one step.

Fixes: #1252

[rockstorm101]

The Windows instruction need some correction.

Thanks, please go ahead and update the README with the new instructions. You know better than anyone how that works.

[volconst]

I have no objections to release, but do not follow the changes.

[DivingDuck]

#1309 includes the update for readme.md and release_windows.bat (instruction changes).

I made yesterday evening a successful print with the new artifact file from here. Lets make a new release.

[DivingDuck]

Finally done, yay. Huge thanks to all.

[DivingDuck]

@rockstorm101, @kliment
Today I rebuild the master templates for translation based on actual file status with pygettext for those who want to update their translations. Thought, it will be a good idea to have that also in line with the actual version.
In addition I updated the German translation based on the new templates.
Pull request #1311

[rockstorm101]

Hi all,

• @DivingDuck I added a summary of your changes, please have a look and see if you are happy.
• @hroncok are you happy that I addressed your comments? Would you like to add/modify anything else?

[rockstorm101]

Hi @a2k-hanlon, could you please check the macOS binaries produced by the current workflow and see if they work as expected?

[a2k-hanlon]

@rockstorm101 I have an Intel-based Mac (not Apple Silicon-based) running macOS 10.15.7 (Catalina), which is several major versions behind the latest, 13.2.1, as well as the version GitHub is currently using as the default macOS, 12 (Monterey). The current GitHub workflow-built binary crashes at startup on my machine due to what looks like a dynamic library incompatibility (error output below if you're interested), but that is understandable and doesn't surprise me at all since this binary is being built on a newer major macOS version.

I can't update my own machine to macOS 12 unfortunately, but I could try to find a friend with a more up to date Mac in the next day or two to give the GitHub workflow built binary a try for us.

For now, I did a local build of this PR branch with the same procedure as the GitHub workflow on python 3.10, and up to date dependencies, and that does run successfully on my machine. If you would like to include a build for macOS version 10.15 in the release, I can share the binary I built.

Error output from running the GitHub-built binary on my machine:

2023-02-16 02:01:06.000 pronterface[21557:1320281] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to (null)
[21558] Error loading Python lib '/var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib': dlopen: dlopen(/var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib, 10): Symbol not found: _preadv
  Referenced from: /var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib (which was built for Mac OS X 11.7)
  Expected in: /usr/lib/libSystem.B.dylib
 in /var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib

[hroncok]

Food for thought: Isn't the number of changes between the latest rc and this final release a little bit too much?

[DivingDuck]

Only a loud thinking...
In case it makes sense to support more than one macOS version and it is "only" a question of the workflow we can do different workflows for macOS. Up to now there are 3 runners available. (https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners)
The big question is, is there anyone available and willing to help and test the different versions. I can duplicate the workflows but I can't test them as I'm not a macOS user nor having access to those hardware.
And of cause, @kliment should willing to support this too.

[DivingDuck]

@hroncok,
It took 2 years to be at this point. And it feels like a never ending story. It is maybe easier to release a new version if we find something that need to be fixed.

Last time I thought about it I got mixed feelings as I was one of the requester for a new release candidate and after that the project was more or less on hold. :)

From the Windows perspective of Pronterface I think we have actual a better code as before. For Pronsole the user can compile the binaries manually within the release_windows.bat script. There I fond only two points that needs a bit rework. The stand alone program should not try to load custom button entries from the config file and the second point is that Pronsole should show all temperature values of a connected printer (for printer with more then one extruder and bed). Both do not harm the functionality for now. This is why I did not add the automated building via workflow now. This can be done in an future release.

[hroncok]

I see your point. It just feels wrong, but maybe it's the pragmatic thing to do anyway.

[DivingDuck]

I see your point too as Linux is a beast too with all the different distro version's and not to mention the macOS part as I just recognize again.

[rockstorm101]

First, thanks a lot @a2k-hanlon for your detailed test. Much appreciated.

Food for thought: Isn't the number of changes between the latest rc and this final release a little bit too much?

I agree I guess, but we are where we are.

It's taken more than 2 years for this next release, I see no issue with waiting just one more week :P. Or did I miss the point of the discussion here?

Could we not simply add two more macOS runners to the current workflow? (from @a2k-hanlon's comment I'm assuming Python 3.10 is available on all of them). Something like:

-        os: [macos-latest]
+        os: [macos-10.15, macos-11, macos-12]

I'd rather provide only the macOS 10.15 binary, if that's the only one we can test, than blindly provide untested stuff. But before that, there might be other people to ask for help. I'm I right in thinking that the binary from 10.15 won't work on 12? Please forgive my ignorance here.

[DivingDuck]

@rockstorm101,
ups, my conversation was meant as a exchange of thoughts. Not meant as criticism from my side, sorry if anyone felt this. A new release takes as long as it need.

Regarding the workflow, this might be possible. It looks like it needs to be changed for both buildpackage-mac.yml and pypi-manylinux.yml.

[rockstorm101]

Not meant as criticism from my side

No worries, no offense taken.

it needs to be changed for both buildpackage-mac.yml and pypi-manylinux.yml

Agreed, happy with that.

[rockstorm101]

I'll send a PR with those changes later today if no body beats me to it. Let's see if we can find beta-testers for them.

[ascheucher]

@rockstorm101 I have an Intel-based Mac (not Apple Silicon-based) running macOS 10.15.7 (Catalina), which is several major versions behind the latest, 13.2.1, as well as the version GitHub is currently using as the default macOS, 12 (Monterey). The current GitHub workflow-built binary crashes at startup on my machine due to what looks like a dynamic library incompatibility (error output below if you're interested), but that is understandable and doesn't surprise me at all since this binary is being built on a newer major macOS version.

I can't update my own machine to macOS 12 unfortunately, but I could try to find a friend with a more up to date Mac in the next day or two to give the GitHub workflow built binary a try for us.

For now, I did a local build of this PR branch with the same procedure as the GitHub workflow on python 3.10, and up to date dependencies, and that does run successfully on my machine. If you would like to include a build for macOS version 10.15 in the release, I can share the binary I built.

Error output from running the GitHub-built binary on my machine:

2023-02-16 02:01:06.000 pronterface[21557:1320281] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to (null)
[21558] Error loading Python lib '/var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib': dlopen: dlopen(/var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib, 10): Symbol not found: _preadv
  Referenced from: /var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib (which was built for Mac OS X 11.7)
  Expected in: /usr/lib/libSystem.B.dylib
 in /var/folders/rd/snnr5ymj3y58vljd921_rfcc0000gn/T/_MEIkPuSzN/libpython3.10.dylib

Just a lurker here. In case you are looking for an easy way to test on different Mac OS X versions, you could take a look at Proxmox VMs. Nick Sherlock has a nice HOWTO to create them.

[a2k-hanlon]

To follow up, I wasn't able to find anyone with appropriate Macs to test drive builds on, sorry.

Thanks for the suggestion @ascheucher. I'm not in a position to try running a VM on my computer right now but someone else is welcome to take a crack at it.

[neofelis2X]

Hi, I have just tested the latest macOS runners on my Macbook running macOS 12.6.3.
Pronterface starts, but takes kinda long to open, about 15 seconds. It seems to crash on the first attempt, and finally opens after a while. Once opened, it works fine. All three runners (12,11,10.15) show the same behaviour.

Additionally i get this error message when it opens:

I'm using an older release of 2.0.0rc8 (Feb21) on my mac. It also takes about 15s to open, but doesn't show the error message. Further, the interface of this older version seems to have less problems than the latest build. Looks to me as if the dark mode is a bit off. These screenshots may explain what i mean:

Latest mac build

Older mac build of February 2021

I hope this helps. If I find some time I can test on an up-to-date M2 macbook in the next days.

[DivingDuck]

Hi @neofelis2X,
Thanks for testing. Yes, please test for M2 as well.

The language issue is kind of a expected information as the combination of English-Austria looks for me not as a correct combination.

[rockstorm101]

Hi, I have just tested the latest macOS runners on my Macbook running macOS 12.6.3.

Can't thank you enough for that. Much appreciated.

Additionally i get this error message when it opens:

Do you see any additional hints as of what is causing the error if you launch pronterface from the terminal? Do you get this same error on all versions? (I presume "yes" or "irrelevant", but just in case)

I cannot reproduce the dark theme issue on my Linux box. This is what mine looks like on latest commit:

[DivingDuck]

On Windows I can see similar effects with System color settings and high contrast activated. Some of the color schemes are looking as well not good up to not readable (like the temperature text line below the gauges or colored custom buttons). Maybe it is worth to check and modify those settings. Pronterface don't have a own dark mode setup.

[neofelis2X]

The language issue is kind of a expected information as the combination of English-Austria looks for me not as a correct combination.

Yes, this is definitely something specific to my machine. However, with the Feb21 release, this message does not appear.

Apparently pronterface reads for some reason the 'AppleLocale' value. I don't know why it needs to do that, but it might be better of with the first entry of 'AppleLanguages'. Terminal 'defaults read -g' on my system gives:
... AppleLanguages = ( "en-GB", "de-AT" ); AppleLanguagesDidMigrate = "12.6.3"; AppleLanguagesSchemaVersion = 2000; AppleLocale = "en_AT"; AppleMeasurementUnits = Centimeters; ...

Do you see any additional hints as of what is causing the error if you launch pronterface from the terminal? Do you get this same error on all versions? (I presume "yes" or "irrelevant", but just in case)

Yes I get error with all three versions. I launched it from terminal in verbose mode and this message showed up:
2023-03-06 23:38:11.182 pronterface[56040:990520] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/ ... /pronterface.savedState

I then tried to set
defaults write org.python.python ApplePersistenceIgnoreState NO
and
defaults write org.python.python3 ApplePersistenceIgnoreState NO
but it didn't change anything.
I honestly don't know if the "PersistentIgnoreState" is even relevant to any of the issues.

[rockstorm101]

Yes I get error with all three versions. I launched it from terminal in verbose mode and this message showed up:
2023-03-06 23:38:11.182 pronterface[56040:990520] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/ ... /pronterface.savedState

Thanks for this testing again. Given that neither me nor @a2k-hanlon got such error I would think this issue is something specific to your machine. No error trace related to Printrun I mean.

On Windows I can see similar effects with System color settings and high contrast activated. Some of the color schemes are looking as well not good up to not readable (like the temperature text line below the gauges or colored custom buttons). Maybe it is worth to check and modify those settings. Pronterface don't have a own dark mode setup.

Ouch... not ideal. I hate to use my program-manager-hat here but, do you think we can leave this issue for a later point in time? Maybe open an issue with a screenshot of what the problem is and deal with it on a future 2.1 release?

[DivingDuck]

Hi @rockstorm101,
I had the same thought on this.

For translation issue, we should open a separate issue for that. My feeling is, that there is maybe something with the workaround from issue #1154 (utils.py line 47 ff). This need some more investigation as
a) the language combination is wrong,
b) we are using from the coding eg. de-AT only the first part for identifying the language, so it should find a fallback
c) I'm not sure if the warning is from Pronterface, I can't even find any message string for this window. Strange.

For the dark mode issue, yes we should open a separate issue for this for a later investigation/improvements as this is something what is driven by operating system and selected colors (at least for Windows).

So I think we put both to future improvements

[a2k-hanlon]

@neofelis2X Really appreciate your help testing these binaries on appropriate machines!

@rockstorm101:

Given that neither me nor @a2k-hanlon got such error I would think this issue is something specific to your machine. No error trace related to Printrun I mean.

Oh, I have always gotten this ApplePersistenceIgnoreState error with Printrun actually, whether I run it from source or from a built binary on my Mac. I always just ignore it. Not sure if it has an impact or not but at least it hasn't caused any issues that I have picked up on. I haven't ever looked into how to fix it.

Running from source:

2023-03-07 10:01:25.062 Python[1247:11313] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to (null)

Running from binary:

2023-03-07 09:59:33.477 pronterface[1113:10004] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to (null)

[neofelis2X]

Okay, it's probably just some macOS feature that isn't cleaned up properly. Using defaults delete pronterface ApplePersistenceIgnoreState will remove the message, but only until the next time pronterface is opened.

Now I had a chance to do a quick run on an Apple M2 with macOS 13.2.1
Pronterface starts and works basically, almost the same as on Intel macOS 12.6.
Nothing in the printrun.log. But verbose mode gives back this entrys:

FALLBACK (log once): Fallback to SW vertex for line stipple
FALLBACK (log once): Fallback to SW vertex processing, m_disable_code: 2000
FALLBACK (log once): Fallback to SW vertex processing in drawCore, m_disable_code: 2000

And the two temperature gauges are not visible. :-[

[rockstorm101]

Oh, I have always gotten this ApplePersistenceIgnoreState error with Printrun actually, whether I run it from source or from a built binary on my Mac. I always just ignore it.

Ouch hahaha. Interestingly I don't remember seeing any of that when I borrowed an iMac.

Now I had a chance to do a quick run on an Apple M2 with macOS 13.2.1
Pronterface starts and works basically, almost the same as on Intel macOS 12.6.

Well, that's great news, thanks for that. Though it seems we definitely need to look into GUI/theme user experience in the future. Also good to know the same binary seems to work on both architectures.

[rockstorm101]

First, thank you all for pushing this PR forward.

I consider the two tasks preventing this merge now done. If no one argues against it, by the end of the week I'll be merging this PR. So please speak up now or get ready to celebrate a (long overdue) new release!