From mazen.harake@REDACTED Fri Oct 9 13:14:54 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Fri, 09 Oct 2009 13:14:54 +0200 Subject: wx_object fixes. Message-ID: <4ACF1B2E.7060908@erlang-consulting.com> I've attached a patch that fixes two issues with the wx_object.erl file. 1) I removed a pattern match in the start functions so that if a server returns {stop, ...} in the init function it doesn't crash with a badmatch error. 2) I added 2 call functions which makes it possible to call an wx_object using the registered name that was used when creating the object. Currently it was only possible to make a call to an object when you have the reference and not by name. I have tested it in normal cases but I can't guarantee 100% bugfree fixes :D This patch will get anyone going until these issues are fixed (or patch applied) to the release. cheers, /Mazen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wx_object.patch URL: From dangud@REDACTED Fri Oct 9 14:50:33 2009 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 9 Oct 2009 14:50:33 +0200 Subject: [erlang-patches] wx_object fixes. In-Reply-To: <4ACF1B2E.7060908@erlang-consulting.com> References: <4ACF1B2E.7060908@erlang-consulting.com> Message-ID: <93df43b60910090550y4d56abcag6366a08d34085c3e@mail.gmail.com> Thanks I'll have look at it. /Dan On Fri, Oct 9, 2009 at 1:14 PM, Mazen Harake wrote: > I've attached a patch that fixes two issues with the wx_object.erl file. > > 1) I removed a pattern match in the start functions so that if a server > returns {stop, ...} in the init function it doesn't crash with a badmatch > error. > > 2) I added 2 call functions which makes it possible to call an wx_object > using the registered name that was used when creating the object. Currently > it was only possible to make a call to an object when you have the reference > and not by name. > > I have tested it in normal cases but I can't guarantee 100% bugfree fixes :D > This patch will get anyone going until these issues are fixed (or patch > applied) to the release. > > cheers, > > /Mazen > > --- wx_object.original.erl ? ? ?2009-09-25 23:22:12.810000000 +0200 > +++ wx_object.erl ? ? ? 2009-10-09 12:22:13.115710400 +0200 > @@ -143,8 +143,7 @@ > ?%% @doc Starts a generic wx_object server and invokes Mod:init(Args) in the > ?%% new process. > ?start(Mod, Args, Options) -> > - ? ?{ok, Pid} = gen:start(?MODULE, nolink, Mod, Args, > [get(?WXE_IDENTIFIER)|Options]), > - ? ?receive {ack, Pid, Ref = #wx_ref{}} -> Ref end. > + ? ?gen_response(gen:start(?MODULE, nolink, Mod, Args, > [get(?WXE_IDENTIFIER)|Options])). > > ?%% @spec (Name, Mod, Args, Options) -> wxWindow:wxWindow() > ?%% ? Name = {local, atom()} > @@ -155,8 +154,7 @@ > ?%% @doc Starts a generic wx_object server and invokes Mod:init(Args) in the > ?%% new process. > ?start(Name, Mod, Args, Options) -> > - ? ?{ok, Pid} = gen:start(?MODULE, nolink, Name, Mod, Args, > [get(?WXE_IDENTIFIER)|Options]), > - ? ?receive {ack, Pid, Ref = #wx_ref{}} -> Ref end. > + ? ?gen_response(gen:start(?MODULE, nolink, Name, Mod, Args, > [get(?WXE_IDENTIFIER)|Options])). > > ?%% @spec (Mod, Args, Options) -> wxWindow:wxWindow() > ?%% ? Mod = atom() > @@ -166,8 +164,7 @@ > ?%% @doc Starts a generic wx_object server and invokes Mod:init(Args) in the > ?%% new process. > ?start_link(Mod, Args, Options) -> > - ? ?{ok, Pid} = gen:start(?MODULE, link, Mod, Args, > [get(?WXE_IDENTIFIER)|Options]), > - ? ?receive {ack, Pid, Ref = #wx_ref{}} -> Ref end. > + ? ?gen_response(gen:start(?MODULE, link, Mod, Args, > [get(?WXE_IDENTIFIER)|Options])). > > ?%% @spec (Name, Mod, Args, Options) -> wxWindow:wxWindow() > ?%% ? Name = {local, atom()} > @@ -177,9 +174,13 @@ > ?%% ? Flag = trace | log | {logfile, File} | statistics | debug > ?%% @doc Starts a generic wx_object server and invokes Mod:init(Args) in the > ?%% new process. > -start_link(Name, Mod, Args, Options) -> > - ? ?{ok, Pid} = gen:start(?MODULE, link, Name, Mod, Args, > [get(?WXE_IDENTIFIER)|Options]), > - ? ?receive {ack, Pid, Ref = #wx_ref{}} -> Ref end. > +start_link(Name, Mod, Args, Options) -> > + ? ?gen_response(gen:start(?MODULE, link, Name, Mod, Args, > [get(?WXE_IDENTIFIER)|Options])). > + > +gen_response({ok, Pid}) -> > + ? ?receive {ack, Pid, Ref = #wx_ref{}} -> Ref end; > +gen_response(Reply) -> > + ? ?Reply. > > ?%% @spec(wxObject(), Request) -> term() > ?%% @doc Make a call to a wx_object server. > @@ -190,7 +191,18 @@ > ? ? ? ?Res > ? ? catch _:Reason -> > ? ? ? ? ? ?erlang:error({Reason, {?MODULE, call, [Ref, Request]}}) > - ? ?end. > + ? ?end; > +%% @spec(atom(), Request) -> term() > +%% @doc Make a call to a registered wx_object server > +%% Invokes handle_call(Request, From, State) in server > +call(Name, Request) when is_atom(Name) -> > + ? ?try > + ? ? ? ?{ok,Res} = gen:call(Name, '$gen_call', Request), > + ? ? ? ?Res > + ? ?catch _:Reason -> > + ? ? ? ? ? ?erlang:error({Reason, {?MODULE, call, [Name, Request]}}) > + ? ?end. > + > ?%% @spec(wxObject(), Request, integer()) -> term() > ?%% @doc Make a call to a wx_object server. > ?%% Invokes handle_call(Request, From, State) in server > @@ -200,6 +212,16 @@ > ? ? ? ?Res > ? ? catch _:Reason -> > ? ? ? ? ? ?erlang:error({Reason, {?MODULE, call, [Ref, Request, Timeout]}}) > + ? ?end; > +%% @spec(atom(), Request, integer()) -> term() > +%% @doc Make a call to a registered wx_object server > +%% Invokes handle_call(Request, From, State) in server > +call(Name, Request, Timeout) when is_atom(Name) -> > + ? ?try > + ? ? ? ?{ok,Res} = gen:call(Name, '$gen_call', Request, Timeout), > + ? ? ? ?Res > + ? ?catch _:Reason -> > + ? ? ? ? ? ?erlang:error({Reason, {?MODULE, call, [Name, Request, > Timeout]}}) > ? ? end. > > ?%% ----------------------------------------------------------------- > > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org > From christopher.faulet@REDACTED Fri Oct 9 16:31:44 2009 From: christopher.faulet@REDACTED (christopher faulet) Date: Fri, 09 Oct 2009 16:31:44 +0200 Subject: Epp Bugfix and macros overloading Message-ID: <4ACF4950.4070409@capflam.org> Hi all, Here are two patches for the module epp in R13B02-1. * The first one fixes a bug in the function scan_undef. The dict that helps to find circular macros is not correctly updated. Here is an example: ============================= -module(test). -export([test/0]). -define(FOO(X), ?BAR(X)). -define(BAR(X), ?FOO(X)). -undef(FOO). test() -> ?BAR(1). ============================= On the last line, the preprocessor should found that 'FOO' is undefined. But, with the current version, it finds a cycle between FOO and BAR. * The second patch includes the first one and adds support of multiple definitions for macros in the module epp (i.e. with the same name but with different arities). This feature wouldn't break any code (I hope so :) and might be usefull. Here is an simple example that uses it: ============================= -module(test). -export([test/0]). -define(MY_MACRO(), foo). -define(MY_MACRO, bar). -define(MY_MACRO(X,Y), {X, Y}). test() -> %% return [bar, foo, foo, {foo, bar}] [ ?MY_MACRO, %% use the 2nd def, replaced by bar ?MY_MACRO(), %% use the 1st def, replaced by foo ?MY_MACRO(foo), %% use the 2nd def, replaced by bar(foo) ?MY_MACRO(foo, bar) %% use the 3rd def, replaced by {foo,bar} ]. bar(X) -> X. ============================= In this patch, we follow these rules: - the overloading of predefined macros (?MODULE, ?LINE, ...) is forbidden - the directive '-undef' removes all definitions of a macro - when a macro is called, the preprocessor tries to match the definition with the right number of arguments. If it fails, it uses the constant definition, if there is one, else returns an error. - the circular definitions are checked following the previous rule. It would be interesting to add this feature. What do you think about it? Best regards, -- Christopher Faulet -------------- next part -------------- A non-text attachment was scrubbed... Name: bugfix-epp-R13B02-1.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: overload-epp-R13B02-1.patch Type: text/x-patch Size: 10034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From christopher.faulet@REDACTED Fri Oct 9 16:38:56 2009 From: christopher.faulet@REDACTED (christopher faulet) Date: Fri, 09 Oct 2009 16:38:56 +0200 Subject: Some bugfixes in ei_x_format in R13B02-1 Message-ID: <4ACF4B00.5010601@capflam.org> Hi all, the attached patch fixes some bugs in functions that build terms from strings, called by ei_x_format and ei_x_format_wo_ver. It improves the parsing of lists, tuples, strings, atoms and digits. The file test_ei.c in attachement shows examples that ei_x_format doesn't parse correctly. In addition, I added support of hexadecimal representations of digit. This patch also fixes a bug in erl_call. When we use the option "-a 'Mod Fun Args'", the module and function are extracted and the remainings are passed to ei_x_format_wo_ver in order to build arguments before calling the function ei_rpc. The problem is that this function tries to replace all ~a,~s,~i... But in this context, it's a mistake. To avoid this behaviour, I added a new function, ei_x_parse, that transforms a string in erlang term without any replacement. Here is an example: * the following command returns an error instead of ["test"]: erl_call -sname bug_ei -s -a 'io_lib format ["~p", [test]]' I only tested this patch on linux but I hope that it works on other OS. Best regards, -- Christopher Faulet -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_interface-R13B02-1.patch Type: text/x-patch Size: 13830 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_ei.c Type: text/x-csrc Size: 6305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From egil@REDACTED Fri Oct 9 17:43:10 2009 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 09 Oct 2009 17:43:10 +0200 Subject: [erlang-patches] Some bugfixes in ei_x_format in R13B02-1 In-Reply-To: <4ACF4B00.5010601@capflam.org> References: <4ACF4B00.5010601@capflam.org> Message-ID: <4ACF5A0E.5010005@erix.ericsson.se> Hi Cristopher, Thank your for pointing out these issues and supplying a patch for it. I will have a look at it as soon as I can. Regards, Bj?rn-Egil Erlang/OTP christopher faulet wrote: > Hi all, > > the attached patch fixes some bugs in functions that build terms from > strings, called by ei_x_format and ei_x_format_wo_ver. It improves the > parsing of lists, tuples, strings, atoms and digits. The file test_ei.c > in attachement shows examples that ei_x_format doesn't parse correctly. > > In addition, I added support of hexadecimal representations of digit. > > This patch also fixes a bug in erl_call. When we use the option "-a 'Mod > Fun Args'", the module and function are extracted and the remainings are > passed to ei_x_format_wo_ver in order to build arguments before calling > the function ei_rpc. The problem is that this function tries to replace > all ~a,~s,~i... But in this context, it's a mistake. To avoid this > behaviour, I added a new function, ei_x_parse, that transforms a string > in erlang term without any replacement. Here is an example: > > * the following command returns an error instead of ["test"]: > erl_call -sname bug_ei -s -a 'io_lib format ["~p", [test]]' > > I only tested this patch on linux but I hope that it works on other OS. > > Best regards, > From andrew@REDACTED Fri Oct 9 19:47:43 2009 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 9 Oct 2009 13:47:43 -0400 Subject: PATCH: ODBC application discarding sqlstate in get_diagnos function Message-ID: <20091009174743.GJ11500@hijacked.us> Hi, I've been using the ODBC application against a unixodbc/mysql setup for a while now and its been bothering me that ANY SQL error always returns {port_exit,could_not_access_column_count} from the erlang side. I decided to dig into the code and figure out why and this is what I discovered: In the get_diagnos function of odbcserver.c every time SQLGetDiagRec is called diagnos.sqlState is passed in as the target to write the returned SQLSTATE into. However, when you've run out of diagnostic information and SQLGetDiagRec() returns something other than SQL_SUCCESS, the value of diagnos.sqlState *still* gets changed (at least in my case) to 00000, which is, of course, the INFO SQLSTATE. This causes the check in db_query against INFO to succeed when it should be failing and since in my case the error message didn't begin with 'error' it falls through encode_result which is where the EXIT_COLS comes in. Attached is a patch to resolve this problem by only updating diagnos.sqlState when SQLGetDiagRec returns success. I don't know if all ODBC implementations behave this way, but I'd assume that the SQLSTATE from a failed SQLGetDiagRec can safely be ignored in all cases. Thanks, Andrew -------------- next part -------------- --- c_src/odbcserver.c.orig 2009-10-09 13:11:01.000000000 -0400 +++ c_src/odbcserver.c 2009-10-09 13:20:21.000000000 -0400 @@ -2451,6 +2451,7 @@ SQLSMALLINT errmsg_buffer_size, record_nr, errmsg_size; int acc_errmsg_size; byte *current_errmsg_pos; + SQLCHAR current_sql_state[SQL_STATE_SIZE]; diagnos.error_msg[0] = 0; @@ -2463,7 +2464,7 @@ /* Foreach diagnostic record in the current set of diagnostic records the error message is obtained */ for(record_nr = 1; ;record_nr++) { - if(SQLGetDiagRec(handleType, handle, record_nr, diagnos.sqlState, + if(SQLGetDiagRec(handleType, handle, record_nr, current_sql_state, &nativeError, current_errmsg_pos, (SQLSMALLINT)errmsg_buffer_size, &errmsg_size) != SQL_SUCCESS) { @@ -2471,6 +2472,9 @@ break; } else { + /* update the sqlstate in the diagnos record, because the SQLGetDiagRec + call succeeded */ + memcpy(diagnos.sqlState, current_sql_state, SQL_STATE_SIZE); errmsg_buffer_size = errmsg_buffer_size - errmsg_size; acc_errmsg_size = acc_errmsg_size + errmsg_size; current_errmsg_pos = current_errmsg_pos + errmsg_size; From juhani@REDACTED Sat Oct 10 09:30:48 2009 From: juhani@REDACTED (=?ISO-8859-1?Q?Juhani_R=E4nkimies?=) Date: Sat, 10 Oct 2009 10:30:48 +0300 Subject: [erlang-patches] PATCH: ODBC application discarding sqlstate in get_diagnos function In-Reply-To: <20091009174743.GJ11500@hijacked.us> References: <20091009174743.GJ11500@hijacked.us> Message-ID: I've had similar problems on windows with mssql2008. The behaviour wasn't identical, but with luck your patch fixes it in my setup too. I'll definitely have a look. It'll take a while though, as setting up a build env in windows is laborious and I've got my hands full already. Thanks, -juhani On Fri, Oct 9, 2009 at 8:47 PM, Andrew Thompson wrote: > Hi, > > I've been using the ODBC application against a unixodbc/mysql setup for > a while now and its been bothering me that ANY SQL error always returns > {port_exit,could_not_access_column_count} from the erlang side. I > decided to dig into the code and figure out why and this is what I > discovered: > > In the get_diagnos function of odbcserver.c every time SQLGetDiagRec is > called diagnos.sqlState is passed in as the target to write the returned > SQLSTATE into. However, when you've run out of diagnostic information > and SQLGetDiagRec() returns something other than SQL_SUCCESS, the value > of diagnos.sqlState *still* gets changed (at least in my case) to 00000, > which is, of course, the INFO SQLSTATE. This causes the check in > db_query against INFO to succeed when it should be failing and since in > my case the error message didn't begin with 'error' it falls through > encode_result which is where the EXIT_COLS comes in. Attached is a patch > to resolve this problem by only updating diagnos.sqlState when > SQLGetDiagRec returns success. > > I don't know if all ODBC implementations behave this way, but I'd assume > that the SQLSTATE from a failed SQLGetDiagRec can safely be ignored in > all cases. > > Thanks, > > Andrew > > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org From andrew@REDACTED Sat Oct 10 18:45:45 2009 From: andrew@REDACTED (Andrew Thompson) Date: Sat, 10 Oct 2009 12:45:45 -0400 Subject: [erlang-patches] PATCH: ODBC application discarding sqlstate in get_diagnos function In-Reply-To: References: <20091009174743.GJ11500@hijacked.us> Message-ID: <20091010164544.GA15291@hijacked.us> On Sat, Oct 10, 2009 at 10:30:48AM +0300, Juhani R?nkimies wrote: > I've had similar problems on windows with mssql2008. The behaviour > wasn't identical, but with luck your patch fixes it in my setup too. > > I'll definitely have a look. It'll take a while though, as setting up > a build env in windows is laborious and I've got my hands full > already. > If it doesn't, I can try to resurrect my windows build setup and do some investigating. What behaviour are you seeing? Andrew From juhani@REDACTED Sun Oct 11 09:40:10 2009 From: juhani@REDACTED (=?ISO-8859-1?Q?Juhani_R=E4nkimies?=) Date: Sun, 11 Oct 2009 10:40:10 +0300 Subject: [erlang-patches] PATCH: ODBC application discarding sqlstate in get_diagnos function In-Reply-To: <20091010164544.GA15291@hijacked.us> References: <20091009174743.GJ11500@hijacked.us> <20091010164544.GA15291@hijacked.us> Message-ID: On Sat, Oct 10, 2009 at 7:45 PM, Andrew Thompson wrote: >> > If it doesn't, I can try to resurrect my windows build setup and do some > investigating. What behaviour are you seeing? > Sometimes when an update/insert/delete is successfully executed in the db, I get {error,"No SQL-driver information available."}. My assumption (with no factual support) is that odbc app gets confused if the db sends additional information (SQLSTATE?) about the execution of the statement, like nulls ignored by aggregate functions or info about type conversions that were made. -juhani From andrew@REDACTED Sun Oct 11 20:17:16 2009 From: andrew@REDACTED (Andrew Thompson) Date: Sun, 11 Oct 2009 14:17:16 -0400 Subject: [erlang-patches] PATCH: ODBC application discarding sqlstate in get_diagnos function In-Reply-To: References: <20091009174743.GJ11500@hijacked.us> <20091010164544.GA15291@hijacked.us> Message-ID: <20091011181716.GA8073@hijacked.us> On Sun, Oct 11, 2009 at 10:40:10AM +0300, Juhani R?nkimies wrote: > On Sat, Oct 10, 2009 at 7:45 PM, Andrew Thompson wrote: > > Sometimes when an update/insert/delete is successfully executed in the > db, I get {error,"No SQL-driver information available."}. > > My assumption (with no factual support) is that odbc app gets confused > if the db sends additional information (SQLSTATE?) about the execution > of the statement, like nulls ignored by aggregate functions or info > about type conversions that were made. > Ah, that does sound like a similar issue although I'm not sure my patch will solve it. Does it happen consistantly or is it random? Are you using parameterized queries? Andrew From vinoski@REDACTED Mon Oct 12 00:46:27 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 11 Oct 2009 18:46:27 -0400 Subject: erlang.el patch for try/after Message-ID: <65b2728e0910111546w5dc5fef1obef0088729389817@mail.gmail.com> I've found that erlang.el doesn't properly indent try/after without an intervening catch -- the after keyword ends up being indented to the same level as the code within the try clause rather than being indented to the same level as the try keyword. Also, the second and subsequent lines within the after clause are indented only half the correct distance. Another issue is that a lot of the regular expressions used within erlang.el try to match word boundaries using [^_a-zA-Z0-9] rather than just using the \b word boundary backslash construct. The patch below is for erlang.el from Erlang/OTP version R13B02-1 and it fixes these issues. The same patch also works for versions at least as far back as R12B-5, but with different line offsets. --steve --- erlang.el.orig 2009-10-11 17:31:48.000000000 -0400 +++ erlang.el 2009-10-11 18:18:18.000000000 -0400 @@ -3353,7 +3353,7 @@ ;; Word constituent: check and handle keywords. ((= cs ?w) - (cond ((looking-at "\\(end\\|after\\)[^_a-zA-Z0-9]") + (cond ((looking-at "\\b\\(end\\|after\\)\\b") ;; Must pop top icr layer, `after' will push a new ;; layer next. (progn @@ -3361,7 +3361,7 @@ (erlang-pop stack)) (if (and stack (memq (car (car stack)) '(icr begin))) (erlang-pop stack)))) - ((looking-at "catch[^,\n\\of]*\n") + ((looking-at "\\bcatch[^,\n\\of]*\n") ;; Must pop top icr layer, `catch' in try/catch ;;will push a new layer next. (progn @@ -3378,10 +3378,10 @@ ;; (if (and stack (memq (car (car stack)) '(icr begin))) ;; (erlang-pop stack)))) ) - (cond ((looking-at "\\(if\\|case\\|receive\\|try\\)[^_a-zA-Z0-9]") + (cond ((looking-at "\\b\\(if\\|case\\|receive\\|try\\)\\b") ;; Must push a new icr (if/case/receive) layer. (erlang-push (list 'icr token (current-column)) stack)) - ((looking-at "\\(fun\\)[^_a-zA-Z0-9]") + ((looking-at "\\b\\(fun\\)\\b") ;; Push a new icr layer if we are defining a `fun' ;; expression, not when we are refering an existing ;; function. @@ -3390,7 +3390,7 @@ (erlang-skip-blank to) (eq (following-char) ?\()) (erlang-push (list 'icr token (current-column)) stack))) - ((looking-at "\\(begin\\|query\\)[^_a-zA-Z0-9]") + ((looking-at "\\b\\(begin\\|query\\)\\b") (erlang-push (list 'begin token (current-column)) stack)) ;; In test suites you may want to do something like ;; ?match(Mem when integer(Mem), mnesia:table_info(Tab, @@ -3399,22 +3399,22 @@ ;; erlang mode to think the 'when' in the argument is a ;; "real" when. The following three clauses will avoid ;; this problem. - ((looking-at "when[^->\.]*if[^->\.]*->")) - ((looking-at "when[^->\.]*case[^->\.]*->")) - ((looking-at "when[^->\.]*receive[^->\.]*->")) + ((looking-at "\\bwhen[^->\.]*if[^->\.]*->")) + ((looking-at "\\bwhen[^->\.]*case[^->\.]*->")) + ((looking-at "\\bwhen[^->\.]*receive[^->\.]*->")) ;; Normal when case - ((looking-at "when [^->\.]*->") + ((looking-at "\\bwhen [^->\.]*->") (erlang-push (list 'when token (current-column)) stack)) - ((looking-at "after[.]+->") + ((looking-at "\\bafter[.]+->") (erlang-push (list 'icr token (current-column)) stack)) - ((looking-at "after[^_a-zA-Z0-9->]") - ;; Probably in try-statment, fake "->" to get right + ((looking-at "\\bafter\\b") + ;; Probably in try-statement, fake "->" to get right ;; indentation in erlang-calculate-stack-indent. If it ;; was an ordinary catch without try, these entries will ;; be popped of the stack at a later ocaccion. (erlang-push (list 'icr token (current-column)) stack) (erlang-push (list '-> token (current-column)) stack)) - ((looking-at "catch[^,\n\\of]*\n") + ((looking-at "\\bcatch[^,\n\\of]*\n") (erlang-push (list 'icr token (current-column)) stack) (erlang-push (list '-> token (current-column)) stack)) ;;((looking-at "^of$") @@ -3469,7 +3469,7 @@ ((looking-at "->\\|:-") (save-excursion (back-to-indentation) - (cond ((looking-at "after[^_a-zA-Z0-9]") + (cond ((looking-at "\\bafter\\b") (erlang-pop stack)))) (if (and stack (eq (car (car stack)) 'when)) (erlang-pop stack)) @@ -3580,7 +3580,7 @@ ;; Return nil or t. (eq (nth 3 state) 'comment)) ((null stack) - (if (looking-at "when[^_a-zA-Z0-9]") + (if (looking-at "\\bwhen\\b") erlang-indent-guard 0)) ((eq (car stack-top) '\() @@ -3608,28 +3608,34 @@ ;; ;; `after' should be indented to the save level as the ;; corresponding receive. - (if (looking-at "after[^_a-zA-Z0-9]") - (nth 2 stack-top) - (save-excursion - (goto-char (nth 1 stack-top)) - (if (looking-at "case[^_a-zA-Z0-9]") - (+ (nth 2 stack-top) erlang-indent-level) - (skip-chars-forward "a-z") - (skip-chars-forward " \t") - (if (memq (following-char) '(?% ?\n)) - (+ (nth 2 stack-top) erlang-indent-level) - (current-column))))) - (if (looking-at "catch[^_a-zA-Z0-9]") - (nth 2 stack-top) - (save-excursion - (goto-char (nth 1 stack-top)) - (if (looking-at "case[^_a-zA-Z0-9]") - (+ (nth 2 stack-top) erlang-indent-level) - (skip-chars-forward "a-z") - (skip-chars-forward " \t") - (if (memq (following-char) '(?% ?\n)) - (+ (nth 2 stack-top) erlang-indent-level) - (current-column))))) + (let ((top-word (save-excursion + (goto-char (nth 1 stack-top)) + (looking-at "\\b\\(\\w+\\)\\b") + (match-string 0)))) + (if (and (looking-at "\\bafter\\b") + (not (string= top-word "try"))) + (if (string= top-word "case") + (+ (nth 2 stack-top) erlang-indent-level) + (save-excursion + (goto-char (nth 1 stack-top)) + (skip-chars-forward "a-z") + (skip-chars-forward " \t") + (if (memq (following-char) '(?% ?\n)) + (+ (nth 2 stack-top) erlang-indent-level) + (current-column))))) + (if (or (looking-at "\\bcatch\\b") + (and (looking-at "\\bafter\\b") + (string= top-word "try"))) + (nth 2 stack-top) + (if (string= top-word "case") + (+ (nth 2 stack-top) erlang-indent-level) + (save-excursion + (goto-char (nth 1 stack-top)) + (skip-chars-forward "a-z") + (skip-chars-forward " \t") + (if (memq (following-char) '(?% ?\n)) + (+ (nth 2 stack-top) erlang-indent-level) + (current-column)))))) ) ;; Real indentation, where operators create extra indentation etc. ((memq (car stack-top) '(-> || begin)) @@ -3638,7 +3644,8 @@ ;; same line. If so use this indentation as base, else ;; use parent indentation + 2 * level as base. (let ((off erlang-indent-level) - (skip 2)) + (skip 2) + (is-after (looking-at "\\bafter\\b"))) (cond ((null (cdr stack))) ; Top level in function. ((eq (car stack-top) 'begin) (setq skip 5)) @@ -3648,7 +3655,9 @@ ;; Look at last thing to see how we are to move relative ;; to the base. (goto-char token) - (cond ((looking-at "||\\|,\\|->\\|:-") + (cond ((and is-after (looking-at ",")) + off) + ((looking-at "||\\|,\\|->\\|:-") base) ((erlang-at-keyword) (+ (current-column) erlang-indent-level)) @@ -3665,7 +3674,7 @@ ;; the block. (Here we have a choice: should ;; the user be forced to reindent continued ;; lines, or should the "end" be reindented?) - ((looking-at "\\(end\\|after\\|catch\\)[^_a-zA-Z0-9]\\|$") + ((looking-at "\\b\\(end\\|after\\|catch\\)\\b\\|$") (if (eq (car (car stack)) '->) (erlang-pop stack)) (if stack @@ -3680,7 +3689,7 @@ ) ((eq (car stack-top) 'when) (goto-char (nth 1 stack-top)) - (if (looking-at "when\\s *\\($\\|%\\)") + (if (looking-at "\\bwhen\\s *\\($\\|%\\)") (progn (erlang-pop stack) (if (and stack (eq (nth 0 (car stack)) 'icr)) @@ -3757,13 +3766,13 @@ (defun erlang-at-keyword () "Are we looking at an Erlang keyword which will increase indentation?" - (looking-at (concat "\\(when\\|if\\|fun\\|case\\|begin\\|query\\|" - "of\\|receive\\|after\\|catch\\)[^_a-zA-Z0-9]"))) + (looking-at (concat "\\b\\(when\\|if\\|fun\\|case\\|begin\\|query\\|" + "of\\|receive\\|after\\|catch\\)\\b"))) (defun erlang-at-operator () "Are we looking at an Erlang operator?" (looking-at - "\\(bnot\\|div\\|mod\\|band\\|bor\\|bxor\\|bsl\\|bsr\\)[^_a-zA-Z0-9]")) + "\\b\\(bnot\\|div\\|mod\\|band\\|bor\\|bxor\\|bsl\\|bsr\\)\\b")) (defun erlang-comment-indent () "Compute Erlang comment indentation. @@ -4813,7 +4822,7 @@ This function is designed to be a member of a criteria list." (save-excursion (erlang-skip-blank) - (looking-at "end[^_a-zA-Z0-9]"))) + (looking-at "\\bend\\b"))) ;; Erlang tags support which is aware of erlang modules. From dgud@REDACTED Mon Oct 12 08:56:49 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 12 Oct 2009 08:56:49 +0200 Subject: [erlang-patches] erlang.el patch for try/after In-Reply-To: <65b2728e0910111546w5dc5fef1obef0088729389817@mail.gmail.com> References: <65b2728e0910111546w5dc5fef1obef0088729389817@mail.gmail.com> Message-ID: <4AD2D331.8010103@erix.ericsson.se> Thanks, but I have just re-wrote how the try-after is handled (and a lot of other fixes) in the mode. I will apply your word boundary match. /Dan Steve Vinoski wrote: > I've found that erlang.el doesn't properly indent try/after without an > intervening catch -- the after keyword ends up being indented to the same > level as the code within the try clause rather than being indented to the > same level as the try keyword. Also, the second and subsequent lines within > the after clause are indented only half the correct distance. > Another issue is that a lot of the regular expressions used within erlang.el > try to match word boundaries using [^_a-zA-Z0-9] rather than just using the > \b word boundary backslash construct. > > The patch below is for erlang.el from Erlang/OTP version R13B02-1 and it > fixes these issues. The same patch also works for versions at least as far > back as R12B-5, but with different line offsets. > > --steve > > --- erlang.el.orig 2009-10-11 17:31:48.000000000 -0400 > +++ erlang.el 2009-10-11 18:18:18.000000000 -0400 > @@ -3353,7 +3353,7 @@ > > ;; Word constituent: check and handle keywords. > ((= cs ?w) > - (cond ((looking-at "\\(end\\|after\\)[^_a-zA-Z0-9]") > + (cond ((looking-at "\\b\\(end\\|after\\)\\b") > ;; Must pop top icr layer, `after' will push a new > ;; layer next. > (progn > @@ -3361,7 +3361,7 @@ > (erlang-pop stack)) > (if (and stack (memq (car (car stack)) '(icr begin))) > (erlang-pop stack)))) > - ((looking-at "catch[^,\n\\of]*\n") > + ((looking-at "\\bcatch[^,\n\\of]*\n") > ;; Must pop top icr layer, `catch' in try/catch > ;;will push a new layer next. > (progn > @@ -3378,10 +3378,10 @@ > ;; (if (and stack (memq (car (car stack)) '(icr begin))) > ;; (erlang-pop stack)))) > ) > - (cond ((looking-at "\\(if\\|case\\|receive\\|try\\)[^_a-zA-Z0-9]") > + (cond ((looking-at "\\b\\(if\\|case\\|receive\\|try\\)\\b") > ;; Must push a new icr (if/case/receive) layer. > (erlang-push (list 'icr token (current-column)) stack)) > - ((looking-at "\\(fun\\)[^_a-zA-Z0-9]") > + ((looking-at "\\b\\(fun\\)\\b") > ;; Push a new icr layer if we are defining a `fun' > ;; expression, not when we are refering an existing > ;; function. > @@ -3390,7 +3390,7 @@ > (erlang-skip-blank to) > (eq (following-char) ?\()) > (erlang-push (list 'icr token (current-column)) stack))) > - ((looking-at "\\(begin\\|query\\)[^_a-zA-Z0-9]") > + ((looking-at "\\b\\(begin\\|query\\)\\b") > (erlang-push (list 'begin token (current-column)) stack)) > ;; In test suites you may want to do something like > ;; ?match(Mem when integer(Mem), mnesia:table_info(Tab, > @@ -3399,22 +3399,22 @@ > ;; erlang mode to think the 'when' in the argument is a > ;; "real" when. The following three clauses will avoid > ;; this problem. > - ((looking-at "when[^->\.]*if[^->\.]*->")) > - ((looking-at "when[^->\.]*case[^->\.]*->")) > - ((looking-at "when[^->\.]*receive[^->\.]*->")) > + ((looking-at "\\bwhen[^->\.]*if[^->\.]*->")) > + ((looking-at "\\bwhen[^->\.]*case[^->\.]*->")) > + ((looking-at "\\bwhen[^->\.]*receive[^->\.]*->")) > ;; Normal when case > - ((looking-at "when [^->\.]*->") > + ((looking-at "\\bwhen [^->\.]*->") > (erlang-push (list 'when token (current-column)) stack)) > - ((looking-at "after[.]+->") > + ((looking-at "\\bafter[.]+->") > (erlang-push (list 'icr token (current-column)) stack)) > - ((looking-at "after[^_a-zA-Z0-9->]") > - ;; Probably in try-statment, fake "->" to get right > + ((looking-at "\\bafter\\b") > + ;; Probably in try-statement, fake "->" to get right > ;; indentation in erlang-calculate-stack-indent. If it > ;; was an ordinary catch without try, these entries will > ;; be popped of the stack at a later ocaccion. > (erlang-push (list 'icr token (current-column)) stack) > (erlang-push (list '-> token (current-column)) stack)) > - ((looking-at "catch[^,\n\\of]*\n") > + ((looking-at "\\bcatch[^,\n\\of]*\n") > (erlang-push (list 'icr token (current-column)) stack) > (erlang-push (list '-> token (current-column)) stack)) > ;;((looking-at "^of$") > @@ -3469,7 +3469,7 @@ > ((looking-at "->\\|:-") > (save-excursion > (back-to-indentation) > - (cond ((looking-at "after[^_a-zA-Z0-9]") > + (cond ((looking-at "\\bafter\\b") > (erlang-pop stack)))) > (if (and stack (eq (car (car stack)) 'when)) > (erlang-pop stack)) > @@ -3580,7 +3580,7 @@ > ;; Return nil or t. > (eq (nth 3 state) 'comment)) > ((null stack) > - (if (looking-at "when[^_a-zA-Z0-9]") > + (if (looking-at "\\bwhen\\b") > erlang-indent-guard > 0)) > ((eq (car stack-top) '\() > @@ -3608,28 +3608,34 @@ > ;; > ;; `after' should be indented to the save level as the > ;; corresponding receive. > - (if (looking-at "after[^_a-zA-Z0-9]") > - (nth 2 stack-top) > - (save-excursion > - (goto-char (nth 1 stack-top)) > - (if (looking-at "case[^_a-zA-Z0-9]") > - (+ (nth 2 stack-top) erlang-indent-level) > - (skip-chars-forward "a-z") > - (skip-chars-forward " \t") > - (if (memq (following-char) '(?% ?\n)) > - (+ (nth 2 stack-top) erlang-indent-level) > - (current-column))))) > - (if (looking-at "catch[^_a-zA-Z0-9]") > - (nth 2 stack-top) > - (save-excursion > - (goto-char (nth 1 stack-top)) > - (if (looking-at "case[^_a-zA-Z0-9]") > - (+ (nth 2 stack-top) erlang-indent-level) > - (skip-chars-forward "a-z") > - (skip-chars-forward " \t") > - (if (memq (following-char) '(?% ?\n)) > - (+ (nth 2 stack-top) erlang-indent-level) > - (current-column))))) > + (let ((top-word (save-excursion > + (goto-char (nth 1 stack-top)) > + (looking-at "\\b\\(\\w+\\)\\b") > + (match-string 0)))) > + (if (and (looking-at "\\bafter\\b") > + (not (string= top-word "try"))) > + (if (string= top-word "case") > + (+ (nth 2 stack-top) erlang-indent-level) > + (save-excursion > + (goto-char (nth 1 stack-top)) > + (skip-chars-forward "a-z") > + (skip-chars-forward " \t") > + (if (memq (following-char) '(?% ?\n)) > + (+ (nth 2 stack-top) erlang-indent-level) > + (current-column))))) > + (if (or (looking-at "\\bcatch\\b") > + (and (looking-at "\\bafter\\b") > + (string= top-word "try"))) > + (nth 2 stack-top) > + (if (string= top-word "case") > + (+ (nth 2 stack-top) erlang-indent-level) > + (save-excursion > + (goto-char (nth 1 stack-top)) > + (skip-chars-forward "a-z") > + (skip-chars-forward " \t") > + (if (memq (following-char) '(?% ?\n)) > + (+ (nth 2 stack-top) erlang-indent-level) > + (current-column)))))) > ) > ;; Real indentation, where operators create extra indentation etc. > ((memq (car stack-top) '(-> || begin)) > @@ -3638,7 +3644,8 @@ > ;; same line. If so use this indentation as base, else > ;; use parent indentation + 2 * level as base. > (let ((off erlang-indent-level) > - (skip 2)) > + (skip 2) > + (is-after (looking-at "\\bafter\\b"))) > (cond ((null (cdr stack))) ; Top level in function. > ((eq (car stack-top) 'begin) > (setq skip 5)) > @@ -3648,7 +3655,9 @@ > ;; Look at last thing to see how we are to move relative > ;; to the base. > (goto-char token) > - (cond ((looking-at "||\\|,\\|->\\|:-") > + (cond ((and is-after (looking-at ",")) > + off) > + ((looking-at "||\\|,\\|->\\|:-") > base) > ((erlang-at-keyword) > (+ (current-column) erlang-indent-level)) > @@ -3665,7 +3674,7 @@ > ;; the block. (Here we have a choice: should > ;; the user be forced to reindent continued > ;; lines, or should the "end" be reindented?) > - ((looking-at "\\(end\\|after\\|catch\\)[^_a-zA-Z0-9]\\|$") > + ((looking-at "\\b\\(end\\|after\\|catch\\)\\b\\|$") > (if (eq (car (car stack)) '->) > (erlang-pop stack)) > (if stack > @@ -3680,7 +3689,7 @@ > ) > ((eq (car stack-top) 'when) > (goto-char (nth 1 stack-top)) > - (if (looking-at "when\\s *\\($\\|%\\)") > + (if (looking-at "\\bwhen\\s *\\($\\|%\\)") > (progn > (erlang-pop stack) > (if (and stack (eq (nth 0 (car stack)) 'icr)) > @@ -3757,13 +3766,13 @@ > > (defun erlang-at-keyword () > "Are we looking at an Erlang keyword which will increase indentation?" > - (looking-at (concat "\\(when\\|if\\|fun\\|case\\|begin\\|query\\|" > - "of\\|receive\\|after\\|catch\\)[^_a-zA-Z0-9]"))) > + (looking-at (concat "\\b\\(when\\|if\\|fun\\|case\\|begin\\|query\\|" > + "of\\|receive\\|after\\|catch\\)\\b"))) > > (defun erlang-at-operator () > "Are we looking at an Erlang operator?" > (looking-at > - "\\(bnot\\|div\\|mod\\|band\\|bor\\|bxor\\|bsl\\|bsr\\)[^_a-zA-Z0-9]")) > + "\\b\\(bnot\\|div\\|mod\\|band\\|bor\\|bxor\\|bsl\\|bsr\\)\\b")) > > (defun erlang-comment-indent () > "Compute Erlang comment indentation. > @@ -4813,7 +4822,7 @@ > This function is designed to be a member of a criteria list." > (save-excursion > (erlang-skip-blank) > - (looking-at "end[^_a-zA-Z0-9]"))) > + (looking-at "\\bend\\b"))) > > > ;; Erlang tags support which is aware of erlang modules. > From juhani@REDACTED Mon Oct 12 22:33:16 2009 From: juhani@REDACTED (=?ISO-8859-1?Q?Juhani_R=E4nkimies?=) Date: Mon, 12 Oct 2009 23:33:16 +0300 Subject: [erlang-patches] PATCH: ODBC application discarding sqlstate in get_diagnos function In-Reply-To: <20091011181716.GA8073@hijacked.us> References: <20091009174743.GJ11500@hijacked.us> <20091010164544.GA15291@hijacked.us> <20091011181716.GA8073@hijacked.us> Message-ID: On 10/11/09, Andrew Thompson wrote: > > Ah, that does sound like a similar issue although I'm not sure my patch > will solve it. Does it happen consistantly or is it random? Are you > using parameterized queries? I haven't worked with that part of the system in 5-6 months and i'm no longer sure if it was consistent or not. I'm on a trip and can't check it now. I'll try to find time to reproduce it on weekend. Juhani From puzza007@REDACTED Wed Oct 14 10:05:46 2009 From: puzza007@REDACTED (Paul Oliver) Date: Wed, 14 Oct 2009 09:05:46 +0100 Subject: [erlang-questions] blowfish ECB implementation in erlang? In-Reply-To: References: <38ff4e6b0909231233i4435a436v170a8b1953b22c4e@mail.gmail.com> Message-ID: On Sun, Sep 27, 2009 at 11:35 PM, Paul Oliver wrote: > > > On Fri, Sep 25, 2009 at 1:19 PM, Paul Oliver wrote: > >> On Wed, Sep 23, 2009 at 8:33 PM, Larry Ogrodnek wrote: >> >>> Hi, I'm wondering if anyone has put together an implementation of >>> blowfish ECB? >>> >>> thanks. >>> >> >> Hi Larry, >> >> Check the following page for the patch that added cfb64. >> >> >> http://www.nabble.com/Patch-to-add-Blowfish-cfb64-to-crypto-app-td24232164.html >> >> You should almost be able to copy this verbatim to add ecb. >> >> Cheers, >> Paul. >> > > Hi Larry, > > The attached patch should do ECB for you. It works for me on the test data > I obtained from http://www.schneier.com/code/vectors.txt. > > puzza@REDACTED:~/Downloads/otp_src_R13B02-1$ /tmp/bin/erl > Erlang R13B02 (erts-5.7.3) [source] [smp:2:2] [rq:2] [async-threads:0] > [kernel-poll:false] > > Eshell V5.7.3 (abort with ^G) > 1> %% FEDCBA9876543210 == Key = <<254,220,186,152,118,84,50,16>> > 1> %% 0123456789ABCDEF == Clear = <<1,35,69,103,137,171,205,239>> > 1> %% 0ACEAB0FC6A0A28D == Enc = <<10,206,171,15,198,160,162,141>> > 1> > 1> crypto:start(). > ok > 2> Key = <<254,220,186,152,118,84,50,16>>. > <<254,220,186,152,118,84,50,16>> > 3> Clear = <<1,35,69,103,137,171,205,239>>. > <<1,35,69,103,137,171,205,239>> > 4> Enc = <<10,206,171,15,198,160,162,141>>. > <<10,206,171,15,198,160,162,141>> > 5> Enc == crypto:blowfish_ecb_encrypt(Key, Clear). > true > 6> Clear == crypto:blowfish_ecb_decrypt(Key, Enc). > true > 7> > > I'm off on holiday tomorrow so if it doesn't work as it should I'll take > another look in a couple of weeks. ;} If it works OK please reply and > perhaps it can be picked up in a future OTP release. > > Cheers, > Paul. > Hi, I've rounded out the patch to include the rest of the blowfish functions from openssl and included a primitive test program. Cheers, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: blowfish_ecb_cbc_ofb.patch Type: text/x-diff Size: 9353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bf_test.erl Type: text/x-erlang Size: 4920 bytes Desc: not available URL: From mazen.harake@REDACTED Wed Oct 14 15:22:42 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 14 Oct 2009 15:22:42 +0200 Subject: wxe_server bug? (and patch) Message-ID: <4AD5D0A2.2030602@erlang-consulting.com> Hi, There is a situation in the wx library that causes the wxe_server to crash when it receives a message with a pid which is considered by distributed Erlang to come from another node when in fact it isn't. This happens when net_kernel is started explicitly (I.e. Erlang going into distribution mode) and an wx_object (which was created before net_kernel was started) is destroyed. Here is a simple example: Create this module: -module(test). -compile(export_all). start() -> wx:new(), wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []). close(_, _) -> wx_object:call(?MODULE, stop). init(Wx) -> wx:set_env(Wx), Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]), wxFrame:show(Mf), wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]), {Mf, Mf}. handle_call(stop, _From, Mf) -> wxFrame:destroy(Mf), {stop, normal, ok, Mf}. terminate(normal, _) -> ok. Then run this in the shell: Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0] Eshell V5.7.1 (abort with ^G) 1> c(test). {ok,test} 2> test:start(). {wx_ref,35,wxFrame,<0.42.0>} 3> This should give you a small frame, don't close it yet, Now do this: 3> net_kernel:start([bad,shortnames]). {ok,<0.49.0>} (bad@REDACTED)4> Now close the frame and you should see: =ERROR REPORT==== 14-Oct-2009::13:17:08 === ** Generic server <0.39.0> terminating ** Last message in was {'_wxe_destroy_',<3.42.0>} ** When Server state == {state,#Port<0.2605>,#Port<0.2602>, {1,{<0.32.0>,{user,[],[],undefined},nil,nil}}, [<0.57.0>], {1,{#Fun,1,nil,nil}}, 2} ** Reason for termination == ** {badarg,[{erlang,is_process_alive,[<3.42.0>]}, {wxe_server,handle_info,2}, {gen_server,handle_msg,5}, {proc_lib,init_p_do_apply,3}]} The pid which comes from the port is not recognized as a local pid and thus erlang:is_process_alive/1 will exit with badarg. My question is: Is this a "feature" or a bug? I think this is a bug but I'm not sure what is expected from the wx library point of view. IMHO it shouldn't crash and just ignore it in this case because the wxe_server shouldn't be allowed to crash. Anyway I put in a patch as well just in case this is something that should be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3. Cheers, /Mazen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wxe_server.patch URL: From mazen.harake@REDACTED Wed Oct 14 15:25:21 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 14 Oct 2009 15:25:21 +0200 Subject: [erlang-patches] wxe_server bug? (and patch) In-Reply-To: <4AD5D0A2.2030602@erlang-consulting.com> References: <4AD5D0A2.2030602@erlang-consulting.com> Message-ID: <4AD5D141.30207@erlang-consulting.com> A quick note: I just realized that this example doesn't work unless you have applied my previous patch for wx_object.erl. Either apply that or change the code to call the wx_object with the form (somehow) :) /Mazen Mazen Harake wrote: > Hi, > > There is a situation in the wx library that causes the wxe_server to > crash when it receives a message with a pid which is considered by > distributed Erlang to come from another node when in fact it isn't. > This happens when net_kernel is started explicitly (I.e. Erlang going > into distribution mode) and an wx_object (which was created before > net_kernel was started) is destroyed. > > Here is a simple example: > Create this module: > -module(test). > -compile(export_all). > > start() -> > wx:new(), > wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []). > > close(_, _) -> > wx_object:call(?MODULE, stop). > > init(Wx) -> > wx:set_env(Wx), > Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]), > wxFrame:show(Mf), > wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]), > {Mf, Mf}. > > handle_call(stop, _From, Mf) -> > wxFrame:destroy(Mf), > {stop, normal, ok, Mf}. > > terminate(normal, _) -> > ok. > > Then run this in the shell: > Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0] > > Eshell V5.7.1 (abort with ^G) > 1> c(test). > {ok,test} > 2> test:start(). > {wx_ref,35,wxFrame,<0.42.0>} > 3> > > This should give you a small frame, don't close it yet, > Now do this: > 3> net_kernel:start([bad,shortnames]). > {ok,<0.49.0>} > (bad@REDACTED)4> > > Now close the frame and you should see: > =ERROR REPORT==== 14-Oct-2009::13:17:08 === > ** Generic server <0.39.0> terminating > ** Last message in was {'_wxe_destroy_',<3.42.0>} > ** When Server state == {state,#Port<0.2605>,#Port<0.2602>, > > {1,{<0.32.0>,{user,[],[],undefined},nil,nil}}, > [<0.57.0>], > {1,{#Fun,1,nil,nil}}, > 2} > ** Reason for termination == > ** {badarg,[{erlang,is_process_alive,[<3.42.0>]}, > {wxe_server,handle_info,2}, > {gen_server,handle_msg,5}, > {proc_lib,init_p_do_apply,3}]} > > > The pid which comes from the port is not recognized as a local pid and > thus erlang:is_process_alive/1 will exit with badarg. My question is: > Is this a "feature" or a bug? I think this is a bug but I'm not sure > what is expected from the wx library point of view. IMHO it shouldn't > crash and just ignore it in this case because the wxe_server shouldn't > be allowed to crash. > > Anyway I put in a patch as well just in case this is something that > should be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3. > > Cheers, > > /Mazen > > > > > ------------------------------------------------------------------------ > > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org From dgud@REDACTED Wed Oct 14 15:52:16 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 14 Oct 2009 15:52:16 +0200 Subject: [erlang-patches] wxe_server bug? (and patch) In-Reply-To: <4AD5D141.30207@erlang-consulting.com> References: <4AD5D0A2.2030602@erlang-consulting.com> <4AD5D141.30207@erlang-consulting.com> Message-ID: <93df43b60910140652u77630d3dw58176892af6c02d5@mail.gmail.com> I'll fix the problem, in the right way(tm). /Dan PS: I just applied your wx_object patch but I allowed pids as well as registered names and added wx_object:cast/2. On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake wrote: > A quick note: > I just realized that this example doesn't work unless you have applied my > previous patch for wx_object.erl. Either apply that or change the code to > call the wx_object with the form (somehow) :) > > /Mazen > > Mazen Harake wrote: >> >> Hi, >> >> There is a situation in the wx library that causes the wxe_server to crash >> when it receives a message with a pid which is considered by distributed >> Erlang to come from another node when in fact it isn't. This happens when >> net_kernel is started explicitly (I.e. Erlang going into distribution mode) >> and an wx_object (which was created before net_kernel was started) is >> destroyed. >> >> Here is a simple example: >> Create this module: >> -module(test). >> -compile(export_all). >> >> start() -> >> ?wx:new(), >> ?wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []). >> >> close(_, _) -> >> ?wx_object:call(?MODULE, stop). >> >> init(Wx) -> >> ?wx:set_env(Wx), >> ?Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]), >> ?wxFrame:show(Mf), >> ?wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]), >> ?{Mf, Mf}. >> >> handle_call(stop, _From, Mf) -> >> ?wxFrame:destroy(Mf), >> ?{stop, normal, ok, Mf}. >> >> terminate(normal, _) -> >> ?ok. >> >> Then run this in the shell: >> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0] >> >> Eshell V5.7.1 ?(abort with ^G) >> 1> c(test). >> {ok,test} >> 2> test:start(). >> {wx_ref,35,wxFrame,<0.42.0>} >> 3> >> >> This should give you a small frame, don't close it yet, >> Now do this: >> 3> net_kernel:start([bad,shortnames]). >> {ok,<0.49.0>} >> (bad@REDACTED)4> >> >> Now close the frame and you should see: >> =ERROR REPORT==== 14-Oct-2009::13:17:08 === >> ** Generic server <0.39.0> terminating >> ** Last message in was {'_wxe_destroy_',<3.42.0>} >> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>, >> >> ?{1,{<0.32.0>,{user,[],[],undefined},nil,nil}}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[<0.57.0>], >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{1,{#Fun,1,nil,nil}}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?2} >> ** Reason for termination == >> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]}, >> ? ? ? ? ? {wxe_server,handle_info,2}, >> ? ? ? ? ? {gen_server,handle_msg,5}, >> ? ? ? ? ? {proc_lib,init_p_do_apply,3}]} >> >> >> The pid which comes from the port is not recognized as a local pid and >> thus erlang:is_process_alive/1 will exit with badarg. My question is: Is >> this a "feature" or a bug? I think this is a bug but I'm not sure what is >> expected from the wx library point of view. IMHO it shouldn't crash and just >> ignore it in this case because the wxe_server shouldn't be allowed to crash. >> >> Anyway I put in a patch as well just in case this is something that should >> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3. >> >> Cheers, >> >> /Mazen >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> ________________________________________________________________ >> erlang-patches mailing list. See http://www.erlang.org/faq.html >> erlang-patches (at) erlang.org > > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org > > From mazen.harake@REDACTED Wed Oct 14 16:13:15 2009 From: mazen.harake@REDACTED (Mazen Harake) Date: Wed, 14 Oct 2009 16:13:15 +0200 Subject: [erlang-patches] wxe_server bug? (and patch) In-Reply-To: <93df43b60910140652u77630d3dw58176892af6c02d5@mail.gmail.com> References: <4AD5D0A2.2030602@erlang-consulting.com> <4AD5D141.30207@erlang-consulting.com> <93df43b60910140652u77630d3dw58176892af6c02d5@mail.gmail.com> Message-ID: <4AD5DC7B.2000305@erlang-consulting.com> Yeah I can see how using pids are useful but the semantic difference is that you can't really get the pid from somewhere unless you register it? I mean the return value is a wxWindow() type. I dunno... just a thought :) Waiting patiently to learn the right way ;) /Mazen Dan Gudmundsson wrote: > I'll fix the problem, in the right way(tm). > > /Dan > PS: I just applied your wx_object patch but I allowed pids as well as > registered names and > added wx_object:cast/2. > > On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake > wrote: > >> A quick note: >> I just realized that this example doesn't work unless you have applied my >> previous patch for wx_object.erl. Either apply that or change the code to >> call the wx_object with the form (somehow) :) >> >> /Mazen >> >> Mazen Harake wrote: >> >>> Hi, >>> >>> There is a situation in the wx library that causes the wxe_server to crash >>> when it receives a message with a pid which is considered by distributed >>> Erlang to come from another node when in fact it isn't. This happens when >>> net_kernel is started explicitly (I.e. Erlang going into distribution mode) >>> and an wx_object (which was created before net_kernel was started) is >>> destroyed. >>> >>> Here is a simple example: >>> Create this module: >>> -module(test). >>> -compile(export_all). >>> >>> start() -> >>> wx:new(), >>> wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []). >>> >>> close(_, _) -> >>> wx_object:call(?MODULE, stop). >>> >>> init(Wx) -> >>> wx:set_env(Wx), >>> Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]), >>> wxFrame:show(Mf), >>> wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]), >>> {Mf, Mf}. >>> >>> handle_call(stop, _From, Mf) -> >>> wxFrame:destroy(Mf), >>> {stop, normal, ok, Mf}. >>> >>> terminate(normal, _) -> >>> ok. >>> >>> Then run this in the shell: >>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0] >>> >>> Eshell V5.7.1 (abort with ^G) >>> 1> c(test). >>> {ok,test} >>> 2> test:start(). >>> {wx_ref,35,wxFrame,<0.42.0>} >>> 3> >>> >>> This should give you a small frame, don't close it yet, >>> Now do this: >>> 3> net_kernel:start([bad,shortnames]). >>> {ok,<0.49.0>} >>> (bad@REDACTED)4> >>> >>> Now close the frame and you should see: >>> =ERROR REPORT==== 14-Oct-2009::13:17:08 === >>> ** Generic server <0.39.0> terminating >>> ** Last message in was {'_wxe_destroy_',<3.42.0>} >>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>, >>> >>> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}}, >>> [<0.57.0>], >>> {1,{#Fun,1,nil,nil}}, >>> 2} >>> ** Reason for termination == >>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]}, >>> {wxe_server,handle_info,2}, >>> {gen_server,handle_msg,5}, >>> {proc_lib,init_p_do_apply,3}]} >>> >>> >>> The pid which comes from the port is not recognized as a local pid and >>> thus erlang:is_process_alive/1 will exit with badarg. My question is: Is >>> this a "feature" or a bug? I think this is a bug but I'm not sure what is >>> expected from the wx library point of view. IMHO it shouldn't crash and just >>> ignore it in this case because the wxe_server shouldn't be allowed to crash. >>> >>> Anyway I put in a patch as well just in case this is something that should >>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3. >>> >>> Cheers, >>> >>> /Mazen >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ________________________________________________________________ >>> erlang-patches mailing list. See http://www.erlang.org/faq.html >>> erlang-patches (at) erlang.org >>> >> ________________________________________________________________ >> erlang-patches mailing list. See http://www.erlang.org/faq.html >> erlang-patches (at) erlang.org >> >> >> From dgud@REDACTED Wed Oct 14 16:23:00 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 14 Oct 2009 16:23:00 +0200 Subject: [erlang-patches] wxe_server bug? (and patch) In-Reply-To: <4AD5DC7B.2000305@erlang-consulting.com> References: <4AD5D0A2.2030602@erlang-consulting.com> <4AD5D141.30207@erlang-consulting.com> <93df43b60910140652u77630d3dw58176892af6c02d5@mail.gmail.com> <4AD5DC7B.2000305@erlang-consulting.com> Message-ID: <4AD5DEC4.3000701@erix.ericsson.se> Mazen Harake wrote: > Yeah I can see how using pids are useful but the semantic difference is > that you can't really get the pid from somewhere unless you register it? > I mean the return value is a wxWindow() type. I dunno... just a thought :) wx_object:get_pid(Ref). > > Waiting patiently to learn the right way ;) The right way is to not use term_to_binary(self()) when registrering the process with the driver, because that representation changes when the node becomes distributed. I.e. more code and changes in the driver, but better, nicer and uses less memory, that code wasn't the best I have written :-) /Dan > > /Mazen > > Dan Gudmundsson wrote: >> I'll fix the problem, in the right way(tm). >> >> /Dan >> PS: I just applied your wx_object patch but I allowed pids as well as >> registered names and >> added wx_object:cast/2. >> >> On Wed, Oct 14, 2009 at 3:25 PM, Mazen Harake >> wrote: >> >>> A quick note: >>> I just realized that this example doesn't work unless you have >>> applied my >>> previous patch for wx_object.erl. Either apply that or change the >>> code to >>> call the wx_object with the form (somehow) :) >>> >>> /Mazen >>> >>> Mazen Harake wrote: >>> >>>> Hi, >>>> >>>> There is a situation in the wx library that causes the wxe_server to >>>> crash >>>> when it receives a message with a pid which is considered by >>>> distributed >>>> Erlang to come from another node when in fact it isn't. This happens >>>> when >>>> net_kernel is started explicitly (I.e. Erlang going into >>>> distribution mode) >>>> and an wx_object (which was created before net_kernel was started) is >>>> destroyed. >>>> >>>> Here is a simple example: >>>> Create this module: >>>> -module(test). >>>> -compile(export_all). >>>> >>>> start() -> >>>> wx:new(), >>>> wx_object:start_link({local, ?MODULE}, ?MODULE, wx:get_env(), []). >>>> >>>> close(_, _) -> >>>> wx_object:call(?MODULE, stop). >>>> >>>> init(Wx) -> >>>> wx:set_env(Wx), >>>> Mf = wxFrame:new(wx:null(),1,"",[{size,{300,300}}]), >>>> wxFrame:show(Mf), >>>> wxFrame:connect(Mf, close_window, [{callback, fun ?MODULE:close/2}]), >>>> {Mf, Mf}. >>>> >>>> handle_call(stop, _From, Mf) -> >>>> wxFrame:destroy(Mf), >>>> {stop, normal, ok, Mf}. >>>> >>>> terminate(normal, _) -> >>>> ok. >>>> >>>> Then run this in the shell: >>>> Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0] >>>> >>>> Eshell V5.7.1 (abort with ^G) >>>> 1> c(test). >>>> {ok,test} >>>> 2> test:start(). >>>> {wx_ref,35,wxFrame,<0.42.0>} >>>> 3> >>>> >>>> This should give you a small frame, don't close it yet, >>>> Now do this: >>>> 3> net_kernel:start([bad,shortnames]). >>>> {ok,<0.49.0>} >>>> (bad@REDACTED)4> >>>> >>>> Now close the frame and you should see: >>>> =ERROR REPORT==== 14-Oct-2009::13:17:08 === >>>> ** Generic server <0.39.0> terminating >>>> ** Last message in was {'_wxe_destroy_',<3.42.0>} >>>> ** When Server state == {state,#Port<0.2605>,#Port<0.2602>, >>>> >>>> {1,{<0.32.0>,{user,[],[],undefined},nil,nil}}, >>>> [<0.57.0>], >>>> {1,{#Fun,1,nil,nil}}, >>>> 2} >>>> ** Reason for termination == >>>> ** {badarg,[{erlang,is_process_alive,[<3.42.0>]}, >>>> {wxe_server,handle_info,2}, >>>> {gen_server,handle_msg,5}, >>>> {proc_lib,init_p_do_apply,3}]} >>>> >>>> >>>> The pid which comes from the port is not recognized as a local pid and >>>> thus erlang:is_process_alive/1 will exit with badarg. My question >>>> is: Is >>>> this a "feature" or a bug? I think this is a bug but I'm not sure >>>> what is >>>> expected from the wx library point of view. IMHO it shouldn't crash >>>> and just >>>> ignore it in this case because the wxe_server shouldn't be allowed >>>> to crash. >>>> >>>> Anyway I put in a patch as well just in case this is something that >>>> should >>>> be fixed. The patch can be applied to both wx 0.98.1 and 0.98.3. >>>> >>>> Cheers, >>>> >>>> /Mazen >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> ________________________________________________________________ >>>> erlang-patches mailing list. See http://www.erlang.org/faq.html >>>> erlang-patches (at) erlang.org >>>> >>> ________________________________________________________________ >>> erlang-patches mailing list. See http://www.erlang.org/faq.html >>> erlang-patches (at) erlang.org >>> >>> >>> > > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org > From rvirding@REDACTED Fri Oct 16 00:55:30 2009 From: rvirding@REDACTED (Robert Virding) Date: Fri, 16 Oct 2009 00:55:30 +0200 Subject: [erlang-patches] Epp Bugfix and macros overloading In-Reply-To: <4ACF4950.4070409@capflam.org> References: <4ACF4950.4070409@capflam.org> Message-ID: <3dbc6d1c0910151555r6f7c0209r3bc282a7bae53cec@mail.gmail.com> 2009/10/9 christopher faulet > Hi all, > > Here are two patches for the module epp in R13B02-1. > > * The second patch includes the first one and adds support of multiple > definitions for macros in the module epp (i.e. with the same name but > with different arities). This feature wouldn't break any code (I hope so > :) and might be usefull. > > Here is an simple example that uses it: > > ============================= > -module(test). > > -export([test/0]). > > -define(MY_MACRO(), foo). > -define(MY_MACRO, bar). > -define(MY_MACRO(X,Y), {X, Y}). > > > test() -> %% return [bar, foo, foo, {foo, bar}] > [ > ?MY_MACRO, %% use the 2nd def, replaced by bar > ?MY_MACRO(), %% use the 1st def, replaced by foo > ?MY_MACRO(foo), %% use the 2nd def, replaced by bar(foo) > ?MY_MACRO(foo, bar) %% use the 3rd def, replaced by {foo,bar} > ]. > > bar(X) -> > X. > ============================= > I rather like this extension, it is something I always meant to do but never got around to doing. I am not sure, though, that I completely agree with how you choose which definition to use, especially the third case here which I think should give an undefined macro error. My reasoning is that if you define a macro to have arguments, one or many definitions, and call it with arguments, even with an empty argument list then you should only try for the matching definition and not take the one without arguments. So if: -define(M, a). -define(M(), b). -define(M(X,Y), {X,Y}). then ?M - should use 1st def ?M() - should use 2nd def ?M(a,b) - should use 3rd def ?M(a) - should generate an error However if only: -define(M, a). then all calls will use this definition. Robert From christopher.faulet@REDACTED Fri Oct 16 17:16:46 2009 From: christopher.faulet@REDACTED (christopher faulet) Date: Fri, 16 Oct 2009 17:16:46 +0200 Subject: [erlang-patches] Epp Bugfix and macros overloading In-Reply-To: <3dbc6d1c0910151555r6f7c0209r3bc282a7bae53cec@mail.gmail.com> References: <4ACF4950.4070409@capflam.org> <3dbc6d1c0910151555r6f7c0209r3bc282a7bae53cec@mail.gmail.com> Message-ID: <4AD88E5E.7060809@capflam.org> Robert Virding a ?crit : > I rather like this extension, it is something I always meant to do but never > got around to doing. > > I am not sure, though, that I completely agree with how you choose which > definition to use, especially the third case here which I think should give > an undefined macro error. My reasoning is that if you define a macro to have > arguments, one or many definitions, and call it with arguments, even with an > empty argument list then you should only try for the matching definition and > not take the one without arguments. So if: > > -define(M, a). > -define(M(), b). > -define(M(X,Y), {X,Y}). > > then > > ?M - should use 1st def > ?M() - should use 2nd def > ?M(a,b) - should use 3rd def > ?M(a) - should generate an error > > However if only: > > -define(M, a). > > then all calls will use this definition. > Hi Robert, Thanks for your comments. You are probably right. Your solution is less error prone and avoids ambiguities. I made a new patch that takes your suggestion into account. I also modified some errors to be more precise in diagnostics. -- Christopher Faulet -------------- next part -------------- A non-text attachment was scrubbed... Name: overload-epp-R13B2-1.patch Type: text/x-patch Size: 12576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From juhani@REDACTED Sun Oct 18 09:06:44 2009 From: juhani@REDACTED (=?ISO-8859-1?Q?Juhani_R=E4nkimies?=) Date: Sun, 18 Oct 2009 10:06:44 +0300 Subject: [erlang-patches] PATCH: ODBC application discarding sqlstate in get_diagnos function In-Reply-To: References: <20091009174743.GJ11500@hijacked.us> <20091010164544.GA15291@hijacked.us> <20091011181716.GA8073@hijacked.us> Message-ID: On Mon, Oct 12, 2009 at 11:33 PM, Juhani R?nkimies wrote: > On 10/11/09, Andrew Thompson wrote: >> >> Ah, that does sound like a similar issue although I'm not sure my patch >> will solve it. Does it happen consistantly or is it random? Are you >> using parameterized queries? > > it now. I'll try to find time to reproduce it on weekend. > Yes, I'm using param_query. I wasn't able to reproduce the problem at this time. I couldn't use the environment where I observed the problem and the test setup has at least these differences: - newer version of erlang - newer versions of sql server and drivers - it's is not patched to support unicode strings - my tests were light, so if it occurs rarely I might not have caught it next week i'll drop my workaround for {error,"No SQL-driver information available."} from couple of places and see what happens. > Juhani > From jean-sebastien.pedron@REDACTED Mon Oct 19 10:17:54 2009 From: jean-sebastien.pedron@REDACTED (=?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?=) Date: Mon, 19 Oct 2009 10:17:54 +0200 Subject: Bugs in httpc timeout and keep-alive queue handling Message-ID: <4ADC20B2.9070607@dumbbell.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Attached is a patch against R13B02-1 that fixes two bugs in httpc_handler.erl. The first part fixes a bug with request timeout. When a queued request (ie. not the active one in #state.request) times out, the error is sent to the process associated with the active request. If I understand the problem correctly, this means that this process could receive the timeout error and the HTTP response, but the process for which the request timed out won't receive anything. The second part fixes a bug with the keep-alive queue: in terminate/2, the requests in this queue are "forgotten". With the patch, the keep-alive queue is treated like the pipeline queue. The third part adds a clause to the retry_pipline/2 function to not retry timed out requests. With this patch, I couldn't hang httpc with multiple concurrent requests to the same URL (a slow webservice). The handle_info/2 clause printing a warning about unexpected received data isn't triggered anymore (it was added in R13B02). - -- Jean-S?bastien P?dron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrcILIACgkQa+xGJsFYOlPy+ACeNJMIIkKBUaOH7+r7FYBKgSpG C94AoIvGUW4NLh/FjjorTYJJxLVEFjiy =D7JD -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: erlang-R13B02-1-httpc_handler-timeout-handling-a.patch URL: From yrashk@REDACTED Mon Oct 19 13:33:06 2009 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Mon, 19 Oct 2009 04:33:06 -0700 Subject: R13B02-1: a patch for omitting a warning on {foo, bar}:fun(args) calls Message-ID: <565086C4-5094-4CC1-879B-DBEB6EB678A2@gmail.com> Hi, Currently erlc will spit a warning on this kind of constructs: {db, "localhost"}:connect() as opposed to DB = {db, "localhost"}, DB:connect() The warning will look like: Warning: invalid module and/or function name; this call will always fail which is misleading, because this call will not fail (provided modules are in place and such) Here is a proposed solution to the problem: http://github.com/yrashk/erlang/commit/cda6f1727965e6794aa088a200bf6c37c4586958 I am not sure it is perfect (hey, I am not an erlang compiler hacker, as of yet), but it proved to work quite well for me. Any chance it can make it to the mainstream in some way? Thanks, Yurii. From yrashk@REDACTED Mon Oct 19 16:55:42 2009 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Mon, 19 Oct 2009 07:55:42 -0700 Subject: [erlang-patches] R13B02-1: a patch for omitting a warning on {foo, bar}:fun(args) calls In-Reply-To: <4ADC7BF4.30806@gmail.com> References: <565086C4-5094-4CC1-879B-DBEB6EB678A2@gmail.com> <4ADC7BF4.30806@gmail.com> Message-ID: <6C53C4E1-69C6-479B-ADC7-15280D4686FA@gmail.com> On 19-Oct-09, at 7:47 AM, Richard Carlsson wrote: > Yurii Rashkovskii wrote: >> Currently erlc will spit a warning on this kind of constructs: >> >> {db, "localhost"}:connect() >> >> as opposed to >> >> DB = {db, "localhost"}, >> DB:connect() >> >> The warning will look like: >> >> Warning: invalid module and/or function name; this call will always >> fail >> >> which is misleading, because this call will not fail (provided >> modules >> are in place and such) > > When you write code like the above, you are depending on how the > current > implementation of parameterized modules works. Don't do that. I am pretty much aware of this mantra, thanks. In fact, I seldom use parametrized modules per se, I am just utilizing Erlang's capability to treat tuples as modules in another approach to parametrized modules I built for myself. Yurii. From max.lapshin@REDACTED Wed Oct 21 12:55:08 2009 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 21 Oct 2009 14:55:08 +0400 Subject: Capture stderr of spawned process Message-ID: This is patch, required to catch stderr of spawned process (tools like x264 print their status to stderr). bif open_port/2 gets new flag: error ?(maybe bad name?). If you pass it, process will receive messages {error, ErrorData} Patch made for R13B02-1, not appliable for QNX because I even cannot imagine, how to test it. Usage example: Port = open_port({spawn_executable, Cmd}, [stream, {args, Args}, {line, 1000}, error, exit_status, binary, eof]), -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-capture-stderr-of-spawned-process.patch Type: application/octet-stream Size: 16384 bytes Desc: not available URL: From lars@REDACTED Wed Oct 21 16:15:52 2009 From: lars@REDACTED (Lars Thorsen) Date: Wed, 21 Oct 2009 16:15:52 +0200 Subject: [erlang-patches] Patch to fix 630 English typos in documentation In-Reply-To: <732f49190909230541r7629c210u6077712c4e971d1@mail.gmail.com> References: <732f49190909230541r7629c210u6077712c4e971d1@mail.gmail.com> Message-ID: <4ADF1798.9080803@erix.ericsson.se> Hi, thank you for the spelling patch. We have now applied it to our documentation. Best regards, /Lars , Erlang/OTP Ericsson Badlop wrote: > Hello, > > The attached patch fixes 630 English spelling typos in 198 documentation files. > > It is not comprehensive. For instance, the automated spell checking > was limited to verify only lowercase words. During my manual > verification I also discarded some changes. > > The typos were originally extracted from R13B01 documentation, but > I've updated the patch to apply to R13B02, and manually verified it > again. > > > > --- > Badlop > ProcessOne > > > ------------------------------------------------------------------------ > > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org From dmitriy.budashny@REDACTED Thu Oct 22 16:22:38 2009 From: dmitriy.budashny@REDACTED (Dmitriy Budashny) Date: Thu, 22 Oct 2009 17:22:38 +0300 Subject: small patch for tv Message-ID: <891161a10910220722s2cbae812pddbe8fcc1387a263@mail.gmail.com> Hi there I've found some strange issue with tv while using stumpwm. tv was crashing while I was trying to load some table, so I got such output to my console: ### log begins here ### =ERROR REPORT==== 22-Oct-2009::16:31:05 === Error in process <0.571.0> with exit value: {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]} Internal error... restarting. 10> =ERROR REPORT==== 22-Oct-2009::16:31:06 === Error in process <0.578.0> with exit value: {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]} Internal error... restarting. ### log ends here ### So it continued restarting over and over again. The problem was with call to lists:nthtail(6,[]) which raised exception: ** exception error: no function clause matching lists:nthtail(6,[]) So I've made small changes to tv_pg_gridfcns.erl file. Patch attached. -- wbr, dym -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tv_pg_gridfcns.erl.patch Type: application/octet-stream Size: 1109 bytes Desc: not available URL: From dmitriy.budashny@REDACTED Fri Oct 23 10:39:32 2009 From: dmitriy.budashny@REDACTED (Dmitriy Budashny) Date: Fri, 23 Oct 2009 11:39:32 +0300 Subject: small patch for tv In-Reply-To: <891161a10910220722s2cbae812pddbe8fcc1387a263@mail.gmail.com> References: <891161a10910220722s2cbae812pddbe8fcc1387a263@mail.gmail.com> Message-ID: <891161a10910230139w78c1e1aaj8cc90b9f777641b1@mail.gmail.com> My last letter was written w/o testing for other problems, I've found there were other calls to lists:nthtail/2. I've attached a new patch file in this letter 2009/10/22 Dmitriy Budashny > Hi there > I've found some strange issue with tv while using stumpwm. tv was crashing > while I was trying to load some table, so I got such output to my console: > ### log begins here ### > =ERROR REPORT==== 22-Oct-2009::16:31:05 === > Error in process <0.571.0> with exit value: > {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]} > > Internal error... restarting. > 10> > =ERROR REPORT==== 22-Oct-2009::16:31:06 === > Error in process <0.578.0> with exit value: > {function_clause,[{lists,nthtail,[6,[]]},{tv_pg_gridfcns,resize_grid,3},{tv_pg,loop,1}]} > > Internal error... restarting. > ### log ends here ### > > So it continued restarting over and over again. The problem was with call > to lists:nthtail(6,[]) which raised exception: > ** exception error: no function clause matching lists:nthtail(6,[]) > So I've made small changes to tv_pg_gridfcns.erl file. Patch attached. > > -- > wbr, dym > -- wbr, dym -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tv_pg_gridfcns.erl.patch Type: application/octet-stream Size: 2497 bytes Desc: not available URL: