From fritchie@REDACTED Thu May 1 00:53:48 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 30 Apr 2003 17:53:48 -0500 Subject: ets:update_counter/3 taking a looooong time! In-Reply-To: Message of "Mon, 28 Apr 2003 19:43:22 BST." <3EAD764A.6000801@manderp.freeserve.co.uk> Message-ID: <200304302253.h3UMrm3M010168@snookles.snookles.com> >>>>> "pm" == Peter-Henry Mander writes: pm> The attached gives the output of fprof, and the last line pm> indicates that all the time is spent waiting for pm> ets:update_counter/3 to return a new transaction ID to pm> megaco_config:incr_trans_id_counter/1. I've got two theories. 1. Has your Erlang VM's size grown so large that your OS has started paging memory to disk to make room? Or has some other OS process started hogging CPU cycles? Er, well, those are easy guess, and surprisingly easy to forget about if you're distracted by other things. 2. Is your OS platform FreeBSD (or perhaps one of the other *BSDs)? I've been doing some simple ETS benchmarks lately, and I've noticed really weird behavior of ets:delete() (deleting lots of items in a table or deleting an entire table at once) with FreeBSD 4.7-RELEASE and 5.0-RELEASE and Erlang R9B-1. If the table is large (tens of thousands to millions of items), the delete operation can take up to 40 times (!) longer than running on the exact same hardware under a "modern" Linux (Mandrake 9.1 distribution). This was so surprising to me that I tried it on two different machines, a Pentium III laptop and an AMD XP+ desktop. Same thing: FreeBSD was horrible in the delete case, Linux was not. I haven't chased down the final answer (hopefully I'll get back to finding the answer and propose a fix) ... but "gprof" analysis strongly suggests that libc's free() is the culprit. Bummer. -Scott From erlang@REDACTED Thu May 1 09:33:16 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 01 May 2003 08:33:16 +0100 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) References: <200304302253.h3UMrm3M010168@snookles.snookles.com> Message-ID: <3EB0CDBC.9040400@manderp.freeserve.co.uk> Hi Scott, Well, I did a bit of hacking and then realised I should use my brain too! First I replaced megaco_config:incr_trans_id_counter/1 with something I rolled myself, a very simple tail-recursive counter server that didn't use ets. Not because of any scheme or strategy I had, just because I can! And the result was a noticable but minor improvement. The fprof trace now show that blocking occurs on waiting for a reply, but the performance still sucks. The media gateway end now held up the gateway controller beyond 18 concurrent processes instead of 16. Since I haven't managed to conclusively fprof the media gateway (possibly due to lack of experience I'm sorry to say), I decided to see if things improved by adding a 20ms pause between launching each process. Maybe all 2000 processes were trying to access ets at once, effectively an avalanche of processes. The performance sucked a bit less beyond 18 processes, but the call rate was a constant 36 cps all the way up to 2000 concurrent processes maintaining 2000 open calls. So the avalanche hypothesis seemed correct. This figure was a lot less than the 400 cps I get doing a "churning" call cycle running on a dozen threads. Each thread repeatedly does a Megaco add followed by modify and subtract as fast as possible. So I know that this rate is achievable and will remain stable and constant for hours on end without anything going pop! I then tweaked the launching code to introduce a 20ms pause after starting seven processes at a time, seven being a trial-and-error figure. This backs off process launching just enough to prevent the avalanche effet and now I can open up 2000 calls at a rate of 330 cps. Not quite 400 cps, but sufficient and an order of magnitude better! So, not exactly an ets problem (I'm using Linux, not FreeBSD), but I haven't reversed my hacks to the megaco stack to see if there is any significant speed gains through avoiding ets in this situation. Probably not, I've been assured that ets is perfectly fast enough. I hope this little tail helps someone out there, it's not always clearly obvious what's wrong with your code when an process avalanche situation occurs. Ah the joys of massively concurrent systems (-: Pete. Scott Lystig Fritchie wrote: >>>>>>"pm" == Peter-Henry Mander writes: >>>>> > > pm> The attached gives the output of fprof, and the last line > pm> indicates that all the time is spent waiting for > pm> ets:update_counter/3 to return a new transaction ID to > pm> megaco_config:incr_trans_id_counter/1. > > I've got two theories. > > 1. Has your Erlang VM's size grown so large that your OS has started > paging memory to disk to make room? Or has some other OS process > started hogging CPU cycles? > > Er, well, those are easy guess, and surprisingly easy to forget > about if you're distracted by other things. > > 2. Is your OS platform FreeBSD (or perhaps one of the other *BSDs)? > > I've been doing some simple ETS benchmarks lately, and I've noticed > really weird behavior of ets:delete() (deleting lots of items in a > table or deleting an entire table at once) with FreeBSD 4.7-RELEASE > and 5.0-RELEASE and Erlang R9B-1. If the table is large (tens of > thousands to millions of items), the delete operation can take up > to 40 times (!) longer than running on the exact same hardware > under a "modern" Linux (Mandrake 9.1 distribution). > > This was so surprising to me that I tried it on two different > machines, a Pentium III laptop and an AMD XP+ desktop. Same thing: > FreeBSD was horrible in the delete case, Linux was not. > > I haven't chased down the final answer (hopefully I'll get back to > finding the answer and propose a fix) ... but "gprof" analysis > strongly suggests that libc's free() is the culprit. Bummer. > > -Scott > > From fritchie@REDACTED Thu May 1 09:50:39 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 01 May 2003 02:50:39 -0500 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) In-Reply-To: Message of "Thu, 01 May 2003 08:33:16 BST." <3EB0CDBC.9040400@manderp.freeserve.co.uk> Message-ID: <200305010750.h417od3M022187@snookles.snookles.com> >>>>> "pm" == Peter-Henry Mander writes: pm> So, not exactly an ets problem (I'm using Linux, not FreeBSD), but pm> I haven't reversed my hacks to the megaco stack to see if there is pm> any significant speed gains through avoiding ets in this pm> situation. The other thing to try would be to see if changing the table type of 'megaco_config' (IIRC, it's currently 'set') to 'ordered_set'. As I'm discovering, there are significant differences in the performance of those two when table sizes are "large" (10-100K tuples or more) or "small" (less than "large" :-). -Scott From erlang@REDACTED Thu May 1 10:29:32 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 01 May 2003 09:29:32 +0100 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) References: <200305010750.h417od3M022187@snookles.snookles.com> Message-ID: <3EB0DAEC.1050000@manderp.freeserve.co.uk> Thanks for the tip Scott. Considering that the megaco testing rig I'm building will need to open that many calls, it's a good thing to know. I'll do some comparisons when the scope of test reaches that magnitude. A quick grep reveals that ets defaults are used in otp_src_R9B-1/lib/megaco/src/engine/*.erl Maybe a bit more profiling and statistics collecting could improve an already stunning protocol stack? (-: Pete. Scott Lystig Fritchie wrote: > > The other thing to try would be to see if changing the table type of > 'megaco_config' (IIRC, it's currently 'set') to 'ordered_set'. As I'm > discovering, there are significant differences in the performance of > those two when table sizes are "large" (10-100K tuples or more) or > "small" (less than "large" :-). > > -Scott > > From ulf.wiger@REDACTED Thu May 1 11:23:03 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Thu, 1 May 2003 11:23:03 +0200 Subject: Network partition and OTP References: <2A6AC44C-7A7F-11D7-BDED-000393B64312@acm.org> Message-ID: <004b01c30fc3$537c4bc0$fd7a40d5@telia.com> Global has a "deconflict" hook for globally registered names. The default behaviour is to pick one of the conflicting processes and kill it; another standard option is to simply unregister the name. The locker (my contrib) performs a lock merge and forcefully releases locks that cannot be automatically merged (e.g. two different processes have an exclusive lock on the same resource. Mnesia will detect partitioned networks, but will not do anything to resolve the situation automatically (there is no automatic solution that works in all cases.) Dist_ac will not try to resolve partitioned networks, so if you use dist_ac, you have to restart all nodes except one. The problem of partitionet networks is really difficult, and as Asko explains, we address it in AXD301 with the 'dist_auto_connect once' option. This also gives some release from the general problem that a system that automatically reconnects from a partitionet net is quite unstable during the merge process. ?/Uffe ----- Original Message ----- From: Reto Kramer To: erlang-questions@REDACTED Cc: etxuwig@REDACTED Sent: den 29 april 2003 22:14 Subject: Network partition and OTP I'm looking for information on how OTP behaves when the network between nodes fails, and reconnects (nodes stay up all the time). ** Question 1 ** In particular the behavior of "global", the "distributed application controller" and Ulf's "locker" (contrib page) is what I'd like to understand better in network partition/reconnect scenarios. I've found references to work of Thomas Arts et al [1,2] and Ulf Wiger [3] and snippets here and there, but it would be most helpful to me if an OTP wizard could illuminate this topic comprehensively. For "global" one has to expect "name conflict" errors when the network comes back together. By extension I guess the same applies to the application controller (via it's use of global). Not sure about Ulf's locker. Using Ulf's release handling tutorial example, I can generate a naming conflict and observe what happens (start n1 then n2 (owner), suspend erl process that runs n2, dist fails over to n1, then resume erl that runs n2, ping n1 -> naming conflict, kills dist_server on n2, supervisor restarts n2 which takes over from n1 - takeover handshake not logged - does it happen?). =INFO REPORT==== 29-Apr-2003::12:59:39 === global: Name conflict terminating {dist_server,<1930.59.0>} ** Question 2 ** is there any risk of loosing messages that were buffered by the dist_server instance just before it got killed? I'm worried that while the global:register etc call are atomic across nodes [docs and 2], a potential client (client of dist_server I mean here) is not part of the atomic conflict resolution/re-registering process. I noticed the "relay" function in Ulf's release handling tutorial [3], but am not sure it kicks in when global detects the naming conflict upon reconnect - I guess not, correct? ** Question 3 ** - somewhat related to the above: Is there any library support for "majority voting" and/or "lease management" in OTP that I've not discovered yet? In particular I'm interested in rejecting a global:register/2 if the process calling the function is not in a node majority-set. Thanks, - Reto References: Thomas Arts et al [1,2], Ulf Wiger [3] [1] http://www.ericsson.com/cslab/~thomas/publ2.shtml (resource locker case study) [2] http://www.erlang.org/ml-archive/erlang-questions/200107/msg00031.html (christian paper) [3] (OTP release handling tutorial by Ulf) - was on the newsgroup, cannot find ref right now ______________________ There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. C.A.R. Hoare 1980 Turing Award Lecture -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.geib@REDACTED Thu May 1 16:38:03 2003 From: mark.geib@REDACTED (mark.geib@REDACTED) Date: 01 May 2003 08:38:03 -0600 Subject: problem using bif now(). Message-ID: <1051799883.1436.30.camel@casmgr-pu.util.uplink> I am writing my first production erlang program and need to measure the duration of calls hitting a server. I am using the bif now() to get the mega-seconds, seconds and micro-seconds from a base time reference. The problem is this. The following code fragment causes the CPU useage to continually increase, eventually consuming all the CPU on the machine. {MSec,Sec,MicoSec} = erlang:now(), Read_time = (Msec*1000000)+Sec+(MicoSec/1000000), but the following does not have the problem. {MSec,Sec,MicoSec} = erlang:now(), Read_time = Sec+(MicoSec/1000000), However, now about every 12 days the seconds values wraps back to zero. Is this a bug that should be reported, or is there a problem in my code.? I am running erlang R9B-0 on Linux Redhat 7.3. -- Cheyenne Software Engineering -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part URL: From peter@REDACTED Thu May 1 17:00:30 2003 From: peter@REDACTED (peter@REDACTED) Date: Thu, 1 May 2003 16:00:30 +0100 (BST) Subject: problem using bif now(). In-Reply-To: <1051799883.1436.30.camel@casmgr-pu.util.uplink> References: <1051799883.1436.30.camel@casmgr-pu.util.uplink> Message-ID: <21342.149.254.120.136.1051801230.squirrel@www.lundata.se> 1 year is about 31 000 000 secs. 1/31 of a year seems to be 12 days. All seems ok to me... /Peter > I am writing my first production erlang program and need to measure the > duration of calls hitting a server. I am using the bif now() to get the > mega-seconds, seconds and micro-seconds from a base time reference. > > The problem is this. The following code fragment causes the CPU useage > to continually increase, eventually consuming all the CPU on the > machine. > > {MSec,Sec,MicoSec} = erlang:now(), > Read_time = (Msec*1000000)+Sec+(MicoSec/1000000), > > but the following does not have the problem. > > > {MSec,Sec,MicoSec} = erlang:now(), > Read_time = Sec+(MicoSec/1000000), > > However, now about every 12 days the seconds values wraps back to zero. > > Is this a bug that should be reported, or is there a problem in my > code.? > > I am running erlang R9B-0 on Linux Redhat 7.3. > > -- > > Cheyenne Software Engineering From mark.geib@REDACTED Thu May 1 17:05:20 2003 From: mark.geib@REDACTED (mark.geib@REDACTED) Date: 01 May 2003 09:05:20 -0600 Subject: problem using bif now(). In-Reply-To: <21342.149.254.120.136.1051801230.squirrel@www.lundata.se> References: <1051799883.1436.30.camel@casmgr-pu.util.uplink> <21342.149.254.120.136.1051801230.squirrel@www.lundata.se> Message-ID: <1051801519.1436.37.camel@casmgr-pu.util.uplink> Peter, I agree, the values returned by now() are correct. The problem is that if I use the mega-second value in my calculation then the program uses more and more cpu as it runs. Mark. On Thu, 2003-05-01 at 09:00, peter@REDACTED wrote: > 1 year is about 31 000 000 secs. 1/31 of a year seems to be 12 days. > All seems ok to me... > > /Peter > > > I am writing my first production erlang program and need to measure the > > duration of calls hitting a server. I am using the bif now() to get the > > mega-seconds, seconds and micro-seconds from a base time reference. > > > > The problem is this. The following code fragment causes the CPU useage > > to continually increase, eventually consuming all the CPU on the > > machine. > > > > {MSec,Sec,MicoSec} = erlang:now(), > > Read_time = (Msec*1000000)+Sec+(MicoSec/1000000), > > > > but the following does not have the problem. > > > > > > {MSec,Sec,MicoSec} = erlang:now(), > > Read_time = Sec+(MicoSec/1000000), > > > > However, now about every 12 days the seconds values wraps back to zero. > > > > Is this a bug that should be reported, or is there a problem in my > > code.? > > > > I am running erlang R9B-0 on Linux Redhat 7.3. > > > > -- > > > > Cheyenne Software Engineering -- Cheyenne Software Engineering -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part URL: From martin@REDACTED Thu May 1 19:58:08 2003 From: martin@REDACTED (martin j logan) Date: 01 May 2003 12:58:08 -0500 Subject: Redhat 9 Message-ID: <1051811888.1226.13.camel@berimbau> All, I was wondering if anyone has built R9 on RedHat 9. I have the disks for the OS sitting here in front of me and would like to know if I should expect any problems building R9. If so I will hold off on installing this OS until I have more available time. Thanks, Martin From fritchie@REDACTED Thu May 1 20:27:43 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 01 May 2003 13:27:43 -0500 Subject: Redhat 9 In-Reply-To: Message of "01 May 2003 12:58:08 CDT." <1051811888.1226.13.camel@berimbau> Message-ID: <200305011827.h41IRh3M025229@snookles.snookles.com> I don't have a RedHat 9 box around, but I do have a Mandrake 9.1 box. I discovered that Javier G?mez Sierras's advice on this list, back in July 2002, was still (mostly) true: I needed to install the "libtermcap2" RPM in order to get "beam" to link correctly. (Without it, termcap functions such as tgetent(3X) were missing.) Javier's message was about Mandrake 8.1; the dependency mentioned there was on "libtermcap2-devel". Oh, you'll need to run the top-level "configure" script *after* that library is installed. I ran into no other problems compiling & installing. -Scott From cpressey@REDACTED Thu May 1 20:28:53 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 01 May 2003 13:28:53 -0500 Subject: problem using bif now(). In-Reply-To: <1051801519.1436.37.camel@casmgr-pu.util.uplink> References: <1051799883.1436.30.camel@casmgr-pu.util.uplink> <21342.149.254.120.136.1051801230.squirrel@www.lundata.se> <1051801519.1436.37.camel@casmgr-pu.util.uplink> Message-ID: <20030501132853.7dcaf285.cpressey@catseye.mb.ca> On 01 May 2003 09:05:20 -0600 mark.geib@REDACTED wrote: > > > The problem is this. The following code fragment causes the CPU > > > useage to continually increase, eventually consuming all the CPU > > > on the machine. > > > > > > {MSec,Sec,MicoSec} = erlang:now(), > > > Read_time = (Msec*1000000)+Sec+(MicoSec/1000000), No idea, sorry. But out of curiousity: - MSec and Msec are different variables (I assume that's a typo) - what happens if you use floating point (MSec*1.0e+6) ? I use bigints fairly extensively and I've never noticed it hogging CPU, but then again, I've never really looked for it specifically... -Chris From jeinhorn@REDACTED Thu May 1 20:59:17 2003 From: jeinhorn@REDACTED (Jeff Einhorn) Date: 01 May 2003 13:59:17 -0500 Subject: Redhat 9 troubles. Message-ID: <1051815557.27147.15.camel@dhcp-lom-195-14.futuresource.com> I'm having some trouble compiling erlang R9B-1 on Redhat 9. I have exported the LANG=en_US variable so that I can avoid the perl problems, but I should also get the following error later in the compile. /usr/local/src/otp_src_R9B-1/erts/obj.instr.beam/i686-pc-linux-gnu/sys.o(.text+0x2564): In function `sys_preloaded': sys/unix/sys.c:3236: undefined reference to `pre_loaded' collect2: ld returned 1 exit status make[2]: *** [/usr/local/src/otp_src_R9B-1/bin/i686-pc-linux-gnu/beam.instr] Error 1 make[2]: Leaving directory `/usr/local/src/otp_src_R9B-1/erts/emulator' make[1]: *** [instr] Error 2 make[1]: Leaving directory `/usr/local/src/otp_src_R9B-1/erts/emulator' make: *** [emulator.instr] Error 2 thanks for your help, -jeff einhorn From mark.geib@REDACTED Thu May 1 21:06:54 2003 From: mark.geib@REDACTED (mark.geib@REDACTED) Date: 01 May 2003 13:06:54 -0600 Subject: problem using bif now(). In-Reply-To: <20030501132853.7dcaf285.cpressey@catseye.mb.ca> References: <1051799883.1436.30.camel@casmgr-pu.util.uplink> <21342.149.254.120.136.1051801230.squirrel@www.lundata.se> <1051801519.1436.37.camel@casmgr-pu.util.uplink> <20030501132853.7dcaf285.cpressey@catseye.mb.ca> Message-ID: <1051816014.4591.3.camel@casmgr-pu.util.uplink> Chris, It's a typo, sorry. I would not be so concerned if the cpu usage was constant, but it just keeps increasing until the machine is swamped. I did try floating point, no diffenence. Mark. On Thu, 2003-05-01 at 12:28, Chris Pressey wrote: > On 01 May 2003 09:05:20 -0600 > mark.geib@REDACTED wrote: > > > > > The problem is this. The following code fragment causes the CPU > > > > useage to continually increase, eventually consuming all the CPU > > > > on the machine. > > > > > > > > {MSec,Sec,MicoSec} = erlang:now(), > > > > Read_time = (Msec*1000000)+Sec+(MicoSec/1000000), > > No idea, sorry. But out of curiousity: > - MSec and Msec are different variables (I assume that's a typo) > - what happens if you use floating point (MSec*1.0e+6) ? > > I use bigints fairly extensively and I've never noticed it hogging CPU, > but then again, I've never really looked for it specifically... > > -Chris -- Cheyenne Software Engineering -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part URL: From kent@REDACTED Thu May 1 22:30:18 2003 From: kent@REDACTED (Kent Boortz) Date: 01 May 2003 22:30:18 +0200 Subject: Redhat 9 troubles. In-Reply-To: <1051815557.27147.15.camel@dhcp-lom-195-14.futuresource.com> References: <1051815557.27147.15.camel@dhcp-lom-195-14.futuresource.com> Message-ID: Jeff Einhorn writes: > I'm having some trouble compiling erlang R9B-1 on Redhat 9. I have > exported the LANG=en_US variable so that I can avoid the perl problems, > but I should also get the following error later in the compile. > > /usr/local/src/otp_src_R9B-1/erts/obj.instr.beam/i686-pc-linux-gnu/sys.o(.text+0x2564): In function `sys_preloaded': > sys/unix/sys.c:3236: undefined reference to `pre_loaded' > collect2: ld returned 1 exit status > make[2]: *** > [/usr/local/src/otp_src_R9B-1/bin/i686-pc-linux-gnu/beam.instr] Error 1 > make[2]: Leaving directory `/usr/local/src/otp_src_R9B-1/erts/emulator' > make[1]: *** [instr] Error 2 > make[1]: Leaving directory `/usr/local/src/otp_src_R9B-1/erts/emulator' > make: *** [emulator.instr] Error 2 Did you do this in a new clean unpacked source tree? If not one suggestion sent to the Wings3D list was to do (in bash) % export LANG=C % rm configure.cache % make clean % ./configure % make % make install You can find a suggestion that includes editing "make_preload" at http://www.erlang-projects.org/Public/documentation/tutorials/building_r9b-0_on_li/view Yet another suggestion is to upgrade the Perl version http://www.erlang.org/ml-archive/erlang-questions/200302/msg00357.html Maybe it would be easier if someone good at Perl and the Perl unicode changes could help us by pointing out the few lines in the Perl scripts that are not compatible with different language versions and what to do about it. Changing to "use bytes" is not the way to go, this will break the build on lots of systems with older Perl installations. We could of course let configure find out if the Perl version supports "use bytes" or not and preprocess the Perl scripts, kent From jeinhorn@REDACTED Thu May 1 22:46:07 2003 From: jeinhorn@REDACTED (Jeff Einhorn) Date: 01 May 2003 15:46:07 -0500 Subject: Redhat 9 troubles. In-Reply-To: References: <1051815557.27147.15.camel@dhcp-lom-195-14.futuresource.com> Message-ID: <1051821967.5204.4.camel@dhcp-lom-195-14.futuresource.com> export LANG=en_US and installing libtermcap2 does allow erlang to compile on redhat 9. thanks, -jeff From cpressey@REDACTED Thu May 1 21:03:02 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 01 May 2003 14:03:02 -0500 Subject: type safety Message-ID: <20030501140302.436a3c04.cpressey@catseye.mb.ca> I had the following thought about type safety: In order to both hide the structure of a data type (so that one can later change the implementation without breaking anything) and to allow the data type to be matched in patterns (in cases and function heads and so forth,) I think one needs to both partially define the data type, and partially leave it undefined. Not as weird as it sounds - e.g. if you have a queue, you could document it like: "the structure of the queue data type is {queue, XXX} where XXX is undefined outside the queue module." This gives the data type implementor the opportunity to change the implementation, but also lets the code that uses the data type distinguish it from other data types. I think many Erlang programmers probably do do this in one form or another, but it's not systemized - it might be worth considering for the next time the programming rules (specifically 3.11) are updated. -Chris From james@REDACTED Fri May 2 05:31:56 2003 From: james@REDACTED (James Hague) Date: Thu, 1 May 2003 22:31:56 -0500 Subject: Fix for A=<<1>> Message-ID: <3EB1A05C.31699.BBB37@localhost> That the start of "A=<<1>>" is incorrectly tokenized into A, =<, < has always bothered me, so here's a patch for erl_scan.erl that fixes it. Special casing this in the scanner is a bit grotty, but it's better than having a special case in the documentation. I'm posting this here instead of erlang-patches to see if anyone can come up with a reason why this is a bad idea (besides being an odd special case). (Apologies for the manual patch, BTW.) James After: %% Punctuation characters and operators, first recognise multiples. insert: %% The first clause looks for "=<<" and splits it into "=","<<" so %% matches like "=<<1>>" aren't tokenized as "=<","<". scan1([$=,$<,$<|Cs], Toks, Pos) -> scan1(Cs, [{'<<',Pos},{'=',Pos}|Toks], Pos); From youki-k@REDACTED Fri May 2 04:40:22 2003 From: youki-k@REDACTED (Youki Kadobayashi) Date: Fri, 2 May 2003 11:40:22 +0900 Subject: crypto under FreeBSD 4.8 etc. Message-ID: <20030502114022.3197b6b0.youki-k@is.aist-nara.ac.jp> Hi, I found that simply #defining OPENSSL_DES_LIBDES_COMPATIBILITY is not enough to make crypto functions work. I verified the following patch under FreeBSD-4.8. It would be applicable to other systems with newer versions of OpenSSL. NB: The patch to Makefile is crude hack and it should be replaced with more appropriate tests against OpenSSL versions.. Anyway here it goes... -- Youki Kadobayashi, Ph.D. Graduate School of Information Science Nara Institute of Science and Technology *** otp_src_R9B-1/lib/crypto/c_src/crypto_drv.c.ports Fri May 2 09:43:00 2003 --- otp_src_R9B-1/lib/crypto/c_src/crypto_drv.c Fri May 2 11:01:10 2003 *************** *** 208,216 **** cfs.SHA1_Init = driver_dl_sym(lib_handle, "SHA1_Init"); cfs.SHA1_Update = driver_dl_sym(lib_handle, "SHA1_Update"); cfs.SHA1_Final = driver_dl_sym(lib_handle, "SHA1_Final"); ! cfs.des_set_key = driver_dl_sym(lib_handle, "des_set_key"); ! cfs.des_ncbc_encrypt = driver_dl_sym(lib_handle, "des_ncbc_encrypt"); ! cfs.des_ede3_cbc_encrypt = driver_dl_sym(lib_handle, "des_ede3_cbc_encrypt"); /* Check that all pointer where initialized */ for (i = 0; i < sizeof(crypto_funcs)/sizeof(void*); i++) { --- 208,216 ---- cfs.SHA1_Init = driver_dl_sym(lib_handle, "SHA1_Init"); cfs.SHA1_Update = driver_dl_sym(lib_handle, "SHA1_Update"); cfs.SHA1_Final = driver_dl_sym(lib_handle, "SHA1_Final"); ! cfs.des_set_key = driver_dl_sym(lib_handle, "_ossl_old_des_set_key"); ! cfs.des_ncbc_encrypt = driver_dl_sym(lib_handle, "_ossl_old_des_ncbc_encrypt"); ! cfs.des_ede3_cbc_encrypt = driver_dl_sym(lib_handle, "_ossl_old_des_ede3_cbc_encrypt"); /* Check that all pointer where initialized */ for (i = 0; i < sizeof(crypto_funcs)/sizeof(void*); i++) { *** otp_src_R9B-1/lib/crypto/c_src/i386-unknown-freebsd4.8/Makefile.orig Fri May 2 09:43:28 2003 --- otp_src_R9B-1/lib/crypto/c_src/i386-unknown-freebsd4.8/Makefile Fri May 2 10:57:47 2003 *************** *** 98,103 **** --- 98,118 ---- -u _des_ncbc_encrypt \ -u _des_ede3_cbc_encrypt else + ifeq ($(findstring freebsd,$(TARGET)),freebsd) + ELIBCRYPTO_UNDEFS = \ + -u CRYPTO_set_mem_functions \ + -u MD5 \ + -u MD5_Init \ + -u MD5_Update \ + -u MD5_Final \ + -u SHA1 \ + -u SHA1_Init \ + -u SHA1_Update \ + -u SHA1_Final \ + -u _ossl_old_des_set_key \ + -u _ossl_old_des_ncbc_encrypt \ + -u _ossl_old_des_ede3_cbc_encrypt + else ELIBCRYPTO_UNDEFS = \ -u CRYPTO_set_mem_functions \ -u MD5 \ *************** *** 111,116 **** --- 126,132 ---- -u des_set_key \ -u des_ncbc_encrypt \ -u des_ede3_cbc_encrypt + endif endif # ---------------------------------------------------- From DANIESC.SCHUTTE@REDACTED Fri May 2 10:33:50 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Fri, 02 May 2003 10:33:50 +0200 Subject: Extreme programming - module template Message-ID: Morning all - I would like to present and ask for suggestions on an updated template that we want to introduce in the extreme programming environment - having had a look at Dunit (delphi) and Junit (java) and a few others - I started thinking of extending the current stuff we have. All suggestions welcome :) Explanation: local -> relates to testing the module functions. integration -> relates to testing integration with all "lower level" modules. scenario -> relates to scenario testing (mostly only "application level modules"). ##################################################################################### The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy and copies. ##################################################################################### -------------- next part -------------- A non-text attachment was scrubbed... Name: template.erl Type: application/octet-stream Size: 6185 bytes Desc: not available URL: From cb47@REDACTED Fri May 2 12:41:40 2003 From: cb47@REDACTED (Clara Benac Earle) Date: Fri, 02 May 2003 11:41:40 +0100 Subject: proyecto Erlang References: <3E8AB39F.4192909C@ukc.ac.uk> Message-ID: <3EB24B64.DCA8470C@ukc.ac.uk> Dear Victor, Thank you for the comments and all the additional information. We are working on a new version of the proposal and we hope to send it to you as soon as possible. Besides, I would like you ask you something. On your email you mention: > In addition, as you suggested, I asked our private partner (the cable > network operator) if they were interested in taking part in this > project; even though they are reluctant as becoming an active part of > the project, they agreed on signing a letter of interest on the > project and offering resources for experimentation. We were not really sure about what "offering resources for experimentation" means. Could you be more specific so that we can put it in the proposal? Thank you, Clara From cb47@REDACTED Fri May 2 12:55:35 2003 From: cb47@REDACTED (Clara Benac Earle) Date: Fri, 02 May 2003 11:55:35 +0100 Subject: Email to the wrong list Message-ID: <3EB24EA7.4639604@ukc.ac.uk> Sorry, I sent an email which was not intented for this list. Please ignore it. clara From etxuwig@REDACTED Fri May 2 13:47:36 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 2 May 2003 13:47:36 +0200 (MEST) Subject: Fix for A=<<1>> In-Reply-To: <3EB1A05C.31699.BBB37@localhost> Message-ID: I quickly glanced at erl_scan.erl to see if my instinctive objection to your patch was correct, and it was... but leading to a further question/complaint: erl_scan.erl is designed to be reentrant. Thus, your code may not always work, since it might happen that the split into chunks will occur right inside "=<<". What I observed in erl_scan.erl is that this kind of cheating is already done when matching "<<", ">>", ">=", "->", etc. pre_escape/2 does things the hard (reentrant) way, but e.g. scan_escape/2 cheats. Or am I overlooking some magic code snippet that guarantees that there are always enough bytes in the scan buffer to ensure that the right function clause matches? (BTW, xmerl_scan.erl, which I wrote, suffers from the same problem; matching multiples in the function head is great for readability, but not if you want your scanner to be reentrant.) /Uffe On Thu, 1 May 2003, James Hague wrote: >That the start of "A=<<1>>" is incorrectly tokenized into >A, =<, < has always bothered me, so here's a patch for >erl_scan.erl that fixes it. Special casing this in the >scanner is a bit grotty, but it's better than having a >special case in the documentation. > >I'm posting this here instead of erlang-patches to see if >anyone can come up with a reason why this is a bad idea >(besides being an odd special case). > >(Apologies for the manual patch, BTW.) > >James > > >After: > >%% Punctuation characters and operators, first recognise multiples. > >insert: > >%% The first clause looks for "=<<" and splits it into "=","<<" so >%% matches like "=<<1>>" aren't tokenized as "=<","<". >scan1([$=,$<,$<|Cs], Toks, Pos) -> > scan1(Cs, [{'<<',Pos},{'=',Pos}|Toks], Pos); > > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From jamesh@REDACTED Fri May 2 16:00:46 2003 From: jamesh@REDACTED (James Hague) Date: Fri, 2 May 2003 09:00:46 -0500 Subject: Fix for A=<<1>> Message-ID: >What I observed in erl_scan.erl is that this kind of >cheating is already done when matching "<<", ">>", ">=", >"->", etc. I thought the same thing, and I wouldn't have even tried to special-case "=<<" if there already hadn't been support in the same function for multi-character tokens like "=<". But I agree with your concern, and I'm curious how those are handled properly by erl_scan. From erlang@REDACTED Fri May 2 17:05:12 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 02 May 2003 16:05:12 +0100 Subject: multiprocessor SMP support? Message-ID: <3EB28928.1030708@manderp.freeserve.co.uk> Hi Gurus, I wish to know if launching multiple Erlang nodes would take advantage of a SMP server class PC? Will a two processor PC only require two nodes? Will Linux automatically assign each node to each available processor? Does message passing between these nodes suffer any bandwidth impediment compared to message passing between processes within a single node? Am I asking too many questions on a Friday afternoon? Pete. On Sun, 15 Dec 2002, Ulf Wiger wrote: ... << snip >> I think it's interesting to be able to combine multi-CPU support with many thousand processes. One use that comes to mind would be to separate communication and control (where there could be thousands of control threads), or control and Operation and Maintenance, while still running on the same processor board. Essentially, coarse-grained load sharing without many of the hassles of distributed computing (loosely coupled computers on a slow communication medium.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From mikpe@REDACTED Fri May 2 17:37:25 2003 From: mikpe@REDACTED (mikpe@REDACTED) Date: Fri, 2 May 2003 17:37:25 +0200 Subject: multiprocessor SMP support? In-Reply-To: <3EB28928.1030708@manderp.freeserve.co.uk> References: <3EB28928.1030708@manderp.freeserve.co.uk> Message-ID: <16050.37045.466110.47535@gargle.gargle.HOWL> Peter-Henry Mander writes: > Hi Gurus, > > I wish to know if launching multiple Erlang nodes would take advantage > of a SMP server class PC? Well, communication between the two nodes _will_ be faster if they run on the same SMP box. > Will Linux automatically assign each node to each available > processor? It depends on what other Linux processes the system is running. If you want to be sure, run a recent kernel with "CPU affinity" support. Then you can bind those nodes to different CPUs. You'll need a 2.4.18 or newer redhat kernel, a 2.4.21 or newer standard kernel, or a current 2.5 development kernel for this. (Other vendors may have it too, I wouldn't know.) From luke@REDACTED Fri May 2 17:37:35 2003 From: luke@REDACTED (Luke Gorrie) Date: 02 May 2003 17:37:35 +0200 Subject: Extreme programming - module template In-Reply-To: References: Message-ID: "DANIESC SCHUTTE" writes: > I would like to present and ask for suggestions on an updated > template that we want to introduce in the extreme programming > environment - having had a look at Dunit (delphi) and Junit (java) > and a few others - I started thinking of extending the current stuff > we have. All suggestions welcome :) It looks really bureaucratic to me, with all the boilerplate. (Sorry, you asked! :-)) I also think that is a lot of real code to be including in a template (e.g. module_test/1). I think you should Refactor as much as possible into a library, so you can have it Once-And-Only-Once in the source code and change it more easily. Templates are really copy-and-paste programming. You could also write the version/0 function as a library routine if you like. It could call YourModule:module_info(attributes) to extract the 'revision' attribute, and then parse that. Cheers, Luke From vances@REDACTED Fri May 2 18:45:43 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 2 May 2003 12:45:43 -0400 Subject: multiprocessor SMP support? In-Reply-To: <16050.37045.466110.47535@gargle.gargle.HOWL> References: <3EB28928.1030708@manderp.freeserve.co.uk> <16050.37045.466110.47535@gargle.gargle.HOWL> Message-ID: <20030502164543.GO89739@frogman.motivity.ca> The distribution module is replacable. For example there is an SSL version in the SSL application. There is a user contribution for Unix domain sockets. It would be interesting to see a new distribution module written to use a linked in driver which would be designed to maximize performance in an SMP system. Using shared memory or some such mechanism instead of the TCP/IP stack it should be possible to really speed things up. -Vance From nhead@REDACTED Sat May 3 12:50:30 2003 From: nhead@REDACTED (Nigel Head) Date: Sat, 3 May 2003 12:50:30 +0200 Subject: Problem with R9B-1 & W2K ?? Message-ID: <20030503125030.365d0bf4.nhead@houbits.com> [Novice warning ON] I have problems with erlang R9B-1 (binary install) on my w2k system: When starting 'erlang with toolbar' the toolbar just hangs. If I then start one of the toolbar apps (like "pman:start().") by hand in the shell then it recovers and all is fine until I stop pman again, at which time the whole toolbar vanishes with a flood of error messages. Starting without the toolbar seems to be fine, as far as this novice can tell. R9B-0 (binary) does not show these problems. I don't know enough about erlang and/or OTP to figure if this is a setup problem (this is my first contact to erlang, ever) so I plan to retreat to using R9B-0 for now, unless somebody tells me it has severe flaws; I looked at the change history for -1 but I'm not yet able to judge the significance of the changes. I'm also not in a position to figure whether the syptoms are significant of a fundamental problem or just a nuisance (I don't actually *need* the toolbar after all, but the point of my looking into erlang is to learn about the synchronisation and distribution of processing, which seems to intersect with these symptoms uncomfortably closely). Is this a known problem, or something that bears further investigation (in which case I will install R9B-1 again if someone tells me what to do to gather useful information)? Regards, N. From tony@REDACTED Sat May 3 17:43:16 2003 From: tony@REDACTED (Tony Rogvall) Date: Sat, 03 May 2003 17:43:16 +0200 Subject: zlib - added to jungerl Message-ID: <3EB3E394.3060605@rogvall.com> Hi all. Just wanted to push for the zlib interface added to jungerl. It can be as simple as writing zlib:compress("Hello world") or you can use the zlib basic functions. Have fun and compress your data :-) /Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From sean.hinde@REDACTED Sat May 3 23:44:28 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Sat, 3 May 2003 22:44:28 +0100 Subject: zlib - added to jungerl In-Reply-To: <3EB3E394.3060605@rogvall.com> Message-ID: <6AACA52D-7DB0-11D7-8C05-000393A45C3C@mac.com> > Just wanted to push for the zlib interface added to jungerl. > This is what I love best about the Erlang community - Just as soon as you set down to start making some essential library for a project then someone goes and announces that they've finished it and open sources it :-) Thanks Tony, this just saved my project from a major slippage Sean From raimo.niskanen@REDACTED Mon May 5 08:26:15 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Mon, 05 May 2003 08:26:15 +0200 Subject: problem using bif now(). References: <1051801519.1436.37.camel@casmgr-pu.util.uplink>, <20030501132853.7dcaf285.cpressey@catseye.mb.ca>, <1051816014.4591.3.camel@casmgr-pu.util.uplink> Message-ID: Give us some more code (to see if something else has gone wrong), and some more figures, like how often the calculation is done, how fast the machine gets swamped (or rather what 'top' reports after how long time)... / Raimo Niskanen, Erlang/OTP, Ericsson AB mark.geib@REDACTED wrote: > Chris, > > It's a typo, sorry. > > I would not be so concerned if the cpu usage was constant, but it just > keeps increasing until the machine is swamped. > > I did try floating point, no diffenence. > > Mark. > > On Thu, 2003-05-01 at 12:28, Chris Pressey wrote: > >>On 01 May 2003 09:05:20 -0600 >>mark.geib@REDACTED wrote: >> >> >>>>>The problem is this. The following code fragment causes the CPU >>>>>useage to continually increase, eventually consuming all the CPU >>>>>on the machine. >>>>> >>>>>{MSec,Sec,MicoSec} = erlang:now(), >>>>>Read_time = (Msec*1000000)+Sec+(MicoSec/1000000), >>>> >>No idea, sorry. But out of curiousity: >>- MSec and Msec are different variables (I assume that's a typo) >>- what happens if you use floating point (MSec*1.0e+6) ? >> >>I use bigints fairly extensively and I've never noticed it hogging CPU, >>but then again, I've never really looked for it specifically... >> >>-Chris > From raimo.niskanen@REDACTED Mon May 5 09:12:55 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Mon, 05 May 2003 09:12:55 +0200 Subject: Fix for A=<<1>> References: Message-ID: I have just rewritten the scanner for R9C to make it twice as fast, and the reentrancy issues you worry about has been solved in that rewrite (presumably). About the '=<<' problem I was just about to fix that when I checked with the other guys, and this is the problem. How should the scanner interpret '=<<<' as in "if A =< <<1,2>>" without spaces; that's easy: '=<' '<<'. But since sub-binaries are allowed when constructing: how about '=<<<<<' as in "if A =< << <<1>>/binary, 2>>", then one can see that the scanning of '=<<' depends on if the number of '<' characters following is odd or even, so the scanner might have to scan infinitely ahead. A look ahead scan of limited small length would be fine, but this is ugly. / Raimo Niskanen, Erlang/OTP, Ericsson AB James Hague wrote: >>What I observed in erl_scan.erl is that this kind of >>cheating is already done when matching "<<", ">>", ">=", >>"->", etc. > > > I thought the same thing, and I wouldn't have even tried to special-case > "=<<" if there already hadn't been support in the same function for > multi-character tokens like "=<". But I agree with your concern, and I'm > curious how those are handled properly by erl_scan. From etxuwig@REDACTED Mon May 5 10:49:10 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 5 May 2003 10:49:10 +0200 (MEST) Subject: Fix for A=<<1>> In-Reply-To: Message-ID: On Mon, 5 May 2003, Raimo Niskanen wrote: >But since sub-binaries are allowed when constructing: how >about '=<<<<<' as in "if A =< << <<1>>/binary, 2>>", then >one can see that the scanning of '=<<' depends on if the >number of '<' characters following is odd or even, so the >scanner might have to scan infinitely ahead. A look ahead >scan of limited small length would be fine, but this is >ugly. I'm not sure what the upper limit would be for a sequence of '<' symbols in a program making any qlaims of still being useable (one of course has to take into account generated code, which is usually less readable than hand-written code.) Perhaps a stupid question, but, so what if the scanner looks ahead and breaks for safety at, say, 1000 tokens? This won't cause any big problems as far as memory is concerned, and at least I find it difficult to envision a program that would break because of this, that is still worthy of being compiled. The following syntactically correct expression would no longer work (line breaks added for nettiquette compliance). I'm prepared to say "so what?": A =<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<1>> /binary,2>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> /binary>>. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From DANIESC.SCHUTTE@REDACTED Mon May 5 11:36:44 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Mon, 05 May 2003 11:36:44 +0200 Subject: Extreme programming - module template Message-ID: I surely did ask :) - and your argument holds true. My reasoning: Having the stories / metaphors and spikes in "code" presents other coders with "options" that were visited as well as the description of this specific story/sub-story. I like the idea of refactoring all of the stuff into a library - I am just not clear on the how :) ? Short description: 1. Translate ISO8583 Message 1.1 Xlate_postbridge_in 1.1.1 Xlate_0200_100_message 1.1.2 Xlate_0200_101_message 1.1.1 and 1.1.2 only does translations of SPECIFIC MESSAGE types - but the test check for invalid routing and other related stuff. (Local Tests). 1.1 selects the translation to use (1.1.1 or 1.1.2) so it does local as well as integration (does it work with 1.1.1) 1 does n scenario test (person X with card Y rocks up at ATM Z doing transaction A for value B with pin C where the pin is invalid :) ). The idea being the following - I'm trying to figure how to put ALL these tests (and some of them can be really "silly") inside of a library application. Since we are introducing various costing schedules / payment schemes etc and non ISO8583 transactions - the whole system needs to be "retested" whenever a new "variable" is introduced. I'm just afraid from a practical perspective - if the tests are not appended to the bottom of the code - it's easy for coders to shortcut the process of not adding new tests. thanks for your input Danie >>> Luke Gorrie 05/02/03 05:37PM >>> "DANIESC SCHUTTE" writes: It looks really bureaucratic to me, with all the boilerplate. (Sorry, you asked! :-)) I also think that is a lot of real code to be including in a template (e.g. module_test/1). I think you should Refactor as much as possible into a library, so you can have it Once-And-Only-Once in the source code and change it more easily. Templates are really copy-and-paste programming. You could also write the version/0 function as a library routine if you like. It could call YourModule:module_info(attributes) to extract the 'revision' attribute, and then parse that. Cheers, Luke ##################################################################################### The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy and copies. ##################################################################################### From micael.karlberg@REDACTED Mon May 5 12:08:09 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Mon, 5 May 2003 12:08:09 +0200 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) In-Reply-To: <3EB0CDBC.9040400@manderp.freeserve.co.uk> References: <200304302253.h3UMrm3M010168@snookles.snookles.com> <3EB0CDBC.9040400@manderp.freeserve.co.uk> Message-ID: <16054.14345.248776.604496@gargle.gargle.HOWL> Hi Peter, I have been trying to reproduce your problem without success. I have some questions and suggestions. q1: Have you changed the max counter value (max_trans_id)? A small value would lead to reset_trans_id_counter more often (I admit that from the fprof output that does not seem to be the case). q2: The fprof results included here, where they produced after the system beeing "warmed up"? s1: When fprof'ing, use fprof:apply(Func, Args, OptionList) and include the megaco system processes megaco_config and megaco_monitor ({procs, [self(),megaco_config,megaco_monitor]}). s2: In order to get more reliable results, run more then one set of call-setup: N*(add, modify & subtract). s3: Try setting prio of the megaco_config process to high. /BMK Peter-Henry Mander writes: > Hi Scott, > > Well, I did a bit of hacking and then realised I should use my brain too! > > First I replaced megaco_config:incr_trans_id_counter/1 with something I > rolled myself, a very simple tail-recursive counter server that didn't > use ets. Not because of any scheme or strategy I had, just because I > can! And the result was a noticable but minor improvement. The fprof > trace now show that blocking occurs on waiting for a reply, but the > performance still sucks. The media gateway end now held up the gateway > controller beyond 18 concurrent processes instead of 16. > > Since I haven't managed to conclusively fprof the media gateway > (possibly due to lack of experience I'm sorry to say), I decided to see > if things improved by adding a 20ms pause between launching each > process. Maybe all 2000 processes were trying to access ets at once, > effectively an avalanche of processes. The performance sucked a bit less > beyond 18 processes, but the call rate was a constant 36 cps all the way > up to 2000 concurrent processes maintaining 2000 open calls. So the > avalanche hypothesis seemed correct. > > This figure was a lot less than the 400 cps I get doing a "churning" > call cycle running on a dozen threads. Each thread repeatedly does a > Megaco add followed by modify and subtract as fast as possible. So I > know that this rate is achievable and will remain stable and constant > for hours on end without anything going pop! > > I then tweaked the launching code to introduce a 20ms pause after > starting seven processes at a time, seven being a trial-and-error > figure. This backs off process launching just enough to prevent the > avalanche effet and now I can open up 2000 calls at a rate of 330 cps. > Not quite 400 cps, but sufficient and an order of magnitude better! > > So, not exactly an ets problem (I'm using Linux, not FreeBSD), but I > haven't reversed my hacks to the megaco stack to see if there is any > significant speed gains through avoiding ets in this situation. Probably > not, I've been assured that ets is perfectly fast enough. > > I hope this little tail helps someone out there, it's not always clearly > obvious what's wrong with your code when an process avalanche situation > occurs. Ah the joys of massively concurrent systems (-: > > Pete. > > Scott Lystig Fritchie wrote: > >>>>>>"pm" == Peter-Henry Mander writes: > >>>>> > > > > pm> The attached gives the output of fprof, and the last line > > pm> indicates that all the time is spent waiting for > > pm> ets:update_counter/3 to return a new transaction ID to > > pm> megaco_config:incr_trans_id_counter/1. > > > > I've got two theories. > > > > 1. Has your Erlang VM's size grown so large that your OS has started > > paging memory to disk to make room? Or has some other OS process > > started hogging CPU cycles? > > > > Er, well, those are easy guess, and surprisingly easy to forget > > about if you're distracted by other things. > > > > 2. Is your OS platform FreeBSD (or perhaps one of the other *BSDs)? > > > > I've been doing some simple ETS benchmarks lately, and I've noticed > > really weird behavior of ets:delete() (deleting lots of items in a > > table or deleting an entire table at once) with FreeBSD 4.7-RELEASE > > and 5.0-RELEASE and Erlang R9B-1. If the table is large (tens of > > thousands to millions of items), the delete operation can take up > > to 40 times (!) longer than running on the exact same hardware > > under a "modern" Linux (Mandrake 9.1 distribution). > > > > This was so surprising to me that I tried it on two different > > machines, a Pentium III laptop and an AMD XP+ desktop. Same thing: > > FreeBSD was horrible in the delete case, Linux was not. > > > > I haven't chased down the final answer (hopefully I'll get back to > > finding the answer and propose a fix) ... but "gprof" analysis > > strongly suggests that libc's free() is the culprit. Bummer. > > > > -Scott > > > > > > -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From raimo.niskanen@REDACTED Mon May 5 13:24:50 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Mon, 05 May 2003 13:24:50 +0200 Subject: Fix for A=<<1>> References: , Message-ID: Alright, fixed for any number of '<' characters. It was a rather simple change. There should be no bad consequences for neither execution time nor memory consumption either, it was just to count the '<' characters and generate the tokens at the end of the sequence. If the change breaks anything in our daily build and test runs I will let you know. Otherwise the change will come in R9C. / Raimo Niskanen, Erlang/OTP, Ericsson AB Ulf Wiger wrote: > On Mon, 5 May 2003, Raimo Niskanen wrote: > > >>But since sub-binaries are allowed when constructing: how >>about '=<<<<<' as in "if A =< << <<1>>/binary, 2>>", then >>one can see that the scanning of '=<<' depends on if the >>number of '<' characters following is odd or even, so the >>scanner might have to scan infinitely ahead. A look ahead >>scan of limited small length would be fine, but this is >>ugly. > > > I'm not sure what the upper limit would be for a sequence of > '<' symbols in a program making any qlaims of still being > useable (one of course has to take into account generated > code, which is usually less readable than hand-written > code.) > > Perhaps a stupid question, but, so what if the scanner looks > ahead and breaks for safety at, say, 1000 tokens? This won't > cause any big problems as far as memory is concerned, and at > least I find it difficult to envision a program that would > break because of this, that is still worthy of being > compiled. > > The following syntactically correct expression would no > longer work (line breaks added for nettiquette compliance). > I'm prepared to say "so what?": > > A =<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<1>> > /binary,2>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > /binary>>. > > /Uffe From Wim.Vanhoof@REDACTED Mon May 5 11:34:23 2003 From: Wim.Vanhoof@REDACTED (Wim Vanhoof) Date: Mon, 5 May 2003 11:34:23 +0200 Subject: LOPSTR 2003 (CFP) Message-ID: <200305050934.h459YNGw018621@woolloomooloo.cs.kuleuven.ac.be> With apology for multiples copies. Deadline in 3 weeks ---------------------------------------------------------------------- International Symposium on Logic-based Program Synthesis and Transformation, LOPSTR'03 August 25 - 27, 2003 Uppsala, Sweden ---------------------------------------------------------- CALL FOR PAPERS ----------------------------------------------------------- http://www.cs.kuleuven.ac.be/~dtai/lopstr03/ ----------------------------------------------------------- The aim of the LOPSTR series is to stimulate and promote international research and collaboration on logic-based program development, and the symposium is open to contributions in logic-based program development in any language paradigm. LOPSTR 2003 will be held at the University of Uppsala, as part of PLI 2003 (Principles, Logics, and Implementation of High-Level Programming Languages), a confederation of conferences and workshops including ICFP 2003 (ACM-SIGPLAN International Conference on Functional Programming) and PPDP 2003 (ACM-SIGPLAN International Conference on Principles and Practice of Declarative Programming). Past events were held in Manchester, UK (1991, 1992, 1998), Louvain-la-Neuve, Belgium (1993), Pisa, Italy (1994), Arnhem, the Netherlands (1995), Stockholm, Sweden (1996), Leuven, Belgium (1997), Venice, Italy (1999), London, UK (2000), Paphos, Cyprus (2001), Madrid, Spain (2002). Since 1994 the proceedings have been published in the LNCS series of Springer-Verlag. LOPSTR also aims to be a lively, friendly forum for presenting and discussing work in progress, so it has a strong workshop character, in the sense that it is also intended to provide useful feedback to authors on their preliminary research. Formal proceedings of the symposium are produced only after the symposium, so that authors can incorporate this feedback in the published papers. Scope of the Workshop We solicit full papers as well as extended abstracts describing work in progress. Topics of interest cover all aspects of logic-based program development, all stages of the software life cycle, and issues of both programming-in-the-small and programming-in-the-large. The following is a non-exhaustive list of topics: * specification * synthesis * verification * transformation * specialisation * analysis * composition * reuse * optimisation * applications and tools * component-based software development * agent-based software development * software architectures * design patterns and frameworks * program refinement and logics for refinement * proofs as programs Submission Guidelines Authors can either submit extended abstracts (up to 6 pages) describing work in progress or they can choose to submit full papers (up to 16 pages in llncs format). Contributions should be written in English and should be submitted electronically in Postscript or PDF format to the program chairman at the following email address: Maurice.Bruynooghe@REDACTED Prospective authors who have difficulties for the electronic submission may contact the chairman. Accepted papers have to be presented at the Symposium by one of the authors and will appear in the informal pre-proceedings distributed at the Symposium. Formal Proceedings After the workshop, authors of work that is judged mature for publication will be invited to submit a full paper. These will be reviewed according to the usual refereeing procedures, and accepted papers will be published in a final collection of papers which are expected to be published in the Lecture Notes in Computer Science series by Springer-Verlag. Accepted full papers that the PC considers of sufficient quality will be exempted from a second reviewing round. Important Dates May 25, 2003: submission deadline for full papers June 8, 2003: submission deadline for extended abstracts June 22, 2003: notification of authors August 1, 2003: deadline for informal pre-proceedings December 1, 2003: submission deadline for revised papers February 1, 2004: notification of authors Program Committee Elvira Albert (Spain) Roland Bol (Sweden) LOCAL ORGANISOR Maurice Bruynooghe (Belgium) PROGRAMME CHAIR Michael Butler (UK) Jim Caldwell (USA) Wlodek Drabent (Poland) Tom Ellman (USA) Norbert E. Fuchs (Switzerland) Robert Gl?ck (Japan) Gopal Gupta (USA) Ian Hayes (Australia) Catholijn Jonker (the Netherlands) Andy King (UK) Mario Ornaghi (Italy) Maurizio Proietti (Italy) German Puebla (Spain) Julian Richardson (USA) Olivier Ridoux (France) Sabina Rossi (Italy) Wim Vanhoof (Belgium) From ndalton@REDACTED Tue May 6 11:37:59 2003 From: ndalton@REDACTED (Niall Dalton) Date: 06 May 2003 10:37:59 +0100 Subject: security and OTP based apps. Message-ID: <1052213879.2209.363.camel@localhost> Hello, I'm thinking of using Erlang (and OTP libs) to build a highly-concurrent distributed application. I'd like to have supervisors starting processes on remote nodes, hot-code swapping and so on. All this seems much easier and more practical in Erlang than other languages. My only real question before starting on a prototype is on security. The application would be accessible from the Internet. I have read a bit about setting the cookies, but also that "the user must be allowed to rsh to the remote hosts without being prompted for a password" (using whatever mechanisms rsh uses for this). Not being a security guy, I'm not sure how what the risks in practice are for this kind of thing. Are there any documents on securing Erlang based applications that are exposed to the Internet? I'd be grateful for any pointers on useful related information. Best regards, niall ------------------------------ This e-mail is intended for the named addressee only. It may contain confidential and/or privileged information. If you have received this message in error, please let us know and then delete this message from your system. You should not copy the message, use it for any purpose or disclose its contents to anyone. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From micael.karlberg@REDACTED Tue May 6 11:50:48 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Tue, 6 May 2003 11:50:48 +0200 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) In-Reply-To: <3EB766A8.1000003@manderp.freeserve.co.uk> References: <200304302253.h3UMrm3M010168@snookles.snookles.com> <3EB0CDBC.9040400@manderp.freeserve.co.uk> <3EB766A8.1000003@manderp.freeserve.co.uk> Message-ID: <16055.34168.594702.960600@gargle.gargle.HOWL> Hi, Peter-Henry Mander writes: > Hi Micael, > <--- snip ---> > > Q2: The results were the same whether "hot" or "cold." I assume you are > hinting at the garbage collector kicking in? Actully I was thinking of making sure all code was loaded. But GC is another possibillity. <--- snip ---> > > If I manage to reproduce the symptoms with a subset of the code, would > you be interested in reading it? I must warn you that it is *very* > "experimental!" i.e. hacked code. Yes. > > Pete. /BMK > > Micael Karlberg wrote: > > Hi Peter, > > I have been trying to reproduce your problem without success. > I have some questions and suggestions. > > q1: Have you changed the max counter value (max_trans_id)? > A small value would lead to reset_trans_id_counter more > often (I admit that from the fprof output that does not > seem to be the case). > > q2: The fprof results included here, where they produced > after the system beeing "warmed up"? > > s1: When fprof'ing, use fprof:apply(Func, Args, OptionList) > and include the megaco system processes megaco_config > and megaco_monitor ({procs, [self(),megaco_config,megaco_monitor]}). > > s2: In order to get more reliable results, run more then one > set of call-setup: N*(add, modify & subtract). > > s3: Try setting prio of the megaco_config process to high. > > /BMK > > -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From eleberg@REDACTED Tue May 6 12:39:27 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 6 May 2003 12:39:27 +0200 (MEST) Subject: security and OTP based apps. Message-ID: <200305061039.h46AdRq14751@cbe.ericsson.se> > I'm thinking of using Erlang (and OTP libs) to build a > highly-concurrent distributed application. I'd like to have > supervisors starting processes on remote nodes, hot-code > swapping and so on. All this seems much easier and more practical > in Erlang than other languages. good idea. > My only real question before starting on a prototype is on security. > The application would be accessible from the Internet. I have read a > bit about setting the cookies, but also that "the user must be allowed > to rsh to the remote hosts without being prompted for a password" (using > whatever mechanisms rsh uses for this). according to the manual page (i am assuming you refer to the slave module) you may specify an alternative to ''rsh'' on the command line. if you change to ''ssh'', and either use a hardened system or openbsd, you will not have security problems with the operating system. use un-guessable/random cookies and you might be safe from somebody using erlang, too. i have not looked into the latter part of the problem. > Not being a security guy, I'm not sure how what the risks in practice > are for this kind of thing. Are there any documents on securing Erlang > based applications that are exposed to the Internet? I'd be grateful > for any pointers on useful related information. i was a security guy. i would love doing this and then write the papers. beeing a family man it will have to wait until somebody is willing to pay me to do it. hint, hint. bengt From etxuwig@REDACTED Tue May 6 13:28:23 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 6 May 2003 13:28:23 +0200 (MEST) Subject: security and OTP based apps. In-Reply-To: <1052213879.2209.363.camel@localhost> Message-ID: On 6 May 2003, Niall Dalton wrote: >Hello, > >I'm thinking of using Erlang (and OTP libs) to build a >highly-concurrent distributed application. I'd like to have >supervisors starting processes on remote nodes, hot-code >swapping and so on. All this seems much easier and more >practical in Erlang than other languages. True. >My only real question before starting on a prototype is on >security. The application would be accessible from the >Internet. I have read a bit about setting the cookies, but >also that "the user must be allowed to rsh to the remote >hosts without being prompted for a password" (using >whatever mechanisms rsh uses for this). Bengt has answered this. I propose that you make sure that the shell given to the user is restricted. I would also avoid giving the users access to the erlang shell. Unfortunately, we still do not have an erlang shell with access control. Regarding distributed erlang, there are a couple of things you can do to increase security: - Use cookies that are hard to guess - You may use net_kernel:allow/1 to restrict which nodes are allowed to connect to your system using distributed erlang - By starting erlang with the boot flag 'erl -kernel dist_auto_connect never', you can further restrict applications from connecting from your node to others (one can still do it explicitly, using net_kernel:connect_node/1) - Do not use distributed erlang for your user interface. Rather, use some socket RPC, CORBA, UBF, or similar. This allows you to restrict what functions can be called from the outside (e.g. not allowing things like os:cmd("rm -rf /") or erlang:halt().) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From pete@REDACTED Tue May 6 09:39:20 2003 From: pete@REDACTED (Peter-Henry Mander) Date: Tue, 06 May 2003 08:39:20 +0100 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) References: <200304302253.h3UMrm3M010168@snookles.snookles.com> <3EB0CDBC.9040400@manderp.freeserve.co.uk> Message-ID: <3EB766A8.1000003@manderp.freeserve.co.uk> Hi Micael, Thanks for the three suggestions. Since I managed to hack the problem into submission and obtain a sufficiently fast result, I'm probably not going to be able to try them until after more urgent hacking is finished. But when I do I'll try to isolate and diagnose what was going on. A curious symptom was that the two nodes either end of the megaco signalling link where running idle, as if they where waiting for each other. Could it be that they were franticly garbage collecting or something? The CPU usage was practically zero. Q1: no, I haven't changed any default values. I noticed the reset_trans_id_counter function but ignored it because it was never being called. Q2: The results were the same whether "hot" or "cold." I assume you are hinting at the garbage collector kicking in? S2: I have a different test that "churns" the calls very quickly, setting them up and tearing them down without holding them and without any pause between. This one sustains almost 400 calls setup and teardown every second, so it is clear to me that ets:update_counter/3 *must* be capable of at least this rate. When I attempted this new test where calls were setup without tearing them down I was expecting at least 400/second if not more. So I am very puzzled as to why I have to introduce "breathing time" when before it wasn't necessary. The only difference is that memory is being rapidly consumed by the call processes to store the call contexts. If I manage to reproduce the symptoms with a subset of the code, would you be interested in reading it? I must warn you that it is *very* "experimental!" i.e. hacked code. Pete. Micael Karlberg wrote: Hi Peter, I have been trying to reproduce your problem without success. I have some questions and suggestions. q1: Have you changed the max counter value (max_trans_id)? A small value would lead to reset_trans_id_counter more often (I admit that from the fprof output that does not seem to be the case). q2: The fprof results included here, where they produced after the system beeing "warmed up"? s1: When fprof'ing, use fprof:apply(Func, Args, OptionList) and include the megaco system processes megaco_config and megaco_monitor ({procs, [self(),megaco_config,megaco_monitor]}). s2: In order to get more reliable results, run more then one set of call-setup: N*(add, modify & subtract). s3: Try setting prio of the megaco_config process to high. /BMK From micael.karlberg@REDACTED Tue May 6 14:09:34 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Tue, 6 May 2003 14:09:34 +0200 Subject: Megaco Avalanche! (was: ets:update_counter/3 taking a looooong time!) In-Reply-To: <3EB766A8.1000003@manderp.freeserve.co.uk> References: <200304302253.h3UMrm3M010168@snookles.snookles.com> <3EB0CDBC.9040400@manderp.freeserve.co.uk> <3EB766A8.1000003@manderp.freeserve.co.uk> Message-ID: <16055.42494.157264.496548@gargle.gargle.HOWL> Hi Peter, Another suggestion came up. Try eprof and compare the result to fprof (in case fprof has a bug). /BMK Peter-Henry Mander writes: > Hi Micael, > > Thanks for the three suggestions. Since I managed to hack the problem > into submission and obtain a sufficiently fast result, I'm probably not > going to be able to try them until after more urgent hacking is > finished. But when I do I'll try to isolate and diagnose what was going on. > > A curious symptom was that the two nodes either end of the megaco > signalling link where running idle, as if they where waiting for each > other. Could it be that they were franticly garbage collecting or > something? The CPU usage was practically zero. > > Q1: no, I haven't changed any default values. I noticed the > reset_trans_id_counter function but ignored it because it was never > being called. > > Q2: The results were the same whether "hot" or "cold." I assume you are > hinting at the garbage collector kicking in? > > S2: I have a different test that "churns" the calls very quickly, > setting them up and tearing them down without holding them and without > any pause between. This one sustains almost 400 calls setup and teardown > every second, so it is clear to me that ets:update_counter/3 *must* be > capable of at least this rate. When I attempted this new test where > calls were setup without tearing them down I was expecting at least > 400/second if not more. So I am very puzzled as to why I have to > introduce "breathing time" when before it wasn't necessary. The only > difference is that memory is being rapidly consumed by the call > processes to store the call contexts. > > If I manage to reproduce the symptoms with a subset of the code, would > you be interested in reading it? I must warn you that it is *very* > "experimental!" i.e. hacked code. > > Pete. > > Micael Karlberg wrote: > > Hi Peter, > > I have been trying to reproduce your problem without success. > I have some questions and suggestions. > > q1: Have you changed the max counter value (max_trans_id)? > A small value would lead to reset_trans_id_counter more > often (I admit that from the fprof output that does not > seem to be the case). > > q2: The fprof results included here, where they produced > after the system beeing "warmed up"? > > s1: When fprof'ing, use fprof:apply(Func, Args, OptionList) > and include the megaco system processes megaco_config > and megaco_monitor ({procs, [self(),megaco_config,megaco_monitor]}). > > s2: In order to get more reliable results, run more then one > set of call-setup: N*(add, modify & subtract). > > s3: Try setting prio of the megaco_config process to high. > > /BMK > > -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From ndalton@REDACTED Tue May 6 17:51:59 2003 From: ndalton@REDACTED (Niall Dalton) Date: 06 May 2003 16:51:59 +0100 Subject: security and OTP based apps. In-Reply-To: <200305061039.h46AdRq14751@cbe.ericsson.se> References: <200305061039.h46AdRq14751@cbe.ericsson.se> Message-ID: <1052236319.12867.548.camel@localhost> Thanks to Bengt and Ulf for their suggestions - it looks like it can be made secure enough for my purposes..roll on the prototype :-) Best regards, Niall ------------------------------ This e-mail is intended for the named addressee only. It may contain confidential and/or privileged information. If you have received this message in error, please let us know and then delete this message from your system. You should not copy the message, use it for any purpose or disclose its contents to anyone. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From erlang@REDACTED Tue May 6 22:59:31 2003 From: erlang@REDACTED (Erlang Question) Date: Tue, 6 May 2003 17:59:31 -0300 Subject: help using Inets and ESP Message-ID: <001f01c31412$67fda9b0$1400a8c0@sbnt.com> Hi! I have a interesting question.... I?m developing a web interface in esp to access mnesia running under inets, and I would like to have control of the user logged in the system. So I need to define session variable to manage the active user in the system. So here is my question: Anybody knows if Inets supports session variables? (like apache) If support, then how i define one? if not, anybody know a trick or tip to simulate a session variable looking my case? I suppose that someone must need it sometime? any kind of help it'll be great! thanks in advance...gabriel! From samuel@REDACTED Wed May 7 08:54:00 2003 From: samuel@REDACTED (Samuel Rivas) Date: Wed, 7 May 2003 08:54:00 +0200 Subject: help using Inets and ESP In-Reply-To: <001f01c31412$67fda9b0$1400a8c0@sbnt.com> References: <001f01c31412$67fda9b0$1400a8c0@sbnt.com> Message-ID: <20030507065400.GA412@crusher.lfcia.pri> > Hi! > I have a interesting question.... > I?m developing a web interface in esp to access mnesia running under inets, > and I would like to have control of the user logged in the system. So I > need to define session variable to manage the active user in the system. > > So here is my question: > Anybody knows if Inets supports session variables? (like apache) > If support, then how i define one? > if not, anybody know a trick or tip to simulate a session variable looking > my case? I suppose that someone must need it sometime? any kind of help > it'll be great! > > thanks in advance...gabriel! > You've to manage the session by yourself, take a look to http//btt.sourceforge.net, there is a complete example of an inets application managing user sessions. You could create the user session with cookies as it's done on btt and store the user info on an ets table. Hope it helps. -- --------------------- | Samuel | --------------------- From vlad_dumitrescu@REDACTED Wed May 7 09:44:32 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 7 May 2003 09:44:32 +0200 Subject: File versioning Message-ID: Hi all, There were some discussions for some time ago about disk data that lives "forever" and all versions are available. Jay wrote: > An interesting > approach would be to make the disk single-assignment. *Never* > allow data to be modified, only allow new versions of the > data to be created and retain all versions for their lifetime. Would this be something to think about? In an Erlang environment, we could modify the file server to access some kind of repository for some parts of the namespace, which could be a database or a CVS repository or something like that. This way everything looks like normal files, but they aren't. Maybe Luke's nfs server could also be a part of this too... best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleberg@REDACTED Wed May 7 09:58:13 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 7 May 2003 09:58:13 +0200 (MEST) Subject: File versioning Message-ID: <200305070758.h477wDq26566@cbe.ericsson.se> > X-Originating-IP: [194.17.126.213] > X-Originating-Email: [vlad_dumitrescu@REDACTED] > From: "Vlad Dumitrescu" > There were some discussions for some time ago about disk data that lives > "forever" and all versions are available. > ...deleted > In an Erlang environment, we could modify the file server to access some kind of repository for some parts of the namespace, which could be a database or a CVS repository or something like that. see http://plan9.bell-labs.com/sys/doc/venti/venti.html for a write-only file server. they (plan9 developers) have plenty (since before 1990) of experience with write-only file servers. they like it. bengt From eleberg@REDACTED Wed May 7 10:18:00 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 7 May 2003 10:18:00 +0200 (MEST) Subject: File versioning Message-ID: <200305070818.h478I0q28833@cbe.ericsson.se> > Date: Wed, 7 May 2003 09:58:13 +0200 (MEST) > X-Sybari-Space: 00000000 00000000 00000000 00000000 > From: Bengt Kleberg ...deleted > see http://plan9.bell-labs.com/sys/doc/venti/venti.html for a > write-only file server. it has been pointed out to me that write-only is wrong terminology. it should be called a write-once file server. (it is possible to write more than once to it, so possibly this name too is wrong. however, i have now copied the name from the original paper, not using my faulty memory of it) bengt From thomas.arts@REDACTED Wed May 7 14:47:51 2003 From: thomas.arts@REDACTED (Thomas Arts) Date: Wed, 7 May 2003 14:47:51 +0200 Subject: Erlang workshop Message-ID: <005d01c31496$def78840$a22d1081@ituniv398> CALL FOR PAPERS (deadline 16 May, 2003) ACM SIGPLAN Erlang Workshop Friday August 29, 2003, Uppsala, Sweden Dear all Upon several requests we have extended the deadline for submission for the ACM sigplan Erlang workshop. We do realize that people in industry are even more bussy than those at universities and that you probably would have liked to submit, but not had the time to do so. If you have submitted but did not get an acknowledgement from me, your email has not passed my SPAM filter. Please submit again (with Submission in the subject field)! For more information: http://www.erlang.se/workshop/2003/ If you have already submitted but would like to beautify your submission, you are ever so welcome to use this extension for that. Kind regards Thomas --- Dr Thomas Arts Program Manager Software Engineering and Management IT-university in Gothenburg Box 8718, 402 75 Gothenburg, Sweden http://www.ituniv.se/ Tel +46 31 772 6031 Fax +46 31 772 4899 From cpressey@REDACTED Wed May 7 19:46:47 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 07 May 2003 12:46:47 -0500 Subject: Erlang filesystem (was: Re: File versioning) In-Reply-To: <200305070818.h478I0q28833@cbe.ericsson.se> References: <200305070818.h478I0q28833@cbe.ericsson.se> Message-ID: <20030507124647.0e01d933.cpressey@catseye.mb.ca> On Wed, 7 May 2003 10:18:00 +0200 (MEST) Bengt Kleberg wrote: > > see http://plan9.bell-labs.com/sys/doc/venti/venti.html for a > > write-only file server. > > it has been pointed out to me that write-only is wrong terminology. http://www.ganssle.com/misc/wom.html :) Seriously, it's a good idea. Vlad wrote: > In an Erlang environment, we could modify the file server to access > some kind of repository for some parts of the namespace, which could > be a database or a CVS repository or something like that. This way > everything looks like normal files, but they aren't. Maybe Luke's nfs > server could also be a part of this too... Everything looks like normal files - in an Erlang environment. That strikes me as the biggest drawback, at least for the sake of argument. I'd like to be able to use it from other programs with a minimum of fuss. I can think of a few ways around it: 1- make Erlang's filesystem mountable as an OS-level filesystem 2- make Erlang an OS 3- have some way to painlessly communicate between external, non-Erlang programs, and a running Erlang node I get the impression that #1, writing a mountable filesystem 'driver', is tricky even in C. I could be wrong though. I have no problem with #2 since Erlang already has many of the characteristics of a good OS and since I've abandoned the adage of "the right language for the task" after realizing that Java - no, Haskell - no, *Erlang* is clearly God's Own Language. Also, re-writing in Erlang all the applications I use daily would give me something interesting to do. :) But #3 is probably the most feasible, and useful for a number of other things too. I've tried using a named pipe as a port, and I've tried ad-hoc connections to an Erlang distribution, but neither seems reliable enough for real use. That pretty much leaves sockets - probably inet sockets since Unix-domain sockets aren't as well tested, and inet sockets would let you connect across the network & can be secured if need be. So I envision doing stuff like the following from the command line: ls | grep foo | sort -r | store-in-erlfs-as bar.txt where 'store-in-erlfs-as' is a little program which opens a socket and talks to the running Erlang distribution that is handling the Erlang filesystem. It could maybe even be a shell script that looks for a temporary file for what machine and port to connect to, then uses 'tcpdump' or similar to connect to that socket and send Erlang it's input. Naturally there'd also be a corresponding 'fetch-from-erlfs' program. With shorter names probably, like 'erlfsstore' & 'erlfsfetch', but you get the idea. On a vaguely related note... someone recently asked on one of the FreeBSD lists if there was any realtime file replication software available. rsync and so forth were mentioned, but apparently there isn't any that is really 'realtime', and what's more it sounds like a 'hard' problem. Maybe an Erlang filesystem could fit the bill here? -Chris From jilani.khaldi@REDACTED Wed May 7 23:13:16 2003 From: jilani.khaldi@REDACTED (Jilani Khaldi) Date: Wed, 07 May 2003 23:13:16 +0200 Subject: Call a compiled Beam module Message-ID: Hi All, how to load "c:\abc\mymodule.beam" from werl shell? I have put l("/abc/mymodule.beam/"). -> Error Thanks. -- Jilani Khaldi http://www.jilani.net From svg@REDACTED Wed May 7 23:53:11 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Thu, 08 May 2003 03:53:11 +0600 (YEKST) Subject: Call a compiled Beam module In-Reply-To: References: Message-ID: <20030508.035311.41641284.svg@surnet.ru> Good day, Please try: code:add_path("c:/abc"). l(mymodule). I can be wrong with slash because I've never used Erlang under Win. Best Regards, Vladimir Sekissov jilani.khaldi> Hi All, jilani.khaldi> how to load "c:\abc\mymodule.beam" from werl shell? jilani.khaldi> jilani.khaldi> I have put l("/abc/mymodule.beam/"). jilani.khaldi> -> Error jilani.khaldi> jilani.khaldi> Thanks. jilani.khaldi> -- jilani.khaldi> Jilani Khaldi jilani.khaldi> http://www.jilani.net jilani.khaldi> jilani.khaldi> jilani.khaldi> From fritchie@REDACTED Thu May 8 06:01:14 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 07 May 2003 23:01:14 -0500 Subject: Erlang filesystem (was: Re: File versioning) In-Reply-To: Message of "Wed, 07 May 2003 12:46:47 CDT." <20030507124647.0e01d933.cpressey@catseye.mb.ca> Message-ID: <200305080401.h4841EN4016035@snookles.snookles.com> >>>>> "cp" == Chris Pressey writes: cp> 3- have some way to painlessly communicate cp> between external, non-Erlang programs, and a running Erlang node Back in the days when I worked at Sendmail... ... we did such a thing. It used TCP (and UNIX domain sockets, later) and Sun RPC. Client applications spoke RPC to an Erlang I/O daemon (running on the same box). The Erlang I/O daemon "knew" were files were really stored: their "real" path(s) on an NFS server(s) somewhere. It knew if the file was replicated or not. Though we never finished it, we had an icky draft of code that could transparently migrate files to new paths and/or new NFS servers in the event that the mapping of files -> {replication-mode, [NFS servers]} changed. We stole open(2), read(2), write(2), close(2), chdir(2), unlink(2) ... everything file I/O related. We could tell the difference between an I/O-daemon'ified file descriptors (e.g., referring to files with paths in the namespace below "/bams", "/var/spool/mqueue", or whatever) and local file system descriptors. We even stole flock(2) and implemented a leasing scheme that was *reliable* when talking to an NFSv3 file server. Heh. The only thing that we couldn't easily do is mmap(2). We stole it, but the implementation was easy: int bams_mmap(...) { return EINVAL; } BAMS'izing an application: 1. Check its use of mmap() first. 2. Link with BAMS library. 3. Run. Worked for "sendmail", GNU "tar" and "ls". I think I did "qmail" or "postfix", but details are foggy now. Oh, yeah, "beam" too. :-) Then I created an LD_PRELOAD'able shared library, making step #2 optional. Ah, those were the days when we wrote code in log cabins with wood-fired generators.... There are several hacks these days that do file system type stuff in user space. Gnome VFS and later versions of Tcl come immediately to mind. But they and other efforts like them don't have all that much in common. Except for perhaps Plastic File System. It'd be great to glue them together. Mebbe I should do that. {sigh} -Scott From luke@REDACTED Thu May 8 06:05:05 2003 From: luke@REDACTED (Luke Gorrie) Date: 08 May 2003 06:05:05 +0200 Subject: Erlang filesystem (was: Re: File versioning) In-Reply-To: <20030507124647.0e01d933.cpressey@catseye.mb.ca> References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> Message-ID: Chris Pressey writes: > Everything looks like normal files - in an Erlang environment. That > strikes me as the biggest drawback, at least for the sake of argument. > I'd like to be able to use it from other programs with a minimum of > fuss. I can think of a few ways around it: > > 1- make Erlang's filesystem mountable as an OS-level filesystem You can do this with my Erlang NFS server. It's a quick hack, very non-robust and unfeatureful etc. It's in the Jungerl if you want to play around - lib/enfs/. I have a "/proc" filesystem included. With that you can grep process dictionaries :-) Cheers, Luke From etxuwig@REDACTED Thu May 8 10:17:03 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 8 May 2003 10:17:03 +0200 (MEST) Subject: help using Inets and ESP In-Reply-To: <001f01c31412$67fda9b0$1400a8c0@sbnt.com> Message-ID: On Tue, 6 May 2003, Erlang Question wrote: >Anybody knows if Inets supports session variables? (like >apache) If support, then how i define one? if not, anybody >know a trick or tip to simulate a session variable looking >my case? I suppose that someone must need it sometime? any >kind of help it'll be great! Two examples of session handling (even if it's not INETS-based) are the "Cookie sessions" and "Tiny shoping cart" examples at http://yaws.hyber.org/examples.yaws /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From jilani.khaldi@REDACTED Thu May 8 10:25:32 2003 From: jilani.khaldi@REDACTED (Jilani Khaldi) Date: Thu, 08 May 2003 10:25:32 +0200 Subject: Call a compiled Beam module In-Reply-To: <20030508.035311.41641284.svg@surnet.ru> Message-ID: >Good day, > >Please try: > >code:add_path("c:/abc"). >l(mymodule). That's Ok, but it loads only the module but not the "*.gif" images inside "c:/abc" that the module uses, and it aborts. Any idea? -- Jilani Khaldi http://www.jilani.net From jilani.khaldi@REDACTED Thu May 8 10:26:48 2003 From: jilani.khaldi@REDACTED (Jilani Khaldi) Date: Thu, 08 May 2003 10:26:48 +0200 Subject: Call a compiled Beam module In-Reply-To: <20030507222820.GI13633@frogman.motivity.ca> Message-ID: <3V1YUSOTYDVNM7695VP074POB.3eba14c8@r-pe024-4> >I believe it should be: > > l("/abc/mymodule"). Sorry. Already tried but it didn't work. At least under Windows. -- Jilani Khaldi http://www.jilani.net From etxuwig@REDACTED Thu May 8 10:35:41 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 8 May 2003 10:35:41 +0200 (MEST) Subject: Call a compiled Beam module In-Reply-To: Message-ID: On Thu, 8 May 2003, Jilani Khaldi wrote: >>Good day, >> >>Please try: >> >>code:add_path("c:/abc"). >>l(mymodule). >That's Ok, but it loads only the module but not the "*.gif" >images inside "c:/abc" that the module uses, and it aborts. >Any idea? An OTPish way of doing things would be to organize your code into applications like in the OTP code tree: $MYROOT/lib/myapp-1.0/ebin/ /priv/ etc. You can then use the function code:priv_dir(myapp) and find $MYROOT/lib/myapp-1.0/priv/. From there, you can e.g. slap on an imgs/ subdirectory and fetch your files. Another method would be to maintain a variable pointing to your personal files. This can be done in many ways. - If you want to specify an OS environment variable, you can do so, and fetch the location using os:getenv(Variable) - If you want to specify the location as an argument to the 'erl' command, you are free to do so: #: erl -mydir /foo Erlang (BEAM) emulator version 5.2.3.3 [source] [threads:0] [kernel-poll] Eshell V5.2.3.3 (abort with ^G) 1> init:get_argument(mydir). {ok,[["/foo"]]} 2> - You can store a value in Mnesia, of course You can also use code:which(?MODULE) in your code to find the location of your .beam file. This is a questionable tactic, since it will be misleading if the module has been loaded from a patch directory. I'm sure there are other, perhaps better, ways, but those were some alternatives off the top of my head. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From eleberg@REDACTED Thu May 8 12:55:12 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 8 May 2003 12:55:12 +0200 (MEST) Subject: Erlang filesystem (was: Re: File versioning) Message-ID: <200305081055.h48AtCq09097@cbe.ericsson.se> > From: Scott Lystig Fritchie > To: erlang-questions@REDACTED > Subject: Re: Erlang filesystem (was: Re: File versioning) ...deleted > ... we did such a thing. It used TCP (and UNIX domain sockets, later) > and Sun RPC. Client applications spoke RPC to an Erlang I/O daemon > (running on the same box). The Erlang I/O daemon "knew" were files > were really stored: their "real" path(s) on an NFS server(s) > somewhere. It knew if the file was replicated or not. Though we > never finished it, we had an icky draft of code that could > transparently migrate files to new paths and/or new NFS servers in the > event that the mapping of files -> {replication-mode, [NFS servers]} > changed. > > We stole open(2), read(2), write(2), close(2), chdir(2), unlink(2) > ... everything file I/O related. We could tell the difference between i could be blinded by a very good pr effort, but i belive that 9p (or styx) is better than nfs (simplified unix) semantics. bengt From cpressey@REDACTED Thu May 8 19:03:23 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 08 May 2003 12:03:23 -0500 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> Message-ID: <20030508120323.625f84a9.cpressey@catseye.mb.ca> What, no takers for #2? I'm disappointed in you guys :) On 08 May 2003 06:05:05 +0200 Luke Gorrie wrote: > You can do this with my Erlang NFS server. It's a quick hack, very > non-robust and unfeatureful etc. It's in the Jungerl if you want to > play around - lib/enfs/. And Scott wrote: > ... we did such a thing. It used TCP (and UNIX domain sockets, later) > and Sun RPC. Client applications spoke RPC to an Erlang I/O daemon > (running on the same box). The Erlang I/O daemon "knew" were files > were really stored: their "real" path(s) on an NFS server(s) > somewhere. [...] We even stole flock(2) and implemented a leasing > scheme that was *reliable* when talking to an NFSv3 file server. Heh. As cool as both of these sound, well... to paraphrase Bengt - I could be blinded by the thousands of horror stories and the unfortunate nickname "Network Failure System" given to it by a guru I highly respect, but I believe that sticking your data on 8" floppy disks and walking it from one computer to the other is superior to NFS in every way :) OK, I'm a *little* biased. I haven't used it in ages, apparently NFSv4 has reliable locking semantics, etc. But still I have the vague feeling it's not quite what I'm looking for - I'd rather have a replicated file system, like an "auto-mirror" perhaps, that propogates updates exactly when it needs to. That doesn't mean, of course, that I won't look into enfs; producing a mountable filesystem from Erlang doesn't have anything inherently to do with NFS, and it would be the most seamless way to go (and just plain cool besides.) But it too has the drawback that porting it outside of Unix would probably be a royal pain. (For this reason, for #3 to be portable, shell scripts, tcpcat, and unix-domain sockets are out; Perl + inet sockets looks like a better choice - maybe C if startup-time is critical (The Erlang runtime's relatively long startup-time is what started me thinking about this approach in the first place.)) #3 also doesn't have anything inherently to do with NFS or any other filesystem; what would be most useful would be a 'tellerl' command that simply sends a message (+ input data) to the Erlang node and waits for a response (+ output data.) Sort of an RPC-like mechanism, except of course it's probably more productive to think of it in terms of messages rather than procedure calls. 'erlfsstore' et al could be built on top of 'tellerl'. There is also at least one other option I missed: #4 - have the Erlang node watch the OS's filesystem and react to changes in it. Different operating systems do this differently, though - FreeBSD has kqueues, WinNT has a notification service, and I don't know what Linux has - so while this approach has a certain elegance, it too would be difficult to make portable, unless it resorted to polling on unknown OS'es, which would seriously detract from the elegance. This too would be a nifty thing to have outside of the context of having it implement a filesystem. Speaking of kqueues - I searched the archives and about a year ago, Per announced a 'devpoll' patch which employed them - but it seems like it was more for the purposes of getting better performance from sockets & other files, than for the purposes of watching and reacting to the filesystem. Which brings me to ask if anyone has interfaced Erlang with kqueue in a general fashion, for example as a port from which you can receive messages when kevents happen. And/or the same concept for other operating systems. This is definately beyond my fu but in a pinch I could probably put together something that uses os:cmd("wait_on " ++ ...). (Not as efficient to shell an executable, certainly, but still far more efficient than polling :) -Chris From nhead@REDACTED Thu May 8 20:14:45 2003 From: nhead@REDACTED (Nigel Head) Date: Thu, 8 May 2003 20:14:45 +0200 Subject: Aerospace users ? Message-ID: <20030508201445.1bbc2c96.nhead@houbits.com> Are there any (prospective or actual) aerospace users here? I'd like to learn from any experience you may have in using or prototyping erlang in this domain, technical or programmatic. Regards, and thanks in advance, Nigel Head nigel dot head at esa dot int From fritchie@REDACTED Thu May 8 20:32:02 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 08 May 2003 13:32:02 -0500 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: Message of "Thu, 08 May 2003 12:03:23 CDT." <20030508120323.625f84a9.cpressey@catseye.mb.ca> Message-ID: <200305081832.h48IW2N4066576@snookles.snookles.com> Too off-topic to continue on the list.... >>>>> "cp" == Chris Pressey writes: cp> I could be blinded by the thousands of horror stories and the cp> unfortunate nickname "Network Failure System" given to it by a cp> guru I highly respect, but I believe that sticking your data on 8" cp> floppy disks and walking it from one computer to the other is cp> superior to NFS in every way :) Ah, you're confusing NFS client implementation with NFS server implementation. If you control the NFS client implementation, you control how it reacts in the event of NFS server or network failure. There's nothing that says that NFS must be implemented by the OS kernel. :-) -Scott From tony@REDACTED Thu May 8 22:18:06 2003 From: tony@REDACTED (Tony Rogvall) Date: Thu, 08 May 2003 22:18:06 +0200 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> <1052414809.7977@DNS02> Message-ID: <3EBABB7E.4060601@rogvall.com> Chris Pressey wrote: > What, no takers for #2? I'm disappointed in you guys :) > Well Erlux is nearly #2 I guess, still some work to do. The first erlux will be a kernel module running a kernel deamon (kerl), this actually works! I have the ring0 exectuting in the emulator, loading code etc. Things remaing - rewrite some code to fit the 2.4.18xx (redhat kernels). Now it's a 2.4.20 only kernel module. - fix floating point issues. - make sure the emulator runs on a bounded stack (SMALL) This was done in the multi-threaded erlang! (some one preserved the code????? I guess not :-( - Think of nice ways of handling input from console (kernel module) All basic drivers are working, even then dll driver (uses kernel modules to implement loadable drivers :-) Near enough ? /Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From fritchie@REDACTED Fri May 9 00:01:05 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 08 May 2003 17:01:05 -0500 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: Message of "Thu, 08 May 2003 22:18:06 +0200." <3EBABB7E.4060601@rogvall.com> Message-ID: <200305082201.h48M15N4083267@snookles.snookles.com> Trying to send a message *to* the list this time. {sigh} >>>>> "tr" == Tony Rogvall writes: tr> Well Erlux is nearly #2 I guess, still some work to do. Out of curiousity, how much does "Kernel Mode Linux" get you toward your goals? http://www.yl.is.s.u-tokyo.ac.jp/~tosh/kml/ "Kernel Mode Linux is a technology which enables us to execute user programs in a kernel mode. In Kernel Mode Linux, user programs can be executed as user processes that have the privilege level of a kernel mode. The benefit of executing user programs in a kernel mode is that the user programs can access a kernel address space directly. So, for example, user programs can invoke system calls very fast because it is unnecessary to switch between a kernel mode and a user mode by using costly software interruptions or context switches. Unlike kernel modules, user programs are executed as ordinary processes (except for their privilege level), so scheduling and paging are performed as usual." This sort of thing is just sick and wrong and against the laws of Kentucky and Tennessee(*) and ... darnit ... cool. -Scott (*) Disclaimer: I am not a lawyer. From etxuwig@REDACTED Thu May 8 10:35:41 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 8 May 2003 10:35:41 +0200 (MEST) Subject: Call a compiled Beam module In-Reply-To: Message-ID: On Thu, 8 May 2003, Jilani Khaldi wrote: >>Good day, >> >>Please try: >> >>code:add_path("c:/abc"). >>l(mymodule). >That's Ok, but it loads only the module but not the "*.gif" >images inside "c:/abc" that the module uses, and it aborts. >Any idea? An OTPish way of doing things would be to organize your code into applications like in the OTP code tree: $MYROOT/lib/myapp-1.0/ebin/ /priv/ etc. You can then use the function code:priv_dir(myapp) and find $MYROOT/lib/myapp-1.0/priv/. From there, you can e.g. slap on an imgs/ subdirectory and fetch your files. Another method would be to maintain a variable pointing to your personal files. This can be done in many ways. - If you want to specify an OS environment variable, you can do so, and fetch the location using os:getenv(Variable) - If you want to specify the location as an argument to the 'erl' command, you are free to do so: #: erl -mydir /foo Erlang (BEAM) emulator version 5.2.3.3 [source] [threads:0] [kernel-poll] Eshell V5.2.3.3 (abort with ^G) 1> init:get_argument(mydir). {ok,[["/foo"]]} 2> - You can store a value in Mnesia, of course You can also use code:which(?MODULE) in your code to find the location of your .beam file. This is a questionable tactic, since it will be misleading if the module has been loaded from a patch directory. I'm sure there are other, perhaps better, ways, but those were some alternatives off the top of my head. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From cpressey@REDACTED Fri May 9 05:42:05 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 08 May 2003 22:42:05 -0500 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: <3EBABB7E.4060601@rogvall.com> References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> <1052414809.7977@DNS02> <3EBABB7E.4060601@rogvall.com> Message-ID: <20030508224205.519cf29f.cpressey@catseye.mb.ca> On Thu, 08 May 2003 22:18:06 +0200 Tony Rogvall wrote: > Chris Pressey wrote: > > What, no takers for #2? I'm disappointed in you guys :) > > > > Well Erlux is nearly #2 I guess, still some work to do. > > The first erlux will be a kernel module running a kernel deamon (kerl), > this actually works! I have the ring0 exectuting in the emulator, > loading code etc. Things remaing > > - rewrite some code to fit the 2.4.18xx (redhat kernels). Now it's a > 2.4.20 only kernel module. > - fix floating point issues. > - make sure the emulator runs on a bounded stack (SMALL) > This was done in the multi-threaded erlang! (some one preserved the > code????? I guess not :-( > - Think of nice ways of handling input from console (kernel module) > > All basic drivers are working, even then dll driver (uses kernel modules > to implement loadable drivers :-) > > Near enough ? > > /Tony !!!!! Dangit, the Erlang community never ceases to amaze me. Downright inspired me to prove that I wasn't just all talk, too - I sat myself down and implemented #3. The README should explain it all: http://www.catseye.mb.ca/projects/tellerl-2003.0508/ -Chris From luke@REDACTED Fri May 9 05:59:15 2003 From: luke@REDACTED (Luke Gorrie) Date: 09 May 2003 05:59:15 +0200 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: <20030508224205.519cf29f.cpressey@catseye.mb.ca> References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> <1052414809.7977@DNS02> <3EBABB7E.4060601@rogvall.com> <20030508224205.519cf29f.cpressey@catseye.mb.ca> Message-ID: Chris Pressey writes: > Downright inspired me to prove that I wasn't just all talk, too - > I sat myself down and implemented #3. The README should explain it all: > > http://www.catseye.mb.ca/projects/tellerl-2003.0508/ Do you know about the erl_call example program included with erl_interface? It is actually incredibly cool, but I never remember to use it.. Of course, a real man would have no hesitation in doing it like this: #!/bin/sh ERLANG_MODE_DIR="/home/luke/elisp" DISTEL_DIR="/home/luke/hacking/distel/elisp" if [ $# != 4 ]; then echo "Usage: $0 " exit 1 fi emacs --batch \ -L ${ERLANG_MODE_DIR} \ -L ${DISTEL_DIR} \ --eval " (progn (defun message (&rest ignore) nil) ; silence messages (require 'distel) (setq worker-pid (erl-rpc (lambda (x) (princ (format \"%s\\n\" x) t)) '() '$1 '$2 '$3 '$4)) (while (erl-local-pid-alive-p worker-pid) (accept-process-output))) " And then: $ ./tellerl x@REDACTED lists reverse "((x y z))" (z y x) Cheers, Luke From luke@REDACTED Fri May 9 06:19:00 2003 From: luke@REDACTED (Luke Gorrie) Date: 09 May 2003 06:19:00 +0200 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> <1052414809.7977@DNS02> <3EBABB7E.4060601@rogvall.com> <20030508224205.519cf29f.cpressey@catseye.mb.ca> Message-ID: Luke Gorrie writes: > Of course, a real man would have no hesitation in doing it like this: Sorry, bad joke. Of course what I meant was: #!/bin/sh ERLANG_MODE_DIR="/home/luke/elisp" DISTEL_DIR="/home/luke/hacking/distel/elisp" if [ $# -lt 2 ]; then echo "Usage: $0 ..." exit 1 fi node=$1; shift expr="$@" emacs --batch \ -L ${ERLANG_MODE_DIR} \ -L ${DISTEL_DIR} \ --eval " (progn (require 'distel) (setq erl-nodeup-hook nil) ; suppress 'nodeup' message (let ((pid (erl-eval-expression '${node} \"${expr}\"))) (while (erl-local-pid-alive-p pid) (accept-process-output))))" So you can just say: $ ./tellerl x@REDACTED "{code_path_size, length(code:get_path())}." {code_path_size,44} But then, "C-c C-d :" is marginally less keystrokes than "tellerl" ;-) -Luke From cpressey@REDACTED Fri May 9 09:23:44 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 09 May 2003 02:23:44 -0500 Subject: erl_call (was Re: Erlang filesystem) In-Reply-To: References: <200305070818.h478I0q28833@cbe.ericsson.se> <20030507124647.0e01d933.cpressey@catseye.mb.ca> <1052414809.7977@DNS02> <3EBABB7E.4060601@rogvall.com> <20030508224205.519cf29f.cpressey@catseye.mb.ca> Message-ID: <20030509022344.1a9b95b6.cpressey@catseye.mb.ca> On 09 May 2003 05:59:15 +0200 Luke Gorrie wrote: > Chris Pressey writes: > > > Downright inspired me to prove that I wasn't just all talk, too - > > I sat myself down and implemented #3. The README should explain it > > all: > > > > http://www.catseye.mb.ca/projects/tellerl-2003.0508/ > > Do you know about the erl_call example program included with > erl_interface? It is actually incredibly cool, but I never remember to > use it.. Had heard of it, hadn't played with it until now. No mention of it in the erl_interface docs that I could see. It doesn't seem to work for me with short node names, only long ones. In contrast, tellerl doesn't require any distribution mechanism, just that tellerl.beam is loaded and started. tellerl also doesn't allow arbitrary functions to be evaluated. (This is a *good* thing in my book, much like avoiding export_all is a good thing... I have enough ComplexityShockHorror in my life as it is) tellerl.pl also acts as a data pipe destination, which is pretty much a requirement for things launched from /etc/aliases or a .qmail-* file. Getting erl_call to do this would be, well, possible, but pretty bodgy (first pipe the data to something that wraps it in an Erlang expression then pipe it to erl_call -e ...) So, yes, I'm marginally aware that I'm reinventing the wheel, but dangit, not all wheels are the same. -Chris From tony@REDACTED Fri May 9 14:43:09 2003 From: tony@REDACTED (Tony Rogvall) Date: Fri, 09 May 2003 14:43:09 +0200 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) References: <1052432047.18715@DNS02> Message-ID: <3EBBA25D.5070904@rogvall.com> > > Out of curiousity, how much does "Kernel Mode Linux" get you toward > your goals? http://www.yl.is.s.u-tokyo.ac.jp/~tosh/kml/ > I could use it to debug the kernel erlang module :-) Erlux will be a kernel only construct or later a standalone thing without userspace at all (at this point modprobe is needs to run in user space) I also have a faint hope that some linux kernel hackers could use Erlux instead of letting the kernel executing shell scripts (as done for hotplug for example) /Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From fritchie@REDACTED Thu May 8 20:32:02 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 08 May 2003 13:32:02 -0500 Subject: Erlang filesystem (a bit long) (was: Re: File versioning) In-Reply-To: Message of "Thu, 08 May 2003 12:03:23 CDT." <20030508120323.625f84a9.cpressey@catseye.mb.ca> Message-ID: <200305081832.h48IW2N4066576@snookles.snookles.com> Too off-topic to continue on the list.... >>>>> "cp" == Chris Pressey writes: cp> I could be blinded by the thousands of horror stories and the cp> unfortunate nickname "Network Failure System" given to it by a cp> guru I highly respect, but I believe that sticking your data on 8" cp> floppy disks and walking it from one computer to the other is cp> superior to NFS in every way :) Ah, you're confusing NFS client implementation with NFS server implementation. If you control the NFS client implementation, you control how it reacts in the event of NFS server or network failure. There's nothing that says that NFS must be implemented by the OS kernel. :-) -Scott From cpressey@REDACTED Fri May 9 18:18:20 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 09 May 2003 11:18:20 -0500 Subject: Erlang filesystem Message-ID: <20030509111820.00c76497.cpressey@catseye.mb.ca> To expand on what I was saying last night while I was falling asleep: On Tue, 6 May 2003 Ulf Wiger wrote: > - Do not use distributed erlang for your user interface. That's essentially my rationale for disallowing the evaluation of arbitrary Erlang functions from tellerl. Of course one could go and write a tellerl handler that allows it to be done, but that'd be silly. 'Eval Scheme'-type silly. (Looking at it in the light of day, the Erlang side of tellerl needs to be seriously rewritten, using a behaviour and maybe proplists - hopefully next week. The Perl side looks just dandy though.) On Thu, 17 Apr 2003 Ulf Wiger wrote: > A common setup is to keep the same code on all nodes -- i.e. > identical application trees. One very good reason for doing > this is to avoid having different versions of the same > module in the system. This is one of the things that got me thinking about a replicated file system. It would be interesting to know how people handle keeping their code in synch across nodes - i.e., what's most popular - rpc:multicall(code, load_binary, [Mod, Bin, File])? rsync? Manually copying the code over when it changes? Using the release handler somehow? Also - this is embarrassing - but I am starting to suspect that for the past two years I've had the wrong impression about the file server (i.e. IoDevices that you get when you call file:open/2 without specifying 'raw'.) I was operating under the assumption that it was trivial to open a file on another node (because I swear I did it once, but my memory might be playing tricks on me, because I've been banging my head against the wall trying to do it again.) It IS trivial to read an entire file from another node: > rpc:call(catbus@REDACTED, file, read_file, [".cshrc"]). {ok,<<35,32,36,70,114,101,101,66,83,68,58,32,115,114,99,47,115, 104,97,114,101,47,115,107,101,108,47,...>>} But when I try just opening it: > {ok,H} = rpc:call(catbus@REDACTED, file, open, [".cshrc", [read]]). {ok,<3931.59.0>} > rpc:call(catbus@REDACTED, file, read, [H, 100]). {error,terminated} > file:format_error({error,terminated}). "unknown POSIX error" Same result if I try merely file:read(H, 100). I'm sure I could get around this by writing a file server process and running it on catbus, but I thought that's why file_server_2 existed in the first place! (I like reinventing the wheel, but not THAT much :) -Chris From kostis@REDACTED Fri May 9 19:36:36 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 9 May 2003 19:36:36 +0200 (MEST) Subject: Paper on HiPE Message-ID: <200305091736.h49Haabi029265@harpo.it.uu.se> We have recently finished writing a short paper titled: All you wanted to know about the HiPE compiler (and might have been afraid to ask) that is intended to be a gentle (i.e., not heavy on technicalities), user-oriented description of features and characteristics of the HiPE native code compiler. The paper is accessible directly from: http://www.csd.uu.se/~kostis/Papers/erlang03.pdf or through HiPE's homepage: http://www.csd.uu.se/projects/hipe/ The following request is quite unconventional, but made nevertheless since we are very much interested in receiving comments from the Erlang User community about its contents. In particular, items that might not be so clear to users, items that would be nice to also include, etc. Your input is appreciated. Cheers, Kostis Sagonas (for the HiPE group) From etxuwig@REDACTED Fri May 9 23:54:05 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 9 May 2003 23:54:05 +0200 (MEST) Subject: Erlang filesystem In-Reply-To: <20030509111820.00c76497.cpressey@catseye.mb.ca> Message-ID: On Fri, 9 May 2003, Chris Pressey wrote: >On Thu, 17 Apr 2003 Ulf Wiger wrote: >> A common setup is to keep the same code on all nodes -- i.e. >> identical application trees. One very good reason for doing >> this is to avoid having different versions of the same >> module in the system. > >This is one of the things that got me thinking about a >replicated file system. > >It would be interesting to know how people handle keeping >their code in synch across nodes - i.e., what's most >popular - rpc:multicall(code, load_binary, [Mod, Bin, >File])? rsync? Manually copying the code over when it >changes? Using the release handler somehow? The release handler works well for this. It's designed to support synchronized upgrade on multiple nodes. >It IS trivial to read an entire file from another node: > > > rpc:call(catbus@REDACTED, file, read_file, [".cshrc"]). > {ok,<<35,32,36,70,114,101,101,66,83,68,58,32,115,114,99,47,115, > 104,97,114,101,47,115,107,101,108,47,...>>} > >But when I try just opening it: > > > {ok,H} = rpc:call(catbus@REDACTED, file, open, [".cshrc", > [read]]). > {ok,<3931.59.0>} > > rpc:call(catbus@REDACTED, file, read, [H, 100]). > {error,terminated} > > file:format_error({error,terminated}). > "unknown POSIX error" Not sure why you get 'terminated', but a problem with doing it this way is that the rpc:call/3 will be executed in a temporary process on catbus; when the call completes, the process is terminated, and since it is the owner of the file descriptor, the file will be closed automatically. I think what you want to do is to run your other nodes as loader slaves to catbus. It's not incredibly clear from the documentation (or I haven't found the place in the documentation where it's clearly described) how to do this. You may try with erl -loader inet -hosts ... or reading the code in file_server.erl, one might perhaps try erl -master catbus@REDACTED, but that doesn't seem to work for me, and I don't find any documentation on it. (I'm sorry I can't give you a working example. From a cursory glance, it's not obvious to me how one tests an erlang node using another erlang node on the same host as a boot loader (it seems consistent with the erlang philosophy that one should be able to do this), and I'm not sure if you need to use a boot server in order to have a file server. I'm sure this is explained in the docs somewhere, but it's late, and I intend to go home and get some sleep.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From rprice@REDACTED Fri May 9 23:54:10 2003 From: rprice@REDACTED (Roger Price) Date: Fri, 9 May 2003 23:54:10 +0200 (CEST) Subject: Testing GS V1.5 Message-ID: As part of a project which generates Erlang code, I probed all the Erlang GS objects with all [1] the Erlang GS options using the three functions gs:create, gs:config and gs:read. During the test I made some notes on what seemed to me to be "anomalies", "unexpected features", "buglets", and errors or omissions in the Erlang GS documentation. The list of 59 items is too long for this mailing list, but if anyone is doing maintenance on GS it might be of interest. It seems to me that GS needs an object/option capability matrix so that consistent error messages can be issued for the many meaningless or buggy combinations of object, option and function. I have a draft of such a matrix which might be of interest to anyone thinking about V1.6. The matrix would also be a useful addition to the documentation. The test was done using Erlang GS V1.5 on SuSE Linux 7.1/8.1 with the fvwm1 window manager. Roger [1] The current test omits options specific to grid and gridline. From eric.melbardis@REDACTED Sat May 10 01:29:02 2003 From: eric.melbardis@REDACTED (Eric P. Melbardis) Date: Fri, 9 May 2003 16:29:02 -0700 Subject: ssl & yaws Message-ID: <4405D76EF1E9D4119B2700A0CC754C7C2A2DC5@postoffice.netkitsolutions.com> hi all, I am using erlang r9b-1/yaws (1.2) in an intel win32 windows/xp environment. I tried to enable ssl support. - downloaded latest version of opnessl (compiled & installed it) with vc 7.0 (.net!) - re-compiled the erlang driver in the erlang library (driver was compiled for earlier version of ssl, and the main init symbol was changed. - configured yaws.conf for ssl operation i connected to the configured web site using https://.... got the first page, everything ok. second page request came back ok, however the werl process started to consume 100% cpu subsequent pages still came back ok cpu remains 100% so it appears to work ok (in returning pages), except for the massive cpu utilization which remains constant after the second page! has any one experienced something like this? figured i would ask first, before diving in..... thanks for any insight/help eric From fritchie@REDACTED Sat May 10 06:52:49 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 09 May 2003 23:52:49 -0500 Subject: Jungerl: bugfix in the posix_drv driver Message-ID: <200305100452.h4A4qnN4088790@snookles.snookles.com> For what it's worth... ... I fixed a significant bug in the getgrnam() and getgrgid() portions of the posix_drv driver (in the Jungerl collection). POSIX functions supported by the driver: getegid geteuid getgid getgrgid getgrnam getgroups getlogin getpgrp getppid getpwnam getpwuid getsid getuid kill lstat mkfifo mknod umask If there are other POSIX'ish functions that aren't currently supported by an OTP library somewhere but you'd like to see it implemented, let me know. I've intentionally avoided implemented system calls such as setuid(), but if someone wants them, they're easy to add. -Scott From cpressey@REDACTED Sat May 10 23:38:19 2003 From: cpressey@REDACTED (Chris Pressey) Date: Sat, 10 May 2003 16:38:19 -0500 Subject: Erlang filesystem In-Reply-To: References: <20030509111820.00c76497.cpressey@catseye.mb.ca> Message-ID: <20030510163819.74690afc.cpressey@catseye.mb.ca> On Fri, 9 May 2003 23:54:05 +0200 (MEST) Ulf Wiger wrote: > On Fri, 9 May 2003, Chris Pressey wrote: > > > {ok,H} = rpc:call(catbus@REDACTED, file, open, [".cshrc", > > [read]]). > > {ok,<3931.59.0>} > > > rpc:call(catbus@REDACTED, file, read, [H, 100]). > > {error,terminated} > > > file:format_error({error,terminated}). > > "unknown POSIX error" > > Not sure why you get 'terminated', but a problem with doing > it this way is that the rpc:call/3 will be executed in a > temporary process on catbus; when the call completes, the > process is terminated, and since it is the owner of the file > descriptor, the file will be closed automatically. Ah, that makes sense. I tried various ways of working around this, but as they got increasingly complex with still no luck, I gave up on this approach. > I think what you want to do is to run your other nodes as > loader slaves to catbus. It's not incredibly clear from the > documentation (or I haven't found the place in the > documentation where it's clearly described) how to do this. > You may try with erl -loader inet -hosts ... That's pretty neat :) After I figured out that I had to start erl with -mode embedded as well, I got catbus to load all its code from the other computer (whose node started erl_boot_server, so actually catbus was the loader slave) - and proved it to myself by removing $ROOT/lib ... neat! Only weirdness was the following messages on catbus on startup: exec: ose_inet: not found And on exiting: Error in process <0.2.0> with exit value: {badarg,[{erlang,unlink, [noport]},{erl_prim_loader,stop_port,1},{erl_prim_loader,loop,3}]} But it otherwise worked fine. > or reading the code in file_server.erl, one might perhaps > try erl -master catbus@REDACTED, but that doesn't seem > to work for me, and I don't find any documentation on it. Me neither, it just hangs when I try it. > (I'm sorry I can't give you a working example. From a > cursory glance, it's not obvious to me how one tests an > erlang node using another erlang node on the same host as a > boot loader (it seems consistent with the erlang philosophy > that one should be able to do this), and I'm not sure if you > need to use a boot server in order to have a file server. > I'm sure this is explained in the docs somewhere, but it's > late, and I intend to go home and get some sleep.) > > /Uffe No problem, thanks for pointing me in what seems to be the right direction. I've gained a lot of insight just wrestling with this. If the raison d'etre of the distributed file server is to load code, then it might not be what I'm looking for (not that I know exactly what I'm looking for...) Feels like it'd be limited to erl_prim_loader:get_file/1. Looking at file.erl, it mostly seems to look for processes named file_server or file_server_2 on the *local* node. I'm not sure how one would tell it to look for that process on some external node, besides hacking the source. Although, an intuitive way from a usage perspective would be file:open(".cshrc", [read, {on_node, catbus@REDACTED}]). Or, using "Joe logic", perhaps file:open({catbus@REDACTED, ".cshrc"}, [read]). to make it orthogonal with file:delete({Node, FileName}) et al. Other than that, I don't know where I'm going with this, and I'll have to re-examine my assumptions. -Chris From chris.danx@REDACTED Sun May 11 00:59:03 2003 From: chris.danx@REDACTED (chris.danx) Date: Sun, 11 May 2003 00:59:03 +0200 Subject: GUI stuff? Message-ID: <3EBD8437.6000004@ntlworld.com> Hi, I've been playing with Erlang for a wee while, and would like to do some GUI stuff. Are there any recent bindings to GTK or some other toolkit? I can only find a toolkit which hasn't had releases for a year and no activity (erlgtk). Are bindings hard to do? Any info available on creating a binding? Cheers, Chris From cpressey@REDACTED Sun May 11 03:17:12 2003 From: cpressey@REDACTED (Chris Pressey) Date: Sat, 10 May 2003 20:17:12 -0500 Subject: GUI stuff? In-Reply-To: <3EBD8437.6000004@ntlworld.com> References: <3EBD8437.6000004@ntlworld.com> Message-ID: <20030510201712.2355dfcf.cpressey@catseye.mb.ca> On Sun, 11 May 2003 00:59:03 +0200 "chris.danx" wrote: > Hi, > > I've been playing with Erlang for a wee while, and would like to do > some GUI stuff. Are there any recent bindings to GTK or some other > toolkit? > I can only find a toolkit which hasn't had releases for a year and > no activity (erlgtk). > > Are bindings hard to do? Any info available on creating a binding? > > > Cheers, > Chris Hi Chris, I think it depends on what kind of GUI stuff you want to do. For simple stuff, GS, which uses Tcl/Tk and is included in the base Erlang/OTP distribution, should be just fine. erlgtk should also be OK for most things. It's not totally dormant; I committed a few bug fixes just the other day... but I think the reason there isn't much activity is because it's also fine for simple stuff, and because the project maintainers are keeping busy with other things. (An exception might be Windows; I know GS has had problems with it in the past, not sure what the current situation is. And erlgtk for Windows is getting pretty old (v0.9.0); I've been trying to coax Luke into building a more recent version with offers of Canadian beer and power supplies, but with little luck :) There's also an embryonic X11 binding; it's in the Jungerl. There's also been talk of creating a radically novel GUI in Erlang itself, but that project is still at the "wow that's a cool idea but where to begin" stage :) Many people are of the opinion you should do the GUI in Java or some other language with an emphasis on GUI, and connect it to Erlang in one of any of a number of ways (jinterface, UBF, etc.) Whether this is a better or worse solution probably depends on what your requirements are. As for making bindings, I've never actually done one myself, but the good news is that the theory is simple; it's generally like making any other port program - see the Interoperability Tutorial in the docs. Writing the interface by hand is of course tedious, so there are several tools to automatically generate one; some of them, such as EDTK[1], are rather sophisticated. But if GTK+ 1.2 is all you need, there's no sense in making a new binding; probably more productive to join the erlgtk project on sourceforge (and help me bug the admins into one day bumping the project status to Beta :) -Chris [1] http://www.erlang.org/ml-archive/erlang-questions/200210/msg00058.html From jilani.khaldi@REDACTED Tue May 13 22:01:56 2003 From: jilani.khaldi@REDACTED (Jilani Khaldi) Date: Tue, 13 May 2003 22:01:56 +0200 Subject: Running GS-1.5.1 exmaples... Message-ID: Hi All, How to use the examples in ..\lib\GS-1.5.1\ebin? When I run calc:start(). from \erlang\lib\gs-1.5.1\ebin I get exited: {undef,[{calc,start,[]}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** I can't get any example running. Thanks. -- Jilani Khaldi http://www.jilani.net From kent@REDACTED Tue May 13 23:05:59 2003 From: kent@REDACTED (Kent Boortz) Date: 13 May 2003 23:05:59 +0200 Subject: Running GS-1.5.1 exmaples... In-Reply-To: References: Message-ID: Jilani Khaldi writes: > How to use the examples in ..\lib\GS-1.5.1\ebin? > When I run > calc:start(). > from \erlang\lib\gs-1.5.1\ebin > I get > > exited: {undef,[{calc,start,[]}, > {erl_eval,expr,3}, > {erl_eval,exprs,4}, > {shell,eval_loop,2}]} ** > > I can't get any example running. The Erlang object file is located in the examples directory. You can go down to that directory before starting Erlang or start Erlang with the -pa flag to point out the directory where the object file is located erl -pa ../examples/ebin Note that there is a bug in gs-1.5.1 that may cause problems on Windows. A work around is to start Erlang using werl -gs backend_comm socket kent From fritchie@REDACTED Wed May 14 09:17:17 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 14 May 2003 02:17:17 -0500 Subject: Jungerl changes: autoconf mods, gd1_drv driver Message-ID: <200305140717.h4E7HHN4091219@snookles.snookles.com> Er, I haven't quite figured out if this is the best place to discuss changes to stuff in the Jungerl collection (http://jungerl.sourceforge.net/). If you're not interested, don't read any further. I've made some changes to the autoconf scheme to make compilation of everything on a Solaris platforms(*) error-free(**). I'm quite new to autoconf, so if my style is bad, please fix it. I've added a new driver to Jungerl, gd1_drv. It's a driver for libgd, a C library for dynamic creation of PNG and JPEG images: line drawing, polygons, text, and lots more. (http://www.boutell.com/gd/) The gd1_drv driver will not be compiled by default: you must follow the directions in the CVSROOT/jungerl/lib/gd1_drv/README file in order to compile it. I made additional autoconf changes to support compiling gd1_drv. I don't *think* I broke anything. Please contact me immediately if I did. -Scott (*) I confess that I've only tested under Solaris 8 x86, but the changes are probably applicable to all releases of Solaris. (Er, releases still in use. Solaris 1.x doesn't count. :-) (**) The changes only ensure clean compilation. I haven't actually tested the executables to see if they actually work. From peter@REDACTED Wed May 14 09:47:29 2003 From: peter@REDACTED (peter@REDACTED) Date: Wed, 14 May 2003 08:47:29 +0100 (BST) Subject: Jungerl changes: autoconf mods, gd1_drv driver In-Reply-To: <200305140717.h4E7HHN4091219@snookles.snookles.com> References: <200305140717.h4E7HHN4091219@snookles.snookles.com> Message-ID: <43072.149.254.120.136.1052898449.squirrel@www.lundata.se> Does gd1_drv suppport all functions in the latest version of gd? I had a look at gif-1.0 in the user contrib page, but that supported only an early version on gd (the one that supported gifs). The latest gd version looked much more advanced when I had a glance at it... /Peter > Er, I haven't quite figured out if this is the best place to discuss > changes to stuff in the Jungerl collection > (http://jungerl.sourceforge.net/). If you're not interested, don't > read any further. > > I've made some changes to the autoconf scheme to make compilation of > everything on a Solaris platforms(*) error-free(**). I'm quite new to > autoconf, so if my style is bad, please fix it. > > I've added a new driver to Jungerl, gd1_drv. It's a driver for libgd, > a C library for dynamic creation of PNG and JPEG images: line drawing, > polygons, text, and lots more. (http://www.boutell.com/gd/) The > gd1_drv driver will not be compiled by default: you must follow the > directions in the CVSROOT/jungerl/lib/gd1_drv/README file in order to > compile it. > > I made additional autoconf changes to support compiling gd1_drv. I > don't *think* I broke anything. Please contact me immediately if I > did. > > -Scott > > (*) I confess that I've only tested under Solaris 8 x86, but the > changes are probably applicable to all releases of Solaris. (Er, > releases still in use. Solaris 1.x doesn't count. :-) > > (**) The changes only ensure clean compilation. I haven't actually > tested the executables to see if they actually work. From ds.erl@REDACTED Wed May 14 15:05:17 2003 From: ds.erl@REDACTED (Daniel Solaz) Date: Wed, 14 May 2003 15:05:17 +0200 Subject: trouble with files bigger than 4GB In-Reply-To: References: <3EA4F06D.90703@uab.ericsson.se> <20030423222602.GM53726@frogman.motivity.ca> Message-ID: <200305141453.03322@no.siento.las.piennas> On Thursday 24 April 2003 14:15 Raimo Niskanen wrote: > Would it be sufficient to have kind of the following shell script > (named gcc) before the real gcc in the path? > #!/bin/sh > exec /usr/local/bin/gcc -m64 ${1+"$@"} for the record: the -m64 switch is not supported by the gcc compiler available on my Feb/2000 x86 Solaris box, but exec /opt/sfw/bin/gcc -DFILE_OFFSET_BITS=64 ${1+"$@"} did the trick Erlang compiled without errors and large file handling now works like it does on FreeBSD BUT it seems the docs are right: large file support seems to break other stuff, resulting in errors not found before, so in the end looks like it's better to not enable it -Daniel From fritchie@REDACTED Wed May 14 19:10:56 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 14 May 2003 12:10:56 -0500 Subject: Jungerl changes: autoconf mods, gd1_drv driver In-Reply-To: Message of "Wed, 14 May 2003 08:47:29 BST." <43072.149.254.120.136.1052898449.squirrel@www.lundata.se> Message-ID: <200305141710.h4EHAuN4093563@snookles.snookles.com> >>>>> "p" == writes: p> I had a look at gif-1.0 in the user contrib page, but that supported p> only an early version on gd (the one that supported gifs). GIF support was removed from GD a while ago due to patent encumberance. It now supports PNG, JPEG, XPM (limited, I think), and a couple of internal-use-only formats. p> Does gd1_drv suppport all functions in the latest version of gd? I confess that I have not taken a look at the 2.x branch to see what new stuff has been added or if any of the "old" functions have had their signatures or semantics change. A quick look at the GD announcements suggests that 2.0.12 added, "clipping, antialiased line drawing, character set specification for freetype, optional specification of PNG compression level...." gd1_drv supports GD version 1.8.4, the last in the 1.x branch. Here's a list of functions it supports: gdImageArc gdImageBlue gdImageBoundsSafe gdImageChar gdImageCharUp gdImageColorAllocate gdImageColorClosest gdImageColorDeallocate gdImageColorExact gdImageColorResolve gdImageColorTransparent gdImageColorsTotal gdImageCompare gdImageCopy gdImageCopyMerge gdImageCopyMergeGray gdImageCopyResized gdImageCreate gdImageCreateFromGd gdImageCreateFromGd2 gdImageCreateFromGd2Part gdImageCreateFromJpeg gdImageCreateFromPng gdImageCreateFromXpm gdImageDestroy gdImageFill gdImageFillToBorder gdImageFilledPolygon gdImageFilledRectangle gdImageGd gdImageGd2 gdImageGd2Ptr gdImageGdPtr gdImageGetInterlaced gdImageGetPixel gdImageGetTransparent gdImageGreen gdImageInterlace gdImageJpeg gdImageJpegFILE gdImageJpegPtr gdImageLine gdImagePaletteCopy gdImagePng gdImagePngFILE gdImagePngPtr gdImagePolygon gdImageRectangle gdImageRed gdImageSX gdImageSY gdImageSetBrush gdImageSetPixel gdImageSetStyle gdImageSetTile gdImageString gdImageStringUp gdImageWBMP gdImageWBMPPtr getFontPtr If anyone wants support for version 2.x, let me know. Otherwise, I don't have immediate plans to look at it. -Scott From matthias@REDACTED Wed May 14 19:45:04 2003 From: matthias@REDACTED (Matthias Lang) Date: Wed, 14 May 2003 19:45:04 +0200 Subject: windows socket problem/limitation Message-ID: <16066.32928.503761.159465@antilipe.corelatus.se> Hi, Is there a Microsoft-Windows-specific limit to how much data you're allowed to transmit in one call to gen_tcp:send()? I was surprised by this a few days ago: 3> {ok, Bin} = file:read_file("my_big_file"), {ok,<<31,139,8,0,188,22,53...>>} 4> size(Bin). 5047116 5> {ok, S} = gen_tcp:connect("172.16.2.3", 2089, []). {ok,#Port<0.37>} 6> gen_tcp:send(S, Bin). {error, einval} worked just fine if I took a smaller file. Works just fine with a large file under linux. I believe the machine was running R8B on Windows 2k. I'm not 100% sure---it wasn't my machine and I wasn't in a position to debug it. Seem familiar to anyone? Matthias From csanto@REDACTED Wed May 14 20:22:53 2003 From: csanto@REDACTED (Corrado Santoro) Date: Wed, 14 May 2003 20:22:53 +0200 Subject: Registered name of a process from its PID Message-ID: <1052936573.3ec2897d3627d@www.cdc.unict.it> Hi all, before I start to write lines of code using registered/0 and whereis/1 BIFs, I would like to know if there is a BIF to obtain the registered name of process starting from its PID. Something like the inverse of the whereis/1 function. Thanks, -Corrado -- ====================================================== Eng. Corrado Santoro, Ph.D. Unversity of Catania - Engineering Faculty Department of Computer Science and Telecommunications Engineering Viale A. Doria, 6 - 95125 CATANIA (ITALY) Tel: +39 095 7382364 Fax: +39 095 338280 EMail: csanto@REDACTED Personal Home Page: http://www.diit.unict.it/users/csanto NUXI Home Page: http://nuxi.iit.unict.it ====================================================== ------------------------------------------------- This mail sent through IMP: http://www.cdc.unict.it/ From svg@REDACTED Wed May 14 20:42:46 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Thu, 15 May 2003 00:42:46 +0600 (YEKST) Subject: Registered name of a process from its PID In-Reply-To: <1052936573.3ec2897d3627d@www.cdc.unict.it> References: <1052936573.3ec2897d3627d@www.cdc.unict.it> Message-ID: <20030515.004246.78708115.svg@surnet.ru> Good day, csanto> before I start to write lines of code using registered/0 and whereis/1 BIFs, I csanto> would like to know if there is a BIF to obtain the registered name of process csanto> starting from its PID. Something like the inverse of the whereis/1 function. process_info(Pid, registered_name) You can get a lot of other useful information with process_info/1,2. Please see `erlang' manpage. Best Regards, Vladimir Sekissov From martin@REDACTED Wed May 14 20:59:51 2003 From: martin@REDACTED (martin j logan) Date: 14 May 2003 13:59:51 -0500 Subject: Registered name of a process from its PID In-Reply-To: <1052936573.3ec2897d3627d@www.cdc.unict.it> References: <1052936573.3ec2897d3627d@www.cdc.unict.it> Message-ID: <1052938791.4267.2798.camel@berimbau.vail> Hello Corrado, A simple way to discover the registered name of a process given a pid() is to use: process_info(Pid) -> InfoList this will return a list of tuples where one will be {registered_name, Atom} An even more straightforward approach would be to use: process_info(Pid, registered_name). Cheers, Martin On Wed, 2003-05-14 at 13:22, Corrado Santoro wrote: > Hi all, > before I start to write lines of code using registered/0 and whereis/1 BIFs, I > would like to know if there is a BIF to obtain the registered name of process > starting from its PID. Something like the inverse of the whereis/1 function. > > Thanks, > -Corrado -- martin j logan From fritchie@REDACTED Thu May 15 01:05:34 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 14 May 2003 18:05:34 -0500 Subject: Release 1.0 of Erlang Driver Toolkit (EDTK) finally done Message-ID: <200305142305.h4EN5YN4096701@snookles.snookles.com> Greetings. I've finally finished fixing bugs and writing enough non-pathetic documentation for the Erlang Driver Toolkit, EDTK, to create a "1.0" release. The source code is available at http://www.snookles.com/erlang/edtk/. The drivers bundled along with the EDTK distribution haven't changed much: Berkeley DB 4.0.14, GD 1.8.4, libnet, libpcap, posix_drv, simple1, and libspread. However, the drivers that EDTK generates are free (as far as I know) of all nasty memory allocation bugs. Furthermore, they all pass their regression tests on FreeBSD, Linux, and Solaris platforms. The non-pathetic documentation is not great, but it's better than nothing. It includes: 1. A tutorial! I wrote the tutorial while I was creating the libgd driver. It demonstrates step-by-step how the driver was created to handle the various wacky data types used by libgd. 2. A FAQ. To be honest, I haven't had many people ask questions about EDTK, so I created a bunch of questions that I asked myself. :-) As always, some of the best documentation is the regression test source code itself, included with each driver. Have fun! -Scott From gerd@REDACTED Thu May 15 15:41:05 2003 From: gerd@REDACTED (Gerd Flaig) Date: Thu, 15 May 2003 15:41:05 +0200 Subject: Attributes of loaded modules Message-ID: Hi, how can I get information about currently loaded modules? I found out about code:is_loaded(foomodule) which gives me the filename of the beam file the module was loaded from. Is there a way to ask if a certain module was compiled with debug_info? Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From etxuwig@REDACTED Thu May 15 15:48:43 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 15 May 2003 15:48:43 +0200 (MEST) Subject: Attributes of loaded modules In-Reply-To: Message-ID: Each erlang module has a generated function, module_info(), which will give you lots of information about the module: Eshell V5.2.3.3 (abort with ^G) 1> queue:module_info(). [{exports,[{new,0},{in,2},{out,1},{to_list,1},{module_info,0},{module_info,1}]}, {imports,[]}, {attributes,[{vsn,[87737766660651954626331902793218912050]}]}, {compile,[{options,[v3, debug_info, {i,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../../kernel/include"}, {i,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../include"}, {outdir,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../ebin"}, {cwd,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src"}]}, {version,"4.1.1"}, {time,{2003,3,13,10,40,2}}]}] There is also a short form in the shell, m(Module). Note that it formats output and then returns 'ok'. 2> m(queue). Module queue compiled: Date: March 13 2003, Time: 10.40 Compiler options: [v3, debug_info, {i,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../../kernel/include"}, {i,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../include"}, {outdir,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../ebin"}, {cwd,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src"}] Object file: /EDUP/Erlang/R9B-1/lib/erlang/lib/stdlib-1.11.4.1/ebin/queue.beam Exports: in/2 module_info/0 module_info/1 new/0 out/1 to_list/1 ok The Module:module_info/1 function will give you a specific subset of the module_info() information: 3> queue:module_info(compile). [{options,[v3, debug_info, {i,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../../kernel/include"}, {i,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../include"}, {outdir,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src/../ebin"}, {cwd,"/home/pkx-macr/wrk/otp/otp_src_R9B-1/lib/stdlib/src"}]}, {version,"4.1.1"}, {time,{2003,3,13,10,40,2}}] /Uffe On Thu, 15 May 2003, Gerd Flaig wrote: >Hi, > >how can I get information about currently loaded modules? I found out >about code:is_loaded(foomodule) which gives me the filename of the >beam file the module was loaded from. > >Is there a way to ask if a certain module was compiled with >debug_info? > > Goodbyte, Gerd. > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From gerd@REDACTED Thu May 15 15:59:24 2003 From: gerd@REDACTED (Gerd Flaig) Date: Thu, 15 May 2003 15:59:24 +0200 Subject: Attributes of loaded modules In-Reply-To: (Ulf Wiger's message of "Thu, 15 May 2003 15:48:43 +0200 (MEST)") References: Message-ID: Ulf Wiger writes: > Each erlang module has a generated function, module_info(), > which will give you lots of information about the module: thank you, this was most helpful. Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From cpressey@REDACTED Fri May 16 04:03:40 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 15 May 2003 21:03:40 -0500 Subject: tellerl 2003.0515 Message-ID: <20030515210340.62a5343c.cpressey@catseye.mb.ca> Just a note to let you know that I overhauled tellerl. http://www.catseye.mb.ca/projects/tellerl-2003.0515/ In keeping with the methodology of "allowing specific Erlang services to be accessed as if they were shell utilities", it now: - uses a callback module which conforms to the tellerl_server behaviour; - has tellerl.pl send the current directory to the tellerl_server; - parses the message sent to it using a simple callback-defined layout; - allows the tellerl_server to ignore input to tellerl.pl, if desired; - has tellerl_server stream its output in chunks to tellerl.pl; - has tellerl.pl exit with an exit code given to it by tellerl_server; - has been tested on Windows. Still not well documented; when I get around to that I'll toss it into the Jungerl, too. -Chris From snickl@REDACTED Fri May 16 09:54:45 2003 From: snickl@REDACTED (Stefan Nickl) Date: Fri, 16 May 2003 09:54:45 +0200 (CEST) Subject: Cool-looking GUI Toolkit Message-ID: I just saw this project scrolling by on freshmeat.net, it reminded me of the GUI discussion that was going on here some time ago: http://ngl.sourceforge.net/news.php (go for "Screenshots") CU, SN -- The UNIX equivalent of the "Blue Screen of Death" would be called "kernel panic". It obviously exists, since I have heard and read about it, but I've never been witness to it in my professional career. John Kirch, Networking Consultant and Microsoft Certified Professional (Windows NT) From peter@REDACTED Fri May 16 19:51:09 2003 From: peter@REDACTED (Peter H|gfeldt) Date: Fri, 16 May 2003 19:51:09 +0200 (MET DST) Subject: Erlang Code Replacement In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA9410DD99DC8@edeacnt100.eed.ericsson.se> Message-ID: Borja, Try the URL www.erlang.org/doc/misc. There you find a few documents about Erlang code replacement written by me. I copy this mail to the erlang-questions list, since the above URL might of general interest. Regards, Peter On Fri, 16 May 2003, Francisco Borja Carbo Malonda (EED) wrote: > > > Hello Peter > > The web page http://www.erlang-projects.org/Public/documentation/tutorials/erlangotp_tutorials/tutorial_erlang_cod/view indicates you have written an good "document explaining Erlang code replacement (Hot code upgrade)." > > I am very interested on the topic. However the link in that web page is not valid. > > Is there any other way to access your document? Could you send a electronic copy to me? > > Thanks a lot for your support. > > Best Regards / Borja > From fritchie@REDACTED Fri May 16 22:17:48 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 16 May 2003 15:17:48 -0500 Subject: Any pending improvements to async thread pool? Message-ID: <200305162017.h4GKHmN4015065@snookles.snookles.com> Hi there. I've a question for the OTP team: are there any improvements to the async thread pool that might be appearing in a future Erlang release? Last night I was bitten by a "feature" that I've known about for ages but had forgotten about.(*) If I have a driver D that utilizes the async thread pool, and if that driver gives an async thread a task T that takes many seconds to finish, then it's quite possible to block task T' by another driver (also using the async thread pool) until task T has finished. As an example, say I've got a driver that executes the C library's sleep(200) call using an async thread.(**) Then, I try launching the debugger (or "pman" or "appmon" or whatever). The application won't run for 200 seconds... ... because the "efile_drv" driver is also using the async thread pool. The task of operating on one of the beam files is assigned by efile_drv to the same thread that's executing the sleep(200). The result is a lot of wasted time. The current scheme for mapping tasks to a particular thread is, IMHO, broken. A short-term solution is to manage my own async worker thread(s) rather than using the async thread pool already provided. However, given that "efile_drv" can end up blocking *itself* by trying to operate on slow media (CD-ROM, NFS, Flash-based storage, or even a really busy local on-disk file system(***)), I think it ought to be fixed. If there are other idle threads available, they should be usable. -Scott (*) I mentioned this in my Erlang Driver Toolkit paper: section 7.3, last paragraph. (**) That's the first driver using async threads I wrote. :-) However, any computation that takes a long time is sufficient. (***) Back when I was running USENET News servers, I had file systems so busy that a single open(), link, or unlink() system call sometimes took 3/4 of a second. Each. I don't recommend workloads that high. From chris.danx@REDACTED Sun May 18 19:16:28 2003 From: chris.danx@REDACTED (chris.danx) Date: Sun, 18 May 2003 19:16:28 +0200 Subject: and-ing, or-ing? Message-ID: <3EC7BFEC.6060502@ntlworld.com> Hi, How do you "and" two truth states? In the following "addEdge" function It is supposed to add an edge if and only if both vertices exist... the function existsVertex is defined to return true if a vertex exists in a given graph. %% return true if given vertex is in the graph. %% existsVertex(N, {graph, []}) -> false; existsVertex(N, {graph, [{N,Y}|Xs]}) -> true; existsVertex(N, {graph, [_|Xs]}) -> existsVertex (N, {graph, Xs}). %% create connection between given vertices %% addEdge (N, M, {graph, []}) -> nil; addEdge (N, M, {graph, L}) -> bothExist = ??? if bothExist -> {graph, []}; true -> {error, {graph, L}} end. It's not complete yet, the return values are just temporary until I figure out how to check the vertices exist... Cheers, Chris p.s. I might add a function which returns an existing {vertex, [edge]} tuple to make it more efficient, but for now I'm keeping it simple. From svg@REDACTED Sun May 18 21:06:03 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Mon, 19 May 2003 01:06:03 +0600 (YEKST) Subject: and-ing, or-ing? In-Reply-To: <3EC7BFEC.6060502@ntlworld.com> References: <3EC7BFEC.6060502@ntlworld.com> Message-ID: <20030519.010603.74736650.svg@surnet.ru> Good day, existsVertex(N, Graph) and existsVertex(M, Graph) or better existsVertex(N, Graph) andalso existsVertex(M, Graph) andalso - C-like "and", second argument is not calculated if first is false. Or-ing: existsVertex(N, Graph) or existsVertex(M, Graph) existsVertex(N, Graph) orelse existsVertex(M, Graph) And slightly shorter function for your case would be existsVertexes(Vertexes, {graph, G}) -> ExistsVertexes = [N || {N, _} <- G, lists:memeber(N,Vertexes) == true], length(Vertexes) == length(ExistsVertexes). existsVertexes([N, M], Graph). Best Regards, Vladimir Sekissov chris.danx> How do you "and" two truth states? In the following "addEdge" function chris.danx> It is supposed to add an edge if and only if both vertices exist... the chris.danx> function existsVertex is defined to return true if a vertex exists in a chris.danx> given graph. chris.danx> chris.danx> chris.danx> %% return true if given vertex is in the graph. chris.danx> %% chris.danx> existsVertex(N, {graph, []}) -> chris.danx> false; chris.danx> existsVertex(N, {graph, [{N,Y}|Xs]}) -> chris.danx> true; chris.danx> existsVertex(N, {graph, [_|Xs]}) -> chris.danx> existsVertex (N, {graph, Xs}). chris.danx> chris.danx> chris.danx> %% create connection between given vertices chris.danx> %% chris.danx> addEdge (N, M, {graph, []}) -> chris.danx> nil; chris.danx> addEdge (N, M, {graph, L}) -> chris.danx> bothExist = ??? chris.danx> if bothExist -> chris.danx> {graph, []}; chris.danx> true -> chris.danx> {error, {graph, L}} chris.danx> end. chris.danx> chris.danx> chris.danx> It's not complete yet, the return values are just temporary until I chris.danx> figure out how to check the vertices exist... chris.danx> chris.danx> chris.danx> Cheers, chris.danx> Chris chris.danx> chris.danx> p.s. I might add a function which returns an existing {vertex, [edge]} chris.danx> tuple to make it more efficient, but for now I'm keeping it simple. From chris.danx@REDACTED Sun May 18 20:58:43 2003 From: chris.danx@REDACTED (chris.danx) Date: Sun, 18 May 2003 20:58:43 +0200 Subject: and-ing, or-ing? In-Reply-To: <20030519.010603.74736650.svg@surnet.ru> References: <3EC7BFEC.6060502@ntlworld.com> <20030519.010603.74736650.svg@surnet.ru> Message-ID: <3EC7D7E3.3060507@ntlworld.com> Vladimir Sekissov wrote: > Good day, > > existsVertex(N, Graph) and existsVertex(M, Graph) > > or better > > existsVertex(N, Graph) andalso existsVertex(M, Graph) thanks! > And slightly shorter function for your case would be > > existsVertexes(Vertexes, {graph, G}) -> > ExistsVertexes = [N || {N, _} <- G, lists:memeber(N,Vertexes) == true], > length(Vertexes) == length(ExistsVertexes). > > existsVertexes([N, M], Graph). Thankyou, I didn't know Erlang had list comprehensions... maybe I missed it in the Erlang book? I will look later. Chris From ekarttun@REDACTED Sun May 18 22:56:22 2003 From: ekarttun@REDACTED (Einar Karttunen) Date: Sun, 18 May 2003 23:56:22 +0300 Subject: and-ing, or-ing? In-Reply-To: <3EC7D7E3.3060507@ntlworld.com> References: <3EC7BFEC.6060502@ntlworld.com> <20030519.010603.74736650.svg@surnet.ru> <3EC7D7E3.3060507@ntlworld.com> Message-ID: <20030518205622.GA31099@melkki.cs.Helsinki.FI> On 18.05 20:58, chris.danx wrote: > Thankyou, I didn't know Erlang had list comprehensions... maybe I missed > it in the Erlang book? I will look later. List comprehensions are a recent feature in Erlang, thus not described in the Erlang book. However there is quite good documentation for them online: http://www.erlang.org/doc/r9b/doc/extensions/list_comprehensions.html ps. Erlang has many other nixw features like higher order functions and records not detailed in the book, so reading the whole "new features" (not really new anymore) might be wise... - Einar Karttunen From raimo.niskanen@REDACTED Mon May 19 09:03:30 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Mon, 19 May 2003 09:03:30 +0200 Subject: Any pending improvements to async thread pool? References: <200305162017.h4GKHmN4015065@snookles.snookles.com> Message-ID: Hi Scott, the changes are still pending; they will not come in R9C. Maybe R10. The simplest fairly backwards compatible change I can think of is to have the threads pick jobs from the queues in a round-robin fashinon instead of as today one thread always picks from the same queue. I also think that it would be a farly simple change. / Raimo Niskanen, Erlang/OTP, Ericsson AB Scott Lystig Fritchie wrote: > Hi there. I've a question for the OTP team: are there any > improvements to the async thread pool that might be appearing in a > future Erlang release? > > Last night I was bitten by a "feature" that I've known about for ages > but had forgotten about.(*) If I have a driver D that utilizes the > async thread pool, and if that driver gives an async thread a task T > that takes many seconds to finish, then it's quite possible to block > task T' by another driver (also using the async thread pool) until > task T has finished. > > As an example, say I've got a driver that executes the C library's > sleep(200) call using an async thread.(**) Then, I try launching the > debugger (or "pman" or "appmon" or whatever). The application won't > run for 200 seconds... > > ... because the "efile_drv" driver is also using the async thread > pool. The task of operating on one of the beam files is assigned by > efile_drv to the same thread that's executing the sleep(200). The > result is a lot of wasted time. > > The current scheme for mapping tasks to a particular thread is, IMHO, > broken. A short-term solution is to manage my own async worker > thread(s) rather than using the async thread pool already provided. > > However, given that "efile_drv" can end up blocking *itself* by trying > to operate on slow media (CD-ROM, NFS, Flash-based storage, or even a > really busy local on-disk file system(***)), I think it ought to be > fixed. If there are other idle threads available, they should be > usable. > > -Scott > > (*) I mentioned this in my Erlang Driver Toolkit paper: section 7.3, > last paragraph. > > (**) That's the first driver using async threads I wrote. :-) > However, any computation that takes a long time is sufficient. > > (***) Back when I was running USENET News servers, I had file systems > so busy that a single open(), link, or unlink() system call sometimes > took 3/4 of a second. Each. I don't recommend workloads that high. From sean.hinde@REDACTED Mon May 19 15:19:38 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 19 May 2003 14:19:38 +0100 Subject: Bignum arithmetic Message-ID: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> Hi all, For a bit of light relief I figured it would be fun to make an ssh client in Erlang. I figured that with such good bignum support it wouldn't be too tricky. So. has anyone any good ideas how to calculate: 2^1292065245826370511117936813749663282546492063092432089491783276644646 6504617309746646057975239671809 without a badarith error? Tried so far: math:pow(2, Big_num). % Ha Ha! 1 bsl Bignum. % I had hopes for this one.. Thanks, Sean From bjorn@REDACTED Mon May 19 15:58:05 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 19 May 2003 15:58:05 +0200 Subject: Bignum arithmetic In-Reply-To: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> References: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> Message-ID: Assuming that you really want 2^129... modulo some other number, you can do repeated multiplications and taking remainders as you go, like this: t() -> N = 12920652458263705111179368137496632825464920630924320894917832766446466504617309746646057975239671809, Base = 1000000000000000000000000000000, pow_mod(N, Base). pow_mod(0, _) -> 1; pow_mod(1, _) -> 2; pow_mod(N, B) -> X = pow_mod(N div 2, B), P = case N rem 2 of 0 -> X*X; 1 -> 2*X*X end, P rem B. I have not verified the result, but the program does seems to work for smaller values of N. /Bjorn Sean Hinde writes: > Hi all, > > For a bit of light relief I figured it would be fun to make an ssh > client in Erlang. I figured that with such good bignum support it > wouldn't be too tricky. So. has anyone any good ideas how to calculate: > > 2^1292065245826370511117936813749663282546492063092432089491783276644646 > 6504617309746646057975239671809 > > without a badarith error? > > Tried so far: > > math:pow(2, Big_num). % Ha Ha! > > 1 bsl Bignum. % I had hopes for this one.. > > Thanks, > > Sean > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From joe@REDACTED Mon May 19 15:58:34 2003 From: joe@REDACTED (Joe Armstrong) Date: Mon, 19 May 2003 15:58:34 +0200 (CEST) Subject: Bignum arithmetic In-Reply-To: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> Message-ID: On Mon, 19 May 2003, Sean Hinde wrote: > Hi all, > > For a bit of light relief I figured it would be fun to make an ssh > client in Erlang. I figured that with such good bignum support it > wouldn't be too tricky. So. has anyone any good ideas how to calculate: > > 2^1292065245826370511117936813749663282546492063092432089491783276644646 > 6504617309746646057975239671809 > > without a badarith error? Yes - buy a bigger computer - say with about 1.9 * 10^86 peta bytes of memory. This number is about 3.88912e+99 If you store 2 digits/byte then you could store 2*10^12 digtes/tera-byte /Joe > > Tried so far: > > math:pow(2, Big_num). % Ha Ha! > > 1 bsl Bignum. % I had hopes for this one.. > > Thanks, > > Sean > From bernardp@REDACTED Mon May 19 16:11:28 2003 From: bernardp@REDACTED (Pierpaolo BERNARDI) Date: Mon, 19 May 2003 16:11:28 +0200 Subject: Bignum arithmetic References: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> Message-ID: <016601c31e10$8b301500$06f36850@c1p4e3> From: "Sean Hinde" > For a bit of light relief I figured it would be fun to make an ssh > client in Erlang. I figured that with such good bignum support it > wouldn't be too tricky. So. has anyone any good ideas how to calculate: > > 2^1292065245826370511117936813749663282546492063092432089491783276644646 > 6504617309746646057975239671809 What do you mean with "calculate"? That number, if expressed in decimal has 3.9?10^99 digits. The universe is not big enough to contain all these digits. 8-) Why do you think you need to calculate this number to implement ssh (I don't know the details of ssh)? Note that if you need to calculate 2^BigNumber mod ReasonableNumber, then there's no need to calculate 2^BigNumber. Cheers, P. From vlad_dumitrescu@REDACTED Mon May 19 16:33:31 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 19 May 2003 16:33:31 +0200 Subject: DotNet Message-ID: Hello everyone, It's been quite quiet lately around here :-) so I thought I'd start a new controversy. No, not really. I got a new job where I will get in touch with DotNet and C# and such monsters. I thought that I might do something fun as a "teach yourself" project: porting JInterface to C#. I think it would be quite straightforward to port most of it, with possible problem areas being streaming and socket communication. Would such a project be of some interest to anyone else than me? I mean real interest as opposed to "just curious" :-) best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.hinde@REDACTED Mon May 19 16:36:47 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 19 May 2003 15:36:47 +0100 Subject: Bignum arithmetic In-Reply-To: Message-ID: <51B362C7-8A07-11D7-A32E-000393A45C3C@mac.com> On Monday, May 19, 2003, at 02:58 PM, Joe Armstrong wrote: > On Mon, 19 May 2003, Sean Hinde wrote: > >> Hi all, >> >> For a bit of light relief I figured it would be fun to make an ssh >> client in Erlang. I figured that with such good bignum support it >> wouldn't be too tricky. So. has anyone any good ideas how to >> calculate: >> >> 2^12920652458263705111179368137496632825464920630924320894917832766446 >> 46 >> 6504617309746646057975239671809 >> >> without a badarith error? > > Yes - buy a bigger computer - say with about 1.9 * 10^86 peta bytes of > memory. > > This number is about 3.88912e+99 > > If you store 2 digits/byte then you could store > > 2*10^12 digtes/tera-byte > > > /Joe Ah yes, that would be the problem then - shoulda thunk for a short while longer before posting ;) I think I need to revisit my interpretation of the RFC.. Sean From sean.hinde@REDACTED Mon May 19 16:45:07 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 19 May 2003 15:45:07 +0100 Subject: Bignum arithmetic In-Reply-To: <016601c31e10$8b301500$06f36850@c1p4e3> Message-ID: <7C40E91D-8A08-11D7-A32E-000393A45C3C@mac.com> On Monday, May 19, 2003, at 03:11 PM, Pierpaolo BERNARDI wrote: > From: "Sean Hinde" > >> For a bit of light relief I figured it would be fun to make an ssh >> client in Erlang. I figured that with such good bignum support it >> wouldn't be too tricky. So. has anyone any good ideas how to >> calculate: >> >> 2^12920652458263705111179368137496632825464920630924320894917832766446 >> 46 >> 6504617309746646057975239671809 > > What do you mean with "calculate"? > > That number, if expressed in decimal has 3.9?10^99 digits. > The universe is not big enough to contain all these digits. 8-) > > Why do you think you need to calculate this number to implement ssh > (I don't know the details of ssh)? Note that if you need to calculate > 2^BigNumber mod ReasonableNumber, then there's no need to > calculate 2^BigNumber. Aha! Any pointers on how to do this? Thanks, Sean From svg@REDACTED Mon May 19 17:23:20 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Mon, 19 May 2003 21:23:20 +0600 (YEKST) Subject: Bignum arithmetic In-Reply-To: <7C40E91D-8A08-11D7-A32E-000393A45C3C@mac.com> References: <016601c31e10$8b301500$06f36850@c1p4e3> <7C40E91D-8A08-11D7-A32E-000393A45C3C@mac.com> Message-ID: <20030519.212320.71106066.svg@surnet.ru> Good day, sean.hinde> > 2^BigNumber mod ReasonableNumber, then there's no need to sean.hinde> > calculate 2^BigNumber. sean.hinde> sean.hinde> Aha! Any pointers on how to do this? Volume 2 of Donald Knuth's "The Art of Computer Programming" is now your best friend. Or search google with "arbitrary precision arithmetic". Best Regards, Vladimir Sekissov From sean.hinde@REDACTED Mon May 19 17:23:44 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 19 May 2003 16:23:44 +0100 Subject: Bignum arithmetic In-Reply-To: <7C40E91D-8A08-11D7-A32E-000393A45C3C@mac.com> Message-ID: On Monday, May 19, 2003, at 03:45 PM, Sean Hinde wrote: > > On Monday, May 19, 2003, at 03:11 PM, Pierpaolo BERNARDI wrote: > >> From: "Sean Hinde" >> >>> For a bit of light relief I figured it would be fun to make an ssh >>> client in Erlang. I figured that with such good bignum support it >>> wouldn't be too tricky. So. has anyone any good ideas how to >>> calculate: >>> >>> 2^1292065245826370511117936813749663282546492063092432089491783276644 >>> 646 >>> 6504617309746646057975239671809 >> >> What do you mean with "calculate"? >> >> That number, if expressed in decimal has 3.9?10^99 digits. >> The universe is not big enough to contain all these digits. 8-) >> >> Why do you think you need to calculate this number to implement ssh >> (I don't know the details of ssh)? Note that if you need to calculate >> 2^BigNumber mod ReasonableNumber, then there's no need to >> calculate 2^BigNumber. > > Aha! Any pointers on how to do this? OK, OK, I get it. Suddenly there is some more work to do.. Sean From sean.hinde@REDACTED Mon May 19 17:55:17 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 19 May 2003 16:55:17 +0100 Subject: Bignum arithmetic In-Reply-To: <20030519.212320.71106066.svg@surnet.ru> Message-ID: <4933EFBF-8A12-11D7-A32E-000393A45C3C@mac.com> On Monday, May 19, 2003, at 04:23 PM, Vladimir Sekissov wrote: > Good day, > > sean.hinde> > 2^BigNumber mod ReasonableNumber, then there's no need to > sean.hinde> > calculate 2^BigNumber. > sean.hinde> > sean.hinde> Aha! Any pointers on how to do this? > > Volume 2 of Donald Knuth's "The Art of Computer Programming" is now > your best friend. > > Or search google with "arbitrary precision arithmetic". > Thanks. Here's what turned up. Translated from C: % Calculate M ^ P mod Q modexp(M, P, Q) -> modexp(M, P, Q, 1). modexp(M, 0, Q, Z) -> Z; modexp(M, P, Q, Z) -> Z1 = if ((P band 1) == 1) -> Z * M rem Q; true -> Z end, M1 = M * M rem Q, P1 = P bsr 1, modexp(M1, P1, Q, Z1). Cheers, Sean From per.gustafsson@REDACTED Mon May 19 16:03:53 2003 From: per.gustafsson@REDACTED (Per Gustafsson) Date: Mon, 19 May 2003 16:03:53 +0200 (MEST) Subject: Bignum arithmetic In-Reply-To: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> References: <8B0AAA0A-89FC-11D7-A32E-000393A45C3C@mac.com> Message-ID: You can't represent 2^1292065245826370511117936813749663282546492063092432089491783276644646 6504617309746646057975239671809 as an erlang bignum as that would require 1292065245826370511117936813749663282546492063092432089491783276644646 6504617309746646057975239671810 bits. That would be too much for most computers. You probably have to represent the number as a tuple {2, 1292065245826370511117936813749663282546492063092432089491783276644646 6504617309746646057975239671809} and use some tricky arithmetic. Per Gustafsson On Mon, 19 May 2003, Sean Hinde wrote: > Hi all, > > For a bit of light relief I figured it would be fun to make an ssh > client in Erlang. I figured that with such good bignum support it > wouldn't be too tricky. So. has anyone any good ideas how to calculate: > > 2^1292065245826370511117936813749663282546492063092432089491783276644646 > 6504617309746646057975239671809 > > without a badarith error? > > Tried so far: > > math:pow(2, Big_num). % Ha Ha! > > 1 bsl Bignum. % I had hopes for this one.. > > Thanks, > > Sean > > From Erik.Reitsma@REDACTED Mon May 19 15:47:22 2003 From: Erik.Reitsma@REDACTED (Erik Reitsma (ETM)) Date: Mon, 19 May 2003 15:47:22 +0200 Subject: Bignum arithmetic Message-ID: <440A2703A54A8F4FB2AC2AE34F27129D215A5D@ESEALNT889.al.sw.ericsson.se> > For a bit of light relief I figured it would be fun to make an ssh > client in Erlang. I figured that with such good bignum support it > wouldn't be too tricky. So. has anyone any good ideas how to > calculate: > > 2^129206524582637051111793681374966328254649206309243208949178 > 3276644646 > 6504617309746646057975239671809 > > without a badarith error? I do not think that this will work, since the result will have 12920652458263705111179368137496632825464920630924320894917832766446466504617309746646057975239671809 bits. :) :) I do not think that you have enough memory to store such a large number (understatement...). You may need every atom in the universe to store such a large number :) So, you will not be able to calculate this number, in any way. Since you will have to take the remainder of the result after division by some number (I presume), you will have to multiply step by step (in a smart way), taking remainders after every step. *Erik. From vlad_dumitrescu@REDACTED Tue May 20 06:38:15 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 20 May 2003 06:38:15 +0200 Subject: Very strange behaviour! Message-ID: Hello good people, I got some time to try to do some stuff at home, where I just finished reinstalling my PC from scratch, and today Erlang seems to not want to start!... When running erl, or erlc, or werl, nothing happens, no matter how long one waits (well, a few minutes anyway). Pressing ^C will bring up the "BREAK: (a)bort..." printout, but that's it. I even reinstalled R9B-1, without success. Does anyone know what this may be about? I thought I had enough problems trying to figure out why Distel doesn't want to work... :-) thanks in advance. Regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad_dumitrescu@REDACTED Tue May 20 08:24:55 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 20 May 2003 08:24:55 +0200 Subject: Very strange behaviour! References: Message-ID: Oh, and it seems like it's the same at work... very strange! It is also on Windows (XP and 2000), where it worked before. I think it's about a week since I tried last time. And now, it just hangs and does nothing... Any ideas about what the problem might be? regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad_dumitrescu@REDACTED Tue May 20 08:28:09 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 20 May 2003 08:28:09 +0200 Subject: Very strange behaviour! References: Message-ID: A correction: at least here at work, the prompt appears after 40 seconds. It may be the same at home but I didn't wait that long (or more since there it's a slower pc) regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From fritchie@REDACTED Tue May 20 09:22:31 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 20 May 2003 02:22:31 -0500 Subject: New Jungerl addition: Spread driver Message-ID: <200305200722.h4K7MV24071943@snookles.snookles.com> I've just added a driver for the Spread reliable multicast library to the Jungerl collection. As always, see http://jungerl.sourceforge.net/http://sourceforge.net/projects/jungerl and http://jungerl.sourceforge.net/ for info on Jungerl. Spread is the communications library behind such nifty projects as PostgreSQL-R (PostgreSQL + synchronous replication of multiple servers) and Wackamole (an IP address migration tool). Quoting from the docs at http://www.spread.org/docs/docspread.html "Spread is a toolkit that provides a high performance messaging service that is resilient to faults across external or internal networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast and group communication support. Spread services range from reliable message passing to fully ordered messages with delivery guarantees, even in case of computer failures and network partitions." The spread_drv driver in the Jungerl is significantly different than the spread driver found my Erlang Driver Toolkit version 1.0 distribution. If you're tempted to try using this driver, the code I just checked in to the Jungerl is much more robust, many more features, *and* less buggy. I hope the docs are clear enough to build & test it out. As always, send questions and flames to me. -Scott From francesco@REDACTED Tue May 20 22:43:22 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 20 May 2003 21:43:22 +0100 Subject: Erl Lounge London 28/5 Message-ID: <3ECA936A.1050706@erlang-consulting.com> Sorry for using the list, but I wanted to make any new London/UK Erlang mailing list members aware that since our first "Erl Lounge" about a year ago, a group of us irregularly meet in various watering holes around the capital, discussing message passing, problems with garbage collecting, concurrency, hardships of finding reliable workers, and complaining that they are in constant need of supervision. (The visiting Swedes usually complain over the price of beer in Sweden until they realize the pub closes at 11 and that the beer is actually more expensive here). We are meeting again next Wednesday the 28th, 7PM at the Lowlander in central London. Let me know if you can make it as the place is popular so we need to book a table. So far, Seven of us have committed. If you can not make it this time around, but want to be informed of similar nights out, drop me a line. Details: 7PM @ the Lowlander, 36 Drury Lane, London WC2 (In front of the New London Theater, closest tube Convent Garden) Map: http://www.streetmap.co.uk/streetmap.dll?postcode2map?wc2b+5rr&Lowlander+Beer+Caf%E9 Review: http://www.telegraph.co.uk/wine/main.jhtml?xml=/wine/2002/08/14/edbar14.xml Regards to all, Francesco -- http://www.erlang-consulting.com From cpressey@REDACTED Wed May 21 03:19:02 2003 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 20 May 2003 20:19:02 -0500 Subject: Very strange behaviour! In-Reply-To: References: Message-ID: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> On Tue, 20 May 2003 08:24:55 +0200 "Vlad Dumitrescu" wrote: > Oh, and it seems like it's the same at work... very strange! > > It is also on Windows (XP and 2000), where it worked before. I think > it's about a week since I tried last time. And now, it just hangs and > does nothing... > > Any ideas about what the problem might be? Well - um - not really, but maybe. More info might help (R9B-1? -name, -sname, or no distribution?) I've encountered a similar thing occasionally on Windows 95 when trying to start werl after closing it (usually after having started and closed it several times.) The problem in my case seemed to be that epmd didn't always stop when werl stopped, and when werl was started again, it was waiting for its new instance of epmd (which wasn't starting because the old instance of epmd was still running.) At least, this is as far as I can gather. My solution was to Ctrl+Alt+Del and kill epmd before starting werl again. So basically I suspect werl is waiting for something - might be epmd, or if you're using -name distribution, it might be a DNS problem, or something. Sorry, that's the best I can come up with :) > regards, > Vlad HTH (in some small way) -Chris From vlad_dumitrescu@REDACTED Wed May 21 06:31:33 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 21 May 2003 06:31:33 +0200 Subject: Very strange behaviour! References: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> Message-ID: Hi, > Well - um - not really, but maybe. I appreciate any kind of help! > More info might help (R9B-1? -name, -sname, or no distribution?) R9B1, and distribution doesn't matter. In any case, Epmd goes up properly. The erl.exe or werl.exe process doesn't just wait, but it keeps a CPU usage of over 90%, while the memory usage grows slowly from ~10M to ~14M (sometimes more). I just don't know what might be going on... The strange thing is that it worked fine directly after installation, both at home and at work. Maybe it's the revenge for not using it as much as before, and for trying out C#? :-) regards, Vlad From erlang@REDACTED Wed May 21 08:30:18 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Wed, 21 May 2003 07:30:18 +0100 Subject: Erl Lounge London 28/5 References: <3ECA936A.1050706@erlang-consulting.com> Message-ID: <3ECB1CFA.2070009@manderp.freeserve.co.uk> Francesco, you make it sound as if we all sob into our expensive beers! It's also when and where Erlvangelists among the C++ heathen like myself find encouragement and a morale boost when I hear the success stories and tales of Erlang's technical supremacy. No, actually it's a gas, and the more the merrier! (-: Pete. Francesco Cesarini wrote: > Sorry for using the list, but I wanted to make any new London/UK Erlang > mailing list members aware that since our first "Erl Lounge" about a > year ago, a group of us irregularly meet in various watering holes > around the capital, discussing message passing, problems with garbage > collecting, concurrency, hardships of finding reliable workers, and > complaining that they are in constant need of supervision. (The visiting > Swedes usually complain over the price of beer in Sweden until they > realize the pub closes at 11 and that the beer is actually more > expensive here). > > We are meeting again next Wednesday the 28th, 7PM at the Lowlander in > central London. Let me know if you can make it as the place is popular > so we need to book a table. So far, Seven of us have committed. If you > can not make it this time around, but want to be informed of similar > nights out, drop me a line. > > Details: 7PM @ the Lowlander, 36 Drury Lane, London WC2 (In front of the > New London Theater, closest tube Convent Garden) > Map: > http://www.streetmap.co.uk/streetmap.dll?postcode2map?wc2b+5rr&Lowlander+Beer+Caf%E9 > > Review: > http://www.telegraph.co.uk/wine/main.jhtml?xml=/wine/2002/08/14/edbar14.xml > > Regards to all, > Francesco From cpressey@REDACTED Wed May 21 08:59:30 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 21 May 2003 01:59:30 -0500 Subject: Very strange behaviour! In-Reply-To: References: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> Message-ID: <20030521015930.5bd8f7da.cpressey@catseye.mb.ca> On Wed, 21 May 2003 06:31:33 +0200 "Vlad Dumitrescu" wrote: > Hi, > > > Well - um - not really, but maybe. > > I appreciate any kind of help! > > > More info might help (R9B-1? -name, -sname, or no distribution?) > > R9B1, and distribution doesn't matter. In any case, Epmd goes up > properly. > > The erl.exe or werl.exe process doesn't just wait, but it keeps a CPU > usage of over 90%, while the memory usage grows slowly from ~10M to > ~14M(sometimes more). I just don't know what might be going on... > > The strange thing is that it worked fine directly after installation, > both at home and at work. Maybe it's the revenge for not using it as > much as before, and for trying out C#? :-) OK, this is a *guess* - based on nothing more than an odd feeling - When you [re]installed Erlang/OTP, did you choose to install Winsock 2? If not - try it. I was thinking about something else entirely when I suddenly got a terrible feeling that installing C# might also install an 'innovative' TCP/IP stack that Erlang doesn't like. I know how cynical that sounds - in fact I dearly hope it's NOT the case - BUT ... well, I'm paranoid :) > regards, > Vlad -Chris From eleberg@REDACTED Wed May 21 10:04:08 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 21 May 2003 10:04:08 +0200 (MEST) Subject: not a question, just a fun thing with syntax_tools Message-ID: <200305210804.h4L848q18048@cbe.ericsson.se> greetings, i have a erlang pretty printer built upon syntax-tools (by Richard Carlsson, thank you very much). i just noticed that it will re-write my ugly code for me. New = [1|[2|Old]], will pretty print as New = [1, 2 | Old], does this mean i have finally found an argument to support not using emacs? :-) and will syntax_tools be able to refactor my functions soon? bengt From etxuwig@REDACTED Wed May 21 10:32:24 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 May 2003 10:32:24 +0200 (MEST) Subject: not a question, just a fun thing with syntax_tools In-Reply-To: <200305210804.h4L848q18048@cbe.ericsson.se> Message-ID: On Wed, 21 May 2003, Bengt Kleberg wrote: >does this mean i have finally found an argument to support >not using emacs? :-) While working at AXD 301, you are allowed to use any editor (I know both vi and textedit have been used), as long as you comply with the indentation rules in the Emacs Erlang mode. ;-) There is even a design rule to this effect: "Indentation shall be according to the Erlang mode for emacs" (actually, this is part of a recommendation - not a rule - outlining preferred coding style. It says other wise things too, like "Comment on principles and ideas rather than details. Never forget that bad programming practice cannot be explained away. It must be rewritten." We stole that last part from Joe.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From eleberg@REDACTED Wed May 21 10:41:50 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 21 May 2003 10:41:50 +0200 (MEST) Subject: not a question, just a fun thing with syntax_tools Message-ID: <200305210841.h4L8foq21302@cbe.ericsson.se> > X-Authentication-Warning: cbe1066.al.sw.ericsson.se: etxuwig owned process doing -bs > Date: Wed, 21 May 2003 10:32:24 +0200 (MEST) > From: Ulf Wiger ...deleted > While working at AXD 301, you are allowed to use any editor > (I know both vi and textedit have been used), as long as you > comply with the indentation rules in the Emacs Erlang mode. > ;-) i use wily (acme). the reason i built the pretty printer was to ''comply with the indentation rules in the Emacs Erlang mode''. my own indention is different. does this mode re-write ugly code, too? what i would like is a un-pretty printer. that took emacs mode erlang and produced my indention... bengt From vlad_dumitrescu@REDACTED Wed May 21 11:13:14 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 21 May 2003 11:13:14 +0200 Subject: Very strange behaviour! References: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> <20030521015930.5bd8f7da.cpressey@catseye.mb.ca> Message-ID: > When you [re]installed Erlang/OTP, did you choose to install Winsock 2? No, but I don't get the question whether to install it or not either, I suppose the installation program senses it's not on Win95 and Winsock2 is already present. I could not find yet any Winsock2 installation for Win2000, and I'm not sure the one for Win95 will work, but I will look further. thanks! regards, Vlad From nhead@REDACTED Wed May 21 19:47:49 2003 From: nhead@REDACTED (Nigel Head) Date: Wed, 21 May 2003 19:47:49 +0200 Subject: Sanity check: Build with gcc3 known to fail? Message-ID: <20030521194749.7839e24f.nhead@houbits.com> Having just tried to build r9b1 on a SuSe8.2 system (which has gcc3) and got reams and reams of compare signed/unsigned warnings -- which look benign -- and some token pasteing errors -- which look less benign -- and a failed install I thought I'd check if this is known to be a problem by any of you old hands. I don't easily have an older gcc available to go the 'trial and error' route and I'm new enough to erlang to have only used the windows binary distribution for toy things so far, so I have no basis for comparison. TIA; Nigel. From vances@REDACTED Wed May 21 20:01:51 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 21 May 2003 14:01:51 -0400 Subject: not a question, just a fun thing with syntax_tools In-Reply-To: References: <200305210804.h4L848q18048@cbe.ericsson.se> Message-ID: <20030521180151.GD63273@frogman.motivity.ca> The vi/emacs religious wars aside .. Im my humble opinion exposing the emacs specific (and broken) way of indenting is just plain wrong. The source shouldn't be tied to the editor. That's just obvious. Indentation should be done with tabs, that should be obvious. A consistent number of spaces is not bad either. The emacs way is just ugly and makes it hard for the rest of us. -Vance From cpressey@REDACTED Wed May 21 22:23:13 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 21 May 2003 15:23:13 -0500 Subject: Very strange behaviour! In-Reply-To: References: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> <20030521015930.5bd8f7da.cpressey@catseye.mb.ca> Message-ID: <20030521152313.4e06d92d.cpressey@catseye.mb.ca> On Wed, 21 May 2003 11:13:14 +0200 "Vlad Dumitrescu" wrote: > > When you [re]installed Erlang/OTP, did you choose to install Winsock > > 2? > > No, but I don't get the question whether to install it or not either, > I suppose the installation program senses it's not on Win95 and > Winsock2 is already present. Hm, you're right - I've only installed Erlang on one Windows XP box, and I don't remember it asking about winsock. > I could not find yet any Winsock2 installation for Win2000, and I'm > not sure the one for Win95 will work, but I will look further. Well, I wouldn't even be suggesting it if you didn't mention that this was a fresh(ish) install of Windows. I thought about it some more and I really can't think of why Erlang would have any reason to do anything with the TCP/IP stack on startup unless it's running a distribution, or maybe just some initialization code. So, I'm beginning to think it's less likely that it's the problem. Although that doesn't rule out C#/.NET - if you have plenty of time, you could try installing XP from scratch, then installing Erlang first thing and trying it, then installing C#/.NET or whatever else, then trying Erlang again. Or... grasping at straws here... maybe you could try: - different boot scripts - recompiling init.beam with a call to fprof at the start (assuming that fprof can be started independent of the rest of the system, which I don't know for sure) - or just littering the startup code with erlang:display("here!") statements... crude but at least an indication of roughly where the slowdown is occurring > thanks! regards, > Vlad No problem :) -Chris From ulf.wiger@REDACTED Wed May 21 23:01:17 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Wed, 21 May 2003 23:01:17 +0200 Subject: not a question, just a fun thing with syntax_tools References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> Message-ID: <001901c31fdc$20088000$fd7a40d5@telia.com> The recommendation at AXD 301 had very little to do with what was considered the prettiest way to indent code. There was one editor available that provided an indentation mode for Erlang, so we chose that in the name of consistency. Even then (and still), some programmers did not like emacs. That's fine, but we want our code to be written in a consistent way. This simplifies maintenance and debugging, and in large projects, the most common scenario is that the person maintaining a program is not the same person who wrote it. Personally, I think emacs is a great editor with really quirky keyboard shortcuts, but you can get used to anything. ;-) /U ----- Original Message ----- From: "Vance Shipley" To: Sent: den 21 maj 2003 20:01 Subject: Re: not a question, just a fun thing with syntax_tools > The vi/emacs religious wars aside .. > > Im my humble opinion exposing the emacs specific (and broken) way > of indenting is just plain wrong. The source shouldn't be tied to > the editor. That's just obvious. Indentation should be done with > tabs, that should be obvious. A consistent number of spaces is > not bad either. The emacs way is just ugly and makes it hard for > the rest of us. > > -Vance From mikpe@REDACTED Wed May 21 23:09:21 2003 From: mikpe@REDACTED (mikpe@REDACTED) Date: Wed, 21 May 2003 23:09:21 +0200 Subject: Sanity check: Build with gcc3 known to fail? In-Reply-To: <20030521194749.7839e24f.nhead@houbits.com> References: <20030521194749.7839e24f.nhead@houbits.com> Message-ID: <16075.60161.192453.525034@gargle.gargle.HOWL> Nigel Head writes: > Having just tried to build r9b1 on a SuSe8.2 system (which has gcc3) and got reams and reams of compare signed/unsigned warnings -- which look benign -- and some token pasteing errors -- which look less benign -- and a failed install I thought I'd check if this is known to be a problem by any of you old hands. I don't easily have an older gcc available to go the 'trial and error' route and I'm new enough to erlang to have only used the windows binary distribution for toy things so far, so I have no basis for comparison. The patch below should fix the token pasting problem. It works for me. I got an unexpected failure in one of our test suites today with gcc-3.3 on SPARC Solaris 9. I'll retest tomorrow on x86. gcc-3.2.3 seems Ok though. /Mikael Index: otp/erts/etc/unix/run_erl.c =================================================================== RCS file: /it/project/fo/hipe/repository/otp/erts/etc/unix/run_erl.c,v retrieving revision 1.5 diff -u -r1.5 run_erl.c --- otp/erts/etc/unix/run_erl.c 16 May 2003 12:15:06 -0000 1.5 +++ otp/erts/etc/unix/run_erl.c 21 May 2003 16:12:28 -0000 @@ -130,7 +130,7 @@ #ifdef NO_SYSLOG #define OPEN_SYSLOG() ((void) 0) -#define ERROR(Parameters) stderr_error##Parameters +#define ERROR(Parameters) stderr_error Parameters #else #define OPEN_SYSLOG()\ openlog(simple_basename(program_name),LOG_PID|LOG_CONS|LOG_NOWAIT,LOG_USER) @@ -138,9 +138,9 @@ #define ERROR(Parameters) \ do { \ if (run_daemon) { \ - syslog##Parameters; \ + syslog Parameters; \ } else { \ - stderr_error##Parameters; \ + stderr_error Parameters; \ } \ } while (0) #endif From vances@REDACTED Wed May 21 23:23:08 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 21 May 2003 17:23:08 -0400 Subject: not a question, just a fun thing with syntax_tools In-Reply-To: <001901c31fdc$20088000$fd7a40d5@telia.com> References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> Message-ID: <20030521212308.GH63273@frogman.motivity.ca> Given that Emacs is supposed to be the end all be all of everything can it not be coaxed to put out normal tab based indentation? -Vance On Wed, May 21, 2003 at 11:01:17PM +0200, Wiger Ulf wrote: } The recommendation at AXD 301 had very little to do with what } was considered the prettiest way to indent code. There was one } editor available that provided an indentation mode for Erlang, } so we chose that in the name of consistency. From cpressey@REDACTED Wed May 21 23:34:52 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 21 May 2003 16:34:52 -0500 Subject: not a question, just a fun thing with syntax_tools In-Reply-To: <20030521180151.GD63273@frogman.motivity.ca> References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> Message-ID: <20030521163452.26d3d4e6.cpressey@catseye.mb.ca> On Wed, 21 May 2003 14:01:51 -0400 Vance Shipley wrote: > The vi/emacs religious wars aside .. > > Im my humble opinion exposing the emacs specific (and broken) way > of indenting is just plain wrong. The source shouldn't be tied to > the editor. That's just obvious. In more ways than one - programs aren't linear! But if you try to improve on it, say by introducing a 2D notation, you risk tying the source to an obscure, custom editor - ends up much worse than simply declaring an arbitrary text editor, like say, emacs, as official. So, I'll bet we'll still be using text files to represent program source code in 2081. What the world could use is a brilliantly clever editor that can display the source in any number of arrangements as determined by the essential structure of the program. I think Gabriel touched on this in 'Patterns in Software' - if you say a(X) -> b(c(X)). and the optimizer and the editor both 'know' this, then you should be able to see and/or type a(X) and b(c(X)) interchangeably while working on your program. For example, have some key binding that switches between the 'collapsed' and 'expanded' forms, kind of like the +/- buttons in the 'tree view' in most modern GUIs. I would love this. It could also help the situation Joe rants about in his Why OO Sucks article - it doesn't matter where data declarations really "are", so long as the programmer can choose to see them all in one place, or individually, as they choose, and so long as the compiler knows where to find them... > Indentation should be done with tabs, that should be obvious. Tabs are the work of the devil. Repent, sinner. :) -Chris From vances@REDACTED Wed May 21 23:40:18 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 21 May 2003 17:40:18 -0400 Subject: not a question, just a fun thing with syntax_tools In-Reply-To: <20030521212308.GH63273@frogman.motivity.ca> References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> Message-ID: <20030521214018.GA64016@frogman.motivity.ca> Just for the record vim (the modern vi) now comes with an Erlang mode. -Vance From thomas@REDACTED Thu May 22 02:54:55 2003 From: thomas@REDACTED (Thomas Fee) Date: Wed, 21 May 2003 19:54:55 -0500 Subject: not a question, just a fun thing with syntax_tools In-Reply-To: <20030521214018.GA64016@frogman.motivity.ca> References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> <20030521214018.GA64016@frogman.motivity.ca> Message-ID: <3ECC1FDF.3060808@versatechs.com> I would not say that it has an "Erlang mode". There is a syntax file for Erlang which colorizes the text according to the types of lexical entities. It doesn't really understand syntactic entities. Not being fully satisfied with the stock syntax file, I have tried experiments in improving it. I think you can get nice results... I think code formatting requires a perceptive mind with a bit of talent for aesthetics. No mode is going to provide that. On a related topic: With a small Vim macro, you can fold Erlang functions into an outline which you can then expand and collapse at will. Vim does a very nice job of managing folds. ~Thomas Vance Shipley wrote: >Just for the record vim (the modern vi) now comes with an Erlang mode. > > -Vance > > > > From hal@REDACTED Thu May 22 06:55:02 2003 From: hal@REDACTED (Hal Snyder) Date: Wed, 21 May 2003 23:55:02 -0500 Subject: The Erlang way - dynamic upgrade of a server and UBF extensions In-Reply-To: (Joe Armstrong's message of "Wed, 30 Apr 2003 10:32:13 +0200 (CEST)") References: Message-ID: <873cj7y40p.fsf@ghidra.vail> Joe Armstrong writes: >> The IP failover seems to handle a reasonable case of >> essentially connectionless single packet transmission, >> or the equivalent of frequency hopping. More complex >> failover can be part of a data packet listing multiple IPs >> or a hierarchy or mapping to particular versions of the >> protocol, as agreed in UBF(B) or UBF(C) contracts. > > Interesting - perhaps the whole of client-server RPC is wrong. > > Should it be cluster-cluster RPC. > > The client could enclose a list of IPs and the server could reply to any > client in the list. > > On *every* reply the server would reply with a list of servers to be > used on the next call - one the next call the client could choose > *any* server. > > (This will not be wildly efficient - because of globally replicate the > state in the clusters at either end - *but* it will be easy to > program fault-tolerent applications) As others have commented, putting IP addresses in this message layer feels very wrong, a la FTP and such. That it is NAT-unfriendly is simply a warning. A few more random thoughts about IP failover: Re sending a bunch of addresses to which a peer could reply, there may be a precedent of sorts - isn't that what happens in SCTP multihoming? Except for the detail that with SCTP all the addresses are on the same client. :) Probably fault tolerant connection logic should not encumber UBF machinery. Instead, use a very reliable (e.g. localhost socket) link to another system that does the connection redundancy - think of it as passing the message to another layer of the protocol stack. There is an analogy with interior vs. exterior gateway protocols in dynamic routing. And cluster-cluster communication is what happens between autonomous systems with exterior routing. Of course somewhere there is host-host communication but that is isolated at a lower layer. A network is made up of globs of consumers and producers of various resources. The characterization of a host includes a list of services for which it is producer or consumer (to which clusters does this host belong), with group and instance identifiers for each service. A message should be sent from a UBF client or server to a logical address, shouldn't it? I suspect UBF clients and servers should no more care about IP addresses than they should care about MAC addresses. From eleberg@REDACTED Thu May 22 07:25:57 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 22 May 2003 07:25:57 +0200 (MEST) Subject: not a question, just a fun thing with syntax_tools Message-ID: <200305220525.h4M5Pvq17281@cbe.ericsson.se> > The vi/emacs religious wars aside .. since i use neither i think this is an axiom :-) > Im my humble opinion exposing the emacs specific (and broken) way > of indenting is just plain wrong. The source shouldn't be tied to > the editor. (this could, on the oter hand be the start of an indention religious war :-) having a ''common'' source code layout helps a lot when maintaining large amounts of code. likewise with the same function/variable name layout. (even if i do not understand the reason for WritingVariablesWithoutSpaces, since Variables_with_spaces_are_easier_to_read). the problem is that there is no ''indent'' program for erlang. using indent with a common .indent file before checking in source is a good thing (tm). those who prefer another formating convention can use indent after checking out. atleast this worked very well for me in my (long past now :-) days of c coding. bengt From eleberg@REDACTED Thu May 22 07:28:28 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 22 May 2003 07:28:28 +0200 (MEST) Subject: not a question, just a fun thing with syntax_tools Message-ID: <200305220528.h4M5SSq17443@cbe.ericsson.se> > X-Original-Recipient: erlang-questions@REDACTED > From: "Wiger Ulf" ...deleted > Personally, I think emacs is a great editor with really quirky > keyboard shortcuts, but you can get used to anything. ;-) must be right. i suggest the mouse chords of wily as an example. (had emacs been x aware in 1990 i most likely would not have been using wily) bengt From erlang@REDACTED Thu May 22 08:11:42 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 22 May 2003 07:11:42 +0100 Subject: not a question, just a fun thing with syntax_tools References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> <20030521214018.GA64016@frogman.motivity.ca> <3ECC1FDF.3060808@versatechs.com> Message-ID: <3ECC6A1E.2030802@manderp.freeserve.co.uk> Since we're on the subject, has anyone come across SciTE from http://scintilla.org/SciTE.html ? It doesn't have an Erlang lexer out-of-the-box, but I've been working on two versions. Both have syntax highlighting, one has folding based on indentation depth, the other folds on (limited) syntax parsing. They're both a bit green, but I use SciTE almost exclusively and it suits me. The source will compile for M$-Windows as well as *NIX, and the editor has a pleasant GUI and tool integration. I'm planning to feed back my work into the SciTE project so that Erlang becomes one of the many languages it supports. But before I do, is anyone interested in giving it a spin and offering some criticism? Pete. Thomas Fee wrote: > I would not say that it has an "Erlang mode". There is a syntax file for > Erlang which colorizes the text according to the types of lexical > entities. It doesn't really understand syntactic entities. Not being > fully satisfied with the stock syntax file, I have tried experiments in > improving it. I think you can get nice results... > > I think code formatting requires a perceptive mind with a bit of talent > for aesthetics. No mode is going to provide that. > > On a related topic: With a small Vim macro, you can fold Erlang > functions into an outline which you can then expand and collapse at > will. Vim does a very nice job of managing folds. > > ~Thomas > > > Vance Shipley wrote: > >> Just for the record vim (the modern vi) now comes with an Erlang mode. >> >> -Vance >> >> >> >> > > > > From richardc@REDACTED Thu May 22 10:05:15 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 22 May 2003 10:05:15 +0200 Subject: not a question, just a fun thing with syntax_tools References: <200305210804.h4L848q18048@cbe.ericsson.se> Message-ID: <007701c32038$e37e0490$8adcd1d9@gnit> ----- Original Message ----- From: "Bengt Kleberg" Sent: Wednesday, May 21, 2003 10:04 AM > does this mean i have finally found an argument to support not using > emacs? :-) > > and will syntax_tools be able to refactor my functions soon? It is already -- if you switch to Emacs and use Luke Gorrie's Distel. :-) /Richard From vlad_dumitrescu@REDACTED Thu May 22 10:14:02 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 22 May 2003 10:14:02 +0200 Subject: Very strange behaviour! References: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> <20030521015930.5bd8f7da.cpressey@catseye.mb.ca> <20030521152313.4e06d92d.cpressey@catseye.mb.ca> Message-ID: Solved!!! > - or just littering the startup code with erlang:display("here!") > statements... crude but at least an indication of roughly where the > slowdown is occurring Thanks a lot for the idea! I was so frustrated that I couldn't think straight! :-) I had installed Spybot, a utility that can track and remove spyware and other unwanted stuff. It can also set some known host names to 127.0.0.1 in etc/hosts, so that those plcase can't be reached anymore. The problem was that etc/hosts became HUGE and it took all that time to put the hosts into the database.... At least I learned something about the startup procedure. Now I can go back and try to sell the Erlang concept to the management :-) regards, Vlad From eleberg@REDACTED Thu May 22 10:15:20 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 22 May 2003 10:15:20 +0200 (MEST) Subject: not a question, just a fun thing with syntax_tools Message-ID: <200305220815.h4M8FKq04586@cbe.ericsson.se> > X-Original-Recipient: eleberg@REDACTED > From: "Richard Carlsson" > > and will syntax_tools be able to refactor my functions soon? > > It is already -- if you switch to Emacs and use Luke Gorrie's Distel. :-) that particular refactoring (in my understanding: i choose the source code lines and get a function head added to those lines) i have already done for wily. i meant for syntax_tools to make the choice of lines in my function, just as syntax-tools re-write my ugly code :-) bengt From serge@REDACTED Thu May 22 03:18:49 2003 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 21 May 2003 21:18:49 -0400 Subject: WinXP and werl Message-ID: <3ECC2579.4030504@hq.idt.net> I am having problem starting "werl -sname nodeX" (9B1 release) on WinXP. While there's no problem starting "werl" in non-distributed mode, any attempt to specify -sname option causes immediate abort with the following crash dump. Any idea what's wrong? Slogan: Kernel pid terminated (application_controller) (shutdown) Erlang (BEAM) emulator version 5.2.3.3 Compiled on Wed Mar 5 10:19:31 2003 Process Information -------------------------------------------------- <0.0.0> Running. Registered as: init Spawned as: otp_ring0:start/2 Message queue (1 message): [{'EXIT',<0.1.0>,{noproc,{gen_server,call,[applicatio n_controller,{load_application,stdlib},infinity]}}}] Message buffer data: 0 words Link list: [<0.4.0>,<0.2.0>] Reductions 4020 stack+heap 6765 old_heap_sz=0 Heap unused=1025 OldHeap unused=0 Stack dump: program counter = 0xd0a7fc (init:sleep/1 + 32) cp = 0xd080f8 (init:things_to_string/1 + 68) 00D17E78 Return addr 0xD087DC (init:boot_loop/2 + 1412) 00D17E7C Return addr 0x100C4B5C () y(0) [] y(1) {state,[{'-root',[<<22 bytes>>]},{'-progname',[<<3 bytes>>]},{'-home',[ <<40 bytes>>]},{'-sname',[<<4 bytes>>]}],[],[],[{application_controller,<0.5.0>} ,{error_logger,<0.4.0>},{erl_prim_loader,<0.2.0>}],<0.1.0>,{starting,application s_loaded},{"OTP APN 181 01","R9B"},[{ets,"C:\PROGRA~1\ERL523~1.3/lib/stdlib-1.1 1.4.1/ebin/ets.beam"},{inet_tcp,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/ inet_tcp.beam"},{file,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/file.beam" },{auth,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/auth.beam"},{erl_epmd,"C :\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/erl_epmd.beam"},{inet_tcp_dist,"C: \PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/inet_tcp_dist.beam"},{net_kernel,"C :\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/net_kernel.beam"},{erl_distributio n,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/erl_distribution.beam"},{inet_ hosts,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/inet_hosts.beam"},{filenam e,"C:\PROGRA~1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/filename.beam"},{erl_open_por t,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/erl_open_port.beam"},{win32reg ,"C:\PROGRA~1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/win32reg.beam"},{inet_parse,"C :\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/inet_parse.beam"},{inet,"C:\PROGRA ~~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/inet.beam"},{inet_udp,"C:\PROGRA~1\ERL523~ 1.3/lib/kernel-2.8.1.1/ebin/inet_udp.beam"},{os,"C:\PROGRA~1\ERL523~1.3/lib/kern el-2.8.1.1/ebin/os.beam"},{inet_config,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1. 1/ebin/inet_config.beam"},{inet_db,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/eb in/inet_db.beam"},{global,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/global .beam"},{rpc,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/rpc.beam"},{supervi sor,"C:\PROGRA~1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/supervisor.beam"},{kernel," C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/kernel.beam"},{application_master ,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/application_master.beam"},{appl ication,"C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/application.beam"},{list s,"C:\PROGRA~1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/lists.beam"},{sys,"C:\PROGRA~ 1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/sys.beam"},{gen_server,"C:\PROGRA~1\ERL523 ~~1.3/lib/stdlib-1.11.4.1/ebin/gen_server.beam"},{application_controller,"C:\PROG RA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin/application_controller.beam"},{proc_lib, "C:\PROGRA~1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/proc_lib.beam"},{gen,"C:\PROGRA ~~1\ERL523~1.3/lib/stdlib-1.11.4.1/ebin/gen.beam"},{gen_event,"C:\PROGRA~1\ERL523 ~~1.3/lib/stdlib-1.11.4.1/ebin/gen_event.beam"},{error_logger,"C:\PROGRA~1\ERL523 ~~1.3/lib/kernel-2.8.1.1/ebin/error_logger.beam"},{heart,"C:\PROGRA~1\ERL523~1.3/ lib/kernel-2.8.1.1/ebin/heart.beam"},{error_handler,"C:\PROGRA~1\ERL523~1.3/lib/ kernel-2.8.1.1/ebin/error_handler.beam"},{erlang,"C:\PROGRA~1\ERL523~1.3/lib/ker nel-2.8.1.1/ebin/erlang.beam"}]} y(2) <0.1.0> -------------------------------------------------- <0.2.0> Waiting. Registered as: erl_prim_loader Spawned as: erlang:apply/2 Message buffer data: 0 words Link list: [<0.0.0>,#Port<0.2>] Reductions 8343 stack+heap 610 old_heap_sz=377 Heap unused=439 OldHeap unused=377 Stack dump: program counter = 0xce6928 (erl_prim_loader:loop/3 + 52) cp = 0x100c4b5c () arity = 0 00DD6EFC Return addr 0x100C4B5C () y(0) ["C:\PROGRA~1\ERL523~1.3/lib/kernel-2.8.1.1/ebin","C:\PROGRA~1\ERL523~1 .3/lib/stdlib-1.11.4.1/ebin"] y(1) <0.1.0> y(2) {state,[],none,#Fun,undefined,#Fun,#Fun,#Port<0.2>,infinity,#Fun} y(3) infinity -------------------------------------------------- <0.4.0> Waiting. Registered as: error_logger Spawned as: proc_lib:init_p/5 Message buffer data: 0 words Link list: [<0.0.0>] Dictionary: [{'$initial_call',{gen,init_it,[gen_event,<0.1.0>,<0.1.0>,{local,err or_logger},[],[],[]]}},{'$ancestors',[<0.1.0>]}] Reductions 1388 stack+heap 987 old_heap_sz=987 Heap unused=65 OldHeap unused=987 Stack dump: program counter = 0xd5e558 (gen_event:loop/4 + 40) From jeinhorn@REDACTED Thu May 22 16:26:01 2003 From: jeinhorn@REDACTED (Jeff Einhorn) Date: 22 May 2003 09:26:01 -0500 Subject: Monitering process. Message-ID: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> Is there a handy tool other than just i(). to moniter serveral erlang processes for how much cpu they are using. Something like top for individual erlang processes? I ask because using the reductions number is difficult to use to get an idea of how busy a process is at a certain point in time. (Or is there a way to grab the counts from somewhere so we can periodically compute a delta?). -jeff -- Jeffrey M. Einhorn Software Engineer Web/Platform Development Group FutureSource, LLC jeinhorn@REDACTED http://www.futuresource.com From siri@REDACTED Thu May 22 16:31:12 2003 From: siri@REDACTED (Siri Hansen (EAB)) Date: Thu, 22 May 2003 16:31:12 +0200 Subject: Monitering process. In-Reply-To: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> References: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> Message-ID: <16076.57136.290755.225597@gargle.gargle.HOWL> You could try etop in the observer application. /siri Jeff Einhorn wrote: > Is there a handy tool other than just i(). to moniter serveral erlang > processes for how much cpu they are using. Something like top for > individual erlang processes? I ask because using the reductions number > is difficult to use to get an idea of how busy a process is at a certain > point in time. (Or is there a way to grab the counts from somewhere so > we can periodically compute a delta?). > > -jeff > -- > Jeffrey M. Einhorn > Software Engineer > Web/Platform Development Group > FutureSource, LLC > jeinhorn@REDACTED > http://www.futuresource.com > From david.wallin@REDACTED Thu May 22 18:25:26 2003 From: david.wallin@REDACTED (david wallin) Date: Thu, 22 May 2003 17:25:26 +0100 Subject: Package support in Erlang: Status ? In-Reply-To: Message-ID: On Tuesday, April 22, 2003, at 12:45 PM, Richard Carlsson wrote: > > On Sun, 20 Apr 2003, Wiger Ulf wrote: > >> I have also privately suggested that Erlang allow "dotted atoms" (that >> is, without single quotes) in other places as well, e.g. in registered >> names, ets tables, etc. This would make package support feel a little >> less like an afterthought, and more like an integrated part of the >> language. > > You mean like this?: > > 1> register(self(), fee.fie.foo). > ok > 2> whereis(fee.fie.foo). > <0.31.0> > > It's already there, if you try it. If you find some example of where it > does not work, please report it to me. > Richard, How about this, do a file:consult/1 on a file containing : {abba_a,a}. {abba.b,b}. This results in an error : '{error,{1,erl_parse,"bad term"}}' cheers, --david. From martin@REDACTED Thu May 22 19:09:20 2003 From: martin@REDACTED (martin j logan) Date: 22 May 2003 12:09:20 -0500 Subject: Monitering process. In-Reply-To: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> References: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> Message-ID: <1053623360.4267.2846.camel@berimbau.vail> Jeff, The eprof tool is nice for time profiling. Look under tools eprof for docs. Eprof tends to slow things down a bit so you will have to consider that when you look at your results. Description: The module eprof provides a set of functions for time profiling of Erlang programs to find out how the execution time is used. The profiling is done using the Erlang trace BIFs. Tracing of local function calls for a specified set of processes is enabled when profiling is begun, and disabled when profiling is stopped. Cheers, Martin On Thu, 2003-05-22 at 09:26, Jeff Einhorn wrote: > Is there a handy tool other than just i(). to moniter serveral erlang > processes for how much cpu they are using. Something like top for > individual erlang processes? I ask because using the reductions number > is difficult to use to get an idea of how busy a process is at a certain > point in time. (Or is there a way to grab the counts from somewhere so > we can periodically compute a delta?). > > -jeff -- martin j logan From richardc@REDACTED Thu May 22 19:45:50 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 22 May 2003 19:45:50 +0200 Subject: Package support in Erlang: Status ? References: Message-ID: <002601c32089$ff3b7180$8adcd1d9@gnit> Thanks. I'll look into it. /Richard ----- Original Message ----- From: "david wallin" To: "Richard Carlsson" Cc: ; "Wiger Ulf" Sent: Thursday, May 22, 2003 6:25 PM Subject: Re: Package support in Erlang: Status ? > How about this, do a file:consult/1 on a file containing : > > {abba_a,a}. > {abba.b,b}. > > This results in an error : '{error,{1,erl_parse,"bad term"}}' > > > cheers, > > --david. > > > From enewhuis@REDACTED Thu May 22 20:06:14 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 22 May 2003 13:06:14 -0500 Subject: Why is ets:delete_trap at top of Eprof Analysis? In-Reply-To: <1053623360.4267.2846.camel@berimbau.vail> References: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> <1053623360.4267.2846.camel@berimbau.vail> Message-ID: <3ECD1196.6030700@futuresource.com> Anyone know why ets:delete_trap/1 shows up at the top of our eprof output? Is this a red herring? ets:delete_trap/1 0 67 % orddict:merge/3 255891 17 % ets:select_delete/2 572 5 % cache:transact/5 7827 3 % ets:match_object/2 7829 2 % ets:insert/2 8348 2 % ets:match/2 7776 1 % From cpressey@REDACTED Fri May 23 03:49:50 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 22 May 2003 20:49:50 -0500 Subject: Very strange behaviour! In-Reply-To: References: <20030520201902.0a209d3d.cpressey@catseye.mb.ca> <20030521015930.5bd8f7da.cpressey@catseye.mb.ca> <20030521152313.4e06d92d.cpressey@catseye.mb.ca> Message-ID: <20030522204950.1b6d9464.cpressey@catseye.mb.ca> On Thu, 22 May 2003 10:14:02 +0200 "Vlad Dumitrescu" wrote: > Solved!!! > > > - or just littering the startup code with erlang:display("here!") > > statements... crude but at least an indication of roughly where > > the slowdown is occurring > > Thanks a lot for the idea! I was so frustrated that I couldn't think > straight! :-) Glad I could help :) Especially since I generally have no idea what I'm doing... :) Mini-poll question to the list in general: What would you think of a -verbose_startup option for helping debug these sorts of problems? -Chris From cpressey@REDACTED Fri May 23 04:02:33 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 22 May 2003 21:02:33 -0500 Subject: SciTE (was: Re: not a question, just a fun thing with syntax_tools) In-Reply-To: <3ECC6A1E.2030802@manderp.freeserve.co.uk> References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> <20030521214018.GA64016@frogman.motivity.ca> <3ECC1FDF.3060808@versatechs.com> <3ECC6A1E.2030802@manderp.freeserve.co.uk> Message-ID: <20030522210233.54f4ec3c.cpressey@catseye.mb.ca> On Thu, 22 May 2003 07:11:42 +0100 Peter-Henry Mander wrote: > Since we're on the subject, has anyone come across SciTE from > http://scintilla.org/SciTE.html ? It doesn't have an Erlang lexer > out-of-the-box, but I've been working on two versions. Both have > syntax highlighting, one has folding based on indentation depth, the > other folds on (limited) syntax parsing. They're both a bit green, but > I use SciTE almost exclusively and it suits me. The source will > compile for M$-Windows as well as *NIX, and the editor has a pleasant > GUI and tool integration. > > I'm planning to feed back my work into the SciTE project so that > Erlang becomes one of the many languages it supports. But before I do, > is anyone interested in giving it a spin and offering some criticism? I found the port, built it, and tried it. Overall, I like it. I'm disappointed that it doesn't seem to have a way to simulate tabs - or if it does, it hides it unecessarily. (Tabs are definately one of my pet peeves. When I press left arrow, I want the cursor to move left one space. Not three spaces, not eight spaces - just, one space, like always. I like predictability in an editor.) I also couldn't see anything about defining or applying macros. Although complete-word is nice, as is folding, and block comments... Don't know yet if it's enough to break my unhealthy nedit addiction. But an Erlang mode might push it over the hump :) -Chris From mikael.karlsson@REDACTED Fri May 23 10:18:16 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Fri, 23 May 2003 10:18:16 +0200 Subject: XSLT like transforms in Erlang Message-ID: <200305231018.16476.mikael.karlsson@creado.com> Hi, I have updated the "user guide" and examples for XSLT like transforms in Erlang using xmerl and yaws. I think the transform module xmerl_xs will make it into xmerl, eventually. Meanwhile you can check it out from the xmerl_xs link found on http://www.creado.com/index2.html. I have also made a simple attempt to use the wiki application bundled with Yaws in combination with xmerl_xs to make a poetry page: http://213.67.104.56:8001/wiki/wiki/showPage.yaws?node=Poems Any one can contribute, so why not spend friday afternoon on a poem instead of playing Quake :-) /Mikael From D.WILLIAMS@REDACTED Fri May 23 14:07:16 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Fri, 23 May 2003 14:07:16 +0200 Subject: Shadowed head variable in fun Message-ID: Hello, How does one 'consume' a head variable in a fun? symbol(Char) when integer(Char) -> fun([Char|Rest]) -> [{Rest,Char}]; (Other) -> [] end. This compiles with a Warning: variable 'Char' shadowed in 'fun'. And doesn't do what I want... i.e. F = symbol($a), F("Hello"). returns [{"ello",72}] (I want it to return []). Thanks for your help, Dominic. From etxuwig@REDACTED Fri May 23 14:14:02 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 23 May 2003 14:14:02 +0200 (MEST) Subject: Shadowed head variable in fun In-Reply-To: Message-ID: The Char in the fun's function head is not the same as Char in the surrounding scope (thus the warning). The simplest way to amend your implementation is probably: symbol(Char) when integer(Char) -> fun([C|Rest]) when C == Char -> [{Rest,Char}]; (Other) -> [] end. I haven't verified absense of typos in the above code, but you probably get the idea. /Uffe On Fri, 23 May 2003, WILLIAMS Dominic wrote: >Hello, > >How does one 'consume' a head variable in a fun? > >symbol(Char) when integer(Char) -> > fun([Char|Rest]) -> [{Rest,Char}]; > (Other) -> [] > end. > >This compiles with a Warning: variable 'Char' shadowed in 'fun'. >And doesn't do what I want... > >i.e. > >F = symbol($a), >F("Hello"). > >returns [{"ello",72}] (I want it to return []). > >Thanks for your help, > >Dominic. > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From D.WILLIAMS@REDACTED Fri May 23 14:19:10 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Fri, 23 May 2003 14:19:10 +0200 Subject: Shadowed head variable in fun Message-ID: That's perfect, thanks very much! > -----Original Message----- > From: Ulf Wiger [mailto:etxuwig@REDACTED] > Sent: Friday, May 23, 2003 2:14 PM > To: WILLIAMS Dominic > Cc: Erlang (E-mail) > Subject: Re: Shadowed head variable in fun > > > > The Char in the fun's function head is not the same as Char > in the surrounding scope (thus the warning). The simplest > way to amend your implementation is probably: > > symbol(Char) when integer(Char) -> > fun([C|Rest]) when C == Char -> [{Rest,Char}]; > (Other) -> [] > end. > > I haven't verified absense of typos in the above code, but > you probably get the idea. > > /Uffe From tony@REDACTED Fri May 23 14:34:46 2003 From: tony@REDACTED (Tony Rogvall) Date: 23 May 2003 14:34:46 +0200 Subject: Monitering process. In-Reply-To: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> References: <1053613561.3240.25.camel@dhcp-lom-195-14.futuresource.com> Message-ID: <1053693286.1698.3.camel@bit.hemma.se> On Thu, 2003-05-22 at 16:26, Jeff Einhorn wrote: > Is there a handy tool other than just i(). to moniter serveral erlang > processes for how much cpu they are using. Something like top for > individual erlang processes? I ask because using the reductions number > is difficult to use to get an idea of how busy a process is at a certain > point in time. (Or is there a way to grab the counts from somewhere so > we can periodically compute a delta?). > > -jeff try: lists:map(fun(P) -> process_info(P, reductions) end, processes()). or replace the 'reductions' with message_queue_len to see if you get a bottle neck somewhere. or use a combination. -- Tony Rogvall From erlang@REDACTED Fri May 23 10:12:35 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Fri, 23 May 2003 10:12:35 +0200 Subject: Supervisor Message-ID: <002401c32103$145af670$1e00a8c0@design> I have three FSM machines FSM1, FSM2 and FSM3. FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked). Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses FSM2 continously. Questions: 1 - Can I use supervisor behavior in this case ? Are there any examples of supervisor usage to look for ? 2 - Is it easier to trap EXIT signals ? Many thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin@REDACTED Fri May 23 16:04:40 2003 From: martin@REDACTED (martin j logan) Date: 23 May 2003 09:04:40 -0500 Subject: Supervisor In-Reply-To: <002401c32103$145af670$1e00a8c0@design> References: <002401c32103$145af670$1e00a8c0@design> Message-ID: <1053698679.4019.35.camel@berimbau.vail> On Fri, 2003-05-23 at 03:12, Inswitch Solutions - Erlang Evaluation wrote: > > I have three FSM machines FSM1, FSM2 and FSM3. > FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked). It is best to have supervisors create all of your workers. If you can structure your processes this way go ahead and do it. It should not be a problem if fsm2 is a long lived process. > > Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses > FSM2 continously. I don't know the specifics of your problem but it sounds like it would be suited to one of two supervision strategies. 1. One supervisor with a one_for_one strategy. Start the FSMs in the following order: FSM1, FSM2, FSM3. 2. A two tier supervision structure. Tier one with a one_for_one strategy. First start a second supervisor next start FSM3. The second supervisor starts, with a one_for_all strategy, FSM1 then FSM2. The chronological order for process creation under this scheme is 1. top level supervisor, 2. second tier supervisor, 3. FSM1, 4. FSM2, 5. FSM3. > > Questions: > 1 - Can I use supervisor behavior in this case ? Yes > Are there any examples of supervisor usage to look for ? > 2 - Is it easier to trap EXIT signals ? No > > Many thanks, > Eduardo Figoli > INSwitch Solutions > > > > > -- martin j logan From Chandrashekhar.Mullaparthi@REDACTED Fri May 23 16:33:15 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 23 May 2003 15:33:15 +0100 Subject: Very strange behaviour! Message-ID: There is a -init_debug option for erl - it works with werl as well. chandru: /export/home/chandru 501>erl -init_debug {progress,preloaded} {progress,kernel_load_completed} {progress,modules_loaded} {start,heart} {start,error_logger} {start,application_controller} {progress,init_kernel_started} {apply,{application,load,[{application,stdlib,[{description,"ERTS CXC 138 10"},{vsn,"1.11.3"},{id,[]},{modules,[beam_lib,c,calendar,dets,dets_server,d ets_sup,dets_utils,dets_v8,dets_v9,dict,digraph,digraph_utils,edlin,epp,eval _bits,erl_bits,erl_compile,erl_eval,erl_id_trans,erl_internal,erl_lint,erl_p arse,erl_posix_msg,erl_pp,erl_scan,erl_tar,error_logger_file_h,error_logger_ tty_h,ets,file_sorter,filelib,filename,gb_trees,gb_sets,gen,gen_event,gen_fs m,gen_server,io,io_lib,io_lib_format,io_lib_fread,io_lib_pretty,lib,lists,li sts_sort,log_mf_h,math,ms_transform,orddict,ordsets,otp_internal,pg,pool,pro c_lib,proplists,queue,random,regexp,sets,shell,shell_default,slave,sofs,stri ng,supervisor,supervisor_bridge,sys,timer,vector,win32reg]},{registered,[tim er_server,rsh_starter,take_over_monitor,pool_master,dets]},{applications,[ke rnel]},{included_applications,[]},{env,[]},{start_phases,undefined},{maxT,in finity},{maxP,infinity}]}]}} {apply,{application,load,[{application,sasl,[{description,"SASL CXC 138 11"},{vsn,"1.9.4"},{id,[]},{modules,[sasl,alarm_handler,format_lib_supp,misc _supp,otp_mib,overload,rb,rb_format_supp,release_handler,release_handler_1,e rlsrv,sasl_report,sasl_report_tty_h,sasl_report_file_h,systools,systools_mak e,systools_rc,systools_relup,systools_lib]},{registered,[sasl_sup,alarm_hand ler,overload,release_handler]},{applications,[kernel,stdlib]},{included_appl ications,[]},{env,[{sasl_error_logger,tty},{errlog_type,all}]},{start_phases ,undefined},{maxT,infinity},{maxP,infinity},{mod,{sasl,[]}}]}]}} {progress,applications_loaded} {apply,{application,start_boot,[kernel,permanent]}} Erlang (BEAM) emulator version 5.2.2 [hipe] [threads:0] {apply,{application,start_boot,[stdlib,permanent]}} Eshell V5.2.2 (abort with ^G) 1> {apply,{application,start_boot,[sasl,permanent]}} =PROGRESS REPORT==== 23-May-2003::15:29:45 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.33.0>}, {name,alarm_handler}, {mfa,{alarm_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 23-May-2003::15:29:45 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.34.0>}, {name,overload}, {mfa,{overload,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 23-May-2003::15:29:45 === supervisor: {local,sasl_sup} started: [{pid,<0.32.0>}, {name,sasl_safe_sup}, {mfa,{supervisor, start_link, [{local,sasl_safe_sup},sasl,safe]}}, {restart_type,permanent}, {shutdown,infinity}, {child_type,supervisor}] =PROGRESS REPORT==== 23-May-2003::15:29:46 === supervisor: {local,sasl_sup} started: [{pid,<0.35.0>}, {name,release_handler}, {mfa,{release_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] {apply,{c,erlangrc,[]}} =PROGRESS REPORT==== 23-May-2003::15:29:46 === application: sasl started_at: nonode@REDACTED {progress,started} -----Original Message----- From: Chris Pressey [mailto:cpressey@REDACTED] Sent: 23 May 2003 02:50 To: Vlad Dumitrescu Cc: erlang-questions@REDACTED Subject: Re: Very strange behaviour! On Thu, 22 May 2003 10:14:02 +0200 "Vlad Dumitrescu" wrote: > Solved!!! > > > - or just littering the startup code with erlang:display("here!") > > statements... crude but at least an indication of roughly where > > the slowdown is occurring > > Thanks a lot for the idea! I was so frustrated that I couldn't think > straight! :-) Glad I could help :) Especially since I generally have no idea what I'm doing... :) Mini-poll question to the list in general: What would you think of a -verbose_startup option for helping debug these sorts of problems? -Chris NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From eleberg@REDACTED Fri May 23 16:42:08 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Fri, 23 May 2003 16:42:08 +0200 (MEST) Subject: ring of processes, as described in ''Concurrency Oriented programming in Erlang'' talk Message-ID: <200305231442.h4NEg8q16295@cbe.ericsson.se> greetings, i am looking in the mail archive to find the source code for the ''ring of processes'', as described in the ''Concurrency Oriented programming in Erlang'' talk given by joe amstrong at Lightweight Languages Workshop 2002. however, i am (sofar) unable to find it. perhaps the source is available somewhere else? bengt From etxuwig@REDACTED Fri May 23 16:55:13 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 23 May 2003 16:55:13 +0200 (MEST) Subject: Supervisor In-Reply-To: <1053698679.4019.35.camel@berimbau.vail> Message-ID: On 23 May 2003, martin j logan wrote: >On Fri, 2003-05-23 at 03:12, Inswitch Solutions - Erlang Evaluation >wrote: >> >> I have three FSM machines FSM1, FSM2 and FSM3. >> FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked). > >It is best to have supervisors create all of your workers. If you can >structure your processes this way go ahead and do it. It should not be a >problem if fsm2 is a long lived process. >> >> Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses >> FSM2 continously. > >I don't know the specifics of your problem but it sounds like it would >be suited to one of two supervision strategies. > >1. One supervisor with a one_for_one strategy. Start the FSMs in the >following order: FSM1, FSM2, FSM3. > >2. A two tier supervision structure. Tier one with a one_for_one >strategy. First start a second supervisor next start FSM3. The second >supervisor starts, with a one_for_all strategy, FSM1 then FSM2. The >chronological order for process creation under this scheme is 1. top >level supervisor, 2. second tier supervisor, 3. FSM1, 4. FSM2, 5. FSM3. 3. Look into using rest_for_one. If the supervisor starts FSM1, FSM2, and FSM3, in that order, FSM3, but not FSM1, will automatically be restarted if FSM2 dies. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From tobbe@REDACTED Fri May 23 14:28:51 2003 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 23 May 2003 14:28:51 +0200 Subject: Help wanted Message-ID: <3ECE1403.1040304@bluetail.com> Hi, I'm in the process of making a new release of BTT (Bluetail Ticket Tracker) after a major overhaul of the system. I wonder if anyone out there would like to help out translating the language definition file from English into other languages. So far I've already got help with the French translation. I've got an outdated German and Swedish translation as well. NB: I think it would be possible to also translate into other non-latin1 languages since the charset used can be defined in the language definition file. So if anyone would like to help out, send me a mail so that I can coordinate the efforts. Have a nice weekend ! /Tobbe From erlang@REDACTED Fri May 23 13:58:39 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 23 May 2003 12:58:39 +0100 Subject: SciTE (was: Re: not a question, just a fun thing with syntax_tools) References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> <20030521214018.GA64016@frogman.motivity.ca> <3ECC1FDF.3060808@versatechs.com> <3ECC6A1E.2030802@manderp.freeserve.co.uk> <20030522210233.54f4ec3c.cpressey@catseye.mb.ca> Message-ID: <3ECE0CEF.7000602@manderp.freeserve.co.uk> Hi Chris, If you're willing to recompile the source, here's the source for Erlang support. The files are for v1.53, but do a diff just to be sure my files don't walk all over things. Hopefully I haven't missed anything. The lexer colours the source file, but the folding algorithm is a bit primitive. It folds "case", "fun", "if" and "receive" statements, but I would also like it to fold function clauses too, which will require a better lexer and syntax analyser. I wish to use http://spirit.sourceforge.net which is recursive descent, easy to understand, and thanks to C++ templates I can practically copy the Erlang EBNF spec straight into C++ code. Nice. There's also user-defined folds which are marked thus: %{ fold start %} fold end ...and I find that's quite neat already. I've also enclosed the .SciteUser.properties file I use which uses spaces instead of tabs. (You'll notice I was using the Matlab lexer until I got tired of it and rolled my own.) The spaces-for-tabs option is not available in any of the menus, but there are _so_many_ options that I think the menus would become impractical if they were all included! Let's see if this weans you off the nedit addiction (-: Nedit doesn't look all that bad really, so why is it so unhealthy? The one possible advantage of SciTE is that it works on M$-Windows too, but why would I want to do that? Pete. Chris Pressey wrote: > On Thu, 22 May 2003 07:11:42 +0100 > Peter-Henry Mander wrote: > > >>Since we're on the subject, has anyone come across SciTE from >>http://scintilla.org/SciTE.html ? It doesn't have an Erlang lexer >>out-of-the-box, but I've been working on two versions. Both have >>syntax highlighting, one has folding based on indentation depth, the >>other folds on (limited) syntax parsing. They're both a bit green, but >>I use SciTE almost exclusively and it suits me. The source will >>compile for M$-Windows as well as *NIX, and the editor has a pleasant >>GUI and tool integration. >> >>I'm planning to feed back my work into the SciTE project so that >>Erlang becomes one of the many languages it supports. But before I do, >>is anyone interested in giving it a spin and offering some criticism? > > > I found the port, built it, and tried it. > > Overall, I like it. > > I'm disappointed that it doesn't seem to have a way to simulate tabs - > or if it does, it hides it unecessarily. (Tabs are definately one of my > pet peeves. When I press left arrow, I want the cursor to move left one > space. Not three spaces, not eight spaces - just, one space, like > always. I like predictability in an editor.) > > I also couldn't see anything about defining or applying macros. > Although complete-word is nice, as is folding, and block comments... > Don't know yet if it's enough to break my unhealthy nedit addiction. > But an Erlang mode might push it over the hump :) > > -Chris > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: .SciTEUser.properties URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SciTE-1.53-Erlang.tgz Type: application/x-gtar Size: 30300 bytes Desc: not available URL: From micael.karlberg@REDACTED Thu May 22 17:02:14 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Thu, 22 May 2003 17:02:14 +0200 Subject: ANNOUNCE: Megaco-1.1.4 & Megaco-1.2.2 Message-ID: <16076.58998.681544.606121@gargle.gargle.HOWL> New versions of the Megaco application has been released. They can be found at the Erlang/OTP Megaco home page: http://www.erlang.org/project/megaco/ Regards, The Erlang/OTP team From etxuwig@REDACTED Fri May 23 19:20:03 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 23 May 2003 19:20:03 +0200 (MEST) Subject: recursive-descent parsing (was: Re: SciTE (was: Re: not a question, just a fun thing with syntax_tools)) In-Reply-To: <3ECE0CEF.7000602@manderp.freeserve.co.uk> Message-ID: On Fri, 23 May 2003, Peter-Henry Mander wrote: >The lexer colours the source file, but the folding >algorithm is a bit primitive. It folds "case", "fun", "if" >and "receive" statements, but I would also like it to fold >function clauses too, which will require a better lexer and >syntax analyser. I wish to use >http://spirit.sourceforge.net which is recursive descent, >easy to understand, and thanks to C++ templates I can >practically copy the Erlang EBNF spec straight into C++ >code. Nice. I started making a recursive-descent version of yecc a while back. The idea was that the generated code would be pretty enough that you'd want to read it. It was never finished. If anyone thinks the idea is interesting, you can have my code and run with it. I started with the erlang grammar for my tests. This was a mistake, I think, since there is a lot of code needed besides the generated code to e.g. compile a .erl file. Anyway... The following yecc clause: case_expr -> 'case' expr 'of' cr_clauses 'end' : {'case', element(2, '$1'), '$2', '$4'}. currently expands to this in the generated code: case_expr(Ts, Match, Skip, S) -> match_rule(['case', 'expr', 'of', 'cr_clauses', 'end'], Ts, fun(Result, Ts1, S1) -> X = {'case',element(2,'?v1'),'?v2','?v4'}, Match(X, Ts1, S1) end, Skip, S). Where Match is a dynamically created continuation. A clause with multiple branches: receive_expr -> 'receive' 'after' expr clause_body 'end' : {'receive', element(2, '$1'), [], '$3', '$4'}. receive_expr -> 'receive' cr_clauses 'end' : {'receive', element(2, '$1'), '$2'}. receive_expr -> 'receive' cr_clauses 'after' expr clause_body 'end' : {'receive', element(2, '$1'), '$2', '$4', '$5'}. Translates to this: receive_expr(Ts, Match, Skip, S) -> match_rules( [ {['receive', 'cr_clauses', 'after', 'expr', 'clause_body', 'end'], fun(Result, Ts1, S1) -> X = {'receive',element(2,'?v1'), '?v2','?v4','?v5'}, Match(X, Ts1, S1) end}, {['receive', 'after', 'expr', 'clause_body', 'end'], fun(Result, Ts1, S1) -> X = {'receive',element(2,'?v1'), [],'?v3','?v4'}, Match(X, Ts1, S1) end}, {['receive', 'cr_clauses', 'end'], fun(Result, Ts1, S1) -> X = {'receive',element(2,'?v1'),'?v2'}, Match(X, Ts1, S1) end} ], Ts, Skip, S). The idea was to maintain the structure of the grammar as far as possible, so that it would not be much harder to write the parser code by hand than to write the actual yecc grammar (the code generated from esyntax.yrl has 2.6 times more lines of code than esyntax.yrl does; compared to the normal yecc output, which expands it >17 times, it's a fair improvement in that regard.) Also, the parser still operates on one token at a time. Another idea was that grammars like the SQL grammar and megaco_text_parser are really pushing the limits of what's feasible with the current yecc (my opinion.) Enough rambling. I may be barking up the wrong tree, but if anyone wants to try and finish it, you can have the code. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From jilani.khaldi@REDACTED Fri May 23 19:41:43 2003 From: jilani.khaldi@REDACTED (Jilani Khaldi) Date: Fri, 23 May 2003 19:41:43 +0200 Subject: Help wanted In-Reply-To: <3ECE1403.1040304@bluetail.com> Message-ID: >I'm in the process of making a new release of BTT (Bluetail Ticket Tracker) >after a major overhaul of the system. > >I wonder if anyone out there would like to help out translating the language >definition file from English into other languages. So far I've already >got help >with the French translation. I've got an outdated German and Swedish >translation as well. NB: I think it would be possible to also translate into >other non-latin1 languages since the charset used can be defined in the >language definition file. Here for Italian. I am a technical writer at: http://www.oltrelinux.com/forums/list.php?f=343 ps. I am preparing 4 long articles on Erlang to publish on the monthly italian magazine "Linux&C" (we have more than 40.000 readers), so Erlang will land in Italy as Ruby did 3 years ago. Now, there is a great italian comunity of Ruby programmers and I will try again with Erlang. I am preparing an Erlang italian site and an interview to Joe to publish it with the articles. Joe, could you here me? -- Jilani Khaldi http://www.jilani.net From vlad_dumitrescu@REDACTED Fri May 23 19:54:53 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 23 May 2003 19:54:53 +0200 Subject: Very strange behaviour! References: Message-ID: RE: Very strange behaviour!>There is a -init_debug option for erl - it works with werl as well. I wish I had known before spending almost a whole day tacking the problem down. :-) Next time, however, there is one more trick to try! Thanks! Vlad From vances@REDACTED Fri May 23 20:36:41 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 23 May 2003 14:36:41 -0400 Subject: Supervisor In-Reply-To: <002401c32103$145af670$1e00a8c0@design> References: <002401c32103$145af670$1e00a8c0@design> Message-ID: <20030523183641.GF67001@frogman.motivity.ca> Eduardo, To be clear you want to have a seperate process which implements the supervisor behaviour and not have the FSM1 process "re-create FSM2". This supervisor process will be linked to FSM2 and will estart it when it terminates according to the restart strategy which you specified. You can have the FSM1 process start the FSM2 process when and if it finds it necessary and still use the seperate supervisor strategy. In this case the FSM1 process would call supervisor:start_child/2 which dynamically sets up a new child which from then on will be supervised by the supervisor process. You can also dynamically terminate or restart it from FSM1. Martin and Ulf described some supervisor heirarchy stategies. You will want to abstract out the supervision problem from the finite state machine logic and create the appropriate handling with some number of supervisor behaviour processes and the appropriate child specifications. } 1 - Can I use supervisor behavior in this case ? You really should. Until you want to spend your time inventing a better mouse trap use the well tested supervisor code. } 2 - Is it easier to trap EXIT signals ? Some of the more purist concurrent programmers on this list would say yes. Their reasoning is that you would create a process recreation strategy which is tailored to your specific problem. For them it is such a simple problem that they would rather just write it than use some generic code for it. I would suggest though that for you (and I) it is a more complicated problem than you want to tackle. -Vance On Fri, May 23, 2003 at 10:12:35AM +0200, Eduardo Figoli wrote: } } I have three FSM machines FSM1, FSM2 and FSM3. } FSM1 creates FSM2 (linked) and FSM3 uses FSM2 (linked). } } Whenever FSM2 exit I'd like FSM1 to re-create FSM2 again, so FSM3 uses FSM2 continously. } } Questions: } 1 - Can I use supervisor behavior in this case ? } Are there any examples of supervisor usage to look for ? } 2 - Is it easier to trap EXIT signals ? } } } Many thanks, } Eduardo Figoli } INSwitch Solutions From vances@REDACTED Fri May 23 21:01:04 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 23 May 2003 15:01:04 -0400 Subject: Supervisor In-Reply-To: <002401c32103$145af670$1e00a8c0@design> References: <002401c32103$145af670$1e00a8c0@design> Message-ID: <20030523190104.GK67001@frogman.motivity.ca> } Are there any examples of supervisor usage to look for ? Scott Lystig Fritchie posted an example back in November: http://www.erlang.org/ml-archive/erlang-questions/200211/msg00258.html -Vance From cpressey@REDACTED Fri May 23 21:08:56 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 23 May 2003 14:08:56 -0500 Subject: SciTE (was: Re: not a question, just a fun thing with syntax_tools) In-Reply-To: <3ECE0CEF.7000602@manderp.freeserve.co.uk> References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> <20030521214018.GA64016@frogman.motivity.ca> <3ECC1FDF.3060808@versatechs.com> <3ECC6A1E.2030802@manderp.freeserve.co.uk> <20030522210233.54f4ec3c.cpressey@catseye.mb.ca> <3ECE0CEF.7000602@manderp.freeserve.co.uk> Message-ID: <20030523140856.20bca712.cpressey@catseye.mb.ca> On Fri, 23 May 2003 12:58:39 +0100 Peter-Henry Mander wrote: > Hi Chris, > > If you're willing to recompile the source, here's the source for > Erlang support. The files are for v1.53, but do a diff just to be sure > my files don't walk all over things. Hopefully I haven't missed > anything. OK, thanks! I'll try it out. > The lexer colours the source file, but the folding algorithm is a bit > primitive. It folds "case", "fun", "if" and "receive" statements, but > I would also like it to fold function clauses too, which will require > a better lexer and syntax analyser. I wish to use > http://spirit.sourceforge.net which is recursive descent, easy to > understand, and thanks to C++ templates I can practically copy the > Erlang EBNF spec straight into C++ code. Nice. > > There's also user-defined folds which are marked thus: > > %{ fold start > %} fold end > > ...and I find that's quite neat already. If I may make a suggestion - I'd like to see folds on lists and maybe tuples, too. Especially in file:consult/1 format files. Often when you're coding in a 'data driven' style, lists can get kind of hairy, spanning multiple lines and so forth... Um... also, is there a way to, say, fold all funs, but just the funs? That would be handy (sometimes I've got one function with a dozen funs inside it (being the easiest way to use bound variables from the main function) and they really clutter the main logic.) > I've also enclosed the .SciteUser.properties file I use which uses > spaces instead of tabs. (You'll notice I was using the Matlab lexer > until I got tired of it and rolled my own.) OK, thanks again - thanks to yvan as well for pointing this out. > The spaces-for-tabs option is not available in any of the menus, but > there are _so_many_ options that I think the menus would become > impractical if they were all included! Yeah, I didn't notice the "Edit [Local/User/Global] Options..." menu item; this approach makes more sense now. > Let's see if this weans you off the nedit addiction (-: Nedit doesn't > look all that bad really, so why is it so unhealthy? It's not actually that bad - I was exaggerating. It is rather heavyweight, though (Motif-based.) I'd like to be able to jettison OpenMotif if I can... almost everything else I use regularly (sylpheed, dillo, gimp, &c) is GTK-based. > The one possible > advantage of SciTE is that it works on M$-Windows too, but why would I > want to do that? > > Pete. It's not as much a matter of 'want' as 'have to', sometimes :) -Chris From enewhuis@REDACTED Fri May 23 21:16:41 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 23 May 2003 14:16:41 -0500 Subject: HIPE'd stdlib modules rule !!! Message-ID: <3ECE7399.6080506@futuresource.com> My app was slow, relatively speaking ~ 20% CPU on an arbitrary peice of iron. I HIPE'd the orddict.beam file (erlc +native orddict.beam) and now the same app is fast, relatively speaking ~ 5% CPU on that same arbitrary peice of iron. Is there an Erlang Makefile option I missed that HIPEs everything? Or have I stumbled onto something new? Were there former recommendations against HIPEing the standard Erlang library modules? Now that I've got this performance kicker I don't want to go back to the non-HIPE'd modules. Am I cutting against the grain? Will Armstrong hunt me down? An inquiring mind wants to know. From rpettit@REDACTED Sat May 24 04:32:21 2003 From: rpettit@REDACTED (Rick Pettit) Date: Fri, 23 May 2003 21:32:21 -0500 Subject: Is there a UBF driver for C++? Message-ID: <20030524023221.GA2376@vailsys.com> I suppose this question should be directed to Joe Armstrong, but perhaps someone else here has been playing with UBF and C/C++? I recently read "Getting Erlang to talk to the outside world" and began to play with the sample servers and contract checker from Joe's site. I also noticed that there was code (in Java) for a UBF driver in: rpettit@REDACTED ~/ubf/ubf-1.11/ubf-java-0.3/src/ubf # ls InteractiveClient.java UBFEncoder.java UBFObject.java UBF.java UBFEventHandler.java UBFString.java UBFAtom.java UBFException.java UBFTest.java UBFClient.java UBFInteger.java UBFTuple.java UBFDecoder.java UBFList.java irc1 Does something like this exist for C/C++? Is anyone working on such a thing? -Rick From klacke@REDACTED Mon May 26 00:19:59 2003 From: klacke@REDACTED (Klacke) Date: Mon, 26 May 2003 00:19:59 +0200 Subject: ssl & yaws In-Reply-To: <4405D76EF1E9D4119B2700A0CC754C7C2A2DC5@postoffice.netkitsolutions.com> References: <4405D76EF1E9D4119B2700A0CC754C7C2A2DC5@postoffice.netkitsolutions.com> Message-ID: <20030525221959.GA11768@bluetail.com> On Fri, May 09, 2003 at 04:29:02PM -0700, Eric P. Melbardis wrote: > hi all, > > I am using erlang r9b-1/yaws (1.2) in an intel win32 windows/xp environment. > > I tried to enable ssl support. > - downloaded latest version of opnessl (compiled & installed it) with vc 7.0 (.net!) > - re-compiled the erlang driver in the erlang library (driver was compiled for earlier version of > ssl, and the main init symbol was changed. > - configured yaws.conf for ssl operation > > i connected to the configured web site using https://.... > > got the first page, everything ok. > second page request came back ok, however the werl process started to consume 100% cpu > > subsequent pages still came back ok cpu remains 100% > > so it appears to work ok (in returning pages), > except for the massive cpu utilization which remains constant after the > second page! > > has any one experienced something like this? > figured i would ask first, before diving in..... > > I'm afraid "diving in" is required. I haven't tested yaws with ssl in quite some time. If you find something, let me know. I think that Sean&Co are running yaws with ssl but i'm not sure. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From joe@REDACTED Mon May 26 11:01:50 2003 From: joe@REDACTED (Joe Armstrong) Date: Mon, 26 May 2003 11:01:50 +0200 (CEST) Subject: Is there a UBF driver for C++? In-Reply-To: <20030524023221.GA2376@vailsys.com> Message-ID: On Fri, 23 May 2003, Rick Pettit wrote: > I suppose this question should be directed to Joe Armstrong, but perhaps > someone else here has been playing with UBF and C/C++? > > I recently read "Getting Erlang to talk to the outside world" and began to play > with the sample servers and contract checker from Joe's site. > > I also noticed that there was code (in Java) for a UBF driver in: > > rpettit@REDACTED ~/ubf/ubf-1.11/ubf-java-0.3/src/ubf # ls > InteractiveClient.java UBFEncoder.java UBFObject.java > UBF.java UBFEventHandler.java UBFString.java > UBFAtom.java UBFException.java UBFTest.java > UBFClient.java UBFInteger.java UBFTuple.java > UBFDecoder.java UBFList.java irc1 > > Does something like this exist for C/C++? Is anyone working on such a thing? > >From the mail I get I think the answer must be yes - either that or people are just interested in the ideas and not the implementation. If anybody does have any C/C++ code pleas send it to me and I'll update the UBF site archive /Joe > -Rick > From cpressey@REDACTED Mon May 26 01:31:50 2003 From: cpressey@REDACTED (Chris Pressey) Date: Sun, 25 May 2003 18:31:50 -0500 Subject: HIPE'd stdlib modules rule !!! In-Reply-To: <3ECE7399.6080506@futuresource.com> References: <3ECE7399.6080506@futuresource.com> Message-ID: <20030525183150.05ac83ec.cpressey@catseye.mb.ca> On Fri, 23 May 2003 14:16:41 -0500 Eric Newhuis wrote: > My app was slow, relatively speaking ~ 20% CPU on an arbitrary peice > of iron. > > I HIPE'd the orddict.beam file (erlc +native orddict.beam) and now the > same app is fast, relatively speaking ~ 5% CPU on that same arbitrary > peice of iron. You might be able to get it to go even faster if you can use 'dict' instead of 'orddict' :) > Is there an Erlang Makefile option I missed that HIPEs everything? Or > have I stumbled onto something new? Were there former recommendations > against HIPEing the standard Erlang library modules? The latest "non-technical" HiPE paper (which was very informative, btw) mentions it as a tip (if you +native your code you should also +native the modules it uses whereever possible.) Just for kicks I tried recompiling all of the kernel app with +native. I discovered that, for some reason, several header files (namely erl_epmd.hrl, hipe_ext_format.hrl, hipe.hrl, and hipe_literals.hrl) were not installed. In fact hipe_literals.hrl I couldn't find at all. Also, even when I copied erl_epmd.hrl over from the tarball, I couldn't get erl_epmd.erl to compile ("undefined macro 'erlang_daemon_port'", etc) so I just skipped it. I assume this is just because this is new, experimental stuff which isn't elegantly packaged. Also, it's kind of weird that so much code (in OTP and elsewhere) uses -include("foo.hrl") when there is the much nicer -include_lib("app/include/foo.hrl"), which makes a lot more sense to me, since it doesn't force you to compile stuff from a particular directory. I had to change a lot of -include's to -include_lib's just to get the kernal app recompiled. Is there still a good reason for using -include, or is it just that old habits die hard? -Chris From taj.khattra@REDACTED Sat May 24 23:12:47 2003 From: taj.khattra@REDACTED (Taj Khattra) Date: Sat, 24 May 2003 14:12:47 -0700 Subject: The Erlang way - dynamic upgrade of a server and UBF extensions In-Reply-To: <873cj7y40p.fsf@ghidra.vail> References: <873cj7y40p.fsf@ghidra.vail> Message-ID: <20030524211247.GA958@localhost.localdomain> On Wed, May 21, 2003 at 11:55:02PM -0500, Hal Snyder wrote: > > A network is made up of globs of consumers and producers of various > resources. The characterization of a host includes a list of > services for which it is producer or consumer (to which clusters does > this host belong), with group and instance identifiers for each > service. > isn't this a type of service that a GCS (group communication system) like Ensemble, Spread etc. would provide ? -taj From kostis@REDACTED Mon May 26 15:51:04 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 26 May 2003 15:51:04 +0200 Subject: HIPE'd stdlib modules rule !!! Message-ID: <3ED21BC8.6060200@csd.uu.se> I've sent the following yesterday, but the Erlang mailing list was down. Apologies if it shows up again. Kostis. ========================================================================= Eric Newhuis wrote: > > My app was slow, relatively speaking ~ 20% CPU on an arbitrary peice of > iron. > > I HIPE'd the orddict.beam file (erlc +native orddict.beam) and now the > same app is fast, relatively speaking ~ 5% CPU on that same arbitrary > peice of iron. > > Is there an Erlang Makefile option I missed that HIPEs everything? Or > have I stumbled onto something new? Currently, there is not something that does what you are looking for automatically. The closest thing to this is to manually edit the src/Makefile of the directory you want to compile to native code and add a +native option in a line that reads: ERL_COMPILE_FLAGS += ... > Were there former recommendations against HIPEing the standard > Erlang library modules? Not as far as I know. There should not be. Currently, there are not compiled to native code by default mostly to preserve backwards compatibility and to minimize the number of possible surprises to the user, whether these are positive (i.e. increased performance), or negative (changes in observable behaviour; e.g. no debugging). > Now that I've got this performance kicker I don't want to go back > to the non-HIPE'd modules. Good for you! > Am I cutting against the grain? Will Armstrong hunt me down? I do not want to speak for Joe, but I cannot see why he would be interested in doing something like that... Kostis Sagonas (for the HiPE group). From kostis@REDACTED Sun May 25 17:00:33 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 25 May 2003 17:00:33 +0200 (MEST) Subject: HIPE'd stdlib modules rule !!! In-Reply-To: Mail from 'Eric Newhuis ' dated: Fri, 23 May 2003 14:16:41 -0500 Message-ID: <200305251500.h4PF0XwA002324@harpo.it.uu.se> Eric Newhuis wrote: > > My app was slow, relatively speaking ~ 20% CPU on an arbitrary peice of > iron. > > I HIPE'd the orddict.beam file (erlc +native orddict.beam) and now the > same app is fast, relatively speaking ~ 5% CPU on that same arbitrary > peice of iron. > > Is there an Erlang Makefile option I missed that HIPEs everything? Or > have I stumbled onto something new? Currently, there is not something that does what you are looking for automatically. The closest thing to this is to manually edit the src/Makefile of the directory you want to compile to native code and add a +native option in a line that reads: ERL_COMPILE_FLAGS += ... > Were there former recommendations against HIPEing the standard > Erlang library modules? Not as far as I know. There should not be. Currently, there are not compiled to native code by default mostly to preserve backwards compatibility and to minimize the number of possible surprises to the user, whether these are positive (i.e. increased performance), or negative (changes in observable behaviour; e.g. no debugging). > Now that I've got this performance kicker I don't want to go back > to the non-HIPE'd modules. Good for you! > Am I cutting against the grain? Will Armstrong hunt me down? I do not want to speak for Joe, but I cannot see why he would be interested in doing something like that... Kostis Sagonas (for the HiPE group). From cpressey@REDACTED Sun May 25 22:56:18 2003 From: cpressey@REDACTED (Chris Pressey) Date: Sun, 25 May 2003 15:56:18 -0500 Subject: (OT) rebuttal against "Why OO Sucks" Message-ID: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> I'm not 100% happy with it, but if I keep editing it until I'm 100% happy it'll never be done. So, here is a rebuttal to Joe's essay: http://www.catseye.mb.ca/articles/oodspd.html And for more fair time, here is another essay critical of OO that I stumbled upon: http://home.planet.nl/~faase009/AoP_OOCH.html -Chris From richardc@REDACTED Mon May 26 16:33:50 2003 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 26 May 2003 16:33:50 +0200 (MET DST) Subject: dict/orddict (was: HIPE'd stdlib modules rule !!!) In-Reply-To: <20030525183150.05ac83ec.cpressey@catseye.mb.ca> References: <3ECE7399.6080506@futuresource.com> <20030525183150.05ac83ec.cpressey@catseye.mb.ca> Message-ID: On Sun, 25 May 2003, Chris Pressey wrote: > On Fri, 23 May 2003 14:16:41 -0500 > Eric Newhuis wrote: > > > I HIPE'd the orddict.beam file (erlc +native orddict.beam) and now the > > same app is fast, relatively speaking ~ 5% CPU on that same arbitrary > > peice of iron. > > You might be able to get it to go even faster if you can use 'dict' > instead of 'orddict' :) Not necessarily. It depends quite a lot on the application. The data structures used by the 'dict' module have higher overhead, both space-wise (if there are relatively few elements in the dictionary) and time-wise. Where the break-even point is exactly can vary a bit (in particular, it can vary with whether you insert often, or just look up), but when I have checked, it has been somewhere between 20 and 100 elements. So, if you *know* that your dictionaries will contain at most than a couple of dozen elements, the 'orddict' module is your choice (but be warned that you could run into complexity problems if you start using the app for larger problems). If you could easily have 50-100 elements or more, you should use the 'dict' module. If in doubt, use the latter, unless it is actually important to you that the representation uses ordered lists. The same reasoning applies to the modules 'sets' and 'ordsets', of course. One example where ordsets can pay off is when you both do insertion and union/intersection. To take the union of two 'sets' actually requires more work than taking the union of two 'ordsets'. It could also be a good idea to separate the data representation into phases, using 'sets' when you do a lot of insertion and/or lookup, and using 'ordsets' when you mostly do union, intersection or subtraction. Needless to say (or is it?), the usual "premature optimization is the root of all evil" applies. Only use ordsets/orddict if you need to. My own programs often contain code like this: %% ---------------------------- %% Dictionary implementation dict__new() -> orddict:new(). % dict:new(). dict__store(Val, Dict) -> orddict:store(Val, Dict). % dict:store(Val, Dict). ...etc. to make it easy to switch implementation. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From erlang@REDACTED Mon May 26 01:21:23 2003 From: erlang@REDACTED (Peter Mander) Date: Mon, 26 May 2003 00:21:23 +0100 Subject: SciTE (was: Re: not a question, just a fun thing with syntax_tools) References: <200305210804.h4L848q18048@cbe.ericsson.se> <20030521180151.GD63273@frogman.motivity.ca> <001901c31fdc$20088000$fd7a40d5@telia.com> <20030521212308.GH63273@frogman.motivity.ca> <20030521214018.GA64016@frogman.motivity.ca> <3ECC1FDF.3060808@versatechs.com> <3ECC6A1E.2030802@manderp.freeserve.co.uk> <20030522210233.54f4ec3c.cpressey@catseye.mb.ca> <3ECE0CEF.7000602@manderp.freeserve.co.uk> <20030523140856.20bca712.cpressey@catseye.mb.ca> Message-ID: <003401c32314$fbb5ce60$a80b893e@qurious> > > If you're willing to recompile the source, here's the source for > > Erlang support. > OK, thanks! I'll try it out. Any feedback will be received with thanks :-) > If I may make a suggestion - I'd like to see folds on lists and maybe > tuples, too. I believe that's in there already. > Um... also, is there a way to, say, fold all funs, but just the funs? > That would be handy I don't think SciTE can selectively fold. Besides, how would that work in the user interface? I don't think SciTE make any distinction between types of folds. I'm beginning to wonder if I can write a C node using ei to take advantage of the Scintilla editor directly from Erlang... And before anyone mentions Distel+Emacs, I reply peanuts+sledgehammers (-: You _can_ have too much of a good thing! :-) Pete. From richardc@REDACTED Mon May 26 18:47:14 2003 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 26 May 2003 18:47:14 +0200 (MET DST) Subject: Package support in Erlang: Status ? In-Reply-To: References: Message-ID: On Thu, 22 May 2003, david wallin wrote: > How about this, do a file:consult/1 on a file containing : > > {abba_a,a}. > {abba.b,b}. > > This results in an error : '{error,{1,erl_parse,"bad term"}}' Found it - the function erl_parse:normalise/1 did not understand the dot notation. Below is a patch, which also fixes another latent bug. /Richard *** lib/stdlib/src/erl_parse.yrl 16 May 2003 12:15:16 -0000 1.13 --- lib/stdlib/src/erl_parse.yrl 26 May 2003 16:12:09 -0000 *************** *** 511,523 **** package_segments(Name) -> ! package_segments(Name, []). ! package_segments({record_field,_,F1,F2}, Fs) -> ! package_segments(F1, [F2 | Fs]); ! package_segments({atom,La,A}, [F | Fs]) -> ! [A | package_segments(F, Fs)]; ! package_segments({atom,La,A}, []) -> ! [A]; ! package_segments(_, _) -> error. --- 511,523 ---- package_segments(Name) -> ! package_segments(Name, [], []). ! package_segments({record_field, _, F1, F2}, Fs, As) -> ! package_segments(F1, [F2 | Fs], As); ! package_segments({atom, _, A}, [F | Fs], As) -> ! package_segments(F, Fs, [A | As]); ! package_segments({atom, _, A}, [], As) -> ! lists:reverse([A | As]); ! package_segments(_, _, _) -> error. *************** *** 581,584 **** --- 581,590 ---- normalise({tuple,_,Args}) -> list_to_tuple(normalise_list(Args)); + %% Atom dot-notation, as in 'foo.bar.baz' + normalise({record_field,_,_,_}=A) -> + case package_segments(A) of + error -> erlang:fault({badarg, A}); + As -> list_to_atom(packages:concat(As)) + end; %% Special case for unary +/-. normalise({op,_,'+',{char,_,I}}) -> I; *************** *** 587,591 **** normalise({op,_,'-',{char,_,I}}) -> -I; %Weird, but compatible! normalise({op,_,'-',{integer,_,I}}) -> -I; ! normalise({op,_,'-',{float,_,F}}) -> -F. normalise_list([H|T]) -> --- 593,598 ---- normalise({op,_,'-',{char,_,I}}) -> -I; %Weird, but compatible! normalise({op,_,'-',{integer,_,I}}) -> -I; ! normalise({op,_,'-',{float,_,F}}) -> -F; ! normalise(X) -> erlang:fault({badarg, X}). normalise_list([H|T]) -> Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From vances@REDACTED Mon May 26 21:23:32 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 26 May 2003 15:23:32 -0400 Subject: (OT) rebuttal against "Why OO Sucks In-Reply-To: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> Message-ID: <20030526192332.GH78046@frogman.motivity.ca> Glamour. Hmmm... Maybe we should write up some of the philosphies and features of Erlang with the direct intent of glamourizing it. The telco hardening perspective, although very attractive to me, does the opposite as telephone companies are seen as slow, stodgy, old fashioned and obsolete (laughably). As has been discussed here before a focus on Erlang as a "concurrent programming language" is great. I have been thinking a lot lately of the "let if fail" philosophy. In the beginning my code was written defensively but over time I began to understand the Erlang world better and without really thinking too much about it the defensiveness started to go away. After having given it some specific attention over the last few months I now am writing much better code. Once you have embraced this concept/philosophy/coding-style your code gets smaller, easier to understand and much more functional. How do we glamorize this? I guess any talk of "failure" is hard to make sexy. :) I see that Limbo has added exception handling to the core language. [http://www.vitanuova.com/inferno/4e/limbo1.html]: } } We have added exception handling to the Limbo language, replacing } sys->rescue etc. This is intended to make it more straightforward } to write fault-tolerant subsystems. The semantics broadly follow } that used by the programming language CLU. There are many advantages: } it is structured and fits into the language rather than being bolted } on; the programmer, compilers and JIT can see the scope of exception } handlers, allowing the system (for instance) to nil out values in the } block on an exception, and get register allocation right; and the } implementation is better. The source changes to Limbo applications } are relatively small, and the result is tidier. } Status:Implemented -Vance From cpressey@REDACTED Mon May 26 21:54:43 2003 From: cpressey@REDACTED (Chris Pressey) Date: Mon, 26 May 2003 14:54:43 -0500 Subject: HIPE'd stdlib modules rule !!! In-Reply-To: <3ED21BC8.6060200@csd.uu.se> References: <3ED21BC8.6060200@csd.uu.se> Message-ID: <20030526145443.2c347ccf.cpressey@catseye.mb.ca> On Mon, 26 May 2003 15:51:04 +0200 Kostis Sagonas wrote: > Eric Newhuis wrote: > [...] > > Were there former recommendations against HIPEing the standard > > Erlang library modules? > > Not as far as I know. There should not be. Currently, there are > not compiled to native code by default mostly to preserve backwards > compatibility and to minimize the number of possible surprises to > the user, whether these are positive (i.e. increased performance), > or negative (changes in observable behaviour; e.g. no debugging). Well, here's my experience - I recompiled kernel (except erl_epmd and hipe_x86_loader, which I couldn't get compiled for lack of proper header files) and stdlib (erl_parse took nearly 2 hours!) with +native. I also recompiled pibfi ( http://www.catseye.mb.ca/projects/pibfi-+ ) with +native, and ran the standard torture test (as shown in its SCREENSHOT.) Before doing this, the torture test took about 2 and a half hours averaging 185,000 instructions per second. With kernel, stdlib, and pibfi HiPE'd, the torture test took about 6 hours and averaged 74,000 instructions per second. Clearly, not what I expected. Looking at the pibfi code, it may be that, even though it 'looks' sequential, it just relies on message passing too much (between the interpreter and the store, etc.) On the other hand - everything still worked; the output was correct. Anyway, my feeling is that judicious use of +native is probably a better way to go than just compiling everything with HiPE ("+naive"? :) -Chris From robert.virding@REDACTED Mon May 26 22:34:53 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 26 May 2003 22:34:53 +0200 Subject: Fix for A=<<1>> References: Message-ID: <011001c323c6$436fc100$8300a8c0@virding.org> The old scanner worked in two passes, the pre_XXX functions just collect characters until the end of the form is reached, then the scan_XXX functions do the actual tokenising which is much easier when you know you all there is. This was done to make it simpler to handle the reentrant handling. As an aside leex generates a one pass scanner which handles the reentrant collecting and tokenising in one pass which is easy in generated code. Robert ----- Original Message ----- From: "Ulf Wiger" To: "James Hague" Cc: Sent: Friday, May 02, 2003 1:47 PM Subject: Re: Fix for A=<<1>> > > I quickly glanced at erl_scan.erl to see if my instinctive > objection to your patch was correct, and it was... but > leading to a further question/complaint: > > erl_scan.erl is designed to be reentrant. Thus, your code > may not always work, since it might happen that the split > into chunks will occur right inside "=<<". > > What I observed in erl_scan.erl is that this kind of > cheating is already done when matching "<<", ">>", ">=", > "->", etc. > > pre_escape/2 does things the hard (reentrant) way, but e.g. > scan_escape/2 cheats. > > > Or am I overlooking some magic code snippet that guarantees > that there are always enough bytes in the scan buffer to > ensure that the right function clause matches? > > (BTW, xmerl_scan.erl, which I wrote, suffers from the same > problem; matching multiples in the function head is great > for readability, but not if you want your scanner to be > reentrant.) > > /Uffe > > On Thu, 1 May 2003, James Hague wrote: > > >That the start of "A=<<1>>" is incorrectly tokenized into > >A, =<, < has always bothered me, so here's a patch for > >erl_scan.erl that fixes it. Special casing this in the > >scanner is a bit grotty, but it's better than having a > >special case in the documentation. > > > >I'm posting this here instead of erlang-patches to see if > >anyone can come up with a reason why this is a bad idea > >(besides being an odd special case). > > > >(Apologies for the manual patch, BTW.) > > > >James > > > > > >After: > > > >%% Punctuation characters and operators, first recognise multiples. > > > >insert: > > > >%% The first clause looks for "=<<" and splits it into "=","<<" so > >%% matches like "=<<1>>" aren't tokenized as "=<","<". > >scan1([$=,$<,$<|Cs], Toks, Pos) -> > > scan1(Cs, [{'<<',Pos},{'=',Pos}|Toks], Pos); > > > > > > -- > Ulf Wiger, Senior Specialist, > / / / Architecture & Design of Carrier-Class Software > / / / Strategic Product & System Management > / / / Ericsson AB, Connectivity and Control Nodes > > From robert.virding@REDACTED Mon May 26 23:19:48 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 26 May 2003 23:19:48 +0200 Subject: Fix for A=<<1>> References: , Message-ID: <011c01c323cc$8a0834c0$8300a8c0@virding.org> Doesn't all this work with a special case just to handle a general case tend to indicate that the original special case was probably wrong. VERY IMPORTANT Actually this special case means that tokens are no longer scaned in the same way. Everywhere else tokenising is eager, you collect as many characters as you can to mke a token EXCEPT HERE. Why not add other fantastic special cases: "caseVar" should be scaned as "case Var" "ifVar" should be scanned as "if Var" How about any word starting with receive/case/if should be split automatically as this is obviously what the programmer intended. As should any word ending in end. Obvious. Actually any token with if/case/receive/end should be split around them. Need I go on? There is no fundamental difference between these examples and the original one!! So this change should not be added for two main reasons: 1. You are introducing an inconsistency and inconsistencies are always bad. 2. You are trying to guess what the user actually meant and at the tokenising stage you have no idea of context. When I wrote "A=<<1>>" I might have actually meant to write "A =< <<1>>" so changing it automagically to "A=<<1>>" introduces a fundamental semantic change to my code. Can you GUARANTEE that this change is always what the programmer intended? ALWAYS? If not then you can't make this change. Sorry if sound a bit harsh but someone has to be the devil's advocate. Robert P.S. Raimo how did you get the speed up. I know the original was coded just as mucg for clarity as for speed (I wrote it), but how? ----- Original Message ----- From: "Raimo Niskanen" To: Sent: Monday, May 05, 2003 1:24 PM Subject: Re: Fix for A=<<1>> > Alright, fixed for any number of '<' characters. It was a rather simple > change. There should be no bad consequences for neither execution time > nor memory consumption either, it was just to count the '<' characters > and generate the tokens at the end of the sequence. > > If the change breaks anything in our daily build and test runs I will > let you know. Otherwise the change will come in R9C. > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > Ulf Wiger wrote: > > On Mon, 5 May 2003, Raimo Niskanen wrote: > > > > > >>But since sub-binaries are allowed when constructing: how > >>about '=<<<<<' as in "if A =< << <<1>>/binary, 2>>", then > >>one can see that the scanning of '=<<' depends on if the > >>number of '<' characters following is odd or even, so the > >>scanner might have to scan infinitely ahead. A look ahead > >>scan of limited small length would be fine, but this is > >>ugly. > > > > > > I'm not sure what the upper limit would be for a sequence of > > '<' symbols in a program making any qlaims of still being > > useable (one of course has to take into account generated > > code, which is usually less readable than hand-written > > code.) > > > > Perhaps a stupid question, but, so what if the scanner looks > > ahead and breaks for safety at, say, 1000 tokens? This won't > > cause any big problems as far as memory is concerned, and at > > least I find it difficult to envision a program that would > > break because of this, that is still worthy of being > > compiled. > > > > The following syntactically correct expression would no > > longer work (line breaks added for nettiquette compliance). > > I'm prepared to say "so what?": > > > > A =<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<1>> > > /binary,2>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>. > > > > /Uffe > > From robert.virding@REDACTED Mon May 26 23:31:02 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 26 May 2003 23:31:02 +0200 Subject: Fix for A=<<1>> References: , Message-ID: <021901c323ce$1b769fe0$8300a8c0@virding.org> Forgot to say sorry for the delay in answering but I haven't been connected for a while. Robert P.S. But the idea is still a bad one.-) ----- Original Message ----- From: "Raimo Niskanen" To: Sent: Monday, May 05, 2003 1:24 PM Subject: Re: Fix for A=<<1>> > Alright, fixed for any number of '<' characters. It was a rather simple > change. There should be no bad consequences for neither execution time > nor memory consumption either, it was just to count the '<' characters > and generate the tokens at the end of the sequence. > > If the change breaks anything in our daily build and test runs I will > let you know. Otherwise the change will come in R9C. > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > > Ulf Wiger wrote: > > On Mon, 5 May 2003, Raimo Niskanen wrote: > > > > > >>But since sub-binaries are allowed when constructing: how > >>about '=<<<<<' as in "if A =< << <<1>>/binary, 2>>", then > >>one can see that the scanning of '=<<' depends on if the > >>number of '<' characters following is odd or even, so the > >>scanner might have to scan infinitely ahead. A look ahead > >>scan of limited small length would be fine, but this is > >>ugly. > > > > > > I'm not sure what the upper limit would be for a sequence of > > '<' symbols in a program making any qlaims of still being > > useable (one of course has to take into account generated > > code, which is usually less readable than hand-written > > code.) > > > > Perhaps a stupid question, but, so what if the scanner looks > > ahead and breaks for safety at, say, 1000 tokens? This won't > > cause any big problems as far as memory is concerned, and at > > least I find it difficult to envision a program that would > > break because of this, that is still worthy of being > > compiled. > > > > The following syntactically correct expression would no > > longer work (line breaks added for nettiquette compliance). > > I'm prepared to say "so what?": > > > > A =<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<1>> > > /binary,2>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>/binary>>/binary>>/binary>>/binary>>/binary>> > > /binary>>. > > > > /Uffe > > From jay@REDACTED Mon May 26 23:43:33 2003 From: jay@REDACTED (Jay Nelson) Date: Mon, 26 May 2003 14:43:33 -0700 Subject: (OT) rebuttal against "Why OO Sucks Message-ID: <4.2.2.20030526144102.00ce4a40@duomark.com> > Once you have embraced this concept/philosophy/coding-style > your code gets smaller,easier to understand and much more functional. > How do we glamorize this? I guess any talk of "failure" is hard to make sexy. :) We need to promote waif code similar to waif models. Less is more (sexy)! Glamour is merely what the ad industry convinces the masses they should desire. From jay@REDACTED Mon May 26 23:52:04 2003 From: jay@REDACTED (Jay Nelson) Date: Mon, 26 May 2003 14:52:04 -0700 Subject: erlang P2P network Message-ID: <4.2.2.20030526144846.00cf9100@duomark.com> Joe mentioned once that he was looking for people to donate servers to set up an erlang P2P network. I am preparing to order and assemble a new machine with at least a firewall and one erlang node, although I want ultimately to have multiple nodes and a backend to access a local network for disk storage and database access. What was the desire for a P2P network? How would you use it? Is anyone still interested in having one? Any particular features you would expect it to have? jay From Chandrashekhar.Mullaparthi@REDACTED Tue May 27 02:31:40 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 27 May 2003 01:31:40 +0100 Subject: ssl & yaws Message-ID: Eric, We are running yaws will ssl on Solaris 2.7. It needed a few patches to make it work. My first attempt at submitting patches to Klacke failed...I'll try again. But I haven't seen the problem you mention. Have you investigated more...Look at the state of the yaws_server process when this is happening...it might give some clues. Try using pman and dig around. cheers, Chandru -----Original Message----- From: Klacke [mailto:klacke@REDACTED] Sent: 25 May 2003 23:20 To: Eric P. Melbardis Cc: erlang-questions@REDACTED Subject: Re: ssl & yaws On Fri, May 09, 2003 at 04:29:02PM -0700, Eric P. Melbardis wrote: > hi all, > > I am using erlang r9b-1/yaws (1.2) in an intel win32 windows/xp environment. > > I tried to enable ssl support. > - downloaded latest version of opnessl (compiled & installed it) with vc 7.0 (.net!) > - re-compiled the erlang driver in the erlang library (driver was compiled for earlier version of > ssl, and the main init symbol was changed. > - configured yaws.conf for ssl operation > > i connected to the configured web site using https://.... > > got the first page, everything ok. > second page request came back ok, however the werl process started to consume 100% cpu > > subsequent pages still came back ok cpu remains 100% > > so it appears to work ok (in returning pages), > except for the massive cpu utilization which remains constant after the > second page! > > has any one experienced something like this? > figured i would ask first, before diving in..... > > I'm afraid "diving in" is required. I haven't tested yaws with ssl in quite some time. If you find something, let me know. I think that Sean&Co are running yaws with ssl but i'm not sure. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From D.WILLIAMS@REDACTED Tue May 27 09:46:47 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Tue, 27 May 2003 09:46:47 +0200 Subject: Learning by reading code Message-ID: Hello, I am trying to learn Erlang, and like to read code written by experienced Erlangers. I came across the following things (in xmerl) for which I could find no explanation in the documentation: -compile(export_all). What does this mean? Does it automatically export all functions contained in the file? '#text'(Text) -> export_text(Text). There are lots of functions in xmerl with these funny names. Does this have any special significance? Cheers, Dominic. From eleberg@REDACTED Tue May 27 09:56:05 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 27 May 2003 09:56:05 +0200 (MEST) Subject: Learning by reading code Message-ID: <200305270756.h4R7u5q15985@cbe.ericsson.se> > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 > content-class: urn:content-classes:message > MIME-Version: 1.0 > Subject: Learning by reading code > Date: Tue, 27 May 2003 09:46:47 +0200 > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > Thread-Topic: Learning by reading code > Thread-Index: AcMkJCBSuu5qysadRYmHgj4F1EFEKg== > From: "WILLIAMS Dominic" > I am trying to learn Erlang, and like to read code written by experienced Erlangers. this is one (very good) part of learning to program. > I came across the following things (in xmerl) for which I could find no explanation in the documentation: > > -compile(export_all). > > What does this mean? Does it automatically export all functions contained in the file? > you are correct. > '#text'(Text) -> > export_text(Text). > > There are lots of functions in xmerl with these funny names. Does this have any special significance? > normal function names are written with [a-z] plus _ . if you want to use special characters in a function name (like #) you have to single quoute the name. bengt From mikael.karlsson@REDACTED Tue May 27 10:25:55 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Tue, 27 May 2003 10:25:55 +0200 Subject: Web applications unification Message-ID: <200305271025.55495.mikael.karlsson@creado.com> Hi, The workgroup at www.erlang-projects.org for a Web applications unification seems really interesting and the visions are impressive. I do not know the progress of the project but expect that it is quite a lot of work to be done, even when implemented in Erlang :-) Meanwhile I have a question how to get the act together to use some of the existing applications/libraries for a more simple web application framework - in a jboss (www.jboss.org) or Apache/Tomcat fashion. Erlang makes it "easy" to write http servers and clients and it seems that everyone contributing with applications like xmlrpc, idx-soap, proxies etc. roll their own. This is fine as long as it runs standalone, but when you want to integrate services in an application framework things get more complicated. So why not set some kind of standard interface or framework to build it on? Like: - http server: Yaws - http client: inets (originally jnets) http.erl - ODBC, Corba etc: Erlang/OTP - application control/configuration: Erlang/OTP - authentication: eldap ? - XML: xmerl - XML-RPC: xmlrpc (with interface to yaws and inets/http client) - SOAP: idx-soap (with interface to yaws and inets/http client) I think most things are (almost) in place to build a *really good* web application framework with Erlang. And I think that any higher order applications as the "Web applications unification" would benefit from a standard interface too. So, is this a good idea, any ideas how to get the things together? Would one need a dedicated framework application to drive and configure the others? /Mikael From joe@REDACTED Tue May 27 10:40:00 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 27 May 2003 10:40:00 +0200 (CEST) Subject: Eppur si sugat In-Reply-To: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> Message-ID: Eppur si sugat (was that right?) Hi Chris, Now I shall have to write a rebuttal to your rebuttal - this is "pens at dawn" stuff ... One of the problems about attacking OO programming is that nobody can actually agree on what it is. When we were researching the Erlang book Robert V. and I went into the library and borrowed *every* book there was that had anything to say about OO programming - most of theses books gave some loose definitions as to what they thought OOP was - unfortunately there was little agreement as to what the core ideas in OOP were. << This is not quite true - they did agree over one point - they all agreed that OOP was great - wonderful - amazingly spiffy etc >> I strongly disagree with the "Everything is an object" school of thinking - I know some people like this but it's not for me. Take a <<> thing like an integer. Integers can be defined by simple recursion equations, thus: If X is an integer then X ++ "1" is an integer (recursive case) "0" is an integer (base case) So "0" "01" "011" ... "011111111111111111111111" are all integers. Since it is a bit of a bother keeping track of all the 1's we use use simplified notations like "XIV" as an alias for "01111111111111", but the basic idea is the same. (And yes I know this is NOT how we implement it - but at least this defines what integers are) Piano would no doubt have been greatly surprised if he was reading "Java in a Nutshell" - he'd look up integer in the index and find himself reading ... public final call Integer extends Number implements Comparable { // Public Constructors public Integer(String s) throws NumberFormatException; ... At which point he would no doubt burst into tears and start banging his head against the wall ... << and yes, I guess you will response that "Joe is attacking Java and not OOP. He has confused the ideas of OOP with what is present in Java". To which I would answer "since there is no generally accepted idea as what OOP means I am forced to pick a specific language which claims to be an OO language and then tell you what's wrong with it" >> It seems to me much nicer to keep data structure definitions apart from the set of functions that operate upon them. Data structure definitions are finite and declarative. The set of functions which operate on them is infinite and (often) imperative. We can *easily* define a string as a sequence of integers - IMHO that's what a string *is*. In Erlang: +type string() = [int()]. I looked up string in the JIAN and to my surprise *nowhere* did it say what a string was. Instead it gave a long list of methods that could be used to turn strings into other things (and I'm guessing here, I'd bet that nowhere could I find definitions of what the other things are :-). In English we have "dictionaries" and "books" - Books are full of paragraphs and sentences, sentences are made of words. *If we want to know what a word means we look it up in the dictionary* Fortunately dictionaries are not OO - if they were I guess the dictionary would not only have a definition of the word, but also have to included all possible citations of the word. So when we looked up string, we would find not A string is a sequence of integers But rather A string is a ... The word string occurs in the following books ... ... list of 10 Million books ... I rest my case (for now) I'll be back /Joe On Sun, 25 May 2003, Chris Pressey wrote: > I'm not 100% happy with it, but if I keep editing it until I'm 100% > happy it'll never be done. So, here is a rebuttal to Joe's essay: > > http://www.catseye.mb.ca/articles/oodspd.html > > And for more fair time, here is another essay critical of OO that I > stumbled upon: > > http://home.planet.nl/~faase009/AoP_OOCH.html > > -Chris > From eleberg@REDACTED Tue May 27 10:54:47 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 27 May 2003 10:54:47 +0200 (MEST) Subject: Eppur si sugat Message-ID: <200305270854.h4R8slq21499@cbe.ericsson.se> > X-Authentication-Warning: enfield.sics.se: joe owned process doing -bs > Date: Tue, 27 May 2003 10:40:00 +0200 (CEST) > From: Joe Armstrong ...deleted > << and yes, I guess you will response that "Joe is attacking Java and > not OOP. He has confused the ideas of OOP with what is present in Java". > To which I would answer "since there is no generally accepted idea as > what OOP means I am forced to pick a specific language which claims to > be an OO language and then tell you what's wrong with it" >> there is an oo book, without language. ie, a book that claims to deal with oo, and not a particular oo language. it is ''object oriented software construction'', by bertrand meyer. perhaps it would be possible to aim the anti-oo critique towards the ideas in that book? failing that, would it not be better to pick a ''good'' oo language? if nothing else it would avoid the ''that is just a strawman'' type of argumentation you are refering to. bengt From tcoram@REDACTED Tue May 27 10:39:48 2003 From: tcoram@REDACTED (Todd Coram) Date: Tue, 27 May 2003 04:39:48 -0400 Subject: Eppur si sugat In-Reply-To: <200305270854.h4R8slq21499@cbe.ericsson.se> References: <200305270854.h4R8slq21499@cbe.ericsson.se> Message-ID: <20030527043948.6f3914de.tcoram@pobox.com> On Tue, 27 May 2003 10:54:47 +0200 (MEST) Bengt Kleberg wrote: > there is an oo book, without language. ie, a book that claims to deal > with oo, and not a particular oo language. it is ''object oriented > software construction'', by bertrand meyer. perhaps it would be > possible to aim the anti-oo critique towards the ideas in that book? That book, while well written, is very much with a language: Eiffel. The author explains at the end of the book that he has just taught you Eiffel. (Which he hopefully would then have you purchase it from his company ;-) Meyer tends to criticize other OO languages (Java, Smalltalk, etc) as being too soft (vague, etc). He is a very opinionated and passionate OO advocate. -- todd From raimo.niskanen@REDACTED Tue May 27 12:07:09 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Tue, 27 May 2003 12:07:09 +0200 Subject: Fix for A=<<1>> References: , , <011c01c323cc$8a0834c0$8300a8c0@virding.org> Message-ID: A non-text attachment was scrubbed... Name: not available Type: multipart/mixed Size: 36170 bytes Desc: not available URL: From eleberg@REDACTED Tue May 27 12:35:09 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 27 May 2003 12:35:09 +0200 (MEST) Subject: Eppur si sugat Message-ID: <200305271035.h4RAZ9q03914@cbe.ericsson.se> > Date: Tue, 27 May 2003 04:39:48 -0400 > From: Todd Coram > To: Bengt Kleberg > Cc: erlang-questions@REDACTED > On Tue, 27 May 2003 10:54:47 +0200 (MEST) > Bengt Kleberg wrote: > > > > there is an oo book, without language. ie, a book that claims to deal > > with oo, and not a particular oo language. it is ''object oriented > > software construction'', by bertrand meyer. perhaps it would be > > possible to aim the anti-oo critique towards the ideas in that book? > > That book, while well written, is very much with a language: Eiffel. The > author explains at the end of the book that he has just taught you > Eiffel. (Which he hopefully would then have you purchase it from his company ;-) i do not agree. (imho, fwiw, etc) he describes what he wants to do, and then introduces a formal way of writing this. so yes, there is a language, but that language is beeing built/constructed in the book. the book is not about the language. other oo books i have seen starts with the languge, showing what the language can do. bengt, who wishes he could explain the difference better... From joe@REDACTED Tue May 27 13:06:57 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 27 May 2003 13:06:57 +0200 (CEST) Subject: Eppur si sugat In-Reply-To: <200305271035.h4RAZ9q03914@cbe.ericsson.se> Message-ID: > > From: Todd Coram > > To: Bengt Kleberg > > Cc: erlang-questions@REDACTED > > > > On Tue, 27 May 2003 10:54:47 +0200 (MEST) > > Bengt Kleberg wrote: > > > > > > > there is an oo book, without language. ie, a book that claims to deal > > > with oo, and not a particular oo language. it is ''object oriented > > > software construction'', by bertrand meyer. perhaps it would be > > > possible to aim the anti-oo critique towards the ideas in that book? > > > > That book, while well written, is very much with a language: Eiffel. The > > author explains at the end of the book that he has just taught you > > Eiffel. (Which he hopefully would then have you purchase it from his company > ;-) > > i do not agree. (imho, fwiw, etc) Since I have the book in question in my bookshelves I thought I'd check ... Part I - is "Issues and principles" Part II - is "Techniques of OO design and programming" Part I is general, Part II is stuffed full of Eiffel Part I is full of rather general statements about good ways to program. Lot's of general statements like: - Design simplicity: a simple architecture will always be easier to adapt to changes than a complex one (page 5) "Every module should communicate with as few others as possible" (page 19) Then he goes on at great length to say "Abstract data types are wonderful" In part I there is virtually nothing I disagree with - and all the statements he makes are equally applicable to *any* style of programming - just general good advice, equally applicable to C, Java, Erlang, Basic, Cobol you name it - And (virtually) nothing do do with OO (at least not *exclusively* so). Part II - *is* Eiffel. The book reeks Eiffel - Part II shows how to achieve the goals in part I (nothing wrong with that) - But since I is so general then part II could equally well have been written in Erlang/C/anything - the goal being to show how good design principles (like minimal interfaces, ADTs etc) can be implemented in any language. I would not call this a "oo book without language" and I think Meyer's title is misleading. It's not about OO software construction. It's more "generally good design principles" + how to code things in Eiffel. The fact the "OO" word is on the cover and the word "eiffel" is absent from the cover notes is probably to sell more titles. /Joe Anyhow why all the fuss --- Erlang *is* OO 1) OO langauges are great, and stuffed full of generally "good to have" things. 2) Erlang is great and stuffed full of "good to have" things. 3) Therefore Erlang is an OO language QED From etxuwig@REDACTED Tue May 27 13:32:43 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 27 May 2003 13:32:43 +0200 (MEST) Subject: Learning by reading code In-Reply-To: Message-ID: On Tue, 27 May 2003, WILLIAMS Dominic wrote: >Hello, > >I am trying to learn Erlang, and like to read code written >by experienced Erlangers. I think this is good, and I notice that you've been reading my code. Hopefully, you will also keep in mind that experienced programmers do not always set good examples. ;) >I came across the following things (in xmerl) for which I >could find no explanation in the documentation: Apologies for the insufficient documentation. >-compile(export_all). >What does this mean? Does it automatically export all >functions contained in the file? Yes. It's a common way to start out when writing code. It means that you can easily call all functions in a compiled module from the shell. This makes it a lot easier to test your code. Normally, you're supposed to remove the -compile(export_all) and specifically export only the functions that should be exported. This is not always done. (: >'#text'(Text) -> > export_text(Text). > >There are lots of functions in xmerl with these funny >names. Does this have any special significance? These appear in callback modules for exporting XML structures (e.g. as HTML or XML text). The '#' is "namespace management", identifying the functions as special control functions. All other exported functions in such a module are supposed to signify XML tags (i.e. the function name matches the XML tag. Since '#text' is not a valid XML tag, there can be no name clash. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From etxuwig@REDACTED Tue May 27 13:36:29 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 27 May 2003 13:36:29 +0200 (MEST) Subject: Web applications unification In-Reply-To: <200305271025.55495.mikael.karlsson@creado.com> Message-ID: On Tue, 27 May 2003, Mikael Karlsson wrote: >So why not set some kind of standard interface or framework >to build it on? > >Like: >- http server: Yaws >- http client: inets (originally jnets) http.erl >- ODBC, Corba etc: Erlang/OTP >- application control/configuration: Erlang/OTP >- authentication: eldap ? >- XML: xmerl >- XML-RPC: xmlrpc (with interface to yaws and inets/http client) >- SOAP: idx-soap (with interface to yaws and inets/http client) > >I think most things are (almost) in place to build a >*really good* web application framework with Erlang. I agree. I also added 'builder' to jungerl as an attempt to provide a lightweight aide for packaging OTP applications and building start scripts. I don't know how well it succeeded (and it does need more work). The general idea was that you should be able to incrementally build more and more complex systems with relative ease. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From tcoram@REDACTED Tue May 27 13:42:42 2003 From: tcoram@REDACTED (Todd Coram) Date: Tue, 27 May 2003 07:42:42 -0400 Subject: Eppur si sugat References: Message-ID: <02f801c32445$15c76bc0$63983e9f@sis.ad.local> Joe Armstrong wrote: > Since I have the book in question in my bookshelves I thought I'd check ... > > Part I - is "Issues and principles" > Part II - is "Techniques of OO design and programming" > > Part I is general, Part II is stuffed full of Eiffel > > Part I is full of rather general statements about good ways to program. > Ah, you must have the first edition... The second edition weighs in at about 1200 pages and greatly expands upon the Eiffel-ness (it even comes with a "demo" Eiffel development environment --- but never referred to as Eiffel). > In part I there is virtually nothing I disagree with - and all the > statements he makes are equally applicable to *any* style of > programming - just general good advice, equally applicable to C, Java, > Erlang, Basic, Cobol you name it - And (virtually) nothing do do with > OO (at least not *exclusively* so). Yes. Those are the comforting bits. It's my favorite OO text because Meyer speaks his mind, stays away from "fashionable trends" (with the exception of OO iteself ;-) and generally irritates other non-Eiffel OO advocates. BTW, Meyer's big claim to fame is "Design by Contract". Although woven throughout Eiffel, it has been applied to other languages as well. Design by Contract specifies that you impose "contracts" (assertive statements) upon your functions that check a pre-condition (are the parameters correct?) and post-conditions (did the function produce what I expected?). Also, there are "class invariants" that make sure that certain variable boundaries are never broken (e.g. count must never be below 0 and above 255). I suppose that the preconditions could be accomplished in Erlang by the use of guards (bear with me, I'm an Erlang newbie), but postconditions and class invariants have little analog in functional programming (no side-effects!). But, then, OO is all about side-effects - (ab)use as many variables as needed so as long as they are encapsulated! You need postconditions and class invariants to keep track of what variables may have been accidently violated... -- todd From eleberg@REDACTED Tue May 27 13:44:05 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 27 May 2003 13:44:05 +0200 (MEST) Subject: Eppur si sugat Message-ID: <200305271144.h4RBi5q10470@cbe.ericsson.se> (when i find myself disagreeing with someone that is obviously much more intelligent and experienced than i am, i really try to understand where i am going wrong. perhaps i will get my mistake if i try to explain how i read oosc) > X-Authentication-Warning: enfield.sics.se: joe owned process doing -bs > Date: Tue, 27 May 2003 13:06:57 +0200 (CEST) > From: Joe Armstrong ...deleted > Since I have the book in question in my bookshelves I thought I'd check ... > > Part I - is "Issues and principles" > Part II - is "Techniques of OO design and programming" > > Part I is general, Part II is stuffed full of Eiffel > > Part I is full of rather general statements about good ways to program. > > Lot's of general statements like: ...deleted > Part II - *is* Eiffel. The book reeks Eiffel - Part II shows how to > achieve the goals in part I (nothing wrong with that) - But since I is > so general then part II could equally well have been written in > Erlang/C/anything - the goal being to show how good design principles > (like minimal interfaces, ADTs etc) can be implemented in any > language. i read oosc part 2 as an attempt to _find_ ''the best possible'' design/notation to achieve the goals in part I. i think it is clearly stated that while any turing complete language would do, it is the intention that this way of designing should be ''the best possible''. there is a book, ''objects unencapsulated'' that explains where oosc goes wrong, so ''the best possible'' definitly needs the quoutes. > I would not call this a "oo book without language" and I think Meyer's > title is misleading. it was i that called oosc "oo book without language". and i really think the title is good. i parse it like this ((OO software)construction). meaning that he is constructing a oo software system/language/notation. see below. > It's not about OO software construction. It's more > > "generally good design principles" + how to code things in Eiffel. i experience the book as an example of 1 stating good ideas (part 1). 2 trying to achive these good ideas (part 2). where i beg to differ from joe is that i do not find that the good ideas are implemented straight off in eiffel (part 2). instead i read part 2 as a attempt to formulate various ways of achiving these good ideas. most ways are rejected as not beeing good enough. the ideas that are kept are then formalised into a notation, a oo language. when the book is done, the total amount of formalised ideas ''happens'' to amount to a language, eiffel. bengt, who have this sinking feeling that he has been brainwashed by a very persuasive author and fails to get his thought processes back on line... From serge@REDACTED Tue May 27 05:28:48 2003 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 26 May 2003 23:28:48 -0400 Subject: erl_interface and lists Message-ID: <3ED2DB70.7040004@hq.idt.net> Could someone shed some light on how to decode lists' elements (other than head and tail) in erl_interface. The examples included in the docs are pretty clear on how to decode tuples and atoms, but I can't seem to find any reference for functions dealing with retrieval of an N'th element of a list. Suppose the Erlang side of the interface is passing a tuple to a C port: {init, [a, b, c]} ETERM *tuple = erl_decode(buf); ETERM *atom = erl_element(1, tuple); ETERM *list = erl_element(2, tuple); Then what I'd like to do is to iterate over each element of the list: for (int i=0; i < erl_length(list); i++) { do_smthng_with_item(ERL_NTH_ELEMENT(i, list)); } So, how can I implement ERL_NTH_ELEMENT()? Thanks. Serge From bruce.fitzsimons@REDACTED Tue May 27 06:48:03 2003 From: bruce.fitzsimons@REDACTED (Bruce Fitzsimons) Date: Tue, 27 May 2003 16:48:03 +1200 Subject: Gentoo: dev-lang/erlang References: <1053660475.1509.4.camel@localhost> <200305222134.29077.george@gentoo.org> Message-ID: <14e501c3240b$28a94d10$0a21970a@norris> Hi George (cc to the helpful people on erlang-questions -- George maintains, amongst other things, the ebuild package for erlang in the Gentoo linux distribution), I agree it is complicated, I wasn't aware of those restrictions on ebuilds. I would suggest simplifying the version number by treating the letters as numbers, where A = 0, so R9B-1 becomes 9.1.1, R8A-0 becomes 8.0.0. A note in the description that says the untranslated Erlang version number might be handy too. What do you think? Thanks for taking the time to write such a detailed response. /Bruce ----- Original Message ----- From: "George Shapovalov" To: "Bruce Fitzsimons" Sent: Friday, May 23, 2003 4:34 PM Subject: Re: Gentoo: dev-lang/erlang > Hi Bruce. > > Thank you for your interest in Gentoo and erlang in particular. > Regarding the versioning of the package: I should say that I am not happy with > such versioning either, however I could not find any better approach at the > moment. > The naming scheme for ebuilds is described here: > http://www.gentoo.org/doc/en/gentoo-howto.xml#doc_chap2 > > The relevant part ("Naming ebuild Files ") says that the PV (version) part of > ebuild name should contain set of dot-separated numbers with optional > (single) letter right after the last number. For example 1.2.3a. There can be > no numbers following the letter. It is possible to append a suffix, one of > _alpha, _beta, _pre or _rc, however any suffix denotes (diferent stage of) > pre-release version. Thus after having erlang R9b with ebuild named -9b with > the r9b-1 version I did not have much room in selecting the valid PV > construct, so that new version would indeed denote another version and would > be recognized by portage as newer. I settled for 9c as an easy fix in the > hope that, as it was with 8b, new version will have increased numeric number. > > The alternative might be to use the revisions by appending -rX to the ebuild > name. However this is really undesirable because: > 1. -rX are supposed to mark updates to the ebuilds corresponding to the same > version of package. > 2. this will very easily go out of sync should I need to do any updates to > ebuild taht would require a revision bump. > Thus this does not resolve the situation in any way either. > > If you can come up with some naming scheme that would resolve this situation I > would greatly appreciate your help. It would be best to avoid the out-of-sync > versioning issue and keep the posibility of "automated" updates by just > renaming the ebuild, however this part is from the "desirable" category and > is optional :). > > George > > > On Thursday 22 May 2003 20:27, you wrote: > > Hi George, > > > > Thanks for maintaining the gentoo erlang entry. Can I make a suggestion > > that the erlang version numbers should more closely reflect the current > > erlang? > > > > The Erlang version numbers are little odd, but you've just defined > > version "9c", which maps to R9B-1. There will be a real R9C (R9C-0) out > > soon with a bunch of new stuff. > > > > Its not a big thing, but I did have to manually inspect the package file > > to see which version it was really installing. > > > > Thanks, > > Bruce > > > From eleberg@REDACTED Tue May 27 08:14:40 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Tue, 27 May 2003 08:14:40 +0200 (MEST) Subject: ring of processes Message-ID: <200305270614.h4R6Eeq04542@cbe.ericsson.se> greetings, thanks to Ulf Wiger and Roger Peppe, who supplied the programs in erlang and limbo respectivly, i have had the opportunity to run the ''ring of processes'' test/benchmark (as described in the ''Concurrency Oriented programming in Erlang'' talk by Joe Amstrong). i used the same, lightly loaded, machine for both tests: SunOS cbe2131 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-5_10 with 256 Mb ram. the test started with 1000 processes in the ring. since i knew that they would not reach 200000 processes without thrashing i had 200000 as the maximum number of processes. the number of processes increased with 20000 for each step. erlang ''crashed'' when the spawning of a processes took more than 60 usec (this value is a timeout in the test code). inferno crashed when there was no more memory left (i had given a limit of 200 Mb at startup. i did not want to continue testing once ram was exhausted). these where the results for: Erlang (THREADS,HIPE) (BEAM) emulator version 5.2.3.1 erl -noshell +P200000 -s ring main ring 1000 200000 20000 1000 24.2000 3.15600 21000 27.8362 4.43110 41000 24.4463 4.54617 61000 23.2400 4.43508 81000 22.6473 4.44777 101000 22.5306 4.41780 121000 22.0450 4.41909 141000 21.8246 4.45016 161000 29.2502 57.8320 {"init terminating in do_boot",{function_clause,[{ring,format,[standard_io,{181000,timeout}]},{lists,f oreach,2},{ring,ramp,4},{ring,main,1},{init,start_it,1},{init,start_em,1}]}} these where the result for: Inferno Third Edition (20020715) main (pid=910) interp inferno -pmain=200000000 /usr/eleberg/src/ring.dis 1000 200000 20000 1000 28 3 21000 27.1429 3.71429 41000 26.3415 3.82927 61000 20.3279 3.7377 81000 18.7407 3.7284 101000 18.5545 3.76238 121000 17.7934 3.72727 141000 29.305 89.2199 arena main too large: size 1088 cursize 199994592 arenasize 200000000 maxsize 200000000 [Ring] Broken: "no memory" From kostis@REDACTED Tue May 27 12:23:28 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 27 May 2003 12:23:28 +0200 (MEST) Subject: HIPE'd stdlib modules rule !!! Message-ID: <200305271023.h4RANS8F002557@harpo.it.uu.se> Chris Pressey wrote: > > Well, here's my experience - > I recompiled kernel (except erl_epmd and hipe_x86_loader, which I > couldn't get compiled for lack of proper header files) and stdlib > (erl_parse took nearly 2 hours!) with +native. Two comments here: 1. The way the Erlang/OTP Makefiles work, the only safe way to make a library of the system is to touch the corresponding files and then issue a "make" command at the top-level. This will generate the appropriate header files (hipe_literals.hrl in this case). 2. The compilation time problem you are mentioning has already been solved in the upcoming Erlang/OTP release (the fix is hard-coded). To avoid the 2 hour compilation time (and bring the time down to the 2 minute range), try the following: erlc +native +'{hipe,[{regalloc,linear_scan}]}' erl_parse.erl > [...] > > Clearly, not what I expected. Looking at the pibfi code, it may be > that, even though it 'looks' sequential, it just relies on message > passing too much (between the interpreter and the store, etc.) > > On the other hand - everything still worked; the output was correct. Without knowing more about your application, it is very difficult to say something intelligent here. Can it be that your application is also heavily using other parts of OTP 9e.g. ets, ...) that you have not compiled to native and you get penalized by mode switches? Is this using R9B, and on which platform? > Anyway, my feeling is that judicious use of +native is probably a > better way to go than just compiling everything with HiPE ("+naive"? :) Judicious use beats naive use of everything hands down, so I could not agree more with the above. However, my experience is that it is very easy to have the illusion that "everything" was compiled to native code. Cheers, Kostis. From yvan.godin@REDACTED Tue May 27 13:09:09 2003 From: yvan.godin@REDACTED (yvan.godin@REDACTED) Date: Tue, 27 May 2003 13:09:09 +0200 (CEST) Subject: Oracle and ODBC erlang driver Message-ID: <1054033749.3ed34755e6932@imp.free.fr> Hello I would like to have a try with Erlang and Oracle but I have some problems with ODBC ORACLE acces on W2K (and same in NT4) when I try to connect my database withing erl (werl) {ok,Ref} = odbc:connect("UID=;PWD=;DBQ=;DSN=",[{driver_trace,on}]). ** exited: {{badmatch,{error,connection_closed}},[{erl_eval,expr,3}]} ** =ERROR REPORT==== 27-May-2003::11:44:05 === ** Generic server <0.112.0> terminating ** Last message in was {'EXIT',#Port<0.72>,normal} ** When Server state == {state,#Port<0.72>, {<0.110.0>,#Ref<0.0.0.526>}, <0.110.0>, undefined, on, undefined, undefined, on, connecting, undefined, 0, false, false, []} LOG FILE *********************************************************************** Fatal NI connect error 12560, connecting to: (DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oracleORCL)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDR ESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=ORCL)(CID=(PROGRAM=c:\PROGRA~1\ERL523~1.3\lib\odbc-1.0.5\priv\bin \odbcserver.exe)(HOST=)(USER=)))) VERSION INFORMATION: TNS for 32-bit Windows: Version 8.1.7.0.0 - Production Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 8.1.7.0.0 - Production Time: 27-MAI-2003 11:27:36 Tracing not turned on. Tns error struct: nr err code: 0 ns main err code: 12560 TNS-12560: TNS : erreur d'adaptateur de protocole ns secondary err code: 0 nt main err code: 530 TNS-00530: Erreur d'adaptateur de protocole nt secondary err code: 126 nt OS err code: 0 on the log file the SID ORCL do not correspond to my TNS SID ... is that a normal way ?? NB:some string have been replaced by :the ODBC connection work fine with VisualBasic or Oracle ODBC Test :release Erlang R9B-1 Thank's for any idea or help Yvan From kent@REDACTED Tue May 27 14:56:23 2003 From: kent@REDACTED (Kent Boortz) Date: 27 May 2003 14:56:23 +0200 Subject: erl_interface and lists In-Reply-To: <3ED2DB70.7040004@hq.idt.net> References: <3ED2DB70.7040004@hq.idt.net> Message-ID: Serge Aleynikov writes: > Could someone shed some light on how to decode lists' elements (other > than head and tail) in erl_interface. The examples included in the > docs are pretty clear on how to decode tuples and atoms, but I can't > seem to find any reference for functions dealing with retrieval of an > N'th element of a list. > > Suppose the Erlang side of the interface is passing a tuple to a C port: > {init, [a, b, c]} > > ETERM *tuple = erl_decode(buf); > ETERM *atom = erl_element(1, tuple); > ETERM *list = erl_element(2, tuple); > > Then what I'd like to do is to iterate over each element of the list: > > for (int i=0; i < erl_length(list); i++) { > do_smthng_with_item(ERL_NTH_ELEMENT(i, list)); > } > > So, how can I implement ERL_NTH_ELEMENT()? In the erl_interface API lists are stored as cons cells (same as in the emulator). This means that a list [a, b, c] is the same as [a | [b | [c | []] I haven't tested this code ETERM *list = erl_decode(buf); ETERM *element; while (list && (element = erl_hd(list))) { /* do something with element */ list = erl_tl(list); } Note that this will increment the reference counter on the list elements and the list cons cells. If you don't want to alter the counters you can use the macros ERL_CONS_HEAD(list) and ERL_CONS_TAIL(list), kent From r.raschke@REDACTED Tue May 27 14:45:56 2003 From: r.raschke@REDACTED (r.raschke@REDACTED) Date: Tue, 27 May 2003 13:45:56 +0100 Subject: erl_interface and lists In-Reply-To: <3ED2DB70.7040004@hq.idt.net> Message-ID: <1637d3eb7e3d11c8eb1cf34e5be5532d@tombob.com> Hi, I have written erl_interface code along the lines of this before: if (ERL_IS_LIST(foo)) { for (list = foo; ! ERL_IS_EMPTY_LIST(list); list = ERL_CONS_TAIL(list)) { item = ERL_CONS_HEAD(list); /* whatever */ } } As far as I know you don't iterate like you would with an array, there being no index into the list. Either you loop destructively like the above or you can write a recursive solution, as you would have to were you programming in Erlang itself. Hope this helps, Robby -------------- next part -------------- An embedded message was scrubbed... From: Serge Aleynikov Subject: erl_interface and lists Date: Mon, 26 May 2003 23:28:48 -0400 Size: 3766 URL: From hrvoje.nezic@REDACTED Tue May 27 15:29:18 2003 From: hrvoje.nezic@REDACTED (Hrvoje Nezic) Date: Tue, 27 May 2003 15:29:18 +0200 Subject: Eppur si sugat References: Message-ID: <021d01c32453$fd8a2340$1301a8c0@envox.local.hr> > It's not about OO software construction. It's more > > "generally good design principles" + how to code things in Eiffel. This is simply not true. OOSC2 is not a book about Eiffel. Meyer's book is about software construction, from his own point of view, of course. Most books about programming languages just describe syntax and semantics of a given language. Meyer's book is very different and almost unique: he discusses various possibilities, dillemas, why some features had to be rejected, etc. And this is a fine book, and Eiffel is a very fine language ("arguably the best object-oriented language"). Of course, if O-O is considered bad by definition, this means nothing. For me, O-O (especially in elegant and well-designed languages, like Eiffel) means big progress from C and alike, freedom from having allocating memory by hand, dealing with pointers etc, etc. In this way Eiffel is light years ahead of C. I am open minded, I love to learn new things and explore new possibilities. That is why I am on this list. I like at least some aspects of Erlang (especially processes). However, stating that some other paradigms, like O-O, are completely wrong, is too much in my opinion. > The fact the "OO" word is on the cover and the word "eiffel" is > absent from the cover notes is probably to sell more titles. This is not a fair statement and not a right way to criticize "ideological enemy", like Meyer. Meyer's book is about object oriented programming. He obviously had to include some program examples in the book. What were his options? To use pseudo-code? To use C++? Simula? Smalltalk? Java (nonexisting when he wrote the first edition)? Eiffel was invented because there were no other suitable O-O language. So, he obviously used Eiffel, not only because he invented it, but because it is in many ways superior to alternatives. By the way, OOSC-2 is not the only Meyer's book. His book about Eiffel is called "Eiffel the Language". If OOSC-2 was book about Eiffel, why he wrote ETL? Of course, you can say that he wrote it to make more money, but again, I think this would not correspond to facts. Regards, Hrvoje Nezic From hal@REDACTED Tue May 27 15:33:21 2003 From: hal@REDACTED (Hal Snyder) Date: Tue, 27 May 2003 08:33:21 -0500 Subject: Oracle and ODBC erlang driver In-Reply-To: <1054033749.3ed34755e6932@imp.free.fr> (yvan.godin@free.fr's message of "Tue, 27 May 2003 13:09:09 +0200 (CEST)") References: <1054033749.3ed34755e6932@imp.free.fr> Message-ID: <878yss5xb2.fsf@ghidra.vail> yvan.godin@REDACTED writes: > I would like to have a try with Erlang and Oracle > > but I have some problems with ODBC ORACLE acces on W2K (and same in NT4) > when I try to connect my database withing erl (werl) It's been awhile since I looked at it, but we've been running an app for a couple years with Oracle and Erlang (R7B-3) ODBC on Slackware. We use odbc:sql_connect as per the "basic.erl" example. [Maybe it's me, but ODBC always gives me fits when configuring a new setup. I don't think it's technically deep - just too many proprietary shims and the right documentation doesn't seem to be anywhere. I would rather spend a day with sendmail.cf...] From joe@REDACTED Tue May 27 17:41:02 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 27 May 2003 17:41:02 +0200 (CEST) Subject: Eppur si sugat In-Reply-To: <021d01c32453$fd8a2340$1301a8c0@envox.local.hr> Message-ID: On Tue, 27 May 2003, Hrvoje Nezic wrote: > > It's not about OO software construction. It's more > > > > "generally good design principles" + how to code things in Eiffel. > > This is simply not true. OOSC2 is not a book about Eiffel. > Meyer's book is about software construction, from his > own point of view, of course. What??? I was referring to "Object Oriented Software construction" by Meyer (the first edition published in 1988) - I don't have the second version so I can't comment in it. The book is about Software construction in Eiffel - That's what the "+" means. How can a book with hundreds of examples in Eiffel not be about Eiffel. It's not *exclusively* about Eiffel, since this is a lot of stuff of software design - but it certainly IS about Eiffel AND software design. It is certainly not about general software design since many of the mechanisms described in the book do not apply to other languages - they are specific to Eiffel and similar languages It seems to me to be very much a book about Eiffel - The first chapter in part II is called "Basic Elements of Eiffel programming" - thereafter follow loads of small code fragments all in Eiffel as far as I can see. Appendix C is the Eiffel grammar - and a quick check reveals that all the code fragments appear to be written in Eiffel. As I pointed out part I is mostly general common sense and is not exclusively owned by any school of programming, ADTs and information hiding are general techniques applicable to any style of programming. > > Most books about programming languages just describe > syntax and semantics of a given language. Meyer's book > is very different and almost unique: he discusses various > possibilities, dilemmas, why some features had to be rejected, > etc. "almost unique" - I doubt it - there are *many* good books that discuss language-design tradeoffs - how about "Abelson and Sussman's - structure and interpretation of computer programs", Wirth and Gutknecht's Oberon book, Brinch Hanssen's operating system principles, Allen's anatomy of lisp ... Meyer's book is certainly good but not unique. > > And this is a fine book, and Eiffel is a very fine language > ("arguably the best object-oriented language"). > Of course, if O-O is considered bad by definition, > this means nothing. > Yes Eiffel is one of the better OO languages - O-O is *not* bad by definition. Particular OO language are bad, for particular reasons, Java is bad because the concurrency model is screwed up, C++ because you can easily confuse or break the type system, .. I have even designed an OO language (OIL = Object Inspired Language) - << son of Erlang :-) >> - and I can image a good OO language, but I just havn't seen one yet (apart from OIL, that is :-) > For me, O-O (especially in elegant and well-designed > languages, like Eiffel) means big progress from C and alike, > freedom from having allocating memory by hand, > dealing with pointers etc, etc. > In this way Eiffel is light years ahead of C. > So is LISP - we had GC etc in 1959 in lisp 1.5 - freedom from pointers etc. has nothing to do with OO. Many languages (logic, functional, OO, imperative, have freedom from pointers - even visual basic :-) > I am open minded, I love to learn new things and explore > new possibilities. That is why I am on this list. > I like at least some aspects of Erlang (especially > processes). > > However, stating that some other paradigms, > like O-O, are completely wrong, is too much > in my opinion. I have never said O-O is completely wrong (I said it "sucks") - and if you choose a title like "Why OO sucks" more people will read your article than if you say "a few things I don't like about OOPLs" > > > The fact the "OO" word is on the cover and the word "eiffel" is > > absent from the cover notes is probably to sell more titles. > > This is not a fair statement and not a right way to criticize "ideological > enemy", This statement was not intended as a criticism - and he's not an enemy. Meyer said a lot of sensible things in his book. If you write a book about a relatively obscure language it might be a good idea not to mention it on the cover - you might sell more that way - that's a fact of life. > like Meyer. Meyer's book is about object oriented > programming. He obviously had to include some program examples > in the book. What were his options? To use pseudo-code? > To use C++? Simula? Smalltalk? Java (nonexisting when > he wrote the first edition)? Eiffel was invented because there > were no other suitable O-O language. So, he obviously used > Eiffel, not only because he invented it, but because it is > in many ways superior to alternatives. > By the way, OOSC-2 is not the only Meyer's book. > His book about Eiffel is called "Eiffel the Language". > If OOSC-2 was book about Eiffel, why he wrote ETL? > Of course, you can say that he wrote it to make more > money, but again, I think this would not correspond to > facts. I assume he wrote it to promote eiffel. The fact that he wrote a book called "Eiffel the language" is irrelevant to any discussion of OOSC. > > Regards, > Hrvoje Nezic > > /Joe From thomasl_erlang@REDACTED Tue May 27 16:39:33 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 27 May 2003 07:39:33 -0700 (PDT) Subject: HIPE'd stdlib modules rule !!! In-Reply-To: <200305271023.h4RANS8F002557@harpo.it.uu.se> Message-ID: <20030527143933.24559.qmail@web41901.mail.yahoo.com> --- Kostis Sagonas wrote: > > Clearly, not what I expected. Looking at the > pibfi code, it may be > > that, even though it 'looks' sequential, it just > relies on message > > passing too much (between the interpreter and the > store, etc.) > > > > On the other hand - everything still worked; the > output was correct. > > Without knowing more about your application, it is > very difficult to > say something intelligent here. Can it be that your > application is > also heavily using other parts of OTP 9e.g. ets, > ...) that you have > not compiled to native and you get penalized by mode > switches? Some more thoughts on this. First, if the program spends its time doing ets operations, message passing and other stuff already done in C, then native code compiling the Erlang parts clearly won't help much. Amdahl's law ensures that. Furthermore, it is possible that things could even get worse from doing so. Consider when the extra native code also produces extra cache misses (that are not tolerated). This is a classic problem, and when it occurs a bytecoded VM might be quite competitive. We experienced precisely that with an older version of Beam vs an ancient version of Hipe used on AXD301, running on an UltraSparc. The current Hipe appears to have evolved quite a bit since then, as has Beam -- not to mention that the underlying platform may be quite different. So I won't say this is the problem. (Being "BIF bound" might be a likelier culprit, from what it sounds like.) But if you have a big program that doesn't behave, I think it's definitely a factor to consider. (Those interested in "the AXD301 experience" can consult ) Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From thomasl_erlang@REDACTED Tue May 27 16:51:38 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 27 May 2003 07:51:38 -0700 (PDT) Subject: Learning by reading code In-Reply-To: Message-ID: <20030527145138.29857.qmail@web41901.mail.yahoo.com> --- WILLIAMS Dominic wrote: > Hello, > > I am trying to learn Erlang, and like to read code > written by experienced Erlangers. > I came across the following things (in xmerl) for > which I could find no explanation in the > documentation: > > -compile(export_all). > > What does this mean? Does it automatically export > all functions contained in the file? Yes. I think a more modern approach (at least when you use makefiles) is to do erlc +export_all module.erl and leave the -compile(...) attribute out. (Because you can change the mass of options once in the makefile instead of going through each module.) (or in the top loop, use the clumsier 1> c(module, [export_all]). ) Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From thomasl_erlang@REDACTED Tue May 27 17:00:26 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 27 May 2003 08:00:26 -0700 (PDT) Subject: Eppur si sugat In-Reply-To: Message-ID: <20030527150026.33844.qmail@web41901.mail.yahoo.com> --- Joe Armstrong wrote: > > > Eppur si sugat (was that right?) > > Hi Chris, > > Now I shall have to write a rebuttal to your > rebuttal - this is > "pens at dawn" stuff ... > > One of the problems about attacking OO > programming is that nobody > can actually agree on what it is. Eppur si sugat indeed (I can't correct the syntax but at least I get the sentiment :-) I think one of the things OO did right was selling the technology to _management_. Sometimes quite shamelessly so. Maybe Erlang (or COPLs) should too. My encounter with Java the language left me unimpressed. What _is_ impressive is the community and the tools used. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From erlang@REDACTED Tue May 27 13:54:42 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Tue, 27 May 2003 13:54:42 +0200 Subject: Port Message-ID: <002901c32446$c30a7920$1e00a8c0@design> I'm using an Erlang port implemented in C/C++ (Win32). and I'm having some trouble with file descriptor 0 and 1 opened by Erlang to manage the C/C++ port. The C/C++ code uses libraries which throws output to stdin/stdout. Can I change the file descriptor number, {fs, In, Out} port setting in Erlang ? What other choices do I have ? Thanks in advance Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.karlsson@REDACTED Tue May 27 19:33:35 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Tue, 27 May 2003 19:33:35 +0200 Subject: Web applications unification In-Reply-To: References: Message-ID: <200305271933.35658.mikael.karlsson@creado.com> tisdag 27 maj 2003 13:36 skrev Ulf Wiger: > On Tue, 27 May 2003, Mikael Karlsson wrote: > >So why not set some kind of standard interface or framework > >to build it on? > > > >Like: > >- http server: Yaws > >- http client: inets (originally jnets) http.erl > >- ODBC, Corba etc: Erlang/OTP > >- application control/configuration: Erlang/OTP > >- authentication: eldap ? > >- XML: xmerl > >- XML-RPC: xmlrpc (with interface to yaws and inets/http client) > >- SOAP: idx-soap (with interface to yaws and inets/http client) > > > >I think most things are (almost) in place to build a > >*really good* web application framework with Erlang. > > I agree. I also added 'builder' to jungerl as an attempt to > provide a lightweight aide for packaging OTP applications > and building start scripts. I don't know how well it > succeeded (and it does need more work). > > The general idea was that you should be able to > incrementally build more and more complex systems with > relative ease. > > /Uffe Yes, hmm this means that one should use generic behaviours like gen_server etc. in such a framework? I noticed that xmlrpc uses generic behaviours in the latest version (1.13), but I can not find any "-behaviour(gen_server)" statement in the code. How is that? For SOAP there is also ErlSOAP 0.2, which seems to make use of inets http client: http://www.erlang-projects.org/Public/projects/services/erlsoap_0.2/view Wouldn't the Erlang projects site be good forum for setting an application server framework/interface ? /Mikael From tobbe@REDACTED Tue May 27 20:40:35 2003 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Tue, 27 May 2003 20:40:35 +0200 Subject: Port In-Reply-To: <002901c32446$c30a7920$1e00a8c0@design> References: <002901c32446$c30a7920$1e00a8c0@design> Message-ID: <3ED3B123.7060601@bluetail.com> There used to exist a 'no_use_stdio' option to open_port/2. It used fd 3 & 4 instead of 0 & 1. Cheers , Tobbe Inswitch Solutions - Erlang Evaluation wrote: > > > I'm using an Erlang port implemented in C/C++ (Win32). > and I'm having some trouble with file descriptor 0 and 1 opened by > Erlang to manage the C/C++ port. > The C/C++ code uses libraries which throws output to stdin/stdout. > > Can I change the file descriptor number, {fs, In, Out} port setting in > Erlang ? > What other choices do I have ? > > > Thanks in advance > Eduardo Figoli > INSwitch Solutions > From garry@REDACTED Tue May 27 21:52:12 2003 From: garry@REDACTED (Garry Hodgson) Date: Tue, 27 May 2003 15:52:12 -0400 (EDT) Subject: (OT) rebuttal against "Why OO Sucks" In-Reply-To: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> Message-ID: <2003052715521054065171@kestrel.sage.att.com> Chris Pressey wrote: > I'm not 100% happy with it, but if I keep editing it until I'm 100% > happy it'll never be done. So, here is a rebuttal to Joe's essay: > > http://www.catseye.mb.ca/articles/oodspd.html > > And for more fair time, here is another essay critical of OO that I > stumbled upon: > > http://home.planet.nl/~faase009/AoP_OOCH.html and yet another, pro and con, at http://www.dreamsongs.com/Essays.html#ObjectsHaveFailed ---- Garry Hodgson, Senior Hacker, AT&T Labs No act is more patriotic than speaking out when your government is doing the wrong thing in your name. This is not your right but your sacred duty. And none are more treasonous than those who would silence these voices. From eduardo@REDACTED Tue May 27 13:54:18 2003 From: eduardo@REDACTED (Eduardo Figoli) Date: Tue, 27 May 2003 13:54:18 +0200 Subject: Port Message-ID: <001b01c32446$b5591250$1e00a8c0@design> I'm using an Erlang port implemented in C/C++ (Win32). and I'm having some trouble with file descriptor 0 and 1 opened by Erlang to manage the C/C++ port. The C/C++ code uses libraries which throws output to stdin/stdout. Can I change the file descriptor number, {fs, In, Out} port setting in Erlang ? What other choices do I have ? Thanks in advance Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocke@REDACTED Tue May 27 23:15:07 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 27 May 2003 23:15:07 +0200 Subject: Web applications unification In-Reply-To: <200305271933.35658.mikael.karlsson@creado.com> References: <200305271933.35658.mikael.karlsson@creado.com> Message-ID: <3ED3D55B.2010901@bluetail.com> Mikael Karlsson wrote: >tisdag 27 maj 2003 13:36 skrev Ulf Wiger: > >>On Tue, 27 May 2003, Mikael Karlsson wrote: >> >>>So why not set some kind of standard interface or framework >>>to build it on? >>> >>>Like: >>>- http server: Yaws >>>- http client: inets (originally jnets) http.erl >>>- ODBC, Corba etc: Erlang/OTP >>>- application control/configuration: Erlang/OTP >>>- authentication: eldap ? >>>- XML: xmerl >>>- XML-RPC: xmlrpc (with interface to yaws and inets/http client) >>>- SOAP: idx-soap (with interface to yaws and inets/http client) >>> >>>I think most things are (almost) in place to build a >>>*really good* web application framework with Erlang. >>> >>I agree. I also added 'builder' to jungerl as an attempt to >>provide a lightweight aide for packaging OTP applications >>and building start scripts. I don't know how well it >>succeeded (and it does need more work). >> >>The general idea was that you should be able to >>incrementally build more and more complex systems with >>relative ease. >> >>/Uffe >> > >Yes, hmm this means that one should use generic behaviours like >gen_server etc. in such a framework? > >I noticed that xmlrpc uses generic behaviours in the latest version (1.13), >but I can not find any "-behaviour(gen_server)" statement in the code. >How is that? > The server part of the xmlrpc lib _behaves_ as a gen_server it isn't written using a gen_server behaviour though. Like this: http://www.erlang.org/doc/r9b/doc/design_principles/spec_proc.html as in: http://www.gleipnir.com/xmlrpc/unpacked/LATEST/src/tcp_serv.erl /Jocke From cpressey@REDACTED Tue May 27 23:28:52 2003 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 27 May 2003 16:28:52 -0500 Subject: Eppur si sugat In-Reply-To: References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> Message-ID: <20030527162852.1245c1b1.cpressey@catseye.mb.ca> On Tue, 27 May 2003 10:40:00 +0200 (CEST) Joe Armstrong wrote: > Eppur si sugat (was that right?) (Not sure - Google just gave me a blank look when I tried it...) > Hi Chris, 'lo Joe, > Now I shall have to write a rebuttal to your rebuttal - this is > "pens at dawn" stuff ... > > One of the problems about attacking OO programming is that nobody > can actually agree on what it is. Well, that's a problem. I don't think the merits of any given thing can be productively debated until the participants can mostly agree on what they're debating. FWIW, I see OO as (I'll do my best to summarize) - a design philosophy rather than a style of coding - splits function and state up into units which may represent both - emphasizing mutual respect across discrete units (encapsulation) - also emphasizing similarity and interoperability between those units (inheritance and polymorphism) If that doesn't strike you as an acceptable premise, there's not much point. I just want to make it clear that I'm just looking for fair time - showing the other side of the argument - rather than showing that one side is "wrong". I think most differences between my premise and those of people who, say, have written books on the subject, is that their premises are more formal and more detailed (often MUCH more detailed) - otherwise I think we *basically* agree. And to me, it doesn't matter that these things aren't the exclusive domain of OO - recursion isn't the exclusive domain of lambda calculus either AFAICT... > When we were researching the Erlang book Robert V. and I went into > the library and borrowed *every* book there was that had anything to > say about OO programming - most of theses books gave some loose > definitions as to what they thought OOP was - unfortunately there was > little agreement as to what the core ideas in OOP were. > > << This is not quite true - they did agree over one point - they all > agreed that OOP was great - wonderful - amazingly spiffy etc >> Yeah, that's the "glamour" thing, as I'm sure you're well aware. > I strongly disagree with the "Everything is an object" school of > thinking - I know some people like this but it's not for me. I have my own reservations about "Everything is X" because, well, "Everything is Everything" (Lauren Hill :) > Take a <<> thing like an integer. Integers > can be defined by simple recursion equations, thus: > > If X is an integer then X ++ "1" is an integer (recursive case) > "0" is an integer (base case) > [...] > Piano would no doubt have been greatly surprised if he was reading > "Java in a Nutshell" - he'd look up integer in the index and find > himself reading ... > > public final call Integer extends Number implements Comparable { > // Public Constructors > public Integer(String s) throws NumberFormatException; > ... > > At which point he would no doubt burst into tears and start banging > his head against the wall ... Whereas Bertrand Russell might grin. ("Integer specializes rational" might even make him smile.) But neither Russell nor Peano is "wrong" (and I don't think either of us is qualified to speak for the emotional reactions of dead mathematicians anyway) so the question might be better put as: which way of defining an integer is more productive for the average systems designer? > [...] > It seems to me much nicer to keep data structure definitions apart > from the set of functions that operate upon them. Data structure > definitions are finite and declarative. The set of functions which > operate on them is infinite and (often) imperative. > > We can *easily* define a string as a sequence of integers - > IMHO that's what a string *is*. I would say it's an ordered set of symbols, but those two views aren't too different, so, OK. > In Erlang: > > +type string() = [int()]. > > I looked up string in the JIAN and to my surprise *nowhere* did it > say what a string was. And this is OO's fault? :) It's probably not even Java's fault. There's only so much you can pack into a nutshell. If you really need an OO model of a string, I can supply you with one (in any of a number of OOPLs or modelling notations or natural languages,) for instance: +--------+ +--------+ | String |<>------*| Symbol | +--------+ (ord.)+--------+ > Instead it gave a long list of methods that > could be used to turn strings into other things (and I'm guessing > here, I'd bet that nowhere could I find definitions of what the other > things are :-). Let's go back to Peano, then: --> If X is an integer then X ++ "1" is an integer (recursive case) --> "0" is an integer (base case) This doesn't tell me what an integer "is", either. It gives me one example ("0") and a method for turning integers into other integers. > In English we have "dictionaries" and "books" - Books are full of > paragraphs and sentences, sentences are made of words. > > *If we want to know what a word means we look it up in the > dictionary* (Which, I feel I should note, defines words in terms of other words) > Fortunately dictionaries are not OO - if they were I guess the > dictionary would not only have a definition of the word, but also > have to included all possible citations of the word. Sorry - insofar as I follow you, I don't agree. Even an "OO dictionary" wouldn't have to list every possible citation of the word, merely every possible *form* of citation of a word. And dictionaries *do* do this, by giving the word's class (noun, verb, &c) and further with "notes on usage" - *examples* of citations from which the reader infers the set of possible citations. > So when we looked up string, we would find not > > A string is a sequence of integers > > But rather > > A string is a ... > The word string occurs in the following books ... > ... list of 10 Million books ... Or perhaps A string is some X such that operation 1 can be done to it to yield blah and operation 2 can be done to it to yield foo and operation 3 can be done to it to yield bar and ... operation n can be done to it to yield !&%*@ and "" is a valid string Which is not at all different in form from Peano's axiom. Also, please remeber JIAN is a "nutshell" work - so of course it's going to concentrate on indexes and glossaries (which are hard for a Java programmer to remember) instead of definitions (which, for brevity, it can assume they have already learned and don't need reminding of.) So I don't think the comparison to a dictionary is an entirely fair one. > I rest my case (for now) > > I'll be back I'll be waiting :) > /Joe -Chris From cpressey@REDACTED Wed May 28 00:32:13 2003 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 27 May 2003 17:32:13 -0500 Subject: HIPE'd stdlib modules rule !!! In-Reply-To: <200305271023.h4RANS8F002557@harpo.it.uu.se> References: <200305271023.h4RANS8F002557@harpo.it.uu.se> Message-ID: <20030527173213.2ef9a169.cpressey@catseye.mb.ca> On Tue, 27 May 2003 12:23:28 +0200 (MEST) Kostis Sagonas wrote: > 1. The way the Erlang/OTP Makefiles work, the only safe way to make > a library of the system is to touch the corresponding files and > then issue a "make" command at the top-level. This will generate > the appropriate header files (hipe_literals.hrl in this case). Ah, thanks. I would then have to re-'make install'? I've grown so used to 'erlc -o ebin src/*.erl' that it didn't occur to me that the base system might need more delicate handling. > [...] > Without knowing more about your application, it is very difficult to > say something intelligent here. Can it be that your application is > also heavily using other parts of OTP 9e.g. ets, ...) ets, yes, but ets.beam was recompiled +native as part of stdlib. > that you have > not compiled to native and you get penalized by mode switches? Only http that I can think of, and that's only used once at startup. > Is this using R9B, and on which platform? R9B-1, on FreeBSD 4.8-STABLE (Apr 21 2003) > > Anyway, my feeling is that judicious use of +native is probably a > > better way to go than just compiling everything with HiPE > > ("+naive"? :) > > Judicious use beats naive use of everything hands down, so I could not > agree more with the above. However, my experience is that it is very > easy to have the illusion that "everything" was compiled to native > code. Perhaps I should bang together a script to :module_info all the modules it can find and say which ones aren't +native? Erik Stenman mentioned that one reason could be the extensive use of dynamic dispatching in the storage behaviour (calls in the form Module:function(...)) I also suspect its performance just depends too heavily on message passing. When I get some spare time I'll rewrite it to eliminate the dynamic dispatching and turn the primary message passing-reliant thing into function calls. I'm sure I'll get better performance then. Meanwhile - with 'all' (most) of kernel+stdlib HiPE'd, common things like using the shell, compiling, etc, do seem a little more sluggish than normal, so it's not just this app... > Cheers, > Kostis. -Chris From ulf.wiger@REDACTED Wed May 28 01:08:26 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Wed, 28 May 2003 01:08:26 +0200 Subject: Web applications unification References: <200305271933.35658.mikael.karlsson@creado.com> Message-ID: <007601c324a4$e11e4640$fd7a40d5@telia.com> On Tue, 27 May 2003, Mikael Karlsson wrote: > tisdag 27 maj 2003 13:36 skrev Ulf Wiger: > > > > I agree. I also added 'builder' to jungerl as an attempt to > > provide a lightweight aide for packaging OTP applications > > and building start scripts. I don't know how well it > > succeeded (and it does need more work). > > > > The general idea was that you should be able to > > incrementally build more and more complex systems with > > relative ease. > > Yes, hmm this means that one should use generic behaviours like > gen_server etc. in such a framework? If you want to use gen_servers, you could of course, but that has nothing to do with builder. The builder utility is intended to simplify the task of building .app files, .rel files, and finally .script and .boot files in order to start a system. When building a framework of different Open Source contributions, I think it helps to agree on a way to start the appl?cations. OTP provides such a way. What you want to do in the start function in order to get your processes running is another matter. I believe that the gen_server behaviour is quite useful, and I use it myself as much as I can, but it's not really something that affects your APIs, so it's normally an internal implementation detail. /Uffe From serge@REDACTED Wed May 28 02:02:44 2003 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 27 May 2003 20:02:44 -0400 Subject: erl_interface Message-ID: <3ED3FCA4.7050601@hq.idt.net> I wonder if someone could share erl_interface-based examples with me. I've been trying to write some code that passes either a tuple/list, or an integer from C to Erlang, and I am having a problem that in case of integers (see iterate() and finalize() below) Erlangs gets a response correctly, but in case of tuple/list (see initialize()), looks like Erlang is waiting for something in addition to what the port replies. I can see in debugger that the Port sends everything normally, and then blocks on the read() function as expected. Serge --------------- C CODE ----------------- #include #include #include #define OPT_INITIALIZE 1 #define OPT_ITERATE 2 #define OPT_FINALIZE 3 typedef unsigned char byte; int read_cmd(byte *buf); int write_cmd(byte *buf, int len); int read_exact(byte *buf, int len); int write_exact(byte *buf, int len); //----------------------------------------------------------------- // Interface routines //----------------------------------------------------------------- int initialize(int nGatewayID, ETERM *demand, ETERM *supply, ETERM *rates) { int nDemandLen = erl_length(demand); int nSupplyLen = erl_length(supply); int nRatesLen = erl_length(rates); ETERM *list, *tuple, *arg1, *arg2; if (ERL_IS_LIST(demand)) { for (list = demand; ! ERL_IS_EMPTY_LIST(list); list=ERL_CONS_TAIL(list)) { tuple = ERL_CONS_HEAD(list); // Fetch a record from the list arg1 = erl_element(1, tuple); arg2 = erl_element(2, tuple); // Check ERL_TUPLE_SIZE(tuple) == 2 fprintf(stderr, "Gateway: %3d, Demand: %4d = %d\n", nGatewayID, ERL_INT_VALUE(arg1), ERL_INT_VALUE(arg2)); erl_free_term(arg1); erl_free_term(arg2); } } return nDemandLen; } int iterate(int y) { return y*2; } int finalize(int z) { return z*3; } int main(int argc, char *argv[]) { ETERM *tuple, *result; ETERM *fun, *arg1, *arg2, *arg3, *arg4; ETERM *array[10]; int res, n; byte buf[1024]; long allocated, freed; erl_init(NULL, 0); // Initialize Erlang interface library while (read_cmd(buf) > 0) { // The parameters are coming encoded as a tuple tuple = erl_decode(buf); // Get the first element in the tuple. fun = erl_element(1, tuple); switch (ERL_INT_VALUE(fun)) { case OPT_INITIALIZE: if (ERL_TUPLE_SIZE(tuple) != 5) { result = erl_format("{error, {demand, tuple_size, ~i}}", ERL_TUPLE_SIZE(tuple)); // Note: The function above doesn't return. } else { // {init, GtwyID, Demand, Supply, Rates} arg1 = erl_element(2, tuple); arg2 = erl_element(3, tuple); arg3 = erl_element(4, tuple); arg4 = erl_element(5, tuple); res = initialize(ERL_INT_VALUE(arg1), // GtwyID arg2, arg3, arg4); erl_free_term(arg1); erl_free_term(arg2); erl_free_term(arg3); erl_free_term(arg4); result = erl_format("{ok, ~i}", res); } break; case OPT_ITERATE: res = 0; // iterate(ERL_INT_VALUE(argp)); result = erl_mk_int(res); break; case OPT_FINALIZE: res = 0; // finalize(ERL_INT_VALUE(argp)); result = erl_mk_int(res); break; default: res = -1; } if (!erl_encode(result, buf)) erl_err_ret("Error in erl_encode(): %d!", erl_errno); else { n = erl_term_len(result); write_cmd(buf, n); } erl_free_compound(tuple); erl_free_term(fun); erl_free_compound((ETERM*)result); } return 0; } //----------------------------------------------------------------- // Data marshaling routines //----------------------------------------------------------------- int read_cmd(byte *buf) { int len; if (read_exact(buf, 2) != 2) return(-1); len = (buf[0] << 8) | buf[1]; return read_exact(buf, len); } int write_cmd(byte *buf, int len) { byte li; li = (len >> 8) & 0xff; write_exact(&li, 1); li = len & 0xff; write_exact(&li, 1); return write_exact(buf, len); } int read_exact(byte *buf, int len) { int i, got=0; do { if ((i = read(0, buf+got, len-got)) <= 0) return(i); got += i; } while (got start("../port/opt_model"). test(P) -> R = initialize(P, 1, [{1, 2}, {2, 3}], [], []), R1 = stop(P), {R, R1}. %%====================================================================== %%================================= API ================================ %%====================================================================== start(ExtPrg) -> spawn_link(?MODULE, init, [ExtPrg]). stop(Pid) -> Pid ! stop. %%--------------------------------------------------------------------------- -define(opt_initialize, 1). -define(opt_iterate, 2). -define(opt_finalize, 3). %%--------------------------------------------------------------------------- initialize(Pid, GtwyID, Demand, Supply, Rates) -> call_port(Pid, {?opt_initialize, GtwyID, Demand, Supply, Rates}). iterate(Pid, GtwyID) -> call_port(Pid, {?opt_iterate, GtwyID}). finalize(Pid, GtwyID) -> call_port(Pid, {?opt_finalize, GtwyID}). %%====================================================================== %%===================== INTERNAL ROUTINES ============================== %%====================================================================== init(ExtPrg) -> process_flag(trap_exit, true), Port = open_port({spawn, ExtPrg}, [{packet, 2}, binary]), loop(Port). call_port(Pid, Msg) -> Pid ! {call, self(), Msg}, receive Result -> Result end. loop(Port) -> receive {call, Caller, Msg} -> io:format("Msg to port: ~p~n", [Msg]), Port ! {self(), {command, term_to_binary(Msg)}}, receive {Port, {data, Data}} -> io:format("Response received: ", []), io:format("~p~n", [binary_to_term(Data)]), Caller ! binary_to_term(Data); {'EXIT', Pid, Reason} -> io:format("Port ~p crashed with reason: ~p~n", [Pid, Reason]), Caller ! {'EXIT', Pid, Reason}, exit(Reason) end, apply(?MODULE, loop, [Port]); stop -> Port ! {self(), close}, receive {Port, closed} -> exit(normal) end; {'EXIT', Port, Reason} -> exit({port_terminated, Reason}) end. From vlad_dumitrescu@REDACTED Wed May 28 08:15:07 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 28 May 2003 08:15:07 +0200 Subject: (OT) rebuttal against "Why OO Sucks" References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> <2003052715521054065171@kestrel.sage.att.com> Message-ID: Hi, > and yet another, pro and con, > at http://www.dreamsongs.com/Essays.html#ObjectsHaveFailed That was a very interesting essay! Especially if reading it with Erlang in mind :-) regards, Vlad From mikael.karlsson@REDACTED Wed May 28 09:23:29 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Wed, 28 May 2003 09:23:29 +0200 Subject: Web applications unification In-Reply-To: <3ED3D55B.2010901@bluetail.com> References: <200305271933.35658.mikael.karlsson@creado.com> <3ED3D55B.2010901@bluetail.com> Message-ID: <200305280923.29636.mikael.karlsson@creado.com> Joakim G. wrote: > Mikael Karlsson wrote: .. > >I noticed that xmlrpc uses generic behaviours in the latest version > > (1.13), but I can not find any "-behaviour(gen_server)" statement in the > > code. How is that? > > The server part of the xmlrpc lib _behaves_ as a gen_server it isn't > written using a gen_server behaviour though. > > Like this: > http://www.erlang.org/doc/r9b/doc/design_principles/spec_proc.html > as in: > http://www.gleipnir.com/xmlrpc/unpacked/LATEST/src/tcp_serv.erl > Thanks, I will not ask you why you implement your own gen_server :-) One note, the spec. says that you also must implement the function: system_code_change(Misc, OldVsn, Module, Extra) -> {ok, NMisc} | Error. Neither tcp_serv.erl or the example in the spec. implements it so is this not really necessary? I guess that if I write code for own use and know that it will not be updated on a running system thats ok, but for generic libraries ? /Mikael From erlang@REDACTED Wed May 28 08:46:41 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Wed, 28 May 2003 07:46:41 +0100 Subject: Eppur si sugat References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> <20030527162852.1245c1b1.cpressey@catseye.mb.ca> Message-ID: <3ED45B51.2070206@manderp.freeserve.co.uk> A bit of dictionary hacking leads me to believe joe was alluding to Galilei; 'Eppur si muove' 'Still the Earth moves' "And yet it still sucks!" == Eppur si sugat Am I right? Everyone else seems or pretends to know exactly what Joe said! As for the debate, it looks as if you are all fighting over how to formalise the OO "method." Joe, from the FP camp desires to see the formal definition of OO to enable comparison with the formal definition of any FP language. Such definition _does_not_exist_ for OO, because it has grown out of day-to-day experience and "best practices" of programmers in the trenches who don't necessarily have time or the inclination to write a thesis about how they get results. OO is no more than a bunch of good recipes for hackers. And like recipes, there's always more than one way to get similar results. This doesn't mean that they're bad. I get results using OO methods when digging my trench. Unfortunately some marketing bright spark came up with a "OOh!" to "Wow!" management, and the rest is history. In this world the best technical solution doesn't even win on merit, and I think Joe (and I) get upset because of that. Pete. Chris Pressey wrote: > On Tue, 27 May 2003 10:40:00 +0200 (CEST) > Joe Armstrong wrote: > > >> Eppur si sugat (was that right?) > > > (Not sure - Google just gave me a blank look when I tried it...) > > (interesting but marginally mathematical related stuff deleted.) From erlang@REDACTED Wed May 28 10:11:56 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Wed, 28 May 2003 09:11:56 +0100 Subject: Eppur si sugat References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> <20030527162852.1245c1b1.cpressey@catseye.mb.ca> <3ED45B51.2070206@manderp.freeserve.co.uk> <20030528023509.624c7be7.cpressey@catseye.mb.ca> Message-ID: <3ED46F4C.3030108@manderp.freeserve.co.uk> Chris Pressey wrote: > On Wed, 28 May 2003 07:46:41 +0100 > Peter-Henry Mander wrote: > >>As for the debate, it looks as if you are all fighting over how to >>formalise the OO "method." Joe, from the FP camp desires to see the >>formal definition of OO to enable comparison with the formal >>definition of any FP language. Such definition _does_not_exist_ for >>OO, because it has grown out of day-to-day experience and "best >>practices" of programmers in the trenches who don't necessarily have >>time or the inclination to write a thesis about how they get results. > > Really? The "Object have not failed" remarks from Garry's link seem to > imply that it has been formalized at least once. > Yeah, and imho he misses the point (or perverts it!) about "smart data and dumb code" by thinking "smart data" == "objects"! What is _really_ meant is "smart data structure design" and "functions without state i.e. dumb", as we find in FP. The interesting thing is that Erlang has the power to create concurrent communicating "objects" with _real_ message passing, not the "messages" which are no more than function calls in modern OO languages. In effect Erlang can be an OO language (sorry Joe), it's just not imposed upon the programmer. It also has the prototyping capability of Smalltalk if you exploit dynamic code replacement. It has the best building blocks a language can have for a helluva lot of tasks. I think the lack of imposition of a half-baked, inconsistent interpretation of the vague OO concepts (or any other "concept") has given Erlang a huge advantage; it can adapt to the latest trend with little effort, even the inconsistent ones! There you are Joe, Erlang is the best foundation to implement any of the latest programming trends (-: Pete. From mikael.karlsson@REDACTED Wed May 28 10:32:14 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Wed, 28 May 2003 10:32:14 +0200 Subject: Web applications unification In-Reply-To: <007601c324a4$e11e4640$fd7a40d5@telia.com> References: <200305271933.35658.mikael.karlsson@creado.com> <007601c324a4$e11e4640$fd7a40d5@telia.com> Message-ID: <200305281032.14693.mikael.karlsson@creado.com> onsdag 28 maj 2003 01:08 skrev Wiger Ulf: > On Tue, 27 May 2003, Mikael Karlsson wrote: > > tisdag 27 maj 2003 13:36 skrev Ulf Wiger: > > > I agree. I also added 'builder' to jungerl as an attempt to > > > provide a lightweight aide for packaging OTP applications > > > and building start scripts. I don't know how well it > > > succeeded (and it does need more work). > > > > > > The general idea was that you should be able to > > > incrementally build more and more complex systems with > > > relative ease. > > > > Yes, hmm this means that one should use generic behaviours like > > gen_server etc. in such a framework? > > If you want to use gen_servers, you could of course, but that has nothing > to do with builder. > > The builder utility is intended to simplify the task of building .app > files, .rel files, and finally .script and .boot files in order to start a > system. > > When building a framework of different Open Source contributions, I think > it helps to agree on a way to start the appl?cations. OTP provides such a > way. What you want to do in the start function in order to get your > processes running is another matter. I believe that the gen_server > behaviour is quite useful, and I use it myself as much as I can, but it's > not really something that affects your APIs, so it's normally an internal > implementation detail. > Thanks, I guess a good starting point for such a framework would be that one should implement the generic behaviour API then, so that a supervisor can start the application or by using application:start. This seems to be the case already for most contributions, either "by hand" like in xmlrpc, or by implementing gen_{server,fsm,event} like yaws, btt, inets/httpc_manager etc. Because those contributing knows how to do it since ages ago :-) If you provide a library with no processes, like xmerl, then there is of course no need for this. Then you have a choice of using builder and making .app, .rel, .script and .boot files or using application:start in your own code? I guess that using application:start to start other applications from my own app is fine as long as my own contribution is standalone, but as soon as it integrated by others it should not. If I for instance wan't to incorporate BTT, (Bluetail Ticket Tracker), as a part in a larger application that also uses Yaws, I probably do not wan't BTT to start and configure the Yaws webserver. Just as an example, BTT is great. /Mikael From cpressey@REDACTED Wed May 28 09:35:09 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 28 May 2003 02:35:09 -0500 Subject: Eppur si sugat In-Reply-To: <3ED45B51.2070206@manderp.freeserve.co.uk> References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> <20030527162852.1245c1b1.cpressey@catseye.mb.ca> <3ED45B51.2070206@manderp.freeserve.co.uk> Message-ID: <20030528023509.624c7be7.cpressey@catseye.mb.ca> On Wed, 28 May 2003 07:46:41 +0100 Peter-Henry Mander wrote: > As for the debate, it looks as if you are all fighting over how to > formalise the OO "method." Joe, from the FP camp desires to see the > formal definition of OO to enable comparison with the formal > definition of any FP language. Such definition _does_not_exist_ for > OO, because it has grown out of day-to-day experience and "best > practices" of programmers in the trenches who don't necessarily have > time or the inclination to write a thesis about how they get results. Really? The "Object have not failed" remarks from Garry's link seem to imply that it has been formalized at least once. > [...] Unfortunately some marketing bright > spark came up with a "OOh!" to "Wow!" management, and the rest is > history. In this world the best technical solution doesn't even win on > merit, and I think Joe (and I) get upset because of that. As do I, believe me! I like the hard-nosed pragmatic approach a lot, myself - judging things on their merits instead of their popularity. It's why I run FreeBSD instead of Linux, qmail instead of sendmail, and to a large degree, Erlang instead of <>. Unfortunately I don't think countering glamour with it's diametric opposite, obloquy (i.e. "that sucks") is very effective, and I really don't think it's going to be effective if it's directed at the thing that just happens to be glamourous in the situation... Wish I had the time to respond to more of these emails. > Pete. -Chris From joe@REDACTED Wed May 28 10:11:28 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 28 May 2003 10:11:28 +0200 (CEST) Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) In-Reply-To: <3ED45B51.2070206@manderp.freeserve.co.uk> Message-ID: On Wed, 28 May 2003, Peter-Henry Mander wrote: > A bit of dictionary hacking leads me to believe joe was alluding to > Galilei; 'Eppur si muove' 'Still the Earth moves' > > "And yet it still sucks!" == Eppur si sugat Right on - I had great trouble with this. It turns out (According to one source) that "Eppur si mnove" is not good 'ol Latin but is 15'th century Florentine Italian - I cannot confirm this (Francisco - help!!!!) I guessed that "muove" must be moves - so I needed the Latin for sucks. I then typed "sucks latin" into google hoping to find a latin translation for "sucks" - This was a mistake - goggle obligingly coughed up several pages of references to young latin ladies who sucked things - the things being sucked were not lollipops - I say no more. > > Am I right? Everyone else seems or pretends to know exactly what Joe said! > > As for the debate, it looks as if you are all fighting over how to > formalise the OO "method." Joe, from the FP camp desires to see the > formal definition of OO to enable comparison with the formal definition > of any FP language. Such definition _does_not_exist_ for OO, because it > has grown out of day-to-day experience and "best practices" of > programmers in the trenches who don't necessarily have time or the > inclination to write a thesis about how they get results. > > OO is no more than a bunch of good recipes for hackers. > > And like recipes, there's always more than one way to get similar > results. This doesn't mean that they're bad. I get results using OO > methods when digging my trench. Unfortunately some marketing bright > spark came up with a "OOh!" to "Wow!" management, and the rest is > history. In this world the best technical solution doesn't even win on > merit, and I think Joe (and I) get upset because of that. > This is precisely the reason why my latest ploy is to call Erlang a COPL. "Concurrency Oriented Programming" is intended to be analogy of OOP - ie nobody knows what it is but everybody recoginised a COPL when they see one. The "thing" about Erlang (and about COPL) is - Isolated processes - Pure message passing It is just the lack of isolation that *prevents* Java from being used for anything sensible. <> ... the only safe way to execute multiple applications written in the Java programming language, on the same computer is to use a separate JVM for each of them, and execute each JVM in a separate OS process. ... In particular, the abstraction of a process, offered by modern OSes, is thew role module in terms of features; isolation from other computations, resources accountability and control, and ease of termination and resource reclamation.} ... tasks cannot directly share objects, and that the only way for tasks to communicate is to use standard, copying communication mechanisms, ... -- Czajkowski and Dayn\`{e}s In Multitasking without comprimise: a virtual machine evolution, Proceedings of the OOPSLA '01 conference on Object Oriented Programming Systems Languages and Applications}, <> The above quote is from two guys at Sun - amazing. Their paper says basically - if you want to run two Java applications on the same machine you have to fire up two JVMs and run each one as a separate OS process. So despite the fact that Java is a "safe" language (with GC etc) you still need the protection as provided by OS processes. Despite this fact Java is still used as a systems programming language -- amazing, since *nobody* knows how to run multiple Java applications on the same machine *without* protecting them within OS processes (what do you do, give *every* programmer an OS process to play in ... :-) - Until this problem is solved Java should not be used for systems applications (it was, after all, *designed* for applets, where it works well and the abstractions are appropriate) ... As for pure message passing - In 1978 PLITS was invented (Programming language in the sky) - this was a pure message passing system - The authors of PLITS argued that "complex concurrency patterns" and "shared memory" was no-no. They thought that shared memory models just didn't work with complex concurrency pattern, they thought that programming such a system would be impossibly difficult. The PLITS people just cared about pure message passing between isolated processes - "communicating black boxes" they didn't even care about what language was *inside* the black box (this is *precisely* the XML/SOAP philosophy of black boxes communicating via XML messages, or the UBF philosophy) Having introduced the idea of a COPL I talk about fault-tolerance. To make a fault-tolerant applications you need TWO computers AND they cannot share data (because If you only have one computer it might crash) - thus you need isolation and pure message passing. The basis of fault-tolerant computations rests upon three things: a) isolation of components b) pure message passing c) stable storage a) the computers must be isolated - if one crashes the other must continue Since the computers are isolated, they can share no data, therefore the *only* way they can interact is by pure message passing (point b) c) stable storage is storage which survives a crash - you need this to recover *after* a crash has occurred. Now a) and b) are built into Erlang. c) can be achieved in a number of different ways - mnesia, asynchronous replications, etc. there are lots of ways of doing this. The conclusion of all this is that if you want to make a fault-tolerant system you *have* to get interested in COPLS. My current way of describing Erlang/OTP is saying that "it is a software emulation of the Tandem computer" Read Jim Gray's 1985 paper "Why do computers stop and what can be done about it? and you will immediately be struck by the similarity in the design of the Tandem and of the Erlang/OTP system. The Tandem was for many years (and possible still is) one of the best known architectures for making fault-tolerant systems - Incidentally, the tandem used "fail-fast processors" the idea was it a failure occurs (ie an error which cannot be corrected) die as soon as possible - *exactly* the "let it crash philosophy" in Erlang. /Joe > Pete. > > Chris Pressey wrote: > > On Tue, 27 May 2003 10:40:00 +0200 (CEST) > > Joe Armstrong wrote: > > > > > >> Eppur si sugat (was that right?) > > > > > > (Not sure - Google just gave me a blank look when I tried it...) > > > > > > > (interesting but marginally mathematical related stuff deleted.) > > From eleberg@REDACTED Wed May 28 10:54:57 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 28 May 2003 10:54:57 +0200 (MEST) Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) Message-ID: <200305280854.h4S8svq21453@cbe.ericsson.se> > X-Authentication-Warning: enfield.sics.se: joe owned process doing -bs > Date: Wed, 28 May 2003 10:11:28 +0200 (CEST) > From: Joe Armstrong ...deleted > The Tandem was for many years (and possible still is) one of the > best known architectures for making fault-tolerant systems - i did not like the way of overloading single functions (eg writeread()) to do many things depending upon the arguments. but, yes, guardian was very nice to program. bengt From robert.virding@REDACTED Wed May 28 11:15:52 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 28 May 2003 11:15:52 +0200 Subject: Fix for A=<<1>> References: , , <011c01c323cc$8a0834c0$8300a8c0@virding.org> Message-ID: <009001c324f9$bce70820$8500000a@Clarke> The problems are at different levels: 1. There is a fundamental difference in scanning atoms/strings and =<<<<<. You have basically introduced infinite look-ahead (at least to the end of the file) to try and determine what the first token actually is, for everything else there is one character look-ahead. (As is the grammar which is one LALR1) 2. There are at least three different "one key-press typos" which can give "A=<<1>>": A==<<1>> A=<<<1>> A= <<1>> Two tests and a match. How can you so so certain what I meant as to choose one? Introducing a match when I really meant a test will introduce a fundamental semantic change to the code, both as to return value and to the error case. Also if I had mistyped the variable name then this *really* changes the meaning of the code. And it does it automagically, completely silently and in a way which can make it extremely difficult for the programmer to find! 3. Nothing should try to correct its input, especially not something as fundamental as the scanner. Especially when the "correction" is not unambiguous. Just because you now don't think the chances of meaning something else is slim doesn't mean other people think the same way. Or that you might not think so in the future. :-) 4. I personally always (or almost always) use spaces to separate my symbols so I don't really see what the problem is. My basic premise is that you can not add an "improver" which works silently and is only sometimes correct. Will you take the responsibility when this generates an serious, invisible error in someones code? The trouble with writing code at this level is that you always have to try and handle the case when users do things which you had assumed was so stupid or strange,even though it is legal, that no one would do it, in this case mean "A=<<<1>>" when they wrote "A=<<1>>". I remember that a relatively early version of the JAM compiler could not handle the case when you did a send as an argument to a function to get the message in as an argument, (foo(X ! , ...)). The premise was that send is used for side effects not return values. Of course someone did just this and it crashed. Robert P.S. Liked the new code. You need to fix the comments. Can't the fun be generated each suspend and include the state? I think it would make things easier. From robert.virding@REDACTED Wed May 28 11:21:22 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 28 May 2003 11:21:22 +0200 Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) References: Message-ID: <009801c324fa$81d72390$8500000a@Clarke> ----- Original Message ----- From: "Joe Armstrong" To: "Peter-Henry Mander" Cc: "Chris Pressey" ; Sent: Wednesday, May 28, 2003 10:11 AM Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) > On Wed, 28 May 2003, Peter-Henry Mander wrote: > > > A bit of dictionary hacking leads me to believe joe was alluding to > > Galilei; 'Eppur si muove' 'Still the Earth moves' > > > > "And yet it still sucks!" == Eppur si sugat > > Right on - I had great trouble with this. > > It turns out (According to one source) that "Eppur si mnove" is not > good 'ol Latin but is 15'th century Florentine Italian - I cannot confirm this > (Francisco - help!!!!) Of course it was Italian, thats what the books say! I thought everyone knew that. :-) Robert From ndalton@REDACTED Wed May 28 11:43:14 2003 From: ndalton@REDACTED (Niall Dalton) Date: 28 May 2003 10:43:14 +0100 Subject: Accept filters on FreeBSD? Message-ID: <1054114994.13253.1465.camel@localhost> Hello, Does anyone have experience using accept filters on FreeBSD in Erlang applications? In particular, I'm interested in using the accf_http filter ("It prevents the application from receiving the connected descriptor via accept() until either a full HTTP/1.0 or HTTP/1.1 HEAD or GET request has been buffered by the kernel."). Is there a way to use these from straight Erlang, or should I be thinking of a little bit of C called from my Erlang code? Best regards, niall ------------------------------ This e-mail is intended for the named addressee only. It may contain confidential and/or privileged information. If you have received this message in error, please let us know and then delete this message from your system. You should not copy the message, use it for any purpose or disclose its contents to anyone. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ From matthias@REDACTED Wed May 28 12:16:44 2003 From: matthias@REDACTED (Matthias Lang) Date: Wed, 28 May 2003 12:16:44 +0200 Subject: Eppur si sugat In-Reply-To: <3ED45B51.2070206@manderp.freeserve.co.uk> References: <20030525155618.1cd7f92a.cpressey@catseye.mb.ca> <20030527162852.1245c1b1.cpressey@catseye.mb.ca> <3ED45B51.2070206@manderp.freeserve.co.uk> Message-ID: <16084.35980.251415.683489@antilipe.corelatus.se> Peter-Henry Mander writes: > desires to see the formal definition of OO to enable comparison > with the formal definition of any FP language. Such definition > _does_not_exist_ for OO Depends a bit on what you mean by "formal". One standard text on the subject is http://www.luca.demon.co.uk/TheoryOfObjects.html Matthias From gandalf@REDACTED Wed May 28 12:19:24 2003 From: gandalf@REDACTED (Alex Ogloblin) Date: Wed, 28 May 2003 16:19:24 +0600 Subject: Fw: erl_interface Message-ID: <031501c32502$9cbf2240$0401a8c0@gandalf> Heil, Serge Aleynikov Got the code : =============== COMM_DRV.CC========================= #include using namespace std; #include #include #include #include #ifndef WIN32 #include #endif #include extern "C"{ #include "erl_eterm.h" #include "erl_format.h" #include "erl_marshal.h" #include "erl_fix_alloc.h" #include "erl_malloc.h" #include "erl_rport.h" #include "erl_connect.h" #include "erl_start.h" #include "erl_resolve.h" extern void erl_init_nothreads(void *x, long y); #define erl_init(x,y) erl_init_nothreads(x,y) } #include #pragma pack(1) #include #include "comm_drv.h" typedef ETERM * PETERM; static void hex_dump(char * buff,int len); HPORT openport(char * name,int speed) { if(!name) { #ifdef WIN32 return INVALID_HANDLE_VALUE; #else return -1; #endif } #ifdef WIN32 //WIN32 platform COMMTIMEOUTS t_outs; COMMCONFIG cfg; DWORD size; HANDLE porthandle=CreateFile(name,GENERIC_READ | GENERIC_WRITE,NULL,NULL, OPEN_EXISTING,NULL,NULL); if(porthandle==INVALID_HANDLE_VALUE || !GetCommConfig(porthandle,&cfg,&size)) { return INVALID_HANDLE_VALUE; } t_outs.ReadIntervalTimeout=1; t_outs.ReadTotalTimeoutMultiplier=1; t_outs.ReadTotalTimeoutConstant=1; t_outs.WriteTotalTimeoutMultiplier=1; t_outs.WriteTotalTimeoutConstant=1; cfg.dcb.BaudRate=speed; cfg.dcb.Parity=NOPARITY; cfg.dcb.StopBits=ONESTOPBIT; cfg.dcb.ByteSize=8; if(!SetCommConfig(porthandle,&cfg,cfg.dwSize) || !SetCommTimeouts(porthandle,&t_outs)) { return INVALID_HANDLE_VALUE; } return porthandle; #else //UNIX (posix) platform int ispeed; int porthandle; switch(speed) { case 115200: ispeed=B115200; break; case 57600: ispeed=B57600; break; case 38400: ispeed=B38400; break; case 19200: ispeed=B19200; break; case 9600: ispeed=B9600; break; case 4800: ispeed=B4800; break; case 2400: ispeed=B2400; break; case 1200: ispeed=B1200; break; case 600: ispeed=B600; break; case 300: ispeed=B300; break; default: return -1; } termios Settings; porthandle=::open(name,O_RDWR | O_NONBLOCK | O_NOCTTY); if(porthandle == -1) { return -1; } tcgetattr(porthandle, &Settings); cfmakeraw(&Settings); Settings.c_cflag = (CS8 | CREAD | CLOCAL | ispeed); Settings.c_lflag =0; //Settings.c_iflag = (IGNCR | IGNBRK | IGNPAR); Settings.c_iflag = (IGNBRK | IGNPAR); Settings.c_iflag &= ~INPCK; tcflush(porthandle,TCIOFLUSH); if(tcsetattr(porthandle, TCSANOW, &Settings) ==-1) { return -1; } return porthandle; #endif }; void closeport(HPORT porthandle) { #ifdef WIN32 if(porthandle!=INVALID_HANDLE_VALUE)CloseHandle(porthandle); #else if(porthandle != -1)close(porthandle); #endif } bool writeport(HPORT port,char * buff,int size) { int rc; if(size == 0)return true; #ifdef WIN32 WriteFile(port,buff,size,(DWORD *)&rc,NULL); #else rc=::write(port,buff,size); #endif //printf("\noutwrite:%u",rc); if(rc==size)return true; if(rc == 0)return false; if(rc < 0) { if(errno == EAGAIN || errno == EINTR)return false; return false; } }; void commstep(HPORT port,ErlDrvPort dport) { char buff[512]; int rc; #ifdef WIN32 if(port ==INVALID_HANDLE_VALUE)return; bool rc2=ReadFile(port,buff,sizeof(buff),(DWORD *)&rc,NULL); #else if(port == -1)return -1; rc=::read(port,buff,sizeof(buff)); #endif if(rc == 0)return; if(rc < 0) { if(errno == EAGAIN || errno == EINTR)return; return; } int n=2; ETERM ** termlist=(ETERM **)new (ETERM *)[n]; ETERM * term_int=erl_mk_int(COMM_READ); ETERM * term_bin=erl_mk_binary(buff,rc); termlist[0]=term_int; termlist[1]=term_bin; ETERM * term2=erl_mk_list(termlist,n); int outsize=erl_term_len(term2); unsigned char * outbuff=new unsigned char[outsize]; erl_encode(term2,outbuff); driver_output(dport,(char *)outbuff,outsize); erl_free_term(term2); erl_free_term(term_int); erl_free_term(term_bin); delete[] termlist; }; #pragma pack() static void hex_dump(char * buff,int len) { for(int i1=0;i1 < len;i1++) { char c1=buff[i1]; printf("%2x(%c)",c1,(isprint(c1))?c1:' '); } printf("\n"); }; void send_int(ErlDrvPort port,int arg) { ETERM * term=erl_mk_int(arg); int size=erl_term_len(term); unsigned char * buff=new unsigned char[size]; erl_encode(term,buff); driver_output(port,(char *)buff,size); delete[] buff; erl_free_term(term); }; typedef struct { ErlDrvPort port; HPORT porthandle; } comm_data; static ErlDrvData comm_drv_start(ErlDrvPort port, char *buff) { erl_init(NULL,0); comm_data* d = (comm_data*)driver_alloc(sizeof(comm_data)); d->port = port; return (ErlDrvData)d; } static void comm_drv_stop(ErlDrvData handle) { driver_free((char*)handle); } static void comm_drv_output(ErlDrvData handle, char *buff, int bufflen) { ETERM * term1; ETERM * tport; ETERM * tspd; char * portname; int spd; ETERM * tbuff; ETERM * tsize; char * buff2; int size2; unsigned char * outbuff; int outsize; comm_data* d = (comm_data*)handle; char fn = buff[0], arg = buff[1], res; switch(fn) { case COMM_OPEN: term1=erl_decode((unsigned char *)buff+1); ((unsigned char *)term1)); tport=erl_element(1,term1); tspd=erl_element(2,term1); portname=erl_iolist_to_string(tport); spd=ERL_INT_VALUE(tspd); d->porthandle=openport(portname,spd); erl_free(portname); erl_free_term(tspd); erl_free_term(tport); erl_free_term(term1); res=(d->porthandle > 0)?1:0; driver_output(d->port, &res, 1); break; case COMM_CLOSE: closeport(d->porthandle); res=1; driver_output(d->port, &res, 1); break; case COMM_STEP: commstep(d->porthandle,d->port); break; case COMM_WRITE: tbuff=erl_decode((unsigned char *)buff+1); buff2=(char *)ERL_BIN_PTR(tbuff); size2=ERL_BIN_SIZE(tbuff); res=(writeport(d->porthandle,buff2,size2))?1:0; erl_free_term(tbuff); driver_output(d->port, &res, 1); break; default: res=0; driver_output(d->port, &res, 1); break; }; } ErlDrvEntry comm_driver_entry = { NULL, /* F_PTR init, N/A */ comm_drv_start, /* L_PTR start, called when port is opened */ comm_drv_stop, /* F_PTR stop, called when port is closed */ comm_drv_output, /* F_PTR output, called when erlang has sent */ NULL, /* F_PTR ready_input, called when input descriptor ready */ NULL, /* F_PTR ready_output, called when output descriptor ready */ "comm_drv", /* char *driver_name, the argument to open_port */ NULL, /* F_PTR finish, called when unloaded */ NULL, /* F_PTR control, port_command callback */ NULL, /* F_PTR timeout, reserved */ NULL /* F_PTR outputv, reserved */ }; extern "C"{ DRIVER_INIT(comm_drv) /* must match name in driver_entry */ { return &comm_driver_entry; } } ==================COMM_DRV.H==================== #ifndef __erlint_h__ #define __erlint_h__ #include #define COMM_OPEN 1 #define COMM_CLOSE 2 #define COMM_STEP 3 #define COMM_READ 4 #define COMM_WRITE 5 #define COMM_DATA 6 #define COMM_ERROR 7 #ifdef WIN32 #include typedef HANDLE HPORT; #else typedef int HPORT; #endif HPORT openport(char * name,int speed); void closeport(HPORT port); bool writeport(HPORT port,char * buff,int size); void commstep(HPORT port,ErlDrvPort dport); #endif =================COMM.HRL==================== -define(COMM_OPEN,1). -define(COMM_CLOSE,2). -define(COMM_STEP,3). -define(COMM_READ,4). -define(COMM_WRITE,5). ==================COMM.ERL======================= -module(comm). -export([start/2,stop/1]). -export([close/1,open/3,write/2]). -export([encode/1,init/3,loop/2]). -compile({inline,30}). -include("comm.hrl"). call_port(Pid,Msg) -> Pid ! {call, self(), Msg}, receive {Pid, Result} -> Result end. encode({comm_open,Name,Speed}) -> [?COMM_OPEN,term_to_binary({Name,Speed})]; encode({comm_close}) -> [?COMM_CLOSE]; encode({comm_step}) -> [?COMM_STEP]; encode({comm_write,Bin}) -> [?COMM_WRITE,term_to_binary(Bin)]. loop(Port,Client) -> receive % command interface to COMM_DRV {call, Caller, Msg} -> Port ! {self(), {command, encode(Msg)}}, receive {Port, {data, Data}} -> Caller ! {self(), Data} end, loop(Port,Client); % periodic poll serial driver {comm_step,Delay} -> Port ! {self(), {command, [?COMM_STEP]}}, timer:send_after(Delay,self(),{comm_step,Delay}), loop(Port,Client); % data from serial driver {Port,{data,List}}-> Bin1=list_to_binary(List), case binary_to_term(Bin1) of [?COMM_READ,Bin2]-> case catch Client ! {?COMM_READ,Bin2} of {'EXIT',Reason}-> io:fwrite("~nCLIENT ~w invalid.~w",[Client,Reason]); _->ok end, io:fwrite("~nREAD:~w",[Bin2]); X -> io:fwrite("~nREAD?:~w",[X]) end, loop(Port,Client); {comm_read,Bin} -> io:fwrite("~nREAD:~w",[Bin]), loop(Port,Client); % stop the driver stop -> Port ! {self(), close}, receive {Port, closed} -> exit(normal) end; % abort in the C++ code {'EXIT', Port, Reason} -> io:fwrite("~nEXIT:~w ~n", [Reason]), exit(port_terminated); X-> io:fwrite("~nLOOP1:~w",[X]), loop(Port,Client) end. init(SharedLib,Client,Period) -> Port = open_port({spawn, SharedLib}, []), timer:send_after(Period,self(),{comm_step,Period}), loop(Port,Client). % load and started serial driver with pid Client and integer Period % Client - pid of receiver of data % Period - millisecond start(Client,Period) -> case erl_ddll:load_driver("./","comm_drv") of ok -> ok; {error, already_loaded} -> ok; {error,A} ->exit({error,A,"comm_drv"}) end, Pid=spawn(?MODULE, init, ["comm_drv",Client,Period]). %close serial port close(Pid) -> call_port(Pid,{comm_close}). % open serial port with Name and Speed % Name - string name of serial port % Speed - integer speed in baud open(Pid,Name,Speed) -> call_port(Pid,{comm_open,Name,Speed}). write(Pid,Bin) -> io:fwrite("~nERL:~w",[Bin]), call_port(Pid,{comm_write,Bin}). % stop and unload serial driver stop(Pid) -> Pid ! {call, self(), {comm_close}}, Pid ! stop, erl_ddll:unload_driver("comm_drv"). loop2() -> receive Data -> io:fwrite("~n~w",[Data]), loop2() end. start2() -> Pid=spawn(?MODULE,loop2,[]). > I wonder if someone could share erl_interface-based examples with me. > I've been trying to write some code that passes either a tuple/list, or > an integer from C to Erlang, and I am having a problem that in case of > integers (see iterate() and finalize() below) Erlangs gets a response > correctly, but in case of tuple/list (see initialize()), looks like > Erlang is waiting for something in addition to what the port replies. I > can see in debugger that the Port sends everything normally, and then > blocks on the read() function as expected. > > Serge From raimo.niskanen@REDACTED Wed May 28 12:32:58 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Wed, 28 May 2003 12:32:58 +0200 Subject: Fix for A=<<1>> References: <011c01c323cc$8a0834c0$8300a8c0@virding.org>, , <009001c324f9$bce70820$8500000a@Clarke> Message-ID: You are of course right, but: Sometimes I and many others do not use spaces to separate the symbols. The best example I can think of is: Rec#rec{length=0,state=init,count=0,buf=<<>>} where I do _not_ want spaces. Size comparision of binaries I think is so uncommon that the programmer that thinks "A =< <<1>>" does not write "A=<<<1>>". It is to ambiguous to the eye. Especially size comparisions of binaries must be _very_ uncommon. The programmer that skips as many spaces between tokens as possible is begging for trouble. Equality comparisions of binaries I think is also rather uncommon, but note that "A==<<1>>" is scanned correctly(tm) and "A==<1>>" gives an error since scanning of '==' is eager. Remains typing "A=<<<1>>" when meaning "A==<<1>>", but that is a double fault. About the code comments: more precisely, which (kind of) comments need to be fixed? About including the state in the fun: I guess more/6 could be change into something like: more(Cs, Pos, State, Fun) -> {more,{Cs,Pos,State,Fun}}. And tokens/3 into: tokens([], Chars, Pos) -> tokens({[],Pos,io, fun (Cs,P,State)-> scan(Cs, [], [] Pos, State}) end, Chars, Pos); tokens({Cs,Pos,eof,_Fun}, eof, _) -> {done,{eof,Pos},Cs}; tokens({Cs,Pos,_State,Fun}, eof, _) -> Fun(Cs++eof, eof); tokens({Cs,Pos,State,Fun}, Chars, _) -> Fun(Cs++Chars, State). note that Cs, Pos, State and Fun are still needed in tokens/3. The fun can only contain Stack, Tokens and Pos. Then the calls to more/6 would have to change into: scan(">"=Cs, Stack, Toks, Pos, State) -> more(Cs, Pos, State, fun (C, S) -> scan(C, Stack, Toks, Pos, S) end); And these calls are rather many so it will clutter the code compared to: scan(">"=Cs, Stack, Toks, Pos, State) -> more(Cs, Stack, Toks, Pos, State, fun scan/5); By passing two (as far as I can see they are only 2: Stack and Tokens) unneseccary arguments to more/6 I can use the "fun scan/5" notation which improves readability. Or did you have a smarter change in mind? / Raimo Robert Virding wrote: > The problems are at different levels: > > 1. There is a fundamental difference in scanning atoms/strings and =<<<<<. > You have basically introduced infinite look-ahead (at least to the end of > the file) to try and determine what the first token actually is, for > everything else there is one character look-ahead. (As is the grammar which > is one LALR1) > > 2. There are at least three different "one key-press typos" which can give > "A=<<1>>": > > A==<<1>> > A=<<<1>> > A= <<1>> > > Two tests and a match. How can you so so certain what I meant as to choose > one? Introducing a match when I really meant a test will introduce a > fundamental semantic change to the code, both as to return value and to the > error case. Also if I had mistyped the variable name then this *really* > changes the meaning of the code. And it does it automagically, completely > silently and in a way which can make it extremely difficult for the > programmer to find! > > 3. Nothing should try to correct its input, especially not something as > fundamental as the scanner. Especially when the "correction" is not > unambiguous. Just because you now don't think the chances of meaning > something else is slim doesn't mean other people think the same way. Or that > you might not think so in the future. :-) > > 4. I personally always (or almost always) use spaces to separate my symbols > so I don't really see what the problem is. > > My basic premise is that you can not add an "improver" which works silently > and is only sometimes correct. Will you take the responsibility when this > generates an serious, invisible error in someones code? > > The trouble with writing code at this level is that you always have to try > and handle the case when users do things which you had assumed was so stupid > or strange,even though it is legal, that no one would do it, in this case > mean "A=<<<1>>" when they wrote "A=<<1>>". I remember that a relatively > early version of the JAM compiler could not handle the case when you did a > send as an argument to a function to get the message in as an argument, > (foo(X ! , ...)). The premise was that send is used for side > effects not return values. Of course someone did just this and it crashed. > > Robert > > P.S. Liked the new code. You need to fix the comments. Can't the fun be > generated each suspend and include the state? I think it would make things > easier. > > From etxuwig@REDACTED Wed May 28 12:58:14 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 28 May 2003 12:58:14 +0200 (MEST) Subject: Web applications unification In-Reply-To: <200305281032.14693.mikael.karlsson@creado.com> Message-ID: On Wed, 28 May 2003, Mikael Karlsson wrote: >I guess a good starting point for such a framework would be >that one should implement the generic behaviour API then, >so that a supervisor can start the application or by using >application:start. If you have a runnable application, you need to write a start/2 function and define it in an .app file. In most cases, such a start function would call supervisor:start_link(), and while this is definitely recommended, it is no requirement. There are other ways to start an erlang node, e.g. using the -s flag and then calling application:start() (which assumes the existence of an .app file), or simply spawning processes. For a robust framework, we should definitely go with the OTP way of doing things, since it works well, and comes with both support and documentation. >If you provide a library with no processes, like xmerl, >then there is of course no need for this. Correct. >Then you have a choice of using builder and making .app, >.rel, .script and .boot files or using application:start in >your own code? If your applications do not have a start function, using builder will still give you the benefit of a start script, always picking the latest version of each application (if that's what you want, otherwise, a specific version of some app) and making sure they're in the path, and semi-automatic configuration of environment variables. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson AB, Connectivity and Control Nodes From jay@REDACTED Wed May 28 14:33:09 2003 From: jay@REDACTED (Jay Nelson) Date: Wed, 28 May 2003 05:33:09 -0700 Subject: Distributed Processing Algorithms Message-ID: <4.2.2.20030528052923.00cf3b50@duomark.com> Anybody have recommended reading on the topic of Distributed Processing Algorithms? I am looking for seminal texts, papers, research or even speculation. My interest is how to express computation in a fully distributed network of equal CPUs, without resorting to a task manager or other such process. I want the nodes to independently decide what to do, yet the group as a whole needs to coordinate their activate with the least amount of overlap in computation or negotiation. I am trying to avoid introducing single points of failure. jay From raimo.niskanen@REDACTED Wed May 28 14:58:28 2003 From: raimo.niskanen@REDACTED (Raimo Niskanen) Date: Wed, 28 May 2003 14:58:28 +0200 Subject: Fix for A=<<1>> References: <011c01c323cc$8a0834c0$8300a8c0@virding.org>, , <009001c324f9$bce70820$8500000a@Clarke> Message-ID: OK, your argument about the typo "A=<<<1>>" when meaning "A=<<1>>" i.e "A = << 1 >>" accidentally becoming a valid syntax "A =< << 1 >>" has convinced us to remove this change from erl_scan (at least for R9C). The debate will probably respawn (reflame) after the R9C release. It is easier to add later than to remove. The final word is certainly not said. / Raimo Niskanen, Erlang/OTP, Ericsson AB Robert Virding wrote: > The problems are at different levels: > > 1. There is a fundamental difference in scanning atoms/strings and =<<<<<. > You have basically introduced infinite look-ahead (at least to the end of > the file) to try and determine what the first token actually is, for > everything else there is one character look-ahead. (As is the grammar which > is one LALR1) > > 2. There are at least three different "one key-press typos" which can give > "A=<<1>>": > > A==<<1>> > A=<<<1>> > A= <<1>> > > Two tests and a match. How can you so so certain what I meant as to choose > one? Introducing a match when I really meant a test will introduce a > fundamental semantic change to the code, both as to return value and to the > error case. Also if I had mistyped the variable name then this *really* > changes the meaning of the code. And it does it automagically, completely > silently and in a way which can make it extremely difficult for the > programmer to find! > > 3. Nothing should try to correct its input, especially not something as > fundamental as the scanner. Especially when the "correction" is not > unambiguous. Just because you now don't think the chances of meaning > something else is slim doesn't mean other people think the same way. Or that > you might not think so in the future. :-) > > 4. I personally always (or almost always) use spaces to separate my symbols > so I don't really see what the problem is. > > My basic premise is that you can not add an "improver" which works silently > and is only sometimes correct. Will you take the responsibility when this > generates an serious, invisible error in someones code? > > The trouble with writing code at this level is that you always have to try > and handle the case when users do things which you had assumed was so stupid > or strange,even though it is legal, that no one would do it, in this case > mean "A=<<<1>>" when they wrote "A=<<1>>". I remember that a relatively > early version of the JAM compiler could not handle the case when you did a > send as an argument to a function to get the message in as an argument, > (foo(X ! , ...)). The premise was that send is used for side > effects not return values. Of course someone did just this and it crashed. > > Robert > > P.S. Liked the new code. You need to fix the comments. Can't the fun be > generated each suspend and include the state? I think it would make things > easier. > > From jay@REDACTED Wed May 28 16:08:20 2003 From: jay@REDACTED (Jay Nelson) Date: Wed, 28 May 2003 07:08:20 -0700 Subject: Glamour, elegance, universality and emergent techniques Message-ID: <4.2.2.20030528063438.00cf5220@duomark.com> Once again the OO discussion rises and the blasphemers curse in church -- during the silence when all are listening, no less! One hopes this can only mark the coming enlightenment fomented by a scientific revolution (see http://www.emory.edu/EDUCATION/mfp/Kuhnsnap.html). Sometimes the solution is not at hand, so reason must give sway. Yet instinct and emotion can provide direction in the fog, and verily one can recover the path not yet trodden. I offer then only my sensations. Close your eyes, breathe and let your mind rest. On glamour vs. elegance: Glamour is the veneer of appeal that leaves one empty after discovering the ruse of the shill. External exuberance with no apparent source is a mirage. Elegance, on the other hand, arises from inner harmony and a transcendent essence. On universality: Objects are everything; everything is everything. In any case, I prefer reductionism and recursion to exceptions, iteration and imperatives. A problem solved as a corollary to a larger universal is elegant; an assemblage of incongruous components would only appear glamourous to Dr. Frankenstein during the frenzy of creation. Find me a result to achieve and I will search for a cause of inevitability, rather than a series of barriers that attempt to corral the solution. On simplicity and complexity: Simple approaches solve 80% of the problem quickly, whilst the remainder proves inevitably out of reach. Complex approaches solve 40% after toil, 80% after sweat, and 95% after much suffering. What appears a solution is dogged by nicks and burrs and other annoyances, and in reality the solution dissolves under stress. Elegance is the merger of simplicity and complexity: on meeting all seems as it should and it is obvious, on reflection deep mysteries abound yet are miraculously resolved. Typically it is not achieved until both simplicity and complexity are rejected. [AI -> OO -> COPL] Emergent techniques: Blueprints and scripts are brittle. Strong earthquakes will ruin the methodical architect. Adaptive behaviour, resilience and emergent techniques are necessary to survive the rigors of nature. And so it is with social organization, evolutionary designs and tools of the trade. Monolithic systems were abandoned with the realization that dinosaurs could not rule Earth. Self-propelled, collective computation by more intelligent individuals proved dominant. Emergence teaches us that something more may yet conquer the present majority. jay From ingela@REDACTED Wed May 28 18:25:59 2003 From: ingela@REDACTED (Ingela Anderton) Date: Wed, 28 May 2003 18:25:59 +0200 Subject: Oracle and ODBC erlang driver References: <1054033749.3ed34755e6932@imp.free.fr> Message-ID: <16084.58135.314737.292796@gargle.gargle.HOWL> The erlang ODBC application consists of an erlang part and a C-part. The C-part delivered for the W2K platform is compiled to work with sqlserver. Have you recompiled it to link with your oracle driver? The C-process has crashed for some reason. We need to set some environment variables to make oracle happy could that be the problem? Here at OTP we have tested odbc with oracle on solaris and with sqlserver on windows both work well. The version of ODBC used by Hal is obsolete an unsupported! Please let me know how it goes. -- /Ingela Ericsson AB - OTP team yvan.godin@REDACTED wrote: > Hello > > I would like to have a try with Erlang and Oracle > > but I have some problems with ODBC ORACLE acces on W2K (and same in NT4) > when I try to connect my database withing erl (werl) > > {ok,Ref} = > odbc:connect("UID=;PWD=;DBQ=;DSN=",[{driver_trace,on}]). > ** exited: {{badmatch,{error,connection_closed}},[{erl_eval,expr,3}]} ** > > =ERROR REPORT==== 27-May-2003::11:44:05 === > ** Generic server <0.112.0> terminating > ** Last message in was {'EXIT',#Port<0.72>,normal} > ** When Server state == {state,#Port<0.72>, > {<0.110.0>,#Ref<0.0.0.526>}, > <0.110.0>, > undefined, > on, > undefined, > undefined, > on, > connecting, > undefined, > 0, > false, > false, > []} > > LOG FILE > *********************************************************************** > Fatal NI connect error 12560, connecting to: > (DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oracleORCL)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDR > ESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=ORCL)(CID=(PROGRAM=c:\PROGRA~1\ERL523~1.3\lib\odbc-1.0.5\priv\bin > \odbcserver.exe)(HOST=)(USER=)))) > > VERSION INFORMATION: > TNS for 32-bit Windows: Version 8.1.7.0.0 - Production > Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version > 8.1.7.0.0 - Production > Time: 27-MAI-2003 11:27:36 > Tracing not turned on. > Tns error struct: > nr err code: 0 > ns main err code: 12560 > TNS-12560: TNS : erreur d'adaptateur de protocole > ns secondary err code: 0 > nt main err code: 530 > TNS-00530: Erreur d'adaptateur de protocole > nt secondary err code: 126 > nt OS err code: 0 > > on the log file the SID ORCL do not correspond to my TNS SID ... is that a > normal way ?? > > NB:some string have been replaced by > :the ODBC connection work fine with VisualBasic or Oracle ODBC Test > :release Erlang R9B-1 > > > > > Thank's for any idea or help > > > > Yvan From serge@REDACTED Wed May 28 18:17:32 2003 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 28 May 2003 12:17:32 -0400 Subject: Compiling erl_interface by Borland C++ Builder 6 Message-ID: <3ED4E11C.9070400@hq.idt.net> While trying to build a couple of projects that utilize ei / erl_interface in Borland C++ Builder I had to rebuild the erl_interface.lib and ei.lib and encountered the following incompatibility: 1. --------- erl_locking.h ----------------- #ifndef _ERL_LOCKING_H #define _ERL_LOCKING_H /* The C++ conditional test below needs to be moved here from a few lines below in order to compile successfully */ #ifdef __cplusplus extern "C" { #endif #ifdef __WIN32__ #include #include 2. --------- *.h ----------------- The __STDC__ test in all header files #ifdef __STDC__ needs to be rewritten as: #if defined(__STDC__) || defined(__BORLANDC__) ----------------------------------- After these changes the library compiled successfully. Serge From martin@REDACTED Wed May 28 18:44:36 2003 From: martin@REDACTED (martin j logan) Date: 28 May 2003 11:44:36 -0500 Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) In-Reply-To: References: Message-ID: <1054140275.12985.63.camel@berimbau.vail> "Why OO is less than sufficient for concurrent and fault tolerant systems." The above title is not too interesting. "Why OO sucks" or "Why OO is the worst thing since reality television" on the other hand are titles that grabs peoples attention. A loaded, provocative title will entice people to read an article. Please forgive me if I am being presumptuous but I think Joe's main point is that much of OO doctrine, philosophy and current implementations render the paradigm quite unsuitable for concurrent, fault tolerant systems. No one will argue that OO techniques are useless for say, a GUI, etc. The point is that if you are interested in programming for the niche that Erlang currently occupies then OO inherently sucks for your purposes and you should embrace the doctrines described by "COPL", its forefathers, and influences. My couple of pennies, Martin On Wed, 2003-05-28 at 03:11, Joe Armstrong wrote: > On Wed, 28 May 2003, Peter-Henry Mander wrote: > > > A bit of dictionary hacking leads me to believe joe was alluding to > > Galilei; 'Eppur si muove' 'Still the Earth moves' > > > > "And yet it still sucks!" == Eppur si sugat > > Right on - I had great trouble with this. > > It turns out (According to one source) that "Eppur si mnove" is not > good 'ol Latin but is 15'th century Florentine Italian - I cannot confirm this > (Francisco - help!!!!) > > > I guessed that "muove" must be moves - so I needed the Latin > for sucks. > > I then typed "sucks latin" into google hoping to find a latin translation > for "sucks" - > > This was a mistake - goggle obligingly coughed up several pages of > references to young latin ladies who sucked things - the things being > sucked were not lollipops - I say no more. > > > > > Am I right? Everyone else seems or pretends to know exactly what Joe said! > > > > As for the debate, it looks as if you are all fighting over how to > > formalise the OO "method." Joe, from the FP camp desires to see the > > formal definition of OO to enable comparison with the formal definition > > of any FP language. Such definition _does_not_exist_ for OO, because it > > has grown out of day-to-day experience and "best practices" of > > programmers in the trenches who don't necessarily have time or the > > inclination to write a thesis about how they get results. > > > > OO is no more than a bunch of good recipes for hackers. > > > > And like recipes, there's always more than one way to get similar > > results. This doesn't mean that they're bad. I get results using OO > > methods when digging my trench. Unfortunately some marketing bright > > spark came up with a "OOh!" to "Wow!" management, and the rest is > > history. In this world the best technical solution doesn't even win on > > merit, and I think Joe (and I) get upset because of that. > > > > This is precisely the reason why my latest ploy is to call Erlang > a COPL. > > "Concurrency Oriented Programming" is intended to be analogy of OOP > - ie nobody knows what it is but everybody recoginised a COPL when > they see one. > > The "thing" about Erlang (and about COPL) is > > - Isolated processes > - Pure message passing > > It is just the lack of isolation that *prevents* Java from being > used for anything sensible. > > <> > > ... the only safe way to execute multiple applications written in > the Java programming language, on the same computer is to use a > separate JVM for each of them, and execute each JVM in a separate OS > process. > > ... In particular, the abstraction of a process, offered by modern > OSes, is thew role module in terms of features; isolation from other > computations, resources accountability and control, and ease of > termination and resource reclamation.} > > > ... tasks cannot directly share objects, and that the only way for > tasks to communicate is to use standard, copying communication > mechanisms, ... > > -- Czajkowski and Dayn\`{e}s In Multitasking without comprimise: a > virtual machine evolution, Proceedings of the OOPSLA '01 conference on > Object Oriented Programming Systems Languages and Applications}, > > <> > > The above quote is from two guys at Sun - amazing. > > Their paper says basically - if you want to run two Java > applications on the same machine you have to fire up two JVMs and run > each one as a separate OS process. So despite the fact that Java is a > "safe" language (with GC etc) you still need the protection as > provided by OS processes. > > Despite this fact Java is still used as a systems programming > language -- amazing, since *nobody* knows how to run multiple Java > applications on the same machine *without* protecting them within OS > processes (what do you do, give *every* programmer an OS process to > play in ... :-) - Until this problem is solved Java should not be used > for systems applications (it was, after all, *designed* for applets, > where it works well and the abstractions are appropriate) ... > > As for pure message passing - In 1978 PLITS was invented > (Programming language in the sky) - this was a pure message passing > system - The authors of PLITS argued that "complex concurrency > patterns" and "shared memory" was no-no. They thought that shared > memory models just didn't work with complex concurrency pattern, they > thought that programming such a system would be impossibly difficult. > > The PLITS people just cared about pure message passing between > isolated processes - "communicating black boxes" they didn't even care > about what language was *inside* the black box (this is *precisely* > the XML/SOAP philosophy of black boxes communicating via XML messages, > or the UBF philosophy) > > Having introduced the idea of a COPL I talk about fault-tolerance. > > To make a fault-tolerant applications you need TWO computers AND > they cannot share data (because If you only have one computer it might > crash) - thus you need isolation and pure message passing. > > The basis of fault-tolerant computations rests upon three things: > > a) isolation of components > b) pure message passing > c) stable storage > > a) the computers must be isolated - if one crashes the other must > continue > > Since the computers are isolated, they can share no data, therefore > the *only* way they can interact is by pure message passing (point b) > > c) stable storage is storage which survives a crash - you need this to > recover *after* a crash has occurred. > > Now a) and b) are built into Erlang. c) can be achieved in a number > of different ways - mnesia, asynchronous replications, etc. there are > lots of ways of doing this. > > The conclusion of all this is that if you want to make a > fault-tolerant system you *have* to get interested in COPLS. > > My current way of describing Erlang/OTP is saying that > > "it is a software emulation of the Tandem computer" > > Read Jim Gray's 1985 paper > > "Why do computers stop and what can be done about it? > > and you will immediately be struck by the similarity in the design of > the Tandem and of the Erlang/OTP system. > > The Tandem was for many years (and possible still is) one of the > best known architectures for making fault-tolerant systems - > > Incidentally, the tandem used "fail-fast processors" the idea was it a > failure occurs (ie an error which cannot be corrected) die as soon as > possible - *exactly* the "let it crash philosophy" in Erlang. > > /Joe > > > > > > Pete. > > > > Chris Pressey wrote: > > > On Tue, 27 May 2003 10:40:00 +0200 (CEST) > > > Joe Armstrong wrote: > > > > > > > > >> Eppur si sugat (was that right?) > > > > > > > > > (Not sure - Google just gave me a blank look when I tried it...) > > > > > > > > > > > > (interesting but marginally mathematical related stuff deleted.) > > > > -- martin j logan From enewhuis@REDACTED Wed May 28 20:54:53 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Wed, 28 May 2003 13:54:53 -0500 Subject: Little-Endian Active Mode Tcp ? Message-ID: <3ED505FD.6080604@futuresource.com> O most knowledgable ones, The active-mode {packet, 4} socket is AMAZING. This is what one needs. Beautiful. But... I'd love to get rid of the binary continuation fragments in my recursive feed parsers. I could do it if Erlang would parse the little-endian header. My messages originate from an Intel box and the 4-byte size header is little-endian. I want Erlang to handle those headers so I can simplify my parser code to focus on the message content instead of content + framing. 1. Is there a way to do this without hacking the Erlang source? 2. If not then is there a way to do this by hacking the Erlang source? 3. Or maybe there is a parser pattern/behavior/template that I should use that has a simple "callback" or message-passing model that gives me what I want? 4. Or is there a way to install a specific protocol handler. I see the asn stuff and wonder. Suggestion: Perhaps a {packet, -2} or {packet, -4} for little-endian packet headers would round-out the built-in active socket logic. Sincerely, Eric Newhuis From kent@REDACTED Wed May 28 21:01:07 2003 From: kent@REDACTED (Kent Boortz) Date: 28 May 2003 21:01:07 +0200 Subject: Compiling erl_interface by Borland C++ Builder 6 In-Reply-To: <3ED4E11C.9070400@hq.idt.net> References: <3ED4E11C.9070400@hq.idt.net> Message-ID: Serge Aleynikov writes: > While trying to build a couple of projects that utilize ei / > erl_interface in Borland C++ Builder I had to rebuild the > erl_interface.lib and ei.lib and encountered the following > incompatibility: . . > 2. --------- *.h ----------------- > > The __STDC__ test in all header files > > #ifdef __STDC__ > > needs to be rewritten as: > > #if defined(__STDC__) || defined(__BORLANDC__) I found this information in a news message __STDC__ is a compiler-defined symbol and is documented in your Borland C++ help file. This symbol is only defined when the compiler is in ANSI "C" mode. By default, the compiler is in "Borland extensions" mode and so __STDC__ is *not* normally defined. Have you tried compiling erl_interface with the compiler in ANSI C mode? kent From per@REDACTED Wed May 28 21:36:52 2003 From: per@REDACTED (Per Hedeland) Date: Wed, 28 May 2003 21:36:52 +0200 (CEST) Subject: Little-Endian Active Mode Tcp ? In-Reply-To: <3ED505FD.6080604@futuresource.com> Message-ID: <200305281936.h4SJaqiI079328@tordmule.bluetail.com> Eric Newhuis wrote: > >The active-mode {packet, 4} socket is AMAZING. This is what one needs. >Beautiful. But... > >I'd love to get rid of the binary continuation fragments in my recursive >feed parsers. I could do it if Erlang would parse the little-endian >header. My messages originate from an Intel box and the 4-byte size >header is little-endian. I want Erlang to handle those headers so I can >simplify my parser code to focus on the message content instead of >content + framing. The {packet, N} format (whether on a socket or a port) is endian- independent - always most significant byte first (or is it last?:-). I guess you can call that "big-endian" like the docs do, but IMHO that term doesn't really apply to bytes on a wire. If whatever is sending the packets doesn't obey that, it has a bug - I would certainly hope that it isn't another Erlang node. (I.e. don't do write(fd, &integer, 4) in your C code, which is inherently non-portable, but make sure you write the bytes in the right order by whatever means you prefer...) --Per Hedeland From enewhuis@REDACTED Wed May 28 21:44:35 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Wed, 28 May 2003 14:44:35 -0500 Subject: Little-Endian Active Mode Tcp ? In-Reply-To: <200305281936.h4SJaqiI079328@tordmule.bluetail.com> References: <200305281936.h4SJaqiI079328@tordmule.bluetail.com> Message-ID: <3ED511A3.3050104@futuresource.com> > "...which is inherently non-portable..." Hmmmmm, Revealed my ignorance is. From cpressey@REDACTED Wed May 28 22:02:16 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 28 May 2003 15:02:16 -0500 Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) In-Reply-To: <1054140275.12985.63.camel@berimbau.vail> References: <1054140275.12985.63.camel@berimbau.vail> Message-ID: <20030528150216.0b96ed62.cpressey@catseye.mb.ca> On 28 May 2003 11:44:36 -0500 martin j logan wrote: > "Why OO is less than sufficient for concurrent and fault tolerant > systems." The above title is not too interesting. "Why OO sucks" or > "Why OO is the worst thing since reality television" on the other hand > are titles that grabs peoples attention. A loaded, provocative (glamourous :) > title will entice people to read an article. And to write rebuttals, naturally. > Please forgive me if I am being presumptuous but I think Joe's main > point is that much of OO doctrine, philosophy and current > implementations render the paradigm quite unsuitable for concurrent, > fault tolerant systems. No one will argue that OO techniques are > useless for say, a GUI, etc. The point is that if you are interested > in programming for the niche that Erlang currently occupies then OO > inherently sucks for your purposes and you should embrace the > doctrines described by "COPL", its forefathers, and influences. Does it *inherently* suck, even for COPL? Smalltalk-style OO *is* "communicating black boxes" AFAICT. Once (on another mailing list far far away) I proposed that one of the properties of objects was that they were chronologically independent (i.e. - since they isolated state from one another, they could well be concurrent.) Naturally, most people on that list thought that was ridiculous, since they don't do that in Java or C++, so it's "not OO". I think the reason this is even an issue in the first place is because several months ago some brave Erlang newbie came on this list and informed us that records suck. I took exception to that, too, and tried to explain how records don't always suck - but eventually settled with the idea that, in order for a replacement for records to not suck as badly, some research would have to be done into what means of aggregating data & code have succeeded in not sucking. i.e. to look into fields like OO and take what works and leave behind what doesn't. But if the anti-OO sentiment in Erlang becomes fundamental, there's no point - anything from OO would be rejected on the grounds that OO inherently sucks for COPL - and the best I could hope for would be that all the relevant OO techniques would be adopted individually and renamed so that we could blissfully pretend that they had nothing to do with OO. Thus confusing newbies all the more. > My couple of pennies, > Martin -Chris From cpressey@REDACTED Wed May 28 22:08:10 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 28 May 2003 15:08:10 -0500 Subject: Distributed Processing Algorithms In-Reply-To: <4.2.2.20030528052923.00cf3b50@duomark.com> References: <4.2.2.20030528052923.00cf3b50@duomark.com> Message-ID: <20030528150810.421f814d.cpressey@catseye.mb.ca> On Wed, 28 May 2003 05:33:09 -0700 Jay Nelson wrote: > Anybody have recommended reading on the topic of > Distributed Processing Algorithms? I am looking for > seminal texts, papers, research or even speculation. > > My interest is how to express computation in a fully > distributed network of equal CPUs, without resorting > to a task manager or other such process. I want the > nodes to independently decide what to do, yet the > group as a whole needs to coordinate their activate > with the least amount of overlap in computation or > negotiation. I am trying to avoid introducing single > points of failure. > > jay One thing to look into might be Linda: http://c2.com/cgi/wiki?LindaLanguage I'm actually a bit surprised that I haven't heard of anyone working on an Erlang-Linda project, but then, I think you can maybe get 80% of the same functionality with subscription to distributed Mnesia database events, so maybe it's not that surprising. -Chris From kent@REDACTED Wed May 28 22:53:27 2003 From: kent@REDACTED (Kent Boortz) Date: 28 May 2003 22:53:27 +0200 Subject: Little-Endian Active Mode Tcp ? In-Reply-To: <3ED505FD.6080604@futuresource.com> References: <3ED505FD.6080604@futuresource.com> Message-ID: Eric Newhuis writes: > The active-mode {packet, 4} socket is AMAZING. This is what one > needs. Beautiful. But... > > I'd love to get rid of the binary continuation fragments in my > recursive feed parsers. I could do it if Erlang would parse the > little-endian header. My messages originate from an Intel box and the > 4-byte size header is little-endian. I want Erlang to handle those > headers so I can simplify my parser code to focus on the message > content instead of content + framing. > > 1. Is there a way to do this without hacking the Erlang source? > 2. If not then is there a way to do this by hacking the Erlang source? If you don't have control of the originating side (no source) you could hack the emulator to handle these packets. But a nicer way is probably to do it all in Erlang using two reads with gen_tcp:recv() for each packet, first read the four length bytes, calculate the size from the bytes and read the exact packet body with a new gen_tcp:recv(). If you want to hack the emulator for the fun of it you have to define a constant in "lib/kernel/src/inet_int.hrl" and add your packet type in "lib/kernel/src/prim_inet.erl" in the function type_opt(). -define(TCP_PB_R4, 15). % Reverse byte order Then add code in "erts/emulator/drivers/common/inet_drv.c" for handling the header. Define #define TCP_PB_R4 15 and duplicate all code handling TCP_PB_4 and change TCP_PB_4 to TCP_PB_R4. Finally add the small change for reading the size case TCP_PB_R4: /* TCP_PB_R4: [L0,L1,L2,L3 | Data] */ hlen = 4; if (n < hlen) goto more; plen = get_int32_le(ptr); goto remain; . . case TCP_PB_R4: put_int32_le(len, buf); h_len = R4; break; . . case TCP_PB_R4: put_int32_le(len, buf); h_len = R4; break; Add to "erts/emulator/beam/sys.h" the macros #define get_int32_le(s) ((((unsigned char*) (s))[3] << 24) | \ (((unsigned char*) (s))[2] << 16) | \ (((unsigned char*) (s))[1] << 8) | \ (((unsigned char*) (s))[0])) #define put_int32_le(i, s) {((char*)(s))[3] = (char)((i) >> 24) & 0xff; \ ((char*)(s))[2] = (char)((i) >> 16) & 0xff; \ ((char*)(s))[1] = (char)((i) >> 8) & 0xff; \ ((char*)(s))[0] = (char)((i) & 0xff);} At least I think this will do it ;-) kent From serge@REDACTED Wed May 28 21:24:06 2003 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 28 May 2003 15:24:06 -0400 Subject: Compiling erl_interface by Borland C++ Builder 6 References: <3ED4E11C.9070400@hq.idt.net> Message-ID: <3ED50CD6.3050101@hq.idt.net> > I found this information in a news message > > __STDC__ is a compiler-defined symbol and is documented in your Borland C++ > help file. > > This symbol is only defined when the compiler is in ANSI "C" mode. By > default, the compiler is in "Borland extensions" mode and so __STDC__ is > *not* normally defined. > > Have you tried compiling erl_interface with the compiler in ANSI C mode? Yes, I have tried to turn on that compatibility option, which in turn, resulted in a handful of error messages within Borland's standard header files. It didn't raise issues for compiling erl_interface in "Borland extensions" compilation mode. I include here the project files for BC++ Builder 6 required to build ei.dll and ei_int.lib under Windows (tested with 2000, and XP). Serge -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: erl_int.bpr URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ei.bpr URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: erl_int.bpf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ei.bpf URL: From erlang@REDACTED Thu May 29 09:17:30 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 29 May 2003 08:17:30 +0100 Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) References: <1054140275.12985.63.camel@berimbau.vail> <20030528150216.0b96ed62.cpressey@catseye.mb.ca> Message-ID: <3ED5B40A.8030907@manderp.freeserve.co.uk> Morning Chris, > Smalltalk-style OO *is* "communicating black boxes" AFAICT. > Once (on another mailing list far far away) I proposed that one of the > properties of objects was that they were chronologically independent > (i.e. - since they isolated state from one another, they could well be > concurrent.) Naturally, most people on that list thought that was > ridiculous, since they don't do that in Java or C++, so it's "not OO". ...and this is why almost so called OO _languages_ suck! The OO "paradigm" itself is not objectionable(!) to me, but the current *implementations* are. Smalltalk is probably the least offensive example of OO that I can think of, and having used a similar late-binding loose-typed proprietry language I can appreciate the rapid prototyping and runtime error recovery. But C++ and Java have lost these most attractive aspects by attempting to be strong-typed and early-binding. > [...] in order for a replacement for records to not suck as > badly, some research would have to be done into what means of > aggregating data & code have succeeded in not sucking. i.e. to look > into fields like OO and take what works and leave behind what doesn't. I find that records in themselves are syntactically ugly, but semantically useful. The only thing about records I would change would be the syntax, and only for aesthetic reasons. > But if the anti-OO sentiment in Erlang becomes fundamental, there's no > point - anything from OO would be rejected on the grounds that OO > inherently sucks for COPL - [...] We discussed this at the London Erlounge over a few pints and fine food at the http://www.lowlander.com/ last night, and I think that dogmatism tends to set in when all one has is a single paradigm to use as an abstraction of our perception of the world and as a frame for our beliefs. A Java/C++ programmer without knowledge of other programming languages can only grasp concepts that relate to Java/C++. I don't think that the good people discussing on this list are exclusively Erlang evangelists or even functional fundamentalists, and wouldn't reject a good idea simply because it's not FP/COPL. In fact I've mostly found that ideas are freely discussed here, it's a pleasantly open-minded discussion group. Pete. From flaig@REDACTED Thu May 29 09:58:27 2003 From: flaig@REDACTED (Dr.Dr.Ruediger M.Flaig) Date: Thu, 29 May 2003 00:58:27 -0700 (PDT) Subject: Erlang rocks (Re: Eppur si sugat) Message-ID: <20030529075827.6D6203AD0@sitemail.everyone.net> Hi all, from my bit of Italian, I think it ought to be "Eppur suga" -- the Latin -t is dropped in the 3rd person singular AFAIK, and it is certainly not reflexive... it does not suck itself, that were recursion. ;-))) Now for something more serious... I think the basic sentiment we all share is that Java sucks, and that C++ sucks. They do, and very badly too, and it is annoying to see that they have become a kind of de facto standard. I have used both (more than Erlang, I am afraid -- as a molecular biologist, I have to deal with megabyte arrays, and that is not quite what Erlang was designed for -- sinner repent -- well Ocaml is quite nice too ;-) ), and I am equally fed up with the cobolesque boilerplate of "private final static paralyzed karl.otto.gustav emil = (karl.otto.gustav) ((egon.kasimir) foo.bar().blah[anything])" and the orkish scrawls of "#define n(x,i,j) {*++(*x)->y %= (i>j)?&i--:--&j}", not to mention memory leaks and, and, and... Maybe OO itself does not suck but a concept without implementation is void. But I think we are missing the point. The important thing is not that OO is an inferior concept but that FP (or COPL, if you please) is a superior one. Erlang were still great even Stroustrup and Gosling had never come near a computer -- because it enables you to be productive, to write clear and concise code, to cope with errors and, last but not least, because it allows reasoning. This latest thing is what I have really been missing. Erlang is a functional language, so it should be possible to employ automatic theorem provers and all that kind of stuff. Cummings wrote about ML: "We are not trying to develop 'safer' programs by testing, but developing SAFE programs by reasoning." This is a very philosophical matter. Let me say that Java and C++ rely on induction, Erlang allows deduction, and Sir Karl Popper has said the rest about that, decades ago. So are there any theorem provers for Erlang, as there are for Lisp and ML? Can we prove a program's correctness by reasoning? If not, let's do that! The other point is that the power of Erlang's concurrency is often underestimated by folks who are not interested in parallelism itself. I am a complete layman to that field but I think that neuronal networks would be a great thing do with Erlang. Has anybody tried this before? Are there any projects in similar fields? Personally, I was attracted to Erlang because I felt that simulation of complex biological processes would be easy to implement. Imagine you have a microbe with some 4000 genes, each with a state of activity and each influencing a couple of others. In Erlang, this would be straightforward... I met a guy who did the like and spend a year on that programming the basic mechanism in Java! So I think we could get away from that "Erlang? Oh, that's for telephones only" image. Has anybody worked on this yet? Sk?l, Ruediger Marcus Flaig Dr. Dr. Ruediger Marcus Flaig Institute for Immunology University of Heidelberg Im Neuenheimer Feld 305 D-69120 Heidelberg Tel. +49-172-7652946 | +49-6221-56-5402 | +49-6221-432963 _____________________________________________________________ Free eMail .... the way it should be.... http://www.hablas.com _____________________________________________________________ Select your own custom email address for FREE! Get you@REDACTED w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag From peter@REDACTED Thu May 29 10:39:25 2003 From: peter@REDACTED (peter@REDACTED) Date: Thu, 29 May 2003 09:39:25 +0100 (BST) Subject: Little-Endian Active Mode Tcp ? In-Reply-To: <3ED505FD.6080604@futuresource.com> References: <3ED505FD.6080604@futuresource.com> Message-ID: <24317.149.254.120.136.1054197565.squirrel@www.lundata.se> Yeah, I have tried it out too, but I am having another problem. The Erlang 4 byte packet header is a count on the REMAINING part of the package. In the SMPP protocol (SMS stuff), the 4 byte length value should be the length of the REMAINING part + the 4 byte header size. (the value defined in SMPP is thus differing by 4 from the value in Erlang/OTP). Is there any way to change the counting in the gen_tcp module? Peter > O most knowledgable ones, > > The active-mode {packet, 4} socket is AMAZING. This is what one needs. > Beautiful. But... > > I'd love to get rid of the binary continuation fragments in my > recursive feed parsers. I could do it if Erlang would parse the > little-endian header. My messages originate from an Intel box and the > 4-byte size header is little-endian. I want Erlang to handle those > headers so I can simplify my parser code to focus on the message > content instead of content + framing. > > 1. Is there a way to do this without hacking the Erlang source? > 2. If not then is there a way to do this by hacking the Erlang source? > 3. Or maybe there is a parser pattern/behavior/template that I should > use that has a simple "callback" or message-passing model that gives me > what I want? > 4. Or is there a way to install a specific protocol handler. I see the > asn stuff and wonder. > > Suggestion: Perhaps a {packet, -2} or {packet, -4} for little-endian > packet headers would round-out the built-in active socket logic. > > Sincerely, > Eric Newhuis From serge@REDACTED Thu May 29 01:12:40 2003 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 28 May 2003 19:12:40 -0400 Subject: erl_interface Message-ID: <3ED54268.5050803@hq.idt.net> Serge Aleynikov writes: > I wonder if you could share some of your erl_interface examples with > me. I've been trying to write some code that passes either a > tuple/list, or an integer from C to Erlang, and I am having a problem > that in case of integers (see iterate() and finalize() below) Erlangs > gets a response correctly, but in case of tuple/list (see > initialize()), looks like Erlang is waiting for something in addition > to what the port replies. I can see in debugger that the Port sends > everything normally, and than blocks on the read() function as > expected. After spending a couple of days in trying to figure out why the C port failed to pass complex (tuple/list) structures back to Erlang under Windows, I found the cause of the problem, which I wanted to share with the rest of the Erlang community. By default the stdout is open in the O_TEXT mode. What this implies is that in text mode, carriage-return/linefeed (CR/LF) combinations are translated to a single linefeed character (LF) on input. On output, the reverse is true: LF characters are translated to CR/LF combinations (under Windows OS). In binary mode, no such translation occurs. So, initially I couldn't figure out why after sending from C to Erlang a tuple of size 10 bytes, Erlang waited for more data. After dumping the stdout to a binary file, I noticed that Windows substituted the value of 10 (LF) with 13,10 (CR/LF) (just as the document said :-)). So Erlang was waiting for 13 bytes instead of 10, and my C port was blocking in the read() function forever. So, for those of you developing C ports under Windows, plese do remember to set the stdout mode to O_BINARY in the beginning of the program: setmode(fileno(stdout), O_BINARY); this will save you from sleepless nights bewildered by the cause of the trouble. ;-) Regards, Serge From cpressey@REDACTED Thu May 29 09:58:19 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 29 May 2003 02:58:19 -0500 Subject: Erlang/OTP as OSS (was Re: Glamour, elegance, universality and emergent techniques) In-Reply-To: <4.2.2.20030528063438.00cf5220@duomark.com> References: <4.2.2.20030528063438.00cf5220@duomark.com> Message-ID: <20030529025819.19e71260.cpressey@catseye.mb.ca> On Wed, 28 May 2003 07:08:20 -0700 Jay Nelson wrote: > Once again the OO discussion rises and the blasphemers > curse in church -- during the silence when all are listening, > no less! One hopes this can only mark the coming enlightenment > fomented by a scientific revolution > (see http://www.emory.edu/EDUCATION/mfp/Kuhnsnap.html). Ooh, good page, some really good criticisms linked at the bottom too. I could go on about paradigms, but, no, I'll try to stick to something less offtopic. I found an interesting site quite by accident while searching for info on folding editors. http://www.softpanorama.org/ Some of the sanest stuff I've seen written about Open Source, especially when compared to the output of TLA's like RMS and ESR. Bezroukov's writings are actually one of the things that got me thinking about glamour (and cursing in church...) Particularly interesting wrt Erlang: http://www.firstmonday.org/issues/issue4_12/bezroukov/index.html "Complexity and size effectively close source code for system programming projects like OSes [and] compilers after, say, 100K lines of code without good higher level documentation or participation in the project from its early stages." Granted, Erlang is better documented than most "big" OSS projects - but there are about *500K* lines of Erlang code in the OTP distro! Certainly most of the "binarization" is merely the vague feeling of intimidation that comes from trying to work with something so massive - but at the same time I doubt I'll ever fully understand some of the design decisions, such as those behind the I/O subsystem, the shell, the code loader, the bootstrapped building process... if I'm lucky I'll maybe pick up one or two. If I were to get extremely lucky and have the opportunity to work on it full-time with other Erlang engineers, I'm sure I'd be able to (and in fact be required to) pick up much more through sheer osmosis. But I do think most people outside Ericsson who use it are simply going to use it, rather than examine or hack it - just like most people who use Linux or FreeBSD just use it rather than examining it or hacking it. If, as Bezroukov asserts, "the key to successful programming is not "source code", it's "understanding"," then maybe my OSS-time would be better invested in *deconstructing* Erlang, rather than trying to help improve it? I dunno, worth thinking about though. -Chris From erlang@REDACTED Thu May 29 11:08:48 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 29 May 2003 10:08:48 +0100 Subject: Erlang rocks (Re: Eppur si sugat) References: <20030529075827.6D6203AD0@sitemail.everyone.net> Message-ID: <3ED5CE20.2070408@manderp.freeserve.co.uk> Have a look here: http://www.sics.se/fdt/projects/vericode/index.html However, I'm not so sure that the proof of correctness is either absolutely necessary or even achievable. But I'm a pragmatist, not a mathematician, and pragmatically I find that Erlang has a vastly superior way of dealing with the unexpected. In all other languages I know there is nothing that equals the process linking and exit trapping provided by Erlang. Being able to effectively and efficiently firewall suspect code with supervisor processes is remarkably powerful. It doesn't guarantee that code will _always_ work correctly, but it does prevent a mistake becoming a disaster! Even when there is a basic error trapping mechanism, as with C++ exceptions, I've found that some programmers *avoid* using it due to efficiency concerns with stack unrolling! When something has failed, what's the point of rushing to bring the *whole* system down?! If the error is handled correctly by a conscientious programmer, they would perform the same process of unrolling with no discernable benefit and possibly introduce more bugs too. I've tried to explain this to these hot-heads but they didn't get it! How can one sell the virtues of program verification to code monkeys like them? I think firewalling their code is the only solution! Pete. Dr.Dr.Ruediger M.Flaig wrote: > Hi all, > > from my bit of Italian, I think it ought to be "Eppur suga" -- the Latin -t is dropped in the 3rd person singular AFAIK, and it is certainly not reflexive... it does not suck itself, thaat were recursion. > ;-))) > > Now for something more serious... I think the basic sentiment we all share is that Java sucks, and that C++ sucks. They do, and very badly too, and it is annoying to see that they have become a kind of de facto standard. > > I have used both (more than Erlang, I am afraid -- as a molecular biologist, I have to deal with megabyte arrays, and that is not quite what Erlang was designed for -- sinnerr repent -- well Ocaml is quite nice too ;-) ), and I am equally fed up with the cobolesque boilerplate of > "private final static paralyzed karl.otto.gustav emil = (karl.otto.gustav) ((egon.kasimir) foo.bar().blah[anything])" > and the orkish scrawls of > "#define n(x,i,j) {*++(*x)->y %= (i>j)?&i--:--&j}", not to mention memory leaks and, and, and... Maybe OO itself does not suck but a concept without implementation is void. > > But I think we are missing the point. The important thing is not that OO is an inferior concept but that FP (or COPL, if you please) is a superior one. Erlang were still great even Stroustrup and Gosling had never come near a computer -- because it enables you to be productive, to write clear and concise code, to cope with errors and, last but not least, becaause it allows reasoning. > > This latest thing is what I have really been missing. Erlang is a functional language, so it should be possible to employ automatic theorem provers and all that kind of stuff. Cummings wrote about ML: "We are not trying to develop 'safer' programs by testing, but developing SAFE programs by reasoning." This is a very philosophical matter. Let me say that Java and C++ rely on induction, Erlang allows deduction, and Sir Karl Popper has said the rest about that, decades ago. So are there any theorem provers for Erlang, as there are for Lisp and ML? Can we prove a program's correctness by reasoning? If not, let's do that! > > The other point is that the power of Erlang's concurrency is often underestimated by folks who are not interested in parallelism itself. I am a complete layman to that field but I think that neuronal networks would be a great thing do with Erlang. Has anybody tried this before? Are there any projects in similar fields? Personally, I was attracted to Erlang because I felt that simulation of complex biological processes would be easy to implement. Imagine you have a microbe with some 4000 genes, each with a state of activity and each influencing a couple of others. In Erlang, this would be straightforward... I met a guy who did the like and spend a year on that programming the basic mechanism in Java! So I think we could get away from that "Erlang? Oh, that's for telephones only" image. > > Has anybody worked on this yet? > > > Sk?l, > Ruediger Marcus Flaig > > > > > > Dr. Dr. Ruediger Marcus Flaig > Institute for Immunology > University of Heidelberg > Im Neuenheimer Feld 305 > D-69120 Heidelberg > > Tel. +49-172-7652946 > | +49-6221-56-5402 > | +49-6221-432963 > > _____________________________________________________________ > Free eMail .... the way it should be.... > http://www.hablas.com > > _____________________________________________________________ > Select your own custom email address for FREE! Get you@REDACTED w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag > > From eleberg@REDACTED Thu May 29 14:31:27 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 29 May 2003 14:31:27 +0200 (MEST) Subject: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) Message-ID: <200305291231.h4TCVRq23970@cbe.ericsson.se> > Date: Wed, 28 May 2003 15:02:16 -0500 > From: Chris Pressey > Subject: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat) ...deleted > badly, some research would have to be done into what means of > aggregating data & code have succeeded in not sucking. abstract data types (adt). bengt From enewhuis@REDACTED Thu May 29 16:47:59 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 29 May 2003 09:47:59 -0500 Subject: Parallelism (Re: Erlang rocks (Re: Eppur si sugat)) In-Reply-To: <20030529075827.6D6203AD0@sitemail.everyone.net> References: <20030529075827.6D6203AD0@sitemail.everyone.net> Message-ID: <3ED61D9F.2050807@futuresource.com> Megabyte arrays? Need to analyze billions of records in seconds? It might be a job for a vector-friendly language. Try K? www.kx.com I use K for our time-series database to store every trade there ever was. 1000s of records per second all day long five days per week forever. (I've been working on a K-Erlang IPC bridge. So far so good.) But K and Erlang are oil and water. Parallelism: One thing that makes Erlang nice for parallelism is that it is easier to migrate processes among physical computing nodes. I do a lot of parallel stuff with gobs of data stored in RAM for the fastest throughput and response-time possible. And it is critical to be able to spread 1000s of processes among 100s of servers with little administrative overhead. Erlang is perfect for this. C++ is sub-optimnal for this, even when one uses specialized libraries. The memory bugs alone will kill you. From serge@REDACTED Thu May 29 12:59:59 2003 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 29 May 2003 06:59:59 -0400 Subject: Erlang rocks (Re: Eppur si sugat) Message-ID: <3ED5E82F.9040008@hq.idt.net> I happened to have quite a bit of experience with Neural Networks, (I got a Master degree in biomedical engineering, doing research in retinal image processing and automated feature extraction and classification using neural nets). For the past several months I've been studying Erlang, and see that while it is extreemly compact and efficient in solving distributed and concurrent problems, it lacks the computational power (which it wasn't designed for anyway). In Neural Nets one needs to perform a lot of calculations involved in training a network of neurons. The goal is given an input and knowing the output to find a distribution of weights between N interconnected nodes a multi-layered network that allows the network to be deterministic with respect to given input/output templates. The training involves a lot of iterations that are in the order of the number of neurons times the number of interconnects divided by some scalar. So in my opinion Erlang is not quite well suited for this performance-wise, as in my iterative tests it was about 10 to 13 times slower than C / Pascal. Regards, Serge Dr.Dr.Ruediger M.Flaig wrote: > Hi all, > > from my bit of Italian, I think it ought to be "Eppur suga" -- the Latin -t is dropped in the 3rd person singular AFAIK, and it is certainly not reflexive... it does not suck itself, thaat were recursion. > ;-))) > > Now for something more serious... I think the basic sentiment we all share is that Java sucks, and that C++ sucks. They do, and very badly too, and it is annoying to see that they have become a kind of de facto standard. > > I have used both (more than Erlang, I am afraid -- as a molecular biologist, I have to deal with megabyte arrays, and that is not quite what Erlang was designed for -- sinnerr repent -- well Ocaml is quite nice too ;-) ), and I am equally fed up with the cobolesque boilerplate of > "private final static paralyzed karl.otto.gustav emil = (karl.otto.gustav) ((egon.kasimir) foo.bar().blah[anything])" > and the orkish scrawls of > "#define n(x,i,j) {*++(*x)->y %= (i>j)?&i--:--&j}", not to mention memory leaks and, and, and... Maybe OO itself does not suck but a concept without implementation is void. > > But I think we are missing the point. The important thing is not that OO is an inferior concept but that FP (or COPL, if you please) is a superior one. Erlang were still great even Stroustrup and Gosling had never come near a computer -- because it enables you to be productive, to write clear and concise code, to cope with errors and, last but not least, becaause it allows reasoning. > > This latest thing is what I have really been missing. Erlang is a functional language, so it should be possible to employ automatic theorem provers and all that kind of stuff. Cummings wrote about ML: "We are not trying to develop 'safer' programs by testing, but developing SAFE programs by reasoning." This is a very philosophical matter. Let me say that Java and C++ rely on induction, Erlang allows deduction, and Sir Karl Popper has said the rest about that, decades ago. So are there any theorem provers for Erlang, as there are for Lisp and ML? Can we prove a program's correctness by reasoning? If not, let's do that! > > The other point is that the power of Erlang's concurrency is often underestimated by folks who are not interested in parallelism itself. I am a complete layman to that field but I think that neuronal networks would be a great thing do with Erlang. Has anybody tried this before? Are there any projects in similar fields? Personally, I was attracted to Erlang because I felt that simulation of complex biological processes would be easy to implement. Imagine you have a microbe with some 4000 genes, each with a state of activity and each influencing a couple of others. In Erlang, this would be straightforward... I met a guy who did the like and spend a year on that programming the basic mechanism in Java! So I think we could get away from that "Erlang? Oh, that's for telephones only" image. > > Has anybody worked on this yet? > > > Sk?l, > Ruediger Marcus Flaig From serge@REDACTED Thu May 29 13:09:20 2003 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 29 May 2003 07:09:20 -0400 Subject: Erlang Port Message-ID: <3ED5EA60.5070308@hq.idt.net> After spending a couple of days in trying to get the C port to work with Erlang under Windows, I seem to resolve most side-effect issues that were on the way of getting the port to work: http://www.erlang.org/ml-archive/erlang-questions/200305/msg00259.html However, I still have one problem. The port works reliably on small message packets (up to 1505 bytes), but when the message size exceeds this barrier, the remaining Erlang -> C stream seems to be getting lost. I tried to enable stdin buffering in the C port, but I am not sure if Erlang is buffering it's stdout in sending data. Is there a way to chack/enable it? Thanks. Serge From vances@REDACTED Thu May 29 18:55:08 2003 From: vances@REDACTED (Vance Shipley) Date: Thu, 29 May 2003 12:55:08 -0400 Subject: Learning by reading code In-Reply-To: References: Message-ID: <20030529165508.GB90945@frogman.motivity.ca> Dominic, The directive is documented in the Erlang Specification: http://www.erlang.org/download/erl_spec47.ps.gz While out of date this is the most definitive documentation there exists on the core language. -Vance On Tue, May 27, 2003 at 09:46:47AM +0200, WILLIAMS Dominic wrote: } } I came across the following things (in xmerl) for which I could } find no explanation in the documentation: } } -compile(export_all). From enewhuis@REDACTED Thu May 29 19:17:36 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 29 May 2003 12:17:36 -0500 Subject: Idleness Signal Message-ID: <3ED640B0.4080903@futuresource.com> I have a "time trial" test whereby I cram a bunch of data into a multi-process single-node Erlang application and then wait for things to "settle down". The application has a lot of messaging and I do not wish to intrude on the messaging pipeline to determine an exact event-driven completion signal. My goal is to determine the total cost of processing my batch of input messages and to compare the various run times among different algorithms, data structures, optimizations, etc. I also intend to use eprof to investigate with finer granularity to help explain differences in "time trial" results. So I am not seeking a substitute for eprof. I love eprof. I am building a complimentary tool. Can anyone suggest alternatives for raising a signal that says that an Erlang node is idle? I am currently entertaining the thought of polling the total REDS, as seen in erl's i() output and terminating my test when the REDS is unchanged for 1 second. Since I think I am all CPU bound during this test I think this will work. (I/O-bound conditions may effect false triggers.) Is there a more clever way to raise such a signal? ...more clever than polling REDS? I don't need precision beyond 1 second; my time trial is expected to run for several minutes to an hour. Sincerely, Eric Newhuis From cpressey@REDACTED Thu May 29 23:14:58 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 29 May 2003 16:14:58 -0500 Subject: Syntax & Records (was: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat)) In-Reply-To: <3ED5B40A.8030907@manderp.freeserve.co.uk> References: <1054140275.12985.63.camel@berimbau.vail> <20030528150216.0b96ed62.cpressey@catseye.mb.ca> <3ED5B40A.8030907@manderp.freeserve.co.uk> Message-ID: <20030529161458.0ddefe13.cpressey@catseye.mb.ca> On Thu, 29 May 2003 08:17:30 +0100 Peter-Henry Mander wrote: > Morning Chris, Good afternoon! > [...] > But C++ and Java have lost these most > attractive aspects by attempting to be strong-typed and early-binding. .'. statically-architected pre-planning sucks. > > [...] in order for a replacement for records to not suck as > > badly, some research would have to be done into what means of > > aggregating data & code have succeeded in not sucking. i.e. to look > > into fields like OO and take what works and leave behind what > > doesn't. > > I find that records in themselves are syntactically ugly, but > semantically useful. The only thing about records I would change would > be the syntax, and only for aesthetic reasons. Erlang's syntax is pretty dire anyway - better than C++ or Perl, but for every nice thing in it I bet I can find something nasty. In that light, the record syntax doesn't seem too bad. My problems with records are more semantic: - they're optimized for performance - which is not always the #1 goal - they're compile-time only - making general functions which work on records very awkward to write - they're not a real type - they're "repurposed" tuples - they're not typesafe - A#b "casts" A as a b whether it is or not - when used across modules you get header file dependency headaches, esp. during code upgrade - when used internal to a module, they can't be pattern-matched from outside that module These all more or less follow from the first. If you're willing to take the performance hit, dicts solve many of the problems. But you can't pattern-match on dict contents, which is why structs look appealing. > [...] > I've mostly found that ideas are freely discussed here, it's a > pleasantly open-minded discussion group. The fact that I haven't been ridden out of town in a rail yet speaks volumes for the tolerance of the Erlang community :) However, pragmatism is a fly's eyebrow away from cynicism... One hopes the influence of the gurus' is only linearly proportional to their focus :) > Pete. -Chris From cpressey@REDACTED Thu May 29 23:38:07 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 29 May 2003 16:38:07 -0500 Subject: ADT's (was: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat)) In-Reply-To: <200305291231.h4TCVRq23970@cbe.ericsson.se> References: <200305291231.h4TCVRq23970@cbe.ericsson.se> Message-ID: <20030529163807.082798ef.cpressey@catseye.mb.ca> On Thu, 29 May 2003 14:31:27 +0200 (MEST) Bengt Kleberg wrote: > > > Date: Wed, 28 May 2003 15:02:16 -0500 > > From: Chris Pressey > > Subject: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si > > sugat) > ...deleted > > badly, some research would have to be done into what means of > > aggregating data & code have succeeded in not sucking. > > abstract data types (adt). ADT's are 90% of it. Encapsulation, interface - the important things. But each stands alone - they don't co-operate. That's the other 10%. Inheritance? Great when it's used wisely; almost never used wisely. It can be avoided by implementing ADT's in terms of other ADT's. Polymorphism? Forget it - it's another case of making relationships implicit - I'm against it on the same basis I'm against monads. The program is clearest when all relationships are made explicit. When two types really do share a common interface, I think it should probably be a behaviour, cleanly seperated. That leaves associations. They're really more in the realm of relational databases, but since most OO languages have shared state, they were easy to dovetail in. They wouldn't work the same in Erlang unless all ADT's were stored in [ets|dets|mnesia] tables - almost certainly a bad requirement! But associations are too useful to ignore - they're what makes an object model coherent IMO. Having Employee and Company types tells you very little - but knowing that a Company employs one or more Employees is halfway to implementing it... It's probably not as important to come up with a language mechanism, as it is to cultivate some kind of discipline or tradition (like e.g. Perl's approach to OO.) There's no shortage of examples; what's lacking is a comprehensive design pattern. > bengt -Chris From cpressey@REDACTED Thu May 29 23:59:11 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 29 May 2003 16:59:11 -0500 Subject: Erlang rocks (Re: Eppur si sugat) In-Reply-To: <20030529075827.6D6203AD0@sitemail.everyone.net> References: <20030529075827.6D6203AD0@sitemail.everyone.net> Message-ID: <20030529165911.20b92e23.cpressey@catseye.mb.ca> On Thu, 29 May 2003 00:58:27 -0700 (PDT) "Dr.Dr.Ruediger M.Flaig" wrote: > [...] > So are there any theorem provers for Erlang, as there are for > Lisp and ML? Yes, it's called "the human mind" :) Seriously, I think it's a lot more effective for the programmer to prove their code to his/herself while writing it, than to prove it mechanically after the fact. In fact I think most (good) programmers do this subconsciously, and testing is part of it, to reassure themselves that they wrote what they meant to write. I do think there's room for more verification in Erlang (e.g. inferring type signatures...) but I think it's more suited to the ground-up 'linting' variety. Disclaimer: I'm mostly a pragmatist too. -Chris From matthias@REDACTED Fri May 30 00:29:24 2003 From: matthias@REDACTED (Matthias Lang) Date: Fri, 30 May 2003 00:29:24 +0200 Subject: Erlang rocks (Re: Eppur si sugat) In-Reply-To: <20030529075827.6D6203AD0@sitemail.everyone.net> References: <20030529075827.6D6203AD0@sitemail.everyone.net> Message-ID: <16086.35268.759490.261589@antilipe.corelatus.se> Dr.Dr.Ruediger M.Flaig writes: > This latest thing is what I have really been missing. Erlang is > a functional language, so it should be possible to employ > automatic theorem provers and all that kind of stuff. Thomas Arts is one of the people who have been involved in work in this area. You can read about it here http://www.sics.se/fdt/projects/vericode/evt.html or on the links you get from google if you enter "Erlang Theorem Prover". Matthias From tony@REDACTED Fri May 30 00:47:31 2003 From: tony@REDACTED (Tony Rogvall) Date: 30 May 2003 00:47:31 +0200 Subject: Erlang rocks (Re: Eppur si sugat) In-Reply-To: <20030529165911.20b92e23.cpressey@catseye.mb.ca> References: <20030529075827.6D6203AD0@sitemail.everyone.net> <20030529165911.20b92e23.cpressey@catseye.mb.ca> Message-ID: <1054248451.13300.3.camel@bit.hemma.se> On Thu, 2003-05-29 at 23:59, Chris Pressey wrote: > On Thu, 29 May 2003 00:58:27 -0700 (PDT) > "Dr.Dr.Ruediger M.Flaig" wrote: > > it's called "the human mind" :) > > Seriously, I think it's a lot more effective for the programmer to prove > their code to his/herself while writing it, than to prove it > mechanically after the fact. In fact I think most (good) programmers do > this subconsciously, and testing is part of it, to reassure themselves > that they wrote what they meant to write. > I guess this is a flame, I wont go for it :-) /Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From sean.hinde@REDACTED Fri May 30 01:05:51 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 30 May 2003 00:05:51 +0100 Subject: Little-Endian Active Mode Tcp ? In-Reply-To: <24317.149.254.120.136.1054197565.squirrel@www.lundata.se> Message-ID: <17F45DDE-922A-11D7-A871-000A95927CCE@mac.com> On Thursday, May 29, 2003, at 09:39 AM, wrote: > Yeah, I have tried it out too, but I am having another problem. > > The Erlang 4 byte packet header is a count on the REMAINING part > of the package. In the SMPP protocol (SMS stuff), the 4 byte length > value should be the length of the REMAINING part + the 4 byte header > size. (the value defined in SMPP is thus differing by 4 from the > value in Erlang/OTP). > > Is there any way to change the counting in the gen_tcp module? > > Sadly no. Clearly then the problem is that the SMPP design is broken ;-) Sean From cpressey@REDACTED Fri May 30 02:31:59 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 29 May 2003 19:31:59 -0500 Subject: Erlang rocks (Re: Eppur si sugat) In-Reply-To: <1054248451.13300.3.camel@bit.hemma.se> References: <20030529075827.6D6203AD0@sitemail.everyone.net> <20030529165911.20b92e23.cpressey@catseye.mb.ca> <1054248451.13300.3.camel@bit.hemma.se> Message-ID: <20030529193159.456c1c2a.cpressey@catseye.mb.ca> On 30 May 2003 00:47:31 +0200 Tony Rogvall wrote: > On Thu, 2003-05-29 at 23:59, Chris Pressey wrote: > > On Thu, 29 May 2003 00:58:27 -0700 (PDT) > > "Dr.Dr.Ruediger M.Flaig" wrote: > > > > it's called "the human mind" :) > > > > Seriously, I think it's a lot more effective for the programmer to > > prove their code to his/herself while writing it, than to prove it > > mechanically after the fact. In fact I think most (good) > > programmers do this subconsciously, and testing is part of it, to > > reassure themselves that they wrote what they meant to write. > > > > I guess this is a flame, I wont go for it :-) > > /Tony Not at all, my good man! Although perhaps I stated it less than elegantly. Took me a while, but I managed to find where I picked up the notion: _Theories of Programming Languages_ by John C Reynolds (Cambridge University Press, 1998), p. 54 (emphasis mine): "This is not to say that every program merits formal proof. Experience with formal proof methods, however, also increases a programmer's ability to detect flaws in informal arguments. The inference rules introduced in this chapter are fundamental laws about imperative programming, in the same sense that the associative, commutative, and distributative laws are fundamental laws about arithmetic. When mathematically literate people perform or check an elementary algebraic manipulation, they rarely descend to the level of applying such laws explicitly, but their knowledge of these laws, and their experience in applying them, underly their ability to avoid and detect errors. _A similar knowledge and experience of program-proof systems can buttress such an ability for programming_." Further on, p. 71: "As a second example, we will prove the total correctness of a program that computes x^n in log n time. In this case, we want to demonstrate that _one does not have to prove programs after the fact, but that program proof can go hand in hand with program construction_." p. 72: "At this point, we have an informal account of the first step in a top-down program construction: _we know how to write the program if we can write a while body B with certain properties_." In other words: start with the specification, derive the program from it while proving it, and the program will be correct "out of the box". Of course, running the program through a proof-checker after all is said and done can't hurt either. But it seems like the long way around, and might be subject to the "seatbelt effect" where the programmer feels he or she can afford to be sloppy, not realizing that mistakes, even when caught, will still have to be fixed eventually. To say nothing about determining whether the specification for a large program is, itself, correct - oi! -Chris From vlad_dumitrescu@REDACTED Fri May 30 18:43:49 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 30 May 2003 18:43:49 +0200 Subject: Syntax & Records (was: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat)) References: <1054140275.12985.63.camel@berimbau.vail> <20030528150216.0b96ed62.cpressey@catseye.mb.ca> <3ED5B40A.8030907@manderp.freeserve.co.uk> <20030529161458.0ddefe13.cpressey@catseye.mb.ca> Message-ID: Hi, > My problems with records are more semantic: > - they're optimized for performance - which is not always the #1 goal > - they're compile-time only - making general functions which work on > records very awkward to write > - they're not a real type - they're "repurposed" tuples > - they're not typesafe - A#b "casts" A as a b whether it is or not > - when used across modules you get header file dependency headaches, > esp. during code upgrade > - when used internal to a module, they can't be pattern-matched from > outside that module > > These all more or less follow from the first. If you're willing to take > the performance hit, dicts solve many of the problems. But you can't > pattern-match on dict contents, which is why structs look appealing. Just one wild thought in the opposite direction from the one discussed before: Why not let records be as they are (or almost) and instead introduce pattern matching on dicts (and maybe other similar data structures)? As an afterthought, I think Joe's structs did work that way, and the idea might not be original. I think records and matchable-dicts/structs would make a very nice complementing pair. regards, Vlad From hal@REDACTED Fri May 30 23:33:21 2003 From: hal@REDACTED (Hal Snyder) Date: Fri, 30 May 2003 16:33:21 -0500 Subject: Erlounge Schaumburg, 2003-06-12 Message-ID: <87vfvsxgpq.fsf@ghidra.vail> Informal gathering of Erlang zealots is planned for Thursday, June 12 at 19:00 CDT. Location: Prairie Rock Brewery, 1385 N. Meacham, Schaumburg, IL, US. As they say, there's still plenty of room. Send email ahead if you like, or just show up and help us figure out What UBF is All About and other conundrums. From ulf.wiger@REDACTED Fri May 30 23:36:18 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Fri, 30 May 2003 23:36:18 +0200 Subject: Idleness Signal References: <3ED640B0.4080903@futuresource.com> Message-ID: <005a01c326f3$81e235a0$fd7a40d5@telia.com> You could also look at run_queue, which should normally be quite small. Of course, if you have one process doing tons of work, reductions will give you a better indicator. A combination of indicators is usually needed to get a good reading on processor load. In an I/O-bound system, run_queue is pretty good. In a CPU-bound system, reductions may work. But I would not go as far as waiting for reductions to be unchanged for one second. That may never happen. I think you should track these indicators for a while and try to determine what thresholds seem sensible. cpu_sup.erl may also be used for some perfmeter-like load measurements. /Uffe ----- Original Message ----- From: "Eric Newhuis" To: Sent: den 29 maj 2003 19:17 Subject: Idleness Signal > I have a "time trial" test whereby I cram a bunch of data into a > multi-process single-node Erlang application and then wait for things to > "settle down". > > The application has a lot of messaging and I do not wish to intrude on > the messaging pipeline to determine an exact event-driven completion > signal. My goal is to determine the total cost of processing my batch > of input messages and to compare the various run times among different > algorithms, data structures, optimizations, etc. > > I also intend to use eprof to investigate with finer granularity to help > explain differences in "time trial" results. So I am not seeking a > substitute for eprof. I love eprof. I am building a complimentary tool. > > Can anyone suggest alternatives for raising a signal that says that an > Erlang node is idle? > > I am currently entertaining the thought of polling the total REDS, as > seen in erl's i() output and terminating my test when the REDS is > unchanged for 1 second. Since I think I am all CPU bound during this > test I think this will work. (I/O-bound conditions may effect false > triggers.) > > Is there a more clever way to raise such a signal? ...more clever than > polling REDS? I don't need precision beyond 1 second; my time trial is > expected to run for several minutes to an hour. > > Sincerely, > Eric Newhuis > > From wicak.noeg@REDACTED Sat May 31 03:17:58 2003 From: wicak.noeg@REDACTED (wicaksono ) Date: Sat, 31 May 2003 08:17:58 +0700 Subject: OOT : Jambala Platform Message-ID: Hi all, sorry for my spamm I have found the article which explain that Erlang also used in Jambala platform , is it true ? by the way do you have any documentation about Jambala platform ? or how can I get it ? thanks wicak. Nb. please reply this email using private line =========================================================================================== "TELKOMNet Instan memberikan diskon 40% untuk akses malam hari dari pukul 23.00 sampai 06.00. Berlaku untuk wilayah Jawa Timur mulai 1 Mei 2003 sampai 30 Juni 2003." =========================================================================================== From fritchie@REDACTED Sat May 31 08:37:30 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Sat, 31 May 2003 01:37:30 -0500 Subject: Accept filters on FreeBSD? In-Reply-To: Message of "28 May 2003 10:43:14 BST." <1054114994.13253.1465.camel@localhost> Message-ID: <200305310637.h4V6bUjD017403@snookles.snookles.com> >>>>> "nd" == Niall Dalton writes: nd> Hello, Does anyone have experience using accept filters on FreeBSD nd> in Erlang applications? I'd never even heard of them until you mentioned them. I should spend more time reading "man" pages. :-) There's an undocumented function in the inet module that you could use to get the OS file descriptor associated with the socket. % erl Erlang (BEAM) emulator version 5.2.3.3 [source] [threads:0] Eshell V5.2.3.3 (abort with ^G) 1> {ok, Port} = gen_tcp:connect("localhost", 25, []). {ok,#Port<0.28>} 2> inet:getfd(Port). {ok,7} 3> According to the accf_http(9) man page, you'd need to call setsockopt() to invoke the proper magic. However, the inets driver doesn't know how to do that. Your options are: 1. Hack your "beam" executable to add the sockopt you need. 2. Create a linked-in driver that would take the file descriptor from inet:getfd() and invoke the setsockopt() as required. #2 would be really easy to do with EDTK. See http://www.snookles.com/erlang/edtk/ for the source code. Sorry it's a hassle to set up, but it really does work quite well once you've compiled the "gslgen" utility. Though I haven't tested it, this ought to work pretty well. Writing int my_setsockopt(int) is easy enough -- put it in my-sockopt.{h,c}. A very simple setsockopt() driver #include <errno.h> #include <my-sockopt.h> /* Just for prototype */ To make your life easier (probably), borrow the Makefile from the examples/simple0 driver to assist compiling & linking everything. -Scott From ulf.wiger@REDACTED Sat May 31 10:27:18 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Sat, 31 May 2003 10:27:18 +0200 Subject: Jambala Platform References: Message-ID: <001301c3274e$735b4700$fd7a40d5@telia.com> The Jambala platform uses a proprietary OS called Dicos, on which Erlang does not run. There are also UNIX file servers involved, and it would be possible, of course, to run Erlang there, but I do not know of any occasion where it's been done. The underlying execution platform, TelORB, is being ported to Linux, so it may be easier to combine Jambala and Erlang in the future, for those who wish it. For today, the best bet might be to use Orber, and run Erlang outside of the Jambala system, communicating with it using Corba. I don't know if Jambala documentation is freely available. The only open document I've come across is http://www.ericsson.com/about/publications/review/1998_03/files/1998033.pdf /Uffe ----- Original Message ----- From: "wicaksono " To: Sent: den 31 maj 2003 03:17 Subject: OOT : Jambala Platform > Hi all, > sorry for my spamm > I have found the article which explain that Erlang also > used in Jambala platform , is it true ? > by the way do you have any documentation about Jambala > platform ? or how can I get it ? > > thanks > > wicak. > > Nb. please reply this email using private line > ============================================================================ =============== > "TELKOMNet Instan memberikan diskon 40% untuk akses malam hari dari pukul 23.00 sampai 06.00. > Berlaku untuk wilayah Jawa Timur mulai 1 Mei 2003 sampai 30 Juni 2003." > ============================================================================ =============== From thomas@REDACTED Sat May 31 02:46:34 2003 From: thomas@REDACTED (Thomas Fee) Date: Fri, 30 May 2003 17:46:34 -0700 Subject: Accept filters on FreeBSD? In-Reply-To: <200305310637.h4V6bUjD017403@snookles.snookles.com> References: <200305310637.h4V6bUjD017403@snookles.snookles.com> Message-ID: <3ED7FB6A.4030305@versatechs.com> You mean the documentation is available as man pages?!! I've been using the erlang.org web site as my html lookup resource but I'd prefer man pages. Doing something in the shell is _so_ much quicker. How would I get the Erlang man pages into my system? ~Thomas Scott Lystig Fritchie wrote: >>>>>>"nd" == Niall Dalton writes: >>>>>> >>>>>> > >nd> Hello, Does anyone have experience using accept filters on FreeBSD >nd> in Erlang applications? > >I'd never even heard of them until you mentioned them. I should spend >more time reading "man" pages. :-) > >There's an undocumented function in the inet module that you could use >to get the OS file descriptor associated with the socket. > > % erl > Erlang (BEAM) emulator version 5.2.3.3 [source] [threads:0] > > Eshell V5.2.3.3 (abort with ^G) > 1> {ok, Port} = gen_tcp:connect("localhost", 25, []). > {ok,#Port<0.28>} > 2> inet:getfd(Port). > {ok,7} > 3> > >According to the accf_http(9) man page, you'd need to call >setsockopt() to invoke the proper magic. However, the inets driver >doesn't know how to do that. Your options are: > >1. Hack your "beam" executable to add the sockopt you need. > >2. Create a linked-in driver that would take the file descriptor from > inet:getfd() and invoke the setsockopt() as required. > >#2 would be really easy to do with EDTK. See >http://www.snookles.com/erlang/edtk/ for the source code. Sorry it's >a hassle to set up, but it really does work quite well once you've >compiled the "gslgen" utility. > >Though I haven't tested it, this ought to work pretty well. Writing >int my_setsockopt(int) is easy enough -- put it in my-sockopt.{h,c}. > > > > A very simple setsockopt() driver > > > #include <errno.h> > #include <my-sockopt.h> /* Just for prototype */ > > > > > > > > > >To make your life easier (probably), borrow the Makefile from the >examples/simple0 driver to assist compiling & linking everything. > >-Scott > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Sat May 31 19:11:19 2003 From: roger@REDACTED (roger) Date: Sat, 31 May 2003 10:11:19 -0700 Subject: First regular annual Bay Area Erlang Beer Break (BAEBB 2003) Message-ID: Hi, I'm not sure how many Erlang folks we have on this list live in the SF Bay Area, but I thought it would be a good idea to find out ! Anyone in the general vicinity of the SF Bay area interested in drinking coffee/beer on a weekday evening, in company of like minded people (but with different opinions :) ? If you are, let me know if the date/time below works for you. Default proposal would be to meet June 19 @ 7PM at Cafe Borrone, Menlo Park. Cheers, -Roger From matthias@REDACTED Sat May 31 20:09:28 2003 From: matthias@REDACTED (Matthias Lang) Date: Sat, 31 May 2003 20:09:28 +0200 Subject: Accept filters on FreeBSD? In-Reply-To: <3ED7FB6A.4030305@versatechs.com> References: <200305310637.h4V6bUjD017403@snookles.snookles.com> <3ED7FB6A.4030305@versatechs.com> Message-ID: <16088.61400.804735.292496@antilipe.corelatus.se> Thomas Fee writes: > You mean the documentation is available as man pages?!! > I've been using the erlang.org web site as my html lookup resource > but I'd prefer man pages. Doing something in the shell is _so_ > much quicker. > > How would I get the Erlang man pages into my system? One way would be to go to the "download" page and download the man pages and then install them. The "download" page is at http://www.erlang.org/download.html Another way is to use a distribution which installs the man-pages for you. For instance, if you use debian, you could do apt-get install erlang-manpages Matt From hal@REDACTED Sat May 31 20:15:29 2003 From: hal@REDACTED (Hal Snyder) Date: Sat, 31 May 2003 13:15:29 -0500 Subject: man pages In-Reply-To: <3ED7FB6A.4030305@versatechs.com> (Thomas Fee's message of "Fri, 30 May 2003 17:46:34 -0700") References: <200305310637.h4V6bUjD017403@snookles.snookles.com> <3ED7FB6A.4030305@versatechs.com> Message-ID: <874r3b6kzi.fsf_-_@ghidra.vail> Thomas Fee writes: > You mean the documentation is available as man pages?!! I've been > using the erlang.org web site as my html lookup resource but I'd > prefer man pages. Doing something in the shell is _so_ much quicker. > > How would I get the Erlang man pages into my system? Download otp_man_R9B-1.tar.gz from erlang site. Extract to /usr/local/lib/erlang or such (so "man" lands in same dir as erts-5.2.3.3). "erl -man erlang" for example to show BIFs, "erl -man erl" for the main CLI, usw. From vances@REDACTED Sat May 31 20:43:56 2003 From: vances@REDACTED (Vance Shipley) Date: Sat, 31 May 2003 14:43:56 -0400 Subject: man pages In-Reply-To: <874r3b6kzi.fsf_-_@ghidra.vail> References: <200305310637.h4V6bUjD017403@snookles.snookles.com> <3ED7FB6A.4030305@versatechs.com> <874r3b6kzi.fsf_-_@ghidra.vail> Message-ID: <20030531184355.GA99427@frogman.motivity.ca> Yes however you also need to add /usr/local/lib/erlang/man to your MANPATH. Do `man man` to figure that out. The problem with doing this is that there are conflicts with the system man pages. If you put the Erlang/OTP man pages first in the path you'll get them. If you put it last you'll get the system ones when there are conflicts. You can specify the MANPATH on the command line: man -p /usr/local/lib/erlang/man erts You might want to leave MANPATH alone and create an erlman shell command using the above. -Vance On Sat, May 31, 2003 at 01:15:29PM -0500, Hal Snyder wrote: } } Download otp_man_R9B-1.tar.gz from erlang site. } Extract to /usr/local/lib/erlang or such (so "man" lands in same dir } as erts-5.2.3.3). } } "erl -man erlang" for example to show BIFs, "erl -man erl" for the } main CLI, usw. From george@REDACTED Sat May 31 23:18:30 2003 From: george@REDACTED (George Shapovalov) Date: Sat, 31 May 2003 14:18:30 -0700 Subject: Gentoo: dev-lang/erlang In-Reply-To: <14e501c3240b$28a94d10$0a21970a@norris> References: <1053660475.1509.4.camel@localhost> <200305222134.29077.george@gentoo.org> <14e501c3240b$28a94d10$0a21970a@norris> Message-ID: <200305311418.31072.george@gentoo.org> Hi Bruce. Replying to the list, since this will probably concern many people. Pelease note, I am not on the list atm (though if more issues come up I believe I will have to sign up to this one :as well )), so if you want me to get your reply lease put me in CC. On Monday 26 May 2003 21:48, Bruce Fitzsimons wrote: > I agree it is complicated, I wasn't aware of those restrictions on ebuilds. > I would suggest simplifying the version number by treating the letters as > numbers, where A = 0, so R9B-1 becomes 9.1.1, R8A-0 becomes 8.0.0. A note > in the description that says the untranslated Erlang version number might > be handy too. Yup, incidentally I thought about this and was thinking about switching to similar scheme when R10 comes out :). I would probably have done so from the beginning had I not observed R8B and then R9B and assumed that this is a complete version name, e.g no stuff is going to be added after the last letter. And yea, the original submission by Charlie Mac had -8b in the name :). The real question however is what to do with the present stuff - the R9 versions. Its inconvenient version numbers vs having to move stuff that is already in and is depended upon by some other packages. Basically it comes down to the following questions: 1. How many more versions are planned in the R9 branch before R10 gets issued? If R9c will be followed by R10 it might be better to just keep this mismatch (9C will be 9d.ebuild) and switch to numeric versioning starting with R10 (note, the ordering of versions will be preserved in portage, so that newver versions will be picked up properly - thus the necessity of this mangling). 2. On a related note: how many gentoo usres are on this list? If there are any, would you prefer to have more correspondance in version numbers for 9B series (namely by mapping A=0, B=1, etc.) but you would have to remerge erlang in order to bring your system to a consistend state? (I think remerging packages dependent upon it can be avoided, unless this is done simultaneously with erlang update. Still unnecessary recompilation but seems to be the easiest way through this). Or would you rather live with this mismatch until R10 comes around? (you can always look up the "real" version in ebuild of course) Note, this change will be observable as "downgrade" as 9.x.xb is considered newver than 9.x.x with x's being any numbers. George