From per@REDACTED Thu Jan 8 00:10:28 2009 From: per@REDACTED (Per Hedeland) Date: Thu, 8 Jan 2009 00:10:28 +0100 (CET) Subject: [erlang-patches] snmp floating bits Message-ID: <200901072310.n07NAS3c076352@pluto.hedeland.org> Hi, There is a quite unnecessary use of math:pow/2 in snmpa_agent.erl, that may (did:-) cause problems on systems without floating point support. Obvious patch below. --Per Hedeland --- lib/snmp/src/agent/snmpa_agent.erl.orig 2008-06-10 14:55:27.000000000 +0200 +++ lib/snmp/src/agent/snmpa_agent.erl 2009-01-08 00:00:36.000000000 +0100 @@ -2940,7 +2940,7 @@ when Asn1#asn1_type.bertype == 'BITS', integer(Val) -> {value,Kibbles} = snmp_misc:assq(kibbles,Asn1#asn1_type.assocList), {_Kibble,BitNo} = lists:last(Kibbles), - case round(math:pow(2,BitNo+1)) of + case (1 bsl (BitNo+1)) of X when Val < X -> {value,'BITS',Val}; _Big -> From c.romain@REDACTED Thu Jan 8 02:02:39 2009 From: c.romain@REDACTED (cyril Romain) Date: Thu, 08 Jan 2009 02:02:39 +0100 Subject: [erlang-patches] packaged modules support for code:load_abs/1 Message-ID: <496550AF.2050805@laposte.net> Hi, Here is a patch for the 1st fix suggestion of the following bug: http://www.erlang.org/pipermail/erlang-bugs/2008-December/001138.html Although it fix the issue, I very much dislike to successively try to load the module until loaded with the right module name, but I couldn't find a better way. As explained in the bug report a more elegant patch would consist in loading the file only once. But unfortunately I don't know the Erlang internal enough nor how Erlang kernel and beam_load.c C code can interact to create such a patch :-/ Hopefully some Erlang hackers here know how to achieve that properly :-) Cyril -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-load_abs-1-so-that-it-supports-module-packages.patch Type: text/x-patch Size: 2519 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Disable-error-logger-when-loading-packaged-modules.patch Type: text/x-patch Size: 1168 bytes Desc: not available URL: From tranniec@REDACTED Fri Jan 16 18:20:58 2009 From: tranniec@REDACTED (Trannie Carter) Date: Fri, 16 Jan 2009 12:20:58 -0500 Subject: [erlang-patches] Detect reliable floating point exceptions on OS X Tiger Message-ID: <20090116172057.GC8673@xserve.internal.designvox.com> Hi, This patch modifies the reliable floating point exception test in the erts configure.in script to correctly test FPEs on Mac OS X Tiger. It moves the "modern (leopard) mcontext" test above the FPE test and then uses the DARWIN_MODERN_MCONTEXT define to choose which mcontext structure to use in the test. Without this patch, I can't enable HiPE on Intel/Tiger. I don't have an appropriate machine to test on, but I think that PPC/Tiger has had HiPE working only because the FPE test still uses the pre-Leopard mcontext in the __ppc__ section and I would guess that HiPE will be disabled on PPC/Leopard. I haven't modified that part of the test because I don't have Leopard include files. Maybe someone can take a look? I'm happy to alter the patch to make it acceptable for inclusion. I've tested it on Intel/Tiger and PPC/Tiger and the system builds successfully and HiPE nicely accellerates the Ackermann function. I don't think I've broken anything :) thanks, trannie -------------- next part -------------- --- otp_src_R12B-5/erts/configure.in 2008-11-04 05:51:24.000000000 -0500 +++ otp_src_R12B-5.tiger-mcontext/erts/configure.in 2009-01-16 09:50:18.000000000 -0500 @@ -1862,6 +1862,44 @@ ;; esac fi + +case $ARCH-$OPSYS in + amd64-darwin*|x86-darwin*) + AC_MSG_CHECKING([For modern (leopard) style mcontext_t]) + AC_TRY_COMPILE([ + #include + #include + #include + #include + #include + #include + #include + ],[ + #if defined(__APPLE__) && defined(__MACH__) && !defined(__DARWIN__) + #define __DARWIN__ 1 + #endif + + #ifndef __DARWIN__ + #error inpossible + #else + + mcontext_t mc = NULL; + int x = mc->__fs.__fpu_mxcsr; + + #endif + ],darwin_mcontext_leopard=yes, + darwin_mcontext_leopard=no) + if test X"$darwin_mcontext_leopard" = X"yes"; then + AC_DEFINE(DARWIN_MODERN_MCONTEXT,[],[Modern style mcontext_t in MacOSX]) + AC_MSG_RESULT(yes) + else + AC_MSG_RESULT(no) + fi + ;; + *) + darwin_mcontext_leopard=no + ;; +esac if test X${enable_fp_exceptions} = Xauto ; then if test X${enable_hipe} = Xyes; then enable_fp_exceptions=yes @@ -2239,6 +2277,7 @@ regs[PT_FPSCR] = 0x80|0x40|0x10; /* VE, OE, ZE; not UE or XE */ #endif #elif defined(__DARWIN__) +#if defined(DARWIN_MODERN_MCONTEXT) #if defined(__x86_64__) mcontext_t mc = uc->uc_mcontext; struct __darwin_x86_float_state64 *fpstate = &mc->__fs; @@ -2254,6 +2293,23 @@ mc->ss.srr0 += 4; mc->fs.fpscr = 0x80|0x40|0x10; #endif +#else +#if defined(__x86_64__) + mcontext_t mc = uc->uc_mcontext; + struct x86_float_state64_t *fpstate = &mc->fs; + fpstate->fpu_mxcsr = 0x1F80; + *(unsigned short *)&fpstate->fpu_fsw &= ~0xFF; +#elif defined(__i386__) + mcontext_t mc = uc->uc_mcontext; + x86_float_state32_t *fpstate = &mc->fs; + fpstate->fpu_mxcsr = 0x1F80; + *(unsigned short *)&fpstate->fpu_fsw &= ~0xFF; +#elif defined(__ppc__) + mcontext_t mc = uc->uc_mcontext; + mc->ss.srr0 += 4; + mc->fs.fpscr = 0x80|0x40|0x10; +#endif +#endif #elif defined(__FreeBSD__) && defined(__x86_64__) mcontext_t *mc = &uc->uc_mcontext; struct savefpu *savefpu = (struct savefpu*)&mc->mc_fpstate; @@ -2360,43 +2416,6 @@ fi fi -case $ARCH-$OPSYS in - amd64-darwin*|x86-darwin*) - AC_MSG_CHECKING([For modern (leopard) style mcontext_t]) - AC_TRY_COMPILE([ - #include - #include - #include - #include - #include - #include - #include - ],[ - #if defined(__APPLE__) && defined(__MACH__) && !defined(__DARWIN__) - #define __DARWIN__ 1 - #endif - - #ifndef __DARWIN__ - #error inpossible - #else - - mcontext_t mc = NULL; - int x = mc->__fs.__fpu_mxcsr; - - #endif - ],darwin_mcontext_leopard=yes, - darwin_mcontext_leopard=no) - if test X"$darwin_mcontext_leopard" = X"yes"; then - AC_DEFINE(DARWIN_MODERN_MCONTEXT,[],[Modern style mcontext_t in MacOSX]) - AC_MSG_RESULT(yes) - else - AC_MSG_RESULT(no) - fi - ;; - *) - darwin_mcontext_leopard=no - ;; -esac From mclaughlin77@REDACTED Fri Jan 23 16:47:20 2009 From: mclaughlin77@REDACTED (Kelly McLaughlin) Date: Fri, 23 Jan 2009 08:47:20 -0700 Subject: [erlang-patches] Patch to add digest authentication support to inets http client Message-ID: <208c9bd70901230747l6e8e2e5bm9176c62d47657e7b@mail.gmail.com> Here's a patch to make the inets http client support HTTP digest authentication that I created for a recent project. Thought I'd share it in case anyone else could use it. To use just specify the authorization header with a value of "digest" and include the user credentials with the url. Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: digest_auth.patch Type: text/x-patch Size: 8241 bytes Desc: not available URL: From davidepesa@REDACTED Thu Jan 29 10:39:12 2009 From: davidepesa@REDACTED (Davide Pesavento) Date: Thu, 29 Jan 2009 10:39:12 +0100 Subject: [erlang-patches] Remove executable stacks (HiPE/amd64) Message-ID: <2da21fe50901290139x5df2afccq3ef22bd8d9c04c7@mail.gmail.com> Hi, the attached patch fixes executable stacks in HiPE asm code for amd64. I guess a similar patch can easily be applied to the other architectures. References: [1] https://bugs.gentoo.org/show_bug.cgi?id=249328 [2] http://www.erlang.org/pipermail/erlang-bugs/2008-December/001125.html [3] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml Regards, Davide Pesavento -------------- next part -------------- A non-text attachment was scrubbed... Name: GNU-stack.patch Type: application/octet-stream Size: 1014 bytes Desc: not available URL: From mikpe@REDACTED Thu Jan 29 11:11:16 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 29 Jan 2009 11:11:16 +0100 Subject: [erlang-patches] Remove executable stacks (HiPE/amd64) In-Reply-To: <2da21fe50901290139x5df2afccq3ef22bd8d9c04c7@mail.gmail.com> References: <2da21fe50901290139x5df2afccq3ef22bd8d9c04c7@mail.gmail.com> Message-ID: <18817.32964.133101.701435@harpo.it.uu.se> Davide Pesavento writes: > Hi, > the attached patch fixes executable stacks in HiPE asm code for amd64. > I guess a similar patch can easily be applied to the other > architectures. > > References: > [1] https://bugs.gentoo.org/show_bug.cgi?id=249328 > [2] http://www.erlang.org/pipermail/erlang-bugs/2008-December/001125.html > [3] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml Thanks, this patch is what I ([2] above) suspected was needed. Note that HiPE never has used executable stacks, all this does is annotate some assembly file modules so that the build tools don't mark them as needing executable stack. This will be included in the R13B release, extended to cover all architectures not just amd64. /Mikael From davidepesa@REDACTED Thu Jan 29 16:43:18 2009 From: davidepesa@REDACTED (Davide Pesavento) Date: Thu, 29 Jan 2009 16:43:18 +0100 Subject: [erlang-patches] Remove executable stacks (HiPE/amd64) In-Reply-To: <18817.32964.133101.701435@harpo.it.uu.se> References: <2da21fe50901290139x5df2afccq3ef22bd8d9c04c7@mail.gmail.com> <18817.32964.133101.701435@harpo.it.uu.se> Message-ID: <2da21fe50901290743s64ab1106y814266a351733c96@mail.gmail.com> On Thu, Jan 29, 2009 at 11:11, Mikael Pettersson wrote: > Davide Pesavento writes: > > Hi, > > the attached patch fixes executable stacks in HiPE asm code for amd64. > > I guess a similar patch can easily be applied to the other > > architectures. > > > > References: > > [1] https://bugs.gentoo.org/show_bug.cgi?id=249328 > > [2] http://www.erlang.org/pipermail/erlang-bugs/2008-December/001125.html > > [3] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml > > Thanks, this patch is what I ([2] above) suspected was needed. > > Note that HiPE never has used executable stacks, all this does is > annotate some assembly file modules so that the build tools don't > mark them as needing executable stack. Indeed. By default gcc does not add GNU_STACK markings to .S files, so they must be added manually to avoid an exec stack when the code does not require it. > > This will be included in the R13B release, extended to cover all > architectures not just amd64. > > /Mikael > Thanks, Davide From nc@REDACTED Thu Jan 29 16:58:16 2009 From: nc@REDACTED (Nicolas Charpentier) Date: Thu, 29 Jan 2009 16:58:16 +0100 Subject: [erlang-patches] Emake on SMP Message-ID: <4981D218.30002@charpi.net> Hi, Here is a proposal to make parallel compilation with emake. The patch is based on OTP R12 b5 source code. I modified the make:process/3 function in order to let it spawn a process per file to compile. The 'main' process wait for the result of all children before to return. I let an 'after' clause in the receive loop in order to not get stuck if one compilation never notify its result. Regards, ---- Nicolas Charpentier -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_make.erl Type: text/x-erlang Size: 1328 bytes Desc: not available URL: From bgustavsson@REDACTED Fri Jan 30 10:39:04 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 30 Jan 2009 10:39:04 +0100 Subject: [erlang-patches] Emake on SMP In-Reply-To: <4981D218.30002@charpi.net> References: <4981D218.30002@charpi.net> Message-ID: <6672d0160901300139x293e3b16rb1ebd41b00deef7a@mail.gmail.com> 2009/1/29 Nicolas Charpentier : > Hi, > Here is a proposal to make parallel compilation with emake. > The patch is based on OTP R12 b5 source code. > > I modified the make:process/3 function in order to let it spawn a process > per file to compile. The 'main' process wait for the result of all children > before to return. > I let an 'after' clause in the receive loop in order to not get stuck if one > compilation never notify its result. Sorry, but we cannot accept a timeout. Sooner or later someone compiles a huge module on a slow machine and the compilation time will exceed one minute. The correct way to handle failing worker processes is to use either monitors or links. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Fri Jan 30 12:15:38 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Fri, 30 Jan 2009 12:15:38 +0100 Subject: [erlang-patches] Emake on SMP In-Reply-To: <4981D218.30002@charpi.net> References: <4981D218.30002@charpi.net> Message-ID: <6672d0160901300315h3a529ad6k791e34709fe5d086@mail.gmail.com> I found another problem... 2009/1/29 Nicolas Charpentier : > I modified the make:process/3 function in order to let it spawn a process > per file to compile. The 'main' process wait for the result of all children > before to return. It is not acceptable to spawn as many processes as there modules to compile. The Erlang virtual machine could easily run out of memory. For instance, our test suit for STDLIB contains 66 modules and some them are HUGE. The number of compilation processes should never be more than the number of scheduler threads, erlang:system_info(schedulers), and it should probably be limited to a value such as 4 or 8 anyway to avoid running of out memory. (The actual number should be an option, with a suitable default.) /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From mpalmer@REDACTED Fri Jan 30 13:12:23 2009 From: mpalmer@REDACTED (Matthew Palmer) Date: Fri, 30 Jan 2009 23:12:23 +1100 Subject: [erlang-patches] fread failing to handle newlines gracefully Message-ID: <20090130121223.GA11448@hezmatt.org> Hi, I recently fielded a question on Stack Overflow regarding some strange behaviour of fread, with the ~d format spec (http://stackoverflow.com/questions/473327/unexpected-behavior-of-iofread-in-erlang/490023#490023). Digging deep, it appears to be a bit of a bug in the way that newlines are handled in the format parser, as demonstrated here: 3> io_lib_fread:fread([], "10 11\n12 13 14\n", "~d"). {done,{ok,"\n"}," 1112 13 14\n"} It's eaten the newline between "11" and "12", which means that on the next pass through it'll read the next number as "1112" instead of "11", which poses some obvious problems. I've come up with the attached patch to fix the problem. I'm not very experienced with Erlang yet, so it might not be the cleanest way to do it, but it does definitely fix the problem, and without (apparently) breaking any other common use case. Comments appreciated. If there's a test suite I should be adding to as well, I'm more than happy to do that, I just couldn't find one in my source tarball. - Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: fread_eats_newlines.patch Type: text/x-diff Size: 1177 bytes Desc: not available URL: From nc@REDACTED Fri Jan 30 19:27:53 2009 From: nc@REDACTED (Nicolas Charpentier) Date: Fri, 30 Jan 2009 13:27:53 -0500 (EST) Subject: [erlang-patches] Emake on SMP In-Reply-To: <6672d0160901300315h3a529ad6k791e34709fe5d086@mail.gmail.com> References: <4981D218.30002@charpi.net> <6672d0160901300315h3a529ad6k791e34709fe5d086@mail.gmail.com> Message-ID: > I found another problem... > > 2009/1/29 Nicolas Charpentier : >> I modified the make:process/3 function in order to let it spawn a >> process >> per file to compile. The 'main' process wait for the result of all >> children >> before to return. > > It is not acceptable to spawn as many processes as there modules to > compile. > The Erlang virtual machine could easily run out of memory. For instance, > our > test suit for STDLIB contains 66 modules and some them are HUGE. > > The number of compilation processes should never be more than the number > of scheduler threads, erlang:system_info(schedulers), and it should > probably > be limited to a value such as 4 or 8 anyway to avoid running of out > memory. > (The actual number should be an option, with a suitable default.) > Humm, it seems that I have to work on it this week-end. I'll be back with another proposal without the "after" and a configuration parameter to limit the number of concurrent compilation. Regards, ---- Nicolas Charpentier http://charpi.net