http://permalink.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/5514 <pre> I haven't actively pushed our CL:HASH-TABLE to such limits, but would be very interested in including alternative implementations in ABCL if that solves your problem. [WeakHashTable][] provides an example of an alternate hashtable structure that "looks" like a standard CL:HASH-TABLE to existing code. [WeakHashTable]: http://lisp.not.org/trac/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/WeakHashTable.java ABCL's [Java implementation of CL:HASH-TABLE][HashTable.java] uses a pre-allocated array of HashEntry objects for the underlying storage buckets, so unless there is some sort of memory pressure from GC, I am surprised by this behavior. Standard questions for your side: Can you comfortably fit 10^6 of your records in memory? Are you copying the structure when adding to the HASH-TABLE, or just inserting a reference? I might start investigating by throwing the "-Xloggc: log GC status to a file with time stamps" switch to see if the GC "pulses" get longer as you get deeper into your transverse. [</pre> Mark Evenson 2013-05-23T05:34:26 http://permalink.gmane.org/gmane.editors.j.devel/5513 <pre>Hi, Has anyone looked at this? I'm traversing a large structure and using an eq (tried eql too) hash table to record where I've been so that I don't get caught in circularities. There are about 1.5M nodes, but what I see is that adding entries to the hash table slows down (a lot) over time, even when I give an initial size of 4,000,000. That would be max occupancy of 30%, lower than anyone would typically rehash. What I see is that it rapidly starts to fill. At 300k entries I'm getting about 2.5K new entries per second. By the time I get to 600k entries it is down to 750 new entries/sec. At 900k (where it stands now) it's about 500 entries/sec. That makes me suspect that the hash isn't distributing well over the size of the underlying vector and that the slowdown is due to buckets getting long. I'm not sure how to probe this - any ideas? Or to fix it. I suppose I could look for an alternative hash implementation, but I thought I would check first with the list to see if anyone else can shed some light. </pre> Alan Ruttenberg 2013-05-22T20:35:08 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.). </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) [...] ## con</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 </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 sti</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 </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 involve</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 d</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 (comp</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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.editors.j.devel