armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #164: Cannot quit SLIME REPL
by Ville Voutilainen 22 Aug '11

22 Aug '11

On 22 August 2011 12:21, armedbear <armedbear-devel(a)common-lisp.net> wrote: > Further analysis reveals that ProcessingTerminated is a pure Java-side > construct so there is currently no way to hook in from Lisp, so that part > of the concern is unfounded. > Still, calling System.exit() seems really wrong. Need to reconsider the > reason under which ProcessingTerminated exception was introduced. Sounds like ext:exit has been converted to do ProcessingTerminated, but it shouldn't actually do that. This strongly suggests that too much has been changed over to ProcessingTerminated; the original reason for converting some uses over is still valid, because in order to work as a library, abcl should avoid exitting.

3 5

Re: [armedbear-devel] [armedbear-cvs] r13530 - trunk/abcl/src/org/armedbear/lisp
by Ville Voutilainen 22 Aug '11

22 Aug '11

On 22 August 2011 12:52, <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Mon Aug 22 02:52:28 2011 > New Revision: 13530 > > Log: > All LispThread objects can act on a ProcessingTerminated exception. > Without this modifications, threads created with the > THREADS:MAKE-THREADS cannot successfully call the EXT:QUIT or EXT:EXIT > functions. This prevented the SLIME quit implementation from > successfully quitting implementations. > Note that all threads can always execute a form like > (jstatic "exit" "java.lang.System" 0) > to uncermoniously exit the JVM, so there is nothing gained > security-wise by preventing threads from using the official Lisp > interfaces. > + catch (ProcessingTerminated e) { > + System.exit(e.getStatus()); > + } This looks.. ..unfortunate. We should not get into a situation where a LispThread catches this exception, the exception is supposed to be used for terminating the repl if it can't load. It's fine as a stopgap measure, but exit requests from threads shouldn't end up throwing that exception.

1 0

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel