ArmedBear / J

I tried to compile Maxima 5.20.1 from source with the lisp based build 
process. In the past this worked very well, but now with ABCL 0.18 even  
(load "maxima-build.lisp") needs too much memory.  Has anybody suceeded 
in compileing Maxim with 0.18?
Reinhard Oldenburg

Re: [j-devel] Maxima compilation on 0.18 From: Ville Voutilainen <ville.voutilainen@gm...> - 2010-01-18 10:25 2010/1/18 Reinhard Oldenburg <oldenbur@...>: > I tried to compile Maxima 5.20.1 from source with the lisp based build > process. In the past this worked very well, but now with ABCL 0.18 even > (load "maxima-build.lisp") needs too much memory.  Has anybody suceeded > in compileing Maxim with 0.18? I think the soon forthcoming 0.18.1 will fix this issue.

Re: [j-devel] Maxima compilation on 0.18 From: Erik Huelsmann <ehuels@gm...> - 2010-01-18 11:37 Actually: I uploaded the tars and signatures already, updated the website too, just didn't get around to announcing it. Bye, Erik. On Mon, Jan 18, 2010 at 11:25 AM, Ville Voutilainen <ville.voutilainen@...> wrote: > 2010/1/18 Reinhard Oldenburg <oldenbur@...>: >> I tried to compile Maxima 5.20.1 from source with the lisp based build >> process. In the past this worked very well, but now with ABCL 0.18 even >> (load "maxima-build.lisp") needs too much memory.  Has anybody suceeded >> in compileing Maxim with 0.18? > > I think the soon forthcoming 0.18.1 will fix this issue. > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > armedbear-j-devel mailing list > armedbear-j-devel@... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel >

The Jena toolkit has antisocially defined the toString method of an
important object to be computationally expensive - it triggers a
description logical classification process in some cases, something
which can blow out memory or take a very very long time.

Therefore I need to be able to override that behavior so that if I
happen to get a stack trace or other wise cause one to be printed
toString is not called.

As far as I can tell, it seems that the case of printing a java object
is handled by

public String writeToString()  in JavaObject.java

An approach that makes sense to me would be to have this method look
for an eql method with the class of the object as specializer.

(defmethod java-object-to-string ((class (eql (load-time-value
(find-java-class "com.hp.hpl.jena.ontology.impl.OntModelImpl"))))))
..)

and if such a method exists, call it instead of using the default
implementation.

Other ideas welcome.

-Alan

Re: [j-devel] need to customize print-object for a java class From: Alessio Stalla <alessiostalla@gm...> - 2010-01-14 14:38 On Thu, Jan 14, 2010 at 3:33 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > The Jena toolkit has antisocially defined the toString method of an > important object to be computationally expensive - it triggers a > description logical classification process in some cases, something > which can blow out memory or take a very very long time. > > Therefore I need to be able to override that behavior so that if I > happen to get a stack trace or other wise cause one to be printed > toString is not called. > > As far as I can tell, it seems that the case of printing a java object > is handled by > > public String writeToString()  in JavaObject.java > > An approach that makes sense to me would be to have this method look > for an eql method with the class of the object as specializer. > > (defmethod java-object-to-string ((class (eql (load-time-value > (find-java-class "com.hp.hpl.jena.ontology.impl.OntModelImpl")))))) > ..) > > and if such a method exists, call it instead of using the default > implementation. > > Other ideas welcome. I believe (defmethod print-object ((obj (jclass "com.foo.whatever")) stream) ...) should do, at least when the printing is done in Lisp through the standard CL printing functions. hth, Ale

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-14 14:43 Where's this implemented? It doesn't work for me because jclass doesn't find classes on the dynamically extended classpath I use. Would this method be called when a backtrace used in slime is constructed? Thanks, Alan On Thu, Jan 14, 2010 at 9:38 AM, Alessio Stalla <alessiostalla@...> wrote: > On Thu, Jan 14, 2010 at 3:33 PM, Alan Ruttenberg > <alanruttenberg@...> wrote: >> The Jena toolkit has antisocially defined the toString method of an >> important object to be computationally expensive - it triggers a >> description logical classification process in some cases, something >> which can blow out memory or take a very very long time. >> >> Therefore I need to be able to override that behavior so that if I >> happen to get a stack trace or other wise cause one to be printed >> toString is not called. >> >> As far as I can tell, it seems that the case of printing a java object >> is handled by >> >> public String writeToString()  in JavaObject.java >> >> An approach that makes sense to me would be to have this method look >> for an eql method with the class of the object as specializer. >> >> (defmethod java-object-to-string ((class (eql (load-time-value >> (find-java-class "com.hp.hpl.jena.ontology.impl.OntModelImpl")))))) >> ..) >> >> and if such a method exists, call it instead of using the default >> implementation. >> >> Other ideas welcome. > > I believe > > (defmethod print-object ((obj (jclass "com.foo.whatever")) stream) ...) > > should do, at least when the printing is done in Lisp through the > standard CL printing functions. > > hth, > Ale >

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-14 14:44 Also, I get: (defmethod print-object ((obj (jclass "java.net.URI")) stream) (print-unreadable-object (obj stream :identity t :type t))) -> ; Evaluation aborted. -Alan 2010/1/14 Alan Ruttenberg <alanruttenberg@...>: > Where's this implemented? It doesn't work for me because jclass doesn't find classes on the dynamically extended classpath I use. > > Would this method be called when a backtrace used in slime is constructed? > > Thanks, > Alan > > On Thu, Jan 14, 2010 at 9:38 AM, Alessio Stalla <alessiostalla@...> wrote: >> On Thu, Jan 14, 2010 at 3:33 PM, Alan Ruttenberg >> <alanruttenberg@...> wrote: >>> The Jena toolkit has antisocially defined the toString method of an >>> important object to be computationally expensive - it triggers a >>> description logical classification process in some cases, something >>> which can blow out memory or take a very very long time. >>> >>> Therefore I need to be able to override that behavior so that if I >>> happen to get a stack trace or other wise cause one to be printed >>> toString is not called. >>> >>> As far as I can tell, it seems that the case of printing a java object >>> is handled by >>> >>> public String writeToString()  in JavaObject.java >>> >>> An approach that makes sense to me would be to have this method look >>> for an eql method with the class of the object as specializer. >>> >>> (defmethod java-object-to-string ((class (eql (load-time-value >>> (find-java-class "com.hp.hpl.jena.ontology.impl.OntModelImpl")))))) >>> ..) >>> >>> and if such a method exists, call it instead of using the default >>> implementation. >>> >>> Other ideas welcome. >> >> I believe >> >> (defmethod print-object ((obj (jclass "com.foo.whatever")) stream) ...) >> >> should do, at least when the printing is done in Lisp through the >> standard CL printing functions. >> >> hth, >> Ale >> > >

Re: [j-devel] need to customize print-object for a java class From: Alessio Stalla <alessiostalla@gm...> - 2010-01-14 14:59 On Thu, Jan 14, 2010 at 3:44 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > Also, I get: > > (defmethod print-object ((obj (jclass "java.net.URI")) stream) > (print-unreadable-object (obj stream :identity t :type t))) > -> ; Evaluation aborted. Oh. I get this too, but it seems related to some failure in printing code; (progn (defmethod print-object ((obj (jclass "java.net.URI")) stream) (print-unreadable-object (obj stream :identity t :type t))) nil) works. > -Alan > > > 2010/1/14 Alan Ruttenberg <alanruttenberg@...>: >> Where's this implemented? It doesn't work for me because jclass doesn't find classes on the dynamically extended classpath I use. It should be implemented in JavaClass.java and clos.lisp, iirc. Wrt. the dynamic classpath, jclass should be extended to handle an optional "classloader" parameter. >> Would this method be called when a backtrace used in slime is constructed? I completely ignore that. Bye, Ale

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-14 18:20 On Thu, Jan 14, 2010 at 9:59 AM, Alessio Stalla <alessiostalla@...> wrote: >> (defmethod print-object ((obj (jclass "java.net.URI")) stream) >> (print-unreadable-object (obj stream :identity t :type t))) >> -> ; Evaluation aborted. > > Oh. I get this too, but it seems related to some failure in printing code; > The problem is that the name slot of JAVA-CLASSes is not initialized, and so class-name fails. -Alan

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-14 18:29 Here's my patch to make this work in my environment: (defmethod print-object ((method standard-method) stream) (print-unreadable-object (method stream :identity t) (format stream "~S ~S~{ ~S~} ~S" (class-name (class-of method)) (%generic-function-name (%method-generic-function method)) (method-qualifiers method) (mapcar #'(lambda (c) (if (typep c 'mop::eql-specializer) `(eql ,(mop::eql-specializer-object c)) (if (typep c 'java::java-class) `(java::jclass ,(#"getName" (cl-user::get-java-field c "javaClass" t))) (class-name c)))) (%method-specializers method)))) method) (advise java::%find-java-class (if (cl-user::find-java-class (car arglist)) (#"findJavaClass" 'org.armedbear.lisp.JavaClass (cl-user::find-java-class (car arglist))) (:do-it)) :when :around :name :dynamic-classpath)) Now to find out why slime isn't using #'print-object ... -Alan 2010/1/14 Alan Ruttenberg <alanruttenberg@...>: > > > On Thu, Jan 14, 2010 at 9:59 AM, Alessio Stalla <alessiostalla@...> wrote: >>> (defmethod print-object ((obj (jclass "java.net.URI")) stream) >>> (print-unreadable-object (obj stream :identity t :type t))) >>> -> ; Evaluation aborted. >> >> Oh. I get this too, but it seems related to some failure in printing code; >> > > The problem is that the name slot of JAVA-CLASSes is not initialized, and so class-name fails. > > -Alan >

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-14 20:43 On Thu, Jan 14, 2010 at 1:29 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > Now to find out why slime isn't using #'print-object ... > > -Alan > That would be because print isn't calling print-object for java objects. (in-package #:system) ;; define the default method for java objects (defmethod print-object ((obj java::java-object) stream) (print-unreadable-object (obj stream :identity t) (let ((tostring (jcall "toString" obj))) (if (> (length tostring) 32) (format stream "~a ~a..." (java::jclass-name (java::jobject-class obj)) (subseq tostring 0 32) stream) (format stream "~a ~a" (java::jclass-name (java::jobject-class obj)) tostring stream))))) ;; modify so that print-object is called on java objects too. (defun output-ugly-object (object stream) (cond ((consp object) (output-list object stream)) ((and (vectorp object) (not (stringp object)) (not (bit-vector-p object))) (output-vector object stream)) ((structure-object-p object) (cond ((and (null *print-readably*) *print-level* (>= *current-print-level* *print-level*)) (write-char #\# stream)) (t (print-object object stream)))) ((standard-object-p object) (print-object object stream)) ((java::java-object-p object) (print-object object stream)) ((xp::xp-structure-p stream) (let ((s (sys::%write-to-string object))) (xp::write-string++ s stream 0 (length s)))) (t (%output-object object stream))))

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-14 21:29 Well, not quite. Also, slime calls sys::frame-to-string, which doesn't respect java object's print-object method. This is inside java code and I don't know how to properly fix that. I'm patching as: (advise sys::frame-to-string (if (typep (car arglist) 'system::lisp-stack-frame) (prin1-to-string (sys::frame-to-list (car arglist))) (:do-it) ) :when :around :name :freedom) but would appreciate if someone could do the right thing. -Alan On Thu, Jan 14, 2010 at 3:43 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > On Thu, Jan 14, 2010 at 1:29 PM, Alan Ruttenberg > <alanruttenberg@...> wrote: >> Now to find out why slime isn't using #'print-object ... >> >> -Alan >> > > That would be because print isn't calling print-object for java objects. > > (in-package #:system) > > ;; define the default method for java objects > (defmethod print-object ((obj java::java-object) stream) >        (print-unreadable-object (obj stream :identity t) >          (let ((tostring (jcall "toString" obj))) >            (if (> (length tostring) 32) >                (format stream "~a ~a..." (java::jclass-name (java::jobject-class > obj))  (subseq tostring 0 32) stream) >                (format stream "~a ~a" (java::jclass-name (java::jobject-class obj)) > tostring stream))))) > > > ;; modify so that print-object is called on java objects too. > > (defun output-ugly-object (object stream) >        (cond ((consp object) >               (output-list object stream)) >              ((and (vectorp object) >                    (not (stringp object)) >                    (not (bit-vector-p object))) >               (output-vector object stream)) >              ((structure-object-p object) >               (cond >                 ((and (null *print-readably*) >                       *print-level* >                       (>= *current-print-level* *print-level*)) >                  (write-char #\# stream)) >                 (t >                  (print-object object stream)))) >              ((standard-object-p object) >               (print-object object stream)) >              ((java::java-object-p object) >               (print-object object stream)) >              ((xp::xp-structure-p stream) >               (let ((s (sys::%write-to-string object))) >                 (xp::write-string++ s stream 0 (length s)))) >              (t >               (%output-object object stream)))) >

Re: [j-devel] need to customize print-object for a java class From: Alessio Stalla <alessiostalla@gm...> - 2010-01-14 22:18 On Thu, Jan 14, 2010 at 10:29 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > Well, not quite. > > Also, slime calls sys::frame-to-string, which doesn't respect java > object's print-object method. > This is inside java code and I don't know how to properly fix that. > I'm patching as: > > (advise sys::frame-to-string >                 (if (typep (car arglist) 'system::lisp-stack-frame) >                     (prin1-to-string >                      (sys::frame-to-list (car arglist))) >                     (:do-it) >                     ) >                 :when :around >                 :name :freedom) > > but would appreciate if someone could do the right thing. You should find that on trunk: I actually called prin1-to-string from Java; I don't think that should cause any problems, but if someone has objections, let me know. Alessio > -Alan > > > On Thu, Jan 14, 2010 at 3:43 PM, Alan Ruttenberg > <alanruttenberg@...> wrote: >> On Thu, Jan 14, 2010 at 1:29 PM, Alan Ruttenberg >> <alanruttenberg@...> wrote: >>> Now to find out why slime isn't using #'print-object ... >>> >>> -Alan >>> >> >> That would be because print isn't calling print-object for java objects. >> >> (in-package #:system) >> >> ;; define the default method for java objects >> (defmethod print-object ((obj java::java-object) stream) >>        (print-unreadable-object (obj stream :identity t) >>          (let ((tostring (jcall "toString" obj))) >>            (if (> (length tostring) 32) >>                (format stream "~a ~a..." (java::jclass-name (java::jobject-class >> obj))  (subseq tostring 0 32) stream) >>                (format stream "~a ~a" (java::jclass-name (java::jobject-class obj)) >> tostring stream))))) >> >> >> ;; modify so that print-object is called on java objects too. >> >> (defun output-ugly-object (object stream) >>        (cond ((consp object) >>               (output-list object stream)) >>              ((and (vectorp object) >>                    (not (stringp object)) >>                    (not (bit-vector-p object))) >>               (output-vector object stream)) >>              ((structure-object-p object) >>               (cond >>                 ((and (null *print-readably*) >>                       *print-level* >>                       (>= *current-print-level* *print-level*)) >>                  (write-char #\# stream)) >>                 (t >>                  (print-object object stream)))) >>              ((standard-object-p object) >>               (print-object object stream)) >>              ((java::java-object-p object) >>               (print-object object stream)) >>              ((xp::xp-structure-p stream) >>               (let ((s (sys::%write-to-string object))) >>                 (xp::write-string++ s stream 0 (length s)))) >>              (t >>               (%output-object object stream)))) >> >

Re: [j-devel] need to customize print-object for a java class From: Mark Evenson <evenson@pa...> - 2010-01-15 07:46 On 1/14/10 3:33 PM, Alan Ruttenberg wrote: > The Jena toolkit has antisocially defined the toString method of an > important object to be computationally expensive - it triggers a > description logical classification process in some cases, something > which can blow out memory or take a very very long time. […] Ouch! I had hoped that the the toString() "contract" in Java entailed a non-computationally expensive result, and that this was widely adopted. Then a HEADS UP is in order: I committed (~20100112) to SLIME HEAD a patch that invokes the "toString()" method on all JAVA-OBJECTs as a convenience. When I get the chance, I will revise the SLIME patch, and revisit the SYS::FRAME-TO-STRING code, but I don't think I will find time for this until much later today or tomorrow. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

Re: [j-devel] need to customize print-object for a java class From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-15 20:05 Thanks Alessio. How about the other patches? http://sourceforge.net/mailarchive/message.php?msg_name=29af5e2d1001141029ved6e76ay532cd0f120614e2f%40mail.gmail.com Fixes the print-object method for close methods specialized on java classes http://sourceforge.net/mailarchive/message.php?msg_name=29af5e2d1001141243s5ff7264fg8538d4054448879%40mail.gmail.com Defines a base method for printing java objects, replicating the behavior of what is currently defined in the java code, and modifies output-ugly-object so that it gets called. Would it be possible to integrate these as well? Thanks, Alan On Thu, Jan 14, 2010 at 5:11 PM, Alessio Stalla <alessiostalla@...> wrote: > On Thu, Jan 14, 2010 at 10:29 PM, Alan Ruttenberg > <alanruttenberg@...> wrote: >> Well, not quite. >> >> Also, slime calls sys::frame-to-string, which doesn't respect java >> object's print-object method. >> This is inside java code and I don't know how to properly fix that. >> I'm patching as: >> >> (advise sys::frame-to-string >>                 (if (typep (car arglist) 'system::lisp-stack-frame) >>                     (prin1-to-string >>                      (sys::frame-to-list (car arglist))) >>                     (:do-it) >>                     ) >>                 :when :around >>                 :name :freedom) >> >> but would appreciate if someone could do the right thing. > > You should find that on trunk: I actually called prin1-to-string from > Java; I don't think that should cause any problems, but if someone has > objections, let me know. > > Alessio > >> -Alan >> >> >> On Thu, Jan 14, 2010 at 3:43 PM, Alan Ruttenberg >> <alanruttenberg@...> wrote: >>> On Thu, Jan 14, 2010 at 1:29 PM, Alan Ruttenberg >>> <alanruttenberg@...> wrote: >>>> Now to find out why slime isn't using #'print-object ... >>>> >>>> -Alan >>>> >>> >>> That would be because print isn't calling print-object for java objects. >>> >>> (in-package #:system) >>> >>> ;; define the default method for java objects >>> (defmethod print-object ((obj java::java-object) stream) >>>        (print-unreadable-object (obj stream :identity t) >>>          (let ((tostring (jcall "toString" obj))) >>>            (if (> (length tostring) 32) >>>                (format stream "~a ~a..." (java::jclass-name (java::jobject-class >>> obj))  (subseq tostring 0 32) stream) >>>                (format stream "~a ~a" (java::jclass-name (java::jobject-class obj)) >>> tostring stream))))) >>> >>> >>> ;; modify so that print-object is called on java objects too. >>> >>> (defun output-ugly-object (object stream) >>>        (cond ((consp object) >>>               (output-list object stream)) >>>              ((and (vectorp object) >>>                    (not (stringp object)) >>>                    (not (bit-vector-p object))) >>>               (output-vector object stream)) >>>              ((structure-object-p object) >>>               (cond >>>                 ((and (null *print-readably*) >>>                       *print-level* >>>                       (>= *current-print-level* *print-level*)) >>>                  (write-char #\# stream)) >>>                 (t >>>                  (print-object object stream)))) >>>              ((standard-object-p object) >>>               (print-object object stream)) >>>              ((java::java-object-p object) >>>               (print-object object stream)) >>>              ((xp::xp-structure-p stream) >>>               (let ((s (sys::%write-to-string object))) >>>                 (xp::write-string++ s stream 0 (length s)))) >>>              (t >>>               (%output-object object stream)))) >>> >> >

Re: [j-devel] need to customize print-object for a java class From: Alessio Stalla <alessiostalla@gm...> - 2010-01-15 21:09 On Fri, Jan 15, 2010 at 9:05 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > Thanks Alessio. > > How about the other patches? > > http://sourceforge.net/mailarchive/message.php?msg_name=29af5e2d1001141029ved6e76ay532cd0f120614e2f%40mail.gmail.com > > Fixes the print-object method for close methods specialized on java classes > > http://sourceforge.net/mailarchive/message.php?msg_name=29af5e2d1001141243s5ff7264fg8538d4054448879%40mail.gmail.com > > Defines a base method for printing java objects, replicating the > behavior of what is currently defined in the java code, and modifies > output-ugly-object so that it gets called. > > Would it be possible to integrate these as well? [R12377] and [R12379] should do it; let me know if they work for you. A couple of notes: for method specialized on Java classes, I made what I believe to be the right thing: have the symbol slot of JavaClass initialized with an uninterned symbol named like the class, so that it's printed correctly by the existing code. Examples: CL-USER(1): (defmethod foo ((obj (jclass "java.lang.Object"))) obj) #<STANDARD-METHOD FOO (#:|java.lang.Object|) {C95DAA}> CL-USER(2): (mop::%class-name (class-of (jnew "java.lang.String"))) #:|java.lang.String| for print-object on java objects, I just made it call %write-to-string on the object, which calls the Java writeToString(), so it's only implemented once. Apparently changing output-ugly-object wasn't necessary, but if you find out it is, let me know. Additionally, I have a local patch to make jclass work with custom classloaders, if you're interested. I prefer to be cautious with this one and not to commit it immediately; I need to properly test it. Bye, Ale [R12377] http://trac.common-lisp.net/armedbear/changeset/12377 [R12379] http://trac.common-lisp.net/armedbear/changeset/12379 > Thanks, > Alan > > On Thu, Jan 14, 2010 at 5:11 PM, Alessio Stalla <alessiostalla@...> wrote: >> On Thu, Jan 14, 2010 at 10:29 PM, Alan Ruttenberg >> <alanruttenberg@...> wrote: >>> Well, not quite. >>> >>> Also, slime calls sys::frame-to-string, which doesn't respect java >>> object's print-object method. >>> This is inside java code and I don't know how to properly fix that. >>> I'm patching as: >>> >>> (advise sys::frame-to-string >>>                 (if (typep (car arglist) 'system::lisp-stack-frame) >>>                     (prin1-to-string >>>                      (sys::frame-to-list (car arglist))) >>>                     (:do-it) >>>                     ) >>>                 :when :around >>>                 :name :freedom) >>> >>> but would appreciate if someone could do the right thing. >> >> You should find that on trunk: I actually called prin1-to-string from >> Java; I don't think that should cause any problems, but if someone has >> objections, let me know. >> >> Alessio >> >>> -Alan >>> >>> >>> On Thu, Jan 14, 2010 at 3:43 PM, Alan Ruttenberg >>> <alanruttenberg@...> wrote: >>>> On Thu, Jan 14, 2010 at 1:29 PM, Alan Ruttenberg >>>> <alanruttenberg@...> wrote: >>>>> Now to find out why slime isn't using #'print-object ... >>>>> >>>>> -Alan >>>>> >>>> >>>> That would be because print isn't calling print-object for java objects. >>>> >>>> (in-package #:system) >>>> >>>> ;; define the default method for java objects >>>> (defmethod print-object ((obj java::java-object) stream) >>>>        (print-unreadable-object (obj stream :identity t) >>>>          (let ((tostring (jcall "toString" obj))) >>>>            (if (> (length tostring) 32) >>>>                (format stream "~a ~a..." (java::jclass-name (java::jobject-class >>>> obj))  (subseq tostring 0 32) stream) >>>>                (format stream "~a ~a" (java::jclass-name (java::jobject-class obj)) >>>> tostring stream))))) >>>> >>>> >>>> ;; modify so that print-object is called on java objects too. >>>> >>>> (defun output-ugly-object (object stream) >>>>        (cond ((consp object) >>>>               (output-list object stream)) >>>>              ((and (vectorp object) >>>>                    (not (stringp object)) >>>>                    (not (bit-vector-p object))) >>>>               (output-vector object stream)) >>>>              ((structure-object-p object) >>>>               (cond >>>>                 ((and (null *print-readably*) >>>>                       *print-level* >>>>                       (>= *current-print-level* *print-level*)) >>>>                  (write-char #\# stream)) >>>>                 (t >>>>                  (print-object object stream)))) >>>>              ((standard-object-p object) >>>>               (print-object object stream)) >>>>              ((java::java-object-p object) >>>>               (print-object object stream)) >>>>              ((xp::xp-structure-p stream) >>>>               (let ((s (sys::%write-to-string object))) >>>>                 (xp::write-string++ s stream 0 (length s)))) >>>>              (t >>>>               (%output-object object stream)))) >>>> >>> >> >

I have created a tarball that should let you test my code.

With the current svn abcl I don't see the same behavior as last time
(good news) - this time it looks like a compilation problem - if the
functions where the errors occur are evaluated instead of compiled it
runs.

However it should also be noted that if I am running under slime it
takes quite a long time for the debugger to be invoked - 5 to 10
seconds - on the error that occurs. This in itself is a problem as it
make debugging rather unpleasant. I think there was the same issue
when I reported the regression.

You can invoke the test by cd into the unpacked directory and running ./abcl.
The expected behavior is that a swing window comes up with a list of entries.
You should be able to select the first and click on the "3" button and
another window will come up.

There are two versions of abcl included in the tarball. abcl.jar is
the version I am using for development.
abcl-svn.jar is the one I just build from source.

The ./abcl script needs to be edited to run one or the other.
Don't forget to remove all the fasls between runs.

http://ashby.csail.mit.edu/test-abcl.tgz

Thanks for any effort you put into this.

-Alan


On Fri, Oct 16, 2009 at 6:46 AM, Alan Ruttenberg
<alanruttenberg@...> wrote:
> Thanks for the offer! I will try to do that.
> -Alan
>
> On Fri, Oct 16, 2009 at 7:36 AM, Mark Evenson <evenson@...> wrote:
>> On 10/15/09 2:21 PM, Alan Ruttenberg wrote:
>> […]
>>>> On Thu, Oct 15, 2009 at 5:53 AM, Alan Ruttenberg
>>>> <alanruttenberg@...>  wrote:
>>>>> I'm sorry about this bug report. Basically, a system I've been working
>>>>> with for a long time has ceased to function in odd ways.
>>
>> […]
>>
>>>>
>>>> Could you provide a bit more information on what the code is doing?
>>>>
>>>>> Unfortunately working on isolating the bug isn't something I have time
>>>>> for so I've had to revert back to an earlier version.
>>
>> Alan,
>>
>> Are we talking about your subsumption of Pellet under [LSW][1]?  If it
>> is easier for you, maybe you could provide a failing test case under
>> that software as I emulated the basic principles (i.e. "use JSS!") from
>> LSW a couple years ago for my own reasoner wrapper a couple years ago,
>> so I am pretty confidant that I could reproduce a failing test case
>> involving LSW in short order.
>>
>> [1]: http://mumble.net:8080/svn/lsw/trunk/
>>
>> --
>> "A screaming comes across the sky.  It has happened before, but there
>> is nothing to compare to it now."
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> armedbear-j-devel mailing list
>> armedbear-j-devel@...
>> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
>>
>

Re: [j-devel] regression From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-06 14:38 Hi Mark, I've debugged the problems, sent email to the list, and worked around them for the moment, so no need to investigate this. Thanks for the offer, though! -Alan On Fri, Jan 1, 2010 at 5:00 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > I have created a tarball that should let you test my code. > > With the current svn abcl I don't see the same behavior as last time > (good news) - this time it looks like a compilation problem - if the > functions where the errors occur are evaluated instead of compiled it > runs. > > However it should also be noted that if I am running under slime it > takes quite a long time for the debugger to be invoked - 5 to 10 > seconds - on the error that occurs. This in itself is a problem as it > make debugging rather unpleasant. I think there was the same issue > when I reported the regression. > > You can invoke the test by cd into the unpacked directory and running ./abcl. > The expected behavior is that a swing window comes up with a list of entries. > You should be able to select the first and click on the "3" button and > another window will come up. > > There are two versions of abcl included in the tarball. abcl.jar is > the version I am using for development. > abcl-svn.jar is the one I just build from source. > > The ./abcl script needs to be edited to run one or the other. > Don't forget to remove all the fasls between runs. > > http://ashby.csail.mit.edu/test-abcl.tgz > > Thanks for any effort you put into this. > > -Alan > > > On Fri, Oct 16, 2009 at 6:46 AM, Alan Ruttenberg > <alanruttenberg@...> wrote: >> Thanks for the offer! I will try to do that. >> -Alan >> >> On Fri, Oct 16, 2009 at 7:36 AM, Mark Evenson <evenson@...> wrote: >>> On 10/15/09 2:21 PM, Alan Ruttenberg wrote: >>> […] >>>>> On Thu, Oct 15, 2009 at 5:53 AM, Alan Ruttenberg >>>>> <alanruttenberg@...>  wrote: >>>>>> I'm sorry about this bug report. Basically, a system I've been working >>>>>> with for a long time has ceased to function in odd ways. >>> >>> […] >>> >>>>> >>>>> Could you provide a bit more information on what the code is doing? >>>>> >>>>>> Unfortunately working on isolating the bug isn't something I have time >>>>>> for so I've had to revert back to an earlier version. >>> >>> Alan, >>> >>> Are we talking about your subsumption of Pellet under [LSW][1]?  If it >>> is easier for you, maybe you could provide a failing test case under >>> that software as I emulated the basic principles (i.e. "use JSS!") from >>> LSW a couple years ago for my own reasoner wrapper a couple years ago, >>> so I am pretty confidant that I could reproduce a failing test case >>> involving LSW in short order. >>> >>> [1]: http://mumble.net:8080/svn/lsw/trunk/ >>> >>> -- >>> "A screaming comes across the sky.  It has happened before, but there >>> is nothing to compare to it now." >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> armedbear-j-devel mailing list >>> armedbear-j-devel@... >>> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel >>> >> >

Re: [j-devel] regression From: Mark Evenson <evenson@pa...> - 2010-01-06 14:40 On 1/6/10 3:38 PM, Alan Ruttenberg wrote: > Hi Mark, > > I've debugged the problems, sent email to the list, and worked around > them for the moment, so no need to investigate this. Thanks for the > offer, though! > Great! I've been following your mails, and will try to make sure that your patch makes it into the upcoming abcl-0.18. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

Re: [j-devel] regression From: Alan Ruttenberg <alanruttenberg@gm...> - 2010-01-06 14:49 On Wed, Jan 6, 2010 at 9:39 AM, Mark Evenson <evenson@...> wrote: > On 1/6/10 3:38 PM, Alan Ruttenberg wrote: >> >> Hi Mark, >> >> I've debugged the problems, sent email to the list, and worked around >> them for the moment, so no need to investigate this. Thanks for the >> offer, though! >> > > Great! I've been following your mails, and will try to make sure that your > patch makes it into the upcoming abcl-0.18. Thanks! I didn't have a patch for the symbol macrolet bug - someone will have to figure out what's with that, but avoided the issue by changing jss to use gensymed argument lists for its generated functions. Regards, Alan > > > -- > "A screaming comes across the sky.  It has happened before, but there > is nothing to compare to it now." >

On Sun, Nov 15, 2009 at 6:26 PM, Dr. Thomas Sturm <sturm@...> wrote:
> Hi,
>
> I am experimenting with bootstrapping the computer algebra system Reduce on ABCL. I now have encountered a problem, which might be a bug in the ABCL compiler. I give a simplified version of my situation.
>
> (compile-file "test") where test.lisp has the following content does not terminate:
>
> (defparameter single-character-symbols
>  '#.(let ((a (make-array 129)))
>       (dotimes (i 129)
>         (setf (svref a i) (make-string 1 :initial-element (code-char i))))
>       a))
>
> When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256.
>
> If this is really a bug, I would be grateful for any hint on a possible workaround.

Well, I finally got around to checking this issue: you indeed
identified a bug. Unfortunately it's not easy to work around, because
it has to do with the fact that your output encoding doesn't seem to
support the specific character (character 0x80, that is).

The weird thing is that the strategy is to replace characters that
can't be encoded, so there's a big question mark here as to why this
error occurs. Anyway, we have a new interesting test case to add to
the tests for our RandomAccessCharacterFile class.

Locally, I patched ABCL to create UTF-8 output files, but that would
require you to patch the Load part of ABCL to read UTF-8 input as
well. Since I can't really do that as simple as that, I can't fix it
right now. However, if you're fine using UTF-8 for input for LOAD, I
could provide you with a patch.


Bye,

Erik.

Re: [j-devel] Compilation Problem in ABCL 0.17 From: Erik Huelsmann <ehuels@gm...> - 2010-01-04 10:36 Hi Thomas, >> (compile-file "test") where test.lisp has the following content does not terminate: >> >> (defparameter single-character-symbols >>  '#.(let ((a (make-array 129))) >>       (dotimes (i 129) >>         (setf (svref a i) (make-string 1 :initial-element (code-char i)))) >>       a)) >> >> When replacing 129 by 128 everything is fine. The size that I actually would like to have there is 256. >> >> If this is really a bug, I would be grateful for any hint on a possible workaround. As stated before, there's no workaround; however, I have a local patch which will be included in 0.18 (scheduled to be released this month) which completely cures the problem: FASLs should support all characters that can be constructed in-memory, meaning they should be any kind of encoded unicode. I chose UTF-8, because I expect our FASLs to be mostly ASCII, in which case UTF-8 is an efficient encoding. > Well, I finally got around to checking this issue: you indeed > identified a bug. Unfortunately it's not easy to work around, because > it has to do with the fact that your output encoding doesn't seem to > support the specific character (character 0x80, that is). > > The weird thing is that the strategy is to replace characters that > can't be encoded, so there's a big question mark here as to why this > error occurs. Anyway, we have a new interesting test case to add to > the tests for our RandomAccessCharacterFile class. I found the issue: when *en*coding, we don't replace. When decoding (ie. reading existing data) we *do* replace. Replacing on encoding would destroy data integrity. That's why we chose not to do it. However, it generates errors now in case a character can't be encoded. > Locally, I patched ABCL to create UTF-8 output files, but that would > require you to patch the Load part of ABCL to read UTF-8 input as > well. Since I can't really do that as simple as that, I can't fix it > right now. However, if you're fine using UTF-8 for input for LOAD, I > could provide you with a patch. Above mentioned patch does exactly this: set the encoding on the stream loaded from to UTF-8. I expect this patch to be committed this week. I hope that addresses your problem. With kind regards, Erik.

Re: [j-devel] Compilation Problem in ABCL 0.17 From: Erik Huelsmann <ehuels@gm...> - 2010-01-04 22:17 Just to keep you up to date: > Above mentioned patch does exactly this: set the encoding on the > stream loaded from to UTF-8. I expect this patch to be committed this > week. I hope that addresses your problem. I had some time to add the required code comments and optimizations today. I tested it the way I usually do. The fix is now in the development version of ABCL; if you want to test it, please check out the latest version of trunk/ Bye, Erik.

Hi, ABCL developers

I found ABCL's DEFUN cannot handle keyword arguments well when the argument itself is a keyword symbol:

Consider this function definition:

(defun socket-connect (host port &key (protocol :stream))
  (list host port protocol))

I got this in latest ABCL (built from SVN):

CL-USER(15): (socket-connect 1 2 :xxx)
Debugger invoked on condition of type PROGRAM-ERROR:
  Odd number of keyword arguments.
Restarts:
  0: TOP-LEVEL Return to top level.

I think ABCL's treating every keyword symbols as keyword arguments name, this is wrong. Don't know how to fix it, and this is a blocking issue when I'm porting UDP-enabled USOCKET into ABCL. Hope someone could look into this.

Regards,

Chun Tian (binghe)

Re: [j-devel] DEFUN keyword arguments bug in ABCL From: Chun Tian (binghe) <binghe.lisp@gm...> - 2009-12-12 21:24 Attachments: smime.p7s      Cancel this post ... I'm such stupid today 在 2009-12-13，02:26， Chun Tian (binghe) 写道： > Hi, ABCL developers > > I found ABCL's DEFUN cannot handle keyword arguments well when the argument itself is a keyword symbol: > > Consider this function definition: > > (defun socket-connect (host port &key (protocol :stream)) > (list host port protocol)) > > I got this in latest ABCL (built from SVN): > > CL-USER(15): (socket-connect 1 2 :xxx) > Debugger invoked on condition of type PROGRAM-ERROR: > Odd number of keyword arguments. > Restarts: > 0: TOP-LEVEL Return to top level. > > I think ABCL's treating every keyword symbols as keyword arguments name, this is wrong. Don't know how to fix it, and this is a blocking issue when I'm porting UDP-enabled USOCKET into ABCL. Hope someone could look into this. > > Regards, > > Chun Tian (binghe) >

3 messages have been excluded from this view by a project administrator.

Previous Messages

Next Messages