March 2012 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] Double printing of the prompt
by Blake McBride 12 Aug '12

12 Aug '12

Greetings, The latest version of ABCL is double printing the prompt at times as follows: Armed Bear Common Lisp 1.1.0-dev-svn-13783 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.465 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): 3 3 CL-USER(2): 'hello HELLO CL-USER(3): '(a b c) (A B C) CL-USER(4): nil NIL CL-USER(5): CL-USER(5): 77 77 CL-USER(6): (cdr '(hello)) NIL CL-USER(7): nil NIL CL-USER(8): CL-USER(8): 3 3 CL-USER(9):

3 3

[armedbear-devel] destroy-thread and unwind-protect
by James Lawrence 08 Aug '12

08 Aug '12

(defun test-cleanup () (let* ((cleanedp nil) (thread (threads:make-thread (lambda () (unwind-protect (sleep 999) (setf cleanedp t)))))) (sleep 0.5) (threads:destroy-thread thread) (sleep 0.5) cleanedp)) (test-cleanup) ABCL-1.0.0 and ABCL-0.27.0 return NIL. Other implementations I tested all return T -- Allegro, Clozure, LispWorks, SBCL (changing "threads" to "bordeaux-threads"). Of course this isn't a bug since ABCL is free to do what it wishes. Does ABCL wish that?

5 5

[armedbear-devel] JSS issues: bug in jss::with-constant-signature, jss::invoke-find-method?
by Jonathan P. Bona 16 May '12

16 May '12

I'm working with Alan Ruttenberg to port LSW from the old version of JSS to the JSS that is now part of abcl-contrib. We've run into the following bug when using with-constant-signature: ; these first two work fine: (#"substring" "some string" 2 4) ; "me" (#"substring" "some string" 2) ; "me string" ; and so does this (with-constant-signature ((substring "substring")) (substring "some string" 2 4)) ; "me" ; but this breaks: (with-constant-signature ((substring "substring")) (substring "some string" 2)) ; Wrong number of arguments for public java.lang.String java.lang.String.substring(int,int): expected 2, got 1 ; [Condition of type PROGRAM-ERROR] A problem seems to be in jss::invoke-find-method, which is finding the two argument version of java.lang.String.substring no matter how many arguments its given: (jss::invoke-find-method "substring" "this is a string" '(1)) ; should return the java.lang.String.substring method with one int arg ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2) ) ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6 7 8) ) ; should be an error ; #<method public java.lang.String java.lang.String.substring(int,int)> - Jonathan Bona

3 5

[armedbear-devel] Patch with improvements to stable-sort and sort
by Jorge Tavares 07 May '12

07 May '12

Hi, I send in attach a patch with further improvements to sort and stable-sort for sequences other than lists. In short, the patch includes a merge sort for vectors. To allow different types I've written the algorithm using macros and these generate the appropriate code according to the vector type. This way the algorithm is in a single place avoiding duplication of code. The macros also take care of the situation of when no key is present, avoiding the use of unnecessary funcalls. The quicksort algorithm was also refactored in the same way. I've tested the algorithms and they seem to be working correct. Stable sort is now considerably faster since the fix before converted the sequences to a list and used the sort-list function. I've made some benchmarking to verify how fast is sort and stable-sort. The tables with the results are also in a file sent in attach [1]. For stable-sort I've compare the current trunk version with the patched one while for sort I've compared 1.0.1, the trunk and with the patch. For unsorted vectors sort has a speed up of 7.5 from 1.0.1 and this considers only vectors of size 8 to 8192 (1.0.1 hits the worst-case quite fast). For stable-sort the speed up is around 90.2 from vectors of size 8 to 32768. The sort functions become even faster for the nearly sorted vectors. I think the tables clearly show the speed-ups :-) Naturally these benchmarks cannot be used to draw definite conclusions since they lack rigorous testing but I think they can provide some indications. With this patch, I think ABCL gets good performant sorting functions, especially for large vectors. As for lists, I haven't looked at them so probably they can also be improved (but I really don't know). Cheers, Jorge [1] The tables result from the generation of simple-vectors of sizes 8 to 524288 (powers of 2 from 3 to 19) with distinct integer: unsorted, nearly sorted (distances 0, 4 and 16), sorted and reversed sorted. The nearly sorted vectors were constructed by selecting pairs where they would swap with a neighbor at a certain distance. I did 100 runs and timed only the sorting operation. The tables contain the averages of the 100 runs. They were performed in an iMac (2.5GHz i5, 4GB) with Mac OS X 10.7.3. -- http://jorgetavares.com

2 2

Re: [armedbear-devel] run-program :environment nil
by Ville Voutilainen 31 Mar '12

31 Mar '12

On 29 March 2012 17:15, Rudolf Schlatte <rudi(a)ifi.uio.no> wrote: > asdf doesn't use run-program for abcl, just run-shell-command. But I see your point about API changes, especially for a non-major release. I guess right now we're bike-shedding. Let's hear what Pascal prefers, but I'm leaning towards your version as well at the moment. I'm not hell-bent on it, just wanted to point that out since I did consider that even though my patch doesn't mention such considerations. Ville-code is sometimes like that, it's well thought-out and minimal, modify anything and things break (for certain values of "break"), but I'm not the best user of explanatory comments on the planet. :)

1 1

Re: [armedbear-devel] run-program :environment nil
by Ville Voutilainen 29 Mar '12

29 Mar '12

Forwarding my reply to the list too. :) On 29 March 2012 16:55, Ville Voutilainen <ville.voutilainen(a)gmail.com> wrote: > On 29 March 2012 16:41, Rudi Schlatte <rudi(a)ifi.uio.no> wrote: >> Ville Voutilainen <ville.voutilainen(a)gmail.com> writes: >>> Here's a tentative patch. I opted for a new keyword argument, since >>> the new function approach would've led to duplication or to a macro >>> that has the new argument anyway. Untested so far, so this is for >>> general review. Also lacking the docstring changes. >> Here's my version, using your getenv and process-builder changes. I >> get by with only the :environment key, see the docstring for an example >> on how to overwrite PATH and keep the rest. Lightly tested. > > Looks reasonable. Some questions though: > >> -(defun run-program (program args &key environment (wait t)) >> +(defun run-program (program args &key (environment nil environment-p) (wait t)) > > Ah, yes, this works too, no need for a separate clear-env. But, does > this change the > semantics? Our previous code did an environment-merge if an > environment is supplied. > This one will clear and insert, and requires using getenv-all if you > want to replace > only some parts. I don't want to do such a semantics change. By > avoiding the semantics > change, I don't need to worry about breaking asdf. > > For that point, I'm still biased towards the clear-env keyword arg > approach. In that > approach, getenv-all is just an utility function that you can use if > you want to do > weird-complex environment processing, but possibly the most common use cases are > still "replace a couple of values by providing an environment without > clearing" and > "run in a very restricted environment with only a handful of > variables", neither of > which requires the use of getenv-all. > > Comments?

1 0

Re: [armedbear-devel] run-program :environment nil
by Rudi Schlatte 29 Mar '12

29 Mar '12

[Originally sent to Ville only because of a disagreement between Gnus and me]

1 0

[armedbear-devel] run-program :environment nil
by Pascal J. Bourguignon 29 Mar '12

29 Mar '12

(lisp-implementation-version) --> "1.0.1" The documentation of extensions:run-program is misleading: :environment An alist of STRINGs (name . value) describing the new environment. The default is to copy the environment of the current process. The alist doesn't describe the NEW environment, it is only MERGED into the current environment. Now of course, I consider the current behavior to be a bug: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment 'nil))) --> ("NNTPSERVER=news.individual.net" "ESHELL=/bin/bash" …) I would expect: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment 'nil))) --> () and: (text-stream-contents (extensions:process-output (extensions:run-program "env" '() :wait t :environment '(("LC_CTYPE" . "C"))))) --> ("LC_CTYPE=C")) Which would match what the documentation says. Also, in a shell environment, an empty variable is not the same as an inexistant variable, so I cannot just loop over all the existing variables to set them to an empty string. I see no SYSTEM::%PROCESS-BUILDER-ENV-REM function… -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

4 8

[armedbear-devel] ABCL on jdk-1.7.0_03
by Mark Evenson 21 Mar '12

21 Mar '12

I've just run abcl-1.1.0-dev the ANSI-COMPILED tests on jdk-1.7.0_03 with reasonable looking results of 31 failures, which is roughly the same number as those run with jdk-1.6.0_31 (some of the tests use randomly generated data so they sometimes either fail or succeed). Previously, I think that we weren't even completing the ANSI-COMPILED test suite due to issues in the character set encoding, so I think we should now more fully endorse running ABCL on Java7.

1 0