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

[armedbear-devel] Fwd: [armedbear-cvs] r13516 - svn:log
by Erik Huelsmann 20 Aug '11

20 Aug '11

Hi Alessio, Thanks for the read tables research last week. I went ahead and implemented a fix. Could you confirm the fix works for your testing? Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sat, Aug 20, 2011 at 12:06 PM Subject: [armedbear-cvs] r13516 - svn:log To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Revision: 13516 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1 +1,3 @@ -Fix #161: READTABLE-CASE setting of *readtable* affects FASL content. \ No newline at end of file +Fix #161: READTABLE-CASE setting of *readtable* affects FASL content. + +Note: Fix based on research by Alessio Stalla. \ No newline at end of file _______________________________________________ armedbear-cvs mailing list armedbear-cvs(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs

1 0

[armedbear-devel] type mismatch for "asList"
by Patrice Seyed 19 Aug '11

19 Aug '11

Hello, With the following expression: (#"asList" 'Arrays "test") I get the error: Java exception 'SchemeException: java.lang.IllegalArgumentException: argument type mismatch ARGUMENT MISMATCH for method public static java.util.List java.util.Arrays.asList(java.lang.Object[]) called with ("test")'. [Condition of type JAVA-EXCEPTION] But "test" is of java.lang.String, which is a subclass of java.lang.Object, so I'm not sure what the mismatch is. Any help appreciated. Patrice

2 1

[armedbear-devel] Using ABCL in Android
by Joe Mendoza 18 Aug '11

18 Aug '11

To ABCL developers, I tried to use the java to lisp interpreter in Android, however, I received an error message; "Could not find method java.beans.Introspector.getBeanInfo, referenced from method org.armedbear.lisp.Java.getPropertyDescriptor". I've learned that Android doesn't support the use of Java beans. Would there be another way to compile ABCL without implementing Java beans? Thanks, Joe

3 4

[armedbear-devel] anonymous inner class in abcl
by Patrice Seyed 17 Aug '11

17 Aug '11

Right, Hello abcl developers, Let's say I want to implement an anonymous inner class, just for example ActionListener with method actionPerformed: JButton button = new JButton("Enter"); button.addActionListener(new ActionListener (){ public void actionPerformed(ActionEvent e){ System.out.println("The Enter button was pressed"); } }); What is the best way to do this in abcl? Cheers, Patrice On Tue, Aug 16, 2011 at 4:09 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com>wrote: > > > On Tue, Aug 16, 2011 at 3:55 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: > >> How about a boolean? >> > > (make-immediate-object nil :boolean) > (make-immediate-object t :boolean) > > >> Next, I'm trying to work my way up to defining anonymous inner classes >> from within abcl. >> > > That's a bit more problematic, at least for me. > Can you write up a specific small code example you want to implement and > send a note the armedbear-devel(a)common-lisp.net asking for what the > recommended approach would be? > > -Alan > > > >> >> Patrice >> >> On Mon, Aug 15, 2011 at 5:53 PM, Alan Ruttenberg < >> alanruttenberg(a)gmail.com> wrote: >> >>> null = (make-immediate-object nil :ref) >>> >>> On Mon, Aug 15, 2011 at 4:06 PM, Patrice Seyed <apseyed(a)gmail.com> >>> wrote: >>> > Alan, >>> > >>> > If I wanted to pass as an argument that I would specify as null in >>> > java, from abcl to java, how would I do that? >>> > >>> > For example a method called method1 that takes two argument that I >>> > want to pass a string and the second argument null: >>> > >>> > (#"method1" 'ClassName "string" nil) >>> > >>> > If I specify nil as i did here I get a java exception "argument type >>> mismatch". >>> > >>> > Patrice >>> > >>> >> >> >

3 2

Re: [armedbear-devel] lsw2
by Alan Ruttenberg 17 Aug '11

17 Aug '11

On Tue, Aug 16, 2011 at 3:55 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: > How about a boolean? > (make-immediate-object nil :boolean) (make-immediate-object t :boolean) > Next, I'm trying to work my way up to defining anonymous inner classes from > within abcl. > That's a bit more problematic, at least for me. Can you write up a specific small code example you want to implement and send a note the armedbear-devel(a)common-lisp.net asking for what the recommended approach would be? -Alan > > Patrice > > On Mon, Aug 15, 2011 at 5:53 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com > > wrote: > >> null = (make-immediate-object nil :ref) >> >> On Mon, Aug 15, 2011 at 4:06 PM, Patrice Seyed <apseyed(a)gmail.com> wrote: >> > Alan, >> > >> > If I wanted to pass as an argument that I would specify as null in >> > java, from abcl to java, how would I do that? >> > >> > For example a method called method1 that takes two argument that I >> > want to pass a string and the second argument null: >> > >> > (#"method1" 'ClassName "string" nil) >> > >> > If I specify nil as i did here I get a java exception "argument type >> mismatch". >> > >> > Patrice >> > >> > >

2 1

[armedbear-devel] readtable-case :invert does not invert uninterned symbols
by Ole Arndt 16 Aug '11

16 Aug '11

This prevents loading a newer parenscript, which uses an inverted readtable case via named-readtables: Armed Bear Common Lisp 0.26.0-dev-svn-13273 Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.712 seconds. Startup completed in 3.154 seconds. Type ":help" for a list of available commands. CL-USER(1): (setf (readtable-case *readtable*) :invert) :invert CL-USER(2): (string :cl) "CL" CL-USER(3): (string '#:cl) "cl" Cheers Ole -- Ole Arndt http://www.sugarshark.com

3 5

[armedbear-devel] Refactoring compile-file.lisp
by Erik Huelsmann 14 Aug '11

14 Aug '11

Yesterday while refactoring compiler-pass2 I found that moving a function from the top of the file to the bottom can cause serious performance degradation (and performance win, the other way around). That somehow doesn't feel like what one would expect of a good enough compiler these days. To see if I can create a change to our file-compiler which doesn't exhibit this issue, I'm preparing an experiment where COMPILE-FILE will batch up all class files to be generated until the end of the processing of the input file. Then, all functions will be known in advance and calling functions being forward-referenced should have the same properties as calling backward referenced functions. In order to be able to even start working on the above, compile-file.lisp should at least be readable and understandable. My refactoring of today is in preparation of the experiment (which I could conduct on a branch), to clean up compile-file.lisp and cut it down to readable chunks of code with well-defined calling conventions. Just thought I'd explain my current work on compile-file.lisp. Bye, Erik.

1 0

[armedbear-devel] Bad Windows regression fixed; time for abcl-0.26.2?
by Mark Evenson 11 Aug '11

11 Aug '11

Today, [I fixed a bad bug in which fasls with whitespace in their path under Windows were failing to load][13460]. Given how common whitespace in pathnames under Windows should be, I would suggest that we should make an abcl-0.26.2 release in the next week or so. Maybe we can use this as an exercise for someone other than Erik to make a release (namely me)? I think Erik has signed my PGP key at this point, although I haven't checked. [13460]: http://trac.common-lisp.net/armedbear/changeset/13460 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Fwd: [armedbear-cvs] r13450 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 07 Aug '11

07 Aug '11

Hi Mark, Maybe you want to check if CL-CONTAINERS now wants to load? At least we now support SETF of APPLY with user-defined functions. And, yes, I did check that the order of evaluation of the arguments remains in tact: (defvar b 0) --> B (defun m () (incf b)) --> M (defvar v nil) -->V (defun (SETF MYFUN) (new-value &rest rest) (setf v new-value)) --> (SETF MYFUN) (setf (apply #'myfun (list (m) (m) (m))) (m)) --> 4 Bye, Erik. ---------- Forwarded message ---------- From: <ehuelsmann(a)common-lisp.net> Date: Sun, Aug 7, 2011 at 10:18 PM Subject: [armedbear-cvs] r13450 - trunk/abcl/src/org/armedbear/lisp To: armedbear-cvs(a)common-lisp.net Author: ehuelsmann Date: Sun Aug 7 13:17:59 2011 New Revision: 13450 Log: Fix #141 (SETF of APPLY not working with arbitrary function) by "adding" the feature. Modified: trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Modified: trunk/abcl/src/org/armedbear/lisp/late-setf.lisp ============================================================================== --- trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Sun Aug 7 07:20:58 2011 (r13449) +++ trunk/abcl/src/org/armedbear/lisp/late-setf.lisp Sun Aug 7 13:17:59 2011 (r13450) @@ -88,11 +88,6 @@ `(getf ,get ,ptemp ,@(if default `(,def-temp))))))) (define-setf-expander apply (functionoid &rest args) - (unless (and (listp functionoid) - (= (length functionoid) 2) - (eq (first functionoid) 'function) - (memq (second functionoid) '(aref bit sbit))) - (error "SETF of APPLY is only defined for #'AREF, #'BIT and #'SBIT.")) (let ((function (second functionoid)) (new-var (gensym)) (vars (make-gensym-list (length args)))) _______________________________________________ armedbear-cvs mailing list armedbear-cvs(a)common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs

1 0

[armedbear-devel] Building support for inspection of local variables in (compiled) code
by Erik Huelsmann 07 Aug '11

07 Aug '11

This summer, Mark and I met in person. We discussed several things, we wanted to improve on ABCL. One of the most important things to improve on ABCL, or so it seems to us, is to be able to inspect - given high enough debug settings - the locals in the current stackframe. Since I have had a good idea how to do this for a long time now, I'm writing down how I want to do it, making it work for both compiled and interpreted functions. The basic requirements are simple: while walking the stack, being able to focus on any single frame and retrieving the locals from it, as well as their values for inspection, of course. Being able to STEP code isn't a requirement - although that may be subject to another change later. My idea is really actually very simple. We already have an interpreter which creates Environment objects to record the lexical variables and their values (as well as temporary "specialness"). The missing bit is the link between the environment and the stack frame. Note that within the scope of a single stack frame, multiple environments may be cycled through, one after another. This typically happens with new binding blocks such as DO/DO*, LET/LET*, M-V-B, etc. Since this information is all readily available, I'm envisioning a method on LispThread which sets the environment of the current stack frame. Then, when the debugger is invoked, the environment object of the stack frame to be inspected can be retrieved and the bindings referred to it can be walked to print the state of the lexical environment. The impact of this change is relatively limited: everywhere we find a "new Environment", we want to review if adding the environment to the stackframe is applicable. So far so good. Now about compiled code. It doesn't have Environment objects, because the environment is hard coded into the compiled functions. If we were to step away from that concept, we might as well completely stop compiling the program. So now what? I see a middle road: values reachable through an Environment are stored in a linked list of Binding objects. We could create these Binding objects, adding them to the environment, but still keeping a reference to them. Then, our performance would only suffer a single additional level of indirection. The thing to be figured out would be how to 'model' closures. The environment model works well with closures in interpreted mode, but with this 'faked' environment it works less well. One solution would be to add the closure variables to the Environment upon function entry. That might cost some performance, but would require no access to the outer Environment. Other solutions - which I haven't evaluated yet - might involve the array of ClosureBindings, which is a way to carry information from one closure to another. Comments? Bye, Erik.

1 0