ryukinix / lisp-chat

An experimental minimal chat written in Common Lisp

Lisp Chat

An experimental chat irc-like written in Lisp.

Installation

Install [roswell][ros] and add ~/.roswell/bin/ to the PATH variable.

After that just type:

ros install ryukinix/lisp-chat

Lisp-chat it's on Quicklisp as well, tested on the following implementations:

• SBCL
• CCL
• ECL

Usage

Load the server

$ lisp-chat-server localhost

Create a client

$ lisp-chat localhost

As alternative of localhost you can use server.lerax.me which points to a lisp-chat server running in the port 5558.

Alternative clients

If you want test this and don't have the Lisp requested, I have those alternatives for you:

• Terminal text-based python client
• Terminal ncurses python client
• Netcat client (wtf?)

On Python client, I wrote in a way only using ths stdlib avoiding pain to handle the dependency hell, so you can just call that:

$ python client.py

So finally... netcat. Yes! You can even just use netcat! An user called Chris in past days just logged in the server with the following message:

|16:30:37| [Chris]: Used netcad
|16:30:41| [Chris]: netcat*
|16:30:50| [Chris]: bye

So you can type netcat server.lerax.me 5558 and go on! I tested on my machine and works fine! The main reason is because the communication between server and client just use raw data. For better synchronization with text data from server while you typing, I suggest you to use a readline wrapper like rlwrap calling as rlwrap netcat server.lerax.me 5558.

lisp-chat's Issues

Write documentation for all the lisp functions at server.lisp and client.lisp

I need at least write the proper docstring for the data structures, functions and so on. Too obscure this shit.

• server.lisp
• config.lisp
• client.lisp

Client stops receiving and sending messages if idle for a while

If you log in the chat and stops sending messages, after a while the client will stop receiving and sending messages.

Give support to execute lisp-chat-client:main inside of a SLIME session

For now everything is fucked up if I call (lisp-chat-client:main) inside of SLIME REPL (Emacs).

sbcl-only?

Hi, I just noticed that this project is sbcl-only. If that remains the case I'm afraid it isn't suitable for Quicklisp.

Refactor project to complain with the quicklisp layout and integrate lisp-chat to quicklisp-projects repo

For now I'm using on each script QL for load the external libraries, but that symbol is not provide inside of quicklisp build environment as on quicklisp-project#1345.

So we need to fix that lines to be not processed on quicklisp:

• server.lisp#4
• client.lisp#5
• client.lisp#8

Why I just not delete them? Because I don't find a way yet to test that scripts without rely on quicklisp asdf build system on emacs. Maybe I should review my habits with emacs + cl development.

New logo for Lisp-Chat

I wanted to contribute to Lisp-Chat. I designed a logo for Lisp-Chat. If you like it, I'll send you files and pr.

Do not hesitate to say if there is something you want to change. Color bla bla...

Create a /nick command

This should able to change the nickname as IRC does.

Create a better lisp-chat client using curses because cl-readline sucks

This should be sufficient: https://github.com/HiTECNOLOGYs/cl-charms

cl-readline is too buggy about async events between input and server IO

Implement a GUI interface using McCLIM

https://common-lisp.net/project/mcclim/excite.html

Server stops message-broadcast thread when clients log with a win32 terminal

Using both python and lisp client occurs that bug. Is possible replicate running a fresh server instance and run a new client from a Windows prompt (cmd.exe or powershell.exe).

A server crash image is attached on this issue.

First the user-wide read thread is crashed because a STREAM-DECODING-ERROR condition (something with terminal of Windows, probably) and later a recursive lock happens on mutex of message broadcast.

The first time when this happened someone with name of federico at IP 191.102.210.96 logged into the server. BLAME FEDERICO!

Add coloring highlight on client-side

Should be implemented as regex substitution on client.lisp and client.py.

I plan to highlight the name of the users as well the date. The ideal is that each user can have a unique color to distinguish easily on a lisp-chat session.

Unhandled exception on lisp-chat-client

Typing something and pressing C-d (sending a EOF) i got this:

❯ lisp-chat
> Type your username: lerax
Connected as [email protected]:5558
|20:12:44| [@server]: The user "lerax" joined to the party!
|20:12:45| [lerax]: hi!
|20:12:54| [@server]: The user "ryukinix" joined to the party!
|20:12:58| [ryukinix]: oh yes!
|20:27:37| [@server]: The user "ryukinix" exited from the party :(
[lerax]: Unhandled TYPE-ERROR in thread #<SB-THREAD:THREAD "client sender" RUNNING
                                  {10029487B3}>:
  The value
    NIL
  is not of type
    STRING
  when binding STRING

Backtrace for: #<SB-THREAD:THREAD "client sender" RUNNING {10029487B3}>
0: (WRITE-LINE NIL #<SB-SYS:FD-STREAM for "socket 10.0.0.100:44790, peer: 138.197.65.96:5558" {1002947B83}>) [external]
1: (LISP-CHAT-CLIENT::SEND-MESSAGE NIL #<USOCKET:STREAM-USOCKET {1002677DD3}>)
2: (LISP-CHAT-CLIENT::CLIENT-SENDER #<USOCKET:STREAM-USOCKET {1002677DD3}> "lerax")
3: ((FLET "WITHOUT-INTERRUPTS-BODY-4" :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
4: ((FLET SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
5: ((FLET "WITHOUT-INTERRUPTS-BODY-1" :IN SB-THREAD::CALL-WITH-MUTEX))
6: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE) {7FFFF5C8ED1B}> #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "client sender" RUNNING {10029487B3}>> NIL T NIL)
7: (SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE #<SB-THREAD:THREAD "client sender" RUNNING {10029487B3}> NIL #<FUNCTION LISP-CHAT-CLIENT::CLIENT-SENDER> (#1=#<SB-THREAD:THREAD "client sender" RUNNING {10029487B3}> #<SB-THREAD:THREAD "main thread" waiting on: #<MUTEX "thread result lock" owner: #1#> {1001956713}>) (#<USOCKET:STREAM-USOCKET {1002677DD3}> "lerax") NIL NIL NIL)
8: ("foreign function: call_into_lisp")
9: ("foreign function: new_thread_trampoline")

Related function problem.

USOCKET:ADDRESS-IN-USE-ERROR

Sometimes I get that on server.lisp:

Nov 08 04:17:09 ustar lisp-chat[18971]: Unhandled USOCKET:ADDRESS-IN-USE-ERROR in thread #<SB-THREAD:THREAD
Nov 08 04:17:09 ustar lisp-chat[18971]:                                                    "main thread" RUNNING
Nov 08 04:17:09 ustar lisp-chat[18971]:                                                     {100399CFB3}>:
Nov 08 04:17:09 ustar lisp-chat[18971]:   Condition USOCKET:ADDRESS-IN-USE-ERROR was signalled.
Nov 08 04:17:09 ustar lisp-chat[18971]: Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {100399CFB3}>
Nov 08 04:17:09 ustar lisp-chat[18971]: 0: ((LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX))
Nov 08 04:17:09 ustar lisp-chat[18971]: 1: (SB-IMPL::CALL-WITH-SANE-IO-SYNTAX #<CLOSURE (LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX) {1005A2C72B}>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 2: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX) {1005A2C6FB}>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 3: (PRINT-BACKTRACE :STREAM #<SB-SYS:FD-STREAM for "standard error" {1007038393}> :START 0 :FROM :INTERRUPTED-FRAME :CONov 08 04:17:09 ustar lisp-chat[18971]: 4: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<USOCKET:ADDRESS-IN-USE-ERROR {10058F6313}> #<unavailable argument>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 5: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<USOCKET:ADDRESS-IN-USE-ERROR {10058F6313}>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 6: (INVOKE-DEBUGGER #<USOCKET:ADDRESS-IN-USE-ERROR {10058F6313}>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 7: (ERROR #<USOCKET:ADDRESS-IN-USE-ERROR {10058F6313}>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 8: (USOCKET:SOCKET-LISTEN "server.lerax.me" 5558 :REUSEADDRESS NIL :REUSE-ADDRESS NIL :BACKLOG 5 :ELEMENT-TYPE CHARACTENov 08 04:17:09 ustar lisp-chat[18971]: 9: (LISP-CHAT-SERVER:MAIN)
Nov 08 04:17:09 ustar lisp-chat[18971]: 10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LISP-CHAT-SERVER:MAIN) #<NULL-LEXENV>)
Nov 08 04:17:09 ustar lisp-chat[18971]: 11: (EVAL-TLF (LISP-CHAT-SERVER:MAIN) 2 NIL)
Nov 08 04:17:09 ustar lisp-chat[18971]: 12: ((LABELS SB-FASL::EVAL-FORM :IN SB-INT:LOAD-AS-SOURCE) (LISP-CHAT-SERVER:MAIN) 2)
Nov 08 04:17:09 ustar lisp-chat[18971]: 13: ((LAMBDA (SB-KERNEL:FORM &KEY :CURRENT-INDEX &ALLOW-OTHER-KEYS) :IN SB-INT:LOAD-AS-SOURCE) (LISP-CHAT-SERVER:MAIN)
Nov 08 04:17:09 ustar lisp-chat[18971]: 14: (SB-C::%DO-FORMS-FROM-INFO #<CLOSURE (LAMBDA (SB-KERNEL:FORM &KEY :CURRENT-INDEX &ALLOW-OTHER-KEYS) :IN SB-INT:LOADNov 08 04:17:09 ustar lisp-chat[18971]: 15: (SB-INT:LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file /home/lerax/projects/lisp-chat/lisp-chat-server" {10039A46D3}>
Nov 08 04:17:09 ustar lisp-chat[18971]: 16: ((FLET SB-FASL::LOAD-STREAM :IN LOAD) #<SB-SYS:FD-STREAM for "file /home/lerax/projects/lisp-chat/lisp-chat-server"Nov 08 04:17:09 ustar lisp-chat[18971]: 17: (LOAD #<SB-SYS:FD-STREAM for "file /home/lerax/projects/lisp-chat/lisp-chat-server" {10039A46D3}> :VERBOSE NIL :PRINov 08 04:17:09 ustar lisp-chat[18971]: 18: ((FLET SB-IMPL::LOAD-SCRIPT :IN SB-IMPL::PROCESS-SCRIPT) #<SB-SYS:FD-STREAM for "file /home/lerax/projects/lisp-chaNov 08 04:17:09 ustar lisp-chat[18971]: 19: ((FLET #:WITHOUT-INTERRUPTS-BODY-146 :IN SB-IMPL::PROCESS-SCRIPT))
Nov 08 04:17:09 ustar lisp-chat[18971]: 20: (SB-IMPL::PROCESS-SCRIPT "/home/lerax/projects/lisp-chat/lisp-chat-server")
Nov 08 04:17:09 ustar lisp-chat[18971]: 21: (SB-IMPL::TOPLEVEL-INIT)
Nov 08 04:17:09 ustar lisp-chat[18971]: 22: ((FLET #:WITHOUT-INTERRUPTS-BODY-82 :IN SAVE-LISP-AND-DIE))
Nov 08 04:17:09 ustar lisp-chat[18971]: 23: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))

This happened when I tried accessing multiple clients on the same machine through the http://chat.lerax.me

Create a better and efficient web-client interface

For now I'm using a modified version of gritty, but I have a lot of problems with it:

• it's slow
• it's written in NodeJS
• each client spawn a new lisp-chat process as terminal client with 100MB at cost (my server only have 500mb of RAM)
• it's buggy as well
• ... this form is to narrow to write all the problems

The main reason for being slow it's because all the data, at each keystroke, is sent by TCP sockets to server. The ideal is only send a new request when is really necessary (RET pressed).

Would nice creating a client-side based solution since I don't have much resources to handling so heavy sessions on server. A nice interface would be something like http://hack.chat, as ideal written well in Common Lisp (parenscript), but it's not necessary for now.

Add MacOS X support for client: handle cl-readline

GNU Readline is not commonly available on Mac OS. How we can handle tihs?

Make it portable for other Common Lisp implementations

• It should not declare GNU readline as dependency if is running on windows
• It should use bordeux-threads for portability
• It should use portable way to exit

Related to #16

Should be tested and running at least on clisp and ecl. LispWorks is desirable. Should works on Windows as well.

Remove HACK on receive-message function on client.lisp

This HACK doesn't works well on the online version even neither running locally by ssh. Why? We have some alternative?

Improve /log command

• filter @server messages
• add optional parameter N to return N messages on the log stack