Server Wish-List
Josh Benner
the MOO server?
Things I'd like to add to the server but haven't taken the time to
look for or try to implement myself:
1. Proper comments -- not because lonely strings don't work, but
comments are a convention in general and make jumping between MOO and
other languages easier. Single-line // things.
2. Preserve empty lines in code -- greatly increases readability of
code.
Luke-Jr
> I'm wondering: types other things do people feel might be missing from
> the MOO server?
>
> Things I'd like to add to the server but haven't taken the time to
> look for or try to implement myself:
> 1. Proper comments -- not because lonely strings don't work, but
> comments are a convention in general and make jumping between MOO and
> other languages easier. Single-line // things.
Supported by JHCore/WaterpointCore for years now.
> 2. Preserve empty lines in code -- greatly increases readability of
> code.
I keep all my MOO code in git-stored text files.
Josh Benner
do those cores support comments, exactly?
Yes, I keep all of my code in revision-controlled text files and use
an extensive custom plugin for Sublime Text 2 to manage highlighting,
code navigation, and deploying code to the server -- however, there
are plenty of times that I inspect code directly on the server, and
preserving empty lines would greatly increase readability.
Luke-Jr
> I was talking about server features -- however, I'm curious about how
> do those cores support comments, exactly?
// this is a "test"
Gets translated to:
"this is a \"test\"";
They also store metadata like verb arguments, last edit user/time, etc, at the
end of the verb.
$bf_set_verb_code/$bf_verb_code are so handy. :)
Also, the MOO server has had /* */ style comments standard for a long time.
But these are true comments: they are discarded when you compile. Since MOO
does not store source code anywhere, and just decompiles the bytecode when you
ask for it, these comments are basically useless except when storing your code
in an external file (like I do).
Todd Sundsted
from bytecode idea was a clever experiment that just does not work
well. I have ideas and plans for fixing this in the server. In the
meantime I do a flavor of what everyone else does -- I've overridden
the built-ins `verb_code()' and `set_verb_code()' and effectively
store the raw source for the verb code as strings at the tail of the
verb itself. This preserves full fidelity of the source (comments,
empty lines, and formatting) and allows me to experiment with a
variety of source code translators as part of the "compilation"
process.
Todd
Luke-Jr
> MOO verb storage desperately needs a revamp. The compile to/decompile
> from bytecode idea was a clever experiment that just does not work
> well.
I strongly disagree. This allows programmers to (in theory) use different
formats for reading/writing code and still work together sensibly. When/if
support for other languages is added (I once did BASIC for MOO), it allows
people to collaborate across language barriers even.
Comments are needed. Been fixed for years.
Extra whitespace would be nice. Easily fixed with "0;" or such.
Josh Benner
another seems very low-value.
The ability to enhance MOO syntax without having to implement compile
AND decompile seems high-value.
The two way (de)compile is, like Todd said, interesting... but
ultimately unnecessarily complex and somewhat limiting.
Furthermore, if MOO didn't decompile to render code from a running
server, you could still have different language compilers that compile
to bytecode. You'd just be missing the magical translate-from-one-
language-to-another capability... which seems very obscure, and not a
major feature.
Josh Benner
from which it was compiled, then might we even gain opportunities for
optimizing the resulting bytecode without needing special opcodes for
each optimization (like is done with integers)?
On Dec 1, 3:38 pm, "Luke-Jr" <l...@dashjr.org> wrote:
Luke-Jr
> Furthermore, if bytecode didn't need to decompile to the same from
> from which it was compiled,
It doesn't. It needs to decompile to something that will do the same thing,
formatted how the programmer wishes.
Josh Benner
then might we even gain opportunities for optimizing the resulting
Luke-Jr
> Let me rephrase then: if bytecode didn't need to decompile /at all/,
> then might we even gain opportunities for optimizing the resulting
> bytecode [...] ?
Might as well drop the current MOO implementation altogether and do something
that compiles to native CPU bytecode...
Josh Benner
yields no benefit over compiling to native machine code, or perhaps
that optimizing bytecode sequences is equally complex as compiling to
machine code. One needs only consider the complexity of machine code
compilation let alone architecture support to quickly see this is a
false assertion. Furthermore, the compiler is already present, and
optimizations would be additive atop it, not an entire compiler
rewrite.
Todd: What do you imagine a revamped code storage approach to look
like? My first thought would be simply storing the verb code string
and retrieving it rather that decompile upon calls to verb_code() and
related db functions.
Luke-Jr
> You imply that removing the decompiler but keeping a bytecode machine
> yields no benefit over compiling to native machine code, or perhaps
> that optimizing bytecode sequences is equally complex as compiling to
> machine code. One needs only consider the complexity of machine code
> compilation let alone architecture support to quickly see this is a
> false assertion. Furthermore, the compiler is already present, and
> optimizations would be additive atop it, not an entire compiler
> rewrite.
There's not much significant gain from removing the decompiler, and a lot of
work to adapt the rest of the MOO server to the change. It would indeed be
just about as easy to replace the whole thing with a native compiler by
translating the MOO code to C and calling the local GCC. Keep in mind I
implemented the basic MOO compiler in only a couple of days in Perl...
Josh Benner
the idea of compiling an interpreted dynamic language to machine code
seems like a bad idea. I'm not even sure how you'd execute the
compiled code in a way that would give it access to the database. If
such an approach was so easy and such a good idea, why don't the likes
of PHP, Java, Ruby, or Python just compile to machine code?
I think MOO might stand to gain from removing the decompiler,
including:
1. Native preservation of code formatting
2. Opens door for bytecode optimization (from simple removal of
comments from bytecode to true optimizations)
3. Simplifies code required to add new language features
Luke-Jr
> I'll freely admit that I'm not a seasoned compiler developer. However,
> the idea of compiling an interpreted dynamic language to machine code
> seems like a bad idea.
MOO isn't that bad. It's already compiled to bytecode-- just not native.
> I'm not even sure how you'd execute the compiled code in a way that would
> give it access to the database.
Obviously standard functions and such would all be accessed via a library.
> If such an approach was so easy and such a good idea, why don't the likes
> of PHP, Java, Ruby, or Python just compile to machine code?
At least Java does behind the scenes. I know Facebook does it for PHP in
house. Python is similar to MOO, in that it compiles to its own bytecode and
interprets it. No idea on Ruby-- don't want to touch that garbage.
> I think MOO might stand to gain from removing the decompiler,
> including:
> 1. Native preservation of code formatting
Usually this is a bad thing. There's a reason why every major program has
strict code formatting guidelines.
> 2. Opens door for bytecode optimization (from simple removal of
> comments from bytecode to true optimizations)
Why reinvent the wheel? GCC already has far better optimizations than a small
team of part time programmers are going to do.
> 3. Simplifies code required to add new language features
Not really.
Josh Benner
On Dec 1, 5:26 pm, "Luke-Jr" <l...@dashjr.org> wrote:
> On Thursday, December 01, 2011 5:21:52 PM Josh Benner wrote:
>
> > I'll freely admit that I'm not a seasoned compiler developer. However,
> > the idea of compiling an interpreted dynamic language to machine code
> > seems like a bad idea.
>
> MOO isn't that bad. It's already compiled to bytecode-- just not native.
>
> > I'm not even sure how you'd execute the compiled code in a way that would
> > give it access to the database.
>
> Obviously standard functions and such would all be accessed via a library.
See, you're describing a much more fundamental modification than
simply removing the decompiler.
>
> > If such an approach was so easy and such a good idea, why don't the likes
> > of PHP, Java, Ruby, or Python just compile to machine code?
>
> At least Java does behind the scenes. I know Facebook does it for PHP in
> house. Python is similar to MOO, in that it compiles to its own bytecode and
> interprets it. No idea on Ruby-- don't want to touch that garbage.
Java compiles to bytecode, which is interpreted by the JVM. PHP
compiles to bytecode that is interpreted by the Zend Engine. Python
(the main CPython anyway) compiles to bytecode that is interpreted by
the internal Python virtual machine. Similar story with the various
Ruby implementations (each their own compile-to-bytecode and virtual
machine).
I've used Facebook's Hiphop approach to compiling PHP. It's cool,
though I'd note that it offers only marginal performance gains over
well-configured opcode caches (which is what the MOO server is) for
many applications, having increased benefit as the codebase grows
(though then it's often due to I/O or available memory, and not pure
execution throughput).
>
> > I think MOO might stand to gain from removing the decompiler,
> > including:
> > 1. Native preservation of code formatting
>
> Usually this is a bad thing. There's a reason why every major program has
> strict code formatting guidelines.
Code conventions and formatting guideline are a good thing. However,
every language (that I'm aware of?) leaves this up to the coder (and
his team?), or at least allows for flexibility. Having a language that
enforces a this-is-the-one-true-way seems far less desirable than
having a standard to be adhered to by the coder.
>
> > 2. Opens door for bytecode optimization (from simple removal of
> > comments from bytecode to true optimizations)
>
> Why reinvent the wheel? GCC already has far better optimizations than a small
> team of part time programmers are going to do.
>
> > 3. Simplifies code required to add new language features
>
> Not really.
To add a new language feature (syntax), you need to implement:
1. Parsing text code to expressions
2. Compiling expressions to opcodes
3. Decompiling opcodes to expressions
4. Unparsing expressions to text code
Without the need to decompile on verb_code() and db write,
implementing a syntax feature would require:
1. Parsing text code to expressions
2. Compiling expressions to opcodes
How is this not simplifying the code required to add new language
features?
michael munson
--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To post to this group, send email to MOO-...@googlegroups.com.
To unsubscribe from this group, send email to MOO-talk+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
Luke-Jr
> > > I'm not even sure how you'd execute the compiled code in a way that
> > > would give it access to the database.
> >
> > Obviously standard functions and such would all be accessed via a
> > library.
>
> See, you're describing a much more fundamental modification than
> simply removing the decompiler.
Removing the decompiler is not at all simple. It's a fundamental restructure
of a lot of the MOO server. And builtins are *already* accessed as if via a
library internally...
> > > If such an approach was so easy and such a good idea, why don't the
> > > likes of PHP, Java, Ruby, or Python just compile to machine code?
> >
> > At least Java does behind the scenes. I know Facebook does it for PHP in
> > house. Python is similar to MOO, in that it compiles to its own bytecode
> > and interprets it. No idea on Ruby-- don't want to touch that garbage.
>
> Java compiles to bytecode, which is interpreted by the JVM.
No, the JVM recompiles it to native CPU bytecode.
> > > I think MOO might stand to gain from removing the decompiler,
> > > including:
> > > 1. Native preservation of code formatting
> >
> > Usually this is a bad thing. There's a reason why every major program has
> > strict code formatting guidelines.
>
> Code conventions and formatting guideline are a good thing. However,
> every language (that I'm aware of?) leaves this up to the coder (and
> his team?), or at least allows for flexibility. Having a language that
> enforces a this-is-the-one-true-way seems far less desirable than
> having a standard to be adhered to by the coder.
There are multiple programs used for enforcing strict formatting rules on
C/C++ code.
Josh Benner
On Dec 1, 6:00 pm, "Luke-Jr" <l...@dashjr.org> wrote:
> On Thursday, December 01, 2011 5:49:04 PM Josh Benner wrote:
>
> > > > I'm not even sure how you'd execute the compiled code in a way that
> > > > would give it access to the database.
>
> > > Obviously standard functions and such would all be accessed via a
> > > library.
>
> > See, you're describing a much more fundamental modification than
> > simply removing the decompiler.
>
> Removing the decompiler is not at all simple. It's a fundamental restructure
> of a lot of the MOO server. And builtins are *already* accessed as if via a
> library internally...
decompile_program() is only called by unparse_program().
unparse_program() is only called by:
1. verb_code()
2. dbio_write_program() (and it's forked counterpart)
unparse_program()'s file and err counterparts both simply redirect the
resulting data from unparse_program().
Removing decompiler would seem to only be a matter of refactoring/
replacing unparse_program().
>
> > > > If such an approach was so easy and such a good idea, why don't the
> > > > likes of PHP, Java, Ruby, or Python just compile to machine code?
>
> > > At least Java does behind the scenes. I know Facebook does it for PHP in
> > > house. Python is similar to MOO, in that it compiles to its own bytecode
> > > and interprets it. No idea on Ruby-- don't want to touch that garbage.
>
> > Java compiles to bytecode, which is interpreted by the JVM.
>
> No, the JVM recompiles it to native CPU bytecode.
Apparently you're partially correct -- a couple major versions ago,
Java JVM started selectively compiling code that is hit often in a
class to machine code in the interest of performance. I'd love to hear
details on how you'd imagine implementing machine code compilation of
moo code in a running server, especially related to linking the code
to the rest of the server. However, such an approach, while
potentially beneficial (if more challenging than I think you're
admitting), does not negate nor serve as an argument against the
benefits I've mentioned related to removing the need to decompile MOO
bytecode.
>
> > > > I think MOO might stand to gain from removing the decompiler,
> > > > including:
> > > > 1. Native preservation of code formatting
>
> > > Usually this is a bad thing. There's a reason why every major program has
> > > strict code formatting guidelines.
>
> > Code conventions and formatting guideline are a good thing. However,
> > every language (that I'm aware of?) leaves this up to the coder (and
> > his team?), or at least allows for flexibility. Having a language that
> > enforces a this-is-the-one-true-way seems far less desirable than
> > having a standard to be adhered to by the coder.
>
> There are multiple programs used for enforcing strict formatting rules on
> C/C++ code.
But they are not part of the language itself not the compiler -- they
are developer tools.
Steve Wainstead
> I'm wondering: types other things do people feel might be missing from
> the MOO server?
Users.
And I mean: people who use LambdaMOO, period. I bet there are other people on this mailing list who, like me, can't imagine a life without a MOO. I've belonged to one since 1995 and it has fundamentally affected my life:
* because of the people I've met
* because of the persistence of "place"
* because of the programmability
The biggest motivation for me to start a fork of LambdaMOO was I wanted to see the project continue. The mainline inches forward every now and then, but like Todd pointed out, I wish 1.8.4 would be tagged and released just to tell the world "It's here, it's alive, it's unlike anything else you've used before."
I don't expect I'll ever achieve some of the wizardry that Todd and Luke have done with their forks, but as I've worked on Waverous LambdaMOO my priorities shifted back to my original goals:
* it should be easy for users to use (and program!)
* it should be easy for admins to install and maintain
* it should be easy for hackers to hack on
Because a technology as great as LambdaMOO should have a much larger community of people using it, improving it and evangelizing it.
But more to the point:
I was really disappointed that, when the project moved to Github, only the server/ directory was brought over. The manual was left behind; the project directory is now just the server source code.
To the goal of "easy to install and maintain" I've worked to bring the autotools support up to date; hell, to make it *current* even. We should be able to do this:
./configure && make && sudo make install
and:
sudo make uninstall
This base level of autotools support would make it far easier for Linux distros to have package files; I don't know how many distros have packages for LambdaMOO right now, but thinking on the support for installation as it is (none), there's no room for documentation.
There should be a doxygen configuration file (or whatever the community likes instead) to generate code documentation. This is another step towards making it "easy for hackers to hack on." There should be a man page (or info page or both) for the server.
All the manuals (programmer, database, database programming) should be in the distro along with JHCore, at the very least. LambdaMOO should be usable from the moment 'make' finishes successfully; and it should print out to the newbie how to start the server, login, etc.
Rather than just shipping with Minimal.db, I'd like to see it ship with a FirstWorld.db, which would be akin to the training sessions in video games. It would teach new wizards how to manipulate the world (create rooms, add users, etc).
And as to clients, how about something like the Qt-based IPython shell (edit your MOO code in your terminal window, anyone?):
http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel
Skip to time index 9:00
I think a project born at Xerox Parc has a lot to live up to... and I think the potential of LambdaMOO (or a technology like it) is huge.
~swain
Luke-Jr
> I don't expect I'll ever achieve some of the wizardry that Todd and Luke
> have done with their forks, but as I've worked on Waverous LambdaMOO my
> priorities shifted back to my original goals:
Hey, if you did an actual port to C++, that would be a greater wizardry in
some ways. (Note I don't mean just compiling with G++, but *actually using
only C++*)
> * it should be easy for users to use (and program!)
> * it should be easy for admins to install and maintain
> * it should be easy for hackers to hack on
The MOO server has been all that for years, IMO :)
> I was really disappointed that, when the project moved to Github, only the
> server/ directory was brought over. The manual was left behind; the
> project directory is now just the server source code.
I think you might be confusing CVS modules with directories. There were two
CVS modules, "server" and "manual"; only server has been imported to Git *so
far* (AFAIK). The "manual" module might be a good idea to import too, but I
think wrog should be the one to do it (or sign off on a particular import)...
> To the goal of "easy to install and maintain" I've worked to bring the
> autotools support up to date; hell, to make it *current* even. We should
> be able to do this:
>
> ./configure && make && sudo make install
>
> and:
>
> sudo make uninstall
>
> This base level of autotools support would make it far easier for Linux
> distros to have package files; I don't know how many distros have packages
> for LambdaMOO right now, but thinking on the support for installation as
> it is (none), there's no room for documentation.
Ok yeah, this needs some serious work. Probably a rewrite. But I'm too scared
to break compatibility with all the ancient platforms MOO supports.
> There should be a doxygen configuration file (or whatever the community
> likes instead) to generate code documentation. This is another step
> towards making it "easy for hackers to hack on."
I'm much more comfortable with code than "code documentation", tbh.
> There should be a man page (or info page or both) for the server.
I think Debian has one. I agree it should be imported to the main server tree.
> All the manuals (programmer, database, database programming) should be in
> the distro along with JHCore, at the very least.
Now this I will disagree with. Having documentation separate never hurt
anyone, and not everyone needs it locally. Most people I think are more
comfortable reading it on a website.
I've found myself more and more unsatisfied with all the LambdaCore
derivatives over the years, and think IF a new core (besides Minimal) is to be
bundled (better to keep it separate IMO), it should be something well thought
out and designed from scratch. I don't have the kind of time that would take.
> LambdaMOO should be usable from the moment 'make' finishes successfully; and
> it should print out to the newbie how to start the server, login, etc.
Should a C compiler also be "usable" by including a suite of applications you
can compile and use with it?
Josh Benner
platforms -- yesterday's LambdaMOO can run on those. I think MOO would
do well to simply support the modern *nix family, honestly.
Luke-Jr
> I don't think we need to fear breaking compatibility with ancient
> platforms -- yesterday's LambdaMOO can run on those.
Not if we're talking about breaking compatibility.
Todd Sundsted
That's pretty much what I had in mind. It would be trivial to add to
the server, but in general I'm trying to experiment in-MOO before
building extensions. So here's what I have built in-MOO right now
(Stunt kernel 1.0.5 does _not_ have this, but the next release will --
if anyone really really wants to see this/use this, I'll post a dump
in a gist):
Verb code is stored as-is alongside the bytecode -- this is
_currently_ achieved by simply appending the source as strings to the
end of the code itself, plus some metadata. It's storage inefficient,
but I'm trying out the idea and interface. `set_verb_code()' and
`verb_code()' are redefined to set/get the original source code,
unless the programmer specifically asks for "raw" code. Boom!
Everything just works, the bytecode and source code are kept in one
place, they don't get out of sync, etc.
One piece of metadata I store is the source code "type". This allows
me to run a translator/compiler on the source code before it's
actually compiled into bytecode. I currently use this so that I can
write verbs in mustache, a templating language that I wrote a MOO
compiler for; and/or other experimental moocode++ translators I'm
working on. When I edit a mustache verb, I just @program it like any
other verb, but I write HTML and markup. When I run the verb, it
generates HTML. The kernel takes care of finding and running the
translator, etc. I don't know whether or not that's of use to anyone
else, but it makes my day, everyday!
Interestingly, I think this would be largely a database compatible
change (minus the source code translation bit). The server just reads
and compiles verb code from the text representation in the database,
anyway. We'd need to compute and store line number information for
tracebacks... I'm sure there are other bits and pieces...
Todd
Todd Sundsted
way forward. I'd also take a look back at Self (which seems to be
reinventing itself) -- which wrestled with many of the same problems
MOO has.
Todd Sundsted
> http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectur...
Todd Sundsted
good idea IMHO. If I had more time, I'd do something exactly like
that with Stunt.
On Dec 1, 8:12 pm, "Luke-Jr" <l...@dashjr.org> wrote:
Josh Benner
those for tracebacks?
Todd Sundsted
On Dec 1, 7:52 pm, Steve Wainstead <wainst...@gmail.com> wrote:
> http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectur...
Steve Wainstead
I was really disappointed that, when the project moved to Github, only theserver/ directory was brought over. The manual was left behind; theproject directory is now just the server source code.
I think you might be confusing CVS modules with directories. There were two
CVS modules, "server" and "manual"; only server has been imported to Git *so
far* (AFAIK). The "manual" module might be a good idea to import too, but I
think wrog should be the one to do it (or sign off on a particular import)...
To the goal of "easy to install and maintain" I've worked to bring theautotools support up to date; hell, to make it *current* even. We shouldbe able to do this:./configure && make && sudo make installand:sudo make uninstallThis base level of autotools support would make it far easier for Linuxdistros to have package files; I don't know how many distros have packagesfor LambdaMOO right now, but thinking on the support for installation asit is (none), there's no room for documentation.
Ok yeah, this needs some serious work. Probably a rewrite. But I'm too scared
to break compatibility with all the ancient platforms MOO supports.
LambdaMOO should be usable from the moment 'make' finishes successfully; andit should print out to the newbie how to start the server, login, etc.
Should a C compiler also be "usable" by including a suite of applications you
can compile and use with it?
Jason SW
I agree. Out with the old, in with the new.
Jason.
>>> ./configure&& make&& sudo make install