From norton@REDACTED Mon Nov 5 12:13:31 2007 From: norton@REDACTED (Joseph Wayne Norton) Date: Mon, 05 Nov 2007 20:13:31 +0900 Subject: [erlang-patches] ERT: supervisor module doesn't support parameterized modules for children Message-ID: Fix to allow a supervisor to support parameterized modules for children. There is a similiar issue with the rpc module. *** ./otp_src_R11B-5/lib/stdlib/src/supervisor.erl.orig 2007-06-11 21:52:46.000000000 +0900 --- ./otp_src_R11B-5/lib/stdlib/src/supervisor.erl 2007-09-19 17:57:17.000000000 +0900 @@ -781,7 +781,7 @@ validName(_Name) -> true. -validFunc({M, F, A}) when is_atom(M), +validFunc({M, F, A}) when is_atom(M); is_tuple(M), is_atom(F), is_list(A) -> true; validFunc(Func) -> throw({invalid_mfa, Func}). @@ -801,7 +801,7 @@ validMods(Mods) when is_list(Mods) -> lists:foreach(fun(Mod) -> if - is_atom(Mod) -> ok; + is_atom(Mod); is_tuple(Mod) -> ok; true -> throw({invalid_module, Mod}) end end, -- norton@REDACTED From matthew@REDACTED Tue Nov 6 21:41:13 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 6 Nov 2007 12:41:13 -0800 Subject: [erlang-patches] Patch to add zlib:crc32_combine/4 and zlib:adler32_combine/4 Message-ID: I wrote an Erlang module to concatenate zlib compressed data, but to generate proper zlib and gzip trailers, I need to compute the adler32 and crc32 checksums. adler32 has a simple algebraic structure that makes it easy to implement in just a few lines of Erlang code (give it a shot---it's fun :-), but combining crc32 checksums involves computing x*2^n in a Galois field (which isn't so fun in Erlang). Anyways, I noticed the zlib C library already provides functions for these, but they're not exposed by the Erlang interface... so I wrote the patch below. (I'm mainly interested in crc32_combine, but I thought it would be nice to have adler32_combine for completeness.) --- erts/emulator/drivers/common/zlib_drv.c.orig 2007-11-06 11:44:12.000000000 -0800 +++ erts/emulator/drivers/common/zlib_drv.c 2007-11-06 11:30:11.000000000 -0800 @@ -55,6 +55,9 @@ #define ADLER32_1 21 #define ADLER32_2 22 +#define CRC32_COMBINE 23 +#define ADLER32_COMBINE 24 + #define DEFAULT_BUFSZ 4000 static int zlib_init(void); @@ -597,6 +600,26 @@ adler = adler32(adler, buf+4, len-4); return zlib_value(adler, rbuf, rlen); } + + case CRC32_COMBINE: { + uLong crc1, crc2, len2; + if (len != 12) goto badarg; + crc1 = i32(buf); + crc2 = i32(buf+4); + len2 = i32(buf+8); + crc1 = crc32_combine(crc1, crc2, len2); + return zlib_value(crc1, rbuf, rlen); + } + + case ADLER32_COMBINE: { + uLong adler1, adler2, len2; + if (len != 12) goto badarg; + adler1 = i32(buf); + adler2 = i32(buf+4); + len2 = i32(buf+8); + adler1 = adler32_combine(adler1, adler2, len2); + return zlib_value(adler1, rbuf, rlen); + } } badarg: --- lib/kernel/src/zlib.erl.orig 2007-11-06 11:20:14.000000000 -0800 +++ lib/kernel/src/zlib.erl 2007-11-06 11:43:28.000000000 -0800 @@ -25,6 +25,7 @@ inflateSync/1,inflateReset/1,inflate/2,inflateEnd/1, setBufSize/2,getBufSize/1, crc32/1,crc32/2,crc32/3,adler32/2,adler32/3,getQSize/1, + crc32_combine/4,adler32_combine/4, compress/1,uncompress/1,zip/1,unzip/1, gzip/1,gunzip/1]). @@ -108,6 +109,9 @@ -define(ADLER32_1, 21). -define(ADLER32_2, 22). +-define(CRC32_COMBINE, 23). +-define(ADLER32_COMBINE, 24). + %% open a z_stream open() -> open_port({spawn, zlib_drv}, [binary]). @@ -213,6 +217,16 @@ adler32(_Z, _Adler, _Binary) -> erlang:error(badarg). +crc32_combine(Z, CRC1, CRC2, Len2) when is_integer(CRC1), is_integer(CRC2), is_integer(Len2) -> + call(Z, ?CRC32_COMBINE, <>); +crc32_combine(_Z, _CRC1, _CRC2, _Len2) -> + erlang:error(badarg). + +adler32_combine(Z, Adler1, Adler2, Len2) when is_integer(Adler1), is_integer(Adler2), is_integer(Len2) -> + call(Z, ?ADLER32_COMBINE, <>); +adler32_combine(_Z, _Adler1, _Adler2, _Len2) -> + erlang:error(badarg). + getQSize(Z) -> call(Z, ?GET_QSIZE, []). From matthew@REDACTED Tue Nov 13 20:05:59 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 13 Nov 2007 11:05:59 -0800 Subject: [erlang-patches] Patch to add zlib:crc32_combine/4 and zlib:adler32_combine/4 In-Reply-To: References: Message-ID: On 11/6/07, Matthew Dempsky wrote: > I wrote an Erlang module to concatenate zlib compressed data, but to > generate proper zlib and gzip trailers, I need to compute the adler32 > and crc32 checksums. Also, for what it's worth, this code has been released as part of our eswf project on google code. You can find the module source at: http://eswf.googlecode.com/svn/trunk/src/zipchunk.erl Right now the public API only supports zlib encoding, but the code internally could handle raw deflate and gzip encoding without much effort. Support for crc32 checksum joining is currently using a slow workaround until the otp patch I submitted is accepted. As such, I'm interested in feedback on my patch. Will it be merged into R12B? Is there anything else I can do to help ensure this happens? Thanks. From matthew@REDACTED Wed Nov 14 01:46:35 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 13 Nov 2007 16:46:35 -0800 Subject: [erlang-patches] Patch to add zlib:crc32_combine/4 and zlib:adler32_combine/4 In-Reply-To: References: Message-ID: Some further testing with the zipchunk module revealed that the zlib_drv does not properly flush the zlib buffers. In particular, a call to zlib:deflate(Z, Binary, full) can leave part of Binary still in Z's internal state. The patch below properly follows the advice of zlib.h that ``If deflate returns with avail_out == 0, this function must be called again with the same value of the flush parameter and more output space (updated avail_out).'' Also, Z_STREAM_END is only returned when Z_FINISH is given. --- otp_src_R11B-5/erts/emulator/drivers/common/zlib_drv.c.orig 2007-11-06 11:44:12.000000000 -0800 +++ otp_src_R11B-5/erts/emulator/drivers/common/zlib_drv.c 2007-11-13 16:39:48.000000000 -0800 @@ -323,12 +323,15 @@ } } } else { - while (d->s.avail_out < d->binsz) { + while (d->s.avail_out == 0) { zlib_output(d); - if (res == Z_STREAM_END) { - break; + if ((res = deflate(&d->s, flush)) < 0) { + return res; } } + if (d->s.avail_out < d->binsz) { + zlib_output(d); + } } } return res; From tomas.abrahamsson@REDACTED Wed Nov 14 12:25:16 2007 From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson) Date: Wed, 14 Nov 2007 12:25:16 +0100 (MET) Subject: [erlang-patches] Patch to add zlib:crc32_combine/4 and zlib:adler32_combine/4 In-Reply-To: (matthew@dempsky.org) References: Message-ID: <200711141125.lAEBPGMV008224@selic139.lmera.ericsson.se> > On 11/6/07, Matthew Dempsky wrote: >> I wrote an Erlang module to concatenate zlib compressed data, but to >> generate proper zlib and gzip trailers, I need to compute the adler32 >> and crc32 checksums. > ... > As such, I'm interested in feedback on my patch. Will it be merged > into R12B? ... I, too, would be interested in the any answer to this. Incidentally, concatenating compressed data happens to be the reason for my interest in this :-) I wrote a piece of C code to do what I needed, but having this directly in the zlib of Erlang/OTP would of couse be much better. BRs Tomas From bjorn@REDACTED Wed Nov 14 14:52:06 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 14 Nov 2007 14:52:06 +0100 Subject: [erlang-patches] Patch to add zlib:crc32_combine/4 and zlib:adler32_combine/4 In-Reply-To: References: Message-ID: "Matthew Dempsky" writes: > As such, I'm interested in feedback on my patch. Will it be merged > into R12B? Barred any unforseen problems, you patches should make it to the R12B release. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From matthew@REDACTED Wed Nov 14 18:38:40 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 14 Nov 2007 09:38:40 -0800 Subject: [erlang-patches] Patch to add zlib:crc32_combine/4 and zlib:adler32_combine/4 In-Reply-To: References: Message-ID: On 14 Nov 2007 14:52:06 +0100, Bjorn Gustavsson wrote: > Barred any unforseen problems, you patches should make it to the R12B release. Awesome, thanks. :-) From daniel@REDACTED Sun Nov 18 17:57:39 2007 From: daniel@REDACTED (Daniel Schutte) Date: Sun, 18 Nov 2007 18:57:39 +0200 Subject: [erlang-patches] Crypto Compile Problem on x86_64 OTP-R11B Message-ID: <200711181857.40406.daniel@erlfinsys.net> I have seen a few postings on the web regarding this error - specifically in the e-jabberd lists. ?The solution is given as compiling with gcc 4.0 instead of 4.1. Erlang Compiles fine, it's just the crypto module that is incomplete - more specifically the driver. ================ ENVIRONMENT ===== ================ OS ===== (CentOS 5.0) Linux cupid.erlfinsys.net 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:28 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux ================ OpenSSL ===== openssl-0.9.8b-8.3.el5_0.2 ================ GCC ===== [olympus@REDACTED otp_src_R11B-5]$ gcc --version gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. ?There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ================ Erlang ===== Erlang OTP-R11B-5 ================ ERROR ===== in the make file the following appears: /usr/bin/ld: /usr/lib64/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[4]: *** [../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so] Error 1 make[3]: *** [opt] Error 2 ============================ Tracing this you get this command that failed [olympus@REDACTED c_src]$ gcc -shared ?-o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o ?/usr/lib64/libcrypto.a /usr/bin/ld: /usr/lib64/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value ============================ else you will find it doing this: 1> crypto:start(). exec: 1: ok 2> crypto_drv: not found =ERROR REPORT==== 25-Oct-2006::12:57:02 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.96>,normal} ** When Server state == {#Port<0.96>,[]} ** Reason for termination == ** {port_died,normal} exec: 1: crypto_drv: not found ============================= Solution / Fix === Right or wrong this fixed the problem after ./configure make go to the directory ?%ERL_TOP%/lib/crypto/c_src issue the command: gcc -shared ?-o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o ?/usr/lib64/libcrypto.so now do: make install crypto:start(). From raimo+erlang-patches@REDACTED Mon Nov 19 09:14:48 2007 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 19 Nov 2007 09:14:48 +0100 Subject: [erlang-patches] Crypto Compile Problem on x86_64 OTP-R11B In-Reply-To: <200711181857.40406.daniel@erlfinsys.net> References: <200711181857.40406.daniel@erlfinsys.net> Message-ID: <20071119081448.GA6881@erix.ericsson.se> It might have been clear, but I did not get it. What is the patch? Is it to relink crypto_drv.so using gcc 4.0, or is it just to manually relink crypto_drv.so using gcc 4.1.. If the problem is in gcc 4.1, do you know if it is a 4.1 bug and has it been reported to gcc - will it be fixed in gcc, or do you know what is the root cause? We have suspected the problem being the OpenSSL libraries not being linked to allow building other (our) shared libraries (.so) that themselves contain statically linked OpenSSL libraries (libcrypto.a), but if it is a gcc 4.1 problem we are interested to know for sure. I might confuse this problem with another problem where we can not build crypto_drv.so on OpenBSD against libcrypto.a... On Sun, Nov 18, 2007 at 06:57:39PM +0200, Daniel Schutte wrote: > I have seen a few postings on the web regarding this error - specifically in > the e-jabberd lists. ?The solution is given as compiling with gcc 4.0 instead > of 4.1. > Erlang Compiles fine, it's just the crypto module that is incomplete - more > specifically the driver. > > > ================ ENVIRONMENT ===== > ================ OS ===== > (CentOS 5.0) > Linux cupid.erlfinsys.net 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:28 EDT > 2007 x86_64 x86_64 x86_64 GNU/Linux > > ================ OpenSSL ===== > openssl-0.9.8b-8.3.el5_0.2 > > ================ GCC ===== > > [olympus@REDACTED otp_src_R11B-5]$ gcc --version > gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52) > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. ?There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > ================ Erlang ===== > Erlang OTP-R11B-5 > > ================ ERROR ===== > in the make file the following appears: > > /usr/bin/ld: /usr/lib64/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 > against `OPENSSL_cpuid_setup' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > make[4]: *** [../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so] Error 1 > make[3]: *** [opt] Error 2 > > ============================ > Tracing this you get this command that failed > > [olympus@REDACTED c_src]$ > gcc -shared ?-o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o ?/usr/lib64/libcrypto.a > /usr/bin/ld: /usr/lib64/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 > against `OPENSSL_cpuid_setup' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > > ============================ > else you will find it doing this: > > 1> crypto:start(). > exec: 1: ok > 2> crypto_drv: not found > > =ERROR REPORT==== 25-Oct-2006::12:57:02 === > ** Generic server crypto_server terminating > ** Last message in was {'EXIT',#Port<0.96>,normal} > ** When Server state == {#Port<0.96>,[]} > ** Reason for termination == > ** {port_died,normal} > exec: 1: crypto_drv: not found > > > ============================= Solution / Fix === > > Right or wrong this fixed the problem > > after > > ./configure > make > > go to the directory ?%ERL_TOP%/lib/crypto/c_src > issue the command: > > gcc -shared ?-o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o ?/usr/lib64/libcrypto.so > > now do: make install > > crypto:start(). > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From daniel@REDACTED Mon Nov 19 22:01:47 2007 From: daniel@REDACTED (Daniel Schutte) Date: Mon, 19 Nov 2007 23:01:47 +0200 Subject: [erlang-patches] Crypto Compile Problem on x86_64 OTP-R11B In-Reply-To: <20071119081448.GA6881@erix.ericsson.se> References: <200711181857.40406.daniel@erlfinsys.net> <20071119081448.GA6881@erix.ericsson.se> Message-ID: <200711192301.48140.daniel@erlfinsys.net> It may have been unclear, reading the mail again :) not enough sleep The problem is that the library must be built against libcrypto.so on the 64 bit environments - I have a 32 bit environment as well and this problem does not appear there. I think the problem is in something in libcrypto.a - but must admit - my knowledge on tracing that problem further is limited ;) although I am willing to try / give more information if you can tell me what you are looking for. In order to ensure that crypto worked on the 64bit machines. The instruction that gets executed is: gcc -shared -o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o /usr/lib64/libcrypto.a but replacing the final "libcrypto.a" with "libcrypto.so" ensures a functional crypto_drv.so (example command): gcc -shared -o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o /usr/lib64/libcrypto.so I know that this change fixed it so that my 64 bit machines are working perfectly with crypto again. So the fix would be to relink using libcrypto.so and not libcrypto.a - there is no issue with gcc 4.1 as far as I could tell - everything else compiled perfectly with 4.1 I also read the mails about the OpenBSD problems on this, but don't have OpenBSD to confirm if this solves that issue on that as well. On Monday 19 November 2007 10:14:48 Raimo Niskanen wrote: > It might have been clear, but I did not get it. What is the patch? > Is it to relink crypto_drv.so using gcc 4.0, or is it just to > manually relink crypto_drv.so using gcc 4.1.. > > If the problem is in gcc 4.1, do you know if it is a 4.1 bug and has > it been reported to gcc - will it be fixed in gcc, or do you know > what is the root cause? > > We have suspected the problem being the OpenSSL libraries not > being linked to allow building other (our) shared libraries (.so) > that themselves contain statically linked OpenSSL libraries (libcrypto.a), > but if it is a gcc 4.1 problem we are interested to know for sure. > I might confuse this problem with another problem where we can not > build crypto_drv.so on OpenBSD against libcrypto.a... > > On Sun, Nov 18, 2007 at 06:57:39PM +0200, Daniel Schutte wrote: > > I have seen a few postings on the web regarding this error - specifically > > in the e-jabberd lists. ?The solution is given as compiling with gcc 4.0 > > instead of 4.1. > > Erlang Compiles fine, it's just the crypto module that is incomplete - > > more specifically the driver. > > > > > > ================ ENVIRONMENT ===== > > ================ OS ===== > > (CentOS 5.0) > > Linux cupid.erlfinsys.net 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:28 > > EDT 2007 x86_64 x86_64 x86_64 GNU/Linux > > > > ================ OpenSSL ===== > > openssl-0.9.8b-8.3.el5_0.2 > > > > ================ GCC ===== > > > > [olympus@REDACTED otp_src_R11B-5]$ gcc --version > > gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52) > > Copyright (C) 2006 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. ?There is > > NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > > > ================ Erlang ===== > > Erlang OTP-R11B-5 > > > > ================ ERROR ===== > > in the make file the following appears: > > > > /usr/bin/ld: /usr/lib64/libcrypto.a(x86_64cpuid.o): relocation > > R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a > > shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Bad value > > collect2: ld returned 1 exit status > > make[4]: *** [../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so] Error 1 > > make[3]: *** [opt] Error 2 > > > > ============================ > > Tracing this you get this command that failed > > > > [olympus@REDACTED c_src]$ > > gcc -shared ?-o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so > > ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o ?/usr/lib64/libcrypto.a > > /usr/bin/ld: /usr/lib64/libcrypto.a(x86_64cpuid.o): relocation > > R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a > > shared object; recompile with -fPIC > > /usr/bin/ld: final link failed: Bad value > > > > ============================ > > else you will find it doing this: > > > > 1> crypto:start(). > > exec: 1: ok > > 2> crypto_drv: not found > > > > =ERROR REPORT==== 25-Oct-2006::12:57:02 === > > ** Generic server crypto_server terminating > > ** Last message in was {'EXIT',#Port<0.96>,normal} > > ** When Server state == {#Port<0.96>,[]} > > ** Reason for termination == > > ** {port_died,normal} > > exec: 1: crypto_drv: not found > > > > > > ============================= Solution / Fix === > > > > Right or wrong this fixed the problem > > > > after > > > > ./configure > > make > > > > go to the directory ?%ERL_TOP%/lib/crypto/c_src > > issue the command: > > > > gcc -shared ?-o ../priv/lib/x86_64-unknown-linux-gnu/crypto_drv.so > > ../priv/obj/x86_64-unknown-linux-gnu/crypto_drv.o > > ?/usr/lib64/libcrypto.so > > > > now do: make install > > > > crypto:start(). > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-patches -- ------------------------------------- Daniel Schutte CEO - Erlang Financial Systems International Office: +27 11 602 9301 Mobile: +27 84 468 3138 Phone : +27 11 602 9302 From matthew@REDACTED Mon Nov 19 23:29:54 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Mon, 19 Nov 2007 14:29:54 -0800 Subject: [erlang-patches] Patch to allow parameterized modules in parse transforms Message-ID: The Erlang compiler does not currently allow parameterized modules to be used for parse transforms, but only because of a bad atom_to_list call. I replaced this with io_lib:format and it seems to work. --- compile.erl~ 2007-10-31 07:05:39.000000000 -0700 +++ compile.erl 2007-11-19 14:12:43.000000000 -0800 @@ -765,7 +765,7 @@ end. foldl_transform(St, [T|Ts]) -> - Name = "transform " ++ atom_to_list(T), + Name = lists:flatten(io_lib:format("transform ~p", [T])), Fun = fun(S) -> T:parse_transform(S#compile.code, S#compile.options) end, Run = case member(time, St#compile.options) of true -> fun run_tc/2; From bjorn@REDACTED Tue Nov 20 07:17:08 2007 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 20 Nov 2007 07:17:08 +0100 Subject: [erlang-patches] Patch to allow parameterized modules in parse transforms In-Reply-To: References: Message-ID: "Matthew Dempsky" writes: > The Erlang compiler does not currently allow parameterized modules to > be used for parse transforms, but only because of a bad atom_to_list > call. I replaced this with io_lib:format and it seems to work. I don't want to include this patch as there is no portable way to use a parameterized module in a compile directive embedded in a source file. We might implement another solution for using parameterized modules as parse transforms later, when/if parameterized modules have become a support part of the language. /Bjorn > --- compile.erl~ 2007-10-31 07:05:39.000000000 -0700 > +++ compile.erl 2007-11-19 14:12:43.000000000 -0800 > @@ -765,7 +765,7 @@ > end. > > foldl_transform(St, [T|Ts]) -> > - Name = "transform " ++ atom_to_list(T), > + Name = lists:flatten(io_lib:format("transform ~p", [T])), > Fun = fun(S) -> T:parse_transform(S#compile.code, S#compile.options) end, > Run = case member(time, St#compile.options) of > true -> fun run_tc/2; > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB