From rabbe.fogelholm@REDACTED Mon Nov 3 15:17:33 2014 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Mon, 3 Nov 2014 15:17:33 +0100 Subject: [erlang-bugs] The description of dict:fold/3 In-Reply-To: <53B402D0.9070607@ericsson.com> References: <53B2764E.6060807@ericsson.com> <53B2D230.2020809@ericsson.com> <53B402D0.9070607@ericsson.com> Message-ID: <54578E7D.4050305@ericsson.com> On the page http://www.erlang.org/doc/man/dict.html#fold-3 in the description of fold/3 the wording "if the list is empty" should most likely be "if the dict is empty" --Rabbe Fogelholm, Ericsson, Stockholm From kostis@REDACTED Mon Nov 3 22:32:09 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 03 Nov 2014 22:32:09 +0100 Subject: [erlang-bugs] code:get_object_code/1 Message-ID: <5457F459.7070008@cs.ntua.gr> A user of PropEr (http://proper.softlab.ntua.gr/) reported that he was not able to use the erlang:timestamp() type as generator. (I.e. be able to generate random time stamp values using the existing mechanisms that PropEr provides.) The culprit was traced to function code:get_object_code/1 which returns 'error' for the 'erlang' module, instead of returning a tuple with its binary data object and beam filename, as one would expect. 1> code:get_object_code(erlang). error While for pretty much all other modules, one gets: 2> code:get_object_code(kernel). {kernel,<<70,79,82,49,0,0,86,252,66,69,65,77,65,116,111, 109,0,0,2,228,0,0,0,65,6,107,101,...>>, "/home/kostis/HiPE/otp/lib/kernel/ebin/kernel.beam"} 3> code:get_object_code(beam_lib). {beam_lib,<<70,79,82,49,0,1,239,188,66,69,65,77,65,116, 111,109,0,0,10,19,0,0,0,225,8,98,101,...>>, "/home/kostis/HiPE/otp/lib/stdlib/ebin/beam_lib.beam"} Is there a reason for this discrepancy? There is a variety of tools that needs to be able to manipulate the object code or extract information from the abstract code of modules, such as the list of their exported types, and there needs to be some (preferably simple) way of getting access to this information. In investigating further the issue, I discovered that the problem can be fixed if one manually adds the erts/preloaded/erl dir in the code path. But in my opinion, having to do this is unnecessarily complicated, possibly error prone and breaks the principle of least astonishment. 4> code:add_path("/home/kostis/HiPE/otp/erts/preloaded/ebin"). true 5> code:get_object_code(erlang). {erlang,<<70,79,82,49,0,1,126,172,66,69,65,77,65,116,111, 109,0,0,15,110,0,0,1,92,6,101,114,...>>, "/home/kostis/HiPE/otp/erts/preloaded/ebin/erlang.beam"} So, I can ask my question differently: Can we please have the preloaded modules in the code path, since they arguably are there? Kostis From mattias.waldau@REDACTED Thu Nov 6 09:21:46 2014 From: mattias.waldau@REDACTED (Mattias Waldau) Date: Thu, 6 Nov 2014 09:21:46 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. Message-ID: This is the program -module('missing-comma-not-detected'). -export([data/1]). -compile(export_all). -record(shcnode, { nodename :: any(), y_axis :: number(), children :: [any()], article_number :: number(), attribute_condition :: string()}). data(1) -> [ #shcnode{nodename = start, y_axis = 0, children = [d1285]}, #shcnode{nodename = d1285, y_axis = 295, children = [1939, 1940]} #shcnode{nodename = 1940, y_axis = 525, children = [bm3203], article_number = 14432861}, #shcnode{nodename = 1939, y_axis = 530, children = [bm3203], article_number = 14432860}, #shcnode{nodename = bm3203, y_axis = 915, children = []} ]. Note the missing "," after [1939, 1940]} Only 4 rows are detected length('missing-comma-not-detected':data(1)). 4 --- If I add the comma, I get length('missing-comma-not-detected':data(1)). 5 ---- I am using Erlang 17.3 on ubuntu. erlang:system_info(otp_release). "17" 36> |erl -V Eshell V6.2 (abort with ^G) 1> | --- Thanks, Mattias -------------- next part -------------- An HTML attachment was scrubbed... URL: From cons@REDACTED Thu Nov 6 12:46:42 2014 From: cons@REDACTED (=?iso-8859-1?Q?Cons_T_=C5hs?=) Date: Thu, 6 Nov 2014 12:46:42 +0100 Subject: [erlang-bugs] Dialyzer performance problem Message-ID: <49DC5489-D594-4A3D-A0D9-62FA60A0A271@tail-f.com> Hi, the attached archive exposes a problem in dialyzer where analysis time increases severely (up to non termination) when defined types are referenced with a module name prefix, probably in combination with recursively defined types. See the README file for further details. Cons -------------- next part -------------- A non-text attachment was scrubbed... Name: ditrap.tgz Type: application/octet-stream Size: 2186 bytes Desc: not available URL: -------------- next part -------------- From vladdu55@REDACTED Fri Nov 7 09:09:04 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 7 Nov 2014 09:09:04 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: Message-ID: Hi Mattias, This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is the same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys overlap, then the last one "wins". best regards, Vlad On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau wrote: > This is the program > > -module('missing-comma-not-detected'). > > -export([data/1]). > > -compile(export_all). > > -record(shcnode, { > nodename :: any(), > y_axis :: number(), > children :: [any()], > article_number :: number(), > attribute_condition :: string()}). > > > data(1) -> > [ > #shcnode{nodename = start, y_axis = 0, children = [d1285]}, > #shcnode{nodename = d1285, y_axis = 295, children = [1939, 1940]} > #shcnode{nodename = 1940, y_axis = 525, children = [bm3203], > article_number = 14432861}, > #shcnode{nodename = 1939, y_axis = 530, children = [bm3203], > article_number = 14432860}, > #shcnode{nodename = bm3203, y_axis = 915, children = []} > ]. > > > Note the missing "," after [1939, 1940]} > > Only 4 rows are detected > > length('missing-comma-not-detected':data(1)). > 4 > > --- > > If I add the comma, I get > > length('missing-comma-not-detected':data(1)). > 5 > > ---- > > I am using Erlang 17.3 on ubuntu. > > erlang:system_info(otp_release). > "17" > > 36> erl -V > Eshell V6.2 (abort with ^G) > 1> > > --- > > Thanks, > > Mattias > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Nov 7 12:15:05 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Nov 2014 13:15:05 +0200 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: Message-ID: <545CA9B9.4000304@ninenines.eu> It is legal but there probably should be a warning for this particular case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when you can just do #rec{a=2, b=3}. On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: > Hi Mattias, > > This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is the > same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys > overlap, then the last one "wins". > > best regards, > Vlad > > > On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau > > wrote: > > This is the program > > -module('missing-comma-not-detected'). > > -export([data/1]). > > -compile(export_all). > > -record(shcnode, { > nodename :: any(), > y_axis :: number(), > children :: [any()], > article_number :: number(), > attribute_condition :: string()}). > > > data(1) -> > [ > #shcnode{nodename = start, y_axis = 0, children = [d1285]}, > #shcnode{nodename = d1285, y_axis = 295, children = [1939, 1940]} > #shcnode{nodename = 1940, y_axis = 525, children = [bm3203], > article_number = 14432861}, > #shcnode{nodename = 1939, y_axis = 530, children = [bm3203], > article_number = 14432860}, > #shcnode{nodename = bm3203, y_axis = 915, children = []} > ]. > > > Note the missing "," after [1939, 1940]} > > Only 4 rows are detected > > length('missing-comma-not-detected':data(1)). > 4 > > --- > > If I add the comma, I get > > length('missing-comma-not-detected':data(1)). > 5 > > ---- > > I am using Erlang 17.3 on ubuntu. > > erlang:system_info(otp_release). > "17" > > 36> |erl -V > Eshell V6.2 (abort with ^G) > 1> | > > --- > > Thanks, > > Mattias > > > > > _______________________________________________ > 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 > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Fri Nov 7 12:41:00 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Nov 2014 13:41:00 +0200 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <8dd18abb2d927551f57fcd766ac26d3c.squirrel@klotjohan.proxel.se> References: <545CA9B9.4000304@ninenines.eu> <8dd18abb2d927551f57fcd766ac26d3c.squirrel@klotjohan.proxel.se> Message-ID: <545CAFCC.7040805@ninenines.eu> Warnings are ordinary Erlang code which is prone to errors. On 11/07/2014 01:46 PM, Roland Karlsson wrote: > No warning is needed methinks. It is just ordinary Erlang code. > It is equal to. > >> REC1 = #rec{b=3}. >> REC2 = REC1#rec{a=2}. > > Nothing strange at all. > > > /Roland > > > > >> It is legal but there probably should be a warning for this particular >> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when you >> can just do #rec{a=2, b=3}. >> >> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: >>> Hi Mattias, >>> >>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is the >>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys >>> overlap, then the last one "wins". >>> >>> best regards, >>> Vlad >>> >>> >>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau >>> > wrote: >>> >>> This is the program >>> >>> -module('missing-comma-not-detected'). >>> >>> -export([data/1]). >>> >>> -compile(export_all). >>> >>> -record(shcnode, { >>> nodename :: any(), >>> y_axis :: number(), >>> children :: [any()], >>> article_number :: number(), >>> attribute_condition :: string()}). >>> >>> >>> data(1) -> >>> [ >>> #shcnode{nodename = start, y_axis = 0, children = [d1285]}, >>> #shcnode{nodename = d1285, y_axis = 295, children = [1939, >>> 1940]} >>> #shcnode{nodename = 1940, y_axis = 525, children = [bm3203], >>> article_number = 14432861}, >>> #shcnode{nodename = 1939, y_axis = 530, children = [bm3203], >>> article_number = 14432860}, >>> #shcnode{nodename = bm3203, y_axis = 915, children = []} >>> ]. >>> >>> >>> Note the missing "," after [1939, 1940]} >>> >>> Only 4 rows are detected >>> >>> length('missing-comma-not-detected':data(1)). >>> 4 >>> >>> --- >>> >>> If I add the comma, I get >>> >>> length('missing-comma-not-detected':data(1)). >>> 5 >>> >>> ---- >>> >>> I am using Erlang 17.3 on ubuntu. >>> >>> erlang:system_info(otp_release). >>> "17" >>> >>> 36> |erl -V >>> Eshell V6.2 (abort with ^G) >>> 1> | >>> >>> --- >>> >>> Thanks, >>> >>> Mattias >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> -- >> Lo??c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Fri Nov 7 13:01:55 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Nov 2014 14:01:55 +0200 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <51a4fe84c78fa12c9a2d65b4df64d9e4.squirrel@klotjohan.proxel.se> References: <545CA9B9.4000304@ninenines.eu> <8dd18abb2d927551f57fcd766ac26d3c.squirrel@klotjohan.proxel.se> <545CAFCC.7040805@ninenines.eu> <51a4fe84c78fa12c9a2d65b4df64d9e4.squirrel@klotjohan.proxel.se> Message-ID: <545CB4B3.2050606@ninenines.eu> I'm not sure how that relates. This expression can be reasonably written on purpose. The same cannot be said for #rec{a=2}#rec{b=3}. On 11/07/2014 02:01 PM, Roland Karlsson wrote: > If there is a warning there, then all expressions including operators, > e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ? > Do you know the precedence of + and rem ? What is the result? > > /Roland > > > >> Warnings are ordinary Erlang code which is prone to errors. >> >> On 11/07/2014 01:46 PM, Roland Karlsson wrote: >>> No warning is needed methinks. It is just ordinary Erlang code. >>> It is equal to. >>> >>>> REC1 = #rec{b=3}. >>>> REC2 = REC1#rec{a=2}. >>> >>> Nothing strange at all. >>> >>> >>> /Roland >>> >>> >>> >>> >>>> It is legal but there probably should be a warning for this particular >>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when >>>> you >>>> can just do #rec{a=2, b=3}. >>>> >>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: >>>>> Hi Mattias, >>>>> >>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is >>>>> the >>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys >>>>> overlap, then the last one "wins". >>>>> >>>>> best regards, >>>>> Vlad >>>>> >>>>> >>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau >>>>> > >>>>> wrote: >>>>> >>>>> This is the program >>>>> >>>>> -module('missing-comma-not-detected'). >>>>> >>>>> -export([data/1]). >>>>> >>>>> -compile(export_all). >>>>> >>>>> -record(shcnode, { >>>>> nodename :: any(), >>>>> y_axis :: number(), >>>>> children :: [any()], >>>>> article_number :: number(), >>>>> attribute_condition :: string()}). >>>>> >>>>> >>>>> data(1) -> >>>>> [ >>>>> #shcnode{nodename = start, y_axis = 0, children = [d1285]}, >>>>> #shcnode{nodename = d1285, y_axis = 295, children = [1939, >>>>> 1940]} >>>>> #shcnode{nodename = 1940, y_axis = 525, children = >>>>> [bm3203], >>>>> article_number = 14432861}, >>>>> #shcnode{nodename = 1939, y_axis = 530, children = >>>>> [bm3203], >>>>> article_number = 14432860}, >>>>> #shcnode{nodename = bm3203, y_axis = 915, children = []} >>>>> ]. >>>>> >>>>> >>>>> Note the missing "," after [1939, 1940]} >>>>> >>>>> Only 4 rows are detected >>>>> >>>>> length('missing-comma-not-detected':data(1)). >>>>> 4 >>>>> >>>>> --- >>>>> >>>>> If I add the comma, I get >>>>> >>>>> length('missing-comma-not-detected':data(1)). >>>>> 5 >>>>> >>>>> ---- >>>>> >>>>> I am using Erlang 17.3 on ubuntu. >>>>> >>>>> erlang:system_info(otp_release). >>>>> "17" >>>>> >>>>> 36> |erl -V >>>>> Eshell V6.2 (abort with ^G) >>>>> 1> | >>>>> >>>>> --- >>>>> >>>>> Thanks, >>>>> >>>>> Mattias >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> -- >>>> Lo????c Hoguin >>>> http://ninenines.eu >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>> >>> >>> >> >> -- >> Lo??c Hoguin >> http://ninenines.eu >> > > -- Lo?c Hoguin http://ninenines.eu From mattias.waldau@REDACTED Sat Nov 8 09:02:08 2014 From: mattias.waldau@REDACTED (Mattias Waldau) Date: Sat, 8 Nov 2014 09:02:08 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <93494073be6dda9f1323712611d792d5.squirrel@klotjohan.proxel.se> References: <545CA9B9.4000304@ninenines.eu> <8dd18abb2d927551f57fcd766ac26d3c.squirrel@klotjohan.proxel.se> <545CAFCC.7040805@ninenines.eu> <51a4fe84c78fa12c9a2d65b4df64d9e4.squirrel@klotjohan.proxel.se> <545CB4B3.2050606@ninenines.eu> <93494073be6dda9f1323712611d792d5.squirrel@klotjohan.proxel.se> Message-ID: Yes, I can agree that #rec{a=2}#rec{b=3} is a matter of opinion. However, I completely fail to understand how #rec{a=2}#rec{a=3} can be a matter of opinion, since data in the code is LOST. There should be a warning. My sample below shows how catastropic the missing "," can be. /mattias On 07/11/2014 13:22, Roland Karlsson wrote: > Maybe we shall not discuss this for ever :) > It is a matter of opinion after all. > > But - it is the same IMHO. It is a matter of operators and the need > to set paranthesis when the precedents and right/left association is > not obvious. > > The rec example can be written thus > > (#rec{a=2})#rec{b=3} > > Then everything is clear. > > > /Roland > > > >> I'm not sure how that relates. This expression can be reasonably written >> on purpose. The same cannot be said for #rec{a=2}#rec{b=3}. >> >> On 11/07/2014 02:01 PM, Roland Karlsson wrote: >>> If there is a warning there, then all expressions including operators, >>> e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ? >>> Do you know the precedence of + and rem ? What is the result? >>> >>> /Roland >>> >>> >>> >>>> Warnings are ordinary Erlang code which is prone to errors. >>>> >>>> On 11/07/2014 01:46 PM, Roland Karlsson wrote: >>>>> No warning is needed methinks. It is just ordinary Erlang code. >>>>> It is equal to. >>>>> >>>>>> REC1 = #rec{b=3}. >>>>>> REC2 = REC1#rec{a=2}. >>>>> Nothing strange at all. >>>>> >>>>> >>>>> /Roland >>>>> >>>>> >>>>> >>>>> >>>>>> It is legal but there probably should be a warning for this >>>>>> particular >>>>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when >>>>>> you >>>>>> can just do #rec{a=2, b=3}. >>>>>> >>>>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: >>>>>>> Hi Mattias, >>>>>>> >>>>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is >>>>>>> the >>>>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys >>>>>>> overlap, then the last one "wins". >>>>>>> >>>>>>> best regards, >>>>>>> Vlad >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> This is the program >>>>>>> >>>>>>> -module('missing-comma-not-detected'). >>>>>>> >>>>>>> -export([data/1]). >>>>>>> >>>>>>> -compile(export_all). >>>>>>> >>>>>>> -record(shcnode, { >>>>>>> nodename :: any(), >>>>>>> y_axis :: number(), >>>>>>> children :: [any()], >>>>>>> article_number :: number(), >>>>>>> attribute_condition :: string()}). >>>>>>> >>>>>>> >>>>>>> data(1) -> >>>>>>> [ >>>>>>> #shcnode{nodename = start, y_axis = 0, children = >>>>>>> [d1285]}, >>>>>>> #shcnode{nodename = d1285, y_axis = 295, children = >>>>>>> [1939, >>>>>>> 1940]} >>>>>>> #shcnode{nodename = 1940, y_axis = 525, children = >>>>>>> [bm3203], >>>>>>> article_number = 14432861}, >>>>>>> #shcnode{nodename = 1939, y_axis = 530, children = >>>>>>> [bm3203], >>>>>>> article_number = 14432860}, >>>>>>> #shcnode{nodename = bm3203, y_axis = 915, children = []} >>>>>>> ]. >>>>>>> >>>>>>> >>>>>>> Note the missing "," after [1939, 1940]} >>>>>>> >>>>>>> Only 4 rows are detected >>>>>>> >>>>>>> length('missing-comma-not-detected':data(1)). >>>>>>> 4 >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> If I add the comma, I get >>>>>>> >>>>>>> length('missing-comma-not-detected':data(1)). >>>>>>> 5 >>>>>>> >>>>>>> ---- >>>>>>> >>>>>>> I am using Erlang 17.3 on ubuntu. >>>>>>> >>>>>>> erlang:system_info(otp_release). >>>>>>> "17" >>>>>>> >>>>>>> 36> |erl -V >>>>>>> Eshell V6.2 (abort with ^G) >>>>>>> 1> | >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Mattias >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> -- >>>>>> Lo????????c Hoguin >>>>>> http://ninenines.eu >>>>>> _______________________________________________ >>>>>> erlang-bugs mailing list >>>>>> erlang-bugs@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>> >>>>> >>>> -- >>>> Lo????c Hoguin >>>> http://ninenines.eu >>>> >>> >> -- >> Lo??c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > From roland.karlsson@REDACTED Sun Nov 9 11:40:44 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 09 Nov 2014 11:40:44 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: <93494073be6dda9f1323712611d792d5.squirrel@klotjohan.proxel.se> Message-ID: <20141109114042.90BF.69B9F832@proxel.se> On Sat, 8 Nov 2014 09:02:08 +0100 Mattias Waldau wrote: > Yes, I can agree that > > #rec{a=2}#rec{b=3} > > is a matter of opinion. However, I completely fail to understand how > > #rec{a=2}#rec{a=3} > > can be a matter of opinion, since data in the code is LOST. Data is not lost. The code creates a record rec with the field a being 2. Then the code creates a copy of that record where the field now is 3. The first record is instance not used though. But, as it has no name that usually do not give a warning in Erlang, just like unused variables with underscore names do not give a warning. But ... I can see why it might maybe be a warning there. It IS a matter of opinion though IMHO. You have to be aware of the following code though. (?MY_DEF_REC)#rec{a=3} Lets say the macro MY_DEF_REC creates a record rec with some special default values. Lets say that one of the fields you have a special default value for is a. Do you want a warning? /Roland > There should be a warning. My sample below shows how catastropic the missing "," can be. > > /mattias > > On 07/11/2014 13:22, Roland Karlsson wrote: > > Maybe we shall not discuss this for ever :) > > It is a matter of opinion after all. > > > > But - it is the same IMHO. It is a matter of operators and the need > > to set paranthesis when the precedents and right/left association is > > not obvious. > > > > The rec example can be written thus > > > > (#rec{a=2})#rec{b=3} > > > > Then everything is clear. > > > > > > /Roland > > > > > > > >> I'm not sure how that relates. This expression can be reasonably written > >> on purpose. The same cannot be said for #rec{a=2}#rec{b=3}. > >> > >> On 11/07/2014 02:01 PM, Roland Karlsson wrote: > >>> If there is a warning there, then all expressions including operators, > >>> e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ? > >>> Do you know the precedence of + and rem ? What is the result? > >>> > >>> /Roland > >>> > >>> > >>> > >>>> Warnings are ordinary Erlang code which is prone to errors. > >>>> > >>>> On 11/07/2014 01:46 PM, Roland Karlsson wrote: > >>>>> No warning is needed methinks. It is just ordinary Erlang code. > >>>>> It is equal to. > >>>>> > >>>>>> REC1 = #rec{b=3}. > >>>>>> REC2 = REC1#rec{a=2}. > >>>>> Nothing strange at all. > >>>>> > >>>>> > >>>>> /Roland > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> It is legal but there probably should be a warning for this > >>>>>> particular > >>>>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when > >>>>>> you > >>>>>> can just do #rec{a=2, b=3}. > >>>>>> > >>>>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: > >>>>>>> Hi Mattias, > >>>>>>> > >>>>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is > >>>>>>> the > >>>>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys > >>>>>>> overlap, then the last one "wins". > >>>>>>> > >>>>>>> best regards, > >>>>>>> Vlad > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau > >>>>>>> > > >>>>>>> wrote: > >>>>>>> > >>>>>>> This is the program > >>>>>>> > >>>>>>> -module('missing-comma-not-detected'). > >>>>>>> > >>>>>>> -export([data/1]). > >>>>>>> > >>>>>>> -compile(export_all). > >>>>>>> > >>>>>>> -record(shcnode, { > >>>>>>> nodename :: any(), > >>>>>>> y_axis :: number(), > >>>>>>> children :: [any()], > >>>>>>> article_number :: number(), > >>>>>>> attribute_condition :: string()}). > >>>>>>> > >>>>>>> > >>>>>>> data(1) -> > >>>>>>> [ > >>>>>>> #shcnode{nodename = start, y_axis = 0, children = > >>>>>>> [d1285]}, > >>>>>>> #shcnode{nodename = d1285, y_axis = 295, children = > >>>>>>> [1939, > >>>>>>> 1940]} > >>>>>>> #shcnode{nodename = 1940, y_axis = 525, children = > >>>>>>> [bm3203], > >>>>>>> article_number = 14432861}, > >>>>>>> #shcnode{nodename = 1939, y_axis = 530, children = > >>>>>>> [bm3203], > >>>>>>> article_number = 14432860}, > >>>>>>> #shcnode{nodename = bm3203, y_axis = 915, children = []} > >>>>>>> ]. > >>>>>>> > >>>>>>> > >>>>>>> Note the missing "," after [1939, 1940]} > >>>>>>> > >>>>>>> Only 4 rows are detected > >>>>>>> > >>>>>>> length('missing-comma-not-detected':data(1)). > >>>>>>> 4 > >>>>>>> > >>>>>>> --- > >>>>>>> > >>>>>>> If I add the comma, I get > >>>>>>> > >>>>>>> length('missing-comma-not-detected':data(1)). > >>>>>>> 5 > >>>>>>> > >>>>>>> ---- > >>>>>>> > >>>>>>> I am using Erlang 17.3 on ubuntu. > >>>>>>> > >>>>>>> erlang:system_info(otp_release). > >>>>>>> "17" > >>>>>>> > >>>>>>> 36> |erl -V > >>>>>>> Eshell V6.2 (abort with ^G) > >>>>>>> 1> | > >>>>>>> > >>>>>>> --- > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Mattias > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>>>> > >>>>>> -- > >>>>>> Lo????c Hoguin > >>>>>> http://ninenines.eu > >>>>>> _______________________________________________ > >>>>>> erlang-bugs mailing list > >>>>>> erlang-bugs@REDACTED > >>>>>> http://erlang.org/mailman/listinfo/erlang-bugs > >>>>>> > >>>>> > >>>> -- > >>>> Lo??c Hoguin > >>>> http://ninenines.eu > >>>> > >>> > >> -- > >> Lo?c Hoguin > >> http://ninenines.eu > >> _______________________________________________ > >> 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 -- Roland Karlsson From essen@REDACTED Sun Nov 9 11:49:41 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 09 Nov 2014 12:49:41 +0200 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <20141109114042.90BF.69B9F832@proxel.se> References: <93494073be6dda9f1323712611d792d5.squirrel@klotjohan.proxel.se> <20141109114042.90BF.69B9F832@proxel.se> Message-ID: <545F46C5.2040009@ninenines.eu> On 11/09/2014 12:40 PM, Roland Karlsson wrote: > > On Sat, 8 Nov 2014 09:02:08 +0100 > Mattias Waldau wrote: > >> Yes, I can agree that >> >> #rec{a=2}#rec{b=3} >> >> is a matter of opinion. However, I completely fail to understand how >> >> #rec{a=2}#rec{a=3} >> >> can be a matter of opinion, since data in the code is LOST. > > Data is not lost. > The code creates a record rec with the field a being 2. > Then the code creates a copy of that record where the field now is 3. > The first record is instance not used though. But, as it has no name > that usually do not give a warning in Erlang, just like unused variables > with underscore names do not give a warning. > > But ... I can see why it might maybe be a warning there. > It IS a matter of opinion though IMHO. When I said it needs a warning earlier in the thread, I meant one you can set optionally, similar to +warn_export_all. Regardless of the contents of the record. You have to program in a very specific way to be annoyed by that kind of warning though. > You have to be aware of the following code though. > > (?MY_DEF_REC)#rec{a=3} > > Lets say the macro MY_DEF_REC creates a record rec with some > special default values. Lets say that one of the fields you have a > special default value for is a. Do you want a warning? And that would be one such way... though my heart would skip a beat seeing code like this. Most people simply do not write code that ends up as #rec{...}#rec{...}, and could very much benefit from a warning that avoids this error. Others can simply choose not to enable it. > /Roland > > > > > > > > >> There should be a warning. My sample below shows how catastropic the missing "," can be. >> >> /mattias >> >> On 07/11/2014 13:22, Roland Karlsson wrote: >>> Maybe we shall not discuss this for ever :) >>> It is a matter of opinion after all. >>> >>> But - it is the same IMHO. It is a matter of operators and the need >>> to set paranthesis when the precedents and right/left association is >>> not obvious. >>> >>> The rec example can be written thus >>> >>> (#rec{a=2})#rec{b=3} >>> >>> Then everything is clear. >>> >>> >>> /Roland >>> >>> >>> >>>> I'm not sure how that relates. This expression can be reasonably written >>>> on purpose. The same cannot be said for #rec{a=2}#rec{b=3}. >>>> >>>> On 11/07/2014 02:01 PM, Roland Karlsson wrote: >>>>> If there is a warning there, then all expressions including operators, >>>>> e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ? >>>>> Do you know the precedence of + and rem ? What is the result? >>>>> >>>>> /Roland >>>>> >>>>> >>>>> >>>>>> Warnings are ordinary Erlang code which is prone to errors. >>>>>> >>>>>> On 11/07/2014 01:46 PM, Roland Karlsson wrote: >>>>>>> No warning is needed methinks. It is just ordinary Erlang code. >>>>>>> It is equal to. >>>>>>> >>>>>>>> REC1 = #rec{b=3}. >>>>>>>> REC2 = REC1#rec{a=2}. >>>>>>> Nothing strange at all. >>>>>>> >>>>>>> >>>>>>> /Roland >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is legal but there probably should be a warning for this >>>>>>>> particular >>>>>>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when >>>>>>>> you >>>>>>>> can just do #rec{a=2, b=3}. >>>>>>>> >>>>>>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: >>>>>>>>> Hi Mattias, >>>>>>>>> >>>>>>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is >>>>>>>>> the >>>>>>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys >>>>>>>>> overlap, then the last one "wins". >>>>>>>>> >>>>>>>>> best regards, >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> This is the program >>>>>>>>> >>>>>>>>> -module('missing-comma-not-detected'). >>>>>>>>> >>>>>>>>> -export([data/1]). >>>>>>>>> >>>>>>>>> -compile(export_all). >>>>>>>>> >>>>>>>>> -record(shcnode, { >>>>>>>>> nodename :: any(), >>>>>>>>> y_axis :: number(), >>>>>>>>> children :: [any()], >>>>>>>>> article_number :: number(), >>>>>>>>> attribute_condition :: string()}). >>>>>>>>> >>>>>>>>> >>>>>>>>> data(1) -> >>>>>>>>> [ >>>>>>>>> #shcnode{nodename = start, y_axis = 0, children = >>>>>>>>> [d1285]}, >>>>>>>>> #shcnode{nodename = d1285, y_axis = 295, children = >>>>>>>>> [1939, >>>>>>>>> 1940]} >>>>>>>>> #shcnode{nodename = 1940, y_axis = 525, children = >>>>>>>>> [bm3203], >>>>>>>>> article_number = 14432861}, >>>>>>>>> #shcnode{nodename = 1939, y_axis = 530, children = >>>>>>>>> [bm3203], >>>>>>>>> article_number = 14432860}, >>>>>>>>> #shcnode{nodename = bm3203, y_axis = 915, children = []} >>>>>>>>> ]. >>>>>>>>> >>>>>>>>> >>>>>>>>> Note the missing "," after [1939, 1940]} >>>>>>>>> >>>>>>>>> Only 4 rows are detected >>>>>>>>> >>>>>>>>> length('missing-comma-not-detected':data(1)). >>>>>>>>> 4 >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> If I add the comma, I get >>>>>>>>> >>>>>>>>> length('missing-comma-not-detected':data(1)). >>>>>>>>> 5 >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> I am using Erlang 17.3 on ubuntu. >>>>>>>>> >>>>>>>>> erlang:system_info(otp_release). >>>>>>>>> "17" >>>>>>>>> >>>>>>>>> 36> |erl -V >>>>>>>>> Eshell V6.2 (abort with ^G) >>>>>>>>> 1> | >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Mattias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>>> >>>>>>>> -- >>>>>>>> Lo????c Hoguin >>>>>>>> http://ninenines.eu >>>>>>>> _______________________________________________ >>>>>>>> erlang-bugs mailing list >>>>>>>> erlang-bugs@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Lo??c Hoguin >>>>>> http://ninenines.eu >>>>>> >>>>> >>>> -- >>>> Lo?c Hoguin >>>> http://ninenines.eu >>>> _______________________________________________ >>>> 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 > -- Lo?c Hoguin http://ninenines.eu From roland.karlsson@REDACTED Sun Nov 9 12:19:55 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 09 Nov 2014 12:19:55 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <545F46C5.2040009@ninenines.eu> References: <20141109114042.90BF.69B9F832@proxel.se> <545F46C5.2040009@ninenines.eu> Message-ID: <20141109121953.90C3.69B9F832@proxel.se> I think you are mixing two things here. You want a warning for the usage of #rec{}#rec{}. Mattias wanted a warning when "data was lost". Those are two different reasons for a warning. I answered Mattias in my post. Generally Erlang do not warn you if you have underscore variables or anonymous terms (in expressions) that are later not used. So - the warning Mattias wanted do break common rules in the Erlang compilator. The general #rec{}#rec{} warning is a bit more complicated. Just writing it is maybe a bit strange and maybe a warning might be in place. But - the macro usage I gave is quite legit I think and not so horrible at all. And ... I do not know if a warning that depends on it being a macro or not is a clever idea. /Roland On Sun, 09 Nov 2014 12:49:41 +0200 Lo?c Hoguin wrote: > > > On 11/09/2014 12:40 PM, Roland Karlsson wrote: > > > > On Sat, 8 Nov 2014 09:02:08 +0100 > > Mattias Waldau wrote: > > > >> Yes, I can agree that > >> > >> #rec{a=2}#rec{b=3} > >> > >> is a matter of opinion. However, I completely fail to understand how > >> > >> #rec{a=2}#rec{a=3} > >> > >> can be a matter of opinion, since data in the code is LOST. > > > > Data is not lost. > > The code creates a record rec with the field a being 2. > > Then the code creates a copy of that record where the field now is 3. > > The first record is instance not used though. But, as it has no name > > that usually do not give a warning in Erlang, just like unused variables > > with underscore names do not give a warning. > > > > But ... I can see why it might maybe be a warning there. > > It IS a matter of opinion though IMHO. > > When I said it needs a warning earlier in the thread, I meant one you can set optionally, similar to +warn_export_all. Regardless of the contents of the record. You have to program in a very specific way to be annoyed by that kind of warning though. > > > You have to be aware of the following code though. > > > > (?MY_DEF_REC)#rec{a=3} > > > > Lets say the macro MY_DEF_REC creates a record rec with some > > special default values. Lets say that one of the fields you have a > > special default value for is a. Do you want a warning? > > And that would be one such way... though my heart would skip a beat seeing code like this. > > Most people simply do not write code that ends up as #rec{...}#rec{...}, and could very much benefit from a warning that avoids this error. Others can simply choose not to enable it. > > > /Roland > > > > > > > > > > > > > > > > > >> There should be a warning. My sample below shows how catastropic the missing "," can be. > >> > >> /mattias > >> > >> On 07/11/2014 13:22, Roland Karlsson wrote: > >>> Maybe we shall not discuss this for ever :) > >>> It is a matter of opinion after all. > >>> > >>> But - it is the same IMHO. It is a matter of operators and the need > >>> to set paranthesis when the precedents and right/left association is > >>> not obvious. > >>> > >>> The rec example can be written thus > >>> > >>> (#rec{a=2})#rec{b=3} > >>> > >>> Then everything is clear. > >>> > >>> > >>> /Roland > >>> > >>> > >>> > >>>> I'm not sure how that relates. This expression can be reasonably written > >>>> on purpose. The same cannot be said for #rec{a=2}#rec{b=3}. > >>>> > >>>> On 11/07/2014 02:01 PM, Roland Karlsson wrote: > >>>>> If there is a warning there, then all expressions including operators, > >>>>> e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ? > >>>>> Do you know the precedence of + and rem ? What is the result? > >>>>> > >>>>> /Roland > >>>>> > >>>>> > >>>>> > >>>>>> Warnings are ordinary Erlang code which is prone to errors. > >>>>>> > >>>>>> On 11/07/2014 01:46 PM, Roland Karlsson wrote: > >>>>>>> No warning is needed methinks. It is just ordinary Erlang code. > >>>>>>> It is equal to. > >>>>>>> > >>>>>>>> REC1 = #rec{b=3}. > >>>>>>>> REC2 = REC1#rec{a=2}. > >>>>>>> Nothing strange at all. > >>>>>>> > >>>>>>> > >>>>>>> /Roland > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> It is legal but there probably should be a warning for this > >>>>>>>> particular > >>>>>>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when > >>>>>>>> you > >>>>>>>> can just do #rec{a=2, b=3}. > >>>>>>>> > >>>>>>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: > >>>>>>>>> Hi Mattias, > >>>>>>>>> > >>>>>>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is > >>>>>>>>> the > >>>>>>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys > >>>>>>>>> overlap, then the last one "wins". > >>>>>>>>> > >>>>>>>>> best regards, > >>>>>>>>> Vlad > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau > >>>>>>>>> > > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> This is the program > >>>>>>>>> > >>>>>>>>> -module('missing-comma-not-detected'). > >>>>>>>>> > >>>>>>>>> -export([data/1]). > >>>>>>>>> > >>>>>>>>> -compile(export_all). > >>>>>>>>> > >>>>>>>>> -record(shcnode, { > >>>>>>>>> nodename :: any(), > >>>>>>>>> y_axis :: number(), > >>>>>>>>> children :: [any()], > >>>>>>>>> article_number :: number(), > >>>>>>>>> attribute_condition :: string()}). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> data(1) -> > >>>>>>>>> [ > >>>>>>>>> #shcnode{nodename = start, y_axis = 0, children = > >>>>>>>>> [d1285]}, > >>>>>>>>> #shcnode{nodename = d1285, y_axis = 295, children = > >>>>>>>>> [1939, > >>>>>>>>> 1940]} > >>>>>>>>> #shcnode{nodename = 1940, y_axis = 525, children = > >>>>>>>>> [bm3203], > >>>>>>>>> article_number = 14432861}, > >>>>>>>>> #shcnode{nodename = 1939, y_axis = 530, children = > >>>>>>>>> [bm3203], > >>>>>>>>> article_number = 14432860}, > >>>>>>>>> #shcnode{nodename = bm3203, y_axis = 915, children = []} > >>>>>>>>> ]. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Note the missing "," after [1939, 1940]} > >>>>>>>>> > >>>>>>>>> Only 4 rows are detected > >>>>>>>>> > >>>>>>>>> length('missing-comma-not-detected':data(1)). > >>>>>>>>> 4 > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> If I add the comma, I get > >>>>>>>>> > >>>>>>>>> length('missing-comma-not-detected':data(1)). > >>>>>>>>> 5 > >>>>>>>>> > >>>>>>>>> ---- > >>>>>>>>> > >>>>>>>>> I am using Erlang 17.3 on ubuntu. > >>>>>>>>> > >>>>>>>>> erlang:system_info(otp_release). > >>>>>>>>> "17" > >>>>>>>>> > >>>>>>>>> 36> |erl -V > >>>>>>>>> Eshell V6.2 (abort with ^G) > >>>>>>>>> 1> | > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Mattias > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>>>> > >>>>>>>> -- > >>>>>>>> Lo????c Hoguin > >>>>>>>> http://ninenines.eu > >>>>>>>> _______________________________________________ > >>>>>>>> erlang-bugs mailing list > >>>>>>>> erlang-bugs@REDACTED > >>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs > >>>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> Lo??c Hoguin > >>>>>> http://ninenines.eu > >>>>>> > >>>>> > >>>> -- > >>>> Lo?c Hoguin > >>>> http://ninenines.eu > >>>> _______________________________________________ > >>>> 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 > > > > -- Lo?c Hoguin > http://ninenines.eu -- Roland Karlsson From essen@REDACTED Sun Nov 9 12:45:57 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 09 Nov 2014 13:45:57 +0200 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <20141109121953.90C3.69B9F832@proxel.se> References: <20141109114042.90BF.69B9F832@proxel.se> <545F46C5.2040009@ninenines.eu> <20141109121953.90C3.69B9F832@proxel.se> Message-ID: <545F53F5.6020109@ninenines.eu> On 11/09/2014 01:19 PM, Roland Karlsson wrote: > I think you are mixing two things here. I was clarifying my position as I was not sure you understood I wanted an optional warning (doesn't affect you if you don't enable it, so why be against it?) as opposed to one enabled by default. > Generally Erlang do not warn you if you have underscore > variables or anonymous terms (in expressions) that are > later not used. So - the warning Mattias wanted do break > common rules in the Erlang compilator. If these are the rules then where are they written? From what I know warnings were added to prevent people from writing "bad" code (quoted because it goes from preventing potential bugs to subjective reasons). There is no rule that would prevent adding a warning that prevents potential bugs. > The general #rec{}#rec{} warning is a bit more complicated. > Just writing it is maybe a bit strange and maybe a warning > might be in place. But - the macro usage I gave is quite legit I > think and not so horrible at all. And ... I do not know if a warning > that depends on it being a macro or not is a clever idea. The macro usage you gave is legal but not wise and quite uncommon to say the least. Regardless of any weird legal usage there may be, adding an *optional* warning will not change anything for people who write their code this way as the warning needs to be enabled explicitly. On the other hand it is immensely useful for everyone else. > /Roland > > > > > On Sun, 09 Nov 2014 12:49:41 +0200 > Lo?c Hoguin wrote: > >> >> >> On 11/09/2014 12:40 PM, Roland Karlsson wrote: >>> >>> On Sat, 8 Nov 2014 09:02:08 +0100 >>> Mattias Waldau wrote: >>> >>>> Yes, I can agree that >>>> >>>> #rec{a=2}#rec{b=3} >>>> >>>> is a matter of opinion. However, I completely fail to understand how >>>> >>>> #rec{a=2}#rec{a=3} >>>> >>>> can be a matter of opinion, since data in the code is LOST. >>> >>> Data is not lost. >>> The code creates a record rec with the field a being 2. >>> Then the code creates a copy of that record where the field now is 3. >>> The first record is instance not used though. But, as it has no name >>> that usually do not give a warning in Erlang, just like unused variables >>> with underscore names do not give a warning. >>> >>> But ... I can see why it might maybe be a warning there. >>> It IS a matter of opinion though IMHO. >> >> When I said it needs a warning earlier in the thread, I meant one you can set optionally, similar to +warn_export_all. Regardless of the contents of the record. You have to program in a very specific way to be annoyed by that kind of warning though. >> >>> You have to be aware of the following code though. >>> >>> (?MY_DEF_REC)#rec{a=3} >>> >>> Lets say the macro MY_DEF_REC creates a record rec with some >>> special default values. Lets say that one of the fields you have a >>> special default value for is a. Do you want a warning? >> >> And that would be one such way... though my heart would skip a beat seeing code like this. >> >> Most people simply do not write code that ends up as #rec{...}#rec{...}, and could very much benefit from a warning that avoids this error. Others can simply choose not to enable it. >> >>> /Roland >>> >>> >>> >>> >>> >>> >>> >>> >>>> There should be a warning. My sample below shows how catastropic the missing "," can be. >>>> >>>> /mattias >>>> >>>> On 07/11/2014 13:22, Roland Karlsson wrote: >>>>> Maybe we shall not discuss this for ever :) >>>>> It is a matter of opinion after all. >>>>> >>>>> But - it is the same IMHO. It is a matter of operators and the need >>>>> to set paranthesis when the precedents and right/left association is >>>>> not obvious. >>>>> >>>>> The rec example can be written thus >>>>> >>>>> (#rec{a=2})#rec{b=3} >>>>> >>>>> Then everything is clear. >>>>> >>>>> >>>>> /Roland >>>>> >>>>> >>>>> >>>>>> I'm not sure how that relates. This expression can be reasonably written >>>>>> on purpose. The same cannot be said for #rec{a=2}#rec{b=3}. >>>>>> >>>>>> On 11/07/2014 02:01 PM, Roland Karlsson wrote: >>>>>>> If there is a warning there, then all expressions including operators, >>>>>>> e.g. arithmetic, should have warnings. How about 10 + 1 rem 3 + 7. ? >>>>>>> Do you know the precedence of + and rem ? What is the result? >>>>>>> >>>>>>> /Roland >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Warnings are ordinary Erlang code which is prone to errors. >>>>>>>> >>>>>>>> On 11/07/2014 01:46 PM, Roland Karlsson wrote: >>>>>>>>> No warning is needed methinks. It is just ordinary Erlang code. >>>>>>>>> It is equal to. >>>>>>>>> >>>>>>>>>> REC1 = #rec{b=3}. >>>>>>>>>> REC2 = REC1#rec{a=2}. >>>>>>>>> Nothing strange at all. >>>>>>>>> >>>>>>>>> >>>>>>>>> /Roland >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> It is legal but there probably should be a warning for this >>>>>>>>>> particular >>>>>>>>>> case. I cannot think of a valid reason to do #rec{a=2}#rec{b=3} when >>>>>>>>>> you >>>>>>>>>> can just do #rec{a=2, b=3}. >>>>>>>>>> >>>>>>>>>> On 11/07/2014 10:09 AM, Vlad Dumitrescu wrote: >>>>>>>>>>> Hi Mattias, >>>>>>>>>>> >>>>>>>>>>> This isn't a bug. The expression #rec{a=2}#rec{b=3} is legal, and is >>>>>>>>>>> the >>>>>>>>>>> same thing as (#rec{a=2})#rec{b=3} or #rec{a=2,b=3}. If the keys >>>>>>>>>>> overlap, then the last one "wins". >>>>>>>>>>> >>>>>>>>>>> best regards, >>>>>>>>>>> Vlad >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Nov 6, 2014 at 9:21 AM, Mattias Waldau >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> This is the program >>>>>>>>>>> >>>>>>>>>>> -module('missing-comma-not-detected'). >>>>>>>>>>> >>>>>>>>>>> -export([data/1]). >>>>>>>>>>> >>>>>>>>>>> -compile(export_all). >>>>>>>>>>> >>>>>>>>>>> -record(shcnode, { >>>>>>>>>>> nodename :: any(), >>>>>>>>>>> y_axis :: number(), >>>>>>>>>>> children :: [any()], >>>>>>>>>>> article_number :: number(), >>>>>>>>>>> attribute_condition :: string()}). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> data(1) -> >>>>>>>>>>> [ >>>>>>>>>>> #shcnode{nodename = start, y_axis = 0, children = >>>>>>>>>>> [d1285]}, >>>>>>>>>>> #shcnode{nodename = d1285, y_axis = 295, children = >>>>>>>>>>> [1939, >>>>>>>>>>> 1940]} >>>>>>>>>>> #shcnode{nodename = 1940, y_axis = 525, children = >>>>>>>>>>> [bm3203], >>>>>>>>>>> article_number = 14432861}, >>>>>>>>>>> #shcnode{nodename = 1939, y_axis = 530, children = >>>>>>>>>>> [bm3203], >>>>>>>>>>> article_number = 14432860}, >>>>>>>>>>> #shcnode{nodename = bm3203, y_axis = 915, children = []} >>>>>>>>>>> ]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note the missing "," after [1939, 1940]} >>>>>>>>>>> >>>>>>>>>>> Only 4 rows are detected >>>>>>>>>>> >>>>>>>>>>> length('missing-comma-not-detected':data(1)). >>>>>>>>>>> 4 >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> If I add the comma, I get >>>>>>>>>>> >>>>>>>>>>> length('missing-comma-not-detected':data(1)). >>>>>>>>>>> 5 >>>>>>>>>>> >>>>>>>>>>> ---- >>>>>>>>>>> >>>>>>>>>>> I am using Erlang 17.3 on ubuntu. >>>>>>>>>>> >>>>>>>>>>> erlang:system_info(otp_release). >>>>>>>>>>> "17" >>>>>>>>>>> >>>>>>>>>>> 36> |erl -V >>>>>>>>>>> Eshell V6.2 (abort with ^G) >>>>>>>>>>> 1> | >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Mattias >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lo????c Hoguin >>>>>>>>>> http://ninenines.eu >>>>>>>>>> _______________________________________________ >>>>>>>>>> erlang-bugs mailing list >>>>>>>>>> erlang-bugs@REDACTED >>>>>>>>>> http://erlang.org/mailman/listinfo/erlang-bugs >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Lo??c Hoguin >>>>>>>> http://ninenines.eu >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Lo?c Hoguin >>>>>> http://ninenines.eu >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> -- Lo?c Hoguin >> http://ninenines.eu > -- Lo?c Hoguin http://ninenines.eu From mattias.waldau@REDACTED Sun Nov 9 13:23:59 2014 From: mattias.waldau@REDACTED (Mattias Waldau) Date: Sun, 9 Nov 2014 13:23:59 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <545F53F5.6020109@ninenines.eu> References: <20141109114042.90BF.69B9F832@proxel.se> <545F46C5.2040009@ninenines.eu> <20141109121953.90C3.69B9F832@proxel.se> <545F53F5.6020109@ninenines.eu> Message-ID: Hi All, I think the discussion went overboard. I made a small typo, forgetting a single comma in a static list. I know realize that #rec{}#rec{} is correct syntax, and I do not understand why it should be. Why not just say that it isn't ok? Who needs this syntax, except a advanced macro? /mattias From roland.karlsson@REDACTED Sun Nov 9 14:02:14 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 09 Nov 2014 14:02:14 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: <545F53F5.6020109@ninenines.eu> Message-ID: <20141109140212.90C7.69B9F832@proxel.se> Hi Mattias and Lo?c. That #rec{}#rec{} is correct syntax is a result of how operators work. Making it not correct syntax needs a special treatment of this case. Which should be weird. Even more weird if it would be correct syntax in "advanced macros" only. Having a warning is another issue, warnings are based on heuristics and opinions. Lo?c - have you seen a warning if you e.g. write A*B+C ? This expression (in principle) takes A*B, creating an unnamed variable. This unnamed variable is then added with C. Have you seen any warnings that this unnamed variable is unused? The same goes for #rec{}#rec{}. The first #rec{} creates an unnamed record of type rec. The second #rec{} modifies the unnamed record. You might not like the record syntax, and find the #rec{}#rec{} unreadable - but it is very clear what it does. BTW - the bit syntax and list comprehensions are even more hairy. Now, I am not a part of the OTP group or developing Erlang syntax, so it feels a bit awkward to defend it and be forced to come with motivations and proofs for being right. So - this is my last post on this subject. /Roland On Sun, 9 Nov 2014 13:23:59 +0100 Mattias Waldau wrote: > Hi All, > > I think the discussion went overboard. I made a small typo, forgetting a single comma in a static list. > > I know realize that > > #rec{}#rec{} > > is correct syntax, and I do not understand why it should be. > > Why not just say that it isn't ok? Who needs this syntax, except a advanced macro? > > /mattias -- Roland Karlsson From essen@REDACTED Sun Nov 9 14:09:32 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sun, 09 Nov 2014 15:09:32 +0200 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <20141109140212.90C7.69B9F832@proxel.se> References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> Message-ID: <545F678C.2070101@ninenines.eu> There are already warnings on otherwise correct syntax. Syntax being correct is why they are warnings and not errors. +warn_export_vars and +warn_shadow_vars are the most obvious examples. I also want to note in addition to everything I mentioned that if such a warning is introduced, it needs to apply to both records and maps, as they both suffer from the same syntactic fragility. On 11/09/2014 03:02 PM, Roland Karlsson wrote: > Hi Mattias and Lo?c. > > That #rec{}#rec{} is correct syntax is a result of how operators work. > Making it not correct syntax needs a special treatment of this case. > Which should be weird. Even more weird if it would be correct syntax in > "advanced macros" only. > > Having a warning is another issue, warnings are based on heuristics > and opinions. > > Lo?c - have you seen a warning if you e.g. write A*B+C ? > This expression (in principle) takes A*B, creating an unnamed > variable. This unnamed variable is then added with C. Have you > seen any warnings that this unnamed variable is unused? > The same goes for #rec{}#rec{}. The first #rec{} creates an > unnamed record of type rec. The second #rec{} modifies > the unnamed record. You might not like the record syntax, and find > the #rec{}#rec{} unreadable - but it is very clear what it does. > BTW - the bit syntax and list comprehensions are even more hairy. > > Now, I am not a part of the OTP group or developing Erlang syntax, so > it feels a bit awkward to defend it and be forced to come with > motivations and proofs for being right. > > So - this is my last post on this subject. > > > /Roland > > > > > On Sun, 9 Nov 2014 13:23:59 +0100 > Mattias Waldau wrote: > >> Hi All, >> >> I think the discussion went overboard. I made a small typo, forgetting a single comma in a static list. >> >> I know realize that >> >> #rec{}#rec{} >> >> is correct syntax, and I do not understand why it should be. >> >> Why not just say that it isn't ok? Who needs this syntax, except a advanced macro? >> >> /mattias > -- Lo?c Hoguin http://ninenines.eu From mattias.waldau@REDACTED Sun Nov 9 14:27:12 2014 From: mattias.waldau@REDACTED (Mattias Waldau) Date: Sun, 9 Nov 2014 14:27:12 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <545F678C.2070101@ninenines.eu> References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> Message-ID: Thank you Loic and Roland for the explanations, I really appreciate it. The trick to understand why this is and should be ok is that #{} is n operator and then it makes sense. Then, there is another question why #{} is an operator. This is what the Erlang reference manual says about record creation, it doesn't mention #rec{}#rec{} So, until you explained, I just thought is was a parser bug. /mattias 10.2 Creating Records The following expression creates a new Name record where the value of each field FieldI is the value of evaluating the corresponding expression ExprI: #Name{Field1=Expr1,...,FieldK=ExprK} The fields may be in any order, not necessarily the same order as in the record definition, and fields can be omitted. Omitted fields will get their respective default value instead. If several fields should be assigned the same value, the following construction can be used: #Name{Field1=Expr1,...,FieldK=ExprK, _=ExprL} Omitted fields will then get the value of evaluating ExprL instead of their default values. This feature was added in Erlang 5.1/OTP R8 and is primarily intended to be used to create patterns for ETS and Mnesia match functions. Example: -record(person, {name, phone, address}). ... lookup(Name, Tab) -> ets:match_object(Tab, #person{name=Name, _='_'}). /mattias On 09/11/2014 14:09, Lo?c Hoguin wrote: > There are already warnings on otherwise correct syntax. Syntax being > correct is why they are warnings and not errors. +warn_export_vars and > +warn_shadow_vars are the most obvious examples. > > I also want to note in addition to everything I mentioned that if such a > warning is introduced, it needs to apply to both records and maps, as > they both suffer from the same syntactic fragility. > > On 11/09/2014 03:02 PM, Roland Karlsson wrote: >> Hi Mattias and Lo?c. >> >> That #rec{}#rec{} is correct syntax is a result of how operators work. >> Making it not correct syntax needs a special treatment of this case. >> Which should be weird. Even more weird if it would be correct syntax in >> "advanced macros" only. >> >> Having a warning is another issue, warnings are based on heuristics >> and opinions. >> >> Lo?c - have you seen a warning if you e.g. write A*B+C ? >> This expression (in principle) takes A*B, creating an unnamed >> variable. This unnamed variable is then added with C. Have you >> seen any warnings that this unnamed variable is unused? >> The same goes for #rec{}#rec{}. The first #rec{} creates an >> unnamed record of type rec. The second #rec{} modifies >> the unnamed record. You might not like the record syntax, and find >> the #rec{}#rec{} unreadable - but it is very clear what it does. >> BTW - the bit syntax and list comprehensions are even more hairy. >> >> Now, I am not a part of the OTP group or developing Erlang syntax, so >> it feels a bit awkward to defend it and be forced to come with >> motivations and proofs for being right. >> >> So - this is my last post on this subject. >> >> >> /Roland >> >> >> >> >> On Sun, 9 Nov 2014 13:23:59 +0100 >> Mattias Waldau wrote: >> >>> Hi All, >>> >>> I think the discussion went overboard. I made a small typo, forgetting a single comma in a static list. >>> >>> I know realize that >>> >>> #rec{}#rec{} >>> >>> is correct syntax, and I do not understand why it should be. >>> >>> Why not just say that it isn't ok? Who needs this syntax, except a advanced macro? >>> >>> /mattias -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattias.waldau@REDACTED Sun Nov 9 16:48:33 2014 From: mattias.waldau@REDACTED (Mattias Waldau) Date: Sun, 9 Nov 2014 16:48:33 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <545F6BB0.7080604@outlook.com> References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> <545F6BB0.7080604@outlook.com> Message-ID: Forget the comment below. After talking to a friend, I at last understood why this is ok. In the expression #{}#{}, the first #{} is the record creation, and the 2nd #{} is record copying, so in Erlang, the same syntax is used for 2 separate things. For example in Ocaml, you use {X with ..} Thanks for the help. Yes, this is not a bug. /mattias On 09/11/2014 14:27, Mattias Waldau wrote: > Thank you Loic and Roland for the explanations, I really appreciate it. > > The trick to understand why this is and should be ok is that #{} is n > operator and then it makes sense. Then, there is another question why > #{} is an operator. > > This is what the Erlang reference manual says about record creation, > it doesn't mention #rec{}#rec{} > > So, until you explained, I just thought is was a parser bug. > > /mattias > > > 10.2 Creating Records > > The following expression creates a new Name record where the value of > each field FieldI is the value of evaluating the corresponding > expression ExprI: > > #Name{Field1=Expr1,...,FieldK=ExprK} > > The fields may be in any order, not necessarily the same order as in > the record definition, and fields can be omitted. Omitted fields will > get their respective default value instead. > > If several fields should be assigned the same value, the following > construction can be used: > > #Name{Field1=Expr1,...,FieldK=ExprK, _=ExprL} > > Omitted fields will then get the value of evaluating ExprL instead of > their default values. This feature was added in Erlang 5.1/OTP R8 and > is primarily intended to be used to create patterns for ETS and Mnesia > match functions. Example: > > -record(person, {name, phone, address}). > > ... > > lookup(Name, Tab) -> > ets:match_object(Tab, #person{name=Name, _='_'}). > > > /mattias > > > On 09/11/2014 14:09, Lo?c Hoguin wrote:at >> There are already warnings on otherwise correct syntax. Syntax being >> correct is why they are warnings and not errors. +warn_export_vars and >> +warn_shadow_vars are the most obvious examples. >> >> I also want to note in addition to everything I mentioned that if such a >> warning is introduced, it needs to apply to both records and maps, as >> they both suffer from the same syntactic fragility. >> >> On 11/09/2014 03:02 PM, Roland Karlsson wrote: >>> Hi Mattias and Lo?c. >>> >>> That #rec{}#rec{} is correct syntax is a result of how operators work. >>> Making it not correct syntax needs a special treatment of this case. >>> Which should be weird. Even more weird if it would be correct syntax in >>> "advanced macros" only. >>> >>> Having a warning is another issue, warnings are based on heuristics >>> and opinions. >>> >>> Lo?c - have you seen a warning if you e.g. write A*B+C ? >>> This expression (in principle) takes A*B, creating an unnamed >>> variable. This unnamed variable is then added with C. Have you >>> seen any warnings that this unnamed variable is unused? >>> The same goes for #rec{}#rec{}. The first #rec{} creates an >>> unnamed record of type rec. The second #rec{} modifies >>> the unnamed record. You might not like the record syntax, and find >>> the #rec{}#rec{} unreadable - but it is very clear what it does. >>> BTW - the bit syntax and list comprehensions are even more hairy. >>> >>> Now, I am not a part of the OTP group or developing Erlang syntax, so >>> it feels a bit awkward to defend it and be forced to come with >>> motivations and proofs for being right. >>> >>> So - this is my last post on this subject. >>> >>> >>> /Roland >>> >>> >>> >>> >>> On Sun, 9 Nov 2014 13:23:59 +0100 >>> Mattias Waldau wrote: >>> >>>> Hi All, >>>> >>>> I think the discussion went overboard. I made a small typo, forgetting a single comma in a static list. >>>> >>>> I know realize that >>>> >>>> #rec{}#rec{} >>>> >>>> is correct syntax, and I do not understand why it should be. >>>> >>>> Why not just say that it isn't ok? Who needs this syntax, except a advanced macro? >>>> >>>> /mattias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Mon Nov 10 12:31:47 2014 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 10 Nov 2014 11:31:47 +0000 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: (Mattias Waldau's message of "Sun, 9 Nov 2014 14:27:12 +0100") References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> Message-ID: Mattias Waldau writes: > Thank you Loic and Roland for the explanations, I really appreciate it. > > The trick to understand why this is and should be ok is that #{} is n > operator and then it makes sense. Then, there is another question why > #{} is an operator. > > This is what the Erlang reference manual says about record creation, it > doesn't mention #rec{}#rec{} > > So, until you explained, I just thought is was a parser bug. This syntax used to be disallowed. The "Nested records" section of the Records chapter of the reference manual mentions a new feature in R14: Before R14 you would have needed to use parentheses as following: "nested0" = ((N2#nrec2.nrec1)#nrec1.nrec0)#nrec0.name, N0n = ((N2#nrec2.nrec1)#nrec1.nrec0)#nrec0{name = "nested0a"}, Since R14 you can also write: "nested0" = N2#nrec2.nrec1#nrec1.nrec0#nrec0.name, N0n = N2#nrec2.nrec1#nrec1.nrec0#nrec0{name = "nested0a"}, As an unintended(?) consequence, this also made the #rec{}#rec{} syntax valid. Regards, Magnus From eric.pailleau@REDACTED Tue Nov 11 23:40:24 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Tue, 11 Nov 2014 23:40:24 +0100 Subject: [erlang-bugs] Missing return values for mnesia:subscribe/1 in documentation Message-ID: <54629058.4080105@wanadoo.fr> Hi, I found that in online documentation is missing possible returned values of mnesia:subscribe/1 . By trying, looks like {ok, nodes()} when OK, but what on error ? I cannot see more info in User's Guide either ... ---8<------------------------------------------------------------------------------ subscribe(EventCategory) Ensures that a copy of all events of type EventCategory are sent to the caller. The event types available are described in the Mnesia User's Guide. ---8<------------------------------------------------------------------------------ Regards. From dns@REDACTED Tue Nov 11 23:59:04 2014 From: dns@REDACTED (Davery) Date: Wed, 12 Nov 2014 06:59:04 +0800 Subject: [erlang-bugs] bug ? Message-ID: hi there: Winxp sp3 Erlang 17.3 -- have a good day. Regards, Davery -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ll.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: l2.txt URL: From eric.meadows.jonsson@REDACTED Wed Nov 12 01:02:56 2014 From: eric.meadows.jonsson@REDACTED (=?UTF-8?Q?Eric_Meadows=2DJ=C3=B6nsson?=) Date: Wed, 12 Nov 2014 01:02:56 +0100 Subject: [erlang-bugs] httpc: Duplicate requests sent on long-running request sending Message-ID: Duplicate requests will be sent when you have already run a request against the same host and therefor have an existing keep-alive connection open. If you then perform a request where the request body takes more than five seconds to send a second identical request will be sent concurrently. I think I have figured what is happening after tracing httpc. The code reaches https://github.com/erlang/otp/blob/ec8e9a96bd0d0148df5008b0665da0725e5b3f92/lib/inets/src/http_client/httpc_manager.erl#L851 and calls `httpc_handler:send` which blocks while sending the request. If the request body takes longer than five seconds to send the `gen_server:call` will timeout and reach this code https://github.com/erlang/otp/blob/ec8e9a96bd0d0148df5008b0665da0725e5b3f92/lib/inets/src/http_client/httpc_manager.erl#L856. `start_handler` will create a new connection sending another identical request even though a request is already in progress. I would be happy to provide a patch after some guidance on what the fix should be. Maybe the `handle_call` in `httpc_handler` should return immediately and the request be sent without blocking the caller? -- Eric Meadows-J?nsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Wed Nov 12 12:32:12 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 12 Nov 2014 12:32:12 +0100 Subject: [erlang-bugs] bug ? In-Reply-To: References: Message-ID: <5463453C.90206@erlang.org> Hello, I've had to guess what you think the bug is, but from what i can understand you are wondering why the shell stops accepting you input? That is not a bug, but works as intended as you started a string but never closed it, so the shell expects you to place a " somewhere to close the string. Lukas On 11/11/14 23:59, Davery wrote: > hi there: > > Winxp sp3 > Erlang 17.3 > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Thu Nov 13 16:32:54 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Thu, 13 Nov 2014 16:32:54 +0100 Subject: [erlang-bugs] [erlang-questions] beam.smp crash reproducibly In-Reply-To: References: Message-ID: <5464CF26.4010801@erix.ericsson.se> On 11/12/2014 11:16 PM, Maxim Sokhatsky wrote: > Hello! > > tl;dr We?ve managed to put beam.smp in crash reproducibly. > It is resistant to reproduce on 17.3 and 16B02 versions. > This happens under heavy load. No HiPE. No NIFs. ulimit is ok. > > We have very simple application that consumes RabbitMQ queue and store data in mnesia's disc_copies. For that purposes we use RabbitMQ client stack amqp_client/rabbit_common wrapped in our simple library synrc/mqs (300 LOC) along with very simple wrapper over mnesia synrc/kvs (200 LOC). We have 16GB RAM on powerful machine and performance is good. However after reaching memory consumption near 10GB the system goes to core. We used the original Ubuntu 12.04 package R16B02 which was without symbol information needed to bug report. So we?ve built with KERL Erlang 17.3 from sources and situation hadn?t change. > > Here is GBD session we did retrieve from core file along with detailed information about application, build procedure, etc.: > > 1. https://gist.github.com/5HT/e35d58b76bc25680e17b > 2. https://gist.github.com/5HT/224c569df807f1e337aa #1 Seems to be corruption in process heap memory, found by gc. #2 Seems to be corruption in ets memory, found by ets:insert. > We heard that 17.3 have some unstable memory allocators. Not sure what allocator problem you are referring to. There is one known race bug in the carrier migration logic for 17. It also exist in R16 but only if you run with carrier migration enabled (+Muacul with a value other than zero). This bug is fixed in tag OTP-17.3.4 at github and will be released in 17.4 > But crashes was also reproducible on R16B02. So we decided not to panic and ask in community the recipe how to perform further checks and plan in calm the regression test kit. > > As you can see crash core files contains information about allocators and gc. We think the problem is there. That leads us with following questions to community: > > 1. Which memory allocators you suggest us to try at first? A gdb backtrace including allocator calls does not mean that the allocator code is to blame. Very often the allocator just happens to be the one that discovers a corruption that has already happened. The same goes for the GC. So I do not see much use of trying different allocators other than maybe to find a workaround. > 2. What other steps we should perform? You could try run with a debug compiled beam.smp. It will be much slower but may catch the bug earlier and give a much nicer core dump. $> cd $ERL_TOP/erts/emulator $> make TYPE=debug smp run with $> $ERL_TOP/bin/cerl -debug OR replace your beam.smp and copy child_setup.debug to the same place: $> cp /bin/beam.smp /bin/beam.smp.saved $> cp $ERL_TOP/bin//beam.debug.smp /bin/beam.smp $> cp $ERL_TOP/bin//child_setup.debug /bin/ and run as you normally do And lastly you can send us the source and a description of how to reproduce including info of hardware and OS. /Sverker, Erlang/OTP Ericsson From dariusz.gadomski@REDACTED Fri Nov 14 11:01:22 2014 From: dariusz.gadomski@REDACTED (Dariusz Gadomski) Date: Fri, 14 Nov 2014 11:01:22 +0100 Subject: [erlang-bugs] Cannot bind epmd to an IPv4 address after building with -DEPMD6 Message-ID: <20141114100122.GA27993@phenom> Hello everyone, There are users observing problems with binding to an IPv4 address with erlang 16b3 version built with -DEPMD6 flag [1]. This flag has been added as a response to another?bug [2]. By looking at erts/epmd/src/epmd_int.h I see that the address definitions are mutually exclusive - enabling IPv6 makes all addresses IPv6-only which may result in problems with binding to a specific IPv4 address: $ ERL_EPMD_ADDRESS="127.0.0.1" epmd epmd: Fri Nov 14 11:00:47 2014: cannot parse IP address "127.0.0.1" Can you please confirm this? Is it a known issue? Maybe there is a workaround? [1]?https://bugs.launchpad.net/ubuntu/+source/erlang/+bug/1374109 [2]?https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1312507 Thanks, Dariusz Gadomski From tuncer.ayaz@REDACTED Sun Nov 16 17:41:35 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 16 Nov 2014 17:41:35 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> Message-ID: On Mon, Nov 10, 2014 at 12:31 PM, Magnus Henoch wrote: > Mattias Waldau writes: > > > Thank you Loic and Roland for the explanations, I really > > appreciate it. > > > > The trick to understand why this is and should be ok is that #{} > > is n operator and then it makes sense. Then, there is another > > question why #{} is an operator. > > > > This is what the Erlang reference manual says about record > > creation, it doesn't mention #rec{}#rec{} > > > > So, until you explained, I just thought is was a parser bug. > > This syntax used to be disallowed. The "Nested records" section of > the Records chapter of the reference manual mentions a new feature > in R14: > > Before R14 you would have needed to use parentheses as following: > > "nested0" = ((N2#nrec2.nrec1)#nrec1.nrec0)#nrec0.name, > N0n = ((N2#nrec2.nrec1)#nrec1.nrec0)#nrec0{name = "nested0a"}, > > > Since R14 you can also write: > > "nested0" = N2#nrec2.nrec1#nrec1.nrec0#nrec0.name, > N0n = N2#nrec2.nrec1#nrec1.nrec0#nrec0{name = "nested0a"}, > > As an unintended(?) consequence, this also made the #rec{}#rec{} > syntax valid. When I forward-ported and submitted the old patch and it was included in R14, unfortunately both the OTP board and I failed to see that particular problem. After R14 was released and users hit that issue, Robert Virding and I discussed this in detail and we suggested to back out that change. However, so far there has been no response from the OTP team. So, personally, like Robert, I still think we should revert the change, as the gain is not worth it given that users accidentally write such code. From eric.pailleau@REDACTED Sun Nov 16 19:15:34 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Nov 2014 19:15:34 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> Message-ID: <5468E9C6.7010500@wanadoo.fr> 1> #test{a=2}#test{a=3}. #test{a = 3,b = 6} but 2> {test, 2,6}{test, 3, 6}. * 1: syntax error before: '{' ---8<------------------------------------------------------------------ 10.8 Internal Representation of Records Record expressions are translated to tuple expressions during compilation. A record defined as -record(Name, {Field1,...,FieldN}). is internally represented by the tuple {Name,Value1,...,ValueN} where each ValueI is the default value for FieldI. ---8<------------------------------------------------------------------ I don't have any opinion on whether this syntax should be allowed or not, but parser should not fail on second notation in such case. MHO. From kostis@REDACTED Sun Nov 16 19:37:19 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 16 Nov 2014 19:37:19 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <5468E9C6.7010500@wanadoo.fr> References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> <5468E9C6.7010500@wanadoo.fr> Message-ID: <5468EEDF.3080507@cs.ntua.gr> On 11/16/2014 07:15 PM, PAILLEAU Eric wrote: > > 1> #test{a=2}#test{a=3}. > #test{a = 3,b = 6} > > but > > 2> {test, 2,6}{test, 3, 6}. > * 1: syntax error before: '{' > > ---8<------------------------------------------------------------------ > 10.8 Internal Representation of Records > > Record expressions are translated to tuple expressions during > compilation. A record defined as > > -record(Name, {Field1,...,FieldN}). > > is internally represented by the tuple > > {Name,Value1,...,ValueN} > > where each ValueI is the default value for FieldI. > ---8<------------------------------------------------------------------ > > I don't have any opinion on whether this syntax should be allowed or > not, but parser should not fail on second notation in such case. FWIW, I am of the same opinion here. Currently, there is some inconsistency that should not be there. Kostis From eric.pailleau@REDACTED Sun Nov 16 19:29:07 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Nov 2014 19:29:07 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <5468E9C6.7010500@wanadoo.fr> References: <545F53F5.6020109@ninenines.eu> <20141109140212.90C7.69B9F832@proxel.se> <545F678C.2070101@ninenines.eu> <5468E9C6.7010500@wanadoo.fr> Message-ID: <5468ECF3.5060602@wanadoo.fr> Proof : Eshell V6.0 (abort with ^G) 1> rd(test, {a=3, b=6}). test 2> {test, 2, 6},{test,5,6}. #test{a = 5,b = 6} 3> {test, 2, 6}{test,5,6}. * 1: syntax error before: '{' Le 16/11/2014 19:15, PAILLEAU Eric a ?crit : > > 1> #test{a=2}#test{a=3}. > #test{a = 3,b = 6} > > but > > 2> {test, 2,6}{test, 3, 6}. > * 1: syntax error before: '{' > > ---8<------------------------------------------------------------------ > 10.8 Internal Representation of Records > > Record expressions are translated to tuple expressions during > compilation. A record defined as > > -record(Name, {Field1,...,FieldN}). > > is internally represented by the tuple > > {Name,Value1,...,ValueN} > > where each ValueI is the default value for FieldI. > ---8<------------------------------------------------------------------ > > I don't have any opinion on whether this syntax should be allowed or > not, but parser should not fail on second notation in such case. > > MHO. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From roland.karlsson@REDACTED Sun Nov 16 19:58:44 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 16 Nov 2014 19:58:44 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <5468EEDF.3080507@cs.ntua.gr> References: <5468E9C6.7010500@wanadoo.fr> <5468EEDF.3080507@cs.ntua.gr> Message-ID: <20141116195843.0FB9.69B9F832@proxel.se> I do not agree. Not the slightest. The use {}{} is quite meaningless. What should it mean? Some kind of double tuple? What is that? It would be like writing two atoms or two integers after each other. Double atoms? Double integers? Nothing like that in the Erlang syntax. The usage #foo{}#foo{} on the other hand is totally meaningful, even if maybe ugly. The first creates a record and the second modifies it. Nothing strange at all. It is like TMP=#foo{}, TMP#foo{}. perfectly legit Erlang code. /Roland On Sun, 16 Nov 2014 19:37:19 +0100 Kostis Sagonas wrote: > On 11/16/2014 07:15 PM, PAILLEAU Eric wrote: > > > > 1> #test{a=2}#test{a=3}. > > #test{a = 3,b = 6} > > > > but > > > > 2> {test, 2,6}{test, 3, 6}. > > * 1: syntax error before: '{' > > > > ---8<------------------------------------------------------------------ > > 10.8 Internal Representation of Records > > > > Record expressions are translated to tuple expressions during > > compilation. A record defined as > > > > -record(Name, {Field1,...,FieldN}). > > > > is internally represented by the tuple > > > > {Name,Value1,...,ValueN} > > > > where each ValueI is the default value for FieldI. > > ---8<------------------------------------------------------------------ > > > > I don't have any opinion on whether this syntax should be allowed or > > not, but parser should not fail on second notation in such case. > > FWIW, I am of the same opinion here. Currently, there is some inconsistency that should not be there. > > Kostis > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Roland Karlsson From eric.pailleau@REDACTED Sun Nov 16 20:52:47 2014 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Sun, 16 Nov 2014 20:52:47 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. Message-ID: Two strings are concatanated. "abc" "def". "abcdef" even without ++. If you look at my second mail, erl guess that {test, 2, 6} is a record, because a record is only a tuple. #test is only a facility in order not to write default values in a tuple. that s all. regards ? Envoy? depuis mon mobile ? Eric Roland Karlsson a ?crit?: >I do not agree. Not the slightest. > >The use {}{} is quite meaningless. What should it mean? >Some kind of double tuple? What is that? It would be like writing >two atoms or two integers after each other. Double atoms? >Double integers? Nothing like that in the Erlang syntax. > >The usage #foo{}#foo{} on the other hand is totally meaningful, >even if maybe ugly. The first creates a record and the second >modifies it. Nothing strange at all. It is like >TMP=#foo{}, TMP#foo{}. >perfectly legit Erlang code. > > >/Roland > > > > >On Sun, 16 Nov 2014 19:37:19 +0100 >Kostis Sagonas wrote: > >> On 11/16/2014 07:15 PM, PAILLEAU Eric wrote: >> > >> > 1> #test{a=2}#test{a=3}. >> > #test{a = 3,b = 6} >> > >> > but >> > >> > 2> {test, 2,6}{test, 3, 6}. >> > * 1: syntax error before: '{' >> > >> > ---8<------------------------------------------------------------------ >> > 10.8 Internal Representation of Records >> > >> > Record expressions are translated to tuple expressions during >> > compilation. A record defined as >> > >> > -record(Name, {Field1,...,FieldN}). >> > >> > is internally represented by the tuple >> > >> > {Name,Value1,...,ValueN} >> > >> > where each ValueI is the default value for FieldI. >> > ---8<------------------------------------------------------------------ >> > >> > I don't have any opinion on whether this syntax should be allowed or >> > not, but parser should not fail on second notation in such case. >> >> FWIW, I am of the same opinion here. Currently, there is some inconsistency that should not be there. >> >> Kostis >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > >-- >Roland Karlsson > >_______________________________________________ >erlang-bugs mailing list >erlang-bugs@REDACTED >http://erlang.org/mailman/listinfo/erlang-bugs From eric.pailleau@REDACTED Sun Nov 16 21:32:09 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Nov 2014 21:32:09 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: Message-ID: <546909C9.7010507@wanadoo.fr> More odd : 3> #test{a=5}{test, 7,6}. * 2: syntax error before: '{' 3> {test, 7,6}#test{a=5}. #test{a = 5,b = 6} From eric.pailleau@REDACTED Sun Nov 16 21:45:43 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Nov 2014 21:45:43 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <546909C9.7010507@wanadoo.fr> References: <546909C9.7010507@wanadoo.fr> Message-ID: <54690CF7.4080501@wanadoo.fr> Le 16/11/2014 21:32, PAILLEAU Eric a ?crit : > > 3> #test{a=5}{test, 7,6}. > * 2: syntax error before: '{' but : 2> ({test, 7,6})#test{a=5}. #test{a = 5,b = 6} !!! From roland.karlsson@REDACTED Sun Nov 16 21:47:08 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 16 Nov 2014 21:47:08 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <546909C9.7010507@wanadoo.fr> References: <546909C9.7010507@wanadoo.fr> Message-ID: <20141116214706.0FBD.69B9F832@proxel.se> Whats odd with that? Why should #foo{}{} be legal? What should it mean? And, of course {}#foo{} is legal. Using tuple syntax for creating a record is perfectly legal. And then using record syntax to modify the tuple/record is perfectly fine. A strange way of doing it maybe, but it is a natural result of records being tuples. /Roland On Sun, 16 Nov 2014 21:32:09 +0100 PAILLEAU Eric wrote: > More odd : > > 3> #test{a=5}{test, 7,6}. > * 2: syntax error before: '{' > > 3> {test, 7,6}#test{a=5}. > #test{a = 5,b = 6} > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Roland Karlsson From roland.karlsson@REDACTED Sun Nov 16 21:50:44 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 16 Nov 2014 21:50:44 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <54690CF7.4080501@wanadoo.fr> References: <546909C9.7010507@wanadoo.fr> <54690CF7.4080501@wanadoo.fr> Message-ID: <20141116215042.0FC1.69B9F832@proxel.se> Also that is perfectly fine. Nothing strange at all. You create a record, using tuple syntax, and then modifies it using record syntax. Extremely ugly and not recommended. Here I can agree that a warning is motivated. But ... it is perfectly legal Erlang syntax. You are misunderstanding the record and tuple syntax. /Roland On Sun, 16 Nov 2014 21:45:43 +0100 PAILLEAU Eric wrote: > Le 16/11/2014 21:32, PAILLEAU Eric a ?crit : > > > > 3> #test{a=5}{test, 7,6}. > > * 2: syntax error before: '{' > > but : > > 2> ({test, 7,6})#test{a=5}. > #test{a = 5,b = 6} > > !!! > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- Roland Karlsson From roland.karlsson@REDACTED Sun Nov 16 21:54:27 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Sun, 16 Nov 2014 21:54:27 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: Message-ID: <20141116215408.0FC5.69B9F832@proxel.se> Concatenating of two strings is an exception I assume. I am not knowledgeable enough in Erlang syntax to explain why it works. Need help of someone else. /Roland On Sun, 16 Nov 2014 20:52:47 +0100 Eric Pailleau wrote: > Two strings are concatanated. > > "abc" "def". > "abcdef" > > even without ++. > > If you look at my second mail, > erl guess that {test, 2, 6} is a record, because a record is only a tuple. > > #test is only a facility in order not to write default values in a tuple. that s all. > > regards > > > > ? Envoy? depuis mon mobile ? Eric > > Roland Karlsson a ?crit?: > > >I do not agree. Not the slightest. > > > >The use {}{} is quite meaningless. What should it mean? > >Some kind of double tuple? What is that? It would be like writing > >two atoms or two integers after each other. Double atoms? > >Double integers? Nothing like that in the Erlang syntax. > > > >The usage #foo{}#foo{} on the other hand is totally meaningful, > >even if maybe ugly. The first creates a record and the second > >modifies it. Nothing strange at all. It is like > >TMP=#foo{}, TMP#foo{}. > >perfectly legit Erlang code. > > > > > >/Roland > > > > > > > > > >On Sun, 16 Nov 2014 19:37:19 +0100 > >Kostis Sagonas wrote: > > > >> On 11/16/2014 07:15 PM, PAILLEAU Eric wrote: > >> > > >> > 1> #test{a=2}#test{a=3}. > >> > #test{a = 3,b = 6} > >> > > >> > but > >> > > >> > 2> {test, 2,6}{test, 3, 6}. > >> > * 1: syntax error before: '{' > >> > > >> > ---8<------------------------------------------------------------------ > >> > 10.8 Internal Representation of Records > >> > > >> > Record expressions are translated to tuple expressions during > >> > compilation. A record defined as > >> > > >> > -record(Name, {Field1,...,FieldN}). > >> > > >> > is internally represented by the tuple > >> > > >> > {Name,Value1,...,ValueN} > >> > > >> > where each ValueI is the default value for FieldI. > >> > ---8<------------------------------------------------------------------ > >> > > >> > I don't have any opinion on whether this syntax should be allowed or > >> > not, but parser should not fail on second notation in such case. > >> > >> FWIW, I am of the same opinion here. Currently, there is some inconsistency that should not be there. > >> > >> Kostis > >> > >> > >> _______________________________________________ > >> erlang-bugs mailing list > >> erlang-bugs@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-bugs > > > >-- > >Roland Karlsson > > > >_______________________________________________ > >erlang-bugs mailing list > >erlang-bugs@REDACTED > >http://erlang.org/mailman/listinfo/erlang-bugs -- Roland Karlsson From eric.pailleau@REDACTED Sun Nov 16 22:12:31 2014 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Nov 2014 22:12:31 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <20141116215408.0FC5.69B9F832@proxel.se> References: <20141116215408.0FC5.69B9F832@proxel.se> Message-ID: <5469133F.7020102@wanadoo.fr> Le 16/11/2014 21:54, Roland Karlsson a ?crit : > > Concatenating of two strings is an exception I assume. > I am not knowledgeable enough in Erlang syntax to explain why it works. > Need help of someone else. It is written in documentation. "Two adjacent string literals are concatenated into one. This is done at compile-time and does not incur any runtime overhead" I don't fight for this syntax, I think it add more inconsistency in syntax. By the way, this syntax only work at first expansion , this below module will never compile ... ---8<--------------------------------------- -module(test). -export([main/0]). -record(test,{a=0, b=0}). main() -> left()right(). left() -> #test{2}. right() -> #test{a=6}. ---8<--------------------------------------- "You are misunderstanding the record and tuple syntax." Not at all . Documentation says "However, record is not a true data type. Instead record expressions are translated to tuple expressions during compilation. " Records are not existing in Erlang , only in syntax. my last mail on this. Anyway, I will never use this syntax. From rvirding@REDACTED Mon Nov 17 16:56:51 2014 From: rvirding@REDACTED (Robert Virding) Date: Mon, 17 Nov 2014 16:56:51 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: <5469133F.7020102@wanadoo.fr> References: <20141116215408.0FC5.69B9F832@proxel.se> <5469133F.7020102@wanadoo.fr> Message-ID: The obvious solution is to reinstate the need to wrap the "thing" before the # with parentheses when it is and expression. Then the problem would go away. :-) Robert On 16 November 2014 22:12, PAILLEAU Eric wrote: > Le 16/11/2014 21:54, Roland Karlsson a ?crit : > >> >> Concatenating of two strings is an exception I assume. >> I am not knowledgeable enough in Erlang syntax to explain why it works. >> Need help of someone else. >> > > It is written in documentation. > > "Two adjacent string literals are concatenated into one. This is done at > compile-time and does not incur any runtime overhead" > > I don't fight for this syntax, I think it add more inconsistency in syntax. > > By the way, this syntax only work at first expansion , > this below module will never compile ... > > ---8<--------------------------------------- > -module(test). > > -export([main/0]). > > -record(test,{a=0, b=0}). > > main() -> left()right(). > > left() -> #test{2}. > > right() -> #test{a=6}. > ---8<--------------------------------------- > > > "You are misunderstanding the record and tuple syntax." > > Not at all . > > Documentation says "However, record is not a true data type. Instead > record expressions are translated to tuple expressions during compilation. " > > Records are not existing in Erlang , only in syntax. > > my last mail on this. > Anyway, I will never use this syntax. > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Mon Nov 17 18:28:06 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 17 Nov 2014 18:28:06 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: <20141116215408.0FC5.69B9F832@proxel.se> <5469133F.7020102@wanadoo.fr> Message-ID: On Mon, Nov 17, 2014 at 4:56 PM, Robert Virding wrote: > The obvious solution is to reinstate the need to wrap the "thing" before > the # with parentheses when it is and expression. Then the problem would go > away. :-) > Is a single variable not an expression? It would be inconsistent if only some expressions would need parentheses! ;-) regards, Vlad > Robert > > > On 16 November 2014 22:12, PAILLEAU Eric wrote: > >> Le 16/11/2014 21:54, Roland Karlsson a ?crit : >> >>> >>> Concatenating of two strings is an exception I assume. >>> I am not knowledgeable enough in Erlang syntax to explain why it works. >>> Need help of someone else. >>> >> >> It is written in documentation. >> >> "Two adjacent string literals are concatenated into one. This is done at >> compile-time and does not incur any runtime overhead" >> >> I don't fight for this syntax, I think it add more inconsistency in >> syntax. >> >> By the way, this syntax only work at first expansion , >> this below module will never compile ... >> >> ---8<--------------------------------------- >> -module(test). >> >> -export([main/0]). >> >> -record(test,{a=0, b=0}). >> >> main() -> left()right(). >> >> left() -> #test{2}. >> >> right() -> #test{a=6}. >> ---8<--------------------------------------- >> >> >> "You are misunderstanding the record and tuple syntax." >> >> Not at all . >> >> Documentation says "However, record is not a true data type. Instead >> record expressions are translated to tuple expressions during compilation. " >> >> Records are not existing in Erlang , only in syntax. >> >> my last mail on this. >> Anyway, I will never use this syntax. >> >> >> >> >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.karlsson@REDACTED Mon Nov 17 19:51:32 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Mon, 17 Nov 2014 19:51:32 +0100 Subject: [erlang-bugs] Parser bug: if missing ", " in list between records, the first is ignored, and no parser warnings are given. In-Reply-To: References: Message-ID: <20141117195129.8808.69B9F832@proxel.se> Not necessarily. Sometimes you get syntactical clashes which forces paranthesis or sometimes even blank spaces. Erlang is not well syntactically designed. But in this particular case no such clash is evident - so a paranthesis is not needed other than for avoiding unreadability. I know of no such other case. But I do not know all. So --- maybe someone has an example? An example where a paranthesis is needed even though it would be unambiguous without. /Roland On Mon, 17 Nov 2014 18:28:06 +0100 Vlad Dumitrescu wrote: > On Mon, Nov 17, 2014 at 4:56 PM, Robert Virding wrote: > > > The obvious solution is to reinstate the need to wrap the "thing" before > > the # with parentheses when it is and expression. Then the problem would go > > away. :-) > > > > Is a single variable not an expression? It would be inconsistent if only > some expressions would need parentheses! > > ;-) > > regards, > Vlad > > > > > Robert > > > > > > On 16 November 2014 22:12, PAILLEAU Eric wrote: > > > >> Le 16/11/2014 21:54, Roland Karlsson a ?crit : > >> > >>> > >>> Concatenating of two strings is an exception I assume. > >>> I am not knowledgeable enough in Erlang syntax to explain why it works. > >>> Need help of someone else. > >>> > >> > >> It is written in documentation. > >> > >> "Two adjacent string literals are concatenated into one. This is done at > >> compile-time and does not incur any runtime overhead" > >> > >> I don't fight for this syntax, I think it add more inconsistency in > >> syntax. > >> > >> By the way, this syntax only work at first expansion , > >> this below module will never compile ... > >> > >> ---8<--------------------------------------- > >> -module(test). > >> > >> -export([main/0]). > >> > >> -record(test,{a=0, b=0}). > >> > >> main() -> left()right(). > >> > >> left() -> #test{2}. > >> > >> right() -> #test{a=6}. > >> ---8<--------------------------------------- > >> > >> > >> "You are misunderstanding the record and tuple syntax." > >> > >> Not at all . > >> > >> Documentation says "However, record is not a true data type. Instead > >> record expressions are translated to tuple expressions during compilation. " > >> > >> Records are not existing in Erlang , only in syntax. > >> > >> my last mail on this. > >> Anyway, I will never use this syntax. > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > -- Roland Karlsson From wieslaw.bieniek@REDACTED Mon Nov 17 11:22:40 2014 From: wieslaw.bieniek@REDACTED (=?UTF-8?B?V2llc8WCYXcgQmllbmllaw==?=) Date: Mon, 17 Nov 2014 11:22:40 +0100 Subject: [erlang-bugs] Problem with timeout on ldaps connection. Message-ID: <5469CC70.2050004@comarch.pl> Hello, I'm using ldaps protocol to communicate with LDAP Server Handle = case eldap:open([LDAPHost], [{port, LDAPPort}, {timeout, Timeout}, {log, LogFun}, {ssl, true}, {sslopts, [{verify, verify_peer}, {reuse_sessions, false}, {cacertfile, CertFile}]}]) of {ok, H} -> H; Error -> ?DEBUG("Open Error: [~p]~n", [Error]), error(Error) end, When LDAP on LDAPHost:LDAPPort is not working and cannot respond for request this function hangs for about 3 minutes (although the Timeout is set to 1000 (1 sec.)) and then returns with {error, etimedout}. I made some investigations and the root cause of this seems to be function from eldap: do_connect(Host, Data, Opts) when Data#eldap.ldaps == false -> gen_tcp:connect(Host, Data#eldap.port, Opts, Data#eldap.timeout); do_connect(Host, Data, Opts) when Data#eldap.ldaps == true -> ssl:connect(Host, Data#eldap.port, Opts++Data#eldap.tls_opts). It does not use timeout when connecting using SSL. I guess It need fixing is next release. But there is an additional question: Due to agreement with user we cannot change any part of OTP Distributions. Only official releases of OTP can be used. Is it possible to workaround the problem without updating eldap.erl and recompiling OTP ? -- *Wies?aw Bieniek* Projektant 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 dariusz.gadomski@REDACTED Tue Nov 18 13:06:34 2014 From: dariusz.gadomski@REDACTED (Dariusz Gadomski) Date: Tue, 18 Nov 2014 13:06:34 +0100 Subject: [erlang-bugs] Cannot bind epmd to an IPv4 address after building with -DEPMD6 In-Reply-To: <20141114100122.GA27993@phenom> References: <20141114100122.GA27993@phenom> Message-ID: <20141118120634.GA13483@phenom> Hello again. On Fri, Nov 14, 2014 at 11:01:22AM +0100, Dariusz Gadomski wrote: > $ ERL_EPMD_ADDRESS="127.0.0.1" epmd > epmd: Fri Nov 14 11:00:47 2014: cannot parse IP address "127.0.0.1" > > Can you please confirm this? Is it a known issue? Maybe there is a workaround? I have managed to observe that for Linux the IPV6_V6ONLY socket option is *disabled* by default so it is possible to use IPv4-mapped IPv6 address [1]. Hence, I was able to do: $ ERL_EMPD_ADDRESS="::ffff:127.0.0.1" empd However, if IPV6_V6ONLY would be turned on or the mapping feature would not be supported (e.g. Windows XP) this workaround would not have been possible. This may still be a bug. [1] http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses Kind regards, Dariusz Gadomski From hans@REDACTED Wed Nov 19 10:14:49 2014 From: hans@REDACTED (Hans Nilsson) Date: Wed, 19 Nov 2014 10:14:49 +0100 Subject: [erlang-bugs] Problem with timeout on ldaps connection. In-Reply-To: <5469CC70.2050004@comarch.pl> References: <5469CC70.2050004@comarch.pl> Message-ID: <546C5F89.5000301@erlang.org> Thanks for the report! I've added it to our backlog. A workaround could be to start eldap on tcp (= without ssl) and then call eldap:start_tls immediatly to upgrade the connection to tls. Most servers support this extension. - Hans On 2014-11-17 11:22, Wies?aw Bieniek wrote: > Hello, > > I'm using ldaps protocol to communicate with LDAP Server > > Handle = case eldap:open([LDAPHost], [{port, LDAPPort}, {timeout, > Timeout}, {log, LogFun}, {ssl, true}, {sslopts, [{verify, > verify_peer}, {reuse_sessions, false}, {cacertfile, CertFile}]}]) of > {ok, H} -> H; > Error -> ?DEBUG("Open Error: [~p]~n", [Error]), > error(Error) > end, > > When LDAP on LDAPHost:LDAPPort is not working and cannot respond for > request this function hangs for about 3 minutes (although the Timeout > is set to 1000 (1 sec.)) and then returns with {error, etimedout}. > > I made some investigations and the root cause of this seems to be > function from eldap: > > do_connect(Host, Data, Opts) when Data#eldap.ldaps == false -> > gen_tcp:connect(Host, Data#eldap.port, Opts, Data#eldap.timeout); > do_connect(Host, Data, Opts) when Data#eldap.ldaps == true -> > ssl:connect(Host, Data#eldap.port, Opts++Data#eldap.tls_opts). > > It does not use timeout when connecting using SSL. > > I guess It need fixing is next release. > > But there is an additional question: > > Due to agreement with user we cannot change any part of OTP > Distributions. Only official releases of OTP can be used. > Is it possible to workaround the problem without updating eldap.erl > and recompiling OTP ? > > -- > *Wies?aw Bieniek* > Projektant 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 atill@REDACTED Wed Nov 19 23:11:14 2014 From: atill@REDACTED (Andy Till) Date: Wed, 19 Nov 2014 22:11:14 +0000 Subject: [erlang-bugs] erts_use_sender_punish not always a good thing Message-ID: <546D1582.90900@mail.com> Short outline of how erts_use_sender_punish works, please comment if there are any errors in the description. erts_use_sender_punish is a flag hard coded to 1 (true), when it is true a process sending messages to another process will have its reduction count reduced by the number of messages in the receivers message queue multiplied by four. Sending messages to processes with zero messages in the queue is free in terms of reductions, but sending messages to load queues is very expensive and will lead the scheduler to context switch to another process more often. In the case where the the relationship between of producers and consumers is one to one, this makes sense. It provides back pressure when part of the system is loaded. In the case where there is one producer to many consumers, if one consumer gets a flood of messages and the producer is punished then the punishment is not only on the producer but on all other consumers because the producer cannot create enough work for them as it used all of its reductions. This makes performance unpredictable when work cannot be spread evenly. Cheers Andy Code: https://github.com/erlang/otp/blob/a70f0ce9b34e4db61dacb8db24f9ab5671ed4c8a/erts/emulator/beam/erl_init.c#L694 https://github.com/erlang/otp/blob/682a6082159568f40615f03d12d44ee70edd14c6/erts/emulator/beam/bif.c#L2058 https://github.com/erlang/otp/blob/a8e12f7168c14cc765a63a51c838d065412795d7/erts/emulator/beam/erl_message.c#L504 From mikpelinux@REDACTED Thu Nov 20 12:49:52 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 20 Nov 2014 12:49:52 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else Message-ID: <21613.54624.494982.748790@gargle.gargle.HOWL> The following, adapted from an example in the online Erlang Reference Manual, looks like a bug to me: > cat bug.erl -module(bug). -compile(export_all). termize_file(Name) -> {ok,F} = file:open(Name, [read,binary]), try {ok,Bin} = file:read(F, 1024*1024) after file:close(F) end, binary_to_term(Bin). > erlc bug.erl bug.erl:11: variable 'Bin' unsafe in 'try' (line 6) Unless I'm missing something, there is no way to reach the binary_to_term/1 call without successfully evaluating the {ok,Bin} = ... match expression; therefore the use is not unsafe. If the file:read/2 call or the {ok,Bin} match fails, the after clause runs and the entire try expression fails, and the binary_to_term/1 is not reached. Reproduced with 17.3 and r15b03-1. Workaround: match on the value of the try itself: "{ok,Bin} = try file:read(...) after ... end". /Mikael From dmkolesnikov@REDACTED Thu Nov 20 13:39:30 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Thu, 20 Nov 2014 14:39:30 +0200 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: <21613.54624.494982.748790@gargle.gargle.HOWL> References: <21613.54624.494982.748790@gargle.gargle.HOWL> Message-ID: <49B52421-0671-4281-A4AC-23EA514791FD@gmail.com> Hello, This is very valid error. The variable Bin is defined within code block but it is used out-side of it. I?ve never heard that any one complained about following error: try { int x = 1; } catch (Exception _) { } x++; error: cannot find symbol Best Regards, Dmitry > On 20 Nov 2014, at 13:49, Mikael Pettersson wrote: > > The following, adapted from an example in the online Erlang > Reference Manual, looks like a bug to me: > >> cat bug.erl > -module(bug). > -compile(export_all). > > termize_file(Name) -> > {ok,F} = file:open(Name, [read,binary]), > try > {ok,Bin} = file:read(F, 1024*1024) > after > file:close(F) > end, > binary_to_term(Bin). >> erlc bug.erl > bug.erl:11: variable 'Bin' unsafe in 'try' (line 6) > > Unless I'm missing something, there is no way to reach the > binary_to_term/1 call without successfully evaluating the > {ok,Bin} = ... match expression; therefore the use is not > unsafe. If the file:read/2 call or the {ok,Bin} match fails, > the after clause runs and the entire try expression fails, > and the binary_to_term/1 is not reached. > > Reproduced with 17.3 and r15b03-1. > > Workaround: match on the value of the try itself: > "{ok,Bin} = try file:read(...) after ... end". > > /Mikael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From kostis@REDACTED Thu Nov 20 13:54:15 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 20 Nov 2014 14:54:15 +0200 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: <49B52421-0671-4281-A4AC-23EA514791FD@gmail.com> References: <21613.54624.494982.748790@gargle.gargle.HOWL> <49B52421-0671-4281-A4AC-23EA514791FD@gmail.com> Message-ID: <546DE477.6060803@cs.ntua.gr> On 11/20/14 14:39, Dmitry Kolesnikov wrote: > Hello, > > This is very valid error. > The variable Bin is defined within code block but it is used out-side of it. > > I?ve never heard that any one complained about following error: > > try > { > int x = 1; > } catch (Exception _) { > } > x++; > > error: cannot find symbol The issue has nothing to do with variables defined in blocks and used outside. If it had, then the following Erlang code would also not be allowed, but it is: termize_file(Name) -> {ok,F} = file:open(Name, [read,binary]), case file:read(F, 1024*1024) of {ok,Bin} -> ok end, binary_to_term(Bin). I suggest you try to understand the (perhaps quite unorthodox) variable scoping rules of Erlang, and of try-catch in particular, and think about the differences between the code that was posted by Mikael (who is right, of course) and the Java one you posted. Kostis >> >On 20 Nov 2014, at 13:49, Mikael Pettersson wrote: >> > >> >The following, adapted from an example in the online Erlang >> >Reference Manual, looks like a bug to me: >> > >>> >>cat bug.erl >> >-module(bug). >> >-compile(export_all). >> > >> >termize_file(Name) -> >> > {ok,F} =file:open(Name, [read,binary]), >> > try >> > {ok,Bin} =file:read(F, 1024*1024) >> > after >> > file:close(F) >> > end, >> > binary_to_term(Bin). >>> >>erlc bug.erl >> >bug.erl:11: variable 'Bin' unsafe in 'try' (line 6) >> > >> >Unless I'm missing something, there is no way to reach the >> >binary_to_term/1 call without successfully evaluating the >> >{ok,Bin} = ... match expression; therefore the use is not >> >unsafe. If thefile:read/2 call or the {ok,Bin} match fails, >> >the after clause runs and the entire try expression fails, >> >and the binary_to_term/1 is not reached. >> > >> >Reproduced with 17.3 and r15b03-1. >> > >> >Workaround: match on the value of the try itself: >> >"{ok,Bin} = tryfile:read(...) after ... end". >> > >> >/Mikael >> >_______________________________________________ >> >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 Nov 20 13:55:36 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 20 Nov 2014 13:55:36 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: <49B52421-0671-4281-A4AC-23EA514791FD@gmail.com> References: <21613.54624.494982.748790@gargle.gargle.HOWL> <49B52421-0671-4281-A4AC-23EA514791FD@gmail.com> Message-ID: <21613.58568.31539.437062@gargle.gargle.HOWL> Dmitry Kolesnikov writes: > Hello, > > This is very valid error. > The variable Bin is defined within code block but it is used out-side of it. > > I?ve never heard that any one complained about following error: > > try > { > int x = 1; > } catch (Exception _) { > } > x++; > > error: cannot find symbol Erlang has (very) different scope rules compared to C++. > > On 20 Nov 2014, at 13:49, Mikael Pettersson wrote: > > > > The following, adapted from an example in the online Erlang > > Reference Manual, looks like a bug to me: > > > >> cat bug.erl > > -module(bug). > > -compile(export_all). > > > > termize_file(Name) -> > > {ok,F} = file:open(Name, [read,binary]), > > try > > {ok,Bin} = file:read(F, 1024*1024) > > after > > file:close(F) > > end, > > binary_to_term(Bin). > >> erlc bug.erl > > bug.erl:11: variable 'Bin' unsafe in 'try' (line 6) > > > > Unless I'm missing something, there is no way to reach the > > binary_to_term/1 call without successfully evaluating the > > {ok,Bin} = ... match expression; therefore the use is not > > unsafe. If the file:read/2 call or the {ok,Bin} match fails, > > the after clause runs and the entire try expression fails, > > and the binary_to_term/1 is not reached. > > > > Reproduced with 17.3 and r15b03-1. > > > > Workaround: match on the value of the try itself: > > "{ok,Bin} = try file:read(...) after ... end". > > > > /Mikael > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs -- From n.oxyde@REDACTED Thu Nov 20 14:13:33 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 20 Nov 2014 14:13:33 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: <21613.54624.494982.748790@gargle.gargle.HOWL> References: <21613.54624.494982.748790@gargle.gargle.HOWL> Message-ID: try file:read(F, 1024 * 1024) of {ok,Bin} -> binary_to_term(Bin) after file:close(F) end Le 20 nov. 2014 ? 12:49, Mikael Pettersson a ?crit : > The following, adapted from an example in the online Erlang > Reference Manual, looks like a bug to me: > >> cat bug.erl > -module(bug). > -compile(export_all). > > termize_file(Name) -> > {ok,F} = file:open(Name, [read,binary]), > try > {ok,Bin} = file:read(F, 1024*1024) > after > file:close(F) > end, > binary_to_term(Bin). >> erlc bug.erl > bug.erl:11: variable 'Bin' unsafe in 'try' (line 6) > > Unless I'm missing something, there is no way to reach the > binary_to_term/1 call without successfully evaluating the > {ok,Bin} = ... match expression; therefore the use is not > unsafe. If the file:read/2 call or the {ok,Bin} match fails, > the after clause runs and the entire try expression fails, > and the binary_to_term/1 is not reached. > > Reproduced with 17.3 and r15b03-1. > > Workaround: match on the value of the try itself: > "{ok,Bin} = try file:read(...) after ... end". > > /Mikael > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From kostis@REDACTED Thu Nov 20 14:22:17 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 20 Nov 2014 15:22:17 +0200 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: References: <21613.54624.494982.748790@gargle.gargle.HOWL> Message-ID: <546DEB09.5010308@cs.ntua.gr> On 11/20/14 15:13, Anthony Ramine wrote: > try file:read(F, 1024 * 1024) of > {ok,Bin} -> binary_to_term(Bin) > after > file:close(F) > end And the reason to _having_ to write this is? (*) Cheers, Kostis (*) Less bugs are exposed in the compiler and less baby cats die in China if we all write like that, perhaps? :) Jokes aside, I also agree the above code is nicer, but that does not mean that the current warning is bogus and the analysis should be fixed. From pierrefenoll@REDACTED Thu Nov 20 14:37:52 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Thu, 20 Nov 2014 14:37:52 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: <546DEB09.5010308@cs.ntua.gr> References: <21613.54624.494982.748790@gargle.gargle.HOWL> <546DEB09.5010308@cs.ntua.gr> Message-ID: I guess the best option (and the one intended by OP) is to file:close/1 as soon as possible. Thus Anthony's proposition would be unsuitable (though valid) and OP would need something like Kostis' case proposition. I don't get why the scoping rules differ between try?after and case?of. I don't think they should (but I am surely missing an edge case where the difference makes sense). Cheers, -- Pierre Fenoll On 20 November 2014 14:22, Kostis Sagonas wrote: > On 11/20/14 15:13, Anthony Ramine wrote: > >> try file:read(F, 1024 * 1024) of >> {ok,Bin} -> binary_to_term(Bin) >> after >> file:close(F) >> end >> > > > And the reason to _having_ to write this is? (*) > > Cheers, > Kostis > > (*) Less bugs are exposed in the compiler and less baby cats die in China > if we all write like that, perhaps? :) > > Jokes aside, I also agree the above code is nicer, but that does not mean > that the current warning is bogus and the analysis should be fixed. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kasettbok@REDACTED Thu Nov 20 14:44:55 2014 From: kasettbok@REDACTED (Joel Ericson) Date: Thu, 20 Nov 2014 14:44:55 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: <546DEB09.5010308@cs.ntua.gr> References: <21613.54624.494982.748790@gargle.gargle.HOWL> <546DEB09.5010308@cs.ntua.gr> Message-ID: The binding {ok,Bin} = file:read(F, 1024*1024) *can* fail. E.g., if I were to load in my own file library, where file:read/2 returns {data,Data}, this fails. And as far as I know, one is not supposed to assume anything about what other modules return during compile time. Regards Joel On Thu, Nov 20, 2014 at 2:22 PM, Kostis Sagonas wrote: > On 11/20/14 15:13, Anthony Ramine wrote: > >> try file:read(F, 1024 * 1024) of >> {ok,Bin} -> binary_to_term(Bin) >> after >> file:close(F) >> end >> > > > And the reason to _having_ to write this is? (*) > > Cheers, > Kostis > > (*) Less bugs are exposed in the compiler and less baby cats die in China > if we all write like that, perhaps? :) > > Jokes aside, I also agree the above code is nicer, but that does not mean > that the current warning is bogus and the analysis should be fixed. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-bugs@REDACTED Thu Nov 20 16:48:34 2014 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 20 Nov 2014 16:48:34 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: References: <21613.54624.494982.748790@gargle.gargle.HOWL> <546DEB09.5010308@cs.ntua.gr> Message-ID: <20141120154834.GB9998@erix.ericsson.se> On Thu, Nov 20, 2014 at 02:44:55PM +0100, Joel Ericson wrote: > The binding {ok,Bin} = file:read(F, 1024*1024) *can* fail. E.g., if I were > to load in my own file library, where file:read/2 returns {data,Data}, this Yes, but since the try .. of .. after .. end construct does not catch any exceptions there is no way to reach the code after it without having succeeded with the variable binding. > fails. And as far as I know, one is not supposed to assume anything about > what other modules return during compile time. > > Regards > Joel > > On Thu, Nov 20, 2014 at 2:22 PM, Kostis Sagonas wrote: > > > On 11/20/14 15:13, Anthony Ramine wrote: > > > >> try file:read(F, 1024 * 1024) of > >> {ok,Bin} -> binary_to_term(Bin) > >> after > >> file:close(F) > >> end > >> > > > > > > And the reason to _having_ to write this is? (*) > > > > Cheers, > > Kostis > > > > (*) Less bugs are exposed in the compiler and less baby cats die in China > > if we all write like that, perhaps? :) > > > > Jokes aside, I also agree the above code is nicer, but that does not mean > > that the current warning is bogus and the analysis should be fixed. > > > > _______________________________________________ > > 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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-bugs@REDACTED Thu Nov 20 17:03:39 2014 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Thu, 20 Nov 2014 17:03:39 +0100 Subject: [erlang-bugs] bogus 'unsafe variable' warning with try-else In-Reply-To: References: <21613.54624.494982.748790@gargle.gargle.HOWL> <546DEB09.5010308@cs.ntua.gr> Message-ID: <20141120160339.GC9998@erix.ericsson.se> On Thu, Nov 20, 2014 at 02:37:52PM +0100, Pierre Fenoll wrote: > I guess the best option (and the one intended by OP) is to file:close/1 as > soon as possible. > > Thus Anthony's proposition would be unsuitable (though valid) and OP would > need something like Kostis' case proposition. > > I don't get why the scoping rules differ between try?after and case?of. I > don't think they should (but I am surely missing an edge case where the > difference makes sense). Let's take a general try..end construct: try f() of {ok,A} -> B = {a,A}; {error,A} -> C = {r,A} catch error:Error -> {error,Error}; exit:Exit -> {exit,Exit} after G = {A,B,C,Error,Exit} % which bound? end, {A,B,C,Error,Exit,G} % which bound? Now, which variables should be bound in the after..end section, and which should be bound after the end? It would be nice if A was safe somwhere after the of..catch section just as for the of..end section in case constructs, but since we might get an exception anywhere we might not have bound A neither when reaching any clause in the catch..after section, nor the after..end section and certainly not after the end. The only safe binding could be the variable G since the after..end section is always executed. So variables from the after..end section could have been exported, but not any other. But in that special case below withount a catch..after section the case construct rules could hold. There might be other special cases. But for the sake of consistency the simplest rule is that no variables are exported from the try..end construct. / Raimo Niskanen > > > Cheers, > -- > Pierre Fenoll > > > On 20 November 2014 14:22, Kostis Sagonas wrote: > > > On 11/20/14 15:13, Anthony Ramine wrote: > > > >> try file:read(F, 1024 * 1024) of > >> {ok,Bin} -> binary_to_term(Bin) > >> after > >> file:close(F) > >> end > >> > > > > > > And the reason to _having_ to write this is? (*) > > > > Cheers, > > Kostis > > > > (*) Less bugs are exposed in the compiler and less baby cats die in China > > if we all write like that, perhaps? :) > > > > Jokes aside, I also agree the above code is nicer, but that does not mean > > that the current warning is bogus and the analysis should be fixed. > > > > _______________________________________________ > > 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 -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From nicolas.dudebout@REDACTED Sun Nov 23 12:53:58 2014 From: nicolas.dudebout@REDACTED (Nicolas Dudebout) Date: Sun, 23 Nov 2014 06:53:58 -0500 Subject: [erlang-bugs] Dialyzer re-factoring in maint fixes a bug and should make it to maint-17 Message-ID: The "minor re-factoring" mentioned in https://github.com/erlang/otp/commit/197a8467f465930372f31c8f8b7340f8339aa23a actually fixes a bug. cleanup_compile_options/1 is supposed to filter out elements from a list. However, the original implementation does not recurse properly and filters out at most one option. The re-factored implementation does not have this problem. This bug is preventing me from creating a PLT file for some libraries compiled with r16b03 by using the dialyzer included with 17.3. Applying this patch solves the problem. I think that this patch should be applied to maint-17. Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.dudebout@REDACTED Sun Nov 23 12:56:20 2014 From: nicolas.dudebout@REDACTED (Nicolas Dudebout) Date: Sun, 23 Nov 2014 06:56:20 -0500 Subject: [erlang-bugs] Dialyzer does not check record update types Message-ID: Dialyzer checks the type of record elements when creating them but not when updating them. Pasted below is a minimal working example. Nicolas -module(test). -export([ baz/1, quux/2 ]). -type bar() :: atom(). -type notbar() :: string(). -record(foo, { bar :: bar() }). % CORRECT: Dialyzer generates a warning % test.erl:13: Invalid type specification for function test:baz/1. The success typing is (atom()) -> #foo{bar::atom()} -spec baz(notbar()) -> #foo{}. baz(NotBar) -> #foo{ bar = NotBar }. % INCORECT: Dialyzer does not say anything -spec quux(#foo{}, notbar()) -> #foo{}. quux(Foo, NotBar) -> Foo#foo{ bar = NotBar }. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.bolinder@REDACTED Mon Nov 24 17:52:13 2014 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 24 Nov 2014 16:52:13 +0000 Subject: [erlang-bugs] Dialyzer does not check record update types In-Reply-To: References: Message-ID: <56466BD70414EA48969B4064696CF28C21E3D3E8@ESESSMB207.ericsson.se> Hi, > Dialyzer checks the type of record elements when creating them but not when > updating them. Pasted below is a minimal working example. Thank you. A correction will appear on the maint branch shortly. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.ryabkov@REDACTED Tue Nov 25 05:08:23 2014 From: anton.ryabkov@REDACTED (Anton Ryabkov) Date: Tue, 25 Nov 2014 11:08:23 +0700 Subject: [erlang-bugs] xmerl_xsd validation failed on attribute list's type Message-ID: Hello, on Erlang R16B03, R17.0 I've found that xmerl_xsd doesn't validate xml, that contains list's type element attribute. Validation failed with error: {error, [{[],xmerl_xsd, {could_not_check_value_for_type, {list,[{simpleType,{item,[],[]}}]}}}]} Steps to reproduce: 1. Untar archive in one directory. 2. compile xsd_list_attr_test.erl 3. xsd_list_attr_test:test(). 4. look at erlang console. There will be printed: Validation result: {error, [{[],xmerl_xsd, {could_not_check_value_for_type, {list,[{simpleType,{item,[],[]}}]}}}]} -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xmerl_xsd_list_attribute_validation_bug.tar.gz Type: application/x-gzip Size: 729 bytes Desc: not available URL: From tuncer.ayaz@REDACTED Wed Nov 26 12:29:13 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 26 Nov 2014 12:29:13 +0100 Subject: [erlang-bugs] UBsan int overflows In-Reply-To: References: <541FF3B5.8000304@erlang.org> Message-ID: On Tue, Sep 23, 2014 at 11:05 AM, Tuncer Ayaz wrote: > On Mon, Sep 22, 2014 at 12:02 PM, Lukas Larsson wrote: > > > > On 17/09/14 19:23, Tuncer Ayaz wrote: > > > > > > On Wed, Sep 17, 2014 at 2:33 PM, Tuncer Ayaz wrote: > > > > > > > > Building OTP-17.3 with --enable-sanitizers=undefined, you can see > > > > the following during the build of lib/wx/examples/demo: > > > > ERLC ex_aui.beam > > > > beam/bif.c:2828:5: runtime error: signed integer overflow: > > > > 426141286 * 10 cannot be represented in type 'int' > > > > > > > > I thought this was also fixed. > > > > As did I. I wonder where that fix went... I've created a new fix > > for it. > > > > > More during dialyzer --build_plt: > > > beam/erl_process.c:9024:2: runtime error: signed integer overflow: > > > 2147482509 + 2001 cannot be represented in type 'int' > > > beam/erl_process.c:4908:35: runtime error: signed integer overflow: > > > 3984 * 625175 cannot be represented in type 'int' > > > > > I've noticed these as well and a couple of other ones in > > erl_process.c. I've added them to our backlog to fix. > > Thanks, and please keep us posted. What's the status? From lukas@REDACTED Wed Nov 26 15:14:12 2014 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 26 Nov 2014 15:14:12 +0100 Subject: [erlang-bugs] UBsan int overflows In-Reply-To: References: <541FF3B5.8000304@erlang.org> Message-ID: <5475E034.3030100@erlang.org> On 26/11/14 12:29, Tuncer Ayaz wrote: > On Tue, Sep 23, 2014 at 11:05 AM, Tuncer Ayaz wrote: >> On Mon, Sep 22, 2014 at 12:02 PM, Lukas Larsson wrote: >>> On 17/09/14 19:23, Tuncer Ayaz wrote: >>>> On Wed, Sep 17, 2014 at 2:33 PM, Tuncer Ayaz wrote: >>>>> Building OTP-17.3 with --enable-sanitizers=undefined, you can see >>>>> the following during the build of lib/wx/examples/demo: >>>>> ERLC ex_aui.beam >>>>> beam/bif.c:2828:5: runtime error: signed integer overflow: >>>>> 426141286 * 10 cannot be represented in type 'int' >>>>> >>>>> I thought this was also fixed. >>> As did I. I wonder where that fix went... I've created a new fix >>> for it. >>> >>>> More during dialyzer --build_plt: >>>> beam/erl_process.c:9024:2: runtime error: signed integer overflow: >>>> 2147482509 + 2001 cannot be represented in type 'int' >>>> beam/erl_process.c:4908:35: runtime error: signed integer overflow: >>>> 3984 * 625175 cannot be represented in type 'int' >>>> >>> I've noticed these as well and a couple of other ones in >>> erl_process.c. I've added them to our backlog to fix. >> Thanks, and please keep us posted. > What's the status? bif.c has been fixed, erl_process.c has not been fixed yet. From mattias.waldau@REDACTED Thu Nov 27 11:21:41 2014 From: mattias.waldau@REDACTED (Mattias Waldau) Date: Thu, 27 Nov 2014 11:21:41 +0100 Subject: [erlang-bugs] Minor issue: dialyzer on ARM: Compiling some key modules to native code => Illegal instruction (core dumped) Message-ID: Hi, I found the --no_native flag, so dialyzer is working nicely. I just wanted to report this. I made build from src. Downloaded zip from github today (2014-11-27). I have run the test suite, no complaints. Thanks, Mattias Ps. I am playing with Erlang on a ARM Chromebook with crouton system (Samsung Chome 2,for $200). Very usable. About half speed of this Exynos 5 Octa 1.9GHz compared to a Intel Core i5-2450, 2.4 Ghz. From mikpelinux@REDACTED Thu Nov 27 11:39:21 2014 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Thu, 27 Nov 2014 11:39:21 +0100 Subject: [erlang-bugs] Minor issue: dialyzer on ARM: Compiling some key modules to native code => Illegal instruction (core dumped) In-Reply-To: References: Message-ID: <21622.65369.884416.792705@gargle.gargle.HOWL> Mattias Waldau writes: > Hi, > > I found the --no_native flag, so dialyzer is working nicely. I just > wanted to report this. > > I made build from src. Downloaded zip from github today (2014-11-27). I > have run the test suite, no complaints. > > Thanks, > > Mattias > > Ps. I am playing with Erlang on a ARM Chromebook with crouton system > (Samsung Chome 2,for $200). Very usable. About half speed of this Exynos > 5 Octa 1.9GHz compared to a Intel Core i5-2450, 2.4 Ghz. Please run the beam processs under gdb (you can attach to it from another shell using gdb --pid), do whatever is needed to trigger the SIGILL, then (in gdb which should now show the SIGILL) disassemble the faulting instruction and show us that and the register values. HiPE generates ARMv5 code which should work on newer generations too. From tuncer.ayaz@REDACTED Sun Nov 30 19:04:40 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 30 Nov 2014 19:04:40 +0100 Subject: [erlang-bugs] The description of dict:fold/3 In-Reply-To: <54578E7D.4050305@ericsson.com> References: <53B2764E.6060807@ericsson.com> <53B2D230.2020809@ericsson.com> <53B402D0.9070607@ericsson.com> <54578E7D.4050305@ericsson.com> Message-ID: On Mon, Nov 3, 2014 at 3:17 PM, Rabbe Fogelholm wrote: > On the page > > http://www.erlang.org/doc/man/dict.html#fold-3 > > in the description of fold/3 the wording > > "if the list is empty" > > should most likely be > > "if the dict is empty" No responses here, so I've included a fix as part of https://github.com/erlang/otp/pull/548