3 ms·

From my experience, Docker helps quite a bit with CL stuff in many cases. When you use some shared libs via CFFI, things can get fragile quick, start depending

From my experience, Docker helps quite a bit with CL stuff in many cases. When you use some shared libs via CFFI, things can get fragile quick, start depending on a particular shared library version on the host system etc. So your app, for instance, works fine on Debian jessie, then you have to upgrade your host system to stretch and oops, it broke here and there. You update your quicklisp dist to fix shared lib incompatibility problem and oops again, you need a week to fix stuff that broke (this reflects some problems with CL library management, too), but you need to have your app up and running on the new system yesterday. If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example.

rini17 7y ago
Right, CFFI is another can of worms. It is sometimes questionable whether the time saved by reusing C code isn't lost by debugging and integration issues. For example I ended up avoiding cl-async (a wrapper over a C library) due to these. In my mind reimplementing in CL is better bet than pulling Docker.
- amirouche 7y ago
  > I ended up avoiding cl-async What do you use instead?
  - rini17 7y ago
    I reimplemented the parts I needed using threads+usockets. There's no fundamental reason it can't be built directly on OS async interfaces, even without threading, instead of C library.
- ivan4th 7y ago
  Well, I did write quite a bit of CL code for money, but it's hard to get paid for reimplementing every library that one may need in CL ;(
  - rini17 7y ago
    I have not meant it in such extreme way at all :( Just this: if something interferes badly with a basic CL feature such as SLIME (cl-async does), toss it.
    - ivan4th 7y ago
      cl-async works pretty well with SLIME if you use its SLIME REPL integration feature that I contributed several years ago. https://github.com/orthecreedence/cl-async/blob/master/src/repl.lisp https://github.com/orthecreedence/cl-async/blob/master/src/r... It basically starts an event loop in a separate thread and then wraps all of the SLIME's evals so they're executed from within that event loop.
amirouche 7y ago
> If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example. That is perfect match for guix channels too. What I do is maintain a repository of package definitions (that possibly inherit from guix master package definitions) and only change a few hashes here and there when I need.

rini17 7y ago

Right, CFFI is another can of worms. It is sometimes questionable whether the time saved by reusing C code isn't lost by debugging and integration issues. For example I ended up avoiding cl-async (a wrapper over a C library) due to these. In my mind reimplementing in CL is better bet than pulling Docker.

amirouche 7y ago
> I ended up avoiding cl-async What do you use instead?
- rini17 7y ago
  I reimplemented the parts I needed using threads+usockets. There's no fundamental reason it can't be built directly on OS async interfaces, even without threading, instead of C library.
ivan4th 7y ago
Well, I did write quite a bit of CL code for money, but it's hard to get paid for reimplementing every library that one may need in CL ;(
- rini17 7y ago
  I have not meant it in such extreme way at all :( Just this: if something interferes badly with a basic CL feature such as SLIME (cl-async does), toss it.
  - ivan4th 7y ago
    cl-async works pretty well with SLIME if you use its SLIME REPL integration feature that I contributed several years ago. https://github.com/orthecreedence/cl-async/blob/master/src/repl.lisp https://github.com/orthecreedence/cl-async/blob/master/src/r... It basically starts an event loop in a separate thread and then wraps all of the SLIME's evals so they're executed from within that event loop.

amirouche 7y ago

> If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example. That is perfect match for guix channels too. What I do is maintain a repository of package definitions (that possibly inherit from guix master package definitions) and only change a few hashes here and there when I need.