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

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

28 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

[armedbear-devel] compiled errors: debug.assertTrue()
by scarbonell＠ono.com 06 Mar '12

06 Mar '12

Hi, When I try to compile the mcs-core.cl file (attached) with java abcl, I get this error: Failed to get InputStream for 'jar:file:D:/otro/kernel/modules/fmcs.bin!/mcs_core_4.cls'ABCL Debug.assertTrue() assertion failed!java.lang.Error: ABCL Debug.assertTrue() assertion failed! Why is this happening? How can I resolved it? Thanks

3 3

[armedbear-devel] compiling lisp files outside Java and calling it after with abcl
by scarbonell＠ono.com 02 Mar '12

02 Mar '12

Hi,I'm trying to compile a lisp application and I get a lot of errors with java abcl. I thought that if I try to compile this lisp files outside of abcl with other systems, perhaps, I could then call this compiled functions lisp files from ABCL (look like a jar file of lisp compiled files). Is this possible?How can I compiled this files outside ABCL? Some examples?Thanks

5 10

[armedbear-devel] Upcoming abcl-1.1 branch
by Mark Evenson 25 Feb '12

25 Feb '12

On [#abcl]() yesterday, ehu and easye discussed how it would be a good idea to start packing up for shipping abcl-1.1 out the door. [#abcl]: http://webchat.freenode.net/?randomnick=1&channels=abcl&prompt=1&uio=d4 Out of our brief discussion, we'd like to branch the trunk in about a week, stabilize with testing, and then release abcl-1.1.0 on 14-FEB-2012. So, unless there are objections, we'd like to start by asking everyone who was thinking of patching something, to think about getting some time in the next week to get something done. All potential contributions are welcome. If you were going to document something, now's the time! [Rudi added real BibTex-based markup to the Manual][1], so even something as trivial as fixing the references would be appreciated. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=5c7faeeb35408… yers in CONS, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Patch for ABCL to dynamically load CFFI JNA requirement
by Mark Evenson 24 Feb '12

24 Feb '12

Please consider the referenced patch for inclusion in cffi-0.10.7. Comments towards improvments solicited. Improvements to ABCL CFFI implementation: o autoload the 'jna.jar' dependency if possible (requires abcl-1.1.0-dev) o initial implementation of callbacks Needs ABCL specific tests, but I can load CL+SSL with this patch. [1]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-20120224a.diff Cheers, easyE -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] 김영태님이 Abcl님을 Facebook으로 초대하셨습니다
by Young Tae Kim 05 Feb '12

05 Feb '12

안녕하세요, Abcl님! 내 사진, 동영상, 이벤트를 게시할 수 있는 Facebook 프로필을 만들었습니다. 귀하가 저의 프로필을 볼 수 있도록 친구로 추가하고 싶습니다. 그러려면 먼저 귀하가 Facebook에 가입해야 합니다! 회원으로 가입하면 귀하도 프로필을 만들 수 있습니다. 고맙습니다! Young Tae Facebook에 가입하려면 아래 링크를 클릭하세요. http://www.facebook.com/p.php?i=100003305725765&k=AQCtufVGAiIaS35gg9kHoIHhT… 이미 계정을 갖고 계신가요? 계정에 이 이메일 주소를 추가하세요. http://www.facebook.com/n/?merge_accounts.php&e=armedbear-devel%40common-li… ======================================= 메시지가 armedbear-devel(a)common-lisp.xn--net()-7s4ut57e 전송되었습니다. 앞으로 이러한 이메일을 그만 받으려면 아래의 링크를 눌러서 수신을 거부해 주세요. http://www.facebook.com/o.php?k=a23045&u=100003558065807&mid=5989382G5af3e4… Facebook, Inc. Attention: Department 415 P.O Box 10005 Palo Alto CA 94303

1 0

[armedbear-devel] Patch that fixes ticket #187 (Stack Overflow for Worst-case Vector Sort)
by Jorge Tavares 05 Feb '12

05 Feb '12

Hi, I'm sending a patch that solves the issue reported in ticket #187. The quicksort function picks the pivot by selecting a midpoint and also sorts the smaller partition first. These are enough to avoid the stack overflow problem as reported. I've performed some tests and it looks it is correct. Below I include a sample session, including the test case in the ticket: idesk:abcl jast$ ./abcl Armed Bear Common Lisp 1.1.0-dev-svn-13848M Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.307 seconds. Startup completed in 0.945 seconds. Loading /Users/jast/.abclrc completed in 4.528 seconds. Type ":help" for a list of available commands. CL-USER(1): (ql:quickload "alexandria") To load "alexandria": Load 1 ASDF system: alexandria ; Loading "alexandria" ("alexandria") CL-USER(2): (defparameter *sorted* (make-array 1000000 :initial-contents (alexandria:iota 1000000))) *SORTED* CL-USER(3): (defparameter *numbers* (alexandria:shuffle (copy-seq *sorted*))) *NUMBERS* CL-USER(4): (equalp *sorted* *numbers*) NIL CL-USER(5): (time (progn (setf *numbers* (sort *numbers* #'<)) nil)) 2.157 seconds real time 3 cons cells NIL CL-USER(6): (equalp *sorted* *numbers*) T CL-USER(7): (let ((a (map-into (make-array 10000) (let ((x 0)) (lambda () (incf x)))))) (sort a #'<) nil) NIL CL-USER(8): (time (progn (setf *numbers* (sort *numbers* #'<)) nil)) 1.074 seconds real time 3 cons cells NIL CL-USER(9): With these changes, sort seems to be a little faster (for vectors) although I was not worried with optimizations. In ABCL 1.0.1, in my machine, sorting 1000000 random integers takes around 10s on average while now it takes 2s. However, I must point out I didn't do any serious and proper benchmarking, just some runs. I will be happy to answer any questions if necessary. Cheers, Jorge Tavares -- http://jorgetavares.com

2 2

[armedbear-devel] Java Collections, ABCL, and you
by Alessio Stalla 04 Feb '12

04 Feb '12

Hello list, I'd like to talk a bit about our Java Collections API integration, and especially a topic that has been lumbering in my mind for quite a lot of time and which has been raised today by Rudi Schlatte on #abcl. Warning: the mail turned out to be quite long. As you probably know, some time ago I added to ABCL an implementation of Christophe Rhodes' extensible sequences proposal[1], until then only implemented in SBCL (as far as I know). It's not loaded by default, but you can get it with (require :extensible-sequences). Some time later I used that API to integrate ABCL with the Java Collections framework, so that (certain) Java collections are Lisp SEQUENCEs. Again, to get it you need to (require :java-collections). However, there are, I think, two interesting limitations in the ext. seq. protocol, which I'm going to discuss. Since it was designed as an extension to CL's sequences, the protocol builds directly upon the concept of CL sequences (lists and vectors) - and in particular it assumes sequences are ordered (accessible by index) and mutable. The only basic operations one must absolutely define to provide a custom sequence implementation are ELT, (SETF ELT), and LENGTH; anything else is defined by default upon those operations, albeit inefficiently. That concept of sequences roughly matches that of Java Lists (except the fact that mutability of Lists is optional). List is a subtype of Collection which implies ordering and access by index. Collection is basically an Iterable thing with a length and optional mutability (in the form of adding elements to the end and removing elements destructively). The concept of a Collection or better an Iterable is missing from the extensible sequences protocol, although it provides an iterator sub-protocol. This makes it unsuitable for those kinds of sequences that do not fully respect CL's definition of sequence (e.g. because they are not mutable of because they can only be iterated once and not accessed by index, like a stream), but that would nevertheless benefit from adhering at least in part to the sequence protocol (because then you might LOOP or, shameless plug, DO+ over them, for example). That would also allow to expose arbitrary Java Collections, and not just Lists, as Lisp sequences - including thus Sets and various specialized Collection types. So the first point is: I'd like to extend the protocol with the concept of an Iterable. How? Ideally, Iterable would be a more basic concept than Sequence, but we cannot modify the class hierarchy of SEQUENCE because it's defined by the standard. So, either ITERABLE must be completely disjoint from SEQUENCE, or it must be a subtype of it. Of the two, I favor the latter, because many sequence operations are supposed to signal errors in case their argument is not a proper sequence, and deviating from that would probably constitute a violation of the standard. So I would define an Iterable as a special SEQUENCE that is defined in terms of an iterator; by default ELT, (SETF ELT) and LENGTH create a new iterator and, very inefficiently, use it to walk the Iterable and do their work. Of course specialized, more efficient implementations are possible. Java Collections would be Iterables, and Java Lists would retain their specialized implementation of ELT and (SETF ELT) which do not necessarily walk the list each time (depending on the type of list). The second idea is that I think it would be beneficial to explicitly state that mutability of sequences is optional. The CL standard doesn't say anything about it (or so it seems to me), although you can clearly see that in certain passages it assumes that list and vector (which are both mutable) are the only subtypes of sequence, whereas list and vector are explicitly said not to constitute an exhaustive partition of the type sequence[2]. Currently a number of sequence functions in the protocol implementation assume mutability, for example SUBSEQ by default creates a copy of the same type and sets elements one by one using an iterator. However, to eliminate the mutability requirement, at least another piece is missing: a generalization of CONS, i.e. an operation that appends a single element to the beginning of a sequence nondestructively. This is roughly what Clojure calls conj (except that conj does not specify where the element is added, which is a very awkward decision to me) and could be defined as (concatenate (class-of sequence) (list item) sequence)... if only concatenate wasn't implemented in terms of (SETF ELT) :P The possible negative sides of such a decision are: 1. it could in the end be an aspect of non-conformity to the ANSI standard (although only relevant to non-standard sequence subtypes) 2. it would make the default implementation of certain sequence operations even more inefficient for custom mutable sequences (that could be mitigated by checking for a marker mixin class MUTABLE-NONSTANDARD-SEQUENCE) 3. it would make ABCL's implementation of sequences a bit more complex. Note also that lifting mutability would NOT benefit Java collections because, inconsistently, they provide no general means to extend a collection without mutating it. What do you think? Cheers, Alessio [1] doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pd [2] http://www.lispworks.com/documentation/HyperSpec/Body/t_seq.htm

2 1

[armedbear-devel] New fasl format: steps to success
by Erik Huelsmann 04 Feb '12

04 Feb '12

After having mailed a few weeks ago about my ideas regarding a new fasl format, I'm now mailing regarding the next steps that I've come up with to implement the new scheme. But first I'd like to mention that I've come to the conclusion that our "each function is its own class" scheme can't be entirely eliminated: since we don't use invokedynamic yet, there are only two ways to create the function objects that we still require (to stick in the symbol function slot): 1. By using the reflection API to extract the XEPs (eXternal Entry Points) from the fasl class and create a single forwarder class which calls the XEP using reflection or 2. By still creating our multitude of classes which each implement a simple forwarder method which calls the fasl's XEP method I'm not sure of the performance implications of either. Maybe we need to test both schemes before we decide which one would be best. My preference is with method (1), btw, if it performs on par with method (2). So, now about the approach: I. We need to be able to have multiple argument list parsers (the equivalent of Closure.processArgs()) in a single class --> To achieve this, we need to factor out the relevant bits from Closure.java In fact, I did that over the past week: step completed. II. Our compiler should no longer specifically compile output to a class; we need to find a way for the COMPILE and COMPILE-FILE infrastructures to use the same basic compiler which compiles into a context provided by the respective callers. The trick here will be to develop a 'protocol' between the basic compiler and COMPILE/COMPILE-FILE which can be used to flatten the nested structure of compilands. III. Re-enable compilation of the content of the ._ file; we used to have that, but it didn't make a difference in start-up performance, so I disabled it again. Now, we need it to prevent having as many init_xxx() routines as we have functions. After all, at this time, we currently run a mix of ._ and initialization code by intermixing class loading and ._ file execution. IV. Develop a way to split overly big fasl classes, <clinit> (class initialization code) and <init> (constructor code) methods V. Change the base compiler to directly link to method/class combinations when instructed to do so by their caller / through some protocol. VI. COMPILE-FILE should start generating functions and XEPs -- within the current structure VII. Change the file compiler to direct its output to one or a small number of fasl classes, replacing the current output classes with either one of the two options presented earlier in the mail. Step (I) is - as mentioned - already completed. I'm envisioning steps (II) through (VI) to be done on trunk. I expect step (VII) to be associated with experimentation, which would best served by a separate branch. Comments? Ideas? Helpers? :-) Bye, Erik.

1 0