A Lisp framework for the creation of electronic art, visual design and more | Hacker News Reader

A Lisp framework for the creation of electronic art, visual design and more

github.com

162 pointsgnocchi40 comments

If Sketch interests you, you may also be interested in joining the Lisp game development community at #lispgames on Freenode. We had our first Lisp game jam in January and will be having another one soon.

Sweeeeet! When ?

We haven't decided yet, but possibly in April. We host the jams on itch.io. Here's what January's looked like: https://itch.io/jam/january-2016-lisp-game-jam

Are there people/organizations I can follow on Twitter to watch out for the next jam? I would love to participate in a future event, but have a hard time keeping up with IRC.

David O'Toole's twitter account is a good one to follow for updates. https://twitter.com/dtotoole

Thanks!

Hi all, author here. Thanks! Finding Sketch on top of HN was very unexpected. If you need help running it, have suggestions, or just want to chat, ping me at #lispgames on freenode, or here.

Sketch looks fun and intuitive. I'm looking forward to experimenting with it! :)

I'm very close to being able to run the examples, but I'm seeing the following issue when running `(ql:quickload :sketch)`: "debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD "main thread" RUNNING {10039CE893}>: Error while trying to load definition for system st atic-vectors from pathname /home/peter/quicklisp/dists/quicklisp/software/static-vectors-1.6/static-vectors.asd: COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "cffi-toolchain" "toolchain" "asdf-compat">"

Any idea why that might be happening? AFAIK, I've installed the appropriate dependencies. I'm running Debian 8, Linux 3.16.0-4-amd64 and SBCL 1.2.4.

Thanks!

Static-vectors, on which Sketch depends, needs to have a working C toolchain (C compiler, linker, etc.) installed. Maybe that's the problem here?

If you do have the toolchain installed, and can call the compiler with "cc", then maybe sbcl's PATH is wrong. You can try copying your env PATH to .sbclrc:

(require :sb-posix) (sb-posix:setenv "PATH" YOUR-PATH-STRING 1)

Thanks for following-up.

I've got gcc 4.9.2 installed and tried adding both my $PATH and the path to gcc to .sbclrc using the above, to no avail.

Maybe I'm doing something incorrectly? (Quite possible, as I haven't used CL in a few years.)

https://gist.github.com/ethagnawl/0af37c12cf2bd1b8063c

I think PATH should only contain folders, not the full path to your binary. But now I'm not sure if even that would help. It would be the best if you could join #lispgames or #lisp on freenode so we can debug it in realtime. We might even find someone there who has more experience with cffi.

OK. I'll check out #lispgames either tonight or tomorrow.

Thanks, again, for your help!

Anything simillar for Scheme?

you might find fluxus interesting. http://www.pawfal.org/fluxus/

Hypergiant for Chicken, maybe Lush and Ypsilon (code.google.com/p/ypsilon)

Take a look at http://extempore.moso.com.au/

It's pretty rough and volatile but I have my own somewhat unique game engine for Guile Scheme. https://dthompson.us/pages/software/sly.html

Nice, but my Guile version is too old. I guess I'd have to install GUIX ;)

For a lua equivalent see http://polycode.org

Looks super cool!

Looks like there's a lot of manual setup to get this going. That seems to be the case for a lot of CL stuff I've seen. Clojure actually has a few Linengen packages for this stuff, Overtone is one I recall for music/sound and Quil for visual design/art. Luminus is great for webapps as well.

Overall I think Clojure has taken most of what was good about lisp and turned it into a much more usable and friendly environment.

Note about Quil it is based around Processing[0] which reminds me a lot of how Dr Racket is designed (UI wise) which is really nice. I agree though, my probability in testing or using software rests upon setup, if it cannot be in a straight forward approach I'll likely not bother.

[0] http://processing.org/

> Looks like there's a lot of manual setup to get this going.

Which is one of the things the Processing[0] environment, whose API this apparently mimics, does better than most other applications I think: you download the PDE, a (completely portable) application, and when you open it you immediately see a basic notepad with a big "Compile And Run" button above it. None of the not-yet-relevant stuff you might see in a more overwhelming IDE[1].

EDIT: comment sniped by giancarlostoro! Dr Racket is a good point of comparison too, for sure!

> Clojure actually has a few Linengen packages for this stuff, Overtone is one I recall for music/sound and Quil for visual design/art. Luminus is great for webapps as well. Overall I think Clojure has taken most of what was good about lisp and turned it into a much more usable and friendly environment.

There's also thi.ng[2]. I'm very curious to see how all of these compare, tbh.

[0] https://processing.org/

[1] https://processing.org/tutorials/gettingstarted/

[2] http://thi.ng/

thi.ng was just getting started when I last looked at Quil/Clojure. It looks a lot more interesting now, and Karsten Schmidt is something of a legend among creative coders.

>Overall I think Clojure has taken most of what was good about lisp and turned it into a much more usable and friendly environment.

For creative coding I completely agree. I think it's a much more rewarding environment than Processing, both from a programming point of view, and also creatively.

It's doable to make a single monolithic application out of Sketch as well, but I guess it hasn't been done yet (especially since most lispers use SLIME)

Did Clojure ever figure out how to avoid those completely unreadable java-style stack traces?

Because if not, it is an entirely unusable and hostile environment.

And though this package may involve a lot of manual setup right now, once it's in quicklisp it'll be just as easy as what Linengen offers.

    (ql:quickload 'package-name)

You're right, that is definitely the worst part.

Does your runtime still barf JVM stack traces?

Yup, pretty awful.

Not that much manual setup - just check it out into quicklisp local-projects directory, and run (ql:quickload "sketch")

Seriously, what kind of pre-done setup one needs these days? Even PDE-style package can be prepared for this with CL-launch and some editor support, and the editor is probably going to be biggest issue (if not using SLIME and Emacs).

what kind of pre-done setup one needs these days?

I'm building a new lisp. It's not ready to show yet, but we're aiming for "Someone running Windows using notepad.exe can still have a good dev experience." We've been calling this "devex" (developer experience) and set out to specifically focus on this area. Mostly out of curiosity, but also to see whether it's a fruitful approach in general.

It uses npm as a package manager, so the setup instructions to install any library are the same: "npm install foo --save". You can then open a REPL, type (require 'foo) and begin using that library. There's also a Homebrew formula for setting it up, for those who don't have npm, so library authors could take the same approach and offer a way to "brew install" their library. I imagine we'll provide a mechanism to make this easy.

It took about six months of focused effort to achieve that, and no one should feel obliged to go through the trouble. But it was doable, and it's pretty exciting to see it work.

Performance was the other objective, which also turned out to be achievable. It comes with several example programs, one of which is a software rasterizer that pushes 7 million pixels/sec. It's 200 lines of code, entirely Lisp. Seeing a smooth 60fps without spending any effort at all on optimization was very interesting.

Why are you using NPM? AFAIK it has horrible recursive dependency resolution.

> I'm building a new lisp. It's not ready to show yet

That sounds interesting. Is it SugarLisp? If not, please announce it also at HN.

https://www.npmjs.com/package/sugarlisp

Not to mention, I'm sure once Xach has a look at this it'll be in a main quicklisp update soon.

Clojure is easier in that sense because it leans on the JVM, but it is missing a few very important things from CL like readabe stack traces. Somebody could repackage Sketch to make it user-friendly. Overtone runs on top of, or uses SuperCollider; you can't make your own ugens AFAIK. Extempore is a scheme-based audio\visual environment that is much more powerful than Overtone or Sonic Pi.

I think what I wrote was honest and factual, and it comes from my experience with all of the items mentioned. I did not resort to writing "barf JVM stack traces" like someone else in this thread, which is BTW a copy without quotes from a January 2014 blog article [1]. There must be people on HN just itching to downvote, or they somehow read wrongly into what I have written.

   [1]   http://www.loper-os.org/?p=42

EDIT - added link

Sorry for not quoting properly. I'll do better next time. :-)

The total setup you need is equivalent to what you'd need to do with Clojure.

1. Install runtime (JVM/CL implementation)

2. Install dependency loader (Leiningen/Quicklisp)

3. Install any native libraries required.

4. Get the package itself.

The last step is currently manual, but will be automated once Sketch is in a Quicklisp dist.

Which Lisp do you have in mind? The old Lisp Machines defined usable and friendly development environments. And modern Common Lisp is powerful and flexible environment that finally has easy enough package and binary management -

http://eudoxia.me/article/common-lisp-sotu-2015/

There is also libgdx which can be used from Clojure. Here is a window example: https://github.com/viperscape/libgdx-example/blob/master/src...

Reply on news.ycombinator.com