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

[armedbear-devel] Why field LispStatckFrame.UNAVAILABLE_ARG is not static ?
by Dmitry Nadezhin 08 Apr '15

08 Apr '15

Memory profiling of ABCL shows that the classes with largest allocation count are LispStackFrame and LispStackFrame.UnavailableArgument . It seems to me that LispStatckFrame.UNAVAILABLE_ARG can be a singleton object, can't it ? =================================================================== --- LispStackFrame.java (revision 14571) +++ LispStackFrame.java (working copy) @@ -44,7 +44,7 @@ private final LispObject third; private final LispObject[] args; - private final class UnavailableArgument extends LispObject + private static final class UnavailableArgument extends LispObject { public UnavailableArgument () { } @Override @@ -53,7 +53,7 @@ } } - private final LispObject UNAVAILABLE_ARG = new UnavailableArgument(); + private static final LispObject UNAVAILABLE_ARG = new UnavailableArgument(); public LispStackFrame(LispObject operator) { ====================================================================

2 1

[armedbear-devel] Fwd: One-jar
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Howdy, I was wondering whether anyone had tried to use this with ABCL. Looks like a nice packaging solution but I'm not sure how it would interact with ABCL's classloader (yes I can try :) ) -Alan ---------- Forwarded message ---------- From: Blaisure, Jonathan <jcblaisu(a)buffalo.edu> Date: Wed, Nov 13, 2013 at 9:12 AM Subject: One-jar To: Alan Ruttenberg <alanruttenberg(a)gmail.com> http://one-jar.sourceforge.net/ Might be useful. -- Regards, Jonathan Blaisure, MS ---------------------- *Database Administrator* *Institute for Health care Informatics* 716.878.2996

3 3

[armedbear-devel] Lazy allocation of LispStackFrames
by Dmitry Nadezhin 08 Apr '15

08 Apr '15

LispStackFrame object are allocated on every LispThread.execute(...) . However, they are seldom (to inspect stack trace). This patch delays allocation of LispStackFrame objects until they are requested. Raw information about stack frames is stored in stack. Stack is an Object[] array ( more precisely a list of 8 MB Object[] arrays ).

3 3

[armedbear-devel] Pdfdoclet - Javadoc for ABCL in PDF format
by Sean Champ 08 Apr '15

08 Apr '15

Hello! In brief: Attached is a shell script for running pdfdoclet[6], a Javadoc doclet component that generates PDF format documentation, instead of HTML, when used with the javadoc tool. For sake of convenience, I was going to send the PDF format ABCL javadoc generated by pdfdoclet, but the resulting PDF file is 13.3 megs in size. Maybe the little utility shell script, as attached, could be enough. The PDF javadoc could be useful, i think, in the interest of studying ABCL's Java API - perhaps more intermediately, for modeling ABCL's Java API in UML - for instance, using Modelio[1], Argo[2], or Papyrus[3], on the laptop, and Cubetto Mobile[4] on the tablet. As an additional plug: As far as the PDF format itself, and PDF's annotation support, typically on mobile, i tend to prefer Goodreader[5]. It offers good support for PDF annotations and so on. PDFDoclet can also be used from Ant. I'm not very well familiar with Ant, offhand. Of course, I notice that Ant is used in ABCL - will take a look... Cheers! [1] http://www.modeliosoft.com/ [2] http://argouml.tigris.org/ [3] http://www.eclipse.org/papyrus/ [4] http://www.semture.de/en/cubetto-mobile-en/overview [5] http://www.goodiware.com/goodreader.html [6] http://pdfdoclet.sourceforge.net/ <http://pdfdoclet.sourceforge.net/><http://www.semture.de/en/cubetto-mobile-en/overview><http://www.eclipse.org/papyrus/>

2 1

[armedbear-devel] mvn snapshots
by Cyrus Harmon 08 Apr '15

08 Apr '15

The attached patch adds support for maven snapshot versions with the following defsystem component syntax: (:mvn "org.openscience.cdk/cdk-bundle" :version "1.5.6" :snapshot t) I’m open to other suggestions to solving this, but this works for my immediate needs. thanks, Cyrus

3 8

[armedbear-devel] Re: What are you working on?
by Rolando Pereira 08 Apr '15

08 Apr '15

ubikation _ <ubikation-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> writes: > What projects are people working on using ABCL? If they are > open-source, would you mind sharing a link to the repository? Since the lack of answers is slightly disappointing I guess I can post something regarding an experiment I did an afternoon a couple months ago which tried to link Jython to ABCL. Since it was an experiment I didn't put the source code online. Also currently the source is basically just a "*slime-scratch*" buffer saved to a file which means that the code is a hairy mess. But here's an example to show how to use it: > (add-to-classpath "/home/rolando/src/jython/jython-standalone-2.5.3.jar") > (defvar *interpreter* (jss:new 'org.python.util.PythonInterpreter)) > > (#"exec" *interpreter* "import feedparser") > > (defvar *rss-parse* (gethash "parse" > (py-unwrap (#"getDict" > (gethash "feedparser" > (py-unwrap (#"getLocals" *interpreter*))))))) > > ;; Get the ABCL mailing list RSS > (defvar *rss* (pycall *rss-parse* "http://rss.gmane.org/gmane.lisp.armedbear.devel")) Having defined the "*rss*" variable you can then do this: > CL-USER> (gethash "title" (nth 1 (gethash "entries" (py-unwrap *rss*)))) > "Web frameworks with ABCL (was Re: SBCL->ABCL migration questions)" > T Something I wanted to make was importing the Python modules as Lisp functions so instead of defining the "*rss-parse*" as > (defvar *rss-parse* (gethash "parse" > (py-unwrap (#"getDict" > (gethash "feedparser" > (py-unwrap (#"getLocals" *interpreter*))))))) you could do: > (feedparser:parse "http://rss.gmane.org/gmane.lisp.armedbear.devel") and that would also allow you slime's autocomplete to complete the python code. I've thought about doing the above using a macro around the "inspect" Python module, but never got around to it. Best Regards, Rolando Pereira

1 0

[armedbear-devel] MQTT example using ABCL and Eclipse Paho
by Frederico Munoz 08 Apr '15

08 Apr '15

Hi all, I have written a simple example of using the Eclipse Paho libraries, via ABCL, to send messages in Common Lisp using MQTT. I will not write much more here since it's in the article which contains the code and some other considerations: http://finisterra.motd.org/?p=237 As I note I initially did this in Clojure so - and just like my experiments with Swing before which I sent to the list as well - this is in a way a comparison on how the interop facilities work. My code is not exactly stellar (either the Clojure or the CL one) but it is, I hope, easy enough to understand and follow, especially since I couldn't found any other example out there, which is why I thought the list could have some use for it (even if only for future reference). I stumbled a bit on getting the command-line arguments but that was due to my custom-made abcl script end with $@ instead of "@" - something to watch for :) I had one problem that I found weird and which I would welcome any help, I'm not sure why the following works: CL-USER(3): (#"currentThread" 'Thread) #<java.lang.Thread Thread[interpreter,5,main] {BD30B16}> ... but the following doesn't: CL-USER(4): (#"sleep" 'Thread 100) #<THREAD "interpreter" {19AA4D78}>: Debugger invoked on condition of type ERROR no such method Restarts: 0: TOP-LEVEL Return to top level. For another short demo I have I will need to subclass, something used in Swing programming a lot from what I could understand. If I'm not mistaken this isn't currently supported in ABCL, but I will read on it. Best regards, Frederico

3 3

[armedbear-devel] Java 6+ Type-checking bytecode verifier compatible output: requirements analysis
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi all, At ECLM the other week, Alessio and I agreed to start working on a requirements analysis regarding the output required for the type-checking bytecode verifier. We know Mark wants to create an intermediate level code representation to address any issues that may arise. However, we want to assess requirements first and come up with a solution after that. That solution may or may not depend on such an intermediate representation. For now, we'd like to leave that undecided. So, what I learned that the type-checking bytecode verifier wants is that it can verify the state of the stack and of the locals for all bytecode instructions. In order to do so, it needs: 1. The "initial state" of stack and locals at the external entry points of a function (ie notably the start and any exception handlers) 2. Optional "state modifications" when locals start being used or when the flow from one instruction to another is broken (such as in case of (conditional) jumps) Apart from a different class file version number and an attribute to store this information in, that's it. More doesn't the verifier want to know. Is it your understanding as well that this is all that is required? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

[armedbear-devel] c++ library FreeLing from ABCL
by Alexandre Rademaker 08 Apr '15

08 Apr '15

I am trying to use a C++ library called FreeLing from ABCL (using the library JAVA API). I have just posted a question in http://stackoverflow.com/questions/17556912/calling-freeling-java-api-from- abcl. Does anyone know of any limitation of ABCL to deal with the System.load of Java? Best, Alexandre

3 7

[armedbear-devel] Bug: COND clauses must have a test
by Pascal J. Bourguignon 08 Apr '15

08 Apr '15

The syntax for COND is: cond {clause}* => result* clause::= (test-form form*) therefore (cond ()) should be a program-error, but abcl 1.0.1 returns NIL. -- __Pascal Bourguignon__ http://www.informatimago.com/

2 1