« first day (444 days earlier)      last day (2050 days later) » 

12:49 AM
@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.
 
1:20 AM
@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
but it don't while this one work
 
@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
 
Sadly, I know nothing about MarioLANG or its interpreter.
 
@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.
 
Yep, just did that. (Not live yet.)
 
okay will do thx
 
1:30 AM
@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.
 
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.
 
@orlp But how do I figure out if an error happened?
 
In my case I was trying to use as many different Befunge-93 interpreters as possible, and I was happy to have crap implementations.
 
@JamesHolderness There are very many crap languages on TIO. I think Dennis just like it when the number increases.
 
says the guy who kept requesting Gaot++ :P
@JamesHolderness So might others. I'll just add them as separate languages.
 
1:40 AM
@Dennis The exit code is nonzero, running (not compiling) produced any StdErr output, or the compilation process failed to produce an executable.
 
@Pavel Hell if that's the case I can come up with dozens of crap Befunge interpreters. :)
 
@Dennis Hey, I like it when the number increases too.
 
Not all errors result in a non-zero exit code, and not all output to STDERR indicate something abnormal.
 
@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.
 
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).
 
1:43 AM
@user202729 The issue with that is that no one wants to see the 50 thousand warnings that GCC produced.
 
Or alternatively, let debug tab open by default. Because it is the bottommost it won't take much space.
 
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.
 
@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.
 
@Pavel Hard? Maybe not. But it would have to be done separately for all compiled languages.
 
@Dennis I could help with that. The majority of TIO langs are interpreted.
 
1:49 AM
@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.
 
@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.
 
I'm more worried about false negatives.
 
@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.
 
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.
 
2:19 AM
@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.
 
Yes, that is very easy.
 
Awesome! Thanks.
 
 
3 hours later…
5:13 AM
@Dennis Could you pull str? I fixed Fixnum deprecation
 
 
1 hour later…
6:16 AM
@Dennis can you please pull Funky?
 
 
4 hours later…
10:44 AM
@Dennis for all intents and purposes, I think just uncollapsing the error box if there's any content in it is good behavior
 
 
1 hour later…
11:53 AM
@ConorO'Brien @ATaco Done.
 
 
4 hours later…
3:30 PM
@orlp True, but some languages use STDERR as debug, even if there isn't any error... Though I do agree that in the general case, output to STDERR is usually something you want to see...
 
3:46 PM
@SocraticPhoenix but why would that matter?
if the program generates output, show it
and IMO stderr is just part of the output of a program
at least in the sense that it's information a user wants to see
 
4:09 PM
@orlp because then you have a box full of completely irrelevant debug information... Assuming the program ran correctly. That being said, I do agree that any output should be shown
 

« first day (444 days earlier)      last day (2050 days later) »