headers
Ricardo Catalinas Jiménez | 4 Feb 16:55
Picon
Gravatar

Fix port leaking after controlling_process(Port, self())

I spotted the same issue that Max Lapshin reported in:

http://erlang.org/pipermail/erlang-questions/2011-April/057944.html

Add case to handle the situation when someone call
{gen_tcp,gen_udp}:controlling_process(Port, self()). Also improve spec
and doc from gen_udp and gen_sctp for controlling_process/2.

To reproduce the issue, open an UDP port:

4> {ok,Port} = gen_udp:open(9000, [binary]).
{ok,#Port<0.587>}
5> gen_udp:controlling_process(Port, self()).
ok

Simulate error:

6> 1=2.
** exception error: no match of right hand side value 2

Here is the leak:

7> inet:i().
Port Module   Recv Sent Owner    Local Address Foreign Address State
Type
581  inet_udp 0    0    <0.31.0> *:cslistener  *:*             BOUND
DGRAM
ok

Please fetch:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ricardo Catalinas Jiménez | 4 Feb 17:03
Picon
Gravatar

Fix typo in `compile' doc: unmatched parenthesis

Please fetch:
git fetch git://github.com/jimenezrick/otp.git fix-compile-doc-typo

Review here:
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-compile-doc-typo
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-compile-doc-typo.patch

By the way, could be also possible to add this another patch that I
already sent to erlang-patches?

Set `font-family: Courier, monospace' in OTP doc CSS

This should be much better for everybody, I left Courier as the primary
original font and also added monospace as secondary for people like me
which in Linux haven't it installed.

It should be more pleasant to read typespecs and code examples. Also
adds minor cosmetic changes to the CSS.

Please fetch:
git fetch git://github.com/jimenezrick/otp.git doc-monospace-css

Review here:
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:doc-monospace-css
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:doc-monospace-css.patch

Regards
--

-- 
Ricardo (http://r.untroubled.be/)
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ricardo Catalinas Jiménez | 5 Feb 01:16
Picon
Gravatar

Fix the type spec from the doc of binary:part/3

As the doc explains, the Len of part() can be negative.

Please fetch:
git fetch git://github.com/jimenezrick/otp.git fix-binary-doc-spec

Review here:
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-binary-doc-spec
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-binary-doc-spec.patch

Regards
--

-- 
Ricardo (http://r.untroubled.be/)
_______________________________________________
erlang-patches mailing list
erlang-patches <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-patches
Permalink | Reply | 1 comment |
headers
Richard Carlsson | 5 Feb 22:15
Picon
Gravatar

add compiler checked atoms

Sorry, pressed send too soon in the last attempt. Here is the code:

   git fetch git <at> github.com:richcarl/otp.git warn-unknown-atom

Here is a suggested patch to the compiler, that I'm throwing out there 
as a request for comments. In any large code base, it can be hard to 
maintain atom hygiene - you may have hidden errors due to misspelled 
atoms, people may be adding atoms without much thought, and it can be 
hard to track which atoms are being used where and for what (e.g., atoms 
used for options, error indicators, message tags, callback module and 
function names, etc. This allows you to declare your atoms like so:

   -atoms([foo, bar]).

You can have any number of such declarations, and an atom may occur 
multiple times and/or in different declarations - it's the union of 
known atoms that matters. Note that this declaration is backwards 
compatible; the current compiler will accept it as a generic attribute 
with no particular meaning.

If you specify the compiler option `warn_unused_atom' when compiling a 
module (you can put `-compile([warn_unused_atom]).' in the module if you 
want to enable the checking in that module only), you will get a warning 
for each atom that has not been explicitly declared. The compiler knows 
about standard atoms such as `ok', `true', `false', `undefined' etc., 
and it does not check function and module names in calls, or record 
names and fields of records, since these are checked in other ways already.

I don't think this addition warrants an EEP, since it doesn't change the 
language as such; it only adds a backwards compatible feature to the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michael Truog | 5 Feb 22:34
Picon
Gravatar

Re: add compiler checked atoms

This is very cool.  It could help document complex code by making atom usage more transparent within the
module, while also preventing errors.  I mention the documentation part, since having the atom
declaration gives the opportunity for comments specific to that atom declaration (so you could have atom
declarations as logical groupings, similar to what is commonly done for export declarations).  Do atoms
used within the spec declarations need to be mentioned within the atom declaration when using this
compiler flag?  That might bring in a lot of external module atom dependencies, which might be counter-productive.

On 02/05/2012 01:15 PM, Richard Carlsson wrote:
> Sorry, pressed send too soon in the last attempt. Here is the code:
>
>   git fetch git <at> github.com:richcarl/otp.git warn-unknown-atom
>
> Here is a suggested patch to the compiler, that I'm throwing out there as a request for comments. In any
large code base, it can be hard to maintain atom hygiene - you may have hidden errors due to misspelled
atoms, people may be adding atoms without much thought, and it can be hard to track which atoms are being
used where and for what (e.g., atoms used for options, error indicators, message tags, callback module
and function names, etc. This allows you to declare your atoms like so:
>
>   -atoms([foo, bar]).
>
> You can have any number of such declarations, and an atom may occur multiple times and/or in different
declarations - it's the union of known atoms that matters. Note that this declaration is backwards
compatible; the current compiler will accept it as a generic attribute with no particular meaning.
>
> If you specify the compiler option `warn_unused_atom' when compiling a module (you can put
`-compile([warn_unused_atom]).' in the module if you want to enable the checking in that module only),
you will get a warning for each atom that has not been explicitly declared. The compiler knows about
standard atoms such as `ok', `true', `false', `undefined' etc., and it does not check function and module
names in calls, or record names and fields of records, since these are checked in other ways already.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Carlsson | 5 Feb 22:57
Picon
Gravatar

Re: add compiler checked atoms

On 02/05/2012 10:34 PM, Michael Truog wrote:
> This is very cool.  It could help document complex code by making
> atom usage more transparent within the module, while also preventing
> errors.  I mention the documentation part, since having the atom
> declaration gives the opportunity for comments specific to that atom
> declaration (so you could have atom declarations as logical
> groupings, similar to what is commonly done for export declarations).
> Do atoms used within the spec declarations need to be mentioned
> within the atom declaration when using this compiler flag?  That
> might bring in a lot of external module atom dependencies, which
> might be counter-productive.

No, atoms occurring in -spec and -type declarations are not checked. As 
you say, that could force you to declare a lot more atoms than you want. 
You'll have to run Dialyzer to check the consistency of specs.

What you mention about groupings of atoms is exactly the sort of thing I 
had in mind. Here are some examples from eunit, which I used as a test 
bed for this feature:

%% used in options
-atoms([verbose, report, no_tty, event_log, enqueue, eunit_test_suffix,
         eunit_generator_suffix, eunit_export_suffix]).

%% atoms used in test representations
-atoms([module, application, file, dir, generator, with, local, spawn,
         local, remote, timeout, inorder, inparallel, setup, node,
         foreach, foreachx]).

%% used by erlang:fun_info/2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ricardo Catalinas Jiménez | 8 Feb 01:05
Picon
Gravatar

Fix typo in supervisor behaviour doc

Remove unnecessary &gt; from a CDATA section.

Please fetch:
git fetch git://github.com/jimenezrick/otp.git fix-sup-doc-typo

Review here:
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-sup-doc-typo
https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-sup-doc-typo.patch

Regards
--

-- 
Ricardo (http://r.untroubled.be/)
_______________________________________________
erlang-patches mailing list
erlang-patches <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-patches
Permalink | Reply | 1 comment |
headers
Fred Hebert | 9 Feb 04:24
Picon

Shell History to Erlang

Hi there,

I have made a hack named erlang-history available a few months ago and since then I've kept maintaining it in a public repo on github (https://github.com/ferd/erlang-history).

It's basically just a small modification to kernel/group.erl and a new module called group_history.erl. I've used DETS tables at this point in time, as it was (at first) easy to store stuff that way. The old requests are injected into the shell when it first starts up (and it does so for all instances of the shell on a given node). They're saved to disk when the command stack/zipper gets saved after a new line.

The other reason for using DETS, aside for not reinventing stuff, is that it's part of stdlib, which is always there anyway. The only downside is that repairing DETS tables uses the group leader and when the group.erl group leader calls it, it can get stuck in a loop -- that's accounted for in the code.

Anyway, it also supports a full set of options, added to 'kernel': number of lines saved, where to save them, terms to drop from history, etc. They're described in the README of the repository.

To make a long story short, I'm wondering if this kind of material has any chance of making it into OTP proper, rather than just being a hack/patch to apply after installing Erlang.

I know there are no tests, but then, group.erl also has no tests and it's difficult to test it all (which I figure could make the OTP team reluctant to including it). I could add tests for the group_history.erl module itself if required though, but some features would definitely be hard to properly test (such as the group leader stuff above).

Regards,
Fred Hebert.


_______________________________________________
erlang-patches mailing list
erlang-patches <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-patches
Permalink | Reply | 1 comment |
headers
Scott Lystig Fritchie | 10 Feb 08:02

Re: DTrace patch, review draft #3

Henrik Nord wrote a while ago, while I was working on another project:

hn> Been a while sens we got any news for this.
hn> The last branch you submitted, this draft #3 I think it was, did not 
hn> compile, and you where in contact with Bj<F6>rn and or Bj<F6>rn-Egil. Then

Hi, Henrik.  That branch worked fine for me.  :-)

hn> there was a release here and we did not really think about this for a
hn> while.

Ja, that branch didn't work so well on the R15B release.  There were
a couple of not-so-nice conflicts, due to a late addition of an Opts
property list to file:read_file_info() and a couple other file.erl
functions.

hn> So now im looking at my branches and there are no Dtrace here.

Well, nothing new in a while.  Sorry about that.  I've been working on
other stuff for the past while....

hn> Do you need assistance from us with something? there was talk about 
hn> loader support?

Last I heard, there was going to be some hackery done by the OTP team.
That hackery would load one of two versions of prim_file.beam, depending
on whether or not DTrace support was available.

I didn't hear anything about that hackery being done, or started, so I
figured y'all were busy working on other stuff.  So I didn't spend much
time on fixing the merge conflict.  To be honest, except for you, nobody
elseuntil today (09 Feb 2012) had asked me about an update for DTrace and
R15B.  {sigh}

hn> Let me know what version of the branch you want us to test and how/if we 
hn> may be of assistance so that we can add that to our plans.

So, I got blessed time from $DAYJOB to finish work on the DTrace stuff.
I've pushed two new branches to git://github.com/slfritchie/otp.git this
evening:

    * dtrace-review4-OTP_R15B, which is DTrace work rebased & conflicts
      fixed, based upon the "OTP_R15B" tag from the OTP team's GitHub
      repo.

    * dtrace-review4-upstream-maint, which is the same rebased & fixed
      stuff, based upon the 09 Feb 2012 "maint" branch of the OTP repo.

I haven't run all of the test suite yet, only the "kernel" portion.  And
only on OS X.  Using code based on the "OTP_R15B" tag, I see 6 test
failures.  Using the "dtrace-review4-upstream-maint" branch, I see 7 test
failures (code_SUITE, big_boot_embedded fails with a timeout).

So, I can do more testing on OS X, Linux, and Solaris boxes and letting
the whole test suite run overnight.

It'd be nice to know if/when y'all were thinking of doing the code loader
hacks.  I also haven't been paying much attention to any rumors of if/when
R15B01 might be frozen.

-Scott
_______________________________________________
erlang-patches mailing list
erlang-patches <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-patches
Permalink | Reply | 0 comments |
headers
Scott Lystig Fritchie | 10 Feb 19:39

Re: DTrace patch, review draft #3

Patrik Nyblom <pan <at> erix.ericsson.se> wrote:

pn> Ouch - guess I should have told you I was starting to work on this a
pn> few days ago - I (with the help of Bjorn-Egil) did the same rebase
pn> as You now have done and started figuring out how to make a hack for
pn> the io-stuff that will affect the non-dtrace version less. I'll take
pn> a look at your rebase and see what we'we missed!

Hej, that's alright.  When I saw the merge conflict, I was afraid that
I'd also have to fix up the protocol junk between prim_file.erl and
efile_drv.c.  That was a depressing thought, so I avoided it for weeks.
When I finally took a close look, the fear was unfounded, hooray.

So, I believe that all the changes between dtrace-review3 and the
dtrace-review4* branches can be seen on the dtrace-experiment+michal2
branch, between these commits:

    adbfd650334d97e02c1290fe5ce6e433c75746e5
    0d30b9356e56acacd144c758cfabacca60d0b110

The dtrace-experiment+michal2 branch is based on R14B, so there are
conflicts when applying them to R15B.  There's also the possibility that
I missed something when applying to R15B.  There request/requirement
that everything be squashed down to only 4 commits and that the 4
commits have no overlapping files ... has caused me headache and
occasional swearing at git.

pn> Anyway, except for the fact that I let you do a rebase work that was
pn> already in some parts done (*blush*), I'm glad to inform you that we
pn> are working on getting the dtrace support upstream for the next
pn> service release. Unless something horrible happens, I see no reason
pn> for this to fail.

That is very, very good news.

We (meaning Basho Technologies) have had the "dtrace-r14b04" branch
running in production on a customer's 60 node Solaris cluster for the
last several weeks.  We are only very infrequently using the Erlang VM
USDT probes, so it's possible that a bug somethere could cause a crash
when the probe is enabled.  But that cluster has been serving over 1
billion Riak requests per day, and that has given us a lot of confidence
that nothing is badly broken.  ^_^

pn> I'm working on a solution where a mechanism similar to sequential
pn> tracing will make the dtrace user tag follow messages through the
pn> i/o-system. If I succeed, almost all changes to the erlang code that
pn> was there to manage the complexity of the i/o-system would
pn> disappear. I have great hopes for this :) I'll push a branch for you
pn> to look at as soon as I have something useful!

I look forward to seeing it!

-Scott
_______________________________________________
erlang-patches mailing list
erlang-patches <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-patches
Permalink | Reply | 0 comments |

Gmane