nanaian / merlon Goto Github PK

The following should result in no changes:

merlon apply mod.merlon
merlon unapply mod.merlon

For me who signs his commits, this was unexpected and I didn't know what I was signing

For multiple packages in a repo
e.g. nanaian/pm-mods

editorconfig/rustfmt/clippy/etc

Currently, dependency patches are applied before the packages that depend on them: https://github.com/nanaian/merlon/blob/main/src/package/registry.rs#L188-L205

@Gorialis has had some thoughts about this: https://discord.com/channels/279322074412089344/1099844075399696394/1101066445472935966

Note: There's no need to do this until a user actually wants this behaviour and we have a concrete use-case to design around.

https://lib.rs/crates/reedline-repl-rs

I can't reproduce, neither can @Ponmander

The current distributable format is a tar archive with AES-256-CBC encryption, SHA-512 as the message digest algorithm, and PBKDF2 for key derivation. My thinking is that we don't really need any encryption on distributables, and can just use an archive format like zip instead

https://lib.rs/crates/clap_mangen

Users shouldn't need to build from source

Changed some code so kmr_20 now redirects to tst_01, and made some edits to the test_01 stage using Star Rod. I then copied the binary files from star rod over to my merlon project and tried to run, but crashed when trying to load the stage. Attached file contains all assets, the output ROM, and the .merlon distributable
custom_map_assets.zip

we really should separate things that need to install inside the specific repo (compilers) and things that need to be installed to your environment (python packages, system packages)

Could be a Discord bot too. Can train on the Merlon docs once they're further ahead
https://vaadin.com/blog/how-to-build-a-chatgpt-assistant-for-your-documentation

https://lib.rs/crates/clap_complete

Why?

• Makes git branch names understandable
• Makes asset directory names understandable
• Having a consistent slug is nice for URLs for package registry when that comes about

Implementation:

• Migration routine for existing packages
  • All(?) UUIDs are valid slugs, so, if we read an ID that looks like a UUID, warn. See below
• Emit warning if manifest id is not a slugged version of name? i.e. convert to kebab lower case
  • May want to reserve this check for a future merlon publish command

The BASEROM_US_URL secret isn't passed to PRs from people who don't have collaborator access (i.e. right now, anyone but me).
For example: https://github.com/striezel-stash/merlon/actions/runs/4927238627/jobs/8803936605

This behaviour is fine, but we shouldn't fail CI tests for people without collaborator access. Instead, we should have certain tests that need the baserom run conditionally on whether BASEROM_US_URL is defined or not.

It would be useful for packages to only include certain deps when testing (cargo run), but not when exporting. For example, skip developer logos.

e.g.

curl https://github.com/nanaian/merlon/releases/download/latest/merlon-linux-x86_64 -o merlon && chmod +x merlon && sudo mv merlon /usr/local/bin/merlon

• On cargo init, add .github/workflows/merlon.yml
• This workflow should
  1. Download baserom from secrets.BASEROM_US_URL
  2. Install Rust
  3. cargo install merlon
  4. merlon build
  5. Upload the distributable as an artifact
  6. If a git tag was made, create a release and upload the distributable

Should make debugging easier, plus its just cool

e.g. https://lib.rs/crates/dynalgo

With egui

1. Create a new merlon package with merlon new
2. in the new mod folder, run merlon init
3. Delete the .merlon folder
4. Run merlon init again

Result: The papermario folder gets deleted and the following error is printed:

fatal: destination path 'papermario' already exists and is not an empty directory.
Error: failed to initialise package test by Pronyo <[email protected]>

Caused by:
    failed to clone decomp repository

This is a potentially destructive operation if the user had unpushed/unexported changes in the papermario folder

I have installed the latest version of Project64 (which currently is 3.0.1) to a common directory, C:\Program Files (x86)\Project64 3.0.
This is an issue as merlon only looks for 2.3.x.

Lets you view metadata of a mod without applying it. e.g.

merlon inspect examples/skip-intro-logos.merlon

Name: Skip intro logos
Description: Skips the Nintendo 64, Intelligent Systems, and Nintendo logos at boot, launching straight to the title screen.
Author: Alex Bates <[email protected]>
License: none

Lots of this data should be stored in merlon.toml.

• https://marketplace.visualstudio.com/items?itemName=Isirode.better-stronger-toml
• https://lib.rs/crates/schemars

https://lib.rs/crates/git2
https://lib.rs/crates/openssl consider vendored
https://lib.rs/crates/tar
https://lib.rs/crates/bzip2

I don't have Windows, so I'd greatly appreciate help with this! Message me on Discord for more info (nanalan#0771).

Merlon currently supports Windows via WSL 2 and the Linux build. However, there shouldn't be anything stopping us from executing shell commands inside WSL but from a native Windows executable.

Specifically:

1. All of the calls to Command::new within the package (package.rs, init.rs, tests/dependencies.rs) need to be calls to wsl followed by the rest of the args. It would be good to create a method on Package like pub fn run_command(args: &[str]) -> Result<String> that constructs a Command with the given args, runs it with the current directory being the package directory, and returns stdout/stderr. On Windows (#[cfg(target_os = "win32")]) we can prepend wsl to args.
2. emulator::run_rom needs to use a Windows version of the ROM path (i.e. $wsl:// or whatever it is). wslpath2 might be useful here!
3. Print a warning if a Package is created with a non-WSL path on Windows arguing that compiling in the Windows filesystem is a source of performance issues.

Why: line number diffs are unstable across decomp versions

• Use a smarter diffing tool, like dyff: https://github.com/homeport/dyff
• Figure out how to integrate this with git / git format-patch / etc
• If this works, can we do something similar for C files?

Let's say I have a mod big that depends on a mod small.
I don't want to have to include small's commits in big.merlon.
Instead, big's merlon.toml should declare small as a dependency, and Merlon can figure out how to resolve it.
This will also affect the order in which mods are applied, i.e. small must be before big.

After #5 and #32

Running merlon add --path Skip-developer-logos-1.0.0.merlon in my merlon directory results in the following error:

merlon_v1/
merlon_v1/._LICENSE
merlon_v1/LICENSE
merlon_v1/._patches
merlon_v1/patches/
merlon_v1/._README.md
merlon_v1/README.md
merlon_v1/._merlon.toml
merlon_v1/merlon.toml
merlon_v1/patches/._0001-set-bSkipIntro-to-true.patch
merlon_v1/patches/0001-set-bSkipIntro-to-true.patch
merlon_v1/
merlon_v1/._LICENSE
merlon_v1/LICENSE
merlon_v1/._patches
merlon_v1/patches/
merlon_v1/._README.md
merlon_v1/README.md
merlon_v1/._merlon.toml
merlon_v1/merlon.toml
merlon_v1/patches/._0001-set-bSkipIntro-to-true.patch
merlon_v1/patches/0001-set-bSkipIntro-to-true.patch
Error: No such file or directory (os error 2)