Few words about Lisp

Status update

2010-12-05T17:52:00.000+01:00

Not much news to the moment. Except I joined Lisp startup (NovaSparks) and moved to Boston, MA in the middle of November.

Why zero-copy is missing in CL-ZMQ

2010-06-18T17:20:00.002+02:00

ZeroMQ can utilize zero-copy technique, which may save a lot of cpu ticks when using large messages. Unfortunately, it's not possible to get this feature to work with supported Common Lisp implementations due to a couple of reasons:

ZeroMQ uses threads for asynchronous I/O operations on messages. When it finishes all the work with message's data, it calls back Lisp to let it know that data can be safely ripped out.

Unfortunately, not all Lisps can distinguish and handle callback from non-lisp thread. For example, Clozure CL feels good here, but SBCL crashes and LispWorks just hangs.

Garbage collector may move lisp objects, which are currently used in I/O threads. This leads to image corruption or segmentation fault.

Widely used with-pinned-object technique is not working here, because ZeroMQ operates asynchronously and pinned body can't protect data from GC when it needs to. It's possible to turn off garbage collecting completely or design system in such way, that it won't do gc'ing when it shouldn't. But that's a hard way.

Other possibility is to allocate objects in static area, where garbage collector doesn't move live objects. Some Lisps support this feature, for example AllegroCL, LispWorks and GCL.

If both features (callback from non-lisp thread, objects in static area) are supported by certain Lisp implementation, it's possible then to use zero-copy in CL-ZMQ. Unfortunately, all four Lisps that I use for development and testing (SBCL, Clozure, CLISP and LispWorks) miss this combination.

CL-ZMQ and LispWorks 6

2010-06-13T11:06:00.000+02:00

Since yesterday I'm happy user of commercial version of LW.

LW complains about unshadowed symbol `identity'. Yeah, that's strange it wasn't yet catched by 3 other lisps I tested with (sbcl, clisp, ccl). Other minor problem was with `trivial-garbage' library: it uses `hcl:mark-and-sweep', but this function exists only on 32-bit LWs. 64-bit uses `system:marking-gc'. Also `system::hash-table-weak-kind' has a bit different name: `system::hash-table-%weak-kind'.

Otherwise everything works good. LW is officially supported by CL-ZMQ now :)

Hugepages patch

2010-03-12T16:13:00.001+01:00

Got something working:

http://paste.lisp.org/display/96287

How to run:

# echo 200 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
# mkdir /dev/huge
# mount -t hugetlbfs none /dev/huge -o size=800M,mode=777
$ sbcl --hugetlbfs-path /dev/huge --huge-pages-nr 200

Here 800 megabytes of memory is prepared for use as huge pages. SBCL has two new command line switches now. If there's something wrong with hugetlbfs, SBCL will fallback to "usual" memory.

To extend feature for other OSes, where POSIX API for hugepages is available, you need to add only few bits:

diff --git a/src/runtime/linux-os.c b/src/runtime/linux-os.c
index 9b2e3cf..386fc25 100644
--- a/src/runtime/linux-os.c
+++ b/src/runtime/linux-os.c
@@ -56,6 +56,8 @@
#include "cheneygc-internal.h"
#endif

+#include "hugepages.h"
+
#ifdef LISP_FEATURE_X86
/* Prototype for personality(2). Done inline here since the header file
* for this isn't available on old versions of glibc. */
@@ -313,7 +315,10 @@ os_validate(os_vm_address_t addr, os_vm_size_t len)
         addr=under_2gb_free_pointer;
     }
#endif
-    actual = mmap(addr, len, OS_VM_PROT_ALL, flags, -1, 0);
+    actual = huge_page_validate(addr, len);
+    if (!actual)
+        actual = mmap(addr, len, OS_VM_PROT_ALL, flags, -1, 0);
+
     if (actual == MAP_FAILED) {
         perror("mmap");
         return 0;               /* caller should check this */
@@ -337,6 +342,7 @@ os_validate(os_vm_address_t addr, os_vm_size_t len)
void
os_invalidate(os_vm_address_t addr, os_vm_size_t len)
{
+    huge_page_invalidate(addr, len);
     if (munmap(addr,len) == -1) {
         perror("munmap");
     }

In other words, only new header and small modification of os_validate and os_invalidate are required.

UPD: Garbage collector works much slower with the patch and needs further investigation.

SBCL and huge pages

2010-03-12T08:59:00.000+01:00

Yesterday was a lucky day: I compiled SBCL with sb!vm:*backend-page-bytes* = 2097152. There were several problems preventing doing this, but, hopefully, all of them are solved. At least, I'm able to run new core and do everything, what comes in mind, for example, load ZeroMQ2 bindings.

Next step is to teach memory allocator to mmap() pages from hugetlbfs. That will give SBCL real 2mb pages, not 2mb regions composed of 4kb chunks.

Stay tuned!

Hugepages save the kittens

2010-02-17T17:17:00.005+01:00

Imagine, we need to read and eval code from some untrusted source. This code may change lisp environment in uncertain way as expected behaviour, but it may also contain error, which stops execution in the middle. This is not what we want: environment should be changed completely or rolled back to previous state.

Naive approach to solve the problem is to fork() lisp image, execute untrusted code in the child (child will be the full clone of parent), return zero in the case of succes and non-zero value otherwise. Parent may check if it's safe to executes code in its environment this way . This is only few lines of code:

(defun rep (expr)
(eval (read-from-string expr)))

(defun safe-eval (expr)
(let ((pid (sb-posix:fork)))
    (cond
      ((plusp pid)
       (multiple-value-bind (pid status)
         (sb-posix:waitpid pid 0)
        (declare (ignore pid))
        (when (zerop status)
         (rep expr))))
      ((zerop pid)
       (handler-case
         (rep expr)
        (error ()
          (sb-ext:quit :unix-status 1)))
       (sb-ext:quit :unix-status 0))
      (t
       (error "fork failed~%")))))

It doesn't even matter if child's image completely crashes due to uber-invalid code or compiler's bugs, parent will survive and understand that the code is bad. Next question is: how expensive fork() operation is?

Linux kernel (I'm Linux-only guy) is enough smart not to copy all the process data one-to-one: it uses copy-on-write (COW) technique to separate memory pages of new process from respective pages of old process only at the moment of page changes. So, basically, kernel duplicates task structures for the new process, and that's all.

Unfortunately, modern lisps (like SBCL) creates huge image up to tens megabytes, and it may grow up to gigabytes. In-kernel VMA chains, which describes how much memory the process has and how this memory is organized in address space of process, may grow significantly. The cost of fork operation grows respectively (not to mention, overall system slowdowns as well). One of accessible and acceptable solution is to use huge pages in those programs, which manipulate with a large memory portions.

Normal page size is equal to 4 kilobytes on most of systems. However, modern hardware allows to set page size for part of memory to larger size. For example, x86-64 supports huge pages of size 2 megabytes.

I wrote a small test, which allocates portions of memory with normal and huge page size, and does fork(). Let see the results:

Gosh!... Fork of a process with normal-sized pages is soooo slow! And huge pages definitely rocks!

I wish SBCL built-in memory manager to work with hugepages...

New Gmail's COMPRESS=DEFLATE feature

2010-01-24T18:07:00.001+01:00

Two days ago I noticed that Google implemented RFC4978 for their mail service. In short, Gmail is able now to compress all traffic with deflate method. Wanderlust shall support this feature!

Unfortunately, my attempts to find ready-to-use deflate/inflate code in Emacs Lisp have been failed. Even it is impossible to access zlib functions from Emacs Lisp (Emacs links with -lz) without hacking Emacs first. So I decided to write a wrapper, which will stay in between of Emacs and gnutls-cli, which I use for TLS. Gnutls-cli is fully text-oriented client, so it has problem with handling binary data from standard input. I did a small patch to fix it:

--- src/cli.c.orig      2009-06-02 20:59:32.000000000 +0200
+++ src/cli.c   2010-01-24 17:48:05.636222100 +0100
@@ -749,7 +749,8 @@ after_handshake:

       if (FD_ISSET (fileno (stdin), &rset))
        {
-         if (fgets (buffer, MAX_BUF, stdin) == NULL)
+         int bytes;
+         if ((bytes = read (fileno(stdin), buffer, MAX_BUF)) < 0)
            {
              if (hd.secure == 0)
                {
@@ -778,11 +779,13 @@ after_handshake:
          if (crlf != 0)
            {
              char *b = strchr (buffer, '\n');
-             if (b != NULL)
+             if (b != NULL) {
                strcpy (b, "\r\n");
+               bytes++;
+             }
            }

-         ret = socket_send (&hd, buffer, strlen (buffer));
+         ret = socket_send (&hd, buffer, bytes);

          if (ret > 0)
            {

The wrapper is mostly functional now, but I need to beatify it first before releasing to public.

As for results... Deflate is known for its ability to recognize similar patterns and replace them with only one pattern definition and references for the rest. I tried to do uid search uid 1:* undeleted in my Inbox folder. At first, Gmail sent me 12401 byte of deflated text. For the same query, sent for 2nd time, it returned only 581 byte, which consisted mostly of the references to already received patterns. Usual uncompressed text is of 25993 bytes. That's pretty amazing!

Thunderbird 3

2010-01-24T14:58:00.000+01:00

Do you know why modern desktop software is so huge? Because most of modern programmers simply do not care about size. For example, Thunderbird 3 sources goes with 2 zlibs: one is at comm-1.9.1/mozilla/modules/zlib/src and another one is at comm-1.9.1/mozilla/security/nss/cmd/zlib. Brilliant.

Wanderlust

2010-01-15T19:21:00.001+01:00

Almost all stuff from more-wl was committed in upstream today. Rest patches, which left in more-wl, weren't really needed, because I've reimplemented the wheel due to insufficient documentation.

Qpidc trampoline

2009-12-21T22:22:00.000+01:00

I know what to do during long three weeks of my days off. Earlier this day I started to type C wrapper for libqpidclient -- the client part of AMQP from Qpidc project. To type, exactly. There's so much copy-and-paste boring work, no room for brains. I suspect, it will take quite a lot of time to implement every class from Qpidc horde...

At the end I want to have something ready to bind in Lisp. May be, other languages also can benefit from this work.

Throughput test using small messages

2009-12-10T18:08:00.001+01:00

Previously I found Lisp bindings performance in throughput test is not good enough when message size is small. This performance drawback can be explained be overhead, introduced by high-level wrappers for libzmq functions. At the very top of bindings there are more o less lispish functions, which works with C data structures wrapped in CLOS instances, checks low-level functions for return values and raises error conditions, when needed. Also, CFFI adds one more wrapping level itself. So, bindings contain up to 4 levels of dummy calls from high- to low-level.

Obviously, under certain conditions throughput peformance is literally equal to how many times code can execute zmq_send(). If you need to break through tons of wrappings, throughput will sufffer a lot due to wrappers.

Fortunately, such behaviour (many calls to zmq_send() in blocking mode, small message size) is not typical. But even in this situation it is possible to use low level libzmq functions and manage all the stuff by hands.

I did another test for message sizes of 1, 2, 4, 8, 16, 32 and 64 bytes. Messages with sizes below 30 are Very Small Messages (VSM), and zeromq library embedds VSM space directly into message header. Result of testing wasn't stable, so all tests were run 10 times.

Here's difference between "normal" and "optimized" versions of bindings and test sources. "Optimized" means there's (declaim (optimize speed (safety 1))) in cl-zmq sources, also both local-thr.lisp and remote-thr.lisp use CFFIized functions directly.

ERRATA: There's bug in pictures 1 and 3, second "Optimized Lisp ranges" should be "Normal Lisp ranges". Unfortunately, I lost original data and can't regenerate pictures easily.

If you use VSM messages (30 bytes or less) in your software, which requires maximum throughput, it makes sense to write your software in low-level C-style... Perhaps, it's better to redesign software to use large messages, but it's up to you ;)

To compare C and optimized version of Lisp:

As you see, throughput is almost equal with message size of 16+ bytes.

Finally, all the mess: "normal", "optimized" Lisp and C in one place.

Performance.... Performance...

2009-12-04T17:03:00.001+01:00

Just did some brief latency and throughput testing.

I've used two 64-bit machines, connected by 1Gb switchless network. Machines are:

1. Core2Duo T9600 2.8GHz running Fedora 12

2. Core2Duo T9400 2.53GHz running RHEL-5.4 with realtime kernel.

Here's latencies compared to C:

Latencies are fine. The throughput in term of messages per second:

Not bad also, except small messages. Throughput in megabits per second:

Small messages is problem. Network latency and context switches cost can't compensate overhead added by bindings. Fortunately, I haven't even thought about optimization yet, so there's large field to improve :)

ØMQ/2.0 can boost your Lisp application. Lisp can boost your financial application.

2009-12-03T11:10:00.000+01:00

I'm pleased to announce inclusion of CL-ZMQ into ØMQ/2.0 mainline tree.

Common Lisp is fast for real business.

2009-12-02T14:34:00.000+01:00

I'm reading ØMQ Whitepapers, especially bits related to performance measurements of Java and Python bindings. Java is something 20% slower comparing to C, and Python works almost 2.5x times slower (very expected).

SBCL kicks asses, I got the same latencies over 1Gb network, like in C. Thanks to CFFI library and decent compiler in SBCL.

Currently I have conversation with Martin Sustrik (FastMQ CEO and architector of ØMQ) about merging Common Lisp support into main tree.

CL-ZMQ is almost ready to go

2009-11-22T14:28:00.000+01:00

Just commited large patch to CL-ZMQ. Main change is elimination of MOP wrapper, which I took from my other project - CL-V4L2. Video4Linux2 API has quite a lot of complex structures, so automatic bindings generation was a must there. But ZeroMQ2 API has only 2 simple structures, so horrible macro `define-wrapper' was definitely an overkill.

As a plus, sources are much simpler now, they started to work with CLISP. Also CLISP showed me a couple of bugs related to memory management and message object initialization. All tests in perf/ work both with SBCL and CLISP and their combination. I'm about to tag sources as version 0.1 in a couple of days.

Btw, if you're going to try CL-ZMQ, you need to build latest zeromq2 without eventfd support (add --disable-eventfd to configure options). Eventfd feature is still buggy in ZeroMQ2.

RESTAS - new web framework from cold Russia

2009-10-20T20:22:00.000+02:00

Well-known russian lisper Archimag aka Andrey Moskovitin just announced his home brewed web framework, based on several interesting ideas. His blog is in Russian, but it is more or less google-translatable.

Distributed computing in Lisp. Again :)

2009-09-26T02:05:00.000+02:00

Half year ago I've started a library for distributed computing. Yes, I know, there are many of them, but I wanted to write one more, just to have experience in that area.

Library (called cl-cluster) uses SSH to get a remote shell, run some lisp and execute given code directly in it. SSH was chosen, because I didn't want to write some kind of tcp server/client. Also I didn't want to write fault tolerant remote objects broker with migration between hosts, etc, so transport level may be really simple.

Besides not very interesting stuff like making connection, sending and receiving data, there were a few moments:

One problem was how to prevent remote lisp from falling to debugger. There are 2 possibilities to trap: parse errors and execution errors. Later problem is relatively simple, I just need to wrap main request's body in (handler-case ...). Parse errors are different, they trigger before handler-case will be able to catch them. The best solution I found was to pass body as string and parsing it on remote side using read-from-string and eval it. Thus, making toplevel input form errors free and fully controlled by the library. Of course, handler-case and read-from-string ate some speed, but it's not important for my proof of concept :)

Another problem is: not all lisp objects can be read back from their printed representation. Especially, I faced to problem of parsing remote exceptions on local side. I've ended up returning exceptions in the form of list with symbol "error" as first argument and error description as second. This is very unlikely that regular user-provided code will produce such result. On local side I rise exception with received description, noticing the node where this exception has really happened. In practice, it looks good.

One more trap was spotted with passing packages names to remote: format specifier ~a just cuts package designators, producing (oos 'load-op :asdf) instead of (asdf:oos 'asdf:load-op :asdf). This is not so tricky for experienced lisper, but I've spent some time understanding what's going on and then switched format to ~s.

At the end I wanted to have a let-like macro for parallel execution of bindings on remote machines, gathering results, and passing preprocessed bindings them to another machine. For example:

;; calculate some stuff on remote lisps and aggregate answers on another remote

(rplet node3

       ((a (with-remote node1

                        (+ 1 2)))

        (b (with-remote node2

                        (sqrt 7d0))))

      (* a b))

A and B will be computed in parallel on nodes node1 and node2 respectively, after that node3 will get request:

(let ((a someval)

      (b anotherval))

  (* a b))

For parallel tasks dispatching I've used the cl-pmap library, written by my friend Alexey Voznyuk a.k.a Swizard. It's not the best solution, because it uses thread per task, whereas I was needed simple i/o muxer to write data to several output streams and read results back from input. It'd be a good idea to use iolib instead.

Recently I've tried to make the library portable across different popular Lisps, but, seems, there's no existing wrapper for asynchronous shell execution, allowing to communicate with it via streams. The most closest library, trivial-shell, hasn't this possibility. Quick overview of trivial-shell sources told me, there will be problems to do such thing on some implementation due to bugs or whatever else.

The last idea is to get rid of SSH and use Zero MQ for transport :) Real life application will help to do good zmq bindings, and also zmq's subscriber model can help to cl-cluster with common changes propagation across all slave nodes. Not telling, zmq can use advanced networking techniques and save some microseconds ;)

As usually, sources are hosted at repo.or.cz: http://repo.or.cz/w/cl-cluster.git

Zero MQ + Lisp

2009-09-18T15:09:00.001+02:00

Last year I got interested in AMQP.

The most advanced implementation was/is Qpid, because it's a flagship product of such famous companies like JPMorgan, Goldman Sachs, Cisco, RedHat and many others. That means the standard was bloated a lot, you can see it, for example, by looking at specs 0-9 and 0-10: first is relatively simple, later is not. I'm afraid, it will ends up like Corba did. Unfortunately, RedHat and other guys are not interested in Lisp, but I thought it might be useful to have such library in Lisp, so thick and rich customers can use "official AI language" in their projects, and Lisp can benefits from it.

After a two weeks of dancing around Lisp client implementation, I gave up. It was too huge work for me, beginner... A year later I've returned back to that theme and found ready to use Qpid client, fully implemented in Python. Python is closer to Lisp, I thought, so it's possible to use Python codes as a guideline. Heh... Sources are more than 350k in tarball, and it's only a client... It's easy to imagine, how much time will it sweep away from my life doing the same way in Lisp. A lot of complicated code to write, a lot of bugs to fix. No, I didn't really want it. I've decided to wrap Lisp calls, minimally required by standard, into Qpidc calls via CFFI. However, Qpidc is written in scary C++ with a lot of Boost (scary for bindings), so it required me to to write a wrapper for calling C++ from C first.

Next idea, which came to my head due to laziness, is to google if there're any good AMQP realizations with ready to use bindings in C. It can be less powerful and less bleeding edge, but I just needed simple, convenient messaging. I found ØMQ.

Zero MQ is not AMQP messaging library, but can use AMQP as an underlying wire-level transport. Feature list said it also has support of OFED, like Qpidc has. But the most impression I got by looking at API. It darn pretty simple! And it is even more simpler in version 2.0, which is in alpha stage at the moment. It is so simple, that I was able to CFFI'ize the only required zmq.h in one hour, and it worked for me. Impressing!

Latency measurement using server and client both written in Lisp showed me quite good results:

message size: 1024 [B]
roundtrip count: 1000
average latency: 48.7915 [us]

It's even slightly better than in C (with asserts commented out) :)

Current bindings are in the early stage and have ugly CFFI interface, but I'm gonna make it a bit nicer and easy to use.

Sources are here: http://repo.or.cz/w/cl-zmq.git

Eyes region tracking in Common Lisp

2009-09-17T13:42:00.003+02:00

I was going to implement eyes region recognition in Lisp, but seems I'm loosing interest in that area. So I've decided to publish what I already has and forget about it.

I've used CL-V4L2 to capture images from two USB cameras and CL-GTK2 with GtkGlExt extension for rasterization. The main idea of how to detect eyes region was taken from [1]. I can also mention [2] and [3].

The basic idea is to apply edge detection filter to gray scale image, this will stress regions with lots of details. More details, more edges, more visibility in filtered image. Region around eyes has a lot of details, btw. Next step is to compute vertical and horizontal derivatives of edges and find extremums at each axises. Ideally, this will give us one horizontal extremum at eye's level and two vertical extremums at the head borders. Or, if a very strong median filter was used, it may give you one vertical extremum near the center of the face.

However, I didn't succeeded in finding of good filter. First filter I've used was Sobel's operator [4]. Basically it works well for edges detection, but... Too much well for my task... It also finds edges in background parts, like shelf, window, wall corner, etc. All this edges were false positives for my purpose. I've started to play with different similar filters, like Scharr's operator, Robert's cross [5] and also my own modifications of Sobel. The intention was to stress horizontal derivatives of edges during energy computation at X axis and, contrary, vertical derivatives at Y axis. I found Sobel/Scharr filter works better if G (gradient magnitude) was computed separately for X and Y energies the way described below:

Here's matrix for Sobel:

and for Scharr:

I've combined Gx from Scharr and Gy from Sobel to compute G for X energies and Gx/Sobel, Gy/Scharr for Y energies.

So, filters output was slightly improved, but still not enough to reduce unneeded edges. Much better result was brought by simplest Robert's cross. It doesn't filter edges well, but edges itselves are not what we definitely want. We want to stress eyes region, and Robert's cross does it better than Sobel or Scharr. However, image processing became more sensitive to background light. The only good time during the day was at evening when artificial daylight lamps were turned on. Noise reduction filters (a bunch of different modifications of Gaussian filter) didn't help at any degree. Finally, all smart computational logic was swept away leaving plain Robert's cross alone, which gave me the best result. Most of problems were caused by my beard and mustache, but I'm not gonna sacrifice my True Siberian Beard(tm) for the glory of science :)

In my best attempt, I got this:

I really enjoyed to play with it in Lisp, because Lisp gives you very powerful constructions like LOOP macro, which, for example, allows you to implement digital filter very quickly with only small amount of syntactical garbage. I can't forget to mention about automatic memory management, it saved me a ton of time. Nevertheless, with all these high-level whistles and bells, my non-optimized program still worked quite fast. I'm happy.

Source is available here: http://paste.lisp.org/display/87221

1. http://journal.info.unlp.edu.ar/Journal/journal15/papers/JCST-Oct05-3.pdf
2. http://www.montegen.com/Montegen/Nature_of_Business/The_Library/The_Pocket-Science/The_Pocket-Science_Vol__4/Security___Intrusion_2000/Eye_location.pdf
3. http://www.ecse.rpi.edu/~qji/Papers/frgc_eye.pdf
4. http://en.wikipedia.org/wiki/Sobel_operator
5. http://en.wikipedia.org/wiki/Roberts_Cross

Video processing

2009-08-25T20:38:00.004+02:00

At my previous job I was working on integrated security system (ISS). One of major task was to capture and process video from video cameras. Usually, it was looked like PC-box with 3-4 very cheap tv-tuners based on bt878 and connected to some kind of "intellectual" signal splitter. It was possible to connect up to 32 cameras using single high-frequency cable of length up to several kilometers (I don't remember maximal extents, sorry). VGA-signal from camera was modulated by special small box, so all three dozens were connected to PC using one cable. If that looks like drastically cheap solution for you, I can ensure you: actually, it is even cheaper than in your dreams! ;)

Our PC boxes were powered by Red Hat Linux 9 and, later, Fedora 2 and 5. Software was written entirely in C++ plus a bunch of shell and perl scripts. For video capturing itself we used Video4Linux2. It was approximately 1.2 megabytes of source code, some parts of it with heavy usage of Boost library. I can say, it was PITA to do research job in project, because, nevertheless we had ability to do partial builds via autotools, project was building at least 2-3 minutes, even after one small change. I didn't know any other computer language at that time, except "must have" z80 and x86 assemblers, C/C++ and some shell/perl. Ok, assembler isn't "must" now, but is highly recommended and useful in video processing tasks, believe me :) Of course, as a normal mainstream programmer, I participated to flame wars at internet forums w.r.t "super high-level" languages, and heard, these new languages can speed up development several times. So, I had some thoughts how would it great to abandon C++ in our ISS at least in non-critical parts like GUI, setup tool, logic, etc.

Later I've started to read Common Lisp books and use SBCL for dumb helloworlds. I found Common Lisp is pretty lovely and, in the case of SBCL, is enough fast tool. I wanted to give it a try in video processing, but have changed my employer and country :) Heh.

2 years flew away, some weeks ago, being kinda more seasoned Lisp programmer, I started to dance around CFFI-bindings for Video4Linux2 - CL-V4L2 project, which, in future, should be a base for my small home ~~brewed~~made ISS. The project sources are at public GIT repository repo.or.cz. Currently, it's possible to capture video from both my web-cameras. I don't have tv-tuner yet, but I'm almost sure it will work.

Example in CL-V4L2 uses CL-GTK2 to draw a picture in GTK-window. I sent a patch to CL-GTK2's author, Dmitry Kalyanov, the patch adds ability to use GL-accelerated canvas in your application (via gtkglext library). Dmitry should prepare new sources for inclusion in CL-GTK2 shortly. I remember image scaling was one of the largest CPU consumer in ISS, and bulk GLDrawArea-prototype showed pretty good results: image scaling became as cheap, as a cost of cheapest modern graphic card you can buy in stores.

So, basically, bindings are ready for work, but they are capture oriented only, no video output, no VBI, not all ioctls and structure are implemented. However, it is quite easy to extend its feature set now. Use it, enjoy it, report bugs :)

Here be dragons

2009-08-25T19:48:00.001+02:00

Finally, I was pushed to start blog in English. Yeah, my wife told me it can be useful for other people who can't read my russian blog (with the same name at livejournal.com).

Ok, I'm gonna write here about my openings in the world of Common Lisp. I've started to discover this great language about 2.5 years ago, and now able to put down a couple of lines of code in Emacs.

2008-03-24T12:39:00.000+01:00

Тест