- qitab-devel - mailman3.common-lisp.net

New cl-stomp maintainer: Dirk Eßer
by Faré 04 Apr '19

04 Apr '19

I doubt anyone is listening here, but out of due diligence, I announce the new maintainer, Dirk Eßer. The cl-stomp-devel mailing-list was victim of some reorganization of common-lisp.net, so I'm posting the announcement to the closest thing, qitab-devel. Dirk, you may want to be added to the project so you can edit the web page https://common-lisp.net/project/cl-stomp/ — then remove the mention of the cl-stomp-devel mailing-list and instead refer to the gitlab issues, or then again get the list reinstated. If some of you use cl-stomp and have a reason to fear an event-stream kind of attack, here is your chance to cop out and fork before it's too late. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Amara's Law: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.

1 0

Re: [Qitab-devel] A problem of quux-hunchentoot and its solution
by 昊谢 25 Apr '14

25 Apr '14

+ qitab-devel On Apr 25, 2014, at 15:00 , 昊谢 <xiehao(a)outlook.com> wrote: > HI Francois-Rene Rideau, qitab-devel, > > I encountered a problem when I’m using your quux-hunchentoot and I have a simple way to fix it. Could you please consider it? > > When I’m using the thread-pooling taskmaster and starting acceptor, there may be an error invoked occasionally like this: > debugger invoked on a SIMPLE-ERROR in thread > #<THREAD "quux-hunchentoot-dispatcher-*:8080" RUNNING {10035DDF03}>: > The assertion > (EQ QUUX-HUNCHENTOOT::DISPATCHER-PROCESS (BORDEAUX-THREADS:CURRENT-THREAD)) > failed with QUUX-HUNCHENTOOT::DISPATCHER-PROCESS = NIL, > (BORDEAUX-THREADS:CURRENT-THREAD) = > #<SB-THREAD:THREAD "quux-hunchentoot-dispatcher-*:8080" RUNNING {10035DDF03}>. > > I think the reason for this is quite straightforward. While the method “execute-acceptor” is creating dispatcher thread and set it by the dispatcher-process accessor of taskmaster, we can’t imagine the “setf” action comes first. In other words, if dispatcher thread started before the accessor was set, the assertion in ensure-dispatcher-process may fail. > > My solution for this is quite simple and here’s the effective solution, adding something like a spin-lock. > diff --git a/thread-pooling.lisp b/thread-pooling.lisp > index dcb3427..8f3f32b 100644 > --- a/thread-pooling.lisp > +++ b/thread-pooling.lisp > @@ -146,6 +146,7 @@ then the reply will be HTTP 503.")) > > (defmethod ensure-dispatcher-process ((taskmaster thread-pooling-taskmaster)) > (with-taskmaster-accessors (dispatcher-process) taskmaster > + (do () (dispatcher-process) (sleep 0.1)) > (assert (eq dispatcher-process (bt:current-thread))))) > > (defmethod decrement-taskmaster-accept-count ((taskmaster thread-pooling-taskmaster)) > > Maybe you can get a better patch to solve this problem and I’m looking forward your reply. > > Thanks & have a good day > Hao Xie

2 2

[Qitab-devel] cl-protobufs
by Faré 16 Apr '14

16 Apr '14

Is anyone using cl-protobufs beside the QPX team at Google (née ITA)? Our resident speed junkies have slightly incompatible changes under the hood, such as using defstruct instead of defclass. If you're impacted by this, positively or negatively, we're interested in hearing from you. I see that nothing in quicklisp uses cl-protobufs, but someone could be using it privately, I'm sure. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you want to do good, work on the technology, not on getting power. — John McCarthy

1 0

[qitab-devel] default (interactive) output mode for run in inferior-shell
by huang ying 22 Jan '14

22 Jan '14

Hi, I found in README of inferior-shell, it is said that the default output mode is as follow: NIL (default) for inheriting the parent process's stdout, But in recent uiop implementation, the ":output nil" means to redirect to /dev/null, while ":output :interactive" means to inherate the parent process's stdout (at least for sbcl). So I think we should change the default value of output parameter for run or change the README. What do you think about that? Best Regards, Huang Ying

2 3

[qitab-devel] Re: Quepasa?
by Faré 21 Jan '14

21 Jan '14

On Wed, Nov 6, 2013 at 2:51 PM, Derek Davies <ddavies(a)ddavies.net> wrote: > > Great news! I would not be upset if I suddenly became subscribed to the > -dev and -announce lists :) If not, I'll attempt to subscribe via email. > Well, don't be upset, then :-) You should be receiving this message via the mailing-list. > I'll start peeling quepasa out of the publicly released stuff and put it up > in a random GIT repo. Once I'm on the -dev list I'll make an announcement > and post progress as suitable progress is made. > If you need utilities from quux that are not in alexandria, I propose we start a separate git repo called "quux" or "qitab" and we start moving utilities there using asdf-package-system style. There's a github group "qitab", and you should probably be added. Do you have a github account? https://github.com/qitab —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To fight a violent enemy, violence is necessary; but to fight violence itself, violence is vain.

3 6

[qitab-devel] quepasa
by DDavies 16 Nov '13

16 Nov '13

Hi, I'm fiddling around with qupasa. Does anyone remember where qmp comes from? E.g. there are calls to qmp:define-thread-variable. Thanks, Derek

2 1

[qitab-devel] Open-Sourcing QUUX, QUAKE, QUEPASA, etc.
by Faré TUNES 27 Sep '13

27 Sep '13

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

1 0

[qitab-devel] Nested extensions in cl-protobufs
by Thomas Munro 22 Sep '13

22 Sep '13

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

1 1

[Qitab-devel] POIU
by Faré 09 Jan '09

09 Jan '09

I published POIU on QITAB: http://www.cliki.net/poiu http://common-lisp.net/projects/qitab/ POIU will help you compile your ASDF systems in parallel, until XCVB becomes a valid ASDF replacement. Thanks to Andreas Fuchs for writing it initially, and apologies for the long delay in publishing it! You can git clone http://common-lisp.net/project/qitab/poiu.git and if you're a developer, use you can git clone ssh://common-lisp.net/project/qitab/poiu.git [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] I'd give my right arm to be ambidextrous.

1 0