Code:
fastfetch -c all.jsoncThere are a couple of modules which are disabled on 10.5 as compared to 10.6 due to SDK limitations, but you should have nearly the same picture.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Open-source software currently supported on macOS PowerPC
- Thread starter barracuda156
- WikiPost WikiPost
- Start date
-
- Tags
- opensource powerpc
- Sort by reaction score
- Status
There are a couple of modules which are disabled on 10.5 as compared to 10.6 due to SDK limitations, but you should have nearly the same picture.
This looks interesting. Thanks @barracuda156, I will go for a build of it and see what happens. 10.5.8 Sorbet and Sonoma will be my targets.
BTW, has anyone *already* built this for either Sorbet or Sonoma? Able to share the resulting .app file?
BTW, has anyone *already* built this for either Sorbet or Sonoma? Able to share the resulting .app file?
Some quick feedback from Sonoma: I built step-writer both via MacPorts and via the macos Sonoma native XCode tools. The resultant program behaves the same in both cases - it seems quite buggy. I can't even find a way to make it quit. I have to kill the Terminal session it is in to stop it.
All of this may be because it is not intended for or been tested on Sonoma, or perhaps I am just doing something wrong, but I followed the install instructions and they executed fully and successfully. Then I checked for a MacPorts port of step-writer and there was one there, so I installed that too. It too went in perfectly successfully.
However, neither seems to be very successful at opening any of my files! Here is what I get back from the macos native version when I attempt to open the file remind.rc in my home directory:
I get the same response from the MacPorts version of step-writer as well.
Any thoughts?
All of this may be because it is not intended for or been tested on Sonoma, or perhaps I am just doing something wrong, but I followed the install instructions and they executed fully and successfully. Then I checked for a MacPorts port of step-writer and there was one there, so I installed that too. It too went in perfectly successfully.
However, neither seems to be very successful at opening any of my files! Here is what I get back from the macos native version when I attempt to open the file remind.rc in my home directory:
I get the same response from the MacPorts version of step-writer as well.
Any thoughts?
1. The app isn’t production ready, but upstream is responsive, you could ask questions and report bugs there, it will help everyone.
Perhaps, experience with emacs will be smoother? It builds for powerpc (use emacs-devel port!).
2. I wanted to ask why on earth you build something against `libc++abi` on powerpc, but then saw 2024, so likely it is Sonoma. Well, Sonoma is buggy (I have it myself). The log looks like a definite bug, but I am not sure on which side. Is it reproducible?
3. Doesn’t Control+C work? I often use just that, it is easy LOL
Yes, my results were from Sonoma. I am trying it on Sorbet right now. I will let everyone know when I have results.
Is there any documentation? There doesn't seem to be. Can anyone say what the intended way to quit the application is? None of the keystrokes mentioned by the author seem to do what they are supposed to... but they may be a Sonoma thing. Again, when I get it done on Sorbet Leopard, I will report back.
Is there any documentation? There doesn't seem to be. Can anyone say what the intended way to quit the application is? None of the keystrokes mentioned by the author seem to do what they are supposed to... but they may be a Sonoma thing. Again, when I get it done on Sorbet Leopard, I will report back.
... and it fails both ways on 10.5.9 Sorbet:
1/ On Mac OS X, the configure dies with errors related to needing "cxx_std_14".
2/ On MacPorts, it also fails, citing "Invalid value for compiler.configure" - sounds like a similar issue. The log is attached.
Does this NEED a later compiler than is available for 10.5.9?
1/ On Mac OS X, the configure dies with errors related to needing "cxx_std_14".
2/ On MacPorts, it also fails, citing "Invalid value for compiler.configure" - sounds like a similar issue. The log is attached.
Does this NEED a later compiler than is available for 10.5.9?
I agree the error message is not greatly helpful, but it results from this, I believe: compiler.cxx_standard 2017.
So yes, gcc7 is a no go.
P. S. I have opened a ticket about an error message: https://trac.macports.org/ticket/71342
Last edited:
Thanks for opening the ticket @barracuda156; I had hoped that step-writer might provide the example I have been looking for, but I guess not.
I am updating my own terminal text editor (VE - Visual Editor) and I will target one of its supported environments to Mac OS X 10.5.8/9 (Sorbet) Leopard. Since earlier versions of VE have run under the Mac OS X Terminal, this won't be an issue BUT I have been hoping to make this version quasi-GUI, by having it be able to open a GUI window and then do so it's work within that window, vs. using Terminal as it's window.
It LOOKED like step-writer might do that very thing, and I was hoping to be able to review it's code and follow it's example. Given it's relative youth, it would not yet be too complex.
However... MacVim DOES do this (open a GUI window and then run within it); I may have to review it's source code.Vim is an old, well established product, and thus I have stayed away from using it as an example... the likelihood seems strong that such old code will not be cleanly layered so that I can easily observe the window-related parts vs. the editor-related parts.
Having not able to actually observe step-writer working, I have no idea if it DOES open a GUI window or not, but it was not obvious to me that it did when I quickly browsed through it's source code.
I am updating my own terminal text editor (VE - Visual Editor) and I will target one of its supported environments to Mac OS X 10.5.8/9 (Sorbet) Leopard. Since earlier versions of VE have run under the Mac OS X Terminal, this won't be an issue BUT I have been hoping to make this version quasi-GUI, by having it be able to open a GUI window and then do so it's work within that window, vs. using Terminal as it's window.
It LOOKED like step-writer might do that very thing, and I was hoping to be able to review it's code and follow it's example. Given it's relative youth, it would not yet be too complex.
However... MacVim DOES do this (open a GUI window and then run within it); I may have to review it's source code.Vim is an old, well established product, and thus I have stayed away from using it as an example... the likelihood seems strong that such old code will not be cleanly layered so that I can easily observe the window-related parts vs. the editor-related parts.
Having not able to actually observe step-writer working, I have no idea if it DOES open a GUI window or not, but it was not obvious to me that it did when I quickly browsed through it's source code.
All FTXUI-based apps (caps-log, json-tui, git-tui etc.) run inside your terminal window. They do not open X window or something like that. (Notice, I am saying this from a user side; I did not examine the code, but they do not depend on X11 etc.)
Another similar, perhaps, app is Turbo.
P. S. A lot of modern TUI apps use Go or Rust. Sorry, I cannot fix those, it will take time beyond I have physically available LOL. So I tried to collect whatever apps use C/C++ and actually work. Bugs are everywhere, and some project maintained by one or few folks during coffee-breaks is expected to have them. Modern Apple software is full of bugs, what can we expect )
UPD. Re Turbo, you may want to read through this thread: https://github.com/magiblot/turbo/issues/65
Some points re how to set it up.
Last edited:
Thanks I'll have a look at Turbo. There is also one other port, whose name I noted down somewhere - I will find it - that bills itself as an easy and lightweight GUI framework. I will have to dig it out and have a better look. When I get the name, I will post it here for anyone else who might want such a thing.
On a general note, it may pay off to bring bugs to upstreams, some of them are actually interested to improve their code, so there is an incentive to fix something. Especially when a bug is not exclusive to an exotic platform.
By the way, kakoune should also work. These are not huge projects to build, you could try both and see what suits better.
step-writer: Control+C works perfectly fine, both on my 10.6.8 in a VM and in Sonoma natively.
With files, it seems it can handle some formats but not some other. I have opened an issue for that, you may add your error log there too: https://github.com/BrianAnakPintar/step-writer/issues/5
Last edited:
Could you try building the updated version of QMPlay2 (the one in upstream MacPorts is fine)? There are some significant changes, which at least on 10.6+ fix YouTube browsing and playback from within the app. However, it has not been tried on pre-SL systems.
I can give it a go a little closer to the mid-late December holiday. Apologies, you may have noticed I've not been very active as of late, IRL has gotten very busy with new job and move. I booted up my normal build machine two weeks ago to find yaboot no longer could find my Ubuntu Remix installation and--for whatever reason--my Airport card will no longer obtain an IP address (though it claims it's conneted, just self-assigned IP). I have no idea if these two things are related, any suggestions are more than welcome (admittedly, I've not had much time to troubleshoot, but even assigning a static IP in the correct range won't cut it after multile reboots and I gave up due to time).
Worst case scenario I will move it down close to the router and hardwire it in. Sounds like a good holiday project for me =)
Worst case scenario I will move it down close to the router and hardwire it in. Sounds like a good holiday project for me =)
Regarding MacPorts, does anyone know how to make port skip a package?
I use gcc7 for compiling, but it's an older revision. In the past i edited the Portfile to make it look like the current version, but that doesn't work anymore. I tried "port upgrade outdated and not gcc7" but it doesnt work.
Any help?
I use gcc7 for compiling, but it's an older revision. In the past i edited the Portfile to make it look like the current version, but that doesn't work anymore. I tried "port upgrade outdated and not gcc7" but it doesnt work.
Any help?
I do not know the "right" way to do it, and it is quite frustrating. I think what you want is to edit the Portfile to make it look like the previous version--not the current. In other words, make the Portfile the same version as what you already have installed. If something is getting pulled in as a dependency upgrade, you can use the -n option to upgrade a specific package without upgrading dependencies. But seeing as how you're just generally trying to upgrade outdated, that's more of a workaround.
There is also the -p option but I've been told in multiple channels not do use this. So what I think we all really need is a script that will run and recursively look for build failures, remove the failed port and everything that depends on it from the upgrade tree, and re-start the upgrade. There's maybe better logic for the script, but I haven't thought of one yet. It's the only thing that prevents me from running my setup weekly instead of once every few months due to how manual the upgrade process is.
EDIT: I also recommend upgrading your gcc7 to the latest (gcc14). It requires some fixes that @barracuda156 made, but it works a charm. I'm about to upload my latest builds to my archive, including adding gcc14 if you want to grab it.
There is also the -p option but I've been told in multiple channels not do use this. So what I think we all really need is a script that will run and recursively look for build failures, remove the failed port and everything that depends on it from the upgrade tree, and re-start the upgrade. There's maybe better logic for the script, but I haven't thought of one yet. It's the only thing that prevents me from running my setup weekly instead of once every few months due to how manual the upgrade process is.
EDIT: I also recommend upgrading your gcc7 to the latest (gcc14). It requires some fixes that @barracuda156 made, but it works a charm. I'm about to upload my latest builds to my archive, including adding gcc14 if you want to grab it.
Last edited:
1. Consider not using gcc7. MacPorts finally moved to gcc14, which I have been advocating for ages. That is why editing portfile won’t work.
If you really need to have gcc7-based setup, do the following: fork MacPorts GH repo, find a PR which moved the setup to gcc14 for old systems, revert those commits (if it does not work cleanly, you may need to do it by hand). Then you can edit sources.conf to point to your local copy of forked repo. Make it default, because it has to use modified portgroups, not only ports. But again, most likely this is not what you really need to do in this case.
2. On a general note: as long as one needs an older or just different version of some port (or a new port altogether), use an overlay local repo (doesn’t need to be forked from MacPorts or use GH at all) and set it in sources.conf above the default one. Then everything which is in that repo will have prevalence over “official” ports.
This won’t work with portgroups, since unfortunately MacPorts cannot handle overrides for them, so one needs either to replace portgroups manually after every port sync or install a distribution of MacPorts where this issue is fixed and local portgroups are honored (either MacStrop or my PPCPorts).
I think I misunderstood what @Nightphase was trying to do; sounds like you want to keep your version of gcc7. I thought you were having issues building other ports with gcc7 and wanted to skip the failed ports. I just put gcc14.2 up on my repo if you want to grab it, you won't have to spend a day building it, just grab and go.
That said, @barracuda156 how do you handle build failures for a port? Are you spending hands-on-keyboard time fixing each one that fails in an upgrade or have you worked out some magic to skip a failed build when doing an "upgrade outdated"?
That said, @barracuda156 how do you handle build failures for a port? Are you spending hands-on-keyboard time fixing each one that fails in an upgrade or have you worked out some magic to skip a failed build when doing an "upgrade outdated"?
That is why little has been done with regard to some heavy stuff like GHC or Qt, since I spent two years fixing ports which everyone else kept breaking on a daily basis LOL
But otherwise, the solution is to have a local overlay repository with whichever ports you need to customize or add. Then you are the one who decides when to upgrade them.