From n.oxyde@REDACTED Sun Dec 1 13:21:05 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 13:21:05 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: A PR was created by Henrik, it may as well be announced here?: https://github.com/erlang/otp/pull/150 -- Anthony Ramine Le 16 nov. 2013 ? 13:58, Anthony Ramine a ?crit : > Finally I may have found one. > > Tell me where I should write tests for that and I will add them. > > git fetch https://github.com/nox/otp.git core-clause-subst > > https://github.com/nox/otp/compare/erlang:maint...core-clause-subst > https://github.com/nox/otp/compare/erlang:maint...core-clause-subst.patch > > Regards, > > -- > Anthony Ramine > > Le 16 nov. 2013 ? 13:27, Anthony Ramine a ?crit : > >> Hello, >> >> I have trying to fix a bug for a while without success so I post it here. >> >> t(Bin1) -> >> case Bin1 of >> <<>> -> ok; >> Bin2 -> >> case Bin1 of >> <<0>> -> ok; >> _ -> Bin2 >> end >> end. >> >> In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: >> >> t: function t/1+17: >> Internal consistency check failed - please report this bug. >> Instruction: return >> Error: {match_context,{x,0}}: >> >> Regards, >> >> -- >> Anthony Ramine >> > From n.oxyde@REDACTED Sun Dec 1 13:21:28 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 13:21:28 +0100 Subject: [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler In-Reply-To: <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> Message-ID: <9FA43EB6-559F-49B4-9971-07F70AC3E9DA@gmail.com> PR created by Henrik: https://github.com/erlang/otp/pull/152 -- Anthony Ramine Le 18 nov. 2013 ? 13:41, Anthony Ramine a ?crit : > I owe you a beer for that tip, I should have thought to grep for no_postopt in the code. > > I have just found another discrepancy with regard to allocate and init by recompiling sofs. > > -- > Anthony Ramine > > Le 18 nov. 2013 ? 12:58, Bj?rn Gustavsson a ?crit : > >> Suggestion: Include the following one-line change in your patch and >> fix the remaining problems: > From n.oxyde@REDACTED Sun Dec 1 14:37:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 14:37:35 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: <64A693D8-EA9C-4E1E-9A1D-82ED07384434@gmail.com> Amended the commit to fix a bug when folding over receive clauses. Please refetch. -- Anthony Ramine Le 1 d?c. 2013 ? 13:21, Anthony Ramine a ?crit : > A PR was created by Henrik, it may as well be announced here?: > > https://github.com/erlang/otp/pull/150 > > -- > Anthony Ramine > > Le 16 nov. 2013 ? 13:58, Anthony Ramine a ?crit : > >> Finally I may have found one. >> >> Tell me where I should write tests for that and I will add them. >> >> git fetch https://github.com/nox/otp.git core-clause-subst >> >> https://github.com/nox/otp/compare/erlang:maint...core-clause-subst >> https://github.com/nox/otp/compare/erlang:maint...core-clause-subst.patch >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 16 nov. 2013 ? 13:27, Anthony Ramine a ?crit : >> >>> Hello, >>> >>> I have trying to fix a bug for a while without success so I post it here. >>> >>> t(Bin1) -> >>> case Bin1 of >>> <<>> -> ok; >>> Bin2 -> >>> case Bin1 of >>> <<0>> -> ok; >>> _ -> Bin2 >>> end >>> end. >>> >>> In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: >>> >>> t: function t/1+17: >>> Internal consistency check failed - please report this bug. >>> Instruction: return >>> Error: {match_context,{x,0}}: >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >> > From n.oxyde@REDACTED Sun Dec 1 14:48:42 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 14:48:42 +0100 Subject: [erlang-bugs] [erlang-patches] Properly handle export_all when looking for undefined callbacks In-Reply-To: <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> <525BA344.9020907@erlang.org> <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> Message-ID: Ping? -- Anthony Ramine Le 29 oct. 2013 ? 16:50, Anthony Ramine a ?crit : > export_all means that everything is exported, so seeing a warning about an undefined behaviour callback is quite weird and surprising and confusing. > > At the very least, the message should be changed when export_all is used, maybe something like "warning: callback is not explicitly exported". > > I still think this is a bug, you use export_all during development to avoid exporting warnings and/or errors. > > -- > Anthony Ramine > > Le 29 oct. 2013 ? 16:07, Robert Virding a ?crit : > >> Sorry I missed this one earlier. Do you mean EVERY callback or just those which haven't been explicitly exported and have been left to the export_all? If it is the latter case then I wouldn't consider this an error. Functions which are meant to be seen on the outside of a module should be explicitly exported, export_all is more a development/debugging hack. IMAO anyway. If it the first case where having an export_all means that no callback is seen then it is a bug. >> >> Robert >> >> ----- Original Message ----- >>> From: "Fredrik" >>> >>> On 10/12/2013 02:10 PM, Anthony Ramine wrote: >>>> Hello, >>>> >>>> When compiling a behaviour with export_all, every callback is marked as >>>> missing by erl_lint. This patch fixes this. >>>> >>>> Thanks to Michele Miron (Cc'd) for reporting this bug. >>>> >>>> git fetch https://github.com/nox/otp.git export_all-behaviour >>>> >>>> https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour >>>> https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour.patch >>>> >>>> Regards, >>>> >>> Hello Anthony, >>> I've fetched your patch, applied the correct bootstrap file and assigned >>> it to be reviewed by responsible developers. >>> Thanks, >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> > From henrik@REDACTED Mon Dec 2 08:53:43 2013 From: henrik@REDACTED (Henrik Nord) Date: Mon, 2 Dec 2013 08:53:43 +0100 Subject: [erlang-bugs] [erlang-patches] Properly handle export_all when looking for undefined callbacks In-Reply-To: References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> <525BA344.9020907@erlang.org> <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> Message-ID: <529C3C87.5080208@erlang.org> We are currently reviewing this patch, and it is under some discussion here. /Henrik On 2013-12-01 14:48, Anthony Ramine wrote: > Ping? > -- /Henrik Nord Erlang/OTP From wieslaw.bieniek@REDACTED Wed Dec 4 11:30:43 2013 From: wieslaw.bieniek@REDACTED (=?UTF-8?B?V2llc8WCYXcgQmllbmllaw==?=) Date: Wed, 04 Dec 2013 11:30:43 +0100 Subject: [erlang-bugs] Mnesia stopped after error {no_exists, tTable, where_to_commit} Message-ID: <529F0453.9070701@comarch.pl> Hello, I've ecountered following problem: 1. There are 2 nodes up. 2. One of them has table as disc_only_copies 3. Second one is trying to write to this table remotely 4. Sometimes the error occurs: Mnesia('radius01v2@REDACTED'): ** ERROR ** (ignoring core) ** FATAL ** mnesia_controller crashed: {no_exists, {tTable, where_to_commit}} state: {state, <0.603.0>, true, [], [], {0, nil}, [], [], {0, nil}, undefined, [], [], #Ref<0.0.175.61285>, false} 5. Then after several tries mnesia reaches max_restarts and whole node is shutting down. The question is: What could cause the problem ? -- *Wies?aw Bieniek* Designer Telco BSS R&D tel. +48 12 646 12 66 website: www.comarch.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2197 bytes Desc: Kryptograficzna sygnatura S/MIME URL: From dangud@REDACTED Wed Dec 4 11:46:09 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 4 Dec 2013 11:46:09 +0100 Subject: [erlang-bugs] Mnesia stopped after error {no_exists, tTable, where_to_commit} In-Reply-To: <529F0453.9070701@comarch.pl> References: <529F0453.9070701@comarch.pl> Message-ID: You need to call mnesia:wait_for_tables/2 before accessing it. /Dan On Wed, Dec 4, 2013 at 11:30 AM, Wies?aw Bieniek wrote: > Hello, > > I've ecountered following problem: > > 1. There are 2 nodes up. > 2. One of them has table as disc_only_copies > 3. Second one is trying to write to this table remotely > 4. Sometimes the error occurs: Mnesia('radius01v2@REDACTED'): ** > ERROR ** (ignoring core) ** FATAL ** mnesia_controller crashed: {no_exists, > > {tTable, > > where_to_commit}} state: {state, > > <0.603.0>, > > true, > > [], > > [], > > {0, > > nil}, > > [], > > [], > > {0, > > nil}, > > undefined, > > [], > > [], > > #Ref<0.0.175.61285>, > > false} > 5. Then after several tries mnesia reaches max_restarts and whole node is > shutting down. > > The question is: > > What could cause the problem ? > > > -- > *Wies?aw Bieniek* > Designer Telco BSS R&D > > tel. +48 12 646 12 66 > website: www.comarch.pl > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a-grk@REDACTED Wed Dec 4 11:56:51 2013 From: a-grk@REDACTED (Alex Peshkov) Date: Wed, 4 Dec 2013 14:56:51 +0400 Subject: [erlang-bugs] R16B02 asn1 encoding issue In-Reply-To: References: <6B4665B5-72CC-4887-B9A6-4C8B796F41A4@yandex.ru> Message-ID: Thank you very much for the advice. It helped. --? Alex Peshkov On 28 ?????? 2013 ?. at 20:15:56, Bj?rn Gustavsson (bgustavsson@REDACTED) wrote: On Thu, Nov 28, 2013 at 2:19 PM, Alex Peshkov wrote: [...]? This part of code is omitted by erlang asn1 compiler: ' enc_AppConfig'({?AppConfig',Val}, TagIn) -> ? ?'enc_AppConfig'(Val, TagIn); and I get function_clause error during asn1ct:encode call. The use of {Type,Val} has long been obsolete, and it didn't work in all back-ends in R15. In R16, we have removed the old back-ends and removed all support for {Type,Val}. So what you need is to stop using {'AppConfig',Val} and only use Val. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From shino.shun@REDACTED Wed Dec 4 15:06:44 2013 From: shino.shun@REDACTED (Shunichi Shinohara) Date: Wed, 4 Dec 2013 23:06:44 +0900 Subject: [erlang-bugs] release_handler error in upgrading slim release In-Reply-To: References: Message-ID: Hi Siri, > release_handler is not explicitly "slim-release aware", since this is > a reltool mechanism. (And also, it is only experimental.) So it's not (exactly) a bug, I'm sorry to bother you and the erlang-bugs list. > I think, however, that you can solve your problem by unpacking your > tar file manually and then using release_handler:set_unpacked/2 > instead of release_handler:unpack_release/1. Thank you very much for the information. I tried release_handler:set_unpacked/2 and could confirm everything went well in upgrading with slim release. Yay! I updated the sample repository and its README to explain the way. https://github.com/shino/slim-upgrade-sample Thanks again! Shino From mikpelinux@REDACTED Wed Dec 4 15:00:33 2013 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 4 Dec 2013 15:00:33 +0100 Subject: [erlang-bugs] mnesia/dets breakage when otp R15B03-1 is compiled by gcc 4.8 or 4.9 Message-ID: <21151.13697.609819.933464@gargle.gargle.HOWL> We're using otp R15B03-1 on x86_64-linux. During initialization of our application we create a bunch of mnesia disc_copies tables. If otp was compiled by gcc 4.8 or 4.9, then during the creation of the 257th mnesia table DETS spews the following warning dets: file "/.../Mnesia.nonode@REDACTED/schema.DAT" not properly closed, repairing ... but the mnesia:create_table/2 call doesn't fail. However the schema.DAT file is corrupt and subsequent usage of mnesia fails. If otp R15B03-1 is compiled with gcc 4.7 or 4.6 the problem doesn't occur. If we use otp R16B02 compiled by gcc 4.8 or 4.9 the problem doesn't occur. At the moment we can't upgrade to R16B02, and as our developers upgrade their machines to newer Linux distributions they get gcc-4.8 as their system compiler and things break. Are there any known bug fixes in R16 that may be related to this? I'm appending the trivial reproducer below. /Mikael -module(bug). -compile(export_all). doit() -> mnesia:delete_schema([node()]), mnesia:create_schema([node()]), mnesia:start(), doit(0). doit(I) when I < 260 -> D0 = $0 + (I rem 10), D1 = $0 + ((I div 10) rem 10), D2 = $0 + ((I div 100) rem 10), Name = list_to_atom([$f, $o, $o, D2, D1, D0]), io:format("creating table ~p~n", [Name]), TabDef = [{disc_copies,[node()]}, {type,set}, {attributes,[key,val]}], {atomic, ok} = mnesia:create_table(Name, TabDef), doit(I + 1); doit(_I) -> ok. From lukas@REDACTED Wed Dec 4 18:03:11 2013 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 4 Dec 2013 18:03:11 +0100 Subject: [erlang-bugs] mnesia/dets breakage when otp R15B03-1 is compiled by gcc 4.8 or 4.9 In-Reply-To: <21151.13697.609819.933464@gargle.gargle.HOWL> References: <21151.13697.609819.933464@gargle.gargle.HOWL> Message-ID: <529F604F.2060605@erlang.org> Hello, Could it be OTP-11246? It is the only gcc version related patch that I can think of. Lukas On 04/12/13 15:00, Mikael Pettersson wrote: > We're using otp R15B03-1 on x86_64-linux. During initialization of our > application we create a bunch of mnesia disc_copies tables. If otp > was compiled by gcc 4.8 or 4.9, then during the creation of the 257th > mnesia table DETS spews the following warning > > dets: file "/.../Mnesia.nonode@REDACTED/schema.DAT" not properly closed, repairing ... > > but the mnesia:create_table/2 call doesn't fail. However the schema.DAT > file is corrupt and subsequent usage of mnesia fails. > > If otp R15B03-1 is compiled with gcc 4.7 or 4.6 the problem doesn't occur. > > If we use otp R16B02 compiled by gcc 4.8 or 4.9 the problem doesn't occur. > > At the moment we can't upgrade to R16B02, and as our developers upgrade their > machines to newer Linux distributions they get gcc-4.8 as their system compiler > and things break. > > Are there any known bug fixes in R16 that may be related to this? > > I'm appending the trivial reproducer below. > > /Mikael > > -module(bug). > -compile(export_all). > doit() -> > mnesia:delete_schema([node()]), > mnesia:create_schema([node()]), > mnesia:start(), > doit(0). > > doit(I) when I < 260 -> > D0 = $0 + (I rem 10), > D1 = $0 + ((I div 10) rem 10), > D2 = $0 + ((I div 100) rem 10), > Name = list_to_atom([$f, $o, $o, D2, D1, D0]), > io:format("creating table ~p~n", [Name]), > TabDef = [{disc_copies,[node()]}, {type,set}, {attributes,[key,val]}], > {atomic, ok} = mnesia:create_table(Name, TabDef), > doit(I + 1); > doit(_I) -> > ok. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From mikpelinux@REDACTED Wed Dec 4 20:44:23 2013 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 4 Dec 2013 20:44:23 +0100 Subject: [erlang-bugs] mnesia/dets breakage when otp R15B03-1 is compiled by gcc 4.8 or 4.9 In-Reply-To: <529F604F.2060605@erlang.org> References: <21151.13697.609819.933464@gargle.gargle.HOWL> <529F604F.2060605@erlang.org> Message-ID: <21151.34327.78126.117903@gargle.gargle.HOWL> Lukas Larsson writes: > Hello, > > Could it be OTP-11246? It is the only gcc version related patch that I > can think of. Perhaps, I did a git bisect which did find something, but I didn't have time to analyze the results today. I'll follow up tomorrow. /Mikael > > Lukas > > On 04/12/13 15:00, Mikael Pettersson wrote: > > We're using otp R15B03-1 on x86_64-linux. During initialization of our > > application we create a bunch of mnesia disc_copies tables. If otp > > was compiled by gcc 4.8 or 4.9, then during the creation of the 257th > > mnesia table DETS spews the following warning > > > > dets: file "/.../Mnesia.nonode@REDACTED/schema.DAT" not properly closed, repairing ... > > > > but the mnesia:create_table/2 call doesn't fail. However the schema.DAT > > file is corrupt and subsequent usage of mnesia fails. > > > > If otp R15B03-1 is compiled with gcc 4.7 or 4.6 the problem doesn't occur. > > > > If we use otp R16B02 compiled by gcc 4.8 or 4.9 the problem doesn't occur. > > > > At the moment we can't upgrade to R16B02, and as our developers upgrade their > > machines to newer Linux distributions they get gcc-4.8 as their system compiler > > and things break. > > > > Are there any known bug fixes in R16 that may be related to this? > > > > I'm appending the trivial reproducer below. > > > > /Mikael > > > > -module(bug). > > -compile(export_all). > > doit() -> > > mnesia:delete_schema([node()]), > > mnesia:create_schema([node()]), > > mnesia:start(), > > doit(0). > > > > doit(I) when I < 260 -> > > D0 = $0 + (I rem 10), > > D1 = $0 + ((I div 10) rem 10), > > D2 = $0 + ((I div 100) rem 10), > > Name = list_to_atom([$f, $o, $o, D2, D1, D0]), > > io:format("creating table ~p~n", [Name]), > > TabDef = [{disc_copies,[node()]}, {type,set}, {attributes,[key,val]}], > > {atomic, ok} = mnesia:create_table(Name, TabDef), > > doit(I + 1); > > doit(_I) -> > > ok. > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- From mikpelinux@REDACTED Thu Dec 5 12:54:10 2013 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 5 Dec 2013 12:54:10 +0100 Subject: [erlang-bugs] mnesia/dets breakage when otp R15B03-1 is compiled by gcc 4.8 or 4.9 In-Reply-To: <529F604F.2060605@erlang.org> References: <21151.13697.609819.933464@gargle.gargle.HOWL> <529F604F.2060605@erlang.org> Message-ID: <21152.26978.96391.430696@gargle.gargle.HOWL> Lukas Larsson writes: > Hello, > > Could it be OTP-11246? It is the only gcc version related patch that I > can think of. Both test cases, mine and Erik's, are fixed by backporting two commits, >From 9f3dc09c1a70bd485b211768bedf989bed7fbf21 Mon Sep 17 00:00:00 2001 From: Lukas Larsson Date: Mon, 12 Aug 2013 16:04:31 +0200 Subject: [PATCH] erts: Refactor non-pure macros to functions and >From 3b1d9f46c187ecdad3930c52fa4fbe4d547277c8 Mon Sep 17 00:00:00 2001 From: Lukas Larsson Date: Tue, 20 Aug 2013 17:19:36 +0200 Subject: [PATCH] erts: Fix bug in translating ev macros to functions The first one suffices for the test cases, but the second one fixes apparent errors in the first one so I'll treat them as a unit. I'll run some more tests on our full code base. /Mikael > > Lukas > > On 04/12/13 15:00, Mikael Pettersson wrote: > > We're using otp R15B03-1 on x86_64-linux. During initialization of our > > application we create a bunch of mnesia disc_copies tables. If otp > > was compiled by gcc 4.8 or 4.9, then during the creation of the 257th > > mnesia table DETS spews the following warning > > > > dets: file "/.../Mnesia.nonode@REDACTED/schema.DAT" not properly closed, repairing ... > > > > but the mnesia:create_table/2 call doesn't fail. However the schema.DAT > > file is corrupt and subsequent usage of mnesia fails. > > > > If otp R15B03-1 is compiled with gcc 4.7 or 4.6 the problem doesn't occur. > > > > If we use otp R16B02 compiled by gcc 4.8 or 4.9 the problem doesn't occur. > > > > At the moment we can't upgrade to R16B02, and as our developers upgrade their > > machines to newer Linux distributions they get gcc-4.8 as their system compiler > > and things break. > > > > Are there any known bug fixes in R16 that may be related to this? > > > > I'm appending the trivial reproducer below. > > > > /Mikael > > > > -module(bug). > > -compile(export_all). > > doit() -> > > mnesia:delete_schema([node()]), > > mnesia:create_schema([node()]), > > mnesia:start(), > > doit(0). > > > > doit(I) when I < 260 -> > > D0 = $0 + (I rem 10), > > D1 = $0 + ((I div 10) rem 10), > > D2 = $0 + ((I div 100) rem 10), > > Name = list_to_atom([$f, $o, $o, D2, D1, D0]), > > io:format("creating table ~p~n", [Name]), > > TabDef = [{disc_copies,[node()]}, {type,set}, {attributes,[key,val]}], > > {atomic, ok} = mnesia:create_table(Name, TabDef), > > doit(I + 1); > > doit(_I) -> > > ok. > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- From sverker.eriksson@REDACTED Thu Dec 5 13:32:58 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 5 Dec 2013 13:32:58 +0100 Subject: [erlang-bugs] mnesia/dets breakage when otp R15B03-1 is compiled by gcc 4.8 or 4.9 In-Reply-To: <21152.26978.96391.430696@gargle.gargle.HOWL> References: <21151.13697.609819.933464@gargle.gargle.HOWL> <529F604F.2060605@erlang.org> <21152.26978.96391.430696@gargle.gargle.HOWL> Message-ID: <52A0727A.3000207@erix.ericsson.se> This commit seems like yet a bug fix for the this fix. c4da6eed78d30670d3602f746030e03c46137ead Fix EV_* macros and functions signedness flaws /Sverker, Erlang/OTP On 12/05/2013 12:54 PM, Mikael Pettersson wrote: > Lukas Larsson writes: > > Hello, > > > > Could it be OTP-11246? It is the only gcc version related patch that I > > can think of. > > Both test cases, mine and Erik's, are fixed by backporting two commits, > > >From 9f3dc09c1a70bd485b211768bedf989bed7fbf21 Mon Sep 17 00:00:00 2001 > From: Lukas Larsson > Date: Mon, 12 Aug 2013 16:04:31 +0200 > Subject: [PATCH] erts: Refactor non-pure macros to functions > > and > > >From 3b1d9f46c187ecdad3930c52fa4fbe4d547277c8 Mon Sep 17 00:00:00 2001 > From: Lukas Larsson > Date: Tue, 20 Aug 2013 17:19:36 +0200 > Subject: [PATCH] erts: Fix bug in translating ev macros to functions > > The first one suffices for the test cases, but the second one fixes > apparent errors in the first one so I'll treat them as a unit. > > I'll run some more tests on our full code base. > > /Mikael > > > > > Lukas > > > > On 04/12/13 15:00, Mikael Pettersson wrote: > > > We're using otp R15B03-1 on x86_64-linux. During initialization of our > > > application we create a bunch of mnesia disc_copies tables. If otp > > > was compiled by gcc 4.8 or 4.9, then during the creation of the 257th > > > mnesia table DETS spews the following warning > > > > > > dets: file "/.../Mnesia.nonode@REDACTED/schema.DAT" not properly closed, repairing ... > > > > > > but the mnesia:create_table/2 call doesn't fail. However the schema.DAT > > > file is corrupt and subsequent usage of mnesia fails. > > > > > > If otp R15B03-1 is compiled with gcc 4.7 or 4.6 the problem doesn't occur. > > > > > > If we use otp R16B02 compiled by gcc 4.8 or 4.9 the problem doesn't occur. > > > > > > At the moment we can't upgrade to R16B02, and as our developers upgrade their > > > machines to newer Linux distributions they get gcc-4.8 as their system compiler > > > and things break. > > > > > > Are there any known bug fixes in R16 that may be related to this? > > > > > > I'm appending the trivial reproducer below. > > > > > > /Mikael > > > > > > -module(bug). > > > -compile(export_all). > > > doit() -> > > > mnesia:delete_schema([node()]), > > > mnesia:create_schema([node()]), > > > mnesia:start(), > > > doit(0). > > > > > > doit(I) when I < 260 -> > > > D0 = $0 + (I rem 10), > > > D1 = $0 + ((I div 10) rem 10), > > > D2 = $0 + ((I div 100) rem 10), > > > Name = list_to_atom([$f, $o, $o, D2, D1, D0]), > > > io:format("creating table ~p~n", [Name]), > > > TabDef = [{disc_copies,[node()]}, {type,set}, {attributes,[key,val]}], > > > {atomic, ok} = mnesia:create_table(Name, TabDef), > > > doit(I + 1); > > > doit(_I) -> > > > ok. > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > From mikpelinux@REDACTED Thu Dec 5 14:00:30 2013 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 5 Dec 2013 14:00:30 +0100 Subject: [erlang-bugs] mnesia/dets breakage when otp R15B03-1 is compiled by gcc 4.8 or 4.9 In-Reply-To: <52A0727A.3000207@erix.ericsson.se> References: <21151.13697.609819.933464@gargle.gargle.HOWL> <529F604F.2060605@erlang.org> <21152.26978.96391.430696@gargle.gargle.HOWL> <52A0727A.3000207@erix.ericsson.se> Message-ID: <21152.30958.675974.237446@gargle.gargle.HOWL> Sverker Eriksson writes: > This commit seems like yet a bug fix for the this fix. > > c4da6eed78d30670d3602f746030e03c46137ead > Fix EV_* macros and functions signedness flaws I saw that one too. It seems related but doesn't backport cleanly (hunk #4 fails to apply) -- the problematic hunk seems redundant so I'll try with it omitted. /Mikael > > /Sverker, Erlang/OTP > > > On 12/05/2013 12:54 PM, Mikael Pettersson wrote: > > Lukas Larsson writes: > > > Hello, > > > > > > Could it be OTP-11246? It is the only gcc version related patch that I > > > can think of. > > > > Both test cases, mine and Erik's, are fixed by backporting two commits, > > > > >From 9f3dc09c1a70bd485b211768bedf989bed7fbf21 Mon Sep 17 00:00:00 2001 > > From: Lukas Larsson > > Date: Mon, 12 Aug 2013 16:04:31 +0200 > > Subject: [PATCH] erts: Refactor non-pure macros to functions > > > > and > > > > >From 3b1d9f46c187ecdad3930c52fa4fbe4d547277c8 Mon Sep 17 00:00:00 2001 > > From: Lukas Larsson > > Date: Tue, 20 Aug 2013 17:19:36 +0200 > > Subject: [PATCH] erts: Fix bug in translating ev macros to functions > > > > The first one suffices for the test cases, but the second one fixes > > apparent errors in the first one so I'll treat them as a unit. > > > > I'll run some more tests on our full code base. > > > > /Mikael > > > > > > > > Lukas > > > > > > On 04/12/13 15:00, Mikael Pettersson wrote: > > > > We're using otp R15B03-1 on x86_64-linux. During initialization of our > > > > application we create a bunch of mnesia disc_copies tables. If otp > > > > was compiled by gcc 4.8 or 4.9, then during the creation of the 257th > > > > mnesia table DETS spews the following warning > > > > > > > > dets: file "/.../Mnesia.nonode@REDACTED/schema.DAT" not properly closed, repairing ... > > > > > > > > but the mnesia:create_table/2 call doesn't fail. However the schema.DAT > > > > file is corrupt and subsequent usage of mnesia fails. > > > > > > > > If otp R15B03-1 is compiled with gcc 4.7 or 4.6 the problem doesn't occur. > > > > > > > > If we use otp R16B02 compiled by gcc 4.8 or 4.9 the problem doesn't occur. > > > > > > > > At the moment we can't upgrade to R16B02, and as our developers upgrade their > > > > machines to newer Linux distributions they get gcc-4.8 as their system compiler > > > > and things break. > > > > > > > > Are there any known bug fixes in R16 that may be related to this? > > > > > > > > I'm appending the trivial reproducer below. > > > > > > > > /Mikael > > > > > > > > -module(bug). > > > > -compile(export_all). > > > > doit() -> > > > > mnesia:delete_schema([node()]), > > > > mnesia:create_schema([node()]), > > > > mnesia:start(), > > > > doit(0). > > > > > > > > doit(I) when I < 260 -> > > > > D0 = $0 + (I rem 10), > > > > D1 = $0 + ((I div 10) rem 10), > > > > D2 = $0 + ((I div 100) rem 10), > > > > Name = list_to_atom([$f, $o, $o, D2, D1, D0]), > > > > io:format("creating table ~p~n", [Name]), > > > > TabDef = [{disc_copies,[node()]}, {type,set}, {attributes,[key,val]}], > > > > {atomic, ok} = mnesia:create_table(Name, TabDef), > > > > doit(I + 1); > > > > doit(_I) -> > > > > ok. > > > > _______________________________________________ > > > > erlang-bugs mailing list > > > > erlang-bugs@REDACTED > > > > http://erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-bugs > > -- From bgustavsson@REDACTED Fri Dec 6 10:56:32 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 6 Dec 2013 10:56:32 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: On Sat, Nov 16, 2013 at 1:58 PM, Anthony Ramine wrote: > Finally I may have found one. > > Tell me where I should write tests for that and I will add them. > > bs_match_SUITE.erl -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Dec 6 11:07:21 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 6 Dec 2013 11:07:21 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: That?s for the original bug, but the fix I did is way more pervasive, don?t you think? Any additional suites I should patch for that reason? -- Anthony Ramine Le 6 d?c. 2013 ? 10:56, Bj?rn Gustavsson a ?crit : > On Sat, Nov 16, 2013 at 1:58 PM, Anthony Ramine wrote: > Finally I may have found one. > > Tell me where I should write tests for that and I will add them. > > > bs_match_SUITE.erl > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Mon Dec 9 12:54:06 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 9 Dec 2013 12:54:06 +0100 Subject: [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: On Fri, Dec 6, 2013 at 11:07 AM, Anthony Ramine wrote: > That?s for the original bug, but the fix I did is way more pervasive, > don?t you think? > > Any additional suites I should patch for that reason? > > core_fold_SUITE.erl I have not looked closely at the patch yet, but I have a few questions: The variable GSub is named that way because it was only used for the guard. Shouldn't it be renamed now that it is used both for the guard and body? Shouldn't the comment be updated? -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Tue Dec 10 00:51:31 2013 From: nem@REDACTED (Geoff Cant) Date: Mon, 9 Dec 2013 15:51:31 -0800 Subject: [erlang-bugs] Weird crypto:start() bug with 717cf073 / OTP-11408 Message-ID: <6036C8A6-92C4-45E0-8EBA-04F1C27E1537@erlang.geek.nz> Hi all, I just updated my OTP install to today's master and ran into a really weird bug - running 'crypto:start()' in the first ~5s after starting erl would fail with the error: > Erlang R17A (erts-5.11) [source-236b48c] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.11 (abort with ^G) > 1> crypto:start(). > ** exception error: undefined function crypto:start/0 > 2> > =ERROR REPORT==== 9-Dec-2013::13:55:59 === > Unable to load crypto library. Failed with error: > "load, Library load-call unsuccessful." > OpenSSL might not be installed on this system. > > =ERROR REPORT==== 9-Dec-2013::13:55:59 === > The on_load function for module crypto returned {error, > {load, > "Library load-call unsuccessful."}} > 2> crypto:start(). > ok > 3> crypto:md5(term_to_binary(1)). > <<67,214,80,204,205,119,185,209,192,165,163,106,79,236,31, > 196>> If I did any of: calling crypto:start() a second time, or waiting a few seconds before calling it, or evaluating another shell command before crypto:start() , it would work just fine. This was particularly annoying with rebar, as rebar wants to start crypto at startup and this would continually fail. Backing out the commit '717cf073' fixed my problem. I'm running OS X 10.9, 'Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64' etc. Cheers, -- Geoff Cant From sverker.eriksson@REDACTED Tue Dec 10 16:23:12 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Tue, 10 Dec 2013 16:23:12 +0100 Subject: [erlang-bugs] Weird crypto:start() bug with 717cf073 / OTP-11408 In-Reply-To: <6036C8A6-92C4-45E0-8EBA-04F1C27E1537@erlang.geek.nz> References: <6036C8A6-92C4-45E0-8EBA-04F1C27E1537@erlang.geek.nz> Message-ID: <52A731E0.7020308@erix.ericsson.se> On 12/10/2013 12:51 AM, Geoff Cant wrote: > Hi all, I just updated my OTP install to today's master and ran into a really weird bug - running 'crypto:start()' in the first ~5s after starting erl would fail with the error: > >> Erlang R17A (erts-5.11) [source-236b48c] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V5.11 (abort with ^G) >> 1> crypto:start(). >> ** exception error: undefined function crypto:start/0 >> 2> >> =ERROR REPORT==== 9-Dec-2013::13:55:59 === >> Unable to load crypto library. Failed with error: >> "load, Library load-call unsuccessful." >> OpenSSL might not be installed on this system. >> >> =ERROR REPORT==== 9-Dec-2013::13:55:59 === >> The on_load function for module crypto returned {error, >> {load, >> "Library load-call unsuccessful."}} >> 2> crypto:start(). >> ok >> 3> crypto:md5(term_to_binary(1)). >> <<67,214,80,204,205,119,185,209,192,165,163,106,79,236,31, >> 196>> > > If I did any of: calling crypto:start() a second time, or waiting a few seconds before calling it, or evaluating another shell command before crypto:start() , it would work just fine. > > This was particularly annoying with rebar, as rebar wants to start crypto at startup and this would continually fail. > > Backing out the commit '717cf073' fixed my problem. I'm running OS X 10.9, 'Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64' etc. > > Cheers, > -- > Geoff Cant > > > I think this is fixed by 94576fd805c9a8 which has been merged to master now accessible at github. /Sverker, Erlang/OTP From zambal@REDACTED Thu Dec 12 15:00:25 2013 From: zambal@REDACTED (Vincent Siliakus) Date: Thu, 12 Dec 2013 15:00:25 +0100 Subject: [erlang-bugs] Possible bug in file:sendfile/5 Message-ID: Hi, It seems that file:sendfile/5 in some situations corrupts or unexpectedly closes the socket it uses. I stumbled up on this while using Elli, a small but flexible http server (https://github.com/knutin/elli). The issue manifests itself when some clients are making single requests (ie. they close the socket after receiving a response) in a short timespan, where the response is a file send back to the clients, using file:sendfile/5. Once in a while, after an acceptor has responded and tries to reuse the connection and calls gen_tcp:recv/3 again, instead of receiving {error, closed}, it receives {error, ebadf} I created a small example, that imitates Elli's tcp acceptor loop, without all the http parsing stuff. When running this example I can reliably reproduce this issue on two systems. System one is a dual core Mac Book Pro, running Ubuntu 13.10 and Erlang 16B03. System two is single core VMWare VM, running Ubuntu 12.04 LTS and Erlang 15B03. I tried different async-thread settings on both systems (also disabling async-threads altogether, by using +A 0), which doesn't seem to make a difference. I published the example as a gist at github, which can be found here: https://gist.github.com/zambal/7927631 In my example, sendfile:server/0 creates a listener, with {active, false} and spawns 10 processes as acceptors on that listening socket. sendfile:clients/0 spawns 50 clients that are all performing a single request, after which they close the connection. If you run the example and no {error, ebadf} manifests itself, you can uncomment the timer:sleep(100) call on line 34, as that seems to make it more likely that the error will popup. Note also that you can replace the sendfile call with an alternative implementation that uses file:read_file and gen_tcp:send, by changing the sendfile(Socket, Path) call with sendfile2 (Socket, Path) on line 32. Using the alternative implementation, I can not reproduce the issue and everything seems to work as expected. -vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Dec 12 17:35:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Dec 2013 17:35:53 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <5280ECDD.3020001@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> Message-ID: This patch breaks reverting of local implicit funs in R16B03. We have two ways of fixing this: - Making erl_syntax reverts local implicit funs? parts as concrete values. - Change the AST format in a backwards-incompatible way and use abstract values for local implicit funs too. My vote is on fixing erl_syntax right now for R16, and change the AST in R17 as we will have maps and named funs anyway in there. Sorry for the inconvenience. Richard, maybe we should write tests for syntax_tools? -- Anthony Ramine Le 11 nov. 2013 ? 15:42, Henrik Nord a ?crit : > Its moving forward as we speak. > > Thank you for your contribution! > > On 2013-11-01 12:29, Anthony Ramine wrote: >> Ping? This is still ? Status: Author ? in the Development page. >> > > -- > /Henrik Nord Erlang/OTP > From n.oxyde@REDACTED Fri Dec 13 00:22:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 00:22:03 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> Message-ID: <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Hello again, I?ve pushed the fix. It is just a partial revert of the previous commit on erl_syntax. Such a thing would have been avoided by basic tests. Or just double checking the documentation about the AST, I?m to blame for that. Should the AST be made consistent between local and remote implicit funs in R17A? I can write a patch for that. With proper tests and documentation. git fetch https://github.com/nox/otp.git fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch Regards, -- Anthony Ramine Le 12 d?c. 2013 ? 17:35, Anthony Ramine a ?crit : > This patch breaks reverting of local implicit funs in R16B03. > > We have two ways of fixing this: > > - Making erl_syntax reverts local implicit funs? parts as concrete values. > - Change the AST format in a backwards-incompatible way and use abstract values for local implicit funs too. > > My vote is on fixing erl_syntax right now for R16, and change the AST in R17 as we will have maps and named funs anyway in there. > > Sorry for the inconvenience. > > Richard, maybe we should write tests for syntax_tools? > > -- > Anthony Ramine > > Le 11 nov. 2013 ? 15:42, Henrik Nord a ?crit : > >> Its moving forward as we speak. >> >> Thank you for your contribution! >> >> On 2013-11-01 12:29, Anthony Ramine wrote: >>> Ping? This is still ? Status: Author ? in the Development page. >>> >> >> -- >> /Henrik Nord Erlang/OTP >> > From jose.valim@REDACTED Fri Dec 13 09:25:31 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 13 Dec 2013 08:25:31 +0000 Subject: [erlang-bugs] Wrong warning when dispatching to a literal tuple Message-ID: The following code: -module(foo). -compile(export_all). sample() -> ({ hello, 1 }):world(). Issues the following warning: foo.erl:4: Warning: invalid module and/or function name; this call will always fail Which is not true if there is a "hello" module defined. This issue has been reported here: http://stackoverflow.com/questions/20556472/elixir-protocols-in-erlang-a-strange-warning/20561973#20561973 Thanks! *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Dec 13 09:52:26 2013 From: henrik@REDACTED (Henrik Nord) Date: Fri, 13 Dec 2013 09:52:26 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Message-ID: <52AACACA.7000005@erlang.org> The patch, igor funs, was merged into maint 2013-11-29 https://github.com/erlang/otp/commit/40d21f3f803a336b3d3edf338ec71a67ea1f09b1 Also, Would you mind pressing the "pull request" button on github for your patches? We are still working on how to solve this in a good way, until then patches, discussions and reviews in email, code on github? And making it a pull request from the getgo ensures that it will go into our patch monitoring system saves us some manual labor Thanks! /Henrik On 2013-12-13 00:22, Anthony Ramine wrote: > Hello again, > > I?ve pushed the fix. It is just a partial revert of the previous commit on erl_syntax. Such a thing would have been avoided by basic tests. Or just double checking the documentation about the AST, I?m to blame for that. > > Should the AST be made consistent between local and remote implicit funs in R17A? I can write a patch for that. With proper tests and documentation. > > git fetch https://github.com/nox/otp.git fix-OTP-11506 > > https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 > https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch > > Regards, > -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Dec 13 10:16:55 2013 From: henrik@REDACTED (Henrik Nord) Date: Fri, 13 Dec 2013 10:16:55 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Message-ID: <52AAD087.6010407@erlang.org> Next release is R17pre sometime in Jan So, If this fix that Anthony sent : git fetchhttps://github.com/nox/otp.git fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch Fixes the problem, you might have to apply that yourself until we merge it into master. On 2013-12-13 10:05, David Welton wrote: > Hi guys, > > Since this code is out in the wild, and seems to cause some problems > (I noticed the problem when trying to work with Chicago Boss with > R16B03 and brought it to Anthony's attention), can you recommend a > good way to work around it until B04 comes out? > > Thank you, -- /Henrik Nord Erlang/OTP From jesper.louis.andersen@REDACTED Fri Dec 13 10:58:08 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 13 Dec 2013 10:58:08 +0100 Subject: [erlang-bugs] Wrong warning when dispatching to a literal tuple In-Reply-To: References: Message-ID: <3F5E658A-4331-44D2-8C91-9C5B644473BD@erlang-solutions.com> The compiler currently seem to understand rather few variants: a:b A:b a:B A:B where a,b are atoms and A,B are variables. Everything else is an invalid call and generates a warning. Which is correct Erlang, since tuple-funs is a hack in place to handle the parameterised module parse transform and other old stuff. Note the compiler still generates an `old_apply` in this case so it allows the code to ?work?, but it warns about the problematic form. fun (element(1, {hello, 1})):world/0 would probably work for generated code. It uses the more modern ?fun M:F/A? form. Jesper Louis Andersen Erlang Solutions Ltd., Copenhagen On 13 Dec 2013, at 09:25, Jos? Valim wrote: > The following code: > > -module(foo). > -compile(export_all). > > sample() -> ({ hello, 1 }):world(). > > Issues the following warning: > > foo.erl:4: Warning: invalid module and/or function name; this call will always fail > > Which is not true if there is a "hello" module defined. > This issue has been reported here: http://stackoverflow.com/questions/20556472/elixir-protocols-in-erlang-a-strange-warning/20561973#20561973 > > Thanks! > > Jos? Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From n.oxyde@REDACTED Fri Dec 13 11:08:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 11:08:51 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <52AACACA.7000005@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AACACA.7000005@erlang.org> Message-ID: I can reluctantly make a PR, but don?t expect me to notice when comments are posted, or to comment myself there. I prefer my mailbox which I can actually archive. -- Anthony Ramine Le 13 d?c. 2013 ? 09:52, Henrik Nord a ?crit : > Also, Would you mind pressing the "pull request" button on github for your patches? From n.oxyde@REDACTED Fri Dec 13 11:09:25 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 11:09:25 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <52AAD087.6010407@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: This means any project relying on erl_syntax won?t work with R16B03. In my opinion we need an R16B03-1. -- Anthony Ramine Le 13 d?c. 2013 ? 10:16, Henrik Nord a ?crit : > Fixes the problem, you might have to apply that yourself until we merge it into master. From essen@REDACTED Fri Dec 13 13:31:37 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 13 Dec 2013 13:31:37 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: <52AAFE29.4010808@ninenines.eu> This potentially breaks pretty much any project that manipulates AST, including many parse_transforms, other BEAM languages targetting the Erlang AST, tools that generate code, and of course everything that requires one of the above to work. This sounds serious enough to do a hotfix. Also sounds like test suites are really missing there, something should be done about it to make sure it doesn't happen again. On 12/13/2013 11:09 AM, Anthony Ramine wrote: > This means any project relying on erl_syntax won?t work with R16B03. In my opinion we need an R16B03-1. > -- Lo?c Hoguin http://ninenines.eu From n.oxyde@REDACTED Sat Dec 14 02:08:18 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Dec 2013 02:08:18 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <52AAFE29.4010808@ninenines.eu> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52AAFE29.4010808@ninenines.eu> Message-ID: <50A92E52-39CF-4199-BD43-5B6168745333@gmail.com> Hello, I?ve added a commit which smoke tests erl_syntax:revert/1. Henrik, please refetch. Regards, -- Anthony Ramine Le 13 d?c. 2013 ? 13:31, Lo?c Hoguin a ?crit : > This potentially breaks pretty much any project that manipulates AST, including many parse_transforms, other BEAM languages targetting the Erlang AST, tools that generate code, and of course everything that requires one of the above to work. This sounds serious enough to do a hotfix. > > Also sounds like test suites are really missing there, something should be done about it to make sure it doesn't happen again. > > On 12/13/2013 11:09 AM, Anthony Ramine wrote: >> This means any project relying on erl_syntax won?t work with R16B03. In my opinion we need an R16B03-1. >> > > -- > Lo?c Hoguin > http://ninenines.eu From serge@REDACTED Mon Dec 16 16:25:42 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 16 Dec 2013 10:25:42 -0500 Subject: [erlang-bugs] bug in erl_interface Message-ID: I believe there's a bug in the definition of ERL_MIN, ERL_MAX: *grep -n -A1 ERL_MAX lib/erl_interface*/src/legacy/erl_eterm.h 28:#define ERL_MAX_COUNT 0xffffff 29:#define ERL_MAX ((1 << 27)-1) 30-#define ERL_MIN -(1 << 27) The macros are used by lib/erl_interface/src/encode/encode_longlong.c: *grep -n -B3 -A5 ERL_MAX lib/erl_interface/src/encode/encode_longlong.c * 63- put8(s,ERL_SMALL_INTEGER_EXT); 64- put8(s,(p & 0xff)); 65- } 66: } else if ((p <= ERL_MAX) && (p >= ERL_MIN)) { 67- /* FIXME: Non optimal, could use (p <= LONG_MAX) && (p >= LONG_MIN) 68- and skip next case */ 69- if (!buf) s += 5; 70- else { 71- put8(s,ERL_INTEGER_EXT); It seems to me that these definitions are obsolete as the VM encodes integers up to (1 << 31)-1 as ERL_INTEGER_EXT (98), and only above that as ERL_SMALL_BIG (110): 1> term_to_binary(1 bsl 31 - 1). <<131,98,127,255,255,255>> 2> term_to_binary(1 bsl 31). <<131,110,4,0,0,0,0,128>> So the proper defines should be: *lib/erl_interface*/src/legacy/erl_eterm.h:29: #define ERL_MAX ((1 << *31*)-1) #define ERL_MIN -(1 << *31*) Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Mon Dec 16 17:39:16 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 16 Dec 2013 17:39:16 +0100 Subject: [erlang-bugs] bug in erl_interface In-Reply-To: References: Message-ID: <52AF2CB4.5070701@erlang.org> I don't stuff will break from this, so I wouldn't consider it a bug per se. For instance, 7> erlang:term_to_binary(1 bsl 29). <<131,98,32,0,0,0>> ok, but you could also define 1 bsl 29 = 536870912 as, <<131,110,4,0,0,0,0,32>> (SMALL_BIG) in the external format, so 9> erlang:binary_to_term(<<131,110,4,0,0,0,0,32>>). 536870912 The "proper" way to encode should probably be as you describe though but I think it correct external format encoded from ei .. erl_interface legacy, what a bundle of joy =) // Bj?rn-Egil On 2013-12-16 16:25, Serge Aleynikov wrote: > I believe there's a bug in the definition of ERL_MIN, ERL_MAX: > > *grep -n -A1 ERL_MAX lib/erl_interface*/src/legacy/erl_eterm.h > 28:#define ERL_MAX_COUNT 0xffffff > 29:#define ERL_MAX ((1 << 27)-1) > 30-#define ERL_MIN -(1 << 27) > > The macros are used by lib/erl_interface/src/encode/encode_longlong.c: > > *grep -n -B3 -A5 ERL_MAX lib/erl_interface/src/encode/encode_longlong.c * > 63- put8(s,ERL_SMALL_INTEGER_EXT); > 64- put8(s,(p & 0xff)); > 65- } > 66: } else if ((p <= ERL_MAX) && (p >= ERL_MIN)) { > 67- /* FIXME: Non optimal, could use (p <= LONG_MAX) && (p >= > LONG_MIN) > 68- and skip next case */ > 69- if (!buf) s += 5; > 70- else { > 71- put8(s,ERL_INTEGER_EXT); > > It seems to me that these definitions are obsolete as the VM encodes > integers up to (1 << 31)-1 as ERL_INTEGER_EXT (98), and only above > that as ERL_SMALL_BIG (110): > > 1> term_to_binary(1 bsl 31 - 1). > <<131,98,127,255,255,255>> > 2> term_to_binary(1 bsl 31). > <<131,110,4,0,0,0,0,128>> > > So the proper defines should be: > > *lib/erl_interface*/src/legacy/erl_eterm.h:29: > #define ERL_MAX ((1 << *_31_*)-1) > #define ERL_MIN -(1 << *_31_*) > > Serge > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Mon Dec 16 18:17:43 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 16 Dec 2013 12:17:43 -0500 Subject: [erlang-bugs] bug in erl_interface In-Reply-To: <52AF2CB4.5070701@erlang.org> References: <52AF2CB4.5070701@erlang.org> Message-ID: You are correct that this doesn't lead to erroneous behavior as the same integer can be encoded as SMALL_BIG and INTEGER_EXT, but it seems to me that the current inconsistency between VM encoding and ei/erl_interface should be normalized to follow the rules of "least astonishment". :-) On Mon, Dec 16, 2013 at 11:39 AM, Bj?rn-Egil Dahlberg wrote: > I don't stuff will break from this, so I wouldn't consider it a bug per > se. > > For instance, > 7> erlang:term_to_binary(1 bsl 29). > <<131,98,32,0,0,0>> > > ok, but you could also define 1 bsl 29 = 536870912 as, > <<131,110,4,0,0,0,0,32>> (SMALL_BIG) > in the external format, so > > 9> erlang:binary_to_term(<<131,110,4,0,0,0,0,32>>). > 536870912 > > The "proper" way to encode should probably be as you describe though but I > think it correct external format encoded from ei .. erl_interface legacy, > what a bundle of joy =) > > // Bj?rn-Egil > > On 2013-12-16 16:25, Serge Aleynikov wrote: > > I believe there's a bug in the definition of ERL_MIN, ERL_MAX: > > *grep -n -A1 ERL_MAX lib/erl_interface*/src/legacy/erl_eterm.h > 28:#define ERL_MAX_COUNT 0xffffff > 29:#define ERL_MAX ((1 << 27)-1) > 30-#define ERL_MIN -(1 << 27) > > The macros are used by lib/erl_interface/src/encode/encode_longlong.c: > > *grep -n -B3 -A5 ERL_MAX lib/erl_interface/src/encode/encode_longlong.c * > 63- put8(s,ERL_SMALL_INTEGER_EXT); > 64- put8(s,(p & 0xff)); > 65- } > 66: } else if ((p <= ERL_MAX) && (p >= ERL_MIN)) { > 67- /* FIXME: Non optimal, could use (p <= LONG_MAX) && (p >= LONG_MIN) > 68- and skip next case */ > 69- if (!buf) s += 5; > 70- else { > 71- put8(s,ERL_INTEGER_EXT); > > It seems to me that these definitions are obsolete as the VM encodes > integers up to (1 << 31)-1 as ERL_INTEGER_EXT (98), and only above that as > ERL_SMALL_BIG (110): > > 1> term_to_binary(1 bsl 31 - 1). > <<131,98,127,255,255,255>> > 2> term_to_binary(1 bsl 31). > <<131,110,4,0,0,0,0,128>> > > So the proper defines should be: > > *lib/erl_interface*/src/legacy/erl_eterm.h:29: > #define ERL_MAX ((1 << *31*)-1) > #define ERL_MIN -(1 << *31*) > > Serge > > > > _______________________________________________ > erlang-bugs mailing listerlang-bugs@REDACTED://erlang.org/mailman/listinfo/erlang-bugs > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Mon Dec 16 23:11:04 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 16 Dec 2013 23:11:04 +0100 Subject: [erlang-bugs] R16B03 : toolbar still present Message-ID: <52AF7A78.60902@wanadoo.fr> Hi, I note that toolbar is still present while documentation says "The Toolbar application is deprecated and will be removed in R16. " moreover toolbar:start(). never returns :>( regards Eric From eric.pailleau@REDACTED Mon Dec 16 23:14:51 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Mon, 16 Dec 2013 23:14:51 +0100 Subject: [erlang-bugs] R16B03 : toolbar still present In-Reply-To: <52AF7A78.60902@wanadoo.fr> References: <52AF7A78.60902@wanadoo.fr> Message-ID: <52AF7B5B.4050208@wanadoo.fr> > moreover toolbar:start(). never returns :>( Sorry, I did not wait enough time, it logically timeout : ** exception exit: {startup_timeout,toolbar} in function toolbar:init_ok/1 (toolbar.erl, line 84) From anton.ryabkov@REDACTED Tue Dec 17 04:33:59 2013 From: anton.ryabkov@REDACTED (Anton Ryabkov) Date: Tue, 17 Dec 2013 10:33:59 +0700 Subject: [erlang-bugs] ssh_cli error during start_shell Message-ID: Hello, on Erlang R16B03 I've found that ssh_cli crushed with function_clause, when I trying connected by ssh to my ssh daemon. Error: ... ** {function_clause,[{proplists,get_value, [user,{ok,[]},undefined], [{file,"proplists.erl"},{line,225}]}, {ssh_cli,start_shell,2,[{file,"ssh_cli.erl"},{line,457}]}, {ssh_cli,handle_ssh_msg,2, [{file,"ssh_cli.erl"},{line,107}]}, {ssh_channel,handle_info,2, [{file,"ssh_channel.erl"},{line,241}]}, {gen_server,handle_msg,5, [{file,"gen_server.erl"},{line,604}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]} Note: all error in the file error. Steps to reproduce: 1. compile ssh_bug.erl 2. ssh_bug:test(). 3. connect by ssh: ssh localhost -p9876 4. look at erlang concole for error. The reason of the bug is getting ConnectionInfo in the ssh_cli. Instead of use ssh_connection_handler:connection_info method to get ConnectionInfo used ssh_connection_handler:info. Patch for current bug: 452c452 < ConnectionInfo = ssh_connection_handler:info(ConnectionHandler, --- > ConnectionInfo = ssh_connection_handler:connection_info(ConnectionHandler, 456c456 < {ok, User} = --- > User = 462c462 < [{_, PeerAddr}] = --- > {_, PeerAddr} = 480c480 < ConnectionInfo = ssh_connection_handler:info(ConnectionHandler, --- > ConnectionInfo = ssh_connection_handler:connection_info(ConnectionHandler, 482c482 < {ok, User} = --- > User = 491c491 < [{_, PeerAddr}] = --- > {_, PeerAddr} = Sample, error and patch in the attach. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_bug_3_0.tar.gz Type: application/x-gzip Size: 3257 bytes Desc: not available URL: From essen@REDACTED Wed Dec 18 12:12:51 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Dec 2013 12:12:51 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: <52B18333.8090807@ninenines.eu> On 12/18/2013 12:05 PM, David Welton wrote: > What is necessary is some code that will do > > case erlang:system_info(otp_release) of > "R16B03" -> > ... mangle the AST in such a way to not make the parse transform barf...; > _ -> ok > end. Don't do that, this doesn't mean that the syntax_tools application will actually be the one that shipped with R16B03. Check the application version instead: application:get_key(syntax_tools, vsn). (Note that this is only available after the application is loaded.) -- Lo?c Hoguin http://ninenines.eu From edwardt.tril@REDACTED Thu Dec 19 00:09:58 2013 From: edwardt.tril@REDACTED (What Name) Date: Wed, 18 Dec 2013 15:09:58 -0800 Subject: [erlang-bugs] Erlang otpR16B03 will not compile on centos 6.4 64 bit Message-ID: Compilation under CEntos 6.x has been not goiing well since R16 is released, since a lot cof companies are using CEntos as production and not ubuntu. Can more resource be spent to make sure it works? Step: autoconf, then ru configure configure:5440: error: /opt/otp-OTP_R16B03/erts/autoconf/configure failed for erts. ./configure --prefix=/opt/erlangR16B03 --enable-threads --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp --disable-hipe --enable-native-libs --enable-shared-zlib --enable-m64-build --without-dynamic-trace --with-ssl --disable-vm-probes --without-javac --enable-megaco_reentrant_flex_scanner Full trace: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.63. Invocation command line was $ ./configure --prefix=/opt/erlangR16B03 --enable-threads --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp --disable-hipe --enable-native-libs --enable-shared-zlib --enable-m64-build --without-dynamic-trace --with-ssl --disable-vm-probes --without-javac --enable-megaco_reentrant_flex_scanner ## --------- ## ## Platform. ## ## --------- ## hostname = chat64.ejabberddev.localdomain uname -m = x86_64 uname -r = 2.6.32-358.23.2.el6.x86_64 uname -s = Linux uname -v = #1 SMP Wed Oct 16 18:37:12 UTC 2013 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/lib64/qt-3.3/bin PATH: /usr/local/sbin PATH: /usr/sbin PATH: /sbin PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /opt/nodebin/bin PATH: /opt/jdk1.7.0_25/bin PATH: /opt/erlangR16B02/lib/erlang/bin PATH: /root/bin PATH: /opt/nodebin/bin PATH: /opt/jdk1.7.0_25/bin PATH: /opt/erlangR16B02/lib/erlang/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2110: checking build system type configure:2128: result: x86_64-unknown-linux-gnu configure:2150: checking host system type configure:2165: result: x86_64-unknown-linux-gnu configure:2270: checking for gcc configure:2286: found /usr/bin/gcc configure:2297: result: gcc configure:2529: checking for C compiler version configure:2537: gcc --version >&5 gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2541: $? = 0 configure:2548: gcc -v >&5 Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) configure:2552: $? = 0 configure:2559: gcc -V >&5 gcc: '-V' option must have argument configure:2563: $? = 1 configure:2586: checking for C compiler default output file name configure:2608: gcc conftest.c >&5 configure:2612: $? = 0 configure:2650: result: a.out configure:2669: checking whether the C compiler works configure:2679: ./a.out configure:2683: $? = 0 configure:2702: result: yes configure:2709: checking whether we are cross compiling configure:2711: result: no configure:2714: checking for suffix of executables configure:2721: gcc -o conftest conftest.c >&5 configure:2725: $? = 0 configure:2751: result: configure:2757: checking for suffix of object files configure:2783: gcc -c conftest.c >&5 configure:2787: $? = 0 configure:2812: result: o configure:2816: checking whether we are using the GNU C compiler configure:2845: gcc -c conftest.c >&5 configure:2852: $? = 0 configure:2869: result: yes configure:2878: checking whether gcc accepts -g configure:2908: gcc -c -g conftest.c >&5 configure:2915: $? = 0 configure:3016: result: yes configure:3033: checking for gcc option to accept ISO C89 configure:3107: gcc -c -g -O2 conftest.c >&5 configure:3114: $? = 0 configure:3137: result: none needed configure:3213: checking for g++ configure:3229: found /usr/bin/g++ configure:3240: result: g++ configure:3267: checking for C++ compiler version configure:3275: g++ --version >&5 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3279: $? = 0 configure:3286: g++ -v >&5 Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) configure:3290: $? = 0 configure:3297: g++ -V >&5 g++: '-V' option must have argument configure:3301: $? = 1 configure:3304: checking whether we are using the GNU C++ compiler configure:3333: g++ -c conftest.cpp >&5 configure:3340: $? = 0 configure:3357: result: yes configure:3366: checking whether g++ accepts -g configure:3396: g++ -c -g conftest.cpp >&5 configure:3403: $? = 0 configure:3504: result: yes configure:3570: checking for ld configure:3586: found /usr/bin/ld configure:3597: result: ld configure:3623: checking for GNU make configure:3661: result: yes (make) configure:3681: checking for a BSD-compatible install configure:3749: result: /usr/bin/install -c configure:3767: checking whether ln -s works configure:3771: result: yes configure:3821: checking for ranlib configure:3837: found /usr/bin/ranlib configure:3848: result: ranlib configure:3874: checking ERTS version configure:3877: result: 5.10.4 configure:3881: checking OTP release configure:3884: result: R16B03 configure:4281: creating ./config.status ## ---------------------- ## ## Running config.status. ## ## ---------------------- ## This file was extended by config.status, which was generated by GNU Autoconf 2.63. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ ./config.status on chat64.ejabberddev.localdomain config.status:698: creating Makefile config.status:845: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting config.status:698: creating make/output.mk config.status:698: creating make/emd2exml configure:5332: === configuring in lib (/opt/otp-OTP_R16B03/lib) configure:5421: WARNING: no configuration information is in lib configure:5332: === configuring in erts (/opt/otp-OTP_R16B03/erts) configure:5435: running /bin/sh /opt/otp-OTP_R16B03/erts/autoconf/configure --disable-option-checking '--prefix=/opt/erlangR16B03' '--enable-threads' '--enable-smp-support' '--with-termcap' '--enable-kernel-poll' '--enable-sctp' '--disable-hipe' '--enable-native-libs' '--enable-shared-zlib' '--enable-m64-build' '--without-dynamic-trace' '--with-ssl' '--disable-vm-probes' '--without-javac' '--enable-megaco_reentrant_flex_scanner' --cache-file=/dev/null --srcdir=/opt/otp-OTP_R16B03/erts configure:5440: error: /opt/otp-OTP_R16B03/erts/autoconf/configure failed for erts ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_c_compiler_gnu=yes ac_cv_cxx_compiler_gnu=yes ac_cv_env_AR_set= ac_cv_env_AR_value= ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CFLAG_RUNTIME_LIBRARY_PATH_set= ac_cv_env_CFLAG_RUNTIME_LIBRARY_PATH_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_DED_LDFLAGS_set= ac_cv_env_DED_LDFLAGS_value= ac_cv_env_DED_LD_FLAG_RUNTIME_LIBRARY_PATH_set= ac_cv_env_DED_LD_FLAG_RUNTIME_LIBRARY_PATH_value= ac_cv_env_DED_LD_set= ac_cv_env_DED_LD_value= ac_cv_env_ERL_TOP_set= ac_cv_env_ERL_TOP_value= ac_cv_env_GETCONF_set= ac_cv_env_GETCONF_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_LD_set= ac_cv_env_LD_value= ac_cv_env_LFS_CFLAGS_set= ac_cv_env_LFS_CFLAGS_value= ac_cv_env_LFS_LDFLAGS_set= ac_cv_env_LFS_LDFLAGS_value= ac_cv_env_LFS_LIBS_set= ac_cv_env_LFS_LIBS_value= ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_RANLIB_set= ac_cv_env_RANLIB_value= ac_cv_env_STATIC_CFLAGS_set= ac_cv_env_STATIC_CFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_erl_xcomp_after_morecore_hook_set= ac_cv_env_erl_xcomp_after_morecore_hook_value= ac_cv_env_erl_xcomp_bigendian_set= ac_cv_env_erl_xcomp_bigendian_value= ac_cv_env_erl_xcomp_clock_gettime_cpu_time_set= ac_cv_env_erl_xcomp_clock_gettime_cpu_time_value= ac_cv_env_erl_xcomp_dlsym_brk_wrappers_set= ac_cv_env_erl_xcomp_dlsym_brk_wrappers_value= ac_cv_env_erl_xcomp_double_middle_endian_set= ac_cv_env_erl_xcomp_double_middle_endian_value= ac_cv_env_erl_xcomp_getaddrinfo_set= ac_cv_env_erl_xcomp_getaddrinfo_value= ac_cv_env_erl_xcomp_gethrvtime_procfs_ioctl_set= ac_cv_env_erl_xcomp_gethrvtime_procfs_ioctl_value= ac_cv_env_erl_xcomp_isysroot_set= ac_cv_env_erl_xcomp_isysroot_value= ac_cv_env_erl_xcomp_kqueue_set= ac_cv_env_erl_xcomp_kqueue_value= ac_cv_env_erl_xcomp_linux_clock_gettime_correction_set= ac_cv_env_erl_xcomp_linux_clock_gettime_correction_value= ac_cv_env_erl_xcomp_linux_nptl_set= ac_cv_env_erl_xcomp_linux_nptl_value= ac_cv_env_erl_xcomp_linux_usable_sigaltstack_set= ac_cv_env_erl_xcomp_linux_usable_sigaltstack_value= ac_cv_env_erl_xcomp_linux_usable_sigusrx_set= ac_cv_env_erl_xcomp_linux_usable_sigusrx_value= ac_cv_env_erl_xcomp_poll_set= ac_cv_env_erl_xcomp_poll_value= ac_cv_env_erl_xcomp_putenv_copy_set= ac_cv_env_erl_xcomp_putenv_copy_value= ac_cv_env_erl_xcomp_reliable_fpe_set= ac_cv_env_erl_xcomp_reliable_fpe_value= ac_cv_env_erl_xcomp_sysroot_set= ac_cv_env_erl_xcomp_sysroot_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_objext=o ac_cv_path_install='/usr/bin/install -c' ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_CXX=g++ ac_cv_prog_ac_ct_LD=ld ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_cc_c89= ac_cv_prog_cc_g=yes ac_cv_prog_cxx_g=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## AR='' BOOTSTRAP_ONLY='no' CC='gcc' CFLAGS='-m64 -g -O2' CFLAG_RUNTIME_LIBRARY_PATH='' CPP='' CPPFLAGS='' CROSS_COMPILING='no' CXX='g++' CXXFLAGS='-g -O2' DED_LD='' DED_LDFLAGS='' DED_LD_FLAG_RUNTIME_LIBRARY_PATH='' DEFAULT_VERBOSITY='1' DEFS='-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"' ECHO_C='' ECHO_N='-n' ECHO_T='' ERL_TOP='/opt/otp-OTP_R16B03' ERTS_VSN='5.10.4' EXEEXT='' GETCONF='' INSTALL_DATA='${INSTALL} -m 644' INSTALL_PROGRAM='${INSTALL}' INSTALL_SCRIPT='${INSTALL}' LD='ld' LDFLAGS='-m64 ' LFS_CFLAGS='' LFS_LDFLAGS='' LFS_LIBS='' LIBOBJS='' LIBS='' LN_S='ln -s' LTLIBOBJS='' MAKE_PROG='make' NATIVE_LIBS_ENABLED='' OBJEXT='o' OTP_REL='R16B03' PACKAGE_BUGREPORT='' PACKAGE_NAME='' PACKAGE_STRING='' PACKAGE_TARNAME='' PACKAGE_VERSION='' PATH_SEPARATOR=':' RANLIB='ranlib' SHELL='/bin/sh' STATIC_CFLAGS='' TARGET='x86_64-unknown-linux-gnu' ac_ct_CC='gcc' ac_ct_CXX='g++' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE}' dvidir='${docdir}' erl_xcomp_after_morecore_hook='' erl_xcomp_bigendian='' erl_xcomp_clock_gettime_cpu_time='' erl_xcomp_dlsym_brk_wrappers='' erl_xcomp_double_middle_endian='' erl_xcomp_getaddrinfo='' erl_xcomp_gethrvtime_procfs_ioctl='' erl_xcomp_isysroot='' erl_xcomp_kqueue='' erl_xcomp_linux_clock_gettime_correction='' erl_xcomp_linux_nptl='' erl_xcomp_linux_usable_sigaltstack='' erl_xcomp_linux_usable_sigusrx='' erl_xcomp_poll='' erl_xcomp_putenv_copy='' erl_xcomp_reliable_fpe='' erl_xcomp_sysroot='' exec_prefix='${prefix}' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='x86_64' host_os='linux-gnu' host_vendor='unknown' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/opt/erlangR16B03' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' subdirs=' lib erts' sysconfdir='${prefix}/etc' target_alias='' configure: exit 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostiamalikov@REDACTED Thu Dec 19 05:47:32 2013 From: kostiamalikov@REDACTED (Constantin Malikov) Date: Thu, 19 Dec 2013 11:47:32 +0700 Subject: [erlang-bugs] invalid processing flag '-name' Message-ID: Hello , friends. I want to tell you about a bug in Erlang: I have a trouble with using flag '-name' when startup 'erl'. I attached simple sample, where you can see this problem. In shell input: _____________________________________________________ user@REDACTED:~$ erl -name a@REDACTED -setcookie test (a@REDACTED)> _____________________________________________________ where 'a' ? nodename and 'alf' ? hostname In other shell input: _____________________________________________________ user@REDACTED:~$ erl -sname b@REDACTED -setcookie test (b@REDACTED)> _____________________________________________________ And iput : _____________________________________________________ (b@REDACTED)>net_adm:ping(a@REDACTED). pong _____________________________________________________ You will see pong, but you runs 'erl' with different flag '-name' and '-sname'. How can i see, in the net_kernel.erl module, invalid processing flag 'longname' when hi include '@hostname' Tested by Erlang 16B03, kernel-2.16.4 I can offer the option of a patch that fixes this problem. The person who is responsible for supporting ssh has the discretion to take it as it is, or can make own fix. ________________________________________________________________ Left base folder: /home/konstantin/erlang/otp_src_R16B03 Right base folder: /home/konstantin/erlang/otp_src_R16B03_patch --- lib/kernel/src/net_kernel.erl 2013-12-19 11:02:00.000000000 +++ lib/kernel/src/net_kernel.erl 2013-12-19 10:42:17.000000000 @@ -1229,13 +1229,23 @@ create_hostpart(Name, LongOrShortNames) -> {Head,Host} = lists:splitwith(fun($@)->false;(_)->true end, atom_to_list(Name)), Host1 = case {Host,LongOrShortNames} of {[$@,_|_],longnames} -> - {ok,Host}; + case lists:member($., Host) of + true -> + {ok, Host}; + false -> + case {inet_db:res_option(domain)} of + {D} when is_list(D), length(D) > 0 -> + {ok, Host ++ "." ++ D}; + _ -> + {error, long} + end + end; {[$@,_|_],shortnames} -> case lists:member($.,Host) of true -> {error,short}; _ -> {ok,Host} end; {_,shortnames} -> ________________________________________________________________ With best regards, Malikov Constantin, software developer, Eltex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Dec 19 10:12:20 2013 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 19 Dec 2013 10:12:20 +0100 Subject: [erlang-bugs] Erlang otpR16B03 will not compile on centos 6.4 64 bit In-Reply-To: References: Message-ID: <52B2B874.7040808@erlang.org> Hello, The interesting part is in erts/config.log, could you please send that as well? Lukas On 19/12/13 00:09, What Name wrote: > Compilation under CEntos 6.x has been not goiing well since R16 is > released, since a lot cof companies are using CEntos as production and > not ubuntu. Can more resource be spent to make sure it works? > > Step: autoconf, then ru configure > > configure:5440: error: /opt/otp-OTP_R16B03/erts/autoconf/configure > failed for erts. > > ./configure --prefix=/opt/erlangR16B03 --enable-threads > --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp > --disable-hipe --enable-native-libs --enable-shared-zlib > --enable-m64-build --without-dynamic-trace --with-ssl > --disable-vm-probes --without-javac --enable-megaco_reentrant_flex_scanner > > Full trace: > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.63. Invocation command line was > > $ ./configure --prefix=/opt/erlangR16B03 --enable-threads > --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp > --disable-hipe --enable-native-libs --enable-shared-zlib > --enable-m64-build --without-dynamic-trace --with-ssl > --disable-vm-probes --without-javac --enable-megaco_reentrant_flex_scanner > > ## --------- ## > ## Platform. ## > ## --------- ## > > hostname = chat64.ejabberddev.localdomain > uname -m = x86_64 > uname -r = 2.6.32-358.23.2.el6.x86_64 > uname -s = Linux > uname -v = #1 SMP Wed Oct 16 18:37:12 UTC 2013 > > /usr/bin/uname -p = unknown > /bin/uname -X = unknown > > /bin/arch = x86_64 > /usr/bin/arch -k = unknown > /usr/convex/getsysinfo = unknown > /usr/bin/hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > PATH: /usr/lib64/qt-3.3/bin > PATH: /usr/local/sbin > PATH: /usr/sbin > PATH: /sbin > PATH: /usr/local/bin > PATH: /usr/bin > PATH: /bin > PATH: /opt/nodebin/bin > PATH: /opt/jdk1.7.0_25/bin > PATH: /opt/erlangR16B02/lib/erlang/bin > PATH: /root/bin > PATH: /opt/nodebin/bin > PATH: /opt/jdk1.7.0_25/bin > PATH: /opt/erlangR16B02/lib/erlang/bin > > > ## ----------- ## > ## Core tests. ## > ## ----------- ## > > configure:2110: checking build system type > configure:2128: result: x86_64-unknown-linux-gnu > configure:2150: checking host system type > configure:2165: result: x86_64-unknown-linux-gnu > configure:2270: checking for gcc > configure:2286: found /usr/bin/gcc > configure:2297: result: gcc > configure:2529: checking for C compiler version > configure:2537: gcc --version >&5 > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > configure:2541: $? = 0 > configure:2548: gcc -v >&5 > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap > --enable-shared --enable-threads=posix --enable-checking=release > --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > --enable-libgcj-multifile --enable-java-maintainer-mode > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic > --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > configure:2552: $? = 0 > configure:2559: gcc -V >&5 > gcc: '-V' option must have argument > configure:2563: $? = 1 > configure:2586: checking for C compiler default output file name > configure:2608: gcc conftest.c >&5 > configure:2612: $? = 0 > configure:2650: result: a.out > configure:2669: checking whether the C compiler works > configure:2679: ./a.out > configure:2683: $? = 0 > configure:2702: result: yes > configure:2709: checking whether we are cross compiling > configure:2711: result: no > configure:2714: checking for suffix of executables > configure:2721: gcc -o conftest conftest.c >&5 > configure:2725: $? = 0 > configure:2751: result: > configure:2757: checking for suffix of object files > configure:2783: gcc -c conftest.c >&5 > configure:2787: $? = 0 > configure:2812: result: o > configure:2816: checking whether we are using the GNU C compiler > configure:2845: gcc -c conftest.c >&5 > configure:2852: $? = 0 > configure:2869: result: yes > configure:2878: checking whether gcc accepts -g > configure:2908: gcc -c -g conftest.c >&5 > configure:2915: $? = 0 > configure:3016: result: yes > configure:3033: checking for gcc option to accept ISO C89 > configure:3107: gcc -c -g -O2 conftest.c >&5 > configure:3114: $? = 0 > configure:3137: result: none needed > configure:3213: checking for g++ > configure:3229: found /usr/bin/g++ > configure:3240: result: g++ > configure:3267: checking for C++ compiler version > configure:3275: g++ --version >&5 > g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > configure:3279: $? = 0 > configure:3286: g++ -v >&5 > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap > --enable-shared --enable-threads=posix --enable-checking=release > --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > --enable-libgcj-multifile --enable-java-maintainer-mode > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic > --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > configure:3290: $? = 0 > configure:3297: g++ -V >&5 > g++: '-V' option must have argument > configure:3301: $? = 1 > configure:3304: checking whether we are using the GNU C++ compiler > configure:3333: g++ -c conftest.cpp >&5 > configure:3340: $? = 0 > configure:3357: result: yes > configure:3366: checking whether g++ accepts -g > configure:3396: g++ -c -g conftest.cpp >&5 > configure:3403: $? = 0 > configure:3504: result: yes > configure:3570: checking for ld > configure:3586: found /usr/bin/ld > configure:3597: result: ld > configure:3623: checking for GNU make > configure:3661: result: yes (make) > configure:3681: checking for a BSD-compatible install > configure:3749: result: /usr/bin/install -c > configure:3767: checking whether ln -s works > configure:3771: result: yes > configure:3821: checking for ranlib > configure:3837: found /usr/bin/ranlib > configure:3848: result: ranlib > configure:3874: checking ERTS version > configure:3877: result: 5.10.4 > configure:3881: checking OTP release > configure:3884: result: R16B03 > configure:4281: creating ./config.status > > ## ---------------------- ## > ## Running config.status. ## > ## ---------------------- ## > > This file was extended by config.status, which was > generated by GNU Autoconf 2.63. Invocation command line was > > CONFIG_FILES = > CONFIG_HEADERS = > CONFIG_LINKS = > CONFIG_COMMANDS = > $ ./config.status > > on chat64.ejabberddev.localdomain > > config.status:698: creating Makefile > config.status:845: WARNING: 'Makefile.in' seems to ignore the > --datarootdir setting > config.status:698: creating make/output.mk > config.status:698: creating make/emd2exml > configure:5332: === configuring in lib (/opt/otp-OTP_R16B03/lib) > configure:5421: WARNING: no configuration information is in lib > configure:5332: === configuring in erts (/opt/otp-OTP_R16B03/erts) > configure:5435: running /bin/sh > /opt/otp-OTP_R16B03/erts/autoconf/configure --disable-option-checking > '--prefix=/opt/erlangR16B03' '--enable-threads' '--enable-smp-support' > '--with-termcap' '--enable-kernel-poll' '--enable-sctp' > '--disable-hipe' '--enable-native-libs' '--enable-shared-zlib' > '--enable-m64-build' '--without-dynamic-trace' '--with-ssl' > '--disable-vm-probes' '--without-javac' > '--enable-megaco_reentrant_flex_scanner' --cache-file=/dev/null > --srcdir=/opt/otp-OTP_R16B03/erts > configure:5440: error: /opt/otp-OTP_R16B03/erts/autoconf/configure > failed for erts > > ## ---------------- ## > ## Cache variables. ## > ## ---------------- ## > > ac_cv_build=x86_64-unknown-linux-gnu > ac_cv_c_compiler_gnu=yes > ac_cv_cxx_compiler_gnu=yes > ac_cv_env_AR_set= > ac_cv_env_AR_value= > ac_cv_env_CCC_set= > ac_cv_env_CCC_value= > ac_cv_env_CC_set= > ac_cv_env_CC_value= > ac_cv_env_CFLAGS_set= > ac_cv_env_CFLAGS_value= > ac_cv_env_CFLAG_RUNTIME_LIBRARY_PATH_set= > ac_cv_env_CFLAG_RUNTIME_LIBRARY_PATH_value= > ac_cv_env_CPPFLAGS_set= > ac_cv_env_CPPFLAGS_value= > ac_cv_env_CPP_set= > ac_cv_env_CPP_value= > ac_cv_env_CXXFLAGS_set= > ac_cv_env_CXXFLAGS_value= > ac_cv_env_CXX_set= > ac_cv_env_CXX_value= > ac_cv_env_DED_LDFLAGS_set= > ac_cv_env_DED_LDFLAGS_value= > ac_cv_env_DED_LD_FLAG_RUNTIME_LIBRARY_PATH_set= > ac_cv_env_DED_LD_FLAG_RUNTIME_LIBRARY_PATH_value= > ac_cv_env_DED_LD_set= > ac_cv_env_DED_LD_value= > ac_cv_env_ERL_TOP_set= > ac_cv_env_ERL_TOP_value= > ac_cv_env_GETCONF_set= > ac_cv_env_GETCONF_value= > ac_cv_env_LDFLAGS_set= > ac_cv_env_LDFLAGS_value= > ac_cv_env_LD_set= > ac_cv_env_LD_value= > ac_cv_env_LFS_CFLAGS_set= > ac_cv_env_LFS_CFLAGS_value= > ac_cv_env_LFS_LDFLAGS_set= > ac_cv_env_LFS_LDFLAGS_value= > ac_cv_env_LFS_LIBS_set= > ac_cv_env_LFS_LIBS_value= > ac_cv_env_LIBS_set= > ac_cv_env_LIBS_value= > ac_cv_env_RANLIB_set= > ac_cv_env_RANLIB_value= > ac_cv_env_STATIC_CFLAGS_set= > ac_cv_env_STATIC_CFLAGS_value= > ac_cv_env_build_alias_set= > ac_cv_env_build_alias_value= > ac_cv_env_erl_xcomp_after_morecore_hook_set= > ac_cv_env_erl_xcomp_after_morecore_hook_value= > ac_cv_env_erl_xcomp_bigendian_set= > ac_cv_env_erl_xcomp_bigendian_value= > ac_cv_env_erl_xcomp_clock_gettime_cpu_time_set= > ac_cv_env_erl_xcomp_clock_gettime_cpu_time_value= > ac_cv_env_erl_xcomp_dlsym_brk_wrappers_set= > ac_cv_env_erl_xcomp_dlsym_brk_wrappers_value= > ac_cv_env_erl_xcomp_double_middle_endian_set= > ac_cv_env_erl_xcomp_double_middle_endian_value= > ac_cv_env_erl_xcomp_getaddrinfo_set= > ac_cv_env_erl_xcomp_getaddrinfo_value= > ac_cv_env_erl_xcomp_gethrvtime_procfs_ioctl_set= > ac_cv_env_erl_xcomp_gethrvtime_procfs_ioctl_value= > ac_cv_env_erl_xcomp_isysroot_set= > ac_cv_env_erl_xcomp_isysroot_value= > ac_cv_env_erl_xcomp_kqueue_set= > ac_cv_env_erl_xcomp_kqueue_value= > ac_cv_env_erl_xcomp_linux_clock_gettime_correction_set= > ac_cv_env_erl_xcomp_linux_clock_gettime_correction_value= > ac_cv_env_erl_xcomp_linux_nptl_set= > ac_cv_env_erl_xcomp_linux_nptl_value= > ac_cv_env_erl_xcomp_linux_usable_sigaltstack_set= > ac_cv_env_erl_xcomp_linux_usable_sigaltstack_value= > ac_cv_env_erl_xcomp_linux_usable_sigusrx_set= > ac_cv_env_erl_xcomp_linux_usable_sigusrx_value= > ac_cv_env_erl_xcomp_poll_set= > ac_cv_env_erl_xcomp_poll_value= > ac_cv_env_erl_xcomp_putenv_copy_set= > ac_cv_env_erl_xcomp_putenv_copy_value= > ac_cv_env_erl_xcomp_reliable_fpe_set= > ac_cv_env_erl_xcomp_reliable_fpe_value= > ac_cv_env_erl_xcomp_sysroot_set= > ac_cv_env_erl_xcomp_sysroot_value= > ac_cv_env_host_alias_set= > ac_cv_env_host_alias_value= > ac_cv_env_target_alias_set= > ac_cv_env_target_alias_value= > ac_cv_host=x86_64-unknown-linux-gnu > ac_cv_objext=o > ac_cv_path_install='/usr/bin/install -c' > ac_cv_prog_ac_ct_CC=gcc > ac_cv_prog_ac_ct_CXX=g++ > ac_cv_prog_ac_ct_LD=ld > ac_cv_prog_ac_ct_RANLIB=ranlib > ac_cv_prog_cc_c89= > ac_cv_prog_cc_g=yes > ac_cv_prog_cxx_g=yes > > ## ----------------- ## > ## Output variables. ## > ## ----------------- ## > > AR='' > BOOTSTRAP_ONLY='no' > CC='gcc' > CFLAGS='-m64 -g -O2' > CFLAG_RUNTIME_LIBRARY_PATH='' > CPP='' > CPPFLAGS='' > CROSS_COMPILING='no' > CXX='g++' > CXXFLAGS='-g -O2' > DED_LD='' > DED_LDFLAGS='' > DED_LD_FLAG_RUNTIME_LIBRARY_PATH='' > DEFAULT_VERBOSITY='1' > DEFS='-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" > -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"' > ECHO_C='' > ECHO_N='-n' > ECHO_T='' > ERL_TOP='/opt/otp-OTP_R16B03' > ERTS_VSN='5.10.4' > EXEEXT='' > GETCONF='' > INSTALL_DATA='${INSTALL} -m 644' > INSTALL_PROGRAM='${INSTALL}' > INSTALL_SCRIPT='${INSTALL}' > LD='ld' > LDFLAGS='-m64 ' > LFS_CFLAGS='' > LFS_LDFLAGS='' > LFS_LIBS='' > LIBOBJS='' > LIBS='' > LN_S='ln -s' > LTLIBOBJS='' > MAKE_PROG='make' > NATIVE_LIBS_ENABLED='' > OBJEXT='o' > OTP_REL='R16B03' > PACKAGE_BUGREPORT='' > PACKAGE_NAME='' > PACKAGE_STRING='' > PACKAGE_TARNAME='' > PACKAGE_VERSION='' > PATH_SEPARATOR=':' > RANLIB='ranlib' > SHELL='/bin/sh' > STATIC_CFLAGS='' > TARGET='x86_64-unknown-linux-gnu' > ac_ct_CC='gcc' > ac_ct_CXX='g++' > bindir='${exec_prefix}/bin' > build='x86_64-unknown-linux-gnu' > build_alias='' > build_cpu='x86_64' > build_os='linux-gnu' > build_vendor='unknown' > datadir='${datarootdir}' > datarootdir='${prefix}/share' > docdir='${datarootdir}/doc/${PACKAGE}' > dvidir='${docdir}' > erl_xcomp_after_morecore_hook='' > erl_xcomp_bigendian='' > erl_xcomp_clock_gettime_cpu_time='' > erl_xcomp_dlsym_brk_wrappers='' > erl_xcomp_double_middle_endian='' > erl_xcomp_getaddrinfo='' > erl_xcomp_gethrvtime_procfs_ioctl='' > erl_xcomp_isysroot='' > erl_xcomp_kqueue='' > erl_xcomp_linux_clock_gettime_correction='' > erl_xcomp_linux_nptl='' > erl_xcomp_linux_usable_sigaltstack='' > erl_xcomp_linux_usable_sigusrx='' > erl_xcomp_poll='' > erl_xcomp_putenv_copy='' > erl_xcomp_reliable_fpe='' > erl_xcomp_sysroot='' > exec_prefix='${prefix}' > host='x86_64-unknown-linux-gnu' > host_alias='' > host_cpu='x86_64' > host_os='linux-gnu' > host_vendor='unknown' > htmldir='${docdir}' > includedir='${prefix}/include' > infodir='${datarootdir}/info' > libdir='${exec_prefix}/lib' > libexecdir='${exec_prefix}/libexec' > localedir='${datarootdir}/locale' > localstatedir='${prefix}/var' > mandir='${datarootdir}/man' > oldincludedir='/usr/include' > pdfdir='${docdir}' > prefix='/opt/erlangR16B03' > program_transform_name='s,x,x,' > psdir='${docdir}' > sbindir='${exec_prefix}/sbin' > sharedstatedir='${prefix}/com' > subdirs=' lib erts' > sysconfdir='${prefix}/etc' > target_alias='' > > configure: exit 1 > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Thu Dec 19 10:18:58 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 10:18:58 +0100 Subject: [erlang-bugs] ssh_cli error during start_shell In-Reply-To: References: Message-ID: <52B2BA02.7090804@erlang.org> Thank you! We will take a look at this, expect delay due to holidays. On 2013-12-17 04:33, Anton Ryabkov wrote: > Hello, > > on Erlang R16B03 I've found that ssh_cli crushed with function_clause, > when I trying connected by ssh to my ssh daemon. Error: > ... > ** {function_clause,[{proplists,get_value, > [user,{ok,[]},undefined], > [{file,"proplists.erl"},{line,225}]}, > {ssh_cli,start_shell,2,[{file,"ssh_cli.erl"},{line,457}]}, > {ssh_cli,handle_ssh_msg,2, > [{file,"ssh_cli.erl"},{line,107}]}, > {ssh_channel,handle_info,2, > [{file,"ssh_channel.erl"},{line,241}]}, > {gen_server,handle_msg,5, > [{file,"gen_server.erl"},{line,604}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]} > > Note: all error in the file error. > > Steps to reproduce: > 1. compile ssh_bug.erl > 2. ssh_bug:test(). > 3. connect by ssh: ssh localhost -p9876 > 4. look at erlang concole for error. > > The reason of the bug is getting ConnectionInfo in the ssh_cli. > Instead of use ssh_connection_handler:connection_info method to get > ConnectionInfo used ssh_connection_handler:info. > > Patch for current bug: > 452c452 > < ConnectionInfo = ssh_connection_handler:info(ConnectionHandler, > --- > > ConnectionInfo = > ssh_connection_handler:connection_info(ConnectionHandler, > 456c456 > < {ok, User} = > --- > > User = > 462c462 > < [{_, PeerAddr}] = > --- > > {_, PeerAddr} = > 480c480 > < ConnectionInfo = ssh_connection_handler:info(ConnectionHandler, > --- > > ConnectionInfo = > ssh_connection_handler:connection_info(ConnectionHandler, > 482c482 > < {ok, User} = > --- > > User = > 491c491 > < [{_, PeerAddr}] = > --- > > {_, PeerAddr} = > > > Sample, error and patch in the attach. > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Thu Dec 19 10:22:04 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 10:22:04 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> Message-ID: <52B2BABC.4060701@erlang.org> On 2013-12-18 12:28, David Welton wrote: >> Don't do that, > Looking at version numbers like this is not something I'm in the habit > of doing often... > >> this doesn't mean that the syntax_tools application will >> actually be the one that shipped with R16B03. Check the application version >> instead: application:get_key(syntax_tools, vsn). (Note that this is only >> available after the application is loaded.) > I don't know how those numbers are managed, but the vsn.mk file in > master still has SYNTAX_TOOLS_VSN = 1.6.12, which is the same as I get > from my Erlang shell in R16B03; presumably, since the code in master > has been patched, the version number should get bumped? Problem is that we usually bump the version only when we do a release, (includes major, minor and patch releases) /Henrik Nord Erlang/OTP From kostis@REDACTED Thu Dec 19 10:24:32 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 19 Dec 2013 10:24:32 +0100 Subject: [erlang-bugs] Erlang otpR16B03 will not compile on centos 6.4 64 bit In-Reply-To: References: Message-ID: <52B2BB50.8080905@cs.ntua.gr> Slightly unrelated to the original intention of the post, but I've noticed the following combination of options which is... well, interesting: On 12/19/2013 12:09 AM, What Name wrote: > $ ./configure --prefix=/opt/erlangR16B03 --enable-threads > --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp > --disable-hipe --enable-native-libs Since you are disabling HiPE (why are you doing that by the way?), how exactly do you expect that the (main) libraries will be made in native code? Kostis From henrik@REDACTED Thu Dec 19 11:36:24 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 11:36:24 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <52B18333.8090807@ninenines.eu> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> Message-ID: <52B2CC28.80801@erlang.org> Hi We will not merge this patch just before Christmas and release a R16B03-1. Our suggestion is that: 1. If you are affected by this bug, apply the patch yourself until it will be merged into Erlang/OTP. (probably 17rc1 late January) 2. If you are using chicagoboss, stay on R16B02 if possible. 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for download on chicagoboss.org for R16B03 users. 4. add the patch to the rebar deps of chicagoboss. We will try to make sure things like this do not sneak into releases in the future, and apologise for the inconvenience caused. -- /Henrik Nord Erlang/OTP From n.oxyde@REDACTED Thu Dec 19 11:47:13 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Dec 2013 11:47:13 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <52B2CC28.80801@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2CC28.80801@erlang.org> Message-ID: <2DE1069F-55EA-45CA-89F1-75B390C837A8@gmail.com> Hello, With all due respect, that is completely irresponsible. Regards, -- Anthony Ramine Le 19 d?c. 2013 ? 11:36, Henrik Nord a ?crit : > Hi > > We will not merge this patch just before Christmas and release a R16B03-1. > > Our suggestion is that: > 1. If you are affected by this bug, apply the patch yourself until it will be merged into Erlang/OTP. (probably 17rc1 late January) > 2. If you are using chicagoboss, stay on R16B02 if possible. > 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for download on chicagoboss.org for R16B03 users. > 4. add the patch to the rebar deps of chicagoboss. > > We will try to make sure things like this do not sneak into releases in the future, and apologise for the inconvenience caused. > > > -- > /Henrik Nord Erlang/OTP > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From essen@REDACTED Thu Dec 19 11:55:46 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Dec 2013 11:55:46 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2BABC.4060701@erlang.org> Message-ID: <52B2D0B2.9070600@ninenines.eu> On 12/19/2013 11:43 AM, David Welton wrote: > Hi, > >>> I don't know how those numbers are managed, but the vsn.mk file in >>> master still has SYNTAX_TOOLS_VSN = 1.6.12, which is the same as I get >>> from my Erlang shell in R16B03; presumably, since the code in master >>> has been patched, the version number should get bumped? >> >> >> Problem is that we usually bump the version only when we do a release, >> (includes major, minor and patch releases) > > The functionality changed, in a way that's not backwards compatible, > so by my understanding of something like http://semver.org/ it'd be a > good idea to change the major number of the syntax_tools application. That only applies to releases. If there's no release there's no need to bump anything. -- Lo?c Hoguin http://ninenines.eu From ulf@REDACTED Thu Dec 19 13:56:15 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 19 Dec 2013 13:56:15 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2CC28.80801@erlang.org> Message-ID: I have pushed a workaround for parse_trans. https://github.com/uwiger/parse_trans/blob/master/doc/parse_trans.md#revert-1 parse_trans:revert/1 and parse_trans:revert_form/1 should be usable as drop-in replacements to erl_syntax:revert(). The workaround verifies that a transform is actually needed by generating a dummy module, reverting it and feeding it to the linter; if the linter crashes, the abstract code needs to be fixed. BR, Ulf W On 19 Dec 2013, at 11:56, David Welton wrote: > Hi, > >> We will not merge this patch just before Christmas and release a R16B03-1. > > Ok. > >> Our suggestion is that: >> 1. If you are affected by this bug, apply the patch yourself until it will >> be merged into Erlang/OTP. (probably 17rc1 late January) > > That's not really a workable solution for most people using CB. Zach > can correct me if I'm wrong, but I think the idea is going to simply > put a warning in CB so that people trying to use it with a R16B03 - > pretty much anyone who gets the "latest and greatest" from, say, > Erlang Solutions .deb repository - will get a user friendly message > saying that that release of Erlang is incompatible with Chicago Boss, > so please downgrade. > >> 2. If you are using chicagoboss, stay on R16B02 if possible. > > That probably works now that people have been warned. > >> 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for >> download on chicagoboss.org for R16B03 users. > > I am not an Erlang power user like you guys, but is it possible to > include that code in CB itself, and conditionally load it, overriding > the system version of that file, in the case of R16B03? > >> 4. add the patch to the rebar deps of chicagoboss. > > I think something like this could work too, but i don't know the > details of how it would work out. > >> We will try to make sure things like this do not sneak into releases in the >> future, and apologise for the inconvenience caused. > > I'm just a Chicago Boss user trying to figure out a solution that > improves things for everyone. I realize that parse_transforms are > kind of a 'dark corner' of Erlang, so I appreciate the help. > > Thank you > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From jared@REDACTED Thu Dec 19 16:00:01 2013 From: jared@REDACTED (Jared Morrow) Date: Thu, 19 Dec 2013 08:00:01 -0700 Subject: [erlang-bugs] Erlang otpR16B03 will not compile on centos 6.4 64 bit In-Reply-To: References: Message-ID: I compile Erlang on many differing CentOS machines and have had no compilation errors. Despite that, I tried following your steps exactly on both an Ubuntu 12.04 and CentOS 6.4 machine and could not reproduce your error, even using the flags you provided. -Jared On Wed, Dec 18, 2013 at 4:09 PM, What Name wrote: > Compilation under CEntos 6.x has been not goiing well since R16 is > released, since a lot cof companies are using CEntos as production and not > ubuntu. Can more resource be spent to make sure it works? > > Step: autoconf, then ru configure > > configure:5440: error: /opt/otp-OTP_R16B03/erts/autoconf/configure failed > for erts. > > ./configure --prefix=/opt/erlangR16B03 --enable-threads > --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp > --disable-hipe --enable-native-libs --enable-shared-zlib --enable-m64-build > --without-dynamic-trace --with-ssl --disable-vm-probes --without-javac > --enable-megaco_reentrant_flex_scanner > > Full trace: > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.63. Invocation command line was > > $ ./configure --prefix=/opt/erlangR16B03 --enable-threads > --enable-smp-support --with-termcap --enable-kernel-poll --enable-sctp > --disable-hipe --enable-native-libs --enable-shared-zlib --enable-m64-build > --without-dynamic-trace --with-ssl --disable-vm-probes --without-javac > --enable-megaco_reentrant_flex_scanner > > ## --------- ## > ## Platform. ## > ## --------- ## > > hostname = chat64.ejabberddev.localdomain > uname -m = x86_64 > uname -r = 2.6.32-358.23.2.el6.x86_64 > uname -s = Linux > uname -v = #1 SMP Wed Oct 16 18:37:12 UTC 2013 > > /usr/bin/uname -p = unknown > /bin/uname -X = unknown > > /bin/arch = x86_64 > /usr/bin/arch -k = unknown > /usr/convex/getsysinfo = unknown > /usr/bin/hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > PATH: /usr/lib64/qt-3.3/bin > PATH: /usr/local/sbin > PATH: /usr/sbin > PATH: /sbin > PATH: /usr/local/bin > PATH: /usr/bin > PATH: /bin > PATH: /opt/nodebin/bin > PATH: /opt/jdk1.7.0_25/bin > PATH: /opt/erlangR16B02/lib/erlang/bin > PATH: /root/bin > PATH: /opt/nodebin/bin > PATH: /opt/jdk1.7.0_25/bin > PATH: /opt/erlangR16B02/lib/erlang/bin > > > ## ----------- ## > ## Core tests. ## > ## ----------- ## > > configure:2110: checking build system type > configure:2128: result: x86_64-unknown-linux-gnu > configure:2150: checking host system type > configure:2165: result: x86_64-unknown-linux-gnu > configure:2270: checking for gcc > configure:2286: found /usr/bin/gcc > configure:2297: result: gcc > configure:2529: checking for C compiler version > configure:2537: gcc --version >&5 > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:2541: $? = 0 > configure:2548: gcc -v >&5 > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --with-bugurl= > http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared > --enable-threads=posix --enable-checking=release --with-system-zlib > --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-gnu-unique-object > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > --enable-libgcj-multifile --enable-java-maintainer-mode > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib > --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 > --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > configure:2552: $? = 0 > configure:2559: gcc -V >&5 > gcc: '-V' option must have argument > configure:2563: $? = 1 > configure:2586: checking for C compiler default output file name > configure:2608: gcc conftest.c >&5 > configure:2612: $? = 0 > configure:2650: result: a.out > configure:2669: checking whether the C compiler works > configure:2679: ./a.out > configure:2683: $? = 0 > configure:2702: result: yes > configure:2709: checking whether we are cross compiling > configure:2711: result: no > configure:2714: checking for suffix of executables > configure:2721: gcc -o conftest conftest.c >&5 > configure:2725: $? = 0 > configure:2751: result: > configure:2757: checking for suffix of object files > configure:2783: gcc -c conftest.c >&5 > configure:2787: $? = 0 > configure:2812: result: o > configure:2816: checking whether we are using the GNU C compiler > configure:2845: gcc -c conftest.c >&5 > configure:2852: $? = 0 > configure:2869: result: yes > configure:2878: checking whether gcc accepts -g > configure:2908: gcc -c -g conftest.c >&5 > configure:2915: $? = 0 > configure:3016: result: yes > configure:3033: checking for gcc option to accept ISO C89 > configure:3107: gcc -c -g -O2 conftest.c >&5 > configure:3114: $? = 0 > configure:3137: result: none needed > configure:3213: checking for g++ > configure:3229: found /usr/bin/g++ > configure:3240: result: g++ > configure:3267: checking for C++ compiler version > configure:3275: g++ --version >&5 > g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:3279: $? = 0 > configure:3286: g++ -v >&5 > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --with-bugurl= > http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared > --enable-threads=posix --enable-checking=release --with-system-zlib > --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-gnu-unique-object > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > --enable-libgcj-multifile --enable-java-maintainer-mode > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib > --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 > --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > configure:3290: $? = 0 > configure:3297: g++ -V >&5 > g++: '-V' option must have argument > configure:3301: $? = 1 > configure:3304: checking whether we are using the GNU C++ compiler > configure:3333: g++ -c conftest.cpp >&5 > configure:3340: $? = 0 > configure:3357: result: yes > configure:3366: checking whether g++ accepts -g > configure:3396: g++ -c -g conftest.cpp >&5 > configure:3403: $? = 0 > configure:3504: result: yes > configure:3570: checking for ld > configure:3586: found /usr/bin/ld > configure:3597: result: ld > configure:3623: checking for GNU make > configure:3661: result: yes (make) > configure:3681: checking for a BSD-compatible install > configure:3749: result: /usr/bin/install -c > configure:3767: checking whether ln -s works > configure:3771: result: yes > configure:3821: checking for ranlib > configure:3837: found /usr/bin/ranlib > configure:3848: result: ranlib > configure:3874: checking ERTS version > configure:3877: result: 5.10.4 > configure:3881: checking OTP release > configure:3884: result: R16B03 > configure:4281: creating ./config.status > > ## ---------------------- ## > ## Running config.status. ## > ## ---------------------- ## > > This file was extended by config.status, which was > generated by GNU Autoconf 2.63. Invocation command line was > > CONFIG_FILES = > CONFIG_HEADERS = > CONFIG_LINKS = > CONFIG_COMMANDS = > $ ./config.status > > on chat64.ejabberddev.localdomain > > config.status:698: creating Makefile > config.status:845: WARNING: 'Makefile.in' seems to ignore the > --datarootdir setting > config.status:698: creating make/output.mk > config.status:698: creating make/emd2exml > configure:5332: === configuring in lib (/opt/otp-OTP_R16B03/lib) > configure:5421: WARNING: no configuration information is in lib > configure:5332: === configuring in erts (/opt/otp-OTP_R16B03/erts) > configure:5435: running /bin/sh > /opt/otp-OTP_R16B03/erts/autoconf/configure --disable-option-checking > '--prefix=/opt/erlangR16B03' '--enable-threads' '--enable-smp-support' > '--with-termcap' '--enable-kernel-poll' '--enable-sctp' '--disable-hipe' > '--enable-native-libs' '--enable-shared-zlib' '--enable-m64-build' > '--without-dynamic-trace' '--with-ssl' '--disable-vm-probes' > '--without-javac' '--enable-megaco_reentrant_flex_scanner' > --cache-file=/dev/null --srcdir=/opt/otp-OTP_R16B03/erts > configure:5440: error: /opt/otp-OTP_R16B03/erts/autoconf/configure failed > for erts > > ## ---------------- ## > ## Cache variables. ## > ## ---------------- ## > > ac_cv_build=x86_64-unknown-linux-gnu > ac_cv_c_compiler_gnu=yes > ac_cv_cxx_compiler_gnu=yes > ac_cv_env_AR_set= > ac_cv_env_AR_value= > ac_cv_env_CCC_set= > ac_cv_env_CCC_value= > ac_cv_env_CC_set= > ac_cv_env_CC_value= > ac_cv_env_CFLAGS_set= > ac_cv_env_CFLAGS_value= > ac_cv_env_CFLAG_RUNTIME_LIBRARY_PATH_set= > ac_cv_env_CFLAG_RUNTIME_LIBRARY_PATH_value= > ac_cv_env_CPPFLAGS_set= > ac_cv_env_CPPFLAGS_value= > ac_cv_env_CPP_set= > ac_cv_env_CPP_value= > ac_cv_env_CXXFLAGS_set= > ac_cv_env_CXXFLAGS_value= > ac_cv_env_CXX_set= > ac_cv_env_CXX_value= > ac_cv_env_DED_LDFLAGS_set= > ac_cv_env_DED_LDFLAGS_value= > ac_cv_env_DED_LD_FLAG_RUNTIME_LIBRARY_PATH_set= > ac_cv_env_DED_LD_FLAG_RUNTIME_LIBRARY_PATH_value= > ac_cv_env_DED_LD_set= > ac_cv_env_DED_LD_value= > ac_cv_env_ERL_TOP_set= > ac_cv_env_ERL_TOP_value= > ac_cv_env_GETCONF_set= > ac_cv_env_GETCONF_value= > ac_cv_env_LDFLAGS_set= > ac_cv_env_LDFLAGS_value= > ac_cv_env_LD_set= > ac_cv_env_LD_value= > ac_cv_env_LFS_CFLAGS_set= > ac_cv_env_LFS_CFLAGS_value= > ac_cv_env_LFS_LDFLAGS_set= > ac_cv_env_LFS_LDFLAGS_value= > ac_cv_env_LFS_LIBS_set= > ac_cv_env_LFS_LIBS_value= > ac_cv_env_LIBS_set= > ac_cv_env_LIBS_value= > ac_cv_env_RANLIB_set= > ac_cv_env_RANLIB_value= > ac_cv_env_STATIC_CFLAGS_set= > ac_cv_env_STATIC_CFLAGS_value= > ac_cv_env_build_alias_set= > ac_cv_env_build_alias_value= > ac_cv_env_erl_xcomp_after_morecore_hook_set= > ac_cv_env_erl_xcomp_after_morecore_hook_value= > ac_cv_env_erl_xcomp_bigendian_set= > ac_cv_env_erl_xcomp_bigendian_value= > ac_cv_env_erl_xcomp_clock_gettime_cpu_time_set= > ac_cv_env_erl_xcomp_clock_gettime_cpu_time_value= > ac_cv_env_erl_xcomp_dlsym_brk_wrappers_set= > ac_cv_env_erl_xcomp_dlsym_brk_wrappers_value= > ac_cv_env_erl_xcomp_double_middle_endian_set= > ac_cv_env_erl_xcomp_double_middle_endian_value= > ac_cv_env_erl_xcomp_getaddrinfo_set= > ac_cv_env_erl_xcomp_getaddrinfo_value= > ac_cv_env_erl_xcomp_gethrvtime_procfs_ioctl_set= > ac_cv_env_erl_xcomp_gethrvtime_procfs_ioctl_value= > ac_cv_env_erl_xcomp_isysroot_set= > ac_cv_env_erl_xcomp_isysroot_value= > ac_cv_env_erl_xcomp_kqueue_set= > ac_cv_env_erl_xcomp_kqueue_value= > ac_cv_env_erl_xcomp_linux_clock_gettime_correction_set= > ac_cv_env_erl_xcomp_linux_clock_gettime_correction_value= > ac_cv_env_erl_xcomp_linux_nptl_set= > ac_cv_env_erl_xcomp_linux_nptl_value= > ac_cv_env_erl_xcomp_linux_usable_sigaltstack_set= > ac_cv_env_erl_xcomp_linux_usable_sigaltstack_value= > ac_cv_env_erl_xcomp_linux_usable_sigusrx_set= > ac_cv_env_erl_xcomp_linux_usable_sigusrx_value= > ac_cv_env_erl_xcomp_poll_set= > ac_cv_env_erl_xcomp_poll_value= > ac_cv_env_erl_xcomp_putenv_copy_set= > ac_cv_env_erl_xcomp_putenv_copy_value= > ac_cv_env_erl_xcomp_reliable_fpe_set= > ac_cv_env_erl_xcomp_reliable_fpe_value= > ac_cv_env_erl_xcomp_sysroot_set= > ac_cv_env_erl_xcomp_sysroot_value= > ac_cv_env_host_alias_set= > ac_cv_env_host_alias_value= > ac_cv_env_target_alias_set= > ac_cv_env_target_alias_value= > ac_cv_host=x86_64-unknown-linux-gnu > ac_cv_objext=o > ac_cv_path_install='/usr/bin/install -c' > ac_cv_prog_ac_ct_CC=gcc > ac_cv_prog_ac_ct_CXX=g++ > ac_cv_prog_ac_ct_LD=ld > ac_cv_prog_ac_ct_RANLIB=ranlib > ac_cv_prog_cc_c89= > ac_cv_prog_cc_g=yes > ac_cv_prog_cxx_g=yes > > ## ----------------- ## > ## Output variables. ## > ## ----------------- ## > > AR='' > BOOTSTRAP_ONLY='no' > CC='gcc' > CFLAGS='-m64 -g -O2' > CFLAG_RUNTIME_LIBRARY_PATH='' > CPP='' > CPPFLAGS='' > CROSS_COMPILING='no' > CXX='g++' > CXXFLAGS='-g -O2' > DED_LD='' > DED_LDFLAGS='' > DED_LD_FLAG_RUNTIME_LIBRARY_PATH='' > DEFAULT_VERBOSITY='1' > DEFS='-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"' > ECHO_C='' > ECHO_N='-n' > ECHO_T='' > ERL_TOP='/opt/otp-OTP_R16B03' > ERTS_VSN='5.10.4' > EXEEXT='' > GETCONF='' > INSTALL_DATA='${INSTALL} -m 644' > INSTALL_PROGRAM='${INSTALL}' > INSTALL_SCRIPT='${INSTALL}' > LD='ld' > LDFLAGS='-m64 ' > LFS_CFLAGS='' > LFS_LDFLAGS='' > LFS_LIBS='' > LIBOBJS='' > LIBS='' > LN_S='ln -s' > LTLIBOBJS='' > MAKE_PROG='make' > NATIVE_LIBS_ENABLED='' > OBJEXT='o' > OTP_REL='R16B03' > PACKAGE_BUGREPORT='' > PACKAGE_NAME='' > PACKAGE_STRING='' > PACKAGE_TARNAME='' > PACKAGE_VERSION='' > PATH_SEPARATOR=':' > RANLIB='ranlib' > SHELL='/bin/sh' > STATIC_CFLAGS='' > TARGET='x86_64-unknown-linux-gnu' > ac_ct_CC='gcc' > ac_ct_CXX='g++' > bindir='${exec_prefix}/bin' > build='x86_64-unknown-linux-gnu' > build_alias='' > build_cpu='x86_64' > build_os='linux-gnu' > build_vendor='unknown' > datadir='${datarootdir}' > datarootdir='${prefix}/share' > docdir='${datarootdir}/doc/${PACKAGE}' > dvidir='${docdir}' > erl_xcomp_after_morecore_hook='' > erl_xcomp_bigendian='' > erl_xcomp_clock_gettime_cpu_time='' > erl_xcomp_dlsym_brk_wrappers='' > erl_xcomp_double_middle_endian='' > erl_xcomp_getaddrinfo='' > erl_xcomp_gethrvtime_procfs_ioctl='' > erl_xcomp_isysroot='' > erl_xcomp_kqueue='' > erl_xcomp_linux_clock_gettime_correction='' > erl_xcomp_linux_nptl='' > erl_xcomp_linux_usable_sigaltstack='' > erl_xcomp_linux_usable_sigusrx='' > erl_xcomp_poll='' > erl_xcomp_putenv_copy='' > erl_xcomp_reliable_fpe='' > erl_xcomp_sysroot='' > exec_prefix='${prefix}' > host='x86_64-unknown-linux-gnu' > host_alias='' > host_cpu='x86_64' > host_os='linux-gnu' > host_vendor='unknown' > htmldir='${docdir}' > includedir='${prefix}/include' > infodir='${datarootdir}/info' > libdir='${exec_prefix}/lib' > libexecdir='${exec_prefix}/libexec' > localedir='${datarootdir}/locale' > localstatedir='${prefix}/var' > mandir='${datarootdir}/man' > oldincludedir='/usr/include' > pdfdir='${docdir}' > prefix='/opt/erlangR16B03' > program_transform_name='s,x,x,' > psdir='${docdir}' > sbindir='${exec_prefix}/sbin' > sharedstatedir='${prefix}/com' > subdirs=' lib erts' > sysconfdir='${prefix}/etc' > target_alias='' > > configure: exit 1 > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.mauritzson@REDACTED Thu Dec 19 11:19:17 2013 From: daniel.mauritzson@REDACTED (Daniel Mauritzson) Date: Thu, 19 Dec 2013 11:19:17 +0100 Subject: [erlang-bugs] Emacs-mode does not recognize functions with binary matching in the header. Message-ID: I recently noticed that the emacs-mode does not recognize functions that have binary matching in the header, like this: function1(<>) -> Bin. I would guess that it is a problem with the regex that is used for functions but my knowlage about regex in lisp is lacking. Version of emacs-mode: 2.7 -- Daniel Mauritzson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Dec 20 13:51:19 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 20 Dec 2013 13:51:19 +0100 Subject: [erlang-bugs] [erlang-patches] syntax_tools anonymous function error In-Reply-To: <52B2CC28.80801@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2CC28.80801@erlang.org> Message-ID: <52B43D47.4060807@cs.ntua.gr> On 12/19/2013 11:36 AM, Henrik Nord wrote: > Hi > > We will not merge this patch just before Christmas and release a R16B03-1. > > Our suggestion is that: > 1. If you are affected by this bug, apply the patch yourself until it > will be merged into Erlang/OTP. (probably 17rc1 late January) > 2. If you are using chicagoboss, stay on R16B02 if possible. > 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for > download on chicagoboss.org for R16B03 users. > 4. add the patch to the rebar deps of chicagoboss. > > We will try to make sure things like this do not sneak into releases in > the future, and apologise for the inconvenience caused. This is just to let you know that this bug also hits Concuerror (it happens when Concuerror tries to instrument gen_server) and we've spent a fair amount of effort debugging why Concuerror suddenly stopped working without changing anything in its code base, but just upgrading the OTP version we use. On a positive side, we can confirm that the following patch: [PATCH 1/2] Fix reverting of local implicit funs in erl_syntax' fixes the error. Minimally, it should be merged to master ASAP. But in my opinion R16B03 should be scrapped and replaced by a R16B03-1. Happy holidays! Kostis From vinoski@REDACTED Fri Dec 20 14:33:45 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 20 Dec 2013 08:33:45 -0500 Subject: [erlang-bugs] Emacs-mode does not recognize functions with binary matching in the header. In-Reply-To: References: Message-ID: On Thu, Dec 19, 2013 at 5:19 AM, Daniel Mauritzson < daniel.mauritzson@REDACTED> wrote: > I recently noticed that the emacs-mode does not recognize functions that > have binary matching in the header, like this: > > function1(<>) -> > > Bin. > > > I would guess that it is a problem with the regex that is used for > functions but my knowlage about regex in lisp is lacking. > When you say "does not recognize" what exactly do you mean? Is the indentation wrong, or something else? --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Fri Dec 20 15:18:26 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 20 Dec 2013 09:18:26 -0500 Subject: [erlang-bugs] Emacs-mode does not recognize functions with binary matching in the header. In-Reply-To: References: Message-ID: I've confirmed there's a problem with the erlang-get-function-arity defun in erlang.el that prevents imenu from recognizing this function. --steve On Fri, Dec 20, 2013 at 8:45 AM, Daniel Mauritzson < daniel.mauritzson@REDACTED> wrote: > No the indentation is correct, the problem I see is this: > * If the function is exported it is not highlighted as the other exported > functions > * imenu does not recognize it (guess this could be a problem of imenu and > not erlang-mode) > * I'm also using edts and that shows the function as function1/nil instead > of function1/1 (an edts problem maybe or xref) > > On the other hand I have no problem with tags for it. > > > On 20 December 2013 14:33, Steve Vinoski wrote: > >> >> >> >> On Thu, Dec 19, 2013 at 5:19 AM, Daniel Mauritzson < >> daniel.mauritzson@REDACTED> wrote: >> >>> I recently noticed that the emacs-mode does not recognize functions that >>> have binary matching in the header, like this: >>> >>> function1(<>) -> >>> >>> Bin. >>> >>> >>> I would guess that it is a problem with the regex that is used for >>> functions but my knowlage about regex in lisp is lacking. >>> >> >> When you say "does not recognize" what exactly do you mean? Is the >> indentation wrong, or something else? >> >> --steve >> > > > > -- > Daniel Mauritzson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.mauritzson@REDACTED Fri Dec 20 14:45:51 2013 From: daniel.mauritzson@REDACTED (Daniel Mauritzson) Date: Fri, 20 Dec 2013 14:45:51 +0100 Subject: [erlang-bugs] Emacs-mode does not recognize functions with binary matching in the header. In-Reply-To: References: Message-ID: No the indentation is correct, the problem I see is this: * If the function is exported it is not highlighted as the other exported functions * imenu does not recognize it (guess this could be a problem of imenu and not erlang-mode) * I'm also using edts and that shows the function as function1/nil instead of function1/1 (an edts problem maybe or xref) On the other hand I have no problem with tags for it. On 20 December 2013 14:33, Steve Vinoski wrote: > > > > On Thu, Dec 19, 2013 at 5:19 AM, Daniel Mauritzson < > daniel.mauritzson@REDACTED> wrote: > >> I recently noticed that the emacs-mode does not recognize functions that >> have binary matching in the header, like this: >> >> function1(<>) -> >> >> Bin. >> >> >> I would guess that it is a problem with the regex that is used for >> functions but my knowlage about regex in lisp is lacking. >> > > When you say "does not recognize" what exactly do you mean? Is the > indentation wrong, or something else? > > --steve > -- Daniel Mauritzson -------------- next part -------------- An HTML attachment was scrubbed... URL: From zerthurd@REDACTED Tue Dec 24 12:44:34 2013 From: zerthurd@REDACTED (Max Treskin) Date: Tue, 24 Dec 2013 18:44:34 +0700 Subject: [erlang-bugs] inet:ntoa/1 incorrect typespec Message-ID: Hello inet:ntoa/1 has following typespec: -spec ntoa(IpAddress) -> ? ?{ok, Address} | {error, einval} when ? ? ? Address :: string(), ? ? ? IpAddress :: ip_address(). ntoa(Addr) -> ? ? inet_parse:ntoa(Addr). but inet_parse:ntoa/1 returns only: ?string() | {error, einval} there is no tagged tuple {ok, string()} This error also exists in inet man page due to incorrect typespec. Is it possible to check kernel and stdlib with dialyzer? --? Max Treskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From edwardt.tril@REDACTED Sat Dec 28 21:32:46 2013 From: edwardt.tril@REDACTED (What Name) Date: Sat, 28 Dec 2013 15:32:46 -0500 Subject: [erlang-bugs] configure: error: cannot find sources () in /opt/otp-OTP_R16B03/erts Centos 6.5 64bit Message-ID: retry manual installation of elerna R16B03 again: cat /etc/redhat-release CentOS release 6.5 (Final) 1) download from http://www.erlang.org/download/otp_src_R16B03.tar.gz 2) tar -xvf otp_src_R16B03.tar.gz , then cd to directory 2) ./configure --disable-option-checking '--prefix=/opt/erlangR16B03' '--enable-threads' '--enable-smp-support' '--with-termcap' '--enable-kernel-poll' '--enable-sctp' '--enable-hipe' '--enable-native-libs' '--enable-shared-zlib' '--enable-m64-build' '--without-dynamic-trace' '--with-ssl' '--disable-vm-probes' '--without-javac' '--enable-megaco_reentrant_flex_scanner' --cache-file=/dev/null --srcdir=/opt/otp-OTP_R16B03/erts 3) seeing this : configure: error: cannot find sources () in /opt/otp-OTP_R16B03/erts 4) ls erts:-rw-rw-r--. 1 421 wheel 62247 Dec 9 14:12 aclocal.m4 -rw-rw-r--. 1 421 wheel 4917 Dec 9 14:12 AUTHORS drwxrwxr-x. 3 421 wheel 4096 Dec 9 14:12 autoconf -rw-rw-r--. 1 421 wheel 31212 Dec 9 14:12 config.h.in -rwxrwxr-x. 1 421 wheel 1110759 Dec 9 14:12 configure -rw-rw-r--. 1 421 wheel 126725 Dec 9 14:12 configure.in drwxrwxr-x. 8 421 wheel 4096 Dec 9 14:12 doc drwxrwxr-x. 12 421 wheel 4096 Dec 9 14:12 emulator drwxrwxr-x. 5 421 wheel 4096 Dec 9 14:12 epmd drwxrwxr-x. 5 421 wheel 4096 Dec 9 14:12 etc drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 example drwxrwxr-x. 3 421 wheel 4096 Dec 9 14:12 include -rw-rw-r--. 1 421 wheel 95 Dec 9 14:12 info.src drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 internal_doc drwxrwxr-x. 3 421 wheel 4096 Dec 9 14:12 lib drwxrwxr-x. 6 421 wheel 4096 Dec 9 14:12 lib_src -rw-rw-r--. 1 421 wheel 4767 Dec 9 14:12 Makefile.in drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 man drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 obj drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 obj.debug drwxrwxr-x. 4 421 wheel 4096 Dec 9 14:12 preloaded drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 start_scripts drwxrwxr-x. 10 421 wheel 4096 Dec 9 14:12 test -rw-rw-r--. 1 421 wheel 842 Dec 9 14:12 vsn.mk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared@REDACTED Sun Dec 29 00:11:46 2013 From: jared@REDACTED (Jared Morrow) Date: Sat, 28 Dec 2013 16:11:46 -0700 Subject: [erlang-bugs] configure: error: cannot find sources () in /opt/otp-OTP_R16B03/erts Centos 6.5 64bit In-Reply-To: References: Message-ID: Remove the '--srcdir' option, you don't need it. On Saturday, December 28, 2013, What Name wrote: > retry manual installation of elerna R16B03 again: > > cat /etc/redhat-release > CentOS release 6.5 (Final) > > > > 1) download from http://www.erlang.org/download/otp_src_R16B03.tar.gz > 2) tar -xvf otp_src_R16B03.tar.gz , then cd to directory > 2) ./configure --disable-option-checking '--prefix=/opt/erlangR16B03' > '--enable-threads' '--enable-smp-support' '--with-termcap' > '--enable-kernel-poll' '--enable-sctp' '--enable-hipe' > '--enable-native-libs' '--enable-shared-zlib' '--enable-m64-build' > '--without-dynamic-trace' '--with-ssl' '--disable-vm-probes' > '--without-javac' '--enable-megaco_reentrant_flex_scanner' > --cache-file=/dev/null --srcdir=/opt/otp-OTP_R16B03/erts > > > 3) seeing this : > configure: error: cannot find sources () in /opt/otp-OTP_R16B03/erts > > 4) ls erts:-rw-rw-r--. 1 421 wheel 62247 Dec 9 14:12 aclocal.m4 > -rw-rw-r--. 1 421 wheel 4917 Dec 9 14:12 AUTHORS > drwxrwxr-x. 3 421 wheel 4096 Dec 9 14:12 autoconf > -rw-rw-r--. 1 421 wheel 31212 Dec 9 14:12 config.h.in > -rwxrwxr-x. 1 421 wheel 1110759 Dec 9 14:12 configure > -rw-rw-r--. 1 421 wheel 126725 Dec 9 14:12 configure.in > drwxrwxr-x. 8 421 wheel 4096 Dec 9 14:12 doc > drwxrwxr-x. 12 421 wheel 4096 Dec 9 14:12 emulator > drwxrwxr-x. 5 421 wheel 4096 Dec 9 14:12 epmd > drwxrwxr-x. 5 421 wheel 4096 Dec 9 14:12 etc > drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 example > drwxrwxr-x. 3 421 wheel 4096 Dec 9 14:12 include > -rw-rw-r--. 1 421 wheel 95 Dec 9 14:12 info.src > drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 internal_doc > drwxrwxr-x. 3 421 wheel 4096 Dec 9 14:12 lib > drwxrwxr-x. 6 421 wheel 4096 Dec 9 14:12 lib_src > -rw-rw-r--. 1 421 wheel 4767 Dec 9 14:12 Makefile.in > drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 man > drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 obj > drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 obj.debug > drwxrwxr-x. 4 421 wheel 4096 Dec 9 14:12 preloaded > drwxrwxr-x. 2 421 wheel 4096 Dec 9 14:12 start_scripts > drwxrwxr-x. 10 421 wheel 4096 Dec 9 14:12 test > -rw-rw-r--. 1 421 wheel 842 Dec 9 14:12 vsn.mk > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdtwonotes@REDACTED Tue Dec 31 05:17:19 2013 From: pdtwonotes@REDACTED (Paul Dickson) Date: Mon, 30 Dec 2013 23:17:19 -0500 Subject: [erlang-bugs] Dependencies changed for building wx .so files? Message-ID: Back in March 2013 a problem appeared in the Arch Linux package distribution of Erlang R16B01. The package building procedure was not building the two .so files that are part of the wx package, as described in the Arch bug: https://bugs.archlinux.org/task/34201 The problem turned out to be two missing dependencies, wxgtk and wxgtk2.0. When those were added to the Arch package build procedure for Erlang, Erlang/otp's own build procedure then generated wxe_driver.so and erl_gl.so. Without the wxgtk dependencies being provided, the wx 'priv' directory was not being created at all. So that was fixed. But now in R16B03 the problem is back again: no wx .so files. Even though the wxgtk dependencies are being used. The bug report for that is here: https://bugs.archlinux.org/task/38302 The assumption is that there is some new dependency that the wx application wants. We have not been able to locate the place in Erlang's build packages where this is specified explicitly, so the missing dependencies can be added to the Arch package-building procedure. So some guidance on how to locate wx's dependencies would be appreciated. Downloading the Erlang sources and building that on my own machine works just fine, of course. -------------- next part -------------- An HTML attachment was scrubbed... URL: