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

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