Erlang/OTP Forums
Author Message

<  Erlang questions mailing list  ~  Stand Alone Erlang or Equivalent
Guest
Posted: Tue Sep 04, 2007 4:30 am Reply with quote
Guest
I was wondering if anyone has actually made progress/headway into the
"stand alone erlang" problem/feature?

I am currently using Erlang for a variety of minor, yet high-concurrency
tasks on our servers. I am currently looking into moving some of our
more complex/CPU-intensive tasks to Erlang as well. And for these tasks,
Erlang/CEAN/OTP distribution method is just fine (not my preferred, but
that is only a matter of taste).

However, I have been talking to a few busy individuals who (inspired by
Tim Sweeney's latest talk) are looking at high-concurrency
languages/executable frameworks for "client-side" game/simulation
execution. They asked me which one I would recommend, and I (of course)
mentioned Erlang. To which their immediate reply was "Yeah, it looks
good - but the deployment is to much of a hassle for general game players".

So I was wondering if I could impress them with some news on the Stand
Alone Erlang front. In a related question, how easy is it to retrieve
code/beams from non-file based sources (e.g. from an embedded native
code database or zip file)?

Thanks for any feedback you might have on this...
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Tue Sep 04, 2007 9:23 am Reply with quote
Guest
On 04/09/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
> So I was wondering if I could impress them with some news on the Stand
> Alone Erlang front. In a related question, how easy is it to retrieve
> code/beams from non-file based sources (e.g. from an embedded native
> code database or zip file)?
>

code:load_binary/3 lets you load a module using a binary blob. This
might be useful.

cheers
Chandru
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
axel
Posted: Tue Sep 04, 2007 10:27 am Reply with quote
User Joined: 03 Mar 2005 Posts: 271
It is easy to load a beam file from non-file based sources. i have a
self-extracting-and-run-archive (i call it besea) that uses escript, if
you are interested.


bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."


On 2007-09-04 10:54, Chandru wrote:
> On 04/09/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
>> So I was wondering if I could impress them with some news on the Stand
>> Alone Erlang front. In a related question, how easy is it to retrieve
>> code/beams from non-file based sources (e.g. from an embedded native
>> code database or zip file)?
>>
>
> code:load_binary/3 lets you load a module using a binary blob. This
> might be useful.
>
> cheers
> Chandru
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top View user's profile Send private message
Guest
Posted: Wed Sep 05, 2007 4:28 am Reply with quote
Guest
I am interested in this, yes. Does it require an installation of erlang
to be present or is it "self contained" (i.e. you send the
self-extracting/self-running archive and it does the rest)?

SAE (discontinued since R9 I believe) has the best implementation I have
seen, with the single file being all that was required in order to run
an Erlang application/server. If Joe were ever to get this back into
working order - he would have many grateful fans (over and above those
of his book *grin*)

Regards,
B.J.Tolputt



Bengt Kleberg wrote:
> It is easy to load a beam file from non-file based sources. i have a
> self-extracting-and-run-archive (i call it besea) that uses escript, if
> you are interested.
>
>
> bengt
> Those were the days...
> EPO guidelines 1978: "If the contribution to the known art resides
> solely in a computer program then the subject matter is not
> patentable in whatever manner it may be presented in the claims."
>
>
> On 2007-09-04 10:54, Chandru wrote:
>
>> On 04/09/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
>>
>>> So I was wondering if I could impress them with some news on the Stand
>>> Alone Erlang front. In a related question, how easy is it to retrieve
>>> code/beams from non-file based sources (e.g. from an embedded native
>>> code database or zip file)?
>>>
>>>
>> code:load_binary/3 lets you load a module using a binary blob. This
>> might be useful.
>>
>> cheers
>> Chandru
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>

_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 6:02 am Reply with quote
Guest
On 9/4/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
> I am interested in this, yes. Does it require an installation of erlang
> to be present or is it "self contained" (i.e. you send the
> self-extracting/self-running archive and it does the rest)?
>
> SAE (discontinued since R9 I believe) has the best implementation I have
> seen, with the single file being all that was required in order to run
> an Erlang application/server. If Joe were ever to get this back into
> working order - he would have many grateful fans (over and above those
> of his book *grin*)
>

Out of curiosity, what's the problem with a CEAN style solution? It's
a standalone environment that you can move anywhere on the filesystem
and it should still work. Other than the naming of the directories,
it's not much different than how Mac OS X applications are packaged,
and nobody really complains about that.

-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
axel
Posted: Wed Sep 05, 2007 6:06 am Reply with quote
User Joined: 03 Mar 2005 Posts: 271
besea is not self containied. it uses escript via the unix #! script
hack(*). so you need a unix system with an installed escript. if this
works on windows i will try to get escript into CEAN.


(*) tmi: if the first 4 charactes of a file are #! / or (on most
systems) the first 3 charactes are #!/, then the kernel will try to use
that file as an interpreter for the file. the kernel uses 32 characters
starting from /, or (on most systems) all characters until end of line.


bengt
Those were the days...
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."


On 2007-09-05 06:24, Benjamin Tolputt wrote:
> I am interested in this, yes. Does it require an installation of erlang
> to be present or is it "self contained" (i.e. you send the
> self-extracting/self-running archive and it does the rest)?
>
> SAE (discontinued since R9 I believe) has the best implementation I have
> seen, with the single file being all that was required in order to run
> an Erlang application/server. If Joe were ever to get this back into
> working order - he would have many grateful fans (over and above those
> of his book *grin*)
>
> Regards,
> B.J.Tolputt
>
>
>
> Bengt Kleberg wrote:
>> It is easy to load a beam file from non-file based sources. i have a
>> self-extracting-and-run-archive (i call it besea) that uses escript, if
>> you are interested.
>>
>>
>> bengt
>> Those were the days...
>> EPO guidelines 1978: "If the contribution to the known art resides
>> solely in a computer program then the subject matter is not
>> patentable in whatever manner it may be presented in the claims."
>>
>>
>> On 2007-09-04 10:54, Chandru wrote:
>>
>>> On 04/09/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
>>>
>>>> So I was wondering if I could impress them with some news on the Stand
>>>> Alone Erlang front. In a related question, how easy is it to retrieve
>>>> code/beams from non-file based sources (e.g. from an embedded native
>>>> code database or zip file)?
>>>>
>>>>
>>> code:load_binary/3 lets you load a module using a binary blob. This
>>> might be useful.
>>>
>>> cheers
>>> Chandru
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@erlang.org
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top View user's profile Send private message
Guest
Posted: Wed Sep 05, 2007 7:43 am Reply with quote
Guest
Bob Ippolito wrote:
> Out of curiosity, what's the problem with a CEAN style solution? It's
> a standalone environment that you can move anywhere on the filesystem
> and it should still work. Other than the naming of the directories,
> it's not much different than how Mac OS X applications are packaged,
> and nobody really complains about that.
>
> -bob
>
The problem is that the CEAN distribution requires the user to extract
files to a directory tree THEN run a separate executable. For servers
and so on (which generally require some form of "setup" to install
anyway) this is not an issue, but for game development (the area of
development the guys are working in) this is not so good (impatient,
technically inexperienced user base).

Something along the lines of a Py2EXE would be ideal. Py2EXE zips and
concatenates the required Python ".pyd" (i.e. Python's equivalent to
"beam" files) to the end of an executable stub. This executable stub
knows that it needs to retrieve the required code files (or in our case
Erlang "beam" files) from the compressed archive at the end of the file
rather than from the local file-system.

The way I would do it (if I were coding the solution) would be to have
an Erlang BEAM VM executable which is hard-coded to look for the
essential files from the end of itself (i.e the appended "BEAM" file
archive). These BEAM files would then setup the internal Erlang
environment to be able to load modules/beam files & DLL's from game
specific locations and/or file formats (i.e. the BEAM's could be
encrypted or compressed).

As I am a Windows-based developer - this is a little hard for me to
contemplate doing as having to setup Cygwin on my dual-boot
Windows/Linux development machine seems a little redundant (but
necessary to compile the Erlang runtimes). If/when Erlang is fully
compilable using MSVC or GCC alone - then I will be happy to work on it.

Regards,
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 8:17 am Reply with quote
Guest
Hi,

On 9/4/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
> I was wondering if anyone has actually made progress/headway into the
> "stand alone erlang" problem/feature?
>
> I am currently using Erlang for a variety of minor, yet high-concurrency
> tasks on our servers. I am currently looking into moving some of our
> more complex/CPU-intensive tasks to Erlang as well. And for these tasks,
> Erlang/CEAN/OTP distribution method is just fine (not my preferred, but
> that is only a matter of taste).
>
> However, I have been talking to a few busy individuals who (inspired by
> Tim Sweeney's latest talk) are looking at high-concurrency
> languages/executable frameworks for "client-side" game/simulation
> execution. They asked me which one I would recommend, and I (of course)
> mentioned Erlang. To which their immediate reply was "Yeah, it looks
> good - but the deployment is to much of a hassle for general game players".

I think you and many others discussing Standalone Erlang are mixing up
things here. The important thing for end user deployment is that it is
easy and quick
to install and uninstall a SW package and that does not imply that for
example all the beam files must be packed together in one or a few
bigger files.
As long as the installation is distributed as e.g a self extracting
and self installing exe file (Windows) it should be ok.
Of course this package should only contain the beam files from OTP
that are actually used plus the specific .beam files for the SW in
question.

>
> So I was wondering if I could impress them with some news on the Stand
> Alone Erlang front. In a related question, how easy is it to retrieve
> code/beams from non-file based sources (e.g. from an embedded native
> code database or zip file)?
We have already implemented (but not released) code loading from ZIP archives.

We are working on "standalone" features but I can not promise today when we
will release something.


Erlang/OTP as available today as open source is a DEVELOPMENT SYSTEM
which the developer uses to create a TARGET SYSTEM. The target system
can be a simple standalone application to be installed on many clients
or it can be
a complex distributed embedded server system.

To create the target system you need the following:
1) Know what parts of Erlang/OTP you need in the target app.
You can pick OTP components on complete application level i.e. stdlib,
kernel, mnesia etc. which is easy. Or you can try to remove unused
modules even from stdlib, kernel etc. which is more tricky and
requires a lot more knowledge about dependencies.
2) Know your own target specific SW.
Must be obvious.
3) Pack 1 and 2 together in a distribution.
You can pack together all resulting files and directory hierarchies
just as they are.
Or you can try to create something which result in just a few files
when installed (e.g. beam files packed together, one per OTP
application or one for all .beam files)
4) Installation script or other SW run at install time
You can for example use NSIS (free and we use it now) for Windows or
something else.
For other OS:es you need something else.

We will primarily address 1 and 3 above and probably offer several
alternatives for
doing them.
We will not take the SAE approach exactly as the one Joe Armstrong did because
we have found several difficulties in maintaining that solution.

/Kenneth (Erlang/OTP team at Ericsson)



>
> Thanks for any feedback you might have on this...
> B.J.Tolputt
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 4:17 pm Reply with quote
Guest
On 9/5/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
> Bob Ippolito wrote:
> > Out of curiosity, what's the problem with a CEAN style solution? It's
> > a standalone environment that you can move anywhere on the filesystem
> > and it should still work. Other than the naming of the directories,
> > it's not much different than how Mac OS X applications are packaged,
> > and nobody really complains about that.
> >
> > -bob
> >
> The problem is that the CEAN distribution requires the user to extract
> files to a directory tree THEN run a separate executable. For servers
> and so on (which generally require some form of "setup" to install
> anyway) this is not an issue, but for game development (the area of
> development the guys are working in) this is not so good (impatient,
> technically inexperienced user base).
>
> Something along the lines of a Py2EXE would be ideal. Py2EXE zips and
> concatenates the required Python ".pyd" (i.e. Python's equivalent to
> "beam" files) to the end of an executable stub. This executable stub
> knows that it needs to retrieve the required code files (or in our case
> Erlang "beam" files) from the compressed archive at the end of the file
> rather than from the local file-system.

I don't buy it. I never see files distributed online as a single
".exe" file unless it's an installer. More often it's either as a zip
or a msi, either of which will carry multi-file payloads just fine.

-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 5:38 pm Reply with quote
Guest
While not strictly necessary, there is still some advantage of having a
single, monolithic executable. For example, upgrading could be that much
easier, and so is deployment (just run the .exe).

Until the day of SAE is resurrected, I think the approach by Wings 3D
works well. I installed it a few weeks ago and I think it would be a
simple matter to reuse their packaging; just replacing the Wings 3D code
with your own code.

CEAN should work the same way too, I just haven't seen a standalone app
distributed with CEAN yet. I also considered CEAN as a deployment
packaging, but it seems to have a lot of files, especially on windows,
and I wasn't clear to me (with my limited understanding), which was
needed and which could be stripped out.

Peter

-----Original Message-----
From: erlang-questions-bounces@erlang.org
[mailto:erlang-questions-bounces@erlang.org] On Behalf Of Bob Ippolito
Sent: Wednesday, September 05, 2007 11:14 AM
To: Benjamin Tolputt
Cc: erlang-questions@erlang.org
Subject: Re: [erlang-questions] Stand Alone Erlang or Equivalent

On 9/5/07, Benjamin Tolputt <bjt@pmp.com.au> wrote:
> Bob Ippolito wrote:
> > Out of curiosity, what's the problem with a CEAN style solution?
It's
> > a standalone environment that you can move anywhere on the
filesystem
> > and it should still work. Other than the naming of the directories,
> > it's not much different than how Mac OS X applications are packaged,
> > and nobody really complains about that.
> >
> > -bob
> >
> The problem is that the CEAN distribution requires the user to extract
> files to a directory tree THEN run a separate executable. For servers
> and so on (which generally require some form of "setup" to install
> anyway) this is not an issue, but for game development (the area of
> development the guys are working in) this is not so good (impatient,
> technically inexperienced user base).
>
> Something along the lines of a Py2EXE would be ideal. Py2EXE zips and
> concatenates the required Python ".pyd" (i.e. Python's equivalent to
> "beam" files) to the end of an executable stub. This executable stub
> knows that it needs to retrieve the required code files (or in our
case
> Erlang "beam" files) from the compressed archive at the end of the
file
> rather than from the local file-system.

I don't buy it. I never see files distributed online as a single
".exe" file unless it's an installer. More often it's either as a zip
or a msi, either of which will carry multi-file payloads just fine.

-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 7:29 pm Reply with quote
Guest
On 9/5/07, Bob Ippolito <bob@redivi.com> wrote:
> I don't buy it. I never see files distributed online as a single
> ".exe" file unless it's an installer. More often it's either as a zip
> or a msi, either of which will carry multi-file payloads just fine.

IME, most of those times, the ".exe" is a CAB file with a
self-extracting header, anyway, which is another multi-file archive
format from Microsoft. Almost all non-trivial applications today have
multiple files that need to be distributed and installed, so I'm
personally with Bob on this one. On the other hand, I do have to say
that py2exe is great and easy to work with, especially for a
non-Windows guy like myself. Having something like this for Erlang
wouldn't suck.

--
Toby DiPasquale
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 7:54 pm Reply with quote
Guest
On 9/5/07, Toby DiPasquale <codeslinger@gmail.com> wrote:
> On 9/5/07, Bob Ippolito <bob@redivi.com> wrote:
> > I don't buy it. I never see files distributed online as a single
> > ".exe" file unless it's an installer. More often it's either as a zip
> > or a msi, either of which will carry multi-file payloads just fine.
>
> IME, most of those times, the ".exe" is a CAB file with a
> self-extracting header, anyway, which is another multi-file archive
> format from Microsoft. Almost all non-trivial applications today have
> multiple files that need to be distributed and installed, so I'm
> personally with Bob on this one. On the other hand, I do have to say
> that py2exe is great and easy to work with, especially for a
> non-Windows guy like myself. Having something like this for Erlang
> wouldn't suck.
>

Yeah, I agree that py2exe is nice. I wrote the equivalent of py2exe
for Mac OS X (py2app). However, I don't think that py2exe is really
measurably better now that it produces a single exe than it used to be
when it produced a three (or more) file distribution (bare minimum of
app exe, python dll, library zip). I know that people constantly asked
for the single file feature until it eventually happened, but I really
don't see very many other single file apps.

-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 8:50 pm Reply with quote
Guest
A stand-alone executable is very useful for putting on a USB thumb drive. I
keep a lot of utilities on my USB drive that I can plug in wherever I go.
Imagine being able to stick your USB drive into any Windows PC and firing up
Erlang.

Cheers,

David

_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
Guest
Posted: Wed Sep 05, 2007 9:06 pm Reply with quote
Guest
Bob Ippolito wrote:
> I don't buy it. I never see files distributed online as a single
> ".exe" file unless it's an installer. More often it's either as a zip
> or a msi, either of which will carry multi-file payloads just fine.
>
It need not be a "single file executable" (though this is preferable
given the methods of "copyright protection" employed by game
publishers), but requiring a "directory tree" is a pain to manage simply
for the underlying language.

Take a look at the deployment/file tree of most commercially released
games. They have a very simple tree usually consisting of a "root"
having all executable files with their DLL's, a data directory (with
generally a handful of "archive" files collating & compressing the game
resources), and a save file directory. It has only been open-source
(i.e. non-commercial) games & applications that have used the default
"deployment directory tree" used by Python, Erlang, and other languages
without compressing &/or somehow collating the files.

For open-source &/or server applications needing to be easily updated,
being able to access the individual files is a good thing. However,
games (and a variety of other application deployments) are meant to be
"solid" when delivered. This means delivering as simple & compact a
deployment tree as possible. This may or may not be the best practice as
far as us "server developers" go, but this is standard practice in the
game development.

Being able to have a single executable with one or two other files would
also be good. It is just my belief (right or wrong) that if we are going
this far, we may as well make it a single executable.

Regards,
B.J.Tolputt
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist
Back to top
vladdu
Posted: Wed Sep 05, 2007 9:11 pm Reply with quote
User Joined: 28 Feb 2005 Posts: 397 Location: Gothenburg, Sweden
Hi,

On 9/5/07, David Mercer <dmercer@gmail.com (dmercer@gmail.com)> wrote:
Quote:
A stand-alone executable is very useful for putting on a USB thumb drive.
Back to top View user's profile Send private message

Display posts from previous:  

All times are GMT
View next topic
View previous topic
Page 1 of 3
Goto page 1, 2, 3  Next
Erlang Forum - Trap Exit Forum Index  ~  Erlang questions mailing list
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
Hosted by Erlang Solutions    |    Powered by phpBB and NoseBleed 1.14