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.
18.10.2012, 00:32, "Juan Jose Garcia-Ripoll" <juanjose.garciarip...@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
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.
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.
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.
> 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
> 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 :-/
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)))
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
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:
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.
On Sat, Oct 20, 2012 at 7:55 AM, Anton Vodonosov <avodono...@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?
On Sat, Oct 20, 2012 at 9:27 AM, Juan Jose Garcia-Ripoll <
juanjose.garciarip...@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.
juanjose.garciarip...@gmail.com> wrote:
> On Sat, Oct 20, 2012 at 9:27 AM, Juan Jose Garcia-Ripoll <
> juanjose.garciarip...@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.
On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodono...@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.
21.10.2012, 14:23, "Juan Jose Garcia-Ripoll" <juanjose.garciarip...@gmail.com>:
> On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodono...@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
> On Sun, Oct 21, 2012 at 3:05 AM, Anton Vodonosov <avodono...@yandex.ru> wrote:
>> This report -
>> http://common-lisp.net/project/cl-test-grid/ecl/closer-mop-dependents... >> 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).
On Sun, Oct 21, 2012 at 2:39 PM, Anton Vodonosov <avodono...@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.
