Robert Goldman | 25 Nov 21:55 2014
Picon

[Armedbear-devel] ABCL and RMI

I am trying to profile (using jvirtualvm) a program that I have compiled
ABCL into.  I'm using ABCL to script the application, and rapidly prototype
extensions.

The program is the PRISM model checker (http://www.prismmodelchecker.org/),
for anyone who is interested.

Oddly, I find that the profiler's call graph shows not just my top level
main() program as a root, but also multiple jobs running RMI TCP
connection.  These are all in the idle state, but seem to be chewing up a
lot of CPU.

There are 16 of these processes and an RMI thread scheduler.

Is there any way that ABCL could be causing this to happen?  I don't see
any use of RMI in the host PRISM program, but then I don't see it in ABCL,
either.
Robert Dodier | 15 Nov 07:34 2014
Picon

[Armedbear-devel] How to load compiled Lisp stuff from a jar

Hi, I think maybe this topic has been covered before but
I wonder what's the state of the art. I want to have a Java
program load a compiled Lisp program contained in a jar
so that I can then call functions in the Lisp code.

For the record, the program in question is Maxima.
Calling Lisp functions worked fine when the compiled code
was unpacked (i.e. just in a directory) but I seem to recall
it is not simply a matter of packing it into a jar.
Or is it? Thanks for any advice.

best,

Robert Dodier

PS. I apologize in advance for any gross misunderstanding on my part.
Robert Goldman | 4 Nov 15:37 2014
Picon

[Armedbear-devel] Access to private methods from ABCL?

Is there some way to find a private method and make it accessible, somewhat
like the way JSS can make a private field accessible?
Thanks!
Mark Evenson | 2 Sep 15:48 2014
Picon

[Armedbear-devel] Advancements in preparing ASDF system in ABCL for WAR

A notice for those interested in my recent work in deploying ABCL as a WAR
binary artifact of [an update to abcl-servlet][1], which is where I am
collecting my ideas on implementation in an open source form. 

After locating the ASDF ABCL-SERVLET/BUILD definition, one may 

	CL-USER> (abcl-servlet/prepare :hunchentoot) 

to create necessary packaging of Hunchentoot and its transitive ASDF
dependences to [<file:hunchentoot/build/web/asdf/≥][2] for merging into Java Servlet WAR
archives.  

I’ve got a 100 Mib deployment WAR out of this system that has been running in
production for six months now, but comments on how to generalise are welcome.

[1]: https://bitbucket.org/easye/abcl-servlet/commits/e3bf36e015f2b5168d3e1d3d547aa6d85373ce6b
[2]: https://bitbucket.org/easye/abcl-servlet/src/b0e7e5353d6c92a1990ed1bb5500be1bd919b341/src/lisp/prepare.lisp?at=default#cl-61

--

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."
Mark Evenson | 21 Aug 08:14 2014
Picon

[Armedbear-devel] Comments on Cyrus's proposal for JSS static calls

Erik asked me to comment on [Cyrus’s proposed patch][1] to extend JSS’s
SHARPSIGN-DOUBLE-QUOTE use in static method calls to accept a string as well as
a symbol to designate the object.

Unfortunately, changing JSS in the manner means that one can no longer use
SHARPSIGN-DOUBE-QUOTE on object descended from java.lang.String, for the
reasons described in the [JSS README][2]:

[…]
Static calls are possible as well with the #" macro, but the
first argument MUST BE A SYMBOL to distinguish 

     (#"getProperties" "java.lang.System")

from 

     (#"getProperties" 'java.lang.System)     

The first attempts to call a method on the java.lang.String object
with the contents "java.lang.System", which results in an error, while
the second invokes the static java.lang.System.getProperties() method.     
[…]

Other than perhaps for aesthetic reasons, is there some functionality that
using strings enables here?  To argue about preserving character case in
strings as opposed to the case folding implicit in symbols doesn’t seem to be
applicable, because JSS currently ignores case when searching for matching JVM
symbols.  In 2006, when I first understood the ignoring case bit of JSS, I was
a bit worried that there would be cases where this resulted in ambiguity and
errors, but in the ensuing years I have yet to run into a single problem with
(Continue reading)

Mark Evenson | 20 Aug 11:24 2014
Picon

[Armedbear-devel] Patches to CFFI for ABCL which passes all tests

I have consolidated all the hard work of Cyrus Harmon and Olof-Joachim Frahm
over the past six months into a [pull request to the CFFI on github][43] which
passes all CFFI tests with ABCL.

 <at> olof:  I couldn’t align your [commit entitled "Convert callback return value
if necessary”][1] with Cyrus’s latest version.  If you could take a look to
understand if this patch superseded by Cyrus’s work, or we should recover your
work in a different form, I would appreciate it.

Even though we are passing all the CFFI tests, 

   CL-USER> (drakma:http-request “https://google.com”) 

still times out with an error.  Always something further to fix…

All hail Cyrus and Olof!

[43]: https://github.com/cffi/cffi/pull/43
[1]: https://github.com/easye/cffi/commit/36012f655372217133b2a83fb3008380724cb373

--

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."
Eduardo Bellani | 17 Aug 22:37 2014
Picon

[Armedbear-devel] handling dependencies


Hello guys.

This is my first post on the list, and beg your forgiveness if this
question was already answered, but alas, my search-fu was incapable
of finding anything that could have helped me.

Here is my situation:

I am trying to build a servlet using ABCL. The servlet is a middleware
that will expose an API, consume JSON, and return JSON. I will also
store some data into a postgres RDBMS.

I've used the google-app-engine example as a basis to build a skeleton
of my app, with a Java class providing a proxy for the servlet. If I
don't use any dependencies on my project, everything runs ok. My
problem is that I have the following system descriptor:

(asdf:defsystem #:abcl-servlet
  :serial t
  :description "An example of a servlet using the ABCL stack."
  :author  "Eduardo Bellani <ebellani <at> gmail.com>"
  :license "Beerware v. 42"
  :depends-on (:jsown
               :postmodern)
  :components ((:module :src
                        :components ((:file "package")
                                     (:file "servlet-interface")))))

As you can see, I have some dependencies on my code. Dependencies
(Continue reading)

Mark Evenson | 6 Aug 09:55 2014
Picon

[Armedbear-devel] ASDF-3.1.3 on abcl trunk

[r14716][] contains asdf-3.1.3, which should not be functionally different from the previous
asdf-3.1.2.9 

[r14716]: http://abcl.org/trac/changeset/14716

--

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."
Robert P. Goldman | 3 Aug 21:22 2014

[Armedbear-devel] ASDF-announce email list is live again

Dear CL implementers and maintainers,

I apologize for the mass spam, but I am sending this out in order to
limit all further ASDF release spam.

Hans Huebner has kindly raised the ASDF-announce <at> common-lisp.net mailing
list from the dead.  See
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-announce
for more details.

Please either sign your list up for ASDF-announce, or appoint someone in
your maintenance community to subscribe.  In return, I undertake to keep
traffic to this mailing list to an absolute minimum.  Indeed, for the
moment, I will be turning on "emergency" moderation of all traffic, to
enforce this.

I plan to cease sending these mass emails upon ASDF releases, effective
immediately, so please do monitor the announcement list.

Best,
Robert
Robert P. Goldman | 24 Jul 18:53 2014

[Armedbear-devel] ASDF version 3.1.3 released: Important bug-fix release

Today I have released (with much help from Fare) ASDF 3.1.3.

We urge implementations that are currently shipping with 3.1.2 to move
forward to 3.1.3.  3.1.3 has no API incompatibilities that we know of,
and contains significant bug fixes.  Most significantly, 3.1.3 fixes
bugs that impede hot-upgrade from 3.1.2 to a later version of ASDF,
which is critical to ASDF development.  In addition, we have fixed
multiple bugs in ASDF system search caching, that impeded correct use of
restarts involving adding new systems to a running CL.

Regards,

Robert Goldman
Robert P. Goldman | 6 May 23:32 2014

[Armedbear-devel] ASDF 3.1.2 released

The release version of ASDF 3.1, version 3.1.2, has finally arrived.
It is loaded with bug-fixes, more portability (substantially better
support on Windows; several new lisp implementations), better
documentation (extensive revisions to the Texinfo manual), and new
convenience features such as PACKAGE-INFERRED-SYSTEMs.

We urge the maintainers of lisp implementations to move to version 3.1.2
directly, as it is clearly superior to its predecessors.  This is
especially true if you are currently bundling a pre-release version of ASDF.

For a list of changes, see the attached changelog.

Special thanks to Dave Cooper and Anton Vodonosov (alphabetically) for
testing support.  Thanks to all those who have participated in the
discussions on ASDF-devel for bug fixes, suggestions, and course
corrections.  Thanks to Pete Keller for proofreading this announcement;
any remaining errors are mine alone.

Although he is no longer the lead maintainer, François-René Rideau
(Fare), has continued to expend vast amounts of effort on ASDF, and
provided invaluable guidance to the code submitted by the rest of us.

The latest version of ASDF is available at the project website:
http://common-lisp.net/project/asdf/

Robert P. Goldman
ASDF maintainer-in-chief
cl-asdf (2:3.1.2-1) unstable; urgency=low
(Continue reading)


Gmane