[armedbear-devel] 김영태님이 Abcl님을 Facebook으로 초대하셨습니다

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

[armedbear-devel] New fasl format: steps to success

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.

[armedbear-devel] HEADS UP: recent changes require full build

Some of the changes I committed yesterday and today change the ABI of
the org.armedbear.lisp.Closure class. Due to this change, a full build
is required.

Bye,

Erik.

[armedbear-devel] Patch that fixes ticket #187 (Stack Overflow for Worst-case Vector Sort)

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

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

[armedbear-devel] Java Collections, ABCL, and you

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

[armedbear-devel] Upcoming abcl-1.1 branch

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=5c7faeeb354081d9f32859557f4b13ab6d695589

yers in CONS,
Mark

--
"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."

Re: [armedbear-devel] [armedbear-cvs] r13841 - trunk/abcl/contrib/abcl-asdf

On 1 February 2012 15:25,  <mevenson <at> common-lisp.net> wrote:
>                (truename (read-line (sys::process-output
> -                                     (sys::run-program "which" `(,mvn-path)))))
> +                                     (sys::run-program "which" `(,mvn-path))))) ;; TODO
equivalent for MSDOS

See http://stackoverflow.com/questions/304319/is-there-an-equivalent-of-which-on-windows,
where.exe does it on windows, where /? gives help for it, and for example

C:\Users\vilvouti>where notepad.exe
C:\Windows\System32\notepad.exe
C:\Windows\notepad.exe

So just run 'where' for it and pick the first line if successful, I guess.

[armedbear-devel] bug report: stable-sort is only stable for lists

Dear ABCL developers, 

Recently I started to investigate the different CL sort implementations and found that stable-sort in
ABCL does not execute as required. The problem is that stable-sort is only stable for lists and not for all
type of sequences (i.e., elements considered equal by the predicate should stay in their original order).

A very simple test shows this error:

idesk:~ jast$ abcl
Armed Bear Common Lisp 1.0.1
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.399 seconds.
Startup completed in 1.069 seconds.
Loading /Users/jast/.abclrc completed in 4.8 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (defparameter *stuff* #((1 0.31648433) (0 0.2704757) (0 0.48931926) (1 0.9958766) (0 0.49251676)))
*STUFF*
CL-USER(2): (setf *stuff* (stable-sort *stuff* #'< :key #'first))
#((0 0.49251676) (0 0.2704757) (0 0.48931926) (1 0.31648433) (1 0.9958766))

The above test is short and simple to understand: *stuff* contains an array where each element is a pair. The
first element of a pair is the key and the second the data. With this in mind, the expected result should have
been: #((0 0.2704757) (0 0.48931926) (0 0.49251676) (1 0.31648433) (1 0.9958766)). 

The same error happens with larger arrays and other types of data. I also tested it in SBCL, CCL, ECL and CLisp
and for these implementations the results are the expected. Only ABCL differs form the major open source
implementations (I didn't test in ACL or LW).

The reason for this bug is actually quite simple. In sort.lisp, in the definition of stable-sort,
seq-dispatch calls for the non-list sequences the quicksort algorithm, which is not stable. For lists it
calls merge sort (which is stable) and the problem does not arise. 

As a quick fix, I send in attach a patch that uses in stable-sort merge sort for all sequences. This is done by
coercing the sequence to list, calling merge sort and coercing it back to the original sequence type.
However, as a long term improvement, the best solution would be to implement a merge sort for non-list sequences.

Cheers,
Jorge Tavares

--

-- 
http://jorgetavares.com

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

[armedbear-devel] Bugs(?) in pathnames

Hi devs,

I've observed a few issues (some I'm not so sure about) with pathnames:

1.

CL-USER> (make-pathname :device '("c:/a.b.jar")
               :directory '(:absolute "cl-ppcre"))
; Evaluation aborted on NIL.

Why am I not getting any errors (and not dropping into a debugger)? I
know the error is because the device is not a list of a pathname ie
missing a #P.

2. What's printed out is not what was read in (trailing /)

CL-USER> #P"jar:file:c:/a/b.jar!/cl-ppcre/"
#P"jar:file:c:/a/b.jar!/cl-ppcre"

3. Should this repeated jar:file:jar:file thing throw an error?

#P"jar:file:jar:file:c:/a/b.jar!/cl-ppcre/"
==> #P"jar:file:jar:file:c:/a/b.jar!/cl-ppcre"

I think that was all I found, at least for now , thanks.

Yong.

[armedbear-devel] Correct README to indicate that JSS 3 has a namespace [ on 2012-01-27 10:11 GMT]

Corrected documentation to indicate that JSS:NEW needs to be explicitly imported, or if you wish to
pollute the namespace , then invoke JSS:ENSURE-COMPATIBILITY to import JSS symbols into CL-USER.

Begin forwarded message:

> From: abcl-dynamic-install <at> googlecode.com
> Subject: [abcl-dynamic-install] push by evenson....@gmail.com - Correct README to indicate that JSS 3
has a namespace. on 2012-01-27 10:11 GMT
> Date: January 27, 2012 11:11:44 AM GMT+01:00
> To: evenson.not.org <at> gmail.com
> 
> Revision: 06d8a71be52d
> Author:   mevenson <at> 1c010e3e-69d0-11dd-93a8-456734b0d56f
> Date:     Fri Jan 27 02:10:22 2012
> Log:      Correct README to indicate that JSS 3 has a namespace.
> http://code.google.com/p/abcl-dynamic-install/source/detail?r=06d8a71be52d
> 
> Modified:
> /contrib/jss/README.markdown
> 
> =======================================
> --- /contrib/jss/README.markdown	Mon Jul 11 06:57:21 2011
> +++ /contrib/jss/README.markdown	Fri Jan 27 02:10:22 2012
> @@ -17,8 +17,11 @@
> 
> Java methods look like this: #"toString". Java classes are represented
> as symbols, which are resolved to the appropriate java class
> -name. When ambiguous, you need to be more specific. A simple example:
> -
> +name. When ambiguous, you need to be more specific. A simple example
> +from CL-USER:
> +
> +    (require 'jss)
> +    (jss:ensure-compatibility
>     (let ((sw (new 'StringWriter)))
>        (#"write" sw "Hello ")
>        (#"write" sw "World")
> @@ -94,7 +97,6 @@
> 
> (jcmn class-name) lists the names of all methods for the class
> 
> -
> Compatibility
> -------------
> 
> @@ -109,3 +111,24 @@
>    Since we are no longer using Beanshell, this is no longer present.
>    For obtaining the current classloader use JAVA:*CLASSLOADER*.
> 
> +# API
> +
> +  1.0
> +    Equivalent to Alan Ruttenberg's version included with the original
> +    [lsw]().
> +
> +[lsw]: http://mumble.net:8080/svn/lsw/trunk/
> +[lsw2]: let-me-google-that-for-you
> +
> +
> +  3.0
> +     In the JSS package loaded from [abcl-contrib]()
> +
> +abcl-contrib: http://svn.common-lisp.net/armedbear/trunk/abcl/contrib/
> +
> +# Colophon
> +
> +<> dc:created "2005" ;
> +   dc:author "Mark <evenson.not.org <at> gmail.com>";
> +   revised: "27-JAN-2012" .
> +

[armedbear-devel] jss issues

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel