« first day (683 days earlier)      last day (1811 days later) » 

01:37
@BMO The Hello World from Esolangs doesn't seem to work. Do you have another one?
Feature request:
Allow easier testing of polyglots by adding a "run in the following languages" option.
That's planned. The backend kinda supports it already, but I'll probably rewrite it first.
I actually want to do more than that and provide the ability to arbitrarily combine requests. So same code in multiple languages (polyglot) and same code with different inputs (test suites) would be particular use cases.
Lemmeguess: you made TIO
01:51
Guilty as charged. :P
I'd like to both thank you for making TIO and scream at you for not making a light colored version of the site.
Light-colored themes are an evil plot to blind the human race.
11
Hey but dark colored themes make it impossible to see a thing t without your brightness all the way up
Wrong audience. You're talking to someone who doesn't leave the house without sunglasses.
@cairdcoinheringaahing tio.run/#rutger
@Dennis \o/
03:33
@Pavel That works for cs-csc, but not for the other four.
tio1:srv# tiodryrun -v -l {cs-{csc,mono},fs-mono,visual-basic-net-{mono,vbc}}
Testing 5 languages on arena localhost...
Arena localhost responded after 12.628 seconds.
cs-csc
Microsoft (R) Build Engine version 15.6.0.0 ( Thu May 10 16:15:27 UTC 2018) for Mono
Copyright (C) Microsoft Corporation. All rights reserved.


Real time: 2.291 s
User time: 2.110 s
Sys. time: 0.182 s
CPU share: 100.05 %
Exit code: 0
cs-mono
Hello, World!

Microsoft (R) Build Engine version 15.6.0.0 ( Thu May 10 16:15:27 UTC 2018) for Mono
 
1 hour later…
04:58
I'll have to take a look later, sorry
 
5 hours later…
10:24
@Dennis Thanks!
 
1 hour later…
11:37
@Dennis Can you pull Rutger please?
 
2 hours later…
BMO
BMO
14:07
@Dennis Yeah I noticed that too, I think I'll adjust the page. I have a working (transpiled brainfuck) one in the readme on github.
BMO
BMO
14:29
I changed the Esolangs program.
15:24
@LuisMendo It took a while longer, but I finally fixed and deployed my hack of libc++. Try it online!
Do you know if that bug has been reported to Octave?
BMO
BMO
15:47
@Dennis Great stuff! Thanks :)
@Dennis lol capitalization is so broken
> nameless language
homepage:
> Nameless language
and is it really called "Nameless language" and not just "Nameless"...
@EriktheOutgolfer ... he wrote, in a sentence without capitalization. Or punctuation.
@EriktheOutgolfer The original website talks about nameless language scripts.
oh, so it's like brainfuck's case
BMO
BMO
16:02
For my purpose (The name of the language being reversed is Case-insensitive) case doesn't really matter ;)
16:27
@Dennis Can you show me exactly what the fs-mono and cs-mono wrappers looked like when you ran that?
Not anymore. I had to revert the changes to add nameless language.
cs-mono was pretty much cs-csc with the flag to msbuild though.
@Dennis Would that mean it didn't have ln -fs /usr/lib/mono/*/mcs.exe ./csc.exe?
I'll have to try again. I had to revert the remaining changes because the lic++ hack required a full sync...
Out of curiosity: why are we doing this?
Two reasons: Keeping everything in the same directory actually causes a lot of problems whenever there are any updates, and because currently the *proj files are in an outdated format--the 2017 format has some additional features and is generally nicer to work with.
The new 2017 format autodetects which source code files to use, except F# is a bit wonky there since it actually cares about the order that files are compiled in, so I'm going to see if there's something up with that.
Mono's visual basic compiler doesn't report errors. It just exits with code 1. Which kinda sucks.
16:43
Yeah.
Okay, searching this room tells me this actually happened before, and the fix is <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> on my end.
@Dennis Ok, I've made some fixes on my end. There should now be fewer errors.
cs-mono was indeed just missing the symlink.
@Pavel fs-mono is still failing. Wrapper and error message follow.
#!/usr/bin/env bash

cp -r /opt/cs-mono/TIO-FS/{obj/,TIO-FS.fsproj} .
ln -f .code.tio Program.fs

msbuild /verbosity:quiet "${TIO_CFLAGS[@]}" >&2
mono bin/*/TIO.exe "$@" < .input.tio
Can't find custom attr constructor image: /home/runner/bin/net47/TIO.exe mtoken: 0x0a000001 due to: Could not load file or assembly 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:<unknown type> member:(null) signature:<none>
Microsoft (R) Build Engine version 15.6.0.0 ( Thu May 10 16:15:27 UTC 2018) for Mono
Copyright (C) Microsoft Corporation. All rights reserved.
hmmm
17:01
visual-basic-net-vbc is working, but visual-basic-net-mono is not.
#!/usr/bin/env bash

cp -r /opt/cs-mono/TIO-VB/{obj/,TIO-VB.vbproj} .
ln -f .code.tio Application.vb

msbuild /verbosity:quiet "${TIO_CFLAGS[@]}" >&2
mono bin/*/TIO.exe "$@" < .input.tio
Microsoft (R) Build Engine version 15.6.0.0 ( Thu May 10 16:15:27 UTC 2018) for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

/usr/lib/mono/msbuild/15.0/bin/Roslyn/Microsoft.VisualBasic.Core.targets(73,5): error MSB6006: "vbnc" exited with code 1. [/home/runner/TIO-VB.vbproj]
Cannot open assembly 'bin/*/TIO.exe': No such file or directory.
Which makes no sense at all, since vbc uses an awful hack and vbnc is the way it's supposed to work.
I've pushed something which might fix the F# issue.
Maybe try removing the verbosity flag so we can see if that gets a useful erro report from vbnc
@Pavel Sense has nothing to do with it.
@Pavel Same error.
Microsoft (R) Build Engine version 15.6.0.0 ( Thu May 10 16:15:27 UTC 2018) for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 7/6/2018 5:08:50 PM.
Project "/home/runner/TIO-VB.vbproj" on node 1 (default targets).
PrepareForBuild:
  Creating directory "bin/net47/".
  Creating directory "obj/Debug/net47/".
GenerateBindingRedirects:
  No suggested binding redirects from ResolveAssemblyReferences.
CoreCompile:
  /usr/bin/vbnc /noconfig /imports:Microsoft.VisualBasic,System,System.Collections,System.Collections.Generic,System.Data,System.Diagnostics,System.Linq,Sy
@Pavel ^
Nope, no clue. Vbnc is dumb.
I don't think it's worth trying to fix F# if I have no hope of getting VB to work, so I suppose we'll shelve that for now
17:23
Is vbnc as obsolete as mcs? It is still the default...
@Dennis That's because the latest stable version was the first one to ship with vbc. They don't want to accidentaly cause breakage.
But yes, vbnc is deprecated and there's no reason to use it.
18:14
@Dennis I remember that you intend (or want) to add a feature to TIO where people can pull languages themselves rather than asking you. Would that feature also apply to adding languages as well, or would that still go through you?
I could set up some kind of sandbox for unapproved languages, some my part could be reduced to pressing a virtual OK button.
How could you sandbox the setup part of that? That takes internet.
Also, @Dennis, did you see this?
@Pavel So does pulling languages. Both would require a TIO account.
@cairdcoinheringaahing Forgot about that. Pulled now.
@Dennis Thanks!
18:26
@Dennis Presumably the script that pulls the lang would be OK'd by you though.
@Dennis Sorry, I made a typo. Could you pull it again?
Done.
@Pavel Right, but I'd still get in trouble if it's triggered too often.
Not with simple rate limiting
18:38
Rate limiting what exactly?
How often you can trigger a pull
Per time unit and user account?
I suppose
19:02
@Dennis Thank you so much! I’ll take a look at Octave’s bug reports later when at the computer
19:29
@Dennis It seems that V isn't taking input right now. Any idea what's up with that?
@DJMcMayhem Not really, no. Any idea how recent this issue is?
I just noticed it the first time today
Any chance you didn't notice it for a week?
Possibly
Jun 29 at 3:53, by Dennis
@DJMcMayhem Due to some dependency conflicts, I had to change vendors for neovim; it got updated from 0.2.2 to 0.3.0 in the process. Please let me know if that caused any issues.
19:36
I thought that I tested some basic stuff after that message
It shouldn't be related to the change I made today; unsetting LD_PRELOAD doesn't fix it.
Is it possible to call the old version of neovim to see if that's related, or would that have been uninstalled in the upgrade?
neovim 0.2.2 had dependency conflicts with the rest of TIO, so I had to upgrade and there's no easy way of going back...
@DJMcMayhem What neovim version are you using locally? If it's outdated you might be able to repro if you upgrade.
@Pavel I have no idea. I almost never run V locally
Honestly, I should probably just rewrite it in vim rather than neovim...
19:44
@DJMcMayhem You have to test changes somehow before asking Dennis to pull, right?
Vimscript related changes get tested locally in vim, python related changes almost never happen. (But when they do I boot up a VM and test it in neovim)
Holy crap, my VM has neovim 0.1.5 XD
Yeah, you should, uh, probably upgrade.
to 0.1.6?
:P
@Dennis Just recreated the bug locally. It's probably on my end
It's the new neovim then?
Yeah
But honestly, V should work with modern neovim. I'll work on fixing it
It's also kinda ridiculous that it all runs on python 2 TBH :/
20:09
@Dennis Will you pull? I think I've got it fixed
I also did pip install --upgrade neovim, and I'm not sure if that's necessary or not, but it's probably worth trying updating for consistency
@DJMcMayhem That worked. Without pip fwiw.
Sweet.
In the end, all I had to do was switch nvim [args] file --embed to nvim [args] --embed file
@Dennis On an unrelated note, would it be possible to not add newlines after the footer/before the header?
I've been meaning to make that selectable for a while now.
 
3 hours later…
23:35
@Dennis I have taken a look at Octave's bug reports and used the search, and couldn't find anything about this. Do you intend to file the bug report yourself? I have an account there, but I wouldn't know how to explain the bug, as I don't quite understand what the problem was

« first day (683 days earlier)      last day (1811 days later) »