Hm, that somehow breaks 12 languages...

Fixed an obvious bug; they all seem to work now.

@Dennis 0/10 no GitHub commit

It's also not live yet. I don't feel comfortable making a change like that before going to bed.

@Dennis Has anything in the backend changed lately? Quite a few people are getting Dyalog APL syserrors (as if the memory got corrupted somehow) lately. Immediately rRe-running the exact same thing usually works fine.

@Adám I've updated a few system packages 6 days ago, but nothing else. Has this happened to you? Do you know what code triggered the syserrors?

@Dennis Yes, it happens to me too. It is all kinds of code. Nothing special and isn't reliably reproducible. You can see the effects when it happened to the TIO bot: Compare this to this.

The observed effect is that TIO takes a long time to output (5 secs in the bot's case) when the computation should be instant, and then it is just a sys error with no other output.

@Adám I'm not sure what that code does. Is it memory intensive? This happens with on the website too, yes?

@Dennis It does very little: Defines an operator, then uses it to compute e^(log 2+log 3) and e^(2×log 3). Yes, it happens on the website too, but I cannot preserve a record of it there (other than screenshots).

Yeah, just reproduced it.

Also died after 5 seconds. That's probably not a coincidence.

What is errno 25 anyway? help.dyalog.com/16.0/Content/Language/Errors/… doesn't say...

Also happened with Hello World. :/ Also 5 seconds.

@Dennis Oh, that list is for proper trappable errors. Syserrors happens when the interpreter finds its memory to be different than expected. The main code (999 here) provides some information about what went wrong, but 999 is for memory corruption that it didn't understand at all, so the minor number (25) doesn't mean anything decipherable.

But why always 5 seconds?

My best guess is that the TIO framework (includes DO) occasionally corrupts the memory that has been assigned to APL. Looks to APL like a hardware fault.

@Dennis Notice that the 5s is real time only, so it doesn't seem like the interpreter is keeping the server busy for that time.

Yeah, it looks like it's waiting for something.

@Dennis it = the framework?

No, the interpreter. If it doesn't consume CPU time, it should be waiting for something.

It's hard to say with an intermittent error, but Dyalog APL Classic doesn't seem to be affected.

@Dennis Hm, you updated Dyalog APL in early April, afaict.

Sounds about right, yes.

No, wait. I rebuilt the servers in May.

I'm running 16.0.32742, the latest version.

@Dennis Yeah, I can see that.

@Dennis OK, got the answer to that: When a syserror happens, it delays 5 seconds before quitting so that you have a chance to read the message before your terminal closes.

Ah, that explains a lot.

Reproduced it on both arena servers, so it's more than just a glitch.

@Dennis For me, it only happens maybe one of of 30 times or so.

@Dennis Can you please change the 2DFuck link to gitlab.com/TheWastl/2DFuck ?

I should also get the source code from there, yes?

@Adám Which makes it that much harder to debug. :/

@wastl Changed it in the frontend.

@Dennis Thanks!

@Adám It becomes a lot more frequent if I simulate some load. Still can't repro with Classic.

@Dennis What does simulate some load mean?

Hashing 1 GiB of null bytes in the background. (line 1)

@Dennis Ah.

@Adám The crashes leave an aplcore file behind. Would that be of any use to you?

@Dennis Yes, can you send that to support@ ?

With an explanation or will they know what this is about?

@Adám This is so weird. If I simulate heavy load (8 concurrent hashing threads), it doesn't happen.

@Dennis Every ≈1/30 times I run ⎕FIX ':namespace' '⎕←''Hello, World!''' ':endnamespace' I get the attached aplcore

@Dennis Ouch, that's some hammering. And yes, that is very strange. Could there be some partial swapping with faulty swapping-back going on? When everything is swapped together, no misalignments happen… Just brainstorming here.

Hashing doesn't use a lot of memory. This just causes some CPU load.

Any chance this happens because access to /etc/ld.so.cache is not allowed?

That's the only thing I can find in my logs.

@Dennis I don't know what that is, but why wouldn't it happen every time?

@Dennis Have you tried seeing if it happens running it in not the sandbox?

@Pavel It certainly never happens for me offline. And it didn't happen before on TIO either. Definitely a new occurrence.

@Adám No clue. Why would memory corruption only affect Dyalog Unicode?

@Pavel Not yet. That's a good idea.

@Dennis Maybe the other languages don't sanity-check all their allotted memory?

Does Dyalog Classic?

@Dennis Yes, they are almost identical.

Anyway, gtg, may be back online in a few minutes. Or not.

@Adám But Dyalog Classic is not affected.

@Dennis maybe it's to do with the different wrappers?

The Classic wrapper sets a handful of environment variables and calls the Unicode wrapper...

I think I found the issue.

@Dennis Ooh?

@Adám The trigger, anyway. I'm using stdbuf (via LD_PRELOAD) to disable buffering, so aborting a request will still print all output up to that point. Unsetting it before launching the APL wrapper seems to fix that.

Try it online!

Didn't you write your own stdbuf for x86?

Sort of. stdbuf really just sets a few environment variables.

@Dennis At what point do you normally unset it? Is this something you've changed lately?

I don't unset it. Unsetting would be a workaround for the issue at hand.

I tried unsetting it inside the wrapper, but that doesn't help at all.

@Dennis: Would you be interested in adding Nameless language?

I just wrote an interpreter for that polyglot challenge: here

@Dennis Oh, now I get it. So APL doesn't cope well with its output being captured as it is produced, rather than buffered and delivered as a whole. Right?

Looks like it, yeah.

@BMO Always interested in new languages. :) I'll take a look later.

@Adám The attempted hotfix is live. Please tell me if it helped.

I have to go now. I should have already left.

@Dennis I guess time will tell.

I decompiled the C# 8 preview, extracted the compiler out of the visual studio extension package, recompiled it, and got... the standard Roslyn compiler that supports up to C# 7.3.

This makes me very confused and not at all happy.

Visual Studio Code does not support Visual Studio extensions, unfortunatly.

rolling eyes emoji

It only took me a solid 15 minutes to figure out how to compile the implementation of Ranges, which depends on System.Span<T> from System.Memory, which is supposed to be part of C# 7.2 but is delegated to a nuget package.

I'll add it to the msbuild packages while I'm at it.

Honestly the whole thing where they release major langauge features as optional nuget packages confuses the hell out of me.

I'm not sure why but the package upgrading tool is chocking on the VB project

@Dennis Could you look into adding Rutger? The Hello, World! is in the examples folder, and the invocation in the README

@Dennis Whenever you have the time, can you try something for me? Switch cs-mono to the 2017-projects branch and change the cs-csc wrapper to this:

Wait no nvm still need to make an adjustment

There

#!/usr/bin/env bash

ln -fst . /opt/cs-csc/TIO-CS/{obj/,TIO-CS.csproj}
ln -f .code.tio Program.cs

msbuild /verbosity:quiet "${TIO_CFLAGS[@]}" >&2
mono bin/*/TIO.exe "$@" < .input.tio

Along with corresponding adjustments for everything else, replaceing CS with FS or VB as needed

Oh, I forgot about mcs and vbnc

Uh

Ok those have been fixed

Also you might want to rename all of the /opt/cs-csc to /opt/cs-mono since the repo is called that

Honestly I think it might be worth dropping support for the mcs compiler entirely. It has no functionality csc doesn't have, it's just super outdated.

@Pavel For x86, I just compiled the official coreutils and saved the resulting libstdbuf.so in the appropriate location. Anyway, since Dyalog APL is x64, that shouldn't matter.

Another blackout! Great...