[noctool-devel] compact configurations for identical machines

[Jim Prewett]

> 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.

I think thats completely fair.  If you must use LOOP, CL:LOOP works.

> > 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!

:)  here here!

> > 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...

ROTFLMAO!  I'm sure glad extensability is a goal ;)

Jim