Chun Tian
Hi, it seems that the design of `usocket:with-client-socket` never consider the possible case that the user may have another `handle-case` with their own condition types being handled. In another words,...
Hi Anton, sorry for the delay. I think I know what's happening. In some usocket backends (SBCL and LW, etc.), the implementation of `handle-condition` (internal of `usocket:with-mapped-conditions`) tries capture all...
> I also looked at the code change briefly. Looks fine too. One cosmetic note - on MKCL the internal function `raise-error` now has unused, dead code, [f2c176f#diff-5f261b86dbedbd79b8e0adde7cd545195e84900b8a47dc164ac485bc45161559R14](https://github.com/usocket/usocket/commit/f2c176f417200387bc7e3c974d844ba0d5f1f013#diff-5f261b86dbedbd79b8e0adde7cd545195e84900b8a47dc164ac485bc45161559R14). > >...
Hi, I have added your macro into `usocket.lisp`. Thanks for your advice and contribution. This macro looks useful for end users. For the gist you mentioned, I've left a message...
A potential issue of my above algorithm is that, if a list equation is partially-simplifiable, then the output will have all `SNOC` eliminated: ``` > listSimps.LIST_EQ_SIMP_CONV ``a::SNOC x l =...
Hi, if you send data by `format`, it's assumed that you are sending character data and there will be an extra character indicating the termination of "line". Since you are...
Hello, I think `(read-byte (usocket:socket-stream server))` is the correct way, while `(read-byte (usocket:socket server))` may also work for those backends in which the underlying "socket" (TCP) is also a valid...
> > poor interface of `socket-connect` which takes an optional and rest arguments > > Agreed, @binghe how about introducing new interface `socket-connect-domain` to get rid of this rabbit hole?...
With f5beb2b7 and afc13a37, perhaps all issues mentioned are gone. Testers needed.