Mark Evenson | 1 Feb 2012 09:26
Picon
Favicon

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


On Jan 31, 2012, at 16:54 , Jorge Tavares wrote:

> 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).

Filed as [ticket #196][#196] with your [patch committed in r13838][r13838].

Thanks for the succinct report, test case, and quick patch!

[#196]: http://trac.common-lisp.net/armedbear/ticket/196
[r13838]: http://trac.common-lisp.net/armedbear/changeset/13838
Mark Evenson | 1 Feb 2012 09:28
Picon
Favicon

[armedbear-devel] Fwd: Bugs(?) in pathnames

[Forwarding message for errors with Pathnames that didn't seem to make it to the list]

Begin forwarded message:

> From: Mark Evenson <evenson <at> panix.com>
> Subject: Re: [armedbear-devel] Bugs(?) in pathnames
> Date: January 28, 2012 14:33:41 GMT+01:00
> To: Theam Yong Chew <senatorzergling <at> gmail.com>
> Cc: armedbear-devel <armedbear-devel <at> common-lisp.net>
> 
> 
> On Jan 27, 2012, at 12:46 PM, Theam Yong Chew wrote:
> 
>> 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.
> 
> We probably expect the serialized form to be in canonical form
> ("file:///C:/a/b.jar").   We can loosen this a bit.  Wrap a local
> handler on the execution:  the full Common Lisp condition system
> should be available.
> 
>> 
>> Why am I not getting any errors (and not dropping into a debugger)? I
(Continue reading)

Mark Evenson | 1 Feb 2012 09:33
Picon
Favicon

Re: [armedbear-devel] Bugs(?) in pathnames


On Jan 28, 2012, at 14:33 , Mark Evenson wrote:

> 
> On Jan 27, 2012, at 12:46 PM, Theam Yong Chew wrote:
> 
>> Hi devs,
>> 
>> I've observed a few issues (some I'm not so sure about) with pathnames:

Filed your report under [ticket #197][#197]:

[#197]: http://trac.common-lisp.net/armedbear/ticket/197
Jorge Tavares | 1 Feb 2012 10:54
Picon
Gravatar

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

On Wednesday, February 1, 2012 at 09:26 , Mark Evenson wrote:
> 
> On Jan 31, 2012, at 16:54 , Jorge Tavares wrote:
> 
> > 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).
> 
> 
> Filed as [ticket #196][#196] with your [patch committed in r13838][r13838].
> 
> Thanks for the succinct report, test case, and quick patch!
> 
> [#196]: http://trac.common-lisp.net/armedbear/ticket/196
> [r13838]: http://trac.common-lisp.net/armedbear/changeset/13838

Thanks! It's only a quick fix. I will see if I can prepare a better solution for the long term.

Cheers,
Jorge Tavares

--

-- 
http://jorgetavares.com
Ville Voutilainen | 1 Feb 2012 14:43
Picon

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.
Mark Evenson | 1 Feb 2012 15:07
Picon
Favicon

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


On Feb 1, 2012, at 14:43 , Ville Voutilainen wrote:

> 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.

Unfortunately, "where.exe" was only shipped starting with Windows
2003 Server, so it doesn't exist on the stock Windows XP installation
that is presumably still the Armed Bear MSFT lowest common denominator.

But thanks for the link, as I couldn't easily find such an authoritative
answer in my searching.

--
"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."
Mark Evenson | 3 Feb 2012 14:57
Picon
Favicon

[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."
Alessio Stalla | 3 Feb 2012 22:54
Picon

[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
(Continue reading)

Jorge Tavares | 4 Feb 2012 11:57
Picon
Gravatar

[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
(Continue reading)

Erik Huelsmann | 4 Feb 2012 15:48
Picon
Gravatar

[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.

Gmane