December 2012 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] default-initargs not respected for funcallable-standard-class
by Pascal Costanza 05 Jan '13

05 Jan '13

Hi, What the subject line says. Here is a test case: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-method (standard-method) ()) #<STANDARD-CLASS MY-METHOD {1EE9DE5F}> CL-USER(3): (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class) (:default-initargs :method-class (find-class 'my-method))) #<FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION {6E06D676}> CL-USER(4): (defgeneric my-function () (:generic-function-class my-generic-function)) #<MY-GENERIC-FUNCTION MY-FUNCTION {2EA1569}> CL-USER(5): (generic-function-method-class #'my-function) #<STANDARD-CLASS STANDARD-METHOD {4E513D61}> The reason is that the defaulting happens in the keyword arguments for ensure-generic-function (in clos.lisp), which thus overrides any default initargs. However, the defaulting should be left to the class. Pascal -- Pascal Costanza

2 6

[armedbear-devel] Additional slots in function classes screw up std-compute-discriminating-function
by Pascal Costanza 23 Dec '12

23 Dec '12

Hi, What the subject says. Here is a test case: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-function (standard-generic-function) ((a-slot :initarg :a-slot :accessor a-slot)) (:metaclass funcallable-standard-class)) #<FUNCALLABLE-STANDARD-CLASS MY-FUNCTION {24DF7EA4}> CL-USER(3): (defgeneric test (x y z) (:generic-function-class my-function)) #<THREAD "interpreter" {14BAAEA8}>: Debugger invoked on condition of type TYPE-ERROR The value TEST is not of type LIST. The reason is that std-compute-discriminating-function is also called for subclasses of standard-generic-function that don't override compute-discriminating function. The specialization in std-compute-discriminating-function should only occur if the passed function is _extactly_ a standard-generic-function (or if it doesn't add any slots on top of standard-generic-function). By the way, we're getting closer (ha!). More and more test cases in my test suites work. I'm pretty confident that I can add full support for ABCL in Closer to MOP for the next version of ABCL. Pascal -- Pascal Costanza

2 2

[armedbear-devel] Concatenating fasls
by Dave Cooper 21 Dec '12

21 Dec '12

Dear ABCLers, Is it possible to concatenate fasl files (.abcl files) in ABCL, to produce a single loadable .abcl file? -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

2 1

[armedbear-devel] abcl-1.1.0.2
by Mark Evenson 19 Dec '12

19 Dec '12

abcl-1.1.0.2 has been tagged and released. The abcl-1.1.0.2 release is functionally the same as artifacts built from the abcl-1.1.0 source , but not to the artifacts released on 07-DEC-2012, which were incorrectly compiled so that the JSS contrib would not load. The abcl-1.1.0 binaries available from [common-lisp.net][1] have been updated "in-place" with cryptographic signatures updated. [1]: http://common-lisp.net/project/armedbear/ The GoogleCode repository which feeds the MacPorts source doesn't allow re-publishing, so [uniquely named abcl-1.1.0.2 artifacts have been published there][2]. [2]: https://code.google.com/p/abcl-dynamic-install/downloads/list We still plan on releasing abcl-1.1.1 around New Year's Eve. hopefully getting better at managing releases, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[armedbear-devel] ABCL 1.1.0 re-published
by Mark Evenson 17 Dec '12

17 Dec '12

For reasons that are not entirely clear, JSS was not working with the images I published for abcl-1.1.0, even though building from the source on the tag worked fine. I have re-published and re-signed the release to common-lisp.net. Still sort of waiting for Quicklisp 2012-12 to drop before mailing an official announcement. Maybe we should just wait for abcl-1.1.1 at this point. mea culpa, Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] ABCL 1.1.0
by Mark Evenson 10 Dec '12

10 Dec '12

Sometime later today, I intend to make [the current snapshots abcl-1.1.0-rc-2][rc-2] the functional base for [ABCL-1.1.0][]. Please speak up loud if we shouldn't do this. We will have a maintenance release within 30 days. [rc-2]: https://code.google.com/p/abcl-dynamic-install/downloads/list [ABCL-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 For the Mgmt., Mark <evenson(a)panix.com> P.S. Multiple cryptographic signatures when tag is created would be a nice thing. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

3 8

Re: [armedbear-devel] jss wouldn't load in trunk, fixed in r14313
by Mark Evenson 07 Dec '12

07 Dec '12

I think this us fixed, but I am currently visiting my doctor so won't be able to verify until later. -- Mark Rudolf Schlatte <rudi(a)constantly.at> wrote: >Hi, > >I just removed a spurious dot in jss.asd which caused loading e.g. cffi to fail. If this . is also in the release candidate, it should be removed before release. :) (I fail at git-svn and so only see trunk.) > >Cheers, > >Rudi >_______________________________________________ >armedbear-devel mailing list >armedbear-devel(a)common-lisp.net >http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >

1 1

[armedbear-devel] jss wouldn't load in trunk, fixed in r14313
by Rudolf Schlatte 07 Dec '12

07 Dec '12

Hi, I just removed a spurious dot in jss.asd which caused loading e.g. cffi to fail. If this . is also in the release candidate, it should be removed before release. :) (I fail at git-svn and so only see trunk.) Cheers, Rudi

1 0

[armedbear-devel] abcl-1.1.0 release status
by Mark Evenson 07 Dec '12

07 Dec '12

Overall, I think we are more-or-less ready to release the long awaited abcl-1.1.0 with the exception of resolving the outstanding ANSI regression failures. I have moved all previously outstanding issues to the abcl-1.1.1 milestone, and I have added as three blocker tickets to the abcl-1.1.0 milestone to decide on what to do. http://trac.common-lisp.net/armedbear/ticket/265 http://trac.common-lisp.net/armedbear/ticket/266 http://trac.common-lisp.net/armedbear/ticket/267 For each of these issues, I have identified the changeset that caused the regression via bisecting the source tree. If the result of the bisection is correct, all three issues should be relatively easy to track down, as "not much happened" in the commits. But maybe something was screwy in my process (I did it "on the road" from an iPad ssh client last week in a non-traditional--for me--working environment). Additionally, we should probably check the Novemeber Quicklisp test reports to see if anything has been broken. I seem to see a problem with Hunchentoot under SLIME regarding the PATHNAME reader, but this may be something local to me. I need to finish writing up the CHANGES, and make a quick pass through the manual, updating the grovelled docstring sections. Hopefully, we can have a quick consultation on #abcl tonight at 2100 CST to see if these plans make sense. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

5 21

[armedbear-devel] ABCL 1.1.0 RC2
by Mark Evenson 06 Dec '12

06 Dec '12

All reported outstanding bugs with CLOSER-MOP addressed in [abcl-1.1.0][rc2]. Please test. [rc2]: http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] JFLI bug
by Carlos Ungil 05 Dec '12

05 Dec '12

Hello, I think this bug report has gone unnoticed: there is a reference to sys::ensure-class (has to be changed to mop:ensure-class) in http://trac.common-lisp.net/armedbear/browser/trunk/abcl/contrib/jfli/jfli.… Thanks, Carlos On Wed, Nov 28, 2012 at 11:10 PM, Carlos Ungil <carlos.ungil(a)gmail.com> wrote: > Mark, Erik, > > thank you for those fixes. > > There is another bug in jfli.lisp, at line 366 there is a call to > sys::ensure-class > but it seems that this function has been moved to another package: > mop:ensure-class > > I have two more comments about jfli.lisp (but these are not critical issues). > > 1) the function unbox-string (never used, probably it can be removed) > calls the undefined function convert-from-java-string > > 2) I used to have an additional clause in infer-box-type (I don't > remember the details, but I think I had to add it to be able to pass a > Float argument to some java API): > > ((typep x '(integer -9223372036854775808 +9223372036854775807)) long.type) > + ((typep x 'single-float) float.type) > ((numberp x) double.type) > > Cheers, > > Carlos > > On Wed, Nov 28, 2012 at 10:26 AM, Mark Evenson <evenson(a)panix.com> wrote: >> >> On Nov 26, 2012, at 11:34 PM, Carlos Ungil <carlos.ungil(a)gmail.com> wrote: >> >>> Dear ABCL developers, >>> >>> I apologize if this is not the right channel for this kind of request, >>> but I'd like to suggest the following change to >>> src/org/armedbear/lisp/Lisp.java (for CFFI to identify the platform >>> properly on MacOSX). >>> >>> @@ -2378,9 +2378,9 @@ >>> } >>> // Processor architecture >>> if(osArch != null) { >>> - if (osArch.equals("amd64")) >>> + if (osArch.equals("amd64")||osArch.equals("x86_64")) >>> featureList = new Cons(Keyword.X86_64, featureList); >>> - else if (osArch.equals("x86")) >>> + else if (osArch.equals("x86")||osArch.equals("i386")) >>> featureList = new Cons(Keyword.X86, featureList); >>> } >>> Symbol.FEATURES.initializeSpecial(featureList); >>> >> >> Erik applied this in [r14256][]. Thanks for the patch! >> >> [r14256]: http://trac.common-lisp.net/armedbear/changeset/14256 >> >>> Also, there is a problem with contrib/jfli/test/yanking.lisp, there is >>> a referece to abclidea:*lisp-dir* and that package is not part of >>> ABCL. >>> As a workaround I've changed contrib/jfli/jfli.asd to remove the >>> (:module test :components ((:file "yanking")) >> >> Since there is no need for runtime dependency for JFLI on IntelliJ, >> I [have moved the JFLI IntelliJ test suite into its own ASDF system >> definition][r14257]. Please let us know if this does' work for you >> for some reason. >> >> [r14257]: http://trac.common-lisp.net/armedbear/changeset/14257 >> >> -- >> "A screaming comes across the sky. It has happened before but there is nothing to compare to it now." >> > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #266: PSETF.47 ANSI regression
by Erik Huelsmann 05 Dec '12

05 Dec '12

That's correct. sent from my phone On Dec 5, 2012 5:02 PM, "armedbear" <armedbear-devel(a)common-lisp.net> wrote: > #266: PSETF.47 ANSI regression > > -----------------------------+---------------------------------------------- > Reporter: mevenson | Owner: nobody > Type: defect | Status: new > Priority: blocker | Milestone: 1.1.0 > Component: java | Version: 1.1.0-dev > Keywords: ansi-regression | > > -----------------------------+---------------------------------------------- > > Comment(by rschlatte): > > (setf mask-bit) is undefined until mask-bit is called. Maybe outoloading > is to blame? > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/266#comment:1> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0

[armedbear-devel] reinitialize-instance on class metaobjects incorrect
by Pascal Costanza 05 Dec '12

05 Dec '12

Hi, Consider the following test case: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass a () ()) #<STANDARD-CLASS A {794563AA}> CL-USER(3): (defclass b (a) ()) #<STANDARD-CLASS B {62F6FB59}> CL-USER(4): (finalize-inheritance (find-class 'a)) NIL CL-USER(5): (finalize-inheritance (find-class 'b)) NIL CL-USER(6): (class-precedence-list (find-class 'b)) (#<STANDARD-CLASS B {62F6FB59}> #<STANDARD-CLASS A {794563AA}> #<STANDARD-CLASS STANDARD-OBJECT {23309E87}> #<BUILT-IN-CLASS T {100C62C8}>) CL-USER(7): (reinitialize-instance (find-class 'b)) #<STANDARD-CLASS B {62F6FB59}> CL-USER(8): (class-precedence-list (find-class 'b)) (#<STANDARD-CLASS B {62F6FB59}> #<STANDARD-CLASS STANDARD-OBJECT {23309E87}> #<BUILT-IN-CLASS T {100C62C8}>) The invocation of reinitialize-instance obviously reinitialized the direct-superclasses slot, and thus removed the superclass a. However, according to the HyperSpec, the general protocol for reinitialize-instance is always that slots for which no initargs are provided through reinitialize-instance should be left untouched. This also restated implicitly in the CLOS MOP specification, for example in the section "Initialization of Class Metaobjects:" The defaulted superclass list is specified to be only assigned during initialization, but not during reinitialization. Pascal -- Pascal Costanza

2 2

[armedbear-devel] defmethod doesn't call add-method
by Pascal Costanza 04 Dec '12

04 Dec '12

Hi, There is a problem that a defmethod may not call add-method as it should. Here is a transcript: CL-USER(1): (use-package :mop) T CL-USER(2): (defclass my-generic-function (standard-generic-function) () (:metaclass funcallable-standard-class)) #<FUNCALLABLE-STANDARD-CLASS MY-GENERIC-FUNCTION {3606AFA2}> CL-USER(3): (defgeneric f (x) (:generic-function-class my-generic-function)) #<MY-GENERIC-FUNCTION F {589D4D84}> CL-USER(4): (defmethod add-method :after ((gf my-generic-function) (m standard-method)) (print :foo)) #<STANDARD-METHOD ADD-METHOD :AFTER (MY-GENERIC-FUNCTION STANDARD-METHOD) {3F4C428F}> CL-USER(5): (defmethod f ((x integer)) (+ x x)) #<STANDARD-METHOD F (INTEGER) {27A5DAC0}> CL-USER(6): (add-method #'f *) :FOO #<MY-GENERIC-FUNCTION F {589D4D84}> CL-USER(7): (f 5) 10 …or maybe just :after methods on add-method are not called… Pascal -- Pascal Costanza

2 2

[armedbear-devel] compiler macro, flet, inline => Failed AVER: "NIL"
by James M. Lawrence 03 Dec '12

03 Dec '12

Armed Bear Common Lisp 1.2.0-dev-svn-14276 Java 1.7.0_04 Oracle Corporation The warning and error occurs on the second COMPILE call. The AVER is in COMPILE-VAR-REF. (defun foo (n) n) (define-compiler-macro foo (n) `(flet ((bar (k) k)) (declare (inline bar)) (bar ,n))) (compile nil '(lambda () (foo 3))) (compile nil '(lambda () (foo 3))) ; Caught STYLE-WARNING: ; The variable K is defined but never used. compile-var-ref general case ; Compilation unit finished ; Caught 1 STYLE-WARNING condition => Failed AVER: "NIL" [Condition of type SIMPLE-ERROR]

2 1

[armedbear-devel] Incomplete file lisp/digest.lisp in r14198
by Eric Marsden 02 Dec '12

02 Dec '12

Hi, File src/org/armedbear/lisp/digest.lisp in current SVN contains an incomplete function named SHA256 (unbalanced parentheses). -- Eric Marsden

5 7

[armedbear-devel] abcl-1.1.0 RC0
by Mark Evenson 01 Dec '12

01 Dec '12

First release candidate of abcl-1.1.0 now available. [source]: svn://common-lisp.net/project/armedbear/svn/branches/1.1.x/ [binaries]: http://code.google.com/p/abcl-dynamic-install/downloads -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0