SLirc - Fairly Late Beta Readme:

This stuff is all a little under flux...

Things will be moving about a heck of a lot soon.

Anyways. On with the documentation.

There's three non-SLang API's to know about.

First one is the general SLirc API, which contain intrinsics for trendy
stuff like the UI code, obscure weird shit involving IRC parsing, and sundry
other stuff. This is a sorta joint effort between Stan and me. I did most of
the early stuff which needs changing, Stan did most of the late stuff which
doesn't.

Next up is the SLtcp API, which extends SLang into the glorious realms of
TCP networking, or notworking, as the case may be. Cunning things are
employed here to support Dumb Crap Cludge, (Also known as DCC). This is all
my work, as you can tell, by the simple fact that it has vast numbers of
pathetic hacks in it to make it work.

Last but by no means least is the list thing that I don't understand by
Stan. It does things with n-tuples, which are apparently quite nice with
ketchup.

I really recommend doing a grep MAKE_ on the *.c files of both this and
slang/src/, and you'll find all the intrinsics.

--

As for the SLang itself, it's quite simple, really.

In general, functions are launched by one of four methods:

1) Hard Coding

check_input, return_parse, and command_default are the only hard coded
functions I can find.

They're called from the C, during normal procedures.

I should be able to get rid of command_default being hardcoded, actually.

2) Direct Calls

These are called from inside the SLang, rather tha the C. You could, if you
wanted, change these without touching a compiler, but othervise they're
hardcoded...

3) Multiplexed by name.

This mostly applies to things like command_* - for example, commnd_quit,
which is called if the buffer was executed with "/QUIT" at the beginning. If
these don't exist, then generally nothing gets called, or else some default
does.

(This is now actually done within command_default()... Still the same
effect, though)

4) Registered actions.

This basically means that somewhere, there's some call (either an intrinsic
or a direct slang call) that registers this function as the thing to do when
a certain event happens. TCP stuff does this, as does keystroke stuff. I
really like this way of doing things, because it makes the code much more
event driven, which is nice.

(This is now done for various other actions... Including commands and server
responses... See README.dropin for how)

--

If you want to add a command, simply define a command_blah function in the
SLang (Which will make /BLAH be your command). It'll take one text
parameter. Try and stick it into a new file, and have the file evalfiled in
from config.sl, if you can. Makes it nicer. When it works, send me a copy.

If you want to hook it to a keystroke, then register it using the
irc_set_keysym() or irc_set_key() functions (Actually,  just use
irc_set_keysym, the other's bollocks.) and let it be called.

If you want to hook it into CTCP, then it's a similar idea to a command, but
in cmd_ctcp.sl (Or better, elsewhere) and autoloaded from ctcp.sl (Yeah.
Well, I hate loading in everything)

Similarly, DCC is a named multiplex, as are /DCC XXXX subcommands, and
friends.

TCP sockets are a registration, so register your function to read or write
as and when required.

--

Some Credits:
Stan Brooks - For loads of code.
Hatstand - Generic testing and whingeing.
impy - Equal testing and whining. Also some attempts at a logo. Heh. GFX? Nah.
Clod - Lots, and I mean lots, of encouragement and help when I started.
John E. Davis - For writing a library that did all the hard work for us.
Everyone on IRCNet's #linux, especially linstat. :-)

--

dwd : Dave Cridland : dwd@non.entity.org

Send SLirc specific email to: slirc@non.entity.org, please.