Error of type NO-RESPONSE

[david....@genworks.com]

Hi, 

I am trying to get the test-grid running on Windows. 

First problem was issues with loading libssl32.dll which I think I solved by copying (from the openssh.exe distribution which ships with Allegro):

  ssleay32.dll into c:/windows/libssl32.dll  and 

  libeay32.dll into c:/windows/libeay32.dll

The problem I foresee with this, tough, is there are 32-bit versions of these as well as 64-bit versions (both named with "32" in the name, confusingly!) and on Windows I'm not sure how a 64-bit Lisp and 32-bit Lisp will know how/where to look for the correct library (I plan to run tests both for 32-bit Allegro CL and 64-bit Allegro CL, probably concurrently, with different lock ports and different work-dirs). 

Anyway for the initial bootstrap load of wx86cl64 I got past the cl+ssl error. 

For the next error I am not seeing an obvious cause. The next error is:

   http://paste.lisp.org/display/139923

Is this a common error with a common cause?

Regards,

 

 Dave

[Anton Vodonosov]

14.11.2013, 09:13, "david....@genworks.com" <david....@genworks.com>:
> Hi,
>
> I am trying to get theО©╫test-gridО©╫running on Windows.

>
> First problem was issues with loading libssl32.dll which I think I solved by copying (from the openssh.exe distribution which ships with Allegro):
>

> О©╫ ssleay32.dll into c:/windows/libssl32.dll О©╫and
> О©╫ libeay32.dll into c:/windows/libeay32.dll

>
> The problem I foresee with this, tough, is there are 32-bit versions of these as well as 64-bit versions (both named with "32" in the name, confusingly!) and on Windows I'm not sure how a 64-bit Lisp and 32-bit Lisp will know how/where to look for the correct library (I plan to run tests both for 32-bit Allegro CL and 64-bit Allegro CL, probably concurrently, with different lock ports and different work-dirs).
>

> Anyway for the initial bootstrap load of wx86cl64 I got past theО©╫cl+ssl error.

I install OpenSSL for Windows from here:
http://slproweb.com/products/Win32OpenSSL.html

I have two versions, they are installed in directories
C:\Program Files\OpenSSL-Win64\
C:\Program Files (x86)\OpenSSL-Win32\

So I can run both 64bit and 32bit CCL and (ql:quickload "cl+ssl")

Note, that CL libraries may depend on other foreign libraries.
You are not required to install all the foreign libraries.
If test fails due to absence of foreign library, cl-test-grid
recognizes it and ads an "ffi" hint to this failure in reports.

You only need to get your main tg-agent program working.
Still, it is desirable that you have OpenSSL available for testing,
that will give more test results.

> For the next error I am not seeing an obvious cause. The next error is:
>

> О©╫ О©╫http://paste.lisp.org/display/139923

>
> Is this a common error with a common cause?
>

Something wrong with the wx86cl64.exe. tg-agent asks it to evaluate
a lisp code, but it fails. You can try manually the command from the log:

f:/cl-engines/windows/ccl/wx86cl64.exe "--no-init" "--eval" "(load #P\"F:/cl-test-grid/agent/proc-common.lisp\")" "--eval" "(set-response #P\"C:/Users/dcooper8/work-dir-acl-32-non-smp/response3143746795260408820.lisp\" \"abcs *() { /d e11 \")" "--eval" "(ccl:quit)"

and see what is wrong.

Best regards,
- Anton

[Dave Cooper]

   Something wrong with the wx86cl64.exe. tg-agent asks it to evaluate

a lisp code, but it fails. You can try manually the command from the log:

   f:/cl-engines/windows/ccl/wx86cl64.exe "--no-init" "--eval" "(load #P\"F:/cl-test-grid/agent/proc-common.lisp\")" "--eval" "(set-response #P\"C:/Users/dcooper8/work-dir-acl-32-non-smp/response3143746795260408820.lisp\" \"abcs *() { /d e11 \")" "--eval" "(ccl:quit)"

and see what is wrong.

Hmm... it's really strange --- that command seems to run fine from the "cmd" command line and from cygwin. It runs CCL and exits with no complaints. And the responsexxxx.lisp file is created. 

So I suppose the next thing to check into would be external-program:start or external-program:run? 

[Anton Vodonosov]

15.11.2013, 01:02, "Dave Cooper" <david....@genworks.com>:
> О©╫ О©╫Something wrong with the wx86cl64.exe. tg-agent asks it to evaluate

>> a lisp code, but it fails. You can try manually the command from the log:
>>

>> О©╫ О©╫f:/cl-engines/windows/ccl/wx86cl64.exe "--no-init" "--eval" "(load #P\"F:/cl-test-grid/agent/proc-common.lisp\")" "--eval" "(set-response #P\"C:/Users/dcooper8/work-dir-acl-32-non-smp/response3143746795260408820.lisp\" \"abcs *() { /d e11 \")" "--eval" "(ccl:quit)"

>>
>> and see what is wrong.
>
> Hmm... it's really strange --- that command seems to run fine from the "cmd" command line and from cygwin. It runs CCL and exits with no complaints. And the responsexxxx.lisp file is created.
>
> So I suppose the next thing to check into would be external-program:start or external-program:run?

If this command work, I would even try to run tg-agent again.
Usually, trying the command manually reveals the reason
of the problem. If the command works manually, it's difficult
to imagine what prevents it from working under tg-agent.

Yes, external-program:start is the basis of the failing functionality.
Also, here is a test-case to reproduce a bit simplified
form of what agent does:

(ql:quickload :test-grid-agent)

(defparameter *ccl-1.8-x86*
(make-instance 'lisp-exe:ccl
:exe-path "C:\\Users\\anton\\unpacked\\ccl\\ccl-1.8-windows\\wx86cl.exe"))

;; start child lisp process and ask it so save it's lisp-implemention-type in a file
(lisp-exe:run-with-timeout 30 *ccl-1.8-x86*
'(with-open-file (out "/Users/anton/result.txt"
:direction :output
:if-exists :supersede
:if-does-not-exist :create)
(princ (lisp-implementation-type) out)))

(alexandria:read-file-into-string "/Users/anton/result.txt") => "Clozure Common Lisp"


I am online in skype and google hangouts and can assist
in an interactive way.

Best regards
- Anton

[Dave Cooper]

Hi,

Yes, external-program:start is the basis of the failing functionality.
Also, here is a test-case to reproduce a bit simplified
form of what agent does:

Thank you, the simplified test case helped me to track it down. 

The issue appears to be that this bug:

   http://trac.clozure.com/ccl/ticket/858

is fixed in CCL 1.9, so the escaping workaround is not needed (and indeed causes failure) for CCL >= 1.9. 

I've attached a patch to stop the superfluous escaping if :ccl-1.9 is detected in the *features* --- I'm not sure if this is the most robust approach to handle this, maybe it would be better to check for CCL version >= 1.9, but apparently they do list all previous CCL versions in the *features* list anyway so even for CCL 1.10 and beyond I expect :ccl-1.9 feature will still be there. 

This patch also fixes a small typo in the message from run-with-timeout, and increases the timeout value for the Quicklisp project-lister from 60 to 180 (I was experiencing timeouts with the value of 60, when running several concurrent agents). 

 

(ql:quickload :test-grid-agent)

(defparameter *ccl-1.8-x86*
  (make-instance 'lisp-exe:ccl
                 :exe-path "C:\\Users\\anton\\unpacked\\ccl\\ccl-1.8-windows\\wx86cl.exe"))

;; start child lisp process and ask it so save it's lisp-implemention-type in a file
(lisp-exe:run-with-timeout 30 *ccl-1.8-x86*
    '(with-open-file (out "/Users/anton/result.txt"
                          :direction :output
                          :if-exists :supersede
                          :if-does-not-exist :create)
       (princ (lisp-implementation-type) out)))

(alexandria:read-file-into-string "/Users/anton/result.txt") => "Clozure Common Lisp"


I am online in skype and google hangouts and can assist
in an interactive way.

Best regards
- Anton

--
My Best,

Dave Cooper, Genworks Support

[Anton Vodonosov]

15.11.2013, 08:56, "Dave Cooper" <david....@genworks.com>:

> Hi,
>
>> Yes, external-program:start is the basis of the failing functionality.
>> Also, here is a test-case to reproduce a bit simplified
>> form of what agent does:
>
> Thank you, the simplified test case helped me to track it down.
>
> The issue appears to be that this bug:
>

> О©╫ О©╫http://trac.clozure.com/ccl/ticket/858

>
> is fixed in CCL 1.9, so the escaping workaround is not needed (and indeed causes failure) for CCL >= 1.9.
>
> I've attached a patch to stop the superfluous escaping if :ccl-1.9 is detected in the *features* --- I'm not sure if this is the most robust approach to handle this, maybe it would be better to check for CCL version >= 1.9, but apparently they do list all previous CCL versions in the *features* list anyway so even for CCL 1.10 and beyond I expect :ccl-1.9 feature will still be there.
>
> This patch also fixes a small typo in the message from run-with-timeout, and increases the timeout value for the Quicklisp project-lister from 60 to 180 (I was experiencing timeouts with the value of 60, when running several concurrent agents).

I have applied the patch.
I believe it is safe to use :ccl-1.9 as you propose.

Best regards,
- Anton

[Dave Cooper]

Thanks.

 Anton, I'll reply to you separately regarding the current run on tests on Allegro/Windows...

On Fri, Nov 15, 2013 at 5:16 PM, Anton Vodonosov <avodo...@yandex.ru> wrote:

15.11.2013, 08:56, "Dave Cooper" <david....@genworks.com>:

> Hi,
>
>> Yes, external-program:start is the basis of the failing functionality.
>> Also, here is a test-case to reproduce a bit simplified
>> form of what agent does:
>
> Thank you, the simplified test case helped me to track it down.
>
> The issue appears to be that this bug:
>

>    http://trac.clozure.com/ccl/ticket/858
>
> is fixed in CCL 1.9, so the escaping workaround is not needed (and indeed causes failure) for CCL >= 1.9.
>
> I've attached a patch to stop the superfluous escaping if :ccl-1.9 is detected in the *features* --- I'm not sure if this is the most robust approach to handle this, maybe it would be better to check for CCL version >= 1.9, but apparently they do list all previous CCL versions in the *features* list anyway so even for CCL 1.10 and beyond I expect :ccl-1.9 feature will still be there.
>
> This patch also fixes a small typo in the message from run-with-timeout, and increases the timeout value for the Quicklisp project-lister from 60 to 180 (I was experiencing timeouts with the value of 60, when running several concurrent agents).

I have applied the patch.
I believe it is safe to use :ccl-1.9 as you propose.

Best regards,
- Anton

--
My Best,

Dave Cooper, Genworks Support

david....@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699