• "Slippery slope" -- you could easily imagine expanding "blocks" into "while-loops", etc. I don't want to implement an entire language (one piece at a time) for this "%source file programming" layer. I'm not looking to implement a whole cpp layer for MOO commands, for instance!

As part of this, I was thinking that other multi-line @-commands should have similar markers to indicate the expected-end of their input. Right now, for instance, @eval is similar to commands like /memo set blah in that it keeps reading input until it reads a separate line with just "." or "abort" on it. In the context of "%source file programming", I think it would be helpful if something like @end:eval was also recognized as an end-of-input marker. That way, if something goes wrong with the initial @eval, the @end:eval would be executed as a command. And the command-version of @end:eval would just trigger an @exitblock outermost-block (if it's in the middle of some block), to skip the remaining commands in that block. A period would still be recognized as end-of-input, since that is more convenient when typing in @eval commands.

This triggers the question of what exactly that new terminator line should be. At first I was going to have it be @endeval, but then my eyes would cross or something and I'd read that as "en deval" instead of "end eval". So now I'm thinking it should be @end_eval, @end-eval, or @end:eval. At the moment, I slightly prefer the last one.

This, in turn, suggests the line to terminate a block should be @end:block, which would be alright with me. But then what should the line be to start a block? I realized that when I've jotted down my thoughts on this, sometimes I used @block and sometimes I used @beginblock. @block would be more consistent with @eval. For that matter, I suppose it could be @{ to start a block, and @} to terminate it. Or maybe we should have all the input-termination lines start with "@end ", which would make it easier for input processing to notice begin/end mismatches, such as:

    @block somename
    @eval blah= &
    @end @block

So... I'm still mulling over several different possibilities for how these begin/end sequences should be handled (keeping in mind that I might want to also support blocks of /-commands or $-commands, thus providing "%source file programming" ideas for more lily users).

(have I mentioned that I can sometimes take longer trying to decide the perfect names for two new variables in a method, than it will take me to rewrite the entire logic of that method?)

-- GaranceDrosehn - 23 Dec 2005

What @dump #objnum will do is print out a series of commands which could completely re-generate the given object number, from scratch, on some other core. Coke recently handed me a lilycoreDB which has an implementation of the game of hearts in it. At least 95% of that work is done in a single new object that he created, so "all I have to do" is copy that object from his lilycore to mine, and vast majority of the work is done (well, except for the testing, of course!). The thing is, I have no automatic way to copy an entire object from one core to another, actively-running core. What I've done in the past is I look at the output files produced by my splitcore script, and then type in commands to a separate file. I type in all the @verb and @property commands, and then type in %source commands to @program the code for each of the defined verbs. I then %source the file that I've typed in (by hand) on my own testcore, run splitcore again on both lilycores, and compare the two sets of splitcore results to see what I missed. If I did miss something, I reset my test lilycore, modify my hand-typed source file, and repeat. Eventually I get it right. Very Tedious.

Once I have @dump working right, I will be able to replace that entire multi-day, trial-and-error process with:

     %log on
     @dump $hearts_game
     %log off

     %capture @dump $hearts_game

(except that right now there's some bugs with %capture in clily when dealing with very long output lines...).

Anyway, that's all well and good. I will be able to quickly generate a %source-able file which can re-generate the original object -- IF the destination core is in the state that "I think" it is in. What if it isn't? I'll have %source-ed this file with over a thousand lines of commands, blindly trying to add and modify things. If something goes wrong in there, one bad command can cause a huge cascade of errors. The end-result might be a real mess. This would not be good.

So. I was thinking, how about defining a "block" of commands, and have the lily server recognize that block. And provide some way for a programmer to say "exit out of this block", which would really mean "keep reading and ignoring input lines until you see the matching end-of-block marker". The basic idea would be something like:

    @beginblock aaa
       @exitblock aaa @unless ($code_utils:has_property(#0, "game"))
       @exitblock aaa @unless (parent(#38) == $nothing)

       @prop $hearts_game #38 "r" $admin
       @eval chparent($hearts_game,$game)
       @verb ...
       @property ...
    @endblock aaa

There are two minor aspects about this which make me a little uneasy:

• "Slippery slope" -- you could easily imagine expanding "blocks" into "while-loops", etc. I don't want to implement an entire language (one piece at a time) for this " %source file programming " layer. I'm not looking to implement a whole cpp layer for MOO commands!

• Why limit this to @-commands? -- Maybe these should be /block and /endblock commands? While this ability would be extremely useful for my cross-core programming issues, there's probably some situations where it would be useful for lily users who are not programmers on the server itself. Maybe I'll do a /-based set of commands in addition to the @-based set. The thing about the /-based set is that it wouldn't be able to execute arbitrary MOO code for the conditions specified on @exitblock, so I'd have to invent something for that. Or else, only exit a /block when some /-command fails.

Still, I am mighty tempted to at least try the @block, @endblock ideas. And the more I think about it, the more I want to do it -- after I get @dump finally working the way it should work, of course.

-- GaranceDrosehn - 22 Dec 2005