When I found both client.py and client.lisp, I thought it would be nice to see direct lisp/python comparison. However, turns out Python version does much more that Lisp one (it maintains edit field even if other people send the messages), so no direct comparison is possible.
Author, can you add a simplified python client with exactly the same functionality as the lisp one?
This is the simplified version making the same output of the lisp version.
I was wondering about race conditions when I try close the read stream on finally keyword. Seems crash sometimes. However I never got this on the Lisp version. Funny.
I hope you like it. Maybe I should push this version to the repository?
Yes, I can do it. The Python client version was a test about handling async STDOUT and STDIN nicely, as I related in other comment in this thread. Actually removing the ChatUI and other ncurses stuff, the rest both clients has the same functionality.
Thanks for look it! I did that as exercise to topics of multi-threading, streams and sockets using SBCL. I added later a Python version (using ncurses as bonus) to non-lispers can test.
On client written Lisp I have a problem with asynchronous STDIN and STDOUT yet. When the user is typing a message input, a message from server may comes and print in middle of the input, so the console will be mixed with stdin and stdou... a messy. .
After looking for a solution almost everybody points to use curses... but I was hesitant for it because I wish keep server and client as more simple possible. As was proposed, the Python client using curses doesn't has this problem and works fine.
Curious question about Lainchan. In another days I posted some programming related stuff on there and a personal music album. Why are you asking?
I'm not sure that using quicklisp that way is kosher. Quicklisp doesn't allow you to pin a particular version of a dependency. The upshot is that your code that works today may not work tomorrow.
I've been looking for a best practice and all I can seem to come up with is make a bundle and include it in your repo.
Quicklisp does let you pin to a particular release, or make your own distribution, both of which will handle this. There is also qlot for more fine-grained dependencies.
Yes. I was wondering about that after I wrote the two client versions! Lisp is really easy to read. I not write yet the docstrings, but still is easy to understand. As much as I enjoy reading code in Python, Lisp is also in my heart.
What ? maybe I'm stupid, but to me the python version seems a a lot more readable. It's only me ? (maybe because I don't know lisp, but neither python, so should be the same)
What programming languages do you know? If you know one or some algol-like one their syntax is very similar to each other and very different from lisp-like langs.
You can use a library like https://github.com/fiddlerwoaroof/format-string-builder to make formatted output more readable. But, in general, format strings are like regular expressions: at first they look like alien technology and then, after using them a while, they become quite legible.
What I do not understand: Why not write a simple IRC (or even XMPP) client – but an “IRC-like” client? The documentation is out there. Do people feel special when their software is incompatible with older software without having features that make incompatibility a necessity?
Last time I was thinking about it the number of non-standard extensions combined with there being multiple RFCs involved if you want to support more than minimal features led me not to consider it for my hobby/learning project.
Thanks for share the IRC's specifications. I wrote this little project just as a exercise of my studies from Common Lisp, basic concepts of multi-threading and TCP/IP sockets.
Sorry if this annoys you. You are correct, would be better implement a well-known protocol for chat like IRC, is unnecessary as you say. But I think is still useful for learning purposes.
https://github.com/rongarret/tweetnacl/blob/master/ratchet.l...
and you can turn this into a state-of-the art encrypted chat.
(Note that to really turn this into a secure chat you need to also add key management code. I'm working on that part now.)