From mikpe@REDACTED Thu Aug 3 14:05:02 2006 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 3 Aug 2006 14:05:02 +0200 (MEST) Subject: HiPE bug with nested try/catch Message-ID: <200608031205.k73C52Xk012340@alkaid.it.uu.se> On Fri, 21 Jul 2006 09:09:03 +0100, Trap Exit wrote: (badly encoding-damaged) >According to the Erlang ref. manual: >Quote: >If an exception occurs during evaluation of Expr but there is no matching ExceptionPattern of the right Class with a true guard sequence, the exception is passed on as if Expr had not been enclosed in a try expression. >(end of quote) > > >So I constructed the following example and noticed that it behaved differently when HiPE compiled. > > >-module(trycatch). > > >-export([main/0]). > >main() -> > try > f() > catch > throw:Throw -> > io:format("gotcha: ~p~n", [Throw]) > end. > >f() -> > try > throw('i.wonder.who.will.catch.me') > catch > error:Error -> > io:format("function f caused an error: ~p~n", [Error]) > end. > > > >Erlang (BEAM) emulator version 5.5 [source] [async-threads:0] [hipe] > >Eshell V5.5 (abort with ^G) >1> c(trycatch). >{ok,trycatch} >2> trycatch:main(). >gotcha: 'i.wonder.who.will.catch.me' >ok >3> c(trycatch,native). >{ok,trycatch} >4> trycatch:main(). > >=ERROR REPORT==== 21-Jul-2006::09:56:33 === >Error in process <0.32.0> with exit value: {undef,[{erlang,raise,[[[{erlang,raise,[[true|16#4044646A0000000000000000000000000000006A],'i.wonder.who.will.catch.me']},{erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]|-16#0000000000000000000000000010],undef]},{erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]} > >** exited {undef,[{erlang,raise, > [[[{erlang,raise, > [[true| > 366900607304749881568687426529269484530033492074], > 'i.wonder.who.will.catch.me']}, > {erl_eval,do_apply,5}, > {shell,exprs,6}, > {shell,eval_loop,3}]| > -00000000000000000016], > undef]}, > {erl_eval,do_apply,5}, > {shell,exprs,6}, > {shell,eval_loop,3}]} ** Thanks for reporting this. The bug has been fixed and the fix will be included in the next OTP-R11B update. In the mean time you can use the patch below. /Mikael Pettersson The HiPE Team --- otp-0704/lib/compiler/src/beam_disasm.erl.~1~ 2006-06-27 15:58:34.000000000 +0200 +++ otp-0704/lib/compiler/src/beam_disasm.erl 2006-08-03 12:48:02.000000000 +0200 @@ -850,7 +850,8 @@ resolve_inst({try_case,[Reg]},_,_,_) -> resolve_inst({try_case_end,[Arg]},_,_,_) -> {try_case_end,resolve_arg(Arg)}; resolve_inst({raise,[Reg1,Reg2]},_,_,_) -> - {bif,raise,{f,0},[Reg1,Reg2],{x,0}}; + {raise,{f,0},[Reg1,Reg2],{x,0}}; % do NOT wrap this as a 'bif' + % as there is no raise/2 bif! %% %% New bit syntax instructions added in February 2004 (R10B). --- otp-0704/lib/hipe/icode/hipe_beam_to_icode.erl.~1~ 2006-06-01 11:29:34.000000000 +0200 +++ otp-0704/lib/hipe/icode/hipe_beam_to_icode.erl 2006-08-03 12:48:43.000000000 +0200 @@ -575,7 +575,7 @@ trans_fun([{try_case_end,Arg}|Instructio Fail = hipe_icode:mk_fail([V],error), [Atom,Tuple,Fail | trans_fun(Instructions,Env)]; %%--- raise --- -trans_fun([{bif,raise,{f,0},[Reg1,Reg2],{x,0}}|Instructions], Env) -> +trans_fun([{raise,{f,0},[Reg1,Reg2],{x,0}}|Instructions], Env) -> V1 = trans_arg(Reg1), V2 = trans_arg(Reg2), Fail = hipe_icode:mk_fail([V1,V2],rethrow), From demius_md@REDACTED Wed Aug 9 10:52:16 2006 From: demius_md@REDACTED (Demius Academius) Date: Wed, 09 Aug 2006 11:52:16 +0300 Subject: list_to_float Message-ID: <44D9A240.1010902@mail.ru> list_to_float("0") exited with badarg it must work as list_to_float("0.0") From hokan.stenholm@REDACTED Wed Aug 9 19:56:16 2006 From: hokan.stenholm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Stenholm?=) Date: Wed, 09 Aug 2006 19:56:16 +0200 Subject: list_to_float In-Reply-To: <44D9A240.1010902@mail.ru> References: <44D9A240.1010902@mail.ru> Message-ID: <44DA21C0.6090205@bredband.net> Demius Academius wrote: > list_to_float("0") exited with badarg > it must work as list_to_float("0.0") > you'll have to do something like: str_to_float(Str) -> try float(list_to_integer(Str)) catch error:_ -> list_to_float(Str) end. or str_to_float(Str) -> case string:to_float(Str) of {error, no_float} -> {Int, []} = case string:to_integer(Str), float(Int); {Float, []} -> Float end. as "0" is considered a integer(), while "0.0" is treated as a float(). But I agree that it would be much nicer if list_to_float/1 and string:to_float/1 would do this by themselves. From jamesh@REDACTED Wed Aug 9 20:06:49 2006 From: jamesh@REDACTED (James Hague) Date: Wed, 9 Aug 2006 13:06:49 -0500 Subject: list_to_float Message-ID: Actually list_to_number would be a good standard library addition. It would call list_to_integer first, then if that failed, call list_to_float. -----Original Message----- From: owner-erlang-bugs@REDACTED [mailto:owner-erlang-bugs@REDACTED] On Behalf Of H?kan Stenholm Sent: Wednesday, August 09, 2006 12:56 PM To: Demius Academius Cc: erlang-bugs@REDACTED Subject: Re: list_to_float Demius Academius wrote: > list_to_float("0") exited with badarg > it must work as list_to_float("0.0") > you'll have to do something like: str_to_float(Str) -> try float(list_to_integer(Str)) catch error:_ -> list_to_float(Str) end. or str_to_float(Str) -> case string:to_float(Str) of {error, no_float} -> {Int, []} = case string:to_integer(Str), float(Int); {Float, []} -> Float end. as "0" is considered a integer(), while "0.0" is treated as a float(). But I agree that it would be much nicer if list_to_float/1 and string:to_float/1 would do this by themselves. From dmitry.kargapolov@REDACTED Wed Aug 9 20:23:14 2006 From: dmitry.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Wed, 09 Aug 2006 14:23:14 -0400 Subject: list_to_float In-Reply-To: References: Message-ID: <44DA2812.3070909@corp.idt.net> As I understand the name "list_to_float" means conversion _to_ float (not integer!) from _some_ list representation. The current implementation is limited to string only argument - this is reasonable, but it's not clear why implementation is limited to narrow X.X representation? Couldn't float be expressed as "0"? As to list_to_number idea, what type of result is expected? Depending on argument text representation? James Hague wrote: > Actually list_to_number would be a good standard library addition. It would > call list_to_integer first, then if that failed, call list_to_float. > > -----Original Message----- > From: owner-erlang-bugs@REDACTED [mailto:owner-erlang-bugs@REDACTED] On > Behalf Of H?kan Stenholm > Sent: Wednesday, August 09, 2006 12:56 PM > To: Demius Academius > Cc: erlang-bugs@REDACTED > Subject: Re: list_to_float > > Demius Academius wrote: > >> list_to_float("0") exited with badarg >> it must work as list_to_float("0.0") >> > you'll have to do something like: > > str_to_float(Str) -> > try float(list_to_integer(Str)) > catch error:_ -> list_to_float(Str) > end. > > or > > str_to_float(Str) -> > case string:to_float(Str) of > {error, no_float} -> > {Int, []} = case string:to_integer(Str), > float(Int); > {Float, []} -> Float > end. > > as "0" is considered a integer(), while "0.0" is treated as a float(). > But I agree that it would be much nicer if list_to_float/1 and > string:to_float/1 would do this by themselves. > From jamesh@REDACTED Wed Aug 9 20:28:14 2006 From: jamesh@REDACTED (James Hague) Date: Wed, 9 Aug 2006 13:28:14 -0500 Subject: list_to_float Message-ID: >The current implementation is limited to string only argument - this is >reasonable, but it's not clear why implementation is limited to narrow >X.X representation? Couldn't float be expressed as "0"? "0" in Erlang means "integer zero." You need to specify "0.0" for a float. Try these in the shell: is_integer(0 + 1). % gives true is_integer(0.0 + 1). % gives false >As to list_to_number idea, what type of result is expected? Depending on >argument text representation? Correct. It's analogous to the is_number function, which checks if a value is either an integer or float. From dmitry.kargapolov@REDACTED Wed Aug 9 22:03:22 2006 From: dmitry.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Wed, 09 Aug 2006 16:03:22 -0400 Subject: list_to_float In-Reply-To: References: Message-ID: <44DA3F8A.8050004@corp.idt.net> I was just trying to say that I don't see any reason for such limitation when we're converting from string to float. James Hague wrote: >> The current implementation is limited to string only argument - this is >> reasonable, but it's not clear why implementation is limited to narrow >> X.X representation? Couldn't float be expressed as "0"? > > "0" in Erlang means "integer zero." You need to specify "0.0" for a float. Depends on context. If you are talking about term syntax (as in an example below) yes, I agree. If we're considering external text that should be interpreted (during the IO operations) as an integer or float, no, I do not agree that there is any reason to limit text representation when we know what we want to have as the result of conversion. > Try these in the shell: > > is_integer(0 + 1). % gives true > is_integer(0.0 + 1). % gives false > >> As to list_to_number idea, what type of result is expected? Depending on >> argument text representation? > > Correct. It's analogous to the is_number function, which checks if a value > is either an integer or float. > From raimo@REDACTED Thu Aug 10 11:10:48 2006 From: raimo@REDACTED (Raimo Niskanen) Date: 10 Aug 2006 11:10:48 +0200 Subject: list_to_float References: <44D9A240.1010902@mail.ru> Message-ID: There have been external and internal discussions about this one. Anyway, the semantics can not be changed now. There must be lots of written code that relies on an exception from erlang:list_to_float("0"), since it is not a valid erlang float - it is an integer. An erlang:list_to_number/1 might be an useful addition, but it is easy enough to write for yourself. If such a function is desired, I can imagine an an erlang:list_to_term/1 also (instead?) would be. It should do all the erl_scan:string(S), erl_parse:parse_term(T) that repeatedly pops up on erlang-questions. Erlang shell example: 1> f(S),S="{tuple}",f(T),{ok,T,_}=erl_scan:string(S++"."). 2> f(X),{ok,X}=erl_parse:parse_term(T),X. {tuple} But that is a beast that involves erl_scan and erl_parse functionality into the erlang module itself - mixing run-time with compile-time. It might fit better into some other module, the question remains which. Enough rambling. Here is another fix for your problem: how_to_float(S) -> case string:to_float(S++".0") of {F,_} when is_float(F) -> F; _ -> erlang:error(badarg, [S]); end. Assuming S is known to not be huge. You probably only need to pick out the best parts of the case statement (you get the idea, ``string:to_float(S++".0")'' is the trick). demius_md@REDACTED (Demius Academius) writes: > list_to_float("0") exited with badarg > it must work as list_to_float("0.0") -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From theman@REDACTED Thu Aug 24 22:51:30 2006 From: theman@REDACTED (Eric Radman) Date: Thu, 24 Aug 2006 15:51:30 -0500 Subject: panic on NetBSD/sparc Message-ID: <20060824205130.GA18555@us270-gl0.eradman.com> Hi, When trying to compile erlang-10.1.10 from pkgsrc on NetBSD/sparc it fails tragically with: checking for unreliable floating point exceptions... panic: fpu_cleanup: NO fault syncing disks... Then the system hangs. Is there a way to bypass this test on sparc? --?? Eric Radman | http://eradman.com From mikpe@REDACTED Fri Aug 25 10:36:34 2006 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 25 Aug 2006 10:36:34 +0200 (MEST) Subject: panic on NetBSD/sparc Message-ID: <200608250836.k7P8aYRE016122@harpo.it.uu.se> On Thu, 24 Aug 2006 15:51:30 -0500, Eric Radman wrote: > When trying to compile erlang-10.1.10 from pkgsrc on NetBSD/sparc it > fails tragically with: > > checking for unreliable floating point exceptions... panic: fpu_cleanup: > NO fault > syncing disks... > > Then the system hangs. Is there a way to bypass this test on sparc? Only by hacking erts/configure so that the embedded fpe-test.c file doesn't compile or does exit(1) before fiddling with your SPARC's FPU. But that is one _seriously_ broken kernel. Surely fixing the kernel is more appropriate than limiting Erlang? From pedro.gomes@REDACTED Thu Aug 31 13:49:42 2006 From: pedro.gomes@REDACTED (Gomes, Pedro) Date: Thu, 31 Aug 2006 12:49:42 +0100 Subject: FW: Question about debug info Message-ID: <82A8DA06D22E154E82F14B9C5F62A2E04BD751@PTLISI051MSX.PT001.SIEMENS.NET> -----Original Message----- From: Gomes, Pedro Sent: quinta-feira, 31 de Agosto de 2006 12:48 To: 'erlang-bugs@REDACTED' Subject: FW: Question about debug info Can this situation be checked ? Pedro -----Original Message----- From: Gaspar Chilingarov [mailto:nm@REDACTED] Sent: quinta-feira, 31 de Agosto de 2006 12:14 To: Gomes, Pedro Subject: Re: Question about debug info Gomes, Pedro wrote: > Hello, > Thanks it does work yes! But then it seems that the erlang compiler is > not parsing or processing the -compile clause as it documented rigth? > > Pedro well, I had also problems with it, but had no time to investigate things further. :) Gaspar > > -----Original Message----- > From: Gaspar Chilingarov [mailto:nm@REDACTED] > Sent: quinta-feira, 31 de Agosto de 2006 10:07 > To: Gomes, Pedro > Subject: Re: Question about debug info > > Gomes, Pedro wrote: >> Hello All, >> I tryed to use the Erlang debugger and in order to do it I need to >> compile the source modules with debug info and for that matter I used >> -compile(debug_info) >> >> This seems to have no effect, even if the .beam module increases its >> size, because the debugger still continues to issue an error saying >> there no debug information present in the .beam module. >> >> What am I doing wrong ? >> >> Thanks, >> Pedro >> > > Would this help? > http://gasparch.blogspot.com/2006/08/erlang-programming-starting-visual. > html > -- Gaspar Chilingarov System Administrator, Network security consulting t +37493 419763 (mob) i 63174784 e nm@REDACTED From richardc@REDACTED Thu Aug 31 14:18:59 2006 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 31 Aug 2006 14:18:59 +0200 Subject: FW: Question about debug info In-Reply-To: <82A8DA06D22E154E82F14B9C5F62A2E04BD751@PTLISI051MSX.PT001.SIEMENS.NET> References: <82A8DA06D22E154E82F14B9C5F62A2E04BD751@PTLISI051MSX.PT001.SIEMENS.NET> Message-ID: <44F6D3B3.4040201@it.uu.se> Gomes, Pedro wrote: > Can this situation be checked ? Try this (after recompiling and reloading the module): 1> mymodule:module_info(compile). [{options,[... ...]}, ...] 2> and see if the options list contains 'debug_info'. /Richard