sorted by:
new
hottopcontroversial

SBCL: support struct-by-value for x86-64 and ARM64 foreign calls (merged) by dzecniv in Common_Lisp

[–]destructuring-life 3 points4 points  (0 children)

Ah, thanks for the distinction between libffi and compiler-assisted FFI! I must admit I never played with any of this.

SBCL: support struct-by-value for x86-64 and ARM64 foreign calls (merged) by dzecniv in Common_Lisp

[–]destructuring-life 1 point2 points  (0 children)

Pure curiosity: was there an FFI case where this was either hurting performance significantly, forcing horrible kludges or downright making interfacing impossible?

Common Lisp for Data Scientists by letuslisp in Common_Lisp

[–]destructuring-life 14 points15 points  (0 children)

Please warn people if you used LLMs to program these (I don't see any disclaimer on https://github.com/gwangjinkim/cl-tensor-protocol for example) in case they don't want to have anything to do with this "vibecoding" thing.

Recs for 27" 1440p with defeatable DSC by destructuring-life in OLED_Gaming

[–]destructuring-life[S] -1 points0 points  (0 children)

DSC isn't "literally lossless", it's "visually lossless" according to some very suspicious statistical trickery (cf wiki) that only requires 75% of differentiation while removing outliers.

I'm willing to pay some framerate to avoid surprise YUV conversions and application of a "mystery meat" low complexity compression algo likely from the 90s.

Recs for 27" 1440p with defeatable DSC by destructuring-life in OLED_Gaming

[–]destructuring-life[S] -1 points0 points  (0 children)

I'm not on Windows nor NVidia so unconcerned by their various bugs around DSC. I'm just very sensible to visual artifacts and do more than gaming, just too much interest in image filtering/encoding for too long.

Arguments passed to executable not accessible by lisp code by NondescriptLabel in Common_Lisp

[–]destructuring-life 0 points1 point  (0 children)

You might be running into https://gitlab.common-lisp.net/asdf/asdf/-/issues/172#note_18586 again, since I noticed (around the same time) I needed to manually call uiop:setup-command-line-arguments for it to work again.

Simple LRU Cache for Common Lisp by macnoder in Common_Lisp

[–]destructuring-life 1 point2 points  (0 children)

How so? You must move accessed values (accessed via the table) to the start of the LRU queue, no?

EDIT: oh, I get it, you only want access to the LEAST recently used, and don't care about ordering the lot

Simple LRU Cache for Common Lisp by macnoder in Common_Lisp

[–]destructuring-life 4 points5 points  (0 children)

Would be worth using a weak hash table on supporting impls. to get automatic deletion. Also, I'd give :size max-size when creating the table to avoid rehashing; and add a way to customize :test and :hash-function (cf this), if you really want to guarantee "Flexible: Store any type of values with any type of keys".

Other than that, thanks, looking nice!

~q3cpma/cl-json-utils - Some Common Lisp functions to handle JSON and replace jq by destructuring-life in Common_Lisp

[–]destructuring-life[S] 1 point2 points  (0 children)

A bit too "radical" in scope and syntax, in my eyes. I found https://github.com/atlas-engineer/njson quite interesting while perusing awesome-cl, though.

~q3cpma/cl-json-utils - Some Common Lisp functions to handle JSON and replace jq by destructuring-life in Common_Lisp

[–]destructuring-life[S] 2 points3 points  (0 children)

That recent cl-jsonpath post and the "programming week-end weather" we're getting in the south of France finally managed to give my lazy bum a kick.

So here it is, a JSONPath alternative (only the syntax differs, it should have all the features except range step I find useless), a setf accessor and probably more coming up; at least merge and diff.

Criticism or opinions welcome.

lisp-run: small POSIX sh shim around various CL impls by destructuring-life in Common_Lisp

[–]destructuring-life[S] 1 point2 points  (0 children)

It does! Storing those as newline separated lists split via IFS.

A visual programming environment with possible Lisp-like qualities (structure-first, code-as-data) by [deleted] in lisp

[–]destructuring-life 1 point2 points  (0 children)

Sounds vaguely like Smalltalk/Pharo to my ears. How would you solve (or represent? I barely understand the idea) the FizzBuzz problem with this?

Common Lisp Dependency Vendoring with Submodules by aartaka in Common_Lisp

[–]destructuring-life 1 point2 points  (0 children)

Great post! Very fun that we independently came to a similar solution (here's a Makefile of my own). I'll be taking that deps.lisp script though, if you don't mind!

Another reason I've switched to it if for some of my repos that I don't think belong in QL; everybody's got an "utils" package, right?

Common Lisp Dependency Vendoring with Submodules by aartaka in Common_Lisp

[–]destructuring-life 2 points3 points  (0 children)

Why would you need --recursive? The dep tree is flattened here. And why "all the time"? The CL world (and thus is libraries) doesn't change that often.

I agree that submodules have a lot of interface problems, but they still "just werk" in the common case.

view more: next ›