From Newsgroup: comp.emulators.apple2

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.

Kent
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On 8/20/21 10:29 AM, Kent Dickey wrote:

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.

Yep, Christopher, we can do diffs against code trees to get close -
won't be as convenient as in git, but perfectly serviceable.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <9e7848a3-6da7-4325-b115-31492bb4fc9bn@googlegroups.com>,
Michael AppleWin Debugger Dev <michael.pohoreski@gmail.com> wrote:

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.

Git makes very complex revision control tasks possible. That's great! It
also makes simple, easy things complex. Boo!

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?

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. Note that I
wrote my own revision control system and build system, and so I like it.

Kent
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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:
* git status
* git diff --staged (along with other variations such as: git diff)
* git commit -m "reason foo" (along with variations such as: git commit --amend -m "Corrected foo")
* git add -p
* git push
* git pull
* git log -#
* git show
* git checkout -b foo, and git checkout foo (along with variations such as: git checkout head^2)
* git rebase, or git merge. (If you are the only developer on a repository this isn't even needed.)
These 10 commands will get you 97% coverage for basic version control for git. These two git commands are also done once per repo and will get you 98% coverage for basic version control.
* git clone
* git init
I would add these lesser used commands will get you 99% coverage for basic version control.
* git cherry-pick
* git bisect
A total of 14 commands isn't TOO complex. The "daily 10" is certainly manageable. How many commands does a typical version control system need for daily operations? 5?
The astute reader will notice I have used the qualifier "for basic version control". I would place git usage into 3 main camps: beginner, experienced, advanced. Once you find yourself needing to use git bisect you are starting to move beyond beginner usage IMO.
While you are correct that git has a LOT of power -- you are assuming you need to master 74 commands before you can be productive in git. That is false. Most of that power _isn't_ need to be for basic operations but you will find that as you use git more and more you will start to make [more] use of the more experienced commands such as git reset, git stash, git log --follow -- filename, etc.
Git provides a lot of power because as professional developers there are many scenarios where we need to inspect, modify, search, the history tree. Fortunately most of the power git provides isn't typically needed for day to day operations. The nice thing about git is that it scales from beginner to advanced. You will probably never "outgrow it".
Git _can_ have a difficult learning curve but like when learning any new tool you start small with your usage scenario. As you get more comfortable you expand the tool's usage. Git is like a swiss army knife. Due to its popularity there are hardly any scenarios where developers haven't thought of a solution. I'm NOT saying all those solution are clean, sometimes they are extremely messy, but for usage scenarios git certainly covers a lot of ground!
If you are just a hobbyist programmer then yeah, don't use git (or TortoiseGit, etc.), but at least use SOMETHING for version control such as TortoiseSVN, etc. or whatever you find easy. Not using _any_ version control, even for small/toy programs, is pure madness.
If you are a professional programmer not knowing git in this day and age is almost corporate/career suicide IMHO. There is a reason almost every other version control systems sucks and why git took the world by storm. i.e. I've written code while on an airplane and sync'd it back up once I was back in the office -- git makes this painless. A distributed version control system is a game changer. Even if working alone "git add -p" has _completely_ changed the way I do development. "Commit early, commit often" isn't just a meme. It greatly simplifies regressions.
As a professional games developer there are certain things that are deal breakers:
* Having less than 4 monitors on my primary dev box,
* Not using a distributed version control system, such as git,
* Not using a professional keyboard,
* Not using an ergonomic chair, and
* Not using wrist rests and/or an inclined trackball.
The "pain" isn't worth it. I'm certainly no git expert but looking back at the 7 years I've been using git whatever little bit of pain git introduced the power is completely worth it. "git bisect" is amazing for finding when a bug got introduced, or the reverse, when a feature stopped working. Which reminds me, I still need to upload my git repro. on using git bisect. =P
I'm not saying git is perfect. It is not.
* It is utter garbage for storing binary files -- which massively bloat your repository -- but it wasn't designed for that usage so it somewhat understandable.
* We've discussed the learning curve above.
The point is that while git certainly CAN have a difficult learning curve but it doesn't NEED to have one. Any version control system is going to have a learning curve. Whether that be checkout, lock, checkin, or git push/pull/add/commit it is going to take time to learn good practices. In programming I have two regrets:
* Not using gvim earlier, and
* Not using git earlier (or even just using any version control system for personal projects.)
I can't even begin to think of all the years I wasted using inferior tools. When AppleWin moved off of Berlios to GitHub at the time we didn't know how that would pan out. Looking back that was a REALLY GOOD decision -- it has streamlined our development process. This is important since for everyone on the team AppleWin is "just a hobby". GitHub's PR feature makes merging code quite painless since you can do all of it from the web interface. The ability for users to create issues, have automatic references to commits or other issues, for visual diffs, are really, really nice. If you need to interface with other developers and users, GitHub does a pretty good job of making it easy to manage code.
Not all git tools are the same. Stay away from BitBucket as it lacks basic features that GitHub does. For git clients, I will refrain since everyone has their pet favorite.
Out of all three options:
* Not using any version control
* Using a non-distributed version control, such as TortoiseSVN
* Using a distributed version control, such as git.
The last one, for my needs, wins by a landslide.
"Sales pitch" mode off. /s
m.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Saturday, August 21, 2021 at 9:42:14 PM UTC-7, Kent Dickey wrote:

Git makes very complex revision control tasks possible. That's great! It also makes simple, easy things complex. Boo!

I would argue that it doesn't actually make most *tasks* more complex. The common CVS/Perforce approach is simply more natural: you check out a file like you would a library book, and sometimes you have to merge the contents. Once upon a time, I had a few colleagues who disliked the added complexity in Perforce, preferring the RCS model where you had exclusive access to the files you wanted to modify. Git requires you to learn a more complicated metaphor that allows distributed rather than centralized control of the contents of the tree. Once you get that sorted out, the everyday stuff doesn't feel much different. (Just don't try to change the checkin comment on a change you've pushed.)
The only commands I use frequently are "git commit -a" and "git push", with the occasional "git add" when I create a new file. Once you understand what it's doing under the hood, the question stops being "OMG why does git reset have all these different forms?" and instead becomes "OMG why couldn't they have named these things in less-obscure ways?"
The real advantage for me was less about git per se and more about github (or gitlab). SourceForge is a festing pile of adware stacked on an awkward UI. git*b is actually pleasant to work with. Part of why these sites work is that git distributes the load, so you don't need significant resources server-side. (Google used to have a *massive* Perforce server, for pretty much all company source code. It was slow and created a single point of failure. Last I checked it's all git now.)
github serves the source code (as individual files or tarballs), provides a fast and convenient site for downloading the pre-built binaries, and hosts the web sites: a2ciderpress.com, nulib.com, and 6502bench.com are all hosted there.

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.

I've used "git blame" any number of times to try to figure out when and why I did something. I've also reverted to the repository copy a few times when a change I was experimenting with turned out to be the wrong idea. I've got my personal web site in a local git repository. It's nice to have an "undo" button. :-)
I don't understand why building and revision control are competing for resources.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <f371e249-19b5-440e-b7de-eeb2bc85f2fcn@googlegroups.com>,
Michael AppleWin Debugger Dev <michael.pohoreski@gmail.com> wrote:

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:

[snip]

Again, you make a long argument for a revision control process. I have one.
I just haven't made it public, but a glance at KEGS code shows it's based
on RCS (you can see the revision numbers in the source files). RCS is terrible, but with some wrappers, it's workable. It has some advantages.

You make a case for GitHub (which is a superset of Git, and where many of
its useful features are not really Git at all) for distributed projects.
I would like a browser interface to view the current source files, and sourceforge cannot really do that (well, without me learning something else that looks like GitHub but isn't), but this is not a high priority for me.

Kent
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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

I find Fossil (https://fossil-scm.org/) better designed than Git, and
I prefer it for most of my projects, unless Git is a requirement upon
me. It integrates a web ui, which can be used to do almost anything with
your repository, including viewing each committed source file and, of
course, their history (also in ways that are not possible in, say,
GitHub).

If by "current source files" you mean the current checkout (changes not
yet committed), those are manipulated through the command-line, although `fossil diff --tk`) will open a graphical diff.

Running a self-hosted server is trivial, but one may also rely on (free) third-party services, such as ChiselApp. 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?

For those familiar with Git, I'd recommend this document:

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

Fossil has *lots* of features (among the rest, it can also import from,
and export to, Git), but getting started is relatively easy (see the
Quick Start guide). I'd only mention that it makes it *really* difficult
to lose your data. Whereas in Git you can easily shoot yourself, e.g.,
with something like `git reset --hard`.

Nicola
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <30c9ef1a-7087-422d-a673-2ff036012bf4n@googlegroups.com>,
Michael AppleWin Debugger Dev <michael.pohoreski@gmail.com> wrote:

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.

I am not familiar with your terminology, so I googled it. A 1st gen tool
is "no networking, single file with locks" and an exmaple is RCS; a 2nd gen
VCS is "centralized repo, multi-file, merge before commit" and is CVS/SVN;
and a 3rd gen is "distributed repo, commit before merge" and is Git/Mercurial. My VCS is gen 2.2 or so. It has features Git doesn't have that I find valuable.

These arguments seem to mostly be insulting me. How do you know what I'm doing? 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.

Kent
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Sunday, August 22, 2021 at 9:16:02 PM UTC-7, Michael J. Mahon wrote:

But surely you
can understand how someone developing a personal project could be happy doing things another way that works well for them.

Which is why I've stated TWICE now:

"If a 1st-gen VCS if works for you more power to you"

and

"1. Use what you know. "

Not sure how many more times I need to repeat myself.

m.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Monday, August 23, 2021 at 6:45:07 AM UTC-7, Jeff Blakeney wrote:

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.

Yes, the industry is littered with many bad examples.

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.

No argument here. Too many programmers, especially the younger ones, don't understand KISS. Just because you CAN do something doesn't mean you can. They love to over-engineer the simplest of problems. One of the "best" examples of the Boost's CRC clusterfuck. Over 2,000 LOC when around 25 lines would do the same job.
I've worked on a C++ compiler. We have an old joke:
There are 2 problems with C++
1. It's design
2. It's implementation

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.

Yes. People include a library for one function, which in turn requires another 2 libs which in turn requires a few more libraries.
At my last job we were using jQuery. We did an "audit" of stuff we were _actually_ using. We had originally been using it's animation system but we had our own (since jQuery doesn't provide any WebGL animation). We also were using another function that I ended up re-writing. We ended up saving over 100K of network traffic. Our entire application was smaller then the video library we included.

Windows 10 does SO many stupid things I absolutely dread when people ask
me to help them with a problem with their computer.

For the longest time I flat outright told friends and family: No, I will NOT support Windows 10.

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.

Yes, that's because Microsoft has never really understood the Unix philosophy. Do one thing.

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.

Yes. The levels of abstraction for modern programming is crazy.
Which is why I, ironically, still program in 6502 assembly, to stay sane. One person CAN literally understand the entire system.

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.

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.
Yes, it isn't accident that the industry is littered with crap languages, PHP, Python, Java, Javascript, crap tools, CMake, etc, and LOVES to reinvent technology. The web was reinvented 3 times.

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.

Correct. I usually use this example:
Just because McDonalds serves BILLIONS of food doesn't mean they are serving gourmet food. Quantity != Quality.

The difference is that git was actually designed to solve modern problems:
* Authenticity
* Performance
* Scalability
* Distributed Nature
None of the first gen VCS even come close to making a dent in those.

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.

If a person expects their program stick around it means they will need to accept patches which mean using modern tools which GREATLY simplify this.
I've used my fair share of VCSs over the years. Most of them are garbage. I'm not going to make excuses why someone's archaic VCS is a piece of shit.
m.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Sunday, August 22, 2021 at 1:06:49 PM UTC-7, Nicola wrote:

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?

Moving out of GitHub is an issue I've wondered about. Always good to hear about replacements. Thanks for the link Nicola!

Whereas in Git you can easily shoot yourself, e.g.,
with something like `git reset --hard`.

That is true. That's one of [potential] downsides with git -- it gives you a LOT of power. Thankfully most operations can be undone if you immediately stop and lookup how to undo the last operation.

For "dangerous" operations is always a good idea to test them out on either a small toy project, or a clone, of the repository.

You wouldn't use a power saw/sander/etc. on your _good_ wood without first testing it out on _scrap_ lumber, right? :-)

m.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

Michael AppleWin Debugger Dev <michael.pohoreski@gmail.com> wrote:

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 rCLMahonrCOs LawsrCY:

rCLQuick and dirtyrCY is never quick but always dirty.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Monday, August 23, 2021 at 9:12:00 AM UTC-7, Michael J. Mahon wrote:

Or one of rCLMahonrCOs LawsrCY:

rCLQuick and dirtyrCY is never quick but always dirty.

LOL. So painful but true.
I'm added that to my quotes file (with proper attribution of course.)
m.
--- Synchronet 3.21d-Linux NewsLink 1.2