July 2009 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] patch: do not call compile for every call of eql-specialized generic functions
by Anton Vodonosov 14 Jul '09

14 Jul '09

Hello. The attached is a patch to improve performance of eql-specialized generic functions. I started to investigate this problem because slime fuzzy completion works very slow with ABCL. For example (time (swank::fuzzy-completions "de" 'cl-user)) takes 1.5 - 2 seconds. That long time is not pleasant for user interface. Turned out that most of the time is spent in COMPILE. During SWANK::FUZZY-COMPLETIONS every symbol is processed by SWANK-CLASSIFY-SYMBOL, which uses (DOCUMENTATION s 'TYPE), and every invocation (DOCUMENTATION s 'TYPE) being eql-specialized function leads to COMPILE. With my patch (time (swank::fuzzy-completions "de" 'cl-user)) takes 0.25 - 0.5 seconds. Not too fast, in CLISP the same takes 0.07 sec, in CCL 0.03 sec. But significantly better than it was. In the patch method getArgSpecialization could probably be named better. Also I am not sure if you want to keep the wordy javadoc comment; i just decided to put the patch explanation to the sources instead of this email. Best regards, - Anton

2 3

[armedbear-devel] [PATCH] build-from-lisp.sh (take 2)
by Tobias C. Rittweiler 14 Jul '09

14 Jul '09

Ok, I've redone build-from-lisp.sh so that build-abcl.lisp can remain untouched. I also added the feature to set :clean, :full, :batch from the command-line via --clean, --full, and --batch. I used the script to build ABCL successfully on SBCL, CLISP, and CCL. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] [PATCH] fix arglist of EXT:ARGLIST
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

Fix (ext:arglist 'ext:arglist) => NIL. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] [PATCH] build-from-lisp.sh
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

The following makes it possible to build ABCL from the command line directly: ./build-from-lisp.sh sbcl ./build-from-lisp.sh clisp etc. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

3 3

[armedbear-devel] [PATCH] Move some symbols into the THREADS package.
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

The patch attached to this mail moves the usual suspects to the THREADS package. It does not move the Gates-related functions because I think that Gates can be removed again now with the SYNCHRONIZE-ON stuff. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] gmane.lisp.armedbear.devel
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

With this message, the gmane.lisp.armedbear.devel group should be created. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

1 0

[armedbear-devel] Saving stackframes?
by Erik Huelsmann 12 Jul '09

12 Jul '09

When looking at numerous backtraces, I find that the pattern LispThread.execute->Symbol.execute->function.execute happens very often. The only thing Symbol.execute does is forward the call to the function in its function slot. Now, we could save ourselves this stackframe by taking "the stack hit" in LispThread.execute the following way: if (function instanceof Symbol) function.getSymbolFunction().execute() else function.execute() where the execute function in LispThread currently only contains function.execute()... I found our implementation uses a *lot* more stack than the average Java application. This may be a way to reduce that a bit. What about it? Bye, Erik.

1 0

[armedbear-devel] Blog to report on ABCL development progress
by Erik Huelsmann 12 Jul '09

12 Jul '09

Yesterday Tobias Rittweiler brought to my attention that all the good work that's being done on the development of ABCL probably has gone unnoticed in the larger Lisp community: we didn't post our release announcements on usenet (comp.lang.lisp) and we don't have a blog to feed the Planet Lisp syndication with. So, as a first step, I created http://abcl-dev.blogspot.com/ seeding it with a first post. A request has been submitted to add the blog to the Planet Lisp feed syndication. Anybody who has an interest in blogging or submitting a blog once in a while, feel free to step up. The blog is intended to be - weekly or bi-weekly, but not high volume - about the highs and lows that make up the ABCL development experience and progress. Bye, Erik.

1 0

[armedbear-devel] [PATCH] Support for SYNCHRONIZED blocks (and company)
by Erik Huelsmann 11 Jul '09

11 Jul '09

Based on discussion earlier this week, I'd like the following patch to get committed to our trunk. It introduces a new block statement SYNCHRONIZED-ON <object> body and next to that a number of functions: object-wait <object> &optional timeout object-notify <object> object-notify-all <object> So, what's the verdict? Anyway, I plan on including some simple test cases, but ofcourse, if someone feels like doing so, please feel free! Bye, Erik.

4 10

[armedbear-devel] [RFC] Support for 'synchronized' blocks in Lisp code
by Erik Huelsmann 07 Jul '09

07 Jul '09

I propose that we introduce a WITH-EXCLUSIVE-ACCESS form in the EXT package, which takes 1 argument (the second value) and a body (the third value). The form makes sure that the body is evaluated as if it had been called with: synchronized (arg1) { body-to-evaluate; } Except that it implements this in Lisp. This way, our Lisp<>Java interoperability would increase. It would also be an efficient way to guarantee exclusive access when modifying a cross-thread shared resource (such as generic functions). Comments? Bye, Erik.

5 7