From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-14 14:12:03
|
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, Erik. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-31 01:08:42
|
On Thu, Aug 14, 2008 at 4:12 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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, FORMATTER.C.4A, FORMAT.LOGICAL-BLOCK.CIRCLE.1, FORMAT.LOGICAL-BLOCK.CIRCLE.2, FORMAT.LOGICAL-BLOCK.CIRCLE.3, COMPILE-FILE.17, COMPILE-FILE.18. 486.926 seconds real time The difference being MAKE-INSTANCE.ERROR.3, .4, CHANGE-CLASS.1.11 and CHANGE-CLASS.ERROR.4 being resolved. Newly introduced are DEFPACKAGE.24 and DEFPACKAGE.25. Erik. PS: Note the difference in evaluation time from last (~700) vs current (~500). Is that due to configuration issues in my hardware, or did we actually speed up? |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-31 20:30:01
|
On Sun, Aug 31, 2008 at 3:08 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Thu, Aug 14, 2008 at 4:12 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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, DO-ALL-SYMBOLS.9, DO-ALL-SYMBOLS.12, 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. 474.349 seconds real time The summary being: IMPORT.ERROR.4, IMPORT.ERROR.5, DEFPACKAGE.24 and DEFPACKAGE.25 have been fixed. Erik - who finds this a productive weekend - all in all. |
From: Ville V. <vil...@gm...> - 2008-09-03 07:31:18
|
> 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. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-03 08:01:12
|
On 9/3/08, Ville Voutilainen <vil...@gm...> 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. |
From: Ville V. <vil...@gm...> - 2008-09-06 18:42:48
|
>> 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. |
From: Ville V. <vil...@gm...> - 2008-09-07 18:09:23
|
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- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-07 18:47:19
Attachments:
Closure.patch
|
On Sun, Sep 7, 2008 at 8:09 PM, Ville Voutilainen <vil...@gm...> 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. |
From: Ville V. <vil...@gm...> - 2008-09-07 21:45:23
|
> 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- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-07 22:03:07
|
On Sun, Sep 7, 2008 at 11:45 PM, Ville Voutilainen <vil...@gm...> 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 > be cleaned up, but I suppose that at least some of it can be, even > in java code. The current code looks unwieldy. Yes, I would accept such a patch. It would indeed seem like a good idea to slowly go over the code-base to do cleanups like these, hopefully reducing memory and stacksize requirements along the way. (But can we at least keep the current speed or even improve on it?) Bye, Erik. |
From: Mark E. <ev...@pa...> - 2008-09-08 12:23:03
|
XXXXXXXXXXXXXX wrote: > On Sun, Sep 7, 2008 at 11:45 PM, Ville Voutilainen > <vil...@gm...> 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." |
From: Ville V. <vil...@gm...> - 2008-09-08 15:27:04
|
On Mon, Sep 8, 2008 at 3:23 PM, Mark Evenson <ev...@pa...> 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 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. |
From: Mark E. <ev...@pa...> - 2008-09-08 18:12:50
|
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 nothing to compare to it now." |
From: Mark E. <ev...@pa...> - 2008-09-09 12:49:28
|
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." |
From: Mark E. <ev...@pa...> - 2008-09-01 16:05:11
|
XXXXXXXXXXXXXX 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." |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-01 19:52:54
|
On Mon, Sep 1, 2008 at 6:05 PM, Mark Evenson <ev...@pa...> wrote: > XXXXXXXXXXXXXX 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. |
From: Mark E. <ev...@pa...> - 2008-09-07 10:56:42
Attachments:
abcl-clos-20080906.diff
clos-asdf-operate-keywords
|
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 <ev...@pa...> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-07 13:18:56
|
Thanks for the report! I reverted the change. Bye, Erik. On Sun, Sep 7, 2008 at 12:56 PM, Mark Evenson <ev...@pa...> 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 <ev...@pa...> > > > > -- > "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)) > - (error 'program-error > - :format-control "Odd number of keyword arguments.")) > +;; parity of totals arguments is not necessarily valid in the absence of > only > +;; &keywords arguments) > +;; (when (oddp (length initargs)) > +;; (error 'program-error > +;; :format-control "Odd number of keyword arguments.")) > (unless (getf initargs :allow-other-keys) > (let ((slots (%class-slots class))) > (do* ((tail initargs (cddr tail)) > @@ -1965,11 +1968,16 @@ > :format-control "Invalid initarg ~S." > :format-arguments (list initarg))))))) > > -;; FIXME: 20080830 XXXXXXXXXX - The above method used to be commented out > +;; FIXME: > +;; 20080906 evenson - Revert to no checking > +;; Counting the parity of arguments fails for non-keywords. > +;; ex: (asdf:operate 'asdf:load-op :hunchentoot :verbose t) > +;; > +;; 20080830 XXXXXXXXXX - The above method used to be commented out > ;; I switched the situation around, based upon my reading of the spec, the > ;; version above is not strict enough, but correct when it generates an > error > ;; In other words: it allows unsupported arguments when ':allow-other-keys > T' > -#+nil > +;; > (defun check-initargs (class initargs) > (declare (ignore class initargs))) > > > 2008 09 04 ME > > >From ABCL 0.0.10.19 to 0.0.10.20 > > (in-package :asdf) > (operate 'load-op 'jss :verbose t) > > No longer works with > > Invalid initarg :VERBOSE. > > Correct version from 0.0.0.19 > > #<FUNCTION ASDF:OPERATE {9E29C}> is an object of type COMPILED-FUNCTION. > The function's lambda list is: > (OPERATION-CLASS SYSTEM &REST ARGS &KEY (VERBOSE T) VERSION > &ALLOW-OTHER-KEYS) > > > The first bad revision is: > changeset: 55:043d5782fd28 > user: Mark Evenson <ev...@pa...> > date: Tue Sep 02 08:29:36 2008 +0200 > summary: ABCL 0.0.10.20 > > > > > ------------------------------------------------------------------------- > 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=/ > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > > |
From: Ville V. <vil...@gm...> - 2008-09-17 16:01:14
|
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? |
From: Ville V. <vil...@gm...> - 2008-09-17 16:19:14
|
On Wed, Sep 17, 2008 at 7:01 PM, Ville Voutilainen <vil...@gm...> 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. |
From: Ville V. <vil...@gm...> - 2008-09-20 12:10:42
|
I ran the compiled tests. Not bad at all, 65 failures. For special variables, LAMBA.64, DEFUN.6 and DEFUN.7 fail. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-20 19:12:53
|
On Sat, Sep 20, 2008 at 2:10 PM, Ville Voutilainen <vil...@gm...> 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. |