Let's create Magic

Text:


@@ This is an experiment, blatantly stolen from Elvira's
@@ presentation during Teaching and Learning month on M*U*S*H.
@@ (That's left-handed credit, if you didn't catch it.)
@@ She gave us this fun exercise to play with called
@@ "Yes, let's!"
@@ The idea is that someone says "Let's do [this]." and
@@ everyone else says "Yes, let's!" and then acts out doing
@@ whatever it was that was suggested. Then another person says
@@ "Let's do [this which is related to the previous this]."
@@ and so on and so forth.
@@ So, I suggest unto you all...
@@
@@ Let's...
@@
@wait 0=@set me=~:[create(Magic,10)]
@@
@@ Now, it's your turn to say "Yes, let's!" and add your
@@ magic to the magic I learned from Elvira and adapted to
@@ a softcode wiki with my own magic.
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:...
@@
&INFORMIARUS [get(me/~)]=$informiarus: @@ Show commands and docs for them.; @pemit %#=[name(me)]%r[iter(lattr(me),[setq(v,get(me/%i0))][if(regmatch(%qv,^\\$(.+?)
:(?: *(?:@@ +(.*?)(\\;|$))?),1:n 2:c),%qn - %qc)],%b,%r)]
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:...
@@
&RULUM [get(me/~)]=$rulum:@@ Display a basic ruler.; @pemit %#=[null(iter(lnum(1, 78),setq(0,%q0[switch(itext(0), *5, ansi(b,:), *0, ansi(bh,right(trim(itext(0),r,0),1)),.)])))]%q0
@@
&SPECTRUM [get(me/~)]=$spectrum:@@ Display an ANSI color palette.; @pemit %#=[setq(0,w r y g c b m x)][iter(. [ucstr(%q0)], iter(%q0, setq(1,if(dec(inum(1)),itext(1))[itext(0)])[rjust(ansi(%q1,%q1),2)]) | [iter(%q0, setq(1,if(dec(inum(1)),itext(1))[itext(0)]h)[rjust(ansi(%q1,%q1),3)])],%b,%r)]
@@
&RUNEUM [get(me/~)]=$runeum:@@ Display the ASCII characters.; @pemit %#=[iter(u(RUNEUM`ORDS), [iter(itext(0), [if(not(mod(dec(inum(0)), div(78, 6))),%r)][rjust(itext(0), 3, 0)][ansi(h, :)][chr(itext(0))])],|,%r)]
&RUNEUM`ORDS [get(me/~)]=[lnum(32, 47)]|[lnum(48, 57)]|[lnum(58, 64)]|[lnum(65, 90)]|[lnum(91, 96)]|[lnum(97, 122)]|[lnum(122, 126)][@@(The following switch determines whether or not to include the extended ASCII set. NOTE: This entire command - runeum - may be incompatible with MUX's new unicode.)][switch(chr(160),#-*,,|[lnum(160, 191)]|[lnum(192, 223)]|[lnum(224, 255)])]
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:...
@@
&INPUT_OBJECT [get(me/~)]=localize(switch(1, strmatch(%0,me), %#, strmatch(%0,here), %l, isdbref(%0), %0, isdbref(setr(d,locate(%#,%0,*))), %qd, isdbref(setr(d,pmatch(%0))), %qd, I don't know what '%0' is.))
@@
@@ .:....1....:....2....:....3....:....4....:....5....:....6....:....7....:...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Informiarus

(Someone should fix the output so it's squished better, but you get the idea :)

Excellent!

We may have to call upon you to help keep future commands 'in theme'. *grin*

I'll leave the code modifications to others until such time as it appears we're losing steam.

Meanwhile, ignore me while I do some display format 'example setting' within the script itself (I figure it's best to start early and stay diligent, if I want to help others learn some 'good habits').

p.s. I've noticed different behaviors between platforms when using @set to set attributes. Specifically of relevance to this contribution is the fact that, for example:

@set obj=attr:contents

In Penn "contents" gets parsed before getting stored. Whereas in Rhost it does not unless you put a @wait 0= in front of it. So, I'm thinking this contribution should probably (for the sake of preserving the code on the way through the parser while being quoted in) be in the format

&INFORMIARUS [get(me/~)]=

... and note the [get(me/~)] - this, too, is a choke point in multi-platform awareness, as [v(~)] doesn't behave consistently across platforms. (please: MUX, Tiny's, et al - offer tips for those of us who've grown up penn-centric)

Attribute Naming

I have absolutely no desire to mandate an attribute naming style, but I do want to suggest it as a relevant feature to simplify this command's code (not complaining about the code, mind you - it's designed to support any attribute naming format that comes along, which is good, but..)

If all attributes containing $commands were named a specific way, this code could be condensed to something miniscule (see the section on Attributes in the WARPEDcore Manifest, elsewhere on this site, for more information on my philosophy of this topic).

Raevnos, IIRC, prefers the format "NAME`TYPE" such as

INFORMIARUS`CMND

which allows all of the relevant 'INFORMIARUS' attributes under one tree. This works nicely for many circumstances - especially those in which you want to see each feature (command, function name, whatever) listed in a minimal examination.

My preference is to use the TYPE first, such as

CMND`INFORMIARUS

which, in situations where there are lots of commands/features, condenses the 'minimal examination' list to a shorter set of types. And with the way trees are designed,

ex obj/*`INFORMIARUS**

can still provide the feature-specific examination.

Either way (or, perhaps some way not mentioned here), identifying $command attributes via their names can condense Javelin's 'informiarus' code into something very concise - like the gem on the tip of a magic wand.

Just my $.02.

On naming conventions...

Attribute names are stylistic. Rather than repeating what has already been said a dozen times, I'll point to an early conversation on Electric Soup. Rather long winded but it basically comes down to choosing a style and sticking with it.

On naming kittens..

I've recently been through the process of midwifing and nannying a litter of kittens, and this response

but it basically comes down to choosing a style and sticking with it.

reminded me of this process and how relevant it was (keyword: was) when the kittens were newborns... hey man, grab a nipple and get your belly full!

And this sort of 'pick a style and stick with it' works okay (not great) for any project in its infancy.

But, later, as these newborns begin to grow into grow into playful little furballs, the mother cat rotates them around (for many natural/instinctual reasons: 3 kittens, 6+ nipples, no need to wear them out; this little fella needs to be close to mommy's head today; etc.). And life goes on from there.

My point here is: Yes, you could pick a style haphazardly/randomly-from-a-hat/whatever and try to force it to work throughout (which, as I said in my post, I do NOT want to do).

Or (my preference)...

you could watch the development of this project with attribute naming conventions in mind... and when it becomes clear that one convention or other will be of benefit (I mentioned two specific ones, but I know there are potentially hundreds/thousands/more) -- look at them, fold them this way and that, stretch them, hold them up to mirrors, and put them under microscopes ... and try to find one which is appropriate for this package. Rather than, as you seem to suggest, choosing one now and trying to make all the rest of the code fit it (grabbing a nipple and getting a belly full).

Originally written between 2002-2004 and transferred to online book format in 2006, this is the research I did and which I set aside (but didn't discard) in this new version which starts fresh with Pennmush's attribute trees (thanks, Talek!).

date correction...

I looked up my old files and my original 'first complete alpha draft' is dated 9/7/2001, and which contained all of the concepts of the 'old' version mentioned above. So, apparently I did this earlier than I had recollected in my original mention.

How much for a kitten?

Did I state that style didn't change with time? Of course they do. You adapt them as you find things that work better. "Stick with it" is only for the current project at hand. Tomorrow's project may be something already existing so the style should try to match that project. The next day may be a new effort during which you can apply your lessons learned. There is always room for growth and improvement.

I should have been more clear that the style should be consistent throughout a projects code to help with readability/maintenance down the line.

Kittens

As for the kittens: when they were born, they were all spoken for... but, the people who wanted them seem to be backing out, now that they're weaned and wormed and ready to be vaccinated and stuff. Story of my life: Yes, let's! oh, wait... you thought I was serious?

If those who claimed them at birth don't come and get them this weekend, I'll give them away to anyone willing to come get them and promise to love them and give them good homes. (and momma cat gets spayed)

Male Orange Stripe
Female Light Tan (almost white) with White Feet, Black highlites on tips of ears and tail, and bright blue eyes.
Female Tuxedo (this one may still be spoken for - firstborn)

(Jav, feel free to delete this if you feel it's inappropriate use of this website, with my sincerest apologies.)

Nah, it's a nice community

Nah, it's a nice community thing to take care of the kitties.

Last Call

Two kittens were adopted today. Only one left now.

Firstborn (my first baby kitten ever in my life): Tuxedo Female.

I've announced 'last call' to those I thought might be interested. One of them said 'maybe a week from Thursday'... so I may as well add last call here, too.

Last call for one of my (possibly only litter of) kittens.

Rulum and Spectrum

From my toolkit rewrite, these are a couple of my favorites for making pretty things... or... making things pretty. These two have been tested on Penn, MUX, and Rhost.

(Jav: because the PRE tag doesn't allow convenient wrapping, I've switched to the CODE tag. however, the CODE tag uses a smaller font and the FONT tag isn't supported to allow it to be increased... any chance you can tweak that for us on the back-end? If so, TIA.)

Runeum

To complete the set. Only tested in Rhost.

Couldn't get map(#lambda/foo) to work for the inner iter() on Rhost; so, for now, this includes another example of iter() nesting.

The #lambda foo

This is more a subtle difference on how Penn and MUX2/Rhost/TM3 handle escape characters in the parser.

My suggestion is to use lit() to escape things out when you can, as that's universal and translates appropriately between the various codebases.

Egads! more #lambda foo

MUX2 doesn't support it at all, so I guess I lucked out not using it. (;

But, egads! With lit(), you can actually nest map(#lambda/foo)'s, similar to nesting iter()s.

cool.

Rhost - hot off the press.

Rhost now supports toggle-able support for the extended ascii characters via the chr() function, but only if the accents toggle is set.

@toggle me=accents

Rhost also has an exploratory markup in progress for these. Yummy. Good stuff.

Need a 'magic' command syntax.

This code was donated to this project, as long as the original code (below) retains attribution credit (derivative works are not restricted). Since it is extremely Rhost-specific code and will definitely require a complete rewrite in order to be compatible with pretty much ANY of the other servers, I really am pleased that this donation arrived this way.

It's example code of a freely usable idea. We just have to adapt it to our needs. Thanks ever so much.

Now, we just need to rewrite it so it works on other servers... and give it a cool 'magic' name/syntax. Any volunteers?


DEBUG: $+debug */*:@pemit %#=[setq(8, u(DEBUG_SET[match(first(%0),#*)], %0, %#))][setq(0, [numpos(\),[setq(9, get(r(8)/%1))][r(9)])][numpos(\(,r(9))])][setq(1, [numpos(\],r(9))] [numpos(\[,r(9))])][setq(2, [numpos(\},r(9))][numpos(\{,r(9))])][u(DEBUG_M[eq(controls(%#,r(8)),1)], r(8), %1, r(0), r(1), r(2))]
DEBUG_SET0: [locate(%1,%0,*)]
DEBUG_SET1: [v(0)]
DEBUG_M0: DEBUG: Permission Denied.
DEBUG_M1: DEBUG: Object -> [name(%0)]\(%0[flags(%0)]\)%r[space(7)]Attribute: [ucstr(%1)]%r[space(7)][u(DEBUG_M1[eq(first(r(0)), rest(r(0)))][eq(first(r(1)), rest(r(1)))][eq(first(r(2)), rest(r(2)))], %0, %1, %2, %3, %4)]
DEBUG_M1111: Debug: Evaluation complete. Object passed eval check.
DEBUG_M1011: Debug: Error in \(\)'s \(Right: [first(%2)] / Left: [rest(%2)]\)
DEBUG_M1101: Debug: Error in \[\]'s \(Right: [first(%3)] / Left: [rest(%3)]\)
DEBUG_M1110: Debug: Error in \{\}'s \(Right: [first(%4)] / Left: [rest(%4)]\)
DEBUG_M1100: Debug: Error in \[\]'s \(Right: [first(%3)] / Left: [rest(%3)]\)%r[space(14)]Error in \{\}'s \(Right: [first(%4)] / Left: [rest(%4)]\)
DEBUG_M1010: Debug: Error in \(\)'s \(Right: [first(%2)] / Left: [rest(%2)]\)%r[space(14)]Error in \{\}'s \(Right: [first(%4)] / Left: [rest(%4)]\)
DEBUG_M1001: Debug: Error in \(\)'s \(Right: [first(%2)] / Left: [rest(%2)]\)%r[space(14)]Error in \[\]'s \(Right: [first(%3)] / Left: [rest(%3)]\)
DEBUG_M1000: Debug: Error in \(\)'s \(Right: [first(%2)] / Left: [rest(%2)]\)%r[space(14)]Error in \[\]'s \(Right: [first(%3)] / Left: [rest(%3)]\)%r[space(14)]Error in \{\}'s \(Right: [first(%4)] / Left: [rest(%4)]\)
@@
Credits: Thorin of RhostMUSH (on Rhostshyl), 1994

INPUT_OBJECT

Although it has plenty of room for improvement, I'm sure, another donation from my toolkit. Basically a utility function for $commands which need to find/locate/figure out the object being referenced in user input.

Usage would be something like:

$command *:@pemit %#=[ifelse(isdbref(setr(0, u(INPUT_OBJECT,%0))), [do code here using %q0], %q0)]

Magic Wiki Book - a silly example

Theoretically, it should be possible to make a book of wiki pages (i.e., all 'public domain and/or open source' community edit-able)... if Jav wrote the content for the book such that it linked directly to wiki page content.

Then, possibly as a supplimental option (if he should take an interest at all and want to pursue it further) custom scripts could be built for all sorts of features including, but not limited to, platform-specific choices for more efficient code.. ba-da-bing.

"Oh, Penn..." Says Me
"Chapter 'N'"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.