gmane.editors.j.devel

ArmedBear status with ANSI tests

Well, it looks like 3 conformance tests have been fixed since the last
update of the ABCL webpages on armedbear.org:

we're now at 64 failures only. This is the output:

64 out of 21702 total tests failed: LAMBDA.54, SYMBOL-MACROLET.ERROR.1,
   PSETQ.7, PSETF.7, DEFINE-SETF-EXPANDER.1, DEFINE-SETF-EXPANDER.6,
   DEFINE-SETF-EXPANDER.7, DEFUN.5, FLET.64, FLET.67, LABELS.43,
   LABELS.46, LABELS.47, MULTIPLE-VALUE-SETQ.5, MULTIPLE-VALUE-SETQ.8,
   REINITIALIZE-INSTANCE.ERROR.1, SHARED-INITIALIZE.ERROR.4,
   CHANGE-CLASS.1.11, CHANGE-CLASS.ERROR.4, MAKE-INSTANCE.ERROR.3,
   MAKE-INSTANCE.ERROR.4, DEFGENERIC.ERROR.20, DEFGENERIC.ERROR.21,
   DEFGENERIC.30, CALL-NEXT-METHOD.ERROR.1, CALL-NEXT-METHOD.ERROR.2,
   DEFMETHOD.ERROR.14, DEFMETHOD.ERROR.15, HANDLER-CASE.29,
   RESTART-CASE.29, RESTART-CASE.30, RESTART-CASE.31, RESTART-CASE.36,
   MAKE-CONDITION.3, MAKE-CONDITION.4, PUSH.5, POP.3, PUSHNEW.21,
   DELETE-PACKAGE.5, DELETE-PACKAGE.6, DO-ALL-SYMBOLS.6,
   DO-ALL-SYMBOLS.9, DO-ALL-SYMBOLS.12, IMPORT.ERROR.4, IMPORT.ERROR.5,
   MAP.48, MAP.SPECIALIZED-STRING.3, TYPE-OF.1, WITH-OUTPUT-TO-STRING.8,
   PRINT.RANDOM-STATE.1, PPRINT-FILL.14, PPRINT-FILL.15,
   PPRINT-LINEAR.14, PPRINT-TABULAR.13, PPRINT-LOGICAL-BLOCK.17,
   PPRINT-POP.7, PPRINT-POP.8, FORMAT.C.4A, FORMATTER.C.4A,
   FORMAT.LOGICAL-BLOCK.CIRCLE.1, FORMAT.LOGICAL-BLOCK.CIRCLE.2,
   FORMAT.LOGICAL-BLOCK.CIRCLE.3, COMPILE-FILE.17, COMPILE-FILE.18.
691.62 seconds real time
20145221 cons cells

And, ofcourse, any help on trying to fix them will be welcome!

Bye,

(Continue reading)

headers

Erik Huelsmann | 31 Aug 03:08

Re: ArmedBear status with ANSI tests

On Thu, Aug 14, 2008 at 4:12 PM, Erik Huelsmann <ehuels <at> gmail.com> wrote:
> Well, it looks like 3 conformance tests have been fixed since the last
> update of the ABCL webpages on armedbear.org:
>
> we're now at 64 failures only. This is the output:

Well, as of today, we're at only 62 failing tests - unfortunately,
only 60 are the same, meaning the resolution of 4 failures created 3
new failures. I still committed, because as per the approach put
forward: it's still monotonically decreasing (and I'm not really sure
they were passing for the right reasons before).

This is the output:

62 out of 21702 total tests failed: LAMBDA.54, SYMBOL-MACROLET.ERROR.1,
   PSETQ.7, PSETF.7, DEFINE-SETF-EXPANDER.1, DEFINE-SETF-EXPANDER.6,
   DEFINE-SETF-EXPANDER.7, DEFUN.5, FLET.64, FLET.67, LABELS.43,
   LABELS.46, LABELS.47, MULTIPLE-VALUE-SETQ.5, MULTIPLE-VALUE-SETQ.8,
   REINITIALIZE-INSTANCE.ERROR.1, SHARED-INITIALIZE.ERROR.4,
   DEFGENERIC.ERROR.20, DEFGENERIC.ERROR.21, DEFGENERIC.30,
   CALL-NEXT-METHOD.ERROR.1, CALL-NEXT-METHOD.ERROR.2,
   DEFMETHOD.ERROR.14, DEFMETHOD.ERROR.15, HANDLER-CASE.29,
   RESTART-CASE.29, RESTART-CASE.30, RESTART-CASE.31, RESTART-CASE.36,
   MAKE-CONDITION.3, MAKE-CONDITION.4, PUSH.5, POP.3, PUSHNEW.21,
   DELETE-PACKAGE.5, DELETE-PACKAGE.6, DEFPACKAGE.24, DEFPACKAGE.25,
   DO-ALL-SYMBOLS.6, DO-ALL-SYMBOLS.9, DO-ALL-SYMBOLS.12,
   IMPORT.ERROR.4, IMPORT.ERROR.5, MAP.48, MAP.SPECIALIZED-STRING.3,
   TYPE-OF.1, WITH-OUTPUT-TO-STRING.8, PRINT.RANDOM-STATE.1,
   PPRINT-FILL.14, PPRINT-FILL.15, PPRINT-LINEAR.14, PPRINT-TABULAR.13,
   PPRINT-LOGICAL-BLOCK.17, PPRINT-POP.7, PPRINT-POP.8, FORMAT.C.4A,

(Continue reading)

headers

Erik Huelsmann | 31 Aug 22:30

Re: ArmedBear status with ANSI tests

On Sun, Aug 31, 2008 at 3:08 AM, Erik Huelsmann <ehuels <at> gmail.com> wrote:
> On Thu, Aug 14, 2008 at 4:12 PM, Erik Huelsmann <ehuels <at> gmail.com> wrote:
>> Well, it looks like 3 conformance tests have been fixed since the last
>> update of the ABCL webpages on armedbear.org:
>>
>> we're now at 64 failures only. This is the output:
>
> Well, as of today, we're at only 62 failing tests - unfortunately,
> only 60 are the same, meaning the resolution of 4 failures created 3
> new failures. I still committed, because as per the approach put
> forward: it's still monotonically decreasing (and I'm not really sure
> they were passing for the right reasons before).
>
> This is the output:
>
> 62 out of 21702 total tests failed

And again we're doing better: only 58 failing tests now.

58 out of 21702 total tests failed: LAMBDA.54, SYMBOL-MACROLET.ERROR.1,
   PSETQ.7, PSETF.7, DEFINE-SETF-EXPANDER.1, DEFINE-SETF-EXPANDER.6,
   DEFINE-SETF-EXPANDER.7, DEFUN.5, FLET.64, FLET.67, LABELS.43,
   LABELS.46, LABELS.47, MULTIPLE-VALUE-SETQ.5, MULTIPLE-VALUE-SETQ.8,
   REINITIALIZE-INSTANCE.ERROR.1, SHARED-INITIALIZE.ERROR.4,
   DEFGENERIC.ERROR.20, DEFGENERIC.ERROR.21, DEFGENERIC.30,
   CALL-NEXT-METHOD.ERROR.1, CALL-NEXT-METHOD.ERROR.2,
   DEFMETHOD.ERROR.14, DEFMETHOD.ERROR.15, HANDLER-CASE.29,
   RESTART-CASE.29, RESTART-CASE.30, RESTART-CASE.31, RESTART-CASE.36,
   MAKE-CONDITION.3, MAKE-CONDITION.4, PUSH.5, POP.3, PUSHNEW.21,
   DELETE-PACKAGE.5, DELETE-PACKAGE.6, DO-ALL-SYMBOLS.6,

(Continue reading)

headers

Mark Evenson | 1 Sep 18:05

[0.0.10.20] IMPORT of NIL broken

Erik Huelsmann wrote:
[…]
>>
>> 62 out of 21702 total tests failed
> 
> And again we're doing better: only 58 failing tests now.

Somewhere in fixing the package stuff, you broke the following (which 
occurs in SLIME's "swank.lisp"):

(let ((package (make-package :swank-io-package :use '())))
     (import '(nil t quote) package))

After this is eval'd SWANK-IO-PACKAGE should have three symbols, but the 
NIL doesn't show up in the package under 0.0.10.20.  This was working in 
0.0.10.19.

Back to trying to decipher why your changes broke this,

Mark

--

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

(Continue reading)

headers

Erik Huelsmann | 1 Sep 21:53

Re: [0.0.10.20] IMPORT of NIL broken

On Mon, Sep 1, 2008 at 6:05 PM, Mark Evenson <evenson <at> panix.com> wrote:
> Erik Huelsmann wrote:
> […]
>>>
>>> 62 out of 21702 total tests failed
>>
>> And again we're doing better: only 58 failing tests now.
>
> Somewhere in fixing the package stuff, you broke the following (which occurs
> in SLIME's "swank.lisp"):
>
> (let ((package (make-package :swank-io-package :use '())))
>    (import '(nil t quote) package))
>
> After this is eval'd SWANK-IO-PACKAGE should have three symbols, but the NIL
> doesn't show up in the package under 0.0.10.20.  This was working in
> 0.0.10.19.
>
> Back to trying to decipher why your changes broke this,

I already know. NIL is LISTP, however, it's also SYMBOLP, so, the
LISTP tests are not correct. I'll commit the correct code (which was
already in %IMPORT, btw) in a few minutes.

Bye,

Erik.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes

(Continue reading)

headers

Ville Voutilainen | 3 Sep 09:31

Re: ArmedBear status with ANSI tests

> And again we're doing better: only 58 failing tests now.

Is there any progress with the "long version of
define-method-combination"? Last time I checked, the gcl ansi
tests did not run all out-of-the-box because of this problem. Erik,
how do you run the tests? Now that my
patch queue is empty, I could start looking at the remaining failing
tests and see if I can patch some of
the problems.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Erik Huelsmann | 3 Sep 10:01

Re: ArmedBear status with ANSI tests

On 9/3/08, Ville Voutilainen <ville.voutilainen <at> gmail.com> wrote:
> > And again we're doing better: only 58 failing tests now.
>
> Is there any progress with the "long version of
> define-method-combination"? Last time I checked, the gcl ansi
> tests did not run all out-of-the-box because of this problem. Erik,
> how do you run the tests? Now that my
> patch queue is empty, I could start looking at the remaining failing
> tests and see if I can patch some of
> the problems.

You cought me there 

In one of the files which is loaded pre-tests, there's a randomizer
for define-method-combination. I disable the randomizer with
#-armedbear.

It would be great if the first thing to be implemented would be the
long form of define-method-combination. I think this is a
non-trivial-task however.

Bye,

Erik.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

(Continue reading)

headers

Ville Voutilainen | 6 Sep 20:42

Re: ArmedBear status with ANSI tests

>> tests did not run all out-of-the-box because of this problem. Erik,
>> how do you run the tests? Now that my
> In one of the files which is loaded pre-tests, there's a randomizer
> for define-method-combination. I disable the randomizer with
> #-armedbear.

For other mere mortals, this file is random-aux.lsp. So add the directive
mentioned by Erik, so that

(define-method-combination randomized nil ((method-list
positive-integer-qualifier-p))

becomes

#-armedbear
(define-method-combination randomized nil ((method-list
positive-integer-qualifier-p))

after this the tests run.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Ville Voutilainen | 7 Sep 20:09

Re: ArmedBear status with ANSI tests

Erik, it looks like the remaining defun/flet/labels test failures are because
of special variables not working. Can you point me where to start looking
in order to fix them?

-VJV-

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Erik Huelsmann | 7 Sep 20:47

Re: ArmedBear status with ANSI tests

On Sun, Sep 7, 2008 at 8:09 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> wrote:
> Erik, it looks like the remaining defun/flet/labels test failures are because
> of special variables not working. Can you point me where to start looking
> in order to fix them?

I was looking at Closure.java myself. If I look at lambda.54, I think
the issue is that the special (x) is becoming special before the &aux
initializations are evaluated. However, when I created the attached
patch, which declares variables special right before they are bound -
and free specials after the full lambda list has been bound. (The free
specials are declared in 'declareOtherSpecials'.)

Even though this looks more correct than what's there now, it doesn't
seem to work, as more tests start failing with it.

I haven't found the part of ABCL where let/let* bindings are processed though.

One of the problems I'm experiencing is that the error printed by
lambda.54 isn't pretty-printed (with human-readable text), but #<ERROR
@xAB124DE>-like instead.

However, everything I fixed until now, I fixed by analysing code or
printf-debugging. It seems this one is a bit too complex to fix that
way. Does anybody have a good setup for debugging the ABCL java side?

Bye,

Erik.

(Continue reading)

headers

Ville Voutilainen | 7 Sep 23:45

Re: ArmedBear status with ANSI tests

> I was looking at Closure.java myself. If I look at lambda.54, I think

Looks interesting. Am I correct if I assume that the no-parameter
execute is a closure with no parameters, and then the 1-parameter to
8-parameter ones are for closures with 1-8 parameters?

There are immediately visible differences in special handling in the
zero param execute and others. (ho humm, I don't see why a zero-param
closure could not have special varibles..)

Another very noticeable thing is that the 1-8 parameter versions contain
a boatload of copy-paste code.

Would you accept a cleanup patch for the copy-paste code in
Closure.java? I find it hard to believe that the current code is very
maintainable as it is. It looks like this kind of copy-paste code is
present in other parts of abcl too, so maybe we could start
the cleanup somewhere, Closure.java being as good a candidate
as any.  I don't yet know how much of the copy-paste can actually
be cleaned up, but I suppose that at least some of it can be, even
in java code. The current code looks unwieldy.

-VJV-

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

(Continue reading)

headers

Erik Huelsmann | 8 Sep 00:03

Re: ArmedBear status with ANSI tests

On Sun, Sep 7, 2008 at 11:45 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> wrote:
>> I was looking at Closure.java myself. If I look at lambda.54, I think
>
> Looks interesting. Am I correct if I assume that the no-parameter
> execute is a closure with no parameters, and then the 1-parameter to
> 8-parameter ones are for closures with 1-8 parameters?
>
> There are immediately visible differences in special handling in the
> zero param execute and others. (ho humm, I don't see why a zero-param
> closure could not have special varibles..)

> Another very noticeable thing is that the 1-8 parameter versions contain
> a boatload of copy-paste code.

Right. This happens all over ABCL. My feeling is that this produces a
*lot* of additional code, possibly even a lot of additional calls.
However, I have no idea what the speed benefit is (if there is any).

In general though, my feeling is that a lot more (than currently done)
can be implemented in Lisp. That would be my preference: having a
small java-side footprint and a (larger) Lisp system. The lisp system
could bootstrap itself that way, so to say.

> Would you accept a cleanup patch for the copy-paste code in
> Closure.java? I find it hard to believe that the current code is very
> maintainable as it is. It looks like this kind of copy-paste code is
> present in other parts of abcl too, so maybe we could start
> the cleanup somewhere, Closure.java being as good a candidate
> as any.  I don't yet know how much of the copy-paste can actually

(Continue reading)

headers

Mark Evenson | 8 Sep 14:23

Re: ArmedBear status with ANSI tests

Erik Huelsmann wrote:
> On Sun, Sep 7, 2008 at 11:45 PM, Ville Voutilainen
> <ville.voutilainen <at> gmail.com> wrote:
>>> I was looking at Closure.java myself. If I look at lambda.54, I think
>> Looks interesting. Am I correct if I assume that the no-parameter
>> execute is a closure with no parameters, and then the 1-parameter to
>> 8-parameter ones are for closures with 1-8 parameters?
>>
>> There are immediately visible differences in special handling in the
>> zero param execute and others. (ho humm, I don't see why a zero-param
>> closure could not have special varibles..)
> 
>> Another very noticeable thing is that the 1-8 parameter versions contain
>> a boatload of copy-paste code.
> 
> Right. This happens all over ABCL. My feeling is that this produces a
> *lot* of additional code, possibly even a lot of additional calls.
> However, I have no idea what the speed benefit is (if there is any).

Naively, I would say that there will be little run time speedup, but the 
codebase will get more maintainable by refactoring.

[…]

--

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

(Continue reading)

headers

Ville Voutilainen | 8 Sep 17:19

Re: ArmedBear status with ANSI tests

On Mon, Sep 8, 2008 at 3:23 PM, Mark Evenson <evenson <at> panix.com> wrote:
> Naively, I would say that there will be little run time speedup, but the
> codebase will get more maintainable by refactoring.

Well, Ville's first axiom of software development is as follows:

(1) performance issues shall not be discussed unless profiling data is
available

Other axioms will be presented if necessary. :)

Now, let's enter the pragmatic world and forget that axiom for the moment. :D

If we can create private static final helper functions, the java compiler will
be able to inline the calls - this is a no-cost/no-gain compared to current
code. Therefore the maintainability increase makes it worth it.

Speculatively, if the compiler is smart enough to put the common code block(s)
into one place only, we gain the following:

- there's less bytecode, which means the code
       - loads faster
       - consumes less memory
       - JITs faster
       - runs faster (due to smaller cache footprint)

I'll try to setup a debugging environment for abcl, I'm most likely going to try
eclipse first. I suppose there are some sort of free-software profiling tools
for java, so those are on the todo-list right after getting the
debugging environment

(Continue reading)

headers

Mark Evenson | 8 Sep 20:12

Re: ArmedBear status with ANSI tests

Ville Voutilainen wrote:
[…]
> I'll try to setup a debugging environment for abcl, I'm most likely going to try
> eclipse first.

For NetBeans 6.1, you should be able to follow the instructions from 
[abcld README.netbeans][1] to get an ABCL build running.   I have to 
test this again, but it was working six months ago.  On the right 
platform, the Sun tools like JFluid and the native dtrace hooks make 
performance geeks happy like pigs in slop…

[1]: 
http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/README.netbeans

  I suppose there are some sort of free-software profiling tools
> for java, so those are on the todo-list right after getting the
> debugging environment
> up and running. Then we can safely do the refactorings because we can
> have actual measurement on the impact of whatever changes we make.
> The gcl ansi tests ensure that we don't do catastrophic mistakes in the
> compatibility department, and actually debugging the code also gives
> us some confidence that the changes are correct.

"In perfect harmony."

Regards,
Mark

--

-- 
"A screaming comes across the sky.  It has happened before, but there is

(Continue reading)

headers

Mark Evenson | 9 Sep 14:49

UPDATE: Profiling/Debugging ABCL with Netbenas (was Re: ArmedBear status with ANSI tests)

I did some checking over my NetBeans integration code, making some 
improvements ending in SVN revision [70].

The neat trick here is that we have a single 'build.xml' that subsumes 
the old build system (relocated to 'abcl-build.xml') with integration to 
a "Modern GUI" (i.e. something a Java coder might recognize), here [ABCL 
running under the NetBeans 6.1 debugger][2]

[70]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=70

[2]: http://code.google.com/p/abcl-dynamic-install/wiki/README_netbeans

--

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Ville Voutilainen | 17 Sep 18:01

Re: ArmedBear status with ANSI tests

Here are some findings of the current failures, wrt special variables.

SYMBOL-MACROLET.ERROR.1 fails because of special vars. Or not. See below.

PSETQ.7 and PSETF.7 fail because symbol-macrolet apparently has other problems.

MULTIPLE-VALUE-SETQ.5 and MULTIPLE-VALUE-SETQ.8 also use symbol-macrolet.

RESTART-CASE.29 and  RESTART-CASE.31 have macrolet,  RESTART-CASE.30 has
symbol-macrolet.

PUSH.5 and POP.3 and PUSHNEW.21 have macrolet.

Looks like there's some relatively-low-hanging fruit to pick here.
Erik? Any ideas?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Ville Voutilainen | 17 Sep 18:19

Re: ArmedBear status with ANSI tests

On Wed, Sep 17, 2008 at 7:01 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> wrote:
> Here are some findings of the current failures, wrt special variables.
> SYMBOL-MACROLET.ERROR.1 fails because of special vars. Or not. See below.

Clarification: I found no cases that fail because of special vars. The
symbol-macrolet.1
is the only one where the test even mentions declare special, and
symbol-macrolet
seems otherwise suspicious.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Ville Voutilainen | 20 Sep 14:10

Re: ArmedBear status with ANSI tests

I ran the compiled tests. Not bad at all, 65 failures. For special variables,
LAMBA.64, DEFUN.6 and DEFUN.7 fail.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Erik Huelsmann | 20 Sep 21:12

Re: ArmedBear status with ANSI tests

On Sat, Sep 20, 2008 at 2:10 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> wrote:
> I ran the compiled tests. Not bad at all, 65 failures. For special variables,
> LAMBA.64, DEFUN.6 and DEFUN.7 fail.

Not bad at all. From what I saw, we need to be looking at jvm.lisp;
the only problem: I have some insight in the structure of the
interpreter now, but less so in the compiler. Maybe we should have a
go at analysing the compiler first (and describing it ofcourse)?

Bye,

Erik.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

headers

Mark Evenson | 7 Sep 12:56

[0.0.10.20] BUG with patch to revert CLOS behavior

This round of fixes broke MOP::CHECK-INITARGS for forms without keyword 
arguments, i.e. CLOS forms that used to work before like

   (asdf:operate 'asdf:load-op :s-xml :verbose t)

now fail.

Attached is a patch and a (inchoherent) bug report for what 
investigation I've done.

Mark <evenson <at> panix.com>

--

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

Index: clos.lisp
===================================================================
--- clos.lisp	(revision 11305)
+++ clos.lisp	(working copy)
@@ -1949,11 +1949,14 @@
 ;; "The set of valid initialization arguments for a class is the set of valid
 ;; initialization arguments that either fill slots or supply arguments to
 ;; methods, along with the predefined initialization argument :ALLOW-OTHER-KEYS."
-;; 7.1.2
+;; [CLHS 7.1.2]
+#+nil
 (defun check-initargs (class initargs)
-  (when (oddp (length initargs))

(Continue reading)

headers

Erik Huelsmann | 7 Sep 15:19

Re: [0.0.10.20] BUG with patch to revert CLOS behavior

Thanks for the report!

I reverted the change.

Bye,

Erik.

On Sun, Sep 7, 2008 at 12:56 PM, Mark Evenson <evenson <at> panix.com> wrote:
> This round of fixes broke MOP::CHECK-INITARGS for forms without keyword
> arguments, i.e. CLOS forms that used to work before like
>
>  (asdf:operate 'asdf:load-op :s-xml :verbose t)
>
> now fail.
>
> Attached is a patch and a (inchoherent) bug report for what investigation
> I've done.
>
> Mark <evenson <at> panix.com>
>
>
>
> --
> "A screaming comes across the sky.  It has happened before, but there is
> nothing to compare to it now."
>
> Index: clos.lisp
> ===================================================================
> --- clos.lisp   (revision 11305)

(Continue reading)