You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Drake W. <dr...@li...> - 2004-06-13 08:08:01
|
On Sat, Jun 12, 2004 at 05:47:17PM -0400, mithras wrote: > I haven't heard from Cynbe since emailing him several weeks ago, but I > haven't lost interest in working with muq. I wish to know how wide > is this community of muq developers, active, inactive and curious. > I've seen Drake Wilson's posts to the bug list, so I know there's at > least one other coder. So, who else is here? Please reply if you > receive this message. (As a side note, I think posting to muq-announce for something like this may not be the best of ideas...) Well, I'm not "else", really, because I am Drake Wilson, but I'm still on the list and list-ening. > Though Cynbe understands the server the best of any of us today, so > long as there's coders who want to work on this software I won't > consider Muq 'dead'. I still fiddle with it somewhat, though not as much as I used to; I've been less actively making stuff on top of it than reading the source code to see how it works (or, in some cases, fails to work -- thus my posts to the bug list). On the surface at least it seems very complicated, but I'm not the best C programmer around by far, so. > Ben Taylor > mithras @ dhp.com > http://www.dhp.com/~mithras ---> Drake Wilson |
From: <mi...@dh...> - 2004-06-12 21:47:19
|
I haven't heard from Cynbe since emailing him several weeks ago, but I haven't lost interest in working with muq. I wish to know how wide is this community of muq developers, active, inactive and curious. I've seen Drake Wilson's posts to the bug list, so I know there's at least one other coder. So, who else is here? Please reply if you receive this message. Though Cynbe understands the server the best of any of us today, so long as there's coders who want to work on this software I won't consider Muq 'dead'. Ben Taylor mithras @ dhp.com http://www.dhp.com/~mithras |
From: Drake W. <dr...@li...> - 2004-02-13 04:49:41
|
Quoth Cynbe ru Taren <cy...@mu...>, on Sun 08 Feb 2004: >=20 > The copyright should be taken as straight GNU LGPL. One of the last > changes I made to Muq pre-Cisco was to change the copyright. In my > version it reads (licensing text snipped) > It is possible this didn't get checked into CVS, or that CVS has > since reverted to an earlier version. Ah, I think I see it now. My confusion resulted from the fact that the most recent copies are actually in muq/muq. > (I still think that society should find a way to compensate creators > of open source code, but that is one battle which I am not personally > interested in fighting at present, at least on the Muq front. Muq is > hard enough without that. :) *giggles* > BTW, I stopped development of Muq Jan 10, 2000, when I started working > for Cisco, which ate all my time after that. I quit Cisco mid-Dec 2003, > and am taking 2004 off to work on open source code (among other things). > Muq is on my priority list of things to work on this year. I won't > make any promises, but there are, thus, objective reasons to be > optimistic about the Muq front. :) Well, I can't wait to see what you'll with-up-come next. :-) > -- Cynbe ---> Drake Wilson |
From: Cynbe ru T. <cy...@mu...> - 2004-02-13 04:39:44
|
I worked full-time on Muq in 1999 getting it to 0.0.0. I racked up some debts in the process. :) I spent 2000->2003 paying those off and getting a bit ahead of the financial game. Hence the hiatus in Muq development. In mid-Dec I quit my Cisco job: I'm taking 2004 off to work on open source projects, including Muq. (Other stuff I want to look at includes 'Self' and some pure-functional programming work.) So far this year I've mostly been rebuilding our house compute infrastructure: o Gigabit ethernet everywhere; o Separate house firewall box; o Separate house fileserver box (4 80G drives in 3:1 software RAID) o Separate house backupserver box (4 300G drives in 2:1:1 software RAID) o Separate house cycleserver box (2 CPU Opteron w 6GB ram) o Updated netserver box (4 80G drives in 2:1:1 software RAID) o Multimedia development box (4 80G drives in 3:1 software RAID) o Personal X server box (6 21.3" 1600x1200 pixel flatpanels in 3x2 array forming 4800x2400 pixel Xinerama display) ... plus a linux sound server for the living room, laptops, wireless hub &t= c. :) Today I'm more or less wrapping up that rebuild phase by bringing up my email pipeline -- I've been on complete email vacation since leaving Cisco and business-only email vacation for months before that. So I'm now in a position to start digging into stuff like Muq again. :) I still don't see any other system that meets the design goals I set out for Muq, so I'm still very much interested in working on it, although I'm not going to be devoting myself 100% to it as I did in 1999. The #1 Muq project on my mind at this point is implementing a clean, mainstream scripting language for Muq to replace, or at minimum complement, the rather clunky and idiosyncratic MUF syntax and semantics. I very much lean toward Ruby as the syntax and semantics of choice. I've become reasonably fluent in Perl over the last couple of years (Drake will probably giggle at this point, since he really does know Perl...) but I unfortunately know nothing whatever of Ruby (or Python) so I'll likely spend some time reducing my ignorance before actually settling down to cranking out Muq releases. Anyhow, that's why Muq has been in hibernation the last four years, and why you might be seeing more activity than usual on the Muq front this year. :) -- Cynbe "Chris Saik" <sou...@ex...> writes: > Is MUQ still even in development? Haven't heard anything from Cynbe in q= uite awhile... > > > > > > > > > > --- On Thu 01/01, Drake Wilson < dr...@li... > wrote: > > From: Drake Wilson [mailto: dr...@li...] > > To: muq...@li... > > Date: Thu, 1 Jan 2004 04:42:03 -0500 > > Subject: [Muq-user] Muq licensing question > > > > According to the licensing comments included in most Muq source files,<br= >the source code is licensed under the GNU GPL v2 for noncommercial<br>purp= oses, but for commercial usage, payment is required at a rate of<br>100 $US= /CPU/year.<br><br>However (at least for me), this results in some confusion= regarding<br>the licensing of non-canonical source. What happens if I mak= e minor<br>modifications? Major modifications? What happens if I release = a<br>modified version noncommercially? Commercially? Must I then collect<= br>100 $US/CPU/year per user and pass it on, or is there some other<br>arra= ngement -- or is this not allowed at all? What about taking<br>individual = source files or functions and using them in other programs;<br>what license= must the other program have, if any -- or does that case<br>preclude distr= ibution of the other program in question?<br><br>More importantly -- what h= appens if I steal^Wobtain design ideas from<br>Muq and then use them in my = own programs without reference to the<br>original source? Are there licens= ing and/or attribution restrictions<br>then? What about lower-level design= details that might plausibly be<br>considered part of the implementation, = but which do not necessarily<br>directly translate into code?<br><br>That's= nine question marks in a row, without a period. I realize this is<br>rath= er a lot of questioning to be doing at once, but inquiring minds want<br>to= know. ;-)<br><br> ---> Drake Wilson<br>Attachment: Attachment (0.23KB)= <br> > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick > _______________________________________________ > Muq-user mailing list > Muq...@li... > https://lists.sourceforge.net/lists/listinfo/muq-user |
From: Cynbe ru T. <cy...@mu...> - 2004-02-13 04:23:17
|
The copyright should be taken as straight GNU LGPL. One of the last changes I made to Muq pre-Cisco was to change the copyright. In my version it reads /************************************************************************/ /* Author: Jeff Prothero */ /* Created: 99May04 */ /* Modified: */ /* Language: C */ /* Package: N/A */ /* Status: */ /* */ /* Copyright (c) 2000, by Jeff Prothero. */ /* */ /* This program is free software; you may use, distribute and/or modify */ /* it under the terms of the GNU Library General Public License as */ /* published by the Free Software Foundation; either version 2, or (at */ /* your option) any later version . */ /* */ /* If you cannot live with GPL, other release terms are */ /* negotiable. Contact cynbe@@muq.org. */ /* */ /* This program is distributed in the hope that it will be useful, */ /* but WITHOUT ANY WARRANTY; without even the implied warranty of */ /* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */ /* GNU Library General Public License for more details. */ /* */ /* You should have received the GNU Library General Public License */ /* along with this program (COPYING.LIB); if not, write to: */ /* Free Software Foundation, Inc. */ /* 675 Mass Ave, Cambridge, MA 02139, USA. */ /* */ /* Jeff Prothero DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, */ /* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN */ /* NO EVENT SHALL JEFF PROTHERO BE LIABLE FOR ANY SPECIAL, INDIRECT OR */ /* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS */ /* OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, */ /* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION */ /* WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ /* */ /* Please send bug reports/fixes etc to bugs@@muq.org. */ /************************************************************************/ It is possible this didn't get checked into CVS, or that CVS has since reverted to an earlier version. (I still think that society should find a way to compensate creators of open source code, but that is one battle which I am not personally interested in fighting at present, at least on the Muq front. Muq is hard enough without that. :) BTW, I stopped development of Muq Jan 10, 2000, when I started working for Cisco, which ate all my time after that. I quit Cisco mid-Dec 2003, and am taking 2004 off to work on open source code (among other things). Muq is on my priority list of things to work on this year. I won't make any promises, but there are, thus, objective reasons to be optimistic about the Muq front. :) -- Cynbe Drake Wilson <dr...@li...> writes: > According to the licensing comments included in most Muq source files, > the source code is licensed under the GNU GPL v2 for noncommercial > purposes, but for commercial usage, payment is required at a rate of > 100 $US/CPU/year. > > However (at least for me), this results in some confusion regarding > the licensing of non-canonical source. What happens if I make minor > modifications? Major modifications? What happens if I release a > modified version noncommercially? Commercially? Must I then collect > 100 $US/CPU/year per user and pass it on, or is there some other > arrangement -- or is this not allowed at all? What about taking > individual source files or functions and using them in other programs; > what license must the other program have, if any -- or does that case > preclude distribution of the other program in question? > > More importantly -- what happens if I steal^Wobtain design ideas from > Muq and then use them in my own programs without reference to the > original source? Are there licensing and/or attribution restrictions > then? What about lower-level design details that might plausibly be > considered part of the implementation, but which do not necessarily > directly translate into code? > > That's nine question marks in a row, without a period. I realize this is > rather a lot of questioning to be doing at once, but inquiring minds want > to know. ;-) > > ---> Drake Wilson |
From: Chris S. <sou...@ex...> - 2004-01-06 12:52:37
|
Is MUQ still even in development? Haven't heard anything from Cynbe in quite awhile... --- On Thu 01/01, Drake Wilson < dr...@li... > wrote: From: Drake Wilson [mailto: dr...@li...] To: muq...@li... Date: Thu, 1 Jan 2004 04:42:03 -0500 Subject: [Muq-user] Muq licensing question According to the licensing comments included in most Muq source files,<br>the source code is licensed under the GNU GPL v2 for noncommercial<br>purposes, but for commercial usage, payment is required at a rate of<br>100 $US/CPU/year.<br><br>However (at least for me), this results in some confusion regarding<br>the licensing of non-canonical source. What happens if I make minor<br>modifications? Major modifications? What happens if I release a<br>modified version noncommercially? Commercially? Must I then collect<br>100 $US/CPU/year per user and pass it on, or is there some other<br>arrangement -- or is this not allowed at all? What about taking<br>individual source files or functions and using them in other programs;<br>what license must the other program have, if any -- or does that case<br>preclude distribution of the other program in question?<br><br>More importantly -- what happens if I steal^Wobtain design ideas from<br>Muq and then use them in my own programs without reference to the<br>original source? Are there licensing and/or attribution restrictions<br>then? What about lower-level design details that might plausibly be<br>considered part of the implementation, but which do not necessarily<br>directly translate into code?<br><br>That's nine question marks in a row, without a period. I realize this is<br>rather a lot of questioning to be doing at once, but inquiring minds want<br>to know. ;-)<br><br> ---> Drake Wilson<br>Attachment: Attachment (0.23KB)<br> _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! |
From: Drake W. <dr...@li...> - 2004-01-05 19:42:35
|
According to the licensing comments included in most Muq source files, the source code is licensed under the GNU GPL v2 for noncommercial purposes, but for commercial usage, payment is required at a rate of 100 $US/CPU/year. However (at least for me), this results in some confusion regarding the licensing of non-canonical source. What happens if I make minor modifications? Major modifications? What happens if I release a modified version noncommercially? Commercially? Must I then collect 100 $US/CPU/year per user and pass it on, or is there some other arrangement -- or is this not allowed at all? What about taking individual source files or functions and using them in other programs; what license must the other program have, if any -- or does that case preclude distribution of the other program in question? More importantly -- what happens if I steal^Wobtain design ideas from Muq and then use them in my own programs without reference to the original source? Are there licensing and/or attribution restrictions then? What about lower-level design details that might plausibly be considered part of the implementation, but which do not necessarily directly translate into code? That's nine question marks in a row, without a period. I realize this is rather a lot of questioning to be doing at once, but inquiring minds want to know. ;-) ---> Drake Wilson |
From: Drake W. <dr...@li...> - 2003-04-30 02:54:03
|
Quoth Cynbe ru Taren <cy...@mu...>, on Tue 29 Apr 2003: >=20 > Good feedback -- thanks! >=20 > I've some comments inline and some more appended. >=20 >=20 > Drake Wilson <dr...@li...> writes: >=20 > > ++ Plaudits: good persistence. > > ++ Plaudits: good persistence (again). >=20 > Good! The persistence is what really differentiates the > Muq design and implementation problems from more mainstream > intepreters like Perl and Python, so it is the persistence > which I thought it most important to Get Right as early in > the process as possible. And it's more right than I've seen it anywhere else. (snip) > > ++ Plaudits: lots of nice builtins. > > ++ Plaudits: compiler support (no text). > > ++ Plaudits: security. >=20 > This is another major thing that distinguishes the Muq > environment and design/implementation problem from that > of Perl/Python &tc: They can quite reasonably assume > that the softcoder is friendly, but we have to assume > that at least some of the softcoders are actively hostile > and trying to take out the system. mooix <http://mooix.net/> does this in an interesting way; it relies on its host system's capabilities. Unfortunately, the way the objects are implemented makes it necessary to cart around big tangled trees of symlinks, and it's _slow_. It uses its host's authentication, multitasking, filesystem... I've been considering using some sort of LD_PRELOAD, plus a Safe compartment, plus chrooting, setuid to nobody, setrlimiting to something very restricted, clearing out the environment, etc. to sandbox arbitrary Perl code into being safe to run, but that hasn't gotten very far. > > -- Problem: no closures. >=20 > I agree and sympathise. This isn't a major coding effort, > just something that got deferred partly because it was > noncritical and could be added in later without breaking > compatability, partly because I wasn't sure whether to make > compiled-functions read-only or not. (I'm now convinced > that they should be.) Hmm. Let me see if I've gotten this right: if an object X is read-only, and it has a slot :foo, X.foo cannot be assigned any value, but if X.foo is another object, it may be mutable. Is this correct? If so, a compiledFunction could contain anonymous Symbols for upvalues, only dereferenceable by the function itself. But I'm not a compiler designer, so I wouldn't know. > > -- Problem: rootAsUserDo{ } doesn't handle object ownership correctly. >=20 > Please expand upon this! This sounds like a design or implementation > error on my part. Example transcript provided below. > We didn't have a lot of prior art for this kind of > stuff -- Perl/Python/etc mostly don't address it, and systems like > MOO and Fuzzball mostly do so very badly Though I can't say anything about MOO, not having tried it, for the hell I've had to go through trying to contort Fuzzball derivants into doing the permissions the way I want, "very badly" may be a slight understatement. > -- so I've had to break path > pretty much unaided, and have very likely made some mistakes in the > process. Possibly. See for yourself -- from the root mufShell: root:=20 =2Eu ls "foo" #<User foo 8fccf00000007c95> "muqnet" #<User muqnet a129680000007c95> "nul" #<User nul 9dd5> "root" #<Root root 1c15> root:=20 makeHash$s.owner =20 root: #<Root root 1c15> pop root:=20 =2Eu["foo"] rootAsUserDo{ makeHash } root: #<Hash _ 85715> dup$s.owner root: #<Hash _ 85715> #<Root root 1c15> pop pop .u["foo"] rootBecomeUser MUF (Multi-User Forth) shell starting up (Do muc:shell to start up Multi-User C shell.) foo:=20 makeHash$s.owner foo: #<User foo 8fccf00000007c95> Hmm. I tried fiddling about with changing to foo's default package, but then since I didn't own the package, I couldn't do _anything_, even rootShutdown or getting the reference to the current job with @ -- which seems a bit strange, to say the least, for root. > > -- Problem: too much stuff compiled into the interpreter. (snip) > > Aaaaaaa, GTK and X. Blech. These should be loaded dynamically, (snip) > I agree. Remember that when Muq started (Dec 1989) Linux was just a > gleam in Linus' eye and the un*x world was fragmented between various > horrors like HP/UX, AIX, AUX, NextStep &tc &tc. Reaching a majority > of the market meant supporting most of them. I spent a lot of time > testing ports to the various platforms. Indeed. > Nowadays, Linux -is- most of the potential market, and it is > reasonable to focus much more heavily on it, and to make use > of facilities it has even when they aren't well supported > elsewhere. (Notice that Netscape got so disgusted with the > dynamic linking situation cross-platform that they finally > wrote their own and just ignored the host one.) Ho ho ho! > GTK and X should compile in only when present -- it is unfortunate > that the GNU autoconfig code supplied with Gtk results in Muq > failing to link when Gtk is not present. :( This isn't hard to > fix by hand, but is still Not Nice. IMNO, the Gtk people screwed > up here. Anyhow, I need to rewrite this. >=20 > As it turns out, the GNU autoconfig people have broken backward > compatability badly, so I'm going to have to do a fair amount of > work on Muq's Configure.in &tc file just to get it 'compiling' > again under the latest version of the config tools, before I can > make furthe progress. (I just picked up a copy of the > "GNU AUTONCONF, AUTOMAKE AND LIBTOOL" book -- I'll see if that > helps explain what they've broken and why, and how to fix it.) Interestingly, I just obtained the same book from the bookstore recently. > Anyhow, dynamic linking is definitely something I lust after, > and have for quite awhile. It has been deferred so far just > because it is something that can be added in upward compatible > fashion later. Right. >=20 > > ?? Unsure: no clear way to get source into the system. > >=20 > > Okay, hypothetically I've built a Muq Forth package, and we'll assume > > for the moment that there aren't any significant problems with it. > > Now how on earth do I get it in the database? Feed it in through the > > shell? Put it in pkg, then recompile the whole database? > >=20 > > I seem to recall something in the docs about this, but now I can't > > find it. Hmm. >=20 > There should be a number of viable approaches. The True Mudder types > might just log in via tinyfugue and /quote in. I tend to run Muq > from the commandline in an Emacs shell window and just cut-and-paste > the required code into that window when I need this sort of > capability. (Since I'm mostly working on the C-coded server, I > mostly -am- rebuilding the whole db from scratch each time, so I > haven't had to deal with this much.) >=20 > It should be pracital to run muq-lib to load in one package or > library -- I should look at this. Uh. Don't take this personally, but that seems to be rather broken at the moment. It just wiped out my file. o.o;; premchai21@octothorpe:/usr/src/muq/bin$ cat > foo.muf "foo" inPackage : hello "Hello, world!\n" , ; premchai21@octothorpe:/usr/src/muq/bin$ muq-lib foo.muf /usr/src/muq/bin/Muq-detexify <foo.muf >foo.muf foo.muf Doing: muq -x muf:compileMufFile -f foo.muf -f /usr/src/muq/pkg/Shutdown ***** A 'muq-RUNNING-ROOTDB.muq' ALREADY EXISTS! Either another Muq is already running on this db, or else a previous Muq run on this db crashed. If another Muq is running, wait until it exits. If the previous Muq run crashed, do rm -rf muq-RUNNING-ROOTDB.muq and then try again. Muq will automatically revert to muq-CURRENT-ROOTDB.muq, which should be an intact db. muq-lib: result =3D 1 premchai21@octothorpe:/usr/src/muq/bin$ cat foo.muf premchai21@octothorpe:/usr/src/muq/bin$=20 A) This apparently doesn't work when a Muq instance is already running. Probably this can be around-gotten with a pipe of some sort -- or the shell-feed can be used, though I usually don't get around to rootAcceptingLogins when just playing around. Naturally, taking down the running Muq to install new libraries is not generally an acceptable option. B) This seems to assume that its input is a Texinfo file. Ordinarily, I would assume that giving it the source directly would just input nothing, or give an error message, or do something equally failureful but unharmful. Instead, it clobbers the file entirely. This is a Bad Thing (tm). I've currently just spliced in a conditional before the Muq-detexification to check whether it's going to overwrite and then prompt. Also, there's some awkward seds and things that could be done entirely in bash -- I assume the reason they're not is portability, as I'm no expert on shell portability (at all). > One of the things I lust for but haven't yet had time to do > is something like a small program 'muf' which lets run code > just the way you run Perl or Python code, but with execution > of course actually transparently taking place within the Muq > server. This would go far towards making Muq "play nice" > with the rest of the unix toolkit. You could: >=20 > muf -e '. ls' | grep foo >=20 > to list stuff in the db and grep through it for interesting stuff, >=20 > muf foo.muf >=20 > to install a file/module 'foo' in the db, &tc &tc. One could > implement it by having the running server export a named pipe > ~/.muq-server or some such which the 'muf' front-end could > use to initiate the interaction. Most serious modern databases > have these sorts of front-end clients to simplify interaction. muq-lib might be able to use this interface too. Presumably such code would run as root by default if executed by the same user as the muq process; with multiple users accessing the same database it might get a little trickier. >=20 > > __END__ > >=20 > > Make of it what you will. > >=20 > > ---> Drake Wilson >=20 >=20 > Here's where I am: >=20 > My financial situation is much improved, and I'm no longer doing > the 3-5 hour/day Cisco commute. I'm taking May and June off from > Cisco mostly to exercise and get back into more reasonable > physical condition. I am also hoping to do some Muq work during > that period, although it has to compete with some other priorities. Well, that's good. > When I suspended work on Muq 2000-Jan-10, writing a really decent > application language looked like the most urgent major project. > (Muq MUF is an interesting exercise in pushing Forth notation about > as far as it can go, but is I think clearly not what the Linux > mainstream wants these days -- or me either, for that matter.) Actually, I rather like it... (snip) > On balance, I now think that Ruby is the best application language > for Muq: Ho ho ho! You know, when I tried to write something like this myself, I kept looking for a good language, and finally was actually trying to implement it in Ruby -- but I was trying to do it on an unmodified interpreter, which became so impossible that I gave up. (snip) > o It has a clear Lisp heritage, just as Muq does -- there's a > deep cultural resonance between Muq and Ruby. (snip) =2E.. and later, I tried some primitive form of serialization and quasi-multi-user capability with the rep Lisp dialect... > So anyhow, on the major-release scale of planning, I think the > sensible direction forward for Muq is to split off the C-coded server > as a separate "PersistentRuby" sourceforge project, retaining the > "Muq" name then for the softcode implementing a virtual world kit in > Ruby on top of the C server. Okay. (major abridgement) > So my mental roadmap for Muq at this point consists of a balance of > small virtual machine improvements of the sort you've pointed out on > the one hand (another I particularly want is to add support for > dynamically resizable objects in the Muq virtual machine, so that we > can support stuff like Perl's shift/unshift/push/pop operations on > vectors) while on the other hand spending some time reading and > understanding the Ruby 1.8 implementation and then phasing in Muq > virtual machine support for Ruby's semantic idiosyncracies where > needed, and hacking together a parser for Ruby's surface syntax. Hmm. I'm wondering whether it'd be possible to take things from the Ruby interpreter itself... > Since Muq makes adding parsers quite easy, and since Ruby's semantics > are very close to those of the existing Muq virtual machine anyhow > (courtesy I think of their common lisp-influenced background), I > expect the latter project to go considerably faster than might at > first blush be suspected. (E.g., the existing "multi-user C" > implementation in Muq already looks a lot like Ruby, and represents > something like 1-2 weeks work.) (scissor) I haven't looked into that much, so I wouldn't know. > Ad astra! :) Perhaps... > -- Cynbe (snip) ---> Drake Wilson |
From: Cynbe ru T. <cy...@mu...> - 2003-04-29 01:08:50
|
Good feedback -- thanks! I've some comments inline and some more appended. Drake Wilson <dr...@li...> writes: > ++ Plaudits: good persistence. > ++ Plaudits: good persistence (again). Good! The persistence is what really differentiates the Muq design and implementation problems from more mainstream intepreters like Perl and Python, so it is the persistence which I thought it most important to Get Right as early in the process as possible. There is still some work needed on handling cross-links between different sub-dbs as nicely as possible in the face of rollbacks &tc. Sometimes you just have to treat the link as broken, but one can preserve the links more often than we currently do, given extra work. The garbage collection is also still pro-tem. It is about as good as Python and such (mark and sweep), but in the Muq context we need to to better, because we can't assume the db is small and in memory: We need a more state-of-the art multigeneration and/or incremental system. Nothing terribly new or hard, just More Coding. > ++ Plaudits: lots of nice builtins. > ++ Plaudits: compiler support (no text). > ++ Plaudits: security. This is another major thing that distinguishes the Muq environment and design/implementation problem from that of Perl/Python &tc: They can quite reasonably assume that the softcoder is friendly, but we have to assume that at least some of the softcoders are actively hostile and trying to take out the system. > -- Problem: no closures. I agree and sympathise. This isn't a major coding effort, just something that got deferred partly because it was noncritical and could be added in later without breaking compatability, partly because I wasn't sure whether to make compiled-functions read-only or not. (I'm now convinced that they should be.) > -- Problem: rootAsUserDo{ } doesn't handle object ownership correctly. Please expand upon this! This sounds like a design or implementation error on my part. We didn't have a lot of prior art for this kind of stuff -- Perl/Python/etc mostly don't address it, and systems like MOO and Fuzzball mostly do so very badly -- so I've had to break path pretty much unaided, and have very likely made some mistakes in the process. > -- Problem: too much stuff compiled into the interpreter. > > premchai21@octothorpe:/usr/src/muq/bin$ ldd muq > libnsl.so.1 => /lib/libnsl.so.1 (0x40026000) > libm.so.6 => /lib/libm.so.6 (0x4003a000) > libc.so.6 => /lib/libc.so.6 (0x4005b000) > libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4016b000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x402a3000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x402d7000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x402da000) > libdl.so.2 => /lib/libdl.so.2 (0x402fe000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40301000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40309000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40316000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Aaaaaaa, GTK and X. Blech. These should be loaded dynamically, > ideally, though I realize that may not be feasible on all platforms. > Ideally, what I'd like to see is some sort of NativePackage class that > magically dlopen()s (or equivalent) a designated native C library, > fetches all the function declarations and such, and automatically > wraps around it. In this case, it'd probably have to be only ownable > by root, immutable once created, etc. etc. etc. -- another possibility > would be to have a generalized C wrapper program that does some sort > of RPC through a pipe. I'm not sure whether this is possible or > reasonable to do, however. I agree. Remember that when Muq started (Dec 1989) Linux was just a gleam in Linus' eye and the un*x world was fragmented between various horrors like HP/UX, AIX, AUX, NextStep &tc &tc. Reaching a majority of the market meant supporting most of them. I spent a lot of time testing ports to the various platforms. Nowadays, Linux -is- most of the potential market, and it is reasonable to focus much more heavily on it, and to make use of facilities it has even when they aren't well supported elsewhere. (Notice that Netscape got so disgusted with the dynamic linking situation cross-platform that they finally wrote their own and just ignored the host one.) GTK and X should compile in only when present -- it is unfortunate that the GNU autoconfig code supplied with Gtk results in Muq failing to link when Gtk is not present. :( This isn't hard to fix by hand, but is still Not Nice. IMNO, the Gtk people screwed up here. Anyhow, I need to rewrite this. As it turns out, the GNU autoconfig people have broken backward compatability badly, so I'm going to have to do a fair amount of work on Muq's Configure.in &tc file just to get it 'compiling' again under the latest version of the config tools, before I can make furthe progress. (I just picked up a copy of the "GNU AUTONCONF, AUTOMAKE AND LIBTOOL" book -- I'll see if that helps explain what they've broken and why, and how to fix it.) Anyhow, dynamic linking is definitely something I lust after, and have for quite awhile. It has been deferred so far just because it is something that can be added in upward compatible fashion later. > ?? Unsure: no clear way to get source into the system. > > Okay, hypothetically I've built a Muq Forth package, and we'll assume > for the moment that there aren't any significant problems with it. > Now how on earth do I get it in the database? Feed it in through the > shell? Put it in pkg, then recompile the whole database? > > I seem to recall something in the docs about this, but now I can't > find it. Hmm. There should be a number of viable approaches. The True Mudder types might just log in via tinyfugue and /quote in. I tend to run Muq from the commandline in an Emacs shell window and just cut-and-paste the required code into that window when I need this sort of capability. (Since I'm mostly working on the C-coded server, I mostly -am- rebuilding the whole db from scratch each time, so I haven't had to deal with this much.) It should be pracital to run muq-lib to load in one package or library -- I should look at this. One of the things I lust for but haven't yet had time to do is something like a small program 'muf' which lets run code just the way you run Perl or Python code, but with execution of course actually transparently taking place within the Muq server. This would go far towards making Muq "play nice" with the rest of the unix toolkit. You could: muf -e '. ls' | grep foo to list stuff in the db and grep through it for interesting stuff, muf foo.muf to install a file/module 'foo' in the db, &tc &tc. One could implement it by having the running server export a named pipe ~/.muq-server or some such which the 'muf' front-end could use to initiate the interaction. Most serious modern databases have these sorts of front-end clients to simplify interaction. > __END__ > > Make of it what you will. > > ---> Drake Wilson Here's where I am: My financial situation is much improved, and I'm no longer doing the 3-5 hour/day Cisco commute. I'm taking May and June off from Cisco mostly to exercise and get back into more reasonable physical condition. I am also hoping to do some Muq work during that period, although it has to compete with some other priorities. When I suspended work on Muq 2000-Jan-10, writing a really decent application language looked like the most urgent major project. (Muq MUF is an interesting exercise in pushing Forth notation about as far as it can go, but is I think clearly not what the Linux mainstream wants these days -- or me either, for that matter.) I've been writing quite a bit of Perl in the last year at Cisco -- I've become truly fluent in it for the first time -- and was wondering about it as a Muq language for awhile, but I eventually decided its syntax and semantics are just too screwy with too much historical baggage (read "old design mistakes") to be a good fit to the Muq environment. In particular, its notion of 'reference', because it was added as an afterthought rather than designed in, does a great job of taking something trivial simple and making it imponderably difficult. The Perl OOP stuff is also at best usable. Python looks much more attractive, but its tuple/array distinction is as ugly and needless as Perl's list/array distinction, its syntax for regular expressions can be most politely described as clunky, and like Perl it insists that numbers are not objects, which is (1) IMHO Just Plain Wrong for a scripting language and (2) not the way the Muq virtual machine does things. On balance, I now think that Ruby is the best application language for Muq: o It treats numbers as objects, the same way Muq does. o Ruby makes simple regular expression usage very simple and clean. I think this is important in a text-oriented virtual world system where command parsing &tc are very common coding issues. o It has a clear Lisp heritage, just as Muq does -- there's a deep cultural resonance between Muq and Ruby. o I like Ruby's design and implementation: It feels good. Rooting through Perl's internals feels like swimming in a sewer, and while Python's code culture is ok, it isn't really my personal cup of tea. It it good to feel good about the code you're working with. o Ruby isn't overly popular yet. That means that the design and implementation have not yet accumulated so much hair as to make a re-implementation in Muq difficult: It is still at the stage where it is reasonably easy for one person to read and understand the Ruby source. But it is popular enough to demonstate that the basic Ruby design and implementation are sound and acceptable to the mainstream -- and to have some books out that user's can buy, to save me the effort of writing and maintaining tutorial books &tc in addition to the server. Working with an established spec like Ruby will also save me lots of time thinking and arguing about scripting language semantics: If someone says they don't like feature X, I just say, "Fine -- but that's our standard and we're sticking to it." :) So anyhow, on the major-release scale of planning, I think the sensible direction forward for Muq is to split off the C-coded server as a separate "PersistentRuby" sourceforge project, retaining the "Muq" name then for the softcode implementing a virtual world kit in Ruby on top of the C server. I am, by the way, considerably less enthusiastic now about multiple scripting languages in virtual worlds generallly and Muq in particular. Researching Perl and Python, I found that one of the most common reasons given for switching from Perl to Python is that Perl is easy to write but hard to read. People repeatedly say that even their own Perl code is hard to read after a three-month lay-off doing something else, whereas with Python it is easy to instantly pick up where one left off, and it is even (relatively!) easy to read and mainstain other people's code. Overgeneralizing somewhat, Perl's strength seems to be short throw-away glue scripts, while Python's strength seems to be large, multi-person codebases: Perl's core installed base is CGI scripts, while Python's core is large multi-person projects like Zope and Randy Pausch's 3D virtual world system Linda. The problem, I think, is that Perl's "There Is More Than One Way To Do It" motto makes things easy for the code writer, who can work in whatever supported paradigm s/he likes best, but makes things hard on the reader, who must be able to read and understand all the paradigms. Having multiple actual different scripting languages in the system would make the effect even more pronounced: The code writer can learn just the one s/he favors, but the code reader and system maintainer must become fluent in all of them. Since I have for years been of the firm opinion that ease of reading code is much more important than ease of writing code -- as the system gets bigger, even the active coder spends more and more time reading the existing code, researching how to make a change -- this in my mind militates strongly in favor of sticking to one simple, clear scripting language for the overwhelming bulk of archival code in a system. So my mental roadmap for Muq at this point consists of a balance of small virtual machine improvements of the sort you've pointed out on the one hand (another I particularly want is to add support for dynamically resizable objects in the Muq virtual machine, so that we can support stuff like Perl's shift/unshift/push/pop operations on vectors) while on the other hand spending some time reading and understanding the Ruby 1.8 implementation and then phasing in Muq virtual machine support for Ruby's semantic idiosyncracies where needed, and hacking together a parser for Ruby's surface syntax. Since Muq makes adding parsers quite easy, and since Ruby's semantics are very close to those of the existing Muq virtual machine anyhow (courtesy I think of their common lisp-influenced background), I expect the latter project to go considerably faster than might at first blush be suspected. (E.g., the existing "multi-user C" implementation in Muq already looks a lot like Ruby, and represents something like 1-2 weeks work.) (I also have some Tcl coding on my plate to finish up before I settle down to any of that. My opinion of Tcl pretty matches that given in Richard Stallman's critique "Why You Should Not Use Tcl" (http://www.vanderburg.org/Tcl/war/0000.html): It is a language so small and simple that applications will inevitably outgrow it, resulting in ugly attempt to retrofit functionality to a design not suited to it -- imho exactly what we are in fact seeing with Tcl 8.x's bytecoded implementation. But I'm enjoying learning more about it anyhow -- and finding Don Libe's Tcl-based 'expect' utility invaluable for various kinds of automation. The various Perl-based imitations of 'expect' which I've tried just don't measure up to the original.) Ad astra! :) -- Cynbe |
From: Drake W. <dr...@li...> - 2003-04-28 01:51:53
|
Allow me to note a few things first. Many of these are already covered (at least somewhat) in the "Future Plans" section of the documentation, or in prior mails, or -- etc. The chance of my implementing any of these things myself is small due to logistical constraints, but not zero. Also, some of these may be wrong -- while I have attempted to verify that they are correct, I haven't done any exhaustive search or exhaustive proof. That being said, here are some (positively and negatively by-me-valued) characteristics of the current Muq system, as far as I can tell... #!/usr/bin/... ++ Plaudits: good persistence. Virtually any object can persist in a dbfile. This is a Good Thing, since it allows one to escape the usual limitations whereby states cannot be restored effectively. ++ Plaudits: good persistence (again). dbfiles can be separately mounted and unmounted, and they're automatically compressed, and backup copies are kept, and garbage collection works wonderfully, and... need I go on? ++ Plaudits: lots of nice builtins. An object system, locking contexts, various data types, streams, lots of extra functions that just make things nicer to with-deal. ++ Plaudits: compiler support (no text). ++ Plaudits: security. The Assembler class guarantees (at least in theory) that the VM will never crash. Almost all objects have built-in protections. -- Problem: no closures. This is annoying, at least to me. I tend to think in some mishmash of programming styles, and one of them is functional. No closures means no effective way to do nontrivial functional programming. Blech. -- Problem: rootAsUserDo{ } doesn't handle object ownership correctly. This makes it virtually impossible to write such things as package managers; the mapping (one user <-> one dbfile <-> one set of packages) doesn't work when root can't create objects asOtherUsers. -- Problem: too much stuff compiled into the interpreter. premchai21@octothorpe:/usr/src/muq/bin$ ldd muq libnsl.so.1 => /lib/libnsl.so.1 (0x40026000) libm.so.6 => /lib/libm.so.6 (0x4003a000) libc.so.6 => /lib/libc.so.6 (0x4005b000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4016b000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x402a3000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x402d7000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x402da000) libdl.so.2 => /lib/libdl.so.2 (0x402fe000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40301000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40309000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40316000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Aaaaaaa, GTK and X. Blech. These should be loaded dynamically, ideally, though I realize that may not be feasible on all platforms. Ideally, what I'd like to see is some sort of NativePackage class that magically dlopen()s (or equivalent) a designated native C library, fetches all the function declarations and such, and automatically wraps around it. In this case, it'd probably have to be only ownable by root, immutable once created, etc. etc. etc. -- another possibility would be to have a generalized C wrapper program that does some sort of RPC through a pipe. I'm not sure whether this is possible or reasonable to do, however. ?? Unsure: no clear way to get source into the system. Okay, hypothetically I've built a Muq Forth package, and we'll assume for the moment that there aren't any significant problems with it. Now how on earth do I get it in the database? Feed it in through the shell? Put it in pkg, then recompile the whole database? I seem to recall something in the docs about this, but now I can't find it. Hmm. __END__ Make of it what you will. ---> Drake Wilson |
From: Cynbe ru T. <cy...@mu...> - 2002-08-17 00:37:05
|
[My comments inline...] Drake Wilson <dr...@li...> writes: > Where did Muq's name come from? Most text VR servers get names that > start with MU, for Multi-User, and Muq, though not strictly a text VR > server in itself, seems to be following that pattern. But usually the > letters following have some meaning -- muD, D = Dungeon, muCK, CK = > Created Kingdom, muSH, SH = Shared Hallucination. > Soo... multi-user... > > quagmire? quality? quandary? quanta? quarantine? quarrel? quasar? > quasiserver? queue? quest? quietude? quince? quiz? quota? quotation? > quotient? > "Created Kingdom"?! "Shared Halluciation"?! :) First I've heard of those! They sound like recent folk etymology backformations to me. My impression was that after "MUD", it became pretty much "anything starting with MU and sounding cold and squishy". Anyhow, the approximate history is: In 1990 or so I was hanging out on David Pirman's Quartz BSS because it was a Citadel (another of my software efforts) and to some extent on its sister QuartzMUCK server. Both named after the host on which they were running -- an overworked, fondly remembered, long lamented Sun box if I remember correctly. Some friends and I decided to put up a mud on my University of Washington workstation, a screamingly fast 16MHz SGI MIPS box (one of the first "Personal Iris"es -- 4D/20 -- and one of the first RISC boxes from SGI after they jumped ship from the Motorola 680x0 architecture) loaded with an amazing 16Meg or so of RAM plus just -megabytes- of disk. My friends had never seen a computer with that kind of power. More than enough to run multiple virtual worlds plus do lots of high performance graphics, obviously. (I noticed today that machines 5x faster are going for $19 in the local discount electronics outlet. All things electronic come to those who wait!) At the time, I was interested in using Forth as a scripting language, so I poked around and decided MUCK looked like it would let me kill two birds with one stone -- put up a virtual world and get some experienc with Forth-scripted systems. So we put up a world called Qwest -- Quartz West, in honor of my favorite internet BBS/MUCK and also the source of most of our original players. We wound up evolving to using fuzzball, and I wound up doing maintainance on fuzzball, tracking down the obscure memory leaks &tc that the other maintainers were unable or unwilling to fix. (I wound up writing a little memory-leak detection package which I think is still distributed as part of fuzzball muck.) And I went through my usual sequence of interactions with any new software package I use: (1) MAN, THIS IS COOL! (2) Um, this is really cool, but a few things need fixing. (3) You know, what this package really needs is a thorough spring-cleanikng -- a top-to-bottom rewrite to clear out the accumuated cruft. (4) You know, it would be a lot faster to write something new from scratch than to try salvaging this thing. So I started writing TinyMuq with 'q' standing for 'Qwest', the world I intended to use the server on, as a name which reasonably honestly showed the server's ancestry and affinity. The TinyMuq development process outlived Qwest muck itself, however (another story), and fuzzball TinyMUCK went off in directions which didn't appeal to me (I like the maintainers, but we agree to disagree about some technical issues of server design...) so I abandoned TinyMU* compatibility as a design goal, and truncated "TinyMUQ" down to just "Muq" to reflect this. I write it "Muq" rather than "MUQ" partly because I don't like shouting, and partly to suggest that it isn't much of an acronym at this point. Anyhow, of your suggestions, "quagmire" is clearly the one best fitting into the "soft and squishy" tradition of mud/muck/mush/&tc. (Since you listed it first, I expect you made the same observation.) I think we can say that "MUQ" stands for "Multi-User Quagmire" just as surely as "MUCK" stands for "Multi-User Created Kingdom." :) I must admit, however, that this wasn't an issue that had ever occurred to me. (Then again, I seem better at creating software than names for it. My "Citadael" software had already been in use nationwide for about a year by the time I finally came up with that name for it...) There. Aren't you glad you asked? :) > Also, how is one supposed to pronounce "Muq" so that it is > distinguishable from "Muck"? > > ----> Drake Wilson This is actually documented somewhere in the Muq docs, believe it or not! During the period when I was both maintaining (fuzzball) tinyMuck and also working on tinyMuq, I got sick of people asking me "How's muck coming?" and having no clue which one they meant. So after running through all the variant pronunciations I could think of for MUQ, I finally exercised my vast authority as creator of the software (naming the package is about the only power an open source developer has...) and decreed that "Muq" is pronounced so as to rhyme with "hook'. Mnemonic: "I took a look in the Muq book." :) -- Cynbe |
From: Drake W. <dr...@li...> - 2002-08-16 03:45:09
|
Where did Muq's name come from? Most text VR servers get names that start with MU, for Multi-User, and Muq, though not strictly a text VR server in itself, seems to be following that pattern. But usually the letters following have some meaning -- muD, D =3D Dungeon, muCK, CK =3D Created Kingdom, muSH, SH =3D Shared Hallucination. Soo... multi-user... quagmire? quality? quandary? quanta? quarantine? quarrel? quasar?=20 quasiserver? queue? quest? quietude? quince? quiz? quota? quotation?=20 quotient? Also, how is one supposed to pronounce "Muq" so that it is distinguishable from "Muck"? ----> Drake Wilson |
From: Artiste E. <ar...@mu...> - 2000-08-03 00:08:19
|
Testing to see if names show up in 'from' fields now. I had one of the protection features on that hides the 'from' address, but obviously that works less well if there's no way to identify the sender (ie PGP). -Andy |