If you read the manual page for patch it answers your question.

See the "NOTES FOR PATCH SENDERS" section:

> You  can create a file by sending out a diff that compares /dev/null or
> an empty file dated the Epoch (1970-01-01 00:00:00 UTC) to the file you
> want to create.  This only works if the file you want to create doesn't
> exist already in the target directory.  Conversely, you  can  remove  a
> file by sending out a context diff that compares the file to be deleted
> with an empty file dated the Epoch.  The file will  be  removed  unless
> patch  is conforming to POSIX and the -E or --remove-empty-files option
> is not given.  An easy way to generate patches that create  and  remove
> files is to use GNU diff's -N or --new-file option.

To concur with Rett here, I think there is a totally coherent software
development model using a tool like Flux which would work at scale and
still be an improvement over tools like CVS/Subversion where merging
branches was awful.

I would propose something even simpler: when rebasing a branch onto
main, you first need to collapse the commits from the branch point
into a single patch (commit) and then apply that at the end. From the
main branch point of view merging a branch and apply a third-party
patch would look the same, and dealing with conflicts would work about
the same in either case.

It's not clear that being able to do a "zipper merge" of two branches
is ever necessary in practice. It can be convenient but it complicates

On Mon, Feb 10, 2025 at 05:09:52PM -0700, Rett Berg wrote:
> Thoughts? Do I just need to spend more time with the Unix diff? If so,
> does anyone have a good reference on the spec? It would be best if we
> could ingest either, but I strongly prefer the before/after version
> that I've outlined for both storage and default usage.

Without making any other claims I will say that I definitely prefer
the unified diff format over the one outlined.

It is documented pretty well on Wikipedia, among other places:

   https://en.wikipedia.org/wiki/Diff#Unified_format

I have independently considered a barebones version control system

To echo Virgil, I would say that getting a 68k Mac computer in 2025
requires at least one of:

 - Money (paying high prices for "vintage" hardware on ebay)
 - Expertise (skills to fix broken machines sold more cheaply)
 - Time (checking around junk stores and flea markets)

Good luck!

On Fri, Sep 20, 2024 at 06:34:55PM +0000, Dave VanEe wrote:
> It might be useful to have the unused system/vector evaluate when the VM is closed. It could set the system/state port to a non-zero value, allowing the vector handler to prompt the user to save or cancel. If the system/state port is zeroed by the handler the VM would resume standard event handling, otherwise it would quit as normal.

This is a great idea.

It's nice to build this at the emulator level, so that exiting the VM
outside of the program (e.g. clicking a button to close a window)
would still give the program a chance to clean up.

On Mon, Oct 23, 2023 at 04:10:35AM +0000, Charles Langlois wrote:
> So my hypothesis is that the latest orca tal implementation is just not compatible with the uxn release on nixpkgs for some reason.
> 
> Thanks again to the implementers and contributors, looking forward to having fun learning a bit of orca and further discovering the uxn ecosystem!

Hi Charles,

Glad you got it figured out!

Varvara and uxn are still changing pretty frequently, so if you're
interested in working with them the best idea is to clone the
repository and periodically update it yourself. I would say the
project is not (yet) stable enough to be worth installing from a
package manager.

I think circular stacks would be good. I am not sure if they are
specifically "useful" (it's easy enough to use a ring buffer of
whatever size you want in memory if that's your thing) but I also
can't imagine a correct program getting anywhere close to using 256
bytes of wst or rst so it's a moot point either way. Getting rid of
unnecessary checks to speed up the stack is all to the good.

I don't like the idea of getting rid of div-by-zero errors as much
because these do signal program errors that might otherwise be hard to
catch. Also, I don't think checks on division are very expensive
relative to the cost of division itself (unlike overflow/underflow
checks).

If we have to give up division by zero I'd prefer to return a weirder

On Mon, Apr 17, 2023 at 11:44:22AM -0700, Devine Lu Linvega wrote:
> Here's a little something that has been requested over and over again.
> A way to detect when the argument stream ends.
> 
> This is basically an implementation of zzo38's design with a little
> tweak, btw you should check out their wonderful uxn(sdl1) emulator.

This is really great! I've wanted to write more command-line
tools that accept optional arguments as well as data on stdin
and this change will make that possible!

Thanks zzo38 and Devine!

-- d_m

So I'm in favor of some kind of change like this, both because I do
find myself needing to do #00 SWP a fair amount and also because
POPk and NIPk are otherwise not very useful.

I think that if we made this change it might be nice to rename them to
avoid a "false" symmetry with the existing POP/NIP. I might call POPk
"NUL" (it turns the top item on the stack into zero i.e. null) and
NIPk either "PAD" (it pads the top item of the stack with a zero
behind it) or "PIN" (which is NIP in reverse).

Similarly, if we made this change it would be better to make signature
of PAD/PIN ( a -> 0 a ) instead of ( a b -> a 0 b ). Once we break
symmetry a little bit holding onto the rest of the similarity to NIP
feels confusing and unproductive.

hey folks!

i wrote a proposal for adding metadata to uxn roms. you can find a
link to the text of the proposal here:

http://plastic-idolatry.com/erik/nxu/proposal.txt

for convenience i'm also going to paste the proposal below.

(i will continue updating the link above as i find typos or
improvements, so this email may become outdated.)

please let me know what you think -- i know there has not been much
enthusiasm for metadata up until now but i think something like this