freenode/#lisp - IRC Chatlog
Search
10:36:56
makomo
Shinmera: neat, good job. :-) the "[SRC]" links seem to be broken though -- "file:///..."?
10:45:01
makomo
Shinmera: :-). also, nice work on the docs. i'm always pleasantly surprised whenever i find a project of yours, because it usually has a wall of text (in a good sense) accompanying it
10:46:26
makomo
and it's not just the classical "here's an example" thing. you actually describe the concepts and introduce the terminology, i.e. give the person a theoretical understanding of the project
15:40:58
Shinmera
I'm also happy to announce that another Lisp website is finished: http://studio.tymoon.eu/ https://github.com/Shirakumo/studio
16:05:55
pjb
drmeister: I'd suggest a network dump, to check if the message is transmitted (is it lost before sending or after receiving?)
16:08:19
drmeister
I have a tiny example now of a python program that sends a request and waits for a response and a common lisp script that waits for a request and sends a response. The common lisp script sends the response but the python script doesn't receive it.
16:09:59
drmeister
The common lisp script works in cando - I'm currently trying to get it to work in sbcl.
16:21:05
drmeister
That contains the stuff that I'm sending. What is the localhost.54007 ? Is that the python code sending this out on another port?
16:21:52
drmeister
Here is the output of the Common Lisp script ( I can post the script as well - but it is longish)
16:39:15
pjb
If you don't seen any other packet, then it means the problem is on the sending lisp side.
17:06:48
drmeister
I suspect the problem is the identities part - because I had to add code to deal with the non-string nature of zmq's default identities.
17:14:18
trittweiler
drmeister: if you can't see any outgoing packet from 127.0.0.1:9734, then dive into pzmq:send. Does that have any kind of meaningful return value? Maybe the data is waiting in a buffer, and needs to be flushed out
17:15:48
drmeister
The main detail to notice when reading the man page is the requirement for adding in a null (empty) message part between the identity routing information prepended to all messages and the message body containing the application-level data. This null message part is used as a delimiter to separate routing information from application-level data. When communicating to/from REQ/REP sockets, the routing information is silently
17:15:48
drmeister
processed by the framework up to the null message part; the framework then hands off the remaining message parts to your application for processing.
17:17:12
trittweiler
presumably, the python side is doing that automatically? If that's the case you can inspect the request to get an idea how null/empty is supposed to look at the wire
17:19:04
drmeister
The python side isn't doing that - because I don't send an identity - my understanding is that the Python side will create an identity of the form #(0 w x y z) where w x y z are octets that code for a 4-byte random value integer.
17:19:37
drmeister
I'm trying different combinations of null in the python and null in the Common Lisp.
17:21:03
drmeister
No combination of b'' in the python and "" in the common lisp appear to change the behavior.
17:30:09
Colleen
Function emptyp https://common-lisp.net/project/alexandria/draft/alexandria.html#index-emptyp-137
18:37:52
shka_
i think that's because arch put it into /usr/include/hwloc/cuda.h instead of /usr/include/cuda.h