by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    E-Hern Lee
    @somebody1234
    Ok so this is not exactly a bug but on TIO2 I'd prefer to have no text overflow, just adjusting the widths manually or using some kind of flexbox
    DennisMitchell
    @DennisMitchell
    @somebody1234 I'm not sure I understand. Are you referring to the soft wrap or the automatic resizing?
    Andrew Savinykh
    @AndrewSav
    If you have notifications that are not dismissed your output is cut at the bottom
    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
    blob
    This is blocked output ^^^
    blob
    This is output with dismissed messages
    Note, that when it's cut you cannot scroll down to see the rest
    DennisMitchell
    @DennisMitchell
    @AndrewSav Yeah, that's because notifications are displayed on top of the main div. I'll think about a way to fix this.
    Felipe Bastos
    @fbastos1
    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.
    Martin Ender
    @m-ender
    @fbastos1 I don't know what 93 is supposed to do when wrapping around in string mode, but pushing spaces in string mode is the one thing where Befunge-98 spec is explicitly breaking backwards-compatibility.
    (and since 93's grid size is hardcoded, the number of spaces isn't quite indeterminate, so this might actually be intentional)
    Felipe Bastos
    @fbastos1
    @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.
    Felipe Bastos
    @fbastos1
    I stand corrected, again. The reference interpreter does indeed push the spaces, as does TIO's; please ignore the fact that I didn't think of running that before coming here. Sorry I'm stupid
    DennisMitchell
    @DennisMitchell
    @sp33dsk8 That's not a memory leak. scanf hits EOF, so the second variable is still uninitialized after calling it.
    moridar719
    @moridar719
    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.
    Andrew Savinykh
    @AndrewSav
    @moridar719 If I'm not mistaken evil is not maintained
    @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
    @moridar719
    I definitely don't think it's being maintained. Further testing makes it looks like the issue is that new cells are never being added to the Wheel, so something is going wrong in the function wopen(). I'll look into it further.
    Andrew Savinykh
    @AndrewSav
    @moridar719 thanks!
    DennisMitchell
    @DennisMitchell
    @moridar719 wopen looks iffy. It doesn't change wheelSize.
    @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.
    Andrew Savinykh
    @AndrewSav
    Yep, since I'm no evil expert at all this part concerns me most ;)
    moridar719
    @moridar719
    @moridar719 wopen looks iffy. It doesn't change wheelSize.
    @DennisMitchell was about to say the same thing.
    Daniel Hill
    @YellowOnion
    Haskell compiler is broken
    [1 of 1] Compiling Main ( .code.tio.hs, .code.tio.o )
    Linking .bin.tio ...
    .: file not recognized: Is a directory
    DennisMitchell
    @DennisMitchell
    Could you give me a permalink?
    DennisMitchell
    @DennisMitchell
    Daniel Hill
    @YellowOnion
    Oh I did not see that.
    Benjam Welker
    @benjamw
    Has anybody mentioned the fact that the byte count is actually a character count? Some of the golfing languages use UTF8 characters that are more than 1 byte each
    DennisMitchell
    @DennisMitchell
    @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.
    DennisMitchell
    @DennisMitchell
    @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.
    Taylor Scott
    @TaylorAScott
    @DennisMitchell if you take a look at the ReadMe from the EtchedPixels git you will however see that it supports String variables (A$-Z$ required) and LEFT$(), RIGHT$(), MID$(), CHR$() however none of the these appear to be in use .
    Is it possible that the interpretter that TIO uses is https://github.com/adamdunkels/ubasic