Run with patched quicklisp

[Juan Jose Garcia-Ripoll]

As I mentioned before, the idea is to test all of quicklisp when one has fixed one or more libraries and see live how this changes influences the rest of the common lisp ecosystem.

It seems that the only changes required for that is 

1) to instruct cl-test-grid agent not to downloadquicklisp,

2) supply the desired directory

3) change the lib world name.

This all amounts to the interface of the "main" function. The diff file attached shows how I am trying to do it. Please comment.

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com

[Anton Vodonosov]

18.10.2012, 00:32, "Juan Jose Garcia-Ripoll" <juanjose.g...@gmail.com>:
> As I mentioned before, the idea is to test all of quicklisp when one has fixed one or more libraries and see live how this changes influences the rest of the common lisp ecosystem.It seems that the only changes required for that is

> 1) to instruct cl-test-grid agent not to downloadquicklisp,
> 2) supply the desired directory
> 3) change the lib world name.

> This all amounts to the interface of the "main" function.О©╫The diff file attached shows how I am trying to do it. Please comment.
> Juanjo

This patch should work. I've committed slightly fixed version of it:
https://github.com/cl-test-grid/cl-test-grid/commit/be405bc4a104eb400244c0056d55e66c1891f8cb

To make sure it really works as necessary, take a look into the
work-dir/agent/test-runs/20120919201615-ecl-12.7.1-c7faea1d-win-x86-lisp-to-c/asdf-output/private-quicklisp/
The .fasl files of all quicklisp libraries should be placed there -
that's how fresh recompilation is acheaved, by running with customized
ASDF output translations.

Your changes to ecl-reports.lisp are also commited.

Yesterday I've received 4 test runs:

quicklisp 2012-10-13
ecl-12.7.1-4b19fb3f-linux-x64-bytecode
ecl-12.7.1-4b19fb3f-linux-x64-lisp-to-c

In the lisp-to-c compiler results there are lot of CRASH
results, which means child ECL process exited without returning
a value to the parent agent process. Probably something
was bit wrong with your setup.

Just few examples:
https://cl-test-grid.appspot.com/blob?key=607011
https://cl-test-grid.appspot.com/blob?key=608020
https://cl-test-grid.appspot.com/blob?key=600015
https://cl-test-grid.appspot.com/blob?key=599867

quicklisp with ecl patches
ecl-12.7.1-4b19fb3f-linux-x64-bytecode
ecl-12.7.1-4b19fb3f-linux-x64-lisp-to-c

As you said before, the results in the "quicklisp with ecl patches"
do not contain closed-mop fixes and should be the same.
The strange CRASH results have gone.

So your setup seems to be OK now.

I am looking forward to see the results of fixed closer-mop.
Also I think it makes sense to re-run the test on non-patched
quicklisp.

PS, please pass more specific lib-world identifier - include
the base version of quicklisp and description of the changes.
Like "quicklisp 2012-10-13+closer-mop-ecl-fix-01". With your
patch the lib-world value is written into the library log headers,
so it would be good to record informative value there.

Best regards,
- Anton


PS, tomorrow I might be very busy, so don't guarantee
fast responses.

[Anton Vodonosov]

18.10.2012, 07:56, "Anton Vodonosov" <avodo...@yandex.ru>:

> To make sure it really works as necessary, take a look into the
> work-dir/agent/test-runs/20120919201615-ecl-12.7.1-c7faea1d-win-x86-lisp-to-c/asdf-output/private-quicklisp/
> The .fasl files of all quicklisp libraries should be placed there

check this while tests are run of course, before the test-run directory is deleted

[Juan Jose Garcia-Ripoll]

On Thu, Oct 18, 2012 at 5:56 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:

Yesterday I've received 4 test runs:

quicklisp 2012-10-13
  ecl-12.7.1-4b19fb3f-linux-x64-bytecode
  ecl-12.7.1-4b19fb3f-linux-x64-lisp-to-c

In the lisp-to-c compiler results there are lot of CRASH
results, which means child ECL process exited without returning
a value to the parent agent process. Probably something
was bit wrong with your setup.

No idea. Both these tests and the other ones were run in similarly configured directories, building ECL in the process and only differing in the quicklisp they used. Something must have gone awry.

 

quicklisp with ecl patches
  ecl-12.7.1-4b19fb3f-linux-x64-bytecode
  ecl-12.7.1-4b19fb3f-linux-x64-lisp-to-c

As you said before, the results in the "quicklisp with ecl patches"
do not contain closed-mop fixes and should be the same.
The strange CRASH results have gone.

Actually I uploaded the patches to this quicklisp before running the tests. However I did it by pusing a directory to quicklis/local-projects At home this seems to override any library that quicklisp has, but during testing it seemed to have no effect :-/

[Juan Jose Garcia-Ripoll]

On Thu, Oct 18, 2012 at 5:56 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:

This patch should work. I've committed slightly fixed version of it:
https://github.com/cl-test-grid/cl-test-grid/commit/be405bc4a104eb400244c0056d55e66c1891f8cb

Unfortunately private-quicklisp-dir (as function) is used internally in other places. This is why the previous tests showed no difference: cl-test-grid was still downloading and using quicklisp. To solve this I made this fix, which stores the quicklisp directory in the agent.

diff --git a/agent/agent.lisp b/agent/agent.lisp

index 9d8782d..05b3536 100644

--- a/agent/agent.lisp

+++ b/agent/agent.lisp

@@ -20,6 +20,7 @@

   ( ;; initial values for the base class slots

    (work-dir :initform (default-work-dir))

    ;; own slots

+   (quicklisp-dir :initform nil)

    (persistence :type persistence :accessor persistence)

    (blobstore :accessor blobstore :initform (make-gae-blobstore))

    (project-lister :type project-lister :accessor project-lister)))

@@ -49,7 +50,8 @@

   (merge-pathnames relative-path (work-dir agent)))

 

 (defun private-quicklisp-dir (agent)

-  (workdir-child agent #P"quicklisp/"))

+  (or (slot-value agent 'quicklisp-dir)

+      (workdir-child agent #P"quicklisp/")))

 

 (defun persistence-file (agent)

   (workdir-child agent "persistence.lisp"))

@@ -264,7 +266,9 @@ the PREDICATE."

         (check-config agent)

         (ensure-has-id agent)

         (say-hello-to-admin agent)

-        (let* ((quicklisp-dir (or quicklisp-dir (private-quicklisp-dir agent)))

+        (when quicklisp-dir

+          (setf (slot-value agent 'quicklisp-dir) quicklisp-dir))

+        (let* ((quicklisp-dir (private-quicklisp-dir agent))

                (lib-world (or lib-world (let ((quicklisp-version (update-testin

                                           (format nil "quicklisp ~A" quicklisp-

           (setf (project-lister agent)

[Anton Vodonosov]

Juan Jose, it would be necessary to re-run the test on your system.

>> О©╫О©╫ In the lisp-to-c compiler results there are lot of CRASH
>>О©╫О©╫О©╫ results, which means child ECL process exited without returning
>>О©╫О©╫О©╫ a value to the parent agent process. Probably something
>>О©╫О©╫О©╫ was bit wrong with your setup.

>
> No idea. Both these tests and the other ones were run in similarly configured directories, building ECL in the process and only differing in the quicklisp they used. Something must have gone awry.

Do you have messages from oom-killer in /var/log/syslog* ?
It is the only idea I have, because I had problem with oom-killer, although
as you run more powerful computer than my VPS I am not sure oom-killer is the cause.

> Unfortunately private-quicklisp-dir (as function) is used internally in other places.
> This is why the previous tests showed no difference: cl-test-grid was still downloading
> and using quicklisp. To solve this I made this fix, which stores the quicklisp directory
> in the agent

I've commited a fix with storing quicklisp directory as a property of the agent
like this:
https://github.com/cl-test-grid/cl-test-grid/commit/c8605b6a2559400ad22ccce2ad9223b3cfeebabf

Another problem it fixes is that local-projects directory in quicklisp was not
covered by custom ASDF output translations. Now I included local-proects into
the ASDF output translations, which means local-projects are recompiled
freshly at every test run.

I've decided to not include the parameters for running customized
quicklisp into the public API of the agent, because I think final solution
for custom lib-worlds will have somewhat different API.

Instead I've introduced separate (non exported) function, please call it like this:

(test-grid-agent::test-patched-quicklisp *agent* #P"C:\\Users\\anton\\quicklisp\\" "quicklisp 2012-10-13+my-patches")

About test results.

Check this report, it compares "quicklisp 2012-10-13" with "quicklisp 2012-10-13+closer-mop-ecl-fix-01"

(print-quicklisp-diff-report "ecl/quicklisp-diff.html"
*all-results*
"quicklisp 2012-10-13"
"quicklisp 2012-10-13+closer-mop-ecl-fix-01")

http://common-lisp.net/project/cl-test-grid/ecl/quicklisp-diff.html

It seems like your patched quicklisp distribution is actually
based on quicklisp 2012-09-09. It is the only way I can explain
many load of failures with "Cannot find the external symbol STRCAT in #<"ASDF" package>".

For example, :fare-utils. I've tested, it loads OK by ECL on quicklisp 2012-10-13
but fails on 2012-09-09 (and on "quicklisp 2012-10-13+closer-mop-ecl-fix-01").

Could you confirm this?

In short, I suggest to re-run the tests, both unpatched and patched quicklisps
(i.e. test-grid-agent:main and test-grid-agent::test-patched-quicklisp).

Then we will compare the results and see how closer-mop fixes affect them.

Best regards,
- Anton

[Juan Jose Garcia-Ripoll]

On Sat, Oct 20, 2012 at 7:55 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:

It seems like your patched quicklisp distribution is actually
based on quicklisp 2012-09-09. It is the only way I can explain
many load of failures with "Cannot find the external symbol STRCAT in #<"ASDF" package>".

For example, :fare-utils. I've tested, it loads OK by ECL on quicklisp 2012-10-13
but fails on 2012-09-09 (and on "quicklisp 2012-10-13+closer-mop-ecl-fix-01").

Could you confirm this?

It shouldn't be the case. Every night my computer runs quicklisp's update-client and update-all-dists. I understand this means the local copy should be equal to the latest release, am I wrong?

Juanjo

[Juan Jose Garcia-Ripoll]

On Sat, Oct 20, 2012 at 9:27 AM, Juan Jose Garcia-Ripoll <juanjose.g...@gmail.com> wrote:

It shouldn't be the case. Every night my computer runs quicklisp's update-client and update-all-dists. I understand this means the local copy should be equal to the latest release, am I wrong?

> (quicklisp-client:update-client)                                              

Installed version 2012081400 is as new as upstream version 2012081400. No updat\

e.                                                                              

T                                                                               

Seems that the quicklisp update procedure is botched on my system. I will download quicklisp again.

[Juan Jose Garcia-Ripoll]

On Sat, Oct 20, 2012 at 10:28 AM, Juan Jose Garcia-Ripoll <juanjose.g...@gmail.com> wrote:

On Sat, Oct 20, 2012 at 9:27 AM, Juan Jose Garcia-Ripoll <juanjose.g...@gmail.com> wrote:

It shouldn't be the case. Every night my computer runs quicklisp's update-client and update-all-dists. I understand this means the local copy should be equal to the latest release, am I wrong?

> (quicklisp-client:update-client)                                              

Installed version 2012081400 is as new as upstream version 2012081400. No updat\

e.                                                                              

T                                                                               

Seems that the quicklisp update procedure is botched on my system. I will download quicklisp again.

Sorry, I was mistaken about the version numbers that Anton was talking about. The client has an older version number than the list of libraries, which is the one he expected

* (quicklisp-client:update-all-dists)                                           

                                                                                

1 dist to check.                                                                

You already have the latest version of "quicklisp": 2012-10-13.                 

[Anton Vodonosov]

I've received new test results, for lisp-to-c compiler and lib-world named

"quicklisp 2012-10-13+closer-mop-ecl-fix-02".

This lib-world is indeed based on quicklisp 2012-10-10. (the previous results, for lib-world

"quicklisp 2012-10-13+closer-mop-ecl-fix-01" were definetely based on quicklisp 2012-09-09).

 

This report -

http://common-lisp.net/project/cl-test-grid/ecl/closer-mop-dependents.html

lists the 59 projects which we previously "blocked exclusively" by closer-mop,

i.e. which had the closer-mop as the only failing dependency.

 

Some of them now build ok, some still fail. You may review to see, wether

the failures are bugs in ECL or new closer-mop patches.

 

Would you re-run the tests for bytecode compier with

"quicklisp 2012-10-13+closer-mop-ecl-fix-02" and also both bytecode

and lisp-to-c with upatched "quicklisp 2012-10-13"?

 

Best regards,

- Anton

[Juan Jose Garcia-Ripoll]

On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:

Would you re-run the tests for bytecode compier with

"quicklisp 2012-10-13+closer-mop-ecl-fix-02" and also both bytecode

and lisp-to-c with upatched "quicklisp 2012-10-13"?

The last two were run yesterday. Didn't you get the results? I just used cl-test-grid as is, without invoking the patched loading routine.

Juanjo

[Juan Jose Garcia-Ripoll]

On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:

This report -

http://common-lisp.net/project/cl-test-grid/ecl/closer-mop-dependents.html

lists the 59 projects which we previously "blocked exclusively" by closer-mop,

i.e. which had the closer-mop as the only failing dependency.

 

Some of them now build ok, some still fail. You may review to see, wether

the failures are bugs in ECL or new closer-mop patches.

Your cl-test-grid system is really useful! :-) The following bug reports solve some of the issues

cl-dbi, dbd-postgress

https://github.com/fukamachi/cl-dbi/issues/4

cl-gpu, cl-gpu-tests

load fine after fixing ECL's type propagator for LOGAND

cl-protobufs-test

uses nonstandard declarations in DEFGENERIC

http://code.google.com/p/cl-protobuf/issues/detail?id=1

still does not load because of some compilation problems in the automatically generated file geodata

Will fix more things as I find time.

Juanjo

[Anton Vodonosov]

21.10.2012, 14:23, "Juan Jose Garcia-Ripoll" <juanjose.g...@gmail.com>:

> On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:
>> Would you re-run the tests for bytecode compier with
>> "quicklisp 2012-10-13+closer-mop-ecl-fix-02" and also both bytecode
>> and lisp-to-c with upatched "quicklisp 2012-10-13"?
>
> The last two were run yesterday. Didn't you get the results? I just used cl-test-grid as is, without invoking the patched loading routine.Juanjo

I didn't receive these results. Please check test gird agent logs in work-dir/agent/log
and check for linux OOM killer in /var/log/syslog* files

[Anton Vodonosov]

21.10.2012, 16:04, "Juan Jose Garcia-Ripoll" <juanjose.g...@gmail.com>:

> On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodo...@yandex.ru> wrote:
>> This report -
>> http://common-lisp.net/project/cl-test-grid/ecl/closer-mop-dependents.html
>> lists the 59 projects which we previously "blocked exclusively" by closer-mop,
>> i.e. which had the closer-mop as the only failing dependency.
>>
>> Some of them now build ok, some still fail. You may review to see, wether
>> the failures are bugs in ECL or new closer-mop patches.
>

> Your cl-test-grid system is really useful! :-) The following bug reports solve some of the issuescl-dbi, dbd-postgress

> https://github.com/fukamachi/cl-dbi/issues/4
> cl-gpu, cl-gpu-tests
> load fine after fixing ECL's type propagator for LOGAND
>
> cl-protobufs-test
> uses nonstandard declarations in DEFGENERIC
> http://code.google.com/p/cl-protobuf/issues/detail?id=1
> still does not load because of some compilation problems in the automatically generated file geodata
> Will fix more things as I find time.

I suggest for you to not be distracted by 3rd party libraries, lets
finish with closer-mop, then I will show you some bugs in ECL
(I didn't show everything to not over-flood you with information).

[Juan Jose Garcia-Ripoll]

On Sun, Oct 21, 2012 at 2:39 PM, Anton Vodonosov <avodo...@yandex.ru> wrote:

I didn't receive these results. Please check test gird agent logs in work-dir/agent/log

and check for linux OOM killer in /var/log/syslog* files

I just discovered I am sitting before even a worse firewall at this hotel -- no ssh port, therefore no way to log in to the machines where I run tests. It is also inconvenient that I cannot upload the fixes I mentioned before.

I suggest for you to not be distracted by 3rd party libraries, lets
finish with closer-mop, then I will show you some bugs in ECL
(I didn't show everything to not over-flood you with information).

No distraction here: it is simply that I have to go through each library seeing whether the bug report indicates a CLOS/MOP problem or not and sometimes this easily spots another problem which can be fixed.