armedbear-devel

armedbear-devel@common-lisp.net

1202 discussions

[armedbear-devel] abcl-1.1.0 engineering scrum @ 2100 CET (1900 GMT) on #abcl
by Mark Evenson 06 Aug '12

06 Aug '12

We will be holding the weekly abcl-1.1.0 engineering scrum @ 2100 CET on #abcl. Anyone with questions, priorities, patches, welcome to join. The meeting will probably be sparsely attended, so I will just work on recording the [current status as I see it on the Armed Bear Trac Wiki][1]. We can move to audio/video if there is a need. [1]: http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Unqualified FIND-PACKAGE call in ABCL compiled files
by Vladimir Sedach 06 Aug '12

06 Aug '12

Hi, Currently, ABCL doesn't qualify the package of FIND-PACKAGE when it serializes a package in a compiled file. This causes a bug when loading a compiled file that has code (for example, the EOS:TEST macro from the EOS unit-testing library) that serializes a package, and occurs after an IN-PACKAGE into a package that either shadows or does not import FIND-PACKAGE from COMMON-LISP. I didn't work out a minimum test case, but the problem can be observed when trying to load the Parenscript test suite: (ql:quickload :parenscript.test) Here's the fix: Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 14055) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -1191,7 +1191,7 @@ (defun serialize-package (pkg) "Generate code to restore a serialized package." - (emit 'ldc (pool-string (concatenate 'string "#.(FIND-PACKAGE \"" + (emit 'ldc (pool-string (concatenate 'string "#.(CL:FIND-PACKAGE \"" (package-name pkg) "\")"))) (emit-invokestatic +lisp+ "readObjectFromString" (list +java-string+) +lisp-object+)) Index: src/org/armedbear/lisp/Package.java =================================================================== --- src/org/armedbear/lisp/Package.java (revision 14055) +++ src/org/armedbear/lisp/Package.java (working copy) @@ -865,7 +865,7 @@ public String printObject() { if (_PRINT_FASL_.symbolValue() != NIL && name != null) { - StringBuilder sb = new StringBuilder("#.(FIND-PACKAGE \""); + StringBuilder sb = new StringBuilder("#.(CL:FIND-PACKAGE \""); sb.append(name); sb.append("\")"); return sb.toString(); Happy hacking, Vladimir

2 1

[armedbear-devel] Monday progress meeting
by Erik Huelsmann 05 Aug '12

05 Aug '12

Hi Mark, Dunno if I'll be making it to our monday progress meeting tomorrow (travelling to be done). But this is my status: * My work on DEFINE-METHOD-COMBINATION can be considered Done; I left some todo's behind which should be relatively small in comparison to the original problem. It's now just a matter of changing the symbols in the backquote patterns. * My work on the autoloader has been mostly done as far as our current infrastructure allows; next steps: - Clean autoload.lisp for any symbols which automatically end up in autoload-gen.lisp - Create infrastructure for autoloading of SETF functions (ie function names not designated by a symbol) * Crashes evaluating a form referencing an undefined function in a clean image --> solved by requiring PRINT-OBJECT in the right place With respect to this point: it's possibly a good idea to do a search of the code base and find out if we're doing this everywhere PRINT-OBJECT methods are being defined * COMPILER-UNSUPPORTED-FEATURE-ERROR derived from CONDITION --> solved * Autoloader fails when *READ-xxx* variables bound to unexpected values --> solved * Implement USE-FAST-CALLS properly --> resolved by deleting the USE-FAST-CALLS infrastructure from the interpreter; the compiler already does the right thing * Compiling #n# causes stack overflow --> solved; however, Stas Boukarev reports that the case I've fixed only fixes in-memory compilation and the issue still exists in file compilation. Ticket #191 should be re-opened to and should say so. All in all a pretty good result for one week. However, from here on $WORK will start again which means I'll only be able to address the bigger issues in small steps. Or just the smaller issues, of course. Which is why I'm glad to have worked out the D-M-C stuff. That was a week more than full time work to completely comprehend the spec and macrology going on in our implementation. That's it for now. If I'm available tomorrow at 21:00 CET, I'll be on #abcl. Bye, Erik.

1 0

[armedbear-devel] Trouble compiling functions with cyclic structures.
by Stas Boukarev 05 Aug '12

05 Aug '12

compile-file has trouble with (defun bar () '#1=(cycle . #1#)) -- With best regards, Stas.

1 0

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel