[noctool-devel] compact configurations for identical machines

[Ingvar]

Jim writes:
> One more thing here... I think we should *guarantee* that the config file 
> is Lisp.  That way I could create my own monitor classes, methods, etc. 
> (even replace internal noctool methods :) inside my config file without 
> ever having to touch noctool sources.  This is pretty much what I do with 
> the LoGS config file - I think it is an especially powerful concept.

At the end of the day, they're loaded by CL:LOAD, it'd be a Right Hassle<tm> 
to change that. It's just that the package they're loaded in is not very well 
connected to the rest of the CL world.
 
> If the noctool developers weren't on top of having sets of machines, I, 
> the user, sure would want to be able to use LOOP or some such thing.  Its 
> also awefully handy if there's some obnoxious-ass user that wants a frob 
> object and the entire rest of the user community thinks its a bad idea - 
> he can just implement it himself, hopefully without having to maintain his 
> own fork of the codebase. :)

One of my general thoughts is that there should be some sort of "internals" 
doicument, with "this is a stable internal interface, please use for 
extensions" and a "this is the rest of the internals" documents. Ideally, I 
want to be able to programmatically generate config files, though. Not 
necessarily in an identical maner, but at least one taht ends up with 
equipment and monitor objects that have the same effect at run-time.

At least at the moment, there is working code that serialises the equipment 
and monitors to disk, so that you can reload them in a new image. They're not 
called, from the rest of the code, but they have been tested. No config 
serialisation as of yet.

That reminds me, there should be a check in the config reader to NOT 
instantiate equipment that shares a class and name with pre-existing 
equipment, but (ideally) intelligently merges the monitors.
 
> I LIKE BEING ABLE TO POINT THE BAZOOKA AT MY FOOT!  I'M WORKING ON A 
> DOUBLE-BARRELLED BAZOOKA SO I CAN POINT IT AT *BOTH* FEET!! ;)
> 
> (i just work dilligently and pray (a lot) i don't pull the trigger at the 
> wrong time)

That's where the "supported" and "unsupported" internal API docs come in. 
Anything that's been classed as "stable" should persist at least through the 
next publicly released version. Anything marked "unstable" is fair game. If 
you extend and break things, you get to keep ALL the parts!
 
> I get offended by tools that *tell me what I want to do*.  Maybe you 
> shouldn't be able to use dc as a word processor... Then again, why not? 
> (if you're sick and twisted enough to put in the work, I could imagine a 
> calculator you could turn into a word processor... look at Mathematica for 
> pete's sake!  I think thats actually precisely what happened with 
> Mathematica - and its a pretty cool tool because that sort of thing is 
> possible.).  No, I'm not a Mathematica salesman... or even a user, really 
> :P :)
> 
> I'll get off my soap box now :)
> 
> Jim
> p.s. I think I want to use noctool as a word processor - Can you help me 
> with that Ingvar? ;P  I've got this PDF file.... ;)

Sure, start with a document class (goes in classes.lisp), then get "bold", 
"paragraph", "normal-weight", "image" and "page" classes, parse the document 
into these and...

//Ingvar