@pxeger Oh yes, it'd be totally organic, I just wouldn't disclose my affiliation with Vyxal :P

@pxeger I don't think there'd be much risk of us accidentally DDoSing it, right? That'd only happen if the post got very popular, which is not too likely

Wouldn't any site be at risk of being ddosd if it's shared around?

But you're assuming it becomes super hot on HN and everyone actually tries to go there to try out Vyxal, which is probably not going to happen (unfortunately? fortunately?)

I more mean any site in general

You'd have to ask Aaron

I feel like PA sites would be at a higher risk of that happening because PA might restrict how many people access it? idk tho

@user people ddos PA without HN influence so I'm sure it'd be no different lol

Ah, no worries about that then because we're already at risk for it :P

Exactly lol

mobile.twitter.com/pythonanywhere/status/1413476278154539012

That's the PA twitter account

Hrm, what is this new feed? Ah

I figured we might as well have their twitter feed in here given that our site is reliant on them

Because then we can be notified if they're doing site maintenance or whatever

Goodidea

Uh oh, it's going to be doing that for a while.

→ 5 month-old twitter posts moved to ­Trash

Mmm yes it doesn't one box

Thank you feeds

Maybe it should be a vyxal bot thing

@hyper-neutrino Add PA twitter feed to Vyxal bot so it can post messages instead of links?

idk how to do that but sure

it's just adding a RSS feed to vyxal bot right?

rss.app/feeds/Hm5iCT7sS4MkyKon.xml is the feed url

tutorialspoint.com/python_text_processing/…

well i could try

never done it before

this is where we're at

and I almost pasted that into the Velay room by accident

lol

btw v2.6pre2 is dropping in a few minutes

Lyxal closed issue #271 (`¨M` always casts `b` to an iterable, Vyxal/Vyxal)

v2.6.0pre2

GAMING!

gaming.

now for flags and CLI

tenor.com/view/…

that's the checklist for actual 2.6 release

notice how I scribbled out an item

that's because I can't be bothered to do that and because I want to drop the full version by december

why not keep dictionaries for other languages so they can come up like twice

smh

no no it's gonna happen, just not for 2.6

it'll probably be a 2.6.1 thing

ah

yeah makes sense

> I want to drop the full version by december

december is only a week and a bit away

meaning we have that long to tie up loose ends

Lyxal closed issue #269 (Digraphs to implement, Vyxal/Vyxal)

Lyxal opened PR #272 (Vyxal/Vyxal) (Vyxal:digraph-implementation → Vyxal:fresh-beginnings): Digraph implementation - yeeting 2.6.0pre2 into base.

@user why is there a black linter error when I format my code using black?

@lyxal Yeah, I wasn't planning for that to be part of the rewrite.

@lyxal uh so you played games and the code generated depending on how good you played the games?

Idk

@user the black formatting error is probably because it doesn't have the line length 80 flag enabled

> Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.

> occasionally

took me a hot second to realize you meant hackernews and not hyper-neutrino

Lol

like it has the word news in the name

and i've also never actually browsed it

fun fact: you can add black as an extension for a metric crap top of editors

@user I fixed the black check by just changing the workflow to use a custom black check

the sweet, sweet look of 2 successful workflows

I think we could be managing our branches a bit better. It's best to keep branches either: very short-lived (only one feature (e.g. a single digraph or adding a single workflow)), or very long-lived, like master or fresh-beginnings. In the case of a long-lived branch, it should only be added to by merging short-lived branches. (Or for very minor changes like typos and whatnot, it's ok to work directly on the branch)

@lyxal @user @emanresuA @UnrelatedString @PyGamer0 ^

@pxeger that's what digraph-implementation was (is) supposed to be

I figured seeing as how it was for the rewrite, it'd be fine if it was a little longer lived

I thought it was just for implementing some digraphs

If it wasn't, why was it called digraph-implementation then lol

sure, something like all-digraphs would have been more appropriate, but I figured just for the last stretch of the rewrite, it'd be fine

btw I fully agree with the idea of short-lived branches being PR'd into the long-lived branch

btw, the point of this is to avoid massive merges and therefore massive code review tasks

yeah, I kinda realised that when I opened #272

it's a bit late to apply that to the rewrite now (given that it's almost done), but those principles can be applied to bug patches and other feature requests in the future

ok!

probably not the best stats to have for a PR ngl

yeah lol

I mean, it's ok for something like merging long-running projects into master (e.g. the rewrite, or if we decided to switch to bytecode compilation)

but you don't want it too much lol

of course and I fully understand what you mean

I suppose I more wanted to just focus on getting this rewrite finished than think about practicalities

also pxeger while you're here what do you think of my proposed release schedule?

looks good

if it helps avoiding what happened with 2.5, I'm totally on board lol

It's also because sites like emkc.org/challenges can't exactly keep up to date with the latest commit, but they can update to new versions

@pxeger i dont think i manage anything here

@PyGamer0 I just pinged everyone who had sent a message recently, sorry lol

(also I just realised I forgot h-n)

HackerNews or Hyper-Neutrino? ;p

hackernews

the latter lol

of course

@pxeger ofc, I was just making the obvious joke lol

huh, looks like I lost the corpus code

this corpus btw

I think I had it saved somewhere, when you sent it to me

Let me see

nope, doesn't look like it I'm afraid

I don't think it'd be too hard to make one based on an existing one for a different language (e.g. the Jelly one)

I'll probably base it on the Husk one

I've just realised I'm commenting "complex numbers?" on basically every arithmetic builtin you added in this PR lol

what about them?

they should be covered by sympy

I think they need tests at least

if not for actual unit testing but just for documentation to quickly see the behaviour on edge-cases

> TypeError: 'complex' object is not iterable

I'm guessing that's because it sees complex isn't numeric, so it assumes it's an iterable and tries to vectorise

that's coming from the vyxalify function trying to parse the 3j in the test case

so it isn't even getting to the main function lol

huh lol

because vy_type already accounts for complex

but the vyxalify function didn't

there we go it works now that vyxalify knows to just return the value

and ofc I forgot to account for complex in simplify

ah dang

complex number support is gonna be a whole lot harder

elif is_sympy(value):
    return sympy.nsimplify(value.as_real_imag()[0], rational=True)

because imaginaries returned by sympy are realified

damn

and that was because having the imaginary part was screwing up the test case comparison and because you can't exactly have imaginaries as rationals

that's gonna take some major thinking about

more thinking than my tired brain is capable of right now

lol

i'mma go sleep to recharge lol

!!/'night

@lyxal o/

\o

(before I go, thanks for the help and suggestions pxeger, I appreciate it)

:)

don't think too much before bed lol

get some rest!

Ha, I never think :p

Be like me lyxal

@pxeger I second this, reviews on big merged afe useless

Why doesn't vyxal have a builtin to change my sheets? It's really annoying doing it manually

Also yay 2 successful tests

way up at 2? wow!

@pxeger make a challenge to do it and I’m sure some golflang will add it as a builtin :p

@pxeger i meant checks whoops

I mean come on, mathematica has it!

couldn't we have it, even as a digraph?

Wait what

joke

pxeger approved on PR #272 (Vyxal/Vyxal): "Lots of comments, but \almost all minor things that shouldn't prevent merging, so I'm approving"

oh boy lol

Comments are good

@pxeger aww, i was hoping matgematica could do my irl stuff too

Ok, I have had a thought.

(dangerous, I know...)

...Yes?

I'm typing!

Oh whoops, I forget this isn't Discord (or any other chat thing where you see that)

Why do we need separate characters to close function definitions (;), if-statements (]), while loops (}), and for loops ())? If we replace them all with ;, we can free up 3 more one-byters!

I think this was suggested before, and the answer was readability ¯\_(ツ)_/¯

golfiness vs readability is a difficult trade-off

If we do use ; to close everything, I don't think we should use symmetric characters like [, {, and ( to open (because it'd be confusing later when you use ] as a command instead of using it to close [)

@pxeger Java chose to trade both of them off :P

@pxeger IMHO it's kinda silly to make a language which tries to achieve both, because they're both such polar opposites, so I think Vyxal should aim to be the golfiest (first), but without completely disregarding readability

but that would mean we can sacrifice readability (sometimes)

We already do sacrifice readability tbh

so why not sacrifice this one more thing?

I would second this as long as we can come up with decent-looking examples of code written with a new syntax

just indent them properly and it won't look too bad

practical languages don't have a problem with } being used to close all kinds of structures

But they also open everything with {, unlike Vyxal

so just do this

Yeah

That user makes a lot of sense :P

> It appears to be a necessary evil as long as we make stack a global variable like that

could we make stack an attribute of ctx?

I wanted to do exactly that :|

(or just put global stack somewhere in the function header?)

But errors happened

@pxeger Oh that's much easier to do lol

(ref: github.com/Vyxal/Vyxal/pull/272#discussion_r753811667)

cgccuser approved on PR #272 (Vyxal/Vyxal): "There are things to be fixed, but I think we can merge now and fix those in a separate (short-lived) branch."

lol, my later replies to pxeger's comments were turned into separate comments

Should've finished all my single comments first and done the review later

@lyxal Regarding this, can we have ẋ not do string multiplication for str-num and instead treat it like any-num?

@user I think they're there as replies as well, but GitHub doesn't load all of my comments initially because there are so many of them, so it thinks yours are orphaned. If you go to Files Changed and open the actual diffs, you can see the proper conversations

Ah

chunkybanana approved on PR #272 (Vyxal/Vyxal): "looks pretty poggers, the minor things can wait"

Hmm yes the joys of having email and github app notifications on the same phone

!!/run 81 3 •

@lyxal 4.0

🤔

Unless you mean actual base conversion ofc

Oh lol

I take back my thumbs up, pxeger

@lyxal what do you think about pxeger's proposal to end all structures with ;?

It'd probably have to be a version 3 thing because backwards compatibility

Yeah

Lyxal merged PR #272 (Vyxal/Vyxal) (Vyxal:digraph-implementation → Vyxal:fresh-beginnings): Digraph implementation - yeeting 2.6.0pre2 into base.

Lyxal deleted branch Vyxal/digraph-implementation

That's for later reference for me to know how to make workflows for all branches

Lyxal created branch Vyxal/cli-implementation

This new branch is purely for adding flags

there shouldn't be any element changes on this branch

Lyxal created branch Vyxal/pr-272-suggestions

That's for doing the suggestions from the comments on the recent PR

__main__.py shouldn't be changed on this branch

(@pxeger is that an appropriate way of managing branches?)

We could probably just do pr272 right now and then open up cli later but ¯\_(ツ)_/¯

note that I want to get 2.6 out by December, meaning that getting the CLI done has a somewhat higher priority than suggestions from pr272

Lyxal opened issue #273 in Vyxal/Vyxal: 2.6 Release Checklist