From hans.bolinder@REDACTED Tue Apr 1 08:57:34 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 1 Apr 2008 08:57:34 +0200 Subject: [erlang-bugs] Bug in qlc when a cursor is created In-Reply-To: <47F10518.5070302@capflam.org> References: <47F10518.5070302@capflam.org> Message-ID: <18417.56542.781364.637114@gargle.gargle.HOWL> [christopher faulet:] > I think there is a bug in the qlc module. ... > receive > %% ... snipped code ... > _Ignored -> > parent_fun(Pid, Parent) > end. > > > IMHO, this clause must be removed otherwise we cannot "safely" create a > cursor. Thanks. Yes, you are right. The bug will be fixed in the upcoming R12B-2 release. (Those who have downloaded the daily snapshot some time during the last week do not need to apply the patch; we discovered the bug a couple of weeks ago.) Best regards, Hans Bolinder, Erlang/OTP team From tim.becker@REDACTED Tue Apr 1 15:56:58 2008 From: tim.becker@REDACTED (Tim Becker) Date: Tue, 1 Apr 2008 15:56:58 +0200 Subject: [erlang-bugs] PDF documentation bug for erl_interface Message-ID: <254c7bfb0804010656x24d6e92dm4642c9e61754c55c@mail.gmail.com> Hi, (this is my first bug report here, so I'm not fully aware of the local etiquette, bare with me) The PDF version of erl_interface has a strange "bug" that took me a while to figure out: the first chapter is repeated twice. Once it's called " 1.1 The EI Library User's Guide" and once called "1.2 The Erl_Interface Library". The PDF is downloaded from here: http://www.erlang.org/doc/pdf/erl_interface.pdf The equivalent HTML Docs (http://www.erlang.org/doc/apps/erl_interface/index.html) doesn't seem to contain this error. I did one or two spotchecks on other PDFs and that behaviour doesn't seem to appear anywhere else. I couldn't see to find the source of that particular document in the source distribution, so I can't tell whether this is "on purpose" or a tool bug. Thanks, -Tim From egil@REDACTED Tue Apr 1 17:51:43 2008 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 01 Apr 2008 17:51:43 +0200 Subject: [erlang-bugs] PDF documentation bug for erl_interface In-Reply-To: <254c7bfb0804010656x24d6e92dm4642c9e61754c55c@mail.gmail.com> References: <254c7bfb0804010656x24d6e92dm4642c9e61754c55c@mail.gmail.com> Message-ID: <47F25A0F.3040605@erix.ericsson.se> Hi Tim, This is an error in the PDF-documentation due to repeated references and it will be corrected in upcoming release. Thank you for reporting this. Regards, Bj?rn-Egil Tim Becker wrote: > Hi, > > (this is my first bug report here, so I'm not fully aware of the > local etiquette, bare with me) > > The PDF version of erl_interface has a strange "bug" that took me a > while to figure out: the first chapter is repeated twice. Once it's > called " 1.1 The EI Library User's Guide" and once called "1.2 The > Erl_Interface Library". > > The PDF is downloaded from here: > http://www.erlang.org/doc/pdf/erl_interface.pdf > > The equivalent HTML Docs > (http://www.erlang.org/doc/apps/erl_interface/index.html) doesn't seem > to contain this error. I did one or two spotchecks on other PDFs and > that behaviour doesn't seem to appear anywhere else. > > I couldn't see to find the source of that particular document in the > source distribution, so I can't tell whether this is "on purpose" or a > tool bug. > > Thanks, > -Tim > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From hpjcon@REDACTED Tue Apr 1 22:53:02 2008 From: hpjcon@REDACTED (Jan Jacobs) Date: Tue, 1 Apr 2008 22:53:02 +0200 Subject: [erlang-bugs] R12B1: pman exits on XP. Message-ID: <008f01c8943a$67590380$c800a8c0@jan03> Hi I have been testing with R12B1 on XP Profesional on a Pentuim 4 which SMP enabled. When I do the following, pman keeps on exiting! (maxman@REDACTED)3> pman:start(). <0.524.0> Click on "Hide System Processes" (maxman@REDACTED)4> GS frontend. Last mgs in was:{<0.524.0>,{destroy,554}} (maxman@REDACTED)4> exit:{<0.524.0>,{destroy,554}} (maxman@REDACTED)4> Reason: {'EXIT', {function_clause, [{gs_frontend,remove_objs, [123, {error, {{badmatch,[]}, [{gstk_db,opt,3}, {gstk_gridline,delete,2}, {gstk,delete_only_this_widget,2}, {gstk,destroy_impl,2}, {gstk,doit,2}, {gstk,loop,1}]}}]}, {gs_frontend,doit,2}, {gs_frontend,loop,1}]}} If I start the run time with no applications the exiting is erratic, sometimes it will exit on the fist click other times it will do it after third or forth click. If I start run time with my application it will exit on the first click. Cheers Jan From dgud@REDACTED Wed Apr 2 13:01:22 2008 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 02 Apr 2008 13:01:22 +0200 Subject: [erlang-bugs] R12B1: pman exits on XP. In-Reply-To: <008f01c8943a$67590380$c800a8c0@jan03> References: <008f01c8943a$67590380$c800a8c0@jan03> Message-ID: <47F36782.5060806@erix.ericsson.se> Thanks will be fixed in next release. gs/src/gstk_gridline.erl 90,92c90,92 < gstk_db:delete_widget(DB, Gstkid), < {Gstkid#gstkid.parent, Gstkid#gstkid.id, gstk_gridline, < [Gstkid, gstk_db:opt(DB,Gstkid,row)]}. --- > Row = gstk_db:opt(DB,Gstkid,row), > gstk_db:delete_widget(DB, Gstkid), > {Gstkid#gstkid.parent, Gstkid#gstkid.id, gstk_gridline,[Gstkid, Row]}. /Dan Jan Jacobs wrote: > Hi > > I have been testing with R12B1 on XP Profesional on a Pentuim 4 which SMP > enabled. > When I do the following, pman keeps on exiting! > > (maxman@REDACTED)3> pman:start(). > <0.524.0> > > Click on "Hide System Processes" > > (maxman@REDACTED)4> GS frontend. Last mgs in was:{<0.524.0>,{destroy,554}} > (maxman@REDACTED)4> exit:{<0.524.0>,{destroy,554}} > (maxman@REDACTED)4> Reason: {'EXIT', > {function_clause, > [{gs_frontend,remove_objs, > [123, > {error, > {{badmatch,[]}, > [{gstk_db,opt,3}, > {gstk_gridline,delete,2}, > {gstk,delete_only_this_widget,2}, > {gstk,destroy_impl,2}, > {gstk,doit,2}, > {gstk,loop,1}]}}]}, > {gs_frontend,doit,2}, > {gs_frontend,loop,1}]}} > > > If I start the run time with no applications the exiting is erratic, > sometimes it will exit on the fist click other times it will do it after > third or forth click. > If I start run time with my application it will exit on the first click. > > Cheers > Jan > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From justin@REDACTED Sat Apr 5 20:06:05 2008 From: justin@REDACTED (Justin T. Sampson) Date: Sat, 5 Apr 2008 11:06:05 -0700 Subject: [erlang-bugs] Internal consistency check failed in compiler Message-ID: Using R12B-0 on Mac OS X 10.4.11... $ erlc bug_test.erl bug_test: function process/2+25: Internal consistency check failed - please report this bug. Instruction: {bs_append,{f,0}, {integer,0}, 0,2,8, {x,0}, {field_flags,[]}, {x,2}} Error: {match_context,{x,0}}: ===== bug_test.erl ===== -module(bug_test). -compile(export_all). escape_char($<) -> <<"<">>; escape_char($>) -> <<">">>; escape_char($&) -> <<"&">>; escape_char(C) when C =:= $\t; C =:= $\r; C =:= $\n; C >= $\s, C =< $~ -> <>; escape_char(C) when C >= 128 -> <<"&#", (list_to_binary(integer_to_list(C)))/binary, ";">>. process(<<>>, SoFar) -> SoFar; process(<<"\r\n", Rest/binary>>, SoFar) -> process(Rest, <\n">>); process(<<"\r", Rest/binary>>, SoFar) -> process(Rest, <\n">>); process(<<"\n", Rest/binary>>, SoFar) -> process(Rest, <\n">>); process(<<" ", Rest/binary>>, SoFar) -> process(<<" ", Rest/binary>>, <>); process(<<" ", Rest/binary>>, SoFar) -> process(<>, <>); process(<<"\t", Rest/binary>>, SoFar) -> process(<>, <>); process(<<"----\r\n", Rest/binary>>, SoFar) -> process(<>, <\n">>); process(<<"----\r", Rest/binary>>, SoFar) -> process(<>, <\n">>); process(<<"----\n", Rest/binary>>, SoFar) -> process(<>, <\n">>); process(<>, SoFar) -> process(Rest, <>). ===== end bug_test.erl ===== From matthew@REDACTED Sun Apr 6 04:26:42 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sat, 5 Apr 2008 19:26:42 -0700 Subject: [erlang-bugs] Internal consistency check failed in compiler In-Reply-To: References: Message-ID: This compiles fine for me using R12B-1 on OS X 10.5.2. On Sat, Apr 5, 2008 at 11:06 AM, Justin T. Sampson wrote: > Using R12B-0 on Mac OS X 10.4.11... > > $ erlc bug_test.erl > bug_test: function process/2+25: > Internal consistency check failed - please report this bug. > Instruction: {bs_append,{f,0}, > {integer,0}, > 0,2,8, > {x,0}, > {field_flags,[]}, > {x,2}} > Error: {match_context,{x,0}}: > > ===== bug_test.erl ===== > -module(bug_test). > -compile(export_all). > > escape_char($<) -> > <<"<">>; > escape_char($>) -> > <<">">>; > escape_char($&) -> > <<"&">>; > escape_char(C) when C =:= $\t; C =:= $\r; C =:= $\n; C >= $\s, C =< $~ -> > <>; > escape_char(C) when C >= 128 -> > <<"&#", (list_to_binary(integer_to_list(C)))/binary, ";">>. > > process(<<>>, SoFar) -> > SoFar; > process(<<"\r\n", Rest/binary>>, SoFar) -> > process(Rest, <\n">>); > process(<<"\r", Rest/binary>>, SoFar) -> > process(Rest, <\n">>); > process(<<"\n", Rest/binary>>, SoFar) -> > process(Rest, <\n">>); > process(<<" ", Rest/binary>>, SoFar) -> > process(<<" ", Rest/binary>>, <>); > process(<<" ", Rest/binary>>, SoFar) -> > process(<>, <>); > process(<<"\t", Rest/binary>>, SoFar) -> > process(<>, <>); > process(<<"----\r\n", Rest/binary>>, SoFar) -> > process(<>, <\n">>); > process(<<"----\r", Rest/binary>>, SoFar) -> > process(<>, <\n">>); > process(<<"----\n", Rest/binary>>, SoFar) -> > process(<>, <\n">>); > process(<>, SoFar) -> > process(Rest, <>). > ===== end bug_test.erl ===== > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From tim.becker@REDACTED Sun Apr 6 12:26:27 2008 From: tim.becker@REDACTED (Tim Becker) Date: Sun, 6 Apr 2008 12:26:27 +0200 Subject: [erlang-bugs] R12-1 Build on MacOS (again, workaround) Message-ID: <254c7bfb0804060326o16ca0b5dv1eb8c16142c1ee9c@mail.gmail.com> Hi, The fact that R12-1 doesn't build properly on Mac (Tiger/Leopard) seems to be pretty well known by now, I'd like to summarize, though and offer a workaround for the benefit of others running into this problem. The problem apparently has to do with link the gd imaging library that the percept profiling tool uses. The suggested workaround: ./configure --without-gd doesn't work, unfortunately. The build system will still try to make percept, but will fail because it doesn't find the gd headers: gcc -c -o ../priv/obj/i386-apple-darwin9.2.0/egd_port_driver.o -g -O2 -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/i386-apple-darwin9.2.0 -no-cpp-precomp -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -fPIC -fno-common -DHAVE_CONFIG_H -O2 -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/emulator/beam -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/emulator/sys/unix -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/include/internal -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/include/internal/unix -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/include -I/Users/tim/tools/erlang/otp_src_R12B-1/erts/include/unix egd_port_driver.c In file included from egd_port_driver.c:19: egd_image.h:22:16: error: gd.h: No such file or directory egd_image.h:23:21: error: gdfontt.h: No such file or directory Oh the joy of autotools. Two solutions that do work: * as was suggested by Aleix here (http://www.erlang.org/pipermail/erlang-bugs/2007-December/000531.html), you can add the line: CC_R_FLAG=-rpath to ./lib/percept/c_src/Makefile.in (preferable somewhere towards the top ;-) * If you don't want to muck about with makefiles, a less gentle solution to disable building percept is `rm -rf lib/percept` the rest of the build isn't affected by it and at least you'll have a running system. I'm not sure if the fact that --without-gd doesn't work as expected is indicative of other problems in the build system. I'm not very well versed in autotools, unfortunately, so I'm afraid I can't be of much help. Thanks, -Tim From justin@REDACTED Sun Apr 6 17:23:03 2008 From: justin@REDACTED (Justin T. Sampson) Date: Sun, 6 Apr 2008 08:23:03 -0700 Subject: [erlang-bugs] Internal consistency check failed in compiler In-Reply-To: References: Message-ID: Okay, cool. I figured out that it also compiles fine if I replace every occurrence of <> with just Rest. Cheers, Justin On Sat, Apr 5, 2008 at 7:26 PM, Matthew Dempsky wrote: > This compiles fine for me using R12B-1 on OS X 10.5.2. > > On Sat, Apr 5, 2008 at 11:06 AM, Justin T. Sampson wrote: > > > Using R12B-0 on Mac OS X 10.4.11... > > > > $ erlc bug_test.erl > > bug_test: function process/2+25: > > Internal consistency check failed - please report this bug. > > Instruction: {bs_append,{f,0}, > > {integer,0}, > > 0,2,8, > > {x,0}, > > {field_flags,[]}, > > {x,2}} > > Error: {match_context,{x,0}}: > > > > ===== bug_test.erl ===== > > -module(bug_test). > > -compile(export_all). > > > > escape_char($<) -> > > <<"<">>; > > escape_char($>) -> > > <<">">>; > > escape_char($&) -> > > <<"&">>; > > escape_char(C) when C =:= $\t; C =:= $\r; C =:= $\n; C >= $\s, C =< $~ -> > > <>; > > escape_char(C) when C >= 128 -> > > <<"&#", (list_to_binary(integer_to_list(C)))/binary, ";">>. > > > > process(<<>>, SoFar) -> > > SoFar; > > process(<<"\r\n", Rest/binary>>, SoFar) -> > > process(Rest, <\n">>); > > process(<<"\r", Rest/binary>>, SoFar) -> > > process(Rest, <\n">>); > > process(<<"\n", Rest/binary>>, SoFar) -> > > process(Rest, <\n">>); > > process(<<" ", Rest/binary>>, SoFar) -> > > process(<<" ", Rest/binary>>, <>); > > process(<<" ", Rest/binary>>, SoFar) -> > > process(<>, <>); > > process(<<"\t", Rest/binary>>, SoFar) -> > > process(<>, <>); > > process(<<"----\r\n", Rest/binary>>, SoFar) -> > > process(<>, <\n">>); > > process(<<"----\r", Rest/binary>>, SoFar) -> > > process(<>, <\n">>); > > process(<<"----\n", Rest/binary>>, SoFar) -> > > process(<>, <\n">>); > > process(<>, SoFar) -> > > process(Rest, <>). > > ===== end bug_test.erl ===== > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs From vances@REDACTED Sun Apr 6 18:51:45 2008 From: vances@REDACTED (Vance Shipley) Date: Sun, 6 Apr 2008 12:51:45 -0400 Subject: [erlang-bugs] R12-1 Build on MacOS (again, workaround) In-Reply-To: <254c7bfb0804060326o16ca0b5dv1eb8c16142c1ee9c@mail.gmail.com> References: <254c7bfb0804060326o16ca0b5dv1eb8c16142c1ee9c@mail.gmail.com> Message-ID: <20080406165144.GH179@h216-235-12-173.host.egate.net> On Sun, Apr 06, 2008 at 12:26:27PM +0200, Tim Becker wrote: } * If you don't want to muck about with makefiles, a less gentle } solution to disable building percept is `rm -rf lib/percept` An even gentler method is `touch lib/percept/SKIP'. -Vance From dougedmunds@REDACTED Tue Apr 8 22:58:56 2008 From: dougedmunds@REDACTED (DougEdmunds) Date: Tue, 08 Apr 2008 13:58:56 -0700 Subject: [erlang-bugs] Documentation error? erl_ext_dist.html Message-ID: <47FBDC90.1050108@gmail.com> In erts-5.6.1/Doc/Html/erl_ext_dist.html under 8.13 LIST_EXT, it says: Tail is the final tail of the list; it is LARGE_TUPLE_EXT for a proper list, but may be anything type if the list is improper (for instance [a|b]). It appears that instead, this should read: Tail is the final tail of the list; it is NIL_EXT for a proper list, but may be anything type if the list is improper (for instance [a|b]). -- dae From matthew@REDACTED Wed Apr 9 09:34:48 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 9 Apr 2008 00:34:48 -0700 Subject: [erlang-bugs] Silly eshell history behavior In-Reply-To: References: Message-ID: I downloaded an R12B-1 snapshot to see if this patch had been merged yet, and was initially excited because looking over the current group.erl, the lines match up with the + lines in my diff below, but testing then showed my test case still fails... after first wildly assuming it was a platform specific thing and a few hours of repeated recompiling on every machine I have access to, I finally noticed that my patch below is reversed (I ran "diff -u group.erl group.erl.orig" instead of "diff -u group.erl.orig group.erl")... So in case any Erlang developers looked at this patch and/or tried to merge it and assumed it had already been applied, no, it has not (as of the 20080408 snapshot I downloaded). I'd appreciate if someone would give feedback on this. (patch(1) has a -R option to apply a patch in reverse for this reason. Alternatively, I'll repost the diff correctly generated.) On Thu, Mar 27, 2008 at 11:38 AM, Matthew Dempsky wrote: > Run erl, type "1.", hit enter, type "2.", hit enter, press up, press > down, press up. > > I expect at the end of this sequence for the command edit buffer to > contain "2.", not "1.". Below is a patch for this. > > Let me know if this breaks any intentional behavior and I will revise > it as necessary. > > > --- lib/kernel/src/group.erl 2008-03-27 11:34:12.000000000 -0700 > +++ lib/kernel/src/group.erl.orig 2007-11-26 10:55:37.000000000 -0800 > @@ -329,9 +329,9 @@ get_line1({undefined,{_A,Mode,Char},Cs,C > or ((Mode =:= meta_left_sq_bracket) and (Char =:= $A)) -> > send_drv_reqs(Drv, Rs), > case up_stack(Ls0) of > - {none,_Ls} -> > + {none,Ls} -> > send_drv(Drv, beep), > - get_line1(edlin:edit_line(Cs, Cont), Drv, Ls0); > + get_line1(edlin:edit_line(Cs, Cont), Drv, Ls); > {Lcs,Ls} -> > send_drv_reqs(Drv, edlin:erase_line(Cont)), > {more_chars,Ncont,Nrs} = edlin:start(edlin:prompt(Cont)), > @@ -346,9 +346,9 @@ get_line1({undefined,{_A,Mode,Char},_Cs, > or ((Mode =:= meta_left_sq_bracket) and (Char =:= $B)) -> > send_drv_reqs(Drv, Rs), > case down_stack(Ls0) of > - {none,Ls} -> > + {none,_Ls} -> > send_drv_reqs(Drv, edlin:erase_line(Cont)), > - get_line1(edlin:start(edlin:prompt(Cont)), Drv, Ls); > + get_line1(edlin:start(edlin:prompt(Cont)), Drv, Ls0); > {Lcs,Ls} -> > send_drv_reqs(Drv, edlin:erase_line(Cont)), > {more_chars,Ncont,Nrs} = edlin:start(edlin:prompt(Cont)), > @@ -407,17 +407,21 @@ new_stack(Ls) -> {stack,Ls,{},[]}. > > up_stack({stack,[L|U],{},D}) -> > {L,{stack,U,L,D}}; > +up_stack({stack,[L|U],C,D}) -> > + {L,{stack,U,L,[C|D]}}; > up_stack({stack,[],{},D}) -> > {none,{stack,[],{},D}}; > -up_stack({stack,U,C,D}) -> > - up_stack({stack,U,{},[C|D]}). > +up_stack({stack,[],C,D}) -> > + {none,{stack,[C],{},D}}. > > down_stack({stack,U,{},[L|D]}) -> > {L,{stack,U,L,D}}; > +down_stack({stack,U,C,[L|D]}) -> > + {L,{stack,[C|U],L,D}}; > down_stack({stack,U,{},[]}) -> > {none,{stack,U,{},[]}}; > -down_stack({stack,U,C,D}) -> > - down_stack({stack,[C|U],{},D}). > +down_stack({stack,U,C,[]}) -> > + {none,{stack,U,{},[C]}}. > > %% This is get_line without line editing (except for backspace) and > %% without echo. > From bjorn@REDACTED Wed Apr 9 15:29:46 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 09 Apr 2008 15:29:46 +0200 Subject: [erlang-bugs] Documentation error? erl_ext_dist.html In-Reply-To: <47FBDC90.1050108@gmail.com> References: <47FBDC90.1050108@gmail.com> Message-ID: DougEdmunds writes: > In erts-5.6.1/Doc/Html/erl_ext_dist.html > under 8.13 LIST_EXT, it says: > > Tail is the final tail of the list; it is LARGE_TUPLE_EXT for a proper > list, but may be anything type if the list is improper (for instance [a|b]). > > It appears that instead, this should read: > > Tail is the final tail of the list; it is NIL_EXT for a proper list, > but may be anything type if the list is improper (for instance [a|b]). Thanks! We will correct it in R12B-3. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From jan@REDACTED Tue Apr 8 16:00:15 2008 From: jan@REDACTED (=?ISO-8859-1?Q?Jan_B=F6lsche?=) Date: Tue, 8 Apr 2008 16:00:15 +0200 Subject: [erlang-bugs] Fwd: an error in the erlang tutorail References: <18427.29971.876313.820354@antilipe.corelatus.se> Message-ID: <2E14CDF8-5C77-4B13-91E5-C187358AB4A7@muskelfisch.com> Matthias and me found a couple of problems in module five of the erlang tutorial. (See below for details). Would be great, if someone with permissions to do so could fix this. Many thanks for your great work! Jan Begin forwarded message: > From: Matthias Lang > Date: 8. April 2008 15:37:23 MESZ > To: Jan B?lsche > Subject: Re: an error in the erlang tutorail? > > Hi, > > You're quite right. In addition, the argument to server/1 should be > 'Data' and not 'Date'. Also, it's a bad example because it impedes hot > code loading. > > If I were you, I'd report it to erlang-bugs@REDACTED > > If you're shy, I can do it for you. (but tell me to) > > Matthias (I just maintain the FAQ) > > ---------------------------------------------------------------------- > > > Jan B?lsche writes: >> Hi Matthias, >> >> I'm currently evaluating Erlang for use in an experimental web-based >> game project. And I am really pleased with what I figured out until >> now. >> I think I spotted an error in the tutorial at http://www.erlang.org/course/advanced.html >> >> In Module 5 it says: >> >>> Last Call Optimisation >>> The last call optimisation must be used in persistant servers. >>> >>> For example: >>> >>> server(Date) -> >>> receive >>> {From, Info} -> >>> Data1 = process_info(From, Info, Data), >>> server(Data1); >>> {From, Ref, Query} -> >>> {Reply, Data} = process_query(From, Query,Data), >>> From ! {Ref, Reply}, >>> server(Data1) >>> end. >> >> Where I think it should say >> >> {Reply, Data1} = process_query(From, Query,Data), >> >> because Dara is already bound and Data1 is otherwise only defined in >> the {From, Info} branch but nevertheless used in the other branch. >> >> I am not sure whether you are the correct person to send this to but >> I'll give it a try. >> >> Keep up the good work and thanks for sharing! >> Jan From jan@REDACTED Wed Apr 9 14:45:23 2008 From: jan@REDACTED (=?ISO-8859-1?Q?Jan_B=F6lsche?=) Date: Wed, 9 Apr 2008 14:45:23 +0200 Subject: [erlang-bugs] Fwd: an error in the erlang tutorail References: <18427.29971.876313.820354@antilipe.corelatus.se> Message-ID: Hi, Matthias and me found a couple of problems in module five of the erlang tutorial. (See below for details). Would be great, if someone with permissions to do so could fix this. Many thanks for your great work! Jan Begin forwarded message: > From: Matthias Lang > Date: 8. April 2008 15:37:23 MESZ > To: Jan B?lsche > Subject: Re: an error in the erlang tutorail? > > Hi, > > You're quite right. In addition, the argument to server/1 should be > 'Data' and not 'Date'. Also, it's a bad example because it impedes hot > code loading. > > If I were you, I'd report it to erlang-bugs@REDACTED > > If you're shy, I can do it for you. (but tell me to) > > Matthias (I just maintain the FAQ) > > ---------------------------------------------------------------------- > > > Jan B?lsche writes: >> Hi Matthias, >> >> I'm currently evaluating Erlang for use in an experimental web-based >> game project. And I am really pleased with what I figured out until >> now. >> I think I spotted an error in the tutorial at http://www.erlang.org/course/advanced.html >> >> In Module 5 it says: >> >>> Last Call Optimisation >>> The last call optimisation must be used in persistant servers. >>> >>> For example: >>> >>> server(Date) -> >>> receive >>> {From, Info} -> >>> Data1 = process_info(From, Info, Data), >>> server(Data1); >>> {From, Ref, Query} -> >>> {Reply, Data} = process_query(From, Query,Data), >>> From ! {Ref, Reply}, >>> server(Data1) >>> end. >> >> Where I think it should say >> >> {Reply, Data1} = process_query(From, Query,Data), >> >> because Dara is already bound and Data1 is otherwise only defined in >> the {From, Info} branch but nevertheless used in the other branch. >> >> I am not sure whether you are the correct person to send this to but >> I'll give it a try. >> >> Keep up the good work and thanks for sharing! >> Jan From hans.bolinder@REDACTED Fri Apr 11 10:40:43 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Fri, 11 Apr 2008 10:40:43 +0200 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: References: Message-ID: <18431.9227.133848.989614@gargle.gargle.HOWL> [Matthew Dempsky:] > We're seeing weird behavior with pg2, namely that dead pids are not > getting cleared from the pg2:get_members table. E.g. > > 250> [X || X <- pg2:get_members(Group) -- > pg2:get_local_members(Group), node(X) =:= node()]. > [<0.795.0>,<0.794.0>,<0.793.0>,<0.792.0>,<0.791.0>, > <0.790.0>,<0.789.0>,<0.773.0>] > > Am I correct that this is a bug in pg2? It seems that pg2:leave() assumes that the pid is a member of the group. The patch below should solve that problem ('ok' is returned if the group exists but the pid is not a member of the group). Best regards, Hans Bolinder, Erlang OTP/team *** /usr/local/otp/releases/otp_beam_solaris8_r12b_patched/lib/kernel-2.12.1.2/src/pg2.erl Tue Mar 4 13:37:04 2008 --- pg2.erl Tue Apr 8 09:53:10 2008 *************** *** 193,207 **** node(Pid) =:= node() -> [{_, LocalMembers}] = ets:lookup(pg2_table, {local_members, Name}), ! ets:insert(pg2_table, ! {{local_members, Name}, ! lists:delete(Pid, LocalMembers)}), ! NLinks = lists:delete(Pid, S#state.links), ! case lists:member(Pid, NLinks) of ! true -> ok; ! false -> unlink(Pid) ! end, ! NLinks; true -> S#state.links end, --- 193,212 ---- node(Pid) =:= node() -> [{_, LocalMembers}] = ets:lookup(pg2_table, {local_members, Name}), ! case lists:member(Pid, LocalMembers) of ! true -> ! ets:insert(pg2_table, ! {{local_members, Name}, ! lists:delete(Pid, LocalMembers)}), ! NLinks = lists:delete(Pid, S#state.links), ! case lists:member(Pid, NLinks) of ! true -> ok; ! false -> unlink(Pid) ! end, ! NLinks; ! false -> ! S#state.links ! end; true -> S#state.links end, From matthew@REDACTED Fri Apr 11 12:02:10 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Fri, 11 Apr 2008 03:02:10 -0700 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: <18431.9227.133848.989614@gargle.gargle.HOWL> References: <18431.9227.133848.989614@gargle.gargle.HOWL> Message-ID: On Fri, Apr 11, 2008 at 1:40 AM, Hans Bolinder wrote: > It seems that pg2:leave() assumes that the pid is a member of the > group. The patch below should solve that problem ('ok' is returned if > the group exists but the pid is not a member of the group). Ah, good find. I'm curious though, in one of the gen_servers affected, in the module's init/1 we call pg2:create(?GROUP) and then pg2:join(?GROUP, self()), but then we never call pg2:leave (leaving it to pg2 to clean up if the process crashes). How would this issue affect this server? Looking at the R12B-1 Erlang source, the only module that uses pg2 is disk_log_sup. Looking at modules in OTP that mention disk_log, the only one that might possibly affect us is mnesia, but the above described server process only uses mnesia:dirty_read and only on a ram_copies table. (It also updates this table, but only indirectly by cast'ing a request to another gen_server to handle it.) It would seem like either mnesia's disk_log usage is broken or there's another pg2 bug to be discovered. :( From Balint.Reczey@REDACTED Fri Apr 11 12:17:10 2008 From: Balint.Reczey@REDACTED (Balint Reczey) Date: Fri, 11 Apr 2008 12:17:10 +0200 Subject: [erlang-bugs] [BUG] SCTP_ADDR_CONFIRMED event not handled Message-ID: <1207909031.16445.13.camel@localhost> Hi, A new SCTP_PEER_ADDR_CHANGE event named SCTP_ADDR_CONFIRMED was introduced in draft-ietf-tsvwg-sctpsocket-13.txt. It is implemented in the Linux kernel in post-2.6.21 versions (commit 1ae4114dce35dd1d32ed847f60b599dbbdfd5829). The attached patch maps the new event to the Erlang SCTP API. Regards, Balint -------------- next part -------------- A non-text attachment was scrubbed... Name: otp-sctp-addr-confirmed.patch Type: text/x-patch Size: 2363 bytes Desc: not available URL: From s.egner@REDACTED Fri Apr 11 12:36:59 2008 From: s.egner@REDACTED (Sebastian Egner) Date: Fri, 11 Apr 2008 12:36:59 +0200 Subject: [erlang-bugs] example of io_lib:fread/2 Message-ID: <47FF3F4B.2070305@specs.de> Hi there, This is not a bug report, but an Erlang beginner here spent a long time staring at the output: 1> io_lib:fread("Uptime: ~d", "Uptime: 100"). {ok,"d",[]} Maybe a candidate for an example that comes with io_lib:fread/2... Cheers, Sebastian. From s.egner@REDACTED Fri Apr 11 13:01:51 2008 From: s.egner@REDACTED (Sebastian Egner) Date: Fri, 11 Apr 2008 13:01:51 +0200 Subject: [erlang-bugs] example of io_lib:fread/2 In-Reply-To: <47FF4339.3010201@gmail.com> References: <47FF3F4B.2070305@specs.de> <47FF4339.3010201@gmail.com> Message-ID: <47FF451F.7010500@specs.de> Serge Aleynikov wrote: > Sebastian Egner wrote: >> [...] >> This is not a bug report, but an Erlang beginner here spent a long >> time staring at the output: >> >> 1> io_lib:fread("Uptime: ~d", "Uptime: 100"). >> {ok,"d",[]} >> >> [...] > > This is not really the io_lib:fread/2 issue. Try this: > > 1> [100]. > "d" > > When a list is printed in the shell if it contains all integers being > printable characters, they are printed as a string. > > Serge Of course, only that the poor guy (even knowing that $d = 100 in Erlang!) got confused by the unfortunate choice of 100, trying to understand "why fread returned the format instead of the value"... ;-) Sebastian. From saleyn@REDACTED Fri Apr 11 12:53:45 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Fri, 11 Apr 2008 06:53:45 -0400 Subject: [erlang-bugs] example of io_lib:fread/2 In-Reply-To: <47FF3F4B.2070305@specs.de> References: <47FF3F4B.2070305@specs.de> Message-ID: <47FF4339.3010201@gmail.com> Sebastian Egner wrote: > Hi there, > > This is not a bug report, but an Erlang beginner here spent a long time > staring at the output: > > 1> io_lib:fread("Uptime: ~d", "Uptime: 100"). > {ok,"d",[]} > > Maybe a candidate for an example that comes with io_lib:fread/2... > > Cheers, > > Sebastian. This is not really the io_lib:fread/2 issue. Try this: 1> [100]. "d" When a list is printed in the shell if it contains all integers being printable characters, they are printed as a string. Serge From Balint.Reczey@REDACTED Fri Apr 11 15:43:52 2008 From: Balint.Reczey@REDACTED (Balint Reczey) Date: Fri, 11 Apr 2008 15:43:52 +0200 Subject: [erlang-bugs] [BUG] SCTP_ADDR_CONFIRMED event not handled In-Reply-To: <1207909031.16445.13.camel@localhost> References: <1207909031.16445.13.camel@localhost> Message-ID: <1207921432.10167.6.camel@localhost> Oh, I forgot to mention that we experienced SCTP connection lockups with post-2.6.21 kernels without that patch. :-\ Regards, Balint 2008. 04. 11, p?ntek keltez?ssel 12.17-kor Balint Reczey ezt ?rta: > Hi, > > A new SCTP_PEER_ADDR_CHANGE event named SCTP_ADDR_CONFIRMED was > introduced in draft-ietf-tsvwg-sctpsocket-13.txt. > > It is implemented in the Linux kernel in post-2.6.21 versions > (commit 1ae4114dce35dd1d32ed847f60b599dbbdfd5829). > > The attached patch maps the new event to the Erlang SCTP API. > > Regards, > Balint > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From raimo+erlang-bugs@REDACTED Fri Apr 11 16:12:16 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 11 Apr 2008 16:12:16 +0200 Subject: [erlang-bugs] [BUG] SCTP_ADDR_CONFIRMED event not handled In-Reply-To: <1207909031.16445.13.camel@localhost> References: <1207909031.16445.13.camel@localhost> Message-ID: <20080411141216.GA18674@erix.ericsson.se> On Fri, Apr 11, 2008 at 12:17:10PM +0200, Balint Reczey wrote: > Hi, > > A new SCTP_PEER_ADDR_CHANGE event named SCTP_ADDR_CONFIRMED was > introduced in draft-ietf-tsvwg-sctpsocket-13.txt. > > It is implemented in the Linux kernel in post-2.6.21 versions > (commit 1ae4114dce35dd1d32ed847f60b599dbbdfd5829). > > The attached patch maps the new event to the Erlang SCTP API. > Thank you for your patch. It looks fine. I will take it into our development branch as soon as possible. Unfortunately we do not have a that late Linux kernel in our daily build machine park (yet), nor any real SCTP load tests. > Regards, > Balint > diff -Naur otp_src_R12B-1/bootstrap/lib/kernel/include/inet_sctp.hrl otp_src_R12B-1-mod/bootstrap/lib/kernel/include/inet_sctp.hrl > --- otp_src_R12B-1/bootstrap/lib/kernel/include/inet_sctp.hrl 2008-02-06 22:16:52.000000000 +0100 > +++ otp_src_R12B-1-mod/bootstrap/lib/kernel/include/inet_sctp.hrl 2008-04-10 18:32:18.000000000 +0200 > @@ -73,7 +73,7 @@ > %% sctp_paddr_change: Peer address is a list. Possible "state" values: > %% addr_available, addr_unreachable, > %% addr_removed, addr_added, > -%% addr_made_prim > +%% addr_made_prim, addr_confirmed > -record(sctp_paddr_change, > { > addr = [0,0,0,0], > diff -Naur otp_src_R12B-1/erts/emulator/drivers/common/inet_drv.c otp_src_R12B-1-mod/erts/emulator/drivers/common/inet_drv.c > --- otp_src_R12B-1/erts/emulator/drivers/common/inet_drv.c 2008-04-10 18:52:00.000000000 +0200 > +++ otp_src_R12B-1-mod/erts/emulator/drivers/common/inet_drv.c 2008-04-10 18:46:45.000000000 +0200 > @@ -2752,7 +2752,7 @@ > /* For #sctp_paddr_change{}: */ > am_addr_available, am_addr_unreachable, > am_addr_removed, am_addr_added, > - am_addr_made_prim, > + am_addr_made_prim, am_addr_confirmed, > > /* For #sctp_remote_error{}: */ > am_short_recv, am_wrong_anc_data, > @@ -3007,6 +3007,9 @@ > case SCTP_ADDR_MADE_PRIM: > i = LOAD_ATOM (spec, i, am_addr_made_prim); > break; > + case SCTP_ADDR_CONFIRMED: > + i = LOAD_ATOM (spec, i, am_addr_confirmed); > + break; > default: > ASSERT(0); > } > @@ -3840,6 +3843,7 @@ > INIT_ATOM(addr_removed); > INIT_ATOM(addr_added); > INIT_ATOM(addr_made_prim); > + INIT_ATOM(addr_confirmed); > > INIT_ATOM(short_recv); > INIT_ATOM(wrong_anc_data); > diff -Naur otp_src_R12B-1/lib/kernel/include/inet_sctp.hrl otp_src_R12B-1-mod/lib/kernel/include/inet_sctp.hrl > --- otp_src_R12B-1/lib/kernel/include/inet_sctp.hrl 2008-02-05 14:38:24.000000000 +0100 > +++ otp_src_R12B-1-mod/lib/kernel/include/inet_sctp.hrl 2008-04-10 18:41:16.000000000 +0200 > @@ -73,7 +73,7 @@ > %% sctp_paddr_change: Peer address is a list. Possible "state" values: > %% addr_available, addr_unreachable, > %% addr_removed, addr_added, > -%% addr_made_prim > +%% addr_made_prim, addr_confirmed > -record(sctp_paddr_change, > { > addr = [0,0,0,0], > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From matthew@REDACTED Fri Apr 11 18:23:04 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Fri, 11 Apr 2008 09:23:04 -0700 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: References: <18431.9227.133848.989614@gargle.gargle.HOWL> Message-ID: On Fri, Apr 11, 2008 at 3:02 AM, Matthew Dempsky wrote: > It would seem like either mnesia's disk_log usage is broken or there's > another pg2 bug to be discovered. :( The other reason I don't think this is the bug we're looking for is that it doesn't show the symptoms we've experienced. In particular, it leaves the dead pid in both the local_members and the members tables. Our problem is that the pid stays around in only the members table, not the local_members table. matthew@REDACTED:~$ erl Erlang (BEAM) emulator version 5.6.1 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6.1 (abort with ^G) 1> {pg2:create(foo), pg2:create(bar)}. {ok,ok} 2> spawn(fun() -> pg2:join(foo, self()), pg2:leave(bar, self()) end). <0.35.0> 3> pg2:get_local_members(foo). [<0.35.0>] 4> pg2:get_members(foo). [<0.35.0>] From hans.bolinder@REDACTED Mon Apr 14 09:21:29 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 14 Apr 2008 09:21:29 +0200 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: References: <18431.9227.133848.989614@gargle.gargle.HOWL> Message-ID: <18435.1529.209488.50485@gargle.gargle.HOWL> [Matthew Dempsky:] > > It would seem like either mnesia's disk_log usage is broken or there's > > another pg2 bug to be discovered. :( Mnesia doesn't use pg2 since all its logs are local disk logs. In fact, pg2 isn't used by OTP at all. > Our problem is that the pid stays around in only the members table, > not the local_members table. I've tried to find more bugs, but so far without success. Best regards, Hans Bolinder, Erlang/OTP team From mail.wolfgang.keller@REDACTED Mon Apr 14 12:21:58 2008 From: mail.wolfgang.keller@REDACTED (mail.wolfgang.keller@REDACTED) Date: Mon, 14 Apr 2008 12:21:58 +0200 Subject: [erlang-bugs] Bug in Interoperability Tutorial Message-ID: <1755184100@web.de> Hi, I found a bug in the Interoperability tutorial (hosted at http://www.erlang.org/doc/tutorial/part_frame.html) which - luckily - did not take a lot of time to track for me but is probably able to confuse a lot of beginners and courses malfunctions of the test program: Let's look at chapter 5: http://www.erlang.org/doc/tutorial/erl_interface.html In 5.2 (short before 5.3) we find the following C code: /* snip */ if (strncmp(ERL_ATOM_PTR(fnp), "foo", 3) == 0) { res = foo(ERL_INT_VALUE(argp)); } else if (strncmp(ERL_ATOM_PTR(fnp), "bar", 17) == 0) { res = bar(ERL_INT_VALUE(argp)); } /* snap */ the string "bar" is only 3 characters long - not 17. So it must be: } else if (strncmp(ERL_ATOM_PTR(fnp), "bar", 3) == 0) { This bug caused - of course - some malfunctions on my tests. Yours faithfully Wolfgang Keller P. S.: In chapter 7 this bug doesn't seem to exist: /* snip */ if (strncmp(ERL_ATOM_PTR(fnp), "foo", 3) == 0) { res = foo(ERL_INT_VALUE(argp)); } else if (strncmp(ERL_ATOM_PTR(fnp), "bar", 3) == 0) { res = bar(ERL_INT_VALUE(argp)); } /* snap */ _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 From bjorn@REDACTED Mon Apr 14 15:20:35 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 14 Apr 2008 15:20:35 +0200 Subject: [erlang-bugs] Silly eshell history behavior In-Reply-To: References: Message-ID: "Matthew Dempsky" writes: > Run erl, type "1.", hit enter, type "2.", hit enter, press up, press > down, press up. > > I expect at the end of this sequence for the command edit buffer to > contain "2.", not "1.". Below is a patch for this. > > Let me know if this breaks any intentional behavior and I will revise > it as necessary. > Thanks! Seems to work. We will include your patch in R12B-3. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From matthew@REDACTED Mon Apr 14 19:18:12 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Mon, 14 Apr 2008 10:18:12 -0700 Subject: [erlang-bugs] Seg fault in binary_to_term on bad data Message-ID: Calling binary_to_term can cause a segmentation fault. The binary below is an EXPORT_EXT encoding, but with the Module, Function, and Arity parts all set to SMALL_INTEGER_EXT encoding for 13. I expect binary_to_term to instead just raise an exception in the calling process. matthew@REDACTED:~$ erl Erlang (BEAM) emulator version 5.6.2 [source] [64-bit] [async-threads:0] [kernel-poll:false] Eshell V5.6.2 (abort with ^G) 1> binary_to_term(<<131,113,97,13,97,13,97,13>>). Segmentation fault (core dumped) From bjorn@REDACTED Tue Apr 15 10:05:24 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 15 Apr 2008 10:05:24 +0200 Subject: [erlang-bugs] Seg fault in binary_to_term on bad data In-Reply-To: References: Message-ID: "Matthew Dempsky" writes: > Calling binary_to_term can cause a segmentation fault. The binary > below is an EXPORT_EXT encoding, but with the Module, Function, and > Arity parts all set to SMALL_INTEGER_EXT encoding for 13. I expect > binary_to_term to instead just raise an exception in the calling > process. Thanks! We will correct it in R12B-3. Here is a patch: *** erts/emulator/beam/external.c@@/OTP_R12B-2 Mon Apr 7 15:57:52 2008 --- erts/emulator/beam/external.c Tue Apr 15 09:08:51 2008 *************** *** 1396,1403 **** Eterm temp; Sint arity; ! ep = dec_atom(dep, ep, &mod); ! ep = dec_atom(dep, ep, &name); *hpp = hp; ep = dec_term(dep, hpp, ep, off_heap, &temp); hp = *hpp; --- 1396,1407 ---- Eterm temp; Sint arity; ! if ((ep = dec_atom(dep, ep, &mod)) == NULL) { ! goto error; ! } ! if ((ep = dec_atom(dep, ep, &name)) == NULL) { ! goto error; ! } *hpp = hp; ep = dec_term(dep, hpp, ep, off_heap, &temp); hp = *hpp; /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Balint.Reczey@REDACTED Tue Apr 15 13:20:51 2008 From: Balint.Reczey@REDACTED (Balint Reczey) Date: Tue, 15 Apr 2008 13:20:51 +0200 Subject: [erlang-bugs] [BUG] SCTP_ADDR_CONFIRMED event not handled In-Reply-To: <20080411141216.GA18674@erix.ericsson.se> References: <1207909031.16445.13.camel@localhost> <20080411141216.GA18674@erix.ericsson.se> Message-ID: <1208258451.25766.5.camel@localhost> Hi, Sergei Golovan updated the patch, now it builds with older lksctp-tools without SCTP_ADDR_CONFIRMED definition, too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475540#10 Regards, Balint 2008. 04. 11, p?ntek keltez?ssel 16.12-kor Raimo Niskanen ezt ?rta: > On Fri, Apr 11, 2008 at 12:17:10PM +0200, Balint Reczey wrote: > > Hi, > > > > A new SCTP_PEER_ADDR_CHANGE event named SCTP_ADDR_CONFIRMED was > > introduced in draft-ietf-tsvwg-sctpsocket-13.txt. > > > > It is implemented in the Linux kernel in post-2.6.21 versions > > (commit 1ae4114dce35dd1d32ed847f60b599dbbdfd5829). > > > > The attached patch maps the new event to the Erlang SCTP API. > > > > Thank you for your patch. It looks fine. I will take it into > our development branch as soon as possible. Unfortunately > we do not have a that late Linux kernel in our daily build > machine park (yet), nor any real SCTP load tests. > > > Regards, > > Balint > > > diff -Naur otp_src_R12B-1/bootstrap/lib/kernel/include/inet_sctp.hrl otp_src_R12B-1-mod/bootstrap/lib/kernel/include/inet_sctp.hrl > > --- otp_src_R12B-1/bootstrap/lib/kernel/include/inet_sctp.hrl 2008-02-06 22:16:52.000000000 +0100 > > +++ otp_src_R12B-1-mod/bootstrap/lib/kernel/include/inet_sctp.hrl 2008-04-10 18:32:18.000000000 +0200 > > @@ -73,7 +73,7 @@ > > %% sctp_paddr_change: Peer address is a list. Possible "state" values: > > %% addr_available, addr_unreachable, > > %% addr_removed, addr_added, > > -%% addr_made_prim > > +%% addr_made_prim, addr_confirmed > > -record(sctp_paddr_change, > > { > > addr = [0,0,0,0], > > diff -Naur otp_src_R12B-1/erts/emulator/drivers/common/inet_drv.c otp_src_R12B-1-mod/erts/emulator/drivers/common/inet_drv.c > > --- otp_src_R12B-1/erts/emulator/drivers/common/inet_drv.c 2008-04-10 18:52:00.000000000 +0200 > > +++ otp_src_R12B-1-mod/erts/emulator/drivers/common/inet_drv.c 2008-04-10 18:46:45.000000000 +0200 > > @@ -2752,7 +2752,7 @@ > > /* For #sctp_paddr_change{}: */ > > am_addr_available, am_addr_unreachable, > > am_addr_removed, am_addr_added, > > - am_addr_made_prim, > > + am_addr_made_prim, am_addr_confirmed, > > > > /* For #sctp_remote_error{}: */ > > am_short_recv, am_wrong_anc_data, > > @@ -3007,6 +3007,9 @@ > > case SCTP_ADDR_MADE_PRIM: > > i = LOAD_ATOM (spec, i, am_addr_made_prim); > > break; > > + case SCTP_ADDR_CONFIRMED: > > + i = LOAD_ATOM (spec, i, am_addr_confirmed); > > + break; > > default: > > ASSERT(0); > > } > > @@ -3840,6 +3843,7 @@ > > INIT_ATOM(addr_removed); > > INIT_ATOM(addr_added); > > INIT_ATOM(addr_made_prim); > > + INIT_ATOM(addr_confirmed); > > > > INIT_ATOM(short_recv); > > INIT_ATOM(wrong_anc_data); > > diff -Naur otp_src_R12B-1/lib/kernel/include/inet_sctp.hrl otp_src_R12B-1-mod/lib/kernel/include/inet_sctp.hrl > > --- otp_src_R12B-1/lib/kernel/include/inet_sctp.hrl 2008-02-05 14:38:24.000000000 +0100 > > +++ otp_src_R12B-1-mod/lib/kernel/include/inet_sctp.hrl 2008-04-10 18:41:16.000000000 +0200 > > @@ -73,7 +73,7 @@ > > %% sctp_paddr_change: Peer address is a list. Possible "state" values: > > %% addr_available, addr_unreachable, > > %% addr_removed, addr_added, > > -%% addr_made_prim > > +%% addr_made_prim, addr_confirmed > > -record(sctp_paddr_change, > > { > > addr = [0,0,0,0], > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > From matthew@REDACTED Tue Apr 15 21:41:37 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 15 Apr 2008 12:41:37 -0700 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: <18435.1529.209488.50485@gargle.gargle.HOWL> References: <18431.9227.133848.989614@gargle.gargle.HOWL> <18435.1529.209488.50485@gargle.gargle.HOWL> Message-ID: On Mon, Apr 14, 2008 at 12:21 AM, Hans Bolinder wrote: > I've tried to find more bugs, but so far without success. I think I came up with a race condition scenario for pg2: Node1 and Node2 are running and communicating. Pid is on Node1, and a member of pg2 group Group. Node3 starts up and connects to Node2 first. Node3 and Node2's pg2 processes exchange their group tables, and Node3 ends up with Pid in the Group table. Node1 goes down before Node3 connects to it. A nodedown message is sent to Node2, who clears Pid from Group. Node1 restarts and exchanges group tables with Node2 and Node3 again, and Pid remains in the Group table. I'm thinking a possible solution would be when a pg2 process receives a {nodeup, Node} message, it first removes all pids from Node in its ets tables and relies on the exchange to reinstate them. From adam@REDACTED Wed Apr 16 10:38:14 2008 From: adam@REDACTED (Adam Lindberg) Date: Wed, 16 Apr 2008 10:38:14 +0200 Subject: [erlang-bugs] edoc copyright generation Message-ID: <6344005f0804160138t2f192b6boe1c63068c220e00a@mail.gmail.com> Hi, When generating an edoc the copyright tag generates a copyright character ((c)) and not the XHTML entity © This renders as ? in Firefox for example. Cheers! Adam From hans.bolinder@REDACTED Wed Apr 16 10:46:22 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Wed, 16 Apr 2008 10:46:22 +0200 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: References: <18431.9227.133848.989614@gargle.gargle.HOWL> <18435.1529.209488.50485@gargle.gargle.HOWL> Message-ID: <18437.48350.271334.980195@gargle.gargle.HOWL> [Matthew Dempsky:] > I think I came up with a race condition scenario for pg2: > > Node1 and Node2 are running and communicating. > Pid is on Node1, and a member of pg2 group Group. > Node3 starts up and connects to Node2 first. > Node3 and Node2's pg2 processes exchange their group tables, > and Node3 ends up with Pid in the Group table. > Node1 goes down before Node3 connects to it. > A nodedown message is sent to Node2, who clears Pid from Group. > Node1 restarts and exchanges group tables with Node2 and Node3 again, > and Pid remains in the Group table. > > I'm thinking a possible solution would be when a pg2 process receives > a {nodeup, Node} message, it first removes all pids from Node in its > ets tables and relies on the exchange to reinstate them. This solution probably works most of the time. But if Global doesn't maintain a fully connected network, or Global encounters problems while connecting nodes, it probably won't work. I think pg2 should monitor all pids rather than link to local pids only. Carefully setting up monitors, like Global does since R11B-4, should work. Best regards, Hans Bolinder, Erlang/OTP team From richardc@REDACTED Wed Apr 16 11:02:07 2008 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 16 Apr 2008 11:02:07 +0200 Subject: [erlang-bugs] edoc copyright generation In-Reply-To: <6344005f0804160138t2f192b6boe1c63068c220e00a@mail.gmail.com> References: <6344005f0804160138t2f192b6boe1c63068c220e00a@mail.gmail.com> Message-ID: <4805C08F.80405@it.uu.se> Adam Lindberg wrote: > Hi, > > When generating an edoc the copyright tag generates a copyright > character ((c)) and not the XHTML entity © > This renders as ? in Firefox for example. Thanks for the report. /Richard From matthias@REDACTED Wed Apr 16 19:59:23 2008 From: matthias@REDACTED (Matthias Radestock) Date: Wed, 16 Apr 2008 18:59:23 +0100 Subject: [erlang-bugs] 100% CPU usage on Mac OS X Leopard after peer closes socket Message-ID: <48063E7B.6020609@sorted.org> The RabbitMQ team have received several reports from users running Mac OS X Leopard that sometimes the RabbitMQ beam process would consume 100% CPU when it was supposedly not doing anything, and never recover from that. We eventually managed to reduce the problem to a test case captured by the attached program. It simply listens on a port, accepts a connection and then sends lots of data down the socket. The interesting bit is what happens when the peer closes the socket. To reproduce the abnormal behaviour just run sock_spin:broken(SomePort). connect to the port with netcat, e.g. nc localhost SomePort > /dev/null and then terminate the connection by ^C'ing netcat. On Mac OS X Leopard this results in {error,einval} being returned (which is expected) and the beam process subsequently consuming 100% CPU (though the Erlang shell remains responsive). By contrast, sock_spin:working/1 is behaving fine - after reporting the error the CPU drops to 0%. Running 'dtruss -c -s -p ' on the spinning beam process shows the following system calls being repeated over and over again: select(0xB, 0x400244, 0x400344, 0x0, 0xBFFFE69C) = 1 0 libSystem.B.dylib`select$DARWIN_EXTSN+0xc beam`check_fd_events+0x124 beam`erts_poll_wait_nkp+0xa0 beam`erts_check_io_nkp+0xb0 beam`erl_sys_schedule+0x90 beam`schedule+0x2ec beam`process_main+0x18c beam`erl_start+0x1150 beam`main+0x10 beam`start+0x44 writev(0xA, 0x48DFBC, 0x2) = -1 Err#32 libSystem.B.dylib`writev$UNIX2003+0xc beam`tcp_inet_drv_output+0x14c beam`erts_port_ready_output+0x6c beam`erts_port_task_execute+0x24c beam`schedule+0x330 beam`process_main+0x18c beam`erl_start+0x1150 beam`main+0x10 beam`start+0x44 getpeername(0xA, 0xBFFFE5BC, 0xBFFFE5B8) = -1 Err#22 libSystem.B.dylib`getpeername$UNIX2003+0xc 0xbfffe590 beam`tcp_inet_drv_output+0x1ac beam`erts_port_ready_output+0x6c beam`erts_port_task_execute+0x24c beam`schedule+0x330 beam`process_main+0x18c beam`erl_start+0x1150 beam`main+0x10 beam`start+0x44 We can reliably reproduce the spinning behaviour with R11B-5, R12B-1 and R12B-2 on Mac OS X Leopard on both ppc and x86. We cannot reproduce the problem on Mac OS X Tiger or various flavours of Debian or Windows. Matthias. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sock_spin.erl URL: From matthew@REDACTED Fri Apr 18 05:48:36 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 17 Apr 2008 20:48:36 -0700 Subject: [erlang-bugs] Patrick Mahoney's SIGWINCH patch In-Reply-To: References: Message-ID: This patch was not included in R12B-2 either, and I've still received no feedback from the developers regarding this patch. Are there any concerns barring its consideration? Upon further review, I did notice that cols_needs_update was not properly marked as volatile in the original diff, so I've changed corrected that and included the updated diff below. I'd really like to see this included upstream. :-) On Thu, Feb 7, 2008 at 12:00 AM, Matthew Dempsky wrote: > I noticed that Patrick Mahoney's SIGWINCH patch[1] was not included in > R12B-1. Is it possible for it to be included in R12B-2? Are there > any issues that need to be resolved for it to be acceptable for > inclusion? > > [1] http://www.erlang.org/pipermail/erlang-patches/2007-December/000205.html --- erts/emulator/drivers/unix/ttsl_drv.c.orig 2007-12-18 04:57:58.000000000 -0700 +++ erts/emulator/drivers/unix/ttsl_drv.c 2007-12-31 12:13:30.000000000 -0700 @@ -58,6 +58,7 @@ static char *capbuf; static char *up, *down, *left, *right; static int cols, xn; +static volatile int cols_needs_update = FALSE; /* The various opcodes. */ #define OP_PUTC 0 @@ -114,6 +115,7 @@ static int move_right(int); static int move_up(int); static int move_down(int); +static void update_cols(void); /* Terminal setting functions. */ static int tty_init(int,int,int,int); @@ -122,6 +124,7 @@ static int ttysl_control(ErlDrvData, unsigned int, char *, int, char **, int); static RETSIGTYPE suspend(int); static RETSIGTYPE cont(int); +static RETSIGTYPE winch(int); /* Define the driver table entry. */ struct erl_drv_entry ttsl_driver_entry = { @@ -200,6 +203,7 @@ setlocale(LC_CTYPE, ""); /* Set international environment */ sys_sigset(SIGCONT, cont); + sys_sigset(SIGWINCH, winch); driver_select(port, (ErlDrvEvent)(Uint)ttysl_fd, DO_READ, 1); ttysl_port = port; @@ -262,6 +266,7 @@ close(ttysl_fd); driver_select(ttysl_port, (ErlDrvEvent)(Uint)ttysl_fd, DO_READ, 0); sys_sigset(SIGCONT, SIG_DFL); + sys_sigset(SIGWINCH, SIG_DFL); } ttysl_port = (ErlDrvPort)-1; ttysl_fd = -1; @@ -432,6 +437,8 @@ int i, l, r; byte *c; + update_cols(); + /* Step forward or backwards over n logical characters. */ c = step_over_chars(n); @@ -553,6 +560,8 @@ */ static int write_buf(byte *s, int n) { + update_cols(); + while (n > 0) { if (isprint(*s)) { outc(*s); @@ -598,6 +607,8 @@ { int dc, dl; + update_cols(); + dc = COL(to) - COL(from); dl = LINE(to) - LINE(from); if (dl > 0) @@ -704,6 +715,27 @@ tputs(down, 1, outc); return TRUE; } + +/* + * Updates cols if terminal has resized (SIGWINCH). Should be called + * at the start of any function that uses the COL or LINE macros. If + * the terminal is resized after calling this function but before use + * of the macros, then we may write to the wrong screen location. + * + * We cannot call this from the SIGWINCH handler because it uses + * ioctl() which is not a safe function as listed in the signal(7) + * man page. + */ +static void update_cols(void) +{ + Uint32 width, height; + + if (cols_needs_update) { + cols_needs_update = FALSE; + ttysl_get_window_size(&width, &height); + cols = width; + } +} /* @@ -830,3 +862,7 @@ } } +static RETSIGTYPE winch(int sig) +{ + cols_needs_update = TRUE; +} From matthew@REDACTED Fri Apr 18 10:23:04 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Fri, 18 Apr 2008 01:23:04 -0700 Subject: [erlang-bugs] [erlang-questions] Weird pg2 behavior In-Reply-To: <18437.48350.271334.980195@gargle.gargle.HOWL> References: <18431.9227.133848.989614@gargle.gargle.HOWL> <18435.1529.209488.50485@gargle.gargle.HOWL> <18437.48350.271334.980195@gargle.gargle.HOWL> Message-ID: On Wed, Apr 16, 2008 at 1:46 AM, Hans Bolinder wrote: > I think pg2 should monitor all pids rather than link to local pids > only. Carefully setting up monitors, like Global does since R11B-4, > should work. Sounds good to me. Can we hope to see this in R12B-3? :-) From bjorn@REDACTED Fri Apr 18 11:37:03 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Apr 2008 11:37:03 +0200 Subject: [erlang-bugs] 100% CPU usage on Mac OS X Leopard after peer closes socket In-Reply-To: <48063E7B.6020609@sorted.org> References: <48063E7B.6020609@sorted.org> Message-ID: Matthias Radestock writes: > On Mac OS X Leopard this results in {error,einval} being returned > (which is expected) and the beam process subsequently consuming 100% > CPU (though the Erlang shell remains responsive). A simple patch that eliminates problem follows. It has not yet been tested in our daily builds on multiple platforms, but it does eliminate the problem on Mac OS 10.5.2 and we don't expect it to cause problems on other platforms. (We are considering fixing the problem in a different way in the R12B-3 release.) Note that the return value from sock_spin:broken/1 will now be {error,closed}, which is that it returns on other platforms. /Bjorn --- erts/emulator/drivers/common/inet_drv.c.ORIG 2008-04-18 11:21:39.000000000 +0200 +++ erts/emulator/drivers/common/inet_drv.c 2008-04-18 11:22:42.000000000 +0200 @@ -8924,6 +8924,7 @@ code = sock_peer(desc->inet.s,(struct sockaddr*) &other,&sz); if ((code == SOCKET_ERROR) && (sock_errno() == ENOTCONN || + sock_errno() == EINVAL || sock_errno() == EPIPE)) { DEBUGF(("driver_failure_eof(%ld) in %s, line %d\r\n", (long)desc->inet.port, __FILE__, __LINE__)); -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From matthias@REDACTED Fri Apr 18 19:04:10 2008 From: matthias@REDACTED (Matthias Radestock) Date: Fri, 18 Apr 2008 18:04:10 +0100 Subject: [erlang-bugs] 100% CPU usage on Mac OS X Leopard after peer closes socket In-Reply-To: References: <48063E7B.6020609@sorted.org> Message-ID: <4808D48A.1090601@sorted.org> Bjorn, Bjorn Gustavsson wrote: > Matthias Radestock writes: > >> On Mac OS X Leopard this results in {error,einval} being returned >> (which is expected) and the beam process subsequently consuming 100% >> CPU (though the Erlang shell remains responsive). > > A simple patch that eliminates problem follows. I can confirm that this does indeed fix the problem on our test system. Thanks for looking into this and producing a patch so quickly. Matthias. From johanmon@REDACTED Wed Apr 16 10:03:39 2008 From: johanmon@REDACTED (Johan Montelius) Date: Wed, 16 Apr 2008 10:03:39 +0200 Subject: [erlang-bugs] gen_tcp:accept manual Erlang/OTP R12B suggestion Message-ID: 8<---------------------------------- accept(ListenSocket) -> {ok, Socket} | {error, Reason} accept(ListenSocket, Timeout) -> {ok, Socket} | {error, Reason} Types: ListenSocket -- see listen/2 Timeout = int() | infinity Socket = socket() Reason = closed | timeout | posix() Accepts an incoming connection request on a listen socket. Socket must be a socket returned from listen/2. Timeout specifies a timeout value in ms, defaults to infinity. 8<--------------------------------- "Socket must be a ...." should be "ListenSocket must be .." or one a could write: accept(Listen) -> {ok, Socket} | {error, Reason} : and then write "Listen must be a ...". Johan -- KTH ICT Johan Montelius From rvirding@REDACTED Mon Apr 21 22:47:34 2008 From: rvirding@REDACTED (Robert Virding) Date: Mon, 21 Apr 2008 22:47:34 +0200 Subject: [erlang-bugs] Crash running R12B-0 code in R12B-2 Message-ID: <3dbc6d1c0804211347r5b89669eta65adf9e39e13d22@mail.gmail.com> I compile my LFE compiler written in straight Erlang on R12B-0 where it runs as expected. However when I then run it on R12B-2 without recompiling it I get the following error: =ERROR REPORT==== 21-Apr-2008::22:41:23 === beam/beam_load.c(1897): Error loading function sys_core_fold:bsm_could_match_binary/1: op bif1_body: bsd: not a BIF: import table index 56 =ERROR REPORT==== 21-Apr-2008::22:41:23 === Loading of c:/Documents and Settings/GameStudio/My Documents/Erlang/Lisp Flavoured Erlang/sys_core_fold.beam failed: badfile ** exception error: no match of right hand side value {error, [{".", [{none,compile, {crash,core_fold_module, {undef, [{sys_core_fold,module, [{c_module,[], {c_literal,[1],test_let}, [{c_fname,[1],a,2}, {c_fname,[1],b,2}, {c_fname,[1],c,...}, {c_fname,[...],...}, {c_fname,...}, {...}|...], [], [{{c_fname,[...],...},{c_fun,...}}, {{c_fname,...},{...}}, {{...},...}, {...}|...]}, [binary,from_core,return_errors]]}, {compile,core_fold_module,1}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]}}}]}], []} in function lfe_comp:do_return/3 The second error report comes from my compiler because I don't check for error returns. :-) My LFE compiler generates Core Erlang code. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Apr 22 12:03:25 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 22 Apr 2008 12:03:25 +0200 Subject: [erlang-bugs] Crash running R12B-0 code in R12B-2 In-Reply-To: <3dbc6d1c0804211347r5b89669eta65adf9e39e13d22@mail.gmail.com> References: <3dbc6d1c0804211347r5b89669eta65adf9e39e13d22@mail.gmail.com> Message-ID: "Robert Virding" writes: > I compile my LFE compiler written in straight Erlang on R12B-0 where it runs > as expected. However when I then run it on R12B-2 without recompiling it I > get the following error: > > =ERROR REPORT==== 21-Apr-2008::22:41:23 === > beam/beam_load.c(1897): Error loading function > sys_core_fold:bsm_could_match_binary/1: op bif1_body: bsd: > not a BIF: import table index 56 Detta ?r ju en fil i kompilatorn. Laddar du kompilatorn fr?n R12B-0 i R12B-2. Det funkar inte. Jag har rensat bort experimentella BIFar och instruktioner. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bjorn@REDACTED Tue Apr 22 12:07:56 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 22 Apr 2008 12:07:56 +0200 Subject: [erlang-bugs] Crash running R12B-0 code in R12B-2 In-Reply-To: <3dbc6d1c0804211347r5b89669eta65adf9e39e13d22@mail.gmail.com> References: <3dbc6d1c0804211347r5b89669eta65adf9e39e13d22@mail.gmail.com> Message-ID: "Robert Virding" writes: > I compile my LFE compiler written in straight Erlang on R12B-0 where it runs > as expected. However when I then run it on R12B-2 without recompiling it I > get the following error: > > =ERROR REPORT==== 21-Apr-2008::22:41:23 === > beam/beam_load.c(1897): Error loading function > sys_core_fold:bsm_could_match_binary/1: op bif1_body: bsd: > not a BIF: import table index 56 Sorry for my previous answer in Swedish. I only noticed that erlang-bugs was CC:ed the same moment I hit the send button. :-( This file is in compiler application. It seems that you are loading the compiler from R12B-0 in R12B-2. That will not work, because I have removed experimental instructions and BIFs. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bengt.kleberg@REDACTED Wed Apr 23 13:55:11 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 23 Apr 2008 13:55:11 +0200 Subject: [erlang-bugs] lack of symmetry in format string for fwrite() and fread() Message-ID: <1208951711.5722.11.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Greetings, ~b is missing in fread() format string and ~d is missing in fwrite() format string. Although properly documented I still feel that this is a bug in the handling of integers in the format string for fwrite() and fread(). Exmaple: > io:fwrite( "~b", [1]). 1 > io:fwrite( "~d", [1]). ** exception exit: {badarg,[{io,format,[<0.30.0>,"~d",[1]]}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_exprs,6}, {shell,eval_loop,3}]} in function io:o_request/2 > io_lib:fread( "~d", "1"). {ok,[1],[]} > io_lib:fread( "~b", "1"). {error,{fread,format}} bengt From bjorn@REDACTED Wed Apr 23 16:15:59 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 23 Apr 2008 16:15:59 +0200 Subject: [erlang-bugs] Patrick Mahoney's SIGWINCH patch In-Reply-To: References: Message-ID: "Matthew Dempsky" writes: > I'd really like to see this included upstream. :-) Thanks for the patch. We will test it and consider it for inclusion in R12B-3. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From tty@REDACTED Wed Apr 23 22:40:57 2008 From: tty@REDACTED (tty@REDACTED) Date: Wed, 23 Apr 2008 16:40:57 -0400 Subject: [erlang-bugs] Internal consistency check failed Message-ID: Hello, Compiling the following code generated an internal consistency check failed. ============================================= -module(test0). -compile([export_all]). parse(<>) -> parse(R, [A]). parse(<<".", R/binary>>, Acc) -> {Acc, <<".", R>>}; parse(<>, Acc) -> parse(R, Acc ++ [A]). ============================================= The output from erlc is: ============================================= Internal consistency check failed - please report this bug. Instruction: {bs_put_integer,{f,0}, {integer,8}, 1, {field_flags,[unsigned,big]}, {x,0}} Error: {match_context,{x,0}}: ============================================= Changing parse(<<".", R/binary>>, Acc) -> {Acc, <<".", R>>}; to parse(<<".", R/binary>>, Acc) -> {Acc, <<".", R/binary>>}; works fine. Changing parse(<<".", R/binary>>, Acc) -> {Acc, <<".", R>>}; to parse(<<".", R>>, Acc) -> {Acc, <<".", R>>}; also works fine. Running with Erlang (SMP,ASYNC_THREADS,HIPE) (BEAM) emulator version 5.6 on Mac OS X v10.5.2 Thanks, Tee From bjorn@REDACTED Thu Apr 24 09:17:04 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 24 Apr 2008 09:17:04 +0200 Subject: [erlang-bugs] Internal consistency check failed In-Reply-To: References: Message-ID: tty@REDACTED writes: > Compiling the following code generated an internal consistency check failed. > The code compiles without problems in R12B-2. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From matthew@REDACTED Fri Apr 25 01:11:27 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 24 Apr 2008 16:11:27 -0700 Subject: [erlang-bugs] R12B-3 crypto driver doesn't build on OpenBSD Message-ID: Trying to build R12B-3 on OpenBSD (4.2-stable or a somewhat dated 4.3-beta snapshot) dies trying to compile crypto_drv.c. gmake[4]: Entering directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' /usr/bin/install -c -d ../priv/obj/x86_64-unknown-openbsd4.3 gcc -c -o ../priv/obj/x86_64-unknown-openbsd4.3/crypto_drv.o -g -O2 -I/home/matthew/src/otp_src_R12B-3/erts/x86_64-unknown-openbsd4.3 -fPIC -I/home/matthew/src/otp_src_R12B-3/erts/emulator/beam -I/home/matthew/src/otp_src_R12B-3/erts/emulator/sys/unix crypto_drv.c crypto_drv.c:36:4: #error No thread support by openssl gmake[4]: *** [../priv/obj/x86_64-unknown-openbsd4.3/crypto_drv.o] Error 1 gmake[4]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' gmake[3]: *** [opt] Error 2 gmake[3]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto' gmake[1]: *** [opt] Error 2 gmake[1]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib' gmake: *** [libs] Error 2 From sverker@REDACTED Fri Apr 25 10:56:21 2008 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 25 Apr 2008 10:56:21 +0200 Subject: [erlang-bugs] R12B-3 crypto driver doesn't build on OpenBSD In-Reply-To: References: Message-ID: <48119CB5.7030105@erix.ericsson.se> I've improved the smp performance by letting several threads call the crypto driver in parallel. Your openssl does however not seem to support thread-safeness. I did not think that would ever be the case. This is how I find out if OpenSSL was configured with thread support according to http://www.openssl.org/docs/crypto/threads.html: #define OPENSSL_THREAD_DEFINES #include #ifndef OPENSSL_THREADS # error No thread support by openssl #endif I will change crypto_drv.c to fall back on the old behaviour with one thread at a time (using driver lock) in the case when openssl does not support it. /Sverker > > ------------------------------------------------------------------------ > > Subject: > [erlang-bugs] R12B-3 crypto driver doesn't build on OpenBSD > From: > "Matthew Dempsky" > Date: > Thu, 24 Apr 2008 16:11:27 -0700 > To: > erlang-bugs@REDACTED > > To: > erlang-bugs@REDACTED > > > Trying to build R12B-3 on OpenBSD (4.2-stable or a somewhat dated > 4.3-beta snapshot) dies trying to compile crypto_drv.c. > > gmake[4]: Entering directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' > /usr/bin/install -c -d ../priv/obj/x86_64-unknown-openbsd4.3 > gcc -c -o ../priv/obj/x86_64-unknown-openbsd4.3/crypto_drv.o -g -O2 > -I/home/matthew/src/otp_src_R12B-3/erts/x86_64-unknown-openbsd4.3 > -fPIC -I/home/matthew/src/otp_src_R12B-3/erts/emulator/beam > -I/home/matthew/src/otp_src_R12B-3/erts/emulator/sys/unix crypto_drv.c > crypto_drv.c:36:4: #error No thread support by openssl > gmake[4]: *** [../priv/obj/x86_64-unknown-openbsd4.3/crypto_drv.o] Error 1 > gmake[4]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' > gmake[3]: *** [opt] Error 2 > gmake[3]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' > gmake[2]: *** [opt] Error 2 > gmake[2]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto' > gmake[1]: *** [opt] Error 2 > gmake[1]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib' > gmake: *** [libs] Error 2 > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > ------------------------------------------------------------------------ > > > > From matthew.dempsky@REDACTED Fri Apr 25 21:32:50 2008 From: matthew.dempsky@REDACTED (Matthew Dempsky) Date: Fri, 25 Apr 2008 12:32:50 -0700 Subject: [erlang-bugs] R12B-3 crypto driver doesn't build on OpenBSD In-Reply-To: <48119CB5.7030105@erix.ericsson.se> References: <48119CB5.7030105@erix.ericsson.se> Message-ID: I'm not familiar with what OPENSSL_THREADS is supposed to do, but I did notice that if I simply comment out that #error line, the driver compiled fine on OpenBSD, and I was able to crypto:start() and run crypto:sha(<<"test">>). It seems like the OpenSSL thread functions are available, just OPENSSL_THREADS isn't defined. On Fri, Apr 25, 2008 at 1:56 AM, Sverker Eriksson wrote: > I've improved the smp performance by letting several threads call the > crypto driver in parallel. Your openssl does however not seem to support > thread-safeness. I did not think that would ever be the case. > This is how I find out if OpenSSL was configured with thread support > according to http://www.openssl.org/docs/crypto/threads.html: > > #define OPENSSL_THREAD_DEFINES > #include > #ifndef OPENSSL_THREADS > # error No thread support by openssl > #endif > > > I will change crypto_drv.c to fall back on the old behaviour with one > thread at a time (using driver lock) in the case when openssl does not > support it. > > /Sverker > > > > > ------------------------------------------------------------------------ > > > > Subject: > > [erlang-bugs] R12B-3 crypto driver doesn't build on OpenBSD > > From: > > "Matthew Dempsky" > > Date: > > Thu, 24 Apr 2008 16:11:27 -0700 > > To: > > erlang-bugs@REDACTED > > > > To: > > erlang-bugs@REDACTED > > > > > > > > Trying to build R12B-3 on OpenBSD (4.2-stable or a somewhat dated > > 4.3-beta snapshot) dies trying to compile crypto_drv.c. > > > > gmake[4]: Entering directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' > > /usr/bin/install -c -d ../priv/obj/x86_64-unknown-openbsd4.3 > > gcc -c -o ../priv/obj/x86_64-unknown-openbsd4.3/crypto_drv.o -g -O2 > > -I/home/matthew/src/otp_src_R12B-3/erts/x86_64-unknown-openbsd4.3 > > -fPIC -I/home/matthew/src/otp_src_R12B-3/erts/emulator/beam > > -I/home/matthew/src/otp_src_R12B-3/erts/emulator/sys/unix crypto_drv.c > > crypto_drv.c:36:4: #error No thread support by openssl > > gmake[4]: *** [../priv/obj/x86_64-unknown-openbsd4.3/crypto_drv.o] Error 1 > > gmake[4]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' > > gmake[3]: *** [opt] Error 2 > > gmake[3]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto/c_src' > > gmake[2]: *** [opt] Error 2 > > gmake[2]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib/crypto' > > gmake[1]: *** [opt] Error 2 > > gmake[1]: Leaving directory `/home/matthew/src/otp_src_R12B-3/lib' > > gmake: *** [libs] Error 2 > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From mog-lists@REDACTED Sat Apr 26 08:13:46 2008 From: mog-lists@REDACTED (mog) Date: Sat, 26 Apr 2008 01:13:46 -0500 Subject: [erlang-bugs] gen_event:notify unexpected behavior Message-ID: <4812C81A.9030406@rldn.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I recently started playing with the gen_event module, in hopes of using it in my program for some optional debugging. Some of the time I would like to turn on an event handler that prints out all the incoming packets, the majority of the time I would just like it off as I would not like to inure the penalty of copying the packets or a description of them all the time only when debugging. The documentation says that gen_event:notify always returns ok, but this is not the case. gen_event:notify(debug,"test"). ** exception error: bad argument in function gen_event:send/2 any of the other options except for the pid option also return an error if the handler is not started. Passing a pid does do what I want in that it returns very quickly, however I would like to have named handlers as they are easier to deal with. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEsfieq+tARrxhnsRAkg7AJ9xB1SO23jUPhR4mJveeroY8fZcXgCdEz+a LwgswouBNKHMF0Zwxg1P5fg= =rs9+ -----END PGP SIGNATURE----- From matthew@REDACTED Sat Apr 26 10:19:12 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sat, 26 Apr 2008 01:19:12 -0700 Subject: [erlang-bugs] gen_event:notify unexpected behavior In-Reply-To: <4812C81A.9030406@rldn.net> References: <4812C81A.9030406@rldn.net> Message-ID: On Fri, Apr 25, 2008 at 11:13 PM, mog wrote: > gen_event:notify(debug,"test"). > ** exception error: bad argument > in function gen_event:send/2 This is documented in the last paragraph of gen_event:notify/2: notify will not fail even if the specified event manager does not exist, unless it is specified as Name. Also, exceptions are not included in the return type specification. From tobbe@REDACTED Mon Apr 28 09:21:08 2008 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Mon, 28 Apr 2008 09:21:08 +0200 Subject: [erlang-bugs] Documentation broken - gotapi Message-ID: Hi folks, I'm a heavy user of: http://www.gotapi.com/erlang It is an absolutely superb service! However, since some Erlang release(s) back. The documentation was changed in some way so that gotapi.com can't locate the exact position in the doc.page for the function you are searching for. Now you only end up at the top of the page. Please, could this be fixed ? -- Tobbe From matthias@REDACTED Mon Apr 28 09:32:04 2008 From: matthias@REDACTED (Matthias Lang) Date: Mon, 28 Apr 2008 09:32:04 +0200 Subject: [erlang-bugs] Documentation broken - gotapi In-Reply-To: References: Message-ID: <18453.32116.458007.877764@antilipe.corelatus.se> Torbjorn Tornkvist writes: > Hi folks, > > I'm a heavy user of: > > http://www.gotapi.com/erlang > > It is an absolutely superb service! > > However, since some Erlang release(s) back. The documentation > was changed in some way so that gotapi.com can't locate > the exact position in the doc.page for the function you are > searching for. Now you only end up at the top of the page. > > Please, could this be fixed ? This is not a bug with the erlang documentation. It's a bug in gotapi's scraper, or, if they do these things manually (?!) a lack of maintenance at gotapi. All that's changed there is that the anchors are now like this: http://erlang.org/doc/man/io.html#fwrite-1 instead of http://erlang.org/doc/man/io.html#fwrite/1 Not exactly rocket science for gotapi to fix. (Not rocket science for erlang.org to change back either, but that's putting the cart in front of the horse) Matthias From kenneth.lundin@REDACTED Mon Apr 28 09:37:21 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 28 Apr 2008 09:37:21 +0200 Subject: [erlang-bugs] Documentation broken - gotapi In-Reply-To: References: Message-ID: Hi, The general change in the Erlang documentation that causes the gotapi to fail is that anchors to functions now are generated as in html. Earlier (in R11B) it was (func is the function name, 1 is the arity) The change is due to that we are now generating xhtml and in xhtml the "/" is not allowed in the name attribute. /Kenneth Erlang/OTP, Ericsson On 4/28/08, Torbjorn Tornkvist wrote: > Hi folks, > > I'm a heavy user of: > > http://www.gotapi.com/erlang > > It is an absolutely superb service! > > However, since some Erlang release(s) back. The documentation > was changed in some way so that gotapi.com can't locate > the exact position in the doc.page for the function you are > searching for. Now you only end up at the top of the page. > > Please, could this be fixed ? > > -- Tobbe > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From kenneth.lundin@REDACTED Mon Apr 28 09:39:53 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 28 Apr 2008 09:39:53 +0200 Subject: [erlang-bugs] Documentation broken - gotapi In-Reply-To: References: Message-ID: Correction, We are now generating . /Kenneth Erlang/OTP, Ericsson On 4/28/08, Kenneth Lundin wrote: > Hi, > > The general change in the Erlang documentation that causes the gotapi > to fail is that anchors to functions now are generated as > in html. Earlier (in R11B) it was > (func is the function name, 1 is the arity) > > The change is due to that we are now generating xhtml and in xhtml > the "/" is not allowed in the name attribute. > > /Kenneth Erlang/OTP, Ericsson > > On 4/28/08, Torbjorn Tornkvist wrote: > > Hi folks, > > > > I'm a heavy user of: > > > > http://www.gotapi.com/erlang > > > > It is an absolutely superb service! > > > > However, since some Erlang release(s) back. The documentation > > was changed in some way so that gotapi.com can't locate > > the exact position in the doc.page for the function you are > > searching for. Now you only end up at the top of the page. > > > > Please, could this be fixed ? > > > > -- Tobbe > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > From tobbe@REDACTED Mon Apr 28 10:00:14 2008 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Mon, 28 Apr 2008 10:00:14 +0200 Subject: [erlang-bugs] Documentation broken - gotapi In-Reply-To: <18453.32116.458007.877764@antilipe.corelatus.se> References: <18453.32116.458007.877764@antilipe.corelatus.se> Message-ID: Matthias Lang wrote: > Torbjorn Tornkvist writes: > > Hi folks, > > > > I'm a heavy user of: > > > > http://www.gotapi.com/erlang > > > > It is an absolutely superb service! > > > > However, since some Erlang release(s) back. The documentation > > was changed in some way so that gotapi.com can't locate > > the exact position in the doc.page for the function you are > > searching for. Now you only end up at the top of the page. > > > > Please, could this be fixed ? > > This is not a bug with the erlang documentation. It's a bug in > gotapi's scraper, or, if they do these things manually (?!) a lack of > maintenance at gotapi. Aha, I see. Apparently the guy who hooked in Erlang is named Matthew Pflueger. Are you reading this Matthew ? Any ideas on a solution? --Tobbe > > All that's changed there is that the anchors are now like this: > > http://erlang.org/doc/man/io.html#fwrite-1 > > instead of > > http://erlang.org/doc/man/io.html#fwrite/1 > > Not exactly rocket science for gotapi to fix. (Not rocket science for > erlang.org to change back either, but that's putting the cart in front > of the horse) > > Matthias > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From opfer@REDACTED Tue Apr 29 02:07:35 2008 From: opfer@REDACTED (Christian Faulhammer) Date: Tue, 29 Apr 2008 02:07:35 +0200 Subject: [erlang-bugs] Patch to build with --as-needed in LDFLAGS Message-ID: <20080429020735.111355e8@gentoo.org> Hi, as I wrote some weeks ago, Erlang is badly broken if a system is built with --as-neede in LDFLAGS. Attached patch corrects this. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: erlang-as-needed.patch Type: text/x-patch Size: 681 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Wed Apr 30 12:14:04 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 30 Apr 2008 12:14:04 +0200 Subject: [erlang-bugs] lack of symmetry in format string for fwrite() and fread() In-Reply-To: <1208951711.5722.11.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> References: <1208951711.5722.11.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Message-ID: <20080430101404.GA17328@erix.ericsson.se> On Wed, Apr 23, 2008 at 01:55:11PM +0200, Bengt Kleberg wrote: > Greetings, > > ~b is missing in fread() format string and ~d is missing in fwrite() > format string. > > Although properly documented I still feel that this is a bug in the > handling of integers in the format string for fwrite() and fread(). > io_lib:fread("~16b", " -17 ") -> {ok,[-23]," "} would then be functionally equivalent to the existing: io_lib:fread" ~-~16u", " -17 ") -> {ok,[-1,23]," "} that delivers the result in two variables, and io_lib:fread("~b", " -17 ") -> {ok,[-17]," "} would then be the same as io_lib:fread("~d", " -17 ") -> {ok,[-17]," "} io:fwrite("~d\n", [-17]) would then be the same as the existing: io:fwrite("~b\n", [-17]) which actually is a shorthand for: io:fwrite("~.10b\n", [-17]) So the missing read ~b and write ~d does not add any functionality, we regard it as a low priority problem. Do not count on them being added in the near future. > Exmaple: > > io:fwrite( "~b", [1]). > 1 > > io:fwrite( "~d", [1]). > ** exception exit: {badarg,[{io,format,[<0.30.0>,"~d",[1]]}, > {erl_eval,do_apply,5}, > {shell,exprs,6}, > {shell,eval_exprs,6}, > {shell,eval_loop,3}]} > in function io:o_request/2 > > > io_lib:fread( "~d", "1"). > {ok,[1],[]} > > io_lib:fread( "~b", "1"). > {error,{fread,format}} > > > > bengt > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB