headers
Alan Ruttenberg | 3 Feb 2011 05:33
Picon
Gravatar

Re: [armedbear-devel] (defstruct (teststruct (:type list) :named) testslot)))

Verified. Thanks!
-Alan

On Thu, Jan 27, 2011 at 5:37 PM, Erik Huelsmann <ehuels <at> gmail.com> wrote:
> Hi Alan,
>
> On Sat, Dec 25, 2010 at 8:31 AM, Alan Ruttenberg
> <alanruttenberg <at> gmail.com> wrote:
>> (defstruct (teststruct (:type list) :named) testslot)))
>>
>> causes the following defun to be compiled:
>>
>> (DEFUN NIL (SYSTEM::INSTANCE) (ELT SYSTEM::INSTANCE 0))
>>
>> That shouldn't be. Particularly if (fdefinition nil) gives an error.
>
> Sorry to come back to your report just now. Yes, this is a bug. I've
> fixed it and committed the change. Could you confirm that your issue
> is fixed on current trunk?
>
> Thanks in advance!
>
>
> Bye,
>
> Erik.
>
Permalink | Reply | 0 comments |
headers
Alan Ruttenberg | 3 Feb 2011 08:45
Picon
Gravatar

[armedbear-devel] (quit) in slime doesn't

CL-USER> (quit)
; Evaluation aborted on NIL.
Permalink | Reply | 0 comments |
headers
Mark Evenson | 3 Feb 2011 12:05
Picon
Favicon

Re: [armedbear-devel] (quit) in slime doesn't

On 2/3/11 8:45 AM, Alan Ruttenberg wrote:
> CL-USER>  (quit)
> ; Evaluation aborted on NIL.
>

Filed as [ticket #127][1] so I won't forget to follow up, as I 
unfortunately don't have the time to do the proper analysis right now. 
This bug was likely introduced by the new ProcessingTerminated exception 
mechanism introduced to remove all calls to the OS exit() function.

[1]: http://trac.common-lisp.net/armedbear/ticket/127

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Alessio Stalla | 4 Feb 2011 11:37
Picon

[armedbear-devel] Maven & ABCL

Hello folks,

I'm in the process of integrating Dynaspring [1] in a
yet-to-be-released open source utilities project developed together
with some (ex-)colleagues. The utilities project is built with Maven,
so in order to use Dynaspring (and transitively ABCL) I had to write a
simple pom.xml (Maven project descriptor) for ABCL to make it known to
Maven (i.e. usable as a dependency in Maven projects). For the other
developers' convenience, it would be nice if the poms were available
from a publicly accessible Maven repository (Sonatype provides a free
one, [2]). I'm going to create one there for Dynaspring, but if you're
ok with it, I can create a separate one for ABCL, and from now on,
publish ABCL releases there as well. What do you think?

Bye,
Alessio

[1] http://code.google.com/p/dynaspring/
[2] https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 4 Feb 2011 12:03
Picon
Gravatar

Re: [armedbear-devel] Maven & ABCL

Hi Alessio,

> I'm in the process of integrating Dynaspring [1] in a
> yet-to-be-released open source utilities project developed together
> with some (ex-)colleagues. The utilities project is built with Maven,
> so in order to use Dynaspring (and transitively ABCL) I had to write a
> simple pom.xml (Maven project descriptor) for ABCL to make it known to
> Maven (i.e. usable as a dependency in Maven projects). For the other
> developers' convenience, it would be nice if the poms were available
> from a publicly accessible Maven repository (Sonatype provides a free
> one, [2]). I'm going to create one there for Dynaspring, but if you're
> ok with it, I can create a separate one for ABCL, and from now on,
> publish ABCL releases there as well. What do you think?

I'm not very familiar wit Maven and its repositories, so I have some
additional questions:

 * Is a maven-user restricted to a single maven repository per
project? In other words, do all dependencies have to be in a single
repository, or can dependencies be downloaded from different
repositories?
 * You choose for this specific Maven repository. Is there a specific
reason? Are they the best (and by which definition of best)? Are they
the most well known?
 * Can the steps for publishing to the repository be built into the
release process? Will it make our release process much heavier, or is
uploading a purely technical step a computer can do with a human just
supervising correct completion of the action? (In the latter case, we
could just script the uploads to our website and the maven repository
and wait a little more than before...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alessio Stalla | 4 Feb 2011 12:48
Picon

Re: [armedbear-devel] Maven & ABCL

On Fri, Feb 4, 2011 at 12:03 PM, Erik Huelsmann <ehuels <at> gmail.com> wrote:
> Hi Alessio,
>
>> I'm in the process of integrating Dynaspring [1] in a
>> yet-to-be-released open source utilities project developed together
>> with some (ex-)colleagues. The utilities project is built with Maven,
>> so in order to use Dynaspring (and transitively ABCL) I had to write a
>> simple pom.xml (Maven project descriptor) for ABCL to make it known to
>> Maven (i.e. usable as a dependency in Maven projects). For the other
>> developers' convenience, it would be nice if the poms were available
>> from a publicly accessible Maven repository (Sonatype provides a free
>> one, [2]). I'm going to create one there for Dynaspring, but if you're
>> ok with it, I can create a separate one for ABCL, and from now on,
>> publish ABCL releases there as well. What do you think?
>
> I'm not very familiar wit Maven and its repositories, so I have some
> additional questions:

I'm not very familiar either, but I'll do my best ;)

>  * Is a maven-user restricted to a single maven repository per
> project? In other words, do all dependencies have to be in a single
> repository, or can dependencies be downloaded from different
> repositories?

They can be in different repositories; the repositories to use can be
written in the project POM - but that is generally discouraged [1] -
or in a local settings file.

>  * You choose for this specific Maven repository. Is there a specific
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alessio Stalla | 6 Feb 2011 23:48
Picon
Subject: [armedbear-devel] compiler-pass2, dump-form and the dreaded 64k constant string size limit

[armedbear-devel] compiler-pass2, dump-form and the dreaded 64k constant string size limit

I found another limitation caused by the class file format: constant
strings are limited to a size of 64k bytes. The compiler uses
dump-form to externalize objects to FASLs, and this means that not
only literal strings are limited to 64k, but every object that is
dumped is limited by its printed representation. I found that out
while trying to compile closure-html [1], which creates a big vector
to hold generated parser states and stores it as a constant in the
code [2]. So we need to split big dumped forms over multiple strings.
I'll attempt a solution in the following days.

Bye,
Alessio

[1] http://common-lisp.net/project/closure/closure-html
[2] Incidentally, I also found out that dump-vector causes a stack
overflow error for such a vector (probably because it contains other
vectors that form circular references). What's the reason for
dump-vector not to use the normal vector printing code?
Permalink | Reply | 0 comments |
headers
Theam Yong Chew | 7 Feb 2011 12:39
Picon

[armedbear-devel] Cannot RENAME-FILE to a file without extensions

Dear developers of ABCL,

I found a problem recently in both ABCL 0.21.0 and 0.24.0,
where I could not rename a file to any file without an
extension. For example, with an existing file /tmp/a.txt,

CL-USER> (rename-file "/tmp/a.txt" "/tmp/a")
#P"/tmp/a.txt"
#P"/tmp/a.txt"
#P"/tmp/a.txt"

The file does not change at all. With any extension,
everything works as expected.

Thanks in advance.

Yong.
Permalink | Reply | 0 comments |
headers
Zach Beane | 7 Feb 2011 12:55
Gravatar

Re: [armedbear-devel] Cannot RENAME-FILE to a file without extensions

Theam Yong Chew <senatorzergling <at> gmail.com> writes:

> Dear developers of ABCL,
>
> I found a problem recently in both ABCL 0.21.0 and 0.24.0,
> where I could not rename a file to any file without an
> extension. For example, with an existing file /tmp/a.txt,
>
> CL-USER> (rename-file "/tmp/a.txt" "/tmp/a")
> #P"/tmp/a.txt"
> #P"/tmp/a.txt"
> #P"/tmp/a.txt"
>
> The file does not change at all. With any extension,
> everything works as expected.
>
> Thanks in advance.

That is how RENAME-FILE is specified in Common Lisp. See
http://l1sp.org/cl/rename-file and in particular the part regarding
merge-pathnames.

Zach
Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 8 Feb 2011 22:35
Picon
Gravatar

Re: [armedbear-devel] [armedbear-cvs] r13209 - trunk/abcl/src/org/armedbear/lisp

This fixes the regression I introduced a few days ago.

Bye,

Erik.

On Tue, Feb 8, 2011 at 10:46 PM, Erik Huelsmann
<ehuelsmann <at> common-lisp.net> wrote:
> Author: ehuelsmann
> Date: Tue Feb  8 16:46:47 2011
> New Revision: 13209
>
> Log:
> Add documentation to STD-SHARED-INITIALIZE and
> add initarg checking to REINITIALIZE-INSTANCE.
>
> Modified:
>   trunk/abcl/src/org/armedbear/lisp/clos.lisp
>
> Modified: trunk/abcl/src/org/armedbear/lisp/clos.lisp
> ==============================================================================
> --- trunk/abcl/src/org/armedbear/lisp/clos.lisp (original)
> +++ trunk/abcl/src/org/armedbear/lisp/clos.lisp Tue Feb  8 16:46:47 2011
>  <at>  <at>  -2650,18 +2650,23  <at>  <at> 
>  ;; slots should be initialized according to their initforms), and the initargs
>  ;; it received."
>  (defmethod reinitialize-instance ((instance standard-object) &rest initargs)
> +  (check-initargs (list #'reinitialize-instance) (list* instance initargs)
> +                  instance () initargs)
>   (apply #'shared-initialize instance () initargs))
(Continue reading)

Permalink | Reply | 0 comments |

Gmane