News for hackers. Stuff that matters.

jackdaniel

Re:AI promised less work. I've never worked more on Tuesday October 27, 2026 @08:36AM (#50258192)
or the cognitive strain from trying to understand and rubberstamp a word salad is bigger than working through problems
Re:Heavenly delights of hashing numbers under EQUALP on Monday October 26, 2026 @11:38AM (#50245593)
A case study of recent work on EQUALP hashing in Embeddable Common Lisp with microptimizations and benchmarks comparing to other Common Lisp implementations.
corporate incentives turned into a laughing stock :p
Re:What will our economic future look like? on Wednesday September 09, 2026 @01:51PM (#49630471)
I did not state any goals, I've only falsified your naive claim.
Re:What will our economic future look like? on Wednesday September 09, 2026 @10:56AM (#49627669)
Lowering prices or raising wages due to increased productivity is not a given, and often does not follow. There is more to pocket by shareholders though.
Re:Building an AmigaOS Development Environment in 2026 on Monday July 20, 2026 @06:25AM (#48976799)
I've recently built Linux dev environment for Amiga and documented the process in a form of a blog post.
Re:The curious case of retro demo scene graphics on Monday March 30, 2026 @02:32AM (#47571092)
This is quite tone deaf - demoscene stands for creativity and resource constraint, and using ai cancels both in favor of resource intensive cognitive offload
Re:Cross-Compiling Common Lisp to WASM on Thursday December 04, 2025 @03:40AM (#46145193)
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.
Re:Show HN: Using Common Lisp from Inside the Browser on Thursday August 21, 2025 @11:11AM (#44973781)
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.
Re:Show HN: Using Common Lisp from Inside the Browser on Thursday August 21, 2025 @11:05AM (#44973704)
There's also Guile Hoots compiling directly to WASM.
Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @04:12PM (#44381393)
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.
Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @03:15PM (#44380915)
Btw, eval (ed "wecl.lisp") to see some interesting function definitions, like canvas or webgl access drafts.
Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @01:57PM (#44380085)
With enough code - yes. But not right now. You may precompile to native though.
Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @01:50PM (#44380005)
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.
Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @01:48PM (#44379989)
What a bunch of fud..

If you want to make mcclim progress faster then chip in with actual expertise instead of unfunded snarks.

ECL is a stable implementation with actual users, if you can point out existing problems then please report them.

Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @01:32PM (#44379836)
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.

Re:Web Embeddable Common Lisp on Wednesday June 25, 2025 @01:15PM (#44379687)
This is just a test page. Today I've shared an information about an accepted grant proposal:

https://functional.cafe/@jackdaniel/114742776265318353

The work will go towards improving browser integration and porting to WASI.

Re:Maxima in the browser using Embedded Common Lisp on WASM on Wednesday January 29, 2025 @04:32AM (#42863136)
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).

Relevant links: https://gitlab.com/embeddable-common-lisp/ecl/-/merge_reques... https://github.com/ivmai/bdwgc/issues/650

Most notably an entry in the INSTALL file:

``` 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) ```

Re:Maxima in the browser using Embedded Common Lisp on WASM on Tuesday January 28, 2025 @04:30PM (#42858303)
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).

Re:Maxima in the browser using Embedded Common Lisp on WASM on Tuesday January 28, 2025 @12:46PM (#42855439)
Scheme requires TCO. It is a different Lisp (it also has standard[s]).
Re:Maxima in the browser using Embedded Common Lisp on WASM on Tuesday January 28, 2025 @12:20PM (#42855015)
Common Lisp does not require TCO. This runs on emscripten port of Embeddable Common Lisp - this platform support is relatively new. I'm also working on WASI port and an optimizing compiler at runtime (currently we use bytecodes compiler when running).
Re:Maxima in the browser using Embedded Common Lisp on WASM on Tuesday January 28, 2025 @11:38AM (#42854371)
Web version of ecl when compiler is invoked at runtime, uses one-pass bytecodes compiler, so things tend to lack optimization unless compiled beforehand.

Older »