From dae@REDACTED Fri Jan 4 21:56:27 2008 From: dae@REDACTED (Doug Edmunds) Date: Fri, 04 Jan 2008 12:56:27 -0800 Subject: [erlang-bugs] Duplicate documentation in otp_win32_R12B-0.exe Message-ID: <477E9D7B.501@douglasedmunds.com> There is a substantial unnecessary duplication of docs in otp_win32_R12B-0.exe Subdir 'docs contains duplications of 2044 Files in 152 Folders consuming 15.7 MB (Size on disk 20 MB). The files in those subdirectories are duplicates of docs contained in other directories, found under c:\erlang\erts-5.6 and c:\erlang\lib The documentation system, as best I can determine does not call any files in the 'docs' directory -- Doug Edmunds From dae@REDACTED Sun Jan 6 19:40:34 2008 From: dae@REDACTED (Doug Edmunds) Date: Sun, 06 Jan 2008 10:40:34 -0800 Subject: [erlang-bugs] documentation out of date - /doc/getting_started/seq_prog.html Message-ID: <478120A2.5030406@douglasedmunds.com> Documentation should be updated to reflect this change: RE: file: [root]/doc/getting_started/seq_prog.html section: 2.11 If and Case code example: tut9.erl The output shown is for versions prior to 12B: 70> tut9:test_if(33, 33). =ERROR REPORT==== 11-Jun-2003::14:03:43 === Error in process <0.85.0> with exit value: {if_clause,[{tut9,test_if,2},{erl_eval,exprs,4},{shell,eval_loop,2}]} ** exited: {if_clause,[{tut9,test_if,2}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** The output for 12B is (I get this result): 3> tut9:test_if(33, 33). ** exception error: no true branch found when evaluating an if expression in function tut9:test_if/2 ------ ALSO! The current explanation (near beginning of 2.11 says only "If no condition matches, there will be a run time failure." Perhaps change to this: If no condition matches, there will be a run time failure. The error message is "no true branch found when evaluating an if expression". Doug Edmunds From egil@REDACTED Tue Jan 8 15:50:22 2008 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 08 Jan 2008 15:50:22 +0100 Subject: [erlang-bugs] problem compiling percept in mac os x In-Reply-To: <21ED14B1-C382-4928-87F5-84DAADFBE2D5@gmail.com> References: <21ED14B1-C382-4928-87F5-84DAADFBE2D5@gmail.com> Message-ID: <47838DAE.6050205@erix.ericsson.se> Hi Aleix, Thank you for pointing this out. It will be corrected. Sorry for my delay in answering. Regards, Bj?rn-Egil Aleix Conchillo Flaqu? wrote: > Hi, > > I'm the maintainer of the erlang fink package. I just noticed an error > while compiling the percept application: > > === Entering application percept > make -f powerpc-apple-darwin9.1.0/Makefile TYPE=opt > /usr/bin/install -c -d ../priv/lib/powerpc-apple-darwin9.1.0 > gcc /sw/lib -bundle -flat_namespace -undefined suppress -o ../priv/lib/ > powerpc-apple-darwin9.1.0/egd_drv.so ../priv/obj/powerpc-apple- > darwin9.1.0/egd_port_driver.o ../priv/obj/powerpc-apple-darwin9.1.0/ > egd_image.o ../priv/obj/powerpc-apple-darwin9.1.0/egd_coding.o -lutil - > ldl -lm -L/sw/lib -lgd > ld: in /sw/lib, can't map file, errno=22 > collect2: ld returned 1 exit status > make[4]: *** [../priv/lib/powerpc-apple-darwin9.1.0/egd_drv.so] Error 1 > make[3]: *** [opt] Error 2 > > This is caused because the DED_LD_FLAG_RUNTIME_LIBRARY_PATH variable > is set to empty in darwin, and this causes: > > $(LIBDIR)/egd_drv.so: $(EGD_DRV_OBJS) > $(INSTALL_DIR) $(LIBDIR) > $(LD) $(CC_R_OPT) $(LDFLAGS) -o $@ $^ $(LIBS) $(GD_LINK_LIB) > > to fail, because CC_R_OPT is set to > > CC_R_OPT = $(CC_R_FLAG)$(GD_LIBDIR) > > where CC_R_FLAG=@DED_LD_FLAG_RUNTIME_LIBRARY_PATH@ > > I have provided a patch for fink where CC_R_FLAG=-rpath. I guess you > could provide a better and general fix for this. > > Thanks in advance. > > Aleix > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From stupalo@REDACTED Wed Jan 9 10:55:42 2008 From: stupalo@REDACTED (=?UTF-8?B?R8O2cmFuIFN0dXBhbG8=?=) Date: Wed, 09 Jan 2008 10:55:42 +0100 Subject: [erlang-bugs] Duplicate documentation in otp_win32_R12B-0.exe In-Reply-To: <477E9D7B.501@douglasedmunds.com> References: <477E9D7B.501@douglasedmunds.com> Message-ID: <47849A1E.4020502@erix.ericsson.se> Hi Doug, Yes, you are right. The 'docs' directory isn't supposed to be part of the release. This will be fixed in R12B-1. -- Goran Stupalo, Erlang/OTP, Ericsson AB Doug Edmunds wrote: > There is a substantial unnecessary duplication of > docs in otp_win32_R12B-0.exe > > Subdir 'docs contains duplications of 2044 Files in 152 Folders > consuming 15.7 MB (Size on disk 20 MB). > > The files in those subdirectories are duplicates of > docs contained in other directories, found under > c:\erlang\erts-5.6 > and > c:\erlang\lib > > The documentation system, as best I can determine does not call > any files in the 'docs' directory > > -- Doug Edmunds > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From matthias@REDACTED Wed Jan 9 14:12:34 2008 From: matthias@REDACTED (Matthias Lang) Date: Wed, 9 Jan 2008 14:12:34 +0100 Subject: [erlang-bugs] documentation typo in gb_trees:next Message-ID: <18308.51266.633484.284421@antilipe.corelatus.se> This page: http://erlang.org/doc/man/gb_trees.html documents gb_trees:next like this: next(Iter1) -> {Key, Val, Iter2 it should probably read next(Iter1) -> {Key, Val, Iter2} | none Matthias From egil@REDACTED Wed Jan 9 15:41:17 2008 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 09 Jan 2008 15:41:17 +0100 Subject: [erlang-bugs] FreeBSD build fix [resent] In-Reply-To: <20071213102950.41df13a7@gentoo.org> References: <20071213102950.41df13a7@gentoo.org> Message-ID: <4784DD0D.4070809@erix.ericsson.se> Hi Christian, Thank you for pointing out this problem. Your fix, or something close to it, will be included in coming releases of erl_interface. Regards, Bj?rn-Egil Erlang/OTP Christian Faulhammer wrote: > * PGP Signed by an unknown key: 12/13/2007 at 10:29:50 AM > Hi, > > I sent in this patch before but there was neither a reaction nor > inclusion into 12B. So I resend it: FreeBSD above 6.2 had some > problems in Gentoo/FBSD, while the attached patch fixes this. > > V-Li > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From zl9d97p02@REDACTED Thu Jan 10 08:23:46 2008 From: zl9d97p02@REDACTED (Simon Cornish) Date: Wed, 9 Jan 2008 23:23:46 -0800 Subject: [erlang-bugs] Compiler bug in R12B Message-ID: <1430-72902@sneakemail.com> Hi, The R12B compiler (even the latest -1 snapshot) barfs at this simple Erlang program - a.erl The problem is that match context from the first clause overwrites the register holding the binary. The fault probably lies in v3_codegen:bsm_rename_ctx/2 or the annotation logic in sys_core_fold. My work around (v3_codegen.patch) was to bypass the reuse optimisation. The resulting S file from compiling a.erl with the patched v3_codegen module is also attached. One thing to note from this is that now {x,1} never contains a match context when label 4 is reached. I don't know if this is an artefact of my workaround or another bug. Fortunately, the code works because the beam emulator basically ignores this operation if the register doesn't contain a match context. Have fun fixing this. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: a.erl Type: application/octet-stream Size: 80 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v3_codegen.patch Type: application/octet-stream Size: 399 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a.S Type: application/octet-stream Size: 1005 bytes Desc: not available URL: From bjorn@REDACTED Thu Jan 10 09:09:51 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 10 Jan 2008 09:09:51 +0100 Subject: [erlang-bugs] documentation typo in gb_trees:next In-Reply-To: <18308.51266.633484.284421@antilipe.corelatus.se> References: <18308.51266.633484.284421@antilipe.corelatus.se> Message-ID: Matthias Lang writes: > This page: > > http://erlang.org/doc/man/gb_trees.html > > documents gb_trees:next like this: > > next(Iter1) -> {Key, Val, Iter2 > > it should probably read > > next(Iter1) -> {Key, Val, Iter2} | none Thanks! It will be corrected in R12B-1. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From stupalo@REDACTED Thu Jan 10 15:01:02 2008 From: stupalo@REDACTED (=?UTF-8?B?R8O2cmFuIFN0dXBhbG8=?=) Date: Thu, 10 Jan 2008 15:01:02 +0100 Subject: [erlang-bugs] documentation out of date - /doc/getting_started/seq_prog.html In-Reply-To: <478120A2.5030406@douglasedmunds.com> References: <478120A2.5030406@douglasedmunds.com> Message-ID: <4786251E.4030707@erix.ericsson.se> Hello Doug, Thank you for your mail. The documentation will be updated in R12B-1. -- G?ran Stupalo, Erlang/OTP, Ericsson AB Doug Edmunds wrote: > Documentation should be updated to reflect this change: > > RE: > file: [root]/doc/getting_started/seq_prog.html > section: 2.11 If and Case > code example: tut9.erl > > The output shown is for versions prior to 12B: > > 70> tut9:test_if(33, 33). > > =ERROR REPORT==== 11-Jun-2003::14:03:43 === > Error in process <0.85.0> with exit value: > {if_clause,[{tut9,test_if,2},{erl_eval,exprs,4},{shell,eval_loop,2}]} > ** exited: {if_clause,[{tut9,test_if,2}, > {erl_eval,exprs,4}, > {shell,eval_loop,2}]} ** > > The output for 12B is (I get this result): > > 3> tut9:test_if(33, 33). > ** exception error: no true branch found when evaluating an if expression > in function tut9:test_if/2 > > ------ > > ALSO! > > The current explanation (near beginning of 2.11 says only > "If no condition matches, there will be a run time failure." > > Perhaps change to this: > > If no condition matches, there will be a run time failure. > The error message is "no true branch found when evaluating an if > expression". > > > Doug Edmunds > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From bjorn@REDACTED Thu Jan 10 17:45:06 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 10 Jan 2008 17:45:06 +0100 Subject: [erlang-bugs] Compiler bug in R12B In-Reply-To: <1430-72902@sneakemail.com> References: <1430-72902@sneakemail.com> Message-ID: Thanks! "Simon Cornish" writes: > The R12B compiler (even the latest -1 snapshot) barfs at this simple > Erlang program - a.erl > The problem is that match context from the first clause overwrites the > register holding the binary. > The fault probably lies in v3_codegen:bsm_rename_ctx/2 or the > annotation logic in sys_core_fold. sys_core_fold. My attached patch corrects the problem. > One thing to note from this is that now {x,1} never contains a match > context when label 4 is reached. > I don't know if this is an artefact of my workaround or another bug. It is an artefact of your workaround (because it targeted v3_codegen and not sys_core_fold). > Have fun fixing this. I had. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler_otp_7094.patch Type: text/x-patch Size: 814 bytes Desc: Fix for validation failure URL: From opfer@REDACTED Fri Jan 11 12:52:12 2008 From: opfer@REDACTED (Christian Faulhammer) Date: Fri, 11 Jan 2008 12:52:12 +0100 Subject: [erlang-bugs] Build failure with --as-needed Message-ID: <20080111125212.1661c3ac@gentoo.org> Hi, 12B-0 linked with LDFLAGS="--as-needed" (Linux machine, 64-bit) fails to identify OpenSSL correctly: "checking for OpenSSL >= 0.9.7 in standard locations... found; but not usable configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh and crypto applications" This occurs with dynamic SSL (not built-in). V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikpe@REDACTED Fri Jan 11 13:42:18 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 11 Jan 2008 13:42:18 +0100 Subject: [erlang-bugs] Build failure with --as-needed In-Reply-To: <20080111125212.1661c3ac@gentoo.org> References: <20080111125212.1661c3ac@gentoo.org> Message-ID: <18311.25642.956371.890729@harpo.it.uu.se> Christian Faulhammer writes: > Hi, > > 12B-0 linked with LDFLAGS="--as-needed" (Linux machine, 64-bit) fails > to identify OpenSSL correctly: > > "checking for OpenSSL >= 0.9.7 in standard locations... found; but not > usable configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh > and crypto applications" So why do you link with --as-needed? (looks at man ld) It would seem that --as-needed only is an optimisation, and only in case the link command mentions redundant libraries, no? /Mikael From opfer@REDACTED Fri Jan 11 14:35:33 2008 From: opfer@REDACTED (Christian Faulhammer) Date: Fri, 11 Jan 2008 14:35:33 +0100 Subject: [erlang-bugs] Build failure with --as-needed In-Reply-To: <18311.25642.956371.890729@harpo.it.uu.se> References: <20080111125212.1661c3ac@gentoo.org> <18311.25642.956371.890729@harpo.it.uu.se> Message-ID: <20080111143533.141c12d6@gentoo.org> Mikael Pettersson : > Christian Faulhammer writes: > > 12B-0 linked with LDFLAGS="--as-needed" (Linux machine, 64-bit) > > fails to identify OpenSSL correctly: > > "checking for OpenSSL >= 0.9.7 in standard locations... found; but > > not usable configure: WARNING: No (usable) OpenSSL found, skipping > > ssl, ssh and crypto applications" > So why do you link with --as-needed? A user reported it. > It would seem that --as-needed only is an optimisation, and > only in case the link command mentions redundant libraries, no? More information can be found here: V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fw@REDACTED Fri Jan 11 22:43:41 2008 From: fw@REDACTED (Florian Weimer) Date: Fri, 11 Jan 2008 22:43:41 +0100 Subject: [erlang-bugs] Potential endless loop in DNS resolver Message-ID: <871w8orqb6.fsf@mid.deneb.enyo.de> It seems to me that the following code from lib/kernel/src/inet_dns.erl contains an endless loop: dn_exp([N1,N2 | T], Buffer, Name) when N1 band ?INDIR_MASK =:= ?INDIR_MASK -> Offset = ((N1 band 16#3f) bsl 8) bor N2, case catch nthtail(Offset, Buffer) of {'EXIT', _} -> error; NDn -> %% We have to keep the Tail of original Dn in order to %% prohibit ending up with the tail from an offset. case dn_exp(NDn, Buffer, Name) of {ExpName, _} -> {ExpName, T}; Res -> Res end end; A compression reference which points to itself results in dn_exp being called with the same argument over and over again. From exta7@REDACTED Sun Jan 13 01:10:26 2008 From: exta7@REDACTED (Zvi) Date: Sat, 12 Jan 2008 16:10:26 -0800 (PST) Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd Message-ID: <14780551.post@talk.nabble.com> When running inets httpd webserver and serving single static file index.html, it works, but after pressing reload button 3 times, the html page didn't served. After opening new browser instance it's also working 2 times and then hangs. From the Firefox everything works fine. The exact version of my IE is 7.0.5730.13. TIA Zvi -- View this message in context: http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14780551.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From zl9d97p02@REDACTED Sun Jan 13 09:20:59 2008 From: zl9d97p02@REDACTED (Simon Cornish) Date: Sun, 13 Jan 2008 00:20:59 -0800 Subject: [erlang-bugs] compiler bug with funs Message-ID: <12052-97267@sneakemail.com> The attached Erlang code demonstrates a bug with funs. Compile and evaluate broken_fun:die(a) or broken_fun:die({b,c}) for two different failure modes. It seems to me that the live register check for call_fun is off by one. Attached also a suggested patch. If I actually understood the compiler, I'd post this to erlang-patches, but since I don't someone else can check to see whether this is the right fix :-) Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: broken_fun.erl Type: application/octet-stream Size: 233 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: beam_utils.patch Type: application/octet-stream Size: 621 bytes Desc: not available URL: From bjorn@REDACTED Mon Jan 14 12:02:22 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 14 Jan 2008 12:02:22 +0100 Subject: [erlang-bugs] compiler bug with funs In-Reply-To: <12052-97267@sneakemail.com> References: <12052-97267@sneakemail.com> Message-ID: "Simon Cornish" writes: > It seems to me that the live register check for call_fun is off by > one. Attached also a suggested patch. If I actually understood the > compiler, I'd post this to erlang-patches, but since I don't someone > else can check to see whether this is the right fix :-) Thanks! The patch is correct. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kenneth.lundin@REDACTED Mon Jan 14 19:33:52 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 14 Jan 2008 19:33:52 +0100 Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: <14780551.post@talk.nabble.com> References: <14780551.post@talk.nabble.com> Message-ID: Hi, How do you mean that this fails, can you explain further. Why do you think this is a problem with the httpd web-server and not a problem with IE 7.0? You need to give more information if we should be able to understand what the problem really is. 1) Exactly what happend with your browser after reload 3 times 2) Contents of the file you are reloading 3) more observations I also recommend that you don't send to erlang-bugs before you have very clear indications on that there is a bug in Erlang/OTP. Before that i recommend erlang-questions. /Regards Kenneth Erlang/OTP team at Ericsson On Jan 13, 2008 1:10 AM, Zvi wrote: > > When running inets httpd webserver and serving single static file index.html, > it works, but after pressing reload button 3 times, the html page didn't > served. After opening new browser instance it's also working 2 times and > then hangs. From the Firefox everything works fine. > The exact version of my IE is 7.0.5730.13. > > TIA > Zvi > -- > View this message in context: http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14780551.html > Sent from the Erlang Bugs mailing list archive at Nabble.com. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From exta7@REDACTED Mon Jan 14 20:46:01 2008 From: exta7@REDACTED (Zvi) Date: Mon, 14 Jan 2008 11:46:01 -0800 (PST) Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: References: <14780551.post@talk.nabble.com> Message-ID: <14811163.post@talk.nabble.com> Hi Kenneth, sorry for the cryptic description :( I put simple "index.html" file in the directory specified in inets configuration. The content of the file is:

Ha ha ha!

ha hah ah Then I opened IE7 browser window and typed the URL: "http://localhost:2001/index.html". After pressing enter the webpage correctly rendered in the browser. After pressing reload first time - again it's rendered OK. When pressing "reload" button 2nd or 3rd time IE7 just stuck (like it trying to load the page indefinitely). Then I open new IE7 browser instance and there it working twice and stuck on the 3rd page reload. This doesn't happen in the Firefox. And also tried just now IE7 with Apache and the same index.html file - it doesn't happen with Apache - everything works fine. So either Apache has workarround for IE7 bugs or inets:httpd has a bug. Anyway I considered which webserver to use for my web application yaws or inets, I guess inets is more suited for embedded web applications. I didn't tried it with yaws yet. Thanks in advance, Zvi Kenneth Lundin wrote: > > Hi, > > How do you mean that this fails, can you explain further. > Why do you think this is a problem with the httpd web-server and not a > problem with IE 7.0? > > You need to give more information if we should be able to understand > what the problem > really is. > > 1) Exactly what happend with your browser after reload 3 times > 2) Contents of the file you are reloading > 3) more observations > > I also recommend that you don't send to erlang-bugs before you have > very clear indications on > that there is a bug in Erlang/OTP. Before that i recommend > erlang-questions. > > /Regards Kenneth Erlang/OTP team at Ericsson > > On Jan 13, 2008 1:10 AM, Zvi wrote: >> >> When running inets httpd webserver and serving single static file >> index.html, >> it works, but after pressing reload button 3 times, the html page didn't >> served. After opening new browser instance it's also working 2 times and >> then hangs. From the Firefox everything works fine. >> The exact version of my IE is 7.0.5730.13. >> >> TIA >> Zvi >> -- >> View this message in context: >> http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14780551.html >> Sent from the Erlang Bugs mailing list archive at Nabble.com. >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > -- View this message in context: http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14811163.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From r.kelsall@REDACTED Mon Jan 14 21:42:38 2008 From: r.kelsall@REDACTED (Richard Kelsall) Date: Mon, 14 Jan 2008 20:42:38 +0000 Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: <14811163.post@talk.nabble.com> References: <14780551.post@talk.nabble.com> <14811163.post@talk.nabble.com> Message-ID: <478BC93E.8030207@millstream.com> Zvi wrote: > Hi Kenneth, > > sorry for the cryptic description :( > I put simple "index.html" file in the directory specified in inets > configuration. The content of the file is: > > >

Ha ha ha!

>
> ha hah ah > > > Then I opened IE7 browser window and typed the URL: > "http://localhost:2001/index.html". > After pressing enter the webpage correctly rendered in the browser. > After pressing reload first time - again it's rendered OK. > When pressing "reload" button 2nd or 3rd time IE7 just stuck (like it trying > to load the page indefinitely). > > Then I open new IE7 browser instance and there it working twice and stuck on > the 3rd page reload. > This doesn't happen in the Firefox. > > And also tried just now IE7 with Apache and the same index.html file - it > doesn't happen with Apache - everything works fine. > So either Apache has workarround for IE7 bugs or inets:httpd has a bug. Maybe IE7 does not play nice in some way and Apache can cope with it but inets expects better behaviour somehow. I think we can only make progress by seeing what's happening at a lower level. The http conversation between the web server and browser might be a good place to look. For details of how http works see the RFCs http://www.faqs.org/rfcs/ maybe 2616 would be a good place to start http://www.faqs.org/rfcs/rfc2616.html (Perhaps you knew that, but maybe somebody else reading doesn't.) If you could get a trace of http requests and responses and point out the one that works followed by the one that fails that would be the kind of information that might be interesting. Hope that helps. Richard. > > Anyway I considered which webserver to use for my web application yaws or > inets, I guess inets is more suited for embedded web applications. > > I didn't tried it with yaws yet. > > Thanks in advance, > Zvi > > > > > Kenneth Lundin wrote: >> Hi, >> >> How do you mean that this fails, can you explain further. >> Why do you think this is a problem with the httpd web-server and not a >> problem with IE 7.0? >> >> You need to give more information if we should be able to understand >> what the problem >> really is. >> >> 1) Exactly what happend with your browser after reload 3 times >> 2) Contents of the file you are reloading >> 3) more observations >> >> I also recommend that you don't send to erlang-bugs before you have >> very clear indications on >> that there is a bug in Erlang/OTP. Before that i recommend >> erlang-questions. >> >> /Regards Kenneth Erlang/OTP team at Ericsson >> >> On Jan 13, 2008 1:10 AM, Zvi wrote: >>> When running inets httpd webserver and serving single static file >>> index.html, >>> it works, but after pressing reload button 3 times, the html page didn't >>> served. After opening new browser instance it's also working 2 times and >>> then hangs. From the Firefox everything works fine. >>> The exact version of my IE is 7.0.5730.13. >>> >>> TIA >>> Zvi >>> -- >>> View this message in context: >>> http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14780551.html >>> Sent from the Erlang Bugs mailing list archive at Nabble.com. >>> From bob@REDACTED Mon Jan 14 21:44:47 2008 From: bob@REDACTED (Bob Ippolito) Date: Mon, 14 Jan 2008 12:44:47 -0800 Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: <14811163.post@talk.nabble.com> References: <14780551.post@talk.nabble.com> <14811163.post@talk.nabble.com> Message-ID: <6a36e7290801141244h5d44b165g6eef25775013762a@mail.gmail.com> You could give mochiweb a shot. If you can reproduce the bug with mochiweb, we'll fix it :) mochiweb is designed for embedded apps and is easier to get up and going than the server in inets. On Jan 14, 2008 11:46 AM, Zvi wrote: > > Hi Kenneth, > > sorry for the cryptic description :( > I put simple "index.html" file in the directory specified in inets > configuration. The content of the file is: > > >

Ha ha ha!

>
> ha hah ah > > > Then I opened IE7 browser window and typed the URL: > "http://localhost:2001/index.html". > After pressing enter the webpage correctly rendered in the browser. > After pressing reload first time - again it's rendered OK. > When pressing "reload" button 2nd or 3rd time IE7 just stuck (like it trying > to load the page indefinitely). > > Then I open new IE7 browser instance and there it working twice and stuck on > the 3rd page reload. > This doesn't happen in the Firefox. > > And also tried just now IE7 with Apache and the same index.html file - it > doesn't happen with Apache - everything works fine. > So either Apache has workarround for IE7 bugs or inets:httpd has a bug. > > Anyway I considered which webserver to use for my web application yaws or > inets, I guess inets is more suited for embedded web applications. > > I didn't tried it with yaws yet. > > Thanks in advance, > Zvi > > > > > > Kenneth Lundin wrote: > > > > Hi, > > > > How do you mean that this fails, can you explain further. > > Why do you think this is a problem with the httpd web-server and not a > > problem with IE 7.0? > > > > You need to give more information if we should be able to understand > > what the problem > > really is. > > > > 1) Exactly what happend with your browser after reload 3 times > > 2) Contents of the file you are reloading > > 3) more observations > > > > I also recommend that you don't send to erlang-bugs before you have > > very clear indications on > > that there is a bug in Erlang/OTP. Before that i recommend > > erlang-questions. > > > > /Regards Kenneth Erlang/OTP team at Ericsson > > > > On Jan 13, 2008 1:10 AM, Zvi wrote: > >> > >> When running inets httpd webserver and serving single static file > >> index.html, > >> it works, but after pressing reload button 3 times, the html page didn't > >> served. After opening new browser instance it's also working 2 times and > >> then hangs. From the Firefox everything works fine. > >> The exact version of my IE is 7.0.5730.13. > >> > >> TIA > >> Zvi > >> -- > >> View this message in context: > >> http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14780551.html > >> Sent from the Erlang Bugs mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> erlang-bugs mailing list > >> erlang-bugs@REDACTED > >> http://www.erlang.org/mailman/listinfo/erlang-bugs > >> > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > -- > View this message in context: http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14811163.html > > Sent from the Erlang Bugs mailing list archive at Nabble.com. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From kenneth.lundin@REDACTED Mon Jan 14 22:26:41 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 14 Jan 2008 22:26:41 +0100 Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: <6a36e7290801141244h5d44b165g6eef25775013762a@mail.gmail.com> References: <14780551.post@talk.nabble.com> <14811163.post@talk.nabble.com> <6a36e7290801141244h5d44b165g6eef25775013762a@mail.gmail.com> Message-ID: We will of course also fix obvious bugs in the inets httpd when and if we find the bug:) If we can reproduce the bug ourselves or get traces from both input and output data we will able to understand whats going on and can fix the problem if it is on our side. /Kenneth Erlang/OTP team at Ericsson On 1/14/08, Bob Ippolito wrote: > You could give mochiweb a shot. If you can reproduce the bug with > mochiweb, we'll fix it :) > > mochiweb is designed for embedded apps and is easier to get up and > going than the server in inets. > > On Jan 14, 2008 11:46 AM, Zvi wrote: > > > > Hi Kenneth, > > > > sorry for the cryptic description :( > > I put simple "index.html" file in the directory specified in inets > > configuration. The content of the file is: > > > > > >

Ha ha ha!

> >
> > ha hah ah > > > > > > Then I opened IE7 browser window and typed the URL: > > "http://localhost:2001/index.html". > > After pressing enter the webpage correctly rendered in the browser. > > After pressing reload first time - again it's rendered OK. > > When pressing "reload" button 2nd or 3rd time IE7 just stuck (like it trying > > to load the page indefinitely). > > > > Then I open new IE7 browser instance and there it working twice and stuck on > > the 3rd page reload. > > This doesn't happen in the Firefox. > > > > And also tried just now IE7 with Apache and the same index.html file - it > > doesn't happen with Apache - everything works fine. > > So either Apache has workarround for IE7 bugs or inets:httpd has a bug. > > > > Anyway I considered which webserver to use for my web application yaws or > > inets, I guess inets is more suited for embedded web applications. > > > > I didn't tried it with yaws yet. > > > > Thanks in advance, > > Zvi > > > > > > > > > > > > Kenneth Lundin wrote: > > > > > > Hi, > > > > > > How do you mean that this fails, can you explain further. > > > Why do you think this is a problem with the httpd web-server and not a > > > problem with IE 7.0? > > > > > > You need to give more information if we should be able to understand > > > what the problem > > > really is. > > > > > > 1) Exactly what happend with your browser after reload 3 times > > > 2) Contents of the file you are reloading > > > 3) more observations > > > > > > I also recommend that you don't send to erlang-bugs before you have > > > very clear indications on > > > that there is a bug in Erlang/OTP. Before that i recommend > > > erlang-questions. > > > > > > /Regards Kenneth Erlang/OTP team at Ericsson > > > > > > On Jan 13, 2008 1:10 AM, Zvi wrote: > > >> > > >> When running inets httpd webserver and serving single static file > > >> index.html, > > >> it works, but after pressing reload button 3 times, the html page didn't > > >> served. After opening new browser instance it's also working 2 times and > > >> then hangs. From the Firefox everything works fine. > > >> The exact version of my IE is 7.0.5730.13. > > >> > > >> TIA > > >> Zvi > > >> -- > > >> View this message in context: > > >> http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14780551.html > > >> Sent from the Erlang Bugs mailing list archive at Nabble.com. > > >> > > >> _______________________________________________ > > >> erlang-bugs mailing list > > >> erlang-bugs@REDACTED > > >> http://www.erlang.org/mailman/listinfo/erlang-bugs > > >> > > > _______________________________________________ > > > erlang-bugs mailing list > > > erlang-bugs@REDACTED > > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > > > > > > > > -- > > View this message in context: http://www.nabble.com/bug%3A-http-get-request-from-IE7-hangs-up-on-inets-httpd-tp14780551p14811163.html > > > > Sent from the Erlang Bugs mailing list archive at Nabble.com. > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From ingela@REDACTED Tue Jan 15 09:25:34 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 15 Jan 2008 09:25:34 +0100 Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: <6a36e7290801141244h5d44b165g6eef25775013762a@mail.gmail.com> References: <14780551.post@talk.nabble.com> <14811163.post@talk.nabble.com> <6a36e7290801141244h5d44b165g6eef25775013762a@mail.gmail.com> Message-ID: <478C6DFE.8030503@erix.ericsson.se> Hi! In Inets user's guide you can see options that you can use to enable trace on the inets HTTP server. This could help in finding out what is the problem. http://www.erlang.org/doc/apps/inets/part_frame.html Bob Ippolito wrote: > [...] > mochiweb is designed for embedded apps and is easier to get up and > going than the server in inets. > > I just want to point out that as of Erlang/OTP-R12 the inets web server is a lot easier to get up and going and a lot of inflexibilities from older versions of inets HTTP server has been removed and more default values have been added. For instance it is not necessary to have a config-file if you do not want to, you can start it directly using a list of proerties. Regards Ingela - OTP team > On Jan 14, 2008 11:46 AM, Zvi wrote: > >> Hi Kenneth, >> >> sorry for the cryptic description :( >> I put simple "index.html" file in the directory specified in inets >> configuration. The content of the file is: >> >> >>

Ha ha ha!

>>
>> ha hah ah >> >> >> Then I opened IE7 browser window and typed the URL: >> "http://localhost:2001/index.html". >> After pressing enter the webpage correctly rendered in the browser. >> After pressing reload first time - again it's rendered OK. >> When pressing "reload" button 2nd or 3rd time IE7 just stuck (like it trying >> to load the page indefinitely). >> >> Then I open new IE7 browser instance and there it working twice and stuck on >> the 3rd page reload. >> This doesn't happen in the Firefox. >> >> And also tried just now IE7 with Apache and the same index.html file - it >> doesn't happen with Apache - everything works fine. >> So either Apache has workarround for IE7 bugs or inets:httpd has a bug. >> >> Anyway I considered which webserver to use for my web application yaws or >> inets, I guess inets is more suited for embedded web applications. >> >> I didn't tried it with yaws yet. >> >> Thanks in advance, >> Zvi >> >> >> >> >> >> Kenneth Lundin wrote: >> >>> Hi, >>> >>> How do you mean that this fails, can you explain further. >>> Why do you think this is a problem with the httpd web-server and not a >>> problem with IE 7.0? >>> >>> You need to give more information if we should be able to understand >>> what the problem >>> really is. >>> >>> 1) Exactly what happend with your browser after reload 3 times >>> 2) Contents of the file you are reloading >>> 3) more observations >>> >>> I also recommend that you don't send to erlang-bugs before you have >>> very clear indications on >>> that there is a bug in Erlang/OTP. Before that i recommend >>> erlang-questions. >>> >>> /Regards Kenneth Erlang/OTP team at Ericsson >>> >>> On Jan 13, 2008 1:10 AM, Zvi wrote: >>> >>>> When running inets httpd webserver and serving single static file >>>> index.html, >>>> it works, but after pressing reload button 3 times, the html page didn't >>>> served. After opening new browser instance it's also working 2 times and >>>> then hangs. From the Firefox everything works fine. >>>> The exact version of my IE is 7.0.5730.13. >>>> >>>> TIA >>>> Zvi >>>> >>> > From opfer@REDACTED Tue Jan 15 10:04:17 2008 From: opfer@REDACTED (Christian Faulhammer) Date: Tue, 15 Jan 2008 10:04:17 +0100 Subject: [erlang-bugs] Implicit declaration Message-ID: <20080115100417.46db49a6@gentoo.org> Hi, Erlang has a lot of compiler warnings when compiled from source. These should be fixed (mostly this can be done by include statements of the needed header file), as they can have impact on hardened systems. * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * rx.c:43: warning: implicit declaration of function `malloc' rx.c:65: warning: implicit declaration of function `free' rxanal.c:54: warning: implicit declaration of function `malloc' rxanal.c:56: warning: implicit declaration of function `realloc' rxanal.c:344: warning: implicit declaration of function `rx_refresh_this_superst ate' rxbasic.c:87: warning: implicit declaration of function `malloc' rxbasic.c:115: warning: implicit declaration of function `free' rxbitset.c:105: warning: implicit declaration of function `rx_bzero' rxcset.c:40: warning: implicit declaration of function `malloc' rxcset.c:77: warning: implicit declaration of function `free' rxdbug.c:64: warning: implicit declaration of function `isprint' rxgnucomp.c:53: warning: implicit declaration of function `rx_bzero' rxgnucomp.c:630: warning: implicit declaration of function `malloc' rxgnucomp.c:962: warning: implicit declaration of function `strncmp' rxgnucomp.c:965: warning: implicit declaration of function `sscanf' rxgnucomp.c:999: warning: implicit declaration of function `strcmp' rxgnucomp.c:1026: warning: implicit declaration of function `isalnum' rxgnucomp.c:1027: warning: implicit declaration of function `isalpha' rxgnucomp.c:1029: warning: implicit declaration of function `iscntrl' rxgnucomp.c:1030: warning: implicit declaration of function `isdigit' rxgnucomp.c:1031: warning: implicit declaration of function `isgraph' rxgnucomp.c:1032: warning: implicit declaration of function `islower' rxgnucomp.c:1033: warning: implicit declaration of function `isprint' rxgnucomp.c:1034: warning: implicit declaration of function `ispunct' rxgnucomp.c:1035: warning: implicit declaration of function `isspace' rxgnucomp.c:1036: warning: implicit declaration of function `isupper' rxgnucomp.c:1037: warning: implicit declaration of function `isxdigit' rxgnucomp.c:1175: warning: implicit declaration of function `realloc' rxgnucomp.c:1648: warning: implicit declaration of function `free' rxhash.c:39: warning: implicit declaration of function `malloc' rxhash.c:75: warning: implicit declaration of function `free' rxhash.c:252: warning: implicit declaration of function `rx_bzero' rxnfa.c:46: warning: implicit declaration of function `malloc' rxnfa.c:49: warning: implicit declaration of function `rx_bzero' rxnfa.c:65: warning: implicit declaration of function `free' rxnode.c:43: warning: implicit declaration of function `malloc' rxnode.c:64: warning: implicit declaration of function `free' rxnode.c:86: warning: implicit declaration of function `realloc' rxnode.c:125: warning: implicit declaration of function `memcpy' rxnode.c:145: warning: implicit declaration of function `memcmp' rxnode.c:195: warning: implicit declaration of function `rx_bzero' rxposix.c:66: warning: implicit declaration of function `rx_bzero' rxposix.c:77: warning: implicit declaration of function `malloc' rxposix.c:83: warning: implicit declaration of function `isupper' rxposix.c:83: warning: implicit declaration of function `tolower' rxposix.c:147: warning: implicit declaration of function `strlen' rxposix.c:178: warning: implicit declaration of function `strncpy' rxposix.c:182: warning: implicit declaration of function `strcpy' rxposix.c:431: warning: implicit declaration of function `free' rxsimp.c:81: warning: implicit declaration of function `isdigit' rxspencer.c:64: warning: implicit declaration of function `malloc' rxspencer.c:67: warning: implicit declaration of function `rx_bzero' rxspencer.c:145: warning: implicit declaration of function `free' rxstr.c:84: warning: implicit declaration of function `strncasecmp' rxstr.c:88: warning: implicit declaration of function `strncmp' rxsuper.c:141: warning: implicit declaration of function `malloc' rxsuper.c:159: warning: implicit declaration of function `free' rxsuper.c:715: warning: implicit declaration of function `rx_bzero' rxunfa.c:67: warning: implicit declaration of function `malloc' rxunfa.c:106: warning: implicit declaration of function `free' rx.c:43: warning: implicit declaration of function `malloc' rx.c:65: warning: implicit declaration of function `free' rxanal.c:54: warning: implicit declaration of function `malloc' rxanal.c:56: warning: implicit declaration of function `realloc' rxanal.c:344: warning: implicit declaration of function `rx_refresh_this_superst ate' rxbasic.c:87: warning: implicit declaration of function `malloc' rxbasic.c:115: warning: implicit declaration of function `free' rxbitset.c:105: warning: implicit declaration of function `rx_bzero' rxcset.c:40: warning: implicit declaration of function `malloc' rxcset.c:77: warning: implicit declaration of function `free' rxdbug.c:64: warning: implicit declaration of function `isprint' rxgnucomp.c:53: warning: implicit declaration of function `rx_bzero' rxgnucomp.c:630: warning: implicit declaration of function `malloc' rxgnucomp.c:962: warning: implicit declaration of function `strncmp' rxgnucomp.c:965: warning: implicit declaration of function `sscanf' rxgnucomp.c:999: warning: implicit declaration of function `strcmp' rxgnucomp.c:1026: warning: implicit declaration of function `isalnum' rxgnucomp.c:1027: warning: implicit declaration of function `isalpha' rxgnucomp.c:1029: warning: implicit declaration of function `iscntrl' rxgnucomp.c:1030: warning: implicit declaration of function `isdigit' rxgnucomp.c:1031: warning: implicit declaration of function `isgraph' rxgnucomp.c:1032: warning: implicit declaration of function `islower' rxgnucomp.c:1033: warning: implicit declaration of function `isprint' rxgnucomp.c:1034: warning: implicit declaration of function `ispunct' rxgnucomp.c:1035: warning: implicit declaration of function `isspace' rxgnucomp.c:1036: warning: implicit declaration of function `isupper' rxgnucomp.c:1037: warning: implicit declaration of function `isxdigit' rxgnucomp.c:1175: warning: implicit declaration of function `realloc' rxgnucomp.c:1648: warning: implicit declaration of function `free' rxhash.c:39: warning: implicit declaration of function `malloc' rxhash.c:75: warning: implicit declaration of function `free' rxhash.c:252: warning: implicit declaration of function `rx_bzero' rxnfa.c:46: warning: implicit declaration of function `malloc' rxnfa.c:49: warning: implicit declaration of function `rx_bzero' rxnfa.c:65: warning: implicit declaration of function `free' rxnode.c:43: warning: implicit declaration of function `malloc' rxnode.c:64: warning: implicit declaration of function `free' rxnode.c:86: warning: implicit declaration of function `realloc' rxnode.c:125: warning: implicit declaration of function `memcpy' rxnode.c:145: warning: implicit declaration of function `memcmp' rxnode.c:195: warning: implicit declaration of function `rx_bzero' rxposix.c:66: warning: implicit declaration of function `rx_bzero' rxposix.c:77: warning: implicit declaration of function `malloc' rxposix.c:83: warning: implicit declaration of function `isupper' rxposix.c:83: warning: implicit declaration of function `tolower' rxposix.c:147: warning: implicit declaration of function `strlen' rxposix.c:178: warning: implicit declaration of function `strncpy' rxposix.c:182: warning: implicit declaration of function `strcpy' rxposix.c:431: warning: implicit declaration of function `free' rxsimp.c:81: warning: implicit declaration of function `isdigit' rxspencer.c:64: warning: implicit declaration of function `malloc' rxspencer.c:67: warning: implicit declaration of function `rx_bzero' rxspencer.c:145: warning: implicit declaration of function `free' rxstr.c:84: warning: implicit declaration of function `strncasecmp' rxstr.c:88: warning: implicit declaration of function `strncmp' rxsuper.c:141: warning: implicit declaration of function `malloc' rxsuper.c:159: warning: implicit declaration of function `free' rxsuper.c:715: warning: implicit declaration of function `rx_bzero' rxunfa.c:67: warning: implicit declaration of function `malloc' rxunfa.c:106: warning: implicit declaration of function `free' V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bob@REDACTED Tue Jan 15 11:21:43 2008 From: bob@REDACTED (Bob Ippolito) Date: Tue, 15 Jan 2008 02:21:43 -0800 Subject: [erlang-bugs] bug: http get request from IE7 hangs up on inets httpd In-Reply-To: <478C6DFE.8030503@erix.ericsson.se> References: <14780551.post@talk.nabble.com> <14811163.post@talk.nabble.com> <6a36e7290801141244h5d44b165g6eef25775013762a@mail.gmail.com> <478C6DFE.8030503@erix.ericsson.se> Message-ID: <6a36e7290801150221s23b55402q63b463ca6497a1cb@mail.gmail.com> Would've been nice to have that a long time ago! :) It was much easier to write our own than to try and fix inets. On Jan 15, 2008 12:25 AM, Ingela Anderton Andin wrote: > Hi! > > In Inets user's guide you can see options that you can use to enable > trace on the > inets HTTP server. This could help in finding out what is the problem. > > http://www.erlang.org/doc/apps/inets/part_frame.html > > Bob Ippolito wrote: > > [...] > > mochiweb is designed for embedded apps and is easier to get up and > > going than the server in inets. > > > > > I just want to point out that as of Erlang/OTP-R12 the inets web server > is a lot > easier to get up and going and a lot of inflexibilities from older > versions of inets HTTP server has been > removed and more default values have been added. For instance it is not > necessary to have a config-file if > you do not want to, you can start it directly using a list of proerties. > > Regards Ingela - OTP team > > > On Jan 14, 2008 11:46 AM, Zvi wrote: > > > >> Hi Kenneth, > >> > >> sorry for the cryptic description :( > >> I put simple "index.html" file in the directory specified in inets > >> configuration. The content of the file is: > >> > >> > >>

Ha ha ha!

> >>
> >> ha hah ah > >> > >> > >> Then I opened IE7 browser window and typed the URL: > >> "http://localhost:2001/index.html". > >> After pressing enter the webpage correctly rendered in the browser. > >> After pressing reload first time - again it's rendered OK. > >> When pressing "reload" button 2nd or 3rd time IE7 just stuck (like it trying > >> to load the page indefinitely). > >> > >> Then I open new IE7 browser instance and there it working twice and stuck on > >> the 3rd page reload. > >> This doesn't happen in the Firefox. > >> > >> And also tried just now IE7 with Apache and the same index.html file - it > >> doesn't happen with Apache - everything works fine. > >> So either Apache has workarround for IE7 bugs or inets:httpd has a bug. > >> > >> Anyway I considered which webserver to use for my web application yaws or > >> inets, I guess inets is more suited for embedded web applications. > >> > >> I didn't tried it with yaws yet. > >> > >> Thanks in advance, > >> Zvi > >> > >> > >> > >> > >> > >> Kenneth Lundin wrote: > >> > >>> Hi, > >>> > >>> How do you mean that this fails, can you explain further. > >>> Why do you think this is a problem with the httpd web-server and not a > >>> problem with IE 7.0? > >>> > >>> You need to give more information if we should be able to understand > >>> what the problem > >>> really is. > >>> > >>> 1) Exactly what happend with your browser after reload 3 times > >>> 2) Contents of the file you are reloading > >>> 3) more observations > >>> > >>> I also recommend that you don't send to erlang-bugs before you have > >>> very clear indications on > >>> that there is a bug in Erlang/OTP. Before that i recommend > >>> erlang-questions. > >>> > >>> /Regards Kenneth Erlang/OTP team at Ericsson > >>> > >>> On Jan 13, 2008 1:10 AM, Zvi wrote: > >>> > >>>> When running inets httpd webserver and serving single static file > >>>> index.html, > >>>> it works, but after pressing reload button 3 times, the html page didn't > >>>> served. After opening new browser instance it's also working 2 times and > >>>> then hangs. From the Firefox everything works fine. > >>>> The exact version of my IE is 7.0.5730.13. > >>>> > >>>> TIA > >>>> Zvi > >>>> > >>> > > > > From yu_c@REDACTED Tue Jan 15 11:53:29 2008 From: yu_c@REDACTED (Chih - Wei Yu [ MTN - Innovation Centre ]) Date: Tue, 15 Jan 2008 12:53:29 +0200 Subject: [erlang-bugs] R12B-0 Compiler issues In-Reply-To: Message-ID: Hi, I'm having some issues when compiling code in R12B-0. Its reporting internal consistency check failed. I can compile the code in R11B-5. I've provided the code that is reporting the error when compiling. I did see other 'similar' issues raised but would like to raise it again. Thanks. [Code] encode_octet_string( <>, Len ) -> <>; % The compiler reports an error for this line of code encode_octet_string( [H|T], Len ) -> B = list_to_binary( [H|T] ), << B:Len/binary-unit:8>> % However, for this line of code it does not report an error. ; encode_octet_string( _ANY, _ ) -> <<>>. [compiler error] (test@REDACTED)8> c("../../../../projects/src/smpp_types"). smpp_types: function encode_octet_string/2+9: Internal consistency check failed - please report this bug. Instruction: {bs_put_binary,{f,0}, {x,1}, 8, {field_flags,[unsigned,big]}, {x,0}} Error: {match_context,{x,0}}: ------------------------------------------------------------------------ ------------------------------------------------------------- Another piece of code [Code] <> = R7, <> = R8, {C, <<_R10/binary>>} = if A > 0 -> decode_octet_string( A, R9 ); true -> <<_NIL:8, R9x/binary>> = R9, % The compiler reports an error for this line of code {[], <>} end, [Compiler error] Internal consistency check failed - please report this bug. Instruction: {bs_append,{f,0}, {integer,0}, 0,5,8, {x,3}, {field_flags,[]}, {x,5}} Error: {match_context,{x,3}}: Regards, Chih-Wei Yu NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/default.aspx?pid=34411 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Jan 15 16:25:15 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 15 Jan 2008 16:25:15 +0100 Subject: [erlang-bugs] R12B-0 Compiler issues In-Reply-To: References: Message-ID: "Chih - Wei Yu [ MTN - Innovation Centre ]" writes: > I've provided the code that is reporting the error when compiling. I did > see other 'similar' issues raised but would like to raise it again. > [Code] > > encode_octet_string( <>, Len ) -> > <>; % The compiler reports an error for > this line of code > > encode_octet_string( [H|T], Len ) > > -> > > B = list_to_binary( [H|T] ), > > << B:Len/binary-unit:8>> > % However, for this line of code it does not report an error. > > ; > > encode_octet_string( _ANY, _ ) -> <<>>. > Thanks for the new test case. Bjorn's law - "If it isn't tested, it doesn't work" - has again been proved. :-) Your other code example is not complete, so I haven't verified, but it seems to be the same bug that I have already fixed. The attached patch should fix all found bugs in beam_bsm.erl. It should be applied to the unchanged beam_bsm.erl in R12B-0. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- A non-text attachment was scrubbed... Name: t2 Type: application/octet-stream Size: 2163 bytes Desc: Cumulative patch for beam_bsm.erl URL: From yu_c@REDACTED Wed Jan 16 09:28:59 2008 From: yu_c@REDACTED (Chih - Wei Yu [ MTN - Innovation Centre ]) Date: Wed, 16 Jan 2008 10:28:59 +0200 Subject: [erlang-bugs] R12B-0 Compiler issues In-Reply-To: Message-ID: Hi Bjorn, Thank you for your response, I'll try the patch and see I can recompile the modules. Regards, Chih-Wei Yu -----Original Message----- From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] On Behalf Of Bjorn Gustavsson Sent: Tuesday, January 15, 2008 5:25 PM To: erlang-bugs@REDACTED; erlang-questions@REDACTED Subject: Re: [erlang-bugs] R12B-0 Compiler issues "Chih - Wei Yu [ MTN - Innovation Centre ]" writes: > I've provided the code that is reporting the error when compiling. I did > see other 'similar' issues raised but would like to raise it again. > [Code] > > encode_octet_string( <>, Len ) -> > <>; % The compiler reports an error for > this line of code > > encode_octet_string( [H|T], Len ) > > -> > > B = list_to_binary( [H|T] ), > > << B:Len/binary-unit:8>> > % However, for this line of code it does not report an error. > > ; > > encode_octet_string( _ANY, _ ) -> <<>>. > Thanks for the new test case. Bjorn's law - "If it isn't tested, it doesn't work" - has again been proved. :-) Your other code example is not complete, so I haven't verified, but it seems to be the same bug that I have already fixed. The attached patch should fix all found bugs in beam_bsm.erl. It should be applied to the unchanged beam_bsm.erl in R12B-0. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/default.aspx?pid=34411 From raimo+erlang-bugs@REDACTED Wed Jan 16 09:47:01 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Wed, 16 Jan 2008 09:47:01 +0100 Subject: [erlang-bugs] Potential endless loop in DNS resolver In-Reply-To: <871w8orqb6.fsf@mid.deneb.enyo.de> References: <871w8orqb6.fsf@mid.deneb.enyo.de> Message-ID: <20080116084701.GC32100@erix.ericsson.se> Thank you for your bug report. We will have a look at it, and you seem to have thought this one through. It is probably a real problem. The DNS resolver is a bit low priority for us - it is mostly used by customers with control over their DNS configuration, so for them it is a ignorable real problem. Then we will see what to do about it... On Fri, Jan 11, 2008 at 10:43:41PM +0100, Florian Weimer wrote: > It seems to me that the following code from lib/kernel/src/inet_dns.erl > contains an endless loop: > > dn_exp([N1,N2 | T], Buffer, Name) when N1 band ?INDIR_MASK =:= ?INDIR_MASK -> > Offset = ((N1 band 16#3f) bsl 8) bor N2, > case catch nthtail(Offset, Buffer) of > {'EXIT', _} -> error; > NDn -> > %% We have to keep the Tail of original Dn in order to > %% prohibit ending up with the tail from an offset. > case dn_exp(NDn, Buffer, Name) of > {ExpName, _} -> {ExpName, T}; > Res -> Res > end > end; > > A compression reference which points to itself results in dn_exp being > called with the same argument over and over again. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dougedmunds@REDACTED Thu Jan 17 23:57:05 2008 From: dougedmunds@REDACTED (Doug Edmunds) Date: Thu, 17 Jan 2008 14:57:05 -0800 Subject: [erlang-bugs] external term format documentation Message-ID: I am considering how the output of term_to_binary/1 could be read in another programming language. I ran across this issue. In http://erlang.org/doc/apps/erts/erl_ext_dist.html, Section 8.4 Float_Ext states: "This term is used in minor version 0 of the external format; it has been superseded by NEW_FLOAT_EXT ." Apparently it has not been superseded. ( R12B, Windows XP) > term_to_binary(1.0) . produces this binary: <<131,99,49,46,48,48,48,48,48,48,48,48,48,48,48,48,48,48, 48,48,48,48,48,48,101,43,48,48,48,...>> The second byte is 99, followed by 31 bytes. This is the byte code for Float_ext (Float string) (See Section 8.4) Is New_Float_Ext still pending? When will it be implemented? -- Doug Edmunds -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Fri Jan 18 09:58:19 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Jan 2008 09:58:19 +0100 Subject: [erlang-bugs] external term format documentation In-Reply-To: References: Message-ID: "Doug Edmunds" writes: > > Is New_Float_Ext still pending? > When will it be implemented? It has been implemented, but it is not default: 1> term_to_binary(1.0, [{minor_version,1}]). <<131,70,63,240,0,0,0,0,0,0>> It will become default in a future release. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From john.hughes@REDACTED Fri Jan 18 11:48:11 2008 From: john.hughes@REDACTED (John Hughes) Date: Fri, 18 Jan 2008 11:48:11 +0100 Subject: [erlang-bugs] binary_to_term--are these bugs? Message-ID: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> I've found some behaviour that I didn't expect in binary_to_term in R12B. I'm testing the QuickCheck property prop_binary_to_term() -> ?FORALL(Bin,binary(), case catch binary_to_term(Bin) of {'EXIT',{badarg,_}} -> true; Term -> Bins = term_to_binaries(Term), ?WHENFAIL(io:format("~p~n~p~n",[Term,Bins]), lists:any(fun(Bin2)->Bin=:=Bin2 end,Bins)) end). term_to_binaries(T) -> lists:usort([term_to_binary(T,[{compressed,Level},{minor_version,Ver}]) || Level <- lists:seq(0,9), Ver <- [0,1]]). binary() -> ?LET(L,list(choose(0,255)), list_to_binary(L)). The property says that any binary that binary_to_term successfully decodes, must be an encoding of that term using some compression level and minor version (the encoding options mentioned in the documentation). But it fails, on, for example: <<131,97,0,0>> 0 [<<131,97,0>>] Or <<131,106,0>> [] [<<131,106>>] Or <<131,106,191,1,69,44,184,180,64>> [] [<<131,106>>] Or <<131,67,0>> '_' [<<131,100,0,1,95>>] where the output in each case is the binary, the term it decodes to, and the list of all possible encodings produced by term_to_binary. Is this a bug? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Fri Jan 18 12:22:21 2008 From: matthias@REDACTED (Matthias Lang) Date: Fri, 18 Jan 2008 12:22:21 +0100 Subject: [erlang-bugs] binary_to_term--are these bugs? In-Reply-To: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> References: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> Message-ID: <18320.35821.813706.981925@antilipe.corelatus.se> Most of your examples seem to say that appending extra data to the end of something which was produced by term_to_binary() doesn't upset binary_to_term(). That came up on the mailing list recently: http://www.erlang.org/pipermail/erlang-bugs/2007-November/000507.html The last example is different, i.e. > <<131,67,0>> > '_' > [<<131,100,0,1,95>>] 67 is an ERL_CACHED_ATOM whereas 100 is an ERL_ATOM_EXT, which are two different ways of representing the same thing, though the former has some undesirable properties (tm), which is probably why term_to_binary() won't generate it for you. Matthias ====================================================================== John Hughes writes: > I've found some behaviour that I didn't expect in binary_to_term in R12B. > I'm testing the QuickCheck property > > > > prop_binary_to_term() -> > > ?FORALL(Bin,binary(), > > case catch binary_to_term(Bin) of > > {'EXIT',{badarg,_}} -> > > true; > > Term -> > > Bins = term_to_binaries(Term), > > ?WHENFAIL(io:format("~p~n~p~n",[Term,Bins]), > > lists:any(fun(Bin2)->Bin=:=Bin2 > end,Bins)) > > end). > > > > term_to_binaries(T) -> > > lists:usort([term_to_binary(T,[{compressed,Level},{minor_version,Ver}]) > > || Level <- lists:seq(0,9), > > Ver <- [0,1]]). > > > > binary() -> > > ?LET(L,list(choose(0,255)), > > list_to_binary(L)). > > > > The property says that any binary that binary_to_term successfully decodes, > must be an encoding of that term using some compression level and minor > version (the encoding options mentioned in the documentation). But it fails, > on, for example: > > > > <<131,97,0,0>> > > 0 > > [<<131,97,0>>] > > > > Or > > > > <<131,106,0>> > > [] > > [<<131,106>>] > > > > Or > > > > <<131,106,191,1,69,44,184,180,64>> > > [] > > [<<131,106>>] > > > > Or > > > > <<131,67,0>> > > '_' > > [<<131,100,0,1,95>>] > > > > where the output in each case is the binary, the term it decodes to, and the > list of all possible encodings produced by term_to_binary. > > > > Is this a bug? > > > > John From bjorn@REDACTED Fri Jan 18 12:28:49 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Jan 2008 12:28:49 +0100 Subject: [erlang-bugs] binary_to_term--are these bugs? In-Reply-To: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> References: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> Message-ID: "John Hughes" writes: > I've found some behaviour that I didn't expect in binary_to_term in R12B. binary_to_term/1 ignores trailing garbage. We tried to change that a long time ago (around R3B-R4B), but found that too much code depended on that property. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mogorman@REDACTED Sat Jan 19 01:30:38 2008 From: mogorman@REDACTED (Matthew O'Gorman) Date: Fri, 18 Jan 2008 18:30:38 -0600 Subject: [erlang-bugs] erlang r12b fails to build on newer linux kernels Message-ID: In newer versions of the linux kernel they changed the word adaption to adaptation for sctp related things here is a patch that fixes it for newer kernels however it would break older kernels it probably needs proper ifdefing. Mog -------------- next part -------------- A non-text attachment was scrubbed... Name: inet_drv_sctp.patch Type: text/x-diff Size: 5803 bytes Desc: not available URL: From exta7@REDACTED Sat Jan 19 21:16:48 2008 From: exta7@REDACTED (Zvi) Date: Sat, 19 Jan 2008 12:16:48 -0800 (PST) Subject: [erlang-bugs] binary_to_term--are these bugs? In-Reply-To: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> References: <057201c859bf$a5326cb0$ef974610$@hughes@quviq.com> Message-ID: <14974713.post@talk.nabble.com> Hi John, can you please tell where these macros defines? ?FORALL ?WHENFAIL ?LET TIA, Zvi John Hughes-7 wrote: > > I've found some behaviour that I didn't expect in binary_to_term in R12B. > I'm testing the QuickCheck property > > > > prop_binary_to_term() -> > > ?FORALL(Bin,binary(), > > case catch binary_to_term(Bin) of > > {'EXIT',{badarg,_}} -> > > true; > > Term -> > > Bins = term_to_binaries(Term), > > ?WHENFAIL(io:format("~p~n~p~n",[Term,Bins]), > > lists:any(fun(Bin2)->Bin=:=Bin2 > end,Bins)) > > end). > > > > term_to_binaries(T) -> > > > lists:usort([term_to_binary(T,[{compressed,Level},{minor_version,Ver}]) > > || Level <- lists:seq(0,9), > > Ver <- [0,1]]). > > > > binary() -> > > ?LET(L,list(choose(0,255)), > > list_to_binary(L)). > > > > The property says that any binary that binary_to_term successfully > decodes, > must be an encoding of that term using some compression level and minor > version (the encoding options mentioned in the documentation). But it > fails, > on, for example: > > > > <<131,97,0,0>> > > 0 > > [<<131,97,0>>] > > > > Or > > > > <<131,106,0>> > > [] > > [<<131,106>>] > > > > Or > > > > <<131,106,191,1,69,44,184,180,64>> > > [] > > [<<131,106>>] > > > > Or > > > > <<131,67,0>> > > '_' > > [<<131,100,0,1,95>>] > > > > where the output in each case is the binary, the term it decodes to, and > the > list of all possible encodings produced by term_to_binary. > > > > Is this a bug? > > > > John > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -- View this message in context: http://www.nabble.com/binary_to_term--are-these-bugs--tp14950900p14974713.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From john.hughes@REDACTED Sun Jan 20 16:55:56 2008 From: john.hughes@REDACTED (John Hughes) Date: Sun, 20 Jan 2008 16:55:56 +0100 Subject: [erlang-bugs] binary_to_term--are these bugs? In-Reply-To: References: Message-ID: <019901c85b7c$f366c4d0$da344e70$@hughes@quviq.com> Hi Zvi, I guess I should have explained them. They're part of QuickCheck, our testing tool, not Erlang/OTP. - ?FORALL(Bin,binary(),...) binds Bin to a randomly generated binary within the rest of the property. - ?WHENFAIL(io:format(...),...) tells QuickCheck to run the io:format only when reporting a failed test case. - ?LET(L,list(...),...) is used to define the binary test data generator: it binds L to a random list of bytes, which is then converted to a binary. QuickCheck then generates and runs tests, and when a test fails, simplifies it to a minimal failing example. The values you see printed are the value of Bin (printed by ?FORALL), and the values of Term and Bins (printed by ?WHENFAIL). I ran a few thousand tests to find these examples. There's more information about QuickCheck at www.quviq.com. By the way, if you're still running R11B then try this one for fun: binary_to_term(<<131,105,165,0,0,0>>). (It's fixed in R12B). This one took some tens of thousands of tests, and a bit more work on my part, to find and simplify. John ---------------------------------------------------------------------- Date: Sat, 19 Jan 2008 12:16:48 -0800 (PST) From: Zvi Subject: Re: [erlang-bugs] binary_to_term--are these bugs? To: erlang-bugs@REDACTED Message-ID: <14974713.post@REDACTED> Content-Type: text/plain; charset=us-ascii Hi John, can you please tell where these macros defines? ?FORALL ?WHENFAIL ?LET TIA, Zvi John Hughes-7 wrote: > > I've found some behaviour that I didn't expect in binary_to_term in R12B. > I'm testing the QuickCheck property > > > > prop_binary_to_term() -> > > ?FORALL(Bin,binary(), > > case catch binary_to_term(Bin) of > > {'EXIT',{badarg,_}} -> > > true; > > Term -> > > Bins = term_to_binaries(Term), > > ?WHENFAIL(io:format("~p~n~p~n",[Term,Bins]), > > lists:any(fun(Bin2)->Bin=:=Bin2 > end,Bins)) > > end). > > > > term_to_binaries(T) -> > > > lists:usort([term_to_binary(T,[{compressed,Level},{minor_version,Ver}]) > > || Level <- lists:seq(0,9), > > Ver <- [0,1]]). > > > > binary() -> > > ?LET(L,list(choose(0,255)), > > list_to_binary(L)). > > > > The property says that any binary that binary_to_term successfully > decodes, > must be an encoding of that term using some compression level and minor > version (the encoding options mentioned in the documentation). But it > fails, > on, for example: > > > > <<131,97,0,0>> > > 0 > > [<<131,97,0>>] > > > > Or > > > > <<131,106,0>> > > [] > > [<<131,106>>] > > > > Or > > > > <<131,106,191,1,69,44,184,180,64>> > > [] > > [<<131,106>>] > > > > Or > > > > <<131,67,0>> > > '_' > > [<<131,100,0,1,95>>] > > > > where the output in each case is the binary, the term it decodes to, and > the > list of all possible encodings produced by term_to_binary. > > > > Is this a bug? > > > > John > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -- View this message in context: http://www.nabble.com/binary_to_term--are-these-bugs--tp14950900p14974713.ht ml Sent from the Erlang Bugs mailing list archive at Nabble.com. ------------------------------ _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://www.erlang.org/mailman/listinfo/erlang-bugs End of erlang-bugs Digest, Vol 104, Issue 1 ******************************************* From paul-trapexit@REDACTED Tue Jan 22 06:59:12 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Mon, 21 Jan 2008 21:59:12 -0800 (PST) Subject: [erlang-bugs] xmerl default encoding Message-ID: when i run the attached document (a simple xml document that lacks an encoding declaration) through xmerl_scan:file/1 the result contains the iso-8859-1 encoding of tilde n (\361). however the original contains the utf-8 encoding of tilde n (\303\261) and the character set change suprised me. adding a { encoding, "utf-8" } option to xmerl_scan:file/2 fixed things but the reference manual (and xml spec) say the utf-8 is the default. thanks, -- p Eshell V5.5.5 (abort with ^G) 1> xmerl_scan:file ("noencodingdecl.xml"). {{xmlElement,'Actor', 'Actor', [], {xmlNamespace,[],[]}, [], 1, [], [{xmlText,[{'Actor',1}],1,[],"Elizabeth Pe\361a",text}], [], ".", undeclared}, []} 2> xmerl_scan:file ("noencodingdecl.xml", [ { encoding, "utf-8" } ]). {{xmlElement,'Actor', 'Actor', [], {xmlNamespace,[],[]}, [], 1, [], [{xmlText,[{'Actor',1}],1,[],"Elizabeth Pe\303\261a",text}], [], ".", undeclared}, []} -------------- next part -------------- A non-text attachment was scrubbed... Name: noencodingdecl.xml Type: application/xml Size: 52 bytes Desc: URL: From paul-trapexit@REDACTED Tue Jan 22 23:55:55 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Tue, 22 Jan 2008 14:55:55 -0800 (PST) Subject: [erlang-bugs] zlib binary fails to round trip Message-ID: Interestingly enough, removing either the first or last character from this binary eliminates the problem. Cheers, -- p ------- 37> zlib:unzip (zlib:zip (<<"2714880batteryB000B6MLSCA2NNNAUZZIIVC6xbox 360 accessoryB000B6MLSCA3R2YUWPTEGASYxbox 360Items12424B000B6MLSCA3L6JBR3XAO9L5B000B6MLSCA3R2YUWPTEGASYbattery packItems11313B000B6MLSCA2XQT4U37YFO40B000B6MLSCA19EPX5X6LRPPBxbox 360 accessoryItems199B000B6MLSCA37IUBFAP495XQB000B6MLSCA3R2YUWPTEGASYbatteryItems155B000B6MLSCA2NNNAUZZIIVC6B000B6MLSCA3R2CSI4NSJCCVrechargeable batteryItems144B000B6MLSCA368EJ0XEL1PRVB000B6MLSCA3R2YUWPTEGASY">>)). =ERROR REPORT==== 22-Jan-2008::14:53:52 === Error in process <0.196.0> with exit value: {data_error,[{zlib,call,3},{zlib,unzip,1},{erl_eval,do_apply,5},{shell,exprs,6},{shell,eval_loop,3}]} ** exited: {data_error,[{zlib,call,3}, {zlib,unzip,1}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_loop,3}]} ** 38> zlib:module_info (). [{exports,[{open,0}, {close,1}, {deflateInit,1}, {deflateInit,2}, {deflateInit,6}, {deflateSetDictionary,2}, {deflateReset,1}, {deflateParams,3}, {deflate,2}, {deflate,3}, {deflateEnd,1}, {inflateInit,1}, {inflateInit,2}, {inflateSetDictionary,2}, {inflateSync,1}, {inflateReset,1}, {inflate,2}, {inflateEnd,1}, {setBufSize,2}, {getBufSize,1}, {crc32,1}, {crc32,2}, {crc32,3}, {adler32,2}, {adler32|...}, {...}|...]}, {imports,[]}, {attributes,[{vsn,[235850242155034454638676172994528236350]}]}, {compile,[{options,[{cwd,"/build/buildd/erlang-11.b.2/lib/kernel/src"}, {outdir,"/build/buildd/erlang-11.b.2/lib/kernel/src/../ebin"}, {i,"/build/buildd/erlang-11.b.2/lib/kernel/src/../include"}, debug_info]}, {version,"4.4.2"}, {time,{2007,1,23,12,4,54}}, {source,"/build/buildd/erlang-11.b.2/lib/kernel/src/zlib.erl"}]}] -------- Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce From matthew@REDACTED Wed Jan 23 06:13:00 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 22 Jan 2008 21:13:00 -0800 Subject: [erlang-bugs] zlib binary fails to round trip In-Reply-To: References: Message-ID: On 1/22/08, Paul Mineiro wrote: > Interestingly enough, removing either the first or last character from this binary eliminates the problem. I can't reproduce this with either R11B-5 or R12B-0, but I suspect the word wrapping is at fault. Can you send this binary again, but using the output from io:write/1? From bertil.karlsson@REDACTED Wed Jan 23 12:31:17 2008 From: bertil.karlsson@REDACTED (Bertil Karlsson) Date: Wed, 23 Jan 2008 12:31:17 +0100 Subject: [erlang-bugs] xmerl default encoding In-Reply-To: References: Message-ID: <47972585.2040507@ericsson.com> Thank you for reporting this problem. I will take a look at it soon. /Bertil Karlsson Paul Mineiro wrote: > when i run the attached document (a simple xml document that lacks an > encoding declaration) through xmerl_scan:file/1 the result contains the > iso-8859-1 encoding of tilde n (\361). however the original contains the > utf-8 encoding of tilde n (\303\261) and the character set change > suprised me. adding a { encoding, "utf-8" } option to xmerl_scan:file/2 > fixed things but the reference manual (and xml spec) say the utf-8 is > the default. > > thanks, > > -- p > > Eshell V5.5.5 (abort with ^G) > 1> xmerl_scan:file ("noencodingdecl.xml"). > {{xmlElement,'Actor', > 'Actor', > [], > {xmlNamespace,[],[]}, > [], > 1, > [], > [{xmlText,[{'Actor',1}],1,[],"Elizabeth Pe\361a",text}], > [], > ".", > undeclared}, > []} > 2> xmerl_scan:file ("noencodingdecl.xml", [ { encoding, "utf-8" } ]). > {{xmlElement,'Actor', > 'Actor', > [], > {xmlNamespace,[],[]}, > [], > 1, > [], > [{xmlText,[{'Actor',1}],1,[],"Elizabeth Pe\303\261a",text}], > [], > ".", > undeclared}, > []} > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From ulf.wiger@REDACTED Wed Jan 23 15:38:11 2008 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Wed, 23 Jan 2008 15:38:11 +0100 Subject: [erlang-bugs] undef in docbuilder Message-ID: <47975153.8080603@ericsson.com> I started playing with docbuilder, and encountered the following error: ** exception error: undefined function docb_tr_fascicules2html:extension/0 in function docb_main:finish_transform/4 in call from lists:foreach/2 in call from docb_transform:file/2 Indeed, the module docb_tr_fascicules2html.erl does not seem to exist in the source tree. At least this is true for the R12B for Windows package. BR, Ulf W From kenneth.lundin@REDACTED Wed Jan 23 16:34:14 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 23 Jan 2008 16:34:14 +0100 Subject: [erlang-bugs] undef in docbuilder In-Reply-To: <47975153.8080603@ericsson.com> References: <47975153.8080603@ericsson.com> Message-ID: Hi, I will look at this since I am doing a lot of other changes in docbuilder right now. The module docb_tr_fascicules2html is not present in our sources either but still it works perfectly well to build all our docs to html. I think the reason is that we don't use the fascicules dtd for the html generation. /Kenneth On 1/23/08, Ulf Wiger (TN/EAB) wrote: > > I started playing with docbuilder, and encountered the > following error: > > ** exception error: undefined function docb_tr_fascicules2html:extension/0 > in function docb_main:finish_transform/4 > in call from lists:foreach/2 > in call from docb_transform:file/2 > > Indeed, the module docb_tr_fascicules2html.erl does > not seem to exist in the source tree. > > At least this is true for the R12B for Windows package. > > BR, > Ulf W > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From ulf.wiger@REDACTED Wed Jan 23 16:58:09 2008 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Wed, 23 Jan 2008 16:58:09 +0100 Subject: [erlang-bugs] undef in docbuilder In-Reply-To: References: <47975153.8080603@ericsson.com> Message-ID: <47976411.7000407@ericsson.com> Kenneth Lundin skrev: > Hi, > > I will look at this since I am doing a lot of other changes in > docbuilder right now. > The module docb_tr_fascicules2html is not present in our sources > either but still > it works perfectly well to build all our docs to html. > I think the reason is that we don't use the fascicules dtd for the > html generation. > > /Kenneth Ok. What I'm doing right now is formatting a set of design rules using docbuilder. I'm using separate files for chapters, and used the fascicules DTD for a top-level document. I assume there is another way then? I had in mind to follow the User Guide format, frames and all. BR, Ulf W > > On 1/23/08, Ulf Wiger (TN/EAB) wrote: >> I started playing with docbuilder, and encountered the >> following error: >> >> ** exception error: undefined function docb_tr_fascicules2html:extension/0 >> in function docb_main:finish_transform/4 >> in call from lists:foreach/2 >> in call from docb_transform:file/2 >> >> Indeed, the module docb_tr_fascicules2html.erl does >> not seem to exist in the source tree. >> >> At least this is true for the R12B for Windows package. >> >> BR, >> Ulf W >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> From paul-trapexit@REDACTED Wed Jan 23 19:11:06 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Wed, 23 Jan 2008 10:11:06 -0800 (PST) Subject: [erlang-bugs] zlib binary fails to round trip In-Reply-To: <18327.7545.172893.249297@antilipe.corelatus.se> References: <18327.7545.172893.249297@antilipe.corelatus.se> Message-ID: Gentlemen, I can only reproduce this on a feisty box running 11b-2 (my bad, didn't notice the version difference at first). My mac has 11b-5 and doesn't have the problem. However, the problem under 11b-2 is data dependent so it's possible that it still exists under 11b-5 and we just don't know how to tickle it. Do you have an 11b-2 setup you can fire up to investigate? I've attached a file called "mega" with the bad data in it to disambiguate. Thanks, -- p 3> [ zlib:unzip (zlib:zip (Bin)) || { ok, Bin } <- [ file:read_file ("mega") ] ]. =ERROR REPORT==== 23-Jan-2008::10:04:42 === Error in process <0.32.0> with exit value: {data_error,[{zlib,call,3},{zlib,unzip,1},{erl_eval,do_apply,5},{erl_eval,eval_lc1,5},{lists,flatmap,2},{erl_eval,eval_lc,6},{shell,exprs,6},{shell,eval_loop,3}]} ** exited: {data_error,[{zlib,call,3}, {zlib,unzip,1}, {erl_eval,do_apply,5}, {erl_eval,eval_lc1,5}, {lists,flatmap,2}, {erl_eval,eval_lc,6}, {shell,exprs,6}, {shell,eval_loop,3}]} ** 4> [ Compile || { compile, Compile } <- zlib:module_info () ]. [[{options,[{cwd,"/build/buildd/erlang-11.b.2/lib/kernel/src"}, {outdir,"/build/buildd/erlang-11.b.2/lib/kernel/src/../ebin"}, {i,"/build/buildd/erlang-11.b.2/lib/kernel/src/../include"}, debug_info]}, {version,"4.4.2"}, {time,{2007,1,23,12,4,54}}, {source,"/build/buildd/erlang-11.b.2/lib/kernel/src/zlib.erl"}]] On Wed, 23 Jan 2008, Matthias Lang wrote: > Matthew Dempsky writes: > > On 1/22/08, Paul Mineiro wrote: > > > Interestingly enough, removing either the first or last character from this binary eliminates the problem. > > > > I can't reproduce this with either R11B-5 or R12B-0, but I suspect the > > word wrapping is at fault. Can you send this binary again, but using > > the output from io:write/1? > > I can't reproduce it either, but I took some guesses about what the > input data was (it got wrapped). > > Matthias > Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce -------------- next part -------------- 2714880batteryB000B6MLSCA2NNNAUZZIIVC6xbox 360 accessoryB000B6MLSCA3R2YUWPTEGASYxbox 360Items12424B000B6MLSCA3L6JBR3XAO9L5B000B6MLSCA3R2YUWPTEGASYbattery packItems11313B000B6MLSCA2XQT4U37YFO40B000B6MLSCA19EPX5X6LRPPBxbox 360 accessoryItems199B000B6MLSCA37IUBFAP495XQB000B6MLSCA3R2YUWPTEGASYbatteryItems155B000B6MLSCA2NNNAUZZIIVC6B000B6MLSCA3R2CSI4NSJCCVrechargeable batteryItems144B000B6MLSCA368EJ0XEL1PRVB000B6MLSCA3R2YUWPTEGASY From matthias@REDACTED Wed Jan 23 22:55:34 2008 From: matthias@REDACTED (Matthias Lang) Date: Wed, 23 Jan 2008 22:55:34 +0100 Subject: [erlang-bugs] zlib binary fails to round trip In-Reply-To: References: <18327.7545.172893.249297@antilipe.corelatus.se> Message-ID: <18327.47062.340514.680153@antilipe.corelatus.se> Paul Mineiro writes: > I can only reproduce this on a feisty box running 11b-2 (my bad, didn't > notice the version difference at first). My mac has 11b-5 and doesn't have > the problem. > However, the problem under 11b-2 is data dependent so it's possible that > it still exists under 11b-5 and we just don't know how to tickle it. Do > you have an 11b-2 setup you can fire up to investigate? It fails for me too on R11B-2 compiled from source on an x86 Debian box (see below). It works for R11B-4 and R11B-5. >From the R11B-3 release notes: OTP-6394 The version of zlib (http://zlib.net) linked into run-time system has been updated to version 1.2.3. It looks like R11B-2 uses zlib 1.1.4. I had a bit of a go at debugging but lost interest. Basically I tried to show that using zlib 1.1.4 directly would also fail to decompress the data. But I failed to do that, which may be because it's late, or because the problem is more subtle. Matt ---------------------------------------------------------------------- tmp >/usr/local/src/otp_src_R11B-2/bin/erl Erlang (BEAM) emulator version 5.5.2 [source] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.5.2 (abort with ^G) 1> [ zlib:unzip (zlib:zip (Bin)) || { ok, Bin } <- [ file:read_file ("mega") ] ]. ** exited: {data_error,[{zlib,call,3}, {zlib,unzip,1}, {erl_eval,do_apply,5}, {erl_eval,eval_lc1,5}, {lists,flatmap,2}, {erl_eval,eval_lc,6}, {shell,exprs,6}, {shell,eval_loop,3}]} ** =ERROR REPORT==== 23-Jan-2008::22:10:11 === Error in process <0.30.0> with exit value: {data_error,[{zlib,call,3},{zlib,unzip,1},{erl_eval,do_apply,5},{erl_eval,eval_lc1,5},{lists,flatmap,2},{erl_eval,eval_lc,6},{shell,exprs,6},{shell,eval_loop,3}]} From ulf.wiger@REDACTED Thu Jan 24 17:59:31 2008 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Thu, 24 Jan 2008 17:59:31 +0100 Subject: [erlang-bugs] error in R12B Efficiency Guide Message-ID: <4798C3F3.8000906@ericsson.com> Has this been reported already? http://www.erlang.org/doc/efficiency_guide/part_frame.html Under Common Caveats, 3.4 length/1: "foo(L) when length(L) >= 3 -> ... can be rewritten to foo([_,_,_]=L) -> ..." The two declarations are of course not equivalent. The alternative should rather be: foo([_,_,_|_] = L) -> ... BR, Ulf W From matthew@REDACTED Thu Jan 24 20:30:31 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 24 Jan 2008 11:30:31 -0800 Subject: [erlang-bugs] error in R12B Efficiency Guide In-Reply-To: <4798C3F3.8000906@ericsson.com> References: <4798C3F3.8000906@ericsson.com> Message-ID: On 1/24/08, Ulf Wiger (TN/EAB) wrote: > The two declarations are of course not equivalent. > The alternative should rather be: > > foo([_,_,_|_] = L) -> > ... It should also be noted that even this clause is not exactly semantically equivalent, because the "length(L) >= 3" guard also ensured that L is a proper list: 1> (fun(L) when length(L) >= 3 -> true; (_) -> false end)([1,2,3|4]). false 2> (fun([_,_,_|_] = L) -> true; (_) -> false end)([1,2,3|4]). true From exta7@REDACTED Fri Jan 25 02:09:05 2008 From: exta7@REDACTED (Zvi) Date: Thu, 24 Jan 2008 17:09:05 -0800 (PST) Subject: [erlang-bugs] error in R12B Efficiency Guide In-Reply-To: References: <4798C3F3.8000906@ericsson.com> Message-ID: <15079082.post@talk.nabble.com> Slightly OT: is there is some built-in mechanism for testing if expression matching the pattern? Something like this: -module(is_match). -compile([export_all]). -define(IS_MATCH(Pattern,Expr), ((fun(Pattern) -> true; (_) -> false end)(Expr))). test() -> { ?IS_MATCH([_,$b,_], "abc"), ?IS_MATCH("xab"++_, "waba"), ?IS_MATCH({_,_}, {1,2}) }. Erlang (BEAM) emulator version 5.6 [smp:32] [async-threads:0] Eshell V5.6 (abort with ^G) 1> c(is_match). {ok,is_match} 2> is_match:test(). {true,false,true} Zvi -- View this message in context: http://www.nabble.com/error-in-R12B-Efficiency-Guide-tp15069805p15079082.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From exta7@REDACTED Fri Jan 25 02:10:02 2008 From: exta7@REDACTED (Zvi) Date: Thu, 24 Jan 2008 17:10:02 -0800 (PST) Subject: [erlang-bugs] error in R12B Efficiency Guide Message-ID: <15079082.post@talk.nabble.com> Slightly OT: Does Erlang have some built-in mechanism for testing, if expression matching the pattern? Something like this: -module(is_match). -compile([export_all]). -define(IS_MATCH(Pattern,Expr), ((fun(Pattern) -> true; (_) -> false end)(Expr))). test() -> { ?IS_MATCH([_,$b,_], "abc"), ?IS_MATCH("xab"++_, "waba"), ?IS_MATCH({_,_}, {1,2}) }. Erlang (BEAM) emulator version 5.6 [smp:32] [async-threads:0] Eshell V5.6 (abort with ^G) 1> c(is_match). {ok,is_match} 2> is_match:test(). {true,false,true} Zvi -- View this message in context: http://www.nabble.com/error-in-R12B-Efficiency-Guide-tp15069805p15079082.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From richardc@REDACTED Fri Jan 25 09:55:40 2008 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 25 Jan 2008 09:55:40 +0100 Subject: [erlang-bugs] error in R12B Efficiency Guide In-Reply-To: <15079082.post@talk.nabble.com> References: <4798C3F3.8000906@ericsson.com> <15079082.post@talk.nabble.com> Message-ID: <4799A40C.6060607@it.uu.se> Zvi wrote: > is there is some built-in mechanism for testing if expression matching the > pattern? > Something like this: > > -define(IS_MATCH(Pattern,Expr), ((fun(Pattern) -> true; (_) -> false > end)(Expr))). No, nothing built-in. But your macro should work fine. Using the 'inline' flag when you compile should get rid of the run-time fun calls. /Richard From christophe.romain@REDACTED Fri Jan 25 11:11:53 2008 From: christophe.romain@REDACTED (Christophe Romain) Date: Fri, 25 Jan 2008 11:11:53 +0100 Subject: [erlang-bugs] doc typo in bit syntax expressions Message-ID: from http://www.erlang.org/doc/reference_manual/part_frame.html 6.16 Bit Syntax Expressions Type= integer| float|binarybytes|bitstring|bits The default is integer, bytes is a shorthand for binary and bits is a shorthand for bitstring i guess there is a missing pipe -> binary | bytes From kenneth.lundin@REDACTED Fri Jan 25 12:01:26 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 25 Jan 2008 12:01:26 +0100 Subject: [erlang-bugs] doc typo in bit syntax expressions In-Reply-To: References: Message-ID: Thanks for pointing this out. The correction (already done) will be delivered in R12B-1 preliminary planned for February 6:th. /Regards Kenneth On 1/25/08, Christophe Romain wrote: > from http://www.erlang.org/doc/reference_manual/part_frame.html > 6.16 Bit Syntax Expressions > Type= integer| float|binarybytes|bitstring|bits > The default is integer, bytes is a shorthand for binary and bits > is a shorthand for bitstring > > i guess there is a missing pipe -> binary | bytes > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From fritchie@REDACTED Sat Jan 26 02:32:18 2008 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 25 Jan 2008 19:32:18 -0600 Subject: [erlang-bugs] erlang:phash2/1 isn't architecture-independent? Message-ID: <94416.1201311138@snookles.snookles.com> Greetings. Using R11B-5 on both i386 and amd64 platforms, I see that erlang:phash2/1 yields different values. R12B-0 on amd64 agrees with R11B-5 on amd64. However, on both platforms, erlang:phash/2 agree. According to the R11B-5 docs for erlang:phash2/1: "Portable hash function that will give the same hash for the same Erlang term regardless of machine architecture and ERTS version (the BIF was introduced in ERTS 5.2)." So, is the bug in the source code or in the documentation? :-) -Scott 3> os:cmd("uname -a"). "FreeBSD snookles.snookles.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Sun Jan 13 13:51:57 CST 2008 root@REDACTED:/tank/exp/obj-fbsd7/tank/exp/src-fbsd7/sys/GENERIC amd64\n" 4> erlang:phash(<<"Scott9">>, 999999). 952273 5> erlang:phash2(<<"Scott9">>). 2589127136 ----------------- (dev@REDACTED)10> os:cmd("uname -a"). "FreeBSD old-snookles.snookles.com 5.4-STABLE FreeBSD 5.4-STABLE #0: Sat Sep 24 16:25:26 CDT 2005 fritchie@REDACTED:/scratch/freebsd-stable-obj/scratch/freebsd-stable-src/sys/GENERIC i386\n" (dev@REDACTED)11> erlang:phash(<<"Scott9">>, 999999). 952273 (dev@REDACTED)12> erlang:phash2(<<"Scott9">>). 38990304 From bjorn@REDACTED Mon Jan 28 11:56:00 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 28 Jan 2008 11:56:00 +0100 Subject: [erlang-bugs] error in R12B Efficiency Guide In-Reply-To: <4798C3F3.8000906@ericsson.com> References: <4798C3F3.8000906@ericsson.com> Message-ID: Thanks! I have now corrected this embarrassing mistake. /Bjorn "Ulf Wiger (TN/EAB)" writes: > Has this been reported already? > > http://www.erlang.org/doc/efficiency_guide/part_frame.html > > Under Common Caveats, 3.4 length/1: > > "foo(L) when length(L) >= 3 -> > ... > > can be rewritten to > > foo([_,_,_]=L) -> > ..." > > The two declarations are of course not equivalent. > The alternative should rather be: > > foo([_,_,_|_] = L) -> > ... > > BR, > Ulf W > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From hans.bolinder@REDACTED Mon Jan 28 14:36:12 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 28 Jan 2008 14:36:12 +0100 Subject: [erlang-bugs] erlang:phash2/1 isn't architecture-independent? In-Reply-To: <94416.1201311138@snookles.snookles.com> References: <94416.1201311138@snookles.snookles.com> Message-ID: <18333.55884.769261.885281@gargle.gargle.HOWL> [Scott Lystig Fritchie:] > Using R11B-5 on both i386 and amd64 platforms, I see that > erlang:phash2/1 yields different values. phash2/1 is broken on 64-bit platforms. Thanks for reporting this bug! Best regards, Hans Bolinder, Erlang/OTP team *** bif.c Mon Jan 28 14:25:22 2008 --- /clearcase/otp/erts/erts/emulator/beam/bif.c Mon Jan 28 13:47:02 2008 *************** *** 3624,3630 **** Uint32 hash; hash = make_hash2(BIF_ARG_1); ! BIF_RET(make_small(hash & MAX_SMALL)); } BIF_RETTYPE phash2_2(BIF_ALIST_2) --- 3624,3630 ---- Uint32 hash; hash = make_hash2(BIF_ARG_1); ! BIF_RET(make_small(hash & ((1L << 27) - 1))); } BIF_RETTYPE phash2_2(BIF_ALIST_2)