Re: Re: IRC

Some updates on that TODO, I was incorrect on two counts.

cl-irc *does* have a BSD/MIT style license. Hurray. I don’t know why I was under the impression it was otherwise.
snirc now does the [number] -> [string] mappings I wanted, such that the server sending, say, numeric reply 001 will result in snirc:conn-command being “RPL_WELCOME”.

snirc:cconnect does make more sense seperate from the read loop. It is sensible to expect the user to wish to be able to do something like (snirc:join conn “#Some_Channel”) between connecting and entering the read loop. As such, snirc:cconnect has been renamed to snirc:open-connection! and snirc:disconnect has been renamed to snirc:close-connection!.

Also, I won’t be modifying the default handlers to serve as examples. I’m going to be writing general documentation as well, which would be a better place for such examples. Ideally, the the general and API documentation should be well enough that the user has no reason to ever look at snirc’s code for reasons other than curiosity. I want it to work perfectly fine as a ‘black box’, as really a library should.

Also, I will likely be submitting some patches to the tcpip snowball, for things such as Chez/SCM support, flushing buffers, just returning #f instead of calling error or exceptions or whatever when a socket can’t be created (this one will be hard, but I’ve found the code to do for mzscheme at least), and such like.

Re: IRC

Last month I mentioned I was working on an IRC snowball and expected it to be complete in about a week. Well, that didn’t happen. Between being busy with other projects (such as light construction, ugh) and shear procrastination, it’s taking longer. Here’s the current/future TODOs:

———-
NOW:
———-

Rest of the RFC2812 command wrapper procedures.

Figure out how to get SchemeDoc to recognize define* as it does define.

Clean up the documentation.

Have someone else proofread the documentation.

Add handlers for the required CTCP replies.

Add a handler for case where desired NICK is unavailable at connect time.

Possibly replace all the record shit with a simple object system.

Make the default handlers use the same API the users are expected to use.

3digit codes -> ERR_* RPL_* at parse time, such that snirc:msg-command could be ERR_NOSUCHNICK or whatever. Get rid of snirc:msg-code.
cl-irc has a lovely alist of this mapping in its code. Should find out if its author minds it being borrowed, considering this code is BSD licensed while cl-irc is not.

Figure out why the fuck I couldn’t match against snirc:msg-code, even though it’s likely to disappear anyway. It’s probably due to my noobishness, but possibly a logical error somewhere. Need to know.

Merge snirc:cconnect into snirc:read-message-loop. Seriously, there’s not much reason for it to be seperate and there’s not really a logical name for it that I can think of considering snirc:connect is taken for a wrapper to RFC CONNECT. snirc:read-message-loop already checks if it’s connected at startup anyway.

Handle exiting/disconnecting/quitting cleaner. Make it never go to debugger/error/whatever. It pretty much just needs to be more careful about not trying to read from a closed socket.

Possibly split the RFC command wrapper stuff from the internal connection/handler stuff into separate files. Maybe the existing/future CTCP/DCC stuff should be in their own files as well.

———————–
Handle PINGs required for connection registrations. A solution to this is for the user to wait to send non registration related commands until we’re sure it’s complete, from within read-message-loop (which will handle the PING), such as this handler which deletes itself when it’s no longer needed:

(snirc:add-handler! conn (lambda (msg)
                           ;; Numeric 001 is the welcome message
                           ;; after a successful registration.
                           (if (string=? "001" (snirc:msg-command msg))
                               (begin (snirc:join conn "#Some_Channel")
                                      (snirc:remove-handler! (snirc:msg-conn msg)
                                                             'temp)))
                           #f)
                         tag: 'temp)

This “solution”, however, is crap. It’s somewhat difficult to describe clearly why it works, and it is reasonable for the user to expect snirc:register-user to finish its job and be able to call snirc:join, snirc:mode, etc… before calling snirc:read-message-loop anyway. Why some servers want to send a PING and demand a PONG before completing the registration, I havn’t a clue. Also the tested server sends the PING after it receives NICK, but it is happy to wait for the PONG until after it receives USER. If it demanded the PONG before receiving the USER command, this would have to be more complicated.

-rant-
If you ask me, the “proper” solution would be to remove this crap from the servers stupid enough to do it in the first place. The only even remotely logical use of it I can think of is for the server to adjust how much idle time should go by between pings to save an irrelevantly small amount of bandwidth, if it were also too stupid to check the reply times of later PINGs, and there’s no reason it couldn’t send an initial ping *after* registration anyway, even if for some reason the latency between the client and server were somehow magically guaranteed not to change during the lifetime of the connection. Not to mention that given such, if a client wished to deal with fewer PINGs it would artificially wait some time before sending a PONG anyway. The whole thing is entirely senseless, I can’t for the life of me figure out any other reason for it what so ever, and even if there *is* a good reason for it I don’t care as it’s arguable (and I would argue it) that it violates the RFC anyway.
-rant-
———————–

———-
LATER:
———-

SSL/TLS support. Not likely to happen until someone else provides a snowball that deals with SSL/TLS. I could break out my copy of Applied Cryptography and take a look at existing encryption-related snowballs, but really there’s many other things I’d rather work on.

Support for the rest of CTCP such as colors(ew) and what not? At least an option for the parsing mechanisms to strip the colors and crap out of messages to ease the writing of bots. As far as actually doing anything with them, that’s probably best handled via code in a client being written using this snowball.

DCC support (technically a part of CTCP, crap bolted onto crap bolted onto IRC…). Will require threading, or something in the vein of select/poll.

———-
WISH:
———-

Docs for the RFC command wrappers.
Even though it’s basically redundant and involves rewriting bits of the RFC, and the wrappers are so thin they’re pretty much translucent.
If the RFC command takes an optional ‘target’ parameter, then so does the snirc procedure, &c.
I would just copy the relevant bits of the RFC and adjust the examples it gives, but although it seems fairly liberal I’m unsure as to whether its copyright would allow for such use. As far as I can tell: no. I’m just an unpaid code monkey, I don’t speak legalese.

-rant-
As long as I’m wishing, I wish that all existent RFCs were relicensed under the Creative Commons or public domain or suchlike. Besides making my docs easier, it would perhaps prompt someone to clean up much of the the RFC protocol, which while writing this snowball I’ve become entirely convinced it badly needs. MODE in 2 different sections with 2 different uses comes immediately to mind, as well as the grammar of different types of commands being different enough that you wind up with silly shit like having to check the sender to see who’s nick changed and suchlike without making the parsing code vastly more complex, or the fact that notifications such as those share the names of the commands used to cause them in the first place, such that MODE actually means *three* things, depending on whether you’re sending or receiving it… It would also be lovely if CTCP wern’t crudely bolted on top of IRC, with DCC bolted onto CTCP in turn. The RFC could very well provide CTCP/DCC commands directly. And if you had a real reason to add stupid shit like registration-time PINGs, a new RFC would be the place to do it.
-rant-

More state tracking ala cl-irc (who’s in what channels, user/chan modes, etc…).

Possibly update records with relevant server replies re: whois and etc…

Possibly in addition to, or instead of the above, provide a FIFO queue (string port? list?) that contains numeric server replies (say, the last 20 or so).

Really, both of the above can be handled by the user. It would just be nice, and not that hard to do.

Replace all the record shit with a simple object system if not done already?

Multiple server connections. Will require threading, or something in the vein of select/poll.
Perhaps it is cleaner to have the user use their implementation’s threading system, and call an snirc:read-message-loop for each connection.
It’d just be really nice if they could simply pass snirc:read-message-loop a list of connections and let it deal with the threading instead.
Plus the message records know which connection records they belong to, and we need to be able to handle multiple sockets for DCC support anyway.

Add a socket control interface. Same requirements as DCC and multiple servers.
Think out of band communication between applications using this snowball, or clients/bots that can be written in any language the user damn well pleases using this snowball as a backend through a local (or remote) socket, maybe even a web app. I really want this.
Bonus points if it can use SSL and/or TLS, thus making remote possibilities saner.

There are snowballs to talk to other processes. Make it fall back to netcat/socat/telnet if snow doesn’t know how to open a socket in the implementation. Hopefully one or the other will always work. (Also, I’m pretty damn sure Chez and SCM can open sockets, the tcpip snowball should be updated.)

———-
Misc ideas:
———-

SILC support? Have to see just how different that protocol so far as commands and whatnot from the client’s perspective is. I’d hope it’s much cleaner, but if not it may be worth adding to this snowball. Also, would require SSL/TLS support.

Some sort of juju to torify ourselves?
Perhaps by talking directly to Tor’s socks4 or socks5 proxy?
Perhaps by skipping the tcpip snowball altogether and using netcat &c through torify to open the connection?
Probably will never happen, it would be pure feature bloat.

What I’ve been up to this month.

So I’ve noticed that I have 23 posts for January (I need a life), and only 4 for February. What have I been up to?

Mostly delving more into Scheme(see footnote), nearly to the exclusion of Common Lisp, other than the occasional tweaking of my StumpWM config.

A few years ago when I was still doing security (of the rent-a-cop sort) I was reading some Scheme book or another (I don’t remember which) in PDF format on my old Palm T3 running LispME. I miss my T3, I thought the format was just about perfect, and it was well built. I wouldn’t have given it away if I knew it would finally be figured out how to get Linux on it. Oh well, I have a laptop now. Anyway, I don’t really know why I never got more into it… I loved it, but I probably got distracted by other things after I moved (like trying to find a fucking job -_-). I don’t really know how it caught my interest again either (along with Common Lisp this time), but I figure it was inevitable with nothing else really going on.

So now I spend large portions of my time coding Scheme, and I’ll talk about a couple of the things I’ve been working on, the things I plan to work on, and some things I might eventually work on.

I wrote an IRC bot in Common Lisp as I always do when learning a new language. It was mostly a matter of the quote given in my earlier post on Scheme vs. Common Lisp, “Most newcomers eventually (and independently) decide the same thing: Scheme is a better language, but Common Lisp is the right choice for production work. CL has more libraries, and the implementations are somewhat more compatible than Scheme implementations, particularly with respect to macros.“.

But I decided, fuck that, it is the better language, and reimplemented it in Scheme. But I wasn’t happy, there wasn’t enough separation of layers, and the code to make the network interface bits portable across different Scheme implementations was a gigantic cond expression requiring the user (I always (try to) code with the assumption that other people will have to use/read it) to set a variable to the name of their implementation. All that complexity just to open a socket is bullshit, and doesn’t belong in the bot’s code.

I knew I must have been reinventing wheels, so I started looking around, and I found what I needed, Snow. It’s not perfect, but it’s still a fairly new project and pretty much does the job. And more importantly, it already has things like a portable TCP/IP package, among many others I’ve also found useful, and works on pretty much all of the major implementations. Documentation for specific packages can be sparse at times, but they *do* always at least tell you the procedures they make available and what args they expect. And one of the nice things about Lisp in general is that it’s not generally a bitch to figure out someone else’s code, should you need to.

With that, I set about writing an IRC library for Scheme using the Snow framework, to eventually use to rewrite my bot. And I dare say it’s nearing completion. The only thing currently lacking is DCC support, which will come at some later time. The IRC client protocol itself and CTCP support are pretty much there however. It was originally inspired by cl-irc but so much of it wound up being based around the ideas of the IRC “egg” for Chicken that I consider it a derivitive thereof (and is happily BSD licensed anyway). While it does have its issues (such as not checking whether a nick change actually worked…), its general design, which I thought was quite simply fucking brilliant, is obviously far superior to that of cl-irc’s (especially in how hooks/handlers and CTCP are handled). It seems I learned about as much Scheme from reading that code as I have reading any books. I only hope that my IRC code may be useful to Chicken’s, as mine likely wouldn’t exist as it does without it, so I’m going to wind up trying to write a couple patches for the parts of the egg I found lacking. Open source is grand, isn’t it?

Once that’s all done, I’ll be using it to (re-re-)implement my IRC bot in Scheme. And I think, for once, I’ll finally have the bot I always really wanted instead of a hack job that has to get around the limitations of the language it’s written in.

One of the things the bot does is retrieve information from Last.FM, so I’ll need to write an implementation of the API for Scheme too (obviously, based on the excellently written cl-audioscrobbler).

And then, I’ll get back to work on my MUD based on the ideas in Mooix NG. I’ve got a basic framework done making heavy use of Common Lisp’s CLOS, as an object system seemed the obvious tool for the job, and CLOS is simply sexy to work with. But working with Common Lisp just didn’t feel quite right, and I wound up looking more into Scheme(see other footnote).

I’m also vaguely entertaining the thought of writing Snow packages for the 9P and Freenet protocols. But what I’d really like to see is a widely supported SRFI for Foreign Function Interfaces(FFI). That would make the others (and other cool shit like POSIX) nearly trivial to do portably across implementations. Although threading at least has a couple of its own SRFI’s anyway. But in the mean time, a lot of Scheme implementations do support FFI to one extent of another… maybe someday when I’ve got more experience I’ll see about writing a Snow package to smooth over their differences, as CFFI does for Common Lisp.

So yeah. Do I need to get laid, or what?

(footnote) As it breaks compatibility both literally and ideologically to previous Scheme standards, I do not refer to R6RS as Scheme. When I say Scheme, assume R5RS.

(other footnote) Separate namespaces making me care whether it’s a variable or if I need to use #’, having to remember to use gensym in macros, should it be defvar or defparameter, … I don’t want to give a shit about the language, I just want to write what I’m trying to write, and when trying to write a MUD it was getting pretty old. Sure, I could abstract all that away. Lisp is GREAT for that sort of thing, and I started to do just that. But then I thought, why should I make Common Lisp be Scheme-like, when there’s already Scheme? If the language I really want is already there… use it.

With friends like these…

[16:52:51] bobf | simias: I’ve got leet code that lets someone say, e.g. bobf: exec wget http://www.goatse.cx/hello.jpg
[16:53:03] bobf | And it’ll execute that code on my system!
[16:53:03] simias | I don’t like where this is going…
[16:53:14] bobf | It saves me time when people want to execute code on my computer.
[16:53:20] Prael | bobf: exec shutdown -h now
[16:53:21] simias | bobf: exec kill -9 -1
[16:53:21] Prael | XD
[16:53:27] <– bobf (n=bobf@<somewhere>) has quit (“Shutting down…”)

I’m the new bitch.

* Prael got bored, http://stumpwm.antidesktop.net/cgi-bin/wiki?action=history;id=FAQ
<male> Congratulations, you're the new Wiki bitch.
<male> Erm. I mean, Wiki editor.
<Prael> lol