#quicklisp | Explore Tumblr Posts and Blogs

readevalprint · 3 years

Text

Ichiran@home 2021: the ultimate guide

Recently I’ve been contacted by several people who wanted to use my Japanese text segmenter Ichiran in their own projects. This is not surprising since it’s vastly superior to Mecab and similar software, and is occassionally updated with new vocabulary unlike many other segmenters. Ichiran powers ichi.moe which is a very cool webapp that helped literally dozens of people learn Japanese.

A big obstacle towards the adoption of Ichiran is the fact that it’s written in Common Lisp and people who want to use it are often unfamiliar with this language. To fix this issue, I’m now providing a way to build Ichiran as a command line utility, which could then be called as a subprocess by scripts in other languages.

This is a master post how to get Ichiran installed and how to use it for people who don’t know any Common Lisp at all. I’m providing instructions for Linux (Ubuntu) and Windows, I haven’t tested whether it works on other operating systems but it probably should.

PostgreSQL

Ichiran uses a PostgreSQL database as a source for its vocabulary and other things. On Linux install postgresql using your preferred package manager. On Windows use the official installer. You should remember the password for the postgres user, or create a new user if you know how to do it.

Download the latest release of Ichiran database. On the release page there are commands needed to restore the dump. On Windows they don't really work, instead try to create database and restore the dump using pgAdmin (which is usually installed together with Postgres). Right-click on PostgreSQL/Databases/postgres and select "Query tool...". Paste the following into Query editor and hit the Execute button.

CREATE DATABASE [database_name] WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'UTF8' LC_COLLATE = 'Japanese_Japan.932' LC_CTYPE = 'Japanese_Japan.932' TABLESPACE = pg_default CONNECTION LIMIT = -1;

Then refresh the Databases folder and you should see your new database. Right-click on it then select "Restore", then choose the file that you downloaded (it wants ".backup" extension by default so choose "Format: All files" if you can't find the file).

You might get a bunch of errors when restoring the dump saying that "user ichiran doesn't exist". Just ignore them.

SBCL

Ichiran uses SBCL to run its Common Lisp code. You can download Windows binaries for SBCL 2.0.0 from the official site, and on Linux you can use the package manager, or also use binaries from the official site although they might be incompatible with your operating system.

However you really want the latest version 2.1.0, especially on Windows for uh... reasons. There's a workaround for Windows 10 though, so if you don't mind turning on that option, you can stick with SBCL 2.0.0 really.

After installing some version of SBCL (SBCL requires SBCL to compile itself), download the source code of the latest version and let's get to business.

On Linux it should be easy, just run

sh make.sh --fancy sudo sh install.sh

in the source directory.

On Windows it's somewhat harder. Install MSYS2, then run "MSYS2 MinGW 64-bit".

pacman -S mingw-w64-x86_64-toolchain make # for paths in MSYS2 replace drive prefix C:/ by /c/ and so on cd [path_to_sbcl_source] export PATH="$PATH:[directory_where_sbcl.exe_is_currently]" # check that you can run sbcl from command line now # type (sb-ext:quit) to quit sbcl sh make.sh --fancy unset SBCL_HOME INSTALL_ROOT=/c/sbcl sh install.sh

Then edit Windows environment variables so that PATH contains c:\sbcl\bin and SBCL_HOME is c:\sbcl\lib\sbcl (replace c:\sbcl here and in INSTALL_ROOT with another directory if applicable). Check that you can run a normal Windows shell (cmd) and run sbcl from it.

Quicklisp

Quicklisp is a library manager for Common Lisp. You'll need it to install the dependencies of Ichiran. Download quicklisp.lisp from the official site and run the following command:

sbcl --load /path/to/quicklisp.lisp

In SBCL shell execute the following commands:

(quicklisp-quickstart:install) (ql:add-to-init-file) (sb-ext:quit)

This will ensure quicklisp is loaded every time SBCL starts.

Ichiran

Find the directory ~/quicklisp/local-projects (%USERPROFILE%\quicklisp\local-projects on Windows) and git clone Ichiran source code into it. It is possible to place it into an arbitrary directory, but that requires configuring ASDF, while ~/quicklisp/local-projects/ should work out of the box, as should ~/common-lisp/ but I'm not sure about Windows equivalent for this one.

Ichiran wouldn't load without settings.lisp file which you might notice is absent from the repository. Instead, there's a settings.lisp.template file. Copy settings.lisp.template to settings.lisp and edit the following values in settings.lisp:

*connection* this is the main database connection. It is a list of at least 4 elements: database name, database user (usually "postgres"), database password and database host ("localhost"). It can be followed by options like :port 5434 if the database is running on a non-standard port.

*connections* is an optional parameter, if you want to switch between several databases. You can probably ignore it.

*jmdict-data* this should be a path to these files from JMdict project. They contain descriptions of parts of speech etc.

ignore all the other parameters, they're only needed for creating the database from scratch

Run sbcl. You should now be able to load Ichiran with

(ql:quickload :ichiran)

On the first run, run the following command. It should also be run after downloading a new database dump and updating Ichiran code, as it fixes various issues with the original JMdict data.

(ichiran/mnt:add-errata)

Run the test suite with

(ichiran/test:run-all-tests)

If not all tests pass, you did something wrong! If none of the tests pass, check that you configured the database connection correctly. If all tests pass, you have a working installation of Ichiran. Congratulations!

Some commands that can be used in Ichiran:

(ichiran:romanize "一覧は最高だぞ" :with-info t) this is basically a text-only equivalent of ichi.moe, everyone's favorite webapp based on Ichiran.

(ichiran/dict:simple-segment "一覧は最高だぞ") returns a list of WORD-INFO objects which contain a lot of interesting data which is available through "accessor functions". For example (mapcar 'ichiran/dict:word-info-text (ichiran/dict:simple-segment "一覧は最高だぞ") will return a list of separate words in a sentence.

(ichiran/dict:dict-segment "一覧は最高だぞ" :limit 5) like simple-segment but returns top 5 segmentations.

(ichiran/dict:word-info-from-text "一覧") gets a WORD-INFO object for a specific word.

ichiran/dict:word-info-str converts a WORD-INFO object to a human-readable string.

ichiran/dict:word-info-gloss-json converts a WORD-INFO object into a "json" "object" containing dictionary information about a word, which is not really JSON but an equivalent Lisp representation of it. But, it can be converted into a real JSON string with jsown:to-json function. Putting it all together, the following code will convert the word 一覧 into a JSON string:

(jsown:to-json (ichiran/dict:word-info-json (ichiran/dict:word-info-from-text "一覧")))

Now, if you're not familiar with Common Lisp all this stuff might seem confusing. Which is where ichiran-cli comes in, a brand new Command Line Interface to Ichiran.

ichiran-cli

ichiran-cli is just a simple command-line application that can be called by scripts just like mecab and its ilk. The main difference is that it must be built by the user, who has already did the previous steps of the Ichiran installation process. It needs to access the postgres database and the connection settings from settings.lisp are currently "baked in" during the build. It also contains a cache of some database references, so modifying the database (i.e. updating to a newer database dump) without also rebuilding ichiran-cli is highly inadvisable.

The build process is very easy. Just run sbcl and execute the following commands:

(ql:quickload :ichiran/cli) (ichiran/cli:build)

sbcl should exit at this point, and you'll have a new ichiran-cli (ichiran-cli.exe on Windows) executable in ichiran source directory. If sbcl didn't exit, try deleting the old ichiran-cli and do it again, it seems that on Linux sbcl sometimes can't overwrite this file for some reason.

Use -h option to show how to use this tool. There will be more options in the future but at the time of this post, it prints out the following:

>ichiran-cli -h Command line interface for Ichiran Usage: ichiran-cli [-h|--help] [-e|--eval] [-i|--with-info] [-f|--full] [input] Available options: -h, --help print this help text -e, --eval evaluate arbitrary expression and print the result -i, --with-info print dictionary info -f, --full full split info (as JSON) By default calls ichiran:romanize, other options change this behavior

Here's the example usage of these switches

ichiran-cli "一覧は最高だぞ" just prints out the romanization

ichiran-cli -i "一覧は最高だぞ" - equivalent of ichiran:romanize :with-info t above

ichiran-cli -f "一覧は最高だぞ" - outputs the full result of segmentation as JSON. This is the one you'll probably want to use in scripts etc.

ichiran-cli -e "(+ 1 2 3)" - execute arbitrary Common Lisp code... yup that's right. Since this is a new feature, I don't know yet which commands people really want, so this option can be used to execute any command such as those listed in the previous section.

By the way, as I mentioned before, on Windows SBCL prior to 2.1.0 doesn't parse non-ascii command line arguments correctly. Which is why I had to include a section about building a newer version of SBCL. However if you use Windows 10, there's a workaround that avoids having to build SBCL 2.1.0. Open "Language Settings", find a link to "Administrative language settings", click on "Change system locale...", and turn on "Beta: Use Unicode UTF-8 for worldwide language support". Then reboot your computer. Voila, everything will work now. At least in regards to SBCL. I can't guarantee that other command line apps which use locales will work after that.

That's it for now, hope you enjoy playing around with Ichiran in this new year. よろしくおねがいします！

#common lisp #japanese #language

6 notes · View notes

zblisp · 7 years

Text

UIOP 3.3.0 problems

Ok, here's something that is causing problems when I build this month's Quicklisp dist.

UIOP 3.3.0 was recently released, and it's causing some stuff to apparently compile over and over again. Here's a real simple thing to try:

$ cd ~/quicklisp/local-projects/ $ curl -O https://common-lisp.net/project/asdf/archives/uiop.tar.gz $ tar xzvf uiop.tar.gz

Then:

CL-USER> (ql:quickload "circular-streams")

On my setup, I see cffi and babel stuff compiled twice:

To load "circular-streams": Load 1 ASDF system: circular-streams ; Loading "circular-streams" [package uiop/package]............................ .................................................. .................................................. [package alexandria.0.dev]........................ .................................................. [package babel-encodings]......................... [package babel]................................... .................................................. [package cffi-sys]................................ [package cffi].................................... .................................................. [package cffi-features]........................... [package alexandria.0.dev]........................ .................................................. [package impl-specific-gray]...................... [package trivial-gray-streams].................... [package uiop/package]............................ .................................................. .................................................. [package babel-encodings]......................... [package babel]................................... .................................................. [package cffi-sys]................................ [package cffi].................................... .................................................. [package cffi-features]........................... [package static-vectors].......................... [package fast-io]................................. [package circular-streams]..

If I remove uiop-3.3.0/ from local-projects, the output looks like this:

To load "circular-streams": Load 1 ASDF system: circular-streams ; Loading "circular-streams" [package alexandria.0.dev]........................ [package impl-specific-gray]...................... [package trivial-gray-streams].................... [package uiop/package]............................ .................................................. .................................................. [package babel-encodings]......................... [package babel]................................... .................................................. [package cffi-sys]................................ [package cffi].................................... .................................................. [package cffi-features]........................... [package static-vectors].......................... [package fast-io]................................. [package circular-streams]..

Any ideas?

update Commit 4ed76c32050753c8a4450c342a1592881e11d63d seems to reference this behavior, with the "fast-io" system given as an example. And indeed, when I try this with fast-io, I see similar recompilation.

#lisp #uiop #quicklisp

0 notes

danielkvasnicka · 4 years

Text

Using Advent of Code 2019 to rediscover Common Lisp

UPDATE: Added generic-cl as suggested on Reddit.

Before last year’s Advent of Code started I declared on Twitter that I was going to do it in Common Lisp. And so I "did" (with a couple of 2016 challenges in CL as well). Yes, quite a bit of the challenges are missing. I hope to get back to them some time 😇

This writeup will be a summary of what I liked, what I did not like and finally a set of libraries for various purposes I used and found interesting. There are a couple of lists like that on the net (especially https://awesome-cl.com/, which I have actually submitted PRs to during my work on this article) but I wanted one that would include a couple of comments based on my personal experiences -- basically I’ll be making a purely subjective list of things I don’t want to forget about and it so happens that it will be publicly available on my blog 🤓

Just so you know, the views here will be expressed from the PoV of a long time Clojure and Racket fan.

Pros & Cons

Let’s start with what I liked:

Speed -- the best CL implementations are fast, while still allowing you to maintain a very readable, high level idiomatic code. With SBCL, the most popular implementation, you are basically getting one of the fastest lispy experiences possible. We obviously need to address the elephant in the room here and that’s Cloure. Clojure, thanks to JVM, can be faster than Common Lisp. However the speed often times comes at the cost of writing a relatively ugly “C wrapped in parens” style of code and/or you need enough data to get good amortization while JITting.

Debugging and optimization -- this one kind of relates to the first point as well. Common Lisp contains very powerful debugging, introspection and optimization tools that are part of the base lang spec. It does not matter what kind of implementation you use or whether you are using the IDE everyone thinks is the coolest right now... Hell, you can even disassmble your program to see the actual ASM code that your CPU will juggle.

Stability of the language -- there are people who can express this better so I’ll just link to the appropriate section of the magnificent article Steve Losh wrote in 2018:

My advice is this: as you learn Common Lisp and look for libraries, try to suppress the voice in the back of your head that says "This project was last updated six years ago? That's probably abandoned and broken." The stability of Common Lisp means that sometimes libraries can just be done, not abandoned, so don't dismiss them out of hand.

Specification & standard (kinda applies to Scheme as well) -- This is a tricky issue that has started many flamewars in the past, not just in the Lisp world (see the Spring vs Java EE battle). Having to adhere to a spec brings limitations but there are 2 counterarguments I can think of in the case of CL:

The power of macros means you can overcome almost all cases of stalled innovation without performance penalty. Look at the loop macro and how it was essentially completely covered with zero-cost abstractions.

The myriads of Clojure-like languages all suffer from the same problem: You cannot use libraries or any of the cool tools in the ecosystem. Yet, they themselves do not have anywhere near the traction necessary to be widely used production languages. CL shows that you can have a standard and still have enough room for differentiation and innovation.

Lisp-2 -- yep, you read that right. I would have never expected to say this (and I believe I’ve actually shunned Lisp-2 on this very blog some time ago?) but I actually like that functions in Common Lisp live in a separate namespace, for a very simple reason: code is read way more ofthen than it is written. When I look at code and see that seemingly annoying funcall I know it’s not just a top level defunned function and that I need to trace its origins somewhere else. Similar principle applies for the #' prefix (also makes life easier for syntax highlighters).

Next, the annoyances:

Widespread mutability and imperativeness -- Mutability is good if used in specific cases where it makes sense and if quarantined properly. However in CL mutability is king. It's not as much a problem of the language or implementations (you don't have to write mutable code) as it is a problem of the historical baggage -- it was never customary in the CL land to look bad at code that creates a mutable collection, then puts stuff in it in an imperative cycle and returns it from a function out to the dark and cold world... Purely functional collections exist but CL is not built around them. This is where Clojure shines.

CL Sequences apparatus not being user-extensible -- Common Lisp has a concept of sequences which puts a roof over lists and vectors and allows the user to use one function for both. However this facility, for some reason, is not easily extensible. This leads to many libraries implementing various new data structures and using completely custom API to do simple things like getting the size of a collection because (defmethod length ((seq my-epic-data-structure)) ...) signals COMMON-LISP:LENGTH already names an ordinary function or a macro. Fortunately there are libraries that are trying to solve this and to be honest it is not that much of a PITA anyway, because using a different function name for a special data structure has positive readability and performance implications. This applies to Racket too, to some degree. This lack of extensibility might have technical reasons I don't know of and if that is the case I'd be curious to learn and understand them.

LOOP -- I hate loop. Fortunately, this is an issue only if you have to deal with legacy code. The iteration story in CL is so good that you'll basically never have to write a single line of loop if you don't want to. My favourite comment on the topic is this one.

Destructuring not being 1st class citizen (enough) -- CL has macros with annoyingly long names to do destructuring and does not have the concept built-in deep enough for it to be ubiquitous in e.g. function definitions like you can see in JS or Clojure. Fortunately -- you guessed it -- libraries solve this issue satisfactorilly.

Interesting tools and libraries

What follows is a set of libraries that I tried and found useful -- libraries that helped me make a lot of annoyances (almost) irrelevant. I'll include one or two libraries that I have not used yet but would like to as they seem cool to me:

Platform tools

Quicklisp -- primary source of packages for CL. There is also Ultralisp, which is a faster-moving package distro.

Roswell -- this became my go-to tool for managing implementations and also packages. It can install packages from Quicklisp as well as GitHub repos in a manner similar to how go get works for example.

Qlot -- project-local dependencies manager that works well with Roswell. Think npm for Common Lisp. Can get dependencies from other Git repos, not just GitHub.

General purpose

Alexandria -- this is the utilities library in the CL world. It's so widespread that it's almost a standard thing.

Serapeum -- the Serapeum of Alexandria was an ancient Greek temple; referred to as the daughter of the Library of Alexandria. You get the idea ;) As you can see, the library is massive and I include it in most programs I write.

rutils (API) -- another impressive assortment of functions and macros. I would especially like to point out the with macro in the rutils.bind package, which is a kind of an extensible über-let.

metabang-bind -- another let on steroids. Unlike with it can bind arrays/vectors out of the box but is a little bit more chatty (and probably not as actively maintained).

cl-losh -- this is a library that its author explicitly does not want you to use. Sorry, Steve :) Your library is way too good for me to abide by your orders. What I found especially useful is the library of extensions for iterate, the de-facto replacement for LOOP we'll discuss later.

CL21 (and its very recent revival named 20XX) -- very interesting attempt at refreshing some of the more antiquated aspects of CL. It can be used as a library only to cherry-pick good stuff but it's probably less painfull to go all in and write programs "in" CL21 if it makes sense for a particular package.

cl-str -- Modern, simple and consistent Common Lisp string manipulation library.

Iteration & sequence procesing

iterate -- IMHO overall the best of iteration libraries for Common Lisp. A significantly lispier alternative to LOOP. Allows for very idiomatic, concise and understandable iteration code, is extensible and widely accepted and extended.

series -- the original transducers library (yes, those transducers). When used in tandem with taps (see my fork with a bugfix as well) it allows the programmer to write very succinct "top level" code (e.g. the main driver of a program that reads from a stream and delegates work to other parts of the code), or complex pipelines in general.

for -- another extensible LOOP replacement, this time a bit closer to Racket's ecosystem of for comprehensions.

gmap -- this is probably one of the most underrated/under-popularized pieces of gear I've come across in the Common Lisp land (tracing its origins back to 1980!). Combines mapping, filtering and reducing into a neat transducer-ish extensible construct and has a built-in support for FSet, a functional collections library we'll talk about later. The same Lisp project also contains new-let ...guess what is it supposed to be 😉 Yeah, let is the new loop.

generic-cl -- provides a generic function wrapper over various functions in the Common Lisp standard, such as equality predicates and sequence operations. An answer to on of my critical points above (defines generics that overlay CL builtins).

You can also find many small iteration helper tools scattered across the general purpose libraries we discussed in the previous section. Mapping from X to Y, reducing all kinds of things etc...

Math

cl-geometry -- 2D computational geometry library, which made work on Day 3 of AoC 2019 very enjoyable for me.

Data structures

FSet -- functional library of sets, maps and bags that has a natural and clean API and as we already mentioned, it comes with the added bonus of being written by the same guy who wrote gmap.

cl-containers -- a massive collection of (mostly tree-based) data structures and algorithms, useful when you need stuff like sorted map etc.

graph-utils -- graph data structure and algorithms

sycamore -- fast purely functional data structures

random-access-lists -- useful library for when you need a listy data structure and you don't want to pay O(n) when accessing elements in it.

array-operations -- library for concisely expressing operations on (multidimensional) arrays. Being used to the Racket array library it took me a while to get used to some of the specifics but it indeed is very powerful and fast.

Static typing & contracts

Apart from the built in tools for specifying types statically you can also use these to strenghten your safety net:

defstar -- Macros for easy inclusion of type declarations for arguments in lambda lists. Can replace defun, defmethod, defgeneric and others.

cl-algebraic-data-type -- a library for defining algebraic data types in a similar spirit to Haskell or Standard ML, as well as for operating on them

quid-pro-quo -- A contract programming library for Common Lisp in the style of Eiffel’s Design by Contract

Testing

These are the two testing libraries I tried out. I prefer parachute, the API feels more natural to me. There are others and it's getting worse 😉

rove

parachute

OOP

In addition to the following libraries you should check CLOS-related sections of almost all of the general purpose util libraries we discussed above. They contain stuff to help make CLOS a bit less verbose.

defclass-std -- a macro that atempts to give a very DRY and succint interface to the common DEFCLASS form. The goal is to offer most of the capabilities of a normal DEFCLASS, only in a more compact way.

sheeple -- prototype-based OOP in Common Lisp? 😱 Because we can!

Verdict

So is CL my new favorite language that I'll be using for everything from now on? No, not really. But in my book it's moving from a language that I wasn't really taking very seriously to a language that has a fixed place on my toolbelt. One scenario where I can see it shine is situations where I don't want (need?) to use Clojure but Racket / Scheme does not have the right libraries.

#commonlisp #lisp #adventofcode #programming #clojure #functional programming #adventofcode2019

0 notes

hackernewsrobot · 7 years

Text

OpenPGP and SHA verification

http://blog.quicklisp.org/2017/09/something-to-try-out-quicklisp-with.html Comments

0 notes

topicprinter · 4 years

Link

I have gone through initial chapters of "Practical Common Lisp"[1] and "Loving Common Lisp" [2], and have a bit of intuition on lisp, and the power of macros. Haven't done any projects yet, but was also researching on real issues faced by adopting lisp, and ran into articles about abandoning lisp [3], adopting lisp [4],[5]. Could not find anything more recent; but what they mention in these articles - even the ones that are adopting lisp talk about issues like:

* poor ecosystem of libraries - few gems, most other half-baked

* poor community coordination

* Dependency management limitations with quicklisp

And some specific red flags like:

* poor support for json[6] * poor support for async

* have to restart the server every 20 days because of some memory leak [3]

* hack to tune GC [5]

If you are using lisp in production for non-trivial cases, do these issues still exist? is there a way you can quantify effort is resolving them, and if yes, what is it? and, finally, if you had to re-do your project, would you chose lisp or something else?

[1]: http://www.gigamonkeys.com/book/

[2]: https://leanpub.com/lovinglisp/read#quicklisp

[3]: https://lisp-journey.gitlab.io/blog/why-turtl-switched-from-...

[4]: https://lisp-journey.gitlab.io/blog/why-deftask-chose-common...

[5]: https://www.grammarly.com/blog/engineering/running-lisp-in-p...

[6]: https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s4...

Comments URL: https://news.ycombinator.com/item?id=23231701

Points: 6

# Comments: 5

#hacker news

0 notes

commonlisp-it · 1 year

Link

#quicklisp

0 notes

zblisp · 4 years

Text

New SBCL 2.0.9 behavior breaks some stuff

The latest SBCL handles slot :initform and :type options in a new way. It's mentioned in the release notes.

minor incompatible change: the compiler signals a warning at compile-time when an initform of T, NIL or 0 does not match a STANDARD-CLASS slot's declared type._

Sounds pretty benign, but it breaks dozens of projects in Quicklisp. (To be fair, most of the failures are caused by a small number of core systems on which many other systems depend.)

Here's an example of the new behavior:

(defclass foo () ((name :type string :initform nil)))

With the above defclass form, SBCL 2.0.9 will signal a warning at compile time:

; processing (DEFCLASS FOO ...) ; file: foo.lisp ; in: DEFCLASS FOO ; (NAME :TYPE STRING :INITFORM NIL) ; ==> ; (SB-KERNEL:THE* (STRING :SOURCE-FORM NIL :USE-ANNOTATIONS T) NIL) ; ; caught WARNING: ; Constant NIL conflicts with its asserted type STRING. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition

This compile-time warning means "failure" as far as loading with ASDF is concerned.

If you have both :type and :initform in your slot definitions, and you want to be compatible with the latest SBCL, make sure the initform type matches the slot type. If you want to use NIL as the initform, one easy option is to set the type to (or null <actual type>).

0 notes

zblisp · 6 years

Text

Vectometry is now part of Vecto

I wrote vecto to be able to draw stuff to PNGs. It’s based on the PostScript/PDF drawing model, all the way down to the level of function arguments. To move to a point, you use (move-to x y). Curves are done with (curve-to x1 y1 x2 y2 x3 y3). Color calls are done with (set-rgb-fill r g b), etc. Each function argument that has multiple components is passed with the components separated.

This is all right, I guess, but it’s also pretty inconvenient if you have an object that aggregates X and Y components to break them out all the time. Passing around six things instead of three or three things instead of one is annoying.

So, a long time ago, I made a more objecty frontend for Vecto and called it Vectometry. It has a load of convenience functions for working with points and colors as objects rather than separated components. It predefines some useful points (like *origin*) and colors (like *white* and *black*). It also adds a set of functions for working with rectangles, which are called “boxes” in the interface.

So, for example, the old vecto code might look like this:

(with-canvas (:height 100 :width 100) (move-to 0 0) (line-to 50 50) (line-to 100 0) (stroke) (save-png "foo.png"))

The new code looks something like this:

(let ((canvas (box 0 0 100 100))) (with-box-canvas canvas (move-to *origin*) (line-to (centerpoint canvas)) (line-to (bottom-right canvas)) (stroke) (save-png "bar.png")))

Boxes have maxpoint, minpoint, centerpoint, bottom-left, top-left, top-right, bottom-right, height, and width functions. They all return about what you’d expect.

But there’s also a combine function that takes two boxes, or a point and a box, or two points, and returns a box big enough to cover the two objects.

And expand takes a box and an amount, and returns a new box that has its corners moved out by the specified amount, in all directions. And the nice thing about with-box-canvas is that if your box doesn’t align with the origin, the drawing system still does - that is, the bottom left of your canvas box can be at positive or negative coordinates, but drawing at the origin will still draw at 0, 0.

displace takes a box and a point, and adds the point components to the minpoint of the box to produce a new box at a new location.

For points, there’s new add, sub, mul, and div functions that do about what you’d expect. And there’s also a function angle to get the angle between two points, and a function apoint that produces a point at a specified angle and distance from the origin.

Color objects are easier to make and pass around. rgb-color does what you’d expect, but there’s also an hsv-color that provides a much nicer way to get related colors, and even an html-color function so you can easily use “#rgb” or “#rrggbb” strings to set fill or stroke colors.

Everything else that doesn’t deal with component arguments is just passed through verbatim to Vecto, so things like stroke or fill-path don’t change.

This object stuff creates new objects all the time instead of mutating old ones. Maybe it’s slower and puts more pressure on the GC. But for the stuff I do I haven’t noticed and it hasn’t mattered.

I’ve been sitting on this vectometry code, using it for all my drawing needs for years but never publicizing it, because it wasn’t documented yet. But I’d rather put it into vecto and make it easily accessible and document it Someday rather than leave it buried.

If you like drawing stuff and 2D APIs and PNGs and stuff, try the latest vecto from Quicklisp and give it a whirl. If you have problems let me know. If you want me to post some example code and output images let me know. Enjoy!

edit Here’s some code I posted to twitter and 100-pointed and 5-pointed stars:

(defun star-demo (box points dip-factor) (let* ((radius (/ (max (height box) (width box)) 2)) (step (/ pi points)) (angle (/ pi 2)) (center (centerpoint box))) (with-box-canvas (expand box 5) (set-fill-color *white*) (clear-canvas) (set-stroke-color (rgba-color 0 0 0 0.5)) (centered-circle-path center radius) (set-line-width 10) (stroke) (translate center) (move-to (apoint angle radius)) (dotimes (i points) (incf angle step) (line-to (apoint angle (* radius dip-factor))) (incf angle step) (line-to (apoint angle radius))) (set-fill-color *black*) (fill-path) (save-png (format nil "star~D.png" points)))))

1 note · View note

zblisp · 5 years

Text

SBCL20 in Vienna

Last week I attended the SBCL 20th anniversary workshop, held in Vienna, Austria. Here are some rough impressions - I wish I had detailed enough notes to recreate the experience for those who did not attend, but alas, this is what you get! It's incomplete and I'm sorry if I've left out someone unfairly - you have to go yourself next time so you don't miss a thing.

Structure of the gathering

I didn't go to SBCL10, so I didn't know what to expect. There were few speakers announced, and I worried (to myself) that this was a sign of insufficient participation, but I couldn't have been more wrong.

Philipp Marek played host at his employer, BRZ. We had a large room laid out with several tables, ample power, notepads, markers, and treats, fresh food and drink, and a stage area with chairs set out for an audience.

The conference lead off with a BRZ representative who explained BRZ's purpose with an English-language video and encouraged qualified people to consider joining the company.

Christophe Rhodes acted as master of ceremonies. He put the conference in historical context and explained the format. While there were only a small number of planned talks, the remainder of the two-day conference was intended for brainstorming, reminiscing, hacking, and impromptu talks by anyone with an interesting idea, demo, or controversial proclamation. He challenged all of us to pick something to work on and present it by the end of the conference.

With everyone in the same room, it was nice to see people help each other in unexpected ways. People describing a problem would get interrupted by people who could help. And not "Have you tried installing My Favorite Linux?"-type unhelpful speculation - it was always valuable in one form or another. The breadth and depth of SBCL and Common Lisp knowledge meant that, for example, someone could explain why a certain decision was made in CMUCL 30 years ago, why SBCL went in a different direction 20 years ago, and how things could be improved today.

I chose to revisit a problem I first wrote about five years ago. It boils down to this: can a third party (Quicklisp, in this case) control the dynamic environment of each load-system operation when recursively loading a system? The SBCL connection is a little loose, but it relates to how SBCL's compiile-time analysis warnings should be shown prominently for local development, even when loading systems with ql:quickload.

A lot of people pitched in with ideas and suggestions. Mark Evanson in particular acted as a sounding board in a way that helped me get to the essence of the problem. Unfortunately, I wasn't able to find a solution before the end of the conference.

Robert Smith and Lisp at Rigetti

Robert gave an introduction to the math behind quantum computing, and then described the success Rigetti has had with SBCL and Common Lisp for building its quantum computing simulator and compiler. CL allows exploring and adopting new ideas at a very quick pace. I liked that it wasn't high-level "Lisp is great!" preaching to the choir, but gave some specific practical examples of how CL features made life easier.

Charlie Zhang and RISC-V

Charlie is a newcomer to SBCL development as of 2019. In the span of a few months added a new compiler backend for fun. He talked about the challenges of understanding and extending SBCL, and some of his future plans.

He generated backend the assembly with the Lisp assembler - it gave full advantages of Lisp for code manipulation at the assembly level. First and only backend to do so!

Funniest fact I overheard at dinner after the workshop: "I don't even use Common Lisp for anything, I just hack on the compiler!"

Doug Katzman and SBCL as a Unix program

Doug Katzman talked about his recent work at Google aimed at making SBCL play well with Unix tools. Specifically debugging and profiling tools that expect a binary to act in a certain way and to provide debugging and stack info in a specific format. This makes it easier to provide insight into how SBCL is spending its time when there are many, many instances running across many, many computers. And with so many instances running, the benefits of improving performance add up in significant ways.

This use case is far removed from my typical live, ongoing, interactive development session with SBCL. It was interesting to learn about the constraints and requirements of Lisp servers in that kind of environment.

Other talks

There were a dozen or more short presentations and talks about various topics. Luís talked about porting an application to SBCL from another Lisp and some of the good and bad parts along the way. Charlie talked about contification optimization for SBCL. There were quick talks about tuning the GC, SIMD extensions, missing features of SBCL, Coalton, CL support in SWIG, and several more.

Bits and pieces

There are more commits to SBCL now than ever before, despite there being fewer people contributing overall

It would nice to have support for good CL interaction in popular new editors, but some of the existing components (e.g. LSP) are insufficient to support SLIME-like levels of interaction

Siscog has more than 60 people who work on Lisp programs - biggest collection in the world?

Closing wishlist items

Christophe solicited wishlist items to close out the conference. Here are a few that I jotted down:

Debug-oriented interpeter, e.g. with macroexpand-always behavior (the current interpreters do not especially improve the debug experience)

Profile-based compilation feedback (sort of like tracing jit but not exactly?)

Class sealing

Full configurable numeric tower

Arbitrary-precision floats

Concurrent GC - GC pauses cited by more than one person as a pain point

Overall

I had a great time at SBCL20 and it renewed my energy for working on Common Lisp projects. It's great to see in person the people you are helping when you create or contribute to a community project.

Thanks to everyone who attended and spoke, to Philipp Marek for hosting, and to Christophe Rhodes for acting as MC and much more.

It's too long to wait for SBCL30. How about an SBCL25, or even sooner?

See you there!

0 notes

zblisp · 7 years

Text

The slime-selector

I use and love the slime-selector. It's a very quick way to jump around between various SLIME buffers.

In my .emacs, C-c s is bound to slime-selector with

(global-set-key "\C-cs" 'slime-selector)

Then, in any buffer, I can use \C-c s to pop up a minibuffer selector that takes a single additional key. Here's the list of keys and what they do:

4: Select in other window ?: Selector help buffer. c: SLIME connections buffer. d: *sldb* buffer for the current connection. e: most recently visited emacs-lisp-mode buffer. i: *inferior-lisp* buffer. l: most recently visited lisp-mode buffer. n: Cycle to the next Lisp connection. p: Cycle to the previous Lisp connection. q: Abort. r: SLIME Read-Eval-Print-Loop. s: *slime-scratch* buffer. t: SLIME threads buffer. v: *slime-events* buffer.

I use r the most to instantly get into the repl. But I also use l to jump to the last Lisp file I was working on, or d to find a debugger buffer I might have buried.

It's also quite helpful with c, to bring up a list of active Lisp connections. For Quicklisp work, I sometimes want to switch between four or five active slime connections, and \C-c s c makes it quick and easy to choose.

Enjoy!

2 notes · View notes

zblisp · 7 years

Text

UIOP, sly, and qlt

uiop

The problem I had with UIOP is due to using stock SBCL ASDF (3.1.5) with UIOP 3.3.0. UIOP changed a public function's behavior in a way that affected older ASDFs (and seemingly only older ASDFs). This is considered a bug and will be fixed in a future UIOP release.

sly

September of Sly has turned into Season of Sly. I haven't been hacking as much with Sly as I wanted in September, so I'm going to keep going with it for October and beyond, and write up a summary Very Soon. My current hangup is C-c M-q, which is slime-reindent-defun in slime, but does nothing in Sly, and there's no sly-reindent-defun to try to bind instead. I try to use C-c M-q a thousand times a day.

qlt

You might know that Quicklisp dists are constructed after building every project that Quicklisp tracks, and projects that don't build (due to compile-time problems) aren't included. This is better than nothing, but it does nothing to catch runtime problems.

Last week Quicklisp got hit with a runtime problem that broke a lot of stuff, so it prompted me to create qlt.

qlt is for collecting small files of Common Lisp code to run before a Quicklisp dist is created. If any of the files signal an error, Quicklisp generates a report with the console output and the dist is no-go until the problem is tracked down.

The project is sparse right now, but it does include a test file that catches the runtime problem from last week. I hope to include many more things to test as time goes on. If there is something you want to check, patches welcome!

0 notes

zblisp · 7 years

Text

September of Sly

I like the idea of sly: like slime, but cooler. Less conservative with changes, less concerned about backwards-compatibility, more features, cleaner implementation, etc. But I don't know that much about it in detail, and I've never tried it - until now.

I'm going to use sly exclusively for the month of September. As I bump into differences from slime, I'm taking notes and will share them here. I hope to give people an idea about what it's like to switch and help them decide if it's worthwhile for them, and figure out if I'll be switching back on October 1.

So here are a few quick notes from getting started:

Pretty easy to install, but not as easy as quicklisp-slime-helper - I can make a sly-helper in the future

Would not start initially because I had a reference to the swank package in my ~/.swank.lisp file. Referencing swank in a swank init file seems reasonable so it was a little annoying to have to add some #+swank/#+sly conditionalization.

I use slime-selector a lot, and it's moved into a keymap in sly - I like that it now uses a standard Emacs UI instead of a custom UI

...but it's missing the "l" binding, which I use a hundred times a day, so I wrote a little bit of elisp to add it back

docstring of sly-selector-map helps explain what to do

Window management in sly-selector confuses me - expect REPL to replace current window, but it seems to go somewhere else every time

comma commands are different! I use ,chTAB and ,cdRET a hundred times a day, and now they are ,set package (which has nice completion) and ,set directory

Much more verbose repl output for integers at least:

(+ 1 1) => 2 (2 bits, #x2, #o2, #b10)

M-RET in REPL history does what I expect

Not 100% sure how to get started with stickers, but C-c C-s ? has good starting points

Should read manual...

Stay tuned for more!

0 notes

zblisp · 9 years

Text

Quicklisp: beyond beta

I gave a talk at ELS 2015 in London in April about the past, present, and future of Quicklisp. The “future” part detailed several things I’d like to accomplish before removing the beta label from Quicklisp.

The slides and script of the talk are available on github. But since there are over a hundred slides and about twenty pages of script, I thought I’d summarize things in this post.

First, what’s Quicklisp for, anyway? The slogan I put in the talk is: Make it easy to confidently build on the work of others. (Also, work on as many Common Lisps on as many platforms as possible.)

Quicklisp achieves part of that already. It runs well on almost all Common Lisp implementations on all platforms. It’s easy to install, use, and update. Things are tested together so everything usually works. But if something breaks on update, you can revert to a previous working version. And with those features you can build on hundreds of libraries already.

If it can do all that, why not drop the “beta” already? There are still a number of things that I want Quicklisp to do before I’m ready to say “Here, this is what I had in mind from the start.”

First, I’d like to improve the confidence in the code you download and run. By adding HTTPS, signature checking, and checksum validation, you can be sure that there is nobody intercepting and modifying the software provided by Quicklisp. The signature and archive integrity checks must be made complete and automatic to have the best results.

Second, I’d like to add comprehensive user and developer documentation. For users, that means being able to learn each command, feature, and behavior of Quicklisp, to be able to use it to its fullest. For developers, that means being able to build your own solutions on a Quicklisp foundation without starting from scratch.

Third, I’d like to make it easy to find the project that does what you need, evaluate its quality and popularity, and find out if its license is compatible with your goals. If you want to make changes to a project, I want it to be easy to get the original source of a project and send fixes or improvements to the upstream maintainer.

Fourth, I’d like to make it easy to hook into the archive-fetching component of Quicklisp in a way that makes it easy to support additional integrity checks, support local development policies, and add local mirrors or caches for Quicklisp software.

These changes and improvements will take time. When they’re done, I’ll be happy to drop “beta” from Quicklisp.

#lisp #quicklisp

2 notes · View notes