Notices by Daniel Kochmański (jackdaniel@functional.cafe), page 2

@screwtape the interface waits for well deserved refactor (see for accepting-value tickets on the repo). If you have certain requests about changes then the tracker is the right place to discuss it.

Thanks for the link!

@screwtape is there a recording of your presentation available?

@mdhughes @screwtape generally accepting-values is ran on behalf of a frame, so running it from execute frame command is correct (note that execute-frame-command *is* thread safe).

Re starting a frame in a background, you may wrap run-application-frame in make-thread, or use find-application-frame.

Note that soon (before christmas?) I'm merging a branch that adds thread-safe drawing and a repaint queue that speeds things up a lot and enables animations.

@amoroso well, that would be destructive uncommon lisp then!

@amoroso no, if it is not uncommon lisp, then it is common lisp, or at least something semantically compatible with it, isn't that right?

that's just one of ideas I'm playing right now when reworking parts of ECL -- Common Lisp without "Standard Library".

UCL - UnCommon Lisp
NUCL - Not UnCommon Lisp

Naming is the hardest problem in computing, but I'm pretty happy with these goofs!

I've send my application to NGI Zero for improving #ecl.

The goal is to create a comfortable environment for using Common #Lisp in a browser along with a JS bridge to:

a) use Common Lisp from a comfortable IDE in a browser

b) write web applications using Common Lisp (think <script type='cl'> ... </script>)

Keep your fingers crossed :)

I'm working on a proposal to @nlnet to improve ECL in the browser. Keep your fingers crossed!

#lisp

@dougmerritt @screwtape technically common lisp has both unnamed and keyword arguments, although the latter can't be specialized in standard generic functions.

There's also that many editors provide the function signature as a hint when you edit a function invocation; I don't know how this would work like with messages though.

@met

This branch is not fast; I've split recent works into two branches -- first thread safety, then repaint queue - because each feature is pretty independent.

FPS-wise untangling recording from drawing gives fps that goes easily above 4000fps (but it is throttled to go at 60fps); although recording technically may not keep up with this.

I'm working now on concurrent drawing from multiple threads. #lisp #mcclim

The color "leakage" is a sign of an issue that has not been addressed yet, the important part is that rectangles are drawn at correct coordinates and that the output does not get corrupted.

@alexshendi @screwtape @cwebber @dthompson @technomancy @gramian

(With-output-to-drawing-stream (s nil nil)
(Draw-circle* s 50 50 25))

Voila. Assuming wish is already game over portability wise.

@screwtape @lispm @nytpu @lispi314 @zoerhoff @mapcar

Regarding friendly commentary - they cosponsor european lisp symposium and donate to common lisp foundation, they do innovate and evolve by providing new software products and, I think, they are only vendor capable of providing enterprise support for big clients. From Lisp viability perspective they do good fo CL, even if their offer to individual devs is not good.