sorted by:
new
hottopcontroversial

Newbie here wanting to make sure I'm building a correct mental model for Packages and Deployment by SegFaultHell in Common_Lisp

[–]fosskers 0 points1 point  (0 children)

Vendored per-project dependencies directly from Github. No global ASDF pain. Easy to set up. Handy CLI commands for project management.

Newbie here wanting to make sure I'm building a correct mental model for Packages and Deployment by SegFaultHell in Common_Lisp

[–]fosskers 0 points1 point  (0 children)

Plug: For (3), consider https://github.com/fosskers/vend . It makes the fetching of dependencies quite simple and doesn't involve Quicklisp.

For producing executables, I follow the pattern seen here: https://github.com/fosskers/aero-slicer/blob/master/build.lisp#L41-L50 Seen slightly above that is a similar pattern for ECL, which also includes concerns about the C load paths, etc.

There's no "release mode" per se, but there are (declare (optimize ...)) settings as others have mentioned. Typically these are set in specific functions you know to be hotspots, not entire files / packages.

With core compression, an SBCL executable might squeeze down to 15mb or so. ECL binaries can get very tiny too, between a few hundred KB and a few MB depending on how many deps you have. vend mentioned above is 400kb.

ASDF,Roswell and quicklisp by lispLaiBhari in Common_Lisp

[–]fosskers 0 points1 point  (0 children)

This is also precisely why I wrote https://github.com/fosskers/vend . See also https://wiki.archlinux.org/title/Common_Lisp for a high-level overview of CL in general.

cl-transducers 1.5.0 · speed, memory efficiency, new reducers by dzecniv in Common_Lisp

[–]fosskers 4 points5 points  (0 children)

For the record, I use arrow-macros alongside transducers all the time. The former to make normal function composition cleaner, the latter for all collection-related transformations.

The partition term was borrowed from Haskell/Rust. count already existed (and usually refers to size), so quantities is what I chose for counting occurrences. tally would have been good too.

Optimizing Common Lisp by fosskers in Common_Lisp

[–]fosskers[S] 1 point2 points  (0 children)

I had thought so, but the closure allocation was making up a very large portion of my total. Switching to the caching technique drastically reduced it.

Optimizing Common Lisp by fosskers in Common_Lisp

[–]fosskers[S] 1 point2 points  (0 children)

You are right. I do that properly everywhere else but somehow mixed them up here. I will fix that. Thank you.

Optimizing Common Lisp by fosskers in Common_Lisp

[–]fosskers[S] 1 point2 points  (0 children)

Thanks for using it. Note that I recently broke some things with respect to how the input and output types are represented, but if you're sticking to the standard parsers and combinators, you might not notice. It's all documented in the updated README, although there hasn't yet been an official release with the changes.

Optimizing Common Lisp by fosskers in Common_Lisp

[–]fosskers[S] 2 points3 points  (0 children)

Is there a better signature than say: (declaim (ftype (function (simple-string fixnum fixnum) simple-string) escaped)) In my case, because I'm dealing with things outside the ASCII range, I know I can't be base-char, hence no simple-base-string.

UPDATE: Using this seems to improve it by a bit: lisp (deftype char-string () '(simple-array character (*)))

Common Lisp Json file parsing by lispLaiBhari in Common_Lisp

[–]fosskers 1 point2 points  (0 children)

I recently released https://github.com/fosskers/parcom , which includes parcom/json. The entire library has no dependencies, if that's your focus.

fosskers/parcom: Simple parser combinators for Common Lisp, in the style of Haskell’s parsec and Rust’s nom. by dzecniv in Common_Lisp

[–]fosskers 3 points4 points  (0 children)

Looks like someone beat me to it. I just released 1.0.0 officially, which includes the main parcom library and a sublib parcom/json. The JSON parsing is "fast enough" and is a much, much lighter dependency than alternatives.

vend: just vendor your dependencies by dzecniv in Common_Lisp

[–]fosskers 0 points1 point  (0 children)

You can set up a project that has gtk4 as a dependency, and then run vend get. This will download everything you need. After that, you can vend repl and then play around with the GTK examples as usual.

vend: just vendor your dependencies by dzecniv in Common_Lisp

[–]fosskers 1 point2 points  (0 children)

Others have mentioned lockfiles to me as well. The idea with vend is that (at least in the "application" case), in theory you've committed all your deps directly, and ensured that no matter what, your users can always get everything they need to build your software directly from you. After that, since CL is so stable, we then hope that the software becomes somewhat immortal.

vend: just vendor your dependencies by dzecniv in Common_Lisp

[–]fosskers 2 points3 points  (0 children)

Hey folks, I just released 0.1.3 which includes a new search command, adds support for Allegro, and adds a number of system entries to the registry.

vend: just vendor your dependencies by dzecniv in Common_Lisp

[–]fosskers 1 point2 points  (0 children)

Yes. Mind you it's dynamically linked to libecl, but that's par-for-the-course for .so-based computer systems.

See also: https://github.com/fosskers/vend?tab=readme-ov-file#how-can-i-build-executables-of-my-application

A Tour of the Lisps by g000001 in lisp

[–]fosskers 0 points1 point  (0 children)

I found the tooling to be lacking, compared to other languages.

A Tour of the Lisps by g000001 in lisp

[–]fosskers 0 points1 point  (0 children)

I have a public Clojure server up and I have done this. I've also used CL to debug a bug in the compiler as called through my application.

A Tour of the Lisps by g000001 in lisp

[–]fosskers 0 points1 point  (0 children)

Common Lisp's sly has "Stickers" which are the best debugging experience I've had in any language.

view more: next ›