gmane.lisp.armedbear.devel

Performance of eq hash tables

Alan Ruttenberg — 2013-05-22T20:35:08

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.

Are we back?

Erik Huelsmann — 2013-04-11T08:49:46

Test.

sent from my phone

REMOVE CACHES: r14460 changes FASL entry pointname

Erik Huelsmann — 2013-04-03T21:55:49

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-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Patch for ASDF2.26.32 to support concatenatedfasls for ABCL

Erik Huelsmann — 2013-04-03T21:50:21

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
< at >< at > -185,7 +185,7 < at >< at >
       (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

Support for concatenated fasls

Erik Huelsmann — 2013-04-03T20:39:39

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-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Other findings (was Re: Questions about r14452(Fix cl-cont))

Erik Huelsmann — 2013-04-02T19:40:16

While studying this problem using DESCRIBE, it seems our current
implementation dispatches (DESCRIBE (MAKE-INSTANCE
'CL-CONT::FUNCALLABLE/CC)) the wrong way: to the T way instead of the
STANDARD-OBJECT way...

Yet more to investigate...

Bye,

Erik.
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Fwd: Re: Questions about r14452 (Fix cl-cont)

Erik Huelsmann — 2013-04-02T17:52:45

sent from my phone
---------- Forwarded message ----------
From: ehuels-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
Date: Apr 2, 2013 7:51 PM
Subject: Re: Questions about r14452 (Fix cl-cont)
To: Rudolf Schlatte <rudi-4eUIStHq6WvhYHbOoDrFzw< at >public.gmane.org>
Cc:

Hi Rudi,

Basically the expectation we violated was the fact that %set-lambda-name
didn't want to take a funcallable instance as its function argument. The
commit changed that and used the first slot  of the funcallable  instance
class layout (called NAME) to store the name. I guess we forget to finalize
the class somewhere, so the spots don't appear?

Bye,

Erik.

sent from my phone
On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi-4eUIStHq6WvhYHbOoDrFzw< at >public.gmane.org> wrote:

Hi,

I suspect that the changes in commit r14452 only work by accident.

The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs
FuncallableStandardObject are no problem, since the latter simply isn't
used anywhere.  But the new methods getName() and setName() assume tha

Questions about r14452 (Fix cl-cont)

Rudolf Schlatte — 2013-04-02T17:32:32

Hi,

I suspect that the changes in commit r14452 only work by accident.

The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere.  But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name.  Since 
    (class-slots (find-class 'funcallable-standard-object))
returns NIL, these assumptions hold only when the objects are in fact generic functions.

Amusingly,
    (function-lambda-expression (make-instance 'funcallable-standard-object))
runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though
    (typep (make-instance 'funcallable-standard-object) 'function) => T
so I can't trigger the array-out-of-bounds error right now.

Could I have a recipe for triggering the bug?  I'd like to see how cl-cont uses funcallable-standard-objects, and wh

ASDF-JAR vs ASDF3 deployment support

Erik Huelsmann — 2013-04-01T12:15:47

Hi all,


Some years ago, Mark wrote ASDF-JAR; a solution to package ASDF systems and
their dependencies in JARs.

As it turns out, the solution chosen has some problems with correctly
packaging ASDs for systems which use the #. reader macro. As an example:
bordeaux-threads uses a version.lisp-sexp file to canonically define the
version number and the system definition reads that file in a #. form.
However, this file isn't packaged because it's not part of the file listing
in the system definition. This means asdf can't load the definition after
deployment.

With the advent of ASDF3, its developers have created infrastructure to
combine fasls of a single system and even fasls of a  system and all its
dependencies into a single large combined FASL. Among others, this new
infrastructure does not run into the issue ASDF-JAR is running into. While
not completely equivalent to the JAR solution, using this infrastructure
would help us a huge step along that way of getting better deployment. My
current thinking is

Using ASDF/BUNDLE for ABCL

Erik Huelsmann — 2013-03-31T19:39:38

Hi,


Some time ago Mark Evenson created ASDF-JAR on ABCL. It has some issues
packaging ASD files which uses #. syntax to read e.g. version files
(version.lisp-sexp) such as bordeaux-threads does.

We know ECL started hooking into the ASDF/BUNDLE machinery for ASDF to
overcome problems like these. Could you help me/us out and explain how we
can plug ABCL into the same machinery? From what I've seen, it's most
efficient if the resulting code be committed to ASDF. That's fine by me. At
this point, I'd just be happy with an explanation on how to do the hooking
up: the new ASDF/BUNDLE functionality doesn't seem to be documented in the
manual yet.


Thanks for any help you may be able to provide!


Bye,


Erik.
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

bug in format ~f

Carlos Ungil — 2013-03-31T11:14:50

Hello,

comparing output from different implementations I've found the following
(minor) bug:

1.0 ;; should be 1.00

I think there is a problem here as well:

.0000 ;; should print "  0.0"

Only SBCL gives the output I would expect, most implementations print
".0000" as ABCL does. From the HyperSpec 22.3.3.1: "If the parameter d is
omitted, then there is no constraint on the number of digits to appear
after the decimal point. A value is chosen for d in such a way that as many
digits as possible may be printed subject to the width constraint imposed
by the parameter w and the constraint that ___no trailing zero digits may
appear in the fraction, except that if the fraction to be printed is zero,
then a single zero digit should appear after the decimal point___ if
permitted by the width constraint." This problem appears only when the
value is close to zero, otherwise the output is fine:

  1.0 ;; OK

I guess those zero digits are not considered trailing because there is no
non-zero digit before but I think th

How to .... generate abcl-diff9.html?

Erik Huelsmann — 2013-03-30T17:38:54

Hi Anton,

The test run has completed. How do I generate a new difference report?

Bye,

Erik.
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Setup changes for cl-test-grid.cloud.efficito.com

Erik Huelsmann — 2013-03-30T09:14:01

Hi Anton,


Looking at some of the test grid failures for ABCL, I noticed some of the
OpenGL packages failing due to being unable to locate LibGL.so. To resolve
that, I ran:

 $ aptitude install libgl1-mesa-swx11

Then I noticed something wanted to require JSS, but didn't know how to, so
I've added "(require :abcl-contrib)" to /home/testgrid/.abclrc.

With these in place cl-glfw-opengl-core seems to load just fine.

Any other libraries or measures I should take in order to be able to load
(currently failing) systems?


Bye,


Erik.
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Bordeaux-threads test hangs

Erik Huelsmann — 2013-03-24T20:50:18

From a mail by Stellian Ionescu:

From: Stelian Ionescu <sionescu-ct8TMaJCiNI< at >public.gmane.org>
To: armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
Cc:
Date: Sat, 23 Mar 2013 01:07:04 +0000 (UTC)
Subject: Bordeaux-threads test hangs
The B-T test suite hangs on test "condition-variable". If I do a ^C ABCL
exits,
so I'm not sure how to debug it.

CL-USER(1): (lisp-implementation-version)
"1.1.1"
"OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_17-b02"
"amd64-Linux-3.7.10-10-default"
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

cl-l10n: GETENV on ABCL

Erik Huelsmann — 2013-03-24T19:38:59

Hi Attila,


cl-l10n wants to use GETENV. Now that ABCL seems to support closer-mop
rather well, we're testing many more libraries to see if they're loading
correctly on ABCL.

cl-l10n seems to lack a GETENV for ABCL. Could you use the the function
EXT:GETENV for it?

Example:

    (ext:getenv "PATH")
--> "some path string"

Or NIL if no env var by the given name exists.


Thanks in advance!


Bye,


Erik.
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

preparing to test ABCL trunk

Anton Vodonosov — 2013-03-16T22:40:18

Today Erik configured for me a VM on his server, where I can run cl-test-grid tests.

We were trying the recent ABCL trunk (1.2.0-dev-svn-14436) on the very very recent
quicklisp 2013-03-12, which includes long awaited releases for closer-mop and cffi
with ABCL patches.

Some notes I collected:

1. New CFFI tries to (require :jss) and fails, because (require :abcl-contrib) hasn't been done.
    If we do (require :abcl-contrib) then CFFI loads. 
2. But when we test actual work, for example by doing
      (ql:quickload :drakma) (drakma:http-request "https://google.com/") it fails with strange
   error "UNDEFINED-FUNCTION is called". On SBCL these calls work.
3. (ql:quickload "cl-l10n") fails with ArrayIndexOutOfBounds - may be an ABCL bug.

Aside from this, closer-mop seems working (at leas compilation of dependent library
"access" doesn't fail anymore).

Mark, If you want to quickly reproduce the above problems, you can access 
the server at cl-test-grid.cloud.efficito.com. Username - testgrid.
Erik have adde

Tests broken?

Rudolf Schlatte — 2013-03-05T19:41:12

Hi,

Seems our tests are currently broken - e.g., the (asdf:operate 'asdf:load-op :abcl) form on line 994 of build.xml fails for me.

Does this ring a bell for anyone?

Rudi

[Extended Deadline] European Lisp Symposium 2013- Madrid - June 1-4

Didier Verna — 2013-03-05T16:12:51

;;            ______   _         _____   _   __   ____  
;;           |  ____| | |       / ____| ( ) /_ | |___ \ 
;;           | |__    | |      | (___   |/   | |   __) |
;;           |  __|   | |       \___ \       | |  |__ < 
;;           | |____  | |____   ____) |      | |  ___) |
;;           |______| |______| |_____/       |_| |____/ 
;;                                                      
;;              European Lisp Symposium 2013 - ELS'13
;;                         Madrid, Spain
;; 
;;                        June 1-4, 2013
;;
;;           http://els2013.european-lisp-symposium.org/

                ** DEADLINE EXTENSION: March 17th **

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in L

variable-information?

James M. Lawrence — 2013-03-02T15:35:47

Is there something akin to variable-information in CLTL2? For a given
environment I would like to know if a symbol is a lexical variable or
a symbol macrolet.

Package-local nicknames landed

Rudolf Schlatte — 2013-03-01T11:30:56

Hi,

I just committed support for package-local nicknames in abcl.  This follows the lead of sbcl and lets you introduce short, meaningful nicknames ("XML" for "COM.WHATEVER.FOO.XML-PARSER") in your own packages without fear of package (nick)name collisions.

Here's the example from Nikodemus' documentation:

(defpackage :bar (:intern "X"))
(defpackage :foo (:intern "X"))
(defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar)))
(find-symbol "X" :foo) ; => FOO::X
(find-symbol "X" :bar) ; => BAR::X
(let ((*package* (find-package :quux)))
  (find-symbol "X" :foo))               ; => BAR::X
(let ((*package* (find-package :quux)))
  (find-symbol "X" :bar))               ; => FOO::X

This puts :package-local-nicknames on *features*; I had to increase the fasl version since %defpackage got a new parameter.

Cheers,

Rudi

encoding issues with ABCL

Faré — 2013-02-25T21:28:01

Dear ABCL developers,

it looks like ABCL is not doing the Right Thing with respect to
LOAD's :EXTERNAL-FORMAT argument, instead reading everything with
some dubious default from the environment. Can you fix it?

For instance, in Robert Golman's test below,
the file is read as MacRoman.

Please check COMPILE-FILE too in case it has the same bug.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Men have a much better time of it than women; for one thing they marry later;
for another thing they die earlier.
— H.L. Mencken

---------- Forwarded message ----------
From: Robert Goldman <rpgoldman< at >sift.info>
Date: Mon, Feb 25, 2013 at 4:15 PM
Subject: Re: [asdf-devel] Test results on Mac OSX
To: Faré <fahree< at >gmail.com>
Cc: ASDF-devel <asdf-devel< at >common-lisp.net>


On 2/25/13 Feb 25 -10:34 AM, Faré wrote:

Done.  I'm afraid the results are Greek to me.  Or would be if I could
get ABCL to print non-ASCII! ;-)

ASDF-TEST(7): (load "test-encodings.script")
  0: (LOAD