From Mattias.Wadman.0881@REDACTED Tue Jan 3 20:41:03 2006 From: Mattias.Wadman.0881@REDACTED (Mattias Wadman) Date: Tue, 03 Jan 2006 20:41:03 +0100 Subject: Default FTP transfer type Message-ID: <1136317263.43bad34f19eeb@webmail.uu.se> Hello >From R10B-6 and higher the FTP client no longer sends a "TYPE" command after login to set transfer mode to binary. The documentation still says it does this automatically, ftp:type description: "Sets the file transfer type to ascii or binary. When an ftp session is opened, the transfer type is set to binary." Is this is bug or is the documentation out of sync? Also what is the purpose of the default state type value ftp_server_default? -Mattias From rlenglet@REDACTED Fri Jan 6 13:32:53 2006 From: rlenglet@REDACTED (Romain Lenglet) Date: Fri, 6 Jan 2006 21:32:53 +0900 Subject: Wrong implementations of system_code_change/4 in gen_server and gen_fsm Message-ID: <200601062132.53487.rlenglet@users.forge.objectweb.org> Implementations of system_code_change/4 in gen_server and gen_fsm always call code_change on the module implementing the behaviour, ignoring which module is upgraded. This can lead to unexpected bugs. For instance, the following code is accepted by gen_server (resp. by gen_fsm), although it is wrong: {ok, Pid} = gen_server:start_link(ModA, [], []). sys:change_code(Pid, ModB, OldVsn, Extra). ModA:code_change/3 is called by gen_server:system_code_change/4 although it is ModB that is upgraded. This is wrong. I propose the following modification, to call the generic module's code_change/3 only if the module given to sys:change_code/4-5 is this module. It is sufficient to change the definition of gen_server:system_code_change/4 from: system_code_change([Name, State, Mod, Time], _Module, OldVsn, Extra) -> ... to: system_code_change([Name, State, Mod, Time], Module, OldVsn, Extra) when Mod == Module -> ... If the guard does not hold an exception is raised, which is catched by sys:change_code. Everything's safe. I also propose a similar change in gen_fsm: system_code_change([Name, StateName, StateData, Mod, Time], _Module, OldVsn, Extra) -> should become: system_code_change([Name, StateName, StateData, Mod, Time], Module, OldVsn, Extra) when Mod == Module -> gen_event is already compliant with the semantics of sys:change_code/4 -5 and system_code_change/4. Nothing to change here. -- Romain LENGLET Pr. Chiba Shigeru Group Dept. of Mathematical and Computing Sciences Tokyo Institute of Technology From gunilla@REDACTED Mon Jan 9 14:22:28 2006 From: gunilla@REDACTED (Gunilla Arendt) Date: Mon, 09 Jan 2006 14:22:28 +0100 Subject: Wrong implementations of system_code_change/4 in gen_server and References: <200601062132.53487.rlenglet@users.forge.objectweb.org> Message-ID: Thank you for the bug report. A corrected version of gen_server and gen_fsm will be included in a future release of Erlang/OTP. Best regards, Gunilla Romain Lenglet wrote: > Implementations of system_code_change/4 in gen_server and gen_fsm > always call code_change on the module implementing the > behaviour, ignoring which module is upgraded. > This can lead to unexpected bugs. > > For instance, the following code is accepted by gen_server (resp. > by gen_fsm), although it is wrong: > > {ok, Pid} = gen_server:start_link(ModA, [], []). > sys:change_code(Pid, ModB, OldVsn, Extra). > > ModA:code_change/3 is called by gen_server:system_code_change/4 > although it is ModB that is upgraded. This is wrong. > > > I propose the following modification, to call the generic > module's code_change/3 only if the module given to > sys:change_code/4-5 is this module. It is sufficient to change > the definition of gen_server:system_code_change/4 from: > > system_code_change([Name, State, Mod, Time], _Module, OldVsn, > Extra) -> > ... > > to: > > system_code_change([Name, State, Mod, Time], Module, OldVsn, > Extra) when Mod == Module -> > ... > > If the guard does not hold an exception is raised, which is > catched by sys:change_code. Everything's safe. > > > I also propose a similar change in gen_fsm: > > system_code_change([Name, StateName, StateData, Mod, Time], > _Module, OldVsn, Extra) -> > > should become: > > system_code_change([Name, StateName, StateData, Mod, Time], > Module, OldVsn, Extra) when Mod == Module -> > > > > gen_event is already compliant with the semantics of > sys:change_code/4 -5 and system_code_change/4. > Nothing to change here. > -- _____Gunilla Arendt______________________________________________ EAB/UKI/O OTP Design Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 From lists@REDACTED Sat Jan 28 00:08:50 2006 From: lists@REDACTED (dmz (sent by Nabble.com)) Date: Fri, 27 Jan 2006 15:08:50 -0800 (PST) Subject: compiling erlang on gentoo Message-ID: <2628175.post@talk.nabble.com> When I compile erlang on gentoo linux, even using the --disable-hipe option I get a segmentation fault when running the interpeter "erl". How to fix this? thanks. -- View this message in context: http://www.nabble.com/compiling-erlang-on-gentoo-t1013068.html#a2628175 Sent from the Erlang Bugs forum at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Mon Jan 30 17:38:10 2006 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 30 Jan 2006 11:38:10 -0500 Subject: hipe patch for glibc.i686 2.3.90 Message-ID: <43DE40F2.3070305@hq.idt.net> We ran into the hipe compilation issue (R10B-9) on Linux Fedora related to the newer GLIBC version. $ uname -a Linux stardev1.corp.idt.net 2.6.15-1.1881_FC5.idtsmp #1 SMP PREEMPT Mon Jan 30 02:16:35 EST 2006 i686 i686 i386 GNU/Linux Installed Packages glibc.i686 2.3.90-30 $ make ... /home/serge/tmp/otp_src_R10B-9/erts/obj.hybrid.beam/i686-pc-linux-gnu/hipe_x86_signal.o: In function `my_sigaction':hipe/hipe_x86_signal.c:182: undefined reference to `INIT' :hipe/hipe_x86_signal.c:192: undefined reference to `__next_sigaction' /home/serge/tmp/otp_src_R10B-9/erts/obj.hybrid.beam/i686-pc-linux-gnu/hipe_x86_signal.o: In function `hipe_signal_init':hipe/hipe_x86_signal.c:225: undefined reference to `INIT' /home/serge/tmp/otp_src_R10B-9/erts/obj.hybrid.beam/i686-pc-linux-gnu/hipe_x86_signal.o: In function `my_sigaction':hipe/hipe_x86_signal.c:182: undefined reference to `INIT' :hipe/hipe_x86_signal.c:192: undefined reference to `__next_sigaction' :hipe/hipe_x86_signal.c:182: undefined reference to `INIT' :hipe/hipe_x86_signal.c:192: undefined reference to `__next_sigaction' collect2: ld returned 1 exit status Attached is the patch. Serge -- Serge Aleynikov R&D Telecom, IDT Corp. Tel: (973) 438-3436 Fax: (973) 438-1464 serge@REDACTED -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hipe_x86_signal.c.patch URL: From mikpe@REDACTED Mon Jan 30 19:38:40 2006 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 30 Jan 2006 19:38:40 +0100 Subject: hipe patch for glibc.i686 2.3.90 In-Reply-To: <43DE40F2.3070305@hq.idt.net> References: <43DE40F2.3070305@hq.idt.net> Message-ID: <17374.23856.858923.175573@alkaid.it.uu.se> Serge Aleynikov writes: > We ran into the hipe compilation issue (R10B-9) on Linux Fedora related > to the newer GLIBC version. > > $ uname -a > Linux stardev1.corp.idt.net 2.6.15-1.1881_FC5.idtsmp #1 SMP PREEMPT Mon > Jan 30 02:16:35 EST 2006 i686 i686 i386 GNU/Linux > > Installed Packages > glibc.i686 2.3.90-30 ... > --- erts/emulator/hipe/hipe_x86_signal.c 2006-01-30 10:27:20.000000000 -0500 > +++ erts/emulator/hipe/hipe_x86_signal.c 2006-01-30 10:15:46.000000000 -0500 > @@ -27,7 +27,7 @@ > #include > #include "hipe_signal.h" > > -#if __GLIBC__ == 2 && __GLIBC_MINOR__ == 3 > +#if __GLIBC__ == 2 && __GLIBC_MINOR__ >= 3 > /* See comment below for glibc 2.2. */ > #ifndef __USE_GNU > #define __USE_GNU /* to un-hide RTLD_NEXT */ So there will be a glibc-2.4 and FC5 will use it. Thanks for this info, but note that this patch only fixes up a compilation issue, it doesn't guarantee that the sigaction override code actually works with glibc-2.4. That requires testing with a multi-threaded runtime system that is instructed to create several threads at start-up. So I would prefer to delay applying this patch until FC5 final is released (around March 15 it seems) and I've had a chance to test it properly. /Mikael From serge@REDACTED Mon Jan 30 21:04:32 2006 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 30 Jan 2006 15:04:32 -0500 Subject: hipe patch for glibc.i686 2.3.90 In-Reply-To: <17374.23856.858923.175573@alkaid.it.uu.se> References: <43DE40F2.3070305@hq.idt.net> <17374.23856.858923.175573@alkaid.it.uu.se> Message-ID: <43DE7150.2020209@hq.idt.net> Agree. This is more for those who are currently working with the 2.6.15 kernel or with the FC development branch... Mikael Pettersson wrote: > Serge Aleynikov writes: > > We ran into the hipe compilation issue (R10B-9) on Linux Fedora related > > to the newer GLIBC version. > > > > $ uname -a > > Linux stardev1.corp.idt.net 2.6.15-1.1881_FC5.idtsmp #1 SMP PREEMPT Mon > > Jan 30 02:16:35 EST 2006 i686 i686 i386 GNU/Linux > > > > Installed Packages > > glibc.i686 2.3.90-30 > ... > > --- erts/emulator/hipe/hipe_x86_signal.c 2006-01-30 10:27:20.000000000 -0500 > > +++ erts/emulator/hipe/hipe_x86_signal.c 2006-01-30 10:15:46.000000000 -0500 > > @@ -27,7 +27,7 @@ > > #include > > #include "hipe_signal.h" > > > > -#if __GLIBC__ == 2 && __GLIBC_MINOR__ == 3 > > +#if __GLIBC__ == 2 && __GLIBC_MINOR__ >= 3 > > /* See comment below for glibc 2.2. */ > > #ifndef __USE_GNU > > #define __USE_GNU /* to un-hide RTLD_NEXT */ > > So there will be a glibc-2.4 and FC5 will use it. Thanks for this info, > but note that this patch only fixes up a compilation issue, it doesn't > guarantee that the sigaction override code actually works with glibc-2.4. > That requires testing with a multi-threaded runtime system that is > instructed to create several threads at start-up. > > So I would prefer to delay applying this patch until FC5 final is released > (around March 15 it seems) and I've had a chance to test it properly. > > /Mikael > -- Serge Aleynikov R&D Telecom, IDT Corp. Tel: (973) 438-3436 Fax: (973) 438-1464 serge@REDACTED From kostis@REDACTED Mon Jan 30 21:42:13 2006 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 30 Jan 2006 21:42:13 +0100 (MET) Subject: hipe patch for glibc.i686 2.3.90 In-Reply-To: Mail from 'Serge Aleynikov ' dated: Mon, 30 Jan 2006 15:04:32 -0500 Message-ID: <200601302042.k0UKgDLU010064@spikklubban.it.uu.se> > Agree. This is more for those who are currently working with the 2.6.15 > kernel or with the FC development branch... Although I am on the same team as Mikael, I have a slightly different opinion. Rather than disabling HiPE when using glibc-2.4, I would encourage all users who want to be on the cutting (bleeding?) edge, to apply Serge's patch and if they report any problems when using HiPE to report them to us. Best, Kostis From Hans.Bolinder@REDACTED Mon Jan 30 15:51:11 2006 From: Hans.Bolinder@REDACTED (Hans.Bolinder@REDACTED) Date: Mon, 30 Jan 2006 15:51:11 +0100 Subject: erl_pp botches try-catch clauses In-Reply-To: References: Message-ID: <17374.10207.841439.644057@gargle.gargle.HOWL> > erl_pp writes out try-catch clauses in a very strange > way that doesn't compile. Thanks. It will be fixed in the upcoming release of R10B. Best regards, Hans Bolinder, Erlang/OTP