http://blog.gmane.org/gmane.editors.j.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.editors.j.devel/5512 <pre>Dear ABCL hackers, I'm proud to announce the release of release ASDF 3.0.0. Please test it and include it in ABCL. I'll have to produce some document explaining the innovations since ASDF 2.26, 2.000 and/or 1.369, but for now here are just the changes since 2.33. As you can see, it's very minor stuff, and ASDF has been mostly stable these last two months, which is a good sign and the reason why I'm making an official 3.0.0 release. I'm also inserting a new digit in the version, so releases will have three digits: 3.0.0, 3.0.1, etc. will be minor continuations of 3.0. 3.1.0 will be the next "major" milestone in a series that preserves backward compatibility, and 4.0 (if ever) will be the next major release that doesn't. But I probably won't be there to see it, because I'm moving away from my Common Lisp job in Cambridge MA to some new as yet undetermined opportunities in NYC that are unlikely to see me do Common Lisp for a living, and I plan to try out different Lisps for a hobby (Racket, Maru, etc.). * Portability: have *uninteresting-conditions* be empty by default. Move stuff to *usual-uninteresting-conditions*, unused by default. Will make the SBCL team happy. Also, fix tests on ABCL. Fix regression of program-op on ECL, by implicitly linking in UIOP or ASDF. * UIOP: improvements to slurp-input-stream and thus run-program, notably accepting T as alias for *standard-output*, for better backward-compatibility of the deprecated run-shell-command. New macro with-output-file. * POIU support enhanced with various tweaks. * Build cleanup so make and concatenate-source-op create the same asdf.lisp —♯ƒ • François-René ÐVB Rideau •Reflection&amp;Cybernethics• http://fare.tunes.org Reason isn't about not having prejudices, it's about having (appropriate) postjudices. — Faré </pre> Faré 2013-05-15T05:07:43 http://permalink.gmane.org/gmane.editors.j.devel/5511 <pre> OK, I'll check that out soon - in the mean time, I do have a working installation to play with, after following the quickstart instructions from http://abcl-web.sourceforge.net/tutorial.html - maybe the text and links there should be updated to reflect the above: ## Deploy via web application archive You can get web application archive (WAR) file for test application [here](http://downloads.sourceforge.net/abcl-web/lispwebapp-0.0.1.war?modtime=1168806257&amp;big_mirror=0), and easily deploy it into servlet container -- if you're using Tomcat's Manager HTML interface, just use upload form with a 'Deploy' button. [...] ## Get web-application by parts Then you can get Java and Lisp files of lispwebapp, and put abcl.jar into WEB-INF/lib directory, and then deploy it into servlet container according to it's documentation (for Tomcat, you can unpack it to /var/lib/tomcat5/webapps/lispwebapp (or whatever home of tomcat is called) and access url http://localhost:8180/manager/deploy?path=/lispwebapp) [...] ## configure Servlet container settings - ABCL won't work if security features are turned on, disabled it for servlet container (in Debian it's /etc/default/tomcat5). You can try to grant all permissions to lispwebapp instead, but i was not successful with it - make your lispwebapp dir be writable by tomcat user -- ABCL writes compiled .abcl files near the source files. (most likely you can do it with chown) </pre> Joe Corneli 2013-05-14T11:25:48 http://permalink.gmane.org/gmane.editors.j.devel/5510 <pre>lispwebapp was superseded by this thing: http://sourceforge.net/p/abcl-web/code/HEAD/tree/trunk/src/org/armedbear/servletbridge/ (You probably want to checkout the whole trunk.) IIRC you need NetBeans to build it. </pre> Alex Mizrahi 2013-05-13T15:07:06 http://permalink.gmane.org/gmane.editors.j.devel/5509 <pre>I had to add these JAR files to the lispwebapp WAR file (http://downloads.sourceforge.net/abcl-web/lispwebapp-0.0.1.war) to get past a couple errors that came up when running "Execute": cp commons-logging-1.1.2/commons-logging-1.1.2.jar WEB-INF/lib cp xerces-2_11_0/xercesImpl.jar WEB-INF/lib After that I was good to go! </pre> Joseph Corneli 2013-05-13T13:12:03 http://permalink.gmane.org/gmane.editors.j.devel/5508 <pre>30.03.2013, 16:17, "Zach Beane" &lt;xach&lt; at &gt;xach.com&gt;: News in this regard: https://groups.google.com/forum/#!topic/cl-test-grid/P_-_CBJW84M </pre> Anton Vodonosov 2013-04-21T07:55:25 http://permalink.gmane.org/gmane.editors.j.devel/5507 <pre>Back are we! On Thu, Apr 11, 2013 at 11:14 AM, Ville Voutilainen &lt; ville.voutilainen&lt; at &gt;gmail.com&gt; wrote: </pre> Alessio Stalla 2013-04-11T09:28:22 http://permalink.gmane.org/gmane.editors.j.devel/5506 <pre> We are back. </pre> Ville Voutilainen 2013-04-11T09:14:31 http://permalink.gmane.org/gmane.editors.j.devel/5505 <pre> Probably. </pre> Stas Boukarev 2013-04-11T08:51:18 http://permalink.gmane.org/gmane.editors.j.devel/5504 <pre>Test. sent from my phone </pre> Erik Huelsmann 2013-04-11T08:49:46 http://permalink.gmane.org/gmane.editors.j.devel/5503 <pre> Completely agreed. I'm going to write a blog item about my own use case, but true, there's a lot more to it than just that. That's not really what I meant, if I understand you correctly. What I meant is: if we can use cl-test-grid to test if libraries load, then we surely can use cl-test-grid to test if a "compiled-and-loaded-from-monolithic-fals" version works. If it doesn't, I'd take that as an indication the ASDF system is broken (that is, if the loader would work for the non-monolithic case). That's fine. In this case, the current ASDF system builder includes only the lisp files it knows about. Right, so I'm not arguing we should include "everything below the system file". I'm saying that system definitions can use #. macros to include files dynamically into the system definition and once that definition is compiled and packed, there's no need to evaluate the #. macro anymore so, loading off a monolithic fasl is still a viable option. True. Isn't it the case that those subdirectories are currently included using reader conditionals? I'm assuming we're not cross-compiling systems for ABCL on SBCL here. I have a feeling I'm not understanding you on this point. I'm not certain with respect to this point. Lets ask Fare about that :-) Only if that's the right thing to do in the sense that ASDF-JAR's functionality has been subsumed into ASDF3's build facility. However, I don't think we need to: it's a contrib in its own right until it's broken and nobody can be motivated to unbreak it. Well, the only difference betweer a FASL and a JAR is the MANIFEST file... I'm sure we can come up with a way to make the .abcls look like jars or even turn them into real ones. However, if there's a file called "my-application--systems.jar", why Bye, Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-04T17:32:09 http://permalink.gmane.org/gmane.editors.j.devel/5502 <pre> […] Updating the ASDF documentation on how to use the new ops as well as recommendations for ASDF definitions would be good steps in this direction. When time and resources are available, of course… […] Maybe we could implement an ASDF/LINT that checks the "well-formedness" of a given .asd file, reporting potential problems? Conceptually such checking needs to be maintained "closer" to ASDF than CL-TEST-GRID. Implementation is the sincerest form of flattery, of course… […] Think of the ABCL-TEST-LISP definition in abcl.asd: it only references files in the test/lisp/abcl sub-directory. So, if one one were to treat the pathname of the .asd file it is defined in, one would include the abcl Java source, possibly the build artifacts, etc. which is probably not what one wants. Or consider CFFI with the cffi-ffi.asd definition, which needs one specific subdirectory. Conceptually, it sounds like a step ahead but how do I use it. Could you write up a quick document on how to use it? I'm still not sure how things like ASDF:SYSTEM-RELATIVE-PATHNAME would work in the monolithic fasl scenario, so I would like to get my hands dirty a bit here. And then deprecate ASDF-JAR? In some ways, I thought that being able to present ABCL components as jar files (abcl.jar, abcl-contrib.jar, hunchentoot-all-1.2.14.jar) would be a more natural fit to typical Java server deployment scenarios. Other than this more natural fit to JVM deployments (whereby the pointy-headed boss would be none-the-wiser as "everything just looks like jar dependencies") the only advantage of using a jar format that still might exist would be to leverage the ["One Jar" approach][one-jar] to actually use a custom classloader to make JVM artifacts (libraries, resources, etc.) packaged in the deployment as well. With this sort of approach we could include the jna.jar needed for CFFI in the deployment artifact, as opposed to needing to override going for the resolving the Maven dependency at deployment runtime. [one-jar]: http://one-jar.sourceforge.net/ </pre> Mark Evenson 2013-04-04T12:13:14 http://permalink.gmane.org/gmane.editors.j.devel/5501 <pre> Well, systems should declare the resources they want packaged into their applications in their system files. That's a requirement both ECL and ABCL now put forward, but I think other implementations which are able to deliver more or less stand alone programs would want the same. Surely we can add tests for that in cl-test-grid as well? The above is no longer true: with MONOLITHIC-FASL-OP you can build a fasl which holds a system and all its depedencies, including QL provided dependencies. This means you only need a working quicklisp setup on the development machine. True, but with the above, they don't need to anymore: they'll be included in the monolithic fasl. Even better: the monolithic fasl really doesn't require ASDF at all: you can simply load the FASL with a normal LOAD call and it will load all the embedded FASLs in the right (ASDF derived) order. I'm sorry, I don't understand this bit. Could you try to explain your concern with different words? So, assuming that "deployment outside of Quicklisp from an ASDF Well, there is no need to develop the ASDF/BUNDLE operation: Fare did. Buth other than that, the fact that I can now succesfully package bordeaux-threads which we couldn't with ASDF-JAR, I think this is really a step ahead? Any ideas? [I actually started writing this mail bottom to top, so what's below may be a reiteration...] Well, the great thing about the solution that Fare has now rolled out is that I was able to package and load Bordeax-threads even though it is problematic because it uses the #. reader macro and does not include the version.lisp-sexp in the ASDF definition... The infrastructure I've added to ABCL has been hooked up into ASDF with his new release. Much more doesn't seem to be required to get it all correctly packaged. Package providers can simply use #. reader macros to inject the list of :static-files they need to be distributed with their code and asdf will pick it up. We'll need to work and test ASDF + ABCL to see if everything works as intened though. Bye, Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-04T10:39:21 http://permalink.gmane.org/gmane.editors.j.devel/5500 <pre>[…] In my opinion of "the right way", system definitions should contain a comprehensive listing of all the resources in the DEFSYSTEM form. Anything referenced by ASDF:SYSTEM-RELATIVE-PATHNAME or as a target of a CL:SHARPSIGN-DOT reader macro should be declared as a STATIC-FILE ASDF component. If this were somehow universally the case, then we could reliably use the machinery of ASDF3 to transverse its components, and determine both the "source" and the "compiled" components. But because "universal distribution" (i.e. for the majority of users of a given system) has more-or-less subsumed by Quicklisp, there is no real constraint on the developers of system definitions to ensure that all components are so enumerated: loading the system from Quicklisp works so nothing is broken, right? After Xach, Anton probably has the most practical experience with packaging ASDF definitions for deployment due to his pioneering work on CL-TEST-GRID. I find Anton comments to be a succinct summary of the issues involved in packaging a given ASDF system in Quicklisp. But when facing deployment for an ASDF system that is not in Quicklisp, but has dependencies on Quicklisp systems, Anton's approach won't work so well. One would have to find the .asd definition on the filesystem, then transverse its sub-directories to find the source files. This has the problem that there is no guarantee that the components of an asd definition exist in subdirectories, as theoretically the PATHNAME could point to an ancestor. And even if one discarded this possiblity, often directory hierarchies share multiple ASDF definitions, so one would package "source" components that aren't really source components. So, assuming that "deployment outside of Quicklisp from an ASDF definition" would be a greater good for the community, we seem to be stuck at a bootstrap problem. I can't think of a way to force ASDF authors to enumerate their static components, but until such enumeration is widespread, I can't demonstrate its utility by developing an ASDF/BUNDLE operation. Any ideas? </pre> Mark Evenson 2013-04-04T08:50:58 http://permalink.gmane.org/gmane.editors.j.devel/5499 <pre>01.04.2013, 16:28, "Erik Huelsmann" &lt;ehuels&lt; at &gt;gmail.com&gt;: General note about deployment CL systems. Often the deployment package should contain not only compiled code, but also resources: web libraries and frameworks often contain .css, .html, .javascript; bordeaux-threads uses version.lisp-sexp files, and so on. In addition to the #. reader macro as used in bordeaux-threads, applications/libraries access their resources during run-time using asdf:system-relative-pathname or similar functions. In other words, such libraries assume presence during run-time of their full source control checkout . A general purpose deployment solutions should account this aspect. Of course, if an application is free from such problems, one can use concatenated fasls, lisp images or similar ways. One way to deploy applications with full content of the dependencies code and resources: 1. install quicklisp in a custom directory, 2. (ql:quickload :my-application) 3. copy the directory of my-application, the custom quicklisp directory and probably prebuild .fals files to server. A little bit more docs and example of this approach is here: https://github.com/avodonosov/heroku-buildpack-cl2 Best regards, - Anton _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Anton Vodonosov 2013-04-03T22:44:21 http://permalink.gmane.org/gmane.editors.j.devel/5498 <pre>Hi all, Commits between r14456 and r14460 change the FASL entry point name. Everybody tracking trunk will need to blow their caches away. Bye, Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-03T21:55:49 http://permalink.gmane.org/gmane.editors.j.devel/5497 <pre>Hi! In order for these commands to generate a fasl per ASDF system, I had to apply the patch below to ASDF. $ ./abcl CL-USER(1): :ld c:/users/erik/quicklisp/setup CL-USER(2): (ql:quickload :bordeaux-threads) CL-USER(3): (asdf:oos 'asdf:binary-op :bordeax-threads) The commands above work with current trunk (r14460) and produces 2 concatenated fasls in my cache directory: 1 for alexandria and 1 for bordeaux-threads. This patch is required (also attached, to prevent line wrapping): diff --git a/bundle.lisp b/bundle.lisp index 568f894..24fbf90 100644 --- a/bundle.lisp +++ b/bundle.lisp &lt; at &gt;&lt; at &gt; -185,7 +185,7 &lt; at &gt;&lt; at &gt; (or #+ecl (or (equalp type (compile-file-type :type :object)) (equalp type (compile-file-type :type :static-library))) #+mkcl (equalp type (compile-file-type :fasl-p nil)) - #+(or allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) + #+(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) (defgeneric* (trivial-system-p) (component)) diff --git a/uiop/lisp-build.lisp b/uiop/lisp-build.lisp index e2e376d..4b7e819 100644 --- a/uiop/lisp-build.lisp +++ b/uiop/lisp-build.lisp &lt; at &gt;&lt; at &gt; -669,11 +669,12 &lt; at &gt;&lt; at &gt; it will filter them appropriately." ;;; Links FASLs together (with-upgradability () (defun combine-fasls (inputs output) - #-(or allegro clisp clozure cmu lispworks sbcl scl xcl) + #-(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (error "~A does not support ~S~%inputs ~S~%output ~S" (implementation-type) 'combine-fasls inputs output) #+clozure (ccl:fasl-concatenate output inputs :if-exists :supersede) #+(or allegro clisp cmu sbcl scl xcl) (concatenate-files inputs output) + #+abcl (sys:concatenate-fasls inputs output) #+lispworks (let (fasls) (unwind-protect _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-03T21:50:21 http://permalink.gmane.org/gmane.editors.j.devel/5496 <pre>Hi Mark, Thanks for your reaction. I have a better idea which always works and works without searching for the entry: let's call the main entry point a constant name: __loader__._ Actually in my local working copy, I already have done this and it works like a charm even with the renaming scheme ASDF employs. Will commit in a bit. Which probably means we can remove the fallback code (yay! simplicity!) Agreed? Bye, Erik. On Wed, Apr 3, 2013 at 11:16 PM, Mark Evenson &lt;evenson&lt; at &gt;panix.com&gt; wrote: _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-03T21:26:05 http://permalink.gmane.org/gmane.editors.j.devel/5495 <pre> The code in the java implementation of CL:LOAD, in Load.java:175 ff. makes an attempt to match a pathname with a wild NAME component if the fasl has been renamed. </pre> Mark Evenson 2013-04-03T21:16:40 http://permalink.gmane.org/gmane.editors.j.devel/5494 <pre>Hi! As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF: Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip. My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._". How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation? Bye, Erik. _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-03T20:39:39 http://permalink.gmane.org/gmane.editors.j.devel/5493 <pre> […] Recorded as ticket [314][]. Thanks for the bug report. [314]: http://trac.common-lisp.net/armedbear/ticket/314 </pre> Mark Evenson 2013-04-03T08:19:36 http://permalink.gmane.org/gmane.editors.j.devel/5492 <pre>As it turns out, it chose the wrong method to print the funcallable-standard-object: r14455. Bye, Erik. On Tue, Apr 2, 2013 at 9:44 PM, Rudolf Schlatte &lt;rudi&lt; at &gt;constantly.at&gt; wrote: _______________________________________________ armedbear-devel mailing list armedbear-devel&lt; at &gt;common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel </pre> Erik Huelsmann 2013-04-02T20:00:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.editors.j.devel