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?
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.
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 ? 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.
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?
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.
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?
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.
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.
I'm learning Lisp right now so I'll definitely try this out when I get home. It's nice to go and read other's Lisp projects.
I love the brevity of this code! Awesome work.
Are you on Lainchan?
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?
Take a look at the first picture in your readme :)
Oooh... this is really obvius >.< Thanks. It's because I'm really a big Lain fan. Lain for all.
I love Lain.
Lainchan has a bunch of Lisp programmers and it looks like you have a "lain" reference in your screenshot.
besides, that shows me how well readable lisp code is. even better than python.
And it AOT compiles to native code when needed.
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.
Agreed. Except format strings and stream formatting and printing options get confusing quickly.
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.
If you are more proficient in Lisp than Python, your Lisp will be more readable than your Python.
LISP has no syntactic sugar. It only shows you the important parts, and it does so purely: it shows them just as they are.
Lisp not only has syntactic sugar (quote, backquote, all the sharpsign[1] macros), it is possible to add your own syntactic sugar (e.g. [2])
1: http://www.lispworks.com/documentation/HyperSpec/Body/02_dh....
2: http://weitz.de/cl-interpol/
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.
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?
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.
As you requested: https://ghostbin.com/paste/zba9f
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?
Add this:
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.)
Seems pretty nice! Thanks for share it.
My pleasure. If you do decide to integrate it let me know.
read eval transport print loop
RETPL. HAHAHA
Read & Output To File Loop.
;).
is this a common acronym ?
I think maybe lerax had a dyslexic moment and thought it was REPTL, which would be a little funny (reptile).
I thought it was a ROTFL synonym...
Very interesting
Cool.
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.
https://www.quicklisp.org/beta/bundles.html
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.
The writer has good taste
Thanks.
Ps.: Lain + Lisp?
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?
Internet Relay Chat: Client Protocol https://tools.ietf.org/html/rfc2812
Internet Relay Chat: Server Protocol https://tools.ietf.org/html/rfc2813
I think many people overestimate how complicated the IRC protocol is. A minimal IRC client is much less work than one would expect.
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.
Thanks for looking it, anyway.
Why did you choose SBCL among the several other common choices available? Thanks.
Not the OP, but my guess would be because SBCL is the fastest known free implementation of Common Lisp.
Yes.
Well done, manoel
HAHAHAHAHA. Thanks.
Was my first front-end on HN.