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