[erlang-questions] Define "exists".

[Eric Newhuis (personal)]

The problem is with list_to_existing_atom/1.  Really it is a great idea.  But...

1.  I have raw query strings coming in from the cruel outside world.

2.  I convert some bits of those into atoms by way of list_to_existing_atom so that someone cannot kill me with DOS attack by bloating my atom table.

3.  With me so far?  Good.

4.  My server, an OTP app, has a .app file that lists several other apps.

5.  list_to_existing_atom fails on atoms defined in those several other apps.

Suggestion:  The documentation should specify what "exists" really means.

Question:  What should I do to force the atoms from my dependent apps to be loaded?  I've been manually calling Module:module_info/0 just in time but, alas, this is starting to fail due to other module dependencies that are unknown at my call sites.

For reference, here is the existing Erlang doc from the .org site:

http://www.erlang.org/doc/man/erlang.html#list_to_existing_atom-1

list_to_existing_atom(String) -> atom()

Types:

String = string()

Returns the atom whose text representation is String, but only if there already exists such atom.

Failure: badarg if there does not already exist an atom whose text representation is String.

[Vlad Dumitrescu]

Hi,

I think that the modules defining the atoms must be loaded when you call to_existing_atom.

Can you preloaded those?

Regards, vlad

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Floris van Manen]

While googling around for (simple) erlang implementations of discrete event simulations,
i come across a single paper about the subject.
"Discrete Event Simulation in Erlang" by A. Ermedahl (1995)
Does it mean that is a non issue, or an ultimate example of write once use for ever ?

Is there more information available ?
Thanks
.Floris

[Frédéric Trottier-Hébert]

The existing atoms is simply a question of what atoms were loaded into the VM's atom table. Atoms are loaded when you evaluate them, have them in loaded modules, etc. Until then, they have not been declared and are not counted as existing.

As for loading dependent atoms, have you tried to load applications? By doing application:load(AppName), Erlang should take care of loading all the app files in these applications, creating the required atoms when you need them, if they're in there. It won't load the object code for you, but you could do it yourself.

In any case, it worries me that you're getting errors on dependencies and whatnot. To me, it sounds like you're trying to protect yourself against the public, but the public is allowed to call atoms matching modules and function calls -- are you building some kind of RPC module matching strings to modules? If so, your approach might be dangerous; the only safe option there is usually a white list. Am I wrong in assuming that's what you're trying to do?

--

Fred Hébert

http://www.erlang-solutions.com

_______________________________________________

[Ulf Wiger]

On 13 Oct 2011, at 15:24, Eric Newhuis (personal) wrote:

> Question: What should I do to force the atoms from my dependent apps to be loaded? I've been manually calling Module:module_info/0 just in time but, alas, this is starting to fail due to other module dependencies that are unknown at my call sites.

Eric,

I presume you have a proper boot script?

If you start the system with the command-line option 'mode -embedded', all modules will be loaded at boot time.

This also turns off dynamic code loading - no free lunch here. You can still explicitly load modules, but unfortunately (?), it's not possible to tell the code_server to go from embedded to 'interactive' mode.

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com

[Jon Watte]

Why do they need to be atoms?

We have a very similar case, where we take HTTP headers from calls to our own servers and turn them into proplists, with atoms for the header kinds ("content-type," "cache-control" etc).

However, we'd probably be just as well off, if not better, to use binaries as the keys -- we get those straight out of the HTTP request anyway. Then we don't have the problem of growing atom store, and/or having to pre-declare all possible headers we might care about.

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.

[Jack Moffitt]

> However, we'd probably be just as well off, if not better, to use binaries
> as the keys -- we get those straight out of the HTTP request anyway. Then we
> don't have the problem of growing atom store, and/or having to pre-declare
> all possible headers we might care about.

I often do this and make the getters/setters convert atoms to binary
so that I can still avoid typing the <<" and ">> as much as possible.
Of course, this won't help if you are pattern matching.

jack.

[Ryan Harrison]

Sorry for the late response, I flagged this e-mail for responding to, but accidentally also archived it.

I am doing research in discrete distributed simulation and have read the paper that you are referring to. I have not found any other references to using Erlang for simulation work. I think this is because not one really ran with the research and produced more papers. There may be industrial applications that have been built, but since those tend to be internal projects and not outward facing products there isn't much press on them :-) The mainline languages that are used for simulation tend to be OO based, so you see a lot of discussion of using Java and C++, but almost nothing for other languages.

I don't feel that there is a significant advantage in using something like C++, because Erlang/OTP allows for the encapsulation that OO is being used for. Also to be quite honest when it comes to large distributed simulations I suspect that modern Erlang would beat the pants off more traditional languages wrt to engineering costs and performance, since doing large scale threading and concurrency in most OO languages is a pain. I am looking at doing a comparison of implementing in C++ and Erlang for distributed simulation, but I don't have a lot of spare time to work on it.

-Ryan Harrison 

[Olivier BOUDEVILLE]

Hi,

First of all, sorry for the shameless plug(s)!

I believe we are doing something along the lines of what you described: we developed a large-scale concurrent (parallel and distributed) generic discrete synchronous (time-stepped) simulation engine in Erlang, named Sim-Diasca. We used it then on high-performance clusters, notably for the CLEVER project (http://www.cleveronline.org/).

Since 2010 we have been releasing it as free software (LGPL), see http://www.sim-diasca.com.

Compared to other approaches (ex: C++ augmented of a middleware), I would say that using Erlang looks a lot more like a non-issue. Regarding the OO issue you mentioned, we relied on WOOPER (http://ceylan.sourceforge.net/main/documentation/wooper/) to fully cover our needs. We may have in the future a chance of comparing this Erlang-based approach with a high-end C++ one, and I am fully confident that, at least cost-wise, Erlang will easily win that match.

I think one can also find at least some PhD theses mentioning other works in that field, notably an asynchronous (optimistic) simulator that was developed, still in Erlang, some time ago.

So, yes, even if it is probably not expected to become a mainstream use of Erlang, I believe this language happens to be very suitable to such simulation needs.

Not wanting to hijack more this list, so maybe for any further exchanges on that topic we could move off-list? As for me, I would be glad to share experiences and thoughts about the use of Erlang for such simulations.

Best regards,

Olivier.
---------------------------
Olivier Boudeville

EDF R&D : 1, avenue du Général de Gaulle, 92140 Clamart, France
Département SINETICS, groupe ASICS (I2A), bureau B-226
Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47 65 27 13

rhar...@google.com Envoyé par : erlang-quest...@erlang.org 18/11/2011 15:52

A v...@klankschap.nl cc erlang-q...@erlang.org Objet Re: [erlang-questions] discrete event simulation

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.