it also visually unclear that it's cut, so if you do not know that there is more iutput if you dismiss you cannot guess from the look if ut
This is blocked output ^^^
This is output with dismissed messages
Note, that when it's cut you cannot scroll down to see the rest
The Befunge-93 interpreter pushes an indeterminate number of spaces (32s) to the stack when the instruction pointer wraps around in string mode. This is not in the language specification and does not happen in the Befunge-98 interpreter. Here's a program that shows it, and here's the expected behavior.
(and since 93's grid size is hardcoded, the number of spaces isn't quite indeterminate, so this might actually be intentional)
@m-ender That's a good point. I used "indeterminate" because I just didn't know how many it'd push, I just knew that it did. I did look up the specification again and it really doesn't say what it's supposed to do then, especially since normally the spaces are no-ops; I just decided to report anyways, since it's unexpected (even if compliant), and not in line with some of the other interpreters.
Fairly sure I found a memory leak of some sort
Seem to have found a bug in the evil interpreter. https://tio.run/nexus/evil#@19UmZxSkFj@/38iAA should output 'b' (input + 1) but instead outputs 0 + 1. Seems to be an issue with creating and deleting Wheel cells.
it originally came from here https://web.archive.org/web/20070103000858/www1.pacific.edu/~twrensch/evil/index.html
@moridar719 I copied it here: https://github.com/TryItOnline/evil So I'm guessing you can make a pull request? @DennisMitchell would you be comfortable to accepting a pull request to evil interpreter to fix what appears to be a bug?
@moridar719 I copied it here: https://github.com/TryItOnline/evil So I'm guessing you can make a pull request? @DennisMitchell would you be comfortable to accepting a pull request to evil interpreter to fix what appears to be a bug?
@AndrewSav As long as I can verify that it's actually a bug, gladly.
@DennisMitchell was about to say the same thing.
[1 of 1] Compiling Main ( .code.tio.hs, .code.tio.o )
Linking .bin.tio ...
.: file not recognized: Is a directory
Linking .bin.tio ...
.: file not recognized: Is a directory
That's caused by the two empty compiler flags. Without them, complication is successful. https://tio.run/##JcyxCsIwGEXhVzmDQzIYYt3E@BoOVegPjTQ0SaUNgk8fI10v93yTbLOPsdb3GpLfcHRceIVY/Ip6CMcbeSkoyV@Ucg6rMaRlRDQHisz@PoXoUVeHMIzhM9Bpdk9r@rMxz5ok5Ia3NZfW/zNO1jZhP9Yf
@benjamw Jelly, for example, uses Unicode characters, but not necessarily UTF-8. In its codepage, each of the 256 characters it understands is encoded as a single byte.
I Believe that the uBASIC compiler is not functioning correctly, specifically it appears to cause errors using when any of the reserved string variables (
a$-z$): I tried running the sample code from http://www.zenoshrdlu.com/kapstuff/zsubasic.html - but it fails on the first mention of the string variable a$ -https://tio.run/##bZLBboMwDIbveQrLilQQHJZAgR54g71ESAOkomnVZFP39MxpASFtNzv@fud3nK9OeavnWcD9YV0A9EE9Atx6CMYHZBIUbwFVp8@mH0aLrICOtyhkUR6rujkhO67ST@OGMEYtaTCHybhE8ZRVf4FuAzoCarD9SkO7HkMYjdtsqauJBdIjayJPMLH/cj5QMiA7gebtZPrACc6IzYVMmfhYYM2ZEBF52GF8M4TAi5E7pojM1Z43oskbQsodcowIXcsTUWRlbFDtqvUSx8E0zSua3QGG0XqEDChQAakabdNoeqR2RZkyuTMsBVyoprx@dZKrzwuTxRJ@qyl574eayRJsax1ZS4ocdmujpKrfwPJ095u3wd5c3M@hqg9gHRw2AaWeRJbJdd/Li@Qyl2mGz58n/Y3VKRp33j7RPP8C
@TaylorAScott TIO doesn't use the version from http://www.zenoshrdlu.com/kapstuff/zsubasic.html, to which the author decided to add string handling. https://github.com/EtchedPixels/ubasic, which is the interpreter TIO uses, doesn't seem to be compatible.