On Wed, Oct 25, 2023 at 10:25:44AM +0000, Simon Ser wrote:
>This is likely a result of [1]. It sounds like you were making use of
>the repo owner's secret and pushing with a different account.

If the person making the push is using a non-paying account, will they
be able to use builds.sr.ht for that repo? (The repo owner is on a paid
service, of course.)

Thanks very much,
Andy

Dear hikari_no_yume and Annette,

On Tue, Jul 04, 2023 at 10:03:30PM +0100, Annette Wilson wrote:
>With regard to the second problem, I think the [uxn-essentials-mac64.tar.gz][1]
>file linked from the [100r.co site][2] has ROMs compiled with a newer version
>of uxn but executables for an older one. After a bunch of experimentation, I
>figured out that these executables don't handle the JCI/JMI/JSI opcodes, and
>similarly the bundled assembler doesn't recognise the immediate runes "!" and
>"?".

Thanks so much for tracking the problem down! While Sourcehut Pages has
had a fault and the usual binaries were unavailable, I built Uxn
manually to upload the binaries elsewhere. Since I use temporary
snapshots on my macOS machine the logs of my exact steps are gone, but

On Wed, Nov 09, 2022 at 08:58:53AM -0800, Devine Lu Linvega wrote:
>So I was thinking, what would you say if on top of : for raw label
>shorts, I added =label for raw shorts, and -label for raw bytes?
>Consider your macros that might begin with - or =.

I think it could be quite a rarely-used feature, and I had some
inspiration from Huffman coding…

What about a double rune?

We can keep the unadorned “:” for raw shorts, but we could also use “:;”
for the same thing. We can then use “:.” for raw zeropage bytes and even
“:,” for raw relative bytes.

Hi Dave,

On Fri, Jul 08, 2022 at 11:30:26AM -0700, Dave VanEe wrote:
>This patch adds tests for most k (keep) variations of UXN
>instructions, based on the existing instruction tests.

Thanks very much for your work! I've added it to our main branch now.

There was a slight niggle with your patch, which was that you had 
converted tabs to spaces in your source file. If you're able to keep the 
tabs intact next time, that'll make it easier for us to work with :-)

Best wishes,
Andy

On Tue, Jun 21, 2022 at 07:43:10AM -0700, Hundred Rabbits wrote:
>Gotcha, thanks for the explanation :) I will merge the patch today and
>experiment.

I see the patch restricts File access to the current directory and 
below — well done!

I wonder what the appetite is to restrict it further so that if it's run 
in the home directory, it changes directory to e.g. ~/.config/uxn after 
reading the ROM. My threat model here is that running Uxn from inside 
~/uxn is safer, but when it's run directly in ${HOME} then it can 
read/delete my ~/.ssh/ private keys.

This is technically doable with little extra work, but I was interested

On Sun, Jun 19, 2022 at 04:28:35PM -0700, Hundred Rabbits wrote:
>Sounds like we're all onboard with this new File design.
>
>If we went this way, how would we read a file larger than 64kb, for
>example, I have a slideshow program, I use it a lot, which streams TGA
>files and draw them but does not cache them because they are larger
>than 64kb.
>
>I can imagine that we could have a seek address that is 2 shorts?

Yes, I think that keeping it to one short isn't that practical now we 
have rich applications like your slideshow program.

The snag then is that we don't have room for File/stat, File/delete and

On Mon, Jun 13, 2022 at 08:00:03AM -0700, Hundred Rabbits wrote:
>I've been thinking about this one and I was wondering, this file I/O
>stuff is quite unfamiliar territory to me, so bear with me ^^;
>
>I enjoy the current device because I can stream content from files
>without taking any space in the running program, for example, my wiki
>only reads 1 byte at a time, and so the buffer has a length of 1,
>which leaves me a lot of space to do other things with the program.
>
>If we were to go back to a simpler file device like we had, with the
>option of getting bytes at a specific address with a specific length,
>would I just have to increment an address in my uxntal program, and
>still read one byte at a time at that specific address, pretty much
>the same way I did? Would it be much slower since now it would

Hi Felix!

UF is indeed awesome, as Devine and Erik have said :-)

Just to note that in your README you say:

> SDL uxn added a timeout after which the VM aborts when no events
> are processed.

That restriction has been removed in SDL uxn. It may make it back in but 
it won't take action by default, so software such as yours shouldn't 
need this warning with an up-to-date uxnemu.

Thanks very much for sharing this with us!

On Sun, Jun 12, 2022 at 02:05:42PM -0700, Devine Lu Linvega wrote:
>> I mean the timeout caused by throwing an error when the event loop
>> has not been called inside a certain time limit:
>
>Oh! Yes, I think I'd like this removed too, I've never implemented it
>in uxn11, and on the raspberry pi it makes using uxn-sdl applications
>almost impossible since every little lag fills the stack is garbage.

I've been working on vsync support lately, but on reading this it's 
clear that the execution timeouts aren't working. I've disabled them 
with 
https://git.sr.ht/~rabbits/uxn/commit/fb030288f941615df5bfa2a2fbaf6a075b8ab6ca 
.

Hi all,

On Sat, Jun 04, 2022 at 02:21:48PM -0000, binarycat@envs.net wrote:
>Seeking within files is a very useful operation, especially in a 
>context where you can only have 2 files open at a time.
>
>The tricky part is trying to fit seeking operations into the existing 
>device.  we could use the unused file vector for this, but we could 
>also reuse `success` for this, as currently it is never written to.

As Devine said in their reply, we used to have a File device that was 
able to seek. Its ports were:

2 × vector (unused)