armedbear-devel August 2009

armedbear-devel@common-lisp.net

14 participants
16 discussions

[armedbear-devel] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[armedbear-devel] [BUG] EXT:ARGLIST produces bogus case-sensitive arglists
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

`arglist' in `arglist.java' calls `readObjectFromString' which uses the FASL Readtable which is case sensitive. This ain't good because this way the lambda-list keywords (&OPTIONAL etc.) are not properly read back (EXTENSIONS:|&optional|) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] [PATCH] incorporating java stack frames into backtrace
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

When evaluating (ext:make-thread #'(lambda ())) you get an error "The value NIL is not of type STRING." -- this is a bug in ABCL itself, by the way, but that's not the matter of this mail. The concern of this mail is the backtrace that'd you get: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 2: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 3: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) ... The only thing the backtrace reveales is that the error was signalled somewhere in MAKE-THREAD. With the patch of this mail, the backtrace will also contain the relevant Java stack frames for errors that were signalled from within ABCL's Java runtime: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.getStringValue(LispObject.java:1061) 4: org.armedbear.lisp.LispThread.<init>(LispThread.java:111) 5: org.armedbear.lisp.LispThread.<init>(LispThread.java:39) 6: org.armedbear.lisp.LispThread$3.execute(LispThread.java:909) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:108) 8: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 9: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 10: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) Another example: (LENGTH 12) Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {814AF5}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.length(LispObject.java:403) 4: org.armedbear.lisp.LispObject.LENGTH(LispObject.java:410) 5: org.armedbear.lisp.Primitives$24.execute(Primitives.java:427) 6: (LENGTH 12) 7: (SYSTEM::%EVAL (LENGTH 12)) 8: (EVAL (LENGTH 12)) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

4 18

[armedbear-devel] [OT] best way to structure and deploy a project
by Alessio Stalla 09 Sep '09

09 Sep '09

Hello everyone, I have a question which is not exactly pertinent with the development of ABCL, but which imho can start a useful discussion. Please forgive me if this is too OT. I have a project with sources in two languages, Java and Lisp. It is an Eclipse project, but the IDE does not make difference. The project is a library, not an end-user application. Currently it is structured as follows: src/java - Java source code src/lisp - Lisp source code lib/ - third-party libraries, both Java (jars) and Lisp (directories). The Java code is compiled by the IDE and put in an output directory. The Lisp source files are treated by the IDE as normal, non-source files, and copied verbatim into the same ouput folder as the Java classes. When I run the project from the IDE, I launch a class which compiles and loads the Lisp systems using asdf. This works for me locally, but thinking about distributing the project to users, this approach has some drawbacks: - Lisp files must be true files, they can't be in a Jar (asdf doesn't understand jars). - Lisp files are recompiled every time, since the IDE always overwrites the Lisp source files in the output directory. - If I make a jar, it will contain Lisp source files, not binaries, since binaries are unknown to the IDE. Ideally I'd like to do what ABCL does, i.e. create one big jar containing .class files and compiled Lisp files. Lisp sources could be compiled by the IDE or by a script, I don't care. Still, I would like to maintain the use of asdf (since some of my dependencies use it and loading them manually is too much of a hassle). I don't know how I can do this. I have also thought about leaving everything as-is, and when I'll distribute the library as a jar, have it extract at runtime the Lisp source files from the jar in a temporary directory and instruct asdf to search for systems in that directory. I will also need the lib/ folder to be in a known place, since asdf has to load stuff from there too (but this is less of a problem since I can make the library user configure that place, and use a sensible default otherwise). I am wondering if a cleaner approach exists, and if someone has experience in this regard. Cheers, Alessio

7 19

[armedbear-devel] eol-style problem with abcl-src-0.15.tar.gz
by Mark Evenson 01 Sep '09

01 Sep '09

Somehow we seemed to have shipped [the abcl-0.15.0 source][1] with a CR+LF file-ending for 'abcl.in', which means when built under a 'NIX one gets the slightly mysterious message "#!/bin/sh -- interpreter not found. It is slightly surprising that we haven't gotten more complaints on this (or maybe everyone builds from SVN?). The svn:eol-style is now set to 'LF' in SVN for 'abcl.in', which does the "right thing" when building the source tar balls, so abcl-0.16 should be ok, as long as whoever builds the release doesn't somehow override this is local SVN settings Looking through the SVN log for metadata changes to 'abcl.in' doesn't seem to report anything. Maybe there is somehow to report metadata changes, but I don't see how to do this quickly. We have the currently unused ability to fix line endings in the relevant Ant targets. Maybe I should revisit them? If so, what would be the correct policy? [1]: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4

[armedbear-devel] Release planning: two month intervals, but which months?
by Erik Huelsmann 31 Aug '09

31 Aug '09

Last year we set a bi-monthly release planning. Last spring, we released once or twice within 6 weeks. This summer it took me - due to holidays - more time to get our trunk into a releasable state. Or so it must have looked from the outside. What I should have communicated is that I'd like to set our bi-monthly release planning to release around the first weekend of the odd-numbered months. Why? Well, it allows the release schedule to continue without suffering from most of the holidays: summer holidays (at least mine) are mostly during august; Christmas isn't around a first weekend and October holidays are rarely close to the first weekend of November. This means that February holidays may interfere with our release planning, but if I look at school holidays, these are mostly in the middle or the end of February. This plan would also mean that a release should be cut around next weekend. Then there's the issue of me being the only one with the right access to SourceForge to upload ABCL release files. We can do two things about that: 1. Give others upload access to SourceForge 2. Host our downloads on c-l.net The second option would make any committer a release manager, if we decided to do that [because we would commit the releases to our repository, which automatically updates our site]. The reason our downloads are currently hosted on SF is that they provide nice download stats. If we decide we don't need those or that we can create those stats ourselves on c-l.net, there's no reason to continue with SF. What are your comments? Bye, Erik.

2 2

[armedbear-devel] BLOCK-NODE -> specific node types done; let's go for a release
by Erik Huelsmann 31 Aug '09

31 Aug '09

Hi everybody, Over the past weeks, I've been rewriting our generic use of BLOCK-NODE structures to specific structures for every node type. There are TAGBODY-NODEs, CATCH-NODEs, etc. Although I introduced that change for a reason: I want to be able to analyse the nesting set up by pass1 from outer to inner blocks. This gives us some opportunities in preventing functions from becoming closures. Currently every function which is enclosed in a block which defines a closure, becomes a closure. That's too generic and doesn't need to be. Well, as I said, even though I want to introduce changes to that extent, I'm done changing the existing structure. This means I think we're in shape to go for a release. Everybody please run your test suite and your own applications to see if we still meet the quality levels we've delivered in the past releases (or, preferably: better!) I've updated changes, but there are probably a lot more tasks to be addressed. Just to name one: did 'build.xml' get fixed for releasing with Java 1.5? Or should I use 1.6 next time? Bye, Erik.

3 5

[armedbear-devel] BUG: problem with THE type checks in compiler
by eric.marsden＠free.fr 31 Aug '09

31 Aug '09

Hi, There is a problem in the recent improvements to the way the compiler handles THE type checking. File-compiling the code below leads to an error "The value 6 is not of type FOO". (defconstant +foo-OK+ (the (integer 0 10) 5)) (deftype foo () '(integer 0 10)) (defmacro assemble-foo (x) `(the foo ,x)) (defconstant +foo+ (assemble-foo 6)) Eric

3 4

[armedbear-devel] No JSR-223 code in abcl-src-0.15.tar.gz
by Alessio Stalla 28 Aug '09

28 Aug '09

Greetings all, I have downloaded the 0.15 release of abcl from the official site, to use it in a side-project at work. I found out that the archive does not contain the src/org/armedbear/lisp/scripting directory, where the JSR-223 stuff resides. Worse, the archive does contain the META-INF/services/javax.script.ScriptEngineFactory, so when built the jar actually declares it contains a JSR-223 implementation, but it does not. How is the archive built? I think I saw tasks in the Ant-based build file to zip the source, maybe those don't include the scripting/ directory. If that is the case, I can fix it for build.xml. I don't know how the Lisp based build works, though. Alessio

2 3

[armedbear-devel] Embedding ABCL into IntelliJ IDEA and writing plugins
by Anton Vodonosov 23 Aug '09

23 Aug '09

Hello, I created IntelliJ IDEA plugin that embeds ABCL, allows to connect from SLIME and extend IDEA using Common Lisp. I haven't contrived any useful functionality (that is easy to implement), therefore, for the sake of example, the plugin ads to IDEA commands yank and yank-pop, like in Emacs. Source may be found here: http://github.com/avodonosov/abcl-idea/tree/master Binary distro: http://cloud.github.com/downloads/avodonosov/abcl-idea/abcl-idea.zip There is a readme, check it for more details. Some conclusions from my experience: - it is absolutely possible to create IDEA plugins using ABCL. - Jfli interface to java is currently more convenient than native ABCL's - ABCL's performance of slime fuzzy-completion is still unsatisfying (it is the only little unsatisfying thing for me) - ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like: if (jlisp) { ... close input output streams } else System.exit(status); I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process This is not a big problem, because with having Interpreter source code we may But having source code we can copy/past desirable kill behavior - closing streams. But it would make sense to reactor it a little to be more embedding friendly. If somebody is interested to write IDEA plugins in Lisp, my plugin may be used as a basis for further extension. Best regards, - Anton

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel August 2009