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

[armedbear-devel] special operators without a macro definition
by Pascal J. Bourguignon 03 Aug '12

03 Aug '12

Here is a "bug-report"/enhancement suggestion: ------------------------------------------------------------------------ The following special operators don't have a corresponding macro definition. THREADS:SYNCHRONIZED-ON EXTENSIONS:TRULY-THE JVM:WITH-INLINE-CODE While the standard doesn't specify anything for special operators not in the CL package, it would still be nice if they followed the same rule as for CL macros implemented as special operators: 3.1.2.1.2.2 Macro Forms An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided. since this would ensure that portable code walkers can be written. ------------------------------------------------------------------------ -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

1 0

[armedbear-devel] Simpe swing examples using JSS and JFLI
by fsmunoz＠gmail.com 01 Aug '12

01 Aug '12

Greetings, I've been playing around with ABCL for some days now, especially in terms of the Java interop abilities and Swing. This is because I was searching for a Lisp that could be easily used for cross-platform GUI programming and easy deployed (for the user). This narrowed it down to the several JVM-based Lisps (ABCL, Kawa, etc) and Clojure. While I like Clojure - and "lein uberjar" is a great facility, for example - I'm more confortable in CL, so I did this two small examples that can perhaps be useful as a way to compare ABCL's different interop facilities with themselves and Clojure. In a way I used this to get a "feel" on how things would work out and make a decision. ABCL JSS Swing Example: http://paste.lisp.org/display/130606 ABCL JFLI Swing Example: http://paste.lisp.org/display/130605 I'm going to make another use using the lower-level API (jcall, etc), for the sake of completeness, but I think that perhaps this examples can be helpful to others as a small reference, using a well-known example. For me it was quite fun and my overall impressions thus far is that: 1) ABCL offers different interop facilities that taken as a whole make it a quite capable solution for overall Java interop, including GUI programming. 2) The JSS approach has the advantage of being less verbose since the methods need not contain the class name (which looks cleaner IMO). It is also simpler to setup, i.e. no need for def-java-class et. al. 3) The JFLI approach integrates well with Lisp, since it provides completion of methods, amongst other small things. The lack of #"foo" syntax is also visually appealing IMO. It can also - theoretically - be used by JFLI installations in other Lisps. It is more verbose though, since methods must be preceeded with the class (class.foomethod) 4) Clojure's approach is (naturally) conceptually quite similar to JFLI, in the "feel" that it provides, although the use of (.fooMethod instance) is similar to (#"fooMethod" instance) in terms of synxtax. The use of macros (like doto) significantly reduces number of words used. 5) I see nothing in the way of implementing similar macro mechanisms on top of either JSS or JFLI - but I can be simplifying things brutally here. In the most simple scenario syntax differences are as follows: ABCL JSS: (#"setText" my-label "The Larch") ABCL JFLI: (jlabel.settext my-label "The Larch") Clojure: (.setText my-label "The Larch") The Clojure approach seems quite similar to the javadot approach of jscheme (http://jscheme.sourceforge.net/jscheme/doc/javadot.html) as noted in the ABCL blog - I was unaware of that. More complex approachs envolving the need for proxies contain more differences of course. I would greatly welcome any comments concerning style and approach: I am completely new to this so I am probably missing a lot. It was quite enjoyable though, even if there are still some rough edges here and there (quite understandable since for JFLI I had to used trunk). I think that this is an area worth exploration, easy (meaning well-integrated, clear syntax, small impact) interop is a huge advantage. Thank you for your hard work, highly appreciated. Cheers, Frederico

4 4

[armedbear-devel] RFC: Autoloading and "multi-homed symbols"
by Erik Huelsmann 01 Aug '12

01 Aug '12

Hi all, Just committed my progress on the automatically generated autoloads. The next step is to clean up "autoloads.lisp" (the file which still exists to allow manual addition/manipulation. While I can do that step by myself, I'd like to discuss a problem we already have today, just never encountered: Generic functions can have methods defined in more than one file. Example: PRINT-OBJECT has its GF defined in print-object.lisp, but has methods defined in print-object.lisp, java.lisp and format.lisp. Clearly, when PRINT-OBJECT is being called for the first time (and hence needs to be autoloaded), it's not correct to autoload java.lisp or format.lisp: we would miss the generic function and if print-object.lisp is loaded later, it'll overwrite the methods already defined. On the other hand, *only* loading print-object.lisp isn't correct either: we have no idea if the arguments passed to the call should have caused the methods in java.lisp or format.lisp to be triggered. My current thinking about the above is that we'd need to load all files in which methods are being defined for PRINT-OBJECT. These files should makes sure (through REQUIRE) that they load the file with the generic function first. The autoloading facility should then hook into require in some way or another to make sure it doesn't load files which have been loaded through REQUIRE to prevent out-of-order loading. Then my next issue is that if one of the files being loaded in the loaded group has symbols which are multi-homed in a different (but overlapping) set of files, those files need to be loaded as well, for the same reasons. My question is: what are your thoughts on the subject? BTW: I have some more questions I'd like to discuss regarding autoloading, but since they are unrelated, I'm holding off posting until discussion on this subject has settled on a general direction for development. What was autoloading again? Autoloading is a mechanism which allows ABCL to start up quickly by deferring loading of FASLs which it only needs later. Also, helps ABCL to run in memory-restrained environments by loading only the support necessary to run the code at hand. Autoloading is a feature used *only* for ABCL's own FASLs. User-FASLs will always be fully loaded (although I suppose it should be possible to leverage the existing autoloader infrastructure to help users who think they need this for themselves). Bye, Erik.

3 2

[armedbear-devel] Autoloading && method definitions
by Erik Huelsmann 01 Aug '12

01 Aug '12

Hi all, Today I've been playing around with ways to automatically extract symbols from our build to automate (most) of the autoloads.lisp maintenance. So, I've created a small adjustment to COMPILE-FILE which saves the top-level DEFUNs, DEFMETHODs and DEFGENERICs which have been compiled. The result is interesting even in light of today's file: analysis shows we have several generic functions for which methods have been defined across multiple files. An example: we have definitions for PRINT-OBJECT in print-object.lisp, but also in java.lisp and format.lisp. This is a problem, because the autoloader has been instructed to load "print-object.lisp" only, when finding references to the print-object generic function. My conclusion so far is that we need to be able to trigger auto-loading of more than one source file *and* that we need a way to determine in which order to load them: we'd typically want to load the file containing the DEFGENERIC before we load the one with the other method definitions. While the former isn't trivial (think threading) but doable, I'm still thinking how to achieve the latter. So, why do we want autoloading at all? Well, we want to make sure we get a short start up time and to achieve that, we don't load the parts of the system that we don't need. How much extra time it would take to load the full system? I have no idea at this moment. (But we could experiment and code to that extent would be greatly appreciated!) And why do I want to part with our current system? Well, from analysis of the DEFUN/DEFGENERIC/DEFMETHOD data (and thus excluding the DEFMACRO data) we have 2512 definitions each of which may be referenced by our users. Currently only a few hundred of them actually exist before the file gets autoloaded. Which ones will exist is hard to tell from the sources themselves. Maintaining the file is somewhat a trial and error process: if ABCL doesn't load without the autoloads, add them to the autoloads.lisp file. I'd like our process to be both more automatic and less trial and error. [I started to write the above yesterday, but apparently didn't send it...] Bye, Erik.

2 1

[armedbear-devel] ANSI bugs in call-next-method
by Rudi Schlatte 31 Jul '12

31 Jul '12

Hi, Just wanted to mention that the two test failures for call-next-method are much easier to fix now that we have mop:make-method-lambda, which gets passed the method metaobject. I can have a look this month (still busy with family matters until next week). Rudi

1 0

[armedbear-devel] Autoloader progress and experiences
by Erik Huelsmann 31 Jul '12

31 Jul '12

Hi all, Although I wanted to work on ticket #201 (&whole broken in DEFINE-METHOD-COMBINATION), I found a regression (ticket #227) which I believe is strongly correlated with how our process of auto loading works (ticket #226). So, I've done a bit of work, some of which already committed, to extract the symbols of toplevel defined functions/methods and macros from our bootstrap build. I'm now working to use that list to create a more complete "autoloads.lisp" file. During that work I found at least one cause of instability regarding our autoloading and the definition of generic functions: we were resolving (autoloading) symbols with an autoloader in the function slot when defining a generic function on them. Usually however, the reason to be defining a generic function on a symbol with an autoloader in the function slot will be the fact that autoloading has been triggered. The only reason this worked in the past is that our list of autoloaded symbols was so small we haven't run into this situation. Should that ever have happened, that'd have been very hard to find though. Another thing I found is that MACROEXPAND-1 (and by extension of its use in PRECOMPILE, the precompilation) try to resolve symbols with autoloaders on them. That's a problem as well, because we have forward-referenced functions: e.g. we forward-reference SLOT-VALUE-USING-CLASS from SLOT-VALUE. When clos.lisp is being loaded and SLOT-VALUE is being defined using DEFUN, it's being "precompiled": translated to an efficient execution form. However, that process finds a reference to SLOT-VALUE-USING-CLASS, which it will autoload. This recursively triggers loading of clos.lisp. Do we still want to do precompilation? Yes, I think so, because on my machine usual build times are ~ 6 minutes for a full build; this time goes up to ~16 minutes without precompilation. So, the process does what it's designed to do well. The answer then - I think - is to stop precompiling during function definition and delay that until the first actual invocation. ---- breaking news: While writing the above, I came up with another option, which is to make MACROEXPAND-1 only resolve symbols which are macro functions. That worked, or at least, that's what it looks like. I had a successful build and will run the compiled tests in a minute. As things stand, we'd be able to start generating most of our autoloads.lisp file. [even later: seems the test suite is completing now. I'm having a PSETF regression, I think, but no idea why yet.] ----- So, I think I'll work out the remainder of the change and make sure it gets committed. After that, I'll have a look at the PSETF failure - which is hopefully fall-out from another change or at least has a workaround in a different way: having automated autoloaders seems a valuable asset. Bye, Erik.

1 0

[armedbear-devel] Autoloading && method definitions
by Erik Huelsmann 30 Jul '12

30 Jul '12

Hi all, Today I've been playing around with ways to automatically extract symbols from our build to automate (most) of the autoloads.lisp maintenance. So, I've created a small adjustment to COMPILE-FILE which saves the top-level DEFUNs, DEFMETHODs and DEFGENERICs which have been compiled. The result is interesting even in light of today's file: analysis shows we have several generic functions for which methods have been defined across multiple files. An example: we have definitions for PRINT-OBJECT in print-object.lisp, but also in java.lisp and format.lisp. This is a problem, because the autoloader has been instructed to load "print-object.lisp" only, when finding references to the print-object generic function. My conclusion so far is that we need to be able to trigger auto-loading of more than one source file *and* that we need a way to determine in which order to load them: we'd typically want to load the file containing the DEFGENERIC before we load the one with the other method definitions. While the former isn't trivial (think threading) but doable, I'm still thinking how to achieve the latter. So, why do we want autoloading at all? Well, we want to make sure we get a short start up time and to achieve that, we don't load the parts of the system that we don't need. How much extra time it would take to load the full system? I have no idea at this moment. (But we could experiment and code to that extent would be greatly appreciated!) And why do I want to part with our current system? Well, from analysis of the DEFUN/DEFGENERIC/DEFMETHOD data (and thus excluding the DEFMACRO data) we have 2512 definitions each of which may be referenced by our users. Currently we define a subset "likely to be used" which causes autoloading to happen. However, since we regularly break that subset ourselves, I want to automate the task by collecting the symbols during the build (and allow for manual additions and deletions - which should be much more rare). Any comments, complementing experiments or proposed solutions are very welcome! Bye, Erik.

1 0

[armedbear-devel] bug in FASL loader
by Durward McDonell 29 Jul '12

29 Jul '12

Hello. I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl. Consider the following code: (defmacro foo-bar (s) `(sublis '((foo . bar)) ,s)) (defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it))) Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis". -- Durward McDonell durward.mcdonell(a)jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)

4 7

[armedbear-devel] Planning for abcl-1.1.0
by Mark Evenson 29 Jul '12

29 Jul '12

Yesterday (and today), Erik and I spent time discussing and preparing for the engineering work necessary to get abcl-1.1.0 released. This release will obviously feature Rudi's hard work as a reasonably stable version of AMOP that CLOSER-MOP can be patched to reference, but we have other goals as well which I want to capture so I now transcribe a bit about our thinking, decisions, and plans going forward. Comments, objections, innovations, etc. solicited. We now have [some 34 active bugs][abcl-1.1.0] in the ABCL 1.1.0 milestone that we intend to address. We have assigned an owner to most of the bugs of either Erik or myself. This does not mean that others shouldn't be working on the bug as well if they have time to contribute to it, just that they should co-ordinate to the "owner" (a quick #abcl message like "ehu: I have stuff for #19?, do you have any patches?" would be fine to avoid duplication). Roughly, Mark got everything dealing with abcl-contrib and Pathnames, and Erik got everything dealing with the compiler. We intend to have a weekly meeting on #abcl, tentatively for set for Mondays around 2100 CET which we will review what we have gotten done, ask questions, and generally try to move the release forward. Everyone is welcome to contribute feedback, volunteer help, etc. as these will be open meetings. We plan on an abcl-1.1.1 maintenance release 30 days after abcl-1.1.0 that will fix everything that we can. [abcl-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0 An explanation of the criteria for bugs we selected: # Criteria for issues In order of importance: 0. Enable CLOSER-MOP. 1. No regressions with respect to the behavior of abcl-1.0.1. Fortunately, there only seems to be one categorized with "regression" tag (is this really the correct situation?) 2. Load a wider range of Quicklisp systems. Fix the ANSI test-grid problem if it is still active, using the source code distributed by Quicklisp as the basis for a more robust system. We might not necessarily fix the compiler in all cases, but instead implement a fallback strategy to include source forms in our FASLs for which to pass to EVAL for forms that we can't compile. This is under active consideration, as it presents the single largest unknown in terms of necessary resources to address. 3. Fix all known "ansi-conformance" problems. 4. Fix everything reported as broken by users. In the weekly meetings, we may start "jettisoning" some issues for later releases as time goes on. We estimate that given just Erik's and my time, it will take roughly three months from now to release abcl-1.1.0. If you want to make this happen faster, we welcome all helping hands. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare it to now."

1 0

[armedbear-devel] Space leak due to threads stuck in LispThread map
by Pendergrass, James A. 27 Jul '12

27 Jul '12

Hello all, I'm having some trouble with space leakage that looks to be because the static map in LispThread isn't letting go of completed JavaThreads. Basically what I'm doing on the Java side looks like: > class Foo { > public static int main(){ > manager = new Manager(); > fun = getLispFunction("processResults"); > > new Thread() { > public void run() { > LispObject res = generateSomeLisp(); > fun.execute(manager, res); > }.run(); > manager = null; > while(1); > } > } The lisp side looks like: > (defun processResults (manager res) > (let ((*manager* manager)) > (declare (special *manager*)) > (eval res))) But the manager never gets destroyed. I used the eclipse Java Memory Analysis tool to track this down to the created JavaThread being referenced as a key in the static map variable in LispThread. Any suggestions on how to get around this? The whole code base is pretty memory intensive so garbage collecting that manager is really a must (and cleaning up the thread is probably a good plan too). Thanks, -Aaron

3 6