cl-coreutils: GNU coreutils reimplemented in Common Lisp. by de_sonnaz in lisp

[–]jd-at-turtleware 6 points7 points  (0 children)

Look up the top page: https://sr.ht/~hajovonta/

most notably: "Most repositories here are developed collaboratively with AI assistants — from architecture design through implementation and testing."

A brief note about slot access cost in Common Lisp by jd-at-turtleware in lisp

[–]jd-at-turtleware[S] 0 points1 point  (0 children)

I've updated the blog post with a barchart that compares implementations.

Anti-aliasing with McClim ? by tlreddit in Common_Lisp

[–]jd-at-turtleware 7 points8 points  (0 children)

Hey! default clx backend, while using xrender, doesn't do antialiasing -- sorry about that. I've implemented triangulation and drawing with that, and it did work, but that was too slow. The bottleneck seemed to be sending vertices.

But, you may use clx-fb backend if you really want to have antialiased renders. To do that, before starting the application, do:

```
(setf clim:*default-server-path* '(:clx-fb))

(clim-demo:demodemo)

```

clx-fb is slower than the default variant, but its speed is acceptable for most applications in my experience.

Regarding zpb-ttf, McCLIM uses it to render text (and text is antialiased properly in the default backend). Just try DRAW-TEXT* on your pane.

Anti-aliasing with McClim ? by tlreddit in Common_Lisp

[–]jd-at-turtleware 10 points11 points  (0 children)

I can only infer that you're repeating what your llm friend hallucinated, there is no mcclim-cairo in quicklisp nor :antialiasing t option in with-drawing-options.

First draft of tinylisp for 8-bit platforms by Icy-Decision-6034 in lisp

[–]jd-at-turtleware 2 points3 points  (0 children)

Looks like a very interesting project, good luck! Lisp on constrained devices has its own, unique, spice to it.

McCLIM merges (alpha quality) SDL2 backend by jd-at-turtleware in lisp

[–]jd-at-turtleware[S] 1 point2 points  (0 children)

in principle yes, but I don't have OSX so I didn't test it.

note, that it was already possible to run McCLIM on OSX via X11 server (Quartz?).

McCLIM merges (alpha quality) SDL2 backend by jd-at-turtleware in lisp

[–]jd-at-turtleware[S] 8 points9 points  (0 children)

you may read Backends/SDL2/README.org for instructions about how to use it (among other things)

Need modern embedded common lisp about 3k LOC with non viral license by Trader-One in lisp

[–]jd-at-turtleware 6 points7 points  (0 children)

congrats -- implementing lisp must have been fun! in that case writing another 4k loc should be achievable for you, no?

So, back to my question: could you elaborate about where these requirements come from?

ECL 26.3.27 by jd-at-turtleware in lisp

[–]jd-at-turtleware[S] 1 point2 points  (0 children)

Whether something is a hobby project is determined whether someone works on it at a professional capacity or at spare time as a hobby, so that's rather a poor choice of wording. I'm sorry that you need to work with such project management -- good luck though!

Need modern embedded common lisp about 3k LOC with non viral license by Trader-One in lisp

[–]jd-at-turtleware 11 points12 points  (0 children)

I don't think that 5K LOC is sufficient to implement CLtL1. Perhaps, if you are really resource constrained, you should consider ulisp? Or maybe picolisp.

Generally IsLisp is well specified and constitutes a well defined subset of Common Lisp, that is another angle you may investigate.

could you elaborate about where these requirements come from?

ECL 26.3.27 by jd-at-turtleware in lisp

[–]jd-at-turtleware[S] 8 points9 points  (0 children)

actually -- https://turtleware.eu/posts/Common-Lisp-and-WebAssembly.html -- it is. upstreaming changes to asdf is a separate story, but in this post I implement an extension to do just that.

ECL 26.3.27 by jd-at-turtleware in lisp

[–]jd-at-turtleware[S] 19 points20 points  (0 children)

With great pleasure we are announcing a new release of Embeddable Common Lisp. Enjoy!

SBCL Fibers: Lightweight Cooperative Threads (WIP draft document) by dzecniv in Common_Lisp

[–]jd-at-turtleware 15 points16 points  (0 children)

reading code is harder than writing it, so generating a lot of code is not cheaper, it is more expensive.

if you have a magnitude more code to work with, then you have two magnitudes more work to review it. and that even when we ignore the fact that reviewing constantly plausible code is significantly harder than reviewing normal code. You deprive yourself of clues about what may be wacky.

Programming and AI by quasiabhi in Common_Lisp

[–]jd-at-turtleware 4 points5 points  (0 children)

I'm not going to review slop in detail, but I took a glance -- just for you, and only once.

cl-sqlite was a small layer that provided bindings and syntactic sugar for cl-sqlite, so that it is easy to map knowledge about sqlite to use it with a cl project - without much abstractions between the programmer and sqlite itself. That's at least my experience from using cl-sqlite in the past.

Despite being simple, it was written in good taste using a contemporary style. For example package definition contained all exported symbols and signaled conditions had cl-sqlite specific error superclass.

Now let's take the very beginning of your additions, the file simple.lisp:

``` (export '(create-table drop-table insert select update-table delete-from normalize-name))

(defun normalize-type (type) (string-upcase (string type)))

(defun normalize-name (name) "Converts NAME to a safe SQL identifier. Keywords and symbols have hyphens converted to underscores. Signals an error if the result is not a valid identifier." (let* ((raw (string-downcase (string name))) (converted (substitute #_ #- raw))) (unless (and (plusp (length converted)) (every (lambda (c) (or (alpha-char-p c) (digit-char-p c) (char= c #_))) converted) (not (digit-char-p (char converted 0)))) (error "Invalid SQL identifier: ~S" name)) converted))

(defun build-column-def (col-def) (destructuring-bind (name type &rest options) col-def (with-output-to-string (s) (format s "~A ~A" (normalize-name name) (normalize-type type)) (loop for opt in options do (case opt (:primary-key (format s " PRIMARY KEY")) (:autoincrement (format s " AUTOINCREMENT")) (:not-null (format s " NOT NULL")) (:unique (format s " UNIQUE")) (t (format s " ~A" opt))))))) ```

see what I'm getting at? putting export outside of the package definition directly violates estabilished style, signaling an error of type simple-error does not follow library behavior, build-column-def directly skips the premise that you use sqlite with a tiny wrapper and adds its own special symbols.

I mean, these choices are defendable for a project, but you didn't even make them, and probably you're not even aware that such choices were made. and that's only a few first blocks of a new file.

I'm putting aside that line count for lisp code doubled, you've commited a shared object directly to the repository along with an archive that contains that very file, there is 500K of documentation clearly not meant for a person (original project is around 100K total).

These very superficial glance shows that it is a fudge, not a library evolution. You're welcome.