FYI: Rewriting Playdar: C++ to Erlang, massive savings

[Angel Alvarez]

Another erlang success history...

http://www.metabrew.com/article/rewriting-playdar-c-to-erlang-massive-savings/

interesting fact is people misses having a tiny erlang distributable.

I think erlang is more than de VM alone,
what's the size of a comparable java setup (including OTP-like functionality)?

another problems arises from the concept of having one erlang setup for each package we install on the system.

"...Packaging an Erlang app for the desktop involves taking the installed VM directory structure
and stripping out all the docs, source and parts of the Erlang stdlib we don’t use, then packaging
it along with the compiled Playdar code. CouchDB does something like this too, and RabbitMQ
ships the Erlang VM without stripping unneeded libs..."


Well, erlang installs should detect prior erlang installations and boot from those setups without duplicating
erlang dists whenever oyu install a new erlang app.

Fortunaley (IMHO) these guys think the same after all:

"...We’ll put together a Windows installer soon that’ll probably be around the same size. A 10MB download
isn’t so bad nowadays, and I expect we can optimize the packaging process some more. Linux users will get
a package that depends on the erlang VM in their package manager. Seems like shipping Erlang apps to the
desktop isn’t so hard after all."


/angel
--
Agua para todo? No, Agua para Todos.
->>-----------------------------------------------
    Clist UAH a.k.a Angel
---------------------------------[www.uah.es]-<<--

Los dinosaurios murieron porque no tenían un programa espacial. Larry Niven.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Antoine Koener]

> "...We’ll put together a Windows installer soon that’ll probably be around
> the same size. A 10MB download
> isn’t so bad nowadays, and I expect we can optimize the packaging process
> some more. Linux users will get
> a package that depends on the erlang VM in their package manager. Seems
> like shipping Erlang apps to the
> desktop isn’t so hard after all."
>
>
Thanks, interesting read


I'm now building a windows installer to deploy some erlang application, and
here's problems that takes a lot of time
to fix.

 Erlang for windows (R13B) needs some versions of the VC++ 2005 Runtime.
(msvcr80.dll)
Unfortunately the only way the find which one is to read the last part of
the file "erl.exe" for example and extract information related to its
"manifest".
There you will find that you need the VC++ 2005-SP1 runtime.
(And I think that with R12B this was not the case)


The crypto_drv.dll needs the openssl "ssleay32.dll" to be installed. If it's
not the case you won't be able to use anything
related to crypto... And thanks to windows dll Hell problem, you need to put
this dll in \windows\system32 [ SystemFolder ],
making the package uninstallation not really "nice" because you may remove
this file, breaking other apps...

 Erlsrv is not really efficient, since your service may no longer be in
place but still in the erlsrv registry key, you won't be able
to reinstall it. Windows XP comes with tools like 'sc' that is able to set
and configure a service.
Erlsrv with "cmd.exe loves to break your double quotes" is absolutely not
convenient.
(I know that there's a new version of it, I didn't tested it for the moment,
so maybe this part is no longer valid)

There's two "bin" directories, which one is the "one" ?
Same question with erl.ini.
erl.ini: should contains good directory names but you can't use the single
'\' because your path will not be valid :(


While using the NSIS installer version is nice to install erlang for testing
purpose, massively deploying it, is not possible using
what windows admins are used to i.e. group policy and .msi files. (providing
silent or "unattended" deployments)

I'm using makemsi[1] to build a .msi package to deploy my windows app, while
difficult to use, it works almost flawlessly.
I'll be glad to share my experience with anyone.

Finally my point is that under windows Erlang is difficult to repackage.
May be we should take time to make it completely autonomous ? ( including
every dependencies needed )
Then you may say, what about dependencies upgrades ?  ( openssl
vulnerability or else )
I will say that I've no good answers to this question :p

I'm not pushing for massive adoption of Erlang but I think that if anyone is
able to repackage its erlang app for windows and
making it full automatic deployment compatible, erlang and erlang based apps
may spread a lot quicker...



[1] http://dennisbareis.com/makemsi.htm

[Robert Raschke-5]

Lovely summary of the little gotchas when trying to create your own
standalone packaged Erlang app for Windows. Thank you for sending
this, Antoine.

Robby


On 10/23/09, Antoine Koener <antoine.koener@...> wrote:

>> "...We’ll put together a Windows installer soon that’ll probably be around
>> the same size. A 10MB download
>> isn’t so bad nowadays, and I expect we can optimize the packaging process
>> some more. Linux users will get
>> a package that depends on the erlang VM in their package manager. Seems
>> like shipping Erlang apps to the
>> desktop isn’t so hard after all."
>>
>>
> Thanks, interesting read
>
>
> I'm now building a windows installer to deploy some erlang application, and
> here's problems that takes a lot of time
> to fix.
>
>  Erlang for windows (R13B) needs some versions of the VC++ 2005 Runtime.
> (msvcr80.dll)
> Unfortunately the only way the find which one is to read the last part of
> the file "erl.exe" for example and extract information related to its
> "manifest".
> There you will find that you need the VC++ 2005-SP1 runtime.
> (And I think that with R12B this was not the case)
>
>
> The crypto_drv.dll needs the openssl "ssleay32.dll" to be installed. If it's
> not the case you won't be able to use anything
> related to crypto... And thanks to windows dll Hell problem, you need to put
> this dll in \windows\system32 [ SystemFolder ],
> making the package uninstallation not really "nice" because you may remove
> this file, breaking other apps...
>
>  Erlsrv is not really efficient, since your service may no longer be in
> place but still in the erlsrv registry key, you won't be able
> to reinstall it. Windows XP comes with tools like 'sc' that is able to set
> and configure a service.
> Erlsrv with "cmd.exe loves to break your double quotes" is absolutely not
> convenient.
> (I know that there's a new version of it, I didn't tested it for the moment,
> so maybe this part is no longer valid)
>
> There's two "bin" directories, which one is the "one" ?
> Same question with erl.ini.
> erl.ini: should contains good directory names but you can't use the single
> '\' because your path will not be valid :(
>
>
> While using the NSIS installer version is nice to install erlang for testing
> purpose, massively deploying it, is not possible using
> what windows admins are used to i.e. group policy and .msi files. (providing
> silent or "unattended" deployments)
>
> I'm using makemsi[1] to build a .msi package to deploy my windows app, while
> difficult to use, it works almost flawlessly.
> I'll be glad to share my experience with anyone.
>
> Finally my point is that under windows Erlang is difficult to repackage.
> May be we should take time to make it completely autonomous ? ( including
> every dependencies needed )
> Then you may say, what about dependencies upgrades ?  ( openssl
> vulnerability or else )
> I will say that I've no good answers to this question :p
>
> I'm not pushing for massive adoption of Erlang but I think that if anyone is
> able to repackage its erlang app for windows and
> making it full automatic deployment compatible, erlang and erlang based apps
> may spread a lot quicker...
>
>
>
> [1] http://dennisbareis.com/makemsi.htm
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[James Hague]

It would also be good to completely avoid any use of the registry. The bit
that is used right now is not needed at all, and Microsoft recommends not
using the registry for application settings. werl.exe should use the proper
location in the "Users" folder (under Vista--different location under XP),
and there should be an option to not save settings at all.

James