This is quite tone deaf - demoscene stands for creativity and resource constraint, and using ai cancels both in favor of resource intensive cognitive offload
Not knowing the scene and only what I took from the article - it’s precisely this. There is a reverence towards human labour and effort that affords relaxing what are generally accepted social contracts in other areas (e.g. copying). It’s a very interesting social construct where the self-policing is in a very specific are whilst other areas are forgiven.
to be honest I feel much more comfortable with git -- muscle memory, magit etc., but fossil is much more appealing when you look at the underlying model and how it bundles wiki and issues along with the repository; that's why I'm starting as of late all my solo projects with fossil repo.
CL enables many paradigms of programming, including functional one and imperative. Currently the most popular way of programming among CL programmers is OOP with CLOS.
Bytecodes compiler used in this build from repl is one-pass with very little optimizations, so it is not surprising. Natively compiled code is much faster.
ECL features native code and bytecodes vm for targets without incremental compilation support - both native and bytecode can be freely mixed at runtime.
That means that you may interactively use repl to call functions that were compiled ahead of time and to add new functions even on uncooperative targets.
After you've finished prototyping you may compile the finished library to native ahead of time.
I didn't plan explicitly for SLIME, but loading swank shouldn't be much of a problem. The missing piece would be a bridge between a websocket and tcp I think.
It's worse, it is -O0 -- this is because of the GC and binaryen/llvm interaction. For GC to work we need to spill stack call pointers (and binaryen has such a flag!), but for the optimization level 1 and above said pointers are sometimes optimized away :3
I'm experimenting with WASI and the GC extension for WASM, but that's months from today if we speak about complete port (given my time capacity at the moment).
WasmGC would be the best solution here, yeah, then the VM handles pointers for you.
Otherwise, I could look into the SpillPointers issue for you if you want - optimizations should not remove GC pointers, so that sounds like a bug. If so feel free to file an issue with a testcase. (But WasmGC would be best, avoiding all that.)
As far as I know, optimization levels higher than -O0 work fine with SpillPointers. But at least in a cursory first look I had a while ago, the optimizations made things slower overall. I guess they might lead actually to more "moving pointers in and out of the heap" since the SpillPointers pass is done at the very end. But this should all be investigated more thoroughly.
Hey! Thanks for the offer and thanks for the correction. I've revisited relevant threads and it seems that it is indeed -O0 because things are slower with higher optimization levels (I must have misremembered).
```
the optimization level -O0 is used because higher optimization
levels seem to interfere with the binaryen options needed to get the
garbage collector to work correctly and tend slow down the program
(might be worth experimenting with the optimization options)
```
reply