« first day (4 days earlier)    last day (39 days later) » 

ais523
ais523
1:36 PM
@mousetail: I'm wondering whether the KotH controller is (still) buggy? It's showing example C bot surviving a huge number of attacks that should kill it, whereas The Burrowing Wheel is dying to attacks on the chaff (possibly this is timeouts due to your computer being slower than mine?)
 
mousetail
mousetail
@ais523 It's not impossible. It might be timing out. Or the chaff attacks could be the final straw after a lot of other data got deleted first
 
ais523
ais523
the KotH controller used to be even more buggy, it was doing things like showing programs twice, sometimes with the wrong source code, and showing MVP surviving a round on average (when it dies to an attack on everything but the final newline), but that seems to have been fixed
 
mousetail
mousetail
I have a 10MB log file if you want to check :)
 
ais523
ais523
10MB isn't too bad
 
mousetail
mousetail
@ais523 The wrong source code was my mistake, I pasted the base64 into the wrong bot config
I recently made the controller multithreaded so now all the output is out of order
 
Fatalize
Fatalize
1:42 PM
@ais523 that’s way too low-level for me
 
mousetail
mousetail
$  echo -n aWlpaWlpaWl2dnZ2dnZ2CgoKCmxsbGxsbGxsbGxsbGxsbAoKCgoxMTExMTExMTExMTExMTEKCgoKLS0tLS0tLS0tLS0tLS0tCgoKCm5ubm5ubm5ubm5ubm5ubgoKCgo4ODg4ODg4ODg4ODg4ODgKCgoKMjIyMjIyMjIyMjIyMjIyCgoKCjIyMjIyMjIyMjIyMjIyMgoKCgoqKioqKioqKioqKioqKioKCgoKKioqKioqKioqKioqKioqCgoKCm9vb29vb29vb29vb29vbwoKCgpvb29vb29vb29vb29vb28KCgoKOzs7Ozs7Ozs7Ozs7Ozs7Cg== | base64 --decode | timeout 1.1 ~/.local/bin/jelly f code 

Player The Burrowing Wheel was eliminated, output:
b'243 \x7f\n'
 
ais523
ais523
I split my time between the really low-level and really high-level languages, but the latter take longer to implement
 
mousetail
mousetail
This error might be relavent:

bash: line 4227: warning: setlocale: LC_ALL: cannot change locale (C.ISO-8859-1)
 
ais523
ais523
@mousetail hmm, maybe an encoding issue? the character at 0xf3 in that program is newline, which is at 0x0A in Unicode or ISO-8859-1, but 0x7F in Jelly's codepage
 
mousetail
mousetail
Yea probably
 
ais523
ais523
1:48 PM
seems to be an encoding issue – I get the 0x7F output too, but only when using LC_ALL=C.ISO-8859-1
and get 0x0A instead when going by character
 
mousetail
mousetail
I tried putting export LC_ALL=C.ISO-8859-1 before running the script because I couldn't figure out how to set environment variables in combination with the timeout function, but that might have broken something
 
ais523
ais523
aha, there's a special case in jelly/interpreter.py, on line 1303, that specifically checks to see if the locale is set to a Unicode locale – if it isn't, the output is encoded in the Jelly code page
so it's a bug in Jelly, but one that might be impossible to work around
 
mousetail
mousetail
That's unfortunate :/
I'm surprised both Vyxial and Jelly seem to have fundamental issues with this basic task
 
ais523
ais523
ooh, may be a workaround of using LANG rather than LC_ALL, I'm testing this at the moment
most golfing language designers don't take locales into account, because CGCC's rules rarely go down to that level of detail in I/O requirement
 
mousetail
mousetail
I mean not caring about locales at all would solve the problem. Just read and write bytes
Avoid dealing with locales and unicode entirely
 
ais523
ais523
1:59 PM
then you can't read input
but LANG does seem to work
I will update both of my Jelly solutions to specify using that rather than LC_ALL
 

« first day (4 days earlier)    last day (39 days later) »