From tinymuck-sloggers-owner Wed Oct 3 16:28:57 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03193; Wed, 3 Oct 90 15:59:45 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA03189; Wed, 3 Oct 90 15:59:43 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA03818; Wed, 3 Oct 90 16:04:39 PDT Date: Wed, 3 Oct 90 16:04:39 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010032304.AA03818@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: interp.c switch fix Status: O Here's a fix for interp.c's large switch. I have had many complaints about the problem from people on different systems. There's other ways to fix this but this shouldn't interfere with local mods at all... :-) This is up for ftp as well, on belch.berkeley.edu -- *** interp.c Fri Sep 28 12:28:56 1990 --- interp.c.fix Wed Oct 3 15:55:55 1990 *************** *** 1056,1062 **** CLEAR(oper1); push(arg, top, PROG_OBJECT, MIPSCAST &ref); break; ! case IN_DESC: case IN_NAME: case IN_SUCC: --- 1056,1064 ---- CLEAR(oper1); push(arg, top, PROG_OBJECT, MIPSCAST &ref); break; ! default: ! switch (pc -> data.number) ! { case IN_DESC: case IN_NAME: case IN_SUCC: *************** *** 1603,1608 **** --- 1605,1614 ---- /*NOTREACHED*/ break; } + break; + } } + + -- ChupChup From tinymuck-sloggers-owner Thu Oct 4 14:59:07 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08081; Thu, 4 Oct 90 14:33:20 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA08077; Thu, 4 Oct 90 14:33:18 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA04522; Thu, 4 Oct 90 14:33:14 PDT Date: Thu, 4 Oct 90 14:33:14 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010042133.AA04522@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: concentrator Status: O Has anyone successfully run TinyMUCK 2.2 with the concentrator code option? I hacked the 2.0 concentrator to work with TinyMUCK and tested it briefly but I really have no idea how it works long-term, and how good the logging is. I'd like to hear from anyone who's tried it or would like to give it a shot, for a while at least. Thanks, -- ChupChup From tinymuck-sloggers-owner Thu Oct 4 22:59:43 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13630; Thu, 4 Oct 90 22:34:16 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA13626; Thu, 4 Oct 90 22:34:10 PDT Received: by zia.aoc.nrao.edu (4.1/SMI-DDN) id AA03462; Thu, 4 Oct 90 23:34:07 MDT Date: Thu, 4 Oct 90 23:34:07 MDT From: dbriggs@zia.AOC.NRAO.EDU (Dan Briggs) Message-Id: <9010050534.AA03462@zia.aoc.nrao.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: A better sort algorithm in MUF Status: O I was working on a MUF project last night, and needed a reasonable sorting routine. It wasn't much of a big deal to implement a Shell sort, and it turned out to work quite well. Well enough in fact that I've decided to post it, rather than just let it molder in ChupChup's macro library. This Shell sort uses the stack manipulation operators, so it needs 2.2 to run. There are a couple of features worth noting. 1) All storage is done on the stack. Neither local variables nor property strings are used. This means that it is comparitively fast (by MUF standards), and there is no possibility of storage conflicts with the calling routine. (The corollary to this property is that the code is not terribly clear stuff. You can't have both.) 2) The comparison operator is factored out fairly cleanly in the code. You can select a comparison appropriate for strings or integers by passing the routine an index number. If you want to roll your own ordering, you can just pass it a pointer to the comparison. For those who don't know it, the Shell sort is also called a diminishing increment sort. It's worst case running time is O(n^1.5). For randomly sorted data, it usually does better than that. (O(n^1.27) was quoted in one of my texts.) A crude measurement of my implementation showed that it was scaling about like n^1.37. The comparison is a bubble sort, written by Black Dougal. (BTW, I think that his can run under 2.1.1???). Bubble sorts are O(n^2), with a not terribly good proportionality constant to boot. Here are some running times from ChupMUCK. Both algorithms are dominated by the MUF interpretation, so it makes almost no difference whether it is sorting strings or integers. N Bubble Sort Shell Sort 20 1 0 40 7 1 60 13 1 These are running times in seconds 80 28 2 as reported by the testing program 100 48 2 below. 120 76 3 140 115 3 160 163 5 200 - 6 300 - 9 400 - 15 500 - 18 Given the realities of what can and cannot be tackled in MUF, I don't see that there's a whole lot of incentive to tackle an asymptotically more efficient sort. I suspect that the complities of, say, a heap or a quick sort would likely dominate the execution time for all but the largest values of n. Enough blathering. Here is the code. All the usual caveats.... It seems to work on everything that I've tried. If you find a bug or a pathological case, let me know, please. Thanks! --Gazer [dbriggs@nrao.edu] ---------------- Cut Here ------------------- ( Shell Sort This particular implementation is based on the version in AHU's Data Structures and Algorithms, p.290 The algorithm is O[n^1.5] worst case and about O[n^1.27] for pure random data. This implementation works purely on the data stack, so it is reasonably fast, and can be called by any other program. My test data indicates that this implementation scales about like O[n^1.37] or so. Takes [ x1 x2 x3 ... xn n index -- x1' x2' x3' ... xn' n ] The index selects both the type of data to be sorted, as well as how it is to be sorted. Ascending order means that the smallest numbered items are neasest the top of the stack. [And hence will be the first to be printed out later.] Valid choices are: index Name Description 0 SortStrACI String Data, Ascending, Case Insensitive 1 SortStrACS String Data, Ascending, Case Sensitive 2 SortIntA Integer Data, Ascending 3 SortStrDCI String Data, Descending, Case Sensitive 4 SortStrDCS String Data, Descending, Case Insensitive 5 SortIntD Integer Data, Descending 6 SortGen Pass your own ordering function under the index Requires tinyMUCK 2.2 or later Baseline version 1.0 04-Oct-90 Gazer [dbriggs@nrao.edu] ) ( These functions return a true flag when the data items ) ( should be swapped. ) : CmpStrCaseInsensAsc stringcmp 0 > ; : CmpStrCaseSensAsc strcmp 0 > ; : CmpIntegerAsc > ; : CmpStrCaseInsensDesc stringcmp 0 < ; : CmpStrCaseSensDesc strcmp 0 < ; : CmpIntegerDesc < ; : SortJLoop ( n cmp inc i j -- n cmp inc i ) dup 0 <= if pop exit then ( while j > 0 ) dup 5 + pick ( get A[j] ) over 5 pick + 6 + pick ( get A[j+inc] ) 6 pick execute if ( do comparison ) dup 5 + pick ( swap: get A[j] ) over 5 pick + 6 + pick ( get A[j+inc] ) 3 pick 6 + put ( put into A[j] ) over 5 pick + 5 + put ( put into A[j+inc] ) 3 pick - ( j := j - inc ) else pop exit then ( break out if we don't swap ) SortJLoop ; : SortILoop ( n cmp inc i -- n cmp inc) dup 5 pick > if pop exit then ( for i := inc + 1 to n ) over over swap - SortJLoop ( j := i - inc ) 1 + SortILoop ; ( while j > 0 ) : SortIncLoop ( n cmp inc --- n ) dup 0 <= if pop pop exit then ( while inc > 0) dup 1 + SortILoop ( for i := inc + 1 to n ) 2 / SortIncLoop ; ( The index determines the type of data sorted and the operation ) ( performed. At the moment, there are seven recognized indicies. ) : Sort ( n index ) dup 0 = if pop 'CmpStrCaseInsensAsc else dup 1 = if pop 'CmpStrCaseSensAsc else dup 2 = if pop 'CmpIntegerAsc else dup 3 = if pop 'CmpStrCaseInsensDesc else dup 4 = if pop 'CmpStrCaseSensDesc else dup 5 = if pop 'CmpIntegerDesc else dup 6 = if pop ( pointer is passed from caller ) else "Sort: Illegal Comparison Index [" swap intostr strcat "]" strcat me @ swap notify exit then then then then then then then over 2 / SortIncLoop ; ----------------- Cut Here --------------------- /* Test the sorting routines. Hack to taste */ /* Uses cpp prior to MUFing */ /* Watch out for local variable conflicts with .sort */ : temp 30 variable ; : seconds ( -- i ) time 24 * + 60 * + ; : dl-loop ( list n+1 -- list list ) dup 0 <= if pop exit then temp @ pick swap 1 - dl-loop ; : dup-list ( list -- list list ) dup 1 + dup 1 + temp ! dl-loop ; : pl-loop ( list index -- list ) over over swap > if pop exit then dup 2 + pick intostr .tell-me 1 + pl-loop ; : print-list ( list -- list ) 1 pl-loop ; : mt-loop ( n -- random*n ) dup 0 <= if pop exit then random 10000 % swap 1 - mt-loop ; : make-test ( n -- list ) dup temp ! mt-loop temp @ ; : tst-bubble ( -- ) "bubble" .tell-me read pop seconds temp ! .sort seconds temp @ - intostr .tell-me .popn ; : test-cmp ( i1 i2 -- f ) < ; : tst-shell ( -- ) "shell" .tell-me read pop print-list seconds temp ! 'test-cmp .sortGen seconds temp @ - intostr .tell-me print-list .popn ; : tst-em ( s -- ) atoi dup if make-test // dup-list // tst-bubble tst-shell else "barf" .tell-me pop then ; ------------- Cut Here ---------------- /* Install Shell Sort routine */ /* Appropriate for ChupMUCK */ #define P_SHELLSORT_ID #1514 @edit p_shellsort 1 1000 d 1 i #include "shell.m" . c sortStrACI kill sortStrACS kill sortIntA kill sortStrDCI kill sortStrDCS kill sortIntD kill sortGen kill def sortStrACI 0 P_SHELLSORT_ID call def sortStrACS 1 P_SHELLSORT_ID call def sortIntA 2 P_SHELLSORT_ID call def sortStrDCI 3 P_SHELLSORT_ID call def sortStrDCS 4 P_SHELLSORT_ID call def sortIntD 5 P_SHELLSORT_ID call def sortGen 6 P_SHELLSORT_ID call q From tinymuck-sloggers-owner Sat Oct 6 17:30:03 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22755; Sat, 6 Oct 90 17:20:49 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA22751; Sat, 6 Oct 90 17:20:46 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA03626; Sat, 6 Oct 90 17:20:45 PDT Date: Sat, 6 Oct 90 17:20:45 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010070020.AA03626@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: 2.2 patches are out Status: O There is a new distribution file of TinyMUCK 2.2 on belch.berkeley.edu as well as patches to the old file to bring it up to specs. These patches fix a memory leak in IF, a few bogus free()s in the editor (not my fault!) and a few other cosmetic things, most notably, paybacks for recycling and unlinking. Also included are contents-fix.m and environment-fix.c, to simulate 2.1.1 CONTENTS and to zap all rooms into the global environment for 2.2, respectively. All in all I'd say I'm pretty happy how few bugs have turned up in 2.2. Keep those reports coming... -- ChupChup From tinymuck-sloggers-owner Mon Oct 8 20:00:26 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04107; Mon, 8 Oct 90 19:31:06 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04101; Mon, 8 Oct 90 19:30:59 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA05428; Mon, 8 Oct 90 19:30:49 -0700 Date: Mon, 8 Oct 90 19:30:49 -0700 From: jearls@polyslo.CalPoly.EDU (MicroBrain) Message-Id: <9010090230.AA05428@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Proposal for Lock Evaluation in MUF Status: O Hey Folx, I've been working out a way to do a boolean lock evaluation in MUF... I got a version working (and it only requires one little new primitive :-) Basically, it requires a new 'getlock' command that will take a dbref and return a pre-order traversal of the expression tree for that lock. (I hope I remember the code correctly... Locks are stored as boolean expr trees, right?), along with the count of the nodes. Then you can run the code below to do the evaluation... ------------------------------- CUT HERE ------------------------------- ( Boolean Lock Evaluation ) ( Requires a 'GETLOCK' primitive that will return a pre-order traversal) ( of the boolean expression tree, with positive dbrefs for objects [or ) ( #0] and negative dbrefs for AND, OR, NOT {represented by DB_AND, etc}) ( ) ( Stack: { d -- f } where 'd' is the dbref of the locked object, and ) ( 'f' is the boolean return. ) ( ) ( Limitations: Currently does no error checking on the data obtained ) ( from 'GETLOCK' ) ( ) ( GETLOCK is as follows: { d -- d[n] d[n-1] ... d[2] d[1] n } ) ( where d[1]..d[n] are the dbrefs from the tree and 'n' is the count. ) : eval-expr-loop over over + 4 + pick dup int -1 > if ( check for a single object ) dup me @ location dbcmp swap location me @ dbcmp of rot 1 + rot else ( evaluate AND, OR, NOT ) dup DB_AND dbcmp if pop ( AND ) 4 rotate 4 rotate and 4 rotate 1 - 4 rotate else DB_OR dbcmp if 4 rotate 4 rotate or 4 rotate 1 - 4 rotate else rot not rot rot then then then 1 + over 3 + pick over = not if eval-expr-loop else pop then ; : eval-expr-cleanup ( n a -- a : removes 'n' items from the stack ) rot pop swap 1 - dup if swap eval-expr-cleanup else pop then ; : eval-lock ( d -- f ) getlock dup if 0 0 eval-loop pop eval-cleanup else pop 1 then ; ------------------------------- CUT HERE ------------------------------- Well, that's it. Sorry 'bout the derth of comments, but I'm not sure I could explain it 'tall... So, Chup, d'y'all think you could put in GETLOCK? d:-) -- R'n'D / JaXoN -- Johnson Earls _______________________________________________________________________________ | | Q: "Growl for me, microbrain; jearls@polyslo.CalPoly.EDU | show me that you still care." From tinymuck-sloggers-owner Mon Oct 8 20:30:26 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04298; Mon, 8 Oct 90 20:24:50 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04293; Mon, 8 Oct 90 20:24:48 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA06247; Mon, 8 Oct 90 20:24:41 PDT Date: Mon, 8 Oct 90 20:24:41 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010090324.AA06247@grunt.berkeley.edu> To: jearls@polyslo.calpoly.edu Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: MicroBrain's message of Mon, 8 Oct 90 19:30:49 -0700 <9010090230.AA05428@polyslo.CalPoly.EDU> Subject: Proposal for Lock Evaluation in MUF Status: O Hmmm... A few thoughts of mine on boolean expressions :- Boolean expressions are one of the greatest things to come to tinyMUD. Their biggest drawback in that context: they only come one per object. I'm aiming to have boolean expressions in p-lists for 2.3 which would obviate a need to have the .key part of a database object hardcoded. (Among many other things that can be stored in p-lists!) The proposal looks interesting and it's on my wavelength, but I think this can be done a lot easier. To wit: a function address is a fully operational type in MUF, but right now it's only available to the compiler; 'foo leaves you foo's address, a constant for the duration the program's code is in core memory. Interpreting it will always push the same number on the stack. Oh, before I start in on it, one thing I'm pretty sure to put in - a PROG_BOOLEXP type for MUF. Maybe this isn't necessary? Basically you would use "getlock" to return a boolexp type on the stack, then [ see below ] use my idea on it. Here's the boolexp/address idea: have a "compile_boolexp" primitive which takes a boolexp/property (see above) and compiles it *into a MUF function*, returning its newly allocated address. Run this with a dbref on the stack, and your result is true or false. Example: ~~~~ you wake up in the future - bear with me :) ~~~~~ : check-my-lock ( -- i ) me @ "foo-key" getproplock (check property; leave boolexp type on the stack) dup trigger @ me @ name rot 0 addprop (adds the user's key to the list) compile_boolexp (takes user's key, returns address of new function) trigger @ owner swap execute (put programmer's dbref on stack, execute lock) ; (returns result of the compiled boolexp, telling me if I, the programmer, fits the user's foo-key lock) Anyway, I may just be babbling, is anyone with me still? Perhaps I'm going overboard on the boolexp examples, but the idea is we've compiled a boolean expression and left the user with a new function address to use. Oh, some would say, why not evaluate our boolean expression directly, rather than taking it, compiling MUF code, and executing that address? Isn't this rather roundabout? Because, we could use the MUF address as a return value of a program, for instance, where in other cases you would want to return your own evaluation function. Ugh. I *am* babbling. Questions? -- ChupChup From tinymuck-sloggers-owner Mon Oct 8 21:00:26 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04531; Mon, 8 Oct 90 20:59:20 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04526; Mon, 8 Oct 90 20:59:17 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA11373; Mon, 8 Oct 90 20:57:50 -0700 Date: Mon, 8 Oct 90 20:57:50 -0700 From: jearls@polyslo.CalPoly.EDU (MicroBrain) Message-Id: <9010090357.AA11373@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Proposal for Lock Evaluation in MUF Cc: rearl@grunt.berkeley.edu Status: O Chup said: >Hmmm... > >A few thoughts of mine on boolean expressions :- > >Boolean expressions are one of the greatest things to come to tinyMUD. >Their biggest drawback in that context: they only come one per object. >I'm aiming to have boolean expressions in p-lists for 2.3 which would >obviate a need to have the .key part of a database object hardcoded. >(Among many other things that can be stored in p-lists!) > OK, I'm lost. Why the need for multiple locks? You mean a specific lock keyed to a player? Why not use a bool expression for that... @lock in=(*Slinky | (*Sthiss & BlackKey) | (*Lynx & WhiteKey) | (*chupchup & InvisibleKey)) > >The proposal looks interesting and it's on my wavelength, but I think >this can be done a lot easier. To wit: a function address is a fully >operational type in MUF, but right now it's only available to the >compiler; 'foo leaves you foo's address, a constant for the duration >the program's code is in core memory. Interpreting it will always push >the same number on the stack. > >Oh, before I start in on it, one thing I'm pretty sure to put in - >a PROG_BOOLEXP type for MUF. Maybe this isn't necessary? Basically >you would use "getlock" to return a boolexp type on the stack, then >[ see below ] use my idea on it. > >Here's the boolexp/address idea: have a "compile_boolexp" primitive >which takes a boolexp/property (see above) and compiles it *into a >MUF function*, returning its newly allocated address. Run this with >a dbref on the stack, and your result is true or false. Example: > OK, one little thing -- would there be a way to deallocate the space used by the new function? Say I wanted to make a program to go through and find all the exits that I could go through. I don't particularly want all the old lock functions left laying around taking up memory and possibly crashing the MUCK... > >~~~~ you wake up in the future - bear with me :) ~~~~~ > ACK! Get out the paper and get ready to do a stack trace! :-) >: check-my-lock ( -- i ) >me @ "foo-key" getproplock (check property; leave boolexp type on the stack) >dup trigger @ me @ name rot 0 addprop (adds the user's key to the list) >compile_boolexp (takes user's key, returns address of new function) >trigger @ owner swap execute (put programmer's dbref on stack, execute lock) >; (returns result of the compiled boolexp, telling me if I, the programmer, > fits the user's foo-key lock) I have no idea what this little piece of code is supposed to do... > >Anyway, I may just be babbling, is anyone with me still? Perhaps >I'm going overboard on the boolexp examples, but the idea is we've >compiled a boolean expression and left the user with a new function >address to use. > >Oh, some would say, why not evaluate our boolean expression directly, >rather than taking it, compiling MUF code, and executing that address? >Isn't this rather roundabout? Because, we could use the MUF address as >a return value of a program, for instance, where in other cases you >would want to return your own evaluation function. > >Ugh. I *am* babbling. Questions? > >-- ChupChup > -- JaXoN / R'n'D -- John _______________________________________________________________________________ | | Q: "Growl for me, microbrain; jearls@polyslo.CalPoly.EDU | show me that you still care." From tinymuck-sloggers-owner Mon Oct 8 21:30:26 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04831; Mon, 8 Oct 90 21:18:21 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04827; Mon, 8 Oct 90 21:18:19 PDT Message-Id: <9010090418.AA04827@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Tue, 9 Oct 90 00:18:15 -0400 Date: Tue, 9 Oct 90 00:18:13 -0400 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: locks Status: O Forgive me if I'm missing something, but just what's wrong with having only a MUF primitive (say, checklock) which takes two parameters, objects X and Y, and returns true if X isn't locked to Y, and false otherwise? And leave the locks as they are. From tinymuck-sloggers-owner Mon Oct 8 21:43:31 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04573; Mon, 8 Oct 90 21:07:46 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04569; Mon, 8 Oct 90 21:07:45 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA06406; Mon, 8 Oct 90 21:07:36 PDT Date: Mon, 8 Oct 90 21:07:36 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010090407.AA06406@grunt.berkeley.edu> To: jearls@polyslo.calpoly.edu Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: MicroBrain's message of Mon, 8 Oct 90 20:57:50 -0700 <9010090357.AA11373@polyslo.CalPoly.EDU> Subject: Proposal for Lock Evaluation in MUF Status: O Okay, to clear up your questions, here's a very common example of a need for multiple locks. BOXES. MbongoMUCK has a local BOXES mod, for those who don't know, and Mbongo himself admits BOXES are a rather distasteful hack that he put in when it was an inflexible MUD. One big reason is, you can't have a put-in-box lock, a take-out-of-box lock, an open-box lock, a take-the-actual-box lock, etc. So for a box, one key does not cut it. Put them in p-lists, you can have zero locks or 50 locks, depending on how complex your item is. About the functions -- this would be a temporarily allocated spot to be freed after interp cleanup. You can't store a function address anywhere as it is, and it would be dangerous to do so as the pointer would become invalid on recompile of the corresponding program. -- ChupChup From tinymuck-sloggers-owner Mon Oct 8 21:52:29 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04856; Mon, 8 Oct 90 21:22:20 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04852; Mon, 8 Oct 90 21:22:17 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA13123; Mon, 8 Oct 90 21:21:55 -0700 Date: Mon, 8 Oct 90 21:21:55 -0700 From: jearls@polyslo.CalPoly.EDU (MicroBrain) Message-Id: <9010090421.AA13123@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Proposal for Lock Evaluation in MUF Cc: rearl@grunt.berkeley.edu Status: O Chup replied: > >About the functions -- this would be a temporarily allocated spot to be >freed after interp cleanup. You can't store a function address anywhere >as it is, and it would be dangerous to do so as the pointer would become >invalid on recompile of the corresponding program. > >-- ChupChup > OK, but what about a program that does large numbers of lock checking in _one_ execution? All those functions would be in memory until the end of the run? -- JaXoN/R'n'D -- John _______________________________________________________________________________ | | Q: "Growl for me, microbrain; jearls@polyslo.CalPoly.EDU | show me that you still care." From tinymuck-sloggers-owner Mon Oct 8 22:00:27 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04915; Mon, 8 Oct 90 21:36:10 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04911; Mon, 8 Oct 90 21:36:08 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA06427; Mon, 8 Oct 90 21:35:57 PDT Date: Mon, 8 Oct 90 21:35:57 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010090435.AA06427@grunt.berkeley.edu> To: arromdee@server.cs.jhu.edu Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: arromdee@server.cs.jhu.edu's message of Tue, 9 Oct 90 00:18:13 -0400 <9010090418.AA04827@belch.Berkeley.EDU> Subject: locks Status: O | Forgive me if I'm missing something, but just what's wrong with having only | a MUF primitive (say, checklock) which takes two parameters, objects X and Y, | and returns true if X isn't locked to Y, and false otherwise? And leave the | locks as they are. Sounds good for a limited extension to some type of TinyMUD game, but we're talking about TinyMUCK. -- ChupChup From tinymuck-sloggers-owner Mon Oct 8 22:14:39 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04959; Mon, 8 Oct 90 21:39:58 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA04955; Mon, 8 Oct 90 21:39:57 PDT Received: by avalanche.Berkeley.EDU (5.61/CHAOS) id AA00546; Mon, 8 Oct 90 21:39:52 -0700 Date: Mon, 8 Oct 90 21:39:52 -0700 From: Jon Blow Message-Id: <9010090439.AA00546@avalanche.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: You know what they say... Status: O > Forgive me if I'm missing something, but just what's wrong with having only > a MUF primitive (say, checklock) which takes two parameters, objects X and Y, > and returns true if X isn't locked to Y, and false otherwise? And leave the > locks as they are. "No hosers!" From tinymuck-sloggers-owner Mon Oct 8 22:30:27 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA05102; Mon, 8 Oct 90 22:23:53 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA05098; Mon, 8 Oct 90 22:23:51 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA17929; Mon, 8 Oct 90 22:23:42 -0700 Date: Mon, 8 Oct 90 22:23:42 -0700 From: jearls@polyslo.CalPoly.EDU (MicroBrain) Message-Id: <9010090523.AA17929@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: locks Status: O +| Forgive me if I'm missing something, but just what's wrong with having only +| a MUF primitive (say, checklock) which takes two parameters, objects X and Y, +| and returns true if X isn't locked to Y, and false otherwise? And leave the +| locks as they are. + +Sounds good for a limited extension to some type of TinyMUD game, but +we're talking about TinyMUCK. + +-- ChupChup + Actually, when I was thinking about the lock eval, I couldn't really think of a good reason why you would WANT to evaluate it as part of the program instead of part of the MUCK... the checklock procedure mentioned would be a generic version of the lock functions CC is talking about... -- JaXoN/R'n'D -- John _______________________________________________________________________________ | | Q: "Growl for me, microbrain; jearls@polyslo.CalPoly.EDU | show me that you still care." From tinymuck-sloggers-owner Mon Oct 8 23:00:27 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA05130; Mon, 8 Oct 90 22:34:59 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA05126; Mon, 8 Oct 90 22:34:57 PDT Message-Id: <9010090534.AA05126@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Tue, 9 Oct 90 01:34:54 -0400 Date: Tue, 9 Oct 90 01:34:52 -0400 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: sigh Status: O I shouldn't send out messages at a quarter to one, I suppose.... From tinymuck-sloggers-owner Mon Oct 8 23:12:18 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA05136; Mon, 8 Oct 90 22:39:00 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA05132; Mon, 8 Oct 90 22:38:55 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA19673; Mon, 8 Oct 90 22:38:48 -0700 Date: Mon, 8 Oct 90 22:38:48 -0700 From: gminette@polyslo.CalPoly.EDU (The Sylver Dragon) Message-Id: <9010090538.AA19673@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Proposal for Lock Evaluation Status: O ChupChup writes: >Okay, to clear up your questions, here's a very common example of a need >for multiple locks. BOXES. MbongoMUCK has a local BOXES mod, for those >who don't know, and Mbongo himself admits BOXES are a rather distasteful >hack that he put in when it was an inflexible MUD. One big reason is, >you can't have a put-in-box lock, a take-out-of-box lock, an open-box lock, >a take-the-actual-box lock, etc. So for a box, one key does not cut it. >Put them in p-lists, you can have zero locks or 50 locks, depending on >how complex your item is. I can attest to the need for that! I have been trying to work out how to make my TygBoot use only a couple of locks per item in it's latest version that I'm doing. Vehicles objects for example, cause problems with room locks. If the room lock is being used to determine if the room's succ or fail is shown, then what do I use for determining if a player can exit a vehicle into that room? and what about a lock to prevent items from using an exit as opposed to players? Can't be done right with only a single lock list per object. (at least not easily with UberMUD, since I have to make kludgy lock lists that aren't even boolean) Multiple locks can be VERY useful, even if I don't quite grok Chup's way of doing them. - Tygryss in Exile: Day one. - Mailed for krivers@nike.calpoly.edu (Tygryss/littlefox/Menolly) - Individual replies should be sent to gminette@polyslo.calpoly.edu - with 'for Karen' in the subject line. From tinymuck-sloggers-owner Fri Oct 19 17:32:42 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25661; Fri, 19 Oct 90 17:25:26 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA25657; Fri, 19 Oct 90 17:25:24 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA08540; Fri, 19 Oct 90 11:07:32 PDT Date: Fri, 19 Oct 90 11:07:32 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010191807.AA08540@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Some MUF code... Status: O Here's a few useful MUF routines I wrote last night, it's basically three functions, two of which are useful on their own, and a main body that uses both. Also included is MUV source so you can see how neat MUV is and so I can excuse the ugly raw MUF :) If anyone else has some useful subroutines like this, that you think would be useful in many MUCKs' macro libraries, feel free to post it here or on belch's ftp directory. There's a subdirectory of pub/tinymuck, muf-examples, just waiting for code... -- ChupChup @edit setprop 1 5000 d i var arg1 var pos ( s -- s1 s2 ) ( parses arguments separated by an "=" ) ( does not handle spaces surrounding the "=" correctly ) ( 2 variables ) : parse_args arg1 ! arg1 @ "=" instr pos ! pos @ not if arg1 @ "" exit then arg1 @ pos @ 1 - strcut 1 strcut swap pop exit ; ( d1 d2 -- i ) ( returns true if d1 controls d2. results are ) ( undefined if d1 is not a player object. ) ( 0 variables -- suitable for inline macro use ) : controls swap over ok? not if pop pop 0 exit then swap over swap owner dbcmp swap "WIZARD" flag? or exit ; ( s -- i ) ( main routine for a generic property setting program, ) ( modeled after @desc, etc. property on trigger "property" tells ) ( it which property it is to modify. ) var target var text var argv : setprop trigger @ "property" getpropstr argv ! argv @ not if me @ "This command has not been initialized." notify 0 exit then parse_args text ! target ! target @ not if me @ "You must specify something to @" argv @ "." strcat strcat notify 0 exit then target @ match target ! target @ not if me @ "I don't see that here." notify 0 exit then target @ 2 0 swap - dbref dbcmp if me @ "I don't know which one you mean!" notify 0 exit then me @ target @ controls not if me @ "Permission denied." notify 0 exit then text @ not dup if pop target @ argv @ remove_prop me @ "Message removed." notify 1 then not if target @ argv @ text @ 0 addprop me @ "Message set." notify then 1 exit ; . c q #include "db.h" /* some short header files I cooked up */ #include "io.h" /* these follow the program source */ func parse_args() { var arg1, arg2, pos; arg1 = top; pos = instr(arg1, "="); if (!pos) { push(arg1, ""); return; } strcut(arg1, pos - 1); pop(swap(strcut(top, 1))); return; /* Two values */ } func controls() { over(swap()); if (!ok?(top)) { pop(); pop(); return (0); } over(swap()); return (dbcmp(owner(swap()), top) || flag?(swap(), "WIZARD")); } func setprop() { var target, text, argv; argv = getpropstr(trigger, "property"); if (!argv) { tell_me("This command has not been initialized."); exit (0); } parse_args(); text = top; target = top; if (!target) { tell_me(strcat("You must specify something to @", strcat(argv, "."))); exit (0); } target = match(target); if (!target) { /* No match */ tell_me("I don't see that here."); exit (0); } if (dbcmp(target, AMBIGUOUS)) { tell_me("I don't know which one you mean!"); exit (0); } if (!controls(me, target)) { tell_me("Permission denied."); /* You could scribble on someone else's */ exit (0); /* properties but it's not social. */ } if (!text) { remove_prop(target, argv); tell_me("Message removed."); } else { addprop(target, argv, text, 0); tell_me("Message set."); } exit (1); } From tinymuck-sloggers-owner Fri Oct 26 15:53:41 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02474; Fri, 26 Oct 90 15:30:35 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA02470; Fri, 26 Oct 90 15:30:32 PDT Received: from phantom.CalPoly.EDU by polyslo.CalPoly.EDU (5.61/2.890629) id AA15684; Fri, 26 Oct 90 15:30:24 -0700 Received: by phantom.calpoly.edu (4.12/1.881115) id AA03537; Fri, 26 Oct 90 15:30:07 pdt Date: Fri, 26 Oct 90 15:30:07 pdt From: jearls@phantom.calpoly.edu (MicroBrain) Message-Id: <9010262230.AA03537@phantom.calpoly.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: MUF Temple code Status: O This is a MUF program to simulate the MUD-style temples in MUCK. Create an action called 'drop;dro;dr' or whatever and link it to this program. You can customize the messages somewhat with properties on the action (see the dox at the top of the code). - R'n'D / JaXoN (jearls@polyslo.calpoly.edu) @edit gen-temple 1 999 d 1 i ( Generic Temple Code for MUCK 2.2 ) ( by JaXoN ) ( ) ( Properties called 'temple' and 'otemple' on the trigger describe what ) ( people see. "%w" will be replaced by the name of the object, and "%c" ) ( with the number of pennies. ) : temple match dup #-1 dbcmp if pop "I don't see that here." .tell exit then dup #-2 dbcmp if pop "I don't know which one you mean!" .tell exit then dup thing? over program? or if dup name trigger @ "otemple" getpropstr dup if "%w" "%W" subst "%%w" "%w" subst "%c" "%W" subst "%%c" "%c" subst me @ swap pronoun_sub over "%w" subst 3 pick pennies intostr "%c" subst me @ name " " strcat swap strcat .otell else pop then trigger @ "temple" getpropstr "%w" "%W" subst "%%w" "%w" subst "%c" "%W" subst "%%c" "%c" subst me @ swap pronoun_sub swap "%w" subst over pennies intostr "%c" subst .tell dup pennies me @ pennies over + 9999 > if pop 9999 me @ pennies - then me @ swap addpennies dup getlink moveto else pop me @ "You can't drop that." notify then ; . c q QUIT From tinymuck-sloggers-owner Fri Oct 26 23:53:45 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA05476; Fri, 26 Oct 90 23:42:40 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA05472; Fri, 26 Oct 90 23:42:38 PDT Received: by danube.Berkeley.EDU (5.57/Ultrix3.0-C) id AA15986; Fri, 26 Oct 90 23:41:26 -0700 Date: Fri, 26 Oct 90 23:41:26 -0700 From: c150-eb@danube.berkeley.edu (Doug Orleans) Message-Id: <9010270641.AA15986@danube.Berkeley.EDU> To: jearls@phantom.calpoly.edu Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: MicroBrain's message of Fri, 26 Oct 90 15:30:07 pdt <9010262230.AA03537@phantom.calpoly.edu> Subject: MUF Temple code Status: O Did you know that you can have the @drop field of a room (or anything else, for that matter) set to trigger a program? Just say @drop #=#. Then whenever anything is dropped in the room, your program is run, with trigger being the object dropped, and me being the person who dropped it. This way, you can avoid having to match the argument, nor do you have to create an action called drop. (This feature was in fact intended to solve this sort of problem; for instance, what if the player has an action called drop also?) Anyone, please correct me if I'm wrong; this is how it was in the beta version of 2.2. A note on style: you shouldn't include macros in your public program listings, because not every 2.2 Muck has the particular macro you're using (.tell, in this instance), and those which do may be defined differently. You should expand the macro manually, or better yet include the macro listing separately so that other Mucks can add to their macro library. In fact, we should start posting any useful macros to this mailing list so we can all share... DougO, aka WhiteRabbit ``A witty saying proves nothing.'' -- Voltaire From tinymuck-sloggers-owner Sat Oct 27 15:53:54 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07664; Sat, 27 Oct 90 15:41:59 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA07660; Sat, 27 Oct 90 15:41:55 PDT Message-Id: <9010272241.AA07660@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Sat, 27 Oct 90 18:41:48 -0400 Date: Sat, 27 Oct 90 18:41:46 -0400 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Yet Another Muf Example Program Status: O OK, since everybody else seems to be showing programs, here's an attempt to simulate the MUF editor in MUF. (Appended is a short program to put in the descs of objects, so you can look at an object and see the lines of text.) I originally wrote this under 2.1 so I could edit the Mud test on the Muck, which accounts for certain bogosities.... ----------------------------------------------------------------------- (Test editor program. Format of test is:) (cline: current line [numeric variable; refers to virtual line number]) (clinea: current line [ditto; actual line number as used in properties]) (next1, next2...., prev1, prev2....: pointers from actual lines to previous) ( and next actual lines. "0" if none; otherwise a string representing a) ( number. [string properties of edited item]) (numlines: numeric variable, also stored in string property with same name) (first: ditto. Refers to actual, not virtual, lines.) (newl: used when adding a line. Never decreases; always increases.) (nonumbers: non-zero if line numbers are off) (read_in_line/output_line/freeline: only these functions care about the format) ( of the line, which needn't even be a line. I'd make them separate functions) (settable by properties, except that you might want to use some internal) (variablesd of this program.) var dv var item var counter var cline var clinea var first var numlines var newl var rangetop var rangeend (Function to take a line from the stack top and stick it in actual line #newl) : read_in_line (str --) item @ swap "test" newl @ intostr strcat swap 0 addprop ; (Function to print a line at whatever line is in clinea, numbered as in cline.) : output_line (--) me @ item @ "test" clinea @ intostr strcat getpropstr item @ "nonumbers" getpropstr not if cline @ intostr ": " strcat swap strcat then notify ; : freeline (int --) item @ swap "test" swap intostr strcat remove_prop ; : setptr (ob int str int --) (i.e. setprev ob 52 "prev" 100 sets 100->prev = 52) intostr strcat swap intostr 42 addprop ; : getptr (ob str int -- int) intostr strcat getpropstr atoi ; : testresults (str --) ": cline=" strcat cline @ intostr strcat " clinea=" strcat clinea @ intostr strcat " clinea->prev=" strcat item @ "prev" clinea @ getptr intostr strcat " clinea->next=" strcat item @ "next" clinea @ getptr intostr strcat " numlines=" strcat numlines @ intostr strcat " newl=" strcat newl @ intostr strcat " newl->prev=" strcat item @ "prev" newl @ getptr intostr strcat " newl->next=" strcat item @ "next" newl @ getptr intostr strcat " first=" strcat first @ intostr strcat me @ swap notify ; (Infinite loop in insert mode until . is typed) : insertloop (int -- int) dup 15 >= if exit then read dv ! dv @ "." strcmp not if pop 1000 exit then newl @ 1 + newl ! (Create a blank line for read_in_line to fill in) dv @ read_in_line (Bump count of lines, and current line) cline @ 1 + cline ! numlines @ 1 + numlines ! (If we added above the first line, set the first) cline @ 2 = if newl @ first ! then (Link the new line into the linked list) (newl->next = clinea) item @ clinea @ "next" newl @ setptr (newl->prev = clinea->prev) item @ item @ "prev" clinea @ getptr "prev" newl @ setptr (Special case: if first, don't fix the previous one [which doesn't exist].) ([Although there is a 0, it's the last and not first element.]) cline @ 2 = not if (clinea->prev->next = newl) item @ newl @ "next" item @ "prev" clinea @ getptr setptr then (clinea->prev = newl) item @ newl @ "prev" clinea @ setptr 1 + insertloop 1 - 1 + insertloop 1 - 1 + insertloop 1 - 1 + insertloop 1 - 1 + insertloop 1 - ; : insert me @ "Entering insert mode." notify 0 insertloop pop me @ "Leaving insert mode." notify ; : destroystack dup 0 = if pop exit then 1 - swap pop destroystack ; : printlineloop dup 15 >= if exit then cline @ numlines @ > if pop 1000 exit then cline @ rangeend @ > if pop 1000 exit then cline @ rangetop @ >= if output_line then cline @ 1 + cline ! (clinea = clinea->next) item @ "next" clinea @ getptr clinea ! 1 + printlineloop 1 - 1 + printlineloop 1 - 1 + printlineloop 1 - 1 + printlineloop 1 - 1 + printlineloop 1 - ; : printlines rangetop @ numlines @ > if me @ "Line not available for display." notify exit then rangetop @ rangeend @ > numlines not or if me @ "No lines to print." notify exit then 1 cline ! first @ clinea ! 0 printlineloop pop rangetop @ rangeend @ < if me @ "Lines listed." notify then ; (Finds cline and clinea, given a range start. [Actually cline is trivial]) : findlineloop dup 15 >= if exit then swap dup 1 = if pop (the zero cline) pop 1000 exit then 1 - swap (dv = dv->next) item @ "next" dv @ getptr dv ! 1 + findlineloop 1 - 1 + findlineloop 1 - 1 + findlineloop 1 - 1 + findlineloop 1 - 1 + findlineloop 1 - ; : findline (-- int) first @ dv ! rangetop @ numlines @ 1 + <= not if me @ "There are only " numlines @ intostr strcat " lines!" strcat notify 0 exit then rangetop @ 0 <= if me @ "Line must be positive." notify 0 exit then rangetop @ 0 findlineloop pop rangetop @ cline ! dv @ clinea ! 1 ; : deletelineloop dup 15 >= if exit then clinea @ not if pop 1000 exit then (no more lines!) cline @ rangeend @ > if pop 1000 exit then (end of range) counter @ 1 + counter ! cline @ 1 = if (first = clinea->next) item @ "next" clinea @ getptr first ! else (clinea->prev->next = clinea->next) item @ item @ "next" clinea @ getptr "next" item @ "prev" clinea @ getptr setptr then (clinea->next->prev = clinea->prev) item @ item @ "prev" clinea @ getptr "prev" item @ "next" clinea @ getptr setptr clinea @ dv ! (clinea = clinea->next) item @ "next" clinea @ getptr clinea ! (Now delete the line) item @ "prev" dv @ intostr strcat remove_prop item @ "next" dv @ intostr strcat remove_prop dv @ freeline numlines @ 1 - numlines ! rangeend @ 1 - rangeend ! 1 + deletelineloop 1 - 1 + deletelineloop 1 - 1 + deletelineloop 1 - 1 + deletelineloop 1 - 1 + deletelineloop 1 - ; : deletelines 0 counter ! 0 deletelineloop pop me @ counter @ intostr " lines deleted." strcat notify ; : parse (Check all the 0 parameter commands) dup dup "h" stringcmp 0 >= swap "i" stringcmp 0 < and if pop (the h) me @ "Commands are like the MUF program editor. Line numbers are optional" notify me @ " d delete lines" notify me @ "help this message" notify me @ " i enter insert mode" notify me @ ". (while in insert mode) exit insert mode" notify me @ " l list lines" notify me @ "n toggle line numbering" notify me @ "q quit editor" notify 1 exit then dup dup "n" stringcmp 0 >= swap "o" stringcmp 0 < and if pop (the n) item @ "nonumbers" getpropstr if item @ "nonumbers" remove_prop me @ "Line numbers now on." notify else item @ "nonumbers" "yes" 0 addprop me @ "Line numbers now off." notify then 1 exit then dup dup "i" stringcmp 0 >= swap "j" stringcmp 0 < and if pop (insert doesn't use rangetop/end except for findline, not needed here) insert 1 exit then dup dup "l" stringcmp 0 >= swap "m" stringcmp 0 < and if pop cline @ rangetop ! cline @ rangeend ! printlines 1 exit then dup dup "d" stringcmp 0 >= swap "e" stringcmp 0 < and if pop cline @ rangetop ! cline @ rangeend ! deletelines 1 exit then dup dup "c" stringcmp 0 >= swap "d" stringcmp 0 < and if pop me @ "Oh dear, I hope you didn't think this was the _program_ editor." notify 1 exit then dup dup "a" stringcmp 0 >= swap "b" stringcmp 0 < and if pop me @ "No assembly required." notify 1 exit then " " explode dup 3 = not if dup 2 = not if destroystack 0 exit then pop (the 2) (Check all the 1 parameter commands) atoi rangetop ! dup dup "l" stringcmp 0 >= swap "m" stringcmp 0 < and if pop (the l) rangetop @ rangeend ! printlines 1 exit then dup dup "i" stringcmp 0 >= swap "j" stringcmp 0 < and if pop (the i) findline not if 1 exit then insert 1 exit then dup dup "d" stringcmp 0 >= swap "e" stringcmp 0 < and if pop (the i) findline not if 1 exit then rangetop @ rangeend ! deletelines 1 exit then pop 0 exit then pop (zap the extra 3) atoi rangetop ! atoi rangeend ! (Check all the 2 parameter commands) dup dup "l" stringcmp 0 >= swap "m" stringcmp 0 < and if pop (the l) printlines 1 exit then dup dup "d" stringcmp 0 >= swap "e" stringcmp 0 < and if pop (the d) findline not if 1 exit then deletelines 1 exit then pop 0 ; (Input an editing command from the user and parse it.) : editloop (int -- int) dup 15 >= if exit then read dv ! dv @ "q" stringcmp 0 >= dv @ "r" stringcmp 0 < and if pop 1000 (Immediately exit.) item @ "numlines" numlines @ intostr 0 addprop item @ "first" first @ intostr 0 addprop item @ "newl" newl @ intostr 0 addprop item @ "clinea" clinea @ intostr 0 addprop item @ "cline" cline @ intostr 0 addprop me @ "Editor exited." notify exit then dv @ parse not if me @ "Illegal editor command." notify then 1 + editloop 1 - 1 + editloop 1 - 1 + editloop 1 - 1 + editloop 1 - 1 + editloop 1 - ; : main dup not if me @ "You have to specify what you wish to edit!" notify exit then match dup #-1 dbcmp if me @ "I don't see that here." notify exit then dup #-2 dbcmp if me @ "I don't know which one you mean!" notify exit then (dup owner me @ dbcmp not me @ "wizard" flag? not me @ "mucker" flag? and and not if me @ "Permission denied." notify exit then) item ! item @ "numlines" getpropstr dup not if pop "0" then atoi numlines ! item @ "first" getpropstr dup not if pop "0" then atoi first ! item @ "newl" getpropstr dup not if pop "0" then atoi newl ! item @ "clinea" getpropstr dup not if pop "0" then atoi clinea ! item @ "cline" getpropstr dup not if pop "1" then atoi cline ! cline @ dup rangetop ! rangeend ! printlines item @ "prev0" getpropstr not if item @ "prev0" "0" 0 addprop item @ "next0" "0" 0 addprop then me @ "Entering editor." notify 0 editloop pop ; ------------------------------------------------------------------------ var ob var cline var clinea var numlines : getptr (ob str int -- int) intostr strcat getpropstr atoi ; : output_line (--) me @ ob @ "test" clinea @ intostr strcat getpropstr notify ; : printlineloop dup 15 >= if exit then cline @ numlines @ > if pop 1000 exit then output_line cline @ 1 + cline ! (clinea = clinea->next) ob @ "next" clinea @ getptr clinea ! 1 + printlineloop 1 - 1 + printlineloop 1 - 1 + printlineloop 1 - 1 + printlineloop 1 - 1 + printlineloop 1 - ; : main trigger @ ob ! ob @ "numlines" getpropstr dup atoi dup numlines ! and not if dup if me @ swap notify else ob @ room? not if me @ "You see nothing special." notify then then else 1 cline ! ob @ "first" getpropstr dup not if pop "0" then atoi clinea ! 0 printlineloop pop then ; From tinymuck-sloggers-owner Sat Oct 27 17:23:54 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07826; Sat, 27 Oct 90 17:17:36 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA07822; Sat, 27 Oct 90 17:17:35 PDT Received: by typhoon.Berkeley.EDU (5.61/CHAOS) id AA12282; Sat, 27 Oct 90 17:17:25 -0700 Date: Sat, 27 Oct 90 17:17:25 -0700 From: Jon Blow Message-Id: <9010280017.AA12282@typhoon.Berkeley.EDU> To: arromdee@server.cs.jhu.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Yet Another Muf Example Program Status: O No offense intended, but duplicating the muf editor in muf has got to be one of the dumbest things I've ever seen in my life, and I've seen a whole lot of dumb things. From tinymuck-sloggers-owner Sat Oct 27 17:53:54 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07872; Sat, 27 Oct 90 17:42:02 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA07868; Sat, 27 Oct 90 17:42:01 PDT Received: by grunt.berkeley.edu (4.1/1.30) id AA16568; Sat, 27 Oct 90 17:07:47 PDT Date: Sat, 27 Oct 90 17:07:47 PDT From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9010280007.AA16568@grunt.berkeley.edu> To: blojo@ocf.berkeley.edu Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Jon Blow's message of Sat, 27 Oct 90 17:17:25 -0700 Subject: Yet Another Muf Example Program Status: O Of course the MUF editor is nothing to get excited over, but one of the most important things in MUCK lately is being able to manipulate property lists easily. If you have a better program for editing said lists that works for 2.2 MUCK, I think a lot of people would be interested in seeing it. -- ChupChup From tinymuck-sloggers-owner Sat Oct 27 18:53:55 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07941; Sat, 27 Oct 90 18:29:19 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA07937; Sat, 27 Oct 90 18:29:17 PDT Received: by tornado.Berkeley.EDU (5.61/CHAOS) id AA02103; Sat, 27 Oct 90 18:29:14 -0700 Date: Sat, 27 Oct 90 18:29:14 -0700 From: Jon Blow Message-Id: <9010280129.AA02103@tornado.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Editing p-lists Status: O Well, it's an interesting idea, but not overly feasible. Being able to edit p-lists means that you need some sort of meaningful line-ordering for the lists, which means that either all your properties are named predictably or you have an index which informs of and orders said entries (and which must be updated each time an entry is added). The latter produces a lot of overhead as far as memory, time, and space are concerned; the former is a pain, if only because it is a step backwards. Now, writing an editor in MUF is not necessarily a bad idea, but a cohabiting muf and non-muf editor are a really bad idea (especially when they're not quite the same.) This starts to cause problems like those which occurred in the program library on ChupMUCK, where Three decided to make macros that worked entirely different from other peoples' (and which had more negative effect when used than positive) and, because of this, new people are discouraged from using the macros because they can't figure out how they work because the second they get one working they try to use another and find it broken for some reason. Now, if the server were to call a piece of muf software for its editor, and this same editor could also be accessed from the command line, the situation would be fine; almost as good would be an editor that, though built into the server, was versatile enough to be used on more than just programs in the m/ directory. But having one in one place and one in the other isn't kosher. Stinglai From tinymuck-sloggers-owner Sat Oct 27 21:23:56 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08446; Sat, 27 Oct 90 21:18:04 PDT Received: by belch.Berkeley.EDU (5.57/1.41) id AA08442; Sat, 27 Oct 90 21:18:02 PDT Received: by rex.cs.tulane.edu; Sat, 27 Oct 90 23:18:01 -0500 Message-Id: <9010280418.AA10709@rex.cs.tulane.edu> From: Michael Rawdon Subject: Please Remove Me To: tinymuck-sloggers@belch.Berkeley.EDU Date: Sat, 27 Oct 90 23:18:00 CDT X-Mailer: ELM [version 2.3 PL6] Status: O Please remove me from the tinymuck-sloggers mailing list. Thanx. -- Michael Rawdon Tulane University, New Orleans, Louisiana ------------------------------------------------------------------------------ Internet: rawdon@rex.cs.tulane.edu | "I trusted him like a brother; that is Usenet: rex!rawdon.uucp | to say, not at all." Bitnet: CS6FECU@TCSVM | - Roger Zelazny ----------------------------------------------------------------------------- Disclaimer: Opinions mine, typos and grammar errors someone else's. From tinymuck-sloggers-owner Sun Oct 28 10:24:58 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA10350; Sun, 28 Oct 90 10:18:44 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA10343; Sun, 28 Oct 90 10:18:41 PST Message-Id: <9010281818.AA10343@belch.Berkeley.EDU> Subject: Re: Yet Another Muf Example Program To: Jon Blow Date: Sun, 28 Oct 90 12:16:51 CDT Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: <9010280017.AA12282@typhoon.Berkeley.EDU>; from "Jon Blow" at Oct 27, 90 5:17 pm X-Mailer: ELM [version 2.2 PL10] From: mtymp01@ux.acs.umn.edu Status: O > No offense intended, but duplicating the muf editor in muf has got to > be one of the dumbest things I've ever seen in my life, and I've seen > a whole lot of dumb things. It is not dumb. Maybe some people don't like the current muf editor? Maybe some people want to write their own clients that communicate with the editor in an unusual way? I suggest 4 new primitives: getmline (dbref number -- string) setmline (dbref number string --) delmline (dbref number --) insmline (dbref number string --) From tinymuck-sloggers-owner Sun Oct 28 17:54:06 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11960; Sun, 28 Oct 90 17:21:23 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA11956; Sun, 28 Oct 90 17:21:21 PST Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA21651; Sun, 28 Oct 90 17:21:15 -0800 Date: Sun, 28 Oct 90 17:21:15 -0800 From: gminette@polyslo.CalPoly.EDU (The Sylver Dragon) Message-Id: <9010290121.AA21651@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Yet Another Muf Example Program Status: O Stinglai, Stinglai, Stinglai. You will eat your words when you see the list manager and list editor that Sthiss and I have written. This will all be mailed out as soon as we have added a few more bells and whistles like the move feature, and the ability to incorporate other lists into the one you are editing. It is a MUCH better editor than the @edit. And it is pretty much already done, so it's not VaporWare. The list manager routines and the list editor will be integral to MUBAR (my unofficial name for the crossroads MUCK in building right now) along with my newly completed BBS system and Sthiss's MUFmail program. (MUCH bettr than the APO). Heck, we practically are gonna have UNIXMUCK. (bleagh!) I still have to do the lmgr-keysearch and edit-format routines, but when the whole shmere is done, Sthiss will eventually tar it with all sorts of stuff that uses it. (I believe I forgot to mention Sthiss's heirarchial help system too) Expect to see it in the mailing list, but I can't give any timeline as to when. - MUFfing along, - Tygryss - Mailed for krivers@nike.calpoly.edu (Tygryss/littlefox/Menolly) - Replies should be sent to gminette@polyslo.calpoly.edu - with 'for Karen' in the subject line. From tinymuck-sloggers-owner Sun Oct 28 18:54:06 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12202; Sun, 28 Oct 90 18:28:49 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA12198; Sun, 28 Oct 90 18:28:48 PST Received: from web-3e.Berkeley.EDU by weaver.berkeley.edu (4.0/1.33(web)) id AA14679; Sun, 28 Oct 90 18:28:46 PST Date: Sun, 28 Oct 90 18:28:46 PST From: c60b-2aj@WEB.berkeley.edu (Stinglai Ka'abi) Message-Id: <9010290228.AA14679@weaver.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Yellow Submarines Status: O I reiterate that the problem is not having an editor written in the extension language, but that of having different editors for doing different things within the same program. I wish people would understand these things. On the subject of new primitives, how about these four? getmlife (dbref number -- life) setmlife (dbref number life -- ) ( what happens when you play TinyMUD too much.) delmlife (dbref number -- ) ( what happens when you play TinyMUD too much for too long.) insmlife (dbref number life -- ) ( 'specially for schizophrenics ) From tinymuck-sloggers-owner Sun Oct 28 23:54:08 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12941; Sun, 28 Oct 90 23:41:09 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA12937; Sun, 28 Oct 90 23:41:06 PST Received: by danube.Berkeley.EDU (5.57/Ultrix3.0-C) id AA11724; Sun, 28 Oct 90 23:39:59 -0800 Date: Sun, 28 Oct 90 23:39:59 -0800 From: c150-eb@danube.berkeley.edu (Doug Orleans) Message-Id: <9010290739.AA11724@danube.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Pink elephants and white rabbits Status: O Ah, what would we do without the stinging wit of Stinglai? It's really a breath of fresh air compared to a letter crowded with smileys and IMHOs and ``I don't want to start a flame war, but...''s... Anyway, I agree that a MUF editor that duplicates @edit is worth nothing more than MUFfing practice. I eagerly await Tygryss' editor. What would be really neat is a screen-oriented editor that used a termcap library (the programmer would have a property called term). But that seems too daunting to even bother with, when you can just edit off-line and upload. Here's my entry of the week for the MUCK 2.3 suggestion box: put source code into the property list of a program (rather than store it in a separate m/ directory.) (1) This would make it easier to write a MUF editor and (2) you could write SELF-MODIFYING CODE! Mwoooaahahahahahaha! DougO aka WhiteRabbit From tinymuck-sloggers-owner Mon Oct 29 15:24:16 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA16318; Mon, 29 Oct 90 15:05:18 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA16314; Mon, 29 Oct 90 15:05:16 PST Received: by bagend.eng.umd.edu (5.64/umdeng-0.4/09-20-90) id AA08558; Mon, 29 Oct 90 18:04:54 -0500 Date: Mon, 29 Oct 90 18:04:54 -0500 From: buzzard@eng.umd.edu (Sean T. Barrett) Message-Id: <9010292304.AA08558@bagend.eng.umd.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: editors etc. Status: O Who cares what language etc. the editor is written in? Points: (1) You can't use the built-in MUF editor to edit anything besides programs. (2) You can write some sort of editor in MUF to use for lots 'o things. Conclusion: If you want to do editting of non-programs in the MUF environment, you need to (have someone) write an editor. (3) You may want to have the same people using the new editor and a the MUF program editor (i.e. programmers may want to use your editor too) (4) Having to learn more than one editor syntax is a real pain. (5) It is possible to write a close simulation of the MUF editor in MUF. Conclusion: If you make an editor in MUF, and make it very like the MUF editor, it will be easier for some users. This to me sounds like "a good idea", not "a kludge", "stupid", etc. Consider some counter-points: (a) The MUF editor sucks; emulating it is unwise because more users would appreciate a more powerful/easier to use editor. I have no idea if this is true. If this point is true, then I agree, it may be not be advantageous to emulate it exactly. Err... undoubtedly there are other counter points. I wonder if some of you can restrict yourself to a reasonable logical argument like this though. I.e, say "No, I don't accept point (4)," or "I don't see how you draw that conclusion". Personal observation: I spend most of my mudding time lpmudding these days. lpmud provides a built in editor which is apparently an imitation of 'ed' in unix. I recently wrote a 170 line LPC program which simulates 90% of the functions of lpmud's ed for use by the post office and other places that take input. (Those places currently require you to just type everything in sequentially, no editting.) I discovered someone else had written another editor which probably had a cleaner command interface (it was modeless); but we agreed that standardizing with mine would make more sense since this would be a real convenience in terms of learning multiple editor syntaxes (or even forgetting which editor you were in). From tinymuck-sloggers-owner Mon Oct 29 17:24:17 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA16715; Mon, 29 Oct 90 17:02:43 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA16711; Mon, 29 Oct 90 17:02:41 PST Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA06831; Mon, 29 Oct 90 17:02:15 -0800 Date: Mon, 29 Oct 90 17:02:15 -0800 From: gminette@polyslo.CalPoly.EDU (The Sylver Dragon) Message-Id: <9010300102.AA06831@polyslo.CalPoly.EDU> To: c60b-2aj@web.berkeley.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Yellow Submarines Status: O The list editor is identical in syntax and use to the @edit muf editor with only one little thing to remember: It allows you to do a helluva lot more. The syntax for all the commands is identical on the List, Delete, Insert, Quit and Help commands. There are also, however, in the list editor, commands for Search and replace, Moveing lines, Copying lines, Altering lines (this lists the range/line you tell it to, then it deletes it/them, then it puts you in insert mode there, all in one command), you can Find all lines that have a word or phrase on them, and if while entering text, you decide you don't want to make that change after all, you ca quit from the insert mode without saving the changes. You can also read in lines from another list, or write out line to another one. In the commands that @edit has, it is identical, but @edit doesn't go far enough for us. Sthiss added in all those features to make life easier for all MUBAR programmers/builders. (BTW, the new commands use logical extentions of the syntax from the current @edit commands, so consistency is preserved.) - Tygryss - Mailed for krivers@nike.calpoly.edu (Tygryss/littlefox) From tinymuck-sloggers-owner Mon Oct 29 19:24:18 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA17038; Mon, 29 Oct 90 19:11:12 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA17032; Mon, 29 Oct 90 19:11:00 PST Received: from basser.cs.su.oz by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA10168; Tue, 30 Oct 1990 14:10:45 +1100 (from 8936547@basser.cs.su.OZ.AU) Received: by basser.cs.su.oz (upas2.3); Tue, 30 Oct 90 14:10:26 +1100 Date: Tue, 30 Oct 90 14:10:26 +1100 From: Geoffrey Michael Bailey <8936547@cs.su.oz.au> To: tinymuck-sloggers@belch.Berkeley.EDU Message-Id: <24699.657256226@mango.cs.su.oz> Subject: Re: Pink elephants and white rabbits Status: O You can write self modifying code already! Just store the program as a sequence of property lists (line1, line2, etc...) on an object. Then all you have to do is write a MUF interpreter in MUF to run these programs, which can then modify themselves. I'm sure the people writing the MUF editor in MUF would love to do this :-) ftww. From tinymuck-sloggers-owner Mon Oct 29 21:24:19 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA17240; Mon, 29 Oct 90 21:19:21 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA17236; Mon, 29 Oct 90 21:19:19 PST Received: from web-4b.Berkeley.EDU by weaver.berkeley.edu (4.0/1.33(web)) id AA09435; Mon, 29 Oct 90 21:19:17 PST Date: Mon, 29 Oct 90 21:19:17 PST From: c60b-2aj@WEB.berkeley.edu (Stinglai Ka'abi) Message-Id: <9010300519.AA09435@weaver.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Things Status: O Sorry if some of the commentary was a bit pointed; understand, though, that TinyMUCK's main problem is that it possesses no unity of form. Everything that does something interesting in muck is tacked onto something else that does something interesting, but things don't work together (or, when they do, there are a sufficiently large number of things "Working Together" that it's hard for people who don't know how to use them to learn.) If you want a software editor (and this does, indeed, seem to be the consensus) then I would advise that you make this the only editor. Doing so would bring muck that much closer to actually not being so icky. @edit, @prog, etc. would be phased out and replaced by commands in the root environment. In the ideal software setup, there are almost no built-in commands and everything is written in the extension language; this allows anyone (including users) to easily modify anything they want. [Deja vu. Sound familiar, CC?] Having an editor written in muf that coresides with an editor written into the server is just another sign of progressive code rot. Stinglai From tinymuck-sloggers-owner Mon Oct 29 21:54:19 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA17297; Mon, 29 Oct 90 21:46:22 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA17293; Mon, 29 Oct 90 21:46:19 PST Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA26928; Mon, 29 Oct 90 21:46:10 -0800 Date: Mon, 29 Oct 90 21:46:10 -0800 From: gminette@polyslo.CalPoly.EDU (The Sylver Dragon) Message-Id: <9010300546.AA26928@polyslo.CalPoly.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Pink elephants and white rabbits Status: O Geoffrey Michael Bailey <8936547@cs.su.oz.au> wrote: > >You can write self modifying code already! Just store the program as a sequence >of property lists (line1, line2, etc...) on an object. Then all you have to do >is write a MUF interpreter in MUF to run these programs, which can then modify >themselves. I'm sure the people writing the MUF editor in MUF would love to do >this :-) Yeeeaaaaahhhhhhh. Riiiiiggghhhht. As if we had no other projects for the next month. Or the next month after that in which we'd run the first program on it. ALL MONTH, ONE RUN. Suuuuurrrrrreeee. }=) - Tygryss - Mailed for krivers@nike.calpoly.edu (Tygryss/littlefox) PS: That idea about being able to read and write to program files from MUF is neat! It could be incorporated into the list editor with not too much trouble at all, but you would have to use the real @edit to compile. From tinymuck-sloggers-owner Tue Oct 30 13:54:25 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20150; Tue, 30 Oct 90 13:50:05 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA20146; Tue, 30 Oct 90 13:49:58 PST Received: from basser.cs.su.oz by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA03284; Wed, 31 Oct 1990 08:49:50 +1100 (from 8936547@basser.cs.su.OZ.AU) Received: by basser.cs.su.oz (upas2.3); Wed, 31 Oct 90 08:49:00 +1100 Date: Wed, 31 Oct 90 08:49:00 +1100 From: Geoffrey Michael Bailey <8936547@cs.su.oz.au> To: tinymuck-sloggers@belch.Berkeley.EDU Message-Id: <10509.657323340@mango.cs.su.oz> Subject: Self modifying code. Status: O Yeah, well, I didn't say it was practical ... :-) Mind you, it could be fun - do thorough time testing before hand to see how long it takes to run, and then with a little bit of experimenting and a fair bit of time you have TYPE_DAEMON implemented :-) ftww. PS: Has anyone done a TYPE_DAEMON coding yet? From tinymuck-sloggers-owner Wed Oct 31 00:24:32 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22371; Wed, 31 Oct 90 00:20:38 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA22367; Wed, 31 Oct 90 00:20:32 PST Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 31 Oct 90 08:15:37 GMT Message-Id: <9010310815.AA01178@hplb.hpl.hp.com> To: tinymuck-sloggers@belch.Berkeley.EDU Cc: me@hplb.hpl.hp.com Subject: TYPE_DAEMON ? Wassat ? Date: Wed, 31 Oct 90 08:16:29 GMT From: mjp@hplb.hpl.hp.com Status: O Hmmm. I wonder what a TYPE_DAEMON is ? Is this a discussion I missed ? I have a clock running in the MUCK I administer, herinafter known as VenueMUCK. (Before you ask, this is an internal Hewlett Packard MUCK. We have no external net access - so sorry). The clock is implemented as a cron job that pops off every minute. It runs a little script that connects to the MUCK in question, and runs a MUF program. As far as I can see, this MUF program can be anything. At the moment, it just updates our clock object (which contains all the fields from the UN*X date(1) command), but it looks like it will be expanded in the near future to run an arbitrary list of programs whoses dbrefs are stored on the clock in a p-list. A 'clock admin' looks after the p-list, and makes sure everything runs tickety-boo. The main reason for this was so that we could implement self-healing over time. I am sure it has a myriad other uses. Is this what you meant by a TYPE_DAEMON ? ---------------------------- Another announcement while I am here..... If anyone missed my posting on rec.games.mud, that well known purveyor of quality discussion, I am gradually transferring all the useful programs, and program SYSTEMS we have developed on VenueMUCK over to belch.berkeley.edu in the tinymuck/muf-examples directory. I hope they are of use to y'all out there. I also hope that they act as a stimulant for everyone to start putting their useful MUCK snippets out to the public. Think - you can save people a lot of time !! As a PS, but don't spread it around, I am prepared to answer any questions on the MUF code I put on belch, put please only people on this mailing list. I don't want to be inundated with cries from every Joe in town saying "I can't get your super-whizzo-bang program to work. Do I need to have a MUCKER bit or something ?" I am sure you know what I mean. Cheers, Mike. aka blip, as if you didn't know. From tinymuck-sloggers-owner Wed Oct 31 15:24:38 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25505; Wed, 31 Oct 90 15:12:46 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA25500; Wed, 31 Oct 90 15:12:31 PST Received: from basser.cs.su.oz by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA08929; Thu, 1 Nov 1990 10:12:10 +1100 (from 8936547@basser.cs.su.OZ.AU) Received: by basser.cs.su.oz (upas2.3); Thu, 1 Nov 90 10:11:14 +1100 Date: Thu, 1 Nov 90 10:11:14 +1100 From: Geoffrey Michael Bailey <8936547@cs.su.oz.au> To: tinymuck-sloggers@belch.Berkeley.EDU Message-Id: <19505.657414674@zeppo.cs.su.oz> Subject: TYPE_DAEMON Status: O TYPE_DAEMON is one of the flags for object types (the others are TYPE_ROOM, TYPE_PLAYER, etc.). An object of TYPE_DAEMON is almost the same as one of TYPE_PROGRAM, but it has a provision to run every so many cycles, rather than be triggered by something. Unfortunately, this is not implemented in 2.2, and I was wondering if anyone had, and if so would it be in for version 2.3? I feel it would be nicer to have an internal TYPE_DAEMON rather than a cron job set up from outside. ftww. From tinymuck-sloggers-owner Wed Oct 31 16:24:39 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25614; Wed, 31 Oct 90 16:16:28 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA25610; Wed, 31 Oct 90 16:16:25 PST Received: from sdcc13.ucsd.edu by ucsd.edu; id AA14293 sendmail 5.64/UCSD-2.1-sun via SMTP Wed, 31 Oct 90 16:16:23 -0800 for tinymuck-sloggers@belch.berkeley.edu Received: by sdcc13.UCSD.EDU (5.60/UCSDGENERIC2) id AA03172 for tinymuck-sloggers@belch.berkeley.edu; Wed, 31 Oct 90 16:17:32 PST Date: Wed, 31 Oct 90 16:17:32 PST From: rearl%sdcc13@ucsd.edu (Robert Earl) Message-Id: <9011010017.AA03172@sdcc13.UCSD.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: DAEMON Status: O hi... it's chupchup on the vax from hell, with a few words about type_daemon. i took type_daemon out first thing after releasing 2.2, and should have done it earlier, as the struct was the largest one of any type object, and just tended to waste space for something that has remained unimplemented for so long. as a very few people have demonstrated, a lot of neat things can be done with combinations of muf programs and very simple drone robots that may do either of a) spit back everything they hear from the muck verbatim or b) queue commands to be issued at timed intervals. see bob's cronos code on belch.berkeley.edu, conductor (not running anymore) on mbongomuck, chronos on pegasus, and various others i have just heard of... anyway, it's my opinion that things that can be done by clients, thus distributing some of the load away from the server, should be kept that way. i have heard various suggestions about multi-threading muf program execution in tinymuck, i'm pretty interested in it but i know it's going to take a lot of work and i have a lot of other ideas that won't either involve nor require that to be done. -- chupchup ps i apologize for all the downtime chupmuck has had lately; the database is still intact in a 2.2 dump format, i've been having a lot of trouble loading it up under 2.3isms for some unknown reasons :) i'm willing to send bits of code out (gasp! shock!) to someone who thinks they can lend me a hand, you'll need a copy of a 2.2 database and a lot of patience for hunting down a very nasty memory munger... From tinymuck-sloggers-owner Mon Nov 19 14:15:29 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA05664; Mon, 19 Nov 90 13:57:29 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA05660; Mon, 19 Nov 90 13:57:28 PST Received: by grunt.berkeley.edu (4.1/1.30) id AA04409; Mon, 19 Nov 90 13:10:22 PST Date: Mon, 19 Nov 90 13:10:22 PST From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9011192110.AA04409@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: patch for look.c Status: O Here's a small patch for look.c. Fixes a fatal bug that allowed you to crash the server by setting a field to @548623 or another suitably out-of-database number. -- ChupChup *** look.c.old Sat Oct 6 19:04:57 1990 --- look.c Mon Nov 19 13:52:55 1990 *************** *** 117,123 **** for (; *p && !isspace(*p); p++) ; if (*p) p++; ! if ((Typeof(i) != TYPE_PROGRAM) || DBFETCH(player)->sp.player.run) { if (*p) notify (player, p); else notify(player, "You see nothing special."); } else { --- 117,124 ---- for (; *p && !isspace(*p); p++) ; if (*p) p++; ! if (i < 0 || i >= db_top ! || (Typeof(i) != TYPE_PROGRAM) || DBFETCH(player)->sp.player.run) { if (*p) notify (player, p); else notify(player, "You see nothing special."); } else { From tinymuck-sloggers-owner Sat Nov 24 21:16:54 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27896; Sat, 24 Nov 90 21:03:44 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA27892; Sat, 24 Nov 90 21:03:43 PST Received: by grunt.berkeley.edu (4.1/1.30) id AA08007; Sat, 24 Nov 90 21:03:41 PST Date: Sat, 24 Nov 90 21:03:41 PST From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9011250503.AA08007@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: @boot bug Status: O well, looks like @boot is back to haunt us still. mbongo and i finally found a bug that's been there from the start while working on 2.2, that one caused random crashes upon @booting someone and was really nasty to trace. there have been reports from a few sites that it now consistently crashes when you @boot yourself. well, looking at it again i realized that the whole *idea* of @boot is not very good for the health of the server, because @boot frees things from _within_the_command_loop_. a socket shutdown really can't be handled correctly while processing someone's command, and it becomes apparent when it's the same person. anyway, here's the fix. kinda icky, a hack to let the outer loop know if the person who just did this command is still connected. but it works, and it's long overdue. -- chupchup p.s. i hope the line #s are okay, this is from 3.0 source. *** /tmp/,RCSt1a27870 Sat Nov 24 20:52:01 1990 --- interface.c Sat Nov 24 20:05:08 1990 *************** *** 742,747 **** --- 742,748 ---- queue_string (d, d->output_suffix); queue_write (d, "\r\n", 2); } + return (d->connected); } else { check_connect (d, command); } From tinymuck-sloggers-owner Sun Nov 25 20:17:04 1990 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01400; Sun, 25 Nov 90 19:54:16 PST Received: by belch.Berkeley.EDU (5.57/1.41) id AA01396; Sun, 25 Nov 90 19:54:14 PST Received: by grunt.berkeley.edu (4.1/1.30) id AA08176; Sun, 25 Nov 90 19:54:13 PST Date: Sun, 25 Nov 90 19:54:13 PST From: rearl@grunt.berkeley.edu (ChupChup) Message-Id: <9011260354.AA08176@grunt.berkeley.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: hold it! Status: O never mind about the patch i sent out for the interface. i looked again and realized how hopeless it is to check that pointer in case it's been freed by an @boot. it's all freed and invalidated and you can get in big trouble by looking there for something. so instead what should be done is just make sure you cannot boot yourself. and remind me not to touch the interface again. -- chupchup From tinymuck-sloggers-owner Thu Feb 14 10:53:15 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11368; Thu, 14 Feb 91 10:29:59 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11364; Thu, 14 Feb 91 10:29:57 -0800 Received: by cgl.ucsf.EDU (5.64/GSC4.19) id AA23025 for tinymuck-sloggers@belch.berkeley.edu; Thu, 14 Feb 91 10:29:52 -0800 Received: from noe.UUCP by hop.toad.com id AA05720; Thu, 14 Feb 91 08:27:08 PST Received: by noe.uucp (3.2/KG6KF's Internet<->AMPRnet gateway) id AA00211; Thu, 14 Feb 91 04:42:27 PST Date: Thu, 14 Feb 91 04:42:27 PST From: noe.UUCP!marc@cgl.ucsf.EDU (Marc de Groot - KG6KF) Message-Id: <9102141242.AA00211@noe.uucp> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Looking for info on MUDs.. Status: O Hello. I'm looking for info on MUDs. I was given the name of belch.berkeley.edu as a place to FTP, and having found these mailing lists, I'm asking for info on them. In particular: What is the difference between mud, muck, and mush? I saw Forth source code patches for the tinyMuck code (I looked in the mailing list archive). Is the system written partly or wholly in Forth? Are the other systems written in Forth? Can I get a list of running games? Thanks in advance.. ^M Marc de Groot marc@toaster.sfsu.edu From tinymuck-sloggers-owner Thu Feb 14 11:17:37 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11445; Thu, 14 Feb 91 10:58:08 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11439; Thu, 14 Feb 91 10:57:44 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 14 Feb 91 18:55:41 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA03457; Thu, 14 Feb 91 18:49:50 gmt Message-Id: <9102141849.AA03457@prudence.hpl.hp.com> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: When you move, do your things come with you ?? Date: Thu, 14 Feb 91 18:49:49 GMT From: Mike Prudence Status: O Evenin' all, Here's a little food for some thought and comment. A mere snippet to enliven your day. Scenario : Imagine the scene. You are carrying a hyper-radioactive isotope. This is so powerful, that it causes the room you're in to glow. You're pretty cool about it, though. You have a radiation suit on, so you don't really care. Then you decide to visit the local purveyor of fine cheese to spice his shop up a bit. You leave your house, which continues to glow, and you move into the Cheese Shoppe. Funnily enough, the Cheese Shoppe doesn't glow. How it works : - the isotope you are carrying has some properties on it that define its level of radioactivity. - rooms also have a property that tells you what the radiation is, and a program is linked to the @desc for the room, so an appropriate message can be printed, depending on how hot the room is. Fine and dandy, except you need a way to model someone coming into the room with a hot item, and making the room glow. Similarly, when someone leaves, the effect should go with the object they are carrying. Put more generally, when you move from room to room, the possessions you are carrying need to have their influence withdrawn from the room you are leaving, and exert it on the room you are entering. Food for thought : After a little bit of brainwork, I came up with the following simple scheme. Put a couple of properties on objects - call them trigger-enter and trigger-exit. These have some MUF program numbers in them, for example trigger-enter: #1234 trigger-enter: #4567 When an object is moved from one room to another, by being carried, the 'trigger-exit' program is called just before the bearer is 'moveto'd out of the room. The 'trigger-enter' program is called just after s/he arrives in the new room, before the @desc is printed. This just about solves the problem. The only fly in the ointment is the dratted 'moveto' primitive. If an object is 'moveto'd from within a program, there is no way to execute any 'trigger' programs attached to the object. Solution is for each program doing a moveto to check any objects it is transferring. This is pretty damn messy, but at least you've been warned. I've implemented this scheme - it isn't too tricky. It seems to work. I've written a torch implementation with it that seems to work. I think this is an issue that needs to be addressed. How do we model the movement of objects in and out of rooms ? Comments ? Cheers, Mike/blip. From tinymuck-sloggers-owner Tue Mar 12 01:01:27 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07383; Tue, 12 Mar 91 00:39:50 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07379; Tue, 12 Mar 91 00:39:49 -0800 Received: by cory.Berkeley.EDU (5.63/1.42) id AA19904; Tue, 12 Mar 91 00:39:15 -0800 Date: Tue, 12 Mar 91 00:39:15 -0800 From: orleans@cory.Berkeley.EDU (ORLEANS DOUGLAS KEVIN) Message-Id: <9103120839.AA19904@cory.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Hello Status: O Has this mailing list been dead for a while, or am I just not on it anymore? Is anyone out there actively hacking TinyMuck code? It seems like the "official" version (i.e. the one chupchup is in charge of) won't be changed for a long time, if at all. (Correct me if I'm wrong... please!) Anyway, I would like to see a new version of TinyMuck (or Muck, as I think it should be officially called now) sometime soon. I have a lot of ideas for neat things to add, as I'm sure lots of you do too. To begin with, chupchup, could you tell us what you had already done, and what you had planned to do? (e.g. making any object @editable, moving @desc fields and such into p-lists, etc.) Doug Orleans aka WhiteRabbit aka orleans@cory.Berkeley.Edu From tinymuck-sloggers-owner Tue Mar 12 03:31:28 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07515; Tue, 12 Mar 91 03:03:52 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07511; Tue, 12 Mar 91 03:03:45 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 12 Mar 91 11:02:24 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA07949; Tue, 12 Mar 91 11:03:02 gmt Message-Id: <9103121103.AA07949@prudence.hpl.hp.com> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Hello ?? Oh, hello. Date: Tue, 12 Mar 91 11:03:02 GMT From: Mike Prudence Status: O Howdy fellow Sloggers > Has this mailing list been dead for a while, or am I just not on it anymore? Well, I ain't seen no traffic. I have come to the conclusion that most of the real discussion takes place on one MUD or another. Or have we just run out of things to say ? > Is anyone out there actively hacking TinyMuck code? It seems like the > "official" version (i.e. the one chupchup is in charge of) won't be changed > for a long time, if at all. (Correct me if I'm wrong... please!) I've been having a lot of Deep Thought about the things that are *missing* from TinyMUCK, and putting together some solutions. My main interest is actually in coding MUF - I find server hacking a bit on the tedious side - so my solutions have tended to involve very little or no C-code. I'll summarise the points below :- - a notion of time. I have corrected this with the Cronos robot, and a couple of MUF programs to help out. - adding a 'trigger' property to an object (containing a program dbref). The trigger is called whenever something happens in the room (ie, something gets printed out to a player's terminal) with the triggering string as an argument. This makes it easy to do Non Player Characters (NPCs) and a more intuitive interface to some other programs. eg a clock that gives the time if you ask it. - 'exit' and 'entry' properties attached to objects. These contain the dbrefs of programs that are called when an object enters or leaves a room. I put this in to allow me to model a torch, with torch light moving with the person carrying the torch. The system is not perfect - in particular, the 'one program at a time' structure of TinyMUCK means that if an object is MOVETOd about, it's entry and exit triggers are not called. But what the hell :) - addition of regular expression and simple string matching primitives, along with 'toupper', 'tolower' and 'setlink'. The latter I added to allow 'installation' programs that setup an object to use other programs. These are *vital* for complicated systems, and avoid the hapless user having to set up 10e99 properties to use the WizzBang Gizmo system widget. My main thrust has been towards producing some MUF programs to provide facilities *useful* for writing adventures with. I have produced a general descriptions program, along the lines of the Crossroads effort, which has certainly pointed the way forward in description technology. I am putting the finishing touches to a system for modelling light and dark in rooms. Yes, it is complicated, but with the right blend of helpful installation and configuration programs, it becomes almost trivial, and can add a lot to an adventure. > Anyway, I would like to see a new version of TinyMuck (or Muck, as I think > it should be officially called now) sometime soon. I have a lot of ideas > for neat things to add, as I'm sure lots of you do too. > To begin with, chupchup, could you tell us what you had already done, and > what you had planned to do? (e.g. making any object @editable, moving > @desc fields and such into p-lists, etc.) I would like to see a sort of 'best of' release. If TinyMUCK 3.0 is going to be delayed for a long time, I think it is up to us to stop the divergence from the 'standard' 2.2 MUCK that is inevitable. We should be pooling our good ideas, and putting together a TinyMUCK 2.2 PLUS, if you like. I imagine that a lot of work has already been put in by a few people. It shouldn't be too difficult to merge in changes from several different people, as I imagine they are in different areas. Of course, finding a volunteer to do the merging is another thing. I also suspect that the majority of people who have added to the basic server would be unwilling to share their code. From my efforts in trying to get MUF code exchange going, I get the impression that the concept of sharing with the rest of the world doesn't fit in with the average MUD hackers mindset. I could be wrong - if so, I'd love to be proven wrong. One thing I would say, though, is that this TinyMUCK 2.2 PLUS should have decent documentation with it. I am thoroughly sick of the general attitude of 'code it and release it', with no thought for writing down just what your super whizzy hacked version actually does. If we are going to take ourselves seriously, we have to treat TinyMUCK as more than just a part time hack. Anyway, sorry for ranting :) To summarise, I think it would be a good idea to pool our hacks and release it, if only to try and bring the working MUCKs back into some sort of standard fold. In my opinion, the difference between MUCKs should be the database, not the server. On a related note, is there ever going to be any hope of putting together a list of 'standard' macros ?? Or am I living on the wrong planet for that :) Finally, I'd be more than willing to make my code available. I am waiting to hear from the Crossroads people (Hi Tygryss !) regarding their general description program, but I feel that some sort of freely available solution to this problem should be released soon. It is damn useful. It's long past time we got back to writing adventures, folks. Cheers, Mike mjp@hplb.hpl.hp.com "Beware. Lettuce ahead" From tinymuck-sloggers-owner Tue Mar 12 12:31:31 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08194; Tue, 12 Mar 91 12:05:39 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08190; Tue, 12 Mar 91 12:05:37 -0800 Message-Id: <9103122005.AA08190@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Tue, 12 Mar 91 15:05:33 -0500 Date: Tue, 12 Mar 91 15:05:31 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Hello ?? Oh, hello. Status: O One interesting thing that has been done to Muck is Mage, done mostly by Koosh I think. An attempt to combine Mush and Muck. Notwithstanding the common conception that Koosh is a d00f (for instance, he said that anyone who runs a Mage has to give him an M bit. Blecch.), or the bugginess of Mage (I won't say "very", but I'll say "buggy enough"), or certain dubious "improvements", I think that there is some merit to the idea. One can program on two different levels. (Analogy: Mush == shell, MUF == C) Mage, mostly via Mush, already has time, "trigger" properties (listen and ahear), the equivalent of exit/entry properties, and a string matching primitive. You can use TRIGOBJ to make objects do things, so you can link, dig, @create, etc.... Also, people already know Mush, so this should be a bit easier for lots of users to comprehend, and either Mush or Muck items could be ported over. I really _would_ like to see someone do Mage _right_. (I'd probably do it myself if I had the time, and a site....) Mage is on Belch, though I haven't actually downloaded the source to check that it's all there. From tinymuck-sloggers-owner Wed Mar 13 12:19:57 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA00232; Wed, 13 Mar 91 11:51:26 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA00228; Wed, 13 Mar 91 11:51:22 -0800 Received: by cory.Berkeley.EDU (5.63/1.42) id AA25202; Wed, 13 Mar 91 01:14:42 -0800 Date: Wed, 13 Mar 91 01:14:42 -0800 From: orleans@cory.Berkeley.EDU (ORLEANS DOUGLAS KEVIN) Message-Id: <9103130914.AA25202@cory.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Muck wish list Status: O > I've been having a lot of Deep Thought about the things that are > *missing* from TinyMUCK, and putting together some solutions. My main > interest is actually in coding MUF - I find server hacking a bit on > the tedious side - so my solutions have tended to involve very little > or no C-code. I agree that most things should be done in MUF, but I think the Muck server is incomplete and it needs a few more things before we can really start writing MUF code. Maybe that isn't how I should think of it. What it doesn't need is more features, like more primitives and more @commands and things like that. What it needs is to be more "integrated", to borrow a term from Lachesis (the one who wrote MUF in the first place). To me, that means having the server written as much as possible in MUF (sort of the way emacs is written in elisp). This would accomplish two things: 1) The programming environment would be more "seamless", and less of a hack (which is what it is now). 2) There would be standard MUF code distributed with Muck. I remember someone making an analogy to the C library functions distributed with Unix. This would help standardize MUF programming. From what I've seen of MOO, it has this sort of idea, with the matcher being Status: O a subsystem of the parser, etc. The main difference of Muck is that it uses a Forth-derivative, instead of a quasi-C derivative. (Personally, I'd like to make it more like real Forth, with interpreted and compiled modes, a real dictionary structure, etc., but this would probably take more effort than it's worth.) Anyway, there are some other issues that need to be thought about: the reason we don't have any looping constructs in MUF is because each program takes up the whole server; security issues, eg. a tiered system of accesses to certain primitives; and better resolution of multiple-inheritance, ie. actions with the same name on different objects in a room. Another thing that might help would be a complete list of primitives (and I mean real primitives as in those words that can't be expressed in terms of other words) that we think should be in the language. > I really _would_ like to see someone do Mage _right_. (I'd probably do it > myself if I had the time, and a site....) Why is it that those of us who have all these neat ideas about how to do it "_right_" don't have the resources? I'm not being sarcastic, this is a fact. Sorry for rambling so much, but you aren't English professors (at least not my English professors), so I'm not worried. Doug Orleans -- WhiteRabbit@Mbongo From tinymuck-sloggers-owner Wed Mar 13 12:48:55 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01589; Wed, 13 Mar 91 11:54:36 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01585; Wed, 13 Mar 91 11:54:27 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 13 Mar 91 17:08:06 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA00361; Wed, 13 Mar 91 17:08:31 gmt Message-Id: <9103131708.AA00361@prudence.hpl.hp.com> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Further Hacked MUCKs - TinyMAGE Date: Wed, 13 Mar 91 17:08:30 GMT From: Mike Prudence Status: RO Hi all, Ah yes - TinyMAGE. This is a good idea done bad. Readers of this list may remember my last rant when I found TinyMAGE lurking on belch. Unless it has changed since then, MAGE was totally undocumented, so that the interested hacker had *no way* to find out what made MAGE different, apart from reading the source. If anyone can convince us that this is a good situation, feel free. In fact, Ken Arromdee gave me more information about MAGE in his last message than I have had from the author. I thought it just had scheduling put in for timed execution and stuff like that. That'll teach me to skim read C code :) Anyways, sure - let's take the ideas from other types of MUD. MUSH seems to be fairly competent, although I wonder about putting two levels of language interpretation into a single MUD. I've said it before and I'll say it again : we (the MUF programmers) have done very little to help your average Joe MUD-player actually create interesting, interactive areas. The Crossroads effort, from what I've read, is about the nearest that the world has come to a supported environment for the builder who doesn't know a pop from rot. In fact, I seem to remember reading something about MIST, which seemed to be their verions of the MUSH programming idea. Anyone from Crossroads care to comment on that one ? Having thought about all this a bit more, I have two proposals that I would like to see some serious "yea" or "nea" activity on, please. Proposal One: ------------- [This works on the assumption that ChupChup's TinyMUCK 3.0 (or 2.3) is a long time away, because Chup is too busy doing other things] Let all those who have added stuff into TinyMUCK server code submit their changes to some central agency (and it could be me, although I would prefer to pan this out to a small team. I am pretty overloaded with work at the moment). This central agency will consider the submissions, eliminate or merge those that are duplicates, and produce an enhanced TinyMUCK 2.2 (maybe even call it 2.3) for general release the same way that ChupChup does. This release would also include some up to date documentation, (both MUCK and MUF) as well as some items from Proposal 2. Proposal Two. ------------- [This one is long past due, and I feel very strongly about it, so be warned :] Let all those who have written MUF building tools, or MUF systems for special functions submit them to some central agency (possibly the same as above, probably different). Duplicate submissions will be discarded, or merged, as appropriate. Finished MUF program(s) will then be released, in the same way as above, complete with documentation, and any other dependent information. This process should also be carried out for MUF Macros, to allow MUF programs released in this way to use macros from the 'standard' library. Again, I am assuming the Central Agency will actually be a team of people, and I would prefer to see people with the same sort of MUF code working out any merging. One thing that we might like to do is put a restrictive copyright notice into any such code - if you use this code, and feel it needs hacking, ask the author to do it. Do not use hacked versions of this code. You have read and execute permissions *ONLY* on this code. Now, ladies and gentlemen. Comments, please. And descriptions of submissions, as well. And volunteers for the central agencies. C'mon - it don't take too much effort, and in the end we will all benefit. Cheers, Mike/blip mjp@hplb.hpl.hp.com "Beware. Lettuce ahead" From tinymuck-sloggers-owner Wed Mar 13 12:49:58 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01583; Wed, 13 Mar 91 11:54:19 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01579; Wed, 13 Mar 91 11:53:52 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 13 Mar 91 19:12:45 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA00509; Wed, 13 Mar 91 19:13:11 gmt Message-Id: <9103131913.AA00509@prudence.hpl.hp.com> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Hello ?? Oh, hello. Date: Wed, 13 Mar 91 19:13:10 GMT From: Mike Prudence Status: RO Okay, Here are the changes I have made to TinyMUCK. Primitives. ----------- dbtop ( -- n) - returns the size of the database connect? (d -- n) - returns the number of times that the player with dbref 'd' is connected (ie 0 => not connected, >1 => connected) toupper (s -- s) tolower (s -- s) - convert string to all upper/lower case logon (d -- s) - returns the time that the player with dbref 'd' logged on. String is formatted as year month date day hour minute idle (d -- s) - returns the player idle time. String is formatted as days hours minutes seconds smatch (s1 s2 -- s n) - simple string matching. Matches pattern s2 in string s1. The only substitution supported is a "*" meaning any character. If a match is found, n=1, and s is the part of s1 that matched the last '*' in s2. Otherwise, n=0 and s is undefined. setlink (d1 d2 -- ) - links d1 to d2. If d2 is #-1, then d1 is unlinked. regmatch (s1 s2 s3 -- s4 n) - full regular expression matching. s1 is the input string. s2 is the RE. s3 is the substitution string. If s1 matches s2, n=1 and s4 is set to s3, with any tagged subexpression substitutions performed. Otherwise, n=0 and s4 is undefined. Taken from the regexp stuff in the Cronos robot code. Server Modifications -------------------- - on player login, if an action called 'pending' is found on the player, the action is triggered - usually to run a MUF program. - any strings sent to the players in a room are also sent to all the objects in a room. If any object has a property called 'trigger' set to a valid MUF program number, that program is called, with the text being sent as an argument on the stack. This allows easy Non Player Characters and stuff. - when an object is moved from one room to another, normally as the result of being carried by a player, the object is checkec to see if it has the properties 'trigger-entry' and 'trigger-exit' defined to valid MUF program numbers. If so, then the 'trigger-exit' program is called as the player leaves the room. 'trigger-entry' is called as the player enters the room on the other end of the link. This is used to carry torch light about, amongst other things. MUF Program Systems ------------------- - general descriptions program - property list standard, with commands to set/delete/list property lists. Macros to pick an entry from a plist, either by index or at random, to print out two consecutive plist entries as a succ and osucc message. - Cronos robot for timed execution using a .schedule macro and MUF proxy triggering program. - Program to list the obvious exits in a room. - doorbells, 'come-in' code and directories for apartment levels. - tube transport system for moving between arbitrary destinations - Banking system based on ATM machines, with EFT transactions for merchants. - [in development] standard for light and dark, with code for describing the light levels in a room, push/toggle switches, dimmers and torches. Fully customizable. - [in development] standard for handling exits that are made visible/accessible as the result of general actions in a room. - Clock - a cron daemon connects once a minute and updates a clock object with the stuff avalable from the date(1) command. Also macros to extract this information. This is also available from the general descriptions program for the non-MUF programmer. - [in development] fully customizable vehicle code, including support for multi-room vehicles, radar devices, loudhailers, cocktail bar. Let's keep this ball rolling, guys and gals. Cheers, Mike mjp@hplb.hpl.hp.com "Beware. Lettuce ahead" From tinymuck-sloggers-owner Wed Mar 13 14:49:58 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02213; Wed, 13 Mar 91 14:29:05 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02209; Wed, 13 Mar 91 14:29:03 -0800 Message-Id: <9103132229.AA02209@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Wed, 13 Mar 91 17:28:59 -0500 Date: Wed, 13 Mar 91 17:28:57 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Hello ?? Oh, hello.Hmm. Status: RO Mage has "smatch" but named wmatch; it should br probably be named wmatch for "compatibility". Similarly, I'm sure some mucks already have connect? under various names; we should get the names consistent. We don't want an index/strchr confusion here. Some more suggestions: (Unlike yours, these are all off the top of my head, and I've implemented none. Still, ideas are ideas. Names are, of course, pulled from thin air.) Timestamps should be a compile-time option. None of this everyone-hacks-in- timestamps-on-their-own business. last (dbref -- str): returns the "last" field of something. setlast (dbref str --): sets it (requires wizard permission) date (-- str): returns the time and date in the same format as is default for date(1). Currently there is no way to get the day, month, or year. nextprop (str -- str): Given the name of a property, returns the next property in an object's property list. (This will have to do it by searching through the object's entire list of properties. Those are the breaks.) Requires wizard permission. checklock (dbref dbref -- int): checks to see if the lock on the first dbref allows the second one through or not. This assumes no changes to the server to add locks in places where they can't already be now. (What to do if the lock has a program in it? Hmm....) It should be possible to define macroes for the duration of a single program. I suggest allowing "def" lines in programs which behave like "def" lines typed in the editor, but affect only that one program. (Probably outside functions only, just like "var" has to be outside functions). "version" command. (I know it can be done with a global.) Allow locking to FALSE. me&!me is just silly. Furthermore, if an object in a lock is recycled, instead of leaving the other thing locked to garbage, lock it to FALSE automatically. You have to search the whole DB for this? Well, recycling already has to do that. (If you want to get really smart, you could always shorten expressions like a|FALSE to just a, but that's a bit extreme.) We could add TRUE, except 1) there's no need for it, and 2) TRUE would probably end up being #-1, which is counterintuitive. Get a working extract for Muck. Yes, programs will have to have any db references manually changed. So be it. Bugfixes: Programs which are W should be allowed to call any program. Currently the caller has to set the callee L before calling and back after returning, thus leaving the L around if the callee crashes. Teleporting into a room with a @succ containing a program without parameters should not give "You see nothing special." for the succ. The infamous %n bug. Giving an object a program as a @drop should suppress the standard @odrop message. (No, having the program _set_ the @odrop won't work. What if, for instance, the program produces two lines of text? Or no lines?) From tinymuck-sloggers-owner Wed Mar 13 15:49:59 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02339; Wed, 13 Mar 91 15:24:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02335; Wed, 13 Mar 91 15:24:29 -0800 Received: by enet-gw.pa.dec.com; id AA18244; Wed, 13 Mar 91 15:24:25 -0800 Message-Id: <9103132324.AA18244@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Wed, 13 Mar 91 15:24:26 PST Date: Wed, 13 Mar 91 15:24:26 PST From: This message sent with 100% recycled bits 13-Mar-1991 1814 To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Additions to the MUF compiler Status: RO I've made the following words: DATE -- (... day month year) UNPARSE_OBJECT (dbref) -- (s) UID -- (dbref) THIS_PROGRAM -- (dbref) I've also done two access checks for the security stuff I've implemented on The Dreamtime, checking a player's access against some object. I've been working on a LOCK? word to evaluate a lock. The tricky part here is that you have to be careful when you evaluate a lock that executes a program. I've not coded it yet, but I think that can easily be done if the boolean expression evaluator saves the currently executing MUF execution frame, executes the lock, and then restores it. I've also been planning SETLINK and some of the other suggested. I've specifically said, though, that I am *not* making words to search the property lists. I think that it's a feature that you can't go fishing for properties. Thanks for your ideas. Jon From tinymuck-sloggers-owner Wed Mar 13 16:07:05 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02357; Wed, 13 Mar 91 15:28:15 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02353; Wed, 13 Mar 91 15:28:13 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01856; Wed, 13 Mar 91 15:26:27 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03075; Wed, 13 Mar 91 15:26:22 PST Date: Wed, 13 Mar 91 15:26:22 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9103132326.AA03075@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Mike Prudence's message of Wed, 13 Mar 91 19:13:10 GMT <9103131913.AA00509@prudence.hpl.hp.com> Subject: Hello ?? Oh, hello. Status: RO Here's my opinions on blip's primitives and mods. I'd love to see a "Best-of" TinyMUCK release, especially with primitives for building/linking/destroying objects, because I left those out of 2.2 so I could get them right in a later release. Oh, and I have some ideas and questions for all of you, but I'll leave that for the next message. I don't have the resources to work on MUCK right now, but I haven't given up, and I'd like to help out as much as I can with whoever would want to put this release together. | Primitives. | ----------- | | dbtop ( -- n) - returns the size of the database This is a good one. I've seen a few MUCKs put this in the same way. (Maybe `n' should be type `dbref'? That's how it is in the code...) | connect? (d -- n) - returns the number of times that the | player with dbref 'd' is connected | (ie 0 => not connected, >1 => connected) Okay, Crossroads put this one in, I had it in my 3.0 code, tho we both called it "awake?". Dunno if Xroads' returned a meaningful number, maybe just 1 or 0. We also had one called "online" that returned a list "d1 d2 .. n" of all players logged on. | toupper (s -- s) | tolower (s -- s) - convert string to all upper/lower case Neat, especially because SUBST and INSTR are case-sensitive. | logon (d -- s) - returns the time that the player with dbref 'd' | logged on. String is formatted as | | year month date day hour minute | | idle (d -- s) - returns the player idle time. String is | formatted as | | days hours minutes seconds Welllllll, I'd rather go with ALL time primitives returning an INTEGER type, and have the standard ctime primitives to convert it out, instead of trying to parse that junk if you wanted to compare two times. | smatch (s1 s2 -- s n) - simple string matching. Matches pattern | s2 in string s1. The only substitution | supported is a "*" meaning any character. | If a match is found, n=1, and s is the | part of s1 that matched the last '*' in s2. | Otherwise, n=0 and s is undefined. Why have this, if you can do it with real regexps already? Globbing: Just Say No. | setlink (d1 d2 -- ) - links d1 to d2. If d2 is #-1, | then d1 is unlinked. Sigh. This won't let you link to >1 thing? That's completely ignoring the better linking capabilities of TinyMUCK. Of course, I did that with GETLINK, because returning one of those lists on the stack was going to be too unwieldy for most peoples' needs. MUF NEEDS REAL LISTS -- or a way to implement them smoothly and uniformly from the language itself, but I chose the first and put in list primitives for 3.0. | regmatch (s1 s2 s3 -- s4 n) - full regular expression matching. | s1 is the input string. s2 is the RE. | s3 is the substitution string. If s1 | matches s2, n=1 and s4 is set to s3, with | any tagged subexpression substitutions | performed. Otherwise, n=0 and s4 is | undefined. Taken from the regexp stuff | in the Cronos robot code. This is good, I had regexp stuff in MUF for a long time but I had a regexp type, which you could fiddle around on the stack and maybe reuse it many times, which could be a good speed gain over compiling from a string each time. Is this Henry Spencer's library? I think that's what bob used anyway. My interface looked a lot different too; it's hard to get a good one that wouldn't be too unwieldy (see above :) | Server Modifications | -------------------- | | - on player login, if an action called 'pending' is found | on the player, the action is triggered - usually to run | a MUF program. I had hooks in for actions named "connect" and "disconnect", but there were lotsa problems with them, first of all: you just check the player? I thought it useful for public areas to have a "disconnect" exit that'd send you home or whatever, instead of implementing one of those stooopid "DARK player" or whatever mods in the server. | - any strings sent to the players in a room are also sent to all | the objects in a room. If any object has a property called | 'trigger' set to a valid MUF program number, that program is | called, with the text being sent as an argument on the stack. | This allows easy Non Player Characters and stuff. This is gross, why have the server in charge of sending "strings" to "objects" and looking for programs on them? Can I ask what happens when an infinite loop occurs? Much better to have the extension language in charge of dispatching all output, and from there you can check for programs or whatever on objects. Automatically re-entrant and protected from server loops, and more extensible. | - when an object is moved from one room to another, normally as | the result of being carried by a player, the object is checkec | to see if it has the properties 'trigger-entry' and 'trigger-exit' | defined to valid MUF program numbers. If so, then the | 'trigger-exit' program is called as the player leaves the room. | 'trigger-entry' is called as the player enters the room on the | other end of the link. This is used to carry torch light about, | amongst other things. Once again, I'd like to see this handled by MUF and not by a few special cases in the server. I'm not saying that's a solution for now, but better to make fundamental changes in how programmers can use MUF than to fiddle with a few things and need to do MORE later. This is what's happened to MUSH, where if you need something you just throw a new flag at it. --chupchup From tinymuck-sloggers-owner Wed Mar 13 23:20:02 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06258; Wed, 13 Mar 91 23:00:18 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06254; Wed, 13 Mar 91 23:00:15 -0800 Received: by watcgl.waterloo.edu id ; Thu, 14 Mar 91 02:00:07 EST Date: Thu, 14 Mar 91 02:00:07 EST From: Stephen White Message-Id: <9103140700.AA06724@watcgl.waterloo.edu> To: arromdee@server.cs.jhu.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Hello ?? Oh, hello.Hmm. Status: RO ken arromdee sez: > Allow locking to FALSE. me&!me is just silly. actually, locking to #0 works also (assuming that the object/action won't end up in room #0). i've always thought that me&!me was a bit inefficient. i do agree that FALSE should be allowed, though. i made provision for it in the tinymud compatibility database for moo. -- stephen From tinymuck-sloggers-owner Wed Mar 13 23:47:44 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06264; Wed, 13 Mar 91 23:06:52 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06260; Wed, 13 Mar 91 23:06:50 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03688; Wed, 13 Mar 91 23:05:01 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA00992; Wed, 13 Mar 91 23:04:39 PST Date: Wed, 13 Mar 91 23:04:39 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9103140704.AA00992@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: arromdee@server.cs.jhu.edu's message of Wed, 13 Mar 91 17:28:57 -0500 <9103132229.AA02209@belch.Berkeley.EDU> Subject: Primitives (Was Re: Hello ?? Oh, hello.Hmm.) Status: RO | Similarly, I'm sure some mucks already have connect? under | various names; we should get the names consistent. We don't want an index/strchr | confusion here. Agreed. | Timestamps should be a compile-time option. None of this everyone-hacks-in- | timestamps-on-their-own business. Okay, but a big problem is deciding what to stamp and when to stamp it. When I put fuses in Mbongo, I changed the criteria for stamping players, at least, so they were stamped when they typed a command and not when they logged on. That's a pretty minor change, but it's harder to decide, say, when an object or a room gets stamped-- when you pick it up? When you look at it? ??? | last (dbref -- str): returns the "last" field of something. Okay. Once again, why a string? I'd rather convert it into a ctime string later. | setlast (dbref str --): sets it (requires wizard permission) I don't get it. If anything, you could provide a "stamp" primitive like the UNIX touch(1) command, then you could basically let anyone who controls an object stamp the thing. | nextprop (str -- str): Given the name of a property, returns the next | property in an object's property list. (This will have to do it by | searching through the object's entire list of properties. Those are | the breaks.) Requires wizard permission. This, like the next primitive, is just a kludge to get around the fact that you don't have real lists in MUF :( Much better if you could return properties as a list of lists. And why wizard permission? | checklock (dbref dbref -- int): checks to see if the lock on the first | dbref allows the second one through or not. This assumes no changes | to the server to add locks in places where they can't already be now. | (What to do if the lock has a program in it? Hmm....) No! This is a prime example of how MUF isn't well integrated yet, if it was you could do locks written in MUF itself. I had boolean expression types in 3.0 but I always felt uneasy about it, and OliverJones proved that you could provide the same level of parsing in MUF as boolexp.c does currently. | It should be possible to define macroes for the duration of a single program. | I suggest allowing "def" lines in programs which behave like "def" | lines typed in the editor, but affect only that one program. (Probably | outside functions only, just like "var" has to be outside functions). Hmm. This sounds like a Good Idea, and is pretty easy to do. Another thing that some people have really wanted is personal macro libraries, so they can define their own things that wouldn't otherwise be useful to everyone on the MUCK; but things that are used in their own programs a lot. But this is harder and would mean more disk/memory... | Allow locking to FALSE. me&!me is just silly. Furthermore, if an object | in a lock is recycled, instead of leaving the other thing locked to | garbage, lock it to FALSE automatically. You have to search the whole DB | for this? Well, recycling already has to do that. Well, you have to *parse* all the boolean locks to do this. Possible, but a pain, too consuming for any good it could do, and it doesn't hurt anything to be locked to garbage. | Get a working extract for Muck. Yes, programs will have to have any db | references manually changed. So be it. Hear hear. Also, I heard there was a bug in the merge program that involved not updating parent rooms correctly; does anyone have a fix for it? I'll go ahead and apply it to the distribution on belch if I get one, thanx. | Bugfixes: | Programs which are W should be allowed to call any program. They can't? Oh :( | Teleporting into a room with a @succ containing a program without | parameters should not give "You see nothing special." for the succ. Well, it's not possible to tell what wanted to trigger the program at that point, and I thot it was better than spitting out an error message, and much better than not printing anything. | The infamous %n bug. (That's the %N bug) tolower() and toupper() are braindead. Just make the call to toupper() in stringutil.c a call to an UPCASE macro like the DOWNCASE one already provided. The moral is, don't use %N at all :) --chupchup From tinymuck-sloggers-owner Thu Mar 14 00:20:02 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06344; Thu, 14 Mar 91 00:04:36 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06340; Thu, 14 Mar 91 00:04:35 -0800 Message-Id: <9103140804.AA06340@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Thu, 14 Mar 91 03:04:32 -0500 Date: Thu, 14 Mar 91 03:04:29 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: A few things Status: RO Yep, a primitive for 2.2+ to check locks is a kludge. But we're talking about only medium-sized changes at most. Deleting locks from the game is not a medium-sized change (IMHO). "You see nothing special" in succs is terrible because the room usually has a desc, and so you see a desc immediately followed by "You see nothing special." Usually the program is one which just spits out more text, and it looks a lot less ugly to just not have the extra text than to have the bogus message. BTW, why do extracts from Mud seem to come with "sex:unassigned" on everything? From tinymuck-sloggers-owner Thu Mar 14 01:20:02 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07778; Thu, 14 Mar 91 01:04:23 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07774; Thu, 14 Mar 91 01:04:21 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA00534; Thu, 14 Mar 91 01:02:37 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01975; Thu, 14 Mar 91 01:02:34 PST Date: Thu, 14 Mar 91 01:02:34 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9103140902.AA01975@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: arromdee@server.cs.jhu.edu's message of Thu, 14 Mar 91 03:04:29 -0500 <9103140804.AA06340@belch.Berkeley.EDU> Subject: A few things Status: RO Well, like I say, if you can't do it right don't do it at all-- and locks in 2.2 can't be done right because you *can* lock to programs. MUD extracts get read in with some long-untouched code that made efforts to convert GENDER flags to properties on players, but it updated everything, and one MUCK admin told me it set all the players HAVEN, altho I haven't seen it happen anywhere else. I had a spiffy little convert program that took that redundant, unecessary code out of the server and required you to convert offline, before loading it into a MUCK, much more efficient that way. And it was more complete, players carrying exits or moving rooms to #0, for example, can't be handled easily while the database loads but should be done afterwards or offline. --chupchup(EVIL!) From tinymuck-sloggers-owner Thu Mar 14 03:50:03 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07846; Thu, 14 Mar 91 03:44:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07842; Thu, 14 Mar 91 03:44:26 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 14 Mar 91 11:43:03 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04708; Thu, 14 Mar 91 11:43:30 gmt Message-Id: <9103141143.AA04708@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK 2.2+ Proposals Date: Thu, 14 Mar 91 11:43:29 GMT From: Mike Prudence Status: RO Okay, It looks like we have a lot of interest on this, so it's time for someone to take charge. With the permission of the assembled millions (!) I'll try and coordinate this, and get some action going. First step is to look at the messages so far, and pick out a few elements we can decide on easily. I also have some comments on some of the more "long term" stuff that ChupChup mentioned. Anyways, on with the show. I'll send out three messages, because I think we have three categories to discuss - primitives, server changes, and bug fixes. I'll list each item submitted so far, along with outstanding issues. Things that have to be decided on, I'll put in a line with the word VOTE. Please respond with your votes on the various issues. If anyone disagrees with this process, please let me know. I'm easy, as they say :) As a BTW, I have a list of hacks that Tygryss and Sthiss have done. Are either of you two on this mailing list ? If not, could someone get in touch with them and get them on the list ? I am reluctant to mention their mods until they have made them public themselves. Oh - and a name for this release. Is it going to be 2.2+ or 2.3 ?? Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Thu Mar 14 04:12:06 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07882; Thu, 14 Mar 91 03:46:39 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07878; Thu, 14 Mar 91 03:46:35 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 14 Mar 91 11:45:13 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04731; Thu, 14 Mar 91 11:45:40 gmt Message-Id: <9103141145.AA04731@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Proposed Bugfixes for 2.2+ Date: Thu, 14 Mar 91 11:45:39 GMT From: Mike Prudence Status: RO BugFixes -------- I was unaware of any of these !! 1) W programs should be allowed to call any program. No argument there, I think. Or is there ? 2) If the @succ for a room is a program, teleporting (using MOVETO programs, no ?) causes a "You see nothing special" message. I actually removed this message in my MUCK - it is caused by the server's inability to run the @succ program, because it is already running the program doing the MOVETO. Such is life. VOTE : do we "see nothing special" if we MOVETO into a room with a program in its @succ ? 3) The infamous %N bug Another one I missed. Seems like a good idea to fix it ! 4) Giving an object a program as an @drop should supress the standard @odrop message. I'm not clear on why this is a problem. Surely if you set the @drop to a program, you can set the @odrop to be nothing, and let the program handle all the output. Maybe I've missed something ! VOTE : If an object has a program as it's @drop, should we supress the @odrop message ? From tinymuck-sloggers-owner Thu Mar 14 04:20:04 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07876; Thu, 14 Mar 91 03:46:13 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07872; Thu, 14 Mar 91 03:46:09 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 14 Mar 91 11:44:46 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04724; Thu, 14 Mar 91 11:45:13 gmt Message-Id: <9103141145.AA04724@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Proposed 2.2+ Server Mods Date: Thu, 14 Mar 91 11:45:12 GMT From: Mike Prudence Status: RO Server Modifications -------------------- 1) 'connect' and 'disconnect' actions Well, I think changing my 'pending' to 'connect' is pretty sensible. I also think that having a 'disconnect' exit in a room is a good move, too. ChupChup said there were problems, but never said exactly what they were - care to elaborate ? Looking at the code I have, I actually just use this :- if (can_move(player, "pending")) do_move(player, "pending"); so I guess it takes any viable exit. VOTE : Should we implement connect and/or disconnect actions ? 2) Timestamps Ken brought this one up. I've never found the need, which is why I forgot them, but they seem a good idea for Real Mucks. I mentioned timestamp primitives in the previous message. I think we need to look closely at timestamps, which is why I am leaving most of the discussion out for now. VOTE : should we implement timestamps ? 3) Locking to FALSE Good idea. VOTE : should we implement locking to FALSE ? 4) Tidying up of LOCKS after a recycle. Basically, a recycle can leave locks on other objects as garbage. It seems to me to be a Good Thing to leave the database in as nice a state as possible after a recycle. However, ChupChup tells us we would have to parse the locks, which sounds like a Bad Thing. VOTE : should we implement lock tidying after recycle ? 5) Working Extract C'mon guys - amongst all this enthusiastic database hacking, I think we should spend some time providing a proper support environment - and extract is part of that environment. VOTE : should we provide a working extract program ? VOTE : should we spedn time tidying up the support environment ? 6) Providing "def" lines in programs for program-local macros This seems like a damn good idea. I imagine something like this :- ( Program : test.m ) def prompt me @ swap notify var blah : main "Hello World" .prompt ; Is that what everyone else thinks ? VOTE: should we implement program-local macros ? 7) Personal Macro Libraries I think this is more or less catered for with the above, considering that it would probably need more work to get it going. VOTE : should we implement personal macro libraries ? 8) Any strings sent to the players in a room are also sent to all the objects in a room. I can't argue with ChupChup here - it is gross. However, I didn't quite follow what you said afterwards, Chup - care to elaborate a bit more ? I think that the sort of modification you were talking about is quite a hefty piece of coding, with some redesign to boot. If I'm wrong, let us know. As for infinite loops, they don't happen because the server can only execute one program at a time. If a program does a 'notify' it cannot cause another program to be triggered. I put this mod in to allow objects to react to player actions, not to other programs. It is simple to use and implement, even though it reeks of hackiness. VOTE : should we implement the 'trigger' object mods ? 9) Triggering Programs When Objects are Moved Again, this is hacky, but it answers the need I had. I agree with ChupChup, but I think that is a longer term view. As I saw 3.0 developing, it was going to be a radical redesign - most of the MUF we had now would break for one reason or another. Anyway, I would like to see this in if only to cope with the special cases it does cope with. I am open to other suggestions. VOTE: should we implement triggers for objects being moved ? From tinymuck-sloggers-owner Thu Mar 14 04:26:12 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07870; Thu, 14 Mar 91 03:45:40 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07866; Thu, 14 Mar 91 03:45:35 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 14 Mar 91 11:44:12 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04715; Thu, 14 Mar 91 11:44:39 gmt Message-Id: <9103141144.AA04715@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Proposed 2.2+ Primitives Date: Thu, 14 Mar 91 11:44:38 GMT From: Mike Prudence Status: RO Primitives ---------- dbtop ( -- n) - returns the size of the database. ChupChup suggested that this returns an actual dbref. That has a nice ring to it, but I suspect the majority use of this primitive is to control loops, in which case an int is easier. VOTE: should we implement a dbtop primitive ? VOTE: return an integer or a dbref ? connect? (d -- n) - is player 'd' connected ? ChupChup and jearls pointed out that the Crossroads people and others have this as 'awake?'. This is fine by me. VOTE: should we implement awake ? VOTE: should awake? return the number of times a player is connected instead of a simple boolean result ? online ( -- d d .. n) - returns a list of the connected players This seems like a nice idea (thanks John). VOTE : should we implement online ? toupper (s -- s) tolower (s -- s) - convert string to all upper/lower case I see these as being pretty vital, as ChupChup says, because SUBST and INSTR are case sensitive. VOTE: should we implement toupper and tolower ? logon (d -- s) - returns the time that the player logged on. idle (d -- s) - returns the player idle time. ChupChup pointed out that these would be better done to return an integer, with some sort of ctime primitive to parse them. This sounds good, and I think it's what John was suggesting with his systime stuff (see below.) VOTE : should we implement logon and idle ? VOTE : should logon and idle return integers ? systime ( -- int ) returns number of seconds since midnight, Jan 1 1970 timefmt ( str int -- str ) formats a systime into a string. timesplit ( int -- int int... ) splits a systime into year, month, date, day of week, hour, minute, second. These three primitives could provide the time munging capability we need. What can timefmt do for us, John ? VOTE : should we implement all/some/none of systime/timefmt/timesplit ? int? ( ?? -- flag ) string? ( ?? -- flag ) dbref? ( ?? -- flag ) return true if the top of the stack is the specified type. These all seem like a Good Idea. VOTE : should we implement type-checking primitives ? smatch (s1 s2 -- s n) - basic '*' string matching. Ken Arromdee says that TinyMage has the same primitive - I seem to recall taking the code for this out of the Mass-Neotek 'bot a long time ago. Anyway, Mage calls it wmatch. (Why wmatch ??). Personally, I don't care what it is called, and I think, as ChupChup points out, we could probably lose it anyway - regexp does the same and more. I suspect a simple macro could replace uses of smatch to use regexp instead. BTW, Does TinyMAGE have it's arguments the same way around ?? VOTE : do we need to keep smatch if we have regmatch ? VOTE : do we call it smatch or wmatch ? setlink (d1 d2 -- ) - links d1 to d2 As ChupChup noted, this only allows you to link to one thing. I put it in to allow one program to configure an object's actions automatically - part of an 'install' program for a MUF system. I would love to see a way to use multi links, but I don't have the necessary brainpower to tackle it myself. VOTE : Should we implement the setlink primitive ? VOTE : Should we extend it to allow multiple links ? setown ( db1 db2 -- ) changes ownership of db1 to db2. Another one from John. VOTE : should we implement setown ? newobject ( str dbref -- dbref ) newroom ( str dbref -- dbref ) newexit ( str dbref -- dbref ) These create new objects with the name "str" and the location "dbref", and return the dbref. VOTE : should we include object/room/exit creation primitives ? regmatch (s1 s2 s3 -- s4 n) - full regular expression matching. Yes, this is Henry Spencer's library ((c) Univ. of Toronto). I put in the simplest interface I could think of, but I can understand the speed gains to be had by keeping compiled up regexps around. Maybe two primitives - regcomp and then regmatch - would be better. In a simple form, we could just store regexps as strings, but this might be a problem if someone prints one out :) VOTE : should we implement regmatch ? VOTE : should we have separate regcomp and regmatch ? last (dbref -- str) - returns the timestamp on an object. Mentioned by Ken Arromdee. I wonder whether this might be better called 'getstamp' or somesuch ? 'last' seems a bit too vague by itself (personal opinion). ChupChup suggested just returning an integer. I think this is a good idea, too. VOTE : should we implement 'last' ? VOTE : 'last' or 'getstamp' or any other name ? VOTE : should 'last' return an integer for use with timefmt/ctime ? setlast (dbref str -- ) - set the timestamp on an object. Another Ken invention. ChupChup suggested calling it 'stamp'. 'setstamp' is my offer. Chup also said that an owner should be able to set a timestamp. Might this allow the owner to preserve his areas by just logging in and running a 'global timestamp' program ? VOTE : should we implement 'setlast' ? VOTE : 'setlast', 'stamp', 'setstamp' or any other name ? date (-- str) - return the current date in date(1) format. I wonder whether this would be better given by John's systime stuff ? (see above) VOTE : should we implement date if we have systime ? nextprop (str -- str) - returns the next property in an object's p-list I (and Jon) are a little unsure of this one. I think we *do* need some more sophisticated access to property lists, but I think it is achieved by defining a *standard* for property lists, and a few macros to access them. I'll send out a separate message with a proposed property list standard on. checklock (dbref dbref -- int) - checks locks on an object This would seem to be a good idea. Chup seemed to have a few reservations, though :) Not wanting to get into a major hacking bout, I'll leave this for greater minds and future discussion. version ( -- s) I take it that this returns the version of the MUCK server ? A can't see a use for this, offhand. At least, if only 2.2+ has it, the only result it would return would be "2.2+" which wouldn't be all that useful :) Ken - have you any specific uses in mind ? unparse_object (dbref -- s) I'm a little hazy on what this does. Would you care to clarify, Jon ? (callas@erienet.dec.com) uid (-- dbref) Another one from Jon that I don't have enough info on - care to clarify ? At a guess, does it return the effective user ID of the program that is running ? this_program ( -- dbref) - return current program dbref This would seem to be a nice addition to the me, loc, trigger stuff. What uses has it been put to, Jon ? VOTE : should we implement this_program ? From tinymuck-sloggers-owner Thu Mar 14 08:50:05 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08244; Thu, 14 Mar 91 08:32:10 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08240; Thu, 14 Mar 91 08:32:07 -0800 Message-Id: <9103141632.AA08240@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Thu, 14 Mar 91 11:32:01 -0500 Date: Thu, 14 Mar 91 11:31:59 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: version' Status: RO A clarification: I wasn't proposing version as a MUF word, but as a server command. It doesn't have to be built in, but if it's not the standard distribution should probably include a "version" action in #0 along with any other standard material. "last" was named as it is because the property on mushes is named "last", and I think it was on mbongo too. It was wizard only because on mushes you cannot set "last" unless you're a wizard.... A few more suggestions: Programs in a person's succ, fail, and drop do not work. Fix them.... Allow the C flag to actually _work_ on programs. Allow someone to set a program JUMP_OK (same word, but now referring to JUMP as in a jump to another program!) which allows you to call them from other programs, and run them if you have a link to them (and list them for that matter), but which does not permit new links to them. Bugfixes: > VOTE : do we "see nothing special" if we MOVETO into a room > with a program in its @succ ? My vote is obvious. :-) (No, don't show anything at all) >4) Giving an object a program as an @drop should supress the standard > @odrop message. > I'm not clear on why this is a problem. Surely if you set the > @drop to a program, you can set the @odrop to be nothing, and let the > program handle all the output. Maybe I've missed something ! > VOTE : If an object has a program as it's @drop, should we > supress the @odrop message ? Clarification: If you drop something, others see "Player dropped item." If the object's @drop is a program, others still see this message. The message can be changed by changing the @odrop of the item, but cannot be removed. This means that if you want to create an undroppable item like a shirt that must first be removed before dropping, or an item which does something after it's dropped, you have to do "@action drop shirt;drop shir;dro shirt;dr shirt;drop shi;....." to get rid of the message. My vote yes. > VOTE: should we implement a dbtop primitive ? > VOTE: return an integer or a dbref ? Yes, integer. > VOTE: should we implement awake ? > VOTE: should awake? return the number of times a player is > connected instead of a simple boolean result ? Yes, return the number of times. Anyone who wants a boolean result can use "number of times" as one anyway, since like in C all non-zero values are true. >online ( -- d d .. n) - returns a list of the connected players > This seems like a nice idea (thanks John). > VOTE : should we implement online ? This was named "users" on SynthMAGE. (On the other hand, do we really _want_ MAGE compatibility? :-)) (Yes, do it.) > VOTE: should we implement toupper and tolower ? Yes! > VOTE : should we implement logon and idle ? > VOTE : should logon and idle return integers ? Yes, yes. > VOTE : should we implement all/some/none of > systime/timefmt/timesplit ? Do it. >int? ( ?? -- flag ) >string? ( ?? -- flag ) >dbref? ( ?? -- flag ) > return true if the top of the stack is the specified type. Do it. > VOTE : do we need to keep smatch if we have regmatch ? > VOTE : do we call it smatch or wmatch ? I checked, and the format for wmatch was (str pat -- int); it returned a 1 or 0. This is not identical to smatch, so forget I ever mentioned "wmatch". Use smatch, only if you don't have regmatch. >setlink, setown, newobject, newroom, newexit, setown Along with recycle. This is one of those things that a Mush/Mage type system would be better at, but sure, go ahead.... >regmatch (s1 s2 s3 -- s4 n) - full regular expression matching. I don't think people will be using this enough to need compiled regexps, so do it uncompiled.... > VOTE : should we implement 'last' ? > VOTE : 'last' or 'getstamp' or any other name ? > VOTE : should 'last' return an integer for use with timefmt/ctime ? Return an integer, yes. (I didn't think of that.) I prefer the name "last" (or at least "stamp"). "last" is the name on Mushes, and we don't have "getdesc", "getfail", "getsucc", etc... but "desc", "fail", "succ".... >setlast (dbref str -- ) - set the timestamp on an object. Hmm. The reason, I would guess, why players are not allowed to set "last" fields is that somebody could log in and create a hundred objects all with dates of February 29, 2000, then never log in again and never have his objects caught when the wizards want to recycle stuff and start going through the old objects. So I don't know if it should be wiz-only or not. (Maybe players can set timestamps to anything past/present, and wizards can also set it to the future?) Make it take whatever the date functions return. (str is a bit silly...) > VOTE : should we implement date if we have systime ? Naaaah... >nextprop (str -- str) - returns the next property in an object's p-list > I (and Jon) are a little unsure of this one. ... So am I. :-) I proposed it more for completeness than anything else (I don't see a use for it other than writing an "examine" simulation anyway.) >uid (-- dbref) > Another one from Jon that I don't have enough info on - care to >clarify ? At a guess, does it return the effective user ID of the >program that is running ? If this is it, sounds good. >this_program ( -- dbref) - return current program dbref > This would seem to be a nice addition to the me, loc, trigger >stuff. What uses has it been put to, Jon ? Ditto. > VOTE : Should we implement connect and/or disconnect actions ? Hmm.... Dunno.... > VOTE : should we implement timestamps ? You could leave it a compile-time option.... > VOTE : should we implement locking to FALSE ? Yes. > VOTE : should we implement lock tidying after recycle ? Undecided. > VOTE : should we provide a working extract program ? > VOTE : should we spedn time tidying up the support environment ? Yes. (Though it's easy for me to talk, since I don't work on any servers and wouldn't be the one doing this.) > VOTE: should we implement program-local macros ? Yes! > VOTE : should we implement personal macro libraries ? Not really needed. >8) Any strings sent to the players in a room are also sent to all the >objects in a room. >9) Triggering Programs When Objects are Moved It's gross. :-) It also reeks of Mush/Mage. I don't particularly like the idea unless it's done completely. From tinymuck-sloggers-owner Thu Mar 14 09:20:05 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08298; Thu, 14 Mar 91 09:01:54 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08294; Thu, 14 Mar 91 09:01:52 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01134; Thu, 14 Mar 91 09:00:11 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA02842; Thu, 14 Mar 91 09:00:08 PST Date: Thu, 14 Mar 91 09:00:08 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9103141700.AA02842@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Server Modifications Status: RO | 7) Personal Macro Libraries | I think this is more or less catered for with the above, considering | that it would probably need more work to get it going. This has a great advantage in that it provides a new namespace; macro definitions within programs only supplement function definitions and they can't be used outside those programs... --chupchup From tinymuck-sloggers-owner Thu Mar 14 09:47:45 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08273; Thu, 14 Mar 91 08:55:36 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08269; Thu, 14 Mar 91 08:55:34 -0800 Received: by coke.eng.umd.edu (5.65+(UMDENG)/UMDENG-0.4/09-20-90) id AA09794; Thu, 14 Mar 91 11:56:31 -0500 Date: Thu, 14 Mar 91 11:56:31 -0500 From: buzzard@eng.umd.edu (Sean Barrett) Message-Id: <9103141656.AA09794@coke.eng.umd.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Proposed 2.2+ Primitives Status: RO > version ( -- s) > I take it that this returns the version of the MUCK server ? A > can't see a use for this, offhand. It has no use--now. Future generations will thank you for it--assuming "2.2+" makes it into fututre generations. > setlink (d1 d2 -- ) - links d1 to d2 > I > would love to see a way to use multi links, but I don't have the > necessary brainpower to tackle it myself. addlink, removelink? > setlast (dbref str -- ) - set the timestamp on an object. > Might this allow the owner to preserve his areas > by just logging in and running a 'global timestamp' program ? Without it, programmers will resort to writing bots that log in and keep their stuff fresh. Creating a "secure" timestamping system is essentially impossible--all it takes is for a builder to have a second computer account from which she can create a new character on your registration-only, one character-per-account mud. With that new character, she can bypass any restrictions you make on "builders can't affect their own timestamps". Might as well give a primitive to them and save yourself the trouble, and trust that most things you wish to catch with timestamps will still get caught. > toupper (str -- str) > tolower (str -- str) Hmm. On both lpmud and my mud, we provide a "convert string to all lowercase" primitive and a "convert the first letter to upper case" primitive. I can't honestly see the need for both. Either one allows you to do case insensitive operations, and so only one seems necessary. I "arbitrarily" selected tolower, as this allows you to handle idiots with stuck caps-lock keys, and my "toupper"-like thing allows you to conveniently capitalize words at the beginning of a sentence or whatever. Unless you really want to encourage people to write BIFF filters in MUF. Halloway @ EVIL!mud Satoria @ mud_of_the_month@uokmax.ecn.uoknor.edu Satoria @ Darker Realms lpmud p.s: Maybe you should have a DISCUSS period before the VOTE period? (: From tinymuck-sloggers-owner Thu Mar 14 09:50:06 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08350; Thu, 14 Mar 91 09:28:12 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08346; Thu, 14 Mar 91 09:28:10 -0800 Received: by eagle.calpoly.edu (4.1/2.890629) id AA20156; Thu, 14 Mar 91 09:25:47 PST Date: Thu, 14 Mar 91 09:25:47 PST From: jearls@eagle.calpoly.edu (Johnson M. Earls) Message-Id: <9103141725.AA20156@eagle.calpoly.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Oops Status: RO In my "votes" message I talked about having DBTOP return a dbref and said to see below. Well I forgot the below part, so here it is: Get rid of DBCMP (or maybe keep it for compatibility) but make it so <, =, and > work on any two items of the same type. I.E. "A" "B" < if "This is true" .tell then #5 #3 < if "This won't happen" .tell then - John From tinymuck-sloggers-owner Thu Mar 14 11:20:07 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08678; Thu, 14 Mar 91 11:13:20 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08674; Thu, 14 Mar 91 11:13:14 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01561; Thu, 14 Mar 91 11:11:18 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03361; Thu, 14 Mar 91 11:11:14 PST Date: Thu, 14 Mar 91 11:11:14 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9103141911.AA03361@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Johnson M. Earls's message of Thu, 14 Mar 91 09:25:47 PST <9103141725.AA20156@eagle.calpoly.edu> Subject: Oops Status: RO I did that in my 3.0 code a while ago -- the old primitives still worked, but < = > worked on like types to provide a simpler interface if you don't like "strcmp not" all the time. Gazer pointed out to me that DBCMP is misnamed to begin with, it should return the difference between two database numbers, but this would break code, as a zero result would be true. But I might do it in 3.0 anyway :) --chupchup From tinymuck-sloggers-owner Thu Mar 14 11:50:06 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08693; Thu, 14 Mar 91 11:25:03 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08689; Thu, 14 Mar 91 11:24:59 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Thu, 14 Mar 91 13:24:54 -0600 id AA07076 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Thu, 14 Mar 91 13:24:41 -0600 id AA27898 Date: Thu, 14 Mar 91 13:24:41 -0600 From: Lee Brintle Message-Id: <9103141924.AA27898@umaxc.weeg.uiowa.edu> To: arromdee@server.cs.jhu.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: A few things Status: RO A good reason to have locks as MUF primitives is that the parser takes up stack space; probably quite a bit of stack space. I don't like the idea of endless loops, as you all already know, so I don't see that as an answer to the problem. The lock primitive ought to be: eval_lock ( d s -- i ) Evaluate lock s for user d. Then with a get_lock primitive, you could easily evaluate locks and also evaluate non-locks (that is, you wouldn't have to have a string be in a lock in order to evaluate it). -- Tanj From tinymuck-sloggers-owner Thu Mar 14 20:35:38 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA00526; Thu, 14 Mar 91 20:03:42 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA00520; Thu, 14 Mar 91 20:03:30 -0800 Received: from hussar.dco.dec.com by decuac.DEC.COM (5.61/Ultrix-fma) id AA08369; Thu, 14 Mar 91 23:02:18 -0500 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-111690); id AA00557; Thu, 14 Mar 91 23:02:16 -0500 Date: Thu, 14 Mar 91 23:02:16 -0500 From: mjr@decuac.DEC.COM (Marcus J. Ranum) Message-Id: <9103150402.AA00557@hussar.dco.dec.com> To: durrell@umaxc.weeg.uiowa.edu, jennifer@valkyrie.ecn.uoknor.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUCK and Unter Cc: untermud@hussar.dco.dec.com Status: RO >I may be sorry for suggesting this later. Onward. You'll be sorry for it *immediately*, I assure you. ;) >Since all Unter database elements are strings, there is no reason I >can see why a MUCK 2.x couldn't be hacked to add another port for >OIF (object interchange format). Should be do-able. The code for OIF transactions will be like all the other UnterMUD code - a "snap in" module. Presumably it would snap into another MUD, if the required wrapper code to convert local objects to OIF and back were present. >When a player moves from Unter to MUCK, all props that make sense >in a MUCK context would be translated to the appropriate thing -- >name to name, so on. This would also be do-able, but I question how well it would work (though I'd *LOVE* to see something like this someday) since many MUDs are just conceptually different enough to make things hard to translate. UnterMUD's notion of objects being owned by more than one person, for example, might be difficult to translate to MUCK, and if you did translate it, it would be hard to translate it back. UnterMUD @odrops, for example, can be either commands or text - simply converting to text would be inadequate. I feel that eventually inter-MUD portability of objects will be the way to go, but I suspect (and hope) it'll be based on a common architecture, preferably mine. ;) >Any Unter props that didn't make sense could be stored as MUCK >properties -- you'd probably want a naming scheme that attempted >to avoid overwriting existing props. Mapping an Unter prop >called "foo" to a MUCK prop named "unterfoo" would work >reasonably well. That it would, but by the time the object's attributes had all be translated, there wouldn't be much left of the thing. Everything would "break". IMHO it'd be easier to write a xyzMUD -> UnterMUD translator and just use UnterMUD, or use an UnterMUD -> xyzMUD translator. I'm tempted to hack together a TinyMUD->UnterMUD data base dumper - it shouldn't be too hard, since the underlying concepts of UnterMUD are basically TinyMUD-derived. mjr. From tinymuck-sloggers-owner Thu Mar 14 21:05:39 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA00628; Thu, 14 Mar 91 20:47:03 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA00624; Thu, 14 Mar 91 20:46:59 -0800 Received: by cory.Berkeley.EDU (5.63/1.42) id AA27901; Thu, 14 Mar 91 20:45:51 -0800 Date: Thu, 14 Mar 91 20:45:51 -0800 From: cwong@cory.Berkeley.EDU (Conrad Wong) Message-Id: <9103150445.AA27901@cory.Berkeley.EDU> To: durrell@umaxc.weeg.uiowa.edu, jennifer@valkyrie.ecn.uoknor.edu, mjr@decuac.dec.com, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUCK and Unter Cc: untermud@hussar.dco.dec.com Status: RO Um, one question. *why* do you want to port objects back and forth between MUCKs and UnterMUD? I can see transferring rooms, but it's a hack and a half, and frankly, it'd be much easier to make an extract tool that spits out a build file. -- Lynx From tinymuck-sloggers-owner Thu Mar 14 21:35:39 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01965; Thu, 14 Mar 91 21:11:52 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA01961; Thu, 14 Mar 91 21:11:50 -0800 Received: from boris.sdsc.edu by sluggo.sdsc.edu (4.1/4.7) id AA13101; Thu, 14 Mar 91 21:02:01 PST Date: Thu, 14 Mar 91 21:02:01 PST From: David Moore Message-Id: <9103150502.AA13101@sluggo.sdsc.edu> Received: by boris.sdsc.edu (4.1/SMI-4.1) id AA07822; Thu, 14 Mar 91 21:09:41 PST To: lbrintle@umaxc.weeg.uiowa.edu Cc: arromdee@server.cs.jhu.edu, tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Lee Brintle's message of Thu, 14 Mar 91 13:24:41 -0600 <9103141924.AA27898@umaxc.weeg.uiowa.edu> Subject: A few things Status: RO Ummmm, I think that my muf lock checking code ran using probably no more than 10 things on the stack at the widest point. Chup said he could understand it when I showed it to him a while back, but I had always been meaning to clean it up and then send it out. How much interest is there in it? Basically looked like check_lock ( s d -- b ). Where s was the lock in a string format (it's already compiled, exact same format as the locks in the db dump), and d was a player dbref. It checked the lock using the player's current postion and objects. Other routines are readily doable to convert from a @lock sort of format to the dump format. David "OliverJones" Moore From tinymuck-sloggers-owner Thu Mar 14 22:05:39 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02092; Thu, 14 Mar 91 22:00:43 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02088; Thu, 14 Mar 91 22:00:39 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Fri, 15 Mar 91 00:00:37 -0600 id AA15365 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Fri, 15 Mar 91 00:00:23 -0600 id AA10498 Date: Fri, 15 Mar 91 00:00:23 -0600 From: Cyberpixie Message-Id: <9103150600.AA10498@umaxc.weeg.uiowa.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUCK and Unter Cc: untermud@hu Status: RO How odd. I got replies, but not the original message. Anyways. The reason to do it isn't trying to move mass amounts of things from MUCK to Unter. I think it's reasonably obvious that you aren't going to get much crosscompatibility here. Only reason to do it is to get some minimum capabilities of walking from MUD to MUD. On the other hand, people seem to spend most of their time using say and pose anyways... On the third hand, nobody's going to do this, so the point becomes more or less moot. ---------------------- "I was always busy doing something close to nothing..." Bryant Durrell durrell@umaxc.weeg.uiowa.edu durrell@husc9.harvard.edu bryant@valkyrie.ecn.uoknor.edu Speaker-to-Eris // 'Muffin // FEM // Tif's Consort --------------------------- From tinymuck-sloggers-owner Thu Mar 14 23:35:39 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02185; Thu, 14 Mar 91 23:14:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02181; Thu, 14 Mar 91 23:14:26 -0800 Received: by cory.Berkeley.EDU (5.63/1.42) id AA01455; Thu, 14 Mar 91 23:13:48 -0800 Date: Thu, 14 Mar 91 23:13:48 -0800 From: cwong@cory.Berkeley.EDU (Conrad Wong) Message-Id: <9103150713.AA01455@cory.Berkeley.EDU> To: durrell@umaxc.weeg.uiowa.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUCK and Unter Cc: untermud@hu.Berkeley.EDU Status: RO If you want to walk from one MUD to another, won't cyberports still be compatible? I understand what you mean, using the same mechanism as UnterMUD to walk from one place to another, but the point is that the benefit gotten is very little-- transferrence of objects-- for a very large cost, rewritting a lot of stuff to add UnterOIF capability. Then again, I'm not a server hacker-- what do I know?... At any rate, I should stop replying on this subject until I look at what the complete UnterMUD as it stands looks like. ('gryn) So g'night all of you. -- Lynx From tinymuck-sloggers-owner Sat Mar 16 22:36:00 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11861; Sat, 16 Mar 91 22:09:59 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA11857; Sat, 16 Mar 91 22:09:57 -0800 Received: by cory.Berkeley.EDU (5.63/1.42) id AA21606; Sat, 16 Mar 91 22:09:22 -0800 Date: Sat, 16 Mar 91 22:09:22 -0800 From: orleans@cory.Berkeley.EDU (ORLEANS DOUGLAS KEVIN) Message-Id: <9103170609.AA21606@cory.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Replies to various messages Status: RO Wow! I guess this mailing list is far from dead. Here are my thoughts on what some people have said so far: blip sez: > Here are the changes I have made to TinyMUCK. > [Lots of interesting changes.] Where is your muck? I'd like to try it out and experiment with these features. Ken Arromdee sez: > It should be possible to define macroes for the duration of a single > program. I suggest allowing "def" lines in programs which behave like > "def" lines typed in the editor, but affect only that one program. > (Probably outside functions only, just like "var" has to be outside > functions). Well, it's very easy to do this; to define a macro .foo, just say : .foo ; The whole point of macros was to facilitate code re-use among different programs. If we had macros with parameters, then that would be a different story, but that's what the stack is for. chupchup's reply to the previous part: > Hmm. This sounds like a Good Idea, and is pretty easy to do. Another thing > that some people have really wanted is personal macro libraries, so they can > define their own things that wouldn't otherwise be useful to everyone on the > MUCK; but things that are used in their own programs a lot. But this is > harder and would mean more disk/memory... Now personal macro libraries would be useful. I like chupchup's idea of "publish"able words. Basically, each program would have its list of words, and at the end, it would have a sequence of "publish " commands, which essentially make those words public. Then to call a program, you have to call a specific word in the program (as opposed to just running the last word defined, as it is now). This would require a modified syntax for the call primitive: call ( dbref string -- ?? ) ( calls word "string" defined in program dbref ) Basically, this would be like the private/public function mechanism in C++ and other object-oriented languages. An alternative would be to have the equivalent of C #include directives; a program could say "include #X" and all the words defined in the program X would be available to the program. There should be some way to have private words, though, so that programs could have its own helper-words without having to worry about name conflicts. I think a simple "private" before the : definition would suffice. chupchup sez: > MUF NEEDS REAL LISTS -- or a way to implement them smoothly and uniformly > from the language itself, but I chose the first and put in list primitives > for 3.0. I think the second way is much better, especially since that's how it's done in Forth. (If we had a type-definition mechanism the way Forth does, than we could also have inorder math and all sorts of neat things, if we wanted.) blip sez: > [Lots of things to vote about.] Well, for all the "should we implement" questions, my vote is YES. For the "either/or" questions, I really don't see any strong arguments against either alternative , so whatever whoever writes the code thinks would work out the best. blip sez: > 2) If the @succ for a room is a program, teleporting (using MOVETO > programs, no ?) causes a "You see nothing special" message. > > I actually removed this message in my MUCK - it is caused by the > server's inability to run the @succ program, because it is already > running the program doing the MOVETO. Such is life. The server could very easily run the @succ program, it seems to me. I don't see how it's any more complicated than handling the call primitive. I think the main reason a moveto doesn't trigger the @succ program (or the @desc program, for that matter) is to avoid an infinite loop: consider teleporting into a room which has a @desc program which teleports you into itself... I think this is annoying, because this one small possibility of an infinite loop screws everything up. It's nice to have a program in the @desc and/or @succ to handle changing scenery, etc, but either you have to make the room !jump_ok, so that no one can teleport in, or have the people who do teleport in see a plain old message. In the case of time-dependent scenery, one kludge would be to have the @desc program change the "plain old message" part if applicable, but obviously this isn't the answer. The only way I think would be feasible to avoid this is to "push down" the limitation one more level: instead of not allowing you to run a program after a moveto, it should just limit you to one moveto in the sequence of programs called. Suggestion for implementation: have a flag (a C flag, not a db flag) which is set false whenever a program terminates; whenever a moveto instruction is encountered, if the flag is false, then set it true and do the moveto, otherwise terminate with an error message. I know, terminating in the middle of a program would be messy, but that's what happens when an item to be moveto'd is not jump_ok. Basically, it would be up to the programmer to not put a program which does a moveto into a @desc or @succ field. You could make the server enforce this, assuming it had some easy way to determine whether a program did a moveto, by not allowing you to set the @desc field to one of these programs, but this idea seems far too silly to be worthwhile. Rather make the programmer be responsible. One final question: Do you think it would be worthwhile to have a list of all Muds running MUCK 2.2? DougO aka WhiteRabbit orleans@cory From tinymuck-sloggers-owner Sat Mar 16 23:35:59 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19676; Sat, 16 Mar 91 23:13:46 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19672; Sat, 16 Mar 91 23:13:44 -0800 Message-Id: <9103170713.AA19672@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Sun, 17 Mar 91 02:13:41 -0500 Date: Sun, 17 Mar 91 02:13:39 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Replies to various messages Status: RO Oops. You're right. I never thought of defining words like that. Sigh.... From tinymuck-sloggers-owner Tue Mar 19 02:50:47 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12730; Tue, 19 Mar 91 02:33:01 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12726; Tue, 19 Mar 91 02:32:57 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Mar 91 10:31:20 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA14610; Tue, 19 Mar 91 10:31:57 gmt Message-Id: <9103191031.AA14610@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK2.2+ - feedback so far Date: Tue, 19 Mar 91 10:31:56 GMT From: Mike Prudence Status: RO Hi everyone, Well, we've seen quite a bit of discussion and even some voting, so I guess it's time to sort through the mail. I'll send out three messages again - one each for primitives, server mods and bugfixes. My intention with the 'VOTE' bit was to weed out the issues we all agreed on, and just leave the contentious stuff behind. By and large, from the few voters, it seemed to work well, and the list of outstanding issues is much smaller. When we've decided on the things to include, we'll have to sort out who is going to supply what. Most of the things have already been coded out there, so it should be a matter of persuading the author to send me (or someone else - any volunteers ?) the code for inclusion. The things that are brand new might require some hacking, so now might be as good a time for anyone interested in any specific aspect to stick up their hands and let us know. Thanks everyone for your feedback - this has been one of the most fruitful discussions I have seen for a long time. Let's keep it up !! Cheers, Mike mjp@hplb.hpl.hp.com "Beware. Lettuce ahead" From tinymuck-sloggers-owner Tue Mar 19 03:16:56 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12742; Tue, 19 Mar 91 02:42:43 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12738; Tue, 19 Mar 91 02:42:39 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Mar 91 10:41:04 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA14633; Tue, 19 Mar 91 10:41:40 gmt Message-Id: <9103191041.AA14633@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK2.2+ Server Modifications Date: Tue, 19 Mar 91 10:41:39 GMT From: Mike Prudence Status: RO Server Modifications -------------------- 1) 'connect' and 'disconnect' actions No-one had any violent objections to this one, so I guess we can put it in. 2) Timestamps These should be a compile time option, but were generalyl considered useful. The details have yet to be ironed out, though. 3) Locking to FALSE Voted in. 4) Tidying up of LOCKS after a recycle. Apparently this is more hassle than it is worth. Not going in, 5) Working Extract and Environment Well, a working extract is one of those things that is 'nice' but doesn't help us play the game, I guess. With the advent of UnterMUD, it might become a moot point anyway :) I would like to see some more documentation put together, though, as well as a decent start database with a few good MUF programs included - sort of a starter kit. Submissions are welcome. 6) Providing "def" lines in programs for program-local macros Some kind soul pointed out that def foo me @ swap notify : main "bar" .foo ; is the same as :.foo me @ swap notify ; : main "bar" .foo ; so maybe we don't need them after all. If anyone has any pressing reasons why we do, speak now or forever hold your peace. 7) Personal Macro Libraries This seems to be an area open to debate, so maybe we should debate it. I have no feel for the difficulty of implementation, or the usefulness. Any comments ? 8) Any strings sent to the players in a room are also sent to all the objects in a room. People didn't seem to like this (I can't think why !!). That's fine by me, but I would maybe like to try and work out how you would do this properly - it has proved to be a handy feature for doing all those little things around the MUCK. Any thoughts, chaps and chapesses ? 9) Triggering Programs When Objects are Moved A few less 'blechs' than suggestion #8, but still disliked. Again, I would like to see this done properly as I think it has a place in the MUCK. Suggestions anyone ? From tinymuck-sloggers-owner Tue Mar 19 03:20:47 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12753; Tue, 19 Mar 91 02:55:05 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12749; Tue, 19 Mar 91 02:55:01 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Mar 91 10:53:26 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA14642; Tue, 19 Mar 91 10:54:02 gmt Message-Id: <9103191054.AA14642@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK2.2+ Bugfixes Date: Tue, 19 Mar 91 10:54:01 GMT From: Mike Prudence Status: RO BugFixes -------- 1) W programs should be allowed to call any program. Apparently a program called by a 'W' program doesn't inherit the W status. Is this what we want to happen ? 2) If the @succ for a room is a program, teleporting (using MOVETO programs, no ?) causes a "You see nothing special" message. The consensus seemed to be to nuke this message. Doug Orleans had another idea for implementation, and this may be an area for discussion. Over to you, folks. 3) The infamous %N bug Fix it. 4) Giving an object a program as an @drop should supress the standard @odrop message. Now that I understand this, I think we should do it - and so did most of you. 5) Programs in succ/fail/drop messages. I have a hunch that there is a pressing reason why this is not implemented. If there isn't, we should put this feature in. 6) Make CHOWN_OK programs work properly. Should we ? Why don't they ? OOops - a suggestion that really belongs in primitives. > = < should be modified to work on items of the same type. This seems to be a good idea. Any objections ? Oh - and the use of 'JUMP' programs. How about having programs that are READable (LINK_OK) and EXECUTable (JUMP_OK). I can see that you might not want a program to be readable, although you'd like to make it publically available. Doug also had some ideas on more advanced mechanisms for calling programs - food for further discussion, perhaps? From tinymuck-sloggers-owner Tue Mar 19 03:33:46 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12736; Tue, 19 Mar 91 02:34:59 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA12732; Tue, 19 Mar 91 02:34:56 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Mar 91 10:33:20 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA14617; Tue, 19 Mar 91 10:33:57 gmt Message-Id: <9103191033.AA14617@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK 2.2+ Primitives Date: Tue, 19 Mar 91 10:33:56 GMT From: Mike Prudence Status: RO The outstanding stuff is marked with stars '**'. Primitives ---------- dbtop ( -- n) - returns the size of the database. It looks like the consensus was to include this, and have it return an integer. awake? (d -- n) - how many times is player 'd' connected ? This primitive (I called it connect?) seems to be in. online ( -- d d .. n) - returns a list of the connected players Another primitive that people wanted. toupper (s -- s) tolower (s -- s) - convert string to all upper/lower case These seem to be in. I don't think you can emulate these in MUF, BTW - am I wrong ? logon (d -- n) - returns the time that the player logged on. idle (d -- n) - returns the player idle time. This are going in, and they'll return an integer number of seconds since the year dot. (whatever that is going to be) ************************************************************************* systime ( -- int ) returns number of seconds since midnight, Jan 1 1970 timefmt ( str int -- str ) formats a systime into a string. timesplit ( int -- int int... ) splits a systime into year, month, date, day of week, hour, minute, second. We were a little split on these - certainly, systime needs to be included, although both timefmt and timesplit could be done as MUF programs. Anyone got any strong feelings one way or the other ? I suggest, as we already have them coded up somewhere, that it might be easiest to just take them and plug them in. ************************************************************************* int? ( ?? -- flag ) string? ( ?? -- flag ) dbref? ( ?? -- flag ) return true if the top of the stack is the specified type. These were voted in. smatch (s1 s2 -- s n) - basic '*' string matching. The general feeling seems to be that smatch is rather redundant if we have regmatch, too. So we'll leave it out. ************************************************************************* setlink (d1 d2 d3 .. dA n -- ) - links dA to d1, d2, d3, ... A possible syntax for multiple links is shown above. We need to decide if this is the way to go. Another possibility is to have addlink and removelink primitives, so that multiple links are built up step by step. ************************************************************************* setown ( db1 db2 -- ) changes ownership of db1 to db2. newobject ( str dbref -- dbref ) newroom ( str dbref -- dbref ) newexit ( str dbref -- dbref ) recycle ( dbref -- ) With the addition of a recycle primitive, these were generally voted in. ************************************************************************* regmatch (s1 s2 s3 -- s4 n) - full regular expression matching. The consensus seemed to be that this was a good idea, and that holding compiled regexps around was perhaps overkill. David Moore suggested keeping a buffer of the last few regexps, but I don't have a feeling for whether this is worth the effort. Do you have any figures or hunches, David ? ************************************************************************* ************************************************************************* last (dbref -- int) - returns the timestamp on an object. Apparently, 'last' is used in Mushes, so it might be the name to use. Any other offers ? setlast (dbref int -- ) - set the timestamp on an object. One thought here was to restrict the ability of the non-wizard owner to set dates in the future. That sounds like a good idea to me. ************************************************************************* ************************************************************************* checklock (dbref dbref -- int) - checks locks on an object The issue of locks still has to be decided on. We have had suggestions for eval_lock and get_lock primitives, as well as some MUF lock code from David Moore. ************************************************************************* uid (-- dbref) If this returns the effective UID of the current program, then it was seen as a good idea. this_program ( -- dbref) - return current program dbref This was generally voted in. Provision of a safe 'me' was also mentioned. What's the feeling on that ? From tinymuck-sloggers-owner Tue Mar 19 08:50:49 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14358; Tue, 19 Mar 91 08:31:01 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14354; Tue, 19 Mar 91 08:31:00 -0800 Received: by enet-gw.pa.dec.com; id AA10078; Tue, 19 Mar 91 08:30:50 -0800 Message-Id: <9103191630.AA10078@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Tue, 19 Mar 91 08:30:56 PST Date: Tue, 19 Mar 91 08:30:56 PST From: This message sent with 100% recycled bits 19-Mar-1991 1125 To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Safe ME and LOC Status: RO There are already safe ME and LOC -- namely "me" match and "here" match but there is no safe TRIGGER. My feeling is that ME, LOC, and TRIGGER should say variables, but there should also be ways to get "safe" versions. I have seen some very good modular code that works by passing ME and LOC as parameters. As long as a potentially dangerous program has a way to get the *real* ME and LOC, then keeping them as variables is a good thing. Jon From tinymuck-sloggers-owner Tue Mar 19 09:12:57 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14338; Tue, 19 Mar 91 08:26:18 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14334; Tue, 19 Mar 91 08:26:16 -0800 Received: by enet-gw.pa.dec.com; id AA09553; Tue, 19 Mar 91 08:26:13 -0800 Message-Id: <9103191626.AA09553@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Tue, 19 Mar 91 08:26:14 PST Date: Tue, 19 Mar 91 08:26:14 PST From: This message sent with 100% recycled bits 19-Mar-1991 1109 To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Resend Status: RO Apparantly, my last mail message got lost, so I'll try again. The words that I suggested, UID, and THIS_PROGRAM, are as someone guesses they are. UID returns the effective user ID of this program. THIS_PROGRAM returns the DBREF of the executing program. Both are useful for some interesting cases. Since I only coded them up last week, I don't have code examples, but I can give the idea. Sometimes you want to know the UID running (to compare ownership before doing a MOVETO or something). The people in my game who want UID want it so that they can do this sort of thing. THIS_PROGRAM is useful because it allows you to have a handy known spot to store a useful database in a plist. The niftiest case is a SETUID program that stores a protected database on itself. This is what I want it for. A couple more comments: I vote against the suggestion to pass the W bit to called programs. This simply makes it too easy to make a trojan horse that takes advantage of a passed W bit. The current behavior is the correct behavior, in my opinion. In base 2.2, there is a bug in protected properties in the MUF interpreter. The interpreter checks for ability to write a dot-property (or _-property) based on the UID. This is wrong, it should be OWNER(program). Jon From tinymuck-sloggers-owner Tue Mar 19 09:20:49 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14391; Tue, 19 Mar 91 09:08:52 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14387; Tue, 19 Mar 91 09:08:49 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Mar 91 17:07:13 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA15902; Tue, 19 Mar 91 17:07:50 gmt Message-Id: <9103191707.AA15902@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Re: Safe ME and LOC Date: Tue, 19 Mar 91 17:07:49 GMT From: Mike Prudence Status: RO Hi guys and gals, > My feeling is that ME,LOC, and TRIGGER should say variables, but there should > also be ways to get "safe" versions. I have seen some very good modular code > that works by passing ME and LOC as parameters. As long as a potentially > dangerous program has a way to get the real ME and LOC, then keeping them as > variables is a good thing. I agree. I have used the writable nature of me,loc and trigger once or twice. Mind you, I never really have any security concerns because the MUCK I run has a pretty restricted playership. Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Tue Mar 19 09:50:49 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14484; Tue, 19 Mar 91 09:39:22 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14480; Tue, 19 Mar 91 09:39:20 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Tue, 19 Mar 91 11:39:09 -0600 id AA11563 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Tue, 19 Mar 91 11:38:56 -0600 id AA18514 Date: Tue, 19 Mar 91 11:38:56 -0600 From: Lee Brintle Message-Id: <9103191738.AA18514@umaxc.weeg.uiowa.edu> To: callas@eris.enet.dec.com, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Resend Status: RO (Skip the subject line....) Without sounding like a broken record (okay, maybe sounding LIKE a broken record), I'd like to see MUF tightened up from a security standpoint before I see any additions or extensions to it. In my opinion, MUF programs ought not be able to do anything that a user cannot do, security wise. We NEED a safe trigger @. In a big bad way. Thank you to whoever pointed out "me" match; that was a great idea (I'm now not even going to mention what I was doing before). I'd like to see a new flag added to the server. If all the MUCK commands are being moved to primitives, then we can do without the "BUILDER" flag. I propose the "BACKSTAGE" flag (or "NUMBERS" flag, if BUILDER is loved so much). If you are not set BACKSTAGE (the default), then database numbers of objects you own or L|A objects do not appear on the display. If you need the numbers, set yourself BACKSTAGE. There is nothing that spoils the current virtual reality more than seeing a cryptic string of numbers and flags after objects and rooms. I've been wanting this flag for about a year now.... please? If you all are interested, I still have my list of security changes that I posted in December; to me, this is the most important change that can be done to MUF/MUCK. Tanj Tanstaafl From tinymuck-sloggers-owner Tue Mar 19 10:20:50 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14530; Tue, 19 Mar 91 10:08:16 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14526; Tue, 19 Mar 91 10:08:15 -0800 Received: by enet-gw.pa.dec.com; id AA22109; Tue, 19 Mar 91 10:07:55 -0800 Message-Id: <9103191807.AA22109@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Tue, 19 Mar 91 10:08:01 PST Date: Tue, 19 Mar 91 10:08:01 PST From: This message sent with 100% recycled bits 19-Mar-1991 1303 To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Security Status: RO Gosh, well, I could post the security enhancements that I made. The ones that I have here are mostly just icing. Jon From tinymuck-sloggers-owner Tue Mar 19 10:46:00 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14610; Tue, 19 Mar 91 10:19:27 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14606; Tue, 19 Mar 91 10:19:24 -0800 Received: from UNLVM.BITNET by lilac.berkeley.edu (5.64/1.16.28) id AA07548; Tue, 19 Mar 91 10:19:17 -0800 Message-Id: <9103191819.AA07548@lilac.berkeley.edu> Received: by UNLVM (Mailer R2.07) id 2794; Tue, 19 Mar 91 12:20:11 CST Date: Tue, 19 Mar 91 11:08:53 CST From: Drazz'zt Subject: A few things mentioned.... To: TINYMUCK-SLOGGERS@belch.Berkeley.EDU Status: RO Howdy..... There are just a couple of things I wanted to point out concerning the current topic... 1. Macros for programs: Well, someone has pointed out the old use of :.foo bar ; as an alternate for def foo bar. This works all find and dandy, but I don't know if that is what the original suggestor was getting at (sorry I don't remember whose idea it was). But the one possibliity that I was thinking of was being able to call program macros from a called program. (eg. @prog junk1 i : .foo bar ; : main junk2 call ; . c q @prog junk2 i : main .foo ; . c q Trying to make this legal brings in a whole mess of possibilities, which someone address awhile ago with the idea of changing call to work like call (dbref string --- ? ) where dbref is the program # and string is the name of the function in that program that you want to execute. Using this methodology doing personal macros would be simple, but if someone does go this route, I would like to see something other then call used, just for the simple fact that I don't remember what I name the main procedure in my programs, and also to keep compatibility with older version.... 2. Sending strings to objects: This is very nice to have, and I have spent many night trying to come up with a simple, but effective method of handling this. If I remember right Chup did manage this using his publish idea in 3.0, but I don't know how well it worked, and I never did manage to get to play with it.... A few ideas and/or solutions I have come up with for this idea: 1. Swipe the code out of TinyMush (why write what is already done): Well, I am not truly familiar with Mush, and have not looked at the code, but from what I have heard the code for ahear and listen is not a pretty site. 2. I have implemented two macros .notify and .notify_except which take care of this in a simple manner, but it is still VERY restricted because you can't trap things like arrives, leaves, and field messages. This is only useful in the respect that it will make things flow when you want more one say/pose bug in the room. (like multiple vehicles) Also with this setup (under current restrictions) there are problems with permissions such that all programs in the ahear prop must be link_ok, and other things (that can be fixed) like when there are MASSIVE amounts of stuff in a room, you overflow the stack when notifing each item. But with this method you don't have to worry about infinate loops because you will eventually overflow the stack before things get too out of hand. In otherwords, this method is better then nothing, but it is by no means complete or even all that effective. 3. The following method has only been worked out in my mind as I do not have the resources to do any actual coding (in fact I don't even have a Unix account this semester) So I may have missed many possibilities and or problems. But what I was thinking of was something like in the notify_except function (and a change in notify) to notify all things in the room, and if an inanimate object has a certain prop (like listen) set it calls the program in that prop. To keep the program from looping you could use a single byte on the object (or program) that is incremented each time the program is called, and check the current counter against a preset limit, when ever the notify ends, it resets the counters (from a list of programs activated by the notify), and life continues as normal. This is nice because you can set the max number of call backs that you want, but still eliminate the infinate loop problem. Of course this solution breings into effect alot of other problems like being able to start execution of a new program while one is currently running (which messes with program frames, and I don't know much there) It also addeds some extra stuff like the activated program list, and the extra byte for each program. And I am sure there are many other things that I have missed in looking at the cons of this method, and I am sure there are ways around each of them, and maybe by presenting this idea to the folx out there we can come up with a workable solution.... 4. Programs in the succ, fail, and drop: I think you mean the osucc,ofail, odrop. Regardless, what is the use. It can all be done from the succ, fail, and drop, and if not what would the difference be? 5. Now, a wish list :) These are some of the things I would like to see (and yes I would be willing to help) implemented in future releases of TinyMuck (probably ver 3.0 and later as most of them are major workings) a: A working heartbeat function I don't know if the reason behind this not being implemented is because of a cpu cost, or just because no-one has the time/effort/caring to do it. I would assume that it is not too much more cost effective then LPmud would be (again I don't know the statistics on LPmud and its CPU drag) b: Some form of Disk-Based storage. I have been putting a little thought into to this one, but it would be a major rewrite, and in some cases could save you nothing. And if someone implements my idea, I would at least like a little credit if you get the idea from here. My proposal would be to give each user(builder) his own environment room when the character is created (or his builder flag is set) This environment would be the default for all his rooms. Now, when a player logs on his environment is loaded (the Global is loaded when the mud starts up). All objects are located in the environment of their location, and all exits in the environment of what they are attached to. Now when an environment is loaded, it is only done one deep for rooms. ie when the global is loaded, only rooms directly in the global environment are loaded (and all objects/exits in that room). All environments have a file of their own, and are loaded into the muck when either they are accessed via movement, or when a player logs on. Now, when environments are not in use (ie their owner is not on and there is noone in them, they are put in an old queue and swapped out as space is needed. The reason I like this idea is that it keeps locality at it optimum, and it has been done (in a conceptual way) in LPmud. It also enforces the use of player defined environments, and if the players are considerate enough, it should seriously reduce the virtual size of a muck. That way you shouldn't have to recycle a players stuff if he is never on, and noone ever uses it, it will be stored somewhere on disk instead. c: Multitasking, I am sure there are many reasons why this has not been implemented on a muck, but it would still be very nice to see it done while I seriously doubt that it will be since I assume it would be very costly. Well, that is about my um $10 worth :) Drazz'zt Blackfist From tinymuck-sloggers-owner Tue Mar 19 10:50:50 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14673; Tue, 19 Mar 91 10:35:11 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14669; Tue, 19 Mar 91 10:34:57 -0800 Message-Id: <9103191834.AA14669@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Tue, 19 Mar 91 13:34:53 -0500 Date: Tue, 19 Mar 91 13:34:51 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: def in programs Status: RO No, we don't need them... consider my proposal withdrawn. :-) From tinymuck-sloggers-owner Tue Mar 19 11:08:31 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14688; Tue, 19 Mar 91 10:46:59 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14684; Tue, 19 Mar 91 10:46:57 -0800 Message-Id: <9103191846.AA14684@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Tue, 19 Mar 91 13:46:54 -0500 Date: Tue, 19 Mar 91 13:46:52 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Resend Status: RO A clarification of something of my own: I didn't want to pass the W bit to called programs. What I wanted is this: If the current program is not set W, you may only call programs which are L or owned by the current user's or program's owner (depending on whether the program is S). If the current program is W, it _should_ be able to call even programs that are not L and that you don't own, but it doesn't seem to work that way. That's different from having the called program run with W permission; it should just run, and that's it. From tinymuck-sloggers-owner Wed Mar 20 01:12:21 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06372; Wed, 20 Mar 91 01:03:41 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06368; Wed, 20 Mar 91 01:03:36 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 20 Mar 91 09:01:59 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA18182; Wed, 20 Mar 91 09:02:36 gmt Message-Id: <9103200902.AA18182@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Clarifying clarity on WIZ programs Date: Wed, 20 Mar 91 09:02:36 GMT From: Mike Prudence Status: RO Howdy Sloggers. Recently regarding arromdee@server.cs.jhu.edu said: > A clarification of something of my own: I didn't want to pass the W bit to > called programs. What I wanted is this: If the current program is not set W, > you may only call programs which are L or owned by the current user's or > program's owner (depending on whether the program is S). > If the current program is W, it _should_ be able to call even programs > that are not L and that you don't own, but it doesn't seem to work that way. > That's different from having the called program run with W permission; it > should just run, and that's it. Actually it was jearls@eagle.calpoly.edu (Johnson M. Earls) who suggested that programs called by WIZ programs inherit the WIZ status. My apologies for lumping the two ideas together under the same title. Boy - it's tough to try and keep track of all this stuff !! Cheers, Mike mjp@hplb.hpl.hp.com "Lettuce ? What Lettuce ?" From tinymuck-sloggers-owner Wed Mar 20 01:42:22 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06317; Wed, 20 Mar 91 00:55:17 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06313; Wed, 20 Mar 91 00:55:14 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 20 Mar 91 08:53:37 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA18145; Wed, 20 Mar 91 08:54:15 gmt Message-Id: <9103200854.AA18145@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Security in TinyMUCK 2.2+ Date: Wed, 20 Mar 91 08:54:14 GMT From: Mike Prudence Status: RO Howdy Sloggers. Recently Lee Brintle said : > Without sounding like a broken record (okay, maybe sounding LIKE a > broken record), I'd like to see MUF tightened up from a security > standpoint before I see any additions or extensions to it. In my > opinion, MUF programs ought not be able to do anything that a user > cannot do, security wise. I'd actually forgotten all about security, as usual, mainly because running a MUCK inside HP is a good way to avoid having any of the problems that tight MUF security solves ! (lucky me) Having said that, I do see the need for some security measures, but at the same time, I don't think we should get too much away from the basic aim of this so-called '2.2+' release. As I see it, we're adding in already existing hacks and a few 'fairly' easy to do things. > We NEED a safe trigger @. In a big bad way. Thank you to whoever > pointed out "me" match; that was a great idea (I'm now not even going > to mention what I was doing before). I propose simply having three new words as follows :- o safe-me o safe-loc o safe-trigger o safe-program (if we have the 'program' variable) I guess the "me" match solution is a valid one, but doesn't that involve searching for something that the server knows pretty easily already ? > I'd like to see a new flag added to the server. If all the MUCK commands > are being moved to primitives, then we can do without the "BUILDER" flag. > I propose the "BACKSTAGE" flag (or "NUMBERS" flag, if BUILDER is loved > so much). If you are not set BACKSTAGE (the default), then database > numbers of objects you own or L|A objects do not appear on the display. > If you need the numbers, set yourself BACKSTAGE. There is nothing that > spoils the current virtual reality more than seeing a cryptic string > of numbers and flags after objects and rooms. I've been wanting this > flag for about a year now.... please? I'd like to see this flag too. What's the consensus on the loss of the BUILDER flag ? Does anyone use it much ? > If you all are interested, I still have my list of security changes that > I posted in December; to me, this is the most important change that > can be done to MUF/MUCK. You might care to repost that to the list, if only to refresh our memories (cursed DRAM brain :). BTW, have you actually implemented any of these changes yourself ? or is it all just on paper for the moment ? Whatever security enhancements we make, I'd like to see them put in as a compile time option for those of us who don't need the extra restrictions. Cheers, Mike/blip mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Wed Mar 20 09:12:25 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06750; Wed, 20 Mar 91 09:04:48 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06746; Wed, 20 Mar 91 09:04:45 -0800 Received: by eagle.calpoly.edu (4.1/2.890629) id AA06688; Wed, 20 Mar 91 09:02:16 PST Date: Wed, 20 Mar 91 09:02:16 PST From: jearls@eagle.calpoly.edu (Johnson M. Earls) Message-Id: <9103201702.AA06688@eagle.calpoly.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Clarifying clarity on WIZ programs Status: RO Yes, I would like to see programs that are called by wiz programs run under wiz permissions -- I use a lot of libraries that can't be set wiz on their own, but should have the permissions of the called program so that they can access all the same data. - John From tinymuck-sloggers-owner Wed Mar 20 09:42:25 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06780; Wed, 20 Mar 91 09:40:11 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA06776; Wed, 20 Mar 91 09:40:10 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Wed, 20 Mar 91 11:40:06 -0600 id AA26902 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Wed, 20 Mar 91 11:39:53 -0600 id AA20108 Date: Wed, 20 Mar 91 11:39:53 -0600 From: Lee Brintle Message-Id: <9103201739.AA20108@umaxc.weeg.uiowa.edu> To: jearls@eagle.calpoly.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Clarifying clarity on WIZ programs Status: RO I would NOT like this... it means that Wiz programs could never call any program on the system; it has no idea what that program is going to do. Just like I do not think that the SETUID should be inherited. From tinymuck-sloggers-owner Wed Mar 20 13:12:26 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07531; Wed, 20 Mar 91 12:49:24 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07527; Wed, 20 Mar 91 12:49:23 -0800 Received: by enet-gw.pa.dec.com; id AA09113; Wed, 20 Mar 91 12:49:12 -0800 Message-Id: <9103202049.AA09113@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Wed, 20 Mar 91 12:49:16 PST Date: Wed, 20 Mar 91 12:49:16 PST From: This message sent with 100% recycled bits 20-Mar-1991 1502 To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Security stuff... Status: RO o I use the builder flag -- but minimally. The Guest player on my Muck has no builder flag. Everyone else does. I'd like to have the builder flag still around, but it's not very useful. If there were another way for me to have a non-builder guest, then I'd be happy with that. o Again, passing the W bit to a called program is in my opinion wrong. As is passing the SETUID bit. These *must* be isolated from the called programs, or we should just hang up on all security whatsoever. To me, passing the W-bit is serious enough that I'd not use 2.2+ solely for this. o I use "me" match as a safe-me and don't care about the fact that it executes slowly (compared to just figuring it out). On my system, the Muck doesn't consume much CPU time at all. Memory, yes. Disk space, yes. CPU time, no. So I have no opinions one way or the other. o The seecurity stuff I've implemented works. We've been running with it since last Decemeber. I said it's rudimentary, and it is. It only limits access to the "information" words. (I also have a couple other things, like restrictions on ADDPENNIES). I enclose my note on the subject below. If people like the idea, then I can send the up-to-date code. To explain something, our WHO display shows the room someone is in and we use the ABODE flag on a player to mark them as "". I use the access function below to control access to information, and make sure that CONTENTS etc. obey dark rules. Other than that, by-and-large I agree with the proposal that Lee Brintle made last winter. My comments to his comments still stand, but we're in basic agreement. Jon ================================================================================ Note 94.3 Privacy 3 of 32 LILITH::CALLAS "I feel better than James Brown" 56 lines 19 December '90 11:23 -< Here's the new access rule. >- -------------------------------------------------------------------------------- I've gone and modified the way that magic works for the "information" functions in MUF. I've added two forms of protection, "strong" and "loose." The following functions need "strong" access: DESC, CONTENTS. The following functions need "loose" access: LOCATION, NAME, SUCC, FAIL, DROP, OSUCC, OFAIL, ODROP. Here's the function that describes access. The "loc()" function returns the room that the object is in (which is the object itself for rooms): int has_access(dbref player, dbref thing, int kind) { if (controls(player,thing)) /* It's ours. */ return 1; if (Dark(thing) || /* It's dark, */ Dark(DBFETCH(thing)->location) || /* carried by a dark person, */ Dark(loc(thing))) /* or in a dark room */ return 0; if (loc(player) == loc(thing)) /* you're in the same room */ return 1; #ifdef ABODE if (Typeof(thing) == TYPE_PLAYER /* It's an abode player */ && (FLAGS(thing) & ABODE)) return 0; #endif ABODE #ifdef HAVEN if (Typeof(thing) == TYPE_PLAYER /* It's a havened player */ && (FLAGS(thing) & HAVEN)) return 0; if (FLAGS(loc(thing)) & HAVEN) /* it's in a havened room */ return 0; #endif /* Loose access always succeeds from here */ if (kind == STRONG) { if ( (FLAGS(loc(thing)) & LINK_OK) || (FLAGS(loc(thing)) & JUMP_OK) || (FLAGS(loc(thing)) & CHOWN_OK) ) return 1; return 0; } return 1; } From tinymuck-sloggers-owner Wed Mar 20 13:42:26 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07592; Wed, 20 Mar 91 13:38:50 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA07588; Wed, 20 Mar 91 13:38:45 -0800 Received: by viper.calpoly.edu (4.1/2.890629) id AA05646; Wed, 20 Mar 91 13:36:12 PST Date: Wed, 20 Mar 91 13:36:12 PST From: jearls@viper.calpoly.edu (Johnson M. Earls) Message-Id: <9103202136.AA05646@viper.calpoly.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: More on wiz-bit calls. Status: RO How about adding in a primitive to pass priveleges along to a "secure" program? I.e. the "call" primitive will remain the same, but there would be a "scall" primitive that would pass the priveleges along to the called program. That way if you know a program is secure (for example, you wrote it), then you can do an "scall" to allow that program to inherit your priveleges. - John From tinymuck-sloggers-owner Wed Mar 20 18:12:28 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08657; Wed, 20 Mar 91 18:02:00 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA08653; Wed, 20 Mar 91 18:01:54 -0800 Received: by zia.aoc.nrao.edu (4.1/SMI-DDN) id AA16577; Wed, 20 Mar 91 19:01:51 MST Date: Wed, 20 Mar 91 19:01:51 MST From: dbriggs@zia.AOC.NRAO.EDU (Dan Briggs) Message-Id: <9103210201.AA16577@zia.aoc.nrao.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: macro processor, namespaces, primitives Status: RO Regarding local macro definitions: >No, we don't need them... consider my proposal withdrawn. :-) Yes we do!! The kludge we currently have has been bugging me a long time, but I've mostly managed to work around it. First of all, one primary use for macros is symbolic constants. I will concede that #define MAGIC 12648430 : MAGIC 12648430 ; are fairly similar, from a speed perspective. The first form is a little faster, but not enough that you'd notice. (Besides, MUF has never been a language for speed demons in the first place.) But does anyone other than me find the latter form incredibly ugly? What we really need is a macro processor that is just a little bit smarter. I can live without function arguments and compile time logic, but I would *really* like an #ifdef. I want to be able to write #define SYS_MBONGO ( for my code on MBongo, of course ) #ifdef SYS_XR .pmatch ( this is similar to what I've used before ) #elifdef SYS_MBONGO "*" swap strcat .pmatch ( but invented as I write ) #else .pmatch ( try anyway, but bitch ) "I don't know this system" me @ swap notify #endif BTW, I *do* write like this, since my own programs are automatically preprocessed with cpp, as I upload it. This isn't a very good solution, though, since it makes my programs harder to read on the MUCK side of things, and I can't do it when I team program. I'd much prefer to see it built into the language. Since it seems that all the macro stuff involves a leading '.', I guess that it would make sense for the macro control stuff to start with '.' as well, although frankly I'd prefer '#'. Thus, I propose: .define .undef .ifdef \ .elifdef | conditional compilation does what you think it does .else | .endif / (yields replacement string) . (also yields replacement string) A null replacement string for .define will result in a null replacement text, but will test true for the purposes of .ifdef. I'd suggest that .defining an existing macro *not* be an error, but I'm flexible on that point. .undef should never return an error, whether or not it finds the token. We gain a little convenience at slightly higher risk of typoes. There is no conflict with the global def, since one occurs in program text, and the other at the editor command level. I don't see any conflicts there. Anyone? The only one of the above commands that is sensitive to line breaks is .define. With the long line lengths that are allowed on MUCKs, I don't see the need for a continuation character. Anyone really want a "\"? All of the above will be normal space delimited tokens, with no requirement about being at the beginning of a line. We should probably make these six tokens reserved to the language, and bitch about it if anyone tries to redefine them. Of the six, though, only .undef really *needs* to be reserved. Opinions, anyone? While I'm on the subject of reserved names, it really bugs me that the preprocessor has to have a leading '.' to recognize a macro! This is a kludge of the first magnitude. What should happen, is that the compiler should test each and every token it gets, in the following order, against 1) The local namespace. This includes both user defined functions and locally defined macros. We simply expand the currently used rule of 'most recently defined' gets precedence. 2) The global (macro) namespace. 3) The primitive namespace. 4) Literal space, (that is, try to interpret the token as a literal number or string or dbref.) If it falls through the above without a hit, it should bitch about the undefined token. As the situation stands now, btw, you are allowed to define a function with the same name as a primitive or literal, but later definitions can't see it! They compile with the primitive or literal instead. The namespaces are definitely being searched in the wrong order! Also as it stands now, you are *not* allowed to define a name that starts with a '.'. (You can't define a name that starts in ", either, but I'm less upset about that.) For old forth folk like myself, this is a real pain in the neck. Note that MUCK already has reasonable hash table functions in it, and these are used to search the primitive name space. Since we are already going to the trouble of computing the hash function on each token, it is a very minor performance hit to check three hash tables (with the same key) instead of the one and a half that is done now. In the interests of backwards compatibility, I suppose that the compiler should make an intelligent guess when it finds a token which starts with '.'. When presented with the token ".foo", I suggest that it check for the old style global macro "foo" between steps 2 and 3 above. (That is, strip the leading '.', and search the global namespace again.) This would allow existing programs to compile unchanged. I think I might have a reasonable chance selling you people on what I've said just now, since it is all essentially backwards compatible. Anything it breaks shouldn't have worked in the first place. There's one more place that the language is wedged, as far as namespace problems goes, but I doubt that it will be fixed. That's the way that we recurse. There is no way to redefine an existing function in terms of itself. For instance, on a forth-83 (like) system, I could write ( debugging version ) : + ( i1 i2 -- i1+i2 ) over "Arg 1:" swap intostr strcat " Arg 2:" strcat over intostr strcat me @ swap notify + ; Every function that uses '+' and is compiled after this thing, will print out its arguments before it does the add. With MUF, of course, I will just recurse and eventually run out of return stack space. The forth solution was to make identifiers invisible to to the namespace search (SMUDGEd, in the jargon) until the definition was completed by the ';'. There was a separate primitive, recurse, which jumped to the definition being compiled. I think that's a much more elegant solution, but it would break any MUF program that uses looping. Keep it in mind, though, and maybe when MUCK 3.0 breaks all out programs anyway, we can slip this little change in during the general chaos. As far as primitives go, I highly support making as many operators as possible, (and all of the comparison operators in particular) sensitive to the type of their argument. #3 #5 < should definitely return true! As it stands know, half the operators are overloaded, and half aren't it's quite a chaotic situation. *Everything* should make an intelligent decision as far as forced type conversion is concerned. For instance, I think it would be nice if 6 "3" / returned 2, but I'll admit that this is a pretty extreme example. Note that if you force strings into this model, (and I think you should) we will still need a few more primitives just for strings, since strings are intrinsically more complicated animal that integers. I would suggest that strcmp and stringcmp be retained, in addition to teaching the comparison operators to grok strings. (Maybe make = do a case insensitive comparison, since that seems to be the most common MUD case?) You might want to consider making int return the ASCII value of the first character. As a last parting shot, has anyone suggested 'depth' yet? It would return the number of items on the stack, before the primitive is executed. Just stirring the waters a bit, --- Daniel Briggs (dbriggs@nrao.edu) [aka Gazer] New Mexico Tech / National Radio Astronomy Observatory P.O. Box O / Socorro, NM 87801 (505) 835-7360 From tinymuck-sloggers-owner Wed Mar 20 20:42:29 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA15646; Wed, 20 Mar 91 20:36:04 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA15642; Wed, 20 Mar 91 20:36:02 -0800 Message-Id: <9103210436.AA15642@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Wed, 20 Mar 91 23:35:58 -0500 Date: Wed, 20 Mar 91 23:35:56 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: setlink Status: RO OK, imagine you're Hurin. :-) Create a program which links an exit to a bogus "say" program, then make a room where entering it runs that program. You could also stick it on the "out" exit. You might want to trap "examine" too; the first time it recycles the bug, says 'I don't see that here', and then recycles itself. Synth handled this sort of thing by requiring all programs to be setuid, and a waizard was needed to un-S them. LPmud just ignores the problem, though it's not quite as bad in the first place. What do we do? From tinymuck-sloggers-owner Thu Mar 21 02:12:31 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA18904; Thu, 21 Mar 91 01:54:09 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA18900; Thu, 21 Mar 91 01:54:02 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 21 Mar 91 09:52:15 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA22858; Thu, 21 Mar 91 09:52:51 gmt Message-Id: <9103210952.AA22858@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: WIZ Programs Date: Thu, 21 Mar 91 09:52:50 GMT From: Mike Prudence Status: RO Howdy Sloggers. Recently jearls@eagle.calpoly.edu (Johnson M. Earls) said: > Yes, I would like to see programs that are called by > wiz programs run under wiz permissions -- I use a lot > of libraries that can't be set wiz on their own, but > should have the permissions of the called program so > that they can access all the same data. Sounds like a compile time option to me, folks. Any objections ? Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Thu Mar 21 03:12:31 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19000; Thu, 21 Mar 91 03:11:12 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA18996; Thu, 21 Mar 91 03:11:09 -0800 Received: by churchy.gnu.ai.mit.edu (5.65/4.0) id ; Thu, 21 Mar 91 06:11:49 -0500 Date: Thu, 21 Mar 91 06:11:49 -0500 From: rearl@gnu.ai.mit.edu (Robert Earl) Message-Id: <9103211111.AA01828@churchy.gnu.ai.mit.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: catching up Status: RO My accounts on the UCR NeXTs have been down for repair and it's sent all my sloggers mail bouncing for a while now. I just read the archive on belch to catch up, and I only have a few things to say in response, mainly to Drazz'zt, who said: | [ ... ] But the one | possibliity that I was thinking of was being able to call program macros | from a called program. (eg. | @prog junk1 | : .foo bar ; | : main junk2 call ; | . | @prog junk2 | : main .foo ; | . Well, (maybe I'm not reading you right?) you can call an arbitrary function from a CALLed program; like so: @prog junk1 : predicate "yes" strcmp not ; : main 'predicate junk2 call .tell-me ; . @prog junk2 ( a -- s ) : main "no" swap execute if "Wrong!" else "Right." ; . So junk2 is calling `predicate' in junk1. You could stick an address in a variable too, just not a property :-) I was working on mechanisms for safe function lookup from a string or something similar in 3.0, so you could, essentially, put a function in a property. About 3.0's CALL: first I made it (d s -- ?) then I realized I could make it completely intelligent about its arguments, so I made it EITHER [old] (d -- ?) or [new] (d s -- ?) so if it was called the old way, it'd default to the main word. (I think the main word of every program was `published' too..) About new flags, sending strings to objects, etc, why not just make MUF capable of handling such things, which could introduce lots of new possibilities, instead of patching in a flag or something? That's what mush does, and look at the mess of code and versions it's created. Ewww. --chupchup From tinymuck-sloggers-owner Thu Mar 21 03:42:31 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19033; Thu, 21 Mar 91 03:36:18 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19029; Thu, 21 Mar 91 03:36:10 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 21 Mar 91 11:34:30 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA23090; Thu, 21 Mar 91 11:35:08 gmt Message-Id: <9103211135.AA23090@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK 2.2+ - Ewww. Date: Thu, 21 Mar 91 11:35:07 GMT From: Mike Prudence Status: RO Hi all, That last message from ChupChup has set me thinking. Maybe we should put some effort into moving commands out of the server and into MUF in the global environment ? What do y'all think ?? This then leads us onto the question : What extra stuff (primitives and server mods) do we need to be able to do this ? More grist for the mill. Cheers, Mike/blip mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Thu Mar 21 07:42:33 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19401; Thu, 21 Mar 91 07:30:33 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19397; Thu, 21 Mar 91 07:30:30 -0800 Received: by thesisa.hsch.utexas.edu (5.57/Ultrix3.0-C) id AA08394; Thu, 21 Mar 91 09:31:48 -0600 Date: Thu, 21 Mar 91 09:31:48 -0600 From: snewton@thesisa.hsch.utexas.edu (Steven E. Newton) Message-Id: <9103211531.AA08394@thesisa.hsch.utexas.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: TinyMUCK 2.2+ - Ewww. Status: RO Date: Thu, 21 Mar 91 11:35:07 GMT From: Mike Prudence Hi all, That last message from ChupChup has set me thinking. Maybe we should put some effort into moving commands out of the server and into MUF in the global environment ? What do y'all think ?? Alright, I'll quit lurking long enough to bite. YES absolutely we should be moving stuff OUT of the server and into MUF. This was (it seemed to me) the whole point of the direction Chup was taking MUCK/MUF. Lessee, can we get the server down to interface.c, compile.c and interp.c? Maybe not, (maybe that's just too silly to even joke about) but the more we can move to MUF, the more it will be possible for each site to customize, WITHOUT a dozen compile-time options. This does mean that absolutely a minimal set of programs and macros must be provided in the distribution. Think of it as the MUF equivalent of what's in /bin when you first boot Un*x. CookieMonster + + + + + + + |snewton@thesisa.hsch.utexas.edu Beatitscramgoawaytakeahike -- Oscar the Grouch |Nobody else speaks for me, |and I speak for no one else. | + + + + + From tinymuck-sloggers-owner Thu Mar 21 09:42:34 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19551; Thu, 21 Mar 91 09:20:50 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19547; Thu, 21 Mar 91 09:20:42 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Thu, 21 Mar 91 17:18:38 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA23811; Thu, 21 Mar 91 17:19:15 gmt Message-Id: <9103211719.AA23811@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK 2.2+ - Global Environment Commands Date: Thu, 21 Mar 91 17:19:14 GMT From: Mike Prudence Status: RO Hi all, Well, a bit more thought out loud, to see if this idea has any merit. First off, do we pay an obscene efficiency penalty by moving stuff out of the server and into MUF based commands ? Below I've gone through all (I think) the MUCK commands, and had a little think about what we need to implement them in MUF. I'd like to use this as a springboard for discussion, if we can. If, on the other hand, you think this is a waste of time, tell us. All opinions welcome. At a guess, I would think we could split the MUF coding up between five or so people without too much of a load. [I've got the MUCK manual in front of me, and I'm just gonna run down the primitives] The Old '@' Commands -------------------- (What's the @ for anways, Chup ??) @action @attach @open Need to be able to create an action/exit and attach it to an object. One primitive might do the job, although it might be better to have two - one to create, and one to attach. newexit/newaction (str -- dbref ) attach (dbref dbref -- result) Is there a real difference between actions and exits ?? @boot @dump @edit @force @list @newpassword @password @pcreate @prog @shutdown @stats @toad @trace These fall into a class I would call 'system' functions. Some could be taken out of the server (for instance password stuff) but I would like to think about the securityu implications of it all first. As for the MUF editor ?? I use emacs and download, so maybe just an easy mechanism to 'open' a program for downloading is needed. On the other hand, we have the editor, so why mess with it ? @chown Just need a CHOWN primitive for this. @create Need a primitive to create an object, and set it's cost. BTW, do we need to give things costs anymore ?? Is it time to revise the penny ? Could we put my electronic funds transfer MUF system in to the default MUCK database instead ?? @dig Need newroom primitive. @describe @drop @fail @find @odrop @ofail @osuccess @owned @set @success @teleport @wall These I think we can do today without too much sweat. @link @unlink Need setlink for this, with multiple destinations too. @lock @unlock Need the lock manipulation primitives to do this one. @name We need to extend the setname primitive to allow us to give a password. @recycle Need the recycle primitive. The Other Commands ------------------ drop/put/throw - we could change these to do slightly different things examine get/take give - could be extended to work with objects goto/move gripe inventory - could be a lot more creative than it is now kill - the adventurous could imagine a combat system inserted here look/read page pose rob say score whisper WHO These I think we can do with a minimum of difficulty. Certainly it would allow us to beef up a lot of these things. For instance, we could maybe put in a weights system so that get and drop become weight related. All sorts of possibilities. help man news quit Again, system commands that I am not sure we should take out of the server. Unless we put in primitives to allow UNIX file access (check the security implications, someone) I think there is not a lot we can do here. outputprefix outputsuffix I've never used these, but I could see them being munged in with the 'say' stuff pretty easily. All in all, I am thinking this is a spiffing idea. I'm waiting for someone to tell me it won't work (isn't that always the way ?). Until then, I think this might be a good area to mark as a differentiator between 2.2 and 2.2+. We must be compatible with 2.2, but I don't think we'd hurt anything too much by doing these mods. One problem might be the size of the interp.c switch. Certainly I've had size problems with this on a lesser brained machine than my own workstation. Maybe we could split it ?? More food for thought. Cheers, Mike/blip mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Thu Mar 21 10:12:34 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19664; Thu, 21 Mar 91 09:56:10 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19660; Thu, 21 Mar 91 09:56:09 -0800 Received: by newcory.Berkeley.EDU (5.57/Ultrix3.0-C) id AA04811; Thu, 21 Mar 91 09:56:06 -0800 Date: Thu, 21 Mar 91 09:56:06 -0800 From: cwong@newcory.berkeley.edu (Conrad Wong) Message-Id: <9103211756.AA04811@newcory.Berkeley.EDU> To: snewton@thesisa.hsch.utexas.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: TinyMUCK 2.2+ - Ewww. Status: RO My personal theory is that if you're going to have everything done in MUF, you're going to have to expect the consequent slowdown-- you're running an interpreted language here, even if it *is* compiled to tokens-- you didn't seriously think it compiled MUF programs to binaries, did you?... On the other hand, customizing things is nice... UnterMUD's approach, as you know, is to allow direct server hacking in an easily handled way so that it's easy to change the server for mods. -- Lynx From tinymuck-sloggers-owner Thu Mar 21 10:42:34 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19702; Thu, 21 Mar 91 10:34:14 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA19698; Thu, 21 Mar 91 10:34:13 -0800 Received: by enet-gw.pa.dec.com; id AA03414; Thu, 21 Mar 91 10:33:55 -0800 Message-Id: <9103211833.AA03414@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Thu, 21 Mar 91 10:34:01 PST Date: Thu, 21 Mar 91 10:34:01 PST From: This message sent with 100% recycled bits 21-Mar-1991 1326 To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Compiler optimizations and a bug... Status: RO A bug someone found for me last night: In a description that is @12345, if that number is bogus, the game may crash. It did for me. The fix is simply to test "i" in "exec_or_notify" to be between 0 and db_top. About doing more in MUF: My only objection to that is that it takes a *long* time for my game to start up. We have 20K objects, and around 900 programs. It takes about 30 minutes to start up, and most of that is spend compiling programs. Has anyone looked at modifying things so that a program isn't compiled until it's used? It's on my list of things to do, but I've not persued it very far. Anyone have ideas on how hard this would be? Jon From tinymuck-sloggers-owner Thu Mar 21 12:12:35 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA21124; Thu, 21 Mar 91 11:50:49 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA21120; Thu, 21 Mar 91 11:50:47 -0800 Received: by soda.Berkeley.EDU (5.61/CHAOS3) id AA10478; Thu, 21 Mar 91 10:49:50 -0900 Date: Thu, 21 Mar 91 10:49:50 -0900 From: Jon Blow Message-Id: <9103211949.AA10478@soda.Berkeley.EDU> To: cwong@newcory.berkeley.edu, snewton@thesisa.hsch.utexas.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: TinyMUCK 2.2+ - Ewww. Status: RO Conrad writes: > you're going to have to expect the consequent slowdown... Yes, well writing things in higher-level languages produces very inefficient code, but that doesn't keep us writing in ML for everything we do. From tinymuck-sloggers-owner Thu Mar 21 14:12:36 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22018; Thu, 21 Mar 91 13:48:58 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22014; Thu, 21 Mar 91 13:48:55 -0800 Received: from UNLVM.BITNET by lilac.berkeley.edu (5.64/1.16.28) id AA12925; Thu, 21 Mar 91 13:48:49 -0800 Message-Id: <9103212148.AA12925@lilac.berkeley.edu> Received: by UNLVM (Mailer R2.07) id 7503; Thu, 21 Mar 91 15:44:42 CST Date: Thu, 21 Mar 91 15:20:23 CST From: Drazz'zt Subject: Some general thoughts..... To: TINYMUCK-SLOGGERS@belch.Berkeley.EDU Status: RO Chup, I think you are doing the same thing I was describing... But I didn't think that I could use execute as a primitive in 2.2 (guess there still is alot of stuff I don't know about in MUF :) Anyway, I will have to play with that now that I know about it :) As for strings to objects, yeah, to do it in muf would be execellent, and I still want to play with how you did it in 3.0, but I guess that will have to wait. Whoever was having the long wait for the muck to load... Sounds to me like you are having serious problems, when Pegasus was running well, we had 25K objects, and 1.3K programs, and it never took more then 10-15 minutes to bring it up, and about 2-5 minutes for a dump. Unless you are running on a small machine, you may have problems somewhere (Of course I have been wrong before :) Some general comments on putting things from the server into Muf. I like the concept, in fact that is one of MOO's strongest points. But as several people have pointed out, you will lose some responce time in doing so, as an extreme case take a look at DBLOOP(used in 3.0) and a simple program that searches the DB. Anyway, Chup was to my understanding taking all primitives out of the switch and putting them into seperate function calls I don't know if this helped speed things up noticably or not, but one idea would be to move MUF into a LEX or FLEX based format (I know yet another major rewrite, and I am definately not qualified for this even if I had the resources), and I don't know how much this would actually speed things up anyway (other then maybe the compile time, which really isn't that big, but I thought I would mention it anyway) Also on the mention of Kill and weight in general. I don't think that the weight idea would be a good one, but this is based solely on my idea of what a Tiny* is. I look at Tinys as mainly entertainment, not actually a game per se, but just fun. I don't want to get into what tinys are, this topic was flogged to death on r.g.m. But in a true sense I think Abers and LPs would qualify as games (they have a distinct goal). While TInys would qualify as entertainment because they are fun to play with, but there really is not set goal to achieve other then having a good time building, Mufing, or socializing. But anyway to put weight on objects would only restrict the way things are done, and not really add anything to the fun (IMHO). As for killing, it is my belief that to do this you should do it right, and that would mean some form of a timing function like heart_beat in LPs. And while the capability is there via cronos, it is still very limited because it is my experience that when cronos is presented with a barrage of commands, he will lose some. Also cronos being a seperate entity he is not garunteed 100% availablity whenever the muck is up (I realize this is the responsibility of #1 or whoever starts up the muck) but he has been known to die off upon rare occassion and if you are going to rely on him as a timing daemon, he should be reliable. As for combat in general, I have written a combat system (but never opened to the public so I am sure it has bugs, is somewhat of a kludge, and has several loopholes). But I fluctuate in my view on this I wrote it because I wanted to see if it could be done, and I thought it would be neat, but it pales in comparison to LP's (obviously), and I doubt that it could even give MOO's system any compition (although I have not actually played with this). So I guess what I am saying is that using the current resources on a Muck, I really don't think that a 'serious' combat system would be either feasible, reliable, or practicle. But if you can prove me wrong I would LOVE to see it as I have always been infatuated with combat systems. And one last thing, to whoever mentioned "me" match as a valid form of a safe me @, THANK YOU!!!! As someone else had said, I don't even want to mention what kind of messy, ugly, unreliable, kludge of a system I was using. Drazz From tinymuck-sloggers-owner Thu Mar 21 17:12:37 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24546; Thu, 21 Mar 91 16:59:47 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24542; Thu, 21 Mar 91 16:59:44 -0800 Received: from localhost (stdin) by snow.white.toronto.edu with SMTP id 28707; Thu, 21 Mar 91 19:58:43 EST To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Compiler optimizations and a bug... In-Reply-To: 's message of Thu, 21 Mar 91 13:34:01 -0500. <9103211833.AA03414@enet-gw.pa.dec.com> Date: Thu, 21 Mar 91 19:58:30 EST From: Chris Siebenmann Message-Id: <91Mar21.195843est.28707@snow.white.toronto.edu> Status: RO | A bug someone found for me last night: | In a description that is @12345, if that number is bogus, the game may | crash. It did for me. The fix is simply to test "i" in | "exec_or_notify" to be between 0 and db_top. This points out the crying need for a 2.2+ that is simply a collection of bugfixes for 2.2, as this bug was found and fixed informally shortly after 2.2 was released for the first time. I think ChupChup was at one point working on a 2.3 that was only to have bugfixes, but it doesn't seem to have materialized. - cks From tinymuck-sloggers-owner Thu Mar 21 19:42:48 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27428; Thu, 21 Mar 91 19:36:14 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27421; Thu, 21 Mar 91 19:36:09 -0800 Received: by volga.Berkeley.EDU (5.57/Ultrix3.0-C) id AA26426; Thu, 21 Mar 91 19:35:19 -0800 Date: Thu, 21 Mar 91 19:35:19 -0800 From: c188-aj@volga.berkeley.edu (Doug Orleans) Message-Id: <9103220335.AA26426@volga.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Potpourri Status: RO There are many things which need to be done to TinyMuck to make it better, like writing all the system commands in MUF, making it more object-oriented (i.e., message passing), etc. However, I think the whole point of doing a 2.2+ is to put together all the little things that people have done to change 2.2. These big kinds of changes should be put into a 3.0. We definitely need an official test site for 2.2+. I really can't judge a feature that I haven't played around with directly. In the beginning we had Atlantis, then we had ChupMuck; both are now defunct, and the closest thing we have to an official site is Mbongo, just because it's been a Muck since Atlantis was around. Unfortunately, Mbongo isn't up very often, and when it is, it's pretty slow. Mike, I guess your Muck is out of the question. Any volunteers? By the way, Mike, when you say you don't have to worry about security issues, is it because all the players are employees of yours, and you can just fire anyone who screws around with the Muck? I don't see how being a "closed" muck eliminates security problems. What to stop people from spamming the db? Speaking of security issues, I used to be in favor of a tiered system of access to certain words. Now I think that we shouldn't let security issues get in the way of finishing Muck (face it, it is definitely in an unfinished state). I would rather see a Muck that had lots of neat features and an integrated system with only an honor code for security, than a Muck crippled by too much emphasis on being "safe". I think the best way to be secure is to trust your Muckers, and toad anyone who abuses this trust. Once we finish Muck, then we can put in a complete security system. footnote: chupchup sez: > About 3.0's CALL: first I made it (d s -- ?) then I realized I could > make it completely intelligent about its arguments, so I made it > EITHER [old] (d -- ?) or [new] (d s -- ?) so if it was called the old > way, it'd default to the main word. (I think the main word of every > program was `published' too..) How can it be intelligent about its arguments? What if the user wants to use the "old" call, but happens to have a string on the stack that happens to be the name of a word defined in the program he calls? Forth words should never have variable number of arguments. footnote^2: Am I the only one who is bothered by the fact that "drop" is not the same as "pop"? Maybe we should be uniform and have "get*" retrieve the "*" field, be it desc, succ, drop, etc. Better yet, let's move all the fields into p-lists!!!! please? This was a major part of 3.0, I think, and it really would be easy to do, I think. footnote^3: The @ symbol is for distinguishing system commands from verbs in the VR. The fewer the better, in my opinion. That's my biggest beef against Mush. WhiteRabbit A head of lettuce From tinymuck-sloggers-owner Fri Mar 22 06:13:37 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03763; Fri, 22 Mar 91 05:57:45 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03759; Fri, 22 Mar 91 05:57:44 -0800 Received: by soda.Berkeley.EDU (5.61/CHAOS3) id AA17494; Fri, 22 Mar 91 04:57:33 -0900 Date: Fri, 22 Mar 91 04:57:33 -0900 From: Jon Blow Message-Id: <9103221357.AA17494@soda.Berkeley.EDU> To: dbriggs@zia.aoc.nrao.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: macro processor, namespaces, primitives Status: RO > As a last parting shot, has anyone suggested 'depth' yet? It would > return the number of items on the stack, before the primitive is > executed. This is only useful either in very very very simple programs or in very very very complex programs. In either case, it is not needed, and is merely a tool with which to write more obfuscated forth. From tinymuck-sloggers-owner Fri Mar 22 07:43:38 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03798; Fri, 22 Mar 91 07:26:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03794; Fri, 22 Mar 91 07:26:25 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 22 Mar 91 15:24:44 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA26406; Fri, 22 Mar 91 15:25:24 gmt Message-Id: <9103221525.AA26406@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Re: TinyMUCK 2.2+ - Ewww. Date: Fri, 22 Mar 91 15:25:23 GMT From: Mike Prudence Status: RO Howdy Sloggers. Recently Jon Blow said: > Conrad writes: >> you're going to have to expect the consequent slowdown... > Yes, well writing things in higher-level languages produces very > inefficient code, but that doesn't keep us writing in ML for everything > we do. Well, we expect a slowdown, but sometimes there's slowdowns and there's s..l..o..w..d..o..w..n..s. I run my MUCK on a fairly powerful machine (HP 9000/835). I use a general descriptions program (soon to be released to you lot, BTW) for a lot of descriptions, and can't say that I ever noticed a speed difference between it and a regular description. I do notice that my program 'who' commands runs a lot slower than the builtin 'WHO' command, but not enough to make me curse and swear about it. It runs slower because of the DB search involved. Put another way, if making everything MUF results in doubling the amount of CPU time taken to perform a command, will I actually notice ? Is the CPU the bottleneck or is it the network ? Is double 3us worth worrying about ? Obviously, MUF-based command sets are the way to go. We could use 2.2 to lay a foundation for later versions - get all the easy commands done. We could even say "Look - we'll leave the server as it is, but here's a MUF library that can replace 70% of all the builtin commands." That would then suit both camps, and allow us to actually measure whether having MUFized commands is a performance hit that is too large to live with. On the other hand, it might start us thinking about optimizing the MUF interpreter (I don't know how efficient it is at the moment - for all I know, it could be the best in the universe !). Personally speaking, I am going to try MUFizing a lot of stuff anyway, if only to add functionality for my users. Yours clarifyingly, Mike/blip mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Fri Mar 22 08:04:33 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03815; Fri, 22 Mar 91 07:40:47 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03811; Fri, 22 Mar 91 07:40:43 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 22 Mar 91 15:38:51 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA26429; Fri, 22 Mar 91 15:39:32 gmt Message-Id: <9103221539.AA26429@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Re: Some general thoughts..... Date: Fri, 22 Mar 91 15:39:31 GMT From: Mike Prudence Status: RO Howdy Sloggers. Recently Drazz'zt said: > As for strings to objects, yeah, to do it > in muf would be execellent, and I still want to play with how you did it in > 3.0, but I guess that will have to wait. How did you do it in 3.0, ChupChup ? Did I miss that one ? > Whoever was having the long wait for the muck to load... Sounds to me like > you are having serious problems, when Pegasus was running well, we had 25K > objects, and 1.3K programs, and it never took more then 10-15 minutes to > bring it up, and about 2-5 minutes for a dump. Unless you are running on a > small machine, you may have problems somewhere (Of course I have been wrong > before :) I found that unless I defined the DB_DOUBLING flag in the Makefile, I ran into this sort of problem (amongst others). This might be worth a try if you are not using it already. > Also on the mention of Kill and weight in general. I don't think that the > weight idea would be a good one, but this is based solely on my idea of what > a Tiny* is. I look at Tinys as mainly entertainment, not actually a game > per se, but just fun. Sorry - I obviously got the wrong mesage across, here. My suggestion is that we could provide a different set of basic functions, as they are so easily changed. If you wanted to run your MUCK with the weight extensions, all you had to do was load in the relevant MUF programs for the global commands that differ. I certainly don't want to force people to use more complex systems if all they want is to chat. > ...cronos, ... is still very limited because it is my experience that > when cronos is presented with a barrage of commands, he will lose some. I've not done a destruction test on this one, so I can't comment. I certainyl do agree that some sort of timed execution is needed in the server, and I think I might know roughly how to do it (put in a queue of programs to be executed in the future, with an alarm set for when the next program should be sent out). > combat in general, I have written a combat system (but never opened to the > public so I am sure it has bugs, is somewhat of a kludge, and has several > loopholes). Is this written in MUF ? Could you post more details of your method, or just mail 'em to me. Combat is one of the next things on my list to implement in MUF, and I'd like to see what some other people have tried, and why it didn't work. > I don't think that a 'serious' combat system would be either > feasible, reliable, or practicle. I would like to prove you wrong on that one. Again, I have not looked at it in depth, but I think it is just a case or working out what server functions are needed, and adding them in. Certainly timing of some sort, and probably a whole host of support functions for descriptions and stuff. It is not a trivial thing to program. More fuel for the fire. Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Fri Mar 22 08:13:38 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03826; Fri, 22 Mar 91 07:54:39 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03822; Fri, 22 Mar 91 07:54:35 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 22 Mar 91 15:52:55 GMT Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA26445; Fri, 22 Mar 91 15:53:35 gmt Message-Id: <9103221553.AA26445@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Re: Potpourri Date: Fri, 22 Mar 91 15:53:34 GMT From: Mike Prudence Status: RO Howdy Sloggers. Recently c188-aj@volga.berkeley.edu (Doug Orleans) said: > However, I think the whole point of doing a > 2.2+ is to put together all the little things that people have done to > change 2.2. These big kinds of changes should be put into a 3.0. Agreed !! However, and something I just thought of, we should keep a weather eye on 3.0 to see if we can move up the slope a little now. Functionality /|\ 3.0 | | 2.2+ <- put it here, I think | | 2.2 | | 2.1 +-------------------------------------------.....---------> time > We definitely need an official test site for 2.2+. I really can't judge a > feature that I haven't played around with directly. > Mike, I guess your Muck is out of the question. Any volunteers? Unfortunately yes. I don't have a machine that I could make externally available, certainly not just for playing MUCK on. > By the way, Mike, when you say you don't have to worry about security > issues, is it because all the players are employees of yours, and you can > just fire anyone who screws around with the Muck? I don't see how being a > "closed" muck eliminates security problems. What to stop people from > spamming the db? Ah - a digression. People not interested in the history of HP internal MUCKs can skip the next paragraph or three. HP has two internal MUDs - mine (VenueMUCK, UK based) and one run in the US (ChaosMUCK - predates the other Chaos, too). Chaos started out as an original TinyMUD about the same time that Classic was started. It slowly caught on, but was mutated by the owner with various server hacks. The DB format was changed, which was a major mistake. They also decided to hand out wizard bits to all their friends, which makes life amusing sometimes, but annoying at other times. When TinyMUCK 2.1 came out, I snarfed it 'cos I was interested in the idea of a programmable MUD. I put it up for my own use, but then was persuaded to make it available HP-wide. A 6 month honeymoon followed, when we had a lot of people playing, all creating programs and gadgets. It allowed me to develop the infrastructure (transport, banking, etc) and we all had a lot of fun. Chaos then went MUCK, although they hacked in their DB changes too (poor fools). Venue declined, because most people decided that what they wanted was somewhere to chat. Exploring and programming was for the minority. Venue went to 2.2 without a murmur. Chaos is still 2.1 (hacked) and will probably stay that way forever. Today, VenueMUCK ticks over - it is the place to go to find new features and MUF programmers, but there are only about 5 or so regular players. We're quietly keeping busy, though. For some reasons, which I can only put down to the sort of people that HP recruits, we don't get DB spammers, jerks or other obnoxious people making life hell for the rest of us. The worst we had was someone writing a bug program, and planting it on someone else. The offender capitulated, and stopped playing MUD a short while later. > I think the best way to be secure is > to trust your Muckers, and toad anyone who abuses this trust. Once we > finish Muck, then we can put in a complete security system. Easy for me to agree to that one, although I think we should put in some of the security suggestions, albeit as compile time options, though. > Better yet, let's move all the > fields into p-lists!!!! please? This was a major part of 3.0, I think, and > it really would be easy to do, I think. Is this easy to do ?? Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Fri Mar 22 10:43:39 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04080; Fri, 22 Mar 91 10:39:28 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04076; Fri, 22 Mar 91 10:39:27 -0800 Received: by enet-gw.pa.dec.com; id AA03286; Fri, 22 Mar 91 10:39:15 -0800 Message-Id: <9103221839.AA03286@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Fri, 22 Mar 91 10:39:21 PST Date: Fri, 22 Mar 91 10:39:21 PST From: "That's me in the spotlight, losing my religion. 22-Mar-1991 1303" To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Compile-load-and-go Status: RO Well, I did it last night. I sat down and made Muck work so that none of the programs are loaded and compiled upon system startup -- it's deferred to the first execution of the program. Would someone like me to send in these changes? They're actually rather simple, and might make people happy for 2.2+ Jon From tinymuck-sloggers-owner Sat Mar 23 17:43:51 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA09020; Sat, 23 Mar 91 17:19:11 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA09016; Sat, 23 Mar 91 17:19:08 -0800 Received: by eagle.calpoly.edu (4.1/2.890629) id AA01395; Sat, 23 Mar 91 17:16:41 PST Date: Sat, 23 Mar 91 17:16:41 PST From: jearls@eagle.calpoly.edu (Johnson M. Earls) Message-Id: <9103240116.AA01395@eagle.calpoly.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: LOCAL VARIABLES!!! Status: RO How about a way to declare local variables as well as the current global variables? Something like: LVAR MyVar ( MyVar will only be available to this program ) VAR GlobVar ( GlobVar is available to everyone ) - John From tinymuck-sloggers-owner Sat Mar 23 19:13:51 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA09135; Sat, 23 Mar 91 18:52:03 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA09131; Sat, 23 Mar 91 18:52:01 -0800 Received: by churchy.gnu.ai.mit.edu (5.65/4.0) id ; Sat, 23 Mar 91 21:52:42 -0500 Date: Sat, 23 Mar 91 21:52:42 -0500 From: rearl@gnu.ai.mit.edu (Robert Earl) Message-Id: <9103240252.AA04642@churchy.gnu.ai.mit.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: memory leak FIX Status: RO Thanks to schlake@minos.nmt.edu for spotting this, I fixed this later, but not soon enough! This will save you about 16K of growth every time someone gets permission denied on a program. Ouch. --chupchup *** /tmp/interp.c~ Sat Mar 23 21:48:07 1991 --- /tmp/interp.c Sat Mar 23 21:46:43 1991 *************** *** 136,141 **** --- 136,142 ---- (struct frame *) calloc(1, sizeof(struct frame)); if (!can_link_to(OWNER(source), TYPE_EXIT, program)) { notify(player, "Program call: Permission denied."); + free((void *) fr); return 0; } fr -> system.top = 1; From tinymuck-sloggers-owner Mon Mar 25 06:44:04 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14723; Mon, 25 Mar 91 06:40:52 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14719; Mon, 25 Mar 91 06:40:49 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Mon, 25 Mar 91 15:39:02 +0100 Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA01652; Mon, 25 Mar 91 14:39:51 gmt Message-Id: <9103251439.AA01652@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: TinyMUCK 2.2+ - the story so far. Date: Mon, 25 Mar 91 14:39:50 GMT From: Mike Prudence Status: RO Okay, Well, here's the summary (as I see it) of the last week's discussion. As most of the discussion seems to have been looking at features that really belong in 3.0, I think we have enough points now to fit into one mail message. 1) setlink (d1 d2 d3 ..... dA n -- n1) - links dA to d1, d2, d3 ... Apart from adding a success/fail return value (n1), does anyone have any problems with putting this one in ? 2) newroom/exit/object/recycle As pointed out by John Phillip Maraist , these would allow the unscrupulous to spam the database. Do we have any way around this, or should we just not worry about it ?? 3) uid ( -- dbref) - returns the effective UID of this program this_program ( -- dbref) - returns the currently running program These were clarified by Jon, and seem to be useful - one example being a SETUID program that stores a protected database on itself. Neat idea. 4) W bit passed to called programs I think we nuked this one good and proper. Although jearls did come up with the idea of a secure call primitive that would pass along it's privileges to the called program. 5) BUG in protected properties Jon pointed out that the permission check for dot properties should be made on OWNER(program) rather than the UID. 6) Personal Macro Libraries Well, although we can just define words with macro names, this didn't seem to sit well with the populace. One idea that keeps coming back is of extending the call primitive to allow one to call a particular word within a particular program. 7) Compiler directives A Lynx suggestion that I think would be neat. How easy is it to do, I wonder ? '#include' would be a winner (and long overdue). Also the #ifdef stuff (suggested by Gazer) would be good to see. 7) Well, it looks like no-one likes my 'sending strings to objects' mods at all. Nice idea, but everyone wants a 'cleaner' solution. I agree - but all the cleaner solutions involve a lot of rewrite. The bottom line - I'd like to see it in ( as a COMPILE time option) just so that I (and any other dirty hackers :) can use it. Any objections to that ? 8) Same for my triggering objects on movement mods. 9) MUF versions of system/user commands. A good idea in theory, but not many people were too sure about the practice. This might be an idea we will have to see some actual code and performance figures for, methinks. Plus, as WhiteRabbit pointed out, 2.2+ is really just a 'best of' hacks collection - not a major "nice" rewrite. 10) Deferred program compilation Jon has actually written this to help speed up his MUCKs startup time. We could include it (again as a compile time option, maybe) 11) Local variables How about this - variables that are protected from the heavy footsteps of programs they call ? At this point, I guess I would like to call in some of the stuff that has been already written. So, if you have an implementation of any of these ideas, and would like your code to sit in 2.2+, send me some mail (for want of anyone else). We seem to have done well at agreeing on the easy stuff, now we may as well start putting it together. If I can work out what has already been done, then I can see what has to be written. If you want to volunteer to write anything in particular, maybe now would be the time to raie your hand, too. I'm still not sure about the organization of this, and I don't know how much input/control ChupChup would like to have, so volunteering at this stage will not commit you to anything. Honest :) I'm also in the market for MUF to go in, as I think it would be nice to include a decent MUF program library with the distribution - at least some nice builder commands (general descriptions, exit listers, etc). Anyone got anything they'd care to contribute ? Cheers, Mike "not holding his breath here, folks" mjp@hplb.hpl.hp.com "Lettuce ? We don' need no steenking lettuce" From tinymuck-sloggers-owner Mon Mar 25 07:14:04 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14757; Mon, 25 Mar 91 06:53:34 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14753; Mon, 25 Mar 91 06:53:32 -0800 Received: by through.cs.caltech.edu (15.11/1.2) id AA09832; Mon, 25 Mar 91 06:57:24 pst Date: Mon, 25 Mar 91 06:57:24 pst From: tygryss@through.cs.caltech.edu (Karen Rivers) Message-Id: <9103251457.AA09832@through.cs.caltech.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: local macros Status: RO Why do we need a new MUF primitive to de local defines for a program? After all, instead of doing: def prompt me @ swap notify : main "test" .prompt ; simply do: : prompt me @ swap notify ; : main "test" prompt ; QED. It even takes up one less character in the source, and it takes less memory if it is called in multiple spots. PS: What do I have to do to subscribe to this mailing list? I mailed to tinymuck-sloggers-request@belch.berkeley.edu, but I still aren't recieving any mail from it. I might or might not see replies to this post depending on whether I can get John to forward them to me. - Tygryss From tinymuck-sloggers-owner Mon Mar 25 07:44:05 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14793; Mon, 25 Mar 91 07:18:12 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14789; Mon, 25 Mar 91 07:18:10 -0800 Received: by through.cs.caltech.edu (15.11/1.2) id AA09844; Mon, 25 Mar 91 07:22:05 pst Date: Mon, 25 Mar 91 07:22:05 pst From: tygryss@through.cs.caltech.edu (Karen Rivers) Message-Id: <9103251522.AA09844@through.cs.caltech.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: other ideas Status: RO As for a multiple setlink, why not do a setlink (d d ... d n -- ) where you have a set of dbrefs on the stack and the count on top. I would like to define a couple terms: range -- A set of values on the stack with the count of them on top. the proposal I made for setlink above would take a range of dbrefs, for example. On CrossRoads, we have defined a stand- ard where the first element of the range is the one on the bottom of the stack, and the last is the element judt beneath the element count. By this standard, the primitive 'explode' returns a reversed range. list -- a set of ordered properties with a count. On crossroads, the standard is: #: 1: 2: <2nd list element> ... n: For example, with listname of 'test' with 3 elements: test#: 3 test1: First element test2: second one test3: last line, and third element. Crossroads uses string lists as you can store integers in strings, and not vice-versa. Another idea I had which would make a wonderful kludge would be SLIPPY exits. Basically, the idea is, that when a player sends a command to the MUCK, it looks for an action that matches the player's input. If it finds an exit linked to a program, it passes on any command line parameters to the program and runs it. It then stops. With SLIPPY exits, it checks to see if the action linked to the program is set STICKY (SLIPPY), and if it is, it will execute the program is links to, then *continue* the search for another action that would be triggered by it. If that one is linked to a prog, and it is set SLIPPY, it will run it with the parameter, and continue looking. If the action is !SLIPPY, it executes the program with the param, but then stops the search there. Like I said, it's a kludge, and it would take duplicating lots of match.c to implement. The reasoning I have for wanting this mod is for things like allowing more than one vehicle with say and pose traps in the same room without getting the convo split between all of the vehicles. - Just some random thots. Take 'em or leave 'em. - Tygryss From tinymuck-sloggers-owner Mon Mar 25 14:14:07 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA15739; Mon, 25 Mar 91 14:11:56 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA15735; Mon, 25 Mar 91 14:11:52 -0800 Received: from localhost (stdin) by snow.white.toronto.edu with SMTP id 28706; Mon, 25 Mar 91 17:10:59 EST To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: TinyMUCK 2.2+ - the story so far. In-Reply-To: mjp's message of Mon, 25 Mar 91 09:39:50 -0500. <9103251439.AA01652@prudence.hpl.hp.com> Date: Mon, 25 Mar 91 17:10:43 EST From: Chris Siebenmann Message-Id: <91Mar25.171059est.28706@snow.white.toronto.edu> Status: RO Mike writes: |7) Well, it looks like no-one likes my 'sending strings to objects' |mods at all. Nice idea, but everyone wants a 'cleaner' solution. I |agree - but all the cleaner solutions involve a lot of rewrite. The |bottom line - I'd like to see it in ( as a COMPILE time option)| just |so that I (and any other dirty hackers :) can use it. Any objections |to that ? I'd urge that it not be folded in under #ifdefs. #ifdefs are a creeping evil that should be avoided whenever possible; any more than a small amount of them has a horrible effect on program maintainability and usability. If you stick your code in, even #ifdef'd, you oblige all future server maintainers to make sure it keeps working, and keeps working in all possible combinations of #ifdef's with other features. Code that has been heavily #ifdef'd is also amazingly hard to read; people who don't believe me are invited to try deciphering Xterm's main.c or display.c in MicroEmacs (unless it's gotten better since MicroEmacs 3.6). And when was the last time someone went over TinyMUCK and built a test server for each combination of options, and made sure it worked? Eschew creaping obfusciation and server maintainer workload; either decide new features are worthwhile enough to be included for everyone, or maintain patch files to add your modifications to a normal server. Everyone who has to read or work on the code will thank you. On the same line, maybe it's time to throw out some of the existing #defines: is there anyone who compiles without ABODE, COMPRESS, HAVEN, PLAYER_CHOWN, or RECYCLE? If not, take out those flags and the #ifdefs that use them, and just make it mainline code. - cks From tinymuck-sloggers-owner Tue Mar 26 13:44:16 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20044; Tue, 26 Mar 91 13:18:35 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20040; Tue, 26 Mar 91 13:18:32 -0800 Received: by enet-gw.pa.dec.com; id AA21716; Tue, 26 Mar 91 13:18:22 -0800 Message-Id: <9103262118.AA21716@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Tue, 26 Mar 91 13:18:30 PST Date: Tue, 26 Mar 91 13:18:30 PST From: "That's me in the spotlight, losing my religion. 26-Mar-1991 1614" To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Compile-time options Status: RO I do not use COMPRESS. I use all of ABODE, HAVEN, PLAYER_CHOWN and RECYCLE. Jon From tinymuck-sloggers-owner Tue Mar 26 15:44:16 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20369; Tue, 26 Mar 91 15:35:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20365; Tue, 26 Mar 91 15:35:28 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Tue, 26 Mar 91 17:35:25 -0600 id AA15062 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Tue, 26 Mar 91 17:35:09 -0600 id AA13173 Date: Tue, 26 Mar 91 17:35:09 -0600 From: Lee Brintle Message-Id: <9103262335.AA13173@umaxc.weeg.uiowa.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Name Changes in MUCK Status: RO Is there a reason why players are allowed to change their name? It just seems like another way to hassle other players without being accountable for it. Allow players to change the case or their name (no password required) or allow wizards to do it. It shouldn't happen that often (IMO). -- Tanj From tinymuck-sloggers-owner Tue Mar 26 16:14:17 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20465; Tue, 26 Mar 91 16:07:57 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20461; Tue, 26 Mar 91 16:07:56 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Tue, 26 Mar 91 18:07:53 -0600 id AA15444 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Tue, 26 Mar 91 18:07:39 -0600 id AA18579 Date: Tue, 26 Mar 91 18:07:39 -0600 From: Lee Brintle Message-Id: <9103270007.AA18579@umaxc.weeg.uiowa.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Name Changes in MUCK Status: RO I mentioned in my first note that players should be allowed to change the case of their name, and that passwords should not be required for this. If it's really desireable to allow name changes, perhaps announcing it to everyone in the room (a la IRC's "Tanj is not known as Tanstaafl") would be an intermediate solution. I still would rather see it gotten rid of, however. It's now fairly easy to spam someone and change your name a lot, making /gag not a workable method for preventing this. I don't think the benefits of allowing "The_Band" during special events are worth the added headache from people bent on making MUCK a pain in the ass for others. -- Tanj Tanstaafl From tinymuck-sloggers-owner Tue Mar 26 16:34:09 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20438; Tue, 26 Mar 91 16:00:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20434; Tue, 26 Mar 91 16:00:26 -0800 Received: by cory.Berkeley.EDU (5.63/1.42) id AA04694; Tue, 26 Mar 91 15:59:37 -0800 Date: Tue, 26 Mar 91 15:59:37 -0800 From: cwong@cory.Berkeley.EDU (Conrad Wong) Message-Id: <9103262359.AA04694@cory.Berkeley.EDU> To: lbrintle@umaxc.weeg.uiowa.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Name Changes in MUCK Status: RO It seems to me you could outline the following legitimate uses: 1. Change your name if you initially cased it incorrectly (lynx to Lynx) 2. Change to a new identity without having to use a new character (especially important for people who want to use one-time characters such as "The_Band" during parties) On the other hand, recent spoofing events on FurryMUCK make it evident that namechanging is also easy to abuse for spoofing, which is what Tanj addresses as a concern. So how can you draw a line to permit the legit uses? Possibility: to add "accountability", you might install a time limit on how often you can namechange-- that is, if you namechange, you might have to wait 30 seconds before you could change to another name again. This allows, assuming reasonable networks, people to see who's doing it (WHO lists, etc.), continues to allow basic namechanging as outlined above, and discourages namechanging as a spoof method unless you are prepared to be accountable for it (i.e. people knowing that you're doing it) One way to implement this would be as an added value in players' descriptors, which would be a timestamp (based on systime) of the last name change. If a name change is attempted before a certain amount of time has elapsed, then it returns a fail message (i.e. "The Social Security Bureau has not as yet finished processing your last change of name form.") Just some thoughts-- -- Lynxie From tinymuck-sloggers-owner Tue Mar 26 16:44:17 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20504; Tue, 26 Mar 91 16:27:29 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA20500; Tue, 26 Mar 91 16:27:21 -0800 Received: from VALKYRIE.ECN.UOKNOR.EDU by uokmax.ecn.uoknor.edu with SMTP id AA18034 (5.64+/IDA-1.3.4 for tinymuck-sloggers@belch.berkeley.edu); Tue, 26 Mar 91 18:27:12 -0600 Received: by valkyrie.ecn.uoknor.edu. (4.0/SMI-4.0) id AA08354; Tue, 26 Mar 91 18:21:49 CST Message-Id: <9103270021.AA08354@valkyrie.ecn.uoknor.edu.> From: jennifer@valkyrie.ecn.uoknor.edu (Jennifer "Moira" Smith) Date: Tue, 26 Mar 1991 18:21:36 CST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Name Changes in MUCK Status: RO As a small side note, Only a wizard can change a player's name in UnterMUD. I've often thought this was A Good Idea; if you NEED another name often, get another character. Moira -- Jennifer Smith (oooog, oh baby) \ jennifer@valkyrie.ecn.uoknor.edu Moira@Asylum & other MUDS here 'n' there \ "How short, though?" Here, have a clue. Take two, they're small. \ -- Dr. Ruth From tinymuck-sloggers-owner Tue Mar 26 18:14:17 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22283; Tue, 26 Mar 91 18:03:25 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22279; Tue, 26 Mar 91 18:03:21 -0800 Message-Id: <9103270203.AA22279@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Tue, 26 Mar 91 21:03:18 -0500 Date: Tue, 26 Mar 91 21:02:35 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Name changes in Muck? Status: RO Sometimes I feel like I'm trying to hold back the tide. (In this case, it's slow but it comes in relentlessly.) In Nethack development, there was something called the "ratchet effect": there may be lots of changes, each individual one being small, but since each change was in the direction of making the game more difficult, the overall effect was to greatly increase the difficulty of the game. I think a similar thing is happening to Muck (or at least would be if many proposed changes were to be adopted): Many of the changes proposed past 2.2, either as changes in Muck, good ways of running Mucks, or as desirable features in the next generation of muds, have the effect of keeping a normal, non-wizard, player from doing something he used to be able to do. Cumulatively, the effect is to prevent players from doing a _lot_ of things. Higher-ups tend not to notice this because 1) they're wizards, exempt from the restrictions, so they never get inconvenienced by them and thus only think of the restrictions as "minor", and 2) the restrictions they propose are restrictions for things they themselves do not do, so they might not even realize that people who play in different ways from them are being restricted. I, of course, use name changes quite a lot--because you can't think of a good reason for something doesn't mean that someone doesn't have one that you didn't think of. (It also means that putting in the restriction and then trying to fix it up so it doesn't restrict the special uses you can think of _now_, is a losing proposition.) This even applies to "spoofing" using name changes. Also, such "spoofing" can be annoying, but so can streams of puns--yet I do not see many Muds call for the banning of puns. I sometimes get annoyed when people talk about pieces of computer hardware that I do not own and have never worked with--but I deal with it. I do not call for the installation of programs that keep you from saying "2400 bps modem" in a public room. It's inevitable that on a Mud, people will say things that are uninteresting or annoying to others; banning one particular class of those just because they are easy to detect automatically is, IMHO, not a good idea. From tinymuck-sloggers-owner Tue Mar 26 19:14:18 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22445; Tue, 26 Mar 91 18:47:54 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22441; Tue, 26 Mar 91 18:47:52 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/900928) on Tue, 26 Mar 91 20:47:50 -0600 id AA17498 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Tue, 26 Mar 91 20:47:27 -0600 id AA22918 Date: Tue, 26 Mar 91 20:47:27 -0600 From: Lee Brintle Message-Id: <9103270247.AA22918@umaxc.weeg.uiowa.edu> To: arromdee@server.cs.jhu.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Name changes in Muck? Status: RO There is, however, a big difference between things that annoy you and things that are fraudulent. I am not a wizard, have never been a wizard (for all practical purposes), and have no plans to be a wizard, yet I am the one trying to tighten up the game more than any else, so I don't fall under your group of people. As I've said repeatedly, I'd like to see examples of things that would not longer work with all these restrictions. So far, the only things people have mentioned is that is would prevent them from doing what the changes are designed to stop: abuse of the system. I think these issues go far beyond the question of taste. -- Tanj Tanstaafl From tinymuck-sloggers-owner Tue Mar 26 19:44:18 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22521; Tue, 26 Mar 91 19:18:21 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA22517; Tue, 26 Mar 91 19:18:03 -0800 Received: from ugrad.cs.su.oz (via basser) by munnari.oz.au with SunIII (5.64+1.3.1+0.50) id AA02594; Wed, 27 Mar 1991 13:17:53 +1000 (from 8936547@ugrad.cs.su.oz.au) Received: by ugrad.ugrad.cs.su.oz (upas2.3); Wed, 27 Mar 91 13:17:10 +1000 Date: Wed, 27 Mar 91 13:17:10 +1000 From: Geoffrey Michael Bailey <8936547@ugrad.cs.su.oz.au> To: tinymuck-sloggers%belch.berkeley.edu%munnari@basser.cs.su.oz.au Message-Id: <18674.670043830@mango.ugrad.cs.su.oz> Subject: lock primitive Status: RO Well, I've missed a bit of the debate about new features because our system got rewritten, so pardon me if this has been mentioned before. One thing I'd like to have is a lock primitive for MUF (d1 d2 -- i) which returns in i true if player d1 would pass the lock on d2. Comments/flames? ftww ------ email: 8936547@ugrad.cs.su.oz.au `Theorem 6.2 follows easily from theorem 6.9' From tinymuck-sloggers-owner Wed Mar 27 01:44:20 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25281; Wed, 27 Mar 91 01:16:30 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25277; Wed, 27 Mar 91 01:16:19 -0800 Received: from unipress.unipress.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with UUCP id AA28222; Wed, 27 Mar 91 02:25:21 EST Received: from dot.unipress.com.unipress by unipress.com (3.2/SMI-3.0DEV3) id AA10061; Tue, 26 Mar 91 23:40:24 EST Date: Tue, 26 Mar 91 23:40:24 EST From: joe@unipress.unipress.com (Joe Miklojcik) Message-Id: <9103270440.AA10061@unipress.com> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: UnterMUD? Status: RO This sounds interesting. Unfortunately, our net connection has been down for some time now, and ftping anything is impossible for me. I would be very interested in reading any documentation there may be for this If someone could mail me any, I'd really appreciate it. thanks. --joe joe@dot.unipress.com From tinymuck-sloggers-owner Wed Mar 27 01:59:27 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25289; Wed, 27 Mar 91 01:18:36 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA25285; Wed, 27 Mar 91 01:18:29 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 27 Mar 91 10:16:35 +0100 Received: from localhost by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA08083; Wed, 27 Mar 91 09:17:24 gmt Message-Id: <9103270917.AA08083@prudence.hpl.hp.com> To: sloggers@hplb.hpl.hp.com Subject: Compile time flags Date: Wed, 27 Mar 91 09:17:23 GMT From: Mike Prudence Status: RO Yo all, Seems like it might be a good idea to get rid of the flags that everyone uses anyway. How about if you all mail me a list of the flags you define, or even just your Makefile, and I'll coordinate a list and publish the results ? Yours helpfully, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Wed Mar 27 23:44:28 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27909; Wed, 27 Mar 91 23:35:42 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27905; Wed, 27 Mar 91 23:35:40 -0800 Received: by eagle.calpoly.edu (4.1/2.890629) id AA00423; Wed, 27 Mar 91 23:33:10 PST Date: Wed, 27 Mar 91 23:33:10 PST From: jearls@eagle.calpoly.edu (Johnson M. Earls) Message-Id: <9103280733.AA00423@eagle.calpoly.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Name changes in Muck? Status: RO Personally, I think that name changes should be allowed, but with the timestamp idea. I like changing my name slightly to indicate, for example, my current status (IdleSthiss) or that I have changed slightly (GooSthiss). The IdleSthiss is very nice because I don't wake back up with hundreds of "xxx pages: You awake?" - John From tinymuck-sloggers-owner Thu Mar 28 00:14:28 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27927; Thu, 28 Mar 91 00:05:54 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA27923; Thu, 28 Mar 91 00:05:52 -0800 Received: by volga.Berkeley.EDU (5.57/Ultrix3.0-C) id AA15966; Thu, 28 Mar 91 00:05:04 -0800 Date: Thu, 28 Mar 91 00:05:04 -0800 From: c188-aj@volga.berkeley.edu (Doug Orleans) Message-Id: <9103280805.AA15966@volga.Berkeley.EDU> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Spoofing Status: RO People will always find a way around any restrictions you put in to disallow spoofing. I think you should make spoofing easy, maybe even supply a spoof action; people will get tired of abusing it. Spoofing can be fun, but not when it's done excessively or done to annoy people. This is not quite the same argument as legalizing drugs, because spoofing is not addictive. (At least not to most people I know.) WhiteRabbit, aka Going, aka Connection, aka Daemun, etc... DougO From tinymuck-sloggers-owner Thu Mar 28 09:14:32 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA28372; Thu, 28 Mar 91 08:57:08 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA28368; Thu, 28 Mar 91 08:57:06 -0800 Received: by enet-gw.pa.dec.com; id AA25433; Thu, 28 Mar 91 08:56:59 -0800 Message-Id: <9103281656.AA25433@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Thu, 28 Mar 91 08:57:04 PST Date: Thu, 28 Mar 91 08:57:04 PST From: "That's me in the spotlight, losing my religion. 28-Mar-1991 1151" To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Name changes Status: RO I must admit that I'm simply amused, and can't get excited about restricting name changes. Perhaps it's because I've never had a problem with it. If we're voting, count my vote as a vote against. I tend to agree with the 'ratchet' argument, but also feel it's no big deal one way or the other. Jon From tinymuck-sloggers-owner Sun Mar 31 12:15:00 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03001; Sun, 31 Mar 91 12:13:09 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA02997; Sun, 31 Mar 91 12:13:08 -0800 Received: from boris.sdsc.edu by sluggo.sdsc.edu (4.1/4.7) id AA08314; Sun, 31 Mar 91 12:01:49 PST Date: Sun, 31 Mar 91 12:01:49 PST From: David Moore Message-Id: <9103312001.AA08314@sluggo.sdsc.edu> Received: by boris.sdsc.edu (4.1/SMI-4.1) id AA04009; Sun, 31 Mar 91 12:10:18 PST To: blojo@soda.berkeley.edu Cc: dbriggs@zia.aoc.nrao.edu, tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Jon Blow's message of Fri, 22 Mar 91 04:57:33 -0900 <9103221357.AA17494@soda.Berkeley.EDU> Subject: macro processor, namespaces, primitives Status: RO >> As a last parting shot, has anyone suggested 'depth' yet? It would >> return the number of items on the stack, before the primitive is >> executed. > This is only useful either in very very very simple programs or in > very very very complex programs. In either case, it is not needed, > and is merely a tool with which to write more obfuscated forth. Well, I have at one time or another been forced to call a program of which I was unsure of what it would do to the stack. So I can of course save my current stack away before calling this thing, but I have no way of clearing what it's done to the stack, or of cleanly being able to check that it did return a value. It was supposed to leave a boolean on the top of the stack, but if it did nothing my routine would die hard on the first compare of this puppy, when I should be able to do error recovery. So, depth is useful, or perhaps, to make things seem cleaner for people, just provide an empty? primitive which returns true if the stack is empty. David From tinymuck-sloggers-owner Sun Mar 31 13:15:01 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03031; Sun, 31 Mar 91 12:54:21 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03027; Sun, 31 Mar 91 12:54:20 -0800 Return-Path: Received: from aries.ipac.caltech.edu by castor.ipac.caltech.edu (5.65-ir.022091) id AA15863; Sun, 31 Mar 91 12:54:14 -0800 Received: by Aries.ipac.caltech.edu (ig.020791) Date: Sun, 31 Mar 91 12:54:13 PST From: Dave Van Buren Message-Id: <9103312054.AA02312@Aries.ipac.caltech.edu> To: u7466@sdsc.edu Subject: Re: macro processor, namespaces, primitives Cc: tinymuck-sloggers@belch.Berkeley.EDU Status: RO Just push a special value "David Moore" onto the stack before the call, then afterwards, just swap and pop until it shows up again. You'll have to do logic on the intermediate values depending on what the routine returns, but your stack will end up in fine order. From tinymuck-sloggers-owner Sun Mar 31 13:45:01 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03090; Sun, 31 Mar 91 13:34:34 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03086; Sun, 31 Mar 91 13:34:33 -0800 Received: from boris.sdsc.edu by sluggo.sdsc.edu (4.1/4.7) id AA08326; Sun, 31 Mar 91 13:23:17 PST Date: Sun, 31 Mar 91 13:23:17 PST From: David Moore Message-Id: <9103312123.AA08326@sluggo.sdsc.edu> To: dave@ipac.caltech.edu, u7466@Sdsc.EDU Subject: Re: macro processor, namespaces, primitives Cc: tinymuck-sloggers@belch.Berkeley.EDU Status: RO However, as I said, the called program makes no guarantees to me to do leave the stack in any condition what so ever. It might be some fluke remove this special value from the stack. Yes, I know that this means that this program being called is evil and will crash under normal circumstances, but that's all really kludgy for a primitive which is provided in essentially all stack based languages. From tinymuck-sloggers-owner Sun Mar 31 21:15:04 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03547; Sun, 31 Mar 91 21:06:35 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA03543; Sun, 31 Mar 91 21:06:00 -0800 Received: by volga.Berkeley.EDU (5.57/Ultrix3.0-C) id AA18756; Sun, 31 Mar 91 21:03:38 -0800 Date: Sun, 31 Mar 91 21:03:38 -0800 From: c188-aj@volga.berkeley.edu (Doug Orleans) Message-Id: <9104010503.AA18756@volga.Berkeley.EDU> To: dave@ipac.caltech.edu, u7466@sdsc.edu Subject: Re: macro processor, namespaces, primitives Cc: tinymuck-sloggers@belch.Berkeley.EDU Status: RO My vote would be to include an empty? primitive. This seems very easy to implement, as well as being very useful. I really don't see any reason NOT to include this. Doug's two sense worth. From tinymuck-sloggers-owner Wed Apr 3 07:15:26 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13693; Wed, 3 Apr 91 06:52:47 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13689; Wed, 3 Apr 91 06:52:45 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/910327) on Wed, 3 Apr 91 08:52:42 -0600 id AA27232 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Wed, 3 Apr 91 08:52:29 -0600 id AA24764 Date: Wed, 3 Apr 91 08:52:29 -0600 From: Lee Brintle Message-Id: <9104031452.AA24764@umaxc.weeg.uiowa.edu> To: tinymuck-sloggers@belch.Berkeley.EDU Subject: MUF if...then construct Status: RO May we please make the word "endif" equivilant to "then"? Nothing about MUF is more confusing than that little misnomer. Huh Huh, pretty please? -- Tanj Tanstaafl From tinymuck-sloggers-owner Wed Apr 3 08:15:26 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13804; Wed, 3 Apr 91 08:11:49 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13800; Wed, 3 Apr 91 08:11:48 -0800 Received: by enet-gw.pa.dec.com; id AA01689; Wed, 3 Apr 91 08:11:41 -0800 Message-Id: <9104031611.AA01689@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Wed, 3 Apr 91 08:11:45 PST Date: Wed, 3 Apr 91 08:11:45 PST From: "That's me in the spotlight, losing my religion. 03-Apr-1991 1056" To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Cleaning up error conditions in MUF Status: RO One thing that we also ought to do for 2.2+ (and I'm doing myself) is cleaning up some of the error conditions for the builtin words. For example, I was writing yesterday, and wanted to check to see if an exit was linked to a room. Well: thing @ getlink room? blows up when the exit is unlinked, because ROOM? complains that #-1 is not a valid object. My response was, "so bloody what? #-1 is not a room, so just return 0, okay?" I changed the code for it and its related predicates to simply return 0 when they'd have aborted the interpreter before. This sort of thing is needed in a lot of other places. NAME of #-1 ought to be "*NOTHING*" #-2 ought to be "*AMBIGUOUS*" and #-3 ought to be "*HOME*". Most other errors should simply return null strings. Why abort the compiler when there's a logical error value to return? Jon From tinymuck-sloggers-owner Wed Apr 3 08:45:26 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13839; Wed, 3 Apr 91 08:36:34 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13835; Wed, 3 Apr 91 08:36:32 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA05496; Wed, 3 Apr 91 08:35:08 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA06505; Wed, 3 Apr 91 08:36:08 PST Date: Wed, 3 Apr 91 08:36:08 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9104031636.AA06505@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Lee Brintle's message of Wed, 3 Apr 91 08:52:29 -0600 <9104031452.AA24764@umaxc.weeg.uiowa.edu> Subject: MUF if...then construct Status: RO Why? It's "if..else..then" in Forth, and what makes it a misnomer? --chupchup From tinymuck-sloggers-owner Wed Apr 3 10:15:27 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13995; Wed, 3 Apr 91 09:46:37 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA13991; Wed, 3 Apr 91 09:46:34 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/910327) on Wed, 3 Apr 91 11:46:21 -0600 id AA29820 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Wed, 3 Apr 91 11:46:08 -0600 id AA06954 Date: Wed, 3 Apr 91 11:46:08 -0600 From: Lee Brintle Message-Id: <9104031746.AA06954@umaxc.weeg.uiowa.edu> To: rearl@watnxt2.ucr.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUF if...then construct Status: RO Because it's if...endif in a gizillion other languages. I can't think of another one (other than Forth) that uses "if...else...then". Grr.... Do we lose anything by allowing the "endif" (other than cryptic syntax)? -TT From tinymuck-sloggers-owner Wed Apr 3 11:15:27 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14114; Wed, 3 Apr 91 11:11:20 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14110; Wed, 3 Apr 91 11:11:19 -0800 Received: by enet-gw.pa.dec.com; id AA20999; Wed, 3 Apr 91 11:11:11 -0800 Message-Id: <9104031911.AA20999@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Wed, 3 Apr 91 11:11:18 PST Date: Wed, 3 Apr 91 11:11:18 PST From: "That's me in the spotlight, losing my religion. 03-Apr-1991 1406" To: tinymuck-sloggers@belch.Berkeley.EDU Subject: if...then Status: RO I think it's counter intuitive, too, but here's what you can do: @prog foo def endif then if ... .endif Jon From tinymuck-sloggers-owner Wed Apr 3 13:45:28 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14292; Wed, 3 Apr 91 13:26:59 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14288; Wed, 3 Apr 91 13:26:58 -0800 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA21007; Wed, 3 Apr 91 13:26:34 -0800 Date: Wed, 3 Apr 91 13:26:34 -0800 From: Jon Blow Message-Id: <9104032126.AA21007@soda.berkeley.edu> To: brintle@umaxc.weeg.uiowa.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUF if...then construct Status: RO But I like "then". From tinymuck-sloggers-owner Wed Apr 3 14:15:29 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14357; Wed, 3 Apr 91 13:49:01 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14353; Wed, 3 Apr 91 13:48:58 -0800 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64/910327) on Wed, 3 Apr 91 15:48:52 -0600 id AA03291 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/891218) on Wed, 3 Apr 91 15:48:40 -0600 id AA06465 Date: Wed, 3 Apr 91 15:48:40 -0600 From: Cyberpixie Message-Id: <9104032148.AA06465@umaxc.weeg.uiowa.edu> To: blojo@soda.berkeley.edu, brintle@umaxc.weeg.uiowa.edu, tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: MUF if...then construct Status: RO Jon Blow writes: > But I like "then". I like "endif". Next? In all seriousness, I'm not sure an arguement based on what other Forthish languages do is valid. If there were huge numbers of people who knew Forth moving to MUF, yeah, but I think it's more likely that most MUF programmers are used to C. MUF, in other words, is not the best place in the world to fight for a pure Forth. Bryant Durrell durrell@umaxc.weeg.uiowa.edu ------------------------------------------------------------------------------- "UUCP is an old protocol. Weeg does not support it and has no plans to do so." -- Rex Pruess (rpruess@umaxc.weeg.uiowa.edu) From tinymuck-sloggers-owner Wed Apr 3 14:45:29 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14390; Wed, 3 Apr 91 14:18:47 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14386; Wed, 3 Apr 91 14:18:45 -0800 Received: from boris.sdsc.edu by sluggo.sdsc.edu (4.1/4.7) id AA11676; Wed, 3 Apr 91 14:07:13 PST Date: Wed, 3 Apr 91 14:07:13 PST From: David Moore Message-Id: <9104032207.AA11676@sluggo.sdsc.edu> Received: by boris.sdsc.edu (4.1/SMI-4.1) id AA05559; Wed, 3 Apr 91 14:15:54 PST To: durrell@umaxc.weeg.uiowa.edu Cc: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Cyberpixie's message of Wed, 3 Apr 91 15:48:40 -0600 <9104032148.AA06465@umaxc.weeg.uiowa.edu> Subject: MUF if...then construct Status: RO C doesn't have an endif. :-) Seriously, just leave it as then, and since we're so darn convinced we want them def's (which we do) then just do as Jon suggested and def endif then. David From tinymuck-sloggers-owner Wed Apr 3 15:15:29 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14435; Wed, 3 Apr 91 14:47:53 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14431; Wed, 3 Apr 91 14:47:48 -0800 Received: from watnxt2.ucr.edu (watnxt2) by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA00766; Wed, 3 Apr 91 14:46:23 GMT-0800 Received: by watnxt2.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA08194; Wed, 3 Apr 91 14:47:15 PST Date: Wed, 3 Apr 91 14:47:15 PST From: rearl@watnxt2.ucr.edu (chup) Message-Id: <9104032247.AA08194@ watnxt2.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU In-Reply-To: Cyberpixie's message of Wed, 3 Apr 91 15:48:40 -0600 <9104032148.AA06465@umaxc.weeg.uiowa.edu> Subject: MUF if...then construct Status: RO | MUF, in other words, is not the best place in the world to fight for | a pure Forth. It's even less a place to fight for C, eh. --chupchup From tinymuck-sloggers-owner Wed Apr 3 15:38:12 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14475; Wed, 3 Apr 91 15:13:13 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA14471; Wed, 3 Apr 91 15:13:12 -0800 Received: from hpsovtx.cup.hp.com by relay.hp.com with SMTP (16.5/15.5+IOS 3.13) id AA08139; Wed, 3 Apr 91 15:12:02 -0800 Received: by hpsovtx.cup.hp.com with SMTP (15.11/15.5+IOS 3.20+cup+OMrelay) id AA03913; Wed, 3 Apr 91 15:11:40 pst Message-Id: <9104032311.AA03913@hpsovtx.cup.hp.com> To: tinymuck-sloggers@belch.Berkeley.EDU Cc: bruce@hpsovtx.cup.hp.com Subject: Re: MUF if...then construct Date: Wed, 03 Apr 91 15:11:38 -0800 From: Bruce LaVigne Status: RO Please remove my name from the muck-sloggers mailing list. Thank you. -bruce (bruce@hpda.cup.hp.com) From tinymuck-sloggers-owner Fri Apr 5 08:15:45 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24418; Fri, 5 Apr 91 08:11:22 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24414; Fri, 5 Apr 91 08:11:16 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 5 Apr 91 17:09:09 +0100 Received: by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04360; Fri, 5 Apr 91 16:10:06 gmt Message-Id: <9104051610.AA04360@prudence.hpl.hp.com> To: sloggers%prudence.hpl.hp.com@hplb.hpl.hp.com Subject: Hmm - what about this, guys ? Date: Fri, 05 Apr 91 17:10:06 BST From: Mike Prudence Status: RO Hi Sloggers. One of my fellow HP-ites is working on a project, and he has been using the DB code from TinyMUCK (2.1 as it happens, but the portion shown below is about the same for 2.2). > As I was working on the WB code I seem to have a problem with one of the > MUCK routines in the 2.1 source. In the TinyMuck file > "src/db.c" in the function "db_read_object_lachesis()" under the case > statement at the end for TYPE_GARBAGE you have the following code: > case TYPE_GARBAGE: > o->next = recyclable; > recyclable = objno; > free(NAME(objno)); > free(o->description); > NAME(objno) = ""; > o->description = ""; > break; > Please note that the code is setting the NAME and description fields for > an object AFTER it has free'd the alloc'd space for that entry. > Doesn't this cause a problem? Now I may be a bit dense today, but isn't this a problem ? I can't work out why it hasn't caused many a fruity crash before now. Any ideas ?? Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Fri Apr 5 09:45:45 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24548; Fri, 5 Apr 91 09:29:59 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24544; Fri, 5 Apr 91 09:29:57 -0800 Message-Id: <9104051729.AA24544@belch.Berkeley.EDU> Received: by server.cs.jhu.edu ; Fri, 5 Apr 91 12:29:54 -0500 Date: Fri, 5 Apr 91 12:29:52 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers@belch.Berkeley.EDU Subject: Re: Hmm - what about this, guys ? Status: RO Uh... The free frees the space to which the pointer points. The pointer itself still exists, it doesn't point anywhere. And = is not a string copy, just a pointer assignment, so it doesn't write over any space. From tinymuck-sloggers-owner Fri Apr 5 10:15:45 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24628; Fri, 5 Apr 91 09:46:41 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24624; Fri, 5 Apr 91 09:46:36 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 5 Apr 91 18:44:32 +0100 Received: from hplb.hpl.hp.com by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04439; Fri, 5 Apr 91 17:45:30 gmt Received: from ux.acs.umn.edu by hplb.hpl.hp.com; Fri, 5 Apr 91 18:44:23 +0100 Message-Id: <9104051744.AA09748@hplb.hpl.hp.com> Received: by ux.acs.umn.edu id aa28619; 5 Apr 91 11:44 CST Subject: Re: Hmm - what about this, guys ? To: Mike Prudence Date: Fri, 5 Apr 91 11:42:23 CST Cc: sloggers%prudence.hpl.hp.com@hplb.hpl.hp.com In-Reply-To: <9104051610.AA04360@prudence.hpl.hp.com>; from "Mike Prudence" at Apr 5, 91 5:10 pm X-Mailer: ELM [version 2.3 PL8] From: mtymp01%ux.acs.umn.edu@hplb.hpl.hp.com Status: RO C'mon people. learn how pointers work. From tinymuck-sloggers-owner Fri Apr 5 12:15:46 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24791; Fri, 5 Apr 91 11:50:37 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA24787; Fri, 5 Apr 91 11:50:25 -0800 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 5 Apr 91 20:48:21 +0100 Received: from hplb.hpl.hp.com by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA04552; Fri, 5 Apr 91 19:49:19 gmt Received: from [192.31.146.125] by hplb.hpl.hp.com; Fri, 5 Apr 91 20:48:10 +0100 Received: by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA08461; Fri, 5 Apr 91 11:48:43 PST Date: Fri, 5 Apr 91 11:48:43 PST From: rearl%watnxt3.ucr.edu@hplb.hpl.hp.com (chup) Message-Id: <9104051948.AA08461@ watnxt3.ucr.edu > To: mjp@hplb.hpl.hp.com Cc: sloggers%prudence.hpl.hp.com@hplb.hpl.hp.com In-Reply-To: Mike Prudence's message of Fri, 05 Apr 91 17:10:06 BST <9104051610.AA04360@prudence.hpl.hp.com> Subject: Hmm - what about this, guys ? Status: RO | > case TYPE_GARBAGE: | > o->next = recyclable; | > recyclable = objno; | > free(NAME(objno)); | > free(o->description); | > NAME(objno) = ""; | > o->description = ""; | > break; If you watch closely, you'll find that the description and name of garbage objects can't ever be set from the game, since nobody controls them, and they can't be re-recycled. (Also, the name and dsec can be unconditionally freed because we know we just read in a name and desc for it-- that's how garbage is dumped. Thus, having the name and desc pointing to static strings saves a *LOT* of space. I suppose it could be more robust, or at the very least have /* XXX */ comments surrounding it explaining the tricks involved; I can see this breaking if you're modifying something else blindly. --chupchup PS [still reading my mail this morning] | From: mtymp01%ux.acs.umn.edu@hplb.hpl.hp.com | | C'mon people. learn how pointers work. I think anyone who knows how pointers work might be worried about that bit of code, especially when strings in those fields are (normally) dynamically allocated... From tinymuck-sloggers-owner Fri Apr 5 18:45:49 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04630; Fri, 5 Apr 91 18:35:55 -0800 Received: by belch.Berkeley.EDU (5.57/1.41) id AA04626; Fri, 5 Apr 91 18:35:50 -0800 Received: by watnxt3.ucr.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA11444; Fri, 5 Apr 91 18:34:24 PST Date: Fri, 5 Apr 91 18:34:24 PST From: rearl@watnxt3.ucr.edu (chup) Message-Id: <9104060234.AA11444@ watnxt3.ucr.edu > To: tinymuck-sloggers@belch.Berkeley.EDU Subject: TinyMUCK 2.2 patches! Status: RO I finally collected enough bug reports and patches from the tinymuck-sloggers list and other sources to make up a decent sized patch release; here it is. These should agree fine with teh distribution from belch.berkeley.edu, if anyone has trouble applying these to a vanilla TinyMUCK 2.2, let me know ASAP; they'll be up for ftp on belch in a day or two if I don't hear about any problems. Fixes include: fatal bug in move.c, stack frame memory leak and setting negative variables in interp.c, capitalized % subs bug in stringutil.c, and some annoying wiz.c bugs. The only important new fix for those who have been following sloggers is in wiz.c; it's for do_toad() in the cases where a player owns programs or [this won't happen] objects are homed to him/her, the toad ended up carrying the objects. It can't hurt anything as far as I can see having an object with contents, but nevertheless, it won't happen again. --chupchup rearl@watnxt3.ucr.edu rearl@gnu.ai.mit.edu *** look.c.old Sat Oct 6 19:04:57 1990 --- look.c Mon Nov 19 13:52:55 1990 *************** *** 117,123 **** for (; *p && !isspace(*p); p++) ; if (*p) p++; ! if ((Typeof(i) != TYPE_PROGRAM) || DBFETCH(player)->sp.player.run) { if (*p) notify (player, p); else notify(player, "You see nothing special."); } else { --- 117,124 ---- for (; *p && !isspace(*p); p++) ; if (*p) p++; ! if (i < 0 || i >= db_top ! || (Typeof(i) != TYPE_PROGRAM) || DBFETCH(player)->sp.player.run) { if (*p) notify (player, p); else notify(player, "You see nothing special."); } else { *** interp.c.old Fri Apr 5 20:11:14 1991 --- interp.c Fri Apr 5 19:49:30 1991 *************** *** 135,140 **** --- 135,141 ---- fr = DBFETCH(player)->sp.player.run = (struct frame *) calloc(1, sizeof(struct frame)); if (!can_link_to(OWNER(source), TYPE_EXIT, program)) { + free((void *) fr); notify(player, "Program call: Permission denied."); return 0; } *************** *** 289,295 **** abort_loop("Program word: Stack Underflow."); temp1 = arg + --atop; if (temp1->type != PROG_ADD) ! abort_loop("Program word: Program internal error."); if (stop >= STACK_SIZE) abort_loop("Program word: Stack Overflow"); sys[stop++].data.call = pc + 1; --- 290,296 ---- abort_loop("Program word: Stack Underflow."); temp1 = arg + --atop; if (temp1->type != PROG_ADD) ! abort_loop("JMP: Non-address argument."); if (stop >= STACK_SIZE) abort_loop("Program word: Stack Overflow"); sys[stop++].data.call = pc + 1; *************** *** 767,773 **** case IN_BANG: CHECKOP(2); oper1 = POP(); oper2 = POP(); ! if (oper1->type != PROG_VAR || oper1->data.number >= MAX_VAR) abort_interp("Non-variable argument (2)"); CLEAR(&fr -> variables[oper1->data.number]); copyinst(oper2, &(fr -> variables[oper1->data.number])); --- 768,775 ---- case IN_BANG: CHECKOP(2); oper1 = POP(); oper2 = POP(); ! if (oper1->type != PROG_VAR ! || (oper1->data.number >= MAX_VAR) || (oper1->data.number < 0)) abort_interp("Non-variable argument (2)"); CLEAR(&fr -> variables[oper1->data.number]); copyinst(oper2, &(fr -> variables[oper1->data.number])); *** wiz.c.old Fri Apr 5 20:19:55 1991 --- wiz.c Fri Apr 5 21:11:06 1991 *************** *** 377,401 **** } else if(Wizard(victim)) { notify(player, "You can't turn a Wizard into an idiot!"); } else { ! /* we're ok */ ! /* do it */ ! send_contents(player, HOME); for (stuff = 0; stuff < db_top; stuff++) { if (OWNER(stuff) == victim) { ! switch (Typeof(stuff)) { ! case TYPE_ROOM: ! case TYPE_THING: ! case TYPE_EXIT: ! case TYPE_PROGRAM: ! OWNER(stuff) = recipient; ! DBDIRTY(stuff); ! break; ! } } } if(DBFETCH(victim)->sp.player.password) { free((void *) DBFETCH(victim)->sp.player.password); ! DBFETCH(victim)->sp.player.password = 0; } FLAGS(victim) = TYPE_THING; OWNER(victim) = player; /* you get it */ --- 377,403 ---- } else if(Wizard(victim)) { notify(player, "You can't turn a Wizard into an idiot!"); } else { ! /* chown things to recipient, checking for a sane home location */ ! /* for object. XXX -- if HOME/inventory handling changes, */ ! /* please check this code.*/ ! for (stuff = 0; stuff < db_top; stuff++) { + if ((Typeof(stuff) == TYPE_THING) + && (DBFETCH(stuff)->sp.thing.home == victim)) { + DBSTORE(stuff, sp.thing.home, PLAYER_START); + } if (OWNER(stuff) == victim) { ! OWNER(stuff) = recipient; ! DBDIRTY(stuff); } } + /* Take them home; things should no longer be homed here, programs */ + /* should not be owned by player */ + + send_contents(victim, HOME); if(DBFETCH(victim)->sp.player.password) { free((void *) DBFETCH(victim)->sp.player.password); ! DBFETCH(victim)->sp.player.password = NULL; } FLAGS(victim) = TYPE_THING; OWNER(victim) = player; /* you get it */ *** stringutil.c.old Fri Apr 5 18:28:27 1991 --- stringutil.c Fri Apr 5 18:29:31 1991 *************** *** 47,53 **** #include "externs.h" extern const char *uppercase, *lowercase; ! #define DOWNCASE(x) (lowercase[x]) #ifdef COMPRESS extern const char *uncompress(const char *); #endif /* COMPRESS */ --- 47,54 ---- #include "externs.h" extern const char *uppercase, *lowercase; ! #define DOWNCASE(x) (lowercase[(x)]) ! #define UPCASE(x) (uppercase[(x)]) #ifdef COMPRESS extern const char *uncompress(const char *); #endif /* COMPRESS */ *************** *** 129,135 **** { strcat(result, self_sub); if (isupper(prn[1])) ! *result = toupper(*result); result += strlen(result); str++; } --- 130,136 ---- { strcat(result, self_sub); if (isupper(prn[1])) ! *result = UPCASE(*result); result += strlen(result); str++; } *************** *** 190,197 **** result[1] = '\0'; break; } ! if(isupper(c) && islower(*result)) { ! *result = toupper(*result); } result += strlen(result); --- 191,198 ---- result[1] = '\0'; break; } ! if(isupper(c)) { ! *result = UPCASE(*result); } result += strlen(result); From tinymuck-sloggers-owner Mon Apr 8 01:21:09 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA28474; Mon, 8 Apr 91 01:14:06 -0700 Received: by belch.Berkeley.EDU (5.57/1.41) id AA28470; Mon, 8 Apr 91 01:13:59 -0700 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Mon, 8 Apr 91 09:11:36 +0100 Received: by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA06755; Mon, 8 Apr 91 08:12:34 gmt Message-Id: <9104080812.AA06755@prudence.hpl.hp.com> To: sloggers%prudence.hpl.hp.com@hplb.hpl.hp.com Subject: Re: Hmm - what about this, guys ? Date: Mon, 08 Apr 91 09:12:31 BST From: Mike Prudence Status: RO Geez, Ask the wrong question and start a war :) Thanks to all the folks who responded, and I apologise for asking a dumb question. For those that are interested, I've actually been programming 'C' and other things for a large number of years, so this apparent lapse I put down to being a bit drugged up (bad cold at the moment). In actuality, the confusion came from the rest of the question I received from my co-worker, which I neglected to include ..... > I also would have though so. My problem comes when I try to re-load a > database. The db_free() command in db.c, does the damage with the garbage > strings, and the the program dumps core with a SEGV. Note the key words - reloading. What this guy is seeing is the loss of the data space, because he is later trying to reload a string in there. Again, apologies for touching of the 'anti-dumb-question' alarms :) Cheers, Mike mjp@hplb.hpl.hp.com PS Talking of dumb questions, is anyone ever going to come forward with some of the code they have done for the features discussed for 2.2+ ?? Response so far : 1. From tinymuck-sloggers-owner Mon Apr 8 03:21:10 1991 Received: by belch.Berkeley.EDU (5.57/1.41) id AA28543; Mon, 8 Apr 91 02:55:25 -0700 Received: by belch.Berkeley.EDU (5.57/1.41) id AA28539; Mon, 8 Apr 91 02:55:14 -0700 Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Mon, 8 Apr 91 10:52:50 +0100 Received: by prudence.hpl.hp.com with SMTP (15.11/15.6+ISC) id AA07362; Mon, 8 Apr 91 09:53:51 gmt Message-Id: <9104080953.AA07362@prudence.hpl.hp.com> To: sloggers%prudence.hpl.hp.com@hplb.hpl.hp.com Subject: 2.2+, 2.3, 2.blubber ??? Date: Mon, 08 Apr 91 10:53:49 BST From: Mike Prudence Status: RO Hi Sloggers. Recently rearl@watnxt3.ucr.edu (Robert Earl) said: > PS. So it's 2.2+? I was hoping for it to be 2.3: 1) people already > hacked on theirs and it's common practice to list as 2.2+ if you have > local mods and 2) there won't be any chupchup-2.3 so you might as well > get my stamp of approval on one! :) All good points. I was using 2.2+ 'cos I like putting 'plus' on the end of things. 2.3 would be fine with me - anyone else got any feelings ?? Cheers, Mike mjp@hplb.hpl.hp.com From tinymuck-sloggers-owner Sat Aug 3 19:27:42 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA10585; Sat, 3 Aug 91 19:27:45 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA10581; Sat, 3 Aug 91 19:27:42 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA27649 sendmail 5.64/UCSD-2.1-sun via SMTP Sat, 3 Aug 91 19:26:54 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA04271 for tinymuck-sloggers@piggy.ucsb.edu; Sat, 3 Aug 91 19:27:28 pdt Date: Sat, 3 Aug 91 19:27:28 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108040227.AA04271@sdnp1.UCSD.EDU> To: tinymuck-sloggers, hawkeye@ucsd.edu, crash@glia.biostr.washington.edu Subject: self printing muf code Reply-To: dmoore@ucsd.edu Since this list is totally dead...I thought I'd just toss off a random piece of muf code just to bounce it around the net. :-) Anyways, the other day I wrote a little muf toy which prints it's own source code, and it used properties to do so. So today, I wrote one to work w/o properties. This is essentially a trade off of efficiency and readability. I could speed things up by moving the loop bounds all up by 2 and saving a 2 + in each pass, but then it wouldn't be clear. :) Anyways, enjoy or delete at your pleasure. Note that loop2 should be 1 contiguous line, and so should the "ed version of it, just in case your mailer does something strange to them. -- ~/mud/muf/self.muf -- ( This program dedicated to Firiss. 8/3/91 by OliverJones. ) : loop1 dup 5 > if pop exit then me @ over 2 + pick notify 1 + loop1 ; : loop2 dup not if pop exit then me @ over 2 + pick "\\\\" "\\" subst "\\\"" "\"" subst "\"" strcat " \"" swap strcat notify 1 - loop2 ; : loop3 dup 7 > if pop exit then me @ over 2 + pick notify 1 + loop3 ; : self_print ";" " 1 loop1 7 loop2 6 loop3" ": self_print" ": loop3 dup 7 > if pop exit then me @ over 2 + pick notify 1 + loop3 ;" ": loop2 dup not if pop exit then me @ over 2 + pick \"\\\\\\\\\" \"\\\\\" subst \"\\\\\\\"\" \"\\\"\" subst \"\\\"\" strcat \" \\\"\" swap strcat notify 1 - loop2 ;" ": loop1 dup 5 > if pop exit then me @ over 2 + pick notify 1 + loop1 ;" "( This program dedicated to Firiss. 8/3/91 by OliverJones. )" 1 loop1 7 loop2 6 loop3 ; -- ~/mud/muf/self.muf -- Wheee, OliverJones -- David Moore (I don't know what I am saying, why should anyone else.) E-Mail: dmoore@ucsd.edu ojones@ucsd.edu "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From tinymuck-sloggers-owner Mon Aug 5 15:39:29 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA15589; Mon, 5 Aug 91 15:39:35 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA15585; Mon, 5 Aug 91 15:39:29 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA23054; Mon, 5 Aug 91 15:38:35 -0700 Date: Mon, 5 Aug 91 15:38:35 -0700 From: blojo.member.cc Message-Id: <9108052238.AA23054@soda.berkeley.edu> To: tinymuck-sloggers Subject: Amazing X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] The following code fragment has probably been in edit.c for a long time. I'm fairly sure it was in there when I was bashing on the file about a year ago, though at the time my knowledge of C was sufficiently scant to keep me confused enough not to realize how silly the code was. q = p = linespec; while(*p) { while(*p && !isspace(*p)) *q++ = *p++; while(*p && isspace(*++p)); } *q = '\0'; Think we can get the author of said code to fess up? From tinymuck-sloggers-owner Mon Aug 5 16:40:34 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA15826; Mon, 5 Aug 91 16:40:36 -0700 Received: from netcomsv.netcom.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA15822; Mon, 5 Aug 91 16:40:34 -0700 Received: from netcom.netcom.com by netcomsv (4.1/SMI-4.1) id AA00824; Mon, 5 Aug 91 16:39:24 PDT Received: by netcom.netcom.com (4.1/SMI-4.1) id AA06471; Mon, 5 Aug 91 16:39:22 PDT From: foxen@netcom.com (Foxen / Fiera / LadyFox) Message-Id: <9108052339.AA06471@netcom.netcom.com> Subject: Amazing To: tinymuck-sloggers (TinyMUCK Tech. Mail List) Date: Mon, 5 Aug 91 16:39:20 PDT X-Mailer: ELM [version 2.3 PL11] blojo.member.cc once wrote: > The following code fragment has probably been in edit.c for a long time. > I'm fairly sure it was in there when I was bashing on the file about a year > ago, though at the time my knowledge of C was sufficiently scant to keep > me confused enough not to realize how silly the code was. > > q = p = linespec; > while(*p) { > while(*p && !isspace(*p)) *q++ = *p++; > while(*p && isspace(*++p)); > } > *q = '\0'; > > Think we can get the author of said code to fess up? Took me a few moments to see what I think you see. Lets see now... for (q = p = linespec; *p; p++) if (!isspace(*p)) *q++ = *p; *q = '/0'; Right? - Foxen (formerly Tygryss) ( Who is having to learn C the hard way very quickly ) -- ___ __ ___ _ . _^^ ____ foxen@netcom.com \ / | | \ | | | -> '-" \______/___/ Another Fine Furry Fan `v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the | |___ | \ | o //|| ||| Holy Furr of Bastis!" From tinymuck-sloggers-owner Mon Aug 5 20:00:10 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA17116; Mon, 5 Aug 91 20:00:12 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA17112; Mon, 5 Aug 91 20:00:10 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA06401; Mon, 5 Aug 91 19:59:11 -0700 Date: Mon, 5 Aug 91 19:59:11 -0700 From: blojo.member.cc Message-Id: <9108060259.AA06401@soda.berkeley.edu> To: foxen@netcom.com, tinymuck-sloggers Subject: Re: Amazing X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] > for (q = p = linespec; *p; p++) > if (!isspace(*p)) *q++ = *p; > *q = '/0'; Actually, that doesn't work. The code wasn't necessarily too silly in that it did things in a silly way, but that it did something in a silly way that was done in a less silly way over the next twenty lines of code, though those next twenty lines of code were, in fact, done somewhat sillily. From tinymuck-sloggers-owner Mon Aug 5 20:53:01 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA17367; Mon, 5 Aug 91 20:53:04 -0700 Received: from enet-gw.pa.dec.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA17363; Mon, 5 Aug 91 20:53:01 -0700 Received: by enet-gw.pa.dec.com; id AA26595; Mon, 5 Aug 91 20:52:05 -0700 Message-Id: <9108060352.AA26595@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Mon, 5 Aug 91 20:52:10 PDT Date: Mon, 5 Aug 91 20:52:10 PDT From: "That's me in the spotlight, losing my religion. 05-Aug-1991 2318" <"eris::callas"@eris.enet.dec.com> To: tinymuck-sloggers@Pa.dec.com Subject: What I've been upto... Well, with Muck 3.0 (and 2.3 even) on what seems to be indefinite hold, I've been hacking the server. I've added some things that I think are rather nice, and I'm going to post them here so people can throw brickbats, or put them on the list of things to be added to the standard distribution if they seem like a good idea. I suppose that soon I should consider declaring ErisMUCK to be a major variant. Sigh. Jon * A compile-load-and-go system to the MUF compiler so that programs don't have to be compiled when the game loads. ChupChup actually sent out patches for this to the standard distribution, but I did it first, nyah! * A security system to MUF which is very rudimentary, but stops the most overt forms of prying. I've discussed this here, and it's *supposed* to be a part of 2.3 if/when it's ever done. * A form of joint ownership. It's a change to the control() predicate that allows a person to put the property ".control to:dbref;dbref;...;dbref" on themselves, and the people with that dbref(s) get to control their stuff. People seem to like it here. * Changes to MUF to drive most things off of control rather than strict ownership. Also a CONTROL? MUF word. * Many of the discussed new MUF words in the proposed 2.3. * A function @checkdb that examines the stuff you control and shows things that are "unlinked." This means exits with no link, rooms that have no links, object homes, etc., and programs with no links to them (and are uncompiled -- see the CLG system above). This is an aid in finding cruft caused when people do something like "@dig w;west" instead of @open. * A function @slink that Shows the LINKs to an object. This is so that you can see who has things linked to your stuff. * An enhancement to @unlink so that you can unlink exits and droptos to your stuff. This is useful if you were so foolish as to have set something LINK_OK (or granted control to someone you no longer like) and now regret it. I have not enhanced this so you can banish the homes of players and things. * An enhancement to @recycle so that exits that are *linked* *to* a recycled object are recycled. Combined with @slink, you can unlink exits you like before you blow something away. This also reduces database clutter. * I removed (shock horror) the KILL command. I replaced it with TIDY. You can tidy another player for free, sending that player home (and their stuff, too), but you can only TIDY up sleeping players. It piggy-backs on the same function I did for the AWAKE? MUF word. * Cash back on recycling. If a player was clever enough to create things in 5p increments, they get all the cash back for recycling an object. If not, then they may lose up to 4p. Hey, what can I say... There are two possible undesirable side-effects: (1) the accumulated cash for recycled exits goes to the recycler. No one has complained about this, and as easy as it is to gain pennies, I don't see this as a problem. (2) This makes an easy way to accumulate cash via COPYOBJ and @recycle. Again, it's *so* easy to get pennies that I don't see this as a problem. I did, however, lower the max number of pennies carried to 1,000. People who want to accumulate pennies can do it by making items. * I experimented for a time by granting universal control to CHOWN_OK objects (except players). Some people like it, some don't. The non-intuitive side-effect here is that CHOWN_OK items show up in @FIND (and @CHECKDB). We are currently running without it. The problems it solves are solved better by the joint-ownership code. Jon From tinymuck-sloggers-owner Mon Aug 5 21:14:59 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA17702; Mon, 5 Aug 91 21:15:02 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA17698; Mon, 5 Aug 91 21:14:59 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA07159 sendmail 5.64/UCSD-2.1-sun via SMTP Mon, 5 Aug 91 21:14:06 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA06132 for tinymuck-sloggers@piggy.ucsb.edu; Mon, 5 Aug 91 21:14:40 pdt Date: Mon, 5 Aug 91 21:14:40 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108060414.AA06132@sdnp1.UCSD.EDU> To: tinymuck-sloggers Subject: What I've been upto... In-Reply-To: "That's me in the spotlight, losing my religion. 05-Aug-1991 2318"'s message of Mon, 5 Aug 91 20:52:10 PDT <9108060352.AA26595@enet-gw.pa.dec.com> Reply-To: dmoore@ucsd.edu Some of those suggestions sound good. Now when you say 2.3 are you referring the 2.3 which was debated in this mailing list a few monthes back. If so, that never really recieved (to my knowledge) official sanctioning for that name from Robert who is the current maintainer of muck. And I am pretty sure that I was on a running 2.3, egads was it a year ago!, which got tossed in hopes of going to 3.0. Anyways, as far as I know 3.0 is being worked on now, but was delayed due to loss of computer resources. So can we come up with a different name for the "2.3" that was being bashed around a while back in this list, just to keep different versions straight. Also, I got the impression that you implemented @checkdb, @slink, tidy (and overriding of kill) in the server. If you did, I'd just like to mention that these are all readily writeable in muf (since you already had awake? for example) and would therefore be more portable and useful to other mucks. I have a very nice db_loop program, however a bug in 2.2 which has not been tracked down makes it more obnoxious to use. The changes to allow @unlink to affect things which are linked to things you own sound very good. Note that if you had a RECYCLE muf primitive you could have also implemented this in muf nicely reducing the number of changes to the server. David "OliverJones" Moore ps: If anyone is interested in db_loop, I can mail it to you. Basic format is db_loop ( d -- ) and it goes through the entire db (runs in vanilla 2.2) calling the dbref passed to it (ie a program) on each item in the database. It was supposed to work by passing the address of the function to use, so you don't have to use multiple program objects to do db looping, but as I said a strange bug sometimes occurs. -- David Moore (I don't know what I am saying, why should anyone else.) E-Mail: dmoore@ucsd.edu ojones@ucsd.edu "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From tinymuck-sloggers-owner Tue Aug 6 09:57:32 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA18923; Tue, 6 Aug 91 09:57:35 -0700 Received: from drums.reasoning.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA18919; Tue, 6 Aug 91 09:57:32 -0700 Received: from cymbal.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef) id AA03446; Tue, 6 Aug 91 09:56:36 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by cymbal.reasoning.com. (4.0/SMI-4.0) id AA23488; Tue, 6 Aug 91 09:56:34 PDT Date: Tue, 6 Aug 91 09:56:34 PDT From: nils@cymbal.reasoning.com (Nils McCarthy) Message-Id: <9108061656.AA23488@cymbal.reasoning.com.> To: dmoore@ucsd.edu Cc: tinymuck-sloggers In-Reply-To: David Moore's message of Mon, 5 Aug 91 21:14:40 pdt <9108060414.AA06132@sdnp1.UCSD.EDU> Subject: Re: What I've been upto... things you own sound very good. Note that if you had a RECYCLE muf primitive you could have also implemented this in muf nicely reducing the number of changes to the server. You'd have to be careful with a RECYCLE muf primitive. Strange things happen when you recycle a program you're running(or editing), even crashing the whole muck. From tinymuck-sloggers-owner Tue Aug 6 16:52:41 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20241; Tue, 6 Aug 91 16:52:45 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20237; Tue, 6 Aug 91 16:52:41 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA03029; Tue, 6 Aug 91 16:51:50 -0700 Message-Id: <9108062351.AA03029@soda.berkeley.edu> To: tinymuck-sloggers Subject: Re: Amazing X-Face: (4D-osoq?}7M3\EgvbWKo Date: Tue, 06 Aug 91 16:51:48 -0700 From: dougo@soda.berkeley.edu > The following code fragment has probably been in edit.c for a long time. > I'm fairly sure it was in there when I was bashing on the file about a year > ago, though at the time my knowledge of C was sufficiently scant to keep > me confused enough not to realize how silly the code was. > > q = p = linespec; > while(*p) { > while(*p && !isspace(*p)) *q++ = *p++; > while(*p && isspace(*++p)); > } > *q = '\0'; > > Think we can get the author of said code to fess up? This code doesn't seem particularly silly when taken out of context. It looks like it's just deleting whitespace from the string linespec. What is it supposed to be doing? And why is it so silly? DougO From tinymuck-sloggers-owner Tue Aug 6 17:01:49 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20270; Tue, 6 Aug 91 17:01:51 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20266; Tue, 6 Aug 91 17:01:49 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA03291; Tue, 6 Aug 91 17:00:54 -0700 Date: Tue, 6 Aug 91 17:00:54 -0700 From: blojo.member.cc Message-Id: <9108070000.AA03291@soda.berkeley.edu> To: dougo@soda.berkeley.edu, tinymuck-sloggers Subject: Re: Amazing X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] Oh, never mind. I guess it's not quite that funny out of edit.c. From tinymuck-sloggers-owner Wed Aug 7 01:21:08 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA22395; Wed, 7 Aug 91 01:21:11 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA22391; Wed, 7 Aug 91 01:21:08 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA03809; Wed, 7 Aug 91 01:20:15 -0700 Message-Id: <9108070820.AA03809@soda.berkeley.edu> To: tinymuck-sloggers Subject: Re: self printing muf code X-Face: (4D-osoq?}7M3\EgvbWKo Date: Wed, 07 Aug 91 01:20:14 -0700 From: dougo@soda.berkeley.edu > Anyways, the other day I wrote a little muf toy which prints it's > own source code, and it used properties to do so. So today, I wrote one > to work w/o properties. This is essentially a trade off of efficiency and > readability. I could speed things up by moving the loop bounds all up > by 2 and saving a 2 + in each pass, but then it wouldn't be clear. :) > Anyways, enjoy or delete at your pleasure. Note that loop2 should be 1 > contiguous line, and so should the "ed version of it, just in case your > mailer does something strange to them. > > -- ~/mud/muf/self.muf -- > > ( This program dedicated to Firiss. 8/3/91 by OliverJones. ) > : loop1 dup 5 > if pop exit then me @ over 2 + pick notify 1 + loop1 ; > : loop2 dup not if pop exit then me @ over 2 + pick "\\\\" "\\" subst "\\\"" "\"" subst "\"" strcat " \"" swap strcat notify 1 - loop2 ; > : loop3 dup 7 > if pop exit then me @ over 2 + pick notify 1 + loop3 ; > : self_print > ";" > " 1 loop1 7 loop2 6 loop3" > ": self_print" > ": loop3 dup 7 > if pop exit then me @ over 2 + pick notify 1 + loop3 ;" > ": loop2 dup not if pop exit then me @ over 2 + pick \"\\\\\\\\\" \"\\\\\" subst \"\\\\\\\"\" \"\\\"\" subst \"\\\"\" strcat \" \\\"\" swap strcat notify 1 - loop2 ;" > ": loop1 dup 5 > if pop exit then me @ over 2 + pick notify 1 + loop1 ;" > "( This program dedicated to Firiss. 8/3/91 by OliverJones. )" > 1 loop1 7 loop2 6 loop3 > ; > > -- ~/mud/muf/self.muf -- Okay, I think this one wins the First Annual Obfuscated MUF contest. Send entries to the Second Annual Obfuscated MUF Contest to tinymuck-sloggers@piggy.ucsb.edu. Entries will be judged primarily on unreadability, though it should actually do something (not necessarily useful). Elegance is a plus. From tinymuck-sloggers-owner Wed Aug 7 07:58:48 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA22813; Wed, 7 Aug 91 07:58:50 -0700 Received: from ux1.cso.uiuc.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA22809; Wed, 7 Aug 91 07:58:48 -0700 Received: by ux1.cso.uiuc.edu id AA17442 (5.65c/IDA-1.4.4 for tinymuck-sloggers@piggy.ucsb.edu); Wed, 7 Aug 1991 09:57:45 -0500 Date: Wed, 7 Aug 1991 09:57:45 -0500 From: Wanderer Message-Id: <199108071457.AA17442@ux1.cso.uiuc.edu> To: tinymuck-sloggers Subject: mailing list Please remove me from the mailing list. From tinymuck-sloggers-owner Wed Aug 7 12:17:33 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA23220; Wed, 7 Aug 91 12:17:35 -0700 Received: from netcomsv.netcom.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA23216; Wed, 7 Aug 91 12:17:33 -0700 Received: from netcom.netcom.com by netcomsv (4.1/SMI-4.1) id AA09976; Wed, 7 Aug 91 12:16:22 PDT Received: by netcom.netcom.com (4.1/SMI-4.1) id AA08825; Wed, 7 Aug 91 12:16:19 PDT From: foxen@netcom.com (Foxen / Fiera / LadyFox) Message-Id: <9108071916.AA08825@netcom.netcom.com> Subject: Recycling Programs. To: tinymuck-sloggers (TinyMUCK Tech. Mail List) Date: Wed, 7 Aug 91 12:16:17 PDT X-Mailer: ELM [version 2.3 PL11] Okay, I just did some testing, and found a fun new way of crashing MUCK2.2. if a program is @chowned, and recycled by a wizard, say, while a player is still in the editor, then when they quit insert mode, if dies with a crash. Going down - Bye. So it turns out that the @recycle command *doesn't* check if someones doing something to the program. Looks like something in need of a bugfix to me. - Foxen -- ___ __ ___ _ . _^^ ____ foxen@netcom.com \ / | | \ | | | -> '-" \______/___/ Another Fine Furry Fan `v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the | |___ | \ | o //|| ||| Holy Furr of Bastis!" From chupchup Wed Aug 7 15:25:55 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA23784; Wed, 7 Aug 91 15:25:56 -0700 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA23780; Wed, 7 Aug 91 15:25:55 -0700 Date: Wed, 7 Aug 91 15:25:55 -0700 From: Robert Earl Message-Id: <9108072225.AA23780@piggy.ucsb.edu> To: tinymuck-sloggers Subject: Recycling Programs. References: <9108071916.AA08825@netcom.netcom.com> Reply-To: rearl >>>>> On Wed, 7 Aug 91 12:16:17 PDT, foxen@netcom.com (Foxen / Fiera / LadyFox) said: Foxen> So it turns out that the @recycle command *doesn't* check if Foxen> someones doing something to the program. It's nearly impossible to determine if someone is doing something with a given program. It's not enough to sweep the database and check if a player is editing it, or if a player is running it and in a READ. (The reason is left as an exercise for the reader.) It would be easiest just to zero the recycled object (program) out, without freeing any pointers. This would waste memory which can't be reclaimed until a reboot. Foxen> Looks like something in need of a bugfix to me. -- ______________________________________________________________________ robert earl / rearl@piggy.ucsb.edu \ "Supercalifragilisticsadomasochism!" From tinymuck-sloggers-owner Wed Aug 7 15:53:01 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA23852; Wed, 7 Aug 91 15:53:07 -0700 Received: from jolt.eng.umd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA23848; Wed, 7 Aug 91 15:53:01 -0700 Received: by jolt.eng.umd.edu (5.65+(UMDENG)/umdeng-0.4/09-20-90) id AA24724; Wed, 7 Aug 91 18:52:31 -0400 Date: Wed, 7 Aug 91 18:52:31 -0400 From: buzzard@eng.umd.edu (Sean Barrett) Message-Id: <9108072252.AA24724@jolt.eng.umd.edu> To: rearl, tinymuck-sloggers Subject: Re: Recycling Programs. Add a reference count of actively run programs (& being-editted programs) and refuse to recycle if non-0? From tinymuck-sloggers-owner Wed Aug 7 16:53:28 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA24030; Wed, 7 Aug 91 16:53:34 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA24026; Wed, 7 Aug 91 16:53:28 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA19774 sendmail 5.64/UCSD-2.1-sun via SMTP Wed, 7 Aug 91 16:52:31 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA07828 for tinymuck-sloggers@piggy.ucsb.edu; Wed, 7 Aug 91 16:53:02 pdt Date: Wed, 7 Aug 91 16:53:02 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108072353.AA07828@sdnp1.UCSD.EDU> To: tinymuck-sloggers In-Reply-To: Sean Barrett's message of Wed, 7 Aug 91 18:52:31 -0400 <9108072252.AA24724@jolt.eng.umd.edu> Subject: Recycling Programs. Reply-To: dmoore@ucsd.edu Date: Wed, 7 Aug 91 18:52:31 -0400 From: buzzard@eng.umd.edu (Sean Barrett) Add a reference count of actively run programs (& being-editted programs) and refuse to recycle if non-0? The problem with this is that someone can be editing a program and not be connected, etc. Of course there are mucks which will bring you back to the top level on a disconnect. Ie, you can keep a program from being recycled by a wizard ever if you have some dummy character stuck in a read on it, etc. From tinymuck-sloggers-owner Thu Aug 15 21:12:00 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA08666; Thu, 15 Aug 91 21:12:02 -0700 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA08661; Thu, 15 Aug 91 21:12:00 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA849885; Thu, 15 Aug 91 21:11:07 -0700 Date: Thu, 15 Aug 91 21:11:07 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9108160411.AA849885@nike.calpoly.edu> To: tinymuck-sloggers Subject: Oh, stuff... Ok... There's a file on watnxt3.ucr.edu named pub/belch.archive/tinymuck/new_sanity.c That I wrote/slapped together quite some time ago, along with a little note which basically said "Try me! (and mail me info on how well it works)". To date I have received no replies, so I figure no one has seen it :) It's meant to replace sanity.c in the vanilla code, and _should_ compile fine. Try it, maybe you'll like it... ALSO.... PythonMUCK is running at zeus.calpoly.edu 4201, and we have a working type DAEMON. We access through the SLEEP primitive... SLEEP ( i -- ) causes the current program to stop execution and creates a DAEMON to continue running the program i seconds later... No, it's not a silly nasty Kludge bot or anything, it's all in the server. I will release DAEMON code to anyone who asks... Unfortunately, our site is !stable right now (zeus has power supply problems), but that is promised to be remedied. OH! almost forgot. Claudius and I are working on taking out the huge switch of-a-pain-in-the-ass-computationally-speaking dispatch(); in interp.c We're making it an array of pointers to functions, so you can call a primitive straight from a number, and not do 100 odd compares on the way. We'll also release those mods when we're done. [WARNING: BLATANT PLUG!] All this and more at zeus.calpoly.edu 4201, mail awozniak@morpheus.calpoly.edu for a character! (we do have a guest character) (we're also _very_ small and looking for _good_ builders...) --Doran awozniak@morpheus.calpoly.edu From tinymuck-sloggers-owner Thu Aug 15 22:42:36 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA08863; Thu, 15 Aug 91 22:42:38 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA08859; Thu, 15 Aug 91 22:42:36 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA119195; Thu, 15 Aug 91 22:41:55 -0700 Date: Thu, 15 Aug 91 22:41:55 -0700 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9108160541.AA119195@nike.calpoly.edu> To: tinymuck-sloggers Subject: please subscribe:claudius@zeus.calpoly.edu thanks a great deal. From tinymuck-sloggers-owner Thu Aug 22 12:38:36 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29603; Thu, 22 Aug 91 12:38:38 -0700 Received: from orion.oac.uci.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29598; Thu, 22 Aug 91 12:38:36 -0700 Received: from orion.oac.uci.edu by orion.oac.uci.edu id aa18012; 22 Aug 91 12:32 PDT To: tinymuck-sloggers Date: Thu, 22 Aug 91 12:32:06 -0700 From: Jack Dietz Message-Id: <9108221232.aa18012@orion.oac.uci.edu> 19 August 1991 Here are some poured concrete slabs for me to stand on as I advocate adding features to MUCK. Note that (at least for the summer) I have no UNIX system at hand, let alone something I can test this on; I don't even have a good version of 'diff'. I'm just writing this down to see if it will work -- these are not tested. LOOPS: o It is _very_ easy to add loops to the existing server. As an example: (Make a list of all the players online:) : user-string ( -- s ) online 1 + index ! "" do swap name strcat ", " strcat index @ 1 - dup index ! 0 = until ; Introducing the 'do...until' primitive pair. The principle is that each time it hits 'until' it jumps back to the 'do' if the number on the stack is zero. Now, an 'if' primitive jumps forward to the then if the number on the stack is zero. So, an 'until' can be compiled to the 'if' primitive! No changes are needed to the interpreter. And all the compiler needs to do is use the if-stack to hold 'do's as well. All it needs to do is have the 'do' put its address onto the if-stack, and the 'until' pulls it off and compiles to an 'if'. Now, the problem with loops is the chance of an infinite loop, which would crash the server. In order to get around this there must be an extra field in the frame which counts the number of primitives executed. Each time a primitive is executed a counter must be incremented and tested. If it overruns a pre-set limit, say 500 for programs set DEBUG, some larger number for standard programs, and a very large but finite number for wizard programs (programs set W or with SS 6 or 7...), the interpreter should abort. Text for muf.manual, in the same stilted style: do ... until ( x -- ) Do marks the beginning of a loop of things to be done, and until marks the end. Until expexts boolean value x. If x is TRUE, the loop is not repeated -- control leaves the loop. If x is FALSE, control is transfered to the statement following the do. Note that checking the top of the stack actually pops it, so if you want to re-use it, you should dup (see DUP) it before the until. For every do in a word, there MUST be an until, and vice-versa. Hastily-written code for do..until: compile.c: /* in process_special(): */ else if (!string_compare(token, "DO")) { new = new_inst(); new -> no = nowords++; new -> in.type = PROG_PRIMITIVE; new -> in.data.number = IN_NOP; // Needs a new NO-OP primitive. addif(new); // Something like 'swap swap' or return new; // 'dup pop' could be substituted, } // but a specific no-op would be // cleaner and faster. This will // be used as a place-holder. */ else if (!string_compare(token, "UNTIL")) { struct INTERMEDIATE *doo; // 'do' is reserved... struct INTERMEDIATE *curr; doo = find_if(); if (!doo) abort_compile("UNTIL without DO."); if (doo -> in.type != PROG_PRIMITIVE) // Note that any IF in the abort_compile("UNTIL without DO."); // if-stack will point to new -> new_inst(); // a type PROG_ADD object. new -> no = nowords++; new -> in.type = PROG_ADD; new -> in.data.call = (doo -> no) + 1; new -> next = new_inst(); curr = new -> next; curr -> no = nowords++; curr -> in.type = PROG_PRIMITIVE; curr -> in.data.number = IN_IF; return new; } /* in special(): */ && string_compare(token, "DO") && string_compare(token, "UNTIL) Code for a NO-OP primitive: inst.h: #define IN_NOP xx inst.c: (Only if 'no-op' is to be a user primitive... :) /* in const char *base_inst[]: */ "NOP", interp.c: /* in dispatch(): */ case IN_NOP: break; Code for a primitive count: db.h: /* in struct frame */ int count, maxcount; interp.c: /* in interp(): */ fr -> count = 0; fr -> maxcount = MAXPCOUNT; /* MAXCOUNT should probably have three different values: one for programs set DEBUG, one for standard programs, and one for programs set W and owned by wizards. */ /* in interp_loop(): */ while (stop) { + if (fr -> maxcount <= (fr -> count)++) + abort_loop("Error: Program executed too long."); if ... There it is -- I'd like any comments you have. Working, -- Jack Dietz. (jdietz@ucsd.edu)  From tinymuck-sloggers-owner Thu Aug 22 12:38:43 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29614; Thu, 22 Aug 91 12:38:45 -0700 Received: from orion.oac.uci.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29610; Thu, 22 Aug 91 12:38:43 -0700 Received: from orion.oac.uci.edu by orion.oac.uci.edu id aa18037; 22 Aug 91 12:33 PDT To: tinymuck-sloggers Date: Thu, 22 Aug 91 12:32:50 -0700 From: Jack Dietz Message-Id: <9108221233.aa18037@orion.oac.uci.edu> 20 August 1991 One of the gripes I have heard about MUF is that the variable frame is static for an entire run. That is, any called program has to either save all 53 variables from the caller on the stack and rotate its parameters up, or else hope that the caller didn't have any important vars. Neither is really satisfactory. A facility for automatically and transparently saving variables each time a program is called is needed to alleviate this problem. In order to save the variables for each program transparently, the current variable array must be either abandoned or separated from the stack frame. Other proposals seem to create a new stack frame for each call, which is both time-consuming (to clear the 6K or so and to copy over the 'A'stack) and wasteful of space. One possibility is to create a new variable array only for each call. This saves some space, but seems inflexible -- some programs could do with arrays of variables, others need none. My proposal is to remove the variable array, and create a new variable stack. This stack would allocate only the space each program needs for its variables, and grow downward from the top of the 'A'stack frame. _____ _____ _____ _____ | | | | | 'V' | | | ! The variable stack would | | | | |==v==| | | ! grow downwards, using the | | |==^==| _____ | | |==^==| ! under-utilized 'A'stack's |==^==| | | | | |==^==| | | ! space. This allows a space | 'A' | | 'S' | | 'V' | | 'A' | | 'S' | ! trade-off between arugments ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ! and variables. 1. Current stack frame. 2. Proposed stack frame. The following diagram shows the proposed use of the 'V'stack. The variables are currently numbers (of type PROG_VAR) which are used as indexes into the array of variables. Under this system, they would become offsets added to the VP (so that '3 variable' would translate to [VP + 3]. < VP = 509 > ________ < Top of frame | This is the variable list during 511 | #-3 | v2 < | a sample program. Three variables 510 | 42 | v1 < Current vars | have been allocated and used, holding 509 |"foobar"| v0 <- VP | "foobar", 42, and #-3 respectively. 508 | | | The VP points to v0, "foobar". Note that there is no change to the compiler's use of variables, only the interpreter's. All the compiler needs to do is save the number of variables the program uses. Now, how does this affect program calls? Each time a new program is invoked, the VP is decremented by the number of variables that program uses. When that program is returned from, the VP is incremented by the same number. Here's how that would work: < VP = 506 > ________ < Top of frame | This is the state of the variable 511 | # -3 | | frame after that program has called 510 | 42 | | another one. Its variables, which 509 |"foobar"| | it refers to as v0, v1, and v2, are 508 | #2181 | v2 < | different from the caller's variables. 507 | 64 | v1 < Current vars | Note that it could still refer to the 506 |"grapes"| v0 <- (VP) | caller's variables as v3 and up. 505 | | | This could be useful for debugging. So that is the scheme for variables. But how does that affect the code? Two changes need to be made. One is that the code for setting and fetching variables needs to be changed slightly. But the other is that calls and returns must handle saving and restoring those variables transparently to the calling program _and_transparently_to_the_compiler_, if possible. Here is my idea for that. We still have the system stack for holding addresses for returns. Unfortunately, right now a return cannot tell the difference between returning from another word in the same program and returning from another program. One way to handle that is to make a different primitive for returning from programs, like Return From Interrupt in most assembly languages. But that necessitates a change in the compiler, not good. Instead, 'call' can save the address as normal, but with a different type, 'PROG_CADDR' or something. Then a 'ret' can tell the difference and update the variable stack. 5 | | | <- 'stop' | Returning to
is handled as 4 |a|
| | normal. ('a' designated an address, 3 |c| <#432> | | 'c' a cross-program address.) 'ret' 2 |a|| | just restores the old pc. But the 1 |a|| | next 'ret' hits an address in #432, 0 |a|
| | which causes it to add (fr -> vars) ~ ~~~~~~~~ | to the vp before restoring the pc. Note that there are problems with the static variables, 'me', 'loc' and 'trigger'. There are three possibilities: 1. They can be added to each variable frame. It would indeed be possible to have each program have at least three variables, although it would slow calls to have these three assigned (not to mention waste space). This has the advantage of allowing called SETUID programs change these values. 2. They can be specially reserved. Either an array of three spaces can be reserved for them, or they can always refer to MAX_STACK - 1, 2, and 3. This has the disadvantage of making @ and ! check for variables 0, 1 and 2 specifically. 3. Three new primitives can be intoduced, allowing a simple translator written in 'C' to strip the @'s and !'s following them. In any case, someone's going to have to take care of it. Here is an outline of the changes that need to be made: (My sample code follows, but this is a list if someone else decides to make different tradeoffs.) db.h: A field needs to be added to 'union specific: type program' to keep the number of variables each program requires. The new 'PROG_CADDR' type needs to be added. compile.c: The compiler needs to update the number of variables required by the program. This could be done by counting the number of variables as it cleans the structure holding variable names. interp.c: The frame needs both a variable pointer and the number of variables in the current program. It can dispose of the variable array. On initialization, the variable pointer needs to be assigned the value (MAX_STACK - vars). The number of variables for the program needs to be fetched from the object. 'call' needs to save the current pc as a different type, 'PROG_CADDR' or something. It also needs to get the new value of 'fr -> vars' and update the variable pointer. 'ret' needs to have code added to handle the case of a 'PROG_CADDR' operand. This code needs to update the variable pointer and get the old value of 'fr -> vars' from the object. 'at' and 'bang' need to be able to handle the new structure. References need to use the variable pointer as an index and the variable number as an offset. They also need to check for references beyond the top of the stack, which are a definite no-no. Here are my provisional changes to interp.c. The following assumptions are made: 1. Each program has a field called 'vars' which holds the number of variables it uses. Also, the 'variables[MAX_VAR]' has been replaced with 'variables[]', which is the same as 'vp' mentioned in the docs. 2. 'me', 'loc' and 'trigger' are treated as normal -- each program's variable frame will contain them. (This requires the smallest change to the existing compiler. It also wastes space but removes the security hole that 'me' can be changed before a call.) These are also quite untested (I outlined my limitations in the previous letter) and are to be used as something to comment about and not to install yet. /* in interp(): */ fr -> pc = DBFETCH(program)->sp.program.start; + fr -> variables = fr -> argument.st[STACK_SIZE]; + fr -> variables -= DBFETCH(program)->sp.program.vars; fr -> writeonly = (Typeof(source) == TYPE_ROOM); /* in prog_clean(): */ x for (i = 0; i < MAX_VAR; i++) x CLEAR(&fr -> variables[i]); /* in interp_loop(): */ /* case IN_EXECUTE: */ abort_loop("Program word: Stack Overflow"); + sys[stop].type = PROG_ADD; sys[stop++].data.call = pc + 1; /* case IN_CALL: */ /* Note: This is before the compile-on-demand patch. That would be pretty easy to merge once I got a copy. */ abort_loop("CALL: Stack Overflow"); + sys[stop].type = PROG_CADDR; sys[stop++].data.call = pc + 1; + *variables -= DBFETCH(temp1->data.objref)->sp.program.vars; + if (*variables <= *arg[atop]) + abort_loop("CALL: Variable stack overflow."); + variables[0].type = PROG_OBJECT; + variables[0].data.number = player; + variables[1].type = PROG_OBJECT; + variables[1].data.number = DBFETCH(player)->location; + variables[2].type = PROG_OBJECT; + variables[2].data.number = source; pc = DBFETCH(temp1->data.objref)->sp.program.start; /* case IN_RET: */ case IN_RET: + if (sys[--stop].type = PROG_CADDR) + { + *variables += DBFETCH(program)->sp.program.vars; + } ! pc = sys[stop].data.call; break; /* in dispatch(): */ /* case IN_AT, IN_BANG: */ ! if (temp1.type != PROG_VAR || ! *variables[temp1.data.number > *arg[STACK_SIZE]) abort_interp("Non-variable argument."); And the necessary change to compile.c: NOTE: As it stands, there is still a limit of 53 variables per program. With these changes that should be more like 500, but I don't know enough about the code to make the variable list a linked list. /* in copy_program(): */ set_start(); + set_vars(); cleanup(); /* add function set_vars(): */ void set_vars() { int i; for (i = 0; i < MAX_VAR; i++) if (!variables[i]) break; DBSTORE(program, sp.program.vars, i); } And the necessary changes to db.h: /* in union special, struct program */ int siz; + int vars; int curr_line; /* in defines 'stack and object declarations' */ #define PROG_VAR 6 /* variables */ #define PROG_CADDR 7 /* addresses that cross program lines -- interpreter's use only */ #define MAX_VAR 53 /* maximum number of variables including ... I hope this idea will improve the quality of MUF programming and allow larger problems to be tackled. Please mail me any comments you have. -- Jack Dietz. (jdietz@ucsd.edu)  From tinymuck-sloggers-owner Thu Aug 22 13:24:02 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29713; Thu, 22 Aug 91 13:24:04 -0700 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29709; Thu, 22 Aug 91 13:24:02 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA814398; Thu, 22 Aug 91 13:21:56 -0700 Date: Thu, 22 Aug 91 13:21:56 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9108222021.AA814398@nike.calpoly.edu> To: jdietz@orion.oac.uci.edu, tinymuck-sloggers Subject: Variables.... I didn't have time to read jdietz's letter completely, but just a small thought/question: I've heard (snicker) Xroads has local variables for MUF programs. Anyone know they handled the problem? Or will we need to wait to look at the 2.2fb code? --Doran From chupchup Thu Aug 22 13:33:21 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29753; Thu, 22 Aug 91 13:33:23 -0700 Received: by piggy.ucsb.edu via UUCP (Sendmail 5.65b/1.05) id AA29749; Thu, 22 Aug 91 13:33:21 -0700 Date: Thu, 22 Aug 91 13:33:21 -0700 Message-Id: <9108222033.AA29749@piggy.ucsb.edu> From: chupchup (Robert Earl) To: tinymuck-sloggers Subject: Variables.... References: <9108222021.AA814398@nike.calpoly.edu> Reply-To: rearl When I was working on 3.0 I had local variables written, and the idea was basically "keep a variable pointer array as large as the stack. allocate a hunk of variables each time you go into a procedure, clean up and free them all when you exit." it was potentially very hoggish though, since the default number of variables in a program is/was 53, and people usually don't use that many so the spots get wasted. Later I decided to do away with the 53 magic number, and allocate all the variables the user wanted, and keep that total on the program, so Jack of course has a good point suggesting that scheme. The stickiest problem I had though, was something to do with the presets, "me", "loc", "trigger". But I can't remember what. :-) I think it was that, calling a program, there could be no way to find a suitable value for "trigger". Foxen, how does Xroads' server do it? -- ______________________________________________________________________ robert earl / "Obviously then a Woman is not to be rearl@piggy.ucsb.edu \ irritated as long as she is in a position / where she can turn round." From tinymuck-sloggers-owner Thu Aug 22 14:01:00 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29835; Thu, 22 Aug 91 14:01:02 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29831; Thu, 22 Aug 91 14:01:00 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA160563; Thu, 22 Aug 91 14:00:05 -0700 Date: Thu, 22 Aug 91 14:00:05 -0700 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9108222100.AA160563@nike.calpoly.edu> To: tinymuck-sloggers Subject: Loops and other ideas Ok, loops can be a good thing, this made me thing up another great [tm] idea: Use the instruction counter ONLY, making the address and workspace stacks linked-lists... Advantages: no more 'top' checking, you'll always have the space. no more address-stack checking either dynamic use of the space available loops are no problem at all Disadvantages: more allocation and deallocation time complex stack operations on the workspace stack would take considerably longer [well, rotate won't, but pick and put will take N searches versus 1.] How do people like this idea? [personally, it makes it much more orthogonal and clean] From tinymuck-sloggers-owner Thu Aug 22 14:05:31 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29868; Thu, 22 Aug 91 14:05:34 -0700 Received: from netcomsv.netcom.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29860; Thu, 22 Aug 91 14:05:31 -0700 Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA20265; Thu, 22 Aug 91 14:04:04 PDT Received: by netcom.netcom.com (4.1/SMI-4.1) id AA19518; Thu, 22 Aug 91 14:04:03 PDT From: foxen@netcom.com (Foxen) Message-Id: <9108222104.AA19518@netcom.netcom.com> Subject: Local Variables on XRoads. To: tinymuck-sloggers (TinyMUCK Tech. Mail List) Date: Thu, 22 Aug 91 14:04:02 PDT X-Mailer: ELM [version 2.3 PL11] Robert Earl once wrote: > > The stickiest problem I had though, was something to do with the > presets, "me", "loc", "trigger". But I can't remember what. :-) I > think it was that, calling a program, there could be no way to find a > suitable value for "trigger". Foxen, how does Xroads' server do it? Well, the way I originally make local variables was to keep a stack of variable arrays that I would allocate and push onto the stack on a call (copying over the old values), and clear and pop off on a IN_PROGRAM. The program frame had a stack of pointers to variable arrays. Only problem with this, is that it breaks peoples code. In fact, (No names mentioned), One player was using variables to pass arguments back and forth in a rather important set of routines. So, It wen't back to the drawing board. Now, you can either use global variables, specified with 'var ' or local variables that you can specify with 'lvar varname'. Globals are handled exacly like normal variables in 2.2 MUF. Local variables are a new stack data type, so that IN_BANG, and IN_AT can handle them as appropriate, where local variables are used from a stack of variable arrays, and globals are from a standard array in the program frame. So far as I know of, XRoads will run any normal 2.2 programs without crashing them, unless they overrun the max. instruction count. - Foxen From tinymuck-sloggers-owner Thu Aug 22 14:10:32 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29897; Thu, 22 Aug 91 14:10:35 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29893; Thu, 22 Aug 91 14:10:32 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA23567 sendmail 5.64/UCSD-2.1-sun via SMTP Thu, 22 Aug 91 14:09:31 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA05848 for tinymuck-sloggers@piggy.ucsb.edu; Thu, 22 Aug 91 14:10:04 pdt Date: Thu, 22 Aug 91 14:10:04 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108222110.AA05848@sdnp1.UCSD.EDU> To: tinymuck-sloggers In-Reply-To: King_Claudius's message of Thu, 22 Aug 91 14:00:05 -0700 <9108222100.AA160563@nike.calpoly.edu> Subject: Loops and other ideas Reply-To: dmoore@ucsd.edu Well, there were loops at one time in tinymuck. And they were removed, because people would tend to loop a lot. Just think about your friendly neighborhood muck which gives out free mucker bits. Now imagine that first time mucker sees a loop command. Now you don't have the stack limit to protect you from him locking everything up. Certainly the stack limit isn't a good way to stop bad loops, since it is quite easy to write something which loops an arbitrarily number of times even with the limit, most people don't get aware of this until the point where they understand what is going on a bit better. As far as using a linked list for the stack, it seems to me to be extremely unefficient, both for doing operations and the massive overhead of creating and deleting nodes (I guess you'd want to put unused nodes onto a free list or something and reuse them, than free/malloc). If you really want more stack space on your local muck, just change an errant 512 into 2048 or some other size which works better for you. David "OliverJones" Moore From chupchup Thu Aug 22 14:27:10 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29955; Thu, 22 Aug 91 14:27:11 -0700 Received: by piggy.ucsb.edu via UUCP (Sendmail 5.65b/1.05) id AA29951; Thu, 22 Aug 91 14:27:10 -0700 Date: Thu, 22 Aug 91 14:27:10 -0700 Message-Id: <9108222127.AA29951@piggy.ucsb.edu> From: chupchup (Robert Earl) To: tinymuck-sloggers Subject: Local Variables on XRoads. References: <9108222104.AA19518@netcom.netcom.com> Reply-To: rearl Grumble. That's kind of what I thought, and it's far too complex, and it's not my style to kludge the right stuff (locals) in just because there's SOME existing code that uses the unpopular stuff (globals). But I've been wrong before. So, your mission, MUFfers, is to prove that there's too much code using the global variables in this way, and throwing them out would break things. Personally, I have seen more software that kludges around global variables, like this var a var b var c var d var e var f var g ( save space for these ) var mine var something-else and I've seen this too (which is better, btw) : tempvar 40 variable ; There are lots of problems inherent in programs that use each other's global variables, and there are a lot of alternate solutions that don't involve using global variables. -- ______________________________________________________________________ robert earl / "Obviously then a Woman is not to be rearl@piggy.ucsb.edu \ irritated as long as she is in a position / where she can turn round." From tinymuck-sloggers-owner Thu Aug 22 14:41:24 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA29990; Thu, 22 Aug 91 14:41:26 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA29986; Thu, 22 Aug 91 14:41:24 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA167384; Thu, 22 Aug 91 14:40:33 -0700 Date: Thu, 22 Aug 91 14:40:33 -0700 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9108222140.AA167384@nike.calpoly.edu> To: tinymuck-sloggers Subject: Loops and other ideas I'd have to disagree that using a linked list stack is less efficient: the rotate command is vastly sped up...and that's one of the more commonly used commands that deal with a large amount of elements. Yes, the allocation and deallocation is messy tho'... From tinymuck-sloggers-owner Thu Aug 22 14:56:17 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00206; Thu, 22 Aug 91 14:56:18 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00202; Thu, 22 Aug 91 14:56:17 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA28173 sendmail 5.64/UCSD-2.1-sun via SMTP Thu, 22 Aug 91 14:55:17 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA05888 for tinymuck-sloggers@piggy.ucsb.edu; Thu, 22 Aug 91 14:55:55 pdt Date: Thu, 22 Aug 91 14:55:55 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108222155.AA05888@sdnp1.UCSD.EDU> To: tinymuck-sloggers In-Reply-To: King_Claudius's message of Thu, 22 Aug 91 14:40:33 -0700 <9108222140.AA167384@nike.calpoly.edu> Subject: Stack handling (List vs. Array) Reply-To: dmoore@ucsd.edu Ok, this is how I see the various opertations in the linked list and the array environment. rotate n - Takes n+1 memory moves for array, Takes n next-node references and 2 memory moves for linked list. pick n - Takes 1 memory move for array, Takes n next-node references a new node creation and 1 memory move for linked list. Now consider that most rotates are for the 3-7 depth range, I can't really see where you get a great speedup when compared to the massive overhead of node creation on normal push opertations. From tinymuck-sloggers-owner Thu Aug 22 15:08:14 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00233; Thu, 22 Aug 91 15:08:16 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00229; Thu, 22 Aug 91 15:08:14 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA29280 sendmail 5.64/UCSD-2.1-sun via SMTP Thu, 22 Aug 91 15:07:08 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA05903 for tinymuck-sloggers@piggy.ucsb.edu; Thu, 22 Aug 91 15:07:43 pdt Date: Thu, 22 Aug 91 15:07:43 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108222207.AA05903@sdnp1.UCSD.EDU> To: tinymuck-sloggers In-Reply-To: David Moore's message of Thu, 22 Aug 91 14:55:55 pdt <9108222155.AA05888@sdnp1.UCSD.EDU> Subject: Stack handling (List vs. Array) Reply-To: dmoore@ucsd.edu Blah, ignore that last thing. I seriously need some sleep. Anyways, I think though you should look at the depth at which most rotates are done when deciding which method to use. From tinymuck-sloggers-owner Thu Aug 22 17:24:04 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00711; Thu, 22 Aug 91 17:24:06 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00707; Thu, 22 Aug 91 17:24:04 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA10558; Thu, 22 Aug 91 17:23:01 -0700 Date: Thu, 22 Aug 91 17:23:01 -0700 From: blojo.member.cc Message-Id: <9108230023.AA10558@soda.berkeley.edu> To: tinymuck-sloggers Subject: Stuff X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] Has anyone ever thought of implementing 'mark' and 'cleartomark', thus protecting us from idiots who write standard/library/global programs that leave junk on the stack? From chupchup Thu Aug 22 17:28:58 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00737; Thu, 22 Aug 91 17:28:59 -0700 Received: by piggy.ucsb.edu via UUCP (Sendmail 5.65b/1.05) id AA00733; Thu, 22 Aug 91 17:28:58 -0700 Date: Thu, 22 Aug 91 17:28:58 -0700 Message-Id: <9108230028.AA00733@piggy.ucsb.edu> From: chupchup (Robert Earl) To: tinymuck-sloggers Subject: Stuff References: <9108230023.AA10558@soda.berkeley.edu> Reply-To: rearl >>>>> On Thu, 22 Aug 91 17:23:01 -0700, blojo.member.cc said: Jon> Has anyone ever thought of implementing 'mark' and 'cleartomark', thus Jon> protecting us from idiots who write standard/library/global programs that Jon> leave junk on the stack? Hmm, mind explaining this more? I think you mean this: stack positions [0 1 2 3 4 5 6] stack top is at 6 2 MARK call #34 CLEARTOMARK ==> clears 6, 5, 4, 3, and 2. Am I right? -- ______________________________________________________________________ robert earl / "Obviously then a Woman is not to be rearl@piggy.ucsb.edu \ irritated as long as she is in a position / where she can turn round." From tinymuck-sloggers-owner Thu Aug 22 17:38:03 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00789; Thu, 22 Aug 91 17:38:04 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00785; Thu, 22 Aug 91 17:38:03 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA11203 sendmail 5.64/UCSD-2.1-sun via SMTP Thu, 22 Aug 91 17:36:53 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA06022 for tinymuck-sloggers@piggy.ucsb.edu; Thu, 22 Aug 91 17:37:30 pdt Date: Thu, 22 Aug 91 17:37:30 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108230037.AA06022@sdnp1.UCSD.EDU> To: tinymuck-sloggers In-Reply-To: Robert Earl's message of Thu, 22 Aug 91 17:28:58 -0700 <9108230028.AA00733@piggy.ucsb.edu> Subject: Stuff Reply-To: dmoore@ucsd.edu I'm not sure what he had in mind, but it I think that you should be able to do a mark such that when you do a call, it can't go down below that mark and mess up that part of the stack, and when you do the cleartomark it clears down to there. If that routine was supposed to return some value you'd have to put it in a variable until after you did the clearstack, else you'd lose it. Ex: [ 0 1 2 3 4 5 6 ] <- Start Stack (prog #34 puts 7 8 9 on the stack) 4 MARK call #34 save_nine ! cleartomark ==> 0 1 2, and save_nine == 9. The 4 to MARK tells it how far back in the stack to protect. So if you wanted to call a routine giving it no starting stack you use 0 MARK. This is quite useful for programs which have to call other programs w/o knowing what they do to the stack, ie lock checkers, etc. By not allowing anything after the mark to go below that point on the stack protects you from programs which might mess up data for your program. Sure the program that you called is screwed, but there are times you have to blindly call other programs. From tinymuck-sloggers-owner Thu Aug 22 17:52:28 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00843; Thu, 22 Aug 91 17:52:31 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00839; Thu, 22 Aug 91 17:52:28 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA125527; Thu, 22 Aug 91 17:51:40 -0700 Date: Thu, 22 Aug 91 17:51:40 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9108230051.AA125527@nike.calpoly.edu> To: tinymuck-sloggers Subject: Dtuff Maybe like..... : main "string" #-2 666 mark #45 call cleartomark ; [standard stuff skipped for brevity ] Debug> Stack( "string", #-2, 666 ) MARK Debug> Stack( "string", #-2, 666, !MARK! ) #45 Debug> Stack( "string", #-2, 666, !MARK!, #45 ) CALL Program does it's dirty work, and returns. It _should_ abort_interp("STACK UNDERFLOW"); if it attempts to touch the !MARK!... Debug> Stack( "string", #-2, 666, !MARK!, "junk", #12 ) CLEARTOMARK Debug> Stack( "string", #-2, 666 ) EXIT I got this right? maybe the !MARK! needs to be a new type, something that'll cause errors if you touch it... --Doran From tinymuck-sloggers-owner Thu Aug 22 17:57:53 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00881; Thu, 22 Aug 91 17:57:56 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00877; Thu, 22 Aug 91 17:57:53 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA12725 sendmail 5.64/UCSD-2.1-sun via SMTP Thu, 22 Aug 91 17:56:49 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA06061 for tinymuck-sloggers@piggy.ucsb.edu; Thu, 22 Aug 91 17:57:26 pdt Date: Thu, 22 Aug 91 17:57:26 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9108230057.AA06061@sdnp1.UCSD.EDU> To: awozniak@nike.calpoly.edu Cc: tinymuck-sloggers In-Reply-To: The WOZ's message of Thu, 22 Aug 91 17:51:40 -0700 <9108230051.AA125527@nike.calpoly.edu> Subject: Dtuff Reply-To: dmoore@ucsd.edu Well, I was thinking that, but you'd have to do a lot of extra processing for people who do a 20 pick in that case. Whereas if you just kept an offline marker of what the lowest stack point people could see, you'd just need to do a comparison operator. If you make !MARK! a type, how do you know when you are below it unless you look for it down the whole stack. Also, I liked the idea of being to set how far down for the mark to take effect, since otherwise you have to do strange tricks to get arguments to functions above the mark. For example, you want to call #52 which takes two arguments. If you used it where MARK marks the current spot you'd have to do something like this: : whee 1 2 3 4 save_1 ! save_2 ! mark save_2 @ save_1 @ #52 call ; versus : whee 1 2 3 4 2 mark #52 call ; OJ From tinymuck-sloggers-owner Thu Aug 22 18:06:56 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00905; Thu, 22 Aug 91 18:06:59 -0700 Received: from relay.hp.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00901; Thu, 22 Aug 91 18:06:56 -0700 Received: from hpsovtx.cup.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA16095; Thu, 22 Aug 91 18:05:55 -0700 Received: by hpsovtx.cup.hp.com with SMTP (15.11/15.5+IOS 3.20+cup+OMrelay) id AA29420; Thu, 22 Aug 91 18:05:07 pdt Message-Id: <9108230105.AA29420@hpsovtx.cup.hp.com> To: tinymuck-sloggers Subject: Please remove me from this mailing list Date: Thu, 22 Aug 91 18:05:05 -0700 From: Bruce LaVigne Like the subject line says, please remove me (bruce@cup.hp.com) from this mailing list. Thank you. -bruce From tinymuck-sloggers-owner Thu Aug 22 18:15:00 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA00934; Thu, 22 Aug 91 18:15:02 -0700 Received: from drums.reasoning.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA00930; Thu, 22 Aug 91 18:15:00 -0700 Received: from cymbal.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef) id AA01715; Thu, 22 Aug 91 18:13:35 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by cymbal.reasoning.com. (4.0/SMI-4.0) id AA01198; Thu, 22 Aug 91 18:13:33 PDT Date: Thu, 22 Aug 91 18:13:33 PDT From: nils@cymbal.reasoning.com (Nils McCarthy) Message-Id: <9108230113.AA01198@cymbal.reasoning.com.> To: tinymuck-sloggers Subject: Mark/clearmark stuff? how about a new primitive 'safecall'... arg1 arg2 2 1 safecall -> That way the program you call couldn't cleartomark and then mess up your stack... btw, has anyone thought about a source-level debugger? like instead of just 'c', you could use 'c -d' to compile with line number and program # information? so you would know where the error happened without having to wade through pages of debug output, tracing what your program is doing? From tinymuck-sloggers-owner Thu Aug 22 18:38:57 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA01008; Thu, 22 Aug 91 18:38:59 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA01004; Thu, 22 Aug 91 18:38:57 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA137804; Thu, 22 Aug 91 18:38:10 -0700 Date: Thu, 22 Aug 91 18:38:10 -0700 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9108230138.AA137804@nike.calpoly.edu> To: tinymuck-sloggers Subject: Re: Mark/clearmark stuff? This brings up another one of my ideas: making interp_loop a recursive function, and having it able to create new stacks when you use either 'call' or some new primitive such as 'safecall' or my idea was 'stackcall' since it creates a new stackframe. Anyone try this before? Should I try it? Or should I put my head through a wall first? From tinymuck-sloggers-owner Thu Aug 22 21:06:53 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA01444; Thu, 22 Aug 91 21:06:55 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA01261; Thu, 22 Aug 91 20:19:12 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA14468; Thu, 22 Aug 91 20:18:06 -0700 Date: Thu, 22 Aug 91 20:18:06 -0700 From: blojo.member.cc Message-Id: <9108230318.AA14468@soda.berkeley.edu> To: claudius@nike.calpoly.edu, tinymuck-sloggers Subject: Re: Mark/clearmark stuff? X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] > Or should I put my head through a wall first? Now there's an idea. Umm, I think that if you think about it a little bit you'll realize why you can't make interp_loop a recursive function that works like you want without some serious instruction-count restriction. When implementing things such as 'mark' and 'cleartomark', I would think that it's not so necessary to make sure things aren't popped below the mark-- I don't know how often it's happened to any of you, but it's never happened to me. And it slows down popping things off the stack by at least two times. The 'mark' should just be a marker that one knows one will be able to clear to. That way it doesn't slow anything down at all and gives you some nifty reassurance. Note that you can implement mark and cleartomark within muf, but it's hellaslower. From tinymuck-sloggers-owner Fri Aug 23 07:40:06 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA03427; Fri, 23 Aug 91 07:40:08 -0700 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA03423; Fri, 23 Aug 91 07:40:06 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA821602; Fri, 23 Aug 91 07:37:59 -0700 Date: Fri, 23 Aug 91 07:37:59 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9108231437.AA821602@nike.calpoly.edu> To: blojo@soda.berkeley.edu, claudius@nike.calpoly.edu, tinymuck-sloggers Subject: Re: Mark/clearmark stuff? How do I mark and clear in MUF? How can I be sure the program I just called didn't drop my mark off the stack? --Doran From tinymuck-sloggers-owner Fri Aug 23 11:06:42 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA03687; Fri, 23 Aug 91 11:06:43 -0700 Received: from orion.oac.uci.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA03683; Fri, 23 Aug 91 11:06:42 -0700 Received: from orion.oac.uci.edu by orion.oac.uci.edu id aa12537; 23 Aug 91 11:00 PDT To: tinymuck-sloggers Date: Fri, 23 Aug 91 11:00:28 -0700 From: Jack Dietz Message-Id: <9108231100.aa12537@orion.oac.uci.edu> Can't you just tell people to keep their stacks clean? :) Seriously, here is a possibility: Keep a new number in the stack called the 'stackbot'. This is the underflow value checked by 'CHECKOP(x)'. It is set with the 'mark' primitive, which saves the old value and updates it; it is cleared with the 'clear' primitive, which updates the 'atop' with the current 'stackbot' and pops the old one. Pseudocode for mark and clear: mark: Push current 'stackbot' to sys[]. Load 'stackbot' with 'atop'. clear: Load 'atop' with 'stackbot'. Pop current 'stackbot' from sys[]. stackbot: Used instead of 0 when testing for bottom of stack. These primitives should not be used for normal calls -- they hide the old values and prevent them from being so much as looked askance at. Only use them for calling unfamiliar programs. Also, any mark MUST be cleared or the program will abort next time it returns. (However, it would be possible to have 'ret' call 'clear' whenever it hit a mark...) I think that will fill the perceived need. -- Jack Dietz | this is not to be construed as a .sig | (jdietz@orion.oac.uci.edu) From tinymuck-sloggers-owner Fri Aug 23 13:35:24 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA03863; Fri, 23 Aug 91 13:35:29 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA03859; Fri, 23 Aug 91 13:35:24 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA23183; Fri, 23 Aug 91 13:34:05 -0700 Date: Fri, 23 Aug 91 13:34:05 -0700 From: blojo.member.cc Message-Id: <9108232034.AA23183@soda.berkeley.edu> To: awozniak@nike.calpoly.edu, blojo@soda.berkeley.edu, claudius@nike.calpoly.edu, tinymuck-sloggers Subject: Re: Mark/clearmark stuff? X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] > How do I mark and clear in MUF? How can I be sure the program I just called > didn't drop my mark off the stack? You can't. But I was pointing out that the mark and clear one would implement in the server if one were sane can also be emulated in muf, though it's a lot slower. From tinymuck-sloggers-owner Fri Aug 23 13:37:47 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA03880; Fri, 23 Aug 91 13:37:49 -0700 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA03876; Fri, 23 Aug 91 13:37:47 -0700 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA23213; Fri, 23 Aug 91 13:36:37 -0700 Date: Fri, 23 Aug 91 13:36:37 -0700 From: blojo.member.cc Message-Id: <9108232036.AA23213@soda.berkeley.edu> To: jdietz@orion.oac.uci.edu, tinymuck-sloggers Subject: Artificial Stack Bottom X-Face: ")H=q1&W6"l&(~9rc:D,b8bCdy$94>cC!hJ@(AL=xM&|9kU6(W:nF!PSNNS$yq^vX:#q[@,>sOa]AiK<9I{XpRmBZgP(\ `_r(NV`Lv$!CU~a[.*p:Sq8KNyv3P47NTx~i.3}xq`_tgY."Ws%Fax';LF^:im P[$^#JL#oHodp[!vkzohFn=Lj=x>sTx] > Seriously, here is a possibility: Keep a new number in the stack called > the 'stackbot'. This is the underflow value checked by 'CHECKOP(x)'. It is This is a good idea; note, however, that it will still slow down all popping operations. From tinymuck-sloggers-owner Mon Aug 26 21:09:32 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA01663; Mon, 26 Aug 91 21:09:33 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA01659; Mon, 26 Aug 91 21:09:32 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA178779; Mon, 26 Aug 91 21:06:24 -0700 Date: Mon, 26 Aug 91 21:06:24 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9108270406.AA178779@nike.calpoly.edu> To: tinymuck-sloggers Subject: silly question... Anyone ever think of setting programs INTERACTIVE when they do a READ or a CALL, and unsetting them when they get back? Then you could make sure programs being run can't be recycled (check for the flag). Along with this you'd probably need to see the INTERACTIVE flag in an examine, and let wizards set and unset it (with a few safegaurds, of course). Questions? Comments? Criticisms? --Doran From tinymuck-sloggers-owner Tue Aug 27 06:05:01 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA02206; Tue, 27 Aug 91 06:05:04 -0700 Received: from ns-mx.uiowa.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA02202; Tue, 27 Aug 91 06:05:01 -0700 Received: from umaxc.weeg.uiowa.edu by ns-mx.uiowa.edu (5.64.jnf/910724) on Tue, 27 Aug 91 08:03:30 -0500 id AA20469 with SMTP Received: by umaxc.weeg.uiowa.edu (5.61.jnf/910817) on Tue, 27 Aug 91 08:03:19 -0500 id AA09498 Date: Tue, 27 Aug 91 08:03:19 -0500 From: Lee Brintle Message-Id: <9108271303.AA09498@umaxc.weeg.uiowa.edu> To: tinymuck-sloggers Subject: Re: Silly question Whoops... after I thought more about it.... How do you know how many times the flag has been set? If someone runs the same program while another person is blocked in a read, then when one or the other quits the flag is removed while the other person is still inside the program. You'd have to maintain a counter or somethin'. -- Lee From tinymuck-sloggers-owner Tue Aug 27 18:17:23 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA03235; Tue, 27 Aug 91 18:17:25 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA03231; Tue, 27 Aug 91 18:17:23 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA193915; Tue, 27 Aug 91 18:14:14 -0700 Date: Tue, 27 Aug 91 18:14:14 -0700 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9108280114.AA193915@nike.calpoly.edu> To: tinymuck-sloggers Subject: @set OBJ = :blah Is a command like this valid? We've made sure it doesn't work on our server. [after I wiped my properties, which included mail...oof!] One other thing relating to properties: We've created a new property type [thanks to Doran] called MUF properties [or as Doran calls/called them, INVISIBLE]. These properties are inaccessable from the @set command and don't show up in examine...this works for both properties on players and on objects. Use: basically to remove the clutter of stuff like our mail messages. We've chosen to use the "*" as the token to signify a MUF property. Comments? We hope to release our modifications to the server [although they may overwhelm many, we've been mighty busy lately] within a week. From tinymuck-sloggers-owner Wed Aug 28 10:43:46 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA03831; Wed, 28 Aug 91 10:43:51 -0700 Received: from [128.52.46.34] by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA03827; Wed, 28 Aug 91 10:43:46 -0700 Received: by geech.gnu.ai.mit.edu (5.65/4.0) id ; Wed, 28 Aug 91 13:38:55 -0400 From: gregb@gnu.ai.mit.edu (Gregory Joseph Blake) Message-Id: <9108281738.AA26389@geech.gnu.ai.mit.edu> Subject: disk based MUCK? To: tinymuck-sloggers Date: Wed, 28 Aug 91 13:38:54 WET DST X-Mailer: ELM [version 2.3 PL0] Is there one? We're currently trying to see if we can find one for spinoza? anyone got any leads/ideas???? thanks snooze gregb@gnu.ai.mit.edu From tinymuck-sloggers-owner Wed Aug 28 13:21:13 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA04258; Wed, 28 Aug 91 13:21:16 -0700 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA04251; Wed, 28 Aug 91 13:21:13 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA168080; Wed, 28 Aug 91 13:18:04 -0700 Date: Wed, 28 Aug 91 13:18:04 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9108282018.AA168080@nike.calpoly.edu> To: gregb@gnu.ai.mit.edu, tinymuck-sloggers Subject: Re: disk based MUCK? I head FluxMUCK is working on it... I'm not sure though... --Doran From tinymuck-sloggers-owner Wed Aug 28 18:14:49 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA04615; Wed, 28 Aug 91 18:14:52 -0700 Received: from miavx1.acs.muohio.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA04611; Wed, 28 Aug 91 18:14:49 -0700 Received: from MIAVX1.ACS.MUOHIO.EDU by MIAVX1.ACS.MUOHIO.EDU (PMDF #12251) id <01G9XD78R4I88WW1SX@MIAVX1.ACS.MUOHIO.EDU>; Wed, 28 Aug 1991 21:15 EDT Date: Wed, 28 Aug 1991 21:15 EDT From: James Walden Subject: Disk based MUCK To: tinymuck-sloggers Message-Id: <01G9XD78R4I88WW1SX@MIAVX1.ACS.MUOHIO.EDU> X-Vms-To: IN%"tinymuck-sloggers@piggy.ucsb.edu" We are working on making TinyMUCK disk based here at FluxMUCK and have made substantial progress on the code, though recently not much has been done as the other programmer is out of state and I'm started school this week. Can't offer a definite date as to when it will be done, but we're willing to offer help to anyone else who's working on a disk-based MUCK and we're also quite interested in hearing anyone else's experience with creating a disk-based MUCK. It takes a lot of care to ensure that the db is saved correctly and to avoid filling the cache (as when we discovered that recycle searches the entire db...our solution was to queue recycles until the save and deal with them then). Oh, and many thanks to Chup Chup for all the disk-based preparation code, though a macro for NEXT would have been nice too (we'll probably do that later since things will run much more efficiently with it). Syrinx From tinymuck-sloggers-owner Sun Sep 1 21:26:02 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07533; Sun, 1 Sep 91 21:26:05 -0700 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07529; Sun, 1 Sep 91 21:26:02 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA154772; Sun, 1 Sep 91 21:22:58 -0700 Date: Sun, 1 Sep 91 21:22:58 -0700 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9109020422.AA154772@nike.calpoly.edu> To: tinymuck-sloggers Subject: TinyMUCK 2.2db release announcement Q:What the H*LL are you talking about? A:TinyMUCK2.2db. Q:What is it? A:The first and only MUCK with working DAEMONS. This is a beta release to the general public, and we're pretty sure our code works, but no guarantees. Q:Um, can you be more specific? A:Sure...Some of the features [taken from CHANGES]: **Start of CHANGES** Changes in TinyMUCK 2.2db - RWHO server access [uses sigalarms to time] - New object type:daemon - daemons are objects that have attached stackframes and which run programs at specified times. * - @ps shows currently running daemons [all of them for wizards, otherwise only the ones you own] * - @kill terminates a daemon * - modified most [hopefully all] primitives so that daemons have the same permissions of their owner * - if a wizard sets an exit 'w' [wizard] and 'a' [autostart], the program will be executed when the server is started. The "_autostart" property on that exit is checked so that arguements may be given to the program upon starting. - @who command - shows descriptors as well as location and site. - took out 'dispatch' and replaced it with an array of functions. - added a new property 'type'...MUFprops-all properties beginning with '*' are considered MUFprops, and are hidden and can't be @set by normal players, although they can still CLEAR them with @set me = : . - added the 'SILENT' flag...[setting a player 'sticky'] This makes it so that normal operations don't show dbrefs or flags of objects. - added the 'AUTHOR' flag...[setting a player 'abode'] This makes it so that whenever a player sees a dbref and flags, he/she also sees the owner of the object. - players automatically run a MUF specified by the property '_do_connect' (on #0) when they log in. (i.e. @set #0 = _do_connect:113 to run program the program #113 when people log in.) - players automatically run a MUF specified by the property '_do_disconnect' (on #0) when they log out. - a multi-level help system. - changed @set to no longer clear properties when given @set obj = :string. - now allows objects to be linked to players - copyobj no longer has the one-object/run limit...it now bills the player for the cost of the new object. - timestamps have been added to objects. - turning line numbers on shows line numbers while inserting. - passwords are now encrypted, using the standard UNIX encryption routine - moving to a new room automatically runs the 'look' action if possible, and checks automagically for looping. - New primitives: CHOWN, RECYCLE, CREATE, OPEN, DIG, UNLINK, ADDLINK, LINKCOUNT, GETLINKS, SLEEP, INT?, STRING?, DBREF?, VAR?, TIME, DATE, SYSTIME, CTIME, TIME_CREATED, TIME_MODIFIED, TIME_USED, TOUCH, ONLINE, DB_TOP, DBTOP, DAEMON?, AWAKE?, DEPTH, GETFLAGS, |, &, ~, <<, >>, PROG, TRIG, CALLERS, CONCOUNT, CONNECTIONS, CONDBREF, CONIDLE, CONTIME, CONHOST, CONBOOT, CONNOTIFY Credits: Thanks to ChupChup[s] for all the work he's/they've done. Thanks to Foxen and the crew at XRoads for some of their fantastic ideas and some of their code. [well, a little of their code...:)] Thanks also to Sthiss/*fox for some of the ideas and help. Thanks to mjr for the RWHO server code and ideas. Thanks to all the players on PythonMUCK for coming up with ideas galore. Doran->coding and many ideas on the daemons, coding of the @who and rwho server interface, the timestamps, the help system, do_connect, do_disconnect, passwd encryption, "silent", and "author". Claudius->coding of most of the new primitives, designing the split of the dispatch loop, mods to @set and @link, LOOKING and related things, line numbers during insert mode, this list, much of the documentation, and lots of nagging of Doran. Lyssa->support and nagging of Claudius. [All of our code is OURS although much of it is written after seeing what others have done...we've tried to make it efficient and as clean looking as possible.] If you would like to get more information, make comments, join PythonMUCK, tell us off, or just plain old talk to us, we're: claudius@zeus.calpoly.edu awozniak@zeus.calpoly.edu [Lyssa prefers to remain anonymous] Coming soon: easy installation guide, patchfiles, floating point math types, math library primitives, commenting, and other fun stuff. **End of CHANGES** Q:Why would I want it? A:Because, it's neat! Q:I have found a bug, who do I send a report to? A:That depends...you could mail it to us and we'll see if it's something specific to what we've done [and not done] or if it should be sent to CC and the rest of the crew. Q:Can I get a uuencoded tar file mailed to me? A:No. Q:Who is responsible for this mess? A:Uh...George Bush. [may as well blame him for everything, eh?] Q:Can I get patch files? A:Sure, what for? [in other words, we don't quite know how to split this beast up, and patches aren't going to work on non-vanilla code, you'll have to do that stuff by hand...] Q:Can I try out the changes before installing? A:Sure, log in to PythonMUCK [either the guest account, or get your own.] (That's PythonMUCK->zeus.calpoly.edu 4201... [and for those with nameserver dyslexia...129.65.16.21 4201]) Q:Where to get it? A:We've dumped copies on beowolf.acc.stolaf.edu, piggy.ucsb.edu, and watnxt3.ucr.edu [as soon as we can get to it, that is]. Q:You've stolen my ideas! A:Prove they're your ideas and we'll give you credit. [not bank credit] [Sorry, we don't believe in shareware.] From chupchup Wed Sep 4 01:18:28 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA09538; Wed, 4 Sep 91 01:18:32 -0700 Received: by piggy.ucsb.edu via UUCP (Sendmail 5.65b/1.05) id AA09534; Wed, 4 Sep 91 01:18:28 -0700 Date: Wed, 4 Sep 91 01:18:28 -0700 Message-Id: <9109040818.AA09534@piggy.ucsb.edu> From: chupchup (Robert Earl) To: claudius@nike.calpoly.edu (King_Claudius) Cc: tinymuck-sloggers Subject: TinyMUCK 2.2db release announcement References: <9109020422.AA154772@nike.calpoly.edu> Reply-To: rearl Um, okay, the release seems okay to me, except a minor detail: the extension "db" makes it *LOOK* like a starter/sample database of some kind. Know what I'm saying? Up for ftp, people will grab it thinking they have a db and not a set of mods... So what does the "db" stand for, and maybe it could be changed? -- ______________________________________________________________________ robert earl / "Obviously then a Woman is not to be rearl@piggy.ucsb.edu \ irritated as long as she is in a position / where she can turn round." From tinymuck-sloggers-owner Mon Nov 18 22:13:52 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA04837; Mon, 18 Nov 91 22:13:55 -0800 Received: from geech.gnu.ai.mit.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA04833; Mon, 18 Nov 91 22:13:52 -0800 Received: by geech.gnu.ai.mit.edu (5.65/4.0) id ; Tue, 19 Nov 91 01:11:51 -0500 Date: Tue, 19 Nov 91 01:11:51 -0500 From: feoh@gnu.ai.mit.edu (feoh) Message-Id: <9111190611.AA14315@geech.gnu.ai.mit.edu> To: tinymuck-sloggers Subject: Robots in MUF Hi there folks. I haven't received anything since I joined this list. so If me posting this here is Taboo please feel free to flame away :) I was wondering if anyone has any work in prograess/past done on Robots in MUF. It's such a trivial process in MUSH code (no flames please just making comparoison) to have a object that listens to what's aisaisd and per forms some kind of action ans a result.. in MUF thats's quite another story.. Any help would be appreciated, thanks. From tinymuck-sloggers-owner Tue Nov 19 01:53:19 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA05593; Tue, 19 Nov 91 01:53:21 -0800 Received: from soda.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA05589; Tue, 19 Nov 91 01:53:19 -0800 Received: by soda.berkeley.edu (5.61/CHAOS3) id AA16906; Tue, 19 Nov 91 01:51:11 -0800 Message-Id: <9111190951.AA16906@soda.berkeley.edu> To: feoh@gnu.ai.mit.edu (feoh) Cc: tinymuck-sloggers Subject: Re: Robots in MUF X-Face: (4D-osoq?}7M3\EgvbWKo Date: Tue, 19 Nov 91 01:51:06 -0800 From: dougo@soda.berkeley.edu > I was wondering if anyone has any work in progress/past done on Robots > in MUF. It's such a trivial process in MUSH code (no flames please just > making comparison) to have a object that listens to what's said and per > forms some kind of action as a result.. in MUF that's quite another > story.. I have a file called "muckcron.c" that was written by Andrew/bob (amolitor@eagle.wesleyan.edu) a long time ago, like a year or so. I remember hacking on it a bit, also, but I haven't touched it in a long while. Anyway, it is a Muck robot client that will accept commands to queue actions; for instance, you can tell it to output '"Cuckoo!' every hour. It's pretty simple, but a useful base for MUF code stuck on top of it. As for a robot written entirely in MUF, it may be possible if you rewrite every primitive (especially say and pose), but even then it would be time-independent, that is it would only be triggered by user actions. I will send this file to you if you'd like, or maybe I can arrange to put it up for anonymous ftp if there is a large enough interest. I again warn you, however, that it has been hacked upon and may not even do exactly what it says anymore; I don't really plan on supporting it or anything. -- DougO (WhiteRabbit@[^{Visions}]) P.S. Stinglai has something vaguely along these lines in the works, to be released Any Day Now (that is, sooner than RSN). But don't tell him I told you. From tinymuck-sloggers-owner Tue Nov 19 13:18:51 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07722; Tue, 19 Nov 91 13:18:52 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07718; Tue, 19 Nov 91 13:18:51 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA188241; Tue, 19 Nov 91 13:10:34 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9111192110.AA188241@nike.calpoly.edu> Subject: Re: Robots in MUF To: dougo@soda.berkeley.edu Date: Tue, 19 Nov 91 13:10:33 PST Cc: tinymuck-sloggers In-Reply-To: <9111190951.AA16906@soda.berkeley.edu>; from "dougo@soda.berkeley.edu" at Nov 19, 91 1:51 am X-Mailer: ELM [version 2.3 PL11] Actually, in MUF on the daemonmuck code it's not very difficult...you can do a similiar thing to AHEAR with our server code, setting an exit HAVEN makes any notifies or notify_excepts going to that exit to spawn a daemon. This daemon could then record the message on a list on the robot object and the robot code would just check this list to see if there has been any input. [basically a poormans input queue] Utilizing the other features of the 2.2d server code makes it possible to do just about any robot code in MUF, although some of it requires wizard bit. -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Tue Nov 19 14:17:35 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA08135; Tue, 19 Nov 91 14:17:42 -0800 Received: from mole.gnu.ai.mit.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA08131; Tue, 19 Nov 91 14:17:35 -0800 Received: by mole.gnu.ai.mit.edu (5.65/4.0) id ; Tue, 19 Nov 91 17:14:31 -0500 Date: Tue, 19 Nov 91 17:14:31 -0500 From: feoh@gnu.ai.mit.edu (feoh) Message-Id: <9111192214.AA06304@mole.gnu.ai.mit.edu> To: claudius@nike.calpoly.edu, dougo@soda.berkeley.edu Subject: Re: Robots in MUF Cc: tinymuck-sloggers Hrrm thanks for rthtthe info.. 2.2d.. is that a subset of 2.2fd? From tinymuck-sloggers-owner Tue Nov 19 15:33:08 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA08570; Tue, 19 Nov 91 15:33:10 -0800 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA08566; Tue, 19 Nov 91 15:33:08 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA832291; Tue, 19 Nov 91 14:52:32 -0800 Date: Tue, 19 Nov 91 14:52:32 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9111192252.AA832291@nike.calpoly.edu> To: claudius@nike.calpoly.edu, dougo@soda.berkeley.edu, feoh@gnu.ai.mit.edu Subject: Re: Robots in MUF Cc: tinymuck-sloggers 2.2fd??? That's not us :) perhaps you mean 2.2fb(fuzzball!) that Crossroads is running on.... PythonMUCK runs 2.2.6d-beta, all versions of this code use the format 2.2.nd-beta (except our first release, which was 2.2db). --Doran From tinymuck-sloggers-owner Tue Nov 19 15:52:16 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA08672; Tue, 19 Nov 91 15:52:17 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA08668; Tue, 19 Nov 91 15:52:16 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA113643; Tue, 19 Nov 91 14:32:50 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9111192232.AA113643@nike.calpoly.edu> Subject: Re: Robots in MUF To: feoh@gnu.ai.mit.edu (feoh) Date: Tue, 19 Nov 91 14:32:49 PST Cc: claudius@nike.calpoly.edu, dougo@soda.berkeley.edu, tinymuck-sloggers In-Reply-To: <9111192214.AA06304@mole.gnu.ai.mit.edu>; from "feoh" at Nov 19, 91 5:14 pm X-Mailer: ELM [version 2.3 PL11] >Hrrm thanks for the info.. 2.2d.. is that a subset of 2.2fd? Nope, actually it's a seperate branch of the MUCK development tree. Doran and I felt we were upset with how some of the code was implemented and the limitations of one program/person, and that got Doran to code up daemons and we added somewhere near 80 new primitives. Many of them were modelled after the 2.2fb code, some with different names [personal choice...] Some of the advantages of daemons though are that they are usable by everyone, there is just a limitation on the number each user can have running at one time. -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Tue Nov 19 18:12:13 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA10086; Tue, 19 Nov 91 18:12:15 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA10082; Tue, 19 Nov 91 18:12:13 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA183886; Tue, 19 Nov 91 18:03:49 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9111200203.AA183886@nike.calpoly.edu> Subject: Re: Daemons in Muck To: dougo@soda.berkeley.edu (Doug Orleans) Date: Tue, 19 Nov 91 18:03:48 PST Cc: claudius@nike.calpoly.edu, piaw@soda.berkeley.edu, tinymuck-sloggers In-Reply-To: <9111200138.AA02075@soda.berkeley.edu>; from "Doug Orleans" at Nov 19, 91 5:38 pm X-Mailer: ELM [version 2.3 PL11] >Have you really filled in the daemon-code hook that was in TinyMuck 2.0? >If so, do you have a good usermanual or something you can send me? I'd >be interested in the details of this. Actually, I'm not sure what the original sockets were, but I'll describe how we did daemons... Originally Doran created the daemon code with the intention of creating 'temporary players' so that we could just use that structure...this worked fine in older versions but we had some troubles, so we eventually added a new object, DAEMON. This object type has no location or any other specifics except for DAEMON related stuff. The daemons are linked together aka the contents lists, and the head is kept in a static global variable. A clock signal is used to initiate a daemon refresh, the SAME signal that initiates dumps. All that we did was have it keep track of the time and when the right time came it dumped, otherwise it'd just do the daemon sweep. Daemons on the database are prettymuch nothing, just placeholders and are recycled when the database is reloaded. As for how daemons are used, @ps shows all the daemons you own [or all if you're a wizard] and @kill DBREF kills a daemon. @go DBREF forces a daemon to go in the next sweep, no matter how much time it had remaining. When a program calls SLEEP ( i -- ) it spawns a daemon [or just puts the current daemon into a sleep state again...] automatically. When the daemon finishes [no more sleeps] it is automatically recycled. There are various other support primitives and stuff, I'd recommend checking out PythonMUCK, our testbed. [zeus.calpoly.edu 4201 (129.65.16.21 4201)] Be sure to check out the library to the north of the bazaar. The code is considered beta mostly because we haven't really stopped working on it and the documentation so far is fairly sparse. As for where to get it, it is available on piggy.ucsb.edu...in pub/mud/incoming usually. We have a mailing list specifically for talking about code changes and new releases, you are welcome to join. Send mail to daemonmuck-request@zeus.calpoly.edu for more info. -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Tue Nov 19 19:03:49 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA10303; Tue, 19 Nov 91 19:03:51 -0800 Received: from ns-mx.uiowa.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA10299; Tue, 19 Nov 91 19:03:49 -0800 Received: from icaen7.icaen.uiowa.edu by ns-mx.uiowa.edu (5.64.jnf/911107) on Tue, 19 Nov 91 21:01:44 -0600 id AA18332 with SMTP Received: by icaen.uiowa.edu ( 5.52 (84)/1.1) id AA02488 on Tue, 19 Nov 91 20:10:08 CST. Date: Tue, 19 Nov 91 20:10:08 CST From: ISCA Games Manager Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <9111200210.AA02488@icaen.uiowa.edu> To: claudius@nike.calpoly.edu, feoh@gnu.ai.mit.edu Subject: Re: Robots in MUF Cc: dougo@soda.berkeley.edu, tinymuck-sloggers Hrm...Somebody forwarded this note to me because I've been working on this. I've coded a complete robot in MUF running on the 2.3a testMUCK. Right now, I'm ironing the bugs out of the verbal interface, but MUF-bot (original, huh?) is capible of mapping rooms, pathfinding, etc. and basically acting as a Julia-type independent robot. With some minor mods to the MUF paging code (which I hope to implement Soonest), MUF-bot will also be able to intercept and respond to pages. Peace, Doug (aka "Bard" and "GreyLensman") From tinymuck-sloggers-owner Wed Nov 20 14:48:29 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA14737; Wed, 20 Nov 91 14:48:32 -0800 Received: from server.cs.jhu.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA14732; Wed, 20 Nov 91 14:48:29 -0800 Message-Id: <9111202248.AA14732@piggy.ucsb.edu> Received: by server.cs.jhu.edu; Tue, 19 Nov 91 23:20:16 -0500 Date: Tue, 19 Nov 91 23:20:12 -0500 From: arromdee@server.cs.jhu.edu Sender: arromdee@server.cs.jhu.edu To: tinymuck-sloggers Subject: 2.3 OK, GreyLensman, where _is_ 2.3? :-) From tinymuck-sloggers-owner Thu Nov 21 11:53:44 1991 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20076; Thu, 21 Nov 91 11:53:46 -0800 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20072; Thu, 21 Nov 91 11:53:44 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA814830; Thu, 21 Nov 91 11:45:00 -0800 Date: Thu, 21 Nov 91 11:45:00 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9111211945.AA814830@nike.calpoly.edu> To: arromdee@server.cs.jhu.edu, tinymuck-sloggers Subject: Re: 2.3 Chupchups wanna tell us what to expect from 2.3 ??? :drools slightly in expectation. Doran drools slightly in expectation. From tinymuck-sloggers-owner Fri Jan 17 10:14:30 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA15298; Fri, 17 Jan 92 10:14:33 -0800 Received: from athena.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA15294; Fri, 17 Jan 92 10:14:30 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA440324; Fri, 17 Jan 92 10:14:27 -0800 Date: Fri, 17 Jan 92 10:14:27 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9201171814.AA440324@nike.calpoly.edu> To: tinymuck-sloggers Subject: Command line arguments and actions locked to programs. Ok folks. Byte pointed this one out to me. I don't know if anyone else ever noticed or cared enough to bring it up, but... test(#21216E) Owner: Doran Type: EXIT/ACTION Key: blah(#22869FD) Stack( "doran" ) DUP Debug> Stack( "doran", "doran" ) MATCH Debug> Stack( "doran", #2226 ) addr Debug> Stack( "doran", #2226, addr ) IF Debug> Stack( "doran" ) 1 Debug> Stack( "doran", 1 ) addr Debug> Stack( "doran", 1, addr ) JMP Debug> Stack( "doran", 1 ) EXIT Stack( "" ) V0 Stack( "", V0 ) @ Debug> Stack( "", #2226 ) SWAP Debug> Stack( #2226, "" ) NOTIFY Debug> Stack( ) EXIT Ok, the lock executes normally, with the correct string on the stack. However, when the program blah2 gets executed, it no longer has that command string on the stack. I know this is 'normal' and 'correct' behavior, but it seems a little lopsided to me. Why give the command line to the lock? Why not give it to the destination? Or both? Lemme know how you feel about it. --Doran You don't understand, Doran. Bugs do not happen because you do something. Bugs just are. -Explorer_Bob to me, awozniak@morpheus.calpoly.edu From tinymuck-sloggers-owner Fri Jan 17 11:53:12 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA15529; Fri, 17 Jan 92 11:53:15 -0800 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA15525; Fri, 17 Jan 92 11:53:12 -0800 Received: from sdnp2.ucsd.edu by ucsd.edu; id AA20701 sendmail 5.64/UCSD-2.2-sun via SMTP Fri, 17 Jan 92 11:53:04 -0800 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp2.UCSD.EDU (5.57/UCSDGENERIC.2) id AA02343 for tinymuck-sloggers@piggy.ucsb.edu; Fri, 17 Jan 92 11:52:56 PST Date: Fri, 17 Jan 92 11:52:56 PST From: dmoore@sdnp2.UCSD.EDU (David Moore) Message-Id: <9201171952.AA02343@sdnp2.UCSD.EDU> To: awozniak@nike.calpoly.edu, tinymuck-sloggers Subject: Re: Command line arguments and actions locked to programs. It does give the command line to both....BUT, match is not reentrant, using global state information. So when you call match in the lock, it loses the original command line, since it was possible that match was going to be matching up with exits. It's a bug which requires someone to fix the matching code. Or you could just save off the command line args someplace if a program has progs in both the lock and the main body. OliverJones From tinymuck-sloggers-owner Fri Jan 17 12:00:14 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA15574; Fri, 17 Jan 92 12:00:16 -0800 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA15570; Fri, 17 Jan 92 12:00:14 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA877037; Fri, 17 Jan 92 11:59:19 -0800 Date: Fri, 17 Jan 92 11:59:19 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9201171959.AA877037@nike.calpoly.edu> To: awozniak@nike.calpoly.edu, dmoore@sdnp2.UCSD.EDU, tinymuck-sloggers Subject: Re: Command line arguments and actions locked to programs. Does that qualify as a bug or a feature? :) Thanks, I thought I was missing something... --Doran You don't understand, Doran. Bugs do not happen because you do something. Bugs just are. -Explorer_Bob to me, awozniak@morpheus.calpoly.edu From tinymuck-sloggers-owner Fri Feb 7 11:38:49 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07477; Fri, 7 Feb 92 11:38:51 -0800 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07473; Fri, 7 Feb 92 11:38:49 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA178497; Fri, 7 Feb 92 11:38:59 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9202071938.AA178497@nike.calpoly.edu> Subject: MUCK-S Conference Update To: tinymuck-sloggers (user alias), daemonmuck@nike.calpoly.edu Date: Fri, 7 Feb 92 11:38:59 PST X-Mailer: ELM [version 2.3 PL11] Update: The MUD Standardization Con is slated for 2/22/92, a Saturday at 18:00 PST on PythonMUCK (zeus.calpoly.edu 4201). Players who do not preregister will be able to attend but will not be able to speak or pose openly in Conference room. Everyone is welcome to attend. Please mail claudius@zeus.calpoly.edu to register. Also feel free to submit any requests for agenda additions/changes. Those currently signed up: Claudius Foxen Explorer_Bob Schlake Paramour Agenda: * STRINGCMP vs STRCASECMP (and possibly adding STRNCASECMP) * the reentrant interpreter * looping constructs and forms of limitation * property datastructures - can/should flags and pennies be removed? - efficiency vs. space vs. complexity * variables and arrays - should MUF be extended to have local variables to functions? - MUF array allocation * commands to load programs from within MUF - if these are to be, what should the commands be * the hotly debated and often misunderstood FORCE primitive * making intostr, atoi, etc. able to take any form of argument? - if this is to be done, change the names to TOSTR, TOINT, TODBREF? * need more string primitives? * database primitives and standardization - DIG/OPEN/CREATE/PCREATE/... vs. NEWROOM/NEWEXIT/NEWOBJECT/NEWPLAYER/... - access to primitives * the question of locks - can boolean locks be removed and replaced with simple locks on programs? * possible modifications to make MUCK allow networked databases - a standardized approach - security concerns * memory concerns - should users be limited in the amount of memory one program's stackspace can take? [including the memory usage of strings] * player object quotas? * more flags? * futures for modifications of systems - the future of 2.2.xd and 2.2fb and other versions -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Fri Feb 7 11:41:53 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07501; Fri, 7 Feb 92 11:41:54 -0800 Received: from morpheus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07497; Fri, 7 Feb 92 11:41:53 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA886932; Fri, 7 Feb 92 11:41:35 -0800 Date: Fri, 7 Feb 92 11:41:35 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9202071941.AA886932@nike.calpoly.edu> To: claudius@nike.calpoly.edu, daemonmuck@nike.calpoly.edu, tinymuck-sloggers Subject: Re: MUCK-S Conference Update Please put me on the list of those attending :) --Doran From tinymuck-sloggers-owner Mon Feb 10 04:32:21 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA17737; Mon, 10 Feb 92 04:32:24 -0800 Received: from sting.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA17729; Mon, 10 Feb 92 04:32:21 -0800 Received: by sting.berkeley.edu (5.57/Ultrix3.0-C) id AA24029; Mon, 10 Feb 92 04:32:17 -0800 Date: Mon, 10 Feb 92 04:32:17 -0800 From: dougo@xcf.berkeley.edu (Doug Orleans) Message-Id: <9202101232.AA24029@sting.berkeley.edu> To: daemonmuck@zeus.calpoly.edu, moo-cows@xerox.com, tinymuck-sloggers Subject: Anouncing: MPIF mailing list. Attention: the MPIF mailing list is now in service! MPIF, or Multi-Player Interactive Fiction, for those of you who like to have everything spelled out for you, is a new and exciting subgenre (so to speak) of Interactive Fiction, involving multiple players (like you couldn't tell from the name). The prupose of the list is to serve as a forum for discussing implementation-dependent topics relevant to the various forms of MPIF. Rather than go into all the details in this naughtily wide-spread crosspost, I'll let you finger dougo.MPIF@soda.berkeley.edu for a more detailed explanation. Or you can just send subscription requests directly to MPIF-request@xcf.berkeley.edu a day or so after which you'll get a handy dandy welcome message and you'll be added to the list. (No, it isn't automated yet...) So go ahead, join up! What do you have to lose? -- DougO owner-MPIF@xcf.berkeley.edu (Those under 18 must have their parents' permission before subscribing. Void where prohibited. This commercial was not paid for by the U.S. Army.) From tinymuck-sloggers-owner Mon Feb 10 18:17:31 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20634; Mon, 10 Feb 92 18:17:35 -0800 Received: from sting.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20630; Mon, 10 Feb 92 18:17:31 -0800 Received: by sting.berkeley.edu (5.57/Ultrix3.0-C) id AA25287; Mon, 10 Feb 92 18:17:32 -0800 Date: Mon, 10 Feb 92 18:17:32 -0800 From: dougo@xcf.berkeley.edu (Doug Orleans) Message-Id: <9202110217.AA25287@sting.berkeley.edu> To: moo-cows@xerox.com, tinymuck-sloggers Subject: Change my address Change my address from dougo@soda.berkeley.edu to dougo@xcf.berkeley.edu please. Thanks. From tinymuck-sloggers-owner Mon Feb 17 02:42:29 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA04225; Mon, 17 Feb 92 02:42:31 -0800 Received: from netcom.netcom.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA04221; Mon, 17 Feb 92 02:42:29 -0800 Received: by netcom.netcom.com (4.1/SMI-4.1) id AA19203; Mon, 17 Feb 92 02:42:59 PST From: foxen@netcom.com (Foxen) Message-Id: <9202171042.AA19203@netcom.netcom.com> Subject: TinyMUCK2.2fb: Project abandoned. To: tinymuck-sloggers (TinyMUCK Tech. Mail List), daemonmuck@zeus.calpoly.edu (daemonmuck list) Date: Mon, 17 Feb 92 2:42:58 PST X-Mailer: ELM [version 2.3 PL11] This is to announce, that as of this time, I no longer support the TinyMUCK 2.2fb server. I came to this decision because of several reasons, including my lack of time, and the fact that I'm just too damn tired to continue working on it. The biggest reason however is simply that every bit of work I've done on my server has either had an equivalent worked into the daemonmuck code, or it's better, or it will be soon. Since I never more than tenatively released my code, most people have moved on to using the available (and in truth, well done) daemonmuck code. Claudius and Doran (and others) have done a fine job on their server. I look out at the various MU*s available, and now see MOO, and UnterMUD 2.0, along with several other well done, and much more elegant servers than what I'm doing. Basically, I guess, I've just gotten tired of competing. I've watched hundreds of hours of my work, and the work of others, become obsolete in the fb code. With the levels of stress I already put on myself every day, I don't need this, so I'm letting go. I quit. I'm not going to continue working on the MUCK 2.2fb server. If you wish to get ahold of the server as it stands at MUCK2.2fb3.3, then you can ftp it from ftp.apple.com in the pub/fb directory. Thank you, - Foxen/Revar/Fiera. -- ___ __ ___ _ . _^^ ____ foxen@netcom.com \ / | | \ | | | -> '-" \______/___/ Another Fine Furry Fan `v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the | |___ | \ | o //|| ||| Holy Furr of Bastis!" From tinymuck-sloggers-owner Tue Feb 18 11:00:07 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA10976; Tue, 18 Feb 92 11:00:10 -0800 Received: from pa.itd.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA10972; Tue, 18 Feb 92 11:00:07 -0800 Received: by pa.itd.com (4.1/SMI-4.1) id AA23496; Tue, 18 Feb 92 12:59:10 CST Message-Id: <9202181859.AA23496@pa.itd.com> From: agri@pa.itd.com (Howard/Dark_Lord/IOAG) Date: Tue, 18 Feb 92 12:59:09 CST X-Mailer: Mail User's Shell (7.0.0 12/10/89) To: tinymuck-sloggers Subject: ? If this mailing list still exists, please add me to the list. -- ------------------------------------------------------------------------------- * Howard * * Howard or Dark_Lord on most MUDS and BBSs * * Admin of AfterFive at pa.itd.com 9999 128.160.2.249 9999 * ------------------------------------------------------------------------------- Programmers Creed: Written by Howard and Doran. All rights reserved. ^^^^^^^^^^^^^^^^^^^ 1) Ignore all warnings at compile time. 2) The programmer is always right, NOT the user. 3) If it compiles successfully, it works. 4) Never document your work. 5) Thats not a bug, its a feature. 6) If at first you don't succeed, tell the user "It can't be done." 7) If it doesn't work, comment it out. 8) It's always better to add a new feature than fix an old bug. 9) Always assume malloc returns a non-NULL pointer. 10) All good code is self documenting. 11) If the user asks a question, refer him to the documentation. 12) The simple problems are always the toughest. 13) Variables are always constant unless you change them. From tinymuck-sloggers-owner Wed Feb 19 09:07:14 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20159; Wed, 19 Feb 92 09:07:15 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20155; Wed, 19 Feb 92 09:07:14 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA195832; Wed, 19 Feb 92 09:07:23 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9202191707.AA195832@nike.calpoly.edu> Subject: MUCK-S Con:UPDATE To: tinymuck-sloggers (user alias), daemonmuck@nike.calpoly.edu Date: Wed, 19 Feb 92 9:07:23 PST X-Mailer: ELM [version 2.3 PL11] The MUCK-Standardization Convention is still on for 2/22 at 18:00PST [translate as you see fit...] on PythonMUCK [zeus.calpoly.edu 4201]. Everyone is welcome to attend and participate, but you MUST preregister through me before you will be able to speak at the Convention. Here is the list of those registered. If I have somehow missed you please drop me another line, I've been rather scatter-brained lately. I hope to put an edited log onto an FTP site eventually. If you have registered or are going to register, connect to PythonMUCK and create your character [you can get a free M and B bit too!] so that we'll be ready Saturday. Those attending are recommended to be there by 17:00PST. Claudius Dietz Doran Drazz'zt Druid Eighmi Explorer_Bob Foxen Gazer Howard Jake JimB Jiro Jon Ken Lucifer Merlin Mithrandir OliverJones Paramour Rasputin Schlake Spike Stinglai TruthQuark feoh wes@hpsmo100.rose.hp.com The current agenda: * STRINGCMP vs STRCASECMP (and possibly adding STRNCASECMP) * FIRSTPROP/NEXTPROP vs. PROPERTIES/NEXT * the reentrant interpreter * regular expressions? - where would they go? * multi-treaded interpreter? * looping constructs and forms of limitation * property datastructures - can/should flags and pennies be removed? - efficiency vs. space vs. complexity - having permissions on properties - propdirs - property ownership and permissions * memory conservation and options - the disk-based MUCK + what about storing properties [only]? - are shared-strings worth the effort? - compression of strings * variables and arrays - should MUF be extended to have local variables to functions? - MUF array allocation * a better builtin editor - macros, should they exist? + global versus local macros + a better preprocessor? (ala /lib/cpp?) - standard models + ed/ex? * possibilities for a debugger? - what about creating a debugger in MUF + what primitives would be needed * commands to load programs from within MUF - if these are to be, what should the commands be * the hotly debated and often misunderstood FORCE primitive * making intostr, atoi, etc. able to take any form of argument? - if this is to be done, change the names to TOSTR, TOINT, TODBREF? * need more string primitives? * database primitives and standardization - DIG/OPEN/CREATE/PCREATE/... vs. NEWROOM/NEWEXIT/NEWOBJECT/NEWPLAYER/... - access to primitives * the question of locks - can/should boolean locks be removed and replaced with simple locks on programs? - what happens when an object locked-to is recycled? * possible modifications to make MUCK allow networked databases - a standardized approach - security concerns * memory concerns - should users be limited in the amount of memory one program's stackspace can take? [including the memory usage of strings] * player object quotas vs. pennies * more flags? * futures for modifications of systems - the future of 2.2.xd, 2.2fb...? -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Wed Feb 19 10:06:26 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20340; Wed, 19 Feb 92 10:06:28 -0800 Received: from morpheus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20336; Wed, 19 Feb 92 10:06:26 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA872982; Wed, 19 Feb 92 10:05:54 -0800 Date: Wed, 19 Feb 92 10:05:54 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9202191805.AA872982@nike.calpoly.edu> To: tinymuck-sloggers Subject: Mailer woes in MUF Almost every muck has their own flavor of mailer. A problem always comes up in the design phase (design? phases? Are we still talking about MUF?) about where to stuff all those silly mail properties. Some people shove them off on the player. Some of them shove everything to one object. Some people kludge the server so the players can't see their mail props (me? never!). Yet others use 'proplocs' and hide them on alternate objects. The problem is if the players see them on their player object they complain. If you stuff them on one object you're asking for trouble as you watch your server walk through literally thousands of properties on some mucks... Has anyone tried a hashing algorithm using n objects instead of just one? : get_hash_value ( -- i ) me @ n @ % ; No, couldn't be that easy. :) If you've tried this, or done this, please drop me a line and let me know if you had any big problems, drawbacks, things to look out for, etc... On a similar note, what's the best mail editor you've ever seen? Best mail system? Smallest mailer code? Anyone toyed with inter-muck mailers? (mail between two mucks??) Drop me a line --Doran awozniak@morpheus.calpoly.edu From tinymuck-sloggers-owner Wed Feb 19 11:27:47 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20684; Wed, 19 Feb 92 11:27:51 -0800 Received: from netcom.netcom.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20680; Wed, 19 Feb 92 11:27:47 -0800 Received: by netcom.netcom.com (4.1/SMI-4.1) id AA08817; Wed, 19 Feb 92 11:28:17 PST From: foxen@netcom.com (Foxen) Message-Id: <9202191928.AA08817@netcom.netcom.com> Subject: Mailer woes in MUF To: tinymuck-sloggers (TinyMUCK Tech. Mail List) Date: Wed, 19 Feb 92 11:28:16 PST X-Mailer: ELM [version 2.3 PL11] The WOZ once wrote: > Almost every muck has their own flavor of mailer. A problem always comes up > in the design phase (design? phases? Are we still talking about MUF?) about > where to stuff all those silly mail properties. Some people shove them off > on the player. Some of them shove everything to one object. Some people > kludge the server so the players can't see their mail props (me? never!). > Yet others use 'proplocs' and hide them on alternate objects. > > The problem is if the players see them on their player object they complain. > If you stuff them on one object you're asking for trouble as you watch your > server walk through literally thousands of properties on some mucks... This was one reason darkfox and I made propdirs. You can either hide the mail on the player in a propdir, so they don't have to see it unless they specify that they do on an examine, or else you can still store them on one item, but since propdirs use AVL trees, the accessing is fast. Yeah, its yet another server hack, and a fairly major one, but it worked very nicely for this sort of thing. > On a similar note, what's the best mail editor you've ever seen? Now for the actual reason I replied. I'm making a fair bit of my MUF code available for anonymous ftp at ftp.apple.com in the pub/fb directory. This includes code for a MUF text editor that is pretty advanced, with features including: insert, delete, move, copy, find, replace, split line, join lines, right, left, and center justification to X columns, formatting (like UNIX fmt) to X columns, say and pose inside the editor, and more. This editor is not intrinsic to any one program, and can be used by many different programs. On furryMUCK, it is used in both the global "list edit" command, and the Message Board's posting command. You just put the range of strings on the stack, and call the program via a macro, and it returns with the new range of strings, with a string on top that tells you how the program was exited. (ie abort, or end) Anyways, the name of the editor muf file will be lib-editor. Have fun with it! - Foxen PS: What formats does everyone use for property lists? I currently use: listname#:3 listname#/1:first line listname#/2:second line listname#/3:third line when I'm working with propdirs, (since it hides the entire list in the listname# property directory), and otherwise I use the format: listname#:3 listname1:first line listname2:second line listname3:third line. which has problems with listnames ending in numbers. Should there be a standard set up so that list editor can easily edit lists needed by several different programs? Hmm... And should this be a topic for the upcoming MUF standardizations meeting? Claudius, are you out there? *gryn* -- ___ __ ___ _ . _^^ ____ foxen@netcom.com \ / | | \ | | | -> '-" \______/___/ Another Fine Furry Fan `v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the | |___ | \ | o //|| ||| Holy Furr of Bastis!" From tinymuck-sloggers-owner Wed Feb 19 12:17:27 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20844; Wed, 19 Feb 92 12:17:31 -0800 Received: from xcf.Berkeley.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20840; Wed, 19 Feb 92 12:17:27 -0800 Received: by xcf.berkeley.edu (5.57/Ultrix3.0-C) id AA00159; Wed, 19 Feb 92 12:17:14 -0800 Date: Wed, 19 Feb 92 12:17:14 -0800 From: blojo@xcf.berkeley.edu (Jon Blow) Message-Id: <9202192017.AA00159@xcf.berkeley.edu> To: foxen@netcom.com, tinymuck-sloggers Subject: Re: Mailer woes in MUF > but since propdirs use AVL trees, the accessing is fast. But since AVL trees use like 3 pointers per node, your runtime database is totally bloated. What you really really want to do with propdirs is make them 1-dimensional skiplists with directory separations indicated by occurrences of '/' in the property name; then you get the same access time with a lot less memory, and your code runs a lot faster too. -J. From tinymuck-sloggers-owner Wed Feb 19 12:23:08 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA20855; Wed, 19 Feb 92 12:23:10 -0800 Received: from netcom.netcom.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA20851; Wed, 19 Feb 92 12:23:08 -0800 Received: by netcom.netcom.com (4.1/SMI-4.1) id AA14569; Wed, 19 Feb 92 12:23:34 PST From: foxen@netcom.com (Foxen) Message-Id: <9202192023.AA14569@netcom.netcom.com> Subject: Re: Mailer woes in MUF (fwd) To: tinymuck-sloggers (TinyMUCK Tech. Mail List) Date: Wed, 19 Feb 92 12:23:34 PST X-Mailer: ELM [version 2.3 PL11] Jon Blow once wrote: > > But since AVL trees use like 3 pointers per node, your runtime database > is totally bloated. What you really really want to do with propdirs > is make them 1-dimensional skiplists with directory separations indicated > by occurrences of '/' in the property name; then you get the same > access time with a lot less memory, and your code runs a lot faster too. > > -J. > Yes, and I was working on interfacing this nice skiplist package I have (thanks partly to you) into it about the time I decided enough was enough, and gave up on the server as too much of a drain on my time. - Foxen -- ___ __ ___ _ . _^^ ____ foxen@netcom.com \ / | | \ | | | -> '-" \______/___/ Another Fine Furry Fan `v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the | |___ | \ | o //|| ||| Holy Furr of Bastis!" From tinymuck-sloggers-owner Mon Feb 24 16:44:45 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA10632; Mon, 24 Feb 92 16:44:46 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA10628; Mon, 24 Feb 92 16:44:45 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA164973; Mon, 24 Feb 92 16:44:55 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9202250044.AA164973@nike.calpoly.edu> Subject: MUCK-S log... To: tinymuck-sloggers (user alias), daemonmuck@nike.calpoly.edu Date: Mon, 24 Feb 92 16:44:54 PST X-Mailer: ELM [version 2.3 PL11] I've placed the MUCK-Standardization Conference log on piggy.ucsb.edu... [it's currently /pub/mud/incoming/MUCK-S.2.22.92.log.Z] There will be a second Convention in weeks:3/6/1992 at 16:00PST. Agenda and location hasn't been decided yet. I would prefer if someone else would host this one, make this a travelling Convention. Contact me if you are interested. We only got through about 1/8th of the agenda...in 5 hours. Things decided upon: propdirs are to be supported, but also a #defineable thing. a standard interface to propdirs hasn't been decided upon yet. permissions are to comprise of a 1 byte [8 bits] set of flags: Bit Name Effect 7 l Locked - owner cannot change permissions on property 6 h Hidden - examine does not show, and if !controller, nextprop will skip property. 5 r Read permission for controller - controller can read the value of this property 4 w Write permission for controller - controller can write over the value of this property. [This does NOT mean that it can be deleted, write permission must be obtained on the propdir in which this property is contained.] 3 s Search permission for controller - controller can search this propdir. Ignored for flat properties. 2 r Read permission for !controller 1 w Write permission for !controller 0 s Search permission for !controller Permissions are to be placed on ALL propdirs and properties, even on !propdir systems. Wizards ignore permissions. STRINGCMP and STRINGNCMP are to be standard case-insensitive primitives. Some form of regular expression parsing or sscanf-like parsing is requested. Actual interface has yet to be decided. The following permissions MUF primitives are to be the standard: PERM( d s -- i ) - returns an integer containing the permissions flags for a property SETPERM( d s i -- ) - sets the permissions on a property This would require some sort of bit manipulation facilities in MUF. Plus it is recommended that octal and hex numbers be supported. [Octal being designated by a leading 0, hex by a leading 0x] Properties, when loaded initially off of a DB that doesn't have permissions, and when a property is created using @set and ADDPROP, they are to have the following default permissions: Leading character Permissions [*] none --rwsrws _ --rwsr-s . --rws--- * -hrwsrws ~ --r-s--- @ -h------ [Not too sure about the @ and ~, only really matters on 2.2fb releases where they are supported.] -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Tue Feb 25 12:31:51 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA17389; Tue, 25 Feb 92 12:33:23 -0800 Received: from enet-gw.pa.dec.com by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA17384; Tue, 25 Feb 92 12:31:51 -0800 Received: by enet-gw.pa.dec.com; id AA08920; Tue, 25 Feb 92 12:31:07 -0800 Message-Id: <9202252031.AA08920@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Tue, 25 Feb 92 12:31:25 PST Date: Tue, 25 Feb 92 12:31:25 PST From: "Trust an olive, but tie up your camel. 25-Feb-1992 1523" To: tinymuck-sloggers Apparently-To: tinymuck-sloggers Subject: Second MUCK-S conference Before the next conference, I have a suggestion. There is a list of about twenty discussion topics. It would be good if someone were to make up a list of oh, about eight of them, and send out a proposal for each to this list. It doesn't have to be a big deal, but the reason it didn't go quickly last time is that each proposal had to be explained at telnet speeds. This way we know what we're voting for. Also, when I was on PythonMUCK, I noticed a bunch of other neat enhancements. All of us who run worlds should (some day) come up with a list of all the enhancements we've made to the system, so we can standardize on *those*, too. Jon From tinymuck-sloggers-owner Tue Feb 25 15:03:42 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA17834; Tue, 25 Feb 92 15:03:43 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA17829; Tue, 25 Feb 92 15:03:42 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA187970; Tue, 25 Feb 92 15:03:26 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9202252303.AA187970@nike.calpoly.edu> Subject: Re: Second MUCK-S conference To: callas@eris.enet.dec.com (Trust an olive, but tie up your camel. 25-Feb-1992 1523) Date: Tue, 25 Feb 92 15:03:25 PST Cc: tinymuck-sloggers In-Reply-To: <9202252031.AA08920@enet-gw.pa.dec.com>; from "Trust an olive, but tie up your camel. 25-Feb-1992 1523" at Feb 25, 92 12:31 pm X-Mailer: ELM [version 2.3 PL11] >Before the next conference, I have a suggestion. > >There is a list of about twenty discussion topics. It would be good if someone >were to make up a list of oh, about eight of them, and send out a proposal for >each to this list. It doesn't have to be a big deal, but the reason it didn't >go quickly last time is that each proposal had to be explained at telnet >speeds. This way we know what we're voting for. > >Also, when I was on PythonMUCK, I noticed a bunch of other neat enhancements. >All of us who run worlds should (some day) come up with a list of all the >enhancements we've made to the system, so we can standardize on *those*, too. Let's have a conference to choose the conference topics! NOT. Anyways, I'll go ahead and choose the agenda items that I think people are most interested in getting out of the way and especially those that don't take much time at all. As for those 'special enhancements' all I did was create a say and pose command and lock them to properties, plus the board. All could be quickly modified to run on 2.2fb or even 2.2 vanilla. As for the other enhancements, [like how say worked and such] I don't think we'll EVER get agreement between servers...people like me are stubborn. I'd like to get the lower layers ironed out first, then work on the complicated stuff. This reminds me: I'd like to propose a discussion on tinymuck-sloggers in the meantime: If we can replace a system command such as @desc with a MUF command, should we take @desc out of the server code and just provide a MUF program with a minimal db? Do people like the flexibility or the standardization of having a systemwide command? -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Thu Mar 5 11:32:25 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07925; Thu, 5 Mar 92 11:32:27 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07921; Thu, 5 Mar 92 11:32:25 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA107877; Thu, 5 Mar 92 11:32:45 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9203051932.AA107877@nike.calpoly.edu> Subject: Second MUCK-S Conference To: daemonmuck@nike.calpoly.edu, tinymuck-sloggers (user alias) Date: Thu, 5 Mar 92 11:32:43 PST X-Mailer: ELM [version 2.3 PL11] WHAT: The second MUCK-Standardization Convention WHEN: 16:00 PST 3/7/92 (Saturday) WHERE: TimeTraveller MUCK->betz.biostr.washington.edu 4096. Connect and create your character if you don't have one already. [thanks to Codrus for offering it] From the inner nexus type 'conference' and it'll take you to the conference room. There is no preregistration this time, and the agenda isn't going to be as strongly adhered to. Seeyathere! AGENDA: * variables and arrays - should MUF be extended to have local variables to functions? - MUF array allocation * a better builtin editor - macros, should they exist? + global versus local macros + a better preprocessor? (ala /lib/cpp?) - standard models + ed/ex? * FORCE primitive * looping constructs and forms of limitation * property datastructures - progress report * memory conservation and options - the disk-based MUCK + what about storing properties [only]? + storing individual properties vs. all properties on each obj. - are shared-strings worth the effort? - compression of strings * possibilities for a debugger? - what about creating a debugger in MUF + what primitives would be needed * commands to load programs from within MUF - if these are to be, what should the commands be * making intostr, atoi, etc. able to take any form of argument? - if this is to be done, change the names to TOSTR, TOINT, TODBREF? * the question of locks - can/should boolean locks be removed and replaced with simple locks on programs? - what happens when an object locked-to is recycled? * possible modifications to make MUCK allow networked databases - a standardized approach - security concerns * memory concerns - should users be limited in the amount of memory one program's stackspace can take? [including the memory usage of strings] * futures for modifications of systems - the future of 2.2.xd and 2.2fb and other versions * standardizing 'examine' and other commands -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Mon Mar 9 12:32:44 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA25708; Mon, 9 Mar 92 12:32:45 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA25704; Mon, 9 Mar 92 12:32:44 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA169923; Mon, 9 Mar 92 12:31:38 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9203092031.AA169923@nike.calpoly.edu> Subject: CALL and reentrancy To: daemonmuck@nike.calpoly.edu, tinymuck-sloggers (user alias) Date: Mon, 9 Mar 92 12:31:37 PST X-Mailer: ELM [version 2.3 PL11] With the possibility of having reentrancy, we could create a protected CALL very easily...question is, what should be passed/returned? PCALL ( d s -- s ) ok? -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Mon Mar 9 12:48:59 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA25838; Mon, 9 Mar 92 12:49:01 -0800 Received: from morpheus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA25834; Mon, 9 Mar 92 12:48:59 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA827636; Mon, 9 Mar 92 12:49:11 -0800 Date: Mon, 9 Mar 92 12:49:11 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9203092049.AA827636@nike.calpoly.edu> To: claudius@nike.calpoly.edu, daemonmuck@nike.calpoly.edu, tinymuck-sloggers Subject: Re: CALL and reentrancy An integer. Doesn't break existing code, no big stuff to add. Just like the integer returned from a lock... --Doran From tinymuck-sloggers-owner Mon Mar 9 13:02:41 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA25920; Mon, 9 Mar 92 13:02:43 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA25916; Mon, 9 Mar 92 13:02:41 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA177201; Mon, 9 Mar 92 12:51:19 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9203092051.AA177201@nike.calpoly.edu> Subject: Re: CALL and reentrancy To: awozniak@nike.calpoly.edu (The WOZ) Date: Mon, 9 Mar 92 12:51:19 PST Cc: claudius@nike.calpoly.edu, daemonmuck@nike.calpoly.edu, tinymuck-sloggers In-Reply-To: <9203092049.AA827636@nike.calpoly.edu>; from "The WOZ" at Mar 9, 92 12:49 pm X-Mailer: ELM [version 2.3 PL11] >An integer. Doesn't break existing code, no big stuff to add. >Just like the integer returned from a lock... Well, you coundn't replace the current CALL with that...many programmers expect lots of return stuff on the stack when they do a CALL...just look at how XR was designed...[much of the functionality was in CALLed routines if I'm not mistaken...] -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Mon Mar 16 09:13:26 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA05428; Mon, 16 Mar 92 09:13:28 -0800 Received: from morpheus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA05424; Mon, 16 Mar 92 09:13:26 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA814774; Mon, 16 Mar 92 09:13:30 -0800 Date: Mon, 16 Mar 92 09:13:30 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9203161713.AA814774@nike.calpoly.edu> To: tinymuck-sloggers Subject: wierd flags in strange places... Just bopping about on the net and saw someplace where you could set a room MISTY (M). Anyone in the know what this does? (just curious) --Doran From tinymuck-sloggers-owner Mon Mar 16 09:30:01 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA05458; Mon, 16 Mar 92 09:30:03 -0800 Received: from zeus.CalPoly.EDU by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA05454; Mon, 16 Mar 92 09:30:01 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA183353; Mon, 16 Mar 92 09:30:25 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9203161730.AA183353@nike.calpoly.edu> Subject: Re: wierd flags in strange places... To: awozniak@nike.calpoly.edu (The WOZ) Date: Mon, 16 Mar 92 9:30:24 PST Cc: tinymuck-sloggers In-Reply-To: <9203161713.AA814774@nike.calpoly.edu>; from "The WOZ" at Mar 16, 92 9:13 am X-Mailer: ELM [version 2.3 PL11] >Just bopping about on the net and saw someplace where you could set a room >MISTY (M). Anyone in the know what this does? (just curious) Maybe 'sometimes dark'? Hehehehe...[sounds interesting and entirely useless] -- claudius@zeus.calpoly.edu (King_Claudius) From tinymuck-sloggers-owner Tue Mar 17 11:00:18 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA10195; Tue, 17 Mar 92 11:00:20 -0800 Received: from zeus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA10191; Tue, 17 Mar 92 11:00:18 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA198174; Tue, 17 Mar 92 11:00:46 -0800 From: claudius@nike.calpoly.edu (King_Claudius) Message-Id: <9203171900.AA198174@nike.calpoly.edu> Subject: DaemonMUCK 2.2.9 release announcement To: daemonmuck@nike.calpoly.edu, tinymuck-sloggers (user alias) Date: Tue, 17 Mar 92 11:00:46 PST X-Mailer: ELM [version 2.3 PL11] Announcing probably the most revolutionary change in MUCK development: 2.2.9 now no longer stores stack frames on players. This means TRUE MULTITHREADING....plus such features as FORK and EXEC and FORCE on objects that are not players are just steps away. Daemons are gone now [we're goiong to rename our code in the next release...] and we're happy to see them go. Also in 2.2.9: propdirs AND permissions! [As discussed in the MUCK-S convention] You [yes YOU] can pick up the sourcecode from piggy.ucsb.edu [either in pub/mud/incoming or pub/mud/tinymuck, check both for any further releases] Also here to support the sourcecode and discuss the developments is the daemonmuck mailing list. Send mail to daemonmuck-request@zeus.calpoly.edu to be added. Drop by PythonMUCK [zeus.calpoly.edu 4201] to catch the latest changes as they happen. [Funding for this blatant plug provided by the Monks of Antioch] -- claudius@zeus.calpoly.edu (King_Claudius) From chupchup Wed Mar 18 17:29:55 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA18350; Wed, 18 Mar 92 17:29:56 -0800 Received: from localhost.ucsb.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA18346; Wed, 18 Mar 92 17:29:55 -0800 Message-Id: <9203190129.AA18346@piggy.ucsb.edu> To: tinymuck-sloggers Subject: bounced mail... last try Reply-To: rearl Date: Wed, 18 Mar 92 17:29:54 PST From: Robert Earl Does anyone know who belongs to the following address, or how I could get in touch with him/her? The mail to here has been bouncing lately with "Unknown user" errors. <8936547@ugrad.cs.su.oz.au> Sorry, there's no real name or even a non-numeric login name. From tinymuck-sloggers-owner Fri Apr 3 12:17:30 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA14586; Fri, 3 Apr 92 12:17:32 -0800 Received: from morpheus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA14582; Fri, 3 Apr 92 12:17:30 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA847532; Fri, 3 Apr 92 12:17:31 -0800 Date: Fri, 3 Apr 92 12:17:31 -0800 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9204032017.AA847532@nike.calpoly.edu> To: tinymuck-sloggers Subject: interface.c Is it just me, or is interface.c gross? Or am I just stupid? (don't answer that :) --Doran From tinymuck-sloggers-owner Fri Apr 24 14:54:07 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07821; Fri, 24 Apr 92 14:54:09 -0700 Received: from morpheus.calpoly.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07817; Fri, 24 Apr 92 14:54:07 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA813794; Fri, 24 Apr 92 14:52:56 -0700 Date: Fri, 24 Apr 92 14:52:56 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9204242152.AA813794@nike.calpoly.edu> To: tinymuck-sloggers Subject: TinyMuck 2.3 ??? I hear it's out, but have not seen any 'official' announcements. Is this rumor true? --Adam From jim Fri Apr 24 15:09:24 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07856; Fri, 24 Apr 92 15:09:30 -0700 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07851; Fri, 24 Apr 92 15:09:24 -0700 Date: Fri, 24 Apr 92 15:09:24 -0700 From: Jim Lick Message-Id: <9204242209.AA07851@piggy.ucsb.edu> To: awozniak@nike.calpoly.edu, tinymuck-sloggers Subject: Re: TinyMuck 2.3 ??? >From: awozniak@nike.calpoly.edu (The WOZ) > >I hear it's out, but have not seen any 'official' announcements. > >Is this rumor true? No, it's not. Time Traveller is running an alpha test of 2.3, so it is in production use. However, it is not released yet. I've been told that the release will be announced on the sloggers list first. Jim Lick Work: University of California | Play: 6657 El Colegio #24 Santa Barbara | Isla Vista, CA 93117-4280 Dept. of Mechanical Engr. | (805) 968-0189 voice/msg 2311 Engr II Building | "when you gonna make up your mind? (805) 893-4113 | when you gonna love you as much jim@ferkel.ucsb.edu | as i do?" -Tori Amos From tinymuck-sloggers-owner Fri Apr 24 15:21:52 1992 Received: by piggy.ucsb.edu (Sendmail 5.65b/1.05) id AA07893; Fri, 24 Apr 92 15:21:55 -0700 Received: from ucsd.edu by piggy.ucsb.edu via SMTP (Sendmail 5.65b/1.05) id AA07889; Fri, 24 Apr 92 15:21:52 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA18987 sendmail 5.64/UCSD-2.2-sun via SMTP Fri, 24 Apr 92 15:21:48 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA16626 for tinymuck-sloggers@piggy.ucsb.edu; Fri, 24 Apr 92 15:21:36 pdt Date: Fri, 24 Apr 92 15:21:36 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9204242221.AA16626@sdnp1.UCSD.EDU> To: awozniak@nike.calpoly.edu (The WOZ) Cc: tinymuck-sloggers Subject: TinyMuck 2.3 ??? In-Reply-To: The WOZ's message of Fri April 24, 1992, at 14:52:56 References: <9204242152.AA813794@nike.calpoly.edu> Reply-To: dmoore@ucsd.edu The WOZ writes: | | I hear it's out, but have not seen any 'official' announcements. | | Is this rumor true? | | --Adam 1) It's not out. 2) There haven't been any official announcements, yet. 3) The rumor that you haven't seen any announcements is true. :) 4) I started writing an announcement 2 weeks ago, but I got very busy with work for my job. The first place an official announcement will occur will be on this list (tmuck-sloggers). 5) I (and chupchup) don't want to deal w/ a lot of people mailing asking questions about 2.3 at this time. There will be an official announcement at some point. Probably in the near future. 6) There is no official release date as of this time. I've been very busy with work, as I said above. 7) I (and chupchup) probably aren't in the mood to humor lots of suggestions and other mail pouring in at this time. Summary: No official announcement yet. There will be one. Pretend you didn't hear a thing about 2.3 until you get the official announcement. Don't mail asking about questions, your favorite feature, suggestions, etc. They will be ignored, I don't have time to deal with them currently. David "OliverJones" Moore From tinymuck-sloggers-owner Tue Jun 23 05:31:57 1992 Received: by piggy.ucsb.edu id AA17491 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 23 Jun 1992 12:32:46 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA17487 (5.65c/IDA-1.4.4 for ); Tue, 23 Jun 1992 12:32:43 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA13827 sendmail 5.64/UCSD-2.2-sun via SMTP Tue, 23 Jun 92 12:32:48 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA00825 for tinymuck-sloggers@piggy.ucsb.edu; Tue, 23 Jun 92 12:31:57 pdt Date: Tue, 23 Jun 92 12:31:57 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9206231931.AA00825@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: test message Reply-To: dmoore@ucsd.edu please ignore From tinymuck-sloggers-owner Wed Jun 24 15:14:51 1992 Received: by piggy.ucsb.edu id AA24403 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 24 Jun 1992 22:15:48 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA24399 (5.65c/IDA-1.4.4 for ); Wed, 24 Jun 1992 22:15:45 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA14582 sendmail 5.64/UCSD-2.2-sun via SMTP Wed, 24 Jun 92 22:15:44 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA02433 for tinymuck-sloggers@piggy.ucsb.edu; Wed, 24 Jun 92 22:14:51 pdt Date: Wed, 24 Jun 92 22:14:51 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9206250514.AA02433@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Information about 2.3 Reply-To: dmoore@ucsd.edu I am probably going to bed now, but I'll mail this first letter tonight. This will give folks a chance to hop off the list if they want to. Note that I don't expect the traffic to get too bad, IF people follow the suggestions below. More letters to follow tomorrow. -- In the next few letters I will be explaining TinyMUCK 2.3. In order to keep traffic on this mailing list down to a reasonable amount (and to help me), I am going to propose the following structure on how to ask questions (if you have any). Note, there will be more letters directly following this one, so wait before replying. If you have any questions, mail them directly to _me_ (dmoore@ucsd.edu) and not to the mailing list. To make things easier, please stick something meaningful in the subject of the letter, like 'muck 2.3'. If you use a subject I don't immediately recognize it's likely to sit longer in my mail folder (I am giving priority to muck questions). If you mail to the list, it's possible I will also ignore it. Now, what I will do with the questions is read them over, and try to from them generate a list of commonly asked questions (as well as good ones) and then I will answer them. I will send that out to the list, in the question/answer format. By mailing directly to me, I can collate questions and organize them. If you mail to the list you will generate needless traffic. I want to make it clear at this point, I am _not_ looking for a discussion on 2.3 raging on tinymuck-sloggers. I do want to answer people's questions, and try elucidate what 2.3 is all about, and how it's about. At this point, suggestions for features will most likely be ignored and are not being sought out. For a more interactive discussion, you can come to MallocMUCK [1], where I am logged in essentially 24 hours a day as 'Students'. My tf is fairly stable so if you talk to me, I'll probably see it. Also, if I'm there I will talk to you. At various times server discussions occur depending on my mood (and who else is there) which range over wide topics (from internals, general issues, macro libraries, etc). On there you are also likely to find Ben, who knows a fair amount about what is going on. Now that that's out of the way, more messages to follow. David "OliverJones" [1] MallocMUCK betz.biostr.washington.edu (128.95.10.119) port 6666. -- David Moore - SysAdmin/Programmer UCSD | Dept. of Anesthesiology | V-151 | La Jolla, CA 92093-9151 Work Phone: (619) 552-8585 x7042 "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From tinymuck-sloggers-owner Thu Jun 25 08:03:18 1992 Received: by piggy.ucsb.edu id AA26203 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 25 Jun 1992 15:04:27 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA26199 (5.65c/IDA-1.4.4 for ); Thu, 25 Jun 1992 15:04:18 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA02294 sendmail 5.64/UCSD-2.2-sun via SMTP Thu, 25 Jun 92 15:04:14 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA02976 for tinymuck-sloggers@piggy.ucsb.edu; Thu, 25 Jun 92 15:03:18 pdt Date: Thu, 25 Jun 92 15:03:18 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9206252203.AA02976@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: History of 2.3 Reply-To: dmoore@ucsd.edu A brief history of TinyMUCK 2.3 follows. This should hopefully explain why things were done, and where the various design decisions for the server came from. Around December 1991 TimeTraveller was taken from it's site at ucsd to betz. When at ucsd, there were no apparent [1] problems with the muck server code, however upon reaching betz the server would not stay up over a few hours without dying a horrible death. At the time the problems were tracked to core dumps occurring inside the malloc routines. An alternate malloc package was used, and I suggested some ways for Codrus to clean up malloc usages to hopefully detect problems like freeing NULL, or freeing already used data. This detected very quickly some bugs in the server which were fixed up readily. Things lasted longer, but weren't great. At some point I offered to directly work on the server to help with these bugs to get it stable enough to run. I wrote up a debugging malloc package, and had the server use it. This found many more problems, which I cleaned up. I had also written the package to track memory leaks, and it became very apparent that muck leaks like a sieve in many locations. Some of these I fixed up, if they were relatively easy. Other leaks would have involved some fairly decent rewrites of large portions of code. So up to here, I was entirely working to simply fix bugs in the server, I was using the coding style of whatever section of code I was in, and not making large changes. Soon other very fatal bugs in the server, namely buffer overflows, came under my scrutiny. I started to fix them up on a one by one basis. Then it occurred to me that the right way to handle all of this would be to have a buffer package. But then I worried that I would be performing enhancements and large rewrites to the server. But eventually my desire to see it done right and with some prodding by other people, I wrote it up this way. Chupchup helped by writing an early version of the Bufsprint routine which provided easier access to the buffer routines. At Chris's encouragement, I reformatted every file in the distribution to the _same_ indentation style. So, this marks the beginning of the larger changes to the server. But it should be clear that all of these changes are strictly internal, bug fixes, and the right way of dealing with some of these problems. They are entirely transparent changes to the user [2], and make the code more readable and more stable. Following spending a good week+ rewriting every portion of the code to efficiently make use of the buffers. I went and changed how fields on objects (and flags) were accessed. Rather than someone doing: db[x].desc they got changed to GetDesc(x), with a macro to hide the internals. I did this change to make the code more readable. And I knew that this was how it should be done in case anyone in the future every wanted to consider disk basing or changing the layouts of objects in various ways. Changing all of these references in the code only took a couple days. It wasn't very fun. Extremely boring drudge work, but it was needed. Hey, I like how these four lines all line up perfectly at the period. Somewhere around this time, I fixed a known bug in the interface which took some rewriting. This bug was namely the 'Famous @boot Bug', which can be found to have been ''fixed'' a few times already if you look in the RCS logs. :) From another muck it was found that '@force some-wizard = @boot first-wizard' would happily crash the system to bits. So I rewrote the interface code to properly handle this. Also some additional cleanup was done. Now, at some point TT had a situation which could desire some lockout code. So I wrote up a nice lockout package, and it was added in. This lockout code removed the need for registration code in the interface, so it was removed. Oh, TT's db was corrupted badly at some point, I don't remember the order that things occurred exactly. So I wrote up a new sanity checker which was actually useful in being able to find problems with the database unlike the old one which was pretty poor. The sanity checker even has automatic repair options now. The 2.2 version of the checker was used by Jingoro to find problems in the CaveMUCK database, and was sent to the Furry wizards when their db became corrupted. I later heard that it was useful. It turned out the cause of the corruption was a bug in the operating system (AIX 3.1 perhaps also hardware troubles on the machine) [3]. To fix this I looked into the dumping code for the muck. I rewrote the general dumping method, removing the bad suggestion of using vfork, coding a proper inline dump, cleaning up forked dump method. I also changed how dumps are set off, avoiding the use of alarm, and found a few race conditions in this code and in the interface code which I also fixed. Around here, the idea of actually releasing this code as either 2.3 or as a bug fix patch to 2.2 was decided upon. It could have easily been released as a 2.2 patch, since it essentially offered only bug fixes and no new features, however the changes to the internals were a bit large. I did some math using various databases I had available, and realized that I could save memory by sticking the various text fields (such as desc, succ, etc, but not name) as properties on objects rather than directly on the object structure. Luckily this was an extremely easy change since I had already done all of the hard work earlier. About this time the dump format changed to something far saner. Also, these properties used for desc/etc, were made internal properties which means they are not visible from muf, and live in a separate name space entirely. Code in db.c was extensively cleaned up as the new dump format was designed and planned. One particular problem we noticed was the db locking up for a few seconds (20-40) at a time. So I added some code to track who was running what muf program on various slices. It turned out that the culprit was our mailer! Our mail object had at the time about 10,000 properties on it. This wasn't so bad, except that the mailer didn't do editing on the stack, it did it in properties. So if you entered a few lines of text, and then deleted a line in the middle, it had to renumber all of the following lines. This caused many, many O(n) operations to this object. I decided to rewrite the property code. I was well aware of the decisions to use trees in other servers, however after thinking about it, I chose to use a hash table [4]. One hash table is used for _every_ property in the system. In a sense this allows objects with few properties to distribute the load with objects with a lot of properties. This caused no visible changes to anyone other than speed improvements. Various places got cleaned up. I finally decided to rewrite the editor. I was able to maintain keeping my lunch in my stomach long enough while reading the old one to hopefully duplicate it's visible functionality. I clear distinction was made between lowish level text operations, and what the editor did. An efficient text package was written to actually handle the data, the editor code merely provided the user interface on top of it. It should be quite easy for someone to rewrite that to a different form of editor. Some bugs apparently never noticed before were found in the old editor source. They were fixed, they were used to crash FurryMUCK, they were fixed on Furry. I now no longer talk about fatal bugs as much. I rewrote the entire interface again. This time to use the text package rather than it's own queues. It was also made far more efficient, and does it's best to send the trailing "\r\n" in the same packet as the line it's on. This can be considered a nice win for many clients, and halves the number of times the server has to call 'write'. Also, some point near the beginning, I rewrote how the builtin commands were handled. Shell scripts are used to convert simple files into the proper header files for the builtins/editor command lists. The interpreter/compiler are being rewritten after much design and planning has gone into working out a nice extensible clean method of handling various things. Hostname code was added which lessens your reliance on name servers and meshes well with the lockout package. Many many things were rewritten in small and large amounts. It's hard for me to actually remember them all at this point, perhaps if I missed something major someone could email me with that as a question. Also, Jiro/Mizue (who is doing player/mucker docs for 2.3), Ben (who is working on the macro library), and chupchup might have some ideas about things I've left out. They are generally reasonably clued in about 2.3, but the last word on things of course comes from me. Hopefully this explains a bit the history behind the development of 2.3, what it's motivations were. If I were asked to describe what the point of 2.3 is in just a few words I'd say that it was to be stable, bug free, cleanly written, very easily extendable, and the code code should be readable. David "OliverJones" [1] There were apparently other problems. Namely the next did have approximately weekly kernel panics which stopped once TT left the machine. Other mach based mucks have shown some similar crashing patterns. This of course tells us that the OS isn't very stable if a user program can crash things. But it also shows that even on machines where muck apparently runs alright, it still has bad bugs which can affect you in many ways. [2] I say no user visible changes. But I guess you could call having a mud which doesn't crash, and do stupid things w/ buffers a visible change. [3] AIX has copy-on-write fork/vfork semantics much like SunOS and other newer unix releases. However, amazingly enough (as a test program I wrote showed) it _SHARES_ some of the pages between the parent and child at times. This is badly losing. [4] There are hashtable and linked lists versions of property code both available for 2.3. The hashtable is faster, but does take more memory than the much slower linked lists. -- David Moore - SysAdmin/Programmer UCSD | Dept. of Anesthesiology | V-151 | La Jolla, CA 92093-9151 Work Phone: (619) 552-8585 x7042 "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From tinymuck-sloggers-owner Tue Aug 4 18:28:07 1992 Received: by piggy.ucsb.edu id AA04540 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 4 Aug 1992 19:29:07 -0700 Received: from blaze.cs.jhu.edu ([128.220.13.50]) by piggy.ucsb.edu with SMTP id AA04536 (5.65c/IDA-1.4.4 for ); Tue, 4 Aug 1992 19:29:04 -0700 Message-Id: <199208050229.AA04536@piggy.ucsb.edu> Received: from mail-client (jyusenkyou.cs.jhu.edu) by blaze.cs.jhu.edu; Tue, 4 Aug 92 22:29:04 EDT Date: Tue, 4 Aug 92 22:28:07 EDT From: arromdee@blaze.cs.jhu.edu Sender: arromdee@blaze.cs.jhu.edu To: tinymuck-sloggers@piggy.ucsb.edu Subject: moveto X-Face: %+?l4Tsy_f|BAjdQt'l{lepxV)F==X3Z|BgE^igzD1p[Glqxiq%r!N&7'xy/<=Cak]N2WnM irsYLgS=L&^MVIC~b(/'/?+W(ol%lm?h\dYPC{:@_N=BpgCWg[Y;LH="M=+B.:T:!H4k*V~^=D&/`T YBL!X{&)0K&ILIcSK93Lw&)0%/i u'T$E/k{Y;`_/Rak&_:bAEjb%*=yvO:x~Wz(qav}X"}!\lwN Muck contains the following code for moveto permissions for things (this is from 2.3, but is essentially fossil code): if (!wizard) { if (permissions(uid, dest)) matchroom = dest; if (permissions(uid, GetLoc(victim))) matchroom = GetLoc(victim); if (matchroom != NOTHING && !HasFlag(matchroom, JUMP_OK) && !permissions(uid, victim)) abort_interp("Permission denied."); } Documentation claims the moveto permissions are: If the object being moved is not a player, is owned by the owner of either the source or destination rooms, and either room where the ownership matches is !JUMP_OK, the moveto fails. The code comes nowhere near the documentation, of course. The code has two problems: 1) it checks to see if the object is owned by the current effective uid instead of checking to see if it's owned by the owner of the room. 2) only one matchroom is actually checked, so a source room which is a matchroom but J will hide an !J destination even if the destination is also a matchroom. (This in turn means you can have permission to move an object somewhere without having permission to move it out.) Does anyone have any ideas about what the code _is_ supposed to do? And if so, whether or not it's actually a good idea to do it that way? (The documentation seems to describe something rather odd. The best explanation I've heard is that it's intended to keep you from breaking someone else's puzzles, so you can't move their own objects around within them.) From tinymuck-sloggers-owner Wed Aug 5 11:31:29 1992 Received: by piggy.ucsb.edu id AA06390 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 12:32:36 -0700 Received: from blaze.cs.jhu.edu by piggy.ucsb.edu with SMTP id AA06386 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 12:32:33 -0700 Message-Id: <199208051932.AA06386@piggy.ucsb.edu> Received: from mail-client (jyusenkyou.cs.jhu.edu) by blaze.cs.jhu.edu; Wed, 5 Aug 92 15:32:28 EDT Date: Wed, 5 Aug 92 15:31:29 EDT From: arromdee@blaze.cs.jhu.edu Sender: arromdee@blaze.cs.jhu.edu To: tinymuck-sloggers@piggy.ucsb.edu Subject: test X-Face: %+?l4Tsy_f|BAjdQt'l{lepxV)F==X3Z|BgE^igzD1p[Glqxiq%r!N&7'xy/<=Cak]N2WnM irsYLgS=L&^MVIC~b(/'/?+W(ol%lm?h\dYPC{:@_N=BpgCWg[Y;LH="M=+B.:T:!H4k*V~^=D&/`T YBL!X{&)0K&ILIcSK93Lw&)0%/i u'T$E/k{Y;`_/Rak&_:bAEjb%*=yvO:x~Wz(qav}X"}!\lwN Please ignore. From tinymuck-sloggers-owner Wed Aug 5 07:35:11 1992 Received: by piggy.ucsb.edu id AA07036 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 14:28:06 -0700 Received: from nike.calpoly.edu (zeus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA07032 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 14:28:03 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA176710; Wed, 5 Aug 92 14:35:12 -0700 From: claudius@nike.calpoly.edu (King_Claudius (Chris Knight)) Message-Id: <9208052135.AA176710@nike.calpoly.edu> Subject: Re: moveto To: arromdee@blaze.cs.jhu.edu Date: Wed, 5 Aug 92 14:35:11 PDT Cc: tinymuck-sloggers@piggy.ucsb.edu In-Reply-To: <199208050229.AA04536@piggy.ucsb.edu>; from "arromdee@blaze.cs.jhu.edu" at Aug 4, 92 10:28 pm X-Mailer: ELM [version 2.3 PL11] arromdee@blaze.cs.jhu.edu says: >Documentation claims the moveto permissions are: > > If the object being moved is not a player, is owned by the owner of > either the source or destination rooms, and either room where the > ownership matches is !JUMP_OK, the moveto fails. Read this as: If source & destination are both J, and the object being moved is owned/controlled by the owner of either the source or destination room's owner, move the object. How I remember it: If source & destination are J and the object is controlled by the mover [controlled rules are a long story] then the object can be moved. I don't remember it having anything to do with the room's owners. >1) it checks to see if the object is owned by the current effective uid >instead of checking to see if it's owned by the owner of the room. Yeah, makes a little sense. It'd be kinda rude if you can move everyone out of your rooms all the time, including wizards. >2) only one matchroom is actually checked, so a source room which is a >matchroom but J will hide an !J destination even if the destination is also a >matchroom. (This in turn means you can have permission to move an object >somewhere without having permission to move it out.) Huh? I don't get this one. >Does anyone have any ideas about what the code _is_ supposed to do? And if >so, whether or not it's actually a good idea to do it that way? (The >documentation seems to describe something rather odd. The best explanation >I've heard is that it's intended to keep you from breaking someone else's >puzzles, so you can't move their own objects around within them.) PERSONALLY: I think the moveto code in tinymuck 2.2 was very dumb. From what I remember of how I changed it, I'd guess the most realistic rules would be: If dest is locked against object being moved, fail. If object is not a 'thing' and is not controlled by the player, fail. If dest is link_ok and mover is a builder, succeed. If source AND dest are jump_ok, succeed. [allowing people to moveto without being able to link to...] That's about it. Even though the link_ok rule isn't supported in tinymuck, a link_ok room is easy to move objects to... -- ---King Claudius--- claudius@zeus.calpoly.edu From tinymuck-sloggers-owner Wed Aug 5 13:30:45 1992 Received: by piggy.ucsb.edu id AA07051 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 14:31:49 -0700 Received: from blaze.cs.jhu.edu by piggy.ucsb.edu with SMTP id AA07047 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 14:31:46 -0700 Message-Id: <199208052131.AA07047@piggy.ucsb.edu> Received: from mail-client (jyusenkyou.cs.jhu.edu) by blaze.cs.jhu.edu; Wed, 5 Aug 92 17:31:44 EDT Date: Wed, 5 Aug 92 17:30:45 EDT From: arromdee@blaze.cs.jhu.edu Sender: arromdee@blaze.cs.jhu.edu To: tinymuck-sloggers@piggy.ucsb.edu Subject: Re: moveto X-Face: %+?l4Tsy_f|BAjdQt'l{lepxV)F==X3Z|BgE^igzD1p[Glqxiq%r!N&7'xy/<=Cak]N2WnM irsYLgS=L&^MVIC~b(/'/?+W(ol%lm?h\dYPC{:@_N=BpgCWg[Y;LH="M=+B.:T:!H4k*V~^=D&/`T YBL!X{&)0K&ILIcSK93Lw&)0%/i u'T$E/k{Y;`_/Rak&_:bAEjb%*=yvO:x~Wz(qav}X"}!\lwN >>2) only one matchroom is actually checked, so a source room which is a >>matchroom but J will hide an !J destination even if the destination is also a >>matchroom. (This in turn means you can have permission to move an object >>somewhere without having permission to move it out.) >Huh? I don't get this one. The intended result is: check both rooms. If the permissions match in either room, check to see if the room in question is J. What the code does is: If the permissions match in the first room, matchroom=the first room. If the permissions match in the second room, matchroom=the second room. Check to see if matchroom is J. This doesn't do the same thing. From tinymuck-sloggers-owner Wed Aug 5 13:36:41 1992 Received: by piggy.ucsb.edu id AA07098 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 14:37:44 -0700 Received: from snow.white.toronto.edu by piggy.ucsb.edu with SMTP id AA07094 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 14:37:41 -0700 Received: from localhost (stdin) by snow.white.toronto.edu with SMTP id 28752; Wed, 5 Aug 92 17:36:45 EDT To: tinymuck-sloggers@piggy.ucsb.edu Subject: Re: moveto In-Reply-To: claudius's message of Wed, 05 Aug 92 17:35:11 -0400. <9208052135.AA176710@nike.calpoly.edu> Date: Wed, 5 Aug 92 17:36:41 EDT From: Chris Siebenmann Message-Id: <92Aug5.173645edt.28752@snow.white.toronto.edu> | Yeah, makes a little sense. It'd be kinda rude if you can move | everyone out of your rooms all the time, including wizards. Why? You already can, after all; it just takes a little bit more work. (except for wizards; you have to recycle the room to get them out) I see no reason to disallow 'sweep' programs. [Claudius's moveto rules:] | If dest is locked against object being moved, fail. Using room locks is nice, but is unfortunately not backwards compatable; there is existing building that uses room locks to mean specific things. If 2.3/you/whoever is willing to tell them to bugger off, I think that's decently cool; may I propose a few modest ideas as to what else to do with room locks? - cks From tinymuck-sloggers-owner Wed Aug 5 08:06:59 1992 Received: by piggy.ucsb.edu id AA07316 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 15:09:08 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA07312 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 15:09:05 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA07752 sendmail 5.67/UCSD-2.2-sun via SMTP Wed, 5 Aug 92 15:09:05 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA04603 for tinymuck-sloggers@piggy.ucsb.edu; Wed, 5 Aug 92 15:06:59 pdt Date: Wed, 5 Aug 92 15:06:59 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9208052206.AA04603@sdnp1.UCSD.EDU> To: cks@white.toronto.edu, tinymuck-sloggers@piggy.ucsb.edu Subject: Re: moveto I think Jiro's point was that the 2.2 docs sucked. Ok, maybe that wasn't his point, but merely my interpretation of them as far as moveto. Let's face it 2.2 moveto was a crock. And was the largest security hole in the entire muf design. Summary on what a decent moveto probably looks like (suggestions?): Object/Player/Program: 1) euid/wizard or jump_ok perms on object 2) euid/wizard or abode (or jump_ok if room _only_) perms on destination (note this gives meaning to A on players). 3) if object perms are from jump_ok, euid/wizard (or jump_ok rooms) perms on source 4) no players in players, obviously Rooms: 1) euid/wizard perms on room 2) euid/wizard or abode perms on destination 3) no source conditions Exits: 1) euid/wizard perms on exit 2) euid/wizard perms on destination I'll have to think about it more, before I change it's semantics for 2.3. Tho, I'd really love to break programs which stick objects on me or in my rooms. Locks on rooms. I know a bunch of nice things to do with locks in rooms, but I don't think I wish to change those semantics at this point. Some people amazingly still actually use them the way they were designed. OJ From tinymuck-sloggers-owner Wed Aug 5 14:20:31 1992 Received: by piggy.ucsb.edu id AA07411 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 15:21:34 -0700 Received: from blaze.cs.jhu.edu by piggy.ucsb.edu with SMTP id AA07407 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 15:21:31 -0700 Message-Id: <199208052221.AA07407@piggy.ucsb.edu> Received: from mail-client (jyusenkyou.cs.jhu.edu) by blaze.cs.jhu.edu; Wed, 5 Aug 92 18:21:30 EDT Date: Wed, 5 Aug 92 18:20:31 EDT From: arromdee@blaze.cs.jhu.edu Sender: arromdee@blaze.cs.jhu.edu To: tinymuck-sloggers@piggy.ucsb.edu Subject: Re: moveto X-Face: %+?l4Tsy_f|BAjdQt'l{lepxV)F==X3Z|BgE^igzD1p[Glqxiq%r!N&7'xy/<=Cak]N2WnM irsYLgS=L&^MVIC~b(/'/?+W(ol%lm?h\dYPC{:@_N=BpgCWg[Y;LH="M=+B.:T:!H4k*V~^=D&/`T YBL!X{&)0K&ILIcSK93Lw&)0%/i u'T$E/k{Y;`_/Rak&_:bAEjb%*=yvO:x~Wz(qav}X"}!\lwN My point was both that 2.2 sucked _and_ that the code didn't even do what was intended. Under the given 2.2 moveto permissions as actually implemented in the code, it was possible to be allowed to move an object from A to B, and then have the object stuck in B, with no ability to move it _anywhere_ else. From tinymuck-sloggers-owner Wed Aug 5 14:57:27 1992 Received: by piggy.ucsb.edu id AA07451 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 5 Aug 1992 15:58:44 -0700 Received: from snow.white.toronto.edu by piggy.ucsb.edu with SMTP id AA07447 (5.65c/IDA-1.4.4 for ); Wed, 5 Aug 1992 15:58:41 -0700 Received: from localhost (stdin) by snow.white.toronto.edu with SMTP id 28752; Wed, 5 Aug 92 18:57:42 EDT To: tinymuck-sloggers@piggy.ucsb.edu Subject: Re: moveto Date: Wed, 5 Aug 92 18:57:27 EDT From: Chris Siebenmann Message-Id: <92Aug5.185742edt.28752@snow.white.toronto.edu> My take on a set of rules for moveto, since I couldn't decipher David Moore's: moveto succeeds if and only if the euid controls either the source or the source's location and either: the destination is 'home' or the destination is a room and is jump-ok or link-ok or abode or is controlled by euid or the destination is a player and is abode or controlled by euid, and the source is not a player or a room (no mucking the db consistency up) A program running wizbitted always controls everything its wizard would. Clearly players always control themselves. Note that I have deleted the 'if source is a player then the location must be jump-ok' restriction, because actions don't have this requirement. Add it back in if actions acquire this restriction again. Comments? - cks From tinymuck-sloggers-owner Fri Aug 14 05:23:07 1992 Received: by piggy.ucsb.edu id AA07917 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 14 Aug 1992 12:23:12 -0700 Received: from nike.calpoly.edu (morpheus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA07913 (5.65c/IDA-1.4.4 for ); Fri, 14 Aug 1992 12:23:09 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA834527; Fri, 14 Aug 92 12:23:07 -0700 Date: Fri, 14 Aug 92 12:23:07 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9208141923.AA834527@nike.calpoly.edu> To: daemonmuck@nike.calpoly.edu, tinymuck-sloggers@piggy.ucsb.edu Subject: Squeeze me Baby! : Compression algorithms... A long while back some people were discussing various compression algorithms, and the merits of the one in the vanilla dist. of TinyMuck 2.2 I found an algorithm for Huffman coding in a discrete mathematics text I had lying around, and spent a couple of days worth of work implementing it. I had what I thought was a pretty decent compression ratio, but then got curious as to how good the vanilla one really was, so I compressed 1100 strings (gathered from descriptions on NewDay) and compared total length compressed with total length uncompressed: 39079 : 65632 <--- compression ratio: optimal Huffman coding 38229 : 65632 <--- compression ratio: 'vanilla' compression Turns out the Vanilla algorithm actually does a decent enough job of compressing straight generic english text. (At least compared to the Huffman algorithm I found). The difference is so small here that I'm almost embarrased that I spent that much time on the damn thing. Unless someone digs up a nicer algorithm, I don't see any reason to replace the Vanilla one. --Doran/Eos From tinymuck-sloggers-owner Fri Aug 14 05:28:51 1992 Received: by piggy.ucsb.edu id AA07998 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 14 Aug 1992 12:28:57 -0700 Received: from nike.calpoly.edu (zeus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA07994 (5.65c/IDA-1.4.4 for ); Fri, 14 Aug 1992 12:28:55 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA132853; Fri, 14 Aug 92 12:28:52 -0700 From: root@nike.calpoly.edu (The Super-user) Message-Id: <9208141928.AA132853@nike.calpoly.edu> Subject: Re: Squeeze me Baby! : Compression algorithms... To: awozniak@nike.calpoly.edu (The WOZ) Date: Fri, 14 Aug 92 12:28:51 PDT Cc: daemonmuck@nike.calpoly.edu, tinymuck-sloggers@piggy.ucsb.edu In-Reply-To: <9208141923.AA834527@nike.calpoly.edu>; from "The WOZ" at Aug 14, 92 12:23 pm X-Mailer: ELM [version 2.3 PL11] > A long while back some people were discussing various compression > algorithms, and the merits of the one in the vanilla dist. of > TinyMuck 2.2 Um, was this vanilla straight out of the box or had you changed the code tuples [or whatever you call it...]? I seemed to remember we as part of a later version of DaemonMUCK came up with tuples that were a bit more optomized based on an empirical study of the database. From tinymuck-sloggers-owner Fri Aug 14 05:41:27 1992 Received: by piggy.ucsb.edu id AA08078 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 14 Aug 1992 12:41:32 -0700 Received: from nike.calpoly.edu (morpheus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA08074 (5.65c/IDA-1.4.4 for ); Fri, 14 Aug 1992 12:41:29 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA834758; Fri, 14 Aug 92 12:41:27 -0700 Date: Fri, 14 Aug 92 12:41:27 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9208141941.AA834758@nike.calpoly.edu> To: daemonmuck@nike.calpoly.edu, tinymuck-sloggers@piggy.ucsb.edu Subject: Re: Squeeze me Baby! : Compression algorithms... The bigrams in DaemonMuck distribution are unchanged from original TinyMUCK 2.2 distribution. Frequency distribution data for construction of the optimal Huffman tree was obtained directly from the test data used in the comparison. --Doran/Eos From tinymuck-sloggers-owner Fri Aug 14 10:08:19 1992 Received: by piggy.ucsb.edu id AA08784 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 14 Aug 1992 17:08:58 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA08780 (5.65c/IDA-1.4.4 for ); Fri, 14 Aug 1992 17:08:55 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA10857 sendmail 5.67/UCSD-2.2-sun via SMTP Fri, 14 Aug 92 17:08:55 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA02809 for tinymuck-sloggers@piggy.ucsb.edu; Fri, 14 Aug 92 17:08:19 pdt Date: Fri, 14 Aug 92 17:08:19 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9208150008.AA02809@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Compression Reply-To: dmoore@ucsd.edu I looked over the bigrams before, and they seemed pretty decent. I did think it might be possible to get a slightly better rate by doing whole words rather than bigrams. But it wasn't much of a win, if I recall correctly. I assume you choose to encode characters for your ''optimal'' huffman compression? Huffman is optimal, but only if you choose the right symbolic components yourself. That is, Huffman found the best possible encoding of the strings limiting itself to only looking at single characters (I am assuming this is the version you coded). So, yes, bigraphs beat huffman, but it wasn't a fair fight. :-) You might consider a quick change to your algorithm to encode words using huffman. Well, actually you'd probably only want to encode a fixed dictionary of words w/ huffman, and leave all letters also in there individually. When you are parsing the string to decide what lexeme to return next, check if the next word (up to a following space or eol [1]) is in your dictionary of words, if so return it for encoding, otherwise just return the next character. You'll probably find this does a better job than bigraphs. Of course it might not be worth all the bother. Speed of compression/decompression is another thing you might want to think about. David 1. I said spaces. You could stop at punctuation, but last time I checked my cache of db's I decided it didn't matter enough. From chupchup Fri Aug 14 15:04:36 1992 Received: by piggy.ucsb.edu id AA10209 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 14 Aug 1992 21:04:39 -0700 Received: from localhost by piggy.ucsb.edu with SMTP id AA10205 (5.65c/IDA-1.4.4 for ); Fri, 14 Aug 1992 21:04:37 -0700 Message-Id: <199208150404.AA10205@piggy.ucsb.edu> To: tinymuck-sloggers@piggy.ucsb.edu Subject: looking for addresses. Reply-To: rearl Date: Fri, 14 Aug 92 21:04:36 MDT From: Robert Earl I'm looking for valid email paths for the following people: Sean Barrett (buzzard@eng.umd.edu bounces) Blackwinter (dolmen!anaconda!jph@iuvax.cs.indiana.edu bounces) Johnson Earls/Sthiss (jearls@polyslo.calpoly.edu is unknown user) Roy Riggs/fur (mdbs!rcr@eddie.mit.edu gets an unknown UUCP host) thanks for your time and trouble. From tinymuck-sloggers-owner Wed Aug 26 12:37:26 1992 Received: by piggy.ucsb.edu id AA18130 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 26 Aug 1992 13:39:00 -0700 Received: from blaze.cs.jhu.edu by piggy.ucsb.edu with SMTP id AA18126 (5.65c/IDA-1.4.4 for ); Wed, 26 Aug 1992 13:38:55 -0700 Message-Id: <199208262038.AA18126@piggy.ucsb.edu> Received: from mail-client (jyusenkyou.cs.jhu.edu) by blaze.cs.jhu.edu; Wed, 26 Aug 92 16:38:59 EDT Date: Wed, 26 Aug 92 16:37:26 EDT From: arromdee@blaze.cs.jhu.edu Sender: arromdee@blaze.cs.jhu.edu To: tinymuck-sloggers@piggy.ucsb.edu Subject: Invalid arguments X-Face: %+?l4Tsy_f|BAjdQt'l{lepxV)F==X3Z|BgE^igzD1p[Glqxiq%r!N&7'xy/<=Cak]N2WnM irsYLgS=L&^MVIC~b(/'/?+W(ol%lm?h\dYPC{:@_N=BpgCWg[Y;LH="M=+B.:T:!H4k*V~^=D&/`T YBL!X{&)0K&ILIcSK93Lw&)0%/i u'T$E/k{Y;`_/Rak&_:bAEjb%*=yvO:x~Wz(qav}X"}!\lwN Idea: #-1 name should return "*NOTHING*" and not crash. #-2 and #-3 should return "*AMBIGUOUS*" and "*HOME*". #-1 "string" flag? should return 0, as well as #-1 player?, #-1 exit?, etc. (Exception: one could argue #-3 room? should return 1.) #garbage name should return "", and return 0 for player?, flag?, etc. owner used on bad objects should return #-1, etc. Good or bad idea, and why? (This came up in the context of a rejected suggestion for TinyMUCK 2.3....) From tinymuck-sloggers-owner Wed Aug 26 08:11:22 1992 Received: by piggy.ucsb.edu id AA18526 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 26 Aug 1992 15:12:52 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA18521 (5.65c/IDA-1.4.4 for ); Wed, 26 Aug 1992 15:12:47 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA15840 sendmail 5.67/UCSD-2.2-sun via SMTP Wed, 26 Aug 92 15:12:45 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA10323 for tinymuck-sloggers@piggy.ucsb.edu; Wed, 26 Aug 92 15:11:22 pdt Date: Wed, 26 Aug 92 15:11:22 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9208262211.AA10323@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Invalid Arguments Reply-To: dmoore@ucsd.edu I think 'name' might make sense on garbage and #-1..#-3. For the type checking primitives like player?, room?, etc, they should probably return false for garbage, and DIE DIE DIE on #-1..#-3. Tho it might be acceptable for those to also just return false. I see absolutely no reason why you'd want #-1..#-3 to work w/ any other db primitives like flag? or owner, or location. Keeping the primitives at their limited state (w/ the exception of fixing the object type predicates to work w/ garbage) makes it easier to read other people's code, and debug your own. Checking flags on a non-existant object makes absolutely no sense to me. And it's not entirely clear to me that '0' is always the right answer in that case. **** What, I'd like to know is what current existing servers have made some of these changes. Like on fuzzball, daemon, valdez, shadows, etc, can you say '#-3 name' and get "*HOME*"? Can you say '#-1 "sticky" flag?' and get some result? And if you can is it intentional? :) As a side issue I'll listen to arguements why people think it would make their life easier to be able to check flags, or any other feature on totally nonexistant things, but I'd rather hear about existing server practice. **** I'd personally say that making player?, exit?, etc smart about garbage makes sense (I'm not so sure I agree on making them work for #-1, #-2, #-3). On many servers you are allowed to home objects to players, that makes '#-3 room?' returning 1 incorrect. It might make sense for 'name' to also work w/ garbage and #-1..#-3. I don't see that flag? or any other db primitive should particularly. What does '#xxx getlink "J" flag?' return? You'd expect it to tell you whether the room behind his exit is jump_ok or whatever. However, this totally fails if the exit is linked to home. In short, I like player?, room? working for garbage. And name working on garbage and #-1..#-3 makes sense. You should treat NOTHING in muf like NULL in C. Don't be doing any db operations on it. From tinymuck-sloggers-owner Wed Aug 26 08:24:10 1992 Received: by piggy.ucsb.edu id AA18652 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 26 Aug 1992 15:24:15 -0700 Received: from nike.calpoly.edu (zeus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA18648 (5.65c/IDA-1.4.4 for ); Wed, 26 Aug 1992 15:24:10 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA199650; Wed, 26 Aug 92 15:24:11 -0700 From: claudius@nike.calpoly.edu (King_Claudius (Chris Knight)) Message-Id: <9208262224.AA199650@nike.calpoly.edu> Subject: Re: Invalid arguments To: arromdee@blaze.cs.jhu.edu Date: Wed, 26 Aug 92 15:24:10 PDT Cc: tinymuck-sloggers@piggy.ucsb.edu In-Reply-To: <199208262038.AA18126@piggy.ucsb.edu>; from "arromdee@blaze.cs.jhu.edu" at Aug 26, 92 4:37 pm X-Mailer: ELM [version 2.3 PL11] arromdee@blaze.cs.jhu.edu says: > >#-1 name should return "*NOTHING*" and not crash. #-2 and #-3 should return >"*AMBIGUOUS*" and "*HOME*". sounds good to me... >#-1 "string" flag? should return 0, as well as #-1 player?, #-1 exit?, etc. >(Exception: one could argue #-3 room? should return 1.) #-3 should return the flags on the player's [owner's for STICKY] home. #-2 "string" flag? should return 0 also. >#garbage name should return "", and return 0 for player?, flag?, etc. Fine by me. It'd be nice to have #213 garbage?...akin to ok?... >owner used on bad objects should return #-1, etc. yeah. Why is it a good idea? Because errors in MUF suck. ;^) Also having to check every time you want to do this operation or that to see if the object is ok? or not is getting awfully redundant. Of course it makes us c-coder's lives easier but heck. -- ---King Claudius--- claudius@zeus.calpoly.edu From tinymuck-sloggers-owner Wed Oct 7 07:43:59 1992 Received: by ferkel.ucsb.edu id AA25695 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 7 Oct 1992 10:43:07 -0700 Received: from sun1.coe.ttu.edu by ferkel.ucsb.edu with SMTP id AA25691 (5.65c/IDA-1.4.4 for ); Wed, 7 Oct 1992 10:43:04 -0700 Received: by sun1.coe.ttu.edu (4.1/SMI-4.1) id AA23898; Wed, 7 Oct 92 12:44:30 CDT Date: Wed, 7 Oct 1992 12:43:59 -0500 (CDT) From: Subject: To: tinymuck-sloggers@ferkel.ucsb.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SUB Tinymuck Joey Lamb From tinymuck-sloggers-owner Thu Oct 8 01:19:50 1992 Received: by piggy.ucsb.edu id AA21153 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 8 Oct 1992 02:20:02 -0700 Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by piggy.ucsb.edu with SMTP id AA21149 (5.65c/IDA-1.4.4 for ); Thu, 8 Oct 1992 02:19:57 -0700 Received: from NEWKIRK.MIT.EDU by Athena.MIT.EDU with SMTP id AA21000; Thu, 8 Oct 92 05:19:57 EDT From: fihsu@Athena.MIT.EDU Received: by newkirk (5.57/4.7) id AA13792; Thu, 8 Oct 92 05:19:54 -0400 Message-Id: <9210080919.AA13792@newkirk> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Diskbasing TinyMUCK Date: Thu, 08 Oct 92 05:19:50 EDT Hi, I have heard that there have been several attempts (or at least a healthy pondering) to diskbase TinyMUCK. I would like to know what problems I might run into with this possible scheme: (assume that we have this "load object into memory on demand" pseudo-diskbasing). Have a separate file for every object. A random object needs to be fetched. First, check if it is already in memory. If not, read the file associated with the object and store in memory. If any data associated with the object is changed in the future (ie. desc change, change of location, etc) then mark it as modified. At @dump time, go through all objects in memory, saving each modified object to its disk file. (So you won't have to save every damn object during dumps!) I realize that a separate file for every object will result in the database requiring much more disk space than the current scheme. Would 2-3 times be a good estimate? (assume separate file for each object, and have objects stored in subdirectories, each of which contain 300 or so objects). Also, I assume there are diskbasing schemes for other types of M**s which are much more effecient with disk space usage? However, I really want each object to have its own file for preserving simplicity and making building offline relatively easy. So.. is this feasible? Thanks, Francis From tinymuck-sloggers-owner Thu Oct 8 01:29:03 1992 Received: by piggy.ucsb.edu id AA21174 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 8 Oct 1992 02:29:25 -0700 Received: from ferut.sys.toronto.edu by piggy.ucsb.edu with SMTP id AA21170 (5.65c/IDA-1.4.4 for ); Thu, 8 Oct 1992 02:29:21 -0700 Received: from localhost by ferut.sys.toronto.edu with SMTP id <20492>; Thu, 8 Oct 1992 05:29:10 -0400 To: tinymuck-sloggers@piggy.ucsb.edu Subject: Re: Diskbasing TinyMUCK In-Reply-To: fihsu's message of Thu, 08 Oct 92 05:19:50 -0400. <9210080919.AA13792@newkirk> Date: Thu, 8 Oct 1992 05:29:03 -0400 From: Chris Siebenmann Message-Id: <92Oct8.052910edt.20492@ferut.sys.toronto.edu> One file an object requires a *huge* number of inodes on a filesystem. Very few filesystems can absorb that sort of punishment. Don't for that you are also using a minimum size per file, typically 1k on BSD systems; this will also bloat your db storage requirements. One object per file was tried by UnterMUD; the general conclusion people arrived at was that it was a fine initial idea, but it didn't scale very well. I don't think any existing UnterMUD uses it; all use dbm indexes into a file of storage space, allocated in blocks. - cks warning: author is more sleepy than appears in text From tinymuck-sloggers-owner Thu Oct 8 07:52:33 1992 Received: by piggy.ucsb.edu id AA23731 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 8 Oct 1992 16:10:40 -0700 Received: from nike.calpoly.edu (morpheus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA23727 (5.65c/IDA-1.4.4 for ); Thu, 8 Oct 1992 16:10:37 -0700 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA886447; Thu, 8 Oct 92 14:52:33 -0700 Date: Thu, 8 Oct 92 14:52:33 -0700 From: awozniak@nike.calpoly.edu (The WOZ) Message-Id: <9210082152.AA886447@nike.calpoly.edu> To: cks@sys.toronto.edu, tinymuck-sloggers@piggy.ucsb.edu Subject: Re: Diskbasing TinyMUCK > From: fihsu@Athena.MIT.EDU > Subject: Diskbasing TinyMUCK > Date: Thu, 08 Oct 92 05:19:50 EDT > > Hi, I have heard that there have been several attempts (or at least > a healthy pondering) to diskbase TinyMUCK. I would like to know what > problems I might run into with this possible scheme: (assume that > we have this "load object into memory on demand" pseudo-diskbasing). > > Have a separate file for every object. A random object needs to be fetched. Ouch! (see below) If you're going to use this approach, you may want to consider stuffing an arbitrary number of objects into a single file (say, I dunno, 256 objects per file). This would take a minimal amount of time to read in (256 objects go fast) and would only require about 100 files for a moderate sized (25,600 objects) database. You'd then have two choices: either read all 256 objects when you need to get into the file (still better than loading 25,600 at once) OR do a linear search (yuch, see below) for the one object you need... > First, check if it is already in memory. If not, read the file associated > with the object and store in memory. If any data associated with the object > is changed in the future (ie. desc change, change of location, etc) then > mark it as modified. At @dump time, go through all objects in memory, saving > each modified object to its disk file. (So you won't have to save every > damn object during dumps!) > > I realize that a separate file for every object will result in the database > requiring much more disk space than the current scheme. Would 2-3 times be a > good estimate? (assume separate file for each object, and have objects Disk space is not exactly the problem. Unix only sets aside so much space to keep track of where it's hiding files (inodes). You'd eat those up to fast. (Excuse me if this is simplistic; I'm an idiot :) > stored in subdirectories, each of which contain 300 or so objects). Also, > I assume there are diskbasing schemes for other types of M**s which are > much more effecient with disk space usage? However, I really want each > object to have its own file for preserving simplicity and making building > offline relatively easy. So.. is this feasible? > > Thanks, > Francis > > From: Chris Siebenmann > > One file an object requires a *huge* number of inodes on a filesystem. > Very few filesystems can absorb that sort of punishment. Don't for that > you are also using a minimum size per file, typically 1k on BSD systems; > this will also bloat your db storage requirements. > > One object per file was tried by UnterMUD; the general conclusion people > arrived at was that it was a fine initial idea, but it didn't scale very > well. I don't think any existing UnterMUD uses it; all use dbm indexes > into a file of storage space, allocated in blocks. > > > - cks > warning: author is more sleepy than appears in text > The other idea I've been toying with (not implemented, just contemplating) is keeping an index file (see the help.c in DaemonMuck) to keep track of where the objects are in the database file. Then when you need to read something off disk you just lseek() into the file and read it in... Of course here you're going to chow time and disk access reading in all the old data so you can write a new database when you need to dump. The next idea would be to keep two files, one for integer fields (loc, owner, etc...) and one for string fields (along with appropriate index files.) The int file would have a standard format, so you could easily write straight to disk when you wanted to dump an object. Updateing string fields would take a little more work, but could be done by allocating blocks of space inside the strings file... Gosh that sounds like a lot of work. The last idea would be to go out and steal, err... borrow an existing database package, or hack some unter... uhh other mud's database layer... --Adam/Doran/Eos From tinymuck-sloggers-owner Fri Oct 9 10:33:54 1992 Received: by piggy.ucsb.edu id AA27134 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 9 Oct 1992 11:31:56 -0700 Received: from host4.colby.edu by piggy.ucsb.edu with SMTP id AA27130 (5.65c/IDA-1.4.4 for ); Fri, 9 Oct 1992 11:31:52 -0700 Received: by host4.COLBY.EDU (5.57/Colby 1.1) id AA13231; Fri, 9 Oct 92 14:35:38 -0400 Received: by host0.COLBY.EDU (5.57/Colby 1.0) id AA09512; Fri, 9 Oct 92 14:33:54 -0400 Date: Fri, 9 Oct 92 14:33:54 -0400 From: kthatch@COLBY.EDU (Karney T. Hatch '95) Message-Id: <9210091833.AA09512@host0.COLBY.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Get me off. Please take me off of this mailing list, thank you. From tinymuck-sloggers-owner Fri Oct 9 04:36:41 1992 Received: by piggy.ucsb.edu id AA27154 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 9 Oct 1992 11:36:58 -0700 Received: from ucsd.edu by piggy.ucsb.edu with SMTP id AA27150 (5.65c/IDA-1.4.4 for ); Fri, 9 Oct 1992 11:36:56 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA16229 sendmail 5.67/UCSD-2.2-sun via SMTP Fri, 9 Oct 92 11:36:55 -0700 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA00383 for tinymuck-sloggers@piggy.ucsb.edu; Fri, 9 Oct 92 11:36:41 pdt Date: Fri, 9 Oct 92 11:36:41 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9210091836.AA00383@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Administrivia Reply-To: David Moore To get on or off of mailing lists, it's considered annoying to mail to the entire list. Hence mailing lists have a special address that you use for such requests. It's generally the list name followed by '-request'. So to ask to be removed from tinymuck-sloggers you'd mail to 'tinymuck-sloggers-request@piggy.ucsb.edu'. -- David Moore - SysAdmin/Programmer UCSD | Dept. of Anesthesiology | V-151 | La Jolla, CA 92093-9151 Work Phone: (619) 552-8585 x7042 "God does not play dice." - A. Einstein "Yes, I do." - D. Moore From tinymuck-sloggers-owner Wed Oct 28 18:38:38 1992 Received: by ferkel.ucsb.edu id AA12584 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 28 Oct 1992 12:33:52 -0800 Received: from sun2.nsfnet-relay.ac.uk by ferkel.ucsb.edu with SMTP id AA12566 (5.65c/IDA-1.4.4 for ); Wed, 28 Oct 1992 12:32:40 -0800 Via: uk.ac.hertfordshire; Wed, 28 Oct 1992 18:46:46 +0000 Received: from unix1.herts.ac.uk (unix1.ARPA) by infsc1.herts.ac.uk; Wed, 28 Oct 92 17:39:04 -0100 From: The Dragon Date: Wed, 28 Oct 92 17:38:38 +0100 Message-Id: <29665.9210281638@unix1.herts.ac.uk> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: Tiny fugue! OK! Call me behind-the-times, I don't care! Can anybody point me in the right direction for tinyfugue? I'm one of these persons wot still uses tinytalk!! Arigato! David Cotterill. ) ( 18 Hillcrest, /|\ /|\ ドゥラゴン Hatfield, Herts. / | ¥ ¥_|_/ / | ¥ コテリッ * AL10 8HW / | ¥ (/¥|/¥) / | ¥ * |`.__________________________o___¥`|'/___o__________________________.'| | _ __ '^` ¥|/ '^` | | ' ) ) V "Where does reality end and | | / / _ _ _ _ __ fantasy begin? Personally | | /__/ / (_>(_)(_)/ /. I reckon that fantasy begins | | /| An endangered ,_. when my alarm clock goes off | | |/' species /,-.¥ in the morning...." | | .____________________________//___¥¥______________________________. | |' (( ¥¥_// cs4bl@herts.ac.uk `| * David 'Dragon' Cotterill ¥¥ `-' 100014,3230@compuserve.com * v From tinymuck-sloggers-owner Tue Nov 3 06:03:18 1992 Received: by piggy.ucsb.edu id AA05461 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 3 Nov 1992 14:03:28 -0800 Received: from nike.calpoly.edu (morpheus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA05457 (5.65c/IDA-1.4.4 for ); Tue, 3 Nov 1992 14:03:26 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA807447; Tue, 3 Nov 92 14:03:18 -0800 Date: Tue, 3 Nov 92 14:03:18 -0800 From: awozniak@nike.calpoly.edu (Adam "Hey Sister, can you spare a hug?" Wozniak) Message-Id: <9211032203.AA807447@nike.calpoly.edu> To: tinymuck-sloggers@piggy.ucsb.edu Subject: TinyMuck 2.3: When? Subject line says it all... From tinymuck-sloggers-owner Tue Nov 3 14:31:06 1992 Received: by piggy.ucsb.edu id AA06711 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 3 Nov 1992 22:34:07 -0800 Received: from netcom2.netcom.com by piggy.ucsb.edu with SMTP id AA06707 (5.65c/IDA-1.4.4 for ); Tue, 3 Nov 1992 22:34:04 -0800 Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) id AA11869; Tue, 3 Nov 92 22:31:07 -0800 From: jrg@netcom.com (Parade) Message-Id: <9211040631.AA11869@netcom2.netcom.com> Subject: Re: TinyMuck 2.3: When? To: awozniak@nike.calpoly.edu (Adam "Hey Sister, can you spare a hug?" Wozniak) Date: Tue, 3 Nov 92 22:31:06 PST Cc: tinymuck-sloggers@piggy.ucsb.edu In-Reply-To: <9211032203.AA807447@nike.calpoly.edu>; from "Adam "Hey Sister, can you spare a hug?" Wozniak" at Nov 3, 92 2:03 pm X-Mailer: ELM [version 2.3 PL11] > > > Subject line says it all... I think I speak on behalf of the TinyMUCK 2.3 developer(s) by saying 'Real Soon Now'. -- jrg@netcom.com russ granger Founder of the People's Popular Front for Revolutionary Darwinism Parade says, "Evolution NOW!" From tinymuck-sloggers-owner Wed Nov 4 02:51:23 1992 Received: by piggy.ucsb.edu id AA08141 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 4 Nov 1992 10:45:41 -0800 Received: from uwavm.u.washington.edu by piggy.ucsb.edu with SMTP id AA08137 (5.65c/IDA-1.4.4 for ); Wed, 4 Nov 1992 10:45:37 -0800 Received: from glia.biostr.washington.edu by UWAVM.U.WASHINGTON.EDU (IBM VM SMTP V2R1) with TCP; Wed, 04 Nov 92 10:45:14 PST From: codrus@glia.biostr.washington.edu (Ian McCloghrie) Posted-Date: Wed, 4 Nov 92 10:51:23 PST Message-Id: <9211041851.AA23192@glia.biostr.washington.edu> Received: by glia.biostr.washington.edu (911016.SGI/Eno-0.1) id AA23192; Wed, 4 Nov 92 10:51:28 -0800 Subject: Re: TinyMuck 2.3: When? To: tinymuck-sloggers@piggy.ucsb.edu Date: Wed, 4 Nov 92 10:51:23 PST In-Reply-To: <9211040631.AA11869@netcom2.netcom.com>; from "Parade" at Nov 3, 92 10:31 pm X-Mailer: ELM [version 2.3 PL11] > > Subject line says it all... > > I think I speak on behalf of the TinyMUCK 2.3 developer(s) > by saying 'Real Soon Now'. That's 'Real Soon Now (TM)'. tsk tsk :) -- /‾> Ian McCloghrie | Commander of Secret Police, Cal Animage Beta. < < /‾¥ |‾¥ |‾> | | <‾ | email: codrus@ucsd.edu <-> No Macek Nadia! ¥_> ¥_/ |_/ |‾¥ |__| _> | Card Carrying Member, UCSD Secret Islandia Club From tinymuck-sloggers-owner Wed Nov 4 19:51:18 1992 Received: by piggy.ucsb.edu id AA09936 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 4 Nov 1992 21:51:43 -0800 Received: from ferut.sys.toronto.edu by piggy.ucsb.edu with SMTP id AA09932 (5.65c/IDA-1.4.4 for ); Wed, 4 Nov 1992 21:51:40 -0800 Received: from localhost by ferut.sys.toronto.edu with SMTP id <38963>; Thu, 5 Nov 1992 00:51:27 -0500 To: tinymuck-sloggers@piggy.ucsb.edu Subject: Re: TinyMuck 2.3: When? In-Reply-To: jrg's message of Wed, 04 Nov 92 01:31:06 -0500. <9211040631.AA11869@netcom2.netcom.com> Date: Thu, 5 Nov 1992 00:51:18 -0500 From: Chris Siebenmann Message-Id: <92Nov5.005127est.38963@ferut.sys.toronto.edu> | I think I speak on behalf of the TinyMUCK 2.3 developer(s) |by saying 'Real Soon Now'. Who *are* the developers these days? I have a Saberized 2.3 of some vintage that I'm not sure patches got back into the mainline code. I'd like to reSaberize the current version, for that matter. - cks From tinymuck-sloggers-owner Wed Nov 4 14:06:10 1992 Received: by piggy.ucsb.edu id AA10002 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 4 Nov 1992 22:06:32 -0800 Received: from nike.calpoly.edu (morpheus.calpoly.edu) by piggy.ucsb.edu with SMTP id AA09998 (5.65c/IDA-1.4.4 for ); Wed, 4 Nov 1992 22:06:29 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA870683; Wed, 4 Nov 92 22:06:10 -0800 Date: Wed, 4 Nov 92 22:06:10 -0800 From: awozniak@nike.calpoly.edu (Adam "Hey Sister, can you spare a hug?" Wozniak) Message-Id: <9211050606.AA870683@nike.calpoly.edu> To: cks@sys.toronto.edu, tinymuck-sloggers@piggy.ucsb.edu Subject: Re: TinyMuck 2.3: When? > | I think I speak on behalf of the TinyMUCK 2.3 developer(s) > |by saying 'Real Soon Now'. > > Who *are* the developers these days? > I have a Saberized 2.3 of some vintage that I'm not sure patches > got back into the mainline code. I'd like to reSaberize the current > version, for that matter. > Ok, the last I heard was from David, who told me he had handed it to Ben and Chupchups for a final look over/whatever. From tinymuck-sloggers-owner Sun Jan 3 19:01:43 1993 Received: by ferkel.ucsb.edu id AA28177 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Sun, 3 Jan 1993 17:02:54 -0800 Received: from uiamvs.weeg.uiowa.edu by ferkel.ucsb.edu with SMTP id AA28173 (5.65c/IDA-1.4.4 for ); Sun, 3 Jan 1993 17:02:52 -0800 Received: by UIAMVS.WEEG.UIOWA.EDU (Soft-Switch Central V4L380P2); 03 Jan 1993 19:00:19 GMT Message-Id: Date: 03 Jan 93 19:01:43 GMT From: "RAD232" Subject: TINYMUCK-SLOGGERS To: tinymuck-sloggers@ferkel.ucsb.edu Comment: INFORMM NOTE RAD232 I send tinymuck-sloggers From tinymuck-sloggers-owner Thu Jan 21 10:18:25 1993 Received: by ferkel.ucsb.edu id AA09540 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 20 Jan 1993 00:19:14 -0800 Received: from kauri.vuw.ac.nz by ferkel.ucsb.edu with SMTP id AA09536 (5.65c/IDA-1.4.4 for ); Wed, 20 Jan 1993 00:19:08 -0800 Received: by kauri.vuw.ac.nz id AA26190 (5.65c/IDA-1.4.4 for tinymuck-sloggers@piggy.ucsb.edu); Wed, 20 Jan 1993 21:18:25 +1300 Date: Wed, 20 Jan 1993 21:18:25 +1300 From: Jamieson Norrish Message-Id: <199301200818.AA26190@kauri.vuw.ac.nz> To: tinymuck-sloggers@piggy.ucsb.edu Subject: MUCK combat and background programs I am about to embark on writing a skill system (including combat) for my MUCK, but unfortunately my knowledge of forth is fairly minimal. I have looked through what manuals I have, but they are lacking in the appropriate areas. My apologies if this is an obvious question. Therefore, I have two questions to ask. Firstly, how do I set up programs to run in the background? Secondly, does anyone have any ideas on how a combat system may be made to operate. I am intending a system whereby continuous time is kept, and each blow by a combatant is given a length of time for it to occur after the previous one. However, I still wish for the system to be fairly automated; that is, after initiating combat by "kill ", the program then continues to resolve attacks, until a combatant leaves the area or decides not to continue attacking. However, I do not want the program to interfere with the character's ability to do other things, such as say etc. Any ideas on how to do this? Or any suggestions as to a better system altogether? Jamie From tinymuck-sloggers-owner Thu Jan 21 12:55:24 1993 Received: by ferkel.ucsb.edu id AA23777 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 21 Jan 1993 20:54:17 -0800 Received: from tuba.calpoly.edu by ferkel.ucsb.edu with SMTP id AA23773 (5.65c/IDA-1.4.4 for ); Thu, 21 Jan 1993 20:54:15 -0800 Received: by tuba.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA25997; Thu, 21 Jan 1993 20:55:24 -0800 Date: Thu, 21 Jan 1993 20:55:24 -0800 From: awozniak@tuba.calpoly.edu Message-Id: <9301220455.AA25997@tuba.calpoly.edu> To: jamie@kauri.vuw.ac.nz, tinymuck-sloggers@piggy.ucsb.edu Subject: Re: MUCK combat and background programs under DaemonMuck, a program is automagically shoved into the background once it does a SLEEP. Therefore, to have a program run in the background... : main 1 SLEEP ( more stuff here ) ; --Adam/Doran/Eos From tinymuck-sloggers-owner Mon Jan 25 03:57:01 1993 Received: by ferkel.ucsb.edu id AA18726 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 25 Jan 1993 11:59:25 -0800 Received: from netcom.netcom.com by ferkel.ucsb.edu with SMTP id AA18722 (5.65c/IDA-1.4.4 for ); Mon, 25 Jan 1993 11:59:23 -0800 Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA00819; Mon, 25 Jan 93 11:57:02 -0800 From: foxen@netcom.com (Foxen) Message-Id: <9301251957.AA00819@netcom.netcom.com> Subject: Re: MUCK combat and background processes. To: tinymuck-sloggers@piggy.ucsb.edu Date: Mon, 25 Jan 93 11:57:01 PST X-Mailer: ELM [version 2.3 PL11] In FB MUCK, when you run a program from an action or an @message, you can background it with the BACKGROUND primitive. ie: : main ( s -- ? ) background (rest of function) ; Programs that are run from _arrive, _depart, _connect, _depart, or _listen propqueuers run background by default, as do AUTOSTART programs. - Foxen/Revar -- ___ __ ___ _ . _^^ ____ foxen@netcom.netcom.com ¥ / | | ¥ | | | -> '-" ¥______/___/ Yet Another Furry Fan (YAFF!) `v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the | |___ | ¥ | o //|| ||| Holy Fur of Ilura!" From tinymuck-sloggers-owner Wed Feb 3 04:55:24 1993 Received: by ferkel.ucsb.edu id AA21762 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 1 Feb 1993 18:56:26 -0800 Received: from kauri.vuw.ac.nz by ferkel.ucsb.edu with SMTP id AA21750 (5.65c/IDA-1.4.4 for ); Mon, 1 Feb 1993 18:56:17 -0800 Received: by kauri.vuw.ac.nz id AA07475 (5.65c/IDA-1.4.4 for tinymuck-sloggers@piggy.ucsb.edu); Tue, 2 Feb 1993 15:55:24 +1300 Date: Tue, 2 Feb 1993 15:55:24 +1300 From: Jamieson Norrish Message-Id: <199302020255.AA07475@kauri.vuw.ac.nz> To: tinymuck-sloggers@piggy.ucsb.edu Subject: Calling global words How do I call words which are defined outside of the current program? I know about call, but I do not wish to call another program, just one particular word. Basically I want the facility to define my own "system calls"; one solution might be to have a "system program" which takes a string argument and checks through its list of words for a match. This would have to be done (as far as I can see) as one series of if exit then if ... statements. Or is the only method to have one program per system call? Thanks. Jamie From tinymuck-sloggers-owner Mon Feb 1 18:16:08 1993 Received: by ferkel.ucsb.edu id AA22289 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 1 Feb 1993 20:17:16 -0800 Received: from ucbeh.san.uc.edu by ferkel.ucsb.edu with SMTP id AA22285 (5.65c/IDA-1.4.4 for ); Mon, 1 Feb 1993 20:17:13 -0800 Received: from ucunix.san.uc.edu by UCBEH.SAN.UC.EDU (PMDF #2697 ) id <01GU83TA6ALC8WWA0T@UCBEH.SAN.UC.EDU>; Mon, 1 Feb 1993 23:16:25 EST Received: by ucunix.san.uc.edu (5.65/Ultrix3.0-C) id AA15957; Mon, 1 Feb 93 23:16:08 -0500 Date: 01 Feb 1993 23:16:08 -0500 From: Crys Rides Subject: Calling global words In-Reply-To: <199302020255.AA07475@kauri.vuw.ac.nz> Sender: Crys Rides To: Jamieson Norrish Cc: tinymuck-sloggers@piggy.ucsb.edu Message-Id: <9302020416.AA15957@ucunix.san.uc.edu> X-Envelope-To: tinymuck-sloggers@piggy.ucsb.edu Content-Transfer-Encoding: 7BIT References: <199302020255.AA07475@kauri.vuw.ac.nz> -----BEGIN PGP SIGNED MESSAGE----- >How do I call words which are defined outside of the current program? >I know about call, but I do not wish to call another program, just one >particular word. Basically I want the facility to define my own >"system calls"; one solution might be to have a "system program" which >takes a string argument and checks through its list of words for a >match. This would have to be done (as far as I can see) as one series >of if exit then if ... statements. Or is the only method to >have one program per system call? The FB variant servers support this sort of operation through their 'library' code. Perhaps you'd like to take a look into them. The latest version is ftp'able from ftp.tcp.com, I think. > >Thanks. No Problem. > >Jamie CrysRides -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK23zkpSqD+bQ7So3AQG8uwP+Kt8hJ7aV+ojV7rSm59i1v95fRW9Di0LE x3gc7A0FcpCh7Lb4Ko70SM5/XaQ2Qe5B6pzTSJj9Xn84KeruDfztKRKAWDyshEE0 m3OseAkPGxoEKfE9ewvdMOrwBfP4Tg1eD6enrGiWgsm7/lG6qzNRv9kEHUn5Um98 t9BksQ2Hk5g= =2n3Y -----END PGP SIGNATURE----- From tinymuck-sloggers-owner Sun Mar 21 10:06:36 1993 Received: by ferkel.ucsb.edu id AA05190 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Sun, 21 Mar 1993 12:12:48 -0800 Received: from ihb.compuserve.com by ferkel.ucsb.edu with SMTP id AA05186 (5.65c/IDA-1.4.4 for ); Sun, 21 Mar 1993 12:12:39 -0800 Received: by ihb.compuserve.com (5.65/5.930129sam) id AA14842; Sun, 21 Mar 93 15:12:39 -0500 Date: 21 Mar 93 15:06:36 EST From: Will Cowman To: TinyMUCK Subject: subscribe Will Cowman Message-Id: subscribe Will Cowman From tinymuck-sloggers-owner Mon Mar 22 07:55:14 1993 Received: by ferkel.ucsb.edu id AA15171 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 22 Mar 1993 16:06:53 -0800 Received: from ucsd.edu by ferkel.ucsb.edu with SMTP id AA15167 (5.65c/IDA-1.4.4 for ); Mon, 22 Mar 1993 16:06:51 -0800 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA07866 sendmail 5.67/UCSD-2.2-sun via SMTP Mon, 22 Mar 93 16:06:52 -0800 for tinymuck-sloggers@piggy.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA01692 for tinymuck-sloggers@piggy.ucsb.edu; Mon, 22 Mar 93 15:55:14 pst Date: Mon, 22 Mar 93 15:55:14 pst From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9303222355.AA01692@sdnp1.UCSD.EDU> To: tinymuck-sloggers@piggy.ucsb.edu Subject: TinyMUCK 2.3 BETA released Reply-To: David Moore Tinymuck 2.3 beta is now available after much long awaited anticipation. The code is considered extremely stable and has not undergone any significant changes in approximately 6 months. Muds running 2.3 alpha had uptimes in months, often only going down for machine reboots. The 'betaness' of the release is due to three primary reasons: 1) the standard macro library is not present 2) there are no administration documentation 3) we can get some more feedback about installation on various systems. The server code is in good shape. The db converter only works for 2.2 dbs, and could probably be cleaned up. The sanity checker works well for detection, but can be cleaned up a lot for repairing. The sanity program has also become slightly outdated in some respects. Helpful hints to those who want to play with it now are to check the top level Makefile in src/, to edit src/include/config.h. You might want to look at src/include/params.h. If you get any compile complaints about 'difftime', 'errno', 'remove', 'size_t', 'time_t' then look in src/include/ansify.h. You might want to look in it anyways. If you get an error about conflicting header information for muck_strftime in buffer.c, just comment out the prototype for muck_strftime in buffer.c. You may wish to run 'make depend' before building. It's not necessary, however. If you plan to convert a 2.2 database to 2.3, you MUST run the sanity checker on the output of the convert program. Most 2.2 dbs I have seen have major inconsistencies in them. 2.3 wants clean dbs. There is a sample restart script in the minimal-db/ directory. You will very likely want to remove the 'return 0' located just after the line saying 'check_db () {'. Also, this version of the script is set to mail error messages to an account named 'tt'. You will want to change this. If you have questions about getting things running, and about specific features, mail to the list. Check the user documentation if it's a user level question. I'll try to write up reponses in a timely manner. I'm currently thinking that answering the questions will help to develop the documentation for the main release. Also, I am leaving town Wednesday (March 24th) through Sunday (March 28th). I mention this as I won't be reading any email during this period. But perhaps other people on the list can answer some questions while I'm gone. REMEMBER: This is a beta release. Not necessarily designed for public consumption. Mostly as it has no docs. I'd like to take this opportunity to thank the following people who greatly assisted in and influenced the 2.3 release: Ben Jackson, Ken Arromdee, Chris Siebenmann, Robert Earl, Cyndy Matuszek, the TimeTraveller wizards and players, and of course IBM for building the amazingly badly built RS/6000 computer and AIX operating system. Send all applauds for the 2.3 compiler to Ben, for the user documentation to Ken. I'd certainly take some applauds as well, but don't really expect them anymore. Send serious suggestions and reasonable complaints to me. The source code is available from: /@ferkel.ucsb.edu:pub/mud/TinyMUCK/tmuck2.3b.tar.z Yes, that's a lower case 'z'. You'll need gzip to retrieve the source. Of course, you're going to want gzip anyways, since ftps sites are switching to it like wildfire. David "OliverJones" Moore From tinymuck-sloggers-owner Mon Apr 1 09:53:46 1993 Received: by ferkel.ucsb.edu id AA13074 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 29 Mar 1993 18:07:37 -0800 Received: from ucsd.edu by ferkel.ucsb.edu with SMTP id AA13067 (5.65c/IDA-1.4.4 for ); Mon, 29 Mar 1993 18:07:33 -0800 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA09518 sendmail 5.67/UCSD-2.2-sun via SMTP Mon, 29 Mar 93 18:07:35 -0800 for tinymuck-sloggers@ferkel.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA05807 for tinymuck-sloggers@ferkel.ucsb.edu; Mon, 29 Mar 93 17:53:46 pst Date: Mon, 29 Mar 93 17:53:46 pst From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9303300153.AA05807@sdnp1.UCSD.EDU> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: 2.3b @open fix Reply-To: David Moore Wouldn't you know it. Right before sending it out, I made about 10 lines of code changes (big mistake, yeah, I know). And actually introduced a bug in my sleep-deprived mental state. Thanks to byte/tourist and Ben for noticing this. The slight change to src/builtins/open.c follows. I apologize profusely for editing code after testing and before release. Codrus (imccloghrie@ucsd.edu) has reworked the database converter to handle daemonmuck and shadow db formats. He might be interested in hearing from people with real dbs from those servers who would be willing to try the converter. He is not currently planning to work on fuzzball dbs as there seem to be db formats well into the double digits. There is currently no motivation to provide a fuzzball converter in the near future, so don't look for one unless someone decides to donate one. If someone w/ knowledge of those dump formats has interest, you should contact Ian. at the end of do_open() in open.c, MALLOC(temp, dbref, ndest); for (i = 0; i < ndest; i++, temp++) { *temp = dest[i]; } SetNDest(exit, ndest); SetDest(exit, temp); should be changed to.. SetNDest(exit, ndest); MALLOC(temp, dbref, ndest); SetDest(exit, temp); for (i = 0; i < ndest; i++, temp++) { *temp = dest[i]; } From tinymuck-sloggers-owner Wed Apr 3 01:32:57 1993 Received: by ferkel.ucsb.edu id AA19879 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 30 Mar 1993 14:35:47 -0800 Received: from sun2.nsfnet-relay.ac.uk by ferkel.ucsb.edu with SMTP id AA19865 (5.65c/IDA-1.4.4 for ); Tue, 30 Mar 1993 14:35:31 -0800 Via: uk.ac.hertfordshire.mercury; Tue, 30 Mar 1993 23:34:29 +0100 Received: from unix1.herts.ac.uk by hermes.herts.ac.uk with SMTP (PP) id <09385-0@hermes.herts.ac.uk>; Tue, 30 Mar 1993 22:33:33 +0000 From: The Dragon Date: Tue, 30 Mar 93 23:32:57 +0200 Message-Id: <3111.9303302132@unix1.herts.ac.uk> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: TinyFantasy!! The Hatfield Muck! Sender: D.R.Cotterill@hertfordshire.ac.uk OK! I grabbed 2.3 the moment I heard it was out, but then realised after that the db wasn't compatable with the previous 2.2.10.4 I had been using. The TinyFantasy system incorporates some pretty MAJOR changes. For start remove 'kill =' altogether and add real fighting/magic/ mobiles/monsters/character stats etc. The new muf proggies are up and stable, anybody who wants a copy of all the TinyFantasy mufs may e-mail me for the asking. And prepare for a uuencoded gzip'ed tar file!! You'll need to set up your system to run it, but that isn't too difficult! Now if I could just get the database converter...... Dragon. _ __ | cs4bl@herts.ac.uk | Condense soup not books! ' ) ) David Cotterill | Compu$erve : 100014,3230 | / / _ _ _ _ __ | Voice : +44 (707) 276251 | /__/ / (_>(_)(_)/ /. An | Fax/Data on request--^ | Editor: /| endangered | 18 Hillcrest, Hatfield, | Anime-hem |/ species | Herts. ENGLAND. AL10 8HW | From tinymuck-sloggers-owner Wed Apr 3 01:43:35 1993 Received: by ferkel.ucsb.edu id AA19969 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 30 Mar 1993 14:46:16 -0800 Received: from sun2.nsfnet-relay.ac.uk by ferkel.ucsb.edu with SMTP id AA19963 (5.65c/IDA-1.4.4 for ); Tue, 30 Mar 1993 14:46:08 -0800 Via: uk.ac.hertfordshire.mercury; Tue, 30 Mar 1993 23:45:06 +0100 Received: from unix1.herts.ac.uk by hermes.herts.ac.uk with SMTP (PP) id <09416-0@hermes.herts.ac.uk>; Tue, 30 Mar 1993 22:44:11 +0000 From: The Dragon Date: Tue, 30 Mar 93 23:43:35 +0200 Message-Id: <3193.9303302143@unix1.herts.ac.uk> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: TinyFantasy Part II Sender: D.R.Cotterill@hertfordshire.ac.uk Ummm. BTW: My current project is a version of TinyShadowRun and true to form, it'll include ALL possible cyberware, magic, this that and the other........ (How can you guess my final year Comp. Sci. project is on Multi-user games!) Dragon. _ __ | cs4bl@herts.ac.uk | Confucius, he say "never ' ) ) David Cotterill | Compu$erve : 100014,3230 | eat yellow snow". / / _ _ _ _ __ | Voice : +44 (707) 276251 | /__/ / (_>(_)(_)/ /. An | Fax/Data on request--^ | Editor: /| endangered | 18 Hillcrest, Hatfield, | Anime-hem |/ species | Herts. ENGLAND. AL10 8HW | From tinymuck-sloggers-owner Tue Apr 2 09:08:40 1993 Received: by ferkel.ucsb.edu id AA21365 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Tue, 30 Mar 1993 17:08:33 -0800 Received: from netcom3.netcom.com by ferkel.ucsb.edu with SMTP id AA21361 (5.65c/IDA-1.4.4 for ); Tue, 30 Mar 1993 17:08:29 -0800 Received: by netcom3.netcom.com (5.65/SMI-4.1/Netcom) id AA13910; Tue, 30 Mar 93 17:08:41 -0800 From: foxen@netcom.com (Foxen) Message-Id: <9303310108.AA13910@netcom3.netcom.com> Subject: Re: 2.3b @open fix To: tinymuck-sloggers@ferkel.ucsb.edu Date: Tue, 30 Mar 93 17:08:40 PST In-Reply-To: <9303300153.AA05807@sdnp1.UCSD.EDU>; from "David Moore" at Mar 29, 93 5:53 pm X-Mailer: ELM [version 2.3 PL11] David Moore wrote: > > Codrus (imccloghrie@ucsd.edu) has reworked the database >converter to handle daemonmuck and shadow db formats. He might be >interested in hearing from people with real dbs from those servers who >would be willing to try the converter. He is not currently planning to >work on fuzzball dbs as there seem to be db formats well into the double >digits. There is currently no motivation to provide a fuzzball >converter in the near future, so don't look for one unless someone >decides to donate one. If someone w/ knowledge of those dump formats >has interest, you should contact Ian. > Sheesh... I read in 2 other people's db formats, plus two of my own, plus one dbformat extention of my own, and somehow they get referred to as "db formats well into the double digits". =) For the record, FB reads in the following formats, beyond those that standard 2.2 read in: Mage Format (Furry's old format. No dbs use it now.) WhiteFire Format (Tapestries' old format. No dbs use it now.) Foxen Format. (for backwards compatability with old fb db's.) Foxen2 Format. (The current db format.) Foxen Deltadump Extention. (In current use for delta-dumps.) Amazingly enough, these are all read in by one routine. =) - Foxen PS: No, I'm not volunteering to write the db converter. The differences between FB and 2.3 are too extensive to make an FB db useful under 2.3. -- =/¥= ____ Illuminati... foxen@netcom.com /¥/¥/¥ It's not just for /¥/¥/¥/¥ breakfast anymore! From tinymuck-sloggers-owner Sat Apr 3 02:24:46 1993 Received: by ferkel.ucsb.edu id AA22620 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Sat, 3 Apr 1993 10:23:21 -0800 Received: from tuba.calpoly.edu by ferkel.ucsb.edu with SMTP id AA22616 (5.65c/IDA-1.4.4 for ); Sat, 3 Apr 1993 10:23:18 -0800 Received: by tuba.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA25965; Sat, 3 Apr 1993 10:24:46 -0800 Date: Sat, 3 Apr 1993 10:24:46 -0800 From: awozniak@tuba.calpoly.edu Message-Id: <9304031824.AA25965@tuba.calpoly.edu> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: Anyone running 2.3 ? Anyone running it who would be willing to let me in and bang on it? From tinymuck-sloggers-owner Fri Apr 9 14:35:50 1993 Received: by ferkel.ucsb.edu id AA00735 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 9 Apr 1993 21:29:40 -0700 Received: from garden.csc.calpoly.edu (melon.csc.calpoly.edu) by ferkel.ucsb.edu with SMTP id AA00729 (5.65c/IDA-1.4.4 for ); Fri, 9 Apr 1993 21:29:38 -0700 Message-Id: <199304100429.AA00729@ferkel.ucsb.edu> Received: by garden.csc.calpoly.edu (1.37.109.4/16.2) id AA17430; Fri, 9 Apr 93 21:35:50 -0700 Date: Fri, 9 Apr 93 21:35:50 -0700 From: Adam Wozniak To: tinymuck-sloggers@piggy.ucsb.edu Subject: @dig and @open patches Anyone have the 2.3b @dig and @open patches? Seems I misplaced them. From tinymuck-sloggers-owner Fri Apr 9 16:09:57 1993 Received: by ferkel.ucsb.edu id AA01235 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 9 Apr 1993 23:10:11 -0700 Received: from ucsd.edu by ferkel.ucsb.edu with SMTP id AA01231 (5.65c/IDA-1.4.4 for ); Fri, 9 Apr 1993 23:10:09 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AB21979 sendmail 5.67/UCSD-2.2-sun via SMTP Fri, 9 Apr 93 23:10:11 -0700 for tinymuck-sloggers@ferkel.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA02016 for tinymuck-sloggers@ferkel.ucsb.edu; Fri, 9 Apr 93 23:09:57 pdt Date: Fri, 9 Apr 93 23:09:57 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9304100609.AA02016@sdnp1.UCSD.EDU> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: TinyMUCK2.3beta patchlevel 1 Reply-To: David Moore I am releasing a new patchlevel to 2.3beta. You will want to upgrade, as it fixes the @open and @dig bugs as well as makefile changes and revision control comments. The CHANGES file appears below. You might want to peer at the TODO file and offer suggestions and such. As always, please include 'tmuck2.3' in the subject of email. There is a full tar distribution as well as a patch file. You can find them on ferkel.ucsb.edu in pub/mud/TinyMUCK, once they are moved from the incoming directory. (Right now they are in pub/mud/incoming). The tar file is called: tmuck2.3b1.tar.z and the patch is tmuck2.3b1.diff. 2.3 beta patchlevel 1: ---------------------- o Fixed @open and @dig bugs which were introduced 10 minutes before 2.3b release. o Fixed muf property security hole allowing players to replace other player's passwords with known strings. (Noticed by Adam Wozniak). o Changed Makefiles to notice when sub files were edited and to rebuild everything properly. o Added some items to Makefile and ansify.h for helping to port to some additional platforms. o Stuck more system specific signal ifdefs in interface/main.c. o Cleaned up the restart script provided. o Fixed up a few errant settings in config.h. o Added edit_quit_external and interp_quit_external to make it easier for servers to kick players out of the editor on disconnect. o Converter modified to work with daemonmuck and shadow dbs. (Modifications by Ian McCloghrie). o Added command line options to convert and sanity. (Added by Ian McCloghrie). o Added a sample lockout.sites to minimal-db/data. From tinymuck-sloggers-owner Mon Apr 12 03:44:59 1993 Received: by ferkel.ucsb.edu id AA15161 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 12 Apr 1993 04:45:01 -0700 Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by ferkel.ucsb.edu with SMTP id AA15157 (5.65c/IDA-1.4.4 for ); Mon, 12 Apr 1993 04:44:58 -0700 Received: from M11-116-3.MIT.EDU by Athena.MIT.EDU with SMTP id AA29442; Mon, 12 Apr 93 07:45:01 EDT From: fihsu@Athena.MIT.EDU Received: by m11-116-3 (5.57/4.7) id AA14370; Mon, 12 Apr 93 07:44:59 -0400 Message-Id: <9304121144.AA14370@m11-116-3> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: Converting DaemonMUCK, Shadows, MAGE, etc. to 2.3 Date: Mon, 12 Apr 93 07:44:59 EDT From what I can tell, it looks like the conversion for DaemonMUCK/Shadows to 2.3 is done directly without consideration of making the db 2.3-sane. In DaemonMUCK, things, exits (I think), and programs can have contents. And the contents can be basically any object type (except for exits I would hope...). Thus, the possibility of the sanity checker going crazy after conversion, as of now, would be pretty high. I think it would be putting too much burden on an ignorant admin to have him/her prepare the db beforehand. (The potential inconsistencies are more than just with regard to contents.. homes for objects may be something other than rooms also?) I did notice there was an attempt to handle converting Shadow Daemons into players... here's an excerpt: from 2.3, utilprogs/convert.c: /* * Note, this handling of daemons, currently, won't work right. The * problem lies in the sanity checker, which ends up introducing cycles * into the db when it tries to fix the inconsistancies caused by the * fact that the converter doesn't know enough about the db to fix things * in a sane way. The production sanity checker will do this right. * Until tile, if you've got daemons in your db, @recycle them all before * doing the conversion. They're useless in 2.3 anyway. */ if (dbtype == DB_SHADOWS) { getref(f); /* throw away owner */ SetOwner(objno, objno); /* 'player' so owns itself */ SetLoc(objno, 0); /* move it into #0 */ ...and so on. The method for converting Shadows Daemons will indeed fail as the comments say. It sets the location of the Daemon/Player to #0, yet does not adjust the Contents pointer of #0 and the Next pointer of the Daemon. The Daemons example wasn't a great one, because since there are so few it would indeed be easy just to recycle all of them beforehand. However, Daemons aren't going to be the only problem and the idea of moving problem objects to #0 is appealing. Looking at the db_move() function in db/db.c, the solution appears to be simple after all. if (Typeof(objno) != TYPE_EXIT) { loc = GetLoc(objno); if (Typeof(loc) != TYPE_ROOM && Typeof(loc) != TYPE_PLAYER) { SetLoc(objno, global_environment); PushContents(objno, global_environment); } /* if (Typeof(objno) == TYPE_PLAYER && Typeof(loc) == TYPE_PLAYER) { SetContents(loc, remove_first(GetContents(loc), objno)); SetLoc(objno, global_environment); PushContents(objno, global_environment); } */ } (The only problem with the above is it doesn't fix players inside players, but it keeps things simple to assume that a location is either absolutely good or absolutely bad. Uncommenting the commented part may work for the players in players exception I think...) This would have to be done after all objects have been read since the object might be read before the location (and we need to check if the location is valid). A similar thing could be done for invalid links/homes. if (Typeof(objno) != TYPE_EXIT && Typeof(GetLink(objno) != TYPE_ROOM))) SetLink(objno, player_start); Sorry, I didn't check to see if those would work since I don't have a Daemon/Shadow db handy. :) And the main procedure would be basically db_read db_fix <--- where the above would go db_write I hope what I proposed would work and greatly increase the 2.3-sanity of the db.. it might even help corrupt 2.2 dbs. ;) Feedback would be appreciated... Francis From tinymuck-sloggers-owner Mon Apr 12 06:57:36 1993 Received: by ferkel.ucsb.edu id AA16390 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 12 Apr 1993 06:57:38 -0700 Received: from uu4.psi.com by ferkel.ucsb.edu with SMTP id AA16386 (5.65c/IDA-1.4.4 for ); Mon, 12 Apr 1993 06:57:36 -0700 Received: from witch.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA27474 for ; Mon, 12 Apr 93 09:50:46 -0400 Received: by hunter.win.net; Sun, 11 Apr 1993 21:59:29 Mailer: WinNET Mail, v1.52B Message-Id: <117@hunter.win.net> Reply-To: gbandy@hunter.win.net (Gregory S. Bandy) To: tinymuck-sloggers@ferkel.ucsb.edu Date: Sun, 11 Apr 1993 21:59:28 Subject: Subscription Request From: gbandy@hunter.win.net (Gregory S. Bandy) Hi - Please add me to your mailing list. Thanks! ______________________________________________________________________ Greg Bandy |"He's so perky! Kill her!" |En Garde! Richmond, VA | --- Crow, "Mr. B Natural" |GURPS: USA |(Keep circulating the tapes) |Cliffhangers gbandy@hunter.win.net | |Swashbucklers CompuServe 71331,142 | |mst3k From tinymuck-sloggers-owner Tue Apr 13 01:27:41 1993 Received: by ferkel.ucsb.edu id AA19673 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 12 Apr 1993 14:29:43 -0700 Received: from alf.zfn.uni-bremen.de by ferkel.ucsb.edu with SMTP id AA19669 (5.65c/IDA-1.4.4 for ); Mon, 12 Apr 1993 14:29:39 -0700 Received: by alf.zfn.uni-bremen.de (AIX 3.2/UCB 5.64/4.03-k4) id AA19950; Mon, 12 Apr 1993 23:27:41 +0200 Date: Mon, 12 Apr 1993 23:27:41 +0200 From: c07g@alf.zfn.uni-bremen.de (Roland Kraesse) Message-Id: <9304122127.AA19950@alf.zfn.uni-bremen.de> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: Subscription Request I dunno if there's a special request mailing address, but I'd like to subscribe. :) From tinymuck-sloggers-owner Mon Apr 12 10:50:57 1993 Received: by ferkel.ucsb.edu id AA21456 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 12 Apr 1993 17:48:02 -0700 Received: from mailhost1.cac.washington.edu by ferkel.ucsb.edu with SMTP id AA21452 (5.65c/IDA-1.4.4 for ); Mon, 12 Apr 1993 17:47:59 -0700 Received: from glia.biostr.washington.edu by mailhost1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28942; Mon, 12 Apr 93 17:51:56 -0700 From: codrus@glia.biostr.washington.edu (Ian McCloghrie) Posted-Date: Mon, 12 Apr 93 17:50:57 PDT Message-Id: <9304130050.AA22115@glia.biostr.washington.edu> Received: by glia.biostr.washington.edu (911016.SGI/Eno-0.1) id AA22115; Mon, 12 Apr 93 17:50:58 -0700 Subject: Re: Converting DaemonMUCK, Shadows, MAGE, etc. to 2.3 To: fihsu@Athena.MIT.EDU Date: Mon, 12 Apr 93 17:50:57 PDT Cc: tinymuck-sloggers@piggy.ucsb.edu (TinyMUCK Sloggers List) In-Reply-To: <9304121144.AA14370@m11-116-3>; from "fihsu@Athena.MIT.EDU" at Apr 12, 93 7:44 am X-Mailer: ELM [version 2.3 PL11] > 2.3 is done directly without consideration of making the db 2.3-sane. In > DaemonMUCK, things, exits (I think), and programs can have contents. And > ... > Looking at the db_move() function in db/db.c, the solution appears to be > simple after all. I considered doing this while writing the converter, and decided against it. Simply maintaining a list of objects to be moved to #0 once the entire db is loaded will work, assuming that there aren't any other, more major problems with the db. The problems arise if you've got a db that's already got errors, cycles, etc. These need to be fixed before you can use any normal db operations on the database. Putting the code necessary to fix all of these possible errors into the converter is silly, and redundant, as it already exists (or will exist) in the sanity checker. IMHO, the best way of converting a database is to make a very naive conversion in the converter, and feed the resulting db to the sanity checker, which will then correct it. This avoids duplication of code, and keeps the elaborate sanity checking routines where they belong, in the sanity checker. The problem with daemons lies in the fact that the existing sanity checker is not capable of fixing the problems caused by converting daemons to players and changing their location to #0, it ends up introducing unresolvable cycles into the database. It does, however, manage to fix other problems, such as the BOX flag, where objects contain other objects, by moving all these objects into #0 (or rather, into player_start). The only known problem lies with daemons, and as DruidMUCK only had 9 daemons, and I don't know of any other Shadows format databases, there seemed to be little point in writing elaborate code to fix this problem, given the fact that a new sanity checker is expected soon. > A similar thing could be done for invalid links/homes. The sanity checker already fixes these. -- /‾> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta. < < /‾¥ |‾¥ |‾> | | <‾ | email: codrus@ucsd.edu <----> Net/2, USL 0! ¥_> ¥_/ |_/ |‾¥ |__| _> | Card Carrying Member, UCSD Secret Islandia Club From chupchup Wed Apr 14 18:52:38 1993 Received: by oinker.ucsb.edu id AA29033 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 15 Apr 1993 01:10:47 -0700 Received: from localhost by oinker.ucsb.edu with SMTP id AA28817 (5.65c/IDA-1.4.4 for ); Thu, 15 Apr 1993 00:52:39 -0700 Message-Id: <199304150752.AA28817@oinker.ucsb.edu> To: neph@oinker.ucsb.edu, concrete-blonde@oinker.ucsb.edu, fuzzy-ramblings@oinker.ucsb.edu, tinymuck-sloggers@oinker.ucsb.edu Subject: where to send the right things Reply-To: rearl@piggy.ucsb.edu Date: Thu, 15 Apr 93 00:52:38 MDT From: Robert Earl two messages were sent to me yesterday when it was quite clear that they were meant for general list consumption, prompting this Public Service Announcement to all the lists I run, about where to send things: NOTE: in the following paragraphs, can be one of "neph", "concrete-blonde", "fuzzy-ramblings", or "tinymuck-sloggers". "piggy" can also be "pi-chan", "ferkel", or "oinker". * if you need to subscribe, unsubscribe, or ask a question of me, the list administrator, send to listname-request@piggy.ucsb.edu. * if you wish to post a message to the entire list, please make sure it's not a uuencoded binary (we have an ftp site for those things, contact me if you have .au, .jpg, or .gif files...) and send it to listname@piggy.ucsb.edu. * never, NEVER, ever send anything to listname-owner@piggy.ucsb.edu; these addresses are solely for collecting bounces and I'll probably just delete them sight unseen. have a Nice Day. From tinymuck-sloggers-owner Mon Apr 26 22:22:23 1993 Received: by ferkel.ucsb.edu id AA17318 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 26 Apr 1993 12:37:11 -0700 Received: from sun2.nsfnet-relay.ac.uk by ferkel.ucsb.edu with SMTP id AA17314 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 12:37:01 -0700 Via: uk.ac.hertfordshire.helios; Mon, 26 Apr 1993 20:23:07 +0100 Received: from unix1.herts.ac.uk by helios.herts.ac.uk with SMTP (PP) id <24917-0@helios.herts.ac.uk>; Mon, 26 Apr 1993 20:22:27 +0000 From: The Dragon Date: Mon, 26 Apr 93 20:22:23 +0200 Message-Id: <6028.9304261822@unix1.herts.ac.uk> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: TinyFantasy!!! Sender: D.R.Cotterill@hertfordshire.ac.uk Due to a bug in the set-up here at Hatfield. Hatfield is now an OPEN ACCESS SITE!!! Connect now to TinyFantasy on 147.197.200.41 on port 8989!! Full fighting capability and magic!! Call now before the Administrators realise their error and close the site down again!!! Dragon. _ __ | cs4bl@herts.ac.uk | First Computer Axiom: ' ) ) David Cotterill | Compu$erve : 100014,3230 | When putting it into / / _ _ _ _ __ | Voice : +44 (707) 276251 | memory, remember where /__/ / (_>(_)(_)/ /. An | Fax/Data on request--^ | you put it. Editor: /| endangered | 18 Hillcrest, Hatfield, | Anime-hem |/ species | Herts. ENGLAND. AL10 8HW | From tinymuck-sloggers-owner Mon Apr 26 08:07:27 1993 Received: by ferkel.ucsb.edu id AA18639 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Mon, 26 Apr 1993 15:10:50 -0700 Received: from soda.Berkeley.EDU by ferkel.ucsb.edu with SMTP id AA18632 (5.65c/IDA-1.4.4 for ); Mon, 26 Apr 1993 15:10:47 -0700 Received: by soda.berkeley.edu (5.65/KAOS-1) id AA10897; Mon, 26 Apr 93 15:07:27 -0700 Date: Mon, 26 Apr 93 15:07:27 -0700 From: Jon Blow Message-Id: <9304262207.AA10897@soda.berkeley.edu> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: Re: TinyFantasy!!! > Due to a bug in the set-up here at Hatfield. Hatfield is now an OPEN ACCESS > SITE!!! Connect now to TinyFantasy on 147.197.200.41 on port 8989!! M-x insert-random-flame-concerning-blatant-idiocy From tinymuck-sloggers-errors Fri May 21 10:46:56 1993 Received: by ferkel.ucsb.edu id AA28378 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 21 May 1993 18:21:57 -0700 Received: from ucsd.edu by ferkel.ucsb.edu with SMTP id AA28374 (5.65c/IDA-1.4.4 for ); Fri, 21 May 1993 18:21:55 -0700 Received: from sdnp1.ucsd.edu by ucsd.edu; id AA22359 sendmail 5.67/UCSD-2.2-sun via SMTP Fri, 21 May 93 18:22:59 -0700 for tinymuck-sloggers@ferkel.ucsb.edu Received: by sdnp1.UCSD.EDU (1.2/UCSDGENERIC.2) id AA16680 for tinymuck-sloggers@ferkel.ucsb.edu; Fri, 21 May 93 17:46:56 pdt Date: Fri, 21 May 93 17:46:56 pdt From: dmoore@sdnp1.UCSD.EDU (David Moore) Message-Id: <9305220046.AA16680@sdnp1.UCSD.EDU> To: tinymuck-sloggers@ferkel.ucsb.edu Subject: tmuck2.3b2 available The latest patchlevel is now available. If you didn't get 2.3b1 fresh from a tar file, you will want to get 2.3b2 from the tar file. Otherwise, you can get the patch file or tar as you prefer. (Ie, the patch file last time didn't apply right, so if you used it, get a fresh version). ferkel.ucsb.edu:pub/mud/TinyMUCK/ -rw-r--r-- 1 jim 328394 May 17 15:48 tmuck2.3b2.tar.z -rw-r--r-- 1 jim 40380 May 18 03:58 tmuck2.3b_1to2.patch.z 2.3 beta patchlevel 2: ---------------------- o Added a README file which might help those who get ahold of the code not already knowing about it. o Changed lockout.c so that the dbref field can now contain *. This allows you to easily lockout everyone except for specific people (such as wizards). An example of this was added to minimal-db/data/lockout.sites. o Added '-s' option to sanity which enabled the security check option. Basically this will spit out what objects in your database have flags set which might be security problems. You might wish to save the output of this, and run it on your db every week and checkout new objects that appear in the list. o Changed @link so that objects can be homed to people in addition to rooms. o Updated the forth.ref and help.txt files in minimal-db/data to be the same as the newer ones in docs. o Added chown_macros command to compile/macro.c and changed builtins/toad.c to call this to chown all player macros upon toading. o Added code to compile/macro.c to detect bad macro owners when the display macros command is run. o Fixed bug in interp/primitives file related to the number of arguments returned by 'open' and 'depth' primitives. o Fixed it so that non-wizards can't set or clear BUILDER or MUCKER bits if RESTRICTED_BUILDING isn't defined or MUCKER_ALL is defined. o Added '+' (plussign) and '-' (minussign) cookies. Renamed 'amperstand' to 'ampersand' for '&' cookie. From tinymuck-sloggers-errors Fri May 28 10:53:27 1993 Received: by ferkel.ucsb.edu id AA29185 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 28 May 1993 11:53:54 -0700 Received: from CMS.CC.WAYNE.EDU by ferkel.ucsb.edu with SMTP id AA29181 (5.65c/IDA-1.4.4 for ); Fri, 28 May 1993 11:53:50 -0700 Message-Id: <199305281853.AA29181@ferkel.ucsb.edu> Received: from CMS.CC.WAYNE.EDU by CMS.CC.WAYNE.EDU (IBM VM SMTP V2R2) with BSMTP id 1059; Fri, 28 May 93 14:53:56 EDT Received: from WAYNEST1 (NJE origin MEDSYS@WAYNEST1) by CMS.CC.WAYNE.EDU (LMail V1.1d/1.7f) with BSMTP id 9374; Fri, 28 May 1993 14:53:55 -0400 Date: Fri, 28 May 93 14:53:27 EDT From: MEDSYS@CMS.CC.WAYNE.EDU To: tinymuck-sloggers@ferkel.ucsb.edu Please add MEDSYS@CMS.CC.WAYNE.EDU to the list. Thank you! From chupchup Fri May 28 15:09:00 1993 Received: by oinker.ucsb.edu id AA05155 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 28 May 1993 21:18:27 -0700 Received: from localhost by oinker.ucsb.edu with SMTP id AA05103 (5.65c/IDA-1.4.4 for ); Fri, 28 May 1993 21:09:01 -0700 Message-Id: <199305290409.AA05103@oinker.ucsb.edu> To: fuzzy-ramblings@oinker.ucsb.edu, concrete-blonde@oinker.ucsb.edu, neph@oinker.ucsb.edu, himmelfahrtstransport@oinker.ucsb.edu, tinymuck-sloggers@oinker.ucsb.edu Subject: New list software Reply-To: rearl@piggy.ucsb.edu Date: Fri, 28 May 93 21:09:00 MDT From: Robert Earl I have written a little Perl program to parse incoming request mail and deal with simple operations. This means that I will no longer be handling all list administration requests by hand; also that there may be some bugs in the program, so if you find that the list server has not handled your mail properly, let me know. The server understands these commands, which MUST BE IN THE SUBJECT LINE: subscribe [add yourself to the mailing list] subscribe [add yourself at another address] unsubscribe [remove yourself from the list] who, send list [send back a list of all subscribers] send archive [send back the list's mail archive file] send FAQ [send back an FAQ list] help [this listing of commands] Please remember, the body of the message is IGNORED (why? cos it made the programming simpler :) Thanks for your support; I hope that the new abilities to send files will be expanded soon to include discographies, lyrics, and bugfixes when these become available. From chupchup Wed Jun 2 12:43:20 1993 Received: by oinker.ucsb.edu id AA06443 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Wed, 2 Jun 1993 12:43:20 -0700 Date: Wed, 2 Jun 1993 12:43:20 -0700 Message-Id: <199306021943.AA06443@oinker.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: Robert Earl Subject: mailing list downtime Sender: tinymuck-sloggers-errors Errors-To: tinymuck-sloggers-errors X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.9 X-Unsub-Address: Sorry about the downtime experienced by my mailing lists, it was caused by some unforseen setuid problems when running the new list server script directly from /usr/lib/aliases. Everything should be fixed now; if you sent any mail since yesterday evening, it has probably disappeared and you should resend it. Thanks. From chupchup Thu Jun 3 18:50:00 1993 Received: by oinker.ucsb.edu id AA17936 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 3 Jun 1993 18:50:00 -0700 Date: Thu, 3 Jun 1993 18:50:00 -0700 Message-Id: <199306040150.AA17936@oinker.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: Robert Earl Subject: Messing with 2.3 beta 1.. ;) [Forward] Sender: tinymuck-sloggers-errors Errors-To: tinymuck-sloggers-errors Return-Path: tinymuck-sloggers-errors@oinker.ucsb.edu X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.95 X-Unsub-Address: ------- Forwarded Message Return-Path: c07g@alf.zfn.uni-bremen.de Received: from alf.zfn.uni-bremen.de by ferkel.ucsb.edu with SMTP id AA25381 (5.65c/IDA-1.4.4 for ); Thu, 3 Jun 1993 16:52:11 -0700 Received: by alf.zfn.uni-bremen.de (AIX 3.2/UCB 5.64/4.03-4ki) id AA30180; Fri, 4 Jun 1993 01:50:46 +0200 Date: Fri, 4 Jun 1993 01:50:46 +0200 From: c07g@alf.zfn.uni-bremen.de (Roland Kraesse) Message-Id: <9306032350.AA30180@alf.zfn.uni-bremen.de> To: tinymuck-sloggers@oinker.ucsb.edu Subject: Messing with 2.3 beta 1.. ;) Well, as I was messing with 2.3, I decided to add some new primitives to it. These primitives allow a user to edit a program if that program doesn't have an EDIT_LOCK flag on it, and the euid of the current program allows control of the program that is going to be edited. I added a hash table to the stack frame which holds program entries that contain the information needed. That information is the dbref of the program to be edited, and the text of the program. The new primitives I added are the following: can_open ( d -- i ) returns 1 if can open, 0 if not. open_prog ( d -- ) attempts to open program so it can be edited. close_prog ( d -- ) closes the program if it is opened. add_line ( d i s -- ) adds string s to line i of program d if d is opened. del_lines ( d i1 i2 -- ) deletes lines i1 - i2 of program d if d is opened. get_lines ( d i1 i2 -- s1 s2 ... sN N ) pushes lines i1 - i2 of program d onto the stack along with the number of lines if program d is opened. max_lines ( d -- i ) pushes the number of lines in program d if d is opened. When a program's stack is cleared, it's program list hash table is cleaned out automatically. Anyone got any comments on these prims? -- Spike -- # Log: rejecting mail to tinymuck-sloggers from c07g@alf.zfn.uni-bremen.de (Roland Kraesse) # Log: mailing /tmp/mf25385 to c07g@alf.zfn.uni-bremen.de (Roland Kraesse) ------- End of Forwarded Message From chupchup Thu Jun 3 20:20:55 1993 Received: by ferkel.ucsb.edu id AA27147 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 3 Jun 1993 20:20:55 -0700 Date: Thu, 3 Jun 1993 20:20:55 -0700 Message-Id: <199306040320.AA27147@ferkel.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: Jon Blow Subject: New prims Sender: tinymuck-sloggers-errors@oinker.ucsb.edu Errors-To: tinymuck-sloggers-errors@oinker.ucsb.edu Return-Path: tinymuck-sloggers-errors@oinker.ucsb.edu X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.95 X-Unsub-Address: > Anyone got any comments on these prims? > -- Spike -- Yeah-- tinymuck has too many primitives already. Whereas the functionality these primitives add is good, I think it would be much better to work on generalization of the muck data paradigm such that this editing can be done by existing primitives. -J. From chupchup Fri Jun 11 22:32:18 1993 Received: by ferkel.ucsb.edu id AA14405 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 11 Jun 1993 22:32:18 -0700 Date: Fri, 11 Jun 1993 22:32:18 -0700 Message-Id: <199306120532.AA14405@ferkel.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: Jamieson Norrish Subject: Line print problem Sender: tinymuck-sloggers-errors@oinker.ucsb.edu Errors-To: tinymuck-sloggers-errors@oinker.ucsb.edu Return-Path: tinymuck-sloggers-errors@oinker.ucsb.edu X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.95 X-Unsub-Address: I'm trying to have a series of strings printed out on one line, with a pause in between them. By making the program pause between printing out each string, I cannot simply strcat the strings together and print it out as a whole. Therefore, what can I do to stop the notify moving the output onto the next line? What I get now is something like: str1 [pause] str2 [pause] str3 etc. while I really want str1 [pause] str2 [pause] str3 etc. Any solutions? Jamie From chupchup Sat Jun 12 07:13:35 1993 Received: by ferkel.ucsb.edu id AA16986 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Sat, 12 Jun 1993 07:13:35 -0700 Date: Sat, 12 Jun 1993 07:13:35 -0700 Message-Id: <199306121413.AA16986@ferkel.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: fihsu@Athena.MIT.EDU Subject: Re: Line print problem Sender: tinymuck-sloggers-errors@oinker.ucsb.edu Errors-To: tinymuck-sloggers-errors@oinker.ucsb.edu Return-Path: tinymuck-sloggers-errors@oinker.ucsb.edu X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.95 X-Unsub-Address: Jamieson Norrish writes: >I'm trying to have a series of strings printed out on one line, with a >pause in between them. By making the program pause between printing >out each string, I cannot simply strcat the strings together and print >it out as a whole. Therefore, what can I do to stop the notify moving >the output onto the next line?> You can't. > while I really want >str1 [pause] str2 [pause] str3 etc. >Any solutions? The only solution is if another MUF primitive is created to do exactly what you say. Send the characters, but without the newline. Even then all will not be well. People using clients like tinyfugue, which waits for a new line, will basically see it like this unless they do /lp on: [pause x n] str1 str2 ... strn For people using telnet or lpmud clients, a MUF primitive like that would have the effect you desire. >Jamie Francis From chupchup Thu Jul 22 23:15:06 1993 Received: by oinker.ucsb.edu id AA05983 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Thu, 22 Jul 1993 23:15:06 -0700 Date: Thu, 22 Jul 1993 23:15:06 -0700 Message-Id: <199307230615.AA05983@oinker.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: Robert Earl Subject: Re: CB's new album Sender: tinymuck-sloggers-errors Errors-To: tinymuck-sloggers-errors Return-Path: tinymuck-sloggers-errors@oinker.ucsb.edu X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.95 X-Unsub-Address: In message <199307230445.AA14307@ferkel.ucsb.edu> jessica writes: | Matt writes: | | > Is anyone still subscribing to this group? Someone should probably | > turn it into a newsgroup to boost the traffic. | | Aren't there enough newsgroups that have high traffic to satisfy your | high-traffic-group desires!? | | I can't see any reason to turn this list into a newsgroup. It certainly | doesn't have enough traffic to require or justify a newsgroup, and making | it a newsgroup might in fact increase the traffic, but I highly doubt | it would increase the *valuable* traffic!! I agree with jessica completely, and I have added a few lines to each mailing list's charter file to address this issue as well as that of digests (I'm against those too :-) Feel free to retrieve the new files (send mail to listname-request@oinker.ucsb.edu, with Subject: send archive) Thanks robert From chupchup Fri Jul 23 19:01:14 1993 Received: by oinker.ucsb.edu id AA07927 (5.65c/IDA-1.4.4 for tinymuck-sloggers-list); Fri, 23 Jul 1993 19:01:14 -0700 Date: Fri, 23 Jul 1993 19:01:14 -0700 Message-Id: <199307240201.AA07927@oinker.ucsb.edu> To: tinymuck-sloggers@oinker.ucsb.edu From: Robert Earl Subject: oops. Sender: tinymuck-sloggers-errors Errors-To: tinymuck-sloggers-errors Return-Path: tinymuck-sloggers-errors@oinker.ucsb.edu X-Listserv-Author: Robert Earl X-Listserv-Version: listadm 0.95 X-Unsub-Address: I meant "send charter" not "send archive". sorry folks.