talk.tryitonline.net

« first day (444 days earlier) ← previous day next day → last day (2050 days later) »

James Holderness

00:49

@Dennis Any chance of getting support for command line arguments in some of the Befunge implementations?

My specific need was for enabling Befunge-93 compatibility in FBBI and PyFunge, but I can imagine some other options might be useful too.

Not urgent or essential though.

Ether Frog

01:20

@Dennis i think i found a bug in the marioLANG interpreter :

in this example program ( a multiplication ) the stop condition should work as far as i know

tio.run/…

but it don't while this one work

tio.run/##jZC9CsMwDAZ3PYUcL/owhnTo0sR6kUyZSqE/…

Pavel

@EtherFrog Dennis doesn't make the interpreters, if there's a bug leave an issue on the interpreter's GitHub: github.com/mynery/mariolang.rb

Dennis

Sadly, I know nothing about MarioLANG or its interpreter.

TIO uses github.com/tomsmeding/MarioLANG though.

Pavel

@Dennis Ah. You should replace the MarioLANG link, it currently points to the esolangs page which lists the one I linked as the reference interpreter.

Dennis

Yep, just did that. (Not live yet.)

Ether Frog

okay will do thx

Dennis

01:30

@JamesHolderness Is Befunge-93 compatibility different from Befunge-93? If not, I'd rather add Befunge-93 (FBBI) and Befunge-93 (PyFunge) as different languages. A switch to make the "Befunge-98" interpreter interpret Befunge-93 seems a bit awkward.

James Holderness

I don't think they're really worthwhile adding as separate languages. Nobody would seriously want to use them as Befunge-93 interpreters since they're pretty crap.

Dennis

@orlp But how do I figure out if an error happened?

James Holderness

In my case I was trying to use as many different Befunge-93 interpreters as possible, and I was happy to have crap implementations.

Pavel

@JamesHolderness There are very many crap languages on TIO. I think Dennis just like it when the number increases.

Dennis

says the guy who kept requesting Gaot++ :P

@JamesHolderness So might others. I'll just add them as separate languages.

Pavel

01:40

@Dennis The exit code is nonzero, running (not compiling) produced any StdErr output, or the compilation process failed to produce an executable.

James Holderness

@Pavel Hell if that's the case I can come up with dozens of crap Befunge interpreters. :)

Pavel

@Dennis Hey, I like it when the number increases too.

Dennis

Not all errors result in a non-zero exit code, and not all output to STDERR indicate something abnormal.

Pavel

@Dennis Doesn't have to be abnormal, if normal execution produced StdErr output I want to see that output. During normal execution, the stderr is interleaved with the stdout, and the user wouldn't be able to tell the difference, so presumably it should be shown.

user202729

I think if there is something output to stderr the user should be informed by this. Same for stdout (generally the user doesn't fold the stdout).

Pavel

01:43

@user202729 The issue with that is that no one wants to see the 50 thousand warnings that GCC produced.

user202729

Or alternatively, let debug tab open by default. Because it is the bottommost it won't take much space.

Dennis

← 9 messages moved from The Nineteenth Byte

@Pavel Some languages always print to STDERR. The fact that the terminal cannot separate the streams is a limitation of the terminal.

@Pavel And there's no way for the frontend to tell if the output came from the compiler or the executable.

@user202729 Not an option I like very much, but I'll make that an option when I finally implement settings.

Pavel

@Dennis Well obviously some changes would have to be made to accomodate this, but I don't think it would be too hard for the wrapper to set a variable $ERROR_OUTPUT_PRODUCED and send it to the frontend.

@Dennis Right, but the language was created with the knowledge that the streams wouldn't be seperate, so the stderr is output with the intent that the user sees it. In this case, the debug pane should always pop open for those languages.

Dennis

@Pavel Hard? Maybe not. But it would have to be done separately for all compiled languages.

Pavel

@Dennis I could help with that. The majority of TIO langs are interpreted.

Dennis

01:49

@Pavel You seem to assume that the language creator had usage in a terminal in mind. That may be true from some languages, but not at all for others.

Pavel

@Dennis I suppose it isn't true for APL or Mathematica or R, but none of those write extra stuff to StdErr. I can't think of any others, and while there might be, I'm sure that the debug drawer opening unnecessarily for them isn't really that big of an issue.

Dennis

I'm more worried about false negatives.

Pavel

@Dennis Well if running it errors, but there's no stderr output, and the exit code is still 0, than there's nothing in Debug to see.

James Holderness

On a somewhat related note, I was wondering whether it would be useful to have the state of expanded tabs (specifically the debug tab) recorded as part of the url when generating a TIO link.
Had a situation recently where I was intentionally generating code that crashed, and there was debug output that I wanted others to see.

Pavel

02:19

@Dennis regardless of what you think of my scheme for detecting an error, I believe that making debug open by default would be easy to implement and, while not perfect, would still be preferable to the current way it's done.

Dennis

Yes, that is very easy.

Dennis

02:37

@JamesHolderness tio.run/#befunge-93-fbbi tio.run/#befunge-93-pyfunge

James Holderness

Awesome! Thanks.

3 hours later…

Conor O'Brien