Nabble - Erlang Questions

Re: Erlang/OTP now at Github

2009-11-25T21:52:36Z

On Wed, Nov 25, 2009 at 3:20 PM, Juan Jose Comellas <juanjo@...> wrote:
> Why was the commit history discarded? Wouldn't it be better to at
> least preserve the history corresponding to the public releases? Maybe
> you could use Matthew Foemmel's repository[1] in Github as a base.
>
> [1] http://github.com/mfoemmel/erlang-otp/

I have added a wiki page explaining how you can prepend
mfoemmel's history to our history by using two
simple commands:

http://wiki.github.com/erlang/otp/extending-the-history-of-erlangotp

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

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

Re: Fastest pseudo-random number-generator: erlang:statistics(io) ?

2009-11-25T19:57:40Z

The new nif (native implemented functions) provide a great alternative
to generate random numbers and timestamps, much faster than the Erlang
alternatives!

The speed is about 1/2 to 1/3 of statistics(io), but still much faster
than erlang:now().
I simply used time(0) for the nif_now() and gettimeofday(&tv, NULL)
for the nif_random() functions.

nif's are a great addition to the language!

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

- Thijs Terlouw, Shenzhen, China

Erlang R13B03 EXPERIMENTAL FreeBSD port

2009-11-25T18:29:00Z

FreeBSD *EXPERIMENTAL* (unofficial) port for R13B03
available at
http://www.ne.jp/asahi/bdx/info/software/erlang-r13b03,1-20091126-1.tar.gz

KNOWN issues:

* NO JAVA test yet (WITHOUT_JAVA=yes set in the Makefile)
* Makefile.man has been put dupes of snmp*.3 in MAN3/MAN6/MAN7
(necessary to remove errors on "make package")
* r13b02_1,1 fix (of Steve Vinocki's erlang.el) hasn't been merged

I've sent this port to Giacomo Olgeni (the official port maintainer) so
I hope he'll use mine as a feedback source.

Kenji Rikitake

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

Re: How to match on a nested record against a dict

2009-11-25T16:09:28Z

If you don't need the values that you store in the dict (in your
example, you store [] and never use it), you can use a sets instead of
a dict. Usage is a little bit simpler:

-------------------------
1> D = dict:store("_see._tcp.local", [], dict:new()).
{dict,1,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
{{[],[],[],[],
[["_see._tcp.local"]],
[],[],[],[],[],[],[],[],[],[],[]}}}
2> dict:find("_see._tcp.local", D).
{ok,[]}

3> S = sets:add_element("_see._tcp.local", sets:new()).
{set,1,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
{{[],[],[],[],
["_see._tcp.local"],
[],[],[],[],[],[],[],[],[],[],[]}}}
4> sets:is_element("_see._tcp.local", S).
true
-------------------------

See also gb_sets and ordsets.

Igor.

On Tue, Nov 24, 2009 at 7:25 PM, Jarrod Roberson <jarrod@...> wrote:

> On Tue, Nov 24, 2009 at 3:18 PM, Jarrod Roberson <jarrod@...>wrote:
>
>>
>> process_dnsrec1(Sub,[#dns_rr{domain=Dom}|Rest]) ->
>> case dict:find(Dom,Sub) of
>> [Result] ->
>> io:format("Interesting domain ~p=~p~n",[Dom,Result]);
>>
>
> thanks for reading I figured it out by trial and error.
> I replaced the [Result] with {ok,Result} and it started working as expected

--
"The secret of joy in work is contained in one word - excellence. To
know how to do something well is to enjoy it." - Pearl S. Buck.

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

Re: A Generic API for controlling software components

2009-11-25T16:06:44Z

On Wed, Nov 25, 2009 at 3:50 PM, Jayson Vantuyl <kagato@...> wrote:

> If you want to deprecate applications, that's fine, but understand that two packaging / distribution formats is a horrible idea. It took forever in Python to unify eggs and setuptools.

I'd heartily second this. Python still doesn't have a unified
packaging schema/toolset -- distutils and setuptools are still both in
mainstream use, and it's a total pain.

I've done a fair amount of work in package management systems in the
commercial/proprietary work. I've never seen a packaging scheme that
didn't have some pretty annoying warts. This tends to lead to package
manager proliferation as it's very tempting to start anew on this
common problem. Unfortunately, what initially looks like not-a-wheel
is probably just another wheel.

Unfortunately, I can only hand wave as I don't have a deep
understanding of Erlang's current application/release scheme (though I
have managed to used it :) I do think there's a reasonable burden to
demonstrate why Erlang's application abstraction can't be evolved to
support Python Egg or Ruby Gem like features. If the application
scheme doesn't work, could application be morphed into components, or
packages (also a common term for this)?

Is there something from Faxien that gets us closer to Joe's goal?

http://code.google.com/p/faxien/

Garrett

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

Re: Erlang/OTP now at Github

2009-11-25T15:40:03Z

An event of significance -> mojombo has featured this on the GitHub
main blog :)

http://github.com/blog/554-erlang-otp-now-on-github

/s

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

Re: A Generic API for controlling software components

2009-11-25T13:59:35Z

On Nov 25, 2009, at 10:56 PM, Joe Armstrong wrote:
> Rule4: All components C must have a file called
>
> $HOME/eComponents/C.ec/Preferences.pl
>
> The extension .pl means the file contains a property
> list. Here is an example:

We already have .pl meaning Prolog and .pl meaning Perl.
Since the property list uses Erlang syntax, how about
.epl (Erlang Property List)?
>
> Rule6: Code upgrade
>
> We should upgrade an component C when it's expiry date has
> been reached. To update an component we delete the entire
> component under $HOME/eComponents/C.ec we install the
> new component and run the command: C:install().

What happens if the expiry date is reached and there _isn't_ any
new version, or the site the new version should be obtained from
is unreachable?
>

There are many kinds of components.
For example,
- there should be exactly one instance
- there should be at most one instance
- there can be up to N instances to share work
- there should be one instance per client
...
It isn't clear to me what range of component types this proposal
is meant to cover.

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

Re: A Generic API for controlling software components

2009-11-25T13:50:03Z

> I guess you mean OTP applications? - If so then I disagree. To start
> with the directory structure within
> an OTP application is fixed which I don't really like. Also there is
It's fine that you don't like it, however, what use case justifies it. "Because I want to" is not really a reason. If you don't want to do it for a reason, it's probably bad design. No offense, really.

Here's what I don't want. I don't want each component to have radically different layouts that require a ton of work to adapt to. I want contributing to projects and deploying them to be easy. Conventions solve this. Unless you have a problem that "rigid directory structures" prevent you from solving, that's just not good enough.

> no construction rule
> that says you are not allowed to write anything in the application
> directory tree. I'd like to put the
> entire component in a read-only area of disk for safety reasons (once
> an initial install has been performed).
This is a good idea. Separate the mutable data from code. This can be done perfectly well by convention, though.

> I have a differnt proposal for reducing duplicates - this is a
> different problem.
If the problem is that deployment and installation is a hassle, I beg to differ. Part of the problem is that the core Erlang developers are often changing internal modules, so it is natural that their deployment system duplicates the entire system. For most of us, we just need to overlay our little modules on top of the giant Erlang environment. That's why I've been suggesting an overlay approach.

> Yes to deploying Erlang components *and upgrading them*
Applications are in modules and have versions. The upgrade case for Erlang applications is pretty much solid. Now, the way that releases do it (mutating an existing installation) is not exactly ideal, and I'd love to make adapt it to something smarter.

> Sure. epkg etc. will be just a thin shell script layer over the API I suggested.
> The CLI can be written as a thin layer over the API as well.
I would welcome that. I think that a gen_event is a good model for handling runtime CLI functions.

> because 90% is not enough
Perhaps I wasn't clear. I was suggesting you start from 90% done instead of start from 0% done. Also, components and applications have enough conceptual overlap that it would only serve to be confusing.

If you want to deprecate applications, that's fine, but understand that two packaging / distribution formats is a horrible idea. It took forever in Python to unify eggs and setuptools.

> Of course. I just want to download yaws, ejabberd etc. drop them into
> my eComponent Directory
> and that's it - they are installed and runnable.
No, you don't. :) A list of steps is not what you want. You want "installing components to be easy". Downloading a file and dropping it in can't run any code, can't make any decisions custom to your system, and can't autogenerate configuration. All of these things are great strengths of "gem install" and "easy_install". The last thing you want is to have a dozen different component downloads.

For example, assume that RabbitMQ gets a bunch of C components that need building for three OSes. Now assume that it gets a special federated mode that requires different configuration. Next assume that it develops a multi-hosted version for hosting providers. If each combination has to be packaged separately (i.e. because we can't build the C extensions or mutate the configuration on install) then we end up with 12 (3*2*2) packages!

Being devil's advocate here, let's say we do it your way and have "install code" that runs when you start it the first time we do a deployment. Even with this code, it has very weird behavior. The first time startup may take forever or fail if the extension fails to build. Now we have to keep track of that process and recover gracefully from it. It would have been far better to have had the "install" or "deploy" step fail.

Basically, I don't see any value to the extra step. It should be "install" then "deploy", and install should be smart. If "install" is downloading a file and working with directories it's not smart.

Ironically, it's also not really that beneficial to anyone in terms of user experience. Power users won't mind a single command in the shell. Non-power users would rather click an icon (moving files around for them is scary). It lands in a middle-ground that is probably less populated than you would think.

> Ok, I didn't fully specify this - fine to change the details here or
> use an environment variable to point
> to the directory.
I think unobtrusive default + environmental variable is good here.

> This is the bit that is not enforced in OTP applications - I think
> users are even encouraged to use the /priv
> directory in an otp application
Is there something about this that is hard to retrofit into applications? The great thing is that it's all abstracted already--just change what comes back from code:priv_dir/1. If people are doing it properly, their data should go where you want it to go.

I'd really recommend having a cascading/overlaying/shadowing setup. Have everything search the deploy location, user location, and system location in that order. Mutable data never is found outside of the deploy.

> Ok .eplist then?
That sounds good.

> Because I might not want to follow that particular convention. For
> simple applications I usually put everything in one directory.
> Actually this could be dropped, the system could scan the filesystem
> to find the code paths
> the first time you run the program.
> directory
One of the most misunderstood things about the Ruby community is their intolerance. Don't get me wrong, some of them are intolerant bigots, just like you get anywhere. However, a lot of the intolerance comes from a desire to have solid conventions. If you have to write applications all day long, knobs are only helpful if they're invisible. Every required parameter and every choice about where to put a directory is extra time before I have a working project and extra trouble when I come back to it six months later.

Having the ability to override a convention is fine, but it should have a default and it should require no configuration.

The scanning the filesystem part is a good one. One of the ugly things about Python, Java, Ruby, and Erlang is management of the code path. Java has it down with a set of mostly ugly conventions. Ruby still does a lot of manhandling (mostly generating stub files that know where the real code is). Python has, in my opinion, the best solution. Specifically, in the "system" directory, you can drop .pth files that point to additional code paths. This is fabulous in that it helps package managers (i.e. dpkg, rpm) plug in code in a manageable way. If Erlang were to have, for example, .epth files in /usr/lib/erlang/bin, that would make an awesome hook for distribution managers. Adding a .erlang directory (in the $HOME) with the same semantics would make it easy for users. It would be nice to move the cookie and hosts file into that directory, but I understand that might be asking too much too soon.

> It's a hint to tell the package manager how often to check for updates
> - I havn't thought through all the details
> it could be something else:
>
> {checkForUpdates, everyTimeYouStart | dayly | hourly | weekly |
> {after,Year,Month,Day} | {every, 10, minutes}}
>
> etc.
Most system administration tasks are done rarely (i.e. running updates with the package manager, which this is a hint for). In this case, everybody else just downloads the current package list and compares it locally. I don't think that hints are all that useful in comparison. They can only generate false positives (expired but no update) and false negatives (not expired, but new update is out there).

> The designer of the program knows what is a sensible value here
Upgrades can trash data. It is not the designer's data. I don't think it takes more than blowing away the data in your RabbitMQ or losing your ejabberd user database to see why this could be extraordinarily bad on a large scale. Bugs happen. Best to let the administrator be in the loop.

>> Again, I humbly suggest more traditional Unix pathnames. How about $HOME/.erlang/library/<component>/<vsn>/prefs.epl?
>
> No worries ...
Thank you.

> I guess the component framework would use the check for updates or
> expiry date or whatever
> to decide whether to do a check. The check would return a list of
> improvements and the user would decide
> whether or not to install them.
Almost everything under the sun has an update command, but never does anything automatically. I really think it would be prudent. If you want to do "automatic updates", I would at least suggest that you have it turned off by default, and have it turned on by a project, not the user. The rationale is that the user of a component probably doesn't know enough about how the data is stored to keep it safe, but that the component developer should know.

> I guess we should also be able to roll back a version (which is why I
> have eLibrary/ComponentName/VSN/data ..
> tags.
Definitely. This is another reason that I suggested having a separate "deploy" step. You no longer have to worry about upgrading an installation. Each "version" is another deployment. In this scenario, you can specify "migrations" to upgrade/downgrade the data, but the code is managed as a separate entity.

> It is pretty similar
One is better than two. :)

--
Jayson Vantuyl
kagato@...

Re: Erlang "object-oriented" after all?

2009-11-25T13:49:11Z

Hi,

This is surely a shameless plug, but, in terms of OOP with Erlang, one
might give WOOPER a try
(http://ceylan.sourceforge.net/main/documentation/wooper/), as it
basically provides most OOP constructs in order to rely on concurrent
instances in pure Erlang.

Best regards,

Olivier.

Jachym Holecek a écrit :

> # Michael Turner 2009-11-24:
>
>> I ran across a very interesting exchange with Alan Kay, who most likely
>> coined the term "object-oriented programming."
>>
>> http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
>>
>> If you'll excuse some (only slightly tendentious) editing of his remarks:
>>
>> ----
>> "I thought of objects being like biological cells and/or individual
>> computers on a network, only able to communicate with messages . . . .
>>
>
> No, you didn't. If you did, you would certainly have noticed that individual
> cells/computers live concurrently and communicate asynchronously, which is not
> how your objects behave.
>
> :-)
>
> SCNR, I still remember the disappointment of discovering (ages back) that
> Objective-C objects didn't really fulfill the "they behave like real-world
> objects" promise given by the (otherwise pretty good) NeXT book because
> you couldn't "run objects in parallel" which sounded like something that
> should obviously be possible.
>
> Regards,
> -- Jachym
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
>
>

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

Re: Question about erlang.log

2009-11-25T09:24:29Z

Wael Ebrahim wrote:

> I have a question about Erlang log.
>
> I have a target system and I want to increase the size and number of log
> files named erlang.log.1 ....erlang.log.5 in the directory ROOT_DIR/log/
>
>
> The default values are 5 files each one is 100K , but I had a very big
> crash that was repeated multiple times causing these files to be
> overwritten, and I couldn't reach its start.
>
> I know I can use sasl for this kind of monitoring, but it doesn't log
> the user input on the erlang shell as the erlang.log.x does.
> Also sasl doesn't log any output except from standard applications, or
> error_logger.
>
> Any ideas about increasing size of these files "erlang.log.x" ???
>
> Thanks in advance,
>
> Wael Ebrahim
>
>
>

Before starting run_erl, you can set these environment variables:

export RUN_ERL_LOG_GENERATIONS=10
export RUN_ERL_LOG_MAXSIZE=1000000

see http://www.erlang.org/doc/man/run_erl.html for more details

Cheers

Rob

--
Erlang Training and Consulting Ltd
www.erlang-consulting.com

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

Re: Erlang/OTP now at Github

2009-11-25T08:00:46Z

On Wed, Nov 25, 2009 at 3:20 PM, Juan Jose Comellas <juanjo@...> wrote:
> Why was the commit history discarded? Wouldn't it be better to at
> least preserve the history corresponding to the public releases? Maybe
> you could use Matthew Foemmel's repository[1] in Github as a base.

Including the history would require approximately 300 Mb.

However, we will probably provide an *optional* Erlang/OTP
history that can be added using the new replace mechanism in
git 1.6.5.

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

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

Re: Erlang/OTP R13B03 has been released

2009-11-25T06:30:37Z

Hi,

Thanks a lot for another OTP release!

I just wanted to say that the links to the torrent files are not
correct. The correct links should be:

http://www.erlang.org/download/torrents/otp_src_R13B03.tar.gz.torrent
http://www.erlang.org/download/torrents/otp_win32_R13B03.exe.torrent

-
vincent

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

Question about erlang.log

2009-11-25T06:21:27Z

I have a question about Erlang log.

I have a target system and I want to increase the size and number of log
files named erlang.log.1 ....erlang.log.5 in the directory ROOT_DIR/log/

The default values are 5 files each one is 100K , but I had a very big
crash that was repeated multiple times causing these files to be
overwritten, and I couldn't reach its start.

I know I can use sasl for this kind of monitoring, but it doesn't log
the user input on the erlang shell as the erlang.log.x does.
Also sasl doesn't log any output except from standard applications, or
error_logger.

Any ideas about increasing size of these files "erlang.log.x" ???

Thanks in advance,

Wael Ebrahim

Re: Erlang/OTP now at Github

2009-11-25T06:20:14Z

Why was the commit history discarded? Wouldn't it be better to at
least preserve the history corresponding to the public releases? Maybe
you could use Matthew Foemmel's repository[1] in Github as a base.

[1] http://github.com/mfoemmel/erlang-otp/

2009/11/25 Björn Gustavsson <bgustavsson@...>

>
> The official git repository for Erlang/OTP can now be found at Github:
>
> http://github.com/erlang/otp
>
> Build instructions can be found at:
>
> http://wiki.github.com/erlang/otp
>
> We plan to add more wiki pages with additional information in the
> near future.
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>

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

Re: Erlang "object-oriented" after all?

2009-11-25T06:14:06Z

# Michael Turner 2009-11-24:

>
> I ran across a very interesting exchange with Alan Kay, who most likely
> coined the term "object-oriented programming."
>
> http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
>
> If you'll excuse some (only slightly tendentious) editing of his remarks:
>
> ----
> "I thought of objects being like biological cells and/or individual
> computers on a network, only able to communicate with messages . . . .

No, you didn't. If you did, you would certainly have noticed that individual
cells/computers live concurrently and communicate asynchronously, which is not
how your objects behave.

:-)

SCNR, I still remember the disappointment of discovering (ages back) that
Objective-C objects didn't really fulfill the "they behave like real-world
objects" promise given by the (otherwise pretty good) NeXT book because
you couldn't "run objects in parallel" which sounded like something that
should obviously be possible.

Regards,
-- Jachym

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

Erlang/OTP now at Github

2009-11-25T06:01:24Z

The official git repository for Erlang/OTP can now be found at Github:

http://github.com/erlang/otp

Build instructions can be found at:

http://wiki.github.com/erlang/otp

We plan to add more wiki pages with additional information in the
near future.

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

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

Re: mnesia:transform_table

2009-11-25T06:00:59Z

That would be the reason I couldn't find it anywhere in the documentation
then!

I'll just live with the old table name, it seems easier!

Thanks very much,

Andrew

2009/11/25 Håkan Mattsson <hakan@...>

> 2009/11/25 andrew mmc <andrewmmc@...>:
>
> > So I guess the next question, is: how do I change the table name!?
>
> It is not supported. As a last resort you can do it off-line by creating a
> backup, use mnesia:traverse_backup/8 to patch the backup and then
> restore the database from the backup. But if you would do that you
> could transform the records off-line also.
>
> /Håkan
>

Re: mnesia:transform_table

2009-11-25T05:56:42Z

2009/11/25 andrew mmc <andrewmmc@...>:

> So I guess the next question, is: how do I change the table name!?

It is not supported. As a last resort you can do it off-line by creating a
backup, use mnesia:traverse_backup/8 to patch the backup and then
restore the database from the backup. But if you would do that you
could transform the records off-line also.

/Håkan

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

Erlang/OTP R13B03 has been released

2009-11-25T05:49:50Z

Bug fix release : otp_src_R13B03
Build date : 2009-11-23

This is R13B03, the third maintenance release for the R13B major release.

You can find the README file for the release at

http://www.erlang.org/download/otp_src_R13B03.readme

The source distribution and binary distribution for Windows can be
downloaded from

http://www.erlang.org/download/otp_src_R13B03.tar.gz
http://www.erlang.org/download/otp_win32_R13B03.exe

The distribution can also be downloaded using the BitTorrent
protocol. Use the following torrent files to download the source
distribution and binary distribution for Windows:

http://www.erlang.org/download/otp_src_R13B03.tar.gz.torrent
http://www.erlang.org/download/otp_win32_R13B03.exe.torrent

Note: To unpack the TAR archive you need a GNU TAR compatible program.

For installation instructions please read the README file that is part
of the distribution.

The on-line documentation can be found at: http://www.erlang.org/doc/
You can also download the complete HTML documentation or the Unix manual files

http://www.erlang.org/download/otp_doc_html_R13B03.tar.gz
http://www.erlang.org/download/otp_doc_man_R13B03.tar.gz

We also want to thank those that sent us patches, suggestions and bug
reports,

The OTP Team

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

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

Re: mnesia:transform_table

2009-11-25T05:47:39Z

Hi Håkan,

Thanks for your answer... Actually I see that it has worked - I expected the
table name to change with the record name, but the name is the same as
before. I got an empty table because I used dirty_match_object without
specifying the 'old' table name.

So I guess the next question, is: how do I change the table name!?

Thanks,

Andrew

2009/11/25 Håkan Mattsson <hawk.mattsson@...>

> It looks like you have done the right thing. Perhaps you have
> simplified your code too much in order to post it on the list?
>
> I tried to reproduce your error, but it worked for me.
> See the printouts and the test program below.
>
> /Håkan
>
> 16> foo:go(foo).
> Before: [{old,7,49},
> {old,6,36},
> {old,4,16},
> {old,1,1},
> {old,9,81},
> {old,10,100},
> {old,8,64},
> {old,2,4},
> {old,3,9},
> {old,5,25}]
> Before: [{new,7,49,42},
> {new,6,36,42},
> {new,4,16,42},
> {new,1,1,42},
> {new,9,81,42},
> {new,10,100,42},
> {new,8,64,42},
> {new,2,4,42},
> {new,3,9,42},
> {new,5,25,42}]
> ok
>
>
> -module(foo).
> -compile([export_all]).
>
> -record(old, {key, val}).
> -record(new, {key, val, extra}).
>
> go(Tab) ->
> mnesia:delete_table(Tab),
> {atomic, ok} = mnesia:create_table(Tab, [{attributes,
> record_info(fields, old)},
> {record_name, old}]),
> [mnesia:dirty_write(Tab, #old{key = K, val = K*K}) || K <-
> lists:seq(1,10)],
> io:format("Before: ~p\n", [ets:tab2list(Tab)]),
> Transformer =
> fun(#old{key = Key, val = Val}) ->
> #new{key = Key, val = Val, extra = 42}
> end,
> {atomic, ok} = mnesia:transform_table(Tab, Transformer,
> record_info(fields, new),
> new),
> io:format("Before: ~p\n", [ets:tab2list(Tab)]).
>
>
>
> On Wed, Nov 25, 2009 at 2:07 PM, andrew mmc <andrewmmc@...> wrote:
> > Hello,
> >
> > I needed to change the structure of an mnesia table. I followed the
> example
> > in the documentation:
> >
> > -record(old, {key, val}).
> > -record(new, {key, val, extra}).
> >
> > Transformer =
> > fun(X) when record(X, old) ->
> > #new{key = X#old.key,
> > val = X#old.val,
> > extra = 42}
> > end,
> > {atomic, ok} = mnesia:transform_table(foo, Transformer,
> > record_info(fields, new),
> > new)
> >
> > Substituting the record names and field mappings as per my
> > requirement. The transformation function works fine when I test it on
> > a record of the old type, outputting the new record ok.
> >
> > However, now when I try to read from the new table, mnesia reports
> > no_exists, and the old table still exists but reads as empty... Where
> > has my data gone?!
> >
> > Any help much appreciated!
> >
> > Regards,
> >
> >
> > Andrew
>
> On Wed, Nov 25, 2009 at 2:07 PM, andrew mmc <andrewmmc@...> wrote:
> > Hello,
> >
> > I needed to change the structure of an mnesia table. I followed the
> example
> > in the documentation:
> >
> > -record(old, {key, val}).
> > -record(new, {key, val, extra}).
> >
> > Transformer =
> > fun(X) when record(X, old) ->
> > #new{key = X#old.key,
> > val = X#old.val,
> > extra = 42}
> > end,
> > {atomic, ok} = mnesia:transform_table(foo, Transformer,
> > record_info(fields, new),
> > new)
> >
> > Substituting the record names and field mappings as per my
> > requirement. The transformation function works fine when I test it on
> > a record of the old type, outputting the new record ok.
> >
> > However, now when I try to read from the new table, mnesia reports
> > no_exists, and the old table still exists but reads as empty... Where
> > has my data gone?!
> >
> > Any help much appreciated!
> >
> > Regards,
> >
> >
> > Andrew
>

Re: mnesia:transform_table

2009-11-25T05:40:21Z

It looks like you have done the right thing. Perhaps you have
simplified your code too much in order to post it on the list?

I tried to reproduce your error, but it worked for me.
See the printouts and the test program below.

/Håkan

16> foo:go(foo).
Before: [{old,7,49},
{old,6,36},
{old,4,16},
{old,1,1},
{old,9,81},
{old,10,100},
{old,8,64},
{old,2,4},
{old,3,9},
{old,5,25}]
Before: [{new,7,49,42},
{new,6,36,42},
{new,4,16,42},
{new,1,1,42},
{new,9,81,42},
{new,10,100,42},
{new,8,64,42},
{new,2,4,42},
{new,3,9,42},
{new,5,25,42}]
ok

-module(foo).
-compile([export_all]).

-record(old, {key, val}).
-record(new, {key, val, extra}).

go(Tab) ->
mnesia:delete_table(Tab),
{atomic, ok} = mnesia:create_table(Tab, [{attributes,
record_info(fields, old)},
{record_name, old}]),
[mnesia:dirty_write(Tab, #old{key = K, val = K*K}) || K <- lists:seq(1,10)],
io:format("Before: ~p\n", [ets:tab2list(Tab)]),
Transformer =
fun(#old{key = Key, val = Val}) ->
#new{key = Key, val = Val, extra = 42}
end,
{atomic, ok} = mnesia:transform_table(Tab, Transformer,
record_info(fields, new),
new),
io:format("Before: ~p\n", [ets:tab2list(Tab)]).

On Wed, Nov 25, 2009 at 2:07 PM, andrew mmc <andrewmmc@...> wrote:

> Hello,
>
> I needed to change the structure of an mnesia table. I followed the example
> in the documentation:
>
> -record(old, {key, val}).
> -record(new, {key, val, extra}).
>
> Transformer =
> fun(X) when record(X, old) ->
> #new{key = X#old.key,
> val = X#old.val,
> extra = 42}
> end,
> {atomic, ok} = mnesia:transform_table(foo, Transformer,
> record_info(fields, new),
> new)
>
> Substituting the record names and field mappings as per my
> requirement. The transformation function works fine when I test it on
> a record of the old type, outputting the new record ok.
>
> However, now when I try to read from the new table, mnesia reports
> no_exists, and the old table still exists but reads as empty... Where
> has my data gone?!
>
> Any help much appreciated!
>
> Regards,
>
>
> Andrew

On Wed, Nov 25, 2009 at 2:07 PM, andrew mmc <andrewmmc@...> wrote:

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

Re: A Generic API for controlling software components

2009-11-25T05:12:55Z

On Wed, Nov 25, 2009 at 1:40 PM, Jayson Vantuyl <kagato@...> wrote:

> First, let me take a stab at describing the goal (or what I think is and should be the goal) of components.
>
> It seems that you're trying to address:
>
> 1. Unifying execution / configuration conventions across popular Erlang projects.
> 2. Putting some sort of management conventions around deployments of said products.
>
> So, I don't think you're going to get a lot of traction on #2 unless it makes deployment easier. Right now, those programs all have ad-hoc conventions precisely because Erlang's deployment conventions, while rock solid, are nearly impossible to use outside of an embedded environment.
>
> If you really want to make things better (and I'm sure you do), here's what I suggest doing.
>
> Don't create yet-another-packaging-abstraction (i.e. components). Applications are perfectly fine for this. Really.
>

I guess you mean OTP applications? - If so then I disagree. To start
with the directory structure within
an OTP application is fixed which I don't really like. Also there is
no construction rule
that says you are not allowed to write anything in the application
directory tree. I'd like to put the
entire component in a read-only area of disk for safety reasons (once
an initial install has been performed).

Some people want to put components into read-only memory for embedded
devices - it also makes it
easier to scan things for security reasons.

> Address the issues that make it hard to deploy Erlang applications. Specifically, applications should probably be deployed as a set of modules in a second LIBDIR, that shadows the existing one, thereby reducing the number of duplicates of the entire environment (which is a current problem with Erlang's release stuff). I already do this, and it's great.

I have a differnt proposal for reducing duplicates - this is a
different problem.

Yes to deploying Erlang components *and upgrading them*

>
> Address issues that make deploying applications hard, in general. The CLI itch is a good one to scratch. Make it trivial to write a CLI event handler. Make it a normal gen_event. Maybe require a key in the app config (maybe {cli_handler,Module}) or perhaps just have a convention (something like an atom of the form '<application>_cli'). For that matter, make a distribution container that is more like a gem/egg.
>
> I think this is really want you want. Installing an Erlang application should be as easy as commands something like:
>
> # epkg install rabbitmq
> ...downloads, builds, and installs rabbitmq code somewhere sane...
> # epkg deploy rabbitmq mydeploy
> ...generates a "deployment" somewhere, basically just config and state data, mydeploy is used to generate nodenames (i.e. mydeploy_rabbitmq_main, mydeploy_rabbitmq_helper, etc)...
> # ectl mydeploy start
> ...starts nodes specified for the deploy...
> # ectl mydeploy flush_cache
> ...since flush_cache is not implemented by ectl, it should be passed through to an event handler...

Sure. epkg etc. will be just a thin shell script layer over the API I suggested.
The CLI can be written as a thin layer over the API as well.

>
> Obviously there's a lot to go on under the covers, but anything more complex than that is, at best, a well engineered user-experience failure. More importantly, I think the above captures what you should be doing.
>
> All of that said, here are my comments on the proposal, so far (most of which I've already stated above):
>
>> What I would like to do is manage all the components in a uniform manner.
>> Much of this design is inspired by how Mac OS-X manages applications.
> Why not just use the application framework, again? It's 90% there for this.

because 90% is not enough

> Is there anything about an application that makes it unsuitable (i.e. smaller than) a component? I would just add this to an application.
>
>> By manage I mean start and stop the component, upgrade the code,
>> change the behavior of the component at run time and so on.
> I think you're thinking in terms of actual user-level management, right? Basically, this is to unify things like ejabberdctl and rabbitmqctl. I think that's a fantastic idea.

Of course. I just want to download yaws, ejabberd etc. drop them into
my eComponent Directory
and that's it - they are installed and runnable.

>
> Looking forward, I'd suggest taking a hard look at Ruby gems and Python distutils/setuputils/eggs. I really think that it would make a lot of sense to take the existing Erlang release system and use it to make something not unlike a gem or egg (which it already kind of does, but at a whole-Erlang-system level, not a component level).
>
> As for the command line, it would be extremely handy to be able to have a convention where the nodename of a certain component was known, and there was a command line wrapper to send it commands. Perhaps, have the component run a gen_event, and have "erlctl <component> <command> [args...]" generate an event in the node that the component runs in. Extending edoc to generate commandline documentation would be killer here, too.
>
>> Here's a suggestion for a set of rules for managed components:
>>
>> Draft 1 - 25 Nov 2009
>>
>> Rule1: All components are unpacked into the same top-level
>> directory (default $HOME/eComponent) and have the extension
>> .ec (Erlang component)
>>
>> Example: Imagine I have installed mochiweb ejabberd and couchDB
>> then after installation I should see the following:
>>
>> $pwd
>> /home/joe/eComponents
>> $ls
>> mochiweb.ec ejabberd.ec couchDB.ec
> I don't think eComponents, as a non-hidden top-level directory is going to thrill the aesthetic sense of most Unix users. I would humbly suggest something more like $HOME/.erlang/components/. Or, better yet, a system directory (probably just in the Erlang code root) and a user directory ($HOME/.erlang/lib).

Ok, I didn't fully specify this - fine to change the details here or
use an environment variable to point
to the directory.

>
>> Rule2: A normal user should *never* have to examine any of the
>> files *inside* the component. To do so causes
>> "abstraction leakage" - I want to consider each of these
>> components as black boxes. Once installed the component
>> should be installed in a read-only disk area.
> Certainly.

This is the bit that is not enforced in OTP applications - I think
users are even encouraged to use the /priv
directory in an otp application

>
>>
>> Rule3: The component should not break if relocated to a different
>> top-level directory. A simple "mv" command should suffice
>> So no hard-wired paths or links please.
> Certainly.
>
>> Rule4: All components C must have a file called
>>
>> $HOME/eComponents/C.ec/Preferences.pl
>>
>> The extension .pl means the file contains a property
>> list. Here is an example:
> .pl is bad mojo, as it's universally accepts to be Perl. How about, .epl (i.e. Erlang Property List).

Ok .eplist then?

>
>>
>> {codePath, "/bin"}.
>> {expiryDate, {2009,12,24}}.
>> {icon, "/images/myIcon.png"}
>> {version,1}
>> {myKey1, ...}
>>
>> The keys codePath, version, and expiryDate are obligatory
>>
>> Why do we need code path? - so that Erlang can find
>> a module called C.erl
> If the code path is relative, what is gained by having it specifiable? Why not just have a convention that it's ebin (or maybe have component/lib be added as an additional LIBDIR).

Because I might not want to follow that particular convention. For
simple applications I usually put everything in one directory.
Actually this could be dropped, the system could scan the filesystem
to find the code paths
the first time you run the program.
directory

>
>> Expiry date has a "time to live for the component"
>> Version is used for local configuration data (see later)
>> Version numbers should start at one and be increased by one
>> for each new release.
> The expiry time thing is confusing to me. Is this automatically done by some program, or is it metadata for a person?

It's a hint to tell the package manager how often to check for updates
- I havn't thought through all the details
it could be something else:

{checkForUpdates, everyTimeYouStart | dayly | hourly | weekly |
{after,Year,Month,Day} | {every, 10, minutes}}

etc.

The designer of the program knows what is a sensible value here

>
>> Rule5: Local configuration data
>>
>> Local configuration data must not be stored under the
>> eComponents directory - (you can't remember we said the
>> component is in a read-only disk area - see rule2)
>>
>> Local data for the component C must be stored
>> in the directory
>>
>> $HOME/eLibrary/ComponentName/Vsn
>>
>> Thus local preferences for ejabberd version 1
>> would be stored in the file
>>
>> $HOME/eLibrary/ejabberd/1/Preferences.pl
> Again, I humbly suggest more traditional Unix pathnames. How about $HOME/.erlang/library/<component>/<vsn>/prefs.epl?

No worries ...

>
>> Rule6: Code upgrade
>>
>> We should upgrade an component C when it's expiry date has
>> been reached. To update an component we delete the entire
>> component under $HOME/eComponents/C.ec we install the
>> new component and run the command: C:install().
>>
>> Data that is to be carried over between different versions
>> of the component is stored in $HOME/eLibrary/C/V/...
> Is this done by the component framework? Is this really a good idea to be done automatically? Automatically deployed upgrades have generally been associated with tears and gnashing of teeth in my experience.

I guess the component framework would use the check for updates or
expiry date or whatever
to decide whether to do a check. The check would return a list of
improvements and the user would decide
whether or not to install them.

I guess we should also be able to roll back a version (which is why I
have eLibrary/ComponentName/VSN/data ..
tags.

>
>> Rule7: management
>>
>> All components C must provide a module in the file
>> C_control.erl - so ejabberd provides ejabberd_control.erl
>>
>> The management API is as follows:
>>
>> C:start_link() -> Pid
>>
>> create a controller process for the component.
>>
>> Pid has the following protocol [see note 1 for notation]
>> PL is a property list (list of {Key::atom(), Value::any()}
>>
>> Pid !! {start, PL} => ok | {error, Why}
>>
>> Cold start the component. PL is a property
>> list describing how the component should behave
>>
>> Pid !! {stop, PL} => ok
>>
>> Stop the component
>>
>> Pid !! {modify, PL} => ok | {error, Why}
>> Change the behavior of the component
>>
>> Pid !! info => PL
>> Pid !! {info, [Keys]} => [Values]
>>
>> Pid !! suspendLocal => ok
>> Pid !! resumeLocal => ok
>>
>> Suspend the component data can be written to
>> $HOME/eLibrary/ComponentName/Vsn/...
>>
>> Pid !! suspendRemote => <<BinaryClosure>>
>> Pid !! {resumeRemote, <<BinaryClosure>>} => ok
>>
>> This ton suspend an component on one machine
>> and resume it on another
>
> This looks a lot like it could just use the existing application framework. I don't think that most of this would even require breaking backwards-compatibility.

It is pretty similar

/Joe

>
>
> --
> Jayson Vantuyl
> kagato@...
>
>
>
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

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

mnesia:transform_table

2009-11-25T05:07:21Z

Hello,

I needed to change the structure of an mnesia table. I followed the example
in the documentation:

-record(old, {key, val}).
-record(new, {key, val, extra}).

Transformer =
fun(X) when record(X, old) ->
#new{key = X#old.key,
val = X#old.val,
extra = 42}
end,
{atomic, ok} = mnesia:transform_table(foo, Transformer,
record_info(fields, new),
new)

Substituting the record names and field mappings as per my
requirement. The transformation function works fine when I test it on
a record of the old type, outputting the new record ok.

However, now when I try to read from the new table, mnesia reports
no_exists, and the old table still exists but reads as empty... Where
has my data gone?!

Any help much appreciated!

Regards,

Andrew

Re: A Generic API for controlling software components

2009-11-25T04:41:16Z

> The idea is sound. The execution is suboptimal here. The ending *.pl* is
> embedded in the minds of a very large number of people as a perl script.
> Choose perhaps a longer, more descriptive extension like, say, .proplist or
> .propl or .plist or whatever?

.plist is used in OS X. So I would vite for .proplist.

mue

--
**
** Frank Mueller / Oldenburg / Germany
**

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

Re: A Generic API for controlling software components

2009-11-25T04:40:21Z

First, let me take a stab at describing the goal (or what I think is and should be the goal) of components.

It seems that you're trying to address:

1. Unifying execution / configuration conventions across popular Erlang projects.
2. Putting some sort of management conventions around deployments of said products.

So, I don't think you're going to get a lot of traction on #2 unless it makes deployment easier. Right now, those programs all have ad-hoc conventions precisely because Erlang's deployment conventions, while rock solid, are nearly impossible to use outside of an embedded environment.

If you really want to make things better (and I'm sure you do), here's what I suggest doing.

Don't create yet-another-packaging-abstraction (i.e. components). Applications are perfectly fine for this. Really.

Address the issues that make it hard to deploy Erlang applications. Specifically, applications should probably be deployed as a set of modules in a second LIBDIR, that shadows the existing one, thereby reducing the number of duplicates of the entire environment (which is a current problem with Erlang's release stuff). I already do this, and it's great.

Address issues that make deploying applications hard, in general. The CLI itch is a good one to scratch. Make it trivial to write a CLI event handler. Make it a normal gen_event. Maybe require a key in the app config (maybe {cli_handler,Module}) or perhaps just have a convention (something like an atom of the form '<application>_cli'). For that matter, make a distribution container that is more like a gem/egg.

I think this is really want you want. Installing an Erlang application should be as easy as commands something like:

# epkg install rabbitmq
...downloads, builds, and installs rabbitmq code somewhere sane...
# epkg deploy rabbitmq mydeploy
...generates a "deployment" somewhere, basically just config and state data, mydeploy is used to generate nodenames (i.e. mydeploy_rabbitmq_main, mydeploy_rabbitmq_helper, etc)...
# ectl mydeploy start
...starts nodes specified for the deploy...
# ectl mydeploy flush_cache
...since flush_cache is not implemented by ectl, it should be passed through to an event handler...

Obviously there's a lot to go on under the covers, but anything more complex than that is, at best, a well engineered user-experience failure. More importantly, I think the above captures what you should be doing.

All of that said, here are my comments on the proposal, so far (most of which I've already stated above):

> What I would like to do is manage all the components in a uniform manner.
> Much of this design is inspired by how Mac OS-X manages applications.
Why not just use the application framework, again? It's 90% there for this.

Is there anything about an application that makes it unsuitable (i.e. smaller than) a component? I would just add this to an application.

> By manage I mean start and stop the component, upgrade the code,
> change the behavior of the component at run time and so on.
I think you're thinking in terms of actual user-level management, right? Basically, this is to unify things like ejabberdctl and rabbitmqctl. I think that's a fantastic idea.

Looking forward, I'd suggest taking a hard look at Ruby gems and Python distutils/setuputils/eggs. I really think that it would make a lot of sense to take the existing Erlang release system and use it to make something not unlike a gem or egg (which it already kind of does, but at a whole-Erlang-system level, not a component level).

As for the command line, it would be extremely handy to be able to have a convention where the nodename of a certain component was known, and there was a command line wrapper to send it commands. Perhaps, have the component run a gen_event, and have "erlctl <component> <command> [args...]" generate an event in the node that the component runs in. Extending edoc to generate commandline documentation would be killer here, too.

> Here's a suggestion for a set of rules for managed components:
>
> Draft 1 - 25 Nov 2009
>
> Rule1: All components are unpacked into the same top-level
> directory (default $HOME/eComponent) and have the extension
> .ec (Erlang component)
>
> Example: Imagine I have installed mochiweb ejabberd and couchDB
> then after installation I should see the following:
>
> $pwd
> /home/joe/eComponents
> $ls
> mochiweb.ec ejabberd.ec couchDB.ec

I don't think eComponents, as a non-hidden top-level directory is going to thrill the aesthetic sense of most Unix users. I would humbly suggest something more like $HOME/.erlang/components/. Or, better yet, a system directory (probably just in the Erlang code root) and a user directory ($HOME/.erlang/lib).

> Rule2: A normal user should *never* have to examine any of the
> files *inside* the component. To do so causes
> "abstraction leakage" - I want to consider each of these
> components as black boxes. Once installed the component
> should be installed in a read-only disk area.
Certainly.

>
> Rule3: The component should not break if relocated to a different
> top-level directory. A simple "mv" command should suffice
> So no hard-wired paths or links please.
Certainly.

> Rule4: All components C must have a file called
>
> $HOME/eComponents/C.ec/Preferences.pl
>
> The extension .pl means the file contains a property
> list. Here is an example:
.pl is bad mojo, as it's universally accepts to be Perl. How about, .epl (i.e. Erlang Property List).

>
> {codePath, "/bin"}.
> {expiryDate, {2009,12,24}}.
> {icon, "/images/myIcon.png"}
> {version,1}
> {myKey1, ...}
>
> The keys codePath, version, and expiryDate are obligatory
>
> Why do we need code path? - so that Erlang can find
> a module called C.erl

If the code path is relative, what is gained by having it specifiable? Why not just have a convention that it's ebin (or maybe have component/lib be added as an additional LIBDIR).

> Expiry date has a "time to live for the component"
> Version is used for local configuration data (see later)
> Version numbers should start at one and be increased by one
> for each new release.
The expiry time thing is confusing to me. Is this automatically done by some program, or is it metadata for a person?

> Rule5: Local configuration data
>
> Local configuration data must not be stored under the
> eComponents directory - (you can't remember we said the
> component is in a read-only disk area - see rule2)
>
> Local data for the component C must be stored
> in the directory
>
> $HOME/eLibrary/ComponentName/Vsn
>
> Thus local preferences for ejabberd version 1
> would be stored in the file
>
> $HOME/eLibrary/ejabberd/1/Preferences.pl

Again, I humbly suggest more traditional Unix pathnames. How about $HOME/.erlang/library/<component>/<vsn>/prefs.epl?

> Rule6: Code upgrade
>
> We should upgrade an component C when it's expiry date has
> been reached. To update an component we delete the entire
> component under $HOME/eComponents/C.ec we install the
> new component and run the command: C:install().
>
> Data that is to be carried over between different versions
> of the component is stored in $HOME/eLibrary/C/V/...
Is this done by the component framework? Is this really a good idea to be done automatically? Automatically deployed upgrades have generally been associated with tears and gnashing of teeth in my experience.

> Rule7: management
>
> All components C must provide a module in the file
> C_control.erl - so ejabberd provides ejabberd_control.erl
>
> The management API is as follows:
>
> C:start_link() -> Pid
>
> create a controller process for the component.
>
> Pid has the following protocol [see note 1 for notation]
> PL is a property list (list of {Key::atom(), Value::any()}
>
> Pid !! {start, PL} => ok | {error, Why}
>
> Cold start the component. PL is a property
> list describing how the component should behave
>
> Pid !! {stop, PL} => ok
>
> Stop the component
>
> Pid !! {modify, PL} => ok | {error, Why}
> Change the behavior of the component
>
> Pid !! info => PL
> Pid !! {info, [Keys]} => [Values]
>
> Pid !! suspendLocal => ok
> Pid !! resumeLocal => ok
>
> Suspend the component data can be written to
> $HOME/eLibrary/ComponentName/Vsn/...
>
> Pid !! suspendRemote => <<BinaryClosure>>
> Pid !! {resumeRemote, <<BinaryClosure>>} => ok
>
> This ton suspend an component on one machine
> and resume it on another

This looks a lot like it could just use the existing application framework. I don't think that most of this would even require breaking backwards-compatibility.

--
Jayson Vantuyl
kagato@...

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

Re: A Generic API for controlling software components

2009-11-25T04:34:03Z

2009/11/25 Joe Armstrong <erlang@...>

> >> Rule4: All components C must have a file called
> >>
> >> $HOME/eComponents/C.ec/Preferences.pl
> >>
> >> The extension .pl means the file contains a property
> >> list. Here is an example:
> >>
> >> {codePath, "/bin"}.
> >> {expiryDate, {2009,12,24}}.
> >> {icon, "/images/myIcon.png"}
> >> {version,1}
> >> {myKey1, ...}
> >>
> >> The keys codePath, version, and expiryDate are obligatory
> >>
> >> Why do we need code path? - so that Erlang can find
> >> a module called C.erl
> >>
> >> Expiry date has a "time to live for the component"
> >> Version is used for local configuration data (see later)
> >> Version numbers should start at one and be increased by one
> >> for each new release.
> >
> > Here I would like to have a consistent naming style. Until today most
> parts of Erlang don't use
> > camel case. I like it in Smalltalk, and I like the consistency inside
> Scheme, and until today I
> > like the consistency in Erlang. It's not like Python, where you can see
> which libs are from the
> > Smalltalk or Java side, from the .NET side or the C side. Awful. So it
> should be called
> > preferences.pl with code_path, expiry_date, and so on. Additionally I
> would like nested
> > preferences. My Tideland CEL celcfg module handles this well.
>
> I use names_like_this for function and module names but namesLikeThis
> for atoms in code
>

The idea is sound. The execution is suboptimal here. The ending *.pl* is
embedded in the minds of a very large number of people as a perl script.
Choose perhaps a longer, more descriptive extension like, say, .proplist or
.propl or .plist or whatever?

Re: A Generic API for controlling software components

2009-11-25T03:54:16Z

On Wed, Nov 25, 2009 at 11:55 AM, Frank Mueller <frank@...> wrote:

> Hi Joe,
>
> your idea sounds really good to me, even if I would like some changes.
>
>> Draft 1 - 25 Nov 2009
>>
>> Rule1: All components are unpacked into the same top-level
>> directory (default $HOME/eComponent) and have the extension
>> .ec (Erlang component)
>>
>> Example: Imagine I have installed mochiweb ejabberd and couchDB
>> then after installation I should see the following:
>>
>> $pwd
>> /home/joe/eComponents
>> $ls
>> mochiweb.ec ejabberd.ec couchDB.ec
>
> It's OK to have a default value for the directory, but I would like to have a defined variable
> named $ECOMPONENT_HOME so that I can easily change it.

Yes

>
> Rule 2 and 3 full ack.
>
>> Rule4: All components C must have a file called
>>
>> $HOME/eComponents/C.ec/Preferences.pl
>>
>> The extension .pl means the file contains a property
>> list. Here is an example:
>>
>> {codePath, "/bin"}.
>> {expiryDate, {2009,12,24}}.
>> {icon, "/images/myIcon.png"}
>> {version,1}
>> {myKey1, ...}
>>
>> The keys codePath, version, and expiryDate are obligatory
>>
>> Why do we need code path? - so that Erlang can find
>> a module called C.erl
>>
>> Expiry date has a "time to live for the component"
>> Version is used for local configuration data (see later)
>> Version numbers should start at one and be increased by one
>> for each new release.
>
> Here I would like to have a consistent naming style. Until today most parts of Erlang don't use
> camel case. I like it in Smalltalk, and I like the consistency inside Scheme, and until today I
> like the consistency in Erlang. It's not like Python, where you can see which libs are from the
> Smalltalk or Java side, from the .NET side or the C side. Awful. So it should be called
> preferences.pl with code_path, expiry_date, and so on. Additionally I would like nested
> preferences. My Tideland CEL celcfg module handles this well.

I use names_like_this for function and module names but namesLikeThis
for atoms in code

>> Rule5: Local configuration data
>>
>> Local configuration data must not be stored under the
>> eComponents directory - (you can't remember we said the
>> component is in a read-only disk area - see rule2)
>>
>> Local data for the component C must be stored
>> in the directory
>>
>> $HOME/eLibrary/ComponentName/Vsn
>>
>> Thus local preferences for ejabberd version 1
>> would be stored in the file
>>
>> $HOME/eLibrary/ejabberd/1/Preferences.pl
>
> Ack, but see comments above about env variable and naming.
>
> Rule 6 and 7 again ack.
>
> Thx for this idea, Joe. I would like to make my Tideland EAS conforming to such a standard.

Great - I'm going to write a generic manager to support this. But I'd
like some discussion
in the list first.

>
> mue
>
> --
> **
> ** Frank Mueller / Oldenburg / Germany
> **
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

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

Re: A Generic API for controlling software components

2009-11-25T02:55:39Z

Hi Joe,

your idea sounds really good to me, even if I would like some changes.

> Draft 1 - 25 Nov 2009
>
> Rule1: All components are unpacked into the same top-level
> directory (default $HOME/eComponent) and have the extension
> .ec (Erlang component)
>
> Example: Imagine I have installed mochiweb ejabberd and couchDB
> then after installation I should see the following:
>
> $pwd
> /home/joe/eComponents
> $ls
> mochiweb.ec ejabberd.ec couchDB.ec

It's OK to have a default value for the directory, but I would like to have a defined variable
named $ECOMPONENT_HOME so that I can easily change it.

Rule 2 and 3 full ack.

> Rule4: All components C must have a file called
>
> $HOME/eComponents/C.ec/Preferences.pl
>
> The extension .pl means the file contains a property
> list. Here is an example:
>
> {codePath, "/bin"}.
> {expiryDate, {2009,12,24}}.
> {icon, "/images/myIcon.png"}
> {version,1}
> {myKey1, ...}
>
> The keys codePath, version, and expiryDate are obligatory
>
> Why do we need code path? - so that Erlang can find
> a module called C.erl
>
> Expiry date has a "time to live for the component"
> Version is used for local configuration data (see later)
> Version numbers should start at one and be increased by one
> for each new release.

Here I would like to have a consistent naming style. Until today most parts of Erlang don't use
camel case. I like it in Smalltalk, and I like the consistency inside Scheme, and until today I
like the consistency in Erlang. It's not like Python, where you can see which libs are from the
Smalltalk or Java side, from the .NET side or the C side. Awful. So it should be called
preferences.pl with code_path, expiry_date, and so on. Additionally I would like nested
preferences. My Tideland CEL celcfg module handles this well.

Ack, but see comments above about env variable and naming.

Rule 6 and 7 again ack.

Thx for this idea, Joe. I would like to make my Tideland EAS conforming to such a standard.

mue

--
**
** Frank Mueller / Oldenburg / Germany
**

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

A Generic API for controlling software components

2009-11-25T01:56:37Z

I would like to start a discussion about the generic control
of software components. Let me start by describing the problem
and a possible solution. I'd welcome feedback on this.

What's the problem?

To start with I'll use the term "component" rather than the word
"application" since the word application has specific meaning in the OTP
context.

To me a component is a black-box offering some functionality that I want
to use in my project.

Examples of components are couchDB, mochiweb, rabbitMQ, ejabberd, yaws
etc.

All these different components have chosen Ad Hock ways of controlling
them. The way that I control couchDB and yaws is completely different.
The way I upgrade the code is completely different.

What I would like to do is manage all the components in a uniform manner.
Much of this design is inspired by how Mac OS-X manages applications.

By manage I mean start and stop the component, upgrade the code,
change the behavior of the component at run time and so on.

Here's a suggestion for a set of rules for managed components:

Draft 1 - 25 Nov 2009

Rule1: All components are unpacked into the same top-level
directory (default $HOME/eComponent) and have the extension
.ec (Erlang component)

Example: Imagine I have installed mochiweb ejabberd and couchDB
then after installation I should see the following:

$pwd
/home/joe/eComponents
$ls
mochiweb.ec ejabberd.ec couchDB.ec

Rule2: A normal user should *never* have to examine any of the
files *inside* the component. To do so causes
"abstraction leakage" - I want to consider each of these
components as black boxes. Once installed the component
should be installed in a read-only disk area.

Rule3: The component should not break if relocated to a different
top-level directory. A simple "mv" command should suffice
So no hard-wired paths or links please.

Rule4: All components C must have a file called

$HOME/eComponents/C.ec/Preferences.pl

The extension .pl means the file contains a property
list. Here is an example:

{codePath, "/bin"}.
{expiryDate, {2009,12,24}}.
{icon, "/images/myIcon.png"}
{version,1}
{myKey1, ...}

The keys codePath, version, and expiryDate are obligatory

Why do we need code path? - so that Erlang can find
a module called C.erl

Expiry date has a "time to live for the component"
Version is used for local configuration data (see later)
Version numbers should start at one and be increased by one
for each new release.

Rule5: Local configuration data

Local configuration data must not be stored under the
eComponents directory - (you can't remember we said the
component is in a read-only disk area - see rule2)

Local data for the component C must be stored
in the directory

$HOME/eLibrary/ComponentName/Vsn

Thus local preferences for ejabberd version 1
would be stored in the file

$HOME/eLibrary/ejabberd/1/Preferences.pl

Rule6: Code upgrade

We should upgrade an component C when it's expiry date has
been reached. To update an component we delete the entire
component under $HOME/eComponents/C.ec we install the
new component and run the command: C:install().

Data that is to be carried over between different versions
of the component is stored in $HOME/eLibrary/C/V/...

Rule7: management

All components C must provide a module in the file
C_control.erl - so ejabberd provides ejabberd_control.erl

The management API is as follows:

C:start_link() -> Pid

create a controller process for the component.

Pid has the following protocol [see note 1 for notation]
PL is a property list (list of {Key::atom(), Value::any()}

Pid !! {start, PL} => ok | {error, Why}

Cold start the component. PL is a property
list describing how the component should behave

Pid !! {stop, PL} => ok

Stop the component

Pid !! {modify, PL} => ok | {error, Why}
Change the behavior of the component

Pid !! info => PL
Pid !! {info, [Keys]} => [Values]

Pid !! suspendLocal => ok
Pid !! resumeLocal => ok

Suspend the component data can be written to
$HOME/eLibrary/ComponentName/Vsn/...

Pid !! suspendRemote => <<BinaryClosure>>
Pid !! {resumeRemote, <<BinaryClosure>>} => ok

This ton suspend an component on one machine
and resume it on another

Notes:

[1] Notation

Pid !! M => A | B | C ...

Is my notation for for a remote procedure call

This means if you send Pid the message Pid ! {self(), M}
you will eventually be send one of the messages {Pid,A} or {Pid,B}, ...

/Joe

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

Re: Record typing for dialyzer

2009-11-24T23:44:06Z

Bernard Duggan wrote:

> Hi list,
> We have a lot of auto-generated record types that we use to allow
> our (newer, awesomer) erlang/mnesia code to interact with our (older,
> less awesome, but we're stuck with it for now) C++/mysql code. It
> recently occurred to me that it would be a simple matter to add type
> specifiers to the records to give dialyzer (which we love to death) some
> extra info to work with. And for the most part it was. So we now have
> nice auto-generated records of the form:
>
> -record( person{
> id :: integer(),
> name :: string(),
> is_awesome :: boolean()
> }).
>
> which is great (and already helped us find several bugs - have I
> mentioned we love dialyzer?). We struck a problem, however, when we
> used one of our records in a select statement thus:
>
> Match = #person{name="Bernie", id='$1', _='_'},
> mnesia:select(person, [{Match, [], [{{'$1'}}]}]),
>
> At this point, dialyzer quite correctly points out that '$1' isn't an
> integer and '_' isn't a boolean and so we've got no business assigning
> them to fields typed as such.
>
> My solution, then was to add an extra type definition:
>
> -type search_spec() :: '_' | '$1' | '$2' | '$3' | '$4' | '$5' | '$6' |
> '$7' | '$8' | '$9'.
>
> and change all the record definitions to something like:
>
> -record( person{
> id :: integer() | search_spec(),
> name :: string() | search_spec(),
> is_awesome :: boolean() | search_spec()
> }).
>
> Now this solves the problem, but it really looks ugly and seems like
> kind of a hack and I can't help but feel like there must be some more
> elegant solution. But I don't know what it is :) Any input (even if
> it's only "nope, there's no better way to do it") would be greatly
> appreciated.

I am not aware of any cleaner way of doing what you want to do, so what
you've done is how I would personally also do it. The only thing I
would recommend is to try to add these declarations as sparsely as
possible, meaning try to add them only to the record fields that are
used in match specifications in your program, not everywhere.

The problem is that you (and dialyzer) are up against a really bad
design decision in the language here, namely the use of "special" atoms
to represent variables in match specifications. I sincerely hope that
this is fixed by Erlang providing an alternative way of writing match
specifications that does not lie about types.

Thanks for your thumbs up for dialyzer!

Kostis

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

Re: Fastest pseudo-random number-generator: erlang:statistics(io) ?

2009-11-24T17:33:00Z

On Nov 25, 2:59 am, Jayson Vantuyl <kag...@...> wrote:
> Is it too slow to run the result through erlang:phash/2?

I tested it, erlang:phash2(erlang:statistics(io), 10) it still is
fast, but significantly slower than without. You are right that it
immediately scales the result, so i tested with scaling the
erlang:statistics(io) as well. I think the randomness (for my case)
will not improve a lot, but I will keep this function in mind.

On Nov 25, 12:10 am, "Zoltan Lajos Kis" <ki...@...> wrote:
> How about process_info(self(), reductions). ?
This one is also very fast (only a bit slower than statistics(io)),
but I am concerned about the randomness of this function (at least in
my case). I have many short-lived processes and it's likely that the
number of reductions for each process might be quite similar if they
follow similar code paths?

new benchmark results:

erlang_now req/sec 296667.7
stats_io req/sec 2638898.4
stats_wall_clock req/sec 289306.0
stats_runtime req/sec 522258.4
stats_reductions req/sec 484499.9
stats_cont_switch req/sec 491190.3
random_uniform req/sec 1109517.1
process_info_reduc req/sec 2410724.8
phash2_io req/sec 1773493.0
stats_io_scaled req/sec 2357073.0

tested like this:

---------------------------

test_random_speed(ParCount, SeqCount) ->
FunErlangNow = fun() -> erlang:now() end,
FunIO = fun() -> erlang:statistics(io) end,
FunWallClock = fun() -> erlang:statistics(wall_clock) end,
FunRuntime = fun() -> erlang:statistics(runtime) end,
FunReductions = fun() -> erlang:statistics(reductions) end,
FunContextSwitches = fun() -> erlang:statistics(context_switches)
end,
FunRandomUniform = fun() -> random:uniform() end,
FunProcessInfoRed = fun() -> erlang:process_info(self(), reductions)
end,
FunPhashIO = fun() -> erlang:phash2(erlang:statistics(io), 10) end,
FunIOScaled = fun() ->
{{input, Input}, {output, Output}} = erlang:statistics(io),
(Input+Output) rem 10
end,

test_fun_x_times_parallel(erlang_now, FunErlangNow, ParCount,
SeqCount),
test_fun_x_times_parallel(stats_io, FunIO, ParCount, SeqCount),
test_fun_x_times_parallel(stats_wall_clock, FunWallClock, ParCount,
SeqCount),
test_fun_x_times_parallel(stats_runtime, FunRuntime, ParCount,
SeqCount),
test_fun_x_times_parallel(stats_reductions, FunReductions, ParCount,
SeqCount),
test_fun_x_times_parallel(stats_cont_switch, FunContextSwitches,
ParCount, SeqCount),
test_fun_x_times_parallel(random_uniform, FunRandomUniform, ParCount,
SeqCount),
test_fun_x_times_parallel(process_info_reduc, FunProcessInfoRed,
ParCount, SeqCount),
test_fun_x_times_parallel(phash2_io, FunPhashIO, ParCount, SeqCount),
test_fun_x_times_parallel(stats_io_scaled, FunIOScaled, ParCount,
SeqCount),
ok.

test_fun_x_times_parallel(Name, Fun, ParCount, SeqCount) ->
Tick = now(),
app_util:pmap(
fun(_) ->
lists:foreach(fun(_) ->
Fun()
end,
lists:seq(1, SeqCount))
end,
lists:seq(1, ParCount),
[],
250000),
Tock = now(),
AvgTime = timer:now_diff(Tock, Tick)/1000,
Speed = ParCount*SeqCount*1000/AvgTime,
io:format("~20w req/sec ~10.1f ~n", [Name, Speed]),
Speed.

pmap(Fun, List, Nodes, Timeout) ->
SpawnFun =
case length(Nodes) of
0 ->
fun spawn/1;
Length ->
NextNode = fun() -> lists:nth(random:uniform(Length), Nodes) end,
fun(F) -> spawn(NextNode(), F) end
end,
Parent = self(),
Pids =
[
SpawnFun(fun() -> Parent ! {self(), (catch Fun(Elem))} end)
|| Elem <- List
],
[
receive
{Pid, Val} -> Val
after Timeout ->
exit(timeout)
end
|| Pid <- Pids
].

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

- Thijs Terlouw, Shenzhen, China

Re: Record typing for dialyzer

2009-11-24T16:51:41Z

That was another other option I toyed with - I ended up coming down on
the side of keeping the "code" as un-hacked as possible and just messing
with the headers and auto-generated stuff. My reasoning being that I
didn't want others in the team to have to re-solve the problem every
time they wanted to use a select() statement. Not that I'm saying it's
not a perfectly valid solution, just explaining why I didn't choose it :)

Cheers,

B

Paul Mineiro wrote:

> I had the same problem.
>
> I ended up keeping the type signature in the declaration strict, and using
> setelement/3 to construct the type-violating version of the record that I
> pass to mnesia:select/2.
>
> -- p
>
> On Wed, 25 Nov 2009, Bernard Duggan wrote:
>
>
>> Hi list,
>> We have a lot of auto-generated record types that we use to allow
>> our (newer, awesomer) erlang/mnesia code to interact with our (older,
>> less awesome, but we're stuck with it for now) C++/mysql code. It
>> recently occurred to me that it would be a simple matter to add type
>> specifiers to the records to give dialyzer (which we love to death) some
>> extra info to work with. And for the most part it was. So we now have
>> nice auto-generated records of the form:
>>
>> -record( person{
>> id :: integer(),
>> name :: string(),
>> is_awesome :: boolean()
>> }).
>>
>> which is great (and already helped us find several bugs - have I
>> mentioned we love dialyzer?). We struck a problem, however, when we
>> used one of our records in a select statement thus:
>>
>> Match = #person{name="Bernie", id='$1', _='_'},
>> mnesia:select(person, [{Match, [], [{{'$1'}}]}]),
>>
>> At this point, dialyzer quite correctly points out that '$1' isn't an
>> integer and '_' isn't a boolean and so we've got no business assigning
>> them to fields typed as such.
>>
>> My solution, then was to add an extra type definition:
>>
>> -type search_spec() :: '_' | '$1' | '$2' | '$3' | '$4' | '$5' | '$6' |
>> '$7' | '$8' | '$9'.
>>
>> and change all the record definitions to something like:
>>
>> -record( person{
>> id :: integer() | search_spec(),
>> name :: string() | search_spec(),
>> is_awesome :: boolean() | search_spec()
>> }).
>>
>> Now this solves the problem, but it really looks ugly and seems like
>> kind of a hack and I can't help but feel like there must be some more
>> elegant solution. But I don't know what it is :) Any input (even if
>> it's only "nope, there's no better way to do it") would be greatly
>> appreciated.
>>
>> Cheers,
>>
>> Bernard
>>
>> ________________________________________________________________
>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>> erlang-questions (at) erlang.org
>>
>>
>>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

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

Re: Record typing for dialyzer

2009-11-24T16:21:56Z

I had the same problem.

I ended up keeping the type signature in the declaration strict, and using
setelement/3 to construct the type-violating version of the record that I
pass to mnesia:select/2.

-- p

On Wed, 25 Nov 2009, Bernard Duggan wrote:

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

Re: Re: list size 'causing VM "problems"

2009-11-24T16:18:12Z

Hendrik Visage wrote:
> the:
> List=read_lines(FD).
> executes, doesn't *appear* to be using lots of VM space, and it
> outputs the partial (being the shell it only prints a part of the
> lines with the [...]...] stuff.

This appears to be an improvement!

> Then it *hangs* at that, not showing the prompt (this is inside
> Aquamacs's erlang shell mode). This is then where it appears the
> system goes "west", as the memory utilization (as measured/shown by
> the MacOSX Activity Monitor) starts to grow and grow. with the last
> test (using the Accumulator as below) it grew to 7G at which point I
> killed the beam.smp process.

Next I'd suspect your regex is causing issues. Try some logging to
figure out what lines are causing issues with the regex expression you
defined (and perhaps incorporate Ulf's suggestion to use binaries).

If you don't find a solution there, it could well be that you'll have to
push the results out to ETS as Ulf suggested (and my experience is that
Ulf is generally right about such things - not to mention the fact that
he has many more years of experience with OTP than I do).

/s

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

Record typing for dialyzer

2009-11-24T15:37:28Z

Hi list,
We have a lot of auto-generated record types that we use to allow
our (newer, awesomer) erlang/mnesia code to interact with our (older,
less awesome, but we're stuck with it for now) C++/mysql code. It
recently occurred to me that it would be a simple matter to add type
specifiers to the records to give dialyzer (which we love to death) some
extra info to work with. And for the most part it was. So we now have
nice auto-generated records of the form:

-record( person{
id :: integer(),
name :: string(),
is_awesome :: boolean()
}).

which is great (and already helped us find several bugs - have I
mentioned we love dialyzer?). We struck a problem, however, when we
used one of our records in a select statement thus:

Match = #person{name="Bernie", id='$1', _='_'},
mnesia:select(person, [{Match, [], [{{'$1'}}]}]),

At this point, dialyzer quite correctly points out that '$1' isn't an
integer and '_' isn't a boolean and so we've got no business assigning
them to fields typed as such.

My solution, then was to add an extra type definition:

-type search_spec() :: '_' | '$1' | '$2' | '$3' | '$4' | '$5' | '$6' |
'$7' | '$8' | '$9'.

and change all the record definitions to something like:

-record( person{
id :: integer() | search_spec(),
name :: string() | search_spec(),
is_awesome :: boolean() | search_spec()
}).

Now this solves the problem, but it really looks ugly and seems like
kind of a hack and I can't help but feel like there must be some more
elegant solution. But I don't know what it is :) Any input (even if
it's only "nope, there's no better way to do it") would be greatly
appreciated.

Cheers,

Bernard

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

Nabble - Erlang Questions

Re: Erlang/OTP now at Github

Re: Fastest pseudo-random number-generator: erlang:statistics(io) ?

Erlang R13B03 *EXPERIMENTAL* FreeBSD port

Re: How to match on a nested record against a dict

Re: A Generic API for controlling software components

Re: Erlang/OTP now at Github

Re: A Generic API for controlling software components

Re: A Generic API for controlling software components

Re: Erlang "object-oriented" after all?

Re: Question about erlang.log

Re: Erlang/OTP now at Github

Re: Erlang/OTP R13B03 has been released

Question about erlang.log

Re: Erlang/OTP now at Github

Re: Erlang "object-oriented" after all?

Erlang/OTP now at Github

Re: mnesia:transform_table

Re: mnesia:transform_table

Erlang/OTP R13B03 has been released

Re: mnesia:transform_table

Re: mnesia:transform_table

Re: A Generic API for controlling software components

mnesia:transform_table

Re: A Generic API for controlling software components

Re: A Generic API for controlling software components

Re: A Generic API for controlling software components

Re: A Generic API for controlling software components

Re: A Generic API for controlling software components

A Generic API for controlling software components

Re: Record typing for dialyzer

Re: Fastest pseudo-random number-generator: erlang:statistics(io) ?

Re: Record typing for dialyzer

Re: Record typing for dialyzer

Re: Re: list size 'causing VM "problems"

Record typing for dialyzer

Erlang R13B03 EXPERIMENTAL FreeBSD port