Merge 1.7.0 from upstream

[desertkun]

In this change, recent work from upstream git://git.code.sf.net/p/fuse-emulator/fuse has been merged in.

@morozov please support testing thig change.

Along with the change, I plan to change the versioning scheme to <upstream version>-fusex-<fusex changes version>, currently 1.7.0-fusex-0.1

[morozov]

A few thoughts on the merge itself before testing.

1. It doesn't look like a real merge

The first commit of the PR has a single parent, while a merge one would have two (the FuseX tip and the upstream fuse-1.7.0 tag). That would:

1. Preserve both commit histories
2. Establish a real merge base for all future syncs
3. Allow to review the 3-way diff between the HEAD, upstream and base and see which changes come from where.

The way to do it:

git checkout -b merge/fuse-1.7.0 master
git fetch git://git.code.sf.net/p/fuse-emulator/fuse --tags
git merge fuse-1.7.0
# resolve conflicts, then:
git add .
git commit
# apply fixes and removal of irrelevant workflows on top

There are 4 conflicts with straightforward resolutions. I'd put the necessary minimum of additional changes into the merge commit itself — it would communicate the intent clearly: these changes don't come from upstream or from the fork's own history, but they are needed to make them work together.

2. Non-macOS code is selectively updated

The PR updates the build system (configure.ac, Makefile.am) to reflect upstream 1.7.0, but leaves the corresponding source trees at their pre-1.7.0 state — GTK, SDL, etc.

I think FuseX should either drop the unused code entirely or keep merging the patches from upstream. The latter is easier because once you merge them and don't touch this code, there will be no future Git conflicts by definition. If you delete them, there will be permanent conflicts (the upstream makes changes ↔ the fork has deleted these files).

3. Some upstream bug fixes were dropped

A handful of upstream 1.7.0 fixes touch code that is active in FuseX builds (e.g. networking, the debugger disassembler, display rendering). It would make sense to keep them at lets to have the right to carry the upstream vesion (1.7.0-fusex...).

Let me know if I should try merging myself.

[desertkun]

Yeah, you're right my git client appears to messed up the merge process. Let me redo it.

[desertkun]

As per non-macos use, I am considering ditching fuse repository in this organization, renaming this repository into fusex, and trying to maintain it for both mac and windows.

[desertkun]

Okay I have restored merge history. Opted to resolve conflicts upstream way, and then just replaced the repo with local copy, making a commit that takes those changes back, most of which are about spectranet anyways.

Could you please elaborate on "Some upstream bug fixes were dropped", which ones?

[morozov]

Could you please elaborate on "Some upstream bug fixes were dropped", which ones?

One example: peripherals/nic/w5100_socket.c (upstream commit d936529).

Two lines are present in fuse-1.7.0 but were absent from the original version of this PR:

// in w5100_socket_process_accept():
socket->ir |= 1 << 0;  /* CON interrupt */

// in w5100_socket_process_read(), on EOF:
socket->ir |= 1 << 1;  /* DISCON interrupt */

Another example: debugger/disassemble.c — upstream 1.7.0 fixed the DDFD CB prefix disassembler for BIT/RES/SET instructions. At the time of review, these changes were not in the PR:

The PR had the old code at lines 608 and 619:

https://github.com/speccytools/fuse-for-macosx/blob/dadc1f7998de7a0bba9edcfec8ad132f0cdf6810/debugger/disassemble.c#L608

https://github.com/speccytools/fuse-for-macosx/blob/dadc1f7998de7a0bba9edcfec8ad132f0cdf6810/debugger/disassemble.c#L619

Upstream 1.7.0 has the corrected versions at the same lines:

https://github.com/speccytools/fuse-for-macosx/blob/d30cd156d1f220103f5ea1176523c497be2bea59/debugger/disassemble.c#L608

https://github.com/speccytools/fuse-for-macosx/blob/d30cd156d1f220103f5ea1176523c497be2bea59/debugger/disassemble.c#L619

[...] and then just replaced the repo with local copy

Doesn't this invalidate the merge? It retains the commit history but discards the change and introduces potential new conflicts (similar to deletion of unused code, if we revert upstream changes and they make new changes, we won't be able to accept them). I can review the post-merge commit in detail closer to the weekend.

[desertkun]

I think I have nailed it this time.

I kept original (to the mac version) settings scheme

I am also considering to turn off spectranet by default, help me here. I want it turned on because I plan to expose users who never used Fuse before into the use case with spectranet, so I want them have to do less clicks. Produce separate builds?

[desertkun]

@morozov have you had the time to look into this latest change? Thanks.

[morozov]

Not yet, sorry. But I plan to in the next two days. So far, my immediate concern is the “Post-merge patches (conflict resolution)” commit (f639e87). I don't believe that there are +9,365/-2,164 lines of conflicts with the upstream. I want to perform this merge myself and see what's going on.

The other caveat that I didn't think of is that besides the main repo, we may need to merge the changes from the submodules — this is besides and before updating the pointers in the main repo.

[desertkun]

I already did update libspectrum library submodule. There it was straightforward.

[morozov]

I worked through this end-to-end on a reference branch (merge/fuse-1.7.0) that builds cleanly from a fresh clone. Three categories of issue, then the missing steps, then how we got there.

What's wrong

1. Doesn't build from a clean clone. 'libspectrum_snap_uspeech_active' undeclared in 3rdparty/libspectrum/{z80,sna,szx,snapshot}.c. Upstream Fuse 07d6bba5 builds fine standalone against upstream libspectrum master, so the regression is purely in fork-side integration.
2. Same merge antipattern as the prior attempts. For each conflicted file, the merge commit picked one parent verbatim and f639e87b patches the other side back in. Example: peripherals/spectranet.c is 1114→603→1137 lines across master → merge commit → f639e87b. Git can't relate the post-merge additions to either parent, so future upstream syncs will re-conflict on these files indefinitely.
3. Subtle refcount bug in peripherals/nic/w5100.c (see inline).

Steps that are missing

This branch bumps 3rdparty/libspectrum to e4a2d6e1, but the bump in this fork is not a one-file operation. The following are also required for the build to work and aren't here:

1. Regenerate fusepb/libspectrum.h against the bumped libspectrum's libspectrum.h.in + accessor txt files (via fusepb/generate.pl).
2. Update fusepb/FuseX.xcodeproj:
   • Update the path of the five sound peripherals upstream moved into peripherals/sound/ (ay, covox, fuller, melodik, specdrum).
   • Add the two new sound peripherals upstream introduced (sp0256, uspeech).
   • Add dsnap.c, wav_macos.c, wav_internals.h (new libspectrum files used by upstream Fuse).
   • Add AudioToolbox.framework to the FuseX target (for the wav_macos backend; matches upstream macOS CI's --without-libaudiofile choice).
3. Commit in 3rdparty/FuseImporter: regenerate its tracked libspectrum.h, wire dsnap.c + wav_macos.c into the Xcode project, add AudioToolbox.framework. Then bump the fusex submodule pointer to it. (Also: latent bug in its generate.pl — missing #define WIN32_DLL in the LIBSPECTRUM_DEFINE_TYPES handler — surfaces on regen and needs fixing.)
4. Commit in 3rdparty/FuseGenerator: same as FuseImporter, but for both Quick Look targets (Preview and Thumbnail).
5. Resolve the six text conflicts as 3-way merges in the merge commit itself, not as "take one side, patch other in follow-up". Conflicts: memory_pages.c, peripherals/spectranet.{c,h}, settings.dat, settings.pl, ui/sdl/sdlui.c.

The libspectrum bump itself cannot be a separate pre-merge commit because the new libspectrum isn't backward-compatible with the fork's pre-merge code (signature changes in libspectrum_creator_*, etc.) — it has to travel inside the merge commit alongside the changes that need its new APIs.

Proposed replacement

I'd like to propose merge/fuse-1.7.0 as the replacement for this PR so that you don't have to redo the same work. It's a single atomic merge commit on top of master with the steps above bundled in, and it builds cleanly from a fresh clone.

It depends on companion branches in the dependent submodule repos (regenerated libspectrum.h, Xcode wiring for new libspectrum source files + AudioToolbox.framework, the WIN32_DLL fix in FuseImporter's generate.pl):

• morozov/fuse-generator @ merge/fuse-1.7.0
• morozov/fuse-importer @ merge/fuse-1.7.0

Things on this branch that don't belong in the merge but are otherwise fine

A few of your changes here are deliberate fork-side decisions that just shouldn't ride inside the merge commit. Cleanest as separate commits on top of the merge:

• Versioning scheme bump (fusepb/English.lproj/InfoPlist.strings: CFBundleShortVersionString from "1.7.1" to "1.7.0-fusex-0.1") — exactly the scheme you described in the PR description. Belongs to a separate commit after the merge, not here.
• Removing GitHub Actions workflows (.github/workflows/*, 0f6feb66) — already its own commit here, but worth narrowing rather than blanket-removing. Dropping the Linux and Wii workflows makes sense, but the macOS and Windows ones build the platforms this fork does target. Unless they're utterly broken, removing them is counterproductive — those are exactly the pipelines that catch breakage like what we hit in this PR. Suggestion: keep build_macos*.yml, build_windows*.yml, build_libspectrum_macos_sub.yml, build_libspectrum_windows_sub.yml, windows_release.yml, test_release*.yml; drop the Linux/Wii ones.
• Root settings-header.pl parser update for the 6-field format — forward-looking improvement (the macOS build uses fusepb/settings-header.pl, not the root one, so it doesn't affect macOS specifically) but a reasonable thing to land. Separate commit.

I haven't tested my branch thoroughly yet, so I may need to spend a couple more cycles. I also want to see if the GitHub Actions workflows are healthy or at least in a salvageable state.

[morozov]

This calls the unwrapped compat_socket_networking_init(), but the fork has a refcounted wrapper for it: utils_networking_init() in utils.c. Together with the utils_networking_init() call at line 148, the bookkeeping drifts at shutdown — the real init happens here outside the refcount, while w5100_start_io_thread increments the refcount per thread without a paired underlying init.

[desertkun]

Hmmm, your proposed branch/merge loses commit history from upstream. I would like to ideally preserve that. Maybe we're taking this too seriously.

Let me try make another attempt. With better conflict resolution. I'll take a look into submodules.

[morozov]

your proposed branch/merge loses commit history from upstream

No, it does not. morozov@a6988e4 has both parents.

Let me try make another attempt.

Why? I already did the merge.

[desertkun]

Can you open a new PR from your branch then?

[desertkun]

Closed in favor of new PR