Nabble - Erlang Bugs

[R13B02] Error message and duplicate menu item after debugger:start() on Mac OS X 10.6.1

2009-12-15T04:36:20Z

The following bug was observed running Erlang R13B02 on Mac OS X 10.6.1

Start an erl shell:
erl

Start the debugger:
debugger:start().

The debugger window opens.

At this point in time the menu items for the debugger window are: beam.smp,
File, Edit, Module, Process, Break, Options, Windows, Help, Window.

Click on the Help menu item. A drop down menu with the options Search and
Debugger appears.

In the Erl shell the following error message appears:

2009-12-15 07:18:10.894 beam.smp[2675:3903] Calling -[NSMenuItemViewer
_getMenuItemViewerHIViewClassRegisteringIfNecessary] off the main thread.
This is not supported and will likely crash.

The menu changes and now includes the following items: beam.smp, File, Edit,
Module, Process, Break, Options, Windows, Help, Window, Help.

Note that the Help item is present twice. The first Help item has a drop
down menu with a single item Debugger. The second Help item has a drop down
menu with a single item Search.

Re: Recursive Make Considered Harmful (OT?)

2009-12-15T02:14:51Z

On 12/15/2009, "Bengt Kleberg" <bengt.kleberg@...> wrote:

>Perhaps I am mistaken, but I think the solution presented in the paper,
>while being better than recursive make, is cumbersome and fragile. So I
>would say that make is lacking, once the project leaves a single
>directory.

What do you mean by "leaves a single directory?" The only
interpretation I can think of is: "has source files in more than one
directory." Whatever the demerits of the approach suggested, it's
clearly not limited to single-directory builds. It's a way to have one
big makefile (composed of some fragments of makefiles in subdirectories)
for something you're building in several directories.

From the beginning of the Implementation Notes:

"The most basic problem to overcome when implementing single-session
make is to avoid flattening your directory structure, while joining the
dependency information present in each subdirectory in a single tree."

So what did you mean by "leaves a single directory"?

-michael turner

>On Mon, 2009-12-14 at 13:07 -0500, Toby Thain wrote:
>> On 14-Dec-09, at 5:47 AM, Michael Turner wrote:
>>
>> >
>> > http://miller.emu.id.au/pmiller/books/rmch/
>> >
>> > Thanks for this. I wasn't on the list when you first mentioned this
>> > paper. I vaguely remembered just such a paper while trying to build an
>> > Erlang release a few months ago. It struck me as a breath of fresh
>> > air
>> > when I first read it over a decade ago.
>> >
>> > It's not so much that "make" is lacking, I think.
>>
>> Right, the problem isn't with 'make' per se, which the paper serves
>> to prove.
>>
>> --Toby
>>
>> > Mainly it's that
>> > the obvious approach (recursion) for building stuff out of a
>> > hierarchical directory structure is not necessarily the best way if
>> > you're using make.
>> >
>> > Having one big makefile seems, of course, horribly inelegant. But
>> > when
>> > I've tried that approach, it always reminds me of things I'd forgotten
>> > while using big, lumbering, recursive build systems. Like, make is
>> > really fast. Compilers are pretty fast, too. And having
>> > everything in
>> > one place can be nice.
>> >
>> > -michael turner
>> >
>> > On 12/14/2009, "Bengt Kleberg" <bengt.kleberg@...> wrote:
>> >
>> >> Greetings,
>> >>
>> >> It has been well over a year since last time I mentioned this paper
>> >> "Recursive Make Considered Harmful",
>> >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok
>> >> that I
>> >> do it again.
>> >>
>> >> Nice little reading for those that find themselves wondering if
>> >> they are
>> >> the only ones that think make is somewhat lacking, at times.
>> >>
>> >>
>> >> bengt
>> >>
>> >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:
>> >>> Hi!
>> >>>
>> >>> I did some further investigations and found that simply calling make
>> >>> in all doc/src
>> >>> directories works better then trying to run make recursively.
>> >>>
>> >>> pwd=`pwd`
>> >>> for i in `find . -wholename '*/doc/src'` ; do
>> >>> (cd $i ; make man ERL_TOP=$pwd )
>> >>> done
>> >>>
>> >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached
>> >>> docb_gen script)
>> >>> generates manpages perfectly, make html and make pdf though
>> >>> suffer from runtime
>> >>> errors while running xsltproc.
>> >>>
>> >>> Running make recursively reveals a whole bunch of problems with
>> >>> missing and redefined
>> >>> 'docs' targets in makefiles.
>> >>>
>> >>> On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:
>> >>>> Hi Sergei,
>> >>>> we started to build our documentation with open source tools in
>> >>>> R13B03 so it
>> >>>> would be possible to build the doc from the delivered sources.
>> >>>>
>> >>>> But it's still only built in house because we hadn't time to
>> >>>> test it but the plan is
>> >>>> to have it work for everyone in R13B04.
>> >>>>
>> >>>> Thanks for your report, we'll have a look at those fault.
>> >>>>
>> >>>> Regards Lars
>> >>>>
>> >>>>
>> >>>> Sergei Golovan wrote:
>> >>>>> Hi!
>> >>>>>
>> >>>>> I'm trying to build Erlang documentation from the sources (the
>> >>>>> goal is
>> >>>>> to switch from prebuilt docs for Debian Erlang packages as
>> >>>>> building
>> >>>>> them from the source is preferable).
>> >>>>>
>> >>>>> To do that I run
>> >>>>> make
>> >>>>> make TYPE=docs
>> >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace
>> >>>>> "make
>> >>>>> opt" by "make $(TYPE) in the top-level Makefile).
>> >>>>>
>> >>>>> and I've found several problems which make build fail:
>> >>>>>
>> >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc
>> >>>>> reports
>> >>>>> runtime errors about undefined variables (partnum in line 871
>> >>>>> and 963
>> >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this
>> >>>>> a bug
>> >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian
>> >>>>> stable and
>> >>>>> 1.1.26 from Debian unstable failed.)
>> >>>>>
>> >>>>> 2) wx application has duplicated targets html and docs in its
>> >>>>> makefile.
>> >>>>>
>> >>>>> 3) wx application (and others too) require docb_gen script to
>> >>>>> generate
>> >>>>> XML docs sources. It is missing. (I suppose that it is a simple
>> >>>>> wrapper around docb_gen Erlang module and could be recreated,
>> >>>>> but It'd
>> >>>>> be better if it were shipped in Erlang sources.)
>> >>>>>
>> >>>>> Is Erlang documentation supposed to be buildable from the
>> >>>>> source, or
>> >>>>> it still requires some unavailable tools?
>> >>>>>
>> >>>>> Cheers!
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> ________________________________________________________________
>> >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> >>> erlang-bugs (at) erlang.org
>> >>
>> >>
>> >> ________________________________________________________________
>> >> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> >> erlang-bugs (at) erlang.org
>> >>
>> >>
>> >
>> > ________________________________________________________________
>> > erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> > erlang-bugs (at) erlang.org
>> >
>>
>
>
>________________________________________________________________
>erlang-bugs mailing list. See http://www.erlang.org/faq.html
>erlang-bugs (at) erlang.org
>
>

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

OT: Re: Recursive Make Considered Harmful

2009-12-15T00:55:16Z

Greetings,

Perhaps I am mistaken, but I think the solution presented in the paper,
while being better than recursive make, is cumbersome and fragile. So I
would say that make is lacking, once the project leaves a single
directory.

bengt

On Mon, 2009-12-14 at 13:07 -0500, Toby Thain wrote:

> On 14-Dec-09, at 5:47 AM, Michael Turner wrote:
>
> >
> > http://miller.emu.id.au/pmiller/books/rmch/
> >
> > Thanks for this. I wasn't on the list when you first mentioned this
> > paper. I vaguely remembered just such a paper while trying to build an
> > Erlang release a few months ago. It struck me as a breath of fresh
> > air
> > when I first read it over a decade ago.
> >
> > It's not so much that "make" is lacking, I think.
>
> Right, the problem isn't with 'make' per se, which the paper serves
> to prove.
>
> --Toby
>
> > Mainly it's that
> > the obvious approach (recursion) for building stuff out of a
> > hierarchical directory structure is not necessarily the best way if
> > you're using make.
> >
> > Having one big makefile seems, of course, horribly inelegant. But
> > when
> > I've tried that approach, it always reminds me of things I'd forgotten
> > while using big, lumbering, recursive build systems. Like, make is
> > really fast. Compilers are pretty fast, too. And having
> > everything in
> > one place can be nice.
> >
> > -michael turner
> >
> > On 12/14/2009, "Bengt Kleberg" <bengt.kleberg@...> wrote:
> >
> >> Greetings,
> >>
> >> It has been well over a year since last time I mentioned this paper
> >> "Recursive Make Considered Harmful",
> >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok
> >> that I
> >> do it again.
> >>
> >> Nice little reading for those that find themselves wondering if
> >> they are
> >> the only ones that think make is somewhat lacking, at times.
> >>
> >>
> >> bengt
> >>
> >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:
> >>> Hi!
> >>>
> >>> I did some further investigations and found that simply calling make
> >>> in all doc/src
> >>> directories works better then trying to run make recursively.
> >>>
> >>> pwd=`pwd`
> >>> for i in `find . -wholename '*/doc/src'` ; do
> >>> (cd $i ; make man ERL_TOP=$pwd )
> >>> done
> >>>
> >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached
> >>> docb_gen script)
> >>> generates manpages perfectly, make html and make pdf though
> >>> suffer from runtime
> >>> errors while running xsltproc.
> >>>
> >>> Running make recursively reveals a whole bunch of problems with
> >>> missing and redefined
> >>> 'docs' targets in makefiles.
> >>>
> >>> On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:
> >>>> Hi Sergei,
> >>>> we started to build our documentation with open source tools in
> >>>> R13B03 so it
> >>>> would be possible to build the doc from the delivered sources.
> >>>>
> >>>> But it's still only built in house because we hadn't time to
> >>>> test it but the plan is
> >>>> to have it work for everyone in R13B04.
> >>>>
> >>>> Thanks for your report, we'll have a look at those fault.
> >>>>
> >>>> Regards Lars
> >>>>
> >>>>
> >>>> Sergei Golovan wrote:
> >>>>> Hi!
> >>>>>
> >>>>> I'm trying to build Erlang documentation from the sources (the
> >>>>> goal is
> >>>>> to switch from prebuilt docs for Debian Erlang packages as
> >>>>> building
> >>>>> them from the source is preferable).
> >>>>>
> >>>>> To do that I run
> >>>>> make
> >>>>> make TYPE=docs
> >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace
> >>>>> "make
> >>>>> opt" by "make $(TYPE) in the top-level Makefile).
> >>>>>
> >>>>> and I've found several problems which make build fail:
> >>>>>
> >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc
> >>>>> reports
> >>>>> runtime errors about undefined variables (partnum in line 871
> >>>>> and 963
> >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this
> >>>>> a bug
> >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian
> >>>>> stable and
> >>>>> 1.1.26 from Debian unstable failed.)
> >>>>>
> >>>>> 2) wx application has duplicated targets html and docs in its
> >>>>> makefile.
> >>>>>
> >>>>> 3) wx application (and others too) require docb_gen script to
> >>>>> generate
> >>>>> XML docs sources. It is missing. (I suppose that it is a simple
> >>>>> wrapper around docb_gen Erlang module and could be recreated,
> >>>>> but It'd
> >>>>> be better if it were shipped in Erlang sources.)
> >>>>>
> >>>>> Is Erlang documentation supposed to be buildable from the
> >>>>> source, or
> >>>>> it still requires some unavailable tools?
> >>>>>
> >>>>> Cheers!
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> ________________________________________________________________
> >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> >>> erlang-bugs (at) erlang.org
> >>
> >>
> >> ________________________________________________________________
> >> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> >> erlang-bugs (at) erlang.org
> >>
> >>
> >
> > ________________________________________________________________
> > erlang-bugs mailing list. See http://www.erlang.org/faq.html
> > erlang-bugs (at) erlang.org
> >
>

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

Re: Re: Recursive Make Considered Harmful

2009-12-14T10:07:18Z

On 14-Dec-09, at 5:47 AM, Michael Turner wrote:

>
> http://miller.emu.id.au/pmiller/books/rmch/
>
> Thanks for this. I wasn't on the list when you first mentioned this
> paper. I vaguely remembered just such a paper while trying to build an
> Erlang release a few months ago. It struck me as a breath of fresh
> air
> when I first read it over a decade ago.
>
> It's not so much that "make" is lacking, I think.

Right, the problem isn't with 'make' per se, which the paper serves
to prove.

--Toby

> Mainly it's that
> the obvious approach (recursion) for building stuff out of a
> hierarchical directory structure is not necessarily the best way if
> you're using make.
>
> Having one big makefile seems, of course, horribly inelegant. But
> when
> I've tried that approach, it always reminds me of things I'd forgotten
> while using big, lumbering, recursive build systems. Like, make is
> really fast. Compilers are pretty fast, too. And having
> everything in
> one place can be nice.
>
> -michael turner
>
> On 12/14/2009, "Bengt Kleberg" <bengt.kleberg@...> wrote:
>
>> Greetings,
>>
>> It has been well over a year since last time I mentioned this paper
>> "Recursive Make Considered Harmful",
>> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok
>> that I
>> do it again.
>>
>> Nice little reading for those that find themselves wondering if
>> they are
>> the only ones that think make is somewhat lacking, at times.
>>
>>
>> bengt
>>
>> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:
>>> Hi!
>>>
>>> I did some further investigations and found that simply calling make
>>> in all doc/src
>>> directories works better then trying to run make recursively.
>>>
>>> pwd=`pwd`
>>> for i in `find . -wholename '*/doc/src'` ; do
>>> (cd $i ; make man ERL_TOP=$pwd )
>>> done
>>>
>>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached
>>> docb_gen script)
>>> generates manpages perfectly, make html and make pdf though
>>> suffer from runtime
>>> errors while running xsltproc.
>>>
>>> Running make recursively reveals a whole bunch of problems with
>>> missing and redefined
>>> 'docs' targets in makefiles.
>>>
>>> On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:
>>>> Hi Sergei,
>>>> we started to build our documentation with open source tools in
>>>> R13B03 so it
>>>> would be possible to build the doc from the delivered sources.
>>>>
>>>> But it's still only built in house because we hadn't time to
>>>> test it but the plan is
>>>> to have it work for everyone in R13B04.
>>>>
>>>> Thanks for your report, we'll have a look at those fault.
>>>>
>>>> Regards Lars
>>>>
>>>>
>>>> Sergei Golovan wrote:
>>>>> Hi!
>>>>>
>>>>> I'm trying to build Erlang documentation from the sources (the
>>>>> goal is
>>>>> to switch from prebuilt docs for Debian Erlang packages as
>>>>> building
>>>>> them from the source is preferable).
>>>>>
>>>>> To do that I run
>>>>> make
>>>>> make TYPE=docs
>>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace
>>>>> "make
>>>>> opt" by "make $(TYPE) in the top-level Makefile).
>>>>>
>>>>> and I've found several problems which make build fail:
>>>>>
>>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc
>>>>> reports
>>>>> runtime errors about undefined variables (partnum in line 871
>>>>> and 963
>>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this
>>>>> a bug
>>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian
>>>>> stable and
>>>>> 1.1.26 from Debian unstable failed.)
>>>>>
>>>>> 2) wx application has duplicated targets html and docs in its
>>>>> makefile.
>>>>>
>>>>> 3) wx application (and others too) require docb_gen script to
>>>>> generate
>>>>> XML docs sources. It is missing. (I suppose that it is a simple
>>>>> wrapper around docb_gen Erlang module and could be recreated,
>>>>> but It'd
>>>>> be better if it were shipped in Erlang sources.)
>>>>>
>>>>> Is Erlang documentation supposed to be buildable from the
>>>>> source, or
>>>>> it still requires some unavailable tools?
>>>>>
>>>>> Cheers!
>>>>
>>>>
>>>
>>>
>>>
>>> ________________________________________________________________
>>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>>> erlang-bugs (at) erlang.org
>>
>>
>> ________________________________________________________________
>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> erlang-bugs (at) erlang.org
>>
>>
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>

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

Re: Cover blows up on parsing binary comprehension

2009-12-14T06:20:29Z

[Matthew Sackman:]
> g(SeqIds) -> << <<3:2, SeqId:62>> || SeqId <- SeqIds >>.

Thanks!

There is a patch on GitHub, see

http://github.com/erlang/otp/commit/420b28bb007946307eeda5d4e2bf200fe0ee25ba

Best regards,

Hans Bolinder, Erlang/OTP team, Ericsson

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

Re: Recursive Make Considered Harmful

2009-12-14T03:28:47Z

The proposed solution, which you aptly name "horribly inelegant", always
suggests to me that make should be replaced. At least for new things.

bengt

On Mon, 2009-12-14 at 10:47 +0000, Michael Turner wrote:

> http://miller.emu.id.au/pmiller/books/rmch/
>
> Thanks for this. I wasn't on the list when you first mentioned this
> paper. I vaguely remembered just such a paper while trying to build an
> Erlang release a few months ago. It struck me as a breath of fresh air
> when I first read it over a decade ago.
>
> It's not so much that "make" is lacking, I think. Mainly it's that
> the obvious approach (recursion) for building stuff out of a
> hierarchical directory structure is not necessarily the best way if
> you're using make.
>
> Having one big makefile seems, of course, horribly inelegant. But when
> I've tried that approach, it always reminds me of things I'd forgotten
> while using big, lumbering, recursive build systems. Like, make is
> really fast. Compilers are pretty fast, too. And having everything in
> one place can be nice.
>
> -michael turner
>
> On 12/14/2009, "Bengt Kleberg" <bengt.kleberg@...> wrote:
>
> >Greetings,
> >
> >It has been well over a year since last time I mentioned this paper
> >"Recursive Make Considered Harmful",
> >(http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I
> >do it again.
> >
> >Nice little reading for those that find themselves wondering if they are
> >the only ones that think make is somewhat lacking, at times.
> >
> >
> >bengt
> >
> >On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:
> >> Hi!
> >>
> >> I did some further investigations and found that simply calling make
> >> in all doc/src
> >> directories works better then trying to run make recursively.
> >>
> >> pwd=`pwd`
> >> for i in `find . -wholename '*/doc/src'` ; do
> >> (cd $i ; make man ERL_TOP=$pwd )
> >> done
> >>
> >> (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script)
> >> generates manpages perfectly, make html and make pdf though suffer from runtime
> >> errors while running xsltproc.
> >>
> >> Running make recursively reveals a whole bunch of problems with
> >> missing and redefined
> >> 'docs' targets in makefiles.
> >>
> >> On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:
> >> > Hi Sergei,
> >> > we started to build our documentation with open source tools in R13B03 so it
> >> > would be possible to build the doc from the delivered sources.
> >> >
> >> > But it's still only built in house because we hadn't time to test it but the plan is
> >> > to have it work for everyone in R13B04.
> >> >
> >> > Thanks for your report, we'll have a look at those fault.
> >> >
> >> > Regards Lars
> >> >
> >> >
> >> > Sergei Golovan wrote:
> >> >> Hi!
> >> >>
> >> >> I'm trying to build Erlang documentation from the sources (the goal is
> >> >> to switch from prebuilt docs for Debian Erlang packages as building
> >> >> them from the source is preferable).
> >> >>
> >> >> To do that I run
> >> >> make
> >> >> make TYPE=docs
> >> >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make
> >> >> opt" by "make $(TYPE) in the top-level Makefile).
> >> >>
> >> >> and I've found several problems which make build fail:
> >> >>
> >> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports
> >> >> runtime errors about undefined variables (partnum in line 871 and 963
> >> >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug
> >> >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and
> >> >> 1.1.26 from Debian unstable failed.)
> >> >>
> >> >> 2) wx application has duplicated targets html and docs in its makefile.
> >> >>
> >> >> 3) wx application (and others too) require docb_gen script to generate
> >> >> XML docs sources. It is missing. (I suppose that it is a simple
> >> >> wrapper around docb_gen Erlang module and could be recreated, but It'd
> >> >> be better if it were shipped in Erlang sources.)
> >> >>
> >> >> Is Erlang documentation supposed to be buildable from the source, or
> >> >> it still requires some unavailable tools?
> >> >>
> >> >> Cheers!
> >> >
> >> >
> >>
> >>
> >>
> >> ________________________________________________________________
> >> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> >> erlang-bugs (at) erlang.org
> >
> >
> >________________________________________________________________
> >erlang-bugs mailing list. See http://www.erlang.org/faq.html
> >erlang-bugs (at) erlang.org
> >
> >

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

Re: Recursive Make Considered Harmful

2009-12-14T02:47:15Z

http://miller.emu.id.au/pmiller/books/rmch/

Thanks for this. I wasn't on the list when you first mentioned this
paper. I vaguely remembered just such a paper while trying to build an
Erlang release a few months ago. It struck me as a breath of fresh air
when I first read it over a decade ago.

It's not so much that "make" is lacking, I think. Mainly it's that
the obvious approach (recursion) for building stuff out of a
hierarchical directory structure is not necessarily the best way if
you're using make.

Having one big makefile seems, of course, horribly inelegant. But when
I've tried that approach, it always reminds me of things I'd forgotten
while using big, lumbering, recursive build systems. Like, make is
really fast. Compilers are pretty fast, too. And having everything in
one place can be nice.

-michael turner

On 12/14/2009, "Bengt Kleberg" <bengt.kleberg@...> wrote:

>Greetings,
>
>It has been well over a year since last time I mentioned this paper
>"Recursive Make Considered Harmful",
>(http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I
>do it again.
>
>Nice little reading for those that find themselves wondering if they are
>the only ones that think make is somewhat lacking, at times.
>
>
>bengt
>
>On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:
>> Hi!
>>
>> I did some further investigations and found that simply calling make
>> in all doc/src
>> directories works better then trying to run make recursively.
>>
>> pwd=`pwd`
>> for i in `find . -wholename '*/doc/src'` ; do
>> (cd $i ; make man ERL_TOP=$pwd )
>> done
>>
>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script)
>> generates manpages perfectly, make html and make pdf though suffer from runtime
>> errors while running xsltproc.
>>
>> Running make recursively reveals a whole bunch of problems with
>> missing and redefined
>> 'docs' targets in makefiles.
>>
>> On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:
>> > Hi Sergei,
>> > we started to build our documentation with open source tools in R13B03 so it
>> > would be possible to build the doc from the delivered sources.
>> >
>> > But it's still only built in house because we hadn't time to test it but the plan is
>> > to have it work for everyone in R13B04.
>> >
>> > Thanks for your report, we'll have a look at those fault.
>> >
>> > Regards Lars
>> >
>> >
>> > Sergei Golovan wrote:
>> >> Hi!
>> >>
>> >> I'm trying to build Erlang documentation from the sources (the goal is
>> >> to switch from prebuilt docs for Debian Erlang packages as building
>> >> them from the source is preferable).
>> >>
>> >> To do that I run
>> >> make
>> >> make TYPE=docs
>> >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make
>> >> opt" by "make $(TYPE) in the top-level Makefile).
>> >>
>> >> and I've found several problems which make build fail:
>> >>
>> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports
>> >> runtime errors about undefined variables (partnum in line 871 and 963
>> >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug
>> >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and
>> >> 1.1.26 from Debian unstable failed.)
>> >>
>> >> 2) wx application has duplicated targets html and docs in its makefile.
>> >>
>> >> 3) wx application (and others too) require docb_gen script to generate
>> >> XML docs sources. It is missing. (I suppose that it is a simple
>> >> wrapper around docb_gen Erlang module and could be recreated, but It'd
>> >> be better if it were shipped in Erlang sources.)
>> >>
>> >> Is Erlang documentation supposed to be buildable from the source, or
>> >> it still requires some unavailable tools?
>> >>
>> >> Cheers!
>> >
>> >
>>
>>
>>
>> ________________________________________________________________
>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> erlang-bugs (at) erlang.org
>
>
>________________________________________________________________
>erlang-bugs mailing list. See http://www.erlang.org/faq.html
>erlang-bugs (at) erlang.org
>
>

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

OT: Building docs for R13B-03 fails

2009-12-14T02:19:10Z

Greetings,

It has been well over a year since last time I mentioned this paper
"Recursive Make Considered Harmful",
(http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok that I
do it again.

Nice little reading for those that find themselves wondering if they are
the only ones that think make is somewhat lacking, at times.

bengt

On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:

> Hi!
>
> I did some further investigations and found that simply calling make
> in all doc/src
> directories works better then trying to run make recursively.
>
> pwd=`pwd`
> for i in `find . -wholename '*/doc/src'` ; do
> (cd $i ; make man ERL_TOP=$pwd )
> done
>
> (using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script)
> generates manpages perfectly, make html and make pdf though suffer from runtime
> errors while running xsltproc.
>
> Running make recursively reveals a whole bunch of problems with
> missing and redefined
> 'docs' targets in makefiles.
>
> On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:
> > Hi Sergei,
> > we started to build our documentation with open source tools in R13B03 so it
> > would be possible to build the doc from the delivered sources.
> >
> > But it's still only built in house because we hadn't time to test it but the plan is
> > to have it work for everyone in R13B04.
> >
> > Thanks for your report, we'll have a look at those fault.
> >
> > Regards Lars
> >
> >
> > Sergei Golovan wrote:
> >> Hi!
> >>
> >> I'm trying to build Erlang documentation from the sources (the goal is
> >> to switch from prebuilt docs for Debian Erlang packages as building
> >> them from the source is preferable).
> >>
> >> To do that I run
> >> make
> >> make TYPE=docs
> >> (in fact, make libs doesn't recognize TYPE, so I had to replace "make
> >> opt" by "make $(TYPE) in the top-level Makefile).
> >>
> >> and I've found several problems which make build fail:
> >>
> >> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports
> >> runtime errors about undefined variables (partnum in line 871 and 963
> >> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug
> >> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and
> >> 1.1.26 from Debian unstable failed.)
> >>
> >> 2) wx application has duplicated targets html and docs in its makefile.
> >>
> >> 3) wx application (and others too) require docb_gen script to generate
> >> XML docs sources. It is missing. (I suppose that it is a simple
> >> wrapper around docb_gen Erlang module and could be recreated, but It'd
> >> be better if it were shipped in Erlang sources.)
> >>
> >> Is Erlang documentation supposed to be buildable from the source, or
> >> it still requires some unavailable tools?
> >>
> >> Cheers!
> >
> >
>
>
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org

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

Re: Building docs for R13B-03 fails

2009-12-14T02:02:12Z

Hi!

I did some further investigations and found that simply calling make
in all doc/src
directories works better then trying to run make recursively.

pwd=`pwd`
for i in `find . -wholename '*/doc/src'` ; do
(cd $i ; make man ERL_TOP=$pwd )
done

(using Erlang R12B-02-1 edoc and docbuilder, and the attached docb_gen script)
generates manpages perfectly, make html and make pdf though suffer from runtime
errors while running xsltproc.

Running make recursively reveals a whole bunch of problems with
missing and redefined
'docs' targets in makefiles.

On Mon, Dec 14, 2009 at 12:16 PM, <lars@...> wrote:

> Hi Sergei,
> we started to build our documentation with open source tools in R13B03 so it
> would be possible to build the doc from the delivered sources.
>
> But it's still only built in house because we hadn't time to test it but the plan is
> to have it work for everyone in R13B04.
>
> Thanks for your report, we'll have a look at those fault.
>
> Regards Lars
>
>
> Sergei Golovan wrote:
>> Hi!
>>
>> I'm trying to build Erlang documentation from the sources (the goal is
>> to switch from prebuilt docs for Debian Erlang packages as building
>> them from the source is preferable).
>>
>> To do that I run
>> make
>> make TYPE=docs
>> (in fact, make libs doesn't recognize TYPE, so I had to replace "make
>> opt" by "make $(TYPE) in the top-level Makefile).
>>
>> and I've found several problems which make build fail:
>>
>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports
>> runtime errors about undefined variables (partnum in line 871 and 963
>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug
>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and
>> 1.1.26 from Debian unstable failed.)
>>
>> 2) wx application has duplicated targets html and docs in its makefile.
>>
>> 3) wx application (and others too) require docb_gen script to generate
>> XML docs sources. It is missing. (I suppose that it is a simple
>> wrapper around docb_gen Erlang module and could be recreated, but It'd
>> be better if it were shipped in Erlang sources.)
>>
>> Is Erlang documentation supposed to be buildable from the source, or
>> it still requires some unavailable tools?
>>
>> Cheers!
>
>

--
Sergei Golovan

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

docb_gen (2K) Download Attachment

Re: Building docs for R13B-03 fails

2009-12-14T01:16:13Z

Hi Sergei,
we started to build our documentation with open source tools in R13B03 so it
would be possible to build the doc from the delivered sources.

But it's still only built in house because we hadn't time to test it but the plan is
to have it work for everyone in R13B04.

Thanks for your report, we'll have a look at those fault.

Regards Lars

Sergei Golovan wrote:

> Hi!
>
> I'm trying to build Erlang documentation from the sources (the goal is
> to switch from prebuilt docs for Debian Erlang packages as building
> them from the source is preferable).
>
> To do that I run
> make
> make TYPE=docs
> (in fact, make libs doesn't recognize TYPE, so I had to replace "make
> opt" by "make $(TYPE) in the top-level Makefile).
>
> and I've found several problems which make build fail:
>
> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports
> runtime errors about undefined variables (partnum in line 871 and 963
> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug
> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and
> 1.1.26 from Debian unstable failed.)
>
> 2) wx application has duplicated targets html and docs in its makefile.
>
> 3) wx application (and others too) require docb_gen script to generate
> XML docs sources. It is missing. (I suppose that it is a simple
> wrapper around docb_gen Erlang module and could be recreated, but It'd
> be better if it were shipped in Erlang sources.)
>
> Is Erlang documentation supposed to be buildable from the source, or
> it still requires some unavailable tools?
>
> Cheers!

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

Re: internal compiler faults

2009-12-11T14:42:37Z

2009/12/11 Björn Gustavsson bgustavsson-at-gmail.com:
> Fixed. Included in 'pu'.

Cool! Thanks.

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

Re: internal compiler faults

2009-12-11T14:08:24Z

On Fri, Dec 11, 2009 at 3:20 PM, Simon Cornish <zl9d97p02@...> wrote:
> Regarding the internal consistency check, I used the beam_bool patch
> and still encountered the same problem. Attached is a small example.
> It will compile if no_bopt is used. It will also compile if the
> boolean guard is not repeated (eg. CH2 is assigned a constant value).

Fixed. Included in 'pu'.

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

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

Cover blows up on parsing binary comprehension

2009-12-11T08:11:19Z

-module(foo).

-export([f/0, g/1]).

f() ->
cover:start(),
{ok,foo} = cover:compile_module(foo).

g(SeqIds) -> << <<3:2, SeqId:62>> || SeqId <- SeqIds >>.

$ erlc -Wall -v +debug_info foo.erl
$ erl
Erlang R13B03 (erts-5.7.4) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.7.4 (abort with ^G)
1> foo:f().

=ERROR REPORT==== 11-Dec-2009::16:10:15 ===
Error in process <0.35.0> with exit value: {{badmatch,{bin,9,[{bin_element,9,{integer,9,3},{integer,9,2},default},{bin_element,9,{var,9,'SeqId'},{integer,9,62},default}]}},[{cover,munge_expr,2},{cover,munge_body,4},{cover,munge_clauses,4},{cover,munge,4},{cover,transform_2...

** exception exit: {{badmatch,{bin,9,
[{bin_element,9,{integer,9,3},{integer,9,2},default},
{bin_element,9,{var,9,'SeqId'},{integer,9,62},default}]}},
[{cover,munge_expr,2},
{cover,munge_body,4},
{cover,munge_clauses,4},
{cover,munge,4},
{cover,transform_2,5},
{cover,transform,4},
{cover,do_compile_beam,2},
{cover,main_process_loop,1}]}
in function cover:call/1
in call from cover:compile_modules/3
in call from cover:compile_module/2
in call from foo:f/0

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

Re: internal compiler faults

2009-12-11T07:38:35Z

On Fri, Dec 11, 2009 at 3:20 PM, Simon Cornish <zl9d97p02@...> wrote:

> I fail to see how this minimisation helps the discussion. The point of
> including both the yes/3 and bad/3 functions was to show that only one
> of the two different methods of calculating Do1 & Do2 caused the
> crash. I would have thought this would help point to the underlying
> optimisation error.

It helped me. I generally debug optimization problems
by printing out and inspecting the internal data structures,
so the smaller the better. Having different versions to
compare can be useful, however, when I have located
the problem and I need to decide the best way to solve it.

> Regarding the internal consistency check, I used the beam_bool patch
> and still encountered the same problem. Attached is a small example.
> It will compile if no_bopt is used. It will also compile if the
> boolean guard is not repeated (eg. CH2 is assigned a constant value).

Thanks! That information gives me a pretty good idea
where I should start looking for the problem.

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

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

Re: internal compiler faults

2009-12-11T06:20:49Z

Hi Björn,
Thanks for your quick patch.

2009/12/10 Björn Gustavsson bgustavsson-at-gmail.com wrote:
> On Thu, Dec 10, 2009 at 2:05 PM, Kostis Sagonas <kostis@...> wrote:
>> For Bjorn, I guess, I include a smaller version of your module that also
>> throws the same error as the program you attached.
>
> Thanks for minimizing the example.

I fail to see how this minimisation helps the discussion. The point of
including both the yes/3 and bad/3 functions was to show that only one
of the two different methods of calculating Do1 & Do2 caused the
crash. I would have thought this would help point to the underlying
optimisation error.

Regarding the internal consistency check, I used the beam_bool patch
and still encountered the same problem. Attached is a small example.
It will compile if no_bopt is used. It will also compile if the
boolean guard is not repeated (eg. CH2 is assigned a constant value).

On Thu, Dec 10, 2009 at 2:05 PM, Kostis Sagonas wrote:
[...]
> we'll never know if you do not show us the code.

Yes, it is self-evident that the code that produces an error is
preferable for solving that problem than different code that produces
a different error.

Regards,
Simon

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

a2.erl (474 bytes) Download Attachment

Building docs for R13B-03 fails

2009-12-11T05:52:00Z

Hi!

I'm trying to build Erlang documentation from the sources (the goal is
to switch from prebuilt docs for Debian Erlang packages as building
them from the source is preferable).

To do that I run
make
make TYPE=docs
(in fact, make libs doesn't recognize TYPE, so I had to replace "make
opt" by "make $(TYPE) in the top-level Makefile).

and I've found several problems which make build fail:

1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc reports
runtime errors about undefined variables (partnum in line 871 and 963
of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this a bug
in the stylesheets or in xsltproc? (Both 1.1.24 from Debian stable and
1.1.26 from Debian unstable failed.)

2) wx application has duplicated targets html and docs in its makefile.

3) wx application (and others too) require docb_gen script to generate
XML docs sources. It is missing. (I suppose that it is a simple
wrapper around docb_gen Erlang module and could be recreated, but It'd
be better if it were shipped in Erlang sources.)

Is Erlang documentation supposed to be buildable from the source, or
it still requires some unavailable tools?

Cheers!
--
Sergei Golovan

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

Re: internal compiler faults

2009-12-10T13:37:52Z

On Thu, Dec 10, 2009 at 2:05 PM, Kostis Sagonas <kostis@...> wrote:

> For Bjorn, I guess, I include a smaller version of your module that also
> throws the same error as the program you attached.

Thanks for minimizing the example.

I have included a fix in the 'pu' branch. Basically, my fix just
treats the symptom (disabling the optimization for that kind of code
instead of crashing), but I have looked at the code to understand
why it crashed and added some information about it to the comments
and commit message.

To debug problems found by the beam_validator, I generally start
by disabling various optimization passes to see if the problem
disappears. If it does, I know in which part of the code to start
looking.

Type

compile:options()

in the shell to get a list of the compiler options (the one
with the explanation "Skip..." are the ones you are
interested in).

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

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

Re: internal compiler faults

2009-12-10T05:05:37Z

Simon Cornish wrote:
> Hi,
> I was trying to refine some code (that I can't publish) that threw
> this error on compilation:
>
> xxx: function make_content_list/6+108:
> Internal consistency check failed - please report this bug.
> Instruction: {move,{y,0},{x,0}}
> Error: {unassigned,{y,0}}:

This error might or might not be the same as the one the program you
attached in your previous mail is suffering from (function clause
exception in gb_trees:get/1) -- we'll never know if you do not show us
the code. Please try to minimize it so that it shows the same internal
consistency problem as above -- minimizing it not only saves time for
the compiler maintainer but it also makes sure that the program will be
useful to no one other than the compiler writers -- and send it here.

> And instead I get something different with the attached module using
> two variants of more or less the same code from the first error:

For Bjorn, I guess, I include a smaller version of your module that also
throws the same error as the program you attached.

Function: bad/3
/home/kostis/a1.erl:none: internal error in beam_bool;
crash reason: {{case_clause,
{'EXIT',
{function_clause,
[{gb_trees,get_1,[{tmp,0},nil]},
{lists,mapfoldl,3}]}}},

> Any hints on debugging/fixing the first error will also be appreciated.

You've not shown us the problematic code so it's very hard to know
what's happening, but here is some educated guess on how to bypass it:

Your program has the following construct:

Var = BOOLEAN_EXPR,
if Var == true;
Var == false,OTHER_TESTS -> ...

Change this to either:

Var = BOOLEAN_EXPR,
if Var == true orelse
Var == false,OTHER_TESTS -> ...

or to simply:

Var = BOOLEAN_EXPR,
if Var == true;
OTHER_TESTS -> ...

Kostis

-module(a1).
-export([bad/3]).

bad(XDo1, XDo2, Do3) ->
Do1 = (XDo1 =/= []),
Do2 = (XDo2 =/= []),
if Do1 =:= true;
Do1 =:= false, Do2=:=false, Do3 =:= delete ->
no
end.

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

internal compiler faults

2009-12-10T04:12:00Z

Hi,
I was trying to refine some code (that I can't publish) that threw
this error on compilation:

xxx: function make_content_list/6+108:
Internal consistency check failed - please report this bug.
Instruction: {move,{y,0},{x,0}}
Error: {unassigned,{y,0}}:

And instead I get something different with the attached module using
two variants of more or less the same code from the first error:

d124:test_server simon$ erlc -W ~/tmp/a1.erl
Function: bad/3
/Users/simon/tmp/a1.erl:none: internal error in beam_bool;
crash reason: {{case_clause,
{'EXIT',
{function_clause,
[{gb_trees,get_1,[{tmp,0},nil]},
{beam_bool,bopt_good_arg,2},
{beam_bool,bopt_good_args,2},
{beam_bool,bopt_tree,3},
{beam_bool,bopt_tree,3},
{beam_bool,bopt_tree_cg,3},
{beam_bool,bopt_block,5},
{beam_bool,bopt,3}]}}},
[{compile,'-select_passes/2-anonymous-2-',2},
{compile,'-internal_comp/4-anonymous-1-',2},
{compile,fold_comp,3},
{compile,internal_comp,4},
{compile,internal,3}]}

Build is http://github.com/erlang/otp/tree/ee51ffa886cdbc7a577d6e068236c107f0137696
(a few behind on ccase/r13b04_dev), host is OSX 10.6 (32-bit kernel)
built with --enable-darwin-64bit

Any hints on debugging/fixing the first error will also be appreciated.

/Simon

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

a1.erl (716 bytes) Download Attachment

Re: Bug in documentation

2009-12-09T04:28:39Z

Hello,

There is misplaced paragraph in http://www.erlang.org/doc/man/erlang.html

process_flag(save_calls, N)
When there are runnable processes on priority max no processes
on priority low, normal, or high will be selected for execution. As
with the high priority, processes on lower priorities might execute in
parallel with processes on priority max.

Paragraph startin "When there are ..." should be placed above
`process_flag(save_calls, N)` because it belongs to
`process_flag(priority, Level)` above.

With best regards

--
--Hynek (Pichi) Vychodil

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

Re: asn1ct out of date?

2009-12-08T16:16:27Z

Hi Kenneth,

Thanks for your complete and excellent response to this issue. I'm most
impressed by you and also by your team.

(btw the github move, the beta website, and doc searching is all truly
spectacular and highly appreciated)

Best regards,
Steve

Kenneth Lundin wrote:

> Hi again,
>
> I was a bit quick in the last answer regarding the SEQUENCE SIZE() OF construct.
> This construct is already supported, but not the NamedType following
> the OF keyword.
> This is the same limitation as the plain SEQUENCE OF which also did
> not support NamedType.
>
> By the way thanks for the bug-report.
> I will correct and add this functionality in the next release.
>
> I also think that your changes in the ASN.1 spec in order to let it
> through the compiler is
> perfectly ok because they will have no impact on the BER encoding
> (which is used in LDAP).
>
> /Kenneth
>
> On Fri, Dec 4, 2009 at 1:52 PM, Kenneth Lundin <kenneth.lundin@...> wrote:
>> Hi,
>>
>> This isa new LDAP ASN.1 spec that I have not seen before.
>> The previous ones has passed the Erlang ASN.1 compiler without problems.
>>
>> The Erlang ASN.1 compiler does not support everything in the 2002
>> standard of ASN.1 and there might also be limitations vs the 1997
>> standard.
>>
>> We have implemented the constructs that we have seen need for because
>> they have occured in specifications used by our customers.
>>
>> This is the firs time I see use of:
>>
>> EXSTENSIBILITY IMPLIED, % I will implement that soon, quite easy
>> SEQUENCE OF NamedType which is equivalent to
>> SEQUENCE OF identifier Type % I will implement that too,the
>> identifier is of no real use as I understand it except maybe if the
>> XML encoding rules and value notation is to be used. And
>> we don't support them now.
>>
>> SET OF identifier Type % will implement that too, same as SEQUENCE OF
>>
>> SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed
>> syntax in any version of ASN.1?
>>
>> /Kenneth , Erlang/OTP Ericsson
>>
>> On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis
>> <steven.charles.davis@...> wrote:
>>> While working towards implementing an LDAP server I found that asn1ct does
>>> not appear to support the current LDAP asn.1 specification format.
>>>
>>> http://tools.ietf.org/html/rfc4511#appendix-B
>>>
>>> Attached is the modified ASN.1 for LDAP3 with the statements that cause the
>>> compile time errors commented out as: --##
>>>
>>> Of course, the modified asn file defines a protocol that is no longer
>>> "according to spec"
>>>
>

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

Re: asn1ct out of date?

2009-12-08T13:39:56Z

Hi again,

I was a bit quick in the last answer regarding the SEQUENCE SIZE() OF construct.
This construct is already supported, but not the NamedType following
the OF keyword.
This is the same limitation as the plain SEQUENCE OF which also did
not support NamedType.

By the way thanks for the bug-report.
I will correct and add this functionality in the next release.

I also think that your changes in the ASN.1 spec in order to let it
through the compiler is
perfectly ok because they will have no impact on the BER encoding
(which is used in LDAP).

/Kenneth

On Fri, Dec 4, 2009 at 1:52 PM, Kenneth Lundin <kenneth.lundin@...> wrote:

> Hi,
>
> This isa new LDAP ASN.1 spec that I have not seen before.
> The previous ones has passed the Erlang ASN.1 compiler without problems.
>
> The Erlang ASN.1 compiler does not support everything in the 2002
> standard of ASN.1 and there might also be limitations vs the 1997
> standard.
>
> We have implemented the constructs that we have seen need for because
> they have occured in specifications used by our customers.
>
> This is the firs time I see use of:
>
> EXSTENSIBILITY IMPLIED, % I will implement that soon, quite easy
> SEQUENCE OF NamedType which is equivalent to
> SEQUENCE OF identifier Type % I will implement that too,the
> identifier is of no real use as I understand it except maybe if the
> XML encoding rules and value notation is to be used. And
> we don't support them now.
>
> SET OF identifier Type % will implement that too, same as SEQUENCE OF
>
> SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed
> syntax in any version of ASN.1?
>
> /Kenneth , Erlang/OTP Ericsson
>
> On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis
> <steven.charles.davis@...> wrote:
>> While working towards implementing an LDAP server I found that asn1ct does
>> not appear to support the current LDAP asn.1 specification format.
>>
>> http://tools.ietf.org/html/rfc4511#appendix-B
>>
>> Attached is the modified ASN.1 for LDAP3 with the statements that cause the
>> compile time errors commented out as: --##
>>
>> Of course, the modified asn file defines a protocol that is no longer
>> "according to spec"
>>

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

Re: asn1ct out of date?

2009-12-04T04:52:53Z

Hi,

This isa new LDAP ASN.1 spec that I have not seen before.
The previous ones has passed the Erlang ASN.1 compiler without problems.

The Erlang ASN.1 compiler does not support everything in the 2002
standard of ASN.1 and there might also be limitations vs the 1997
standard.

We have implemented the constructs that we have seen need for because
they have occured in specifications used by our customers.

This is the firs time I see use of:

EXSTENSIBILITY IMPLIED, % I will implement that soon, quite easy
SEQUENCE OF NamedType which is equivalent to
SEQUENCE OF identifier Type % I will implement that too,the
identifier is of no real use as I understand it except maybe if the
XML encoding rules and value notation is to be used. And
we don't support them now.

SET OF identifier Type % will implement that too, same as SEQUENCE OF

SEQUENCE SIZE (1..MAX) OF uri URI % I can't see that this is allowed
syntax in any version of ASN.1?

/Kenneth , Erlang/OTP Ericsson

On Sun, Nov 8, 2009 at 4:38 PM, Steve Davis
<steven.charles.davis@...> wrote:

> While working towards implementing an LDAP server I found that asn1ct does
> not appear to support the current LDAP asn.1 specification format.
>
> http://tools.ietf.org/html/rfc4511#appendix-B
>
> Attached is the modified ASN.1 for LDAP3 with the statements that cause the
> compile time errors commented out as: --##
>
> Of course, the modified asn file defines a protocol that is no longer
> "according to spec"
>
> /s
>
> --## Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
> -- Copyright (C) The Internet Society (2006). This version of
> -- this ASN.1 module is part of RFC 4511; see the RFC itself
> -- for full legal notices.
> LDAP3
> DEFINITIONS
> IMPLICIT TAGS
> --## EXTENSIBILITY IMPLIED
>
> ::=
>
> BEGIN
>
> LDAPMessage ::= SEQUENCE {
> messageID MessageID,
> protocolOp CHOICE {
> bindRequest BindRequest,
> bindResponse BindResponse,
> unbindRequest UnbindRequest,
> searchRequest SearchRequest,
> searchResEntry SearchResultEntry,
> searchResDone SearchResultDone,
> searchResRef SearchResultReference,
> modifyRequest ModifyRequest,
> modifyResponse ModifyResponse,
> addRequest AddRequest,
> addResponse AddResponse,
> delRequest DelRequest,
> delResponse DelResponse,
> modDNRequest ModifyDNRequest,
> modDNResponse ModifyDNResponse,
> compareRequest CompareRequest,
> compareResponse CompareResponse,
> abandonRequest AbandonRequest,
> extendedReq ExtendedRequest,
> extendedResp ExtendedResponse,
> ...,
> intermediateResponse IntermediateResponse },
> controls [0] Controls OPTIONAL }
>
> MessageID ::= INTEGER (0 .. maxInt)
>
> maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
>
> LDAPString ::= OCTET STRING -- UTF-8 encoded,
> -- [ISO10646] characters
>
> LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
> -- [RFC4512]
>
> LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
> -- [RFC4514]
>
> RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
> -- [RFC4514]
>
> AttributeDescription ::= LDAPString
> -- Constrained to <attributedescription>
> -- [RFC4512]
>
> AttributeValue ::= OCTET STRING
>
> AttributeValueAssertion ::= SEQUENCE {
> attributeDesc AttributeDescription,
> assertionValue AssertionValue }
>
> AssertionValue ::= OCTET STRING
>
> PartialAttribute ::= SEQUENCE {
> type AttributeDescription,
> --## vals SET OF value AttributeValue }
> vals SET OF AttributeValue }
>
> Attribute ::= PartialAttribute(WITH COMPONENTS {
> ...,
> vals (SIZE(1..MAX))})
>
> MatchingRuleId ::= LDAPString
>
> LDAPResult ::= SEQUENCE {
> resultCode ENUMERATED {
> success (0),
> operationsError (1),
> protocolError (2),
> timeLimitExceeded (3),
> sizeLimitExceeded (4),
> compareFalse (5),
> compareTrue (6),
> authMethodNotSupported (7),
> strongerAuthRequired (8),
> -- 9 reserved --
> referral (10),
> adminLimitExceeded (11),
> unavailableCriticalExtension (12),
> confidentialityRequired (13),
> saslBindInProgress (14),
> -- 15??? --
> noSuchAttribute (16),
> undefinedAttributeType (17),
> inappropriateMatching (18),
> constraintViolation (19),
> attributeOrValueExists (20),
> invalidAttributeSyntax (21),
> -- 22-31 unused --
> noSuchObject (32),
> aliasProblem (33),
> invalidDNSyntax (34),
> -- 35 reserved for undefined isLeaf --
> aliasDereferencingProblem (36),
> -- 37-47 unused --
> inappropriateAuthentication (48),
> invalidCredentials (49),
> insufficientAccessRights (50),
> busy (51),
> unavailable (52),
> unwillingToPerform (53),
> loopDetect (54),
> -- 55-63 unused --
> namingViolation (64),
> objectClassViolation (65),
> notAllowedOnNonLeaf (66),
> notAllowedOnRDN (67),
> entryAlreadyExists (68),
> objectClassModsProhibited (69),
> -- 70 reserved for CLDAP --
> affectsMultipleDSAs (71),
> -- 72-79 unused --
> other (80)
> --## ...
> },
> matchedDN LDAPDN,
> diagnosticMessage LDAPString,
> referral [3] Referral OPTIONAL }
>
> --## Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
> Referral ::= SEQUENCE OF URI
>
> URI ::= LDAPString -- limited to characters permitted in
> -- URIs
>
> --## Controls ::= SEQUENCE OF control Control
> Controls ::= SEQUENCE OF Control
>
> Control ::= SEQUENCE {
> controlType LDAPOID,
> criticality BOOLEAN DEFAULT FALSE,
> controlValue OCTET STRING OPTIONAL }
>
> BindRequest ::= [APPLICATION 0] SEQUENCE {
> version INTEGER (1 .. 127),
> name LDAPDN,
> authentication AuthenticationChoice }
>
> AuthenticationChoice ::= CHOICE {
> simple [0] OCTET STRING,
> -- 1 and 2 reserved
> sasl [3] SaslCredentials,
> ... }
>
> SaslCredentials ::= SEQUENCE {
> mechanism LDAPString,
> credentials OCTET STRING OPTIONAL }
>
> BindResponse ::= [APPLICATION 1] SEQUENCE {
> COMPONENTS OF LDAPResult,
> serverSaslCreds [7] OCTET STRING OPTIONAL }
>
> UnbindRequest ::= [APPLICATION 2] NULL
>
> SearchRequest ::= [APPLICATION 3] SEQUENCE {
> baseObject LDAPDN,
> scope ENUMERATED {
> baseObject (0),
> singleLevel (1),
> wholeSubtree (2),
> ... },
> derefAliases ENUMERATED {
> neverDerefAliases (0),
> derefInSearching (1),
> derefFindingBaseObj (2),
> derefAlways (3) },
> sizeLimit INTEGER (0 .. maxInt),
> timeLimit INTEGER (0 .. maxInt),
> typesOnly BOOLEAN,
> filter Filter,
> attributes AttributeSelection }
>
> --## AttributeSelection ::= SEQUENCE OF selector LDAPString
> AttributeSelection ::= SEQUENCE OF LDAPString
> -- The LDAPString is constrained to
> -- <attributeSelector> in Section 4.5.1.8
>
> Filter ::= CHOICE {
> --## and [0] SET SIZE (1..MAX) OF filter Filter,
> --## or [1] SET SIZE (1..MAX) OF filter Filter,
> and [0] SET OF Filter,
> or [1] SET OF Filter,
> not [2] Filter,
> equalityMatch [3] AttributeValueAssertion,
> substrings [4] SubstringFilter,
> greaterOrEqual [5] AttributeValueAssertion,
> lessOrEqual [6] AttributeValueAssertion,
> present [7] AttributeDescription,
> approxMatch [8] AttributeValueAssertion,
> extensibleMatch [9] MatchingRuleAssertion,
> ... }
>
> SubstringFilter ::= SEQUENCE {
> type AttributeDescription,
> --## substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
> substrings SEQUENCE OF CHOICE {
> initial [0] AssertionValue, -- can occur at most once
> any [1] AssertionValue,
> final [2] AssertionValue } -- can occur at most once
> }
>
> MatchingRuleAssertion ::= SEQUENCE {
> matchingRule [1] MatchingRuleId OPTIONAL,
> type [2] AttributeDescription OPTIONAL,
> matchValue [3] AssertionValue,
> dnAttributes [4] BOOLEAN DEFAULT FALSE }
>
> SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
> objectName LDAPDN,
> attributes PartialAttributeList }
>
> PartialAttributeList ::= SEQUENCE OF PartialAttribute
> --## partialAttribute PartialAttribute
>
> SearchResultReference ::= [APPLICATION 19] SEQUENCE OF URI
> --## SIZE (1..MAX) OF uri URI
>
> SearchResultDone ::= [APPLICATION 5] LDAPResult
>
> ModifyRequest ::= [APPLICATION 6] SEQUENCE {
> object LDAPDN,
> --## changes SEQUENCE OF change SEQUENCE {
> changes SEQUENCE OF SEQUENCE {
> operation ENUMERATED {
> add (0),
> delete (1),
> replace (2),
> ... },
> modification PartialAttribute } }
>
> ModifyResponse ::= [APPLICATION 7] LDAPResult
>
> AddRequest ::= [APPLICATION 8] SEQUENCE {
> entry LDAPDN,
> attributes AttributeList }
>
> --## AttributeList ::= SEQUENCE OF attribute Attribute
> AttributeList ::= SEQUENCE OF Attribute
>
> AddResponse ::= [APPLICATION 9] LDAPResult
>
> DelRequest ::= [APPLICATION 10] LDAPDN
>
> DelResponse ::= [APPLICATION 11] LDAPResult
>
> ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
> entry LDAPDN,
> newrdn RelativeLDAPDN,
> deleteoldrdn BOOLEAN,
> newSuperior [0] LDAPDN OPTIONAL }
>
> ModifyDNResponse ::= [APPLICATION 13] LDAPResult
>
> CompareRequest ::= [APPLICATION 14] SEQUENCE {
> entry LDAPDN,
> ava AttributeValueAssertion }
>
> CompareResponse ::= [APPLICATION 15] LDAPResult
>
> AbandonRequest ::= [APPLICATION 16] MessageID
>
> ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
> requestName [0] LDAPOID,
> requestValue [1] OCTET STRING OPTIONAL }
>
> ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
> COMPONENTS OF LDAPResult,
> responseName [10] LDAPOID OPTIONAL,
> responseValue [11] OCTET STRING OPTIONAL }
>
> IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
> responseName [0] LDAPOID OPTIONAL,
> responseValue [1] OCTET STRING OPTIONAL }
>
> END
>
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>

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

Re: Fix crash when decoding commercial certificates

2009-12-03T23:41:00Z

Hmm, you should use the public_key application, though it is rather
undocumented :-)
The ssl_pkix module should not be used anymore.

Patches on (or documentation of) the public_key application would be great.

I don't know if I like the idea of continuing patching ssl_pkix.erl,
that will lead to more usage of a module we want to phase out.

/Dan

2009/12/3 Björn Gustavsson <bgustavsson@...>:

> On Thu, Dec 3, 2009 at 8:32 PM, Simon Cornish <zl9d97p02@...> wrote:
>> git fetch git://github.com/dotsimon/otp.git ssl_pkix_extensions
>
> Thanks! I have included your branch in 'pu'.
>
> There are two minor things that would be nice to fix:
>
> 1. Lines in the commit message are very long, so it is difficult to
> read it in gitk.
>
> 2. Your email address does not seem to be configured in your git configuration.
>
> Instructions for configuring your user information can now be found
> at the beginning of:
>
> http://wiki.github.com/erlang/otp/submitting-patches
>
> If it is OK, I can break the lines in the commit message and replace
> that local email address with the email that you have subscribed to this
> list with.
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>
>

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

Re: Fix crash when decoding commercial certificates

2009-12-03T12:16:18Z

On Thu, Dec 3, 2009 at 8:32 PM, Simon Cornish <zl9d97p02@...> wrote:
> git fetch git://github.com/dotsimon/otp.git ssl_pkix_extensions

Thanks! I have included your branch in 'pu'.

There are two minor things that would be nice to fix:

1. Lines in the commit message are very long, so it is difficult to
read it in gitk.

2. Your email address does not seem to be configured in your git configuration.

Instructions for configuring your user information can now be found
at the beginning of:

http://wiki.github.com/erlang/otp/submitting-patches

If it is OK, I can break the lines in the commit message and replace
that local email address with the email that you have subscribed to this
list with.

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

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

Fix crash when decoding commercial certificates

2009-12-03T11:32:51Z

The Erlang ssl application assumes that it is fully aware of all
existing extensions, that they are in its list of SSL extensions, and
it is able to decode them.

However since this is not true commercial certificates containing the
id-pe-logotype extension crash the decoder. This is only one example
of an extension that the ssl application is unaware of.

This patch improves the behaviour by returning the OID tuple and raw
extension data for extensions that cannot be decoded.

git fetch git://github.com/dotsimon/otp.git ssl_pkix_extensions

The attached bare certificate (ie. the BEGIN/END CERTIFICATE lines
have been removed) can be used to test the fault and fix as shown:

{ok, Bin} = file:read_file("server.bare").
Cert = base64:decode(binary_to_list(Bin)).
ssl_pkix:decode_cert(Cert,[ssl]).

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

server.bare (1K) Download Attachment

R12B-05 beam.smp core

2009-12-03T07:53:33Z

I have a case of R12B-05 beam.smp dumping core on rare occasions on Linux
with the traceback below. I've seen it maybe 5 times in 2+ years and have
never been able to reproduce it when attempting to debug it. I'm posting it
here in the probably slim chance that someone recognizes it and probably
even slimmer chance that there's already a patch for it?

--steve

#0 0x10118414 in offset_heap_ptr ()
#1 0x1011888c in offset_one_rootset ()
#2 0x10118738 in offset_rootset ()
#3 0x10117454 in shrink_new_heap ()
#4 0x1011384c in minor_collection ()
#5 0x10111a2c in erts_garbage_collect ()
#6 0x101117d0 in erts_gc_after_bif_call ()
#7 0x1014e204 in process_main ()
#8 0x100a2138 in sched_thread_func ()
#9 0x101c75f0 in thr_wrapper ()
#10 0x0fe5481c in start_thread () from /lib/libpthread.so.0
#11 0x0fd8db6c in clone () from /lib/libc.so.6

Trouble with precompiled binaries and USE_DECLSPEC_THREAD

2009-12-01T14:28:50Z

The windows binaries available for download are compiled with
USE_DECLSPEC_TRHEAD.
This, according to the following link:

http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx

can cause trouble on systems before Vista when using _declspec(thread)
compiled modules via LoadLibrary. It did happen to me with the ei libraries,
which I needed to use by wrapping them in a dll which was called by .net
with LoadLibrary. On windows XP, in order to work with the dll that wrapped
the ei libs using LoadLibrary, I needed to recompiled sources with cygwin
and remove USE_DECLSPEC_THREAD. On Vista it works out of the box.

There is a catch though when recompiling: When you remove the
USE_DECLSPEC_THREAD definition from the compiler args, the code fragment
that gets included due to the removal (TLS API calls in ei_pthreads.c)
contains a call to SwitchToThread which needs <winbase.h>. Winbase.h is
included in ei.h .But there is something wrong with the include order or the
/D compiler definitions order, which causes an unresolved symbol for
SwitchToThread() and i had to explicitly re-include winbase.h in
ei_pthreads.c

I would suggest defining USE_DECLSPEC_THREAD via a test for version (WINVER
or WIN32_WINNT or something, i cant remember now).

Sorry for not giving more details and maybe provide a patch suggestion, but
cygwin got uninstalled and I dont have VC++ on my machine.
If you cant reproduce and verify the problem easily please tell me and I
will try to get access to VC++ 2005 and reproduce details.

Thanks,
Vassilis

Re: R13B03: dialyzer --apps option not documented

2009-11-26T13:32:06Z

Bernard Duggan wrote:

> Kostis Sagonas wrote:
>> Ulf Wiger wrote:
>>> The new --apps option for Dialyzer is mentioned in the release notes,
>>> and
>>> seems to work, but it is not mentioned in the reference manual, user
>>> guide
>>> or the built-in help (dialyzer --help).
>> Indeed it isn't. It will be. Thanks for bringing this to our attention.
>>
>> Kostis
> I'm sure you would have noticed when adding --apps, but the same also
> goes for the new -Wrace_conditions

Yep. Did notice and since three hours ago it's checked in to our
repository.

> (which, having taken for a test-drive yesterday, I have to say is really cool).

I would be curious to know what/how many bugs you have discovered but we
can take that off this list...

Cheers,
Kostis

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

Re: R13B03: dialyzer --apps option not documented

2009-11-26T13:20:36Z

Kostis Sagonas wrote:

> Ulf Wiger wrote:
>> The new --apps option for Dialyzer is mentioned in the release notes,
>> and
>> seems to work, but it is not mentioned in the reference manual, user
>> guide
>> or the built-in help (dialyzer --help).
>
> Indeed it isn't. It will be. Thanks for bringing this to our attention.
>
> Kostis

I'm sure you would have noticed when adding --apps, but the same also
goes for the new -Wrace_conditions (which, having taken for a test-drive
yesterday, I have to say is really cool).

Cheers,

Bernard

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

Re: R13B03: dialyzer --apps option not documented

2009-11-26T02:31:38Z

Ulf Wiger wrote:
> The new --apps option for Dialyzer is mentioned in the release notes, and
> seems to work, but it is not mentioned in the reference manual, user guide
> or the built-in help (dialyzer --help).

Indeed it isn't. It will be. Thanks for bringing this to our attention.

Kostis

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

R13B03: dialyzer --apps option not documented

2009-11-26T02:29:00Z

The new --apps option for Dialyzer is mentioned in the release notes, and
seems to work, but it is not mentioned in the reference manual, user guide
or the built-in help (dialyzer --help).

BR,
Ulf W

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

Re: R13B02 on 8/16 core box: all TCP communication hangs/frozen

2009-11-24T18:20:12Z

Thanks, sounds good! It has passed our testing too and will appear in
R13B03 which will be released later today (wednesday).

Regards,
Rickard

Rickard Green, Erlang/OTP, Ericsson AB.

2009/11/25 Scott Lystig Fritchie <fritchie@...>:

> Rickard, I don't recall when the R13B03 release is scheduled, but
> it's probably soon. We've had no problems with the patch you'd so
> quickly provided last week. On the 30 or so Linux boxes that we
> have access to in the lab, none have experienced any net_kernel
> communication disruption. Furthermore, we haven't seen any obvious
> scheduling irregularities or negative performance impact.
>
> We'll be continuing our testing over the next couple of weeks at
> least, but knock on wood things are looking very good. Tusen takk!
>
> -Scott
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>
>

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

Re: R13B02 on 8/16 core box: all TCP communication hangs/frozen

2009-11-24T17:22:36Z

Rickard, I don't recall when the R13B03 release is scheduled, but
it's probably soon. We've had no problems with the patch you'd so
quickly provided last week. On the 30 or so Linux boxes that we
have access to in the lab, none have experienced any net_kernel
communication disruption. Furthermore, we haven't seen any obvious
scheduling irregularities or negative performance impact.

We'll be continuing our testing over the next couple of weeks at
least, but knock on wood things are looking very good. Tusen takk!

-Scott

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

Bug in documentation

2009-11-24T12:00:55Z

Hello,

There is misplaced paragraph in http://www.erlang.org/doc/man/erlang.html

process_flag(save_calls, N)
When there are runnable processes on priority max no processes
on priority low, normal, or high will be selected for execution. As
with the high priority, processes on lower priorities might execute in
parallel with processes on priority max.

Paragraph startin "When there are ..." should be placed above
`process_flag(save_calls, N)` because it belongs to
`process_flag(priority, Level)` above.

With best regards

--
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill
your boss. Be a data hero!
Try Good Data now for free: www.gooddata.com

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