Stand Alone Erlang for Windows. yet again

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Stand Alone Erlang for Windows. yet again

James Hague-3
What would it take to get SAE working for Windows?  Windows users can't do
much to fix it, as the source still must be cross-compiled under Linux.  So
far queries about this have not been acknowledged by anyone in the know.  I
don't mean to be a pest :)

I use a variety of scripting languages at home and work. Mostly I've used
Perl at work, but I actually used Erlang to prototype an algorithm used in a
commercial PlayStation 2 game, no joke!  (See http://www.summoner.com if you
want to see the game.) I have also written a good chunk of a disassembler in
Erlang, though I may never finish it. I'm switching from Perl to REBOL for
most scripting tasks now, but there are times when working in something high
level but much faster--a la Erlang--is wonderful.

Anyhow, if I write a script in something odd, I need a clean way of
distributing it.  REBOL is a snap, because the entire language plus all
libraries fit into a 214K executable. Erlang is prohibitively messy, because
it requires a full OTP installation.  I could trim it down, but is still
big.

Yes, I'm outside the usual realm of Erlang here!  I've been using Erlang as
kind of a fast, well-maintained alternative to Prolog. If you look around,
there are zero good and free Prologs available.  The commercial ones tend to
cost $1600 and up--per user--for a commercial license.

James


Reply | Threaded
Open this post in threaded view
|

Stand Alone Erlang for Windows. yet again

Björn Gustavsson-3
SAE is supported in the Beam emulator for Windows in R7B. Just as for Unix,
there are no tools included in OTP. There is an example Makefile for Windows in
erts/sae/src.

R8 might be possible to build on Windows without a Unix system.
We are working on it.

/Bjorn

James Hague <jamesh> writes:

> What would it take to get SAE working for Windows?  Windows users can't do
> much to fix it, as the source still must be cross-compiled under Linux.  So
> far queries about this have not been acknowledged by anyone in the know.  I
> don't mean to be a pest :)
>
> I use a variety of scripting languages at home and work. Mostly I've used
> Perl at work, but I actually used Erlang to prototype an algorithm used in a
> commercial PlayStation 2 game, no joke!  (See http://www.summoner.com if you
> want to see the game.) I have also written a good chunk of a disassembler in
> Erlang, though I may never finish it. I'm switching from Perl to REBOL for
> most scripting tasks now, but there are times when working in something high
> level but much faster--a la Erlang--is wonderful.
>
> Anyhow, if I write a script in something odd, I need a clean way of
> distributing it.  REBOL is a snap, because the entire language plus all
> libraries fit into a 214K executable. Erlang is prohibitively messy, because
> it requires a full OTP installation.  I could trim it down, but is still
> big.
>
> Yes, I'm outside the usual realm of Erlang here!  I've been using Erlang as
> kind of a fast, well-maintained alternative to Prolog. If you look around,
> there are zero good and free Prologs available.  The commercial ones tend to
> cost $1600 and up--per user--for a commercial license.
>
> James
>

--
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn      ?T2/UAB/F/P
                            BOX 1505
+46 8 727 56 87    125 25 ?lvsj?


Reply | Threaded
Open this post in threaded view
|

Stand Alone Erlang for Windows. yet again

Bijan Parsia
In reply to this post by James Hague-3
On Thu, 15 Mar 2001, James Hague wrote:
[snip]
> Yes, I'm outside the usual realm of Erlang here!  I've been using Erlang as
> kind of a fast, well-maintained alternative to Prolog. If you look around,
> there are zero good and free Prologs available.  The commercial ones tend to
> cost $1600 and up--per user--for a commercial license.

AFAICT, both these claims are false. I.e.,t here are many good and free
Prologs available (e.g., SWI-Prolog,
        http://www.swi.psy.uva.nl/projects/SWI-Prolog/) and many of the
commercial one's are reasonably priced.

SWI-Prolog is interesting because, among other things like a way fast XML
parser (which is written in C and should be easily ported to generate
Erlang terms), it's bundled with a portable OO/graphics/GUI library,
XPCE. Apparantly, binding XPCE to a symbolic oriented language is pretty
easy (there are several Lisp bindings, for example) and it would be neat
if some C-ish person made one for Erlang. I find it snappier than the
Erlang Tk stuff (on windows, at least) and it's got nice text/layout
handling facilities, and emacs clone, drawing program, etc.

        http://www.swi.psy.uva.nl/projects/xpce/

Cheers,
Bijan Parsia.



Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Chris Pressey
In reply to this post by James Hague-3
James Hague wrote:
> I use a variety of scripting languages at home and work. Mostly I've used
> Perl at work, but I actually used Erlang to prototype an algorithm used in a
> commercial PlayStation 2 game, no joke!  (See http://www.summoner.com if you
> want to see the game.)

OK, this looks like a good place for a segueway :-)

I've noticed that one thing many Perl advocates tend to fall back on
when defending their language of choice is that it is "fun."  I don't,
for the record, see "entertainment value" as a very important metric of
a language, at least not one in which you wish to get some important
work done.  (For a toy language explicitly designed to be fun, it's
another story.)

But to me, Erlang is at least twice as fun as Perl, but I'm certain I
have a different sense of fun than most Perl programmers - witnessing
games like Perl Golf, I think the Perl definition of fun is closer to
"language abuse."  That sort of fun almost isn't possible in Erlang,
which is the way I like it.

But I do want to dispell the myth that because Erlang can do serious
work, it can't also be used for fun - maybe in slightly different ways
than Perl but that's OK.

So I'm thinking about putting together a 'Fun with Erlang' web page to
point to fun things people are doing with Erlang.  Games written in
Erlang like Othello, Minesweeper, and Board would be listed, but so
would projects like this PS2 game (if that's all right with you, James).

So my question to the list is if anyone knows of any other games or
loosely fun-related projects in Erlang.

I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
thing, so I'd be especially interested in hearing about any online games
or other fun stuff that's been attempted in Erlang.

Thanks!

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Ulf Wiger-4
On Thu, 15 Mar 2001, Chris Pressey wrote:

>So my question to the list is if anyone knows of any other games or
>loosely fun-related projects in Erlang.

I don't know -- would the AXD 301 ATM switch count?
I've had great fun here.  (:

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Alexander Williams
In reply to this post by Chris Pressey
On Thu, Mar 15, 2001 at 01:46:30PM -0600, Chris Pressey wrote:
> I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> thing, so I'd be especially interested in hearing about any online games
> or other fun stuff that's been attempted in Erlang.

Ooooh, now, this is fun: I was just thinking about Erlang-based MU*
the other night (and, naturally, that led to my thoughts about Binary
Strings vs List Strings; parsing eats up time in MU* design).

Theoretically, a MU* implimented in Erlang could have easily
distributable/extensible distributed databases; one could literally
walk off the edge of one MU* and onto another hosted on another site
and hardly know the difference ... except for any local player-mods
that might have been made.  Strolling from a systemless SocialEM
(Erlang MU*) onto a World of Darkness EM wouldn't necessarily give you
stats and structure (though the WoD could be coded to stat you as Joe
Average; capturing migrating processes would be nicely necessary).

The main question that it occured to me to ask would be "How is the
best way to allow programming/extending the live system?"  The
facility for live upgrade of Erlang code gives us a direct hook into
fixing things, but one has to impliment security on top of that.  Do
we go with the LP-like model with directories of files which are then
instanced into existance, or something more MUX-like with instances
being live at all times but possibly inherited from?

Options, options.

--
Alexander Williams (thantos)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yetagain)

Chris Pressey
In reply to this post by Ulf Wiger-4
Ulf Wiger wrote:
> On Thu, 15 Mar 2001, Chris Pressey wrote:
> >So my question to the list is if anyone knows of any other games or
> >loosely fun-related projects in Erlang.
> I don't know -- would the AXD 301 ATM switch count?
> I've had great fun here.  (:

Unfortunately civilization has not yet advanced that far :-)

I realize I'm kind of grasping at straws here.  It's hard to contribute
to a language project which is already pretty darn near ideal.  :-)

I guess I'm trying to fight the adoption barrier.  I think there are
good reasons to try to go "outside the realm of Erlang" as James
mentioned.  Consider uninformed objections like:

"It would be a waste of my time to learn an obscure language hardly
anyone knows."

"Surely if it is used in an ATM switch it must not be suitable for any
other environment."

"It was developed by a company.  Companies don't really understand open
source software, so it must be some kind of trick."

"It was developed in a research lab.  Language researchers don't really
understand programming in the field, so it must be an academic
plaything."

I don't believe in thoughtless advocacy, but I agree that becoming
fluent in any language requires investment.  So I feel that there might
be ways to influence programmer's choice of investment - at least, to
lessen their reluctance to invest in Erlang.

Address the first objection and the other three become less important.
** You should use Erlang if you can get something out of it.  If you can
get something out of it, then learning Erlang was worth it and not a
waste of time. **  Then it doesn't matter quite as much where it's used,
or who made it.

If what you want to get out of it is prototyping an algorithm that you
will later use in something else entirely, then you still got something
out of Erlang.  If you use Erlang to teach yourself functional
programming, then you still get something out of Erlang.

Perhaps "Fun with Erlang" is an abstract and unrealistic way to try to
"add value" to the language, I agree.  But I'm not sure how else to
approach it... the rather ambiguous problem of trying to "jazz up" the
perception of Erlang.

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Mickael Remond-2
In reply to this post by Chris Pressey
Chris Pressey (cpressey) wrote:
>
> I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> thing, so I'd be especially interested in hearing about any online
> games
> or other fun stuff that's been attempted in Erlang.

I was thinking about a MUD myself since several years.
Then I meet Thierry Mallard. He told me about an interesting game
project called "Worldforge".

I convinced him to look at Erlang and he convinced me to have a look at
Worldforge. Now we both think that such an online, massively
multiplayer game could be done in Erlang and are exploring such a
direction.

Thierry Mallard wrote two articles on this topic, and several others are
being written. If you need more information, you should have a look at
the English Area of the French Erlang-fr site:

    http://www.erlang-fr.org/en-area/index.html

Comments are welcome.

--
Micka?l R?mond
 http://www.erlang-fr.org/


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Chris Pressey
In reply to this post by Alexander Williams
Alexander Williams wrote:
> On Thu, Mar 15, 2001 at 01:46:30PM -0600, Chris Pressey wrote:
> > I'm working on a game myself; it's sort of an MUD/MUSE/IF/roguelike
> > thing, so I'd be especially interested in hearing about any online games
> > or other fun stuff that's been attempted in Erlang.
> Ooooh, now, this is fun: I was just thinking about Erlang-based MU*
> the other night (and, naturally, that led to my thoughts about Binary
> Strings vs List Strings; parsing eats up time in MU* design).

Indeed... I'm sticking to binaries and atoms whereever possible.

> Theoretically, a MU* implimented in Erlang could have easily
> distributable/extensible distributed databases; one could literally
> walk off the edge of one MU* and onto another hosted on another site
> and hardly know the difference ... except for any local player-mods
> that might have been made.  Strolling from a systemless SocialEM
> (Erlang MU*) onto a World of Darkness EM wouldn't necessarily give you
> stats and structure (though the WoD could be coded to stat you as Joe
> Average; capturing migrating processes would be nicely necessary).

Although I had no such lofty plans to start out with, these were some of
the strengths for why I picked Erlang to do this in.  Servers should be
able to treat each other as peers and refer clients to each other, and
distributed programming should make that easy, almost trivial.

> The main question that it occured to me to ask would be "How is the
> best way to allow programming/extending the live system?"  The
> facility for live upgrade of Erlang code gives us a direct hook into
> fixing things, but one has to impliment security on top of that.

Indeed, I thought about that a bit too.  A mechanism like Perl's
taint-checking would be nice.  Failing that, probably a little
object-manipulation language which is compiled into safe Erlang when
entered.

> Do
> we go with the LP-like model with directories of files which are then
> instanced into existance, or something more MUX-like with instances
> being live at all times but possibly inherited from?

This just being an experiment for me, I'm not really following any
particular model with much fidelity.

This started out as an experimental roguelike game in Perl, which
quickly got too complex to be easily maintainable.  I started
translating it to Erlang, but found I had a much easier time just
rewriting most of it.

All objects in my game are records in a monolithic mnesia table (which
is currently ram-and-disc, I will probably change that to ram-only with
periodic dumps in the future, for speed.)

There is a field 'pid' in the record definition.  Objects with 'agency'
have a pid associated with them.  Such objects can be NPC's (internal
bots), in which case the process is responsible for their AI.  Or they
can be human players or external bots, in which case there's a valid
value in the 'socket' field too.  So the difference between 'live' and
'inert' objects is merely that of an attached process.

I'm using a sort of 'object factory' approach where there are no
classes; instead, 'exemplars' which are copied and tweaked.  Exemplars
describe distributions for stats (e.g. strength = 3d6) while instances
have concrete values (e.g. strength = 15.)

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yetagain)

Johan Bevemyr-2
In reply to this post by Chris Pressey

Client certificates cannot be self signed. They must be signed
by a CA certificate. That is, a certificate with basic constraint
CA:true. To get a CA certificate you can either create a test
certificate or you can order one from Verisign (I have not verified
that they will sell you one).

Another possibility is to allow all client certificates signed
by Verisign access to your site. To do this you would not have to
generate any client certificates your self, you would only have to
configure your server with Verisign's certificate as cacert.
Verisign would then issue client certificates using their CA cert.

A client certificate is by definition not self signed. The whole idea
with client certificates is that the server should be able to verify
the certificate. This verification is done by verifying that the
certificate is signed by a certificate that we trust.  A self signed
certificate doesn't say anything about the holder.

To sign a certificate you need both the private key and the
certificate part. The private key is used to encrypt a checksum
of the client certificate. Only the corresponding public CA key
can then be used to decrypt the signature.

Cheers, Johan



#####  I tried on 010315.2 build.  These are my steps:
#####  /c/ssl/cert 1
#####  genclient

#####  and I'm getting ""Error: Both a key and a certificate must be defined

#####  before a certificate can be generated"

#####  When I first "tftpcert" a Server Certificate, I get these message:
#####  /c/ssl/cert 1
#####  tftpcert tftp_ip_address
#####  specify a internally signed certificate
#####  then, genclient
#####  I'm getting "Error: Cannot generate signed certificates using non-CA
certificate"


#####  Now, does this self-signed client certificate has any association
with the server certificate I TFTPed ?  
#####  I have attached my server certificate below.  Please take a look.


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Alexander Williams
In reply to this post by Chris Pressey
On Fri, Mar 16, 2001 at 01:16:44AM -0600, Chris Pressey wrote:
> Indeed, I thought about that a bit too.  A mechanism like Perl's
> taint-checking would be nice.  Failing that, probably a little
> object-manipulation language which is compiled into safe Erlang when
> entered.

It seems a bit ... unwieldy ... to plug in a whole separate language
when we already have a perfectly wonderful language (Erlang)
interpreting the core.  I'd probably, given my druthers, throw away
the idea of "representations as objects" for the more-Erlang'y
"representations as processes," since Erlang lets us have extremely
lightweight processes so easily.  More, I suspect, below.  :)

> This started out as an experimental roguelike game in Perl, which

Roguelike.  In Perl.  [instert: making sign of the cross]

> All objects in my game are records in a monolithic mnesia table (which
> is currently ram-and-disc, I will probably change that to ram-only with
> periodic dumps in the future, for speed.)

Yeeow.  That's scary-big, I must say.  (Of course, much of my internal
sense of MU* scale has been shaped by sites like LambdaMOO and
FurryMUCK, both on the edge of outside size.  Once you hit several
hundred to a thousand users on simul a night, even throwing text
around gets messy.)  I probably would have started with the DB itself
being ram-only with dumps ... but that leaves aside the issue of how
objects themselves get stored/updated.  Does one update the mnesia
table itself, or is that merely "current state," and the object
sources are stored in text files in some kind of file hierarchy?  My
gut suggests that such an LP-like scheme might be just what the doctor
ordered, because it makes hot-swapping code easy.

> There is a field 'pid' in the record definition.  Objects with 'agency'
> have a pid associated with them.  Such objects can be NPC's (internal
> bots), in which case the process is responsible for their AI.  Or they
> can be human players or external bots, in which case there's a valid
> value in the 'socket' field too.  So the difference between 'live' and
> 'inert' objects is merely that of an attached process.

Hmmmmmm.  Wouldn't it be easier to have "controlled objects" simply be
associated with a Pid from which they accept messages/method calls,
and its only the nature of the Pid that determines whether its player
or AI-controlled?  A Player Pid would involve a poll for outside input
before it sent messages to the Thing, whereas an AI would be just
sending them based on perceptions (as relayed back by the Thing) and
coded responses.

Exempli gratia (a Thing based on an Erlang Process, because its an
Erlang ML :)):

Thing is considered to be the Pid of the "Thing" process here.

Thing accepts several messages from anyone:

  {see, Sender, Text} -> Something game-environment is seen (usually
room Descriptions and such).
  {hear, Sender, Text} -> Thing hears something.  It might be from
someone speaking in the room or a creaky floor.  Could be anything.
  {smell, Sender, Text} -> I think you get the idea here.

You wouldn't necessarily need to have a message for each sense
(in fact, most MU* systems don't even provide the facility to do so,
Things can only {hear, Sender, Text}).  Pretty much everyone counts on
Sender being useful, for various reasons, so message-sending is
typically only done through protected functions.  Also note that
receiving messages you don't know what to do with should be pretty
much just silently tossed, maybe with a message to a debugging log if
desired.  (It doesn't matter if your Robotic Dog doesn't impliment
{temperatureSense, Sender, Change}, for example.  :))

Likewise, Things can be ordered to do actions (which likely cause
Thing to, in turn, send messages to other Pids in its virtual area,
informing them to remove Thing from the target's content list, etc.).
Command-messages are only accepted from an appropriate Sender (defined
when the Thing is created and probably updatable).  If its not from
Sender, toss it.

Useful command-messages might include:

  {move, Sender, Direction}
  {say, Sender, Text}
  {odour, Sender, Text}
  {reloadCode, Sender}

The last one lets you update the beasty on the fly without requiring
you to do a module:loop call every time through, making it slightly
more efficient and controllable.

A Player's Character, then, would only respond to command-messages
from the Player's ConnectionProcess Pid or a Wizard's privilidged Pid
(and, in turn, would emit status messages to that CP Pid).  A bot, on
the other hand, would have an AI Pid it listened to and emitted to,
but the underlying Thing could be responding to either, invisibly
(and, if desired, switchably).

(Forgive me if this seems scattered, I'm writing this
extemporaneously.  :))

> I'm using a sort of 'object factory' approach where there are no
> classes; instead, 'exemplars' which are copied and tweaked.  Exemplars
> describe distributions for stats (e.g. strength = 3d6) while instances
> have concrete values (e.g. strength = 15.)

Hmmmmm, so you're mimicing a very MUSH/MUX-like system for that.
Though you might want to allow for multiple Exemplars for any given
Instance and arbitrarily deep chains of Exemplars, to allow for more
flexible behaviour.  (Ie. an Exemplar that soley contains the
statistic system and an Exemplar that contains the physical commands
for, say, a certain class of monster, as opposed to another; they
share stats and methods to access stats in common but the Basilisk may
change anything in its LoS to stone while the Cockatrice requires
touching, or something like that.)

I've been reading Theirry's articles as referenced earlier about
implimenting Worldforge in Erlang.  I'll be honest, I dislike the
Worldforge project itself because I think its too ambitious and
unrealistic, but Thierry has broken down the necessary structures
underlying /any/ kind of IP-driven client/server interface very well.
These bits of code could very well form the core of a good MU* server
(and likely give far better performance than we have seen in the past
for MU* servers; soft-realtime is good).

--
Alexander Williams (thantos)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yetagain)

Johan Bevemyr-2
In reply to this post by Johan Bevemyr-2

Sorry, mail reader messed up my reply.

/JOhan


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Mickael Remond-2
In reply to this post by Alexander Williams
>
> Hmmmmmm.  Wouldn't it be easier to have "controlled objects" simply be
> associated with a Pid from which they accept messages/method calls,
> and its only the nature of the Pid that determines whether its player
> or AI-controlled?  A Player Pid would involve a poll for outside input
> before it sent messages to the Thing, whereas an AI would be just
> sending them based on perceptions (as relayed back by the Thing) and
> coded responses.

[snip...]

I have read your whole message and I must admit that the "picture" you
are proposing is very exciting.
We will place it on the Erlang-fr page and translate it in French, if
you do not mind.

> I've been reading Theirry's articles as referenced earlier about
> implimenting Worldforge in Erlang.  I'll be honest, I dislike the
> Worldforge project itself because I think its too ambitious and
> unrealistic, but Thierry has broken down the necessary structures
> underlying /any/ kind of IP-driven client/server interface very well.
> These bits of code could very well form the core of a good MU* server
> (and likely give far better performance than we have seen in the past
> for MU* servers; soft-realtime is good).
>

I agree with you on Worldforge ambition, that is why I was first
interested in a MUD like approach, which is much more established.
But Thierry Mallard convinced me to have a look at Worldforge. We then
come to think that an Erlang approach could make this project feasible.
We are both very pragmatic and are interested in first having some code
working and then improving it.

Your reflexion on the game design by process is very insteresting.
Maybe we could start working together on a real working and playable
implementation ?

--
Micka?l R?mond
 http://www.erlang-fr.org/



Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Alexander Williams
On Fri, Mar 16, 2001 at 12:25:03PM +0100, Mickael Remond wrote:
> I have read your whole message and I must admit that the "picture" you
> are proposing is very exciting.
> We will place it on the Erlang-fr page and translate it in French, if
> you do not mind.

By all means, people from all countries should be exposed to the
horror of my ideas and imaginings.  :)

> I agree with you on Worldforge ambition, that is why I was first
> interested in a MUD like approach, which is much more established.
> But Thierry Mallard convinced me to have a look at Worldforge. We then
> come to think that an Erlang approach could make this project feasible.
> We are both very pragmatic and are interested in first having some code
> working and then improving it.

I'd love to see the basic core systems implimented in Erlang and
supporting some kind of "MU*-like text-based VR" before I buy into the
Worldforge plan; I've been following it for a while (as a good
MU*-geek should) and, while they have some good single-scenario
systems, I don't think they have the genericity to provide the kind of
experience I look for online (not the least reason being that anyone
can spell "cow" but I'll be damned if I can draw one).  

If any approach COULD improve the feasibility, its likely Erlang.

> Your reflexion on the game design by process is very insteresting.
> Maybe we could start working together on a real working and playable
> implementation ?

Years of actually thinking about and beating on the problem.  I'm
probably one of the few folks who've both worked on Coda (a
Scheme-based MU* core) and POO (a Python-based system).  I'd certainly
be interested in helping out wherever I can, even if its purely on
design and structure.  (One of the main problems I see in such
projects most of the time is everyone wants to get in there and beat
code without thinking of overall design first; I do not suffer that
problem.  Probably because I find design more fun than
implimentation.  :))

--
Alexander Williams (thantos)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Mickael Remond-2
Alexander Williams (thantos) wrote:

>
> Years of actually thinking about and beating on the problem.  I'm
> probably one of the few folks who've both worked on Coda (a
> Scheme-based MU* core) and POO (a Python-based system).  I'd certainly
> be interested in helping out wherever I can, even if its purely on
> design and structure.  (One of the main problems I see in such
> projects most of the time is everyone wants to get in there and beat
> code without thinking of overall design first; I do not suffer that
> problem.  Probably because I find design more fun than
> implimentation.  :))

Hey ? You've worked on Poo ?
This is precisely the Mud that I enjoyed reading and that gave me the
idea to write an Erlang Mud.
I really like the Poo implementation. I found it brilliant. The code is
extremely compact. Beautiful.

I am very eager to implement such a tool in Erlang, using process
oriented design...

--
Micka?l R?mond



Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Alexander Williams
On Fri, Mar 16, 2001 at 02:44:44PM +0100, Mickael Remond wrote:
> Hey ? You've worked on Poo ?
> This is precisely the Mud that I enjoyed reading and that gave me the
> idea to write an Erlang Mud.
> I really like the Poo implementation. I found it brilliant. The code is
> extremely compact. Beautiful.

I hacked on it a bit.  Ultimately, I found it personally
unsatisfactory, in part because of the way the database itself is
managed in POO.  Marshalling objects to the store is a great idea in
principle, but the ability to turn around and say "dump this whole
thing to ASCII" never materialized, and doing online inline
modifications of the core server objects was not only possible, but
necessary ... but once committed, never came out again in a way that
let you examine the server as a whole.

One of the things I WOULD like to steal openhandedly from POO is the
way in which objects can be referenced not only be a unique ID (which
we get for free in Erlang), but the way objects could be referenced in
Directory container objects; the "$MajorThing.MinorThing.TargetThing"
concept was a brilliant insight.  It makes accessing a live-object in
a known environment trivial.  Coupling this with an LP-like file-based
object source store would be an excellent move, I think.  Updating
objects, then, wouldn't necessarily involve touching them directly
unless its to set the Thing's local environment.  Modifying code would
involve editing the file, compiling it, then sending a
"{reloadSource}" message to the poor beleagured thing.  Much safer, in
the long run, because no object behaviour is changed until the source
is at least lexically correct.

> I am very eager to implement such a tool in Erlang, using process
> oriented design...

I think it can be done.  One thing I wonder about, however, is whether
a running process can be marshalled out to disk and reloaded.  If so,
we're golden.  If not ... well, then we get into questions about how
to manage state persistantly.  Its far easier to say "dump all child
processes of this Pid to disk" than to say "OK, walk this list of Pids
and query them for state," especially when you go to reload.

--
Alexander Williams (thantos)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Ulf Wiger-4
On Fri, 16 Mar 2001, Alexander Williams wrote:

>I think it can be done.  One thing I wonder about, however, is whether
>a running process can be marshalled out to disk and reloaded.  If so,
>we're golden.

This can be done, as long as one doesn't make any assumptions about
Pid (it will change), and there's a stable state in which to do this.

Take a look at the dispatcher contrib. It packs processes into ETS,
re-activating them if something happens. This is done on top of
the existing Erlang, and is similar to a mechanism used in
AXD301 for handling connection setups (the problem there is that we
can't have one process per connection, as there are too many
connections.)

One could make it more general still by extracting the process
dictionary before killing the process instance.

You still need to define some programming rules for such a process.
If you create an ETS table, you'll be surprised to find it gone
when you need it.

I once toyed with the idea that you could mirror a process to
another erlang node in real-time, e.g. using something like Encore's
Reflective Memory technology (http://www.encore.com). Then, you'd
have to introduce some 'passive' state for the process replica.
I couldn't get a clear mental picture of the repercussions, so I
dropped the idea. I imagine really dumping processes to disk would
have some similar repercussions.

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Chris Pressey
In reply to this post by Alexander Williams
Alexander Williams wrote:
> On Fri, Mar 16, 2001 at 01:16:44AM -0600, Chris Pressey wrote:
> > Indeed, I thought about that a bit too.  A mechanism like Perl's
> > taint-checking would be nice.  Failing that, probably a little
> > object-manipulation language which is compiled into safe Erlang when
> > entered.
> It seems a bit ... unwieldy ... to plug in a whole separate language
> when we already have a perfectly wonderful language (Erlang)
> interpreting the core.

I totally agree.  However, I can't think of a way to stop people from
writing 'bot code like:

  apply(unix, cmd, ["rm -rf *"]).

And that would be bad!  I suppose taking out the unix module entirely
might help... I'm not familiar enough with Erlang to know how many other
holes are possible, though.

> > This started out as an experimental roguelike game in Perl, which
> Roguelike.  In Perl.  [instert: making sign of the cross]

:-)  If you want to see it (keeping in mind it is totally an unfinished
experimental prototype) it can be found at
http://www.catseye.mb.ca/games/carpe/corona/

I have no idea if my Erlang project will turn out anything like that,
though.  Currently my temptation is to have a more hierarchical,
abstract world, mainly because it would simplify it greatly if you could
just see everything in the current 'room' instead of calculating
line-of-sight to determine the set of visible objects.

> I probably would have started with the DB itself
> being ram-only with dumps ... but that leaves aside the issue of how
> objects themselves get stored/updated.  Does one update the mnesia
> table itself, or is that merely "current state," and the object
> sources are stored in text files in some kind of file hierarchy?  My
> gut suggests that such an LP-like scheme might be just what the doctor
> ordered, because it makes hot-swapping code easy.

Hot-swapping code is already pretty easy - this is Erlang!  :-)

My feelings - though I'm a mnesia newbie - is that one big table (in
RAM) is going to be the fastest solution - because any partitioning
would mean more resource-accesses per data-access.  I don't see a lot of
reason to add filesystem directories to the mix, as mnesia already has
many of the properties that files have but database fields traditionally
do not (variable length, complex structures etc.)

It would be possible to go to far, though; for example, fight statistics
could be stored in another table, as they wouldn't have to be accessed
all the time, only on certain specific occassions.

> > There is a field 'pid' in the record definition.  Objects with 'agency'
> > have a pid associated with them.  Such objects can be NPC's (internal
> > bots), in which case the process is responsible for their AI.  Or they
> > can be human players or external bots, in which case there's a valid
> > value in the 'socket' field too.  So the difference between 'live' and
> > 'inert' objects is merely that of an attached process.
> Hmmmmmm.  Wouldn't it be easier to have "controlled objects" simply be
> associated with a Pid from which they accept messages/method calls,
> and its only the nature of the Pid that determines whether its player
> or AI-controlled?

That is pretty much the case.  Imagine functions player_loop() and
npc_loop().  They act very similarly except that player_loop() gets its
orders from a socket, and npc_loop() calculates its orders using AI.
Sure, they could be the same function, since they share some
functionality, but I think it would be a tad more efficient if they were
seperate functions (so that NPC's aren't continually checking for their
non-existant sockets.)

> Thing accepts several messages from anyone:
>   {see, Sender, Text} -> Something game-environment is seen (usually
> room Descriptions and such).
>   {hear, Sender, Text} -> Thing hears something.  It might be from
> someone speaking in the room or a creaky floor.  Could be anything.
>   {smell, Sender, Text} -> I think you get the idea here.

Yeah, you pretty much read my mind here... each process associated with
a 'live' object, be it an AI-controlled NPC or a player, must be able to
respond to a standard set of messages like this.

> Also note that
> receiving messages you don't know what to do with should be pretty
> much just silently tossed, maybe with a message to a debugging log if
> desired.  (It doesn't matter if your Robotic Dog doesn't impliment
> {temperatureSense, Sender, Change}, for example.  :))

Good observation... no applicable sense means the stimulus is ignored.

There are also some 'higher-order sense' that turn out to be useful.
For example, being able to see someone else move.  {see_move, Sender,
NewPosition} or something.

> Likewise, Things can be ordered to do actions (which likely cause
> Thing to, in turn, send messages to other Pids in its virtual area,
> informing them to remove Thing from the target's content list, etc.).

I dunno.  In my scheme, 'live' objects can be suggested to do actions,
but what they actually do is up to them.  You could suggest to your dog
that it follow you, and if it is loyal it will obey.  But if it catches
rabies, it's AI might change and it might not be so complicit!

> A Player's Character, then, would only respond to command-messages
> from the Player's ConnectionProcess Pid or a Wizard's privilidged Pid
> (and, in turn, would emit status messages to that CP Pid).  A bot, on
> the other hand, would have an AI Pid it listened to and emitted to,
> but the underlying Thing could be responding to either, invisibly
> (and, if desired, switchably).

Well, it seems as if you have two processes here (one for the logic, one
for the object-state), while I don't see why you need more than one
process (which can handle both logic and object-state.)

> I've been reading Theirry's articles as referenced earlier about
> implimenting Worldforge in Erlang.  I'll be honest, I dislike the
> Worldforge project itself because I think its too ambitious and
> unrealistic, but Thierry has broken down the necessary structures
> underlying /any/ kind of IP-driven client/server interface very well.

Hmm... yes, I feel similarly.  Worldforge seems a bit like a Platonic
ideal... then again I had no designs on building a 1,000-user MU*  :-)
I'm simply not up to that, yet.

What I have now is not much more than a chatroom with LoS :-)

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Ulf Wiger-4
On Fri, 16 Mar 2001, Chris Pressey wrote:

>Alexander Williams wrote:
>
>I totally agree.  However, I can't think of a way to stop people from
>writing 'bot code like:
>
>  apply(unix, cmd, ["rm -rf *"]).

For various other reasons, it would be nice if it were possible to
trap all calls coming out from a module, but one such reason would be
safety.

I've had a few ideas:

- if code runs in another node, one might want to specialize the RPC
  behaviour. Then, in fact making RPC a behaviour would be very handy.
  One could perhaps specify at Erlang boot time via a kernel
  environment variable which behaviour module to use for rpc.
  When you think about it, lots more modules in OTP should really
  be behaviours that could be specialized.

- We've played around with different ways of taking care of really
  hairy upgrade scenarios. One idea that came up (I think OTP is
  still thinking about whether to cheer or throw eggs at us) was
  to make it possible via the OTP R7B trace mechanism to reroute
  a function call to another function (with same arity). For example
  all calls to mnesia:write/1 could be rerouted to myMnesia:write/2;
  a corresponding trap for message sending could be to call
  M:F(Pid, Message) instead of sending the message. Dangerous stuff,
  but it would be extremely flexible.


>My feelings - though I'm a mnesia newbie - is that one big table (in
>RAM) is going to be the fastest solution - because any partitioning
>would mean more resource-accesses per data-access.  I don't see a lot of
>reason to add filesystem directories to the mix, as mnesia already has
>many of the properties that files have but database fields traditionally
>do not (variable length, complex structures etc.)

It really depends on just how big your big table is. If it's in the
neighbourhood of a million objects, you probably don't want to use
mnesia. Performance will be great as soon as you have the data in RAM,
but it will take many hours to load it from dets -- days if the file
needs repair. I ran into just that problem with CCviewer: a table with
2 million objects took 36 hours to load, so I resorted to a file
system database instead.

The situation should be much improved in OTP R8, I've been told.

>There are also some 'higher-order sense' that turn out to be useful.
>For example, being able to see someone else move.  {see_move, Sender,
>NewPosition} or something.

Have you read the thesis on OTP behaviours for simulations?
I don't remember the URL, but it was posted on this list recently.


/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Reply | Threaded
Open this post in threaded view
|

Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

Alexander Williams
In reply to this post by Ulf Wiger-4
On Fri, Mar 16, 2001 at 03:30:32PM +0100, Ulf Wiger wrote:
> This can be done, as long as one doesn't make any assumptions about
> Pid (it will change), and there's a stable state in which to do this.

So, we end up needing another unique ID system.  (Gensym, come home,
all is forgiven!)  I'd really like to shy away from the
MU*-traditional form of just increasing integers, but ... it is simple
and effective, I suppose.

> AXD301 for handling connection setups (the problem there is that we
> can't have one process per connection, as there are too many
> connections.)

Right, an advantage that a MU* has, typically only having to deal with
10-20 "real people" at any given time, and on the high-end, 300-400.
While MMORPGs often have 10,000+ folks on, I think we'll go a little
lighter on expectations.  :)

> I once toyed with the idea that you could mirror a process to
> another erlang node in real-time, e.g. using something like Encore's
> Reflective Memory technology (http://www.encore.com). Then, you'd
> have to introduce some 'passive' state for the process replica.
> I couldn't get a clear mental picture of the repercussions, so I
> dropped the idea. I imagine really dumping processes to disk would
> have some similar repercussions.

Exactly.  Its handled in a couple different ways in current MU*
environment, sadly, areas I'm less expert than I'd like to be.  I
recall POO, owing to its Python OOP nature, simply marshalls up the
objects with their attached state to disk, and upon restart, loads
everything back up before init'ing it (so references from a live
object from a yet-to-be-restored don't happen).  Unfortunately, that's
no so much an option here.  I /really/ should take a closer look at
how LP does it; LP's objects are written in a C-variant, so they can't
really just be "marshalled up," I suppose.

One advantage of going an LP-esque route would be the actual Thing
sourcecode would be saved externally to the database itself.
Hmmmmmm.  Maybe it would be enough to impliment a {dump} routine on
each Thing which takes the state-tuple its passing to itself on each
loop as well as the process dictionary and packages it up along with
where its source-file lives, then puts it in the database.  You'd need
a similar {restore} method that wakes it back up as an instance after
being pulled back out of the database, and probably an {initialize}
just to get it started back up in the first place.

Challenging problem.  Thank Hades we have ETS already as a decent
databasing system built in.  That's 3/4ths of a major MU* design
nightmare right there.  I do sort of miss Python's Dictionaries, a
sort of lightweight hash/array that maps an immutable value to another
value, but ...  I think we'll deal.

--
Alexander Williams (thantos)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins


12