/opt/vsl/vsl build -t obj "${TIO_CFLAGS[@]}" -o .obj.tio .code.tio >&2
clang -o .bin.tio .obj.tio
./.bin.tio "$@" < .input.tio

@Downgoat Does this look correct?

@Dennis that looks good.

@Downgoat OK. What about the location of lib/vsl/transform/typeLookup?

@Dennis not sure how type lookup got there, must have accidentally clicked + draged in atom

That'll be fixed in nxet PR

Ah, sanity!

@Downgoat The latest VSL version is now live.

@Dennis Could you please pull Dirty? The bug has been fixed.

@Οurous Done.

I'm curious: what was going on?

@Dennis The way I was checking how many elements were on each stack was forcing the main stack to be evaluated more strictly, because there were more checks as it's a more complex (multi-layered, sectioned) stack. So if enough operations were performed on either the left or right stacks before the result of said operations was required, the call stack exploded because the runtime had to dive all the way down to where the value was returned.

Credit for thinking about that, and for the idea for the fix both go to @Potato44, who mentioned a similar symptom occurring in Haskell, and reminded me about head-strict lists which were fixed in Clean since the last time I'd checked them, so now the first few elements of each stack are always evaluated at all times.

@Dennis also thanks for pulling, once again please?

@Dennis Could this be being caused by TIOs ram-compression thingy? tio.run/##S8ksKqn8/9/QAAr0HrVPN6jWrlX8//… <- that runs fine, but remove one zero from the large number and it blows the heap

@Οurous 10000 works fine, but 100000 blows the heap, does clean have some kind of max heap size?

The heap blows somewhere between 75000 and 76000

I have a guess on why the heap is filling up, I'll explain in the dirty room

@Dennis: Request to update stax. I've released 1.0.6. Thanks.

@Dennis The issue mentioned just a few messages above ^ has been fixed now, could you pull Dirty again please. Unfortunately TIO / Linux Dirty in general will take a large performance hit until the marking GC is fixed, but it will work sensibly until then.

@Οurous I tried. The results are identical if I disable zram.

@Οurous Done.

@recursive Done.

Thanks.

@Dennis Could you please pull Attache?

As soon as I get home.

Thank you, Dennis, for having an unnecessarily large maximum request size that lets me dump a serialized version of my company's entire database in the Input field that I can play around with without instantiating a new project locally every time I want to test something.

It's probably doubled my productivity.

:P

Glad it's useful for something.

@ConorO'Brien Done.

@Dennis Thanks, and also thanks for checking.

@Dennis Thank you!

@Dennis New Mathematica version just released, if you could update it. (However you update Mathematica).

There's now a built in for currying and partial application, so this is really exciting stuff.

psh, attache had that days ago

@Pavel I'll have to ask how I get the new version.

@Pavel "exiting stuff" (Do you mean exciting?)

Goddammit I spelled it right and then corrected it to be wrong

@ConorO'Brien Curry also lets you generate a curried function with the arguments set in an arbitrary order, which is neat.

:P nice

not really, it's something I hacked together and is probably 1000% inferior the Great and Mighty Mathematica R&D

Not necessarily, it's marked Experimental

Might still be broken

@ConorO'Brien psh, Clean & Haskell had that decades ago

@Οurous What mathematica used to have was that commonly curried functions were manually overrided in the standard library to take just one argument, so you could still do cool functional programming tricks, but now you can do cooler functional programming tricks.

@Dennis Could you pull Dirty again please? There was an issue with the handling of zero when casting to symbolic types.

@Οurous That didn't work. Compiling arithmetic is failing again.

@Dennis What's it saying?

Generating code for 'arithmetic'.
code generator exited abnormally

Same thing as last time.

@Dennis Try again?

Awesome. Thanks.

@Dennis Could you pull again please? Off-by-one error on wrapping strings this time.

Ah, off-by-one errors, the two most common problems in programming.

@Οurous Done.