Vyxal

lyxal

12:14 AM

Hey so I have an important thing to discuss

how are we going to implement the D flag? (that is, don't dictionary decompress)

I've come up with 5 ways to handle it:

1. Pass a context value to the transpile function

2. Decompress strings during execution / make pushing strings a function

3. Make a module variable inside transpile that is set during flag handling

4. Have two transpile functions (one for decompressing with dictionary compression and one without) that are called at transpilation time inside an if statement

5. Have an optional (i.e default value) parameter dont_decompress for tranpsile

For option 1, the problem I have with it is that you're making transpile reliant on context, and that doesn't seem like the best solution

For option 2, the problem I can see with it is that it's potentially inefficient if you have a string being decompressed several times during execution (e.g. in a map/for-loop)

For option 3, the problem I have with it is that it relies on yucky globals which is what the whole rewrite was avoiding

user

@lyxal I think this one is okay

I don't particularly like decompression being a part of transpilation but it's more efficient than doing it at runtime

lyxal

For option 4, the obvious problem is code duplication

user

Wait, actually doing it lazily might be better

lyxal

@user well decompression has to happen somewhere

user

But then we'd need some kind of VyxalDecompressedString object that just has the original string at first and only gets decompressed later

lyxal

12:20 AM

it's either at transpilation or at runtime

@user correct

that just seems overly complicated

user

It might be nice for efficiency but yeah

lyxal

@user that's also kind of the premise of option 2

you create a function for pushing strings

What does everyone else think?

!!/hyperping

user

But simply having a function that does it each time would mean that in a loop, you would decompress the same literal over and over again

Vyxal Bot

@AaronMiller @AaroneousMiller @Allxy @Ausername @Fmbalbuena @Milk @PyGamer0 @Wansen @emanresuA @hyper-neutrino @math @pxeger @user ^

user

otoh, we're currently decompressing every literal whether or not it ever gets evaluated, so ¯\_(ツ)_/¯

@lyxal I dislike this

@lyxal This is okay but option 5 is probably better. No need to pass the entire context to it

lyxal

12:22 AM

@user same. I just wanted to come up with a whole bunch of options to choose from

user

Of course

lyxal

heh, I wrote 3 full A5 pages on the pros and cons of each option

user

O.o

lyxal

1:01 AM

CMQ: Should the transpiled code being printed for REPL sessions?

user

2:03 AM

No, unless you set a flag to see it

lyxal

Bruh how tf you gonna set a flag on the REPL

The whole point is that it's a Read-Eval-Print Loop

It's not CLI it's enter the expression and see the output mode

user

Obviously you add some syntax for special commands (maybe ]setflag f)

Repls can have extra syntax for repl-specific commands

(And you could of course set a flag when you start the repl itself, although that’d be inconvenient)

emanresu A

2:56 AM

@lyxal Option 6: Have an external decompression function that accesses an attribute of ctx.

lyxal

But the point is that ctx would have to be passed to that function somehow

Meaning that's just option 1

emanresu A

Oh wait, true...

lyxal

Besides I went ahead and did option 5 anyway and it works good

emanresu A

3:13 AM

@lyxal Nah, it works fine in v2 :p

"it's not a bug, it's a feature"

Aaron used it once in print x without x

!!/run 1 10 r ' 2 % ) \* * ¶

Vyxal Bot

@emanresuA (output was empty)

emanresu A

!!/run 1 10 r ' 2 % ) \* * ¶ j

Vyxal Bot

[@emanresuA: 59668682]
*
***
*****
*******
*********

emanresu A

Or...

!!/run 1 5 r ( n \* *, ; kH,

Vyxal Bot

[@emanresuA: 59668689]
*
**
***
****
Hello, World!

emanresu A

3:16 AM

See?

lyxal

yes, but there are some answers (mostly mine) that have proper closing brackets

emanresu A

O true

@lyxal I use proper closing brackets as well simply for the sake of explanations

lyxal

oh there's also now an e flag that lets you use the file name for code

emanresu A

ಠ_ಠ why?

lyxal

py -m vyxal '`ƈṡ`' 'e'

for easy CLI usage

jelly has it

emanresu A

3:24 AM

Oh

lyxal

so like instead of opening a file, it runs the provided argument

emanresu A

I thought it was like pxem style or something

lyxal

heck no

besides, that wouldn't work because file name restrictions

emanresu A

I can implement E / G :P

(On the frontend)

lyxal

E?

emanresu A

3:25 AM

E -> eval as JS (sandboxed)

G -> render as HTML (sandboxed iframe)

lyxal

oh uh one problem with G

!!/run `` h

Vyxal Bot

[@lyxal: 59668751]
ALL flags should be used as is (no '-' prefix)
	H	Preset stack to 100
	j	Print top of stack joined by newlines on end of execution
	L	Print top of stack joined by newlines (Vertically) on end of execution
	s	Sum/concatenate top of stack on end of execution
	M	Make implicit range generation start at 0 instead of 1
	m	Make implicit range generation end at n-1 instead of n
	Ṁ	Equivalent to having both m and M flags
	v	Use Vyxal encoding for input file
	c	Output compiled code
	f	Get input from file instead of arguments

lyxal

> G Print the maximum item of the top of stack on end of execution

emanresu A

Oh, it's taken

I forgot

Ġ then

Vyxal Bot

3:48 AM

Lyxal opened PR #274 (Vyxal/Vyxal) (Vyxal:cli-implementation → Vyxal:fresh-beginnings): Cli implementation

lyxal

how's that for short lived? ;p

but seriously tho I've done everything I needed to on that branch and it's genuinely ready for PRing

emanresu A

What about flags?

lyxal

that is flags

emanresu A

Including the ones from #160?

lyxal

those are half done

> Basically just the CLI - there's still flags that need implementing, but those can be done on the pr-272-suggestions branch.

emanresu A

3:49 AM

as in...

lyxal

so like they exist in context, and they are recognised in __main__.py but they don't do anything

because that would require modifying elements

4 hours ago, by lyxal

there shouldn't be any element changes on this branch

∴ they're half implemented

emanresu A

2 + 3 require a tiny bit of transpiler modification, t's probably more complex, w should just require a bit of modification of mapping, P requires modifying vy_str, i also requires map modification, and ĠE are frontend only.

lyxal

@emanresuA t should be easy because it's just boolify modifications

emanresu A

Oh true :P

lyxal

7:31 AM

Okay so it seems I need to make a main function that allows execution of vyxal from a function call rather than just a single file

I suppose that'll be used by the online interpreter too

and by the looks of things, that main function will be called from __init__.py

meaning that the main function should go in __main__.py

meaning it'd be imported in __init__.py as from vyxal import main

I think that's right

I still don't know what exactly to place into the scripts folder though

Nov 18 at 14:54, by pxeger

@user it's called a script; if you're using setuptools (with a setup.py), follow the guide I linked exactly; if you're using another tool (e.g. Poetry (<3)) then you need to check its documentation for setting up entry points and use console_scripts as described in that guide

the tutorial there has something like

#!/usr/bin/env python

import funniest
print funniest.joke()

in the script file

so I'm guessing a vyxal equivalent might be

#!/usr/bin/env python

import vyxal
vyxal.main(args)

also, can two branches be merged into the same branch without merge conflicts if it's made sure no conflicts exists between the two branches?

better question: will merging the cli-implementation branch (which changed __main.py__ and context.py) into fresh-beginnings cause merge conflicts when merging pr-272-suggestions (which will change elements.py, helpers.py, elements.yaml and so on - it won't touch the two files changed in the other branch) into fresh-beginnings?

you know what, there's only three changes in the pr-272-suggestions branch, which can easily be reproduced.

I think it's fine if it's deleted for now

Vyxal Bot

Lyxal deleted branch Vyxal/pr-272-suggestions

lyxal

there we go

easy

Anyhow I gotta go for now

!!/bye

Vyxal Bot

@lyxal o/

emanresu A

7:48 AM

@lyxal I thought you were calling Vyxal a joke :P

pxeger

@lyxal I mean, it's definitely not normal, but I don't see why it wouldn't work lol

Vyxal Bot

8:06 AM

pxeger approved on PR #274 (Vyxal/Vyxal)

emanresu A

8:26 AM

Vyxal promotion idea: KoTH written in Vyxal

user

12:32 PM

Mmm, I don’t think it’d get much activity

allxy

1:00 PM

Gaming.

2

lyxal

@allxy truer words have never been spoken

such inspiration for all of us

user

4:57 PM

Bruh

lyxal

10:07 PM

18 hours ago, by Vyxal Bot

Lyxal opened PR #274 (Vyxal/Vyxal) (Vyxal:cli-implementation → Vyxal:fresh-beginnings): Cli implementation

Vyxal Bot

hyper-neutrino approved on PR #274 (Vyxal/Vyxal): "poggers"

lyxal

Very good

Vyxal Bot

Lyxal merged PR #274 (Vyxal/Vyxal) (Vyxal:cli-implementation → Vyxal:fresh-beginnings): Cli implementation

Lyxal deleted branch Vyxal/cli-implementation

Lyxal created branch Vyxal/finishing-touches

hyper-neutrino

i like these smaller more frequent merges/updates

so i don't have to spend two hours reviewing

lyxal

@VyxalBot That branch is for doing pr272 suggestions and getting the server ready

hyper-neutrino

10:10 PM

kekw

lyxal

@VyxalBot Chances are this'll be the last branch before release

hyper-neutrino

pog

user

10:32 PM

^^^^^

user

11:30 PM

Hey @lyxal, can we use 2.6.xrcx instead of pre? PEP 440 says to only support a, b, rc, post, and dev, and setup.py gives an annoying warning each time that it's turning the pre into rc each time. Might as well go with that

wtf

Also, I think we should use # to start commands in the REPL, since using a single comment in the REPL is almost always unnecessary. If someone really wants a comment, they can put a space before it

lyxal

editing release notes re-releases

user

Oh ok, I thought it auto-edited somehow lol

Vyxal Bot

v2.6.0rc2

4

lyxal

→ 2 messages moved to Trash

just to be clear, those aren't new releases - I just renamed the 3 existing pre-releases

@user that could be for setting flags

user

Yup, we could have a command for setting flags like >>> #toggleflag f

My tabs right now

I use WSL for Vyxal stuff, and I was having crazy problems with getting the right version of Python to run. Still not completely fixed :\

But it does build and install scripts/vyxal on my computer. Hopefully we can start using python3 instead of python3.9 once 3.9 becomes the default instead of 3.8

Transcript for