flambard / cleric Goto Github PK

In quicklisp 2012-12-23 cleric fails to build on some lisps like CCL, ACL, wile on the previous quicklisp it build on these lisps OK.

Check the library test-grid page: http://common-lisp.net/project/cl-test-grid/library/cleric.html
Click the failure links to open the build logs.

Some examples:
ACL: http://cl-test-grid.appspot.com/blob?key=1001268
CCL: http://cl-test-grid.appspot.com/blob?key=973288

There's no documentation for CLERIC.

Please write an API reference. Check out tools for generating reference documentation.

CLERIC does not know how to compress and uncompress external Erlang terms.

CLERIC signals an error when receiveing a message with compressed terms.
It's not possible to compress the terms in an outgoing message.

A Common Lisp zlib library is needed.

The domain cl-user.net has fallen prey to porn sites, but the page at https://common-lisp.net/project/cleric/ still mentions that website. It should be updated.

There should be some clearly defined way of making user defined data types 'Erlang translatable'.

i.e. define the CLERIC:ENCODE method for your new data type and make it transform your object into valid Erlang terms.

When a new data type is Erlang translatable it must also be a subtype of ERLANG-TRANSLATABLE (see type-erlang-translatable.lisp.)

Found on SBCL on Mac OS X.

For some reason the handshake challenge fails when running on SBCL.

It's currently not possible to make CLERIC listen for incoming connections from other nodes.

I get this: Unhandled ASDF/FIND-COMPONENT:MISSING-DEPENDENCY in thread #<SB-THREAD:THREAD "main thread" RUNNING {10008E8083}>: Component :ERLANG-TERM-TRIVIA not found, required by #<SYSTEM "erlang-term-optima">

The documentation at https://common-lisp.net/project/cleric/doc/ gives me HTTP 403 Forbidden.

Hi,

Since quicklisp 2014-02-11 CLERIC doesn't load on CLISP and ACL:
http://common-lisp.net/project/cl-test-grid/ql/quicklisp-2014-02-11-diff2.html

The error is

COMMON-LISP:SUBTYPEP: invalid type specification COMMON-LISP-ERLANG-INTERFACE::OCTET

Sorry for the late notice, I was overloaded at that time, so didn't manage to report all the regressions.

While connecting to an Elixir node (based on Erlang/OTP 23) I get:

On the Elixir node in iex:
"08:08:43.722 [error] ** :"[email protected]": Connection attempt from node :lispnode@localhost rejected since it cannot handle ['BIG_CREATION', 'UTF8_ATOMS', 'NEW_FUN_TAGS'].**"

On the Lisp side (AllegroCL 10.1 Enterprise Edition):
#<HANDSHAKE-FAILED-ERROR @ #x100079433f2>
[Condition of type COMMON-LISP-ERLANG-INTERFACE:HANDSHAKE-FAILED-ERROR]

Backtrace:
0: (ERROR COMMON-LISP-ERLANG-INTERFACE:HANDSHAKE-FAILED-ERROR :REASON "Connection not allowed")
Locals:
EXCL::DATUM = COMMON-LISP-ERLANG-INTERFACE:HANDSHAKE-FAILED-ERROR
EXCL::ARGUMENTS = (:REASON "Connection not allowed")
EXCL::LOCAL-0 = (:REASON "Connection not allowed")
(:DEAD EXCL::LOCAL-1) = COMMON-LISP-ERLANG-INTERFACE:HANDSHAKE-FAILED-ERROR
(:DEAD EXCL::LOCAL-2) = #(22659694466373723 T (CLERIC-HANDSHAKE-PROTOCOL::MESSAGE-LENGTH CLERIC-HANDSHAKE-PROTOCOL::TAG CLERIC-HANDSHAKE-PROTOCOL:STATUS) #() # 0 ...)
(:DEAD EXCL::LOCAL-3) = #<COMMON-LISP-ERLANG-INTERFACE:HANDSHAKE-FAILED-ERROR @ #x100079433f2>
(:DEAD EXCL::LOCAL-4) = 97
:UNKNOWN = NIL

I truly need this to work. May I get support on enabling these features?
Thank you!

// Frank

Using code from:
https://github.com/JonathanSmith/Lisp-on-Yaws

Sorry for the complex setup to reproduce... It is a new project and haven't gotten my build script in order...
(Perhaps you can reproduce with a simpler example).
You will have to run make on yaws and lfe, subdirectories in /3rdparty as well as running ./yawstart and doing.

c(ybed_sup).
c(ybed).

Erlang Output (Terminal 1):

jon@jon-desktop:~/Dropbox/Lisp-on-Yaws$ ./yawstart
Eshell V5.8.4 (abort with ^G)
([email protected])1> ybed_sup:start_link().
{ok,<0.39.0>}
([email protected])2>
=INFO REPORT==== 1-Aug-2011::22:29:45 ===
Yaws: Listening to 0.0.0.0:8080 for <1> virtual servers:

• http://foobar:8080 under /home/jon/Dropbox/Lisp-on-Yaws/www

%%%this happens after running (init) in the lisp buffer.

=ERROR REPORT==== 1-Aug-2011::22:29:51 ===
'[email protected]' got a corrupted external term from 'lispnode@localhost' on distribution channel 7842
<<...,104,4,97,6,103,115,18,108,105,115,112,110,111,100,101,64,108,111,99,97,108,104,111,115,116,0,0,0,1,0,0,0,0,1,82,0,82,1,104,3,82,2,107,0,11,104,101,108,108,111,95,119,111,114,108,100,107,0,137,40,100,101,102,109,111,100,117,108,101,32,104,101,108,108,111,95,119,111,114,108,100,32,40,101,120,112,111,114,116,32,40,111,117,116,32,49,41,41,41,10,40,105,110,99,108,117,100,101,45,102,105,108,101,32,34,105,110,99,108,117,100,101,47,121,97,119,115,95,97,112,105,46,108,102,101,34,41,10,40,103,101,110,95,114,101,115,111,117,114,99,101,115,32,108,105,115,112,110,111,100,101,64,108,111,99,97,108,104,111,115,116,32,40,40,104,101,108,108,111,95,119,111,114,108,100,32,71,69,84,32,40,41,41,41,41,10>>
ATOM_CACHE_REF translations: none

Lisp Dump (run through emacs, having loaded 'yaws_embed.lisp' through most recent quicklisp, loaded (ql:quickload "CLERIC"...) configured the yaws-server-node-name and cookie-file path in the lisp file... ./yawstart and ybed_sup:start_link() is already running...):

• (init)

Lisp Backtrace:
Couldn't write to #<SB-SYS:FD-STREAM
for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021"
{1003C3E2C1}>:
Broken pipe
[Condition of type SB-INT:SIMPLE-STREAM-ERROR]

Restarts:
0: [TERMINATE-THREAD] Terminate this thread (#<THREAD RUNNING {100575EE51}>)

Backtrace:
0: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {1003C3E2C1}> 32)
Locals:
SB-DEBUG::ARG-0 = "Couldn't write to ~s"
SB-DEBUG::ARG-1 = #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {100..
SB-DEBUG::ARG-2 = 32
1: (SB-IMPL::FLUSH-OUTPUT-BUFFER #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {1003C3E2C1}>)
Locals:
SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {100..
2: (SB-IMPL::FINISH-FD-STREAM-OUTPUT #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {1003C3E2C1}>)
Locals:
SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {100..
3: (FINISH-OUTPUT #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {1003C3E2C1}>)
Locals:
STREAM = #<SB-SYS:FD-STREAM for "socket 127.0.0.1:48100, peer: 127.0.1.1:37021" {100..
4: (FINISH-OUTPUT #<FLEXI-STREAMS:FLEXI-IO-STREAM {1003C41FC1}>)
Locals:
STREAM = #<FLEXI-STREAMS:FLEXI-IO-STREAM {1003C41FC1}>
5: (COMMON-LISP-ERLANG-INTERFACE::READ-NODE-MESSAGE #<FLEXI-STREAMS:FLEXI-IO-STREAM {1003C41FC1}>)
Locals:
SB-DEBUG::ARG-0 = #<FLEXI-STREAMS:FLEXI-IO-STREAM {1003C41FC1}>
6: (COMMON-LISP-ERLANG-INTERFACE:RECEIVE-NODE-MESSAGES :TIMEOUT NIL)
Locals:
#:TIMEOUT-DEFAULTING-TEMP = NIL
7: ((LAMBDA ()))
[No Locals]
8: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK360]365))
[No Locals]
9: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
[No Locals]
Catch-tags:
SB-IMPL::%END-OF-THE-WORLD
SB-INT:TOPLEVEL-CATCHER
10: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300))
[No Locals]
11: (SB-THREAD::CALL-WITH-MUTEX ..)
Locals:
SB-DEBUG::ARG-0 = #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {7FFFF50FECC9}>
SB-DEBUG::ARG-1 = #S(SB-THREAD:MUTEX ..)
SB-DEBUG::ARG-2 = #<SB-THREAD:THREAD RUNNING {100575EE51}>
SB-DEBUG::ARG-3 = T
12: (SB-THREAD::INITIAL-THREAD-FUNCTION)B
[No Locals]
13: ("foreign function: call_into_lisp")
[No Locals]
14: ("foreign function: new_thread_trampoline")
[No Locals]
--more--

It seems that the issue is erlang term encoding..

This example works with the older version of the library from quicklisp... from the archives dated 2011-06-19.
It produces an yaws appmod at the server running on 0.0.0.0::8080/hello_world/ that returns "hello world" when visited via web browser. When (add-math-appmod) is invoked, (via the lisp repl), it produces an appmod at /math/ which takes an operator and two numbers. ex. 0.0.0.0:8080/math/+/2/3/ will return a web page with 5, 0.0.0.0:8080/math/*/2/3/ page with 6, etc.