armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[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

[armedbear-devel] Unix domain sockets for abcl
by Rudolf Schlatte 26 Nov '12

26 Nov '12

Hi, I'm having a go at getting clx to run on abcl. Seems the jvm doesn't support unix domain sockets out-of-the-box and we need a library like junixsocket (http://code.google.com/p/junixsocket/) or juds (https://github.com/mcfunley/juds) to avoid connecting to localhost:6000 over IP where the X server might not be listening depending on how it's configured. What's the best way to proceed? (I'm a bit jetlagged or I could maybe answer this one myself..) Rudi

2 1

[armedbear-devel] Mobile ports of ABCL?
by Andrew Pennebaker 24 Nov '12

24 Nov '12

Any interest in porting ABCL to Android, iPhone, and Windows Phone? Even just a basic REPL would be really useful for Lispers. -- Cheers, Andrew Pennebaker www.yellosoft.us

2 1

[armedbear-devel] Issue finding methods in JSS
by Jonathan P. Bona 09 Nov '12

09 Nov '12

Hello, We found this issue while working with LSW. It seems to be a bug in how public methods are found for inner classes. The last line of code below results in an exception rather than finding and running the size() method: ;;;---------------- (require :abcl-contrib) (require :jss) (jss::ensure-compatibility) (setq headers (#"getHeaderFields" (#"openConnection" (jss::new 'java.net.url "http://google.com")))) ; a java.util.Collections$UnmodifiableRandomAccessList (setq ural (#"get" headers (second (jss::set-to-list (#"keySet" headers))))) ;finds: #<method public int java.util.Collections$UnmodifiableCollection.size()> (find "size" (#"getMethods" (#"getClass" ural) ) :test 'string-equal :key #"getName") ; Java exception 'java.lang.NoSuchMethodException: No applicable method named size found in java.lang.Object or java.util.Collections$UnmodifiableRandomAccessList'. (#"size" ural) ;;;---------------- I chased this into org.armedbear.lisp.Java, where findMethod is returning null. - Jonathan Bona

4 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel