From thomasl_erlang@REDACTED Thu Sep 2 16:12:57 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 2 Sep 2004 07:12:57 -0700 (PDT) Subject: Man page bug R9C2 Message-ID: <20040902141257.77175.qmail@web41901.mail.yahoo.com> The R9C2 man page for gen_server:reply/2 claims the function returns 'true', but it actually returns something like: {Tag, Reply} | {'EXIT', Rsn} Best, Thomas __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From thomasl_erlang@REDACTED Wed Sep 8 16:08:43 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 8 Sep 2004 07:08:43 -0700 (PDT) Subject: Macros and keywords, R9C2 Message-ID: <20040908140843.98619.qmail@web41906.mail.yahoo.com> You currently can't define macros with the same name as keywords: -define(begin, 4711). -define(end, 11147). % compiler complains "badly formed define" However, this restriction is, as far as I can see, unnecessary: the namespaces are entirely distinct. That is, when you subsequently use the macro, it will be written '?begin', which will never be confused with plain 'begin'. Hence, I report this as a bug. Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From danie@REDACTED Wed Sep 8 16:26:46 2004 From: danie@REDACTED (Danie Schutte) Date: Wed, 08 Sep 2004 16:26:46 +0200 Subject: Macros and keywords, R9C2 In-Reply-To: <20040908140843.98619.qmail@web41906.mail.yahoo.com> References: <20040908140843.98619.qmail@web41906.mail.yahoo.com> Message-ID: <1094653605.6984.124.camel@blackbox.erlfinsys.net> I understand the reasoning, but from a practical perspective, isn't it better to stay away from names like that - just to avoid confusion? (Especially with newbies) ------- begin case ?begin of vs case ?BEGIN_PORT of ------- A bit far fetched though :) On Wed, 2004-09-08 at 16:08, Thomas Lindgren wrote: > You currently can't define macros with the same name > as keywords: > > -define(begin, 4711). > -define(end, 11147). > > % compiler complains "badly formed define" > > However, this restriction is, as far as I can see, > unnecessary: the namespaces are entirely distinct. > That is, when you subsequently use the macro, it will > be written '?begin', which will never be confused with > plain 'begin'. > > Hence, I report this as a bug. > > Best, > Thomas > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail > From thomasl_erlang@REDACTED Wed Sep 8 18:18:13 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 8 Sep 2004 09:18:13 -0700 (PDT) Subject: Macros and keywords, R9C2 In-Reply-To: <1094653605.6984.124.camel@blackbox.erlfinsys.net> Message-ID: <20040908161813.46461.qmail@web41902.mail.yahoo.com> --- Danie Schutte wrote: > I understand the reasoning, but from a practical > perspective, isn't it > better to stay away from names like that - just to > avoid confusion? > (Especially with newbies) Actually, I thought it a bit confusing that one _couldn't_ define begin, end, etc :-) Personally, I would consider "[staying] away from names like that" a matter for organizational coding standards, rather than language standards. For instance, you can already use 'begin', 'end' and so on as atoms. And Erlang macros can already be confusing for all the usual reasons (just like C macros). Best, Thomas PS. Nice domain name :-) __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From alexey@REDACTED Fri Sep 10 22:53:59 2004 From: alexey@REDACTED (Alexey Shchepin) Date: Fri, 10 Sep 2004 23:53:59 +0300 Subject: Mnesia crashed Message-ID: <87k6v17sm0.fsf@alex.sevcom.net> Hi! I just got the following error: =ERROR REPORT==== 2004-09-11 00:16:25 === Mnesia('ejabberd@REDACTED'): ** ERROR ** (core dumped to file: "/opt/jabber/server/ejabberd/src/MnesiaCore.ejabberd@REDACTED") ** FATAL ** mnesia_locker crashed: {badarg, [{erlang, '++', [{error, {premature_eof, "/opt/jabber/server/ejabberd/src/Mnesia.ejabberd@REDACTED/roster.DAT"}}, []]}, {lists,append,2}, {mnesia_locker, set_read_lock_on_all_keys, 6}, {mnesia_locker,loop,1}, {mnesia_sp,init_proc,4}, {proc_lib,init_p,5}]} state: [<0.87.0>] After that mnesia have stopped. I can send that MnesiaCore file (it is less than 300KB). From kramer@REDACTED Sat Sep 11 03:17:43 2004 From: kramer@REDACTED (Reto Kramer) Date: Fri, 10 Sep 2004 18:17:43 -0700 Subject: Mac OSX installation issue with R9C-2 Message-ID: <61D9687E-0390-11D9-BD58-000393B64312@acm.org> I've noticed that my "make install" command fails for R9C-2 on my OSX Mac because the /usr/local/lib/erlang/Install script at line 95 does a if [ -d $ERL_ROOT/lib/sasl* ] which fails with [yoghurt:~/erlang/otp_src_R9C-2] reto% sudo make install.Install Password: cd /usr/local/lib/erlang && ./Install -minimal /usr/local/lib/erlang ./Install: line 95: [: too many arguments Formatting manual pages (this may take a while...) make: *** [install.Install] Error 127 It turns out that I've got 3 version of the sasl application installed (back from older OTP releases that I used): /usr/local/lib/erlang/lib/sasl-1.10: /usr/local/lib/erlang/lib/sasl-1.9.3: /usr/local/lib/erlang/lib/sasl-1.9.4: My work around was to patch the line to be if [ -d $ERL_ROOT/lib/sasl-1.10* ] This then allowed the sasl boot script to be generated correctly (it now is the R9 script that includes kernel-2.9 rather than 2.8, which is what I cared about). Best regards, - Reto From kramer@REDACTED Sat Sep 11 03:36:51 2004 From: kramer@REDACTED (Reto Kramer) Date: Fri, 10 Sep 2004 18:36:51 -0700 Subject: test_server does not capture sasl output Message-ID: <0DC5B46E-0393-11D9-BD58-000393B64312@acm.org> In one of my testcases sasl prints information to the terminal that I start the testrun from (I use the batch option, so no new window is opened). I had hoped that sasl output would be captured per testcase like io:formation material is. Is this a bug, or do I have to do something special to capture the sasl reports (ideally associated with the test case that triggered them)? Thanks, - Reto From kramer@REDACTED Mon Sep 13 17:49:11 2004 From: kramer@REDACTED (Reto Kramer) Date: Mon, 13 Sep 2004 08:49:11 -0700 Subject: [test-server] missleading warning Message-ID: <74D8756B-059C-11D9-BD58-000393B64312@acm.org> This is not a big issue, but rather confusing to the newby. If I start a node with the {cleanup, false} option and later stop it in another testcase function [**], I receive the warning: == WARNING: Attempt to stop a nonexisting slavenode (test_a@REDACTED) === Trying to kill it anyway!!! This warning is missleading in this context since the node is indeed running (left running). Perhaps the warning can be avoided by implicitly pinging the node beforehand? Thanks, - Reto start(Config) when list(Config) -> ?line {ok, test_a@REDACTED} = ?t:start_node( test_a, slave, [{args, "-pa /Users/reto/sdev/discover/src/discover-1.0/ebin"}, {cleanup, false}]), % keep node alive until stop/1 ... stop(Config) when list(Config) -> ?line pong = net_adm:ping(test_a@REDACTED), % still there % Note that the following warning in the output of stop/1 is missleading % since the node is in fact alive. % % == WARNING: Attempt to stop a nonexisting slavenode (test_a@REDACTED) % === Trying to kill it anyway!!! % ?line true = ?t:stop_node(test_a@REDACTED), % node was started in start/1 [**] ?line pang = net_adm:ping(test_a@REDACTED). % really gone # From jamesh@REDACTED Tue Sep 21 15:22:30 2004 From: jamesh@REDACTED (James Hague) Date: Tue, 21 Sep 2004 08:22:30 -0500 Subject: Missing beam.dll exports in R9C-2 for Windows Message-ID: All of the driver-related functions are not exported from beam.dll, including driver_output. This prevents dynamically loaded drivers from even *loading* under Windows. This is a showstopper for users of Wings, esdl, or any other application making use of custom drivers. I'd like to see a new beam.dll for R9C-2 posted as soon as possible. James From vlad_dumitrescu@REDACTED Tue Sep 21 16:16:59 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 21 Sep 2004 16:16:59 +0200 Subject: Missing beam.dll exports in R9C-2 for Windows References: Message-ID: Hmm, they work for me (from the binary distribution)... Maybe it's something with the source build? /Vlad ----- Original Message ----- From: "James Hague" To: Sent: Tuesday, September 21, 2004 3:22 PM Subject: Missing beam.dll exports in R9C-2 for Windows > All of the driver-related functions are not exported from beam.dll, > including driver_output. This prevents dynamically loaded drivers from > even > *loading* under Windows. > > This is a showstopper for users of Wings, esdl, or any other application > making use of custom drivers. I'd like to see a new beam.dll for R9C-2 > posted as soon as possible. > > James > From jamesh@REDACTED Tue Sep 21 16:27:43 2004 From: jamesh@REDACTED (James Hague) Date: Tue, 21 Sep 2004 09:27:43 -0500 Subject: Missing beam.dll exports in R9C-2 for Windows Message-ID: > Hmm, they work for me (from the binary distribution)... Maybe > it's something with the source build? Hmmm...I couldn't get my drivers working because of the exports not being found, so I used Borland's tdump utility to view the exports, and they weren't there. Could you send me your beam.dll? James From Panos.Kontakos@REDACTED Tue Sep 21 17:22:50 2004 From: Panos.Kontakos@REDACTED (Panos Kontakos) Date: Tue, 21 Sep 2004 08:22:50 -0700 Subject: Missing beam.dll exports in R9C-2 for Windows Message-ID: you need to modify the DRIVER_INIT subroutine and rebuild the drivers. The method of exporting the driver entry points has been modified. A good sample might be some of the internal port drivers. Panos ________________________________ From: owner-erlang-bugs@REDACTED on behalf of James Hague Sent: Tue 9/21/2004 7:27 AM To: 'Vlad Dumitrescu'; erlang-bugs@REDACTED Subject: RE: Missing beam.dll exports in R9C-2 for Windows > Hmm, they work for me (from the binary distribution)... Maybe > it's something with the source build? Hmmm...I couldn't get my drivers working because of the exports not being found, so I used Borland's tdump utility to view the exports, and they weren't there. Could you send me your beam.dll? James From jamesh@REDACTED Tue Sep 21 17:33:48 2004 From: jamesh@REDACTED (James Hague) Date: Tue, 21 Sep 2004 10:33:48 -0500 Subject: Missing beam.dll exports in R9C-2 for Windows Message-ID: > you need to modify the DRIVER_INIT subroutine and rebuild the > drivers. The method of exporting the driver entry points has > been modified. A good sample might be some of the internal > port drivers. Okay, thank you. Somehow I don't ever recall reading this in the release notes; I must have missed it. James From Panos.Kontakos@REDACTED Tue Sep 21 17:32:47 2004 From: Panos.Kontakos@REDACTED (Panos Kontakos) Date: Tue, 21 Sep 2004 08:32:47 -0700 Subject: Missing beam.dll exports in R9C-2 for Windows Message-ID: I do not recall if it is in the release notes, but I found the hard way in order to rebuild my port drivers. panos ________________________________ From: James Hague [mailto:jamesh@REDACTED] Sent: Tue 9/21/2004 8:33 AM To: Panos Kontakos; Vlad Dumitrescu; erlang-bugs@REDACTED Subject: RE: Missing beam.dll exports in R9C-2 for Windows > you need to modify the DRIVER_INIT subroutine and rebuild the > drivers. The method of exporting the driver entry points has > been modified. A good sample might be some of the internal > port drivers. Okay, thank you. Somehow I don't ever recall reading this in the release notes; I must have missed it. James From jamesh@REDACTED Tue Sep 21 20:25:17 2004 From: jamesh@REDACTED (James Hague) Date: Tue, 21 Sep 2004 13:25:17 -0500 Subject: Missing beam.dll exports in R9C-2 for Windows Message-ID: > Okay, thank you. Somehow I don't ever recall reading this in > the release > notes; I must have missed it. I have this sorted out now. The problem was that the method of dynamically linking in a driver under Windows changed quite a bit. Rather than the driver code referencing symbols in beam.dll and having the DLL loader resolve them, there's now a table of function pointers passed to the driver upon initialization. This is cleaner than the old method, and makes it easier to see what functions a driver can access. erl_driver.h attempts to hide the changes, so you can simply recompile after a few tweaks. But this only works if the driver is written in C. In my case, I used Delphi, so I had to write my own erl_driver equivalent. It's easy enough to change, but it would have been nice to see a more up front mention of the driver linkage changes. Perhaps in R10? James From samuel@REDACTED Mon Sep 27 11:15:10 2004 From: samuel@REDACTED (Samuel Rivas) Date: Mon, 27 Sep 2004 11:15:10 +0200 Subject: pman trace shell bug or initial_call bug Message-ID: <20040927091510.GA24871@crusher.lfcia.pri> The trace shell option of pman is no longer working. Pman hangs forever when you try to trace the shell process. The problem is in pman_shell:find_shell function. It assumes the shell process is the one that has the {initial_call,{shell,evaluator,3}} tuple within its process info, but some change has broken this: a process created with spawn_link will have {erlang, apply, 2} as its initial_call value. I've attached a patch that solves the pman problem adding a dictionary entry so that the shell process can be recognized again, but seems a "dirty" solution. IMO it would be worth restoring the former behaviour of the spawn functions, but it is beyond my knowledge so far :( Any ideas? Best regards. -- Samuel -------------- next part -------------- --- otp_src_R9C-2/lib/stdlib/src/shell.erl 2003-11-27 13:48:30.000000000 +0100 +++ otp_src_R9C-2-patched/lib/stdlib/src/shell.erl 2004-09-24 15:06:47.000000000 +0200 @@ -333,6 +333,7 @@ evaluator(Shell, Bs, Ds) -> init_dict(Ds), + put(shell, yes), case application:get_env(stdlib, restricted_shell) of undefined -> eval_loop(Shell, Bs); --- otp_src_R9C-2/lib/pman/src/pman_shell.erl 2000-08-22 14:07:15.000000000 +0200 +++ otp_src_R9C-2-patched/lib/pman/src/pman_shell.erl 2004-09-24 15:28:05.000000000 +0200 @@ -70,8 +70,13 @@ %% Constants %% +%% XXX: This will not work any longer. Initial call after being spanw_linked is +%% {erlang, apply, 2} so this feature is not usefull at all to identify the +%% shell process, I use the process dictionary either. + %% Initial call function for the shell. Used to find the shell process. -define(SHELL_INITIAL_CALL, {shell, evaluator, 3}). + -define (PMAN_DB, pman_db). % The pman db for trace windows @@ -294,10 +299,15 @@ lists:max(Ack); find_shell([P|Tail], Ack) -> - case erlang:process_info(P, initial_call) of - {initial_call, ?SHELL_INITIAL_CALL} -> - find_shell(Tail, [P|Ack]); - _ -> + case erlang:process_info(P, dictionary) of + {dictionary, Dict} -> + case lists:keysearch(shell, 1, Dict) of + {value, {shell, yes}} -> + find_shell(Tail, [P|Ack]); + _ -> + find_shell(Tail, Ack) + end; + _ -> find_shell(Tail, Ack) end. From geoffw@REDACTED Mon Sep 27 16:43:00 2004 From: geoffw@REDACTED (Geoff White) Date: Mon, 27 Sep 2004 07:43:00 -0700 Subject: Building Erlang R9C2 under OpenBSD 3.6-current (Sept 26,2006) Message-ID: <6.1.0.6.0.20040927070045.0cbb9db0@mail.v-site.net> Greeting. I tried to build R9C2 from the source and ran into a couple of minor problems. When I built it on the bleeding edge OpenBSD. 1) OpenBSD comes preloaded with OpenSSL but it is not where the configure script for R9C2 expects it to be. Furthermore, neither the UNIX readme nor the help from configure --help , list the required option to configure erlang with ssl & crypto support., I stumbled upon the right option by accidentally listing the README.win32, so, you must do ... /configure --with-ssl-includes=/usr/include/openssl --with-ssl-libraries=/usr/lib Make sure you have done a "gmake clean", if you forget to do this, you will never get this to compile,even if you do enter the correct options!! 2) There doesn't seem to be a compile flag for OpenBSD and configure deduces that it is a BSD4_4 system. This creates a problem when compiling the file .../lib/os_mon/c_src/memsup.c. OpenBSD does not use vm/vm_param.h, it used sys/vmmeter.h, like FreeBSD. To get it to compile, I just added this include into the #ifdef as so... #ifdef BSD4_4 #include #include #include /* #include */ #ifdef __FreeBSD__ #include #endif #endif this is not the production solution but it got me going, I leave it to the erlang release crew to figure out the *right thing*. Maybe an __OpenBSD__ flag ;-) 3) Had a minor problem at the very end, with catman. catman doesn't seem to be installed by default under OpenBSD, even though there is a copy in the source distribution under /usr/src/usr.sbin/catman. A quick "make; make install", places catman in /usr/sbin/catman. Unfortunately the script that actually uses this program doesn't know about openbsd, it tests for "BSDness" by testing for /vmunix, which does not exist on OpenBSD, and would set the path to catman incorrectly anyway, the work around is to execute the last command by hand... cd /usr/local/lib/erlang/misc; /usr/sbin/catman -M /usr/local/lib/erlang/man > /dev/null 2>&1 4) A better location to install erlang by default (for OpenBSD) would be /usr/local instead of /usr/local/lib cheers, geoffw