00:44:47 dto [~user@pool-96-252-62-13.bstnma.fios.verizon.net] has joined #ccl 00:51:55 what would cause (load "asdf.lisp") to sit forever in the pipe_wait stage? 00:52:17 doing (load "test.lisp") where it prints a simple message to stdout, that works fine. 01:00:09 -!- dto [~user@pool-96-252-62-13.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 01:10:35 -!- jangle [~jimmy1984@198.151.8.4] has quit [Quit: jangle] 02:28:00 -!- DataLinkDroid [~DataLinkD@1.148.13.205] has quit [Quit: Bye] 02:41:21 -!- brucem [~bmitchene@waywardmonkeys.com] has quit [Quit: ZNC - http://znc.sourceforge.net] 02:54:35 jangle [~jimmy1984@ip-64-134-188-93.public.wayport.net] has joined #ccl 03:04:58 dto [~user@pool-96-252-62-13.bstnma.fios.verizon.net] has joined #ccl 03:10:32 -!- dto [~user@pool-96-252-62-13.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 03:11:33 brucem [~bmitchene@waywardmonkeys.com] has joined #ccl 03:42:48 bfulgham [~brent@c-24-130-218-134.hsd1.ca.comcast.net] has joined #ccl 04:41:41 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Read error: Connection reset by peer] 04:51:13 -!- bfulgham [~brent@c-24-130-218-134.hsd1.ca.comcast.net] has quit [Quit: bfulgham] 10:45:09 segv- [~mb@95-91-243-235-dynip.superkabel.de] has joined #ccl 10:59:17 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [*.net *.split] 10:59:24 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #ccl 12:49:40 -!- jangle [~jimmy1984@ip-64-134-188-93.public.wayport.net] has quit [Quit: jangle] 13:22:25 pnpuff- [~v_eskimo@unaffiliated/pnpuff] has joined #ccl 13:24:40 -!- pnpuff- [~v_eskimo@unaffiliated/pnpuff] has quit [Client Quit] 15:06:34 billstclair [~billstcla@p-68-237-142-18.dsl1.rtr.chat.fpma.frpt.net] has joined #ccl 15:06:34 -!- billstclair [~billstcla@p-68-237-142-18.dsl1.rtr.chat.fpma.frpt.net] has quit [Changing host] 15:06:34 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 15:09:21 -!- jagaj [~AdmiralBu@pool-71-99-141-240.tampfl.fios.verizon.net] has quit [Quit: jagaj] 15:47:48 pnpuff [~ln@unaffiliated/pnpuff] has joined #ccl 16:00:24 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 16:02:05 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Read error: Connection reset by peer] 16:11:07 jagaj [~AdmiralBu@pool-71-99-141-240.tampfl.fios.verizon.net] has joined #ccl 16:28:45 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 17:05:43 jangle [~jimmy1984@198.151.8.4] has joined #ccl 17:21:22 I'm trying to read from a stream socket made with ccl:with-open-socket 17:22:38 i'm finding that, while the clhs definition of (read-sequence) allows for the dest sequence to be larger than the amount of data in the input stream, and read-sequence will return 17:23:51 all of it. I'm finding that when I look for this behavior with a socket stream made by the ccl call, I can't seem to figure out how to read all data availalbe, regardless of the size of my target sequence passed to read-sequence 17:34:32 -!- pnpuff [~ln@unaffiliated/pnpuff] has quit [] 18:08:35 (coerce (loop while (cl:listen socket) collect (cl:read-char socket)) 'string) 18:32:15 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Read error: Connection reset by peer] 19:12:11 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Ping timeout: 264 seconds] 19:19:30 patrickwonders [~patrickwo@67-220-27-111.usiwireless.com] has joined #ccl 19:34:39 pjb: so eventually cl:listen will return nil when there is no more data to read, is that how I am to understand this? 19:43:03 billstclair [~billstcla@p-69-195-56-107.dsl1.rtr.chat.fpma.frpt.net] has joined #ccl 19:43:03 -!- billstclair [~billstcla@p-69-195-56-107.dsl1.rtr.chat.fpma.frpt.net] has quit [Changing host] 19:43:03 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 19:46:06 -!- jagaj [~AdmiralBu@pool-71-99-141-240.tampfl.fios.verizon.net] has quit [Quit: jagaj] 19:53:20 jagaj [~AdmiralBu@pool-71-99-141-240.tampfl.fios.verizon.net] has joined #ccl 20:01:49 jangle: yes, that's the purpose of listen. 20:02:54 Now the problem is that CL:LISTEN is specified apparently to work on interactive _character_ streams. Is a socket stream an interactive stream? Has it been open as a character stream? Is the implementation doing the right thing in CL:LISTEN on socket streams? 20:26:30 -!- patrickwonders [~patrickwo@67-220-27-111.usiwireless.com] has quit [Quit: patrickwonders] 20:27:58 pjb: I guess I can test it and find out huh 20:45:46 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 22:07:54 well, it looks like the packet takes a small amount of time to come back, so the the listen check immediately returns 22:30:20 You can always write a server that sends back packets with some delay. 22:43:57 DataLinkDroid [~DataLinkD@120.158.126.242] has joined #ccl 23:09:58 -!- segv- [~mb@95-91-243-235-dynip.superkabel.de] has quit [Remote host closed the connection] 23:12:19 but, a client somewhere still needs to wait for data, so I still need to handle the difference between cl:listen being nil due to no data yes vs no data anymore 23:12:34 or maybe I didn't understand what you meant 23:22:52 jangle: man 2 socket 23:23:13 Instead of SOCK_STREAM, you want to open the socket with SOCK_PACKET. 23:24:36 or SOCK_DGRAM (= udp) 23:24:54 tcp doesn't transmit "packet" boundaries, it implements a stream of bytes. 23:25:50 The presence of available bytes in buffers is mostly unrelated to the calls to write(2) on the sender side: packets can be rearranged by the various network nodes (eg. when the MTU changes). 23:33:13 ok, I get that. but the service I"m using to communicate with requires tcp. So I can't modify anything server side. But I understand what you're saying (except I've never heard of a packet type socket 23:34:19 I appreciate the suggestion however. 23:36:09 Usually, protocols are used. 23:36:18 For example, in English, we write a dot at the end of a sentence. 23:36:49 In HTTP, byte sequences 13 10 are used to finish 23:36:53 "packets". 23:37:14 (and for data "packets". Content-Length: headers are used. 23:37:15 ) 23:37:54 So the question is what protocol above TCP you're using? 23:40:49 a vendor proprietary protocol that does delimit message boundaries. but I see what you mean now. its my responsibility to know how the data is coming over tcp/udp, and there is no way for tcp to know when I'm done with a message 23:41:07 yes. 23:41:36 or when a message has been sent. I guess I've been dealing with data small enough to fit in one packet, making me think that I was able to use low level socket commands to consume the contents of one enitre packet, no matter whether it arrived over tcp or udp 23:42:12 Well, you can't really count on it. Some hardware require very small packets. You could really receive the data byte by byte. 23:42:58 Packets can be subdivided, when traversing networks with smaller MTU. 23:43:48 ok, that has been clarifying. 23:44:50 so i need to write my own things like "blocking read one message with a default timeout, report timeout failure or malformed packet" 23:44:58 er ^packet^message 23:45:44 Yes. In accordance to the protocol in question of course. (Protocols should specify those things). 23:51:26 thanks 23:53:50 so I guess, for ccl specifically and other implementations in general, can the socket handling code issue a timeout for me, if I want to kick out if there has been no incomoing data for a specific time? Or do I have to add that kind of stuff to my protocol