Robert Dodier | 9 Dec 23:06 2014
Picon

[Armedbear-devel] How to get a fresh session or instance

Hi, is there a way to get a fresh session or instance of ABCL, short
of reloading all the classes? Ideally I'd like to be able to have
two or more instances which exist at the same time and are independent
of each other.

I believe the answer to this question is "no", but I just want to make
sure I am not overlooking something. If indeed it's not possible now,
what would it take to make it happen? I see there is a certain amount
of static data -- would it be necessary to replace that with
(just for the sake of discussion) a hash table which takes a session
or instance id as a key?

Any thoughts on this topic will be appreciated.

best,

Robert Dodier
Didier Verna | 5 Dec 08:24 2014
Face
Picon
Picon
Picon
Picon

[Armedbear-devel] [CfP] ELS 2015, 8th European Lisp Symposium, Apr. 20-21, London


		 ELS'15 - 8th European Lisp Symposium
		    Goldsmiths College, London, UK

			  April 20-21, 2015

	       http://www.european-lisp-symposium.org/

	  Sponsored by EPITA, Franz Inc. and Lispworks Ltd.

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.

The 8th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
(Continue reading)

Robert Dodier | 5 Dec 02:59 2014
Picon

[Armedbear-devel] Having trouble with ASDF-JAR

Hi, I'm trying ASDF-JAR again. I'm working with the svn trunk (current
revision 14736). Here's what I get:

    CL-USER(1): (require 'asdf)
    ("uiop" "UIOP" "asdf" "ASDF")
    CL-USER(2): (require 'abcl-contrib)
    Using probed value of abcl-contrib:
    'NIL'.
    ("ABCL-CONTRIB")
    CL-USER(3): (require 'asdf-jar)
    #<THREAD "interpreter" {13AD88B}>: Debugger invoked on condition of type SIMPLE-ERROR
      Don't know how to REQUIRE ASDF-JAR.

I guess I'm doing something wrong?

Thanks for your help,

Robert Dodier
Robert P. Goldman | 2 Dec 17:19 2014

[Armedbear-devel] Installing ABCL?

Sorry if this is a stupid question, but is there a way to install ABCL
in the standard sort of location (e.g., /usr/local/bin and
/usr/local/lib, etc.)?

I see that there's a copy of install-sh in the ABCL source, but I don't
see a way to invoke it.  I looked with

find . \( -name '.git' -prune \) -o -type f -exec fgrep -q install-sh {}
\; -print

but didn't find anything.

I have lots of bleeding edge lisp implementations because of needing to
test ASDF, so was looking to figure out how to install using GNU stow
for easy rebuilding and testing.

[sorry if this is all handled by some Java thing like ant that I don't
understand.]

thanks,
r
Mark Evenson | 2 Dec 16:34 2014
Picon

Re: [Armedbear-devel] ABCL and RMI


> On 02 Dec 2014, at 16:24, Robert Goldman <rpgoldman <at> sift.net> wrote:

[…]

> I think this is a false alarm.  Looks like the oddity comes from
> jvisualvm.  Sorry about that.  Looks like it was a Heisenbug.
> 
> I was debugging a search routine where I first wrote the heuristic class
> in ABCL, then hand-compiled to Java when it was working.
> 
> Bug was not ABCL, but rather seems to be in the underlying search routine.
> 
> Thanks everyone for the help.  I'm a newcomer to the Java platform.
> ABCL helps with this, but I'm still prone to stupid errors.

I am glad to hear things are working out as I am (mostly) always happy to be a
[rubber duck][1] for ABCL usage.

[1]: http://en.wikipedia.org/wiki/Rubber_duck_debugging

--

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."

_______________________________________________
Armedbear-devel mailing list
Armedbear-devel <at> common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
(Continue reading)

Mark Evenson | 2 Dec 09:29 2014
Picon

Re: [Armedbear-devel] ABCL and RMI

On 11/28/14 21:24, Robert Goldman wrote:
> Mark Evenson wrote:

[…]
>> Any chance you can put the source up publicly for me to have a shot at running it? 
>>
> I probably could, but I don't know that you'd thank me.  PRISM is
> already huge, and with an idiosyncratic build process. Then adding ABCL
> to the mix makes a real gonkulator.
> 
> I'll have a quick whack at using Eclipse to profile first, and will
> report back.  If the oddity persists (and isn't just a weirdness of
> jvisualvm), I'll package up stuff so that you can see it.

I'm more of a Netbeans fan myself, but looking forward to the result of
your efforts.

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

_______________________________________________
Armedbear-devel mailing list
Armedbear-devel <at> common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
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)


Gmane