From matthew@REDACTED Tue Feb 2 15:29:42 2010 From: matthew@REDACTED (Matthew Sackman) Date: Tue, 2 Feb 2010 14:29:42 +0000 Subject: [erlang-bugs] win32sysinfo.c doesn't understand DWORDLONG is unsigned and long In-Reply-To: <4B61D072.40304@erix.ericsson.se> References: <20100128170226.GA4191@wellquite.org> <4B61D072.40304@erix.ericsson.se> Message-ID: <20100202142942.GA8311@mrnibble.lshift.net> Hi Bj?rn-Egil, On Thu, Jan 28, 2010 at 06:59:14PM +0100, Bj?rn-Egil Dahlberg wrote: > I will have a look at this but I think you are correct. > %I64d seems to be the wrong thing here. Eeek, my apologies, I am totally wrong. I hadn't realised that Windows has its own version of format specifiers for printf, and thus I64 means exactly "unsigned 64-bit int" which is precisely what's wanted. http://msdn.microsoft.com/en-us/library/56e442dc(VS.71).aspx And indeed release notes for R13B show that this fixed (the bug really did exist before R13B) in os_mon 2.2.1: OTP-7944 An error in memsup could cause os_mon to report erroneous memory values on windows for ranges of memory between 2GB and 4GB. This have now been fixed. Sorry for wasting your time. Matthew From caleb.tennis@REDACTED Sat Feb 6 21:18:52 2010 From: caleb.tennis@REDACTED (Caleb Tennis) Date: Sat, 6 Feb 2010 15:18:52 -0500 Subject: snmp bug? Message-ID: I've been communicating with snmp devices on the network with erlang, but I'm having issues getting MIBs into erlang, but I'm running into errors with the compiler. One of the mibs I've focused on uses the TEXTUAL-CONVENTION macro, but I get these errors when trying to compile it: root@REDACTED:~# erlc AP-SERIES-300-UPS-MODULE-MIB.mib AP-SERIES-300-UPS-MODULE-MIB.mib: 47: Error: Macro 'TEXTUAL-CONVENTION' not imported. AP-SERIES-300-UPS-MODULE-MIB.mib: 54: Error: Macro 'TEXTUAL-CONVENTION' not imported. Now, I recognize this may be an issue with the MIB file itself, and I consider myself far from an snmp expert. But in digging, I've noticed that there are a number of MIBs that come with erlang, and some of them are compiled and put into the priv directory, but not all. In digging some more, it seems like those MIBs don't compile. For example, SNMPv2-TC.mib, which I believe is needed for understanding TEXTUAL-CONVENTIONS, gives this error: root@REDACTED:~# erlc SNMPv2-TC.mib SNMPv2-TC.mib: 8: Error: syntax error before: 'TEXTUAL-CONVENTION' In fact, there are a number of mib files that ship with erlang that give errors like this, all on line with MACRO statements. The erlang code leads me to believe that these *should* work and compile, but it looks like they don't. So, while I'm not positive this is a bug, it smells a bit like one, hence why I'm posting. Thanks, Caleb From kruegger@REDACTED Sun Feb 7 09:44:01 2010 From: kruegger@REDACTED (Stephen Han) Date: Sun, 7 Feb 2010 00:44:01 -0800 Subject: reltool support in MS Windows Message-ID: <86f1f5351002070044r6a36f537y9b112d7b442b0049@mail.gmail.com> Is reltool in R13B-03 supports MS Windows XP? I ran reltool:start() in werl and it crashes the werl. The release note does not talk about supporting platform so I assumes that it should work with Windows. From hakan@REDACTED Sun Feb 7 17:26:26 2010 From: hakan@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Sun, 7 Feb 2010 17:26:26 +0100 Subject: [erlang-bugs] reltool support in MS Windows In-Reply-To: <86f1f5351002070044r6a36f537y9b112d7b442b0049@mail.gmail.com> References: <86f1f5351002070044r6a36f537y9b112d7b442b0049@mail.gmail.com> Message-ID: <922d05851002070826m3b4affa1md585947bc3bffb74@mail.gmail.com> On Sun, Feb 7, 2010 at 9:44 AM, Stephen Han wrote: > Is reltool in R13B-03 supports MS Windows XP? > I ran reltool:start() in werl and it crashes the werl. The release note does > not talk about supporting platform so I assumes that it should work with > Windows. Reltool itself has no such limitations. I suspect that you have encountered some problem with wxErlang. Can you start reltool with: reltool:start_link([{wx_debug, [trace, driver]}]). and send the printouts? /H?kan From mbj@REDACTED Mon Feb 8 09:14:30 2010 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 08 Feb 2010 09:14:30 +0100 (CET) Subject: [erlang-bugs] snmp bug? In-Reply-To: References: Message-ID: <20100208.091430.160465603.mbj@tail-f.com> Hi, Caleb Tennis wrote: > I've been communicating with snmp devices on the network with erlang, but I'm > having issues getting MIBs into erlang, but I'm running into errors with the > compiler. > > One of the mibs I've focused on uses the TEXTUAL-CONVENTION macro, but I get > these errors when trying to compile it: > > root@REDACTED:~# erlc AP-SERIES-300-UPS-MODULE-MIB.mib > AP-SERIES-300-UPS-MODULE-MIB.mib: 47: Error: Macro 'TEXTUAL-CONVENTION' not > imported. > AP-SERIES-300-UPS-MODULE-MIB.mib: 54: Error: Macro 'TEXTUAL-CONVENTION' not > imported. > > Now, I recognize this may be an issue with the MIB file itself It is. The MIB must IMPORT the TEXTUAL-CONVENTION macro. > In digging some more, it seems like those MIBs don't compile. For example, > SNMPv2-TC.mib, which I believe is needed for understanding > TEXTUAL-CONVENTIONS, gives this error: > > root@REDACTED:~# erlc SNMPv2-TC.mib > SNMPv2-TC.mib: 8: Error: syntax error before: 'TEXTUAL-CONVENTION' SNMPv2-TC isn't really a MIB; it defines the ASN.1 macro TEXTUAL-CONVENTION, but unfortunately it also uses the macro and defines some common TEXTUAL-CONVENTIONs. > In fact, there are a number of mib files that ship with erlang that give > errors like this, all on line with MACRO statements. > > The erlang code leads me to believe that these *should* work and compile, but > it looks like they don't. So, while I'm not positive this is a bug, it > smells a bit like one, hence why I'm posting. The erlang MIB compiler simply cannot handle the MACRO statement. It should be straightforward to do what libsmi does - check that the module that contains the MACRO is one of the known modules, and simply skip the MACRO invocation. In any case, the real bug here is that your MIB does not IMPORT TEXTUAL-CONVENTION. Even if the erlang MIB compiler could compile SNMPv2-TC, your MIB needs to be fixed. /martin From vladdu55@REDACTED Mon Feb 8 14:37:04 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 8 Feb 2010 14:37:04 +0100 Subject: documentation of test_server:Case/1 Message-ID: <95be1d3b1002080537l1cd628c5q56d3879d8f9feba4@mail.gmail.com> Hi, I think there are some errors in the docs for test_server:Case/1. See comments below, marked with <<<--- Case(doc) -> [Decription] <<<--- spelling Case(suite) -> [] | TestSpec | {skip, Comment} <<<--- see below, should be 'spec'? Case(Config) -> {skip, Comment} | {comment, Comment} | Ok The specification clause (argument spec) shall return an empty list, the test specification for the test case or {skip,Comment}. The syntax of a test specification is described in the Test Server User's Guide. The execution clause (argument Config) is only called if the specification clause returns an empty list. <<<--- or if spec returns a TestSpec, right? regards, Vlad From kenji.rikitake@REDACTED Wed Feb 10 08:58:32 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 16:58:32 +0900 Subject: Fix typos of lib/sasl/src/rb.erl and lib/snmp/src/misc/snmp_config.erl Message-ID: <20100210075832.GB69344@k2r.org> git fetch git://github.com/jj1bdx/otp.git sasl_snmp_typofix This patch fixes typos of the following two files: lib/sasl/src/rb.erl lib/snmp/src/misc/snmp_config.erl This patch is originally taken from FreeBSD port patch files. Regards, Kenji Rikitake From kenji.rikitake@REDACTED Wed Feb 10 09:11:35 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 17:11:35 +0900 Subject: Fix ODBC compilation error on FreeBSD by adding netinet/in.h to #include macros Message-ID: <20100210081135.GC69344@k2r.org> git fetch git://github.com/jj1bdx/otp.git odbc_netinet Fix ODBC compilation error on FreeBSD by adding netinet/in.h to #include macros This fix modifies lib/odbc/c_src_odbcserver.c This has been tested on FreeBSD port, and will not affect Linux. This patch is originally taken from FreeBSD port patch files, by Giacomo Olgeni. See http://www.erlang.org/cgi-bin/ezmlm-cgi?3:mss:335:200811:hijljjocpmpkhgkhfkdl for the details too Regards, Kenji Rikitake From kenji.rikitake@REDACTED Wed Feb 10 09:25:28 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 17:25:28 +0900 Subject: Fix semantic error of http:request/4 when stream_to() in Options is set to {self, once} Message-ID: <20100210082528.GD69344@k2r.org> git fetch git://github.com/jj1bdx/otp.git r13b03_http_client Fix semantic error of http:request/4 when stream_to() in Options is set to {self, once} Fix the bug in lib/inets/src/http_client/http.erl of the following behavior: error handling when stream_to() = {self} in Options was not executed whenb the stream_to() option is set to {self, once}. Originally from FreeBSD port patch files. See also the "Stream" section of http://www.erlang.org/doc/man/http.html#request-4 Regards, Kenji Rikitake From kenji.rikitake@REDACTED Wed Feb 10 09:51:20 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 17:51:20 +0900 Subject: Fix Makefile permission problem of crypto library on FreeBSD Erlang/OTP building Message-ID: <20100210085120.GG69344@k2r.org> git fetch git://github.com/jj1bdx/otp.git r13b03_crypto_makefile This patch changes INSTALL_PROGRAM to INSTALL_DATA for the Makefile at lib/crypto/priv/obj, which discontinues the building procedure of Erlang/OTP on FreeBSD. Originally posted by Giacomo Olgeni as a part of FreeBSD port patch files. See http://www.erlang.org/cgi-bin/ezmlm-cgi?3:mss:335:200811:hijljjocpmpkhgkhfkdl for the detailed analysis. Regards, Kenji Rikitake From kenji.rikitake@REDACTED Wed Feb 10 10:04:12 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 18:04:12 +0900 Subject: Fix the shell operator bug of "==" to "=" in erts/configure.in Message-ID: <20100210090412.GA71672@k2r.org> git fetch git://github.com/jj1bdx/otp.git r13b03_erts_configure In UNIX test command, "==" is incorrect for string comparison; "=" is the right operator. Originally pointed out by Giacomo Olgeni in the following article: http://www.erlang.org/pipermail/erlang-patches/2008-November/000334.html and available as a FreeBSD port patch. Accordingly fixed in erts/configure.in Regards, Kenji Rikitake From a.zhuravlev@REDACTED Wed Feb 10 10:54:15 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 10 Feb 2010 12:54:15 +0300 Subject: issue with http:request Message-ID: <20100210095415.GB94910@zaa.local> Hello, It looks like there is some issue with http request handling in http:request function or some other subsystem underneath. Here is a test case: Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] 1> inets:start(). ok 2> % this one works as expected 2> http:request(head, {"http://google.com", []}, [{timeout, 100}], []). {error,timeout} 3> URL = [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166,130,227, 3> 129,173,229,189,147,227,129,159,227,129,163,227,129,166,227,130, 3> 139,227,128,130,119,119,119,46,112,97,103,101,46,115,97,110,110, 3> 101,116,46,110,101,46,106,112,47,109,97,121,117,114,105,47,122,121, 3> 111,115,101,105,47,109,97,114,95,51,48,54,46,104,116,109,108]. [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166, 130,227,129,173,229,189,147,227,129,159,227,129,163,227|...] 4> http:request(head, {URL, []}, [{timeout, 100}], []). The latest request hangs indefinitely. Request to the same URL (while being UTF-8 encoded) also hangs: 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). Moreover, http_uri shows that both URLs are valid: 1> http_uri:parse(URL). {http,[], [227,129,147,227,130,140,230,166,130,227,129,173,229,189, 147,227,129,159,227,129,163,227,129,166,227,130|...], 80,"/mayuri/zyosei/mar_306.html",[]} 2> http_uri:parse("http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html"). {http,[], [12371,12428,27010,12397,24403,12383,12387,12390,12427, 12290,119,119,119,46,112,97,103,101,46,115,97,110,110,101, 116,46|...], 80,"/mayuri/zyosei/mar_306.html",[]} Our production system logs the following error to the console (however I do not see it when I run the code in a new local erlang shell), I suppose it is connected to the issue above: =CRASH REPORT==== 10-Feb-2010::12:25:09 === crasher: initial call: httpc_handler:init/1 pid: <0.18577.0> registered_name: [] exception exit: badarg in function gen_tcp:connect/4 in call from httpc_handler:send_first_request/3 in call from httpc_handler:init/1 ancestors: [httpc_handler_sup,httpc_sup,inets_sup,<0.80.0>] messages: [] links: [<0.86.0>] dictionary: [] trap_exit: true status: running heap_size: 233 stack_size: 24 reductions: 104 neighbours: =SUPERVISOR REPORT==== 10-Feb-2010::12:25:09 === Supervisor: {local,httpc_handler_sup} Context: child_terminated Reason: badarg Offender: [{pid,<0.18577.0>}, {name,undefined}, {mfa, {httpc_handler,start_link, [{request,#Ref<0.0.0.79940>,<0.18533.0>,0,http, {[12371,12428,27010,12397,24403,12383,12387, 12390,12427,12290,119,119,119,46,112,97,103, 101,46,115,97,110,110,101,116,46,110,101,46, 106,112], 80}, "/mayuri/zyosei/mar_306.html",[],get, {http_request_h,undefined,"keep-alive", undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined, [12371,12428,27010,12397,24403,12383,12387, 12390,12427,12290,119,119,119,46,112,97, 103,101,46,115,97,110,110,101,116,46,110, 101,46,106,112], undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,[],undefined,undefined,undefined, undefined,"0",undefined,undefined, undefined,undefined,undefined,undefined,[]}, {[],[]}, {http_options,"HTTP/1.1",infinity,true,[], undefined,false,infinity}, [104,116,116,112,58,47,47,12371,12428,27010, 12397,24403,12383,12387,12390,12427,12290,119, 119,119,46,112,97,103,101,46,115,97,110,110, 101,116,46,110,101,46,106,112,47,109,97,121, 117,114,105,47,122,121,111,115,101,105,47,109, 97,114,95,51,48,54,46,104,116,109,108], [],none,[]}, {options, {undefined,[]}, 0,2,5,120000,2,disabled,false,inet,default, default}, httpc_manager]}}, {restart_type,temporary}, {shutdown,4000}, {child_type,worker}] -- Alexander Zhuravlev From a.zhuravlev@REDACTED Wed Feb 10 12:29:04 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 10 Feb 2010 14:29:04 +0300 Subject: [erlang-bugs] issue with http:request In-Reply-To: References: <20100210095415.GB94910@zaa.local> Message-ID: <4B729880.2050800@gmail.com> On 2/10/10 1:52 PM, Kenji Rikitake wrote: >> 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). > > Can you directly write non-ASCII Unicode letters in the URL like this? > I guess not. If the first part ends with .jp were a domain name, this > wouldn't be a legal one because this should have been encoded with IDN > (International Domain Name) encoding, which is represented in ASCII > only. This sort of domain name cannot be handled by DNS. (BTW this is a > mixed string of Japanese and English letters, FYI.) Yes, I know and too think that the URL is not correct, however erlang http client code (or underlying inets code?) does not handle this case correctly and just crash or hang, regardless of the fact that the function should have returned within 100 ms. It is just a question of correct input handling. From kenji.rikitake@REDACTED Wed Feb 10 12:33:20 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 20:33:20 +0900 Subject: [erlang-bugs] issue with http:request In-Reply-To: <4B729880.2050800@gmail.com> References: <20100210095415.GB94910@zaa.local> <4B729880.2050800@gmail.com> Message-ID: <20100210113320.GA74641@k2r.org> I understand your problem, and I think that is a part of broader issue of Unicode string handling in Erlang/OTP. Kenji Rikitake In the message <4B729880.2050800@REDACTED> dated Wed, Feb 10, 2010 at 02:28:40PM +0300, Alexander Zhuravlev writes: > On 2/10/10 1:52 PM, Kenji Rikitake wrote: > >> 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). > > > > Can you directly write non-ASCII Unicode letters in the URL like this? > > I guess not. If the first part ends with .jp were a domain name, this > > wouldn't be a legal one because this should have been encoded with IDN > > (International Domain Name) encoding, which is represented in ASCII > > only. This sort of domain name cannot be handled by DNS. (BTW this is a > > mixed string of Japanese and English letters, FYI.) > > Yes, I know and too think that the URL is not correct, however > erlang http client code (or underlying inets code?) does not handle > this case correctly and just crash or hang, regardless of the fact that > the function should have returned within 100 ms. It is just a question > of correct input handling. From bgustavsson@REDACTED Wed Feb 10 13:09:38 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 10 Feb 2010 13:09:38 +0100 Subject: [erlang-patches] Fix the shell operator bug of "==" to "=" in erts/configure.in In-Reply-To: <20100210090412.GA71672@k2r.org> References: <20100210090412.GA71672@k2r.org> Message-ID: <6672d0161002100409j57ffbf4ehc165edb3bfa6b976@mail.gmail.com> On Wed, Feb 10, 2010 at 10:04 AM, Kenji Rikitake wrote: > git fetch git://github.com/jj1bdx/otp.git r13b03_erts_configure Thanks! We will probably apply the patch directly on the dev branch. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From a.zhuravlev@REDACTED Wed Feb 10 14:08:51 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 10 Feb 2010 16:08:51 +0300 Subject: issue with http:request In-Reply-To: <20100210095415.GB94910@zaa.local> References: <20100210095415.GB94910@zaa.local> Message-ID: <4B72AFE3.1020608@gmail.com> On 2/10/10 12:54 PM, Alexander Zhuravlev wrote: > Hello, > > It looks like there is some issue with http request handling in > http:request function or some other subsystem underneath. > > Here is a test case: > > Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] > > 1> inets:start(). > ok > 2> % this one works as expected > 2> http:request(head, {"http://google.com", []}, [{timeout, 100}], []). > {error,timeout} > 3> URL = [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166,130,227, > 3> 129,173,229,189,147,227,129,159,227,129,163,227,129,166,227,130, > 3> 139,227,128,130,119,119,119,46,112,97,103,101,46,115,97,110,110, > 3> 101,116,46,110,101,46,106,112,47,109,97,121,117,114,105,47,122,121, > 3> 111,115,101,105,47,109,97,114,95,51,48,54,46,104,116,109,108]. > [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166, > 130,227,129,173,229,189,147,227,129,159,227,129,163,227|...] > 4> http:request(head, {URL, []}, [{timeout, 100}], []). > > The latest request hangs indefinitely. > Request to the same URL (while being UTF-8 encoded) also hangs: > > 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). > > Moreover, http_uri shows that both URLs are valid: > > 1> http_uri:parse(URL). > {http,[], [227,129,147,227,130,140,230,166,130,227,129,173,229,189, > 147,227,129,159,227,129,163,227,129,166,227,130|...], > 80,"/mayuri/zyosei/mar_306.html",[]} > > 2> > http_uri:parse("http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html"). > {http,[], > [12371,12428,27010,12397,24403,12383,12387,12390,12427, > 12290,119,119,119,46,112,97,103,101,46,115,97,110,110,101, > 116,46|...], 80,"/mayuri/zyosei/mar_306.html",[]} > > > Our production system logs the following error to the console (however I do not see it when I run the > code in a new local erlang shell), I suppose it is connected to the issue above: > > =CRASH REPORT==== 10-Feb-2010::12:25:09 === > crasher: > initial call: httpc_handler:init/1 > pid:<0.18577.0> > registered_name: [] > exception exit: badarg > in function gen_tcp:connect/4 > in call from httpc_handler:send_first_request/3 > in call from httpc_handler:init/1 > ancestors: [httpc_handler_sup,httpc_sup,inets_sup,<0.80.0>] > messages: [] > links: [<0.86.0>] > dictionary: [] > trap_exit: true > status: running > heap_size: 233 > stack_size: 24 > reductions: 104 > neighbours: > > =SUPERVISOR REPORT==== 10-Feb-2010::12:25:09 === > Supervisor: {local,httpc_handler_sup} > Context: child_terminated > Reason: badarg > Offender: [{pid,<0.18577.0>}, > {name,undefined}, > {mfa, > {httpc_handler,start_link, > [{request,#Ref<0.0.0.79940>,<0.18533.0>,0,http, > {[12371,12428,27010,12397,24403,12383,12387, > 12390,12427,12290,119,119,119,46,112,97,103, > 101,46,115,97,110,110,101,116,46,110,101,46, > 106,112], > 80}, > "/mayuri/zyosei/mar_306.html",[],get, > {http_request_h,undefined,"keep-alive", > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined, > [12371,12428,27010,12397,24403,12383,12387, > 12390,12427,12290,119,119,119,46,112,97, > 103,101,46,115,97,110,110,101,116,46,110, > 101,46,106,112], > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,[],undefined,undefined,undefined, > undefined,"0",undefined,undefined, > undefined,undefined,undefined,undefined,[]}, > {[],[]}, > {http_options,"HTTP/1.1",infinity,true,[], > undefined,false,infinity}, > [104,116,116,112,58,47,47,12371,12428,27010, > 12397,24403,12383,12387,12390,12427,12290,119, > 119,119,46,112,97,103,101,46,115,97,110,110, > 101,116,46,110,101,46,106,112,47,109,97,121, > 117,114,105,47,122,121,111,115,101,105,47,109, > 97,114,95,51,48,54,46,104,116,109,108], > [],none,[]}, > {options, > {undefined,[]}, > 0,2,5,120000,2,disabled,false,inet,default, > default}, > httpc_manager]}}, > {restart_type,temporary}, > {shutdown,4000}, > {child_type,worker}] > We have managed to deploy a workaround for the issue with request hanging using a patch from: http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1601 Now the http:request(head, {URL, []}, [{timeout, 5000}], []) function call returns: {error, internal_error} Here is the patch in the unified format: --- httpc_manager.erl 2009-11-10 19:06:40.000000000 +0300 +++ /home/zaa/httpc_manager.erl 2010-02-10 15:22:23.000000000 +0300 @@ -363,6 +363,11 @@ %% Handled in DOWN {noreply, State}; handle_info({'DOWN', _, _, Pid, _}, State) -> + Requests = ets:match(State#state.handler_db, {'$1', Pid, '$2'}), + [begin + httpc_response:send(From, {Id, {error, internal_error}}) end || + [Id, From] <- Requests], + ets:match_delete(State#state.handler_db, {'_', Pid, '_'}), %% If there where any canceled request, handled by the @@ -500,10 +505,31 @@ ets:insert(State#state.handler_db, {Request#request.id, HandlerPid, Request#request.from}); - _ -> %timeout pipelining failed + Error -> %timeout pipelining failed + case Error of + {request_failed, _Reason, Queue} -> + spawn(fun() -> restart_requests(Queue, State) end); + _E -> + ok + end, start_handler(Request, State) end. +restart_requests([], _) -> ok; +restart_requests([undefined | Queue], State) -> + restart_requests(Queue, State); +restart_requests([Request = #request{ from = answer_sent} | Queue], State) -> + restart_requests(Queue, State); +restart_requests([Request | Queue], State) -> + restart_request(Request, State), + restart_requests(Queue, State). + +restart_request(Request, State) -> + ProfileName = State#state.profile_name, + catch ets:delete(State#state.handler_db, Request#request.id), + httpc_manager:request(Request, ProfileName). + + start_handler(Request, State) -> {ok, Pid} = case is_inets_manager() of --- httpc_handler.erl 2009-11-10 19:06:40.000000000 +0300 +++ /home/zaa/httpc_handler.erl 2010-02-10 15:22:23.000000000 +0300 @@ -284,7 +284,7 @@ undefined}}} end; {error, Reason} -> - {reply, {pipline_failed, Reason}, State} + return_error(pipline_failed, Reason, State) end; handle_call(Request, _, #state{session = Session = @@ -337,9 +337,17 @@ Relaxed]}}} end; {error, Reason} -> - {reply, {request_failed, Reason}, State} + return_error(request_failed, Reason, State) end. +return_error(Error, Reason, State) -> + Queue = case State#state.status of + pipeline -> State#state.pipeline; + keep_alive -> State#state.keep_alive; + _ -> [] + end, + {reply, {Error, Reason, [State#state.request | queue:to_list(Queue)]}, State#state{ pipeline = queue:new(), keep_alive = queue:new() }}. + %%-------------------------------------------------------------------- %% Function: handle_cast(Msg, State) -> {noreply, State} | %% {noreply, State, Timeout} | From kenji.rikitake@REDACTED Wed Feb 10 14:42:20 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 22:42:20 +0900 Subject: Fix beam/erl_bif_re.c building bug due to wrong version of PCRE is used Message-ID: <20100210134220.GA76956@k2r.org> git fetch git://github.com/jj1bdx/otp.git r13b03_compile_pcre Reported by Giacomo Olgeni in the follwing message http://www.erlang.org/cgi-bin/ezmlm-cgi?3:mss:335:200811:hijljjocpmpkhgkhfkdl Giacomo also reported this patch is still needed in the latest build (R13B03) of FreeBSD Erlang port. Patch summary: Sorting the $(CC) command line flag so that the local $(INCLUDES) show up as the first option is required to link with correct PCRE version. This patch is mandatory for FreeBSD port build of lang/erlang (and will not harm the building procedure of other OS) Regards, Kenji Rikitake From kenji.rikitake@REDACTED Wed Feb 10 14:52:07 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 22:52:07 +0900 Subject: Fix building error of SCTP in FreeBSD 7.1 and later Message-ID: <20100210135207.GB76956@k2r.org> git fetch git://github.com/jj1bdx/otp.git r13b03_sctp_freebsd Fix building error of SCTP in FreeBSD 7.1 and later This patch fixes building error of SCTP in FreeBSD 7.1 and later. See http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1257:200904:hppnfialjjdlgecdiehe for the details. Patch summary: R13A patch for solving a compilation error when building erts/emulator/drivers/common/inet_drv.c by Kenji Rikitake 12-APR-2009 Symptom solved by this patch: When building R13A in FreeBSD 7.1-RELEASE, the compiler flag HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY is NOT enabled. Some code in erts/emulator/drivers/common/inet_drv.c incorrectly assumes HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY is always true when HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_FLAGS is true in config.h. This assumption causes a compilation error. Regards, Kenji Rikitake From raimo+erlang-bugs@REDACTED Wed Feb 10 16:39:45 2010 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 10 Feb 2010 16:39:45 +0100 Subject: [erlang-bugs] Fix building error of SCTP in FreeBSD 7.1 and later In-Reply-To: <20100210135207.GB76956@k2r.org> References: <20100210135207.GB76956@k2r.org> Message-ID: <20100210153945.GA22452@erix.ericsson.se> On Wed, Feb 10, 2010 at 10:52:07PM +0900, Kenji Rikitake wrote: > git fetch git://github.com/jj1bdx/otp.git r13b03_sctp_freebsd > > Fix building error of SCTP in FreeBSD 7.1 and later > > This patch fixes building error of SCTP in FreeBSD 7.1 and later. > > See > http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1257:200904:hppnfialjjdlgecdiehe > for the details. It seems Giacomo Olgeni's patch that this patch depends on is missing. erts/configure will not define HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY so it will be disabled on all platforms even the ones that have that flag... And that would be bad. See also: http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1264 sorry about me not managing to rework that issue, other emergencies came in the way... > > Patch summary: > > R13A patch for solving a compilation error when building > erts/emulator/drivers/common/inet_drv.c > by Kenji Rikitake 12-APR-2009 > > Symptom solved by this patch: > > When building R13A in FreeBSD 7.1-RELEASE, > the compiler flag > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY > is NOT enabled. > Some code in > erts/emulator/drivers/common/inet_drv.c > incorrectly assumes > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY > is always true when > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_FLAGS > is true in config.h. > This assumption causes a compilation error. > > Regards, > Kenji Rikitake > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Wed Feb 10 17:12:32 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 10 Feb 2010 17:12:32 +0100 Subject: [erlang-patches] Fix typos of lib/sasl/src/rb.erl and lib/snmp/src/misc/snmp_config.erl In-Reply-To: <20100210075832.GB69344@k2r.org> References: <20100210075832.GB69344@k2r.org> Message-ID: <6672d0161002100812k11981e8ek7d905b798f2d14b2@mail.gmail.com> On Wed, Feb 10, 2010 at 8:58 AM, Kenji Rikitake wrote: > git fetch git://github.com/jj1bdx/otp.git sasl_snmp_typofix > > This patch fixes typos of the following two files: > lib/sasl/src/rb.erl Will be included in pu > lib/snmp/src/misc/snmp_config.erl Micael Karlberg will handle this change. In general, unrelated changes to different applications are better put into separate commits. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Wed Feb 10 17:26:44 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 10 Feb 2010 17:26:44 +0100 Subject: [erlang-bugs] Fix beam/erl_bif_re.c building bug due to wrong version of PCRE is used In-Reply-To: <20100210134220.GA76956@k2r.org> References: <20100210134220.GA76956@k2r.org> Message-ID: <6672d0161002100826v20e97c5cne5bff086f531db9c@mail.gmail.com> On Wed, Feb 10, 2010 at 2:42 PM, Kenji Rikitake wrote: > git fetch git://github.com/jj1bdx/otp.git r13b03_compile_pcre Thanks! Will include in pu. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Wed Feb 10 17:29:13 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 10 Feb 2010 17:29:13 +0100 Subject: [erlang-bugs] Fix Makefile permission problem of crypto library on FreeBSD Erlang/OTP building In-Reply-To: <20100210085120.GG69344@k2r.org> References: <20100210085120.GG69344@k2r.org> Message-ID: <6672d0161002100829v9a732d7q4fa0feb2399f296@mail.gmail.com> On Wed, Feb 10, 2010 at 9:51 AM, Kenji Rikitake wrote: > git fetch git://github.com/jj1bdx/otp.git r13b03_crypto_makefile > Thanks! Will include in pu. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kenji.rikitake@REDACTED Thu Feb 11 00:20:20 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 11 Feb 2010 08:20:20 +0900 Subject: [erlang-patches] Fix calendar:local_time_to_universal_time_dst/2 bug of return value -1 from mktime In-Reply-To: <6672d0161002100626y36ab72f4oc451c9478865be75@mail.gmail.com> References: <20100210051304.GA48531@k2r.org> <6672d0161002092257s10b3dbd1u1fd225c93ef17048@mail.gmail.com> <6672d0161002100626y36ab72f4oc451c9478865be75@mail.gmail.com> Message-ID: <20100210232020.GA83470@k2r.org> Bjorn and all: I would like the mktime fix of erl_time_sup.c to be included ASAP. (check out git fetch git://github.com/jj1bdx/otp.git local_to_univ for the patch details) In the message <6672d0161002100626y36ab72f4oc451c9478865be75@REDACTED> dated Wed, Feb 10, 2010 at 03:26:07PM +0100, Bjorn Gustavsson writes: > We don't want the change in calendar.erl. > > The documentation says that local_time_to_universal_time_dst/1 > returns an empty list for a time that does not exist. We don't want > the same return value for a valid time that cannot be handled because > of an implementation detail. I will not argue against this decision for the time being. > We may consider using the patch for erl_time_sup.c, if you can > provide some information to show that it is really needed. Note > that the BIF does a range check of its arguments. Are there some > values of the arguments that slip through the range check and > cause mktime() to return -1? > > Since such a change is considered a bug fix, we can accept > it after the feature freeze today. Paul Guyot summarized the case in http://www.erlang.org/pipermail/erlang-bugs/2008-November/001077.html as: (quote) "I found a bug in Erlang/OTP R12B-4 that occurs on FreeBSD 7.0 with TZ set to UTC. On such systems, mktime(3) returns -1 when is_dst is set to true. According to SUSv3, the OS can return -1 when the time since Epoch cannot be represented, and therefore FreeBSD is perfectly allowed to do so. http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html " (unquote) The POSIX doc for mktime in the above opengroup.org link shows the following definition for the return value: (quote) RETURN VALUE The mktime() function shall return the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 and may set errno to indicate the error. (unquote) And a source code of error checking example as: (quote) /* What day of the week is July 4, 2001? */ #include #include struct tm time_str; char daybuf[20]; int main(void) { time_str.tm_year = 2001 - 1900; time_str.tm_mon = 7 - 1; time_str.tm_mday = 4; time_str.tm_hour = 0; time_str.tm_min = 0; time_str.tm_sec = 1; time_str.tm_isdst = -1; if (mktime(&time_str) == -1) /* <-- HERE */ (void)puts("-unknown-"); else { (void)strftime(daybuf, sizeof(daybuf), "%A", &time_str); (void)puts(daybuf); } return 0; } (unquote) So I think the -1 return value of mktime should be properly handled. Regards, Kenji Rikitake > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > ________________________________________________________________ > erlang-patches (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED From kenji.rikitake@REDACTED Thu Feb 11 00:46:53 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 11 Feb 2010 08:46:53 +0900 Subject: [erlang-bugs] Fix building error of SCTP in FreeBSD 7.1 and later In-Reply-To: <20100210153945.GA22452@erix.ericsson.se> References: <20100210135207.GB76956@k2r.org> <20100210153945.GA22452@erix.ericsson.se> Message-ID: <20100210234653.GA83952@k2r.org> Raimo: Thanks for comments. I will rework this patch after R13B04 comes out. (I have other higher-priority projects than this one) Kenji Rikitake In the message <20100210153945.GA22452@REDACTED> dated Wed, Feb 10, 2010 at 04:39:21PM +0100, Raimo Niskanen writes: > On Wed, Feb 10, 2010 at 10:52:07PM +0900, Kenji Rikitake wrote: > > git fetch git://github.com/jj1bdx/otp.git r13b03_sctp_freebsd > > > > Fix building error of SCTP in FreeBSD 7.1 and later > > > > This patch fixes building error of SCTP in FreeBSD 7.1 and later. > > > > See > > http://www.erlang.org/cgi-bin/ezmlm-cgi?2:mss:1257:200904:hppnfialjjdlgecdiehe > > for the details. > > It seems Giacomo Olgeni's patch that this patch depends on > is missing. erts/configure will not define > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY so it will > be disabled on all platforms even the ones that have > that flag... And that would be bad. > > See also: > http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1264 > sorry about me not managing to rework that issue, > other emergencies came in the way... > > > > > Patch summary: > > > > R13A patch for solving a compilation error when building > > erts/emulator/drivers/common/inet_drv.c > > by Kenji Rikitake 12-APR-2009 > > > > Symptom solved by this patch: > > > > When building R13A in FreeBSD 7.1-RELEASE, > > the compiler flag > > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY > > is NOT enabled. > > Some code in > > erts/emulator/drivers/common/inet_drv.c > > incorrectly assumes > > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_SACKDELAY > > is always true when > > HAVE_STRUCT_SCTP_PADDRPARAMS_SPP_FLAGS > > is true in config.h. > > This assumption causes a compilation error. > > > > Regards, > > Kenji Rikitake From bgustavsson@REDACTED Thu Feb 11 07:38:19 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 11 Feb 2010 07:38:19 +0100 Subject: [erlang-patches] Fix calendar:local_time_to_universal_time_dst/2 bug of return value -1 from mktime In-Reply-To: <20100210232020.GA83470@k2r.org> References: <20100210051304.GA48531@k2r.org> <6672d0161002092257s10b3dbd1u1fd225c93ef17048@mail.gmail.com> <6672d0161002100626y36ab72f4oc451c9478865be75@mail.gmail.com> <20100210232020.GA83470@k2r.org> Message-ID: <6672d0161002102238w7a62fa55gbf1d62758674b371@mail.gmail.com> 2010/2/11 Kenji Rikitake : > I would like the mktime fix of erl_time_sup.c to be included ASAP. I will include a fix in a new branch in pu and unless it causes any problems in our daily builds (unlikely), it will be included in R13B04. See the end of the email for the fix and my description of it. >> The documentation says that local_time_to_universal_time_dst/1 >> returns an empty list for a time that does not exist. We don't want >> the same return value for a valid time that cannot be handled because >> of an implementation detail. > > I will not argue against this decision for the time being. We may change our minds if the patch is to be included in a major release (such as R14, where some incompatibilities are allowed) and the patch is ready in good time before the release so we don't have to rush the review. I agree that calendar will need some sort of update to properly handle badargs from local_time_to_universal_time(). Here is my suggested patch (which will soon be included in pu): Subject: [PATCH] erl_time_sup.c: test for error return from mktime() When converting from local time to universal time in erlang:localtime_to_universal_time/2, the return value from mktime() is not checked, so if it returns -1 (an error return), the BIF will return a time just before the start of the epoch (namely {{1969,12,31},{23,59,59}}). There is a range check in erlang:localtime_to_universal_time/2 that causes an badarg exception if the arguments are out their valid ranges (for example, year less than 1970 or month greater than 12). At least on FreeBSD systems, however, mktime() returns -1 when the TZ is set to UTC and is_dst is set to true. Therefore it is necessary to check the return value of mktime() and cause a badarg exception if it is -1. Reported by Kenji Rikitake and Paul Guyot. See: http://www.erlang.org/pipermail/erlang-bugs/2008-November/001077.html --- erts/emulator/beam/erl_time_sup.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/erts/emulator/beam/erl_time_sup.c b/erts/emulator/beam/erl_time_sup.c index c15f85f..51202fb 100644 --- a/erts/emulator/beam/erl_time_sup.c +++ b/erts/emulator/beam/erl_time_sup.c @@ -650,6 +650,9 @@ local_to_univ(Sint *year, Sint *month, Sint *day, t.tm_sec = *second; t.tm_isdst = isdst; the_clock = mktime(&t); + if (the_clock == -1) { + return 0; + } #ifdef HAVE_GMTIME_R gmtime_r(&the_clock, (tm = &tmbuf)); #else -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kenji.rikitake@REDACTED Thu Feb 11 09:25:18 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 11 Feb 2010 17:25:18 +0900 Subject: [erlang-patches] Fix calendar:local_time_to_universal_time_dst/2 bug of return value -1 from mktime In-Reply-To: <6672d0161002102238w7a62fa55gbf1d62758674b371@mail.gmail.com> References: <20100210051304.GA48531@k2r.org> <6672d0161002092257s10b3dbd1u1fd225c93ef17048@mail.gmail.com> <6672d0161002100626y36ab72f4oc451c9478865be75@mail.gmail.com> <20100210232020.GA83470@k2r.org> <6672d0161002102238w7a62fa55gbf1d62758674b371@mail.gmail.com> Message-ID: <20100211082518.GA84396@k2r.org> I'll keep this terse: In the message <6672d0161002102238w7a62fa55gbf1d62758674b371@REDACTED> dated Thu, Feb 11, 2010 at 07:37:55AM +0100, Bj?rn Gustavsson writes: > 2010/2/11 Kenji Rikitake : > > I would like the mktime fix of erl_time_sup.c to be included ASAP. > > I will include a fix in a new branch in pu and unless it causes any > problems in our daily builds (unlikely), it will be included in R13B04. > See the end of the email for the fix and my description of it. The patch is confirmed and I have no objection. > >> The documentation says that local_time_to_universal_time_dst/1 > >> returns an empty list for a time that does not exist. We don't want > >> the same return value for a valid time that cannot be handled because > >> of an implementation detail. > > > > I will not argue against this decision for the time being. > > We may change our minds if the patch is to be included in > a major release (such as R14, where some incompatibilities > are allowed) and the patch is ready in good time before the > release so we don't have to rush the review. I agree that calendar > will need some sort of update to properly handle badargs from > local_time_to_universal_time(). I'd be glad if Erlang/OTP team will review the semantics of local_time_to_universal_time() again before R14. > Here is my suggested patch (which will soon be included in pu): > > Subject: [PATCH] erl_time_sup.c: test for error return from mktime() Patch confirmed. (rest deleted) Regards, Kenji Rikitake From nem@REDACTED Thu Feb 18 23:27:32 2010 From: nem@REDACTED (Geoff Cant) Date: Thu, 18 Feb 2010 14:27:32 -0800 Subject: Strings handled differently in the shell and compiled modules Message-ID: I've just been working on some code and came across a surprising result and wonder if it's a bug. If I create a module with a unicode string: %%%%% -module(unitest). -export([test/0]). test() -> "?|?|?|[\\-\\.!,]". %%%%% Then the following is true in the shell: unitest:test() =/= "?|?|?|[\\-\\.!,]". That is, the string literal in the module is a list of utf-8 bytes and the shell string literal is a list of unicode codepoints; string literals have a different value depending on their context. Have I simply missed something in the documentation that says this is the expected behaviour? If not, then it'd be nice if shell code and module code behaved as similarly as possible. Cheers, -- Geoff Cant From igorrs@REDACTED Fri Feb 19 05:48:45 2010 From: igorrs@REDACTED (Igor Ribeiro Sucupira) Date: Fri, 19 Feb 2010 02:48:45 -0200 Subject: [erlang-bugs] Strings handled differently in the shell and compiled modules In-Reply-To: References: Message-ID: Hi, Geoff. An Erlang "string" is actually just a list of integers representing ISO-8859-1 characters. 1> [202, 204]. "??" If you need to work with Unicode characters, this module might help: http://www.erlang.org/doc/man/unicode.html Good luck. Igor. On Thu, Feb 18, 2010 at 8:27 PM, Geoff Cant wrote: > > I've just been working on some code and came across a surprising result > and wonder if it's a bug. > > If I create a module with a unicode string: > > %%%%% > -module(unitest). > -export([test/0]). > > test() -> > ? ?"?|?|?|[\\-\\.!,]". > %%%%% > > Then the following is true in the shell: > unitest:test() =/= "?|?|?|[\\-\\.!,]". > > That is, the string literal in the module is a list of utf-8 bytes and > the shell string literal is a list of unicode codepoints; string > literals have a different value depending on their context. > > Have I simply missed something in the documentation that says this is > the expected behaviour? If not, then it'd be nice if shell code and > module code behaved as similarly as possible. > > Cheers, > -- > Geoff Cant > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- "The secret of joy in work is contained in one word - excellence. To know how to do something well is to enjoy it." - Pearl S. Buck. From raimo+erlang-bugs@REDACTED Fri Feb 19 14:00:30 2010 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 19 Feb 2010 14:00:30 +0100 Subject: [erlang-bugs] Strings handled differently in the shell and compiled modules In-Reply-To: References: Message-ID: <20100219130030.GA5440@erix.ericsson.se> On Thu, Feb 18, 2010 at 02:27:32PM -0800, Geoff Cant wrote: > > I've just been working on some code and came across a surprising result > and wonder if it's a bug. > > If I create a module with a unicode string: > > %%%%% > -module(unitest). > -export([test/0]). > > test() -> > "?|?|???|[\\-\\.!,]". > %%%%% > > Then the following is true in the shell: > unitest:test() =/= "?|?|???|[\\-\\.!,]". > > That is, the string literal in the module is a list of utf-8 bytes and > the shell string literal is a list of unicode codepoints; string > literals have a different value depending on their context. > > Have I simply missed something in the documentation that says this is > the expected behaviour? If not, then it'd be nice if shell code and > module code behaved as similarly as possible. It might be a terminal and locale problem. What does this produce? 1> io:format("~w~n", ["?|?|???|[\\-\\.!,]"]). 2> io:format("~w~n", [unitest:test()]). And, at the shell prompt: $ locale $ env | grep '^LC_' $ echo $LANG $ cat >test.txt ?|?|???|[\\-\\.!,] ^D $ hexdump -C test.txt > > Cheers, > -- > Geoff Cant > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From ulf.wiger@REDACTED Mon Feb 22 17:13:08 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 22 Feb 2010 17:13:08 +0100 Subject: inconsistency in mnesia user guide Message-ID: <4B82AD14.3040704@erlang-solutions.com> In http://www.erlang.org/doc/apps/mnesia/Mnesia_App_C.html#id2278898 Appendix C: The Activity Access Call Back Interface The example code exports the function select_cont/3, but that function is not present in the listed module. Sorry for not offering a patch. No time at the moment. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From aquino.gustavo@REDACTED Thu Feb 25 23:57:49 2010 From: aquino.gustavo@REDACTED (Gustavo Aquino) Date: Thu, 25 Feb 2010 19:57:49 -0300 Subject: Unexpected behaviour from operating system high resolution timermake Message-ID: <5ef296b31002251457k24364253sc035fcc0c739e9c7@mail.gmail.com> Hi, I'm trying to install Erlang on RHE on VM if this VM have one CPU qith 2 cores I got no problem, but if I put more than 1 cpu with 2 cores I always get "Unexpected behaviour from operating system high resolution timermake" problem. I tried to found something on internet but don't found nothing about this problem... just a kernel CLOCK MONOTONIC problem, but without clue ... It's a BUG or have some clue to solve it ? Regards. Gustavo *Problem:* make[3]: Entering directory `/root/download/otp_src_R13B04/lib/hipe/rtl' erlc -W +debug_info +inline -o../ebin hipe_rtl_cfg.erl Crash dump was written to: erl_crash.dump Unexpected behaviour from operating system high resolution timermake[3]: *** [../ebin/hipe_rtl_cfg.beam] Aborted *System info:* # uname -a Linux fsp-srv-oms-d02.fatordoria.br 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:12 EDT 2008 i686 i686 i386 GNU/Linux # cat /proc/version Linux version 2.6.18-92.el5 (brewbuilder@REDACTED) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-41)) #1 SMP Tue Apr 29 13:16:12 EDT 2008 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz stepping : 11 cpu MHz : 1591.045 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni cx16 lahf_lm bogomips : 3243.03 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz stepping : 11 cpu MHz : 1591.045 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni cx16 lahf_lm bogomips : 3194.36 From jmakarlsson@REDACTED Sun Feb 28 10:09:44 2010 From: jmakarlsson@REDACTED (J K) Date: Sun, 28 Feb 2010 01:09:44 -0800 (PST) Subject: module name with . Message-ID: <373657.24739.qm@web113418.mail.gq1.yahoo.com> Hi, is this a bug? Erlang R13B01 (erts-5.7.2) [smp:2:2] [rq:2] [async-threads:0] Eshell V5.7.2 (abort with ^G) 4> c('fm2.2'). fm2.2.beam: Module name 'fm2.2' does not match file name 'fm2.2' error 5> i have: -module('fm2.2'). BR Johan From rvirding@REDACTED Sun Feb 28 17:15:36 2010 From: rvirding@REDACTED (Robert Virding) Date: Sun, 28 Feb 2010 17:15:36 +0100 Subject: [erlang-bugs] module name with . In-Reply-To: <373657.24739.qm@web113418.mail.gq1.yahoo.com> References: <373657.24739.qm@web113418.mail.gq1.yahoo.com> Message-ID: <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> My guess is that you are interacting with the experimental, and poorly documented, package system which assumes things when it sees module names with '.'. As far as I know there is no way to turn this off. Someone else may know more about this. My only suggestion is to avoid module names with a '.'. Robert On 28 February 2010 10:09, J K wrote: > Hi, > is this a bug? > > Erlang R13B01 (erts-5.7.2) [smp:2:2] [rq:2] [async-threads:0] > > Eshell V5.7.2 ?(abort with ^G) > > 4> c('fm2.2'). > fm2.2.beam: Module name 'fm2.2' does not match file name 'fm2.2' > error > 5> > > i have: > -module('fm2.2'). > > BR > Johan > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > From jmakarlsson@REDACTED Sun Feb 28 17:57:29 2010 From: jmakarlsson@REDACTED (J K) Date: Sun, 28 Feb 2010 08:57:29 -0800 (PST) Subject: [erlang-bugs] module name with . In-Reply-To: <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> References: <373657.24739.qm@web113418.mail.gq1.yahoo.com> <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> Message-ID: <141807.74724.qm@web113407.mail.gq1.yahoo.com> My opinion is that experimental stuff should be off by default. I'm using "_" now. I tried comma just for "fun": 254> c(fm2,2). ./fm2.erl:none: no such file or directory error 255> compile:file(fm2,2.erl). * 1: illegal expression 256> compile:file('fm2,2.erl'). {ok,'fm2,2'} 257> Maybe something with the shell? Johan ----- Original Message ---- From: Robert Virding To: J K Cc: Erlang Bugs Sent: Sun, February 28, 2010 5:15:36 PM Subject: Re: [erlang-bugs] module name with . My guess is that you are interacting with the experimental, and poorly documented, package system which assumes things when it sees module names with '.'. As far as I know there is no way to turn this off. Someone else may know more about this. My only suggestion is to avoid module names with a '.'. Robert On 28 February 2010 10:09, J K wrote: > Hi, > is this a bug? > > Erlang R13B01 (erts-5.7.2) [smp:2:2] [rq:2] [async-threads:0] > > Eshell V5.7.2 (abort with ^G) > > 4> c('fm2.2'). > fm2.2.beam: Module name 'fm2.2' does not match file name 'fm2.2' > error > 5> > > i have: > -module('fm2.2'). > > BR > Johan > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > From hynek@REDACTED Sun Feb 28 22:44:13 2010 From: hynek@REDACTED (Hynek Vychodil) Date: Sun, 28 Feb 2010 22:44:13 +0100 Subject: [erlang-bugs] module name with . In-Reply-To: <141807.74724.qm@web113407.mail.gq1.yahoo.com> References: <373657.24739.qm@web113418.mail.gq1.yahoo.com> <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> <141807.74724.qm@web113407.mail.gq1.yahoo.com> Message-ID: <4d08db371002281344n5cb468eby651202717c4382d5@mail.gmail.com> On Sun, Feb 28, 2010 at 5:57 PM, J K wrote: > My opinion is that experimental stuff should be off by default. > > I'm using "_" now. > > I tried comma just for "fun": > > 254> c(fm2,2). > ./fm2.erl:none: no such file or directory > error > 255> compile:file(fm2,2.erl). > * 1: illegal expression > 256> compile:file('fm2,2.erl'). > {ok,'fm2,2'} > 257> > > Maybe something with the shell? Try c('fm2,2'). It's just erlang syntax. > > Johan > > > ----- Original Message ---- > From: Robert Virding > To: J K > Cc: Erlang Bugs > Sent: Sun, February 28, 2010 5:15:36 PM > Subject: Re: [erlang-bugs] module name with . > > My guess is that you are interacting with the experimental, and poorly > documented, package system which assumes things when it sees module > names with '.'. As far as I know there is no way to turn this off. > Someone else may know more about this. My only suggestion is to avoid > module names with a '.'. > > Robert > > On 28 February 2010 10:09, J K wrote: >> Hi, >> is this a bug? >> >> Erlang R13B01 (erts-5.7.2) [smp:2:2] [rq:2] [async-threads:0] >> >> Eshell V5.7.2 ?(abort with ^G) >> >> 4> c('fm2.2'). >> fm2.2.beam: Module name 'fm2.2' does not match file name 'fm2.2' >> error >> 5> >> >> i have: >> -module('fm2.2'). >> >> BR >> Johan >> >> >> >> >> >> ________________________________________________________________ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED >> >> > > > > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try GoodData now for free: www.gooddata.com From bernie@REDACTED Sun Feb 28 22:54:19 2010 From: bernie@REDACTED (Bernard Duggan) Date: Mon, 01 Mar 2010 08:54:19 +1100 Subject: [erlang-bugs] module name with . In-Reply-To: <141807.74724.qm@web113407.mail.gq1.yahoo.com> References: <373657.24739.qm@web113418.mail.gq1.yahoo.com> <3dbc6d1c1002280815r5e253336j60ab467d8b18a146@mail.gmail.com> <141807.74724.qm@web113407.mail.gq1.yahoo.com> Message-ID: <4B8AE60B.1050900@m5net.com> Actually, all these look pretty much as I'd expect: J K wrote: > I tried comma just for "fun": > > 254> c(fm2,2). > ./fm2.erl:none: no such file or directory > error > By putting a comma there you've passed two parameters to the 'c' function. While the shell docs don't seem to mention it, a quick glance at the source shows that there is indeed a c/2 where the second parameter is the compilation options. So you're trying to compile a module called 'fm2' with an option of 2 (which probably doesn't mean anything, but the missing file is the first problem that is picked up). > 255> compile:file(fm2,2.erl). > * 1: illegal expression > Here, you've put a full stop/period in the middle of an expression (prior to closing the parentheses). That's the character the ends expressions, so of course it makes it illegal. > 256> compile:file('fm2,2.erl'). > {ok,'fm2,2'} > And here, by correctly wrapping the whole term in single quotes to make it an atom, the syntax becomes correct. The compile module seems to be a little more permissive here than the docs suggest, allowing you to add '.erl' to the module name and have it still work. > Maybe something with the shell? > If by 'something with the shell' you mean 'the shell doing exactly what it should', then yeah, I'd say there is indeed 'something with the shell' ;) B