I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.11. The Mac executable should run on 10.13 or later. It's also a universal app, so it runs native on Apple M1 silicon. There's a Linux executable as well.
KEGS v1.11 is available at: http://kegs.sourceforge.net
On 8/19/2021 6:08 PM, Kent Dickey wrote:
I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.11. >> The Mac executable should run on 10.13 or later. It's also a universal app, >> so it runs native on Apple M1 silicon. There's a Linux executable as well. >>
KEGS v1.11 is available at: http://kegs.sourceforge.net
Kent,
Is it possible to start using source code management? I'd like to track
some the 1.x changes to the KEGS core in order to update GSport. Most if
not all the changes made thus far should merge into GSport (which mostly
has bug fixes to the v0.91 core and emulated I/O device additions).
In article <sfn3om$jfh$1@dont-email.me>,
Christopher G. Mason <cgm1@my-deja.com> wrote:
On 8/19/2021 6:08 PM, Kent Dickey wrote:
I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.11. >>> The Mac executable should run on 10.13 or later. It's also a universal app,
so it runs native on Apple M1 silicon. There's a Linux executable as well. >>>
KEGS v1.11 is available at: http://kegs.sourceforge.net
Kent,
Is it possible to start using source code management? I'd like to track
some the 1.x changes to the KEGS core in order to update GSport. Most if
not all the changes made thus far should merge into GSport (which mostly
has bug fixes to the v0.91 core and emulated I/O device additions).
I have no plans to start using Git. KEGS source arrangement is pretty easy to drop into any source code system.
I have no plans to start using Git. KEGS source arrangement is pretty easy to drop into any source code system.
On Friday, August 20, 2021 at 7:29:38 AM UTC-7, Kent Dickey wrote:
I have no plans to start using Git. KEGS source arrangement is pretty easy >> to drop into any source code system.
That's a shame to hear. Obviously the final decision is yours but I
have found git, and GitHub, to be a complete game changer -- managing PR >(pull requests) via GitHub is almost trivial. Visual diffs are
automated.
I would highly recommend taking the time to learn git if you haven't
already and are a professional programmer. I found the basics of git
trivial to learn but others say it is difficult. YMMV. Once you have a
good cheat sheet it becomes much easier to understand the differences
between stash, workspace, index, local repository, upstream.
**cough**
https://github.com/Michaelangel007/git_cheat_sheet
m.
You're not the first person to try to say Git is great, without being able to express that in a convincing way. How is a chart of 74 commands simple?
Git makes very complex revision control tasks possible. That's great! It also makes simple, easy things complex. Boo!
My build environment is structured around building fast and easily. Revision control is a distant thought--it's nice for diffs and for a written history of the code, but it's much less important than building.
On Saturday, August 21, 2021 at 9:42:14 PM UTC-7, Kent Dickey wrote:
You're not the first person to try to say Git is great, without being able >> to express that in a convincing way. How is a chart of 74 commands simple?
You're assuming that all 74 commands are used/needed in daily
operations. They are not. I have over 200+ git repos and if I were
sort the git commands by my usage over the last 7 years of using git I
would hazard a guess at placing the most frequently used in this order:
RCS is terrible, but with some wrappers, it's workable. It has some advantages.
I would like a browser interface to view the current source files
On Sunday, August 22, 2021 at 9:43:37 AM UTC-7, Kent Dickey wrote:
I would like a browser interface to view the current source files
On Sunday, August 22, 2021 at 9:43:37 AM UTC-7, Kent Dickey wrote:
RCS is terrible, but with some wrappers, it's workable. It has some >advantages.
If a 1st-gen VCS if works for you more power to you but there are
reasons the world has switched to 3rd-gen VCSs even for single developer >projects.
RCS is archaic garbage. In the ~40 years since 1982 there have been >significant developments to version control.
I would like a browser interface to view the current source files
Any modern repo hosting site will do that.
m.
The Apple II is archaic garbage, yet here we are emulating it.
Vi is archaic garbage, and I happily use it every day.
These arguments seem to mostly be insulting me.
You know, it's possible to write a version control system that
worked exactly like Git in terms of interface and commands, and yet had RCS underneath it (hidden in the .git directories).
And wasn't CVS built on top of RCS at the file level, too?
CVS's problems were not RCS, they were in
how they used RCS and it's general overall features.
On Sunday, August 22, 2021 at 2:56:17 PM UTC-7, Kent Dickey wrote:
The Apple II is archaic garbage, yet here we are emulating it.
Apples and Oranges comparison.
First, IF that was true we wouldn't be writing emulators for it.
Second, the design of the Apple 2 is pretty damn elegant.
Third, while the Apple 2 is primitive it STILL has better input latency
then many modern systems. Not bad for an "archaic system"! -- https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie
Fourth, there are STILL much software (such as many original games) on
these old systems that are not available on a modern system.
Sure, from a performance POV old 8-bit computers are "archaic" but that doesn't make them garbage. You are not going to be editing 4K video on
an Apple 2. The hardware can only do what the hardware can do.
A VCS has ONE job: To keep an accurate history of changes.
The design of RCS is archaic garbage because it doesn't meet the needs of modern developers. There is a reason git and Perforce have become de
facto standards amongst professionals -- the biggest being scalability.
Git makes common operations, such as branching and checkout, trivial. RCS does not.
Vi is archaic garbage, and I happily use it every day.
No. It's design of using modes is far superior for many tasks -- which makes it trivial to repeat almost any command. Something completely lost
on modern text editors. While Vi is getting a little long in the tooth
Vim builds upon that good foundation.
These arguments seem to mostly be insulting me.
Did you COMPLETELY miss the part where I said?
"If a 1st-gen VCS if works for you more power to you"
You know, it's possible to write a version control system that
worked exactly like Git in terms of interface and commands, and yet had RCS >> underneath it (hidden in the .git directories).
BWAHAHA.
1. You are not understanding the features of a distributed VCS let alone modern work-flow.
2. That would STILL be a garbage design AND implementation -- things such
as performance, scalability, and size (of the repro.) matter. For
example, the Windows source code is 450 GB. That is just to checkout "head". Good LUCK trying to have RCS dealing with THAT.
Why is that a problem? With RCS the older the checkout revision the
longer the checkout takes since an increasing number of deltas need to be calculated. In git this is O(1) since it is a matter of just updating a pointer. While this time may not matter for small repos, for large repos this certainly does matter. Why not just use a VCS that is designed
better right from the start to handle scalability and won't run into performance issues until LONG down the road?
And wasn't CVS built on top of RCS at the file level, too?
When you build upon a crap foundation you end with a shaky building --
which is all the more reason to avoid CVS as well.
CVS's problems were not RCS, they were in
how they used RCS and it's general overall features.
Doesn't change the fact that CVS is garbage too. Did they _finally_ fix
the inability to rename a file AND keep the revision history? Can you rename a directory AND keep the revision history? The CVS FAQ says this isn't possible. This is idiotic. The _contents_ of the file didn't change, only the meta-data did. What the hell is the point of using a (broken) VCS if it can't even track basic changes???
The problem with CVS, and RCS, and why their design is fundamentally
broken is that history is tracked on a per-file basis. History of people using VCSs has shown that this is bad design. Modern VCSs take a
snapshot of the entire project which is the revision.
Linus (of Linux fame) has discussed to death some of the problems with
CVS when he gave his git talk to google:
Tech Talk: Linus Torvalds on git
https://www.youtube.com/watch?v=4XpnKHJAok8
The world has moved on from crap like RCS and CVS for over 15+ years now. Not just for 1 reason but for MANY reasons: Functionality, Performance, Security, Size, etc.
If you want to keep using an archaic VCS such as RCS then no one is going
to stop you -- but you are selling yourself extremely short by not using
a more modern VCS. Almost no one is going to submit RCS patches to you. With git it is _almost_ trivial to merge a PR. I have submitted a few patches to various repros that I never would have unless git had made it easy:
* git clone foo
* edit file
* git add -p bar
* git commit "Fixed bar"
* git push
* Hit the PR button on GitHub
Compared to other VCSs git isn't THAT hard to learn. It doesn't suffer
from the same dumbs designs that others do. As they say hindsight is
20/20 and git has benefitted very much from that. Git, ironically, literally owes its existence to the closed source proprietary BitKeeper.
EVERY VCS sucks. Knowing what they are good at, and what they are bad
at, helps you pick and use tools that are easier, faster, etc.
Personally I think Vim sucks too. I find it utterly retarded that in
2021 you STILL can't bind CAPS, Ctrl-1, Ctrl-Shift-1 because it is stuck
in 1970's thinking. However, I find Vim sucks _least_ compared to other editors. Ditto for git. Git's lack of handling binary files without
blowing up the repository is a major deal breaker with games. For the longest time git couldn't handle large files so you have hacks/extensions like Git LFS (Large File Storage). But for what git was designed to do
it does a damn good job, far, far better then other VCSs.
If you feel insulted that I called RCS "archaic garbage" then you would
know it is not just my opinion that RCS and CVS are hot garbage. It
would behoove you to learn WHY many professional developers have switched
to git and Perforce. (Having used Perforce I'm not a fan of it either --
it feels extremely clunky.) I'd rather listen to the guy who not only
made his own Operating System, has it running on 100% of the Top 500 supercomputers in the world, along with over 2 Billion mobile devices,
AND wrote a better designed VCS that puts most of them to shame because, chances are, he is smarter than me then to some "nobody" that wrote a
piece of software decades ago that almost NO ONE uses anymore because the broken design never got tossed out, nor did it kept evolving to deal with handling modern problems.
People have used Vi to edit LARGE text files over dial-up. THAT is a
good design that stands up reasonably well today -- not archaic --
because it is performant.
RCS / CVS is like having a hammer. You may think it is OK if all you
need to do pound a few nails in but when you need to eventually drill
holes, use a screwdriver for screws (go figure), etc. you will want to
expand the proverbial toolbox with power tools that can not scale up but scale down as well. RCS / CVS doesn't scale up hence why it is a
complete joke amongst professional developers.
To summarize:
1. Use what you know. Take the blue pill and remain happy in your ignorance.
2. Or take the red pill and don't be surprised when people offer better alternatives based on years of experience of having attempted to solve
the same problems year in, year out.
We now return to your favorite emulator discussion ...
m.
But surely you
can understand how someone developing a personal project could be happy
doing things another way that works well for them.
Michael, you keep saying that one of the best reasons to use the things
you are promoting are because they have been adopted by many modern, professional programmers. Just to let you know, I gave up on doing programming for a living because the entire industry went in, what I consider to be, really stupid directions.
The popular programming languages I find are designed to create job
security by purposely making it difficult to understand the code. This
has the side effect of making it difficult, at least for me, to be able
to create code in that language.
Also, I'm constantly baffled by the
size of many modern applications so the modern languages seem to add a
lot of bloat to the executable.
Windows 10 does SO many stupid things I absolutely dread when people ask
me to help them with a problem with their computer.
I'm sure the source
for it is 450 GB because it isn't just an operating system. It is also
a collection of programs that I use less than 1% of and I'm sure it
makes up well over 50% of the Windows install on my computer.
The whole development cycle model nowadays is also annoying. Let's
write a program, maybe do some basic testing, release it, then keep
putting out updates every week to fix all the bugs that are found by the public using it.
My brother is still programming for a living and he keeps telling me
about his frustrations with dealing with some of the tools that he has
to use. This is partly because he is involved in larger projects with multiple programmers and some group of people decide how they are going
to do things and invariably pick poor options that cause him to have to
do extra work.
So, just because something is in wide spread use doesn't mean that it is good or is the only way things should be done. Many modern programmers
are using certain tools simply because it is mandated by their employers
and the decisions to use those specific tools was made by others who may
not know anything about programming.
We get it, you like Git and you promoted it but after someone tells you
that they aren't interested in using it, you really shouldn't keep
trying to push it on them.
I find Fossil (https://fossil-scm.org/) better designed than Git, and
...
In any case, you keep control
over *all* of your data, including tickets and discussions. How do you
move away from GitHub or GitLab without losing such information?
Whereas in Git you can easily shoot yourself, e.g.,
with something like `git reset --hard`.
I've always reminded of Murphy's Computer Law:
MESKIMEN'S LAW
There's never time to do it right, but always time to do it over.
Or one of “Mahon’s Laws”:
“Quick and dirty” is never quick but always dirty.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 468 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 18:26:19 |
| Calls: | 9,440 |
| Calls today: | 3 |
| Files: | 13,594 |
| Messages: | 6,109,727 |