Dear Common Lispers,
I am pleased to announce an initial release as open source (under the
MIT license) of QUUX, QUAKE, and the rest of the infrastructure used
by QRes.
Currently, all that is available is a tarball with files excerpted
from our source tree and lightly scrubbed:
http://common-lisp.net/project/qitab/archives/quux-2013-09-24.tar.bz2
This is not directly usable, and won't even compile, but we realized
that by failing to release, and not spending resources on a clean
release either, we were only losing mindshare and the opportunity to
outsource part of the cleanup and bugfixing, so there it is.
We expect some interested lispers to loot the code for useful bits,
integrate them in their own libraries, that we may perhaps someday
reimport into our code base.
This qitab-devel mailing-list is a proper venue for discussion on how
to take apart the codebase and get pieces to work cleanly outside of
it. There is no official support for that code from Google engineers,
but we will still try to be helpful, even without firm commitment. On
the other hand, there are of course plenty of Lisp consultants around
the world who will gladly offer you commercial support if you pay them
enough.
Some known issues:
* We haven't yet worked on extracting history, but will try to unearth
some useful history. Even then, commit messages will be essentially
non-informational, because it's too much work to scrub potential trade
secrets from an entire history. Stay tuned.
* (bug 10342133 & 7868425) Quake fails to do its updates, inserts,
deletes and mod_count checks in a consistent order (e.g. via sorting
object ids) which causes database deadlocks.
* We are experiencing stability issues at times using CCL 1.9 and the
current multithreaded server. An uncommitted patch improves on the
multithreading using thread-pooling, but exposed a memory leak issue
that may or may not have been fixed.
* Support for MySQL as a backend is also available as an uncommitted patch.
* We may or may not include our patched (but now antique) SLIME in a
further release.
* There are probably many more issues that will surface if anyone
actually tries to use that code.
* QUUX is a ball of mud that begs to be taken apart in smaller units,
such as the previously published QUUX-TIME (though we recommend you
use LOCAL-TIME, and push any useful feature you miss from the former
to the latter).
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
We mathematicans are all a bit crazy. — Lev Landau
Hi!
I am starting out with cl-protobufs. I would like to interact with a
service that is doing the equivalent of the following line of Python, which
allows polymorphic treatement of animals, creating a cat and serializing it
for transmission to a recipient expecting an Animal (the base message).
animal = Animal()
animal.type = Animal.Cat
cat = animal.Extensions[Cat.animal]
# now work with cat...
# now serialize animal ...
That example is from the tutorial at
http://www.indelible.org/ink/protobuf-polymorphism/ which shows the .proto
file containing Animal, Cat and Dog messages.
How would this code look in cl-protobufs? I'd be most grateful for any
clues. I couldn't see anything like like this in the examples (but I admit
I'm totally new to the protobufs concepts, and rusty at Lisp, so might have
missed it...).
Thanks!
Thomas
