« first day (1022 days earlier)      last day (751 days later) » 

02:14
Hey, I wrote 5 Vyxal answers:
https://codegolf.stackexchange.com/questions/204813/golf-me-a-world-clock/257144#257144
https://codegolf.stackexchange.com/questions/252557/sample-from-the-discrete-triangular-distribution/257145#257145
https://codegolf.stackexchange.com/questions/252927/make-a-court-transcriber/257148#257148
https://codegolf.stackexchange.com/questions/257159/salacious-bacon-tripod/257179#257179
https://codegolf.stackexchange.com/questions/18925/hello-world-with-no-repetition/257365#257365
02:35
Nice
@lyxal Ooh, fancy
@lyxal And presumably we could get pxeger to add a separate "Vyxal (v3)" language, using the JVM
@97.100.97.109 edit that into the bounty post and I'll notify emanresu and razetime
@lyxal Galileo uses an Apache license, which seems to allow people to fork and distribute
Should I make a Vyxal/galileo fork?
Or I guess we could try to go as far as we can without an extra library and only use it then
03:04
That's a good idea
As far as we can libraryless
Obviously it'll be needed when algebra is a thing, but until then, we don't really need it yet
03:44
@lyxal Btw, do you want to try adding a Scala Native target?
Given that you seemed like you wanted it in that message
you said it makes things faster
and that's something I'd like
Ye
so yes
Alright, I'll make a branch
04:19
Hmm, we may want to try GraalVM instead. It won't be as fast as Scala Native, but it does mean we can use Java libraries. I'll try out that later too
There's troubles with scala native?
The regex isn't compiling for some reason
I guess the Pattern class that Scala Native has doesn't cover everything that the normal JVM Pattern does?
which regex?
(?=[^.ı])|\d*\.\d*(ı(\d*\.\d*|\d+)?)?|\.|ı|\d+)
It doesn't like the ^
[info] - Does the interpreter handle variable unpacking? *** FAILED ***
[info]   java.util.regex.PatternSyntaxException: Unknown inline modifier near index 4
[info] (?=[^.ı])|\d*\.\d*(ı(\d*\.\d*|\d+)?)?|\.|ı|\d+)
[info]     ^
[info]   at java.lang.StackTrace$.currentStackTrace(Unknown Source)
try \\?= instead of ?=
I know it's complaining about ^, but maybe it's because of the ?
apparently java regex is a little silly with ?s
04:34
Now the pattern compiles but 22 tests fail
I guess the regex is no longer correct
Is it possible to rewrite it without lookarounds?
hey wait where's the rest of the regex?
(0(?=[^.ı])|\d*\.\d*(ı(\d*\.\d*|\d+)?)?|\.|ı|\d+)
It's somehow missed a 0
Hmm
That's really weird
What are all the possible ways you can have a number?
\d+
\d*.\d*
\d*ı\d*
\d*.\d*ı\d*.\d*
\d*.\d*ı\d+
\d+ı\d*.\d*
Are there any more?
x
x.y
x.
.y
.
x.yıa.b
x.ıa.b
.yıa.b
x.yıa
.ı
.ı.
x.yı.b
x.yıa.
.yı.b
.yıa.
.ıa.b
.ıa.
.ı.b
I think
which might all be covered by the regexes
\d*.\d*ı\d+ is actually \d*.\d*ı\d*
also, 0
because 04 is lexed as a 0 and a 4
not just 4
Oh, that complicates things
hence the lookaround
how about (?![.ı]) instead of (?=[^.ı])
that removes the ^ and keeps the functionality
(I think)
04:47
I was thinking something like
private def decimalRegex = raw"(0|[1-9]\d*)?\.\d*|0|[1-9]\d*"
def number: Parser[VyxalToken] =
    raw"(${decimalRegex}?ı${decimalRegex}?)|${decimalRegex}".r ^^ { value =>
maybe that'll have to be it if the negative lookahead doesn't work out
Okay, that didn't work
the negative lookahead or the string interpolation regex?
String interpolation
Oh I'm dumb, I didn't wrap it in parens
Yeah negative lookaheads aren't supported either, same errors
Dang
Goofy regex flavour
04:54
Weird, this regex works on regex101, but 22 tests fail when I run vyxalNative/test
how does scala native work?
as in, what's it turning into?
Native code
It does AOT compilation
what java version do you have?
17.0.5
hmm so that's not the problem then
04:58
That same regex works when I do vyxalJVM/test
How the frick can they not have a proper regex implementation?
@user native as in java or jvm bytecode?
I think we might just have to use GraalVM lol
The performance difference won't be that much
@lyxal Native as in the thing that C and stuff compile to
Binary?
I'm not sure if that's what it's called
Machine code
they typically compile to assembly :P
machine code is the assembler's job
Okay, the thing that the linker outputs
Oh ok
well I figured out why the lookaheads weren't working
> This implementation of RE2 does not support: Lookaheads: (?=X), (?!X), (?<=X), (?<!X), (?>X)
that would explain it I think
05:02
lol ninja'd
No character classes either
wtf
Oh wait it does have character classes, just not unions and intersections
No predefined character classes
That must be why \d fails
bruh
I thought it just meant \h, \H, \v, \V
Oh
Then I have no idea what the "safe" regex I made contains that isn't supported
It's just 0, [1-9], \d, +, *, ?, |
I hope it isn't that it's failing on the unicode
that would just be really fricking stupid
05:06
It really would
tbf Scala Native is still using zerover
I removed the "i" thing from the regex but tests are still failing
Screw you, Scala Native
which tests? all of them?
22
Let me try listing them
there's only 10 number tests though?
Yeah, it also can't parse augmented variables and stuff
well that seems like a bigger problem than just the number regex
so there's apparently 23 lexer tests
05:09
I think literally every test involving parsing failed
sounds like the parser library doesn't play nice with native
Oh we should probably check the docs for that
Maybe they have a fix
so you're saying that if we were to roll our own lexer, these issues may go away
- Does the interpreter handle variable unpacking? *** FAILED ***
- Does the parser recognise lambda to newline? *** FAILED **
- Does the interpreter handle augmented assignment? *** FAILED ***
- Does the parser handle nested modifiers? *** FAILED ***
- Does the parser handle basic modifiers? *** FAILED ***
- Is the parser capable of parsing (something that looks like) FizzBuzz? *** FAILED ***
- Does the parser auto-close lists in structures? *** FAILED ***
- Can the interpreter vectorise simple dyads? *** FAILED ***
Element Ė
  - should properly execute code that uses the stack *** FAILED ***
  - should use the same context for executing the code *** FAILED ***
Well, 27 tests succeeded
Oddly enough, 2 lexer tests passed (5 failed)
The two that passed were "does it recognize numbers" and "does it differentiate between strings and dictionary strings"
@lyxal I guess, but who knows what other issues may pop up down the line?
that's...that's one of the tests that has the goofy numbers
05:17
GraalVM guarantees that all the Java stuff will work
It looks like it can parse numbers, but it also goes and parses other stuff for some reason
@user hol' up - why is the vectorisation model not working?
It's working
Just can't parse it
- Can the interpreter vectorise simple dyads? *** FAILED ***
(all of these tests pass with vyxalJVM/test)
there is no parsing in that test
05:18
Sure there is
Interpreter.execute("#[4 | #[5 | 6#] #] 3 v;")
then where is this test
I can't find it
InterpreterTests, line 33
oh I see it now
dang
The monads one does get parsed, though
So what's the difference that causes the error?
Wait no
The simple monads one doesn't work either
[info]   java.lang.Error: Error while executing #[100 | #[101 | 0#] #] vB: VyxalCompilationError(string matching regex '[ᵃᵇᶜᵈᵉᶠᶢᴴᶤᶨᵏᶪᵐⁿᵒᵖᴿᶳᵗᵘᵛᵂᵡᵞᶻᶴ′″‴⁴ᵜ !"#$%&'()*+,-./0123456789:;
[info] <=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\\[\\\\]^_`abcdefghijklmnopqrstuvwxyz{|}~¦ȦḂĊḊĖḞĠḢİĿṀṄ
[info] ȮṖṘṠṪẆẊικȧḃċḋėḟġḣŀṁṅȯṗṙṡṫẋƒΘΦ§ẠḄḌḤỊḶṂṆỌṚṢṬ…≤≥≠₌⁺⁻⁾√∑«»⌐∴∵⊻₀₁₂₃₄₅₆₇₈₉λƛΩ₳µ∆øÞ½ʀɾ¯
[info] ×÷£¥←↑→↓±‡†Π¬∧∨⁰¹²³¤¨∥∦ı„”ð€“¶ᶿᶲ•≈¿ꜝ]' expected but 'B' found)
Hmm, something sussy is the fact that we use "[$CODEPAGE]" without escaping regex or whatever
Which means that ^ is going to mess things up
it's only starting to occur to me now that maybe escaping the regex in the codepage variable might be breaking a few things
05:27
don't think that'd fix things on native, but I'll change everything to use it
hey wait won't that mean that there'll be troubles with js?
Regex.quote?
I was thinking we could just have a person manually write regex for command separately
Commands can't be everything in the codepage anyway
All tests passed! (with native)
I guess it must've been the command token thing messing it up
05:55
ysthakur created branch Vyxal/v3-native
ysthakur opened PR #1588 (Vyxal/Vyxal) (Vyxal:v3-native → Vyxal:version-3): Scala Native support
@lyxal I'm saying that if we use GraalVM, we won't have as many of these problems
I made a PR anyway, but if GraalVM turns out to be easy to set up in a GitHub workflow, it'll be much easier to just use that
06:22
ysthakur created branch Vyxal/v3-graalvm
07:03
@user then we might have to use that
 
1 hour later…
08:22
Don’t you just hate it when the cool thing you want to use just doesn’t work for you or isn’t ready
09:17
That's like half the libraries we've tried for v2 and v3 :p
 
2 hours later…
11:14
dang didn't realise it takes a bit to install the stuff for scala native
also:
> Download and install Visual Studio Community 2019
no thank you
guess I'm using ubuntu for scala native builds
| => vyxalNative / Compile / compileIncremental 110s
it may go brrr when executing code
it does not go brrr when compiling
136s now
184s
200s
oh
looks like it got caught in a sort of loop
Now it's the linkers turn to be a slow child
120s and counting
259s
300w
300s to link
Well at least the tests finished faster than they did when executing via jvm :p
 
2 hours later…
13:15
On the add-more-tests branch, I've made a few changes
first, I added something to help compare stacks
  def testStackLike(code: String)(tests: (List[VAny], List[VAny])*) =
    for (inputs, stackEnd) <- tests do
      it(s"$inputs -> $stackEnd") {
        given ctx: Context = Context(inputs = inputs, testMode = true)
        for i <- inputs do ctx.push(i)
        Interpreter.execute(code)
        assertResult(ctx.pop(stackEnd.length))(stackEnd)
      }
basically, "is the end of the stack returned the same as the expected stack"
useful for things like $ which operate on the stack
second, modulo has been changed from truncated integer to floored floating-point
because that's what's currently used in v2, and people like Knuth recommend using it
and third, I made calls to string formatting more like v2 behaviour
in conclusion, a little refactoring of %
> % (Modulo | String Formatting) (non-vectorising)
Ah
see that's a problem
because it both vectorises and doesn't
it does when you have a list and a number
it doesn't when you have a list and a string
but addVect makes the behaviour vectorise when you have a string and list
so I used addElem
but I don't know whether % should be marked as vectorising or not
 
3 hours later…
15:55
hyper-neutrino created a repository: Vyxal/vyxapedia
starting a rewrite; I renamed the old one Vyxal/vyxapedia-legacy
@lyxal Edited.
does vyxal have an official color
i found our style guide but it's code style :P also if anyone has a font choice lmk but otherwise i'll just use smth random for now
16:14
@hyper-neutrino the color we call bordoviy in russian. its a brownish red
idk if theres an equivalent in english
@hyper-neutrino some serif font
16:25
@Seggan maroon, maybe?
translate says burgundy
Other places say burgundy and claret
Hm yes, very different colors
are you being sarcastic
Yes
@Seggan Why serif?
looks nice
16:41
hmm
I like burgundy better so I'll use that
also serif? interesting
17:25
Lots of good fonts fonts.google.com/…
I've spent the past 20-30 minutes just scrolling through
yeah noto is a good one
Sort of a boring choice IMO
17:52
@97.100.97.109 Unrelated, but I don't think I've heard or seen any mention of the color maroon in the US (until that message)
I feel like I heard it all the time in India
I like Roboto
And Droid Sans Mono
Also boring though
How about Antic Slab?
18:03
@lyxal Windows amirite
I think you need to install Visual Studio even if you're developing C++ in Rider or VS Code or something else
18:22
^
So, uh, just found out that GraalVM executables aren't actually faster, they just start up faster
Good for short-lived applications, probably not so good if someone's doing some computationally expensive Vyxal stuff
Scala Native may outperform even a warmed-up JVM but now I'm starting to think we should just focus on getting Vyxal up and running before trying to get it to run faster, which we can do anytime
Sorry for the waste of time yesterday lol
@Seggan Did you mean to reply to that?
(or whoever starred that message)
18:38
no
19:24
I'll just clear the star
19:35
Oh, and because we use enums, which use reflection, GraalVM will need extra configuration to work, although that's doable
19:53
@user reply to what?
@user erm enums use reflection?
values() is generated by the compiler
unless scala enums are different
20:18
@Seggan The message that was starred
"Scala Native may outperform..."
@Seggan They are
I think it can be disabled
21:05
is there intentionally no distinction between structures like lambda and elements (in elements.yml)
21:49
@hyper-neutrino yes
Because structures are technically speaking elements
oh, I see
It straight up discards the original type information
And does everything over again
Oh
But once it's compiled it doesn't take a long time, right?
Also @emanresuA bounty time you nerd.
21:56
Yeah
You kinda have to make a tradeoff between long compilation times and long runtimes
So if someone wants to use scala native and isn't a developer, do they have to compile it?
Or is there something they can just run out the box
By "use scala native", do you mean use the scala native compiler thing to turn their code into an executable, or do you mean use our Vyxal executable created with scala native?
If the latter, no, it's just an executable that they can download and run immediately
If the former, yeah, they'll need sbt and llvm, but you always need to install stuff to develop software, right?
@user good
22:12
So after we're done adding more tests, what's next on the roadmap for v3?
Elements
Lots of them
All of them
Every single one and then even more
Aight
case (a: VList, b: String) =>
        if a.length != 1 then StringHelpers.formatString(b, a*)
        else StringHelpers.formatString(b, a(0))
Doesn't StringHelpers.formatString(b, a*) cover both cases?
(in modulo)
@lyxal Do we need to add a new addXXX? (or rethink the whole thing?) Are there lots of elements like this that partially vectorise?
@user now that I think about it, it probably does
If I change it to only use the first one and all the tests pass, does that mean we're safe?
Yes
22:17
Cool
It was 11pm logic
Meaning it's sure to be somewhat too complicated :p
I mean, better safe than sorry
Better to have unnecessary checks than to forget necessary ones
Gotta love having to implement your own numeric modulo
Yeah
Varies wildly between programming languages
Any elements/cases in particular that need testing?
Well all of them
22:31
lol
I'm just going through everything implemented and adding tests while there's still only a few things
So I'll be doing * next

« first day (1022 days earlier)      last day (751 days later) »